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

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

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

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

統一基準は、国の行政機関、独立行政法人及び指定法人(まとめて「機関等」)に共通の情報セキュリティ対策を定めます。令和7年度版は2025年6月27日にサイバーセキュリティ戦略本部が公表しました。

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

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

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

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

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

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

2026年6月12日のガイドライン一部改定は、公表された改定事項を見る限り、脆弱性対策の強化、IT-BCPの整備、インシデント時の連絡事項の追加、多要素認証の強化、DMARC対応です。Claudeの利用申請に直接かかわる項目は含まれていません。ガイドライン本文でもクラウドサービスの解説は、暗号鍵の管理主体や保存される国・地域を把握せよという趣旨の記述にとどまります。

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

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

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

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

実務で迷いやすいのは機密性2の線です。基準は「不開示情報に該当すると判断される蓋然性の高い情報を含む」という書き方をしています。個人に関する情報、審議中の検討資料、法人の内部情報などが入った文書は、たとえ部分的でも機密性2側に寄ります。

機密性1に当たるのは、公表済みの資料や、開示しても支障がないと判断できる情報です。要約したい公開資料、一般的な文書の文体調整、公開情報に基づく調査のたたき台などが典型でしょう。

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

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

要機密情報を扱う側は、生成AIに限らず重い手続きです。統括情報セキュリティ責任者が「クラウドサービス利用判断基準」「選定基準」「利用申請の許可権限者と利用手続」「管理者の指名」を含む運用規程を整備します。個別の利用では、セキュリティ要件に「情報が保存される国・地域及び廃棄の方法」を含める点と、原則としてISMAP等クラウドサービスリストから選ぶ点が要になります。

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

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

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

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

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

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

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

現場で最も出番が多いのは4.2.3です。公表資料の整理や文書の文体調整など、機密性1情報でClaudeを使う場面が対象になります。手続きは職員、許可権限者、管理者の三者で進みます。

1. 職員等が、サービスの定型約款やその他の提供条件から、利用のリスクが許容できると確認したうえで、許可権限者に利用を申請する
2. 利用申請の許可権限者が、その確認結果を踏まえて審査し、利用の可否を決める
3. 承認する場合は、クラウドサービス管理者を指名し、承認したサービスを記録する
4. クラウドサービス管理者が、サービスを安全に利用するための適切な措置を講じる

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

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

申請書に添える材料の例

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

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

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

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

公式の権限設定には、Readの拒否ルールがあります。Read(./secrets/**) のようにパスを指定すると、Claudeのファイル読み取りツールがそのパスを読めなくなります。組織で使うなら、機密性2以上の文書を置くディレクトリを拒否側に登録しておくと、統一基準の格付を運用に反映できます。

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

上は .claude/settings.json に置く形の例で、ディレクトリ名は例示です。ただし公式は、この拒否ルールがBashの中でシェルが直接ファイルを開く場合まですべて防ぐわけではないと明記しています。たとえばPythonやNodeのスクリプトが自分でファイルを開く場合は対象外です。すべてのプロセスからのアクセスを止めたいときは、サンドボックスを有効にするようにと案内されています。

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

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

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

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

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

まとめ

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

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

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