0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@cvusk

AIエージェントはどこで動かすべきか ― 配置行列・重力モデル・三面アーキテクチャによる設計指針 ―

0
Posted at

概要

「AIエージェントをどこで動かすか」という問いは、ローカル、マネージドサービス、クラウドでの自前構築、SaaS内蔵という4つの選択肢として語られがちです。

しかし、エージェントは一枚岩ではありません。複数の構成要素に分解でき、それぞれを異なる場所に配置できます。

本稿では、次の5つの主張を軸に、この問いに対する設計指針を示します。

  1. 配置とは、「構成要素 × 配置先」の行列を設計することです。
  2. 配置を最も強く決めるのは、データの所在ではなく、ツールと認証情報の所在です。
  3. 制御面・実行面・能力面の三面モデルで構成し、「計算は使い捨て、記憶は永続」を原則とします。
  4. 分離レベルはエージェント単位ではなく、ツール（ステップ）単位で決めます。
  5. 容量とコストの単位はトークンであり、プロンプトキャッシュが配置と運用を左右します。

1. 問いの再定義：4択では議論が粗くなる

実運用では、次のような、一見すると矛盾する要求が同時に存在します。

  • データは外部に出せないが、フロンティアモデルは使いたい
  • 運用は任せたいが、副作用のあるツールは社内境界で実行したい
  • 開発は手元で行いたいが、本番と同じツール群に接続したい

こうした要求は、「エージェント全体をどこに置くか」という問いだけでは解決できません。

エージェントを次の6つの構成要素に分解し、それぞれについて配置先を選ぶことで、初めて要件を整合させられます。

記号 構成要素 配置を決める主な要因
A 推論（LLM） データ持ち出しの可否、コスト
B 制御ループ 耐久性（長時間実行）、可観測性
C ツール実行面 副作用の到達範囲、認証情報の所在
D 状態・メモリ 永続性、データレジデンシー
E サンドボックス 爆発半径、起動速度
F アイデンティティ 最小権限、監査

たとえば「業務自動化エージェント」であれば、Aは外部LLM API、Bはマネージドサービス、CとEは社内VPC、Dはマネージドストア、Fはサービスアカウントと短命トークン、という配置が考えられます。

ローカル、マネージド、自前クラウド、SaaS内蔵という4つの選択肢は、この行列において「すべての行を同じ列にそろえた」特殊解にすぎません。

2. 配置を決める力学：配置は認証情報に従う

データベース設計における「データ重力」の類推から、各構成要素を特定の配置先へ引き寄せる力を、次の5つに整理できます。

重力 引かれる先 影響する要素
ツール・認証情報重力 クレデンシャルが存在する境界内 C, E, F
データ重力 データの保管場所 A, D
キャッシュ重力 同一のプロバイダ・リージョン・レプリカ A, B
人間重力 Slack、IDEなど、人がいる場所 B, D
規制重力 指定リージョン、監査可能な基盤 A, D, F

本稿の中心的な主張は、最も強い重力はデータ重力ではなく、ツール・認証情報重力であるというものです。

エージェントは、単に情報を「読む」だけではなく、「行動する」システムです。そして、行動には認証情報が必要です。

長期間有効なシークレットをセキュリティ境界の外へ持ち出すべきではないため、ツール実行面は、原則として認証情報が存在する境界内に置かざるを得ません。

一方、推論については、データにマスキングや要約を施すことで、境界の外へ出せる場合があります。

この原則から、

推論は外部API、行動は社内境界内

という分離が自然に導かれます。

また、SaaS内蔵エージェントも、「そのSaaSの認証情報を持つ唯一の場所」と考えれば、合理的に位置づけられます。

3. アーキテクチャ：三面モデル

KubernetesにおけるControl PlaneとData Planeの分離をAIエージェントに応用し、アーキテクチャを3つの面で構成します。

面 性質 推奨する配置先
制御面 長寿命、少数、耐久実行が必要 マネージド。自前の場合もTemporalなどの耐久実行基盤の上に置く
実行面 短命、多数、使い捨て ツールと認証情報の近く（VPC内、SaaS内）。開発時はローカル
能力面 外部サービス MCP／A2Aで接続し、契約テストとSLOで管理

この構成を支える原則は2つあります。

計算は使い捨て、記憶は永続

実行面はセッションごとに新しく作り、状態は制御面へ1ステップごとにチェックポイントします。

これにより、実行面をどこに配置しても差し替えられます。また、人間の承認を待っている間は実行面を停止し、計算コストをゼロにできます。

MCPゲートウェイをポリシー実施点にする

すべてのツール呼び出しを単一のゲートウェイに通し、そこで次の処理を行います。

  • 認可
  • 引数検証
  • 短命トークンの注入
  • 監査

エージェント本体は、認証情報を一切持ちません。

「2がオーケストレーター、2・3・4がワーカー」というマルチエージェント構成も、ローカルからMCPで接続する構成も、このゲートウェイを経由させることで、同じ統制下に置けます。

4. 分離レベル：ツール単位で決める

自前構築において「どのレベルで分離するか」は、エージェントの属性の関数として決めます。

レベル 手段 適用例
L0 同一プロセス内 読み取り専用の分類・要約
L1 コンテナ 内部ツールのみ、社内データのみ
L2 microVM（Firecracker、gVisor） 任意コード実行、Web閲覧
L3 専用VM・専用アカウント 本番インフラ操作、決済
L4 物理・ネットワーク分離 規制産業、極めて機微なデータ

必要なレベルは、自律度 $A$、権限の強さ $P$、信頼できない入力への曝露 $X$、不可逆性 $I$ をそれぞれ0〜2で表し、その重み付き平均によって近似できます。

副作用側を重く評価し、次のように設定します。

$$
w_P = w_I = 2,\quad w_A = w_X = 1
$$

分離レベル $L$ は、次の式で近似できます。

$$
L =
\left\lceil
\frac{A + 2P + X + 2I}{6} \cdot 2
\right\rceil
$$

重要なのは、同じエージェントであっても、ツールごとに分離レベルを変えることです。

たとえば、

  • 計画：L0
  • コード実行：L2
  • デプロイ：L3

のように、ゲートウェイがツール種別に応じて適切な実行面へディスパッチします。

さらに、エラーバジェットの類推として「爆発半径バジェット」を定義します。

たとえば、

  • 削除可能な範囲
  • 1日の支出上限
  • 送信可能な宛先

などです。

これらの制約をゲートウェイで強制します。

プロンプトインジェクションは防ぎ切れないことを前提とし、防御を入力側ではなく、副作用側に置くことが、この設計の要点です。

5. インフラ性能：単位はトークン

LLMが外部APIである場合、エージェント本体はI/Oバウンドであり、待ち時間が支配的な長寿命ワークフローになります。

CPU使用量はほぼ無視できる一方、次の要素が重要になります。

  • 同時セッション数に比例するメモリ
  • サンドボックスのI/O
  • 多数のストリーミング接続を処理するネットワーク

5.1 レイテンシとコストはステップ数で増幅

1セッションあたりのステップ数を $S$ とします。

LLMの初動遅延も、ツールとの往復時間も、基本的には $S$ 倍に増幅されます。$S=100$ であれば、ローカルMCPとリモートMCPのわずかなレイテンシ差でも、セッション全体では数十秒の差になります。

これが、ツールを実行面と同居させるべき理由です。

さらに、コンテキストがステップごとに線形に増加すると、総入力トークン数はおおよそ次のようになります。

$$
\mathrm{Tok}_{\mathrm{in}}
\approx
S C_0 + \frac{S^2 \Delta}{2}
$$

つまり、総入力トークン数はステップ数の2乗で増加します。

この2乗項を打ち消すうえで重要になるのが、プロンプトキャッシュです。

容量計画は「リクエスト数」ではなく、

セッション到着率 × セッションあたりトークン数

で考え、プロバイダのTPM上限と比較します。

また、セッションごとのトークン予算をSLO兼キルスイッチとして設定すれば、暴走ループの検知にも利用できます。

5.2 プロンプトキャッシュが配置と運用を制約

プロンプトキャッシュはプレフィックス一致によって効果を発揮するため、コンテキストは次の順序で並べます。

  1. 静的：システムプロンプト、ツール定義
  2. 準静的：メモリ
  3. 動的：会話

たとえば、コンテキストの先頭にタイムスタンプを入れるだけで、その後ろにあるキャッシュ全体が無効化される可能性があります。

また、キャッシュはプロバイダ、リージョン、そして自前推論の場合はレプリカに束縛されます。

そのため、フェイルオーバーはキャッシュの喪失を意味します。

切り替えはセッション境界で行い、自前推論ではセッションアフィニティを持つルーティングが必須です。

人間の承認待ちでは、TTLとの損益分岐も生じます。

TTLを $T$、キャッシュの書き込み単価と読み取り単価の比を $p_{\mathrm{write}} / p_{\mathrm{read}}$ とすると、キャッシュを維持し続けるほうが有利な待ち時間の上限は、次のように近似できます。

$$
W^{*}
\approx
T \cdot
\frac{p_{\mathrm{write}}}{p_{\mathrm{read}}}
$$

たとえば、$T=5$ 分、単価比が12.5であれば約60分となります。

したがって、承認待ちが1時間以内ならキープアライブし、それ以上なら一度落として再構築するほうが合理的です。

ただし、実際の単価はプロバイダごとに確認する必要があります。

5.3 ローカルLLMは「推論をどこで動かすか」問題

自前推論へ切り替えると、性能プロファイルはGPUバウンドへと反転します。

その場合、主な課題は次のようになります。

  • vLLMやSGLangの運用
  • KVキャッシュメモリ
  • モデル配布

自前推論が妥当なのは、主に次の2つの場合です。

  1. データを外部へ出せない場合
  2. 高頻度・低難易度のステップを小型モデルへ振り分けるハイブリッド・ルーティングによって、コストを下げたい場合

6. 運用：AgentOpsの3つの柱

6.1 エージェントBOMで固定

エージェントの挙動は、次の要素の組み合わせによって決まります。

  • モデルのスナップショット
  • プロンプト
  • ツール定義
  • SDK
  • ポリシー
  • 評価セット

これらを1つのロックファイルとして固定し、その変更単位でデプロイとロールバックを行います。

モデルは必ず日付付きスナップショットへ固定し、本番環境で「自動的に最新」を使いません。

6.2 モデル移行は記録・再生とセッション単位カナリアで行う

ゲートウェイですべてのツール呼び出しを記録しておけば、テスト時にはツールをモックとして再生し、LLMだけを差し替えて軌跡を比較できます。

カナリアリリースでは、リクエスト単位ではなくセッション単位で割り当てます。

セッション途中でモデルを変更すると、コンテキストや挙動の一貫性が崩れる可能性があるためです。

6.3 テストは予測的評価選択でコストを抑制

エージェントのテストは、次のピラミッドで構成します。

ユニット
↓
記録再生によるコンポーネントテスト
↓
実LLMによる軌跡評価
↓
E2E

LLMには非決定性があるため、1つのテストケースを複数回実行し、合格率で判定します。

一方、軌跡評価はトークン費用が高く、すべてのケースを変更のたびに実行することは現実的ではありません。

そこでPredictive Test Selection [8] の発想を転用します。

変更差分、たとえば、

  • プロンプト
  • ツール定義
  • モデル

と、過去の失敗履歴から「壊れそうな評価ケース」だけをPull Request時に実行します。

そのうえで、夜間には全件を実行し、その結果を使って選択モデルを補正します。

CIには専用のAPIキーと予算上限を設定し、サンドボックスにはCI環境でもmicroVMを使って、副作用を構造的に遮断します。

ローカル環境は開発ループの高速化に特化させ、無人運用には使いません。

7. 結論：技術選定手順

AIエージェントの配置を考える際は、次の順序で判断します。

  1. エージェントを6つの構成要素に分解します。
  2. 各要素について5つの重力を評価し、最も強く引かれる先へ配置します。原則として、認証情報のある場所に実行面を置きます。
  3. ツールごとに分離レベルと爆発半径バジェットを決め、ゲートウェイで強制します。
  4. 制御面は耐久実行基盤に置き、マネージドを優先します。実行面は使い捨てサンドボックスとし、能力面はMCP／A2Aで接続された、契約テスト付きの外部サービスとして扱います。
  5. エージェントBOMで構成を固定し、記録・再生とセッション単位カナリアによって移行します。

典型的な進化パスとしては、まずマネージドサービスに制御面を置き、実行面を認証情報のある場所へ配置するところから始めます。

その後、トークン量が増え、キャッシュ局所性やハイブリッド推論による最適化が必要になった段階で、実行面と一部の推論を自前環境へ寄せていきます。

AgentOpsは、現在も各社が手探りで構築している段階にあります。

しかし、本稿で述べた原則は、SRE、DevOps、セキュリティ工学の類推から導けるものであり、最終的にどの配置を選んだとしても、共通して適用できるでしょう。

参考文献

  1. Anthropic. Model Context Protocol Specification.
    https://modelcontextprotocol.io/

  2. Google. Agent2Agent (A2A) Protocol.
    https://github.com/a2aproject/A2A

  3. The Kubernetes Authors. Kubernetes Components.
    https://kubernetes.io/docs/concepts/overview/components/

  4. Agache, A. et al. "Firecracker: Lightweight Virtualization for Serverless Applications." USENIX NSDI 2020.

  5. Temporal Technologies. Temporal Documentation: Durable Execution.
    https://docs.temporal.io/

  6. Kwon, W. et al. "Efficient Memory Management for Large Language Model Serving with PagedAttention." ACM SOSP 2023.（vLLM）

  7. Zheng, L. et al. "SGLang: Efficient Execution of Structured Language Model Programs." NeurIPS 2024.

  8. Machalica, M. et al. "Predictive Test Selection." ICSE-SEIP 2019.

  9. Greshake, K. et al. "Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection." ACM AISec 2023.

  10. OWASP Foundation. OWASP Top 10 for Large Language Model Applications.
    https://owasp.org/www-project-top-10-for-large-language-model-applications/

  11. Rose, S. et al. Zero Trust Architecture. NIST SP 800-207, 2020.

  12. Beyer, B. et al. (eds.) Site Reliability Engineering. O'Reilly, 2016.（エラーバジェット）

  13. OpenTelemetry. Semantic Conventions for Generative AI Systems.
    https://opentelemetry.io/docs/specs/semconv/gen-ai/

  14. NTIA. The Minimum Elements for a Software Bill of Materials (SBOM). 2021.

URLは執筆時点の代表的な公開場所です。公開前に有効性をご確認ください。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?