はじめに：受託で納品したAIが、半年後に使われていなかった話
ある製造業の検品工程にAIを導入した案件がありました。画像認識モデルを構築し、精度も出た。納品して検収も通った。ですが半年後に聞いた話では、現場はExcelに戻っていたんです。
理由はいくつかありました。製品ラインが変わってモデルの精度が落ちた。再学習の手順書は渡してあったものの、誰もやらなかった。そもそも「AIを使い続ける」という業務設計がなかったんですね。
これは特殊な失敗談ではないはずです。AI案件に関わる人なら、似た経験が一つや二つあるんじゃないかと。そしてこの構造的な問題に向き合った結果、自分たちのビジネスモデルを「受託」から「運用ラボ」に寄せていくことになりました。
AI案件が「作って終わり」と相性が悪い理由
従来のシステム開発には「完成」がありますよね。要件を満たし、テストを通し、本番稼働すれば、あとは保守フェーズ。機能追加がなければ、基本的に動き続けます。
AIはそうじゃない。データの分布が変われば精度は劣化します。機械学習の文脈ではこれをデータドリフトと呼びます。ユーザーの使い方が変われば、想定外の入力が増える。ビジネス要件自体が四半期ごとに変わることもある。
つまりAIシステムは、納品した瞬間から劣化が始まるんです。ソフトウェアの保守とは質が違う。「壊れたら直す」ではなく「放っておくと性能が落ちる」という性質ですね。
受託モデルでこれに対応しようとすると、追加開発の見積もり→発注→着手→納品というサイクルを毎回回すことになります。クライアント側の稟議も毎回必要。結果、対応が遅れ、現場は「AIは使えない」と判断してしまう。構造的に、受託の契約形態がAIの価値を毀損している。そういう話です。
ラボ型が機能する構造
ラボ型、つまり継続改善を前提としたチーム常駐モデルは、この問題に対する一つの解になり得ます。
自分たちが採用しているのは2段構成です。
第1段階は導入フェーズ。4〜8週間で、PoCまたはMVPを構築します。準委任契約で、スコープを絞って短期集中で回す。目的は「動くものを見せて、現場の反応を取る」こと。この段階で合わないと判断すれば、ここで終わりにします。
第2段階が運用改善フェーズ。3ヶ月以上の継続契約で、モデルの再学習、パイプラインの改善、新しいユースケースへの展開を行います。月額固定のラボ契約で、チームの一部がクライアントの業務に入り込む形ですね。
この構成が機能するのは、AI案件の価値が「作ること」ではなく「使い続けること」にあるから。MLOpsの議論でも繰り返し指摘されていますが、モデル構築にかかる工数は全体の20%程度で、残り80%は運用・改善・監視に費やされます。
ラボ型であれば、精度劣化を検知して翌週には対応できる。新しいデータが入れば即座に再学習を回せる。稟議を待つ必要がない。この速度差が、AI活用の成否を分けるポイントだと感じています。
「案件獲得最大化」をやめた理由
IT企業の営業組織は、多くの場合「案件数」や「新規受注額」で評価されます。しかしAI領域でこの指標を追うと、厄介なことが起きる。
小規模なPoC案件を大量に受注すると、一つひとつの案件に深く入れません。AIの導入は業務理解が不可欠で、ドメイン知識の蓄積に時間がかかる。案件を転々とすると、毎回ゼロからキャッチアップすることになり、チームの学習が資産化しないんですよね。
また、小規模案件はPoCで終わることが多い。「AIで何かやりたい」という漠然とした動機で始まり、成果が見えないまま予算が切れる。経産省のDXレポートでも指摘されているPoC疲れの問題そのものです。
自分たちが舵を切ったのは「大型・反復・安定稼働」の案件に集中するという方針でした。具体的には、以下の基準を設けています。
- 年間契約額が一定額以上であること
- 導入後の運用改善フェーズに進む意思があること
- 社内にAI活用の意思決定者がいること（「とりあえずPoC」ではないこと）
この基準を満たさない案件は、丁寧にお断りしています。断ることで営業数字は短期的に下がりますが、チームの稼働率と利益率は上がった。一つの顧客に深く入ることで、ドメイン知識が蓄積され、提案の質も上がる。結果として契約更新率が高くなり、売上の予測可能性が改善されました。
誰に売るか：ペルソナの優先順位
ラボ型の契約を提案するとき、相手を間違えると話が進みません。自分たちの経験から、優先順位は明確になっています。
第1優先は事業部門長。AIを使って何を改善したいか、事業上の課題を持っている人ですね。この人が「やる」と決めれば、予算と体制がつく。技術的な詳細よりも、業務インパクトと投資対効果の話ができる相手です。
第2優先は調達・購買部門。特に大企業では、契約形態や単価の妥当性を見る人がいます。ラボ型の契約は従来の請負や派遣とは異なるため、契約形態の説明が必要になる。準委任と請負の違い、SLAの設計、解約条件などを明確にしておくことが重要で、ここを曖昧にすると後から揉めます。
第3優先はPM・技術責任者。現場で一緒に動く相手ですが、予算決裁権を持っていないことが多い。技術的な議論は盛り上がるものの、この人だけと話していても契約には至りません。
よくある失敗は、PMと意気投合して技術検証を進めたものの、部門長の承認が得られず案件が消えるパターン。最初から部門長にアクセスできる案件を優先することで、この空振りを減らしています。
差別化は文言ではなく契約設計で作る
「AI開発に強い」「最新技術に対応」といった文言で差別化しようとする会社は多いですよね。しかし、クライアントから見ればどこも同じに見える。
差別化が効くのは、契約と運用の具体性です。自分たちが提示しているのは以下のようなSLA設計。
開始SLA：契約締結から稼働開始まで2週間以内。チームのアサインと環境構築を事前に準備しておくことで実現しています。「契約したのに3ヶ月動かない」という不満を潰すためのものですね。
代替SLA：メンバーの離脱時、2週間以内に同等スキルの代替要員をアサイン。ラボ型で最も不安視されるのが「人が抜けたらどうなるか」という問題で、これに対する明確な回答を契約に入れています。
増員SLA：追加要員の要請から4週間以内にアサイン可能。事業が拡大したときにスケールできることを示します。
こうした具体的な数字を契約書に入れることで、「この会社は本気で運用を考えている」という信頼が生まれる。文言の差別化は一瞬で陳腐化しますが、運用設計の差別化は簡単に真似できません。
AIエージェントを活用した運用自動化についても、近年では注目が集まっています。実際にAIエージェント開発プラットフォームの比較記事でも紹介しているように、運用フェーズでの自動化ツール選定は重要な論点です。
契約前ゲート：断る基準を持つ
すべての案件を受けない、という判断は営業組織にとって抵抗がありますよね。しかしAI領域では、合わない案件を受けることのコストが大きい。
自分たちが設けている契約前ゲートは以下の通りです。
- データの所在と品質が確認できるか。「データはあるはず」は危険信号。
- 意思決定者が導入フェーズに関与するか。PMだけでは判断できない局面が必ず来ます。
- 運用改善フェーズへの移行を前提としているか。「まずPoCだけ」は原則受けません。
- 社内にAI活用を推進する担当者がいるか。外注丸投げでは定着しない。
これらを満たさない場合、理由を説明して辞退しています。断った案件のうち、後から条件を整えて再度相談に来るケースも少なくない。断ることは関係を切ることではなく、条件を明確にすること。そう捉えています。
なお、AI導入プロジェクトではデータドリフトだけでなく、モデルの精度評価手法自体の選定も重要になります。圧縮ベースの分類手法のような新しいアプローチも、運用ラボの中で継続的に検証していく対象です。
おわりに
AI案件のビジネスモデルは、まだ業界全体で模索している段階にあります。受託で成功している会社もあれば、SaaSで伸びている会社もある。ラボ型が唯一の正解だとは思っていません。
ただ、「作って納品して終わり」ではAIの価値が出にくいという構造は、かなり普遍的な問題だと感じています。クライアントにとっても、開発側にとっても、継続的な関与がある方が成果につながりやすい。
自分たちの場合、受託からラボ型に軸足を移したことで、売上の安定性、チームの学習効率、クライアントとの関係性、いずれも改善しました。同じ課題を感じている人にとって、何かの参考になれば幸いです。
関連記事として、GPT-5の法的推論能力に関する分析も、AIが専門領域でどこまで実用化されているかを考える上で参考になるかもしれません。