【AWS Summit Japan 2026】AI エージェント時代における責任あるAIのベストプラクティスと実践例 [AIM345] セッションレポート

はじめに

今月誕生日の人、おめでとうございます🎉 エデュケーショナルサービス課の森純子です。

AWS Summit Japan 2026のセッションレポート第2弾です。

AIエージェントの自律性が上がるほど、インシデント時のインパクトも大きくなります。このセッションで印象に残ったのは、責任あるAIは「ガードレール→監視→組織的改善」のサイクルを回し続けることが本質だということ。そしてIndeed様の実践事例「Anticipate→Guardrail→Observe」のフレームワークが具体的で参考になりました。

構成が非常に分かりやすく、Responsible AIにこれから取り組む方にもおすすめだと思いましたので、セッション内容をレポートします。

対象読者

AIアプリケーションやAIエージェントの開発を担うエンジニア
AI活用とセキュリティ/ガバナンスの両立を検討・提案したいエンジニア
責任あるAI（Responsible AI）の概念は知っているが、具体的な実装方法を知りたいエンジニア

本記事で使用する略称

略称	正式名称
RAI	Responsible AI（責任あるAI）
Bedrock Guardrails	Amazon Bedrock Guardrails
AgentCore	Amazon Bedrock AgentCore
CloudWatch	Amazon CloudWatch
PII	Personally Identifiable Information（個人を特定できる情報）
LLM	Large Language Model（大規模言語モデル）

セッション概要

項目	内容
タイトル	AI エージェント時代における責任ある AI（Responsible AI）のベストプラクティスと実践例 [AIM345]
登壇者	鵜飼裕紀氏（アマゾンウェブサービスジャパン合同会社ソリューションアーキテクト）
日時	2026年6月26日（金）15:00 - 15:40 JST
関連サービス	Amazon Bedrock Guardrails / Amazon CloudWatch / Amazon Bedrock AgentCore

本セッションの動画は、すでにオンデマンドで公開されていました。スライドの詳細は動画をご覧ください。

summitjapan.awslivestream.com

責任あるAIが求められる背景

AIは「生成AIアシスタント」→「AIエージェント」→「Agentic AIシステム」へと進化しています。人間の介入が減り、自律性とビジネスインパクトが増大する一方で、万が一のインシデント時の影響範囲も拡大します。

実際にAIによるインシデント報告件数は増大傾向にあり、累計12,152件（2022/01〜2026/03）。前年同月比+106.3%（2026/03: 594件 vs 2025/03: 288件）と、AIの進化に比例してリスクも増えています。

身近なユースケース（不動産の物件紹介、通販サイトのレコメンドエージェント）で考えても、公平性、ハルシネーション防止、個人情報保護、プロンプト攻撃への耐性など、AIを搭載することで新たに考慮すべき課題が増えることは想像に難くありません。

AWSが考える「責任あるAI」の8観点

AWSが定義する責任あるAIの8観点は以下の通りです。

公平さ: さまざまなステークホルダーのグループへの影響を考慮する
説明可能性: システム出力を理解して評価する
プライバシーとセキュリティ: データとモデルを適切に取得、使用、保護する
安全性: 有害なシステム出力と誤用を防ぐ
制御性: AIシステムの動作をモニタリングおよび制御するメカニズムを備える
正確性と堅牢性: 予期しない入力や敵対的な入力があっても、正しいシステム出力を実現する
ガバナンス: プロバイダーやデプロイヤーを含むAIサプライチェーンにベストプラクティスを組み込む
透明性: ステークホルダーがAIシステムとの関わりについて十分な情報に基づいた選択を行えるようにする

ベストプラクティスと方法論

AWSは以下のリソースを公開しています。

AWS Well-Architected Responsible AI Lens: 設計・開発・運用の各段階で考慮すべき事項をアセスメントできるカスタムレンズ
Agentic AIベストプラクティスレンズ（2026年6月10日公開）: エージェンティックAI向けのアセスメント項目

シフトレフト: 開発部門にも責任あるAIを担わせる

責任あるAIを監査部門やリスク部門だけに押し付けず、開発組織自身が担う（シフトレフト）という考え方が紹介されました。

ベストプラクティスを開発過程に組み込む

責任あるAIのベストプラクティスをドキュメント化し、コーディングエージェントが読み込める場所に置いておく。AIが開発中にバイアスのかかった出力をした場合、その時点でリリース基準に対して不合格とし追加対処を行う。Kiroのステアリングファイルとして自社のAIポリシーを組み込む例も紹介されました。

AWSサービスでの実装例

Bedrock Guardrails: ガードレールの実装

有害コンテンツのブロック、ハルシネーション防止、PII（個人情報）のマスキング、プロンプト攻撃への防御を提供します。

直近のアップデートとして:

リソースを作らずに呼べるAPI: ガードレールリソースを事前に作成せずとも、リクエストごとに必要なチェックだけを手軽にかけられる
Bedrock AgentCoreポリシーとの統合: エージェントに到達する前にガードレールでブロック可能に

CloudWatch: 監視と洞察（インサイト）

Bedrock Guardrailsのテレメトリとして、以下が確認できます:

ガードレール介入回数と入力/出力の区別
どのポリシーが適用されたか
機微情報の検出種別
ユーザー単位での呼び出し状況
ガードレールのレイテンシ（性能影響の確認）

CloudWatch Alarmで「5分以内に同一理由の呼び出しが5回以上」等のトリガーを設定することで、常時人が監視していなくても危険な挙動をタイムリーに検知できます。

継続的な改善活動

ガードレールによる制御とCloudWatchによる監視を実装しても、一度やって終わりではありません。経営層を含む組織的な対応→コントロール実装→継続的な監視・監査→改善と最適化のサイクルを回し続けることで、より高度なリスクにも対応できるようになります。

お客様事例: Indeed様

Indeed様は6億3,500万人の求職者と330万の雇用主が登録する求人マッチングサービスを展開している企業です。月間1,060万件のLLMリクエストを処理しており、人力でのチェックは不可能な規模だそうです。

海外で提供している「Indeed Career Scout」では、AIがキャリアを提案し、Fit Check（マッチング度合い）を提示します。なぜそのポジションが提案されたかの説明可能性や、AI生成であることの明示（透明性）も実装されています。

Indeed様の責任あるAI戦略: Anticipate→Guardrail→Observe

Anticipate（予測）: AIレッドチーミングにより、攻撃役LLMが攻撃的プロンプトを送り、審判役LLMが目的達成度を判定。リリース前にリスク対応性能を確認
Guardrail（制御）: 不適切発言、文脈逸脱、プロンプトインジェクション等に対するリアルタイムガードレールを実装
Observe（観測）: 本番環境をモニタリングし、改善の優先順位と新たなパターンを把握

特徴的だったのは、開発部門だけでなく、責任あるAI部門、セキュリティ/ガバナンス部門、法務部門、ブランド部門が一堂に会し、AI Constitution（AI憲法）として目指す良いサービスの仕様を文書化した点です。組織として一丸で取り組んでいるとのことです。

成果として、本番環境に適用されたガードレール17種類、月間1,060万件のLLMリクエストを全件スクリーニングできたそうです。

まとめ

責任あるAIの8観点（公平さ、説明可能性、プライバシーとセキュリティ、安全性、制御性、正確性と堅牢性、ガバナンス、透明性）を押さえる
ベストプラクティスを理論で終わらせず、開発の仕様に組み込んで設計段階から取り入れる
Bedrock GuardrailsとCloudWatchで実装・監視し、組織として継続的に改善サイクルを回す

今日から試せる3つのこと

Responsible AI Lensで自社のAI環境を評価する
AWS Skill Builderで「責任あるAI」を学ぶ
Kiroで「責任あるAI」を仕様に組み込んで開発する

所感

「なぜ必要か」→「何を押さえるか」→「どう実装するか」→「実例」と段階的に解像度が上がっていく構成で、Responsible AIに初めて触れる人でも理解しやすい内容だったと思います。

Indeed様の事例も参考になりました。月間1,060万件規模で全件スクリーニングを実現していること、そして「AI Constitution」として組織横断で価値観を文書化してから実装に入るという進め方は、規模を問わず取り入れられるアプローチではないかなと思いました。

悔やんでいるのは、質問できなかったこと… Indeed様が組織横断でAI Constitutionを文書化するに至るまで、そして文書化した後も各部門が歩調を合わせて進められたのか、定期的なミーティングを全社横断で実施したのか、どのくらいの時間をかけて合意形成したのか… 機会があればぜひ聞いてみたいです。