Claude Code × Electron：プロンプトだけでデスクトップTodoアプリを作る
目次
はじめに
最近話題のClaude Codeを使った「バイブコーディング」が気になり、入門書を読んでみました。
せっかくなので実践してみようと、ElectronでデスクトップのTodoアプリを作ることに。ただし今回は自分でコードを一切書かず、プロンプトだけで完成させるというルールを設けました。
この記事では、作ったものの紹介と、実際に書いたプロンプト、そしてうまく作るために工夫した点をまとめます。これからClaude Codeを試してみたい方の参考になれば嬉しいです。
作ったもの：ElectronのTodoアプリ
今回作ったTodoアプリは通常のものと異なります。
私が普段服薬をしたかどうかたまに忘れてしまうことがあるので、1日の中でやるタスクに期限の時間を設定して24時を過ぎるとタスクのチェックがリセットされるようにしました。
期限の順に自動で並び、アプリケーションのウィンドウがアクティブでないときは必要な部分のみ半透明で表示します。
今回のルール：コードには触らずプロンプトだけで作る
今回作るにあたってのコンセプトとしてClaude Codeにコーディングをしてもらい、ある程度アプリケーションが出来たら実装の流れを後から追ってElectron、TypeScriptでの実装の仕方を学ぶという点を設定しました。
私自身Electron、TypeScriptに対して習熟しているわけではないのでローカルアプリケーション開発の流れを掴むことを目標としました。
そのため今回は始めにElectron開発用テンプレートとして、書いたプロンプトやそこからどのような作業が行われたかという概要を1つのプロンプトごとまとめるという仕組みを作成してから具体的なアプリケーションの内容の開発を行うようにして、後からどのようなことを行なったか遡れるようにしました。
また、ネットワーク通信を現段階では行わない方針で作ったので、わかりやすくやりやすい課題になったと思います。
Electron開発用のテンプレート
https://github.com/TKano-Null/electron-template
プロジェクトルートでClaude Codeを実行することでhistoryフォルダに実行した内容がまとめられて行きます。
また、CLAUDE.mdおよびdocsフォルダには最低限守りたいルールが書かれており、実装するごとにルールが足されていきます。これによりより正確にClaude Codeに意図が伝わりやすくなるものと思われます。
開発の流れ
- CLAUDE.md、設計docs、実装ステップに分けて完了条件を決める
- フックでプロンプト履歴と操作履歴を自動で記録する仕組み(election-template)
- 機能追加時「docsを更新->ステップに分けて実装」を繰り返し
実際に書いたプロンプト
プロジェクト開始時のプロンプトです
## #1 設計案の作成と CLAUDE.md の作成（2026-09-27）
### プロンプト
```
ElectronでローカルのToDoリストアプリを作りたい。まだ実装はせず、設計案を出してほしい。
最初にCLAUDE.mdを作成したい。
要件:
- タスクの追加・編集・削除・完了切り替え
- データはローカルに永続化（アプリ再起動後も残る）
- オフラインで完結
技術方針:
- TypeScript
- contextIsolation有効、nodeIntegration無効、preload経由のIPCのみ
- レンダラーのUIフレームワークは提案して（理由付きで）
- 永続化の方式も候補を比較して提案して
出してほしいもの: ディレクトリ構成、IPCのAPI設計、データモデル、実装ステップの分割案
```
### 実施内容
- `CLAUDE.md` を作成（機能要件、技術スタック、ディレクトリ構成、セキュリティ規約、アーキテクチャ規約、コーディング規約）
- 設計案をチャットで提示
- UI フレームワーク: React + Vite（electron-vite）を推奨（Svelte・Vanilla TS と比較）
- 永続化: JSON ファイル＋アトミック書き込みを推奨（electron-store・SQLite・IndexedDB と比較）
- IPC API: `todo:list` / `create` / `update` / `toggle` / `remove` の5チャネル
- データモデル: `Todo`（id・title・completed・createdAt・updatedAt）と `TodoStore`（version・todos）
- 実装ステップ: 雛形 → 永続化 → IPC → UI（表示・追加）→ UI（編集・削除・切り替え）→ 仕上げ →（任意）E2E・パッケージ化
### 成果物
- `CLAUDE.md`
---
## #2 設計内容を docs フォルダに .md として保存（2026-09-27）
### プロンプト
```
出して欲しいものとして挙げた各項目を.mdファイルに纏めたい
新しくdocsフォルダを作成してそこに.mdファイルを保存して
```
### 実施内容
- `docs/` を作成し、設計案を項目ごとのファイルに分けて保存
- チャットの設計案から次の点を具体化
- 壊れた保存ファイルは退避してから空で起動する
- IPC の入力検証ルール（`title` は 1〜200 文字など）
- 各実装ステップの完了条件
- `CLAUDE.md` に設計ドキュメントへのリンクを追記
### 成果物
- `docs/tech-decisions.md`
- `docs/directory-structure.md`
- `docs/ipc-api.md`
- `docs/data-model.md`
- `docs/implementation-steps.md`
- `CLAUDE.md`（更新）
---Code language: PHP (php)この二つのプロンプトで大まかなドキュメントを設定し、それに追記してくれるようになるルールが定められます。
そのため、ドキュメント更新とは言っても直にファイルをチェック修正しても良いのですが、基本的にプロンプトで追記修正していってくれるようになります。
機能追加時のプロンプトです。
## #20 期限（時刻）機能の docs 更新（2026-10-17 18:39）
### プロンプト
~~~~
期限日機能を追加したい。仕様は以下。まずプランモードで docs（data-model / ipc-api /
implementation-steps）の更新案を出して。実装はステップごとに分けて、承認後に進める。
- 各タスクに任意の期限(hourとminuteのみ)を設定できる
- 期限切れの未完了タスクはタスクの右側に赤い四角を表示する
~~~~
### 実施内容
- 仕様をユーザーに確認: 期限は時刻のみ（HH:MM。日付は持たず毎日リセット）、追加時に設定し後から変更・解除もできる
- プランの承認後、docs を更新（コードは未変更）
- `Todo.dueTime?: string`（"HH:MM"）を追加。任意項目なので `version` は 1 のまま、既存ファイルはそのまま読める
- patch の `dueTime: null` で期限を解除。期限切れの判定は `isOverdue(todo, now)`（期限ちょうどの分は期限切れでない）
- IPC のチャネルは追加せず、create / update の引数と入力検証のルールを拡張
- 実装ステップに「ステップ8: 期限（データ・IPC）」「ステップ9: 期限（UI）」を追加
- `CLAUDE.md` の機能要件に期限機能を 1 行追加
- コミットはしていない
### 成果物
- `docs/data-model.md`
- `docs/ipc-api.md`
- `docs/implementation-steps.md`
- `CLAUDE.md`
- `history/prompt-history.md`（更新）
---
## #21 実装ステップ8: 期限（データ・IPC）（2026-10-17 19:16）
### プロンプト
~~~~
ステップ8を実装
~~~~
### 実施内容
- `history/.current-step` を `step-08` にして開始し、終了後に削除
- `node_modules` が無かったので `npm ci` を実行。動作確認のため `node node_modules/electron/install.js` で Electron 本体も取得
- `src/shared/dueTime.ts` を追加: `isDueTime`（HH:MM の形式チェック）、`toDueTime`（ローカル時刻 → HH:MM）、`isOverdue`
- 型に `dueTime` を追加（`Todo` / `CreateTodoInput` / `UpdateTodoPatch`。patch の `null` は解除）
- `todoRepository.ts`: `isTodo` で `dueTime` を検証（無ければ可。`version` は 1 のまま）、create で保存、`dueTime: null` でキーを削除
- `validation.ts`: `parseDueTime` を追加し、create / patch で `dueTime` を受け付ける
- テストを追加（71 → 114 件。すべて成功）: 既存形式のファイルがそのまま読める、不正な dueTime のファイルは退避、設定・変更・解除、検証、`isOverdue` の境界
- 完了条件を確認: `npm run typecheck` / `npm test` が成功。一時的な user-data-dir に既存形式の `todos.json` を置いてビルド版を起動し、DevTools プロトコル経由で `window.api` の create（dueTime 付き）→ update（null で解除）、不正な期限の拒否を確認。既存のタスクは退避されずに残った
- `CLAUDE.md` の現状とディレクトリ構成、`docs/directory-structure.md`（`dueTime.ts`・`tests/shared`・shared 層の説明）を更新し、ステップ8 のチェックを付けた
- コミットはしていない
### 成果物
- `src/shared/dueTime.ts`（新規）
- `src/shared/types.ts`
- `src/main/todoRepository.ts`
- `src/main/validation.ts`
- `tests/shared/dueTime.test.ts`（新規）
- `tests/main/todoRepository.test.ts`
- `tests/main/validation.test.ts`
- `tests/main/ipc.test.ts`
- `CLAUDE.md`
- `docs/directory-structure.md`
- `docs/implementation-steps.md`
- `history/prompt-history.md`（更新）
---Code language: PHP (php)全文はファイルとして
プロンプトで工夫した点
ドキュメント更新時はプランモードで実行し、内容が伝わったことを確認してからautoモードでドキュメント更新をした。
実装時は既にstepに別れているため、step00の実装と書くだけで実装フェーズが完了する
AIと作ってみた感想
うまくいったこと：小さなStepの設定、docsを正とする運用、履歴が残ること
人間が注力するべきこと：仕様を決めること、見た目の確認、各OSでの実機確認
まとめ
比較的短時間で、自分の欲しい要件を満たした1日限定Todoリストを作成する事ができました。
Claude Codeでいきなり作ろうとするよりもドキュメントを作成し、それベースで進めると進行しやすかった。
課題として、単純なアプリにも関わらず非常にファイルおよびメモリ使用量が多いことです。
これはElectronでは仕方のないことです。
軽量化のためにTauriで作れないかと試しており、今回作ったもののドキュメント部だけをコピーして、Tauri用に書き換えることは容易にやってくれるようでした。これもドキュメントベースで作成したことのメリットだと思います。
Tauriは軽いメリットがありますが、環境によって動作が異なる可能性があるため、本当に作り込むならば選択肢として良いものではあるが、とりあえず形にしたいということであればElectionの方が優れていると思います。
コメントを残す