AIエージェント開発とは？主要な概念とリスク

AIエージェント開発とは？

AIエージェント開発とは、問題について推論し、行動を計画し、ツールや外部サービスを使ってタスクを実行することで、自律的に目標を追求できるAIシステムを設計、構築、テスト、デプロイする分野です。これが今重要なのは、エージェントが研究段階のデモから、実データ、実インフラ、実ユーザーとやり取りする本番のクラウドworkloadへと急速に移行しているためです。その結果、従来のソフトウェアエンジニアリングが想定していなかった開発上とセキュリティ上の課題が生じています。

まず、何がエージェント開発に当たらないのかを明確にしておくと理解しやすくなります。ユーザーがpromptを送信してテキストを受け取るだけのシンプルなLLMチャットアプリケーションの構築は、エージェント開発ではありません。従来のif-then型のautomationスクリプトを書くことも同様です。AIエージェントは、LLMにメモリ、ツール、データアクセス、そして次の手順を自ら決定する意思決定ロジックを組み合わせたものです。LLMは単なるテキスト生成器ではなく、推論エンジンとして機能します。

Wizの『クラウドにおけるAIの現状2025年版（State of AI in the Cloud 2025）』レポートによると、現在85%の組織がAIサービスやツールを利用しており、エージェントベースのアーキテクチャはクラウド環境で最も急速に拡大しているパターンの1つです。この変化は大きな意味を持ちます。従来のautomationは開発者が記述した固定ルールに従いますが、AIエージェントはLLMを使って状況を解釈し、次に何をすべきかを判断します。この柔軟性がエージェントの強みである一方、予測しにくく保護も難しくなる要因にもなっています。

今AIエージェント開発が重要な理由

AIは「質問すれば答えが返ってくる」ものから、「目標を定義すれば、あとはエージェントが方法を考える」ものへと進化しました。チャットボットや要約ツールのような静的なLLMアプリケーションから、本番環境で実際にアクションを実行する自律型エージェントへの移行により、開発者が構築するものも、セキュリティチームが保護すべきものも変わります。

エージェントフレームワーク（LangGraph、CrewAI、Google ADK、AutoGenなど）の急増に加え、Model Context Protocol（MCP）などのプロトコルの登場により、エージェント構築のハードルは劇的に下がりました。より多くのチームがより速くエージェントをリリースしていますが、確立されたセキュリティレビューのプロセスや一元的なgovernanceがないまま進めているケースも少なくありません。

ビジネス上の推進要因は明確です。エージェントは、カスタマーサポート、コード生成、データ分析、社内業務にわたる複雑なエージェント型ワークフロー（agentic workflow）を自動化します。しかし、自律的に動くエージェントは自律的に誤りも犯し、本番システムの認証情報を保持している場合、その誤りは現実の影響をもたらします。

エージェントが独自のアイデンティティ、ネットワークアクセス、データ接続を持つクラウドworkloadになるにつれ、開発チームが構築するものとセキュリティチームが把握できるもののギャップは広がり続けています。

たとえば、開発者がコードリポジトリ、クラウドのデプロイpipeline、データベースに接続するコーディングエージェントを立ち上げたとします。このエージェントは、ソースコード、本番インフラ、場合によっては機密データにまでアクセスできるようになります。しかも、そのすべてがセキュリティチームのレビューを一度も受けない可能性のある、単一の認証情報セットを通じて行われます。

エージェント開発をクラウドインフラとアイデンティティの問題ではなく、純粋なAIの問題として扱う組織は、危険な死角を生み出しています。

AIエージェントの仕組みとは？

AIエージェントは、継続的なループの中で連携するいくつかの主要コンポーネントで構成されています。フレームワークを選んだりコードを書いたりする前に、これらの構成要素を理解しておくことが不可欠です。

これらのコンポーネントは、繰り返しのサイクルで動作します。エージェントは入力を認識し、LLMで推論し、次のアクションを計画し、ツールやAPIを呼び出して実行し、結果を観察して、このサイクルを繰り返します。たとえばカスタマーサポートのチケットをトリアージするエージェントであれば、チケットを読み、RAGを使ってナレッジベースを検索し、API呼び出しで顧客のアカウント状態を確認したうえで、適切なチームにチケットを振り分けます。これらはすべて人の介入なしに行われます。

このアーキテクチャの各コンポーネントは、障害やセキュリティ上のexposureの起点にもなり得ます。ツールには認証が必要です。メモリストアには機密データが含まれる可能性があります。オーケストレーションロジックは、エージェントに何が許可されるかを決定します。だからこそ、エージェント開発は単なるAIの問題ではなく、クラウドインフラ、アイデンティティ、データセキュリティの問題でもあるのです。

AIエージェントの主要な設計パターン

すべてのユースケースに完全自律型のエージェントが必要なわけではありません。優れたエージェント開発者は、問題を解決できる最もシンプルなパターンを選び、そのアプローチで足りない場合にのみ複雑さを加えます。Anthropic社の『効果的なエージェントの構築（Building effective agents）』ガイドがこのパターンベースの考え方を広め、今では実務者がアーキテクチャを決定する際の標準的なアプローチとなっています。

prompt chaining

タスクを固定されたステップに分割し、各ステップのoutputsを次のステップに渡します。このパターンはシンプルで予測しやすく、デバッグも容易です。実行するアクションの順序が事前にわかっている、明確に定義されたワークフローに最適です。たとえば、ステップ1で主要な主張を抽出し、ステップ2で各主張をファクトチェックし、ステップ3で要約レポートを生成するコンテンツレビューのpipelineなどが該当します。

ルーティング

入力を分類し、専門のハンドラーに振り分けます。このパターンは、多様な種類のリクエストを処理する必要があるエージェントに適しています。たとえば、受信したチケットを請求、技術、アカウントの問題に分類し、それぞれを専用のpromptやツールセットに振り分けるサポートエージェントがその例です。

ツール使用と関数呼び出し

LLMが、どのツールをどのパラメーターで呼び出すかを判断します。エージェントが現実世界で能力を発揮するのはこの段階であり、最も重要なセキュリティ上の考慮事項が生じるのもこの段階です。ツール使用は、エージェントが「考える」段階から「実行する」段階へ移る転換点であり、セキュリティリスクの大半はこの移行部分に集中します。任意のAPIを呼び出したり、任意のコードを実行したりできるエージェントには、慎重に範囲を限定した権限が必要です。

オーケストレーター・ワーカー

中心となるLLMがタスクをサブタスクに分割し、専門のワーカーに委任します。AIエージェントのオーケストレーションは、サブタスクが事前にわからない複雑な多段階の問題に有効です。たとえば、広範な質問を受け取ったリサーチエージェントが、それをサブ質問に分解し、異なるデータソースを検索する各ワーカーに割り当て、その結果を統合するケースがこれに当たります。

マルチエージェントシステム

複数のエージェントが、それぞれ異なる役割と能力を持って協働します。このパターンは強力ですが、各エージェントが独自のアイデンティティ、ツールアクセス、データ接続を持つ可能性があるため、デバッグ、保護、監視が難しくなります。本番環境のユースケースの大半では、マルチエージェントアーキテクチャは必要ありません。複数のエージェントを連携させる負荷が正当化されるのは、単一のエージェントでは本当にタスクを処理できない場合に限られるため、シンプルな構成から始めるのがほぼ常に正しい判断です。

AIエージェント開発のフレームワークとツール

フレームワークのエコシステムは急速に進化しており、最適な選択はユースケース、チームの専門性、本番環境の要件によって異なります。

• LangGraph：複雑でステートフルなエージェントワークフロー向けのグラフベースのオーケストレーションです。条件分岐と、ステップをまたいだ永続的な状態管理に対応しています。

• CrewAI：ロールベースのマルチエージェント協調フレームワークです。複数のエージェントがそれぞれ異なるペルソナを担うシステムを簡単に構築できます。

• Google Agent Development Kit（ADK）：Google Cloudと深く統合されたコードファーストのフレームワークです。エージェントをGoogleのサービスに接続するエンタープライズチーム向けに設計されています。

• AutoGen：マイクロソフトのマルチエージェント会話フレームワークです。会話型マルチエージェントシステムの研究やプロトタイピングに強みがあります。

• Pydantic AI：型安全なエージェントフレームワークです。構造化されたoutputsと、エージェントの入力およびoutputsに対する厳格なデータ検証を重視しています。

• Model Context Protocol（MCP）：エージェントをツールやデータソースに標準化された方法で接続するためのオープンプロトコルです。USBがハードウェア接続を標準化したのと同様の役割を果たします。

フレームワークの選定はセキュリティにも影響します。エージェントに広範なツールアクセスを簡単に付与できたり、任意のMCPサーバーに接続できたりするフレームワークでは、より慎重なgovernanceが必要です。各フレームワークがデフォルトでエージェントに何を許可するかを理解することは、選定プロセスの重要な要素です。状況は急速に変化するため、現在の機能だけでなく、コミュニティの活発さ、ドキュメントの質、ベンダーのセキュリティデフォルトに対する姿勢もあわせて評価してください。

AIエージェントの構築方法：ステップごとのプロセス

AIエージェントの構築は体系的なプロセスに沿って進めますが、エージェントの挙動は非決定的であるため、従来のソフトウェアとは異なり各ステップに固有の考慮事項があります。以下のステップは、本番品質のエージェントが実際にどのように構築されているかを反映しています。

ステップ1：目標とスコープを定義する

技術ではなく、問題から始めます。エージェントに具体的にどのタスクを達成させるべきでしょうか。どのデータが必要で、どのデータには決して触れさせるべきではないでしょうか。スコープの設定はセキュリティ上の作業でもあり、エージェントがすべきでないことを定義するのは、すべきことを定義するのと同じくらい重要です。

ステップ2：エージェントのアーキテクチャを設計する

適切な設計パターンを選び、ツール、データソース、オーケストレーションロジックを整理します。エージェントのアイデンティティを定義するのもこの段階です。つまり、どのクラウドサービスに対して、どのような権限で認証するかを決めます。ここでの決定が、問題が発生した場合のエージェントのblast radius（被害が及ぶ範囲）を左右します。

ステップ3：フレームワーク、model、ツールを選定する

LLM、オーケストレーションフレームワーク、ツール統合を選びます。すべてのmodelプロバイダー、ツールコネクター、MCPサーバーがエージェントのsupply chainの一部になります。これらのdependenciesは、他のサードパーティ製ソフトウェアコンポーネントと同じ厳格さで扱ってください。

ステップ4：構築し、反復改善する

エージェントのロジックを実装します。まずは実用最小限のシンプルなバージョンから始めてください。各コンポーネントは、組み合わせる前に個別にテストします。2つのツールで動作する単一エージェントのシステムは、本番環境にたどり着かないマルチエージェントアーキテクチャよりも多くのことを教えてくれます。

ステップ5：評価し、テストする

エージェントの挙動は非決定的であるため、評価はユニットテストの範囲を超えます。多様な入力やエッジケース、さらにprompt injection攻撃のような敵対的入力に対してテストする評価ハーネスを構築してください。タスク完了率、ツール呼び出しの精度、hallucinationの発生頻度などの指標を追跡します。

ステップ6：本番環境にデプロイする

適切なアイデンティティのバインディング、ネットワークアクセス制御、監視を備えたクラウドインフラにデプロイします。開発中に便宜上付与していた権限は、least privilege（最小権限）の範囲に絞り込む必要があります。個人のAPIキーを使っていた開発者のローカルエージェントには、監査ログ付きで適切に範囲を限定したサービスアカウントが必要になります。

ステップ7：監視し、改善する

ツール呼び出し、データアクセスのパターン、エラー率、異常な挙動を継続的に追跡します。入力が予測できないため、エージェントはデプロイ後も変化していきます。テスト時のエージェントの動作は、実際のユーザー入力にさらされたときの動作とは大きく異なる場合があります。

AIエージェント開発でよくある落とし穴

エージェント開発ガイドの多くは、エージェントを動作させることに焦点を当てています。このセクションでは、本番環境のAI workloadに関する実務経験をもとに、動作し始めた後に何が問題になるのかを解説します。

過剰な権限を持つエージェントのアイデンティティ

開発中、エージェントには「とにかく動く」ように広範なIAM権限が付与されがちです。こうした権限はそのまま本番環境に持ち込まれ、不必要に大きなblast radiusを生み出します。エージェントのアイデンティティは各タスクに必要な最小限の権限に絞り込み、人間のユーザーアカウントと同じ厳格さでレビューしてください。

追跡されていないエージェントのsupply chain

1つのエージェントが複数のmodel、ツール統合、MCPサーバー、promptテンプレート、データコネクターに依存することもあり、複雑なAI supply chainセキュリティの要件が生じます。software bill of materials（ソフトウェア部品表）に相当する、これらのコンポーネントの明確なinventoryがなければ、脆弱性が見つかった際に自らのexposureを評価できません。この問題は、コミュニティによって保守されていることが多いMCPサーバーで特に深刻です。

runtimeの挙動の見落とし

静的コード解析は設定の問題を検出できますが、エージェントは設計上、非決定的な挙動を示します。prompt injection、想定外のツール呼び出し、データの不正な持ち出しの試みは、runtimeにおける実際の入力を通じてはじめて表面化します。開発中にしかエージェントをテストしないチームは、リスクの一分類をまるごと見逃すことになります。

シャドーエージェントとgovernance不在のデプロイ

フレームワークによって参入障壁が下がるにつれ、組織内のさまざまなチームが一元的なvisibilityやセキュリティレビューなしにエージェントを立ち上げています。Wizの『クラウドにおけるAIの現状2025年版（State of AI in the Cloud 2025）』レポートによると、クラウド環境全体でのAIサービスの急増は、大半の組織がそれらをinventoryとして把握し保護する能力をはるかに上回っています。

RAGとナレッジベースを通じた機密データのexposure

RAGを利用するエージェントは、機密情報を含む可能性のあるdatastoreに接続します。適切なアクセス制御がなければ、エージェントは本来到達すべきでないデータを気付かないうちに表示してしまう可能性があります。たとえば、公開ドキュメントと社内のセキュリティ手順の両方を含む社内ナレッジベースに、顧客向けエージェントが接続されているとします。適切なアクセス境界がなければ、巧妙に作られたユーザーのクエリに応じて、エージェントが社内手順を表示してしまうおそれがあります。

開発ライフサイクル全体にわたるAIエージェントの保護

セキュリティは、デプロイ後に後付けするのではなく、エージェント開発のあらゆる段階に組み込む必要があります。エージェントは複数のサービスに認証し、ユーザーが制御する入力を処理し、自律的にアクションを実行します。この組み合わせには、コード、クラウド、runtimeのcontextを結び付けるAIエージェントセキュリティのベストプラクティスが求められます。

• 開発段階：エージェントのコードをスキャンし、ハードコードされた認証情報、安全でないツール定義、脆弱なdependenciesを検出します。リリース前に、無制限のツールアクセスや入力検証の欠如といった安全でないパターンがないか、エージェントのロジックを分析します。

• デプロイ段階：アイデンティティのバインディング、ネットワークのexposure、暗号化、データアクセスを含め、エージェントのクラウドインフラの態勢を評価します。AIサービスの設定ベースラインを適用し、開発時の権限が本番環境に適したレベルに絞り込まれていることを確認します。

• runtime段階：稼働中のエージェントの挙動を監視し、prompt injection、不正なツール呼び出し、異常なデータアクセス、実際の入力を通じてのみ現れる不正なアクションを検出します。

単一領域のツールだけでは全体像を把握できません。エージェントのコードにある脆弱性が問題になるのは、ネットワークのexposureがあり、機密データにアクセスできる状態でそのエージェントがデプロイされている場合に限られます。misconfigurationのあるアイデンティティが問題になるのも、エージェントに到達可能で、ユーザー入力を処理している場合だけです。リスクはこうした要素の組み合わせの中に存在するため、大規模にエージェントを構築する組織には、エージェントのコンポーネント、クラウドresource、アイデンティティ、データの関係をまとめて把握する手段が必要です。

WizによるAIエージェント開発のセキュリティ対策

Wizは、AIエージェントを独立したアプリケーションではなく、相互に接続されたクラウドworkloadとして扱います。Wiz AI-Application Protection Platform（AI-APP）は、コード、クラウド、runtimeのcontextを単一のplatformに結び付けることで、エージェントをライフサイクル全体にわたって保護します。

Wizがエージェント開発ライフサイクルを保護する仕組みは次のとおりです。

• 構築（Wiz Code & AI-BOM）：エージェントのコードベース、CI/CD pipelines、IDEをスキャンし、埋め込まれた認証情報、安全でないツール定義、脆弱なAI SDKを検出します。AI Bill of Materials（AI部品表）は、すべてのmodel、ツール、MCPサーバー、データコネクターを追跡し、supply chain全体をマッピングします。

• デプロイ（Wiz Cloud）：インフラ、アイデンティティのバインディング、データアクセスをマッピングし、実際のリスクを評価します。Agent Inventory Viewは接続されたmodelとツールのblast radiusを明らかにし、組み込みのチェックが暗号化されていないエンドポイントや過剰な権限を持つアイデンティティといったmisconfigurationを検出します。

• 実行（Wiz Defend）：稼働中のエージェントのトラフィックをアウトオブバンド（帯域外）で監視し、prompt injection、不正な挙動、悪意あるmodelの実行を検出します。

• context（Wiz Security Graph）：インフラ、アイデンティティ、データ、コードにまたがるリスクを相関付け、悪用可能なattack pathを明らかにします。たとえば、パブリックエンドポイントが、ツール使用能力と個人を特定できる情報（PII）への読み取り権限を持つエージェントに接続されているといった、危険な組み合わせ（toxic combination）を検出します。

AIエージェントのインフラ、アイデンティティ、実行時のリスクを包括的に把握する方法を、Wizでご確認ください。 Wizの実際の動作を見る

よくある質問