2024年後半、日本のある商用車グループのエンジニアリング部門は、根本的な問いを立てました——AIの能力はどこで終わり、人間である整備士の権限はどこから始まるのか。意図的に「境界」を定めるという彼らのアプローチこそが、Technician Co-Pilotが1年を超える本番運用を成功させた理由でした——他社の同種システムが概念実証(PoC)の段階で苦戦するなかで。本稿では、その境界設計を、CXOの視点で解説します。
課題：仕事の速度に、知識が間に合わない
大型商用車の整備は、繰り返し同じ課題に直面します——整備士は、数百のトラブルコード、複数システムに散在する断片的なサービス履歴、蓄積されたエンジニアリング速報、そして顧客の納期期待を、すべて素早く統合しなければなりません。参照資料も専門知識も「存在する」のに、必要な瞬間にアクセスできない。これが、診断速度・初回修理完了率(first-time-fix)・ベテランと新人の間の知識移転に、ばらつきを生みます。
設計の問い：機械に移せない責任とは
リーダーシップは「AIに何ができるか?」から始めませんでした。代わりにこう問いました——「整備士の仕事とは正確に何か。そして、機械に移せない責任とは何か?」。彼らの結論が特定したのは、具体的で運用上「説明責任を伴う仕事」——診断し、決定し、承認し、車両を解放(リリース)し、署名する——でした。これらの行為は、規制上の意味、安全への含意、顧客の信頼を担います。その周辺にあるすべて——取得、比較、統合、類似事例の検索——は、価値は高いが「説明責任を伴わない仕事」であり、権限を与えることなく整備士の時間を消費します。
境界の決定：AIは取得し、整備士が決める
明示された境界は——「AIは取得する(retrieve)。整備士が決める(decide)。」。AIがすること:Technician Co-Pilotは、整備士の問い合わせに会話の速度で応じ、関連するサービス手順・過去事例・エンジニアリング速報・診断情報を取得します。AIがしないこと:診断の決定、修理の承認、車両の解放、サービス記録への署名、顧客向けの修理許可の生成。これらの除外は、見落としではなく意図的な設計の選択でした。
実践での動き方
車両が入庫し、参照資料を要する診断状況になると、整備士は手元の文脈を使い、自然言語でCo-Pilotに問い合わせます。システムは、関連するサービス手順、解決済みの過去事例、エンジニアリング速報、車両固有のディーラーノートを、数秒以内に走査しやすい形式で返します。整備士は読み、決定し、行動する。診断・修理許可・署名は、彼らの責任のまま。Co-Pilotは「診断の代替」ではなく、「加速された情報アクセス」として機能します。
採用の成果：境界が信頼を築いた
本番運用から1年後、2つの測定可能な成果が現れました。診断までの時間が明確に改善し、参照資料の取得が以前は困難だった診断カテゴリで初回修理完了率が向上しました。さらに重要なことに、整備士の採用率は、AIが「代替」「エキスパートシステム」「決定権を持つパートナー」として位置づけられた他社のAI展開よりも、有意に高かったのです。当初は懐疑的だった何人かのベテラン整備士が、強力な利用者になりました——システムが「自分の領分にとどまり(stayed in its lane)」、彼らの専門的判断を脅かすのではなく高めたからです。
他の現場AIへの示唆
この原則は、整備の現場を超えて広がります。長期的に成功する現場AIの展開は、一つの設計上の特徴を共有します——「AIの仕事」と「説明責任を伴う人間の仕事」の境界が、技術が作られる“前”に決められていたこと。この順序——境界が先、技術が後——が、品質・安全・説明責任をめぐる基盤的な規律を保ちながら、運用システムにAIを統合することを可能にします。2つ目の問いに正確に答えるチームこそが、長く存続するデプロイを生むのです。境界を先に定める設計を、御社の現場AIに据えるために、Cubastionのビジネスソリューションにご相談ください。
