基本原則：ビジネス×システムの二段判定
★3/★4の判定は、「何を守るか（ビジネス観点）」と「どこまで触れるか（システム観点）」の掛け合わせで決まります。前者は機密性・停止影響・対外説明責任、後者は発注者内部システムへの接続可否・権限の強度・ネットワーク分離・ログの完全性などが軸です。
ビジネス観点（守る価値）
- 重要機密（機微情報・知財・設計）を扱うか
- 停止時の事業影響（納期・法令・社会的影響）の大きさ
- 顧客・監督当局への対外説明責任の強度
システム観点（触れる範囲）
- 発注者内部ネットワークへ接続するか（双方向／一方向）
- 付与権限の強度（管理者・共有ID・APIキー）
- 分離の徹底（ネットワーク／テナント／アカウント）
- ログの網羅性・改ざん耐性・保存年限
判断フロー（決定木）とスコアリング
決定木（最短3問）
- 発注者内部システムへ恒常的に接続するか？
はい → 2へ。いいえ → 3へ。 - 接続経路に特権・共有・APIキーなど高権限が含まれるか？
はい → ★4を第一候補に。いいえ → 3へ。 - 停止が社会的・法的影響を伴う業務か？
はい → ★4を強く推奨。いいえ → ★3を起点（のち重要取引のみ★4拡張）。
スコアリング（100点満点・目安）
| 項目 | 説明 | 配点 |
|---|---|---|
| 発注者内部への接続 | 恒常・広帯域・双方向で高評価（リスク高） | 0/15/25 |
| 権限の強度 | 管理者・共有ID・APIキーの有無・数 | 0/10/20 |
| 分離の徹底 | 業務／管理／顧客ごとに論理分離・テナント分離 | 0/10/15（逆配点） |
| ログの完全性 | 網羅・改ざん耐性・保存期間・検索性 | 0/10/15 |
| 機密性 | 設計・未公開情報・個人関連の有無 | 0/10/15 |
| 停止影響 | 納期・ペナルティ・法令・レピュテーション | 0/10/20 |
判定目安：合計60点以上で★4を第一候補、40〜59点は重要取引を★4候補にしつつ★3で運用固め、39点以下は★3起点。ただし、単一項目でも重大閾値（例：管理者権限×恒常接続）を満たす場合は★4推奨。
システム観点の要点：境界・権限・ログ・分離
1) 境界（接続）の扱い
- 対象 自社から発注者内部へ到達する経路・端末・踏み台・ゲートウェイは制度上の射程に入る前提で棚卸し。
- 設計 必要最小の経路に限定し、双方向→一方向化、永続接続→オンデマンド化。
- 証跡 接続元・宛先・ユーザー・端末姿勢（整備状態）の記録。
2) 権限（ID/IAM）の扱い
- 原則 多要素・最小権限・JIT（Just-In-Time）付与。
- 要注意 共有IDや固定の管理者権限は、★4判定を押し上げる主要因。代替策（PAM、ブレークグラス運用）。
- 自動化 入退社・異動イベント連動で権限の自動剥奪。
3) ログ（監視・保存）の扱い
- 網羅 ID、ネットワーク、エンドポイント、クラウド管理プレーン、主要SaaS。
- 耐改ざん WORM相当の保存・ハッシュ鎖、第三者評価の視点では完全性を重視。
- 活用 アラート閾値・自動相関・定期レビューの「回る運用」。
4) 分離（ネットワーク／テナント／アカウント）
- ネットワーク 顧客接続セグメントは厳格に分離。横移動を想定した境界制御。
- テナント 顧客・環境ごとにテナント分離を基本。共用時はガードレール（ポリシー・タグ・自動化）を明示。
- アカウント 人・機械・APIキーを分離しライフサイクル管理。
ビジネス観点の要点：機密・停止影響・対外説明
1) 機密性（Confidentiality）
設計図、仕様、未公開情報、個人関連など、漏えい時の被害が大きい情報を扱うかどうか。扱うなら★4候補です。暗号化・鍵管理・アクセス審査の高度化が前提となります。
2) 停止影響（Availability）
停止が納期遅延・賠償・法令違反・社会的混乱につながる業務は★4候補。冗長化・復旧訓練・RTO/RPOの明確化と定期検証が求められます。
3) 対外説明（Accountability）
監督当局・大手顧客・市場に対し説明責任が重い場合は★4の第三者評価が信頼性の証跡になります。IR/開示・監査・アシュアランスの一貫性を設計してください。
再委託（下請け）の扱い：波及・責任分界・証跡
★4を選択する場合、重要パートナーの対策状況の把握（少なくとも年1回）など、サプライチェーン全体の見える化が要求されます。再委託が多層に及ぶ場合、責任分界（誰がどこまで対策を保障するか）と証跡の連鎖（誰のログがどこにあるか）を明確にします。
契約・実務で押さえる4点
- 適用範囲条項：本制度の適用対象（IT基盤・境界）を契約で明文化。
- 再委託条件：再委託時に遵守すべき水準（★3/★4）と、違反時の是正・報告期限。
- 監査・報告：年次自己評価・第三者評価の提供、重大インシデントの通報SLA。
- 証跡の帰属：ログの所有・保存年限・提出方法、個人情報・機密情報の扱い。
実例シナリオ：3つの典型パターン
Scenario A：SaaS開発会社（発注者内部へ非接続）
自社SaaSを提供し、顧客とはAPI連携のみ。発注者内部へは非接続。権限は顧客テナントごとに分離、ログはWORM保存。判定：★3起点。ただし機密性が高い顧客向け機能（設計図等）がある場合は、当該契約のみ★4拡張。
Scenario B：保守運用ベンダ（発注者内部へ恒常接続・特権あり）
顧客の基幹にVPN＋特権アカウントで恒常接続。運用委託・緊急対応あり。判定：★4第一候補。分離・特権管理（PAM）・JIT付与・操作録画・月例レビュー・再委託の監督が鍵。
Scenario C：製造業の共同開発（図面共有・一時接続）
共同設計で図面・未公開情報を扱う。一時的に顧客の設計ポータルへ接続。判定：★3＋契約で部分★4。機密性は高いが接続は限定的。接続時の端末姿勢、持出可否、ファイル追跡、キー管理を強化。
RACIと体制：★3運用→★4拡張の二段ロケット
| 領域 | 責任(R) | 説明責任(A) | 協力(C) | 情報(I) |
|---|---|---|---|---|
| 資産・接続棚卸し | IT運用 | CISO/情報セキュリティ委員会 | 各事業部・PM | 経営会議 |
| IAM（権限・MFA・PAM） | セキュリティ | CIO | 人事・総務 | 監査 |
| パッチ・脆弱性対応 | IT運用 | システムオーナー | 開発・ベンダ | 事業責任者 |
| 監視・ログ・保存 | SOC/運用 | CISO | 法務・個人情報保護 | 経営会議 |
| 再委託管理（年次把握） | 調達/ISMS事務局 | CPO/CSO | 主要パートナー | 監査 |
運用Tips：まず★3の「回る運用」を前提にし、重要契約に合わせて★4の要求（第三者評価・証跡強化・再委託監督）を差し込む設計が、コストとスピードの両立に有効です。
テンプレート集（社内説明用・委託契約用）
1) 社内説明用：★3/★4判定メモ（1ページ）
- 案件名・顧客名・期間／システム概要（接続の有無・権限・データ）
- 決定木の回答（Q1〜Q3）・スコアリング結果・重大閾値の該当有無
- 最終判定（★3 or ★4）・根拠・想定コスト・スケジュール
- 再委託の有無・管理方法（年次把握・監査・是正）
2) 委託契約用：条項サンプル（抜粋）
第X条（適用範囲）
甲乙は、本制度の対象が乙のIT基盤および甲の内部システムとの接続境界であることを確認する。
第Y条（再委託）
乙が再委託を行う場合、当該再委託先は乙と同水準（★3又は★4）の対策を実施し、年次自己評価又は第三者評価の結果を提出する。
第Z条（監査・報告）
乙は毎事業年度、自己評価結果を甲に提出する。★4の契約においては更新時の第三者評価結果を提出する。重大インシデントは発覚後○時間以内に通報する。まとめ
- 判定の軸：ビジネス観点（機密・停止影響・説明責任）×システム観点（接続・権限・分離・ログ）。
- 最短ルート：決定木3問で当たりを付け、スコアリングで合意形成。重大閾値に該当すれば★4。
- 再委託：★4は重要パートナーの年次把握などの監督が前提。責任分界・証跡の連鎖を契約に織り込む。
- 実装方針：まず★3の回る運用を標準化し、重要契約から★4の要求を差し込む二段ロケットが効率的。
FAQ（3問）
- Q1. ★3から始めて、後で★4に上げても間に合いますか？
- A. 多くの企業では★3の運用を先に固め、重要契約に合わせて★4要件（第三者評価・再委託監督・証跡強化）を段階導入する設計が現実的です。
- Q2. 顧客の内部に閲覧のみで接続する場合は？
- A. 閲覧専用でも、到達できること自体がリスク。接続の恒常性・権限の強度・ログの完全性次第で★4候補になります。厳密な分離とJIT付与でリスクを抑えれば、★3維持も検討できます。
- Q3. 再委託先が海外事業者の場合の注意点は？
- A. 法域差によるログ保存・開示義務・個人情報規制の違いを確認し、契約で保存年限・提出形式・監査権を明文化。年次把握の方法（自己評価・第三者評価）も指定してください。
