「標準化できない業務」をAIに移管する4フェーズ設計書

2026-08-02 • 属人業務改善

あなたの工場に、こんな業務はないだろうか。

「Aさんがいれば何とかなる」「この段取りはBさんに確認しないと進められない」「顧客のC社への対応は経験がないと難しい」——。

こうした業務を「標準化できない」と片付けてしまうと、永遠に同じ問題が繰り返される。熟練者が異動・退職するたびに生産が止まり、後継者育成に何年もかかり、DX推進の話が出るたびに「まずは人の問題から」と先送りされる。

しかしここで問いを変えてみてほしい。「その業務は本当に標準化できないのか、それとも可視化の手順を知らないだけなのか」と。

トヨタは2022年、工場の従業員が自分でAIモデルを作れるプラットフォームを構築した。2024年までに全10工場へ展開し、従業員が作ったAIモデルは1万件に達した(2023年の8,000件から増加)。製造工程では年間1万人時(マンアワー)を超える削減を実現している。そして2025年、この動きは「GAIA」という全社イニシアチブに発展し、11の重点領域の一つに「ナレッジ保持・移転」が明記された。専門家の独占物だった知識を、体系的なプロセスによって「組織の資産」に変えた事例だ。

この記事では、「標準化できない業務」をAIに移管するための設計全工程を示す。可視化・構造化・ルール化・AI実装の4フェーズを順に解説し、各フェーズで使えるワークシートの骨格も示す。必要なときに繰り返し参照できる総合ガイドとして構成した。

「この人しかできない」をシステムへ——可視化から始まる属人業務の移管設計

「この人しかできない」をシステムへ——可視化から始まる属人業務の移管設計

なぜ「標準化できない」と思い込むのか——暗黙知の構造を理解する

属人業務の核心は、担当者が「無意識に行っている判断」の積み重ねにある。

知識管理の分野では、野中郁次郎・竹内弘高によるSECIモデル(1995年、著書『The Knowledge-Creating Company』)が今も基本フレームワークとして使われている。このモデルによれば、知識には「暗黙知(Tacit Knowledge)」と「形式知(Explicit Knowledge)」の二種類があり、両者の変換サイクルによって組織知が形成される。

  • 共同化(Socialization):体験を通じた暗黙知の共有(OJT、見て学ぶ)
  • 表出化(Externalization):暗黙知の言語・図解への変換(マニュアル化)
  • 連結化(Combination):形式知同士の統合・再編(データベース化)
  • 内面化(Internalization):形式知を実践を通じて暗黙知に変換(習熟)

製造現場の属人業務は、「共同化」の段階で止まっていることが多い。Aさんを見て学ぶだけで終わり、「表出化」——言語・構造への変換——が行われていない。

AIが介入できるのは「連結化」以降だ。つまりまず人間が表出化を行わない限り、AIへの移管は始まらない——というのが従来の前提だった。

ここに一石を投じているのが、2026年に発表されたarXiv論文「Tacit Knowledge Management with Generative AI: Proposal of the GenAI SECI Model」(北陸先端科学技術大学院大学・内平直志)だ。この論文は「完全な形式知化を経ずとも、現場で撮った写真や音声メモといった『断片的な知識』のまま生成AIが集約・活用できる」という提案を示している。生成AIは表出化・連結化・内面化の3プロセスに適用可能とされ、想定システム(Smart Voice Messaging System / Digital Knowledge Twin)は音声メッセージ・写真・センサーデータを半自動で集約する仕組みだ。

つまり「完璧に言語化してからAIへ」ではなく「断片を出しながらAIに整理させる」という進め方もありうる。ただし同システムは開発中で、効果の実証はこれからだ。

だからこそ本記事は、外部ツールなしで今日から着手できる「人間による表出化を先に行う」アプローチを軸に据える。ここで作った判断記録や決定木は、将来こうしたAIツールが実用化されたときの学習材料としてもそのまま使える。無駄にはならない。

フェーズ1:可視化——「何をどう判断しているか」を引き出す

移管設計の出発点は「当事者インタビューと観察記録」だ。ただし、ただ話を聞くだけでは暗黙知は出てこない。構造化された問いかけが必要になる。

ワークシート1:判断記録シート(可視化フェーズ)

項目 記載内容
業務名 例)受注品の段取り順序決定
判断が発生するタイミング 例)前日夕方・当日朝・材料入荷後
判断に使う情報 例)納期・材料在庫・機械の段取り替え時間・顧客の優先度
判断の選択肢 例)A機→B機、C機→B機の2択
選択の決め手 例)C社は欠品NGなので必ず先行、A社はリードタイム2日の余裕あり
例外ケース 例)急加工が入ったとき、機械トラブル時
確認相手 例)自己判断 / 上司確認 / 顧客確認

このシートを記入してもらうだけでは不十分だ。「なぜその情報を判断に使うのか」を繰り返し問うことで、判断の「深部」に潜む前提条件が引き出される。LLM(大規模言語モデル)を使った構造化インタビューでも、この「なぜ」の連鎖を追いかける補助として活用しやすい。

可視化フェーズの落とし穴

よくある失敗は「手順書を作れば完了」と思い込むことだ。手順書は「何をするか」しか書けない。AIに移管するためには「なぜその順序か」「例外をどう判断するか」を構造化する必要がある。可視化で終わってはいけない。

フェーズ2:構造化——判断を「決定木」に変換する

可視化で得た判断記録を、次に**決定木(ディシジョンツリー)**として構造化する。これがAI移管設計の核心部分だ。

暗黙判断を決定木に変換するイメージ——「なぜその順番か」を条件分岐として可視化する

暗黙判断を決定木に変換するイメージ——「なぜその順番か」を条件分岐として可視化する

ワークシート2:決定木設計シート(構造化フェーズ)

START:段取り順序の決定

└─[Q1] 顧客の優先度クラスはAか?
   ├─ YES → [Q2] 当日の機械B稼働率は80%超か?
   │          ├─ YES → 機械Cを先行割り当て
   │          └─ NO  → 機械Bを通常割り当て
   └─ NO  → [Q3] 納期まで2日以上あるか?
              ├─ YES → 標準スケジュール
              └─ NO  → 緊急フラグ → 上長確認

この木構造を作る過程で必ず直面するのが「条件を言語化できない判断」だ。「なんとなく危なそう」「Aさんの顔色を見て決める」といった判断がここで顕在化する。

これらは「判断の曖昧領域」として別管理する。AIに渡せる部分と渡せない部分を最初から分類しておくことが重要だ。

AI移管可否の三軸評価

属人判断をAIに移管できるかどうかは、以下の三軸で評価する。

評価軸 AIへの移管に向く 人が残るべき
判断の曖昧性 条件を言語化できる 「経験からくる勘」が必要
確認コスト データで確認できる 顧客や他部門への確認が必要
例外の頻度 月数回以下、かつ対応パターンが決まっている 週複数回、対応も都度異なる

この評価を業務ごとに行い、「AIが担う領域」「人が判断しAIが補助する領域」「人のみの領域」の三つに分類する。「全部AIに」という発想は捨てることが大前提だ。

フェーズ3:ルール化——「例外」こそが本番のデータになる

構造化した決定木の次のステップは「例外処理マトリクス」の作成だ。

多くの現場では、例外ケースが日常的に発生している。しかしこの例外こそが「ベテランの本当の知識」が凝縮されている場所でもある。

ワークシート3:例外処理マトリクス(ルール化フェーズ)

例外ケース 発生頻度 担当者の対応 判断根拠 AIへの組み込み方針
機械Bが突発停止 月1〜2回 機械Cに振り替え+C社に連絡 C社はリード緩いが欠品NG ルール化可(頻度は基準内で対応パターンも一意)
急加工オーダー入荷 週1回程度 全スケジュール再計算 単価が高いので優先 半自動化(AIが候補提示→人が承認)
材料品質不良 月3〜5回 仕入先に確認し待機 独自の品質基準がある 人が対応(品質判断はルール化困難)

この表を埋めていく作業自体が、組織の「暗黙ルール」を初めて文書化する機会になる。担当者が「そんなルールがあったのか」と自覚する瞬間が必ず訪れる。

ルール化の失敗パターン:「例外だらけ」になったとき

ルール化を進めると「全部例外」になってしまう業務がある。これは可視化の失敗ではなく、業務自体が「判断ではなく経験値」に依存しているサインだ。

こうした業務は、AIへの移管ではなく「類似事例の検索支援」として設計し直す。過去事例をデータベース化し、類似ケースをAIが提示→人が選択する「AIアシスト型」に切り替える。

フェーズ4:AI実装設計——どのAIで、何をどこまで自動化するか

ここまでの3フェーズを経て、ようやく「どのAIを使うか」の議論に入る。多くの現場でいきなりツール選定から始まるが、それが失敗の最大原因だ。

AI実装の三類型

  1. ルールエンジン型(最もシンプル) 決定木がそのままIF-THENルールに変換できる場合。業務システムへの組み込みが現実的。初期コストが低く、動作が透明。製造現場では最初の一歩として最適。

  2. 機械学習モデル型(ある程度のデータが必要) 過去の判断データが数百件規模で蓄積されており、パターンが抽出できる場合。需要予測・品質予測・異常検知などで実績が多い。ブラックボックスになりやすいため、説明可能AI(Explainable AI)の実装を推奨。

  3. 生成AI(LLM)アシスト型(曖昧判断の補助に) 例外処理や顧客対応など、文脈依存の判断が多い業務に向く。過去事例・マニュアル・メール履歴などをRAG(社内文書をAIに参照させる仕組み)で参照し、「この状況ではこう対応した事例があります」と提示する形。最終判断は人が行う。

トヨタは「工場作業者が自分でAIモデルを作れる環境」を構築したが、これは中小製造業がいきなり目指すべき姿ではない。まずルールエンジン型で1〜2業務を成功させ、組織の「AI移管慣れ」を作ることが先決だ。

実装後の最大の罠:「誰も使わない」

AI移管に成功したはずなのに、気づいたらまた「Aさんに確認」に戻っている——これが最も多い失敗だ。

原因は決まって「ツールの使いやすさ」ではなく「AIの提案を信じない心理」にある。対策は二つだ。

一つ目は**「AIの判断根拠の可視化」**。「なぜこの順序を提案するか」を画面に表示する。ブラックボックスでは人は信頼しない。

二つ目は**「移行期の二重運用」**。3ヶ月間は人の判断とAIの提案を並走させ、差分を記録する。AIが外れた事例を週次でレビューし、ルールを更新し続ける体制を作る。この体制がないと、実装しても定着せずに使われなくなるケースが多い。

AI移管の4フェーズ全体像——「可視化なきAI実装」は失敗する

AI移管の4フェーズ全体像——「可視化なきAI実装」は失敗する

トヨタ事例から中小製造業へ——「材料は何か」を問う

冒頭で触れた、従業員が自分でAIモデルを作るプラットフォームに加え、トヨタは「O-Beya(大部屋)」と呼ばれる取り組みも進めている。約800名のパワートレイン技術者向けに、設計報告書・規制データ・ベテラン技術者の手書き文書を基盤としたAIエージェント群を提供し、シニア技術者の退職に伴う知識喪失を防ぐことを目的としたものだ。

規模は中小製造業に直接あてはまらない。しかし注目すべきは「何を材料に暗黙知をデータ化したか」だ。設計報告書・規制データ・手書き文書——特別なセンサーやIoT基盤ではなく、現場にすでに存在する紙とデータを集めている。

これは、本記事の4フェーズに置き換えて読むこともできる(筆者による解釈)。可視化(手書き文書を集める)→構造化(設計報告書と規制データを結びつける)→ルール化(技術者の判断パターンを抽出)→AI実装(エージェント群として提供)——順序を守れば、材料は工場にすでにある。

規模も業種も違うが、貫いているのは「AIを入れてから考える」ではなく、**「まず人間の判断構造を解析してからAIを設計する」**という順序だ。この順序は、従業員10人の工場でも変わらない。

まとめ:最初の一手は「ワークシート1枚」から

AI移管設計の全工程を示してきたが、今日から取り組める最初のステップは一つだ。

フェーズ1の「判断記録シート」を、一人の担当者と一つの業務について1週間かけて埋める。

この一枚が、それまで「標準化できない」と思われていた業務の輪郭をはっきりさせる。「あ、これは言語化できる」「でもこれは難しい」という感覚が、現場から自然に出てくる。

そこから先が設計の出発点だ。「標準化できない」のではなく「まだ可視化していなかった」——この認識の転換が、製造現場のAI移管を現実のものにする。

中小製造業でも、フェーズ1〜2は外部ツールや費用なしに着手できる。まずはベテランとのワークショップを一度設定するところから始めてほしい。

CONTACT

「これ、AIでできない?」

業務の流れに落とし込みます。

相談内容をもとに、
AIで支援できそうな工程と、
人が確認すべきポイントを整理します。

まずは、分かる範囲で構いません。

まずは、できそうな業務を教えてください

送信後、業務フロー・AI支援箇所・確認ポイントを整理してお返しします

※ 箇条書き・未整理のメモでも構いません

送信後にお返しする内容

業務フロー整理 AI支援できる工程 人が確認すべき点 初期導入の進め方
送信しました。 お問い合わせありがとうございます。

参考・出典