「AIコンサルを発注したいが、何を聞けば良いかわからない」「複数社から提案を受けたが、比較軸がブレる」「契約後に『話が違う』と気付くのが怖い」——AIコンサル選定の発注担当者が口にする悩みは、突き詰めると一点に集約される。提案の良し悪しを測る自分なりの物差しを持たないまま、相手の土俵で評価してしまっている、ということだ。
発注の現場でつまずく企業に共通するのは、評価軸を持たずに知名度や提案書の見栄えだけで選んでしまう構図である。AIコンサルの提案書は、どの会社のものも一見すると似た図表と似たフレームで構成されているため、横並びで眺めているだけでは差が見えてこない。差が表面化するのは、たいてい契約後、実装フェーズに入ってからである。だからこそ、発注前のヒアリングで意図的に差をあぶり出す質問を投げかける必要がある。
国の側でも論点整理は進んでおり、経産省は2025年2月に「AIの利用・開発に関する契約チェックリスト」を取りまとめ、契約前に確認すべき事項を明示した。本稿では、このチェックリストの考え方を踏まえつつ、AX Boost が発注前ヒアリングで実際に効くと考える質問群と、相手の答えから危険を読み取るための着眼点、そして複数社を比較して最終契約に至るまでの判断の流れを、発注担当者の目線で解説する。コンサル選定そのものの上位フレームはAX支援サービスの選び方、契約形態の違いは伴走型 vs スポット型 vs FDE型、生成AIコンサルの全体像は生成AIコンサルティングとはで扱っているので、あわせて参照してほしい。
なぜ質問の設計が選定の精度を決めるのか
AIコンサルと一口に言っても、戦略コンサル、大手SI、AI専業ベンチャー、そしてFDE型のブティックまで、出自も得意領域もまったく異なるプレイヤーが同じ看板の下に混在している。同じ「AIコンサルティング」という言葉を使っていても、扱える階層は戦略提言止まりなのか実装まで降りられるのか、現場への関与はどの程度の深さなのか、メンバー自身がコードを書けるのか、特定業界の規制や商習慣を肌で知っているのか、契約は人月なのか成果報酬なのか——こうした基底の違いが、提案書の表面ではほとんど見えない。
ブランドや見積金額だけで判断すると、自社のフェーズに合わない相手を選んでしまい、結果としてPoCが本番に届かない、あるいは本番化が延々と遅れるという形でツケが回ってくる。質問の設計が重要なのは、それがベンダー間の構造的な差を可視化し、自社のいまの段階に本当にフィットする相手を見極めるための、数少ない能動的な手段だからである。以下では、発注前に確かめておきたい論点を、実装力・業界理解・出口設計・採算・体制・柔軟性・統制という順に掘り下げていく。
実装まで降りられるか — コード執筆能力を確かめる
最初に確かめたいのは、その会社が戦略レポートを書いて終わりなのか、それとも提案後に自分たちの手で動くものを作れるのか、という点である。ここを曖昧にしたまま発注すると、立派な構想だけが残り、実装は別の誰かに丸投げされる構図に陥りやすい。
確認の仕方はシンプルでよい。「貴社のメンバーは、提案後にプロダクションコードを書きますか」と単刀直入に尋ね、続けて「過去に実際に納品した、動いているシステムの例を見せてください」と求める。後者に対して具体物が出てこない場合、その会社の実装能力は紙の上だけの可能性が高い。
危ういのは、答えが「実装は別パートナーと連携します」「弊社はあくまで戦略策定までです」「外部の協力会社が実装します」といった形で、実装責任を外部に逃がす言い回しになっているケースだ。これらが危険なのは、戦略を描いた当事者と手を動かす当事者が分かれた瞬間、要件の解釈ズレや責任の押し付け合いが起きやすくなり、PoCと本番のあいだの溝がそのまま放置されるからである。FDE型のコンサルティングでは現場でコードを書くこと自体が標準動作であり、構想と実装が同じチームの中で閉じる。「コードを書けないAIコンサル」がPoC止まりの典型原因になる理由は、この構造的な分断にある。掘り下げはFDE型コンサルティング完全解説とAI PoC止まり脱出フレームワークで扱っている。
自社業界の言語を話せるか — 規制と業務文化への理解
二つ目は、相手が自社の業界特有の規制・業務文化・データの癖をどこまで理解しているかである。汎用的なAIの知識があっても、業界固有の制約を踏まえなければ、机上では正しくても現場で使えない提案になる。
「同業界での過去案件は何件あるか」「金融なら金融庁、医療なら薬機法といった業界特有の制約にどう対応してきたか」を尋ね、さらに踏み込んで、その業界で起きがちな落とし穴を具体例で語れるかを確かめたい。経験のある相手なら、抽象論ではなく「この業界ではここで必ず詰まる」という固有名詞混じりの話が出てくる。
逆に、何を聞いても「業界横断で対応できます」としか返ってこない、あるいは金融庁AIディスカッションペーパー、PMDA SaMD、経産省AI事業者ガイドラインといった業界特有の規制名がまったく出てこない場合は、その業界での実戦経験が乏しいと見てよい。過去事例を尋ねても件数や成果の数値が曖昧なら、なおさらだ。これらが警戒に値するのは、業界知見の欠落が後工程で要件の作り直しや規制対応の手戻りとして顕在化し、コストと納期を直撃するからである。業界別の論点は製造業のAI活用、金融機関のAI活用、医療機関のAI活用、小売・EC業界のAI活用、物流・サプライチェーンのAI活用、SaaS / IT業界のAI活用でそれぞれ整理している。
自分たちが抜けた後を描けるか — 内製化と出口設計
三つ目は、契約が終わった後の世界を相手がどう設計しているかである。優れたコンサルほど、自分たちがいなくなっても顧客が回り続ける状態を出口として描く。逆に、自社への依存が続くほど儲かる構造の相手は、無意識のうちにロックインを選びがちになる。
確かめたいのは、「12ヶ月後・24ヶ月後の引き継ぎプランを契約に含められるか」「貴社が抜けた後、自社で運用を継続できるドキュメントとコードの状態を保証してくれるか」「内製人材の育成プログラムは含まれるか」といった、出口の具体性である。
「引き継ぎは別途相談」と濁す、ベンダー独自プラットフォームへの依存を強く勧めてくる、あるいは内製化の話を持ち出すと急に歯切れが悪くなる——こうした反応が要注意なのは、それが「抜けにくくして稼ぐ」インセンティブの表れである可能性が高いからだ。ここはコンサルの利害と顧客の利害が最も衝突しやすい論点でもある。AX Boostが成果報酬型を軸に置くのは、顧客の工数が減って自走できるようになることが自社の報酬につながる構造、すなわち利害が一致する設計を取りたいからである。AIの導入を「ツールの足し算」ではなく「人がやらなくてよい仕事を見極めて引き算し、空いた工数を価値ある仕事へ再配置する」営みとして捉えれば、出口は依存ではなく自走に置くのが筋になる。この考え方はAIは足し算より引き算 — 労働の再配置で、内製化と外注の損益分岐はAI内製化 vs 外注で掘り下げている。
採算の見通しに根拠があるか — ROIとKPIの具体性
四つ目は、投資対効果の語り方である。AIの採算は読みにくいテーマだが、読みにくいことと、説明を放棄してよいことは別である。
「ROIの試算根拠と前提条件を見せてほしい」「成功条件・KPIを事前に合意できるか」「過去案件のROI実績データを共有できるか」と問えば、相手が採算をどこまで真剣に詰めているかが透けて見える。前提条件と感度を添えて試算を示せる相手は、少なくとも採算から逃げていない。
注意したいのは、「ROIは導入してみないとわからない」と最初から測定を放棄する、試算が「年間〇〇億円削減」のような根拠の薄い大づかみの数字にとどまる、KPIの事前合意そのものを避けようとする、といった態度である。これらが危険なのは、成果の定義を曖昧なままにしておけば、後から「これは成果だ」「いや違う」という水掛け論を招き、精算の段で揉める火種になるからだ。経営層を巻き込んで成功条件を先に握っておくことが、この種の紛争を防ぐ最も確実な手立てになる。ROI測定の枠組みはAI ROIの測定方法、投資判断を経営の意思決定に乗せる組み立てはAI予算計画と社内稟議、報酬を成果に連動させる契約は成果報酬型AIコンサルティングで扱っている。
誰が、どれだけ関わるのか — 伴走体制の実体
五つ目は、契約書の社名ではなく、実際に手を動かす個人の話である。提案の場に出てくるエース級の人材と、プロジェクトに張り付く担当者が別人だった、というすれ違いは珍しくない。
だからこそ「実際にこのプロジェクトを担当する個人の経歴を見せてほしい」「週に何時間関与するのか、オンサイトかリモートか」「問題が起きたときのエスカレーションのプロセスはどうなっているか」を、契約前に具体で確かめておきたい。
「シニアが監修し、実務はジュニアが対応します」という体制は、それ自体が悪いわけではないが、監修の頻度と実務の質が見合っているかを確認しないまま受け入れると、現場の判断力不足に後で苦しむことになる。担当者を明示せず「ベストの人材を割り当てます」としか言わない、関与時間の事前合意を避ける、といった姿勢は、稼働の実体を見せたくない兆候と読むのが安全だ。誰がどれだけ関わるかが曖昧なまま走り出すと、関与の薄さがそのまま進捗の停滞として返ってくる。
変化にどう向き合うか — スコープ変更への柔軟性
六つ目は、計画が変わったときの振る舞いである。AIプロジェクトは、走りながら要件が見えてくることが多く、初期スコープが最後まで固定されるほうが稀だと考えておいたほうがよい。
「初期スコープから追加要件が出たらどう対応するか」「スコープ変更にかかる費用は事前に定義されているか」「契約期間中に優先順位が変わったらどう動くか」を尋ね、変化を前提に設計された契約かどうかを見極めたい。
「追加要件は別契約です」の一点張り、スコープ変更時の費用が不透明、「柔軟に対応します」と言うわりに具体的なプロセスが説明できない——こうした反応は、変化への耐性の低さを示している。これが厄介なのは、変更が発生するたびに交渉と見積りで時間を浪費し、肝心の実装が止まるからだ。変更の起き方と費用の扱いをあらかじめ取り決めておけるかどうかが、プロジェクトの推進力を大きく左右する。
データと撤退をどう守るか — リスク管理とセキュリティ
七つ目は、うまくいかなかったときと、機密情報の扱いに関する備えである。順調なときの話は誰でもできるが、本当に問われるのは失敗時とセキュリティ事案への構えである。
「自社データの取扱いポリシーを文書で見せてほしい」「失敗時の撤退基準や違約金条項はどうなっているか」「ハルシネーション対策やモニタリング体制は整っているか」「機密情報の取扱いについて、ISO27001 / SOC2 等の認証はあるか」を、口頭の約束ではなく書面で確認したい。
セキュリティ態勢が文書化されていない、「失敗の定義は曖昧で」と濁す、データ取扱いポリシーが書面になっていない——これらが危険なのは、いざ事故や撤退の局面になったときに拠り所となる取り決めが存在せず、責任の所在が宙に浮くからである。撤退基準を先に決めておくことは、相手を縛るためというより、自社が深手を負う前に止まれる安全装置を持っておくという意味で重要だ。AIガバナンスの論点は企業のAIガバナンス実務ガイド、ハルシネーション対策の実装はAIハルシネーション対策の実装論、生成物の権利関係はAI著作権リスクの実務対応で扱っている。
公的ガイドラインを共通言語にする
ここまでの七つの論点は、発注側の経験則であると同時に、公的な整理とも重なっている。経産省は2025年2月、生成AIの普及を踏まえて「AIの利用・開発に関する契約チェックリスト」を公表した。そこで挙げられているのは、AIの開発・利用における責任の分担、学習データと出力結果の権利の帰属、セキュリティと機密保持、個人情報の取扱い、そして撤退・解約の条件といった論点である。
このチェックリストの価値は、発注側とベンダーが同じ枠組みを参照することで、暗黙の前提のズレを早い段階で言語化できる点にある。とくに学習データと出力結果の権利、撤退・解約条件は、契約後に解釈が割れやすい領域なので、公的文書を共通言語として持ち込むと交渉が滑らかになる。政策動向の全体像は国の人工知能基本計画、金融分野の規制議論は金融庁ミュトス作業部会から読むで補える。
複数社をどう比べ、どう絞り込むか
七つの論点を各社にぶつけたら、次は回答を突き合わせて絞り込む段階に入る。まずは「ベンダー × 質問」のマトリクスとして回答を一枚に並べてみると、提案書を個別に眺めていたときには見えなかった差が浮かび上がる。同じ問いに対して、片方は固有名詞と数値で答え、もう片方は一般論で逃げている、といった対比が一目で分かるからだ。
並べたうえで、まず効かせたいのが警戒サインによる一次フィルタである。前述した危険な反応が二つ以上重なる会社は、個別の魅力に関わらず原則として候補から外してよい。これは厳しすぎる基準に思えるかもしれないが、警戒サインは単独では偶然でも、複数重なると体質の問題である公算が高くなる、という経験則に基づく。
残った候補については、自社のいまのフェーズとの適合度を評価する。AI成熟度をどう捉えるかはAX、何から始める?で示した3軸が手がかりになる。構想段階の企業に重実装型の体制は過剰だし、逆に本番化を急ぐ企業に戦略提言止まりの相手では物足りない。強みと自社の段階がかみ合っているかを見るわけだ。
そのうえで、料金と価値の釣り合いを検証する。AX Boostが市場で観測している相場感を目安として示すと、おおむね次のレンジに収まる。
| フェーズ | 観測される費用レンジ |
|---|---|
| PoC段階 | 40〜200万円程度 |
| 本番実装 | 200〜2,000万円程度 |
| 月次アドバイザリー | 15〜500万円程度 |
このレンジから極端に外れて安い、あるいは高い場合は、なぜそうなるのかを必ず確認したい。安すぎる見積りは関与の薄さや実装の外注を疑う材料になり、高すぎる見積りは何に費用が乗っているのかの説明を求める根拠になる。最後は、提案書の評価だけで決めず、実際にプロジェクトを担当する個人と面談し、相性と熟練度を自分の目で確かめてから判断したい。紙の上の体制図と、目の前の担当者の受け答えが一致しているかどうかは、面談でしか分からない。
契約に落とし込む前のチェック
最終契約に進む前には、口頭で握ったつもりの事項を契約条文に落とし込めているかを点検しておきたい。実務上つまずきやすいのは、成果物の定義(文書の範囲・機能要件・評価基準)、コードやデータ、モデルの所有権を定める知的財産権の帰属、成果報酬型なら特に重要になるKPIと精算ルール、外部APIやライセンス費の負担者、中途解約の条件と精算の扱い、失敗時の撤退基準、そしてNDAの対象範囲と期間、といったあたりである。
これらは個別に見れば当たり前の項目だが、曖昧なまま走り出すと、いずれもプロジェクト中盤以降に「言った言わない」を生む種になる。発注前ヒアリングで確かめた内容が、そのまま契約条文として書き残されているか——この一点を最後に確認しておくことが、後の紛争を最も効率よく予防する。資金面の段取りについては補助金の活用も手段の一つになり得るが、これは主役ではなく、詳細はAI予算計画と社内稟議に譲る。
AX Boost が発注前ヒアリングにどう答えるか
ここまで挙げてきた論点は、裏を返せば、AX Boost自身が発注検討の場で問われる問いでもある。AX Boostでは、これらの問いに対して口頭の安心材料ではなく文書での回答を提示することを基本姿勢としている。
実装については、メンバー全員がプロダクションコードを書くことを前提に置き、構想と実装を同じチームの中で完結させる。業界経験は守秘の範囲内で案件別の具体実績として開示し、内製化支援は契約に引き継ぎプランを明記して、自社が抜けた後も顧客が自走できる状態を出口に据える。採算については過去案件のKPIと実績を業種の文脈で共有し、伴走体制は担当する個人の経歴と関与時間を契約書に書き残す。スコープ変更の費用は事前に取り決め、セキュリティ態勢と撤退基準も契約に落とし込む。FDE型コンサルが「現場に深く入る」モデルである以上、この程度の透明性は前提条件であって、特別なサービスではない。
そして根底にあるのは、AIの導入を道具の足し算で測らず、どの仕事を引き算できるかを経営の文脈で見極め、空いた工数を価値ある仕事へ再配置するという発想である。成果報酬型を選ぶのも、顧客が自走に近づくほど自社も報われる、利害の一致した関係を結びたいからにほかならない。選定そのものの上位枠組みはAX支援サービスの選び方とAXコンサルティングとはで、FDE型の中身はFDE型コンサルティング完全解説で詳しく扱っている。
発注前ヒアリングで本稿の論点を実際にぶつけてみたい、あるいは自社のフェーズに合う体制を相談したいという場合は、トップページからお問い合わせいただきたい。
主要参照ソース
本稿で参照した公的文書の一次ソースを以下に挙げる。発注前の確認事項を整理する際の共通言語として、原典にあたることを勧める。
経済産業省『AIの利用・開発に関する契約チェックリスト』(2025年2月)— 生成AIの普及を踏まえ、契約前に確認すべき責任分担・データと出力結果の権利帰属・セキュリティ・撤退/解約条件等を整理した44ページの文書。 https://www.meti.go.jp/press/2024/02/20250218003/20250218003.html
※本稿の費用レンジ(PoC段階・本番実装・月次アドバイザリー)は、AX Boost が案件を通じて観測した範囲であり、公的統計に基づく市場相場ではない。RFPで各社の見積りを比較する際は、金額そのものより前提条件と含まれる範囲を揃えて読むことを勧める。