AIエージェントの「振る舞い」をどう評価する？ 実践者が明かす「設計」「テスト」の勘所：開発・運用でつまずかない、実務に耐え得る「AIアプリ」構築のヒント
2025年12月20日、JAWS-UG主催のコミュニティーイベント「AI Builders Day」が開催された。本稿では、そのセッションの中から、Amazon Web Servicesを活用したAIエージェント開発の現在地と、AIエージェントの設計や評価のポイントをまとめてお届けする。
生成AI（人工知能）を巡るトレンドは、チャットbotから、人の代わりに業務を完遂する「AIエージェント」へと変化しており、企業のビジネス活用への期待も高まり続けている。だが、AIモデルの進化があまりに速く、肝心の開発手法や運用に関するベストプラクティスはいまだ確立されていない、あるいは日進月歩で変わり続けているといえる。
多くの企業がアーキテクチャやモデル選定、AIエージェントの構築や運用について模索を続ける中、こうした「試行錯誤」の最前線にいるITエンジニアたちが知見やノウハウを共有し議論する場として、2025年12月末にAmazon Web Services（AWS）のユーザー会（JAWS-UG：AWS Users Group-Japan）主催の「AI Builders Day」が開催された。イベントでは、AIエージェント開発に取り組む企業のITエンジニアが複数登壇した。
そこで本稿は、当日のセッションの中から、AWSにおける最新の開発環境事情から、実務に耐え得るAIエージェントアーキテクチャ設計の勘所、そしてAIエージェントの評価手法にフォーカスした3つの講演内容をまとめてお届けする。
ChatGPTからAIエージェントへ 進化するAIアプリ開発の現在地
キーノートセッションでは、KDDIアジャイル開発センターの御田 稔氏が、生成AIの出現からAIエージェントに至る流れを振り返りながら、AWSにおけるAIエージェント開発環境の最新動向を紹介した。
2022年11月、「ChatGPT」の登場によって、世界は一変した。多くの企業がビジネス活用の可能性を感じ、生成AIを自社アプリに組み込んだチャットbotの開発に乗り出した。その際に課題となったのがハルシネーション（幻覚）、つまりAIが事実とは異なる情報をもっともらしく生成してしまう現象だった。そこで、ハルシネーションを克服するため、RAG（検索拡張生成）といった新しいアプローチが生み出され、ビジネスでの生成AI活用は現実味を増した。
しかし、テキストによる一問一答では、AIに任せられる業務は限られる。そこで登場したのが、自ら考えて業務を遂行するAIエージェントという概念だ。
AIエージェントは、ユーザーの依頼を達成するために必要な作業を洗い出し、TODOリストを作成して行動計画を立てる。その過程で必要に応じてツールと呼ばれる小さなプログラムを実行する。ツールを用いることで、APIを呼び出したり、社内システムを操作したり、ファイルを生成したりといった複雑な処理が可能になり、生成AIの適用範囲が大きく広がった。
AIエージェントはツールをただ実行するだけではなく、ReAct（Reasoning & Acting）の考え方に基づき、ツールの実行結果を観察し、次の行動計画を自ら修正する。このように、行動計画の立案・実行・観察・修正というプロセスを継続的に回しながら動くのが、AIエージェントの基本原理だ。御田氏は、「今やAIアプリ開発といえば、多くの場合AIエージェント開発と同義になりつつある」と指摘する。
AWSは2023年9月の「Amazon Bedrock」を皮切りに、RAGを扱いやすくする「Amazon Bedrock Knowledge Bases」、ノーコードでAIエージェントを構築できる「Amazon Bedrock Agents」などを立て続けにリリースしてきた。その中でも御田氏が大きな変化として取り上げたのが開発者向けフレームワーク「Strands Agents」とAWSのサービスである「Amazon Bedrock AgentCore」だ。
Strands Agentsは、AWSが公開したオープンソースのエージェント開発フレームワークだ。PythonおよびTypeScriptに対応し、わずか3行のコードでエージェントやツール呼び出しを実装できる。MCP（Model Context Protocol）を用いた外部連携に対応している他、ネットワーク型やグラフ型を含む柔軟なマルチエージェント構成も可能だ。
Amazon Bedrock AgentCoreは、AIエージェント運用に必要な基盤機能をビルディングブロックとして提供するプラットフォームだ。AIエージェントをサーバレスに実行するRuntime、短期・長期の会話記憶を扱うMemory、MCPをはじめとするツール群の統合ハブとなるGatewayなどから構成される。さらにEvaluationsとObservabilityにより「LLMOps」を実現し、運用品質を継続的に改善できる点が特徴だ。Strands Agents以外のフレームワークで開発したエージェントもデプロイ可能で、開発者は必要な機能だけを選択して利用できる。
「AIアプリ開発と聞くと『機械学習エンジニアによる難解な作業』が必要だというイメージを持つ人も多いのではないでしょうか。しかし現在は、LLM（大規模言語モデル）の処理がフレームワークによって抽象化され、Webエンジニアでも手軽にアプリケーションへ組み込める強力なパーツとなりつつあります」（御田氏）
AIエージェント開発で考慮すべきポイント 「アーキテクチャ」「LLMOps」「独自性」
クラウドサービスやフレームワークの発展により、エージェントを「作る」こと自体のハードルは下がりつつあるというわけだ。ただ、実務で使える品質や運用までを見据えた設計となると、話は別だ。
NECソリューションイノベータの福地 開氏のセッションでは、自身の開発経験を踏まえて、AIエージェントの設計において考慮すべき3つのポイントが紹介された。
1. 外部情報の取得方法がアーキテクチャを決定する
AIエージェントのアーキテクチャは大きく「自律型」と「ワークフロー型」の2種類に分類される。
自律型エージェントは、LLMが計画作成・ツール実行・振り返りのループを自律的に繰り返し、処理全体を統制する。本来の意味でのAIエージェントに当たるものだが、柔軟性が高い半面、動作が不安定になりやすい。
一方、ワークフロー型は事前に定義した処理フローに沿って実行され、柔軟性には欠けるものの、ビジネスに必要な安定性を確保しやすい。さらに、ワークフローの中に自律型エージェントを組み込む「エージェンティックワークフロー」という派生形も存在する。処理自体は決まった順番で進むが、その途中にLLMによる分岐処理や判定処理が入るというものだ。
福地氏によれば、AIエージェントにどのような情報を与えるか（コンテキスト）によって、適切なアーキテクチャを選択するとよいという。特に重要なのは、外部情報の取得方法だ。エージェント自身が動的に情報を取得する必要があれば自律型が適し、あらかじめ渡すデータが決まっているならワークフロー型が適しているという。
「『ワークフローの構築も、LLMに任せるべき』という考え方もあります。ただ、不確定要素が増え過ぎると扱いづらくなります。アーキテクチャに正解はないのですが、現実の業務ではワークフローやエージェンティックワークフローが好まれるでしょう」（福地氏）
福地氏は、自身が業務の中で開発した2つのAIエージェントを例に、アーキテクチャ選択の具体例を紹介した。
顧客向けのレポート作成を自動化するためのレポート生成エージェントでは、必要なデータがあらかじめ決まっていることから、ワークフロー型を採用したという。Amazon Bedrockと「Amazon Step Functions」によるAIワークフローを構築し、データベースから取得したデータを月次でレポートに加工する。
一方、セキュリティレビューエージェントは、構築したAWS環境のセキュリティチェックを実施するエージェントだ。こちらは、チェック項目が入力値によって変わることがあるため、Strands Agentsを用いて自律型エージェントとして開発したという。
2. 評価と改善のサイクルを設計段階から組み込む
福地氏は、「AIエージェントはWebアプリとして構築できるものの、通常のWebアプリとは似て非なる性質を持つ」と注意を促す。基盤となるLLMがアップデートされれば、出力の品質や傾向が変化する可能性が高い。また、エージェントが対応するユースケースを広げるためにツールを追加すると、エージェントの振る舞い全体に影響が及ぶこともある。さらに、APIの使用上限（レートリミット）を考慮したリトライ処理の実装や、障害時に備えたフェイルオーバー用のセカンダリーモデルの準備など、LLM特有のエラーハンドリングも求められる。
こうした、LLMの特性を踏まえて継続的にシステムを運用、改善する取り組みが「LLMOps」であり、AIエージェントのライフサイクルにおいて、常に付きまとう課題となるわけだ。そのため「AIエージェントを構築する際には、設計段階からLLMOpsを見据えた技術選定が求められる」と、福地氏は指摘する。
中でも特に重要なのが、AIの回答を評価し、改善させるサイクルだ。有害な内容やハルシネーションが回答に含まれていないかどうかをチェックするのは当然だが、たとえ正解であっても、文体や答え方によってはサービスとして不適切になることがある。
そこで、利用者が期待する回答と、AIの生成との差を定量的／定性的に判断し、最適な結果を得られるように調整する作業が必要となる。言い換えれば、評価とは「AIエージェントの回答において何を正解とするか」を定める行為だと、福地氏は定義する。
自律型エージェントの場合は回答だけでなく、正しいツールを正しいタイミングで使えているか、思考プロセスは適切かといった「振る舞い」も評価対象となり、評価方法はさらに複雑になる。「このような評価を継続的に実施するためにも、評価の仕組みを初期段階から組み込んでおく必要がある」と、福地氏は言う。
加えて、組織的な観点を考慮した運用設計も欠かせない。特に受託開発などで、開発と運用が分かれている場合は、運用・顧客側との綿密な意識合わせや、スキルセットを考慮した技術選定が求められる。その上で、AIエージェントを運用する担当者の負荷が増加しないよう、自動化を意識したLLMOpsの仕組みづくりが重要になるという。
福地氏自身も顧客とのコミュニケーションでやっていることとして、次のようにアドバイスする。
「お客さま環境向けのAIエージェントを構築する際には、あらかじめ『精度向上のためのフィードバックにご協力ください』とお願いしておくと、お互いにとって良い結果につながるはずです」（福地氏）
3. プロダクトとしての独自性
せっかくAIエージェントを開発しても、既存のAIアプリケーションで代替可能であれば、利用されない可能性は高い。そのため、「特定の領域やタスクに特化したAIエージェントを開発することが重要だ」と、福地氏は指摘する。
差別化のための要素として、福地氏は3つの要素を挙げた。
- 独自データ：RAGやMCP連携によって社内ドキュメントなど固有のデータをコンテキストとして与えることで、汎用（はんよう）AIとの差別化が図れる
- 最適なトリガー：どのようなきっかけでAIエージェントを動作させるか検討する。イベント駆動やスケジュール駆動で動作するだけでも、汎用AIとは明確に異なる価値を提供できる
- 優れたUI/UX（ユーザーインタフェース／ユーザー体験）：利用者が常にPCの前でタイピングできる環境にいるとは限らない。音声操作を採用するなど、利用シーンに応じた体験設計が必要になる
「3つの差別化要素を全てそろえる必要はありません。難しく考えすぎず、1つだけでもよいので、既存のAIと差別化できるポイントを意識しながら作ってみることが重要だと考えます」（福地氏）
AIエージェントの評価指標とDeepEvalによる実践
このように、AIエージェントをビジネスで活用するには、開発するだけでなく、その回答や振る舞いを適切に評価し、継続的に改善していく必要がある。三菱電機の塚田真規氏は、デモを交えながら、AIエージェントの評価手法を解説した。
塚田氏によると、AIエージェントの評価指標には3つの観点があるという。
1つ目は、「最終回答の評価」だ。これはユーザーの質問に対する回答が、ユーザーの意図に沿っているかを確認するもので、先ほどの福地氏のセッションでいえば、オンライン評価に相当する。ユーザー目線での最終段階の評価には有効だが、AIエージェント内部の処理がブラックボックスとなるため、問題発生時の原因特定には限界がある。
2つ目は「単一ステップの評価」だ。AIエージェントの各処理ステップにおいて、適切なツールを選択しているか、正しいパラメーターで実行しているかを検証する。動作の検証には有効だが、ユーザーにとっての回答の品質を評価することは難しい。
3つ目は「軌跡の評価」だ。これは、AIエージェントが入力を受けてから最終回答を返すまでに、どのツールをどの順序で使用したかという、一連の軌跡（行動履歴）を評価する。軌跡の評価には「完全一致」「順序一致」「順序不問」の3タイプがあり、要件に応じて使い分ける。
- 完全一致：指定した実行軌跡が厳密に一致しているかどうか検証する
- 順序一致：必要なツールの使用順序のみを検証する
- 順序不問：必要なツールが使われていれば順序を問わない
これを踏まえ塚田氏は、Confident AIが開発するオープンソースの評価フレームワーク「DeepEval」を用いた実践例を披露した。これは、AIエージェントの実際の「実行軌跡」と、テストケースとして事前に設定した「期待する軌跡」を比較し、その乖離（かいり）を定量的に評価するというアプローチだ。
この例で用いられたのは、足し算・引き算・掛け算・割り算を個別のツールとして定義したシンプルな「計算エージェント」だ。塚田氏は、このエージェントに対して以下の計算を実行させ、DeepEvalがどのように判定を下すのかを解説した。
- 実施する四則演算
- 3+4-5/5
- 実行軌跡（使用するツールと順番）
- 1. div：割り算ツール 5/5 = 1
- 2. add：足し算ツール 3+4 = 7
- 3. sub：引き算ツール 7-1 = 6
- 実行結果
- 6
ケース1-1：完全一致
まず、最も厳格な評価基準である「完全一致」のケースだ。ここでは、DeepEval側で期待する軌跡として、「割り算ツール（div）→足し算ツール（add）→引き算ツール（sub）」という順序でツールが実行されることを定義した。
エージェントの実行軌跡は「割り算→足し算→引き算」の順で行われており、定義した正解データとツールおよび順序が完全に合致した。その結果、評価指標である Tool Correctness（ツールの正確性）スコアとして満点の「1.0」が出力され、テストは「Pass（合格）」となった。
ケース1-2：完全一致
次に、同じ「完全一致」の設定で、あえて正解データ側を「割り算→引き算→足し算」という順序に書き換えてテストを実行した。エージェントの実際の動き（割り算→足し算→引き算）は変わっていないが、定義した正解データ（割り算→引き算→足し算）とは順序が異なる。そのため、DeepEvalはこれを「不一致」と判定。スコアは「0.0」となり、テストは「Fail（不合格）」となった。
ケース2：順序一致
続いて、要件を少し緩めた「順序一致」のケースだ。ここでは、期待する軌跡からあえて「足し算」を省き、「割り算→引き算」という順序だけを定義した。
エージェントは「割り算→足し算→引き算」という順序でツールを実行しているため、間に「足し算」が挟まっている。しかし、順序一致（Subsequence）の評価基準では、指定したツール間の前後関係さえ正しければ、未指定のツールが間に含まれていても評価が変わることはない。
結果として、「割り算の後に引き算が実行されている」という要件は満たしているため、テストは「Pass（合格）」した。
ケース3：順序不問
最後は、使用するツールが含まれていれば順序を問わない「順序不同」のケースだ。DeepEvalは「期待されたツール群が全て呼び出されている」という点のみを評価し、順序の不整合は不問として、このテストは「Pass（合格）」した。
塚田氏は「AIエージェントの評価メトリクスを自前で実装することは、非常に難易度が高い。しかし、近年はDeepEvalをはじめ、AIエージェント向けの評価フレームワークも充実しつつある。まずは既存のフレームワークを使って、AIエージェントの評価を始めてみては」と締めくくった。
手を動かすことの重要性
3人のセッションに共通していたのは、「手を動かしてみることの重要性」だ。AIエージェントの構築や運用を支援するクラウドサービスフレームワークは着実に充実してきており、エージェントの構築を試しながら知見を蓄積するためのハードルは下がってきている。
開発手法やLLMOpsのベストプラクティスはいまだ確立されていないが、それを待っていては時代に取り残されてしまう。かといってAIエージェントの設計に悩み過ぎると前へ進めなくなる。これはあらゆるシステム開発にも通じる話だが、AIエージェントにおいても、まずは小さく作って試し、そこから知見を積み重ねていくことが重要だといえる。
最後に、キーノートを担当した御田氏のメッセージを紹介し、本記事の締めくくりとしたい。
「2025年はAIエージェントの利用元年だったのではないかと思います。2026年はぜひAIエージェント構築元年にしましょう」（御田氏）
Copyright © ITmedia, Inc. All Rights Reserved.