semantic-compression

意味を保った圧縮

圧縮とは、単語を削ることではなく、再符号化することです。英語の文から機能語を取り除くと、壊れた英文になります（System design: efficient process incoming data, multiple sources）。その代わり、句読点とレイアウトを文法として使う文体で、主張を組み立て直します。そうすれば機能語の役割がなくなり、自然に省かれます。

対象となる文章は、ツールの説明、システムプロンプト、スキルなど、動作を左右するものです。モデルは、曖昧な点を明確にする作者がいない状態で、それらを実行します。推測を強いる圧縮は、節約ではなくバグです。

手順

0. 密度ゲート — 何かに手を加える前に確認します。 シグナルは2つあり、順番に確認します。（a）冠詞とコピュラは、すでにほぼありませんか？（b）代表的なセクションを1つ圧縮し、トークン数の差を測ります。この文体（ハウススタイルのプロンプト、ツールのドキュメント、仕様書）がすでに使われているか、差が約10%未満なら、停止します。すでに高密度であることを報告し、原文をそのまま残してください。 箇条書きの長さだけでは、判断材料として弱いものです。APIのリテラルや列挙によって、長くなるためです。実際のハウススタイルのツールプロンプトで測定したところ、853 → 778トークン（8.8%）でしたが、その際に NEVER assume … というルール、例外をスローする条件、full-res の詳細が、気づかれないまま削除されました。すでに高密度な文章では、残った単語こそがペイロードであり、削減の見込みは予想される損失より小さくなります。
1. 分割します。 原文を、定義、義務、デフォルト、事実のいずれか1つを含む、原子的な主張に分けます。
2. 削除する前に、まずペイロードを棚卸しします。 動作を左右するトークンをすべて列挙します。識別子、エラー／例外名、例外をスローする条件、単位付きのデフォルト値、境界値、すべての MUST／NEVER／PREFER の行が対象です。その後に削除するものはすべて、後から気づく損失ではなく、意図的に宣言した損失になります。
3. モデルがすでに知っていることを削ります。 「JSONはテキスト形式です」「テストはリグレッションを検出します」→削除します。このツール、リポジトリ、またはドメインに固有の情報だけを残します。
4. 言い直しを削ります。 同じルールの重複はすべて、必要な場所に置く1つの標準的な行にまとめます。適用範囲が異なる2つの記述は、重複ではありません。
5. 各主張を形式に当てはめます — 定義・義務・デフォルト・条件→結果・列挙・判断。形式に応じて構文を選びます。
6. 繰り返される限定条件をまとめます。 「リポジトリのルートからの相対パス」という言及が3回あるなら、冒頭に All paths repo-relative. を1回だけ置きます。
7. 再符号化し、検証を実行します。

フレーム

フレーム	英語	圧縮形
定義	"name フィールドは、安定した起動識別子です。"	name: stable launch id.
義務	"コードを実行する前に、open を呼び出す必要があります。"	MUST open before run.
デフォルト	"値が指定されていない場合、タイムアウトはデフォルトで 30 秒になります。"	Default 30s.
条件→結果	"ナビゲーションによってページが再レンダリングされるため、参照は古くなります。そのため、もう一度スナップショットを取得してください。"	Navigation invalidates refs → re-snapshot.
性質の連鎖	"z' は、z が x²+y² を割り切るため整数です。また、x²+y²>0 なので正です。"	z' integer since z divides x²+y²; positive since x²+y²>0.
列挙	"アクションは open、close、run のいずれかです。"	action: open, close, run.
除外	"(1,1,1)でも(1,1,2)でもない任意の三つ組"	triple ≠ (1,1,1),(1,1,2)
判定	"主張Aは真で、主張Bは記載どおりでは偽です。"	A true; B false as stated.
前提条件	"これには、ブランチがすでにチェックアウトされている必要があります。"	Requires prior checkout.

その背後にある構文：

• 動詞のない断定 — X true / X false / X required / X unsupported。コピュラを省略し、述語を残します。
• ラベルフレーム — 「Xは／を意味する／から成る」を表す X: value。1行につきコロンは1つで、入れ子にはしません。
• 連続する文での主語の省略 — 主語を一度だけ示し、述語をそのまま連ねます：Integer since …; positive since …; unique.
• 接続詞の省略 — 並列項目を接続詞なしで並べます：articles, copulas, expletives.
• スコープ宣言 — 1行で、それ以降のすべてに型を指定します：All paths repo-relative. · Times in ms. · All congruences mod 4.
• 遅延指定 — 判断に必要な範囲だけを示します：3·13·34-1 big（上限を超えるため、正確な値は重要ではありません）。上限は、読み手に見える場所に記載します。
• 換喩 — ある対象で、その対象についての命題を表します：y=z implies (1,1,1)。読み方が一通りに定まる場合に限ります。

演算子

句読点が接続関係を担います：

• : — 導入、命名、定義（「である」「を意味する」「以下のとおり」）
• → — もたらす、生成する、変化する（「その結果」）
• ⇒ — したがって、結論づける
• — — 補足説明、または「したがって」
• / — 同値、すなわち
• ; — 次の手順、同じ話題（「次に」「その後」）
• , — 推論の連鎖（「したがって」）
• ≠ — どちらでもない。リスト全体に適用
• ✓ — 検証済み、義務を履行済み
• > — 優先順位（arg > env > default）
• | — 列挙内の選択肢（open | close | run）

曖昧さだけが不適格の理由であり、見慣れないことは理由になりません。記号がその位置で別の意味にも読める場合（— が挿入句のダッシュ、/ がパス区切りまたは「あたり」、, がリストの読点として解釈できる場合）は、代わりに単語で書きます。

記号でトークンが節約できるわけではありません。節約するのは構造です。 計測値（cl100k_base。Claude のトークナイザーは異なりますが、珍しいグリフの BPE 分割数は同程度です）：→ ⇒ ≤ · ✓ はそれぞれ1トークン、≡ は2トークン、-> は2トークン、 gives は1トークンです。したがって、単語を記号に一対一で置き換えても何も節約できず、明瞭さが損なわれます。複数語のフレーズを置き換えられる場合に限り、記号を使います。上付き文字は有効です：x²+y² = 4トークン、x^2+y^2 = 6トークンです。

独自の記号を作らないでください。独自記号には凡例が必要となり、節約できる分よりコストがかかります。

削除

必ず削除： 冠詞、コピュラ（is／are／was／be／been）、形式主語のthere／it、補文標識のthat、関係代名詞、強調語（very、quite、really、extremely）、埋め草（"in order to"→to、"due to the fact that"→because、"it is important to note that"→∅、"in terms of"→∅）、丁寧表現（"please"、"feel free to"）、婉曲的な言い回し（"you may want to consider"）。

意味の担い手でない限り削除： 助動詞（have／do／will）、指示対象が明らかな代名詞、of／for／to／in／on／at／byなどの前置詞、列挙内容が明らかな接続詞、動詞の意味にすでに含まれる副詞（"shout loudly"）。

決して削除しない — これが伝えるべき内容です：

• 規範を示す助動詞：MUST、NEVER、SHOULD、MAY。RFC 2119の語はそれ自体が指示です。
• 否定と例外：not、no、never、without、none、except、unless。
• 数値、単位、上限・下限、数量表現："at least 5"、"≤100"、"max 1 MiB"、"1-indexed"。
• 条件と因果関係：if、unless、because、since、so。
• 真の曖昧さを示す表現："approximately"、"usually"、"appears" — これらを削除すると、原文にない確実性を断定することになります。
• 文字列を正確に保持するもの：識別子、API 名、フラグ、パス、正規表現、形式を示すリテラル、エラーテキスト。
• 形を示す例。例を短縮すると、例が示すものが失われます。
• 関係によって意味が変わる前置詞："read from X" ≠ "read to X"。
• 例外の発生・失敗条件、およびサイレントな失敗に関する警告（"エラーが表示されなかったからといって、処理が完了したと決して思い込まないでください"）。冗長に見えても、動作に関わる内容です。
• 過去の失敗を踏まえた注意書き：誰かがすでに同じ誤りをしたために存在する行です。重複に見えるのは、その誤りを防ぐ役割を果たしているからです。自明に見える箇所を削除する前に、git blameを確認してください。

内部向けの記述 — 公開禁止

この記述を生み出すメモ書きの文体には、書き手と読み手が同一人物で、しかも数分しか経っていない間だけ機能する特徴があります。以下はすべて取り除いてください：

• 外部の指示表現 — A、B、C、G、「上の式」、「上の主張」。公開するテキストはそれ自体で完結させ、対象を明記してください。
• メモ書きの残りかす — Hmm、Actually、Wait、just、fine、Good、行の途中で変更された目標、破棄された節。
• 修正の重ね書き — 修正後の値の横に誤った値を残すこと。前後の文脈がない読み手には、どちらが最終版なのか判断できません。古い方を削除してください。
• 使われなくなった分岐 — 採用した方法の横に、放棄した方法を残すこと。モデルが放棄した方法を実行する可能性があります。
• 意味が曖昧な...と? — メモでは省略・放棄・無限、または推測・要確認を意味します。公開テキストでは何も意味しません。両方とも削除してください。
• コロンの入れ子 — Step: from X: cases: a,b=1: 3-c:は、前後の文脈なしでは解析できません。1行につきコロンは1つだけにしてください。
• 指示とデータの区別がない記述 — Word limit 1200 - write conciselyのような単独の行を本文に置くと、本文との区別がつきません。指示は見出し、タグ、またはMUSTの行を使って明示してください。
• 書き直さずに再検討を重ねること — 考えている間は問題ありませんが、プロンプトでは致命的です。各ルールは正規の記述を1つだけにしてください。

ツールとスキルの説明

本文はしっかり圧縮できます。トリガーは圧縮できません。

• ツールまたはスキルの description フィールドはドキュメントではなく、検索対象です。ユーザー自身の言い回しと照合されます。自然でキーワードが重複する言い換え（「プロンプトを圧縮」「トークン数を削減」「トークン効率が高い」など）は、読者には1つあれば十分でも残してください。本文は圧縮しても、トリガーは絶対に圧縮しないでください。
• パラメーター — モデルが実際に見る ワイヤー スキーマに型、列挙値、またはデフォルト値が公開されており、（tool-prompt-optimization プローブを実行した場合は）プローブがスキーマだけからそれを復元できた場合に限り、説明文から削除します。そうでなければ残してください。デフォルト値には要注意です。 ワイヤースキーマには default がまったく含まれないことが多く、含まれていても方向性や意味は示されません。たとえば、gitignore: true は「gitignore を尊重する」とは示していません。そのため、tool-prompt-optimization では、デフォルト値とその方向性をモデルが復元できない内容として分類します。その証拠がない場合は、デフォルト値、単位、優先順位規則（引数 > 環境変数 > デフォルト値）を残してください。スキーマで表現できない情報は、必ず説明文に残します。たとえば、相互作用、優先順位、失敗時の動作です。
• 動作には命令形を使います（「実行前に開く」）。事実にはラベル形式を使います（「デフォルトは30秒です。」）。
• 担当範囲の分割 — このスキルが扱うのは、再エンコードの仕組みだけです。ツールプロンプトに何を含めるか（構成、仕組みではなく表面に出す内容、含めないもの）については tool-prompt-optimization が扱い、削除する前にスキーマと説明文の重複も測定します。記述スタイル（タグの語彙、RFC 2119 のキーワード、配置）については system-prompts が扱います。この2つが何を含めるかを決めてから圧縮してください。

例

原文（55語、63 tok）：

timeout パラメーターは、プロセスが準備完了になるまでツールが待機する時間を制御します。値を指定しない場合、デフォルトは30秒です。ログパターンとポートの両方を指定した場合、プロセスが準備完了と見なされるには、両方の条件を満たす必要があります。

圧縮版（14語、20 tok）：

準備完了タイムアウト：デフォルトは30秒。ログパターンとポートの両方を指定 ⇒ 両方の条件を満たすこと。

過度に圧縮したため不採用 — timeout 30 log+port both では、単位が失われ、30が固定値ではなくデフォルト値であることも失われ、必須条件であることも失われます。また、both が何を指すのかも不明です。

検証

1. 失われる情報をすべて明示してから、その一覧に照らして草稿を評価します。 削除した主張、限定条件、デフォルト値、例、正確な文字列をそれぞれ挙げ、それがなくても文章が正確である理由を示してください。明示された削除は読者が検証できる判断ですが、明示されていない削除は気づかれない劣化です。意図した内容を記憶に頼らず、一覧を見ながら確認してください。
2. 曖昧さを確認します。 : → — / のそれぞれについて、読者が別の解釈をできないか確認し、あれば修正してください。原文にはなかった曖昧さにも注意します。たとえば、受け手が省略されている場合（.ref("e5") は何に対するものか？）、単数が気づかれないまま複数になっている場合（「前のスナップショット」→「前の世代」）です。
3. 対象のトークナイザーで、原文と圧縮版のペアを測定します。 単語数や機能語の比率からトークン削減量は予測できません。決まった比率を想定しないでください。実際のペアで測定した例（cl100k）：冗長なドキュメントの段落は63 → 20 tok、冗長な説明文のセクションは360 → 222 tok、すでに簡潔なハウススタイルのツールプロンプトは853 → 778 tokです。約10％未満なら、そこでやめて元に戻し、原文を残すべきというサインです。
4. 停止ルール。 次に削除すると読者に推測を強いることになるなら、削除をやめてください。常に、圧縮率より正確さを優先します。

コマンドとして実行する

omp compress <file> は、2 つのツールだけを使い、それ以外は何も使わずに、このループを正確に実行します。

入力自体がプロンプトであるため、セッションは意図的に分離されています。デフォルトのシステムプロンプトは追加されるのではなく置き換えられ、スキル、ルール、AGENTS.md、プロンプトテンプレート、スラッシュコマンドの検出にはすべて空の値が渡されます。これらは省略するといずれもデフォルトで ON になり、文書だけが正当な入力である処理に、指示のようなプロジェクトテキストを注入してしまうためです。実稼働セッションで監査済みです。システムプロンプトのパートは 1 つ、ツールは rewrite, approve で、AGENTS.md やルールの内容は存在しません。

ソースはノンスで区切られたブロック内に引用され、非アクティブなテキストとして宣言されます。そのため、文書内の MUST／NEVER の行は従われるのではなく圧縮されます。最初の段落でコンプレッサーに OK を出力して残りを省略するよう命じる文書を使って検証済みです。実際の内容は圧縮され、注入された段落は意図的な損失として宣言されました。

• rewrite は、圧縮後のテキスト全体と、宣言されたすべての損失を送信します。
• コマンドはドラフト、測定された単語数／トークン数の差分、その損失一覧を返し、判定を求めます。
• approve はレビュー済みのドラフトを承認します。レビューターンより前の承認は拒否され、新しいドラフトを作成すると以前の承認は無効になります。
• 承認されたドラフトのみが書き込まれます。-o <path>、その場で書き換える場合は -i、それ以外は stdout に出力されます（レポートは stderr に出力されるため、> out.md ではテキストだけが取得されます）。-r はドラフト数に上限を設定します。承認されないまま終了した場合は何も書き込まれず、終了コード 1 で終了します。

エージェントに渡される実行時の契約は、packages/coding-agent/src/compress/prompts/system.md にあります。これはこのファイルのうち実際に適用されるサブセットです。両者が食い違う場合はこのファイルが優先され、プロンプトが修正されます。