10月28日、StartupHub.aiが「Stripe lets AI agents move money, with guardrails」と題した記事を公開した。StripeがAIエージェントから実際の送金を可能にするCLIコマンドを提供し、複数段階の承認フローによってリスクを制御する仕組みについて詳しく紹介されている。
なぜ今、Stripeはこの機能を出したのか
OpenAI Function CallingやAnthropic Tool Useの普及により、AIエージェントが外部APIを「ツール」として呼び出し、自律的にタスクをこなすアーキテクチャが急速に広まっている。こうした設計は一般にTool-calling（Function calling）と呼ばれ、エージェントがコードの実行・検索・フォーム送信などを人間の逐一指示なしに行えるようにするものだ。
その延長線上で次の課題として浮上しているのが「AIエージェントに金融操作をさせること」だ。ECの自動発注・フリーランサーへの報酬送金・SaaSの課金処理など、ビジネスプロセスの自動化においてマネームーブメントは避けられない。一方でPayPalやAdyenといった決済プラットフォームも同様の自動化ニーズに対応しつつあり、決済インフラ企業にとってAIエージェント対応は競争上の優先課題になりつつある。こうした文脈の中でStripeが公開したのが、今回紹介する「Stripe Treasury for agents」を中核とした送金機能だ。
AIエージェントが「本物のお金」を動かす
Stripeが公開したドキュメントによると、AIエージェントはCLIコマンド一つで送金を実行できる。コマンドは stripe pay で、Stripeの内部金融口座（Financial Account）から別のビジネスへインスタント送金を行う。
stripe pay @recipient 10.00 usd --agent
これはシミュレーションではなく、実際の資金移動だ。
対話式ターミナルであれば受取人・金額・通貨をプロンプト入力できるが、--agent または --json フラグを付けると、これら3つをすべてコマンド引数として渡す必要がある。エージェントが自律的に動作する状況を想定した設計だ。
基盤となる「Stripe Treasury for agents」は、Stripe内部で資金を保持するAPIアクセス可能なFinancial Accountを中心に構築されている。Stripe TreasuryはStripeが提供するBanking-as-a-Service APIであり、Financial Accountはその中核をなす資金保持口座で、残高管理・送受金・カード発行などをAPI経由で操作できる。複数のFinancial Accountが存在する場合は --financial-account fa_... で明示指定が必要になる。
セキュリティの要は「確認フロー」の多段構造
エンジニアが最も注目すべきポイントは、送金が即座に実行されない設計になっている点だ。stripe pay を実行すると、まず confirmation_required が返される。資金はこの時点では動かない。
送金を確定させるには以下の手順を踏む：
stripe whoamiで認証済みアカウントを確認- 返却された送金元口座・受取人・金額・通貨・手数料・到着タイミング・メモを目視確認
- 確認後、
--yesと--financial-accountを明示した上で同一コマンドを再実行
ポリシー設定によっては approval_required が返される場合もある。この場合、Stripeは approval_url と、人間が承認後に実行すべき next_step.command を提供する。あるいは approvals_dashboard_url 経由でチーム全員がダッシュボード上で承認を行い、それをトリガーに送金が自動実行される。
承認フローには厳しい時間制限がある
承認待ちのリクエストにはいくつかの制約がある。
- 承認はポーリング不可（ループで状態確認することはできない）
- Resumable approvalの有効期限は5分
- 却下または期限切れになった場合、
--approval-idの再利用は不可 - やり直す場合は確認ステップから最初からやり直し
この設計はエージェントが「承認待ちの間に別の処理を走らせる」ような動作を前提にしていない。承認が下りるまで待つか、タイムアウト後に再度処理を始めるか、のどちらかだ。
リスクなしで試せる --dry-run
本番環境に影響を与えずに動作を検証したい場合のために、--dry-run オプションが用意されている。ドライランはプロファイル・口座・受取人・送金レール（rail）の解決まで行うが、プロファイルの作成・承認リクエスト・実際の送金は一切発生しない。
ただし、ドライランであっても最終バリデーションを完了させるには --yes が必要だ。
「Human-in-the-loop」を明示的に組み込んだ設計思想
金融操作はTool-callingのユースケースの中でも最もリスクが高いカテゴリに属する。誤送金・不正操作・エージェントの誤判断による意図しない資金移動は、サービスの信頼性を根本から損なうリスクがある。
Stripeのアプローチの核心は、エージェントに送金能力を与えながらも、人間の承認ゲートを明示的にフローに組み込む点にある。これはHuman-in-the-loopと呼ばれる設計思想で、自律的なシステムが重要な判断を下す前に人間の確認・介入ステップを挟む手法だ。AI安全性の文脈では特に高リスクなアクションに対して推奨されるアプローチとして広く議論されており、今回のStripeの実装はその金融領域への具体的な適用例といえる。
confirmation_required → 人間目視 → approval_required → チーム承認 という多段構造は、完全自律を志向しながらも現時点では人間の判断を保険として外せないという、業界全体の現在地を反映しているとも読める。
詳細はStripe lets AI agents move money, with guardrailsを参照していただきたい。
