ContextとLLMの精度を考察

現代のAI開発において、LLM（大規模言語モデル）を使いこなす鍵は「Context（コンテキスト）」にあります。けれど、単に多くの情報を流し込めば精度が上がるわけではない、というのを最近あらためて実感しました。

この記事では、開発現場での私の体験を交えながら、Contextの本質と、最新モデルたちの意外な落とし穴について書きます。

1. Contextとは何か

AIとの会話において、Contextとは一言で言えば 「共通認識の箱」 です。

• 背景と基礎情報: 人間とLLMのやり取りの積み重ねによって形成される「文脈」
• 設計図の要約: 読み込ませた設計書や、特定の要望を要約したインデックス情報
• ソースコードの知識化: 既存コードを読み込ませることで、LLMが一時的に得た「そのプロジェクト特有の知識」

これらが組み合わさり、LLMは「今、何をすべきか」を判断するための土台を構築します。

2. Contextがもたらすメリット

Contextを適切に構築できると、LLMとのやり取りは劇的にスムーズになります。

• 阿吽（あうん）の呼吸: こちらが「あ」と言えば、LLMが背景を察して「うん」と返してくる、ハイコンテキストな対話が成立する
• 精度の向上: 当該要件に特化した、ブレの少ない解答や成果物が得られる
• 具体的な活用例:
  • requirement.md（要件）や define-schema.md（DB定義）を読み込ませ、前提条件を固める
  • style.md でCSSのコーディング規約を定義し、デザインの一貫性を保つ
  • これらを「永続化」して、常に同じ前提でAIを起動させる手法も一般化しつつある

3. Contextがもたらす「弊害」と人間のメモリ

ここで重要な落とし穴があります。LLMにContextを100与えたからといって、その100すべてが均等に評価されるわけではありません。

「中だるみ」の法則

私の経験上、LLMが成果物に色濃く反映させるのは以下の部分に集中します。

1. 最初の0〜20%
2. 最後の90〜100%

これは人間に例えると分かりやすいと思います。「やってほしいことを100個いっぺんに渡されても、すべてを完璧にこなすのは無理」という、脳のメモリ不足と同じ現象がAIの中でも起きているのです。

つまり、「とりあえずドキュメントを全部食わせればいい」というのは間違い。人間への指示と同じく、要点を絞る論理構成力 が使い手側に求められるのだと思います。

4. 上限トークン数vs実務での「真の精度」

現在、各社はコンテキストウィンドウ（一度に読み込める情報量）を競い合っています。

モデル名	コンテキストウィンドウ	最大出力トークン
Gemini 3.0 Pro	104万トークン	6.5万トークン
Claudecode-Opus4.7	100万トークン	12.8万トークン
gpt-codex-5.3	40万トークン	12.8万トークン

数値だけを見れば、100万トークンを誇るGeminiやClaudecodeが最強に見えます。Webアプリの新規作成など、スピード重視の作業では、彼らは確かに人間の10倍速で動き、非常に重宝します。

大規模マイグレーションで露呈する「実力差」

しかし、「レガシーアプリの大規模マイグレーション」 のように、事前に把握すべき情報量が膨大で、かつ緻密な論理が求められるプロジェクトに取り組むと、景色が一変します。

• Gemini / Claudecodeの限界: 仕様の把握漏れ、リスク評価の読み違い、潜在的なバグの量産……。結局、AIが書いたコードの「おしりふき（修正作業）」に人間の時間が無限に溶けていきます。まるで、手のかかる新米エンジニアの教育係をさせられているような感覚です
• gpt-codex-5.3の実力: トークン上限では劣るものの、情報の保持能力と論理的整合性において、私の体感ではCodexが頭ふたつ抜けているように感じます

※具体的な私の経験は、また別の記事で書こうかと思います。

私の現時点の結論：Codexを軸に据える

少なくとも今、大規模な調査が前提のプロジェクトでは、私は gpt-codex-5.3 を軸に据えています。

もちろん、ただ使うだけでは不十分です。

• SKILL.mdで各SubAgentの役割を定義
• agent.md によるMainAgentの役割を定義（特に、作業ワークロードの定義や、どんなタイミングでAgentTeamを起動するべきかを定義）
• Orchestrator（オーケストレーター）を起点としたAgentTeamを展開し、ワークフローごとにAsignするSubAgentを切り替え
• workflow.md による手順の厳格化
• Hook 定義したWorkFlowと、各SubAgentを利用するワークロードを100％履行するために必要

これらを揃えると、Codexの精度がとても高くなりました。使いこなすまでの学習コストもそこまで掛かりません。また、越えた先の投資対効果は大きいと感じています。 これをGeminiやClaudeCodeの環境向けにCustomしてやってみていますが、「正確さ」の追求はLLMも人材と同じく、難しく感じます。

• “コーディングの速度はとても早いが、働き方に難がある期待のFresher” == ClaudeCode
• “リーディング経験のあるシニアエンジニア” == Codex という印象です。

Contextと論理性

ある起点からGoalに向かう時、いったいどこまでの指示を与える必要があるのでしょうか。 仮に、地点Aを出発点として地点BをGoalとした移動を行うとします。 この時に考えうる道筋は、道路があればあるほど、無数に存在します。 しかしながら、ここに一定の条件を与えると、進むべきルートは限りなく “1” に近づきます。

# 条件例
- "〇〇分以内に到着せよ" という制約により、ルートや移動手段が絞られてくる
- "徒歩を使っていきましょう" という手段の縛りにより、最短経路と思えるルートに絞られる
- "歩道が広い道で安全に" という条件により、ルートの候補が道幅で絞られる

通るべき道路の名称を細かく指定したり、右左折すべき交差点名をすべて列挙する必要があるかというと、ありません。

「ある一定のルールをもたせると、自ずと答えが1つに絞られる」

そのある一定のルールこそ、論理性であるはずです。 大規模言語モデルが推論モデルを身に着けてきた今、Contextは本来、論理性に優れた情報をContextとして持つべきだと思います。 ここに向き合い

• 「十分かつ必要最低限のTokenで解決する方法を開発してきたgpt-5.3-codex」
• 「大量の情報を読み込める方法に糸口を求めてきたLLM」 では、ずいぶんと「精度」に差が出るのは必然なのではないでしょうか。

---

次回予告

なぜ、数値で劣るCodexが最適になってしまうのか？ 具体的にどうやってCodexを運用しているのか？ 私が実践しているAgentTeamや、ワークフローの組み方については、また別の記事で詳しく書いていきます。