@bridge が高速で低コストな理由

@bridge は、あなたがすでに使っている AI — Claude Desktop、Cursor、任意の MCP 対応エージェント — を、あなたがすでに持っているメールに接続します。これをローカルで行い、メッセージ本文を第三者のクラウドサービスに一切送信しません。そして、あらゆるクラウドの代替手段よりも、測定可能な形でトークンが軽く — そして、直接操作においては測定可能な形で高速です。

このページでは、それらの数値を生み出す2つの設計上の選択を、アーキテクチャについて考察できる一方で、そっくり複製できる設計図にはならない水準で説明します。

一目でわかる比較

@bridge が2つの一般的な代替手段 — 1つのプロバイダーの API をラップするクラウド MCP（例：Gmail MCP）と、あなたのメールボックスをホストするオールインワンの AI メールクライアント — とどう比較されるか：

	@bridge	Gmail MCP	クラウドメール AI
直接アクション1回あたりの速度	約5ミリ秒（ローカル）	約110ミリ秒以上の往復	約110ミリ秒以上の往復
メールをベンダーのクラウド経由でやり取りするか	いいえ — 直接かつローカル	はい — そのクラウドへ	はい
メールプロバイダー	任意（Thunderbird 経由）	Gmail のみ	通常は Gmail / Outlook
あなたの LLM、あなたの選択	はい	はい	いいえ — 固定モデル
ブランド HTML メール作成	はい — @bridge ブランドメール	いいえ	いいえ
トークン効率が良い（HTML の肥大化なし）	はい — 既定でテキスト	いいえ — 完全な HTML を吐き出す	—
オフラインで動作	はい	いいえ	いいえ

あなたはすでに Claude、GPT、あるいは Gemini に支払っており、@bridge はそれに一切上乗せしません — 追加の API 料金も、呼び出しごとの上乗せも、あなたのプロバイダーのものに加わる当社独自のクォータもありません。@bridge それ自体は、あなたの AI プロバイダーが請求する金額とは別個の、そしてそれから独立した、シンプルな定額サブスクリプションです。このページの残りでは、速度とコストの数値の背後にある2つの設計上の選択を説明します。

私たちが比較している対象

クラウドを介したメールツール — Gmail MCP、Microsoft Graph MCP、そしてオールインワンの AI メールクライアント — は、あらゆる操作をプロバイダーのクラウド経由でやり取りします。あなたのメッセージ本文はノート PC から Google （あるいは Microsoft、あるいは他の誰か）のサーバーへ送られ、そこで処理され、結果が公共インターネット経由で戻ってきます。あらゆる操作がネットワークの往復コストを支払い、取得されるすべてのメールが、誰も求めていない HTML マークアップのためのトークン料金の上乗せを支払います。

@bridge はそのどちらもしません。

一段落で説明するアーキテクチャ

@bridge は、あなた自身のマシン上で3つの小さなプロセスを実行します — あなたの AI が呼び出すコネクター、ローカル専用のポートで待ち受ける小さなブリッジ、そして実際のメール作業を行う Thunderbird 拡張機能です。あなたの AI はコネクターとやり取りし、コネクターはブリッジとやり取りし、ブリッジは拡張機能とやり取りし、拡張機能は Thunderbird のローカルメールストアとやり取りします。このストアは、 Thunderbird がすでに使っているメールプロトコルを介して、あなたの受信箱からすでに同期されています。この経路のどの部分も、他の誰かのクラウドを通りません。 あなたの AI のリクエストは、多くても1つのループバックソケットと1つのオペレーティングシステムのパイプ — どちらもカーネル内部のメモリ内転送 — を通るだけで、Thunderbird 自身が読むのと同じメールストアに到達します。

3つの部品、1つのブリッジ、すべてローカル — 片側にあなたの AI クライアント、もう片側に Thunderbird、そしてその間に atbridge.ai が、あなたのマシン上で：

あなたの AI クライアント

Claude Desktop、Cursor、Cline、Aider、あるいはあなた自身のエージェント — あなたが選んだモデルを動かします。今や、あなたのメール、カレンダー、連絡先、ノート、タスクを、すでに使っている他のツールと同じように、読み、検索し、書き、送信し、整理できます。

atbridge.ai — ローカルブリッジ

Thunderbird 拡張機能に、作業を行うローカルブリッジを加えたもの。数分でインストールでき、あなたの AI と localhost 経由でやり取りします — インターネット経由ではありません。さらに、ローカルの markdown ワークスペースである @bridge ノートも追加します。

Thunderbird

あなたの既存の Thunderbird — 無料でオープン。任意のアカウント（Gmail、Outlook、 iCloud、IMAP）を接続でき、あなたのメール、カレンダー、連絡先、タスクはすべてここにあります。マルチアカウントは最初から機能します。

効果 1 — アーキテクチャによる高速化（ネットワークの往復なし）

これはアーキテクチャ効果です。@bridge がネットワークの往復をしないために存在します。

クラウドメールツールがリクエストを処理するとき、次のコストを支払います：

プロバイダーの API エンドポイントへの DNS 解決；
公共インターネットを越える TCP ハンドシェイク；
暗号化のための TLS ハンドシェイク；
HTTP のシリアライズと送信；
プロバイダーのインフラ内でのサーバー側処理；
戻り経路の対称的な処理。

そのネットワークの往復は、プロバイダーが何らかの作業を行う前の、あらゆる操作の下限です。@bridge はそのすべてを取り除きます。あらゆる操作は、1つのループバック TCP 接続 — オペレーティングシステムのカーネルによって、ネットワークカードを完全にバイパスするメモリ内転送として実装されます — と、2つのローカルプロセス間の 1つの標準入出力パイプを通ります。それだけです。

実測：直接操作は約20倍高速

私たちはそれを測定しました。以下の数値は代表的な実行結果です — 操作ごとに30回繰り返し、curl のオンザワイヤークロックで計測しています（いかなる言語モデル自身のレイテンシーとも独立しています；スクリプトはリポジトリにあります）。 @bridge はローカルループバックブリッジに対して実行され、クラウドのベースラインは同じマシンからの Gmail API への HTTPS 往復です：

操作	@bridge（ローカル）	クラウド往復の下限	高速化
メッセージ本文を読む（id 指定）	約5ミリ秒	約110ミリ秒	約22倍高速
フォルダーを一覧する	約5ミリ秒	約110ミリ秒	約24倍高速
アカウントを一覧する	約4ミリ秒	約110ミリ秒	約26倍高速
生存確認 ping	約2ミリ秒	約110ミリ秒	約58倍高速

2つの但し書きが、これを誠実に保ちます：

約110ミリ秒というクラウドの数値は往復の_下限_です — 何らかの作業が行われる前に返る、認証なしのリクエストです。実際の認証付き操作は、この往復に 加えてプロバイダーのサーバー側の作業（さらに、ホスト型 MCP を通す場合は 2つ目の中継ホップ）のコストがかかるため、実際の差はもっと大きくなります。私たちは意図的に下限を引用しています。
検索は除外しています。 ローカルの全文検索はメールストアのスキャンであり、転送操作ではありません。大きなメールボックスでは、クラウドプロバイダーのサーバー側インデックスに匹敵、あるいはそれを超えることもあります（対象を絞った差出人検索はここで約330ミリ秒でした）。優位性は、直接操作におけるネットワークの往復を排除したことにあります — 生の検索スループットではありません。

したがって、控えめで実測に基づく主張はこうです：直接的な @bridge の操作は 1桁ミリ秒で完了します — クラウドツールが作業を始める前にすら支払うネットワークの往復より、およそ20倍高速です。 そして、一連の操作を実行する対話的なエージェントにとって、その節約はチェーン内のあらゆる呼び出しにわたって 積み重なります。

なぜこれが重要か

あなたの AI エージェントにとって、「作業を完了する」とは「次の応答を生成する」ことを意味します。あらゆるツール呼び出しからネットワークの往復を取り除くことで、「思考中…」インジケーターでの待ち時間が、数秒から即座に感じられる何かへと変わります。

効果 2 — 入力トークンコストが約72%低い

これはプロトコル効果です。@bridge のワイヤープロトコルが既定で無駄がないために存在します。

あなたの AI エージェントがツールの応答を受け取ると、その応答はモデルの次のターンの入力トークンになります。モデルプロバイダー — Anthropic、OpenAI、その他の誰であれ — は入力トークンごとに課金します。したがって、応答が安いほど、次の推論ステップも安くなります。

クラウドメールツールは、あらゆるメールの完全な HTML 本文を返します。これには次が含まれます：

言語モデルにとって何の意味もないスタイリング用のインライン CSS；
言語モデルにとって何の意味もないトラッキングピクセルとトラッキング URL；
言語モデルにとって何の意味もない装飾的マークアップ、テーブルレイアウト、 div の入り乱れ。

典型的なマーケティングメールでは、取得されるメール1通ごとに、実質的に無関係な 6,000トークン以上のコンテンツになります。

@bridge のワイヤープロトコルには、このオーバーヘッドを排除する、協調して働く 4つの機能があります：

既定でテキスト

本文の取得は、メッセージ本文のプレーンテキスト表現を返します。HTML は、利用者が明示的にオプトインした場合（html: true）にのみ返されます。レンダリングされたスタイリングを必要としない90%のエージェントワークフローにとって、これだけで肥大化のほとんどが取り除かれます。

任意のスニペットプレビュー

検索と一覧の操作には、最初の空でない本文断片の短いスニペットが含まれます。エージェントは各本文を取得せずに結果を仕分け・要約でき、メッセージごとの 2回目の往復を排除します。

Message-ID による重複排除

複数のフォルダーにまたがるスレッドが、複数回返されることはありません。ブリッジは、モデルが目にする前に、RFC-2822 の Message-ID で結果を重複排除します。

自動ページネーションなし

結果は、カーソルエンベロープやストリーミングの定型文で包まれることはありません。応答は、データを伝える最小限の読みやすい JSON です。

同じ3メッセージのワークロードでの実測結果：@bridge はツール応答で約 3,711入力トークンを生成するのに対し、クラウドのベースラインでは約 13,143入力トークン — 約**72%**の削減です。

Anthropic Claude Sonnet の入力価格である100万トークンあたり$3（2026年6月）で計算すると、このワークロードの請求コストは約3.94セントから1.11セントへと下がります — 約3.5倍のコスト効率の改善です。

2つの効果、2種類の証拠

コスト効果と速度効果は、異なる設計上の選択から生じ、互いに依存しません — そして、それらは異なる種類の証拠に基づいています：

コスト効果は実測です：稼働中の Gmail MCP に対して繰り返した3メールのトークン／コストのベンチマーク（上記の数値）。無駄のないペイロードプロトコルだけを実践すれば — たとえクラウドアーキテクチャ上であっても — このコスト効果は得られます。
速度効果はアーキテクチャによるもので — かつ直接操作で実測されています： ローカルループバックアーキテクチャはあらゆる操作から公共インターネットの往復を取り除くため、直接操作は、クラウドの約110ミリ秒の往復下限に対して1桁ミリ秒で完了します（≈20倍；効果1を参照）。決してしない往復が、あなたを遅くすることはできません。私たちはこれを直接操作に限定しています — 検索はローカルスキャンであり、転送における勝利ではありません。

@bridge はその両方を行います。@bridge のようなものを作りたい人は、両方を必要とします。

これがあなたにとって意味すること

あなたはすでに Claude、GPT-5、あるいはお使いのどのモデルにも支払っています。 @bridge はその請求にゼロを追加します。それは2つの意味においてです：

LLM 側にサブスクリプション税がありません。 Superhuman AI や Shortwave と異なり、@bridge はあなたとモデルの間に独自の従量課金で割り込むことはありません。あなたのモデルの請求額は、これまでどおりです。
モデルが操作ごとに使う量が減ります。 各ツール応答が無駄なく軽いため、応答を処理するあらゆる推論ターンのコストは、Gmail MCP を通した場合のおよそ 5分の1で済みます。

そしてプライバシー面も改善します：atbridge.ai はクラウドの仲介者を一切加えません — ホスト型 MCP が自社のサーバー経由でメールを中継するのとは違い、あなたのメールが当社のサーバー経由でやり取りされることはありません。ローカルモデル（Ollama）を使えば、あなたのメール内容は完全にワークステーション上にとどまります。 クラウドモデルを使う場合、あなたが AI に処理を頼んだ内容だけが、あなたの選んだプロバイダーに送られます。DPA で開示すべきこと、調達部門と交渉すべきこと、 SOC 2 の質問票で証明すべきことがはるかに少なくなります — データ経路はあなたとあなたの選んだモデルのものであり、間に余計なベンダーはいません。

どのようにこれを誠実に保っているか

上記のコスト数値は、合成のマイクロベンチマークではなく、実際のワークロードから得た本物の数字です。具体的には：

ワークロードはサイズの異なる3通の実際のメールです：短い HTML のみのメッセージ1通、長いスレッド形式の会話1通、構造化された通知1通 — 両方のメールストアに存在する同じ3通で、RFC Message-ID で結合しています。
トークン数は、実際のツール応答ペイロードから導出され（文字数 ÷ 4 の近似）、 Anthropic Claude Sonnet の入力レート（100万トークンあたり $3、2026年6月）で価格付けしています。
トークンベンチマークは修正が入るたびに再実行され（これまでに6回）、引用した数字は @bridge の完全に動作する無駄のない経路を反映しており、たまたま良かった単一の試行ではありません。
**速度の数値は実時間（wall-clock）**で、操作ごとに30回繰り返し、curl のオンザワイヤークロックで計測し（モデルの自己推定ではありません）、直接操作に限定しています — クラウドの数値は往復の下限であり、検索（ローカルスキャン）は除外しています。完全な方法論は技術ホワイトペーパーにあり、ご請求いただけます。

数値はワークロードによって変わります。短いプレーンテキストのメールは、長い HTML の多いスレッドより小さなコスト削減になります。アーキテクチャによる速度の優位性はより一様です — あらゆる呼び出しで節約される、同じネットワークの往復だからです。私たちがこの3メールの組み合わせを選んだのは、実践的なエージェントワークロードを反映しているからであって、マーケティング用に最大の数字を生み出すからではありません。

権利

完全な技術ホワイトペーパーはご請求いただけます。

著者について

Nazar Kholboiev（atbridge.ai の作者）が執筆 — LinkedIn · nazar@atbridge.ai。

続けて読む

AI がどのようにあなたのメールに接続するか — 実践的なインストール経路。
プランと料金 — サブスクリプションの仕組み。
完全にローカルな AI を動かす（Ollama） — メール内容が決して AI プロバイダーに送られないよう、@bridge をローカルモデルと組み合わせます。

Was this page helpful?