--- title: "政府統一基準の実装：令和7年度版と2026年6月改定の要件を設定とコードに落とす" url: "https://www.issoh.co.jp/tech/details/17951/" published: 2026-09-29 updated: 2026-09-29 categories: ["セキュリティ"] publisher: "株式会社一創" --- # 政府統一基準の実装：令和7年度版と2026年6月改定の要件を設定とコードに落とす 政府統一基準は、国の行政機関・独立行政法人・指定法人が守る情報セキュリティのベースラインで、本体の正式名称は「政府機関等のサイバーセキュリティ対策のための統一基準」、統一規範とガイドラインを含めた全体は「政府機関等のサイバーセキュリティ対策のための統一基準群」と呼ばれます。この記事は条文の要約ではなく、調達仕様書に書かれた項番を、受託側がDNSレコード・IAMポリシー・SBOM・試験項目へ変換する手順を扱います。2026年6月12日のガイドライン一部改定で追加された多要素認証とDMARCの強化、2026年5月に公開されたDMARCの新仕様RFC 9989との食い違いまで、そのまま使える設定例とあわせて整理しました。根拠法・名称の変遷・格付区分といった正式名称で調べる人が知りたい前提も1章にまとめています。文書の版と日付は2026年9月29日時点で国家サイバー統括室の公開資料を確認した内容です。 ## まとめ：政府統一基準の案件で受託側が最初に実装する5項目と根拠の項番 最新は令和7年度版です。統一基準本体は2025年6月27日決定のまま変わっておらず、具体策を書いたガイドラインだけが2025年9月5日と2026年6月12日に一部改定されています。令和8年度版は2026年9月29日時点で公開されていません。 受託側が最初に手を付けるのは次の5項目です。DMARCを `p=quarantine` 以上にする（ガイドライン6.2.2(1)-3）。強い権限を持つアカウントに多要素主体認証を強制する（7.1.1(1)-2）。パッチ適用を前提にした運用設計を構築段階で決める（7.2.1）。SBOMを納品物に含める（4.3.1(1)-4）。そして、どの項番をどの設定で満たしたかを示すトレーサビリティ表を残すことです。 最後の表が抜けると、実装していても監査で説明できません。証跡の設計は要件定義の段階から始めてください。扱う情報の格付（機密性・完全性・可用性の区分）も、要件定義の最初に決めておく項目です。格付が決まらないと、どの遵守事項が効くかが定まりません。 ## 政府統一基準群の3文書と令和7年度版・2026年6月改定の読み分け方 統一基準群は性格の違う3文書でできています。調達仕様書に引用されるのは主に統一基準の「遵守事項」ですが、受託側が作業に使うのはガイドラインの「基本対策事項」と「解説」です。 ### 統一規範・統一基準・ガイドラインの決定主体と遵守事項・基本対策事項の差 [国家サイバー統括室の統一基準群ページ](https://www.cyber.go.jp/policy/group/general/kijun.html)によると、統一規範と統一基準はサイバーセキュリティ戦略本部の決定、ガイドラインは内閣サイバー官の決定です。統一基準は「何を満たすか」を遵守事項として書き、ガイドラインは「そのために何をするか」を基本対策事項として書きます。 | 文書 | 決定主体 | 中身 | 受託側での使い道 | | ------ | -------------- | ------------- | ------------ | | 統一規範 | サイバーセキュリティ戦略本部 | 目的・趣旨と組織の枠組み | ほぼ参照しない | | 統一基準 | サイバーセキュリティ戦略本部 | 遵守事項（第1部〜第8部） | 調達仕様書の項番を読む | | ガイドライン | 内閣サイバー官 | 基本対策事項と解説 | 設定値・実装方式を決める | [統一基準（令和7年度版）](https://www.cyber.go.jp/pdf/policy/general/kijyunr7.pdf)は総則・基本的枠組み・情報の取扱い・外部委託・ライフサイクル・構成要素・セキュリティ要件・利用の8部構成です。受託開発に効くのは第4部から第7部で、7.3節には動的なアクセス制御を扱うゼロトラストアーキテクチャの節も置かれています。構成要素の考え方は[NISTの構成要素から整理したゼロトラストアーキテクチャの設計ステップ](https://www.issoh.co.jp/column/details/13100/)と対応づけると読みやすくなります。 統一基準1.1は、対策項目を部・節・款の3階層で分類し、款ごとに目的・趣旨と遵守事項を示すと定めています。そのうえで、機関等は基本対策事項に例示された対策か、それと同等以上の対策を講じて遵守事項を満たす必要がある、というのが1.1の規定です。ガイドラインの例示どおりでなくても「同等以上」を説明できれば足りる、という読み方が受託側の設計の自由度になります。 ### 2026年6月12日のガイドライン一部改定で増えた5項目と実装側の作業 国家サイバー統括室の[2026年6月一部改定の要点資料](https://www.cyber.go.jp/pdf/policy/general/rev%5Fpointr8%5F6.pdf)は、改定事項を5つ挙げています。実装に直結する度合いで並べ替えると次のとおりです。 1. 多要素認証等の主体認証の強化：基幹システム等で強い権限を持つ主体には原則として多要素主体認証方式を導入 2. DMARC対応：なりすましメールが受信側で quarantine か reject になるよう、政府機関等側のDMARCポリシーを強化 3. 脆弱性対策：全情報システムでセキュリティパッチの適時適用を前提とした運用設計（パッチマネジメント）を行う 4. インシデント対処：国家サイバー統括室への報告事項にIoC・ログ・デジタルフォレンジック結果等を追加 5. IT-BCP：非常時優先業務を支えるシステムかを確認し、IT-BCPの要件を踏まえてセキュリティ要件を策定 4番目は受託側のログ設計に跳ね返ります。IoCやフォレンジック結果を出せるだけのログ項目と保存期間を、7.1.4（ログの取得・管理）の要件として構築時に決めておかないと、事故のあとで報告に必要な材料が残っていません。 ### 適用対象122組織と、民間の受託事業者が調達仕様書で拘束される範囲 改定資料が示す適用対象は、政府機関26組織・独立行政法人86組織・指定法人10組織の計122組織です。民間企業は直接の適用対象ではありません。 それでも受託事業者は拘束されます。統一基準4.1.2は、情報システムに関する業務委託の要求事項を調達仕様書に定めて契約条件にするよう発注側に求めているからです。構築を受ける場合は4.1.2(2)(a)により、セキュリティ要件の実装、セキュリティの観点での試験、開発環境と開発工程の対策の3つが契約上の義務になります。運用・保守を受ける場合は4.1.2(3)(b)で、対策による変更内容を速やかに報告する義務も加わります。 統一基準1.3の用語定義では、「業務委託」は委任・準委任・請負といった契約形態を問わず全て含むとされています（機関等の情報を取り扱わせる場合に限る）。準委任のSES契約だから対象外、という整理は通りません。 ## 正式名称「政府機関等のサイバーセキュリティ対策のための統一基準」の根拠と改定の変遷 「政府機関等のサイバーセキュリティ対策のための統一基準」という長い正式名称で検索する人の多くは、調達仕様書や提案依頼書でこの名称を初めて見た担当者です。ここでは、どの法律に基づく文書なのか、いつから名前が変わったのか、本体の第1部に何が書かれているのかを、実装の前提として押さえます。 ### サイバーセキュリティ基本法26条1項2号から統一規範・統一基準へ至る決定の流れ 統一基準群ページによると、サイバーセキュリティ戦略本部はサイバーセキュリティ基本法（平成26年法律第104号）第26条第1項第2号で、国の行政機関等のサイバーセキュリティに関する対策の基準を作成する役割を負っています。これに基づいて決定されたのが統一基準群で、同ページは令和7年7月1日に統一基準群を決定したと記載しています。 文書ごとの日付は表紙で確かめます。[統一規範（令和7年度版）](https://www.cyber.go.jp/pdf/policy/general/kihanr7.pdf)は平成28年8月31日のサイバーセキュリティ戦略本部決定で、平成30年・平成31年・令和3年・令和5年と改定を重ね、直近は令和7年6月27日の改定です。統一基準（令和7年度版）の表紙も令和7年6月27日です。提案書や設計書に根拠を書くときは「統一基準（令和7年度版、令和7年6月27日サイバーセキュリティ戦略本部決定）」のように文書名と表紙の日付をセットで引くと、発注側の監査担当と版の認識がずれません。 統一基準1.1は、情報セキュリティの基本を機関等が扱う情報の重要度に応じた機密性・完全性・可用性の確保と置き、統一規範の実施に必要な要件として遵守事項を定めるとしています。原案は内閣官房国家サイバー統括室が策定し、サイバーセキュリティ戦略本部が決定する仕組みです。 ### 2005年の統一基準初版から令和7年度版まで：名称と文書構成が変わった5つの節目 統一基準群ページの改定履歴をたどると、名称と構成は次のように変わってきました。本体の名称は「対象」の「対策」のための統一基準という形で、対象の表記と対策の表記がそれぞれ入れ替わっています。古い調達仕様書や既存システムの設計書に旧名称が残っていることがあるため、どの版を指しているかを名称から見分けられると便利です。 | 版 | 対象の表記 | 対策の表記 | 構成の特徴 | | --------------- | ----- | ------------ | ------------------ | | 2005年項目限定版〜第4版 | 政府機関 | 情報セキュリティ対策 | 本体と解説書の2冊 | | 平成23年度版・平成24年度版 | 政府機関 | 情報セキュリティ対策 | 統一管理基準と統一技術基準に分割 | | 平成26年度版・平成28年度版 | 政府機関 | 情報セキュリティ対策 | ガイドライン名は府省庁対策基準策定用 | | 平成30年度版 | 政府機関等 | 情報セキュリティ対策 | 名称に「等」が入る | | 令和3年度版以降 | 政府機関等 | サイバーセキュリティ対策 | 「サイバーセキュリティ」へ改称 | 令和3年度版以降は令和5年度版、令和7年度版と2年ごとに本体が改定され、その間にガイドラインだけの一部改定が入る流れになっています。令和5年度版のガイドラインは令和6年7月、令和7年度版のガイドラインは令和7年9月と令和8年6月に一部改定されました。 ### 第1部総則の格付区分：機密性3段階・完全性2段階・可用性2段階を要件へ写す 統一基準1.2は、情報を機密性・完全性・可用性の3つの観点で格付けします。機密性は3段階で、機密性2情報と機密性3情報をまとめて「要機密情報」と呼びます。完全性と可用性はそれぞれ2段階で、完全性2情報が「要保全情報」、可用性2情報が「要安定情報」です。いずれか1つにでも該当すれば「要保護情報」になります。 行政機関の場合、機密性2情報は情報公開法第5条の不開示情報に該当する蓋然性が高い情報を含むもの、機密性3情報は行政文書の管理に関するガイドラインで秘密文書としての取扱いを要するものと定義されています。4.2.1のISMAP等クラウドサービスリストからの選定原則も「要機密情報を扱う場合」が条件なので、格付が決まらないとクラウドの選定条件すら確定しません。 受託側では、発注側から受け取った格付をデータ項目の単位に写し、保存先と取扱制限を決める表をリポジトリに置いておくと、後段のトレーサビリティ表と突き合わせられます。 ``` # docs/security/data-classification.yaml # 統一基準1.2の格付区分をデータ項目に写す（格付の判断は発注側、写像と実装は受託側） - item: "申請者の氏名・住所" confidentiality: 2 # 機密性2情報＝要機密情報 integrity: 2 # 完全性2情報＝要保全情報 availability: 1 handling: ["暗号化必須", "複製禁止"] storage: "RDS（ISMAP登録サービス・東京リージョン）" - item: "公開済みのお知らせ本文" confidentiality: 1 integrity: 2 # 改ざんで国民の権利を害するおそれ availability: 2 # 可用性2情報＝要安定情報 handling: [] storage: "CloudFront＋S3" ``` `handling` には統一基準1.2が例示する取扱制限（複製禁止・持出禁止・配布禁止・暗号化必須・読後廃棄など）から該当するものを書きます。格付そのものを受託側が決めてしまうのではなく、発注側の判断を写して証跡に残す、という役割分担をこの表で明確にしておきます。 ## 調達仕様書に出る統一基準の項番を要件定義書の実装項目へ対応させる作業 調達仕様書には「統一基準に準拠すること」とだけ書かれている場合と、項番が列挙されている場合があります。どちらでも、受託側は項番ごとに実装と証跡を対応させた表を作ります。 ### クラウド利用の項番4.2.1とISMAP等クラウドサービスリストからの選定原則 要機密情報をクラウドで扱う場合、統一基準4.2.1(2)(c)は原則としてISMAP等クラウドサービスリストからサービスを選ぶよう求めています。登録状況は[ISMAPポータル](https://www.ismap.go.jp/csm)で確認できます。制度の仕組みと登録費用は[ISMAPのクラウドサービスリストと管理基準の解説](https://www.issoh.co.jp/column/details/17439/)にまとめました。 見落としやすいのは、構成に含めるSaaSとマネージドサービスの一つひとつが対象になる点です。メール配信、ログ分析、エラー監視などの周辺SaaSが未登録なら、代替を探すか、要機密情報を渡さない設計に変える必要があります。4.2.1(2)(b)は、情報が保存される国・地域と廃棄方法をセキュリティ要件に含めるよう求めているため、リージョンとデータ削除の手順も表に書き込みます。 ### 発注側が仕様書づくりで参照する要件策定マニュアルとサプライチェーン手引書 統一基準群ページには、本体とガイドラインのほかに「統一基準適用個別マニュアル群」が並んでいます。受託側から見ると、発注側が調達仕様書を書くときの下敷きなので、先に読んでおくと仕様書の要求が予測できます。 | 資料 | 受託側で読む目的 | | -------------------- | ---------------------- | | セキュリティ要件策定マニュアル | 仕様書に入るセキュリティ要件の書き方を先読み | | サプライチェーン・リスク仕様書策定手引書 | 委託先・再委託先に課される要件の範囲を確認 | | 情報セキュリティ監査の実施手引書 | 監査で求められる証跡の粒度を把握 | [情報システムに係る政府調達におけるセキュリティ要件策定マニュアル](https://www.cyber.go.jp/policy/group/general/sbd%5Fsakutei.html)は、要件定義の段階でどんなセキュリティ要件を仕様書に書くかを扱います。[外部委託等における情報セキュリティ上のサプライチェーン・リスク対応のための仕様書策定手引書](https://www.cyber.go.jp/pdf/policy/general/risktaiour7.pdf)（2025年7月1日版）は、委託先によって不正プログラムが埋め込まれるなど、発注者の意図しない変更が加えられるリスクに対象を絞り、開発・製造から運用・保守・廃棄までのライフサイクル全体を範囲にしています。開発工程に組み込む具体的な防御は[開発工程に組み込むサプライチェーンセキュリティの実装判断](https://www.issoh.co.jp/tech/details/16232/)で扱いました。 [統一基準群に基づく情報セキュリティ監査の実施手引書（令和7年7月）](https://www.cyber.go.jp/pdf/policy/general/R7%5FAuditManual.pdf)は、発注側が受ける監査の進め方を示す資料です。監査で何を見せることになるかが分かるので、次のトレーサビリティ表の `evidence` 欄を何で埋めるかの判断材料になります。 ### 項番ごとに実装場所と証跡を記録するトレーサビリティ表の作り方 表はリポジトリにYAMLで置き、設定ファイルと同じレビューを通します。スプレッドシートで別管理にすると、設定変更のたびに表が古くなるためです。 ``` # docs/security/requirements-trace.yaml # 統一基準の項番と、実装場所・証跡・試験を1対1で結ぶ - id: SEC-MAIL-01 kijun: "6.2.2(1)(c)" guideline: "6.2.2(1)-3" requirement: "DMARCは p=quarantine 以上。メールを送らないドメインは p=reject" implementation: "infra/dns/example.com.zone" evidence: "check_dmarc.py の実行ログ（リリースごと）" test: "結合試験 ST-112 なりすまし送信の隔離確認" - id: SEC-AUTH-02 kijun: "7.1.1(1)" guideline: "7.1.1(1)-2" requirement: "管理者権限を持つ主体は多要素主体認証" implementation: "iam/require-mfa.json" evidence: "IAM認証情報レポート（月次）" test: "MFAなしセッションで管理操作が拒否されること" - id: SEC-SCM-03 kijun: "4.3.1(1)" guideline: "4.3.1(1)-4" requirement: "納品物にSBOM（CycloneDX）を添付" implementation: "ci/sbom.yml" evidence: "sbom.cdx.json（リリースタグごと）" test: "SBOMの部品数とlockファイルの突合" ``` `kijun` には統一基準の遵守事項、`guideline` にはガイドラインの基本対策事項を分けて書きます。発注側の監査は遵守事項の単位で、設計レビューは基本対策事項の単位で行われるので、両方の番号がないと質問に答えられません。 ## DMARCをp=quarantine以上へ上げるDNS設定とdig・Python検証 2026年6月改定で最も作業が具体的なのがDMARCです。ドメインを預かる受託事業者は、DNSの変更と点検の自動化までを求められます。 ### 基本対策事項6.2.2(1)-3の送信側・受信側の要件とp=noneを短期に限る理由 [ガイドライン（2026年6月一部改定版）第3部以降](https://www.cyber.go.jp/pdf/policy/general/guider8%5F6%5F02.pdf)の6.2.2(1)-3は、送信側の対策（SPFとDKIMのいずれか又は両方）、受信側の対策（SPFとDKIMの両方）、DMARCポリシーを `p=quarantine` 又は `p=reject` にすることの3点を求めています。やむを得ず `p=none` にする場合も、期間を可能な限り短くするよう書かれています。 解説はさらに具体的です。メールを使わないドメインは `p=reject`、使うドメインは `p=quarantine`、そしてDMARCレポートを取得して正規メールの認証失敗を潰すこと。転送やメーリングリストではSPFが失敗するため、DKIMを検討するよう添えてあります。DNSSECの導入も望ましいとされています。 ### SPF・DKIM・DMARCのTXTレコード例とdigで公開内容を確かめるコマンド ゾーンファイルの記述例です。送信用と、メールを送らないドメインの両方を示します。 ``` ; 送信に使うドメイン example.com. IN TXT "v=spf1 include:_spf.mail.example.net -all" selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..." _dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-rua@example.com" ; メールを一切送らないドメイン（Webサイト専用など） noreply-example.com. IN TXT "v=spf1 -all" _dmarc.noreply-example.com. IN TXT "v=DMARC1; p=reject" ``` 反映後は権威サーバーから引いて確かめます。 ``` dig +short TXT example.com dig +short TXT selector1._domainkey.example.com dig +short TXT _dmarc.example.com dig +short TXT _dmarc.noreply-example.com ``` 解説は、送信に使うドメインだけでなくWebサイトのURLなど機関が使うあらゆるドメインについて、受信者が正当性を確認できる情報を登録するよう求めています。キャンペーンサイト用に取った別ドメインこそ、2行目の `p=reject` の出番です。none・quarantine・rejectの挙動の差は[DMARCの3つのポリシーが分けるなりすまし防御の差](https://www.issoh.co.jp/tech/details/12267/)で詳しく扱っています。 ### RFC 9989でpctタグが廃止された影響とt=yによる段階移行の書き方 2026年5月、DMARCの新仕様[RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html)がStandards Trackとして公開され、RFC 7489を置き換えました。移行作業に効く変更は3つあります。 1つ目は `pct` タグの廃止です。これまでの「`pct=10` で1割だけ隔離」という段階移行は書けなくなりました。代わりに `t=y`（テストモード）が入り、受信側は指定より1段階弱いポリシーを適用します。`p=reject; t=y` なら実際には quarantine、`p=quarantine; t=y` なら none として扱われる仕様です。 2つ目は `np` タグで、存在しないサブドメインに別のポリシーを指定できます。3つ目は組織ドメインの判定がPublic Suffix ListからDNS Tree Walkに変わった点です。 ここに落とし穴があります。`p=quarantine; t=y` は新仕様の受信側では none 扱いになり、ガイドラインの「quarantine 又は reject」を満たしているとは言えません。`t=y` を使うなら `p=reject; t=y` で実質 quarantine にするか、`t` を付けずに `p=quarantine` を置いてください。 ### 複数ドメインのDMARCポリシーをdnspythonで一括点検するスクリプト ドメインが10を超えるとdigを手で打つのは続きません。次のスクリプトは、ガイドラインの要件とRFC 9989の変更点をまとめて判定します。`pip install dnspython` のあと、`python check_dmarc.py example.com noreply-example.com` のように渡します。 ``` import sys import dns.resolver # pip install dnspython def fetch_dmarc(domain): """_dmarc.ドメイン のTXTからDMARCレコードを辞書で返す。無ければNone""" try: answers = dns.resolver.resolve("_dmarc." + domain, "TXT") except (dns.resolver.NXDOMAIN, dns.resolver.NoAnswer): return None for rdata in answers: txt = b"".join(rdata.strings).decode() if txt.lower().startswith("v=dmarc1"): pairs = [kv.split("=", 1) for kv in txt.split(";") if "=" in kv] return {k.strip().lower(): v.strip() for k, v in pairs} return None for domain in sys.argv[1:]: tags = fetch_dmarc(domain) if tags is None: print(domain, "NG: DMARCレコードなし") continue issues = [] policy = tags.get("p", "").lower() testing = tags.get("t", "n").lower() == "y" if policy not in ("quarantine", "reject"): issues.append("p=" + (policy or "未設定")) if testing and policy == "quarantine": issues.append("p=quarantine; t=y は受信側で none 扱い") if "pct" in tags: issues.append("pct はRFC 9989で廃止") if "rua" not in tags: issues.append("rua 未設定（集約レポートを受け取れない）") print(domain, "OK" if not issues else "NG: " + " / ".join(issues)) ``` 出力をCIのログに残せば、トレーサビリティ表の `evidence` にそのまま使えます。 ## 強い権限を持つ主体への多要素主体認証をIAMポリシーで強制する実装 多要素認証は以前から「検討すること」でしたが、2026年6月改定で強い権限を持つ主体には原則導入へ強まりました。対象の洗い出しから始めます。 ### 7.1.1(1)-2の「厳格な主体認証が必要な場合」6類型と対象アカウントの洗い出し ガイドラインの解説は、厳格な主体認証が必要な場合として6つの例を挙げています。VPN等で機関外からリモートアクセスできる主体（管理者権限の有無を問わない）、クラウドサービスの管理機能にアクセスできる管理者、Webコンテンツを更新できる管理者、基幹システムの重要なサーバーの管理者、Active Directoryのドメイン管理者、そして機微な情報を扱うシステムで強い権限を持つ主体です。 受託開発で漏れやすいのは3つ目です。CMSの編集者アカウントも「Webコンテンツを管理・更新できる管理者権限」に当たります。7.1.3の解説は、アカウント管理者や権限管理者のような核心的な権限は常時付与せず、必要なときに申請と承認を経て有効化する方式が望ましいとも書いています。 ### aws:MultiFactorAuthPresentで管理者にMFAを強制する例 AWSでは、[IAMユーザーガイドのMFA条件](https://docs.aws.amazon.com/IAM/latest/UserGuide/id%5Fcredentials%5Fmfa%5Fconfigure-api-require.html)にある `aws:MultiFactorAuthPresent` を使い、MFAなしのセッションを拒否します。MFAデバイスの登録に必要な操作だけは除外しておかないと、初回ログインで自分のMFAを登録できません。 ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "DenyAllExceptMfaSetupWithoutMFA", "Effect": "Deny", "NotAction": [ "iam:CreateVirtualMFADevice", "iam:EnableMFADevice", "iam:GetUser", "iam:ListMFADevices", "iam:ListVirtualMFADevices", "iam:ResyncMFADevice", "sts:GetSessionToken" ], "Resource": "*", "Condition": { "BoolIfExists": { "aws:MultiFactorAuthPresent": "false" } } } ] } ``` ``` aws iam put-group-policy \ --group-name gov-admins \ --policy-name RequireMFA \ --policy-document file://iam/require-mfa.json ``` `BoolIfExists` は、キーが存在しない長期アクセスキーの呼び出しも拒否します。CIが管理者グループの長期キーで動いているなら、先にOIDC連携などの一時認証へ移してから適用してください。 ### SMSやプッシュ通知の2段階認証がAiTMに弱いという解説とフィッシング耐性方式 ガイドラインの解説は、SMSやメールのワンタイムパスワード、スマートフォンへのプッシュ通知といった2段階認証の例を挙げたうえで、AiTM（Adversary in The Middle）型のフィッシングでは突破されうると明記しています。7.1.1(1)-3は、Webブラウザ経由の主体認証にフィッシング耐性を持つ方式の導入を検討するよう求めています。 実装の選択肢はパスキー（WebAuthn）かクライアント証明書です。国民向けのログインにまで一律で入れるかは7.1.1(1)(b)のリスク評価で決め、管理画面は最初からパスキーにしておく。この線引きなら、利用者の負担を増やさずに改定の趣旨を満たせます。方式ごとの実装コードは[耐フィッシングMFAまで扱った多要素認証の実装解説](https://www.issoh.co.jp/tech/details/13314/)を参照してください。 ## パッチマネジメント前提の運用設計とSBOM納品を構築段階で組み込む手順 2026年6月改定は、パッチの適用を「運用で頑張る」ものから「設計で決めておく」ものへ位置づけ直しました。構築を受ける側の成果物が増えます。 ### 7.2.1解説が求める適用基準の事前定義とCVSSで即時適用を分ける判定表 解説は、構成機器とソフトウェア（ファームウェアを含む）の把握、パッチの適用基準、適用時の影響の調査・検証手順を、新規構築と更改の設計段階で定めるよう求めています。適用基準は、製品・セグメント・深刻度を踏まえて事前に決め、即時適用する場合と検証を優先する場合を分けておく。深刻度の物差しにはCVSSなどが例示されています。次の表は、その基準を具体化した本記事の提案例です。 | 条件 | 適用の扱い | 検証 | | ------------------------- | ----------------- | ------------- | | CVSS 9.0以上かつインターネットから到達可能 | 即時適用（運用の一時停止も選択肢） | 適用後に回帰試験 | | CVSS 7.0以上、または悪用が公表済み | 7日以内に適用 | 検証環境で主要シナリオのみ | | 上記以外 | 月次の定期適用に含める | 通常の回帰試験 | 改定資料は、迅速な適用が必要な場合にシステムの運用を一時停止することも検討するよう書いています。停止の判断者と連絡経路は、運用設計書の段階で名前まで決めておきます。 ### syftでCycloneDX形式とSPDX形式のSBOMを生成し納品物に含めるコマンド ガイドライン4.3.1(1)-4は、ソフトウェアなどの調達でSBOMの作成・提供を評価項目にすることを選定基準に定めるよう求めています。安全な開発慣行の参考には[NIST SP 800-218（SSDF Version 1.1）](https://csrc.nist.gov/pubs/sp/800/218/final)が挙げられています。生成は[anchore/syft](https://github.com/anchore/syft)が手軽です。 ``` # インストール（README記載の方法） curl -sSfL https://get.anchore.io/syft | sudo sh -s -- -b /usr/local/bin # リポジトリ直下を走査し、CycloneDXとSPDXの2形式で出力 syft ./ -o cyclonedx-json=./sbom.cdx.json -o spdx-json=./sbom.spdx.json # コンテナイメージを納品する場合はイメージを指定 syft registry.example.com/app:1.4.2 -o cyclonedx-json=./sbom-image.cdx.json ``` ソースから作るSBOMと、ビルド後のイメージから作るSBOMは中身が違います。OSパッケージを含むのは後者だけです。納品するのがコンテナなら、両方を添付しておくと発注側の脆弱性管理が楽になります。形式の選び方は[SBOMのフォーマットと作成・運用の判断](https://www.issoh.co.jp/tech/details/13457/)で比較しています。 ### 年1回以上と機能追加時の脆弱性診断を委託契約の範囲に書き込む方法 ガイドラインの解説は、定期的な脆弱性診断の頻度を少なくとも1年に1回程度以上とし、機能追加などの変更時にも実施するのが望ましいとしています。構築の委託契約に初回診断だけを入れ、運用保守契約に年次診断を入れ忘れる例が少なくありません。 契約書には「年1回」と「機能追加のリリース前」の2つの契機を書き、診断対象のURLと画面数の上限も添えておくと、見積りと実施範囲がぶれません。診断の実施や報告書の作成を外部に任せる場合は、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)のような専門サービスを初めから体制に組み込むと、発注側への説明も1回で済みます。 ## 政府統一基準準拠を受託開発で引き受ける条件と見送る案件の線引き 「統一基準準拠」は、書いた瞬間に証跡を出す義務が生じる言葉です。引き受けてよい案件と、見送るべき案件をはっきり分けておきます。 ### 準拠を見積りに含めてよい条件と工数が膨らむ4.2・7.1・7.2の3領域 引き受けてよいのは、項番の列挙か準拠範囲の合意が契約前にでき、トレーサビリティ表を納品物に含められる案件です。この2点が揃えば、見積りは項番単位で積み上げられます。 工数が膨らむのは4.2（クラウドの選定と利用）、7.1（主体認証・ログ・監視）、7.2（脆弱性・不正プログラム・標的型攻撃）の3領域です。4.2はISMAP未登録の周辺SaaSの置き換え、7.1はログ項目と保存期間の設計、7.2は診断と是正の往復で、いずれも開発本体とは別に日数が要ります。この3領域を「開発に含む」の一行で済ませた見積りは採らず、項番ごとに作業と成果物を分けて計上してください。 見積りの前提には、発注側が決めた情報の格付も書き添えます。要機密情報を扱わない前提で積んだ見積りは、あとから機密性2情報が混ざった時点で4.2の作業が丸ごと増えるためです。 ### 準拠をうたうべきでない場面：未登録SaaS前提の構成と証跡を残せない体制 2つの場面では準拠をうたいません。1つ目は、要機密情報を扱うのに、中核機能がISMAP等クラウドサービスリスト未登録のSaaSに依存し、置き換えも拒まれている構成です。4.2.1(2)(c)の「原則として」を例外で押し切る判断は発注側の権限で、受託側が請け負えるものではありません。 2つ目は、変更の記録を残せない体制です。4.1.2(3)(b)は運用・保守での変更内容の速やかな報告を求めています。本番環境への手作業の変更が常態化している現場で準拠を約束すると、最初の監査で破綻します。この場合は、変更管理の仕組みを先に作る案件として切り出し、準拠はその次の契約で扱うのが筋です。 ## 政府統一基準の調達案件を受けた開発チームから出るよくある質問 調達仕様書を受け取った開発チームから実際に出やすい質問を5つ選び、2026年9月29日時点の公開資料に沿って答えます。 ### 政府統一基準と「政府機関等のサイバーセキュリティ対策のための統一基準」は同じですか？ 同じものを指します。本体の正式名称は「政府機関等のサイバーセキュリティ対策のための統一基準」で、統一規範とガイドラインを含めた3文書の総称が「政府機関等のサイバーセキュリティ対策のための統一基準群」です。令和3年度版より前は「情報セキュリティ対策のための統一基準」という名称だったため、古い仕様書では旧名称が使われていることもあります。「政府統一基準」は略称として本体と統一基準群の両方の意味で使われるため、調達仕様書で見かけたら、統一基準本体の遵守事項を指すのか、ガイドラインの基本対策事項まで含むのかを発注側に確認してください。基本対策事項まで含むなら、2026年6月12日の一部改定版が対象になります。 ### 政府統一基準は民間企業にも適用されますか？ 直接の適用対象は政府機関26・独立行政法人86・指定法人10の計122組織で、民間企業は含まれません。ただし統一基準4.1.2が、委託先への要求事項を調達仕様書に定めて契約条件にするよう求めているため、政府機関等から情報システムの構築や運用を受託すると、契約を通じて同等の対策を求められます。再委託先にも同じ要件が流れる点に注意が要ります。 ### 令和8年度版の政府統一基準はもう公開されていますか？ 2026年9月29日時点で、国家サイバー統括室のページに令和8年度版は掲載されていません。現行は令和7年度版で、統一基準本体は2025年6月27日決定のまま、ガイドラインだけが2025年9月5日と2026年6月12日に一部改定されています。「令和8年度」と書かれた資料は、ガイドラインの令和8年6月一部改定を指していることが多いため、日付で見分けてください。 ### 政府統一基準とISMAPの違いは何ですか？ 政府統一基準は政府機関等自身が守る対策の基準で、ISMAPはクラウドサービスを事前に評価・登録する制度です。両者は、統一基準4.2.1(2)(c)が要機密情報を扱うクラウドを原則としてISMAP等クラウドサービスリストから選ぶよう定めていることでつながっています。クラウド事業者側がISMAPに登録していても、利用する機関側の設定や運用は統一基準で別に求められるので、ISMAP登録サービスを使えば統一基準を満たすわけではありません。 ### 地方自治体のシステムにも政府統一基準は適用されますか？ 適用されません。地方公共団体は政府統一基準の適用対象外で、総務省の「地方公共団体における情報セキュリティポリシーに関するガイドライン」を基に各団体がポリシーを定める仕組みです。ただし、ガバメントクラウド上で標準準拠システムを動かす場合などは、国の要件と接する場面があります。自治体案件の前提は[ガバメントクラウドの仕組みと費用負担](https://www.issoh.co.jp/column/details/16150/)で整理しています。 ## 関連記事 - [ISMAPとは？クラウドサービスリスト・管理基準・費用を2026年時点で解説](https://www.issoh.co.jp/column/details/17439/)：統一基準4.2.1が選定の原則とするクラウドサービスリストの制度解説です - [DMARCの仕組みとnone・quarantine・rejectが分けるなりすまし防御の差](https://www.issoh.co.jp/tech/details/12267/)：6.2.2(1)-3で求められるポリシーの挙動を詳しく扱います - [多要素認証（MFA）とは？3要素と実装方式・耐フィッシングMFAをコード付きで解説](https://www.issoh.co.jp/tech/details/13314/)：7.1.1(1)-2と(1)-3を満たす認証方式の実装です - [SBOMとは？ソフトウェア部品表の目的・フォーマットと作成・運用の判断を解説](https://www.issoh.co.jp/tech/details/13457/)：4.3.1(1)-4で評価されるSBOMの形式と運用です - [サプライチェーンセキュリティとは？開発工程に組み込む防御と2026年規制対応の実装判断](https://www.issoh.co.jp/tech/details/16232/)：サプライチェーン・リスク仕様書策定手引書が求める委託先対策の実装です - [ゼロトラストアーキテクチャとは？NISTの構成要素と設計ステップを解説](https://www.issoh.co.jp/column/details/13100/)：統一基準7.3節のゼロトラストアーキテクチャを設計する前提知識です - [ガバメントクラウドとは？自治体が使う仕組み・対象サービス・費用負担を解説【2026年版】](https://www.issoh.co.jp/column/details/16150/)：自治体案件で国の要件と接する場面の前提知識です --- 出典: [政府統一基準の実装：令和7年度版と2026年6月改定の要件を設定とコードに落とす]()（株式会社一創）