ObsidianとCodexを連携する初期設定｜初心者向けの安全な使い方

Obsidianにメモをため始めると、「どのフォルダに保存すればよいか分からない」「AIに編集を頼んだら、関係ないノートまで変わりそうで不安」と感じることがあります。

そこで今回は、Mac版Obsidianをインストールした直後の状態から、Codexと一緒に使いやすい保管庫へ整えました。対象はObsidian 1.13.7（installer 1.13.7）です。確認日は2026年8月23日。コミュニティプラグインは追加せず、Obsidianの標準機能と公式CLIだけで設定しています。

前回の記事「【Mac版】Obsidianのインストール方法｜ダウンロードから初回保管庫作成まで」で、Obsidian本体のインストールと初回保管庫の作成を済ませている前提で進めます。

この記事で設定するもの

Codexとの「連携」はプラグインのことではない

ここでいう連携は、Obsidianの画面にCodex専用ボタンを追加するという意味ではありません。Obsidianの保管庫はMarkdownファイルを中心に構成されているため、Codexでその保管庫フォルダを作業対象として開けば、ノートを検索したり、指定したファイルだけを編集したりできます。

さらに保管庫のルートに AGENTS.md を置くと、そのフォルダで作業するときのルールをCodexに伝えられます。保存先、編集範囲、出典の残し方、公開操作をしないことなどを文章にしておく仕組みです。実際の変更はファイルに反映されるので、Obsidianを閉じている間でもMarkdownとして確認できます。

1．インストール直後の状態を確認する

まず、初期状態を撮影しておきます。最初から整理されているように見せるためではなく、設定後に何が増えたかを比較できるようにするためです。

この段階で確認するのは、保管庫名とファイル一覧です。個人名、メールアドレス、同期サービスの通知などが写っていないかも確認してから、ブログ用の画像として保存します。今回の画像はアプリのウィンドウ内だけを撮影し、デスクトップ全体や他のアプリは含めていません。

2．最初にフォルダの役割を決める

AIに編集を頼む前に、ノートの置き場所を決めました。フォルダ名は一例ですが、役割を先に固定しておくと、Codexへの依頼が短くなります。

フォルダ	役割
00_受信箱	保存先を決めていない思いつきや新規メモ
10_記事/企画	読者、検索意図、見出し、必要画像などの企画
10_記事/下書き	執筆中の記事本文
10_記事/公開済み	公開後の控えや更新メモ
20_調査	URL、確認日、事実と推測を分けた調査メモ
30_日次	日々の作業ログ
80_添付ファイル	スクリーンショット、画像、PDFなど
90_テンプレート	記事、調査、依頼、日次ノートのひな形
99_ガイド	保管庫の使い方と依頼文の例

最初から完璧な分類を目指す必要はありません。迷ったら 00_受信箱 に置き、あとで一覧を見ながら人が移動先を決めます。Codexには、いきなり移動や削除を頼まず、「重複候補と推奨保存先だけを表にしてください」と依頼すると安全です。

3．AGENTS.mdでCodexの作業範囲を固定する

保管庫のルートに AGENTS.md を作成しました。Codexの公式ドキュメントでは、作業前にプロジェクトの指示ファイルを読み、対象ディレクトリに応じたルールを適用する考え方が説明されています。

AGENTS.md には、少なくとも次の内容を書いておくと運用しやすくなります。

1. この保管庫を何に使うか
2. フォルダごとの役割
3. 保存先が未指定の新規ノートをどこへ作るか
4. 既存のYAML、内部リンク、画像リンクを壊さないこと
5. 事実には出典URLと確認日を付け、推測と提案を分けること
6. 大量移動・削除・公開を勝手に行わないこと
7. 作業後に変更ファイル、確認内容、未確認点を報告すること

ここで重要なのは、AIに「良い感じに整理して」とだけ頼まないことです。どこまで変更してよいか、何を残すか、どのように確認するかをルールにします。AGENTS.md は魔法の保護機能ではないため、重要な編集前には差分を確認し、バックアップや履歴管理も別に考えてください。

4．Obsidian側の保存先を設定する

新規ノートと添付ファイルの保存先

Obsidianの「設定」→「ファイルとリンク」を開きます。「新規ノートの作成場所」を「以下で指定されたフォルダ」にし、新規ノートを作成するフォルダに 00_受信箱 を指定しました。添付ファイルフォルダのパスは 80_添付ファイル です。

同じ画面のリンク設定では、内部リンクを自動更新する項目も有効にしました。ファイル名やフォルダを変更したときにリンクが追随しやすくなりますが、設定変更後はリンク切れがないか確認してください。リンクの形式やWikiリンクの使用は、保管庫全体で統一することが大切です。

テンプレートフォルダを指定する

コアプラグインの「テンプレート」を有効にし、テンプレートフォルダを 90_テンプレート にします。記事企画、記事下書き、調査メモ、Codex作業依頼、日次ノートのひな形をここに置きました。

テンプレートには、たとえば記事下書きなら「想定読者」「結論」「見出し」「出典」「公開前チェック」をあらかじめ入れておきます。テンプレートを使うと、毎回同じ項目を思い出す負担が減ります。ただし、テンプレートがあるからといって内容の正確さが保証されるわけではありません。

日次ノートを設定する

「デイリーノート」では、日付の形式を YYYY-MM-DD、新規ファイルの場所を 30_日次、テンプレートファイルを 90_テンプレート/デイリーノート に設定しました。

日次ノートは、Codexへの依頼を記録する場所としても便利です。「何を依頼したか」「どのファイルが変わったか」「次に確認すること」を短く残しておくと、後から作業の経緯を追えます。会話全文を自動保存するのではなく、必要な結論だけを人が確認して記録する運用にしました。

ファイルリカバリーを確認する

コアプラグインの「ファイルリカバリー」では、スナップショットの間隔が5分、履歴の期間が7日になっていることを確認しました。

大規模な編集を依頼する前に、保管庫を別の場所へコピーするか、Gitなどの履歴管理を検討します。

削除前の確認とリンク更新を有効にする

「ファイルとリンク」の下部にあるゴミ箱の設定では、「ファイル削除前に確認」をオンにしました。削除したファイルは「システムのゴミ箱に移動する」設定です。添付ファイルについても、削除時には毎回確認するようにしています。

Codexにファイル整理を頼む場合も、まず対象一覧を出してもらい、移動・改名・削除は一つずつ確認するのがおすすめです。特に、完全削除やコード実行を伴うコマンドは、便利そうに見えても初期運用では使わないことにしました。

5．日次ノートが作成できるか確認する

設定が終わったら、左側のカレンダーアイコンなどから今日の日次ノートを作成します。今回は 30_日次/2026-08-23.md が作成され、設定したテンプレートの項目が入ることを確認しました。

ここで確認するポイントは、次の3つです。

• ファイルが 30_日次 に作成されているか
• ファイル名が意図した日付形式になっているか
• テンプレートの見出しやチェック項目が入っているか

テンプレートの読み込みに失敗する場合は、テンプレートファイルの場所が間違っていないか、テンプレートフォルダが 90_テンプレート になっているかを見直します。

6．公式CLIを有効にして、正確なパスで確認する

Obsidian 1.13.7では、設定の「Obsidianについて」→「高度な設定」にある「コマンドラインインターフェース」を有効にしました。CLIはターミナルから保管庫やノートを扱うための入口です。今回はCodexからファイルを指定しやすくする目的で使います。公式ヘルプによると、CLIにはObsidian 1.12.7以降のインストーラーが必要です。コマンドを実行するときはObsidian本体も起動している必要があります。起動していない場合は、最初のCLIコマンドを実行するとObsidianが起動します。

ターミナルで、次の確認を行いました。

obsidian version
obsidian vaults

実測結果は、obsidian version が 1.13.7 (installer 1.13.7)、obsidian vaults が Obsidianブログ練習 でした。CLIのバージョンと保管庫名が表示されれば、登録状態を確認できます。

次に、テンプレートを使って依頼ノートを作成しました。

obsidian create 'path=00_受信箱/Codex連携の最初の依頼.md' 'template=Codex作業依頼' open

CLIでファイルを指定するときは、曖昧な検索よりも相対パスを明記する path= を優先します。フォルダ名やファイル名が似ている場合でも、意図しないノートを開きにくくなるためです。

7．Codexへの依頼は4項目で書く

Codexに頼むときは、次の4項目を毎回書くと意図が伝わりやすくなります。

• Goal（ゴール）：最終的に何をできるようにするか
• Context（背景・対象）：読むファイル、読者、前提条件
• Output（出力）：作るファイル、形式、文字数、画像や出典の要否
• Boundaries（境界）：変更しないファイル、外部公開しないこと、確認が必要な操作

たとえば、次のように依頼します。

Goal:
  Mac版Obsidian初心者が、記事企画を作れる下書きを準備する。
Context:
  対象は20_調査/Obsidian初期設定.mdと、
  10_記事/企画/ObsidianとCodex.mdです。
  読者はObsidianを入れたばかりの人です。
Output:
  10_記事/下書き/ObsidianとCodexの初期設定.mdを作る。
  見出し、本文、出典、スクリーンショットの位置、alt案を含める。
Boundaries:
  調査メモ、公開済み記事、画像原本は変更しない。
  WordPressへ投稿しない。
  先に構成案を示し、本文作成前に確認を取る。

短い依頼でも、対象パスと変更しないものがあるだけで安全性が上がります。「全体を整理」「いい感じに修正」のような依頼は、変更範囲が広くなりがちです。まず一覧、次に構成案、最後に承認した部分だけ本文、という順番にします。

8．実際の使い方：受信箱から記事下書きまで

思いつきを受信箱へ置く

新しいメモは、迷わず 00_受信箱 に作ります。タイトルと日付だけ付け、思いつきをそのまま書いて構いません。Codexには「受信箱を読み、記事化できそうなメモと調査が必要なメモを分類して。まだ移動・結合・削除はしないで」と依頼します。

調査は出典付きで分ける

記事にしたいテーマが決まったら、調査結果を 20_調査 に保存します。ページ名、URL、公開日または更新日、確認日、確認できた事実、そこからの推測、自分の提案を分けます。公式情報を優先し、更新されやすい仕様は記事を書く時点でもう一度確認します。

企画を作ってから本文を書く

調査メモから 10_記事/企画 に企画を作り、想定読者、悩み、読後にできること、見出し案、必要な画像を確認します。構成が決まったら 10_記事/下書き に本文を作ります。調査と執筆を分けると、「いつの間にか事実と感想が混ざっていた」という状態を見つけやすくなります。

最後にQAを依頼する

下書きができたら、Codexに「本文と画像の対応」「リンク切れ」「altの有無」「バージョン表記」「個人情報の映り込み」「未確認事項」を点検させます。AIの文章をそのまま公開するのではなく、画面と実際の設定が一致しているかを人が確認します。

9．参考にした公開例から取り入れた考え方

今回の構成は、複数の公開事例をそのままコピーしたものではありません。自分の保管庫に適用できる考え方だけを採用しました。

Andrej Karpathy氏のLLM Wikiでは、変更しない原資料、LLMが整えるMarkdown、作業規則を記した AGENTS.md を分ける考え方が示されています。今回は、原画像とPDFを 80_添付ファイル、調査を 20_調査、記事本文を 10_記事/下書き として分離しました。

Xzan氏のCodex＋Obsidianの事例からは、Inboxに一度集め、出典や確認日を残し、最後は人が判断する流れを参考にしました。Codexが分類案を出しても、移動や公開は自動で確定させません。

John Castorina氏の公開Wikiでは、最初に索引や必要なページだけを読み、ファイル全体を不用意に書き換えない運用が紹介されています。私も依頼時に対象ファイルを列挙し、「このファイルは変更しない」と書くようにしました。

Kepano氏の obsidian-skills には、Obsidian MarkdownやCLIの扱いを補助する公開例があります。ただし、今回は初心者が仕組みを追いやすいように、コミュニティプラグインや外部スキルは導入していません。便利そうな拡張を後から追加する場合は、権限、更新、保管庫のバックアップを確認してからにします。

10．よくあるつまずきと対処

Codexが別のフォルダを編集しそう

Codexで開いている作業フォルダが、保管庫のルートになっているか確認します。依頼文にも、/ を基準にした絶対パスではなく、保管庫からの相対パスを列挙します。AGENTS.md が保管庫直下にあることも確認してください。

新規ノートが受信箱に入らない

「設定」→「ファイルとリンク」で、新規ノートの作成場所が「以下で指定されたフォルダ」になっているか、フォルダ名が正確に 00_受信箱 になっているかを見ます。プラグイン側の保存先設定が優先される場合もあるので、導入している拡張があれば確認します。

日次ノートのテンプレートが反映されない

テンプレートファイルのパスを、ファイル名だけでなく 90_テンプレート/デイリーノート として選び直します。テンプレートフォルダに通常のメモを置くと候補が増えるため、ひな形だけを置くようにします。

CLIコマンドが見つからない

Obsidianのバージョン、CLI設定、ターミナルのPATHを順番に確認します。公式CLIはバージョンやインストーラーの条件によって表示が異なることがあるため、公式ドキュメントの案内に従い、まず obsidian version と obsidian vaults で確認します。パス登録のために管理者パスワードを求められた場合は、意味を理解してから自分で入力してください。

まとめ：AIに任せる範囲を先に決める

ObsidianとCodexの組み合わせは、特別なプラグインを大量に入れなくても始められます。今回のポイントは、次の4つです。

1. 新規メモの入口を 00_受信箱 に固定する
2. 調査、企画、下書き、公開後の記録を分ける
3. AGENTS.md と依頼文で、対象・出力・境界を明示する
4. CLIやAIの操作後に、人が差分・出典・画像を確認する

Codexは、整理案、構成案、文章のたたき台、リンクや画像の点検に向いています。一方、事実の最終確認、公開判断、個人情報の扱いは人が担うべき領域です。最初から自動化を広げるより、「受信箱に集める」「小さく依頼する」「確認してから次へ進む」という流れを作ると、Obsidianを長く使いやすくなります。

AIの利用について

この記事では、Codexを使って公式資料と公開事例の調査、Obsidian保管庫の初期設定、テンプレート作成、画面記録、画像整理、記事構成、SWELL入稿準備を行いました。設定値、CLIの実行結果、作成されたMarkdownファイルは実機で確認しています。公開前の事実確認と最終判断は運営者が行います。

実機確認：2026年8月23日／公式資料・リンク再確認：2026年9月2日

出典・参考資料

• CodexのAGENTS.md（公式）
• ChatGPT／Codexのプロンプト作成（公式）
• Obsidian Templates（公式）
• Obsidian Daily notes（公式）
• Obsidian File recovery（公式）
• Obsidian CLI（公式）
• Andrej Karpathy — LLM Wiki
• Xzan — Codex + Obsidian
• John Castorina — codex-obsidian
• Steph Ango — obsidian-skills