outlook-bridge

Claude が Outlook classic（Windows、COM 経由）でメールを検索・閲覧するための MCP サーバー — list_folders、search_mail、read_mail、get_thread、read_attachment。完全な設計は docs/superpowers/specs/2026-08-24-outlook-bridge-design.md、実装計画は docs/superpowers/plans/2026-08-24-outlook-bridge-a.md を参照。

読み取り専用 — 書き込みツールなし

このサーバーには send_mail、delete_mail、move_mail、mark_as_read や、メールを変更・削除・送信するツールは一切ありません。Win32MailStore 内のどのメソッドも .Send()、.Save()、.Delete()、.Move()、.MarkAsRead() を呼び出したり、Outlook のプロパティに値を代入したりしません。唯一の例外: read_attachment は、テキスト抽出のために添付ファイルをサーバー自身が作成した一時ディレクトリ（tempfile.TemporaryDirectory）に書き出し、その後すぐにそのディレクトリを削除します — SaveAsFile は読み取り API であり、Outlook 内の何も変更しません。

Related MCP server: outlook-mcp

Linux（開発機）での実行 — FakeMailStore

Outlook も Windows も不要です。FakeMailStore は YAML フィクスチャ（約50通の合成メール: 複数フォルダ、複数ストア、会話スレッド、各種添付ファイル、ベトナム語メール、長文ボディ、空メール、メール以外のアイテム）を読み込み、Win32MailStore と同じ MailStore インターフェースを実装します。

python -m venv .venv
.venv/bin/pip install -e ".[dev]"

# Chạy server với store giả (không cần Outlook)
OUTLOOK_BRIDGE_FAKE=1 OUTLOOK_BRIDGE_FIXTURE=tests/fixtures/mailbox.yaml \
  .venv/bin/python server.py

テストの実行

Linux（ロジックの大部分 — 純粋な Python + FakeMailStore）:

.venv/bin/pytest

Windows（両ストアに共通のコントラクトテストスイート — これが Win32MailStore が実際に FakeMailStore と動作を一致させていることを証明する唯一の方法であり、「動く」だけではありません）:

set OUTLOOK_BRIDGE_CONTRACT_WIN32=1
.venv\Scripts\pytest tests/contract -v

このスイートの一部のケースは、実際のメールボックスでは意図的に SKIP されます（データは FakeMailStore のフィクスチャにのみ存在）— SKIP を問題の兆候と見なす前に、docs/WINDOWS-RUNBOOK.md の「意図的な SKIP テスト」セクションを参照してください。

Windows でのインストールと MCP サーバーの登録は docs/INSTALL-windows.md、実際の Windows マシンで初めて作業する際の手順は docs/WINDOWS-RUNBOOK.md を参照してください。

環境診断 — doctor.py

python doctor.py            # trên Linux: báo "không phải Windows", degrade an toàn
python doctor.py --verbose  # trên Windows: thêm chi tiết root.Name, cây folder, giá trị raw

誰も解決できていない2つのリスク（仕様 §13）

R2 — New Outlook が徐々に Outlook classic を置き換え、COM も消えていく。 Microsoft はユーザーを New Outlook へ強制移行しており、New Outlook は COM サーバーを登録しません（これが発生すると doctor.py は com_ok: False を報告します）。これは賞味期限付きのものであり、修正可能なバグではありません。発生した場合の唯一の脱出経路は、Microsoft Graph API ベースで Win32MailStore を書き直すことです — プロジェクトのアーキテクチャ（COM の詳細はすべて win32_store.py と doctor.py のちょうど2ファイルにのみ存在）により、被害はその2ファイルの書き直しに限定され、システム全体には及びません。

R3 — 社内メールの内容が Anthropic の API を経由する。 COM は完全にローカルで動作します（メールを読むためにマシンから何も出ません）が、Claude がメールの内容に基づいて回答するには、その内容を API に送信する必要があります。これは AI アシスタントでメールを読むことの本質的なトレードオフであり、どのサーバーも代わりに解決してはくれません。

唯一の制御手段: config.toml の folder_allowlist。これを特定のフォルダリスト（ストア修飾、例: "Mailbox - Nguyen Van A/Inbox"）に設定すると、このサーバーが見えるメールの範囲を制限できます — 許可リスト外のメールは、どのツールからも、どの呼び出し経路でも（検索、ID による読み取り、スレッド読み取り、添付ファイルのダウンロード）、会話スレッドが許可リストの境界をまたぐ場合でも読み取られません。

一致は完全一致であり、プレフィックス一致ではありません。 "Inbox" を許可しても "Inbox/Bao cao" は許可されません — 許可する各フォルダは個別にリストする必要があります。これは意図的な設計選択であり、制限ではありません。プレフィックスベースの許可リストは、設定者が想定していない機密のサブフォルダを誤って許可してしまう可能性が高いからです。folder_allowlist を設定しない場合（デフォルト、空リスト）、メールボックス内のすべてのフォルダが読み取り可能になります — このサーバーを実際の企業メールボックスに向ける前に設定してください。list_folders からストア修飾フォルダ名を取得する方法は、docs/WINDOWS-RUNBOOK.md のステップ2を参照してください。

さらに厳しくする必要がある場合: folder_allowlist を特定の数フォルダに絞り込むか、それでも不十分な場合は、メールの全内容ではなくメタデータとスニペットのみを返すことを検討してください（現在この機能を持つツールはありません。新しいツールが必要になります）。