第3節 暴走させない5原則

この5つは本講座の背骨です。制作パートで何十回も登場します。

原則1: 1サイクル1機能

一度に頼むのは1機能だけ。「指示→AIが作る→動かす→確認→OK」の1周を回してから、次の機能へ。大きく頼むほどAIは脱線し、脱線に気づくのも遅れます。小さな周回は遠回りに見えて、常に「どこまでは正常か」が分かっている状態を保てる最短ルートです。

原則2: 指示書で仕様を固定する

作るもの・作らないものを文書(指示書)にして、実装AIに最初に渡します。口頭(チャット)だけの指示は、会話が長くなると押し流されて忘れられます。文書は消えません。特に効くのが「作らないものリスト」。AIの「ついでにこれも付けました」を、仕様レベルで封じます。

原則3: 動いたらセーブポイント

動作確認がOKになるたびに、その状態を記録します(GitHubへの「コミット」。ゲームのセーブと同じです)。セーブがあれば、次の変更で何かが壊れても「最後に動いていた状態」へ確実に戻れます。セーブなしの開発は、セーブなしでラスボスに挑むのと同じです。

原則4: 迷走したら、粘らずリセット

AIとのやりとりが長くなり、修正を頼むたびに別の場所が壊れる——そんな泥沼に入ったら、その会話に粘るのをやめます。会話を新しく始め、指示書とセーブポイントからやり直す。AIとの会話は、こじれたら「仕切り直せる」のが人間との仕事にない利点です。損切りの基準は第4節で扱います。

原則5: AIの「ついでに提案」を全部受けない

AIは気を利かせて「ダークモードも付けましょうか?」「統計機能があると便利では?」と提案してきます。魅力的に聞こえますが、提案に乗るたびに範囲が膨らみ、完成が遠のきます。判断基準は1つ——指示書に書いてあるか。書いてなければ「今回はやらない。メモだけ残して」。良い提案なら、アプリが完成して公開された後にゆっくり足せばいいのです。

5原則を支える土台: 会議室と工事現場を分ける

第1章で紹介した2ツール分業を、運用ルールとして固めます。

考える場所はブラウザのClaude(会議室)、作る場所はClaude Code(工事現場)。そして両者の間の線引きはこうです。

実装の途中で「やっぱりこの仕様、変えたほうがいいかも」と思う瞬間は必ず来ます。そのときClaude Codeにそのまま相談したくなりますが、こらえてください。現場で設計変更を始めると、指示書と現物がずれ、指示書が仕様を固定する力(原則2)が死にます。迷いは会議室へ。決めてから現場へ。この往復こそが、第1章で言った「工程は行き来する」の実践です。