LLMのコンテキストウィンドウとは？トークン数・RAG・長文処理の仕組みを完全解説
オープンソースラボ編集部 ・ 2026年6月13日
LLMのコンテキストウィンドウとは？トークン数・RAG・長文処理の仕組みを完全解説
GPT-4o（128K tokens）・Claude 3.7 Sonnet（200K tokens）・Gemini 2.0 Flash（1M tokens）など、最新のLLMは数十万〜数百万トークンのコンテキストウィンドウを持ちます。この「コンテキストウィンドウ」が何で、なぜ重要で、どう活用するかを解説します。
コンテキストウィンドウとは何か
コンテキストウィンドウ（Context Window） とは、LLMが1回の推論で参照できる最大のテキスト量です。入力（プロンプト）と出力（生成テキスト）の合計がこの上限に収まる必要があります。
コンテキストウィンドウ = 入力トークン（プロンプト + 過去の会話） + 出力トークン（生成テキスト）
トークンとは何か
テキストをLLMが処理する最小単位が「トークン」です。英語の場合、1単語が約1.3〜1.5トークン。日本語は1文字が約0.5〜3トークン（ひらがな・カタカナは約2トークン/文字、漢字は約1〜2トークン/文字）。
# トークン数を計算する（tiktoken - OpenAI公式ライブラリ）
# pip install tiktoken
import tiktoken
def count_tokens(text: str, model: str = "gpt-4o") -> int:
enc = tiktoken.encoding_for_model(model)
return len(enc.encode(text))
# 日本語テキストのトークン数を確認
texts = [
"Hello, world!", # 英語
"こんにちは、世界！", # 日本語
"OpenAI GPT-4o has 128K tokens", # 混合
]
for text in texts:
tokens = count_tokens(text)
print(f"{repr(text)[:30]:35s} → {tokens:4d} tokens")
# 出力例:
# 'Hello, world!' → 4 tokens
# 'こんにちは、世界！' → 9 tokens
# 'OpenAI GPT-4o has 128K tokens' → 8 tokens
# Anthropic Claude のトークンカウント（公式SDK）
import anthropic
client = anthropic.Anthropic()
# トークン数の事前確認（APIコール前にコスト見積もり）
response = client.messages.count_tokens(
model="claude-sonnet-4-6",
system="あなたはOSSの専門家です。",
messages=[
{
"role": "user",
"content": "KubernetesとDockerの違いを500字で説明してください。",
}
],
)
print(f"入力トークン数: {response.input_tokens}")
# 入力トークン数: 35 (例)
主要LLMのコンテキストウィンドウ比較
| モデル | コンテキスト | 入力コスト | 出力コスト |
|---|---|---|---|
| GPT-4o | 128K tokens | $2.50/1Mtok | $10.00/1Mtok |
| Claude 3.7 Sonnet | 200K tokens | $3.00/1Mtok | $15.00/1Mtok |
| Claude Haiku 4.5 | 200K tokens | $0.80/1Mtok | $4.00/1Mtok |
| Gemini 2.0 Flash | 1M tokens | $0.10/1Mtok | $0.40/1Mtok |
| Llama 3.1 70B | 128K tokens | $0.59/1Mtok（Groq） | $0.79/1Mtok |
| Mistral Large | 128K tokens | $2.00/1Mtok | $6.00/1Mtok |
128Kトークンは約8万〜10万文字の日本語テキストに相当します。A4用紙に換算すると約300〜400ページ分です。
コンテキストウィンドウの使い方と制限
Long Context vs RAG の使い分け
コンテキストウィンドウが大きくなった今、全文書をコンテキストに入れる（Long Context） か RAGで関連部分だけ注入する かという選択が重要になっています。
# Long Context アプローチ（小〜中規模文書）
# 100ページのPDFをそのまま渡す
import anthropic
from pathlib import Path
client = anthropic.Anthropic()
def analyze_document_long_context(pdf_text: str, question: str) -> str:
# 文書全体をコンテキストに入れる
token_count = len(pdf_text) // 3 # 概算
print(f"文書サイズ: 約{token_count:,}トークン")
response = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=2000,
messages=[
{
"role": "user",
"content": f"以下の文書を読んで質問に答えてください。
{pdf_text}
質問: {question}",
}
],
)
return response.content[0].text
# RAG アプローチ（大規模文書・コスト最適化）
from qdrant_client import QdrantClient
from openai import OpenAI
qdrant = QdrantClient(host="localhost", port=6333)
openai = OpenAI()
def analyze_document_rag(question: str, collection: str = "docs") -> str:
# 質問に関連する部分だけを検索して取得
query_vector = openai.embeddings.create(
model="text-embedding-3-small",
input=question,
).data[0].embedding
results = qdrant.search(
collection_name=collection,
query_vector=query_vector,
limit=5, # 関連上位5チャンク
)
context = "
---
".join([r.payload["text"] for r in results])
# コンテキストは5チャンク分だけ（コスト大幅削減）
response = openai.chat.completions.create(
model="gpt-4o-mini",
messages=[
{"role": "system", "content": "以下のコンテキストを元に質問に答えてください。"},
{"role": "user", "content": f"コンテキスト:
{context}
質問: {question}"},
],
)
return response.choices[0].message.content
# コンテキストウィンドウのコストを最適化する
# プロンプトキャッシュ（Anthropic Claude）
client = anthropic.Anthropic()
# キャッシュプレフィックスを設定（system promptなど繰り返し使う部分）
LARGE_SYSTEM_DOCUMENT = open("company-docs.txt").read() # 50,000トークン
def query_with_cache(question: str):
response = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=1000,
system=[
{
"type": "text",
"text": LARGE_SYSTEM_DOCUMENT,
"cache_control": {"type": "ephemeral"}, # キャッシュを有効化
}
],
messages=[{"role": "user", "content": question}],
)
# 2回目以降はcached_input_tokensとしてカウント（90%割引）
usage = response.usage
print(f"入力: {usage.input_tokens} / キャッシュ: {getattr(usage, 'cache_read_input_tokens', 0)}")
return response.content[0].text
# 1回目: キャッシュ作成コスト（通常の25%増）
result1 = query_with_cache("OSSツールの活用シーンを教えて")
# 2回目以降: キャッシュヒット（入力コスト90%削減）
result2 = query_with_cache("セキュリティ対策の方法は？")
コンテキストウィンドウとRAGの組み合わせ
LLMツールカテゴリ/categories/llm-toolsのRAGフレームワーク（LangChain・LlamaIndex）では、長いコンテキストと短いRAGコンテキストを使い分けるハイブリッド手法が主流です。DevOpsカテゴリ/categories/devopsのQdrant・ChromaDBにドキュメントを保存してRAGパイプラインを構築し、必要な時だけコンテキストに注入することでコストを最適化します。
FAQ
Q. コンテキストウィンドウが大きいほど良いのですか？
A. 必ずしもそうではありません。大きいウィンドウの利点: 長い文書を丸ごと渡せる・会話の長期記憶・複数ファイルを同時参照。大きいウィンドウの課題: ①コスト増加: 200Kトークン入力はGPT-4oで約$0.50/リクエスト②「Lost in the Middle」問題: コンテキストの中間部分のテキストを参照する精度が低下することが研究で示されている（先頭と末尾は参照されやすい）③レイテンシー: トークン数が多いほど回答生成が遅くなる。実用的な指針: 〜50Kトークンの文書はLong Context直接注入。50K〜500Kトークンの文書はRAGで関連部分のみ注入。500K+はRAG+サマリー階層化が必要。
Q. 日本語は英語に比べてトークン数が多くなるのはなぜですか？
A. LLMのトークナイザー（GPT系はBPE: Byte Pair Encoding）は英語テキストで事前学習されているため、英語の単語や形態素は1〜2トークンで表現できます。日本語はUnicodeの多バイト文字をBPEで分割するため、1文字が1〜4トークンに分割されることがあります。影響: 同じ内容を日本語で書くと英語の1.5〜3倍のトークンを消費します。対策: Cl100kや最新のトークナイザーは日本語効率が改善されています。Claude系はSentencePieceベースで日本語トークン効率がGPT系より高い傾向があります。コスト見積もりは常に実際のtiktoken/count_tokensで確認することを推奨します。
Q. コンテキストウィンドウに入れる情報の順番は重要ですか？
A. 重要です。「Lost in the Middle」研究（スタンフォード、2023年）によると、LLMはコンテキストの先頭と末尾の情報を最もよく参照し、中間は参照精度が低下します。実践的な指針: ①最も重要な指示・ルール → プロンプトの先頭②関連ドキュメント → 中間（RAGで取得したテキスト）③ユーザーの質問 → 末尾（最直前の情報として認識させる）。RAGのチャンクはスコアが高い順に並べて先頭に入れることで参照精度が向上します。
Q. Gemini 2.0 Flashの1Mトークンと他モデルの128Kを比べてどちらが実用的ですか？
A. 用途によります。1Mトークン（Gemini 2.0 Flash）が有利な場面: コードベース全体を読ませる（10万行のプロジェクト）・長編動画のトランスクリプト（数時間分）・大規模なPDF論文セット・マルチモーダルで大量の画像+テキストを同時処理。128K（GPT-4o・Claude Sonnet）が有利な場面: 精度重視の推論タスク・コード生成・複雑な多段階推論。コスト比較: 1Mトークン入力でGemini Flash=$0.10、GPT-4o=$2.50（25倍差）。大規模文書分析ではGemini Flashが圧倒的にコスト効率が高いです。
まとめ
| 文書サイズ | 推奨アプローチ |
|---|---|
| 〜50Kトークン | Long Context直接注入 |
| 50K〜500Kトークン | RAG（Qdrant/Chroma） |
| 500K+・大規模コードベース | Gemini 2.0 Flash（1Mウィンドウ） |
| コスト最適化 | Claudeのプロンプトキャッシュ |