AI導入支援会社は5類型＋FDE型で選ぶ｜失敗しない見極め方

2026年8月28日

AI導入支援会社は、コンサル系、SIer系、ツールベンダー系、比較メディア系、受託開発系という既存の5類型に、エンジニアが顧客側に入り込んで伴走するFDE型を加えた6つの型に分かれます。型が違えば強い工程も課金の形も違います。自社がどの工程で止まっているかを先に特定し、その工程に強い型を選ぶのが、外さない順序です。

私は株式会社Walkersの代表として、自社と顧客企業のAI導入を実装側から進めています。その立場で言うと、支援会社を比較するときに実際にぶつかる論点は「どの会社がよいか」ではありません。「どの型に頼むべきか」のほうです。だからこの記事では、会社名の優劣ではなく、型の構造と、それぞれが担当しない範囲を書きます。

クリックできる目次

なぜ会社名ではなく「型」で選ぶのか

支援会社選びで怖いのは、外れを引くことではありません。契約どおりに納品され、報告書も上がり、検収も通り、それでも現場の作業が一つも減っていない、という終わり方です。誰も手を抜いていません。ただ、頼んだ相手が、その会社の止まっている工程を担当する型ではありませんでした。ずれはそこにしかないのに、半年たつまで表に出ません。

候補が多すぎるから難航するのではありません。候補どうしが、そもそも同じ商品を売っていないからです。ある会社は業務の棚卸しと投資判断を売り、別の会社は稼働するシステムを売り、また別の会社はライセンスを売ります。同じ「AI導入支援」という看板の下で、納品物の種類が違います。

この違いは見積書を並べても見えにくいです。棚卸しの成果物は資料で、システムの成果物は動くコードで、ライセンスの成果物はアカウント。どれも「AI導入支援一式」と書けてしまいます。だから金額だけを横に並べると、比較しているつもりで別々の商品を眺めることになります。

実際、日本企業は導入そのもので詰まっているわけではありません。PwC Japanグループが2026年2月に実施した調査（売上高500億円以上の企業で生成AI導入に関与する課長職以上932名が対象）では、日本企業の生成AI活用中が71%、推進中が16%で、合計87%が着手しています。一方、効果が「期待を大きく上回る」と答えた企業は10%にとどまり、効果実感の合計64%は比較した6カ国で最下位でした。効果が1年以内に出ると見込む企業も日本は41%で、米国とドイツの66%と開きがあります。

着手率が高く、効果実感が低いのです。この形が示しているのは、導入の意思決定ではなく導入後の工程、つまり業務への埋め込みと運用の定着で止まっている企業が多いということです。IPAの「DX動向2025」でも、DX推進人材の量について「さらなる人数の確保が必要」と答えた企業が85.1%に達し、過不足がないとした企業は3.8%でした。手を動かす人が社内に足りない状態で、資料だけが増えていきます。

だから、選ぶときの問いは「どこが優秀か」ではなく「自社が止まっている工程を、その型は担当するのか」になります。

AI導入支援会社にはどんな5類型があるか？

5つの型は、中心に座っている人が違います。誰が中心にいるかで、強い工程も、請求の立て方も決まります。

型	中心にいる人	強い工程	課金の形	向いている会社	向かない会社
コンサル系	経営コンサルタント、業務コンサルタント	現状分析、投資判断、全社ロードマップ	月額固定のリテイナー、または稼働人月	投資の優先順位が社内で割れていて、判断材料が要る会社	何をやるかは決まっていて、作る人がいない会社
SIer系	プロジェクトマネージャー、システムエンジニア	要件定義、基幹システム連携、大規模開発の統制	人月単価×工数の一括見積、保守は月額	既存基幹システムとの接続が主戦場で、社内に情報システム部門がある会社	要件が固まっておらず、作りながら決めたい会社
ツールベンダー系	プロダクトの営業、カスタマーサクセス	製品の設定、初期セットアップ、社内展開	ユーザー課金や従量課金。例としてMicrosoft 365 Copilot（エンタープライズ向けプラン）は1ユーザーあたり月額4,497円（年間サブスクリプション、税別）	既製品の機能で足りる業務があり、まず全社に配りたい会社	自社固有の業務手順に合わせ込みたい会社
比較メディア系	メディア運営者、コンシェルジュ	候補の一次スクリーニング、相見積の取得	発注側は無料。掲載側が広告費や成約手数料を負担する	発注先の心当たりがまったくなく、候補の母集団を作りたい会社	掲載していない会社も含めて広く探したい会社
受託開発系	エンジニア、デザイナー	仕様に沿った実装、既存業務の自動化	プロジェクト単位の一括見積、運用は月額	作るものが決まっていて、実装力を外から足したい会社	何を作るべきかの整理から必要な会社

正直に書いておくと、コンサル系とSIer系の価格については、業界横断で検証できる公的な統計を確認できませんでした。だから表の金額欄も空けてあります。ツールベンダー系は公開価格を参照でき、比較メディア系は課金の向きが公表されているが、残る2つは同じようには書けません。相場を語る記事は多いものの、出所をたどれない数字は発注の判断材料になりません。

コンサル系

コンサル系の強みは、社内で意見が割れている状態を、判断できる形に整えることにあります。どの業務にどれだけ工数がかかっていて、AIで置き換えたときの効果がどこに出るのかを、決裁者が読める資料に落とします。経営会議に持ち込む材料が要る局面では、この型が最短です。

問い合わせると、まず現状を伺うところから、という返事になることが多いです。見積は月額のリテイナーか稼働人月で、期間と体制が先に決まり、成果物は資料です。この形自体は正しいです。ただ、資料が仕上がった時点で、実装は別の会社に発注し直すか、社内の人員で進めることになります。コンサル系が納めるのは判断材料であって、稼働するシステムではありません。

DX推進人材が足りない企業がここでもう一段止まるのは、計画の質が低いからではありません。計画を実行に移す担い手が、契約のどこにも書かれていないからです。だから、契約前に「実装フェーズは誰が担当する想定か」だけは確かめておきます。同じ会社に実装部隊があるのか、提携先を紹介するのか、それとも発注側が探すのか。ここが曖昧なまま計画だけが仕上がると、資料の鮮度が落ちる速度のほうが速いです。

SIer系

SIer系の武器は規模です。基幹システムとの接続や大規模なプロジェクト統制で力を発揮し、工程管理、品質保証、複数ベンダーの取りまとめといった、規模が大きくなるほど効いてくる能力を組織として持っています。既存の販売管理システムや会計システムに手を入れる必要があるなら、この型を外して進めるのは難しいです。

一方で、SIer系の見積は要件が固まっていることを前提にしています。人月単価に工数を掛けて金額を出す以上、工数が読めない仕事は請けにくいです。AI導入の初期段階は「何を自動化すれば効くのか」が読めない状態から始まることが多く、この前提とかみ合いません。

かみ合わないまま相談すると、返ってくるのは実装の見積ではなく、要件定義の見積です。工程が一つ手前で切り出され、有償化されます。進め方としては妥当で、ほかにやりようもありません。ただ、要件定義が終わってから実装見積が出るため、発注の判断は二段階になり、着手までの期間が伸びます。急いでいる案件で先に確かめるべきは、金額よりこの時間割のほうです。

ツールベンダー系

ツールベンダー系は、自社製品の導入と社内展開に責任を持ちます。製品が業務に合っている場合、この型が最も速く、最も安いです。Microsoft 365 Copilot（エンタープライズ向けプラン）のように公開価格があり、1ユーザーあたり月額4,497円（年間サブスクリプション、税別）といった単位で予算を立てられるのも扱いやすいです。

商談はデモから始まり、提案は製品の機能に沿った形で返ってきます。この型の限界は、その返り方にそのまま出ています。ベンダーの担当者は自社製品の設定には詳しいが、顧客固有の業務手順そのものを設計し直す立場にはありません。そして「この業務にこの製品は合わない」という結論を出す動機も持ちません。

合わない業務に製品を当てはめると、使われないアカウントが積み上がります。更新の時期になって、解約の判断を誰も出せない、という形で表に出ることが多いです。複数のツールベンダーから同時に提案を受けているなら、提案どうしの重複やデータの置き場所の分散も一緒に出てきます。どの業務にどの製品を当てるかの割り振りだけは、発注側かほかの型の支援者が握っておきます。

比較メディア系

比較メディア系は、発注先の候補をゼロから探す手間を引き受けます。心当たりがまったくない状態から数社の候補と相見積を得るには有効な入口で、発注側は無料で使えます。運営費は掲載企業側の広告費や成約手数料でまかなわれる仕組みです（比較ビズは、掲載企業からの広告費で運営し、発注側は完全無料で発注時の手数料もかからないと明示しています）。

無料で候補が返ってくる理由は、その課金の向きにあります。そして、構造上の限界も同じ場所から出てきます。収益源が掲載側にある以上、掲載していない会社は候補に出てきません。得意分野が近い会社が並んでいるように見えても、それは市場全体の縮図ではなく、そのメディアに出稿している会社の集合です。だから、母集団を作る道具として使い、最終判断の材料としては使わない、という距離感が現実的です。

受託開発系

受託開発系は、決まった仕様を形にします。実装力を外から足す使い方では、この型が素直に効きます。社内に企画者がいて、作るものの輪郭が描けているなら、余計な工程を挟まずに進められます。

最初の打ち合わせで聞かれるのは、多くの場合「仕様書はありますか」です。渡すものがないと、見積は出るには出るが、決まっていない部分が「別途協議」として残ります。決めるための会議は、そのまま発注側の宿題になります。受託開発の契約は「発注側が仕様を確定させ、受注側が実装する」という役割分担を前提にしているため、発注側に仕様を決める人がいないと、開発は着手前で止まります。

ここまで見てきてわかるとおり、どの型も、業務の分解から実装、運用の定着までを一つの担い手で通しては担当しません。コンサル系は分解までで降り、受託開発系は仕様が確定してから乗ります。ツールベンダー系は製品の内側にとどまり、SIer系は要件が固まるのを待ちます。5つのあいだには、誰も受け持たない谷間があります。契約どおりに終わったのに作業が減らない案件は、たいていここで起きています。

第6の型としてのFDE型とは？

谷間は、相談の場面にそのまま現れます。何を自動化すべきかは決まっていません。手順書もありません。ただ、月末になると数人が二日つぶれる作業があって、それを見にきて、そのまま作ってほしい、という依頼です。

これを5類型に振り分けようとすると、どこにも収まりません。コンサル系に頼めば棚卸しは出るが、作る人はついてきません。受託開発系は作るが、何を作るかは発注側が決めることになります。ツールベンダー系に合う製品はなく、SIer系が体制を組むには小さいです。比較メディア系は、この依頼の宛先を持っていません。

宛先のなかったこの依頼に名前がついたのは、日本ではなく米国の実装現場です。FDE型とは、Forward Deployed Engineerが顧客側に入り込み、業務の分解から実装、運用の定着までを一人ないし少人数の同じチームで担当する支援形態を指します。分析する人と作る人を分けないことが、ほかの5類型との構造的な違いです。

呼び名の由来はPalantir Technologiesにあります。同社はこの職種をForward Deployed Software Engineerと呼び、社内では「Delta」の通称で扱っています。同社のブログは、一般的なソフトウェアエンジニアが多数の顧客に使われる単一の機能を作るのに対し、FDSEは単一の顧客に対して多数の機能を実現することに集中する、と両者を対比しています¹。日本でも、住友商事グループのInsight Edgeが2026年5月にFDE職を新設した事例が公開されており、職種名として輸入が始まっている段階です。

FDE型が担当する工程

FDE型の担当範囲は、業務の観察から始まります。どの作業に何分かかり、誰が判断し、どの情報がどこに置かれているかを、資料からではなく実際の作業から拾います。そのうえで自動化できる単位に切り分け、切り分けた単位をそのまま実装します。実装したものが使われなければ、使われない理由を現場で確かめて作り直します。

この進め方が成立するのは、分解した本人が実装するからです。分解と実装が別の会社に分かれていると、分解の結果は仕様書という形式に翻訳されます。翻訳の過程で、現場の人が口頭でしか説明しなかった例外処理や、資料に書かれていない判断基準が落ちます。落ちた分だけ、できあがったものは使われません。同じ人が続けて担当すれば、翻訳の工程そのものが消えます。

もうひとつの特徴は、成果物が顧客ごとに違うことです。汎用の製品を設定で寄せるのではなく、その会社の業務手順に合わせて実装します。結果として、他社にそのまま転用できるものは残りにくいです。提供する側から見れば、効率の悪い形態です。

FDE型が適合する条件

FDE型が効くのは、次の条件がそろっているときです。

業務が言語化されていない：手順書がなく、担当者の頭の中に判断基準があります。資料を渡して要件定義を頼める状態ではありません。
社内に手を動かす人がいない：計画を受け取っても実装に移す人員がいません。IPAの調査が示すDX推進人材の不足は、この条件に直結します。
既製品の機能に業務が収まらない：複数のツールにまたがるデータを、自社固有の判断のために組み合わせる必要があります。
経営層が意思決定に関与できる：業務の切り方を変える判断が必要になる場面があり、現場の合意だけでは進みません。

前の3つは、独立してはいません。言語化されていない業務ほど既製品からはみ出しやすく、はみ出した分を社内の誰かが手で埋めています。だから、ひとつ当てはまる会社は、たいてい残りも当てはまります。最後の1つだけは性質が違います。前の3つがそろっていても、判断を出せる人がいなければ業務の切り方は変えられません。

FDE型が適合しない条件

一方、次の場合はFDE型を選ぶ理由が薄いです。ほかの型のほうが速いか安いです。

既製品で足りる業務：勤怠管理や経費精算のように、標準的な手順で回る業務は、ツールベンダー系に任せたほうが安く済みます。作り込むと保守費が乗るだけになります。
要件がすでに確定している：仕様書が完成しているなら、受託開発系に実装を発注するほうが見積を比較しやすく、価格競争も働きます。
基幹システムの大規模改修が主目的：工程管理と品質保証の体制が要る規模では、SIer系の組織的な統制力が要ります。少人数のFDEでは受け切れません。
投資判断そのものが未着手：何にいくら投じるかを経営会議で決める段階なら、コンサル系の資料化能力が先に効きます。
担当者を出せない：FDE型は顧客側の業務に入り込む前提なので、現場に一定の時間を割いてもらう必要があります。誰も時間を出せない状態では成立しません。

FDE型は万能な上位互換ではなく、5類型が担当しない谷間に特化した型です。谷間に落ちていない案件に当てても、費用が高いだけの受託開発になります。

WalkersはFDE型で何を提供しているのか？

当社が提供している「FDE-NOAH」は、経営に必要なデータを1つの画面に集約し、1顧客につき1デプロイの形で構築するサービスです。共通のSaaSにアカウントを発行するのではなく、顧客ごとに独立した環境を用意し、その会社の業務に合わせて画面と処理を実装します。

公開している範囲で載せているのは、メールの未返信チェックと返信下書きの生成、商談の進行に応じた営業パイプラインの自動更新、マーケティング指標の集計、SNS投稿の下書きと承認の流れ、検索順位の監視と記事修正案の提示、議事録の作成、経理と財務のダッシュボード、請求と契約金額の管理、そして自動実行しているジョブ自体の監視です。

これらは当社が自社の業務で先に動かし、運用に耐えることを確かめてから顧客環境に展開しています。自社で動かしている点は誇るべき性質というより、FDE型の作り方の必然でもあります。業務を分解して実装し、使われなければ直すという反復を、まず自社の業務で回しています。

導入は無料のアセスメントから始める形をとっています。業務を観察して自動化できる単位を切り出し、どこから着手するかを決めるまでを先に済ませます。ここで「既製品で足りる」と判断すれば、そのとおりに伝えます。当社のAI導入支援（FDE型伴走支援）は完全月額制で、月額50万円から100万円（税別・初期構築費0円）に収まることが多く、この金額に見合う効果が業務側に見つからないなら、FDE型を選ぶ理由はありません。詳細は料金一覧で確認でき、自社の案件でどのあたりに位置するかの概算は料金シミュレーターで算出できます。

金額のレンジを先に出しているのは、比較の起点を作るためです。実装を伴う支援は、資料だけを納める支援より高くなります。その差額が、翻訳工程を省いて運用まで届かせることに対する対価であるかどうかを、発注側が判断できる状態にしておきたいのです。

自社の状況から型を選ぶ

型は、自社が止まっている場所から逆算すると決まります。

何に投資すべきかが社内で割れているなら、コンサル系です。判断材料の不在が原因であり、実装力を足しても解決しません。ただしこの段階で、実装フェーズの担い手を誰にするかまで契約時に決めておきます。

投資対象は決まっていて、既存の基幹システムに手を入れる必要があるなら、SIer系です。規模が大きく、関係者が多く、止められないシステムがある案件では、統制の能力が価格差を正当化します。

対象業務が標準的で、既製品の機能で回るなら、ツールベンダー系です。この判断を下せるかどうかは、業務が標準から外れている度合いをどれだけ正確に把握しているかで決まります。判断がつかないなら、まず1部署で試すほうが安いです。

発注先の候補がまったく思い当たらないなら、比較メディア系で母集団を作ります。そこで得た候補が市場全体ではないことを踏まえ、掲載外の会社も併せて当たります。

仕様書が仕上がっていて、実装力だけが足りないなら、受託開発系です。ここでは相見積が機能するので、価格と納期で比較してよいです。

そして、業務が言語化されておらず、手を動かす人もおらず、既製品に業務が収まらないなら、FDE型です。3つのうち1つか2つしか当てはまらないなら、ほかの型のほうが安く済む可能性が高いです。

自社の状況	推奨する型	選ぶ理由
何にいくら投資すべきかが決まっていない	コンサル系	決裁に必要な材料を作る工程が最短の隘路になっている
基幹システムとの接続や大規模改修が主戦場	SIer系	工程管理と品質保証を組織で担保できる
業務が標準的で、既製品の機能で回る	ツールベンダー系	作り込むより公開価格で配るほうが安く速い
発注先の候補がまったく思い当たらない	比較メディア系	候補の母集団を短時間で作れる
仕様が確定していて実装力だけが足りない	受託開発系	相見積が機能し、価格と納期で比較できる
業務が言語化されておらず、社内に実装者もいない	FDE型	分解と実装を同じ担い手が続けるため、翻訳による欠落が起きない
PoCは動いたが現場で使われていない	FDE型	使われない理由は業務側にあり、作り直しではなく業務の観察から入る必要がある

複数の型を組み合わせる選び方もあります。全社ロードマップはコンサル系に、標準業務はツールベンダー系に、固有業務はFDE型に、という分担は矛盾しません。組み合わせるときは、業務ごとにどの型が担当するかの割り振りを発注側が持ち、割り振り自体を外注しないほうがよいです。割り振りを外注すると、その会社の型に寄った配分になります。

冒頭の終わり方に戻ります。契約どおりに納品され、それでも作業が減らなかった案件は、発注先の力量が足りなかったのではありません。担当してほしかった工程と、頼んだ型の担当範囲がずれていました。ずれは見積書には出ません。出るのは、業務そのものを見に行ったときだけです。FDE型という呼び名が日本でどこまで通じるようになるかは、まだわかりません。ただ、谷間のほうは、名前がつく前から現場にありました。

よくある質問

AI導入支援会社は結局どの型に頼めばよいですか？

自社が止まっている工程で決まります。投資判断で止まっているならコンサル系、仕様は決まっていて実装力が足りないなら受託開発系、業務の言語化から実装、定着までを一貫して任せたいならFDE型です。会社の規模や知名度ではなく、担当してほしい工程を先に書き出してから候補を当たると、比較の軸がぶれません。

FDE型とコンサル会社の常駐支援は何が違いますか？

常駐しているかどうかではなく、同じ担い手が実装まで続けるかどうかが違います。コンサル会社の常駐支援は、現場に入って業務を分解し、改善案を設計するところまでを担当する形が多いです。FDE型は分解した本人が実装し、使われなければ作り直します。仕様書という中間成果物を介さないため、口頭でしか語られない例外処理が落ちにくいです。

従業員50人規模の会社でもFDE型に頼めますか？

規模そのものは条件ではありません。条件になるのは、既製品に収まらない固有業務があるかと、業務を見せてくれる担当者を出せるかの2点です。50人規模でも、複数のツールにまたがる情報を人が手で突き合わせている業務があるなら適合します。逆に、業務が標準的な手順で回っているなら、規模が大きくてもツールベンダー系のほうが安く済みます。

AI導入の費用はどこまで見ておけば足りますか？

型によって費用の構造が違うため、単一の相場では答えられません。ツールベンダー系はユーザー数と期間で計算でき、Microsoft 365 Copilotのように公開価格があるものは事前に固定できます。実装を伴う支援は案件ごとの見積になり、当社のAI導入支援（FDE型伴走支援）は完全月額制で、月額50万円から100万円（税別）に収まることが多いです。加えて、稼働後の運用費と、社内担当者が業務を説明するための時間を計上しておくと、着手後の見込み違いが減ります。

PoCで止まった案件は最初から作り直しになりますか？

作り直しになるとは限りません。PoCが止まる原因は、動かなかったからではなく、対象業務と運用責任が決まらないまま検証だけが終わることが多いです。この場合、動いた部分は資産として残るので、業務側の観察からやり直して、どの作業のどの判断を置き換えるかを決め直すほうが速いです。作り直しの要否は、既存のコードではなく業務の切り方を見てから判断します。

最終更新日：2026年8月28日

著者：株式会社Walkers 代表取締役渡辺敦司

出典

Palantir Blog “Dev versus Delta: Demystifying engineering roles at Palantir” および同社のForward Deployed Software Engineer職の募集要項。 ↩