道具が半分になっていた日

夜、作業が進まなくなった。

会話が2分ごとに止まる。画面には「Compacting conversation…」とだけ出て、その間は何も打てない。1回や2回ではない。その日だけで23回。

止まっていた時間を合計すると、40分を超えていた。

最初に疑ったのは、自分だった

「何か入れたか」「設定を変えたか」。まずそこを疑う。当然だと思っていた。

心当たりはあった。その日の午前にプラグインを1つ入れている。前日には設定ファイルを触っている。犯人はこのどれかだろう、と。

結論から言うと、2回外した。

1回目。ツールの起動オプションが原因だと断定して、モデル指定を書き換えた。実測してみたら、その仮説を支える数字はどこにもなかった。差し戻した。

2回目。「修正はまだ反映されていない、再起動が要る」と説明した。ログを見たら、修正した瞬間から効いていた。再起動は不要だった。

どちらも、確かめる前に喋った。

「今日から」を数字で追う

外し続けたあと、ようやく正しい順番に戻った。

「今日から急に」と言われたら、まず日次推移を出す。 仮説より先に、いつ何が変わったかを確定させる。

セッションの記録を日付ごとに並べた。会話が強制的に圧縮されたタイミングと、そのときの会話量を全部拾う。

出てきた数字はこうだった。

8月19日までは82万を超えるまで動いていたものが、その日は16万台で止まる。しかも23回全部が、ほぼ同じ数字で発火していた。

人間の操作ミスなら、こんなに揃わない。機械的な閾値がどこかにある。

犯人は、自分が触っていない場所にいた

設定ファイルを全部あたった。auto-compactに関する項目は、どこにも書かれていなかった。書かれていない、ということは、デフォルト値で動いていたということだ。

だから設定は変わっていない。変わったのは、デフォルトの中身のほう。

見つけたのは、ツールがローカルにキャッシュしているサーバー配信フラグだった。538個ある。その中の1行。

tengu_hawthorn_window = 200000

会話の上限を200,000として扱う、という指定。その約84%が168,000。実測した発火点166,939〜170,648と一致する。

実際に使える上限は、その日も355,691まで伸びていた。上限そのものは変わっていない。壊れていたのは、いつ圧縮するかを決める計算だけ。

一行のフラグが上から降ってきて、作業机の広さが実質半分になっていた。通知はない。リリースノートもない。ローカルには何の痕跡も残らない。

「所有している」と思っていた

対処は簡単だった。閾値による自動圧縮を切る。それだけ。数秒で終わった。

問題は、そこじゃない。

自分が触っていない設定が、自分の知らないタイミングで変わる場所に、仕事の基盤を置いている。 これは今回に限った話ではない。AIを業務の中心に据えるというのは、そういう場所に住むということだ。

「We ship. We own.」と掲げている。作ったものは自分たちのものだ、と。

けれど今夜わかったのは、道具のほうは所有していないという事実だった。手元にあるように見えて、中身は上から書き換わる。

これはAnthropicが悪い、という話ではない。フラグを配る側には配る理由がある。段階的に挙動を変えるのは、大規模なサービスでは普通のやり方だ。

問うべきなのは、こちら側。自分の道具の中で何が起きているか、数字で言えるか。

言えなかった。だから2時間かかった。そして2回外した。

残ったもの

体感は正しかった。「今日から急に」という一言が、最後まで唯一の正しい手がかりだった。

正しくなかったのは、それを数字で確かめるより先に、原因を語り始めたほうだ。

道具の中身は見えない。せめて、見えていないことを知っておく。次に何かが半分になったとき、2時間ではなく10分で気づけるように。

診断の手順は記録に残した。同じことは、たぶんまた起きる。