リスク通信第60号：「フロンティアAI時代の生成AI・AIエージェントリスク管理 ～基本原理からAIMS/ISMS/SCSを組み合わせた対策まで～」

１．はじめに

米Anthropic社が嚆矢となった「フロンティアAI」の勢いは止まることを知りません。今や、組織も個人も「AIを使うか否か」ではなく「AIをどう使うか」が課題となっています。そんな中、サイバーセキュリティもAIを無視できません。そして、AIは新しい技術なので、これまでのセキュリティ対策をそのまま適用するだけでは不十分であるばかりかAIの可能性を損なう可能性すら有ります。

そこで、今号では、AIの動作原理をおさらいするにあたり、今日主流となっているLLM（Large Language Model：大規模言語モデル）に加えて、今後の業務利用の中心になることが予想されるAIエージェントの基本原理も取り上げます。その上で、AIの主要リスクを列挙し、それらへの推奨対応策を紹介した上で、その推奨対応策をAIMS/ISMS/SCSと組み合わせることによって技術とガバナンス両面の対策を実現する道筋を探ってみたいと思います。

なお、本稿でいうAIMSはISO/IEC 42001に代表されるAIマネジメントシステム、ISMSはISO/IEC 27001に代表される情報セキュリティマネジメントシステム、SCSは「サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）」を念頭に置いています。また、本稿でいうAIエージェントは、LLMを中核に置きつつ、目的達成のために計画、検索、ツール呼び出し、実行、結果確認を繰り返すアプリケーション又はシステムを意味します。

２．LLMとAIエージェントの基本原理

まず、今日の生成AIの中心にあるLLMについて整理したいと思います。LLMは、一言で表現すると「与えられた文脈に対して、次に続く可能性が高いトークンを予測するように訓練された大規模なニューラルネットワーク」です。もっとも、この「次に続くトークンの予測」が膨大なデータ、巨大なパラメータ、Transformerと呼ばれるアーキテクチャ、そして人間の指示に合わせるための追加学習と組み合わさることで、質問応答、要約、翻訳、文章作成、プログラム作成、推論支援などの機能が実現されています。

ここでいうトークンとは、文章を処理しやすくするために分割した単位です。単語そのものの場合も有れば、単語の一部、記号、文字列の断片の場合も有ります。例えば「サイバーセキュリティ」という語が1つのトークンとして扱われることも有れば、「サイバー」と「セキュリティ」のように分かれることも有ります。LLMは、私たちが見る文章そのものを直接理解しているのではなく、トークン化された入力を数値に変換した上で処理しています。

LLMの主な構成技術を整理すると下記の通りです。

これらの構成技術が相互に連携する流れを、通常のチャット型生成AIを例に整理すると次のようになります。

① ユーザーがプロンプトを入力します。このプロンプトには、質問文だけでなく、システム側の指示、会話履歴、添付ファイルから抽出された文章、RAGによって取得された関連文書、ツール実行結果なども含まれます。

② 入力はトークンに分割され、埋め込みベクトルに変換されます。これによって、自然言語がニューラルネットワークで処理可能な数値情報になります。

③ Transformer層では、自己注意機構によって、どのトークンがどのトークンと関係しているかが繰り返し計算されます。例えば「その会社」「前述の契約」「この脆弱性」のような参照関係を、入力全体の中から推定する形です。

④ モデルは、現在の文脈に続く可能性が高いトークンの確率分布を出します。そして、デコーディング処理によって実際に出力するトークンを選びます。これを繰り返すことで、文章としてまとまった回答が生成されます。

⑤ 必要に応じて、生成前後に安全フィルタ、ポリシー判定、外部ツール呼び出し、検索、コード実行、ログ記録などが行われます。つまり、現在の生成AIサービスは、LLM単体ではなく、LLMを中核とするアプリケーション・サービス群として構成されていると理解するのが実態に近いと言えます。

この仕組みを踏まえると、生成AIは「人間のように意味を理解している便利な箱」と見るよりも、「入力された情報、学習済みのパターン、外部から与えられた文脈、そして安全制御の組み合わせによって出力を生成するシステム」と見るべきです。

次に、AIエージェントについて整理します。AIエージェントは、LLMの出力を「文章による回答」で止めるのではなく、目的達成のために、計画を立て、必要な情報を集め、外部ツールを呼び出し、実行結果を確認し、必要に応じて再度計画や実行を行う仕組みです。つまり、LLMが「考える・文章化する」中核だとすれば、AIエージェントは、LLMに「状態」「道具」「権限」「実行環境」「監督」を接続して業務遂行に近づける仕組みと言えます。

AIエージェントの主な構成技術を整理すると下記の通りです。

これらの構成技術が相互に連携する流れを、一般的なAIエージェントを例に整理すると次のようになります。

① ユーザーが「この顧客向けの提案書を作ってほしい」「脆弱性情報を調べて影響を判定してほしい」のように目的を入力します。目的、制約、期限、利用してよいデータ、実行してよい操作がエージェントの初期条件になります。

② オーケストレーターは、ユーザー入力、システムプロンプト、利用可能なツール一覧、権限情報、過去の会話やメモリ、関連文書、ポリシーをまとめてLLMへ渡します。

③ LLMは目的を解釈し、必要な手順を計画します。例えば、情報検索、社内文書参照、数値確認、ファイル生成、レビュー依頼、メール草案作成のようにタスクを分解します。

④ 必要に応じて、RAGやメモリから関連情報を取得します。この時点で、社内文書、過去の案件、チケット、コード、顧客情報などがエージェントの文脈に追加されます。

⑤ LLMは、必要なツールと引数を選びます。重要なのは、LLMが外部システムを直接操作するのではなく、「このツールをこの引数で実行したい」という構造化された指示を出し、アプリケーション側が実行する点です。

⑥ オーケストレーター又はポリシーエンジンは、ツール実行前に権限、データ分類、操作の影響度、外部送信の有無を確認します。高影響操作であれば人間の承認を求め、許可された場合のみ実行環境又は外部APIで処理を行います。

⑦ ツールの実行結果は再びLLMの文脈に戻されます。LLMは結果を確認し、目的が達成されたかを判断します。不足が有れば、追加の検索、別ツールの利用、再計算、人間への質問を行います。

⑧ 目的が達成されたと判断された時点で、エージェントは最終回答、作成物、操作結果、参照元、未解決事項を提示します。同時に、実行ログ、承認履歴、利用データ、エラー、出力物が監査証跡として保存されます。

このように、AIエージェントの本質は「LLMにより高度な自律性を与えること」ではなく、「LLMを中心に据えた業務処理の実行ループを作ること」に有ります。そして、この実行ループは便利である反面、従来の生成AIよりもリスクの現れ方を変えます。従来は「誤った回答を信じる」ことが主な問題でしたが、AIエージェントでは「誤った判断に基づいて実際の操作が行われる」可能性が出てくるからです。この理解が、次節以降で述べるリスク対策の出発点になります。

３．基本原理から見た機密情報入力・接続のリスク

次に、上記の基本原理を踏まえて、機密情報を生成AI又はAIエージェントに読み込ませることのリスクを考えます。生成AIに機密情報を入力することの危険性は、単に「AIがその情報を覚えてしまうかもしれない」という話に限定されません。より本質的には、入力した情報が、モデル、サービス、ログ、検索基盤、メモリ、ツール連携、委託先、運用担当者、さらには将来のモデル改善プロセスに接触し得る点に有ります。

AIエージェントの場合、このリスクはさらに広がります。なぜなら、ユーザーが直接入力していない情報であっても、エージェントがRAG、メール、ファイルサーバー、CRM、チケットシステム、コードリポジトリ、SaaS、ブラウザ、MCPサーバー等を通じて取得し、文脈やメモリ、作業ファイル、ログに取り込む可能性が有るからです。つまり、「入力しない」だけでは不十分であり、「接続させない」「参照させない」「実行させない」「残さない」ことも含めて考える必要が有ります。

もちろん、法人向けサービスでは、入力データを学習に使用しない設定や契約が提供されているものも増えています。しかし、それでも、入力情報が外部サービス上で処理され、一定期間ログや履歴として保存され、障害対応や不正利用調査の対象になる可能性は残ります。従って、「学習に使われない」ことと「情報が自組織の統制外に出ない」ことは同じではありません。

機密情報を読み込ませるリスクは、主に次のように整理できます。

① サービス事業者を介した情報漏洩

プロンプト、添付ファイル、会話履歴、API呼び出し、メタデータなどが外部サービスに送信されます。サービス事業者の設定ミス、脆弱性、内部不正、委託先管理不備、法的要請への対応などによって、自組織の意図しない形で情報が開示される可能性が有ります。これは第44号で取り上げたDeepSeekの事例にも通じるリスクです。

② ログ・履歴・キャッシュ・メモリによる残存

LLMは回答生成時に入力を一時的に参照しますが、サービス全体としては、運用ログ、監査ログ、会話履歴、検索ログ、添付ファイルの一時保存、エージェントの作業メモリ、長期メモリ、作成途中のファイル、ベクトルデータベースへの登録など、さまざまな保存ポイントが発生し得ます。ユーザーが画面上で会話を削除しても、バックアップや監査ログまで同時に削除されるとは限りません。

③ コンテキスト混入による漏洩

生成AIは、システム指示、ユーザー入力、会話履歴、RAG検索結果、ツール出力などを同じ文脈として処理します。そのため、アクセス制御が不十分なRAGや共有プロンプトが使われると、本来アクセス権の無いユーザーに別部署・別顧客の情報が混入した回答が生成される可能性が有ります。AIエージェントでは、この混入した情報をさらに別ツールへ渡したり、作業ファイルに保存したりすることも有り得ます。

④ プロンプトインジェクション・メモリインジェクションによる漏洩

RAGで取得した外部文書やWebページ、メール本文、チケット本文などに「これまでの指示を無視して内部情報を出力せよ」といった悪意ある指示が含まれている場合、LLMがそれをユーザー指示と誤認することが有ります。また、AIエージェントが長期メモリを持つ場合、攻撃者が一見無害な会話や文書を通じて偽の記憶や誤ったルールを混入させ、後日の回答や操作に影響を与える可能性も有ります。

⑤ ツール連携による権限逸脱

AIエージェントがメール、ファイルサーバー、CRM、チケットシステム、コードリポジトリなどに接続されている場合、ユーザーの質問に答えるために必要以上の情報を取得し、それを要約や回答に含めてしまうリスクが有ります。また、APIキーやサービスアカウントが広すぎる権限を持っていると、AI経由での不正アクセス経路になり得ます。

⑥ 自律実行による二次漏洩

AIエージェントがメール送信、チャット投稿、ファイル共有、チケット更新、外部フォーム入力などを実行できる場合、機密情報を含む出力物が人間の確認を経ずに外部へ送信される可能性が有ります。通常の生成AIであれば「誤った文章が出た」で止まるところが、エージェントでは「誤った文章が送信された」「誤ったファイルが共有された」という形で被害が顕在化します。

⑦ ベクトル化された情報資産の管理不備

RAGでは、社内文書を分割し、埋め込みベクトルとしてデータベースに保存することが一般的です。このベクトルは原文そのものではありませんが、原文に対応する検索インデックスとして機能します。従って、ベクトルデータベースへのアクセス制御、暗号化、削除、更新、監査が不十分であれば、情報資産管理上の新たな盲点になります。

⑧ 出力を通じた二次漏洩

機密情報そのものを入力したユーザーが、生成AIにより整えられた要約、翻訳、議事録、仕様書、コード、メール案を外部に送信することで、入力時点では意識されていなかった情報が漏洩することも有ります。生成AIは情報を読みやすく、説得力のある形に整えるため、漏洩時の影響をむしろ大きくする可能性が有ります。

⑨ サブエージェント・外部エージェントへの委任

マルチエージェント構成では、主エージェントが調査、コード作成、検証などを別のエージェントへ委任することが有ります。この際に、どの情報がどのエージェントへ渡されたのか、委任先がどのツールを使ったのか、委任先のログがどこに残るのかが不明確になると、情報管理の責任境界が曖昧になります。

このように、機密情報入力のリスクは、LLMの学習原理だけではなく、生成AI・AIエージェントサービス全体の設計・運用・契約・権限・ログ・メモリ・外部連携の問題として捉える必要が有ります。

４．機密情報漏洩以外の主なリスク

機密情報の入力・接続リスクは重要ですが、生成AI及びAIエージェントのリスクはそれだけではありません。前節までの基本原理を踏まえると、次のようなリスクも想定されます。

① 誤った出力・ハルシネーション

LLMは、真偽そのものを検証しているのではなく、文脈上もっともらしいトークン列を生成しています。そのため、存在しない判例、架空の制度、誤った仕様、古い情報、実在しない引用元などを、自然な文章で出力することが有ります。文章が整っているため、むしろ誤りに気づきにくい点が危険です。

② 過信・判断の委任

生成AIの出力が便利であるほど、人間側が確認を省略しやすくなります。特に、法務、医療、採用、人事評価、与信、セキュリティ判断、契約判断などにおいては、誤った出力や不十分な前提に基づいて意思決定が行われると、損害が大きくなります。第45号でも触れたように、HITL（Human-in-the-Loop）は依然として重要です。

③ バイアス・差別的影響

学習データやフィードバックデータに社会的偏りが含まれていれば、出力にもそれが反映されます。また、特定業務向けにファインチューニングした結果、意図しない偏りが強まることも有ります。採用、人事、顧客対応、与信、マーケティングなどでは、特定属性に不利益な出力が生じるリスクを考慮する必要が有ります。

④ プロンプトインジェクション・ジェイルブレイク

悪意ある入力によって、システム指示や安全制御を迂回させる攻撃です。RAGやエージェント化が進むほど、外部文書やメールに埋め込まれた間接的なプロンプトインジェクションのリスクが高まります。

⑤ 不適切・有害な出力

攻撃コード、詐欺メール、差別的表現、自傷他害を助長する内容、危険物の作成方法、社会的混乱を招く偽情報などが生成されるリスクです。多くのサービスは安全対策を備えていますが、完全ではありません。

⑥ 知的財産権の侵害・被侵害

学習データ、入力データ、出力データの各段階で、著作権、営業秘密、商標、特許、ライセンス条件の問題が発生し得ます。また、生成AIに自社の設計資料やコードを入力した結果、営業秘密管理の要件を満たせなくなる可能性も有ります。

⑦ 個人情報・プライバシー侵害

個人情報を含むデータを入力・要約・分類・推論する場合、利用目的、本人同意、第三者提供、越境移転、安全管理措置、開示請求対応などの論点が発生します。個人の属性や評価をAIが推論する場合には、明示的な個人情報よりも扱いが難しくなることも有ります。

⑧ 自律実行の誤操作・過剰なエージェンシー

AIエージェントには、外部システムを操作する能力、権限、自律性が与えられます。この能力・権限・自律性が必要以上に広い場合、誤出力、曖昧な指示、プロンプトインジェクションをきっかけに、メール送信、ファイル削除、データ更新、クラウド操作、コード実行などの有害な操作が行われる可能性が有ります。

⑨ ツール・コネクタ・MCPサーバ等のサプライチェーンリスク

モデル、API、プラグイン、RAG基盤、ベクトルデータベース、プロンプト管理ツール、MLOps基盤、OSSライブラリ、MCPサーバーなど、生成AI・AIエージェントの利用には多くの外部要素が関与します。いずれかの脆弱性や悪意ある変更が、AIシステム全体のリスクにつながります。

⑩ データポイズニング・モデルポイズニング・メモリポイズニング

学習データや追加学習データ、RAGの参照文書、エージェントの長期メモリに悪意ある情報や誤情報が混入すると、AIの出力や行動が攻撃者に有利な方向へ誘導される可能性が有ります。社内ナレッジベースや業務メモリをAIに接続する場合、元データの品質管理が極めて重要になります。

⑪ モデル盗用・プロンプト漏洩

独自に作成したプロンプト、評価データ、ファインチューニング済みモデル、業務ノウハウを組み込んだRAG構成、エージェントのワークフロー定義などは、組織の競争力そのものです。これらが漏洩すると、単なる情報漏洩にとどまらず、業務上の優位性が損なわれます。

⑫ シャドーAI・シャドーエージェント

従業員が個人アカウントや未承認サービスを用いて業務データを処理する状態です。これは、クラウドサービス普及時に問題となったシャドーITのAI版であり、機密情報漏洩、ログ不在、契約不備、監査不能といった問題を引き起こします。AIエージェントの場合、未承認のブラウザ拡張、MCPサーバー、ノーコード自動化ツールが業務システムに接続されることで、影響範囲がさらに大きくなります。

⑬ 可用性・コスト・ベンダーロックイン

外部AIサービスに業務が依存すると、サービス停止、料金変更、モデル仕様変更、API制限、利用規約変更の影響を受けます。また、特定モデル向けにプロンプトや業務フロー、エージェントの実行手順を最適化しすぎると、移行が困難になります。

⑭ マルチエージェントの連鎖失敗

複数のエージェントが相互に委任し合う構成では、1つの誤解、誤情報、権限設定ミスが別のエージェントへ伝播し、最終的に人間が想定しない操作につながる可能性が有ります。各サブタスクだけを見ると問題が無いように見えても、全体としては情報過剰取得や方針違反になる場合も有ります。

⑮ 監査困難・説明責任の空洞化

AIエージェントは、計画、検索、ツール実行、再試行、出力生成を短時間で繰り返します。その結果、後から「なぜその操作をしたのか」「誰の承認で実行されたのか」「どの情報を根拠にしたのか」を説明できなくなる可能性が有ります。これは、法令遵守、顧客説明、インシデント対応、内部監査の観点で大きな問題になります。

⑯ 法規制・説明責任のリスク

AIに関する規制やガイドラインは国・地域ごとに異なります。海外拠点、越境データ処理、グローバルサービス提供を行う組織では、日本国内の感覚だけで運用すると、現地規制や顧客要求に抵触する可能性が有ります。

５．技術的な推奨対応策

上記のリスクに対しては、禁止一辺倒ではなく、用途・データ・権限・接続先・影響度に応じた技術的対策を組み合わせることが現実的です。特にAIエージェントでは、出力の安全性だけでなく、実行前の制御、実行中の監視、実行後の監査を一体として考える必要が有ります。筆者としては、次の対策を推奨します。

① AI利用環境とエージェント実行環境の分離・承認済みサービスへの集約

個人アカウントでの業務利用を禁止し、法人契約・管理者統制・ログ取得・データ利用条件確認が可能な環境へ集約します。業務データを扱うAI利用は、SSO、多要素認証、アクセス制御、利用ログ、管理者設定が可能なサービスに限定することが望ましいです。また、AIエージェントがコード実行、ブラウザ操作、社内システム操作を行う場合は、通常の端末や本番環境から分離された実行環境を用意します。

② データ分類と入力・参照・実行可否ルールの実装

公開情報、社外秘、機密、重要機密、個人情報、営業秘密、顧客預かり情報などの分類ごとに、どのAI環境へ入力可能か、どのRAGで参照可能か、どのツールで処理可能か、外部送信可能かを定義します。単なる規程に止めず、DLP、秘密情報検知、個人情報マスキング、ファイルアップロード制御、ブラウザ拡張やCASB/SASE等による制御を組み合わせる必要が有ります。

③ プロンプト・添付ファイル・取得文書の自動検査

入力前に、個人情報、認証情報、APIキー、秘密鍵、顧客名、未公開財務情報、設計図、ソースコード等を検知し、警告・遮断・自動マスキングを行います。AIエージェントでは、ユーザー入力だけでなく、RAGで取得した文書、メール本文、Webページ、チケット、ツール出力にも同様の検査を行うことが重要です。

④ RAG・メモリのアクセス制御

RAGを導入する場合は、検索対象文書のアクセス権を回答時にも反映させる必要が有ります。文書をベクトル化した時点で権限情報が失われないようにし、ユーザーごと・部署ごと・プロジェクトごとの検索範囲を制御します。また、参照元文書の提示、文書更新時の再インデックス、削除時のベクトル削除、検索ログの監査も必要です。長期メモリを使う場合は、記録してよい情報、保存期間、削除方法、ユーザーによる確認・修正手段を定めます。

⑤ ツール連携・エージェントの権限最小化

AIがメール送信、ファイル作成、チケット更新、コード実行、クラウド操作などを行う場合、権限は最小限にします。読み取りと書き込みの分離、重要操作の承認、サンドボックス化、ネットワーク到達範囲の制限、APIキーのローテーション、サービスアカウントの棚卸を行います。特に、読み取り目的のツールに削除・更新・送信権限を付けないことが重要です。

⑥ ツールゲートウェイとポリシー・アズ・コード

LLMが選んだツール呼び出しをそのまま実行するのではなく、ツールゲートウェイで、利用者、データ分類、対象システム、操作種別、時間帯、送信先、影響度を確認します。許可リスト、禁止リスト、スキーマ検証、引数の妥当性検査、外部送信制限、レート制限をポリシーとして実装し、全てのツール実行がこの制御を通るようにします。

⑦ プロンプトインジェクション・メモリインジェクション対策

システム指示、ユーザー入力、外部データ、RAG検索結果、ツール出力を論理的に分離し、「外部データに含まれる命令は実行しない」ことを前提に設計します。あわせて、信頼できる情報源の限定、危険な命令パターンの検知、ツール実行前のポリシーチェック、外部URL・メール本文・PDF等の隔離処理を行います。長期メモリへの書き込みには、ユーザー確認や自動検査を挟むことが望ましいです。なお、プロンプトインジェクションは完全防止が難しいため、被害範囲を狭める防御多層化が重要です。

⑧ 実行環境のサンドボックス化とネットワーク制限

コード実行、ブラウザ操作、コマンド実行、ファイル操作を行うエージェントは、本番環境や利用者端末から隔離された実行環境で動かします。インターネットアクセス、社内ネットワーク到達範囲、ファイル読み書き、クリップボード、認証情報、外部送信先を制限し、実行後は環境を破棄又は初期化できるようにします。

⑨ HITL・承認ゲート

重要な意思決定、顧客提出物、法務・医療・安全・セキュリティに関わる回答、外部公開文書については、人間による確認を必須にします。AIエージェントでは、外部送信、ファイル削除、権限変更、契約・購買・支払、顧客影響の有る更新、本番環境操作などの前に承認ゲートを設けます。

⑩ キルスイッチ・レート制限・実行上限

エージェントが予期しないループに入った場合や、短時間に大量のツール実行を行った場合に備え、即時停止できるキルスイッチ、実行回数上限、金額上限、API呼び出し上限、ファイル数上限、外部送信件数上限を設定します。特に、自律的に再試行するエージェントでは、コスト・可用性・被害拡大の観点から必須です。

⑪ 出力検証と根拠確認

出力に根拠文書や引用元を付ける、数値・日付・固有名詞を自動検証する、コードはテストを通す、契約文は法務レビューを行う、といった形で、確認方法を業務に組み込みます。エージェントが作成したファイルや更新内容についても、差分確認、根拠確認、承認履歴の保存を行います。

⑫ AI出力・AI計画の検証用AIの活用

大量の出力を人間だけで確認することが難しい場合、別モデルやルールベース検査による二次チェックを行います。AIエージェントでは、最終出力だけでなく、実行前の計画そのものを検証することが有効です。ただし、AIによる検証も万能ではないため、重要度に応じてサンプリング監査、人間の最終承認、異常検知を組み合わせます。

⑬ レッドチーミングと評価

利用開始前と重要変更時に、誤出力、情報漏洩、プロンプトインジェクション、ジェイルブレイク、不適切出力、権限逸脱、RAGのアクセス制御漏れ、ツール誤実行、メモリ汚染、マルチエージェントの連鎖失敗などを評価します。業務固有のテストデータを用意し、モデルやプロンプト、ツール、ワークフロー変更後にも回帰テストを行うことが望ましいです。

⑭ AIシステム・エージェントの構成管理・変更管理

モデル名、バージョン、プロンプト、RAG対象文書、ベクトルDB、接続ツール、MCPサーバー、API権限、実行環境、承認条件、評価結果、承認履歴を台帳化します。生成AIは同じサービス名でもモデル更新で挙動が変わるため、通常のシステム変更管理に加えて、AI固有の挙動確認が必要です。

⑮ ログ監視とAIインシデント対応

誰が、いつ、どのAIサービスに、どの種類のデータを入力し、どの文書を参照し、どのツールを実行し、どのような出力を得たかを、必要な範囲で記録します。機密情報入力、異常な大量利用、禁止カテゴリの入力、外部送信、ツール実行失敗、承認回避、メモリ書き込み異常などを検知し、AIインシデントとして対応できる手順を整備します。

⑯ サプライチェーン・外部サービス管理

AIサービス提供者、RAG基盤、プラグイン、MCPサーバー、MLOpsツール、OSSライブラリについて、契約、データ取扱い、ログ保持、脆弱性対応、障害時対応、下請け・再委託、リージョン、暗号化、監査権限を確認します。必要に応じてSBOMだけでなく、モデルやデータセット、プロンプト、評価データ、接続ツール、エージェントワークフローを含むAI-BOM的な管理も検討します。

⑰ 利用者教育と実務テンプレート

「機密情報を入れないでください」という注意喚起だけでは不十分です。どの情報なら入れてよいのか、要約・翻訳・議事録・コード作成・調査・顧客対応・エージェントによる自動実行などの典型業務ごとに、使ってよい環境、入力例、禁止例、確認手順、承認が必要な操作をテンプレート化することが重要です。

６．AIMS/ISMS/SCSを組み合わせた組織的な管理

前節までの対策は技術的なものが中心でした。しかし、生成AI及びAIエージェントの利用は、単なるツール導入ではなく、業務プロセス、情報管理、委託先管理、リスク判断、説明責任を伴う取り組みです。従って、技術対策を単発で実装するだけではなく、AIMS/ISMS/SCSと結びつけて組織的に管理する必要が有ります。

AIMSは、AIをどの目的で、どの範囲で、誰の責任で、どのようなリスク評価と監視の下で使うかを管理する枠組みです。AIの便益とリスクを両方扱い、透明性、公平性、人間による監督、AIシステムのライフサイクル管理などを担います。AIエージェントについては、自律性、ツール実行、メモリ、承認、停止条件をAIMSの管理対象に含める必要が有ります。

ISMSは、情報資産の機密性・完全性・可用性を守る枠組みです。アクセス制御、ログ、脆弱性管理、委託先管理、インシデント対応、バックアップ、暗号化、教育など、生成AI・AIエージェントを支える情報セキュリティ対策の土台になります。AIエージェントでは、APIキー、サービスアカウント、MCPサーバー、実行環境、RAG、メモリ、ツールゲートウェイもISMS上の管理対象として扱う必要が有ります。

SCS評価制度は、サプライチェーン上の委託元・委託先間で、必要なサイバーセキュリティ対策の段階を提示し、実施状況を確認するための制度です。本稿執筆時点では、★3・★4の要求事項・評価基準が2026年4月21日に公開されており、★3・★4は2027年3月頃の運用開始が予定されています。また、★4は第三者評価及び技術検証を求めるスキームとされています。なお、経産省は、SCS評価制度が任意の制度であり、特定のセキュリティ対策製品の導入が必須ではない旨の注意喚起も行っています。従って、SCSは「取引先に対する最低限の共通言語」として活用するのが妥当です。

この3つを組み合わせる際の考え方を簡潔に表現すると、AIMSは「AIとして妥当か」、ISMSは「情報とシステムとして安全か」、SCSは「取引先を含めて説明可能か」を確認する枠組みと言えます。AIエージェントの場合は、ここに「実行させてよいか」「止められるか」「後から説明できるか」という観点を明示的に追加する必要が有ります。

具体的な運用手順としては、次のような流れが推奨されます。

① AIユースケース台帳・エージェント台帳の作成

部署、業務目的、利用者、利用するAIサービス、扱うデータ、出力の利用先、外部公開の有無、接続する社内システム、利用するツール、エージェントの自律性、承認条件、停止条件、想定される影響を記録します。これはAIMS上のAIシステム管理台帳であると同時に、ISMS上の情報資産台帳・システム台帳の拡張として位置付けます。

② データ分類とAI利用・参照・実行可否の紐づけ

社外秘、機密、重要機密、個人情報、顧客預かり情報、営業秘密などの分類ごとに、利用可能なAI環境、参照可能なRAG、保存可能なメモリ、実行可能なツール、外部送信可否を定義します。AIMSではAIへの入力データと行動範囲の妥当性、ISMSでは情報資産の保護、SCSでは取引先から預かった情報の取扱いとして管理します。

③ AIリスク評価・情報セキュリティリスク評価・業務影響評価の三段化

AI特有のリスク（誤出力、バイアス、説明性、人間の監督、透明性、悪用可能性、自律実行）をAIMSで評価し、情報漏洩、アクセス制御、可用性、脆弱性、ログ、委託先、インシデントをISMSで評価します。さらに、エージェントが実行する業務操作について、顧客影響、法務影響、財務影響、事業継続影響を評価します。サプライチェーンに関わる場合は、SCSの要求事項と照合します。

④ 承認ゲートの設定

低リスク用途は部門承認、高リスク用途はAIリスク管理委員会やCISO/CDAO/法務/個人情報保護責任者の承認を必要とするなど、影響度に応じた承認段階を設けます。特に、外部公開、顧客影響、個人評価、安全関連、社内システム操作、本番環境操作を伴う用途は慎重に扱うべきです。

⑤ 技術対策と管理策の対応表を作成

前節の技術対策を、AIMS/ISMS/SCSのどの管理対象で運用・監査するかを明確にします。担当部門、証跡、確認頻度、KPI/KRI、例外承認、改善期限を併せて記録することで、対策が「やりっぱなし」になることを防ぎます。

⑥ 監視・教育・定期見直し

利用ログ、インシデント、誤出力、禁止データ入力、RAG参照エラー、メモリ書き込み異常、ツール実行失敗、承認回避、ユーザーからの問い合わせ、取引先要求の変化を定期的に確認します。モデルやサービスの更新、業務変更、法規制・ガイドライン変更に応じて、台帳とルールを更新します。

⑦ サプライチェーン・委託先との責任分界の明確化

外部AIサービス、AIエージェント基盤、MCPサーバー、RAG基盤、委託先が運用するSaaSやAPIについて、データ取扱い、障害時対応、脆弱性対応、ログ提供、再委託、モデル更新時の通知、インシデント通知、監査権限を契約・運用手順に反映します。

技術的対応策とAIMS/ISMS/SCSの紐づけ例は下記の通りです。

このように、技術対策をAIMS/ISMS/SCSの各管理策に紐づけることで、AI固有のリスク、情報セキュリティリスク、サプライチェーンリスクを一体として管理できます。特に重要なのは、「AIだから特別扱い」でも「従来のISMSだけで十分」でもなく、AI固有の論点をAIMSで補い、実装と防御をISMSで担保し、取引先との共通言語をSCSで整えることです。

また、AIエージェントについては、ここに「実行権限の管理」と「実行証跡の管理」を加える必要が有ります。LLMの回答だけを管理していると、ツール実行、メモリ保存、サブエージェント委任、外部送信、承認回避のリスクを見落とします。従って、AIMS/ISMS/SCSの統合運用では、AIユースケース台帳、情報資産台帳、委託先台帳、リスク対応計画、教育記録、インシデント記録に加えて、エージェント台帳、ツール台帳、実行ログ、承認ログを可能な範囲で統合し、「1つの対策がどの制度要求にも効いているか」を見える化することが実務上は重要です。

なお、ISO/IEC 27090のようにAIシステムに特有のセキュリティ脅威に対応する国際規格も整備が進んでいます。本稿執筆時点では最終草案段階ですが、今後、AIMSとISMSをつなぐ実装ガイドとして参照される可能性が有ります。生成AI・AIエージェントの管理策は固定的なものではなく、今後も制度・標準・実務の進展に応じて更新していく必要が有ります。

７．おわりに

今号では、生成AIの基本原理として、今日主流となっているLLMとその構成技術を概観した上で、AIエージェントの構成技術と、それらがどのように連携して業務実行に近い機能を実現しているかを紹介しました。その上で、機密情報を読み込ませることのリスク、その他の主要リスク、技術的な推奨対応策、そしてAIMS/ISMS/SCSを組み合わせた組織的な管理方法を紹介しました。

生成AIのリスクを考える際に重要なのは、「AIは便利だが危険だから使わない」という結論に飛びつくことではなく、「どう使えば価値を得ながらリスクをコントロールできるか」を設計することだと思われます。第44号でも述べた通り、筆者は生成AIについて「使用しない理由は無い」と考えています。しかし、それは無防備に使ってよいという意味ではありません。

特にAIエージェントは、生成AIの利便性を一段引き上げるものです。文章を作るだけでなく、社内情報を読み、業務判断を補助し、外部サービスと連携し、場合によっては実際の業務操作を行うからです。従って、セキュリティ対策も、単に「プロンプトに機密情報を入れない」という注意喚起だけでは足りません。データ分類、DLP、RAGの権限管理、メモリ管理、ツール連携の権限最小化、プロンプトインジェクション対策、HITL、ログ監視、レッドチーミング、委託先管理、実行環境の分離などを、業務プロセスとして定着させる必要が有ります。

その際に、AIMS/ISMS/SCSを組み合わせることは有効です。AIMSでAIとしての妥当性と人間による監督を管理し、ISMSで情報セキュリティとしての実装を担保し、SCSでサプライチェーン上の説明可能性を確保する。この三層を整えることで、AIの可能性を損なわず、むしろ安心して活用できる環境を作ることができます。

生成AIとAIエージェントは今後も進化し、モデル、サービス、規制、標準、攻撃手法のいずれも変化し続けることが予想されます。従って、対策も一度作って終わりではなく、継続的な監視と改善が必要です。当リスク通信でも、今後、AIに関するリスクと対策を継続的に取り上げていきたいと思います。

最後までお読みいただきありがとうございました。

参考記事・文献：

Anthropic 「Anthropic’s Responsible Scaling Policy」 https://www.anthropic.com/responsible-scaling-policy

Vaswani et al. 「Attention Is All You Need」 https://arxiv.org/abs/1706.03762

Google Research 「Attention is All You Need」 https://research.google/pubs/attention-is-all-you-need/

OpenAI 「Agents SDK」 https://developers.openai.com/api/docs/guides/agents

OpenAI 「Using tools」 https://developers.openai.com/api/docs/guides/tools

OpenAI 「Function calling」 https://developers.openai.com/api/docs/guides/function-calling

Anthropic 「Connect Claude Code to tools via MCP」 https://docs.anthropic.com/en/docs/claude-code/mcp

Model Context Protocol 「Specification」 https://modelcontextprotocol.io/specification/2025-11-25

Model Context Protocol 「Understanding Authorization in MCP」 https://modelcontextprotocol.io/docs/tutorials/security/authorization

ISO 「ISO/IEC 42001:2023 - AI management systems」 https://www.iso.org/standard/42001

ISO 「ISO/IEC 27001:2022 - Information security management systems」 https://www.iso.org/standard/27001

ISO 「ISO/IEC 27002:2022 - Information security controls」 https://www.iso.org/standard/75652.html

ISO 「ISO/IEC FDIS 27090 - Cybersecurity — Artificial Intelligence」 https://www.iso.org/standard/56581.html

NIST 「AI Risk Management Framework」 https://www.nist.gov/itl/ai-risk-management-framework

NIST 「Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile」 https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

NIST 「Control Overlays for Securing AI Systems」 https://csrc.nist.gov/News/2025/control-overlays-for-securing-ai-systems

OWASP 「Top 10 for Large Language Model Applications」 https://owasp.org/www-project-top-10-for-large-language-model-applications/

OWASP 「LLM01:2025 Prompt Injection」 https://genai.owasp.org/llmrisk/llm01-prompt-injection/

OWASP 「LLM06:2025 Excessive Agency」 https://genai.owasp.org/llmrisk/llm062025-excessive-agency/

OWASP 「Agentic AI - Threats and Mitigations」 https://genai.owasp.org/resource/agentic-ai-threats-and-mitigations/

OWASP 「Securing Agentic Applications Guide 1.0」 https://genai.owasp.org/resource/securing-agentic-applications-guide-1-0/

OWASP 「OWASP Top 10 for Agentic Applications for 2026」 https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/

経済産業省 「AI事業者ガイドライン（第1.2版）」 https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/20260331_report.html

AIセーフティ・インスティテュート 「AIセーフティ・インスティテュート（AISI）」 https://aisi.go.jp/

IPA 「AIセキュリティ」 https://www.ipa.go.jp/digital/ai/security/index.html

IPA 「サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）」 https://www.ipa.go.jp/security/scs/index.html

IPA 「SCS評価制度 要求事項・評価基準」 https://www.ipa.go.jp/security/scs/requirements-criteria.html

IPA 「SCS評価制度の詳細情報」 https://www.ipa.go.jp/security/scs/details.html

IPA 「SCS評価制度 よくある質問」 https://www.ipa.go.jp/security/scs/faq.html

経済産業省 「サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）」 https://www.meti.go.jp/policy/netsecurity/scs.html

経済産業省 「SCS評価制度に係る不適切な勧誘に御注意ください」 https://www.meti.go.jp/policy/netsecurity/20260427_scs.html

―以上―