コンテンツにスキップ

メルペイ 決済プラットフォーム常駐 AI エージェント(pcp-agent)の設計と5層防御

作成日: 2026-07-02 出典 / きっかけ: FujishiroKengo「決済プラットフォームに常駐する自律AIエージェントの設計と運用」Mercari Engineering Blog 2026-06-30 / https://engineering.mercari.com/blog/entry/20260630-28a5eee688/ 関連: 社内mcp共通基盤_認証認可ログ_整理 / ai生産性パラドックス_メトリクス起点の改善ループ_整理 / ホタルシステム_個人業務のai自動化_整理 / ai_ガバナンス_誰がnoと言えるか_整理 / 法務経理ai_改善ループとガードレール_事例込み資料


0. 要点(3行)

  • 「人間が AI をキックする」ではなく、トリガー(Slack メンション / cron)で自律実行する Ambient Agent を、Claude Code をエージェントランタイムにして決済ドメインの運用(障害調査・アラート分析・金額検証)に常駐させた事例。
  • 肝はセキュリティを5層で多重化したこと。特に PreToolUse hook を fail-closed(想定外終了は「黙って許可」でなく「ブロック」)にし、auth-proxy でエージェントにトークンを一切持たせない(IaC 管理・ダミー値のみ)設計。
  • 運用は計測とナレッジで閉じる: PostToolUse hook で DX にイベント送信 → Core4 で可視化日次で人間の会話からドメイン知識を自動抽出(LangMem)cron YAML で宣言的スケジュール。共有基盤 remote-claude をマルチテナント化。

1. ビジョン — Ambient Agent(トリガー駆動・常駐)

従来の「AI にお願いする」ツールは人間が毎回起動する。本事例は逆で、イベント(アラート・スケジュール・Slack)を起点に AI が自分から動く「Ambient Agent」。

  • LangChain の Harrison Chase が提唱する ambient agent の定義そのもの: イベントストリームを常時監視し、適時トリガーされて事前指示に沿って動く。「1対1クエリでなくイベント駆動」で「大規模並列・自律ワークフロー」を狙う。CI/CD・イベントバス・チケット系に差し込める(VentureBeat)。
  • 決済ドメインの運用作業(障害の一次切り分け、アラートのトリアージ、問い合わせ調査)を、人間の初動の前に AI が済ませておく、という発想。

2. アーキテクチャ — remote-claude(Claude Code をランタイムに)

Claude Code を「コマンドラインで動くエージェントランタイム」として使い、その周りを共有基盤 remote-claude が固める。

flowchart TD
    Trig[トリガー<br>Slack メンション / cron] --> RC[remote-claude 共有基盤]
    RC --> Cont[セッション毎コンテナ<br>copy-on-write 隔離]
    Cont --> CC[Claude Code<br>エージェントランタイム]
    CC --> Pre{PreToolUse hook<br>fail-closed}
    Pre -->|deny・秘密検出| Block[ブロック]
    Pre -->|許可| Proxy[auth-proxy<br>認証情報を一点集中]
    Proxy --> Ext[外部 API<br>Notion / Jira / Datadog / PagerDuty / Slack]
    CC --> Post[PostToolUse hook<br>fail-open]
    Post -.->|イベント送信| DX[(DX ダッシュボード<br>Core4 / sentiment)]
    DX -.->|MCP でクエリ| CC
  • remote-claude が担うのは: Slack・スケジューラからのトリガー受信、Docker コンテナ管理、標準出力を Slack に橋渡し。
  • セッションごとに copy-on-write ファイルシステムで隔離したコンテナを立ち上げる(1タスク=使い捨て隔離環境)。

3. セキュリティ — 5層防御(本事例の核心)

決済ドメインで自律 AI を回すので、防御を単層に頼らず5層に重ねる。

# 役割 設計の勘所
1 deny rules 危険ツール/操作を静的に禁止 Claude Code 標準の deny
2 PreToolUse hook ツール実行にゲート fail-closed(後述)
3 behavioral rules 振る舞いの規範(CLAUDE.md 等) 確率的なガード
4 auth-proxy ネットワーク層で認証を集中 iptables DNAT・トークン非保持
5 コンテナ隔離 セッション毎に隔離環境 copy-on-write FS

fail-closed な PreToolUse hook

  • シークレットファイルのパターン検出: .env / .pem / .key / credentials.json / /proc/<pid>/environ を検出。boundary・pathchar 条件で「ファイルパスとして現れる鍵ファイル」だけを対象化(誤検知を抑える)。
  • 想定外終了は「黙って許可」でなく「ブロック」。フック自身がエラーで落ちても危険側に倒れない:
# PreToolUse hook — fail-closed(エラー終了なら許可しない)
trap 'ec=$?; if [[ $ec -ne 0 && $ec -ne 2 ]]; then
    exit 2   # 想定外で落ちたら「ブロック」に倒す
fi' EXIT
  • 設計思想: 安全に関わるゲート(PreToolUse)は fail-closed、計測など可用性優先の処理(PostToolUse)は fail-open、とフックの役割で倒す方向を変える

auth-proxy — エージェントはトークンを持たない

  • クレデンシャルを auth-proxy に一点集中。エージェントのコンテナにはトークンを埋め込まない(IaC で管理し、コンテナ内はダミー値のみ)。通信は iptables DNAT でプロキシに寄せ、そこで本物の認証を差す。
  • 対応先: Notion / Jira / DX / PagerDuty / Datadog / Slack など複数 API。
  • 効果: エージェントやプロンプトインジェクションが認証情報を読み出してもそこに本物が無い(漏れる対象を構造的に消す)。

実装上あえて絞った点

  • Codex MCP は有効化せず: 独自シェル実行エンジンが Claude Code の deny rule を迂回する危険があるため。
  • WebSearch / WebFetch はドメイン許可リストの対象外(読み取りは別の脅威モデル)だが、取得した URL は秘密パターンでスキャンする。

4. 計測 — PostToolUse → DX、そして自分のメトリクスを見る

  • PostToolUse hook でツール実行を DX にイベント送信(fail-open)。セッション内で重複排除し、メール解決でユーザーを特定。
  • ダッシュボードで「スキル別・ツール別の利用状況」「Core4(Effectiveness / Impact / Quality / Speed)」「sentiment」を可視化。
  • Core4 の正体: getdx.com(Abi Noda)が DORA・SPACE・DevEx を1枚に統合した4次元フレーム。Speed=複雑度調整済みの週次マージ PR 数、Effectiveness=DXI(開発体験の14要素)、Quality=劣化を招いた変更割合、Impact=新機能に割いた時間割合(getdx)。→ ai生産性パラドックス_メトリクス起点の改善ループ_整理 の「可視化→改善ループ」と同じ土台。
  • 面白いのは エージェント自身が DX メトリクスを MCP 経由でクエリして行動に反映する点(自分の効果を見て動く)。

5. ナレッジ管理 — 人間の会話から知識を自動抽出

  • 日次チャンネルナレッジ抽出: 前日の人間の Slack 会話からドメイン知識を自動抽出・提案。
  • LangMem ベースの自動メンテナンス: Slack スレッドの知識を登録し、既存エントリを更新・削除(LangChain のメモリ基盤)。
  • 機械可読なドメイン情報(リポジトリ一覧・監視チャンネル一覧)を自動同期。
  • 勘所: 現場の会話が知識源(signal source)。→ 法務経理ai_芯_現場はsignal源_1枚整理 と同じ発想。

6. スケジューラとセッション管理

cron ベースの自律実行を YAML で宣言的に定義:

- name: xxxx-weekly-alert-digest
  enabled: true
  cron: "0 11 * * 1"               # 毎週月 11:00 JST
  timezone: "Asia/Tokyo"
  active_deadline_seconds: 600     # 10 分でタイムアウト
  backoff_limit: 1                 # 1 回リトライ
  concurrency_policy: forbid       # 多重起動抑止

セッションのライフサイクル(起動コスト最適化):

状態
コールドスタート 約 30 秒
ウォーム起動 約 2〜3 秒
アイドルタイムアウト 約 30 分で切断
session_ttl 約 1 週間で破棄

7. プラットフォーム化 — マルチテナント

  • remote-claude再利用可能なエージェント基盤にし、テナントを載せる: pcp-agent(決済)/ remote-claude-sre(SRE)/ remote-claude-n8n(ワークフロー自動化)
  • 共有基盤が提供: Slack 統合・セッション隔離・cron スケジューラ・auth-proxy・フック機構・PII リダクション・リソース制限(メモリ/PID/CPU)。
  • 各テナントは差分(.claude の CLAUDE.md・スキル・ルール)だけ持つ。基盤は共通、個性は .claude に閉じる。

8. 自分の設定・プロジェクトとの接点(メモ)

この事例は自分が個人でやっていることの本番・組織版で、対応がきれいに付く。

  • PreToolUse fail-closed: 自分の ~/.claude/scripts/block-secret-file-reads.shgitleaks-precommit.sh(PreToolUse hook)と同じ思想。「秘密ファイルの読み出しをブロック」「検出時はコミットを止める」は既に実装済み。fail-closed(想定外は危険側に倒さない)を明文化しておくと強い。
  • auth-proxy でトークン非保持: 自分の .env.op + op run(生キーを置かず注入実行)と同じ「漏れる対象を構造的に消す」発想の、ネットワーク層版。~/.claude/docs/secret-handling.md の whitelist 反転設計と地続き。
  • deny > ask > allow の権限層 / dontAsk での無人運用: 自分の settings.json の4層権限と同型。cron/headless を dontAsk で回す方針の実例として使える。
  • 確率の防御 vs 構造の防御: ~/ai-engineering-study/lectures/guardrails_basicssandbox_basics で学んだ「どの防御がどのフックに化けるか」「コンテナ隔離=構造の防御」がそのまま5層に対応。
  • cron 駆動の自律エージェント: ~/research-orchestrator~/temporal-workflows と同じ無人運用。あちらは Temporal、こちらは Claude Code ネイティブ + 自前スケジューラ、という実装差。
  • 決済ドメイン: persona-fintech の関心(決済オペレーション自動化)ど真ん中。

9. まとめ — いつ・何を効かせるか

局面 この事例の打ち手
AI を自律で動かしたい Ambient Agent(トリガー駆動)+ Claude Code をランタイム化
決済ドメインで安全に回す 5層防御。安全ゲートは fail-closed、計測は fail-open
認証情報を守る auth-proxy でトークン非保持(エージェントに本物を渡さない)
効果を測る PostToolUse → DX、Core4 で可視化、エージェントも自分の指標を見る
知識を腐らせない 人間の会話から日次自動抽出(LangMem)+機械可読ドメイン情報の同期
横展開する 共有基盤をマルチテナント化、個性は .claude の差分だけ

一言: 決済という「間違えたら終わり」のドメインで自律 AI を回す鍵は、賢さより「倒れる方向を設計する」こと。安全ゲートは fail-closed、認証は非保持、環境は使い捨て隔離 ── 確率(プロンプト)でなく構造で守り切る。


参考リンク


作成: 2026-07-02 / 最終更新: 2026-07-02