Qwen Code が実際に公開したもの
9月20日に2つのプルリクエストがマージされ、同日午後に v0.24.2 としてリリースされました。
1つ目は /context detail の出力を変更するものです。アクティブな拡張機能に属するコンテキストファイルは、拡張機能名の後にファイル名が続く形式（例：Extension: Report Tools · QWEN.md）で表示されるようになりました。拡張機能の所有者がいないファイルは、従来通りのパスが維持されます。その理由は率直に述べられています。以前は拡張機能のコンテキストファイルが「インストールディレクトリ配下のパスとして表示されていたため、どの拡張機能がそのコストを支払っているのかが読者に伝わらなかった」ためです。
2つ目は、拡張機能が指示を提供する仕組みそのものの変更です。拡張機能は、パス条件付きのルール（path-conditional rules）を提供できるようになりました。これは、作者が「ファイル固有のガイダンスを、常に読み込まれるコンテキストファイルから移動させる」ための方法として説明されており、これにより「起動時に送信されるのではなく、一致するファイルがアクセスされたときに注入される」ようになります。これに伴い、拡張機能ガイドにはそのコストに関する一文が全文掲載されています。
「拡張機能のコンテキストファイルは、その拡張機能がアクティブなすべてのセッションのすべてのリクエストのシステムプロンプトに結合されます。現在行っている作業がその拡張機能と関係があるかどうかは関係ありません。関連性によるフィルタリングはなく、サイズ制限もありません。」
この一文の背景にある測定結果は、プルリクエストが参照している追跡イシューに記載されています。あるサンプルセッションでは、「9つの拡張機能のコンテキストファイルが合計 9,989 トークンに達した」とのことです。対照的に、同じセッションのスキル一覧は 84 個のスキルで合計 4,620 トークンでした。なぜなら、スキルは名前と説明のみで一覧化され、呼び出されたときにのみその本体が読み込まれるためです。
また、新しい警告も追加されました。Qwen Code は、常にオンになっているコンテキストの総量が、モデルのウィンドウから算出されるしきい値（推定 10,000 トークンを上限とする）を超えた場合に警告を表示するようになりました。プルリクエストでは、この警告の性質について慎重に説明されています。「これは警告であり、切り捨て（truncation）や拡張機能ごとのクォータ制限ではありません。」
これが変えること、変えないこと
これ自体が何かを削減するわけではありません。プルリクエストには直接こう書かれています。「条件付きの代替手段を提供しても、拡張機能の作者が実際に適切なガイダンスをそこに移行しない限り、常駐するコンテンツは削減されません。」仕組みは新しいものですが、移行は自動的には行われません。作者自身の言葉を借りれば、「既存のコンテキストファイルは自動的には移行されません。」
したがって、アップデートしたその日も、インストールされているすべての拡張機能は、前日とまったく同じ内容を送信し続けます。変わったのは、項目化されたリストを確認できるようになったこと、そして拡張機能の作者が情報を配置するより良い場所を手に入れたことです。
さらに2つの詳細について、意図ではなく挙動を説明しているため、注意深く読む価値があります。
拡張機能のルールには、フロントマターに paths: エントリを含める必要があります。これがないルールは「警告付きでスキップされます」— サイレントに常にオンのルールになることも、サイレントに消滅することもありません。ルールは「拡張機能の所有者によってラベル付け」され、これは新しい表示領域に適用されたものと同じ属性付与の考え方です。
また、プルリクエストが明白に述べているように、信頼の処理において非対称性があります。「インストールされた拡張機能のルールは、ワークスペースの信頼（workspace trust）による制限を受けません。これは既存の拡張機能コンテキストの境界と一致しています。一方で、プロジェクトのルールは引き続き信頼の制限を受けます。」インストールした拡張機能は、すでにあなたが保証したものとして扱われますが、開いたばかりのリポジトリにあるルールファイルはそうではありません。これは見落としではなく意図的な境界線であり、拡張機能ガイドが「そもそも拡張機能に何を含めるべきか」について1段落を割いて説明している理由でもあります。
人々が誤解しがちなこと
最初に広まる解釈は「Qwen Code に拡張機能のコストを表示するコマンドが追加された」というものでしょう。これは事実ですが、あまり有用な情報ではありません。なぜなら、そのコマンドはすでに存在していたからです。/context detail は以前から、メモリファイルを1行に1ファイルずつリストアップしていました。できなかったのは、その行がどの拡張機能に属しているかを示すことでした。
2つ目の解釈は、より有害なものです。それは「このリリースによって拡張機能が軽量化される」という誤解です。そうではありません。条件付きルールのルートは拡張機能の作者に提供されただけであり、作者がガイダンスをそこに移行するまでは、手元にあるファイルは結合され続けます。拡張機能を無効化する以外に、自身のプロジェクトで何を行ってもそれを変えることはできません。
3つ目の誤解は、1段落を割いて説明する価値があります。「常にオンの指示が問題であり、すべてを条件付きにすべきだ」と結論付けたくなるかもしれません。しかし、ガイドはそうは言っていません。ガイドが推奨しているのは、「コンテキストファイルは、常に真であるいくつかの事実（拡張機能のアイデンティティ、語彙、厳格な制約など）に留め、シナリオごとのガイダンスは代わりにスキルに配置する」ことです。いくつかの事実は本当に常に真です。失敗の本質は、常にオンのコンテキストが存在することではなく、シナリオごとのガイダンスが「常に真である事実」であるかのように分類され、システムの誰もそれを教えてくれなかったことにあります。
この区別は、長いコンテキストウィンドウがメモリと同じではない理由の背後にあるものと同じです。ウィンドウが大きくなっても、入るものが変わるだけで、そこに置くべき価値があるものが変わるわけではありません。
解決策：項目化されたリストを読み、何が「常に真である事実」かを判断する
拡張機能の作者に代わって、その拡張機能のコンテキストファイルを移行することはできません。しかし、自分が何を抱え込んでいるかを把握し、自分自身のもののうち何が「常にオン」のレイヤーに属するかを判断し、残りを移動させることはできます。
ステップ 1：変更を加える前に、項目化されたリストを確認する
実際に作業しているプロジェクトでセッションを開き、1ターン進めた状態で、詳細なコンテキストの内訳を実行します。特にメモリファイルのセクションを確認してください。v0.24.2 以降、拡張機能が所有する各ファイルには拡張機能の名前が表示されるため、パスのリストではなく、所有者のリストが得られます。
ツールの外部に、各名前の横にファイルサイズを添えてリストを書き留めておきます。後でこれと比較することになります。内訳自体はセッションによって変化する動的な情報だからです。
この時点で、通常2つのことに驚かされます。1つは、分布が不均一であることです。サンプルセッションでは、2つの拡張機能が拡張機能全体の約3分の1を占めていました。もう1つは、最もコストをかけている拡張機能が、必ずしも最も頻繁に使われている拡張機能ではないということです。
ステップ 2：自分自身の「常に真である事実」と「シナリオガイダンス」を分離する
次に、あなた自身の行（プロジェクト独自の指示ファイルや、そこから参照しているもの）を確認します。各行を次の2つのバケットのいずれかに分類します。
常に真：プロジェクトの名前と目的、ビルドおよびテストコマンド、触っている場所に関係なく適用される制約、ツールが誤解しがちな語彙。これらは常にオンのファイルに属し、通常は想定よりも短くなります。
時々のみ真：決済モジュールの作業方法、マイグレーションディレクトリの規約、リリースのチェックリスト。これらはシナリオガイダンスです。Qwen Code 自体の推奨事項は「スキル」です。スキルは名前と説明でリストされ、呼び出されたときにその本体を読み込みます。さらに、ファイルパスで制限されたスキルは「一致するファイルが触られるまでリストにすら表示されません」。
この分類は、あなたが実際に何を作っているかに依存するため、誰も代わりにやってくれません。しかし、これは効果を発揮し続ける作業です。なぜなら、この分類こそがエージェントに指示ファイルを読ませるための秘訣だからです。本当に常に真である事実だけをまとめた短いファイルは、長いファイルよりも確実に遵守されます。
ステップ 3：書き留めたリストと内訳を再確認する
同じプロジェクトで詳細な内訳を再度実行し、ステップ1で書き留めた内容と1行ずつ比較します。確認することは2つです。移動した行が「常にオン」のレイヤーから消えていること、そして拡張機能の行が変更されていないことです（これらには触れていないため、移動していないはずです）。
もし全体の警告が表示されている場合は、どの所有者がそれを引き起こしているかに注目してください。それが拡張機能の作者に伝えるべきリストであり、今や曖昧な表現ではなく、正確に提示できるリストになっています。
この記録は手元に残しておいてください。インストールされている拡張機能が次回アップデートされた際、あなたに知らせることなくコンテキストファイルを変更する可能性があり、それに気づく唯一の方法は、昨日の数値を把握しておくことだからです。
MemoryLake での設定方法
ステップ2での分類により、耐久性のあるものが生まれます。セッションをまたいで真である短い事実のセットと、特定の状況でのみ真となる長い事実のセットです。MemoryLake は、前者のセットを保持し、今月たまたま使っているツールが変わってもそれを維持するための場所です。
エントリはあなた自身が自分の言葉で記述します。Qwen Code 独自のメモリフォルダ、拡張機能のインストールディレクトリ、またはベンダーのストアから何かが読み取られたり、書き込まれたり、削除されたりすることはありません。
ステップ 1：API キーを作成する
サインインし、ダッシュボードからキーを生成します。このキーにより、エージェントがあなたが作成したエントリを読み取れるようになります。キーは特定のプログラマやCLIではなく、ワークスペース全体に紐づきます。
ステップ 2：最初の記憶をアップロードする
上記のステップ2で作成した「常に真」のリストから始めます。プロジェクトの目的、コマンド、触っているものに関係なく適用される制約などです。各エントリは、新しい同僚に説明するような表現で、1つの事実に留めてください。
ステップ 3：AI とエージェントを接続する
エージェントをワークスペースに紐づけます。これにより、どこで作業していても同じ短い事実のセットを利用できるようになります。つまり、ツールを変更したときに事実が失われることなく、プロジェクトの指示ファイルを短く保つことができます。
実務における変化
実務上の変化は、「割合」から「リスト」への移行です。このリリース以前は、「プロンプトのどれくらいが拡張機能で占められているか」に対する誠実な回答は、名前のない単なる数値でした。今では、確認可能な所有者のセットであり、自身のファイルとは別に個別に対処できるセットになりました。
これは見た目以上に重要です。なぜなら、この2つのグループには異なる対処法があるからです。あなた自身の「常にオン」のコンテンツは、今日にでも短縮できます。拡張機能のコンテンツは作者が移動させるべきものであり、あなたができる最も有用なことは、どのファイルがどれくらいのサイズであるかを正確に伝えることです。
また、増大するコンテキストコストの見え方も変わります。ウィンドウをほとんど消費していないように見えるセッションであっても、すべてのリクエストに大きな固定のプレフィックスが乗っている可能性があります。プレフィックスは絶対的なものであり、ウィンドウの消費量は相対的なものだからです。構成を意識せずにトークン使用量だけを監視してきたチームは、項目化されたリストを見ることで、まずこの固定部分に気づく傾向があります。そして、コスト削減は、毎回送信するのをやめたものから得られるのであり、ウィンドウを大きくすることから得られるわけではありません。
もう1つ言及しておくべき結果として、ツール間を移行する場合、「常に真」のセットはきれいに引き継げる部分であるということです。シナリオガイダンスは通常、特定のツールの制限メカニズムの語彙で表現されるため、移行時にそのまま維持されることは稀です。これは、モデルを変更する際にコンテキストが自動的に引き継がれると仮定せず、意図的に移行する必要があるのと同じ理由です。
常にオンのレイヤーを小さく保つためのベストプラクティス
拡張機能をインストールする前と後に必ず確認する。 項目化された内訳は低コストで実行でき、インストールによって何が追加されたかを示す唯一の記録です。事前の状態がなければ、事後の状態から何も判断できません。
「常に真」のリストは、ツールが書き換えられない場所に書く。 拡張機能のファイルはアップデート時に変更されます。あなた自身のファイルは、あなたが編集したときに変更されます。その両方の外部に記録を保持しておくことで、どちらが変更されたかを特定できます。
動作する範囲で最も狭い伝達手段を優先する。 ファイルパスで制限されたスキルは、一致するファイルが触られるまでリストされません。制限のないスキルは名前と説明でリストされます。コンテキストファイルは常に全文が送信されます。このリストを下に進むほどコストが高くなるため、下から始めて、本当に毎回適用される場合にのみ上に移動してください。
拡張機能は機能リストではなく、プロンプトに常駐させる内容で評価する。 週に一度しか使わない便利な機能を提供しつつ、長いコンテキストファイルを送信し続ける拡張機能は、その間のすべてのリクエストでコストを支払っています。それが妥当なトレードオフである場合もありますが、それは自覚的な決定であるべきです。
作者に特定のファイルを要求する。 行にラベルが付いたことで、一般的な懸念を説明するのではなく、拡張機能名とサイズを指定して要望を出せるようになりました。作者にはガイダンスを条件付きルールに移行するためのドキュメント化されたルートが用意されており、正確なレポートこそがその移行を促す動機になります。
カタログ変更後に再確認する。 拡張機能カタログが更新されると、目に見えるイベントなしにインストール済みやアクティブな状態が変化することがあります。これは、カタログにあるはずのスキルが静かに欠落している問題と同じ種類の問題です。
結論
新しい属性行は、出力における小さな変更ですが、把握できる情報においては大きな変化です。初めて、「どの拡張機能がこれをプロンプトに入れたのか」に対する答えがパスではなく名前になり、コストのかかる構成を推奨していたガイドが、そのコストについて明記するようになりました。
これ自体が何かを短縮するわけではありません。条件付きルールのルートは拡張機能の作者がそれを使用するかにかかっており、あなた自身の「常にオン」のファイルはあなたがそれを整理するかにかかっています。このリリースが提供するのは「可視化」であり、書き留めた記録こそが、単に不満を言うだけの請求書と、項目ごとに精査できる請求書の分かれ目になります。
まずは内訳を確認し、自身の行を「常に真」と「時々真」に分類し、「常に真」のセットは現在のツールよりも長生きする場所に保管してください。呼び出し可能なスキルは記憶ではありません。これはすべてを1つにまとめる前に明確にしておく価値がある事実であり、送信していることを忘れてしまったコンテキストファイルも同様です。