近年、実務の現場で特に課題として挙がりやすいのが、「マルチモーダルAI（画像認識AI）」の本格運用です。
「ChatGPTやGeminiを導入して、お客様から送られてくる故障画像の診断を自動化したい」と考えるDX担当者は多いですが、PoC（概念実証）の段階で壁にぶつかるケースが後を絶ちません。
「AIが自信満々に誤った情報を生成する（ハルシネーション）」。
「経験豊富なオペレーターならすぐに分かる傷を見落とす」。
「回答のトーンが毎回異なり、そのまま顧客に送信できない」。
これらの課題は、AIの性能不足だけが原因ではありません。AIへの「指示の出し方（プロンプト）」が、チャットボットのような対話型AIに対するものからアップデートされていないことも大きな要因です。
業務レベルの画像診断システムを構築するには、AIを単なる「話し相手」ではなく、厳密な「ロジック処理エンジン」として扱う必要があります。入力された画像をどのように分析し、どのマニュアルと照合し、どのような形式で結果を出力するか。このプロセスを緻密に設計し、まずはプロトタイプとして動かしてみなければ、現場で実際に使えるツールにはなりません。
今回は、企業のCS（カスタマーサポート）部門や保守現場での実装を想定し、開発者だけでなく、現場のオペレーション担当者がアジャイルに活用・検証できる「故障診断プロンプトテンプレート」を紹介します。皆さんの現場でも、ぜひ実際に動かして試してみてください。
本テンプレート集の活用とゴール設定
プロンプトを紹介する前に、AIによる画像診断を業務フローにどう組み込むべきか、その「設計思想」を共有しましょう。このアーキテクチャの視点が欠けていると、どれほど優れたプロンプトもシステムとして機能しません。
故障診断におけるマルチモーダルAIの役割定義
まず大前提として認識すべきは、現在のAI技術においては「AIに最終診断（確定）をさせてはいけない」という点です。
特に製造物責任（PL）法や安全規定が関わるハードウェアの故障診断において、AIの誤診は経営的な重大リスクに直結します。目指すべきゴールは、AIに「正解」を出させることではなく、「可能性の高い仮説」と「判断材料」を人間に提示させることです。
これを「AIトリアージ（選別）」モデルと呼びます。
- AIの役割: 画像から客観的事実を抽出し、マニュアルに基づいた可能性を提示し、一次回答案を作成する。
- 人間の役割: AIの提示した仮説を検証し、最終的な判断を下して送信する。
この役割分担を明確にすることで、現場導入の心理的なハードルが下がり、実質的な工数削減とスピーディーな運用開始を両立できます。
「ハルシネーション（幻覚）」を防ぐ前提知識
画像診断で最も警戒すべきはハルシネーションです。例えば、画像には写っていない「焦げ跡」をAIが誤って認識し、「火災のリスクがあります」と回答してしまうケースが考えられます。
これを防ぐためのプロンプト設計の鉄則は以下の通りです。
「観察（Observation）」と「推論（Reasoning）」を分けること。
最初から「この製品のどこが壊れていますか？」と質問するのではなく、まずは「画像に何が写っているか、客観的な事実だけを述べてください」と指示します（観察）。その後に「その事実に基づくと、どのような故障が考えられますか」と質問します（推論）。この2段階のステップを踏むことで、ハルシネーションのリスクを劇的に抑え込むことができます。
テンプレートのカスタマイズ方針
本記事で紹介するプロンプトは、以下のプレースホルダーを使用しています。
{{image_input}}: 顧客から送られてきた画像データ。{{product_manual}}: 自社製品のマニュアルやFAQテキスト。{{history}}: 過去の問い合わせ履歴（もしあれば）。
これらを自社の環境に合わせて組み込み、まずは手元で動かしてみてください。それでは、具体的なテンプレートを見ていきましょう。
【基本編】画像から「事実」だけを抽出する観察プロンプト
トラブルシューティングの最初のステップは「現状把握」です。ここでは、AIに一切の推測をさせず、客観的な情報に基づいた検証を行わせるプロンプトを構築します。
主観を排した状態記述の生成
このプロンプトの目的は、画像データをテキストデータ（構造化データ）に変換することです。これが後続の推論プロンプトの確固たる入力基盤となります。
▼ 観察用プロンプトテンプレート
# Role
あなたは熟練した製造業の品質管理検査員です。感情や予断を持たず、視覚情報のみに基づいて客観的な事実を報告することが任務です。
# Input Data
画像: {{image_input}}
# Instruction
提供された画像を詳細に分析し、以下の項目についてJSON形式で出力してください。
推測や「〜だと思われる」といった曖昧な表現は禁止します。画像から明確に確認できない場合は「不明」または「確認不可」と記述してください。
# Output Format (JSON)
{
"product_condition": {
"overall_appearance": "製品全体の概観（例：全体像が写っている、一部のみ拡大されている等）",
"visible_damage": ["確認できる物理的損傷のリスト（例：ひび割れ、変色、部品の欠損）"],
"foreign_objects": "異物の有無（例：水滴、埃、不明な付着物）",
"indicators": "LEDランプやディスプレイの表示内容（点灯色、点滅パターン、エラーコード文字列）"
},
"image_quality": {
"clarity": "画像の鮮明度（高/中/低）",
"issues": "診断を妨げる要因（例：手ブレ、照明不足、反射、対象が見切れている）"
}
}
💡 Point
このプロンプトの重要な点は、image_quality（画像の品質）を評価させている点です。もしここで「低」や「診断を妨げる要因あり」と判定された場合、診断を無理に進めず、顧客に「ピントを合わせて再撮影してください」と自動で返信するフローに即座に移行できます。これにより、誤診の根本原因となる「低品質な画像」を入り口でシャットアウトできるわけです。
製品型番・シリアルナンバーの読み取り
OCR（光学文字認識）機能を活用し、製品特定を自動化します。顧客が使用している製品の型番を正確に把握していない場合が多いため、画像からの特定はCS業務の効率化において非常に有効なアプローチとなります。
▼ 型番特定プロンプト（追加指示）
# Additional Instruction
画像内に文字情報（ラベル、刻印、ディスプレイ表示）が含まれる場合、それを正確に転記してください。
特に以下のパターンに一致する文字列を探し、抽出してください。
- 型番パターン: [A-Z]{2,3}-[0-9]{4} (例: SR-2024)
- シリアルNoパターン: SN[0-9]{8}
見つかった場合は `product_id` フィールドに出力し、確信度（confidence_score）を0.0-1.0で添えてください。
破損・汚損レベルの数値化
「非常に汚れている」という定性的な情報は、システム上でロジックとして扱いにくい場合があります。これを5段階などの数値に変換することで、優先順位付け（トリアージ）の自動化が可能になります。
例えば、「損傷レベル4以上であれば即時交換対応のフローを回す」といったビジネスルールをシステムに組み込むことができます。
【応用編】症状から原因を推定する推論プロンプト
事実情報が抽出できたら、次は「なぜ故障したのか」を推論させます。ここではRAG（Retrieval-Augmented Generation：検索拡張生成）のアプローチを取り入れ、自社のナレッジベースを参照させながら、論理的に原因を絞り込ませる手法を解説します。
近年のAI技術の進化により、テキスト情報だけでなく、マニュアル内の図版、回路図、UI画面などを統合的に理解・検索するマルチモーダルRAGが実用化されています。また、知識間の関連性をグラフ構造で捉えるGraphRAGについても、クラウドAIサービスでのサポートが進むなど、複雑な推論に向けた検証が活発です。これらを活用すれば、単なるキーワードマッチングを超えた、文脈に即した精度の高い診断基盤を構築できます。
「観察事実」×「ナレッジ」による原因仮説の立案
ここではChain-of-Thought（思考の連鎖：CoT）プロンプティングを用います。最新のLLMではCoTが標準的な推論手法として進化を遂げており、問題の複雑さに応じて推論の深さを自動的に判断し、リソースを最適に配分する機能が搭載されるようになっています。
さらに、ClaudeなどのAIモデルを活用する現場では、単純なプロンプト入力から、より高度なエージェント的ワークフローへの移行が進んでいます。具体的には、プロジェクト機能を用いたカスタム指示（役割や出力形式の固定化）や、タスクを分割して計画から実行までを管理するアプローチです。特定の条件下で発火する「Skills」のような概念を取り入れ、診断フローを自動化する試みも注目を集めています。ただし、これらの高度な機能や推奨されるプロンプト設計は頻繁にアップデートされるため、実装の際は常に公式ドキュメントで最新情報を確認し、まずはプロトタイプで検証することが重要です。
いきなり「答え」を出させるのではなく、段階的な「思考プロセス」を明示的に出力させる基本構造は引き続き有効であり、論理の飛躍や事実に基づかない回答（ハルシネーション）を強力に防ぎます。
▼ 推論用プロンプトテンプレート
# Role
あなたはハードウェア製品のテクニカルサポートエンジニアです。
# Context
先ほどの「観察フェーズ」で得られた以下の事実情報と、検索システムから提供される「製品マニュアル・技術ドキュメント」に基づき、故障原因を推論してください。
[観察された事実]
{{observation_result_json}}
[製品マニュアル・FAQ抜粋（関連性の高いコンテキスト）]
{{product_manual_context}}
# Instruction
以下のステップで思考を展開し、原因を特定してください。問題の複雑さに応じて、可能な限り深く多角的な検証を行ってください。
Step 1: 観察された事実（損傷箇所、エラーコード、LEDの状態等）に関連するマニュアルの記述や図解を特定する。
Step 2: 事実とマニュアルの記述を照らし合わせ、矛盾がないか、あるいは仕様通りの挙動かを確認する。
Step 3: 可能性のある原因をすべて列挙し、それぞれの「確からしさ」を論理的に評価する（マルチモーダル情報がある場合は図表との整合性も考慮すること）。
Step 4: 最も可能性が高い原因トップ3を選定し、その根拠と解決策を提示する。
# Output Format
## 推論プロセス
(Step 1~3の思考過程を記述。段階的な深掘りを明示すること)
## 診断結果
1. 原因仮説A (確度: 高)
- 根拠: ...
- 推奨アクション: ...
2. 原因仮説B (確度: 中)
- ...
💡 Point
最新のRAG実装では、検索精度を高めるために「ハイブリッド検索（キーワード検索とベクトル検索の併用）」や「リランキング（検索結果の再順位付け）」を取り入れるアプローチが一般的です。また、マニュアルに記載がない未知の現象については、無理に原因を特定させず「既知の不具合には該当しません。専門家による詳細調査が必要です」と回答させ、人間のエンジニアへエスカレーションするフローを設計に組み込むことが、システムの信頼性担保に直結します。
追加確認すべき事項をリストアップする
画像や初期のテキスト情報だけでは判断できない場合が多いため、「何を確認すれば判断できるか」をAIに提案させます。これは「Active Retrieval（能動的検索）」の考え方に近く、不足情報を埋めるための対話を自動生成する仕組みです。
- 「電源を入れた直後に異音は発生しますか？」
- 「この状態がどのくらい続いていますか？」
- （マルチモーダル対応の場合）「製品背面のラベル部分の画像を追加で撮影してください。」
これらのヒアリング項目を自動生成させることで、オペレーターは顧客に対してスムーズに質問でき、診断に必要な情報を効率的に収集できます。特に、推論の過程で複数の仮説が残った場合、それらを絞り込むための決定的な質問（切り分けの質問）をAIに提示させることで、解決までのリードタイムを大幅に短縮する効果が期待できます。エージェント的な振る舞いを持たせることで、単なる回答マシーンではなく、問題解決のパートナーとしてAIを機能させることが可能になります。
【実務編】ステークホルダー別アウトプット生成プロンプト
診断結果が出ても、そのまま関係者に共有するのではなく、相手（ペルソナ）に合わせて情報を加工することが重要です。技術の価値は、それがビジネスの現場でどう使われるかで決まります。
顧客向け：専門用語を分かりやすくした一次回答メールの作成
顧客は不安を感じているため、事務的な診断結果だけでなく、「共感」と「明確な次のステップ」を伝える必要があります。
▼ CSメール生成プロンプト
# Instruction
診断結果に基づき、顧客への一次返信メールを作成してください。
# Tone & Manner
- 丁寧で共感的なトーン（「ご不便をおかけし申し訳ございません」等のクッション言葉を適切に使用）
- 専門用語は使用せず、分かりやすい言葉に言い換える
- 「故障です」と断定せず、「〜の可能性があります」と表現する
# Structure
1. 謝罪と画像の受領確認
2. 画像から確認できた状況の共有（「お送りいただいた画像を拝見したところ、〇〇の部分に...」）
3. 提案する解決策または試してほしい操作（箇条書きで分かりやすく）
4. それでも解決しない場合の案内
現場作業員向け：必要な工具と交換部品リストの提示
修理を行う担当者には、具体的かつ実践的な情報が必要です。「現場に何を持っていくべきか」という情報を的確に提供します。
▼ サービスマン向け指示書生成プロンプト
# Instruction
診断結果に基づき、修理担当者が持参すべき「交換部品リスト」と「必要工具」を出力してください。
過去の修理履歴データ（{{repair_history}}）を参照し、類似事例で交換頻度の高かった部品を推奨してください。
# Output Style
- 箇条書き
- 部品コードを併記
- 予想作業時間を算出
精度を安定させるための「Few-Shot」活用法
紹介したテンプレートを使用しても、自社特有の製品（例えば、特殊な産業機械や独自規格の端子など）の場合、一般的なAIモデルでは認識精度が向上しないことがあります。
そこで威力を発揮するのが「Few-Shot（フューショット）プロンプティング」です。
これは、プロンプトの中に「正解の例（事例）」をいくつか含める手法です。AIに対して「この画像の場合はこう答えるのが適切である」と具体的な事例を示すことで、モデルの挙動を実務レベルにチューニングできます。
自社の「正解診断例」をプロンプトに含める方法
例えば、特定の部品の「錆び」を検知させたい場合、言葉で「茶色い変色」と説明するよりも、実際の錆びた画像の診断例をプロンプトに含める方が圧倒的に効果的です。
▼ Few-Shotの実装例
# Examples (Few-Shot)
例1:
[状況] 電源ケーブルの被膜が破れ、内部の銅線が見えている画像
[出力]
{
"status": "DANGER",
"reason": "ケーブル被膜損傷による感電リスクあり",
"action": "使用中止および即時交換"
}
例2:
[状況] 表面に微細な擦り傷があるが、機能に影響しない画像
[出力]
{
"status": "SAFE",
"reason": "外装の軽微なコスメティックダメージ",
"action": "経過観察（機能影響なし）"
}
このように、「危険な状態（NG）」と「許容範囲（OK）」の境界線となる事例をセットで教え込むことがポイントです。これを3〜5例ほどプロンプトの冒頭に追加するだけで、AIの判断基準を劇的に安定させることができます。
フィードバックループの構築
現場で運用を始めると、必ず「AIが誤った事例」が発生します。しかし、これは失敗ではなく改善のチャンスです。これらの事例を蓄積し、次のFew-Shotの素材として活用します。
- AIが誤診した画像を特定する。
- 人間が正しい診断内容を作成する。
- それをプロンプトの「Examples」に追加する。
このアジャイルなサイクルを高速で回すことで、AIを現場の即戦力として育成することができます。エンジニアが複雑なコードを修正するのではなく、プロンプトを更新することで、システムを継続的に進化させられるのです。
まとめ：プロンプトは「書く」ものではなく「育てる」もの
今回紹介したプロンプトテンプレートは、あくまで出発点に過ぎません。重要なのは、まずはプロトタイプとして実際の現場で動かし、結果を分析してアジャイルに調整を繰り返すことです。
- 観察と推論を分ける: ハルシネーションを防ぐ強固な基本構造。
- ステークホルダー別に出力を変える: CS、現場、管理者、それぞれのビジネスニーズに対応。
- Few-Shotで基準を教える: 自社の「良品・不良品」の基準を具体的な事例で示す。
これらを実践することで、AIは単なる「画像認識ツール」から、ビジネスを加速させる頼れるエージェントへと成長します。皆さんの現場でも、ぜひ今日から試してみてください。
コメント