Claude Sonnet 4が1百万トークンのコンテキストに対応
(anthropic.com)- AnthropicのClaude Sonnet 4が最大1百万トークンのコンテキストを提供するようになり、大規模なコードベースや多数の文書を一度に処理できるようになった
- 強化されたコンテキスト対応により、大規模コード分析、膨大な文書群の処理、コンテキストを維持するエージェント開発など、さまざまな活用が可能になった
- 20万トークンを超えるプロンプトではAPI料金が引き上げられるが、プロンプトキャッシュやバッチ処理によってコスト削減が可能
- 実際の顧客であるBolt.newとiGent AIは、この機能によって生産性とAI機能を大きく向上させている
- 現在、Sonnet 4のロングコンテキスト対応はAnthropic APIとAmazon Bedrockでベータ提供中で、まもなくGoogle Cloudにも展開予定
1百万トークンのコンテキスト対応
- Anthropic APIを利用するClaude Sonnet 4が、最大1百万トークンのコンテキストに対応
- これにより、1回のリクエストで75,000行を超えるコード全体や複数の研究論文をまとめて処理できる機能を提供
- 1百万トークンコンテキストのベータ機能は、現在Anthropic APIとAmazon Bedrockで利用可能で、Google CloudのVertex AIもまもなく対応予定
より長いコンテキストで広がる活用事例
- 大規模コード分析: コードベース全体（ソースファイル・テスト・ドキュメントを含む）を一度に読み込み、プロジェクト構造の理解、ファイル間の関連性把握、システム設計に基づくコード改善提案が可能になる
- 文書の統合要約: 数百件におよぶ法務契約書、論文、技術仕様書を一括分析し、文書間の関係を維持したまま総合的なインサイトを導き出せる
- コンテキスト維持型エージェント: 数百回のツール呼び出しやマルチステップのワークフローの過程でも、APIドキュメント全体・ツール定義・相互作用の記録を含めて一貫した状態を保つ対話型エージェントを開発できる
API価格ポリシー
- 20万トークン以下のプロンプト: 入力 $3/100万トークン、出力 $15/100万トークン
- 20万トークン超のプロンプト: 入力 $6/100万トークン、出力 $22.5/100万トークン
- プロンプトキャッシュを適用すると、レイテンシとコストを削減できる
- 1百万トークンのコンテキストとバッチ処理を組み合わせると、最大50%の追加コスト削減が可能
顧客企業での活用事例
-
Bolt.new
- Bolt.newはClaudeをWebベースの開発プラットフォームと統合し、Web開発の革新を進めている
- "Sonnet 4の1百万コンテキストウィンドウにより、開発者はより大規模なプロジェクトを高い精度で扱えるようになった"
-
iGent AI
- 英ロンドン拠点のiGent AIは、MaestroというAIパートナーを通じて会話内容を実行可能なコードへ変換する
- "以前は不可能だった自律的なソフトウェアエンジニアリング機能が、Sonnet 4の1百万トークンコンテキストによって実現し、実際のコードベース上で数日にわたるセッション運用が可能になった"
利用方法と今後の計画
- ロングコンテキスト機能は、Anthropic APIのTier 4およびカスタム料金プランの顧客にベータ提供中で、数週間以内により広いユーザー層へ拡大予定
- Amazon Bedrockでも対応中で、Google Cloud Vertex AI対応もまもなく提供される予定
- 他のClaude製品群にもロングコンテキストを導入する計画
- 詳細情報は公式ドキュメントと価格案内ページで確認可能
1件のコメント
Hacker Newsの意見
プロのソフトウェアエンジニアリング業務では、LLMが本当に優れたコンテキスト保持力を持つことが切実に必要だと感じる。新しいモデルが少し良くなったという発表は、実務ではあまり興味を引かない。しかし価格が最大の決定要因だ。自分のコードベースを十分にコンテキストウィンドウへ入れられるのは良いが、価格が大きく上がったので、今はコンテキスト管理をもっと上手くやる方が正しいと思う。自分がコンテキストウィンドウを多く使うのはサービス提供者には得でも、実際にSonnetがどれだけ効果的に焦点を維持できるかは別途評価が必要だと感じるので、実際の価値を確信しにくい
コンテキストはリポジトリにあり、LLMが常に必要なコンテキストをすべて持てるわけではないと認めるべきだ。特に大規模リポジトリは1台のマシンに全部入らない。特定の作業を完了するには、集中のために不要な情報を取り除く必要があるが、すべてを入れるとかえって集中力が落ちる。以前はウィンドウサイズが小さすぎたし、今でも小さいと思うが、最終的には適切な質問を通してリポジトリを理解する能力が必要だ
コンテキストを入れすぎると、LLMが自分自身で混乱するリスクが高まる。長いコンテキストのせいでリセットせずに進めると、集中力が乱れる
コードベース全体ではなく、抽象化された情報だけをAIが扱うように訓練する必要があると思う。実際、人間もコード全体を頭に入れて仕事をしているわけではないので、LLMもそうである必要はないという立場だ
最近Claude Codeで数週間作業した後、エージェント型AIの実質的な価値はむしろマイナスだという結論に達した。それでも6〜8か月後にもう一度試す予定だ
用途は単により多くのコードを一度にコンテキストへ入れることだけではないと思う。特定の作業には最低限必要な文脈もあるが、1Mコンテキストモデルはデータをどう投入するかについて新しいやり方を求める。このモデルの本当の強みは、長いホライズンでの反復探索、インコンテキスト学習、再構成のようなディープダイブ問題にある。例えばAPI変更を100個のファイルに適用する幅優先の作業もあるが、15通りの方法を試しながら解決策を探す深さ優先の作業にも強みを持つ。Sonnet 1Mは特に後者で際立った能力を見せる
Claude Codeとトークン使用量が心配なユーザー向けに、いくつかのヒントを提案する
/resumeで同じスレッドを呼び出し、コンテキストが豊富な時点へダブルエスケープしてリセットできるClaudeに「別セッションであなたがX作業を書いた」と伝え、そのコンテキストを活用して質問したり変更依頼をしたりする方法を使っている
自分もよくそうするが、常にうまく効くわけではない。ときには会話全体の文脈を持ったままClaudeを使う方が助けになる
待ち時間が大きく減る。新しいClaudeが文脈ロードを最初からやり直すのを待つ必要がない
この過程がプログラマー向けの占星術のように感じられる。言わなければ、エージェントがコードベース作業中に何が起きるか分からない
興味深いのは、コードを別の開発者が書いたかのように伝えるとClaudeがより多くの問題を見つける理由が気になることだ
これまでClaude Codeで最も役立った使い方は「現在のdiffにバグはある？」と直接聞くことだ。するとチャットボットが変更点を綿密に分析し、長い時間と数多くのデプロイ工程を必要とする微妙なバグを素早く見つけてくれて、コードの正確性を高めるためのさまざまな点を項目ごとに教えてくれる
「もっと深く考えてほしい」と別に指示しなくても、望みどおりによく動く点が不思議だ
コーディング以外の作業でも使った経験上、創造性は不足しているが、批評的で几帳面なリーダーとしての能力は優れている
この機能をClaude Codeのhookとして具体的に実装すると良いという提案もある
本人も明日からすぐこの方法を試してみるつもりだ
現在のツールに対する自分の経験は次のとおり
自分も似たようなものだった（Cline + Sonnet & Geminiを1年）。その後Claude Codeに出会い、何よりも「コンテキストを本当にきれいに管理する方法」を身につけてから、本当の突破口を感じた。AIをコード生成器ではなくアーキテクト兼実装者として扱うのが肝だ。最近はまず必ずCCに、これからやる作業の設計文書を書かせ、それをコードと文書の両方を参照するよう指示している。自分がそれをレビューしながら望む方向性を明確に確認したあと、作業ステップをchunkに分け、各chunkもさらに細分化する。初期定義が終わったら文脈を消し、ステップごとに文書を読ませてから実装させる。必要なら修正方針を決めたり、文書を直してそのステップだけやり直したりする。各ステップごとにコミットし、文脈をクリアし、次のステップへ、というやり方だ。こうすると以前は2〜3日かかっていた機能を1日以内で作れる。結果として、検証済みの文書、ユニットテスト、Storybook、アクセシビリティ（ariaなど）までしっかり揃った成果物が得られる。最後は別モデルでコードレビューも受ける。たとえ今すぐ圧倒的な速度を出せなくても、成長するツールに備えた実力への未来投資だと思っている
自分の考えでは、このツールは昔のRuby on Railsの
rails newスキャフォールディングに近い感覚だ。LLMはツールの公式ドキュメントさえよく把握すればよい領域、つまりプロジェクト初期の骨組み作りにはぴったりだ。一方でレガシーシステムや外部要件の多いプロジェクトでは有用性が低い。Databricksのように変化の速いツールについてはほとんど役に立たない。トレーニングデータ以後に名称・文法・機能が変わっているなら、リアルタイムのドキュメントをプロンプトに積極的に使ってようやく可能性が出る自分のワークフローではClaudeデスクトップとmcpサーバーのファイルシステムを一緒に使っている。関連ファイルのパスをClaudeに伝え、タスクを解決するよう命令する。Claudeが直接ファイルを読んで分析し、必要な修正や追加をしてくれる。たいていはいくつかのビルドエラーを自分が貼り付ければ再度直してくれる。コードスタイルをそのまま保ちながら新しいコードを書いてくれる点も印象的だ。TypescriptとC#で使ってみたが、自分の経験では成果物は趣味レベルにとどまらない
自分はプログラマーではないが、Pythonやbashコードを必要とする仕事をしている。個人プロジェクトやWebサイトもいくつか運営中だ。Claude Codeのおかげで、以前は能力不足や時間の都合でできなかった小さなプロジェクトを実装できるようになった。今ではemacs環境も自分で改善できるし、lisp関数もすらすら作ってくれる。自分にとってこれは完璧なツールだ。これまで詰まっていたことを次々に解決してくれて、生活が楽になった
Typescript、Go、SQL、Rustで使ってみた。Rustは複雑すぎてエラーだらけだったし、早くプロジェクトを終えたい（ただしプロジェクト自体がかなり難しい）。Goは言語があまりにシンプルなので非常に生産的で、速度が2倍になる。TypescriptはReactコンポーネントやアニメーションに無難。SQL/PostgreSQLも同様だ。ストアドファンクションのボイラープレートが嫌なのだが、LLMがそれを減らしてくれるので手首の痛みが軽くなる
こうしてオプションが増えるのは確かに良いことだが、同時に大量のコンテキストを入れるとLLMの出力品質が落ちる可能性がある。LLMが注意散漫になりやすくなるからだ。ユーザーがこのトレードオフを理解せず、自動モードだけに頼るなら、Claude Codeで書かれたコードの品質が心配だ
参考になる記事リンクをいくつか示す
現時点では長いコンテキストはClaude Codeに統合されていない。「他の製品にも長いコンテキストを適用する方法を検討中」とのことだ。すでにこれを問題として認識し、解決策を考えているはずだと思う。ユーザーが高額プランで追加費用を発生させる前に、ソリューションを出そうとしているように見える
代替として何を勧めるのか気になると質問している。Claude Codeには慣れてきたが、まだベストプラクティスには不慣れだ
Chromaチームがこの問題を研究中で、数値データも出る予定だ
Opusの方が良くないかと尋ねており、トークンが尽きてSonnetへ強制切り替えされると大きな差を感じるという。経験も積み、アイデアは豊富だがコーディングは苦手だった立場から、Claude登場後はアイデア実装もテストもバグ修正も飛ぶように進んでいるそうだ
チャットアプリ（ChatGPT、Claude.ai）の大きな問題は、コンテキストウィンドウ周りの異常動作（突然の切り落とし、要約、「ゴーストスニペット」の再挿入など）だ。ユーザーがコンテキストを維持するか、新しいチャットを始めるかを自分で選べる方が便利そうだが、現実には料金プランと計算資源の制限のためやむを得ない。実際には開発者ツール（Google AI Studio）やAPIをラップしたチャットアプリを使わないと、全コンテキストを完全に送れない。カスタムのチャットアプリを作れば、各メッセージにタイムスタンプを挿入して、「10分ごとにMarkdownテーブルの新しい行へその時間帯の内容を要約せよ」とLLMに指示することもできる
今回の料金プランは、トークン数が増えるほどコストが「二乗」のように跳ね上がる点を初めて認めたケースだと思う。LLM提供者が初めて非線形の料金構造を反映したように見える。この方式は、私たちがすでに知っている推論スケーリング則に似ている
関連トピックの議論も案内している
この機能は素晴らしいが、推論速度を改善する方法が何なのか気になる。個人的には200Kコンテキストで十分なので、応答速度が速くなってほしい。多くの人は、コンテキストサイズが小さくてもエージェントがはるかに速く作業してくれるなら満足すると思う（現在はプロンプトごとに2〜3分待ちだ）