AIセキュリティとは。生成AI利用の5つのリスクと国内完結クラウドでの守り方
「生成AIを業務で使いたいが、社内データを入れて本当に大丈夫なのか判断できない」という方も多いでしょう。情報システム部門は漏洩を心配し、法務は個人情報保護法との整合を気にし、経営企画は現場の利用実態を把握しきれていない、というように、部門ごとに違う不安を抱えたまま議論が止まってしまうケースをよく見かけます。
ただし、「危ないから禁止」という判断だけでは、現場は個人アカウントでこっそり使う「シャドーAI」に流れてしまい、かえって管理の目が届かなくなります。本当に必要なのは、AIセキュリティの全体像を整理し、リスクごとに正しい対策を組み合わせることです。
そこで本記事では、
- AIセキュリティとは何か、Security for AIとAI for Securityの違い
- 生成AI利用で押さえるべき5つのリスクと、実際に起きた事例
- 個人情報保護法・越境移転規制という法務面の論点
- Amazon Bedrockを例にした、クラウドでの具体的な多層防御の設計
についてわかりやすく解説します。生成AIの利用可否を社内で判断する立場にある情報システム・法務・経営企画のご担当者は、ぜひ最後までご覧ください。
「自社のAIセキュリティ対策をどこから整理すればよいか分からない」という方は、リベルクラフトへご相談ください。
⇨リベルクラフトへの無料相談はこちら
AIセキュリティとは
AIセキュリティとは、AI・生成AIの活用にともなうリスクを管理し、安全に利用できる状態を保つための取り組み全般を指します。ひとくちに「AIセキュリティ」といっても、実は性質の異なる2つの意味が混在しているため、まずこの整理から始めます。
Security for AIとAI for Securityの違い
AIセキュリティは大きく「Security for AI（AIを守る）」と「AI for Security（AIで守る）」の2軸に分けられます。
Security for AIは、AI・生成AIを利用することで生じるリスク、つまり情報漏洩やハルシネーション、著作権侵害などから自社を守るための対策です。一方、AI for Securityは、AIを活用してサイバー攻撃の検知や脆弱性診断を効率化する、いわば「守るためにAIを使う」という文脈です。
本記事が扱うのは前者のSecurity for AI、すなわち生成AIを業務で利用する際に企業が押さえるべきセキュリティです。情報システム・法務・経営企画が日常的に直面する「AIに何を入力してよいか」「クラウドで使って安全か」という問いに、正面から答えていきます。
AIセキュリティが注目される背景
AIセキュリティが急速に注目を集めている背景には、生成AIの利用実態と統制の乖離があります。PwC Japanの2025年調査では、日本の従業員の52%が個人契約のAIツールを業務に使用した経験があると回答しています。会社としてルールを整備するより先に、現場での利用が先行している状況です。
こうした「シャドーAI」を放置するコストも明らかになりつつあります。シャドーAIが関与したデータ侵害の平均コストは527万ドルにのぼり、AI利用を監視していない企業は、厳格に管理している企業と比べて平均67万ドル高い損失を被るという分析もあります。Gartnerは、2027年までにデータ漏洩の40%がAI・シャドーAIの誤用に起因すると予測しています。
つまり、AIセキュリティは「禁止するか、許可するか」の二択の問題ではなく、すでに現場で使われている前提のもとで、どこまでを可視化し、どう安全な形に統制するかという設計の問題になっています。
生成AI利用で押さえるべき5つのリスク
背景を踏まえたうえで、生成AI利用に固有のリスクを具体的に整理します。上位表示される他社解説記事でも複数のリスクが取り上げられていますが、本記事では代表的な5つに絞って、実際の事例とあわせて解説します。
1. 情報漏洩・機密情報の露出
もっとも警戒されるのが情報漏洩です。入力した情報が生成AIモデルの学習に使われ、別のユーザーへの回答を通じて外部に流出する可能性があります。
広く知られている実例として、2023年にサムスン電子のエンジニアが、社内の機密ソースコードや会議録を少なくとも3件、ChatGPTに入力してしまった事例があります。同社はこれを受けて生成AIの利用を一時全面禁止し、社内専用AIの構築に方針を転換しました。この事例のポイントは、「AIを使ったこと」自体ではなく「管理されない環境で機密情報を入力してしまったこと」にあります。学習に使わない契約形態や、入力してよい情報の線引きが整っていれば防げた可能性が高いといえます。
参照：サムスン電子の情報漏洩事例｜Impress Watch
2. 越境移転によるデータ主権の喪失
2つ目は、入力したデータが自社の想定していない国・地域で処理される「越境移転」のリスクです。生成AIサービスの多くはグローバルに展開されており、意識しないまま海外のリージョンでデータが処理されている場合があります。
これは単なる技術的な話にとどまらず、日本の個人情報保護法における外国第三者提供のルールに関わる法務論点でもあります。詳しくは後述の「個人情報保護法とAIセキュリティの関係」で解説します。
3. ハルシネーション・誤情報の拡散
3つ目は、生成AIがもっともらしい誤情報を生成する「ハルシネーション」です。事実と異なる内容を、あたかも正しいかのように出力してしまう現象を指します。
社内向けの補助であれば誤りに気づきやすいものの、顧客向けの文書や外部公開のコンテンツにそのまま利用すると、誤った情報が拡散し、信用の毀損につながります。生成AIの出力は必ず人がファクトチェックし、最終的な責任は利用者が負うという運用ルールを徹底する必要があります。
4. 著作権侵害
4つ目は著作権侵害のリスクです。生成AIが学習データに含まれる著作物と類似した内容を出力してしまう、あるいは第三者の著作物をそのままプロンプトに入力してしまうといったケースが該当します。
マーケティング資料や公開コンテンツの制作に生成AIを使う場合は特に注意が必要で、出力結果を無検証のまま公開しない運用が欠かせません。
5. プロンプトインジェクション
5つ目は、悪意のある指示文（プロンプト）をAIに読み込ませることで、本来の制御を無視した動作をさせる「プロンプトインジェクション」です。AIエージェントやRAG（検索拡張生成）のように、外部のデータやツールと連携する仕組みほど攻撃の入口になりやすいという特徴があります。
エージェント型のAI活用が広がるほど重要性が増すリスクであり、AIセキュリティ専門のベンダーもプロンプトインジェクション対策を主要なサービスメニューに位置づけています。
個人情報保護法とAIセキュリティの関係
5つのリスクのなかでも、越境移転は法務上の論点として独立して扱う必要があります。情報システム・法務の担当者が「入れて大丈夫か」を判断する際、実は最初に確認すべきなのがこの法律面の整理です。
個人情報保護法28条が定める外国第三者提供のルール
個人情報保護法28条は、外国にある第三者へ個人データを提供する場合、原則として本人の同意、十分性認定国であること、または基準適合体制の整備のいずれかが必要であると定めています。生成AIサービスに個人データを入力し、その処理が海外のサーバーで行われる場合、この「外国第三者への提供」に該当する可能性があります。
クラウド例外がAIでは効きにくい理由
クラウドサービス全般には、提供先が個人データを取り扱わない場合に外国第三者提供に該当しないとする、いわゆる「クラウド例外」の考え方があります。ただし、この例外が成立するには「外的環境の把握」、つまりデータがどの国のどのような法制度のもとで扱われるかを自社が把握・説明できることが前提になります。
生成AIサービスの多くは、リクエストの処理経路や保存場所がブラックボックス化しやすく、外的環境を正確に把握・説明することが難しいケースが少なくありません。結果として、「クラウド例外だから問題ない」と単純に判断できない場面が生じます。
国内完結が法務説明を軽くする理由
一方で、生成AIサービスの処理を日本国内のリージョンに限定できれば、そもそも外国第三者提供という論点自体が発生しません。越境移転が起きない設計にしておけば、法務は「外的環境の把握」という難しい説明責任から解放され、稟議や監査対応の負担も軽くなります。
| 構成 | 越境移転の発生 | 法務対応の負担 |
|---|---|---|
| 海外リージョン・処理経路が不明確なAI | 発生しうる（外的環境の把握が必要） | 重い（説明責任・監査対応が都度発生） |
| 国内リージョンに限定したAI（国内完結） | 原則発生しない | 軽い（越境移転の論点自体が生じない） |
この表からも分かるとおり、「越境移転をどう管理するか」ではなく「そもそも越境移転を起こさない設計にする」ほうが、法務・情報システム双方の負担を減らせます。次章では、これを技術的にどう実現するかを具体的に見ていきます。
クラウドで実現するAIセキュリティの多層防御
法務面の論点を踏まえたうえで、実際にクラウドサービスを使いながらAIセキュリティをどう技術的に担保するかを、Amazon Bedrockを例に具体的に見ていきます。クラウドセキュリティ・AWSセキュリティの分野でも、生成AI特有の設計が必要になってきています。
学習に使われない・国内リージョンに閉じる設計
Amazon Bedrockは、AWS公式の仕様として、プロンプトや生成された回答を学習に使わず、保存もしないと明記しています。加えて、選択したリージョン内でAPIリクエストが完結する設計になっています。
さらに2025年9月には、日本国内に処理を限定できる「日本国内クロスリージョン推論（JP Geo）」がClaude Sonnet 4.5と同時にGAされました。「jp.」という接頭辞のついたモデルIDを指定することで、処理を東京・大阪の国内リージョンに限定できます。
参照：Amazon Bedrock データ保護｜AWS公式、日本国内クロスリージョン推論の提供開始｜AWS公式ブログ
注意点として、クロスリージョン推論の設定でGlobal（世界共通）やUS（米国）のGeoを選んでしまうと、一時的にデータが国外のリージョンへ移動する可能性があります。JP Geoを明示的に指定し、IAMポリシーで国外Geoの利用を禁止しておくことが欠かせません。
VPC・PrivateLinkによる閉域接続
2つ目の層は、ネットワーク経路の閉域化です。VPC（仮想プライベートクラウド）内からAmazon Bedrockへ、インターネットを経由せずにPrivateLink経由でアクセスする構成を組むことで、データが公衆インターネットに晒されるリスクを排除できます。
社内の基幹システムやデータベースと同じ閉域ネットワークの中でAI活用を完結させられるため、既存のセキュリティポリシーとも整合させやすくなります。
参照：Amazon Bedrock PrivateLinkアーキテクチャ｜Tech Blog
暗号化・Guardrails・IAM/SCPによる多層防御
3つ目以降の層は、データそのものと権限に対する防御です。AWS KMS（Key Management Service）による暗号化では、自社が管理するCMK（カスタマー管理キー）を指定することもでき、保存データ・通信データの両方を暗号化できます。
Amazon Bedrock Guardrailsは、機密情報のフィルタリングや不適切なコンテンツの検出など6種類のポリシーを設定でき、入力・出力の両方を監視できます。さらにIAM（最小権限の原則）とSCP（サービスコントロールポリシー）で誰がどのモデル・リージョンにアクセスできるかを統制し、CloudTrailで操作ログを監査できる状態にしておきます。
学習不使用・国内リージョン限定・閉域接続・暗号化・権限統制という5つの層を重ねることで、単一の対策に依存しない多層防御を実現できるのが、クラウドで国内完結を設計するメリットです。
参照：Amazon Bedrock Guardrails｜AWS公式
ここまで解説した「学習・参照」の区別や情報漏洩の仕組みについては、生成AIで情報漏洩は起こるのか｜「学習・クラウド・公開設定」3つのリスクで判断するでさらに詳しく解説しています。
ここまでクラウドでの多層防御について解説しましたが、「自社の環境でも国内完結の安全なAI活用基盤を構築したい」という方は、リベルクラフトへご相談ください。
リベルクラフトでは、Amazon Bedrockを使った国内完結アーキテクチャの設計・構築支援が可能です。ただ、学習不使用・JP Geo・閉域接続を組み合わせた環境を用意するだけでなく、RAGを活用して社内データを安全に参照させるところまで一貫して構築できるため、自社業務に特化した安全なAI活用基盤の構築が可能です。
以下のリンクからまずは詳細をチェックしてみてください。
⇨リベルクラフトへの無料相談はこちら
AIセキュリティ対策の進め方
技術的な仕組みが分かったところで、実際に自社でどう対策を進めればよいか、機密度別の環境選び分けと具体的なステップに落とし込みます。
機密度別に環境を選び分ける
社内データは「学習させる」のではなく「参照（RAG）させる」対象として扱い、データの機密度に応じて利用する環境を選び分けるのが現実的な進め方です。
| 機密度 | 想定するデータ | 適した環境 |
|---|---|---|
| 一般 | 公開情報・一般的な業務資料 | 国内完結クラウドで広く活用 |
| 社外秘・個人データ | 未公表の技術情報・顧客の個人情報 | 国内完結クラウド（閉域接続・暗号化を徹底） |
| 最高機密 | 門外不出のノウハウ・防衛関連情報等 | オンプレミス・外部接続を遮断した環境 |
すべてを一律に最も厳しい環境で扱おうとすると、コストと導入スピードが見合わなくなります。逆にすべてを一般クラウドで扱おうとすると、機密情報の漏洩リスクを抱えたままになります。この表のように機密度で環境を切り分けることで、「一律禁止」でも「無条件に許可」でもない、現実的な運用が可能になります。
導入の4ステップ
AIセキュリティ対策は、以下の順で進めると着手しやすくなります。
- データを機密度で分類する：一般・社外秘・個人データ・最高機密の区分で、社内データを棚卸しする
- 利用環境をリージョン・接続経路まで含めて選定する：機密度に応じて国内完結クラウドかオンプレミスかを決め、JP Geo・VPC/PrivateLinkの設定まで具体化する
- Guardrails・IAM/SCPで運用ルールを技術に落とし込む：ガイドラインの文言だけでなく、フィルタリングや権限設定として実装する
- 稟議・監査対応の資料を整備する：越境移転の有無、データ保存場所、暗号化方式を説明できる状態にしておく
社内データの棚卸しの具体的な進め方は、データ活用の進め方｜AI導入前に必須の「社内データ棚卸し」5ステップで詳しく解説しています。
稟議で確認すべきチェックリスト
稟議・社内承認を通す際に、情報システム・法務・経営企画がそれぞれ確認しておきたい項目は次のとおりです。
- 入力データが学習に使われない契約・設定になっているか
- 処理リージョンが国内に限定されているか（Global/US Geoが混在していないか）
- インターネットを経由しない閉域接続になっているか
- 暗号化キーの管理方針（自社管理か、ベンダー管理か）が明確か
- 個人情報保護法28条上の外国第三者提供に該当しない設計になっているか
- アクセス権限がIAM/SCPで最小権限に絞られているか
- 操作ログが監査可能な形で保存されているか
つまり、機密度で環境を分け、4ステップで具体化し、稟議のチェックリストで最終確認する、という流れを踏めば、判断に迷う場面を大きく減らせます。
AIセキュリティに取り組む企業の事例
最後に、実際にAIセキュリティを重視した設計でAI活用を進めている企業の事例を紹介します。競合の解説記事では匿名化された事例が多いですが、ここでは公表されている実名の取り組みを紹介します。
TISの全社標準化
TIS株式会社は2026年6月、Amazon BedrockとClaude Codeを組み合わせたセキュアなAI開発環境を、金融・公共分野の基準にも耐えうる全社標準として導入したと発表しました。国内完結の設計を前提に、開発現場全体でAIを安全に活用できる体制を整えている点が特徴です。
参照：TISプレスリリース
セゾンテクノロジー・サルソニードの活用実績
セゾンテクノロジーは、Bedrockを活用したRAG型の社内回答支援システムを導入し、回答作成時間を最大30%短縮しています。サルソニードは、Bedrock・Kendra・GenU（AWS提供のOSS）を組み合わせてセキュアな生成AI環境を短期構築し、記事のリライト業務時間を70%削減するとともに、シャドーIT・情報漏洩リスクの低減にも寄与しています。
三菱電機の取り組み
三菱電機は、28の業務領域でBedrockを活用した生成AI導入を進め、業務効率30%以上の向上を目標に掲げています。製造業のような大規模組織でも、国内完結の設計を前提にAI活用を横展開できることを示す事例です。
リベルクラフトでも、外部接続を遮断した閉域クラウド環境にLLMとデータベースを統合し、1,000ページを超える技術文書の審査をRAGで支援する仕組みをJAXA（宇宙科学研究所）向けに構築した実績があります。また、防衛省情報本部の「AI技術開発用装置の技術支援」を受託し、クラウドに依存しない環境でのAI技術活用を設計・実装しています。いずれも、機密度に応じて環境を選び分けるという本記事の考え方を、実際のプロジェクトで具体化したものです。
まとめ
本記事の要点を整理します。
- AIセキュリティは「Security for AI（AIを守る）」と「AI for Security（AIで守る）」の2軸に分けられ、本記事は前者を扱う
- 生成AI利用のリスクは、情報漏洩・越境移転・ハルシネーション・著作権侵害・プロンプトインジェクションの5つに整理できる
- 個人情報保護法28条の外国第三者提供規制は、クラウド例外が効きにくく、国内完結の設計が法務対応の負担を軽くする
- Amazon Bedrockを例にすると、学習不使用・国内リージョン限定・閉域接続・暗号化・権限統制の5層で多層防御を実現できる
- 対策は機密度別の環境選び分けから始め、4ステップで具体化し、稟議チェックリストで最終確認する
AIセキュリティは「使うか禁止か」の二択ではなく、リスクを切り分けて設計する問題です。この視点を持てれば、社内データを安全に活用しながらAIの導入を前に進められます。
ウェビナー資料（ホワイトペーパー）のダウンロード
本記事のもとになったウェビナー「社内データをAIに入れて大丈夫か：Bedrockで国内完結する設計」の資料を配布しています。個人情報保護法との関係やBedrockの多層防御アーキテクチャ、稟議チェックリストをスライドでまとめて確認したい方はご活用ください。
⇨ウェビナー資料のダウンロードはこちら
AIセキュリティの構築・実装は「リベルクラフト」へ
ここまで、AIセキュリティの全体像とリスクの切り分け方、クラウドでの多層防御の設計を解説してきました。考え方は整理できても、自社のデータと業務にどう当てはめるかは、判断に迷う場面が多いのではないでしょうか。
リベルクラフトでは、AIセキュリティの方針整理から、Amazon Bedrockを使った国内完結アーキテクチャの設計・構築、RAGによる社内データ活用、PoC・本格導入までを一気通貫で支援しています。JAXA・防衛省情報本部など、機密性の高いデータを扱う現場での支援実績があります。
- AIセキュリティ対策をどこから始めればよいか整理したい
- 社内データを安全に活用できる国内完結の環境を構築したい
- 個人情報保護法との関係を踏まえた稟議資料を用意したい
という方は、リベルクラフトへお気軽にご相談ください。
⇨リベルクラフトへの無料相談はこちら
この記事を書いた人
慶應義塾大学で金融工学を専攻。 卒業後はスタートアップのデータサイエンティストとして、AI・データ活用コンサルティング事業などに従事。 その後、株式会社セブン&アイ・ホールディングスにて、小売・物流事業におけるAI・データ活用の推進に貢献。 株式会社リベルクラフトを設立し、AIやデータサイエンスなどデータ活用領域に関する受託開発・コンサルティングや法人向けトレーニング、教育事業を展開。
