AIの発注は要件が書けずに止まる｜提案依頼書に入れる項目

「AIで何かやれと言われているのですが、何を頼めばいいのか分かりません」「何社かと相談だけは続けていて、半年たっても見積もりが1枚も出てきません」——AIの導入やAIエージェントの開発を外に頼もうとする場面で、判で押したように出てくる詰まり方です。原因は担当者の力不足ではありません。本当は作る前に仕様が確定しないという、この種の案件の性質のほうが先にあります。だから発注側がやるべきことは、仕様を書き切ることではありません。困っていることと、できたと言える状態と、守ってほしい制約を、各社が同じ土俵で答えられる形にして渡すことです。その渡す紙が提案依頼書です。この記事では、提案依頼書に入れる項目と書く順番、AI案件だから増える項目、要件が固まらないときの進め方、出したあとの評価の仕方までを順に見ていきます。

提案依頼書は「作り方」ではなく「困りごと」を渡す紙

提案依頼書は、外部の会社に提案を出してもらうために発注側が渡す書類です。頭文字を取ってRFPとも呼ばれます。よくある誤解は、これを仕様書だと思ってしまうことです。画面はこう、項目はこう、処理はこう、と細かく書き切ってから渡すものだと考えると、書けないまま何か月も止まります。実際には、細部を確定させるのは契約後の要件定義の仕事です。提案依頼書の役割は、達成したい状態と、守ってほしい制約を示して、良い提案を引き出すことにあります。

役割がずれると、提案の質もずれます。仕様を書き切って渡すと、返ってくるのは「書かれたとおりに作った場合の金額」だけになり、相手が持っている経験や、もっと安く済む代替案は出てきません。逆に困りごとだけを渡して制約を書かないと、自社では使えない前提の提案（社外にデータを出す前提、専任者が2人いる前提など）が並びます。引き出したいのは提案であって、見積もりの数字だけではないという点を、書き始める前に社内で合わせておきます。

似た書類に、情報提供依頼書（RFI）があります。こちらは提案の前段で、どんな会社があり、どんな実績や技術を持っているかを教えてもらう紙です。自社が初めてAI案件を出すときは、いきなり提案依頼書を配るより、情報提供依頼書で3社から5社の輪郭をつかんでから、提案を求める相手を絞るほうが、比べる作業がずっと軽くなります。

なぜAIの発注は、要件が書けずに止まるのか

普通のシステム開発なら、業務の流れを書き出せば、必要な画面と機能はおおよそ決まります。AI案件でそれが効かないのは、やってみないと、どこまでできるか分からない部分が残るからです。手元のデータで狙った精度に届くのか、届かないのか。社内の文書を読ませて答えさせたときに、実用に足る答えが返るのか。これらは事前の机上検討では確定しません。だから発注側が仕様を書き切ろうとすると、確定できない項目の前で筆が止まります。

この性質は、公的な整理の中でも前提として扱われています。経済産業省が2018年6月に公表し、2019年12月に1.1版が出た「AI・データの利用に関する契約ガイドライン」は、開発を一気に進めるのではなく、アセスメント・実証・開発・追加学習という4つの段階に分けて進める形を示しています。段階を分ける利点は2つあります。段階ごとに達成目標をすり合わせられること、そして難しいと分かった時点で止めて、損失の広がりを抑えられることです。

発注側から見ると、これは「最初から全部を1本の契約で頼まなくてよい」という許可でもあります。要件が書けないから止まっているのではなく、要件が書けない段階に一括発注をぶつけようとしているから止まっている。そう捉え直すと、提案依頼書に書くべきことも変わります。書くのは完成形の仕様ではなく、いま分かっていること、分かっていないこと、そして分からない部分をどう確かめたいか、です。

相談だけが進んで止まるのは、社内が決まっていないから

外に相談を持ちかけたのに要件が書けない、という状態には、社内側の事情も重なっています。総務省が2026年7月に公表した令和8年版情報通信白書によると、日本企業のうち何らかの業務で生成AIを利用していると答えた割合は86.4パーセントで、2024年度調査の55.2パーセントから大きく伸びました。一方で、生成AIによる業務変革について「組織的な取り組みはない」と答えた割合は27.0パーセントあり、米国1.4パーセント、ドイツ4.9パーセント、中国2.6パーセントと比べて際立って高い水準にあります。

この2つの数字を並べると、国内で起きていることが見えてきます。使うこと自体は広がったが、業務をどう変えるかは組織として決まっていない。その状態で外部への相談だけが先に進むと、何を頼みたいのかが社内で確定していないため、提案依頼書の欄が埋まりません。同じ白書では、全社横断で事業変革に取り組んでいると答えた割合は21.5パーセントにとどまり、業務の見直しに必要なスキルやノウハウを学ぶ環境があると答えた割合も39.9パーセントで、米国62.7パーセント、ドイツ60.4パーセント、中国71.7パーセントを下回っています。

裏を返すと、提案依頼書を書き始める前に社内で決めておくべきことは、多くありません。どの業務を対象にするか、誰が使う仕組みなのか、いくらまでなら出せるかの3つです。この3つが決まっていれば、残りの欄は未定と書いたままでも提案は集まります。逆に3つが決まらないまま配ると、各社から自社の事情に合わない提案が返り、読み比べる作業だけが積み上がります。

最初に書くのは、目的ではなく「いま起きている困りごと」

提案依頼書の書き出しでつまずく人の多くは、いきなり「目的」から書こうとします。ところが目的の欄には、たいてい「業務効率化」「顧客対応の高度化」といった、どの会社にも当てはまる言葉が並びます。これを読んでも、提案する側は何を作ればよいか分かりません。先に書くのは、いま誰が、何に、どれくらい時間や手間を取られているかという事実です。

たとえば「問い合わせ対応を効率化したい」ではなく、「問い合わせが1日あたり何件あり、そのうち何割が過去に答えたことのある内容で、担当者が探すのに何分かかっているか」。「資料作成を自動化したい」ではなく、「毎月の報告資料に何時間かかり、そのうち数字を集める作業が何時間か」。数えていない場合は、1週間だけでも数えてから書きます。困りごとが数で書かれていると、提案の側は効果を試算でき、金額の根拠も示せます。

この順番には副作用もあります。困りごとを数で書き出すと、そもそもAIを使わなくても解ける問題が混ざっていることに気づきます。重複した入力をやめる、様式を1つに揃える、といった整理で片づく分は、外に出す前に社内で片づける。残ったものだけを提案依頼書に載せると、案件が小さくなり、通りやすくなります。

提案依頼書に入れる項目と、書く順番

項目は会社ごとに増減しますが、骨格はおおむね共通しています。前半で自社の状況を渡し、中盤で頼みたいことを渡し、後半で選び方を渡すという順番です。この順で並べると、提案する側は読みながら前提を組み立てられます。

並び	項目	書く中身
前半	背景と困りごと	いま何が起きているか。数と、影響している範囲
前半	現在の仕組みと体制	使っている道具、データの置き場所、関わる人数
中盤	頼みたい範囲	どこからどこまでを任せたいか。任せない部分も書く
中盤	できたと言える状態	業務の言葉で書いた合格の目安
中盤	制約と前提	予算の幅、期限、社外に出せないもの、既存の決まり
中盤	提供できるもの	渡せるデータ、担当者の時間、検証に使える環境
後半	提案してほしい内容	提案書の構成、見積もりの内訳の粒度、提出の形式
後半	選び方	評価の観点と配点、選定の日程、問い合わせの窓口

欄を埋めるうえで効くのは、書けない欄をそのまま空欄にせず、「現時点では未定」「この点は提案の中で示してほしい」と明記することです。空欄は、読む側には「聞かれていない」と映ります。未定だと書いてあれば、提案側は前提を仮置きしたうえで金額を示せますし、後から前提が違ったときに、どちらの責任かも整理しやすくなります。

AI案件だから増える4つの項目

ここが、通常のシステム開発の提案依頼書との一番の違いです。AIを使う案件では、次の4つを書いていないと、提案の中身が比べられなくなります。どれも、後から揉めやすい場所でもあります。

• 学習への利用：渡したデータや入力した文章を、相手側のモデルの学習に使ってよいか。使わせない場合はその旨を書く
• 出てきたものの権利：生成された文章・画像・コード、そして作られたモデルそのものが、どちらのものになるのか
• 精度の合意：どの数字をもって「できた」とするか。測り方と、測るデータと、測る時期をそろえて決める
• 止まったときの扱い：狙った精度に届かなかったとき、そこで終えるのか、範囲を変えて続けるのか、費用はどう精算するか

この4つを整理するときの下敷きとして使えるのが、経済産業省が2025年2月に公表した「AIの利用・開発に関する契約チェックリスト」です。この資料は、AIを使う場面を入れるもの（インプット）と、出てくるもの（アウトプット）の2つに分けて、それぞれについて定義・提供と保証・利用と管理・第三者への提供・権利帰属・処理成果といった区分で確認すべき点を並べる構成になっています。契約書を書くのは法務の仕事ですが、提案依頼書の段階でこの区分に沿って希望を書いておくと、契約交渉でのやり直しが減ります。

• 精度の合意は、数字だけを書くと危険。同じ「正解率9割」でも、測るデータが変われば結果は変わる
• 止まったときの扱いを書いていないと、うまくいかなかった局面で「約束と違う」と「そういう性質だと説明した」がぶつかる
• 学習への利用は、自社が使う出来合いのサービス側の規約とも突き合わせて確認する

渡せるデータを、先に棚卸ししておく

AIの提案は、渡せるデータの中身でまるごと変わります。同じ「問い合わせ対応を助けてほしい」でも、過去の問い合わせと回答が5年分そろっているのか、去年の分が担当者の受信箱に散らばっているだけなのかで、提案も金額も別物になります。だから提案依頼書には、持っているデータの量・形式・置き場所・持ち出しの可否を書きます。

ここは、国内企業がとくに弱いところでもあります。総務省が2026年7月に公表した令和8年版情報通信白書によれば、生成AIによる業務変革の環境整備について、「生成AIに社内データを学習させたり、生成AIが参照可能なデータベースを構築したりしている」と答えた割合は、日本が24.5パーセントで、米国57.2パーセント、ドイツ54.4パーセント、中国73.0パーセントと比べて低い水準にあります。使えるデータが整っていないという前提から始まる案件のほうが、国内では多数派だということです。

整っていないこと自体は問題ではありません。問題になるのは、整っている前提で提案を受け、契約後に「データ整備に想定外の工数がかかる」と判明することです。棚卸しの結果が芳しくなくても、そのまま書きます。書き方の目安は、置き場所・件数・期間・形式・個人情報の有無・社外に出してよいかの6点です。この6点が書いてあれば、提案側は整備の手間を見積もりに含められます。

「できたと言える状態」は、業務の言葉で決める

AI案件の合格ラインを、技術の数字だけで決めると失敗します。正解率が何パーセントという数字は、測るデータの選び方で動きますし、その数字が上がっても業務が楽になるとは限りません。書くべきなのは、その仕組みが動いた結果、業務のどこがどう変わっていれば合格なのかです。

たとえば「調べ物にかかる時間が、いまの半分になっていること」「担当者が答えを探す作業が、1日あたり何件減っていること」「新人が単独で回答できる問い合わせの割合が上がっていること」。こうした業務側の目安と、技術側の目安を、両方書いておくのが実務的です。技術の数字だけだと業務が変わらず、業務の言葉だけだと、開発側が何を作れば合格か分からなくなります。

測り方も一緒に決めます。いつ・誰が・どのデータで測り、その結果を誰が見て合否を判断するか。ここを提案依頼書に書いておくと、提案側は検証の工数を見積もりに含めますし、契約後に「その測り方は聞いていない」という食い違いが起きません。測る対象のデータは、開発側が学習に使ったものとは別に取り分けておく、という約束も先に書いておきます。

要件が固まらないときの二段構え

それでも要件が固まらない案件はあります。そのときに取れる道は2つです。1つは調査だけを先に頼むこと。もう1つは範囲を切って、小さく試すことです。どちらも、いきなり本開発を一括で発注しないための手立てです。

この進め方をするときに大事なのが、調査の段階と本開発の段階で、契約の形を変えられるようにしておくことです。先に触れた契約ガイドラインでも、成果の約束が難しい段階については、仕事の完成を約束しない類型が向くという整理が示されています。提案依頼書には「段階を分けた提案も可」と一言添えておくと、現実的な進め方を提案できる相手が手を挙げやすくなります。

評価の重み付けは、提案を見る前に決める

提案が集まってから評価の観点を決めると、すでに読んだ提案の印象に引きずられた配点になります。見栄えのする実績が並んだ提案を読んだあとでは、実績の配点が上がる。安い金額を見たあとでは、価格の配点が上がる。これは意識して避けられるものではないので、配点は提案を受け取る前に紙で確定させ、社内で共有しておきます。

配点の柱は、価格・実現できるか・進め方と体制・運用の現実味、の4つに置くのが分かりやすい形です。公開されている解説では、価格30点・技術の実現性30点・体制と進め方20点・運用の現実味20点といった配点の例も示されています。配点の数字そのものより大事なのは、運用の現実味に独立した点を与えることです。AI案件は作って終わりにならず、作った後に手を入れ続ける必要があるため、そこに触れていない提案を見分ける必要があります。

評価する人も先に決めます。情報システム部門だけで見ると使い勝手の観点が抜け、業務部門だけで見ると運用の負荷や安全面が抜けます。業務・情報システム・法務や購買の3方向から見る体制にして、誰がどの観点を見るかを決めておくと、点が割れたときも議論の焦点がぶれません。

費用とスケジュールは、幅で書いてよい

予算を書くと足元を見られる、という理由で金額を伏せる発注が今もありますが、AI案件ではおすすめできません。予算の幅が分からないと、提案側は当てずっぽうで規模を仮置きするしかなく、返ってくる提案の粒度がばらばらになって比べられなくなります。上限だけでも書く、あるいは「初年度はこの範囲を想定」と幅で書くのが現実的です。

見積もりの内訳の粒度も、こちらから指定します。AI案件では、初期の構築費用だけでなく、使うたびにかかる従量の費用、月々の保守、精度を保つための手入れ、データ整備の工数が別々にかかります。内訳の欄を指定しないと、各社が違う粒度で出してきて、合計だけを見比べることになります。1年目と2年目以降を分けて出してもらうと、運用に入ってからの負担が見えます。

スケジュールも、確定日程ではなく区切りで書きます。「この時期までに、ここまで確かめたい」という区切りを示し、細かい日程は提案の中で組んでもらう。社内の決裁の時期、繁忙期、既存の仕組みの更新時期など、動かせない予定だけは先に伝えておくと、実現できない日程での提案が減ります。

作ったあと、誰が面倒を見るかまで書く

AIを使った仕組みは、納品された時点が完成ではありません。業務の言葉遣いが変わる、扱う商品が入れ替わる、参照させている資料が古くなる。こうした変化で、同じ仕組みでも答えの質は下がっていきます。だから提案依頼書には、納品後に誰が何を見るのかを書く欄を置きます。

具体的には、動きを見張る役、答えの質を定期的に確かめる役、参照させる資料を差し替える役、問い合わせを受ける窓口の4つです。これを自社で持つのか、相手に頼むのか、頼むなら月にいくらかかるのか。ここを空欄で出すと、提案側も触れずに出してきて、運用が始まってから誰も見ていない状態になります。

あわせて、使っている出来合いのAIサービス側が変わったときの扱いも書いておきます。外部のモデルは、こちらの都合と関係なく版が変わったり、提供が終わったりします。そのときに誰が気づき、誰が確認し、誰が費用を持つのか。提案の中で触れているかどうかは、相手が運用を分かっているかを見分ける材料にもなります。

下書きを生成AIに作らせるときの線引き

提案依頼書の下書きに生成AIを使うのは、有効です。項目の抜け漏れを指摘させる、渡した困りごとの記述から質問を作らせる、文章の重複を削らせる。こうした作業は明確に速くなります。ただし線引きが要ります。埋めさせてよいのは形式であって、判断ではありません。

判断とは、頼む範囲をどこで切るか、合格の目安をどこに置くか、配点をどう割るか、社外に出してよいデータはどれか、といった決めごとです。これらは自社の事情と責任に属するもので、AIに決めさせると、もっともらしいが自社では守れない条件が紛れ込みます。しかも、その条件は提案依頼書として外に出てしまうため、後から「その前提では作れない」と差し戻される原因になります。

実務的な使い方は、次の3つに絞るのが安全です。1つ目は、書いた原稿を読ませて「提案する側が困る箇所」を挙げさせること。2つ目は、自社で決めた方針を、社外向けの表現に整えさせること。3つ目は、集まった提案を同じ観点で要約させて、比較表の下ごしらえをさせることです。いずれも最後に人が原文へ戻って確かめることが前提で、とくに金額と日付と固有名詞は、要約を信用せずに提案書そのものを見ます。

出したあとの進め方

提案依頼書は、配って終わりではありません。配ったあとの進め方を先に決めて、日程として書いておきます。ここが曖昧だと、質問の受付と提案書の締め切りが近すぎて各社が前提を仮置きしたまま出す、という残念な結果になります。

1. 説明の場を設ける：資料に書けなかった背景と、社内の温度感を口頭で伝える
2. 質問を書面で受け、回答を全社に同じ内容で返す：ここで前提の食い違いが消える
3. 提案書を受け取る：形式と分量をそろえておくと、読む負担が下がる
4. 評価を先に個別で付け、そのあと持ち寄る：先に議論すると声の大きい意見に寄る
5. 気になる点を1回だけ追加で確認する：この確認は候補全社に同じ形で行う
6. 選定と、選ばなかった相手への連絡：理由を短く返すと、次の案件で相談しやすくなる

質問への回答を全社に同じ内容で返す、という手順は地味ですが効果が大きいところです。AI案件では、提案依頼書に書き切れなかった前提が必ず残っており、その前提を各社が別々に想像すると、金額が2倍3倍と開きます。同じ前提に揃えてから比べることで、はじめて金額と中身の比較が意味を持ちます。

提案依頼書でよくある失敗

最後に、実際に手戻りを生みやすい書き方を挙げておきます。どれも、書いている最中は問題に見えないのが厄介なところです。

• 他社の様式をそのまま流用する：自社にない前提や不要な要件が残り、提案側がそこに工数を積む
• 作りたい機能名だけを並べる：困りごとが読めず、もっと簡単な解き方があっても提案されない
• 予算も期限も書かない：各社が別々の規模を想定し、金額の比較が成立しなくなる
• データの状態を良く書く：契約後に整備の工数が発覚し、最初の見積もりが意味を失う
• 評価の観点を後から決める：読んだ提案の印象に引きずられ、選定の理由を社内に説明できなくなる
• 運用と保守の欄を置かない：作って終わりの提案が並び、動き出してから面倒を見る人がいない

よくある質問

提案依頼書は、どれくらいの分量が適切ですか。

分量より、比べられる形になっているかが基準です。小規模な案件なら、背景・困りごと・頼みたい範囲・制約・提供できるもの・選び方が数ページに収まっていれば足ります。分厚くしようとして一般論を足すと、読む側の負担が増えるだけで提案の質は上がりません。

要件が固まっていない状態で配ってしまってよいのでしょうか。

固まっていない部分を「未定」「提案の中で示してほしい」と明記していれば構いません。むしろ固まるまで待つと、何か月も動かないことになります。分からない部分を確かめるための調査や小さな検証を、最初の依頼の中身にしてしまうのが現実的な進め方です。

何社に配るのがよいですか。

提案を読んで評価する側の体力で決まります。3社から5社が扱いやすい範囲で、それ以上になると各社の提案を同じ深さで読めなくなり、印象で選ぶことになります。候補が多いときは、先に情報提供依頼書で絞ってから提案を求めます。

精度は何パーセントと書けばよいですか。

先に数字を決め打ちするのは避けます。どの数字が妥当かは、手元のデータを見なければ分かりません。書くべきなのは、業務としてどうなっていれば合格かという状態と、その合否を誰がいつどのデータで測るか、という測り方のほうです。

提案依頼書と要件定義は、どう役割が分かれますか。

提案依頼書は、頼む相手を選ぶために渡す紙です。要件定義は、選んだ相手と一緒に、画面や項目や処理の中身を確定させていく工程で、契約後に行います。線引きの目安は、その情報が相手を選ぶために要るかどうかです。選定に関係しない細部まで先に確定させようとすると、提案依頼書がいつまでも出せません。

AIに提案依頼書そのものを書かせてもよいですか。

骨組みや文章の整えには使えますが、判断の部分は任せられません。頼む範囲、合格の目安、配点、社外に出せるデータの線引きは、自社の責任で決める内容です。AIが出した条件をそのまま外に出すと、自社で守れない前提が紛れ込みます。

まとめ

AIの発注が止まるのは、要件を書く力が足りないからではありません。作る前に仕様が確定しないという性質に、一括発注の作法をぶつけているからです。提案依頼書に書くのは、困りごとと、できたと言える状態と、守ってほしい制約。そこにAI案件特有の4項目（学習への利用・出てきたものの権利・精度の合意・止まったときの扱い）を足し、渡せるデータの状態を正直に書く。要件が固まらないなら、調査だけ先に頼むか、範囲を切って試す。評価の配点は提案を見る前に確定させ、運用を誰が見るかまで書いておく。生成AIには形式を埋めさせ、判断は自社で持つ。まずは、いま困っていることを1週間だけ数えるところから始めてみてください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。