本文へスキップ
株式会社オープンナレッジ
株式会社オープンナレッジ Open Knowledge Inc.
Copy-Ready Template:SCS ★3 & SECURITY ACTION 対象:中小企業経営者様・総務人事ご担当者様・士業先生方(商用改変・転載自由) 執筆:株式会社オープンナレッジ 技術調査・編集室(監修:加藤 明生)

そのまま使える「中小企業の情報セキュリティ基本方針&生成AI安全利用ルール」ひな形(SCS★3・SECURITY ACTION対応)

1. 基本と全体像

この記事の要点と4つの章のご案内

なぜ「難しくて長い社内規程」ほど現場で守られなくなるのか?に関するイメージ写真
なぜ「難しくて長い社内規程」ほど現場で守られなくなるのか?
【ひな形 01:社外公開用】情報セキュリティ基本方針(Webサイト・会社案内掲載用)に関するイメージ写真
【ひな形 01:社外公開用】情報セキュリティ基本方針(Webサイト・会社案内掲載用)
そのまま使える「中小企業の情報セキュリティ基本方針&生成AI安全利用ルール」ひな形(SCS★3・SECURITY ACTION対応) の各章におけるテーマと要点一覧表
章構成 主なテーマ 要点と確認ポイント
1. 基本と全体像 なぜ「難しくて長い社内規程」ほど現場で守られなくなるのか? IPAの「SECURITY ACTION(二つ星)」および2026年「SCS評価制度(★3)」を取得するには、経営者が定めた『情報セキュリティ基本方針』の策定と公開が最初の必須要件です。
2. 現場での進め方と対策 【ひな形 01:社外公開用】情報セキュリティ基本方針(Webサイト・会社案内掲載用) 2026年版の社内ルールには、従来のウイルス・パスワード対策に加え、「生成AIへの個人情報・社外秘入力の禁止(学習されない法人環境の利用)」と「3分以内の早期報告者を責めない原則」を盛り込むことが重要です。
3. 関連する制度とルール 【ひな形 02:社内周知用】従業員・スタッフのための「情報安全&生成AI利用 10の約束」 本ページの第2章に掲載している「2つのひな形(社外公開用の基本方針+社内用の10か条ルール)」は、御社の社名を入れるだけで今日からすぐにお使いいただけます。
4. 詳しい技術仕様としくみ 理解を深める確認クイズ(セキュリティ基本方針・AI規程編) いいえ、分厚い規程集は逆効果になることが多いです。誰も読まない50ページの文書よりも、社員全員が3分で読めて今日から守れる「A4・1〜2枚の基本方針と行動ルール」を定め、自社のホームページ(または会社案内)に社外公開し、実際にその通り運用されていることの方がSCS★3でも高く評価されます。本ページのひな形は社名を書き換えるだけでそのままお使いいただけます。
第1章〜第4章では、実務チェックリスト・公的制度基準・詳しい技術仕様を確認できます。
この記事のポイント 要点まとめ
  • 01. IPAの「SECURITY ACTION(二つ星)」および2026年「SCS評価制度(★3)」を取得するには、経営者が定めた『情報セキュリティ基本方針』の策定と公開が最初の必須要件です。
  • 02. 2026年版の社内ルールには、従来のウイルス・パスワード対策に加え、「生成AIへの個人情報・社外秘入力の禁止(学習されない法人環境の利用)」と「3分以内の早期報告者を責めない原則」を盛り込むことが重要です。
  • 03. 本ページの第2章に掲載している「2つのひな形(社外公開用の基本方針+社内用の10か条ルール)」は、御社の社名を入れるだけで今日からすぐにお使いいただけます。

01. なぜ「難しくて長い社内規程」ほど現場で守られなくなるのか?

多くの中小企業がセキュリティ規程を作ろうとして挫折したり、せっかく作った規程が机の奥で眠ってしまったりする一番の理由は、「大企業向けの50ページもあるサンプル規程集をそのままコピーしてしまい、自社の現場には存在しない役職名や専門用語が並んでいるから」です。

実際に現場を守り、かつ経済産業省・IPAのSCS評価制度(★3)やSECURITY ACTION(二つ星)の要件を確実に満たすために必要なのは、次の2つの文書だけです。1つ目はホームページ等に掲載して取引先へ姿勢を示す「情報セキュリティ基本方針(社外公開用・A4で1枚)」、そして2つ目は社員全員が毎日守れる具体的な「社内セキュリティ&生成AI安全利用10か条(社内掲示用・A4で1枚)」です。

身近なたとえで見る「六法全書」と「交差点の横断歩道ルール」 道路交通法の条文をすべて暗記していなくても、「赤は止まれ、青でも左右を確かめて渡る」というシンプルなルールが全員に浸透していれば交通事故は防げます。社内規程もまったく同じで、新入社員でもパートスタッフでも3分で読んで納得できる平易な言葉で書かれていることこそが、最高のセキュリティ規程の条件です。

中小企業の規程整備・生成AIルールに関する3つの重要データ

補助金・公募の必須要件
SECURITY ACTION

IT導入補助金(デジタル化基盤導入枠等)の申請や、2026年SCS評価制度(★3)へのステップアップにおいて、基本方針の策定・外部公開は必須の出発点となります。

シャドーAI(無断利用)防止
「禁止」より「安全な基準」

生成AIのルールが未策定の職場では、社員が個人の無料アカウントに顧客名や会議録を入力してしまうリスクが高まります。入れてはいけない情報の明確化が急務です。

規程と実態の一致(SCS★3)
5分野 15項目 と連動

SCS★3では「規程があること」だけでなく、「規程に書いた多要素認証・不変バックアップ・年1回訓練が実際に動いていること」の一致が確認されます。

ひと目でわかる構造図解:形骸化しない「中小企業のセキュリティ規程・3層ピラミッド構造」

SCS★3・SECURITY ACTION対応:分厚い規程集を不要にする「A4・2枚+自動点検」モデル 文書 01:情報セキュリティ基本方針 【用途】:Webサイト等で社外公開 ・経営トップの署名入り宣言(全6条) ・SECURITY ACTION 申請に直結 ・取引先の調査票「基本方針の有無」に  URLまたはPDF添付で即回答可能 下部の「ひな形 01」をそのまま利用可 文書 02:社内実践&生成AIルール 【用途】:社内掲示・入社時配布 ・パスキー認証・OS更新・USB禁止 ・無料生成AIへの個人情報・機密入力禁止 ・怪しいリンクを踏んだら「3分以内に  LANを抜いて報告(報告者は免責)」 下部の「ひな形 02」をそのまま利用可 仕組み 03:自動点検と証跡保存 【用途】:SCS★3 専門家確認の証跡 ・不変バックアップが毎日成功しているか ・SPF/DKIM/DMARCが有効か自動検証 ・年1回15分の初動・復元訓練の記録 ・規程と実際の設定のズレを自動検知 『お助け隊』が毎月自動でレポート化

02. 【ひな形 01:社外公開用】情報セキュリティ基本方針(Webサイト・会社案内掲載用)

以下の枠内の文章をコピーし、【株式会社〇〇】 と日付・代表者名を御社の情報に書き換えてホームページに掲載するだけで、SECURITY ACTION(二つ星)およびSCS評価制度(★3)の「基本方針の策定・公開」要件を満たすことができます。

TEMPLATE 01:PUBLIC SECURITY POLICY

情報セキュリティ基本方針

【株式会社〇〇】(以下「当社」といいます)は、お客様およびお取引先様からお預かりする情報資産ならびに当社の技術・業務情報をサイバー攻撃や情報漏洩等の脅威から守り、社会の信頼に応えるため、ここに情報セキュリティ基本方針を定め、全役職員がこれを実践することを宣言いたします。

  1. 01. 経営者の責任と体制整備:当社は、代表者主導のもとで情報セキュリティ管理体制を整備し、情報資産の保護と継続的な改善に取り組みます。
  2. 02. 法令および契約上の要求事項の遵守:当社は、個人情報保護法、不正競争防止法その他の関連法令、国が定めるガイドライン(経済産業省・IPAのサプライチェーンセキュリティ対策評価基準を含む)、およびお取引先様との機密保持契約を厳格に遵守します。
  3. 03. 技術的・物理的安全管理措置の順守:当社は、すべての業務用端末の最新化、多要素認証(パスキー等)の順守、ネットワークの適切な分離、およびランサムウェア等によっても消去・改ざんされない不変バックアップの運用により、情報資産の機密性・全体性・可用性を確保します。
  4. 04. 生成AIおよびクラウドサービスの安全な利活用:当社は、生成AIや外部クラウドサービスを業務に活用するにあたり、個人情報や社外秘データが外部のAI学習に利用されない安全な法人環境のみを使用し、無断利用(シャドーIT)を防止します。
  5. 05. 教育・訓練と緊急時の迅速な初動対応:当社は、全役職員に対して定期的な教育および年1回以上の緊急初動・復元訓練を実施します。万が一、情報セキュリティ上の事故やその疑いが発生した場合は、速やかに通信隔離と影響調査を行い、お取引先様および関係機関へ誠実に報告します。
制定日:2026年〇月〇日
【株式会社〇〇】 代表取締役 【氏名】

03. 【ひな形 02:社内周知用】従業員・スタッフのための「情報安全&生成AI利用 10の約束」

こちらは社内掲示や入社時の配布資料としてそのまま使えるA4・1枚の実践ルールです。平易な表現で、現場で迷いやすいポイント(生成AI・振込詐欺・早期報告)を明確にしています。

TEMPLATE 02:INTERNAL 10 RULES & AI POLICY

社内の情報安全&生成AI活用 10の約束

01. ログインは「パスキー・2段階認証」で守る:パスワードの使い回しや付箋貼り付けはやめ、生体認証・スマホ確認を必ず有効にします。
02. パソコン・スマホの更新を放置しない:OSやブラウザの「再起動して更新」が出たら、その日の業務終了時に必ず更新します。
03. 私物USBメモリや個人LINEで仕事のファイルを運ばない:会社が指定した安全な共有フォルダ(期限付きリンク)だけを使います。
04. 無料の生成AIに「個人名・取引先名・未公開図面」を入れない:AIを使う時は会社が許可した法人環境を使い、お客様の実名やマイナンバーは入力しません。
05. AIが作った文章・数字は必ず最後に人間の目で確認する:AIの下書きをうのみにせず、金額・日付・法令・事実に誤りがないか確認してから送ります。
06. 「振込先口座の変更連絡」は必ず電話で裏を取る:メールやFAXだけで振込先を変えず、従来の登録電話番号へ折り返して確認します。
07. 画面の警告に出る電話番号(0120/050等)には厳格かけない:「ウイルスに感染しました」と音が鳴っても画面の番号には電話せず、社内窓口へ連絡します。
08. 外出先での画面の覗き見と置き忘れを防ぐ:席を離れる時は画面をロック(Win+L / Ctrl+Cmd+Q)し、公衆フリーWi-Fiには繋ぎません。
09. 重要データは毎日の「不変バックアップ」対象フォルダに保存する:個人のデスクトップだけに重要書類を置かず、保護された共有領域へ保存します。
10. 「怪しいリンクを押したかも」と思ったら3分以内に報告する(免責の約束):電源は切らずにLANを抜いて(Wi-Fiを切り)すぐ報告してください。早期報告者を会社は決して責めません。

現場で陥りやすい落とし穴と回避策(規程・ポリシー策定編)

落とし穴 01:規程に「3ヶ月ごとにパスワードを強制変更する」と古いルールを書いてしまう

現在の総務省・NIST・IPAのガイドラインでは、「定期的なパスワード変更はかえって推測されやすい連番パスワードを招くため不要(流出疑い時のみ変更し、代わりに多要素認証・パスキーを導入する)」と改定されています。【回避策】古いひな形を使わず、パスキー・多要素認証を軸にした最新ルールにしましょう。

落とし穴 02:「生成AIは全面禁止」とだけ通達し、代替の安全な手段を用意しない

頭ごなしに禁止すると、社員は個人のスマートフォンで無料AIアプリに社外秘を入力してしまいます。【回避策】「個人情報は入れない」「会社が用意した学習オフの環境・裏方自動化ツールを使う」という前向きなルールにしましょう。

落とし穴 03:Webサイトに基本方針を載せただけで、実際のメール認証(DMARC)やバックアップが未設定のまま

2026年からのSCS評価制度(★3)では、宣言だけでなく実際の設定証跡が確認されます。【回避策】基本方針の公開とあわせて、15項目の技術チェックを順番に整えていきましょう。

今日中に終わる!情報セキュリティ基本方針&AIルール導入チェック(3項目)

進捗に合わせてチェックを入れると、次のステップが表示されます(ブラウザ内でのみ動作します)。

現在 0 / 3 項目チェック済み:まずは「ひな形 01」のコピーから始めてみましょう。

理解を深める確認クイズ(セキュリティ基本方針・AI規程編)

Q. 現代の情報セキュリティ規程(パスワード管理と生成AI利用)において、国の最新ガイドラインやSCS評価制度(★3)に沿った正しいルールはどれでしょうか?

選択肢 A:パスワードは毎月必ず変更させ、生成AIについてはルールを作らず個人の判断に任せる クリックして解説を見る →

毎月パスワードを変更させるルールは現在では非推奨です。
また、生成AIの利用ルールを決めずに放置すると、無料AIに顧客名簿や社外秘が入力されてしまうリスクがあるため、明確な基準(選択肢B)が必要です。

選択肢 B:ログインには「多要素認証(パスキー)」を必須とし、生成AIは「学習に使われない法人環境のみ・個人情報入力禁止・人間による最終確認」をルール化する クリックして解説を見る →

大正解です!これが2026年基準の最も合理的で安全なルールです。
定期変更の代わりにパスキーや2段階認証でなりすましを防ぎ、生成AIは安全な環境で下書きに活用しつつ最後を人間が確認することで、安全性と業務効率を両立できます。

選択肢 C:専門用語だらけの80ページの規程集をネットから拾ってきて、誰も読まないまま金庫にしまっておく クリックして解説を見る →

実態と乖離した規程は監査でもすぐに見抜かれてしまいます。
全員が読んで実践できるA4・1〜2枚の明快なルール(選択肢B)を定め、実際のシステム設定と一致させておくことが大切です。

関連コラム・豆知識:Governance & Law History

聖徳太子の「十七条憲法」や戦国大名の「分国法」が短く平易な言葉で書かれた理由

日本最古の成文法とされる聖徳太子の「十七条憲法」や、戦国時代に武田信玄(甲州法度之次第)や今川義元が定めた「分国法」、さらには老舗商家の「家訓・店則」には共通点があります。それは、現場の役人や奉公人が暗唱できるよう「10〜20項目程度の短い箇条書き」に絞られ、「なぜそれを守るのか」の理由が平易な言葉で添えられていたことです。400年前も現代のサイバー空間も、「全員が覚えて行動できる簡潔さ」こそが組織を守る一番の力になります。

自社に合わせた規程カスタマイズ・SCS★★3適合確認のご案内

「取引先から100問のセキュリティ調査票が来て書き方がわからない」「基本方針に沿ったシステム設定を整えたい」という方は、個別相談・設定確認をご利用ください。

場面別の実務確認ポイント

01 中小企業経営者・個人事業主・院長の方へ

IT導入補助金申請やSECURITY ACTION二つ星、SCS★★3取得に必要な「基本方針のWeb公開」を今日中に完了できるテンプレートが手に入ります。

02 総務・人事・法務・労務担当の方へ

入社時オリエンテーションや社内回覧でそのまま配れる「従業員・パート向けセキュリティ&生成AI利用10か条」(第2章)を収録しています。

03 税理士・社労士・中小企業診断士・商工会議所指導員の方へ

顧問先や会員事業者から「補助金の要件で基本方針が必要になった」「AI規程を作りたい」と相談された際の標準配布資料としてご活用いただけます。

04 情報システム担当・DevSecOpsエンジニアの方へ

技術仕様セクションにて、自然言語の規程を形骸化させない「Policy-as-Code(規程の自動コード検証エンジン)」のRust実装を詳解しています。

技術仕様・実装解説(POLICY-AS-CODE & OSCAL COMPLIANCE ENGINE) 4. 詳しい技術仕様としくみ
Rust 2024(NIST OSCAL + Automated Drift Detection)

自然言語規程の形骸化を防ぐ Policy-as-Code 適合性検証エンジン:文書条項と実機テレメトリ(DNS / TLS / OpenZFS / IdP)の連続同型写像

本モノグラフでは、「情報セキュリティ基本方針をWebに公開したが、実際のサーバー設定やバックアップは放置されている」というコンプライアンス・ドリフト(Compliance Drift)を数学的に消滅させるため、(1) NIST OSCAL (Open Security Controls Assessment Language) に着想を得た条項・技術プローブ間の全単射マッピング、(2) SPF/DMARC DNSレコード・TLS 1.3 設定・OpenZFS スナップショット鮮度・FIDO2 適用率の決定論的評価関数、および (3) Rust 2024 による実装コードを提示する。

Architecture
Policy-as-Code / NIST OSCAL
Drift Detection
Clause-to-Telemetry Bijection
Email & TLS Proof
DMARC p=reject + TLS 1.3
Evidence Output
Machine-Readable Audit JSON
1. 設計仕様・数理モデル(Formal Bijection Between Written Security Policy Clauses and Live System Telemetry)

01. 規程条項集合 C と実機状態空間 S の乖離(Compliance Drift)の定義: 従来の情報セキュリティ監査では、自然言語で記述された規程文書 C = {c_1, c_2, …, c_m} と、実際のインフラ設定状態 s(t) ∈ S が独立して管理されていたため、時間の経過とともに宣言内容と実態が乖離するドリフト Δ(t) = ∑_i=1^m 𝕀(φ_i(s(t)) = false) が不可避であった。ここで φ_i : S → {true, false} は条項 c_i に対応する実機検証述語である。SCS評価制度(3〜4)における継続的適合性を保証するには、すべての公開条項 c_i に対して機械実行可能なプローブ関数 φ_i を束縛し、Δ(t) = 0 を日次CIジョブで検証し続ける Policy-as-Code 構造が不可欠となる。

02. 主要5条項に対応する決定論的テレメトリ述語 φ_1 … φ_5: 本ページの「情報セキュリティ基本方針(全5条)」および「社内10の約束」は、以下の5つの機械検証プローブと1対1に対応する。 (a) 認証統制 φ_auth:IdP 上のアクティブ全アカウント集合 U に対し、FIDO2/WebAuthn または TOTP 多要素認証が強制された割合 |U_mfa| / |U| = 1.0 かつ、退職日 t_retire < t_now の有効アカウント数が 0 であること。 (b) メール・ドメイン認証 φ_mail:DNS TXT レコードにおいて SPF が -all(または ~all)で終端かつ DNS Lookup 回数 ≤ 10(RFC 7208 Section 4.6.4)、DKIM 公開鍵長 ≥ 2048 bits、DMARC ポリシーが p=quarantine または p=reject であること。 (c) 不変バックアップ鮮度 φ_backup:最新 OpenZFS スナップショット時刻 t_snap が t_now - t_snap ≤ 86400 s(24時間以内)かつ readonly=on であること。 (d) 生成AIガバナンス φ_ai:法人APIゲートウェイのゼロデータ保持(Zero Data Retention / Opt-out of Training)フラグが真であること。 (e) 訓練・復元実証 φ_drill:直近の初動・リストア訓練実施時刻 t_drill が t_now - t_drill ≤ 365 days であること。

2. パラメータ・構成仕様(Policy Clause to Automated Telemetry Probe Mapping Table)
Written Policy Clause Telemetry Probe Target Formal Pass Predicate SCS ★3 Category
Clause 01/03: Identity & Access IdP / Active Directory / VPN Users mfa_enforced_users == total_users && orphaned_accounts == 0 PROTECT (PR.AA)
Clause 03: Email & Boundary DNS TXT (_dmarc, SPF, DKIM) spf_lookups <= 10 && dmarc_policy in {Quarantine, Reject} PROTECT (PR.DS / PR.IR)
Clause 03: Immutable Backup OpenZFS Dataset Snapshot Age snapshot_age_secs <= 86400 && zfs_readonly == true RECOVER (RC.RP)
Clause 04/05: AI & Annual Drill AI Gateway Config & Drill Ledger ai_training_opt_out == true && drill_age_days <= 365 GOVERN / RESPOND
3. 実装コード・設定仕様(Production Rust 2024 Implementation (crates/ok-policy-engine/src/policy_as_code.rs)) Zero-Unsafe:Clause-to-Telemetry Compliance Drift Evaluator
#![forbid(unsafe_code)]

#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub enum DmarcEnforcement {
    None,
    Quarantine,
    Reject,
}

#[derive(Debug, Clone, PartialEq, Eq)]
pub struct LiveSmeTelemetrySnapshot {
    pub public_policy_url_status_200: bool,
    pub total_active_accounts: u32,
    pub mfa_enforced_accounts: u32,
    pub lingering_retired_accounts: u32,
    pub spf_dns_lookup_count: u8,
    pub dmarc_policy: DmarcEnforcement,
    pub latest_immutable_snapshot_age_secs: u64,
    pub ai_zero_data_retention_enabled: bool,
    pub days_since_last_15min_drill: u16,
}

#[derive(Debug, Clone, PartialEq, Eq)]
pub enum PolicyDriftViolation {
    PublicPolicyPageUnreachable,
    MfaCoverageIncomplete { covered: u32, total: u32 },
    OrphanedRetiredAccountDetected { count: u32 },
    SpfLookupLimitExceeded { lookups: u8 },
    WeakDmarcPolicyNone,
    StaleImmutableBackup { age_secs: u64 },
    ShadowAiTrainingOptOutMissing,
    AnnualIncidentDrillOverdue { days: u16 },
}

/// Evaluates whether the live system configuration strictly satisfies every promise
/// made in the published SME Security & Generative AI Policy (0% Compliance Drift).
pub fn evaluate_policy_as_code_compliance(
    telemetry: &LiveSmeTelemetrySnapshot,
) -> Result<(), Vec<PolicyDriftViolation>> {
    let mut violations = Vec::new();

    if !telemetry.public_policy_url_status_200 {
        violations.push(PolicyDriftViolation::PublicPolicyPageUnreachable);
    }

    if telemetry.total_active_accounts == 0
        || telemetry.mfa_enforced_accounts < telemetry.total_active_accounts
    {
        violations.push(PolicyDriftViolation::MfaCoverageIncomplete {
            covered: telemetry.mfa_enforced_accounts,
            total: telemetry.total_active_accounts,
        });
    }

    if telemetry.lingering_retired_accounts > 0 {
        violations.push(PolicyDriftViolation::OrphanedRetiredAccountDetected {
            count: telemetry.lingering_retired_accounts,
        });
    }

    // RFC 7208 Section 4.6.4 limits SPF DNS-interactive mechanisms to at most 10
    if telemetry.spf_dns_lookup_count == 0 || telemetry.spf_dns_lookup_count > 10 {
        violations.push(PolicyDriftViolation::SpfLookupLimitExceeded {
            lookups: telemetry.spf_dns_lookup_count,
        });
    }

    if telemetry.dmarc_policy == DmarcEnforcement::None {
        violations.push(PolicyDriftViolation::WeakDmarcPolicyNone);
    }

    if telemetry.latest_immutable_snapshot_age_secs > 86_400 {
        violations.push(PolicyDriftViolation::StaleImmutableBackup {
            age_secs: telemetry.latest_immutable_snapshot_age_secs,
        });
    }

    if !telemetry.ai_zero_data_retention_enabled {
        violations.push(PolicyDriftViolation::ShadowAiTrainingOptOutMissing);
    }

    if telemetry.days_since_last_15min_drill > 365 {
        violations.push(PolicyDriftViolation::AnnualIncidentDrillOverdue {
            days: telemetry.days_since_last_15min_drill,
        });
    }

    if violations.is_empty() {
        Ok(())
    } else {
        Err(violations)
    }
}
検証環境・運用について: 当社では、本ページのひな形を用いた基本方針の策定支援から、実際のシステム設定を毎月自動点検する『お助け隊』レポート発行、SCS★3の登録情報処理安全確保支援士による確認までワンストップで提供しています。
規程整備・SCS★3相談へ
ご質問・公的制度の活用に関するお問い合わせ窓口

掲載資料に関するご質問・公的制度活用のご案内

本ページの図解や解説内容に関するご質問、経済産業省「SCS評価制度」やIPA「SECURITY ACTION・サイバーセキュリティお助け隊サービス」等の公的制度の確認方法について、落ち着いた参考窓口としてご案内しております。売り込みや営業連絡は一切行いませんので、社内勉強会やご家庭での確認資料としてご自由にご活用ください。

図解・ビジュアルの拡大表示

図表内のテキストもそのまま選択・検索可能です(ベクターSVG描画) 枠外クリックまたは ESC キーで閉じます