AIエージェント開発の次なる潮流：ループからグラフ、そして判定工学へ

エンジニアの現場において、技術トレンドの移り変わりは時に残酷なほど速い。2026年6月7日、Peter Steinberger氏が提唱した「ループエンジニアリング」という概念は、瞬く間に650万ビューを記録し、Addy Osmani氏によって体系化されるなど、AIエージェント開発のデファクトスタンダードになりつつあった。しかし、わずか1ヶ月後の7月18日、Steinberger氏は「まだループの話をしているのか？もうグラフにシフトしたか？」と問いかけ、再びコミュニティをざわつかせている。この速度感に、我々エンジニアは疲弊するのではなく、むしろこの「抽象化の連鎖」の本質を見極める必要がある。

多くの開発者が陥りやすい罠は、この「グラフ」という言葉を単一の概念として捉えてしまうことだ。実際に複数のAIツールを用いて検証した結果、この言葉は文脈によって全く異なる二つのレイヤーを指していることが判明した。一つは、LangGraphやMicrosoft Agent Frameworkに代表される「オーケストレーショングラフ」であり、これはエージェントの実行順序や条件分岐を制御するフロー設計を指す。もう一つは、GraphRAGなどで用いられる「コンテキストグラフ」であり、エンティティ間の関係性を構造化してLLMに渡す情報設計を指す。これらはレイヤーが全く異なるにもかかわらず、同じ「グラフ」という言葉で語られている。この混同こそが、現場の混乱を招くスパゲッティコードならぬ「スパゲッティ議論」の元凶であると私は考える。

グラフ理論において、ループ（閉路）はグラフの特殊なケースに過ぎない。つまり、グラフへの移行は単なる上位互換への進化であり、Prompt、Context、Harness、Loopと積み上げてきたエンジニアリングの系譜の上に、新たな制御層が乗ったに過ぎない。しかし、ここで立ち止まって考えたい。配線をどれだけ複雑に、どれだけ緻密に設計したところで、その配線の上を流れる「判断」の質が低ければ、それは単に「間違った方向に高速で突き進む装置」を構築しているに過ぎないのではないか。複雑なグラフ構造は、デバッグの難易度を指数関数的に引き上げる。深夜の障害対応で、複雑に絡み合ったエージェントのグラフを追いかける悪夢を想像してほしい。我々が今直面しているのは、配線の複雑化ではなく、その交差点における「判定精度」の欠如という、より根源的な課題である。

これまでのAIエンジニアリングの歴史を振り返ると、Prompt Engineering（何を言うか）、Context Engineering（何を見せるか）、Harness Engineering（どんな環境を用意するか）、Loop Engineering（いつ繰り返すか）、そしてGraph Engineering（どうつなぐか）と、すべてが「構造」の設計に終始してきた。しかし、グラフの各エッジやノードで「進むか、戻るか、止まるか」を決定する判定関数そのものの精度については、これまであまりにも無防備だった。私はこれを仮に「Judgment Engineering（判定エンジニアリング）」と呼びたい。これはAIエージェントが自律的に大量の判断を下す現代において、最も重要かつ未開拓な領域である。

判定関数の精度を担保するために必要なのは、グラフの形状ではない。それは「自己改善ループ」と「メモリ」の二点に集約される。具体的には、Evaluatorが下した判定をさらに上位のモデルが評価し直す「評価の評価」という再帰的な仕組みと、過去にどこで誤判定が発生したかを蓄積するログの活用だ。これはソフトウェア工学におけるテストコードや型定義、レビュー基準のドキュメント化という、我々が長年培ってきた「良い設計・良い検証」の営みを、AIエージェントの文脈で再定義したものに他ならない。AI特有の魔法のような技術ではなく、極めて泥臭い「判断の記録と改善」の積み重ねこそが、エージェントの品質を決定づける。

以下の表は、現在のエンジニアリングの系譜と、私が提唱する「判定エンジニアリング」の立ち位置を整理したものである。

この判定エンジニアリングを実践するために、私はGitHub Copilotを用いた開発フローの中に「判定ログ（review-mistakes.md）」を導入することを提案する。単にサブエージェントに検証を任せるのではなく、その検証結果が「承認」か「差し戻し」か、そしてそれが「正しかったか」を記録し、次回のプロンプトにフィードバックする。この「記憶を持つ検証役」こそが、複雑なグラフ構造を制御するための唯一の処方箋となるだろう。我々は、AIにコードを書かせることだけに熱中しすぎていないか？AIが下した判断を検証し、その誤りを学習させるという、エンジニアとしての本来の責務を忘れてはいないだろうか。

「ループの次はグラフ」という物語は、一見すると技術の進化のように見えるが、実は一周回って「良い設計とは何か」という古典的な問いに戻ってきている。AIエージェントが複雑なグラフ構造を持つようになった今、我々が明日から取り組むべきは、新しいフレームワークの習得ではない。むしろ、AIが下した判断の「根拠」を可視化し、その「誤り」を資産として蓄積する仕組みの構築である。もしあなたが現在、LangGraph等を用いて複雑なエージェントフローを構築しているなら、一度立ち止まってほしい。そのグラフの各ノードで、AIはどのような基準で判断を下しているのか？その判断基準は、過去の失敗から学習されているか？

具体的な対策として、まずは「検証役のサブエージェント」を独立させ、その判断ログを構造化データとして残すことから始めてほしい。例えば、nullチェック漏れを見逃したという過去の事象を、単なるバグ報告として終わらせるのではなく、判定ゲートの「学習データ」としてプロンプトに組み込む。この小さな積み重ねが、数ヶ月後のエージェントの品質を劇的に変えるはずだ。AIエージェントの時代において、エンジニアの価値は「コードを書くこと」から「AIの判断基準を設計し、それを改善し続けること」へとシフトしている。あなたは、AIが下す判断の「品質」に対して、どれだけの責任を負う覚悟があるだろうか？

最後に、読者であるあなたに問いかけたい。グラフという複雑な配線図を描くことに満足し、その交差点でAIが下す判断の「不確実性」から目を背けてはいないだろうか。技術の流行を追うことは重要だが、その裏側にある「検証のボトルネック」を解決しない限り、我々が構築するシステムは、いつか必ず制御不能なデッドロックに陥る。AIエージェントの時代における真のシニアエンジニアとは、AIを動かす者ではなく、AIの判断を律する「判定の設計者」であるべきではないか。明日、あなたが書くコードの検証プロセスに、AIの判断を記録する「ログ」を一行追加することから、この新しいエンジニアリングを始めてみてほしい。