API連携AIエージェントのテスト方法：データ損失を防ぐ

AIコーディングエージェントがスクリプトを実行し、それが成功するのを見届けた後、本番データベースのテーブルが消滅しました。Hacker Newsの事後報告は、「AIがデータベースを削除したのではない、あなたがしたのだ」という鋭いタイトルで瞬く間に広まりました。この指摘は真実であるため、心に響きました。エージェントはツール定義に従い、ツールは実際のエンドポイントにアクセスし、そのエンドポイントにはガードレールがなく、人間はDELETE FROM usersが疑わしいかどうかを立ち止まって問わないプロセスに鍵を渡していたのです。別のr/ClaudeAIのスレッドでは、異なる角度から似たような話が語られました。課金ループに陥ったエージェントが、誰も気づく前に数百ドル分のトークンを消費してしまったのです。表面は違えど、同じ種類の失敗です。問題はモデルが賢くないことではありません。問題は誰もAPIをテストしていなかったことです。

💡

APIを呼び出す自律エージェントを出荷しているなら、このガイドはあなたのためです。エージェント開発中に外部エンドポイントをモックする方法、破壊的な操作をサンドボックス化する方法、ツールスキーマのコントラクトテストを作成する方法、エージェントごとの予算上限を設定する方法、そして本番環境に影響が出る前に障害モードをリハーサルする方法を学びます。テストの足がかりにはApidogを使用します。ApidogはネイティブでOpenAPIを理解し、グルーコードなしでモックサーバーを実行でき、エージェントのツール呼び出しシーケンスにきれいにマッピングされるシナリオテストを提供します。

ボタン

要約

エージェントは、ツールにAPI側のガードレールがない（レート制限の欠如、冪等性の欠如、ホットな削除、破損したスキーマなど）場合に本番環境で失敗します。これを解決するには、4つの対策が必要です。エージェントのツール定義をOpenAPI仕様に対してコントラクトテストし、破壊的なエンドポイントに対してモックサーバーを実行し、エージェントごとの予算と冪等性キーを強制し、CIで障害シナリオを再現します。Apidogは、OpenAPIのインポート、モック、シナリオランナーをすべて1つのプロジェクトで提供します。

はじめに

1年前、「AIエージェントをテストする」とは、ClaudeやGPTにプロンプトを出し、その回答を評価することを意味しました。しかし、もはやそれは基準ではありません。今日のエージェントは関数を呼び出し、その関数はあなたのAPIにアクセスし、あなたのAPIは実際のデータベース、決済処理業者、サードパーティサービスと通信します。不適切なツール定義やレート制限の欠如は、スタイルの問題ではありません。それはあなたの名が刻まれる本番環境でのインシデントなのです。

今月話題になったHacker Newsの記事は、この変化を捉えていました。著者は、AIがデータベースを削除したのではなく、人間が、モデルとデータの間に何の制御も置かずにエージェントに書き込みアクセスを許可した結果だと主張しました。この記事は爆発的に広まりました。なぜなら、それを読んだすべての開発者が「私もあやうくあれを出荷するところだった」と考えていたからです。数週間前、Redditの投稿で、エージェントが失敗した呼び出しを何度も再試行したために、誰も気づく前に請求額が800ユーロを超えてしまった課金ループが記述されていました。根本原因は同じです。信頼を間違った層に置いていたのです。

これを修正できます。モデル層も重要ですが、流血を止めるのはAPI層です。この記事では、AIエージェントのAPI統合をエンドツーエンドでテストする方法を示します。すべてのエージェント-APIセットアップに必要な4つのガードレールについて説明し、破壊的なエンドポイントをモックするためのApidogワークフローをステップバイステップで案内し、スキーマドリフト検出やデュアルキー分離といった高度な技術で締めくくります。今日からあなたのリポジトリにコピーできる具体的なパターンを持って帰っていただけるでしょう。モックサーバーの手順に従うために、始める前にApidogをダウンロードしてください。

なぜエージェントの失敗がAPIの失敗に見えるのか

エージェントの事後報告を十分に読むと、あるパターンが現れます。それは、モデルが主役ではないということです。APIが主役なのです。

プロンプトインジェクションを考えてみましょう。ユーザーが隠された指示を含むPDFをアップロードし、エージェントがそれを読み込み、次のツール呼び出しがあなたの/admin/usersエンドポイントにdelete_all=trueとともに送信されます。モデルはこれを意図したわけではありません。信頼できない理由のない指示に従っただけです。修正はプロンプトを強化することではありません。修正は、ユーザーコンテキストセッションから来たトークンにdelete_all=trueを公開しないAPIを構築することです。OWASPはこれをLLMトップ10のLLM01と呼んでおり、その軽減策はプロンプトエンジニアリングではなく、API側の認可です。

不適切なツールスキーマを考えてみましょう。あなたのOpenAPI仕様ではamountがセント単位の整数であると記述されています。エージェントのツール定義ではamountがドル単位の浮動小数点数であると記述されています。3ヶ月後、誰かが19セントの請求を19ドルとして返金し、経理部門からその不一致を知ることになります。モデルは間違っていませんでした。モデルはあなたが与えたスキーマを使用したのです。スキーマがAPIから乖離していました。誰もコントラクトをテストしていなかったのです。

レート制限の欠如を考えてみましょう。エージェントのプランナーがステップを「まだ成功していない」とマークし続けたため、エージェントがリトライループに入り、2分間にあなたのトランザクションメールエンドポイントを1000回も叩いてしまいました。各再試行には費用がかかります。各再試行は実際のメールをキューに追加します。あなたが目を覚ます頃には、プロバイダーがあなたのアカウントを停止し、顧客はスパムメールを受け取っています。モデルは悪意があったわけではありません。モデルは上限のないツールから動作していたのです。

冪等性の欠如を考えてみましょう。エージェントが顧客に課金するためにPOST /paymentsを呼び出し、ネットワークタイムアウトが発生します。プランナーは呼び出しが失敗したと判断し、再試行します。その結果、顧客は二重に課金されてしまいます。エージェント層は最初の呼び出しが成功したかどうかを判断できません。APIはそれを問い合わせる方法を提供していませんでした。冪等性キーは、5行のサーバーコードでこれを解決しますが、自分で書く必要があります。

共通の糸口は、これらのインシデントのすべてにおいて、エージェントがそのツールが指示することを正確に行っているということです。ツールはAPIそのものです。したがって、エージェントの信頼性がどこで破綻するかを監査するときは、まずAPIコントラクト、次にエージェントハーネス、そしてモデル自体はほとんど見ません。この再構築は、どこに投資すべきかを示してくれるため重要です。より賢いモデルは必要ありません。ガードレールが有効になったテスト可能なAPIが必要なのです。

すべてのエージェント-API統合に必要な4つのガードレール

費用がかかる失敗をする設定と、安全に失敗する設定を分ける4つの制御があります。今四半期に1つだけ追加する時間があるなら、一番上から始めてください。もし4つすべてを実行できれば、2026年に遭遇するインシデントシナリオの90%以上をカバーできるでしょう。

1. ツールスキーマのコントラクトテスト

OpenAPI仕様は、あなたのAPIの信頼できる情報源です。エージェントは、しばしば手書きまたはドキュメントからコピー＆ペーストされた、別のツール定義を持っています。これら2つの成果物は常に乖離します。コントラクトテストは、それらが乖離した瞬間にCIビルドを失敗させます。

Claudeスタイルのツール定義をライブのOpenAPI仕様に対して検証する最小限のPythonチェックを以下に示します。

import json
from jsonschema import Draft202012Validator

def validate_tool_against_openapi(tool_def: dict, openapi_spec: dict) -> list[str]:
    """Return a list of mismatch errors, empty list = pass."""
    errors = []
    op = openapi_spec["paths"][tool_def["path"]][tool_def["method"].lower()]
    api_schema = op["requestBody"]["content"]["application/json"]["schema"]
    tool_schema = tool_def["input_schema"]

    api_props = set(api_schema.get("properties", {}).keys())
    tool_props = set(tool_schema.get("properties", {}).keys())

    for missing in api_props - tool_props:
        if missing in api_schema.get("required", []):
            errors.append(f"Tool missing required field: {missing}")
    for extra in tool_props - api_props:
        errors.append(f"Tool defines field not in API: {extra}")

    for prop, api_def in api_schema.get("properties", {}).items():
        if prop in tool_schema.get("properties", {}):
            tool_def_prop = tool_schema["properties"][prop]
            if api_def.get("type") != tool_def_prop.get("type"):
                errors.append(
                    f"Type mismatch on {prop}: API={api_def.get('type')} "
                    f"tool={tool_def_prop.get('type')}"
                )
    return errors

OpenAPI仕様またはツール定義のいずれかに触れるすべてのPRでこれを実行します。リストが空でない場合はビルドを失敗させます。この1つのチェックだけで、前のセクションのフロートとセントのバグを、払い戻しが行われる数ヶ月前に発見できたはずです。

2. 破壊的なエンドポイントのためのサンドボックスとモック環境

エージェントには練習する場所が必要です。本番環境で練習してはなりません。パターンは単純です。状態を変更するすべてのエンドポイントには、作業を行わずに同じ形式の応答を返すモック同等物があります。エージェント開発ループはモックを使用します。ステージングテストはサンドボックスデータベースを使用します。本番環境は、人間がデプロイを承認するまで手付かずのままです。

Apidogは、Fakerパターンによって駆動される現実的なフィールド値を含め、OpenAPI仕様から直接モックを生成します。エージェントのベースURLをモックサーバーに向け、プロンプトを100回実行し、その動作を監視します。エージェントがドキュメントを誤解して/users/{id}/deleteにPUTしようとし続ける場合、モックがそれを検出します。本番環境のユーザーテーブルがその間違いを見ることはありません。これに適合するより広いパターンについては、コントラクトファースト開発を参照してください。

3. 不可逆的な操作のための冪等性キーとソフトデリート

エージェントが呼び出すことができるすべての書き込みエンドポイントは、冪等性キーを受け入れるべきです。すべての削除は、デフォルトでソフトデリートであるべきで、人間が承認する別のハードデリートパスを持つべきです。

Expressでは、ミドルウェアは次のようになります。

const idempotencyCache = new Map();

function idempotency(req, res, next) {
  const key = req.headers['idempotency-key'];
  if (!key) {
    return res.status(400).json({ error: 'Missing Idempotency-Key header' });
  }
  if (idempotencyCache.has(key)) {
    const cached = idempotencyCache.get(key);
    return res.status(cached.status).json(cached.body);
  }
  const originalJson = res.json.bind(res);
  res.json = function (body) {
    idempotencyCache.set(key, { status: res.statusCode, body });
    setTimeout(() => idempotencyCache.delete(key), 24 * 60 * 60 * 1000);
    return originalJson(body);
  };
  next();
}

app.post('/payments', idempotency, createPayment);

エージェントは論理操作ごとにUUIDを生成し、再試行時にそれを再利用します。APIは、二重課金を避けるために、2回目の呼び出しでキャッシュされた応答を返します。この同じパターンは、メッセージングAPIでの二重送信、CRMでの重複行作成、およびその他のほとんどの「エージェントが再試行して混乱した」シナリオから保護します。

4. エージェントごとの予算上限

すべてのエージェントは予算を持ちます。トークン予算、リクエスト予算、ドル予算、時間予算。予算が尽きると、エージェントは停止します。例外はありません。800ユーロのRedditの事件は、暴走ループに上限が設定されていなかったために発生し、人間がチェックしたときには手遅れでした。

APIゲートウェイをラップする予算ミドルウェアは、以下を追跡するかもしれません。

セッションあたりのトークン数、50,000に制限
1分あたりのAPI呼び出し数、30に制限
累積消費額（セント単位）、500に制限
ツール呼び出しの深さ、ネストされた呼び出し10に制限

いずれかの制限に達した場合、HTTP 429と構造化されたRetry-Afterヘッダー、および上限の名前を示すX-Budget-Exceededヘッダーを返します。エージェントのプランナーは、その後、人間にエスカレートするか、タスクを巻き戻すことができます。これをログと組み合わせて、どのエージェントが制限に近づいているかを確認し、それに応じて調整できるようにします。

これらの4つの制御は複合的に機能します。コントラクトテストは明らかなスキーマの誤りを捕捉します。モックは破壊的な誤りを捕捉します。冪等性は再試行の嵐を捕捉します。予算は暴走ループを捕捉します。これらが連携することで、「エージェントがひどいことをした」という状況を「エージェントが429エラーを返し、問題をログに記録し、助けを求めた」という状況に変えます。これが基準です。

ApidogでエージェントのAPI呼び出しをテストする

それでは実践的な部分です。Apidogで完全なエージェント-APIテストワークフローをセットアップする方法を説明します。エージェントが呼び出すAPIのOpenAPI仕様と、エージェントのツール定義のリストが必要です。

ステップ1: OpenAPI仕様をインポートする

Apidogを開き、新しいプロジェクトを作成し、OpenAPI 3.xファイルをインポートします。Apidogはすべてのパス、スキーマ、および例を解析し、プロジェクトに対応するエンドポイントを作成します。まだAPIがOpenAPIで文書化されていない場合、これがその時です。エージェントの信頼性は、人間とAIエージェントの両方が読み取る単一の情報源を持つことに依存します。ゼロから始める場合は、デザインファーストAPIワークフローガイドを参照してください。

ステップ2: 破壊的なエンドポイントのモックレスポンスを定義する

データ変更を行うすべてのエンドポイントを見つけます。POST、PUT、PATCH、DELETEです。それぞれのエンドポイントをクリックし、モックレスポンスを追加します。Apidogはスキーマから現実的なモックを自動生成できますが、フィールド値を上書きして、本番データではなくテストデータのように見えるようにする必要があります。例えばmock_user_のようなプレフィックスや1970年のタイムスタンプを使用すると、ログで漏洩があった場合にすぐに分かります。

モックサーバーを起動します。Apidogはhttps://mock.apidog.com/m1/your-project-id/のような安定したURLを提供します。開発中はエージェントのAPIベースURLをモックサーバーに向けます。これで、DELETE /users/{id}は偽のユーザーペイロードとともに200を返し、実際のデータベースは安全です。

ステップ3: エージェントの呼び出しシーケンスをシミュレートするシナリオを作成する

Apidogのシナリオでは、テストスイートと同様に、アサーションを使ってAPI呼び出しを連鎖させることができます。サポートチケットをトリアージするエージェントの場合、シナリオは次のようになるかもしれません。

テスト認証情報で/auth/tokenをPOSTし、ベアラートークンをキャプチャする
そのトークンで/tickets?status=openをGETし、最初のチケットIDをキャプチャする
カテゴリ付きで/tickets/{id}/triageをPOSTし、200をアサートし、割り当て先フィールドをキャプチャする
テンプレート化されたメッセージで/notificationsをPOSTし、メッセージ本文が正規表現と一致することをアサートする

実質的に、エージェントがモックサーバー上で何をするか、そして各ステップでアサーションを使ってリハーサルしているのです。もし開発者がチケットスキーマを変更し、正規表現が一致しなくなった場合、シナリオは失敗し、エージェントが本番環境で問題を起こす前に知ることができます。より広範なシナリオテストのプレイブックについては、QAエンジニアのためのAPIテストを参照してください。

ステップ4: CIから実行する

Apidogには、GitHub Actions、GitLabパイプライン、または任意のCIランナーからシナリオを実行するCLIが付属しています。コマンドはapidog run -t scenario-id --env testのようになります。これをPRパイプラインにフックすることで、OpenAPI仕様またはエージェントツール定義へのすべての変更が、完全なシナリオの再実行をトリガーするようになります。

ステップ5: 2つのモデルバージョンを並べて比較する

あるモデルから別のモデルへのアップグレードを評価する場合、新しいモデルのツール呼び出しが同じシナリオで同じように動作するかどうかを知りたいでしょう。モデルAで同じApidogシナリオに対してエージェントを実行し、トレースをキャプチャします。モデルBで再度実行し、トレースをキャプチャします。リクエストボディを比較します。驚くべきことに、すぐに違いが現れます。モデルBが異なるpriority値を渡したり、フィールドを省略したり、異なる日付形式を使用したりします。これにより、行動のドリフトを出荷前に捕捉できます。これはGPT-5.5 API統合で取り上げられているパターンの1つで、新しいモデルの挙動を評価することが繰り返し必要とされます。

このワークフロー全体のセットアップは初回に約1時間かかり、それ以降は実行ごとに数分です。その見返りとして、APIまたはエージェントツールへのすべての変更が、同じ期待値の基準に対して検証されます。

高度なテクニックとプロのヒント

基本的な設定が完了した後、経験豊富なチームが利用するいくつかのパターンを紹介します。

テストでは温度をゼロに固定する。非決定的なエージェントは非決定的なテスト失敗を引き起こします。ツール呼び出しの動作をテストするときは、温度を0に設定し、乱数発生源をシードします。クリエイティブな層ではなく、ツール層をテストしているのです。

ツール呼び出しトレースのスナップショットを作成する。すべてのテスト実行で、エージェントが行ったツール呼び出しの正確なシーケンスを引数とともに記録します。以前のベースラインと比較します。もしエージェントが突然/usersを1回ではなく2回呼び出し始めた場合、請求書が届く3週間後ではなく、すぐにそのことを知りたいでしょう。

エージェントに本番環境の認証情報を絶対に与えない。エージェントはスコープ付きのサービスアカウントを使用します。本番環境の認証情報は、エージェントが読み取れる.envファイルではなく、金庫に保管されます。エージェントが本番環境のエンドポイントを呼び出す必要がある場合、短命のトークンでリクエストに署名するプロキシを介して行われます。

読み取りと書き込みのAPIキーを分離する。ほとんどのエージェントタスクは読み取りが中心です。それらには読み取り専用キーを発行します。書き込みキーは、人間の承認ゲートを通過する必要があるタスクのために予約されています。この変更だけで、侵害されたエージェントの被害範囲を半分に縮小できます。

人間の承認が必要なエンドポイントにはHTTP 423 Lockedを使用する。エージェントが人間の確認を必要とするエンドポイントを呼び出そうとした場合、confirmation_urlフィールドとともに423を返します。エージェントのプランナーはロックされた状態を認識し、URLを人間に提示し、待機します。これは403よりもクリーンです。なぜなら403は「これはできません」を意味するのに対し、423は「まだできません」を意味するからです。

スキーマのずれが発生した場合、クローズドで失敗させる。エージェントのツール定義がOpenAPI仕様と一致しない場合、ビルドは失敗します。警告を出荷するのではなく、エラーを出荷してください。いくつかのビルド失敗が増えるコストは、1つの本番インシデントよりもはるかに低いです。

避けるべきよくある間違い：

モックURLをエージェントのプロンプトにハードコードする。モック、ステージング、本番環境で同じプロンプトが実行されるように環境変数を使用する。
「小さな」エンドポイントで冪等性をスキップする。すべての書き込みに必要です。メール送信も例外ではありません。
本番環境で完全なリクエストボディをログに記録する。PIIが可観測性スタックに漏洩する。ログに到達する前に、トークン、メール、識別子を匿名化する。
エージェントにデータベースへの直接アクセスを許可する。常にAPIを介してアクセスする。APIはあなたのテストが存在する場所です。
エージェントの信頼スコアを信用する。スコアは回答に関するモデルの確信度を反映するものであり、APIの安全性ではありません。99%確信しているエージェントでも、間違ったエンドポイントを呼び出す可能性があります。

エージェントが単一のAPIゲートウェイの背後にない内部サービスと通信する場合、マイクロサービステストパターンでは、シナリオテストをサービス全体に展開する方法が説明されています。

代替手段とツール

選択肢はあります。ここでは、一般的な4つのアプローチを公平に比較します。

アプローチ	セットアップ時間	強み	弱み	最適な対象
手作りのユニットテスト	低い	完全な制御、ベンダーロックインなし	高いメンテナンス性、実際のAPIと乖離しやすい	小規模プロジェクト、単独開発チーム
LangSmith / LangGraph 評価ハーネス	中程度	組み込みのトレース再生、モデルを意識したメトリクス	エージェント側に重く、API側に軽い	評価中心のAIチーム
Postman + Postbot	中程度	使い慣れたUI、豊富なテンプレートライブラリ	モックサーバーは有料アドオン、シナリオ構文が古い	すでにPostmanに投資しているチーム
Apidog シナリオ + モック	中程度	ネイティブOpenAPI、モック無料、CI用シナリオCLI	Postmanほどのブランド認知度はない	デザイン、モック、テストを1つのツールで完結させたいチーム

正直なまとめ：LangSmithを使っているなら、エージェント側でうまくいっていることを継続し、別途APIテスト層を追加してください。Postmanの価格設定やモックモデルに不満があるなら、Apidogは強力な代替品です。ゼロから始めるなら、OpenAPI、モック、シナリオを1つのプロジェクトで処理できるツールを選んでください。なぜなら、エージェント-APIテスト時間の80%はそこに費やされるからです。

これらのツールを組み合わせて使用するチームもあります。彼らはLangSmithをプロンプトレベルの評価に利用し、ApidogをAPI側のコントラクトテストやシナリオ再生に利用します。これは問題なく機能します。ツールは異なる層に役立つからです。

実際の使用例

エージェントが本番データベースの行を更新する。カスタマーサクセスチームは、サポートチケットからアカウントフィールドを更新するエージェントを構築しました。リリース前に、すべての書き込みエンドポイントに冪等性キーを必須とし、サンドボックスデータベースに対してApidogで200回のシナリオ再生を実行しました。再生によって、エージェントがsubscription_statusを列挙型にない文字列に設定しようとした2つのケースが検出されました。彼らはスキーマ検証を追加し、問題なく出荷しました。

エージェントが決済APIを呼び出す。自動返金エージェントを構築するフィンテックチームは、厳格な上限を設定しました。セッションあたり最大5回の返金、返金あたり最大50ドル、すべての呼び出しに冪等性が必須です。彼らはすべてのPRでStripeのOpenAPIに対してコントラクトテストスイートを実行しました。半年後、彼らは12,000件の返金を処理し、二重請求はゼロでした。

エージェントがGitHubの課題をトリアージする。プラットフォームチームは、Clawsweeperにインスパイアされた課題トリアージエージェントを構築しました。彼らはApidogでGitHub APIをモックし、エッジケース（削除された課題、不足しているラベル、形式が不正なユーザー入力）をカバーする50のシナリオテストをエージェントに実行し、リリース前に3つのクラッシュを発見しました。現在、そのエージェントは5,000件の未解決課題を持つ公開リポジトリのトリアージを処理しています。

結論

このガイドから一つだけ持ち帰るとすれば、これです。問題はエージェントではありません。問題はAPIにあります。テストしたかどうかによって、問題にも解決策にもなり得ます。

5つの要点：

ツールスキーマをコントラクトとして扱い、CIでコントラクトテストを実行する。
すべてのエージェント開発ループで破壊的なエンドポイントをモックする。
エージェントが呼び出すすべての書き込みに冪等性キーを必須とする。
予算上限に達した場合はクローズドで失敗する、エージェントごとの予算上限を設定する。
APIまたはツール定義に触れるすべてのPRでシナリオを再実行する。

今年話題になった事件が最後になることはないでしょう。エージェントを出荷するすべてのチームは、少なくとも一度はこれらの失敗モードのいずれかに遭遇するでしょう。素早く回復できるチームは、すでにガードレールを導入していたチームです。Apidogをダウンロードし、モックサーバーのステップから始めてください。それだけで今四半期の寝不足を回避できるでしょう。同じ問題に対するQAチームの視点については、QAエンジニアのためのAPIテストツールを参照してください。エージェントが安全に使用できるツール定義を作成するためのより広い文脈については、AGENTS.mdファイルの書き方を参照してください。

FAQ

トークンにお金をかけずにAIエージェントのAPI呼び出しをテストするにはどうすればいいですか？

開発中にエージェントをモックサーバーに対して実行してください。ApidogのモックURLは現実的なレスポンスを無料で返すため、テストループで実際のAPIクレジットを消費することはありません。温度を0に固定し、小さな固定プロンプトセットを使用してください。モックサーバーのコストはゼロなので、数千回のテストを無料で実行できます。完全なセットアップについては、QAエンジニアのテストチェックリストを参照してください。

エージェントのテストとAPIのテストの違いは何ですか？

エージェントテストは、モデルが正しいツールを選択し、引数を正しく埋めるかどうかをチェックします。APIテストは、エンドポイントが呼び出されたときに正しく動作するかどうかをチェックします。どちらも重要です。完璧なエージェントが壊れたAPIを呼び出しても、依然として壊れた結果を生成しますし、壊れたエージェントが完璧なAPIを呼び出しても、依然としてバグを出荷します。両方の層を別々にテストする必要があります。

すべてのエンドポイントに冪等性キーが必要ですか？

はい、すべての書き込みエンドポイントに必要です。読み取りは定義上冪等です。書き込みはそうではなく、エージェントは再試行します。冪等性ヘッダーをサポートするための5行のミドルウェアは、エージェントが500エラーを再試行し、重複行が発生しない最初の時点で元が取れます。

プロンプトインジェクションによる不正なAPI呼び出しを防ぐにはどうすればよいですか？

プロンプト層だけに頼ってはいけません。APIは、エージェントのリクエストではなく、元のユーザーコンテキストに基づいて認証を強制する必要があります。ユーザーコンテキストセッションが通常/admin/delete-all-usersにアクセスできない場合、そのユーザーに代わって動作するエージェントも、プロンプトが何と言っていようと、アクセスできるべきではありません。OWASPのLLMトップ10に詳しく説明されています。

独自のツール層を記述せずに、ApidogをClaudeまたはGPTと直接使用できますか？

テスト中は、エージェントのツール定義をApidogモックURLに向けます。ClaudeとGPTの両方が、ツール定義で任意のHTTPベースURLをサポートしているため、交換は1つの環境変数で済みます。ステージングまたは本番環境に対してテストする準備ができたら、変数を変更します。

エージェントの適切な予算上限はどのくらいですか？

最初は厳しく設定し、データに基づいて緩めます。セッションあたり50,000トークン、1分あたり30API呼び出し、タスクあたり5ドルから始めます。2週間メトリクスを監視します。正当に上限に達したものは上限を引き上げます。一度も達しなかった上限は引き下げます。毎月レビューします。目標は固定された数値ではなく、暴走ループを捕捉するのに十分厳しく、実際の作業を可能にするのに十分緩い数値です。

エージェントのツールとAPI間のスキーマのずれを検出するにはどうすればよいですか？

すべてのPRでCIでスキーマ差分を実行してください。エージェントのツール定義（JSONスキーマ）を、同じエンドポイントのOpenAPIリクエストボディスキーマと比較します。食い違いがある場合はビルドを失敗させます。上記のガードレールセクションにある30行のPythonスニペットがこれを行います。それをリポジトリにコピーし、GitHub Actionsに組み込んでください。