8. ナレッジベース¶

8.1.1. 製品がやること・利用者がやること¶

製品が自動で行うのは、テキスト抽出、チャンク分割、ベクトル化の 3 工程だけです。文書の整形、OCR、Q&A 形式への変換は、intra-mart Accel Platform の外で事前に済ませておく必要があります。

8.1.2. 取り込めるファイル¶

手動アップロードで取り込めるファイルの形式と、形式ごとのサイズの上限は、テキスト抽出設定（ND Universal Extractorの設定ファイル im-nd-extractor-config.xml）で決まります。取り込む前に、利用する環境のテキスト抽出設定で対象の形式と上限を確認します。設定の内容は、「設定ファイルリファレンス」の「テキスト抽出設定」を参照してください。

テキスト抽出設定にない形式でも、Markdown のように MIME タイプが text/ で始まるファイルは、UTF-8 のテキストとしてそのまま読み込みます。また、テキスト抽出設定の上限にかかわらず、100 MB を超えるファイルは取り込めません。

アイテムを追加する画面では、ファイルを選ぶ時点では形式を絞り込みません。そのため、取り込めないファイルも選択できます。取り込めないファイルは、次のどちらかの段階でエラーが発生します。

• アイテムの追加時: 形式がテキスト抽出設定にない場合や、サイズが上限を超える場合は、アイテムを追加する操作がエラーメッセージを表示して失敗します。アイテムは登録されません。
• ベクトル化の実行時: 形式とサイズが条件を満たしていても、ファイルからテキストを取り出せない場合は、ベクトル化の段階で失敗し、アイテムの状態が「エラー」に変わります（「登録後に確認すること」）。文字を画像としてだけ持つ PDF（スキャンした書類など）や、破損したファイルが該当します。

元資料は、登録する前にこれらの条件に収まるかを確認して用意します。スキャンした書類のように文字が画像になっている資料は、OCR でテキストを付けた PDF にするか、テキストに起こしてから登録します。

8.1.3. 精度は検索と推論の掛け算で決まる¶

エージェントの回答精度は、ナレッジベースの検索精度と、エージェント側の推論品質の掛け合わせで決まります。検索が的確でも推論で読み違えることがあり、逆に推論が的確でも検索が取りこぼせば答えようがありません。精度が出ない場合は、まずナレッジの設計・前処理・カバレッジを疑い、その後で技術的なチューニングに進みます（「精度が出ないときの切り分け」）。

8.1.4. 画面を開く¶

サイトマップから「Copilot」→「Accel Agent」→「ナレッジベース管理」を開きます。

一覧画面では、ナレッジベースごとの状態を「すべて／正常／要確認」で絞り込めます。「要確認」には、アイテム単位のエラーやメタデータ同期失敗（「登録後に確認すること」）を含むナレッジベースが集約されます。個々のアイテムまで見るには、対象のナレッジベースを開きます。

8.2.1. 粒度を決める¶

ナレッジベースはカテゴリで整理したうえで、業務ドメインごとに分けます。一つにまとめすぎると、検索結果に無関係なチャンクが混ざります。逆に細かく分けすぎると、検索範囲が狭くなりカバレッジが不足します。

例えば、購買申請を支援するエージェントであれば、「勘定科目マスタ」と「購買承認ポリシー」を 1 つのナレッジベースにまとめません。前者は科目の対応表という事実の集まり、後者は承認ルートを説明する規程文であり、性質も更新頻度も異なるためです。まとめてしまうと、科目を尋ねただけの質問に承認ルートの文章が紛れ込み、逆に承認ルートを尋ねた質問に無関係な科目の羅列が混ざります。

ナレッジベース名（255 文字まで）と「説明」（1000 文字まで）は、この粒度の分け方が一覧で見分けられるように付けます。「説明」は「AIエージェント向けの説明」（「2 つの説明欄を書き分ける」）と違い、人が一覧で識別するための文章です。

8.2.2. 2 つの説明欄を書き分ける¶

ナレッジベースには、人が読む「説明」と、LLM が読む「AIエージェント向けの説明」（入力欄の名前は「内容と用途」）の 2 つの説明欄があります。多言語で保持できるのは、名前と「説明」だけです。「AIエージェント向けの説明」は多言語に対応しません。

LLM は、ナレッジベースを選ぶ際に「AIエージェント向けの説明」だけを手がかりにします。対象を述べるだけでなく、いつ使うべきかを書く必要があります。

前者は「何についてのナレッジか」しか語っておらず、似た主題の別のナレッジベースがあると LLM はどちらを検索すべきか判断できません。後者は「どの場面で引くべきか」まで書いてあるため、複数のナレッジベースを割り当てたエージェントでも選び分けられます。

図：ナレッジベース編集画面。「説明」（人が読む）と「AIエージェント向けの説明」（LLM が読む）は別欄になっている。

8.3.1. 詳細設定で指定できること¶

図：「アイテム設定」画面。基本設定に有効期間開始日・終了日・外部ソース変更検知、チャンク分割に最大チャンク長・オーバーラップと、ベクトル化済みのチャンク分割結果が並ぶ。

アイテムの内容を更新する方法は、ソースタイプによって異なります。IM-Wiki コンテンツで外部ソース変更検知を有効にしていない場合は、アイテム一覧の「再ベクトル化」を実行すると、その時点の IM-Wiki の内容で登録し直されます（「再ベクトル化のやり方」）。手動アップロードしたアイテムはファイルを差し替えられないため、アイテムを削除してから登録し直します。削除すると、そのアイテムに設定した有効期間やメタデータも消えるため、登録し直した後に設定し直します。

8.3.2. 登録後に確認すること¶

登録した後は、次の 2 点を確認します。

• ジョブネットが有効になっているか: 通常、ベクトル化は「ナレッジベースベクトル化」のジョブが行うため、登録した直後はまだ検索できません。ジョブネットの作成・有効化は環境構築時の作業で、済んでいなければベクトル化がいつまでも進みません（「ジョブの運用」）。ジョブを待たずにすぐ検索できるようにしたい場合は、アイテム一覧の「再ベクトル化」ボタンでその場で処理できます（「再ベクトル化のやり方」）。

  外部ソース変更検知や有効期間を設定したアイテムでは、それぞれに対応するジョブ（「ナレッジアイテム外部ソース変更検知」「ナレッジアイテム有効期間チェック」）も有効にします。これらのジョブが動いていないと、IM-Wiki 側の更新や有効期間の開始日を迎えてもアイテムが「待機中」にならないため、ベクトル化のジョブが動いていても反映されません。また、有効期間の終了日を過ぎても、アイテムは検索対象から外れません。

• アイテムの状態が「完了」になっているか: 一覧または詳細で状態を確認します。「エラー」になっている場合は、対応形式や内容を見直したうえで、アイテム一覧の「再ベクトル化」ボタンで再試行します。

アイテムの状態は、次のように表示されます。

「無効」と「開始待ち」は、どちらもエラーではなく有効期間による正常な状態です。一覧で見分けがつきにくい場合は、対象アイテムの有効期間開始日・終了日を確認します。

8.4.1. 再ベクトル化のやり方¶

アイテムが「待機中」になるケースは複数あります。

• アイテムを登録したとき
• チャンク分割設定を変更して保存したとき（変更前の状態によって異なります。後述の表を参照）
• 外部ソース変更検知で、IM-Wiki 側の更新が検知されたとき
• 有効期間の開始日を迎えたとき
• 「強制的に再ベクトル化待ちへ」ボタンをクリックしたとき

どの経路で「待機中」になった場合でも、実際にベクトル化されるのは次のどちらかのときです。

すぐに検索できる状態にしたい場合や、「エラー」のアイテムを直した後にまず試す場合は、アイテム一覧の「再ベクトル化」ボタンを使います。「待機中」「完了」「エラー」「メタデータ同期失敗」のアイテムに使え、「処理中」と「無効／開始待ち」（有効期間外）のアイテムでは使えません。

「強制的に再ベクトル化待ちへ」は、「処理中」のアイテムを「アイテム設定」画面で開くと表示される、回復用のボタンです。システムダウンなどでベクトル化が中断されると、アイテムが「処理中」のまま残ることがあります。システム側では、実際に処理中なのか、中断されたまま残っているのかを判別できないため、このボタンは「処理中」のアイテムには常に表示されます。

このボタンは、アイテムの状態を「処理中」から「待機中」に書き換えるだけで、実行中のベクトル化を止めるものではありません。実際に処理中のアイテムに使うと、その処理が終わってもアイテムの状態は「完了」「エラー」に更新されず、「待機中」のまま残ります（処理が成功していれば、ベクトルデータ自体は作成されます）。そのため、クリックする前に、ナレッジベースベクトル化のジョブが実行中でないこと（ジョブネットモニタで確認します）と、ほかの利用者がそのアイテムの「再ベクトル化」を実行していないことを確認してください。クリックしても「待機中」に戻るだけなので、実際にベクトル化するには、ジョブの実行を待つか、「再ベクトル化」ボタンを使います。

チャンク分割設定を変更した場合、自動的に「待機中」へ戻るのは、変更前の状態が「完了」または「メタデータ同期失敗」だったアイテムだけです。

「エラー」状態のアイテムがチャンク分割設定の変更だけでは復旧しないのは、原因を直さないまま自動的に再試行を繰り返さないようにするためです。エラーが続くアイテムに気づかず放置しないよう、インデックス状況（「インデックス状況と利用箇所を確認する」）でエラー件数を定期的に確認します。

8.5.1. メタデータが使われる場面¶

メタデータは、次のような場面で使うことを想定して設計されています。

このうち検索時のフィルタリングは、エージェント定義のメタデータフィルタ（「ナレッジベース・スキル・ツール・ガードレールを割り当てる」）として実際に設定できます。回答の根拠確認・Agentic RAG の再問合せは、メタデータを持たせておくこと自体が前提になる場面です。どのメタデータ項目を用意するかは、エージェントに何を確認させたいか・何を根拠として示したいかから逆算して決めます。

例えば、購買承認ポリシーのナレッジベースに、本社向けと支社向けで内容が一部異なる規程を混在させて登録する場合を考えます。targetLocation（対象拠点。選択肢型、候補は「本社」「支社A」「支社B」）というカスタム項目をアイテムごとに設定しておけば、エージェント側のメタデータフィルタと組み合わせて検索範囲を絞り込めます。フィルタの値は固定値のほか、エージェントのインプットパラメータへの参照にもできるため、「targetLocation＝インプットパラメータの拠点コード」のように 1 つのエージェント定義のまま、呼び出し元が渡す拠点コードに応じて絞り込み先を変える、という組み方もできます。同じナレッジベースを、エージェントごとに、さらには呼び出しごとに違う範囲で使い分けられるのが、メタデータ項目を定義する利点です。

8.5.2. ビルトイン項目とカスタム項目¶

メタデータには、製品があらかじめ用意するビルトイン項目と、利用者が定義するカスタム項目があります。

格納パス・参照URLは、IM-Wiki コンテンツを取り込んだ場合にだけ自動で埋まります。手動アップロードでこれらの情報を絞り込みに使いたい場合は、カスタム項目として自分で定義する必要があります。

カスタム項目の型には、文字列・数値・日付・選択肢があります。型によって、エージェント側で設定できる絞り込み条件（演算子）が異なります。

図：アイテム一覧の「メタデータ管理」から開く「メタデータ管理」画面。選択肢型のカスタム項目を作成する例。項目名・型・説明・選択肢を指定する。

文字列型は完全一致でしか絞り込めないため、”本社” と “本社 “（末尾に空白）のような入力ゆれがあると、フィルタで正しく拾えません。値の候補が事前に決まっているなら、選択肢型にしておくほうが運用で崩れにくくなります。項目名も型も登録後には変更できないため、最初の設計がそのまま運用の制約です。