Local REST API案から公式Obsidian CLIへ移行した理由
Obsidian連携は当初、ローカルMCPとコミュニティのLocal REST APIプラグインを候補にしていました。その後、Obsidian 1.12系で公式CLIが利用できるようになったため、ブログ作成の保存経路は公式CLIへ一本化しました。
移行を決めた理由
- Obsidian自身が提供するコマンドである
- Vault、ファイル作成、検索、読み取りを同じCLIで扱える
- ローカルHTTPポートやAPIキーを追加しなくてよい
- コミュニティプラグインの更新状況へ依存しない
- CLIで作成後、その場で読み戻して確認できる
Local REST APIが悪いという話ではありません。既存ワークフローや常時HTTP連携には適する場合があります。今回はデスクトップ上のObsidianとスクリプトをつなぐ用途だったため、公式CLIの方が部品を減らせました。
公式CLIの要件
2026年7月20日時点の公式ヘルプでは、Obsidian 1.12 installerが必要で、1.12.7以降へ更新したうえで「設定 > 一般 > Command line interface」を有効にする手順が案内されています。CLI利用時はObsidianアプリが起動している必要があります。
“`bash
obsidian vaults verbose
obsidian vault="Blog" create path="sample.md" content="# Sample"
obsidian vault="Blog" read path="sample.md"
“`
Vault名またはIDを最初のパラメータに置き、対象を明示します。カレントVaultや最後に開いたVaultへ暗黙に書く運用は避けます。
更新後に古いプロセスが残る落とし穴
実際の移行では、アプリ本体が1.12.7へ更新済みでも、更新前から起動していたObsidianプロセスがCLI接続を持っていませんでした。Obsidianを通常終了して再起動すると、CLIからVault一覧を取得できました。
「ファイルのバージョン」と「現在動いているプロセスのバージョン」が一致するとは限りません。アプリ更新後は再起動とCLI疎通確認までを一組にします。
旧経路は段階的に止める
移行時は、旧MCP/REST経路とCLI経路が同じノートへ同時に書かないようにします。新経路で作成・読み戻しテストを行い、日次処理を一件移した後、旧経路を無効化します。監査ログとバックアップは一定期間残します。
再現チェック
- [ ] Obsidian installerが1.12.7以降
- [ ] Command line interfaceを有効にした
- [ ] アプリを再起動した
- [ ] Vault名またはIDを明示した
- [ ] 作成後にCLIで読み戻した
- [ ] 旧経路との二重書き込みを止めた
次回は、これまでの実装記録を公開記事へ変換する匿名化ルールを紹介します。
参考にした一次情報
- [Obsidian CLI公式ヘルプ](https://obsidian.md/help/cli)
- [Obsidian—Update Obsidian](https://help.obsidian.md/Getting+started/Update+Obsidian)