2026.09.29 セキュリティ

政府統一基準の実装：令和7年度版と2026年6月改定の要件を設定とコードに落とす

政府統一基準は、国の行政機関・独立行政法人・指定法人が守る情報セキュリティのベースラインで、正式名称は「政府機関等のサイバーセキュリティ対策のための統一基準群」です。この記事は条文の要約ではなく、調達仕様書に書かれた項番を、受託側がDNSレコード・IAMポリシー・SBOM・試験項目へ変換する手順を扱います。2026年6月12日のガイドライン一部改定で追加された多要素認証とDMARCの強化、2026年5月に公開されたDMARCの新仕様RFC 9989との食い違いまで、そのまま使える設定例とあわせて整理しました。文書の版と日付は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文書でできています。調達仕様書に引用されるのは主に統一基準の「遵守事項」ですが、受託側が作業に使うのはガイドラインの「基本対策事項」と「解説」です。

統一規範・統一基準・ガイドラインの決定主体と遵守事項・基本対策事項の差

国家サイバー統括室の統一基準群ページによると、統一規範と統一基準はサイバーセキュリティ戦略本部の決定、ガイドラインは内閣サイバー官の決定です。統一基準は「何を満たすか」を遵守事項として書き、ガイドラインは「そのために何をするか」を基本対策事項として書きます。

文書	決定主体	中身	受託側での使い道
統一規範	サイバーセキュリティ戦略本部	目的・趣旨と組織の枠組み	ほぼ参照しない
統一基準	サイバーセキュリティ戦略本部	遵守事項（第1部〜第8部）	調達仕様書の項番を読む
ガイドライン	内閣サイバー官	基本対策事項と解説	設定値・実装方式を決める

統一基準（令和7年度版）は総則・基本的枠組み・情報の取扱い・外部委託・ライフサイクル・構成要素・セキュリティ要件・利用の8部構成です。受託開発に効くのは第4部から第7部で、7.3節には動的なアクセス制御を扱うゼロトラストアーキテクチャの節も置かれています。

2026年6月12日のガイドライン一部改定で増えた5項目と実装側の作業

国家サイバー統括室の2026年6月一部改定の要点資料は、改定事項を5つ挙げています。実装に直結する度合いで並べ替えると次のとおりです。

多要素認証等の主体認証の強化：基幹システム等で強い権限を持つ主体には原則として多要素主体認証方式を導入
DMARC対応：なりすましメールが受信側で quarantine か reject になるよう、政府機関等側のDMARCポリシーを強化
脆弱性対策：全情報システムでセキュリティパッチの適時適用を前提とした運用設計（パッチマネジメント）を行う
インシデント対処：国家サイバー統括室への報告事項にIoC・ログ・デジタルフォレンジック結果等を追加
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)で、対策による変更内容を速やかに報告する義務も加わります。

調達仕様書に出る統一基準の項番を要件定義書の実装項目へ対応させる作業

調達仕様書には「統一基準に準拠すること」とだけ書かれている場合と、項番が列挙されている場合があります。どちらでも、受託側は項番ごとに実装と証跡を対応させた表を作ります。

クラウド利用の項番4.2.1とISMAP等クラウドサービスリストからの選定原則

要機密情報をクラウドで扱う場合、統一基準4.2.1(2)(c)は原則としてISMAP等クラウドサービスリストからサービスを選ぶよう求めています。登録状況はISMAPポータルで確認できます。制度の仕組みと登録費用はISMAPのクラウドサービスリストと管理基準の解説にまとめました。

見落としやすいのは、構成に含めるSaaSとマネージドサービスの一つひとつが対象になる点です。メール配信、ログ分析、エラー監視などの周辺SaaSが未登録なら、代替を探すか、要機密情報を渡さない設計に変える必要があります。4.2.1(2)(b)は、情報が保存される国・地域と廃棄方法をセキュリティ要件に含めるよう求めているため、リージョンとデータ削除の手順も表に書き込みます。

項番ごとに実装場所と証跡を記録するトレーサビリティ表の作り方

表はリポジトリに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部以降の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:[email protected]"

; メールを一切送らないドメイン（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つのポリシーが分けるなりすまし防御の差で詳しく扱っています。

RFC 9989でpctタグが廃止された影響とt=yによる段階移行の書き方

2026年5月、DMARCの新仕様RFC 9989が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条件にある 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まで扱った多要素認証の実装解説を参照してください。

パッチマネジメント前提の運用設計と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）が挙げられています。生成は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のフォーマットと作成・運用の判断で比較しています。

年1回以上と機能追加時の脆弱性診断を委託契約の範囲に書き込む方法

ガイドラインの解説は、定期的な脆弱性診断の頻度を少なくとも1年に1回程度以上とし、機能追加などの変更時にも実施するのが望ましいとしています。構築の委託契約に初回診断だけを入れ、運用保守契約に年次診断を入れ忘れる例が少なくありません。

契約書には「年1回」と「機能追加のリリース前」の2つの契機を書き、診断対象のURLと画面数の上限も添えておくと、見積りと実施範囲がぶれません。診断の実施や報告書の作成を外部に任せる場合は、脆弱性診断・セキュリティ診断のような専門サービスを初めから体制に組み込むと、発注側への説明も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領域を「開発に含む」の一行で済ませた見積りは採らず、項番ごとに作業と成果物を分けて計上してください。

準拠をうたうべきでない場面：未登録SaaS前提の構成と証跡を残せない体制

2つの場面では準拠をうたいません。1つ目は、要機密情報を扱うのに、中核機能がISMAP等クラウドサービスリスト未登録のSaaSに依存し、置き換えも拒まれている構成です。4.2.1(2)(c)の「原則として」を例外で押し切る判断は発注側の権限で、受託側が請け負えるものではありません。

2つ目は、変更の記録を残せない体制です。4.1.2(3)(b)は運用・保守での変更内容の速やかな報告を求めています。本番環境への手作業の変更が常態化している現場で準拠を約束すると、最初の監査で破綻します。この場合は、変更管理の仕組みを先に作る案件として切り出し、準拠はその次の契約で扱うのが筋です。

政府統一基準の調達案件を受けた開発チームから出るよくある質問

調達仕様書を受け取った開発チームから実際に出やすい質問を5つ選び、2026年9月29日時点の公開資料に沿って答えます。

政府統一基準と「政府機関等のサイバーセキュリティ対策のための統一基準」は同じですか？

同じものを指します。正式名称は「政府機関等のサイバーセキュリティ対策のための統一基準」で、統一規範とガイドラインを含めた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登録サービスを使えば統一基準を満たすわけではありません。

地方自治体のシステムにも政府統一基準は適用されますか？

適用されません。地方公共団体は政府統一基準の適用対象外で、総務省の「地方公共団体における情報セキュリティポリシーに関するガイドライン」を基に各団体がポリシーを定める仕組みです。ただし、ガバメントクラウド上で標準準拠システムを動かす場合などは、国の要件と接する場面があります。自治体案件の前提はガバメントクラウドの仕組みと費用負担で整理しています。