はじめに
AIエージェントを取り巻く技術は日々進歩し、本番運用を見据えたHowToも見かけるようになった。
実際にAIエージェントの開発に携わり、AIエージェントの勉強会を開催する中で、AIエージェントの定義、開発手法、アーキテクチャや運用を整理したいと思い本記事を執筆した。
1. AIエージェントとは何か
従来のチャットボットとの違いや、AIエージェントが注目されるようになった背景について。
1.1 AIエージェントの定義
AIエージェントの定義は諸説あるが、本記事では「目標達成のため自律的にタスクを実行するAIシステム」とする。
「自律的」ってなんぞや、が上手く表現されているなと思ったのがAnthropicの2024年12月の記事Building effective agentsで、ワークフローとエージェントの対比の中で以下のように表現している。
Workflows are systems where LLMs and tools are orchestrated through predefined code paths.
Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks.(ワークフローとは、LLMとツールが事前に定義されたコードパスを通じて連携して動作するシステムである。一方、エージェントとは、LLMが自身のプロセスとツール使用を動的に指示し、タスクの遂行方法を制御し続けるシステムである。)
AIエージェントの挙動は「考える → 行動する → 結果を観察する → 考える」の繰り返し(ReActフレームワーク)で、上述のAnthropicのエージェント定義は、「自律的」= 行動計画と実行結果に応じた計画の修正をLLMが判断する、という実装を見れば検証可能な形になっている。
(参考) コンピュータサイエンス分野の研究におけるAIエージェントの定義
コンピュータサイエンスの分野においてAIエージェントの概念が生まれたのは1950年代であり、アイデア自体は古くから存在するが、汎用性や自然言語での指示が実現され実用に堪えるものになったのはLLMの能力が向上した2024年頃である。
過去の研究の例として、1995年のMichael Wooldridgeらの論文 "Intelligent Agents: Theory and Practice" [1] ではAIエージェントの定義が以下のように整理されている。
広義の意味: 自律性、社会性、反応性、能動性の4つの性質を持つシステム
(AI研究者が使うような)狭義の意味: 4つの性質に加え、人間のような属性を付与したシステム
広義の意味は現代のAIエージェントのシステム的な枠組みに、狭義の意味はBDIアーキテクチャ(人間の心の動きをモデルにしたAIエージェントの設計思想)に受け継がれている。
1.2 なぜ今AIエージェントが注目されているのか
長年理論にとどまっていたAIエージェントが実用水準に達した背景には、主に3つの進化があると考える。
-
モデル能力向上: 長いタスクを脱線せずに遂行できるモデル(Claude、GPT、Gemini の各最新世代)が登場した。とりわけ「複数ステップにわたって計画を保持し、ツールを正確に呼び分ける」能力が実用水準に達したことが大きい。
この進歩は2023年頃のエージェント(AutoGPT など)との対比で分かりやすい。当時のエージェントは目標達成の判定を自然言語による自己評価に頼っており、判定基準が一貫しないままタスクを繰り返し続け、作業が終わらないという事象が多数報告されていた。
(参考)AutoGPT Planning Failures - Infinite Loops & Resource Depletion (2023)
Yang, Yue, & He (2023) [2]の研究では、 WebShopベンチマークにおいてGPT-4 を使った Auto-GPT 型エージェントの成功率は0.24(24%)にとどまっている。また、性能の低い他モデルの意見を導入することでGPT-4のパフォーマンスが向上したという結果も出ており、当時のモデルは「単独で一貫した方針を保ちながら計画を維持する」能力が低かったことが伺える。
LLMの能力向上は現在のAIエージェントの普及の大きな要因の1つと言えるだろう。
-
標準プロトコルの成立: MCP によってツール接続が標準化され、エコシステムが爆発的に拡大したことで、AIエージェントができることの幅も大きく広がった。(MCPについては§4.1で詳述)
単なる Anthropic 主導の1プロトコルに留まらず、OpenAIやGoogle等競合ベンダーも含めた各企業が自社製品に相次いで採用し「ツールを1つ作れば各社のエージェントから使える」ため、統合コストが劇的に下がった。
2025年12月には MCPが Linux Foundation 傘下の Agentic AI Foundation に移管され、Anthropic・Block・OpenAIが共同設立者、AWS・Google・Microsoft・Cloudflare・Bloombergなどが支援メンバーとして名を連ね、オープンスタンダードとして整備が進められている。
(参考) Zuplo - One Year of MCP
- IDE統合型エージェントの登場: コーディング/開発エージェント(Claude Code、Cursor、Kiro など)など、IDEに統合されたエージェントも登場した。チャットベースでエージェントに指示を出せる取っつきやすさも、間口を広げるのに一役買っていると考えている。
LLM性能の向上、プロトコルの標準化、エージェントを扱いやすいツールの登場、とAIエージェント普及の素地はできている。
PoCを超えて実用化していくために、評価・セキュリティ・運用をどう設計・実装していくかがこれからの課題である。
1.3 混同されがちな概念との違い
| 概念 | 何をするか | LLMが制御フローを決めるか |
|---|---|---|
| チャットボット | 1問1答の対話 | ✕(単発の生成のみ) |
| RAG | 検索結果を文脈に入れて回答 | ✕(検索→生成の固定フロー) |
| ワークフロー(LLMチェーン) | 事前定義された手順でLLMを複数回呼ぶ | ✕(フローは人間が設計) |
| AIエージェント | ゴールに向けてツールを自律的に使う | ◯(LLMが次の行動を決める) |
あらかじめ人間が定めたルートをなぞる「ワークフロー」に対し、状況の変化に応じてLLM自らがルートを選び直しながらゴールを目指すシステムが「AIエージェント」である。
2. AIエージェントのアーキテクチャ
「エージェント」というワードからは実体を捉えづらいが、脳みそ(モデル・メモリ)と手足(ツール)があって、そこに指示を出すというイメージ。ここではエージェントを安全に使うために実行環境・ガードレールも含めた。
2.1 エージェントの構成要素
OpenAIの"A practical guide to building agents"では、エージェントの核となる要素を モデル・指示(Instructions)・ツール の3つとしている。
ここではその3つに加え、エージェント実行時に必要になるメモリと、暴走を防ぐ実行環境・ガードレールを加えた5要素で考える。
エージェントのLLM以外の構成要素を合わせてハーネスと呼ぶこともある。
(1) モデル(頭脳)
ループの各ステップで「次に何をすべきか」を判断する。
エージェント用途では指示追従性・ツール呼び出し精度・長コンテキストでの一貫性が重要。
作業品質とコスト・レイテンシのバランスを取るためにステップによりモデルを使い分けることも検討する。
(例：計画立案や最終レビューなど難易度の高いタスクには高性能モデル、ツール呼び出しなど難易度の低いタスクは軽量・低コストなモデルを充てる)
毎回やることが決まりきったタスクならLLMでなくプログラムで実行したほうが良いケースもある。
(2) 指示(Instructions / システムプロンプト)
「エージェントに何を・どうやってさせるか」を定義するテキスト。
チャットボットであればペルソナや回答のトーンを設定することが多いが、エージェントではそれらに加えて完了の定義、情報が不足・矛盾しているときにどう動くか、人間に承認や質問をするタイミング、といった判断基準を定義してあげることが重要。
| 主観的な判断基準 | 検証可能な判断基準 |
|---|---|
| 「出力が高品質になったら止める」 | 「テストカバレッジが80%を超えたら止める(閾値)」 |
| 「完璧だと感じるまで改善し続ける」 | 「JSONがスキーマ検証を通過したら止める(構造チェック)」 |
| 「十分な情報が集まるまで調査する」 | 「フォームの全項目が埋まったら止める(リスト充足)」 |
最近のモデルだと気が利くというかよしなに完了を判断してくれることも多いけど、
true/falseで判断可能、主観的な推論の余地が無いような条件を与えてあげたほうが安全。
自分がAIエージェントを使って実際にやっている中では、クラウド環境構築時のトラブルシューティング時「エラーを解消して」と丸投げすると袋小路にはまって迷走しながらずっとコマンドを打ちまくることがあるため、「このエラー原因を調べて」等完了条件を調整している。
(3) ツール(手足)
ツールの実体はモデルに見せる関数の説明書のようなもので「名前」「説明文」「入力スキーマ(JSONなど)」の3点セットで構成されている。これがまるごとプロンプトの一部としてモデルに渡される。
MCP が標準化したのは、まさにこの「名前・説明文・スキーマ」であって、MCPサーバを立てるというのは、実質的にはこれらを標準形式で公開することである。
「ツールを与える」とは、裏で新しいコードを注入することではなく、「こういう関数が呼べます」というテキストをコンテキストに追加しているにすぎない。説明文はプロンプトの一部として読まれ、LLMによって使うツールが判断される。
また、LLM自体はツールを「実行」しているのではなく以下のように「要求」している。
- モデルが「このツールをこの引数で呼びたい」という構造化されたテキストを出力する
- それを受け取ったアプリケーションが、実際の処理を実行する
- 実行結果を「ツール結果」として会話履歴に追加する
- モデルはその結果を読んで、次に何をするか再び判断する
(なので戻り値もLLMが読んで判断できる形式である必要がある)
この分離があるからこそ、途中で人間の承認が入るフローで「モデルを止めずに、実行だけを止める」ことができるし、万一にもLLMが暴走したとしても、アプリ側で許可していない操作(API)は実行できないというガードレールが機能する。
ツールは提供元によって3種類に分けられる。
| 種類 | 説明 | 例 |
|---|---|---|
| ビルトインツール | モデル提供元が用意し、提供元のインフラで実行される | Web検索、コード実行サンドボックス |
| カスタム関数ツール | 開発者が自分で定義し、自分のインフラで実行する | 社内API呼び出し、DB更新 |
| MCPツール | 標準プロトコルで外部サーバが公開し、対応するどのエージェントからも呼べる | GitHub操作、Slack投稿 |
(4) メモリ(記憶)
LLM自体は状態を持たず、経過を毎回コンテキストとして与え直している。
エージェントでは、情報をどこに・どれくらいの期間保持するかで3パターンに分けて考えることが多い。
| 種類 | 実現方法 | 用途 |
|---|---|---|
| 短期記憶 | コンテキストウィンドウ | 現在のタスクの経過 |
| 作業記憶 | スクラッチパッド(ファイル/変数) | 中間成果物、TODO管理 |
| 長期記憶 | ベクタDB、ファイル、DB | セッションを越えた知識・ユーザー情報 |
長時間タスクでは短期記憶のコンテキストが溢れるため、コンテキスト圧縮やサブエージェント分割を検討する。
プロジェクトの前提知識などはファイルに切り出しておくとよい。(Claude CodeであればCLAUDE.md)
この分野は「コンテキストエンジニアリング」と呼ばれ、プロンプトエンジニアリングが「何を指示するか」の最適化だったのに対し、コンテキストエンジニアリングは「限られたコンテキストの中で、各ステップに何を見せるか」を最適化するものである。
(5) 実行環境・ガードレール
ツールを実際に実行する環境(コンピューティング、権限制御など)や、暴走を防ぐ仕組み。
ガードレールは単一の仕組みではなく、複数の層を重ねて設計する。
| ガードレールの種類 | 目的 | 具体例 |
|---|---|---|
| 関連性チェック | タスクと無関係な入出力を弾く | オフトピックな指示を無視する |
| 安全性分類 | 有害・危険な要求を検知する | プロンプトインジェクションの検出 |
| PIIフィルタ | 個人情報の漏洩を防ぐ | ログ・出力のマスキング、ログに回答本文を出力しない |
| ルールベース制御 | 決定的な禁止事項を強制する | 特定ツール・APIの呼び出し自体を禁止 |
| 出力検証 | 形式・整合性を機械的にチェックする | JSON スキーマ検証、想定範囲外の値の拒否 |
| 人間の承認(human-in-the-loop) | 不可逆な操作の最終確認をとる | 送信・削除・決済・デプロイ前の承認 |
| リソース上限 | 暴走時の被害を限定する | 最大ステップ数、コスト上限、タイムアウト |
(参考) "A practical guide to building agents"
最近Loop Engineeringという手法(人間は直接AIエージェントに指示を与えるのではなく、AIエージェントがタスクを実行するサイクルを設計する)が登場したが、その名の通りAIがサイクルをずっと回す手法なので、暴走を防ぐガードレールの重要度はさらに上がるだろう。
3. エージェントを作る
前章で整理した5つの構成要素を踏まえ、本章では「実際のエージェントをどう設計し、実装に落とし込んでいくか」の具体像を見る。
最初は単純な構成から始めて、足りなければエージェントやツールを足していくのがおすすめ。
(ただしプログラムやワークフローで対応できるなら無理にエージェントを使う必要はない)
3.1 コードのイメージ
エージェントのミニマルな定義をコードに落とすとこんな感じ。
(llm.call() は特定SDKの実際の構文ではなく、LLMプロバイダのAPI呼び出しを抽象化したもの)
messages = [{"role": "user", "content": task}]
while True: #ループ
response = llm.call(messages, tools=TOOLS) #LLM呼び出し
if response.stop_reason != "tool_use": #レスポンスを見て、完了条件を満たしていたらループを抜ける
break
for tool_call in response.tool_calls:
result = execute(tool_call) # ツール実行
messages.append(tool_result(tool_call.id, result)) #履歴の追加
print(response.text)
上のコードで固定しているのは聞く→動く→また聞くの形だけで、何を、いつはモデルにゆだねられている。(自律的)
こういうのは自律的じゃない
plan = llm.call("このタスクをサブタスクに分解して", output_schema=PLAN_SCHEMA) # 1回だけ呼ぶ
results = [worker_llm.call(subtask) for subtask in plan.subtasks] # 並列実行
summary = llm.call("これらの結果を統合して", results) # 1回だけ呼ぶ
3.2 標準プロトコル ― MCP と A2A
エージェント連携のプロトコルはMCP(エージェント - ツール) と A2A(エージェント同士) の2つに大別される。
MCP
有名どころのサービスはMCPサーバを公開していることが多いので、活用すると自前で統合コードを書かずにサービス連携ができる。
ツールの説明文はプロンプトの一部として読まれるため、悪意を持った説明文が仕込まれるツールポイズニング、トークンの消費量増加には注意。
MCPに限った話ではないが、なんでもかんでも繋ぐのは考え物。
自前のサービスやツールをエージェントから使わせたいときも、MCPサーバとして1つ公開すれば、エージェントフレームワークごとに何本も作らなくてよくなる。
1つのエージェント内で完結する単純なツール(自分だけが使うシェルスクリプトなど)程度であれば、MCPサーバ化せず関数としてツールを直接定義してもよい。
A2A
エージェント連携時、信頼境界を超える(認証・認可を経る)場合に使用する。
例えば自社のカスタマーサポートエージェントが、決済処理は別チーム(あるいは別会社)が運用する専門エージェントに委譲したいケースがあったとする。この場合認証・認可が必要になる。
A2Aでは相手のエージェントが何をどこまでできるかを Agent Card(エージェントの能力を記述した署名付きのメタデータ)で事前に確認し、認証・認可を経てタスクを渡す。
逆に1つのアプリケーションが管理する範囲でエージェント同士が連携するのであれば、フレームワーク内部の委譲機構で実現できる。
A2AではAgent Cardでのなりすましや誇張によって偽エージェントにタスクを渡させる攻撃が考えられるため、Agent Cardの身元や内容の検証はユーザ側で作りこむ必要がある。
3.3 シングルエージェントとマルチエージェント
単体or複数のエージェントで構成するか、複数体にする場合はどう連携させるかでバリエーションがある。
| パターン | 内容 | 適する場面 |
|---|---|---|
| シングルエージェント | 1つのモデルがツール群を持ち、ゴールに向けて自分でツールを選び続ける | 最初はこの構成を試す |
| サブエージェント(階層型マルチエージェント) | オーケストレータが専門エージェントに委譲する | コンテキストを分離したい調査系タスク |
| 対話型マルチエージェント | エージェント同士が議論・批評し合う | 複数の観点からのレビューやブレストなど |
複数のエージェントを組み合わせるマルチエージェント構成を取ることで作業を並列化したり、スキルセットが大きく異なるエージェントをループの中に組み込んだりすることができる。一方、トークン消費量が嵩みがち、エージェント間の情報伝達時のロスなどデメリットもある。
シングルエージェントで事足りるなら、無理にマルチエージェント構成にする必要は無い。
Anthropicの"Building Effective Agents"では、以下のように述べられている。
Start with simple prompts, optimize them with comprehensive evaluation, and add multi-step agentic systems only when simpler solutions fall short.
(最初は単純なプロンプトから始めて、不十分なときのみマルチステップのエージェントシステムを追加しましょう)
3.4 エージェントオーケストレーションのフレームワーク
主要フレームワークの特徴(設計思想・得意領域)は以下の通り。
(学習コストは、フレームワークを構成している概念・機能の量と理解難易度を主観かつ相対的に判断したもの)
| フレームワーク | 提供元 | 対応言語 | 特徴 | 得意領域 | 学習コスト |
|---|---|---|---|---|---|
| AG2（旧AutoGenのコミュニティ後継） | コミュニティ（Apache 2.0） | Python | イベント駆動のアクターモデル(メッセージをトリガとしてエージェントが並行して自律駆動する) | 複数エージェントによる議論、自律的なコード実行・修正ループ | 高 (非同期イベントの設計や、会話制御のプロンプト調整の難易度が高い) |
| Claude Agent SDK | Anthropic | Python / TypeScript | Claude Codeと同一のハーネスをSDKとして提供、bashやファイルシステムをツールとして利用 | 長時間のコーディングタスク、コンピュータ操作 | 中 (コードはシンプル、学ぶべき概念の数が多め) |
| CrewAI | CrewAI | Python | 決定論的Flowsと、役割ベースのエージェントグループであるCrewsの2層構造 | 組織を模したタスク、PoCの立ち上げ | 低 (直観的に概念を理解しやすい) |
| Dify | LangGenius | ノーコード(GUI)、拡張はPython / JavaScript | LLMアプリ構築特化のノーコードプラットフォーム(RAG・ワークフロー・プロンプト管理を統合) | チャットボット・RAGアプリの構築、非エンジニアによるLLMプロトタイピング | 低 (ブロックをつなぎ合わせてフローを作成できる) |
| Google ADK | Python / TypeScript / Go / Java / Kotlin | Google Cloudエコシステム・A2Aのネイティブ統合 | Geminiの巨大コンテキストを活かしたマルチモーダル処理、組織間のエージェント連携 | 中〜高 (Google CloudのIAMやインフラ知識が必要) | |
| LangGraph | LangChain | Python / TypeScript | Graphによる決定論的な制御と状態管理 | Human-in-the-loop、長大な履歴管理 | 高 (Graphがややとっつきにくいか) |
| Mastra | Kepler Software | TypeScript | TypeScriptファースト・型安全な設計、Evals(評価)を独立したコンポーネントとして持つ | Web・フロントエンド系チーム主導の開発、AI機能の再利用性、拡張パターンの徹底(composableなプリミティブ設計) | 低 (TypeScriptの型システムに乗っている) |
| Microsoft Agent Framework | Microsoft | Python / .NET(C#) / Go | Semantic Kernelエコシステムに統合された、エンタープライズ向けの堅牢なエージェント基盤 | 承認機能などエンタープライズ向けのセキュリティ | 中〜高 (機能が豊富、Microsoftエコシステムの理解が必要) |
| n8n | n8n GmbH | ノーコード(GUI)、カスタムノードはJavaScript/Python | 自動化されたワークフローの一部としてAIエージェントノードを配置する、接続できるツールの種類が豊富 | ツール間のデータ連携、AIをより自動化フローの1ステップとして組み込む | 低 (ドラッグ&ドロップでフローを作成できる) |
| OpenAI Agents SDK | OpenAI | Python / TypeScript(新機能はPython優先) | 軽量・シンプル、ハンドオフ(会話の引き継ぎ)機構、サンドボックス実行のサポート | OpenAIスタックへの最速追従、ハンドオフによるエージェントの連携 | 低〜中 (コードも概念もシンプル) |
| Strands SDK | AWS | Python / TypeScript(TypeScriptはパブリックプレビュー、マルチエージェント機能は未対応) | モデル駆動(手順を人間が設計せず、モデルが実行時に都度組み立てる)、インフラとオーケストレーションの分離（モデル非依存設計） | 事前に手順を決めきれない探索的タスク、モデル非依存な運用 | 中(覚える概念がやや多い) |
選ぶときはそれぞれのフレームワークの得意領域と、目的(PoCを素早く回したいのか、本番で複雑な状態管理・リトライが必要なのか、特定ベンダのエコシステムで動かすのか……)が合っているかを考える。
軽量なフレームワークは構築時の学習コストが低いがラップされている領域が多い分、
トラブルシューティングの際どこが原因なのか分かりづらいこともある。逆に柔軟性が高くユーザ側で色々定義しないといけないフレームワークは何が起こっているのか分かりやすかったりする。
ベンダが出しているフレームワークであっても、実行環境や呼び出すモデルを柔軟に選べるものもある。
4. 評価する
エージェントを作ること自体はAIを使えばすぐできるけど、PoCフェーズを超えて本番でも使えるものを作るには、基準を定めて評価をすることが必要。
(参考) DigitalApplied - Building an AI Agent Evaluation Pipeline: 2026 Methodology
AIエージェントの評価は、チャットボットで測るような回答の良し悪し、レイテンシ、トークン消費量に加えて、ツール呼び出し・計画・ハンドオフ、安全性(チャットボットでももちろん重要だが、AIエージェントはエコシステムが広がりやすい)なども見る必要があり、対象が広い。
本記事2章のエージェントの5要素(モデル・指示・ツール・メモリ・ガードレール)に評価する内容と代表的な指標・手法をマッピングする。
| 評価する要素(§2.1) | 評価する内容 | 指標・手法の例 |
|---|---|---|
| (1) モデル | 出力形式は正しいか、禁止ワード・内容は含まれていないか。 モデルの選択・判断は妥当か。 レイテンシ・トークン消費量は許容範囲か。 |
アサーション、参照ベース評価、レイテンシ(TTFT, TPOT, スループット) |
| (2) 指示 | タスクの解釈がユーザーの意図とズレていないか。出力内容は論理的に破綻していないか 完了条件は満たされているか。無駄なステップを踏んでいないか |
LLM-as-a-Judge、Task Success Rate、ステップ数、重複アクション率 |
| (3) ツール | 適切なツールを適切な引数・順序で呼んだか | Tool Correctness, トレース検査 |
| (4) メモリ | コンテキストは適切に管理されているか | LongMemEval, MemoryAgentBench |
| (5) 実行環境・ガードレール | ガードレールはそれぞれ意図通り作動したか。実行環境のサイジングは適切か(ユーザ側で準備する場合) | 適合率、再現率、F1、偽陽性率、リソース使用率 |
| (全体)信頼性 | 1回だけでなく、毎回安定して成功するか | pass^k(k回連続で実行し、k回すべて成功する確率) |
| (全体)コスト | タスクが成功するまでにかかるコスト | Cost per (successful) task |
最終的な出力を確認するのも重要だが、AIエージェントはゴールに至るまでのプロセスが複雑かつブラックボックス化しやすいため、結果はいいが途中で無駄な行動をしていないか(トークンを無駄遣いしている)、危なっかしい操作をしていないか(バックアップ無しで破壊的な操作をしているとか)、などプロセス(トレース)も評価するべきと考える。
LLMは同じ入力であっても出力が異なるため、同じテストケースを複数回走らせて、成功が偶然でないかも確認したい。(pass^k指標)
本番の外部APIやRAGの検索結果が変わるとエージェントの評価もブレてしまうため、エージェントの推論・判断に係るテストケースはモック化を検討する。
5. セキュリティ
AIエージェントが読み込むものは人間が直接入力するプロンプトに限らず、MCPのツール説明やA2AのAgent Cardなど多岐に渡り、それらが汚染されていると意図しない挙動をしてしまう可能性がある。(間接プロンプトインジェクション)
また、メモリが汚染されると将来のセッションにわたって悪意ある指示が持続してしまうこともある。
ツールの厳選、セッション間で可能なものは分離(クリーンアップ)するといった対策も有効だが、万一悪意のある指示が仕込まれてしまったとき被害を最小限に留めるよう、各エージェントの権限設計を厳密にすることは非常に重要である。
AIエージェントの権限設計で意識したいこと
- 権限の最小化: エージェントに与える認可は、タスクに必要な最小限にとどめる。「信頼できないデータの読み込み」「重要情報へのアクセス」「外部送信手段」の3つを同時に持たせない設計が重要。
- 不可逆な操作への人間の承認（Human-in-the-Loop）: メール送信、データ削除、商品購入、本番デプロイなど、副作用を伴う操作には必ず人間の承認プロセスを挟む。
- サンドボックスでの実行: コード実行やファイル操作は、コンテナなどの隔離環境（サンドボックス）で行い、実行結果のみメインシステムに渡す。
6. AgentOps
作った後も継続的なモニタリングが大事……というのはAIエージェントに限らないが、連携しているツールやRAG、モデルの影響を受けるという前提で設計したい。
AIエージェントを本番で安全に運用するための設計
-
トレースの取得: 入力・出力結果だけでなく、思考過程、ツール呼び出しの引数、思考時間（Thinkingトークン）など、全ステップの実行軌跡（トレース）を記録し、「なぜその行動をしたのか」「どこで思考がスタックしたのか」を追えるようにする。
※レスポンス本文をトレースに出力する際は秘密情報が平文で出力されないようマスキング等の処理をする。OpenTelemetryはデフォルト設定ではプロンプト・出力内容を出力しない。
(参考 過去記事) OpenTelemetry のLLMトレーシング標準「GenAI Semantic Conventions」
-
予算上限の設定: 自律ループや複数回の試行によって想定以上にトークンを消費してしまうことや、Denial of Wallet攻撃(従量課金制を悪用してサービスの可用性ではなく予算を攻撃する)への対策。
タスク単位・ユーザー単位での最大ステップ数上限（Max Iterations）やトークン予算上限を設定しておき、超えそう/超えた場合にアラート通知する。また、無限ループや異常な思考トークンの消費など緊急性が高い場合、システム側で強制的に処理を切り離すサーキットブレーカーを実装する。
サーキットブレーカーはトークンの消費量が一定を超えたら処理を中断するようコードに判定を入れる、Toolkitを入れる、などで実装可能。
(Toolkitの例) Microsoft - agent-governance-toolkit
-
レジリエンス設計: 外部APIの障害、ネットワーク遅延、コンテキストオーバーフローによる中断に対し、ステップごとに状態を外部ストレージに記録しておく。(多くのフレームワークが状態保存の仕組みを標準で持っている)
エラー発生時は最初からやり直すのではなく、直前の正常な状態から復帰できるようにするとベター。
自動復帰かつアクション実行～チェックポイントに書き込まれる間のタイミングでクラッシュしてもアクションを再実行しない、といった厳しめの条件がある場合はTemporal(プログラムがクラッシュしてもすぐに再開できる仕組みを持ったプラットフォーム)などが必要になってくるかも。
OpenAI SDKなど、Temporalとの統合機能を持つエージェントフレームワークもある。
また、タスクが途中で失敗した場合でもそれまでに生成した成果物を安全に活用できるよう、実際のファイルシステムに中間成果物を書き込んでおく。(SDKが最初からそのような設計になっていればあまり意識しないでよい)
おわりに
2026年の動向を踏まえつつAIエージェントの定義、アーキテクチャ、評価、セキュリティ、運用を整理したが、プロンプトエンジニアリングの重要度が相対的に下がり、代わりにコンテキストエンジニアリングやガードレール・運用基盤を含めたシステム全体の設計が存在感を増してきているという印象だった。
プログラムやワークフローの方が得意なこともあるので、AIエージェントを使うことを目的化しないようにしたい。
参考文献
[1] Wooldridge, M., & Jennings, N. R. (1995). Intelligent Agents: Theory and Practice. The Knowledge Engineering Review, 10(2), 115–152. https://doi.org/10.1017/S0269888900008122
[2] Yang, H., Yue, S., & He, Y. (2023). Auto-GPT for Online Decision Making: Benchmarks and Additional Opinions. arXiv preprint, arXiv:2306.02224. https://arxiv.org/abs/2306.02224