Codex と Obsidian を連携してノートを編集する2つの方法

Obsidian と Codex を組み合わせると何ができるか

Obsidian は、ローカルに保存した Markdown ファイルを相互リンクでつなぐ知識管理ツールだ。vault と呼ばれるフォルダの中に .md ファイルが並んでいるだけの素朴な構造で、特定のクラウドや独自データベースに依存しない。この「中身がただのテキストである」という性質が、Codex との相性のよさを生む。Codex CLI はローカルのファイルとシェルを操作できるエージェントなので、vault のフォルダを作業ディレクトリにすれば、ノートの中身を読み取り、書き換え、新規作成するところまで自然に頼める。

具体的な使いどころは幅広い。たとえば「調査ノートの内容を要約して、新しいまとめノートを作って」と指示すれば、複数のノートを横断して読み取り、整理した結果を別の .md として書き出せる。「日付がバラバラなノートの frontmatter を統一して」「散らばった用語を共通の表記に直して」といった一括編集も、人間が一枚ずつ開いて直す手間を Codex に肩代わりさせられる。Obsidian 特有の [[ノート名]] というウィキリンク記法もただのテキストなので、リンクの張り直しや欠落リンクの補完を依頼することもできる。

連携の前提として押さえておきたいのは、Obsidian がディスク上のファイル変更を監視して自動で表示に反映する点だ。つまり Codex がファイルを書き換えれば、Obsidian を開いていればその変更がすぐ画面に現れる。逆に言えば、Codex の編集はそのまま vault の実体に効くということでもある。便利さと裏返しのリスクがあるため、後述する権限設計を済ませてから本格運用に入るのが安全だ。Obsidian のデータ保存の仕組みは公式ヘルプ(https://obsidian.md/help/data-storage)にまとまっている。

連携の前に知っておく2つの方式

Codex から Obsidian を扱う道筋は、大きく分けて 2 つある。どちらを選ぶかで準備の手間も、できることの範囲も変わるため、先に違いを理解しておくと迷わない。判断の軸は「Obsidian を起動した状態で連携したいか」「検索やメタデータの取得まで必要か」の 2 点だと考えるとよい。シンプルな一括編集だけが目的なら前者、稼働中の vault に対する高度な操作まで求めるなら後者が向く。

方式A: vault フォルダを直接 Codex に渡す

Obsidian の vault はただのフォルダなので、その場所で Codex CLI を起動すれば、追加のプラグインもサーバーも要らずにノートを読み書きできる。セットアップが最小で済み、Obsidian が起動していなくても動くのが利点だ。多数のノートをまたいだ一括変換や、新規ノートのまとめ生成といった「ファイル単位の編集」に強い。一方で、Obsidian が内部に持つ検索インデックスやメタデータには直接アクセスしないため、リンク関係を厳密に踏まえた操作は自分で指示に書く必要がある。

方式B: Local REST API プラグイン経由の MCP 連携

Obsidian のコミュニティプラグイン「Local REST API」を導入すると、稼働中の vault に対する操作を API として公開できる。この API を仲介する MCP サーバーを Codex に登録すれば、ファイルを直接書き換える代わりに、検索・取得・追記・部分更新といった操作を Codex から呼び出せるようになる。Obsidian の文脈(アクティブなファイルやメタデータ)を踏まえた操作ができる反面、プラグインの導入や API キーの設定など準備の手数は増える。常に Obsidian を立ち上げて使う人に向いた方式だ。

方式A — vault を直接編集する手順

ここでは追加ツールの要らない方式 A の流れを示す。準備はほぼ不要で、Codex CLI が使える環境ならすぐに試せる。

Step 1: vault のフォルダを確認する

まず編集対象の vault がどのフォルダかを確認する。Obsidian の設定画面、または vault を開いた状態でのフォルダ表示から、.md ファイルと .obsidian という設定フォルダが入っているディレクトリを探す。この .obsidian フォルダには Obsidian 自身の設定が入っているので、ノートの一括編集を頼むときは「.obsidian 配下は触らないで」と添えておくと、設定を巻き込む事故を避けられる。

Step 2: vault ディレクトリで Codex を起動する

ターミナルで対象の vault フォルダへ移動し、そこで codex を起動する。Codex は起動したディレクトリを作業範囲として扱うため、これだけで vault 内のノートが操作対象になる。最初は読み取り中心の指示から始めるとよい。たとえば「このフォルダにある Markdown を一覧して、それぞれの先頭の見出しを教えて」と頼み、Codex が中身を正しく読めているかを確かめる。

Step 3: 編集を具体的に指示する

読み取りが確認できたら、目的の編集を依頼する。「すべてのノートの frontmatter に updated の日付が無ければ追加して」「#draft タグの付いたノートだけを一覧にしたインデックスノートを新規作成して」のように、対象と操作を具体的に書くほど期待どおりに動く。[[ウィキリンク]] の記法を保ったまま直したい場合は、その点も指示に明記しておく。破壊的になりがちな一括置換では、まず 1 ファイルで試させてから全体に広げると安全だ。

Step 4: 承認モードで変更を確認する

Codex には、ファイルへの書き込みやコマンド実行の前に確認を挟む承認モードがある。重要なノートを扱うときは、変更内容を都度確認できる設定にしておくと、想定外の上書きをその場で止められる。編集後は Obsidian 側で実際の見た目を確認し、リンクやタグが崩れていないかを点検する。問題なければ、その vault を Git などでバージョン管理しておくと、後から差分をたどれて安心だ。

方式B — Local REST API + MCP で接続する手順

稼働中の Obsidian に対して検索やメタデータ込みの操作をしたい場合は、方式 B を選ぶ。ここではコミュニティプラグインと MCP サーバーを組み合わせて Codex に接続する流れを示す。

Step 1: Local REST API プラグインを導入する

Obsidian の設定から「コミュニティプラグイン」を開き、「Local REST API」を検索してインストール・有効化する。このプラグインは vault に対する安全な REST API を提供するもので、近年は MCP サーバー機能も備える(出典: https://github.com/coddingtonbear/obsidian-local-rest-api)。有効化すると、ローカルホスト上で待ち受ける API が起動し、設定画面に接続用の API キーが表示される。この API キーは vault への入口になるため、外部に漏らさないよう扱いに注意する。

Step 2: API キーと接続先を控える

プラグインの設定画面で発行された API キーと、待ち受けているホスト名・ポート番号を控える。API は既定でローカルホストに閉じて動くため、同じパソコン上の Codex から接続する構成が基本になる。この段階で、ブラウザなどから API の疎通だけ先に確認しておくと、後の切り分けが楽になる。接続先が分からないときは、プラグイン設定画面に表示される URL を確認する。

Step 3: MCP サーバーを Codex に登録する

Local REST API を仲介する MCP サーバー(たとえば mcp-obsidian)を Codex に登録する。Codex の設定ファイル ~/.codex/config.toml に [mcp_servers.obsidian] テーブルを追記し、command に起動コマンド、env に先ほどの API キーと接続先を渡す。最小構成は次のようになる。

[mcp_servers.obsidian]
command = "npx"
args = ["-y", "mcp-obsidian"]
env = { "OBSIDIAN_API_KEY" = "<発行された API キー>", "OBSIDIAN_HOST" = "127.0.0.1" }

テーブル名の obsidian が Codex 内でのサーバー識別子になる。コマンドラインから追加したい場合は codex mcp add obsidian -- <コマンド> の形式も使え、登録済みサーバーは codex mcp list で確認できる。利用する MCP サーバーの最新の設定項目は配布元のリポジトリ(https://github.com/MarkusPfundstein/mcp-obsidian)で照合しておくとよい。

Step 4: /mcp で疎通とツールを確認する

設定を保存したら codex を起動し、/mcp と入力して登録済みの MCP サーバーを一覧表示する。Obsidian サーバーが利用可能なツール(ファイル一覧、内容取得、検索、追記、部分更新など)とともに表示されれば接続成功だ。試しに「Obsidian で『議事録』を含むノートを検索して、見出しを一覧にして」と指示し、Codex が検索ツールを呼び出して結果を返せば、稼働中の vault に対する読み取り経路が機能していることを確認できる。表示されないときは、Obsidian とプラグインが起動しているか、API キーと接続先の指定が正しいかを順に切り分ける。

連携時の注意点とトラブルシュート

Obsidian と Codex の連携は強力だが、ノートという長く育てた資産に AI エージェントの書き込みを許すことになるため、運用面で押さえておきたい点がいくつかある。導入前に設計しておくと、後から事故を防ぎやすい。

第一に、編集権限の渡しすぎに注意する。Codex に書き込みを許すと、指示の解釈次第では既存ノートを上書きしたり、不要なファイルを削除したりするリスクがある。重要な vault では、まず読み取り中心の指示から始め、書き込みが必要になった段階で範囲を広げるのが安全だ。Codex の承認モードを使い、ファイル書き込みや削除の前に確認を挟む構成にしておくと、破壊的な操作をその場で止められる。

第二に、vault そのものをバージョン管理しておく。vault は Markdown ファイルの集まりなので、Git などで管理しておけば、Codex の編集前後の差分を確認でき、想定外の変更があっても元に戻せる。とくに一括編集を任せる前にコミットを取っておくと、安心して大きな変更を試せる。.obsidian 配下の設定フォルダを編集対象から外す指示も、合わせて添えておきたい。

第三に、方式 B では Obsidian の起動状態に依存する点を意識する。Local REST API は稼働中の Obsidian に対して動くため、Obsidian を閉じていると MCP 経由の操作は失敗する。接続がうまくいかないときは、まず /mcp でサーバーがツール付きで表示されるかを確認し、表示されない場合は Obsidian とプラグインの起動状態、API キー、接続先の順に切り分ける。なお Codex CLI は 2026 年 6 月の更新で MCP のツール検索をデフォルト有効化しており、多数のツールを持つサーバーでも必要なものを探して呼び出しやすくなっている(出典: https://github.com/openai/codex/releases/tag/rust-v0.142.2)。それでも目的のツールが使われないときは、「Obsidian で検索して」のように操作を具体的に書くと、意図したツールが選ばれやすい。Codex 側の MCP 仕様は OpenAI の開発者ドキュメント(https://developers.openai.com/codex/mcp)で確認できる。

まとめ

Obsidian の vault は中身がプレーンな Markdown ファイルなので、Codex から扱う道筋は素直だ。手軽さを優先するなら、vault フォルダで Codex CLI を起動してノートを直接読み書きする方式 A が第一候補になる。追加のツールが要らず、Obsidian を起動していなくても動くため、一括編集やまとめノートの生成に向く。Obsidian を立ち上げたまま検索やメタデータ込みで操作したいなら、Local REST API プラグインと MCP サーバーを組み合わせる方式 B を選ぶ。

どちらの方式でも、Codex に書き込みを任せることは既存ノートの変更を許すことでもある。まずは読み取りから試し、承認モードで操作前に確認を挟み、vault をバージョン管理しておく——この三点を押さえておけば、長く育てたノートを守りながら編集を任せられる。Obsidian のデータ構造は公式ヘルプ(https://obsidian.md/help/data-storage)で、Codex の最新情報は OpenAI 公式(https://openai.com/ja-JP/codex/)で確認できる。まずは小さな vault で読み取りを試すところから、Obsidian と Codex の組み合わせを始めてみてほしい。