AI導入の失敗が見え始めたとき、追加開発を急ぐほど問題が深くなることがあります。PoCでは良かったのに本番データで精度が落ちた、現場が使わない、ERPや設備との連携で止まった、ベンダーから同じ調整提案だけが続く――。この局面で必要なのは、新しいAI導入ロードマップではありません。すでにある案件の事実を30日で集め、症状と原因を分け、継続・縮小・再設計・停止の4択を証拠で決めるリカバリー診断です。
本稿は、タイ拠点で止まった、または期待未達となったAIプロジェクトを立て直す実務ガイドです。失敗率のような根拠が弱い統計や、架空の費用・実績は使いません。baseline、test set、holdout、業務KPI、モデル指標、data drift、human override、IT/OT統合、ログ、stop rule、契約・exit資料をどう再点検し、意思決定メモへまとめるかを解説します。
AI導入の失敗を「症状」で終わらせない
会議で聞こえる「精度が悪い」「遅い」「使われない」は原因ではなく症状です。精度低下一つをとっても、入力分布の変化、正解ラベルの誤り、業務定義の変更、前処理の差、権限制御、モデル版、閾値、UI、教育不足など複数の原因があり得ます。症状の言葉だけでベンダーへ「改善してください」と依頼すると、モデル調整だけが続き、業務やデータの問題が残ります。
最初の診断会議では、意見を反論し合わず、観測事実に変換します。
| 症状の言い方 | 診断可能な事実へ変換する例 |
|---|---|
| 精度が悪い | どの期間・拠点・製品・言語・クラスで、どの指標がbaseline比どれだけ変わったか |
| 現場が使わない | 対象ユーザー、利用機会、実利用、離脱点、手修正、代替手順を記録する |
| 遅い | end-to-endの待ち時間を、前処理・推論・API・画面・人の承認へ分解する |
| 連携できない | system of record、API、ネットワーク、認証、データ型、所有者のどこで止まるか |
| 費用対効果がない | 現行baseline、導入後の業務差、追加運用負荷、便益の対象期間を揃える |
「誰の責任か」を先に決めるのではなく、「どの仮説を、どの証拠で棄却できるか」を決めます。責任分界は後で契約と照合できますが、データを保全しないまま責任論を始めると再現に必要なログが失われます。
30日診断を始める前の保全措置
リカバリーの初日に大規模な設定変更や再学習をしないでください。変更前の状態が唯一の比較基準である場合があります。まず「診断凍結」を宣言し、緊急の安全対策を除いてモデル、prompt、閾値、前処理、検索index、データ接続を承認なしで変えないようにします。
最初の48時間で保全するもの
- 本番とPoCのモデル、prompt、ルール、依存ライブラリ、コンテナの版。
- 学習・検証・test・holdoutデータの識別子、抽出条件、ハッシュ、作成日。
- 入力、出力、confidence、引用、エラー、応答時間、human overrideのログ。
- ERP、MES、SCADA、データレイク、API gatewayのinterface仕様と変更履歴。
- 要件、受入基準、PoC報告、議事録、変更要求、障害票、ベンダー報告。
- 契約、SOW、データ処理条項、SLA、知財、終了支援、再委託先一覧。
個人データや営業秘密を含む可能性があるため、診断用コピーを無制限に作らないことも重要です。タイのPDPAについてはETDAが公開する公式資料を起点に、処理目的、アクセス権、保存期間、委託関係を法務・DPOと確認します。本稿は法的助言ではありません。
30日AIプロジェクト立て直しの全体像
30日は魔法の修復期間ではなく、意思決定に必要な証拠を揃えるtimeboxです。すべてを直すのではなく、これ以上の投資判断を曖昧にしないことを成果にします。
Day 1–5：事実保全と症状マップ
契約・要件・版・データ・ログを凍結し、症状を業務、モデル、データ、連携、運用、ガバナンスへ分類します。経営、業務、現場、IT、セキュリティ、法務、ベンダーから各1名以上を集め、同じ時系列を作ります。「当初何を達成する予定だったか」「いつから何が変わったか」「誰がどの変更を承認したか」を並べます。
成果物は、evidence inventory、症状マップ、変更タイムライン、未取得証拠一覧です。ここでは解決策を決めません。
Day 6–12：baselineと評価設計の再構築
元の成功基準が曖昧なら、現行業務baselineを取り直します。test setとholdoutの分離、ラベル品質、対象母集団、期間、製品・言語・シフト別の分割を確認します。PoC時のデータが本番条件を代表していたかも検証します。
成果物は、metric dictionary、データ系譜、再現可能な評価スクリプト、評価対象の版、既知の偏りです。
Day 13–20：原因仮説と限定実験
原因仮説ごとに、最小の変更で差が出る実験を行います。一度にモデル、prompt、データ、閾値を全部変えると何が効いたか分かりません。例えば、同一モデルで前処理だけを戻す、同一test setでモデル版だけを変える、human override前後の業務結果を比較する、という単変量に近い比較を優先します。
成果物は、仮説・実験・結果・不確実性・再現条件の台帳です。
Day 21–26：運用・統合・契約の回収可能性を評価
モデルが直せても、データ権利、API、OT安全、運用体制、ベンダー依存が回収不能なら本番化できません。技術と別に、運用費用のdriver、担当者、監視、障害対応、ソース・設定の引渡し可能性を確認します。
Day 27–30：4択のdecision memoを承認
継続・縮小・再設計・停止の各案について、便益、残存リスク、必要資源、最初の検証、stop rule、契約影響を同じ書式で比較します。最終日には「検討継続」ではなく、期限・責任者・次の証拠を伴う決定を残します。
baselineを作り直す
AI導入失敗の診断で最も多い混乱は、比較対象がないことです。AIの導入前後で、対象件数、製品mix、シフト、担当者熟練度、需要が変わっていれば単純比較できません。baselineは「AIなしの理想値」ではなく、同じ条件で実行した現行または代替手段の実測です。
baselineに含める3層
- 業務baseline：処理時間、再作業、一次解決、不良流出、停止時間など。
- 既存方式baseline：ルール、検索、統計モデル、人の判断など、AIの比較対象。
- リスクbaseline：誤りの重大度、個人情報露出、未承認操作、復旧時間など。
AIがモデル指標で改善しても、確認作業が増えて業務時間が長くなれば期待未達です。逆にモデルの平均点が大きく伸びなくても、重大な見逃しを人へ確実に回せるなら業務価値が出る場合があります。モデルと業務を同じ表に載せてください。
test setとholdoutの汚染を点検する
PoCが良く本番で崩れた案件では、評価データが開発へ混入していないかを確認します。test setを見ながらpromptや閾値を調整し続けると、実質的にtest setも学習に使われます。そこで診断時には用途を分けます。
- training/development：学習やprompt改善に使用。
- validation：方式、閾値、hyperparameter選択に使用。
- test：選んだ方式の性能を評価。繰り返し最適化に使わない。
- holdout：最後の意思決定まで触れない、独立した確認用。
- production shadow：本番分布を継続観測するが、自動実行には使わない入力。
データ件数が少ない場合でも、分割の思想は必要です。単純なランダム分割が不適切なこともあります。同一設備・同一文書・近接時刻のデータが両側に入るとleakageが起きるため、設備、顧客、期間、ロットなど意味のある単位で分けます。重複、派生データ、ラベル作成者、版を記録します。
NIST AI RMF CoreのMEASUREは、test set、metric、TEVVに用いたtoolの詳細を文書化することや、deploymentに近い条件での測定、運用中の監視を挙げています。Coreはチェックリストや必ず順番に実行する手順ではなく、GOVERN、MAP、MEASURE、MANAGEの4機能を文脈に応じて反復する枠組みです。診断では「測った数字」だけでなく測り方を再現可能にします。
業務KPIとモデル指標を分けて再評価する
モデル指標は必要ですが、それだけで継続判断はできません。診断表では各モデル指標を、影響する業務KPIと対応付けます。
| 用途 | モデル・システム指標 | 対応する業務KPI |
|---|---|---|
| 文書回答 | factuality、citation一致、abstention、latency | 検索時間、一次解決、誤案内、再確認時間 |
| 画像検査 | defect別recall、precision、処理速度 | 不良流出、過検出再検、line taktへの影響 |
| 需要予測 | 誤差分布、bias、重要期間の誤差 | 欠品、余剰、計画変更、緊急輸送 |
| 保全支援 | 検知率、予告時間、誤報 | 計画外停止、点検工数、不要交換 |
平均値だけでなく、製品、設備、言語、ユーザー、シフト、リスクclassで分割します。重大な少数クラスが平均に隠れていないかを確認します。また、AIを使った群と使わない比較群で、選択biasがないかも見ます。
data driftとcontext driftを切り分ける
data driftは入力分布の変化ですが、期待未達の原因はそれだけではありません。ラベルと入力の関係が変わるconcept drift、業務目的や運用条件が変わるcontext drift、sensor交換やETL変更によるpipeline drift、ユーザー行動の変化があります。
drift診断表
| 種別 | 例 | 確認証拠 | 対応候補 |
|---|---|---|---|
| Data drift | 製品mix、言語、照明が変化 | 時系列分布、segment別指標 | 監視、再サンプリング |
| Concept drift | “正解”の業務判断が変化 | 新旧label方針、専門家合意 | label再定義、再評価 |
| Pipeline drift | 単位、欠損補完、APIが変化 | schema、ETL版、interface log | 前処理修正、契約test |
| Context drift | 利用者や意思決定が変化 | SOP、権限、利用ログ | scope縮小、業務再設計 |
「driftを検知したら即再学習」では危険です。原因がラベル方針やETLなら、再学習が誤りを固定化します。drift検知、影響評価、承認、再評価、releaseの順を定めます。
NIST AI Metrology Centerは、AI RMFの特性とlifecycleに対応するmetric、methodology、toolを探すためのリソースです。ただし、掲載はNISTによるendorsement、validation、適合性判断ではないと明記されています。診断では便利なmetricを採用するだけでなく、自社use caseに適切かを検証します。
human overrideが本当に機能したかを確認する
「最終判断は人」と仕様書に書いてあっても、現場ではoverrideできないことがあります。AIの提案が既定値になり、拒否に理由入力が必要、処理時間が短すぎる、権限がない、AIへ反対すると評価が下がる、といった設計は形式上のhuman-in-the-loopにすぎません。
診断では、override率を高い・低いだけで評価しません。overrideした場面、理由、結果、所要時間、AIのconfidence、ユーザー役割を確認します。正しいoverrideが少ないのか、必要なのにできなかったのかは意味が違います。停止権限と再開承認者、手動手順、異議申立て、ログ保全までテストします。
integrationとIT/OTをモデルから切り離して診断する
タイ工場では、AIモデルが正常でもERP、MES、SCADA、PLC、camera、network、時刻同期のどこかで結果が崩れます。モデルを再学習する前に、入力から業務処理までのend-to-end traceを1件ずつ追います。
確認するのは、system of record、データ取得時刻、単位、欠損、再送、順序、ID対応、権限、timeout、buffer、手動切替です。画像ならcamera設定、照明、レンズ、trigger、圧縮を固定できているか、sensorなら校正と交換履歴があるかを確認します。OT制御へ出力する案件は、AIを読み取り専用へ戻せるか、fail-safeが設備側にあるか、変更が品質手順や顧客承認の対象かを点検します。
AIチームだけで診断せず、設備、制御、品質、生産、保全、情報セキュリティを含めます。責任境界がモデルAPIで途切れている場合、end-to-end KPIのownerを新たに置く必要があります。
ログと再現性でAIベンダー見直しを行う
AIベンダーの見直しは、関係悪化を前提にするものではありません。再現性と移管性を、契約した成果物として確認する作業です。診断用sampleについて、第三者または発注側が同じ版、同じ入力、同じ設定で結果を再現できるかを試します。
最低限必要な再現パッケージ
- architectureとdata flow、モデル・prompt・rule・indexのversion対応表。
- 実行環境、dependency、configuration、secret参照方法。
- 評価データの生成手順、ラベル定義、metric計算code、期待結果。
- deployment、rollback、monitoring、incident、backup、decommissionのrunbook。
- third-party API、OSS、license、利用規約、subprocessorの一覧。
- 既知制約、未解決issue、技術負債、変更backlog。
再現できない理由を、ベンダー独自技術だからと片付けないでください。知財を開示できない部分があっても、入力条件、出力、interface、性能、監視、終了時のexportは合意できます。ブラックボックス範囲と発注側が検証できる境界を契約に明記します。
stop ruleを先に書く
立て直しが長期化する最大の要因は、「もう少し調整すれば良くなる」という期待に期限がないことです。recovery sprintを始める前にstop ruleを承認します。
stop ruleの例は、重大安全classの最低基準をholdoutで満たさない、権限外データ露出が再現する、指定日までにデータ権利を確認できない、手動fallbackを制限時間内に実行できない、必要なログを生成できない、改善幅が事前のminimum effectを下回る、といったものです。数値は案件のrisk toleranceから決め、一般値をコピーしません。
停止は必ずしも全廃ではありません。自動実行だけ止めてdecision supportへ戻す、対象製品を限定する、機微データを外す、特定言語だけ継続することもできます。stop ruleと縮小案をセットで用意します。
継続・縮小・再設計・停止の4択
継続
原因が特定され、限定実験で改善が再現し、残存リスクが許容範囲にある場合です。継続条件には、次の評価日、監視owner、変更承認、stop ruleを付けます。惰性の継続は選びません。
縮小
一部segmentでは価値があるが、全拠点・全製品・全言語では成立しない場合です。対象範囲、利用者、権限、手作業を明示し、縮小後のKPIを再定義します。PoC規模へ戻すのではなく、価値が確認できた狭いproductionにします。
再設計
目的は有効だが、architecture、data pipeline、human workflow、評価設計が根本的に合わない場合です。既存成果の再利用可能範囲と捨てる範囲を分け、新しい設計を別projectとして承認します。元案件の成功扱いにして予算を付け替えないことが、説明責任上重要です。
停止
目的に対する価値がない、重大リスクを制御できない、データや権利が確保できない、代替手段の方が合理的な場合です。停止には、ユーザー通知、手動手順、データ返却・削除、権限停止、契約精算、資産保管、lessons learnedを含めます。
NIST AI RMF CoreのMANAGEは、意図した目的を達成するか、開発・deploymentを進めるべきかを判断し、必要に応じてsystemをsupersede、disengage、deactivateする仕組みを扱います。停止判断は失敗の隠蔽ではなく、risk managementの正規の選択肢です。
decision memoのテンプレート
30日目の成果は長い報告書ではなく、承認できる短いdecision memoです。付録に証拠を置き、本文は次の1〜3ページに絞ります。
- 当初目的と現在の症状：範囲、対象ユーザー、期待値、観測事実。
- 原因と確信度：confirmed、probable、unresolvedを分ける。
- 再評価結果：baseline、holdout、segment、業務KPI、リスク、統合。
- 4案比較：便益、残存risk、必要資源、時間、契約影響。
- 推奨判断：継続・縮小・再設計・停止の一つと理由。
- 条件とstop rule：次のgate、owner、証拠、期限。
- 反対意見：未解決の異論と、それでも決める理由。
U.S. GAOのAI Accountability Frameworkは、governance、data、performance、monitoringの4原則を中心に説明責任を整理しています。もともと連邦機関等向けですが、既存AI案件を監査可能な問いへ分解する参考になります。企業へそのまま適用する法的要件ではありません。
契約とexit資料を診断する
AIプロジェクトの立て直しでは、技術より契約が選択肢を制限することがあります。モデルやcodeの権利、データexport、ログ取得、第三者API、最低利用期間、終了支援が不明だと、再設計やベンダー変更を比較できません。
確認する資料は、master agreement、SOW、change order、DPA、SLA、license、acceptance記録、請求根拠、subprocessor、終了条項です。契約と実態が違う場合は、事実を記録して法務へ渡します。
exit readinessの確認項目
- data、label、prompt、設定、log、評価結果をmachine-readable形式で受け取れるか。
- 顧客所有、ベンダー所有、third-party資産を分離できるか。
- credential、接続、ユーザーを停止し、backupを含む削除証明を得られるか。
- 後任が必要なinterface、schema、runbook、既知制約を受け取れるか。
- 稼働中に並行移行する期間と、安全に停止できる時点があるか。
ISO/IEC 42001:2023はAI management systemを確立、実装、維持、継続改善するための要求事項を示します。認証の有無だけでリカバリー判断を決めるのではなく、責任、risk assessment、変更、監視、是正、継続改善がこの案件で記録されているかを見ます。
2026年のTEVV資料をどう扱うか
NISTは2026年8月7日、AI system評価のためのTEVV-Athlon FrameworkについてNIST AI 200-2のinitial public draftへの意見募集を開始し、2026年10月6日までコメントを受け付けると案内しました。これは確定標準ではありません。多様なAI use caseに合わせてtest、evaluation、verification、validationを設計する考え方を検討する資料として参照し、契約上の必須規格や適合認証のように扱わないでください。
同資料は、組織のTEVV目的に基づくcustomized assessmentの構築を意図しています。リカバリー診断では「モデルを一つの点数で再評価する」のではなく、業務目的に合わせてevent、tool、measurement conceptを組み合わせる発想が役立ちます。ただしdraftの用語や構造が変わる可能性をdecision memoに明記します。
ETDAのGenerative AI Governance Guidelineも、便益だけでなく限界、risk、適用形態、governanceを組織文脈で考える材料になります。ガイドラインであることを踏まえ、タイの法令や契約上の義務とは区別して使います。
AI導入失敗のFAQ
AIプロジェクトの立て直しはベンダーを替えることですか？
同義ではありません。原因が要件、データ、社内運用にあればベンダー変更だけでは再発します。まず証拠と再現性を確認し、現ベンダーでの是正、scope縮小、architecture再設計、移管を同じ条件で比べます。
AI PoCを再評価するとき、同じtest setを使えますか？
過去に調整へ繰り返し使ったtest setは独立評価に向かない場合があります。用途履歴を確認し、必要なら未使用holdoutを作ります。データが少なければ、時間・設備・顧客単位の分割やblind reviewでleakageを減らします。PoCの費用と成功条件を初期から整理する方法は「タイのAI PoC費用と成功基準」も参照してください。
モデル精度が改善すれば継続してよいですか？
それだけでは不十分です。業務KPI、重大class、権限、human override、latency、integration、運用負荷、残存riskを同時に確認します。受入評価の設計は「タイ企業のAI品質管理と受入テスト」でも解説しています。
現場がAIを使わない原因は教育不足ですか？
教育だけとは限りません。結果が遅い、修正が面倒、責任が曖昧、既存SOPと競合する、overrideできない、KPIが利用回数だけ、という設計原因があります。利用ログと現場観察で離脱点を特定します。運用定着を継続的に設計する観点は「タイ拠点のAI活用定着支援」を参照してください。
30日でシステムを直せますか？
本稿の30日は修復完了を約束する期間ではなく、投資判断を可能にする診断timeboxです。限定的な修正は行いますが、成果は原因、再評価、選択肢、stop rule、契約影響を証拠でまとめることです。
停止判断をすると投資が無駄になりますか？
継続による追加損失とriskを避け、データ、評価方法、interface、lessons learnedを次へ残せるなら、停止にも価値があります。sunk costではなく、将来の便益とriskで判断します。
まとめ：失敗案件を直す前に、判断できる状態へ戻す
AI導入の失敗局面では、モデルの追加調整を急ぐより、版・データ・ログ・契約を保全し、症状と原因を分離することが先です。30日のrecovery sprintでbaseline、test setとholdout、業務KPI、drift、human override、IT/OT、再現性、stop ruleを確認し、継続・縮小・再設計・停止の4案を同じdecision memoで比較します。
タイ拠点で止まったAI案件について、どこから証拠を回収し、モデル問題と業務・IT/OT問題をどう切り分けるかを整理したい場合は、TOMAS TECHへご相談ください。診断段階から参加し、無理な継続を前提にせず、次の意思決定に必要な材料を整えます。
参考にした一次情報（2026年9月2日確認）
- NIST AIRC, AI RMF Core
- NIST, AI Resource Center
- NIST AIRC, AI Metrology Center
- NIST, The TEVV-Athlon Framework for Evaluating AI Systems
- U.S. GAO, Artificial Intelligence: An Accountability Framework for Federal Agencies and Other Entities
- ISO, ISO/IEC 42001:2023 AI management systems
- ETDA, Generative AI Governance Guideline for Organizations
- ETDA, Thailand Personal Data Protection Act resources
