InfoForge：私のローカルAIエージェント用のRAGソースとしてのオフライン版ウィキペディア

私は自宅にある8B規模のローカルモデルに、『こころ』の著者と出版年を尋ねてみました。すると「夏目漱石、1914年」と答えた上で、実際に私が知りたかった情報も教えてくれました。このモデル自体はその事実を知らないはずなのですが、私の家にある52.69GBもの容量を持つWikipediaデータベースを参照して調べ上げたのです。ちなみにインターネット接続は一切不要でした。

モデルがすでに「知識」を持っているのに、なぜこれが必要か

実際にはモデルは何も知らないのです。問題は、失敗した場合の挙動が非常に厄介だという点です。小規模なモデルに日付や化学的性質、地名などを尋ねると、流暢で自信に満ちた、一見もっともらしい回答が返ってきますが、それが正しいかどうかを示す手がかりは一切ありません。モデルは嘘をついているわけではなく、記憶から引き出した情報と生成した情報を区別する仕組みがないだけです。文章作成には問題ありませんが、事実確認の場面では致命的です。

参照機能はこの問題を解決しますが、従来の参照システムはクラウド上の検索APIを前提としています。つまり質問が企業に送られ、その企業がログを記録し、私たちのアシスタントの有用性は他者の稼働状況や利用規約に左右されることになります。私の子供たちの質問に答えるためのAI環境がある我が家では、この両面とも懸念材料でした。

Wikipediaなら両方の問題を同時に解決できます。これは現存する中で最も密度の高い一般知識コーパスであり、法的・実用的にも完全な形でダウンロード可能です。しかもディスク容量も、外食一回分より安く済む程度です。Kiwixプロジェクトが長年かけて、学校や船内、通信環境のない場所でも利用できるよう、ウィキペディア全体を圧縮・索引付けしたZIM形式にパッケージ化してきました。私は単にブラウザの代わりにAIをそこに向けているだけなのです。

最終的に得られるもの

質問を入力すれば回答が得られ、さらにその回答がどのWikipedia記事に基づいているかを示す引用情報も付随します。例えば以下のようになります：

$ infoforge "『こころ』の著者は誰で、いつ出版されたか？"

『こころ』は夏目漱石によって執筆され、1914年に出版されました。

出典：
  - こころ

見た目はごく普通です。重要なのは「何も起きていない」点です。ネットワークリクエストは一切外部へ送信されておらず、プロバイダー側にログも残っていません。またモデルも記憶から回答することが構造的に防がれています。検索結果が空だった場合には、沈黙を埋めるような回答ではなく失敗メッセージを出力し、非ゼロの終了コードを返します。

仕組み

5つの段階から成りますが、特別巧妙な技術は用いられていません。むしろそれが推奨されるやり方です。

キーワード抽出。 質問そのものが検索クエリになるわけではありません。「『こころ』の著者は誰で、いつ出版されたか？」という文は不適切な検索語ですが、Kokoroという単語は適切です。数ダース程度のコードでストップワードを除外しフレーズを保持するだけで十分な結果が得られ、私もそれ以上改良したことはありません。

検索。 Kiwixの全文検索機能は単なるgrepではなく本格的な検索索引です。この仕組みがあるからこそ、1,919万エントリ中から3～30ミリ秒という高速な検索が可能になります。このシステム内には埋め込みベクトルもベクターデータベースも、更新時に再構築するためのチャンクストアも存在しません。Wikipediaの編集者たちがすでに「記事」という単位で分割してくれているのです。

取得と切り詰め処理。 上位の結果は各約0.5ミリ秒で全文として返されます。ここで唯一判断を要するのが切り詰め処理です。冒頭部分にほとんどの事実情報が含まれているため、トークン予算は冒頭から消費されます。各記事が自己完結できる程度の量は残しつつ、指示文を覆い隠してしまうほど多くは割り当てません。

根拠付きプロンプト。 これらの記事を「この情報のみから回答し、出典名を明記せよ」という指示と共にプロンプト内に含めます。ここが全ての鍵となりますが、これはあくまでプロンプトであり保証ではありません。そのため次の項目が必要になるのです。

モデル。 自宅のGPUサーバー上で動作するローカルの推論用モデル（DeepSeek-R1 8B）が回答を生成します。ウォーム状態では往復に約8秒かかりますが、そのうち約7.9秒はモデル自身の処理時間です。参照機能自体は無料ですが、思考処理にはコストがかかります。

拒否を契約として機能させる

最も強く擁護したい設計上の決定点は技術的なものではありません。

「これらの情報のみを使え」というプロンプトはあくまで要請に過ぎません。モデルはほとんどの場合それに従いますが、情報源が乏しく自身の記憶にある情報が適合する場合には無視してしまうこともあります。システムの防御策がこの一文だけだと、「根拠付き」という状態は単なる雰囲気でしかなくなってしまいます。

そこでモデル外部で根拠付けを強制します。検索結果が利用できない場合、ツールは空の質問文をLLMへ渡すことなく失敗処理を行い、非ゼロの終了コードを返します。これはあらゆる呼び出しプログラムが既に認識できる唯一のシグナルです。またこのツールを利用するAIエージェントには「記憶から回答を補うのではなく検索失敗を報告せよ」と定められています。拒否処理は伝播し、上位レイヤーで平滑化されることはありません。

その結果得られるアシスタントは「何も見つけられませんでした」と告げます。機能リスト上では弱点に映るかもしれませんが、実際は正反対です。「見つけられませんでした」と答えるモデルは、でっち上げ回答をする大規模なモデルより価値があります。 前者は信頼して利用できるのに対し、後者は事実確認が必須となり、結局全ての回答を検証しなければならなくなってしまうからです。

プライバシーはポリシーではなくアーキテクチャである

大手アシスタントにはプライバシーページがありますが、本システムには「トポロジー」があります。質問は端末から同じLAN上の検索索引へ、さらに同じLAN上のモデルへと送られ、そこから返答が戻ります。経路上にログを記録できるプロバイダーもなければ、私を特定するキーも存在せず、次四半期に変更されうる利用規約もありません。子供が恥ずかしい質問をしても、まるで本棚から本を引き出すようにプライベートなやり取りが成立します。実質的にそれと同じものだからです。

誰も私を信頼する必要はありません。インターネットを切断した状態でもシステムが正常に動作することを確認すれば検証可能だからです。

地味な90％

パイプラインの構築自体は週末程度の楽しい作業で済みました。実際に困難だったのはコンテナ関連の3つの設定項目だけでした。

WikipediaサーバーはSELinuxが有効化された不変性を持つLinuxデスクトップ上で、root権限なしのコンテナとして稼働します。これら全ての制約が私に一晩を強いることになったのです：

• rootlessユーザーマッピング。 コンテナ内では自身の名前空間内でrootとして動作する必要があり、外部からは非特権ユーザーにマッピングされます。これが誤っているとサーバーは起動し「正常」と報告するものの実際には何も提供できず、単に指定されたファイルを読み込めない状態になります。
• SELinux再ラベリング。 SELinux環境下でコンテナ内にマウントされるボリュームには、再ラベリングオプションが必須です。そうしないとカーネル側のポリシーにより読み込みが拒否されます。エラーは「ファイルが存在しない」という形で現れるため、まったく別の場所を探してしまうことになります。
• 明示的なファイルパス。 ZIMディレクトリの自動検出機能は、コンテナ内から見たファイルシステム上ではドキュメント通りに働きませんでした。問題が他にあると決めつけていた私が、明示的なファイル名を指定してやっと解決できました。

たった3つの設定項目です。かかった時間の約90％がこれらに費やされました。これこそが自己ホスティング作業の実態であり、多くの記事では語られない部分でもあります。だからこそ初めて独力で取り組む人々は、単に3つの設定項目に直面しているだけなのに自分は不向きだと誤解してしまうのです。

そして機能は停止したが、誰も気づかなかった

正常に動作していました。速さも問題ありませんでした。私はテストを行い、数値を記録してから他の作業に移りました。

一週間後、再び利用しようとしたところ、その機能がなくなっていました。何らかのタイミングでマシンが再起動し、コンテナも復帰せず、私に通知する仕組みも存在しませんでした。サービスユニットも監視機能もヘルスチェックもなかったからです。さらに悪いことに、AIエージェントたちにこのツールの存在を知らせるはずだったスキルファイルは「下書き状態のままでインストールされていなかった」のです。そのため一週間もの間、家にあるすべてのエージェントは本来なら情報を参照できたはずなのに記憶だけで応答しており、自分たちが利用可能なオプションが失われていることすら気づいていませんでした。

教訓は非常に簡潔です：

自動起動されず、誰も知らない機能というのは、まるで作っていない機能と何ら変わりがない。

対策としては、12行程度のサービスユニットと1つのMarkdownファイルを作成しただけです。このサービスユニットによりサーバーは再起動後も正常に稼働します。Markdownファイルはエージェント群が利用可能な機能を認識するための共有スキル情報であり、ツールの存在や呼び出し方法（シェルコマンドまたはHTTP）、そして正確な回答には引用情報も付随すべきだという指示まで含まれています。

元々の処理フローは700行にも及ぶ複雑なものでしたが、実際に機能させるためにはわずか13行の定型的コードが必要だったのです。私はこの教訓を何度も学び直しているのです。

エージェントスタックに組み込まれた機能

私は家庭および業務用に複数のローカルAIエージェントを運用していますが、InfoForgeは今や単なるスクリプトではなく、全エージェントが共有する機能となりました。事実を知りたいエージェントは該当コマンドを実行するかエンドポイントにアクセスし、引用情報付きの回答を受け取ってそれをそのまま私に伝えます。この引用情報は見た目以上に重要です。エージェントが何かを教えてくれつつ記事名も示してくれると、ワンクリックで内容を確認できるのです。こうした検証こそが、単なる「話し上手な存在」を「実用的なアシスタント」へと変えるのです。

またこの機能は家内にある他のあらゆるシステムとも連携します。同じGPUサーバーがInfoForgeのクエリに応答したり、メールの下書きやチャット処理も行います。知識層というのは、アカウント登録すら不要な単なる機能要素となったわけです。

注意点

• ダウンロード前にディスク容量を確認すること。 画像なしのビルドで約53GB、画像付きならその倍程度になります。空き容量を必ず確認してください。途中まで書き込まれたZIMファイルから容量不足を知るのは非効率です。
• ダンプデータには日付がある。 私の環境では2026年6月版です。Wikipediaは常に更新され続けるため、この日付以降の情報は本システム上では存在しないことになります。これを承知していれば問題ありませんが、忘れると落とし穴となります。
• 検索品質はキーワード抽出能力に依存する。 不適切な回答のほとんどはモデルの問題ではなくクエリ作成の失敗によるものです。より大きなモデルを導入する前に、まずキーワード抽出を改善すべきです。
• コンテキスト量の調整が重要。 少なすぎると回答が得られず、多すぎるとモデルが指示から逸脱します。合成データではなく実際に関心のある質問で調整してください。
• 失敗ケースも意図的にテストすること。 Wikipediaに該当記事が存在しない質問を投げかけ、拒否応答やゼロ以外の終了コードが返されることを確認しましょう。うまくいく質問だけでテストしていると、容易なケースしか検証していないことになります。
• サービスユニットは最初から作成すること。 上記の通りです。どうしてそうなるかは私に聞いてください。

これにより私の環境がどう変わったか

今や家には検索インデックス付きのオフライン百科事典があり、AIもそこから得た情報のみで応答するよう制限されています。これらを導入するのにかかったのはダウンロード作業と週末程度の時間だけです。インターネットより速く、通信不能時でも動作し、サービス停止の心配もなく、私自身がビジネスモデルとして関与する必要もありません。

次の目標は同じラックにさらにZIMファイルを追加することです。Kiwixパッケージにある医療・技術関連コレクションや、私自身が作成したウィキなども導入予定です。情報検索層はコーパスの内容を問わないからです。そしてヘルスチェック機能も実装するつもりです。先ほどの教訓を代償を払って学んだばかりだからです。

ダウンロード

• Download InfoForge project source (zip) 80 KB

個人利用は無料です。役に立ったら、コーヒーをおごってもらえると嬉しいです。