Claude Fable 5、明日から世界中で利用可能に

実際に何が起きたのか

Claude Fable 5は、Anthropicの現在のモデルラインアップの一部として、明日から世界各地で利用可能になります。

世界全体で利用できることは、運用上重要です。複数の地域でClaude APIを使って製品を構築している場合、段階的な提供では、ある地域ではあるモデルを、別の地域では別のモデルを使うという、扱いにくいフォールバックロジックが必要になりがちです。そのうえ、コンテキストの上限もプロンプトへの反応も異なります。世界全体で利用できれば、プラットフォームチームは長いコンテキストを扱うワークロードを地域固有の例外として扱うのではなく、共通のモデル処理経路を設計し始められます。

技術的な変化は、1Mのコンテキストウィンドウです。コンテキストは人間の意味での記憶ではなく、データベースでもありません。リクエストの処理中にモデルが参照できる情報です。コンテキストが大きくなっても、インデックス作成、検索、キャッシュ、要約、慎重なプロンプト設計は依然として必要です。ただし、情報を失う圧縮がバグの原因になっていたケースでは、エンジニアがその圧縮を後回しにできるようになります。

実際には、長いコンテキストの最も価値ある点は、百万トークンを貼り付けられることではありません。モデルに何を見せて「よい」のかを、早い段階で決めずに済むことです。

Claude Fable 5がClaude APIエンジニアにとって重要な理由

現在、本番環境でよく使われるパターンは次のようなものです。

1. ユーザーが大規模なコードベースや文書群について質問します。
2. システムがそのクエリを埋め込みベクトルに変換します。
3. 上位k件のチャンクを取得します。
4. それらのチャンクを基に回答するようClaudeに求めます。
5. 重要な制約がチャンク5ではなくチャンク17にあったため、回答が失敗します。

このアーキテクチャには、今でも用途があります。検索は、すべてのリクエストに巨大なコンテキストを詰め込むよりも安価で高速であり、多くの場合、構成もすっきりします。しかし、Fable 5の1Mコンテキストにより、コンテキストの最小化よりも情報の完全性が重要なタスクで、別の処理経路を選べるようになります。

たとえば、社内向けの移行支援アシスタントを想像してください。ユーザーは次のように質問します。

「従来の請求書ステータスのサポートを削除すると、どのサービスが動作しなくなりますか PENDING_REVIEW?”

対象を絞ったRAGパイプラインでは、列挙型の定義と少数の直接参照が取得されるかもしれません。長いコンテキストを使うワークフローでは、次のものを含められます。

• 列挙型の定義。
• すべての呼び出し箇所。
• データベースのマイグレーション履歴。
• APIコントラクトファイル。
• 生成されたクライアントコード。
• テストフィクスチャ。
• 最近のインシデントに関する記録。
• 提案されたパッチ。

この違いが重要なのは、エンジニアリング上の問題が局所的なものにとどまることはほとんどないからです。バグは、生成されたクライアント、古いフィクスチャ、そして二年間誰も手を加えていない再試行処理の相互作用に潜んでいることがよくあります。

以下は、リポジトリ分析タスクに使うシンプルなClaude APIリクエストの形式です。SDKの具体的なインターフェースはバージョンによって異なる場合がありますが、重要なのはパターンです。継続的に適用する指示をシステムプロンプトに置き、構造化したファイル群を送信し、根拠に基づいた回答を要求します。

{
  "model": "claude-fable-5",
  "max_tokens": 4096,
  "system": "You are reviewing a production codebase migration. Use only the provided repository snapshot. Cite file paths for every claim. If evidence is missing, say what is missing.",
  "messages": [
    {
      "role": "user",
      "content": [
        {
          "type": "text",
          "text": "We plan to remove support for invoice status PENDING_REVIEW. Identify breaking changes, risky assumptions, and tests to update."
        },
        {
          "type": "text",
          "text": "<repo_snapshot>\n...large structured repository content...\n</repo_snapshot>"
        }
      ]
    }
  ]
}

実用上の注意点として、tarballのようなひと塊のデータを送り、モデルが構造を推測してくれると期待しないでください。入力をたどりやすい形にしましょう。

コードには、私は次のような形式を好んで使います。

<file path="services/billing/src/invoice_status.py">
...
</file>

<file path="services/billing/tests/test_invoice_lifecycle.py">
...
</file>

<file path="docs/billing-state-machine.md">
...
</file>

このわずかな構造化が効果を発揮します。Claudeは正確なパスを参照し、境界について推論し、ラベルを付けておけば生成ファイルと手書きのコードを区別できます。

1Mコンテキストで変わるClaude Codeのワークフロー

Claude Codeは、ツールを使ってリポジトリを調査できる状況で、すでに十分に機能します。Fable 5は、問題が多数のファイルにまたがるセッションや、コンテキストを何度も再発見することなく、モデルにより多くの作業情報を保持させたいセッションでの動作を変えます。

たとえば、大規模な移行では、私は次のようにClaude Codeを起動することがあります。

claude

次に、明確な作業指示を次の場所に設定します。 CLAUDE.md:

# Project Instructions

- Prefer small, reviewable patches.
- Do not modify generated files directly.
- Run `pnpm test --filter billing` before finalizing billing changes.
- For API changes, update OpenAPI specs and generated clients.
- When uncertain, inspect call sites before editing shared types.

長いコンテキストを使う作業では、チャット履歴だけに頼らず、タスク専用の作業メモファイルも追加するのが好みです。

# Migration Notes: Remove PENDING_REVIEW

## Known entry points
- services/billing/src/invoice_status.py
- services/api/openapi/billing.yaml
- workers/invoice_reconciliation/*

## Questions to resolve
- Does any external webhook still emit PENDING_REVIEW?
- Are old records migrated or tolerated at read time?
- Which tests encode this status as a fixture?

続いて、Claude Codeで次のように指示します。

claude "Analyze the billing status migration notes and inspect the repository for all remaining dependencies on PENDING_REVIEW. Do not edit yet. Return a risk map with file paths."

コンテキストが小さいモデルでは、アシスタントが検索と要約を繰り返し、その過程で詳細を忘れることがあります。Fable 5では、セッション内で調査内容をより多く同時に保持できます。この改善が最もよく現れるのは、APIスキーマ、フロントエンドの描画、ワーカーの挙動、データベースの値、テストなど、リポジトリ内の離れた部分を比較する必要があるタスクです。

よくある落とし穴として、長いコンテキストが使えると、ユーザーが指示をおろそかにしがちです。それは逆効果になります。コンテキストが増えるとモデルにより多くの根拠を与えられますが、注意をそらす情報も増えます。私は今でもタスクの範囲を厳密に定めています。

claude "Implement only the server-side compatibility layer for legacy invoice statuses. Do not change frontend code. Preserve existing API response shape. Add tests for reading old records."

長いコンテキストは、作業範囲を定めることの代わりにはなりません。範囲を定めた作業を、より十分な情報に基づいて進められるようにします。

Fable 5のAPI設計パターン

設計上の最大の課題は、Sonnet 4.6やHaiku 4.5に対して、いつFable 5を使うかということです。

私は、すべてのリクエストを1Mコンテキストのモデルに振り分けることはしません。トレードオフは単純です。コンテキストが大きいほど、モデルは完全な根拠を使って推論する余地を得られますが、リクエストのサイズと料金設定によっては、レイテンシとコストが増えることがあります。モデルが大きな入力に対応していても、アプリケーションが無関係な情報を無差別にシリアライズしていれば、エンジニアリング上の負担は依然として生じます。

適切なルーティングパターンは次のとおりです。

def choose_claude_model(task):
    if task.kind in {"classification", "routing", "field_extraction"}:
        return "claude-haiku-4-5"

    if task.context_tokens > 180_000:
        return "claude-fable-5"

    if task.requires_deep_reasoning and task.blast_radius == "high":
        return "claude-opus-4-8"

    return "claude-sonnet-4-6"

そのしきい値は、あらゆる状況に推奨できるものではありません。私が普段モデルのルーティングをどう考えているかを示す例です。不要な情報の削除を省けて便利だからではなく、入力の大きさがタスクそのものに由来する場合にFableを使います。

本番環境のAPI連携では、コンテキストのサイズと結果の品質も別々に記録します。

import time
from anthropic import Anthropic

client = Anthropic()

def analyze_change(repo_bundle: str, question: str):
    started = time.time()

    response = client.messages.create(
        model="claude-fable-5",
        max_tokens=5000,
        system=(
            "You are a senior code reviewer. Use the provided files only. "
            "Return risks, evidence, and recommended tests. Cite paths."
        ),
        messages=[
            {
                "role": "user",
                "content": f"""
Question:
{question}

Repository bundle:
{repo_bundle}
"""
            }
        ],
    )

    elapsed_ms = int((time.time() - started) * 1000)

    return {
        "model": "claude-fable-5",
        "elapsed_ms": elapsed_ms,
        "answer": response.content[0].text,
    }

実際のシステムでは、次の項目を追加します。

• バイト数だけでなく、トークン数によるリクエストサイズの記録。
• タスクの種類ごとのタイムアウトと再試行の動作。
• 重要度の低いワークフロー向けのフォールバックモデル処理経路。
• プロンプトのバージョン管理。
• 期待される検出結果が既知の評価用フィクスチャ。
• 長いコンテキスト用にまとめる前の機密情報の除去。

機密情報の除去は、重要性を過小評価しやすい点です。コンテキストウィンドウが大きいと、秘密情報、顧客データ、無関係な社内メモを誤って含めやすくなります。リポジトリのファイル群に次のものが含まれている場合、 .env、本番環境の設定、秘密鍵、または未加工のユーザーデータのエクスポートが含まれているなら、それはモデルの機能ではなく、アプリケーションのバグです。

長いコンテキストが検索を上回る場面

検索拡張生成は今でも役立ちます。私も常に使っています。ただし、長いコンテキストによって、そのバランスは変わります。

主な違いは、失敗の仕方です。検索は情報の欠落によって失敗します。長いコンテキストは、情報の希薄化によって失敗することがより多くなります。回答に必要な根拠がすべて利用可能でも、適切な部分を優先させるための明確な指示が依然として必要です。

エンジニアリングのタスクでは、情報の欠落のほうが深刻なことがよくあります。「この移行は本番環境を壊しますか」と尋ねるなら、回答が少し遅くなることよりも、依存関係の見落としのほうが気になります。

とはいえ、重要なシステムでは、私は今でもハイブリッド設計を好みます。

1. 検索を使い、関連する可能性の高い箇所を特定します。
2. インポート、呼び出し元、設定、テストなど、依存関係に沿って対象を広げます。
3. 対象を広げたファイル群をFable 5に含めます。
4. 何が不足しているかを特定するようClaudeに求めます。
5. リスクが最も高いファイルだけに絞って、再度分析します。

これにより、検索の効率性と、重要な箇所での長いコンテキストによる推論の網羅性を両立できます。

Claudeのラインナップとロードマップにおける位置づけ

現在のラインナップは、「小・中・大」という分類よりも、専門化された実行環境の集合に近づき始めています。

Sonnet 4.6は、多くの本番エンジニアリングワークフローで、私がまず選ぶ標準モデルであり続けています。ほとんどのコーディング、レビュー、ツールを使うエージェントループに十分な能力があり、レイテンシ、コスト、品質のすべてが重要なシステムに適する傾向があります。

Opus 4.8は、アーキテクチャのトレードオフ分析、原因が曖昧なバグ、複雑なリファクタリング、誤った回答による損失が大きい計画立案など、最も難しい推論を要する処理に取っておくモデルです。

Haiku 4.5は、大量処理向けです。タスクが構造的に単純なら、必要のない深い推論に費用をかけるべきではありません。

Fable 5は、ラインナップに異なる軸を加えます。推論が単に強力になるだけでなく、作業記憶の範囲が広がります。これは重要です。AIアプリケーションの失敗の多くは、モデルに推論能力がないために起こるのではありません。モデルが、不完全で歪んだ形で表された問題を見ていたために起こります。

過大な主張をせずとも、ロードマップへの示唆は十分に明らかです。Claudeは、モデルが現実世界のより大きな成果物を直接扱えるワークフローへと向かっています。リポジトリ、長い文書、顧客履歴、トレース、仕様書、設計アーカイブは、推論の前に大幅に圧縮しなければならないものではなく、主要な入力になっていきます。

制約も同じくらい重要です。1Mのコンテキストウィンドウがあるからといって、すべてのトークンが同じように重要になるわけではなく、細かな情報をすべて完璧に思い出せる保証もありません。エンジニアは引き続き、重要な情報を見つけやすく、ラベルが付いていて、タスクに関連する形になるよう、プロンプトと入力を設計する必要があります。

実践的な入力のパッケージ化

Fable 5では、パッケージ化もプロンプトエンジニアリングの一部になります。

悪い入力例：

Here is a giant dump of files:
[file contents pasted in arbitrary order]
What breaks?

より良い入力例：

Task:
Determine whether removing PENDING_REVIEW breaks billing behavior.

Repository map:
- services/billing: core invoice lifecycle
- services/api: public REST schema
- workers/reconciliation: async status updates
- web/admin: admin UI

Constraints:
- Do not recommend frontend changes unless API behavior changes.
- Treat database values older than 2024-01-01 as still possible.
- Cite file paths.

Files:
<file path="services/billing/src/status.py">...</file>
<file path="services/api/openapi/billing.yaml">...</file>
<file path="workers/reconciliation/status_mapper.ts">...</file>

APIアプリケーションでは、私は通常、バンドルを機械的に構築します。

rg -l "PENDING_REVIEW|InvoiceStatus|invoice status" \
  services workers web docs \
  | sort \
  > /tmp/fable-files.txt

その後、小さなスクリプトでファイルをまとめられます。

from pathlib import Path

paths = Path("/tmp/fable-files.txt").read_text().splitlines()

for path in paths:
    p = Path(path)
    if p.suffix in {".png", ".jpg", ".lock"}:
        continue

    text = p.read_text(errors="replace")
    print(f'<file path="{path}">')
    print(text)
    print("</file>")

本番環境では、これを適切なバンドラーに置き換え、シークレット、生成物、依存関係のディレクトリ、大きなバイナリ、無関係なスナップショットを除外します。

コンテキストを詰め込みすぎると実際に何が起きるのか

チームが初めて大きなコンテキストウィンドウを使えるようになると、やりすぎる傾向があります。リポジトリ全体、Slackの全エクスポート、ログ、ドキュメント、チケット、メトリクス、会議メモなど、すべてを含めてしまうのです。

モデルは以前よりはるかに多くの情報を処理できますが、アプリケーション側では依然として適切な判断が必要です。情報を含めすぎると、いくつかの問題が生じます。

• レイテンシが増加します。
• コストが増加します。
• 機密データが露出するリスクが高まります。
• プロンプトのデバッグが難しくなります。
• モデルが無関係なコンテキストに注意を割く可能性があります。
• 各リクエストに含まれる変数が多すぎるため、評価にノイズが増えます。

解決策は、小さなチャンクに戻すことではありません。タスクに必要な根拠を一通り揃えてパッケージ化することです。コード移行なら、会社のモノレポ全体ではなく、サブシステム全体が必要になるかもしれません。インシデントなら、その週のすべてのログ行ではなく、完全なタイムラインが必要になるかもしれません。

私の経験則は、Claudeがこちらの前提に疑問を呈せるだけのコンテキストを含めることです。選択したファイルだけでは不十分だとモデルが気づけないなら、バンドルの範囲が狭すぎます。無関係な情報の山からモデルがタスクを推測しなければならないなら、バンドルの範囲が広すぎます。

実践上のポイント

Claude Fable 5のグローバル提供が最も大きな意味を持つのは、コンテキストの断片化によってClaudeのワークフローが行き詰まっているチームです。簡潔なプロンプトと検索ですでにアプリケーションがうまく動作しているなら、大きなウィンドウが登場したというだけで書き直す必要はありません。

推論の対象が本来大きな単位である場合に、Fable 5を使ってください。たとえば、サブシステム、長い契約書、インシデントの完全なタイムライン、複数のドキュメントにまたがる設計の履歴などです。

一般的な本番業務では引き続きSonnet 4.6をデフォルトとし、高速な構造化タスクにはHaiku 4.5、最も難しい推論にはOpus 4.8を使ってください。

Claude Codeでは、明確な CLAUDE.md 指示を追加し、タスクのメモをリポジトリに保存し、大規模な変更では編集前に調査するよう依頼してください。Fable 5は調査内容をより多く保持できますが、それでも範囲を明確に定めることが役立ちます。

APIを利用する場合は、入力のパッケージ化に力を入れてください。ファイルのラベル付け、リポジトリマップ、明示的な制約、シークレットのフィルタリング、トークン数の記録、評価用フィクスチャなどです。1Mのコンテキストウィンドウは強力ですが、規律あるエンジニアリングによって真価を発揮します。

本当の変化は「プロンプトにもっと情報を貼り付ける」ことではありません。要約、検索、推測を強いる前に、Claudeが実際のシステムのより広い範囲を対象として推論できるようになったことです。これにより、エンジニアは本当に尋ねたかった質問をモデルに投げかけやすくなります。