Infobroker

Infobroker

1つのサーバー。あらゆる情報源。成果につながるリサーチ。

Infobroker は、ウェブ検索、構造化された知識、学術情報、アーカイブ、コンテンツ抽出の API を単一のツールインターフェースに統合する、マルチプロバイダー MCP サーバーです。設定不要のプロバイダーを 21 種類同梱しているため、何も設定せずにウェブを検索したり、事実を調べたり、記事を取得したりできます。API キーまたはセルフホストで、さらに 5 種類のプロバイダーを利用できます。組み込みの裏付けエンジンは独立した情報源を相互参照し、確立された事実と議論のある主張を区別します。同梱のクライアントスキルは、生のリサーチ結果を洗練された文章に仕上げます。まずは無料で。プライバシーは常に守られます。

• 北極星
• クイックスタート
• MCP サーバー
• スキル
• プロバイダー
• 設定
• 比較
• 貢献
• ライセンス
• 仕様

北極星

Infobroker はツールとしての Bothan Spynet です。独立した情報源に問い合わせ、結果を単一の公平なインターフェース経由で提供する、分散型の情報ネットワークです。情報活動のサイクルに当てはめると、方向性を示せば情報が届けられ、サーバーが収集と処理を担います。

クイックスタート

cd Infobroker && npm install && npm run start

次の内容を OpenCode の設定（~/.config/opencode/opencode.json）に追加します。

{
  "instructions": [
    "<path-to-Infobroker>/instructions/search-preferences.md"
  ],
  "skills": {
    "paths": [
      "<path-to-Infobroker>/skills",
      "<path-to-opencode-config>/skills"
    ]
  },
  "mcp": {
    "infobroker": {
      "type": "local",
      "command": ["node_modules/.bin/tsx", "src/index.ts"],
      "cwd": "<path-to-Infobroker>",
      "environment": {
        "INFOBROKER_CONFIG": "<path-to-Infobroker>/config.json"
      }
    }
  }
}

mcp ブロックでサーバーを起動し、instructions ブロックと skills ブロックで同梱のクライアントスキルを有効にします。これらがない場合、スキルはリポジトリに含まれていても動作しません。

無料のプロバイダーはすぐに利用できます。API キーが必要なプロバイダー（Brave、Exa、 Tavily、Yep）を使うと、処理量が増え、専門的な検索が可能になります。セルフホストの SearXNG を使えば、クエリのプライバシーを完全に確保できます。

export INFOBROKER_BRAVE_API_KEY="your-key"
export INFOBROKER_EXA_API_KEY="your-key"

要件：Node.js 24 以降。

MCP サーバー

リサーチのバックエンドです。7 つのツール、26 のプロバイダー、1 つの 裏付けエンジンを備えています。機能の全一覧は、仕様の 機能分類に記載されています。

統合検索

「2つ目のデス・スターの場所を検索してください。」 「ハイパースペース航行理論に関する学術論文を見つけてください。」 「最新のアストロメク・ドロイドの仕様を検索し、次の問いに答える箇所を示してください。R2 ユニットはクローン戦争より前に登場しましたか？」

search_web は、クエリに回答できるすべてのプロバイダーに検索を依頼します。DuckDuckGo、Wikipedia、学術データベース、ニュース、コードリポジトリなどを検索できます。また、タスクを説明すれば、サーバーが最適な情報源を選びます。クエリの配列を渡すと、1 回の呼び出しで複数の検索をまとめて実行できます。詳細な読み込みを指示すると、上位の検索結果を取得し、各ページの文章をクエリとの関連度で順位付けします。そのため、リンクではなく質問への回答となる具体的な文章が得られます。失敗したプロバイダーは、設定可能なフォールバックチェーンを通じて通知なしに切り替わるため、エラーメッセージではなく検索結果が返されます。他の検索ツールでは検索エンジンが 1 つに固定されますが、Infobroker は各クエリを適切なプロバイダーに振り分け、1 つが失敗しても処理を続けます。

コンテンツの抽出

「ヤヴィンの戦いに関する記事を取得して要約してください。」 「デス・スターの設計図について書かれたページのテキストを取得してください。」 「そのレポートのどこで、リアクター・コアについて触れていますか？」

fetch_page はあらゆる URL を Jina Reader に渡し、LLM での利用に最適化された、読みやすい Markdown に変換します。Jina がアクセス制限を受けた場合は、ネイティブ HTTP にフォールバックします。Wikipedia と Internet Archive には、ソースに特化した抽出用レンダラーが用意されています。ページについて質問するには、fetch_page に question を渡します。文書全体の代わりに、回答となる箇所をスコア付けして順位付けしたうえで返します。組み込みのウェブ取得ツールは生の HTML を返しますが、Infobroker はあらゆるソースから読みやすく整形されたコンテンツを取得するため、すぐに要約や分析に利用できます。また、特定できる場合はページの最終更新日も取得結果に含めるので、ソースがどの程度新しいかを把握できます。

引用

「ハイパードライブ・フィールドの力学に関する論文の BibTeX 形式の参考文献を提示してください。」 「ハイパードライブ・フィールド方程式を初めて説明した論文を引用してください。」

get_citations は学術ソースを検索し、タイトル、著者、年、掲載誌、URL などの項目を含む、書式設定済みの BibTeX エントリーとして各参考文献を返します。参考文献リストにそのまま貼り付けられます。

プロバイダーのインテリジェンス

「デス・スターの弱点を調べるには、どのソースを使うべきですか？」 「利用可能なすべてのソースと、そのクォータ状況を表示してください。」

このサーバーは、自身の機能を把握しています。search_web は、機能、クォータ、レイテンシを考慮して、タスクに最適なバックエンドを自動で選択します。プライバシー、高速性、無料ソースのみなどの希望がある場合は、その意図に応じてルーティングします。inspect_providers を使うと、設定済みのすべてのソースを確認でき、個々のプロバイダーの稼働時間やエラー履歴も詳しく調べられます。すべてのバックエンドの運用状況を可視化できる検索 MCP サーバーは、ほかにありません。

複数ソースによる検証

「帝国が本当にオルデランを破壊したのか検証してください。」 「ハンとグリードーのどちらが先に撃ったのか、見解の一致を調べてください。」

verify_claims は複数段階の真実発見ループを実行します。最も信頼性の高いプロバイダー（検索エンジン、百科事典、学術インデックス）を横断して広範に検索し、主張を抽出してソース間で照合した後、不足を補うための追加検索を並列で実行します。結論が確定すると、早期に処理を終了します。独立したソース間で裏付けられた主張は高い確信度で評価され、各ソースの信頼性に応じて重み付けされます。また、各ソースは、それが裏付ける主張に紐付けられます。矛盾がある場合は、すべての見解とともに提示されます。不足がある場合は、検索語を調整し、ほかのプロバイダーにも検索範囲を広げます。さらに、過去の調査結果も記憶しています。ネットワークを検索する前に、ナレッジベース内の過去の調査結果が、裏付けとなるソースとして参照されます。ソースの出所、ソースごとの主張、確信度スコアを含む構造化レポートとして、確認済み、見解が分かれている、未検証の調査結果を取得できます。ほかの検索ツールがリンクの一覧を返すのに対し、Infobroker は真実を見つけ、それに対する確信度も伝えます。

ナレッジベース

「反乱同盟軍の艦隊について、これまでに見つけた情報を検索してください。」 「次回に備えて、この記事を取り込んでキャッシュしてください。」

検索、取得、照合の各処理は、すべてローカルのナレッジベースにキャッシュされます。manage_kb は外部プロバイダーに問い合わせる前にキャッシュを確認し、キャッシュされた結果の鮮度や関連性が不十分な場合にのみネットワークに接続します。手動で新しいテキストや URL を取り込む、キャッシュ済みの内容を表示する、コンテンツを削除するといった操作が可能です。コンテンツには経過時間に応じたスコアが付けられ、鮮度スケジュールに従って期限切れになり、ソースごとに重複が排除されます。取得処理は、設定可能なプロセス内埋め込みモデルを使用してお使いのマシン上で実行されます。埋め込み処理のためにコンテンツが第三者に送信されることはありません。キャッシュに加えて、manage_kb は生成したレポートもアーカイブします。source_type: "report" を指定して取り込み（デフォルトではナレッジベースに保存）、manage_kb の list と manage_kb の get で再確認できます。または、代わりにローカルディレクトリに書き出すこともできます。アーカイブされた各レポートには、ソースの最終更新日が記録されるため、ライブソースと比較して、実際に変更された内容だけを更新できます。他の検索 MCP サーバーは毎回同じ情報を再取得しますが、Infobroker はすでに見つけた情報を記憶して再利用します。

リサーチパイプライン

「デス・スターの建造について調査して、要約を作成してください。」 「ダース・ベイダーの出自に関するこれらの主張をファクトチェックしてください。」

Infobroker は検索結果を返すだけではありません。組み込みのクライアントスキルがツールを連携させて執筆パイプラインを構成し、すべてのリクエストを、適切に解決されたワークフローの形と執筆サブスキルに通して、完成した文書を生成します。すべてリポジトリ内にあり、外部パスや個別のインストールは不要です。6 つのスキル、ワークフローの形、エスカレーション経路を含むパイプライン全体については、スキルのセクションで詳しく説明しています。他の検索 MCP サーバーが検索結果を生成するのに対し、Infobroker は完成した成果物を生成します。

運用状況の可視化

「サーバーの健全性を表示してください。」 「再起動せずに設定をホットリロードしてください。」

クォータカウンターはディスクに保存され、再起動後も維持されます。レート制限は全体ではなく、プロバイダーごとに適用されます。設定は reload_config でホットリロード可能です。接続を切断せずにプロバイダーを変更したり、チェーンやしきい値を調整したりできます。また、patch を渡してバックアップを作成しつつ、ユーザーレイヤーに変更をマージすることもできます。search_web は DuckDuckGo のクエリ自動補完機能も兼ねています。inspect_providers はサーバーのビルドの健全性とリクエスト統計を報告します。検索サーバーが何を実行しているのか、残りの処理能力がどれくらいかを常に把握できます。

スキル

MCP サーバーは、製品の片方です。もう片方は、同梱のスキルです。6つのクライアントスキルがリポジトリに含まれており、外部依存も個別のインストールも不要で、調査結果を完成した成果物へと仕上げます。

オーケストレータースキル（infobroker）は、リクエストをワークフローの形に割り当てる分類ゲートから始まります。形には、調査と執筆、ファクトチェック、詳細調査、競合評価、文献レビュー、モニタリング、レッドチーム、審査、ゲート付き分析があります。それぞれの形は、ナレッジベースからの想起、検索、抽出、検証、執筆、引用という同じプリミティブを独自の順序で組み合わせ、最後に grep で検索できる完了トークンを出力するため、結果を確認できます。4つの執筆サブスキルが執筆フェーズを実行します。summarization は執筆前に調査結果を要約し、technical-writing はレポートやドキュメントの下書きを作成し、proofreading は文章を磨き、translation は多言語の出力を作成します。

ゲート付き分析は、エスカレーション用の形です。質問が重大な結果を招く可能性がある場合や、意思決定を左右する場合、分類ゲートは、軽量な調査と執筆のルートではなく、確信度を付与した調査結果、情報源の信頼性評価、適合性に基づいて選ばれ、選定理由も明示される構造化分析手法を備えた、規律ある手順であるanalysis-loopスキルへとルーティングします。同じプリミティブと Infobroker ツールを共有しながら、独自のゲート付きワークフローを実行するため、パイプラインを離れることなく厳密な分析を行えます。

単一の指示ファイルsearch-preferences.mdが、クライアントをこれらのツールへと案内します。まずナレッジベースを使い、キャッシュで不足する場合に限って外部プロバイダーを利用します。Quick Start セクションに記載された正確なスニペットを使って、このファイルとスキルディレクトリを OpenCode の設定に一度組み込めば、調査リクエストはすべて自動的にパイプラインに従います。

独自のワークフローの形を追加するには、skills/に独自のスキルを書いてください。パイプライン図はreferences/pipeline-map.mdに、ワークフローの形の定義はreferences/workflows.mdにあります。他の検索 MCP サーバーはリンクを返しますが、Infobroker には、それらを根拠を明記した回答へと仕上げる執筆ツールが含まれています。

プロバイダー

26 のプロバイダーがあり、そのうち 21 は設定不要で利用できます。

プロバイダー	ティア	種類	キーが必要
DuckDuckGo	組み込み	ウェブ検索	いいえ
Jina Reader	無料 HTTP	コンテンツ抽出	いいえ
Wikipedia	無料 HTTP	百科事典	いいえ
Wiktionary	無料 HTTP	辞書	いいえ
Wikidata	無料 HTTP	構造化データ	いいえ
OpenStreetMap	無料 HTTP	ジオコーディング	いいえ
Internet Archive	無料 HTTP	歴史的資料	いいえ
arXiv	無料 HTTP	学術	いいえ
Semantic Scholar	無料 HTTP	学術	任意
Stack Exchange	無料 HTTP	コード関連の Q&A	任意
GitHub	無料 HTTP	コード検索	任意
CORE	無料 HTTP	オープンアクセス	任意
OpenAlex	無料 HTTP	学術	いいえ
Europe PMC	無料 HTTP	学術	いいえ
Hacker News	無料 HTTP	ニュース	いいえ
GDELT	無料 HTTP	ニュース	いいえ
SEC EDGAR	無料 HTTP	財務書類	いいえ
World Bank	無料 HTTP	経済データ	いいえ
Marginalia	組み込み	小規模ウェブ	いいえ
Mojeek	組み込み	独立系インデックス	いいえ
Wiby	組み込み	小規模ウェブ	いいえ
Brave Search	API キーが必要な HTTP	ウェブ、ニュース	はい
Exa	API キーが必要な HTTP	セマンティック	はい
Tavily	API キーが必要な HTTP	統合	はい
Yep	API キーが必要な HTTP	ウェブ、セマンティック	はい
SearXNG	セルフホスト	完全なプライバシー	はい（セルフ）

組み込みプロバイダーと無料 HTTP プロバイダーは、初期状態で有効です。API キーが必要なプロバイダーは、API キーを設定すると有効になります。セルフホスト型プロバイダーは、自分で運用するサーバーを指定します。

export INFOBROKER_BRAVE_API_KEY="BSA-..."
export INFOBROKER_SEARXNG_URL="http://localhost:8080"

次に、プロバイダーの config.json で "enabled": true を設定してください。

API キーが必要なプロバイダーでは、INFOBROKER_<NAME>_API_KEYS を使って、順序付きの認証情報プールも指定できます（カンマ区切り）。Infobroker は、キーが拒否された場合やレート制限に達した場合に次のキーへ切り替え、キーの情報を決して公開することなく、inspect_providers を通じてキーごとの利用可否を報告します。

同梱されているセルフホスト型プロバイダーは SearXNG のみで、完全にオプションです。サーバーは SearXNG に依存せず、そのために同梱またはインストールされるものもありません。SearXNG はユーザーが運用するコンテナーとして動作し、Infobroker は他のバックエンドと同様にその JSON エンドポイントへクエリを送信します。無効（初期設定）のままでも失われる機能はありません。プライバシーを重視した重要な検索経路は、引き続き DuckDuckGo と Mojeek を通じて利用できます。クエリのプライバシーを完全に確保したい場合にのみ有効にしてください。その場合、クエリを確認できるのは自分の SearXNG インスタンスだけです。

設定

デプロイ環境は4つの環境変数で調整できます。INFOBROKER_CONFIG は別の設定ファイルを指定します（デフォルトは ./config.json）。INFOBROKER_CONFIG_LOCAL はユーザー設定レイヤーを指定します（デフォルトは config.local.json）。INFOBROKER_<NAME>_API_KEY はキーが必要なプロバイダーの認証情報を設定し、INFOBROKER_<NAME>_URL はセルフホスト可能なプロバイダーを指定します。

config.json はリポジトリに含まれており、デフォルト設定を保持します。有効にするプロバイダー、フォールバックチェーンでの優先順位、レート制限、相互検証のパラメーター、タスクからプロバイダーへの振り分けテーブルが設定されています。reload_config でホットリロードできます。ファイルを編集してツールを呼び出すか、patch を渡してプログラムから設定をマージしてください。変更は再起動なしで反映されます。

独自のオーバーライドは、別のユーザーレイヤー（プロジェクトディレクトリ内の config.local.json、または INFOBROKER_CONFIG_LOCAL で設定したパス）に保存します。このファイルは Git の追跡対象外のため、リポジトリから更新を取得しても設定が上書きされることはありません。ユーザーレイヤーの値は同梱のデフォルト設定より優先されます。指定されていない項目には config.json の設定が適用されます。

config.json にはスキーマスタンプ（config_version）が含まれています。ユーザーレイヤーが古いスキーマ用に作成されている場合や、現在のスキーマで認識されないキーが含まれている場合、サーバーは起動時とすべての reload_config の応答で設定の不整合を報告しますが、ファイルは変更しません。必要に応じて、migrate を true にして reload_config を呼び出し、登録済みのマイグレーションを適用してください。サーバーはまずユーザーレイヤーのコピーをタイムスタンプ付きの *.bak-* ファイルに保存し、その後アトミックに更新します。認識されない項目は変更せずに残します。

ナレッジベースは空の状態で同梱されています。検索には、kb.embedding_model で選択する、設定可能なプロセス内埋め込みモデルを使用します。デフォルトでは、ストアはリポジトリ外のユーザーごとのパス（~/.local/share/infobroker/knowledge-base）に書き込みます。そのため、調査してキャッシュしたコンテンツはマシン上に保持され、コミットされることはありません。デプロイされた各インスタンスは、それぞれ独自のストアを蓄積します。kb.store_backend では sqlite（デフォルト）または1リリース限定のレガシー json バックエンドを選択できます。レガシーの vector-store.json ストアを開くと、自動的に移行され、元のファイルは vector-store.json.migrated-<timestamp> として保持されます。JSON バックエンドへのロールバックは、暗号化が一度も有効化されていない場合に限り可能です（暗号化を有効化すると、平文の移行アーカイブは削除されます）。

ナレッジベースの暗号化

調査レポートやキャッシュされたページには機密情報が含まれる可能性があり、ナレッジベースはそれらをホームディレクトリ内の SQLite データベース（および -wal／-shm のサイドカーファイル）に保存します。kb.encryption ブロックを追加し、キーを指定すると、オプションの保存時暗号化を有効にできます。

{
  "kb": {
    "encryption": { "enabled": true, "key_file": "~/.config/infobroker/kb.key" }
  }
}

キーのファイル（平文、0600）は、MCP クライアントやオペレーティングシステムを問わず最も確実な方法です。INFOBROKER_KB_KEY（32 バイトのキー）または INFOBROKER_KB_PASSPHRASE（パスフレーズ）も使用できます。openssl rand -base64 32 でキーを生成できます。暗号化により、キーを持たずにファイルを入手した第三者から、ストアやディスクに保存されたレポートを保護できます。たとえば、デバイスの盗難、バックアップやクラウド同期からの漏えい、ほかのローカルアカウントからのアクセスが該当します。ただし、同じマシン上の悪意ある MCP クライアントやマルウェアからは保護されません。それらはフルディスク暗号化で保護されます。

安全性を保つためのルールが2つあります。まず、暗号化は任意で有効にする機能です。キーが見つからない場合や正しくない場合、ナレッジベースはロックされ、データに手を加えることなくエラーを報告します。そのため、キーをバックアップしてください（キーやパスフレーズを忘れると、仕様上ストアを復旧できません）。次に、サーバーが不完全なファイルを書き込むことはありません。すべての保存はアトミックに行われ、認識できない形式や新しい形式のストアが上書きされることもありません。

manage_kb ツールの encryption アクションが、この一連の操作を日常的に行うための窓口です。秘密情報がそのまま返されることはありません。generate_key と backup が返すのはファイルパスであり、rekey はキーそのものではなくキーのファイルを読み込みます。

キーを生成してバックアップし、kb.encryption ブロックを追加して再読み込みすると、有効化できます。ストアはその場で暗号化されます。ブロックを削除して再読み込みすると、無効化できます。ストアはその場で平文に復号されます（サーバーがストアを読み取って復号できるよう、移行中はキーを使用できる状態にしておいてください）。ロックされたストアを復旧するには、status で状態を確認し、verify で候補のキーを確定前に検証し、backup でキーのファイルのコピーを復元し、rekey で内容を失わずに新しいキーへ移行します。キーの再設定後は、kb.encryption.key_file に新しいキーを指定して再読み込みし、続けて verify を実行して新しいキーでストアを開けることを確認してください。

infobroker_manage_kb action=encryption operation=generate_key key_file=~/.local/share/infobroker/keys/kb.key
infobroker_manage_kb action=encryption operation=backup    key_file=~/.local/share/infobroker/keys/kb.key.bak
infobroker_reload_config

ツール経由でのキー操作（generate_key、backup、rekey の移行先）は、キー用ディレクトリ内に限定されます。kb.keys_dir が設定されている場合はそのディレクトリ、設定されていない場合はナレッジベースの保存先と同階層にある keys ディレクトリ（デフォルトでは ~/.local/share/infobroker/keys）が対象です。このディレクトリの外にあるパスは拒否されます。kb.encryption.key_file の設定値は運用担当者が管理するため、この制限の対象外です。

有効化する場合は再読み込みの前に config.local.json へ kb.encryption ブロックを追加し、無効化する場合は再読み込みの前に削除してください。ストアがロックされている場合でも、ロックを解除する前に復旧できるよう、status、verify、rekey は引き続き使用できます。

コンテンツポリシー

Infobroker はオープンウェブを読み取り、取得した内容をキャッシュするため、取得したコンテンツは保存前に（最も厳格なモードでは、返却前にも）設定可能なポリシーに照らして評価されます。このポリシーは、ヒューリスティックなカテゴリに該当するコンテンツ（プロンプトインジェクションの指示、認証情報のフィッシング、マルウェア／エクスプロイト関連の情報、成人向けコンテンツ）にフラグを付け、外部評価サービスが設定されている場合はそれも利用できます。デフォルトでは flag モードで有効です。フラグが付いたコンテンツは、正当な調査のために引き続き返却されますが、ナレッジベースには決して書き込まれず、すべてのフラグが監査ログに記録されます。

{
  "content_policy": {
    "mode": "flag",
    "threshold": 0.2,
    "patterns": { "prompt_injection": ["ignore previous instructions"] }
  }
}

モード：off は評価を無効にします。flag（デフォルト）はフラグ付きコンテンツを返却しますが、保存しません。block はフラグ付きコンテンツを呼び出し元に返しません。threshold は感度を調整します（0～1、デフォルトは 0.2 — 1 つでも一致すればフラグが付きます）。patterns は、カテゴリ名ごとに組み込みカテゴリを拡張または上書きします。external_url_env は外部評価サービスの URL を格納する環境変数を指定し、external_api_key_env は任意で、そのベアラーキーを格納する環境変数を指定します。外部サービスに接続できない場合は、組み込みの評価が適用されます。

ネットワーク接続先の拒否、ポリシーによるフラグ付け、設定の再読み込み、暗号化の切り替え、キー操作、クォータ超過などのセキュリティ関連イベントは、所有者のみがアクセスできる監査ログ output.audit_log_path（デフォルトは ~/.local/share/infobroker/audit.log）に追記されます。

独自のエンドポイントを追加する

ソースツリーに手を加えなくても、HTTP 検索エンドポイントを Infobroker プロバイダーとして利用できます。config.local.json で generic_http プロバイダーとして宣言し、ディスパッチチェーンから参照してください。

{
  "providers": {
    "my_search": {
      "tier": "generic_http",
      "capabilities": ["web_search"],
      "enabled": true,
      "priority": 20,
      "endpoint": "https://api.example.com/search",
      "query_param": "q",
      "results_path": "data.items",
      "field_map": { "title": "name", "url": "link", "snippet": "summary" }
    }
  },
  "dispatch": { "general_web": ["my_search", "duckduckgo"] }
}

サーバーは endpoint?query_param=<query> に GET リクエストを送り、results_path（ドット区切りでレスポンス JSON をたどるパス）を参照して、field_map を使い各結果を共通形式にマッピングします。スラッグを config.local.json のオーバーライドに追加し、reload_config を呼び出すと、すぐに利用できます。

プロバイダーごとのステータスと情報源

config.json にある次の 2 つのキーで、プロバイダーごとの動作を任意に調整できます。

• degraded_latency_ms — 最近の平均レイテンシーがこのミリ秒数を超えるプロバイダーは、到達可能な状態でも、inspect_providers ヘルスアクションで degraded と報告されます。プロバイダー側で指定されていない場合は、グローバル設定の output.degraded_latency_ms が代わりに使われます。
• resells — 他のパブリッシャーのページを表示する検索エンジン（DuckDuckGo、Brave、SearXNG など）を含むアグリゲーター／再販業者バックエンドでは、true に設定します。基盤となる API が情報を公開している場合、サーバーは各結果の original_source を報告します（例：Brave の profile 名）。Wikipedia や arXiv などの一次情報源では、ページ自体が情報源のため、空のままになります。

ヘッジ付きフォールバック

search_web と fetch_page は、遅いプロバイダーのタイムアウトまで待つのではなく、ヘッジ付きでフォールバックします。最初に選ばれたプロバイダーがレイテンシーに基づいて決まる時間だけ単独で動作し、その後、残りのプロバイダーが競合し、最初の結果が採用されます。通常は 1 回のプロバイダー呼び出しで済み、最初のプロバイダーが遅い場合や失敗した場合にのみヘッジが発動します。fetch_page ではさらに、短い猶予時間内は最初のプロバイダーのレンダラーを優先し、やや遅い jina が品質の低い native_fetch に置き換えられないようにします。レンダラーがボット対策のチャレンジページ（対象ページではなく CAPTCHA や認証の中間ページ）を返した場合、そのレンダリングは失敗として扱われます。そのため、fetch_page はチャレンジページをコンテンツとして返さず、次のレンダラーにフォールスルーします。 ウィンドウは output.hedge_enabled、hedge_min_delay_ms、hedge_max_delay_ms、hedge_grace_ms で調整できます。逐次チェーンを使うには、hedge_enabled を false に設定します。レート制限またはボット対策のレスポンスを返すプロバイダーは、プロバイダーごとのクールダウン（output.rate_limit_cooldown_ms）に入ります。これにより、リクエストが集中しても同じプロバイダーへの再試行が繰り返されなくなります。また、general_web 以外のチェーンを使い切った場合、サーバーは失敗とする前に general_web チェーンを再試行します。

比較

ツール名	おなじみの機能	Infobroker の違い
組み込みの websearch / webfetch	検索エンジンは1つ、取得モードは1つ、設定不要、使用されるバックエンドを確認できない	設定不要の21種類のプロバイダーを、統一されたツールインターフェースで利用できます。タスクごとに適切なソースを選べます。失敗時は自動的にフォールバックします。すべてのプロバイダーのステータスとクォータを確認できます。
生の API 呼び出し	HTTP リクエストの手動送信、プロバイダーごとの認証とレスポンス解析、フォールバックなし、クォータ追跡なし	すべてのプロバイダーに対応する単一のインターフェースです。API キーの設定は一度だけです。結果は共通形式に正規化されます。レート制限とクォータは自動的に追跡されます。
専用の検索 API	クエリごとの課金、ベンダーロックイン、不透明なルーティング	無料優先の設計です。DuckDuckGo、Wikipedia、その他19種類のプロバイダーを設定不要で利用できます。Brave、Exa、Tavily、Yep へのアップグレードにも対応します。プライバシーを最大限に確保できる、セルフホスト可能な SearXNG も利用できます。
その他の検索 MCP サーバー	単一プロバイダーに特化、フォールバックなし、裏付け確認なし、執筆パイプラインなし	複数のプロバイダーに対応し、自動的にフォールバックします。裏付け確認エンジンが独立したソースを相互参照します。同梱の執筆スキルにより、調査結果を完成した文書に仕上げられます。
検索機能を内蔵した AI	モデルが検索エンジンを選択し、古いキャッシュを返す。再現性がない	プロバイダーチェーンを自分で制御できます。クエリは再現可能です。フォールバックの動作も確認できます。裏付け確認エンジンが、独立したソースをもとに事実を検証します。

他の検索 MCP サーバーは、プロバイダーを選んで信頼するよう求めます。 Infobroker は複数のプロバイダーを揃え、タスクごとに適切なものを選びます。 プロバイダーに障害が発生すると、気づかないうちに次のプロバイダーへ切り替わります。 主張の検証が重要なときは、裏付け確認エンジンが一致点、 矛盾点、情報の欠落を見つけます。同梱のスキルが、生の調査結果から 完成した文章に仕上げるまでを一貫して支援します。1つのサーバーで、 すべてのソースを利用できます。成果につながる調査を実現します。

最終更新日：2026-10-22。

貢献

• Node.js 24 以降。 node --version。入手先： nodejs.org。
• npm install && npm run typecheck
• skills/ に独自のスキルを追加して、調査パイプラインを拡張できます。
• README の構造を検証：npm run validate-readme
• バージョン管理： CalVer（YYYY.MM.DD）。npm run version-bump を実行すると、 今日の日付がすべてのバージョン表記に反映されます。コミット前フックで整合性を 確認します。npm run push でチェック、タグ付け、プッシュを行います。
• MCP プロトコル：modelcontextprotocol.io
• プロバイダー：DuckDuckGo · Jina Reader · Wikipedia API

正式なリポジトリ：git.gay/flukeatzerocool/Infobroker。この GitHub リポジトリは読み取り専用のミラーです。

ライセンス

MIT。自由に使用、変更、再配布できます。同梱のクライアントスキルと 指示ファイルも同じライセンスで提供されるため、サーバー、スキル、 ドキュメントを含む調査パイプライン全体を、商用および オープンソースのプロジェクトで自由に再利用できます。サードパーティのプロバイダーには、 各プロバイダー独自の利用規約と API キーが適用されます。

仕様

サーバーは単一のソース仕様 infobroker.md （v2026.10.22）に基づいて構築されています。この仕様では、すべての要件と、 それらを検証するゲートが定義されています。各要件は実装ファイルに対応しており、 npm run check によってコード、仕様、README の整合性を確認し、文書に記載された内容が サーバーの実際の機能と一致していることを検証します。ルーティングゲートは、 引用されたすべてのツールと操作をライブスキーマと照合し、登録済みの各ツールが 少なくとも1回は引用されていることを必須とします。