製造業RAGを意思決定者に説明する——導入ロードマップと1枚資料の設計

製造業RAGを意思決定者に説明する——導入ロードマップと1枚資料の設計

はじめに

製造業向けRAGシリーズの第7弾です。

第5弾（3プロバイダー比較編）の末尾で予告した「ビジネス設計編」です。

第1〜6弾では技術実装を積み上げてきました。ACL-aware retrieval・Prompt Injection防御・監査ログ・再インデックス・3プロバイダー比較・本番運用設計（Evals / Observability / Prompt Versioning / Fallback）。

しかし「動く実装がある」と「意思決定者に導入を承認してもらえる」は別の話です。

今回は同じテーマを意思決定者向けに再構成します。Why now / Why safe / Why measurable の3軸で整理し、PoC → 部分導入 → 全社展開の導入ロードマップと、役員説明に使える1枚資料の骨子を示します。

対象読者: 第1〜6弾を読んだエンジニア・アーキテクト。技術実装は完了しており、経営層・事業部長への提案に進もうとしている方。

シリーズ構成:

• 第1弾（設計編）: https://zenn.dev/kukyotolab/articles/ed209091142b2a
• 第2弾（実装編）: https://zenn.dev/kukyotolab/articles/f52e4daf35fab2
• 第3弾（運用編）: https://zenn.dev/kukyotolab/articles/46e651877241a4
• 第4弾（防御比較編）: https://zenn.dev/kukyotolab/articles/bdc38a5cfb27cb
• 第5弾（3プロバイダー比較編）: https://zenn.dev/kukyotolab/articles/three-provider-rag-comparison
• 第6弾（本番運用設計編）: https://zenn.dev/kukyotolab/articles/llm_production_ops
• 第7弾（本記事・ビジネス設計編）

1. 意思決定者が聞く3つの問い

技術チームがPoC成功を報告したとき、役員・事業部長が聞くのはたいてい次の3つです。

• 「なぜ今やらなければならないのか」（Why now）
• 「安全といえる根拠は何か」（Why safe）
• 「うまくいっているかをどう確認するのか」（Why measurable）

この3つに答えられない提案は、承認されません。以下では各問いへの回答を整理します。

2. Why now — なぜ今か

製造業のRAG導入を「今」議論すべき理由は、外圧と内圧の2つが同時に顕在化しているからです。

外圧: 競合他社のAI導入加速

製造業のAI活用は業界全体で加速しています。「様子を見る」ことのコストが以前より大きくなっています。

内圧①: 技術継承危機

熟練工の退職・技術継承問題は多くの製造業で喫緊の課題です。ベテランは「第3章の図2を見れば分かる」と知っていますが、新人はページめくりから始めます。この暗黙知依存の情報探索行動は、現時点でどのシステムにも記録されておらず、不可視のままです。

内圧②: SOP散在問題

設備マニュアル・品質基準・作業手順書がSharePoint・PDF・イントラ・キャビネットに散在している状況は珍しくありません。「あれどこでしたっけ？」→「〇〇さんに聞こう」という情報探索コストは誰にも見えていません。

RAGはこの2つを直接解決します。暗黙知を検索可能にし、正しい文書を秒単位で返す。問題は「やるかどうか」ではなく「安全にやれるかどうか」です。

3. Why safe — 安全といえる根拠

標準的なRAG実装にはアクセス制御の概念がありません。セマンティック検索はクエリに最も近い文書を返しますが、「そのユーザーが見ていい文書か」を判断しません。

製造業では許容できない状況です。一般社員が設計図面を、ラインAの保守員がラインBの制限手順を、チャットボット経由で取得できてしまいます。

本シリーズの実装は4層の防御でこれに対処しています。

重要な設計原則: セキュリティはLLMの手前（アプリケーション層）に置いています。第6弾のPrompt Versioning実験で確認した通り、システムプロンプトを変更してもsafetyスコアは変化しませんでした。セキュリティ制御がプロンプトの文言に依存していないことを数値で示せます。

4. Why measurable — うまくいっているかの確認方法

この問いへの回答が準備できていない場合、提案の検討が長期化することがあります。

正直に言うと、導入前のbaselineは取りにくい。「現在、保守員が手順書を探すのに何分かかっているか」を正確に測定しているシステムは存在しません。アンケートで体感時間を記録することはできますが、精度に限界があります。

この制約を正直に認めた上で、以下の方針を採ります。

• 導入前: アンケートで体感時間を記録（baseline代替・参考値）
• 導入後: 監査ログとevalスクリプトの実測値のみを正式指標とする

導入後に自動で測定できる指標は次の通りです。

核心のメッセージは「今まで誰も測れなかった情報探索コストを、初めて可視化できるようになる」です。測定インフラがシステムに内蔵されているため、90日後の役員レポートは手作業ではなくデータへのクエリになります。

5. 導入ロードマップ: PoC → 部分導入 → 全社展開

30日: PoC（検証フェーズ）

ゴール: 1設備カテゴリ・1部門・1拠点を対象に、実務担当者が実際の業務で使えるかを検証する。

• 対象文書: 1設備カテゴリのSOP全量
• ユーザー: その部門の実務担当者3〜5名
• 導入前アンケートで体感時間を記録（baseline代替）
• Go/No-Go判断基準: evalスコアの閾値達成 + 現場担当者の「使える」という定性評価の両方

60日: 部分導入（展開フェーズ）

ゴール: PoCの知見をもとにACL・監査ログを本番環境に適用し、複数部門・複数ユーザーに展開する。

• 30日PoC結果を役員に報告・投資継続判断
• ACL設定を本番環境に適用
• 監査ログ運用開始・フィードバック収集
• 対象部門を段階的に拡大

90日: 全社展開準備（定着フェーズ）

ゴール: evalの定期実行・SLA/SLO稼働。情報探索コストの可視化データを役員レポートとして提示。

• evalスクリプトの定期実行スケジュール確立
• SLA/SLO設定（回答精度・レスポンスタイム）
• 90日間の監査ログデータを役員レポートとして初提示——「今まで見えなかったもの」が初めて見える瞬間

6. 役員説明1枚資料の骨子

意思決定者への説明は、上記の構造を1枚に集約します。

【Secure Manufacturing RAG Adoption Pack — 意思決定者向けサマリー】

■ Why now（なぜ今か）
  - 技術継承危機: 熟練工退職で暗黙知が失われつつある
  - SOP散在: 情報探索コストが不可視のまま蓄積している
  - 競合: 業界全体でAI活用が加速している

■ Why safe（安全の根拠）
  - ACL + Fail Closed: 権限外文書には到達しない設計
  - 監査ログ: 誰がいつ何を検索したかの証跡（ISO 27001対応）
  - Prompt Injection防御: 3層設計・実測で検知率確認済み
  - セキュリティ制御はLLMの手前に置く——プロンプト依存しない

■ Why measurable（確認方法）
  - 採用率・回答精度・インシデント数: 導入初日から自動計測
  - 90日後レポート: 監査ログへのクエリで自動生成
  - baseline問題: 導入前はアンケート参考値、正式指標は実測値のみ

■ 導入ロードマップ
  - 30日: PoC（1設備カテゴリ・1部門・3〜5名）
  - 60日: ACL + 監査ログ本番適用・複数部門展開
  - 90日: SLA/SLO稼働・役員レポート初回提示

この骨子は、稟議書・役員プレゼン・RFP回答のいずれにも展開できます。

まとめ

本シリーズ全7弾の構造を振り返ります。

技術的な実装は第1〜6弾に委ねています。第7弾はそれらの「なぜ」を意思決定者の言語で整理する試みです。

技術的な実現可能性の検証が済んでいる段階では、「安全にやれることを示せるか」「効果をどう測るかが決まっているか」が、次のステップに進むための実務上の論点になることが多いです。本記事はその2点を整理するための素材として活用してください。