LLMエージェントの設計図：本番運用に必要な構成と責任分担

AIエージェントを設計するなら、まずは案件を調査し、対応を提案し、承認を待てる単一のLLMエージェントから始めましょう。モデルや標準的なインフラには既存サービスを使い、自分たちで実装するのは業務ルール、権限の境界、そして業務が正しく完了したことを示す仕組みです。

サポートエージェントは、顧客の問い合わせを適切なアカウント、ポリシー、対応に結び付けられて初めて役に立ちます。さらに、その周囲のアプリケーションがアクセス先を説明でき、権限のない変更を防ぎ、ツールの失敗から復旧できれば、安心して運用できるようになります。

システム全体を交通網に置き換えると、関係が見えてきます。モデルが経路を選び、ツールが目的地に接続し、メモリが移動の経緯を保持し、オーケストレーションが運行を管理します。ガードレールと承認ゲートは立ち入りを制御し、評価とログは乗客が正しい目的地に着いたかを確認する役割です。

以下の構成要素の説明は、2026年10月25日にAnthropic、OpenAI、Google Cloudの資料とModel Context Protocolの仕様に照らして確認したものです。サポート業務のフローは設計例であり、実際の顧客環境に導入されたシステムについて述べたものではありません。

LLMエージェントの設計で、システムが担う責任とは

アーキテクチャを設計するということは、モデルが選んでよいことと、アプリケーションが必ず守らせることを決める作業です。この境界は、フレームワークの名前よりも重要です。

出発点として参考になるのが、Anthropicのいう**拡張LLM（augmented LLM）**です。言語モデルに検索、ツール、メモリを接続した構成を指します。同社のガイドは、コードで経路を定めるワークフローと、次の行動を動的に選ぶエージェントを区別し、タスクに必要な場合にだけ複雑さを加えるよう勧めています。Anthropicのエージェント設計ガイド

サポートの一次対応なら、トラブルシューティングのガイドを検索するか、注文を確認するかはモデルが判断してもよいでしょう。それでも、どの顧客の記録を閲覧できるのか、提案した返金が認められるのか、途中で実行が止まったらどうするのかは、アプリケーションのコードで決める必要があります。

手順が決まっている仕事は、そのまま確実に処理しましょう。アカウントの認証、利用権限の確認、完了した操作の記録に、エージェントの臨機応変な判断は必要ありません。モデルに任せるのは、問い合わせを理解し、関連する根拠を選び、役立つ次の対応を提案するという、不確実性のある部分です。

AIエージェントの仕組みを構成図で理解する

エージェントには、永続的な状態管理と各種チェックに支えられた、制御可能なループが必要です。以下に示す層は責任の区分であり、それぞれに別のサービスや契約が必要という意味ではありません。

接続関係はループとして捉えてください。アプリケーションがコンテキストを組み立て、モデルが操作を要求し、ランタイムが検証して実行します。その結果が、次の判断に使うコンテキストになります。このサイクルと停止条件は、エージェントループの解説で詳しく扱っています。

モデル：案件を読み解き、次の操作を提案する

エージェントのワークフローを構築するライブラリであるOpenAI Agents SDKは、モデル、指示、ツールをAgentにまとめます。モデルは問い合わせを読み取り、次に何をすべきかを提案します。この設計例では、アカウントにアクセスできないという問題を受け取り、返信を作成する前に、該当する利用権限の記録を要求します。モデルの選定には、代表的なサポート案件による評価を使いましょう。文章が流暢でも、正しいツールを選べることや、操作する権限があることの証明にはならないからです。OpenAIのエージェント定義

ツールとMCP：業務システムに接続する

Model Context Protocol（MCP）は、AIアプリケーションと外部の機能をつなぐ標準インターフェースです。名前とinputSchemaを持つツール、tools/listによるツールの検出、tools/callによる呼び出しを定義しています。アカウント照会機能は、MCP経由でも、業務APIを呼ぶ通常の関数でも公開できます。どちらの場合も、接続先のサービスで引数を検証し、適切なアカウントへのアクセスだけを認める必要があります。MCPが標準化するのは接続方法です。プロトコルと信頼境界については、MCPの解説を参照してください。MCPのツール仕様

メモリ：必要なコンテキストを適切に保持する

Googleのエージェント構築フレームワークであるAgent Development Kit（ADK）は、やり取りの中で使う情報をSessionとstateで扱い、Memory Bankなどのコンポーネントでセッションをまたぐメモリを支えます。サポート業務では、現在の案件と承認待ちの状態をアプリケーションのストレージに保存し、最新のアカウント情報は元のシステムから取得します。顧客の好みは、保持が適切な場合にだけ残しましょう。これらはそれぞれ別の役割です。コンテキスト、セッションの保存、長期的なメモリの違いは、エージェントのメモリに関する解説で説明しています。Google Cloudのアーキテクチャガイド

オーケストレーション：進行、一時停止、復旧を管理する

OpenAIのエージェント構築ガイドでは、Agents SDKがツールのループ、ハンドオフ、ガードレールを処理すると説明しています。アプリケーションはこれを、モデルの判断で進む処理を実行するランナーとして利用できます。その周囲では、案件が調査中、レビュー待ち、実行中、完了のどの状態にあるかを永続化しましょう。そうすれば、プロセスの再起動後も案件を復旧できます。エージェントの実行を、より長い業務プロセスの中にどう位置付けるかは、オーケストレーションの解説で扱っています。OpenAIのエージェント構築ガイド

ガードレールと人による承認：操作の影響を制御する

OpenAI Agents SDKは、自動で行うガードレールの検査と、ツール呼び出しを一時停止して再開可能な状態を返す承認待ちの中断を、別の仕組みとして扱います。サポートエージェントでは、アカウントへのアクセスと提案された引数を自動で検証したうえで、影響の大きい変更には、実行前に権限のある担当者の承認を求めます。制御は、実際に操作を行うツールの直近に置きましょう。検査の詳細は、ガードレールの解説を参照してください。OpenAIのガードレールと人によるレビュー

評価とオブザーバビリティ：何が起き、適切だったかを確かめる

OpenAI Agents SDKのトレーシングは、モデル呼び出し、ツール呼び出し、ハンドオフ、ガードレールの動作を記録します。一方、トレースの採点に関するガイドは、明示した基準に照らしてワークフローの振る舞いを評価する方法を説明しています。オブザーバビリティは問い合わせへの対応がどう進んだかを示し、評価は、正しいアカウントを選んだか、ポリシーに従ったか、根拠のある回答を作成したかを確かめます。LLMオブザーバビリティツールを比較する前に、何を収集し、どれだけ保持するかを明確にしましょう。SDKのトレーシング、エージェントの評価

Google Cloudのリファレンスアーキテクチャは、ADK、Cloud Run、モデルへのアクセス、MCP接続、Model Armor、オブザーバビリティを組み合わせ、具体的なデプロイ構成を示しています。ただし、掲載例ではメモリとセッションストレージを図から省いていると明記されています。案件の状態を永続化する方法は、含まれているはずだと考えず、設計上の判断として決める必要があります。リファレンスアーキテクチャ

問い合わせの受付から解決の返信まで

エージェントに任せるのは、範囲が明確で、完了を確認できる案件にしましょう。ここでは、料金を支払ったのにサービスを利用できないという顧客の問い合わせを例にします。エージェントは調査と修正案の準備を担当し、導入初期は、アカウントの変更と送信する返信をサポート責任者が承認します。

以下のツール名は、自分たちで実装するアプリケーションの関数を表しています。ベンダーが提供する既製のサポート連携機能ではありません。

1. 1

   案件を受け付け、本人を確認する

   サポートシステムから送られるイベントであるチケットのWebhookを受け、チケットの外部識別子を使って案件を作成または再開します。顧客の認証には既存のアカウント認証フローを使ってください。本文に入力されたメールアドレスだけで、アカウントへのアクセスを認めてはいけません。受信したメッセージは、信頼できるとは限らない顧客由来のコンテンツとして保存します。

2. 2

   用途を絞ったツールで根拠を集める

   エージェントには、get_account_entitlementやsearch_support_policyなどの機能を与えます。アプリケーションのコードで、アクセスできるアカウントを認証済みの本人情報に結び付け、該当する記録とポリシーの参照先を返します。モデルはデータベースに無制限にアクセスすることなく、どの根拠を要求するかを選べます。

3. 3

   根拠に基づく対応案を作る

   モデルは顧客の申告を、アカウントの記録と適用されるポリシーに照らし合わせます。利用権限の修正を裏付ける根拠があれば、変更案と返信案を作成します。根拠が不足していたり矛盾していたりする場合は、追加確認を求めるか、担当者に引き継ぎます。レビューする人が判断の根拠を確認できるよう、参照した資料を提案と一緒に保存します。

4. 4

   業務上の操作を実行する前に停止する

   提案された操作がポリシーに沿うかを検証し、保留中の操作と承認の状態を保存します。サポート責任者には、対象アカウント、具体的な変更内容、裏付けとなる根拠、顧客向けの返信を提示します。却下された場合は書き込みを引き続き禁止し、修正または手動対応のために案件を差し戻します。

5. 5

   実行し、結果を確認する

   承認後、アカウントと提案がレビュー時の内容と一致しているかを再確認してから、修正ツールを呼び出します。接続先のサービスが対応していれば、リトライ時に同じ操作が重複して適用されるのを防ぐ識別子である冪等性キーを使います。アクセスを復旧したと返信する前に、変更後の利用権限を確認してください。返信の送信結果を記録してから、案件を完了扱いにします。

6. 6

   対応結果を評価に使える記録にする

   実行結果、承認済みの返信、案件の最終状態をトレースにひも付けます。タイムアウトを成功とも失敗とも決めつけず、結果が不明な場合は人に引き継ぎます。レビューで誤りが見つかったら、機密情報などを適切にマスキングした事例を評価セットに保存します。

特に注意が必要なのは、書き込みの成否が分からなくなるケースです。アプリケーションが応答を受け取れなくても、アカウントサービス側では変更が適用されているかもしれません。再試行する前に、元のシステムと照合してください。会話ログに「アクセスを復旧します」と書かれていても、それは実行する意思の記録であり、実際にアクセスが変わった証拠ではありません。

エージェントを増やすべき場面と設計パターン

タスクに適用するポリシー、使うツール、責任を持つ担当が一貫している間は、単一のエージェントで進めましょう。役割を分ける必要が明確になったら専門エージェントを追加し、連携の負担が増えても改善効果が残るかを検証します。

OpenAIは、専門エージェントが会話を引き継ぐハンドオフと、主担当のエージェントが返信の責任を持ったまま専門エージェントを呼び出す**ツールとしてのエージェント（agents as tools）**を区別しています。同社のガイドは、指示、機能、ポリシーに実質的な違いがある場合に分割を勧めています。オーケストレーションとハンドオフ

サポート案件で、ヘルプ記事の検索と返信の作成を行うからといって、それぞれを別のエージェントにする必要はありません。一方、請求への異議申し立てなら、別のポリシー、利用を制限した財務関連ツール、別のレビュー担当者が必要になる可能性があります。サポートエージェントが案件の責任を持ち、範囲を限定した判断だけを専門エージェントに任せる方法もあれば、請求業務のフローが主導すべき場合に、担当責任を明示的に引き継ぐ方法もあります。

マルチエージェントの構成図：責任の境界で分ける

ポリシーの違いは分割を考える有用なきっかけですが、必須条件ではありません。独立した根拠収集タスクも、並列に処理するエージェントを設ける理由になります。ただし、最終責任を持つ側が矛盾する結果を突き合わせられ、観測された効果がモデルの追加処理に見合うことが条件です。

専門エージェントを追加する前に、何の失敗を解消したいのかを書き出しましょう。ツールの選択ミス、指示の矛盾、過剰なコンテキスト、専門知識の不足などです。失敗例も含め、同じ案件で新しい設計と比較してください。遅延、使用量、デバッグ、レビューの負担が増えても、それに見合う改善がある場合にだけ採用します。これは判断基準であり、性能向上を約束するものではありません。

エージェントに「調査担当」「批評担当」「管理担当」と名前を付けても、それぞれが独立して判断できるとは限りません。同じ誤った根拠を共有していれば、全員の意見が一致しても、誤りを繰り返しているだけかもしれません。より広い分類については、AIエージェントの種類を整理したガイドを参照してください。

AIエージェントの構築で、購入するものと自分たちで担うもの

代替可能な基盤には既存の製品やサービスを使い、業務上の約束を守る責任は自分たちで持ちましょう。初めて本番用のエージェントを作る際に、コンポーネントを自作する最も有力な理由は、必要な動作を既存のコンポーネントでは表現できない、または外部に公開できないことです。

創業者の方へ： 実際の業務フロー、承認の境界、根拠のエクスポートに対応しているなら、マネージドのエージェント製品を購入する選択肢があります。アカウントごとのポリシーや連携の動作が差別化要因になるなら、標準コンポーネントを使って構築しましょう。デモが説得力に富んでいても、一時停止した案件を復旧できなかったり、失敗した操作を調べられなかったりするなら不十分です。

CTOと開発者の方へ： 業務ツールは用途を絞り、モデルとは独立してテストできるようにしてください。マネージドランタイムはアプリケーションを動かせますが、返金を求める顧客と、返金する権限を持つ従業員の違いを推測してはくれません。その区別は、実際の操作を行うサービスで定義します。

業務運用の責任者の方へ： 例外対応のキューと、何をもって解決とするかの定義に責任を持ちましょう。未解決の案件を誰が引き継ぐのか、どの根拠を渡すのか、いつチケットを閉じてよいのかを定めます。承認待ちの受信箱が放置されているなら、その業務フローは完成していません。

このサポートエージェントに、コード実行は必須ではありません。後から生成コードの実行が必要になった場合は、隔離環境をどう設計するかを別途判断し、エージェント用コードサンドボックスのガイドを活用してください。アカウントを照会するだけのために、汎用シェルを導入する必要はありません。

承認はどこに置き、何を最初からログに残すべきか

委ねられた権限を使う操作の直前に、承認を置きましょう。アカウントが変更された後でエージェントの文章をレビューしても、その変更を防ぐことはできません。

OpenAIの承認機構は、一時停止した実行と、再開可能な状態を返します。アプリケーションが保留中の判断を確定し、実行を再開します。同じドキュメントには、エージェント単位の入力・出力検査が、途中のすべてのツール呼び出しを前後から検査するわけではないという注意もあります。操作を実行する境界に、独自の検証が必要なのはそのためです。承認のライフサイクルとワークフローの境界

この導入例では、レビュー担当者が、具体的なアカウント変更と返信を一緒に確認します。レビュー後に操作、宛先、根拠が変わったら、改めて判断を求めてください。誰が何を承認したか、どのポリシーが適用されたか、実行内容が承認と一致したかを保存します。

ログに何を記録するかは、次の項目を出発点にしてください。トレースは案件内のイベントをひとつにつなぎ、スパンはその中の個別の処理を記録します。

• 案件の識別情報： 案件ID、トレースID、起点となったイベント、認証済みアカウントへの参照を記録します。顧客の詳細情報をあちこちに複製せず、参照を使いましょう。
• 設定： プロバイダーが返したモデルID、指示のバージョン、ツールスキーマのバージョン、ポリシーのバージョンを記録します。これらは、当時どの動作設定が有効だったかを説明する情報です。
• 根拠： 取得した文書のID、該当する改訂版、アクセス範囲を記録します。個人情報や機密情報を含む記録を無差別にコピーせず、何が判断を支えたかを残します。
• 操作： ツール名、機密情報をマスキングした引数、タイムスタンプ、所要時間、結果の状態、再試行または冪等性の識別子を記録します。提案された操作と完了した操作を区別できる情報を残してください。
• 判断： 検証結果、エスカレーションの理由、承認状況、レビュー担当者への参照、承認された提案を記録します。
• 結果と使用量： チケットの最終状態、確認済みの変更や外部への影響、配信結果、プロバイダーが報告する使用量、評価ラベルを記録します。サポートシステムから取得できるなら、顧客による訂正や再開された案件も追跡します。

これはアプリケーションに推奨する記録項目であり、SDKがすべてを自動収集するという意味ではありません。アクセスを制限し、保持期間を定め、エクスポート前に秘密情報をマスキングしてください。モデル内部の非公開の推論過程をログの必須項目にする必要はありません。監査証跡は、観測可能な入力、出力、操作、根拠によって成り立つようにします。

本当に重要な制約と、過大評価されがちなこと

最も重要な制約は、どこまでの権限を委ねるかです。実行時間、ツールの動作、リソース使用量に明確な上限を設け、エスカレーション先も定めましょう。上限値は、デモの適当な値を借りるのではなく、自分たちのワークロードとサービス要件に基づいて決めます。

メモリは、正しい情報を保証するものではありません。 保存された会話には顧客が利用できると書かれていても、アカウントシステムの記録が異なるなら、現在の正式な記録に照らして食い違いを調べてください。記憶する文章を増やしても、古い根拠は正しくなりません。

MCPは、権限を付与する仕組みではありません。 ツール仕様では、アクセス制御と入力検証が引き続き求められます。広範な操作を公開するコネクタには、独自APIと同じように、業務上の認可のレビューが必要です。MCPのセキュリティ要件

実行が完了しても、案件が正しく解決したとは限りません。 正しいアカウントを変更したか、ポリシーに従ったか、返信が実際の結果と一致しているかを評価してください。OpenAIの評価ガイドは、トレースの確認から、繰り返し使えるデータセットでの評価へ進む方法を示しています。これにより、変更の良し悪しを一貫した基準で判断できます。エージェントのワークフロー評価

エージェントを増やしても、責任者は必要です。 最終回答、共有する根拠、未解決の例外には、誰かが責任を持たなければなりません。専門エージェントが役立つのは、異なる責任を担うからです。構成図を高度に見せるためではありません。

エージェント設計についてよくある質問

AIエージェントのアーキテクチャとは何ですか？

AIエージェントのアーキテクチャとは、アプリケーションがタスクを進められるように、モデルの判断、ツール、メモリ、オーケストレーション、制御、評価を組み合わせた構成です。業務用エージェントでは、誰が操作を承認できるか、完了をどう確認するかも、この設計で決まります。

AIエージェントとは、どのようなものですか？

AIエージェントは、モデルを使って目標に向けた行動を選び、その結果を観測し、次にどう進むかを判断します。実用上の自律性は、アプリケーションが与えるツール、権限、停止ルールの範囲に限られます。

エージェントのアーキテクチャには、どのような種類がありますか？

実務では、あらかじめ手順を定めたワークフロー、複数のツールから選択する単一エージェント、専門エージェント同士の連携に分けて考えると役立ちます。どれが適切かは、タスクの予測可能性と、責任の違いに応じてツール、ポリシー、担当を分ける必要があるかによります。これは実装パターンの整理であり、普遍的な分類ではありません。

最初に取り組むこと：技術を選ぶ前に案件の流れを描く

繰り返し発生するサポートの問い合わせがあり、元の記録にアクセスでき、例外対応の責任者がいるなら、設計を始められます。代表的な案件を選び、起点となるイベント、許可する読み取り、提案する書き込み、承認を置く場所、完了に必要な根拠を書き出しましょう。最初は下書きをレビューする運用で動かし、実際に起きた失敗を基に、責任を持って拡大できる権限を判断します。

アカウントの本人確認、ポリシーの管理責任、完了を裏付ける証拠が未整理なら、自律的な実行は待ちましょう。その前提を整える間も、検索や下書きの品質は改善できます。すでに信頼できる確定的なルールで業務が回り、モデルの判断が必要ないなら、その自動化を維持してください。

最初の成果物は、受付から結果までを説明できる案件にしましょう。承認が却下されたときや、ツールの実行結果が不明なときの動きも、そこに含めます。

AIシステムの構築と運用に役立つ実践的なガイドは、ニュースレターに登録してお受け取りください。