これまでの記事で、匠ナレッジコア（KATANA×TAKUMI）が「何であるか」「何ができるようになるか」を説明してきました。今回は、その一歩先「では、実際にどうやって作るのか？」にお答えします。題材にするのは、いま当研究所がQA（品質保証）を重視する大手電機メーカー向けに提案している、Gemini方式（Google Cloud）によるナレッジコア構築手順です。「考え方は分かった。で、どのツールで、どう組み立てるの？」という疑問に、具体的な設計図でお答えします。匠ナレッジコアそのものの基礎は 「匠ナレッジコアとは？ KATANAとTAKUMIを合わせると何が起きるのか」 をご覧ください。本記事は、その「作り方」の解説です。

1. なぜ「Gemini方式（Google Cloud）」なのか

匠ナレッジコアは、特定のAIに縛られる仕組みではありません。お客様が使っている基盤に合わせて構築します。今回のお客様はGoogle Cloudを全社基盤としているため、Gemini方式を選びました。この方式には、QA重視の大企業にとって次の利点があります。

とりわけ大きいのが、Deep Researchによる外部知見の取り込みと、機密データをテナント内で閉じて扱える点です。品質保証部門は外に出せないデータを大量に抱えています。その扱いに正面から答えられることが、この方式を選ぶ決め手になります。

2. 全体像 ── 2つのグループを、1つのAIに束ねる

構築は、性質の異なる2つの知識を、別々のチーム（グループ）で作り、最後に統合する形で進めます。

3. 出力は、いつも同じ「判断カード」でそろえる

匠グループと刀グループは、扱う知識はちがっても、出力の形は同じにそろえます。これが濱田式の要です。すべての知恵を、次の4点セット【判断カード】で残します。

条件 → 判断 → 理由 → 例外

どんな条件で／何を判断し／なぜそうするのか／どんな例外があるか。形がそろっているから、ベテランの暗黙知も過去トラの分析結果も、同じDBに混ぜても矛盾なく引ける。新人でも読めて、AIも答えやすい。この「様式の統一」があるからこそ、2つのグループを1つのAIに束ねられるのです。

4. 構築手順 、6つのステップ

STEP1　現状診断（砂鉄と玉鋼の在りかを探す）

「使われず眠っている過去データ（砂鉄）はどこにあるか」「継ぐべき暗黙知（玉鋼）は誰の頭にあるか」を洗い出します。ここで最初の対象範囲（テーマ）を1つに絞ります。

STEP2　グループ分け（匠と刀に振り分ける）

洗い出した対象を、暗黙知は匠グループ（TAKUMI）へ、記録済みの過去データは刀グループ（KATANA）へ振り分けます。

STEP3　匠グループを作る（暗黙知を判断カードに）

Geminiを逆質問インタビュアーに仕立て、ベテランに「なぜその判断をしたのか」「もし違う選択なら？」と問い続けます。出てきた言葉を「条件→判断→理由→例外」に整理し、本人に確認してもらってから判断カード化。これをDBに入れます。

STEP4　刀グループを作る（過去データを純化する）

過去のクレーム・不具合データから、KATANAで「作業者の不注意」「教育不足」といった精神論を叩き出し、物理的な真因まで掘り下げます。さらにDeep Researchで外部の最新対策を融合し、これも判断カードにしてDBへ。「処置済み」の1行が、なぜ起きたか・どう防ぐかの資産に変わります。

STEP5　統合（1つの不具合調査アシストAIに束ねる）

匠グループと刀グループの判断カードを同じナレッジDB（NotebookLM／RAG）に集約します。これで「暗黙知」と「過去データ」の両方から、根拠付きで答えるAIが立ち上がります。

STEP6　研ぎ続ける（更新のルールを決める）

DBは作って終わりではありません。再発・外部知見の更新・前提の消滅などで知恵は古くなります。「いつ・誰が・どう見直すか」の運用ルールを決めて初めて、使うほど賢くなる状態が続きます。

5. 導入は「2つのパターン」から選ぶ

同じGemini方式でも、扱うデータの機密性によって環境の作り方が変わります。ここが提案時にいちばん丁寧に設計する部分です。

実務上のおすすめは、「暗黙知から軽量PoCで手応えをつかみ、機密性の高い刀グループは早めにインテナントへ」という組み合わせです。小さく始めて効果を確かめつつ、外に出せないデータは最初からお客様の環境で閉じて扱う——この二段構えが、現実的でリスクの低い進め方になります。

6. この方式の「守り」、 データは、外に出ない

QAを重視する企業ほど気になるのが、データの取り扱いです。Gemini方式のインテナント構成では、次を設計上の前提にします。

• ✓ 機密データはお客様のテナント内で完結し、外部に出さない
• ✓ 入力内容をAIの学習に使わせない
• ✓ 会話の履歴を残さない／セッションを分離する設定
• ✓ APIキーなどの鍵はお客様が保有・管理する

まとめ 、「道具」ではなく「作り方」を提供する

Gemini方式の要点は、次の一文に集約されます。

Geminiで暗黙知を引き出し（匠）、過去データを純化し（刀）、同じ判断カードの形でNotebookLMに束ねて、一つの「不具合調査アシストAI」にする。機密データは、お客様の環境から一歩も出さずに。

大切なのは、これが特定のツール頼みの話ではないことです。KATANA・TAKUMI・判断カード・自律進化ループという「作り方」の骨格は変わりません。お客様がGoogle Cloudなら本記事のGemini方式、Microsoft基盤ならCopilot方式、と基盤に合わせて実装だけを載せ替える——それが濱田式AI品質スタンダードの設計思想です。

 最後に

• 品質管理を、属人技から組織標準へ。
• 経験依存から知能協働へ。
• 熟練の暗黙知を、全員が使える武器に。

それが、高崎ものづくり技術研究所の使命です。 濱田（高崎ものづくり技術研究所　代表）

◆関連解説記事・・・熟練の暗黙知を全員が使える武器に～濱田式AI品質スタンダード実務編～