「導入直後はイマイチでした」が普通
AI 業務システムを社内に入れた経営者から、半年後にこんな声を聞くことがあります。
「最初の 1 ヶ月は、正直イマイチでした。期待していた回答が返ってこない、現場の事情を分かっていない判定が出る、抜け漏れもある。導入を止めようかと思った時期もありました。ただ、フィードバックを返し続けた結果、3 ヶ月目から急に賢くなって、半年後には欠かせない存在になっています」
これは特殊事例ではありません。実運用に乗っている経営支援 AI を構築・運用した経営者の証言として、「システム全体の 8 割はフィードバックループによってアップデートしていた」 という発言が公開対談でも紹介されています。
本稿では、この「8 割は育成」という構造を 3 つの角度から解説し、納品後に効かせるための保守設計の考え方を整理します。
※ 本稿は 2026 年 5 月時点の情報・事例観察に基づきます。
なぜ「納品時点完成」が成立しないのか
理由 1: 業務知識のほとんどは暗黙知
経営者・管理職・現場担当者が日々下している判断のうち、明文化・マニュアル化されている部分は ごく一部 であることが、ナレッジマネジメント分野で広く論じられています（野中郁次郎『知識創造企業』に代表される暗黙知・形式知の議論など）。残りの大半は「過去の失敗体験」「顧客との関係性」「組織の暗黙のルール」「業界慣習」など、本人が言葉にしない限り取り出せません。
AI に渡せる情報は、構築時点で言語化された部分だけ。それ以外の暗黙知は 使いながら少しずつ引き出して登録していく しかありません。
理由 2: 「重要度の判定基準」は組織ごと・人ごとに違う
たとえば「営業の失注をどう扱うか」という単純な問いでも：
- ある経営者：「失注は KPI の問題、即対策」
- 別の経営者：「失注の中でも戦略ターゲットセンターピンは即、それ以外は月次で集計」
- さらに別の経営者：「先方都合の失注は無視、自社要因の失注だけ詳細分析」
AI に「失注を検知したらアラート」と教えるのは簡単ですが、「どの失注をどのレベルで通知すべきか」は組織ごとに違う。これは現実の事象を AI が拾ってきて、経営者が「これは違う」「これは正しい」と都度フィードバックする中でしか調整できません。
理由 3: 環境が変わる前提
経営環境・市場・組織体制・取引先構成は半年単位で変化します。半年前に正しかった判定基準が、今は違うかもしれない。「定期的にチューニングする前提」がない AI システムは、半年で陳腐化 します。
「育成前提」の設計に必要な 3 要素
要素 1: フィードバックを記録する仕組み
AI からの出力に対して、人間が「採用」「不採用」「保留」を簡単に記録できる導線が必要です。Slack ボットなら絵文字 1 つでフィードバック、ダッシュボードならボタン 1 つ。摩擦が大きいとフィードバックは溜まりません。
要素 2: フィードバックを学習に反映する設計
記録された「不採用」の理由を、次回以降の判定基準に組み込む仕組みです。具体的には：
- 否認された判定パターンを「除外ルール」として明文化
- 採用された判定パターンを「成功事例」として蓄積
- 月 1 で蓄積された不採用理由を分析し、判定ロジックを更新
これらは AI 自身に「次回以降同じミスをしないよう、学んだことをマニュアルに追記しておいて」と指示することで自動化できます。
要素 3: 「育成のための時間」を契約に組み込む
ここが最も見落とされがちです。AI システムは構築費だけ払って終わりにすると、育成が止まり半年で陳腐化します。月額の保守契約で「フィードバック反映・追加学習・微調整」のための工数を確保 する必要があります。
弊社の保守プランがチケット制を採用しているのも、この「育成工数」を扱いやすくするためです。判定基準の見直し・新しい業務領域の追加・改善要望への対応を、月単位の柔軟な工数として確保できます。
詳細は 保守プランのご案内 をご参照ください。
「8 割育成」を前提とした受発注の作法
発注側（経営者・現場責任者）が知っておくべきこと
- 納品直後の出来は完成形ではない：使い始めてからフィードバックで化ける前提で評価する
- 3 ヶ月使い込む覚悟：1 ヶ月で判断しない。フィードバックが蓄積するのは 3 ヶ月目から
- 保守契約は必須：「構築費だけ」で済ませると半年で陳腐化する。月額の継続学習工数を確保する
受注側（構築事業者）が説明すべきこと
- 「完成系を最初に納品する」とは言わない：誤解を招き、納品後に「期待と違う」と揉める
- 「育成のための保守がセットです」と最初に提示：構築費の見積もりと同時に保守の必要性を伝える
- フィードバックの取り方を最初に設計：摩擦の少ない導線を用意し、記録テンプレートも納品物に含める
「育成前提」は新しい考え方ではない
実は、業務システム全般で「育てる」発想は昔からあります。基幹システムは導入後 3〜5 年かけて社内のフィットを取り続けますし、CRM や SFA も「使いながら定義を見直す」のが常識です。
ただし AI システムは、「数値ロジックの修正」ではなく「判断パターンの修正」を続ける という点で従来と質が違います。判断パターンは現場担当者しか持っていない暗黙知なので、その人の頭の中をフィードバックを通じて取り出していくことが、保守の中心業務になります。
「AI を入れたのに効かない」のほとんどは、AI の性能の問題ではなく、この育成サイクルが組み込まれていない ことが原因です。
関連記事
弊社では AI 業務システムの構築から、納品後の育成支援（保守チケット制）まで一貫して対応しています。詳しくは AI 活用診断（無料） からお問い合わせください。