AIエージェントの開発会社を選ぶ際の5つの確認点

相見積もりで3社の提案を並べた。1社は「マルチエージェント」、もう1社は「独自RAG」、残る1社は「最新モデル対応」を強調している。デモはどれも滑らかだ。価格も一見すると比較できそうに見える。

ところが、提案した人が実装にも入るのか、似た案件を本番まで運用したのか、外部サービスの契約は誰が持つのかが分からない。安い提案には評価や監視が含まれず、高い提案には内製化支援まで入っているかもしれない。これでは金額の差ではなく、前提の差を見ている。

AIエージェントの開発会社を選ぶときは、会社一覧やデモの印象だけでは足りない。実績の証拠、実働体制、見積条件、自社での変更・移管、運用と契約終了時の引き継ぎの5点を、同じ質問で比べる。ここでは、提案依頼書と商談でそのまま使える形に落とす。

AIエージェントの開発会社は一覧だけで決めない

AIエージェントは、社内文書を探すだけの仕組みから、CRM更新やメール送信まで行う仕組みまで幅が広い。「AIエージェントの実績あり」という一文だけでは、自社案件との距離を測れない。

たとえば、FAQ検索を作った経験があっても、顧客別の価格を判断し、承認後に基幹システムを更新する案件とはリスクが違う。PoCを3週間で作れた実績と、1年間止めずに運用した実績も別物だ。

経済産業省のAI事業者ガイドライン（第1.2版）は、AI開発者、AI提供者、AI利用者など主体ごとの役割を整理している。発注案件でも、モデル提供者、開発会社、クラウド事業者、利用企業が連なる。社名だけでなく、誰が何を担うかを確認する必要がある。

比較を始める前に、各社へ同じ業務シナリオを渡す。例は「REQ-12：商談メモを読み、承認済み価格表を参照し、見積書の下書きを作る。価格の根拠が競合した場合は自動作成せず、営業責任者へ戻す。承認後だけCRMへ記録する」でよい。入力、成果物、外部連携、承認、月間件数、受け入れ条件をそろえ、5つの確認点すべてをREQ-12の実現方法と証拠へ紐づける。

AIエージェントの開発会社を選ぶ際の5つの確認点

ここからは、候補会社へ同じ順番で聞く5つの確認点を見ていく。回答は口頭だけで終わらせず、提案書・体制表・見積明細・移管条件へ落とす。

確認点1：類似実績を「条件」で説明できるか

導入企業のロゴや案件数は入口にすぎない。知りたいのは、自社と近い条件で何を担当し、どこまで本番化したかだ。

候補会社には、機密を伏せたまま次の項目を説明してもらう。

ここで「同業界の実績があります」だけなら弱い。業界が違っても、同じ権限構造や同じ承認の重さを扱った経験は参考になる。反対に、同業界でもデモ止まりなら、本番運用の証拠にはならない。

数字を出す場合は分母も聞く。「精度95%」なら、何件を誰が採点したのか。「工数を半減」なら、対象工程と測定期間は何か。公開できない案件では、REQ-12に近い評価表の匿名サンプルでもよい。可能なら事例担当者へ、追加費用の原因や障害時の対応も確認する。

確認点2：提案チームと実働チームが一致しているか

商談では、経験豊富な責任者が説明する。受注後は別チームが入り、さらに実装が再委託される。受託開発では珍しくないが、AIエージェントでは役割のずれが設計へ直結する。

提案書には、氏名を出せる範囲で役割と稼働割合を入れてもらう。

• 業務要件を整理する人
• AIの評価方法を決める人
• アーキテクチャと外部連携を設計する人
• セキュリティを確認する人
• 運用開始後の窓口

重要なのは肩書より責任だ。業務要件の責任者が、要件確定後も評価レビューへ参加するか。アーキテクトが週何時間入るか。障害時に営業窓口を経由せず技術責任者へ届くかを確認する。

再委託があるなら、会社名、担当範囲、アクセスするデータ、成果物のレビュー責任も聞く。外部事業者も別に一覧化すると、データの流れを追いやすい。

日本ディープラーニング協会の生成AI開発契約ガイドラインは、生成AIを組み込んだシステムを外部委託する場面を対象に、契約ひな形を含む資料を公開している。個別案件では法務確認が必要だが、役割、成果物、データ、責任の接点を早くから話す材料になる。

チーム変更時の条件も決めたい。主要メンバーが抜けたら通知する。引き継ぎ期間を置く。交代者の経験を確認する。体制表には、REQ-12の要件責任者、実装責任者、試験責任者も明記する。ここまで合意すれば、「会社を選んだのに、実際は知らないチームだった」を避けやすい。

確認点3：相見積もりの前提をそろえられるか

価格差が大きいとき、値段より先に範囲を疑う。A社はPoCだけ、B社は本番連携まで、C社は監視と半年の改善まで含んでいるかもしれない。

提案依頼書では、次の欄を全社共通にする。

「一式」は減らす。モデルAPI、検索基盤、監視、外部ツール、人による確認など、継続費用も分ける。月間件数が10倍になった場合の試算を頼むと、固定費と変動費の構造が見える。

契約形式にも向き不向きがある。仕様を固定しやすい連携と、試行錯誤が必要な評価改善を同じ固定価格へ押し込むと揉めやすい。請負と伴走型支援の範囲は、法務・調達担当と整理する。

AIエージェントの開発見積もりで確認したい6仕様では、金額を左右する仕様を詳しく整理した。会社選定では詳細を繰り返さず、REQ-12の実装・評価・監視・移管が見積もりに含まれる範囲と追加単価だけを横に並べる。

確認点4：自社で変更・移管できるか

納品物があっても、自社で変更できるとは限らない。開発会社のクラウドアカウント、非公開の管理画面、独自基盤に依存すると、担当会社の変更や内製化が難しくなる。

契約前に、所有者と更新者を一覧にする。

• ソースコードとリポジトリ
• クラウド、モデルAPI、外部ツールのアカウント
• プロンプト、ツール定義、モデル設定
• 評価データと採点基準
• 構成情報、監視設定、運用手順
• 利用データ、ログ、バックアップ

すべてを自社だけで持つ必要はない。ただし、終了時に移管できるか、標準形式で出せるか、別モデルや別クラウドへ替えるとき何が作り直しになるかは把握したい。

候補会社には「明日、別チームが引き継ぐなら何を渡せますか」と聞く。この質問は強い。設計が文書化されているか、特定担当者に依存していないか、評価を再現できるかが一度に出る。

セキュリティ面でも変更権限は重要だ。OWASP GenAI Security Projectは、LLMアプリケーションだけでなく、自律エージェントや複数段のAIワークフローに関する安全性も扱っている。資格情報の失効、外部ツールの停止、ログの保全を自社側で実行できるか確認する。権限の比較項目はAIエージェントのセキュリティで見る5つの境界も参考になる。

確認点5：運用と契約終了時の引き継ぎを説明できるか

AIエージェントは、納品日が完成日ではない。業務ルール、参照資料、モデル、外部サービスが変わる。運用提案には、障害対応だけでなく、変更を評価して反映する流れが必要だ。

最低限、次の条件を確認する。

• 何を監視し、どの失敗を通知するか
• 問い合わせの受付時間と一次回答時間
• モデルやプロンプト変更後に何を再評価するか
• 月次報告に品質、費用、人手介入を含むか
• 重大障害時に停止・切り戻しできるか
• 契約終了時の移管期間、費用、データ削除方法

NIST AI RMF Playbookは、Govern、Map、Measure、Manageの4機能に沿ってAIリスクへの行動例を示す。提案会社がPoCの測定で終わらず、運用で見つけた問題を管理と改善へ戻せるかを見る材料になる。

契約終了時の条件は関係が良い段階で決める。移管資料をいつ更新するか。後任への説明を何回行うか。自社データとバックアップをいつ削除するか。未解決の障害や改善案をどう渡すか。これらの整備状況は、運用が特定担当者だけに依存していないかを確認する手掛かりになる。

25点の選定表で足切りする

5項目を各5点で採点する。0〜2点は口頭回答だけ、条件付き、担当未定の状態。3点は条件を文書で説明できる。4点は匿名サンプルや手順を提示できる。5点はREQ-12に対応する契約成果物と責任者まで確定できる状態とする。

合計点だけで決めない。自社で停止できること、契約終了時にデータを削除・移管できること、再委託先を把握できることは足切り条件にする。たとえば各項目3点以上かつ足切り条件を満たした候補だけを、価格、業界経験、提案速度で比較する。

Atsumellの視点

Atsumellが提案比較を支援するときは、各社へ自由に解決策を書いてもらう前に、要求IDと受け入れ条件をそろえる。たとえば「REQ-12：価格の根拠が競合した場合は自動作成せず営業責任者へ戻す」と書く。候補会社は、その要求をどの構成で満たし、どう試験するか回答する。

この形なら、技術名が違っても比較できる。選定後も、要求IDを見積項目、テスト、検収、運用変更へつなげられる。仕様は発注のためだけでなく、合意を保つ台帳になる。

AIエージェントの開発パートナー選びで、提案依頼書や受け入れ条件から整えたい場合は、株式会社Atsumellへ相談する。業務整理、候補比較、評価設計、本番運用、引き継ぎまでを同じ仕様でつなげられる。

関連記事

• AIエージェントの開発見積もりで確認したい6仕様
• AIエージェントの開発現場で見えた「動くもの」の条件
• AIエージェントに「文脈」を渡す技術 — 仕様書の構造がすべてを決める