Rockxyとは｜Proxyman代替のOSSデバッグプロキシをMCP連携の実測つきで解説

Rockxy（RockxyApp/Rockxy・⭐812）は、ProxymanとCharles Proxyの代替を明示的に掲げるmacOS向けのHTTPデバッグプロキシです。SwiftNIOベースのネイティブアプリで、ライセンスはAGPL-3.0。HTTPSを復号して中身を読み、必要なら書き換えて送り直せます。

この種のツールが1本増えただけなら、わざわざ日本語で解説する理由はありません。Rockxyが他と違うのは、復号した通信をAIに見せる導線が2つ標準搭載されている点です。アプリ内のAIアシスタントと、Claude Desktop・Cursorから接続する内蔵MCPサーバー。どちらも「機密は伏せる」と説明されていますが、伏せる範囲を決めているのは設定画面ではなくコードです。この記事では、その redaction 実装をリポジトリからそのまま切り出してコンパイルし、何が伏せられ何が残るのかを実測します。

Rockxyは「MCPサーバーを内蔵したアプリ」です。MCPサーバーそのものを自分で作る手順は MCPサーバーの作り方2026年完全ガイド：TypeScript・Python両対応チュートリアル をご覧ください。

Rockxyとは——Proxyman代替として何が違うのか

Rockxyは2026年3月26日に公開されたプロジェクトで、開発者はStephen（LocNguyenHuu）氏。README冒頭の位置づけは「The open-source, auditable debugging proxy for macOS」です。auditable（監査可能）という語がこのプロジェクトの主張の中心にあります。

デバッグプロキシは仕事の性質上、極めて強い権限を持ちます。ルート認証局をKeychainに入れ、HTTPSを復号し、平文になったリクエストとレスポンスを保持する。つまりあなたのMacを通る認証トークン・Cookie・APIキーのすべてが、そのアプリの中を通過します。ProxymanもCharlesも実績あるツールですが、中で何をしているかをユーザーが読むことはできません。Rockxyの提案は「同じことをするなら、読めるコードでやろう」という一点に集約されます。

機能面はいわゆる「有償プロキシで使うもの」が概ね揃っています。ホスト単位のTLS復号可否、証明書ピン留めアプリのバイパス、ブロックリストによる障害シミュレーション、Map Local（保存済みファイルを応答として返す）、Map Remote（宛先を本番からステージングへ書き換える）、リクエスト/レスポンスのブレークポイント編集、3G/EDGE/LTE相当のスロットリング、HARの入出力、JavaScriptフックによる書き換え。

比較表は公式READMEにも載っていますが、あちらは他社製品の欄をベンダー自身が埋めたものです。ここでは自分で確認できる軸だけに絞って整理します。

表の最後の行は割り引いて読む必要があります。デバッグプロキシは開発マシンの通信を全て握る種類のソフトウェアで、若いプロジェクトはそれだけ枯れていません。逆に言えば、ソースを読んで判断できることがそのまま若さへの対処になります——本稿の後半がまさにその作業です。

インストールとビルド——Xcode 16+が前提になる

ここは正直に書いておきます。RockxyのREADMEが案内する導入手順は、配布バイナリのダウンロードではなくソースからのビルドです。

git clone https://github.com/RockxyApp/Rockxy.git
cd Rockxy
open Rockxy.xcodeproj

要件は macOS 14.0+ / Xcode 16+ / Swift 5.9。Xcodeでビルドして起動すると、Welcomeウィンドウがルート認証局の作成、ヘルパーツールのインストール、プロキシ有効化まで案内します。

つまりXcodeが入っていないMacでは試せません。筆者の検証環境（macOS 14.5・Command Line Toolsのみ・Swift 5.10）ではアプリ本体はビルドできず、GUIの挙動は公式デモ動画とREADMEの画面キャプチャで確認しています。この記事でGUI操作を断定的に書いていないのはそのためです。

一方で、アプリを起動しなくても検証できる部分があります。Rockxyのコードのうち redaction（機密の伏せ字化）はFoundationだけで完結する純粋なロジックで、Xcodeなしの swiftc でコンパイルできます。後半の実測はこの方法で行いました。

なお公開されているのはソースだけではなく、リポジトリには releases/・appcast.xml・signatures/ が含まれ、GitHub Releasesにタグ付きリリースが並びます。最新は2026年8月7日の v0.34.0 で、CHANGELOGによればこのバージョンでAIアシスタントが「リクエストを選択していない状態でも使い方やワークスペースの状態を答える」よう拡張されています。

MCP連携——Claude DesktopとCursorに見える10個のツール

Rockxyの内蔵MCPサーバーは、キャプチャ済みの通信をAIクライアントから読めるようにするものです。「このリクエストのヘッダをコピーしてチャットに貼る」という往復をなくすのが狙いで、READMEの表現を借りれば「なぜこれは500になったのか」とそのまま聞けるようにする機能です。

Rockxy/Core/MCPServer/MCPToolDefinitions.swift を数えると、定義されているツールはちょうど10個でREADMEの記述と一致します。

10個すべてが参照系です。 通信を書き換える、ルールを追加する、プロキシを止める——といった副作用のあるツールは定義されていません。AIクライアント側が暴走してもキャプチャを読む以上のことは起きない設計で、これは安心して良い部分です。

接続の仕組みは2段構えになっています。アプリ本体がMCPサーバーをローカルに立て、RockxyMCP という小さなCLIバイナリがAIクライアントとの間をstdioで橋渡しします。

橋渡しの実装は RockxyMCP/ の3ファイルだけで、読めばすぐ分かる程度の分量です。起動時にハンドシェイクファイルからトークンとポートを読み、失敗すれば次のメッセージを出して exit(1) します。

・待ち受けは 127.0.0.1 固定（MCPServerConfiguration の既定値）、ポートは 9710
・Origin ヘッダは localhost と 127.0.0.1 のみ許可
・トークンは32バイト、Authorization: Bearer <token> で毎リクエスト検証
・トークンとポートを書いたハンドシェイクファイルはパーミッション 0600 で保存され、終了時に削除される

Claude Desktop側の設定は通常のMCPサーバーと同じ形です。ビルド済みの RockxyMCP バイナリを指定します。

{
  "mcpServers": {
    "rockxy": {
      "command": "/Applications/Rockxy.app/Contents/MacOS/RockxyMCP"
    }
  }
}

アプリが起動していない、あるいは設定でMCPが無効なままだと、ブリッジは標準エラーへ Rockxy is not running or MCP server not started. と出して終了します。Claude Desktop側では「サーバーが起動しない」としか見えないので、まずアプリを起動してMCPを有効化するという順序を覚えておくと詰まりません。Claude Desktop側の設定ファイルの場所や再読み込みの手順は Claude Desktop 使い方入門｜MCP接続で広がるデスクトップAIの可能性とローカル連携 にまとまっています。

実測——AIに渡る前に何が伏せられるのか

ここからが本題です。「機密は自動で伏せる」と書かれているとき、実際に伏せられるのは何なのか。

Rockxyの redaction は2つの実装に分かれています。Rockxy/Core/Utilities/SensitiveDataRedactor.swift（アプリ内の共有・エクスポート用）と、Rockxy/Core/MCPServer/MCPRedactionPolicy.swift（MCP経路用）です。後者が、Claude Desktopが読む側の実装にあたります。

この2つはFoundationのみに依存しており、アプリ本体をビルドできなくても検証できます。リポジトリからソースを一字も変えずにコピーし、周辺の型（HTTPTransaction など redaction の挙動に関係しない型）だけ最小のスタブを書いて swiftc に渡しました。

# 検証したコミット: RockxyApp/Rockxy @ main（2026-08-14 時点）
cp Rockxy/Core/Utilities/SensitiveDataRedactor.swift  probe/
cp Rockxy/Core/MCPServer/MCPRedactionPolicy.swift     probe/
cp Rockxy/Models/Network/ContentType.swift            probe/
cp Rockxy/Models/Network/HTTPRequestData.swift        probe/
cp Rockxy/Models/Network/HTTPResponseData.swift       probe/
# Stubs.swift と main.swift のみ自作（redaction 本体には手を触れない）
swiftc -o probe probe/*.swift && ./probe

まず、判定に使われている語彙の規模が確定します。コンパイル後に実際のSetの要素数を数えると、ヘッダ16語・クエリパラメータ56語・ボディキー93語でした。そして重要なのは判定方法で、いずれも Set.contains(name.lowercased()) による完全一致です。部分一致でも正規表現でもありません（JSON以外のボディだけは正規表現の補助が入ります）。

LLM APIのペイロードは、丸ごと潰れる

最初の結果が実務上いちばん効きます。OpenAI互換のリクエストボディを入れてみます。

入力:

{"model":"gpt-5","temperature":0.7,
 "messages":[{"role":"user","content":"why does my checkout 500?"}],
 "tools":[{"type":"function","function":{"name":"lookup"}}],
 "max_tokens":512}

MCP経路を通した出力:

{"max_tokens":512,"messages":"[REDACTED]","tools":"[REDACTED]",
 "model":"gpt-5","temperature":0.69999999999999996}

messages と tools が配列ごと [REDACTED] という文字列に潰れました。sensitiveBodyKeys には prompt / prompts / messages / input / instructions / system_prompt / tools / tool_calls / arguments / retrieved_context / rag_context / context / embeddings といったLLMペイロードの語彙が丸ごと登録されているためです。

これは設計としては筋が通っています。デバッグ対象のプロンプトを、別のLLMへ横流ししないという判断です。ただし利用者から見ると、「このLLM呼び出しがなぜ失敗したか聞く」という最も自然な用途では、既定のままだと肝心の中身が見えません。Claude Desktopに渡るのはモデル名・温度・max_tokensとステータスコードだけになります。ステータスやヘッダの不整合を追うには足りますが、プロンプト内容が原因の失敗は追えません。設定で redaction を切れば渡りますが、その瞬間に自分のプロンプトと社内データを外部モデルへ送ることになる——このトレードオフを理解した上で選ぶ必要があります。

出力をよく見ると temperature が 0.7 から 0.69999999999999996 に変わっています。redaction はJSONを文字列置換しているのではなく、一度パースして再シリアライズしているためです。キーの並び順も保存されません。AIに渡る内容が原文のバイト列と一致しない点は、差分を取る用途では留意点になります。

独自ヘッダ名と個人情報は素通りする

一方、リストに載っていないものは伏せられません。ヘッダを並べて通すと結果は明確に分かれます。

社内APIが独自の認証ヘッダ名を使っている場合、その値はそのままAIクライアントへ渡ります。同じことはレスポンスボディでも起きます。

入力:

{"id":42,"name":"Yamada Taro","email":"[email protected]",
 "address":"Tokyo, Chiyoda 1-1","phone":"090-1234-5678","card_last4":"4242"}

このJSONは1文字も変わらずに通過しました。name・email・address・phone は sensitiveBodyKeys に含まれていないためです。redaction は「秘密情報フィルタ」であって「個人情報フィルタ」ではない、と理解するのが正確です。

同様に、プロンプトが messages ではなく query のような独自キーに入っている自社APIでは、中身が長文の契約書であっても伏せられません。キー名がすべてを決めます。

JSON以外のボディは別経路で、正規表現による補助が入ります。プレーンテキストを通すと Bearer に続く値と api_key= は捕捉されましたが、session_key= は（語彙に無いため）残りました。

まとめると

・伏せられる：Authorization・Cookie・X-Api-Key 等の標準的な認証ヘッダ、api_key・token・password 等の定番パラメータ名、そして messages・prompt 等のLLMペイロード語彙
・残る：リストに無い独自ヘッダ名、氏名・メール・住所・電話番号といった値、非収録キーに入った本文
・判定はキー名の完全一致。値の中身は（プレーンテキストの正規表現を除き）見ていない

「[REDACTED] が付いているから安全」ではなく、「自分の環境で流れる名前がリストに載っているか」を先に確認するのが正しい使い方です。

2つのredaction経路の差——URLのuserinfoだけ結果が変わる

語彙セットは2つの実装で共有されています（MCPRedactionPolicy が SensitiveDataRedactor の定数を参照する形）。ところがURLの扱いだけ、通る経路によって結果が変わります。

同じ入力を両方に通した実測結果です。

入力: https://user:[email protected]/v1/models?api_key=secret123&model=gpt-5

・MCP経路: https://user:[email protected]/v1/models?api_key=[REDACTED]&model=gpt-5
・アプリ内経路: https://api.example.com/v1/models?api_key=[REDACTED]&model=gpt-5

クエリの api_key はどちらも伏せられますが、URLに埋め込まれた user:pass@ はMCP経路では残ります。クエリ文字列が無いURLだと差はさらに大きくなります。

入力: https://user:[email protected]/v1/models

・MCP経路: https://user:[email protected]/v1/models（完全に無加工）
・アプリ内経路: https://api.example.com/v1/models

原因はコードを読めば明確です。SensitiveDataRedactor.redactURL(URL) は components.user と components.password を明示的に nil にします。対して MCPRedactionPolicy.redactURL(String) は userinfo に触れず、さらにクエリ項目が空なら早期returnして何もしません。呼び出し側の MCPFlowQueryService.swift:236 は transaction.request.url.absoluteString をそのまま渡しているので、途中で洗浄される機会もありません。

リポジトリのテストを見ると、userinfo除去は SensitiveDataRedactorTests.swift と InvestigationContextBuilderTests.swift（いずれもアプリ内経路）でのみ検証されており、MCP経路については同等のテストがありません。意図的な仕様というよりカバレッジの穴に見えますが、断定はできません。事実として言えるのは「本稿執筆時点のmainではこう振る舞う」ということだけです。

実害の大きさは環境次第です。https://user:pass@... 形式は今どき主流ではありませんが、社内のRPCエンドポイント、古いWebhook、.netrc 的な設定を引きずったCIのURL、一部のブロックチェーンRPCプロバイダなどでは今も見かけます。該当する通信がキャプチャに含まれるなら、MCP経由でAIクライアントへ資格情報がそのまま渡ります。

対処は難しくありません。

・SSL Proxying の対象から該当ホストを外す、または Bypass Proxy に入れてキャプチャ自体をさせない
・Focus Sets / Noise Control で作業スコープを絞り、無関係な通信をMCPの視界に入れない
・そもそもURLに資格情報を埋める形をやめ、ヘッダへ移す（Authorization なら確実に伏せられる）

この挙動が気になる場合、Rockxyには SECURITY.md に報告手順があります。

セキュリティ設計と、有効化する前に決めておくこと

redaction 以外の防御についても、コードで確認できる範囲を整理しておきます。

READMEが挙げる設計上のポイントは以下です。

・XPCヘルパーの呼び出し元検証：バンドルIDだけでなく証明書チェーンの比較で検証する
・プラグインの隔離：JavaScriptCoreのサンドボックス内で実行し、5秒タイムアウト、ファイルシステムとネットワークへのアクセス無し
・入力検証：ボディサイズ上限、URI長制限、正規表現DoS対策、パストラバーサル防止
・機密ファイルの権限：0600で保存（MCPハンドシェイクファイルで実際にそうなっていることは確認済み）

その上で、使い始める前に自分で決めておくべきことが3つあります。

1つ目は、ルートCAを入れる意味の理解です。 HTTPS復号は、あなたのMacに「任意のドメインの証明書を発行できる認証局」を信頼させることで成り立ちます。これはツールの欠陥ではなく、この種のツールの原理そのものです。だからこそプロキシを使わない時間帯はキャプチャを止める、業務用マシンなら組織のポリシーを確認する、といった運用が要ります。

2つ目は、復号対象を絞ることです。 全ホストを復号すると、パスワードマネージャや業務SaaSの通信まで平文でディスクに載ります。SSL Proxying は許可リスト方式で運用し、デバッグ対象のドメインだけを入れるのが安全です。

3つ目は、MCPを有効にするかどうかです。 有効にした瞬間、キャプチャの内容はAIクライアント経由で外部モデルへ渡り得ます。ここまで見た通り、既定の redaction は認証情報にはよく効き、個人情報と独自命名には効きません。判断材料を整理すると次のようになります。

なお、アプリ内のAIアシスタントはMCPとは別系統です。Rockxy/Core/Assistant/ には Ollama・OpenAI互換・OpenAI Responses・Anthropic・Gemini の各プロバイダ実装が並び、外部モデルへ送る前に「Review Data」で送信内容を確認させる設計になっています。ローカルのOllamaを選べば通信自体がMacの外へ出ません。プロンプト内容まで見て相談したい場合は、redaction を切ってMCPで外部に出すより、ローカルモデル＋アプリ内アシスタントの組み合わせのほうが筋が良い選択です。

MCPの通信自体を覗いて挙動を確かめたい場合は、MCPのやり取りをパケットレベルで可視化する MCPデバッグの通信を可視化するmcpsnoop｜MCP版Wiresharkでtool callを覗く が別角度から役に立ちます。MCPというプロトコル自体の前提を確認したい場合は MCPとは何か？AIに手足を与えるプロトコルの仕組みと実践ガイド2026 をどうぞ。

Rockxyを使うべき人・見送るべき人

Rockxyが向いているのは、次のような人です。

・macOSでAPI・モバイルアプリのデバッグを日常的にやる人。機能は有償プロキシと概ね重なり、無償で全機能が使える
・ツールの中身を監査したい人。ルートCAを預ける相手のコードを読めるという性質は、規制のある環境ほど価値がある
・AIクライアントから通信を参照したい人。10ツールが参照系のみで、実装を読んで確認できる

逆に、次の場合は既存ツールを続けるほうが妥当です。

・Windows・Linuxでも使いたい（RockxyはmacOS専用）
・Xcodeを入れたくない、すぐ試したい（ビルドが前提）
・長期の実績を重視する（公開から約5か月）

そして、MCPを有効にするなら本稿の実測を出発点にしてください。既定の redaction は認証情報を守るためのもので、個人情報と独自命名は守りません。 自分の環境で流れるヘッダ名とボディのキー名を数個確認するだけで、AIに何が渡るかは事前に分かります。ソースが公開されているとは、そういうことができるという意味です。

参照ソース

・RockxyApp/Rockxy — GitHub 公式リポジトリ（README・Rockxy/Core/MCPServer/・Rockxy/Core/Utilities/SensitiveDataRedactor.swift・RockxyMCP/・SECURITY.md。2026-08-14 参照）
・Rockxy CHANGELOG（v0.34.0 / 2026-08-07 の変更点。2026-08-14 参照）
・Rockxy 公式サイト rockxy.io（プロジェクトの位置づけと比較ページ。2026-08-14 参照）
・Model Context Protocol 公式ドキュメント（MCPのトランスポートと認可の前提。2026-08-14 参照）