政府機関の統一基準はClaudeの利用に何を求めるか — クラウド4.2節の申請と要機密情報の線引き

省庁や独立行政法人の職員がClaudeを業務で使うとき、最初に当たる基準が「政府機関等のサイバーセキュリティ対策のための統一基準」です。令和7年度版の本文には「生成AI」という語が出てきません。生成AIは専用の章を持たず、クラウドサービスの規定に乗って扱われます。

この記事は、その規定の読み方を順にたどります。分かれ目は、入力する情報が「要機密情報」かどうかです。要機密情報を扱うなら4.2.1と4.2.2、扱わないなら4.2.3が動きます。手続きの重さがまるで違います。

用語を先に押さえます。要機密情報は、機密性2と機密性3の情報を合わせた呼び名です。ISMAP(イスマップ)は、政府が求めるセキュリティ要件を満たすクラウドサービスを登録する制度で、登録サービスの一覧がISMAP等クラウドサービスリストです。このリストから選ぶ原則が働くのは4.2.1側だけで、約款で使うClaudeを4.2.3で申請する場合に、リスト登録は求められていません。

統一基準は生成AIを名指ししない — 読み替えの入口はクラウドサービスの節

統一基準は、国の行政機関、独立行政法人及び指定法人(まとめて「機関等」)に共通の情報セキュリティ対策を定めます。令和7年度版は2025年6月27日にサイバーセキュリティ戦略本部が決定しました。2026年9月14日に一部改定され、2026年10月1日から施行されています(附則)。クラウドサービスの節は、この改定後の本文でも4.2.1から4.2.3の3款です。

冒頭で触れたとおり、この版の本文に「生成AI」の語はありません。生成AI専用の遵守事項もありません。チャット型のAIサービスをブラウザから使う行為は、統一基準の目から見ると「外部のクラウドサービスに情報を送る行為」です。

クラウドサービスの例として本文が挙げるのは、IaaS、PaaS、Web会議サービス、ソーシャルメディア、検索サービス、翻訳サービス、地図サービスです。Claudeのような対話型サービスも、この延長線に置くのが自然です。統一基準が例に挙げていないだけで、AIかどうかで扱いは変わりません。

生成AI固有の論点は、デジタル庁の「行政の進化と革新のための生成AIの調達・利活用に係るガイドライン」側にあります。適用対象外になる条件は公共調達でClaude等生成AIが適用対象外になる条件、リスク判定の考え方はデジタル庁の生成AIガイドラインをClaude社内規程に転用するで扱っています。統一基準はその土台にあたる、情報セキュリティ全般のルールです。

統一基準群の3文書 — Claudeの申請に効くのはどれか

統一基準群は3つの文書で構成されます。

各機関等は、統一基準をもとに自組織の「対策基準」を作ります。職員が実際に従うのはこの対策基準と、そこから落とし込まれた運用規程です。したがって、Claudeを使えるかどうかの最終判断は、所属機関の運用規程にあります。統一基準は「運用規程に何を書いておかねばならないか」を定める側です。

ガイドラインの改定履歴を並べると、改定ごとの中身が違います。2025年9月5日は、セキュリティ要件適合評価・ラベリング制度の運用開始や多要素認証の導入促進などです。2026年6月12日は、脆弱性対策・IT-BCP・インシデント対処・多要素認証・DMARC対応の強化です。直近の2026年10月1日は、サイバーセキュリティ基本法の改正に伴う用語定義の一部修正にとどまります。どの回の履歴にも、生成AIやClaudeの利用申請にかかわる項目は載っていません。

ガイドラインの本文にも「生成AI」の語は出てきません。クラウド利用で解説が付くのは、情報システム台帳に書く暗号鍵の管理主体、情報が保存される国・地域、サービスレベルの3つです。暗号鍵をサービス提供者が管理している場合、提供者が利用者の情報を復号できる可能性があると解説されています。

情報の格付 — 「要機密情報」に当たるかが最初の分岐

Claudeに何かを入力する前に、その情報がどの格付かを決めます。統一基準は機密性を3段階に分けます。

• 機密性3情報: 国の行政機関では、文書管理ガイドラインが定める秘密文書として扱うべき情報
• 機密性2情報: 情報公開法の不開示情報に当たる蓋然性の高い情報を含む情報で、機密性3情報以外
• 機密性1情報: 不開示情報に当たる蓋然性の高い情報を含まない情報

機密性2情報と機密性3情報を合わせて「要機密情報」と呼びます。この定義が、以降の分岐の軸になります。

機密性2の線は、情報公開法第5条各号の不開示情報に当たると判断される蓋然性の高い情報を「含む」かどうかで引かれます。文書の一部にでも含めば機密性2側です。入力予定の文書は、全体ではなく部分ごとに見る必要があります。

機密性1の側には、公表を前提にした情報が入ります。統一基準は職員等に、情報を公表する場合はその情報が機密性1に格付されるものかを確認するよう求めています。公開資料の要約や、公開情報に基づく調査のたたき台はこの側です。

要機密情報を扱うか扱わないかで、手続きは2系統に分かれる

統一基準のクラウドサービス規定は、要機密情報を扱う場合と扱わない場合で、節が分かれています。

要機密情報を扱う側は、生成AIに限らず重い手続きです。統括情報セキュリティ責任者が「クラウドサービス利用判断基準」「選定基準」「利用申請の許可権限者と利用手続」「管理者の指名」を含む運用規程を整備します。

要機密情報を扱う側には、利用が終わるまでの定めもあります。4.2.2は、導入・構築、運用・保守、更改・廃棄の各段階に運用規程を求めます。運用開始前にクラウドサービス管理者が整える実施手順は、次の3つです。

• サービスごとの情報セキュリティ水準を維持する手順
• 運用中にインシデントを認知したときの対処手順
• サービスが停止または利用できなくなったときの復旧手順

利用終了時には、サービスで取り扱った情報の廃棄と、利用のために作ったアカウントの廃棄も運用規程に入ります。ガイドラインは、廃棄方法に暗号化消去も考えられるとしつつ、暗号化に用いた鍵の管理を確実に実施していることの確認が要ると解説しています。ClaudeのTeamやEnterpriseを機関が導入するなら、止まったときの復旧手順と解約時の廃棄は、契約前から決めておく項目になります。

ISMAP側の整理、つまりBedrock経由と直接契約でどう扱いが変わるかは官公庁がClaudeを使うにはISMAP登録がどう関わるかに詳しくあります。この記事はそこで扱われていない、統一基準側の手続きの構造を補います。

約款だけで使えるサービスは、原則として要機密情報を扱えない

4.2.1の目的・趣旨には、Claudeの契約形態を考えるうえで外せない一文があります。民間事業者が不特定多数の利用者に提供する、定型約款や規約等への同意のみで利用可能なクラウドサービスは、機関等への特別な扱いを求められない場合が多いというものです。そのため要機密情報を扱うのに必要十分なセキュリティ要件を満たすことが一般に困難で、原則として要機密情報は扱えません。この場合は4.2.3の規定に従います。

同じ扱いは、別の節にも出てきます。ソーシャルメディアの節は、約款等への同意のみで使えるサービスであることを理由に、要機密情報を扱わず、委託先に高いレベルの情報管理を要求する必要がない場合に限って使うと定めています。そのうえで、利用時は4.2.3を参照するよう指示します。チャット型AIを約款のみで使う形態は、この枠組みと同じ線に乗ります。

これをClaudeに当てはめると、次のように読めます。

表の左列の読み方は、基準本文に「Claude」が出てくるわけではなく、契約形態への当てはめです。特にEnterpriseが「約款のみ」に当たるか否かは、個別の契約内容と各機関の判断に依存します。

もう一点、重要な誤解が生まれやすい箇所があります。「有料プランなら学習されないから大丈夫」という理解です。Anthropicの商用規約は、サービス上の顧客コンテンツでモデルを学習してはならないと定めます。これは有力な材料ですが、統一基準が要機密情報の扱いで見るのは学習の有無だけではありません。保存される国・地域、廃棄の方法、サービスレベル、責任分界の整理まで含めた要件です。学習しないことは、その一部にすぎません。プラン別の学習・権利の違いはClaude商用利用の可否・生成物の権利・データ学習のオプトアウトをプラン別に確認するにまとめています。

要機密情報を扱わない場合の申請 — 4.2.3の4つの役割

現場で最も出番が多いのは4.2.3です。公表資料の整理や文書の文体調整など、機密性1情報でClaudeを使う場面が対象になります。

4.2.3の目的・趣旨には、設計の意図が書かれています。要機密情報を扱わない場合でも、機関等から種々の情報を送信していることを認識し、リスクを踏まえて可否を判断することが求められます。一方で、要機密情報と同等の対策を求めるとクラウド利用の推進を妨げるため、この款の遵守事項に従って対策すれば足りる、という整理です。

注目すべきは最初の段です。リスクの確認を、申請する職員が約款や提供条件を読んで行う設計になっています。専門部署が代わりに調べてくれる形ではありません。だからこそ、申請の前に読むべき箇所を整理しておく価値があります。

統括情報セキュリティ責任者の側にも宿題があります。運用規程に「利用可能な業務の範囲」「許可権限者と利用手続」「管理者の指名と利用状況の管理」「利用の運用規程」を含めておくことです。すでに規程がある機関なら、ここにClaudeを含めるかどうかは、規程の書き方次第で決まります。

4.2.1との違いも押さえておきます。要機密情報を扱う側は、情報システムセキュリティ責任者または課室情報セキュリティ責任者が、格付と取扱制限を踏まえてセキュリティ要件を定めます。4.2.3では、この要件策定の役割が遵守事項に出てきません。

申請書に添える材料の例

約款や提供条件から何を拾うか。統一基準が明示するのは「リスクが許容できることの確認」だけで、書式は各機関が決めます。次は、確認の観点をClaudeの提供条件に対応づけた例です(あくまで例示です)。

保持と廃棄についてはClaudeのゼロデータ保持は何を守るのかが、契約範囲との関係まで整理しています。

Claude Codeを使うなら、格付をファイル単位で入口に置く

統一基準は「情報の格付」で判断します。チャット画面に文章を貼るなら、貼る前の人間の判断で足ります。一方、Claude Codeはローカルのファイルを自分で読みます。読ませたくないファイルを、うっかり読ませないための機構が要ります。

公式の権限設定には、Readの拒否ルールがあります。Read(./.env) のようにパスを指定すると、カレントディレクトリの該当ファイルを読む動作が拒否されます。拒否は許可より先に評価され、広い拒否に対して狭い許可で例外を作ることはできません。組織で使うなら、機密性2以上の文書を置くディレクトリを拒否側に登録しておくと、統一基準の格付を運用に反映できます。

{
  "permissions": {
    "deny": [
      "Read(./機密2/**)",
      "Read(./機密3/**)",
      "Read(./.env)"
    ]
  }
}

上は .claude/settings.json に置く形の例で、ディレクトリ名は例示です。Readの拒否ルールは、組み込みのファイルツールのほか、Bashの cat・head・sed などClaude Codeが認識するファイル操作と、リダイレクトの対象にも効きます。一方、grep -r のようにファイルを名指ししない読み取りや、PythonやNodeのスクリプトが自分でファイルを開く場合は対象外です。すべてのプロセスからのアクセスを止めたいときは、サンドボックスを有効にするよう案内されています。

したがって、拒否ルールは「うっかり」を防ぐ一段目です。機密性2以上のファイルが同じ作業ディレクトリに混在する運用そのものが、統一基準の考え方と相性が悪いと言えます。要機密情報を扱う作業は、4.2.1の選定を通過した経路の側に寄せ、Claude Codeの作業ディレクトリには機密性1の資料だけを置くほうが、説明が単純になります。

運用に落とすときの最初の3手

統一基準の側から見て、まず動かせるものは限られています。

• 所属機関の対策基準・運用規程で、クラウドサービスの利用申請の窓口と許可権限者を確認する(4.2.3の申請はここに出す)
• 入力する予定の情報を、機密性1・2・3のどれかに仕分ける。迷う情報は機密性2として扱う
• 約款・商用規約・保持条件から、上の表の観点を拾って申請の根拠メモにする

要機密情報を扱いたい場合は、個人の申請では完結しません。統括情報セキュリティ責任者が4.2.1の運用規程を整備し、その選定基準に沿ってサービスを選ぶ流れになります。自治体職員が読み替える場合の総務省ガイドライン側の線引きは自治体職員の生成AI利用と総務省ガイドラインが扱っています。統一基準の直接の適用対象は国の行政機関、独立行政法人及び指定法人であって、自治体は入っていません。

まとめ

統一基準は生成AIを名指しせず、クラウドサービスの規定で縛る設計です。だからClaudeの利用申請も、AI専用の窓口ではなく、既存のクラウド利用申請に乗ります。

分岐は要機密情報かどうかの一点です。機密性1の情報なら4.2.3の申請で、職員自身が約款や提供条件を読んでリスクを確認します。機密性2以上を入れたいなら、4.2.1の手続きの側に入り、個人の努力では届きません。

約款のみで使える形態は原則として要機密情報を扱えない、という一文が、無料・個人プランの線引きを決めます。有料の商用プランでモデル学習が行われないことは有力な材料ですが、それだけで4.2.1の要件が満たされるわけではありません。申請書を書く前に、情報の格付、契約形態、そして保存国と廃棄の3点をそろえておくと、審査の場で話が進みます。