AI導入支援を掲げる会社は、大きく4つの類型に整理できます。どれが優れているという話ではありません。頼みたい段階と型が合っていないと、提案の時点で話が噛み合わなくなる、という話です。

以下、それぞれの型と、その型に該当する代表的な企業を挙げます。社名は2026年8月時点で各社が公開している情報に基づく分類です。サービス内容は変わるため、実際の検討時は各社の公式サイトでご確認ください。

コンサル型

業務の棚卸しからAI活用の構想を描き、投資対効果（ROI）を検討するところまでを担います。経営層への説明資料としての完成度は高く、全社的な優先順位づけが必要な場合には有力です。

代表的な企業：アクセンチュア、デロイト トーマツ コンサルティング、PwCコンサルティング、KPMGコンサルティング、EYストラテジー・アンド・コンサルティングなどの総合コンサルティングファーム。いずれもAI・生成AI領域の専門組織を設け、戦略立案から実装支援まで幅広く手がけています。

一方で、企業によっては構想・戦略を中心に支援し、実装を別会社と連携して進めるケースがあります。構想と実装の間に別会社が入ることで、引き継ぎが発生する場合があります。

開発型（AI専業）

機械学習やモデル開発を本業とし、精度が要求される案件や研究要素のある案件に強い型です。

この型が向くのは、既存にない精度の判定モデルを作りたい場合です。一方で、業務システムとの接続や、現場が実際に使う画面まわりは範囲外のことがあります。

開発型（システム開発会社）

業務システムやアプリの受託開発が本業で、AIもその一部として扱う型です。既存システムとの連携や、現場で使われる画面を作ることに強みがあります。最先端のモデル研究は範囲外です。

この型は全国に多数あり、規模も地域もさまざまです。特定の数社を挙げるより、自社の対象業務に近い開発実績があるかどうかで探すほうが実際的です。当社（ドコドア）もこの型に該当します。

「AIを業務に組み込んで、現場に使ってもらう」ことが目的なら、この型との相性が良くなります。

ツールベンダー型

自社のAIツールを持ち、その導入と定着を支援します。導入が早く、費用も抑えられ、既存製品の導入実績を活かせる点が特徴です。定型的な業務改善であれば、既存ツールの導入だけで解決できるケースも少なくありません。

代表的なサービス：Microsoft 365 Copilot、ChatGPT Enterprise、Google Workspace の Geminiなどの汎用AIツール。企業としては、AI-OCRのAI inside、チャットボットのユーザーローカルやモビルスなどが挙げられます。

注意点は、提案が自社製品の範囲に収まることです。それが自社の課題に合っていれば最適解ですが、自社製品を前提に提案するため、製品の機能や提供範囲が課題解決の選択肢を制約する場合があります。複数の選択肢を検討したい段階では、別の型にも相談したほうが視野が広がります。

SIer型

基幹システムを含む大規模な案件を、全体として請け負います。体制も実績も厚く、長期にわたる運用まで任せられます。

代表的な企業：NTTデータ、富士通、NEC、日立製作所、TIS、SCSK など。いずれも大規模システムの構築実績を持ち、AI領域にも取り組んでいます。

ただし意思決定の階層が多く、小さく試すことには向きません。1業務に絞って3ヶ月で検証したい、という進め方とは合わないことがあります。

当社はどの型か

当社（ドコドア）はシステム開発会社型です。受託でのシステム・アプリ開発が本業で、AIもその一部として扱っています。

そのため、次のような案件は当社より適した相手がいます。

• 全社的なDX構想から描きたい — コンサル型のほうが体制が合います
• 既存にない精度の判定モデルを研究開発したい — AI専業のほうが知見があります
• 既製ツールで足りる業務を効率化したい — ツールを直接契約したほうが早く、安く済みます

逆に、対象業務は見えているが実際に動くものにできない、既存の業務システムと接続する必要がある、現場に使われる状態まで持っていきたい、という段階であれば、当社の型が噛み合います。

この記事では以降、どの型を選ぶ場合にも使える比較の手順を書きます。AI導入支援の全体像はAI導入支援で整理しています。

支援会社を評価する軸は、おおむね次の7つに整理できます。

• 支援範囲が、どこからどこまでか
• 自社の業種・業務を理解しているか
• PoCの次（本開発）を担えるか
• データ整備をどこまで支援するか
• 内製化を支援するか、外注が続く構造か
• セキュリティ要件に答えられるか
• 見積の内訳が工程単位で割れているか

すべての軸で同じ強さを持つ会社は少なく、何を強みとする会社なのかを見極めることが重要です。

自社の状況によって、重みは変わる

したがって選定作業とは、7軸を平等に採点することではなく、自社にとって重い軸を3つ決め、そこで比較することです。

重い軸を先に決めておくと、提案を受けたときの判断が速くなります。決めていないと、プレゼンの上手さや担当者の印象で決まってしまいます。

評価シートは3社まで

比較検討では、候補を3社程度に絞ると、各社への説明や質疑にかかる負担を抑えながら比較しやすくなります。それ以上になると、各社への説明と質疑だけで1ヶ月以上かかり、比較の前に疲弊します。

類型で当たりをつけてから、同じ型の中で2〜3社、あるいは違う型から1社ずつという選び方をすると、比較の軸が明確になります。同じ型の会社ばかり並べると違いが分かりにくく、違う型ばかり並べると比較になりません。

「答えられない」も情報として扱う

質問に対して即答できなかった場合、それ自体が悪いわけではありません。持ち帰って正確に答える会社のほうが、その場でよい返事をする会社より信頼できることもあります。

見るべきは、持ち帰った質問に、いつ、どういう形で回答が返ってくるかです。この対応速度と丁寧さは、契約後のやり取りをそのまま予告しています。段階別の費用感はAI導入の費用相場で詳しく整理しています。

「御社の業種の実績はありますか」という質問はよく交わされますが、返ってきた実績件数だけでは判断材料になりません。同じ業種でも、担当した業務が違えば理解の深さは変わります。

件数ではなく、制約を知っているかを聞く

業種の理解が本物かどうかは、その業種特有の制約を挙げられるかで分かります。技術ではなく、現場の事情の話です。

• 繁忙期がいつか — その時期に受け入れテストを設定すると、現場の協力を得にくくなります
• 紙やFAXがどこに残っているか — データ化のコストに直結します
• 規制や業界ルールで、できないことは何か — 医療・金融・士業では特に重要です
• 現場の端末環境 — 工場や店舗ではPCの台数や利用できる端末が限られているケースがあります

こうした点を提案の中でどこまで具体的に把握しているかを見ると、業種への理解度を判断する材料になります。提案の中で自然に触れられていれば、その業種で実際に苦労した経験があります。実績の件数だけでは、実務への理解度までは判断できません。

業種特化でなくても問題ないケース

一方で、業種の理解が決定的に重要とは限りません。対象業務が業種に依存しない場合です。

議事録の作成、社内文書の検索、問い合わせへの一次回答、経費精算のチェック。こうした業務は、どの業種でもやることが似ています。この領域であれば、業種特化を条件にすると候補が不必要に狭まります。

業種特化が効くのは、その業界固有の業務にAIを当てる場合です。製造の検査、医療の記録、建設の図面。自社の対象業務がどちらなのかを先に整理しておくと、選定の条件がひとつ減ります。

詳しい事例を聞けないのは、普通のこと

実績を尋ねても、守秘義務を理由に具体的な内容が出てこないことがあります。これは不誠実なのではなく、他社の情報を守っている証拠でもあります。自社が発注したときも同じように守られる、と考えたほうが健全です。

その場合、社名や詳細ではなくプロセスを聞いてください。この聞き方なら、守秘義務に触れずに実力が測れます。

• 「似た案件で、想定と違ったことは何でしたか」
• 「その案件で、お客様側にはどれくらいの作業が発生しましたか」
• 「うまくいかなかった案件があれば、原因は何でしたか」

3つ目のような質問に対して、守秘義務に配慮しながらも具体的に答えられる会社は、過去の経験から学んだことを説明できる可能性があります。成功事例しか出てこない場合、実際に手を動かした量が少ない可能性があります。

「AIの実績」と「業務システムの実績」を分けて見る

もうひとつ確認したいのが、AIの実績だけでなく、その会社が業務システムを作った実績があるかどうかです。

AIを業務に組み込むということは、実際には既存システムとの接続、権限の設計、現場が使う画面の設計を伴います。この部分はAIの技術ではなく、通常のシステム開発の力量が問われます。AIの事例だけが並んでいて、業務システムの実績が見当たらない場合は、そこを補う体制があるかを確認してください。

3社から見積もりが揃ったとき、そのまま金額を並べても比較にはなりません。含まれているものが違うからです。

まず、同じ土俵に乗せる

金額を見る前に、次の項目が各社の見積もりに含まれているかを確認し、含まれていないものは「別途いくらか」を聞いてください。

これらを揃えると、金額差が縮むか、あるいは逆転することがあります。安く見えた見積もりが、範囲を揃えた結果いちばん高くなるのは珍しくありません。

「一式」の見積もりが出てきたら

「AI開発一式 ◯◯◯万円」という1行の見積もりは、比較ができないだけでなく、後の交渉もできません。何を削れば安くなるのかが分からないためです。

工程ごとに割った見積もりを依頼してください。断られる場合、その理由を聞く価値があります。工程を分けられない理由を確認してみましょう。見積の根拠や前提条件が明確になっているかを確認することが重要です。

安さの理由を確認する

他社より明らかに安い見積もりが出てきたとき、確認したいのは次の3点です。

• 作業範囲が狭いのか（範囲を揃えれば同等になる）
• 既製の仕組みを流用できるのか（合理的な安さ。むしろ有力）
• 実績を作るために採算度外視で受けているのか（悪くはないが、優先度が下がるリスクがある）

2つ目であれば、それは選ぶ理由になります。安さの背景を聞いて、納得できる説明が返ってくるかどうかを見てください。

契約の形も、金額と同じくらい効く

見積金額に目が行きがちですが、契約形態の違いは総額に大きく影響します。AI導入では主に2つの形が使われます。

問題になりやすいのは、不確実性の高い段階を請負で契約してしまうことです。不確実性が高いPoCでは、準委任契約が選択されるケースがあります。それでも請負にすると、受注側はリスク分を金額に上乗せせざるを得ず、結果として高くなります。

逆に、仕様が固まった本開発を準委任で進めると、費用の上限が読みにくくなります。段階によって適した形が違うと理解しておくと、見積書の見え方が変わります。

提案を受けたら、「この見積もりはどの契約形態を想定していますか」と確認してください。同じ工程でも、形態が違えば金額の意味が変わります。

1. 自社の依頼範囲を決めずに声をかける

最も多いパターンです。「AI導入を相談したい」とだけ伝えると、各社が自社の得意な範囲で提案するため、企画書と見積書とツール紹介が並びます。比較のしようがありません。

構想から頼みたいのか、対象業務は決まっていて作る人が必要なのか。ここを先に決めてから声をかけてください。

2. 実績数と会社規模で選ぶ

実績が多いことは安心材料ですが、その実績が自社の課題と近いかどうかは別問題です。会社の規模も同様で、大きい会社ほど自社の案件が優先されるとは限りません。

見るべきは会社ではなく、担当するチームです。「実際に担当するのはどなたですか」「その方の直近の案件は何ですか」を聞いてください。

3. 提案の華やかさで決める

デモが動いて見えると強い印象が残りますが、デモは作り込まれた前提の上で動いています。自社の実データで、同じ精度が出るとは限りません。

デモを見せられたときは、「この結果を出すために、どんなデータをどれだけ用意しましたか」と聞いてください。その答えが、自社に必要な準備の量になります。

4. 相見積もりを取らない、あるいは取りすぎる

1社だけで決めると相場観が持てず、5社以上に声をかけると比較の前に力尽きます。3社程度が実務的な上限です。

また、断る手間も想定しておいてください。丁寧に提案を作ってもらった相手に断りを入れるのは負担がかかります。声をかける数は、その手間まで含めて決めるものです。

5. 「AI導入」を目的にしたまま選ぶ

解決したい業務課題が定まらないまま会社選びを始めると、どの提案も魅力的に見えます。判断基準がないためです。

この状態であれば、会社選びの前に戻ってください。選定作業を止めることは後退ではなく、最も費用対効果の高い判断です。相談の中で「まだ選ぶ段階ではない」と言ってくれる会社があれば、その相手は信頼できます。

6. 契約後の体制を確認しない

提案の場に出てきた人と、実際に手を動かす人が違うことは珍しくありません。それ自体は普通のことですが、誰が担当し、窓口は誰で、どのくらいの頻度で状況を共有するのかを契約前に確認しておかないと、進行中に不満がたまります。

特にAI導入は、仕様が進めながら固まっていく部分があります。定例の頻度と、決めたことをどこに残すかを先に握っておくと、後の認識のずれを防げます。「打ち合わせで決めたはずのことが反映されていない」という状態は、記録の運用が決まっていないときに起こります。

RFP（提案依頼書）は、大企業だけのものではありません。小規模な案件であれば、A4で2〜3枚程度でも十分に比較の土台になります。目的は立派な書類を作ることではなく、各社に同じ条件で提案してもらうことです。

最低限、書くべき7項目

• 背景と目的 — なぜAIを検討しているのか。解決したい主要な業務課題を明確に書く
• 対象業務の現状 — 月に何件、1件あたり何分、担当は何人。数字で書く
• 依頼したい範囲 — 構想から／PoCから／開発から。どこを任せたいのか
• 既存システムの状況 — 連携が必要なシステム名と、仕様書の有無
• 制約条件 — セキュリティ要件、データの持ち出し可否、社内の承認プロセス
• 予算と時期 — 桁感で構わない。稼働させたい時期も書く
• 提案してほしい内容 — 工程ごとの金額と期間、体制、想定リスク

2つ目の「対象業務の現状」が最も重要です。ここが数字で書かれていれば、各社の提案は具体的になります。逆にここが曖昧だと、どの会社も一般論で返してくるしかありません。

予算は書いたほうがよい

予算を伏せて提案を取りたくなりますが、書いたほうが精度の高い提案が集まります。桁が分かれば、その範囲で何ができるかという提案になるためです。

伏せたまま進めると、各社が想定で組んだ見積もりが並び、範囲もバラバラになります。比較の手間だけが増えて、結局もう一度条件を揃えて出し直すことになります。

提案の期限と、選定の基準を伝える

いつまでに提案がほしいのか、何を基準に選ぶのかを明記してください。基準を伝えると、各社がそこに合わせて提案を組むため、比較しやすい形で返ってきます。

「価格のみで判断する」のか、「体制と実績を重視する」のか。基準を伝えないと、各社は自社の得意な軸で提案してくるため、また比較できない状態に戻ります。

RFPを作る過程が、社内の整理になる

7項目を埋めていくと、社内で決まっていないことが明らかになります。予算の桁が決まっていない、判断者が曖昧、対象業務の数字を誰も把握していない。

これらは支援会社を選ぶ前に決めるべきことです。RFPが書けない状態で発注すると、契約後に同じ問題が表面化します。その意味で、RFPの作成は発注準備そのものです。

自社の場合にどこまで書けばよいか、どの型の会社に声をかけるべきかも含めてご相談いただけます。相談の結果、当社が適していないと判断した場合は、その旨をお伝えします。