AIがあなたのビジネスを学ぶ場所
自然言語による業務定義。スキーマレスのプレイブック。ツール変更でも残る慣行。
UKBはエージェントの前頭前野です。組織が『アクティブな顧客』とは何かをどう定義しているか、更新チェックはどう進めるべきか、返金は誰が承認すべきか、そして汎用エージェントを『あなたのもの』にする非公式な慣行まで保持します。常に自然言語で保持されるため、人間が衝突で勝ち、インフラの入れ替えでも知識は残ります。
UKBに何が住んでいるか
知識はスキーマレスで保持され、プロバイダー変更、カラム名変更、マイグレーションに耐えます。
プロンプト指示が知識ベースにならない理由
『システムプロンプトに入れろ』が単一ユースケースを超えると機能しない3つの理由。
カスタム指示は毎ターン発火するか全く発火しません。実際のビジネス知識は特定のエンティティ、ロール、瞬間に適用されます。
『Notionを検索』は時限爆弾です。ドキュメントストアを切り替えると、組織中のすべてのシステムプロンプトが一度に壊れます。
オートメモリは事実を蓄積しますが、競合解決の構造を持ちません。最も重要なルールがコンパクション中に薄れてしまいます。
UKBが行うこと
ビジネス知識をファーストクラスにする4つの特性。
自然言語の業務定義
『アクティブな顧客』『Q3 ARR』『サポートエスカレーション』を自然言語で定義します。エージェントは計画段階でこれを読み、すべてのステップに反映します。
ドメインタグ駆動のスキーマレスプレイブック
プレイブックは『[document_store]を検索』『[team_chat]に投稿』のように書かれます。プロバイダーを変えても動作し、バインドはSKB接続済みアカウントに対して行われます。
競合の優先順位 — 人間が常に優先
管理者が記述した知識が発見・使用学習と矛盾した場合、UKBは決定論的な優先順位(人間 > 管理者発見 > 使用)を適用します。静かな上書きはありません。
コンパクションを構造的に生き延びる
UKBエントリは非構造のメモリではなく構造化レコードです。オーケストレーターが計画時点で取得するため、要約で失われません。
3つのソース、1つの真実
UKBが混乱に陥らず成長する方法。
管理者が標準定義を記述
あなたのチームが業務定義・プレイブック・慣行を自然言語で記述します。他のどのソースより優先されます。
発見が新しい知識を提案
エージェントが解決できない反復パターンに出会うと、UKB候補を起草し管理者レビューキューに登録します。承認なしに信頼されることはありません。
使用が粗い部分を磨く
繰り返されるユーザー修正と確認済みパターンは、低優先度のUKB更新として戻ります。常に管理者記述の知識より下位です。
ソースが矛盾するときは、人間が常に勝ちます。
ナレッジベースの正直な比較
UKBが提供するものと代替案の比較。
| 機能 | Interactor UKB | ChatGPT / Cowork | ゼロから構築 |
|---|---|---|---|
| 定義に基づく組織理解 | あり — 3レイヤープロファイル | プロジェクトコンテキストのみ | あり — 3か月以上 |
| ドメインタグ付きプレイブック | あり — ポータブル | プロンプトをハードコード | あり — 4か月以上 |
| インフラ変更でも維持 | あり — スキーマレス | 名前変更で破損 | 6か月以上の慎重設計 |
| 経時的に学習、競合は人間が決定 | あり — 優先順位 | 構造化された学習なし | 6か月以上 |
| 稼働するKBまでの時間 | 数日 | 該当なし | 6〜9か月 |
定義を一つ持ち込んでください。UKBの草案を持ち帰れます。
AIに理解してほしい業務用語を一つ選んでください。UKBエントリとして構造化し、プランがどう変わるかをお見せします。
