結論 — コンテキストは「渡す量」ではなく「置き方」で決まる
Codexのコンテキストには上限があり、確認する /status、圧縮する /compact といった操作も用意されています。ただ、企業へのAIエージェント研修を行う当社の結論は、操作を覚えることより、コンテキストの置き方を設計することのほうがはるかに効くというものです。生データと整理済みの中間成果物を分け、索引(目次)を作らせる——このフォルダ設計だけで、圧縮のお世話になる場面は大きく減ります。
まず基本の用語と操作を短く押さえ、そのあと本題のフォルダ設計に進みます。
Codexのコンテキストとは — 作業中に使える情報のすべて
コンテキストとは、Codexが作業中に参照できる情報のすべてを指します。公式の用語集では、ファイル・これまでのメッセージ・ツールの実行結果・指示などがコンテキストにあたると整理されています。あなたが書いた依頼文だけでなく、読み込ませた議事録も、AGENTS.mdに書いたルールも、Codexが実行したコマンドの結果も、すべてコンテキストです。
そして、モデルが一度に考慮できる情報量の上限をコンテキストウィンドウと呼びます。イメージとしては財布に近く、会話を続けるほど、ファイルを読ませるほど残りは減っていきます。1時間の打ち合わせの書き起こしは、それだけで相当な量です。関連しそうな資料を毎回すべて読ませていると、肝心の作業に使う分が足りなくなります。
上限・確認・圧縮・リセット — まず押さえる基本操作
コンテキストが増えてきたときの確認と対処の操作を整理します(2026年8月時点)。
表は横にスクロールできます →
| やりたいこと | 操作 | 補足 |
|---|---|---|
| 使用量を確認する | /status | チャットIDとあわせて、コンテキスト使用量と利用制限の残りが表示されます |
| 圧縮する | /compact | 現在のチャットのコンテキストを圧縮します。上限が近づくと自動でも実行されます |
| リセットする | 新しいチャットを始める | 専用コマンドを探すより、作業のまとまりごとにチャットを分けるのが基本です |
圧縮(コンパクション)は、古いやり取りを要約して、長時間の作業を続けられるようにする仕組みです。公式ドキュメントでは、デスクトップアプリ・CLI・IDE拡張・クラウドのいずれでも働く機能として整理されています。また /status には利用制限(レート制限)の残りも同じ画面に表示されます。利用制限の仕組みと上限到達時の対処はCodexの利用制限と使用量の確認方法で解説しています。
圧縮は万能ではない
圧縮の実体は要約です。要約である以上、細部は必ず落ちます。序盤に伝えた細かい指示や検討の経緯が、圧縮後の会話では効かなくなることがあります。「圧縮しながら1つのチャットで粘る」のではなく、作業の区切りで新しいチャットを始め、引き継ぎたい内容はファイルに書き出して渡すのが実務では確実です。
圧縮に頼る前に — 詰まらせない「2階建て」フォルダ設計
ここからが本題です。コンテキストが詰まる最大の原因は、上限の小ささではなく、生データを毎回そのまま読ませていることにあります。打ち合わせの書き起こし・PDFの資料・過去のスライドを全部読んでから作業して、という頼み方を続ける限り、どれだけ上限が広くても足りません。
当社がおすすめしているのは、作業フォルダを「生データ」と「整理済み」の2階建てに分ける設計です。
プロジェクト/
├── raw/ ← 生データ置き場(PDF・PowerPoint・書き起こし等をそのまま)
├── docs/ ← Codexに整理させた中間成果物(Markdownに統一)
│ └── INDEX.md ← 索引(目次)。どのファイルに何があるかの一覧
└── output/ ← 最終成果物- 1生データ置き場には何も考えず放り込む — PDF・PowerPoint・Wordや書き起こしなど、拡張子がバラバラのままで問題ありません。集める段階で人間が整える必要はありません
- 2一括でMarkdownに揃えさせる — 「rawの中のファイルをすべてMarkdownに変換してdocsに入れて」と頼めば、形式の違いはCodexが吸収します。手作業で開いて転記する必要はありません
- 3索引(目次)を作らせる — 「docsの各ファイルに何が書いてあるか、一覧をINDEX.mdにまとめて」と頼みます。以降のCodexは索引を見て、必要な箇所だけを読みに行くようになります
この設計が効く理由は単純で、索引があれば全文を読む必要がなくなるからです。1時間分の書き起こしでも、索引に「この議事録の決定事項は◯◯、宿題は◯◯」とあれば、Codexは必要になったときだけ該当ファイルを開きます。読む量が減れば、圧縮が挟まる場面も、上限に届く場面も自然に減ります。
日頃から貯める — 依頼の直前にコンテキストを作り始めない
もうひとつ、フォルダ設計と同じくらい効くのが貯め方の習慣です。依頼しようとした瞬間に「さて、今からコンテキストを集めるか」と資料探しを始めると、そこで時間を取られ、結局「自分でやったほうが早い」に逆戻りします。コンテキストは依頼のたびに作るものではなく、日頃から貯まっていくように設計するものです。
たとえば打ち合わせは、録音して文字起こしを残すだけでコンテキストになります。オンライン会議なら、Zoomのクラウドレコーディングのように録画と同時に文字起こしファイルを残せる仕組みが使えます(録音は相手の許可を取ったうえで)。できた書き起こしを生データ置き場に放り込んでおけば、あとの整理はCodexの仕事です。
「議事録を清書してから保存しよう」と考える必要はありません。清書も索引づくりもCodexに任せられます。人間の仕事は、生データが自然に貯まる置き場所を決めておくことだけです。
ルールはAGENTS.md、資料はフォルダ — 置き場所の使い分け
最後に、コンテキストまわりの置き場所を整理します。「Codexに毎回これを踏まえてほしい」と思ったとき、その情報の性質によって置き場所は3つに分かれます。
表は横にスクロールできます →
| 持たせたいもの | 置き場所 | 理由 |
|---|---|---|
| 毎回必ず守るルール(言語・書式・禁止事項) | AGENTS.md | 毎回自動で読み込まれ、中身がいつでも見えます |
| 作業の材料(議事録・資料・過去の成果物) | 作業フォルダ(生データ + 整理済み) | 索引経由で、必要なときだけ読ませられます |
| 過去のやり取りの偶発的な文脈 | メモリ機能には頼らない | 古い前提が混ざるリスクがあるため、残したい文脈はファイルに書き出します |
AGENTS.mdの書き方はAGENTS.mdの書き方で、メモリ機能に頼らず明示のファイルで担保する考え方はCodexのメモリ機能で詳しく解説しています。1回の依頼の組み立て方(指示・コンテキスト・完成条件の3点セット)はCodexの使い方を参照してください。
こうしたコンテキストの置き方の設計は、個人のテクニックにとどまらず、チームでフォルダ構成と貯め方を揃えたときに最も効果が出ます。当社のCodex研修・導入伴走支援では、ツールの操作方法だけでなく、この情報設計の部分からご支援しています。
Codexを組織に定着させたい企業様へ。AI Orchestraの法人研修・導入支援をご覧ください。




