社内のSaaS（SaaS。クラウド上でソフトウェアを「サービスとして」利用する契約形態）にAIエージェントがAPI経由でアクセスし始めたら、監視設計はどう変わるでしょうか。CRMや問い合わせ対応ツールの運用を担当しているSRE・インフラ担当者に向けて、この変化が障害対応と監視にどう影響するか整理します。
米国のSalesforceやAdobeは2026年に、画面操作を前提としない「ヘッドレス」なAPI基盤を相次いで公開しました。Salesforce Headless 360、Adobe CX Enterpriseがその例です。これらはAIエージェントがダッシュボードを一切開かずに、ケース更新やキャンペーン実行を直接実行できる窓口です。人間向けの画面（いわゆるビューレイヤー）を介さず、エージェントが裏側の処理を直接呼び出す構成だと理解すると分かりやすいです。
SaaSからSaSへ、呼び出し経路が増えるという変化
この動きは「SaaS」から「SaS」への移行と呼ばれています。SaaSはSoftware as a Service（ソフトウェアをサービスとして提供する）の略です。SaSはService as Serviceではなく、Service as Software（業務サービスそのものをソフトウェアとして売る）という意味で、意図的に頭文字のAを一つ減らした造語です。
従来のSaaS運用では、人間がブラウザでログインし、画面を操作してリクエストを送っていました。アクセスログやAPM（アプリケーション性能監視）のトレースも、この「人間のセッション」を前提に設計されているケースが大半です。
SaSの世界では、エージェントがAPIを直接呼び出します。Salesforceが公開したMCP（Model Context Protocol。AIエージェントが外部ツールやデータに安全にアクセスするための標準プロトコル）Headless 360では、Discover、Describe、Dispatch、読み取り専用Dispatchという4つの操作だけがエージェントに公開されています。画面上のボタンが数千個あっても、エージェントが触れるのはこの4つの「動詞」だけという設計です。
監視の観点で重要なのは、呼び出し元の種類が増えるという事実です。人間のセッション、既存の業務システム間連携（バッチやWebhook）に加えて、エージェントからの非同期・自律的な呼び出しが新たに加わります。アクセス元を区別できないまま監視していると、障害発生時の原因切り分けが一段と難しくなります。
障害が起きたとき、何が変わるか
エージェント経由のAPI呼び出しが増えると、従来の障害対応フローに3つの見直しポイントが出てきます。
- 呼び出し元の識別: エージェントからのリクエストにAPIキーやクライアントIDが紐づいているか。ログにエージェント名・タスクIDが残る設計になっているかを確認します
- レート制御の単位: 人間は1クライアントあたり同時接続数が少ないですが、エージェントは短時間に大量のDiscover・Describe呼び出しを発行する可能性があります。既存のレート制限がAPI単位か、クライアント単位かを確認します
- 失敗時のリトライ挙動: エージェントが自律的にリトライするロジックを持つ場合、障害発生時にリクエストが増幅する現象が起きやすくなります
ここで言う根本原因分析（RCA。障害の直接原因だけでなく背景要因まで掘り下げる手法）では、従来「誰がどの画面で何をしたか」を追っていた部分を、「どのエージェントがどのツール呼び出しを、どの契約（コントラクト）に基づいて実行したか」に置き換える必要があります。MCPの文脈では、エージェントが呼び出す操作の仕様書を「契約」と呼ぶことがあり、この契約とログの紐付けが曖昧だと、障害の切り分けに時間がかかります。
オンプレミスからクラウドに移行した経験がある方なら、API Gatewayやサービスメッシュ導入時に似た課題に直面したはずです。あのときは「サービス間通信の可視化」が課題でした。今回は「エージェント対システムの通信の可視化」が同じ構造で求められています。
コスト面で見ておきたいポイント
運用コストの観点でも変化があります。従来のSaaS課金は「シート数（ユーザー数）」に連動するケースが一般的でした。SaS型のAPI利用は、呼び出し回数や処理したトランザクション量に応じた従量課金に寄るケースが想定されます。
監視基盤でAPIコール数をメトリクスとして収集していない場合、コスト急増に気づくのが請求書が届いたタイミングになってしまいます。クラウドの従量課金サービス（AWS LambdaやAPI Gatewayなど）で経験済みの「コストアラート設定」のノウハウを、SaaSベンダーのAPI利用量にも適用する発想が必要です。
今日確認できること
自社が使っているSaaSベンダーが、ヘッドレスAPIやMCP対応窓口を既に公開しているか確認するのが最初の一歩です。Salesforceであれば管理コンソールの「Headless 360」設定、Adobeであれば「CX Enterprise」関連のドキュメントを確認します。
具体的な確認手順は次の通りです。
# 例: APIゲートウェイ側のログからエージェント系クライアントIDの有無を確認
grep -i "agent" api_gateway_access.log | wc -l
# 短時間に集中したリクエストパターンがないか確認
awk '{print $1}' api_gateway_access.log | sort | uniq -c | sort -rn | head -20既存の監視ダッシュボード（Datadog、New Relic、CloudWatchなど）で、API呼び出し元ごとのメトリクスを分割できるかも確認しておきたいポイントです。できない場合は、タグ付け設計の見直しが必要になります。
まとめ
SaaSベンダーがヘッドレスAPIを公開する動きは、画面を介さないエージェントからのアクセスが増えることを意味します。
監視設計では、呼び出し元の識別、レート制御の単位、リトライ挙動によるリクエスト増幅の3点を見直す価値があります。
コスト面では、シート課金から従量課金への移行を見越して、API呼び出し量に対するアラート設定を検討しておくと安心です。
まずは自社の主要SaaSベンダーの管理画面で、ヘッドレスAPIやMCP対応の有無を確認するところから始めてみてください。