AIが生成した変更は自動テストに合格した。ところが、「誰が本番公開を承認したか」と聞くと答えが止まる。生成が速くなるほど、曖昧な責任境界も速く次の工程へ運ばれます。
業務データへ触れる権限、変更を承認する役割、検証の合格条件、本番へ移す手順は、組織が明文化します。AIの性能評価とは別に、開発工程を五つの領域で確認します。
- 誰が何を読み、変え、本番へ出せるか
- 生成とは別の役割が何を検証するか
- 変更理由、差分、承認、検証結果をどう残すか
- どの環境へ、誰の承認でデプロイするか
- 入力、処理、保存、外部送信、削除を誰が管理するか
五つの領域を、AIで業務システムを生成、変更、公開する際の確認面として使います。
NIST SSDFは、安全な開発慣行を各SDLCへ組み込む枠組みを示しています。AISIの実務マニュアルは、監査、是正、変更管理を継続して運用する考え方を扱います。両資料のうち、業務システムの開発工程へ接続する部分を参照しています。[1][2]
五つの確認領域
例として、受注金額に応じた割引ルールをAIで変更する場面を考えます。コード生成と単体テストが終わっても、本番データを読める人、割引条件を承認する人、既存注文への影響を確認する人、公開を止める条件が決まっていなければ、変更を本番へ出す準備は終わっていません。
閲覧から公開までの権限境界を引く
最初に、各役割へ何を許すかを決めます。この例では、開発用の匿名化データを読む権限、割引ルールを変更する権限、本番へ反映する権限を別の役割へ割り当てます。一つの強い権限へまとめると、生成、承認、公開の責任を記録から区別できません。
| 権限 | 導入前に決めること | 残す記録 |
|---|---|---|
| 読む | 参照できる業務資料、ソース、データ、秘密情報の範囲 | 誰が、どの目的で、どこへアクセスしたか |
| 変える | 変更できる仕様、コード、設定と、承認が必要な境界 | 変更要求、差分、実行者、承認者 |
| 出す | 検証結果を誰が確認し、どの環境へ移せるか | 検証結果、承認、デプロイ先、実施時刻 |
Formula AIは、認証と権限を設計するためにSAML、OIDC、MFA、RBACを用意しています。導入時には、利用者の役割ごとに閲覧、変更、承認、公開の範囲を決めます。[3]
生成前に検証の合格条件を固定する
生成した主体が、自分の出力を書き換えながら合格判定まで行うと、検出した不一致と修正した内容を分けにくくなります。Formula AIでは作る役割と確認する役割を分け、検証役は読み取り専用で動きます。[4]
割引ルールの変更なら、境界金額の前後、既存注文、権限のない利用者、下流の請求データを確認対象に含めます。「正常に動いた」ではなく、入力、期待結果、許容しない結果を生成前に固定します。確認できない項目は未確認として残し、公開責任者が影響を判断します。
変更理由から検証結果までを一つの記録でつなぐ
Formula AIは、APIリクエストログとデータ変更ログを二つの軸として扱い、変更前後を確認できる構成です。[3]
割引率が変わった事実に、変更要求、承認者、対象となる仕様ID、再検証結果への参照を加えます。これで、操作の事実から「なぜ許可された変更なのか」まで戻れる統制記録になります。
AISIの実務マニュアルも、内部監査を是正や変更管理とつないで継続運用する流れを示しています。ログを保存することと、ログから是正へ進めることは別です。[2]
公開を止める条件を先に決める
デプロイ先、ネットワーク境界、秘密情報の保管、承認経路、ロールバック方法を公開手順に含めます。この例では、既存注文の再計算結果が確認できない、請求連携の検証が未完了、元の割引ルールへ戻す手順がない場合に公開を止めます。
Formula AIでは、取込情報を構築に必要な範囲へ限定し、必要時のアクセスに承認、最小権限、期限、MFA、操作ログを置きます。保管地域は導入時の個別確認項目とし、契約条件は契約書やDPAと照合します。[3]
データ取扱いは、入力する資料、処理する環境、保存する記録、外部へ送る範囲、削除の責任者までを一つの流れとして確認します。利用するAIモデル名は、その確認項目の一つです。
五つの領域を一枚で確認する
導入前の会議では、機能の有無だけでなく、確認できる証拠と、未決時に判断する担当者を一枚にまとめます。
| 確認領域 | 確認する問い | 確認する証拠 | 未決の場合 |
|---|---|---|---|
| 権限 | 読む、変える、出す権限が役割ごとに分かれているか | 権限一覧、接続設定、承認記録 | 権限設定の責任者と期限を決める |
| 独立検証 | 生成とは別の役割が、変更せずに合否を確認できるか | 検証項目、合格条件、検証結果 | 未確認として残し、公開可否への影響を責任者が判断する |
| 変更記録 | 操作、差分、理由、承認、検証結果をたどれるか | 変更要求、差分、承認、再検証記録 | 不足する記録と保存責任者を決める |
| デプロイ境界 | 環境ごとの権限、公開手順、戻し方が決まっているか | 環境別権限、公開手順、ロールバック手順 | 公開を承認する人と復旧条件を決める |
| データ取扱い | 入力、処理、保存、外部送信、削除の範囲が決まっているか | データフロー、保存条件、削除手順 | 契約と運用の確認責任者を決める |
Formula AIの統制構造
Formula AIは、仕様、実装、検証の責務を工程として分け、読み取り専用の検証ゲートを置きます。認証とRBACは、利用者と役割の境界を設定する機能です。
Formula AIの工程をこの例へ当てはめると、割引ルールの仕様IDと変更要求を生成の入力にし、固定した合格条件を読み取り専用の検証ゲートで確認します。変更前後の記録は監査ログと証跡に結び、未確認項目は公開判断へ渡します。
具体的な権限、デプロイ環境、データ取扱い、契約条件は導入環境ごとに確認します。
Formula AIの製品構造と統制とセキュリティの公開情報で、現在掲載している範囲を確認できます。
よくある質問
- 人は最低限どこを確認すべきですか
- 業務ルールと例外条件、権限とデータ境界、外部連携を含む下流影響、公開とロールバックの条件を確認します。機械検証の未確認項目も人が読み、公開を止めるか、追加確認へ戻すかを決めます。
- 監査ログがあれば統制は十分ですか
- 操作と差分を記録できても、変更理由、承認、検証結果へ戻れなければ、許可された変更かを判断できません。ログの有無と、判断へ使える記録かを分けて確認します。
- PoCから本番へ進む前に何を追加しますか
- 本番データへ触れる権限、変更を承認する役割、合格条件、監査記録、公開停止条件、ロールバック手順を追加します。PoCで確認した機能を、そのまま本番権限へ広げないようにします。
一つの変更を五つの領域で止めてみる
次に予定している変更を一件選び、権限、独立検証、変更記録、デプロイ境界、データ取扱いの五行へ、証拠と担当者を書きます。空欄が残った領域には、決める人と期限を記します。
生成を始める前にこの一枚を作ると、AI導入を開発速度だけでなく、公開判断まで含めて検討できます。
変更の前提となる現行仕様が定まっていない場合は、先に仕様書と実装が食い違うときの現行システム調査で、文書、実装、運用の差分を整理します。