Claude Codeを使って、Obsidianプラグインを作ってみた体験記です。
まさかこんなに爆速で成果が出るとは驚愕しました!
作ったもの
Obsidian内でファイル・フォルダのパスをコピーするだけのプラグインです。
- 右クリックメニューに「物理パスをコピー」「Vault相対パスをコピー」を追加
- クリックすると、該当のパスがクリップボードにコピーされる
やったこと
1. 初期プロジェクトの準備
まずは、プラグイン用のフォルダを作成し、以下の内容の README.md
を配置しました。
# Copy Path Obsidian Plugin
Obsidian用のファイルパスコピープラグインです。Vault内のファイルやフォルダを右クリックして、物理パスやVault相対パスを簡単にクリップボードにコピーできます。
その状態で、claude
コマンドを用いてClaude Codeを起動、CLAUDE.md
を作成してもらいました。
/init
生成された CLAUDE.md
の内容は以下です。
このファイルは、このリポジトリでコードを扱う際のClaude Code (claude.ai/code) へのガイダンスを提供します。
## プロジェクト概要
これはファイルパスをコピーするためのObsidianプラグインプロジェクトです。このプラグインにより、ユーザーはVault内のファイル・フォルダを右クリックして、物理的なパスやVault相対パスをクリップボードにコピーできるようになります。ObsidianプラグインはObsidian知識管理アプリケーション内で動作するTypeScriptベースの拡張機能です。
## 開発コマンド
これは新しいObsidianプラグインプロジェクトのため、一般的なコマンドは以下の通りです:
- `npm install` - 依存関係をインストール- `npm run build` - プラグインをビルド- `npm run dev` - 開発モードでビルド(監視モード付き)- `npm run lint` - ESLintを実行
## アーキテクチャ
Obsidianプラグインは通常以下の構造に従います:
- `main.ts` - ObsidianのPluginクラスを継承するメインプラグインクラス- `manifest.json` - プラグインのメタデータと設定- `package.json` - Node.jsの依存関係とスクリプト- プラグイン機能は以下を通じて実装されます: - コマンド(`addCommand()`で登録) - リボンアイコン(`addRibbonIcon()`経由) - 設定タブ(`addSettingTab()`経由) - Obsidianライフサイクルイベントのイベントハンドラー
## 主要概念
- プラグインはObsidian APIの`Plugin`クラスを継承する必要があります- `onload()`メソッドでプラグインを初期化します- `onunload()`メソッドでリソースをクリーンアップします- `this.app`経由でObsidianアプリインスタンスにアクセスします- ファイルシステム操作にはObsidianのVault APIを使用してください- UI コンポーネントは可能な限りObsidianの組み込みコンポーネントを使用してください
## プラグイン固有の機能
このプラグインはファイルパスをコピーするためのコンテキストメニュー機能を実装します:
- コンテキストメニュー項目は'file-menu'または'folder-menu'イベントで`registerEvent()`を使用して登録してください- クリップボード操作には`navigator.clipboard.writeText()`またはObsidianの`navigator.clipboard` APIを使用してください- ファイルパスは`file.path`(Vault相対)または`this.app.vault.adapter.path.join()`(絶対パス)で取得できます- プラグインはファイルエクスプローラーでファイルとフォルダの両方を処理する必要があります
そもそも Obsidian プラグインの作り方を何も調べずにやってるので、 へー、nodeで作るんだーという感想です。 この時点でもうすごい。。
2. 作業計画作り
次に、作業計画を立てるため、以下のスクリプトで PLAN.md
に初期セットアップの内容を書き出してもらいました。
このプロジェクトはまだ空っぽなので、Obsidianプラグインを開発するのに必要なセットアップから始めていきます。セットアップ方法を調べて、何をする必要があるのか、作業計画を @PLAN.md に書き出してください。なお、初期セットアップのみを書き出してください。プラグインの中身を作成するところまで含めないでください
これで、あってるかどうかわからない PLAN.md
ができました。
どうやってObsidianのプラグインを作るのかはよくわかんないですが、
見た感じ出来そうに見えるからすごい。
問題なさそうなので作ってもらいます。
では、 @PLAN.md どおりに作業して
@
でファイル名を明示的に指定できます。
あとは出来上がるまで放置。 うまくいってるかどうかはわからないものの、
⏺ @PLAN.mdの通りに初期セットアップが完了しました!
✅ 完了した作業: - 基本ファイル構造の作成(package.json, manifest.json, main.ts, tsconfig.json, versions.json, styles.css) - 依存関係のインストール(npm install) - TypeScriptビルドプロセスのテスト(main.js生成成功)
📝 現在の状況: - プラグインの基本構造は整いました - ビルドプロセスは正常に動作しています - ESLintの設定でパッケージの互換性問題がありますが、開発には影響しません
🚀 次のステップ: セットアップが完了したので、実際のプラグイン機能(コンテキストメニューとパスコピー機能)の実装に進むことができます。
できたらしいです。
3. ドキュメント更新を頼む
プロジェクトセットアップできたので、ドキュメントを更新してもらいます。
@README.md と @CLAUDE.md を更新して
結果、情報量が格段に増えました。
特に README.md
とか、いまいち何を書くべきか迷うしめんどくさいので、
勝手に情報を拾って書いてくれるのは非常に助かります。
4. 実装フェーズに移行
指示して実装してもらいます。
# Claude Code内で実行プラグインの実機能の開発に入ります。Chain-of-Thoughtアプローチで作業を分解して、PLAN.mdファイルの中身を一から書き直してください。
これでまた、あってるかどうかわからない PLAN.md
ができました。
妥当な内容なのかどうかは判断できないので、そのまま進めてもらいます。
# Claude Code内で実行では、作業に入ってください。フェーズが進むごとにコミットしてくださいPLAN.mdの更新も忘れないようにお願いします。
これで勝手に進めてくれました。
5. 型エラー対応
作業中、main.ts
にTypeScriptの型エラーが発生したため、
ESC
で中断して、修正の指示を出しました。
@main.ts にTypescriptの型チェックエラーが出てるので確認してください
過去の経験上、こういう型エラーははまりがちです。
今回も、 as any
をつけて回避しようとしたので、叱りました。
'folder-menu' で型エラーが出ているというとこは、 'folder-menu' は使えないということです。何を指定すべきなのかを調べて対処してください
これで、ちゃんと色々検索して調べてくれました。
なお、次回以降も同じ対処をしないように、メモリ(CLAUDE.local.md
) に記憶させておきます。
# 型エラーは as any しないでちゃんと調べて解決する
Claude Code内で #
から入力すると、メモリ保存モードになって、簡単に覚えさせることができて便利です。
あとは放置してたら出来上がりました。 たびたび途中で止まるので、「先に進めて」と促す必要はありました。
作った内容をもとに、再度 README.md
も更新してくれてました。
PLAN.md
をよくみたら、もともと修正予定に入ってたっぽい。できる子。
あと、 TEST_GUIDE.md
っていう、テストのやり方とテストケースを書いたドキュメントも作ってくれてました。
テスト用のVault作って、フォルダとファイルを作って、こうやってプラグインを読み込んで、みたいなことが書かれてました。恐ろしい子。。
6. テスト環境の構築
最後に、テスト用のVaultを作成し、テスト用のフォルダ・ファイルを作ってもらいました。
test-vault を作ったので、中にテスト用のフォルダとファイルを作って
なんと、ファイルとフォルダを作るだけでなく、 テスト用Vaultにプラグインもコピーしてセットアップしてくれました。
ちょっと気が利きすぎて怖いです。
試したらあっさり動きました。これやべぇ。
感想など
これぐらいの小規模なツールであれば、作り方とか知らなくてもできちゃうことがわかりました。 ただ、ちゃんと「調べて」って言わないと、事前学習した知識だけで進めようとするから、 その点は丁寧に指示する必要がありそう。
あと、Chain-of-Thoughtアプローチでタスク分解させる、 どうやろうとしてるかをドキュメントに書かせるのも有効な気がします。
特に、ドキュメントに書かせることで内容確認もしやすくなるし、 一回セッションクリアしても再開しやすくなる。 その点で、進捗をちゃんと自分で記録させておくのも大事な気がしました。
これは、今までめんどくさくてやってこなかったこのブログの修正も捗りますね😅
参考サイト
- LLMの制約を味方にする開発術 - Zenn
- Chain-of-Thoughtアプローチはこれで知りました。自分でやるのはめんどくさいけど、やらせるのはすごく良い。
- タスクリストとタイムスタンプ付き設計ファイルを使って既存プロダクト開発にもCline,Copilot AgentでAIコーディングする - Zenn
- AIの作業計画をドキュメントに書かせるアイデア。指示内容もドキュメントに書いていいというのは目から鱗でした。