AIエージェント開発会社の選び方｜商談で使える質問リストと見積もりの見極め方

なぜ「安さだけで選ぶ」と失敗するのか

AIエージェント開発の発注で後悔するパターンは、ほぼ共通している。見積もりの最安値を出した会社を選び、要件定義が始まると「それは追加費用です」が続き、リリース後は問い合わせの返答が遅くなる、というものだ。

AIエージェントは通常のWebシステム開発と性質が異なる。動作の確実性がモデルの挙動に依存するため、「要件通りに動く」の定義が曖昧になりやすい。設計段階で業務フローと生成AIの特性を両方理解していない会社に依頼すると、完成物が業務に馴染まないまま費用だけがかかる結果になる。

価格の話は別稿（AIエージェント開発の費用相場）で扱っているため、本記事では「どの会社に頼むか」の判断軸そのものに絞る。

なお、AIエージェント開発会社を紹介する比較サイトの多くは会社名の列挙が中心であり、「何を基準に評価すべきか」という判断軸の解説が薄いことが一般的に指摘されている。本記事はその部分を埋めることを目的としている。

---

選定前に自社で整理しておく3つのこと

商談の場に「AIエージェントを作りたい」だけで臨むと、開発会社の提案を評価する軸が持てない。以下の3点を事前に言語化しておくと、商談の質が大幅に上がる。

1. 解決したい業務課題を具体化する

「業務効率化」では範囲が広すぎる。「営業担当者が週に何時間かけているどの作業を」「どの程度まで自動化したいのか」という粒度まで落とす。この解像度が低いと、開発会社は汎用的な提案しかできず、見積もりも精度が出ない。

2. 成功をどう測るかを決める

KPIが「担当者が楽になった感覚」では検収も難しい。「月次で処理するドキュメント件数が○件以上」「人手での確認工程を○ステップ削減」など、計測可能な指標を持つ。開発会社はこの指標への向き合い方で力量が見える。

3. 予算感と意思決定フローを把握する

POCから始めるのか、最終納品まで一括で発注するのか。予算の承認ラインが複数ある場合は、商談初回からその旨を伝えておくと提案の質が上がる。費用感の詳細は費用相場の記事を参照されたい。

---

開発会社を評価する5つの軸

以下の表は、商談前後に使える評価軸の一覧だ。各軸で「何を確認するか」「どんな回答が望ましいか」をセットで持つと、複数社を比較する際に判断がぶれにくくなる。

評価軸	確認するポイント	望ましい回答の方向性
実績の質	類似業務・類似規模の案件があるか	業務フロー・成果指標を含めて説明できる
技術スタック	LLM・オーケストレーション層・インフラの構成を説明できるか	選定理由と代替案を自分の言葉で話せる
要件定義力	業務側の課題を引き出すヒアリング設計があるか	「何が決まっていないか」を先に整理してくれる
運用保守体制	モデルのバージョンアップ・プロンプトの劣化への対応方針	SLAと対応窓口が契約前に明示される
コミュニケーション	非技術者の担当者と話が噛み合うか	専門用語を使う場合は平易な言葉に置き換えて補足する

---

商談で実際に使える質問リスト

以下の質問は、AIエージェント開発の実務知識がなくても投げかけられるものを厳選した。回答の内容より「どう答えるか」を見る質問も含む。

技術・設計の妥当性を確かめる質問

• 「このシステムでLLMをどのように使いますか？自社でホスティングしますか、APIを呼び出しますか？」
  → 自社データをクラウドAPIに送る構成か、オンプレ・プライベートクラウドか。セキュリティポリシーとの整合を確認できる。
• 「エージェントが誤った出力をした場合、どのように検知・修正しますか？」
  → ハルシネーション対策とモニタリング設計の有無を問う。「精度は高いので大丈夫です」と答える会社には注意が必要だ。
• 「LLMのモデルがバージョンアップされたとき、既存の挙動への影響はどう管理しますか？」
  → 継続的なプロンプト評価・回帰テストの設計があるか。AIエージェントはモデル更新で動作が変わるため、これを軽視する会社はリスクが高い。
• 「今回の要件で、PoCと本番導入の違いは何ですか？」
  → PoCをゴールにしていないか、本番スケールへの設計思想があるかを確かめる。

要件定義・プロジェクト管理を確かめる質問

• 「要件が途中で変わった場合、どのようなプロセスで対応しますか？」
  → 変更管理のプロセスが曖昧な会社は、追加費用の出どころが後から見えにくくなる。
• 「過去の案件で、当初の要件と最終納品が大きく変わった事例はありますか？その原因と対処は？」
  → 失敗経験を自分の言葉で話せる会社は、再発防止の設計が進んでいる可能性が高い。
• 「自社の担当者は開発経験がありません。社内への説明資料の作成はどこまでサポートしますか？」
  → 技術の翻訳力を問う。回答が技術的な説明に終始するようであれば、ビジネス側との対話に課題がある可能性がある。

運用・保守体制を確かめる質問

• 「納品後のサポートは何ヶ月、どの範囲が含まれますか？」
  → 「別途相談」が多い場合は保守費用が青天井になりうる。SLA・対応時間・対応窓口を文書で確認する。
• 「プロンプトや設定ファイルはこちらで直接編集できますか？それとも改修依頼が必要ですか？」
  → ブラックボックス化の度合いを確かめる。自社でチューニングできない構成は運用コストが跳ね上がる。

---

見積もりの妥当性をどう判断するか

費用の絶対額より「何が含まれていて何が含まれていないか」の構造を見ることが重要だ。費用相場の詳細は別記事（AIエージェント開発費用の解説）に譲り、ここでは見積書の読み方に絞る。

チェックすべき項目

• 工程が分かれているか：要件定義・設計・開発・テスト・リリース・保守が別行になっているか。「一式」でまとめられている見積もりは、後から追加費用の根拠として使われるリスクがある。
• PoCの位置づけが明確か：PoCを「無償の提案活動」として扱う会社と「検証コストとして請求する」会社がある。どちらが悪いわけではないが、PoCの目的・成功基準・費用負担を契約前に確認する。
• LLM利用料が含まれているか：OpenAIやAnthropic等のAPI利用料は従量課金だ。開発費とは別にランニングコストとして発生する。見積もりに含まれていない場合、月次の実績費用の見込みを別途確認する。
• 「要件確定後に再見積もり」と明記されているか：要件定義前の概算であれば合理的だが、確定後も金額が変動する条件になっていないかを確認する。

---

良い開発会社と注意すべき開発会社の見分け方

「何でも対応できます」は警戒サイン

AIエージェントの開発には、LLMの選定・プロンプト設計・オーケストレーション・セキュリティ・モニタリングという複数の専門領域が絡む。「どんな要件でも対応できます」と初回商談で即答する会社は、各領域に専門担当者がいるか、外注で賄う構成になっている可能性がある。外注自体が問題なわけではないが、どの領域を内製でカバーしているかは明示的に確認すべき点だ。

自社で動かした経験があるかを問う

クリスタルメソッドは、Claude Code（AIコーディングエージェント）を実務に投入し、自社サイトの表示速度を12.89秒から2.03秒に短縮した事例を計測・公開している。この種の取り組みが示すのは「顧客に提案する技術を自社で実際に動かし、何を計測し、何が根拠になるかを確かめている」という姿勢だ。開発会社を選ぶ際、同様に「自社でAIエージェントやLLMを使った業務改善を実行し、結果を計測して公開しているか」を問うことは、技術の実運用経験を判断する有効な手がかりになる。

「実績」の中身を解像度高く問う

「AIエージェント導入実績あり」という表記だけでは判断できない。以下を必ず確認する。

• どの業種・業務領域の案件か
• エージェントの設計（ツール呼び出し型か、マルチエージェント型か）
• 成功・失敗の判断基準は何だったか
• 運用フェーズで発生した問題と対処

「NDA上お話できません」という回答は理解できるが、概要レベルでも話せない場合は、実績の解像度が低い可能性がある。

---

想定シナリオ：商談で起きやすい場面と切り返し方

以下は実際の商談でよくある場面を例示した想定シナリオだ。実在の企業・案件ではなく、発注者が商談前の準備として参考にするための練習用設定として読んでほしい。

シナリオA：「AIで何でもできます」タイプの営業担当との商談

場面設定：社内の見積依頼書類処理を自動化したい情シス担当者が、初回商談に臨んでいる。

営業役：「書類の読み取りから承認フローまで、AIエージェントで全部自動化できますよ。最短1ヶ月で動くものをお見せできます。」

情シス担当者（つまずきがちな返し）：「そうですか、では期待しています。」
→ 具体性の確認なしに進むと、後から「この書類フォーマットは対象外でした」が出やすい。

情シス担当者（望ましい切り返し）：「ありがとうございます。1つ確認させてください。自社の書類は12種類あり、フォーマットが統一されていないものも含まれます。それぞれに対応できるか、どのような前提条件があるか教えていただけますか？」

観察ポイント：

• 例外ケース・非定型データへの言及があるか
• 「できる条件」を先に提示してくれるか
• 「1ヶ月」の根拠（工程・前提）を説明できるか

シナリオB：「実績あり」を強調するが中身が出てこない場合

場面設定：AIエージェントの導入検討を進める事業部担当者。相手は複数の導入実績をアピールしている。

営業役：「AIエージェントの導入実績は多数ございます。詳細はNDAの関係でお伝えできませんが、ご安心ください。」

事業部担当者（つまずきがちな返し）：「そうですか、では信頼できそうですね。」
→ 実績の解像度が確認できないまま進む。

事業部担当者（望ましい切り返し）：「NDAの範囲は承知しました。業種・規模・エージェントの用途（例：社内ヘルプデスク型か、書類処理型か）といった概要レベルであれば教えていただけますか？自社の課題と近いものを判断したいので。」

観察ポイント：

• 業務の種類・規模感だけでも説明できるか
• 自社での検証・運用経験（顧客案件以外）について話せるか
• 「NDAなので一切言えない」が全ての質問に対する回答になっていないか

---

選定後の進め方：初回商談からPoC・契約までの流れ

会社を選んだ後の進行でも、判断が必要な分岐がある。

PoCの設計を共同で行う

PoCは「とりあえずデモを見る」ではなく、「本番導入の判断基準を検証する実験」だ。PoCで何を確かめれば本番に進む判断ができるかを、開発会社と合意した上で始める。この設計を主導的に行える会社は、本番フェーズの要件定義力も高い傾向がある。

契約前に確認すべき3点

• 成果物の定義：ソースコード・ドキュメント・プロンプトファイルなど、何が納品物に含まれるかを明示する。
• 知的財産の帰属：カスタムプロンプト・学習データ・設計書の権利が発注者に移転するかを確認する。
• 解約・引き継ぎ条件：途中で開発会社を変更する場合、どの程度のコストと工数が発生するかを契約前に把握する。

---

よくある質問（FAQ）

Q. 開発実績が少ない会社でも信頼できますか？

実績の件数より内容の方が重要だ。類似業務での経験が1件でも、課題・設計・成果を詳細に語れる会社の方が、実績多数でも中身が出てこない会社より判断材料になる。また、自社サービス・業務でAIエージェントを実運用している会社は、顧客向け案件以外の検証経験として評価できる。

Q. 技術者が社内にいない場合、要件定義はどこまで自分でやる必要がありますか？

「解決したい業務課題」と「成功の定義」の2点は、発注者側が言語化する責任がある。技術的な要件（どのLLMを使うか・アーキテクチャ）は開発会社が提案する領域だ。ただし、その提案内容を理解・承認できる程度の知識は持った方が判断の質が上がる。機械学習の基礎など関連知識の概要を把握しておくと、商談での理解が深まりやすい。

Q. 複数社から提案を受ける場合、どう比較すればよいですか？

同一の業務課題・データ・制約条件を全社に提示し、同じ質問を投げることが前提だ。提案内容・見積もり・体制の違いが明確になる。評価軸は本記事の比較表（5軸）をベースに、自社の優先順位（例：セキュリティ重視・スピード重視）を加重して使う。

Q. PoCが成功したら必ずその会社に本番発注する必要がありますか？

法的には、PoCを別契約にしていれば本番発注の義務はない。ただし、PoCで設計したアーキテクチャや蓄積したデータの権利が発注者に帰属しているかを事前に確認しておく。別の会社に引き継ぐコストが発生することを想定して、契約段階で取り決めておくことを勧める。

---

まとめ

AIエージェント開発会社の選定は、「どの会社がおすすめか」のランキングではなく、「自社の課題に対して適切な設計・運用体制を持つ会社かどうか」を判断する作業だ。

本記事で示した評価軸・質問リスト・見積もりチェックポイントは、いずれも商談の場で今日から使えるものを選んだ。複数社との商談を通じて、回答の内容より「どのように答えるか」「何を先に話すか」「何を確認しようとするか」という姿勢を観察することが、最終的な選定精度を上げる。

技術の話についていけるかどうかより、業務課題を正しく理解しようとする姿勢があるか、リスクを正直に伝えるかどうか、という点を軸にすると、長期的に信頼できるパートナーを見極めやすくなる。

---

本記事はクリスタルメソッド株式会社が執筆しています。同社はAIエージェント・業務自動化システムの開発を手がけており、本記事の内容には利益相反が生じる可能性があります。判断の参考情報としてご活用ください。

---

参考文献

• クリスタルメソッド株式会社「Claude Codeを使った自社サイト表示速度改善の記録」
  https://crystal-method.com/blog/
• クリスタルメソッド株式会社「機械学習とは何か」
  https://crystal-method.com/blog/machine-learing/