AIエージェントのPoCが本番に進まない理由――モデルではなく「システム」を設計する4つの柱：【AWS Summit 2026 - セッションレポート】

Last updated at 2026-08-19Posted at 2026-08-19

はじめに

AIエージェントのデモを作るところまでは、以前よりずっと簡単になりました。

例えば、返金エージェントが丁寧で正しい文章を返しても、タイムアウト後の再試行で二重返金すれば、本番システムとしては失敗です。逆に表現が毎回少し違っても、正しい注文を重複なく返金し、権限外操作を拒否できれば、業務上は成功です。本番で問われるのは「賢く話せるか」だけでなく、正しい状態へ、安全に、重複なく到達できるかです。

プロンプトを与え、いくつかのツールを接続し、社内文書を検索できるようにすれば、短期間で「それらしく動く」ものを見せられます。しかし、そこから本番運用へ進もうとすると、急に難易度が上がります。

なぜその回答になったのか追えない
利用者が増えた途端にコストやレイテンシが悪化する
古い文書や別ユーザーの文脈を参照してしまう
エージェントが権限外の操作を実行する可能性がある
モデルやプロンプトを変更したら、以前できていたことが壊れる

AWS Summit Japan 2026 のセッション「本番展開を見据えて：エージェンティック AI に対する実践的アプローチ（AIM201）」では、このPoCと本番の間にあるギャップを、次の4つの柱で整理していました。

運用上の優秀性
データとコンテキスト
信頼性
堅牢性

本記事では、公式講演資料とオンデマンド動画を出発点に、この4つを「自分のエージェントを本番へ出せるか判断するためのチェック項目」として再構成します。さらに、SRE、セキュリティ、AIガバナンス、RAG・エージェント評価の知見とも照合しました。AWSサービスの紹介に閉じず、別のクラウドや自前実装でも使える設計原則を取り出すことが狙いです。

本記事はAWS Summit 2026 の本番展開を見据えて：エージェンティック AI に対する実践的アプローチ（AIM201）の内容を元にした非公式の日本語要約であり、すべての著作権・知的財産権はAWSに帰属します。

資料の扱い：本記事ではスライド画像や字幕全文を転載せず、講演内容を筆者の言葉で要約し、図表とコードを独自に再構成しました。AWSの商標はAWS Trademark Guidelinesに沿って表記しています。個別の転載許諾を得たものではなく、公式資料へのリンクはAWSによる提携・承認を意味しません（法的助言ではありません）。サービスの提供状況は2026年8月18日時点です。

忙しい方用

本番化で評価すべき単位はモデル単体ではなく、RAG、メモリ、ツール、認可、監視、人の承認まで含むシステム全体
まずコード、単一LLM＋RAG、固定ワークフローを検討し、実行時に手順を決める必要がある部分だけエージェントへ委ねる
品質だけでなく最終状態、権限外操作、レイテンシ、成功タスク当たり費用を継続評価し、段階リリースと停止・復旧まで設計する

本編

PoCと本番の間にあるもの

講演で引用されたS&P Global / 451 Researchの調査（調査レポートの転載PDF）は、北米・欧州のIT部門および事業部門の中間・上級職1,006人を対象としています。回答者によると、所属組織はAIプロジェクトの平均46%を、PoCから広範な導入に至るまでの間に打ち切っていました。PoCを止めること自体は、価値の薄い案を早期に見極める健全な判断でもあります。問題は、価値があるはずの案まで「本番化の準備不足」で消えていないかです。

ただし、この46%はAIエージェント限定の失敗率ではなく、北米・欧州の回答者によるAIプロジェクト全般の自己申告です。この結果を、日本を含むすべての組織にそのまま一般化することはできません。また、この調査だけから「4つの柱が不足したため失敗した」という因果関係も導けません。この数字は課題の広がりを示す材料として、4つの柱はAWSが提示した実践的な処方箋として、分けて捉えます。

PoCでは、少人数が既知の入力を使い、失敗すれば開発者がその場で調べられます。一方、本番には予測不能な入力、同時アクセス、権限、監査、コスト上限、品質保証が持ち込まれます。

つまり、本番化とはモデルを賢くする作業だけではありません。確率的な判断を、決定的な認可・検証と、部分障害を前提にした実行基盤で囲う設計です。

ここで興味深いのは、「最新モデルを使う」が4つの柱に入っていないことです。モデル性能は依然として制約になり得ます。しかし本番では、モデル交換だけでは解けないデータ、運用、権限、評価の問題も同時にボトルネックになります。

この見方はAWS固有ではありません。Berkeley AI Researchは、実用AIの品質が単一モデルではなく、検索、ツール、コードなどを組み合わせた「Compound AI System」の設計から生まれる傾向を整理しています。異なる分野の言葉へ翻訳すると、4つの柱は次のようにつながります。

AWSセッションの柱	別分野で重なる考え方	設計上の問い
運用上の優秀性	SRE、OpenTelemetry	どの構成要素が、品質・遅延・費用を悪化させたか追えるか
データとコンテキスト	情報検索、RAG評価	検索の失敗と生成の失敗を分けて測れるか
信頼性	ゼロトラスト、OWASP、AIガバナンス	モデルが誤っても、権限外の結果に到達できないか
堅牢性	ソフトウェアテスト、段階リリース	非決定性を前提に、回帰を検知し安全に戻せるか

したがって本番化の評価単位は「モデル」ではなく、モデル、プロンプト、検索、メモリ、ツール、ポリシー、人の承認まで含むシステム全体です。

そのユースケースは、本当に独自エージェントを作るべきか

4つの柱は万能な分類ではなく、「解く価値と実現可能性がある」と確認した後に効く枠組みです。RANDが5年以上の経験を持つAI実務者65人を対象に行ったインタビュー調査では、失敗要因として、問題定義のずれ、必要データの不足、最新技術そのものの追求、基盤への過少投資、現時点のAIには難しすぎる課題が整理されています。ただし、この調査は事前学習済みLLMやプロンプトエンジニアリングだけの案件を対象外としており、AIエージェント全般の失敗率を示すものではありません。最初の問いは、その業務問題をAIで解くべきかです。

そのうえで講演では、既存製品を先に検討することが勧められていました。これは重要な視点です。ただし、判断は「買うか、エージェントを自作するか」の二択ではありません。

独自エージェントを作ると、プロンプトやツールだけでなく、認証、監査、データ分離、評価、障害対応まで自分たちの責任になります。既存製品で目的を満たせるなら、その運用機能も含めて利用したほうが短く安全に価値へ到達できる場合があります。

独自実装を選ぶ理由は、少なくとも次のどれかで説明できる状態にしたいところです。

判断軸	独自実装が必要になりやすい例
独自のビジネスロジック	自社固有の審査・承認・価格計算
高度なシステム連携	既存製品が知らない基幹系やレガシーシステムへの接続
専門領域の知識	社内用語や業界固有ルールを深く扱う
完全な制御	セキュリティ、コンプライアンス、データ配置を細かく制御する

Anthropicは「Building effective agents」で、決められたコード経路でLLMとツールをつなぐワークフローと、モデル自身が手順やツール利用を動的に決めるエージェントを区別し、必要性が実測できるまで複雑さを上げないことを勧めています。設計候補は、次の順に並べると判断しやすくなります。

既存製品で満たす
決定的なコード／ルールで処理する
1回のLLM呼び出しに、必要ならRAGを加える
固定経路のワークフローに分解する
手順を事前定義できない部分だけエージェントに委ねる

右へ進むほど柔軟性は増えますが、一般にレイテンシ、費用、テスト範囲、失敗経路も増えます。「作れるから作る」ではなく、左側の構成では満たせない要件と、複雑化による改善を評価結果で説明できるから進む、という順番にします。

柱1：運用上の優秀性――「遅い」の原因を説明できるか

ユーザーから「遅い」「回答がおかしい」と言われたとき、原因はモデルとは限りません。

モデル推論に時間がかかった
RAGの検索が遅い、または無関係な文書を取得した
外部APIがタイムアウトした
ツールの再試行が発生した
エージェントが不要な計画とツール呼び出しを繰り返した

この切り分けには、HTTPのレスポンスタイムだけでは足りません。1回のユーザー要求について、モデル呼び出し、検索、ツール実行、ポリシー判定までを同じトレースで追える必要があります。

Amazon Bedrock AgentCore Observabilityでは、AgentCoreがCloudWatchへ出力する組み込みメトリクスに加え、AWS Distro for OpenTelemetry（ADOT）でエージェントコードを計装できます。AgentCore Runtime外でホストするエージェントの計装もサポートされています。

観測する。ただし、何でも保存しない

「すべてを追えるようにする」と「すべての内容をログへ残す」は別です。OpenTelemetryの生成AI向けSemantic Conventionsも、入力・出力メッセージ、検索クエリ、システム指示、ツールの引数と結果に、個人情報や機密情報が含まれ得ると警告しています。

まずは、内容を保存しなくても診断できるメタデータを標準にします。

トレースID、テナントID、モデル／プロンプト／ツール／ポリシーのバージョン
各処理の開始・終了時刻、成否、再試行回数、トークン数
呼び出したツール名、検索した文書IDとスコア、ポリシー判定
評価結果と、最終的な業務状態

プロンプト本文、検索断片、ツール引数・結果を保存する場合は、目的を限定し、機密情報の削除・マスキング、保存期間、閲覧権限、監査を決めます。デバッグのためのログが、新しい情報漏えい経路になっては本末転倒です。

監査証跡はデバッグ用ログと分け、エージェントや実行ランタイムには更新・削除権限を与えず、別系統の追記専用（append-only）で改ざん耐性のある保存先へ送ります。時刻、認証済み主体、テナント、各構成要素の版、正規化したツール引数またはそのハッシュ値、認可の結果と理由、承認対象と承認者、実行結果を、同じトレースIDで相関できるようにします。例えば、別AWSアカウントのS3 Object Lockを使ったWORM保存は選択肢の1つです。

AgentCoreの標準ログだけで、これらの項目がすべて自動収集されるわけではありません。アプリケーション側でも監査レコードを生成し、リクエストIDやトレースIDでCloudTrail、CloudWatchの記録と相関させます。内部の思考過程を無条件に保存するのではなく、外から検証できる判断・行動・結果を残します。

最初から計測したい4種類の指標

種類	例	分かること
品質	正答率、タスク完了率、拒否の適切さ	役に立つ回答か
レイテンシ	全体、モデル、検索、ツールごとのp50/p95	どこで待っているか
コスト	要求あたりのトークン数、モデル・ツール呼び出し回数	どこに費用がかかっているか
信頼性	エラー率、再試行率、ポリシー拒否率	どこで失敗しているか

ポイントは、品質・コスト・レイテンシを別々に最適化しないことです。安いモデルへ変えて品質が落ちたり、精度を求めて全要求を高性能モデルへ送りコストが持続不能になったりするためです。ユースケースごとに「どこまで遅くてよいか」「1回いくらまでか」「最低品質はいくつか」をセットで決めます。

さらに、メトリクスを眺めるだけでなく、ユーザーが気にする結果からSLI/SLOとリリース条件へ落とします。Google SREのSLOの考え方を返金エージェントへ当てはめるなら、例えば次の形です。数値は例であり、実際には業務影響とベースラインから決めます。

品質SLO：対象案件の99%以上が、正しい返金状態へ重複なく到達する
性能SLO：正常完了案件のp95エンドツーエンド・レイテンシを15秒以下にする
「1リクエスト当たり」ではなく「成功した返金1件当たり」の費用を上限内にする
二重返金、権限外返金、クロステナント参照は、平均で薄めず、検出時にリリースを止める安全性不変条件にする

「安く失敗する」システムを高く評価しないよう、技術指標の分母を業務上の成功へ結び付けることが重要です。

柱2：データとコンテキスト――モデルの失敗に見えるデータの失敗

エージェントが誤答したとき、モデルを変更する前に確認したいことがあります。

正しい文書がインデックスされていたか
取得した文書は最新版だったか
チャンクに回答に必要な文脈が残っていたか
検索結果の順位は適切だったか
ユーザーや業務に固有のコンテキストを渡したか
前の会話を覚えるべき場面で、メモリを参照できたか

講演では、この柱が3つのピースで整理されていました。組織のナレッジをナレッジベース（RAG）で蓄積し、ビジネスコンテキストをメタデータで付与し、ユーザーコンテキストをメモリで補完するという整理です。3つが揃って初めて、エージェントは適切な情報を使って判断できます。

なぜ3つ必要なのかは、講演で挙げられていたサポートチケットの例が分かりやすいです。「注文Aが遅延している」という問い合わせが生データのまま届いた場合、エージェントに返せるのは「お届けが遅れています」という同語反復だけです。ここに、この顧客が有料会員であること、注文が生鮮食品であること、今月2回目の遅延であることというコンテキストが付与されれば、優先対応へエスカレーションし、代替品の即日配送を提案するという、業務上有用な判断に変わります。モデルは何も変わっていません。変わったのは渡した情報です。

以下、3つのピースを順に見ていきます。

組織のナレッジ：RAGはパイプラインであって、投入作業ではない

RAGは「PDFをベクトルDBに入れる作業」ではありません。生データを、エージェントが判断に使えるナレッジへ変換するパイプラインです。

RAGの評価も、最終回答の正誤だけで終わらせません。RAGASの論文が整理するように、RAGには少なくとも「関連する文脈を検索できたか」「取得文脈を忠実に使えたか」「生成物自体の品質はどうか」という異なる評価観点があります。Amazon Bedrock Knowledge Basesの評価指標も、Retrieve onlyとRetrieve and generateの2種類を設け、それぞれ異なる指標を定義しています。

評価層	代表的な問い	改善対象
検索	必要な根拠を取得できたか、不要な断片が多くないか	チャンク、埋め込み、クエリ変換、再ランキング、フィルター
生成	取得した根拠に忠実か、正確・完全か、引用は対応しているか	プロンプト、モデル、コンテキスト構成、出力検証
業務結果	利用者の目的を達成し、正しい状態を作れたか	検索と生成を含むシステム全体

例えば正解文書を取得できていないなら、モデルを大型化しても根拠は増えません。逆に正解文書を取得しているのに誤答するなら、生成側を調べます。この切り分けが、モデル交換を「原因不明の万能薬」にしないための第一歩です。

なお、RAGは根拠を与える仕組みであって、正解を保証する仕組みではありません。質問が知識範囲外にある場合や、コーパスが古い場合には、不正確な回答を生成し得ることが報告されています（EMNLP 2024の検証）。検索精度だけでなく、範囲外の質問を検知して「答えない」「人へ確認する」能力と、権限外文書を取得しないことも評価します。

ビジネスコンテキスト：メタデータは検索品質と安全性の両方に効く

先ほどのチケット例で判断を変えたのは、顧客区分や商品特性といった業務上の意味づけでした。これをデータへ体系的に付与する仕組みがメタデータです。メタデータは検索品質と安全性の両方に関係します。例えば次の情報を文書へ付けておけば、検索時のフィルター、鮮度判定、問題発生時の追跡に使えます。

{
  "document_id": "expense-policy-2026-04",
  "owner": "finance",
  "effective_from": "2026-04-01",
  "expires_at": null,
  "confidentiality": "internal",
  "allowed_roles": ["employee", "manager"],
  "source_uri": "s3://knowledge/finance/expense-policy.pdf",
  "version": 4
}

ここでallowed_rolesは検索対象を絞るための属性であり、認可境界そのものではありません。メタデータは取り込みミスや改変の影響を受けます。認証済みのユーザーとテナントをデータアクセス層まで伝播し、その層でもACLを強制します。

ユーザーコンテキスト：メモリは「何を、いつまで、誰の名前空間へ」を先に決める

3つ目のピースは「この人は誰で、何を求めているか」です。会話履歴も、何でも保存すればよいわけではありません。

短期メモリ：現在の会話、途中の計画、直前のツール結果
長期メモリ：ユーザーの好み、過去の確定事実、継続タスク

AgentCore Memoryは短期・長期メモリを提供し、長期メモリをactorIdなどを使った名前空間で分離できます。実装方式にかかわらず、「何を、いつまで、誰の名前空間へ保存するか」を先に決めないと、パーソナライズ機能が情報漏えいの入口になります。

名前空間があるだけでも不十分です。名前空間はアドレスであり、それ自体が認可境界ではありません。AgentCore Memoryでは、actor、session、namespaceをIAM条件キーとして制限できます。それに加えて、tenant_id、user_id、actorId、sessionIdをモデルの出力やリクエスト本文から自己申告させず、認証済み主体からサーバー側で導出し、メモリの読み取り／書き込み／削除ごとにアプリケーション層とデータ層でも認可します。IDORとクロステナント取得は自動テストへ入れます。

長期メモリには出典、観測時刻、信頼度、有効期限、書き込み原因、版を持たせ、訂正・削除・隔離・ロールバック経路を用意します。モデルが抽出した「記憶」を、無条件に確定事実へ昇格させないためです。

組織のナレッジ、ビジネスコンテキスト、ユーザーコンテキスト。エージェントの誤答を、この3つのうちどれが欠けているかで切り分けられるようになると、「とりあえずモデルを替える」以外の改善経路が見えてきます。

柱3：信頼性（Trustworthiness）――モデルに認可を判断させない

ここでいう信頼性は、主にセキュリティ、プライバシー、制御可能性を含むtrustworthinessの意味です。SREでいう可用性や耐障害性は別の論点であり、柱4で扱います。

本番エージェントは回答するだけでなく、メール送信、返金、注文変更、データ更新などの副作用を伴う操作を行います。そのため、プロンプトに「権限のない操作は禁止」と書くだけでは不十分です。

LLMは「何をしたいか」を解釈できますが、「実行してよいか」を決める最終的な認可機構には向きません。認可はモデルの外側に決定的なポリシーとして実装し、ツールを実行するたびに強制します。

守る対象	主な制御
誰が要求しているか	認証、ユーザーとセッションの対応付け
どのデータを見られるか	テナント・ユーザー単位のデータ分離
どのツールを呼べるか	ロールとツール単位の認可
どの条件なら実行できるか	金額、対象、時間帯などを含む実行直前のポリシー
どんな入出力を許すか	有害内容、禁止トピック、機密情報のガードレール
何が実行されたか	改ざんしにくい監査ログとトレース

OWASP LLM06: Excessive Agencyは、被害の根因を「過剰な機能・過剰な権限・過剰な自律性」に整理しています。裏返すと、本番設計では次の最小エージェンシーを適用します。

機能を最小化：汎用のexecute_shell、execute_sql、任意URL取得ではなく、用途を絞ったツールにする
権限を最小化：読み取りと書き込みを分け、認証済みユーザーに紐づく短期資格情報と最小限のスコープを使う
自律性を最小化：最大ステップ数、時間、費用、送信先を制限し、高リスク操作は人へ戻す

例えば返金エージェントなら、モデルが提出するのは操作の提案だけです。ロール、テナント、返金可能残高をモデルやクライアントに自己申告させてはいけません。

from dataclasses import dataclass
from enum import Enum


class Decision(Enum):
    ALLOW = "allow"
    REQUIRE_APPROVAL = "require_approval"
    DENY = "deny"


@dataclass(frozen=True)
class RefundProposal:  # モデル／クライアントが提案できる値
    order_id: str
    amount_jpy: int
    reason: str


@dataclass(frozen=True)
class Principal:  # 検証済みトークンからサーバーが構成
    user_id: str
    tenant_id: str
    roles: frozenset[str]


@dataclass(frozen=True)
class Order:  # DB／決済システムからサーバーが再取得
    order_id: str
    tenant_id: str
    refundable_amount_jpy: int


def authorize_refund(
    proposal: RefundProposal,
    principal: Principal,
    order: Order,
) -> Decision:
    if proposal.order_id != order.order_id:
        return Decision.DENY
    if principal.tenant_id != order.tenant_id:
        return Decision.DENY
    if not (principal.roles & {"support", "manager"}):
        return Decision.DENY
    if (
        proposal.amount_jpy <= 0
        or proposal.amount_jpy > order.refundable_amount_jpy
    ):
        return Decision.DENY
    if proposal.amount_jpy >= 100_000:
        return Decision.REQUIRE_APPROVAL
    return Decision.ALLOW

Principalは検証済みトークンから構成し、Orderは実行直前にバックエンドが現在値を読みます。ここで「検証済み」とは、発行者、署名、有効期限などを検証済みという意味です。AgentCore RuntimeのX-Amzn-Bedrock-AgentCore-Runtime-User-Id／GetWorkloadAccessTokenForUserId経路では、UserIdはIdPが照合した主体ではなく不透明な文字列として扱われます。本番ではJWTなどを検証するか、上流で認証済みの主体情報を使い、サーバー側でPrincipalを構成します。

サーバーは、テナント、注文、金額、実行主体に結び付けた不変の操作IDと冪等性キーを保存し、同一操作のすべての再試行で同じキーを使います。外部決済をDB更新と同一トランザクションに含めることはできないため、ローカルの実行意図と一意制約／outbox、決済側の冪等性機能、結果の再照合を組み合わせ、必要なら補償処理を行います。高額返金の承認も、ツール名、注文、金額、期限を含む操作内容一式に結び付け、承認後に引数が変われば無効にします。

検索した文書は「命令」ではなく未信頼データ

プロンプトインジェクションは、ユーザーの直接入力だけから来るとは限りません。Webページ、PDF、メール、RAG文書、ツール結果、他エージェント、長期メモリに命令を埋め込む間接攻撃があります。NIST AI 100-2 E2025は、現時点の緩和策がすべての攻撃を防げるわけではないため、未信頼入力がある場合は攻撃可能性を前提に設計するよう述べています。

そこで、外部コンテンツをシステム指示と分離し、不要なツールを公開せず、出力先と引数をallowlistで制限します。読み取り担当と副作用を実行する担当を分ける方法もあります。最も重要なのは、モデルが攻撃に負けても、データアクセス層とツール実行境界の認可を突破できないことです。

AWSの実装例では、Policy in Amazon Bedrock AgentCoreをGatewayへENFORCEモードで関連付け、対象ポリシーをACTIVEにすると、Gatewayを通るMCP（Model Context Protocol）ツール呼び出しを実行前に評価し、Cedarポリシーで許可条件を強制できます。LOG_ONLYでは判定を記録するだけで遮断しません。Gatewayを迂回する直接経路は閉じるか、同等の認可を別途強制します。また、AgentCore Policyの評価対象はMCPツールであり、MCPのprompt／resource操作は対象外のため、機密データを置かないか、別の認可を設けます。

Amazon Bedrock Guardrailsは、入力と出力に対するコンテンツフィルター、禁止トピック、機密情報フィルターなどを提供します。ただし、RetrieveAndGenerateでGuardrailsが適用されるのはユーザー入力と生成応答であり、Knowledge Basesから取得した参照本文には適用されません。また、機密情報フィルターはtool_useの引数中のPIIを検出しません。取得文書、ツール引数、ツール結果には、別途スキーマ検証、allowlist、マスキング、認可を適用します。Guardrailsは認可の代わりではなく、認可ポリシーも入出力の安全性評価の代わりではありません。

人間承認はリスクに応じて設計する

何でも毎回承認させると、承認疲れによって確認が形骸化します。一方、高リスク操作を「計画を一度承認したから」と無制限に許すこともできません。Anthropicの実運用上の整理も、権限をアクション単位で制御しつつ、承認疲れを避ける設計上の課題を挙げています。

影響・可逆性	基本方針
認可済み・非機密・小範囲の読み取り	自動実行し、監査する
機密閲覧、大量取得、外部への出力	追加ポリシーを適用し、目的確認・承認を求める。条件を満たさなければ拒否する
限定的で可逆な書き込み	差分や計画を提示し、範囲を限定して承認する
決済、外部送信、削除など許可済みだが不可逆・高影響	完全な引数を示し、実行直前に承認する。必要なら職務分離・二者承認を使う
権限昇格など、組織が禁止した境界	エージェント経路では拒否し、承認で上書きしない

読み取りでも、機密情報の閲覧・大量取得・外部送信は不可逆な漏えいになり得ます。承認は不足している権限を付与する仕組みではありません。承認者が根拠、差分、副作用を確認でき、検討時間と拒否・中止する権限を持つことまで含めてHuman-in-the-Loopです。

セッション分離にも注意が必要です。AgentCore Runtimeではセッションごとに専用microVMを使って実行環境を分離しますが、ユーザーとセッションIDの対応付けはアプリケーション側の責任です。インフラが分離されていても、バックエンドが別ユーザーのセッションIDを再利用すれば境界は崩れます。また、同じ実行環境内のコードが利用できる実行ロールは、必要最小限の権限にします。

柱4：堅牢性――何でもエージェントにやらせない

今回のセッションで、最も実装へ直結すると感じたのが次の原則です。

公式講演資料（p.44）の要点は、推論が必要なタスクにエージェントを限定し、計算・検証・ルールベースの処理はコードへ戻すことです。

LLMにできることと、LLMに任せるべきことは同じではありません。

処理	置き場所	例
曖昧な意図の理解、計画、要約	LLM／エージェント	「この依頼に必要な作業を整理して」
外部情報の取得、副作用のある操作	ツール	DB検索、レポート作成、メール送信
LLMに見せてよい既知の決定的情報	モデル向けコンテキスト	要求開始日、業務タイムゾーン、対象月
認可に使用する属性	信頼済み実行コンテキスト（モデル非可視）	認証済み`user_id`、`tenant_id`、`roles`
計算、形式検証、業務ルール	コード／ポリシー	翌月の算出、金額上限、JSON Schema検証

例：基準日を取得するためだけのツールを作らない

ユーザーが「来月の支出レポートを作って」と依頼したとします。

基準日を取得するツールをエージェントへ渡すと、次の処理が必要になります。

エージェントがget_current_date()を呼ぶ計画を立てる
ツールを呼び出す
戻り値から翌月を推論する
create_report()を呼ぶ

しかし、基準日はアプリケーションがすでに知っている決定的な情報です。翌月もコードで計算できます。

以下は資料の実装をそのまま転記したものではなく、「LLMに任せる必要のない日付計算をコード側へ寄せる」という考えを、さらに進めた筆者の例です。

from datetime import date


def next_month(value: date) -> str:
    year = value.year + (1 if value.month == 12 else 0)
    month = 1 if value.month == 12 else value.month + 1
    return f"{year:04d}-{month:02d}"


today = date(2026, 8, 18)

agent_context = {
    "today": today.isoformat(),
    "target_month": next_month(today),
}

# エージェントには target_month="2026-09" を渡す。
# エージェントは必要なレポート種別を判断し、
# create_report(month="2026-09", ...) を呼び出すことに集中する。

ここへ認可用のuser_id、tenant_id、rolesは入れません。それらはLLM向けコンテキストではなく、バックエンドが保持する信頼済みの実行コンテキストからツール境界へ注入します。モデルが返したIDやロールは認可根拠として無視します。

実運用では、サーバーのローカル時刻ではなく要求開始時刻を利用者の業務タイムゾーンへ変換し、長時間処理の途中で意味が変わらないよう固定します。「翌月」が暦月か会計月か、月末・年末・うるう年をどう扱うかも、業務ルールとしてテストします。

これにより、不要なモデル／ツール呼び出し、レイテンシ、コスト、障害点を減らせます。講演資料では、LLM呼び出しを4回から3回に、処理時間を約12秒から約9秒に減らした例として「25%高速」と記載されています。ただし、モデル、実行環境、試行回数や結果のばらつきなどの測定条件は示されていないため、再現可能なベンチマーク値ではありません。ここで持ち帰るべきなのは数値ではなく、決定的に取得・計算できる情報をエージェントの推論ループから外すという原則です。

エージェントの役割はコードの代替ではなく、コードとツールをつなぐオーケストレーションです。

ただし、決定的とは再現しやすいという意味であり、正しい・安全という意味ではありません。コードと認可ポリシーにも、境界値、異常系、例外、並行実行のテストが必要です。

エージェントも普通の分散システムである

モデル固有の非決定性に目を奪われると、もっと身近な部分障害を見落とします。Microsoft Azure Well-ArchitectedのAIワークロード設計原則も、AIシステムに通常のクラウドアプリケーションと同じ信頼性設計を適用し、retry、circuit breaker、bulkheadなどを使うよう整理しています。

障害・重複の原因	設計上の備え
モデルや外部APIが応答しない	処理全体のdeadlineを各依存先へ伝播し、個別timeoutを置く
一時障害で再試行する	回数を制限し、exponential backoffとjitterを使う
返金や送信が再実行される	idempotency key、重複検知、実行済み状態の照合
依存先の障害が連鎖する	circuit breaker、同時実行数・rate・費用上限、bulkhead
途中まで成功して停止する	永続的なcheckpoint、再開、照合、補償トランザクション
一部機能が利用不能になる	読み取り専用や人手運用への縮退

特に副作用のある操作では、「ツール呼び出しがタイムアウトした」ことと「処理されなかった」ことは同義ではありません。分散システム全体のexactly-onceを安易に保証せず、再試行前後に実行結果を照合し、冪等性と重複排除によってeffectively-onceを目指します。

「なんとなく良い」を評価データへ変える

非決定的なシステムでは、同じ入力でも出力が完全には一致しません。だからこそ「毎回同じ文章か」ではなく、「許容する品質の範囲に入っているか」を評価します。

評価セットには、正常例だけでなく次を含めます。

同じ意図の異なる言い回し
情報が不足した依頼
境界値や例外
権限外操作やプロンプトインジェクションなどの誤用例
期待するツールと引数
呼んではいけないツール
最終回答に必要な事実や引用元

例えば、先ほどのレポートエージェントなら次のようなケースを用意できます。特定のツール順序へ過度に固定せず、最終状態と安全上必要な制約を中心にします。

{
  "case_id": "expense-report-next-month",
  "input": "来月の支出レポートを作って",
  "trusted_context": {
    "request_started_at": "2026-08-18T09:00:00+09:00",
    "principal_id": "finance-user-123",
    "tenant_id": "tenant-a"
  },
  "expected_outcome": {
    "report_month": "2026-09",
    "created_report_count": 1
  },
  "state_invariants": {
    "deleted_report_count": 0,
    "cross_tenant_read_count": 0
  },
  "trajectory_limits": {
    "forbidden_tools": ["delete_report"],
    "max_tool_calls": 2
  }
}

Anthropicのエージェント評価ガイドは、エージェントが「予約しました」と発話したかではなく、予約データが実際にDBに存在するかというoutcomeを区別しています。評価対象を4層に分けると、見かけの成功を減らせます。

評価対象	例
Outcome／最終状態	正しい月のレポートが1件だけ作られた
Trajectory／過程	禁止ツールを使わず、上限ステップ内で終わった
Efficiency／運用	時間、トークン、ツール回数、成功タスク当たり費用
Safety／不変条件	権限外アクセス、未承認の副作用、情報流出が0件

エージェントが成功を宣言しただけでは成功ではありません。逆に、安全上の理由がない限り、有効な別経路まで「想定したツール順と違う」という理由だけで不合格にしないようにします。

評価方法は1つに寄せず、役割で分けます。

プログラマティック評価
JSON Schema、期待するツール、引数、禁止アクションなど、機械的に判定できる項目。
LLM-as-a-Judge
正確性、完全性、関連性、トーンなど、完全なルール化が難しい項目。
人間による評価
業務上の妥当性、ブランド表現、高リスク判断、評価基準そのものの校正。

LLM-as-a-Judgeは便利ですが、正解器ではなく校正が必要な測定器です。MT-Bench／Chatbot Arenaの研究では、人間選好との高い一致と同時に、回答の位置、冗長さ、自モデルの出力を好む偏りが報告されました。さらに15種類の評価モデルを調べた2025年の研究でも、位置バイアスが評価モデルとタスクによって変わることが確認されています。

そのため、評価モデル、プロンプト、ルーブリック、版を記録し、人手で正解を付与したサンプルで定期的に校正します。A/B比較では出所を伏せ、提示順を反転・ランダム化します。JSON妥当性、認可、テナント分離、禁止アクションなど、コードで判定できるものを評価モデルへ任せません。

また、1回の成功は偶然かもしれません。同じケースを複数回試行し、平均成功率だけでなく「k回すべて成功する確率」のような一貫性も見ます。この観点は、ツール利用エージェントの評価研究τ-benchでpass^kとして提案されています。新しい能力を測るcapability suiteと、以前できたことを壊していないか測るregression suiteを分け、モデル、温度、プロンプト、RAG索引、ツール、ポリシーの版を結果と一緒に保存します。

Amazon Bedrockのモデル評価では、別のLLMを評価モデルとして使う評価や、Bedrock外のモデルが生成した応答データの持ち込みをサポートしています。AgentCore Evaluationsは、サポートされる計装から得たセッション、トレース、ツール呼び出しのテレメトリを評価し、結果をAgentCore Observabilityへ統合します。

重要なのは評価ツールの名前ではなく、評価を変更フローへ組み込むことです。

モデル、プロンプト、RAG索引、メモリ抽出、ツールスキーマ、ポリシーのどれを変更しても、エージェントの振る舞いは変わります。すべてをバージョン管理し、正常動作が確認済みのバージョンへ戻せるようにします。

Google SREのCanary Releaseと同じく、変更を全利用者へ一斉投入せず、小さなカナリア群と対照群の品質、レイテンシ、費用、安全性を分けて比較します。副作用を起こさず同じ本番入力を複製できる場合はシャドー実行も使えます。合格後に段階的に広げ、しきい値を超えたら新規実行を止めて、正常動作が確認済みのバージョンへ戻します。ただし、旧版へ戻しても、すでに送信・決済・削除された副作用は元に戻りません。完了済み操作は別途照合し、可能なものだけ補償します。評価はリリース直前のイベントではなく、継続的な運用機能です。

「止められる」を実装する

停止・ロールバックを図の箱だけにしないため、停止スイッチ（kill switch）はエージェント自身が操作できない制御面へ置きます。

副作用を起こす全境界で、新しいツール呼び出しをポリシー層から拒否する
資格情報は有効期間を短くし、必要時に失効させられる方式にする。実行中のタスク、キュー、再試行、子エージェントのキャンセルはベストエフォートとして扱う
外向き通信を遮断し、対象のセッション、テナント、ツール、版を隔離する
認可済み・非機密の読み取り専用機能、または人手運用へ縮退する
ログ、入力、メモリ版、ポリシー版を保全して実行済みの結果を照合し、補償可能な操作だけ補償する
再開条件、判断責任者、利用者への連絡方法を決める

開始済みの外部処理や、すでに送信・漏えいした情報は、停止スイッチでも取り消せない場合があります。したがって停止機構だけに頼らず、最初から権限、送信先、処理量を絞って爆発半径を小さくします。

NIST AI RMF 1.0 Coreは、本番監視に加えて、利用者からの異議申立てとoverride、廃止、インシデント対応、復旧、変更管理を管理項目として挙げています。これは任意利用のリスク管理枠組みであり、チェックリストへの適合を認定するものではありません。日本のAISIによるAIセーフティのレッドチーミング手法ガイドには、RAGシステムを対象にリスクシナリオ、攻撃シナリオ、実施結果、最終報告書まで作る具体例があります。正常系の評価だけでなく、攻撃され、停止し、復旧するところまで演習します。

さらに、2026年7月公開のAISI「AIセーフティに関する評価観点ガイド」第1.20版では、AIエージェントに関係する「観測と制御」「自律的な挙動」「外部環境との相互作用」が評価観点として追加されました。監視と停止・復旧の設計を点検する際に併用できます。

組織内の責任者、リスク許容度、教育、モニタリング、インシデント対応を整える際は、総務省・経済産業省のAI事業者ガイドライン第1.2版とチェックリストも、日本で使いやすい入口になります。

PoCから本番へ進むためのチェックリスト

最後に、4つの柱を実装時のチェックリストへ落とします。

運用上の優秀性

モデル、RAG、ツール、ポリシー判定を1リクエスト単位で追跡できる
品質、成功タスク当たりコスト、レイテンシをSLI/SLOとして定義している
p50だけでなくp95などの遅いケースを監視している
生のプロンプトやツール結果を無条件保存せず、マスキング・保持・閲覧方針がある
エージェント、ツール、MCPサーバーの所有者とバージョンが分かる
障害時に停止・縮退運転できる

データとコンテキスト

文書の所有者、版、施行日、機密区分を追跡できる
検索、生成、業務結果を分けて自社データで評価している
範囲外の質問に答えないことと、権限外文書を取得しないことをテストしている
インデックス更新の遅延と失敗を監視している
短期メモリと長期メモリの用途を分けている
メモリ操作を毎回データ層で認可し、来歴管理、保持期間、訂正・削除の手順を定め、クロステナントアクセス試験を設けている

信頼性

ユーザーID、テナントID、セッションIDを認証済み主体からバックエンドで導出している
ツールの機能・権限・自律性を最小化している
副作用のある操作を、現在の状態で実行直前に再認可している
高リスク操作の承認を完全な引数と期限へ結び付けている
ガードレールと認可ポリシーを別の制御として設計している
外部コンテンツを未信頼データとして扱い、間接プロンプトインジェクションを試験している
判断・認可・承認・行動・結果を、実行主体が削除できない別系統の監査証跡へ残している

堅牢性

計算、検証、業務ルールを決定的コードへ切り出している
業務日などLLM可視にしてよい既知属性をコンテキストで渡し、認可属性は実行境界に留めている
timeout、上限付きretry、idempotency、同時実行・費用上限がある
最終状態、過程、効率、安全性を分け、重要ケースを複数回試行して評価している
LLM-as-a-Judgeを人間の正解付きデータで校正し、決定的評価と併用している
変更のたびに回帰評価を行い、カナリア群と対照群を比較している
停止スイッチの限界を把握し、縮退、結果照合、可能な補償、証拠保全、再開条件を実地で試している

すべてにチェックが付くまでリリースできない、という意味ではありません。未対応項目とリスクを可視化し、対象ユーザーと権限を絞りながら段階的に広げるためのリストです。

まとめ

PoCから本番へのギャップは、モデル性能だけでは埋まりません。

観測できなければ、直せない
正しいデータとコンテキストがなければ、賢いモデルも正しく答えられない
認可をモデルへ委ねれば、安全な自律実行はできない
決定的に処理できる部分までLLMへ渡せば、遅く、高く、不安定になる
timeout、retry、idempotencyがなければ、正しい推論でも二重実行や部分障害で壊れる
評価がなければ、改善したのか壊したのか証明できない

最初から巨大なエージェント基盤を作る必要はありません。1つのユースケース、1つのエージェントから始めればよいと思います。

ただし、小さく始めることと、観測不能なまま始めることは違います。

動かす。観測する。評価する。安全に止める。改善する。このサイクルを回せる最小構成から始めることが、本番へ到達する一番の近道です。

AIエージェント導入を検討している方へ

私たちナレッジコミュニケーションでは、構想の整理からナレッジ設計、認証連携、実装、運用改善まで、Amazon Bedrock をベースに、社内で使い続けられるAIエージェント体制をお手伝いいたします。

▼ AIエージェント導入・構築支援サービス | Amazon Bedrock

「何から始めればいいかわからない」という方もご相談は無料ですので、お気軽にお問い合わせください。