AI正本化とは？―AIエージェントに「会社の正解・判断基準・例外」を教える方法

AIに社内資料を読ませれば、会社のことを理解してくれる。
生成AIが登場したころは、そんな期待がありました。
議事録を入れる。営業資料を入れる。過去の提案書を入れる。マニュアルを教える。規程を教える。そしてRAGにつなげる。
しかし、企業でAIを使えば使うほど、別の問題が見えてきました。

資料があることと、会社として何が正しいかが決まっていることは、同じではありません。

ベテラン社員なら、すぐに見分けて判断できます。

AIには、それが分かりません。
そこで必要になるのが、「AI正本化」と呼んでいる作業が必要になります。

1．AI正本化とは

ここでいう「正本」は、巨大な一冊のマニュアルを作ることではありません。

AIが仕事をするときに、次のことを確認できる「信頼できる基準点」を作るという意味です。

以前から、企業・専門家・作家・出版社が持つ知識や判断基準を、AIが信頼して参照できる「辞書／教科書＝正本」に変える仕事を、AIナレッジエンジニアの仕事として説明してきました。

2．なぜ、いまAI正本化が必要なのか？

企業での生成AI活用を、大きく三段階に分けると分かりやすいと思います。

第１ステップ：

チャットbot  →  RAG  →  AI エージェント

チャットbotの時代には、AIの主な仕事は「答えること」でした。
間違った答えが返ってきても、人間が読んで直せばよかった。
次にRAGが普及しました。社内文書やデータベースから関連情報を検索し、その情報を使ってAIに回答させる。これは大きな進歩です。
しかし、AIエージェントになると問題が変わります。
AIは、調べる、比較する、判断する、ツールを呼び出す、メールを書く、顧客へ回答する、システムを更新する、次の処理へ進む、といった自律的な行動を連続していきます。

第２ステップ：

「答えるAI」から「働くAI」へ変わる。

答えるだけなら、多少曖昧でも最後に人間が確認して修正すればいい。
でも、AIが判断して次の処理へ進むなら、「AIは何を根拠に判断したのか」が重要になります。
AIの頭が良くなったからこそ、AIに何を信じて働かせるかが次の問題になるのです。

3．AI正本って何が入るの？

たとえば、営業AIに値引き判断を手伝わせるとします。

それが１商品だけならいいですけど、それが100、1,000と増えていくと人間だけでは大変です。

そこで「値引き規程.pdf」を一冊読ませるのですが、実はそれだけでは足りません。実際の現場は、もっと複雑な場合が多いからです。

必要であれば、根拠資料、適用開始日、適用終了日、対象部署、対象顧客、機密区分、旧ルールとの関係なども追加します。

重要なのは情報量ではなく、「この条件では、これを正として使う」とAIが判断できることなのです。

4．RAGとAI正本化は、何が違うか？

・RAGは「どう探すか」
・AI正本化は「何を”正”として探させるか」

たとえば、社内に値引き関連資料が100本あるとします。
RAGは、その100本から質問に近い資料を探すことができます。
しかし、2024年版・2025年版・2026年版の値引き規程、特定顧客だけの例外メール、会議で出ただけの未決定案が全部入っていたらどうでしょう。
検索できたとしても、どれを会社として正しいものとするかは、RAGそのものが決めてくれるわけではありません。

そこで、人間側で
「現在の正式ルールはこれ」
「このメールはA社だけの例外」
「この議事録は検討案であり正式決定ではない」
と意味を付ける必要があります。

というわけで、AI正本化した情報をRAGが正しく取得する、という関係になります。

5．Knowledge Baseと何が違うか？

現在のナレッジベースは、文書の保存だけでなく、チャンク化、検索、RAG、引用元提示などまで行います。したがって、「Knowledge Base＝ただ情報を置くだけ」と考えるのは、技術的には少し乱暴です。

ナレッジベースに新旧の営業資料、FAQ、会議資料、過去の提案書、規程、マニュアルをすべて保存することはできます。

しかし、その中で何を会社として正しいものとするのか。誰がその正しさに責任を持つのか。どんな条件なら適用してよいのか。これは別の設計問題なのです。

AI正本化との違いは、

・Knowledge Base＝情報を蓄積・検索できる状態を作る。
・AI正本化＝何を正本とし、誰が、どの条件で、いつまで責任を持つかを決める。

6．Ontology（オントロジー）とは何が違うのか

ただし、現在の企業向けOntologyは、意味と関係だけではありません。
Palantir Ontologyのように、Objects、Properties、Linksに加えて、Actions、Functions、Securityまで含み、企業の意思決定や実行を扱うOperational Layerとして設計されるものもあります。

したがって、「Ontologyは意味だけ、AI正本は判断まで」と単純に分けるのは正確ではありません。
私が考える違いは、もっと手前にあります。

・Ontologyは「どう表現・接続・実行するか」の技術設計
・AI正本化は「会社として何を正解・規範として採用するのか」を決める編集・ガバナンス工程。

AI正本化したものをOntologyで実装してもいい。RAGで使ってもいい。Knowledge Baseに入れてもいい。データベースでも、構造化テキストでもいい。

つまりAI正本化は、特定の製品やデータ形式の名称ではありません。AIに会社の何を正として渡すのかを決める工程なのです。

7．Context Engineeringとはどういう関係か？

Context Engineeringは、単なるPrompt Engineeringの延長ではありません。system instructions、tools、MCP、external data、message historyなど、モデルが推論時に受け取るContext全体を設計・管理する問題です。

つまり、AIに「いつ」「何を」「どこから取得し」「どの順番で」「どのくらい渡し」「何を記憶させ」「どのツールを使わせるか」まで扱います。

その中でAI正本化が扱うのは、「企業固有の、信頼できる知識・判断基準を作る部分」です。

・Context Engineering＝大きな技術・設計カテゴリー
・AI正本化＝企業固有の信頼できるコンテキスト（文脈）を作る工程

Context Engineeringが「何をContextとして渡すか」を考えても、会社側に信頼できる元情報がなければ、渡すものがありません。

だから企業では、Context Engineeringの前提としてAI正本化が必要になると考えています。

8．AI参照可能性（AI Referenceability）との関係

そして、正本を作っただけでは終わりません。
大事なのは、AIが必要なときに、その正本へ本当にたどり着けるかです。

これを「AI参照可能性（AI Referenceability）」という品質軸で考えています。

その出発点になったのが、2026年3月の言語処理学会第32回年次大会（NLP2026）で発表した「RAG時代の言語資源設計原理―構造化テキストによる『参照可能性』の実証」という研究です。

この実験では、同じ原典から作った情報でも、構造化メタデータのみの場合と本文のみの場合で、構造クエリに対するRecall@10が59.0％対5.3％、11.1倍の差になりました。

同じ知識でも、「AIが参照するためにどう設計されているか」で、たどり着きやすさは大きく変わってくる。

ここで注意したいのは、「AI正本化すれば、どんなAIでも11.1倍よくなる」という意味ではありません。実験したのは、特定条件下のRAGにおけるReference Retrievalです。

人間が読めることと、AIが必要なときに正しい場所へ到達できることは違います。だから、AI正本化＝信頼できる参照点を作る。AI Referenceability＝その参照点へAIが正しく到達できるかを見る。という関係になるのです。

AI参照可能性の定義は、次の正本記事に統一しています。
AI参照可能性（AI Referenceability）とは何か？

9．実際には、何をAI正本化するのか？

営業

「値引きしていいですか？」
一般的なAIなら「顧客との関係性や利益率を考慮して判断しましょう」と答えるでしょう。でも、会社が欲しいのはそんな一般論ではありません。
10％までは担当者、15％までは部長、それ以上は役員決裁。年間契約では別基準。官公庁案件では別ルール。この商品だけは値引き禁止。という会社の判断です。これをAI正本化します。

人事・採用

「この候補者を次の面接に進めてよいか？」
求人票だけではありません。必須条件、加点条件、不採用条件、ポテンシャル採用の例外、誰が例外判断できるか、過去にどう判断したか等の情報が必要です。
人事判断をすべてAIへ丸投げしませんよね。
どこまでAIが判断し、どこから人間へ戻すかまで正本にする必要があります。

出版社

この場合は書籍（文章が多い）出版社であれば、作家、作品、契約内容、権利、紙版、電子版、二次利用、海外利用、AIの利用許諾、正式な書籍情報、改訂履歴などが絡んできます。
「この本の内容をAIサービスで使っていいか」という問いに、書籍本文だけ検索しても答えは出ません。必要なのは、作品の内容＋契約＋権利＋許諾条件を正しく結びつけることです。

顧客対応

例えば「返金できますか？」
FAQだけでは足りませんよね。
返金条件、購入経路、利用期間、商品カテゴリ、障害発生時の特例、VIP顧客への対応、法務確認が必要なケース、人間へエスカレーションする条件まで必要でしょう。AIエージェントが顧客へ直接回答するなら、なおさらです。

10．AI正本化は、「会社の答えを固定すること」ではない

ここで誤解してほしくないことがあります。AI正本化とは、会社のルールを一度決めて、永遠に固定することではありません。
会社は変わります。市場も変わる。商品も変わる。法律も変わる。顧客も変わる。社長の判断も変わる。すべて流動的です。
だから重要なのは、「正解を保存すること」より、「現在、何を正としているかを更新できる仕組み」を構築することなのです。

• そのオーナー（担当者・責任者）は誰か？

• 最終更新日はいつか？

• 何を根拠に決めたか？

• どこまで適用されるのか？

• 旧ルールを誰が、何に更新したか？

だからAI正本には「著者」が必要です。誰がこの判断を書き、誰が更新し、誰が現在の正しさに責任を持つのか。AIが生成・要約・統合する時代だからこそ、知識の出所と更新責任を人間側に残しておく必要があります。

・AI正本化は、データ整理のプロジェクトではありません。
・継続的な会社運営の仕組みなのです。

11．なぜ「AI正本化」と言うのか？

RAG。Knowledge Base。Ontology。Semantic Layer。Context Layer。Context Engineering。
どれも重要です。

しかし、企業の経営者や現場の人と話していると、それだけでは一番重要な問いが抜け落ちることがあります。

結局、AIに何を正しいものとして教えるのですか？

技術の問題だけではありません。会社側が決めなければならない、どの数字を正とするのか。誰の判断を正とするのか。どの資料を正とするのか。どの例外を認めるのか。誰に決める権限があるのか。ここが玉虫色なら、AIは会社の正式判断と、過去の例外と、単なる一担当者の意見を区別できません。その結果、もっとも“それらしい答え”を作ってしまいます。

だから、手短に説明するために「AI正本化」という言葉を使っています。

これは、現時点で一般に標準化された技術用語ではありません。
私が企業・専門家・著者・出版社の知識設計を説明するために使っている実務上の言葉です。

以前は「AI向けの辞書／教科書を作る」とも説明してきました。
話す相手によって「AIに、会社のものさしを教える」と言っています。

AIが賢くなれば、会社の知識を整理しなくてもよくなる。
そんなものは、AIがもっと賢くなれば不要になるのでは？」と思う人も多いでしょう。
でもそれは間違いです。

AIが進化して賢くなり、AIが検索して、AIが判断して、AIが自律的に行動するようになればなるほど、「AIに何を信じさせるか」が重要になります。
だから必要なのは、AIを会社に導入することではないのです。

会社そのものを、AIに教えられる状態にすること。
それがAI正本化なのです。

まとめ

・コンテキストエンジニアリング（Context Engineering）
＝大きな技術・設計カテゴリー

・AI正本化
＝企業固有の知識・判断基準を、信頼できる正本にする工程

・AI参照可能性（AI Referenceability）
＝AIが正しい参照点へ到達できるかを見る品質軸

・AIナレッジエンジニア
＝それを設計する職能

人。工程。品質。そして、それらを包む技術カテゴリー。
この4つを分けて考えています。
AI時代に企業に必要になるのは、AI導入だけではないのです。

AIに教える「会社のものさし」。
そのものさしを、AIが読めるように「正本」にする。

それが「AI正本化」なのです。

参考情報

 Anthropic, “Effective context engineering for AI agents”
https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

 Google Cloud, “What is AI context engineering?”
https://cloud.google.com/discover/ai-context-engineering

 OpenAI, “Inside OpenAI’s in-house data agent”
https://openai.com/index/inside-our-in-house-data-agent/

AWS, “Amazon Bedrock Knowledge Bases”
https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html

Palantir, “Ontology — Core concepts”
https://www.palantir.com/docs/foundry/ontology/core-concepts
 
池松潤「RAG時代の言語資源設計原理―構造化テキストによる『参照可能性』の実証」言語処理学会第32回年次大会（NLP2026）
https://www.anlp.jp/proceedings/annual_meeting/2026/pdf_dir/Q5-8.pdf

 「米国で言われるContext Layer論とは日本語で『AI正本化』のこと」
https://note.com/ikematsu/n/n45b0f83c7e32

 「あらためまして池松潤はAIナレッジエンジニアです」
https://note.com/ikematsu/n/n9872746f04d2

#AI正本化
#AIナレッジエンジニア
#AI参照可能性
#AIReferenceability
#コンテキストエンジニアリング
#ContextEngineering
#AIエージェント
#生成AI
#RAG
#ナレッジマネジメント
#オントロジー
#企業AI
#AI導入
#AIガバナンス
#経営DX