sanctuary：クロスボーダー E コマース支援自動化
Technical Support Engineer @ Global-e · TypeScript, MCP, MSSQL, Snowflake, Coralogix, Playwright
課題
Global-e はクロスボーダー E コマースプラットフォームを運営している。技術支援では、 ばらばらの 10 以上のシステムを横断して調査する必要がある:admin portal、決済ゲート ウェイ(Adyen, Stripe, Klarna, PayPal, Worldpay)、MSSQL / Snowflake データベース、 observability、JIRA / Confluence、Zendesk、メールログ、そしてマーチャントの Shopify ストア。
1 チケットの調査に 2 時間以上かかり、引き継ぎの難しい暗黙知に依存 していた。
解決
sanctuary を作った:調査の全 lifecycle を単一のインターフェースの 背後に束ねる 1 つの MCP サーバー。初期は Python と Go によるマルチサービス構成だった が、単一の TypeScript MCP サーバーとして作り直した。運用コストを下げ、そして直感に 反して、できることを広げた。
主な機能
統合された注文調査
composite ツール 1 回で 1 分以内に全体像を取得する:6 つの価格フィールドを跨ぐ DB join、決済トランザクション履歴、配送タイムライン、返金チェーン、マーチャント設定、 商業インボイス(CI)レンダリング、そして自動 discrepancy 検出まで。
マルチ PSP 決済診断
Adyen、Stripe、Klarna、PayPal、Worldpay を横断した自動調査。異なる API、認証方式、 データフォーマットを一貫した診断ビューに正規化する。MSSQL の保持期間を超えた決済 履歴のための 4.44 億行の Snowflake archive を含む。
自分の徹底さを測る
自分の調査品質を測定する 5 段階フレームワーク。false-positive rate、root-cause 発見 頻度、resolution-direction recall を追跡し、段階間にデータ駆動のゲートを置く。 STAGE 1-3 はデプロイ済み、STAGE 4 は測定ウィンドウ稼働中。
体系化されたルールによる応答品質保証
マーチャント向け応答が送信される前に、checker が feedback メモリとして記録された 216 件の文書化された学習に照らして検証する。そのうち 109 件は自動で強制される YAML ゲートとして体系化され、ツール境界で 違反をブロックする。禁止用語、エスカレーション経路の正しさ、事実の正確性、受信者 ごとのトーン calibration をカバーする。
失敗からルール、そして hook へ
失敗が再発すると、システムがそれを体系化する:feedback メモリを書く → YAML ゲートを 追加 → PreToolUse hook を設置 → ツール境界で失敗モードをブロック。これにより 100 以上 の再発エラーカテゴリを、production 上でほぼ 0 再発まで引き下げた。
ローカル・送出ゼロの推論
一部の調査は、マシンの外に出してはならない機微な顧客データ(PII、決済情報)に触れる。 そうしたケースでは、ローカル LLM ユーティリティ(ollama)がネットワーク送出 ゼロで抽出と分類を実行する:データがネットワーク境界を越えることはない。 ローカルモデルが担うのは抽出と分類だけで、マスキングは決定論的な正規表現に任せる。
多層安全装置の上での Bulk 操作
注文ステータス変更、未請求処理、マーチャントデータエクスポートは、すべて以下の ゲートで保護される:(a) デフォルトの dry-run モード、(b) 承認トークンワークフロー、 (c) 不可逆アクションの StatusID block list、(d) write 後の DB 検証、(e) checkpoint DB への audit logging。
ベアマシンからの再建
2026 年半ば、マザーボード交換中のハードウェア障害でマシンが消えた。3 日でシステム 全体をベアリポジトリから再建した。まずバックアップから。暗号化アーカイブと、バックアップ が実際に復元できることを証明する復旧リハーサル。それからツール。このリセットを機に、 惰性で残していたであろうものを再設計した:ルーティングレイヤー、データフォーマットの 規約、パス処理。いまは golden-master ハーネス がリファクタを守る。 各ツールの出力をバイト単位で捕捉するので、1 バイトでも挙動を変える分割や整理はゲート で落ちる。こうして、挙動変化を 1 つも出荷せずに、肥大化した 6 つのモジュールを分割 した。
7 つの専用 SQLite データベース
単一の monolithic ストアではなく、sanctuary は 7 つの専用 SQLite データベースを使い、
それぞれが単一の関心事を担う:investigation.db(チケット毎の checkpoint
チェーン)、tickets.db(全文検索付きのキャッシュ済みチケット本文)、
conversation_log.db(セッション間メタデータ)、mistakes.db
(体系化パイプラインに供給される構造化された失敗ログ)、metrics.db
(自己計装したツール / hook メトリック)、knowledge.db(再利用可能な
ドメイン知識)、そして forter_learning.db(active learning のための
ドメイン特化チケット cohort)。
関心事ごとに分けることで、システムは inspectable に保たれる。失敗はそれ自身の データベースに存在するので、「今週どんなミスが起きたか?」を 1 クエリで答えられる。 汎用のイベントテーブルから掘り出す必要はない。
結果
- 5 つの PSP を単一の診断ビューに統合
- 7 サービス(K8s + Docker)→ 1 つの統合 TypeScript サーバー
- 調査品質の測定:なし → 定量ゲート付き 5 段階フレームワーク
学んだこと
統合はオーケストレーションに勝つ。かつての 7 サービス構成は技術的には より印象的だった。あとの構成のほうが速く出荷でき、デバッグが容易で、運用コストが低い。
ツールの数より振る舞いが大事だ。 エージェントに 379 のツールを与えるのは仕事の半分にすぎない。残りの半分は、どう 振る舞うべきかを体系化すること。結論の前に何を検証するか、そして推測する代わりに いつ尋ねるか、だ。
自分自身のエンジニアリングを測る。 Investigation Thoroughness フレームワークは、自分の調査品質を数値にできるものとして 扱う。「徹底しているつもりだ」と「データがそれを示している」の間には本当のギャップが あり、私が埋めたいのはそのギャップだ。
強制的な再建は、容赦のない監査だ。ハードウェア障害で マシンが消えたとき、立て直しにかかったのは数日で、それに先立つ 6 か月ではなかった。 しかもより良くなった。自分の居場所を勝ち取ったものだけを作り直したからだ。
ツールの背後にある学習システム
sanctuary のツールは作業を速くする。学習システムは作業が積み上がることを保証する。
ドメイン学習ループ
各支援ドメイン(決済不正、配送、関税など)について、週 2-3 回 × 30 分のサイクル: reference を読む → 過去の実チケットを想起する → 顧客 / 同僚とのやり取りをシミュレー ションする。AI はそのやり取りの相手役を演じる。
2 リポジトリのポートフォリオ
エンジニアリングリポジトリの非公開マスターと、公開の Astro サイト。polished な記事は、 voice インタビューと IP マスキングゲートを強制するスラッシュコマンドを通じて、学習 セッションから昇格される。
生きた回顧録
各記事は EN と KO で同時公開する。JA は voice が言語の壁を越えて残るときだけ、選んで 後を追う。翻訳の規律が明晰さを引き出す。
このシステムこそが、このポートフォリオの存在理由だ。これがなければ、仕事は solved と マークされた瞬間に閉じたチケットへ消えてしまう。あればこそ、仕事は指し示せるものになる。