- 問題の核心: 「AIコーディングはバグや手戻りが多く、自分で書いたほうが早い」と諦めてしまう最大の原因は、AIを単なる「コードタイピスト（下請けコーダー）」として扱い、最初からコードを出力させている点にあります。
- 現場の処方箋: AIにはいきなり実装を指示せず、まず「設計者（アーキテクト）」として振る舞わせます。「仕様の明文化 ➔ 影響箇所の特定 ➔ テスト・完了条件の事前合意」を人間と握り合ってから実装に着手させます。
- 手に入る価値: 仕様や完了条件をあらかじめ整理しておくことで、認識違いによる手戻りや、修正の方向性を見失うリスクを減らし、体感としての開発スピードと精神的な安心感を大きく向上させることができます。
はじめに：「AIのコードは手直しばかりで疲れる」という本音
「AIにコードを書かせてみたけれど、動かないコードばかり出てくる」
「細かいバグを指摘して直させたら、別の場所が壊れて余計に時間がかかった」
「結局、最初から自分で書いたほうが早かった」
SNSやエンジニアの勉強会などで、こうしたAIコーディングに対する懐疑的、あるいは否定的な意見を目にすることが増えました。
新しい技術が登場した直後の過剰な期待（ハイプ）が落ち着き、実際に業務や個人開発で使ってみた人たちから「リアルな疲弊感」が漏れ始めているのを感じます。
率直に申し上げて、その感覚は極めて自然で、真っ当な違和感だと思います。
なぜなら、私自身もAIを活用し始めた当初は、画面に向かって何度も同じような手戻りを経験し、「本当にこれで開発が前に進んでいるのだろうか……」と頭を抱えていた時期があったからです。
しかし、ある決定的な「使い方の転換」を行ってから、開発現場の体感は一変しました。
手戻りや修正の堂々巡りは大きく減少し、開発をスムーズに進めやすくなったのです。
その転換点とは何か。
それは、AIのモデル性能を上げることでも、複雑な拡張機能を導入することでもありません。
AIを単なる「コード生成機（タイピスト）」として扱うのをやめ、まずは「設計者（アーキテクト）」として扱い、人間が「最高責任者（承認ゲート）」として振る舞うように役割を切り替えたことでした。
この記事では、AIコーディングに幻滅しかけている方や、懐疑的な視点をお持ちの方に向けて、現場で私たちが実践している「手戻りを減らす指示の解像度」について実直にお話しします。
1. なぜ「いきなりコードを書かせる」と破綻するのか
まず、なぜAIにコードを書かせると破綻しやすいのか、その根本的な原因を整理してみましょう。
多くの人がやってしまいがちなプロンプトは、以下のような形です。
「Pythonで〇〇を自動化するスクリプトを書いて」
「Reactでこういうレイアウトのダッシュボードを作って」
一見すると、シンプルで分かりやすい指示に見えます。
そしてAIは、極めて優秀なので、指示された数秒後にはそれらしいコードを画面いっぱいに書き出してくれます。
しかし、ここが最大の落とし穴です。
人間とAIの間にある「暗黙の前提」のズレ
人間同士の開発を思い浮かべてみてください。
もし先輩エンジニアが後輩に「適当にいい感じの自動化スクリプト書いておいて」とだけ言って席を立ったとしたらどうでしょうか。
- どのライブラリを使うのか？
- エラーが起きたときはリトライするのか、停止するのか？
- 既存のDB構造や環境変数との兼ね合いはどうするのか？
- 画面サイズが変わったときのレスポンシブ対応はどうするのか？
こうした「前提条件」が一切共有されていないため、後輩が一生懸命書いてきたコードに対して、「いや、そうじゃない。ここはこうして欲しかった」と何度も修正依頼を出すことになります。
AIも全く同じです。
指示がシンプルであればあるほど、AIは欠落した前提条件を自分の解釈で勝手に補ってコードを生成します。
その結果：
1. 出力されたコードを動かしてみてエラーが出る
2. 「ここを直して」と指示すると、AIは辻褄を合わせるために別の箇所を書き換える
3. さらに別のバグが生まれる（修正ループの始まり）
4. 人間の側が「手直しばかりで疲れる」と匙を投げる
この問題の多くは、AIの知能不足だけが原因ではありません。
「設計（仕様決定）」と「実装（タイピング）」を同時にやらせてしまったことにあります。
2. 現場の処方箋：AIを「設計者」として机に座らせる
この手戻りを断ち切る方法は、驚くほどシンプルです。
「AIにコードを書かせる前に、まず仕様書と計画書を書かせる」
たったこれだけのルールを徹底することです。
具体的には、開発のプロセスを明確に2つの段階に分離します。
| フェーズ | AIの役割 | 人間の役割（ゲートキーパー） | 成果物 |
|---|---|---|---|
| 1. 設計・合意フェーズ | 仕様の言語化、影響箇所の特定、終了条件（DoD）の策定 | 計画書のレビュー、暗黙ルールの補足、方針の承認 | 仕様書・実装計画書 |
| 2. 実装・検証フェーズ | 合意された計画書に基づいたコード生成、検証実行 | 検証結果の確認、最終マージ判断 | 実装コード、検証結果、未解決の課題 |
現場で使える「計画先行」指示テンプレート
このアプローチを取る場合、人間側の最初の指示（プロンプト）は大きく変わります。
以下は、現場で手戻りを防ぎ、実装後の報告まで規律づけるためのテンプレートです。
【現場で使える「設計先行」指示テンプレート】
〇〇の機能を実装したいと考えています。まだコードは一切書かないでください。
実装に入る前に、以下の観点で『実装計画書』を作成し、私に提示してください。
- 仕様の具体化： 入力データと期待される出力の具体例（不明な仕様や既存コードとの矛盾があれば、推測で埋めずに質問として列挙してください）
- 影響範囲の特定： 変更が必要な既存ファイル、および新規作成するファイル一覧
- 非機能要件・制約： 既存の規律（命名規則、環境変数、使用禁止ライブラリなど）への適合方針
- 完了条件（Definition of Done）： この実装が完了したと判断するための、実際に実行可能な検証コマンドやテスト手順
【検証と失敗時の追加ルール】
- 実装前に、既存のテスト・静的解析・ビルド手順を必ず確認してください。
- 検証コマンドを実行できない場合は、その理由と未検証の項目を明示してください。実行していない検証を、成功したものとして扱わないでください。
- 検証に失敗した場合は、原因・影響範囲・修正方針を報告してください。関係のないファイルまで変更して、無理にテストを通そうとしないでください。
- 実装完了時は、変更ファイル一覧・実行した検証結果・未解決の課題をまとめて報告してください。
私がこの計画書を確認・承認するまで、コードの実装には着手しないでください。
「まだコードは書かないでください」と一言釘を刺すのが最大のポイントです。
これにより、AIは全リソースを「設計の解像度を上げること」に集中させます。
3. 「事前のすり合わせ」がもたらす3つの効果
AIに設計図を引かせるステップを挟むと、開発の現場には3つの実践的な効果がもたらされます。
① 人間側が「仕様の抜け漏れ」に気づける
AIが出してきた計画書を読むことで、「あ、この場合はエラー画面が必要だったな」「既存のこのAPIを叩く必要があるんだった」と、人間自身が考えていなかった前提に気づくことができます。
コードを書いてから気づくのと、計画書の段階で修正するのとでは、手戻りのコストが大きく異なります。
② AIがコンテキストを見失いにくくなる
AIのコンテキストウィンドウには上限があり、会話が長くなったりエラー修正が重なると、本来の目的から逸脱しやすくなる傾向があります。
最初に明確な計画書が存在していれば、AIは必要に応じてその計画書を再参照しながら、迷走せずに実装を進めやすくなります。
③ 「完了条件（Definition of Done）」を事前に握り合える
客観的な判定基準を事前に合意することで、要件の見落としや「何をもって完成とするか」という認識のズレを減らせます。
もちろんテストの網羅性にも限界はありますが、事前に「どのテストコマンドで確認するか」を決めておくことで、動作確認と手戻りのリスクを効果的に低減できます。
4. 専門家が抱く疑問：「AIが適当な設計書を出してきたらどうするのか？」
ここで、技術に詳しいエンジニアほど、次のような疑問を持たれるはずです。
「AIに設計書を書かせろと言うが、プロジェクトの背景を知らないAIが書く設計なんて、どうせ破綻した机上の空論になるのではないか？」
この指摘は、まさに的を射ています。
前提条件（コンテキスト）を何も与えずに「設計して」と頼めば、AIは存在しない架空のライブラリや、現場の流儀に合わないアーキテクチャを提案してくるリスクがあります。
AIに精度の高い設計図を引かせるためには、「道具としての前提（ルール・規律）」をあらかじめ渡しておくことが不可欠です。
例えば、以下のような情報を事前に数行添えたり、関連ファイルを参照できる状態にしておくだけで、AIの設計精度は向上します。
- プロジェクトの基本構成： 「このリポジトリは TypeScript + Next.js App Router で構成されています」
- 技術選定の規律： 「状態管理には Redux ではなく Zustand を使用しています」
- 環境変数の扱い： 「APIキーなどの機密情報はコードに直書きせず、必ず
.envから取得してください」 - 検証の作法： 「コード生成後は、必ず既存の linter（oxlint や ESLint）を通過させてください」
こうした「プロジェクトの憲法」をあらかじめ共有した上で「計画書を作って」と指示すると、AIは現場の文脈に即した設計図を整理しやすくなります。
5. 036 Factoryの現場リアル：なぜ最近の開発はスムーズに進むのか？
私たち036 Factoryでも、日々様々な自動化スクリプトやWebダッシュボード、ツールの開発を行っています。
アシスタントのAnnと対話しながら開発を進めていますが、体感として手戻りが減り、開発を驚くほどスムーズに進めやすくなっています。
その理由は、私自身がプログラミングに長けているからでも、最新の超巨大モデルを四六時中ぶん回しているからでもありません。
「AIに渡す前提条件と、守るべき規律の解像度」を整えたからです。
私たちは、AIエージェントが参照するガイドラインとして、以下のような規律をあらかじめ定義しています。
- 配色や文字サイズの基本原則
- 外部APIキーを直書きせず、環境変数から取得するルール
- ファイル作成後は必ず検証用スクリプトを一発実行して整合性を確かめる運用
- 「初稿 ➔ 冷徹査読 ➔ 確定保存」の直線パイプラインを守り、AI同士の無駄なループを行わない
プロジェクトの規律や既存コードを参照できる状態で「まず計画書を作って」と依頼すると、設計の前提や変更範囲を格段に整理しやすくなります。
ただし、AIが依存関係や暗黙の仕様を見落とす可能性は常に残るため、人間による確認（レビューゲート）は欠かせません。
方針と完了条件が合意できていれば、AIは実装に集中しやすくなります。生成後は既存のテストや静的解析を実行し、変更差分と検証結果を人間が確認します。
手戻りを減らす鍵は、設計書を作ること自体ではなく、「計画・実装・検証を一貫した流れにすること」です。
6. まとめ：人間の役割は「下請けの検収係」から「最高責任者」へ
もしあなたが、AIコーディングに対して「使えない」「手戻りばかりで疲れる」と感じているなら、ぜひ一度だけ、接し方を変えてみてください。
AIは、キーボードを猛スピードで叩く「タイピスト」ではありません。
数千行の仕様を瞬時に整理し、設計案を提示してくれる「優秀な新米アーキテクト」です。
そして、私たち人間の役割も変わります。
AIが吐き出した読みにくいコードのバグを必死に探す「下請けの検収係」ではなく、「全体の整合性とアーキテクチャを見守る最高責任者（ゲートキーパー）」として机に座るのです。
明日、AIに開発の指示を出すときは、冒頭にこう付け加えてみてください。
「コードを書く前に、まず設計書と検証手順の計画を出してください」
設計先行という考え方を、万能の特効薬ではなく「AI開発の不確実性をコントロールする実務手法」として位置づけること。
これこそが、AIコーディングを真の武器にする最も堅実なアプローチです。
食わず嫌いをしてしまうには、あまりにも惜しい時代です。
AIを「設計者」として隣に座らせ、ストレスのない開発体験をぜひ味わってみてください。
☕ 開発や思考で加熱した頭を、一杯の珈琲で整える
036 Factoryの本業は、ご注文をいただいてから生豆を一粒ずつ手作業で選別（ハンドピック）して焙煎する、小さな自家焙煎珈琲工房です。
AIや設計の思考を巡らせて疲れた頭をふっとリセットする、雑味のない「毎日飲める普通のコーヒー」を少数精鋭で焼いています。作業のお供や息抜きに、ぜひ工房の豆を覗いてみてください。