Claude の API は、長い文章を「読ませて考えさせる」用途で選ばれることが多い。Opus / Sonnet / Haiku の 3 段構成で、200K から最大 1M トークンという大きなコンテキストを扱えるため、契約書・仕様書・ログといった長文ドキュメントを丸ごと渡して解析・要約するワークロードに向く。
コーディング支援での実用性
Claude Code との連携を含め、コード生成・リファクタリング・レビューの精度が評価されている。曖昧な指示に対しても破綻の少ない実装を返す傾向があり、開発支援ツールのバックエンドとして採用するチームが増えている。Tool Use や Computer Use を使えば、モデルにファイル操作やブラウザ操作を委ねたエージェント的な処理も組める。
コスト構造の勘所
従量課金で、Opus は品質重視の高価格帯、Sonnet が標準、Haiku が低コスト帯という位置づけ。注目したいのが Prompt Caching で、同じ長文プレフィックス（システムプロンプトや参照資料）を繰り返し送る場合、キャッシュ分の入力コストを大きく圧縮できる。長文を毎回投げる設計ほど効く仕組みなので、導入時に組み込みたい。実務では「下書きや分類は Haiku、最終出力は Sonnet、難所だけ Opus」とモデルを段階的に使い分けると、品質とコストの折り合いが付けやすい。
モデル選定の実務
3 段構成は便利な反面、どのモデルをどこに当てるかを設計初期に決めておかないと、コストか品質のどちらかで後悔しやすい。経験則としては、ユーザーに見える最終出力は Sonnet を基準にし、レイテンシとコストがシビアな分類・整形・要約の前処理は Haiku に、人間でも判断が割れる難所だけ Opus に振る。モデルは継続的に更新されるため、評価用のプロンプト集を用意して新バージョンが出るたびに回帰確認する運用にしておくと、入れ替えの判断が機械的に下せる。
避けるべきケース
画像生成や音声合成は守備範囲外で、これらは別サービスと組み合わせる必要がある。また、既存資産が OpenAI 互換エンドポイント前提で組まれている場合、リクエスト/レスポンス形式が異なるため移行にはアダプタ層の実装が要る。逆に、入力をそのまま素直に解釈してほしい長文処理や、安全性と説明責任を重視するプロダクション用途であれば第一候補になる。
長文を投げる設計はコスト構造ごと変わる
大きなコンテキストを扱えることは、そのまま「毎回大量の入力トークンを送る」ことを意味する。参照資料を丸ごと添付する作りにすると、リクエストごとの入力コストが積み上がる。ここで効くのが Prompt Caching で、繰り返し送る長いプレフィックス（システムプロンプトや参照文書）をキャッシュ扱いにできる。重要なのは、キャッシュが効くのは「先頭から共通する部分」だという点だ。可変部分を前に置くとキャッシュが効かなくなるため、固定の資料を前、可変の質問を後ろという順序でプロンプトを組み立てる必要がある。
大きな窓に資料を詰め込むほど精度が上がる、というものではありません。無関係な情報が混ざると、かえって的外れな参照が起きます。検索で絞ってから渡す構成のほうが、コストでも精度でも有利になる場面は多くあります。窓の大きさは「絞り込みを省ける」という意味ではなく「絞り込みの失敗を許容できる」という意味で捉えるのが実務的です。
エージェント的な使い方をするときの前提
Tool Use を使ってモデルに外部操作を委ねる場合、モデルが誤った引数でツールを呼ぶ可能性を常に想定する必要がある。破壊的な操作（削除・送信・決済）をツールとして直接渡すのは危険で、実行前に人間の確認を挟むか、影響範囲を限定したツールに分割するのが定石だ。ツールの設計は、モデルの賢さに期待するのではなく「間違えても取り返しがつく範囲に閉じる」ことを前提にする。