2026-09-01 · teai.io team · 6 min read

AIが銀行にFAXを送った日 —
teai MCPが「送信インフラ」になった

今朝、ある銀行の海外送金手続きで「確認書類はFAXでのみ受け付けます。メール添付はセキュリティ上自動削除されます」という要件にぶつかった。 2026年の日本では、これはまだ普通に起きる。前回は対応が間に合わず送金がキャンセルされた。

今回はAIエージェントが自分でオンラインFAXサービスにログインし、送付状つきのPDFを組み立てて送信した。相手先は3回話し中だったが、自動リトライで4ページを送達。銀行からは同日中に受付返信が来た。

で、思った。FAXが送れるなら、LINEも、Telegramも、Slackも、物理の手紙も、メールも、同じ形でエージェントのツールにできるはずだ。 その日のうちに全部つくって本番に出した。この記事はその設計メモ。

できたもの: 6つの送信サービス

サービス	ツール	上流	価格
`/mcp/fax`	`fax_send` / `fax_status`	Phaxio	600 cr(最大5ページ)
`/mcp/line`	`line_send`	LINE Messaging API(自分のチャネル)	6 cr
`/mcp/telegram`	`telegram_send`	Telegram Bot API(自分のbot)	6 cr
`/mcp/slack`	`slack_send`	Slack(webhook / bot token)	6 cr
`/mcp/letter`	`letter_send`(物理郵便)	ClickSend(自分のアカウント)	6 cr
`/mcp/email`	`email_send`	Resend(自分のキー)	6 cr

faxだけteai側の回線を使うので従量600クレジット。それ以外はBYOK(自分の鍵を持ち込む)方式で、上流の費用は自分のアカウントに直接かかるため、teai側は一律6クレジット。

鍵の置き場所: vault

BYOKで一番大事なのは鍵の扱い。LINEのチャネルトークンやResendのAPIキーを会話ログやプロンプトに流したくない。そこでユーザーごとのシークレット保管庫(vault)を作った。

登録は認証済みHTTP APIのみ(MCPツール経由では登録できない=LLMの会話に鍵が流れない)
保存はAES-256-GCMでサーバ側暗号化。一覧APIは末尾4文字のマスク表示のみで、生の値は二度と返さない
同じプロバイダーにラベル付きで複数の鍵を登録できる(例: LINE公式アカウントをブランド別に6本)

# 鍵を登録(例: LINE公式アカウントのチャネルトークン)
curl -X POST https://api.teai.io/api/v1/vault/keys \
  -H "Authorization: Bearer $TEAI_API_KEY" \
  -d '{"provider":"line","label":"mybrand","value":"<channel access token>"}'

# 送信(MCP tools/call)
curl -X POST https://api.teai.io/mcp/line \
  -H "Authorization: Bearer $TEAI_API_KEY" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{
    "name":"line_send",
    "arguments":{"key_label":"mybrand","to":"U…","message":"こんにちは"}}}'

悪用させないための線

送信インフラは便利さと同じだけ悪用リスクがある。最初から次の線を引いた。

送信系ツールは本人確認済みアカウント限定(teai.ioに支払い手段を登録済みであること)。未確認アカウントはクレジットを1つも消費せずに弾かれる
FAXはE.164形式の検証と緊急通報番号(110/118/119)への送信ブロック
サービスごとに1ユーザー1日あたりの送信上限(fax 20件・その他100件)
すべての送信は監査ログに記録(宛先と本文冒頭のみ・鍵は記録しない)
上流呼び出しが失敗したら自動返金

正直に書いておく: 現時点の「本人確認」は支払い手段の登録をもって近似している。厳密なKYCではない。判定は1つの関数に閉じ込めてあり、本人確認サービスを導入したらそこだけ差し替える設計にしている。

実際に動いた記録

FAX: 銀行宛4ページを送達(相手先話し中×3→自動リトライで成功)。送達通知メールも確認
Telegram: telegram_sendをMCP経由で実打→実受信・6クレジット課金まで本番確認
LINE: line_sendで公式アカウントから1:1トークへ実送信→実受信を確認
メール: email_send(Resend)をMCP経由で実打→検証済みドメインから実受信・課金まで本番確認

なぜMCPでやるのか

エージェントに「送る」力を渡すとき、個別のSDKを組み込む方式だとエージェントの数だけ実装が増える。 MCPツールにしておけば、Sente(teai公式CLI)でも、MCP対応の他のエージェントでも、teaiのAPIキー1本で同じ送信手段が使える。鍵の保管と本人確認とレート制限と監査をゲートウェイ側で一度だけやればいい。

FAXしか受け付けない窓口は、これからも当分なくならない。だったら、そこに合わせる面倒はインフラに吸わせて、人間は判断だけすればいい。

teaiキーを取得 MCPゲートウェイの全サービス