Obsidianのノートは、Vaultと呼ぶフォルダに保存されます。Codexにそのフォルダを適切な範囲で参照させることで、過去のメモを探し、出典付きの下書きへつなげられます。専用の連携プラグインを必ず入れる、という始め方ではありません。

記録を、根拠のある下書きへ：ObsidianのVault、Codexで参照、draftsへ保存、ノートで照合
記録を、根拠のある下書きへ
  1. 1ObsidianのVault
  2. 2Codexで参照
  3. 3draftsへ保存
  4. 4ノートで照合
Codex Studio編集部作成。作業の流れを整理した図です。

連携の基本：保存する場所と作業するAI

Obsidianはノートを読み書きする場所、Codexは指定した資料を使って作業を進める役割として考えます。Vaultの基本はObsidian公式、ローカルのファイル操作はCodex CLI公式で確認できます。

OpenAI公式：作業の文脈をCodexへ渡す

2026年5月1日公開。手元の仕事をCodexへ渡す考え方を補う映像です。Obsidian専用連携の実演ではなく、Vaultの運用は本記事の教材例で説明します。

出典：OpenAI公式資料 ↗ · 素材公開日：2026-05-01 · 確認日：2026-10-08

重要なのは資料の量ではありません。「どの資料が正本か」「いつの情報か」「どの作業で参照するか」が分かることです。古いメモと最新の決定事項を同じ扱いにすると、誤った前提で文章が作られる原因になります。

まず練習用Vaultを作る

いきなり会社の全ノートを対象にせず、機密を含まない資料を数件入れたコピーで試します。以下は編集部の教材用構成です。

practice-vault/
  AGENTS.md
  00-index.md
  meetings/
    sample-meeting.md
  decisions/
    current-policy.md
  drafts/
    README.md

00-index.mdには各フォルダの役割を書き、AGENTS.mdには「元資料を上書きしない」「下書きはdraftsへ」「根拠のノート名を残す」などの約束を置きます。

ObsidianでVaultを作り、Codexで同じフォルダを開く

  1. ObsidianのVault管理画面で、新しいVaultの作成を選びます。
  2. 名前をpractice-vaultにし、保存先を自分で分かる場所に決めます。
  3. Vault内に00-index.mdと、練習用の会議メモを作ります。
  4. ターミナルで、そのVaultの実際の保存先へ移動します。
  5. codexを起動し、最初は読み取りだけを依頼します。

MacでDocumentsに保存した場合の例です。場所が違う場合は、自分の保存先へ置き換えてください。

cd "$HOME/Documents/practice-vault"
codex

Windows PowerShellなら、同じ例はcd "$HOME\Documents\practice-vault"です。デスクトップアプリを使う場合も、作業フォルダとしてこのVaultを選ぶ考え方は同じです。アプリの接続権限とノートの保存先が一致しているか確認します。

Obsidianの設定フォルダ.obsidianを編集する必要はありません。練習中はノート本文と下書きフォルダを対象にし、プラグインや同期設定は変更対象から外します。

最小の教材データ

meetings/sample-meeting.mdに、次のような架空メモを保存します。

# 10月7日 商品ページ改善会議
決定：申込ボタンの説明を短くする。
担当：佐藤。期限：10月10日。
提案：価格表を別ページにする。これは次回判断。
未決：画像の担当者と締切。

decisions/current-policy.mdには「価格と問い合わせ先は変更しない」と保存します。こうするとCodexが会議の提案を決定事項と混同していないか、具体的に確認できます。

読み取りから始める指示例

このVaultの00-index.mdを読み、資料の構成を説明してください。
meetingsとdecisionsの違いを確認してください。
ファイルは変更せず、情報が食い違っている箇所があれば
両方のノート名と日付を示してください。

Codexが参照したノートを自分で開き、説明と一致するか確認します。リンクされた全ノートが自動で読まれると思い込まず、必要な参照先が確認されたかを見てください。

ノートから成果物へつなぐ

練習として、会議メモから次の行動を整理します。元資料と下書きを分け、担当者や期限を勝手に補わないよう依頼します。

meetings/sample-meeting.mdとdecisions/current-policy.mdを使い、
次回会議に向けた確認メモをdrafts/next-meeting.mdへ作ってください。

形式：決まっていること／未決事項／次の行動。
各項目に根拠のノート名を付けてください。
担当・期限が資料にない場合は「未定」としてください。
元のノートは変更しないでください。

期待する成果は「読みやすい文章」だけではありません。根拠に戻れること、未決事項が混ざらないこと、元資料が保持されていることも確認します。

結果はObsidianで開いて確認する

作成されたdrafts/next-meeting.mdをObsidianのファイル一覧から開きます。教材例なら、申込ボタンの説明修正は「佐藤・10月10日」、価格表の別ページ化は「未決」、画像は「担当・期限未定」と区別されているのが期待する状態です。

出力に付いた根拠のノートを開き、元の文章と照合します。さらに元資料が上書きされていないかを確認してください。Codexの完了メッセージだけでなく、Obsidian側で成果物が読めるところまでが一つの練習です。

根拠付きの完成例：どのノートから判断したかを残す

次の表は、上の架空メモから作る確認メモの期待例です。実際のCodexの出力記録ではありません。文章表現が違っていても、決定・提案・未定が正しく分かれ、根拠へ戻れるなら目的を満たします。

区分記載する内容根拠
決まっていること申込ボタンの説明を短くするmeetings/sample-meeting.md
次の行動佐藤が10月10日までに説明文を修正するmeetings/sample-meeting.md
現在の制約価格と問い合わせ先は変更しないdecisions/current-policy.md
未決事項価格表の別ページ化は次回判断meetings/sample-meeting.md
要確認画像の担当者と締切meetings/sample-meeting.md

この例で「価格表を別ページへ移す」作業まで始めたら、提案と決定の区別に失敗しています。「最新の日付のメモだから、以前のルールより必ず優先する」とも決めつけられません。会議の発言が正式な変更決定なのか、検討案なのかを本文から確認する必要があります。

ノートが増えたときの、正本・履歴・下書きの分け方

すべてのノートに同じ重みを与えると、AIも人も現在の方針を見つけにくくなります。フォルダを大量に作る前に、ノートの役割と有効な期間を明示します。以下は教材向けの整理例で、Obsidianの必須設定ではありません。

# 商品ページの現行方針
状態：確定
適用開始：2026-10-07
対象：商品ページの文章
決定元：meetings/2026-10-07.md
現在の方針：価格と問い合わせ先は変更しない
見直す条件：責任者による変更決定が記録されたとき

更新前の会議メモは、当時の経緯として残します。現行方針のノートへ過去の全発言を貼り付けるより、「今の方針」と「そこへ至った根拠」をリンクでつなぐ方が、作業時の入口が分かります。

Obsidianのリンクがあることと、Codexがその参照先を読んだことは別です。出力に重要な判断が含まれる場合は、使ったノート名と該当箇所を示すよう依頼し、必要な参照先が実際に確認されたかを見ます。添付PDFや画像の内容も、Markdown本文だけを読む方法では取得できない場合があります。

同期・同時編集・バックアップを別々に設計する

Codexが書いたファイルをObsidianで読むだけなら、まず同じ端末上の練習Vaultから始められます。複数端末へ広げるときは、使用OSに対応した同期方式を選び、必要なノートがローカルで読めるかも確認します。iPhoneなどのモバイルでは、一般的なクラウドフォルダを置くだけでは使えない組み合わせがあります。Obsidian公式：端末ごとの同期方法

人がObsidianで編集しているファイルへCodexも同時に書き込むと、意図しない上書きや競合の原因になります。練習では、元資料を読む時間と、下書きを作る時間を分け、編集先をdrafts/に限定すると確認しやすくなります。同期サービスを複数重ねて同じVaultを扱う構成も、先に公式の注意事項を確認してください。

同期は、変更を別端末へ伝えるためのものです。誤った変更も伝わるため、過去へ戻せる独立したバックアップを別に用意します。バックアップがあると表示されているだけでなく、練習用ノートを別のフォルダへ復元して、本文とリンクが読めるかを一度試してください。

  1. 練習Vaultのコピーを、同期対象と区別できる場所に保存する。
  2. コピーの日付と対象範囲を記録する。
  3. 元Vaultを上書きせず、別フォルダでコピーを開く。
  4. ノート本文・添付ファイル・必要な設定が戻るか確認する。

これは復元確認の考え方を示す教材です。業務データでは保管先のアクセス権や保存期間も決めてください。フォルダ名で分離しただけでは、Codexの技術的なアクセス権が制限されたことにはなりません。

連携がうまくいったか、3段階で点検する

段階確認すること詰まったとき
読める指定したノートの本文を正しく説明できるVaultの実保存先、対象ファイル、読み取り権限を確認
使える複数ノートの決定・提案・不明点を区別できる正本・日付・参照順を明示する
残せる指定先に保存し、Obsidianで開いて根拠をたどれる保存先、ファイル名、リンク先、同期状態を確認

最初の題材が通ったら、ノートがない、方針が矛盾する、担当が未定、添付だけに情報がある、といった入力で試します。情報不足をそのまま示せるかを確認してから、対象範囲を広げましょう。

運用を続けるための更新ルール

情報の種類扱い方残すもの
会議の記録当時の発言として保管会議日・参加者・記録元
現在の方針正本を一つ決める決定日・適用範囲・根拠
AIの下書き確定前の出力として区別参照したノート・未確認項目
検証した結果条件と結果を一緒に残す実施日・環境・できなかったこと

「第二の脳」は、何でも自動で正しく記憶する機能名ではなく、記録を再利用する運用の考え方です。仕組みの精度は、残した情報の整理と確認にも左右されます。

うまくいかないときの見直し方

  • 古い情報を使う：最新の方針と過去の記録を明示的に分ける。
  • 探す範囲が広すぎる：最初の参照ノートと必要なフォルダを指定する。
  • 本文にないことを補う：未定・不明の書き方を決める。
  • 元資料が変わる：書き込み先と編集禁止範囲を指定する。

毎回の整理手順が固まったらSkillsにします。会社全体へ広げる場合は、資料へのアクセス権と運用責任も合わせて設計します。