- 公開日
AI生成コードを本番で使う前は、対象の版と環境を固定し、正常な入力だけでなく、不正入力、権限不足、依存先の失敗でも必要な動作を満たすかを確認します。重要な項目が未実行・未確認なら、本番適用を保留して追加試験へ回します。点検表に「はい」が多いことより、必要な条件が証拠と結び付いていることが判断の基準です。
このチェックリストは、入力を受け付けてデータを保存するAPIを例にします。AIが書いた部分だけを切り出さず、実際に組み込む依存、設定、呼び出し側、保存先との接続まで対象を定めます。説明用コードの断片が構文上正しくても、そのまま本番で使える根拠にはなりません。
この記事は、AI生成コードを本番環境へ出してよいかを判定し、その記録を残す段階を扱います。手元や検証環境で試しに使う段階の確認は「AIが書いたコードを使う前に確かめること」で扱います。
判定する版と四つの状態を揃える
最初に、Commitなどの変更識別子、対象環境、依存の版、設定、試験データ、試験日時を記録します。レビューしたコードと試験したコード、実際に展開する成果物が違えば、以前の結果をそのまま使えるとは限りません。どの差分へ判定したかを追えるようにします。
判定は、確認する命題ごとに次の四つを使います。「資料が存在するか」と「その資料から必要な動作が確認できるか」は別の命題です。
- はい：必要な資料・方法で照合し、命題に合うと確認できた
- いいえ：照合できた結果が、命題に合わなかった
- 未確認：必要な資料や実行結果が足りず、照合を完了できない
- 対象外：その確認が今回の機能や構成に関係しない
例えばテストコードが保存されていても、実行結果がなければ「対象版で試験が通ったか」は未確認です。不正入力を受理した記録があれば同じ命題はいいえになります。拒否の試験がないことを、拒否に失敗したという実測へ変えないようにします。
NIST SSDF v1.1は、開発環境、コードレビュー、実行試験と問題の記録を扱います。下の表はその考え方を用途へ当てはめた点検例で、NISTの認証票や一律の法的要件ではありません。実際には組織の開発基準や業務上の条件も合わせます。
架空の入力受付APIを点検する
例は、社内プロジェクトの作業依頼を登録する架空APIです。所属テナント内の許可されたプロジェクトへ、依頼名と詳細を保存します。呼び出し元は認証済みの利用者で、対象プロジェクトを操作できるかをサーバー側で確認する設計です。メール送信や決済処理は含めません。
説明用の入力は、project_idがP1、titleが「資料更新」、detailが「見出しを見直す」、request_keyがK1とします。テナントT1の利用者がT1内のP1へ登録できることが正常例です。同じ利用者が他テナントのP2を指定した場合は、保存しない期待になります。
以下の判定例では、正常入力の試験記録や不足した資料がある状態を仮定します。実際のAPI、コード、ログを調査した結果ではなく、試験も実行していません。「はい」は架空資料の条件が揃ったという例示であり、実製品の合格判定ではありません。
環境と依存を確認する
環境の違いは、コードの説明だけでは見えにくい問題を生みます。開発用の設定と本番用の設定、依存版、利用する権限、ネットワーク条件を比較し、どの差を試験で再現したかを確認します。未確認の差が重要な動作に影響する場合は保留します。
| 確認する命題 | 確認資料・方法 | 架空例の判定 | いいえ・未確認時の対応 |
|---|---|---|---|
| 対象版と環境が特定されているか | Commit、ランタイム版、設定一覧、試験記録を照合 | はい：模擬記録の識別が一致 | 版と環境を固定し記録を取り直す |
| 必要な依存が意図した配布元・版と対応するか | 依存一覧、ロックファイル、公式の配布情報を照合 | 未確認：新しい依存の由来が不足 | 導入を保留し由来と利用条件を審査 |
| 対象版で正常例を実行し、保存結果まで確認したか | 実行記録、応答、保存先の状態を照合 | はい：一件の模擬正常試験を仮定 | 実行または保存状態の確認を追加 |
| 説明で省略された処理が本番要件を満たすか | コードの省略箇所と本番要件を対応させる | 未確認：失敗処理の確認資料がない | 省略部分を実装し、対応する試験へ戻す |
依存の確認は、登録されていることだけで終えません。配布元、対象版、必要な間接依存、利用許諾や審査条件を確かめます。AIが提案した名前を、検索で見つかった似た名前へ置き換えて済ませないようにします。
正常試験も、成功応答だけでは保存が完了したかを確定できない構成があります。仕様上の成功条件が、受付なのか、保存完了なのか、後続処理の完了なのかを先に決めます。今回の例は保存までを確認対象とし、一件の正常入力が通ったことを全入力の保証には使いません。
入力と権限を確認する
OWASPのREST Security Cheat Sheetは、入力の型・長さ・範囲などの検証と、必要なエンドポイントごとの認可を説明しています。本人がログインできることと、そのプロジェクトへ登録できることは別です。入力が整ったJSONであることも、操作権限の根拠にはなりません。
| 確認する命題 | 確認資料・方法 | 架空例の判定 | いいえ・未確認時の対応 |
|---|---|---|---|
| 型・必須項目・長さ・値の範囲をサーバー側で検証するか | 入力仕様、検証コード、境界値と不正入力の試験を照合 | いいえ：模擬記録では長さ制限を超えたtitleが保存される | 検証を修正し、不正値と正当な境界値を再試験 |
| クライアントが送る主体情報を無条件に信用しないか | 認証情報から主体を確定する経路を確認 | 未確認：経路の証拠が不足 | 認証と入力の対応を確認する |
| 操作主体が対象プロジェクトを操作できるか確認するか | 認可設計、対象ごとの権限判定、他テナント入力の試験 | 未確認：P2を使う拒否試験がない | サーバー側認可と拒否時の保存状態を確認 |
| 許可された利用者の正常処理を維持するか | P1への正当入力を、修正後にも実行する | 未確認：入力検証修正後は再試験前 | 拒否の強化だけでなく正当処理を再確認 |
| 決済の認可と金額条件を確認する必要があるか | 機能一覧と外部接続を照合 | 対象外：このAPIは決済を行わない | 機能が追加されたら対象へ戻す |
対象外を選ぶ場合も、関係がない根拠を残します。「今回は見なかった」「難しいから後回し」は未確認です。APIに認可が必要な前提なのに、ログインできたことを理由に対象外へ変えることはできません。
入力検証の修正では、必要な値まで拒否していないかを見ます。日本語の依頼名、空欄が許される詳細、最大長の境界など、仕様で定めた正当な入力を残します。長さ制限の数値は、例やAIの推測から採用せず、業務と保存先の条件に合わせて決めます。
認可の不合格が分かった場合は、入力の見た目を変えて回避する修正ではなく、主体、テナント、対象資源、操作の対応へ戻ります。拒否した応答だけでなく、保存先に不正な登録が残っていないことも確認します。判定表示と実際の副作用を分けるためです。
失敗時の動作とログを確認する
正常入力に続いて、保存先の停止、応答の遅延、途中失敗、再送の扱いを点検します。エラーを返した後にも保存が完了している可能性がある構成では、「失敗応答だから未処理」と決め付けると二重登録を招きます。実際の仕様に沿って結果不明の状態と確認方法を設計します。
| 確認する命題 | 確認資料・方法 | 架空例の判定 | いいえ・未確認時の対応 |
|---|---|---|---|
| 保存先の失敗を成功として返さないか | 依存障害時の実行記録と応答を照合 | 未確認：正常例以外の記録がない | 隔離環境で失敗条件の試験を追加 |
| 部分保存がある場合の整合性を保つか | 保存単位、トランザクション、途中失敗後の状態を確認 | 未確認：保存後状態が不明 | 整合性の条件と回復手順を確認 |
| 結果不明時の照会と再送条件があるか | 要求識別子、重複防止の仕様、再送時の試験を照合 | 未確認：request_keyの扱いが文書だけ | 有効範囲と保存動作を試験し盲目的な再送を止める |
| エラー応答が内部情報を過剰に出さないか | 模擬エラーの応答本文を確認 | いいえ：模擬例では内部接続情報が含まれる | 利用者向け情報へ限定し再確認 |
| ログに必要な追跡情報を残し、秘密や入力全文を不用意に残さないか | ログ仕様、出力例、閲覧権限と保持条件を照合 | 未確認：通常ログしか確認していない | 異常時を含めて記録項目と扱いを確認 |
OWASPの同資料は、呼出スタックなどの技術的な詳細をクライアントへ返さないことと、ログインジェクションを防ぐためにログへ書く前のデータをサニタイズすることを挙げています。何をログから除くかは、同じOWASPのLogging Cheat Sheetが参考になり、アクセストークン、パスワード、接続文字列などは直接記録せず、除去やマスキングなどで扱うよう示しています。調査に必要な識別情報と残さない情報を分け、組織のログ方針と照らして記録項目を決めます。
今回のrequest_keyという名前だけでは、重複登録が防げるとは言えません。どの利用者・操作・期間で同じ要求とみなすか、内容が違う再送をどう扱うか、保存とキーの記録がどう対応するかを確かめます。応答がない場合に状態を確認できなければ、再送による影響を判断できるまで保留します。
ログに失敗の記録がないことも、失敗が起きていない証拠にはなりません。ログ出力経路が試験対象に含まれていたか、記録が欠けた場合に検知できるかを確認します。観測できない状態は、その範囲を未確認として扱います。
追加試験を計画するときは、試験担当者が操作できる環境、入力、保存先、失敗条件を先に決めます。本番の権限や実利用者のデータを使って、未確認の拒否処理を試す方法にはしません。外部へ作用しない試験用の対象を用意し、終了後に残るデータや設定の扱いまで確認します。検証のための操作にも、その環境で許可された範囲が必要です。
不合格と未確認を差し戻しへつなげる
この架空例では、入力検証とエラー情報の扱いにいいえがあり、依存、認可、失敗系にも未確認があります。正常例が一件通ったという仮定があっても、本番適用へ進む材料は揃っていません。必須条件に関わる不足を修正と追加試験へ回します。
差し戻すときは、「安全性を高める」だけでなく、対象版、満たしていない命題、根拠、期待する修正、再確認方法を渡します。入力の長さ制限なら、仕様で決めた境界と超過値を使い、正当な入力が通り、超過値が保存されないことを確認します。修正後は、影響する正常例も再確認します。
未確認の行では、必要な材料を特定します。認可なら対象別の判定経路と拒否時の保存結果、失敗系なら依存障害の試験記録、といった形です。資料を入手しただけで「はい」へ変えず、その資料が命題に答えているかを照合します。
修正でCommitや設定が変わったら、どの判定が引き続き有効かを見直します。依存を更新した場合は、関係する試験の結果を旧版のまま流用しません。影響しない根拠を説明できる確認は再利用できますが、更新された対象を未確認のまま通さないようにします。
確認票には担当者と次の確認日も添えます。未確認を記録しただけで放置すると、リリース直前に意味の違う資料で穴埋めされるおそれがあります。例えば認可の行はセキュリティ担当と実装担当、依存の行は依存審査の担当というように、必要な証拠を揃える役割を決めます。担当者の名前があること自体は合格ではなく、照合結果を得るための管理情報です。
判定の件数を平均して合格点にする方法は、この用途には向きません。権限不足で他テナントへ書き込める問題を、別の十項目の合格で相殺することはできないためです。必須条件と任意改善を先に分け、停止が必要な項目を責任者と定めます。
本番適用の判断に残すもの
未確認のまま例外を認める組織の手順がある場合も、未確認を「はい」に書き換えません。例外を判断した人、許容する影響、期限、代替策を別に残し、本来の検証結果と区別します。
最終記録には、適用する成果物、確認した環境、結果の根拠、残る制約、承認者、展開と停止の条件を残します。コードレビュー済み、試験済み、展開承認済みはそれぞれ別の状態です。AIの自己評価や点検表の完成だけで、承認が得られたことにはしません。
この表で扱っていない負荷、可用性、利用分野の規制、データ保持などが重要なら、用途に合わせて追加します。項目を増やすこと自体を目的にせず、何が起きると誰へ影響するかを基に選びます。現在の機能には対象外でも、外部送信や決済が加われば判定範囲を更新します。
AI生成か人間の実装かにかかわらず、本番で必要な条件は実際のコードと証拠で確かめます。AIが省いた処理を見つけ、未実行を未確認として残し、不合格を具体的な修正へ戻すことが、この点検表の役割です。
非推奨・廃止APIの使用を防ぐ方法は「非推奨API・廃止APIをAIが使う問題を防ぐ」、破壊的操作の対象・承認・ドライラン・復元の確認は「破壊的操作の対象・承認・ドライラン・復元を確認する」で解説しています。
