はじめに
現在、Webエンジニアを目指して学習を進める中で、AI駆動開発についても学んでいます。今回は、Happiness Chainのカリキュラムで生成AIセキュリティについて学ぶ機会があり、Prompt InjectionやJailbreak、情報漏洩、RAGのセキュリティ、企業でAIを利用する際のガードレールなどについて学びました。
受講前は、生成AIのセキュリティというと「個人情報や機密情報を入力しない」「AIの回答を鵜呑みにしない」といったイメージを持っていました。しかし学習を進めるうちに、「そもそも、この情報をAIに渡してよいのか」「読み込ませるデータに悪意のある指示が含まれていたらどうなるのか」「RAGでは誰がどの情報を検索できるようにするのか」など、考える範囲が広がっていきました。
この記事では講座内容そのものをまとめるのではなく、学習を通して自分の理解がどう変わったのか、疑問に思ったことをどう整理したのかを中心に振り返ります。
1. AIに情報を渡す前に考えること
最初に大きく認識が変わったのが、AIに入力する情報の扱いです。以前の自分は、個人情報をAIへ入力するリスクについて、「入力した情報が外部へ漏洩し、悪用されたら危険」というイメージを強く持っていました。
しかし学習する中で、「漏洩するかどうか」と「そもそも外部のAIサービスへ渡してよい情報なのか」は、分けて考える必要があると気づきました。
たとえば、友人との旅行の日程を考えるためにAIを使うとします。「予定を整理してもらうだけだから」と、友人から送られてきた氏名や連絡先、予約情報などをそのまま入力する。本人としては情報を公開するつもりも悪用するつもりもなく、「ちょっと便利に使っただけ」という感覚だと思います。
でも、ここで考える必要があるのは、**「この情報が漏洩するか」だけではなく、「そもそも自分の判断で外部のAIサービスへ渡してよい情報なのか」**という点です。
そこで、学んだ内容を自分自身のAI利用に当てはめて、情報を4つに分類してみました。
| 情報 | 自分の判断 | 理由 |
|---|---|---|
| 個人情報 | 原則そのまま渡さない | 自分の判断だけで外部サービスへ渡してよい情報なのか確認が必要。必要に応じてマスキングする |
| パスワード・APIキー・トークン | 渡さない | 不正利用などにつながる可能性がある |
| 社外秘・業務データ | 勝手に渡さない | 企業・顧客の機密情報を含む可能性があり、利用ルールの確認が必要 |
| 公開情報・公開して問題ない自分の文章 | 基本的に利用可能 | すでに公開されている、または公開されても問題ない情報であるため |
もちろん、これは企業向けのルールとして作ったものではなく、今回学んだ内容を自分自身のAI利用に当てはめて整理した現時点での基準です。
また、「AIに渡すか、まったく使わないか」の二択ではありません。氏名などが処理に必要ないのであれば、「山田太郎」を「顧客A」に置き換えるなど、マスキングして必要な情報だけを渡すという方法もあります。
山田太郎さんから予約変更の連絡がありました。
↓
顧客Aから予約変更の連絡がありました。
さらに、AIサービスによって入力データの保存やモデル改善への利用などの扱いは異なります。学習利用をオプトアウトできる場合もありますが、「学習に使われない＝何を入力しても安全」ではありません。 利用するサービスの規約や設定を確認する必要があります。
今回の学習を通して、自分の考え方は次のように変わりました。
漏れたら困る情報を入れない
↓
そもそも渡してよい情報なのか考える
↓
渡す必要があるなら必要最小限にする
↓
サービス側でどう扱われるのか確認する
2. Prompt Injectionで変わった認識
もう一つ印象に残ったのがPrompt Injectionです。今回の学習では、Prompt Injectionはシステムが本来想定している指示やタスクを攻撃者の指示によって上書きしようとするもの、JailbreakはAIに設定された安全上の制約などを回避しようとするものとして学びました。
さらにPrompt Injectionには、**直接（Direct）と間接（Indirect）**があることを知りました。
2.1 直接Prompt Injection
直接Prompt Injectionという言葉から、最初は攻撃者自身がAIへ悪意のあるプロンプトを入力する場面をイメージしていました。しかし、ソーシャルエンジニアリングと組み合わさる可能性もあることが印象に残りました。
たとえば、上司やAIベンダーの専門家などを装った相手から「緊急の確認が必要なので、このプロンプトを社内AIへ入力してください」と指示された場合、実際にAIへプロンプトを入力するのは攻撃者ではなく、その指示を受けた利用者になります。
攻撃者
↓
利用者を誘導する
↓
利用者が指定されたプロンプトをAIへ入力
↓
AI
「上司からの指示」「専門家からの依頼」といった権威性や、「今すぐ対応してください」といった緊急性が組み合わさることで、人間の判断を狙う攻撃にもなります。
生成AIのセキュリティというとAIそのものへの攻撃ばかりをイメージしていましたが、AIを操作する人間も攻撃経路の一部になり得るという点は、自分にとって印象に残った観点でした。
2.2 間接Prompt Injection
さらに気づきにくいと感じたのが、**間接Prompt Injection（Indirect Prompt Injection）**です。
これは攻撃者がAIへ直接指示を入力するのではなく、Webページ・PDF・メールなどのデータに悪意のある指示を仕込み、それを利用者がAIへ読み込ませることで、攻撃者の指示を実行させようとする手法です。
ここで、学んだ内容を自分なりの一言で表してみました。
「データの中に紛れ込んだ指示を、AIが自分への指示として扱ってしまう攻撃」
流れを整理すると、次のようになります。
攻撃者
↓
Webページ・PDF・メールなどに
悪意のある指示を仕込む
↓
利用者がそのデータをAIに読み込ませる
↓
AIがデータ内に紛れ込んだ指示を
自分への指示として扱ってしまう
↓
利用者が意図していない動作につながる
ここで重要なのは、利用者自身は悪意のあるプロンプトを入力していないことです。「このPDFを要約して」と頼んだだけでも、そのPDFの中にAIへ向けた別の指示が紛れ込んでいる可能性があります。
この攻撃を知って、「自分がAIへ何を入力するか」だけではなく、「AIに何を読ませるか」にも注意が必要だと考えるようになりました。
3. RAGで考えるデータと権限
情報漏洩について学んでいく中で、RAG（Retrieval-Augmented Generation）についても学びました。最初に疑問だったのが、**「必要な社内文書を全部プロンプトに入れてしまえばいいのでは？」**ということでした。
しかし、すべての文書を毎回渡す方法では、コンテキストウィンドウの制限やトークンコストがあります。また、不要な情報まで大量に含めれば、必要な情報をうまく扱えない可能性もあります。
RAGでは質問に関連する情報を検索し、必要な情報をLLMへ渡して回答を生成します。情報が更新された場合も、検索対象となる文書を更新することで、LLMそのものを再学習させずに、新しい情報を回答に利用できるという点もメリットだと理解しました。
質問
↓
質問をEmbedding
↓
Vector DBから関連情報を検索
↓
関連する情報をLLMへ渡す
↓
回答を生成
RAGについて学ぶ中では、いくつか「最初に思っていたこと」と「学んだ後の理解」に違いがありました。
| 自分の疑問・最初のイメージ | 学んで整理できたこと |
|---|---|
| Embeddingと検索は同じ処理？ | Embeddingは数値表現への変換、Vector Searchはその表現を使った検索 |
| ベクトル化したら安全？ | ベクトル化は暗号化ではない |
| 回答を生成してから権限を確認すればいい？ | RAGでは検索段階で権限のない情報を取得させないことが重要 |
特にEmbeddingは、「文章の意味をベクトルにして、意味が近いものを検索する」と言われても、最初はいまひとつイメージできませんでした。
そこで自分の中では、Embeddingは文章を「意味を表す座標」のような数値表現へ変換するもの、Vector Searchはその数値表現を使って近い情報を探すものと、工程を分けて考えました。このように分けると、自分の中ではかなり理解しやすくなりました。
また、ベクトル化は暗号化ではありません。RAGの構成によっては、検索用ベクトルだけでなく原文やメタデータを保存することもあるため、保存するデータへのアクセス制御も必要になります。
そしてRBAC（Role-Based Access Control）について学んだことで、生成した回答を後から隠すだけではなく、RAGが検索する段階で、権限のない文書を取得できないようにすることが重要だと理解しました。
自分の中では、
検索できなければ、その情報をもとに生成することもできない
という考え方が特に印象に残りました。
もちろん、LLMがもともと持っている知識まで生成できなくなるという意味ではありません。RAGで扱う社内文書について、権限のない情報を検索結果としてLLMへ渡さないという意味です。
生成AIのセキュリティというと、最初は「AIが危険なことを言わないようにする」という出力側の対策を想像していました。しかしRAGを学んで、AIへ情報が届く前の検索やデータ設計もセキュリティの一部なのだと理解しました。
4. 一つの対策だけに頼らない
ここまで学習して気づいたのが、章ごとに異なる技術を扱っているように見えて、何度も同じ考え方が登場していたことです。それが、**一つの対策だけに頼らない「多層防御」**でした。
たとえば、今回学んだ対策を守る場所ごとに整理すると、次のようになります。
| 守る場所 | 対策の例 |
|---|---|
| AIへ入力する前 | 入力ルール、マスキング、DLP |
| AI・RAG内部 | Guardrails、アクセス制御 |
| 保存するデータ | 暗号化、権限管理 |
| APIキーなどの秘密情報 | Vault、最小権限、ローテーション |
| 人・組織 | 教育、監査、インシデント対応 |
人間はミスをする可能性があるため、注意するだけではなくDLPなどの技術的な対策も重ねる。一方で、技術的な対策も完全ではないため、権限管理や監査、教育などをさらに組み合わせる。どれか一つだけで守ろうとしないことが共通していました。
秘密情報の管理では、最初に**「APIキーなら.envに入れて、.gitignoreでGitの管理対象から外せばいいのでは？」**という疑問を持ちました。自分も開発学習で.envを使っていたため、Vaultとの違いがよく分からなかったからです。
整理してみると、解決しようとしている範囲が違いました。
| 観点 | .env + .gitignore |
Vault |
|---|---|---|
| 主な役割 | 秘密情報をソースコードから分離する | 秘密情報を集中管理する |
| アクセス制御・監査 | 限定的 | ポリシーや監査の仕組みを持たせられる |
| ローテーション | 基本的に別途対応 | 仕組みとして管理できる |
自分の中では、Vaultは秘密情報の「置き場所」というより「関所」に近いと考えると分かりやすかったです。
運用面では、モデルのバージョン管理や回帰テストについても学びました。以前、AIを使ったOCR・帳票読み取りを試していた際、新しいモデルへ変更したところ、それまで読めていた内容の読み取り精度が逆に悪くなったことがあります。
新しいモデルへ変更
↓
以前読めていた帳票の精度が低下
↓
「新しいモデル＝すべての用途で性能向上」
ではないと実感
↓
回帰テストの必要性に納得
当時は「新しいモデルなのに、なぜ悪くなるのだろう」と感じていました。今回「回帰テスト」という考え方を学び、その経験と結びついたことで、単なる用語として覚えるよりも納得感がありました。
対策を入れて終わりではなく、システムが変化した後も想定どおり動いているか確認し続けることまで含めて考える必要があるのだと感じました。
5. 自分なりのAI利用ルール
ここまで学んだ内容を踏まえて、「では、自分自身はこれからAIをどう使うのか」を考えてみました。
現時点では、次の3つを自分のルールにしたいと思っています。
| 自分のルール | 学習したこととのつながり |
|---|---|
| 1. 渡してよい情報かを最初に考える | 個人情報・認証情報・機密情報を安易に入力しない。必要ならマスキングする |
| 2. データの中にも指示があり得ると考える | 間接Prompt Injectionを前提に、AIへ何を読ませるかにも注意する |
| 3. 影響の大きい操作ほど人間が確認する | 送信・公開・削除・送金など、取り消しにくい操作ほど確認を強くする |
1つ目は、単に「漏れたら困るか」ではなく、そもそも自分の判断で外部サービスへ渡してよい情報なのかを最初に考えることです。必要な場合でも、マスキングなどによって渡す情報を減らせないかを考えます。
2つ目は、間接Prompt Injectionを学んだことで決めました。自分が入力したプロンプトだけを見るのではなく、Webページ、PDF、メールなど、AIに読ませるデータの中にも指示があり得るという前提を持っておきたいと思います。
3つ目は、AIの動作をすべて同じ強さで確認するのではなく、失敗したときの影響によって確認の強さを変えることです。特に次のような操作は、人間による確認を強くしたいと考えています。
- 送金する
- データを削除する
- 外部へ公開する
- メールやメッセージを送信する
AIの動作をすべて疑い、毎回すべてを細かく確認していたら、AIを使うメリット自体が小さくなってしまいます。
そのため、「AIを信用するか、信用しないか」の二択ではなく、失敗したときの影響が大きい場所に確認のコストを集中させるという考え方を、自分なりのルールにしました。
まとめ
生成AIセキュリティを学ぶ前は、「危険な情報を入力しない」「AIの回答を鵜呑みにしない」くらいのイメージを持っていました。しかし今回の学習を通して、その前後にも守るべき場所があることを知りました。
学習前
「危険な情報をAIに入れなければいい」
「AIが変な回答をしたら気をつける」
↓
学習後
「そもそも、この情報をAIに渡してよいのか」
「読み込ませるデータの中に指示が紛れ込んでいないか」
「AIが検索できる情報は適切に制限されているか」
「秘密情報はどう管理されているか」
「影響の大きい操作をどこで人間が確認するか」
Prompt Injection、RAG、Vault、DLP、アクセス制御など、今回さまざまな技術を学びました。ただ、振り返ってみると、一番印象に残ったのは個々の技術名よりも、一つの防御策だけに頼らないことでした。
人間だけを信用するのでもなく、AIやGuardrailsだけを信用するのでもなく、入力・データ・権限・出力・運用と複数の場所で守る。そして自分自身がAIを使うときも、ただ「AIは危険だから使わない」と考えるのではなく、どこにリスクがあるのかを考え、影響が大きいところに人間の確認と技術的な防御を置くことが大切なのだと、今回の学習を通して感じました。
まだ生成AIセキュリティについて学び始めた段階ですが、今後AIを使った開発を進める際にも、「便利だから使う」だけではなく、**「どんな情報を渡し、どんな権限を持たせ、どこを人間が確認するのか」**を考えながら使っていきたいと思います。
参考
- Happiness Chain「生成AIセキュリティ」学習カリキュラム