OSINTダッシュボードにWorld Monitorが選ばれる理由と類似OSSとの違い

OSINT ダッシュボードの OSS を探していると、ここ最近急激に注目度を上げているリポジトリのひとつが koala73/worldmonitor（公式名: World Monitor）です。スター数はすでに 60,000 を超え、地政学・金融・インフラ・気候・サイバーといった複数領域のリアルタイムシグナルを 1 つの「Situational Awareness Interface（状況認識インターフェース）」に統合するという思い切ったポジショニングを取っています。

一方で、OSINT 領域には WorldView・Osiris・Shadowbroker など類似 OSS が複数存在しており、「自プロジェクトに採用すべきか」「類似リポジトリとどう違うか」「メンテナンス状況は健全か」と迷うエンジニアや分析者は少なくありません。情報量の多い README だけでは、機能カタログは把握できても採用判断には踏み込みにくいのが実情です。

本記事では、World Monitor の機能とアーキテクチャを README と公式ドキュメントから整理した上で、類似 OSS との差分、技術スタックの独自性、自己ホストやライセンス上の検討事項を解説します。最後に、採用判断のためのチェックリストもまとめます。OSINT ダッシュボード OSS の選定で迷っている方が、World Monitor を採用すべきか別の選択肢を検討すべきかを判断するための材料として活用してください。

なお本記事は動作検証は行わず、リポジトリトップ（koala73/worldmonitor）と公式ドキュメントの記述に基づいて整理しています。

World Monitor とは何か

プロジェクトの背景と作者

World Monitor は、音楽配信サービス Anghami の共同創業者兼 CTO（最高技術責任者）である Elie Habib 氏が個人プロジェクトとして公開している、リアルタイム全球インテリジェンスダッシュボードです。リポジトリのトップ（koala73/worldmonitor）には「Real-time global intelligence dashboard. AI-powered news aggregation, geopolitical monitoring, and infrastructure tracking in a unified situational awareness interface」と説明があり、地政学・インフラ・金融などの複数領域を 1 枚のダッシュボードで把握することを目的としています。

ライセンスは AGPL-3.0-only として配布されています。GitHub API 上のライセンスフィールドは NOASSERTION と返りますが、README およびリポジトリ内ライセンスファイルでは AGPL-3.0-only である旨が明記されています。コピーレフトとソース開示義務を伴うため、自己ホスト・改変・商用利用のいずれを選ぶ場合でも、ライセンス条件は早い段階で確認する必要があります。

リポジトリの主要指標とポジショニング

リポジトリのメタ情報を整理すると、スター数 60,697、Fork 数 9,463、最終 push 日時は 2026-06-28 となっており、活発にメンテナンスされている状態です。主要言語は TypeScript で、archived および fork のいずれも false、disabled も false であり、独立した通常リポジトリとして運用されています。フォーク派生でもアーカイブ済みでもないため、本家のメンテナンス継続を前提に検討できます。

ポジショニングとして特徴的なのは、単なる「ニュース集約サイト」や「地図ビューア」ではなく、「Situational Awareness Interface」、つまり状況認識のための統合インターフェースを名乗っている点です。後述する CII v8（Country Instability Index）や Finance radar など、ドメイン横断のシグナル合成指標を内部に持っており、ニュース・市場・地政学イベントを「並べて見る」のではなく「相関を検出する」ことを志向しています。

主要機能とアーキテクチャ

ここでは README とアーキテクチャドキュメントに記載された主要機能を、分析者が実務でどう使うかという視点で整理します。

AI 駆動のニュースアグリゲーションと CII v8

World Monitor は、500 を超えるキュレーション済みニュースフィードを 15 カテゴリで集約し、AI でブリーフに合成します。単純に記事を並べるのではなく、軍事・経済・災害・エスカレーションシグナルの収束を検出する「クロスストリーム相関分析」を備えている点が特徴です。

国別の不安定度を可視化する Country Instability Index（CII v8）は、unrest（騒擾）/ conflict（紛争）/ security（治安）/ information velocity（情報速度）の 4 つの加重コンポーネントに分解されており、それぞれの次元的独立性を強制することで「ヘッドラインアンカリング」（特定の見出しに引きずられて全指標が同じ方向に振れる現象）を回避するよう設計されています。さらに ACH（Analysis of Competing Hypotheses）的な多ソース照合や、Welford のオンライン算法でローリング 2 時間ウィンドウと 7 日ベースラインの偏差を検出する仕組みも組み込まれています。

デュアル地図エンジンと 56 のマップレイヤー

地図表示には 3D グローブ（globe.gl）と WebGL フラットマップ（deck.gl）の 2 つのエンジンを使い分けるデュアル構成を採用しています。マップレイヤーは 56 種類にわたり、軍事・船舶・航空・気象・地震・サイバーなど領域を超えて重ね合わせることができます。

リアルタイム性を保ちながら、ブラウザ側で大量のシグナルを描画する必要があるため、後述する Web Worker でのクラスタリングや ONNX Runtime のフォールバック戦略といった工夫が随所に盛り込まれています。

6 サイトバリアントの単一コードベース運用

World Monitor のユニークな点として、単一コードベースから world / tech / finance / commodity / happy / energy の 6 つのサイトバリアントを生成・配信できる構造があります。Vercel 上の単一デプロイがホスト名検出で出し分けを行うため、運用面でも管理コストが膨らみにくい設計です。

複数のユースケース別ダッシュボードを「別アプリ」として構築すると、コード重複と保守コストが嵩みます。世界全体監視（world）、テックインフラ（tech）、金融市場（finance）、商品市場（commodity）、ポジティブニュース特化（happy）、エネルギー（energy）といった切り口を、同一の技術基盤で運用できることは、組織内で複数チームに横展開する際に効きます。

Tauri 2 によるデスクトップ + Web + PWA の三層配布

クライアントは Tauri 2 ベースでネイティブデスクトップアプリとしても配布されており、macOS / Windows / Linux に対応します。同じ TypeScript コードベースが、Web（Vercel）、Relay（Railway）、Desktop（Tauri）、PWA という 4 つの実行形態へコンパイルされる設計です。

デスクトップ版では、クラウド側の API ハンドラをローカルでミラーする sidecar（サイドカー）プロセスが動作し、トークン認証経由で同一の API 契約を再現します。これにより、オフラインや回線品質が安定しない環境でも一定の機能を維持できる構造になっています。

技術スタックと内部設計の特徴

公式のアーキテクチャドキュメントを読むと、World Monitor は「フレームワーク非依存」「Proto-first」「3 階層キャッシュ」「適応的ポーリング」といった、いくつかの独特な設計選択を組み合わせていることが分かります。README の Tech Stack 説明も合わせて整理します（出典: koala73/worldmonitor）。

フレームワーク非依存の vanilla TypeScript

World Monitor のフロントエンドは React や Vue を使わず、vanilla TypeScript + 直接 DOM 操作で実装されています。コンポーネントライフサイクルはカスタム Panel 基底クラスが提供し、状態の分散は localStorage と CustomEvent で実現する設計です。マーカーの型安全性は _kind フィールドを用いた判別共用体（discriminated union）で確保しており、15 以上のマーカータイプを扱えるようになっています。

モダンなフロントエンドフレームワークが主流のなかで vanilla TypeScript を採用するのは異色ですが、地図と多数のレイヤーを高頻度で更新する用途では、フレームワーク由来の抽象化オーバーヘッドを排除する選択は理に適っています。一方で、Panel 基底クラスや独自イベント設計の理解が必要になるため、コントリビュータ側の学習コストはやや高めと言えます。

Protocol Buffers ベースの API 契約と OpenAPI 生成

バックエンドは Protocol Buffer ファイルで 34 サービスドメインを定義しており、合計 276 個の .proto ファイルから TypeScript クライアント・サーバスタブ・OpenAPI 3.1.0 ドキュメントを生成する Proto-first 設計です。

per-domain edge functions（ドメインごとのエッジ関数）を採用することで、モノリスを廃して各ドメインを独立にスケールさせる構造を取っており、コールドスタートを約 85% 削減したと公式ドキュメントは説明しています。前述の通り、単一の Vercel デプロイで 6 つのバリアントを配信する設計も、この edge functions ベースの分割に支えられています。

3 階層キャッシュと Circuit Breaker

データ取得層は、In-memory → Redis（Upstash） → Upstream API の 3 階層キャッシュ構成です。In-flight promise deduplication によって同一リクエストの重複発火を防ぎ、サンダリングハード現象を抑止します。per-feed circuit breaker（5 分クールダウン）で連鎖障害を防ぎ、エラー状態を sentinel として保存する negative caching も組み込まれています。

さらに /api/bootstrap エンドポイントが、頻繁にアクセスする 38 個のデータセットを Redis pipeline で先読みする Bootstrap Hydration を提供しており、コールドスタートレイテンシを 2〜4 秒短縮するという記述があります。SmartPollLoop と呼ばれる適応的ポーリング機構もあり、失敗時の指数バックオフ、非アクティブタブでの 5 倍スロットル、Intersection Observer によるパネル非表示時の一時停止などを組み合わせています。

ローカル AI（Ollama）対応とブラウザ ONNX のフォールバック

AI 機能は、Ollama を使ったローカル AI 実行に対応しており、API キーが不要な構成を取れます。サードパーティの LLM API に依存しないため、機密度の高い情報を扱う組織でも導入の障壁が下がります。

ブラウザ側の推論には ONNX Runtime が組み込まれており、WebGPU → WebGL → WASM+SIMD という能力検出のカスケードで、環境ごとに最適なバックエンドへ自動的にフォールバックします。CPU 集約的なクラスタリング処理（O(n²)）や相関検出（O(n×m)）は Web Worker で実行し、メインスレッドのブロックを避ける設計です。

類似 OSS との比較と World Monitor が選ばれる理由

ここからが本記事の中核です。OSINT/インテリジェンスダッシュボード OSS は World Monitor だけではないため、類似プロジェクトとの比較を整理します。

主要な類似 OSS との比較表

World Monitor が「選ばれる」3 つの理由

比較表を踏まえて、World Monitor を採用する場面で効く差別化ポイントを 3 つに整理します。

1 つ目は、6 バリアントの単一コードベース運用です。world / tech / finance / commodity / happy / energy という 6 種のサイトを 1 つの TypeScript リポジトリで運用できる点は、組織内で複数チームに横展開する際に大きく効きます。他 OSS の多くは単一ドメイン特化（マップ性能特化、戦術追跡特化、コモディティ特化など）であり、同一コードベースで複数ユースケースを切り替える設計は珍しいアプローチです。

2 つ目は、ローカル AI（Ollama）対応による完全オフライン分析です。クラウド AI を前提とする競合 OSS に対し、World Monitor は外部 API キー不要で AI ブリーフを生成できる構成を取れます。情報の社外送信に制約のある組織や、回線が安定しない環境でも導入しやすい設計です。

3 つ目は、経済・地政学・インフラの統合カバレッジです。CII v8 による国別不安定度スコアリングと、Finance radar による 29 取引所・コモディティ・暗号資産・7 シグナル合成指標を 1 つのダッシュボードで扱える OSS は他にあまりありません。「軍事と市場を同じ画面で見たい」「サプライチェーンとエネルギー需給を相関で捉えたい」という要求に応えやすい構造です。

逆に他 OSS が適する場面

ただし、World Monitor が常に最適というわけではありません。3D マップの描画性能を最優先したい場合は GPU 加速に振った Osiris が向きます。FastAPI + Celery のような Python ベースのサーバ集約処理に寄せたい場合は WorldView がフィットします。航空機・船舶・衛星のテレメトリ統合を中心に据えたいなら、世界各地のセンサー系シグナルを束ねた Shadowbroker が候補になります。

戦術的な紛争追跡やコモディティ・choke point の監視といった、より特化したユースケースであれば、OSINT War Room や GeoPulse のような専門 OSS のほうが、自前カスタマイズの起点として軽量に始められるケースもあります。

セルフホストとライセンス上の検討事項

World Monitor を実際に導入するとなると、どの配布形態で動かすか、ライセンス条件をどう扱うか、外部データソースの API キーをどう用意するかを整理する必要があります。公式のセルフホスティングガイドを踏まえて要点をまとめます。

Quick Start の概要

README には Quick Start として、以下のような起動手順が示されています（出典: koala73/worldmonitor）。

git clone https://github.com/koala73/worldmonitor.git
cd worldmonitor
npm install
npm run dev

このまま動かす場合でも一定の機能は使えますが、地政学・市場・航空・船舶などの実データを取り込むには、後述の .env で各種データソースの API キーを設定する必要があります。Quick Start はあくまでローカル開発用であり、本番運用には別途の構成が前提です。

配布形態の選択肢

セルフホスト時の配布形態は大きく 4 通りに分けられます。1 つ目は Vercel デプロイで、edge functions と組み合わせた最も標準的なオプションです。2 つ目は Docker による自前ホストで、社内ネットワーク内に閉じた環境を作りたい場合に向きます。3 つ目は 静的サイト + Relay 構成で、API 層を Railway 等の Relay にオフロードします。4 つ目は Tauri デスクトップアプリで、社内のアナリストごとに端末で動かす運用も可能です。PWA としてもインストール可能なため、モバイル端末を含む配布も視野に入ります。

AGPL-3.0-only の意味と商用利用時の判断軸

ライセンス条件は AGPL-3.0-only であり、以下の点を採用前に確認する必要があります。1 点目は、コピーレフト義務として、改変版を SaaS としてネットワーク経由で提供する場合にもソース開示義務が発生する点です。2 点目は、自社内部での利用や、研究・教育・自己ホストでの利用は、AGPL 順守の範囲内で問題ない点です。3 点目は、商用 SaaS として展開する場合に AGPL の条件が現実的に飲めない組織のために、商用ライセンスが別途用意されている点です。

著作権表記は 2024-2026 Elie Habib となっており、商用ライセンスについては公式サイトの問い合わせ経路から確認する流れになります。「自社内部ツール」「クライアントへの SaaS 提供」「フォークして再配布」のどれを想定するかで、求められる対応が変わるため、法務部門との早期確認をおすすめします。

追加データソースの API キー要件

外部データソースについては、README の .env.example に必要な環境変数の一覧が示されています。例えば航空券データの TRAVELPAYOUTS_API_TOKEN のように、提供元ごとに個別のキー取得が必要になります。

データソースカタログを見ると、65 以上の外部プロバイダ・API が接続候補として整理されており、領域は地政学・金融・エネルギー・気候・航空・サイバー・軍事・インフラ・ニュースインテリジェンスにわたります。すべてを有効化する必要はないため、自組織で必要な領域から段階的に有効化していく運用が現実的です。

採用判断のためのチェックリスト

ここまでの内容を踏まえ、World Monitor を採用すべきかを判断するためのチェックリストを整理します。あわせて、メンテナンス健全性も最後に再確認します（メンテナンス状況はリリース履歴から定期的に確認できます）。

採用が適する 4 ケース

以下のいずれかに該当する場合、World Monitor は有力な候補になります。

1 つ目は、自前で OSINT 環境を構築したいケースです。商用 SaaS ではなく自組織で運用したい場合、AGPL-3.0 順守を前提に内部利用するシナリオでフィットします。2 つ目は、マルチドメインのダッシュボードを単一基盤で運用したいケースです。世界全体監視・金融・エネルギー・コモディティなど複数の切り口を横展開したい組織で、6 バリアントの単一コードベース運用が効きます。3 つ目は、オフライン AI 分析が必要なケースです。社外送信に制約のある情報を扱う組織や、外部 LLM API への依存を避けたい場合、Ollama 連携によるローカル AI 構成が選択肢になります。4 つ目は、AGPL-3.0 を順守可能な組織です。コピーレフト義務を組織として受け入れられるか、または商用ライセンスを取得する余地がある場合に進めやすくなります。

採用を見送るべき 2 ケース

逆に、以下に該当する場合は別の OSS や商用製品を検討したほうが無理のない選択になります。

1 つ目は、プロプライエタリな商用展開が前提で AGPL を回避したい場合です。商用ライセンスの取得経路はあるものの、契約条件が読めない段階での着手はリスクが高くなります。2 つ目は、既存スタックが React/Next.js に強く依存している場合です。vanilla TypeScript + Panel 基底クラスへの移行や並走には学習コストがかかるため、既存資産の流用を最優先したい組織には合わないことがあります。

メンテナンス健全性の確認方法

採用判断の最後に確認しておきたいのが、リポジトリのメンテナンス状況です。本記事執筆時点では、スター数 60,697、Fork 数 9,463、最終 push 日時 2026-06-28 と、活発に開発が続いている状態でした。archived=false・fork=false であり、本家リポジトリとしてのメンテナンスが継続している点も確認できます。導入を決める前に、最低限以下の 3 つを再確認することをおすすめします。

1 つ目は、リリース履歴で直近 3 ヶ月以内にバージョンが切られているかです。2 つ目は、リポジトリトップの「Insights」タブから直近 1〜2 ヶ月のコミット頻度を確認することです。3 つ目は、コントリビュータ数と Issue / Pull Request の応答ペースです。これらが健全であれば、AGPL 順守を前提に PoC を進めても、メンテナンス停止リスクは比較的低いと判断できます。

OSINT ダッシュボード OSS の選定では、機能の多さよりも「自組織のユースケースと運用条件に合うか」が最も重要です。World Monitor が打ち出している「6 バリアントの単一コードベース」「ローカル AI 対応」「経済・地政学・インフラの統合カバレッジ」が、自プロジェクトの要件と噛み合うかを軸に、本記事のチェックリストを採用判断の起点として活用してください。