DeepSeek-V4.1-Flashで長文脈マルチモーダルAgent構築

2つ目の重要なパラメータは同時実行制限 2500です。これはかなり高い同時実行上限ですが、長コンテキスト Agent にとって真のボトルネックは多くの場合、同時実行数ではなく単一リクエストの継続時間です。1M コンテキストの prefill + 384K 出力の decode は、接続を数分、あるいはそれ以上占有する可能性があります。2500 同時実行は「同時に飛行中のリクエスト数」であり、QPS ではありません。

• コネクションプールの計画: QPS ではなく P99 リクエスト時間に基づいて同時実行の占有量を見積もる。長時間タスクは同時実行枠を長時間占有します。
• 段階的リトライ: レート制限（429）には指数バックオフ + ジッターを採用。タイムアウトしたタスクには、全体をリトライするのではなく、ストリーミングまたは非同期の続き書きを採用します。
• 冪等性と断点続き書き: 長い出力ではストリーミングを有効にし、生成済み部分をディスクに保存して、タイムアウト後に最初からやり直して出力 token を無駄にするのを避けます。

import os
import time
import httpx

API_KEY = os.environ.get("DEEPSEEK_API_KEY", "your-deepseek-api-key")
BASE_URL = "https://api.deepseek.com"
MODEL = "deepseek-flash"

client = httpx.Client(
    base_url=BASE_URL,
    headers={"Authorization": f"Bearer {API_KEY}"},
    timeout=httpx.Timeout(connect=10.0, read=600.0, write=60.0, pool=10.0),
)

def chat_with_retry(messages, max_retries=5, max_tokens=384000):
    """指数バックオフ付きの長コンテキスト呼び出し。2500 同時実行下のレート制限シナリオに対応。"""
    last_err = None
    for attempt in range(max_retries):
        try:
            resp = client.post(
                "/chat/completions",
                json={
                    "model": MODEL,
                    "messages": messages,
                    "max_tokens": max_tokens,
                    "stream": False,
                },
            )
            if resp.status_code == 429:
                raise RuntimeError("rate_limited")
            resp.raise_for_status()
            return resp.json()
        except Exception as e:  # noqa: BLE001
            last_err = e
            backoff = min(2 ** attempt, 30) + (time.time() % 1)
            time.sleep(backoff)
    raise RuntimeError(f"chat failed after {max_retries} retries: {last_err}")

if __name__ == "__main__":
    out = chat_with_retry([
        {"role": "system", "content": "You are a long-context multimodal agent."},
        {"role": "user", "content": "Summarize the attached 200-page spec into an action plan."},
    ])
    print(out["choices"][0]["message"]["content"][:500])

また、課金の時間帯にも注意してください。ピークは月曜から金曜の 9:00-12:00、14:00-18:00 で、アイドルはピークの半額です。長コンテキストのバッチタスクはできるだけアイドル時間帯にスケジュールすべきで、出力コストはピーク時の 8 元からアイドル時の 4 元（100万 tokens あたり）まで下げられます。さらに、北京時間 2026-09-14 12:00 以降、deepseek-v4-pro のリクエストはすべて V4.1-Flash にルーティングされ、Flash の価格で課金されます。これは実質的に既存ユーザー向けの暗黙のアップグレードです。既存の v4-pro 呼び出しは自動的に 1M コンテキストと新機能を獲得しますが、課金基準もそれに伴って変わるため、請求監視で個別に分けて集計する必要があります。

思考モードの3段階 low/high/max と非思考モード：長コンテキスト Agent の推論予算配分

V4.1-Flash はデフォルトで思考モードを有効にし、low / high / max の3段階の強度をサポートしつつ、非思考モードも保持しています。長コンテキスト Agent にとって、思考強度は本質的に出力 token 予算と推論深度のノブです。強度が高いほど、モデルが生成する思考チェーンは長くなり、出力 token 消費は大きくなり、複雑なタスクでの精度向上もより顕著になります。

選択の根拠は一つの原則にまとめられます。タスクの分解不可能な推論ステップが多いほど、段階を高くする。公式ベンチマークも上限能力を裏付けています——GPQA Diamond 90.9、Codeforces レーティング 3471、MathArena Apex 65.6。これらの高スコアは通常、高い思考強度でなければ再現できません。ただし、384K 出力上限は高強度下で実際に消費されることに注意してください。タスク自体が超長いコードベースや長いレポートの出力を必要とする場合、max は「まずしっかり考える」段階に残し、最終成果物は非思考または low で生成し、思考チェーンが正式な出力枠を圧迫しないようにすべきです。

もう一つの落とし穴は、思考モードの中間推論内容も出力課金に含まれることです。したがって、長コンテキストのバッチタスクでは、同一入力のキャッシュ再利用を必ず行い、思考チェーンは本当に変化した増分部分にのみ展開させ、毎回コンテキスト全体を深く考え直さないようにしてください。

ネイティブマルチモーダル視覚理解の統合：画像リンク、base64、Files API の3つのエンジニアリングパス

V4.1-Flash はネイティブマルチモーダル視覚理解能力を備え、画像入力方式を3つサポートしています。画像リンク、base64、Files API です。この3つは単純に等価ではなく、異なるエンジニアリング上のトレードオフに対応します。

• 画像リンク: URL を渡し、サーバー側が取得します。画像がすでに公開 CDN でアクセス可能なシーンに適しており、リクエストボディが小さく転送が高速です。制約は、リンクが安定してアクセス可能でなければならず、失効リスクがあることです。
• base64 インライン: 画像をリクエストボディにエンコードします。小さい画像、イントラネット画像、一度きりの画像に適しており、追加ストレージが不要です。代償はリクエストボディの膨張で、大きい画像は帯域とメモリ使用量を著しく増やします。
• Files API: 先にアップロードしてファイル参照を取得し、複数ターンのリクエストで再利用します。長コンテキスト Agent に適しており、同じ画像が繰り返し参照される場合でもアップロードは一度だけで、自然にキャッシュ再利用と組み合わせられます。

長コンテキストのマルチモーダル Agent では、推奨戦略はFiles API を主、base64 を補助、リンクを特例とすることです。セッションに入る画像はまず Files API にアップロードして参照を取得し、以降のすべてのターンで同じ ID を参照すれば、入力側でキャッシュにヒットできます。一時的なサムネイルや一度きりのスクリーンショットは base64 を使用し、すでに CDN でホストされている公開素材はリンクを直接使用します。これにより、リクエストボディのサイズを制御しつつ、キャッシュヒット率を最大化できます。

import os
import base64
impo

rt httpx

API_KEY = os.environ.get("DEEPSEEK_API_KEY", "your-deepseek-api-key")
BASE_URL = "https://api.deepseek.com"
MODEL = "deepseek-flash"

client = httpx.Client(
    base_url=BASE_URL,
    headers={"Authorization": f"Bearer {API_KEY}"},
    timeout=httpx.Timeout(read=600.0),
)

def to_base64(path: str) -> str:
    with open(path, "rb") as f:
        return base64.b64encode(f.read()).decode("utf-8")

def build_multimodal_messages(image_url=None, image_b64=None, file_id=None):
    """3 つの視覚入力パスを統一的にマルチモーダルメッセージへ組み立てる。"""
    parts = [{"type": "text", "text": "Describe the architecture diagram in detail."}]
    if image_url:
        parts.append({"type": "image_url", "image_url": {"url": image_url}})
    if image_b64:
        parts.append({
            "type": "image_url",
            "image_url": {"url": f"data:image/png;base64,{image_b64}"},
        })
    if file_id:
        parts.append({"type": "file", "file_id": file_id})
    return [{"role": "user", "content": parts}]

if __name__ == "__main__":
    msgs = build_multimodal_messages(image_url="https://example.com/diagram.png")
    resp = client.post(
        "/chat/completions",
        json={"model": MODEL, "messages": msgs, "max_tokens": 4096},
    )
    resp.raise_for_status()
    print(resp.json()["choices"][0]["message"]["content"][:300])

re>
エンジニアリング上の落とし穴：入力方式によってキャッシュヒットへの親和性は異なります。base64 画像は内容に微妙な差異がある場合（たとえば再エンコードによってバイト列が変わる場合）、キャッシュミスを引き起こすため、同じ画像は固定のエンコード成果物を保持すべきです。Files API の参照 ID は安定しており、長いセッションでの再利用に最も適しています。さらに、マルチモーダル入力は prefill 計算量を著しく押し上げるため、セッション設計段階で 1 ターンあたりの画像数を制限し、初回 token 遅延が制御不能になるのを避けるべきです。

JSON Output、Tool Calls、Responses API：長コンテキスト・マルチモーダル Agent の構造化出力チェーン
V4.1-Flash は JSON Output、Tool Calls、Responses API をサポートしており、この三者を組み合わせて初めて完全な Agent 出力チェーンになります。JSON Output はモデル出力がプログラムで解析可能であることを保証し、Tool Calls はモデルが外部ツールを宣言して呼び出せるようにし、Responses API は Agent オーケストレーションにより近いリクエスト/レスポンス抽象を提供します。
推奨される階層設計は、Responses API でセッションと状態を担い、Tool Calls でアクションを駆動し、JSON Output で最終的な構造化結果を制約するというものです。具体的には、ツール呼び出しのパラメータはモデルによって構造化形式で与えられ（その基盤では JSON Output が解析可能性を保証します）、ツール実行結果は新しいコンテキストとして再注入され、その後 Responses API がセッション全体の連続性とキャッシュヒットを維持します。
import os
import json
import httpx

API_KEY = os.environ.get("DEEPSEEK_API_KEY", "your-deepseek-api-key")
BASE_URL = "https://api.deepseek.com"
MODEL = "deepseek-flash"

client = httpx.Client(
    base_url=BASE_URL,
    headers={"Authorization": f"Bearer {API_KEY}"},
    timeout=httpx.Timeout(read=600.0),
)

tools = [{
    "type": "function",
    "function": {
        "name": "search_repo",
        "description": "Search a code repository by natural language query.",
        "parameters": {
            "type": "object",
            "properties": {
                "query": {"type": "string"},
                "top_k": {"type": "integer", "default": 5},
            },
            "required": ["query"],
        },
    },
}]

def agent_turn(messages):
    resp = client.post(
        "/chat/completions",
        json={
            "model": MODEL,
            "messages": messages,
            "tools": tools,
            "tool_choice": "auto",
            "response_format": {"type": "json_object"},
            "max_tokens": 8192,
        },
    )
    resp.raise_for_status()
    msg = resp.json()["choices"][0]["message"]
    calls = msg.get("tool_calls") or []
    return msg, calls

if __name__ == "__main__":
    msgs = [{"role": "user", "content": "Find auth-related bugs and summarize."}]
    msg, calls = agent_turn(msgs)
    if calls:
        for c in calls:
            args = json.loads(c["function"]["arguments"])
            print("tool:", c["function"]["name"], "args:", args)
    else:
        print("final:", msg.get("content"))

エンジニアリング上の要点：JSON Output と思考モードは併存できますが、思考チェーン自体を構造化出力として解析してはならず、最終的な content のみを解析する必要があります。Tool Calls のパラメータ検証はサーバー側で二次検証を行うべきであり、モデル出力を盲信してはいけません。Responses API はリクエストをまたいで状態を維持する必要があるシナリオに適しており、KV Cache の永続化とうまく連携できます。一方、単純な一問一答には Chat Completions のほうが軽量です。組み合わせて使う際は、必ず各ツールに明確な description と JSON Schema を書いてください。そうでなければ、長コンテキスト下でモデルは誤ったツールを選びやすくなります。

Anthropic API、対話プレフィックス継続生成、FIM：マルチプロトコル互換下での Agent コード生成実践
V4.1-Flash は同時に Anthropic API 互換、対話プレフィックス継続生成、FIM（非思考モードのみ）を提供します。この三者はコード系 Agent においてそれぞれ明確な用途があります。

  
Anthropic API 互換：既存の Anthropic プロトコルスタックに基づく Agent フレームワークをほぼゼロ改修で切り替えられ、既存のコード Agent の移行に適しています。
  
対話プレフィックス継続生成：対話履歴の最後のプレフィックス区間を与え、モデルに続きを書かせます。「モデルをある確定した位置から継続させるよう制約する」シナリオに適しており、たとえば指定した関数シグネチャから補完を開始させる場合などです。
  
FIM（Fill-In-the-Middle）：非思考モードのみをサポートし、プレフィックスとサフィックスを与えてモデルに中間を補完させます。これはコード補完、局所修正、単体テスト生成の利器ですが、思考モードとは併用できません。

実践における組み合わせ原則は非常に明確です。深い推論が必要なコードタスクは思考モード + Tool Calls、正確な挿入や補完が必要なものは FIM または対話プレフィックス継続生成を使います。FIM を長コンテキストのコードリポジトリの局所修正に使うことで、モデルにコード全体を書き直させるのを避け、出力 token を大幅に節約できます。対話プレフィックス継続生成は、形式の厳密な一貫性が求められるバッチ生成に適しています。まず規範に合ったヘッダーを与え、モデルにそれに沿って書き続けさせます。
互換性の落とし穴：Anthropic API と OpenAI スタイル API は、ツール呼び出し、システムプロンプト、停止シーケンスの意味論において完全には一致していません。プロトコルをまたいで移行する際は項目ごとに確認する必要があり、特に system フィールドと stop シーケンスの扱いに注意してください。FIM は非思考モードしか使えないため、強い推論が必要なリファクタリングタスクで無理に FIM を使わないでください。そうしないと品質が明らかに低下します。最後に、プレフィックス継続生成ではプレフィックス長を制御する必要があります。長すぎるプレフィックスはコンテキスト予算を占有するため、キャッシュ優先で注入するべきです。
本節でアーキテクチャ、VRAM、命名、プロトコル層の分解は完了しました。CED の非対称性は入力アクティベーションを 8B に圧縮し、出力は 16B に残します。KV Cache の HBM 1/4、SSD 1/8、および初代比 437 倍の縮小により、1M コンテキストと 384K 出力がデプロイ可能な範囲に入ります。deepseek-flash の命名と 2500 同時実行が呼び出し計画を決定し、思考の 3 段階とマルチモーダルの 3 経路、構造化出力とマルチプロトコルが Agent の行動境界を決定します。次の節では、これらの部品を完全なエンドツーエンドの長コンテキスト・マルチモーダル Agent に組み立て、コストモデル、キャッシュヒット戦略、本番級のレート制限とリトライの実践的詳細に深く入ります。
前節では、すでに DeepSeek-V4.1-Flash のアーキテクチャ基盤（552B MoE + CED 非対称アクティベーション）、1M 入力 / 384K 出力の能力境界、そしてマルチモーダルと思考モードの接続方法を組み上げました。この部分では、いよいよ本当の「答案」の段階に入ります。ベンチマークの数字が何を意味するのか、Agent シナリオに耐えられるのか、コストはどう使うのか、移行はどう進めるのか、コードにはどんな落とし穴があるのかを見ていきます。
GPQA Diamond 90.9 と Codeforces 3471：V4.1-Flash がベンチマークで V4 Pro を全面的に上回ることの解釈
まず公式発表のハードな数字を見てみましょう。V4.1-Flash は GPQA Diamond で 90.9 を獲得しています。これは分野の専門家が出題し、物理/化学/生物の大学院生レベルを目標とした高難度推論セットであり、記憶型の題庫ではなく、到達できることは

 90 は、モデルが多段階の科学的推論においてほぼ安定して正解できることを意味する。さらに Codeforces レーティング 3471 はより攻撃的だ——これは「コード補完」のスコアではなく、競技レベルのアルゴリズム問題における実戦的な Elo 水準であり、モデルが問題文の理解、アルゴリズム設計、計算量制御、境界処理を同時にこなす必要がある。これに MathArena Apex 65.6 を重ねると、これら三つの指標が示すのは一つのことだ。すなわち、新アーキテクチャファミリーの最小サイズのメンバーである V4.1-Flash は、推論とコードの中核能力において、すでに前世代のフラッグシップ V4 Pro を全面的に上回っている。

この「小型モデルがフラッグシップを逆転する」という結論が重要なのは、それがエンジニアリングにおけるモデル選定の論理を根本から書き換えるからです。これまでの私たちのデフォルトの前提は、能力の高いモデルは必ず高価で、必ず遅く、必ずコンテキストが短い、というものでした。しかし V4.1-Flash が提示する組み合わせは、1M tokens のコンテキスト + 384K の最大出力 + V4 Pro を超えるベンチマーク + より低い KV Cache オーバーヘッドです。Agent 開発者にとって、これは「最強のモデルは計画に残し、大量のコンテキストは安価なモデルに任せる」という階層型アーキテクチャを、「1つのモデルで最後までやる」に直接簡略化できることを意味します。
冷静さを保つべきなのは、ベンチマークの境界です。GPQA はオープンドメインの真実性評価ではなく、Codeforces のレーティングは実際のランダムなコンテスト問題ではなく公式ベンチマークに由来し、MathArena Apex も特定の問題タイプ分布です。本番システムでは、依然として独自の評価セットを保持すべきであり、特に長コンテキスト下での推論品質の減衰曲線が重要です。1M コンテキストに収められるからといって、900K の位置での検索と推論が依然として信頼できるとは限りません。
Terminal-Bench 2.1 スコア 90.6 と CyberGym 88.1：Agent 系タスク評価のパフォーマンスを分解する
上記の3つが「頭脳スコア」だとするなら、次の2つは「実技スコア」です。Terminal-Bench 2.1 スコア 90.6 は、実際のターミナル環境で多段階の操作タスクを完了する能力を測ります。ファイルを読み、コマンドを実行し、エラーを解析し、修正して再試行する。このスコアは、私たちがよく言う Computer Use / Shell Agent のシナリオに直接対応します。CyberGym 88.1 はセキュリティ攻防系のタスクに焦点を当てています。V4 Pro のこれら2項目での対応スコアは 87.9 と 83.3 であり、つまり V4.1-Flash は Terminal-Bench で約 2.7 ポイント、CyberGym で約 4.8 ポイント向上しています。
さらに注目すべきは、分解して見たときです。CyberGym のようなセキュリティシナリオは、長いチェーン、強い制約、ミスが許されないという要求が極めて高いにもかかわらず、向上幅はむしろ汎用ターミナルタスクよりも大きくなっています。これは、新しい事前学習手法と RL 後学習による利得が、厳密な推論とツール呼び出しを必要とするタスクで増幅されることを示しています。エンジニアリング上、これは2つの実装方向に対応します。
運用と CI/CD Agent：モデルにログ分析、ビルド失敗の特定、依存関係の競合修復を任せる。長コンテキストにより、完全なビルドログを途中で切り捨てられることなく一度に読み込めます。
セキュリティ分析 Agent：脆弱性の再現、トラフィックの研判、ルール生成。思考モードの max 段階と組み合わせて深い推論を行います。
ただし、鉄則を必ず覚えておいてください。ベンチマークスコアは無人運用の信頼性と等しくありません。90.6 は、100 タスクのうち依然として 10 近くが失敗することを意味し、ターミナル Agent の一度の誤操作（例えば rm -rf）の代償は極めて大きいです。したがって、実際のデプロイでは、サンドボックス、コマンドホワイトリスト、危険操作の二次確認、完全なロールバックスナップショットを必ず重ねる必要があります。ベンチマークスコアは、私たちが「使ってみようと思える」ようにするだけで、「保護なしで使う」ことを意味しません。
価格と時間帯戦略：キャッシュヒット/ミスとピーク/アイドル料率下での長コンテキストコスト最適化
長コンテキスト Agent の最大の敵は常にコストです。V4.1-Flash の公式価格（北京時間 2026-09-10 12:00 発効、単位は元/百万 tokens）は、非常に明確な最適化の手がかりを与えてくれます。
課金項目
アイドル時間帯
ピーク時間帯
V4 Flash 比
キャッシュヒット入力
0.02 元
0.04 元
60% 値下げ
キャッシュミス入力
1 元
2 元
約 33.3% 値下げ
出力
4 元
8 元
約 11.1% 値下げ
ピーク時間帯は月曜から金曜の 9:00-12:00 と 14:00-18:00 と定義され、アイドル時間帯の価格はピークの半分です。この表で最も重要な倍率は「どれだけ値下げしたか」ではなく、キャッシュヒットとミスの価格差：1 元 vs 0.02 元、実に 50 倍です。言い換えれば、同じ 100K tokens の文書でも、キャッシュヒット後は入力コストがほぼ無視できます。
ここから3つの実行可能な戦略が導かれます。
安定したプレフィックスを最大限キャッシュする。システムプロンプト、ツール定義、コードリポジトリの要約、長文書の前半など、複数ターン間で変わらない内容はすべて prompt の先頭に置き、キャッシュヒットを保証します。変化する内容は必ず後ろに置く——これが長コンテキストコスト最適化の第一原理です。
アイドル時間帯にバッチを実行する。すべての非リアルタイムタスク（オフライン評価、バッチコードレビュー、知識抽出、夜間データパイプライン）をアイドルウィンドウに移し、直接半分の費用を節約します。
出力コストを制御する。出力は 4/8 元で、384K の出力能力は非常に乱用されやすいです。モデルには構造化された短い結果（JSON Output）を返させ、長文コンテンツは会話に出力させるのではなくファイルに書かせます。
以下は実際に実行可能な Python のコスト認識呼び出し例で、核心は「固定プレフィックス + 可変サフィックス + 構造化出力」です。
import os, json
from openai import OpenAI

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

# 安定プレフィックス：先頭に置き、キャッシュヒットを最大化
FROZEN_PREFIX = (
    "あなたはコードリポジトリレビュー Agent です。以下はリポジトリで合意されたレビュー規範とツール説明であり、内容は長期的に不変です：\n"
    "1) 再現可能な高リスク問題のみを報告する；2) 厳密に JSON を出力する；3) 提供されていないファイルを推測しない。\n"
)

def review(repo_summary: str, changed_file: str) -> dict:
    messages = [
        {"role": "system", "content": FROZEN_PREFIX + "\nリポジトリ全体の要約：\n" + repo_summary},
        {"role": "user", "content": "この変更ファイルをレビューしてください：\n" + changed_file}
    ]
    resp = client.chat.completions.create(
        model="deepseek-flash",
        messages=messages,
        response_format={"type": "json_object"},
        max_tokens=4096
    )
    usage = resp.usage
    return {
        "result": json.loads(resp.choices[0].message.content),
        "cache_hit": getattr(usage, "prompt_cache_hit_tokens", 0),
        "cache_miss": getattr(usage, "prompt_cache_miss_tokens", 0)
    }

if __name__ == "__main__":
    out = review("リポジトリ要約プレースホルダー", "diff プレースホルダー")
    print(json.dumps(out, ensure_ascii=False))
私たちが repo_summary を各ターンの user メッセージではなく system プレフィックスに連結し、すべてのマルチターンリクエストが同じプレフィックステキストを再利用する点に注意してください。キャッシュヒットの判定はプレフィックスがバイト単位で一致することに依存しており、いかなる変更（たとえ改行が1つ増えるだけでも）もミスを引き起こし、コストは直接 50 倍になります。
2026-09-14 12:00 から deepseek-v4-pro が V4.1-Flash に全量ルーティング：移行の影響と課金の変化
公式は明確にしています。北京時間 2026-09-14 12:00 から、deepseek-v4-pro に送信されるすべてのリクエストは完全に V4.1-Flash にルーティングされ、Flash の価格で課金されます。同時に、旧モデル名 deepseek-v4-flash と deepseek-v4-flash-vision-exp はすでに廃止され、互換ルーティングが行われており、現在は deepseek-flash を統一的に使用すべきです。
本番システムにとって、このポリシーには3層の影響があります。
コスト削減は確実です。V4 Pro のトラフィックが Flash に落ちる
価格で、入力も出力もより安くなり、「より高い能力がより低コストで手に入る」ウィンドウ期にあたります。

動作の違いは潜在的なリスクである。ベンチマークスコアが高くても、2つのモデルは出力スタイル、拒否の境界、ツール呼び出し形式、思考モードのデフォルト動作において依然として差異がある可能性があります。V4.1-Flash はデフォルトで思考モードが有効になっており、これによりレイテンシと出力トークン数が大きく変化します。下流のパーサーが「返答がそのまま最終回答である」と仮定している場合、9-14 以降に突然思考プロセスのラッパーを受け取る可能性があります。
移行ウィンドウは数日しかない。ルーティングが有効になる当日になって初めて問題に気づくのを待ってはいけません。
推奨アクションリスト：
直ちにコード内のハードコードされたモデル名を deepseek-flash に変更し、ルーティング動作を明示化する。
ステージング環境でシャドウトラフィックを使い、V4 Pro と V4.1-Flash の出力差異を比較する。特に JSON 解析可能率、ツール呼び出しパラメータの正確率、平均出力長に注目する。
思考強度の段階選択を評価する：低レイテンシの場面では非思考または low、複雑な計画では high/max を使い、グローバルデフォルトがレイテンシバジェットを食いつぶすのを避ける。
課金とクォータの監視を確認する：同時実行制限は 2500 であり、あなたのレートリミッターが新しい上限と一致していることを確認する。
{
  "model": "deepseek-flash",
  "messages": [
    {"role": "system", "content": "あなたは移行検証 Agent です。2つのバージョンの出力差異を比較してください。"},
    {"role": "user", "content": "以下の制約を確認してください：厳密な JSON を出力し、新しいフィールドを追加せず、思考プロセスを出力しないこと。"}
  ],
  "response_format": {"type": "json_object"},
  "thinking": {"type": "enabled", "budget": "high"},
  "max_tokens": 8192
}
この JSON はリクエストボディの形態を示す例です。response_format を明示的に宣言することで構造化を保証し、思考段階を明示的に宣言することでデフォルト値のドリフトを避け、それによって移行に伴う動作の不確実性を制御可能な範囲に収束させます。
552B MoE + 新しい事前学習とより大規模な RL 事後学習：能力向上の背後にある学習側のメカニズム
なぜ「最小サイズのメンバー」がフラッグシップを逆転できるのか？答えは学習側にあります。V4.1-Flash は 552B 総パラメータの MoE であり、まったく新しい Causal-Encoder-Decoder（CED）非対称アーキテクチャを採用しています。入力側では 8B のみを活性化し、出力側では 16B を活性化します。この設計の直感は、理解は生成よりも「安い」というものです。入力側は与えられたコンテキストに直面し、そのタスクは 1M トークンを有効な表現に圧縮することであり、8B の活性化で十分です。一方、出力側は段階的な生成を必要とし、より強力な推論と意思決定を必要とするため、16B の活性化が与えられます。非対称な活性化により、長コンテキスト入力の場面で計算資源を最も重要なところに使えます。
これに対応する 2 つの学習側の変化があります：新しい事前学習手法とより大規模な RL 事後学習です。事前学習は知識の基盤と長コンテキストモデリング能力を決定し、RL 事後学習は「ツールを使えるか、形式どおりに納品できるか、多段階タスクで目標を維持できるか」を決定します。これはまさに、Terminal-Bench 2.1（90.6）や CyberGym（88.1）のようなプロセス重視・制約重視の Agent 指標が顕著に向上した理由を説明しています。それらは本質的に、単なる知識量ではなく、RL 事後学習によって形成された行動戦略を試しているのです。
もう一つ見落とされがちなエンジニアリング上の事実があります：KV Cache の HBM 要件は前世代の 1/4 に低下し、SSD ストレージは 1/8 に低下し、初代 DeepSeek と比べて約 437 倍縮小しました。これは、1M コンテキストがもはや単なる「インターフェース対応」ではなく、長期間常駐でき、高並列でサービス提供できるエンジニアリング能力であることを意味します。マルチターン Agent を構築するチームにとって、これはセッション間でコンテキストを永続化できるか、それとも毎回再構築する必要があるかを直接左右します。
Hugging Face の重みと公式パートナー連携：WorkBuddy、CodeBuddy、OpenCode の実装参考
V4.1-Flash の重みは Hugging Face で公開済みであり、技術レポートも添付されています。プライベート化、監査、カスタム推論スタックを必要とするチームにとって、これは完全な実装パスです。ほとんどのアプリケーションチームにとって、より実用的な参考は公式パートナーです：WorkBuddy（CodeBuddy を含む）と OpenCode はすでに全面的に連携済みです。
これら 2 種類の連携者のエンジニアリング的価値は、それらが 2 つの典型的な Agent 形態を代表している点にあります：IDE 内のコーディング Agentとターミナル/ワークフロー Agentです。それらは長コンテキストの切り詰め、ツール呼び出しの並列性、思考モードのオンオフ、失敗時のリトライと状態復元を実際に処理しなければなりません——これらはまさにあなた自身が踏むことになる落とし穴です。それらの取捨選択を参考にすれば、多くの回り道を避けられます。同時に、重みのオープンソース化 + 技術レポートは、ローカル評価ベースラインを作成し、公式ベンチマークをあなたの業務評価セットと整合させることができることを意味します。単一のリーダーボードを盲信する必要はありません。
長コンテキスト・マルチモーダル Agent のエンジニアリング上の落とし穴：1M 入力から 384K 出力までの切り詰め、リトライ、状態管理
この節は記事全体で最も「痛い」部分です。1M 入力、384K 出力は美しく聞こえますが、実際に導入すると一連の問題にぶつかります：
リクエストボディが大きすぎてゲートウェイがタイムアウトする。1M トークンのリクエストはシリアライズ後に巨大なサイズになります。クライアントと中間層の両方で制限を緩和する必要があり、base64 を直接メッセージボディに詰め込むのではなく、Files API / 画像リンクを優先的に使うべきです。ネイティブのマルチモーダル対応は画像リンク、base64、Files API の 3 方式をサポートしており、長い会話ではリンクと Files API を優先します。
384K 出力は一度にすべて吐き出せるという意味ではない。長い出力はタイムアウトと切り詰めを非常に引き起こしやすいです。正しい方法は分割生成 + 増分永続化です：モデルに章/モジュールごとに分割して出力させ、各セグメントが終わるたびに永続化し、失敗時は現在のセグメントだけをリトライし、全体をやり直さないようにします。
リトライは冪等でなければならない。Agent がツールを呼び出すとき、リトライは重複した書き込み操作を引き起こす可能性があります。各ツール呼び出しに決定的な ID を生成し、サーバー側で重複排除を行います。書き込み操作にはモデルに一意キーを要求します。
並列性とレート制限。並列上限は 2500 ですが、実際のボトルネックはしばしばトークンスループットにあります。リクエスト数ではなくトークンでトークンバケットによるレート制限を行い、ピーク時にはバックオフを適用します。
マルチターンの状態管理。すべての履歴を無限に追加してはいけません。そうしないとキャッシュプレフィックスが頻繁に無効になります。戦略は：固定プレフィックス（キャッシュ）+ ローリング要約（履歴の圧縮）+ 直近 N ターンの原文です。
切り詰め検出。finish_reason が長さによる切り詰めかどうかを確認し、切り詰められている場合は「前文から続ける」プロンプトで続きを書かせ、完全なタスクを再発行しないようにします。
思考モードの落とし穴。思考モードはデフォルトで有効であり、出力に思考内容が含まれる可能性があります。FIM は非思考モードのみをサポートします。会話プレフィックス継続と思考モードの組み合わせは個別に検証する必要があります。
もう一つの注意点：JSON Output、Tool Calls、Responses API、Anthropic API、会話プレフィックス継続、FIM はすべてサポートされていますが、能力マトリクスは完全に直交しているわけではありません——FIM は非思考モードでのみ利用可能です。フォールバックパスを設計するときは、「能力リスト」ではなく「能力の組み合わせ」でテストしてください。
まとめとベストプラクティス
選定の収束：V4.1-Flash はベンチマークで V4 Pro を全面的に上回ります（GPQA Diamond 90.9、Codeforces 3471、MathArena Apex 65.6、Terminal-Bench 2.1 90.6、CyberGym 88.1）。これをデフォルトの主力モデルとして使え、「強いモデルが計画 + 弱いモデルが実行」という階層化はもはや不要です。
直ちに改名：統一的に deepseek-flash を使用してください。旧名の deepseek-v4-flash と deepseek-v4-flash-vision-exp はすでに廃止され、互換ルーティングを通ります。
9-14 12:00 を注視：その時点から deepseek-v4-pro のリクエストはすべて V4.1-Flash にルーティングされ、Flash の価格で課金されます。コストは下がりますが動作がドリフトする可能性があるため、必ず事前にシャドウ比較を行ってください。
コストの三本柱：安定したプレフィックスでキャッシュを最大限に活用（ヒット/ミスの価格差は 50 倍）、非リアルタイムタスクを空闲時間帯に移す（価格はピークの半分）、出力はできるだけ構造化して短くする（384K は上限であり目標ではない）。
動作を明示的に宣言：思考強度（low/high/max）と response_format を明確に指定し、デフォルト値に依存しない；FI
M は非思考モードでのみ使用されます。
マルチモーダル入力：画像リンクと Files API を優先し、base64 はあくまでフォールバックとする。
長文出力のエンジニアリング：分割生成、増分でのディスク書き込み、セグメント単位のリトライ、finish_reason による打ち切り検知と継続生成。
安全フォールバック：ターミナル系・セキュリティ系の Agent には、サンドボックス、コマンド許可リスト、危険操作の二次確認、スナップショットによるロールバックを必ず重ねる。ベンチマークスコアが高くても無人運用が可能とは限らない。
状態戦略：固定プレフィックス + ローリング要約 + 直近 N ターンの原文とし、履歴の無限追加によるキャッシュ無効化を避ける。
ローカルベースライン：Hugging Face の重みと技術レポートを組み合わせてプライベート評価セットを構築し、WorkBuddy（CodeBuddy を含む）と OpenCode の全量接続の実践を参考に、公式ベンチマークを自社のビジネス指標へと変換する。