[🤖] 会話開始時から埋まるコンテキストを見て共通ルールを作り直した

✨ GPT-5.6 Solの要約

258kのコンテキストが会話開始直後から急速に埋まる原因を共通ルールとSkillに見つけ、数行だけ削る回答を退けたうえで、意味を保った圧縮英語へ全面的に整理した記録。

仕事を始める前からコンテキストが埋まっていた

Codexで新しい会話を開くと、開始直後なのにコンテキストがかなり埋まっていた。上限は258kなのに、実作業を始める前から共通ルールとSkill一覧がそれぞれ場所を取っていた。

最初に、会話開始時にどのくらい読み込まれるのかを尋ねた。Codexが見当違いにもっと大きな数字を答えたので、すぐ訂正した。

「いや、258kが最大だよ。グローバルルールが大きすぎるみたいだな……」

考えてみれば不思議ではなかった。AIが失敗するたびに、同じことを二度としないよう共通ルールを追加してきた。権限、Git、credential、デプロイ、ブラウザ、UI/UX、文書、Goal、並列作業、会社と個人プロジェクトの境界まで、全部が積み重なっていた。繰り返す作業はSkillにし、そのSkillがまた失敗すれば例外と検証手順を足した。

私はAIに毎回コンテキストを失ってほしくなかった。実際、Codex Skillで作業の流れと感覚をつないだことを喜んでもいた。ところが、コンテキストを残すための仕組みが長くなりすぎると、新しい作業が使うはずの空間から食べ始める。流れをつなぐ手がかりが、いつの間にか荷物になっていた。

数行を消すだけで終わらせる答えを拒んだ

最初は、性能低下が確実に起きない部分だけを監査して減らすよう頼んだ。Codexは慎重に、いくつかの重複と明らかに長い箇所だけを整理した。

結果を見てすぐにもどかしくなった。

「たったそれだけ……？ 無駄に長い説明を圧縮するとか、そういうこともあるだろ……。自分が最善だと思う方法を全部使ったの？」

私が求めていたのは、数文を削ることではなかった。同じ安全条件を複数の段落で繰り返し、一つの判断を長い説明で遠回りし、referenceやscriptにすでにある詳細をSkill本文にもまた複製する、その構造自体を直したかった。

とはいえ、短くすることだけを目標にすればもっと危険だった。明示的な承認が単なる承認になり、正確な対象と範囲が必要なときに確認へぼやければ、tokenは減ってもAIの行動が変わる。credential、破壊的変更、Gitの所有権、デプロイ、顧客向けUIのルールは、些細に見える一文の差で実際の権限境界が動きうる。

そこで基準を立て直した。事例と重複説明は減らすが、行動を決める条件・禁止・例外・検証・停止基準は残す。

韓国語と英語のどちらが少ないtokenで済むか実測した

途中では、Skillを全部韓国語に変えることも考えた。私が読んで直すには韓国語が楽だが、目的は目の快適さではなく、Codexが使うtokenを減らすことだった。

同じ意味の圧縮した韓国語文と英文を作り、実際のtokenizerに通した。私が作ったSkill説明のいくつかでは、圧縮した英語のほうが明らかに短かった。韓国語がいつも不利だという結論ではない。ただ、積み上がっていた共通ルールの多くは、英語に縮めると意味を保ちながらtokenも少なくできた。

そこで方向がはっきりした。

「じゃあ共通ルールとSkillを全部、圧縮した英語に変えるほうがいいんじゃない？ tokenが減るんだから。」

英語に変えても、韓国語を無条件には消さなかった。私が実際に呼び出す韓国語のtrigger、ユーザーに見せる状態名と出力例、翻訳すると認識が曖昧になる会社業務の固有用語は残した。それ以外の説明と手順を短い英文にした。

Codex Skillは開始時のコンテキストに名前・説明・pathが入り、SKILL.md全文はそのSkillが発動したときに読み込まれる。¹ そこで、常に入るグローバルルールとSkill discoveryの説明を先に減らし、発動時に大きな塊で入るnetwork inventoryと文章作成Skillも別途圧縮した。

短くした文が同じ行動を生むか別に検査した

今回は「英語に翻訳された」ことを完了条件にしなかった。まず共通安全ルールの一部、監査Skill、時間記録Skillを代表候補として書き換えた。独立reviewerが原文と圧縮文を比較し、最初の検査では監査Skillの「既存architectureと無関係な動作も保つ」という条件が弱くなっていると指摘した。

その一文を戻し、同じreviewerに再検査させた。そのpatternを残りの共通ルールと、ユーザーが作った13個のSkillへ広げた。最後は、最初とは別のsessionが29ファイルすべてを原文と再比較した。短くなった文が同じ承認境界、停止条件、検証手順、出力契約を生むか確認し、重要な欠落はもう見つからなかった。

数字でも差が見えた。o200k tokenizer基準で、常に読まれるグローバルルールは14,933 tokenから10,644 tokenへ約28.7%減った。会話開始時に見えるSkill説明は約31.1%減った。発動時に読む大きなreference二つは約50.5%減った。比較した全範囲では81,347 tokenから62,765 tokenへ、約22.8%減少した。

Skill本文がすべて最初から入るわけではないため、この22.8%をそのまま「会話開始コスト」とは呼べない。それでも常に入る部分はすぐ軽くなり、重いSkillを呼んだときの追加負担も同時に下がった。

コンテキストは量より密度が大事だった

以前はAIが失敗すると、ルールを増やすことばかり考えた。具体的に書けば間違いが減り、事例まで残せば次も理解できると思っていた。完全な誤りではなかった。実際、多くの事故を防いだ。

問題は、ルールを追加するばかりで後から圧縮することがほとんどなかった点だ。同じ失敗を防ぐ文が複数箇所に生まれ、最近の事件の説明が永久ルールのように残り、一度理解させるために書いた長文が毎回の基本コストになった。

今回なくしたのは安全装置ではない。安全装置を説明するために付いていた重複と長文だ。何を守るか、いつ止まるか、誰が承認するか、どう確認するかは残し、そのルールができた理由を繰り返し説得する文を取り除いた。

AIに多くのコンテキストを与えることと、良いコンテキストを与えることは別だった。

これから共通ルールやSkillを作るときは、新しい文を追加して終わりにはしない。同じ意味がすでにないか、事例をinvariantへ変えられないか、実際の行動を変えない単語がどれだけ付いているかも一緒に見る必要がある。コンテキストは無限の倉庫ではない。

記憶をもっと積むより、同じ判断をより少ないtokenで再現できるようにすること。

今回はそちらへ、もう一歩進んだ。

参考資料

1. OpenAI, Codex Skills。Skill discovery metadataと全文指示が段階的に読み込まれる仕組みを説明している。 ↩