NotebookLM→Obsidian自動化：
3ヶ月分のアップデートをまとめてリリース v4.1_ArtifactPromptFetch リリース

📚 Part 1：Obsidianを「眠った資産」から「活きたナレッジベース」に変える

v2_SingleFileでファイルの散乱や見出し崩れは解決しましたが、使い続けるうちに新しい課題が出てきました。

500本、1,000本と蓄積されたレポートの中から「先週の良いブログ記事どれだっけ」「あのプロンプト、どこ行った」を探すのが大変になっていったのです。 ObsidianにはDataviewという強力なクエリエンジンがあります。YAMLフロントマターを使えば、ノート群をデータベースのように検索・一覧表示できます。この改善に合わせて、ツールの出力設計をゼロから組み直しました。

デュアルファイル出力

1ノートブックにつき2種類のファイルを生成するようにしました。セッションファイル（目次・概要把握用）は生成されたレポートを[[Wikiリンク]]のみで参照し、個別レポートファイル（ナレッジの正本）は本文をそのまま格納します。

rating・highlight・memo はObsidianのプロパティパネルからGUIで入力でき、Dataviewクエリで「評価済みの優良レポート」だけを一覧表示できます。

レポートの生成プロンプトを自動抽出

良いレポートが出たとき、そのプロンプトを保存していなければ再現できません。各レポートの鉛筆（編集）ボタンを自動クリックしてプロンプト内容を取得し、YAMLにprompt:として保存するようにしました。モード1/2（生成）とモード7（回収）を別セッションで実行しても、プロンプトはキャッシュ経由で引き継がれます。

保存先設定の永続化

保存先フォルダをコード直書きではなく、起動時にパスを表示・変更できるようにし、settings.jsonに自動保存する設計に変更しました。

💻 Part 2：複数PCで設定が壊れる問題を解決

自宅PCと会社PCの両方でツールを使い始めたとき、次の問題に気づきました。

Part 1の設定ファイルはEXEと同じフォルダ（OneDrive同期対象）に保存していたため、PCごとに違うObsidianパスを設定しているのに、片方の設定がもう片方を上書きしてしまっていたのです。

解決策はシンプルで、設定ファイルの保存先をChromeプロファイルと同じ%LOCALAPPDATA%（マシン固有・OneDrive非同期）に揃えました。

あわせて、起動時の保存先確認を「初回のみ」に変更（2回目以降は自動スキップ）し、実行中のメニューから[s]でいつでも保存先を変更できるようにしました。

🛠️ Part 3：「Gemini Notebook」改変で発生したコピーループを解消

そして直近、Googleが NotebookLM を「Gemini Notebook」へ大幅リニューアルしました。これに伴い、ツールの回収（Harvest）処理がおかしな動きを始めました。

何が起きていたか

回収処理は、生成済みレポートの「コピー」ボタンを押してクリップボード経由で本文を取得する仕組みです。この「コピーボタンを探す」処理は、複数の候補セレクタを順番に試し、最初に見つかったものを使う実装になっていました。

Gemini Notebookになってから、画面右上に常設されている「ノートブックをコピーする」ボタン（ノートブック全体を複製する機能）も、レポートのコピーボタンと同じアイコンを使うようになりました。優先順位1番目のセレクタは条件を満たせば即採用されるため、本来使うべき一意なセレクタに辿り着く前に、このヘッダーボタンを掴んでしまっていたのです。

誤ってクリックすると「ノートブックをコピーする」という複製確認ダイアログが開きます。ツールはこのダイアログを認識できず、クリップボードの検証に失敗しては再試行し、そのたびに同じボタンを押し直す——これが「コピーというワードに反応してループする」ように見えていた正体でした。

v4.0の解決策

一意なセレクタを最優先にし、汎用セレクタには既知の誤爆先を明示的に除外条件として追加しました。

さらに、万一何かの拍子に誤ってダイアログが開いてしまっても実害が出ないよう、安全装置も追加しました。開いてしまった場合は「作成」を押さず必ず「キャンセル」で閉じます。

あわせて、レポート一覧の項目を開くクリック対象が<button class="artifact-item-button">から<div class="artifact-item-button">に変わっていた副次的なリグレッションも修正しています。

🔄 Part 4：プロンプト取得の仕組みを刷新（v4.1）

v4.0リリース直後、オーナーから2つの設計上の問題を指摘されました。プロンプトの取得は「生成時（Phase 1）に鉛筆アイコン経由で事前収集し、%TEMP%にキャッシュしておき、回収時（Phase 2）はキャッシュを読むか、無ければ同じダイアログを開き直して収集し直す」という2段構成でした。

何が起きていたか

実際にあるノートブックで、コピーループのバグにより回収（Pass 2）が失敗したにも関わらず、プロンプトのキャッシュだけは「Pass 1完了直後」に削除される実装だったため消えてしまっていました。しかも、キャッシュが無い場合のフォールバックは「レポートを作成」ダイアログを再度開いて鉛筆アイコンから収集し直す仕組みでしたが、Gemini NotebookのAIは「おすすめの形式」をダイアログを開くたびに違う内容で再提案します。つまり後から再収集すると、実際に生成に使われたプロンプトとは別内容を誤って紐付けてしまう構造的な欠陥がありました。

v4.1の解決策

調査の結果、各アーティファクトのケバブメニュー（「その他」）に「プロンプトとソースを表示」という項目があり、これはそのアーティファクト固有の、実際に生成に使われた確定済みプロンプトを、生成からどれだけ時間が経っていても正確に返すことを確認しました。

これにより、Phase 1での鉛筆アイコン経由の事前収集（約94行）と、回収時のダイアログ再収集フォールバック（約290行）、そして%TEMP%キャッシュの読み書きを丸ごと廃止できました。回収（Harvest）はいつ実行しても、常にそのアーティファクトの実際の生成プロンプトを正確に取得します。