システム開発を段階的に発注する方法｜小さく始めて広げる区切り方・費用・契約【2026年9月最新】

要件が固まっていない、AIを使う、総額が数千万円になりそう――このどれかに当てはまるシステム開発は、一括で発注せず「検証・要件整理」→「本開発」→「運用・改善」と段階に分け、前の段階の結果を見てから次を発注するのが安全で、IPA（情報処理推進機構）のモデル契約もこの進め方を採用しています。1段目の費用は、AIの検証（PoC＝本格的に作る前に小さく試作し、業務で使えるかを確かめる工程）で100〜500万円、範囲を1箇所に絞った小規模な改修なら当社では30万円〜（当社価格は税別）が目安で、ここでやめれば出ていくお金はその段階の金額までに収まります。

この記事では、段階的に発注するときに発注する側が決めなければならない4つのこと――どこで区切るか、各段階にいくらかかるか、契約をどう組むか、どの時点で次に進むか・やめるか――を、IPA・経済産業省・JUAS（日本情報システム・ユーザー協会）の資料と、開発会社各社の公開価格をもとに順に説明します。一括で発注したほうがいいケースと、段階に分けることのデメリットも正直に書きます。

一括で発注すると、発注する側で何が起きるか

出典: 日本情報システム・ユーザー協会（JUAS） 公式サイト

一括発注（開発の全工程を1本の契約でまとめて頼むこと）で問題になりやすいのは、技術の失敗よりも、お金が出ていくタイミングと、判断のタイミングがずれることです。

全体の見積が出た時点で、社内の承認が止まる

要件が固まっていない段階で全体の見積を取ると、開発会社は分からない部分を見越した金額を出すしかありません。一括契約では想定外の事態が起きたときの負担を開発会社が負う形になるため、そのリスクに見合う上乗せを見積に含めざるを得ず、結局は発注者もその分を負担することになる、と尾城亮輔弁護士の解説（BUSINESS LAWYERS）でも指摘されています。こうして「想定していた金額を大きく超える見積」が出て、社内の承認が止まるのは、段階的な発注を検討し始めるよくあるきっかけです。

成果を見る前に、大きな金額が出ていく

開発会社の秋霜堂は、システム開発の代金を着手金30〜50%（契約時）、中間金20〜30%（工程の完了時）、完成金30〜40%（納品・検収後）の3回に分けて払う形が一般的だと解説しています。これを当てはめると、3,000万円の開発を一括で発注した場合、動くものを1つも見ないうちに900万〜1,500万円が出ていく計算になります。

段階に分け、最初の検証を300万円で区切れば、うまくいかなかったときに出ていくお金の上限は300万円と社内の担当者の時間です。

規模の大きい開発ほど、予算と期間が外れやすい

JUASの「企業IT動向調査報告書2026」（2025年度調査）は、開発の規模ごとに予算・工期・品質の状況を集計しています。人月は「エンジニア1人が1か月働く量」です。

10人月未満では予算超過が6.0%なのに対し、500人月以上では42.2%です。ただし、これは「規模の小さい開発ほど外れにくい」という傾向を示すデータで、「大きな開発を契約だけ分ければ超過が6%に下がる」ことを示したものではありません。段階的な発注に活かせるのは、最初の1段目を小さな規模に収め、外れたときの影響を小さくしておくという考え方です。追加費用が発生する典型的なパターンはシステム開発の追加費用はなぜ発生する？で解説しています。

段階的な発注とは｜区切り方は4つある

出典: 情報処理推進機構（IPA） 公式サイト

段階的な発注とは、開発を工程や範囲ごとに分けて契約し、前の段階の結果を見てから、次の段階の中身・金額・期間を決める発注方法です。IPAの「情報システム・モデル取引・契約書（第二版）」（2020年12月公開）では「多段階契約」と呼ばれています。最初に全段階に共通する条件（責任の範囲、解除、損害賠償、検収の方法、秘密保持など）を基本契約で決め、各段階の作業内容と金額は個別契約で決める形です。

これは一部の開発会社の独自の考え方ではなく、公的機関が発注者に勧めている進め方です。

• IPA「超上流から攻めるIT化の原理原則17ヶ条」は「多段階の見積もりは双方のリスクを低減する」を原則の1つに挙げ、発注者に「必要最低限のシステム構築からスタートする」ことを求めています
• IPAの講演資料（2025年4月）は、見積は「試算 → 概算 → 確定」と段階ごとに精度が上がるものだとし、「あいまいさがある段階の見積りを、はっきりした段階で見積もり直せるルールがプロジェクト成功の鍵」としています。多段階契約は「契約作業の手間は増大するものの」、仕様変更の影響を極力抑えられる、という位置づけです
• デジタル庁の情報システム調達改革検討会 最終報告書（2023年3月）も、国のシステム調達で大きな案件を細分化するなど「合理的な調達単位」を検討する方針を示しています（民間の発注にそのまま適用される規則ではありません）

なお、IPAは「多段階とは、受注先をその都度変えるということではなく、固まり具合に応じて見積り精度を上げていこうということ」と明記しています。段階的な発注は、開発会社を毎回入れ替えるための仕組みではありません。

区切る場所は、開発の中身で変わる

よく紹介されるのは「要件定義 → 設計・開発」という工程での区切り方ですが、実際には開発の中身によって区切る場所が変わります。

※1 JUAS「ソフトウェア・メトリクス調査2025」にある作業量の配分（要件定義15：設計から部分ごとのテストまで60：全体を通したテスト25）を金額に当てはめた当社の試算です。期間の配分は20：50：30で、要件定義に全体の約2割の期間を使います。

※2 LASSICの公開値（小規模＝単部門・画面10〜20程度、中規模＝複数部門・画面30〜60程度）。

※3 whitch・LASSICの公開値。

※4 Wurの公開値。

「請負」は完成を約束する契約、「準委任」は作業の実施を約束する契約（完成までは約束しない）です。

①工程で切るは、最も一般的な区切り方です。1段目の要件定義書が、2段目の見積の土台になります。要件が固まっていない段階での進め方は要件が固まっていない段階で開発会社に相談する方法、発注側としての要件定義の進め方は要件定義の進め方で解説しています。

②検証で切るは、AIを使う開発で特に重要です。後半の「AI開発を段階的に発注する場合」で詳しく説明します。

③範囲で切るは、IPAの17ヶ条にある「機能要求は膨張する。コスト、納期が抑制する」への対処です。同じ原則は開発会社に対しても、納期内に収まらない開発量なら「段階的稼働を提案する」ことを求めています。最初から全機能を作らず、最小限の機能で使い始めてから、使われ方を見て広げます。

④改修は調査で切るは、IPAのモデル契約が既存システムの改修について示している分け方です。まず「要件定義と既存システムへの影響調査」を準委任で行い、その結果に基づいて実装を請負で見積もります。範囲が小さい改修の費用感はシステムの小規模改修の費用にまとめています。

段階的に発注したほうがいい開発・一括で発注していい開発の境界線

すべての開発を段階に分ければいいわけではありません。IPAは多段階契約を使う場面として、業務や組織を見直しながらシステムにする範囲を検討している場合など、完成したときの姿を早い段階で決めにくい開発を挙げています。逆に言えば、完成の姿が決まっている開発は一括で発注して構いません。

左の列に当てはまる項目が多いほど、段階に分ける意味が大きくなります。

段階に分けることのデメリットも知っておく

段階的な発注には、はっきりしたデメリットもあります。

1. 契約の手間が増える：段階ごとに見積の依頼、社内の承認、契約の締結が発生します。IPA自身が「契約作業の手間は増大する」と認めています
2. 総額が最初に確定しない：Sun*は多段階契約について「最終的な費用が予定より増えるリスク」を挙げています。1段目の契約時に、2段目以降の概算の幅を出してもらい、全体像を社内と共有しておくことが対策です
3. 段階の切れ目で作業が止まる：次の見積・承認・締結のあいだ、作業は進みません。1段目の契約の時点で、判定日と次の契約の予定時期を決めておきます
4. 細かく割りすぎると、つなぎ目で手戻りが出る：LASSICは、要件定義を別の会社に頼んだ場合の注意点として、引き継ぎに手間がかかることと、受け渡す文書の書式が合わないことを挙げています。区切りの数を必要以上に増やさず、各段階で受け渡す成果物の形を先に決めておきます
5. 範囲の決まった小さな開発では、手間のほうが大きい：対象が1箇所で仕様も決まっている改修を、さらに契約を分けて発注する意味はほとんどありません

段階ごとの費用と期間の目安

段階ごとの金額を公開している開発会社の数字と、当社の価格を並べます。各社が想定している規模が違うため、幅は大きめです。

運用・保守の月額はLASSICでは月50〜300万円とされており、想定している規模によって大きく変わります。中堅企業の業務用途ではwhitchの数字を目安にし、LASSICの数字は大規模な場合の参考にしてください。

もう少し具体的な例として、whitchは「社内の文書を読ませて、根拠を示しながら質問に答えるAI」の費用を、PoC 100〜300万円 → 本開発 300〜1,000万円 → 運用 月10〜50万円としています。段階に分けると、最初の判断にかかる金額は100〜300万円で、本開発まで進んだ場合の初期費用は合計400〜1,300万円です。業務システム全体の相場は業務システム開発の費用相場、AI開発の相場はAI受託開発の費用相場で詳しく解説しています。

一括と段階的で「最初に出ていくお金」を比べる

総額3,000万円の開発を例に、一括と段階的で比べます。

人月単価を60〜100万円と置くと、10人月未満はおおむね600万〜1,000万円未満にあたります（当社の換算）。1段目をこの範囲に収めておけば、先ほどのJUASの表で予算超過・工期遅延の割合が最も低かった規模で、最初の判断ができます。

当社の価格は、そのまま段階的な発注の形になっている

当社の受託開発の価格は、段階的な発注の1段目・2段目にそのまま当てはまります。

• 1段目｜範囲を絞る：小規模改修 30万円〜　画面の追加・修正、帳票の追加、CSV出力、システム同士の軽微なデータ連携など
• 1段目｜検証だけを切り出す：PoC 300万円〜　課題と検証内容の整理、簡易的な要件定義、試作の設計と開発、検証環境、結果の整理、本開発の提案までを含みます
• 2段目｜本開発：個別見積　利用者数、機能の数、ほかのシステムとの連携、データの移行、セキュリティ、運用、止まらない仕組み（可用性）の要件で決まります

PoCに本開発の提案まで含まれているので、1段目が終わった時点で「次に進むか・やめるか」を判断する材料が揃います。価格と進め方の詳細は受託開発サービスのページに掲載しています。どの区切り方で始めるべきか分からない段階でも、初回相談は無料です。

契約の組み方｜基本契約＋段階ごとの個別契約

出典: 公正取引委員会 公式サイト

基本契約と個別契約で、それぞれ決めること

個別契約の項目は、IPAのモデル契約（第二版）第4条に沿っています。IPAの例では、システム化の計画と要件定義は準委任、外部設計（画面や帳票など利用者から見える部分の設計）は準委任か請負、内部設計・プログラム作成・テストは請負です。固まっていない段階は準委任、仕様が固まった段階から請負という組み方で、請負と準委任の違いや選び方はAI開発の契約形態で詳しく解説しています。

1段目の契約前に「次に進む・やめる基準」を文書にする

段階に分けても、次に進むかどうかの基準がなければ、結果が出ても誰も判断できず、検証だけが続く状態になりかねません。経済産業省の「AIの利用・開発に関する契約チェックリスト」（2025年2月）も、開発が長く続くと成果物の範囲が不明確になりやすいため、「開発初期の段階で当事者の認識を擦り合わせることが重要」としています。

1段目の契約書（または契約書に添付する文書）には、次の6項目を書いておきます。

例の数字は書き方を示すためのもので、実際の水準は業務ごとに決めます。

途中でやめたとき、払ったお金はどうなるか

段階的な発注で誤解されやすいのが、この点です。IPAはモデル契約（第二版）の論点として、後の段階でトラブルが起きたときに、前の段階の契約までさかのぼって解除できるか（IPAの表現では「上流工程への遡及」）を整理しています。

• 同時に進める複数の契約なら、ほかの契約の解除も可能だが、多段階契約のように前の段階 → 次の段階と続く関係では、次の段階でのトラブルを理由に前の段階の契約まで解除することは、原則としてできない
• 後の工程のトラブルを理由に前の工程の契約まで解除できたケースは、結局、前の工程にすでに契約違反があり、それが後の工程まで進んでから明らかになったケース

つまり、終わった段階に払ったお金は、原則として戻りません。また、秋霜堂は分割払いの中間金について、確定した報酬なのか仮の支払いなのかを契約書に明記すべきで、未完成の場合も中間金は原則として返金されないと解説しています。

発注する側の対策は、各段階の成果物を、その段階だけで価値がある形で受け取るように契約に書くことです。検証なら評価結果と次の段階の提案、要件定義なら別の会社でも見積ができる要件定義書、という形です。

工程を分けていても揉めることはあります。IPAの講演資料（2025年4月）は、NHKが日本IBMに委託したシステム移行（委託金額 約89億5,843万円）を題材に論点を整理しています。基本設計（システム全体の設計）が終わり、細部の設計に進む前の2024年3月に、日本IBMから最終納期に最低16か月の延伸が必要と伝えられ、NHKは2025年2月、契約解除にともなう約55億円の返還と損害賠償を求めて提訴しました。IPAは「契約金額とスケジュールが最初に定まっていた」ことや、すでに払われた31億円（IPAは準委任型の個別契約の対価と推定）が後の工程の解除で返還を求められる契約だったか、を論点に挙げています。どちらに非があるかはここでは扱いませんが（執筆時点で判決・和解の報道は確認できていません）、発注する側の教訓は2つです。工程を分けていても、総額と最終納期を最初に固定していれば、途中で前提が崩れたときに揉めること。そして、払った段階の費用が戻るかどうかは、契約の組み方で決まることです。

次の段階で依頼先を変えられる状態を残しておく

IPAが言うとおり、段階的な発注は毎回依頼先を変えるためのものではありません。ただ、変えられる状態を残しておくことは、次の段階の見積を適正にするうえで効きます。1段目を頼んだ会社しか中身が分からない状態だと、次の段階で相見積もりを取っても形だけになるからです。

• 受け取る成果物：ソースコード、設計資料、要件定義書、検証に使ったデータと評価結果
• 成果物の形：別の会社が読んで見積ができる内容になっているか
• ソースコードの置き場所：開発会社の環境だけに置かれていないか

当社は、契約内容に基づいてGitHubリポジトリ（ソースコードの保管場所）、ソースコード、設計資料などを引き渡しています。納品物の確認項目はシステム開発の納品物にまとめています。

取適法と印紙税は、当てはまる場合だけ確認する

中小受託取引適正化法（取適法、旧・下請法。2026年1月1日施行）：公正取引委員会・中小企業庁のテキストでは、社内にシステム部門や開発に詳しい従業員がいても、外に頼んでいるものと同種のソフトウェアを自社で作っていなければ、自社で使うシステムの外注は対象に当たらないとされています。薬局や医療機関、インフラ企業などが自社の業務システムを開発会社に頼む典型的なケースは、対象外になることが多いと考えられます。発注者自身がソフトウェア開発を事業にしている場合などは対象になり得ます。対象になる場合、仕様が確定していないため発注時に代金を決められないことは「正当な理由」として認められていますが、決まっていない事項を除いた内容を発注時に示し、決められない理由と金額を決める予定日を示したうえで、決まったら直ちに補って示す必要があります。金額の算定方法を示せるなら、算定方法を示さなければなりません。

印紙税：請負の基本契約で、金額を書かずに単価や支払方法などを定めたものは「継続的取引の基本となる契約書」（第7号文書）として1通4,000円です（契約期間が3か月以内で更新の定めがないものを除く）。金額を書いた場合は請負に関する契約書（第2号文書）などとして、記載金額に応じた税額になります。準委任の契約書は原則として印紙税がかからず、電子契約なら印紙は不要です。

AI開発を段階的に発注する場合｜「検証で止まる」前提で区切る

出典: Gartner 公式

AIを使う開発は、業務で使える精度が出るかどうかを、作る前に確かめられません。そのため経済産業省の「AI・データの利用に関する契約ガイドライン」（AI編）は、AI開発を4つの段階に分け、段階ごとに契約する「探索的段階型」の進め方を示しています。

2025年2月の「AIの利用・開発に関する契約チェックリスト」も、開発の契約を結ぶ時点でリスクを十分に分析できない場合は「開発型契約単体でリスク調整を行うのではなく、その後当事者間で締結される契約で段階的に調整をすることで、より実態に即したリスク分配が可能となる場合も想定される」としています。

段階を分ける理由は、検証の段階で止まるAI開発が実際に多いからです。米調査会社のGartnerは2024年7月、生成AIプロジェクトの少なくとも30%が2025年末までにPoCの後で打ち切られると予測していました。双日テックイノベーションが2026年9月に公表した調査（従業員1,000名以上の企業でPoCを経験した生成AI推進担当者111名）では、PoCの後に「全社的に活用が定着している」と答えたのは50.5%で、定着を阻む理由の上位は「AIが社内の情報・データと接続されていないから」（52.7%）、「PoCで期待した成果や精度が得られなかったから」（47.3%）でした。

大企業を対象にした調査ですが、発注する側が1段目の契約に反映できることは2つあります。

1. 合格の基準に「精度」だけでなく「社内のデータやシステムとつなげられるか」を入れる。精度が出ても、社内の資料やシステムにつながらなければ現場では使われません
2. 1段目の成果物に、本開発に進む場合の範囲と概算の見積を含める。検証が終わってから本開発の見積を一から取り直すと、その間に判断が止まります

PoCの費用・工程・成果物はAIのPoC費用の相場、PoCが本開発につながらない典型的な理由はAI開発の失敗例で解説しています。

実際にやった事例｜どこで区切ったかで見る3件

当社が医療機関・薬局・インフラ企業で担当した案件から、段階の区切り方が結果を分けた3件を紹介します（守秘のため社名は伏せています）。

調剤薬局のケース｜範囲で切る：システムの入れ替えではなく、転記1箇所から始めた

課題：使っている業務システムからデータを書き出し、加工して、別のシステムに手で入力し直す作業が毎日発生していました。どこまで直すべきかが決まっておらず、他社からは基幹システムの入れ替えを含む提案も出ていました。

区切り方と作ったもの：「既存システムは残す」「対象は毎日発生している転記1箇所だけ」と1段目の範囲を決め、小規模改修の枠で進めました。データの取り込みと加工、次のシステムへの受け渡しを自動で行い、内容が食い違ったときだけ担当者に確認画面を出す仕組みです。

何がどう変わったか：二重入力がなくなり、担当者が目で確認するのは食い違いが出た件だけになりました。システムの入れ替えから始めていれば、同じ困りごとの解決が大きな発注になっていました。範囲で切る場合、1段目で困りごとが解消したなら「2段目に進まない」のも正しい判断です。

医療機関のケース｜検証で切る：PoCを独立した契約にし、やめる条件を先に書いた

課題：蓄積された文書や記録が多く、必要な情報を探すのに時間がかかっていました。AIで解決できそうでも、どこまでできれば業務に使えるのか誰にも判断できず、全部門を対象にすると費用も期間も膨らんで稟議にかけられない状態でした。

区切り方と作ったもの：対象を1部門・1業務に絞り、PoC（300万円〜の帯）を本開発とは別の契約（準委任）にしました。着手の前に「どの質問に、どの水準で答えられたら合格とするか」を文書で決め、届かなかった場合はこの段階で終了することも契約書に明記しています。作ったのは、手元の資料をAIに読ませ、質問すると根拠の箇所を示しながら答える仕組みです。

何がどう変わったか：「うまくいかなければ検証の費用で止められる」ことがはっきりしたため、稟議が通りました。段階を分けなければ、本開発まで含めた金額で承認を取る必要があり、着手自体ができていませんでした。判定の基準が先にあったので、拡大するかどうかの判断も短期間で済んでいます。

インフラ企業のケース｜工程で切る：評価レポートを要件定義の土台にし、本開発から請負に切り替えた

課題：複数の社内システムにまたがるデータを人が突き合わせて確認しており、月末に負荷が集中していました。検証で有効性は確認できたものの、本番の予算は年度内に固定額で確定させる必要があり、金額が動く契約では社内を通せない状況でした。

区切り方と作ったもの：検証で作った評価レポートをそのまま要件定義の土台にし、要件定義に2ヶ月かけて各システムからのデータの取り出し方を確認し、つなぐシステムの本数と検収の条件を確定させました。つなぐ先が1本増えた場合の追加費用も、この段階で決めています。そのうえで本開発を請負契約に切り替え、システム間のデータを自動で照合して、食い違いがある分だけを人に回す仕組みを作りました。

何がどう変わったか：発注側が負っていた仕様変更のリスクが、契約の時点で固定額に変わりました。全件を人が見る運用から食い違いだけを人が見る運用に切り替わり、月末に集中していた負荷も平準化されています。

3件に共通しているのは、区切り方を先に決めたのではなく、「何が分かっていないか」を先に確かめ、それが分かる最小の単位を1段目にしたことです。

相談から1段目の発注までの流れと期間

当社の進め方を例に、発注する側で準備することをあわせて示します。発注側の列は、他社に相談する場合にもそのまま使えます。

期間は、1段目がPoCなら1〜3か月、要件定義なら小規模で1〜2か月が他社の公開値の目安です。これに加えて、段階の切れ目ごとに、次の見積・社内の承認・契約の締結にかかる時間を計画に入れてください。社内の承認に時間がかかる会社ほど、判定日を予算の締め日や経営会議の日程から逆算して決めておくことが重要です。期間の全体像はAI開発の期間、1段目の稟議資料の作り方は生成AIの稟議資料の作り方で解説しています。

「一括見積の金額が大きすぎて止まっている」「どこで区切ればいいか決められない」という段階でも、受託開発の無料相談でお受けしています。要件が決まっていなくても構いません。

よくある質問

Q1. 段階的に発注すると、一括で発注するより総額は高くなりますか。

どちらになるかは、事前には言えません。高くなる要因は、契約を結ぶ回数が増える手間と、段階の切れ目で作業が止まる時間です。一方で、一括の見積には決まっていない部分に備えた上乗せが含まれやすく、段階的に発注すれば、その上乗せを中身が分かった時点の見積に置き換えられます。比べるときは総額の数字だけを並べず、①一括の見積に書かれた前提条件（対象範囲、つなぐシステムの数など）、②前提が崩れたときに追加費用をどう扱うか、③途中でやめた場合に支払うことになる金額、の3つを並べてください。段階的な発注の価値は、総額を下げることより、判断を誤ったときの損失を小さく抑えることにあります。

Q2. 本開発を任せる前提で、1段目の検証を無償や格安で引き受けてもらうのはありですか。

おすすめしません。本開発の受注を見込んで検証を無償や格安で引き受け、本開発につながらずに費用を回収できない状態は「PoC貧乏」と呼ばれます。特許庁と経済産業省が公開しているオープンイノベーション促進のためのモデル契約書でも、技術検証（PoC）契約書の解説で、こうしたケースが「散見された」と取り上げられています。発注する側にとっても、①無償の作業は成果物の定めがあいまいになりやすく、評価結果やプログラムを受け取る根拠が弱い、②「無償でやってもらった」という負い目から、結果が基準に届かなくても本開発を断りにくい、という問題があります。検証は有償の独立した契約にし、合格の基準と成果物を書いておくほうが、次に進むかどうかを公平に判断できます。

Q3. 年度をまたぐ開発では、予算をどう取ればいいですか。

段階の切れ目を、予算の区切りに合わせて設計するのが現実的です。たとえば、今年度の予算で1段目（検証や要件定義）を終え、その成果物に含まれる概算見積を、来年度の予算策定に間に合わせる順番です。そのためには、来年度の予算を申請する締め日から逆算して、1段目の判定日を決めておく必要があります。判定が締め日に間に合わないと、結果が良くても次の予算が取れるまで待つことになりかねません。来年度分は「1段目の結果を受けて金額を確定させる」と条件を付けた概算の幅で計上し、確定させる時期も予算資料に書いておきます。

Q4. 要件定義だけを別の会社に頼み、開発会社は相見積もりで決めてもいいですか。

できます。特定の開発会社しか中身が分からない状態を避けやすく、同じ要件定義書を複数の会社に渡して、条件を揃えた見積を取れる利点があります。注意点は、要件定義をした会社と開発する会社が違うと、引き継ぎに時間がかかったり、文書の書き方が開発会社の求める形と合わなかったりすることです。IPAのモデル契約にも、前後の工程を別の会社が受ける場合に備えた条項が別に用意されています。別の会社に頼むなら、要件定義の契約で、①開発会社が見積できる粒度で書くこと、②開発が始まってから開発会社の質問に答える支援を一定期間含めること、を決めておいてください。依頼書の作り方はシステム開発の相見積もりと提案依頼書（RFP）の作り方で解説しています。

Q5. 段階の切れ目で待ちが出て、開発会社の担当者が替わってしまうことはありませんか。

あり得ます。基本契約を結んでも次の段階の発注は保証されないため、開発会社は切れ目で担当者を別の案件に回すことがあります。対策は3つです。①1段目の契約の時点で、判定日と次の契約を結ぶ予定時期を開発会社と共有しておく。②担当者が替わっても引き継げるよう、打ち合わせの記録と判断の経緯を成果物に含めてもらう。③正式な契約の前に作業を始める必要がある場合は、IPAがモデルを用意している「LOI（仮発注合意書）」のような、仮の合意書を使う方法を検討する。③は、社内の承認に時間がかかる会社で切れ目を短くする手段になります。

Q6. 1段目の途中で「この機能も欲しい」となったら、どうすればいいですか。

原則として、その段階の契約には入れず、次の段階の個別契約に回します。1段目の範囲と金額は、その範囲を前提に決まっています。途中で対象を足すと、判定の基準まで変わり、「結局何を確かめたのか」が分からない検証になりがちです。出てきた要望は一覧にしておき、判定のときに次の段階の範囲に入れるかどうかを決めてください。どうしても1段目に入れる必要があるなら、口頭で頼まず、作業量・金額・期間への影響を書面で出してもらってから合意します。変更が追加費用になるパターンと防ぎ方はシステム開発の追加費用はなぜ発生する？にまとめています。

Q7. 開発会社から全体の一括見積しか出てこない場合、どう頼めばいいですか。

見積を依頼する時点で、「1段目は確定金額で、2段目以降は概算の幅で出してほしい」と書面で伝えてください。見積は段階ごとに精度が上がるものなので、開発会社にとっても無理のない依頼です。依頼書には、1段目で確かめたいこと、1段目の成果物として受け取りたいもの、判定の時期を書いておくと、各社の提案を同じ条件で比べられます。それでも一括の金額しか出てこない場合は、決まっていない部分への上乗せが含まれている可能性があるので、見積の前提条件と、前提が変わったときの追加費用の扱いを必ず確認してください。見積書の読み方はAI開発の見積もり比較で解説しています。

システム開発の段階的な発注は、区切り方の相談から始められます

システム開発を段階的に発注するときは、開発の中身に合わせて「工程」「検証」「範囲」「改修の調査」のどこで区切るかを決め、1段目を小さな金額に収めます。1段目の目安は、AIの検証で100〜500万円、要件定義で開発全体の約15%です。契約は基本契約と段階ごとの個別契約で組み、次に進む・やめる基準と、やめた場合に受け取る成果物を、1段目の契約前に文書にしておきます。

• 一括見積の金額が大きく、社内の承認が進まない
• AIを使う開発で、どこまでできるか分からないまま本開発の見積を求められている
• 既存システムを直したいが、どこまで手を入れるべきか決められない

このいずれかに当てはまるなら、初回相談は無料です。当社の受託開発の価格は、小規模改修30万円〜、PoC 300万円〜、本開発は個別見積（すべて税別）で、医療機関・調剤薬局・インフラ企業での開発実績があります。要件が決まっていない段階からご相談いただけます。

ご相談の際は、①対象にしたい業務、②使っているシステムの名前、③予算の上限感と決裁の時期、の3点をお聞かせください。どの区切り方で始めるか、1段目の範囲と金額の目安、次に進む・やめる基準の案を整理してお伝えします。段階に分けず一括で頼んだほうがよい案件だと判断した場合は、その理由をお伝えします。

▶ システム開発を段階的に発注する進め方・費用の無料相談はこちら

関連記事：AI開発の契約形態／AIのPoC費用の相場／要件が固まっていない段階で開発会社に相談する方法／システムの小規模改修の費用／システム保守運用費の相場／AI開発会社の選び方／AI導入のROI試算

参考資料

• IPA「情報システム・モデル取引・契約書（第二版）」（2020年12月）
• IPA「情報システム・モデル取引・契約書 講演資料」（2025年4月）
• IPA「超上流から攻めるIT化の原理原則17ヶ条」
• 経済産業省「AIの利用・開発に関する契約チェックリスト」（2025年2月）
• 経済産業省「AI・データの利用に関する契約ガイドライン AI編」
• デジタル庁「情報システム調達改革検討会 最終報告書」（2023年3月）
• 特許庁「オープンイノベーションポータル（モデル契約書）」
• 公正取引委員会・中小企業庁「中小受託取引適正化法テキスト」（令和7年11月）
• 国税庁「No.7104 継続的取引の基本となる契約書」
• 国税庁「第7号文書と他の号に該当する文書の所属の決定」
• JUAS「企業IT動向調査報告書2026」
• JUAS「ソフトウェア・メトリクス調査2025」
• BUSINESS LAWYERS「システム開発における一括契約と多段階契約のメリット・デメリット」
• Gartner「Gartner Predicts 30% of Generative AI Projects Will Be Abandoned After Proof of Concept By End of 2025」（2024年7月）
• 双日テックイノベーション「AI PoC定着に関する実態調査」（2026年9月）
• whitch「AI開発会社の選び方」
• LASSIC「AI開発委託外注の進め方と注意点」
• LASSIC「要件定義を外注する費用と進め方」
• Wur「MVP開発の費用相場」
• 秋霜堂「システム開発費用は分割払いできる？」
• Sun*「システム開発の契約形態を徹底解説」