AI エージェント開発方法｜設計から本番運用までの手順を完全解説

生成 AI の進化により、チャットボットを超えて業務を自律的にこなす「AI エージェント」への関心が高まっています。
たとえば、

• AI エージェント開発の全体像がわからず、どこから手をつければよいか迷っている
• 設計パターンや開発フレームワークの選択肢が多く、自社に合った方法が判断できない
• PoC は成功したが、本番運用に移行する際のセキュリティやコスト管理が不安

といった課題を抱える企業も少なくありません。
本記事では、AI エージェント開発の基本概念から設計パターン、開発手順、AWS を活用した実装方法、導入時のベストプラクティスまで順に説明します。

AI エージェント開発とは

AI エージェント開発とは、大規模言語モデル（LLM）を中核に据え、目標達成に向けて計画・判断・ツール実行を自律的に行うシステムを設計・構築・運用するプロセスです。ここでは、その基本概念と従来のチャットボットとの違いを整理します。

AI エージェントの定義と従来のチャットボットとの違い

AI エージェントは、ユーザーから与えられた目標に対して、逐次的な指示がなくても自己判断でタスクを計画し、外部ツールを使いながら実行を完了するシステムです。

従来のチャットボットは「1問1答」の対話にとどまります。質問に対してテキストで回答を返すことはできますが、複数のステップにまたがる業務処理や、社内システムへの API 呼び出しを自律的に行うことはできません。

AI エージェントはこの限界を超えます。たとえば「顧客の注文状況を確認して、配送遅延があれば社内システムにエスカレーションする」といった一連の業務を、人間が途中で指示を出さなくても自律的に処理できます。

AI エージェントの基本構成は、次の式で表現できます。

AI エージェント = LLM + メモリ + ツール + 計画機構

LLM が推論を担い、メモリが文脈を保持し、ツールが外部システムと連携し、計画機構がタスクを分解・実行します。

参照：Automate tasks in your application using AI agents - Amazon Bedrock

AI エージェントを構成する4つの要素

AI エージェントを開発する際に押さえるべき4つの要素を説明します。

1. LLM（大規模言語モデル）

エージェントの「頭脳」にあたる部分です。ユーザーの意図を理解し、次に取るべき行動を推論します。Amazon Bedrock では Anthropic の Claude、Amazon Nova、Meta の Llama など、用途に応じてモデルを選択できます。

2. メモリ（Memory）

エージェントが過去のやり取りや学習した情報を保持する仕組みです。短期メモリはセッション内の会話履歴を、長期メモリはユーザーごとの設定や過去の処理結果を保持します。文脈を維持することで、繰り返しの説明を減らし、精度の高い応答が可能になります。

3. ツール（Tools）

エージェントが外部システムと連携するための手段です。社内 API の呼び出し、データベースへのクエリ、ファイルの読み書きなどをツールとして定義します。LLM は Function Calling （関数呼び出し）の仕組みを使い、必要なタイミングで適切なツールを選択・実行します。

4. 計画機構（Planning）

複雑なタスクを小さなステップに分解し、実行順序を決定する仕組みです。たとえば「週次レポートを作成する」という目標に対して、「データ取得→集計→グラフ作成→文書生成」というステップに分解して順次実行します。

この4要素を適切に設計・組み合わせることが、AI エージェント開発の出発点となります。

AI エージェント開発が注目される背景

AI エージェント開発への関心が高まっている背景には、いくつかの要因があります。

まず、LLM の推論能力が実用レベルに達したことです。以前は単純な質問応答にとどまっていた生成 AI が、複数ステップの推論や外部ツールの選択を自律的に行えるようになりました。

次に、業務自動化へのニーズが高まっていることです。定型業務の処理、社内データの検索・集計、顧客対応の一次処理など、これまで人手で行っていた作業を AI に任せたいという要望が増えています。

さらに、クラウドマネージドサービスの整備が進んだことも大きな要因です。Amazon Bedrock Agents や Amazon Bedrock AgentCore など、インフラ管理をクラウドに任せながらエージェントを構築できるサービスが提供されるようになり、開発のハードルが下がりました。

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

AI エージェントを開発する際は、用途に応じた設計パターンの選択が成果を左右します。代表的な3つのパターンを紹介します。

ReAct パターンとツール利用

ReAct（Reasoning + Acting）は、推論（Reasoning）と行動（Acting）を交互に繰り返す設計パターンです。エージェントは「考える→ツールを使う→結果を確認する→次の行動を考える」というサイクルを回します。

処理の流れは次のとおりです。

1. ユーザーのリクエストを受け取る
2. LLM が状況を分析し、次に取るべき行動を推論する
3. 必要なツール（API 呼び出し、データ検索など）を実行する
4. ツールの実行結果を受け取り、再度推論する
5. 目標が達成されるまで 2〜4を繰り返す

ReAct パターンは、状況に応じて動的に判断を変える必要がある業務に向いています。顧客対応、データ調査、社内問い合わせへの回答など、入力内容によって処理が変わるケースで効果を発揮します。

Amazon Bedrock Agents では、このパターンがオーケストレーション（指揮）の仕組みとして組み込まれています。エージェントがユーザーリクエストを理解し、Action Groups （アクショングループ）を通じてツールを呼び出す一連の流れが、ReAct パターンに相当します。

参照：Automate tasks in your application using AI agents - Amazon Bedrock

計画・実行型パターン

計画・実行型（Plan-and-Execute）パターンは、タスクを事前に計画し、その計画に沿って順次実行する設計です。ReAct パターンが都度判断を繰り返すのに対し、計画・実行型は最初に全体のステップを立案してから動きます。

このパターンが向いているのは、処理手順が比較的明確な業務です。

• 定型的なレポート生成（データ取得→集計→フォーマット→出力）
• 複数システムを横断するデータ連携
• 承認ワークフローの自動化

計画段階でタスクを分解しておくことで、実行中の推論コストを抑えられます。一方で、実行中に想定外の状況が発生した場合の柔軟な対応は ReAct パターンに劣るため、業務の性質に応じて使い分けることが大切です。

マルチエージェントパターン

マルチエージェントパターンは、複数の専門化したエージェントを連携させて、単一のエージェントでは処理が難しい複雑なタスクを解決する設計です。

大きな目標を小さなサブタスクに分解し、それぞれに特化したエージェントに割り当てます。エージェント間の連携方式には、主に次の2つがあります。

監督者型（Supervisor）: 1つのエージェントが全体を統括し、専門エージェントにタスクを振り分ける方式。タスクの全体像を把握しながら各エージェントの成果を統合する場合に適しています。

階層型（Hierarchical）: エージェントが階層構造を持ち、上位エージェントが下位エージェントを管理する方式。組織構造に近い業務フローの自動化に向いています。

マルチエージェントは強力ですが、設計・運用の複雑さも増します。開発の初期段階では単一エージェントから始め、必要に応じてマルチエージェントへ拡張するアプローチが推奨されます。

参照：エージェント AI システムの設計パターンを選択する | Google Cloud Documentation

AI エージェント開発の手順

AI エージェント開発は、要件定義から本番運用まで、いくつかの段階を踏んで進めます。各ステップのポイントを説明します。

要件定義とユースケース選定

開発を始める前に、エージェントに任せる業務の範囲と成功基準を明確にします。

向いている業務

• 定型的な手順がある業務（データ取得→加工→出力）
• 複数のシステムを参照する必要がある業務
• 判断基準が比較的明確な業務
• 繰り返し発生する業務

向いていない業務

• 高度な創造性や倫理的判断が求められる業務
• 法的責任を伴う最終意思決定
• リアルタイム性が厳しく求められる業務
• 判断基準が属人的で標準化が難しい業務

ユースケース選定では、処理の頻度、削減できる工数、既存システムとの連携のしやすさを評価します。影響範囲が限定的で、成功・失敗が測定しやすい業務から着手するのが定着への近道です。

ツール設計とナレッジ連携

エージェントが利用するツールと、参照するナレッジの設計は、開発の中核となる工程です。

ツール設計のポイント

ツールは、エージェントが実行できる具体的なアクションとして定義します。たとえば、注文管理システムとの連携であれば、次のようなツールを設計します。

• getOrderStatus: 注文番号を受け取り、配送状況を返す
• createSupportTicket: 問い合わせ内容を受け取り、サポートチケットを作成する
• searchKnowledgeBase: キーワードで社内ナレッジを検索する

各ツールには、入力パラメータ・出力形式・エラー時の挙動を明確に定義します。ツールの粒度は「1つのツールが1つの明確なアクションを担う」ことを目安に設計すると、エージェントの判断精度が上がりやすくなります。

ナレッジ連携

社内文書や FAQ などの非構造化データをエージェントに参照させる場合は、RAG （Retrieval-Augmented Generation：検索拡張生成）の仕組みを活用します。Amazon Bedrock では Knowledge Bases を使って、社内文書をベクトル化して検索可能な状態にし、エージェントの応答精度を高められます。

参照：Retrieve data and generate AI responses with Amazon Bedrock Knowledge Bases

プロンプト設計と評価・テスト

プロンプト（指示文）の設計は、エージェントの振る舞いを決定づける重要な工程です。

Amazon Bedrock Agents では、エージェントの処理フローに応じて複数のプロンプトテンプレートを設定できます。

• 前処理（Pre-processing）: ユーザーリクエストの分類・意図の把握
• オーケストレーション（Orchestration）: ツール選択と実行計画の立案
• ナレッジベース応答生成: RAG で取得した情報をもとにした回答生成
• 後処理（Post-processing）: 最終回答の整形・検証

テストでは、Amazon Bedrock コンソールのトレース機能を使って、エージェントが各ステップでどのような推論を行ったかを確認します。想定外のツール選択や回答のブレがないかを検証し、プロンプトを調整していきます。

評価指標としては、タスク完了率、回答の正確性、ツール呼び出しの適切さ、応答時間などを設定し、改善の基準とします。

参照：Enhance agent's accuracy using advanced prompt templates in Amazon Bedrock

デプロイと運用監視

テストで品質が確認できたら、本番環境へのデプロイに進みます。

Amazon Bedrock Agents では、エージェントのバージョン管理とエイリアス（別名）を使って段階的なリリースが可能です。開発版と本番版をエイリアスで切り替え、問題があればすぐにロールバックできます。

運用監視では、次の観点を継続的に確認します。

• パフォーマンス: 応答時間、タスク完了率、エラー率
• コスト: トークン消費量、API 呼び出し回数
• 品質: ユーザーからのフィードバック、回答の正確性
• セキュリティ: 不正なツール呼び出し、権限外のデータアクセス

Amazon Bedrock AgentCore では、OpenTelemetry ベースのオブザーバビリティ（可観測性）機能により、エージェントの動作・コスト・ツール活動を一元監視できます。

参照：Overview - Amazon Bedrock AgentCore

AWS を活用した AI エージェント開発

AWS では、AI エージェント開発に向けた2つの主要サービスを提供しています。それぞれの特徴と使い分けを説明します。

Amazon Bedrock Agents による開発

Amazon Bedrock Agents は、設定ベースで AI エージェントを構築できるフルマネージドサービスです。インフラストラクチャの管理やオーケストレーションコードの記述なしに、コンソールや API を通じてエージェントを構築できます。

主な機能

• Action Groups: エージェントが実行できるアクション（API 呼び出し）を定義
• Knowledge Bases: 社内文書などのナレッジを RAG で連携
• マルチエージェントコラボレーション: 複数エージェントの連携
• セッション横断のメモリ保持: 会話の文脈を維持
• コードインタープリテーション: データ分析用のコード実行
• トレース機能: エージェントの推論過程を可視化

開発の流れ

1. Amazon Bedrock コンソールでエージェントを作成
2. 基盤モデル（Claude、Nova など）を選択
3. Action Groups でツールを定義（OpenAPI スキーマまたは Lambda 関数）
4. 必要に応じて Knowledge Bases を関連付け
5. プロンプトテンプレートを調整
6. テスト・トレースで動作を確認
7. エイリアスを作成してアプリケーションに組み込み

コードをほとんど書かずにエージェントを構築できるため、PoC や初期プロトタイプの作成に適しています。保険金請求の処理や旅行予約のサポートなど、定型的な業務フローの自動化で効果を発揮します。

参照：Automate tasks in your application using AI agents - Amazon Bedrock

Amazon Bedrock AgentCore による開発

Amazon Bedrock AgentCore は、任意のフレームワークや基盤モデルを使って AI エージェントを本番環境で安全かつ大規模に構築・運用するためのプラットフォームです。2025年10月に GA （一般提供）となりました。

Bedrock Agents が「完成されたエージェント機能」を提供するのに対し、AgentCore は開発者が自由にエージェントのロジックを実装し、安全かつスケーラブルに動かすための実行基盤を提供します。

主なコンポーネント

• Runtime: エージェントのサーバーレス実行環境。セッション分離とスケーリングを自動管理
• Gateway: 外部ツールや MCP サーバーへの接続を管理
• Memory: 短期・長期のメモリ管理
• Identity: エージェントの認証・認可制御
• Observability: エージェントの動作監視とトレース
• Browser / Code Interpreter: ブラウザ操作やコード実行の組み込みツール

AgentCore はオープンソースのエージェントフレームワークと組み合わせて利用できます。AWS 公式の Strands Agents フレームワークとの統合にも対応しており、agentcore CLI を使えば、ローカルテストから AWS へのデプロイまでを効率的に進められます。

参照：Amazon Bedrock AgentCore に関するよくある質問 - AWS

本番運用で細かい制御が必要な場合、マルチエージェントの複雑なワークフロー、カスタムの認証・ガバナンス要件がある場合に適しています。

参照：Overview - Amazon Bedrock AgentCore

Bedrock Agents と AgentCore の使い分け

2つのサービスの特徴を比較し、使い分けの判断基準を整理します。

使い分けの判断基準

• Bedrock Agents を選ぶ場合: PoC や初期プロトタイプを素早く作りたい、コーディングリソースが限られている、定型的な業務フローの自動化が目的
• AgentCore を選ぶ場合: 本番環境での大規模運用が必要、カスタムの認証・ガバナンスが求められる、既存のエージェントフレームワークを活用したい

多くのプロジェクトでは、Bedrock Agents で PoC を行い、要件が固まった段階で AgentCore へ移行する段階的なアプローチが有効です。

コスト試算例

Amazon Bedrock Agents の利用コストは、基盤モデルのトークン課金が中心です。InvokeAgent API 自体に直接的な呼び出し料金はかかりませんが、エージェント内部の推論・計画・ツール選択で複数回のモデル呼び出しが発生するため、単純なチャットよりトークン消費量が増える傾向があります。

前提（Claude Sonnet 4 を使用、問い合わせ対応エージェント）:
- 1日の問い合わせ件数: 500件
- 1件あたりの入出力トークン: 入力 2,000 + 出力 1,000（内部推論を含むとさらに増加する場合があります）
- 月間稼働日: 20日

月間コスト試算（入出力トークンのみ、内部推論を除いた概算）:
- 月間入力トークン: 500件 × 2,000 × 20日 = 20M トークン → $3.00 / 100万 × 20 = $60
- 月間出力トークン: 500件 × 1,000 × 20日 = 10M トークン → $15.00 / 100万 × 10 = $150
- 月間合計（概算）: 約 $210

エージェント内部の推論・計画・ツール選択で追加のモデル呼び出しが発生するため、実際のコストはこの概算を上回る場合があります。Knowledge Bases を利用する場合は、ベクトルストアのストレージ料金や検索・リランキング料金も加算されます。

（米国東部リージョンの例）。リージョンによって料金が異なる場合があるため、実際の利用リージョンでの最新料金を AWS 公式料金ページで確認してください。

参照：Amazon Bedrock の料金

導入時の課題とベストプラクティス

AI エージェントを本番環境で運用する際に直面しやすい課題と、その対策を説明します。

よくある課題と対策

ハルシネーション（誤情報生成）

エージェントが存在しないデータや誤った情報を生成する問題です。対策として、RAG による根拠ある情報の参照、回答にソースを付与する設計、Amazon Bedrock Guardrails による出力フィルタリングが有効です。

無限ループ

エージェントが同じツールを繰り返し呼び出し、処理が終了しない問題です。最大ステップ数の設定、タイムアウトの設定、同一ツールの連続呼び出し制限を実装することで防止できます。

コストの想定超過

エージェント内部の複数回のモデル呼び出しにより、トークン消費が想定を超えることがあります。利用量の上限設定、コスト配分タグによる部門別の可視化、モデルの適切な選択（軽量モデルと高性能モデルの使い分け）で管理します。

品質のばらつき

ユースケースや入力内容によって、エージェントの回答品質にばらつきが生じます。定期的な評価テストの実施、ユーザーフィードバックの収集、プロンプトの継続的な改善サイクルを回すことが重要です。

セキュリティ・ガバナンスの設計

AI エージェントは社内システムやデータにアクセスするため、セキュリティ設計は開発の初期段階から組み込む必要があります。

IAM 権限の最小化

エージェントが利用するツールには、必要最小限の IAM 権限のみを付与します。たとえば、注文情報の参照のみが必要なツールに、注文の削除権限を与えないようにします。

Amazon Bedrock Guardrails の活用

入力・出力のフィルタリング、禁止トピックの設定、個人情報のマスキングなどを Guardrails で制御します。本番環境では、プロンプトインジェクション（悪意ある入力によるエージェントの誤動作）への対策も検討します。

参照：Amazon Bedrock Guardrails

監査ログの記録

エージェントのツール呼び出し履歴、入出力内容、エラー情報を Amazon CloudWatch Logs に記録し、定期的なレビューを行います。Enterprise 環境では、部門・ロール単位でエージェントの利用を制御するガバナンス体制を整えます。

データの学習利用への配慮

Amazon Bedrock では、お客様のデータがモデルの学習に使用されない設計になっています。機密情報を扱うエージェントでは、データの保持期間や暗号化の設定も確認しておきます。

PoC から本番展開への段階的アプローチ

AI エージェント開発を成功させるには、いきなり全社展開を目指すのではなく、段階的に進めるのが現実的です。

Phase 1: 小規模テスト（PoC）

限定的な業務領域でエージェントを構築し、動作と効果を検証します。Amazon Bedrock Agents を使えば、コンソール上で素早くプロトタイプを作成できます。正答率やタスク完了率などの定量的指標で成果を測定し、課題を洗い出します。

Phase 2: 効果検証と改善

PoC の結果をもとに、プロンプトの調整、ツール設計の見直し、セキュリティ要件の整理を行います。対象業務を段階的に広げ、処理精度と運用コストのバランスを確認します。必要に応じて AgentCore への移行も検討します。

Phase 3: 本格展開と組織浸透

品質と運用体制が整った段階で、部門横断的な展開を進めます。エンジニア向けのコードファースト環境と、非エンジニア向けの設定ベース環境を併せて整備することで、スキルレベルに応じた参画が可能になります。ユーザートレーニングやフィードバック収集の仕組みを整え、継続的な改善サイクルを確立します。

最後に

AI エージェント開発は、LLM・メモリ・ツール・計画機構の4要素を適切に設計し、用途に応じたパターンを選択することから始まります。開発の初期段階では単一エージェントから着手し、Amazon Bedrock Agents で PoC を素早く回し、本番運用の要件が明確になった段階で Amazon Bedrock AgentCore への移行を検討する進め方が現実的です。

セキュリティ、コスト管理、品質評価を開発の初期段階から組み込んでおくと、PoC の先にある本番運用まで進めやすくなります。

アイレットでは、Amazon Bedrock を活用した AI エージェントの設計・構築・運用を支援しています。実際に、Amazon Bedrock AgentCore を組み込んだノーコード・フルコードの生成 AI エージェント開発基盤を構築し、幅広い社員による内製開発を促進した事例があります。

参照：ノーコード・フルコードの生成 AI エージェント開発基盤を構築。幅広い社員による内製開発を促進 | cloudpack

要件定義やユースケース選定から、PoC の実施、本番環境への展開、継続的な改善まで、一貫してサポートいたします。AI エージェント開発の導入を検討されている方は、ぜひご相談ください。