生成AIに仕様を渡す。少し待つ。すると、画面やコードのたたき台が返ってくる。
初めて見ると、かなり驚く。以前なら数日かけていた作業が、その場で形になるからです。これならシステム開発も一気に速くなる。そう考えるのは自然な流れです。
ただ、企業のシステム開発では、ここから先が長い。
何を作るのか。どの要望を優先するのか。現場の業務をどこまで変えるのか。動くものが早く出てきても、会社として決めるべきことまで自動で決まるわけではない。
AIが変えるのは、開発に必要な時間の総量だけではない。これまで実装待ちの陰に隠れていた「決める時間」まで、かなり見えやすくなる。
ここからは、AI支援開発に関する公開調査と、発注・要件整理・プロジェクト推進で起きる一般的な場面をもとに考えていきます。特定の製品や開発手法の優劣が論点ではありません。
コードが速く書けても、開発はかえって遅くなることがある
生成AIがコード作成を支援し、開発者個人の作業を軽くする。これは、すでに多くの人が実感している変化です。
DORAの2025年調査では、回答した技術職の90％が仕事でAIを使い、80％超が生産性の向上を感じていました。一方で、AIの利用拡大は、ソフトウェアの提供量だけでなく不安定さの増加とも関連していました。
ここは少し丁寧に切り分けた方がよさそうです。
個人が速くコードを書けることと、組織が速くシステムを届けられることは別物です。作られる変更が増えれば、レビュー、テスト、セキュリティ確認、リリースにも仕事が流れ込む。前工程だけが速くなれば、後工程に仕事がたまる。開発の現場では、特に珍しい話でもない。
AIによる速度向上は、対象者や作業によっても変わります。METRは、経験豊富なオープンソース開発者16人を対象に実験しました。2025年初頭のAIツールを使った246件の作業では、所要時間が平均19％長くなっています。
もちろん、この数字を現在の開発全般へ当てはめることはできません。対象は特定の開発者と既存リポジトリで、AIツールも当時のものです。METR自身も、その後のツール進化を踏まえ、現在の速度向上を同じ方法で測る難しさを説明しています。
つまり、「AIは速い」「AIは遅い」という二択ではない。
AIで短くなる作業があっても、その短縮がプロジェクト全体へそのまま反映されるとは限らない。開発側が一日に作れる量だけ増やしても、確認と判断が以前と同じ速度なら、仕事は別の場所にたまる。
AIがプロジェクトを遅くするというより、もともとあった別の遅さを、AIがあぶり出す。こちらの見方の方が実態に近いでしょう。
AIが減らすのは「作る時間」、むき出しになるのは「決める時間」だ
開発にかかる時間を、少し乱暴に二つへ分けてみます。
一つは、設計書、コード、テスト項目など、成果物を「作る時間」。もう一つは、次へ進むために「決める時間」。
要件を確認する。関係部署の意見をそろえる。複数の案から一つを選ぶ。予算を承認する。例外をどこまで認めるか決める。完成した機能を誰が受け入れるか決める。こうした仕事は、コードを書く作業とは性質が違う。
実装に時間がかかっていたときは、判断が多少遅れても、その間に開発側が設計や実装を進められる場合がありました。実装待ちと判断待ちが重なり、どこで本当に時間を使っているのか見えにくかった。
AIによって実装のたたき台が早く出ると、この関係が変わる。
昨日依頼したものが、今日には確認できる。ところが、確認する側の会議は来週のまま。三つの選択肢を作る時間は短くなったのに、どれを選ぶ人か決まっていない。画面は動いているのに、部署ごとに異なる運用を統一する話は進んでいない。
この状態では、AIが生み出した速度をプロジェクトが受け止めきれない。速くなった「作る時間」の先で、「決める時間」が列を作る。
何時間でコードを生成できたかだけを見ても、開発全体の速さは分からない。依頼から判断までに何日かかったのか。判断材料はそろっていたのか。誰が何を決めるのか明確だったのか。
実装速度が上がるほど、こうした素朴な問いが効いてくる。
「こんなものがほしい」は、AIに渡せる要件ではない
「問い合わせ対応へ生成AIを使いたい」「売上を予測できる画面がほしい」。あるいは、「いまExcelで行っている業務をシステム化したい」。
どれも検討の出発点です。ただし、そのままでは要件にならない。
現場では、この一線がよく曖昧になります。
問い合わせ対応なら、誰からの問い合わせに、どの情報を使って、どこまで自動で答えるのか。回答が間違っていたら誰が確認するのか。どの水準なら業務で使えると判断するのか。
売上予測なら、誰がどの判断に使うのか。どの程度の誤差を許容するのか。予測が外れた場合にどう扱うのか。決めるべきことは、機能名の外側にある話です。
AIなら、曖昧な要望からでも、もっともらしい仕様案を作れます。ただ、この便利さには小さな落とし穴もある。
仕様案が流暢で詳しいほど、もとの前提まで正しいように見える。しかしAIは、その会社の事情を踏まえて、何を優先し、どのリスクを受け入れるべきか決めたわけではない。
発注側に必要なのは、最初から完璧な要件定義書を書くことではない。少なくとも、次の問いに答えられる状態は必要です。
- どの業務上の問題を変えたいのか
- 誰が使い、何が変われば成功なのか
- 絶対に守る条件と、見送ってよい要望は何か
- 例外が起きたとき、誰が判断するのか
- 導入後の運用と改善を誰が担うのか
ここが決まっていなければ、AIへ詳しい指示を書いても、精密な文章で曖昧さを包むだけになりかねない。
「こんなものがほしい」を「会社としてこれを選ぶ」へ変える。この仕事は、プロンプトを書くより前に始まっている。
実装が速いほど、未整理の業務と責任が一気に表へ出る
動くものを早く見られる。それ自体は、かなり大きな利点です。抽象的な議論だけでは気づかなかった問題も、画面や試作品を見れば具体的に話せる。
ただし、試作品が早く出ることと、意思決定が進むことは別の話。
営業部門は入力項目を減らしたい。管理部門は記録を詳しく残したい。経営層は全社の数字を一つの形式で見たい。どの要望にも理由はありますが、すべてを同時に満たせるとは限りません。
優先順位を決めないまま修正を続けると、AIによって変更が容易になった分だけ、案が増える。A案を試し、B案も作り、念のためC案も残す。作る負担が小さいため、見送る判断まで先送りしやすい。
ユーザー受入テストでも似たことが起こる。本来は、合意した要件どおりに業務で使えるかを確認する場です。
ところが、部署ごとの業務手順や例外時の対応が整理されていないケースもある。データの責任者まで曖昧なら、テストを始めてから業務上の論点が次々に見つかる。
少し厳しい言い方ですが、完成確認のはずのテストが「遅れて始まった要件定義」に変わってしまう。
実装が遅い時代には、試作品が出るまで判断を保留できました。実装が速くなると、その余白は小さくなる。
技術が仕事を急かすわけではない。これまで後回しにできた業務と責任の整理が、より早い段階で求められるようになる。
AIに任せるべきは判断ではなく、「判断の渋滞整理」だ
会社としての判断をAIへ委ねられない。だから発注側ではAIを使えない。そこで話を終える必要はない。
むしろ、判断そのものより、判断できる状態を作るまでの作業に、大きな活用余地がある。
複数の会議記録と要望一覧から、重複する要望、対立する条件、未決事項を分ける。現行業務と変更後の業務を並べ、影響を受ける部署と確認事項を洗い出す。複数案を費用、効果、リスク、運用負荷で比較する。次の会議で聞くべき質問を準備する。
このあたりはAIが得意です。しかも、人がゼロから資料を作るよりずっと速い。
JUASの2025年度研究資料でも、生成AIの活用には要件を構造化して伝える力が必要だとされています。あわせて、業務文脈から出力の妥当性を判断する知識や、出力を評価・修正する力も挙げられました。
一方で、最後の判断は残る。
AIは選択肢を並べられますが、売上と現場負荷のどちらを優先するかは決められない。リスクを説明できても、そのリスクを会社として受け入れるかは決められない。一般的な業務フローを提案できても、自社の例外業務を廃止してよいかまでは決められない。
AIには、論点を見つけ、比較し、決定事項と未決事項を分けてもらう。人は、その材料を使って選び、理由を説明し、結果に責任を持つ。
少し地味に見えるかもしれません。しかし、これが実務で効くAIの使い方です。「答えを出してもらう」より、「決められる状態を作ってもらう」。この役割分担なら、AIは決める時間をかなり短くできる。
開発速度を決めるものは、コード生成力から意思決定力へ移る
AIによって、システムを作る技術的な負担は軽くなっていくでしょう。コード、仕様書、テスト項目、調査結果のたたき台を作る速度も、まだ上がっていくはずです。
それでも、システム開発から人の仕事が消えるわけではない。
実装が速くなるほど、何を作るかを定める仕事が前面に出る。複数の利害を整理し、業務を変え、投資の妥当性を説明する仕事も、開発速度を左右する。
発注側で要件整理やベンダーとの調整に携わってきた人ほど、その価値を見落としがちです。「会議が多い」「調整ばかり」と捉えているかもしれません。
実際に行ってきたのは、現場の言葉を開発側へ渡せる形に変える仕事です。対立する要望へ優先順位を付け、経営層が判断できる材料もそろえてきた。これは、かなり価値のある経験です。
AIがコードを作る時代になっても、その価値は消えない。むしろ、AIが生み出す速度を組織の成果へ変えるために、重要性が増す可能性がある。
すべてを一人で担った実績がなくてもいい。現場の要望を整理した。仕様の前提を確認した。見送る機能の理由を説明した。そうした行動の一つひとつが、意思決定を前へ進めた経験になる。
AIでシステム開発がどこまで速くなるか。その答えは、AIがどこまでコードを書けるかだけでは決まらない。
AIによって作る時間が短くなったとき、会社がどこまで速く、納得できる形で決められるか。次に問われるのは、そこではないでしょうか。
発注・要件定義・調整の経験を、転職市場でどう捉えるか。関連記事で掘り下げています。
AIと専門知識の関係については、こちらも参考にしてください。
参考資料
- DORA「State of AI-assisted Software Development 2025」
- DORA「Balancing AI tensions: Moving from AI adoption to effective SDLC use」
- METR「Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity」
- METR「We are Changing our Developer Productivity Experiment Design」
- JUAS「システム開発・保守QCDs研究会2025」
