Chapter 15

第15章: エージェントの限界 ─ hallucination・context rot・計画破綻

社内の Slack に、こんな質問が投げ込まれる。

「Claude Code、ここまで自分で計画して、自分で書いて、別エージェントにレビューもさせてるのに、なんでまだ人間が要るんですか？」

良い質問だ。本書はここまで 14 章をかけて、ループ・道具・context・サブエージェント・hooks・MCP・スキル・自己改善 ── エージェントが “動く” 仕組みを階段で上ってきた。 これだけ良くできている存在に、なぜ私たちはまだ毎日 画面を覗き込まないといけない のか。

答えは、エージェントが超えられない 五つの壁 がいまも残っているからだ。 この章で、その壁を一枚の地図に置く。これが第Ⅰ部の最後の仕事になる。

15.1 そもそも、なぜ「限界」を地図にする必要があるのか

エージェントの便利さに馴れると、ありがちな誤解が二つ生まれる。

ひとつは 「もう少し賢いモデルが出れば全部解決する」 という楽観。 もうひとつは 「結局信用できないから使わない」 という諦め。

どちらも雑だ。 現代エージェントの限界は、LLM が賢くなれば消える ものと、構造上どう転んでも残る ものに分かれる。 両者を混ぜたまま議論すると、過剰な期待か過剰な不信のどちらかに転がる。

限界には モデル性能で押し切れる類 と、続きを書く機械という構造に由来する類 がある。 後者は LLM が何倍賢くなっても残る。だから 設計判断で囲い込む ことが永遠に必要になる。

以下、五つの限界を順に並べる。 それぞれが「本書のどの章で見た道具で囲うのか」も同時に示していく。

15.2 限界 1: hallucination (幻覚) ── 存在しないものを自信満々に書く

最も有名な限界がこれだ。

hallucination (幻覚)

LLM が、存在しない API・実在しない関数名・事実と異なる仕様 を、もっともらしい文体で出力する現象。 日本語では「幻覚」と訳される。エージェント時代の最大の足かせのひとつ。

具体的にはこんな形で現れる。

なぜ起きるのか。 本書で繰り返し見てきた通り、LLM は学習データに含まれる 「ある関数がこの形で呼ばれそう」というパターン に引っ張られて、実在を確認せずに それらしい続き を生成してしまう。 これは知識不足というより、生成モデルの構造上の宿命 に近い。

囲い込みの道具は、本書ですでに揃っている。

幻覚は ゼロにはできない が、囲いを重ねれば現場に出てくる確率を大幅に下げられる。

15.3 限界 2: context rot ── 長文脈で精度が落ちる

二つ目の限界は、第4章の context window と直結する。

context rot

context (会話履歴) が長くなるほど、モデルが 中盤の情報を取りこぼし、当初の指示から逸れていく 現象。 「context が腐る」という直訳どおりの俗称で広く使われる。

研究の世界では、Liu らが 2023 年に発表した “Lost in the Middle: How Language Models Use Long Contexts” (Liu et al., 2023) として整理された現象が有名だ。 context の 先頭と末尾 にある情報には強く反応するが、真ん中 に置かれた情報を見落としやすい、という偏りが LLM には組み込まれている。

(第4章の context rot の節で触れた「文脈が長いほど中盤が抜ける」という現象を、論文の言葉で言い直すとこの Lost in the Middle になる。)

実際の現場では、こんな形で痛みが出る。

囲い込みの道具:

context rot は、モデルが賢くなっても 完全には消えない。 人間が長い会議で疲れて要点を見失うのと、同じ構造の問題が LLM にもある、と思っておくほうが安全だ。

15.4 限界 3: 計画破綻 ── 長い計画ほど途中で逸れる

三つ目は、エージェント特有の限界だ。

タスクが大きくなると、エージェントは事前に手順を立てて進む。 ところがこの計画、長くなるほど途中で崩れていく。

計画破綻

エージェントが立てた多段の計画が、途中の予期せぬ結果 によって暗黙のうちに逸れていき、最終成果物が当初の意図と乖離する現象。 「修正」を加えるたびに、その修正自体がさらに逸れていくこともある。

なぜ起きるのか。 context rot (限界 2) と組み合わさるのが厄介だ。 計画はだいたい context の前半に書かれる。タスクが進むうちに、その計画は 真ん中に押しやられ、後半の作業に意識が引っ張られていく。 気づくと、最初に決めた「設計の方針」を 忘れたまま 細部を直し続けている。

囲い込みの道具:

ここでも 「LLM が賢くなれば消える」 とは言えない。 1 万トークンの計画を完璧に追従させるのは、文字数の多い人間の議事録を一字一句守らせるのと同じくらい難しい。

15.5 限界 4: ループの停止判断 ── いつ止まればいいか分からない

第1章の最後で残した宿題が、これだ。 ループは「LLM が道具を呼ばない出力を返した瞬間に止まる」── では、その判断はいつ正しいのか？

ここに二つの典型的な失敗がある。

どちらも、LLM が 「自分の仕事が終わったか」を自分で判断する という構造の難しさから来る。 人間でさえ「もう十分だ」「あと一手必要だ」の線引きは難しいのに、LLM にそれを完全に任せるのは無理がある。

囲い込みの道具:

これが本書のはじめの「なぜ人間が画面を覗き込むのか」への、最も直接的な答えになる。 「終わって良いか」の最終決裁 は、当面の間、人間が握り続けることになるだろう。

15.6 限界 5: 透明性の喪失 ── 中で何が起きたか分からない

最後の限界は、エージェントが 賢くなるほど深刻になる タイプの問題だ。

サブエージェントを起動し、その中でさらに hooks が走り、MCP 経由で外部ツールが呼ばれ、tmux の別ペインで並列タスクが進む ── ここまで複雑になると、親エージェントが「OK でした」と報告してきたとき、その奥で何が起きたかを再現できる人は誰もいない。

重ね合わせのループ (第14章) は、評価の独立性をもたらすと同時に、観測可能性 (observability) を奪っていく。 ループが深くなるほど、「なぜそうなったか」を追跡するためのログ・履歴・痕跡が散逸する。

これに対する道具は、まだ進化の途中だ。

第Ⅱ部で扱う /cost や /export のようなコマンド群は、この 観測可能性 の問題に対する素朴な道具立てだ。 派手ではないが、エージェント時代の運用で生命線になるコマンドたちでもある。

15.7 限界の地図 ── 本書のどの章で囲うか

ここまでの五つを、本書の章構成にマップする。

5 つの限界囲い込む道具 (本書の章)① hallucination (幻覚)存在しない API・誤った仕様を堂々と出す② context rot長文脈で中盤を取りこぼす (Lost in the Middle)③ 計画破綻長い計画が途中で逸れ、修正がさらに逸れる④ 停止判断早すぎる終了 / 無限ループ⑤ 透明性の喪失サブエージェント・hooks の中が見えない道具で実物確認 (2-3)MCP/RAG (12) · hooks (11) · Eval (14)context (4) · memory (8)sub-agent (9) · self-loop (14)Plan モード (7)Planner-Generator-Evaluator (14)Evaluator (14) · hooks (11)permissions (10) · 人間の最終判断hooks ログ (11) · worktree 分離/cost · /export (第Ⅱ部)
図 15.1 — 5 つの限界と、それぞれを囲い込むために本書のどの章を使うか。点線は「完全には消えないが、緩和できる」関係を表す。

5 本の矢印を見て気づくのは、どの限界も、本書のどこか 1 章だけでは囲い込めない ということだ。 複数の道具を 組み合わせて初めて緩和される ── これがエージェント設計の核心であり、本書を 15 章に分けた理由でもある。

15.8 設計判断が永遠に重要な理由

ここまで来ると、最初の「なぜ人間が要るのか」の答えが、少し違う輪郭で見えてくる。

人間が要るのは、エージェントが 馬鹿だから ではない。 ここまで賢くなっても、五つの限界の どれもゼロにはならない からだ。 ゼロにならない以上、誰かが 囲いをどう設計するか を考え続ける必要がある。

LLM が何倍賢くなろうと、続きを書く機械という構造は変わらない。 構造が変わらない以上、幻覚・context 劣化・計画逸脱・停止判断・観測可能性 の問題は形を変えて残り続ける。 だから 設計判断 ── どの道具をどう組み合わせ、どこに人間を置くか ── は、永遠にエンジニアの仕事として残る。

これは悲観的な結論ではない。むしろ、エージェントが普及した先の世界でも、「設計を考える人」の仕事はむしろ増える ことを意味している。 コードを 1 行ずつ書く役割は減るかもしれないが、ループをどう重ねるか・hooks に何を仕込むか・permissions をどう絞るか を判断する役割は、消えるどころか中心に来る。

本書を書きながら、私が何度も戻ってきた感覚はこれだ。 「コーディングエージェントが賢くなる」のと、「人間の仕事がなくなる」のは、まったく別の話だ。

賢くなったエージェントは、人間に “より上のレイヤーの設計判断” を要求するようになる。 どの道具を渡すか、どんな context を作るか、いつ止めるか、誰に評価させるか ── 全部、人間が決めるしかない領域だ。

第Ⅱ部で扱う公式コマンドは、結局のところ この設計判断のための語彙 に他ならない。 /init も /compact も /hooks も /permissions も、「エージェントの周りをどう囲うか」を語るための道具 だ。 だから次のページから、それらを一つひとつ、「そもそも何を囲うコマンドか」から見ていく。

15.9 この章の振り返り

第Ⅰ部のまとめ ── ここまでの 15 章で得たもの

本書の第Ⅰ部は、こんな階段を上ってきた。

段章得たもの
原理編1-3LLM・道具・ループという三役 / function calling / think → act → observe
構造編4-6context window / プロンプトの構造 / 道具設計の作法
制御編7-11Plan モード / memory / sub-agent / permissions / hooks
拡張編12-13MCP / Skills
応用編14-15マルチエージェントと自己改善 / 限界

ここまでで、Claude Code 界隈で飛び交う 「context rot」「サブエージェントで並列」「MCP 経由」「hooks で型止め」「Planner-Generator-Evaluator」 といった会話は、ひとつの地図の上に置けるようになったはずだ。

序章で書いた「Claude Code 界隈の会話・ブログ・X ポストが、構造として読める」という第Ⅰ部のゴールは、ここで達成されたことになる。

この章で読めるようになるツイート / ブログ

第Ⅱ部への橋

これで第Ⅰ部は終わり。次のページから始まる第Ⅱ部は、公式コマンドを 1 つ = 1 章 で逐次解説するリファレンスパートになる。

ただし、第Ⅱ部は単なるコマンド辞書ではない。 本書を通じて伝えたいのは、各コマンドが 第Ⅰ部のどの設計判断の現れか を読めるようになることだ。

辞書として引きに来ても、通読しても、どちらでも腹落ちする ── そういう書き方で第Ⅱ部を組んだ。 ようやく地図を手にした読者として、コマンド世界の旅へ出かけよう。