コードを書けなくてもClaude Codeでアプリを壊さず作り続ける「4つのファイル」の仕組み（プラグイン配布付き）

結論

非エンジニアがClaude Codeでアプリを壊さずに作り続けるのに要るのは、決めたことを会話の外のファイルに書き、Claudeが毎回それに従って動く仕組みだ。Claude Codeは会話が終わると忘れ、人間は確認の手順を忘れるからだ。私はこの仕組みで、コードを書けないまま課金や自動投稿を含むWebアプリを1人で公開・運用している。

使い方は、/add-task で要望を一覧に足し、/dev-loop で1件ずつ作らせ、報告と画面を自分で確かめる往復だ。検証のやり方を表で決めておくと、「自動の確認は全部通ったのに、本番（利用者が使っている公開中のアプリ）では動かない」事故を防ぎやすくなる。4点はキット（プラグイン名は docdd）にまとめ、Claude Codeの「プラグイン」（後から足せる拡張機能）として配布元のGitHubで配っており、コマンド3つで入る（手順は「キットの使い方」）。

この記事の前提

• 対象は、プログラミング経験がない、またはほぼ無い人。ターミナル（文字でパソコンに指示を出す黒い画面。Claude Codeはここで動く）に1行打つことには挑戦してもらう。
• 必要なものはClaude Code（Proなどの有料プラン、または使った分だけ料金がかかるAPI用のConsoleのアカウント）、git、Node.js 18以上（キットが使う無料の道具）。gitとNode.jsが無ければ、導入の途中でClaudeが入れ方を案内する（Windowsは手順0で先にgitを入れておく）。
• キットはWebアプリ向けだが、Unityなどのゲームやスマホのアプリでも、仕様書・作業キュー・検証の表の進め方は使える（Webの画面専用の手順書は「該当なし」で止まる）。
• 本文に出るプロジェクトは、アプリ1つ分のファイル一式を入れたフォルダ。git（ギット）はファイルの変更履歴を残す道具、コミットは「ここまでの作業を1つの記録にする」操作、pushはその記録をGitHubなどネット上の保管場所へ送る操作。どれもClaudeが実行する。テストは、コードが期待どおりに動くかを機械で確かめる小さなプログラムで、全部通ると「緑」、1つでも失敗すると「赤」になる。
• コマンドは、プラグインで入れると /docdd:add-task のように頭にプラグイン名の docdd: が付く。説明では短く /add-task と書き、実際に打つ手順では正確な形で書く。

なぜ「頼み方」ではなく「ファイルに書く」なのか

Claude Codeは会話（セッション）が終わると忘れる。公式ドキュメントにも「各セッションはまっさらな状態から始まる」とある（Memory）。Claudeが自分でメモを残す「自動メモリ」もあるが、何を残すかはClaudeが決めるので、守らせたい決まりは自分で書く。

人間の側にも弱点がある。非エンジニアは「正しい確認手順」を知らないし、知っても忘れる。たとえば、DB（アプリのデータの置き場）の構造を変えたら、利用者が使っている本番のDBにも同じ変更を適用しなければならない。忘れると画面が壊れる。

だから、決めたことはファイルに書いて会話の外に置く。4つのうち約束とスキルはClaude Codeが公式に用意している置き場で、仕様書と作業キューは私が足したものだ。

4つのファイルを1つずつ

キットでは、手順書はプラグインの中に入り、残りの3つは /docdd:init があなたのプロジェクトのフォルダに置く。

1. CLAUDE.md（約束）: 毎回言い直していたことを書く場所

Claudeが会話を始めるたびに必ず読む指示書だ。公式は、Claudeが同じ間違いを2回したら書き足すよう勧めている（Memory）。

キットでは、どのプロジェクトにも共通の約束を、同じく毎回読まれる .claude/rules/docdd-kit.md に分け、CLAUDE.md にはそのプロジェクトのコマンドの表などを置いた。共通の約束の柱は2つある。1つ目は5つの原則で、「このアプリは非エンジニアが1人で運用する」ことをClaudeに伝える。私のプロジェクトで実際に事故を減らしてきた。

1. 黙って壊れない。失敗は必ず記録し、通知や状態確認のコマンドに載せる。「エラーは出ないが何も起きない」が一番怖い。
2. 原因が開発知識なしで辿れる。「ログを読んでください」で終わらせず、画面かコマンド1つで分かる形にする。
3. 手順を人間の記憶に頼らない。忘れると壊れる手順は、1コマンドにまとめるか、忘れたら止まる形にする。
4. 費用が見える。AIや外部サービスの従量課金は、使った額と上限を運営者が把握できるようにする。
5. 判断はまとめて求める。細かい質問を小出しにさせず、「要決定」という欄に整理して出させる。

もう1つの柱は、後で説明する「変更影響 → 必須の検証」の表だ。注意は、書きすぎないこと。公式も「肥大したCLAUDE.mdは、肝心の指示を無視される原因になる」と警告している（Best practices）。消しても困らない行は消す。

2. docs/（仕様書）: 「言った言わない」をなくす

仕様が会話の中にしかないと、次の会話のClaudeはコードから仕様を推測する。推測は少しずつずれ、3週間後には「そんな機能だったっけ？」になる。キットでは仕様書を主に3つに分ける。

決まりは1行、「コードを変えたら、同じ作業の中で仕様書も直す」。これをClaudeに守らせるのが /doc-sync という手順書で、コミットの前に毎回実行させる。仕様書が指すファイルが本当にあるか、更新日が古くないか、埋め忘れの欄が無いかは、同梱の検査スクリプト3本が機械で確かめる。

3. tasks/BACKLOG.md（作業キュー）: 今やることを1か所に

思いついた順にチャットへ投げると、Claudeは目の前の依頼に全力を出し、前回の後始末を忘れる。だから、やることの並びを1本にする。

ふだん使うコマンドは2つだ。思いついたら /add-task ○○したい。Claudeは実装せず、仕様書と照らしてタスクを一覧に足す。作らせるときは /dev-loop。Claudeは、前提の作業や決定が済んだタスクのうち一番上の1件を取り、実装、検証、仕様書の更新、コミットまでを終えて報告する。仕様書にまだ無い機能なら、作る前に仕様の下書きを1回見せて承知を取る。作業中のタスクは常に1件以下、1タスク＝1コミットと決めてある。

BACKLOGにはもう1つ「要決定」という欄がある。料金・外部サービスの契約・利用者に見える文言など、AIが勝手に決めてはいけないことをここに溜めさせ、自分がまとめて決める。

4. スキル（手順書）: 毎回同じ手順をコマンドにする

Claude Codeでは、決まった手順を書いたファイルをスキルと呼ぶ。/名前 と打つと呼び出せ、Claudeが関係のある場面で自分で使うこともある（Skills）。キットの15本のうち、よく使うのは次の5本だ。

このうち /release と /update-kit、それに導入の /docdd:init の3本は、Claudeが自分では使わず、あなたが打ったときだけ動く。

スキルには「やること」だけでなく「やってはいけないこと」も書く。/dev-loop には「テストが通らない状態でコミットしない」、セキュリティ点検の /security-audit には「推測を報告しない」（攻撃の道筋がコード上で本当に通るかを確かめたものだけを報告する）とある。AIは頼まれたことに全力を出すぶん、止まる条件を手順書に埋めておかないと走りすぎる。

一番大事な表「変更影響 → 必須の検証」

キットの約束のもう1つの柱が次の対応表だ（抜粋。キットの表は13行）。左が「Claudeが今回どこを触ったか」、右が「その場合に必ずやる確認」。

表にする理由は、「テストが全部緑なのに、本番では動かない」が実際に起きるからだ。私のプロジェクトでは以前、部品ごとの小さなテスト（単体テスト）1,000件以上とブラウザテストが全部緑だった。それなのに、Web検索付きの文章生成・画像生成・ニュース取得・画像プレビューの4系統が同時に壊れていた。原因は、テストが外部のAIサービスなどを「モック」（本物のふりをする偽物）に置き換えていたこと。本物の側で仕様が変わっても、モックは決まった返事を返し続けるので、テストでは原理的に検出できない。

この失敗から、検証のやり方をその場の判断で選ばず、表で機械的に決めることにした。Claudeは表に照らして「今回はDBを触ったので、テスト用のDBで確かめます」と選ぶ。実物で1周には実費がかかる（私の場合1周約0.3ドル）ので、上限を決めて、超えたら止まって報告させている（キットでは導入のときに金額を聞かれる。空欄のままなら実物1周はせず、しなかったと報告する）。あなたが覚えるのは「表に従わせる」ことだけでいい。

1日の流れ（実例）

私の平日の開発は、だいたいこの往復だ。

あなた:  /docdd:add-task 設定画面のタブが少なくて寂しいので、分けたい
Claude:  （仕様書と照らして、実装はせずに一覧へ）
         T-42として一覧に書き足しました。
あなた:  /docdd:dev-loop
Claude:  （実装 → 表どおりに検証 → /doc-sync → コミット）
         T-42を完了しました。タブを4つに分け、ブラウザでの通し確認・仕様書更新済みです。
あなた:  （画面を見て）/docdd:add-task タブ名は「通知」より「お知らせ」にしたい
Claude:  T-43として一覧に書き足しました。
あなた:  /docdd:dev-loop
Claude:  （直して再検証し、コミット）

コードは読まず、画面と報告を読む。報告には、実行した検証と、できなかった検証とその理由が入るので、不安な点だけ追加で確認を頼めばいい。慣れてきたら /loop /docdd:dev-loop で続けて回し、たまった「要決定」にまとめて答える使い方もできる。/loop はClaude Code本体の機能で、会話を開いている間だけ動く。仕様書にまだ無いタスクや、push・削除などの確認に当たると、そこで止まる。

非エンジニアが実際に踏む落とし穴（と、キットでの対策）

仕組みを入れても、次の3つは起きる。

1. 自分のパソコンでは動くのに、本番で壊れる。本番だけ設定値（接続先など）が違う事故は自分のパソコンでのテストでは防げないので、本番へ出したら本番の画面を開いて確かめたことまで報告させる。
2. ファイルに書いた約束を、Claudeが守らないことがある。公式も、CLAUDE.mdは強制ではないので、必ず止めたい操作はhook（決まった時点で自動で動くプログラム）で止めるよう書いている（Memory）。キットのhookは、別の作業の変更やパスワードなどの秘密が入ったファイルまで記録に入れてしまう git add -A や、ネットに送った記録を上書きする強制pushなど、取り消しにくいgitの操作を実行の直前に止める。v0.4.0からは、秘密鍵や、OpenAI・Stripe（本番用。テスト用のキーは対象外）など決まった形のAPIキー（外部サービスを使うための合言葉）、.env（秘密の値を置くファイル）が入ったコミットも止める。WindowsのPowerShellでも効くように設定してあるが、実機では確かめていない。うっかりを止める柵で、完全な守りではない。
3. 仕様の判断を、AIに任せてしまう。AIは「もっともらしい仕様」を作るのが得意で、それが一番怖い。線引きは「利用者に見えるか」で、見えるものは自分が決め、名前の付け方のような見えない細部は任せてよい。フレームワークやDBのような技術の選定は、キットではClaudeが案を書き、あなたの承知を待つ。

キットの使い方（最初の1件まで）

細部と、英語で出る確認への答え方は配布元のREADMEにある。Claude Codeを初めて起動したフォルダでは、英語で「このフォルダを信頼するか」と聞かれるのでYesを選ぶ（これで後で置く許可設定が効く）。

手順0（まだプロジェクトが無い人だけ）

1. ターミナルを開く（Macは画面右上の虫めがねで「ターミナル」を検索、Windowsはスタートメニューで「PowerShell」）。Windowsは、公式が勧めるGit for Windowsも先に入れておく。
2. Claude Codeが未インストールなら、公式のクイックスタートを済ませる。ターミナルで claude と打てば起動する状態になればよい。
3. 好きな場所に、アプリ一式を置く空のフォルダを作る。名前は半角英数で、空白を入れない（例: myapp）。
4. ターミナルに半角で cd （cdの後に空白1つ）と打ち、そのフォルダを窓へドラッグ＆ドロップしてEnter。ここが「今いる場所」になる。
5. claude と打って起動し、日本語で「○○のWebアプリを作りたい。土台を作って、画面が動くところまでお願いします」と頼む。

すでに自分のプロジェクトがある人は、そのフォルダで claude を起動して手順1から。gitで管理していなければ、手順3で管理を始めてよいか聞かれるので許可する。

手順1〜5（全員）

Claude Codeの中で、次のコマンドを順に打つ。手順1・2はどのフォルダで起動していてもよい。

1. /plugin marketplace add no1013kota/claude-docdd-dev-kit と打つ。配布元を登録する（取得のエラーが出たら /plugin marketplace add https://github.com/no1013kota/claude-docdd-dev-kit と打ち直す）。
2. /plugin install docdd@claude-docdd-dev-kit と打つ。入れる範囲を英語で聞かれたら、User（自分の全プロジェクトで使う）を選ぶ。これで使える状態になる（会話を読み直す旨の警告が出たときだけ /reload-plugins --force と打つ）。
3. 自分のプロジェクトのフォルダ（一番上の階層）でClaude Codeを起動し、/docdd:init と打つ（何も付かない /init は本体の別のコマンド）。別の場所で起動していたら、/exit で終了し、そのフォルダで claude を起動し直す。Claudeは次の順に進める。
   • 作りたいアプリの「やること」「やらないこと」など、分からないことだけを、選択の画面と番号付きのメッセージでまとめて聞いてくる（空欄でもよい。テストなどのコマンドはファイルから推定して書く）。
   • 約束・docs/・tasks/・検査スクリプトなどを置く。既にあるファイルは上書きせず、既存のCLAUDE.mdは「表だけ末尾に足す（おすすめ）／置き換える／そのまま」から選ぶ。
   • 許可設定（.claude/settings.json）を置くと、コミットと検査は確認なしで進み、まとめて消す削除・push・外部のプログラム（ライブラリ。ほかの人が作ったプログラム）の追加は必ず確認が出る。ただし、WindowsでClaudeがPowerShellでコマンドを動かすときは、この許可設定は効かず、柵は前の節のhookだけになる（pushや外部のプログラムの追加でも確認が出ないことがある）。ファイルの編集のたびに確認が出るかは、起動したときのClaude Codeの「モード」（確認の出し方）で決まる。キットが置く許可設定には、モードの指定は入っていない（v0.4.0より前に入れた人は、下の注意点の3つ目）。Pro・Max・Teamのプランでターミナルから起動すると、最近の版では「autoモード」（別のAIが安全を確かめて自動で許可する）で始まり、編集の確認はほぼ出ない（Claude Codeを入れた・更新した直後の最初の起動は、Manualで始まることがある）。EnterpriseのプランやConsoleのアカウント（APIキー）では、毎回確認する「Manual」で始まる。編集のたびに確認してほしければ、Claudeに「.claude/settings.json の permissions に "defaultMode": "default" を足して」と頼む。コミットの前にも確認してほしければ「allow の Bash(git commit:*) を ask へ移して」と頼む。逆に、Manualで始まる人が確認を減らしたければ、"default" の代わりに "acceptEdits" を足すよう頼む。ファイルの編集と、フォルダの作成・移動・1つずつのファイルの削除のような簡単なファイル操作が確認なしになる。
   • コミットしてよいと答えていれば、検査を通してコミットする。埋まらなかった欄は {{…}} のまま残り、もう一度 /docdd:init と打つと聞き直す。
4. 手順3で答えた「やること」「やらないこと」が docs/PRD.md に入っている。Claudeに「docs/PRD.md のやることとやらないことを見せて」と頼んで読み返し、足りなければ「PRDのやることに○○を足して」と頼む（中身を決めるのは人間の仕事。記入例）。
5. initの報告の最後に出る「次の一手」を打つ。既にコードがあるなら、まず /docdd:doc-sync --full（今のコードから仕様書を起こす）。次に、PRDに機能を複数書いたなら /docdd:tasks-from-prd、1件だけなら /docdd:add-task メールアドレスで登録できるようにしたい でタスクを作る。タスクができたら /docdd:dev-loop。initが「テスト基盤の導入」などの準備のタスクを入れていれば、それが先に進む。

注意点は3つ。

• 作業中は、英語で「このコマンドを実行してよいか」と聞かれることがある。画面の下のほうに「manual mode on」か「accept edits on」と出ている人には、許可設定で認めたコミットや検査などを除く、多くのコマンドで出る。「auto mode on」と出ている人には、主にまとめて消す削除・push・外部のプログラムの追加で出る（WindowsのPowerShellでは、この出方にならないことがある）。内容を見てEnterで許可し、迷ったらEscで止めて「これは何をするの？」と聞く。外部のプログラムを入れる確認に出る「don't ask again」（次から聞かない）は選ばない。
• 手順書とキット共通の約束はキットが管理するので、直接は直さない。自分のプロジェクトだけ手順を変えたいときは、CLAUDE.md の「スキルへの追加指示」表に1行足す（例: /docdd:dev-loop に「コミットの前に、変えた箇所を見せて承認を得る」）。その行が、手順書に書かれた内容より優先される。
• キットの新しい版は、既定では自動で届かない（/plugin の Marketplaces で claude-docdd-dev-kit を選び、Enable auto-update にすると自動になる）。手で受け取るときは、/plugin marketplace update claude-docdd-dev-kit のあと /plugin の画面で docdd を更新する。どちらでも、プロジェクトのフォルダで /docdd:update-kit は自分で打つ（プラグインの更新だけでは、置いた雛形は古いまま）。以前の版（v0.1系）からの移行もこれで行う。v0.4.0より前に入れたプロジェクトの .claude/settings.json には、編集を確認なしにする "defaultMode": "acceptEdits" の行が残り、/docdd:update-kit では消えない。手順3に書いた始まり方にしたければ、Claudeに「.claude/settings.json の permissions から defaultMode を消して」と頼む。

まとめ

AIとの開発で信じていいのは、記憶ではなくファイルだ。毎回読まれる約束、いちばん正しい版としての仕様書、1本の作業キュー、止まる条件まで書いた手順書の4点で、Claude Codeは「忘れない同僚」になる。

まず、キットを入れて /docdd:init を打ち、最初の1件を /docdd:dev-loop で作らせてみてほしい。

公式ドキュメント: Claude Code — Memory・Skills・Discover plugins・Permission modes・Hooks・Best practices。