日記はローカル。AIへのリクエストはどこへ行く？

モデル名より先に経路を見る

今回確認したMemexクライアントは、モデル設定でクライアントの種類、モデル、対応する接続方式のベースURLを選びます。エージェントごとの設定または既定の設定が使われます。よく知るモデル名でも、スマホから推論までに関わるすべての組織が分かるわけではありません。

下図はモデルへのリクエスト経路であり、アプリやOSの全通信を示すものではありません。有効なワークフローがいつモデル処理を始めるかも確認します。記録の入力とAI処理が一つのやり取りに含まれる場合があります。応答は設定された接続を通じて戻りますが、記録とリクエストのライフサイクルは別です。

Memex：モデルクライアントの構築とエージェント別設定

送られるのは、いま入力した文章だけとは限らない

モデルが受け取るのはアプリが組み立てたリクエストです。指示、会話履歴、関連する記録、添付ファイル、前のツールの結果が含まれる可能性があります。MemexのSuperAgentのソースでは、ユーザーの記憶を文脈として状態に加え、記録の検索やファイルの読み取りツールも用意しています。

毎回すべての記録をアップロードするという意味ではありません。「一件だけ選んだ」は自分の操作についての説明であり、その実行全体が一件だけに制限されている証拠ではない、ということです。ツールを選ぶ前から記憶が文脈に入り、後のツール結果がさらに情報を加えることもあります。実際のリクエストは、その実行の状態と操作によって決まります。

Memex：SuperAgentの記憶とツール

直接接続とモデルサービスは別の選択

直接接続では、そのクライアントに設定されたプロバイダーの接続先へ送ります。互換ゲートウェイを選べば、モデル名が同じでも受信者はゲートウェイになります。自分のAPIキーを使うことだけでは経路は分かりません。実際に使われる接続先も確認します。

Memexには任意で利用するMemex AIサービスの設定もあります。クライアントはアカウントサービスからベースURLと認証情報を取得し、それを使ってモデル設定を保存します。受信するモデルサービスも処理の境界に含まれます。クライアントのコードだけでは、上流への転送、プロンプトの保管期間、学習方針は証明できません。

設定にある任意のネットワークプロキシ欄とも区別が必要です。通信のプロキシとアプリケーション層のモデルゲートウェイは役割が異なります。「プロキシ」という言葉だけでは、仲介者が復号されたプロンプトを見られるかどうかは決まりません。

Memex：任意のサービス設定 · Memex：アカウントとモデル認証情報

Ollamaのアドレスだけでは端末内推論と分からない

スマホからノートPCのOllamaへ接続すれば、リクエストを受け取るのはノートPCです。そのサーバーが選んだモデルを実際にローカルで動かしていれば、日記をスマホに置いたまま、そのPCで推論できます。接続先はスマホから到達できる必要があり、スマホのlocalhostはスマホ自身を指します。隣にあるPCではありません。

Ollamaの資料はローカルとクラウドの両方を扱い、ローカルサーバー経由でクラウドモデルを使う構成も説明しています。ローカル推論と呼ぶ前に、実際のモデルとサーバー設定を確かめます。クラウド機能を無効にする方法も公式資料にあります。モデルファイルのダウンロードは、日記を推論のために送ることとは別の通信です。

Ollama：ローカルとクラウドのAPI · Ollama：ローカル動作とクラウド設定

文字起こしがローカルでも、文章は遠隔モデルへ渡りうる

音声は、一つの録音が複数の段階を通るよい例です。確認したMemexの実装には、ローカル音声認識とクラウド文字起こしがあります。前者はダウンロード済みの端末内モデルを使い、後者は音声をエンコードして文字起こしの指示とともに、チャットエージェントの設定済みモデルへ送ります。

認識を端末で行えば、その文字起こしの段階で録音をクラウドモデルへ送る必要はありません。ただし、できた文章が次に遠隔モデルを使うエージェントへ渡される場合があります。文字起こしと後の分析は別々に確認します。テキスト専用モデルを選んでも、すべてのメディア機能が動くとは限りません。

Memex：ローカルとクラウドの文字起こし · Memex：端末内認識とモデルの取得

ツール、ログ、バックアップにも行き先がある

ローカル記録を読むことと、それをモデルへ返すことは別の操作です。遠隔ツールを含むワークフローを有効にすれば、ツール入力には別の受信者が生まれます。主なモデルを変えても、ツールの送信先が自動で変わるわけではありません。すべてがチャットの接続先へ行くと仮定せず、実際のツールを確認します。

確認したソースはローカルの診断ログも書き、ワークスペース、データベース、設定をバックアップにまとめられます。バックアップは一件のメモの書き出しより広い範囲です。診断用ファイルやバックアップには機微な情報が入る可能性があるため、共有や別サービスへの保存前に内容を確認します。

プロバイダーによる処理、保存、学習利用は別々の問題です。このソース確認では他の運営者のサーバー内部は証明できません。ローカルの一件を削除しても、送信済みのリクエストは撤回されず、バックアップも消えず、記憶された文脈も必ず消えるとは限りません。それぞれのコピーにライフサイクルと削除手段が必要です。

Memex：ローカル診断ログ · Memex：バックアップの内容

実際の記録の前に、架空の一件を追う

「火曜日にサンプルカフェで夕食」のような架空の内容を使い、本物のレシートは添えません。機能、処理するエージェント、実際のモデル接続、接続先の運営者、仲介サービスをメモします。次に、文章、履歴、記憶、メディア、ツール結果という候補を挙げます。

音声を使うなら文字起こしの設定も別に確認します。ローカル推論を意図するなら、受信ホストと実行モデルを確かめます。新しい会話は確認を簡単にできますが、記憶や検索が存在しない証明にはなりません。

未確認のことも残します。現在の保存条件、まだ特定していない下流の提供者、調べていない添付ファイルの経路などです。これは経路の一覧であり、パケットキャプチャではありません。完全な送信内容を確定するには、架空のデータだけを使い認証情報を保護しながら、制御された環境でリクエストの組み立てや通信を調べる必要があります。本記事ではその端末上の追跡は行っていません。

テスト用の経路メモ

機能と担当エージェント：
実際のモデルと接続先の運営者：
ゲートウェイやネットワークプロキシ：
含まれる文章・履歴・記憶・メディア：
ローカルかクラウドか（文字起こし）：
追加ツールの送信先：
作成されたバックアップやログ：
未確認のこと：

記録を残し、AIへ渡す仕事を選ぶ

オープンソースならリクエストの組み立てを調べられ、モデルを選べれば処理の接続先を選べます。実際の価値は、経路を確認し変更できることです。どちらの言葉も、有効な設定と使う機能の確認には代わりません。別の接続先を試すために、記録の原本をそのサービスへ引っ越す必要はありません。

今日はそれ以上分析しなくても、夕食のメモには残す価値があります。後日、小さな疑問のために、信頼するモデルへ文脈の一部を渡したくなるかもしれません。保存と分析を別々の判断として考えることで、個人の記録と役立つAIの両方を持てます。

エージェントの実行場所 · AI日記のプライバシーチェック · 自分でモデル接続を選ぶ