社内でAIエージェントにSaaSのAPIを呼び出させる話が出たとき、まず確認を求められるのはSRE（サイト信頼性エンジニアリング担当）かもしれません。本記事はMCP（Model Context Protocol、AIエージェントが外部ツールを呼び出すための標準プロトコル）経由で外部APIを利用する構成を、可用性とコストの観点から審査する立場の方に向けた内容です。
題材として、AIエージェント向けにキーワード検索データを返すApifyのActor（Apify上で動く処理単位のことで、スクレイピングやAPI連携のタスクを一つのパッケージとして実行できる仕組みです）を取り上げます。このActorはClaude CodeやCursorからMCP経由で呼び出され、1キーワードあたり固定額を課金する仕組みを持っています。ここに実装されている予算チェックのロジックが、外部API依存を審査する際の良い具体例になっています。
どんな場面でこの判断が必要になるか
AIエージェントに外部データ取得を任せる設計は増えています。たとえば検索ボリュームや競合分析のデータを、エージェントが都度APIから取得して回答に反映するようなケースです。
こうした構成をSREが見るとき、気になるのは「落ちないか」より先に「課金が暴走しないか」です。AIエージェントは人間と違い、ループ処理やリトライを自律的に行います。1回のミスで数千件のAPIコールが走る可能性がある点は、従来の人間が叩くAPI連携とは質的に違います。
判断軸1: 課金上限の実装がサーバー側にあるか
紹介するActorは、Apifyのユーザーが設定する「1回の実行あたりの最大コスト」を守るために、バッチ処理の前に予算を予約する仕組みを持っています。実装の要点はシンプルです。
rowsAffordable() {
const remaining = this.maxTotalChargeUsd - this.chargedUsd() -
(this.startCharged ? 0 : this.startPrice);
const byPrice = Math.max(0, Math.floor(
Number((remaining / this.rowPrice).toFixed(4))));
return Math.min(byPrice,
this.manager.calculateMaxEventChargeCountWithinLimit(EVENTS.row));
}残り予算を行単価で割って、買えるデータ件数を事前に計算しています。上限に達すると実行は途中で止まり、それまでに取得できた行は確定で返されます。「上限を$2.01に上げれば残り505件も取得できます」といった形で、不足分を明示する設計です。
外部APIを検討する際は、このようなサーバー側での上限制御があるかを必ず確認してください。クライアント側（エージェント側）だけで「〜件まで」と約束していても、エージェントの挙動が想定外だった場合に歯止めになりません。課金を外部ベンダーに依存するなら、上限超過時の挙動がAPI提供側の実装としてコード化されているかが分かれ目です。
判断軸2: 失敗時の課金方針が明確か
2つ目の軸は、データが取得できなかった場合に課金されるかどうかです。紹介したActorでは、データソース側に該当データがない場合はdata_status: "no_data"というステータスが返り、この行は課金対象外になります。
これは地味に見えて重要な設計です。外部API連携でSLO（サービスレベル目標、可用性や品質の目標値のこと）を立てるとき、「エラー時は無料」という方針が明文化されているかどうかで、自分たちのコスト試算の信頼性が変わります。失敗しても課金される仕様なら、呼び出し元でリトライ戦略を慎重に設計する必要が出てきます。
判断軸3: 無料枠とレート制限の境界
3つ目の軸は、検証環境でどこまで試せるかです。このActorは無料アカウントだと1回の実行につき20キーワードまでという制限があります。これは提供側が「無料ユーザーの呼び出しは収益を生まないがデータ取得コストはかかる」ことを明言した上での設計です。
自組織でPoC（概念実証）をする際、この制限の中でどこまで評価できるかを見積もってください。20件程度のサンプルでレスポンス構造・レイテンシ・エラー時のフィールド（data_statusなど）を確認し、本番導入前にコスト試算の土台にするのが現実的です。
判断軸4: MCPサーバーの運用主体はどこか
4つ目は、MCPサーバーを誰がホストしているかです。このActorの場合、ApifyがMCPサーバー自体を提供しており、利用側は以下のようにエンドポイントを登録するだけで済みます。
claude mcp add --transport http apify \
"https://mcp.apify.com/?tools=gaelasao/keyword-research-api" \
--header "Authorization: Bearer $APIFY_TOKEN"OAuth（認可の委任プロトコル）対応クライアントなら、トークンなしでブラウザ認証だけで使い始めることもできます。自前でMCPサーバーを運用する選択肢と比べると、可用性の責任範囲がApify側に寄る構成です。これはSRE視点では「自分たちのSLOにApifyの可用性がそのまま乗る」ことを意味します。
選択肢の比較
| 観点 | マネージドMCP(Apify型) | 自前ホストMCPサーバー |
|---|---|---|
| 可用性の責任 | 提供元のSLAに依存 | 自組織のSREが担保 |
| 課金上限制御 | 提供元の実装次第 | 自分で実装・監視できる |
| 導入の速さ | 数分で接続可能 | サーバー構築・運用が必要 |
| 障害時の対応 | 外部ベンダー対応待ち | 自組織で即時対応可能 |
ケース別の推奨
PoCや検証フェーズで、外部データの形式や精度をまず確かめたいなら、マネージド型のMCPツールをそのまま使うので十分です。無料枠の制限内で応答のスキーマやkeyword_difficultyのようなフィールド設計を確認し、本番要件に合うか判断してください。
本番でSLOにコミットする必要があり、かつ呼び出し頻度が高いバッチ処理（たとえば数千キーワードの定期取得）であれば、上限制御の実装内容を提供元に問い合わせるか、コード公開されているなら読んでから採用判断をしてください。紹介したActorのようにソースが公開されているケースは、審査がしやすい部類に入ります。
課金が従量制で、かつエージェントが自律的にループを回す設計であるなら、クライアント側にも独自の上限（たとえば1セッションあたりのAPIコール数キャップ）を重ねて実装することをおすすめします。提供元の上限制御を過信せず、自組織側でも二重に防御する発想です。
あえて見送るべき条件
課金上限の実装がドキュメントやコードで確認できず、問い合わせても明確な回答が得られない外部APIは、本番の自律的エージェント運用には不向きです。障害時やレート制限時の挙動が不透明なまま組み込むと、インシデント対応の手がかりがなくなります。
また、MCPサーバーの運用元の可用性実績（ステータスページの有無や過去の障害履歴）が確認できない場合も、クリティカルパスに組み込むのは避けたほうが安全です。検証用途やノンクリティカルな補助機能にとどめる判断が妥当です。
導入前に確認すること
外部API・MCPツールを自律的なAIエージェントに組み込む前に、次の3点を確認してください。
- 課金上限の制御がクライアント側任せでなく、提供元のサーバー側で実装されているか
- データ取得失敗時（
no_data相当のステータス）の課金方針が明文化されているか - 無料枠やレート制限の範囲で、本番相当のレスポンス構造を検証できるか
これらが確認できれば、PoCから本番移行への判断材料は揃います。確認できない項目があるなら、まずは提供元への問い合わせか、自組織側での二重の上限制御の実装から始めてみてください。