情シス審査を通すために実装したこと

情シス審査は、結局どこを見ているのか？

「便利かどうか」ではなく「事故が起きたとき、誰が何をしたか説明できるか」を見ている。審査項目はすべてこの一点に還元できる。

生成AIツールの導入相談で「情シスに止められた」という話を聞くとき、現場側は「保守的だから」と受け取っていることが多くあります。しかし審査シートを実際に読むと、ほとんどの項目は好みの問題ではありません。事故が起きたときに社内で説明責任を果たせるかどうか、その一点を機械的に確認しているだけです。

そして、その説明責任は「うちのツールは安全です」という主張では果たせません。必要なのは、誰がいつ何をしたかを事後に取り出せること、問題が起きたときに止められること、消してくださいと言われたときに消せることです。IPAの「中小企業の情報セキュリティ対策ガイドライン」は2026年3月に第4.0版が公開され、経営者が認識すべき指針と実務担当者の手順を分けて整理していますが、そこで扱われる対策も突き詰めれば同じ構造をしています（IPA公式ページ・2026年8月確認）。

審査項目を、「なぜ見られるのか」と「無いと何が起きるか」で並べ直すと次のようになります。

認証・セッション・総当たり対策をどう作ったか

認証はワークスペースID＋アクセスコード、セッションはHMAC署名付き8時間クッキー、総当たりは失敗回数の上限で塞ぐ。3点セットで一組になる。

この3項目は独立して見えて、実際には一組です。認証を強くしてもセッションが盗めるなら意味がなく、両方を固めても総当たりが自由なら認証強度の設定は実質的に無効になります。自社プロダクトでは次の構造にしました。

認証：アクセスコードのハッシュは環境変数ではなくシークレットに置く

管理画面へのログインは、ワークスペースIDと強度のあるアクセスコードの組で行います。重要なのは保存の仕方です。アクセスコードそのものはどこにも保存せず、SHA-256ハッシュだけをCloudflare Workerのシークレットに格納しています。Cloudflareの公式ドキュメントでは、シークレットは暗号化されて保存され、定義後はダッシュボードでもWrangler CLIでも値を再表示できないと明記されています（Cloudflare Workers docs: Secrets・2026年8月確認）。運用者本人でも後から平文を読み出せない、という性質が審査の説明では効きます。

照合はハッシュ同士の定数時間比較で行っています。文字列を素朴に比較すると、一致する文字数によって応答時間がわずかに変わり、そこから正解を推定される余地が残るためです。

セッション：属性は3つとも必要で、それぞれ防ぐ相手が違う

ログイン後に発行するクッキーは、実際には次の一行です。

Set-Cookie: <セッションクッキー名>=<HMAC署名付きペイロード>;
  Path=/; HttpOnly; Secure; SameSite=Lax; Max-Age=28800

セッションクッキーの実際の属性。値はHMAC署名付きで、有効期限は8時間（28,800秒）。

3つの属性はそれぞれ別の攻撃を塞ぎます。OWASPのSession Management Cheat Sheetでは、HttpOnlyはJavaScriptからクッキーを読めなくすることでXSS経由のセッションID窃取を防ぐ「必須」の措置、SecureはHTTPS接続でのみ送信させることで中間者攻撃による漏洩を防ぐ「必須」の措置、SameSiteはクロスサイトのリクエストで送信させないことでCSRFを緩和する措置と整理されています（OWASP Session Management Cheat Sheet・2026年8月確認）。審査で「クッキーの属性は」と聞かれたときに、3つを並べて答えられるかどうかで印象が変わります。

有効期限は8時間に固定しました。業務時間を1回のログインで通せて、翌朝には切れている長さです。加えて署名の中身にも有効期限を持たせ、クッキー側の期限だけを書き換えても通らないようにしています。

総当たり：検証の「前」に枠を予約する

ログイン失敗のスロットリングは、R2に置いたカウンタで実装しています。キーは日付・接続元IP・ログイン先の識別子（ワークスペースIDまたはメールアドレス）を混ぜたハッシュにし、1日あたりの失敗回数が上限を超えたら、401ではなく429を返します。しきい値そのものは運用側の設定値なので、ここでは触れません。

キー: 日付・接続元IP・ログイン先の識別子から導出したハッシュ（1日単位で集約）
上限超過時: 429 Too Many Requests
成功時: カウンタをクリア

実装で一つ効いたのは、カウンタを増やす順番です。「認証を検証してから、失敗ならカウンタを増やす」という自然な順序だと、同時に大量のリクエストが来たとき全員がカウンタ0を観測して検証処理まで到達します。そこで、検証の前に枠を予約し、成功したときにクリアする順序へ変えました。OWASPのAuthentication Cheat Sheetでも、失敗カウンタをIPだけでなくアカウント自体に紐付けるべきだと整理されています（OWASP Authentication Cheat Sheet・2026年8月確認）。ここではIPと対象の両方をキーに混ぜることで、片方だけに寄せない形にしています。

テナント分離と権限——「隣の会社のデータが見えない」の作り方

すべてのデータにワークスペースIDを持たせ、一致しないアクセスは403ではなく404を返す。存在の有無すら答えない。

テナント分離は、審査で最も具体的に聞かれる項目です。「他社のデータは見えません」という回答は情報量がゼロなので、構造で答える必要があります。自社プロダクトでは、調査データ（study）が必ずワークスペースIDを持ち、管理操作には一致する署名済みワークスペースセッションを要求しています。

設計上のポイントは、一致しなかったときの応答です。403（権限がない）を返すと「そのIDのデータは存在する」という情報を渡してしまうため、404（見つからない）を返しています。範囲外のワークスペースからは、他社のデータは存在しないのと区別がつきません。

権限は、オーナー・メンバー・閲覧者の3つに分けました。閲覧者は編集操作ができず、操作ログの閲覧と調査の削除はオーナーだけに限定しています。ここは正直に書いておくと、これはRBACではありません。3段階が固定されているだけで、「この機能だけ許可する」といった組み替えはできません。細かい権限設計が要件に入る規模の企業には、現時点では足りない構造です。

3段階の固定ロール。役割の追加や、機能単位での権限の組み替えには対応していない。

メンバーの追加は招待リンクで行い、リンクに含まれるトークンはハッシュ化して保存、有効期限は既定で72時間としています。招待リンクが後から流出しても、期限切れ後は使えません。アカウントの識別子はメールアドレスのSHA-256ハッシュで、メンバー一覧や操作ログにはマスクした表示用の文字列だけを出しています。

監査ログ——審査で必ず聞かれ、後付けが一番つらい

認証と業務操作を1イベント1ファイルでオブジェクトストレージに追記し、オーナーだけが期間を指定して読み出せるようにした。

ここが本題です。監査ログは、審査で必ず聞かれる項目でありながら、実装の優先度を最も落とされやすい機能でもあります。理由は明確で、ユーザーが見て喜ぶ画面ではないからです。しかし前述のとおり、これだけは過去に遡って作れません。

自社プロダクトでは、認証イベントと業務イベントを同じ仕組みで記録しています。保存先はR2で、テナント・日付・発生時刻の順に絞り込める階層をキーに持たせ、1イベントを1ファイルとして書き出しています。

1イベント1ファイルにしたのは、追記のたびに既存ファイルを読み書きする構造にすると、同時書き込みでイベントが消える事故が起きるためです。ファイル名の先頭にミリ秒のエポック時刻を置くことで、キーの文字列を降順に並べるだけで新しい順になります。Cloudflare R2は保存時にAES-256で自動的に暗号化され、設定は不要だと公式ドキュメントに明記されています（Cloudflare R2 docs: Data security・2026年8月確認）。

現在記録しているのは16種類のイベントです。ログインの成功、パスワード変更、招待の発行と受諾、メンバーの停止、調査の公開と削除、レポートの生成、ワークスペース名やロゴの変更などが含まれます。1件のレコードは次の形をしています。

図：値はサンプルです。実行者名は、ワークスペースに所属するアカウントを照合したときだけ表示されます。

閲覧APIはオーナー限定で、期間は最大90日、件数は最大500件に制限しています。無制限にすると、1回の呼び出しでストレージを大量に走査する経路になるためです。

実装で一つ決め事をしたのは、ログの書き込みに失敗したとき、認証自体は失敗させないという点です。監査ログは補助的な記録であり、その書き込み失敗でログインが落ちると、可用性の問題を自分で作り込むことになります。ただしこの判断は「稀にログが欠ける可能性がある」ことと引き換えなので、審査の場では正直に説明する必要があります。

データ削除——「消してください」に答えられるか

実データを本当に消し、消したという事実だけを別の場所に恒久保存する。削除と証跡は必ず分ける。

削除機能の難しさは、「消す」と「消した記録を残す」が矛盾して見えるところにあります。すべてを消すと削除した証明ができず、証明のために残しすぎると削除になりません。自社プロダクトでは、実データと削除証跡を別の場所に分けることで解決しました。

削除の実体は、調査本体・回答個票・音声ファイル・生成済みレポート・読み上げ音声をストレージのプレフィックス単位でまとめて消し、ワークスペースの索引からも除去する処理です。そのうえで、次の内容だけを別のプレフィックスに恒久保存します。

• いつ・誰が消したか：削除日時と実行者のアカウント識別子。
• 何を消したか：調査ID・調査名・対象となった回答セッション数・削除したオブジェクト数。
• 本文は残さない：回答内容・音声・レポート本文は証跡側にも一切コピーしない。

誤操作の対策として、削除には調査タイトルの完全一致入力を必須にしています。確認ダイアログのボタンを押すだけの導線にすると、リストの隣を消す事故が必ず起きます。加えて、削除はオーナーのみが実行でき、実行結果は監査ログにも記録されます。

審査で問われるのは、たいてい削除の有無ではなく削除の証明です。「消しました」と口頭で答えるのと、日時・実行者・削除件数が入ったレコードを提示するのとでは、同じ機能でも通り方が変わります。

パスワード変更——アカウントライフサイクルの最小単位

本人が現在のパスワードを入力して変更でき、変更と同時に他端末のセッションが無効になる。ここまでが最小構成。

パスワード変更は地味な機能ですが、これが無いと「招待時に発行したパスワードを、利用者が一生使い続ける」状態になります。審査で見られるのはこの一点です。

実装では、本人のログイン状態を必須とし、現在のパスワードとの照合を経てから新しいパスワードを受け付けます。保存はソルト付きのPBKDF2です。変更が成功すると、アカウントのバージョン番号を1つ進めて他端末の既存セッションをすべて無効化し、本人にだけ新しいセッションを再発行します。パスワードを変えたのに他の端末でログインしたままなら、変更の意味が半減するためです。

ここで基準との差を正直に書いておきます。2025年7月に確定したNIST SP 800-63B-4では、パスワードだけで認証する場合は15文字以上を要求すること（多要素認証の一要素として使う場合は8文字以上）、ソルト付きのパスワードハッシュ方式で保存すること、そして定期的なパスワード変更を強制してはならないことが規定されています（NIST SP 800-63B-4・2026年8月確認）。この15文字という水準は2025年に引き上げられたもので、それ以前の「8文字以上」を前提に組んだSaaSは、単一要素での運用だと現行基準を下回ります。審査する側は、最小文字数を聞くよりも「どの版のどの基準に照らしているか」を聞いたほうが実態が出ます。

生成AIツール特有の3つの論点

学習利用の有無、入力・出力の保存先、ログの粒度。通常のSaaS審査には無い項目で、ここで止まるケースが最も多い。

ここまでの項目は、生成AIかどうかに関係なく共通です。生成AIツール特有の論点は別に3つあります。

1. 入力データが学習に使われるか

最初に聞かれる項目です。答えるべきなのは自社の方針だけではありません。推論に外部のモデルAPIを使っている場合、その提供事業者の規約まで含めて答える必要があります。自社が保存していなくても、送信している時点で第三者への提供という論点が立ちます。審査に出す資料には、自社の保存ポリシーと、推論の委託先および委託先での学習利用の扱いを分けて書くのが確実です。

2. 音声・テキストがどこに保存されるか

音声を扱うツールでは、テキストより先に音声の保存先を聞かれます。生の音声は本人性の高いデータであり、テキスト化した後も原本を保持しているかどうかで扱いが変わるためです。自社プロダクトでは、音声・文字起こし・生成レポートをすべて同じオブジェクトストレージに置き、調査単位で一括削除できる構造にしています。保存場所が複数に散っていると、削除請求のたびに「あそこにも残っていた」が発生します。

3. ログの粒度——記録しすぎない設計

これは他の2つと逆向きの論点です。操作ログは詳しいほどよいと思われがちですが、生成AIツールでは記録しすぎることが別のリスクになります。プロンプトの全文をログに残せば、そのログ自体が機微情報の塊になるためです。自社では、監査ログに残すのは操作の種類・実行者・対象・件数までとし、回答本文やプロンプト全文は監査ログ側にコピーしない方針にしています。

関連して、社内向けの調査では回答の匿名性そのものが設計対象になります。自社プロダクトでは、部署別の集計で人数が5人未満のグループは分布を出さずにまとめる処理を入れています。匿名と表示しながら実質的に個人が特定できる状態は、回答者への約束を破ることになるためです。総務省の「クラウドサービス利用・提供における適切な設定のためのガイドライン」も、利用者と提供者の責任分界を互いに理解した上で設定不備を防ぐことを基本方針としています（総務省報道資料・2022年10月31日公表・2026年8月確認）。表示と実処理を一致させることは、その責任分界の前提になります。

まだ実装していないもの——SSO・SCIM・RBAC・パスワード回復

4つとも未実装。必要になる順番は、利用範囲が部門から全社へ広がる順番と一致する。

ここまで書いてきた7項目は、部門単位での法人利用に耐える水準です。全社導入の水準ではありません。未実装の4つと、それぞれが必須要件に変わるタイミングを整理します。

SSOについて補足すると、SAML 2.0はOASISの標準（2005年承認）、SCIMはIETFのRFC 7644として標準化されています。どちらも仕様が公開された枯れた技術であり、「実装が難しいから入れていない」わけではありません。入れていない理由は、部門単位の利用では手動のアカウント管理で足りており、実装コストを他の項目に振り向けたほうが導入の障害を減らせると判断したからです。

この判断が変わるのは、利用者が全社に広がるときです。数十名までは手動の発行・停止で回りますが、入退社が毎月発生する規模になると、停止漏れが最大のリスクになります。そこがSSOとSCIMの実装ラインです。

実装していない機能については、「画面に導線が無い」で済ませず、利用可能な認証方式をシステム側から一覧で答えられる状態にしておくことを勧めます。審査資料と実装の食い違いは、たいてい「資料には書いたが実装が追いついていない」方向で起きます。機械が答える形にしておけば、その食い違いが起きません。

審査チェックリスト——両側で使える9項目

審査する側は質問として、される側は事前の自己点検として使う。「はい」ではなく構造で答えられるかを見る。

最後に、ここまでの内容を審査の質問形式にまとめます。ツールを選定する側は、この9問をベンダーに投げれば実装の水準が判別できます。ツールを提供する側は、この9問に構造で答えられるかを事前に点検してください。

審査を通す作業は、能力を大きく見せる作業ではありません。境界を正確に書き、境界の内側については構造で答えられる状態を作る作業です。生成AIツールの導入検討でこの記事の項目に詰まった場合は、Cloudflare Workersの本番運用で踏んだ罠5つやClaude Codeの法人導入もあわせて参考にしてください。

よくある質問