AI エージェントのための知識ベースの作り方
エージェントが知るべきことのほとんどは、すでにどこかに書かれている——あなたのウェブサイトに、そしてチームがすでに顧客に送っている PDF に。URL からのインポートが公開されている半分を、アップロードが残りをカバーする。
パイロットが停滞する最も一般的な理由は、モデルではありません。誰かが腰を据えて「知識ベースを準備する」必要があり——その仕事に持ち主がいないので、決して始まらないことです。
それはまた不要なことです。資料はほぼ必ずすでに存在します。あなたのウェブサイトにあり、チームが毎週顧客にメールで送る一握りの PDF にあります。仕事はそれを書くことではありません。仕事はそれを取り込むことです。
二種類の資料のための、二つの入口
あなたのウェブサイト——URL からインポート。 プラットフォームをあなたのサイトに向けると、公開ページを読み、それぞれを文書に変えます。これは、あなたがすでに顧客向けに書いた資料をカバーします。サービス説明、料金ページ、FAQ、方針の解説、人々が実際に尋ねる質問に答えるブログ記事。
それ以外すべて——ファイルをアップロード。 料金表、製品マニュアル、チームが何を約束できて何を約束できないかを説明する社内の1枚もの。ログインの背後にあるもの、PDF としてしか存在しないもの、ページが決して口に出さないもの。
これらを一つずつアップロードする必要はありません。フォルダを zip して、それをアップロードしてください。インポーターはサブディレクトリを歩き、見つけたすべての .md、.txt、.pdf、.html、.docx を取り込み、画像、.DS_Store、圧縮ツールが加える他のゴミを飛ばします。各ファイルはそれ自身の文書となり、アーカイブ内のパスで名付けられます——だから policies/2026/rates.pdf と policies/2025/rates.pdf は、どちらも「rates.pdf」として現れるのではなく、区別可能なまま残ります。
解析に失敗したファイル——暗号化された PDF、壊れた文書——は飛ばされて報告されます。他の39件を沈めることはありません。
この分け方は恣意的ではありません。ウェブサイトのインポートは速く広いが浅い——訪問者に見えるものしか見られません。アップロードこそ、あなたのエージェントをサイトに向けた検索エンジンと違うものにする資料が存在する場所です。
インポートにできないこと
そのつもりで計画する前に、知っておく価値があります。
JavaScript でコンテンツを組み立てるページは空で返ってきます——インポーターは HTML を取得するのであって、ブラウザを走らせません。ログインの背後にあるものは手が届きません。サイトからリンクされた PDF は飛ばされます。それらはアップロード経路を通ります（個別に、または一括で zip して）。robots.txt を尊重します。そしてそれはサブスクリプションではなく一回きりのインポートです。あなたのサイトが変わっても、知識ベースはそれに合わせて変わりません。更新するにはインポートを再度実行します。
ページを読むこと自体には費用がかかりません。何かが追加される前に、ページ数と文字数の正確な数、そしてトークンコストの見積もりが見え——あなたが承認するまで何も追加されません。
あなたのサイトが通常のサーバーレンダリングのサイト——WordPress、Webflow、Squarespace、たいていの CMS で作られたマーケティングサイト——なら、インポートはそれを読みます。すべてをクライアント側で描画するシングルページアプリが失敗するケースで、しかも空のページを静かにインポートするのではなく、はっきり失敗します。
具体的な作業例
二言語対応のサイトと、料金表でいっぱいの共有ドライブを持つ住宅ローン仲介業者。
サイトをインポート、英語のみ。 彼らはインポーターをホームページに向け、パス接頭辞を /en/ に設定します。それがないと、ページの予算は3言語の同じ8記事に費やされます——同じコンテンツ、3倍のコスト、そして検索時のほぼ重複したヒット。インポートはサイトマップを通じて8ページを見つけます。4本の長いガイド、リソース索引、チームと会社概要のページ、そして問い合わせ。約45,000文字。彼らが承認すると、1分後には知識ベースに8つの文書が入ります。
この時点でエージェントは、すでに「医師向けローンはありますか？」や「バーチャルクロージングはどう機能しますか？」に答えられます——それらの記事は何年も前に書かれ、ブログに置かれていたからです。
サイトが決して言わない四つのものをアップロード。 現在の料金表。自営業申請者向けの書類チェックリスト。ローン担当者がチャットで約束してはならないことについての1枚もの。州の開示書類のスキャンコピー。どれもウェブサイトにはなく、うち二つはあるべきではありません。それらはすでに一つの共有フォルダにあったので、四つのアップロードではなく一つの zip として上がりました。
事実ではなく、境界を書く。 知識ベースの指示に：これは当社の現在の方針であり、一般的な業界慣行に優先する。金利は常にその有効日とともに提示すること。特定の申請に関するものはすべて人間へ引き継ぐこと。 事実は文書に存在します。指示はそれをどう扱うかを言います。
かかった総時間：午後の一区切り、その大半はどの社内文書を含めても安全かを決めることに費やされます——それこそが実際に人の判断に値する部分です。
本当の作業はどこにあるか
この例が含まなかったことに注目してください。新しいコンテンツを書くこと、何かを整形すること、タグ付け、あるいは分類体系を作ること。検索の層はそれらを必要としません。
含んだのは、どんなツールもあなたのために下せない二つの決定でした。どの社内資料が、エージェント越しに顧客が到達しても安全か。そしてエージェントが約束することを許されないのは何か。インポートではなく、その二つのために時間の予算を組んでください。
構造化インデックスとは、エージェントが文書にすでに含まれているフィールド（タイトル、価格、レベル、リンク、画像）から構築する小さなテーブルと、意味を検索するために使用されるベクトル検索を組み合わせたものです。ベクトル検索は質問のように読める段落を見つけますが、カウントしたり、数値でフィルタリングしたり、グループ化したりすることはできません。構造化インデックスはそれらの問いに答え、エージェントが断片から再構築するのではなく、リンクや識別子を正確に引用できるようにします。
ストーリーラインは、エージェントが各エンドユーザーとともにたどる有向グラフである——どのノードも一つのステップ（それ自身のタスク、知識、ツール）で、出口には条件が付き、各人の進捗、プロフィール、メモがセッションやチャネルをまたいで保存・再開される。これはエージェントを、点在するタスクをこなすアシスタントから、複数ステップのサービスを自ら届けられるものへと変える。
Dynamic Planner は会話を見張り、ユーザーがエージェントの領域内で本当に複数ステップを要するタスクに取り組んでいて、どう進めればよいか明らかに分からずにいるとき、そのタスクを一時的なストーリーライン——チェックリスト駆動の、段階的な計画——へ展開することを提案する。エージェントはその計画を、一度に一つのステップへ集中して実行し、進捗はユーザーからも見える。計画づくりは検証つきで一度だけ起こり、実行は決定的である。
長文執筆は、エージェントがアウトラインの計画をまず行い、開始前に必要なものをすべて要求し、各セクションをあなたの資料や公開ソースに対して調査し、再起動しても継続可能なジョブとしてセクションごとに執筆することで、完全な多セクションのドキュメント（提出書類、市場参入レポート、デューデリジェンスメモなど）を生成するものです。チャットの横にあるキャンバスで編集し、選択した段落を書き換えることができ、すべてのバージョンが保持されます。