システム開発でAIを使うときは、「コードを書けるか」だけでなく、その変更を誰が確かめ、運用後に誰が直せるかまで決めておきたいところです。生成したコードが動いても、依頼した仕様や安全上の条件を満たしたかは別に確認します。
この記事では、AIに実装を補助させる開発担当者向けに、依頼範囲・実際の差分・テストの根拠・保守をつなぐ確認方法を説明します。開発速度の改善率や、特定ツールの性能を比較する記事ではありません。
AIに任せる作業の範囲を決める
「この機能を作って」とだけ渡す前に、変更してよい対象、期待する振る舞い、変えてはいけない条件を書きます。小さな作業でも、入力と出力、エラー時の扱いが決まっていなければ、完成の判定が曖昧になります。
説明用の依頼なら、「注文数の上限を変える。料金計算と認証の仕様は変えない。上限の前後を既存仕様と照合する」のように、対象と確認条件を一緒にします。これは特定ツールの必須構文ではなく、開発側が責任を持つ範囲を整理する案です。
秘密情報や顧客データを渡してよいかは、利用サービスと組織の規程で確認します。AIに必要な文脈を与えることと、無関係な資料まで送ることを同一視しないようにします。
説明文より実際の差分を確認する
OWASPの「Secure Coding with AI」は、生成された変更について、要約だけで承認せず、変更された各ファイルや依頼範囲外の編集を確認するよう勧めています。OWASP Section 7
そこで、レビューでは次の二つを別々に確認する方法を提案します。
- 必要な変更があるか：期待した仕様をどこで実現したか。
- 不要な変更がないか：依存関係、設定、既存テストなどを目的なく変えていないか。
コードの説明が自然でも、実際の条件式が違う場合はあります。説明と差分が食い違ったら、差分と仕様へ戻って確認します。実装を理解できる担当者がいなければ、確認不能のまま利用範囲を広げない判断が必要です。
生成したテストも期待仕様へ戻して読む
AIが実装とテストを両方作った場合、テストが通ったことだけを独立した正しさの証拠にはしません。OWASPは、失敗テストの削除、判定の弱体化、誤った実装の動作を正解とするテストなどを確認対象に挙げています。OWASP Section 8
期待値を実装の現在の出力から写すと、同じ誤りを再現して合格することがあります。仕様、既存の合意、許可されたサンプルデータなど、実装とは別の材料から期待結果を確認してください。
テストの追加数だけでなく、どの要求を確かめるかも見ます。成功する入力だけでなく、無効入力、境界、権限外の操作など、変更の影響に応じた問いを加えます。
仮例：注文数の上限を変える
架空の注文機能で、受け付ける整数の数量を1〜5から1〜10へ変更するとします。画面の上限値を10に変えただけでは、API側の判定や表示との整合は未確認です。
| 確認する層 | この例での問い |
|---|---|
| 画面 | 利用者が10を指定でき、範囲外の扱いが分かるか |
| サーバー | 10を受け付け、11を仕様どおり拒否するか |
| 既存機能 | 1〜5の従来の注文が変わらず成立するか |
| テスト差分 | 上限5の期待値を理由なく消していないか。変更理由に対応しているか |
| 対象外 | 料金や認証など、今回依頼していない変更が入っていないか |
この表は説明用で、実システムの検証結果ではありません。数量が在庫や配送条件にも関わるなら、さらに確認範囲を広げます。逆に無関係な機能まで毎回全面的に手作業で確認する必要がある、と一律には決めません。
AIの出力が想定と違ったら、指示を増やす前に、仕様が不足していたのか、実装が違うのか、テストの期待値が違うのかを分けて直します。
利用開始後に直せる状態で受け取る
受け取り時には、コードだけでなく、変更理由、確認した仕様、テスト結果、残る制約をそろえます。OWASPも、AI生成コードの正しさや保守性に責任を持つ開発者の確認を求めています。OWASP Section 14
特定のAIとの会話を読まないと変更理由が分からない状態は避け、通常の開発記録から追えるようにすることを勧めます。再生成すれば必ず同じ変更が得られると仮定せず、受け入れた版を管理します。
まず一つの変更について、仕様と差分とテストが対応するかを見直してみてください。一般的なレビューの進め方はコードレビューの観点、利用開始前の受け渡しは開発から運用への引き継ぎをご覧ください。開発体制のご相談はSES事業で承ります。