NotebookOrigin

AIエージェントを本格的に使い始めると、仕事のボトルネックが変わってきます。 以前は「情報を探す」「資料を読む」「コードを書く」「文章を書く」ことに多くの時間を使っていました。Claude CodeやCodexのようなエージェントを使えば、この部分はかなり高速化できます。 ところが、そこで仕事が終わるわけではありません。むしろ次に、もっと厄介な仕事が残ります。 「で、どれを信じるのか？」 AIが短時間で大量の情報を集められるようになれば、人間が一件ずつ検索する必要は減ります。しかし、「この情報源は信用できるのか」「これは現在も有効なのか」「一次情報なのか、誰かの解釈なのか」「複数の情報が矛盾しているが、どちらを採用するのか」「AIが作った複数案のうち、本番環境へ入れていいのはどれか」という仕事は残ります。 これからは、人間の時間のかなりの部分が、この 判断 に使われるようになるのではないかと思っています。 だからClaude Code、Codex、Obsidianを組み合わせて作るべきものは、単なる「第二の脳」ではありません。必要なのは、 情報の出所、鮮度、検証状態、採用状態まで管理できるナレッジシステム です。 情報をたくさん与えればAIは賢くなる、という誤解 最初に陥りやすいのが、「AIに情報をたくさん与えれば、それだけ賢くなる」という考え方です。 会議メモ、設計資料、過去の意思決定、技術調査、障害対応、AIとの会話。全部Obsidianへ保存して、Claude CodeやCodexからアクセスできるようにする。一見すると理想的です。 しかし、情報が増えてくると問題が起こります。2024年の調査ではA、2025年にはB、2026年にはC。でも昔のAも検索すると出てくる。 AIにとって難しいのは、情報を「見つける」ことではありません。 見つけた情報の中から、今どれを信じるべきか判断すること です。 長大なドキュメントより「地図」を作る そこで最初に必要になるのが、ナレッジの分割です。 巨大な knowledge.md に何でも詰め込むのではなく、 architecture.md 、 security.md 、 decisions.md 、 operations.md 、 current-stack.md のように意味のある単位へ分け、Obsidianの [[Wik...

前回は、ObsidianをCodexの「外部記憶」として使う方法を紹介しました。 次の段階では、単にCodexがVaultを読むだけでは足りません。 重要なのは、 必要な知識をCodex自身が選ぶこと 、 古い情報を避けること 、 確認済みの事実だけを使うこと 、そして 使い終わった知識を再利用可能な形で戻すこと です。 ここまで来ると、Obsidianは単なるノート置き場ではなく、Codexが利用する「知識基盤」に変わります。 上級編のゴール 目指す構成は次の通りです。 Sources → Research → Decisions → Codex → Drafts → Published さらに、Codexは依頼内容に応じて必要なノートだけを読みます。 人間が毎回ファイルを指定する 状態から、 Codexが自分で読むべき知識を判断する 状態へ進化させます。 1. VaultをAI向けに分ける おすすめ構成は次の通りです。 Sources/ ：原資料や一次情報 Research/ ：確認済みの事実や調査結果 Decisions/ ：過去に何を選び、なぜそう判断したか Drafts/ ：生成中の文書 Published/ ：完成済みの成果物 TODO/ ：未確認事項や追加調査 この構成にすると、Codexにルーティングルールを持たせやすくなります。 2. frontmatterで「知識の品質」を管理する Markdownの先頭にメタデータを持たせます。 --- type: research topic: pixel status: verified updated: 2026-08-15 expires: 2027-02-15 source_count: 5 confidence: high --- Codexには、「 status: verified で、 expires を過ぎていないResearchだけ使う」と指示できます。 これで古いノートを誤って使うリスクを減らせます。 3. Decisionsフォルダが意外と重要 Researchには事実を保存します。一方、Decisionsには判断を保存します。 Pixel 11 Proを推した理由 なぜこのSEOタイトルにしたか なぜこの構成を採用し...

Codexを使っていると、次第に「毎回ゼロから情報を渡すのはもったいない」と感じるようになります。 過去に調べたこと、技術メモ、判断した理由、失敗した手順、記事の下書き、製品比較。こうした情報を毎回プロンプトへ貼り付けるのではなく、 Codexが必要なときに自分で読みに行ける知識ベース を用意できれば、かなり効率が上がります。 そこで相性がいいのがObsidianです。 ObsidianのVaultは特殊なデータベースではなく、Markdownファイルが入った普通のフォルダです。Codexから見れば、そのまま「検索できる・読める・編集できる作業データ」になります。 つまり、今回の主役はObsidianではありません。 Codexをより少ない説明で動かすために、Obsidianを外部記憶として使う。 これがこの記事の基本的な考え方です。 さらにNotebookLMを加えると、 NotebookLMで大量の原資料を読み、Obsidianへ整理済みの事実を保存し、Codexが必要な情報だけを使って最終生成する という役割分担もできます。 結論：ObsidianをCodexの「外部記憶」にする CodexとObsidianを組み合わせるために、必ずしも専用プラグインが必要なわけではありません。 Obsidianのノートは .md ファイルとして保存されています。 たとえばWindowsでVaultが次の場所にあるとします。 C:\Users\ユーザー名\OneDrive\Obsidian\MyVault この MyVault をCodexの作業対象にすれば、その中のMarkdownをCodexから読み取ったり、編集したりできます。 Codex ← Obsidian Vault → 人間 同じ知識ベースを、人間はObsidianから、AIはCodexから扱う構成です。 Codexに外部記憶があると何が変わる？ 通常はCodexへ「前回こういう調査をした」「この記事ではこの条件を使う」「この数値はこの資料が根拠」と毎回説明する必要があります。 しかし、それらをObsidianへ保存しておけば、たとえば次のように指示できます。 「Research/Pixel11_2026.mdを読んで記事を書いて」 毎回長い背景説明を書く必要が減り、...