AIエージェントで「全部自動化」できるという話の何が間違っているか

LangChainやLlamaIndexを組み合わせれば、AIが生成したコードの監査から修復まで自動で回せる。そういう話を聞いたことがある人は多いはずだ。

元ITアーキテクトのpapa_story2010氏がQiitaに連載している「AI駆動開発の実態」シリーズの第5章が、その前提をかなり根本から崩している。単なる「AIへの過信への警告」ではなく、なぜ自動化が技術的な構造として破綻するのかを具体的に論じている点で、読む価値がある。

要点を先に言う。AIエージェントによる自動ループが機能しない理由は3層ある。「監査ロジック自体が確率論」「履歴クリアが無限往復ループを生む」「ライブラリとインフラがコンテキストを密輸する」。それぞれに独立した技術的な根拠があり、どれか一つを潰しても残りが牙を剥く。

罠1：監査エージェントも確率論で動いている

著者が最初に指摘するのは、「ハルシネーションの自動再生産ループ」という問題だ。

LangChainで監査エージェントと修復エージェントをループさせるシステムを組もうとすると、「崩壊の兆候を検出するトリガー」自体を別のLLMに委ねることになる。つまり、確率論（修復AI）を確率論（監査AI）で評価するという構造が生まれる。

監査側のAIも確率論で動いている以上、「コードは間違っているが、論理的にもっともらしく見える嘘」を受け取った瞬間、監査AIは「このコードは完璧です」と誤判定を下す可能性がある。そうなると自動化システムは、バグを含んだコードを正しいものとして仕様YAML側に逆流させ、仕様そのものを自動で汚染していく。

著者の言葉を借りれば、「確率論同士の共食いループを止めるロジックはPythonでは書けない」。これは煽り表現ではなく、構造的な事実として理解した方がいい。

人間が手作業でやっているのは単なるリセットではない。「別AIが出した不整合チェックYAMLを見て、次の打席はYAMLのこの論理構造をこう具体化して修正させれば収束するな」という、決定論に基づく判断を挟んでいる。この「どう仕様を具体化してAIを誘導するか」というメタな舵取りが、コードで書けない部分の核心だ。

罠2：履歴クリアが「記憶喪失による無限往復ループ」を生む

一見すると、これを回避する方法がある。「毎回APIコール時に履歴を完全にクリアして、仕様YAMLとエラーのセットだけを送り直す」という手法だ。著者自身もこれが「履歴汚染という問題だけは完全に回避できる」と認めている。

ところが、この方法には別の致命傷がある。

AIは過去に自分が何をして、どう失敗したかを完全に忘れる。1回目でYAMLとエラーを投げてAIが修正コードを出し、2回目でその修正コードがまた別のエラーを出したとする。人間なら「さっきの修正ではダメだったから別の観点が必要だ」と判断できるが、履歴をクリアされたAIには、それが1回目の失敗コードなのか人間が書いたコードなのか、まったく区別がつかない。

結果として何が起きるか。AIは記憶がないので、確率論上の1番手（最も頻出のコードパターン）をフラットに出し続ける。自動化システムは「1回目の修正コード」と「2回目の修正コード」の間を行き来するだけの、「記憶喪失による無限オルタネートループ」に突入する。

これは設計ミスではない。構造上、避けられない帰結だ。

罠3：ライブラリとインフラが勝手にコンテキストを「密輸」する

仮にループの問題を気合で解決したとしても、さらに2つの壁がある。

ひとつは、LangChainやLlamaIndexといったフレームワーク自体の挙動だ。これらは「エンジニアが細かいメモリ管理をしなくても、エージェントが賢く動く」ことを目的に設計されている。そのため、表面上のコードで history.clear() を呼んだとしても、エージェントの内部状態（Agent State）や、裏で動いているコンテキスト管理クラスが、「前回の実行結果のサマリー」や「直前のツール実行のログ」をAPIリクエストのシステムプロンプトやメタデータ領域に勝手に「密輸（インプラント）」して送り続ける仕様になっている。

これを潰すには、ライブラリの裏のソースコードを全部読んで、勝手な挙動をすべて力技でオーバーライドするしかない。

もうひとつは、インフラ側の問題だ。Google AI Studioをはじめとする現代のAPIは、数百万トークン規模の入力コストを抑えるため、「入力プロンプトの大部分が同一であれば、サーバー側でその解析結果（KVキャッシュ）を自動的に使い回す」最適化が走る。これは一見便利だが、AIの推論サーバーのメモリに「前回の推論の残響（重みのバイアス）」が物理的に残るリスクを意味する。

ブラウザで「New Chat」を押して完全に別セッションを立ち上げるという行為は、このサーバー側のKVキャッシュの紐付けを物理的に引き剥がすための操作として機能している。Pythonのラッパー数行でこのインフラ層の「メモリ汚染のパージ」を完璧に制御することは、構造的に不可能だ。

ここからは見方の話：この構造が示すAI開発の本質的な問題

この記事が言っていることは、技術的な細部を超えて、もう少し大きな問題を示している。

現在のAIエージェント開発の多くは、「確率論の出力を確率論で評価する」という多段構造で成り立っている。各レイヤーで精度が高くなっても、それは「90%正しい判断を90%正しく評価する」という確率の積になる。レイヤーが増えれば増えるほど、全体の信頼性は下がる方向に動く。

ここが自動化の本質的な限界だ。「AIが出す答えを人間がジャッジする」という構造では、人間が決定論的なアンカーとして機能している。そのアンカーを別のAIに置き換えた瞬間、確率論の海に漂うだけになる。

AIエージェントの自律性が高まれば解決する、という話でもない。自律性が高まるとは、より複雑な確率論的判断を内部で行うことを意味する。仕様の汚染や無限ループを「賢く回避する」かもしれないが、それ自体が新たなハルシネーションの温床になりうる。

実務的な示唆：自動化できる範囲を引き直す

では、何も自動化するなという話か。そうではない。

ここで整理しておきたいのは、「自動化が効く作業」と「効かない作業」の境界線だ。

コードの実行・テスト・エラーログの収集・YAMLへの出力整形といった「決定論的に正否が判定できる作業」は、自動化に向いている。一方、「AIの出力が正しいかどうかの判断」「仕様の構造をどう組み直すかの判断」「収束しないループを検出してメタな介入を決める判断」は、今のLLMベースのエージェントには任せられない。

実務として取るべきスタンスはシンプルだ。自動化ループの出口に、必ず人間が判断を挟む設計にする。ループの内側を自動化することと、ループの終了条件を人間が決めることは、矛盾しない。その境界をどこに引くかが、AI駆動開発の設計の核心になる。

次に来る論点はおそらく2つだ。ひとつは「監査機能のLLM非依存化」、つまりルールベースや形式検証ツールを使って、判定ロジックを確率論から切り離せるかどうか。もうひとつは「責任の所在」で、ハルシネーションループが仕様を汚染した場合、誰がそれを検知し、誰が差し戻す義務を負うのかという組織設計の問題だ。技術が成熟するほど、この後者が前者を追い越してくる。

LangChainの話だけど、本当はAI開発の体制設計の話だ。そこまで読めると、この種の記事から得られるものが変わってくる。

参考元: 第5章：AI駆動開発における自動化の欺瞞：LangChainやAPIエージェントがハルシネーションループで破綻する理由