第1章 AI業界は、また新しい言葉を発明した
AI業界には、新しい言葉が次々と生まれる。
Prompt Engineering、Context Engineering、Agent Engineering。
そして最近では、Loop EngineeringやGraph Engineeringという言葉まで聞かれるようになった。
いかにも大層である。
Loop Engineering。
何やらAI Agentを高度に自律化する、最先端の設計思想のように聞こえる。
Graph Engineeringとなれば、さらに強そうだ。
複数のAI Agentが協調し、複雑なタスクを分解し、状況に応じて動的に処理経路を変えながら仕事を遂行する。
そんな未来的なシステムを想像するかもしれない。
しかし、ITエンジニアなら少し妙な感覚を覚えるはずだ。
Loop？
処理して、結果を確認して、条件を満たさなければもう一度処理する。
それは昔からある。
Graph？
処理をノードとして配置し、条件によって次の処理へ進み、ときには前の処理へ戻る。
それも昔からある。
Workflow、状態機械、DAG、制御フロー、Retry、Feedback Loop。
名前こそ違えど、コンピュータの世界では何十年も使われてきた考え方だ。
極端に言ってしまえば、
Loop Engineeringの向こう側にはwhile文が見える。
Graph Engineeringの向こう側には、昔ながらのWorkflowや状態遷移図が見える。
「またAI業界が昔からある技術に新しい名前を付けたのか」
そう思うのも無理はない。
実際、AI業界にはそういうところがある。
既存の技術や概念がLLMと結びついた瞬間、新しい名前が与えられ、巨大な市場が生まれ、カンファレンスの題目になり、投資家向け資料を飾る。
名前だけを眺めていると、コンピュータ科学が毎月革命を起こしているように見えてしまう。
だが、今回については、そこで笑って終わるには少し早い。
LoopもGraphも古い。
その基本構造に、革命的な新しさがあるわけではない。
新しくなったのは、その中を流れるものだ。
従来のプログラムでは、プログラマーが処理を書き、条件を書き、次に何をするかを決めていた。
入力が同じなら、基本的には同じ処理経路を通る。
ところが、その途中にLLMを置くと事情が変わる。
LLMは単なる関数ではない。
同じ指示を与えても違う答えを出す。
間違える。
勝手に別の方法を考える。
Toolを呼ぶ。
途中で方針を変える。
うまくいかなければ修正し、ときには自分がなぜ失敗したのかまで考える。
つまり私たちは今、
「次に何をするかを自分で考える部品」
をWorkflowの中へ放り込み始めた。
ここで、古びていたはずのLoopとGraphが突然重要になる。
自由に考えるAI Agentを作れば、それですべて解決する。
一時期、そんな未来も語られた。
しかし実際にAgentへ仕事をさせてみると、人間はすぐに別のことを言い始める。
失敗したらもう一度やれ。
結果を確認してから次へ進め。
同じ失敗を繰り返すな。
このToolだけを使え。
途中の状態を保存しろ。
重要な判断は人間に確認しろ。
何度やってもダメなら諦めろ。
――ずいぶん見覚えのある世界になってきた。
AI Agentが進化した結果、私たちは再び制御について考え始めたのである。
だからLoop EngineeringとGraph Engineeringは、まったく新しい計算機科学ではない。
むしろ逆だ。
LLMという、とんでもなく便利だが、とんでもなく予測しにくい部品が登場したために、古典的な制御の知恵をもう一度引っ張り出してきた。
そう考えた方が、その正体はずっと分かりやすい。
では、その大層な名前の皮を一枚ずつ剥いでみよう。
まずはLoop Engineeringから。
その奥に本当にあるのは、最新のAI技術なのか。
それとも、ただのwhile文なのだろうか。
第2章 Loop Engineering──皮を剥けばwhile文なのか
Loop Engineering。
名前だけ聞けば、何か新しいAI開発手法のように思える。
だが、まずは思い切って単純化してみよう。
AI Agentに仕事をさせる。
結果を見る。
うまくいっていなければ、もう一度やらせる。
成功するまで繰り返す。
これがLoop Engineeringの基本だとすれば、プログラマーならこう思うはずだ。
それ、ループでは？
たとえば、こんな処理である。
仕事を実行する
↓
結果を確認する
↓
成功した？
├─ Yes → 終了
└─ No → 修正してもう一度
↑
└─────
何も新しくない。
通信に失敗すればRetryする。
テストに失敗すればコードを修正して再実行する。
一定条件を満たすまで処理を繰り返す。
コンピュータが誕生して以来、散々やってきたことだ。
だから、
「Loop Engineeringとは、while文に立派な名前を付けただけではないのか」
という疑いは、半分くらい正しい。
しかし、残り半分が面白い。
ループの中に「判断するもの」が入った
従来のプログラムでループを作る場合、プログラマーはかなり多くのことを事前に決めていた。
何を実行するか。
成功とは何か。
失敗したらどうするか。
何回繰り返すか。
どんな条件になったら終了するか。
つまり、ループを回る処理は変化しても、ループそのものの論理は人間が書いていた。
ところがLLM Agentでは事情が違う。
たとえば、AIにこう頼んだとする。
「このプログラムのバグを直して」
Agentはコードを読む。
原因を推測する。
コードを書き換える。
テストを実行する。
エラーを見る。
そして、
「さっきの仮説は間違っていたようだ」
と判断する。
別のファイルを調べるかもしれない。
違う修正方法を試すかもしれない。
追加のログを仕込むかもしれない。
つまり、
生成
↓
実行
↓
観測
↓
評価
↓
修正
↓
再実行
というループの中で、次に何をするかまでLLMが考えている。
ここが従来の単純なループとは大きく違う。
「もう一度やれ」だけではAIは賢くならない
さらに厄介な問題がある。
LLMに同じ仕事を何度もやらせれば、いつか正解へ到達するとは限らない。
むしろ現実には、
同じ修正を何度も繰り返す。
直した場所を再び壊す。
エラーメッセージを読み違える。
最初に立てた間違った仮説へ何度も戻る。
大量のログやコードをContextへ詰め込み、最後には何をしていたのか分からなくなる。
そんなことが普通に起きる。
人間から見れば、
「そこ、さっき試してダメだっただろ」
である。
ここで初めて「Engineering」という言葉が効いてくる。
重要なのは、ループを作ることではない。
良いループを作ることだ。
何を観測させるのか。
前回の失敗から何を残すのか。
成功を誰が判定するのか。
同じ方法を繰り返していないか、どう検出するのか。
何回失敗したら別の戦略へ切り替えるのか。
Contextが膨らんだら、何を捨て、何を保存するのか。
いつ人間へ助けを求めるのか。
そして、いつ諦めるのか。
こうなると、単なるwhile文では済まなくなってくる。
AI Agentの性能は「何回考えたか」では決まらない
ここには、AI Agentを考えるうえで重要なポイントがある。
優秀なモデルを使えば、最初の一発で正解する確率は上がる。
それは間違いない。
しかし現実の仕事は、一発で終わるものばかりではない。
コードを書けばテストする。
調査すれば不足している情報が見つかる。
Webを操作すれば予想外の画面が現れる。
ファイルを編集すれば整合性を確認する。
長い仕事ほど、途中で必ず何かが起きる。
そこで必要なのは、
一発で正解する知能だけではなく、失敗したあと正しい方向へ戻れる能力である。
たとえば、一発の成功率がそれほど高くないモデルでも、
失敗を正しく観測し、
原因を切り分け、
過去の失敗を覚え、
別の方法を試し、
結果を検証できるなら、
何周かしたあとには仕事を完成させられる可能性がある。
逆に、どれほど賢いモデルでも、失敗するたびに同じ場所へ戻るなら仕事は終わらない。
つまりAgentic AIでは、
モデルの知能 × ループの質
で、実際の仕事能力を見る必要が出てくる。
これは、ベンチマークで測る「一問一答の賢さ」とは少し違う世界だ。
粘るAIは、賢いAIとは限らない
実際、Agentを使っていると奇妙な経験をする。
決して最高性能とは言えないモデルが、何度も失敗しながらログを読み、コードを書き換え、テストし、また失敗し、それでも延々と問題へ食らいつく。
一方で、はるかに賢いモデルが一度Tool Callに失敗しただけで、そのまま仕事を止めてしまうこともある。
どちらが「仕事のできるAI」なのだろう。
少なくとも、モデル単体の知能だけでは答えられない。
Agentの世界では、
失敗できることそのものが能力になる。
正確には、
失敗しても、そこから情報を得て次の試行へ進める仕組みを持つことが能力になる。
Loop Engineeringという大層な名前の中身を突き詰めると、ここへ辿り着く。
ループという構造は古い。
Retryも古い。
Feedbackも古い。
Test and Fixなど、プログラマーが毎日やっている。
新しいのは、それらを発明したことではない。
これまで人間がループの外側で行っていた「観測し、考え、修正し、もう一度試す」という仕事の一部を、LLMがループの内側で行えるようになったことだ。
だから、Loop Engineeringを「while文の再発明」と笑うことはできる。
実際、かなりwhile文である。
だが、そのwhile文の中に、
考える奴が入ってしまった。
そこから話がややこしくなったのである。
第3章 Graph Engineering──Workflowは死んでいなかった
Loop Engineeringの皮を剥いだら、while文が出てきた。
では、Graph Engineeringはどうだろう。
こちらも名前は強そうだ。
複数のAgentを配置し、それぞれに役割を与える。
あるAgentが調査し、別のAgentが実装し、さらに別のAgentが検証する。
結果によって処理経路を変え、必要なら前の工程へ戻る。
複雑な仕事をGraphとして設計し、AI Agentたちに遂行させる。
いかにも次世代のAIシステムである。
だが、これもITエンジニアなら既視感を覚える。
入力
↓
処理A
↓
判定
├─ 条件A → 処理B → 出力
│
└─ 条件B → 処理C
↓
再判定
↓
処理Aへ戻る
Workflowでは？
そう。
かなりWorkflowである。
コンピュータは昔からGraphで動いている
そもそも、処理をノードとして表し、その関係をエッジで結ぶという考え方自体が新しくない。
コンパイラにはControl Flow Graphがある。
業務システムにはWorkflowがある。
データ処理にはDAGがある。
状態を扱うならState Machineがある。
分散システムなら、複数のWorkerへ仕事を振り分ける。
ある処理が終わったら次を実行する。
条件によって処理を分岐する。
失敗したら前の工程へ戻す。
一定回数失敗したら別の処理へ送る。
人間の承認が必要なら、そこで止める。
全部、昔からある。
企業の業務システムなど、何十年もこれをやってきた。
申請する。
上司が承認する。
金額によって部長決裁へ回す。
却下されたら申請者へ戻す。
承認されたら経理へ送る。
Graph Engineeringという名前を知らなくても、人類はとっくにGraphをEngineeringしていたのである。
では、なぜ今さらGraph Engineeringなのか。
Agentの夢は「Workflowをなくすこと」だった
LLM Agentが登場した当初、その魅力のひとつは、こうした細かなWorkflowを書かなくてもよくなることだった。
従来なら、
「まず検索する」
「次に情報を整理する」
「条件Aならこの処理をする」
「失敗したら別のAPIを呼ぶ」
と人間が逐一プログラムしなければならなかった。
しかし、十分に賢いAIへ目標だけ渡せば、
何をすべきかはAI自身が考えてくれる。
そんな期待が生まれた。
たとえば、
「このバグを直して」
それだけでいい。
AIがリポジトリを調べ、必要なファイルを見つけ、コードを読み、修正し、テストし、完成させる。
人間がWorkflowを書く必要はない。
極端に言えば、
Task
↓
Agent
↓
Done
これで済む。
夢のような話だ。
そして実際、現在の高性能なCoding Agentは、かなりのところまでこれを実現している。
ところが、仕事が複雑になるにつれて問題が起きた。
Agentが迷子になるのである。
自由を与えたら、制御が必要になった
「このバグを直して」
Agentはコードを読む。
検索する。
別のファイルを読む。
修正する。
テストする。
失敗する。
別の場所を修正する。
さらに失敗する。
最初の修正へ戻る。
Contextが膨らむ。
最初に何を調べたのか曖昧になる。
関係の薄いファイルまで読み始める。
そして人間は思う。
「一度、整理しようか」
そこで仕事を分割する。
まず原因を調査させよう。
調査結果を保存しよう。
その結果を使って別のAgentに修正させよう。
修正後はテスト専用の工程へ送ろう。
失敗したら実装Agentへ戻そう。
同じ失敗が続いたら、別の方法を検討させよう。
重要な変更なら、人間の承認を挟もう。
すると、
┌→ 調査Agent ───┐
Task → 分解 ─┤ ↓
└→ 別調査Agent → 統合
↓
実装Agent
↓
Test/Eval
↙ ↘
修正 完了
↑
└─────────
となる。
見事なGraphが完成した。
WorkflowをなくすためにAgentを作ったら、Agentをちゃんと働かせるためにWorkflowが戻ってきた。
AI史には、なかなか味わい深い展開である。
ただし、昔のWorkflowとは少し違う
ここでも「昔からあった」で終わらせると、本質を見落とす。
従来のWorkflowでは、基本的に人間がGraphを書いていた。
この条件ならAへ進む。
この条件ならBへ進む。
失敗したらCへ戻る。
どのノードを通るかは、あらかじめ定義された条件によって決まる。
ところがAI Agentでは、ノードそのものが判断する。
「この問題は、先にログを調べるべきだ」
「これは自分で直すより、別のAgentへ調査を依頼した方がいい」
「テスト結果を見る限り、実装ではなく設計の問題らしい」
「この方法を続けても解決しそうにない。別の戦略へ切り替えよう」
こうした判断をLLMが行う。
つまりGraphは存在するが、
そのGraphをどう進むかの一部を、AI自身が決める。
さらに進めば、仕事を受け取ったAgent自身が、
「これは三つに分割できる」
と判断し、
複数のSubagentへ仕事を振り、
結果を集め、
必要なら追加調査を行い、
最後に統合する。
ここまで来ると、Graphそのものさえ完全には固定されていない。
実行中にGraphが生まれる。
これが、昔ながらのWorkflowとの大きな違いである。
Graph Engineeringとは「自由と制御の境界」を設計すること
そう考えると、Graph Engineeringで本当に設計しているものが見えてくる。
Graphそのものではない。
そんなものは昔からある。
重要なのは、
どこまでAIに自由を与え、どこから人間がレールを敷くのか。
原因調査は自由にやらせる。
しかし、本番環境への変更は承認させる。
修正方法はAgentに考えさせる。
しかし、テストを通過しなければ次へ進ませない。
必要ならSubagentを使わせる。
しかし、無限にAgentを増殖させない。
一定範囲では自由にGraphを探索させる。
しかし、危険な領域へは進ませない。
これは従来のWorkflow設計とは少し違う。
人間がすべての経路を書くのではなく、
AIが判断できる余白そのものを設計する。
そこにEngineeringが生まれる。
そしてLoopとGraphはつながる
ここまで来ると、Loop EngineeringとGraph Engineeringが別々の話ではないことも分かる。
Graphの中にはLoopがある。
テストに失敗したら実装へ戻る。
調査が不足していたら検索へ戻る。
評価が低ければ生成し直す。
つまり、
Graphは仕事全体の構造を作り、Loopはその中で改善を回す。
昔からあるWorkflowとFeedback Loop。
それらがLLM Agentの世界で再び組み合わされている。
違うのは、そこに配置されたWorkerが、
単なるプログラムではなく、
考え、判断し、ときには勝手なことまで始めるWorkerになったことだ。
だからGraph Engineeringも、まったく新しい発明ではない。
Workflowの再発明と言ってしまって構わない。
ただし、今回はひとつ厄介なものが混ざっている。
Workflowの中を歩く奴が、自分で道を選べる。
そして場合によっては、
自分で道まで作り始める。
Graph Engineeringという大層な名前が必要になった理由は、案外そこにあるのかもしれない。
第4章 なぜ今さら「制御」が主役になったのか
ここまでの話だけなら、結論は簡単である。
Loop Engineeringはループの再発明。
Graph EngineeringはWorkflowの再発明。
AI業界が昔からある技術に新しい名前を付け、いかにも新しい概念であるかのように売り出している。
いつもの話だ。
――で終わってもいい。
だが、それでは説明できないことがある。
なぜ、今になってこれほど「Loop」と「Graph」が重要になったのか。
単なるマーケティング用語なら、一過性の流行で終わる。
ところが実際のAI Agent開発は、明らかにこの方向へ進んでいる。
モデルを賢くするだけではなく、
失敗したら再試行させる。
結果を別のモデルに評価させる。
仕事を分割する。
途中状態を保存する。
複数のAgentへ仕事を振る。
チェックポイントを作る。
人間の承認を挟む。
Contextが限界に近づけば要約して引き継ぐ。
つまり、AI Agentの周囲に大量の制御機構が作られ始めた。
理由は単純だ。
LLMが信用ならないからである。
「賢い」と「予測できる」は別の能力
これはLLMを理解するうえで、非常に重要な違いだ。
現在のLLMは驚くほど賢い。
コードを書ける。
文章を書ける。
画像を理解できる。
Webを検索できる。
複雑な問題を分解し、Toolを使い、長時間の仕事までこなせる。
しかし、
賢いからといって、予測できるわけではない。
ここが従来のソフトウェアと決定的に違う。
普通の関数なら、
入力
↓
処理
↓
出力がある。
もちろんバグはある。
外部APIが落ちることもある。
ネットワークが切れることもある。
それでも、少なくともプログラマーは「このコードは何をするために書かれているのか」を知っている。
LLMは違う。
入力
↓
LLM
↓
たぶん期待した出力である。
しかも問題は、単にランダムなだけではない。
それなりに筋の通った間違いをする。
存在しないAPIを使う。
エラーの原因をもっともらしく誤認する。
本来触る必要のないコードを修正する。
ユーザーの意図を少しだけ取り違え、そのまま何千トークンも突っ走る。
一見すると合理的なので、単純なエラーコードでは検出できない。
ここが厄介だ。
従来のエラー処理では足りない
従来のソフトウェアなら、
成功 → 次へ
失敗 → Retryで済む場面が多かった。
HTTP 500なら再試行する。
ファイルがなければエラーにする。
テストが落ちれば処理を止める。
成功と失敗を機械的に判定できる。
ところがLLMの場合、
処理自体は成功しているのに、中身が間違っている
という状態が頻繁に発生する。
API Callは200 OK。
Tool Callも成功。
ファイルも生成された。
プログラムも起動した。
しかし、ユーザーが頼んだものとは微妙に違う。
これをどう判定するのか。
そこでEvaluatorが登場する。
別のLLMに評価させる。
テストコードを書かせる。
出力形式を検証する。
期待条件と照合する。
場合によっては人間に確認させる。
つまりLoop Engineeringでは、
実行
↓
エラーだった？では足りない。
実行
↓
観測
↓
これは本当に正しいのか？
↓
十分に良いのか？
↓
次に進んでよいのか？まで考える必要がある。
成功判定そのものがEngineeringの対象になった。
これは大きな変化である。
Agentになると、失敗は連鎖する
さらにLLMをAgentとして使うと、問題はもっと大きくなる。
Chatbotなら、一回間違えても被害は小さい。
ユーザーが、
「いや、それ違うよ」
と言えば済む。
Agentは違う。
最初の判断を間違える。
その判断を前提にファイルを読む。
間違った原因を推測する。
その推測を前提にコードを書く。
コードを実行する。
エラーが出る。
そして、そのエラーを最初の仮説に合わせて解釈する。
こうして、
推測が次の推測の入力になる。
一回の小さな誤りが、Loopを回るたびに増幅される可能性がある。
人間でも似たことは起きる。
最初の思い込みに固執し、証拠を都合よく解釈し始める。
ただしAI Agentは、疲れない。
止めなければ何度でもやる。
これは長所でもあり、恐ろしい短所でもある。
間違った方向へ進んでいるAgentに無限のLoopを与えれば、
無限に頑張って間違えるAI
が完成する。
だから「長く働けるAgent」を作るだけでは意味がない。
正しい方向へ戻す仕組みが必要になる。
Context Windowは作業記憶であり、同時にゴミ箱でもある
もうひとつ、Agentを長時間動かすと必ず直面する問題がある。
Contextである。
Agentは作業するたびに情報を蓄積する。
読んだコード。
検索結果。
Toolの出力。
エラーログ。
自分の推論。
失敗した修正。
新しい修正。
さらに新しいエラー。
仕事を続けるほどContextは膨らむ。
一見すると、Context Windowが大きければ解決しそうに思える。
100K。
200K。
1M。
もっと増やせばいい。
しかし、そう単純ではない。
大量のContextには、
必要な情報だけでなく、過去の勘違いまで保存されている。
古い仮説。
すでに修正済みのコード。
意味のなくなったログ。
失敗した試行。
途中で捨てた設計。
それらも一緒に残る。
Context Windowは巨大な作業机であると同時に、
放っておけば巨大なゴミ箱にもなる。
だから長時間Agentでは、Contextを増やすことより、
何を残すか。
何を捨てるか。
何を要約するか。
どの状態を外部へ保存するか。
次のAgentへ何を引き継ぐか。
という設計が重要になる。
これもLoop Engineeringの一部であり、Graph Engineeringの一部でもある。
「ステートレスにする」という逆説
ここで面白い逆転が起きる。
長時間仕事をさせたいなら、巨大なContextを一つのAgentに抱えさせ続けるより、
いったん仕事を終わらせてしまった方がいい
場合がある。
現在の状態を整理する。
何を試したかを書く。
何が成功し、何が失敗したかを書く。
次に何をすべきかを書く。
それを外部ファイルへ保存する。
そして、新しいAgentを立ち上げる。
Agent A
↓
作業
↓
引き継ぎ書
↓
終了
新しいAgent B
↓
引き継ぎ書を読む
↓
作業
↓
新しい引き継ぎ書
↓
終了モデルから見れば、毎回ほぼステートレスである。
しかしシステム全体としては、状態が継続している。
これは別にAIが発明した考え方ではない。
プロセスを分離する。
状態を外へ出す。
永続化する。
次のWorkerが引き継ぐ。
分散システムやWorkflowでは、昔からある設計だ。
また古典へ戻ってきた。
AI Agentは「巨大なモデル」から「システム」へ
ここに、現在起きている変化の本質があると思う。
初期の生成AI競争では、モデルそのものの能力が注目された。
どちらが賢いか。
何点のベンチマークを取ったか。
Context Windowはいくつか。
何兆パラメータなのか。
もちろん、それはいまでも重要だ。
しかしAgentが実際に仕事をするようになると、
モデル単体の能力だけではシステムの性能を説明できなくなった。
どんなToolを与えるか。
どう失敗を検出するか。
どうRetryするか。
どこで別のAgentへ渡すか。
状態をどこへ保存するか。
Contextをどう管理するか。
どうテストするか。
いつ人間を呼ぶか。
つまり、
Harnessの設計が性能になる。
同じモデルを使っていても、Harnessが違えば仕事能力は大きく変わる。
そしてHarnessを作ろうとすると、私たちは再び、
Loop。
Graph。
State。
Queue。
Checkpoint。
Retry。
Validation。
といった、昔ながらの言葉へ戻っていく。
皮肉な話だ。
AIが十分に賢くなれば、細かなプログラムを書く必要はなくなると思われていた。
ところがAIが本当に仕事を始めると、
その賢いAIをどう制御するかという、新しいプログラミングが必要になった。
Loop EngineeringとGraph Engineeringが注目される理由は、ここにある。
古い技術が突然新しくなったのではない。
制御しなければならない対象が、突然とんでもなく賢くなったのである。
第5章 賢いモデルより、賢く働かせる仕組みへ
ここまで来ると、ひとつ疑問が生まれる。
モデルそのものがもっと賢くなれば、こんな面倒な仕組みは必要なくなるのではないか。
間違えないAI。
迷子にならないAI。
一度の指示で最後まで仕事を完成させるAI。
そんなモデルが登場すれば、LoopもGraphもHarnessもいらない。
Task
↓
超賢いAI
↓
Done
これが一番美しい。
そして、おそらく誰もがこれを望んでいる。
だが、現在のCoding Agentを見る限り、進化は少し違う方向にも進んでいる。
モデルを賢くすると同時に、モデルの周囲を賢くしている。
Coding Agentは、もうコード生成AIではない
少し前まで、AIコーディングと言えばコード補完だった。
関数を書き始めると続きを提案する。
コメントを書くとコードを生成する。
エラーを貼れば修正版を返す。
基本的には、
人間
↓
LLM
↓
コード
という関係だった。
現在のCoding Agentはまるで違う。
リポジトリを検索する。
複数のファイルを読む。
Shellを使う。
コードを書き換える。
テストを実行する。
エラーを読む。
修正する。
再びテストする。
必要ならGitの差分を見る。
別の実装方法を検討する。
つまり、コードを書くことは仕事の一部でしかない。
実際にやっていることは、
ソフトウェア開発というWorkflowを歩くこと
である。
ここまで来ると、モデルのコード生成能力だけ比較しても、Coding Agentの実力は分からない。
同じモデルでも、Harnessが違えば別物になる
これはAI Agentを触っていると、かなり露骨に感じる。
同じような性能のモデルでも、
ある環境ではToolを何度も使いながら問題へ食らいつく。
別の環境では、一度Tool Callに失敗しただけで止まる。
ある環境ではテスト失敗を読んで、自分から原因調査へ戻る。
別の環境では「修正しました」と言って仕事を終えてしまう。
モデルの知能だけでは説明できない。
違っているのは、その周囲にある仕組みだ。
どのToolが使えるのか。
Toolの結果をどうモデルへ返すのか。
失敗時に再試行させるのか。
どこまで自律実行を許すのか。
Contextをどう管理するのか。
長時間作業をどう継続するのか。
テスト結果をどう評価させるのか。
つまりHarnessである。
そしてHarnessの中身を分解すると、また見覚えのあるものが出てくる。
Loop。
Graph。
State。
Checkpoint。
Retry。
Evaluation。
Handoff。
昔からある部品ばかりだ。
「賢いモデルを使えば勝てる」から少し離れ始めた
生成AIの初期には、モデルの能力差がそのまま製品の能力差になりやすかった。
より賢いモデルを載せれば、より良い答えが返ってくる。
だからモデル競争を追えば、AI製品の進化もだいたい理解できた。
Agentでは、それが少し崩れてきた。
仮にモデルAがモデルBより一回あたりの成功率で優れていたとしても、
モデルBを使うシステムが、
失敗を検出できる。
正しくRetryできる。
必要な情報を外部へ保存できる。
仕事を適切に分割できる。
別のAgentへ引き継げる。
最後に自動テストできる。
という能力を持っていたらどうなるだろう。
一発勝負ではモデルAが勝つ。
しかし、30分の仕事、1時間の仕事、数百回のTool Callを含む仕事になったとき、結果は分からない。
ここでAgentの評価軸が変わる。
「どれだけ賢く答えるか」から、「どれだけ仕事を完遂できるか」へ。
この違いは大きい。
Loopは「時間」を能力へ変える
LLMには非常に面白い性質がある。
時間を与えると、性能を上げられる場合がある。
もちろん、ただ同じPromptを100回投げればいいという意味ではない。
調査する。
試す。
失敗する。
情報を得る。
仮説を修正する。
もう一度試す。
このLoopが成立していれば、一発では解けなかった問題へ到達できる可能性がある。
つまりLoopは、
計算時間を問題解決能力へ変換する装置
として見ることもできる。
人間も同じだ。
難しいバグを一目見ただけで原因が分からなくても、
ログを見る。
再現条件を調べる。
コードを読む。
仮説を立てる。
試す。
失敗する。
別の仮説を立てる。
そうやって数時間後に原因へ辿り着く。
AI Agentも、ようやく似た働き方を始めた。
重要なのは、最初から全部知っていることではない。
知らない状態から、試行によって正解へ近づけることだ。
Graphは「並列性」を能力へ変える
Graphには別の役割がある。
ひとつのAgentへ全部やらせる必要はない。
大きな仕事を分割する。
片方にはコードを調べさせる。
別のAgentにはドキュメントを調べさせる。
さらに別のAgentにはテスト方法を考えさせる。
それぞれの結果を最後に統合する。
┌→ Agent A → 調査
│
Task → 分解 ─────┼→ Agent B → 調査
│
└→ Agent C → 検証
↓
統合
↓
実装
これは人間の組織と同じだ。
ひとりの天才に全部やらせるのではなく、仕事を分割して並列化する。
Graphは、
複数の知能と計算資源を、ひとつの仕事へ組織化する仕組み
として働く。
もちろん、これも新しくない。
MapReduceでも分散処理でもWorkflow Engineでも、仕事を分割して並列に処理する考え方は昔からある。
しかし今回はWorkerがLLMである。
Worker自身が仕事を読み、
何を調べるべきか考え、
結果を文章としてまとめ、
別のWorkerへ渡せる。
これによってGraphの自由度が一気に上がった。
そしてAgent自身が仕事を分け始める
さらに面白いのは、このGraphを人間がすべて書く必要さえなくなりつつあることだ。
Agentへ大きな仕事を渡す。
Agent自身が考える。
「この問題は三つに分けた方がいい」
調査をSubagentへ渡す。
別のSubagentへ別の調査を依頼する。
結果を待つ。
集まった情報を比較する。
不足していれば、追加の仕事を作る。
そして最後に自分で統合する。
ここでは、
Graphを実行するAgentが、同時にGraphを作っている。
これは従来のWorkflow Engineとはかなり違う。
人間が設計した固定Graphの中をAIが歩くだけではない。
AI自身が、その場で小さなWorkflowを作る。
実行する。
結果によってWorkflowを変更する。
必要ならLoopを追加する。
このあたりまで来ると、「Graph Engineering」という新しい名前を付けたくなる気持ちも少し分かってくる。
優秀なプログラマーより、優秀なチームへ
ここでCoding Agentの進化を別の角度から見ることができる。
初期の目標は、
ものすごく優秀なAIプログラマーを作ること
だった。
しかし現在は、それだけではない。
優秀なプログラマー。
調査担当。
テスト担当。
レビュー担当。
そして、それらへ仕事を振るマネージャー。
全部をAIで構成できるようになり始めている。
すると目標は、
最強の一人を作ることから、強いチームを作ることへ
少しずつ変わっていく。
そしてチームを作れば、当然必要になるものがある。
役割分担。
仕事の受け渡し。
進捗管理。
品質確認。
やり直し。
記録。
承認。
……またWorkflowである。
人類は組織を作り、官僚制を作り、Workflowを作った。
そしてAIにも知能を与えた結果、
AIまで組織化し始めた。
なかなか逃げられない。
Agent Engineeringの主戦場は、モデルの外へ広がった
これは今後のAIを見るうえで重要な変化だと思う。
もちろんモデル競争は続く。
より賢く。
より速く。
より長いContextを扱い。
より正確にToolを使えるモデルが作られる。
しかし、そのモデルを使って実際に仕事をさせる競争では、
モデルの外側
がますます重要になる。
どうLoopを回すか。
どうGraphを組むか。
どうStateを持つか。
どう失敗を検出するか。
どうContextを整理するか。
どう複数Agentを協調させるか。
そして、どこまでAIへ自由を与えるか。
AI Agentが進化した結果、ソフトウェア工学が不要になるどころか、
昔ながらのソフトウェア工学が、AIの周囲へ大量に戻ってきた。
Loop Engineering。
Graph Engineering。
大層な名前ではある。
だが、その名前の向こう側で起きていることは案外堅実だ。
賢いモデルを作る競争から、賢いモデルを賢く働かせる競争へ。
AI Agentは、そこへ入り始めている。
終章 再発明には、意味がある
さて、結局のところLoop EngineeringとGraph Engineeringとは何だったのだろう。
ここまで読んできたITエンジニアなら、おそらく最初に抱いた疑念は完全には消えていないと思う。
Loop Engineering。
やはりループである。
Graph Engineering。
やはりWorkflowである。
RetryもFeedbackもState MachineもDAGもCheckpointも、昨日発明されたものではない。
コンピュータ科学は何十年も前から、こうした問題と格闘してきた。
だから、
「AI業界が昔からあるものに新しい名前を付けた」
という批判は間違っていない。
新しい名前を付ければ、新しい市場に見える。
新しい市場に見えれば、カンファレンスが開かれる。
コンサルティング資料が作られる。
スタートアップが生まれる。
そして投資家は喜ぶ。
AI業界では、技術そのものより先に言葉が走り出すことがある。
Loop EngineeringもGraph Engineeringも、その匂いはかなりする。
だが、それだけでもない。
再発明されたのはLoopでもGraphでもない
今回、本当に新しくなったものは何だったのか。
Loopではない。
Graphでもない。
Workflowでもない。
その中に置かれる部品である。
これまでコンピュータが扱ってきたWorkerは、基本的には人間が書いた処理を実行するものだった。
入力を受け取る。
決められた処理をする。
結果を返す。
ところがLLMは違う。
指示を理解する。
状況を読む。
方法を考える。
Toolを選ぶ。
結果を観察する。
失敗した理由を推測する。
別の方法を試す。
必要なら他のAgentへ仕事を渡す。
つまり初めて、
Workflowのノードに「判断するWorker」を大量配置できるようになった。
構造は古い。
部品が新しい。
その結果、古い構造をもう一度設計し直す必要が生まれた。
「Engineering」と呼ぶ意味はそこにある
while文を書くことをLoop Engineeringと呼ぶ必要はない。
四角と矢印でWorkflowを書くことをGraph Engineeringと呼ぶ必要もない。
それだけなら単なる言い換えだ。
しかし、
何をAIに判断させるのか。
何を機械的なルールで縛るのか。
何を次のLoopへ引き継ぐのか。
どの失敗を記録するのか。
どこで別のAgentへ仕事を渡すのか。
何をEvaluatorに判定させるのか。
いつ人間を呼び戻すのか。
どこでLoopを止めるのか。
ここまで考え始めると、確かに設計領域が生まれている。
つまりLoop Engineeringとは、Loopを発明することではない。
非決定的な知能を、どう反復させれば仕事になるのかを設計すること。
Graph Engineeringとは、Graphを発明することではない。
自分で判断するWorkerたちを、どう組織すれば仕事になるのかを設計すること。
そう定義するなら、この二つの言葉にも意味はある。
AIはソフトウェア工学を破壊しなかった
生成AIが登場したころ、プログラミングそのものが不要になる未来が盛んに語られた。
自然言語で指示すればAIが全部作る。
細かなロジックを書く必要はなくなる。
Workflowを設計する必要もなくなる。
人間は目的だけを伝えればいい。
実際、その方向へ進んでいる部分もある。
しかし面白いことに、AI Agentが高度になるほど、その周囲には古典的なソフトウェア工学が戻ってきた。
Stateを管理する。
処理を分離する。
失敗を検出する。
Retryする。
Checkpointを作る。
ログを残す。
テストする。
権限を制御する。
Workerを分割する。
異常なら停止する。
何十年もかけて人類が学んできたことを、AI Agent相手にもう一度やっている。
考えてみれば当然なのかもしれない。
ソフトウェア工学とは、そもそも、
複雑で、失敗する可能性のあるシステムを、それでも信頼して動かすための知恵
だったからだ。
LLMは、その究極の対象と言っていい。
恐ろしく賢い。
恐ろしく便利だ。
そして、ときどき恐ろしく予測できない。
だからこそ制御が必要になる。
革命の先で、古典へ戻る
AI Agentの進化を追っていると、不思議な循環が見えてくる。
最初は人間がすべての処理を書いていた。
次にLLMが登場し、
「もう細かな処理を書かなくても、AIに考えさせればいい」
となった。
そしてAIに自由に考えさせてみた結果、
「やっぱり、ある程度は制御しよう」
となった。
Loopを作る。
Graphを作る。
Stateを管理する。
評価する。
失敗したら戻す。
必要なら人間を呼ぶ。
一周して、ずいぶん懐かしい場所へ帰ってきた。
だが、同じ場所ではない。
昔のWorkflowの中にいたのは、命令されたことだけを実行するプログラムだった。
いまそこにいるのは、
自分で考え、自分でToolを使い、自分で失敗し、自分でやり直すプログラムである。
だからこれは、単純な回帰ではない。
古い技術を、新しい対象へ適用するための再定義だ。
技術の歴史では、こういうことがよく起きる。
革命的な技術が登場し、すべてが変わったように見える。
しばらくすると、人類は昔から持っていた知恵を引っ張り出してくる。
そして新しい技術に合わせて作り直す。
Loop EngineeringもGraph Engineeringも、おそらくそのひとつなのだろう。
名前だけ見れば、いかにも2026年のAI業界らしい。
皮を剥けば、驚くほど古典的だ。
それでも、その再発明には意味がある。
なぜなら私たちは今、
「考えるプログラム」を、どうやって働かせるか
という、昔は存在しなかった問題を解き始めているからだ。
LoopもGraphも昔からあった。
変わったのは、その中を歩く奴である。
