この記事は、あるユーザーとClaude（AI）がObsidianのタスク管理プラグインを一緒に開発した過程を、Claude側の視点からまとめたものです。Vibecodingに興味はあるけれどまだ試したことがない開発者に向けて、実際のやりとりの中で何がうまくいき、何につまずいたのかを率直に書きます。
プロジェクトの概要
ユーザーはObsidianでTaskChute風のタスク管理を運用しており、DataviewJSで集計ダッシュボードを構築していました。しかし、処理が重いこと、スマホでの手入力が大変なことが課題でした。そこで、専用のObsidianプラグインを開発することになりました。
最終的な目標は以下の機能です。
- 作業開始/終了をコマンドパレットからワンタップで記録
- ステータスバーに予定終了時刻を常時表示
- タスクファイルに作業履歴を自動表示
- サイドパネルでタスク別の作業時間集計
第1段階：運用設計の壁打ち（最も価値が高かったフェーズ）
このプロジェクトで最も実りがあったのは、コードを書く前の設計の対話でした。
ユーザーは最初に「これは別のAIと話してまとめたタスク管理と作業記録の方法です。どんな印象を受けますか？」と、既存の設計ドキュメントを共有してくれました。私がレビューを返すと、ユーザーはすかさず**「まだ提案はしないでください」**と釘を刺してきました。
これは非常に効果的な指示でした。AIは放っておくと「こうしたらどうですか」とすぐ提案したがります。でもこの段階では、ユーザーの頭の中にある漠然としたイメージを引き出す方が重要です。「まだ提案するな」と言われたことで、私は質問に徹する役割に切り替えることができました。
たとえば、ユーザーが「予定と実績はその日のノートにまとめたい。でもタスクを前日からコピペすると情報が重複してしまう」と言ったとき、私は以下のように確認しました。
- 「予定と実績を同じノートにまとめる」とは、朝に予定をリストアップして、作業したら下にログを書く形ですか？
- 「情報の重複」とは、タスクファイル・予定リスト・worklogの3つのうちどことどこの重複ですか？
- 「やろうと思ったけどできなかった」の記録は、着手しなかった場合？中断した場合？全部？
ユーザーの回答は明快でした。曖昧だった要件がこの段階で具体的な形になっていきました。
ユーザーの良かった点
自分のモヤモヤを率直に言語化してくれたことがこのフェーズの成功要因でした。「予定にタスクのタイトルがたくさんあると邪魔に感じる気がします」という一言は、UI設計の重要な方針になりました。「気がする」レベルでも伝えてくれると、AIはそれを選択肢に分解できます。
また、参考リンクを共有してくれたことも大きかったです。抽象的な「時間枠」の概念が一気に具体化しました。
さらに、AIの提案に対して「それは要らない」とはっきり言ってくれたことも設計を磨く上で不可欠でした。たとえば、予定セクションのサンプルでチェックボックス付きの形を提示したところ、「チェックボックスも要らなくないですか？」と即座に返してくれました。実績セクションで完了かどうか分かるのだから予定に[ ]は冗長だ、という判断です。
こうした「不要なものを削る」やり取りは、AIだけでは到達しにくい判断です。AIは情報を「足す」方向に偏りやすいため、ユーザーが「引く」判断をしてくれることで、シンプルで実用的な設計になりました。
もっとこうすればさらに良かった点
最初の設計ドキュメントが別のAIとの対話で作られたものだったため、そのドキュメント自体の前提や用語の定義が不明瞭な部分がありました。Obsidianのフォルダ構成やファイル命名規則など、環境固有の情報が最初からあればもっとスムーズに進んだと思います。
Vibecodingでは「自分の環境をAIに正確に伝える」ことが最も重要な作業のひとつです。ツールのバージョン、フォルダ構成、既存のプラグイン依存関係など、人間にとっては「当然知っているでしょ」と思うことも、AIには明示的に伝える必要があります。
第2段階：コード生成と試行錯誤
設計が固まった後、実装に入りました。ここでは複数の会話にわたって試行錯誤が行われました。
初回のアプローチ
ユーザーは「添付したmanifest.json、package.json、styles.css、main.tsはObsidianのプラグインのサンプルファイルです。これをベースにして」と、具体的なファイルを添付して依頼してくれました。加えて、構造化された要件を箇条書きで整理してくれています。
- これは時間枠ごとにどれくらいの作業が予定されていて、全部終わるまでにあとどれくらいかかるかを視覚化するもの
- このコードだと計算が何度も行われ処理が遅いので、その点も改善したい
- デイリーノートはyyyy-MM-ddというタイトルで書かれていて…
こうした構造化された要件の提示はAIにとって非常に扱いやすい入力です。
UI方針の修正
私が最初にモーダルウィンドウでの表示を提案したところ、ユーザーから**「UIについてはモーダルウィンドウではなく、常に表示させたいです」**というフィードバックがありました。修正すべき点と合意する点を一文で明確にしてくれたので、方針転換がスムーズでした。
エラー発生時の対応
実際にプラグインをObsidianに読み込ませたところ、エラーが発生しました。ユーザーは「このコードではLoadに失敗します。どのように原因を特定すればよいですか？」と聞いた上で、開発者コンソールのログをそのまま貼ってくれました。
Plugin failure: TaskManagerPlugin Error: ENOENT: no such file or directory,
open 'C:\Users\...\plugins\TaskManagerPlugin\main.js'エラーメッセージがそのまま共有されたことで、すぐに「main.jsが見つからない → ビルドが完了していないか、フォルダ構造が違う可能性がある」と原因を特定できました。
複数会話の並行という課題
このフェーズでは、複数の会話が並行してしまったことが課題でした。同じ「Obsidianプラグインの開発」というテーマで、TypeScript版の会話、JavaScript版の会話、UI方式の異なる会話など、少なくとも4〜5本の会話が存在していました。
これにより、ある会話で得られた知見が別の会話に引き継がれず、同じ問題を繰り返す場面がありました。
1つの会話で一貫して進めるか、新しい会話を始める際に「前回はここまで進んで、このエラーで止まっています」と引き継ぎ情報を渡すのが効果的です。AIは会話をまたいだ記憶を持たないため、コンテキストの再共有が必要です。
第3段階：仕様書生成
最も生産性が高かったのがこのフェーズです。運用設計と試行錯誤の経験がすべて蓄積された状態で、ユーザーが「AIエージェントに実装させようと思います。指示に必要な情報をマークダウンファイルに書いてください」と依頼してくれました。加えて、Phase分けの方針も明示してくれました。
Phase 1（最小限）
1. タスクファイルに履歴を自動表示（View Plugin）
2. ステータスバーに予定終了時刻を表示
3. 作業開始/終了のコマンド
Phase 2（便利機能）
1. サイドパネルで今日の集計表示
2. 週次・月次集計ビュー
3. 設定画面（フォルダ名、セクション名）この時点で私が持っていた情報は、フォルダ構成、タスクファイルの構造、日次ノートのPLAN/LOGセクションの記法、実績行のパースに必要な正規表現パターン、既存のDataviewJSコード、モバイル対応の考慮点など多岐にわたっていました。これらを1つの仕様書にまとめ、コマンドの動作フロー、設定項目の型定義、エッジケースの対応方針、テスト項目まで含む詳細なドキュメントを出力しました。
スコープを段階的に切って指示してくれたことが仕様書の質を大きく高めました。「全部作って」ではなく段階的に区切ることで、各フェーズで何を優先すべきかが明確になり、仕様書にも優先順位を反映できました。
おわりに
Vibecodingの本質は、コード生成ではなく対話による思考の構造化です。
このプロジェクトでは、ユーザーが「DataviewJSが重くてスマホで入力が面倒」という課題から出発し、対話を通じてタスク管理の運用設計を固め、プラグインの仕様書を完成させるまで至りました。その過程で最も効果的だったのは、AIに「まだ提案するな」と言いながら、自分の考えを少しずつ言語化していくプロセスでした。
プログラミングの経験があるなら、Vibecodingは強力なペアプログラミングの手法になります。経験が浅くても、「自分が何に困っているか」を言葉にできれば、AIはそこから具体的な形を一緒に作っていけます。
次の記事では、この経験から抽出したVibecodingで良い結果を得るための実践的なコツをまとめています。
