目次
- なぜいま「人材ロックイン」を論点化するのか
- 構造1: モデル開発者一人称型 — 「あの人しか触れない」推論基盤
- 構造2: プロンプト職人型 — 暗黙知が業務フローに張り付く
- 構造3: MLOps属人化型 — パイプラインがブラックボックスに
- 構造4: ベンダー出向者依存型 — 契約終了とともに知財が消える
- 人材ロックインを解除する4つの設計原則
- まとめ
なぜいま「人材ロックイン」を論点化するのか
AI 導入の議論はこれまで「PoC をどう本番化するか」「どのモデルを選ぶか」に集中してきた。しかし 2025 年以降、運用フェーズに入った企業から共通して聞こえてくるのは、技術選定ではなく「特定の担当者が抜けた瞬間にプロジェクトが凍結した」という運用上の事故だ。編集部の取材では、PoC を超えて本番運用に移行した AI システムのうち、相当数が「キーマン 1 名のドキュメント化されていない判断」に依存していた。
この問題は、グローバルな調査からも裏付けられる。Stanford AI Index Report 2025 の Talent 章では、AI 関連職種の求人倍率が依然として高水準で推移し、特に MLOps・モデル評価エンジニアの転職サイクルが平均 18 か月程度に短縮していることが報告されている。一方、McKinsey “The state of AI” の最新版では、生成 AI を業務利用している企業のうち 65% が何らかの形で本番運用に踏み込んでいる一方、AI 人材の獲得・維持を「最大のボトルネック」と回答した経営層が約 4 割に達した。
ここから見えるのは、「採用しても続かない」「育てた直後に抜ける」という単純な離職問題ではない。問題の本質は、属人的に積み上がった判断ロジックが組織知に転換されないまま、個人の頭の中に閉じ込められる構造にある。本稿では、編集部が把握する典型的な凍結プロジェクトを 4 つの構造類型に整理し、それぞれの解除策を提示する。
構造1: モデル開発者一人称型 — 「あの人しか触れない」推論基盤
最初の類型は、社内で 1 名の機械学習エンジニアが独力でモデルアーキテクチャを設計し、推論基盤までを実装したケースだ。製造業や金融の中堅企業で頻繁に見られる。Stanford AI Index 2025 によれば、世界の AI 関連論文の 78% が産学いずれかの「少人数チーム」によって書かれており、特に企業内 R&D ではチーム規模 3 名以下が全体の約 40% を占める。この「小さな成功体験」がそのまま本番運用に持ち込まれる。
典型的な凍結シナリオはこうだ。初期 PoC でモデル精度 92% を達成した担当者が、独自の前処理パイプラインと評価指標を組み込んだまま本番化を進める。スケジュール優先のため、ドキュメントは README 1 枚と Jupyter Notebook のコメント程度。そして本番稼働から 14 か月後、担当者が外資系 AI ベンダーに転職した瞬間、再学習のジョブがエラーを吐いても誰も原因を特定できない。
この構造の怖さは、「動いている間は問題が顕在化しない」点にある。McKinsey の調査では、AI を本番運用する企業の 23% が「過去 12 か月以内に、担当者離脱を理由としたモデル更新停止を経験した」と回答している。更新停止はそのままモデルドリフトを意味し、業務判断の精度が静かに劣化していく。
解除策は、設計レビューを「相互理解」ではなく「再現可能性」の観点で行うことだ。具体的には、(1) モデルカードを必須化し評価指標と前提条件を明文化する、(2) 推論コードと学習コードを別リポジトリに分離し依存関係を明示する、(3) 担当者交代を前提とした「30 日引き継ぎプロトコル」を契約段階で組み込む。これらは抽象論ではなく、AI Index 2025 が示す「Responsible AI 実践指標」の Governance カテゴリでも推奨される運用要件である。
構造2: プロンプト職人型 — 暗黙知が業務フローに張り付く
第二の類型は、生成 AI の業務適用が広がった 2024 年以降に急増した。社内に「プロンプトを書くと劇的に良い結果を返す」職人的人材が現れ、その人物が組み立てたプロンプトテンプレートが営業資料生成、契約書レビュー、顧客対応スクリプトなどの業務フローに組み込まれる。
McKinsey “The state of AI” の調査では、生成 AI を業務利用する企業の 71% が「自社開発のプロンプトテンプレートを保有している」と回答した一方、テンプレートの版管理を行っている企業は 28% にとどまる。残る 7 割超は、Slack のスレッドや個人の Notion に散らばったプロンプトを「なんとなく」運用している状態だ。
編集部が取材した中堅 SaaS 企業の事例では、カスタマーサクセス部門で導入された問い合わせ要約 AI のプロンプトを単独で改良し続けていた担当者が育休に入った 3 週間後、要約精度の体感品質が急落した。原因を調査すると、本人が GPT のバージョンアップに合わせて「temperature と system プロンプトを微調整する暗黙のルーチン」を毎週走らせていたことが判明した。この調整は引き継ぎ資料に一切記載されていなかった。
プロンプト職人型のロックインは、技術スタックが軽量であるがゆえに「資産」として認識されにくい点が厄介だ。解除策は、プロンプトを「ソフトウェアアセット」として扱うことに尽きる。Git によるバージョン管理、評価セット（ゴールデンデータ）の維持、A/B テストの記録という 3 点セットを最低限の運用要件とすべきだ。Stanford AI Index 2025 でも、産業界における Responsible AI 実装のうち「プロンプトの監査ログ保存」を実施している企業は前年比 +18 ポイントに伸びており、業界標準化が進んでいる。
構造3: MLOps属人化型 — パイプラインがブラックボックスに
第三の類型は、データパイプラインと再学習基盤を構築した MLOps エンジニアが組織を離れることで、システム全体が「触れない聖域」と化すケースだ。AI Index 2025 によれば、本番運用される機械学習システムの平均構成要素数は 2020 年比で約 2.3 倍に増えており、特徴量ストア、ベクトル DB、評価基盤、モニタリングが多層化している。
この複雑性は、構築フェーズでは「効率化」として歓迎されるが、運用フェーズでは負債に転じる。McKinsey 調査では、AI 本番運用企業の 38% が「MLOps ツールチェーンの内部仕様を完全に理解しているのは 1 名以下」と回答した。これは IT 部門が外注した ERP 改修より、構造的に脆い状態である。
編集部が把握する具体例では、ある中堅製造業が予知保全モデルを本番運用するために、Airflow + MLflow + 自社開発の評価ダッシュボードを組み合わせた構成を採用した。中核を担っていたエンジニアが転職した後、Airflow の DAG が深夜に失敗し続けたが、誰も復旧手順を把握しておらず、最終的に外部 SI に 6 か月・約 4,800 万円の再構築を発注する羽目になった。
解除策は、ツールチェーンの選定段階で「離脱耐性」を評価軸に組み込むことだ。具体的には、(1) マネージドサービスの利用比率を高める、(2) IaC（Terraform 等）で構成をコード化する、(3) Runbook を「担当者が 1 週間休んでも運用が回るか」というベンチマークでレビューする、の 3 点が現実的な打ち手となる。
構造4: ベンダー出向者依存型 — 契約終了とともに知財が消える
第四の類型は、AI ベンダーから出向またはオンサイト常駐の形で派遣されたエンジニアが、事実上の社内キーマンとなっているケースだ。中堅・大企業の DX 推進部門で頻発する。AI Index 2025 のデータでは、グローバルで AI 関連の業務委託・常駐契約は 2023 年比で 41% 増加しており、特に日本市場では「内製化を目指しつつベンダー人材に依存する」過渡期が長期化している。
この類型の最大のリスクは、契約終了とともに「実装ノウハウ」「学習データの前処理ロジック」「評価指標の選定根拠」といった知財資産が、合法的にベンダー側に帰属する形で消失することだ。McKinsey 調査では、AI 業務委託を活用する企業のうち「契約終了時の知財帰属を明文化している」のは 44% にとどまり、残る 56% は曖昧な状態で運用している。
編集部が取材した事例では、生成 AI を活用した社内ヘルプデスクを構築した大企業が、ベンダー常駐者の契約終了 3 か月後、回答品質の劣化に直面した。原因を追跡すると、ベンダー側が独自に保有していた「業界用語の正規化辞書」と「評価ルーブリック」が引き継ぎ対象外であり、これらが品質維持の中核だったことが判明した。再構築には 9 か月の遅延と約 1.2 億円の追加投資が必要となった。
解除策は契約設計の段階で組み込む必要がある。(1) 成果物の定義に「再現可能なドキュメント」「評価データセット」「運用 Runbook」を明示する、(2) 知的財産権の帰属条項で「業務遂行中に作成された全ての中間生成物」を発注側に帰属させる、(3) 契約終了 60 日前から「知識移管期間」を設定し、社内エンジニアによるシャドーイングを義務化する。これらは Stanford AI Index 2025 の Responsible AI 章 でも、商業 AI 利用におけるベストプラクティスとして挙げられている要件である。
人材ロックインを解除する4つの設計原則
4 類型を横断する解除策は、結局のところ「組織知への転換速度をどう上げるか」に集約される。編集部は、取材と一次ソースの分析から以下 4 つの原則を提示する。
第一に、再現可能性を品質指標に組み込む。 モデル精度や応答速度だけでなく、「別のエンジニアが同じ環境を再現するまでに必要な工数」を運用 KPI として可視化する。AI Index 2025 では、Responsible AI を実装する企業のうち再現性指標を導入しているのは 31% であり、まだ伸びしろが大きい領域だ。
第二に、ドキュメントを「成果物」として扱う。 モデルカード、データシート、評価レポート、Runbook を、コードと同等の納品物として位置づける。McKinsey 調査では、これら 4 種類すべてを揃えている企業の AI ROI 達成率は、未整備企業の約 2.4 倍に達する。
第三に、ナレッジ移管を契約と人事制度に組み込む。 ベンダー契約には知識移管期間を、社員には「離任前 30 日の引き継ぎ義務」を制度化する。属人性は善意では解消されず、ルールでしか解除できない。
第四に、評価データセットを社内資産として独立管理する。 モデルやプロンプトは更新可能だが、評価データだけは組織の判断基準そのものを反映する。これを失うと、品質の連続性が根本から断たれる。
まとめ
AI プロジェクトの凍結は、技術的な失敗ではなく組織設計の失敗である。Stanford AI Index 2025 と McKinsey “The state of AI” が共通して指摘するように、AI 人材の流動性が高まる時代において、特定個人への依存は事業継続リスクそのものだ。本稿で示した 4 類型 — モデル開発者一人称型、プロンプト職人型、MLOps 属人化型、ベンダー出向者依存型 — は、いずれも「動いている間は見えない」性質を持つ。だからこそ、運用開始前に解除策を組み込む必要がある。
意思決定者が今日から着手すべきは、(1) 本番運用中の AI システムについて「担当者 1 名が抜けた場合の復旧計画」を文書化する、(2) ベンダー契約の知財条項と引き継ぎ要件を再点検する、(3) プロンプトと評価データを Git 管理下に移す、の 3 点である。これらは投資判断ではなく、すでに走っているプロジェクトの保険である。
関連記事
- AI導入失敗回避ジャーナル（無料購読） — 週次配信
- 無料相談を予約 — 編集部があなたのAI導入をサポート