もしこの12層を本当に深く理解できれば、実際にはすでに Agent プラットフォームを設計するための基礎能力を備えていると言えます。
1. オーケストレーション・ループ：Agent が「人間のように働けるか」を本当に決めるもの
多くの人は Agent に初めて触れたとき、自然と「大規模言語モデル」こそが中核だと感じます。
しかし、実際にエンジニアリングを経験すると、モデルは実際には「次に何を生成するか」だけを担当しており、Agent がタスクを連続して完了できるかどうかを本当に決めるのは、オーケストレーション・ループ（Orchestration Loop）だと分かります。
というのも、Agent と通常のチャットボットの最大の違いは、単に一文を返すのではなく、「思考 → ツール呼び出し → 結果取得 → 再思考 → 再実行」というサイクルを繰り返す点にあります。このループが、Agent がいつツールを呼ぶのか、いつ推論を継続するのか、いつ人手確認を待つのか、いつタスクを終了するのかを決定します。エンジニアリングの観点では、これはまさに Agent システム全体の CPU スケジューラです。
現在主流の Agent オーケストレーション方式は、おおよそ3種類あります。
1つ目は自動ループです。つまり、フレームワークが model → tool → model の呼び出し経路を自動で処理してくれる方式です。LangChain や OpenAI Agents SDK は基本的にこの方式に属し、開発が簡単で習得も速く、素早くデモを作るのに向いています。
2つ目はワークフロー型オーケストレーションです。開発者がノード、状態、分岐、並列ロジック、そして中断・復帰ポイントを自分で定義します。この方式は DAG ワークフローに近く、複雑な業務システムではより安定しやすいです。LangGraph、ADK、CrewAI は基本的にこのカテゴリに入ります。
3つ目は Actor モデルで、各 Agent を独立したサービスとして扱い、非同期メッセージで通信させます。AutoGen が典型例で、この方式は複雑なマルチ Agent 協調により適しています。
ただし、実運用に入ると、オーケストレーション・ループで最も起きやすい問題は「動かないこと」ではなく、「止まらないこと」です。多くの Agent はツールを無限に呼び出し、最終的に token が爆発的に増加し、さらには無限ループに陥ります。そのため本番環境では、最大ループ回数、最大ツール呼び出し回数、タイムアウト、最大 token 消費量、中断・復帰機構など、さまざまな制限を加える必要があります。さもないと、Agent は「知的システム」から「コストブラックホール」へと変わってしまいます。
一言で言えば、オーケストレーション・ループの本質は Agent の CPU スケジューリングシステムです。
2. ツールシステム：Agent が突然「仕事をこなせる」ようになる理由
多くの人は、Agent が自動で Web 検索を行ったり、メールを送ったり、ブラウザを操作したりするのを見て、とても不思議に感じます。
しかし本質的には、これらの能力はすべてツールシステム（Tool System）から来ています。
大規模言語モデル自体は外部世界を本当に操作することはできず、生成できるのはテキストだけです。Agent に「仕事をさせる」ためには、開発者がさまざまな外部能力を、モデルが理解できるツールインターフェースとして包装する必要があります。言い換えれば、ツールシステムとは AI に「手足」を装着するようなものです。
ツールシステムが担当する範囲は非常に広く、Web 検索、データベース問い合わせ、メール送信、内部 API 呼び出し、コード実行、ブラウザ操作、さらには企業内部システムの制御まで含まれます。ツールシステムがなければ Agent は永遠にチャットボットのままですが、ツールシステムがあれば、初めて実行能力を持ちます。
現在主流のツールプロトコルは主に3種類あります。
1つ目は Function Calling です。これは本質的に、ツールを JSON Schema として記述し、モデルに「このツールの名前は何か」「どのようなパラメータが必要か」「何を返すか」を理解させる方法です。現在最も主流で、導入もしやすい方式です。
2つ目は OpenAPI です。既存の REST API システムにより適しています。多くの企業は既存のインターフェースをそのまま Agent Tool に変換します。
3つ目は MCP で、近年ますます注目されている方向性です。MCP の最大の価値はツール接続を標準化することであり、将来的には異なる Agent フレームワーク間でアダプタを何度も書き直す必要がなくなります。
しかし、実際のエンジニアリングで最大の難所は「ツールをどう呼ぶか」ではなく、「ツールをどう制限するか」です。Agent が shell、データベース、ファイルシステム、決済 API を操作できるようになると、リスクは一気に拡大します。
そのため、成熟した Agent プラットフォームでは必ず権限制御を行います。たとえば、どのツールは人手承認が必要か、どの操作は読み取り専用にするか、どのパラメータの入力を禁止するか、すべてのツール呼び出しに完全な trace と監査記録を持たせるか、といったことです。さもないと、ツール能力が強いほど、むしろシステムリスクは大きくなります。
一言で言えば、ツールシステムの本質は Agent のデバイスドライバ層です。
3. 構造化出力：なぜ本当の Agent は直接「自然言語」を出力しないのか
多くのチームが Agent を作り始めた初期にたどる典型的な段階があります。まずモデルに長文を出力させ、その後自分たちで正規表現を使って解析する、というものです。たとえば、回答から状態、金額、タスクフィールドを抽出する、といった具合です。最初は問題なさそうに見えますが、システムが本番に入ると、すぐにこの方法が極めて不安定だと分かります。なぜなら、自然言語はそもそもプログラムが消費するためのものではないからです。実際のエンジニアリングシステムに必要なのは構造です。
そのため、構造化出力（Structured Output）はほぼすべての Agent フレームワークで標準機能になっています。これは本質的に、LLM の「言語能力」を、プログラムが本当に実行できるプロトコルへ変える問題を解決しています。たとえば Agent にチケットを作成させる場合、最終出力は「作成しました」という一文ではなく、チケット ID、優先度、担当者、状態などを含む標準的な JSON であるべきです。そうして初めて、下流システムが自動処理を継続できます。
現在主流の実装方法はおおよそ3種類です。
1つ目はモデルネイティブな Structured Outputs です。つまり、モデルに schema に厳密に従って出力するよう直接要求する方式です。この方法は最も安定しています。プロトコル自体がすでに制約されているからです。
2つ目は validator + retry です。モデルがまず生成し、その後 Pydantic や Validator で検証します。形式が正しくなければ再生成します。PydanticAI が典型例です。
3つ目はより低レベルな grammar decoding です。トークン生成の段階で制約をかけ、最初からモデルが正しい構造しか出力できないようにします。Outlines や vLLM はこの方向へ進んでいます。
しかし本番で最も重要なのはとても単純です。自由なテキストを決して信用しないこと。モデルは今日 status を出力していても、明日は state、翌日は current_status と表記するかもしれません。人間にとっては理解に支障がなくても、プログラムにとってはそれが本番障害になります。そのため、成熟した Agent システムでは必ず schema 検証、失敗時の再試行、repair 修復、さらには人手によるフォールバックまで行います。構造化出力は「体験をよくする」ためではなく、システムを稼働可能に保つためのものです。
一言で言えば、構造化出力の本質は Agent のプロトコル層です。
4. メモリシステム：なぜ Agent は「使うほどあなたを理解する」のか
多くの人はメモリシステムを「会話履歴をもう一度 Prompt に入れること」と理解しがちです。
しかし実際にエンジニアリングを経験すると、このやり方では到底持ちこたえられないことが分かります。コンテキストウィンドウには常に限界があり、実際のユーザー履歴はどんどん増えていくからです。
成熟したメモリシステムは、会話履歴というよりデータベースに近い存在です。Agent が毎回ゼロからユーザーを理解し直さなくても済むようにします。たとえば、ユーザーが好む表現、これまでに行った操作、会社の業種、すでに確認済みの情報などは長期記憶に属します。一方、現在のタスク状態、現在のページ内容、直前に実行したステップは短期記憶です。成熟した Agent は、この2種類を分けて管理します。すべてが混ざると、すぐに「メモリ汚染」が起こるからです。
メモリ汚染とは、Agent が意味のない大量の情報を覚え始めることです。たとえば、ユーザーが今日何気なく株の話をしただけなのに、システムが恒久的に「このユーザーは株が好き」と記録してしまうようなものです。やがて Agent は「情報のゴミ捨て場」のようになっていきます。したがって、成熟したメモリシステムで本当に重要なのは「どう保存するか」ではなく、「何を保存するか」です。
本番環境では通常、書き込み前抽出、重複排除、TTL、階層ストレージ、ユーザー単位の分離、ソース追跡など、一連の書き込み戦略があります。多くのチームは最初にベクトル検索に強く注目しますが、後になって、システム品質を本当に左右するのは embedding ではなくメモリガバナンスだと気づきます。メモリ戦略が間違っていれば、どれだけ優れた検索システムでも、間違った情報をより速く検索しているだけだからです。
現在の主流フレームワークでは、Mem0、Zep、Letta がまさにこの問題を重点的に解決しています。特に Letta は興味深く、「常駐メモリ」と「アーカイブメモリ」を分離しており、本質的にはオペレーティングシステムのメモリ階層に非常に近いです。したがって、メモリシステムで本当に重要なのは、Agent に「より多く覚えさせる」ことではなく、「正しく覚えさせる」ことです。
一言で言えば、メモリシステムの本質は Agent の長期ストレージシステムです。
5. コンテキスト管理：モデルが「今まさに何を考えられるか」を本当に決めるもの
Agent を作り始めたばかりの頃、多くの人は無意識にこう考えます。
「コンテキストウィンドウがどんどん大きくなるなら、すべての情報を入れればいいのでは？」
しかし結果としては、Prompt はどんどん長くなるのに、モデルはむしろ賢くなくなります。なぜなら、コンテキストは多ければ多いほど良いのではなく、より正確であるほど良いからです。
成熟した Agent システムでは、コンテキスト管理（Context Management）は非常に重要な中核能力です。これは、その推論ラウンドでモデルが何を見るべきかを決定します。この重要性は多くの人の想像を超えています。大規模言語モデルには本当の意味での長期記憶はなく、毎回の推論は、その時点の token ウィンドウに入っている内容だけを基に行われるからです。つまり、誰がコンテキストウィンドウに入るかによって、「モデルに考えてもらえる」資格が決まります。
エンジニアリングの観点では、コンテキスト管理は本質的に情報のスケジューリングシステムです。毎日4つのことを行っています。検索、選別、圧縮、再配置です。どの内容を保持すべきか、どれを削除すべきか。どの情報を前に置くべきか、どれを要約・圧縮すべきか。どの履歴がまだ重要で、どれがすでに無効なのか。これらすべてがコンテキスト管理に含まれます。
現在、多くのフレームワークはすでにこれらの機能を組み込み始めています。LangChain には trim、summarize、tool limit などの middleware があり、ADK は instruction を動的生成します。Responses API も stateful continuation と prompt caching をサポートし始めており、本質的にはすべて「コンテキスト・スケジューリング」の問題を解いています。
しかし実運用では、最大の2つの落とし穴は Context Overload と Context Collapse です。Context Overload は理解しやすいでしょう。情報が多すぎて重要点が埋もれるのです。モデルは「すべてを見ている」ように見えても、実際には関連情報が希釈されてしまいます。一方、Context Collapse の方が厄介です。多くのシステムは token 節約のために会話履歴を繰り返し要約しますが、要約を重ねるほど詳細が失われ、最後にはモデルに曖昧な要約しか残りません。Agent が長く話すほど「記憶を失う」ように見えるのは、本質的にはコンテキスト崩壊です。
そのため、最近では単純なテキスト要約ではなく、構造化コンテキストを作るチームが増えています。真に高品質なコンテキストシステムの目的は、決して「より多くの情報を詰め込むこと」ではなく、「重要な瞬間に、モデルに最も重要な情報を見せること」です。
一言で言えば、コンテキスト管理の本質は Agent のメモリマネージャです。
6. Prompt 組み立て：本当の Prompt Engineering は、ますます「コンパイラ工学」に似てきている
Prompt Engineering と聞くと、多くの人はまず「どうやってより強力な System Prompt を書くか」を思い浮かべます。
しかし実際の大企業の Agent システムは、すでに「手書きのプロンプト」ではありません。なぜなら、モデルに実際に入る Prompt は動的に生成されることが多いからです。そこには、システムルール、ユーザー目標、ツール定義、コンテキスト検索結果、履歴メモリ、出力 schema、安全ルール、さらにはデバッグ情報まで含まれることがあります。
言い換えれば、今の Prompt は単なる一文ではなく、動的なコンパイルシステムです。そのため、Prompt Assembly はますます重要になります。これはシステム内のさまざまな情報源を、安定した順序とルールに従って組み合わせ、最終的にモデルが実際に見る入力へとまとめ上げる役割を担います。エンジニアリングの観点では、これはコンパイラのフロントエンドに非常によく似ています。上位レイヤーの意味情報を、モデルが実行可能な Prompt に「コンパイル」しているからです。
現在の成熟したシステムでは、通常 Prompt をレイヤー分けします。
たとえば、system layer はアイデンティティとルールを担当し、task layer は現在のタスクを担当し、memory layer は履歴記憶を担当し、tool layer はツール記述を担当し、output layer は構造化制約を担当します。これを行う最大の価値は、単にコードが見やすくなることではありません。むしろ、真にエンジニアリング的な3つの問題を解決することにあります。すなわち、テスト可能、キャッシュ可能、説明可能です。
テスト可能とは、Prompt に回帰テストを適用できること。キャッシュ可能とは、安定したプレフィックスを再利用できること。説明可能とは、本番で問題が起きたとき、開発者が「その時モデルが実際に何を見ていたか」を正確に再現できることです。これは非常に重要です。
というのも、多くの Agent システムで問題が発生した後、開発者は実際の Prompt すら再現できません。結局のところ、モデルがなぜそのように答えたのかをひたすら推測するしかなくなります。そして Agent がますます複雑になるにつれ、Prompt も「実行時に動的生成されるコード」にますます似てきます。したがって、将来の本当に成熟した Prompt Engineering は、「プロンプトを書く」ことではなく、「Prompt コンパイルシステムを設計する」ことになる可能性が高いです。
一言で言えば、Prompt 組み立ての本質は Agent の Prompt コンパイラです。
7. 状態とチェックポイント：なぜ本当の Agent は「途中から再開」できなければならないのか
多くの Agent デモはとても滑らかに見えます。なぜなら、通常は10数秒しか動かないからです。
しかし本番システムはまったく違います。
実際の業務における Agent は、数時間、場合によっては数日間動作することもあります。その間に、承認待ち、外部 API 待ち、データベース処理待ち、さらにはユーザーが翌日続きの操作をするのを待つことすらあります。そこで致命的になるのが、システムが途中で落ちたらどうするのか、という問題です。
そこで状態とチェックポイント（State & Checkpoint）が必要になります。これは、すでに完了したステップ、現在のワークフローノード、ツール結果、会話状態、承認状態など、Agent の現在の実行状態を保存する役割を担います。
本質的には、Agent の「保存」です。成熟した Agent システムは必ず復元可能でなければなりません。つまり、システムがクラッシュした後でも、最初からやり直す必要はなく、直近の checkpoint から実行を再開できる必要があります。
ただし、ここで本当に難しいのは「状態を保存すること」ではなく、「副作用の重複実行を避けること」です。たとえば、Agent がすでにメールを送信していたとします。ところがシステム復旧時にもう一度同じ処理を実行してしまう。これは本番事故です。そのため durable execution システムでは、冪等性が特に重視されます。すべてのツール呼び出しは、もともと冪等であるか、少なくともロールバックをサポートできなければなりません。
もう1つのエンジニアリング上の難しさは checkpoint の粒度です。粗すぎると、失敗時に大量のステップを再実行しなければなりません。細かすぎると、状態ストレージが急増します。したがって、成熟した状態システムは本質的に「復旧効率」と「ストレージコスト」のバランスを取っています。
現在、LangGraph、Temporal、DBOS、Azure Durable Functions などは、まさにこの種の問題を解決しています。なぜなら、本当の Agent はいつまでも短命なチャットセッションであり続けることはできず、やがて長期稼働するタスクシステムへと変わっていくからです。
一言で言えば、状態とチェックポイントの本質は Agent の保存・復元システムです。
8. エラー処理：成熟した Agent は「エラーが出たら即死」しない
多くの Agent デモには共通の特徴があります。API エラーが出ると、全体のフローが即座に終了してしまうことです。しかし実際の本番システムでは、そんなことは到底不可能です。現実世界そのものが不安定だからです。API はタイムアウトし、モデルはレート制限に遭遇し、データベースは揺らぎ、外部サービスはダウンし、さらにはモデル自身が不正な結果を出力することすらあります。そのため、成熟した Agent には完全なエラー回復システムが必要です。
エラー処理（Error Handling）の本質は、「システムでエラーが起きたとき、どうすべきか」を解決することです。再試行するのか、縮退運転するのか、人手を介入させるのか、あるいはそのまま終了するのか。成熟したシステムは通常、エラーを階層化します。
1つ目は一時的エラーです。たとえば 429、ネットワークの揺らぎ、リクエストタイムアウトなどです。これは本質的に「一時的に利用不可」なので、指数バックオフによる再試行が最も適しています。
2つ目は構造エラーです。たとえばモデル出力が schema に一致しない、JSON 形式が不正、フィールドが欠落している、といったものです。この種の問題には通常、repair や re-prompt が適しています。
3つ目は本当に危険な業務エラーです。たとえば権限不足、資金検証失敗、重要な前提条件の欠落です。この種の問題を盲目的に再試行すると、むしろより大きな事故を起こす可能性があります。
そのため、多くの企業向け Agent は最終的に人手引き継ぎ機構を導入します。本番ではもう1つ非常に重要な問題があります。それは、エラー情報の分離です。システム内部のエラーには、スタックトレース、内部パス、データベース構造、API Key など、多くの機密情報が含まれていることがあるからです。これらがそのままモデルに露出すると、セキュリティリスクは非常に高くなります。そのため、成熟したフレームワークでは通常、「システムエラー」と「モデルに見せるエラー」を分けます。システム内部には完全なログを残し、モデルにはマスキング済みの修正シグナルだけを渡します。
本質的に、成熟したエラー処理システムの目的は、「Agent にエラーを起こさせないこと」ではなく、「エラーが起きてもシステムが落ちないようにすること」です。
一言で言えば、エラー処理の本質は Agent の異常回復センターです。
9. ガードレールシステム：本当に危険なのはモデルではなく、「行動するモデル」である理由
多くの人が初めて Agent を作るとき、最も見落としやすいのが安全です。
以前の大規模言語モデルの多くは、せいぜい「言い間違える」だけでした。しかし Agent は違います。モデルがツール能力を持つと、実世界に本当に触れ始めます。メールを送り、ファイルを削除し、データベースを照会し、ブラウザを操作し、さらにはコードまで実行できます。このときリスクは一気に拡大します。なぜなら、本当に危険なのは「会話する AI」ではなく、「行動する AI」だからです。
そこでガードレールシステム（Guardrails）が極めて重要になります。これは入力、推論、ツール実行、出力の各段階で Agent に安全制約をかける役割を担います。
成熟した Guardrails は通常、4層に分かれます。
1層目は入力ガードレール：主に Prompt Injection、権限逸脱要求、機密情報の誘導などの問題を解決します。
2層目はコンテキストガードレール：悪意ある内容の多くは、ユーザー入力ではなく外部検索結果から来る可能性があるためです。
3層目はツールガードレール：これが最も重要です。本当に危険な動作は通常、ツール実行段階で起こるからです。たとえば shell、SQL、ファイル書き込み、決済 API などは、必ず権限を制限しなければなりません。
4層目は出力ガードレール：コンテンツ審査、マスキング、ポリシーチェック、構造検証などを含みます。
しかし、真に成熟した安全体系には非常に重要な原則があります。安全問題のすべてを LLM に任せないことです。モデル自体は安定していないからです。今日リスクを識別できても、明日も安定して識別できるとは限りません。そのため成熟したシステムでは、通常「ルール優先、モデルは補助」という戦略を採用します。
決定論的なルールが中核の安全境界を担当し、LLM は曖昧なリスク判断を担当し、高リスク動作は必ず人手承認とします。エンジニアリングの観点では、Guardrails はもはや「モデル機能」ではなく、企業級の安全基盤です。
一言で言えば、ガードレールシステムの本質は Agent の安全コアです。
10. 評価とフィードバック：Agent を本番投入してから、本当の難しさが始まる理由
多くのチームが Agent を作るとき、最初に気にするのは「動くかどうか」です。
しかし本番に出した直後、すぐにもっと難しい問題に直面します。つまり、Agent が良いかどうかをどう判断するのか、です。
従来のソフトウェアの結果は通常、決定的です。しかし Agent には本質的にランダム性があります。同じ問題でも、時間、モデル、コンテキストが違えば、異なる結果になることがあります。そのため、評価とフィードバック（Eval & Feedback）がますます重要になります。その本質は2つの問題を解決することです。つまり、システムが今どれだけ信頼できるか、そしてシステムをどう継続的に改善するか、です。成熟したチームは通常、3種類の評価を同時に行います。
1つ目はオフライン評価です。固定データセットによる回帰テストで、Prompt、モデル、Workflow の効果変化を比較します。
2つ目はオンライン評価です。実際のユーザートラフィックを直接監視し、本番のドリフトを検出します。
3つ目は人手フィードバックです。本番の bad case を収集し、アノテーションとレビューのプロセスに入れます。
多くのチームは最初、LLM-as-Judge を非常に信じ、「GPT に GPT を採点させれば十分だ」と考えます。しかし実際に長くやってみると、それだけでは全く不十分だと分かります。モデル評価自体もドリフトするからです。そのため、安定した評価基盤は必ず複合的でなければなりません。ルール検証、Schema 検証、Reference Test、LLM Judge、人手によるサンプル検査など、複数の仕組みが一緒に働く必要があります。現在の多くのプラットフォーム、たとえば LangSmith、Phoenix、Braintrust、MLflow などは、本質的に同じことをしています。つまり、traces、eval、dataset、feedback を一つの閉ループに接続しているのです。
なぜなら、成熟した Agent システムは「一度本番投入して終わり」ではなく、継続的に進化するシステムだからです。そのため Eval は最終的には、従来のソフトウェアにおける CI/CD と QA にますます似てきます。ただしテスト対象が「コードロジック」から「モデルの挙動」に変わるだけです。
一言で言えば、評価とフィードバックの本質は Agent の QA と継続最適化システムです。
11. マルチ Agent オーケストレーション：なぜ AI の世界で「AI チーム」が生まれ始めているのか
最近は、マルチ Agent を採用するシステムがますます増えています。たとえば、ある Agent は検索を担当し、別の Agent はコードを書く、別の Agent はレビューし、さらに別の Agent は要約する、といった具合です。初めて見ると、単に「モデルのインスタンスをいくつか立てているだけ」だと思うかもしれません。しかし実際のエンジニアリングでは、マルチ Agent はそれほど単純ではありません。本当に解決している問題は、複雑なシステムにおける役割分担なのです。
1つの Agent が計画、実行、レビュー、コミュニケーション、要約まで同時に担うと、そのコンテキストはどんどん混乱し、目標も衝突しやすくなります。そのため、多くのチームは異なる責務を異なる Agent に分割し始めます。エンジニアリングの観点では、これは分散システムにますます近づいています。なぜなら、マルチ Agent システムでは、役割間通信、共有状態、権限分離、タスク委任、競合処理といった問題が生じるからです。
現在の主流パターンは比較的安定しています。たとえば delegation は主 Agent がタスクを割り当てる方式、handoff は制御権を移譲する方式、parallelization は複数 Agent に並列で解かせる方式、group chat は複数人会議に近い方式です。ただし、実運用で最も落とし穴になりやすいのは「マルチ Agent 化しすぎること」です。多くのチームがあらゆる問題を複数 Agent に分解し、結果としてシステムの複雑度が一気に爆発します。
Agent が増えるほど、通信コスト、状態同期、trace の数、デバッグ難易度は指数関数的に増加します。多くの場合、1つの Agent に planner を付けるだけで十分です。役割の目標、権限境界、コンテキストウィンドウが明確に異なる場合にのみ、マルチ Agent は本当に価値を持ちます。したがって、成熟したマルチ Agent システムで重要なのは「Agent の数」ではなく、「役割境界が明確かどうか」です。本質的に、マルチ Agent はもはや Prompt Engineering というより、組織設計に近いものになっています。
一言で言えば、マルチ Agent オーケストレーションの本質は AI 世界における分散協調システムです。
12. 初期化とランタイム：Agent がデモから本番へ移行できるかを本当に決めるもの
最後のこの層は、しばしば最も見落とされやすいものです。多くの人は Agent を作るとき、Prompt、Workflow、Tools に注目します。
しかし、システムを実際に本番へ載せられるかを決めるのは、実はランタイム（Runtime）です。デモが動くからといって、本番でも動くとは限りません。実運用の環境では、環境不一致、依存関係の衝突、権限分離、セッションライフサイクル、コールドスタート、スケールアップ／ダウン、コード実行の安全性など、さまざまな現実的な問題に直面します。
そのため、初期化とランタイムシステムは非常に重要になります。これは、環境初期化、設定読み込み、秘密情報管理、セッション管理、デプロイ、サンドボックス分離、ライフサイクル管理など、多くのことを担当します。エンジニアリングの観点では、すでに「オペレーティングシステム」に非常に近い存在です。成熟した Agent Runtime は通常、次の3点を特に重視します。
1つ目は再現性です。どこで実行しても環境は一貫していなければなりません。さもないと、本番問題の切り分けが非常に困難になります。
2つ目は隔離です。特に Coding Agent では重要です。モデルにコード実行を許可すると、システムリスクは一気に高まるからです。そのため現在多くのプラットフォームでは、Docker Sandbox や E2B のような隔離環境を導入しており、本質的には AI に独立したオペレーティングシステムを提供しているのです。
3つ目はセッション再利用です。多くの Agent は長寿命タスクだからです。毎回環境を再初期化すると、コストが非常に高くなります。そのため成熟した Runtime は通常、workspace、cache、session 状態を保持します。
現在、Agent Framework、ADK、LangSmith Agent Server などは、まさに「Agent Runtime プラットフォーム」の方向へ進化しています。なぜなら、将来の本当の Agent は、もはや単なる SDK ではなく、長期稼働するインテリジェントサービスへ変わっていく可能性が高いからです。
一言で言えば、ランタイム層の本質は Agent のオペレーティングシステムとホスト環境です。
最後に：本当の Agent は、ますます「次世代ソフトウェアアーキテクチャ」に近づいている
ここまで読んできたなら、非常に明確な変化に気づくはずです。
以前は AI といえば、多くの場合モデルそのものが語られていました。たとえばパラメータ数、コンテキスト長、推論能力、Benchmark の順位などです。しかし Agent 時代に入ると、問題は完全に変わり始めています。システム能力を本当に決めるのは、もはや「モデルが十分強いか」だけではなく、エンジニアリング全体がどれだけ整っているかです。
真に成熟した Agent システムの背後には、実際には従来のソフトウェアアーキテクチャにますます似たものがあります。そこには独自の CPU、すなわちオーケストレーション・ループがあり、独自のメモリ管理、すなわちコンテキストシステムがあり、独自の長期ストレージ、すなわちメモリシステムがあります。さらに、プロトコル層、状態復元システム、安全コア、実行環境、継続的評価体系まで備えています。
言い換えれば、Agent はもはや単なる「LLM 呼び出し」ではありません。ゆっくりと、新しいソフトウェア形態へ進化しているのです。だからこそ、多くのチームは最初に Agent を作るとき非常に苦しみます。もともとは、Agent とは「Prompt + Tools」にすぎないと思っていたのに、実際に本番投入して初めて、真に難しいのはモデルに質問へ答えさせることではないと気づくからです。難しいのは次のことです。
- システムを長期的に安定稼働させること
- 状態を中断させないこと
- 無限ループを避けること
- ツール権限を制御すること
- コンテキストをガバナンスすること
- 安全監査を行うこと
- オンライン評価を行うこと
- 継続的に改善すること
これらの問題は、もはや AI の問題というより、「ソフトウェア工学の問題」にますます近づいています。
そのため、将来の本当の競争は「誰がより良い Prompt を書けるか」ではなく、「誰が Agent の基盤インフラ全体を本当にエンジニアリングできるか」になる可能性が高いです。なぜなら、この12モジュールが本当に安定して協調して初めて、Agent はデモから、実際に本番投入可能で、拡張可能で、保守可能で、継続進化可能な本番システムへと変わるからです。そしてこれこそが、AI Agent がソフトウェア業界を本当に変え始める地点なのかもしれません。
(Translated by GPT)
元のリンク：https://mp.weixin.qq.com/s/cgWAJ8whcH0rDsgWBExz9g?token=639931501&lang=zh_CN&wt.mc_id=MVP_325642