CISコントロールをAIエージェントに当てる｜管理策の優先順位を決める

「AIエージェントを入れたいが、今のセキュリティの管理策のどこに何を書き足せばいいのか分からない」「AI専用の基準を一から作る余裕はない。手元の管理策の一覧で何とかならないか」。情報システム部門の責任者から、こうした声が聞かれます。管理策の一覧をきちんと運用している会社ほど、AIをどこに収めるかで手が止まりやすいものです。そうした中、管理策の型を持つ米国の非営利団体CISが、2026年4月に、既存のCISコントロールをAIに当てはめる付属文書を3本公表しました。AIエージェントの守りは、新しい枠組みを足すことではありません。本当は、既存の18項目のうち、どれを先に読み替えるかという優先順位を決めることです。この記事では、付属文書の位置づけを確かめたうえで、自社のAI構成の棚卸しから、実装グループの選び方、読み替える項目の順番、適用しない項目の扱い、見直しの周期までを手順で整理します。

CISコントロールとは。18項目、153の保護策、3つの実装グループ

CISコントロールは、米国の非営利団体CIS（センター・フォー・インターネット・セキュリティ）がまとめた、優先順位付きのセキュリティの管理策の一覧です。企業の資産の棚卸しから侵入テストまでの18項目があり、その下に具体的な保護策が置かれています。現行は2024年6月の第8.1版で、保護策は全部で153あります。

第8.1版は第8版を改訂したもので、米国の標準技術研究所が定めるサイバーセキュリティの枠組みの2.0版に合わせて機能の対応を見直し、統治の機能を取り込みました。用語の定義の追加や、資産の区分の見直しも行われています。2026年10月時点で、次の版の公表や、第8.1版の終了の告知は確かめられませんでした。

CISコントロールの特徴は、保護策を3つの実装グループ（区分記号はIG1からIG3）に分けていることです。実装グループ1は、CISが基本的なサイバー衛生と呼ぶ、すべての組織が備えるべき最低限の保護策です。実装グループ2はその上に保護策を足し、実装グループ3はすべての保護策を含みます。グループは積み上げ式で、CISはどの組織も実装グループ1から始めるべきだとしています。

2026年4月に出た3本の付属文書は、何を読み替えたのか

CISは2026年4月20日、第8.1版をAIエージェントに当てる付属文書と、MCPを使う仕組みに当てる付属文書を公表しました。大規模言語モデルに当てる付属文書と合わせた3本で、CISとセキュリティ企業2社の専門家が共同で執筆しています。CISのブログは、3本の役割を、モデルの層、自律と行動の層、道具とデータにつなぐ層の守りに分けて説明しています。

AIエージェントの付属文書の概要によれば、対象は、計画、推論、道具の呼び出し、何段にもわたる作業の流れといった、エージェントの層です。身元、端末での実行、知識の置き場、連携の流れへと攻撃される面が広がることを踏まえ、許可されていない行為、データの漏えい、意図しないシステムの変更といったリスクを扱うとしています。

大規模言語モデルの付属文書は、指示文、文脈の扱い、機密情報の露出に関わるリスクを扱います。MCPの付属文書は、道具へのアクセス、人でない身元の管理、記録に残る形でのやり取りを重視し、データの取得や命令の実行といった能力を1つずつ個別に許可するというMCPの考え方を踏まえています。本稿が主に扱うのはAIエージェントの付属文書で、他の2本は関わる箇所で触れます。

付属文書は新しい枠組みではない。既存の一覧に行を足す

3本の付属文書に共通するのは、新しい枠組みを作っていないことです。AIエージェントの付属文書は、自らを第8.1版をエージェントの層に当てるための実務の手引きと位置づけ、関連する保護策をエージェントの振る舞いの文脈で読み替えるとしています。CISのブログも、CISコントロールは引き続き当てはまるが、AIの仕組みは従来のアプリとは振る舞いが違うとし、各項目をAIの観点で見直したと説明しています。

この位置づけは、導入の判断にとって大きな意味があります。すでにCISコントロールや同じような管理策の一覧を使っている会社は、AIのために別の一覧を作って二重に管理する必要がありません。今の一覧の各行に、AIエージェントの場合の読み替えを書き足すことで、監査や社内の説明も、これまでと同じ物差しで続けられます。

一方で、従来の前提が通じない箇所があることも、付属文書は認めています。概要には、従来の管理策がそのまま当てはまる箇所を明らかにし、AIエージェントの構成に固有の新しい考慮点を加える、と書かれています。つまり、読み替えは全項目を同じ重さで書き直すことではありません。そのまま使える項目と、書き足しが要る項目を見分けることが最初の仕事になります。

手順1　自社のAI構成を、3つの層で書き出す

読み替えの前に、自社にどんなAIの構成があるかを書き出します。付属文書の分け方に合わせて、モデルの層（どの大規模言語モデルをどこで使っているか）、エージェントの層（どのエージェントが何の仕事を、どの資格で行っているか）、つなぐ層（MCPなどでどの道具やデータにつないでいるか）の3つに分けると、後でどの付属文書を開けばよいかが決まります。

書き出す粒度は、管理策の一覧の行に当てられる程度で十分です。たとえば、エージェントごとに、持ち主の部門、使う資格、読み書きする社内の仕組み、つなぐ外部の道具、扱うデータの区分、の5つを並べます。資産の台帳そのものの作り方は「IT資産の台帳が合わなくなる原因｜AI端末を数え直す」の記事に、エージェント単位の台帳の項目は「AIエージェントのガバナンス｜モデルの統制とは別物」の記事に譲ります。

この書き出しの下書きは、AIに任せやすい作業です。購買の記録、認証の記録、接続の設定を読ませて一覧の形にまとめさせれば、手で集めるより早く揃います。ただし、部門が自分で足した道具や、個人の契約で使われているAIは、記録に載っていないことがあります。下書きを各部門の持ち主に見せ、抜けを人が確かめる段を必ず置いてください。

手順2　どの実装グループまでAIの分を求めるかを決める

次に、AIエージェントの読み替えを、どの実装グループの保護策まで求めるかを決めます。CISの考え方に沿えば、出発点は実装グループ1です。自社の一覧ですでに実装グループ2や3まで運用していても、AIの分は実装グループ1の保護策から読み替えを始め、揃ってから上に広げるのが無理のない順番です。

どこまで求めるかは、エージェントに任せる仕事の重さで変わります。社内の文書を読んで要約するだけのエージェントと、顧客の情報を書き換えたり、発注や送金に関わったりするエージェントでは、同じ実装グループで足りるとは限りません。本稿では、エージェントごとに、求める実装グループを決める形を勧めます。会社全体で1つに決めると、軽い用途には重すぎ、重い用途には軽すぎる結果になりがちです。

この線を引くのは人です。どの実装グループまで求めるかは、守る費用と、事故が起きた時の影響との比べ合いで、AIには決めさせません。情報システム部門の責任者とセキュリティの担当が案を作り、エージェントの持ち主である業務部門と合意して、決めた理由とともに一覧に記録します。

手順3　読み替える項目の順番を決める

18項目のうち、AIエージェントのために書き足しが要る度合いは項目によって違います。本稿では、各付属文書の本体が個々の保護策をどう扱っているかまでは確かめていません。そこで下の表は、公式の概要とCISコントロールの各項目の説明をもとに、どの項目から読み替えるかを本稿の観点で並べたものです。項目の日本語の名前も本稿の訳です。

項目（番号と名前）	AIエージェントで問い直すこと	読み替えの順番（本稿の整理）
第1項目　企業の資産の棚卸しと管理	エージェントと、それが動く環境を資産として数えているか	最初
第2項目　ソフトウェア資産の棚卸しと管理	エージェントが呼び出す道具や接続先を、許可したものに限っているか	最初
第3項目　データ保護	エージェントが読める範囲、書ける範囲、残す範囲を決めているか	最初
第5項目　アカウント管理	人でない身元を、人のアカウントと分けて管理しているか	最初
第6項目　アクセス制御の管理	エージェントに渡す権限を、仕事の範囲に合わせて付け外ししているか	最初
第8項目　監査ログの管理	誰の依頼で、どのエージェントが、何を呼んだかが残るか	次
第15項目　サービス提供者の管理	モデルや道具の外部の提供元を、評価の対象に入れているか	次
第16項目　アプリのソフトウェアの安全	自社で組むエージェントを、開発の安全の手順に乗せているか	次
第17項目　事故対応の管理	エージェントを止める手順と、元に戻す手順があるか	次
第4・7・9〜14・18項目	設定、脆弱性、メールとブラウザ、不正なプログラム、復旧、ネットワーク、研修、侵入テスト	残りを順に。そのまま使える行も多い

「最初」に置いた5つは、エージェントが何者で、何に触れ、何を持ち出しうるかを決める項目です。ここが空いていると、他の項目で何を書き足しても、守る対象の範囲が定まりません。「次」に置いた4つは、最初の5つが決まって初めて中身が書ける項目です。

残りの項目にも読み替えは要りますが、エージェント固有の書き足しは比較的少なく、従来の行がそのまま使える箇所も多いと考えられます。順番は会社ごとに変えてかまいません。順番そのものを一覧に書き、なぜその順にしたかを残しておくことが、後で見直すときの手がかりになります。

第1・第2項目　棚卸しに、エージェントと接続先を数える

第1項目は企業の資産を、第2項目はソフトウェアを、能動的に棚卸しし、追跡し、正すことを求めています。第2項目の目的は、許可したソフトウェアだけが入っている状態を保つことです。AIエージェントの読み替えでは、この2つの対象に、エージェントそのものと、エージェントが動く環境、エージェントが呼び出す道具や接続先を入れるかどうかが論点になります。

本稿では、エージェントを第1項目の資産、呼び出す道具と接続先を第2項目のソフトウェアとして数える整理を勧めます。こうすると、許可していない道具をエージェントが呼んでいる状態を、第2項目の未許可のソフトウェアとして同じ手順で見つけられます。どちらに数えるかは会社ごとに決めてかまいませんが、一覧のどこかに必ず行を持たせます。

棚卸しのきっかけも読み替えが要ります。エージェントは設定1つで新しい道具とつながることがあり、端末のように購買の手続きを経ません。購買の記録だけを起点にした棚卸しでは、エージェントの接続先の増減を拾えません。接続の設定の変更そのものを、棚卸しを更新するきっかけに加えます。

第3項目　データ保護に、エージェントが読める範囲と残す範囲を足す

第3項目は、データを特定し、区分し、安全に扱い、保存し、廃棄するための手順と技術的な管理を求めています。従来は、人が扱うデータの区分と保存の期間を決めることが中心でした。AIエージェントの付属文書の概要も、データの漏えいを主なリスクの1つに挙げています。

読み替えで書き足すのは、エージェントが読める区分、書ける区分、そしてエージェントの作業の途中で生まれるデータの扱いです。エージェントは、読んだ文書の要約や作業の記録、外の道具に渡した中身を、どこかに残します。エージェントが作業の途中で残すものも、第3項目のデータとして区分と保存の期間を決めることが要になります。

外部のAIサービスに送ってよい区分を決めることも、この項目の読み替えに入ります。送ってよい区分の線を引くのは人で、AIに区分を判定させる場合でも、判定の根拠を書かせ、重い区分の判定は人が確かめる形にします。契約や設定の読み方は「生成AIから情報が漏れる原因と対策｜契約と設定で防ぐ」の記事に譲ります。

第5・第6項目　アカウントとアクセスに、人でない身元の行を足す

第5項目は、管理者を含む利用者のアカウントの資格の割り当てと管理を、第6項目は、アクセスの資格と権限の作成、割り当て、管理、取り消しを求めています。どちらも、人が使うアカウントを前提に書かれてきた項目です。MCPの付属文書が人でない身元の管理を重点に挙げているのは、この前提がAIで変わるからです。

読み替えの要点は、エージェントの身元を、人のアカウントとは別の行として一覧に持つことです。誰がそのエージェントの持ち主か、権限をいつ見直すか、持ち主の異動や退職のときにどう扱うかを、人のアカウントと同じ深さで書きます。鍵の渡し方、期限、止め方といった具体的な対策は「AIエージェントに鍵を渡す前に決めること｜権限は人と分ける」の記事が扱っているので、本稿では一覧に行を持たせるところまでにとどめます。

本番の仕組みへの書き込みの権限をエージェントに渡すかどうかは、この項目で最も重い判断です。本番の権限を渡すか、MCPで新しい接続を許すかは、一覧の行を書いた人ではなく、権限の持ち主である業務部門と情報システム部門の責任者が決めます。個々の接続の審査項目は「MCPで外部とつなぐ前の確認項目一覧｜権限を絞る決め方」の記事を参照してください。

第8項目　監査ログに、誰の代わりに何を呼んだかを足す

第8項目は、攻撃を見つけ、理解し、復旧する助けになる出来事の記録を、集め、警告を出し、見直し、保存することを求めています。MCPの付属文書が記録に残る形でのやり取りを重視しているのも、エージェントの行為が後から辿れなければ、他のどの項目の守りも確かめようがないからです。

読み替えで足すのは、エージェントの1回の行為ごとに、どのエージェントが、誰の依頼で、どの身元を使い、どの道具を呼び、何を読み書きしたかが残ることです。人の操作の記録と同じ場所に、同じ名前の付け方で残すと、後で並べて読めます。記録の項目を決めるのは人、膨大な記録から外れ値の候補を拾うのはAI、という分担が現実的です。

記録の保存の期間も見直します。エージェントは人より多くの行為を短い時間で行うため、記録の量が増えます。量を理由に保存の期間を縮めると、事故の後で辿れなくなります。どの記録をどれだけの期間残すかは、事故のときに何を辿る必要があるかから逆算して人が決めます。

第15・第16項目　提供者と開発の管理に、外の提供元と作る側を足す

第15項目は、組織の重要な仕組みやデータを預かるサービス提供者を評価する手順を求めています。AIエージェントの読み替えでは、モデルの提供元、エージェントの基盤の提供元、MCPでつなぐ道具の提供元が、この評価の対象に入るかどうかが論点です。いずれも、自社のデータに触れ、自社の名前で行為をする仕組みの一部を担っています。

第16項目は、自社で開発したり、預けたり、取得したりするソフトウェアの安全を、作る段階から管理することを求めています。社内でエージェントを組む場合、その開発は第16項目の対象に入ります。社内でAIを作る側が満たすべき技術的な対策は「AIセキュリティガイドラインは作る側の宿題｜総務省の指針を実務へ」の記事が扱い、読み込ませた外部の文に乗っ取られる問題の原因と対策は「AIが外部の指示に乗っ取られる原因と対策｜見えない指示への備え」の記事に譲ります。

この2項目は、最初の5項目が決まってから中身が書ける項目です。どの提供元を評価の対象にするかは、第1・第2項目で数えた資産と道具の一覧から決まり、どの開発を第16項目に乗せるかは、第5・第6項目で決めた身元と権限の範囲から決まります。順番を飛ばして提供元の評価から始めると、評価の対象が定まらないまま書類だけが増えます。

第17項目　事故対応に、エージェントの止め方と戻し方を足す

第17項目は、事故に対応する力を育て、保つための体制を求めています。従来の事故対応の手順は、感染した端末を切り離す、乗っ取られたアカウントを止める、といった人や端末を単位にした手順が中心でした。AIエージェントの付属文書が挙げる意図しないシステムの変更は、この単位では止めきれないことがあります。

読み替えで足すのは、エージェントを単位にした止め方と戻し方です。どのエージェントを、誰の判断で、どの手段で止めるか。止めた後、そのエージェントが行った変更をどこまで遡って確かめ、元に戻すか。止める判断を誰が持つかを、エージェントごとに手順書に名前で書くことが要になります。

止める基準をAIに任せる設計は避けます。異常の候補を出すところまではAIに任せてかまいませんが、業務を止めるかどうかは、止めることによる影響を知っている人が決めます。訓練の場面でも、エージェントを実際に止めて、戻せるかを一度は試すことを勧めます。手順書にあるだけの止め方は、いざという時に動かないことがあります。

手順4　適用しない項目と、例外として受け入れるリスクを書く

読み替えを進めると、AIエージェントには当てはまらない、あるいは当てはめても意味が薄い保護策が出てきます。その場合に大切なのは、黙って空欄にしないことです。適用しないと決めた保護策は、適用しない理由と、決めた人と、決めた日を書いて残します。空欄と、検討した結果の不適用は、監査でも社内の説明でも別のものとして扱われます。

適用すべきだが今は満たせない保護策は、例外として扱います。例外には、満たせない理由、代わりに置く手当て、受け入れるリスクの中身、期限、受け入れを決めた人を書きます。たとえば、エージェントの記録を人の記録と同じ場所に残す仕組みがまだない場合に、当面は週に1回、手作業で抜き取って確かめる、といった手当てです。期限のない例外は、例外ではなく不適用と同じになります。

どの保護策を適用しないか、どのリスクを例外として受け入れるかは、AIに決めさせてはいけない判断です。AIに未対応の項目を洗い出させ、例外の文面を下書きさせるのはかまいません。しかし、受け入れるリスクの重さを判断し、その責任を負うのは人です。例外の受け入れには、セキュリティの担当だけでなく、そのエージェントを使う業務の責任者の名前を並べることを勧めます。

AIに任せてよい作業と、人が決める判断

ここまでの手順の中で、AIに任せてよいのは、既存の管理策の一覧とAI構成の突き合わせの下書き、未対応の項目の洗い出し、記録の要約、例外の文面の下書きまでです。どれも人が確かめる前提の下ごしらえで、AIが間違えても、確かめる段で拾えます。

反対に、次の判断はAIに任せません。どの実装グループまで求めるか、どの保護策をAIエージェントに適用しないか、例外として受け入れるリスク、本番の権限を渡すか、MCPの接続を許すか、の5つです。どれも、誤ったときの責任を負う人が、根拠を見たうえで決めるべき判断です。読み替えの作業で起きやすい失敗も挙げておきます。

• AIが作った突き合わせの表を、人が見ないまま管理策の一覧に貼り付ける
• 付属文書が出たことを理由にAIのための別の一覧を作り、既存の一覧と二重に管理する
• 18項目すべてを同じ重さで一度に読み替えようとし、どの項目も途中で止まる
• 適用しない保護策を理由なく空欄のままにし、検討したのか忘れたのか分からなくなる
• エージェントの身元を人のアカウントの行に混ぜ、持ち主と見直しの時期が誰にも分からない

これらの失敗の多くは、手順の順番を飛ばしたときに起きます。棚卸し、実装グループ、順番、読み替え、例外という並びを守るだけで、かなりの部分は避けられます。

手順5　見直しの周期と、見直すきっかけ

読み替えは一度で終わりません。エージェントの構成は、従来の業務システムよりも速く変わります。周期を決めた定期の見直しに加えて、変化をきっかけにした見直しを、手順の最後に組み込んでおきます。ここまでの手順を通して並べると、次のようになります。

見直しのきっかけのうち見落とされやすいのが、CIS側の改訂です。付属文書は第8.1版を前提にしているため、本体が改訂されれば、読み替えの前提も変わります。2026年10月時点で次の版の公表は確かめられませんでしたが、付属文書と本体の版を一覧の冒頭に書いておくと、改訂の際にどこを見直すかが分かります。

なお、会社全体の守りの層のどこがAIで崩れるかは、管理策の一覧とは別の見方で整理できます。入口・内部・出口の層で見る方法は「AI導入で多層防御が崩れる3か所｜入口・内部・出口に足す層」の記事で扱っています。

よくある質問

問：CISコントロールを使っていない会社でも、この進め方は使えますか。　答：使えます。ISOの管理策や社内独自の一覧でも、AI構成の棚卸し、求める水準の決定、読み替える項目の順番、例外の記録という流れは同じです。ただし、他の規格との対応の付け方は本稿では扱いません。クラウドの管理策の規格については「ISO27017とは何を確かめる規格？｜AIを預ける側の管理策」の記事があります。

問：付属文書の本体はどこで確かめればよいですか。　答：CISの公式サイトに、3本それぞれの紹介のページがあり、そこから入手する形です。本稿は公式の概要とブログをもとに書いており、個々の保護策が付属文書の中でどう扱われているかは、本体で必ず確かめてください。

問：小さな会社でも、実装グループ1をすべて読み替える必要がありますか。　答：CISはどの組織も実装グループ1から始めるべきだとしています。ただ、エージェントを1つしか使っていない段階なら、表で最初に置いた5項目のうち、そのエージェントに関わる行だけを先に書き足すところから始めてかまいません。米国の標準技術研究所のAIのリスク管理の枠組みとの比べ方は、本稿の範囲外です。

• CISコントロールの項目数、保護策の数、実装グループの考え方、第8.1版の改訂内容は、CISの公式サイトに基づきます。項目の日本語の名前は本稿の訳です
• 3本の付属文書の公表日、対象とする層、扱うリスクは、CISの公式サイトの各付属文書の紹介とブログに基づきます（2026年10月3日確認）
• 18項目のうちどれを先に読み替えるか、各項目の読み替えの要点、表の順番は本稿の整理で、付属文書の本体の記述ではありません

まとめ

CISが2026年4月に公表した3本の付属文書は、AIのための新しい枠組みではなく、CISコントロール第8.1版の18項目を、モデル、エージェント、つなぐ道具の層で読み替えるためのものです。だからこそ、実務の要は中身を一度に書くことではなく、自社のAI構成を書き出し、求める実装グループを決め、どの項目から読み替えるかの優先順位を決めることにあります。

本稿では、資産とソフトウェアの棚卸し、データ保護、アカウントとアクセスの5項目を最初に、監査ログ、提供者、開発、事故対応を次に置く順番を示しました。突き合わせの下書きや未対応項目の洗い出しはAIに任せてかまいませんが、どの実装グループまで求めるか、どの保護策を適用しないか、例外として受け入れるリスク、本番の権限とMCPの接続を許すかどうかは、責任を負う人が決めてください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。