エージェンティックコーディングで開発はこう変わる｜中小企業のシステム発注の新常識

システム開発の見積書には、たいてい「人月」という単位で金額が書かれています。

エンジニアが1人で1か月働く量を単位にして、そこに単価を掛ける。長く使われてきた値付けの方法です。

この方法には、いくつもの決まりごとが付いてきました。

作り始める前に、仕様を固めること。途中で変えると追加の費用がかかること。動くものを見られるのは、契約から数か月あとになること。要件定義書に押印を求められ、内容の意味がよく分からないまま承認したことのある方もいるはずです。

どれも、理由があってそうなっていました。人が1行ずつコードを書いていた時代は、作り直しに時間がかかったからです。だから先に決めておく必要がありました。

その前提は、いまは完全に崩れています。

AIがコードを書くようになり、作り直しの手間が下がりました。試作を先に見せられるようになり、最初に仕様を決定してから発注する必要が薄れました。開発に関わる人数も減っています。

すべて作る側の話に聞こえるかもしれません。ただ、影響を受けるのは発注する側です。見積書の読み方、納期の考え方、契約の切り方。どれも、これまでの常識のままでは判断を誤ります。

---

開発スピードは、もはや別次元になった

先に結論からお伝えします。

同じ規模のシステムを作るために必要な時間が、目に見えて短縮されました。 この変化は、2024年ごろから急速に進みました。

AIがコードを書くこと自体は以前からありました。しかし、当時の役割は「1行ごとの入力補完」にとどまっていたのです。それが現在では、複数のファイルにまたがる複雑な修正も、まとめてAIに任せられるようになりました。 この違いが、実際の開発時間に圧倒的な差を生んでいます。

ただし、すべての工程が同じ割合で速くなったわけではありません。「劇的に速くなった工程」と「従来と変わらない工程」が存在します。 この違いを理解しないまま発注してしまうと、期待と現実に大きなギャップが生じてしまいます。

---

開発の自動化は、どこまで進んだか？

この変化は、決して2026年から突然始まったわけではありません。

歴史を順に振り返ると、現在の立ち位置がよく分かります。

時期	主なテクノロジー	何が変わったのか
2000年代	開発環境の入力補完、雛形の自動生成	コードを打ち込む手間そのものが減少
2010年代	ノーコード・ローコード	簡単なアプリなら、非エンジニアでも作成可能に
2021年	GitHub Copilot	書きかけのコードの続きをAIが予測して提示
2022年	ChatGPTの公開	自然言語による指示ででコードの生成が可能に
2023年	AI統合型開発環境の普及	ファイル単位でのコード生成・修正が日常化
2024年	自律修正型AIの登場	複数ファイルをまたぐ修正をAIが自力で完結
2025年	Claude Code、Codex、Antigravity	人間の役割が「記述」から「指示と確認」へシフト
2026年	複数AIエージェントの協調運用	設計・レビュー・テストなど開発全工程へ自動化が拡大

2021年から2024年までの進化は、主に「コードを書くスピードの改善」でした。しかし2025年以降は、「開発における人間の役割そのもの」が大きく変わりつつあります。

---

エージェンティックコーディングとは？

現在、開発の現場で具体的に何が起きているのかを解説します。

従来の「人が書き、AIが補う」開発

数年前までのAI活用は、あくまでキーボード入力の補助が中心でした。

書きかけの行を予測して提示したり、関数の使い方を教えてくれたりする段階です。便利ではあるものの、実際にコードを書いているのは人間でした。この段階での作業効率化は、せいぜい1割〜2割程度の改善にとどまります。

現在の「AIが書き、人が確かめる」段階

今起きているのは、その先にある大きなパラダイムシフトです。

例えば「この画面に検索機能を追加してほしい」と指示するだけで、AIが自ら関連するファイルを特定し、複数箇所のコードをまとめて書き換えます。さらにプログラムを実行し、エラーが出れば自分で原因を突き止めて修正するところまで進めます。

ここで人間の役割は、「AIに適切な指示を出し、上がってきた成果物を検証すること」に移りました。このようにAIエージェントに主導させる開発スタイルを、「エージェンティックコーディング」と呼びます。

現在、代表的なツールには次の3つがあります。

Claude Code（Anthropic社）
ターミナルやエディタから操作するAIエージェント。当社でもメインツールとして活用しています。

Codex（OpenAI社）
クラウド上で複数の作業を並行して進められる強力なエージェントです。

Antigravity（Google社）
2025年11月に公開されたIDE（統合開発環境）で、複数のAIエージェントを同時に動かし、その作業を人間がリアルタイムで監視・確認しながら進められます。

いずれも「人間が1行ずつコードを書くこと」を前提としていません。「人間が指示を与え、AIの出力を確認する」という前提で設計されたツールです。開発費用の値付けや構造が変わった最大の理由は、この前提の違いにあります。

当社でもこの手法を全面的に導入して開発を行っています。

---

自動化はコード記述の全工程に広がった

スピードアップしたのは、プログラミングの工程だけではありません。システム開発におけるすべての工程で作業効率が劇的に向上しつつあります。

デザインとプロトタイピング

Figma Makeのような高度なデザイン生成ツールの登場により、言葉で指示するだけで、画面デザインだけでなく「実際に操作できるプロトタイプ」まで即座に作成できるようになりました。

さらに、そのデザインからReactなどのフロントエンド部品コードを直接抽出できます。従来のように「デザイナーが作った画面を、エンジニアが目で見て1から組み直す」という手間が大幅に短縮されました。

要件の整理・タスク化

打ち合わせでの雑多なメモから、開発可能な作業単位へと指示書を自動整理できるようになりました。

例えば、ヒアリングで出た「取引先ごとに請求書の書式が異なる」「承認権限は工場長にある」といった断片的な情報を渡すだけで、開発順序に沿った仕様指示書へとまとめ上がります。

その指示書をそのままAIに読み込ませれば、一気に実装の大部分まで完了します。つまり、「要件の整理」と「実際の装入・実装」が地続きでつながったのです。

レビューとテスト

作成したコードの検証作業も、AIがカバーする範囲が広がっています。

ロジックの不具合の見落とし、考慮漏れのある例外条件の指摘、自動テストコードの作成など、人間がすべてを目視で確認する必要はなくなりました。ただし、最終的にリリースしてよいかの判断は、依然として人間が担います。 この点については後述します。

---

発注側にとって、何が変わったのか？

技術的な解説はここまでです。ここからが発注者様にとっての本題となります。

提案段階で「動く試作」を先に見られる

従来の開発では、「要件定義」→「設計」→「実装」という手順を踏むため、発注から数か月間は実際の画面を一切見られないのが普通でした。

しかし現在では、その順序を逆転させることができます。

当社では、ヒアリングにお伺いした当日に「実際に動くプロトタイプ」をお見せすることができます。 当然、完成品ではありません。しかし、実際に触れる画面があることで、打ち合わせの解像度が格段に上がります。

「この入力項目はうちの現場では使わない」「この画面遷移だと作業者が混乱する」といった、紙の仕様書では気づけなかった課題がその場で浮き彫りになるのです。

これは発注側にとって非常に大きなメリットです。仕様書の文字情報だけで「自社の業務に合うか」を想像で判断し、いざ納品されてから「使えない」と判明する——そうした悲劇を未然に防ぐことができます。

「すべて決めてから頼む」必要がなくなった

これこそが、最も本質的な変化です。

従来は、開発途中の仕様変更に伴う「手戻り費用」が高額になるため、発注前に細部まで完璧に仕様を固める必要がありました。

しかし現在は、「作りながら試して決める」アプローチが可能です。動くものを見て、修正し、また確認する。このサイクルを回すコストが極めて低くなったためです。

結果として、「よく分からないから、システム会社の提案通りに決めてしまった」というようなリスクの高い発注を回避できるようになりました。

---

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

発注時に気になる3つのポイントを整理します。

見積り：実装以外の「聞き取り・検証」の比率が上がる

コードを書く時間が大幅に短縮された分、見積りの内訳において他工程の重要度・比重が増しています。

具体的には、「業務フローの聞き取り時間」「例外処理の洗い出し」「テストおよび動作確認の時間」です。これらはAIではなく、人間が責任を持って行うべき領域です。

見積書を確認する際は、実装費用だけでなく「業務理解や検証にどれだけの工数が割かれているか」をぜひチェックしてください。実装費が安くても全体の金額が一定規模ある場合、それは不当に高いのではなく「業務を深く理解するための時間をしっかり確保している良質な会社」である可能性が高いのです。

納期：開発は短縮されるが「顧客側の確認時間」は減らない

システムを作るスピードは劇的に上がりました。

一方で、「発注側が画面を確認し、現場にヒアリングして判断を下す時間」は従来と変わりません。 実はここが、プロジェクト全体の最短納期を決定づける要因となります。

どれだけ短納期を提示されても、社内で「誰が・いつ確認作業を行うのか」を事前に定めておかなければ、確認待ちで作業がストップし、AI開発のスピード感という恩恵を享受できなくなってしまいます。

仕様変更：変更コストは下がるが、無制限ではない

開発途中の仕様変更コストは、以前ほど高くならなくなりました。

しかし、決して「タダ」になったわけではありません。コードの書き換えコストは下がっても、「業務フローの再整理」や「新たな仕様の確認」という人間の作業は発生するからです。「いくらでも後から変えればいい」と安易に考えると、プロジェクトの収束がつかなくなります。

開発チームは「少数精鋭」になる

もうひとつ、発注者様に直接影響する大きな変化があります。開発チームの人数規模です。

以前なら5人〜10人の体制で臨んでいた開発案件も、今や1人〜2人の少人数で十分に回せるようになりました。

打ち合わせや伝言ゲームのロスが消える

大規模なチームでは、「伝言と管理」のための作業が莫大になります。仕様書を作成し、会議で共有し、認識のズレを修正する——時には「作る時間」よりも「伝える時間」の方が長くなることすらありました。

少人数体制になれば、この伝達ロスが丸ごと消失します。同じ目的を持った少人数であれば、口頭やチャットでの即座の確認で済み、書類を作って承認を待つ無駄な時間が発生しません。

下請けへの「外注・オフショア」が不要になる

従来の多くの開発会社は、人手を安く大量に確保するため、実装作業を外部の協力会社や海外の開発拠点に再委託してきました。

しかし、実装そのものをAIが肩代わりするようになった現在、その必要性は急速に薄れています。当社では、今後このような「海外オフショア拠点に依存する開発モデル」は縮小していくと予測しています。

外注工程が減ることで、伝言ゲームによる仕様間違いや、品質のばらつきというリスクを大幅に低減できます。

一人の離脱によるプロジェクト停止を防ぎやすくなる

かつての体制では、「仕様を把握しているキーマンが1人しかおらず、その人が体調を崩すと全員の作業がストップする」というボトルネックが頻発していました。

「判断できる人」が「実装者」を兼ねる現代の少人数体制では、こうした無駄な待ち時間が発生しにくくなります。

注意点：ナレッジの属人化対策は必須

もちろん、少人数化には注意すべきデメリットもあります。

参加人数が少ないため、開発ノウハウや業務知識が個人の中で完結して属人化しやすくなります。万が一、その担当者が事故や退職で離脱した場合の影響は、従来以上に大きくなります。

発注側の防衛策として、契約を結ぶ前に「万が一、担当エンジニアが動けなくなった場合のバックアップ体制はどうなっているか」を必ず確認しておくことをお勧めします。

---

発注者の考え方をどうアップデートすべきか？

開発環境の変化に合わせて、発注側の「頼み方」も新しく更新していく必要があります。

「小さく始めて、徐々に広げる」契約にする

最初から全社の基幹システムを一気に丸ごと発注する必要はありません。

まずは「請求書発行業務だけ」のように対象を絞って開発・導入し、実際に使って効果を確かめてから適用範囲を広げる——このスモールスタートの手法が非常に取りやすくなりました。

万が一効果が出なかった場合でも、最小限の投資で撤退できるため、経営上のリスクを劇的に抑えられます。

「格安見積り」の真偽を見極める

今後、業界内には「相場の半額」のような極端に安い見積りを提示する業者が増えていきます。

しかし、それが「最新のAI体制で効率化しているから安いのか」それとも「単に経験不足で、テストやレビュー工程をサボっているから安いのか」は、全体の提示額だけでは判断できません。

見極めるためのチェックリストを以下にまとめました。

• AIが書いたコードの「レビューとテスト」をどう行っているか説明できるか？
• ヒアリング時に、業務の「例外パターン」について具体的に質問してくるか？
• 担当者が動けなくなった際の「代替・バックアップ体制」が準備されているか？
• 過去に同様の手法で構築した「実際のシステム実績」を見せられるか？

AIを活用して正しくコストを下げている優良企業であれば、これらの質問に対して明快かつ具体的に回答できるはずです。

相見積りは「金額の内訳」を見る

複数社から相見積りを取る際は、総額だけでなく「金額の内訳」に着目してください。

見るべきポイントは、「実装費」「業務ヒアリング費」「定着支援費」の配分です。ここにその会社の姿勢が現れます。

「実装費」だけが極端に安い見積りは、単に「動くものを納品して終わり」にする危険性があります。一方で、ヒアリングや定着支援にしっかりコストを割り振っている会社は、総額が多少高く見えても、結果としてトラブルなく業務改善を成功させてくれるでしょう。

「仕様変更が起きる前提」で取り決めをしておく

開発が進めば、仕様は必ず変わります。変更が起きることを最初から前提として、どこまでが契約範囲に含まれるのかを取り決めておくことが重要です。

保守範囲、修正依頼のルール、対応期間などについての確認事項は、以下の別記事で詳しくまとめています。