Tesserae v0.28.3 — 抽出器の1ターン上限と、それが静かに奪っていたもの

<!-- translations:start -->

English · 한국어 · 中文 · Русский · Español · Français · Deutsch

<!-- translations:end -->

Released 2026-07-31 · PyPI · GitHub release · pip install --upgrade tesserae==0.28.3

フラグひとつ。最初のパイプラインコミット以来 Claude 抽出器に入り続けていたもので、 MCP サーバーが設定されたマシンでは LLM 抽出をまったく機能させなくしていた——しかも コンパイルは失敗させないまま。

--max-turns 1 は決定された選択ではなかった

Claude CLI の呼び出し箇所は2つとも次を実行していた：

claude -p --output-format text --max-turns 1

--max-turns が数えるのは応答ではなくツール呼び出しだ。CLI の設定ディレクトリに MCP サーバーやフックがあると、モデルの最初の動作がツール呼び出しになりうる——その 時点で唯一のターンが尽きる。CLI は JSON を1バイトも出さないまま Reached max turns (1) で exit 1 する。

Tesserae はこれを捕捉して決定論的抽出にフォールバックする。プロバイダの障害が コンパイル全体を中断させてはならないからだ。結果、コンパイルは成功し、グラフは それらしく見え、LLM は何も寄与していなかった。

このフラグが選ばれたことは一度もない。最初のパイプラインコミットとともに入り、3か月後 ClaudeCLIJsonClient がそのまま複製した——docstring に「run_claude_cli のパターンを 踏襲する」と書かれているからだ。どのコミットメッセージにも言及はない。

ワンショットの本当の意味は --strict-mcp-config だ

ターン上限の意図は「一度だけ答え、エージェントループを回すな」だった。それを正しく 表現する方法は、MCP サーバーを一切ロードしないことだ。そうすればターンを消費する ツール自体が存在しない：

claude -p --output-format text --strict-mcp-config

モデルの最初の応答がそのまま答えになり、設定済みの MCP サーバーが呼び出しを飢えさせる ことはもうない。両方の呼び出し箇所を修正し、回帰テストがそれぞれでターン上限が 復活しないことを検証する。

これがグラフを奪っていたか確認する

この失敗はコンパイルのサマリーには現れない。ログにしか残らない：

grep -c 'Reached max turns' <コンパイルログ>

0 より大きければ、それらのファイルは決定論的に抽出されていたということで、この バージョンで再コンパイルすれば回復する。本プロジェクト自身のグラフでは、本物の LLM 抽出を取り戻したところノードが 5,155 から 13,182 に増えた——決定論的フォールバックが グラフのおよそ 60% を奪っていた計算になる。

大半のファイルで LLM 抽出を失いながらコンパイルが成功を報告する点は別個の欠陥で、 #92 で追跡中であり、本リリース では修正されていない。今回は静かなフォールバックの原因をひとつ取り除いただけで、 その静けさ自体は残っている。

v0.28.2 からのアップグレード

そのまま差し替えられる。API・スキーマ・設定の変更はない。以前のコンパイルが影響を 受けていたなら、再コンパイルして取りこぼした抽出を回収してほしい—— ~/.tesserae/llm_cache のキャッシュ済み LLM 応答は再利用されるので、コストが かかるのはフォールバックしたファイルだけだ。