みなさん、こんにちは。ソリューションアーキテクトの片山です。 近年、医療機関におけるセキュリティ対策の重要性が高まっています。厚生労働省の「医療情報システムの安全管理に関するガイドライン」の改定にも見られるように、電子カルテシステムをはじめとする医療情報システムの安全な運用に向けて、組織的なセキュリティ対策の強化がこれまで以上に求められています。 こうした背景を踏まえ、2026 年 3 月 31 日にヘルスケア業界のお客様を AWS にお招きして「ヘルステック企業向け セキュリティインシデント疑似体験 GameDay」を開催しました。今回はそのイベントのご紹介や当日の雰囲気をお伝えし、セキュリティへの取り組みを知っていただければ幸いです。 AWS GameDay とは AWS GameDay は、AWS ソリューションを利用してチーム単位で現実世界の技術課題を実際に体験し取り組む、AWS が提供するユニークなトレーニングプログラムです。実践的なクラウドスキルを楽しみながら習得でき、特に今回のセキュリティインシデント疑似体験 GameDay はクラウドセキュリティに特化したプログラムとして評価いただいています。 このプログラムの特徴は、実際の AWS 環境で発生しうるセキュリティインシデントをシミュレーションし、参加者がチームとなって対応するという点です。例えば、不正アクセスの検知、データ漏洩インシデントの調査、マルウェア感染への対処など、現実世界で直面する可能性のある様々なセキュリティ課題に取り組みます。 参加者は、 Amazon GuardDuty 、 AWS CloudTrail といった実際の AWS セキュリティサービスのログを SIEM on Amazon OpenSearch Service というソリューションから確認し、インシデントの検知から対応までを体験します。このワークショップ形式の学習により、座学だけでは得られない実践的なスキルと経験を積むことができます。 イベントの様子 2026 年 3 月 31 日、目黒 にて「ヘルステック企業向け セキュリティインシデント疑似体験 GameDay」を開催しました。ヘルスケア業界から 18 社、46 名のエンジニアの皆さまにお集まりいただきました。 参加者の皆さまは 3 名ごとのチームに分かれ、AWS 環境でセキュリティイベントが検知されたものの原因が特定できないというシナリオのもと、実際の SIEM 環境を操作して制限時間 2 時間の中でインシデントの調査に取り組みました。 会場では各チームが真剣にログを分析しながらも、ゲーミフィケーションの要素によりリアルタイムでスコアが可視化されるため、チーム間で競い合いながら楽しく学ぶ姿が印象的でした。多くの参加者は既に AWS 上でシステム開発・運用をされており、セキュリティへの意識も高く、非常に活気のあるイベントとなりました。 ワークショップ終了後は表彰式と解説セッションを行い、今回のシナリオで実際に何が起きていたのかを AWS から解説させていただきました。インシデントの検出にはまずは Amazon GuardDuty が効果的であり、根本原因と被害範囲の調査のためにはしっかりと必要なログを保管し、いつでも取得できるような状態にしておくことが肝要です。その後は懇親会にてヘルスケア業界に関わる技術者同士や AWS メンバーとの交流を深めていただきました。 参加者からのフィードバック イベント後のアンケートでは高い満足度の評価をいただき、参加者の 100% が「イベントを通じて学びがあった」と回答いただきました。 特に好評だったのはシナリオのリアルさです。「事象のシナリオとログ内容がかなり現実に近く、具体感をもって取り組めました」「ログ分析の奥深さを感じました」といった声が多く寄せられました。解説セッションについても「ログからセキュリティ侵害の攻撃シナリオを解説していただけたのが大変学びになりました」と、座学では得られない深い理解につながったという感想をいただいています。 「障害が発生した時にまずやるべきことが分かり、今後の運用に活かしていきたい」「普段から GuardDuty を利用していますが、何を見ればいいのか、ログの見方について理解できるようになりました」など、日々の業務に直結する学びを得られたという声も印象的でした。 まとめ セキュリティインシデントへの対応は、実際に発生してから学ぶのでは遅すぎます。AWS GameDay は、安全な環境で事前に経験を積み、実際のインシデント発生時に適切に対応できる体制を整えるための貴重な機会です。 今回の GameDay で得た学びを次のアクションにつなげるために、AWS では AWS セキュリティ成熟度モデル をご用意しています。このモデルは、組織のセキュリティ対策の現在地を把握し、次に取り組むべき施策を明確にするためのフレームワークです。このブログを読んでいただいている皆さまも、インシデント検知や調査のプラクティスが、自組織ではどの段階にあるのかを確認してみてはいかがでしょうか。セルフチェック用の評価シートもございます。詳細は https://maturitymodel.security.aws.dev/ja/assessment-tools/ をご覧ください。 AWS ではこれからもヘルスケア業界の皆さまに貢献できるよう、クラウド技術のご紹介や各種イベントを実施いたします。積極的に活用いただけますと幸いです。 著者 Yohei Katayama (AWS Japan, Public Sector, Healthcare Solutions Architect) Akihiro Nakajima (AWS Japan, Public Sector, Security Solutions Architect)

本記事は 2026 年 4 月 2 日 に公開された「 Agentic AI for observability and troubleshooting with Amazon OpenSearch Service 」を翻訳したものです。 Amazon OpenSearch Service は、組織のオブザーバビリティワークフローを支えるサービスです。Site Reliability Engineering (SRE) チームや DevOps チームは、テレメトリデータを集約・分析する統合ビューとして活用できます。しかしインシデント発生時、シグナルの相関分析や根本原因の特定には、ログ分析の深い専門知識と何時間もの手作業が必要です。根本原因の特定は依然として手動に頼る部分が大きく、多くのチームにとってサービス復旧の遅延やエンジニアリングリソースの消耗を招くボトルネックとなっています。 以前のブログ記事では、 オブザーバビリティエージェントの構築方法 を Amazon OpenSearch Service と Amazon Bedrock を使って紹介し、平均復旧時間 (MTTR) の短縮を実現しました。今回、Amazon OpenSearch Service はこれらの機能の多くを OpenSearch UI に直接組み込みました。追加のインフラストラクチャは不要です。MTTR の短縮を加速する 3 つのエージェント AI 機能を提供します。 エージェントチャットボット — 表示中のコンテキストと基盤データにアクセスし、エージェント推論を適用してツールでデータをクエリし、インサイトを生成します。 調査エージェント — 仮説駆動型の分析でシグナルデータを深掘りし、各ステップで推論過程を説明します。 エージェントメモリ — 両エージェントを支え、使うほど精度と速度が向上します。 本記事では、各機能が連携してエンジニアがアラートから根本原因まで数分で到達する方法を紹介します。また、調査エージェントが複数のインデックスにまたがるデータを自動的に相関分析し、根本原因の仮説を導き出すサンプルシナリオも解説します。 エージェント AI 機能の連携 AI 機能は OpenSearch UI の Ask AI ボタンからアクセスできます。次の図のように、 エージェントチャットボット のエントリポイントとなります。 エージェントチャットボット チャットボットを開くには、Ask AI を選択します。 チャットボットは現在のページのコンテキストを理解しているため、質問する前から表示中の内容を把握しています。データに関する質問、調査の開始、概念の説明を依頼できます。リクエストを理解すると、チャットボットはツールを使ってデータにアクセスし、Discover ページでクエリを生成・実行して、データに基づいた回答を生成します。Dashboard ページでも使用でき、特定のビジュアライゼーションから会話を開始して、次の画像のようにサマリーを取得できます。 調査エージェント 多くのインシデントは 1〜2 回のクエリでは解決できないほど複雑です。調査エージェントを活用できます。調査エージェントは plan-execute-reflect エージェント を使用します。反復的な推論と段階的な実行が必要な複雑なタスク向けのエージェントです。プランナーとして Large Language Model (LLM) を 1 つ、エグゼキューターとしてもう 1 つの LLM を使用します。エンジニアがエラーレートの急上昇やレイテンシーの異常を発見した場合、調査エージェントに調査を依頼できます。調査エージェントの重要なステップの 1 つが再評価です。各ステップの実行後、エージェントはプランナーと中間結果を使ってプランを再評価します。プランナーは必要に応じてプランを調整したり、ステップをスキップしたり、新しい情報に基づいてステップを動的に追加したりできます。プランナーを使って、エージェントは最も可能性の高い仮説と推奨事項を中心とした根本原因分析レポートを生成します。すべての推論ステップ、発見事項、最終仮説を裏付ける根拠を含む完全なエージェントトレースも提供されます。フィードバックの提供、独自の発見事項の追加、調査目標の反復、エージェントの推論の各ステップの確認と検証が可能です。経験豊富なインシデント対応者の作業を模倣しつつ、数分で自動的に完了します。チャットボットから「/investigate」スラッシュコマンドを使って、進行中の会話を基に調査を開始したり、別の調査目標で新たに開始したりもできます。 エージェントの動作 自動クエリ生成 SRE や DevOps エンジニアとして、主要サービスでレイテンシーが上昇しているというアラートを受け取った状況を考えてみましょう。OpenSearch UI にログインし、Discover ページに移動して Ask AI ボタンを選択します。Piped Processing Language (PPL) クエリ言語の専門知識がなくても、「レイテンシーが 10 秒を超えるリクエストをすべて検索」と入力できます。チャットボットはコンテキストと表示中のデータを理解し、リクエストを検討して適切な PPL コマンドを生成し、クエリバーを更新して結果を取得します。クエリでエラーが発生した場合も、チャットボットはエラーを学習して自己修正し、クエリを反復して結果を取得します。 調査と調査管理 通常であれば複数のログを手動で分析・相関して根本原因を探る必要がある複雑なインシデントでは、 Start Investigation を選択して調査エージェントを起動できます。調査の目標と、指示したいコンテキストや仮説を提供できます。例えば、「サービス全体で広範囲に発生している高レイテンシーの根本原因を特定してください。低速スパンの TraceID を使用して、関連するログインデックスの詳細なログエントリと相関させてください。影響を受けたサービス、オペレーション、エラーパターン、インフラストラクチャまたはアプリケーションレベルのボトルネックをサンプリングなしで分析してください」のように指定します。 エージェントは会話の一部として、デバッグしようとしている問題の調査を提案します。 エージェントはインデックス、関連する時間範囲などの関連情報とともに目標を設定し、調査用の Notebook を作成する前に確認を求めます。Notebook は OpenSearch UI 内でリッチなレポートを作成する機能で、ライブかつコラボレーティブです。調査の管理に役立ち、後日の再調査も可能です。 調査が開始されると、エージェントはまずログシーケンスとデータ分布の簡易分析を行い、外れ値を検出します。次に、調査を一連のアクションに計画し、特定のログタイプと時間範囲のクエリなど各アクションを実行します。各ステップで結果を振り返り、最も可能性の高い仮説に到達するまでプランを反復します。エージェントの作業中は中間結果が同じページに表示され、推論をリアルタイムで追跡できます。調査エージェントがサービストポロジーを正確にマッピングし、調査の重要な中間ステップとして活用している様子を確認できます。 調査が完了すると、調査エージェントは最も可能性の高い仮説として不正検出のタイムアウトを結論付けます。関連する発見事項として、決済サービスのログエントリ「currency amount is too big, waiting for fraud detection」が示されます。これは、高額取引が不正検出の呼び出しをトリガーし、トランザクションのスコアリングと評価が完了するまでリクエストをブロックするという既知のシステム設計と一致します。エージェントは 2 つの別々のインデックス（元の期間データを格納するメトリクスインデックスと、決済サービスのエントリを格納する関連ログインデックス）のデータを相関させてこの発見に至りました。トレース ID を使ってインデックスを紐付け、レイテンシーの測定値とその原因を説明する特定のログエントリを結び付けました。 仮説と裏付けとなる証拠を確認すると、ドメイン知識や過去の類似問題の経験と合致する妥当な結果だと判断できます。仮説を承認し、仮説調査で提供された影響トレースのリクエストフロートポロジーを確認できます。 最初の仮説が有用でなかった場合は、レポート下部の代替仮説を確認し、より正確なものがあれば選択できます。追加の入力や前回の修正を加えて再調査を開始し、調査エージェントに再検討させることも可能です。 使い始めるには エージェント AI 機能（制限あり）は OpenSearch UI で無料で利用できます。アカウントの OpenSearch Service ドメインで AI 機能を無効にしていない限り、OpenSearch UI アプリケーションですぐに利用可能です。AI 機能の有効化・無効化は、AWS マネジメントコンソールで OpenSearch UI アプリケーションの詳細ページに移動し、AI 設定を更新します。 registerCapability API で AI 機能を有効化、 deregisterCapability API で無効化することもできます。詳細は Agentic AI in Amazon OpenSearch Services を参照してください。 エージェント AI 機能は、ログインユーザーの ID と権限を使用して接続先データソースへのアクセスを認可します。ユーザーがデータソースへのアクセスに必要な権限を持っていることを確認してください。詳細は Getting Started with OpenSearch UI を参照してください。 調査結果は OpenSearch UI のメタデータシステムに保存され、サービスマネージドキーで暗号化されます。カスタマーマネージドキーを設定して、すべてのメタデータを独自のキーで暗号化することもできます。詳細は Encryption and Customer Managed Key with OpenSearch UI を参照してください。 AI 機能は Amazon Bedrock の Claude Sonnet 4.6 モデルで動作します。詳細は Amazon Bedrock Data Protection を参照してください。 まとめ Amazon OpenSearch Service に追加されたエージェント AI 機能は、コンテキストを理解するエージェントチャットボット、完全な説明可能性を備えた仮説駆動型の調査、コンテキストの一貫性を保つエージェントメモリを提供し、平均復旧時間の短縮を支援します。エージェント AI 機能により、エンジニアリングチームはクエリの作成やシグナルの相関分析に費やす時間を減らし、確認された根本原因への対応により多くの時間を充てられます。ぜひ各機能を試して、アプリケーションで活用してみてください。 著者について Muthu Pitchaimani Amazon OpenSearch Service の Search Specialist です。大規模な検索アプリケーションとソリューションを構築しています。ネットワーキングとセキュリティに関心があり、テキサス州オースティンを拠点としています。 Hang (Arthur) Zuo Amazon OpenSearch Service の Senior Product Manager です。OpenSearch UI プラットフォームと、オブザーバビリティおよび検索ユースケース向けのエージェント AI 機能をリードしています。エージェント AI とデータプロダクトに関心があります。 Mikhail Vaynshteyn Amazon Web Services の Solutions Architect です。ヘルスケアおよびライフサイエンスのお客様を担当し、データ分析サービスを専門としています。幅広いテクノロジーとセクターにわたる 20 年以上の業界経験があります。 この記事は Kiro が翻訳を担当し、Solutions Architect の Takayuki Enomoto がレビューしました。

本記事は 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を保有しています。