このディレクトリでAI戦略の仕事を売っている81社のうち22社は、ソフトウェアを作る項目を何ひとつ掲載していない。準備状況を診断し、優先順位づけのワークショップを回し、ロードマップを手渡す。そしてそのロードマップは、別の誰かを必要とする。これは正当な商売であり、AIが登場するはるか前から正当な商売だった。だが提案書にAIコンサルティングと実装と書かれているとき、買い手が買うつもりでいるものとは違う。この言葉の前半と後半は別々の会社が売っていることが多く、その継ぎ目こそがAIプログラムの死に場所になる。
ここに挙げた件数は2026年10月9日時点の稼働中のディレクトリから読み取ったもので、誰でもカテゴリーページで確認できる。実在の掲載243件のうち、81件がAI戦略コンサルティングのカテゴリーを持つ。何かを作ることを含意するカテゴリー、すなわちAIインテグレーション、カスタムAIソリューション、プロセス自動化のいずれかを持つのは167件。両方を持つのは59件しかない。つまり22社は助言するが作らず、108社は作るが助言せず、仕事の全体を引き受けると公に掲げている会社は市場の4分の1に届かない。
誰も持ち主のいない継ぎ目
戦略の案件はドキュメントで終わる。実装の案件は仕様書から始まる。この2つは同じ成果物ではなく、一方を他方に変換する作業は実在の労働で、しかもどちらの契約もたいていその代金を払っていない。ロードマップにはこう書かれる。「手作業のレビューを減らすため、文書分類モデルを導入する」。作る側が知らなければならないのは、どの文書なのか、精度がどの水準に達したら完了と見なすのか、学習データのラベル付けは誰がやるのか、モデルはどこで動くのか、誤判定になる4パーセントをどう扱うのか、人間がモデルの判断を上書きしたとき責任を負うのは誰なのか、である。
この問いには誰かが答えなければならない。1社で請ける契約では、ロードマップを書いた会社が答える。しかも、その答えと自分で付き合っていくことを知りながら答える。2社に分かれた契約では、助言した会社はすでに引き上げており、作る会社は一度も話したことのない相手が書いた文書を読んでいる。推測で進めるか、自前でディスカバリーをやり直して請求するかのどちらかだ。後者なら、買い手は同じ判断に二度支払う。
実際に多いのは二度払うほうだ。しかもこれはもっとも見えにくい。引き継ぎの失敗としてではなく、作る会社のオンボーディング工程として請求書に載るからである。AIコンサルティングと実装をひとつの契約にまとめても、この作業そのものは消えない。消えるのは、二度払うという部分だけだ。
コンサルティングと実装は1社に任せるべきか
おおむね6か月を超えない仕事なら、たいていは任せたほうがよい。継ぎ目のコストは利益相反のコストより大きく、その利益相反こそが両者を分ける標準的な根拠になっている。この根拠は間違っていない。自分が受注して実施する仕事を推奨する会社には、仕事を多めに推奨する明白な理由がある。問うべきは、自分のケースではどちらのリスクが大きいかだ。最初の本番システムなら、誰も作れないロードマップのリスクのほうが大きい。購買部門があり、実際に大きな金額が動く複数年のプログラムなら、独立性には継ぎ目のコストを払う価値がある。大企業がまさにその理由で分けている。
使える中間解は、判断は分けるが関係は分けないやり方だ。短く、本当に独立した評価を1社から買い、そのうえで実装の競争プロセスを回す。評価をした会社にも入札を認め、ただし優位は一切与えない。これなら助言は正直なままで、問題を理解している会社がそのまま先へ進む道も残る。
この言葉が使われる4つの型
AIコンサルティングと実装をうたう提案書は、仕事が始まったあとの挙動がまったく違う取り決めに、同じ言葉を使う。買い手に届く提案のほとんどは、次の4つに収まる。
| 提案書の表記 | 実務上の意味 | 助言を仕様に変えるのは誰か | 確認すべき点 |
|---|---|---|---|
| 戦略と実装、1社で | 診断から本番までを同じチーム、少なくとも同じ会社が担う | その会社が自社の負担で | 実際に作るエンジニアが戦略の会議に出ているか |
| 戦略と実装サポート | 助言会社が他社の開発を監督する | 形式上は誰もいない | 完成物がロードマップと合っていると誰が承認するのか |
| 実装パートナー | 買い手が渡す仕様に沿って開発だけを行う | 買い手 | 本当に仕様があるのか、ロードマップしかないのか |
| エンドツーエンドのAI変革 | 上の両方から、どちらでもないものまで | 聞くまで分からない | コードを書く人の名前を聞くこと |
気をつけるべきは4行目だ。「エンドツーエンド」は構造ではなく意欲を述べた言葉で、誠実な版とパンフレットの版を分ける試験は単純である。最初の本番コミットを書く人間の名前と肩書きを尋ねればよい。自社で作る会社は一文で答える。下請けに出す会社はプロセスの説明を始める。
掲載データから分かる役割分担
実在の掲載243件のうち46件はカテゴリーをひとつも登録していない。ディレクトリに分かることの限界だから、はっきり書いておく。残る197件については、カテゴリーの並びがまずまずの一次フィルターになる。戦略だけを掲げる会社はほぼ確実に助言側だ。インテグレーション、カスタム開発、自動化を掲げて戦略カテゴリーを持たない会社は、ほぼ確実に、買い手が計画を持って来ることを前提にした開発会社である。両方を持つ59件が、1社完結の契約を検討する際の候補リストになる。
掲載データから分からないのは厚みだ。243件のうち時間単価を公開しているのは40件、チーム規模を公開しているのは42件で、市場の大半については、実装の体制がエンジニア30人なのか、案件が決まったときに代表が声をかける外注1人なのかが見えない。この市場をカテゴリー別に数えた記事が供給の偏りを示しているが、薄いのは買い手が薄くないと思い込んでいるところに集中している。
打ち合わせの前に助言会社と開発会社を見分けられるか
事例紹介は、成果ではなく成果物に注目して読む。助言会社は判断を語る。優先順位づけされたポートフォリオ、オペレーティングモデル、ガバナンスの枠組みだ。開発会社はシステムを語る。パイプライン、レイテンシの数値、APIの裏で動いているモデルだ。どちらも「提供した」という言葉を使う。実際に動いているものを名指しできるのは片方だけである。事例が判断しか書いていなければ、サービスページの記述がどうであれその会社は助言側だ。これは批判ではなく、使える情報である。
金が実際に流れる先
助言の仕事はシニア人材の時間で値付けされ、費用は前半に寄る。実装はエンジニアリングの人月で値付けされ、プログラムの費用の大半はここに乗る。たいていは大差で乗る。金額が許容範囲だという理由で戦略の案件を承認した買い手は、最終的な支出のうち小さいほうの部分をおおよそ承認したにすぎず、そこで作られるロードマップは、費用の大きいほうの部分について厳しい予算制約を受けずに書かれていることになる。
だから、まだ発注先として決めていない段階でも、作る側を早い時期に同席させる実務的な理由がある。データパイプラインの作業3か月分がいくらかかるかを知っているエンジニアは、ロードマップがまだ編集できるうちにそれを言う。同じ情報が4か月後に届けば、それは再交渉として届く。どの契約モデルに署名しているのかという問いもここで効いてくる。リテイナーはこの種の想定外を静かに吸収するが、スコープ固定の契約はそれを表に引きずり出すからだ。
ガバナンスの側には、どちらの契約に署名する前にも読んでおく価値のある標準的な参照先がある。NIST AI Risk Management Frameworkは、戦略ではなく実装の判断に対応する機能を軸に構成されている。ISO/IEC 42001は、コンサルタントが推奨するものではなく組織が運用するものとしてAIマネジメントシステムを扱う。どちらも、結果を誰かが運用しなければならないという前提に立っているからこそ役に立つ。
引き継ぎの時点で契約に何を書いておくべきか
AIコンサルティングと実装の両方を含む契約から日常的に抜け落ちるものが3つあり、どれも今ではなく後で金になる。
- 第三者が検証できる完了の定義。つまり数値と手法であって、「精度の向上」ではない。社外のエンジニアがその試験を実行して可否を出せないなら、その条項は飾りだ。
- 学習データとラベル付けの所有者を名指しすること。実装が3週目で止まる原因としてこれが最も多く、止まるのは双方が相手の担当だと思い込んでいたからだ。
- 終了時に買い手の手元に残るものの一覧。モデルの重み、パイプラインのコード、プロンプトのテンプレート、評価用の一式。ひとつずつ名前を書くこと。「成果物」という語は、弁護士の前で両方の意味に読まれてきた。
案件が終わったとき実際に何を所有しているのかという問題は、AIの仕事では従来のソフトウェアよりはるかに固まっていない。そして2社間の引き継ぎは、それに気づく場所として最悪だ。
最初に削られるチェンジマネジメントの半分
技術的には動くのに使われない実装は、取りうる結末のなかで最も高くつく。しかもこのサイトに届くロングテールの検索が直接それを尋ねてくる程度には、よく起きている。システムによって仕事が変わる人たちを再訓練し、置き換えられる手順書を書き直し、モデルと人間の判断が食い違ったときどうするかを決める。これを誰かが担わなければならない。助言会社はこの作業を見積りに入れる。開発会社はたいてい入れない。エンジニアリングではないからだ。したがってこれも同じ継ぎ目に落ち、プログラムが予算を超えたときに最初に削られる行になる。
MIT Sloan Management Reviewは、これらのプログラムが何かを返すかどうかを決めるのはモデルの品質ではなく組織への定着だという論点を数多く扱ってきた。またProject Management Instituteは、この分野そのものについての標準的な実務体系を維持している。どちらもAI専用ではない。そこがまさに要点で、AIプログラムで最も失敗しやすいのはAIではない部分なのだ。
チェンジマネジメントの専門業者を別に入れる必要はあるか
単一のシステムなら、まず必要ない。作業は実在するが、自社の中の特定の個人に任せられる程度の規模で、しかも社内の担当者には社外の人間が持てない立場がある。複数の部署に同時に手を入れるプログラムになると、これは本物のワークストリームになる。その規模なら、変えようとしているオペレーティングモデルをすでに理解している助言会社から買うのが、たいてい正しい。
候補リストの作り方
自社に足りないのがどちらの半分なのかから逆算する。それが、AIコンサルティングと実装をまとめて探すのか、どちらか一方だけを探すのかを決める。
- 問題は明確に見えているが、エンジニアリングの手がない。作るが助言はしない108社が対象で、最初の打ち合わせの前に書面の仕様を用意しておくべきだ。
- エンジニアリングの手はあるが、何を作るかで社内が合意していない。必要なのは助言側だ。いま開発を発注するのは早すぎるし、2か月目には開発チーム自身がそう言ってくる。
- どちらもない。両方のカテゴリーを持つ59社だけが最初の一本の電話に値する。そして最初のシステムには、1社完結が正しい構え方だ。
地理の重みは以前より下がったが、ゼロではない。このディレクトリは125の異なる都市を収めており、現地でのデータアクセスや規制対象のシステムが絡む実装では、時差と移動は実際の制約になる。その段階では都市から辿るのが妥当なフィルターだ。デンバー、シカゴ、ボストンはそれぞれ助言と開発の構成比が違う。所在地が本当に効くケースは、ほとんどの買い手が想像するより狭い。
最初の打ち合わせで聞くべき最良の質問はどれか
自社の推奨が結果として間違っていた直近の案件と、それにどう対処したかを説明してもらうこと。一度も間違ったことがない助言会社は、一度も本番に出ていない。良い答えを返す開発会社は、外れた具体的な技術的な賭けと、それを巻き戻すのにかかった費用を語る。そこから分かるのは、その会社が本当に出荷していることと、出荷の代償について正直だということの両方だ。この話を出せない会社は、その仕事をしていないか、話す気がないかのどちらかで、どちらも答えである。
この市場の下地
この分裂は市場の欠陥ではない。助言と実行は、原価構造も利益率も採用もまったく違う別の商売で、会社が専門化するのは商業的に筋が通っている。欠陥なのは言葉が崩れたことだ。「AIコンサルティングと実装」は、2つのうち片方しかやらない会社のサイトにも書かれていて、買い手がそれを業務範囲の約束と読むのは無理のない話である。
だからこの言葉は、説明ではなく質問として扱えばよい。両方やる会社はその質問を歓迎する。差別化の手段そのものだからだ。片方だけの会社はどちらなのかを答えてくれるし、その答えには、それが覆すパンフレットより価値がある。そもそもコンサルティング会社が必要なのかという手前の問いから始めるのが正しい場合も多く、答えが経験豊富な個人1人と自社のエンジニアであることもある。
技術の側には、仕事の形について独自の文献がある。AIのソフトウェア開発が従来の開発とどう違うかは、ソフトウェアを発注した経験のある買い手がいちばん驚く部分だ。またOECD AI Policy Observatoryは、実装が何をしてよいのかをますます左右する政策と規制の状況を追っている。
早めに見分けたい2つの失敗の型
ひとつめは孤立したロードマップだ。よくできた戦略文書が承認され予算もついたのに、一度も作られない。開発の見積りがロードマップの前提の3倍で出てきて、プログラムが終わりの日付のない計画作業として再開されるからである。見分ける目印は、エンジニアが同席しないまま書かれたロードマップだ。
ふたつめは仕様なき開発だ。能力のある開発会社が、完了を定義しなかった要件で6週間作業したところで、関係者がそのシステムの目的について互いに違うことを考えていると気づく。見分ける目印は、買い手の社内の人間が別々の成果を語るキックオフだ。どちらの型も悪い発注先が原因ではない。だから、より良い発注先を買ってもどちらも直らない。
いまいる場所から始める
ロードマップがすでにあって何も作られていないなら、足りないのは仕様と開発のパートナーで、この順番だ。ロードマップがなく予算が承認されているなら、足りないのは作る側が同席する短い診断である。この記事が扱っている言葉を使った提案書が届いているなら、次の一手は、上の表の4行のどれを指しているのかを尋ね、最初の請求書より前に書面で答えをもらうことだ。
作ろうとしているものを教えてもらえれば、このディレクトリのなかで、公開カテゴリーが仕事の両方の半分に合う会社を見られる。あるいは、本当に両方をやるエージェンシーを経営しているなら、ここに掲載してほしい。その組み合わせで絞り込む買い手に見つけてもらえる。カスタム開発が実際に何で構成されているかと統合の作業に何が含まれるかを読んでおくのは、金が動く前に仕様を鋭くする妥当な方法だ。