要約： シャドーAIとは、会社が管理していないAIサービスを従業員が業務に使うことです。誰も確認していないAI生成コードとあわせて、攻撃者が手を下さなくても起こるリスクにあたります。IPA（独立行政法人情報処理推進機構）は、禁止するだけでなく、利用を認めるサービスの提供、入力してよいデータの規定、AIの出力すべての確認を推奨しています。
連載「日本におけるAIサイバー攻撃」第5回（全6回）。全体像は第1回：考え方と3つのリスク分類にまとめています。
目次
- 社内でのAIの使い方が、なぜサイバーセキュリティのリスクになるのか
- シャドーAIとは何か、どのように情報漏えいにつながるのか
- AIの利用を禁止しても、なぜシャドーAIは解決しないのか
- AI生成コードには、どのようなリスクがあるか
- AIの速さを保ちながら管理できるのは、どのようなプロセスか
- 開発会社のAI利用について、何を確認すべきか
- 社内規程では解決できないこと
1. 社内でのAIの使い方が、なぜサイバーセキュリティのリスクになるのか
社内でのAIの使い方がサイバーセキュリティのリスクになるのは、攻撃が一切なくても、データが社外に出たり、不具合が製品に入り込んだりする可能性があるためです。IPAは「情報セキュリティ10大脅威 2026」で、「組織」向け3位の脅威の説明そのものにこのリスクを含めています。
IPAの解説書によると、「AIの利用をめぐるサイバーリスク」には、AIへの理解が不十分なことから意図せず起こる問題も含まれます。具体的には、他者の権利の侵害、情報漏えい、AIが生成した結果を十分に検証せず鵜呑みにすることで生じる問題です。IPAは、AIは有用な道具である一方、十分に理解しないまま使うと権利侵害や情報漏えいにつながる可能性があると述べています。
このリスクは、ほかの2つの分類と1点で異なります。フィッシングやプロンプトインジェクションでは、会社は外部の人物から身を守ります。ここでリスクを生むのは、仕事を早く進めようとしている従業員です。
2. シャドーAIとは何か、どのように情報漏えいにつながるのか
シャドーAIとは、会社が許可していない、あるいは把握していないAIサービスを、従業員が業務に使うことです。多くの場合、個人のアカウントが使われます。この言葉はシャドーITに由来します。シャドーITは、情報システム部門の管理外で社内に使われているソフトウェアやサービスを指します。
情報漏えいは、ごく単純な経路で起こります。従業員が議事録、ソースコード、顧客データをチャット欄に貼り付け、要約や修正を依頼します。その時点から、データは会社が管理できない場所に置かれます。サービスの設定によっては、データが保存されたり、モデルの学習に使われたりする可能性があります。
どの程度広がっているかについて、IPAは米国のAI企業による調査を引用しています。
- 利用者の77%が、業務中に生成AIへデータをコピーして、プロンプトとして貼り付けています。
- そのうち82%は、組織が管理していないアカウントで行っています。
IPAは、あまり注目されていない点も挙げています。従業員が個人のアカウントでAIを使っていることを会社が把握できないこと自体が、リスクだという点です。存在を知らないものを、会社は守ることができません。
| 項目 | 会社が許可したAIサービス | シャドーAI |
|---|---|---|
| アカウント | 会社が管理し、退職時に停止できる | 個人のもので、会社からは見えない |
| データを学習に使う設定 | 会社が決め、確認できる | 利用者ごとに異なり、初期設定のままのことが多い |
| 利用履歴 | ログがある | ない |
| 利用規約 | 確認済み | 誰も読んでいない |
3. AIの利用を禁止しても、なぜシャドーAIは解決しないのか
AIの利用を禁止してもシャドーAIが解決しないのは、禁止しても必要性はなくならず、利用が見えなくなるだけだからです。締め切りを抱えた従業員は、間に合わせるために役立つ道具を、スマートフォンや私物のパソコンで使い続けます。
IPAも、経営者向けの対策でこの方向を取っています。最初に挙げられているのは、シャドーAIを避けるためにAIサービスの導入を検討することで、規程はその後に続きます。IPAが挙げる対策は次のとおりです。
- 利用を認めるAIサービスを選定し、提供する。 契約時に利用規約を確認します。
- 利用規程を整備する。 個人アカウントの業務利用を制限し、違反時の対応を明記します。
- 入力データを学習に使わせない設定にする。 IPAは、外部サービスを利用する際のオプトアウト設定の徹底として挙げています。
- 利用状況を把握する。 IT資産を管理し、通信ログを使って、どのAIサービスにアクセスがあるかを確認します。
- 教育を行う。 機密情報を安易に入力しないこと、AIは誤った回答をする場合があると理解すること、過度に依存しないことを伝えます。
効果が出やすいのは、具体的に書かれた規程です。「機密情報を入力しない」だけでは曖昧です。顧客の個人データ、未公表の財務数値、ソースコード、設計図面、契約内容のように、種類ごとに列挙することをおすすめします。
4. AI生成コードには、どのようなリスクがあるか
AI生成コードには、セキュリティ上の主なリスクが4つあります。その多くは、専門知識のある人の確認がないままAIツールが使われたときに生じます。
| リスク | 起こること | 出典 |
|---|---|---|
| コード内の脆弱性 | AIが、動作はするものの入力チェック、権限制御、エラー処理が欠けたコードを生成する | IPA：AIが生成したコードに脆弱性が含まれる場合がある |
| 存在しないライブラリ | AIが実在しないパッケージ名を提案する。攻撃者がその名前で悪意のあるパッケージをあらかじめ登録し、開発者がインストールするのを待つ | IPAが、これを悪用したサプライチェーン攻撃に関するKoi Securityの報告を引用 |
| 開発ツールに命令が仕込まれる | プロジェクト内のファイルに隠された悪意のある指示により、AIツールが開発者の権限でコマンドを実行する | IPA：コードエディタCursorで脆弱性が見つかった |
| ソースコードと秘密情報が社外に出る | 開発者がコード、APIキー、設定情報を、許可されていないAIサービスに貼り付ける | 第2章のシャドーAIそのもの |
2つ目のリスクは、AIの弱点をサプライチェーン攻撃の経路に変えてしまう点で注意が必要です。AIは、実在しない情報を作り出し、事実のように示すことがあります。この現象はハルシネーションと呼ばれます。文章であれば、結果は誤った一文です。コードの場合は、攻撃者のソフトウェアをシステムにインストールする1行のコマンドになります。
ハルシネーションは、開発者だけの問題ではありません。IPAは米国テキサス州の事例を挙げています。2025年1月に開かれた公聴会で、前年に提出された意見書が存在しない判例を引用していたことが判明しました。作成した弁護士は生成AIを使っており、AIがそのような内容を作り出す可能性があるとは知らなかったと述べています。
一方で、AIには別の側面もあります。2026年5月18日に公表された日本政府のProject YATA-Shieldには、ソフトウェアベンダに対し、高性能なAIも活用しながら、開発ライフサイクル全体で脆弱性の早期発見と対応に取り組むよう注意喚起を行う項目があります。問われているのは、ソフトウェア開発でAIを使うかどうかではありません。誰が出力を確認するのか、そしてその確認が証拠として残るのか、という点です。
5. AIの速さを保ちながら管理できるのは、どのようなプロセスか
AIの速さを保ちながら管理できるのは、AIが生成したものをすべて下書きとして扱い、責任を持つ人が確認するプロセスです。次の5つのルールは、ソフトウェア開発チーム向けのものです。
- すべての変更を人がレビューする。 AI生成コードも、人が書いたコードと同じ経路を通します。プルリクエスト、名前の残るレビュー担当者、変更理由です。
- テストは追加作業ではなく、前提条件とする。 AIはコードを速く生成するため、不具合も速く入り込みます。その速さを支えるのが自動テストです。
- 新しいライブラリは、インストール前に確認する。 パッケージが実在するか、誰が保守しているか、どの程度使われているかを調べます。AIの提案だけを根拠に、調べ直さずインストールすることは避けます。
- 秘密情報をプロンプトに入れない。 APIキー、パスワード、お客様の実データは、AIツールに貼り付けません。
- プロンプトやAIへの指示もバージョン管理する。 プロンプトが出力を左右するため、プロンプトの変更もコードの変更と同じように記録します。
ルール5は、VAONが社内プロジェクトで実施しているものです。VAONのチームは、要件定義書を生成するプロンプトを、ファイルとしてソースコードのリポジトリに保存しています。変更はすべてプルリクエストを通し、理由と変更履歴を残します。変更を受け入れる前に、固定したサンプル入力のセットで、新しい出力と以前の出力を比較します。この方法は、現時点ではVAONの社内プロジェクトにのみ適用しています。
ルール1と2は、VAONのすべてのプロジェクトに適用しています。どのプロジェクトでもレビューとテストの記録を保存しており、お客様はその記録をご覧いただけます。2026年、「AIが書いたコードは誰が確認するのか」は、お客様からVAONに寄せられる質問のうち最も多い3つの1つです。この記録が、その答えになります。
6. 開発会社のAI利用について、何を確認すべきか
ソフトウェア開発を委託する側は、開発会社にAI利用について5つの質問をされることをおすすめします。現在は多くの開発チームが、程度の差はあれAIを使っているためです。「AIは使っていません」という回答も、「すべてAIが行います」という回答と同じくらい丁寧に確かめる必要があります。
- 御社のチームはどのAIツールを使っていますか。会社のアカウントですか、個人のアカウントですか。
- 当社のソースコードやデータは、そのツールに入力されますか。データを学習に使う設定はどうなっていますか。
- AI生成コードは誰がレビューしますか。当社が確認できるレビュー記録はありますか。
- 新しいライブラリは、プロジェクトに取り込む前にどのように確認していますか。
- 当社の実データは、開発環境やテスト環境で使われますか。
質問3について、VAONはプロジェクトごとのレビューとテストの記録でお答えできます。それ以外の質問への回答は、プロジェクトごとの取り決めによって変わるため、契約書またはキックオフ資料に明記しておくことをおすすめします。AIツールについて自社の規程をお持ちの場合は、最初の段階でお伝えいただくのがよいと考えます。
7. 社内規程では解決できないこと
AIに関する社内規程には、3つの限界があります。あらかじめ知っておくことで、誤った期待を避けられます。
- 規程は私物の端末までは見えません。 従業員が個人のスマートフォンでAIを使う場合、どのログにも残りません。この部分は、十分に使いやすい許可済みのツールを提供することと、教育によってしか対応できません。
- レビューですべての不具合を見つけられるわけではありません。 レビュー担当者にも見落としはあり、AIによってコードの量が急に増えるとなおさらです。レビューは、自動テストや脆弱性スキャンツールと組み合わせる必要があります。
- 規程はすぐに古くなります。 AIツールには毎月のように新しい機能が加わります。たとえば、自らコマンドを実行する機能や、自らウェブを読む機能です。チャットボットを想定して書かれた規程では、AIエージェントをカバーできません。定期的な見直しをおすすめします。
自社の開発チームがどこでAIを使い、誰がその出力を確認しているか、把握されていますか。 VAONが、データ入力の規程からレビュー記録まで、プロセスの見直しをご一緒します。無料相談はこちら
参考資料
- IPA『情報セキュリティ10大脅威 2026』解説書（組織編）：https://www.ipa.go.jp/security/10threats/10threats2026.html（2026年10月10日確認）
- 国家サイバー統括室ほか13機関『AI性能の高度化を踏まえたサイバーセキュリティ対策の強化について ～Project YATA-Shield～』（2026年5月18日）：https://www.cyber.go.jp/pdf/press/20260518_AI_CS_Package.pdf（2026年10月10日確認）
