Claude CodeやCodexといったコーディングエージェントは、コーディングの効率化にとどまらず、調査やドキュメントの作成など、PCで行う多くのタスクを実行できるようになってきました。

私はプラットフォーム寄りのタスクやインフラのタスクを行うことが多く、一次情報を扱った調査や、他の箇所への影響調査を慎重に行う必要があります。 そのため、事前に情報を資料へ整理し、チームと認識を合わせてからタスクに取り掛かることも少なくありません。

最近は、このような調査をClaude Codeに任せています。 一度、Markdownなどのファイルに整理してもらい、その内容を見た上で設計や実装を進めるという流れです。

人間が実施すると数時間から数日はかかる調査も、LLMに任せると数分で終わります。 一方で、返却される資料を読み解くのには思いのほか時間がかかります。 読めば理解はできるものの、LLMが生成した文章は読みづらく、とても疲れるのです。

今回は、LLMが生成する調査資料はなぜこんなにも疲れるのかについて、最近気づいたことを書いてみたいと思います。

調査が速くても読むのは速くならない

LLMは、本来なら数時間かかる調査を数分で実施し、その結果を一つの資料にまとめます。 当然ながら、短時間で返ってくる資料であっても、含まれる情報は少なくありません。

一つの資料ならまだ読めますが、二つ、三つと異なるタスクを並行して、それぞれの資料が生成されると、読むだけで大変な時間がかかります。 時間がかかるのでLLMに要約を頼み、わからないところがあれば、さらにLLMへ質問することになります。

調査を待つ数分の間に別のタスクを始めることもあります。 しかし、別のことを考えてから結果へ戻ると、「これは何の話だったか?」となり、人間側のコンテキストを戻すところから始めなければなりません。

効率よく複数のタスクを進めているつもりが、資料を読み、コンテキストを切り替えることに時間を使ってしまいます。 このやり取りがとても疲れるのですが、私はその原因をしばらく言語化できませんでした。

欲しい情報と抽象度がずれている

最近、この疲れの原因は、私が知りたい内容とLLMが生成する内容の抽象度がずれていることにあるのではないかと気づきました。

例えば、新しい機能を追加するとき、最初に知りたいのは、その変更が他の箇所へどのような影響を与えるかということです。 他の箇所と照らし合わせたときに局所最適になっていないか、全体としてどの方針を選ぶべきかを考えたいのです。

一方で、どの実装箇所が影響を受けるのか、現在の実装がどうなっているのかといった具体的な情報は、方針が決まった後に考えればよいことです。 最初の意思決定では、そこまでの詳細を必要としていません。

しかし、LLMは一歩目の段階から詳細まで踏み込み、抽象的な方針と具体的な実装を一つの資料にまとめてくれます。 知りたいことは確かに含まれているのですが、今は必要のない情報も同じ粒度で並びます。

その結果、人間は具体的な情報を読み解きながら、より抽象度の高い判断に必要な情報を拾わなければなりません。 LLMが賢く、詳細まで調べられるからこそ生まれるこのギャップが、文章を読むときの疲れにつながっているのだと思います。

人間が関心を持つ場所の変化

以前は人間が自分の手でプログラムを書き、具体的な実装にも強い関心を持っていました。 しかし、LLMがコードを書くようになると、具体的な実装方法はAIに任せた方がよいのではないかと思うことが増えてきます。

その一方で、どこに問題があるのか、どのような方針で実装するのかといった、一歩抽象度の高い意思決定は人間が担う必要があります。 私はその話をしたいからこそ、具体的な内容まで混ざった資料を読むと疲れるのだと思います。

今は、人間が手でプログラムを書いていた時代から、AIが書く時代への転換期です。 そのため、これまで必要だった具体的な情報と、これから人間が判断したい情報が、まだ同じ資料の中に混ざっているのかもしれません。

いずれAIが書くコードへ完全に切り替わっていけば、短時間で生成される膨大なコードを、人間が詳細まで目でレビューすることは難しくなると思います。 だからこそ、人間が意思決定するために読む自然言語の文章は、これまで以上に重要になると感じています。

最後に

今回は、LLMが生成する文章を読むとなぜ疲れるのかについて考えてみました。

調査結果が難しいことや情報量が多いことだけが原因ではありません。 人間が判断したい抽象的な概念と、方針が決まった後に必要となる具体的な情報が、一つの資料に混ざっていることが大きな原因だと感じています。

人間とAIの関心が分かれていく中で、その間をつなぐドキュメントの重要性は高まっていきます。 今感じている課題がドキュメンテーションにあるのなら、抽象度のギャップを埋める対策や、LLMの周辺環境を整えることへ投資するのが、今のフェーズなのだと思います。