Odysseus AIのプライバシー：モデル、データ、通信のリスク

Odysseus AIのプライバシー：四つの境界

セルフホストにするとワークスペースを運用する主体は変わりますが、作業に関わるほかの相手がすべて消えるわけではありません。端末やサーバー上の保存場所、プロンプトを受け取るモデル、機能が接続する外部サービス、アプリに到達できるネットワーク利用者という四つの境界に分けると整理しやすくなります。それぞれが別のプライバシー上の問いに答えます。

ローカルモデルなら、ホスト型モデル企業へプロンプトを送らずに回答できる場合があります。しかし検索機能は SearXNG と検索エンジンへクエリを送ることがあり、カレンダー連携は設定したサーバーと通信します。リバースプロキシや公開ポートも、推論場所とは関係なく接続可能な人を変えます。セルフホストを一つのプライバシー設定とみなさず、各入力をどのコンポーネントが受け取るか確認してください。

ローカルモデルを使うと端末に何が残るか

Odysseus AI の公式セキュリティページは、Ollama、llama.cpp、vLLM などのローカルバックエンドでは、プロンプトと回答はハードウェア内に留まると説明しています。また、会話、ドキュメント、メモリ、メールキャッシュはアプリの `data/` ディレクトリに保存されると記載しています。ローカル推論なら、プロンプトや応答をリモートの推論事業者へ送らずに済む可能性がある、という説明の根拠です。

ただし範囲を区別する必要があります。ローカルモデルが示すのは推論先であり、アプリの全機能の通信先ではありません。ウェブ調査、単発のクラウド推論、メールやカレンダーの同期には別の送信先があります。OS、バックアップ、ディスク、ブラウザー、管理者も信頼境界に含まれます。ローカルに保存しても、アクセス制御とバックアップ方針は必要です。

公式ページは、プロジェクトにテレメトリーや自動接続型の分析機能がないとも述べています。これはプロジェクトの声明であり、事業者の保存期間、ホストのログ、変更を加えたすべての構成を独立に測定した保証ではありません。

連携機能がデータを送る場所

連携機能を有効にしたときのOdysseus AIのプライバシーは、操作によって変わります。公式資料では、クラウドモデル事業者には送信したプロンプトが届き、ウェブ検索のクエリは SearXNG を通って検索エンジンへ送られ、メールや CalDAV の同期は設定したサーバーと通信すると説明されています。想定されたデータ経路の説明であり、すべての要求がすべてのサービスへ複製されるという意味ではありません。

機密情報を扱う前に、選択中のモデルのエンドポイント、検索の有無、接続済みアカウント、ツールが外部に作用するかを確認します。下の画像は概念図です。画像から個別環境の挙動を推測するのではなく、利用する機能と実際の設定を照合してください。

ネットワーク公開は別のリスク

ローカルで動くモデルがワークスペースの閲覧者を決めるわけではありません。公式セキュリティページによると、Docker ではアプリ、ChromaDB、SearXNG、ntfy の四つが既定で `127.0.0.1` にバインドされます。`APP_BIND=0.0.0.0` は意図した LAN やリバースプロキシで使う設定とされ、許可オリジンも合わせる必要があります。待受先を変えることは到達範囲を変えることであり、安全性を自動で高める設定ではありません。

プロジェクトの脅威モデルは、Odysseus を信頼できる利用者がいるプライベートネットワーク向けと説明し、管理者コンソールのように扱うよう求めています。認証のない公開サービスとして運用しないでください。内部ポートを非公開にし、インターネットへの直接ポート転送を避けます。リモート接続には、環境に適した Tailscale、Cloudflare Access、WireGuard などのプライベートアクセス層を使います。

localhost の外から接続する場合は、プロキシ、HTTPS、許可オリジン、認証、ファイアウォールを一緒に確認します。バインド設定がどのサービスに適用されるか読み、コンテナのポートマッピングを広げて検索やデータベースまで公開しないようにしてください。

アカウント、管理者、ツール権限

公式資料は、複数ユーザーのロール、TOTP 二要素認証、パスワードのハッシュ化、セッション検証、特権ツールの管理者限定を説明しています。ローカル開発以外では認証を有効にし、localhost bypass を無効にするよう推奨しています。こうした制御は不正アクセスを減らせますが、管理者がアカウントに与えられた強力な機能を使うことまでは防ぎません。

この点は脅威モデルにも明記されています。ログインした管理者はシェルコマンドを実行し、ファイルを読み書きし、メールを送信し、モデルサービスを制御できます。文書が防止対象とするのは、未認証アクセス、権限境界の突破、外部コンテンツからのプロンプトインジェクション、内部サービスの外部公開です。管理者が意図された権限を行使することは対象外です。

脅威モデルは、ウェブページやメールなど信頼できない入力に対するツール承認とプロンプト保護も説明します。これは有用な防御ですが、すべての攻撃が不可能という証明ではありません。日常作業には非管理者アカウントを使い、管理者を限定し、漏えいした認証情報やトークンを交換します。

実際の作業前に行うプライバシー確認

個人アカウントを接続したり、機密情報を置いたりする前に、短い確認を行います。目的は経路を理解し、不要な公開を減らすことであり、インストールを安全認証することではありません。まず低リスクのテストを行い、どのサービスが動くかを確認してください。

1. 推論エンドポイントを選ぶ

   モデルがローカルかホスト型かを確認します。ローカルなら、指定先が自分で管理する Ollama、llama.cpp、vLLM のサービスか検証してください。

2. 連携機能を見直す

   検索、メール、カレンダー、通知、リモートモデルを列挙します。不要な機能を無効にし、有効な機能ごとに送信先を確認します。

3. アクセスを限定する

   認証を維持し、開発以外では localhost bypass を避けます。通常作業は一般アカウントを使い、必要な人にだけ管理者権限を与えます。

4. ポートとプロキシを確認する

   loopback のみで待ち受けるサービスと LAN 公開のサービスを区別し、リモートアクセスには意図したプライベート層を使います。

5. ローカルデータを守る

   `data/` のアクセスを制限し、バックアップの保存場所を把握します。コピーしたアーカイブも稼働中のホストと同じように保護します。

6. 機密でない入力で試す

   無害なモデル要求を実行し、送信先、認証、ツール承認が意図どおりか、実作業の前に確認します。

Odysseus AIのプライバシーは用途で変わる

同じインストールでも、作業ごとにプライバシー特性は異なります。ローカルファイルをローカル推論で要約する場合、クラウドモデルへ送るプロンプトより外部経路は狭くなりますが、アカウントやホストへアクセスできる人には注意が必要です。ウェブ調査なら検索事業者が加わり、メールならアカウントサーバーと操作権限が加わります。

チームでは、アプリがセルフホストかどうかだけを基準にしないでください。ローカル推論に使えるデータ、承認済み事業者へ送れるデータ、管理者の許可が必要な連携を決めます。決定を記録し、モデルのエンドポイント、プロキシ規則、連携機能を変えた後に再確認してください。

この記事で証明できないこと

この記事は 2026 年 10 月 23 日に確認した公式セキュリティページと脅威モデルを要約したものです。侵入テスト、コード監査、法的なプライバシー評価、特定事業者の保証ではありません。テレメトリーやローカル推論に関する公式見解はプロジェクトの声明として紹介しており、ここで独立検証していません。実際の挙動は commit、設定、連携アカウント、運用にも依存するため、制御を信頼する前に最新資料と自分の環境を確認してください。