NISTとSECURITY ACTIONを並べて見えてくる、一人開発者が「証跡」として残せるもの

二つの枠組みは、一人開発者に何を求めているのか?

日本では、IPA(情報処理推進機構)が2017年から「SECURITY ACTION」を運営している。中小企業などが自らセキュリティ対策に取り組むことを宣言する制度で、「一つ星」「二つ星」の2段階がある。IT導入補助金などの申請要件にも使われている。

米国では、NIST(米国国立標準技術研究所)が2024年2月にサイバーセキュリティフレームワーク(CSF)2.0を公表した。あわせて、小規模事業者向けのクイックスタートガイドなど、実務者向けの資料も公開している。

ただし、どちらも一人開発者に特化した文書ではない。想定されているのは従業員を抱える小規模事業者であり、一人運営に当てはめる際は、読み替えが必要になる。たとえば「従業員教育」は「自分自身の学習記録」に、「担当者の割り当て」は「自分が兼務していることの明示」になる。

本記事の焦点は、対策の「宣言」ではなく、第三者に見せられる「証跡(エビデンス)」である。証跡とは、対策を実施したことを後から確認できる記録や画面保存などを指す。取引先や補助金の審査で問われるのは、取り組む意思そのものより、それを裏づける記録の有無であることが多いと見られる。

NISTの小規模事業者向けガイダンスとは、どのような内容なのか?

6つの機能で整理された構成

CSF 2.0は、サイバーセキュリティの取り組みを次の6つの「機能」に分けて整理している。

機能	意味
統治(Govern)	方針、役割、リスクへの向き合い方を決める
識別(Identify)	守るべき資産やリスクを把握する
防御(Protect)	アクセス制限、更新、バックアップなどで被害を防ぐ
検知(Detect)	異常や侵害の兆候に気づく
対応(Respond)	問題が起きたときに動く
復旧(Recover)	通常の状態に戻す

小規模事業者向けのクイックスタートガイドは、この6機能を、専門部署を持たない組織でも取り組める行動項目に落とし込んだ構成になっている。

「統治」が加わった意味

CSF 2.0では、旧版(1.1)の5機能に「統治」が加わった。一人運営の場合、自分が経営者であり、担当者であり、唯一の利用者でもある。そのため、次のような事項を文書にすることが論点になると見られる。

守る対象の範囲(自社の開発環境、顧客から預かるデータなど)
どこまでのリスクを許容するか(たとえば「数時間のサービス停止は許容、顧客データの漏えいは許容しない」)
誰が最終判断をするか(一人運営では自分自身だが、明記しておくこと自体に意味がある)

達成の証明は利用者側に委ねられている

この枠組みは、取り組みを段階的に進めるための項目を示してくれる。一方で、達成したことをどう証明するかは利用者に任されている。また、NISTのCSFは認証や認定の制度ではなく、自己改善のための参照枠組みである。「NIST準拠」を第三者が認定する仕組みがあるわけではないため、「CSFを参照して自己評価した」という表現が実態に即していると言える。

SECURITY ACTIONは何を宣言する制度で、何を証明しないのか?

一つ星と二つ星の条件

区分	条件
一つ星	IPAの「情報セキュリティ5か条」に取り組むことを宣言する
二つ星	「5分でできる!情報セキュリティ自社診断」を実施し、情報セキュリティ基本方針を定めて外部に公開したうえで宣言する

5か条の内容は、次のとおり基本事項が中心である。

OSやソフトウェアは常に最新の状態にする
ウイルス対策ソフトを導入する
パスワードを強化する
共有設定を見直す
脅威や攻撃の手口を知る

「宣言」であって「審査」ではない

SECURITY ACTIONは、第三者による審査を伴わない自己宣言方式である。ISMS(情報セキュリティマネジメントシステム。組織の情報管理の仕組みを第三者が審査・認証する国際規格に基づく制度)の認証とは性質が異なる。

ロゴを名刺やウェブサイトに掲示することで、取引先に取り組みの意思を示せる点は有効である。ただし、ロゴは対策が実際に機能していることの証明にはならない。「宣言した」という事実と、「実施している」という事実は別物であり、後者を示すには運用の記録が必要になる。

両者を並べると、どこが重なり、どこが違うのか?

重なる領域

資産の把握、アクセス管理、ソフトウェアの更新管理、バックアップといった基本的な衛生管理(サイバーハイジーン)は、両者に共通している。SECURITY ACTIONの5か条は、NISTの「識別」「防御」の一部とおおむね対応づけられる。

違いと比較表

観点	SECURITY ACTION	NIST CSF 2.0(小規模事業者向け資料を含む)
目的	取り組みの意思表示、入口の整備	取り組みの整理と継続的な改善
粒度	5か条と自社診断の25項目程度が中心で、粗い	6機能にわたり、運用サイクルや統治まで扱う
証跡の求め方	宣言の提出が中心で、運用記録の提出は求められない	証明方法は定めず、利用者に委ねる
対外的な通用性	国内の補助金要件や取引先への説明で通用しやすい	国際的に参照されるが、認証ではなく自己評価として扱われる

SECURITY ACTIONは入口の宣言に重点があり、NISTは運用の循環と統治まで視野に入れている。この差が、両者を併用する意味になると見られる。

開発業務に固有の論点

ソースコードの管理、依存ライブラリ(自作コードが利用する外部部品)の脆弱性対応、署名鍵(配布するソフトが正規品であることを示す電子的な鍵)の保護、顧客データの取り扱いといった、ソフトウェア開発に固有の論点は、どちらの資料でも詳細には扱われていないと見られる。ここは、一人開発者が自分の業務に合わせて項目を追加する領域になる。

一人運営のソフトウェア開発者は、実際にどんな証跡を残せるのか?

証跡は、大きく二種類に分けると整理しやすい。

スプレッドシートで管理できる証跡

表計算ソフトを日常的に使っているなら、次の四つの台帳は追加ツールなしで作成できる。

資産・アカウント台帳: PC、スマートフォン、クラウドサービス、ドメイン、リポジトリなどの一覧
更新履歴: OSやソフト、主要ライブラリを更新した日付と内容
バックアップ復元テスト記録: バックアップを取っているだけでなく、実際に復元できたかの確認結果
アクセス権の定期棚卸し: 誰(どのサービス、どの外部協力者)に何の権限があるかの見直し記録

スクリーンショットやエクスポートで残せる証跡

設定画面の状態は、画面保存やエクスポートで残せる。

多要素認証(パスワードに加えて別の確認手段を求める仕組み)の有効化画面
端末のディスク暗号化の設定画面
リポジトリのブランチ保護設定(重要なブランチへの直接の書き込みを制限する設定)

宣言と自己評価表を併せて保管する

SECURITY ACTIONの宣言結果(自社診断の回答、基本方針)と、NISTの各項目に対応づけた自己評価表を、同じフォルダに保管する方法が考えられる。自己評価表は、次のような列で作れる。

NISTの機能	項目	実施状況	証跡の保存先	確認日	確認者	確認方法
識別	資産の一覧化	実施済み	資産台帳.xlsx	2025-04-01	本人	台帳と実機を照合
防御	多要素認証	一部実施	画面保存/2025-04	2025-04-01	本人	各サービスの設定画面を確認
復旧	復元テスト	未実施	(なし)	–	–	–

日付・担当者・確認方法が欠けると検証できない

証跡には、日付、担当者、確認方法の三点を必ず添える必要がある。これが欠けると、「いつ、誰が、どうやって確認した結果なのか」が分からず、後から検証できない記録になってしまう。一人運営では担当者が常に自分になるが、それでも記載することで、記録の性質が明確になると言える。

AI/LLMツールの利用は、セキュリティ上どう扱えばよいのか?

AI/LLM(大規模言語モデル。文章やコードを生成するAIの基盤技術)ツールの利用は、既存の二つの枠組みでは項目が乏しい領域である。NISTにはAIのリスク管理を扱う別の文書(AIリスクマネジメントフレームワーク)があり、日本にも事業者向けのAIガイドラインがあるが、一人開発者の日常業務に直接当てはめられる粒度ではないと見られる。そのため、自主的な補完が必要になる。

一枚の利用ルールにまとめる

まず、何をAIツールに入力してよいかの基準を、一枚の文書にまとめる方法がある。たとえば次のような区分が考えられる。

区分	例	入力の可否
公開情報	公開済みの技術文書、OSSのコード	可
自社の非公開情報	自社製品のソースコード	条件付き(データを学習に使わない設定のプランに限る、など)
顧客情報・顧客のコード	個人情報、契約上の秘密情報	原則不可(顧客の許可がある場合を除く)

利用サービス台帳を作る

使用中のAIサービスを、資産台帳と同じ形式で記録しておくとよい。記録する列は次のとおり。

サービス名
契約プランの区分(無料版、個人向け有料版、法人向けなど)
データの保持期間
入力内容が学習に利用されるかどうかの設定
設定を確認した日付

プランによってデータの扱いが異なることがあるため、確認日付の記録が重要になる。

生成コードのレビュー記録

AIが生成したコードをどのように確認したかの記録は、開発プロセスの証跡になり得る。コードレビューの記録(プルリクエストのコメントなど)、追加された依存ライブラリのライセンスと脆弱性の確認結果が該当する。AIは存在しないライブラリ名を提案することもあるため、依存関係の確認は実務上も意味がある作業と見られる。

取引先や補助金の審査では、どこまで説明すれば十分なのか?

求められる水準の違い

補助金の申請要件は、SECURITY ACTIONの宣言で満たせる場合が多い。一方、取引先から届くセキュリティ質問票は、アクセス管理、バックアップ、インシデント対応(問題発生時の対応手順)、委託先管理など、より詳細な回答を求めることがある。

三層で説明する

説明は、次の三層で組み立てると過不足が出にくいと見られる。

自己宣言: SECURITY ACTIONの宣言(取り組みの意思)
自己評価表: NISTの機能区分に沿った実施状況の一覧(取り組みの範囲)
運用記録: 台帳、更新履歴、復元テスト、設定画面の保存(取り組みの実績)

質問票の各項目には、「宣言→評価表の該当行→記録」の順で答えられる状態にしておくと、回答の根拠を示しやすい。

一人運営特有のリスクへの代替手段

担当者の不在や、自分が唯一の担当者であること(単一障害点)は、取引先が懸念しやすい点である。次のような代替手段を明示すると、信頼性につながると言える。

パスワードマネージャーの緊急アクセス機能や、信頼できる第三者への緊急連絡先の預託
重要データのバックアップ先を複数にすること
長期不在時の連絡方法と対応可能時間の事前告知
他の開発者との相互バックアップ契約など、業務を引き継ぐ手段

実施済みと未実施を区別する

説明では、過大な表現を避けることが重要である。「全社で多要素認証を実施」ではなく、「主要10サービスのうち8サービスで有効化済み、残り2サービスは対応状況を確認中」のように書く。実施済みと未実施を区別して記載する姿勢は、かえって記録全体の信頼性を高めると見られる。

最小限の体制で、何から始めるべきか?

二段構えで進める

現実的な進め方は、二段構えと言える。

SECURITY ACTIONの宣言(一つ星、続いて二つ星)を起点にする
NISTの6機能で自己評価表を作り、不足を洗い出す

今日からできる三つのステップ

最初の一歩: 資産台帳(機器、サービス、アカウント)と、更新・バックアップの記録を、スプレッドシートで作る。日付、担当者、確認方法の列を最初から入れておく。
次の一歩: AIツールの利用ルールと利用サービス台帳を加える。
継続のために: 四半期ごとに記録を見直す日をカレンダーに入れる。アクセス権の棚卸しと復元テストは、この機会にまとめて実施する。

宣言と証跡を分けて考える

SECURITY ACTIONのロゴは「取り組む意思」を示し、運用記録は「実際に取り組んだ事実」を示す。この二つを分けて考えることが、一人運営でも説明可能なセキュリティ体制の要点と見られる。大きな仕組みを導入しなくても、表計算ソフトと画面保存、そして日付の記録から始められる。

なお、制度の要件や名称は改定される場合がある。申請や提出の前には、IPAおよびNISTの公式ページで最新の内容を確認する必要がある。

NIST's Cybersecurity Guide for Solopreneurs vs. Japan's SECURITY ACTION: What a One-Person Software Shop Can Actually Evidence