AI開発の進捗確認｜発注側がやること

AI開発で手戻りが起きる最大の原因は、開発側の技術力ではなく、発注側の確認と判断が遅れることです。 「この場合はどう処理するのが正しいか」という質問への回答が3日遅れれば、期間はそのまま3日延びます。逆に言えば、発注側が週に1回、決まった型で確認を回すだけで、開発の期間と品質はかなりの部分が安定します。

この記事では、AI開発を発注した側が週次で何を見て、何を返せばよいかを整理します。読み手として想定しているのは、初めてAI開発を外注した担当者、または稟議を通した後に「進捗をどう見ればいいのか」を任された方です。技術の中身を理解する必要はありません。

進捗確認で見るのは「進捗率」ではなく「動くもの」

進捗確認の方法は1つで足ります。実際に動いているものを、実データで見せてもらうことです。

「70%完了」という報告は判断材料になりません。 残りの30%に何が含まれているかが分からないからです。AI開発では、最後の精度調整や例外処理に時間の大半がかかることが多く、「動くもの」が出てくるまでの進捗率と、業務で使える状態になるまでの進捗率は別物です。パーセンテージを聞く代わりに、「先週動かなかったもので、今週動くようになったものは何ですか」と聞いてください。

生成AIを組み込む開発では、出力が毎回同じとは限りません。そのため「仕様どおりか」ではなく「業務で使える精度か」を、実データで見て判断することになります。発注側がこの判断をできる立場にいるのは、業務の正解を知っているのが発注側だからです。開発側は正解を作れません。

発注側の役割は、契約のひな型にも書かれている

「進捗確認は開発会社の仕事ではないのか」と思われる方もいます。ここは公的なひな型で整理されている領域です。

情報処理推進機構（IPA）が公開する「情報システム・モデル取引・契約書（第二版）」は、DXを円滑に進めるにはユーザ企業とITベンダが新たな関係を構築していく必要があるとし、モデル契約を情報システム開発の各局面の取引構造を透明化するためのツールと位置づけています。2020年12月22日に公開された第二版では、見直しのポイントとして、セキュリティ、プロジェクトマネジメント義務および協力義務、契約における重大な過失の明確化、システム開発における複数契約の関係、再構築対応が挙げられています（出典1）。プロジェクトマネジメント義務と協力義務が並んで論点になっている点が要点です。開発側の進め方だけでなく、発注側の関わり方も契約上の論点として扱われているということです。

さらに、同じIPAが2020年3月31日に公開した「情報システム・モデル取引・契約書（アジャイル開発版）」は、ベンダ企業が専門家として業務を遂行すること自体に対価を支払う準委任契約を前提とし、ユーザ企業にはプロダクトオーナーを選任して権限を委譲すること、プロダクトの方向性と内容を決めるために主体的かつ積極的に関与することを求めています。ベンダ企業側はスクラムマスターを置き、双方が密にコミュニケーションを取りながら緊密に協働して開発を進めることが前提とされ、契約前にプロジェクトの目的やビジョン、体制などを確認するチェックリストも用意されています（出典2）。

つまり、発注側が判断者を置き、週次で見て、その場で決める。 IPAが示しているのは発注側の主体的な関与という前提までで、週次で見てその場で決めるという運用は、その関与を当社が具体的な形に落としたものです。この前提を社内で共有しておくと、「開発会社に任せているのだから」と確認を後回しにする状況を防げます。

週次確認の型：30分で回す4項目

確認は週1回、30分あれば足ります。毎回同じ順番で聞くことで、報告の粒度が揃い、変化に気づきやすくなります。

4番目を毎回聞いてください。 開発では小さなつまずきが起きるのが普通で、それが報告に出てこないほうが不自然です。順調な報告だけが続く開発は、問題が表に出る時期が遅れ、期間の後半でまとめて出てきます。「難しかったこと」を毎週聞く習慣があると、開発側も早い段階で言いやすくなります。

3番目も見落とされがちです。開発側は質問を溜めてから一度に出す傾向があり、発注側はまとめて答えるのに時間がかかります。週次で「回答待ちはあるか」と聞き、その場で答えられるものは答え、持ち帰るものには期日を付けます。期日を付けずに持ち帰った質問は、次の週にもう一度同じ質問として出てきます。

発注側が用意する3つのもの

1. その場で答えられる判断者を1名

開発中は「この場合はどう処理するのが正しいか」という質問が繰り返し出ます。その場で答えられる人が1名決まっていないと、質問のたびに待ち時間が積み上がります。 複数人の合議にすると、1つの質問に数日かかることがあります。まず1名が答え、必要なら後から調整する形が実務的です。IPAのアジャイル開発版がユーザ企業にプロダクトオーナーの選任と権限委譲を求めているのは、この待ち時間を生まないためと読むことができます。

判断者に求められるのは技術の知識ではなく、その業務の正解を知っていることと、決める権限を持っていることの2つです。現場の担当者が正解を知っていて、決める権限は課長にある、という分かれ方が多いので、着手前に「誰が決めるか」を1名に寄せておいてください。

2. マスキング済みの実データ

テストには実際の業務データが要ります。顧客名や個人名のマスキングを先に済ませておいてください。 ここで待ちが発生する例が目立ちます。データを渡せる状態にする作業は開発側では代行できないため、着手前に「どのデータを、どの範囲で、誰が加工して渡すか」を決めておきます。データの取り扱いはAI開発のセキュリティ｜発注前に確認すべきデータの扱い・学習利用・保管場所で扱っています。

3. 使う人の時間

完成が近づいたら、実際に使う人に触ってもらう時間が要ります。作った人と発注担当者だけが触って納品になると、運用開始後に使われません。 説明なしでどこまで操作できるかを見るために、30分でよいので利用者の時間を確保してください。判断者と利用者は別の人であることが多いので、両方の予定を早めに押さえておきます。

放置すると危ない兆候

5番目は特に注意してください。 追加提案自体は正当なことがあります。実データを見て初めて分かった例外や、業務側の前提が変わった場合です。一方で、当初の見積りが甘かった可能性もあります。理由を確認し、当初範囲内で成立させる案があるかも併せて聞いてください。

要件を変えるときの扱い

途中で要件が変わるのは普通のことです。着手時に次を決めておくと、そのつど揉めません。

• 変更の申請方法（口頭か、書面か、チャットの記録で足りるか）
• 期間への影響をどう扱うか
• 追加費用が発生する基準
• どこまでが当初範囲内の調整か

「調整の範囲」と「追加開発」の線引きを、着手時に例で示してもらってください。 言葉だけの定義では、実際の場面で判断が割れます。「出力の項目を1つ増やすのは調整、連携先のシステムを1つ増やすのは追加開発」のように、具体例で線を引いておくと、週次確認の場でそのまま使えます。

業種×部門で当てはめる

週次確認の型を、実際の業務に当てはめて確認します。以下は想定の典型例で、特定の顧客の実績ではありません。

例：建設会社の積算部門でAI開発の進捗を週次で確認する

建設会社の積算部門では、設計図書から数量を拾い、単価を当て、内訳書にまとめる作業に時間がかかります。案件が重なる時期は、数量の拾い漏れや単価の当て間違いを見つける確認作業だけで一日が終わることもあります。ここにAI開発を発注する場合、対象になりやすいのは「設計図書から拾った数量と項目名の一覧を下書きする」「過去の内訳書から類似項目の単価候補を提示する」「内訳書の書式に転記する」の3つです。判断は人が担い、AIは下書きと候補の提示までにとどめる設計にします。

積算には従うべき基準があります。国土交通省官庁営繕部の「官庁営繕の技術基準」には、公共建築工事の積算に必要な事項を定めた総括的な基準である公共建築工事積算基準（平成28年改定）のほか、標準歩掛や市場単価の取り扱いを定めた公共建築工事標準単価積算基準（令和8年改定）、設計図書からの数量の計測・計算方法を定めた公共建築数量積算基準（令和5年改定）、共通仮設費や現場管理費等の算定方法を定めた公共建築工事共通費積算基準（令和8年改定）、工事費内訳書の標準となる公共建築工事内訳書標準書式（令和8年改定）が掲載されています（出典3）。基準と書式は改定される文書です。 過去の内訳書を参照元にするなら、どの版に基づいて作られたものかを積算部門が判別できる状態にしておく必要があります。ここは開発側には判断できない、発注側の作業です。

この案件の週次確認は、次のように回します。判断者は積算課長1名。実データは直近2年分の内訳書と、その元になった設計図書から、施主名や現場名をマスキングしたものを着手前に用意します。

毎週の場では、開発側の操作デモではなく、積算担当者が自分で図面を投げて出力を見ます。「この項目は当社では別の名称で立てている」「この単価は改定前の基準で拾っている」といった指摘は、積算の実務を知っている人しか出せません。ここが発注側の役割で、AIの精度を上げる材料になります。

想定通りに進まなかったことの例としては、図面の書き方が設計事務所ごとに違い、数量の拾い方がぶれることが挙げられます。この場合、週次の場で「対象にする図面の形式を当面2種類に絞る」と決めれば、開発は止まりません。決めずに持ち帰ると、その週の開発は待ちになります。検収基準も、この段階で「拾い漏れの件数」「単価候補のうち採用できた割合」のように、積算担当者が数えられる形にしておきます。 積算の精度は最終的に人が担うため、AIの出力は「確認する順番を決める下書き」として評価します。

検収の前にやること

納品前に、実データで一定期間動かしてください。開発中のテストデータでは出なかった問題が、実データで出ます。

検収の観点はAI受託開発の進め方｜発注から納品までの流れでも工程として扱っています。

当社が自社で運用して分かったこと

当社は自社サイト500ページ超をAIで開発・運用し、記事の自動公開パイプラインとサイト上のAIチャットを自社で構築して運用しています。AI検索経由の流入は週59〜68ユーザー（検索流入の約3%・2026年7月・当社GA4実測）で、AI検索経由の集客の実測レポート（2026年7月版）に公開しています。

自社の開発で分かったのは、止まる原因はコードではなく判断だということです。「この出力は公開してよいか」「このケースは人に回すか」を決める人がいない時間が、そのまま開発の停止時間になります。当社では、判断が必要な点はその週のうちに決め、決められないものは「当面こう扱う」と仮に決めて進め、後で直す運用にしています。仮決めで進めて後で直すほうが、決まるまで待つより手戻りは小さいというのが、自社で運用してきた結論です。この運用を、お客様との開発でもそのまま使っています。

当社の進め方と費用

当社の費用は、業務自動化ミニ開発300,000円〜（税抜・単発）、AI組込み開発800,000円〜（税抜・要件見積）、AI開発顧問300,000円/月（税抜・最低3ヶ月）です。週次の確認はどの契約でも進行の基本にしています。社内に判断者と開発の担当を置いて内製化を進めたい場合は、AI開発顧問で週次のレビューと開発ロードマップの設計をご一緒します。

初回30分の相談は無料・オンライン対応・秘密厳守です。

商談で聞かれる質問

Q1. 作業範囲はどこまでですか。進捗確認の場は誰が用意しますか

当社が担うのは、要件の整理、開発、週次の確認会の設定と進行、判断を要する点の整理、実データでの精度調整、検収手順の提示、運用担当への引き渡しです。確認会はオンラインで当社が設定し、毎回「今週動くようになったもの」「回答待ちの質問」「想定通りに進まなかったこと」を先にお送りします。発注側にお願いするのは、判断者1名の指名、マスキング済みの実データの提供、確認会への出席、質問への期日内の回答です。業務上の正解を決めることは、当社では代行できません。 ここは発注側の役割として、着手前にお伝えしています。

Q2. 導入後の運用は誰がやりますか

日常の運用は発注側の担当者が担います。具体的には、出力の確認、参照している基準やデータの更新、利用者からの「うまく動かない」の受け付けです。納品時に、これらの手順を画面付きで引き渡します。業務自動化ミニ開発には納品後1ヶ月の動作フォローが含まれ、それ以降の改修は都度見積り、または開発顧問で継続的にご一緒する形のどちらかです。「納品後の窓口はどこか」「週次の確認は納品後も続けるか」は契約前に確認してください。

Q3. 依頼前に何を用意すればよいですか

3点です。第一に、対象業務の実際の作業画面と入出力のサンプル。第二に、判断者になれる人の候補と、その人が週に30分を確保できるか。第三に、実データを渡すためのマスキングの方針。いずれも完成している必要はなく、初回の相談で一緒に整理できます。特に第二の「判断者が週30分を確保できるか」は開発の期間を左右するので、社内で先に確認しておいてください。

まとめ

• 手戻りの最大の原因は発注側の確認と判断の遅さ。技術力より判断のスピードが期間に効く
• 確認方法は「週1回、実データで動くものを見る」で足りる。進捗率のパーセンテージは判断材料にならない
• IPAのモデル取引・契約書は、協力義務や、プロダクトオーナーの選任と主体的な関与を論点にしている。週次で見て決めるのは、この関与の具体的な形
• 週次の4項目は「動くもの・前回からの差分・回答待ちの質問・想定通りに進まなかったこと」
• 発注側が用意するのは「判断者1名・マスキング済みの実データ・使う人の時間」
• 「調整の範囲」と「追加開発」の線引きを着手時に例で確認する

あわせて読みたい

• AI受託開発の進め方｜発注から納品までの流れ
• AI開発の要件定義｜発注前に整理すべき5項目チェックリスト
• AI開発の失敗パターン7つ｜発注側が事前に潰せるリスクと対策
• AI開発のセキュリティ｜発注前に確認すべきデータの扱い・学習利用・保管場所
• 業務自動化PoCの進め方｜30万円規模で小さく検証する手順と成功基準
• AI開発の相見積もり｜同じ条件で比べる
• AI開発の記事一覧

出典

1. IPA「情報システム・モデル取引・契約書（第二版）」（2020年12月22日公開） — 取引構造の透明化を目的とするモデル契約。見直しポイントとしてセキュリティ、プロジェクトマネジメント義務および協力義務、重大な過失の明確化、複数契約の関係、再構築対応
2. IPA「情報システム・モデル取引・契約書（アジャイル開発版）」（2020年3月31日公開） — 準委任契約を前提に、ユーザ企業によるプロダクトオーナーの選任と権限委譲、主体的かつ積極的な関与、ベンダ企業のスクラムマスター選任、密なコミュニケーションと協働、契約前チェックリスト
3. 国土交通省 官庁営繕部「官庁営繕の技術基準」 — 公共建築工事積算基準（平成28年改定）、公共建築工事標準単価積算基準（令和8年改定）、公共建築数量積算基準（令和5年改定）、公共建築工事共通費積算基準（令和8年改定）、公共建築工事内訳書標準書式（令和8年改定）