AI にコーディングを任せてからの検収

半年前、仕事のやり方を変え始めた。

コードを書く作業の大部分は、もはや自分が行わない。自分の役割は「コードを書く人」から「コードが正しいか判断する人」に変わった。

プロジェクトの成否を分けるのは、自分がどの段階で判断に関与したかだ。この記事では、コーディングをAIに任せるとき、人間はどうあるべきかを探究する。

検収者の三つの段階

検収作業を三つの段階に分解した：問題の定義、実装の検証、リリースの判断。

検収者の仕事はコードレビューアーやプロダクトマネージャーとは異なる。検収者がやることはより具体的だ。何が必要かを知り、正しいかを判断し、OKかを決める。

問題の定義

AIコーディングの前提は問題の明確さだ。曖昧な要件は必然的に曖昧な出力を生む。

適切な問題定義には三つの要素が含まれる。第一に入出力の境界だ。「入力はユーザーアクションログを含むCSVファイル、出力はユーザーごとの継続率、形式はJSON配列」と明確に述べる。第二に失敗ケースだ。AIに失敗ケースを提供することは、検収のレッドラインを事前に引くことに相当する。第三に制約条件だ。パフォーマンス要件、依存制限、コードスタイルの好み。「外部依存なし、コード200行以内」と明確に述べるだけで、生成結果の実用性は大幅に向上する。

三つの要素のうち一つでも欠けると、検収の後続段階で問題が生じる可能性がある。明確な入出力の境界がない場合、AIは機能的には正しいがインターフェース設計がまったく異なるモジュールを生成し、統合時に初めて不一致が発覚する。失敗ケースがない場合、AIは正常パスのみをカバーし、例外的な状況はすべて検収者が発見することになる。問題の定義は一回限りの作業ではなく、プロジェクトの進行中に反復される。

実装の検証

コードが動くことは最低条件だ。真の検証はこの問いに答えることだ：この実装は自分が知らないシナリオでも信頼できるか。

比較テスト。同一の要件を異なるバージョンでAIに与え、出力の差異が合理的かを確認する。同じ要件で二回生成した結果がコアロジックで一致しない場合、要件自体に曖昧さがあり、問題定義の段階に戻って再澄清する必要がある。

境界テスト。例外的な状況——空の入力、巨大なファイル、同時リクエスト——こそが実装の品質を試す場だ。具体的な做法は、各入力パラメータの境界値（0、1、最大値）を列挙し、AIが生成したコードが正しく処理できるかを一つずつ検証することだ。ほとんどのAI生成コードは正常パスでは良好に動作するが、境界では検証不足、リソースリーク、無限ループが露呈する。

回帰テスト。AIのコード生成コストは低いが、再生成が一貫性を保証するわけではない。あらゆる変更が回帰検証を必要とする。回帰の鍵は影響を受けるモジュールの範囲を特定することだ。AIが生成したコードには暗黙のクロスモジュール依存が含まれることが多く、コードdiffだけでは本当の影響範囲が見えない。

検証段階で最もスキップされやすいのは記録だ。これらの記録は次回の問題定義への入力となる。

リリースの判断

これが検収者にとって最も核となる判断だ。

三つの基準で見る。第一に、コアパスが信頼できるか。ユーザーが最も頻繁に使う機能チェーンは検証済みでなければならない。コアパスの各段階は少なくとも一度手動で検証する。第二に、失敗が制御可能か。三つの問い検証する：最悪の場合ユーザーに何が見えるか？データは失われるか？システムは復旧できるか？答えられなければ、検証段階に戻って対応するシナリオのテストを補完し、三つの問いすべてに明確な答えが出るまで続ける。第三に、必要範囲を超えているか。AIは「機能完全」だが要件を超えたコードを生成しがちだ。必要以上に生成されているなら、削減は追加よりも判断力を要する。

いくつかのプロジェクトで似た落とし穴を踏んだ。AIが生成したコードは機能完備でテスト通過だが、ある入力閾値で処理時間が急騰した——バッチ処理が欠けていた。別のケースでは回帰検証を飛ばし、小さな変更が隠れた依存を壊した。コードにバグはなかったが、「完了」と「可用」の間にブラインドスポットがあり、それはまさに検収者が埋めるべき部分だった。

二つの具体例

ブログ改造

要件は三つのAgent対応エンドポイント——llms.txt、Markdownエンドポイント、構造化JSON API——で、すべての追加コンテンツを静的ファイルとして生成する。検証段階ではcurlでフォーマットの正確さを確認し、ソースファイル変更後に再ビルドして同期更新を確認し、Agent使用シナリオをシミュレートしてすべてのリンクが存在することを確認した。リリース段階では三つの指標を評価した：コアパス検証済み、失敗制御可能（エンドポイントが利用不可の場合は404を返す）、範囲超過なし。改造にかかった時間は半日、コーディングは2時間以内。

データ処理マイクロサービス

要件は上流からプッシュされるJSONイベントストリームを構造化データに変換してデータベースに書き込むことだ。問題定義では入力形式、失敗ケース（必須フィールドが欠落したイベントはフォーマットエラーとして破棄し、書き込まない）、制約（単一処理時間200ms以内）を明確にした。検証段階では三つのデータセットを準備した：正常データ、境界データ（空のイベントストリーム、単一巨大レコード）、異常データ（フォーマットエラー、フィールド欠落）。AIが生成したコードは境界データで二つの問題を露呈した：単一巨大レコードがJSON解析のタイムアウトを引き起こし、空のイベントストリームが書き込みプロセスをハングさせた。リリース段階ではコアパスが安定していること、失敗時にグレースフルデグラデーションが可能なこと、機能範囲が膨張していないことを確認した。

まとめ

人間の価値は三つのことに体現される：何が必要かを知ること、正しいかを判断すること、OKかを決めること。前二者は業務理解と経験の蓄積に依存し、最後はリスク判断だ。AIが「どうやるか」を担うようになったからこそ、人間は「何がほしいか」と「いいかどうか」をより明確に考える必要がある。

一つだけ覚えておくことがあるなら：AI時代には、判断力は生成速度よりもより希少だ。検収はコーディングの延長である。

One More Thing

検収チェックリストを用意した。リリース前に一通り確認するだけで、感覚だけの判断よりはるかに信頼性が高い。