DeepSeek V4 Flash APIの使い方(実装コード付き)

実際に呼び出しているものは何か

deepseek-v4-flashはDeepSeekの料金表にある2つのモデルのうち小さい方で、総パラメータ284B/アクティブ13BのMixture-of-Experts型LLMであり、MITライセンスのオープンウェイトを持ち、以前DeepSeek V3.2で取り上げた世代の後継にあたる。

このエイリアスは固定されたスナップショットではなく、常に動き続ける標的だ。DeepSeekの変更履歴には「DeepSeek-V4-Flash-0731に更新されました。呼び出し方法は変更ありません」とあり、常に最新のビルドを使うことになり、古いバージョンを固定する公開された方法はない。

設定に必要なものはすべて1ページにまとまっており、コードを1行書く前に一度見ておく価値がある。ベースURLも料金も両方とも同じ表に載っているからだ。

このスクリーンショットの中の2点が、あなたのアーキテクチャの大部分を決める。料金表には両方のモデルで100万トークンのコンテキストと384Kの最大出力が記載されているので、FlashとProの価格差はコンテキストウィンドウのトレードオフではない。そしてthinkingモードは両モードに対応し、thinkingがデフォルトになっていると記載されており、これはコストの観点でAPI全体の中で最も高くつくデフォルト設定だ。

この後すぐに計算することになるので、同じ表を数値として載せておく。

Flashはキャッシュミス入力と出力のレートで見ると、Proのおよそ3分の1に収まっている。どちらも100万トークンあたりの単価だ。この話の気まずい部分を知りたいなら、DeepSeek自身のagentic系のスコアでは安い方のティアが今のところ高い方を上回っている。これについてはFlash vs V4 Proで別途掘り下げている。

他のモデルと比べてどう位置づけられるかについては、Flash vs Kimi K3とFlash vs GPT-5.6がある。Qwen 3.7 Flashとの名前の衝突は残念だが、私のせいではない。

始める前に

前提条件は4つ、そのうち変わっているのは1つだけだ。

1. アカウントとキー。 キーはplatform.deepseek.com/api_keysで作成する。直書きせず環境変数から読み込むこと。DeepSeek自身のサンプルもそうしている。
2. 素のOpenAI SDK。 pip3 install openaiまたはnpm install openai。DeepSeek専用のパッケージはどこにも存在せず、それこそが互換レイヤーの意味そのものだ。
3. 事前にアカウントへの入金。 DeepSeekは前払い制で、これが実際に痛い目を見る前提条件だ。402 - Insufficient Balanceはセットアップ時、つまり実際に気づけるタイミングでは来ない。認証は成功し、最初の呼び出しも成功し、そして残高がゼロになった瞬間に失敗が現れる。バッチループの場合、任意の行インデックスで支払いエラーが発生し、部分的にしか完了しないことを意味する。
4. 使いたいモデル文字列を把握しておくこと。 DeepSeekのドキュメントのコードサンプルはすべてdeepseek-v4-proをハードコードしている。それをコピーしてFlashの料金を期待すると、入力と出力の両方で3.11倍課金されることになる。

ホストは1つではなく3つあり、ドキュメントはそれぞれ別のページに分散している。

現行のドキュメントに/v1というバリエーションは存在しない。古いチュートリアルでこのサフィックスを見たことがあるとしても、今の設定表には単純に存在しない。

ステップ1:最初の呼び出し

モデル文字列をFlashに切り替え、thinkingはDeepSeekのデフォルトのままにしたPythonコードがこちらだ。デフォルト設定が実際に何をしてくるのかが分かるようにしてある。

# pip3 install openai
import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ.get('DEEPSEEK_API_KEY'),
    base_url="https://api.deepseek.com")

response = client.chat.completions.create(
    model="deepseek-v4-flash",
    messages=[
        {"role": "system", "content": "You are a helpful assistant"},
        {"role": "user", "content": "Hello"},
    ],
    stream=False,
)

print(response.choices[0].message.content)
print(response.usage)

通信フォーマットで見たい場合のために、同じ内容をcurlでも示す。

curl https://api.deepseek.com/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer ${DEEPSEEK_API_KEY}" \
  -d '{
        "model": "deepseek-v4-flash",
        "messages": [
          {"role": "system", "content": "You are a helpful assistant."},
          {"role": "user", "content": "Hello!"}
        ],
        "stream": false
      }'

最初の呼び出しでは、contentだけでなくresponse.usageも出力すること。これがこの後説明する内容を確認する唯一の方法だ。

ステップ2:thinkingをオフにするか、課金されていると自覚するか

thinking.typeはenabledかdisabledを受け付け、APIリファレンスではデフォルトがenabledとされている。reasoning_effortはlow、high、maxを受け付け、同じページには「デフォルトのeffortはhigh」とある。最初の呼び出しでこれらを設定する人はまずいない。つまりあなたのhello-worldはhighの推論effortで動き、chain of thoughtが出力レートで課金されていたということだ。

オフにするには引数を1つ渡すだけで、それはextra_bodyの中に入れる。OpenAI SDKにはネイティブのthinkingフィールドが存在しないためだ。

response = client.chat.completions.create(
    model="deepseek-v4-flash",
    messages=[{"role": "user", "content": "Summarise this ticket in one line: ..."}],
    extra_body={"thinking": {"type": "disabled"}},
)

オフにするのではなく下げる場合、Flashは兄弟モデルに対して本当のアドバンテージを持つ。公開されているeffortマッピングは、リクエストした値をモデルごとに変換する。

1行目は2回読んでほしい。lowはFlashでは本当にlowだが、Proでは黙ってhighに格上げされるため、現時点では安く済むPro実行というものはそもそも存在しない。Flashには3行目に独自の癖があり、xhighはhighに丸められてしまうため、highより上でmaxより下を要求しても結局highになるだけだ。DeepSeekは脚注で「deepseek-v4-proの実際のマッピングeffortは2026年8月上旬に更新予定」としており、それはまさに今なので、気になるならProの列を再確認してほしい。

thinkingをオンのままにしておくと、人をはめる副作用が2つある。1つ目は、thinkingモードガイドによると、thinkingモードはtemperature、top_p、presence_penalty、frequency_penaltyをサポートしておらず、DeepSeekは「これらのパラメータを設定してもエラーにはならないが、効果もない」と明言している。2つ目は、chain of thoughtはreasoning_contentという別フィールドで返ってくるため、.message.contentだけを出力するスクリプトでは回答だけが見え、お金を払ったトークンは一切見えない。

ここまで動く部分が多いと、請求額を推測で済ませるのは得策ではない。自分の数字を当てはめてみてほしい。

ステップ3:ストリーミングしながらトークン数を保持する

ストリーミングは引数1つで済む。ストリームから使用量データを取り出すのはもう1つの引数で、これを忘れて、なぜすべてのチャンクがusage: nullを返すのか悩む人がいる。

stream = client.chat.completions.create(
    model="deepseek-v4-flash",
    messages=[{"role": "user", "content": "Draft a refund reply."}],
    stream=True,
    stream_options={"include_usage": True},
    extra_body={"thinking": {"type": "disabled"}},
)

for chunk in stream:
    if chunk.choices and chunk.choices[0].delta.content:
        print(chunk.choices[0].delta.content, end="")
    if chunk.usage:
        print("\n", chunk.usage)

include_usageをオンにすると、data: [DONE]の直前に1つ余分なチャンクが届き、空のchoices配列とともにリクエスト全体のトークン数を運んでくる。APIリファレンスには、streamがtrueのときにだけ設定するようにと書かれている。

SDKを使わず自前でSSEパーサーを書いている場合、もう1つ指摘しておく価値のある点がある。リクエストがキャパシティ待ちの間、接続にはパディングが挿入される。レート制限ページによれば、非ストリーミングリクエストは「継続的に空行を返し」、ストリーミングリクエストは: keep-aliveのSSEコメントを返す。空行をボディの終わりとして扱ったり、:で始まる行をスキップしなかったりする自作のリーダーは、まさにここで壊れる。さらに、10分経っても推論が始まらない場合、サーバーは単に接続を閉じてしまう。

ステップ4:マルチターン、APIは何も覚えていないから

この点についてDeepSeekはかなり率直だ。マルチラウンドガイドは/chat/completionsを「ステートレス」なAPIと呼び、「サーバーはユーザーのリクエストのコンテキストを記録しないことを意味する。したがってユーザーはこれまでの会話履歴をすべて連結し、リクエストのたびにchat APIへ渡す必要がある」としている。

つまり会話履歴を管理するのはあなた自身だ。

messages = [{"role": "user", "content": "What's the highest mountain in the world?"}]
response = client.chat.completions.create(model="deepseek-v4-flash", messages=messages)

messages.append(response.choices[0].message)          # round 1 answer
messages.append({"role": "user", "content": "What is the second?"})
response = client.chat.completions.create(model="deepseek-v4-flash", messages=messages)

毎ターン全履歴を送り直すというのは破滅的に聞こえるし、実際そうなるはずなのだが、ここでまさに料金体系が面白くなる。ディスク上のコンテキストキャッシュは全ユーザーにデフォルトで有効になっており、コード変更は不要で、キャッシュヒット入力レートはミスの$0.14に対して$0.0028だ。同じトークン数で見ると、50倍の開きになる。

キャッシュは自動なので、調整するつまみは存在せず、あなたのプロンプト構造そのものがつまみになる。どちらのレートで課金されるかは、いくつかの仕組みで決まる。

• リクエストが永続化されたキャッシュプレフィックスユニットに完全に一致した場合のみ、ヒットレートで課金される。ユニットの部分的な一致はカウントされず、DeepSeekはこれをSliding Window Attentionの仕組みによるものとしている。
• キャッシュガイドによれば、ユニットはリクエストの境界、リクエスト間の共通プレフィックス検出時、そして長い入力に対する一定トークン間隔で永続化される。
• 呼び出しごとの内訳は確認できる。usageにはprompt_cache_hit_tokensとprompt_cache_miss_tokensが含まれている。
• キャッシュはベストエフォートであり、ヒット率は保証されず、使われないエントリは「通常数時間から数日以内」にクリアされる。

実践的には、システムプロンプトはバイト単位で同一に保ち、履歴は書き換えずに追記し、リクエストごとに変わるものは末尾に置く。タイムスタンプやシャッフルされたナレッジベースのスニペットをプロンプトの先頭に注入するのは、チームがうっかり50倍払ってしまう典型的な原因であり、キャッシュの挙動は請求書の脚注ではなく、れっきとしたプロンプトエンジニアリングの課題になる。

これが最も痛いのはRAGで、取得されるチャンクが設計上、呼び出しのたびに変わるからだ。それを構築しているなら、次に読むべきはサポートRAGパイプラインの解説と、RAG vs 生のLLMの比較記事の2本だと思う。

ステップ5:ツール呼び出しと、あなたを混乱させる400

toolsの形式は標準的なOpenAIのもので、関数は128個までという上限があり、関数名は64文字までに制限されている。

tools = [
    {
        "type": "function",
        "function": {
            "name": "get_order_status",
            "description": "Look up an order's shipping status by order ID.",
            "parameters": {
                "type": "object",
                "properties": {
                    "order_id": {"type": "string", "description": "The order ID, e.g. A-10293"}
                },
                "required": ["order_id"]
            },
        }
    },
]

tool_callsはassistantメッセージ上に配列として返り、argumentsはdictではなくJSON文字列として届く。DeepSeekのエージェントループのサンプルでは、モデルが完了したときのループ終了シグナルはtool_callsがNoneになることだ。ツール呼び出しガイドも、それでも間違える人がいる当たり前の点をわざわざ明記している。「モデル自体が具体的な関数を実行するわけではない」と。

ここからはどこかに刻んでおく価値がある部分だ。thinkingモードの通常のルールでは、中間のreasoning_contentは「コンテキストの連結に参加する必要はない」とされ、渡したとしても無視される。ところがtoolsを追加すると、これが逆転する。

Please note that for requests carrying the tools parameter, the reasoning_content must be fully passed back to the API in all subsequent requests. If your code does not correctly pass back reasoning_content, the API will return a 400 error.

Thinking Mode, DeepSeek docs

これが罠になるのは、ほとんどの人がたどり着くツール呼び出しガイドとは別のページに書かれているからであり、また自然に書いてしまうシリアライザーがrole、content、tool_callsだけを保持し、認識しないフィールドを捨ててしまうからだ。代わりに、メッセージオブジェクト全体をそのまま追記すること。

messages.append(response.choices[0].message)   # keeps reasoning_content intact
for tool in response.choices[0].message.tool_calls:
    result = TOOL_MAP[tool.function.name](**json.loads(tool.function.arguments))
    messages.append({"role": "tool", "tool_call_id": tool.id, "content": result})

もう一つ。DeepSeekは「parallel tool calls」という表現を一度も使っておらず、Chat Completions側にparallel_tool_callsというパラメータも存在しない。ただし公式のループは[0]を取るのではなく配列を反復処理している。だからループを書くこと、保証を前提にしないこと。これはAIエージェントと呼べるものすべての裏側にある仕組みなので、エージェント的な振る舞いを上に重ねる前にきちんと押さえておく価値がある。

スキーマの強制が必要なら、strictモードは存在するが、ベータホスト側にある。要件は3つ。base_url="https://api.deepseek.com/beta"、各function内に"strict": true、そしてすべてのオブジェクトにadditionalProperties: falseと、すべてのプロパティをrequiredに指定すること。minLength、maxLength、minItems、maxItemsはサポートされていない。DeepSeek自身のサンプルはJSON Schemaの$defsではなく単数形の"$def"を定義コンテナとして使っている点は知っておく価値があるので、そのままの綴りをコピーすること。

ステップ6:JSON出力

response_format={'type': 'json_object'}を使う。ここにはjson_schemaのバリエーションは存在しない。DeepSeekの4点の注意事項は短いが、どの項目も重要だ。パラメータを設定すること、systemまたはuserプロンプトに「json」という単語を含めかつ欲しい形の例を示すこと、「JSON文字列が途中で切り詰められるのを防ぐ」ためにmax_tokensを適切に設定すること、そして「APIが時折空のコンテンツを返すことがある」と知っておくこと。

最後の1点は既知の未解決バグで、DeepSeek自身のページに太字で書かれており、彼らが提示する緩和策はプロンプトを変えることだけだ。だから防御的にパースすること。

response = client.chat.completions.create(
    model="deepseek-v4-flash",
    messages=[
        {"role": "system", "content": 'Extract intent and urgency as json. Example: {"intent": "refund", "urgency": "high"}'},
        {"role": "user", "content": ticket_body},
    ],
    response_format={'type': 'json_object'},
    max_tokens=400,
    extra_body={"thinking": {"type": "disabled"}},
)

raw = response.choices[0].message.content
parsed = json.loads(raw) if raw and raw.strip() else None

DeepSeek自身のJSONサンプルは、自らの要件3で求めているにもかかわらずmax_tokensを一切設定していないことに注意してほしい。設定すること。

Responses APIと、それができないこと

現時点でResponses APIがサポートするモデルはFlashだけだ。DeepSeekの説明には「現在はdeepseek-v4-flashモデルのみをサポート」とあり、Proのサポートは2026年8月上旬に予定されている。存在理由はほぼ1つで、DeepSeekはそれを率直に述べている。「Codexの需要に応えるため」だ。

response = client.responses.create(
    model="deepseek-v4-flash",
    instructions="You are a helpful assistant.",
    input="Hi, how are you?",
)
print(response.output_text)

ここで期待が崩れる。他の場所でResponses APIを知っているなら、それはステートフルなものとして知っているはずだ。DeepSeekの実装はステートレスだ。previous_response_idとconversationは「サポート対象外(ステートレスAPI)」、storeは「サポート対象外。レスポンスは常にstore: falseを持つ」とされ、background、metadata、include、prompt、stream_optionsもすべてサポートされていない。

そしてこれらはエラーにならない。互換性テーブルにあるDeepSeek自身の一文をそのまま引用する。「サポートされていないパラメータは黙って無視され、エラーは発生しないため、既存のResponses APIクライアントは変更なしで接続できる」。store: trueを渡せば、200が返ってきて、何も保存されない。

Chat Completionsに対して実際に追加されるものを知っておく価値はある。chain of thought専用のresponse.reasoning_text.deltaチャンネルを含む型付きのセマンティックSSEイベント、サーバーサイドのweb_searchビルトインツール、そしてtop_logprobsだ。ただしビルトインツールの棚はちょうど2つだけで、web_searchとapply_patch。file_search、code_interpreter、computer_use、MCPはすべて無視される項目として挙げられている。

移行時の落とし穴が2つある。data: [DONE]という終端シグナルが存在しないので、response.completed / response.incomplete / response.failedで終了判定すること。そしてinput_imageパートはエラーにならず、「プレースホルダーテキストに置き換えられる」。これはFlashがマルチモーダルではなくテキスト専用であることと整合している。

実際に遭遇するエラーへの対処

文書化されているコードは7つで、それ以外はない。Retry-Afterヘッダーもなく、公開されているバックオフのスケジュールもどこにもないので、判断するのはあなたのラッパー側だ。

400と422の区別は本物で、実際に役立つ。400はボディの形式が不正で、422は形式は正しいがパラメータの値が不正だ。デバッグの道筋はまったく異なり、どちらなのかはエラーメッセージが教えてくれる。

429については一言添える価値がある。DeepSeek自身が文書化している対処法は珍しく率直だ。「リクエストのペースを適切に調整してください。また、OpenAIのような代替のLLMサービスプロバイダーのAPIに一時的に切り替えることも推奨します」。ベンダーが自社のエラードキュメントの中で競合他社を推奨するのは、ピーク時のキャパシティについての本物のシグナルであり、冗談として片付けるのではなく、フォールバックパスを設計しておく価値がある。

制限そのものについて言うと、DeepSeekはRPMもTPMの数値も一切公開していない。唯一の上限は同時実行数で、レート制限ページではキー単位ではなくアカウント単位でカウントされるため、キーを追加で発行しても何も得られない。「リクエストは送信された時点からモデルの応答が完了するまで、1つの同時接続としてカウントされる」ため、長い推論呼び出しはその間ずっと1枠を占有する。Flashは2,500枠、Proは500枠で、拡張は無料だが手動のFeishuフォームを通す必要がある。

マルチテナントのトラフィックを扱っているなら、user_id(OpenAIのuserではないことに注意)をextra_body={"user_id": "..."}として渡すこと。これはコンテンツ安全性レビュー、ユーザーごとのスケジューリング分離、そしてプライバシーのためのKVキャッシュ分離を担う。フォーマットは[a-zA-Z0-9\-_]、最大512文字で、DeepSeekはここにユーザーのプライバシー情報を入れないよう警告している。これはまた、テナントをまたいだプロンプトインジェクションの被害範囲に対する唯一の対抗手段でもあり、実際のユーザーが入力し始めると聞こえる以上に重要になる。

黙って失敗する5つのこと

このAPIのすべての落とし穴はHTTP 200を返す。それがここでの通底テーマであり、差分をチェックできる1つのリストにまとめる価値がある。

1. frequency_penaltyとpresence_penaltyは非推奨。 どちらもAPIリファレンスに同じ一文がある。「このパラメータはサポートされなくなりました。APIに渡しても効果はありません」。OpenAI用の呼び出しを移植するときは取り除くこと。
2. temperatureとtop_pはthinkingモードでは無効で、そしてthinkingモードがデフォルトだ。temperature=0.2でプロンプトを調整して移植したなら、実際にはthinkingモードが決める挙動で動いていることになる。
3. サポート対象外のResponses APIフィールドは黙って無視される。 store、previous_response_id、conversation、background。毎回200が返る。
4. Anthropicエンドポイントで認識されないモデル名はFlashになる。 Anthropic APIガイドによれば、サポート対象外のモデル名は「自動的にdeepseek-v4-flashモデルにマッピングされる」。claude-opus*はProに、claude-sonnet*とclaude-haiku*はFlashにマッピングされる。DeepSeekはこれをClaudeクライアントを自社APIに向けるための機能として売り込んでおり、実際そうなのだが、タイプミス1つで評価がどのモデルに対して実行されたかが黙って変わってしまうまでの話だ。
5. cache_controlはAnthropicエンドポイントでは無視される。 tools、テキストブロック、tool_use、tool_resultなど、どこに現れても同じだ。代わりにDeepSeek自身のディスクキャッシュが動くため、宣言すべきものは何もないが、Anthropicから移植したコードは明示的なキャッシュのブレークポイントを、何の警告もなく失うことになる。

6つ目を付け加えるなら、これは正直DeepSeekのせいとは言えない。finish_reasonにはOpenAIにはない値、insufficient_system_resourceがあり、推論システムのキャパシティによってリクエストが中断されたときに返される。stop/length/tool_callsしか知らないハンドラーは、途中で切れた回答を完全なものとして扱ってしまう。

これは顧客チケットに回答すべきか?

これは実際によく聞かれる質問で、正直な答えとしてはAPIは全体の中で簡単な部分でしかない。モデルに返信させるところまでは週末で終わる。実際のキューの近くに置いても大丈夫だと言えるAIサポートエージェントを作るのは、そうはいかない。

自社製品の中で実際に見た失敗の話をしよう。これはどんなベンチマークよりも示唆に富む。eeselが本番環境で観測した最悪の失敗モードは、モデルが拒否することでも、タイムアウトすることでもなかった。それはエージェントが成功をでっち上げることだった。実際にはAPIを一度も叩いていないのに「Zendeskの検索を実行中」と10ターンほど語り続け、存在しないファイルを保存したと報告し、指標をでっち上げていた。私たちがそれに気づけたのは、探していたからにすぎない。何をしたかについて嘘をつくことほどチームメイトを台無しにするものはない。そしてこの失敗の形にも注目してほしい。これもまた200に見えていたということを。

これはこの記事全体と同じ教訓だ。生のモデル呼び出しが成功したところで、その回答が実際に正しかったかどうかについてはほとんど何も分からない。独立したテストによれば、Flashのハルシネーション率は84%で、前世代から12ポイント改善しているものの、「顧客に向けて放置していい」水準にはまるで届いていない。スコアも、意図的に設定したとは限らない設定次第で、非推論の29からmax effortの50まで振れる。

つまり、実際の仕事をしているのはモデルの上に載っているレイヤーだということだ。検証済みのソースへのグラウンディング、推測ではなく辞退できる信頼度スコア、きれいなエスカレーションパス、そして重要な事柄をレビューする人間。

これらすべての詳しいバージョンが読みたければ、ハルシネーションの防止と敵対的テストを別途まとめている。

次にデータの問題がある。ここは煽るのではなく、正確に書きたい。DeepSeekのOpen Platform利用規約は有料APIを規定しており、あなたの入力のトレーニング利用については沈黙している。これは許可しているのとも、安全であるのとも違う。コンシューマー向けの利用規約には§4.3にオプトアウトのトグル付きの明示的な条項があるが、API専用の文書はその条項の手前で止まっている。公開されたDPAもゼロ保持オプションもどちらも存在せず、データ自体は中国の法律の下に置かれる。

Slackのポリシー明確化を経験したことがあるなら、これがセキュリティ担当者にどう映るか分かるはずだ。顧客データを近づける前にSOC 2とGDPRのガイドと合わせて読み、そもそもどんなデータを送ることになるのかを考える価値がある。

それがどれも受け入れられないなら、MITライセンスの重みが現実的な逃げ道になる。ファインチューニングも含めてセルフホストでき、ライセンスは商用利用を許可している。

すべきかどうかは自作か購入かという問いであり、両方を出荷してきた私の正直な見解では、サポートチームの制約になるのはほとんどの場合モデルへのアクセスではない。実際にうまくいくかどうかを決めるのは、インテグレーションの深さとエスカレーションの質だ。

eeselを試す

Flashをヘルプデスクに組み込もうとしてここにたどり着いたなら、APIはそのプロジェクトの5%ほどにすぎない。残りの95%はモデルが間違ったときに何が起こるかであり、そこは二度作り直してほしくない部分だ。

eeselはその95%を製品化したものだ。すべての返信をあなたの検証済みナレッジ、つまりヘルプセンターの記事、過去のチケット、マクロ、連携ドキュメントに根拠づけたうえで、本番稼働前に最も重要なことを行う。あなた自身の過去のチケットに対するシミュレーションだ。これにより、ベンチマークの数字ではなく、実際のキューでの実際の精度が分かる。デプロイするのは、どこかのリーダーボードが言うからではなく、あなた自身の基準をクリアしたときだ。料金は対応チケット1件あたり40セント、席料なし、人間が対応したチケットに課金されることは一切ない。つまり月間1,000件のチケットのうち200件をAIに回すなら、200件分だけ支払う。50ドル分の無料利用枠があり、クレジットカードも不要で、すべてのインテグレーションが無料プランで使える。

この「ツールごとの承認・却下の利用状況」パネルは、先ほどの成功のでっち上げ問題に対する直接的な答えだ。エージェントが取るすべてのツールアクションは数えられ、レビューできるので、ヘルプデスクを検索したというエージェントの主張は、信じるしかない文章ではなく、確認できる1行になる。

言い換えれば、生のAPIはインフラにすぎない。サポートマネージャーが本当に必要としているのは、従業員だ。

トークンの計算を成果あたりの計算と照らし合わせたいなら、まずAIカスタマーサービスのコストから始めて、次に実際に予算に現れる単位である解決あたりのコストを見てほしい。

CSATを台無しにせずにコストを削減するサポート自動化のあり方もある。それは100万トークンあたりのコストからではなく、チケットあたりのコストから始まる。