v0.4.0.ja.md
docs/i18n/release-notes/v0.4.0.ja.md
Tesserae v0.4.0 — 抽出フィードバックループ、リサーチモード、デフォルト有効の進化
<!-- translations:start -->
English · 한국어 · 中文 · Русский · Español · Français · Deutsch
<!-- translations:end -->
リリース日 2026-05-26 · PyPI · GitHub release · pip install --upgrade tesserae==0.4.0
Tesserae 0.4.0 は、ナレッジベースをユーザーが修正でき、成長させられ、デフォルトで信頼できるものに変えます。目玉は抽出フィードバックループです。ユーザーが Obsidian ボールトで行った修正が型付きの FeedbackEvent として収集され、LLM が言語化したガイダンスにクラスタリングされ、次の抽出にフィードバックされることで、エンジンは同じ間違いを繰り返さなくなります。これと並んでリサーチモード（tesserae project research）が出荷されます — dzhng スタイルのエージェント的な 計画 → 検索 → 内省 → 統合 ループで、型付きの OpenQuestion / SessionHypothesis ノードを生成し、リサーチスレッドがコンパイルをまたいで生き残るようにします。v0.3.0 ではオプトインだった 2 つの進化パス — コミュニティ要約と散文-コードの discusses リンカー — がデフォルト有効になり、LLM バックエンドには一連の堅牢性修正が入ります（~/.claude* 認証情報の自動検出、Claude CLI 未ログイン時の優雅な処理）。すべて加算的で、破壊的変更はありません。
目次:
- 抽出フィードバックループ（機能 E）
- MD0 — エージェント的リサーチモード（機能 G）
- デフォルト有効の進化 — コミュニティ + インサイトリンク
- LLM バックエンドの堅牢性 + グラフビューの下地
- v0.3.0 からのアップグレード
- 戦略的文脈
1. 抽出フィードバックループ（機能 E）
何か
ユーザーと抽出器の間の閉じた修正ループです。Obsidian ボールトでノード本文を編集すると — 誤った型を直す、幻覚の事実を削除する、壊れた知見を書き直す — Tesserae のボールトオーバーレイがその編集を型付きの FeedbackEvent として重複排除された JSONL ストアに記録します。これらのイベントはクラスタリングされ、LLM が各クラスタを短い抽出ガイダンスとして言語化し（ノイズがルールにならないようネガティブフィルタ付き）、そのガイダンスがスライスされて次のコンパイルのプロンプトに注入されます。正味の効果: 一度行った修正は、再抽出のたびに適用し直す必要なく、再発が止まります。
ループには 4 つの可動部があります。
| 部分 | 役割 |
|---|---|
FeedbackEvent モデル + JSONL ストア | すべての修正の永続的で重複排除された記録。 |
| ボールトオーバーレイアダプタ | Obsidian ボールトをバックシンクする間に修正イベントを収集。 |
| ガイダンス構築（クラスタ + LLM 言語化） | 生の修正をキャッシュ可能で再利用可能なガイダンスに変換（フォールバックとネガティブフィルタ付き）。 |
| ガイダンスのレンダー/パース/スライス | ガイダンスを markdown にレンダーし、再びパースし、関連部分を各抽出プロンプトにスライス。 |
使い方
ループは通常のボールト往復に組み込まれています。Obsidian でノードを編集し、obsidian-sync（またはリフレッシュチェーン）を実行すると、修正は自動的に収集されます。次の tesserae project compile で、蓄積されたガイダンスが効きます。
# 1. Obsidian ボールトでノード本文を編集（型修正、幻覚の剪定）
# 2. ボールトをバックシンク — 修正が FeedbackEvent として収集される
tesserae project obsidian-sync
# 3. 再コンパイル — クラスタ化されたガイダンスが抽出に注入される
tesserae project compileいつ有効にするか
- ボールトを手で整えており、毎回のコンパイル後に同じ抽出ミスが再び現れることに疲れている場合。
- コーパスにドメイン固有の言い回しがあり、汎用抽出器が型を誤り続ける場合 — 数回の修正であなたの慣習を教えられます。
どこにあるか
中核実装: tesserae/feedback/（FeedbackEvent モデル、JSONL ストア、ガイダンスの構築/レンダー/パース/スライス）とボールトオーバーレイの収集パス。設計スペックと 7 タスクの TDD 計画は Codex とブレインストーミングされ、PR #20 でマージされました。
注意事項
- 決定的なベースライン抽出器は依然として LLM パスを通じてのみガイダンスを尊重します。LLM バックエンドがオフの場合、修正は記録されますがまだ再注入されません。（決定的パスでのガイダンス尊重は後続作業として追跡されています。）
- ガイダンスはキャッシュされます。修正パターンの大きな変化は、クラスタが再形成されるにつれて完全に反映されるまでにコンパイル 1〜2 回かかる場合があります。
2. tesserae project research — エージェント的リサーチモード（機能 G）
何か
コンパイル済みグラフに対して幅/深さ制限付きの 計画 → 検索 → 内省 → 統合 ループを実行し、引用付き markdown レポートを .tesserae/research/<slug>.md に書き込む新しい tesserae project research <query> サブコマンドです。dzhng のディープリサーチパターンをモデルにしていますが、オープンウェブではなく、あなた自身のナレッジベースに根ざしています。
重要なのは、ループが進行しながら型付きノードとエッジを生成するため、後続のコンパイルがリサーチスレッドを復元できることです。
- サブ質問ごとに 1 つの
OpenQuestion（フォローアップ用のmetadata.parent_question_idとderived_fromエッジ付き）、 - LLM が生成した仮説ごとに 1 つの
SessionHypothesis（依拠した証拠ノード id へのreferencesエッジ付き）、 - そして（
WebFetcherバックエンドが接続されている場合）ウェブ結果ごとに 1 つのSourceDocument。
すべてのバックエンドは Protocol 経由で注入されるため、ループはテスト下で完全に決定的であり、フェッチャーを接続しない限りネットワークに触れません。
使い方
tesserae project research "私たちの検索スタックは候補をどうランク付けするか？"
# → .tesserae/research/...md を書き込み、次のコンパイルで復元可能な
# OpenQuestion / SessionHypothesis ノードを生成ウェブ検索は v1 では意図的に見送られます。--no-web は WebFetcher バックエンドが出荷されるまで前方互換の no-op です。
いつ有効にするか
- 単一ノードのルックアップやフラットな
ask回答ではなく、あなた自身のグラフに対する引用付きの統合が欲しい場合。 - リサーチの質問と仮説をグラフノードとして永続させ、将来のセッションがそれを再質問する代わりにその上に積み上げてほしい場合。
どこにあるか
中核実装: tesserae/research/（LLMJsonClient、LLMWikiMCPServer.search_nodes、ResearchGraphBuilder、stable_id を再利用）。CLI 配線: tesserae/cli.py の research サブパーサ。12 のテストが 計画/検索/内省/統合、グラフ配線、max_iters 上限、プランナー/統合 の失敗フォールバックをカバーします。PR #18 でマージされました。
注意事項
- v1 はローカルグラフ上でのみ統合します。ウェブ層はフェッチャーバックエンドが着地するまで前方互換の no-op です。
- アトミックなディスク書き込みは
batch._write_manifestの PID + ランダム一時サフィックスパターンを使うため、並行リサーチ実行が衝突しません。
3. デフォルト有効の進化 — コミュニティ + インサイトリンク
v0.3.0 でオプトインだった 2 つのパスがデフォルト有効になり、追加のフラグなしで、すぐ使えるグラフがより豊かになります。
- コミュニティ要約（PR #14）— Louvain コミュニティ検出と LLM 要約が、フラグでゲートされる代わりにデフォルトコンパイルで実行されるようになりました。グラフはデフォルトでクラスタレベルの概要を備えます。
- 散文-コードの
discussesリンカー（PR #13）— v0.3.0 の機能 H インサイト-シンボルリンカー（TESSERAE_INSIGHT_SYMBOL_LINK）が v0.4.0 でデフォルト有効になり、環境変数を設定しなくてもセッションの知見がそれが言及するコードシンボルにリンクされます。（コーパスがコード議論の少ないほぼ散文の場合は明示的に無効化できます。）
意図は、最初のコンパイルがすでにコミュニティ概要と散文-コードエッジを持つグラフを生成し、各パスを発見してトグルすることをユーザーに要求する代わりに、「エージェントにすぐ渡せる自己改善型ベース」のミッションに合致させることです。
4. LLM バックエンドの堅牢性 + グラフビューの下地
LLM バックエンドへの一連の信頼性修正と、来たるグラフビューのスペック:
~/.claude*認証情報の自動検出（PR #19）— デフォルト LLM パスが~/.claude*ディレクトリ全体で Claude 認証情報を見つけ、デフォルトバックエンドの環境を埋めるようになり、マルチアカウントマシンでの初回セットアップが煩雑でなくなります。- 優雅な「Claude CLI 未ログイン」（PR #17）— Claude CLI がインストールされているが認証されていない場合、Tesserae はコンパイル途中でクラッシュする代わりに、実行可能なメッセージとともにきれいに降格します。
- PostToolUse sync-code hook（PR #15）— v0.3.0 の
SessionStartsync-code hook を補完し、セッション内のツール編集後にもコードグラフがリフレッシュされます。 - グラフビュー v1 スペック — HypePaper エンコーディングとノードドロワーを Tesserae サイトに移植する設計が Codex とブレインストーミングされ、スペック + 計画として着地し、続くビジュアルグラフ作業を準備します。
v0.3.0 からのアップグレード
pip install --upgrade tesserae==0.4.0アップグレードはこれだけです — v0.4.0 は破壊的変更のない加算的です。注意すべき 1 つの動作変更は、コミュニティ要約と散文-コードの discusses リンカーがデフォルトで実行されることです。以前それらがオフであることに依存していた場合は明示的に無効化してください。
マッスルメモリに加える新しい CLI サブコマンド:
tesserae project research "<質問>" # グラフに対するエージェント的 計画→検索→内省→統合デフォルト有効になった動作（以前はオプトイン）:
- コミュニティ要約（Louvain + LLM）。
- 散文-コードの
discussesエッジ（v0.3.0 のTESSERAE_INSIGHT_SYMBOL_LINKパス）。
それ以外のすべて — graph_ppr、ハイブリッド search_nodes、sync-code、ライブ SessionStart hook、embedding_status、fresh_insights、減衰スコアリング、supersedes、schema-drift、スラッシュコマンド、ウィキ / Obsidian 投影 — は v0.3.0 から変わりません。
戦略的文脈
v0.3.0 は散文の意思決定をそれを実装するコードシンボルに接続しました。v0.4.0 はベースが自らを修正し成長させ始めるリリースです。抽出フィードバックループは「ユーザーが一度直した」と「抽出器がそれを学習する」の間のギャップを閉じ、リサーチモードはエージェントがすでに存在するものを取り込むだけでなく、自身の型付きの質問と仮説でグラフを成長させられるようにします。コミュニティ要約と discusses リンカーをデフォルト有効にすることは、製品側から見れば同じテーマです — エンジンはユーザーにフラグを探させるのではなく、豊かなベースをエージェントに渡すべきです。
これは橋渡しのリリースです。v0.3.0 は型付きの散文-コードグラフを証明し、v0.5.0 は全体をオンデマンドコンテキストコンパイラを備えた継続実行エンジンに変えます。v0.4.0 は、*自己改善*の柱が最初の本物の界面（フィードバック修正、エージェント的リサーチスレッド）を得る場所で、それらすべてを継続的に実行させる v0.5.0 のスパインに先行します。
関連項目:
- v0.3.0 リリースノート — 散文-コードリンク、ポリグロットコードグラフ、ライブ同期
- コンテキストエンジンロードマップ — v0.5.0 が達成するフェーズ別計画
- コンテキストエンジン監査 — これらのリリースが閉じるギャップ分析
- アーキテクチャ概要 — モジュールマップとパイプライン
- MCP 統合 — 完全な MCP ツールリスト