CodexをObsidianと連携する方法！Vaultを外部記憶にしてトークン消費を抑える

8月 16, 2026

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を読んで記事を書いて」

毎回長い背景説明を書く必要が減り、Codex側から必要な情報を取りに行けます。

CodexでVaultを検索できる

たとえば「過去にPixelの発熱について調べたノートを探して」と依頼できます。

さらに「今回の記事に使えそうな情報だけ抜き出して」と続ければ、検索から情報抽出まで一連の作業にできます。

過去の調査を再利用できる

以前にPixel 11の仕様、Tensor G6、カメラ、発売日、価格、デメリットなどを調べていたなら、その結果をObsidianへ残しておきます。

次の記事では「Pixel 11関連はResearch/Pixel11/を使って」と指定できます。

調査結果が一度きりのAI回答ではなく、再利用できる知識資産になります。

CodexにVault全部を読ませる必要はない

ただし、Obsidianを外部記憶にしたからといって、毎回Vault全体をCodexへ読ませる必要はありません。

Vaultが大きくなると、PDF由来ノート、会議メモ、技術資料、Web記事メモなどが大量に蓄積されます。

そこで「全部読んで記事を書いて」と依頼すると、関係のない情報まで探索することになります。

Codexを効率よく使うなら、読む範囲を狭くする設計が重要です。

トークンを抑えるなら「必要な情報だけ読ませる」

基本思想は、原資料 → 情報圧縮 → Obsidian → Codexです。

原資料を読む
必要な事実を抽出する
Obsidianへ保存する
Codexには整理済みノートだけ読ませる

これにより、Codexへ渡すコンテキストを小さくしやすくなります。

実際のトークン使用量は処理内容や読ませるファイル数によって変わるため、固定的な削減率は断定できません。ただし、無関係な大量資料を毎回読ませないという設計自体には十分意味があります。

NotebookLMを「前処理AI」として使う

ここで使えるのがNotebookLMです。

NotebookLMを最終的な文章生成担当にするのではなく、Codexへ渡す情報を整理する前処理担当として使います。

PDF・公式資料・Web資料 → NotebookLM → 必要な事実を抽出 → Obsidian → Codex

NotebookLMでは「記事を書かせない」

NotebookLMには、完成したブログ記事を書かせるより、次の情報を整理させます。

事実
数字
日付
出典
比較ポイント
条件
例外
不明点

Obsidianには事実だけを残す

NotebookLMで整理した情報を、Obsidianへ構造化して保存します。

Research/Pixel11_2026.md

このノートに、発売日、日本価格、CPU、カメラ、Pixel 10との差、メリット、デメリット、出典、TODOなどをまとめます。

Codexは「生成と実行」に集中させる

Codexには「Research/Pixel11_2026.mdだけを根拠に記事を書いて」と指示します。

必要なら、「出典のない事実は追加しない」「Blogger向けHTMLへ変換」「完成稿をDrafts/へ保存」まで任せます。

Obsidianを「Codex用キャッシュ」にする

この考え方を進めると、Obsidianは単なるノートアプリではなく、Codexが再利用するキャッシュになります。

Sources/：原資料・一次情報
Research/：確認済みの事実
Drafts/：Codexが作った草稿
Published/：完成済みの記事
Decisions/：過去の判断理由
TODO/：未解決事項

すると「Vault全部を調べて」ではなく、「Research/のこの2ファイルだけ使って」と指定できます。

テーマごとにノートを分割する

Pixel11_specs.md
Pixel11_camera.md
Pixel11_ai.md
Pixel11_price.md
Pixel11_disadvantages.md

カメラ記事を書くなら「cameraとdisadvantagesだけ読んで」と指定できます。

Vaultを巨大な1つのコンテキストとして扱わないことがポイントです。

AGENTS.mdでCodexの読み方を固定する

CodexではAGENTS.mdへ作業ルールを書いておけます。

.obsidianは変更しない
Sources/は変更しない
記事生成では指定されたResearchノートだけ読む
Vault全体を無条件に走査しない
出典のない数字は追加しない
不明点を推測で埋めない
Wikiリンクは[[ノート名]]
frontmatterを維持する
ノート削除前に確認する

毎回長い指示を書く必要を減らし、Codexを自分のVault専用エージェントに近づけられます。

CodexにVault整理も任せられる

重複ノートの検出
タグの統合候補
関連ノートの探索
MOCの生成
古いResearchの発見
未解決TODOの一覧化
リンク切れの確認

ここでも、いきなり編集させるより、分析 → 提案 → 確認 → 編集の順番がおすすめです。

OneDrive × Obsidian × Codex

WindowsならOneDriveとの組み合わせも便利です。

C:\Users\username\OneDrive\Obsidian\MyVault

同じフォルダをObsidianで開き、Codexの作業対象にし、OneDriveで同期します。

CodexがMarkdownを更新
Obsidianへ反映
OneDriveが同期
別PCでも更新内容を確認

OneDriveでは同期競合に注意

Codexが大量編集している最中に別PCで同じノートを編集すると、同期競合が起きる可能性があります。

同期完了を確認する
バックアップを取る
少数ファイルでテストする
Obsidianで結果を確認する
問題なければ対象を増やす

Gitも組み合わせると安心

変更前にコミットしておけば、「Codexに100ファイル整理させたけど元へ戻したい」という場合でも復旧しやすくなります。

Obsidianの実体がテキストファイルだからこそ使いやすい方法です。

Codexに読ませない情報も決めておく

パスワード
APIキー
個人情報
医療情報
契約情報
機密資料
個人的な日記

AIに必要な情報だけを読ませるという考え方は、トークンだけでなく安全性の面でも重要です。

ChatGPTを入れるなら「考える担当」

ChatGPTも組み合わせるなら、NotebookLM → Obsidian → ChatGPT → Codexという構成も考えられます。

ChatGPTには、アイデア、記事の切り口、比較軸、タイトル、構成を考えさせます。

Codexは、必要なファイルを読み、Markdownを編集し、HTMLを作り、ファイルへ保存する実行担当です。

ここから先はどう発展する？

ここまでで、ObsidianはCodexの外部記憶として機能します。

次の発展段階は、Codexが自分で「どの知識を使うか」を判断し、知識ベース自体も保守できる状態です。

発展1：VaultをAI向けに構造化する

Sources/、Research/、Drafts/、Published/、Decisions/、TODO/のように役割を固定します。

人間が見やすいだけではなく、Codexが「どこを見ればよいか」を判断しやすくなります。

発展2：frontmatterで知識にメタデータを付ける

---
type: research
topic: pixel
date: 2026-08-15
status: verified
source_count: 5
expires: 2027-02-15
---

こうしておけば、「status: verifiedの最新ノートだけ使う」「期限切れResearchは候補から外す」といったルールをCodexへ渡しやすくなります。

発展3：Codexに読むノートを自動選択させる

ユーザーが毎回ファイル名を指定するのではなく、依頼内容からCodex自身に必要なノートを選ばせます。

たとえば、記事作成ならResearch/、過去の判断理由ならDecisions/、未解決事項ならTODO/を見る、といったルーティングです。

発展4：Markdownだけで軽量RAGのような運用を作る

いきなりベクトルDBを導入しなくても、ファイル名、フォルダ、タグ、frontmatter、MOCを使えば、必要な知識だけを拾う仕組みを作れます。

厳密な意味でのRAGそのものではありませんが、「必要な知識を検索してから生成する」軽量なRAG風運用としては十分実用的です。

発展5：知識ベースを定期メンテナンスさせる

Codexへ定期的に、次のようなチェックをさせます。

重複ノート候補を出す
古いResearchを検出する
期限切れノートを一覧化する
未解決TODOをまとめる
リンク切れを探す
更新が必要な記事候補を出す

ここまで行くと、Codexは単なる生成AIではなく、知識ベースの保守担当にもなります。

発展6：半自律のブログ生成ワークフローへ

ブログ用途なら、最終的には次の流れへ発展できます。

NotebookLMで調査 → Obsidianへ事実保存 → Codexが必要なResearchを選択 → 記事構成と本文を生成 → 人間が確認 → Bloggerへ反映

重要なのは、最後の公開や大きな変更まで完全自動化しないことです。

事実確認、タイトル、結論、公開判断などは人間が承認する設計の方が安全です。

この構成のデメリット

短い作業なら逆に手順が増える
Vaultの運用ルール作りが必要
Codexが誤編集する可能性がある
OneDriveなどで同期競合が起こる可能性がある
Gitやバックアップなど保守作業が増える
知識整理そのものが目的化しやすい

この仕組みが特に向いているのは、同じ知識を何度も再利用する人です。

どんな人に向いている？

Codexを頻繁に使う
毎回同じ説明をCodexへしている
大量の資料を扱う
ブログを継続的に書く
技術調査を繰り返す
過去の調査結果を再利用したい
Codexへ渡すコンテキストを小さくしたい
自分専用のAI知識基盤を作りたい

まとめ：ObsidianはCodexのための「外部記憶」になる

CodexとObsidianを組み合わせる最大のメリットは、Obsidianを便利にすることではありません。

Codexへ毎回ゼロから説明する必要を減らせることです。

Obsidianへ調査結果や判断材料をMarkdownとして蓄積しておけば、Codexは必要なときにそこから情報を取得できます。

さらにNotebookLMを使えば、大量資料を読む → 重要情報を圧縮 → Obsidianへ保存 → Codexで生成という流れも作れます。

そして次の段階では、frontmatterやフォルダ構造を使ってCodex自身に必要な知識を選ばせ、軽量RAGのような検索・生成フローや、知識ベースの定期メンテナンスまで発展させられます。

ObsidianはCodexの長期記憶、NotebookLMは前処理、Codexは実行主体。

この考え方で設計すると、Obsidianは単なるノートアプリではなく、AIエージェントが必要なときに参照・保守・再利用できる自分専用の知識レイヤーへ発展していきます。

このブログを検索

NotebookOrigin