OpsJAWS Meetup33 AIOps
 2025/03/04 Amazon Bedrockガードレールで守る 安全なAI運用 株式会社BLUEISH 代表取締役CEO兼CTO 為藤アキラ @AkiraTameto 

為藤 アキラ (Akira Tameto) 株式会社BLUEISH 代表取締役 CEO兼CTO ・AWS歴12年 ・直近のAIプロジェクト マルチAIエージェントサービス 「BLUEISH Agents」の開発 自己紹介 

AI Ops観点での安全なAI運用の重要性 • 大規模言語モデル(LLM)の活用が企業で急増 • 不適切コンテンツ / 機密漏洩リスクが企業が抱える大きな課題 • 運用担当 (Ops)としては監視 / アラート / ポリシー管理が必須 • インシデントが起きると信用問題 / 法的リスクに直結 

Amazon Bedrock ガードレールとは？ • Amazon Bedrock のエンタープライズ向け機能の一つ • 生成AIの不適切な入力・出力を制御し、企業ポリシーに合わせてフィルタリングする仕組み • モデル種類にかかわらず一貫した安全対策を適用可能 アプリケーション ユーザー ガードレール Amazon Bedrock LLMモデル 不適切な入力をブロック フィルタ 出力 入力 

ガードレールの4つのフィルター 1. Denied topics 　 → 回答してはいけないトピックを自然言語ベースで設定 2. Content filters 　 → ヘイト・差別・暴力などを検知し自動遮断 3. Sensitive information filters (PIIフィルター) 　 → 個人情報・機密情報が出力されそうになったらブロック／マスク 4. Word filters 　 → 特定の単語やフレーズを指定してフィルタリング 

AI運用での課題 1. 回答できないトピックをどう管理するか？ 2. 不適切コンテンツをどう遮断するか？
 3. 個人情報・機密をどう守るか？
 

課題に対しての解決！ Amazon Bedrock ガードレールの機能！ 1. 回答できないトピックをどう管理するか？ 　 → 「 」 で回答禁止領域をシステム的にブロック 2. 不適切コンテンツをどう遮断するか？
 3. 個人情報・機密をどう守るか？
 Denied topics 

課題に対しての解決！ Amazon Bedrock ガードレールの機能！ 1. 回答できないトピックをどう管理するか？ 　 → 「 」 で回答禁止領域をシステム的にブロック 2. 不適切コンテンツをどう遮断するか？
 　 → 「 」 でリアルタイムでヘイト・差別・暴力を検出 3. 個人情報・機密をどう守るか？
 Denied topics Content filters 

課題に対しての解決！ Amazon Bedrock ガードレールの機能！ 1. 回答できないトピックをどう管理するか？ 　 → 「 」 で回答禁止領域をシステム的にブロック 2. 不適切コンテンツをどう遮断するか？
 　 → 「 」 でリアルタイムでヘイト・差別・暴力を検出 3. 個人情報・機密をどう守るか？
 　 → 「 」 で個人情報を自動マスキング Denied topics Content filters Sensitive information filters 

Amazon Bedrock ガードレールの強みは「事前防御」 Amazon Bedrockのガードレールは、この「 」を複数モデルに対して統一ポリシーで実 行できるのが強みです。
 「 」とは、LLMに不適切な回答を渡す前に、不適切なやり取りや危険な内容が存在しな いかを自動的にフィルタリング・ブロックする仕組みを指します。 事前防御 事前防御 アプリケーション ユーザー カードレール Amazon Bedrock LLMモデル 不適切な入力をブロック フィルタ 出力 入力 事前防御！ 

Amazon Bedrock ガードレールによる保護体制の比較 vs 事前防御（Proactive Defense） 事後防御（Reactive Defense） 入力ガードレール 出力ガードレール LLMモデル 安全な応答 事前防御の特Š € ユーザーに不適切なコンテンツが届く前に遮x € 入出力の両方でフィルタリングを実g € 問題が発生する前にリスクを低™ € レビュテーションと信頼の保護に効果的 事後防御の課Ù € 不適切なコンテンツが既にユーザーに届いた後の対À € 肥大が発生した後の修復は信頼回復が困± € 問題検出までのタイムラグが発生する可能¦ € レビュテーションリスクと法的リスクが高い 応答(未フィルタ）
 潜在的リスクあり インシデント対応 LLMモデル 問題への対応タイミングが 異なる モニタリングで問題検出! 

AI Opsとしての設計から運用までの流れ ガードレールをきちんと生かすには設計から運用まで多層的に考えるのが重要。 fc 初期設計で安全策を組み込む ‚c 多層防御と継続モニタリング Š Bedrock Guardrails＋ IAM/ネットワーク 制御＋定期アセスメンl Š CloudWatchなどでコンテンツブロック数 を監視、異常値を即発見 ‘c ハルシネーション対策・PII保護 Š RAG（検索拡張型）との併用や幻覚検出設 定、PIIマスク設定のテスト Çc インシデント対応計画 Š もし不適切回答が漏れた場合、どのように 修正・ユーザー通知・再発防止するかまで ルール化 úc 権限管理と変更管理の徹底 Š ガードレールの設定変更には承認フローを 導入し、CloudTrailでログを追跡 Š システム全体でガードレールの導入を
 前提にし、セキュリティ要件を明確化 

インシデント対応計画の深掘りと運用サイクル インシデント対応サイクル 不適切な応答発生時の対応プロセス a ベースラインとして設定しているガードレール ルールが正しく適用されているか確認 (IAM, Config, Guardrailsバージョン等V a 問題の回答や入力ログを精査し、どういう経緯 でガードレールを抜けたか (新種の不適切ト ピック？ NGワードのすり抜け？ ルール記載漏 れ？) a 必要に応じてガードレールを強化 (新たなNGワード 追加、トピック拒否拡張などV a 問題影響範囲を特定し、既に不適切回答を受
 取ったユーザーへのフォロー（謝罪や回答再送） a CloudWatchアラームが発火 (ブロック回数急増、 またはブロック激減V a ユーザーからの「不適切回答があった」という通報 a 設定変更ミス、ガードレールの仕様上の限界、 モデルのバージョンアップによる動作変化など を洗い出h a ガードレール漏れが再発しないように運用ルー ルやチェック体制を修正 a 追加テストケースやレッドチーム評価の 実¤ a IAMポリシー・Configルールで「常に ガードレールを有効にする」強制ルール を導入す© a ユーザー通報フローの強化、開発チー ム・セキュリティチームとの連携プロセ ス見直し ②
 初動対応 ①
 検知 ③
 封じ込め ④
 根本原因
 の調査 ⑤
 再発防止策 

まとめ ™– Amazon Bedrock ガードレール 　 事前防御型で複数モデルを一括管` W– ガードレール + 他サービスと組み合わせ 　 Bedrockに CloudWatch監視 / IAM / Config等と組み合わせてリスク低減
 3. AI Ops視点でAI運用成功の為のサイクル 　 セキュリティ要件の明確化 + 継続的なポリシー更新 + インシデント計画 

Thank You!