提案書を並べても比べられない
AIエージェントの開発を外に頼むと決め、数社から提案書と見積が届いたところで手が止まることがあります。各社が自社の得意な部分を厚く書くため、章立ても金額の単位も揃いません。片方は工程ごとの人数と期間を出し、片方は一式の金額だけを出す、といった状態になります。
このとき技術構成の優劣を判定しようとすると進みません。判定できるのは、後から追加費用や手戻りにつながる項目が書かれているかどうかです。書かれていない項目は、安く見える見積の中に隠れています。
以下は、届いた提案書と見積を読むときに確かめる7項目です。作るものを自社で持つか既製ツールで足りるかをまだ決めていない場合は、AIエージェントは自作か既製ツールか で先に線を引いてから提案を集めたほうが、比較の枠が揃います。全体の進め方と見積の内訳は AIエージェント開発の進め方 にまとめています。
| 確かめること | 提案書のどこに出るか | 書かれていないときの質問 |
|---|---|---|
| 対象業務の切り出し方 | 対象範囲・スコープ・前提条件 | 対象から外れる処理はどれか |
| 接続先と権限 | システム構成図・外部連携の一覧 | 書き込みを行う処理はどれか |
| 評価の方法と合格ライン | 検証計画・受入基準・テスト仕様 | 正解データは誰が作るか |
| 本番後の改修と保守 | 保守運用・月額・時間単価表 | 月額に含む作業はどこまでか |
| 契約形態 | 契約条件・支払条件 | 完成の義務を負う形か |
| 引き継ぎ資料 | 納品物一覧・成果物の権利 | 契約終了後に自社で直せるか |
| 検証（PoC）の位置づけ | 進め方・スケジュール・費用 | 続けない判断はいつ誰がするか |
1. 対象業務の切り出し方が具体的か
「請求書処理の自動化」のような業務名だけが書かれた提案は、あとで範囲の解釈が分かれます。読むべきなのは、処理の開始と終了がどこか、月あたり何件を想定しているか、どの書式まで対象か、対象外はどう扱うかです。
具体的に書かれている提案は、たとえば「月に届く約400通のうち、指定の5書式を読み取り、それ以外は担当者へ差し戻す」という形になっています。件数と書式の数が入っているため、想定と違ったときにどこがずれたかを指摘できます。
書かれていない場合は、対象から外れる処理を列挙してもらいます。あわせて、例外が想定より多かったときに費用と期間がどう変わるかを聞きます。この答えが「その都度ご相談」だけの場合、変更のたびに見積と待ち時間が発生します。処理件数や書式の数え方は AIエージェントの要件定義の書き方 の項目に沿って自社側でも用意しておくと、各社の前提を揃えられます。
2. どのシステムにどこまでの権限でつなぐか
エージェントは既存システムへつないだ時点から、社内の情報を読み、場合によっては書き込みます。提案書では構成図や外部連携の一覧に出ますが、権限の範囲まで書かれているものは多くありません。
確認するのは、接続先ごとに読み取りだけか書き込みまで行うか、どのアカウント名義で接続するか、操作の記録がどこに残るかの3点です。読み取りで足りる処理に書き込み権限を渡す構成になっていれば、その理由を聞きます。
書き込みを行う処理については、誤った書き込みが起きたときに元へ戻す手順を提案側に説明してもらいます。ここが決まっていないと、社内の情報システム部門の審査で止まります。審査に必要な資料を出せるかも、この段階で確認しておく項目です。
3. 評価の方法と合格ラインを誰が決めるか
「精度90%以上を目指します」という記述だけでは、本番へ進めてよいかを判定できません。何件のどの処理を対象に測るか、正解を誰が作るか、どの種類の誤りなら許容するかが決まっていないためです。
読むのは受入基準や検証計画の節です。対象件数、測る指標、判定する人が書かれているかを見ます。誤りを一律に扱わず、金額や社外への送信に関わる誤りは1件でも不可、表記のゆれは許容する、といった区別があるものは実務に耐えます。
正解データを誰が用意するかは費用より先に確認します。過去の処理結果を集める作業は社内でしか行えないことが多く、ここに社内の工数が入ります。あわせて、合格ラインに届かなかったときに何回まで、どの範囲を無償で直すかを聞きます。
4. 本番後の改修と保守を誰がどの単価で持つか
稼働してからの費用は、提案書の後ろのほうに小さく書かれます。月額の保守費に何が含まれるかを、次の3種類に分けて確認します。障害が起きたときの対応、利用しているAIモデルの更新への追従、業務が変わったときの仕様変更です。
多いのは、障害対応だけが月額に含まれ、仕様変更は別見積になっている形です。それ自体は妥当ですが、業務の書式が年に何度も変わる場合は、変更のたびに見積と承認の時間がかかります。月額に含む作業時間、超過分の時間単価、連絡してから着手までの目安を数字で出してもらいます。
AIモデルの利用料は開発費とは別に、使った分だけ毎月かかります。誰の名義の契約で、誰が支払うのかを確認します。委託先の名義でまとめられていると、契約が終わったときに引き継ぎが必要になります。稼働後の費用の考え方は AI開発は外注か内製か で内訳を扱っています。
5. 契約形態で変わる責任範囲
同じ金額でも、契約形態によって「完成させる義務があるか」が変わります。提案書の本文ではなく契約条件の節に出るため、読み飛ばしやすい箇所です。
| 契約形態 | 委託先が負うもの | 向いている状況 |
|---|---|---|
| 受託（請負） | 決めた成果物の完成と、不具合の修補 | 範囲と合格ラインを先に固められる |
| 準委任 | 決めた期間の作業。完成の義務は負わない | 進めながら仕様を決めていく |
| ラボ型 | 一定の人員を期間中確保すること | 稼働後も改修が続く前提で任せる |
受託は範囲が固まっている場合に扱いやすい形です。反面、範囲外の変更は変更契約になるため、要件が動く段階で選ぶと手戻りの調整に時間がかかります。
準委任は方向を変えやすい形ですが、完成の義務が無いため、何をもって作業が終わるかを別に決めておく必要があります。提案書に納品物の一覧が書かれているのに契約形態が準委任になっている場合は、どちらの理解で進めるのかを確認します。
ラボ型は一定の人員を期間で押さえる形です。改修が続く業務では発注のたびの調整が減りますが、依頼する作業が途切れると稼働が埋まらないまま費用が出ます。社内で依頼を出し続けられる担当者がいるかが前提になります。
6. 引き継ぎ資料と社内に残るもの
契約が終わった後に自社で直せるかは、納品物一覧に何が並んでいるかで決まります。動くものだけを受け取っても、次に困ります。
- 実装したコードの一式と、その権利が自社に帰属すること
- 実行環境の名義（自社の契約か、委託先の契約か）
- 設定値と鍵の管理場所、権限を持つ人の一覧
- AIに渡している指示文と、判断の基準になっている資料
- 変更の履歴と、その変更を行った理由
- 運用の手順書と、止まったときの対処
このうち抜けやすいのは、AIへの指示文と判断基準です。振る舞いを決めているのはここなので、渡されないと社内で調整できません。受け取ったものを誰が保管し、どこに置くかも先に決めておきます。契約後に社内へ何が残るかの整理は AI内製化支援サービスの選び方 で扱っています。
7. 検証（PoC）の位置づけと打ち切り条件
多くの提案は検証から始まる形になっています。ここで確認するのは、その検証で何を確かめるのかが1〜2個に絞られているかです。「有効性を確認する」だけの記述では、終わったときに判定できません。
期間と成果物、検証費用が本番の開発費に含まれるのかも見ます。検証の結果に関わらず本番へ進む前提で組まれている場合、判断の機会が実質的にありません。
そして、続けない場合の条件を先に書いておきます。読み取りの正解率が一定に届かない、対象業務の例外が想定の何倍だった、接続先のシステムが必要な形でデータを出せない、といった具体的な事象で決めます。判断する日と判断する人も入れます。止まった検証の切り分けは 生成AIのPoCが進まない を参照してください。
提案を受け取ってから発注までの流れ
7項目を照合すると、多くの提案では2〜3項目が書かれていません。書かれていない項目を質問し、返答を書面で提案書へ追記してもらってから並べます。口頭の回答だけで進めると、着手後に解釈が分かれます。
質問は全社へ同じ文面で送ります。回答の内容だけでなく、答えられない箇所を「わからない」と書いてくるか、確認して後日返すと書いてくるかも判断材料になります。
複数社の提案を同じ枠で並べる
最後に、比較の単位を揃えます。金額を1行で並べるのではなく、次の項目ごとに各社の記載を書き写します。書き写せない欄が、まだ確認できていない箇所です。
| 並べる項目 | 揃える単位 | 空欄になったときの扱い |
|---|---|---|
| 対象業務 | 処理件数と対象の書式・種類の数 | 範囲を書面で確定させるまで金額を比べない |
| 接続先 | システム名と、読み取り／書き込みの別 | 権限の一覧を出してもらう |
| 合格ライン | 測る件数と指標、判定する人 | 受入基準として書面に追記してもらう |
| 社内から出す工数 | 打ち合わせと確認作業の時間／月 | 自社側で見積もり、金額に足して比べる |
| 初期費用 | 工程ごとの人数と期間 | 一式の金額のままなら内訳を依頼する |
| 稼働後の費用 | 月額の保守費、超過の単価、利用料 | 12か月分を試算して比べる |
| 引き渡すもの | 納品物の一覧と権利の帰属 | 契約書の条項として確認する |
| 打ち切り条件 | 判断する日、判断する人、条件 | 発注前に決めて書面に残す |
この表を埋めると、初期費用の安い提案が、社内から出す工数と稼働後の費用を足すと高くなる場合があります。逆に、初期の金額が大きい提案に要件確定と接続の作業が含まれていて、社内の負担が小さいこともあります。比べるのは12か月なり24か月なりの合計額と、その期間に社内から出す時間です。
なお、この記事では具体的な会社名の一覧や順位づけは扱いません。同じ領域で事業を行う立場からの評価になり、比較に必要な一次情報も持たないためです。判断は、自社の業務に対して各社が書いてきた内容で行ってください。
まとめ：提案と見積を判断できる形にする
- 技術構成の優劣ではなく、後から費用と手戻りにつながる項目が書かれているかを見る
- 対象業務は件数と書式の数まで書かれているかを確認し、対象外の処理を列挙してもらう
- 接続先ごとに読み取りか書き込みかを確認し、誤った書き込みの戻し方まで聞く
- 合格ラインは、測る件数・指標・判定する人が揃って初めて判定に使える
- 稼働後は保守費に含む作業、超過の単価、AIの利用料の名義を分けて確認する
- 契約形態で完成の義務が変わる。納品物の記載と契約形態が食い違っていないかを見る
- 検証は確かめる問いを1〜2個に絞り、続けない条件と判断する人を発注前に決める
- 比較は金額1行ではなく、社内から出す工数と稼働後の費用を足した合計で行う
Augueでは、AIエージェントの開発と、稼働後に社内の担当者が自分で改修を続けられる状態までの支援を行っており、対象業務の切り出しや合格ラインの決め方から一緒に整理しています。届いた提案の読み方や社内で決めておくことを相談したい方は、是非ご相談ください。
関連する記事
開発の進め方と見積の内訳は AIエージェント開発の進め方、自社で作るか既製ツールで足りるかは AIエージェントは自作か既製ツールか、外注と内製の費用は AI開発は外注か内製か、支援の提供形態の違いは AI内製化支援サービスの選び方、社内で用意する要件の書き方は AIエージェントの要件定義の書き方 を参照してください。
よくある質問
何社くらいに提案を依頼すればよいですか？
3社前後で足ります。増やすほど比較の手間が増え、同じ質問への回答を読み比べる時間が取れなくなります。それより、少ない社数に対して同じ資料と同じ質問を渡すほうが差が見えます。1社だけで進める場合は、金額の妥当性を判断する材料が無いため、工程ごとの人数と期間の内訳を出してもらってください。
提案依頼書（RFP）は用意したほうがよいですか？
形式の整った文書は必要ありませんが、対象業務の説明、現在の処理件数、接続したいシステムの一覧、いつまでに何ができていてほしいかは書面で渡します。これが無いと各社が別々の前提で見積を作るため、金額を並べても比べられません。1〜2枚のメモでも、全社へ同じものを渡せば役目を果たします。
提案の内容を評価できる人が社内にいない場合はどうすればよいですか？
技術の妥当性を判定しようとせず、書かれていない項目を数えるほうが確実です。対象業務の範囲、接続先と権限、合格ラインの決め方、保守の単価、引き渡すものは、専門知識が無くても記載の有無を確認できます。技術構成の是非を見てもらいたい場合は、開発を請けない立場の第三者に確認を依頼する形もあります。
開発費の相場はどれくらいですか？
対象業務の件数、接続するシステムの数、人が確認する箇所の設計量で変わるため、一律の目安は出せません。判断に使えるのは、工程ごとの人数と期間、社内から出す工数、稼働後に毎月かかる費用（保守と利用料）を合計した金額です。この3つが揃えば、同じ業務を人手で処理し続けた場合と比べられます。