真北科技Zhenbei
ホーム開発ツールpxc
Capture Proxy + Team Collaboration

pxcキャプチャプロキシとチーム協働

Proxyman をベンチマークとしたキャプチャプロキシで、デバッグ現場をチームの共有資産に変えます。Go カーネル pxc-core と各プラットフォームのシェルの唯一の契約は /v1 HTTP/WS API。macOS の Swift、Windows の WinUI、Flutter の 3 つが同じカーネルを共有します。

pxc
01$ pxc sessions --host api.github.com --status 500 --limit 20
02[ { "id": 42, "method": "POST", "path": "/v1/pay", "status": 500 } ]
03
04$ pxc bp respond 7 --status 201 --body '{"ok":true}'
05{ "released": true, "mode": "mock" }
概要使い方モジュールアーキテクチャCLI リファレンス
$

キャプチャは終点ではありません。再現可能なデバッグ現場こそが終点です。

Design

設計のポイント

このツールがなぜこのように作られているのか、そしてそれが何をもたらしたのか。

カーネルと UI の分離

カーネルは /v1 API だけを公開します。Swift / WinUI / Flutter / CLI のどの端も対等な消費者であり、プラットフォームをまたぐ挙動が自然に一致します。

エージェントフレンドリー

pxc status / sessions / body / curl はすべて構造化出力。AI がトラフィックを直接読んで問題を特定でき、スクリーンショットは不要です。

ブレークポイントこそデバッガ

ルール1行で対象トラフィックを保留し、body をリアルタイムに確認して解放・mock・中止を選択。スクリプトを書かずに改変と再生ができます。

チーム共有

キャプチャの現場は HAR と cURL にエクスポートでき、issue に添付すればそのまま再現できます。「もう一度試してください」はもう不要です。

Highlights

能力一覧

  • Go カーネル + マルチプラットフォームシェル。UI 層は差し替え可能で、/v1 HTTP/WS が唯一の契約
  • pxc CLI はエージェントのために設計：既定で JSON 出力、意味を持つ終了コード、トークンの自動解決
  • サーバーサイドフィルタと全文検索：host、ステータスコード、body のキーワードで直接特定
  • ブレークポイントデバッグ：トラフィックを保留し、method / URL / header / body を書き換えてから解放
  • フォールトインジェクションと mock：上流に接続せず直接応答し、異常系を構築
  • HAR 1.2 の全量エクスポートと cURL リプレイ。デバッグ現場をワンクリックで同僚に共有
Metrics

設計指標

どれも実装における具体的な決定に対応しています。

カーネルを共有する端末
3 端末

macOS Swift / Windows WinUI / Flutter。UI は差し替え可能

カーネル検収項目
61

カーネルの E2E 検収カバレッジ。端をまたいだ挙動一致の前提

ルールのホットリロード
1s

ルール保存後 1 秒以内に反映。カーネルの再起動は不要

終了コードの意味
0 / 1 / 2

成功 / 失敗 / 用法エラー。スクリプトやエージェントが判断しやすい

検索方式
FTS

全文検索で body のキーワードから直接特定。目視で探さない

エクスポート形式
HAR 1.2

全量エクスポート + cURL リプレイ。デバッグ現場を共有できる

Platforms

プラットフォーム対応

カーネルとシェルを分離したことで、対応状況はプラットフォームごとに個別に進められます。

macOS
完全対応

Swift デスクトップシェル。/v1 HTTP/WS でカーネルと通信

Windows
完全対応

WinUI デスクトップシェル。同じ Go カーネルを共有

CLI
完全対応

既定で JSON 出力、意味を持つ終了コード、トークン自動解決

Flutter / モバイル
一部対応

モバイルでのキャプチャと閲覧。バインディングは kernel/bindings にあり

Web UI
一部対応

カーネル同梱の Web UI 成果物で、ブラウザ内からトラフィックを閲覧

Comparison

一般的なやり方との違い

違いは通常機能表ではなく、「境界をどこに引くか」にあります。

カーネルと UI
Go カーネルは /v1 HTTP/WS のみを公開し、すべての端が対等な消費者
キャプチャロジックが UI 内にあり、端ごとに再実装
AI での利用
CLI は既定で JSON、終了コードは意味を持つ。エージェントが直接トラフィックを読める
人が UI を目視するしかなく、AI には構造化データが渡らない
デバッグの方法
ブレークポイント保留 + リアルタイム改変 + mock 応答。スクリプト不要
改変には介入スクリプトを書くか、コードを変えて再デプロイが必要
検索能力
サーバーサイド FTS の全文検索。body のキーワードで特定
リストを目視でたどるため、トラフィックが増えると見つからない
チーム協働
HAR 全量エクスポート + cURL リプレイ。現場を再現・共有できる
「そちらでもう一度試して、再現するか確かめて」
Commands

コマンド概要

完全なマニュアルは CLI リファレンスページにあります。すべてのコマンドは既定で構造化された結果を出力します。

コマンド一覧を見る
pxc status

カーネルの稼働状態・待ち受けポート・ライセンス情報を表示

--json
pxc sessions

キャプチャ済みトラフィックを複数条件の組み合わせで検索

--host--status--method--limit--q
pxc body <id>

指定セッションの完全なリクエスト / レスポンスボディを読む

--req--res--raw
pxc curl <id>

再生可能な cURL コマンドとしてエクスポート

--no-headers
In Practice

実際の出力

pxc
01$ pxc sessions --host api.github.com --status 500 --limit 20
02[ { "id": 42, "method": "POST", "path": "/v1/pay", "status": 500 } ]
03
04$ pxc bp respond 7 --status 201 --body '{"ok":true}'
05{ "released": true, "mode": "mock" }
Source

モジュール

3 グループ・15 モジュール。すべてリポジトリの実際のディレクトリ構造に基づきます。

Go · Swift · WinUI · Flutter · WebSocket · HAR · FTS
カーネル

Go 製の pxc-core が唯一の事実源です。

internal/engine

トラフィック捕捉とプロキシエンジン。ブレークポイントの保留と解放を実行する主体

kernel/internal/engine
internal/store

トラフィックの保存と検索。FTS 全文検索で body のキーワードから特定

kernel/internal/store
internal/rules

ルールエンジン：テキスト DSL のルール。保存後 1 秒でホットリロード

kernel/internal/rules
internal/api

/v1 HTTP + WebSocket 契約の実装。カーネルの唯一の対外インターフェース

kernel/internal/api
internal/scripting

スクリプトによる拡張機能

kernel/internal/scripting
internal/pairing / discovery

デバイスのペアリングとインスタンス発見。複数端での協働デバッグを支える

kernel/internal/{pairing,discovery}
internal/license / instance

ライセンスとインスタンス管理

kernel/internal/{license,instance}
コマンドと端末

カーネルが認めるのは /v1 のみ。すべての端は対等な消費者です。

cmd/pxc

CLI：既定で JSON 出力、意味を持つ終了コード（0/1/2）、トークン自動解決

kernel/cmd/pxc
cmd/pxc-core

カーネルのサービスプロセス

kernel/cmd/pxc-core
cmd/pxc-mobile / pxc-license

モバイルとライセンスのコマンド

kernel/cmd/
apps/desktop

デスクトップシェル（macOS Swift / Windows WinUI）

apps/desktop
apps/mobile / webui

Flutter モバイルと Web UI

apps/{mobile,webui}
契約とバインディング

プラットフォーム横断の一貫性を支える部分です。

shared/api-spec

/v1 API の仕様。カーネルと全端がこれに揃う

shared/api-spec
kernel/bindings

モバイルのバインディング層

kernel/bindings
kernel/web

カーネル同梱の Web UI 成果物

kernel/web
その他のツール
legdger暗号化されたローカルファースト家計簿
NewTool開発者ツールボックス
Get in touch

アイデンティティ・エージェント・プライベートドメインの複雑さを、統治可能なひとつのカーネルへ

既存の IAM の置き換え、エージェント基盤の構築、あるいはプライベートドメイン運用の本格化——まずは 30 分のアーキテクチャ相談から始めましょう。私たちが得意とする種類の問題かを先に判断し、適さない場合は率直にお伝えします。

アーキテクチャ相談を予約hi@zhenbei.tech
導入とサービス4つの提供形態と6ステップの導入プロセスセキュリティとコンプライアンス境界の引き方とコンプライアンス対応の対照エンジニアリングノート技術的な決定とその代償API と契約商談の前に契約を確認：OIDC エンドポイント、トークン交換、エージェントツール認可 API