Amazon Web Services ブログ
Agentic AIの運用化 Part 2: ペルソナ別のガイダンス
本記事は 2026 年 3 月 16 日 に公開された「Agentic AI in the Enterprise Part 2: Guidance by Persona」を翻訳したものです。
これは、AWS Generative AI Innovation Center (以下「GenAIIC」)による2部構成シリーズのPart IIです。Part Iをご覧になっていない方は、「Agentic AIの運用化 Part 1: ステークホルダー向けのガイド」をご参照ください。
Agentic AIへの最大の障壁は、テクノロジーではありません。オペレーティングモデルです。Part 1では、エージェントから実際の価値を生み出している組織には3つの共通点があることを確認しました。仕事を詳細に定義すること、エージェントの自律性に明確な境界を設けること、そして改善を単発のプロジェクトではなく継続的な習慣として扱うこと。また、真に「エージェント向き」である仕事の4つの要素も紹介しました。仕事の目的および開始と終了が明確に定義可能、複数のツールを横断した判断が必要、仕事の成功が観察可能で測定可能、そして問題発生時の安全モードの存在。これらの基本的な要素がなければ、どれほど洗練されたエージェントでも研究室から出られません。
ここで、より難しい疑問が発生します。誰が、どのようにエージェントを機能させられるのでしょうか？
Part IIでは、共有された基礎的な情報を実際の行動に移す必要があるリーダーに直接語りかけます。各リーダーの役割には、それぞれ異なる責任、リスク、影響力のポイントがあります。P&Lを所有している、エンタープライズアーキテクチャを運営している、セキュリティをリードしている、データのガバナンスを定めている、またはコンプライアンスを管理しているかにかかわらず、このセクションはそれぞれの職務に合わせた言葉で書かれています。Agentic AIが成功するか、静かに消えていくかは、リーダーの理解と行動によって決まるからです。
Part II – ペルソナ別のガイダンス
事業部門オーナーへ：エージェントをKPIに紐づける
P&Lを所有している方にとって、必要なのは新しいテクノロジーのおもちゃではありません。必要なのは、未解決のチケット数の削減、キャッシュコンバージョンサイクルの短縮、カート放棄率の低下、コンプライアンス例外の減少など、実際のビジネス指標への寄与です。エージェントが有用なのは、これらのビジネス指標に直接結び付けられる場合のみです。
最初のステップは、新しい従業員を採用するときと同じように、エージェント向けのジョブディスクリプションを作成することです。「エージェントは、Xを受け取り、Yを確認し、Zを実行し、完了したらこのチームに引き継ぐ」。運用上の言葉で完了が何を意味するかを明文化してください。たとえば、応答時間、品質基準、エスカレーションのトリガー、顧客向けのコミットメントなどが該当します。
2番目のステップは、ビジネスケースを自分のチームがすでに追跡している数字に結び付けることです。このワークフローを通過する案件は週に何件ありますか？各案件は、人件費、手戻り、棄却のそれぞれにどれくらいのコストがかかりますか？待ち行列で滞留している時間はどれくらいですか？何かが欠けているか誤っているために差し戻される頻度はどれくらいですか？今日これらの質問に答えられない場合、最初にやるべきことはエージェントの構築ではありません。ワークフローの可視化です。
3番目のステップは優先順位付けです。取り組みの初期段階では、最も有用なエージェントは、引き継ぎを削減するものであることが多いです。受信したリクエストを読み取り、複数のシステムからコンテキストを収集し、計画を提案し、すべてが準備された状態でその計画をチームに渡します。エージェント自体がループを完結させることはないかもしれませんが、何時間、何日もの往復作業を削減できます。このようなコスト削減の成果は、CFOとの信頼関係を構築し、後により野心的な収益重視のユースケースを追求するための政治的リソースを与えてくれます。
事業部門オーナーは、モデルやプロンプトを理解する必要はありません。必要なのは、自分の指標に直接結び付いたエージェント業務の小さなポートフォリオを所有すること、そしてすべての取り組みが表面的な企画書ではなく、明文化された業務契約から始まることを主張することです。
CTOまたはチーフアーキテクトへ：必要なエージェントは10個なのか100個なのかを決める
CTOにとって、最大のリスクの1つは成功です。最初のエージェントがうまく機能すると、他のチームも欲しがります。各チームが独自のスタック（独自のフレームワーク、独自のコネクタ、独自のアクセスモデル）を構築すると、見た目も異なり、テスト方法も異なり、全体として監視することが不可能なエージェントの動物園になってしまいます。
アーキテクチャの問いは「言うは易く、行うは難し」です。必要なのは、10個の優秀だが単発のエージェントなのか、それとも100個のエージェントを安全にサポートできるシステムか？
システム構築のアプローチには、早期にいくつかの困難な作業が求められます。すべてのエージェントが顧客データを読み取ったり、チケットを更新したり、支払いを予約したりする必要があるときに、同じインタフェースを呼び出すように、ツールの公開方法を標準化する必要があります。また、ワークフロー全体の設計において「思考」と「実行」を分離する必要があります。1つのコンポーネントが計画し、別のコンポーネントがツールを呼び出し、別のコンポーネントがコンプライアンスをチェックし、別のコンポーネントがユーザーに決定を説明する…といった設計が求められます。観察可能性とデバッグがユースケース全体で機能するよう、一貫した形式で意思決定の痕跡を記録することも必要です。
また、エージェントを単発で実行されるスクリプトではなく、長期運用されるサービスとして考えることも求められます。エージェントには、アイデンティティ、権限、ローテーション、ライフサイクル管理、そして利用者に影響を与えずにアップグレードする方法が必要です。初期段階から着手が必要な作業は増えますが、これにより、エージェントが必要な10番目のチームに対して、ゼロから始めることなく「はい」と言えるようになります。
CTOの仕事は、一人で最高のエージェントフレームワークを選ぶことではありません。多くのチームが安全に、迅速に、一貫してエージェントを提供できるようにする堅牢な基盤（アイデンティティ、ポリシー実施、ロギング、コネクタ、評価機能）を構築することです。
CISOへ：エージェントをソフトウェアではなく同僚とみなす
セキュリティに責任を持つ人は、アセット（例：システム、データストア、認証情報）の単位で考えることに慣れています。エージェントは、脅威モデルに新たな要素を追加します。瞬時に意思決定を行い、アクションを実行できる権限を有するエンティティです。
エージェントを単なる別のアプリケーションとして扱ってはいけません。エージェントは同僚に近い存在です。アカウントがあり、役割を持ち、使用できるツールを持っています。間違いを犯したり、誤った設定がされていたりすることもあります。
実用的なアプローチは、人間に適用するのと同じ真剣さで、エージェントのアイデンティティを設定することです。各エージェントには、独自の認証情報、独自の権限、そして独自の監査証跡が必要です。実行されるサービスアカウントのすべての権限を継承すべきではありません。エージェントが機密データを読み取ったり、高リスクのツールを呼び出したりする場合、チームが認識できる形でログに記録される必要があります。
エージェントを適切に停止する方法も必要です。設計ドキュメントの一行として記すのではなく、実際に機能する停止スイッチです。「このクラスのアクションには常に人間の承認が必要」と定め、エージェントのプロンプトだけでなく、ツールレベルでそれを実施するポリシーを実装する必要があります。また、通常から逸脱したエージェントの挙動を監視することも意味します。通常よりもはるかに頻繁にツールを呼び出したり、以前は必要としなかったデータを読み始めたりする挙動などを指します。
Agentic AIにうまく適応するCISOは、エージェントの自律性を完全にブロックしようとはしません。自律性が許容される場面、信頼するために必要な証拠、そしてその信頼が破られたときに何が起こるかを定義します。設計の議論に早期に参加し、ポリシーを最後のゲートとして適用するのではなく、エージェントの設計の一部として組み込みます。
チーフデータオフィサーへ：データを「退屈」にする
エージェントは、すでに持っているデータ基盤を増幅します。データが断片化され、古く、文書化されていない場合、エージェントはこれらの問題をすぐに顕在化します。データに一貫性があり、適切なガバナンスが施され、理解しやすい場合、エージェントはその価値を倍増させます。
エージェント時代におけるCDOの仕事は、良い意味でデータの扱いを「退屈」にすることです。たとえば、エージェントが「このしきい値を超えるすべての未解決のクレームを表示」と尋ねたとき、どの地域や事業部門で動作しているかに関係なく、一貫した答えが得られることです。また、「顧客健全性スコア」の定義が1つ存在し、人間とエージェントの両方が使用できるほど十分に文書化されていることも含みます。さらに、何かがうまくいかなかったとき、意思決定の根拠となるメトリクスや特徴量を通じて、ソースシステムまで追跡できるような明確なデータリネージの実現も重要です。
また、現実に照らし合わせた判断も必要です。ワークフローの中には、依存するデータが不完全もしくは矛盾を含んでいるため、エージェントによる自律的な意思決定の準備ができていないものもあります。優れたCDOはこの現実を受け入れます。ただし、単純に「エージェントをサポートできない」とは言いません。「現状では、この類の業務をサポートできます。別の業務を自動化したいのであれば、その前に必要なデータ改善はこれです」などといった助言を行うことができます。
CDOがエージェントの議論に対して提供できる最も価値のある貢献の1つは、どの領域が本番化可能なデータを持っているか、どれが進行中か、そして地雷がどこにあるかを示すマップ作りです。このマップがあれば、エージェントの実装の途中でデータ負債を発見する状況に陥らず、最初のエージェント適用業務の堅実な選択が可能です。
チーフデータサイエンスまたはAIオフィサーへ：評価こそが真のプロダクト
データサイエンスまたはAIをリードする立場にいる場合、ついモデルに注目しがちです。どの基盤モデルを選び、どのファインチューニング手法を適用し、どのベンチマークスコアを目指すかなどの決定は確かに重要です。しかし、真に目指すべきプロダクトは、モデルを中心に構築された評価システムです。
エージェントは、ベンチマークが測定できない形で失敗する可能性があります。ループに陥ったり、ツールを誤って呼び出したり、もっともらしく見えるが誤った方法でタスクを中途半端に完了したりします。クリーンなテストデータではうまく動作しますが、誰もテストに含めることを想定していなかったエッジケースで崩壊します。効果的な評価システムは3つのことを行います。
第一に、実際の業務のテストへの変換です。エージェントが本番環境で間違いを犯した場合、そのシナリオは継続的に拡充される評価テストスイートの一部になります。時間の経過とともに遭遇する最も困難なケースが、エージェントの劣化を防ぐガードレールになります。
第二に、自動的な実行です。プロンプト、モデル、ツール、または検索インデックスに変更があった場合、その変更が公開される前に評価をトリガーします。このような仕組みの導入により、抜き取りチェック（と運）に頼るのではなく、変更を迅速に繰り返す自信を与えてくれます。
第三に、ビジネスが重視することの測定です。レイテンシやツール成功率などの技術的メトリクスも重要ですが、タスク完了率、エスカレーション率、意思決定あたりのコスト、人間がエージェントの推奨をそのまま受け入れる割合なども計測しましょう。これらの数字が可視化され、改善されると、事業部門からの信頼が生まれます。
エージェントの評価に早期に投資すると、モデルの選択という困難な課題がよりシンプルになります。実際のタスクでモデルがどのように動作するかを確認できるようになれば、「どのモデルが最適か？」という議論は、哲学的なものではなく、根拠に基づいた比較になります。
コンプライアンスまたは法務責任者へ：監査を想定した設計
コンプライアンスまたは法的リスクに責任を持つ方にとって、Agentic AIはおそらく動く標的のように見えます。規制は常に進化している一方、ベンダーのマーケティング施策はその規制よりも先に行っています。すべての基準が確定するまで組織を凍結することはできませんが、「ガバナンスは後で考える」を容認することもできません。
実用的なアプローチは、監査から逆算することです。規制当局または内部監査委員会が「この日に、なぜこのエージェントはこのアクションを取ったのか？」と尋ねることを想像してください。そして、その質問に明確かつ迅速に答えるために必要な証拠をすぐに決定してください。
これはいくつかの設計上の選択を意味します。すべてのエージェントは入力された情報、呼び出したツール、検討したオプション、選択したもの、適用したルール、などといった証跡を残す必要があります。与信審査、保険引受、雇用関連のアクションなどのリスクが高い業務領域では、人間が判断のループに留まり、エージェントの役割は助言的または準備的である必要があります。このような場合、データの収集、証拠の整理、アクションの提案などといったエージェントのログに加え、人間による承認も記録の一部に含める必要があります。
また、エージェントのユースケース案は全て許可すべきではありません。フレームワークと統制が成熟するまで、規制のレッドゾーンに存在するユースケースはあります。あなたの仕事は、これらの境界線を早期に明確にすることです。明確な条件で一部の案に「はい」と言い、特定の前提条件で他のものに「後で」と言い、別のものには明確な根拠に基づいて「いいえ」と言えるとき、あなたはブロッカーではなく推進者になることができます。
リーダーシップチームの他のメンバーに対してあなたができる最も役立つことの1つは、「責任あるAIが必要」のような抽象的な心配を、提案された各エージェントを活用する前に適用できる具体的なチェックリストに変えることです。
次のアクション
ここまで説明したパターンに聞き覚えがあれば、あなたは決して遅れていません。ほとんどの企業が同じような立ち位置にいます。前進する企業を分けるのは、Agentic AIを技術的な実験ではなく、オペレーティングモデルの課題として扱う決断ができるかです。まず初めにできる5つのアクションを示します：
適切なメンバーを招集する。 事業部門オーナー、CTO、CISO、CDO、AI/データサイエンスリーダー、コンプライアンスリードを集めてください。デモを作る・見せるためではなく、実用化につながる作業セッションが目的です。そして、各人に1つの質問に答えてもらいます：「実際のワークフローでエージェントを本番環境に投入することを妨げている最大の障害は何か？」
1つのユースケースではなく、1つの業務を選ぶ。 明確な開始点、明確な終了点、定義されたツール、チーム外の誰かが検証できる成功指標を持つ、1つの具体的な業務を特定します。エージェントのためのジョブディスクリプションを一緒に作成します。選択した業務の「完了」状態がどのようなものかについて合意できない場合、解決すべき最初の問題を見つけたことになります。
準備状況マップを作成する。 CDOとCISOに、現状どのデータドメインとシステムが自律的な意思決定の本番化のための準備ができているか、どこを先に改善する必要があるのか、そしてどこに絶対的な制約があるかを共同で描いてもらいましょう。この1ページのマップで、何か月もの無駄な努力を省くことができます。
定期的な検証にコミットする。 部門横断チームがエージェントの振る舞い、うまくいったこと、うまくいかなかったこと、調整すべきことを検証する定期的なレビュー（週次または隔週）を設定します。エージェントのローンチ時にのみ評価するのは、デモを構築するときです。継続的な検証を通じてのみ、組織のエージェント活用能力を構築することができます。
ガバナンスを起動ゲートではなく、設計インプットにする。 監査人が6か月後に「なぜこのエージェントはこれを行ったのか？」と尋ねた場合に必要な証拠を今決定してください。その証拠を、最初のコード行が書かれる前にアーキテクチャに統合します。
Agentic AIから実際の価値を生み出している企業は、業務を正確に定義し、自律性に意図的な境界を設け、評価に執拗に投資し、共有されたオペレーティングモデルの周りでステークホルダーを調整するといった地道な作業を行うことでその領域に到達していることを覚えておきましょう。
Generative AI Innovation Centerとの協働
上記のジャーニーを一人で進む必要はありません。最初のエージェントパイロットを計画している場合でも、企業全体の能力への拡張を図っている場合でも、AWS Generative AI Innovation Center にご連絡いただければ、お客様のワークフロー、データ、ビジネス成果に基づいた対話を始めることができます。
著者について
Nav Bhasin は、AWS Generative AI Innovation Centerのシニアデータサイエンスマネージャーです。エンタープライズのお客様がAgentic AIのコンセプトから本番展開へと進む過程を加速させています。産業、エネルギー、ヘルスケア分野でAI製品を構築してきた10年以上の経験を持ち、AWSでは6年間、GenAIアーキテクトと科学者のグローバルチームを率い、Amazon Bedrock、Amazon SageMaker、AgentCoreなどの製品を本番採用へと導く中心的な役割を果たしてきました。GenAIICへの着任前は、AWSの生成AIプロダクトポートフォリオのGTMアーキテクチャおよびデータサイエンスチームを率いていました。AWS入社前は、Utopus InsightsでHead of Data Science and Engineeringを務め、HoneywellではEngineering and Architectureを統括していました。NavはMBAと電子工学の修士号を保有しています。
Sri Elaprolu は、AWS Generative AI Innovation Centerのディレクターです。エンタープライズおよび政府組織向けの最先端AIソリューションを実装するグローバルチームを率いています。AWSでの13年間の在職中、グローバル企業や公共部門組織と協働するMLサイエンスチームを率いてきました。AWS入社前は、Northrop Grummanで製品開発およびソフトウェアエンジニアリングのリーダーシップ職を14年間務めました。Sriは工学修士とMBAを保有しています。