AIコンサルとAI開発会社はどう違う？構想・PoC・本番化で使い分ける

AIコンサルとAI開発会社の違いは、会社の看板だけでは決まらない。現在はコンサル会社がPoCや実装まで扱い、開発会社が業務整理や構想づくりから入る例もある。選ぶ基準は、今の段階で必要な成果物を誰が作り、誰がその結果に責任を持つかだ。

課題がまだ「生成AIを使いたい」にとどまるなら、先に必要なのは構想支援である。対象業務、期待効果、止める条件をすでに決めているなら、システム設計、データ処理、評価、本番運用を引き受けられる開発体制を比べる。

会社の種類よりプロジェクトの段階を合わせる

外部支援を構想、PoC、本番開発、運用の4段階に分けると、依頼内容を整理しやすい。

段階	必要な成果物	主に重視する能力	発注側に残る判断
構想	対象業務、現状の費用、期待効果、リスク、優先順位	業務整理、経営・現場との合意形成、投資判断	何を変え、何を変えないか
PoC	検証仮説、テストデータ、試作、評価結果、次段階の条件	データ準備、短期実装、評価設計	何をもって成功・中止とするか
本番開発	要件、設計、実装、テスト、移行、引き継ぎ	ソフトウェア開発、セキュリティ、既存システム連携	受入条件と変更管理
運用	監視、障害対応、モデル変更時の再評価、改善手順	運用設計、ログ、サービス水準、継続評価	予算、権限、停止判断

この表の「主に」は一般的な役割分けであり、会社種別の保証ではない。PwCは現行サービスで、ユースケース創出からPoC、本格導入、定着までを一貫して支援すると説明している。NTT DATAもデータ・AI戦略、基盤構築、実行支援までの範囲を掲げる。コンサル会社だから実装しない、開発会社だから構想を扱わない、とは決められない。

構想が決まっていないなら開発見積を急がない

「問い合わせ対応へAIを入れたい」だけでは、開発会社は正確な見積を作れない。対象の問い合わせ、参照するデータ、誤回答時の扱い、人が確認する範囲、既存CRMとの連携が未定だからだ。

この段階では、短期間で次を決める支援が先になる。

• 現在の業務量と問題
• AIを使わない改善案を含む選択肢
• AIで検証する仮説
• 成功と中止の条件
• データを利用できる範囲
• PoC後に本番へ進む判断者

AWSのPath-to-Valueは、PoCから本番へ進む際の障害を価値、リスク、技術、人の4面に分け、データアクセス、既存システム連携、評価、監視、運用の複雑さを挙げている。画面の試作だけを先に発注しても、これらが未決定なら本番化の見積は後から膨らみやすい。

構想支援の成果物は、きれいな将来像だけでは足りない。PoCで何を試し、結果がどの数値なら次へ進むかまで決まって初めて、開発会社へ比較可能な依頼を出せる。

作るものが決まっているなら開発責任を確認する

要件がある程度固まっている場合は、技術名より納品責任を見る。「RAGに対応」「最新モデルを使用」という説明だけでは、発注側が必要とする業務システムの完成条件は分からない。

開発提案では少なくとも次を確認する。

• どのデータを誰が準備・加工するか
• プロンプト、検索処理、画面、APIのどこまでが成果物か
• テストデータと評価指標を誰が作るか
• 既存システムとの接続、認証、ログを誰が実装するか
• 本番移行、監視、障害対応を誰が担当するか
• モデルや外部APIの変更時に、誰が再評価するか

デジタル庁の2026年版ガイドラインは政府調達向けだが、契約や仕様書へ入力データ、出力、期待品質、リスク発生時の対応、運用上の義務を盛り込むという整理は、民間の発注でも確認項目として使える。政府向けの規範をそのまま民間契約へ当てはめるのではなく、抜けを見つけるチェック材料として読む。

PoCは「動いた」で検収しない

PoCを依頼する場合、デモ画面が表示されたことだけで成功としない。NIST AI RMFは、AIの評価について、目的に合う指標と方法を選び、再現可能なテスト・評価・検証を文書化する考え方を示している。

発注前に最低限、次を固定する。

1. 対象業務と利用者
2. 入力例と期待結果を含むテストデータ
3. 品質、応答時間、1件当たり費用、安全性の基準
4. 許容できない失敗と許容回数
5. 結果を残すファイルやレポート
6. 次段階へ進む承認者

これを決める能力が外部に必要なら、PoC前の構想支援を依頼する。自社ですでに決められるなら、開発会社には実装と評価の再現性を求める。

費用は肩書ではなく範囲で比べる

コンサル費と開発費を単純に比較しても意味は薄い。構想支援の見積に本番コードが含まれないこともあれば、開発見積にデータ整理、現場ヒアリング、運用設計が含まれないこともある。

同じ表へそろえるべきなのは、次の5項目だ。

比較項目	見積で確認する内容
構想	業務分析、効果試算、リスク整理、意思決定資料
データ	取得、権利確認、匿名化、整形、正解データ作成
開発	試作か本番品質か、外部連携、テスト、文書
運用	監視、障害対応、改善、モデル変更時の再評価
実費	クラウド、API、ライセンス、評価実行、外部サービス

経産省のAI契約チェックリストは、提供データの利用範囲、入力・出力、サービス水準、利益とリスクの分配を契約前に確認するよう整理している。見積金額だけでなく、何を受け取り、何を事業者側が使えるのかまで比較する必要がある。

迷ったら不足している成果物で決める

課題の優先順位、期待効果、PoCの成功条件が未決定なら、構想を具体化できるパートナーが先になる。作る機能、データ、受入条件が決まっているなら、設計・実装・移行・運用の責任を証明できる開発体制を選ぶ。

両方が必要なら、1社へ一括依頼しても、構想と開発を別会社へ分けてもよい。ただし境界では、要件を確定する人、テストデータを作る人、本番移行を承認する人をそれぞれ明記する。

自社側に意思決定者がいない状態は、外注だけでは解消できない。対象業務と中止条件を決める責任まで外へ渡すと、成果物が納品されても「使うべきか」を判断できなくなる。まず社内の責任者を決め、その人が不足する成果物に合わせて外部支援を選ぶ。