研究作業の大半は、考えることではなく、読むこと、抽出すること、そして相互参照することです。それを手動で、一度に一つの情報源から行っており、本来考えるために使うべき時間を奪っています。
Opus 5 は、そのために作られたという点で、この計算式を変えます。Anthropic はこれを Opus 4.8 と同じ価格、つまり入力 100 万トークンあたり 5 ドル、出力 100 万トークンあたり 25 ドルでリリースしましたが、Frontier-Bench v0.1 のスコアは Opus 4.8 の 2 倍以上です。これは、Anthropic の最も賢いモデルとして位置づけられているわけではなく、その座は依然として Fable 5 です。日常的な使用のために作られたモデルとして位置づけられており、その効率性は、単一のベンチマークの見出しでは決して捉えきれない、何千もの呼び出しにわたって複利的に効いてきます。法律 AI 企業の Harvey は、Opus 4.8 の最大推論出力品質を維持しながら、平均トークン使用量を 26% 削減したと、独自に報告しています。
この効率性のプロファイルこそ、まさに研究パイプラインに必要なものです。あなたは、高価なクエリを 1 回だけ実行するのではありません。増え続ける情報源に対して、毎週、何十もの抽出と合成のパスを実行しており、ボリューム向けに作られたモデルを使わなければ、パスあたりのコストはすぐに跳ね上がります。
これが完全なシステムです。Obsidian が永続的なストレージ、Opus 5 が処理エンジン、そして特定のパイプラインが生の読書資料を自動的にリンクされた検索可能な知識に変換し、手動での抽出と相互参照に費やしていた時間をあなたに還元します。
なぜ Opus 5 がこの仕事に特に適しているのか
構築に入る前に、このシステムがなぜ Opus 5 を使用し、Fable 5 ではないのかを正確に理解しておく価値があります。この特定の仕事に間違ったモデルを選ぶことは、このようなシステムで予算超過を引き起こす最も一般的な原因だからです。
毎週情報源を取り込む研究パイプラインは、多数の個別のモデル呼び出しを実行します。新しい情報源ごとの抽出、既存のメモとの相互参照、定期的な合成パス、ダイジェストの生成などです。これはボリュームワークであり、単発の深掘り作業ではありません。Opus 5 のポジショニング全体は、まさにこのプロファイルを中心に構築されています。同じ価格で Opus 4.8 の 2 倍以上の Frontier-Bench スコアを達成し、Harvey によって繰り返しの類似タスクで独立して検証されたトークン効率の向上を実現しています。
Fable 5 は、本当に最も難しい単一の研究質問に対しては依然としてより良い選択肢です。微妙な点を間違えることが現実的な結果を招く、繊細でハイステークスな合成や、約 2 倍のトークン単価を正当化する、より深い SWE-Bench に類する推論深度が必要な場合です。研究システムの構築と維持というルーチンワーク、つまり毎週の取り込み、継続的な抽出、ダイジェスト生成には、Opus 5 の効率性重視の設計が正しいデフォルトであり、Fable 5 は、システムがより詳細な調査に値すると判断した、時折発生する深掘り質問のために予約されます。
基盤：永続的なストレージとしての Obsidian
システムには、永久に存続し、完全にあなたのものであり、決して単一のモデルやプロバイダーに依存しない知識の保管場所が必要です。Obsidian ヴォールト内のプレーンなマークダウンファイルが、まさにこれを実現します。来年、より良いモデルが登場したら、そのモデルを同じフォルダに向ければよく、他に何も変える必要はありません。
研究システムに有効な構造は、一般的な raw と wiki のパターンを基に、以下のようになります。
取り込まれたままのソース資料（PDF、記事テキスト、動画の文字起こし、未処理のもの）を格納する raw フォルダ。
処理済みでリンクされた、知識の永続的なバージョンを、情報源ではなくトピックごとに整理して格納する wiki フォルダ。
研究システムに特化した questions フォルダ。読書中に浮上した、まだ解決されていない未解決の質問を保持します。これにより、処理中に本当に重要なことが失われるのを防ぎます。
digests フォルダ。Opus 5 が生成する毎週のサマリーをタイムスタンプ付きで保持します。これにより、すべてを再読することなく、任意の週に何が重要だったかを振り返ることができます。
ルートに 1 つの CLAUDE.md ファイル。このシステムがどのように動作すべきかを正確に定義します。これについては次のセクションで詳しく説明します。
システムを動かす CLAUDE.md
これは、セットアップ全体の中で最もレバレッジの効いた単一のファイルです。Opus 5 がすべてのセッションの開始時に自動的にこれを読み取るため、システムを使うたびに説明を繰り返す必要がなく、一度指示を書くだけで済みます。
研究システムプロトコル
このヴォールトは研究システムです。構造：
/raw - 取り込まれたままのソース資料、決して編集しない
/wiki - 処理済みでリンクされた知識、トピックごとに整理
/questions - 未解決の未解決の質問
/digests - 毎週のサマリー、タイムスタンプ付き
新しい情報源が /raw にドロップされた場合：
- 文書全体の要約ではなく、具体的で真に新しい主張や発見を抽出する。
- 同じトピックに関する既存のメモがないか /wiki を確認する。トピックが既に存在する場合は、重複を作成するのではなく、既存のメモを拡張する。
- 新しい主張はすべて、[[wikilinks]] を使って関連する既存のメモにリンクする。
- 情報源の主張が /wiki の既存の内容と矛盾する場合、黙って上書きしない。両方のメモで矛盾を明示的にフラグする。
- 情報源が、ヴォールト内の他の資料から解決できない真の未解決の質問を提起した場合、答えを推測するのではなく、/questions に追加する。
合成やダイジェストの生成を求められた場合：
/raw から直接ではなく、/wiki からプルする。Wiki は処理済みで
信頼できるレイヤーです。Raw ソースには、後で誤りや
陳腐化が判明した主張が含まれている可能性があります。そのため、上記のステップ 4 が存在します。
抽出が完了したと報告する前に、これが完全に新しい
資料であると仮定するのではなく、関連する既存のメモがないか
実際に /wiki を確認したことを確認する。
この単一のファイルが、バラバラのメモのフォルダと実際のシステムとの違いを生み出します。その中のすべての指示は、重複メモ、黙って上書きされた矛盾、静かに見落とされた未解決の質問など、長期間の使用で見えないうちに蓄積される特定の、実際の障害モードを防ぐために存在します。
取り込みパイプライン
ヴォールトが構造化され、プロトコルが記述されたので、実際の毎週のワークフローは次のとおりです。
週の間に遭遇した情報源を、読んだ記事、研究論文、ポッドキャストの文字起こし、動画の文字起こし、競合他社のブログ投稿など、そのまま /raw にドロップします。これは数秒で済むべきであり、数分かけてはいけません。その要点は、キャプチャから摩擦を取り除き、一貫して実行できるようにすることです。
まだ処理されていない /raw 内の新しいファイルを取り込む。
それぞれについて、真に新しい主張を抽出し、/wiki で関連する
既存のメモを確認し、適宜メモを拡張または作成し、既に記録されている内容との矛盾をフラグする。
未解決の質問は、推測するのではなく /questions に追加する。
これは、実際の読書パターンに合った任意の頻度で実行します。常に読んでいるのであれば毎日、情報の入力が散発的であれば数日おきに実行します。重要なのは、処理が情報源をキャプチャしたタイミングに近いことと、10 個の情報源のバッチを一度に個別の抽出と相互参照のパスに分解する作業こそが、Opus 5 の効率性プロファイルが構築されているまさにその種の反復的で類似した形状の作業であることです。
毎週のダイジェスト、自動化
ここで実際の時間節約が最も顕著に現れます。これは、手動で実行することを覚えておくタスクではなく、スケジュールされたタスクとして設定する価値があります。システムの要点は、機械的な部分からあなた自身をループから外すことだからです。
今週の研究ダイジェストを生成する。/wiki からプルし、特に
過去 7 日間に追加または更新されたものに焦点を当て、ヴォールト全体の
履歴には焦点を当てない。
構造：
- 今週の最も重要な新しい発見 3 ～ 5 つと、/wiki の完全なメモへのリンク。
- 今週、新しい資料と既存のメモの間でフラグされた矛盾。これらはあなたの直接の注意を必要とするため。
- 今週 /questions に追加された未解決の未解決の質問。
- 今週異常に活発だったトピックを一言。多くの関連メモが急速に蓄積されているトピックは、受動的な蓄積ではなく、より深く意図的な注意を払う価値があることが多いため。
結果を今週の日付で /digests に保存する。ダイジェスト全体は
500 語未満に抑える。これは完全なメノへのポインタであり、
メモを読む代わりにはならない。
これを毎週の初めに自動的に実行するようにスケジュールします。そうすれば、自分でメモを 1 つも開く前に、重要だったすべての要点をまとめた短く構造化されたサマリーがあなたを待っています。これこそが、システムが何時間もの手動読書を置き換える直接的なメカニズムです。あなたはもはや、何を学んだかを思い出すために 1 週間分の生の資料を読み返す必要はありません。2 分で読める 500 語のポインタを読むだけで、同等の手動レビューにかかる 2 時間の代わりになります。
覚えていることだけでなく、すべてを横断してクエリする
ダイジェストとは別の、もう 1 つの主要な時間節約は、答えがどの特定のメモにあるかを思い出そうとするのではなく、蓄積された知識ベース全体に対して真の質問をできることです。
/wiki のすべてに基づいて、[特定のトピック] について私が学んだことは何ですか？
各主張の出典となる特定のメモを引用してください。ヴォールト内の情報源が
このトピックについて互いに異なる意見を持っている場合は、1 つを選んで
合意として提示するのではなく、明示的にそのように述べてください。
これこそが、システムが長く実行されるほど複利的に効いてくる見返りです。1 か月目は、wiki は薄く、この種のクエリは数件のメモを返すだけです。6 か月目には、数十の情報源が処理され相互リンクされているため、同じクエリは、手動では決して行わなかったであろう真のつながりを明らかにします。2 週目に読んだ論文のアイデアが、20 週目のまったく異なる情報源の何かと直接結びつくのです。なぜなら、両方が同じ基礎となるトピックの下にファイルされ、それに応じてリンクされているからです。
矛盾に正直に対処する
自分のメモを記憶から読み返すだけよりも、このシステムの具体的で過小評価されている価値の 1 つは、何かに対する自分の理解が時間の経過とともに変化したときに、それを積極的に表面化することです。かつて持っていた古い信念を、単に持っていたことさえ忘れたという理由だけで、異議を唱えられないまま放置することはありません。
取り込みプロトコルが矛盾をフラグしたとき、つまり新しい情報源の言うことと既存のメモの主張との間で、システムに単に新しい方やより権威のある方を選ばせて静かに解決させたいという衝動に抵抗してください。矛盾を表面化する価値は、それがあなたに実際の決断を強いることです。以前の情報源が間違っていたのか、根底にある現実が実際に変わったのか、それとも両方が正しいが、メモに追加する必要があるコンテキストに依存するケースなのか。その判断を自動化してしまうと、時間の経過とともにより厳密な思考を促すシステムを構築するという目的そのものが損なわれます。
1 か月間の実際の使用例
複合効果を具体的にするために、実際の 1 か月間の使用でこれがどのように展開されるかを大まかに示します。
第 1 週、あなたは調査中のプロジェクトに関連する 6 つの記事をドロップします。取り込みパスにより、/wiki に 8 つの新しいメモが作成されます。いくつかの記事は複数の異なるトピックに触れているため、実際の関係が存在する場合、それらはすべて相互にリンクされます。まだ相互参照する以前の資料が多くないため、ダイジェストは短くなります。
第 2 週、さらに 4 つの情報源を追加します。そのうちの 2 つは、新しいメモを作成するのではなく、第 1 週の既存のメモを拡張します。取り込みプロトコルがトピックの重複を正しく識別したためです。1 つは矛盾をフラグします。第 2 週の情報源からの主張が、第 1 週の情報源が自信を持って述べたことを直接否定するものです。ダイジェストはこの矛盾を顕著に表面化し、それをレビューした結果、第 1 週の情報源が古いデータに基づいて作業していたことに気づきます。あなたはそのメモを直接更新し、修正とその理由を記録します。
第 3 週と第 4 週もこのパターンが続き、月末までに、トピック全体に対するクエリは、修正を含む、あなたの理解の実際の進化をたどる合成を返します。まるで初日から正しい答えを知っていたかのような静的なスナップショットではありません。
これが具体的に述べられた実際の価値提案です。システムがあなたの代わりに考えてくれるというわけではなく、抽出、相互参照、既に知っていることを思い出すといった、毎週あなたの実際の思考時間と競合していた機械的なオーバーヘッドを取り除くということです。
このシステムを損なうよくある間違い
これを設定する際に繰り返し見られる、いくつかの特定の間違いがあります。事前に知っておく価値があります。
CLAUDE.md プロトコルをスキップして、Opus 5 が正しい動作を理解するだろうと期待して、単にファイルを raw にドロップする。 明示的な指示、特に重複作成前の確認ルールと矛盾に対するフラグ・サイレント上書き禁止ルールがないと、システムは、それが避けるために作られたまさにその構造化されていない AI 生成メモの山に退化します。
ヴォールト全体に対してダイジェストを実行し、特定の週のアクティビティに対して実行しない。 これにより、ダイジェストは毎週長くなり、有用性が低下します。なぜなら、既に何度も読んで処理した資料を再要約することになり、本当に新しいものだけを表面化しないからです。
Opus 5 の合成を、出発点としてではなく、自動的に正しいものとして扱う。 モデルはここで実際の認知作業、つまり成長する知識ベース全体にわたる抽出と相互参照を行っており、他の認知作業と同様に、あなた自身のレビュー、特にそれがフラグする矛盾から恩恵を受けます。矛盾はまさに、あなた自身の判断が最も価値を加える瞬間です。
習慣で、より高価なモデルが常に安全な選択であると想定して、ルーチンの毎週の処理に Fable 5 を使用する。 このシステムが毎週生成する、反復的で類似した形状の抽出と合成作業の量に対しては、Opus 5 の効率性プロファイルの方が適しており、コスト差は数か月の継続的な使用で意味のあるものになります。Fable 5 は、システム自体がより詳細な調査に値すると判断した、まれで本当に難しい合成質問のために特別に予約し、ルーチンの取り込みパイプラインには使用しないでください。
コピーペーストではなく、ヴォールトに直接接続する
上記のすべては、手動で Claude を開き、ファイルの内容を貼り付ける場合でも機能します。しかし、このシステムの実際の摩擦のないバージョンは、Opus 5 を Obsidian ヴォールトに直接接続し、取り込みとクエリがコピーペーストを一切必要とせずに行われるようにします。
ここでの実用的なパスは、Obsidian の Local REST API プラグインを使用します。これは Obsidian のコミュニティプラグイン設定で有効にでき、認証キーを使ってローカル API エンドポイント経由でヴォールトを公開します。Claude Code または Claude Desktop MCP 接続は、あなたのヴォールト内のファイルを直接読み書きできるようになります。つまり、この記事の前半の取り込みプロンプトは、あなたの実際のヴォールトに対して実行され、実際のメモを作成および編集するため、チャットウィンドウとメモの間で手動でコンテンツをコピーして戻す必要がなくなります。
これを一度設定します。Obsidian で、Local REST API プラグインをインストールして有効にし、生成された API キーをコピーします。Claude Code で、そのキーを使用してヴォールトを指す MCP 接続を設定します。Claude に /raw フォルダ内のファイルをリストするように依頼してテストします。正確なリストが返ってくれば、接続は確立されています。
これが機能すれば、前半の取り込みとダイジェストのパイプライン全体は、手動のコピーペーストプロセスではなく、単一のメッセージでトリガーできるものになり、また、スケジュールを真に自動化するものにもなります。スケジュールされたタスクは、あなたがその場にいなくても、同じ MCP 接続を呼び出すことができるからです。
複数の研究トピックへの拡張
上記のすべては、1 つのヴォールトに 1 つの研究トピックがあることを前提としています。これを真剣に実行しているほとんどの人は、複数の異なる分野を同時に追跡することになります。特定のプロジェクト、一般的にフォローしている業界、どちらとも無関係な長期的な関心事などです。これらを 1 つの未分化の wiki に混ぜると、まさにシステムが防ぐために作られた種類のノイズが発生します。
この修正は、一般的に Claude Projects に適用される同じスコープ設定の規律を反映しています。真に異なる各研究トピックに独自のサブフォルダ構造を与えるか、トピックが十分に大きく無関係で、相互汚染が合成を積極的に混乱させる場合（ある業界に関する主張が、関連のないプロジェクトと誤って相互参照されるなど、単に両方が同じ未分化の /wiki フォルダに存在するため）、または完全に別のヴォールトを与えます。
マルチトピックスコープ
このヴォールトは複数の研究分野をカバーしており、それぞれが
/wiki の下の独自のトップレベルフォルダにあります：/wiki/トピックa、/wiki/トピックb など。
新しい情報源を取り込むときは、まずそれがどのトピックに属するかを判断する。
それが本当に 2 つのトピックにまたがる場合は、説明なしに曖昧に
1 つのフォルダにファイルするのではなく、トピック間の接続を明示的にメモする。
ダイジェストは、特にトピック間の合成を求められた場合を除き、
1 つの結合されたサマリーとしてではなく、トピックごとに生成する必要があります。
この構造により、各トピックは独立して複合的に成長できます。独自の wiki、独自の一貫性のある相互参照セットを持ちながら、2 つの領域間の真のつながりが実際に表面化する価値がある場合に、トピック間の合成を明示的に要求することも可能です。すべてのメモが、1 つの未分化の山の中で、関連性をめぐって暗黙的に関連のない資料と競合することはありません。
いつ完全に別のヴォールトに分割するか、いつ 1 つのヴォールト内のサブフォルダにするかについての実用的なルール：あるトピックに対するクエリが、誤って別のトピックの無関係な資料を表面化することを本当に決して望まないのであれば、別のヴォールトは、それらを切り替えるという僅かなオーバーヘッドの価値があります。トピック間のいくらかの相互受粉が実際に価値がある場合、つまり一般的な業界動向が特定のプロジェクトに情報を与えるような場合、1 つのヴォールト内のサブフォルダは、その結合組織を保持しつつ、上記の明示的なトピックスコープ設定の指示が、ルーチンの取り込み中に実際の混乱を防ぎます。
これが実際に時間を節約しているかどうかを測定する
このようなシステムは、それが置き換えるために作られたものと実際に比較測定されなければ、生産的であるように感じられる可能性があります。システムが存在してスケジュール通りに実行されているという理由だけで、時間節約が現実のものだと想定するのではなく、定期的に正直なチェックを実行する価値があります。
セットアップ後 2、3 週間は、古い手動プロセスでの月曜日のレビューにかかっていた時間を大まかに追跡します。保存したすべてを読み返し、何が何に接続していたかを思い出し、どこかで読んだと知っている特定の事実を検索するのにかかっていた時間です。それを、生成されたダイジェストを読み、フラグされた注意が必要な項目をフォローアップするのにかかる時間と正直に比較します。
実際に重要な比較は、ダイジェスト自体にかかる生の時間の節約ではありません。500 語の要約が 1 週間分の生の情報源よりも明らかに速く読めるからです。重要なのは、ダイジェストが実際に重要だったものを表面化しているかどうかです。つまり、数日後になって、何か重要なことが生の資料に埋もれてメモやダイジェストにまったく含まれていなかったことに、別途気づくことがないかどうかです。これが定期的に発生している場合、取り込みプロトコルの抽出ステップを強化する必要があり、必ずしも回避策として手動の読書時間を追加する必要はありません。
追跡する価値のあるもう 1 つの正直な指標は、前述のクエリ機能が実際に使用されているかどうかです。きれいな毎週のダイジェストを生成するが、相互参照された回答をクエリしたことがないシステムは、意図された価値の半分、つまり受動的な要約の半分しか提供しておらず、複数月の使用で真の複合価値が現れる能動的な「これまでに与えたすべての情報源から、これについて実際に何を学んだか」という半分が欠けています。クエリを使用していないことに気づいた場合、それは多くの場合、wiki にまだクエリを価値あるものと感じさせるほど十分な相互リンク資料が蓄積されていない兆候であり、これは最初の 1 ～ 2 か月では正常です。または、単に質問する習慣が途絶えてしまった兆候であり、システムの実際の価値の相当な部分がそこにあるため、意図的に修正する価値があります。
今週中にこれを設定する
完全なパイプラインを 1 回の作業で構築しようとしないでください。各ピースが次のピースを追加する前に自分自身を証明できる順序で構築してください。
第 1 週は、ヴォールトの構造と CLAUDE.md ファイルだけを構築し、次に、既に読んでいるものに対して手動で取り込みプロンプトを実行します。何かを自動化する前に、抽出品質に慣れてください。
第 2 週は、毎週のダイジェスト生成を追加します。最初はスケジュールではなく手動で実行し、それが正しい週のアクティビティから実際にプルされ、適切に簡潔であることを確認できるようにします。
第 3 週は、両方のピースが確実に機能するようになったら、取り込みとダイジェストを自動的に実行するようにスケジュールし、システムがトリガーを覚えていなくても実際に実行されるようにします。
第 4 週か第 5 週までには、このシステムが生み出すように設計された実際の変化に気づくはずです。以前は前週に何を読んで学んだかを思い出そうとすることから始まっていた月曜の朝が、今ではその想起を既に行ってくれた 2 分のダイジェストから始まり、以前は自分の研究を手動で読み返し相互参照することに費やしていた時間が、研究のうち実際に人間が必要とする部分、つまり何が重要でその理由を判断することに使えるようになります。
この記事のすべての背後にある正確な CLAUDE.md テンプレートと Obsidian ヴォールトのセットアップについては、@cyrilXBT をフォローしてください。
