AI駆動開発では、プロトタイプを作るのに1日かかった。顧客に「これで進めていいですか」と確認してもらうのに2週間かかった。これが2026年時点の現実だ。

ボトルネックはすでに「作ること」にはない。「決めること」——顧客合意・仕様確定・承認——に移っている。進め方を変えないまま実装ツールだけ変えると、プロジェクト全体は旧来のペースで動き続ける。

AI駆動開発とは何か

AI駆動開発とは、Claude CodeやCursorなどのAIコーディングツールを中心に据え、人間がAIに実装の大部分を委任しながら高速にプロダクトを構築する開発スタイルである。

重要なのは「AIが書くから速い」という点ではなく、速くなった結果として何が変わるか、だ。実装サイクルが週単位から日単位に縮まると、顧客との確認・合意・修正のサイクルが相対的に大きな比重を占めるようになる。進め方を理解するには、まずこの構造変化を把握する必要がある。

従来型開発とAI駆動開発で何が変わるのか

従来型開発AI駆動開発
実装速度週〜月単位日〜数日単位
ボトルネックコードを書く時間顧客合意・仕様確定
仕様の確定タイミング実装前（仕様書ベース）プロトタイプを見ながら
顧客との接触頻度週次定例が中心タスク完了ごとに都度
変更のコスト高い（手戻りが大きい）低い（即日修正できる）
チームに求められるスキル実装力合意形成の設計力

変わるのは実装速度だけではない。開発の全体構造——仕様をいつ確定するか、顧客とどこで合意するか、変更をどう受け取るか——が変わる。

なぜ実装が速いのにプロジェクトが遅くなるのか

これがAI駆動開発で最初にぶつかる矛盾だ。

回答は単純だ。プロジェクト全体の速度は「最も遅い工程」で決まる。実装が1日で終わっても、顧客の確認に5営業日かかれば、1週間に1サイクルしか回らない。AIで実装が10倍速くなっても、合意形成が10倍速くならなければ、プロジェクト全体は速くならない。

当社の開発案件で起きたこと

2026年時点で当社が関わったAI駆動開発案件では、実装タスクが200件を超えた（タスクは200個を超えた。それでも、ひとつも落ちなかった。）。

このプロジェクトで最も合意形成に時間がかかったのは、確認フローの設計が旧来のままだった工程だった。画面の仕様について「Slackで議論→議事録メール→翌週の定例で最終確認」というフローが残っていた部分は、実装完了から承認まで2週間以上かかった。

同じ案件の中で、タスクのコメント欄に「この仕様でいいですか？」と書き、顧客が直接コメントで回答するフローに変えた画面は、同じ合意が2日で取れた。

差を生んだのはツールの機能ではなく、「顧客が何かを見て・判断して・返す」というサイクルの設計だった。詳細は「AI駆動開発で「作る」は1日、「決める」は1週間かかる問題の正体と対処法」で解説している。

AI駆動開発の進め方 — 全体像

AI駆動開発を機能させるには、実装フローと合意フローを別々に設計する必要がある。

ステップ1: プロトタイプ優先で動かす

仕様書を完成させてから実装するのではなく、まず動くものを作って顧客に見せる。「仕様書を読んで承認する」より「動くものを見て判断する」方が、顧客の理解速度も判断速度も上がる。

ステップ2: タスクを実装単位・確認単位に分ける

1機能・1画面を1タスクにする。まとめて確認するより「この機能だけ見てください」という小さい単位の方が、顧客は即日返答できる。タスクが完了したら、そのタスクのコメント欄で確認を依頼する運用にすると、週次定例を待たずに承認サイクルが回る。

ステップ3: 顧客を同じボードに招待する

顧客がタスクのコメント欄に直接フィードバックを書ける環境を作ると、Slackの会話に埋もれず、「いつ・何を・誰が承認したか」が記録として残る。確認依頼のSlackメッセージが流れて見落とされる、というロスがなくなる。

ステップ4: 判断の権限を事前に整理する

プロジェクト開始時に「担当者が判断していい範囲」と「決裁が必要な変更」を明確にしておく。仕様の細部は担当者が即断できる、追加費用が発生する変更は事前確認が必要、という区別が明確なプロジェクトは、承認待ちが極端に短い。

顧客・クライアントをどう巻き込むか

顧客の巻き込み方が、AI駆動開発プロジェクトの成否を分ける最大の変数だ。

直答：顧客を同じタスク管理ボードに招待し、タスク単位でフィードバックをもらう設計を最初に作る。

仕様書なしで開発を進めるときの合意記録の設計は「バイブコーディング時代のプロジェクト管理 — 仕様書はどこまで要るか」で詳しく扱っている。非エンジニアの顧客がAI開発のスピード感に追いつけない問題、プロトタイプを使った顧客合意の手順、修正依頼の受け方と捌き方は、それぞれ個別の工夫が必要になる（近日公開予定のシリーズ記事で扱う）。

ここで鍵になるのは「確認の場所をひとつにすること」だ。Slackで質問、メールで仕様確認、定例で最終決定——という分散した確認フローは、顧客がどこに何の判断が残っているかを把握できなくなる原因だ。確認はすべてタスクのコメントに集約する設計にすることで、顧客の確認漏れが構造的に発生しにくくなる。

受託開発・Web制作会社向けの具体的な活用パターンは受託開発・Web制作のタスク管理にまとめている。

チームとタスクをどう設計するか

AI駆動開発では、「AIが実装するタスク」と「人間が判断・確認するタスク」が混在する。この2種類を同じボードで管理できる設計が、タスク漏れを防ぐ。

当社の200件超の事例で機能した設計のポイントは3つだ。

1つ目は、実装タスクと確認待ちタスクのステータスを分けること。「実装中」「確認依頼中」「承認済み」「修正中」のステータスを持つだけで、誰が何を待っているかが一目で分かる。

2つ目は、「相談」と「タスク」を別の場所に置くこと。まだ決まっていない「ちょっとこの仕様どうしますか」という会話をタスクに昇格させるタイミングを明示的に設けることで、未決事項がボードに積み上がらなくなる（このテーマは近日公開のシリーズ記事で詳しく扱う）。

3つ目は、AIエージェントが生成したコードのレビュータスクを見落とさない仕組みを作ること。実装速度が上がると、レビューの積み残しが一気に増えやすい。レビュー依頼をタスクに紐づけ、担当者が明示されている設計にすることで、レビューの詰まりがプロジェクト全体のボトルネックになることを防げる。

AI駆動開発の「言った・言わない」問題はなぜ悪化するのか

AI駆動開発では、この問題が従来型開発より深刻になる。

直答：イテレーションが速くなった分、仕様の変更頻度が増えるからだ。

従来型開発では仕様確定→実装という順序があったため、仕様変更は「変更依頼書」として記録が残りやすかった。AI駆動開発では「じゃあこの方向で進めましょう」という口頭やSlackの一言から実装が動き出すことが多く、その会話が後から確認できない場所にある場合、「言った・言わない」のトラブルに発展しやすい。

対策は、合意はタスクのコメントに残すことを運用ルールにすることだ。Slackで合意したことをタスクのコメントに転記する、あるいは最初からタスクのコメントで合意を取ることで、「どのタスクについて・誰が・何を決めたか」が記録として残る。

AI駆動開発に向くツールの条件

ツール選定の基準は「外部メンバーをどれだけ摩擦なく巻き込めるか」だ。

社内チームだけが使うツールでプロジェクトを管理すると、顧客や外注先へのフィードバック依頼はSlackかメールになる。そこで確認の場所が分散し、前述の問題が起きる。

AI駆動開発に向くタスク管理ツールの条件は3つある。

  • 外部ゲスト（顧客・外注先）を無料または低コストで招待できること
  • 既存チャットツール（Slack・Discord）と連携し、開発チームの作業フローを変えずに運用できること
  • タスクとコメントで合意の記録が残せること

受託開発チームがすぐ使えるテンプレート（キックオフ・オンボーディング・受け入れテスト）はテンプレートギャラリーから無料で使える。GitHub IssuesやLinearとの使い分け、ドキュメント管理の設計については近日公開のシリーズ記事で扱う。

まとめ — 変えるべきは「作り方」より「進め方」

AI駆動開発で変えるべきは、ツールだけでなく進め方の設計だ。

実装が1日になったとき、プロジェクトが速くなるかどうかは「決めること」の設計で決まる。顧客との確認の場所・単位・権限——この3つを設計した上でAIの実装速度を活かすことが、AI駆動開発を機能させるための本質だ。

このピラー記事が扱う「全体像」の各論は、以下のシリーズ記事で深掘りしている。