Clineが実際に公開したもの
最初の修正はルールに関するものです。リリースノートには次のように書かれています。「Rulesパネルには.clinerulesとDocumentsのグローバルフォルダのみがリストされていたため、.cline/rules、~/.cline/rules、または~/Cline/Rulesからロードされたルールはモデルに適用されていたものの、パネルには表示されていませんでした。また、OneDriveにリダイレクトされたDocumentsフォルダを持つWindows環境では、グローバルルールがまったく検出されませんでした。」
この一文には2つの不具合が含まれています。3つの場所においてルールは機能していたものの不可視であったこと、そしてOneDriveリダイレクトを使用しているWindows環境ではグローバルルールがまったくロードされていなかったことです。
2つ目の修正はフックに関するものです。「UserPromptSubmitおよびTaskStartフックが再びコンテキストを注入できるようになりました。これらのフックがcontextModificationとして返した内容がドロップされ、cancelのみが機能していたため、リポジトリのファクトやハウスルールをタスクに追加するためのフックが静かに何も行わない状態になっていました。」ノートには、このコンテキストが「デグレ前と同様に、実行の最初のリクエストで<hook_context>ブロックとして配信されるようになった」と付け加えられています。
3つ目の修正は長期タスクに関するものです。「長期タスクの途中で、コンパクション（Compaction）が静かに切り詰め（truncation）にフォールバックすることがなくなりました。要約機能はタスク開始時に取得した認証情報を保持し続けていたため、認証情報が更新されると、要約リクエストが握り潰された認可エラーで失敗していました。現在は、タスクの現在の認証情報とモデルに従うようになっています。」
CLIのリリースでは、ユーザー側から見た同じ不具合について次のように説明されています。「要約の代わりに、途切れた履歴（transcript）が返されていました。これは特にcline-free/*モデルで顕著でした。」また、「セッションの途中でモデルを切り替えた後も、要約機能は元のモデルのまま留まっていた」とも指摘されています。
デスクトップ版のリリースはさらに踏み込んでいます。「デスクトップアプリでの長いセッションが自動的にコンパクションされるようになりました。これまで自動コンパクションは実際には機能していませんでした。」そして、これが最近のデグレではないことを明記しています。「これは最近のデグレではなく、4月にコア機能でコンパクションがオプトイン方式になって以来のギャップでした。」
CLIとSDKのノートの双方に、コンパクションに関するもう1つの変更が記載されています。以前のコンパクションは文字数の推定値に基づいてトリガーされていましたが、高密度なコンテンツではその推定が崩れていました。「コンパクションは、文字数の推定値ではなく、プロバイダーの実際のトークン使用量に基づいて実行されるようになりました。」CLIのノートには、古い症状が詳しく説明されています。長いセッションが「コンパクションされることなく実際のコンテキスト上限に達し、その後、1ターンあたりの出力トークンがわずか数トークンにまで絞り込まれてしまう可能性がありました。」
今回の修正で変わること、変わらないこと
最も重要な境界線から始めましょう。リリースノートは、アップデートした瞬間からコードがどのように動作するかを説明しています。これらのノートには、アップデート前に実行されたセッションを修復することについては一切記載されていません。8月に切り詰められたタスクは、切り詰められた履歴のまま残ります。
フックの修正も、見た目より範囲が狭いです。CLIのリリースには、「実行開始時のフック制御（cancelおよびagent_start/agent_resumeスクリプトからのコンテキスト注入）は、意図的なオプトインが行われるまでCLIでは不活性なままです」と記載されています。そのため、フックをCLI経由で実行している場合、拡張機能の修正はあなたのセットアップには該当しません。
ルールの修正は、パネルが表示する内容を変更し、ドキュメントの約束が実際に何を意味するかを変更します。Clineのルールに関するページには、「検出されたすべてのルールタイプがRulesパネルに表示され、個別に切り替えることができます」と書かれています。v4.1.20以降、この一文は修正で指定された3つの場所における拡張機能の挙動を正しく表すようになります。それ以前は、これらの場所のルールは適用されていたものの、リストには表示されていませんでした。
これは、パネルをチェックリストとして使用していたすべての人に直接的な影響を与えます。以前のガイドであるタスク前にアクティブなClineルールをマッピングするでは、パネルを検出されたルールのインベントリ（目録）として扱っています。4.1.20より前のバージョンでは、.cline/rules、~/.cline/rules、および~/Cline/Rulesにあるルールは、モデルに届いていたものの、そのインベントリの対象外でした。そのガイドにある2つのゲートロジック（パネルの切り替えとルール自体の条件）は依然として有効ですが、インベントリのステップを完全にするには最新バージョンが必要です。
コンパクションの修正は、新しい設計を導入するのではなく、ドキュメント化された設計を復元するものです。ClineのAuto Compactページには、意図された挙動（「これまでに発生したすべての包括的な要約を作成する」および「会話履歴を要約に置き換える」）が説明されており、それ以前の挙動（「以前は、コンテキスト制限に達したときに古いメッセージを切り詰め、重要なコンテキストを失っていました」）と対比されています。このバグにより、影響を受けた長期タスクは、告知されることなく古い挙動に戻ってしまっていました。
また、同ページでは、一部のモデルでは依然として切り詰めが仕様であることも明記されています。「他のモデルでは、Auto Compactが有効であっても、Clineは標準的なルールベースのコンテキスト切り詰めにフォールバックします。」したがって、このリリース以降の切り詰めが自動的にバグであるとは限りません。それは、そのタスクがどのモデルで実行されていたかを確認すべきシグナルです。
人々が誤解しがちなこと
最初に広まるであろう解釈は、「Clineが私のルールを無視していた」というものです。しかし、ほとんどのユーザーにとって、ノートに書かれている内容はそうではありません。3つの場所において、ルールは「モデルに適用されていたが、パネルに表示されていなかった」のです。モデルはルールに従っていましたが、ユーザーに見えていなかっただけです。例外は、OneDriveにリダイレクトされたDocumentsフォルダを持つWindows環境であり、そこではグローバルルールが「まったく検出されていませんでした」。このグループに該当するユーザーは、今回の修正を表示の変更だけでなく、挙動の変更として捉えるべきです。
2つ目の解釈は、コンパクションは信頼できないためオフにすべきだというものです。これは歴史を逆行させています。要約は切り詰めの代替手段であり、今回の不具合は要約機能が静かにその役割を切り詰めに差し戻してしまっていたことです。コンパクションをオフにしても、古い挙動を回避できるわけではありません。むしろ、長期タスクの容量が不足した際に、確実に古い挙動（切り詰め）が発生することになります。
3つ目の解釈は、フックがどこでも機能するようになったというものです。これらは拡張機能のUserPromptSubmitおよびTaskStartパスで再び機能するようになりました。CLIのノートには、実行開始時のコンテキスト注入は「意図的なオプトインが行われるまでCLIでは不活性なままです」とあり、SDKリリースでは、それをベースに構築するホスト向けの新しい実行開始チャネルについて説明されています。フックがどこで実行されるかによって、これらの文のどれがあなたに適用されるかが決まります。
最も避けるべき誤解は、一般的なものです。つまり、パネル、フック、または要約が存在することが、コンテキストが届いたことの証明になるという誤解です。今回のリリースは、目に見える表面と実際のコンテキストが一致していなかった3つのケースを記録しています。これは、エージェントが指示ファイルを無視しているように見える原因となる問題と同じ類のものであり、ファイルが存在するかどうかではなく、特定のセッションがそれをロードしたかどうかが問題になることがほとんどです。
対策：すべての環境をアップデートし、各チャネルを記録と照合する
過去のセッションで失われたコンテキストを監査することはできません。できることは、Clineを使用するすべての場所で最新バージョンが実行されていることを確認し、ツール外に保管された記録と照らし合わせて3つのチャネルをチェックすることです。
ステップ 1: 実際に使用しているすべてのCline環境をアップデートする
修正は環境ごとに個別にリリースされました。VS Code拡張機能の修正はv4.1.20に含まれています。デスクトップアプリのコンパクションとルールの修正はデスクトップ版 v0.0.33に含まれています。CLIsのコンパクション、トークントリガー、およびルールの修正はcli-v3.0.63に含まれています。拡張機能とCLIの間でタスクを移動させる場合、リリースノートは各環境の挙動を個別に説明しているため、両方を最新にする必要があります。
各環境がどのバージョンであるかを書き留めておきましょう。来月、挙動に関する疑問が生じた際、それが最初に確認すべき事項になります。
ステップ 2: ディスクからルールのインベントリを作成し、パネルと比較する
パネルから始めてはいけません。Clineがドキュメント化している場所から始めて、実際に何が存在するかをリストアップします。
ワークスペースのルールは.clinerules/または.cline/rules/に配置できます。ドキュメントには「両方のディレクトリが存在する場合は両方が検索されるため、両方の場所にルールをコピーする必要はありません」と記載されています。グローバルルールはDocuments配下のCline Rulesフォルダに配置され、ドキュメントには「Clineはグローバルルールについて~/.cline/rulesおよび~/Cline/Rulesも検索します」と付け加えられています。Windowsでは、OneDriveにリダイレクトされたDocumentsの場所もチェックします。さらに、Clineは「~/.agents/AGENTS.mdからツール横断的なグローバルAGENTS指示を読み取ります」。
見つかったすべてのファイルをリストアップし、アップデートした拡張機能でRulesパネルを開いてチェックを入れます。アップデート後にディスク上に存在するにもかかわらずパネルに表示されないものがあれば、報告する価値があります。逆に、古いツールのファイルや数年前に書かれたグローバルルールなど、パネル内に予期しないものがある場合は、確認する価値があります。なぜなら、このリリース以前は、それらの一部がパネルに表示されることなくモデルに届いていた可能性があるからです。
OneDriveを使用しているWindows環境の場合は、もう1つ確認してください。依存しているグローバルルールが現在実際に適用されているかどうかです。ノートには、それらのルールが「まったく検出されていませんでした」とあるため、アップデート後に挙動が変化する可能性があります。
ステップ 3: 長期タスクを1回実行し、表示される内容を確認する
ClineのAuto Compactページには、目に見えるシグナルが記載されています。「これが発生すると、他のAPIコールと同様にコストを示す要約ツールの呼び出しが表示されます。」長期タスクを実行する際、これを探してください。Auto Compactをサポートするモデルでの長期タスクで容量が不足したにもかかわらず、要約の呼び出しが表示されない場合、それは修正が説明しているケースに該当します。報告する前に、バージョンとモデルを記録しておくとよいでしょう。
フックについては、フックが注入するコンテキストに無害なマーカー（日付を記載した1行など）を追加し、タスクの開始時にエージェントにそれを繰り返すよう求めてください。繰り返すことができれば、コンテキストは届いています。CLI経由でフックを実行している場合は、ノートにある「不活性なまま」の挙動を想定し、それに応じて計画を立ててください。
これら3つのチェックすべてに共通する一般的な原則は、auto-compact実行時に残すべきものに記載されているものです。つまり、長いセッションを生き残る必要のあるファクトを事前に決定し、要約によってドロップされない場所に配置することです。
MemoryLakeでの設定方法
上記の3つのチェックはすべて、エージェントが知っておくべきことについての、ツールの外部に保管された短い記録という1つの要素に依存しています。MemoryLakeは、特定のセッションでパネル、フック、または要約機能が正しく動作したかどうかに依存しないように、その記録を保管しておく場所です。
エントリーはご自身の言葉で作成します。Clineのルールフォルダ、タスク履歴、またはベンダーのストアから何かが読み取られたり、書き込まれたり、削除されたりすることはありません。
ステップ 1: APIキーを作成する
サインインし、ダッシュボードからキーを生成します。このキーにより、どのCline環境（拡張機能、デスクトップ、またはCLI）でタスクが実行されているかに関係なく、エージェントが作成したエントリーを読み取ることができるようになります。
ステップ 2: 最初の記憶をアップロードする
切り詰められた履歴が最初に失うであろうファクトから始めましょう。長期タスクの初期に行われた決定、フックが注入するはずだった制約、グローバルフォルダにあるハウスルールなどです。1つのエントリーにつき1つのファクトを、その理由とともに登録します。
ステップ 3: AIとエージェントを接続する
エージェントをワークスペースに向けます。これにより、すべてのタスクの開始時に決定事項を利用できるようになります。つまり、長いセッションで初期のターンが失われたとしても、重要な部分は維持されます。
実務における変化
実務における最初の変化は、パネルがどれほどの重要性を持つかという点です。アップデート後はより優れたインベントリになりますが、それでも依然として「ユーザーが意図した記録」ではなく「Clineが検出したもの」の表示に過ぎません。独自のリストを保持しておくことで、次の不一致をそのまま受け入れるのではなく、それに気づくことができるようになります。
2つ目は、長期タスクの読み方です。途切れた履歴と要約された履歴は、会話の内部からは似て見えることがあります。どちらもエージェントが開始時よりも少ない情報で作業することになるからです。違いは、初期の決定事項が生き残っているかどうかです。Clineがタスクの初期に何をしていたかを忘れてしまう現象を見たことがある人は、この症状に遭遇しています。今回のリリースはその原因の1つを特定しています。
3つ目は、Memory Bankの目的についてです。ClineのMemory Bankのガイダンスでは、「日常的なコンテキスト管理はAuto Compactに任せ」、手動の更新はチェックポイント用に予約することが推奨されています。このアドバイスはCline of Memory Bank設定ガイドでも繰り返されています。この役割分担は依然として理にかなっていますが、これらのバージョンより前のものについては注意が必要です。日常的なコンテキスト管理がドキュメントに記載されている通りに常に機能していたわけではないため、チェックポイントファイルが想定以上の負荷を担っていた可能性があります。
4つ目は、Clineの記憶セットアップを比較する方法です。すべてが正常に動作しているときの挙動だけでなく、その下のレイヤーで障害が発生したときに何が生き残るかによって、それぞれを評価してください。
長期タスクを生き残るべきコンテキストのベストプラクティス
ルールファイルの独自のインベントリを保持する。 パスのリストと、それぞれに対する1行の目的があれば十分です。これが、パネルが完全であるかどうかを判断する唯一の方法です。
症状が発生したバージョンを記録する。 同日に3つの環境で個別の修正がリリースされました。環境とバージョンを明記したレポートであれば、対応が可能です。
初期の決定事項は履歴以外の場所に保管する。 長期タスクの最初の1時間は、最も切り詰めの影響を受けやすい部分です。そこで決定され、タスクの残りの部分が依存するものはすべて、決定された時点で書き留めておくべきです。
注入されたコンテキストにマークを付け、届いたことを確認できるようにする。 フックの出力に日付入りの1行を追加するだけで、「フックは機能したか」という疑問を1ターンで解決できる質問に変えることができます。
機能を疑う前にモデルを確認する。 Clineのドキュメントには、Auto Compactが有効であっても、一部のモデルではルールベースの切り詰めにフォールバックすることが記載されています。それらのモデルにおける切り詰めは仕様であり、バグではありません。
エージェントが保持している記憶を定期的に再監査する。 AIが記憶している内容を監査するの背景にある習慣はここでも適用されます。唯一の信頼できるチェック方法は、エージェントに何を知っているかを尋ね、その回答を自身の記録と比較することです。
結論
Clineのv4.1.20のノート、およびそれと並行して公開されたデスクトップ版とCLIのノートは、リリースノートとしては珍しいほど具体的です。パネルが見落としていた場所、破棄されていたフックの結果、そして要約機能が失敗した正確な原因を名指ししています。また、そのギャップの1つが4月にまで遡ることも率直に述べています。
これらはすでに実行されたセッションを修復するものではありません。しかし、どこを確認すべきかのマップを提供してくれます。ディスク上のルールとパネルの比較、フックのコンテキストとエージェントが繰り返すことができる内容の比較、および長期タスクで表示されるべき要約の呼び出しです。
すべての環境をアップデートし、ディスクからインベントリを作成し、重要な決定事項は切り詰められた履歴に奪われない場所に保管してください。パネル、フック、要約機能はすべて、先週よりも今日の方が改善されています。自身で保持する記録こそが、それらのいずれかが再び誤った動作をしたときにそれを教えてくれるものです。