AIエージェントを育てる二つのループ

AIエージェントに指示（プロンプト）を与え、単一のタスクを実行させて結果を受け取る。ここまでの仕組みであれば、現代の主要なAIツールを使えば驚くほど短時間で構築できるようになりました。

しかし、そのエージェントを実際のプロダクト運用や業務システムに組み込もうとした瞬間、大きな壁に突き当たります。一件のタスクを終えたところでエージェントの思考は停止してしまい、「次に何を実行すべきか」「今回の結果から何を学習しアーカイブするか」「発生したエラーや失敗を次回どう回避するか」といった判断は、結局すべて人間が手動で行わなければならなかったからです。

単一のタスクを自律的に処理できること（Task Execution）と、一連の仕事を長期的に継続・自己改善できること（Continuous Operation & Learning）は、全く質の異なる課題です。この2つの境界線を曖昧にしたまま無秩序に機能を継ぎ足してしまうと、システム内でエラーが発生した際、何が原因で失敗したのかすら追跡不能になります。

そこで私たちが導入しているのが、目の前の単一タスクを確実にやり切る循環構造を「Agent Loop」、次の最適なタスクを選出し学習へとフィードバックする上位の循環構造を「Outer Loop」として明確に分離するアーキテクチャ設計です。

「目の前のタスクを完了する」と「一連の仕事を継続・改善する」の違い

エージェントシステムを二つのレイヤーにレイヤー分けすることで、それぞれの責任範囲が非常にクリアになります。

この二層構造を明確に区別することで、「実行プロンプトやツールの使い方が悪かったのか（Agent Loopの問題）」それとも「そもそも選んだタスクの優先度や方針が間違っていたのか（Outer Loopの問題）」を切り分けてデバッグ・評価できるようになります。「Agent Harness」という抽象的な一言で括ってしまうよりも、設計・運用の責任が遥かに明確になります。

Agent Loopが「任された仕事を確実にやり切るための泥臭い循環」であるとすれば、Outer Loopは「プロジェクト全体を俯瞰し、次の最適な仕事を選んで学習へ繋げるための上位の循環」です。

Agent Loop（内側のループ）で厳密に設計しておくべきこと

Agent Loopを設計する際、最も重要なのはダラダラとした長文の指示を与えることではなく、明確な「完了条件（Definition of Done）」を定義することです。「競合リサーチをする」といった曖昧な指示ではなく、「指定した3社を比較し、相違点をMarkdown表にまとめ、指定のファイルパスに保存してバリデーションチェックを通す」というレベルまで条件を具体化します。文章を生成して終わりなのか、根拠（一次情報）を確認し、ファイルシステムを更新し、実際の表示結果までテストして終わるのかによって、同一のタスク名であってもエージェントが辿るべきルーティングは全く異なります。

次に、そのタスクに必要なコンテクスト（文脈）だけを動的に取得させる設計にします。過去のすべての会話ログや膨大な社内ルールを一度にプロンプトに流し込むと、不要なノイズが原因でエージェントの思考や判断がぼやけてしまいます。セキュリティやコンプライアンスに関する普遍的な安全ルールだけを常にプロンプトに常駐させ、専門知識や過去の決定事項は、タスクの実行時に必要な分だけナレッジベースから動的検索（RAG）させる方が、遥かに高い出力精度が得られます。

また、実行プロセスにおいては「情報の読み取り（Read）」「判断（Reasoning）」「状態の変更（Write/Execute）」「実行結果の検証（Verify）」という各フェーズを厳密に分離します。特に外部サービスへのメール送信やデータベースのレコード削除といった不可逆な操作には、事前に人間による承認挟むか、明示的なサンドボックス環境を用意します。どのような根拠でその判断を下し、どんなツールをどのようなパラメータで呼び出したのかという完全なトレースログを残さなければ、後から人間や別のエージェントが仕事を引き継ぐことは不可能です。

最後に、実行結果を自己検証（Self-Validation）させ、「完了（Complete）」「修正の上再実行（Retry）」「異常停止（Abort）」のいずれかを判断させます。単にLLMが「できました」と自己申告したテキストを鵜呑みにするのではなく、ユニットテストの実行結果、JSONスキーマの適合チェック、生成画像の存在確認など、客観的なエビデンス（証拠）に基づいて判定を行います。同じエラーで永遠にループに陥るのを防ぐため、再試行回数の上限とフォールバックの停止条件もあらかじめ組み込んでおきます。

Outer Loop（外側のループ）は「無駄なタスクを自動生成するマシン」ではない

Outer Loopを導入する真の目的は、AIエージェントを24時間休みなくフル稼働させることではありません。バックログに溜まった課題や新しく発生したイベントの中から、提供価値、緊急度、実行リスク、トークンAPIコストなどを総合的に勘案し、「あえて今は何もしない」という選択肢も含めて、次に最も投資対効果の高いタスクを優先度付け・選出することにあります。

たとえば、カスタマーサポートの運用を例に考えてみましょう。Agent Loopは「届いた1件の問い合わせメッセージを分類し、社内データベースを参照して回答案を作成し、整合性を検証する」という単一作業を担います。一方でOuter Loopは、未対応チケットの全体量やサポートチームの修正率のトレンドを俯瞰し、「次にどの高優先度チケットを処理すべきか」を判断します。さらに、同一パターンの問い合わせが多発していることを検知した場合、Outer Loopは単に個別チケットを処理し続けるのではなく、「FAQドキュメント自体を更新する」という新しい構造的改善タスクを立ち上げる役割も担います。

このOuter Loop層に明確なゴール指標や評価基準が設計されていないと、価値の低いどうでもいいタスクをエージェントが勝手に自動生成し続け、無駄なAPIコストを垂れ流すだけの「迷惑な自動化マシン」に化けてしまいます。単に「何件のタスクを処理したか」という量的数字だけでなく、「繰り返されるエラーを削減できたか」「不要なタスクを賢くスキップできたか」という質的指標をトラッキングすることが不可欠です。

セッションの壁を越えるための「3つの記憶構造」

Outer Loopが複数の異なるタスクや日数を跨いでプロジェクトを進行させていくためには、一回のチャットセッションが切れた後も情報を保持できる「記憶（Memory）の構造化」が絶対に必要になります。単に生のチャット履歴をそのままログファイルに吐き出しておくだけでは、次回セッションでの再利用は困難です。

私たちはエージェントの記憶を、目的と保持期間に応じて以下の3つのレイヤーに明確に分類して管理しています。

記憶管理において特に見落とされがちなのが、「失敗時のログと停止理由（Abort Reason）」をエピソード記憶として正しく残すことです。失敗した際のエラー内容、当時渡していたコンテクスト、試みた修正のアプローチが構造化されて残っていれば、次回のセッションを開始する際に、AIは全く同じ罠にハマることなく、前回の失敗地点のすぐ手前から賢くリトライを開始できるようになります。

いきなり「完全自律型」を目指さないステップアップ戦略

エージェントシステムを開発する際、最初から「全自動で自律稼働するシステム」を目指して構築し始めるのは非常に危険です。まずは、以下のようにリスクの低い段階からステップバイステップで自律度を上げていくのが最も確実なアプローチです。

1. Phase 1: 単一タスクの完遂と検証（Agent Loopの確立）
一つの明確なタスクから着手します。完了条件と自動検証ロジックを作り込み、実行ログと生成成果物が正しく保存される状態を固めます。この段階では、次にどのタスクを実行するかは100%人間が手動で選択・投入します。
2. Phase 2: 優先度選出の半自動化と人間のレビュー
Outer Loopのプロトタイプとして、タスクの候補と優先順位の推奨ロジックを作成します。ただし、実際にエージェントを起動してタスクを実行させる決定権は、人間がUI上でボタンを押すことで確認・承認します。
3. Phase 3: ルーチンタスクの自動化と成果監視
低リスクかつ定型的なタスク（日次バッチ処理、定期レポート作成、既知のフォーマット変換など）に限って、タイマーやイベント駆動による自動実行を許可します。エージェントによる長期記憶の更新やシステムの改善提案については、引き続き人間がダッシュボード上で検収・承認します。
4. Phase 4: 条件付きの自律改善
低リスク領域において十分な運用のログとテスト結果が蓄積され、安全性が客観的に証明されて初めて、ナレッジの自動更新や軽微なシステム改善の適用をエージェントに自律許可します。

このステップ順序を無視して最初から完全自律化を目指してしまうと、一見画面上では何かが勢いよく動いているように見えても、裏では何が成功していて何が破壊されているのか誰にも把握できない、極めて危険なブラックボックスシステムと化してしまいます。

観測と評価：何をモニタリングすべきか

システムの健全性を保つためには、Agent LoopとOuter Loopのそれぞれで異なる観測指標（メトリクス）を設定し、個別にダッシュボードでトラッキングする必要があります。

• Agent Loopの観測指標: タスク完了率（Success Rate）、人間による手動修正率（Human Intervention Rate）、平均再試行回数（Retry Count）、1タスクあたりの実行時間とAPIトークンコスト。
• Outer Loopの観測指標: 選定されたタスクが最終的なプロジェクト成果に寄与した割合（Value Density）、同一エラーの再発減少率（Error Reduction）、過去記憶の参照成功率（Memory Recall Rate）。

この二つの評価軸を混同してしまうと、「とりあえず大量のタスクを爆速で処理した」という表面的な数字だけに満足してしまう陥穠にハマります。どれほど高速にタスクを回せたとしても、間違った方向のタスクを大量生産していたのであれば、システム全体として生み出された価値はゼロ、あるいはマイナスです。

現代のエージェント開発において私たちが最も重視しているのは、1つの魔法のような巨大プロンプトを作り込むことではありません。タスクの「実行（Agent Loop）」と「選択・評価（Outer Loop）」を明確に分離し、それぞれの挙動を客観的に観測・デバッグできる健全なシステム構造を組み上げることです。

Agent Loopによって目の前の1件を泥臭く確実に終わらせ、Outer Loopによってその結果を次なる最適な判断と組織知へと還元していく。この二つの循環が美しく噛み合った時、AIエージェントは単なる「人間による手動操作の気休め程度の代用品」から、時間とともに自己進化し続ける「本物の運用システム」へと昇華していくのです。