小説より圧倒的漫画派の人間、柴犬花子です。文章だけの計画書、正直つらくないですか？
「結局なにが変わるの？」を一目で分かるようにしたくて、Claudeに計画を出すたびに図を描かせてみました。うまくいかなかったところも含めて、やったこと・書いたルール・結果をそのまま並べます。
1. まずルールを作った
やったこと: 「計画のたびに図も描いて」とお願い。書き方の細かい判断はClaude任せにした。
書き込んだ内容（MEMORY.md）
実装計画・作業計画を提示する際は、文章だけでなく必ずMermaid図も作成する
- 手順が少なく単純な計画はチャット内にそのまま埋め込む
- ファイル数が多い・依存関係が複雑な計画はArtifactとして別途共有する
- どちらを使うかはClaude自身の判断に任せる
結果: 図が出なかった。 原因は「メモリの要約」自体は読んでいたが、詳細ファイルを開いて確認する工程を省いていたこと。情報がなかったのではなく、確認していなかった。
2. 図は出た。でも内部構造止まり
やったこと: 別の作業（マスコットアプリをアイコンクリックだけで起動できるようにする計画）を依頼。
出てきた図
結果: 正確だけど分かりにくい。 .appの内部構成という実装詳細で、知りたかった「そもそも何が変わるのか」が伝わらない。
3. 「全体像を先に」を追記
書き込んだ内容（MEMORY.mdに追記）
計画提示時のMermaid図は、内部の実装詳細（ファイル構成・技術的な内部構造等）ではなく、
「全体として何が変わるのか」を一目で把握できる図（例: 現状→変更後の比較、大まかな流れ）を
最初に置く。実装詳細の図が必要な場合は、全体像の図とは別に、詳細セクションに補足として添える
出てきた図
結果: 欲しかった図。 「現状」と「変更後」を並べるだけで、何が変わるのか一目で分かるようになった。
4. さらに深掘り：もっと直感的にするには
やったこと: 「本質は図を付けることじゃなく、5秒で変化が分かること」だと気づき、CLAUDE.mdにルールを追記。
書き込んだ内容（CLAUDE.md）
## 計画提示時の図の書き方
- 1枚目の図では、ファイル名よりも「ユーザーから見た変化」を書く
- 技術名（フレームワーク名等）は出してよいが、必ず「何を担うか」も添える
- 実装名（コンポーネント名等）は構成図・変更対象一覧側に出し、全体像図には出しすぎない
- 責務図では「どこで業務ルールを保証するか」を明示する
- 関係図では正常系だけでなく、重要な分岐があれば1つだけ足す
- 小修正でも全体像図は基本つける。構成図・責務図・関係図は変更が単純なら1枚にまとめてよいが、全体像と実装詳細は混ぜない
### 表現の置き換え例
- `Container.tsxを修正` → `承認可否の表示条件を整理`
- `APIレスポンスを変更` → `画面が判断に必要な情報を受け取れるようにする`
結果: 図の役割分担を4種類に整理。 「全体像」「利用技術・担当領域」「責務の分担」「関係・流れ」に分けて、そのまま使える計画テンプレートに落とし込んだ。
5. 実践投入：カエレ鳥アプリ
やったこと: テスト題材（毎日19:00に鳥が画面端から出てきて「そろそろカエレ！！」「クエエエエ！！！」と急かすアプリ）で計画書を作らせた。
起きたこと: チャット本文へのMermaid埋め込みが図として描画されない環境だった。 コードブロックがそのままテキスト表示された。
書き込んだ内容（MEMORY.md修正）
チャット本文への埋め込みでは描画されない環境があるため、
簡単な場合でも図はArtifactとして発行する
結果: 完成した全体像図
| 案 | 内容 | 長所 | 短所 |
|---|---|---|---|
| A（推奨） | 単一のHTMLファイル、setIntervalで毎分時刻チェック、ブラウザタブで開いておく | 一番簡単・すぐ試せる | タブを閉じると動かない |
| B | Web Notifications API + Service Worker | タブを閉じていても動く | 実装がやや複雑、通知許可が必要 |
| C | デスクトップ常駐アプリ（Electron等） | 最も確実に毎日19時に出る | 環境構築の手間が要る |
責務図・実装方針比較表もあわせて提示され、「何が起きるアプリか」を先に理解してから実装案を比較できる構成になった。
まとめ
- 最初の図は実装手順ではなく「変化の要約」にする
- ルールは一度作って終わりではなく、出てきた図を見て直す
- 「簡単ならチャット内埋め込みでOK」は環境依存。実際に描画されるか確認する
文字だと頭に入りづらい人はぜひ試してみてください。