シャドーAIとは？

シャドーAIの概要

シャドーAIとは、組織内において承認された管理体制を持たず、インベントリ化されておらず、セキュリティ監視も行われていないAIの使用を指します。ソフトウェアサプライチェーンやクラウド環境内に存在する可能性があります。シャドーAIの具体的な例としては、以下が挙げられます：

• チャットボット、コパイロット、要約ツールなど、未承認のAIアプリ
• ブラウザ拡張機能、プラグイン、公開LLMエンドポイントなど、未承認のモデル／API
• コード、スクリプト、パッケージなど、AIが生成した成果物

従来のAIは、セキュリティリスクを最小限に抑えるため、ガバナンス、監査証跡、リスク管理を備えた集中型プラットフォームを使用することが一般的です。一方、シャドーAIは分散型であり、管理体制が最小限で、監査証跡も存在しません。以下は、シャドーAIと集中型AIの主な違いをまとめた比較表です：

シャドーAIは多くの場合、開発者、アナリスト、その他のチームがスピードと利便性を求めて未承認のAIを使用することで発生します。これらのAIツールやサービスにデータをコピー＆ペーストすることで、ソースコード、企業秘密、機密性の高い顧客データが漏洩する可能性があります。またAIの出力はイメージやパッケージとして形に残るため、さらなるシャドーAI成果物を生み出す連鎖反応につながります。

シャドーITとシャドーAI

シャドーITとは、組織のITチームの承認なしに、未承認のハードウェア、ソフトウェア、またはクラウドサービスを使用することを指します。たとえば、組織内のメンバーが未承認のSaaS（Software as a Service）、スクリプト、または管理されていないデバイスを使用し、セキュリティリスクを招くケースがあります。
シャドーITは可視性とアクセス制御が限られているため、組織にとってセキュリティ上の脅威となり得ます。さらにシャドーAIは、AIツールやサービスの性質上、シャドーITに固有のリスクを加えます。これらのリスクには以下が含まれます：

• AIプロンプトを通じて組織外にデータが流出する
• AIのハルシネーション（幻覚）および安全でないコード
• 不透明なサードパーティモデルプロバイダーやプラグイン
• AIが生成したコードやバイナリのプロベナンス（来歴）の欠如
• AIエージェントに関連するAIアセットが、業務を混乱させる可能性がある

シャドーITがシャドーAIにつながることもあります。未承認のSaaSをプラグインや拡張機能が有効な状態で使用すると、AIの機能がデフォルトでオンになっている場合があります。

シャドーAIのリスクとは？

シャドーAIの主なリスクには以下のものがあります：

• AIが生成したコードは常に安全とは限らず、インジェクション、認可バイパス、サーバーサイドリクエストフォージェリ（SSRF）などの一般的な脆弱性をもたらし、不必要なセキュリティリスクを引き起こす可能性があります。
• プロンプトに貼り付けられたトークンやログ・履歴から漏洩したトークンにより、秘密情報が露出する恐れがあります。
• AIが安全でない依存関係を提案する可能性があります。
• AIが削除または変更すべきでないデータを操作してしまう可能性があります。
• 不明なソースから取得したAIが構築したDockerfileやベースイメージがセキュリティ上の脅威となり得ます。
• 未レビューのコードや、制御なしにCI/CDステップを変更するAIスクリプトなど、ビルドパイプラインの問題が生じる可能性があります。
• サードパーティのAIが機密性の高い社内システムにアクセスできる状態になる可能性があります。

シャドーAIにはデータプライバシーに関する懸念も多く伴います。ソースコード、設定情報、財務データ、顧客との契約書などの機密情報が露出する恐れがあります。また、プロンプトがどこに送信され、どのくらいの期間保存されるかも不明であり、サードパーティのコネクタによってデータが外部に持ち出される可能性もあります。
さらに、シャドーAIはコンプライアンスおよび規制上の法的リスクをもたらします。組織として、特定のコンプライアンスおよびガバナンスプロセスに従う義務があります。しかしシャドーAIでは、誰がどのモデルを使用し、どのようなデータが入力され、いつ使用されたかを把握することができません。SOC 2、ISO 27001、GDPR、HIPAA、PCI、および社内SDLCコントロールなど、一般的なコンプライアンスフレームワークとのポリシー上の矛盾が生じる可能性もあります。
また、帰属および再利用ルールが不明確なことや制限されたコンテンツが取り込まれる可能性があることから、知的財産（IP）およびライセンス上のリスクも存在します。加えて、追跡されていないアーティファクトや依存関係がビルドやリリースに混入し、ソフトウェアサプライチェーンに影響を与える恐れがあります。
最終的に、これらすべてがシャドーAIの悪影響を受けた組織の評判に取り返しのつかないダメージをもたらす可能性があります。

シャドーAIの原因

シャドーAIは常に未承認のAI使用の結果ですが、その背景にはいくつかの理由があります：

• ユーザー主導のイノベーションと利便性の追求による、AIツールの早期導入
• 認識とトレーニングの不足により、出力結果への過度な信頼や、プロンプトを通じたデータ共有のリスクへの無自覚につながる
• 承認ツールリスト、ガードレール、または監視体制の欠如、およびAI支援コードに対するSDLCコントロールの不備
• パッケージ、コンテナ、ビルド出力、SBOM、モデル使用メタデータのインベントリが存在しないなどの組織的な欠陥が、シャドーAIを拡大させる可能性がある

シャドーAIの具体例

シャドーAIの具体例を見ることで、それが組織に与える影響をより深く理解することができます。以下は、ビジネス環境でシャドーAIが使用される一般的なシナリオです：

• 開発者が公開LLMを使用して、Terraform／Kubernetesマニフェストの生成、リファクタリング、作成、およびログのエラー特定を行う
• アナリストが無料のAIツールを使用して社内文書を要約する
• エンジニアがフォーム入力をキャプチャするブラウザ拡張機能をインストールする
• チームが未承認の「AIコードレビュー」ボットを使用してコードを確認する
• Dockerfileに未承認のサードパーティAIモデル／AI APIコールが含まれている

シャドーAIが現れる場所はさまざまです：

• OpenAIまたはGeminiのキーがあれば、シャドーAIは開発者が構築するほぼあらゆるソフトウェアに組み込まれ、開発者がアクセスできるあらゆる情報にアクセスできるようになる
• 公開チャットアシスタント、「コパイロット」コーディングツール、AIミーティング要約ツール
• IDE、ブラウザ、チケッティングツール内の拡張機能やプラグイン
• IaC、パイプライン、コンテナビルドファイル向けのAI搭載コードジェネレーター

2023年1月、AmazonはChatGPTの回答が社内の既存資料と「非常に類似している」ことに気づきました。その結果、Amazonは従業員に対し、ChatGPTのプロンプトに機密情報を入力しないよう注意喚起を行いました。

シャドーAIを効果的に管理する方法

1. シャドーAIの使用状況を検出・測定する

シャドーAIを管理する第一歩は、その使用状況を検出・測定することです。シャドーAIの使用状況を検出する方法はいくつかあります：

• 一般的なAIエンドポイントへのネットワーク外部通信の監視
• ブラウザ拡張機能のインベントリ確認
• AIプラグインのIAMログおよびOAuth許可の確認
• ソフトウェアサプライチェーン全体のスキャン
• AIが生成したコミットシグネチャや突然の依存関係の変化など、リポジトリ／CIのパターン分析

また、承認済みツール／モデルのインベントリ、それらを使用しているチーム、およびそれらのツールで使用可能なデータの種類を記録しておくことも有効です。

2. AI使用ポリシーを策定・徹底する

実施可能なAI使用ポリシーのチェックリストを作成してください。以下の内容を含めましょう：

• 承認済みツール／モデルおよび調達経路のリスト
• 貼り付け可否の内容（ソースコード、秘密情報、顧客データ）とマスキング要件を明記したデータ取り扱いルール
• ログ記録および監査要件
• AIが生成したコード／設定に対する人によるレビューの基準
• サードパーティプラグインのガバナンス（コネクタ、権限、保持期間）

ポリシーの策定は必要不可欠な第一歩であり、従業員へのトレーニングも重要です。しかし真の保護を実現するには、承認済みのAIアセットのみが使用されるよう、妥協のない徹底した運用が求められます。重要なのは、この運用がチームにとって簡単、スムーズ、かつシンプルに実行できるよう組み込まれていることです。そうしなければ、リスクのある抜け道を探そうとする動きを招きかねません。

3. シャドーAIをセキュリティおよびガバナンスフレームワークに統合する

AIの出力は、ソフトウェアサプライチェーンへのインプットとして扱わなければなりません。各AIアウトプットに求められる要件は以下のとおりです：

• アーティファクトのプロベナンス（どのツール／モデルから生成されたか、誰が生成したか）
• 依存関係および脆弱性のスキャン
• 昇格前のポリシーゲート
• SBOMの生成と保持

また、CI/CDおよびレジストリにおいてDevSecOpsポリシーを徹底する必要があります：

• リスクのあるパッケージやイメージをプロアクティブにブロックする
• 未知のアーティファクトを隔離する
• コンプライアンスに適合したビルドのみを昇格させる

4. チームがITを迂回しないよう、安全な代替手段を提供する

「セキュアなAI」の利用経路を提供することは、AI SPMを強化するうえで非常に効果的です。エンタープライズアカウント、シングルサインオン（SSO）、ログ記録、保持期間の管理を含む経路を用意しましょう。
Dockerfile／IaC向けの事前承認済みテンプレートなど、「デフォルトでセキュア」な開発者ワークフローを整備し、ガードレールと自動チェックを活用して効率的なワークフローの摩擦を最小化しましょう。

5. インシデント対応と継続的な改善

組織内でシャドーAIの使用を発見した場合、以下の3つの重要なステップを実行してください：

1. 封じ込め：トークンの失効、シークレットのローテーション、拡張機能の削除
2. 評価：共有されたデータの内容と保存場所の確認
3. 修復：アーティファクトの再スキャン、クリーンな状態での再ビルド、ポリシーおよびトレーニングの更新

これらのステップを踏むことで、組織は管理されていないAIをガバナンスが効いたアセットへと転換し、ソフトウェアサプライチェーン全体で適用されている厳格なセキュリティおよびコントロールチェックを適用できるようになります。確認すべき重要な指標には、承認ツールにおけるAI使用率、ブロック／隔離されたアーティファクト数、および露出の修復にかかる時間が含まれます。

JFrogによるシャドーAIの管理

シャドーAIの使用を止め、セキュリティ上の脅威を特定するには、時間、労力、そして適切なツールを必要とする複数のステップを踏む必要があります。JFrog AIカタログ内のシャドーAI検出機能を活用することで、プラットフォーム全体の管理済み・未管理モデルを一元的に把握することができます。
JFrog AIカタログはXrayを使用してアーティファクトとリポジトリをスキャンし、チームが使用している未審査のモデルを自動的に識別します。モデルには「管理済み」「未管理」「部分的に管理済み」のラベルが付与されるため、どのアセットに対応が必要かを容易に把握できます。その後、安全なモデルを承認するか、リスクのあるモデルをブロックするかを判断できます。
詳細については、ウェブサイトをご覧いただくか、バーチャルツアーをお試しいただくか、ご都合のよい日時で個別デモをご予約ください。