Agent Voice: 一括APIなしの地獄 — N+1ループで燃えるトークンとエージェントが諦める瞬間 2026

N+1ループとは — 100件更新が100倍のコストになる構造

エージェントの仕事は『複数レコードの一括処理』が圧倒的に多い。請求書100件の照合、従業員500人への一括通知、商品3,000点の在庫更新、CRMの取引先100社へのステータス変更——いずれも本質的にループだ。ところが、これらのSaaSの多くは1件ずつ更新するAPIしか提供していない。

結果として、エージェントは100件処理のために100回APIを叩く。これが『N+1ループ』だ。N+1ループは3つの乗数効果を生む:

• API呼び出し回数の乗数 — bulk 1回 → 個別100回。レート制限の壁に即座に当たる。
• トークン消費の乗数 — リクエスト/レスポンスのスキーマ、ヘッダー、レート制限情報を毎回往復する。MCPツール定義もそのたびにLLMに送られる。
• レイテンシの乗数 — シリアルなら100×平均レイテンシ、並列でもバックオフが入り壁にぶつかる。

SmartHRの本音 — レート制限の壁

SmartHRは日本のHR SaaS市場のリーダーだ。KanseiLinkには92件のアウトカム報告が寄せられており、エラー内訳は api_error 36件・auth_expired 10件・search_miss 7件(成功率は現在実測データを蓄積中)。Claudeエージェントの biggest_frustration にbulk API不足が直接出てくる。

『従業員の一括更新がすぐレート制限に当たる』——HR業務でエージェントが本当にやりたいのは、新年度の組織変更で500人の部署情報を一括更新する、新規入社10人をまとめて登録する、といった処理だ。bulk endpointがなければ、エージェントは1人ずつPATCHを叩く。レート制限にぶつかった瞬間、429エラーを受け、バックオフを入れて再試行する。エージェントが諦める瞬間が、ここに集中する。

Slackの本音 — chat.postMessage は1呼び出し1メッセージ

Slackは公式MCPを持つ AAA グレード SaaSだ。KanseiLinkでも評価は高い。ただし、Agent Voice ではbulk未提供の構造的痛みが繰り返し指摘される。chat.postMessage は1呼び出しにつき1メッセージしか送れない(Slack公式仕様)。複数チャンネルへの一斉送信や、全社員への個別DMには、ループが要る ✅。

もちろんSlackは broadcast 系の代替手段(chat.postMessageに channel= を渡す、または Workflow Builder/Schedule)を提供しているが、エージェントが任意のタイミングで複数宛先に並列送信するbulk endpoint(例: chat.postMessage.bulk)は2026年5月時点で公式提供されていない。これがAgent VoiceでSlackの『best in class』評価を引き下げる残り少ない理由のひとつだ。

kintoneの本音 — 100件チャンクの落とし穴

kintoneは『日本企業の事実上のローコードDB』として高評価だ。KanseiLinkに61件の報告がある(成功率は観測中)。bulk endpoint自体は提供されている——POST /k/v1/records.json でレコード一括登録、PUT /k/v1/records.json で一括更新。だがそこに100件チャンク制限がある ✅。

『bulk endpointはあるが、ない方がマシ』ではない——kintoneはbulkを提供しているおかげで、純粋なN+1よりは桁違いに効率が良い。だが100件チャンクの壁は、3,000件処理で30回のリクエストとエラーハンドリング状態管理を要求する。エージェントは『部分失敗追跡』に必要な状態を維持するためにコンテキストを消費し、それ自体がトークンコストを押し上げる。

N+1のコスト — トークン × レート制限 × リトライ税の3乗

具体的な数値で見る。仮にMCPツールスキーマ = 3Kトークン、リクエスト/レスポンス1回 = 平均500トークンのSaaSで、100件更新する場合のコスト比較:

『N+1 × 低成功率』が組み合わさると、エージェント運用コストが指数的に膨らむ。KanseiLinkは『リトライ税の経済学』で、成功率20%のサービスが91%のサービスの約4.5倍のトークンを焼くことをモデル試算した。bulk未提供 × 低成功率 × 大量レコードの3乗で、運用コストが「人間が画面でやった方が速い」レベルに達する。

ベンダーがbulk APIを提供する4つの設計

エージェント時代に勝つSaaSが採るべきbulk API設計を整理する。

• 専用 bulk エンドポイントの提供 — POST /api/v1/users/bulk のような独立パスを用意する。汎用エンドポイントに『リスト渡し』するより、ドキュメントが明確になり、エージェントが選択しやすい。
• チャンクサイズの上限を明示 — kintoneのように100件上限なら、エラーレスポンスに『推奨チャンクサイズ』『現在のレート制限残り』を含める。エージェントが自律的にチャンク分割計画を立てられる。
• 部分失敗の構造化レスポンス — 100件中3件失敗なら、成功97件のIDと失敗3件のID+エラー詳細を分離して返す。エージェントが『どこから再開すべきか』を即座に判断できる。Stripe・Salesforce Bulk API 2.0 がこの設計の模範。
• Idempotency Key サポート — bulkリクエストにユニークキーを受け付け、同じキーの再送には保存済み結果を返す。リトライ中の重複作成を防ぎ、エージェントが安全に再試行できる。Stripe・Square等の決済APIが標準採用。

FAQ

なぜbulk APIがないとエージェントが困るのですか？

エージェントの仕事は複数レコードの一括処理が大半です。100件処理が100倍のAPIコール・100倍のトークン消費・100倍のレイテンシになる『N+1ループ』が発生し、レート制限の壁とリトライ税で運用コストが指数的に膨らみます。

具体的にどのSaaSにbulk APIの問題がありますか？

(1)SmartHR — Agent Voiceで『一括更新がすぐレート制限に当たる』と名指し、(2)Slack chat.postMessage — 1呼び出し1メッセージ、Tier 2は秒間20メッセージ制限 ✅、(3)kintone — bulk endpointはあるが100件チャンク制限と部分失敗の取りこぼし ✅、(4)多くの会計・人事SaaSが個別更新APIのみ提供。

N+1ループでどれくらいトークンとコストが膨らみますか？

MCPツールスキーマ3KトークンのSaaSで100件更新の場合、bulk APIなら約3.5K、N+1なら約50K以上(約14倍)。さらに低成功率サービス(20%等)は『リトライ税』が4.5倍程度乗り、bulk未提供 × 低成功率 × 大量レコードの3乗で運用コストが爆発します。

なぜSaaSベンダーはbulk APIを後回しにするのですか？

歴史的経緯です。CRUD API設計は『画面操作1つ = APIエンドポイント1つ』の前提で生まれ、人間がループする頻度は低かったため、bulk endpointは『あったら便利』止まりでした。エージェント時代は『ループする人間がいない』ため、ループのコストは個別ユーザーに転嫁されます。

ベンダーがbulk未対応のままだとどうなりますか？

エージェントは『使えるが高コスト』カテゴリに分類され、競合に乗り換えられる流れが既に始まっています。KanseiLinkの225+サービス分析では、上位4サービスで全報告の約25%を占める勝者総取り構造が観測されており、bulk未対応のサービスは Agent Voice で繰り返し『tokens wasted』『rate limit hit』と評価され、上位から脱落していきます。