以前は、AIエージェントを構築することは、チャットボットにプロンプトを送るのと基本的には同じことだと思っていました。質問をうまく構成すれば、モデルが答え、それで終わりだ、と。しかし、いくつかのアプリケーションをリリースしたとき、現実は厳しく突きつけられました。LLMはエージェントではありません。LLMは次のトークンを予測するだけです。エージェントを生み出すのは「ループ」なのです。
お茶を淹れることを考えてみてください。make_tea() という単一のコマンドを実行して、そのまま立ち去るわけではありません。ケトルに水を入れ、水圧が低いことに気づいて待ち、スイッチを入れ、スイッチが壊れていることに気づき、別のコンロに移動し、湯気を確認し、注ぎ、味見をし、茶葉が浸かりすぎていたのでハチミツを加えるかもしれません。目標は変わりませんが、手順は変わります。観察し、調整し、そしてやり直す。AIエージェントも、まさにこのように動作します。
エージェンシーを生み出すサイクル
ループは抽象的な理論ではありません。それは、あなたの代わりに動くあらゆるシステムの、運用の鼓動（ハートビート）なのです。実務における実際の動きは以下の通りです。
- Think（思考）: モデルが目標について推論し、何が必要かを決定します。ユーザーが「明日、ポートランドに傘を持っていくべき？」と尋ねると、モデルは天気予報と場所が必要であることを特定します。
- Act（実行）: モデルがツールを呼び出します。「Portland」を解決するためにジオコーディングAPIを呼び出し、次にその座標を使って天気予報のAPIにアクセスするかもしれません。
- Observe（観察）: モデルがツールの出力を読み取ります。APIはJSON形式の予報を返しましたか？それとも403エラー、あるいはHTMLのメンテナンスページでしたか？
- Update（更新）: 見た内容に基づいて、モデルは計画を修正します。ジオコーダーがオレゴン州のポートランドではなくメイン州のポートランドを返した場合、モデルは曖昧さを解消する必要があります。APIがダウンしている場合は、バックアップソースに切り替えるか、ユーザーに尋ねるかもしれません。
- Think Again（再考）: 新しいコンテキストとともにサイクルが再開されます。
これは、一度書いて忘れてしまうような5つの独立した関数ではありません。目標が達成されるか、強制停止がトリガーされるまで走り続ける、継続的なエンジンなのです。モデルはスクリプトのようにコードを実行しているのではなく、世界の状況について推論し、アクションを選択し、その結果を読み取り、次に何をすべきかを決定しているのです。これこそが、単なる高度なオートコンプリートと、仕事を完遂するエージェントとの違いです。
なぜフレームワークはどれも似ているのか
LangGraph、CrewAI、またはAutoGenに触れたことがあるなら、それらが似通って見えることに気づいたかもしれません。LangGraphは、フローをノードとエッジからなる永続的なグラフとしてモデル化します。CrewAIは、エージェントを役割（ロール）とクルーに組織化します。AutoGenは、マルチエージェント間の会話をオーケストレートします。パッケージングは異なりますが、骨組みは同じです。
これらが似ているのは、すべてがこの同じループの原理に基づいて設計されているからです。LangGraphは、ツール呼び出しとモデルの推論の間の状態遷移として、サイクルを明示的に構造化しています。CrewAIは、役割ベースのエージェントの中にループを包み込んでいますが、各クルーメンバーは依然として計画、実行、観察のサイクルを繰り返します。AutoGenはアクター間のメッセージを仲介しますが、すべてのターンは依然として「生成、実行、内省、ルーティング」のバリエーションに過ぎません。
これらのフレームワークがループに焦点を当てているのは、そこにエージェンシー（主体性）が存在するからです。基盤となるモデルがGPT-4、Claude、あるいは微調整されたオープンウェイトモデルであっても、ループがなければ、それは非常に高価な文章補完器に過ぎません。ループがあれば、複数の試行にわたって目標に向かって継続できるシステムになります。
真の仕事が始まる時
ローカルでのデモは魔法のように感じられます。しかし、プロダクション（本番環境）は、その魔法が混沌（カオス）に直面する場所です。プロトタイピングを過ぎると、AIの問題を解くのではなく、システムエンジニアリングの問題を解き始めることになります。
ツールの失敗は避けられません。 APIはタイムアウトします。不正な形式のJSONを返します。HTMLに包まれた500エラーを投げます。もしループがすべてのツール出力を盲目的に信頼してしまうなら、エージェントは成功を幻覚（ハルシネーション）として報告するか、混乱の渦に陥るでしょう。リトライロジック、サーキットブレーカー、そしてすべての返却ペイロードに対するスキーマ検証が必要です。
メモリは古くなります。 エージェントはユーザーの推奨データベースがPostgreSQLであることを覚えています。しかし、インフラチームは昨夜、新しいクラスターに移行しました。コンテキストを更新または期限切れにするメカニズムがなければ、エージェントは存在しないエンドポイントに対して自信満々にコマンドを発行してしまいます。メモリにはタイムスタンプ、信頼スコア、そして自身を無効化する能力が必要です。
無限ループは静かな殺し屋です。 エージェントがウェブを検索し、有用なものが見つからず、クエリをわずかに修正して再検索し、また見つからず、ということを繰り返します。最大反復回数の制限や意味的な重複検知がなければ、ユーザーが待っている間にトークンと資金を浪費し続けます。リトライのハードキャップ、分岐チェック、そして人間へのエスカレーションパスといったガードレールを構築しなければなりません。
無関係なデータが推論を妨げる。 RAG（検索拡張生成）パイプラインは、しばしば漠然と関連した50もの段落のドキュメントをコンテキストウィンドウに放り込んでしまう。その結果、エージェントはノイズに圧倒され、誤ったツールを選択したり、パラメータをハルシネーション（幻覚）したりする。モデルが検索されたテキストを目にする前に、フィルタリング、ランキング、そして簡潔な要約が必要なのだ。
エージェントに必要なのは、単なる知能だけではない。管理されたメモリ、明示的な状態追跡、厳格なガードレール、そして観測可能なテレメトリを備えた「システム」が必要なのだ。モデルが優れていればいるほど、それを取り巻くシステムもより優れたものでなければならない。強力なモデルであっても、脆弱なループの中に置かれれば、単により理路整然とした失敗を生み出すだけである。
最後までやり遂げる
エージェントにおける真の知能とは、最初の回答を的中させることではない。計画通りにいかない時に、意図と結果の間のギャップをどう埋めるかにある。最初の試行は簡単だ。誰にでも「ハッピーパス（正常系）」のスクリプトは書ける。難しいのは4回目のイテレーションだ。主要なAPIがダウンし、コンテキストウィンドウは縮小し、ユーザーはしびれを切らし、それでもなおエージェントは有用なものを届けなければならない状況だ。
その粘り強さこそが、デモと製品を分かつものだ。それは、リアルタイムでモデルの重みを更新することによってではなく、計画を更新することによって、あらゆるステップから学ぶ能力のことである。エージェントは戦術が変化しても、目標を一定に保つ。これこそが、実践における「ルーピング・プリンシプル（ループの原理）」である。
では、未来はより大規模なモデルのものか、それともより優れた実行ループのものだろうか？ スケールが役立つのは確かだ。より有能なモデルは、各サイクル内での推論能力が高い。しかし、緻密で、観測可能で、弾力性のあるループ内で動作する小型モデルは、すべてを一度の試行で解決しようとする巨大なモデルよりも、ほぼ常に優れたパフォーマンスを発揮する。予測を行動へと変えるのは、この「ループ」なのだ。そこに投資せよ。
出典: The Looping Principle: A Simple Mental Model for Understanding AI Agents
このような議論をもっと見たい方は、TelegramのGyaanSetu学習コミュニティに参加してください。