AIで動くものを作るのに1日かかった。顧客に確認してもらうのに1週間かかった。これが2026年のAI駆動開発プロジェクトの現実だ。

ボトルネックはすでに「作ること」にはない。「決めること」——顧客合意・仕様確定・承認——に移っている。

AIが作る速度と、人が決める速度の非対称

Claude CodeやCursorを使えば、業務システムのプロトタイプを1〜3日で動かすことができる。半年前まで2〜3週間かかっていた工程が、文字通り1日の作業になった。

問題はここから始まる。

動くものができても、顧客がそれを確認して「これでいい」と言うまでに、5営業日から10営業日かかる。担当者が確認して、上長に見せて、別部署に意見を聞いて、修正要望をまとめて——このプロセスは、AIの登場前後で何も変わっていない。

実装が3日で終わって、承認に2週間かかる。プロジェクト全体の速度は、遅い方に引っ張られる。

なぜ「決める」が遅くなるのか

AI駆動開発では、顧客との合意のタイミングが根本的に変わっている。

従来の開発では「仕様書を読んで承認する」という合意の型があった。仕様書が上がってきたとき、顧客は時間をかけて読み、コメントを入れ、最終的にサインする。この型には顧客も慣れている。

AI駆動開発では「動いているものを見て、その場で判断する」という合意の型が求められる。プロトタイプを見て、使ってみて、「これはこう変えてほしい」をその日中に返す。顧客がこの型に慣れていないと、動くものを見ても「いったん社内で検討します」という週次定例の判断を待つことになる。

これが承認待ちの正体だ。

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

当社でAI駆動開発を使って受託システムを構築したプロジェクトでは、実装タスクが200件を超えた（詳細はこちらの事例を参照）。タスク管理の設計が機能し、200件で漏れゼロで完走できた。

一方で、最も時間がかかったのは顧客との合意形成だった。

画面の仕様について「Slackで議論→議事録メール→翌週の定例で確認」というフローが残っていた部分は、実装完了からリリースまでに2週間以上かかった。これに対して、タスクのコメント欄で顧客が直接フィードバックを書くフローに変えた画面は、同じ合意が2日で取れた。

差を生んだのは、ツールよりも「顧客が何かを見て・判断して・返す」というサイクルの設計だった。

なぜ承認待ちが生まれるのか — 3つの構造

承認待ちの原因は顧客の怠慢ではなく、確認の単位・場所・権限の3つの設計不足にある。

1. 確認の単位が大きすぎる

週次定例で「先週の実装まとめて全部確認してください」は、顧客に多大な認知負荷をかける。見るものが多いほど、判断は先延ばしされる。

2. 確認の場所が分散している

「Slackで質問→メールで仕様確認→定例で最終決定」のように、確認に関連するやり取りが複数の場所にある状態では、顧客はどこに何の判断が残っているかを把握できない。

3. 返答に権限が必要な質問が混ざっている

「この画面のレイアウトはこれでいいですか」と「この仕様変更に追加費用は発生しますか」を同じタイミングに聞くと、後者の回答に上長の判断が必要となり、前者の確認も止まる。

「決める」を速くする3つの変え方

変え方1: 確認の単位を小さくする

1画面・1機能ごとに確認を取る。まとめて確認するより、「この機能できました。これだけ見てください」という小さい単位の方が、顧客は即日返せる。

タスクが完了したら、そのタスクのコメント欄に「確認お願いします」と書いて顧客に通知する運用にすると、週次定例を待たずに承認サイクルが回る。

変え方2: 判断の権限を事前に整理する

プロジェクト開始時に「この種類の判断は担当者で決めてよい」「これは決裁が必要」を確認しておく。仕様の細部は担当者権限、追加費用が発生する変更は決裁必要——この区別が明確なプロジェクトは、承認待ちが極端に短い。

変え方3: 顧客をタスク管理ツールに巻き込む

顧客が確認・フィードバックをタスクのコメントに直接書ける環境を作ると、Slackの流れに埋もれず、いつ確認が完了したかが記録として残る。

Paqutでは顧客（外部メンバー）を何人招待してもPro ¥2,980/月のフラット料金で追加費用がかからない。顧客を招待することへのコスト的な障壁がない分、プロジェクトごとに迷わず導入できる（タスク管理ツールの外部ゲスト招待コスト比較）。

AI駆動開発で変わること・変わらないこと

AIの登場で「作ること」の速度は変わった。「決めること」の速度は、設計しない限り変わらない。

承認フロー・確認の単位・顧客との合意の型——これを意図的に変えなければ、実装が1日で終わっても、プロジェクト全体は旧来のペースで動く。

速く作れる環境を手に入れたとき、次に問われるのは「決める速度」をどう設計するか、だ。

関連記事

AI駆動開発の全体像：AI駆動開発の進め方 完全ガイド — 従来型と何が変わるか

タスク漏れゼロの運用事例：タスクは200個を超えた。それでも、ひとつも落ちなかった。

顧客との確認依頼の設計：外注先への「確認メール」が週3通を超えたら、依頼設計を疑う

外部メンバーへの最初のタスク：外部メンバーへの最初のタスクが、関係の質を決める