Claude Codeでの開発、捗ってますか？最近、Opus 4.7 がリリースされたり、日々様々なTipsや手法が公開されてます。 その中でもPlan modeを使った開発をしている人は多いのではないでしょうか。

Plan mode×Opus 4.7 の組み合わせは、止まることもエラーを出すこともなく、プランから実装まで一気に走り切ってくれるような頼もしさがあります。一方で、使い続けるうちに「これは自分のやり方とは違うかも」「思うように実装ができない」と感じる場面が増えてきました。

そこで、本記事では、Plan mode を使わずに grill-me スキル + ADR（Architecture Decision Records） で設計を固めて個人アプリを作り、そのなかで気づいたことを共有します。

対象読者

• Opus 4.7 のハンドリングがうまくいっていない方
• 「Plan mode = 良いもの」とされる空気に違和感のある方
• 自分の設計に抜けがないか、第三者視点で確認したい方

1. Plan mode に感じた違和感

1-1. Opus 4.7 の強みと弱み

Opus 4.7 は、プランから実装までを止まらずに走り切ってくれます。最初は率直に驚かされ、「これで十分だ」と思いました。

しかし使い続けるうちに、いくつか引っかかる点が出てきました。

• プランは長いが「それっぽい」ものが出てくるので、なんとなく承認してしまう
• プランが何かの基準に沿って作られているわけではないため、実装するたびに方針がブレる
• Sonnet 4.6 で対話的に進めた方が、実装は遅いものの確認の認知負荷が低く、確実なものができている感覚があった

1-2. 基準のないプランの問題

前述の通り Opus 4.7 は実装力が高いからこそ、ブレたプランでも ブレたまま忠実に実装し切ってしまいます。結果としてコードベースが発散します。

実際、

• 既に存在する関数が、別の場所で再実装される
• フロントエンドで store + useContext で読む実装と、props drilling + 大量のコールバックで渡す実装が同じコードベース内に混在する

一度ブレた実装はコードベースに残り、次の実装はそれを土台にしてさらにブレていきます。プラン自体は毎回それっぽいので、止める動機が生まれません。気づけば「これほど実装量が必要だったか」というところまで膨らんでいました。

これは Plan mode の問題というより、「基準がない」状態で実装力の高いモデルを走らせることの問題だと感じています。

2. grill-me で深堀り、「決定」を ADR として残す

2-1. grill-meを知ったきっかけ

たまたま grill-me スキルを紹介する動画 を見つけました。スキル自体は SKILL.md を見ればわかる通り、たった数行しかありません。

※元のスキルを日本語に翻訳し、日本語で使えるようにしました。

---
name: grill-me
description: 計画やデザインについて、共通理解に達するまでユーザーに徹底的にインタビューし、意思決定ツリーの各分岐を解決する。
---

共通理解に達するまで、この計画のあらゆる側面について徹底的にインタビューしてください。意思決定ツリーの各分岐を順にたどり、決定事項間の依存関係を一つずつ解決してください。各質問には、あなたの推奨回答も提示してください。質問は一度に一つずつ行ってください。

短いです。この「一度に一つずつ」「推奨回答も提示」「意思決定ツリーの各分岐を解決」という指示は、自作の深掘りするスキルで入れていきたいと感じました。

なお、スキルは ~/.claude/skills/<skill-name>/SKILL.md に配置すれば /grill-me として使えます（プロジェクト直下の .claude/skills/ に置けばプロジェクト専用にもなります）。詳しくは公式ドキュメントをご覧ください、

2-2. grill-me vs Plan mode

実際に試したプロンプトはシンプルです。

/grill-me 個人向けサブスクリプション管理アプリを作成したい。なににいくら使っていて、無駄なモノに入っていないか、一時的な加入で解約を忘れないようにしたい

ここから1問ずつ質問が来ます。Plan mode と違ったのは、まず質問が1問ずつ来ること。最初に全体プランを差し出されないので、考えるテンポを自分側で持てます。

次に、理由付きの推奨と対抗馬が一緒に提示されます。実際の出力は次のとおりです。

Q4: フロントエンドのフレームワークPWA + Supabase という組み合わせなら、Supabase の JS SDK と相性のいいフレームワークを選びます。

私の推奨：Next.js（App Router）

理由：
- Supabase 公式テンプレート・ドキュメントが最も充実
- Vercel に無料でデプロイでき、PWA 化も簡単
- Server Components で DB 問い合わせを書きやすく、  サブスクリストのような「DBの内容そのまま表示」が得意
- 将来「メール解析でサブスク自動検出」みたいなサーバー処理を  足したくなった時にも API Routes で対応可能

対抗馬：
- SvelteKit：軽量で書きやすい。Supabase との統合も良好。
- Vite + React (SPA)：シンプル。SEO 不要・サーバー機能不要なら最軽量。
- Remix：Next.js と近いが、コミュニティ規模で劣る。

「個人用で他人に見せない」前提なら、Next.js はオーバースペックです。
Vite + React だけで作るのが最もシンプルで、サーバー側ロジックはSupabase Edge Functions に寄せる、という選択肢も強いです。

「Claude が決めたプランを承認する」のではなく、理由付きで提示された選択肢を自分が選ぶ側に回ります。

そして一番大きいと感じたのは、変更時に「これまでの決定全体」との整合性を取れるようになったことです。Plan mode で「やっぱりこうしたい」と言うと、そのプランの中だけで辻褄が合わされます。grill-me で決めた内容を ADR に残し、以後の相談で ADR を参照させる運用にしたところ、過去に決めた事柄と新しい変更との整合性を、こちらが意識しなくても取りに来てくれるようになりました。決定が「プラン」という揮発するものに乗っているか、「ADR」という積み上がるものに乗っているか、の違いが効いています。

2-3. 決定を ADR として残す

今回、実際のアプリケーション開発を通じて、grill-me スキル + ADR（Architecture Decision Records）の組み合わせを検証してみました。

題材としたアプリは、個人向けサブスクリプション管理アプリです。「何にいくら使っているかを可視化したい / 一時加入の解約忘れを防ぎたい」というよくある個人課題です。

今回の開発では Plan mode を一度も使っていません。設計フェーズは grill-me で意思決定を進め、結果を ADR として残しました。実装では ADR を参照させながら Claude Code に実装させています。

最終的に残った ADR は8本になりました。

docs/adr/latest/
	├── 0001-platform-and-deploy.md
	├── 0002-tech-stack.md
	├── 0003-baas-and-auth.md
	├── 0004-data-model.md
	├── 0005-paused-status.md
	├── 0006-notification-strategy.md
	├── 0007-ui-and-visualization.md
	└── 0008-testing-strategy.md

設計・デザイン段階での活用例を紹介します。

思い付きを設計する

データモデルで、status カラムは当初 active / cancelled の2値でした。実装を進めているうちに、「ジムを2か月だけ休会」「観たい作品が来るまでNetflixを一旦止める」など、一時的な状態があることに気づきました。Plan mode だと「paused という一時停止中の状態を追加して」という指示で終わっていたところを、grill-me を挟むことで「cancelled に丸めると節約効果が出せない」「active のままだと月額合計に含まれて実態と乖離する」ところまで考えを深められました。

また、grill-me は データモデルの変更だけで終わらせませんでした。

• paused の正確な定義は？（課金停止だが再開予定がある、cancelled は永続終了）
• 集計対象に含めるか？（含めない。実際に払っていない＝節約状態）
• 通知対象に含めるか？（含めない）
• 一覧 UI ではどう表示する？（「アクティブ／休止中／履歴」の3タブに拡張、active には混ぜない）
• 再開予定日は専用カラムを持つか？（持たない。memo に自由記述）
• 自動 active 化バッチは作るか？（作らない。「勝手に課金状態に戻った」誤解のリスク）

定義 → DB → 集計 → 通知 → UI → 状態遷移、と網羅して確認した結果、「単なる思い付き」が設計として以下のように決まりました。

## 決定

**`status` に `paused` を追加**し、active / paused / cancelled の3値とする。

### 集計・通知の扱い

- 月額合計・年額換算・カテゴリ別グラフ・期限近リスト・メール通知
  → **すべて `status = 'active'` のみ対象**
- `paused` は集計にも通知にも含めない

### 一覧UIの扱い

- ホーム画面のタブを **「アクティブ／休止中／履歴」の3タブ** に拡張
- `paused` は専用タブで管理し、`active` 一覧には混在させない

ADRをデザインに活かす

もう一つ、ADR が「文書」ではなく「基準」になっている例として、ログイン画面のデザインを取り上げます。

認証では、Supabase Auth の Magic Link 方式 を採用すると決めました。パスワードを持たない、メールにリンクが送られて、それをクリックするとログインできる、という方式です。

## 決定

**Supabase** を採用する。

- DB は PostgreSQL（Supabase 提供）
- 認証は **Supabase Auth の Magic Link** 方式。パスワード管理不要
- 当面は **単一ユーザー前提**。ただし全テーブルに `user_id` カラムを設け、
  Row Level Security（RLS）で「自分のデータのみ参照可」をDB側で強制する

この決定が、実際のログイン画面のデザインにどう反映されているかを見てみます。

• 入力項目はメールアドレスのみ。パスワード入力フィールドが存在しません。Magic Link 方式の決定が、そのまま UI に現れています
• ボタンのラベルが「ログイン」ではなく「ログインリンクを送信」になっています。方式の特性に合わせた言葉選びで、さらにボタン下に「パスワードは不要です。送信されたメールのリンクをタップしてログイン」という補足まで添えられています
• アカウント作成タブと「ログイン」タブが分かれていません。Magic Link 方式では新規/既存をフォーム上で区別しないためです

ここまで決まった状態で Claude Design に渡せたので、Design 側は 「要件を考える」フェーズをスキップして、デザインの判断に集中できました。

そして面白かったのは、Design 中に「ここはこう変えたい」という変更が発生したとき、それを Claude Code に連携して再び grill-me で意図を確認し、ADR に反映するという往復ができたことです。Code 側の決定と Design 側の決定が、ADR を介して整合性を保ったまま動きました。

3. 実装してわかったこと

良かったこと

自分で選択した設計が積み上がっているので、なぜそうしたかを自分の言葉で説明できます。

また、実装ごとにプランを立て直すのではなく、アプリ全体の決定が一箇所に残るので、機能追加のときに過去の決定との整合性が自然と取れました。

Code と Design の往復でも、ADR がハブになって両方向の変更を吸収してくれました。「あれ、これ前にも決めなかったっけ？」と記憶やドキュメントを探るストレスから解放された気分でした。

いまいちだったこと

• 時間がかかる：質問は約20問、所要時間は 約40分です。設計に40分かけることを「長い」と見るか「コードが発散して直す時間より短い」と見るかは、人によります
• チーム運用は要工夫：個人なら自分の裁量で全質問に答えられますが、チームだとメンバーごとに回答が異なり、ADR が乱立します。前提として「チーム/製品の方針が共有されている」必要があります
• ADR はレール：実装の質そのものは個人の技量に依存します。ADR は方向性を揃えますが、実装の質までは保証しません。

個人開発や、設計フェーズだけでも揃えたい場面なら、「grill-me スキル + ADR（Architecture Decision Records）」が有用だと感じました。

【コラム】 ADR を腐らせない運用 — adr-manager スキルを自作した話

そもそも ADR（Architecture Decision Records） とは、「なぜこの技術／設計を選んだのか」という意思決定を、決まった形式（コンテキスト・決定・結果）で一つずつファイルに残していく文書のことです。新しい決定が増えたら新しいファイルが増え、過去の決定はそのまま残ります。

実はこの ADR という言葉に出会ったのも、grill-me と同じ あの動画 がきっかけでした。grill-me で意思決定を引き出し、その結果を ADR として残す、という流れがセットで紹介されていました。

言葉と出会ったとき、「ADR を残せばすべてうまく行くのでは？」と一瞬思いました。同時に、過去にチームでドキュメント駆動の基準作りをやろうとして、何度か失敗してきたことを思い出しました。似た名前のドキュメントが増え、いつ書かれたかわからない古文書が残り、技術スタックの記載は古いまま放置される等々...

「ドキュメントは書いた瞬間から腐り始める」とよく言われますが、本当にその通りです。ADR も例外ではありません。だからこそ、新鮮なドキュメントを残し続ける仕組みが必要だと感じて、adr-manager という小さなスキルを自作しました。スキルの詳細は以下に示します。

ディレクトリ構成

docs/adr/
├── latest/ # 現行版。各ADRは一つだけ。
│ └── NNNN-{slug}.md
└── archive/ # 旧版を番号ごとのサブディレクトリで保管。
└── NNNN/
└── {slug}-YYYYMMDD.md

latest/ には 「いま生きている、アツアツの決定」だけ を置きます。冷めた決定は archive/ に確実によけます。番号は絶対に振り直しません（決定の履歴を追えるようにするためです）。

追加と更新と上書き

ユーザーの依頼を以下の3つに分類します。

• A. 新規追加：新しい ADR を起こす。latest/ の最大番号の次を発番。
• B. 更新（archive送り → 新版を latest に）：意思決定としての変更がある場合。旧版を archive/NNNN/{旧slug}-{YYYYMMDD}.md に退避してから新版を書く。
• C. 上書き（archive送りなし）：typo・てにをは・言い回しの調整など、意思決定としての変更がない修正。Edit で書き換えるだけ。

更新か上書きか

既存 ADR に手を入れる依頼を受けたら、編集を開始する前に必ずユーザーに更新か上書きかを尋ねます。
ここが運用の肝だと感じています。

理由として、意思決定の変更でない修正まで archive 送りにしてしまうと、アーカイブがノイズで溜まるからです。アーカイブは「過去の意思決定」を残す場所で、修正履歴置き場ではありません。
アーカイブにノイズが溜まると、認知負荷が高くなりメンテナンス性も低下します。

ただし、更新か、上書きかはある程度AIに判断してもらいたいので、判断補助テーブルもスキルに入れました。

スキル全文は割愛しますが、ここまでの運用ルールが「腐らせない仕組み」の中核になっています。

4. まとめ — Plan mode の良し悪しではなく、「基準」の話

Plan mode をやめて実際にアプリを作ったことで、基準を作ること と その基準を新鮮に保つこと を意識した運用にすれば、Opus 4.7 の「忠実に実装する強み」を活かせると気がつきました。基準があれば、実装力の高いモデルはそれに沿って走り切ってくれます。基準がなければ、同じ実装力が逆方向に働いてコードベースを発散させます。しかも、決定は放っておくと腐るので、分野をまたいで整合性を保ちながら鮮度を維持する仕組みも要ります。

今回はその手段として grill-me で基準を作り、adr-manager で基準を新鮮に保つ という組み合わせを紹介しました。Plan mode と比較してどちらが優れているかではなく、自分にとって有用性を感じたのがこちらだった、というのが正直なところです。同じように「なんとなく承認してしまう」「コードベースがブレてきた」と感じている方がいたら、選択肢の一つとして試してみてください！

参考リンク

• grill-me スキルの紹介動画
• grill-me SKILL.md (GitHub)