AI駆動開発で変わるシステム発注｜ツールと見積り・契約の見方

システム開発の見積書には、たいてい「人月」という単位で金額が書かれています。エンジニア1人が1か月働く量を単位にして、そこに単価を掛ける値付けの方法です。

この方法には、次のような決まりごとが付いてきました。

• 作り始める前に、仕様を固める
• 途中で変えると、追加の費用がかかる
• 動くものを見られるのは、契約から数か月あと

要件定義書に押印を求められ、内容がよく分からないまま承認したことのある方もいるはずです。人が1行ずつコードを書いていた時代は作り直しに時間がかかったため、先に決めておく必要がありました。

その前提が、AIがコードを書くようになって大きく変わりました。作り直しの手間が下がり、試作を先に見てから仕様を決める進め方が取れるようになっています。

AIに実装や確認の多くを任せる開発は、国内では「AI駆動開発」と呼ばれることが多くなりました。作る側の話に聞こえますが、影響を受けるのは発注する側です。

この記事では、AI駆動開発で見積り・納期・契約の何が変わるかを、中小企業の経営者の方に向けて整理します。

AI駆動開発で発注の何が変わるか

先に答えをお伝えします。同じ規模のシステムを作るのにかかる時間は、コードを書く工程を中心に短くなりました。

以前もAIがコードを書くことはありましたが、役割は1行ごとの入力補完にとどまっていました。今は、複数のファイルにまたがる修正をまとめてAIに任せられます。

発注する側から見た違いを、表にまとめます。

項目	これまで	AI駆動開発では
仕様の決め方	作り始める前に細部まで固める	動く試作を見ながら決める
画面を見られる時期	契約から数か月あと	提案や打ち合わせの段階から
見積りの中身	実装の工数が中心	聞き取り・例外の洗い出し・確認の比率が上がる
納期を決めるもの	開発の作業量	発注する側の確認と判断の速さ
開発の体制	数人から十人ほど。再委託も多い	少人数で進める例が出てきている
仕様変更	手戻りの費用が高い	安くなるが、業務の整理と確認の手間は残る

ただし、すべての工程が同じ割合で速くなったわけではありません。速くなった工程と、変わらない工程があります。

米国の研究団体METRが2025年7月に公表した調査では、経験のある開発者16人が246件の課題に取り組み、AIツールを使ったほうが19%長くかかりました。

本人たちは、20%速くなったと感じていたそうです（METR）。

時点と条件の限られた調査ですが、AIを使えば何でも速くなるわけではないことを示しています。この違いを知らずに発注すると、期待と実際の間にずれが生まれます。

AI駆動開発とは？

AI駆動開発は、AIに実装やテストの多くを任せ、人は指示と確認を担う開発の進め方です。公的な定義はなく、会社によって指す範囲が少し違います。

AIがコードを書くこと自体は、以前からありました。これまでの流れを年表で振り返ると、今の立ち位置が分かります。

時期	主な技術	変わったこと
2000年代	開発環境の入力補完、雛形の自動生成	コードを打ち込む手間が減る
2010年代	ノーコード・ローコード	簡単なアプリなら、エンジニアでなくても作れるように
2021年	GitHub Copilot	書きかけのコードの続きを、AIが予測して示す
2022年	ChatGPTの公開	ふつうの言葉の指示で、コードを作れるように
2023年	AIを組み込んだ開発環境の広がり	ファイル単位でのコードの生成・修正が日常に
2024年	自分で直すAIエージェントの登場	複数のファイルにまたがる修正を、AIが進める
2025年	Claude Code、Codex、GitHub Copilotのエージェント、Antigravity	人の役割が「書く」から「指示と確認」へ
2026年	複数のAIエージェントの分担	設計・レビュー・テストまで自動化が広がる

2021年から2024年までの変化は、主にコードを書く速さの改善でした。2025年以降は、開発で人が担う役割そのものが変わりつつあります。

複数のAIに工程を分担させる考え方は、マルチエージェントシステムとは？で説明しています。

人が書き、AIが補う開発

数年前までのAIの使い方は、キーボード入力の補助が中心でした。書きかけの行の続きを示したり、関数の使い方を教えたりする段階です。

便利ではあるものの、コードを書いて組み立てていたのは人でした。AIの効果は、入力の手間が減る範囲にとどまっていました。

AIが書き、人が確かめる開発

今起きているのは、その先の変化です。たとえば「この画面に検索機能を追加してほしい」と指示すると、AIが関連するファイルを探し、複数の箇所をまとめて書き換えます。

さらにプログラムを動かし、エラーが出れば原因を調べて直すところまでAIが進めます。人の役割は、AIに適切な指示を出し、上がってきた成果物を確かめることに移りました。

このようにAIエージェントに作業を主導させる開発のやり方を、エージェンティックコーディング（agentic coding）と呼びます。

Anthropicは Claude Code を「agentic coding tool」と説明しており、AI駆動開発の中心にある手法です。

AI駆動開発の主なツール

AI駆動開発でよく使われるツールを表にまとめます。どれも人が1行ずつ書くことを前提にせず、人が指示を出し、AIの出力を確かめる前提で作られています。

ツールの機能は2026年9月時点の公式情報です。更新が速い分野なので、使う前に各社のページで確かめてください。

ツール	提供元	使う場所	特徴
Claude Code	Anthropic	ターミナル、VS Code・JetBrains、デスクトップアプリ、ブラウザ	コードを読み、複数のファイルを書き換え、コマンドを実行する。作業を複数のエージェントに分担させられる
Codex	OpenAI	コマンドライン、エディタの拡張機能、アプリ、クラウド	クラウドで複数の作業を並行して進められる。ChatGPTの有料プラン（Plus・Pro・Business・Edu・Enterprise）に含まれる
GitHub Copilot	GitHub	エディタ、GitHubの画面	課題（Issue）を任せると、調べて計画を立て、ブランチでコードを変える（クラウドエージェント）。有料プランで使える
Antigravity	Google	デスクトップアプリ	2025年11月に公開。2026年5月の2.0で単独のアプリになり、複数のエージェントを並行して動かせる

Claude Code は、当社でも開発のメインツールとして使っています。下の画面は、エディタ（VS Code）の中で Claude Code を開いたところです。

Codex は、手元のパソコンで作業を続けなくても、クラウドで作業を進めておける点が特徴です。

GitHub Copilot は入力補完から始まったツールで、今は課題を任せて、プルリクエスト（変更の提案）を作らせる使い方もできます。

Antigravity は、エージェントの作業を実装の計画やスクリーンショットなどの形で示します。人はそれを見て確かめ、コメントで直しを頼めます。

発注先がどのツールを使うかより、AIが書いたコードを誰がどう確かめているかのほうが品質に直結します。確かめ方は、後の「安い見積りの見極め方」で紹介する質問で聞いてください。

設計や確認の工程にも広がった

速くなったのは、コードを書く工程だけではありません。画面の試作、要件の整理、レビューとテストでも、AIが受け持つ範囲が広がっています。

画面の試作

Figma Make のようなデザインツールでは、言葉で指示するだけで、画面のデザインだけでなく実際に操作できる試作まで作れるようになりました。

作った試作は React のコードで書かれていて、中身を開いて確かめられます。デザイナーが作った画面を、エンジニアが見ながら一から組み直す手間は小さくなりました。

下の画面は、Figma Make に作業管理アプリの画面を頼み、2回のやり取りで作った試作です。

要件の整理

打ち合わせの雑多なメモから、開発できる作業の単位に分けた指示書を作れるようになりました。たとえば、ヒアリングで出た次のような断片を渡すと、開発の順番に沿った仕様の指示書にまとまります。

• 取引先ごとに、請求書の書式が違う
• 承認の権限は、工場長にある

その指示書をAIに読み込ませれば、実装の多くまで進められます。要件の整理と実装が、切れ目なくつながったと言えます。

AIがまとめた指示書は、聞き取った内容の範囲でしか正しくありません。抜けている例外がないかは、業務を知る人が読んで確かめてください。

レビューとテスト

作ったコードの確認でも、AIが受け持つ範囲が広がっています。人がすべてを目で見て確かめなくても、次の作業はAIに任せられます。

• 見落としたロジックの不具合の指摘
• 考えが漏れた例外の条件の洗い出し
• 自動テストのコードの作成

それでも、リリースしてよいかの最終判断は人が担います。

Stack Overflow の2025年の開発者調査では、AIツールを使っているか使う予定の人が84%いる一方、AIの出力の正確さを信頼しない人が46%でした（Stack Overflow Developer Survey 2025）。

同じ調査で、AIへの不満の1位は「ほぼ正しいが、完全ではない答え」（66%）です。AIが書いたコードを人が確かめる工程は、今も欠かせません。

発注する側に起きる変化

ここからが、発注する側にとっての本題です。仕様の決め方、進め方、開発の体制が変わります。

動く試作を先に見られる

これまでの開発は「要件定義→設計→実装」の順に進むため、発注から数か月は実際の画面を見られないのが普通でした。今は、この順番を入れ替えられます。

当社では、ヒアリングに伺った当日に、実際に動く試作をお見せすることがあります。完成品ではありませんが、触れる画面があると、打ち合わせで話せる内容が具体的になります。

たとえば、次のような声がその場で出てきます。

• 「この入力項目は、うちの現場では使わない」
• 「この画面の順番だと、作業する人が迷う」

紙の仕様書では気づけなかった課題が、早い段階で見つかります。納品されてから「使えない」と分かる失敗を防げるのが、発注する側にとっての大きな利点です。

作りながら決められる

これが、いちばん大きな変化です。これまでは開発途中の仕様変更に伴う手戻りの費用が高いため、発注前に細部まで仕様を固める必要がありました。

今は、動くものを見て、直し、また確かめるサイクルを回す費用が下がりました。「よく分からないまま、システム会社の提案どおりに決めてしまう」発注を避けやすくなっています。

作りながら決める進め方の契約は、IPA（情報処理推進機構）のアジャイル開発版 情報システム・モデル取引・契約書が参考になります。

成果物の完成ではなく、専門家として作業すること自体に対価を払う準委任契約を前提にしたひな形です。

開発チームが少人数になる

開発チームの人数も変わります。当社が見聞きする範囲では、以前なら数人から十人ほどで進めていた規模の案件を、1〜2人で進める例が出てきています。

少人数になると、発注する側には次の変化があります。

1. 伝言のロスが減る：仕様書を作って共有し、認識のずれを直す作業が小さくなる
2. 再委託が減る：実装をAIが受け持つため、協力会社や海外の拠点に回す必要が薄れる
3. 判断が止まりにくい：判断する人が実装も兼ねるため、キーマンを待つ時間が減る

大きなチームでは、「作る時間」より「伝える時間」のほうが長くなることもありました。少人数なら、口頭やチャットの確認で済む場面が増えます。

当社では、海外の開発拠点に頼る開発のやり方は、今後小さくなっていくと見ています。外に回す工程が減れば、伝言による仕様の間違いや、品質のばらつきも減ります。

担当者が抜けたときの備え

少人数には弱点もあります。関わる人が少ないため、開発の知識や業務の知識が個人の中にとどまり、属人化しやすくなります。

担当者が事故や退職で抜けたときの影響は、これまでより大きくなります。契約の前に、担当のエンジニアが動けなくなったときの代わりの体制を必ず確かめてください。

設計の記録や、AIに渡した指示書も納品物に含めてもらうと、別の技術者が引き継ぎやすくなります。

自社の業務の側で属人化を減らす手順は、業務の属人化解消の進め方で紹介しています。

見積り・納期・仕様変更はどう変わるか？

発注のときに気になる三つの点を整理します。どれも、AIで速くなる工程と、人が担う工程を分けて考えるのがポイントです。

見積りは聞き取りと確認の比率が上がる

コードを書く時間が短くなった分、見積りの中でほかの工程の比重が増しています。具体的には次の三つで、どれもAIではなく人が責任を持つ領域です。

• 業務の流れの聞き取り
• 例外の洗い出し
• テストと動作の確認

見積書では、実装費だけでなく、業務の理解と確認にどれだけの工数を割いているかを見てください。実装費が安くても総額がそれなりにある場合は、業務の理解と確認に時間を取っている表れであることが多いと考えています。

業務システムの人月単価の目安と、費用を予算内に収める方法は次の記事で紹介しています。

納期は発注側の確認で決まる

システムを作る速さは上がりました。一方で、発注する側が画面を確かめ、現場に聞いて判断する時間は変わりません。

ここが、プロジェクト全体の最短の納期を決めます。社内で「誰が、いつ確かめるか」を先に決めておかないと、確認待ちで作業が止まり、AIで速く作れる利点が生きません。

仕様変更は安くなるが無料ではない

開発途中の仕様変更の費用は、以前ほど高くならなくなりました。それでも、無料になったわけではありません。

コードの書き換えは安くなっても、業務の流れの整理と、新しい仕様の確認という人の作業は残るからです。「後からいくらでも変えればいい」と考えると、プロジェクトがいつまでも終わらなくなります。

これからの発注の進め方

開発のやり方が変わったので、発注する側の頼み方も変えていく必要があります。ここでは、頼み方で変えたい四つの点を紹介します。

小さく始めて広げる

最初から全社の基幹システムを丸ごと発注する必要はありません。まずは「請求書の発行だけ」のように対象を絞って作り、使って効果を確かめてから範囲を広げる進め方が取りやすくなりました。

効果が出なかった場合も、小さな投資で引き返せるため、経営上のリスクを抑えられます。

安い見積りの見極め方

今後は、「相場の半額」のような安い見積りを出す業者が増えていくと見ています。その安さがAIで効率化した結果なのか、テストやレビューを省いた結果なのかは、総額だけでは分かりません。

見極めるために、次の四つを聞いてみてください。

• AIが書いたコードのレビューとテストを、どう行っているか
• ヒアリングで、業務の例外について具体的に質問してくるか
• 担当者が動けなくなったときの、代わりの体制があるか
• 同じやり方で作ったシステムの実績を見せられるか

答えの聞き分け方を、例で示します。

聞くこと	具体的な答えの例	気をつけたい答えの例
レビューとテスト	自動テストを動かし、人が変更点を読んでから反映する	「AIが確認するので大丈夫です」
例外の質問	「返品や値引きのときは、誰が承認しますか？」と聞かれる	例外の話が一度も出ない
代わりの体制	設計の記録を残し、もう1人が引き継げる	「担当者が責任を持ちます」だけ
実績	同じやり方で作った画面を触らせてもらえる	資料だけで、画面を見せてもらえない

AIを使って正しく費用を下げている会社なら、これらの質問に具体的に答えられるはずです。

相見積りは内訳で比べる

複数の会社から見積りを取るときは、総額だけでなく内訳を見てください。実装費、業務の聞き取りの費用、定着支援の費用の配分に、その会社の姿勢が表れます。

実装費だけが極端に安い見積りは、動くものを納品して終わりになるおそれがあります。聞き取りや定着支援に費用を割いている会社は、総額が高く見えても、結果として手戻りが少なくなりやすいと考えています。

仕様変更とデータの扱いを契約で決める

開発が進めば、仕様は変わります。変わることを前提に、どこまでが契約の範囲に入るかを最初に決めておきましょう。

AI駆動開発では、発注先が自社の業務データや既存のコードをAIツールに渡して作業します。次の点も、契約の前に確かめてください。

• 渡したデータが、AIの学習に使われない設定や契約になっているか
• パスワードやAPIキーなど秘密の情報を、AIに渡さない決まりがあるか
• 作ったコードの権利が、どちらにあるか

社内のデータをどこまでAIに渡してよいかは、生成AIに社内データを渡していい範囲で整理しています。

保守の範囲、修正の頼み方、対応の期間など、契約前に確かめることは次の記事で詳しくまとめました。

まとめ

AIがコードを書くようになり、発注する側は「すべて決めてから頼む」必要がなくなりました。その代わりに、自社で確認する時間と、確かめる人を用意することが大切になります。

試作から始める進め方について相談したい方は、下のご案内をご覧ください。