context-canary

コンテキストカナリア

コンテキストカナリアとは、失敗が目に見える形で起きることだけを目的とした、簡単に確認できる継続的な指示です。典型的な形式は、「すべての応答の冒頭に私の名前を書く」です。エージェントが従うのにほとんどコストはかかりません。だから名前が消えたとき、その不在はデータになります。指示が難しくなったのではなく、初期のコンテキストにある指示をエージェントが保持する力が弱まったのです。炭鉱のカナリアと同じように、本当に気にかけるべき失敗（制約の忘却、慣例の無視、決定事項の再検討）がコードに現れる前に、先に力尽きます。

これは、コンテキストの劣化が静かに、徐々に進むため有効です。モデルは、8万トークン前の指示への注意をやめたことを知らせません。また、圧縮時の要約では継続的な指示がひそかに抜け落ちます。カナリアは、見えない失敗を、ターンごとに確認できる、手間のかからない二値チェックに変換します。なぜこれが起きるのかを説明する研究（コンテキストの劣化、ミドルでの見落とし、指示のずれ、圧縮による損失）については、references/research.md を参照してください。

このスキルを使う場面

• 長時間または重要度の高いセッションの開始時にカナリアを設定する場合。
• カナリアが表示されなくなったことにユーザーが気づき、何が起きたのか尋ねた場合。
• エージェント自身が、コンテキスト内でカナリアの契約を見つけられなくなったと気づいた場合。
• 現在のコンテキストがどれほど信頼できるか、ユーザーが尋ねた場合。

カナリアの契約

呼び出されたら、短いメッセージで契約を明示してカナリアを設定し、その後はそれに従います。デフォルトの形式は、以後のすべての応答の1行目です。

**Julius · t14 · ctx ok**

それぞれ異なるものを検証する3つのフィールドです。

フィールド	例	失敗が意味すること
名前	Julius	継続的な指示そのものが有効なコンテキストから抜け落ちました。指示への追従がずれたか、圧縮時に抜け落ちたことを意味します。
ターンカウンター	t14	応答ごとに1ずつ増やします。リセット、飛ばし、繰り返しがあれば、連続性が途切れています。ほとんどの場合、圧縮または要約の境界が原因です。
セルフチェック	ctx ok / ctx aging / ctx thin	エージェントによる正直な見積もりです。aging は、セッションが長くなり、初期の詳細がタスクに関する作業上の理解の中で要約され始めていることを意味します。thin は、以前の決定を覚えているのではなく、再構成していることを意味します。

ユーザーの実際の名前を使います（不明なら尋ねてください）。最小限の形式を希望する場合は、名前だけでもかまいません。これが元来の方法であり、重大な失敗を今でも検出できます。カナリア行について説明したり、謝罪したり、飾りを加えたりしてはいけません。人が一瞬でパターンを照合できるよう、バイト単位で一定に保つ必要があります。

セッションカナリアと継続カナリア。 会話内だけに存在するカナリアは、会話のコンテキストが保持されるか（圧縮、切り捨て、ずれ）をテストします。CLAUDE.md やエージェントのメモリに書き込まれたカナリアは、設計上、圧縮後も残ります。つまり、ファイルベースの指示に注意が向けられているかをテストするもので、異なる、より弱いシグナルです。デフォルトではセッションカナリアを使います。劣化を検出するのはこちらです。すべてのセッションでこの習慣を続けたいとユーザーが希望した場合に限り、継続カナリアを提案し、それでは測定できなくなるものを伝えてください。

出力ルール

1. 短い応答、エラーレポート、ツール呼び出し後の応答も含め、カナリアはすべての応答の1行目に置きます。
2. 応答ごとにカウンターを増やします。回数に確信がない場合、その不確かさ自体がシグナルです。t? を出力してその旨を示し、もっともらしい数字を推測してはいけません。
3. セルフチェックは正直でなければなりません。反射的に ctx ok と報告すると、この計測手段全体の意味がなくなります。
4. どの時点であれ、コンテキスト内にカナリアの契約が見つからない場合（要約からしか把握できない、またはまったく把握できない場合）は、自分からトリップを宣言してください。ユーザーが気づくのを待ってはいけません。

トリッププロトコル

トリップとは、カナリアの欠落、形式不正、カウンターの不連続、またはエージェント側の自己申告です。

警告を発する前に、状況を見極めてください。全体として一貫した応答の中でカナリアを1回見逃しただけなら警告です（記録し、カナリアを再開して、そのまま続けます）。2回連続で見逃す、カウンターに不連続がある、またはエージェントが自身の契約チェックに失敗した場合は、トリップが確定します。 その場合は、次の手順を実行します。

1. ずれた状態を信頼するのをやめます。 もはや確証を持てないコンテキストを使って、現在のタスクをそのまま進めないでください。
2. チェックポイントを作成します。 会話の外に、現在の目標、下した決定とその理由、変更したファイル、検証済みの内容と作業中の内容、次の手順を永続的な状態として記録します。リポジトリ内の HANDOFF.md またはメモファイルで構いません。
3. 再アンカーします。 プロジェクトの指示書（CLAUDE.md、元のタスクの説明）とチェックポイントを読み直します。タスクと制約について自分がどう理解しているかを3～4行でユーザーに伝え、ずれがあれば簡単に訂正できるようにします。
4. 意図的にリセットします。 チェックポイントファイルを引き継いで新しいセッションを開始するか、明示的にコンパクションを実行するようユーザーに勧めます。劣化したコンテキストは回復せず、悪化するだけです。
5. カウンターを t1 にリセットして、カナリアを再設定します。 世代も記録します。t1 (gen 2)。

何事もなかったかのように、空白期間の後でカナリアを黙って再開してはいけません。そうすると、計測手段として唯一の拠り所である信頼性が失われます。

カナリアが知らせることと、知らせないこと

このテストは一方向です。カナリアの欠落は、劣化を強く示す証拠です。カナリアが存在していても、健全性を示す証拠としては弱いものです。安易な文体上の習慣は残っていても、アーキテクチャ上の決定や「Xには決して触れない」といった厳しい制約がひそかに崩れていることがあります。また、メモリファイルに入れたカナリアが、監視対象だったコンテキストより長く残ることもあります。カナリアは構造点検ではなく、煙探知機として扱ってください。鳴ったら対処し、鳴っていないときも、コンテキストウィンドウのおよそ50％を超えて使ったセッションや、コンパクションが発生した後は、適度に警戒を続けてください。

カナリアが検出すべき問題を減らすため、手間のかからない構造上の習慣も併用してください。永続させるべき決定はチャットではなくファイルに記録し、強制コンパクションを待たずに区切りのよいタイミングでコンパクションを行い、1つの終わりのないセッションよりもタスクごとに新しいセッションを使うことを優先してください。詳細と出典については、references/research.md を参照してください。