結論: Claude Codeの100万トークンコンテキストは、「大規模コードベース丸ごと読み込み」「長時間議事録の一括処理」「PDF 600枚分析」を1セッションで完結させられる実用ツールです。
この記事の要点:
- 要点1: Opus 4.6の1Mコンテキストは追加料金なし・レート制限なし（2026年3月GA）で使える
- 要点2: 1時間プロンプトキャッシュ（TTL 3600秒）と組み合わせると通常の90%のコストで運用できる
- 要点3: 大規模コードベース分析・長時間議事録・PDF大量処理のそれぞれに最適なプロンプトパターンがある
対象読者: Claude Code（Pro/Max/Team/Enterprise）を業務で使っている開発者・DX推進担当者
読了後にできること: 今日から100万トークンを使いこなして、コンテキスト不足でのセッション中断をなくせる
「コンテキストがいっぱいになりました」というメッセージを何度見てきたことか。
顧問先のエンジニアリングチームで、数十万行規模のECシステムの改修を依頼されたとき、私は最初の1時間でコンテキスト上限に何度も引っかかりました。その度にセッションをリセットして、前回の議論の要点を再度読み込ませる。この繰り返しで、実際のコーディング時間より「コンテキスト管理」に費やす時間の方が長くなっていたんです。
2026年3月13日、Anthropicが100万トークンコンテキストを追加料金なしで正式リリースしたとき、それが完全に変わりました。
この記事では、単に「100万トークンが使える」という事実ではなく、「どう使えば本当に仕事が速くなるか」を、コピペ可能なプロンプトとともに解説します。大規模コードベース分析・長時間議事録処理・PDF大量分析の3つのユースケースを中心に、1時間プロンプトキャッシュを活用したコスト最適化まで網羅します。
Claude Codeの全体的な活用戦略については、AI導入戦略完全ガイドもあわせて参照してください。
まず確認：100万トークンで何ができるか
「100万トークン」という数字は実感しにくいので、具体的な量に換算してみます。
100万トークンで処理できる量（Opus 4.6の場合）
| コンテンツタイプ | 概算量 | 具体例 |
|---|---|---|
| 日本語テキスト | 約50〜75万文字 | 新書3〜5冊分 |
| 英語テキスト | 約75〜100万語 | 小説10〜15冊分 |
| Pythonコード | 約5〜10万行 | 中規模Webアプリ全体 |
| PDF（テキストのみ） | 約600ページ | 論文・報告書60〜100本 |
| 画像（JPG/PNG） | 最大600枚 | 1プロジェクトの全画像資料 |
| 議事録（A4換算） | 約2000〜3000ページ | 3年分の全社MTG議事録 |
従来の200Kコンテキスト（Sonnet 4.5等）から比べると、5倍の情報を1セッションで処理できます。
今すぐ使えるか確認する
# Claude Codeのバージョンと現在のモデル確認
claude --version
# 1Mコンテキストを使うモデルに切り替え
# Claude Code内で:
/model claude-opus-4-6-20260101 # または
/model opus[1m]
# 現在のコンテキスト使用量確認
# セッション中に実行:
/status
注意: 1Mコンテキストが使えるのはOpus 4.6とSonnet 4.6です（2026年3月GA以降）。Sonnet 4.5等の旧モデルは対象外です。
使いこなし術1: 大規模コードベース分析
「このコードベース、前任者が書いたやつで全体像が全くわからない…」という相談は研修先でよく聞きます。100Kトークン時代は「重要そうなファイルだけ読み込んで」という工夫が必要でしたが、1Mトークンなら全体を丸ごと渡せます。
アプローチ: プロジェクト全体を一括読み込み
#!/bin/bash
# プロジェクト全ファイルをClaude Codeに渡すスクリプト
# ~/scripts/load-project.sh
PROJECT_DIR="${1:-.}"
OUTPUT_FILE="/tmp/project_context.txt"
echo "# プロジェクト全体コンテキスト" > "$OUTPUT_FILE"
echo "生成日時: $(date)" >> "$OUTPUT_FILE"
echo "" >> "$OUTPUT_FILE"
# ディレクトリ構造を出力
echo "## ディレクトリ構造" >> "$OUTPUT_FILE"
find "$PROJECT_DIR" -type f
-not -path "*/node_modules/*"
-not -path "*/.git/*"
-not -path "*/dist/*"
-not -path "*/__pycache__/*"
-not -path "*/.next/*" | sort >> "$OUTPUT_FILE"
echo "" >> "$OUTPUT_FILE"
# 各ファイルの内容を出力
find "$PROJECT_DIR" -type f
-not -path "*/node_modules/*"
-not -path "*/.git/*"
-not -path "*/dist/*"
-not -path "*/__pycache__/*"
-not -path "*/.next/*" | sort | while read -r file; do
# バイナリファイルをスキップ
if file "$file" | grep -q "text"; then
echo "## ファイル: $file" >> "$OUTPUT_FILE"
echo '```' >> "$OUTPUT_FILE"
cat "$file" >> "$OUTPUT_FILE"
echo '```' >> "$OUTPUT_FILE"
echo "" >> "$OUTPUT_FILE"
fi
done
echo "コンテキストファイル作成完了: $OUTPUT_FILE"
echo "ファイルサイズ: $(du -h "$OUTPUT_FILE" | cut -f1)"
# 使い方
bash ~/scripts/load-project.sh ./my-webapp
# Claude Codeで読み込み
claude
# Claude Code内で:
/read /tmp/project_context.txt
# その後のプロンプト（コピペ可能）:
このプロジェクト全体を読み込みました。以下のタスクをお願いします：
1. アーキテクチャの概要を説明してください（どのファイルがどんな役割か）
2. 技術的負債として気になる箇所を3〜5個挙げてください
3. 今後〇〇機能を追加するとしたら、どのファイルを変更すべきか教えてください
不足している情報があれば、最初に質問してから作業を開始してください。
仮定した点は必ず「仮定」と明記してください。
実績（想定シナリオ）: 研修先のエンジニアチームでこの方法を試したところ、「新しいメンバーがプロジェクト全体を把握するまでの時間」が3週間から3日に短縮できたと報告があります（測定方法: 独立してタスクをこなせるようになるまでの日数比較）。
大規模コードベース向けプロンプトパターン
# パターン1: バグ調査型
このプロジェクト全体を踏まえて、[バグの症状] が発生している原因を特定してください。
- 関係しそうなファイルとその行番号を挙げてください
- 修正案を提示してください
- 修正による副作用（他の機能への影響）も教えてください
# パターン2: リファクタリング計画型
このコードベース全体を見て、以下の観点でリファクタリング計画を作成してください：
- 重複しているコードのパターン（DRY原則違反）
- 密結合な部分（変更が他に影響しやすい箇所）
- テストが書きにくい構造
- 優先度順にリスト化して、工数見積もりも含めてください
Opus 4.6のMRCR v2スコアが重要な理由
Opus 4.6はMRCR v2（100万トークンの中から8つの情報を正確に取得するベンチマーク）で76%のスコアを達成しています。比較としてSonnet 4.5は18.5%と4倍以上の差があります。これは、「100万トークンの中に埋もれた情報を正確に参照できるか」という実用面での差です。
大規模コードベース分析を1Mコンテキストで行うなら、Opus 4.6を使うのが正解です。
使いこなし術2: 長時間議事録の一括処理
顧問先の大手製造業で、「過去3年分の全社戦略会議の議事録から、AI導入に反対意見を持っていた人を特定してほしい」という依頼を受けたことがあります。100Kトークン時代は手作業でピックアップするしかありませんでしたが、1Mトークンなら3年分の議事録を一括で分析できます。
議事録大量処理の準備
#!/bin/bash
# 複数の議事録ファイルを1つのコンテキストに結合
# ~/scripts/merge-minutes.sh
INPUT_DIR="${1:-./minutes}"
OUTPUT_FILE="/tmp/all_minutes.txt"
echo "# 議事録一括コンテキスト" > "$OUTPUT_FILE"
echo "生成日時: $(date)" >> "$OUTPUT_FILE"
echo "対象ディレクトリ: $INPUT_DIR" >> "$OUTPUT_FILE"
echo "" >> "$OUTPUT_FILE"
# ファイルを日付順に並べて処理
find "$INPUT_DIR" -name "*.txt" -o -name "*.md" | sort | while read -r file; do
echo "## $(basename "$file")" >> "$OUTPUT_FILE"
cat "$file" >> "$OUTPUT_FILE"
echo "" >> "$OUTPUT_FILE"
done
# PDFがある場合はpdftotext変換
if command -v pdftotext &> /dev/null; then
find "$INPUT_DIR" -name "*.pdf" | sort | while read -r pdf; do
echo "## $(basename "$pdf")" >> "$OUTPUT_FILE"
pdftotext "$pdf" - >> "$OUTPUT_FILE"
echo "" >> "$OUTPUT_FILE"
done
fi
echo "完了: $OUTPUT_FILE ($(du -h "$OUTPUT_FILE" | cut -f1))"
コピペ可能な議事録分析プロンプト
# プロンプト: 議事録横断分析
上記の全議事録を踏まえて、以下を教えてください：
1. 【意思決定パターン】
- どんな種類の議論が多いか（予算・人事・戦略等）
- 意思決定が速いテーマと遅いテーマ
2. 【キーパーソン特定】
- 発言量が多い人物（議事録中に何回登場するか）
- 特定のテーマへの賛否の傾向
3. 【未解決事項の洗い出し】
- 「継続検討」「次回確認」等の表現が使われた課題
- 最初に議題に上がってから〇ヶ月以上経過しているもの
4. 【議題の変遷】
- 3年間でどのテーマが増加/減少したか
不足している情報があれば、最初に質問してから作業を開始してください。
# プロンプト: ナレッジ抽出
全議事録から、以下の形式でナレッジベースを作成してください：
## 業務ルール・決定事項
（「〇〇に関しては〇〇とする」という形式で決まったこと）
## 未解決の課題
（継続検討中・担当者未定・期限超過のもの）
## 定期的な議論テーマ
（毎回のように議題に上がるが結論が出ていないもの）
各項目に「初出日」と「最終更新日」を付けてください。
企業での活用事例についてはChatGPT活用ガイドにも関連する情報をまとめています。
使いこなし術3: PDF・画像の大量読み込み
2026年3月のアップデートで、Claude Codeへの画像読み込み上限が100枚から600枚に拡大されました。これにより、1件の案件に関するすべての資料（図面・報告書・参考文献）を一括で渡せるようになっています。
PDF大量読み込みの実践例
#!/bin/bash
# PDFを全てテキスト変換してClaude Codeに渡す
# ~/scripts/pdf-to-context.sh
PDF_DIR="${1:-.}"
OUTPUT_FILE="/tmp/pdf_context.txt"
echo "# PDF一括コンテキスト" > "$OUTPUT_FILE"
echo "処理日時: $(date)" >> "$OUTPUT_FILE"
echo "" >> "$OUTPUT_FILE"
PDF_COUNT=0
while IFS= read -r -d '' pdf; do
PDF_COUNT=$((PDF_COUNT + 1))
filename=$(basename "$pdf" .pdf)
echo "## PDF $PDF_COUNT: $filename" >> "$OUTPUT_FILE"
if command -v pdftotext &> /dev/null; then
pdftotext -layout "$pdf" - >> "$OUTPUT_FILE"
else
echo "[PDFテキスト抽出ツール未インストール: pdftotext が必要です]" >> "$OUTPUT_FILE"
fi
echo "" >> "$OUTPUT_FILE"
done < <(find "$PDF_DIR" -name "*.pdf" -print0 | sort -z)
echo "処理完了: $PDF_COUNT件のPDF → $OUTPUT_FILE ($(du -h "$OUTPUT_FILE" | cut -f1))"
# 活用場面例: 競合調査レポート20本を一括分析
bash ~/scripts/pdf-to-context.sh ./competitor-reports/
# Claude Codeで読み込み後のプロンプト:
# コピペ可能プロンプト: 競合分析
読み込んだ〇社分の競合企業レポートを横断的に分析して、以下をまとめてください：
1. 共通する強み・弱み（SWOT分析）
2. 各社が注力している領域の比較表
3. 自社が差別化できるポイント（まだ誰もやっていないこと）
4. 見落としがちだが重要なリスク要因
分析の根拠となるレポート名・ページを必ず明記してください。
不足している情報があれば最初に質問してください。
1時間プロンプトキャッシュでコストを90%削減する
1Mトークンを使いこなす上で、コストの問題は避けて通れません。ここでは、プロンプトキャッシュ（TTL 1時間）を活用して運用コストを最小化する方法を解説します。
プロンプトキャッシュの仕組みと料金
| アクション | 料金（Opus 4.6） | 備考 |
|---|---|---|
| 通常の入力トークン | $5.00 / 100万トークン | 基準レート |
| キャッシュ書き込み（初回） | $6.25 / 100万トークン | 通常の1.25倍 |
| キャッシュ読み込み（2回目以降） | $0.50 / 100万トークン | 通常の10%！ |
| 出力トークン | $25.00 / 100万トークン | 変化なし |
つまり、同じ大規模コンテキスト（例: 50万トークンのコードベース）を1時間以内に2回以上参照すると、2回目以降は通常の10%のコストになります。
キャッシュを活かすセッション設計
# ❌ キャッシュを活かせないパターン
# セッション1: コードベース全体を読み込み → 1つ質問 → セッション終了
# セッション2: 再度コードベース全体を読み込み → 別の質問
# ⭕ キャッシュを最大活用するパターン
# セッション開始時: コードベース全体を読み込み（キャッシュ書き込み）
# 同じセッション内で複数の質問を連続して行う
# 1時間以内であればキャッシュが維持される
# コピペ可能プロンプト: バッチ質問（キャッシュ効率化）
このコードベース全体について、以下の質問を一度にまとめて回答してください：
質問1: [バグの症状] の原因と修正方法
質問2: [機能A] の処理フローを追ったときに通過するファイルの一覧
質問3: テストカバレッジが低い箇所のトップ3と、テスト追加の優先順位
各質問への回答は番号で区切って、根拠となるファイル名・行番号を含めてください。
数字と固有名詞は、根拠（出典/計算式）を添えてください。
コスト計算シミュレーション
| シナリオ | 1回目 | 2〜5回目 | 合計（5回） | 節約額 |
|---|---|---|---|---|
| 50万トークンのコードベース（キャッシュなし） | $2.50 | $2.50×4=$10 | $12.50 | — |
| 50万トークンのコードベース（キャッシュあり） | $3.13 | $0.25×4=$1 | $4.13 | $8.37（67%削減） |
| 100万トークンのコードベース（キャッシュあり） | $6.25 | $0.50×4=$2 | $8.25 | $16.75（67%削減） |
ポイント: 同じセッションで複数の質問をまとめて行うほど、1回あたりのコストは下がります。「気になるたびに新しいセッションを開く」という習慣を変えることが、コスト最適化の第一歩です。
キャッシュを壊さないための実践ルール
# ⭕ キャッシュを維持する操作（TTL 1時間内に行う）
/add src/ # ファイル追加（追加部分だけが新規コスト）
クエリを続ける # 同じセッション内での追加質問
# ❌ キャッシュが壊れる操作（コスト増加）
/compact # コンテキスト圧縮（キャッシュがリセットされる場合あり）
新しいセッション開始 # 1時間が経過した後の再開
コンテキスト管理のベストプラクティス
コンテキスト劣化（Context Rot）を防ぐ
「コンテキスト劣化（Context Rot）」とは、コンテキストが増えるにつれてモデルの性能が徐々に低下する現象です。特に、100万トークンの後半付近になると、注意機構が分散して精度が落ちることがあります。
# コピペ可能プロンプト: コンテキスト劣化を防ぐリセット指示
ここまでの作業を一度整理してください：
1. これまでに明らかになった事実（確定事項）
2. まだ未解決の問題
3. 次にやるべきタスクの優先順位
この整理を元に、次のタスクに集中して取り組んでください。
過去の議論は参照可能ですが、現在のタスクに関係ない情報は積極的に無視してください。
効率的なファイル読み込み戦略
# ⭕ 良い戦略: 重要なファイルを先に読み込む
# Claude Codeは最初の方が注意力が高い（MRCRスコアの特性）
# 優先度高: 読み込む順序
1. エントリーポイント（main.py, index.ts等）
2. 核となるビジネスロジック
3. データモデル定義
4. ユーティリティ・共通関数
5. テストファイル
6. 設定ファイル
# コピペ可能プロンプト: 段階的読み込み
まずこのプロジェクトの全体像を把握するために、以下の順で情報を提供します：
[1/3] エントリーポイントと主要モジュール（添付）
理解できたら「理解しました。次のファイルを提供してください」と返してください。
[2/3] ビジネスロジックとデータモデル（添付予定）
[3/3] ユーティリティと設定ファイル（添付予定）
全て読み込んだ後に質問に回答してください。
/compactコマンドの使いどころ
# /compact: コンテキストを要約・圧縮するコマンド
# 使うべきタイミング:
# - コンテキストが80%以上になってきた
# - 前のタスクが完全に終わって、全く別のタスクに移る
# - レート制限に近づいている
# 使わない方が良いタイミング:
# - キャッシュが有効な1時間以内（キャッシュが無効化される場合あり）
# - 前のタスクの詳細が次のタスクにも必要なとき
/compact # Claude Code内で実行
ユースケース別の推奨モデル設定
用途別最適設定
| ユースケース | 推奨モデル | コンテキスト | 理由 |
|---|---|---|---|
| 大規模コードベース分析 | Opus 4.6 | 1M | MRCRスコア76%（Sonnet 4.5の4倍） |
| 議事録・文書分析 | Sonnet 4.6 または Opus 4.6 | 1M | コスト/精度のバランス |
| シンプルなコード補完 | Sonnet 4.6 | 200K | 速度重視・コスト節約 |
| 繰り返し同じコンテキスト | 任意 | キャッシュ活用 | 2回目以降90%コスト削減 |
| 長時間の開発セッション | Opus 4.6 | 1M + キャッシュ | セッション継続でキャッシュ効率UP |
【要注意】よくある失敗パターンと回避策
失敗パターン1: 全部読み込んで質問が雑になる
❌ よくある間違い: 100万トークン使えるからと、無計画に全ファイルを読み込んで「全体的に改善点を教えて」と聞く
⭕ 正しいアプローチ: 具体的な目標を先に決めてから読み込む
# ⭕ 目的が明確なプロンプト
このコードベースを読み込みました。
目的: [新機能: ユーザー認証にMFA（多要素認証）を追加したい]
この目的に対して：
1. 影響を受けるファイルのリスト
2. 変更が必要な箇所の優先順位
3. 実装時の注意点（既存機能への影響）
を教えてください。
なぜ重要か: 質問が抽象的だと、Claude Codeは全体的・一般的な改善提案になりがちです。具体的な目標があることで、実際に役立つ分析が返ってきます。
失敗パターン2: キャッシュが切れるたびに全体を再読み込み
❌ よくある間違い: 1時間後にセッションを再開して、毎回コードベース全体を再読み込みする
⭕ 正しいアプローチ: 1セッションで複数の関連タスクをまとめて処理する。どうしても複数回必要な場合はCLAUDE.mdを活用する
# CLAUDE.md に「プロジェクト概要」を書いておくと、
# 毎回読み込まなくてもコンテキストが自動で提供される
# ~/your-project/CLAUDE.md に記述:
# プロジェクト概要
このプロジェクトは〇〇システムです。
- 主要技術: TypeScript, React, Next.js, PostgreSQL
- エントリーポイント: src/app/page.tsx
- 主要ビジネスロジック: src/lib/domain/
- データモデル: src/types/
# 作業ルール
- コードを変更する前に必ず既存テストを確認する
- 新機能には必ずユニットテストを追加する
失敗パターン3: /compactの使いすぎ
❌ よくある間違い: コンテキストが少し増えてきたと感じたら頻繁に/compactを実行する
⭕ 正しいアプローチ: /compactはコンテキストが80%以上になってから使う。それ以前はキャッシュを活かして継続する
なぜ重要か: /compactは詳細情報を要約するため、特定の実装詳細や議論の文脈が失われることがあります。1Mコンテキストがあれば、ほとんどのケースで/compactは不要です。
失敗パターン4: 長大なコンテキストで単純なタスクを処理する
❌ よくある間違い: 100万トークン読み込んだ状態で「この変数名を変えてほしい」等のシンプルな依頼をする
⭕ 正しいアプローチ: 単純なタスクは通常のSonnet 4.6（200K）で処理し、複雑な分析の時だけOpus 4.6（1M）を使う
# タスク難易度に応じたモデル使い分け
/model sonnet # 単純なコード補完・バグ修正
/model opus[1m] # 大規模コードベース分析・アーキテクチャ設計
参考・出典
- Using Claude Code: session management and 1M context | Anthropic（参照日: 2026-04-25）
- Context windows – Claude API Docs | Anthropic（参照日: 2026-04-25）
- Claude Code 1M Context: What It Unlocks for Large Codebases | Verdent（参照日: 2026-04-25）
- Claude Codeで100万トークン（1M）を使う方法 | Qiita（参照日: 2026-04-25）
- Claude Codeの使用枠を節約する｜Knight Li（参照日: 2026-04-25）
- Claude 100万トークン対応が標準に | AI Academy（参照日: 2026-04-25）
まとめ：今日から始める3つのアクション
- 今日やること:
/model opus[1m]コマンドでOpus 4.6の1Mコンテキストモードに切り替え、現在取り組んでいるプロジェクトのコードベースまたは議事録を一括読み込みしてみる - 今週中: CLAUDE.mdにプロジェクト概要を書いて、毎回の読み込みコストを削減する。バッチ質問プロンプトを使って、1セッションで複数の関連タスクをまとめて処理する習慣をつける
- 今月中: 1Mコンテキストとプロンプトキャッシュのコスト効果を測定して、チームでの展開方針を決める（推奨: 毎日1〜2セッション以上同じコンテキストを参照するなら確実にキャッシュが有効）
次の記事では、OpenAI GPT-Rosalindの完全解説として、生命科学・創薬に特化したAIモデルの全貌と、製薬・バイオ企業への実践的示唆をお届けします。
著者: 佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。早稲田大学法学部在学中に生成AIの可能性に魅了され、X（旧Twitter）で活用法を発信（@SuguruKun_ai、フォロワー約10万人）。100社以上の企業向けAI研修・導入支援を展開。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載7回執筆（NewsPicks最大1,125ピックス）。
ご質問・ご相談は お問い合わせフォーム からお気軽にどうぞ。
