- 情シス審査で問われるのは「機能があるか」ではなく「顧客が自分の画面から確認・実行できるか」。監査ログ・データ削除・パスワード変更は、この基準で作り直すべき典型項目だった。
- 実装の芯は既定値の設計。公開サインアップは既定OFFで招待制のみ、認証はfail closed、新しいAIベンダーへの連携も既定OFF。安全側に倒したうえで、契約・同意の更新後に個別にONへ切り替える。
- 「これをやれば審査に通る」という保証はない。審査基準は企業ごとに違うため、本記事は実際に問われた項目と実装の一次情報として、自社の設計判断に落とし込むための材料として使ってほしい。
AI SaaSの情シス審査で、実際に何を聞かれるのか？
データの保存先・処理者・保持期間・削除・アクセス制御・監査証跡の6つが定番の質問群で、多くは「機能があるか」ではなく「顧客側で確認・実行できるか」まで踏み込んで聞かれる。
AI SaaSを情シスに持ち込むと、審査シートには「データの保存先はどこか」「データを処理する第三者（ベンダー）は誰か」「保持期間はどれくらいか」「削除はどう行うか」「誰がアクセスできるか」「操作の記録は残るか」といった質問が並ぶ。言い回しは企業ごとに違うが、突き詰めると保存先・処理者・保持期間・削除・アクセス制御・監査証跡という6つの軸に収束することが多い。
この6軸自体は目新しいものではなく、ISMS（ISO/IEC 27001）やSOC2といった外部認証の考え方にも共通して現れる論点だ。ただし本記事で扱う実装は、特定の認証取得を前提にしたものではない。筆者（TechWorker）もこれから題材にするAI SaaS「CoeSignal」も、ISMSやSOC2などの外部認証を取得しているわけではなく、以下は実際の法人審査で個別に問われた項目に、実装で答えてきた一次情報として読んでほしい。
題材にするのは、筆者が運用するCloudflare Workers上のAI SaaS「CoeSignal」の本番実装だ。抽象的な「べき論」ではなく、実際に組んだ環境変数・データ設計・画面機能を見ていく。
「機能がある」と「顧客が自分で確認・実行できる」は、なぜ違うのか？
監査ログ・データ削除・パスワード変更は多くのSaaSに機能として存在するが、法人審査で問われるのは顧客自身が画面から確認・実行できるかどうか。開発側の内部運用でカバーしているだけでは審査を通らない。
CoeSignalが実際の法人審査で指摘されたのは、この「機能はあるが顧客は使えない」という状態だった。具体的には次の3点が穴として挙がった。
監査ログは記録されていたが、顧客が見る画面がなかった。何かあれば開発チームがデータベースを直接確認して回答する運用で、記録自体は存在していても、顧客からは「無い」のと見分けがつかない。データ削除は開発チームへの依頼ベースで、実行まで数日かかっていた。削除の処理そのものはコードとして存在したが、顧客が自分のタイミングで押せるボタンがなかった。パスワードは初期値のまま運用され、変更は運用者への申請フローだった。顧客が自分の意思で今すぐ変える手段がなかった。
3点に共通するのは、「バックエンドではできる」と「顧客が自分でできる」を混同していたこと。審査する側が確認したいのは前者ではなく後者であり、この区別に気づいてから実装の優先順位が変わった。
データ削除は開発チームへの依頼ベース。実行まで数日
パスワードは初期値のまま。変更は運用者への申請フロー
「データを削除する」ボタンを設置。確認ダイアログを経て顧客が即時実行できる
パスワード変更画面を追加。顧客が自分のタイミングで変更できる
図：法人審査で指摘された3点の、指摘前と実装後の対比。コードとしての機能追加ではなく、顧客が触れる画面の追加が要点だった。
実際に何を実装したか、その理由は？
招待制サインアップ・fail closedの認証・アクセスコードのハッシュ化・監査ログ閲覧/削除/パスワード変更・ベンダー連携の既定OFF・同意のバージョン管理・緊急停止スイッチ・秘密情報の外出しを実装した。審査の観点に対応づけると下表になる。
ここまでの2点——審査で何を聞かれるか、機能と実行可能性の違い——を踏まえ、CoeSignalの本番環境で実際に組んだ実装を、審査の観点に対応づけて整理する。番号は実装した順番ではなく、審査でよく質問される順に近い。
| 実装したこと | 具体（設計・環境変数） | 審査で問われる観点 | なぜこの設計にしたか |
|---|---|---|---|
| 公開サインアップの無効化＋招待制 | PUBLIC_SIGNUP_ENABLED="0" / INVITE_SIGNUP_ENABLED="1"。管理者またはワークスペース所有者が1回限り・期限付きの招待リンクを発行 | アクセス制御・入口管理 | 「誰でも登録できる」入口をなくし、アカウントの発生源を常に特定の人物まで遡れるようにする |
| fail closedの認証設計 | 認証設定が読み込めない・不整合が起きた場合は、通すのではなく拒否する | 認証の堅牢性・障害時の挙動 | 設定ミスや障害の瞬間に「開いてしまう」設計は事故に気づきにくい。閉じる方向に倒して被害を抑える |
| アクセスコードの非平文保存 | access_code_sha256としてSHA-256ハッシュのみ保持し、原文は保存しない | 認証情報の保管 | データベースが漏れても、アクセスコードの原文を復元できない状態にする |
| 監査ログの閲覧機能 | 顧客の管理画面に、操作ログを確認できる画面を実装 | 監査証跡・アカウンタビリティ | 記録されているだけでは審査上「無い」のと同じ。顧客自身が確認できることが要件 |
| データ削除機能 | 顧客がセルフサービスで自分のデータを削除できるボタンを実装 | 削除権・データ主体の権利 | 依頼してから数日ではなく、顧客の意思で即時に完結させる |
| パスワード変更機能 | 顧客が自分の画面からパスワードを変更できる機能を実装 | アカウント管理・認証情報のライフサイクル | 初期パスワードを固定運用にせず、顧客側で更新の主導権を持てるようにする |
| 新規処理者への連携を既定OFF | ALLOW_OPENAI_TRANSCRIPTION_FALLBACK ALLOW_OPENAI_RUNTIME_TTS ALLOW_OPENAI_SCREEN_OBSERVATION 等を既定"0"に設定 | データの処理者・第三者提供 | 契約・同意文の更新より先に、データが新しいベンダーへ渡る事態を防ぐ |
| 同意のバージョン管理 | 同意文にversionを持たせ、処理者（Anthropic・OpenAIなど）を明示。バージョン5以降で特定の処理者への提供に明示同意、という形で追跡 | 同意の追跡可能性 | 「いつ、どの処理者への提供に同意を得たか」を後から契約と突き合わせて説明できる |
| 緊急停止スイッチ | 例：TRANSCRIPT_POLISH="0"のように、特定のAI処理を止める環境変数を用意 | インシデント対応・障害対応の速度 | 問題が見つかったAI処理を、コード変更なしでdeployだけで即座に止められる |
| 秘密情報をリポジトリに置かない | APIキー等はwrangler secret putで登録し、暗号化された状態でCloudflare側に保存。設定ファイルにはsecret名の宣言だけを残す | シークレット管理 | 設定ファイルをリポジトリにコミットしても、値そのものは漏れない |
このうちアクセス制御の考え方は、社内ツール側の話になるがCloudflare Accessによるゼロトラスト構成とも共通する。招待制にしても、その招待リンクの発行画面自体を誰でも開けてしまえば意味がない。入口を絞る設計は、社内向け・顧客向けを問わず同じ発想で組む。
図：本番環境変数の設計方針のイメージ。新しい連携機能は既定OFFで実装し、契約・同意の更新後に値を変更してONにする。秘密情報の扱い方の基本はシークレット管理の基本で扱っている。
共通しているのは、初期状態を安全側に倒し、範囲を広げる操作は後から明示的に行うという設計思想。壊れたときに開くのではなく閉じる。契約も同意もない状態では、新しいベンダーにデータを渡さない。個々の機能の巧拙より、この既定値の設計思想そのものが審査で繰り返し評価されている。
新しいAIベンダーを追加するときは、どういう手順を踏むか？
既定OFFの環境変数として実装し、契約・同意文を更新し、顧客に通知したうえで、環境変数をONにしてdeployする。この順番を逆にしない。
新しいAIベンダー（処理者）を機能として追加したくなる場面は珍しくない。文字起こしのフォールバック先を増やす、音声合成のランタイムを切り替える、画面の内容を解析する——といった機能追加のたびに、CoeSignalでは次の順番を固定している。
| フェーズ | やること | 出口条件 |
|---|---|---|
| 1. 実装 | 新しい処理者への連携をコードとして実装するが、環境変数は既定「0」のまま。コードはマージしてよいが、フラグがオフである限り実際には呼ばれない | コードはデプロイ済みだが、機能はまだ誰にも作用していない |
| 2. 契約・同意文の更新 | 利用規約・プライバシーポリシー等の同意文をバージョンアップし、追加される処理者の名称と、渡るデータの範囲を明示する | 新しい処理者への提供が、文面として説明できる状態になっている |
| 3. 顧客への通知 | 何が変わるか、どの処理者にどのデータが渡るかを顧客に通知し、必要な同意を取得する | 通知・同意の記録が残っている |
| 4. 有効化 | 環境変数をONにしてdeployする。この時点で初めて実際にデータが渡り始める | 機能が有効化され、かつそこに至るまでの契約・同意・通知の記録がすべて揃っている |
ポイントは、コードのマージと機能の有効化を別の出来事として扱うこと。実装が終わっていても、フラグがオフである限り実害は発生しない。逆に言えば、環境変数をONにする最後の一手だけは、契約・同意文の更新が完了するまで誰も押せないようにしておく必要がある。
実装は先に進めていい。データが実際に動き出すのは、契約と同意が追いついてからだ。
導入する側は、審査で何を確認すればよいか？
「機能の有無」ではなく「顧客側で確認・実行できるか」「既定値が安全側か」「変更時に通知される仕組みがあるか」の3点で聞くと、実質的な審査になる。
ここまでは作る側の視点だった。導入審査をする情シス側に立つと、聞くべき質問は少し変わる。「機能があるか」で終わらせず、次の一段まで確認する。
| 確認項目 | 聞き方（質問例） | 一段掘り下げる一言 |
|---|---|---|
| データの保存先・処理者 | データはどこに保存され、処理する第三者（ベンダー）は誰か | 今後ベンダーが増える予定はあるか。増えるときはどう通知されるか |
| 保持期間・削除 | データはどれくらいの期間保持されるか | 削除は自分たちの画面から今すぐ実行できるか、それとも依頼が必要か |
| アクセス制御・入口 | アカウントの発行は公開登録か、招待制か | 退職者・異動者のアクセスは、誰が、どういう手順で失効させるか |
| 認証の安全側設計 | 認証設定に不備があったとき、通すのか止めるのか（fail open／fail closed） | パスワードやアクセスコードは平文で保存されていないか |
| 監査証跡 | 操作ログは記録されているか | そのログは自分たちの画面で見られるか、ベンダーへの問い合わせが必要か |
| インシデント対応 | 特定の機能に問題が起きたとき、どのくらいの速さで止められるか | 止める操作は誰が行うか。コード修正が要るか、設定変更だけで済むか |
この記事の実装をすべて満たしても、審査に通る保証はない。審査基準は企業によって、また業界によって異なり、業種特有の要件（特定の認証取得や、より厳格なデータ所在地の指定など）が加わることもある。ここで示したのは「実際に何を問われ、何を実装したか」という一次情報であり、自社の設計判断に落とし込むための材料として使ってほしい。
よくある質問
機能の存在は前提に過ぎず、法人審査で問われるのは顧客自身が画面から確認・実行できるかどうかだからです。エンジニアへの依頼やデータベースの手動確認で対応できる状態は、顧客からは「無い」のと見分けがつきません。
上がりますが、それが狙いの一部です。管理者またはワークスペース所有者が発行する1回限り・期限付きの招待リンクに限定することで、「誰が入れるか」を常に説明できる状態を保てます。利便性より、入口を絞ることを優先する場面での設計です。
開発を先に進めて構いません。ただし有効化は契約・同意文の更新のあとにします。実装は既定OFFの環境変数として作り、コードのマージと機能の有効化を別の出来事として分離しておくと、この順番を事故なく守れます。
通るとは限りません。審査基準は企業や業界によって異なり、業種によっては本記事にない要件が追加で求められることもあります。本記事は「実際に何を問われ、何を実装したか」という一次情報の共有であり、審査通過を保証するものではありません。