LLMとAIエージェントを混同している人もいるようです。この点をはっきりさせておきましょう。確かに、チャットボットを「拡張」してツールを実行できるようにし、それをAIエージェントと呼ぶケースもあります。しかし、高度な自動化にエージェントを活用するのであれば、それはまだ成熟していないアプローチです。もちろん、エージェントを活用したいとお考えでしょう。それが最も価値の高いユースケースの1つだと認識されているからです。ハイブリッド、マルチクラウドの複雑さによって増大する運用疲れへの対処に役立ちます。
AIエージェントは、目標を解釈し、コンテキストを維持し、ツールを呼び出してアクションを実行する、ソフトウェア単位（アプリケーション）として境界が定められたシステムであるべきです。必要な処理を判断するために、大規模言語モデル（LLM）を使用することもありますが、LLMはその仕組みを構成する一要素にすぎません。エージェント自体がシステムです。
実際には、AIエージェントはタスク（明示的または推論されたもの）を受け取り、コンテキストの範囲内で評価し、どのように動作するかを決定します。こうした動作には、ツールの呼び出し、システムへのクエリ、ワークフローのトリガーなどが含まれます。
とはいえ、AIエージェントの価値を引き出すために、多数のエージェントを用意する必要はありません。適切に範囲を定め、緊密に連携するツールチェーンに接続した単一のエージェントでも、今すぐ有用な作業を実行できます。要約の自動化、レポートの生成、チケットの分類に加え、アラートを適切なキューに振り分けることも可能です。定められた範囲とポリシーを遵守する限り、それだけでも十分な価値があります。
Agentic AIを導入しなくても、AIエージェントは利用できます。しかし、エージェント同士が連携した時点で、実質的にエージェント型AIを実践していることになります。たとえアーキテクチャの準備が整っていなくてもです。
Based on F5の最新調査によると、すでにエージェント型の動作に対応している（回答者の9%）か、今後対応することになる（回答者の79%）と考えられます。Agentic AIには、複数のエージェント（Agentic AIと区別しやすくするため、ここでは「ミニオン」と呼びます）が、共有ツール、コンテキストに応じた目標、MCPなどの適用レイヤーと連携する、制御された実行を中心としたフレームワークが必要です。
エージェントとは
An エージェントとは、明確に定義された制約の範囲内で、自律的または半自律的に動作するソフトウェア構成要素です。タスクを解釈し、コンテキストを管理し、ツールを呼び出し、ユーザーまたはより大規模なシステムに代わって意思決定を行います。MCPに準拠したアーキテクチャでは、エージェントは、タスク、状態、ポリシーの連携方法を規定する構造化プロトコルに従います。
エージェントは推論、委任、実行が可能ですが、与えられたサンドボックス内に限られます。システムコールを独自に実行したり、許可されていないツールへのアクセスを作り出したりすることはありません。すべてのアクションは、セキュリティを確保し、監視し、アクセスを取り消すことができる、宣言済みのインターフェースを介して実行する必要があります。
エージェントには、少なくとも以下の要素があります。
- コンテキストハンドラー – 状態、目標、メモリ（短期または永続）を追跡します
- 推論エンジン – 通常は、タスクを解釈して実行を計画するLLMまたはシンボリックプランナー
- ツールインターフェース – 意図をアクションに対応付け、エージェントが呼び出せる操作を制御します
- セキュリティ境界 – エージェントに許可される操作とその適用範囲を制御
- トランスポート層 – 通常、MCP、HTTP、またはイベントバスを使用して、メッセージとコンテキストを転送します
LLMは考え、エージェントは行動し、プラットフォームは統制します。
エージェント構築モデル
主流のモデルは2つありますが、そのうち1つには落とし穴があります。
1. LLM中心型エージェント（モノリシック）
これは、LangChain、AutoGen、CrewAIなど、現在のほとんどのフレームワークで標準となっている方式です。エージェントは基本的に、ツールとオプションのメモリを組み込んだチャットプロンプトを、単一のLLMセッションでラップしたものです。
- 迅速にプロトタイプを作成可能
- デモが容易
- スケールさせるには安全性に欠ける
制限事項：
- 永続的なアーキテクチャなし
- ネイティブなポリシー適用機能なし
- モデルがツール呼び出しをハルシネーションしたり、制約を忘れたりしやすい
- 拡張しない限り、トークンログ以外の可観測性は皆無
要するに、rootアクセス権を持ちながら、誰にも監督されていない優秀なインターンのようなものです。問題が起きるまでは、非常によく機能します。
2. アプリケーションに紐づくエージェント（モジュール型）
本番環境では、このモデルが適しています。
ここでいうエージェントは、LLMを使用する一方で、処理の実行をLLMに依存しないフレームワーク上に構築された、完全なソフトウェアサービスです。
- 状態は外部で管理されます（Redis、ベクトルDB、ポリシーエンジン）
- ツールの使用は明示的に行われ、制御レイヤー（MCPサーバー、ゲートウェイプロキシ）によって管理される
- セキュリティとオブザーバビリティは後付けではなく、最優先事項として扱われます
- エージェントはプロンプトではなく、デプロイされたサービスです
このアプローチにより、バージョン管理、アクセスログ、ツールレベルのガバナンス、ランタイムの分離が可能になります。エージェントを単なる試作品からインフラストラクチャへと進化させる方法です。
エージェントはペルソナではない
エージェントを知的な人格であるかのように設計すると、人は本能的に、ロールベースのアクセス制御（RBAC）、ログイントークン、ユーザー属性、アイデンティティスコープといった、人間中心のアクセスモデルを採用しがちです。こうしたモデルは、セッション全体を通じて一貫した人間のアイデンティティを扱う場合には理にかなっています。しかし、エージェントはそのようには動作しません。ユーザーではなく、処理の実行主体です。この違いが、すべてを変えます。
エージェントは、動作する中で役割を切り替えます。1つのエージェントが、同じセッション内かつ同じタスクの範囲内で、データ取得、計画立案、自動化のトリガーといった役割を順に担うことも少なくありません。ログインして固定トークンを取得し、1つの役割にとどまり続けるわけではありません。
ここに、従来のアクセス制御の限界があります。RBACは静的なロールを前提とし、属性ベースのアクセス制御（ABAC）は固定された属性を前提とします。セッショントークンは一貫したスコープを前提とします。しかし、エージェントが動的に変化する場合、これらの前提はいずれも成り立ちません。エージェント型システムにおけるアイデンティティは、個人ではなく機能に基づくものです。
そのため、エージェントをガバナンスするには、アイデンティティベースのポリシーから実行ベースのポリシーへ移行する必要があります。すべてのツール呼び出しは、エージェントの現在のタスク上の役割、コンテキストの状態、許可されたスコープに照らして、リアルタイムで検証しなければなりません。ポリシーは認証レイヤーではなく、ツールレイヤーに存在します。これらのポリシーの適用に必要なメタデータを保持するのは、ログインセッションではなくコンテキストブロックです。このパラダイムシフトを「Policy in Payload」と呼ぶのは、文字どおりポリシーが「ペイロード内」にあるためです。
エージェントはエージェントとして扱い、ソフトウェアとしてガバナンスを適用してください。そして、LLMは思考し、エージェントは行動し、プラットフォームは統制するという原則を決して忘れないでください。これらの役割を混同すれば、管理者権限を持ちながら、直前の失敗すら記憶していない人格を構築することになります。
LLMが考え、エージェントが行動し、プラットフォームが統制します。
この原則を守れば、拡張性とセキュリティを備え、現実の運用にも耐えられるエージェントインフラストラクチャを構築できます。
著者について
Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。
Lori Mac Vittieのその他のブログ記事関連するブログ記事
SOAS 2025：足並みの乱れが凡庸さを招く
AI導入における方針の不一致は、非効率を招きます。セキュリティ、自動化、導入の各戦略を整合させ、AIの可能性を最大限に引き出す方法をご紹介します。
WebAssemblyが重要な理由
WebAssembly（Wasm）は、あらゆるプラットフォームで高性能なアプリケーションを実現する、ポータブルで高速かつセキュアなバイナリ命令セットです。
インフラストラクチャは依然として格好の攻撃経路
クラウドコンピューティングでは、APIやドラッグ＆ドロップ式の設定ツールを活用し、ネットワークやインフラストラクチャを敬遠する人がそれらを直接扱わずに済むようにすることで、インフラストラクチャへの対応を不要にすることが長年追求されてきました。しかし、インフラストラクチャを無視することも、攻撃の主要な標的であるという事実を見過ごすこともできません。
堅牢なデータアーキテクチャがもたらす戦略的メリット
適切に構築されたデータアーキテクチャがもたらす効果は、業務プロセスの改善にとどまりません。戦略的な業務効率の向上、より深いビジネスインサイトの獲得、隣接するビジネス機会への展開にもつながり、これらすべてをより俊敏に実行できるようになります。
デジタルワークフローにおける不正検知には、データだけでは不十分
2019年には、業界全体でクレジットカード詐欺の試みが約25万件確認されました。これは約2分に1件の割合です。今日、不正を検知するには、デジタルワークフロー上のできるだけ多くのポイントから収集したデータを相互に関連付け、手作業によるデータ処理をはるかに上回る速度で分析する能力が求められます。