Claude Codeで「失敗続き」は卒業…コードを“1行も読まない”アプリ開発「4原則」(3/3)

【応用編】検証＆修正に役立つ「3つ」の手法

　AIが出力するものは「それっぽい」が完全ではない。実用にするには常に検証と修正が必要だ。AIが作業し、結果を自分で確かめ、問題があれば直してまた確かめる。この繰り返しを、人間がいちいち指示する必要はない。AIに自律的に回させるのだ。筆者はこれを「エージェントループ」と呼んでいる。

　ループを回すための手法は、既に存在している。ソフトウェア工学の手法の多くは、そもそも「人間は間違える」ことを前提に、それをできるだけ無くすために生まれた。前提が同じだから、AIにもそのまま使えるのだ。具体的なやり方は以前の記事で紹介したので、ここでは以下の3つの考え方だけを紹介しよう。

■仕様駆動開発
何を作るか（仕様）とどう作るか（設計）を先に文書にし、それを起点に開発する手法だ。文書は、コンテキストウィンドウの外のことを覚えていられないAIにとって「プロジェクトの記憶」になる。常に最新に保たせれば、そのまま人間への引き継ぎ資料にもなる。

■テスト駆動開発
先にテストを書き、それを通すことを目標に実装する手法だ。「動いたように見える」ではなく「先に決めたテストが通る」を完了の基準にする。グッドハートの法則への対策である。変更のたびに全テストを流す「回帰テスト」で、直したつもりで別の場所を壊してしまう「デグレ」（デグレード）も防げる。

■レビュー駆動開発
作ったものを必ず第三者の目でレビューし、指摘がなくなるまで直す手法だ。人間には、自分の考えを裏付ける情報ばかりに目が向く「確証バイアス」がある。AIも同じで、自分の出力はもっともらしく見えてしまう。だからレビューは別のAIを使う。筆者は設計と実装をClaudeで行い、レビューは学習も癖も違うOpenAIのGPTにさせている。OpenAI公式のClaude Code用プラグイン「codex-plugin-cc」を使えば簡単だ。

　セキュリティも、このループに組み込む。守るべき条件を仕様に書き、テストとレビューで毎回確かめさせる。後から穴をふさぐのではなく設計段階から安全を組み込む「セキュリティ・バイ・デザイン」の考え方だ。

コードは読まなくていい？人間に残る“重要タスク”

　人間のエンジニアの仕事は、コードを書くことから「何を作るか」を決め、結果を判断することに変わる。

　AIに推測させないためには、推測の余地のない仕様が必要だ。何のために、誰が、どんな場面で、何を、どこまで必要としているのか。この「要件定義」は人間にしかできない。ここがあいまいなら、AIがどれほど優秀でも使いにくいシステムになる。

　「レビューで人間がパンクする」のは、AIの作業を1行ずつ見ようとするからだ。見るべきなのは作業ではなく判断だ。仕様と設計と優先順位を決め、AI同士のレビューで決着がつかなかった論点に結論を出せばよい。

　AI時代にこそ、人間はソフトウェア開発をより深く理解している必要がある。本稿の考え方は、どれも開発の経験から出てくるものだ。ベテランの経験はAIによって不要になるのではなく、AIを正しく動かす土台になる。

「AI≠魔法」から始めよう

　1986年、ソフトウェア工学の大家Frederick Brooks氏は「銀の弾丸はない」と書いた。銀の弾丸は不死身の狼男を一撃で倒せる必殺武器だが、ソフトウェア開発の難しさを一挙に解決する魔法の技術は存在しない、という指摘だ。40年たった今も同じだ。AIも銀の弾丸ではない。

　だが、正しい戦い方ならベテランエンジニアはとうに知っている。推測させない、検証させ続ける、人間は判断に専念する。SNSの失敗談に惑わされず、自分が積み上げてきた開発の原則を、AIに渡すルールとして言葉にするところから始めてほしい。