結論から言えば、Claude Opus 4.7の1M token context windowは公式に示されている仕様です。[2] そのため、従来の短いコンテキストのモデルより、長いドキュメントや大きめのコードベース分析には明らかに向いています。
ただし、ここで言う1M tokenは「どんなGitリポジトリでも、中身をそのまま全部プロンプトに貼ればよい」という意味ではありません。正確には、repo本体、タスク指示、会話履歴、ツールの出力、ログ、そしてモデルが回答するための余白まで含めて上限内に収まるなら、一度に分析できる可能性がある、という話です。[2]
まず結論：可能な場合はあるが、無条件ではない
Claude Opus 4.7は、1M token context windowと最大128k output tokensをサポートしています。[2] この数字だけを見ると「repo丸ごと読み込ませられるのでは」と期待したくなります。
しかし、実際には次の3点を満たす必要があります。
- 入力全体が1M tokenに収まること。 ソースコードだけでなく、system prompt、ユーザー指示、会話履歴、検索結果、テストログ、エラーログ、ツール実行結果もコンテキストを消費します。[
2]
- 出力用の余白を残すこと。 Opus 4.7の最大出力は128k tokensです。詳細な監査レポート、大規模なpatch、ファイル別レビュー、移行計画まで求めるなら、入力を限界まで詰め込むのは得策ではありません。[
2]
- Opus 4.7のtokenizerで数え直すこと。 Anthropicは、Opus 4.7の新tokenizerでは同じテキストでも約1x〜1.35xのtokenを使う可能性があり、
/v1/messages/count_tokensの結果もOpus 4.6とは異なると説明しています。[2]
公式情報から確認できること
| 確認したい点 | 公式情報で言えること | 実務上の読み方 |
|---|---|---|
| コンテキストウィンドウの大きさ | Opus 4.7は1M token context windowをサポートしています。[ | 非常に大きな作業セットを扱いやすくなりますが、上限はあります。 |
| 最大出力 | Opus 4.7は最大128k output tokensをサポートしています。[ | 長い報告書や大きなpatchを出させる場合は、入力を詰め込みすぎない設計が必要です。 |
| tokenの数え方 | 新tokenizerにより、同じテキストでも約1x〜1.35xのtokenを使う可能性があります。[ | 旧モデルの見積もりや文字数ベースの感覚だけで判断しない方が安全です。 |
| repo作業への適性 | AnthropicはOpus 4.7をcomplex agentic workflows、long-running work、larger codebases向けに位置づけています。[ | 大きめのコードベース作業に向く、という判断はできます。ただし万能保証ではありません。 |
| 長時間タスクの安定性 | Anthropicの発表では、Opus 4.7はcomplex, long-running tasksをrigor and consistencyをもって扱えるとされています。[ | 公式の評価は前向きですが、本番投入では自分たちのrepoとテストで検証すべきです。 |
なぜ1M contextでも「全repo一発投入」とは限らないのか
コードリポジトリは、きれいな長文ドキュメントとは違います。実際に意味のある分析をさせるには、ソースコードだけでなく、README、設定ファイル、テスト、依存関係、CIの失敗ログ、stack trace、検索結果なども必要になることが多いからです。
さらに、大きなrepoにはしばしば次のようなノイズが含まれます。
- build artifacts
- generated files
- vendorディレクトリや外部依存のコピー
- 巨大なログファイル
- キャッシュ
- 重複したドキュメント
- minifiedされたファイル
これらをすべて入れると、1M tokenの枠を無駄に使い、肝心のアプリケーションコードや設計情報、出力余地を圧迫します。特にOpus 4.7では、新tokenizerにより同じ入力でも前世代よりtoken数が増える場合があるため、見積もりには注意が必要です。[2]
「安定して処理できる」はどこまで信じてよいか
AnthropicはOpus 4.7を、complex agentic workflowsやlong-running work、larger codebasesに適したモデルとして紹介しています。[6] また、公式発表でも、複雑で長く続くタスクをrigor and consistencyをもって処理できると説明しています。[
8]
ただし、これらの情報から言えるのは、あくまで「Opus 4.7は長いコンテキスト、長いワークフロー、大きめのコードベースに向くよう設計・位置づけられている」ということです。任意の巨大monorepo、任意の超長文、任意のagent loopを、常に一度で安定して完了できるとまでは言えません。
セキュリティ監査、CI/CDの自動修復、大規模リファクタリング、長時間動くagentワークフローのような本番用途では、自分たちのrepo、テストスイート、実際の失敗ケースで検証するのが現実的です。[6][
8]
実務でrepoを読ませるなら、こう進める
1. いきなり全部貼らず、まずファイル構成を把握する
最初に、主要ディレクトリ、使用言語、エントリーポイント、テスト、設定ファイル、最近変更された箇所を一覧化します。そのうえで、分析に本当に必要なファイルを選びます。
build artifacts、generated files、vendor依存、巨大ログ、キャッシュ、重複ファイルは、原則として最初から除外した方がよいでしょう。
2. Opus 4.7用にtoken countを取り直す
Opus 4.6や他モデルのtoken数をそのまま流用しない方が安全です。Anthropicは、Opus 4.7の新tokenizerでは同じテキストでも約1x〜1.35xのtokenを使う可能性があり、/v1/messages/count_tokensの結果もOpus 4.6とは異なると説明しています。[2]
3. 1Mの枠を使い切らない
入力がぎりぎり1M tokenに収まるとしても、それで良い分析になるとは限りません。repo分析では、モデルにリスク一覧、設計上の論点、修正案、テスト方針、patchなどを出力させることが多くなります。
Opus 4.7の最大出力は128k tokensです。[2] 長い出力を期待するなら、入力側には余白を持たせるべきです。
4. 大規模repoでは段階的に読む
大型repoでは、最初に全体構造を把握し、次に重要ファイルを読み、参照関係を検索し、テストやエラーログを確認する、という段階的な進め方の方が安定しやすくなります。
AnthropicはOpus 4.7をcomplex agentic workflowsやlarger codebases向けに位置づけています。[6] その強みを生かすなら、「全部を一度に詰め込む」より、「必要な情報をツールで取りに行きながら分析する」設計の方が自然です。
5. モデルに「何を読んだか」を明記させる
repo分析を頼むときは、回答に次の項目を含めるよう指示するとよいでしょう。
- 読んだファイル
- 読んでいないファイル
- 主要な仮定
- 見落とし得るリスク
- 人間が確認すべき点
- 次に実行すべきテスト
これで正確性が保証されるわけではありません。しかし、「一部の文脈を見た」ことを「コードベース全体を完全に理解した」と誤解するリスクは下げられます。
最終判断
Claude Opus 4.7は、公式に1M token context windowと最大128k output tokensをサポートしています。[2] Anthropicも、長いワークフロー、agentic workflow、大きめのcodebaseに向くモデルとしてOpus 4.7を位置づけています。[
6][
8]
したがって、小〜中規模のrepoで、不要ファイルを除外し、指示文や出力余地を含めても上限内に収まるなら、一度の分析でかなり広い範囲を扱える可能性があります。
一方で、大型monorepo、generated filesやvendor依存を多く含むrepo、長大なログやドキュメントを抱えるrepoでは、1M tokenでも足りない、または足りても効率が悪い場合があります。その場合は、token countを取り直し、ファイルを選別し、段階的なツールフローで読ませるのが堅実です。
