こんな経験、ありませんか
ChatGPTやAIコーディングツールにお願いすれば、それっぽく動くコードはすぐ手に入ります。ところが数日後に仕様変更が入った途端、どこを直せばいいのか自分でも分からなくなる。バグの原因を追おうにも、そもそも「なぜそのロジックになっているか」を説明できない——こうした状態は、いわゆる「動けばOK」の勢い任せの開発（俗に vibe coding と呼ばれる進め方）にありがちな落とし穴です。
スピードは出ているのに、後から振り返ると資産にならないコードが積み上がっていく。これでは副業や業務効率化のためにAIを使っているのに、逆に手間が増えてしまいます。
この記事で分かること
本記事では、AIに任せきりにするのでも、逆に全部自分で設計するのでもない、品質と速度を両取りする実践プロセスを紹介します。特別なツールの導入は不要で、普段使っているChatGPTやAIコーディングアシスタントに対する「頼み方」と「進め方」を変えるだけで実践できます。読み終える頃には、今日の作業から適用できる具体的な手順が手元に残るはずです。
実践手順
ステップ1：要件を一行ではなく三行で渡す
まず変えたいのが、AIへの依頼の粒度です。「ログイン機能を作って」だけでは、AIは無数の実装パターンの中から適当に一つを選んでしまいます。代わりに次の三点をセットで伝えましょう。
- 実現したいこと（目的）
- 使ってよい技術・避けたい技術（制約）
- 完了とみなす条件（受け入れ基準）
これだけで出力の方向性がかなり安定します。依頼文を三行に増やす手間は、後の手戻りを減らすための最も安い投資です。
ステップ2：実装前に設計案を先に出させる
いきなりコードを書かせず、「まず設計方針を箇条書きで提案して」と一段階挟みます。ここで出てきた設計案に対して、自分が違和感を持つ箇所だけ質問や修正指示を返す。この段階での対話は正直やや面倒に感じるかもしれませんが、実装後の手直しに比べればずっと軽い作業です。
ステップ3：実装は小さく刻んで都度レビューする
一気に全機能を生成させるのではなく、「まずこの関数だけ」「次にこのテストだけ」と区切って進めます。区切りが細かいほど、AIが出したコードのどこがおかしいかをその場で発見しやすくなります。最初は「区切りすぎて逆に遅くないか」と戸惑う方も多いのですが、慣れるとむしろこちらの方がトータルで速いと感じるはずです。
ステップ4：テストコードもAIに書かせ、自分で読む
テストの作成もAIに任せて構いません。ただし、生成されたテストは必ず自分の目で読み、「この条件で本当に十分か」を確認する工程を省かないでください。ここを飛ばすと、テストが通ること自体が目的化してしまい、肝心の品質担保にはつながりません。
個人的には、テストコードを読む作業を通じて、AIが生成した実装コードの意図も同時に理解できることが多いです。一石二鳥の工程だと感じています。
ステップ5：動いた後に「なぜ動くか」を言語化する
最後に、機能が動作した時点で終わりにせず、簡単な説明文をコメントやドキュメントとして残しましょう。「なぜこの実装にしたか」「他に検討した案は何か」を一言でも書いておくと、次に自分やチームがコードを触るときの負担が大きく変わります。
ポイント：要件の言語化・設計レビュー・小刻みな実装・テストの精読・振り返りの記録という5つの工程は、いずれも古典的なソフトウェア開発の基本に近いものです。AIの速さに、こうした昔ながらの丁寧さを組み合わせることが、品質と速度の両立につながります。
つまずきやすいポイントと対処
設計案を求めても抽象的な回答しか返ってこないことがあります。これは依頼文の制約や受け入れ基準が曖昧なまま投げているケースがほとんどです。ステップ1に戻り、条件をもう一段具体的にしてみてください。
また、小刻みなレビューを続けるうちに、途中で疲れて雑になってしまうという声もよく聞きます。これは正直なところ誰にでも起こることです。慣れないうちは、1回のセッションで区切る機能の数を最初から少なめに設定しておくと、集中力を保ちやすくなります。
AIが提示したコードに違和感を覚えたら、その場で「なぜこの実装にしたのか」を聞き返すクセをつけましょう。理由が説明できない提案は、そのまま採用しないほうが安全です。
まとめ
AIに勢いよく書かせるだけでは、短期的な速さと引き換えに後々の保守性を失いがちです。要件の言語化、設計レビュー、小刻みな実装、テストの精読、振り返りの記録——この5ステップを普段の作業に組み込むことで、AI駆動開発の速度を保ちながら、資産として積み上がるコードを書けるようになります。まずは次にAIへ依頼するタスクひとつからで大丈夫です。三行の要件出しから試してみてはいかがでしょうか。
コメント