AIエージェント開発会社の選び方｜提案と見積で確かめる7項目と、契約前に決めておくこと

提案書を並べても比べられない

AIエージェントの開発を外に頼むと決め、数社から提案書と見積が届いたところで手が止まることがあります。各社が自社の得意な部分を厚く書くため、章立ても金額の単位も揃いません。片方は工程ごとの人数と期間を出し、片方は一式の金額だけを出す、といった状態になります。

このとき技術構成の優劣を判定しようとすると進みません。判定できるのは、後から追加費用や手戻りにつながる項目が書かれているかどうかです。書かれていない項目は、安く見える見積の中に隠れています。

以下は、届いた提案書と見積を読むときに確かめる7項目です。自社で作るか既製ツールで足りるかをまだ決めていない場合は、先にそこを決めてから提案を集めると、各社の提案を同じ前提で比べられます。

確かめること	提案書のどこに出るか	書かれていないときの質問
対象業務の切り出し方	対象範囲や前提条件の節	対象から外れる処理はどれか
接続先と権限	システム構成図・外部連携の一覧	書き込みを行う処理はどれか
評価の方法と合格ライン	検証計画・受入基準・テスト仕様	正しい処理結果の見本（正解データ）は誰が作るか
本番後の改修と保守	保守運用・月額・時間単価表	月額に含む作業はどこまでか
契約形態	契約条件・支払条件	完成の義務を負う形か
引き継ぎ資料	納品物一覧・成果物の権利	契約終了後に自社で直せるか
検証（PoC）の位置づけ	進め方・スケジュール・費用	続けない判断はいつ誰がするか

1. 対象業務の切り出し方が具体的か

「請求書処理の自動化」のような業務名だけが書かれた提案は、あとで範囲の解釈が分かれます。読むべきなのは、処理の開始と終了がどこか、月あたり何件を想定しているか、どの書式まで対象か、対象外はどう扱うかです。

具体的に書かれている提案は、たとえば「月に届く約400通のうち、指定の5書式を読み取り、それ以外は担当者へ差し戻す」という形になっています。件数と書式の数が入っているため、想定と違ったときにどこがずれたかを指摘できます。

書かれていない場合は、対象から外れる処理を列挙してもらいます。あわせて、例外が想定より多かったときに費用と期間がどう変わるかを聞きます。この答えが「その都度ご相談」だけの場合、変更のたびに見積と待ち時間が発生します。処理件数や書式の数は自社でも数えておき、同じ資料を全社へ渡すと、各社の前提を揃えられます。

2. どのシステムにどこまでの権限でつなぐか

エージェントは既存システムへつないだ時点から、社内の情報を読み、場合によっては書き込みます。提案書では構成図や外部連携の一覧に出ますが、権限の範囲まで書かれているものは多くありません。

確認するのは、接続先ごとに読み取りだけか書き込みまで行うか、どのアカウント名義で接続するか、操作の記録がどこに残るかの3点です。読み取りで足りる処理に書き込み権限を渡す構成になっていれば、その理由を聞きます。

書き込みを行う処理については、誤った書き込みが起きたときに元へ戻す手順を提案側に説明してもらいます。ここが決まっていないと、社内の情報システム部門の審査で止まります。審査に必要な資料を出せるかも、この段階で確認しておく項目です。

3. 評価の方法と合格ラインを誰が決めるか

「精度90%以上を目指します」という記述だけでは、本番へ進めてよいかを判定できません。何件のどの処理を対象に測るか、正解を誰が作るか、どの種類の誤りなら許容するかが決まっていないためです。

読むのは受入基準や検証計画の節です。対象件数、測る指標、判定する人が書かれているかを見ます。誤りを一律に扱わず、金額や社外への送信に関わる誤りは1件でも不可、表記のゆれは許容する、といった区別があるものは、本番へ進めてよいかの判定にそのまま使えます。

正解データを誰が用意するかは費用より先に確認します。過去の処理結果を集める作業は社内でしか行えないことが多く、ここに社内の工数が入ります。あわせて、合格ラインに届かなかったときに何回まで、どの範囲を無償で直すかを聞きます。

4. 本番後の改修と保守を誰がどの単価で持つか

稼働してからの費用は、提案書の後ろのほうに小さく書かれます。月額の保守費に何が含まれるかを、次の3種類に分けて確認します。障害が起きたときの対応、利用しているAIモデルの更新への追従、業務が変わったときの仕様変更です。

多いのは、障害対応だけが月額に含まれ、仕様変更は別見積になっている形です。それ自体は妥当ですが、業務の書式が年に何度も変わる場合は、変更のたびに見積と承認の時間がかかります。月額に含む作業時間、超過分の時間単価、連絡してから着手までの目安を数字で出してもらいます。

AIモデルの利用料は開発費とは別に、使った分だけ毎月かかります。誰の名義の契約で、誰が支払うのかを確認します。委託先の名義でまとめられていると、契約が終わったときに引き継ぎが必要になります。

5. 契約形態で変わる責任範囲

同じ金額でも、契約形態によって「完成させる義務があるか」が変わります。提案書の本文ではなく契約条件の節に出るため、読み飛ばしやすい箇所です。

契約形態	委託先が負うもの	向いている状況
受託（請負）	決めた成果物の完成と、不具合の修補	範囲と合格ラインを先に固められる
準委任	決めた期間の作業。完成の義務は負わない	進めながら仕様を決めていく
ラボ型	一定の人員を期間中確保すること	稼働後も改修が続く前提で任せる

受託で頼むときは、範囲外の変更がすべて変更契約になる点に注意します。要件がまだ動く段階で選ぶと、変更のたびに契約の調整が入り、手戻りに時間がかかります。

準委任で頼むときは、何をもって作業が終わるかを別に決めておく必要があります。提案書に納品物の一覧が書かれているのに契約形態が準委任になっている場合は、どちらの理解で進めるのかを確認します。

ラボ型では、発注のたびの調整が減る一方で、依頼する作業が途切れると、確保した人員の手が空いたまま費用だけがかかります。社内で依頼を出し続けられる担当者がいるかが前提になります。

6. 引き継ぎ資料と社内に残るもの

契約が終わった後に自社で直せるかは、納品物一覧に何が並んでいるかで決まります。動くものだけを受け取っても、直したいときに手を付けられません。

実装したコードの一式と、その権利が自社に帰属すること
実行環境の名義（自社の契約か、委託先の契約か）
設定値と鍵の管理場所、権限を持つ人の一覧
AIに渡している指示文と、判断の基準になっている資料
変更の履歴と、その変更を行った理由
運用の手順書と、止まったときの対処

このうち抜けやすいのは、AIへの指示文と判断基準です。AIがどう動くかを決めているのはこの2つなので、渡されないと社内で直せません。受け取ったものを誰が保管し、どこに置くかも先に決めておきます。

7. 検証（PoC）の位置づけと打ち切り条件

多くの提案は検証から始まる形になっています。ここで確認するのは、その検証で何を確かめるのかが1〜2個に絞られているかです。「有効性を確認する」だけの記述では、終わったときに判定できません。

期間と成果物、検証費用が本番の開発費に含まれるのかも見ます。検証の結果に関わらず本番へ進む前提で組まれている場合、続けるかどうかを判断する場面が実質的にありません。

そして、続けない場合の条件を先に書いておきます。読み取りの正解率が一定に届かない、対象業務の例外が想定の何倍にもなった、接続先のシステムが必要な形でデータを出せない、といった具体的な事象で決めます。判断する日と判断する人も入れます。

提案を受け取ってから発注までの流れ

7項目を照合すると、多くの提案では2〜3項目が書かれていません。書かれていない項目を質問し、返答を書面で提案書へ追記してもらってから並べます。口頭の回答だけで進めると、着手後に解釈が分かれます。

不足の質問と書面での追記を挟んでから、同じ枠で並べて比べる。

質問は全社へ同じ文面で送ります。回答の内容だけでなく、答えられない箇所を「わからない」と書いてくるか、確認して後日返すと書いてくるかも判断材料になります。

複数社の提案を同じ枠で並べる

最後に、比較の単位を揃えます。見積の金額だけを並べるのではなく、次の項目ごとに各社の記載を書き写します。書き写せない欄が、まだ確認できていない箇所です。

並べる項目	揃える単位	空欄になったときの扱い
対象業務	処理件数と対象の書式・種類の数	範囲を書面で確定させるまで金額を比べない
接続先	システム名と、読み取り／書き込みの別	権限の一覧を出してもらう
合格ライン	測る件数と指標、判定する人	受入基準として書面に追記してもらう
社内から出す工数	打ち合わせと確認作業に使う、月あたりの時間	自社側で見積もり、金額に足して比べる
初期費用	工程ごとの人数と期間	一式の金額のままなら内訳を依頼する
稼働後の費用	月額の保守費、超過の単価、利用料	12か月分を試算して比べる
引き渡すもの	納品物の一覧と権利の帰属	契約書の条項として確認する
打ち切り条件	判断する日、判断する人、条件	発注前に決めて書面に残す

この表を埋めると、初期費用の安い提案が、社内から出す工数と稼働後の費用を足すと高くなる場合があります。逆に、初期の金額が大きい提案に要件確定と接続の作業が含まれていて、社内の負担が小さいこともあります。比べるのは12か月や24か月といった一定期間の合計額と、その期間に社内から出す時間です。

なお、この記事では具体的な会社名の一覧や順位づけは扱いません。同じ領域で事業を行う立場からの評価になり、比較に必要な一次情報も持たないためです。判断は、自社の業務に対して各社が書いてきた内容で行ってください。

まとめ：提案と見積を判断できる形にする

技術構成の優劣ではなく、後から費用と手戻りにつながる項目が書かれているかを見る
対象業務は件数と書式の数まで書かれているかを確認し、対象外の処理を列挙してもらう
接続先ごとに読み取りか書き込みかを確認し、誤った書き込みの戻し方まで聞く
合格ラインは、測る件数・指標・判定する人が揃って初めて判定に使える
稼働後は保守費に含む作業、超過の単価、AIの利用料の名義を分けて確認する
契約形態で完成の義務が変わる。納品物の記載と契約形態が食い違っていないかを見る
検証は確かめる問いを1〜2個に絞り、続けない条件と判断する人を発注前に決める
比較は見積の金額だけでなく、社内から出す工数と稼働後の費用を足した合計で行う

Augueでは、AIエージェントの開発と、稼働後に社内の担当者が自分で改修を続けられる状態までの支援を行っており、対象業務の切り出しや合格ラインの決め方から一緒に整理しています。届いた提案の読み方や社内で決めておくことを相談したい方は、是非ご相談ください。

自社専用のAIエージェントを作りませんか？

作るか既製品を使うか、費用の目安から相談できます。使うほど育ち、成果が続くAIエージェントの開発をご支援します。開発の進め方と事例はサービス資料でご覧いただけます。

資料をダウンロードする無料相談に申し込む

よくある質問

何社くらいに提案を依頼すればよいですか？

3社前後で足ります。増やすほど比較の手間が増え、同じ質問への回答を読み比べる時間が取れなくなります。それより、少ない社数に対して同じ資料と同じ質問を渡すほうが差が見えます。1社だけで進める場合は、金額の妥当性を判断する材料が無いため、工程ごとの人数と期間の内訳を出してもらってください。

提案依頼書（RFP）は用意したほうがよいですか？

形式の整った文書は必要ありませんが、対象業務の説明、現在の処理件数、接続したいシステムの一覧、いつまでに何ができていてほしいかは書面で渡します。これが無いと各社が別々の前提で見積を作るため、金額を並べても比べられません。1〜2枚のメモでも、全社へ同じものを渡せば役目を果たします。

提案の内容を評価できる人が社内にいない場合はどうすればよいですか？

技術の妥当性を判定しようとせず、書かれていない項目を数えるほうが確実です。対象業務の範囲、接続先と権限、合格ラインの決め方、保守の単価、引き渡すものは、専門知識が無くても記載の有無を確認できます。技術構成の是非を見てもらいたい場合は、開発を請けない立場の第三者に確認を依頼する形もあります。

開発費の相場はどれくらいですか？

対象業務の件数、接続するシステムの数、人が確認する箇所の設計量で変わるため、一律の目安は出せません。判断に使えるのは、工程ごとの人数と期間、社内から出す工数、稼働後に毎月かかる費用（保守と利用料）を合計した金額です。この3つが揃えば、同じ業務を人手で処理し続けた場合と比べられます。