AIコーディングの流れ
一つのアイデアから継続運用まで、AIコーディングは書いて終わりではなく、4つの時期・12の段階を巡るループです。各段階に「なぜ重要か・何をするか・よくある失敗・得られるもの」を添えています。
発展：AIとの協働のコツ（プレイブック） →計画
作る前に考える。曖昧なアイデアを、AIが実行できる計画に変える。
- 1
アイデア
「誰のどんな課題を解くか」を明確に。一文で言えると理想。
- なぜ重要か
- 方向を間違えると後の作業はすべて無駄になる。作り始める前に「やる価値があるか」を確かめる。
- 何をするか
- 「誰の・どんな課題を解くか」を一文で書く。友人に話して伝わるレベルに。
- よくある失敗
- 一度に十個の機能を詰め込み、結局何も完成しない。
- 得られるもの
- 一文で言い切れる製品コンセプト。
- 2
要件
アイデアを具体的な機能とルールに分解し、完成像をAIに伝える。
- なぜ重要か
- AIは言われた通りにしか動かない。曖昧だと推測し、間違いに気づくのはたいてい最後。
- 何をするか
- 主要機能・利用フロー・「やらないこと」を列挙し、AIへの指示書にする。
- よくある失敗
- 「願望」を「要件」と混同し、完成の定義がない。
- 得られるもの
- 機能リストと受け入れ基準。
- 3
アーキテクチャ
フロント・バック・DBの配置を決める。書く前に図を描く。
- なぜ重要か
- 部品の配置を先に決めておけば、後の変更が全体に波及しない。
- 何をするか
- フロント・バック・DBの関係図をAIに描かせ、理解してから次へ。
- よくある失敗
- 構造が固まる前に書き始め、途中でアーキテクチャが破綻する。
- 得られるもの
- アーキテクチャ図と技術選定。
- 4
計画
作業を小さな手順に分割し、AIが一度に一つに集中できるように。
- なぜ重要か
- 大きなタスクを一度に渡すとAIは集中を失う。小さく刻めば正確になる。
- 何をするか
- 機能を、単独で完了・検証できる小タスクに分解する。
- よくある失敗
- 手順が大きく相互依存し、一つ詰まると全部止まる。
- 得られるもの
- 順序付きのタスクリスト。
構築
AIが書き、あなたが舵を取る。動いて読めるコードを作る。
- 5
実装
AIが計画通り実装。あなたは方向確認と文脈補足を担う。
- なぜ重要か
- ここはAIが最も得意な工程。ただし方向の正しさはあなたが担保する。
- 何をするか
- タスクは一度に一つ。書く様子を見て文脈を補い、ずれたらやり直す。
- よくある失敗
- AIのコードを丸呑みし、理解しないまま先へ進む。
- 得られるもの
- 実際に動く機能コード。
- 6
コードレビュー
別のAI（または自分）でロジックと保守性を確認。
- なぜ重要か
- 「動く」と「良い実装」は別物。今点検しなければ、負債は未来の自分へ。
- 何をするか
- 別のAI（または自分）が一段ずつ「正しいか・保守しやすいか」を問う。
- よくある失敗
- バグの有無だけ見て、読みやすさや変更しやすさを見ない。
- 得られるもの
- 修正済みで読めるコード。
検証
公開前の関門。セキュリティ・契約・テストを一つずつ通す。
- 7
セキュリティレビュー
権限・入力検証・機密漏洩など脆弱性を集中点検。公開前に必須。
- なぜ重要か
- 脆弱性一つでユーザーデータが漏れうる。公開前、最後の防衛線。
- 何をするか
- 権限・入力検証・コードに直書きされた機密をAIに集中点検させる。
- よくある失敗
- 「自分の小さな案件は狙われない」と思い込み丸ごと飛ばす。
- 得られるもの
- 脆弱性リストと、その修正。
- 8
契約検証
フロントとバックのデータ形式の約束が一致するか確認。
- なぜ重要か
- フロントとバックでデータ形式の認識がずれると、画面が繋がらずエラーになる。
- 何をするか
- 送受信するフィールドが両者で一致するか確認。理想は同一スキーマの共有。
- よくある失敗
- 各自で実装し、結合時にフィールド名や型が噛み合わないと判明する。
- 得られるもの
- 双方が守るデータ契約。
- 9
統合テスト
各部分を繋いで全体としてテストする。
- なぜ重要か
- 各部品が単体で動いても、繋げて動くとは限らない。結合して初めて分かる。
- 何をするか
- 複数機能を繋げて実際の流れを再現するテストをAIに書かせる。
- よくある失敗
- 単機能だけテストし、協調する場面を一度も試さない。
- 得られるもの
- 自動実行される統合テスト一式。
- 10
実機テスト
本番に近い環境で動かし、実ユーザーのように操作する。
- なぜ重要か
- 自動テストでは測れない「使い心地」や本番特有の問題は、手で触って初めて分かる。
- 何をするか
- 本番に近い環境で、実ユーザーのように最初から操作してみる。
- よくある失敗
- 自分のPCで動かしただけで問題ないと決めつける。
- 得られるもの
- 実際に使って見つけた問題の記録。
運用
公開して守り続ける。デプロイ・観測・改善。
- 11
デプロイ
本番公開して世界からアクセス可能に（本サイトはCloudflare Pages）。
- なぜ重要か
- 公開しなければ誰も使えない。デプロイは成果をユーザーの手に届ける工程。
- 何をするか
- ホスティングを選び（本サイトはCloudflare Pages）、ドメインと環境変数を設定して公開する。
- よくある失敗
- パスワードや鍵をコードに直書きしたまま公開する。
- 得られるもの
- 外部から到達できる公開URL。
- 12
監視
公開後も観察し続ける：壊れていないか、速いか、異常はないか。
- なぜ重要か
- 公開は終点ではない。故障・遅延・攻撃は、ユーザーより先に気づくべき。
- 何をするか
- エラー通知と基本指標を整え、定期的に確認し、学びを次の周回へ戻す。
- よくある失敗
- 公開後に見なくなり、ユーザーの方が先に異常に気づく。
- 得られるもの
- 自分に先に知らせてくれる観測の仕組み。