はじめに ―― そして、正式リリースのご報告

こんにちは、小山（@securoi_koyama）と申します。
エンジニア、コーポレートIT、インフラ・セキュリティ実務の現場に身を置いて20年以上が経ちました。エンタープライズ向けのシステム構築、法執行機関・官公庁関連の高度なセキュリティ案件、そして上場準備（IPO）の修羅場におけるIT全般統制（ITGC）の構築を、最前線で経験してきました。

その私が、手作業の限界と、現場に押し付けられる「形骸化したExcel仕事」をシステム構造で根本から解決したい一心で開発してきた、セキュリティ投資判断・ITGC可視化SaaS『SecuROI（セキュロイ）』が、このたび法人化（合同会社SecuROI）を完了し、正式にサービスを開始しました。

この記事では、多くの成長ベンチャーのコーポレートIT（情シス）やエンジニアが直面する「監査法人から突きつけられるITGCの不備指摘」と「終わらないExcelの書類仕事」を、コンサルに頼らず、いかにシステムアーキテクチャとデータ構造で自動化するかという設計思想を、実務の知見を交えて公開します。

1. なぜ「Excelの内部統制・チェックシート」は現場を疲弊させ、形骸化するのか

J-SOX対応や上場審査（N-2期、N-1期）が始まると、監査法人やコンサルから、国際基準（NIST CSFやCIS Controls）に基づいた膨大な「ITGCチェックシート（Excel）」が渡されます。

「アカウントの追加・削除の承認エビデンスは？」「ソースコードの変更管理と、本番デプロイの職務分掌のドキュメントは？」

これらをExcelで管理しようとした瞬間、現場の運用は崩壊します。理由は、Excel運用が抱える3つの致命的なアンチパターンです。

アンチパターン①：客観的証跡のない「性善説の○」

Excelのチェックシートは、情シスが手作業で「変更管理：○」と入力すれば、ドキュメントとして成立してしまいます。しかしこれは「嘘（見栄）がつける」という統制上の大穴です。監査法人から「では、その『○』の根拠となるGitHubのプルリク承認URLか、Jiraチケットを、今すぐランダムに5件出して」と言われ、現場は徹夜のスクショ集めに追われます。

アンチパターン②：現場をパンクさせる「入力負荷の一様性」

一般的なチェックシートは、「できていること」も「できていないこと」も、同じだけのテキスト入力を要求します。全社アンケートを回収し、すべてのツール設定を毎月Excelに転記する運用は、日々のヘルプデスクやキッティングでパンクしている実務者のリソースを完全にすり潰します。結果、誰も更新しなくなり形骸化します。

アンチパターン③：技術と経営の「認識の非対称性」

エンジニアが「GitHubのブランチ保護を強制し、本番デプロイ用のIAM権限を厳格化した」と説明しても、経営陣（CxO）には「それで上場審査に通るの？売上にどう跳ね返るの？」というビジネス言語に翻訳されず、投資やリソースの正当な評価（ROI）に繋がりません。

この「Excelベースの書類仕事」を、システム構造（コードとDB）で解決すべきだ、というのが私の出発点です。

2. 設計原則①：入力はふだんの言葉、採点は「決定論的エンジン」（AI不使用）

1つ目の原則は、「表面言語と裏マッピングの分離（二面構造）」 と 「スコア算出にLLMを使わない（決定論的アーキテクチャ）」 です。

現場の負担を下げるため、入力インターフェースからは「ITGC」「NIST CSF」といった専門用語と自由記述を排除しました。「退職者のアカウントはどう止めている？」という日常の運用感覚に沿った4択の設問（20問）をタップするだけ。その裏側で、財務統制のITGC 4領域やNISTフレームワークへ機械的に自動マッピングされます。

二面構造のマッピング例

顧客が見る（表面の選択肢）	システムが持つ（裏のデータ構造）	出力レポート
「退職当日中に、自動連携または手動で全権限を削除している」	`maturity_level: L4` `itgc_domain: アクセス管理` `nist: PR.AA（アイデンティティ管理・認証）`	【ITGCアクセス管理】おおむね充足（L4）→監査法人へ提出可能なチャートに変換

算術による決定論的採点（再現性＝監査耐性）

ここで最も重要な技術的ガードレールは、「LLMにスコアの算出や必須/任意の判定をさせない」 ことです。LLMは確率的な出力を行うため、同じインプットでも、プロンプトの揺れやモデルの気まぐれで算出スコアが変わり得ます。

内部統制やJ-SOXの文脈で、昨日「75点」だったものが、何の設定も変えていないのに今日「72点」に揺れるシステムは、監査耐性がゼロで、プロダクトとして一発失格です。
そのため、採点ロジックはサーバーサイドの算術ロジックのみで実行し、採点基準にはバージョン（methodology version）を持たせています。 「同じ回答データ＋同じMethodologyバージョン＝ 100%同じスコア」 という決定論的な再現性を担保しています。

3. 設計原則②：「証跡ポインタの非対称バリデーション」で性善説に基づくExcel管理を是正する

2つ目の原則は、現場の入力負荷を劇的に下げる 「証跡ポインタの非対称設計」 です。

「自己申告の嘘」を排除しつつ、現場が書類仕事で忙殺されないように、次のバリデーションを強制しています。

ルールA： 前回の四半期診断より成熟度スコア（Maturity Level）を「上げる（改善した）」と回答した場合のみ、そのエビデンス（Googleドライブのフォルダ、社内規定名、ツール設定画面のリンク等）を指す参照ポインタの入力をシステムが要求する。
ルールB： スコアが「維持」または「悪化」の場合は、証跡入力を求めず、入力負荷をゼロにする。
ルールC： 証跡ポインタがない状態でのスコア上昇は、サーバーサイドのバリデーションで弾き、保存自体を拒否する（DBへの書き込みがブロックされる）。

// 差分再診断（Delta Reassessment）時の非対称バリデーション（実装イメージ）
// 成熟度を「上げる」場合のみ、証跡ポインタ（evidence_ref）の入力を必須とする
if (isRaised && !evidenceRef?.trim()) {
  throw new Error(
    '成熟度を上げる変更には、根拠（参照先URL・設定名など）の入力が必要です。'
  )
}
// 維持・悪化の場合は証跡不要（入力負荷を徹底的に下げるガードレール）

evidence_ref は、URLでも設定名でも受け入れる単一の「ポインタ」フィールドです。生データそのものは受け取りません。
この非対称設計により、現場は「自分たちが本当に改善して、監査法人にアピールしたい部分」だけ、裏付けポインタを貼ればよくなります。証跡のない自己申告はサーバーサイドで弾かれるため、出力レポートは「本当に改善したのか」の信頼性が構造的に担保されます。

4. 設計原則③：脆弱性の塊を作らない「データ最小化」と「テナント完全分離（RLS）」

セキュリティ診断SaaSを作るにあたり最も神経を研ぎ澄ませたのが、「顧客の弱点データ（どこに不備があるか）が、攻撃者にとって最高のご馳走（標的マップ）になる」というリスクです。

官公庁向けのセキュリティ案件などでも培った「性悪説・ゼロトラスト」の原則から、DB設計に2つのガードレールを最初から組み込みました。

① 生データを一切「預からない」データ最小化

SecuROIは、顧客のJiraの生チケットや社内システムのアクセスログ（RAWデータ）を保存しません。 保持するのは、answer テーブルの「4択の回答（choice_id）」と、顧客自身の社内資産を指す「ポインタ（evidence_ref）」のみです。
万一DBが直接侵害される最悪の事態でも、そこには「4択の回答」しか存在しないため、他社攻撃の踏み台（脆弱性マップ）が機能しないよう、リスクを構造的にダウングレードしています。

② PostgreSQL層でのRow-Level Security（RLS）によるテナント隔離

テナント間のデータ越境（顧客Aと顧客Bの診断を閲覧できるバグ）を、アプリケーションコード（where句の書き忘れ等）に依存するのは危険です。そのため、バックエンドにSupabase（PostgreSQL）を採用し、DB層でRLSを強制しています。

-- 実際のテナント隔離ポリシー（assessmentテーブル）
-- 認証ユーザー(auth.uid())から profiles 経由で org_id を解決し、
-- 自テナントの行以外はDB層でアクセスを遮断する
CREATE POLICY "assessment_tenant_isolation" ON assessment
  FOR ALL USING (
    org_id = (SELECT org_id FROM profiles WHERE id = auth.uid())
  );

アプリケーションコードが、どんなバグを出そうと、DB層の認証ユーザーのテナント（org_id）と一致しない行へのアクセスは遮断されます。

③ お客様アカウントのMFAと、運営者アクセスの最小化

お客様がSecuROIにログインする際は、多要素認証（MFA）を設定要求できます（middlewareでAAL2未達なら認証フローへ誘導）。
また運営者（私自身）による顧客データへのアクセスは、運用方針として最小化しています ―― 常時アクセスはせず、必要時のみSupabaseの管理コンソール（MFA適用済み）から行う運用です。この部分は現時点ではシステムで強制する仕組みでなく運用ルールですが、今後システム的なアクセス制御へ強化していく方針です。

5. 最後に：手作業のExcel仕事を終わらせ、攻めのITインフラへ

現場の泥臭い運用（アカウント管理やデプロイの事実）をシステムに落とし込み、ITGC/NIST基準にマッピングし、最終的に「事業リスクと売上ROI」という経営（CFO）の言語へ垂直に翻訳して届ける。

このパイプライン（Python/reportlabによる経営PDF自動生成、Claude APIによる文章翻訳）が回ることで、ITGC対応はコーポレートITだけの孤独な事務作業から、「経営層からセキュリティ予算を勝ち取り、上場審査を通すための攻めの武器」へと昇華します。

長年、現場の手作業と予算の壁、監査法人との板挟みに、のたうち回ってきた私だからこそ、このプロダクトの構造と思想には自信を持っています。

「今回はITGCの自動化を Next.js × Supabase(RLS) というモダンスタックで解くアプローチをとりましたが、『うちではこうやって手作業をコードで破壊した』『CxO向けのROI翻訳ならこのLLMプロンプトの方が精度が出る』といった、現役のインフラエンジニアやコーポレートITの皆様からのご意見・マサカリ・壁打ちも大歓迎です。ぜひコメント欄などで教えてください！」

1ヶ月の無料トライアル（限定5社）の受付を開始しています

正式リリースを記念し、上場準備（IPO）のカウントダウンが始まっている成長企業の皆様や関心興味がある企業様へ、「1ヶ月の無料トライアル（限定5社）」の募集を開始しております。

今回ご紹介した「20問の自動マッピング」「証跡ポインタの非対称管理」、そしてCxOが納得する「経営サマリーPDF」の出力ができる、スタンダード機能をそのままに1ヶ月間無償でご体験いただけます（推移グラフは複数回の診断で線になるため、トライアルでは最初の一点まで）。試用期間の終了後にご契約へ進まない場合も、勝手に課金されることはありません。

高額なコンサル費用を払い、現場に重いExcelの二重管理を強いる時代は、もう終わりにしましょう。ご興味のある情シス責任者、インフラ・セキュリティエンジニア、管理部長などの皆様からのアクセスをお待ちしています。

▼ 無料トライアルの詳細・プロダクトの全貌はこちら
https://www.securoi.com/

（起業への想いや、ITGC/IT統制を経営言語に翻訳する思想的背景は、note第1弾もあわせてご覧ください）
https://note.com/securoi/n/na58ef8316430