連載「Aina’Ola について」第 4 回: クローンが何を見て答えているか ── ナレッジ参照と、普通の RAG との違い

連載「Aina’Ola について」第 4 回です。前回 (第 3 回) では、クローン人格の作り方 ── Identity・Skills・Resources の 3 階層を、どう構築していくかをご紹介しました。

今回は、その先に出てくる素朴な疑問にお答えします ── 「クローンと話したとき、AI は実際に何を見て答えているのか?」

Aina’Ola のクローンと話していると、思っていた以上に的を射た答えが返ってくる場面と、逆に「なぜそう答えた?」と感じる場面の両方があります。この差を理解するには、クローンが回答するときに裏で何が動いているかを知ることが近道です。今回は、Aina’Ola 独自のナレッジ参照ルールと、いわゆる「普通の RAG」との違いを掘り下げます。

そもそも RAG とは何か

「RAG (Retrieval-Augmented Generation)」は、いま AI を業務に取り入れるときの代表的な手法です。仕組みをざっくり言うと:

1. 会社の文書 (PDF・マニュアル・議事録など) を AI が読み込み、保管しておく
2. 誰かが質問すると、その質問に関係しそうな文書を検索して引っ張ってくる
3. 引っ張ってきた文書を AI に渡し、「この文書を踏まえて答えて」と指示

つまり、AI に「教科書を引いてから答えてもらう」仕組みです。これだけでも「ChatGPT は知らないけど自社の中では当たり前のこと」に答えられるようになるので、社内チャットボットや FAQ システムでよく使われています。

普通の RAG だけでは届かないところ

ところが、普通の RAG だけで業務を任せようとすると、いくつかの限界にぶつかります。

これらは「教科書を引く」だけでは解決できません。「誰が、どんな枠組みで、何を根拠に考えるか」を一緒に渡さないと、人間らしい答えにならない ── ここから Aina’Ola のナレッジ参照ルールが出発しています。

Aina’Ola の答え方 ── 3 階層を毎回組み立てる

Aina’Ola では、クローンが回答するたびに、第 0 回でご紹介した3 階層を動的に組み合わせて AI に渡しています。

普通の RAG が Resources の一部 (文書検索) だけを担当するのに対し、Aina’Ola はIdentity + Skills + Resources の 3 階層をまとめて毎回組み立てます。これにより「同じ会社の同じ文書を見ていても、社長クローンと現場リーダークローンで答えが違う」「同じクローンが、案件評価のときと顧客対応のときで使う思考フレームを切り替える」が実現します。

RAG の使い方も少し工夫している (Two-Stage RAG)

Resources 部分でも、Aina’Ola は普通の RAG より一手間かけています。「2 段階で検索する」方式 (Two-Stage RAG) を採用しています。

1. PDF などの長文資料を取り込むとき、原文に加えて要約 (summary) も生成して保管
2. 質問が来たら、まず要約の中だけを検索して、関連しそうな文書を絞り込む
3. 絞り込んだ文書の原文の該当箇所を取り出して、AI に渡す

例えるなら、「本棚の目次から候補を探して、本文を読む」イメージです。いきなり全文検索すると、長文資料では関係ない箇所まで大量に引っ張られて精度が落ちます。一方、要約だけで答えると、細かい根拠が拾えません。2 段階にすることで、精度と根拠の細かさを両立させています。

クローンごとに「使う本棚」を分けられる

もう一つの工夫が、Resources の参照範囲をクローンごとに分けられることです。

たとえば、Aina’Ola 上に経営者クローン・営業クローン・設計クローンが並んでいるとします。それぞれが見るべき資料は違うはずです:

• 経営者クローン: 経営方針・財務資料・過去の意思決定記録
• 営業クローン: 過去商談・顧客プロファイル・価格表・契約書テンプレート
• 設計クローン: 図面・技術仕様書・過去案件の設計根拠 (Contrail と連携)

同じ Aina’Ola の中にいても、それぞれが「自分の本棚」を持っています。経営者クローンに設計の話を聞いても、設計の資料は見に行きません。逆に設計クローンが経営の判断に踏み込むこともありません。役割と参照範囲が一致しているので、不適切な情報の混入を防げます。

さらに同じクローンの中でも、「営業の中の新規開拓専門」「営業の中の既存深耕専門」のように、より細かく分けることもできます。専門領域ごとに参照する Resources を絞ることで、回答の精度がさらに上がります。

「何を見て答えたか」が必ず分かる ── 参照根拠の透明化

業務で AI を使うときに、いちばん怖いのは「もっともらしいウソをつかれる」ことです。AI の回答を信じて行動した結果、根拠が間違っていた、では困ります。

Aina’Ola では、クローンが回答するたびに、どのクローンが、どの Skills を使って、どの Resources を参照したかを、すべて記録して画面に表示します。

たとえば、設計クローンに「シャフトシール設計の注意点」を聞くと、回答に加えて:

• このクローン名 (例: 設計クローン / 機械加工担当)
• 使った Skills (例: 部品設計の 12 カテゴリ評価フレーム)
• 参照した Resources (例: 図面 MTB-2405、不具合報告書 RPT-2401、技術仕様書 SPEC-2401) と類似度%
• Aina’Ola 側のクローン独自ケース (例: ベテランが過去に判断した事例)

が一緒に表示されます。「AI が嘘を言っていないか」を、参照元リンクで追跡できる仕組みです。これは、業務利用するうえで最低限必要な「説明可能性」を担保するための設計です。

会話の中身も、新しい Resources の素材になる

もう一つ、Aina’Ola 独特なのが、「クローンとの会話そのものが、次のナレッジの素材になる」仕組みです。

クローンと話していると、「これは Resources に追加した方がいい」と感じる発言が出てきます。たとえば:

• 新しい顧客の話題が複数回出てきた → 顧客プロファイルを追加すべき
• 判断ルールを口頭で繰り返した → Skills として明文化すべき
• 新しい工法・新しい規制の話 → Resources のカテゴリを追加すべき

これらを「整理係 AI」が会話履歴から自動で抽出し、経営者に提案します。経営者は Accept / Reject するだけ。これにより、使うほどにナレッジが増え、クローンが賢くなるサイクルが回ります。

この「育てる」プロセスについては、次回 (最終回) で詳しくご紹介します。

普通の RAG との違い、まとめ

整理すると、Aina’Ola のナレッジ参照ルールが普通の RAG と違うのは、次の点です:

• 1 つの質問に対して、Identity・Skills・Resources の 3 階層をまとめて渡す (普通の RAG は Resources だけ)
• RAG 部分も 2 段階検索で精度と根拠の細かさを両立
• クローンごとに参照範囲を分離。役割と本棚を一致させる
• 参照根拠をすべて記録・表示。AI のウソを追跡可能にする
• 会話履歴から自動で素材抽出。使うほどナレッジが育つ

普通の RAG が「教科書を引いて答える」だとすれば、Aina’Ola は「人柄 × 思考フレーム × 経験」を毎回組み立てて答える仕組みです。中小企業の現場で必要なのは、教科書的な答えではなく、自社の文脈に乗った判断 ── ここに Aina’Ola のナレッジ参照ルールが応えています。

次回予告

次回 第 5 回 (最終回) は、いよいよ「クローンを育てる ── 維持・メンテと、ナレッジ管理 AI による自動化」です。本記事の最後で軽く触れた「整理係 AI による自動メンテ」の話を、もう少し踏み込んで掘り下げ、連載のまとめにつなげます。

連載全体については以下をご覧ください:

• 第 0 回 (序章): Aina’Ola とは何か
• 第 1 回: なぜ自分専門の AI が必要だと感じたのか
• 第 2 回: クローンを業務で使う ── 周辺アプリとの組み合わせ
• 第 3 回: クローン人格の作り方 ── 3 階層の構造
• 第 4 回 (本記事): クローンが何を見て答えているか ── ナレッジ参照と、普通の RAG との違い
• 第 5 回 (最終回): クローンを育てる ── 維持・メンテと自動化

関連ページ:

• Aina’Ola Project の概要 → Aina’Ola Project とは
• Contrail 開発事例 → AIと相談しながら 設計の根拠を引き出すアプリ (本記事の「参照根拠の透明化」の実装例)
• 受託開発のご相談 → お問い合わせ