AWS Bedrock Guardrailsの導入取り組み:前編-生成AIセキュリティの必要性

0. はじめに

KINTOテクノロジーズのCloud Infrastructure G(CIG)でInfrastructure Architectを担当している劉(YOU)です。

AIの著しい進化に伴い、世界的に生成AIを活用して様々な取り組みを実施することが日常になりました。生成AIをどれだけ使いこなせるかが重要ですが、併せて生成AIを利用することにより発生するリスク対策も重要になります。

弊社の今年の年間テーマとしてAIファーストが掲げられており、積極的なAI活用を始め社内外で多くの活動を実施しています。社内ではさまざまな部署が生成AIを活用したアプリケーションの開発をする動きが増えています。しかしそれに比例するように生成AI利用におけるセキュリティ対策の重要性も増しており、アプリケーションの開発スピードを落とすことなく実施できる対策の検討が急務となっています。

社内のクラウド環境に責任を持つCIGでは、社内のSCoEチームが発表している様々なAIセキュリティ関連の資料を元に、生成AIセキュリティを実現するために何をすべきかという点で取り組みの優先順位を決めました。OWASP Top 10 for LLM Application 2025をKTCのクラウド環境に適した内容になるよう整理し、それを実現する方法として生成AIガードレール、特にAWS Bedrock Guardrailsを採用することにしました。

本記事ではこのような背景の中で、我々がAWS Bedrock Guardrailsの導入に向けて取り組んだことを詳しく解説します。下記の事項を中心に前編と後編で分けてご紹介します。

• なぜ生成AI活用でセキュリティを確保する必要があるのか
• 生成AIの安全を担保するために生成AIガードレールがなぜ重要なのか
• 生成AIガードレールの中でもなぜAWS Bedrock Guardrailsを選択したのか
• 今までKTCがAWS Bedrock Guardrailsで何をやっているか

前編である本記事では、生成AIセキュリティの必要性と実現するための生成AIガードレールの概要についての情報を記載します。後編でご紹介するAWS Bedrock Guardrailsの具体的な説明の前に、「生成AIセキュリティ」と「生成AIガードレール」についての基本的な考え方を整理し、それを踏まえてAWS Bedrock Guardrailsの役割を正確にご理解いただけるような情報をご提供します。なお、生成AIのセキュリティ全領域をカバーするとなると内容が長くなり過ぎるため、生成AIガードレールを中心とした内容を簡単に取り上げます。

後編では、生成AIガードレール適用のためのAWS Bedrock Guardrailsについてまとめる予定です。理論の話がメインの前編とは違い、後編では主にAWSを使った実装ベースの解説を行います。元々は後編のみの記事を書く予定で書き始めたのですが、この話題でセキュリティの前提となる情報を割愛することは難しかったので前編・後編に分割することにしました。AWS Bedrock Guardrailsの取り組みについては後編で重点的に扱いますのでご留意ください。

本文書ではLLMs at Scale.aiのJothi Periasamy氏の著書Guardrails-GEN-AI-Government-Servicesから主要な考え方を多く参考にさせていただきました。生成AIガードレールに興味があり、深掘りしたいという方は是非ご覧になって下さい。

1. 生成AIセキュリティの重要性

1-1. 生成AIのセキュリティリスク

ここ最近では、生成AIのアップデートに関するニュースを目にしない日はありません。日本国内を見ても、生成AIの導入が加速化し、それとともに企業や公共機関が直面するセキュリティリスクとそれに対応する方法への関心が高まっているように思います。 これから繰り返し生成AIの脅威について取り上げますが、その中でも最も代表的なセキュリティリスク^[1]には次のようなものがあります。

1-1-1.代表的なセキュリティリスク

このようなセキュリティリスクは国内でも深刻に受け止めてられており、日本政府からも各AI事業者に対して積極的に高いセキュリティガバナンスを保つことを要求しています。

海外との交流では2023年G7議長国として、基盤モデル及び生成AIを含む高度なAIシステムを議論する広島AIプロセス^[2]を主導し、国際行動規範を設けました。

国内では、総務省と経済産業省が2024年4月にAI事業者ガイドライン^[3]を発表しました。 このガイドラインは広島AIプロセスの内容を踏襲しており、人間中心、安全性、プライバシー保護など10項目を含めています。

1-1-2. 国内外の生成AIセキュリティに対する動き

しかし、政府が積極的にAIセキュリティの推進を行ってはいるものの、現在はまだガバナンス未整備の企業が大多数です。その理由としては色々有りますが、客観的な情報を提示しながら考察してみます。

1-2. 統計で見る生成AIセキュリティの現状

日本企業を対象にした生成AIとセキュリティに関する意識調査^[4]では次のような結果がでています。

1-2-1.生成AIとセキュリティに関する意識調査

この時、回答者が心配したリスク要素として「法的権利の侵害(64%)」、「情報漏洩(61%)」、「ハルシネーション(56%)」、「不正・不具合の混入(34%)」が上位にランクインしており、前述したセキュリティリスクと実際の企業が感じてる危険要素^[1:1]とも結果が合致しています。

特に法的に問題視される内容が1・2位に揃ってランクしており、各企業が個人情報保護法の順守を重要視していることが見て取れます。2024年改正でのウェブスキミング対策^[5]を見ても、国として流出等発生時の報告·通知義務と安全管理措置の対象が拡大していることがわかります。 生成AIの運用時にも、これらの規定を遵守するための取り組みが欠かせません。

こういった流れを見ると、改めてセキュリティリスクに対する懸念が生成AIの利用に影響を与えていると強く感じます。

総務省の情報通信白書^[6]によると、業務における生成AIの活用状況の実体は国別に次のような結果が出ています。

1-2-2.業務における生成AIの活用状況^[6:1]

日本で46.8％（“業務で使用中”と回答した割合）であり、他国と比較するとその割合は低い。“トライアル中”までを含めると、米国、ドイツ、中国の企業は90％程度が使用しており、日本企業は社内向け業務から慎重な導入が進められていることがわかった

日本企業の生成AI使用率は世界的に比べて低い水準ですが、これは主にデータ、資産、個人情報などのリスク管理方案およびガバナンス体系の不在^[7]だと述べています。これを見ても、AIシステム開発の一連のガバナンス政策を計画する段階から商用化後まで、全段階にわたって構築することが重要であることが分かります。
詳細のデータは右のリンクを参照「IPA DX白書2025」

前述の調査^[4:1]では、回答者の77%が生成AIを使用していますが、その内の27.1%が生成AIに関するセキュリティ教育がないと回答し、全回答者の93.6%が「関連ガイドラインを整備中」と答えました。つまり、回答者が属している企業の大多数が安全なガイドラインを必要と感じているということです。

1-3.　安全なガイドライン

これらのデータを踏まえ、「安全なガイドラインを作成」 するために一番重要なことはなんでしょうか？この問いの答えの一つになるのが構造化された生成AIガードレールの採用です。ガードレールにはプライバシーリスクや入力値・出力値を検査し、セキュリティプロトコルを強制する統制を可能にし、インジェクション/ハルシネーション、毒性（Toxicity、生成AIが有害なコンテンツを生成するリスク）などのリスクを緩和する仕組みが取り入れられています。

一般的なガードレールは、主に行動を許容するかブロックするかに焦点を当てています。しかし、生成AIにおけるガードレールには、倫理的な運用目標も含まれます。「有害であったり、テーマから外れた出力を検知し、それを予防するメカニズムを導入すること」が、この分野におけるAI主導の運用を実現する鍵となります。これは単に脅威を阻止するだけでなく、AIの動作に直接関与することを意味します。特に、生成AIガードレールを適切に適用する戦略によって、高い透明性、責任性、安全性を確保した状態で生成AIを利用することが可能になります。

2. 生成AIガードレールについて

2-1.　概要

生成AIガードレールとは、生成AIシステムが安全かつ倫理的に動作し、組織の目標や社会の価値観に適合することを保障するための構造化されたフレームワーク、指針です。ガードレールは、AIシステムの入力、処理、および出力を制御する役割を果たします。このような制御は、迅速なインジェクション、個人情報の流出、ハルシネーション、偏見といった危険を軽減することで、出力結果が正確で安全かつ関連性のあるものであることを確認するのに役立ちます。特に、組織が法的基準を順守し、倫理的原則を守り、機密情報を保護できるようサポートします。

一般的には、企業が提供するGPT, Claude, Geminiのような基盤モデルの場合、ある程度のセキュリティが自主的に保証されていますが、それでも完璧ではありません。最近の研究^[8]によると、テストされたすべてのLLM（大規模言語モデル）は基本的な脱獄攻撃に対して依然として非常に脆弱であり、一部のモデルは特別な迂回の試みがなくても有害な結果を提供することが確認されています。そのため、このようなガードレールの重要性はさらに高まっています。

生成AIソリューションでのガードレールは次の3つの段階で実現します。

1. 入力段階 (プロンプト/ユーザー質問): ユーザー入力の有効性検証と悪意のあるプロンプトブロック

2. 検索段階（拡張コンテンツ）:RAGシステムで検索された情報の品質と関連性検証

3. 出力段階(応答): 生成された応答の安全性、正確性、適切性の検証

様々なタイプのガードレール制御がありますが、一般的にガードレール制御はこうなります。

2-1-1.一般的なガードレール制御

さらに、これらすべてのコントロールは、ビジネスとセキュリティの要件に応じて高度にカスタマイズできます。 すべてのガードレール アーキテクチャ オプションは、ビジネスの要件とセキュリティ ポリシーによって決定されます。

2-2.　アーキテクチャ

ガードレールの実装には様々な方法がありますが、まずは方法論的な部分を整理してみましょう。

単純なRAGアーキテクチャ^[9]は、外部システムと相互作用せず、独自のランタイム環境内でのみ動作し、エージェントが関与しない実装方式です。

2-2-1.単純なRAGアーキテクチャ

ナレッジベース、意味検索、順位、ベクトルデータベースのようなLLMおよびそのサポートプロセスと直接相互作用を重視し、カスタマイズされたガードレールコンポーネントのようなガードレールコントロールを使用して、ユーザープロンプトとLLM応答およびナレッジベース検索を制御します。 簡単に設計·実装できるため、オープンソースソリューションと組み合わせて使用する場合は、この方法を採用することをお勧めします。

エージェントベースのアーキテクチャ^[10]は、外部システムおよびアプリケーション、メモリ、コード インタープリタ、外部システムの呼び出しなど、さまざまなタイプのツールが存在します。 ここでは、エージェント アーキテクチャ タイプによってガードレールの制御が決まります。

2-2-2.エージェントベースのアーキテクチャ

例えば、スーパーバイザーエージェントがいるエージェントアーキテクチャでは、スーパーバイザーエージェントと協業エージェント間の共通ガードレール制御を通じて、より複雑なセキュリティシステムを実現することができます。 しかし、エージェントを活用するアーキテクチャはまだベストプラクティスが成立できてないことで、複雑度も高いし、実装も非常に難しい状態になっています。そこで、技術変化を対応しているエンタープライズソリューションを活用したら、検証されたエージェントベースのアーキテクチャをすぐに使えます。

2-3.　実装するための選択肢の比較

2-3-1.ソリューションの種類

次に、企業でガードレールを適用する際に
・オープンソースソリューションを採用して独自にガードレールを構成する
・エンタープライズソリューションを採用してガードレールを構成する
について長所と短所を比較してみましょう。

評価項目	Open Source Soulution	Enterprise Soulution
初期コスト	◎	△
人的コスト	x	○
ライセンスコスト	◎	x
カスタマイズ性	◎	△
ベンダー依存性	◎	△
定期的アップデート	△	◎
技術的専門性要求	x	○
専門サポートサービス	△	◎
セキュリティ関連対応力	△	◎

2-3-2.ソリューションの長所と短所
非常に良好：◎、良好：○、不良：△、非常に不良：x

オープンソースソリューションを利用して実装すると、自社独自の要件とドメインに合わせてカスタマイズできます。 そして、ビジネス要件に合うように内部データとサービスロジックに特化した細かい制御が可能だという点は非常に大きなメリットです。 さらに、他のオープンソースを活用するのと同様に、初期コストが節約されるだけでなく、特定のベンダーロックインも防止できます。

しかし、オープンソースソリューションを利用して実装するということは、AIに対する高い技術的専門性と開発ができる専門部隊が必要になります。 そして、該当ガードレールに対して持続的なアップデートとメンテナンスが発生し、専任のAI関連部署が存在しなかった場合、一般的な企業では人的コストが大幅にかかってしまいます。 そして結局、カスタマイズをした瞬間から自主的にガードレールの評価を進めなければならないため、検証されていないセキュリティホール^[11]が存在する可能性があります。 何よりも安全なガイドラインがない状況であれば、要件を定義することからが問題になります。

その為、上記を運用できない場合はエンタープライズソリューションの利用が有効です。 すぐに使用可能な検証済みのセキュリティ機能を持っており、随時発生するセキュリティイシューに対して持続的なアップデートと専門的なサポートサービスを提供します。 そして生成AIセキュリティに要求される多様な規定を自動的に支援してくれます。 つまり、「安全なガイドラインの作成」をすぐに享受できるのがエンタープライズソリューションだということです。

ただし、エンタープライズソリューションはライセンスコストや使用量によるコスト増が発生します。 そして、特定ベンダーのガードレールオプションを使用することになれば、特定ベンダーへの依存性が増加することも避けられません。 また、自分たちのビジネス要件に合ったガードレールを実装したい場合、カスタマイズオプションの制限が存在する可能性があります。これは独自のセキュリティ規定が存在する場合、その規定を準拠できないかも知れません。

もちろん、エンタープライズ ソリューションの欠点を補完した事例も存在します。 私が今まで調べたところ、かなり理想的な形はブルームバーグのハイブリッドガードレール戦略があります。 下記はブルンバーグのAIグループ首席エンジニアであるラーマン氏の話^[12]です。

これらすべてを実現するために、ブルームバーグはオープンソースモデルと商用モデルの両方を使用し、内部で訓練されたモデルも使用しています。 「私たちは特定の技術と強結合されていません」とラーマン氏は言います。 つまり、1つのプラットフォームのガードレールを使用するだけでは十分ではないということです。 ブルームバーグが1つのスタックで成功したとしても、同社は既製のガードレールツールが提供するものを超えることを望んでいるだろうと、彼は言います。

2-3-3.スイスチーズモデル

様々なガードレールを重畳させるスイスチーズ戦略を活用して、特定のガードレールにセキュリティ欠点が発生しても、幾層にも重なったガードレールで問題発生を防止できるようにしました。本当に理想的で優れた方法だとは思いますが、このような方法をする状況は非常に厳格なセキュリティ規定とリソースが存在する時に行うものだと思います。 その為、大多数の企業は合理的なガードレールを選定するために、多くの考慮をする必要があります。 もう少し本質的な内容に近付けるためには、ガードレールの設計についての領域に触れることになります。

2-4.　アプローチ・設計

「Building Guardrails for Large Language Models」^[13]という論文ではAIガードレール構築について深層的に扱っています。ここではAIガードレール設計は技術的複雑性と多様な利害関係者の要求事項をバランスよく調和させなければならない複合的な課題だと定めています。

KTCが主に考慮した部分はConflicting Requirements(相反する要求事項)、Multidisciplinary Approach(多学際的アプローチ)の二つの側面について扱っております。独自にガードレールの開発はしないため、開発論について扱う残りの二つは除外しました。

相反する要求事項はAIの安全性と性能の間の相反する要求事項を解決することを意味します。

2-4-1.相反する要求事項

全てのガードレールを最初から適用してセキュリティを保障しようとしても、求める答えを出さないAIなら、AIを使用する目的自体が失われることになります。 そのため、最も重要なガードレールから始めて、必要に応じて徐々に範囲拡張することをお勧めします。

ガードレールを徐々に拡張するためには多くの学際的アプローチも必要です。 これは、技術的専門性、倫理的フレームワーク、ガバナンス構造、利害関係者の関与を組み合わせることを意味します。 例えば、 弊社ではSCoE(Security Center of Excellence)チーム、AI First部、プラットフォームG、クラウドインフラGなど多様な利害関係者がキックオフから参加しており、AIシステム構築初期から各分野の専門家集団がKTCに必要なガードレールの検討/適用を実施しています。そのガードレールを適用したAIシステムの一つがAgent-store^[14]です。

2-5.　統合(Integration)

最後に、ガードレールは完全なセキュリティを保証するサービスではないことを注意する必要があります。 単一のガードレールではすべてのセキュリティリスクを完璧に防御することはできないし、ガードレール以外でも様々な側面からセキュリティリスクを考慮する必要があります。 例としては次のとおりです。

2-5-1.生成AIガードレールの統合

その他にも説明できなかった要素が存在しますが、ガードレールだけで生成AIセキュリティを担保することはできず、様々な観点での対応が必須ということを理解していただければと思います。

3. まとめ

生成AIの活用が本格化する中で、個人情報流出やプロンプトインジェクション、ハルシネーションなど、従来にはなかった多様なセキュリティリスクが顕在化しています。日本国内でもAIセキュリティに対する意識は高まりつつあり、政府・民間ともにガイドラインやガバナンスの整備が進められていますが、実際の現場では依然として不安や課題が残っています。

こうした状況において、生成AIガードレールは、AIシステムの安全性・倫理性を担保し、組織の目標や法規制に適合したAI活用を実現するための重要な仕組みとなります。ガードレールは入力・出力段階での検証やフィルタリングを通じて、さまざまなリスクを低減し、AIの有用性と安全性のバランスを実現します。

生成AIガードレールの実装にはオープンソースソリューションやエンタープライズソリューションなど複数の選択肢があり、それぞれにメリット・デメリットがあります。各社のリソースや要件に応じて最適な構成を選択することが重要です。また、生成AIガードレールだけに依存するのではなく、プロンプトエンジニアリングやPCS(People Centric Security)、継続的なモニタリングなど、様々なセキュリティ対策の組み合わせが必要となります。

AIセキュリティの実現には、技術面だけでなく、法務・倫理・ガバナンスなど多様な観点からのアプローチと、いくつもの専門部署の連携が欠かせません。まずは最も重要なリスクから段階的に生成AIガードレールを導入し、状況に応じて拡張していくことが、実践的で現実的な戦略となります。

KTCでも生成AIのセキュリティをどのように保障するかを検討し、多々実施している施策の1つとして生成AIガードレールを導入しています。

次回（後編）の記事では、今回の記事の内容を踏まえ、どういった観点から AWS Bedrock Guardrails の採用に至ったのか、AWS Bedrock Guardrails はどのように機能するのか、そしてAWS Bedrock Guardrailsを通じてどのような試みをしたのかについて取り上げる予定です。ぜひお楽しみに！

---

脚注

1. https://llmatscale.ai/publications.php#Guardrails-pub ↩︎ ↩︎

2. https://www.soumu.go.jp/hiroshimaaiprocess/documents.html ↩︎

3. https://www.meti.go.jp/press/2024/04/20240419004/20240419004.html ↩︎

4. https://resources.trendmicro.com/jp-docdownload-form-m747-web-awareness-survey-generative-ai-security.html ↩︎ ↩︎

5. https://blog.jpac-privacy.jp/revisionofguidelines_202404/ ↩︎

6. https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r06/html/nd151120.html ↩︎ ↩︎

7. https://www.jri.co.jp/page.jsp?id=108778 ↩︎

8. https://www.aisi.gov.uk/work/advanced-ai-evaluations-may-update ↩︎

9. https://github.com/AnandJVishwakarma/Gaurdrails-for-RAG-Pipeline ↩︎

10. https://langchain-ai.github.io/langgraph/concepts/agentic_concepts/ ↩︎

11. https://secure-navi.jp/blog/000037 ↩︎

12. https://www.cio.com/article/2503234/how-guardrails-allow-enterprises-to-deploy-safe-effective-ai.html ↩︎

13. https://arxiv.org/abs/2402.01822 ↩︎

14. https://blog.kinto-technologies.com/posts/2025-05-30-Agent-Store/ ↩︎