Claude Code に覚えさせた「段取り」は、その後どう育ったか

2026年10月19日 16:17

Claude Code に決めごとを覚えさせるファイルを作ってみたものの、その後どう増やしていけばいいのか分からない。この記事は、そんな人に向けて書きました。

私は Claude Code（Claude のデスクトップアプリの「Code」タブ）を相棒にして、個人で iPhone アプリと Kindle 本を作っています。Kindle 本のほうでは、作業フォルダに「CLAUDE.md」とルールのファイルを置き、出版の段取りを Claude に覚えさせる仕組みを作りました。その作り方は、拙著『Claudeと作る、はじめてのKindle本』の第3章に書いています。

本の最後には、「この仕組みが本当に役に立つかは、まだ分からない」と書きました。この記事はその続きです。同じ考え方をアプリ開発でも使ってみて、ルールがどう育ったか、どこで形を変えたかを書きます。

この記事で分かることは、次の3つです。

ルールを1つのファイルに書きためていたのを、分野ごとのファイルに分けた経緯と、その分け方
失敗をルールに変えるときの書き方（実例つき）
しばらく使ってみての実感

最初は1枚の手順書だった

アプリ開発を始めたのは、2026年9月です。最初の2本を作って公開するまでに、Xcode の設定、App Store への登録、審査、広告の手続きと、つまずくたびに Claude と調べて解決していきました。

そのとき分かったことは、1つの手順書にまとめていました。「アプリを作るときは、この順番で進める」という Markdown のファイルです。新しいアプリを作るたびに Claude がこれを読み、同じ失敗を繰り返さないようにする、という使い方でした。

ところが、アプリを作るたびに書き足していった結果、手順書は約330行になっていました。企画の段取り、Xcode の設定、画像の作り方、広告の手続き、審査への返信の書き方まで、全部が1つのファイルに入っている状態です。

公式の推奨に近い形へ

2026年10月16日に、この手順書を10個のファイルに分けました。

きっかけは、Claude Code の公式ドキュメントに書かれている推奨に近い形にしたかったことです。CLAUDE.md の書き方について、公式ドキュメント（「How Claude remembers your project」 https://code.claude.com/docs/en/memory ）には、たとえば次のようなことが書かれています。

CLAUDE.md は1ファイル200行未満を目安にする。長いと読み込む量が増え、指示が守られにくくなる
関連する指示は見出しと箇条書きでまとめる
大きなプロジェクトでは、話題ごとにファイルを分ける
指示どうしが矛盾していると、Claude がどちらかを勝手に選ぶことがある。定期的に見直す

330行の手順書は、目安の200行をはっきり超えていました。それに、審査の返信の書き方は、アプリを作っている最中には要りません。そこで、いつも全部を読ませるのではなく、必要なときに必要な部分だけを読ませる形に分けました。

分け方：「いつも守るもの」と「その段階で読むもの」

分けるときに決めたのは、ルールを2種類に分けることです。

いつも守るもの（毎回、CLAUDE.md から読み込む）：作業の進め方、プロジェクトの初期設定、画面の作り方、Mac と Xcode の不具合、学び
その段階で読むもの（その段階に入ったときに読む）：画像と音、広告と分析、サーバー、ストアの掲載情報、審査

アプリ1本の作業を「企画・試作」「作り込み」「広告・分析」「公開の準備」「審査」「公開後」の6つの段階に分け、段階ごとに読むファイルを決めました。広告の段階に入ったら広告のファイルを、審査の段階に入ったら審査のファイルを読む、という形です。

CLAUDE.md 自体は、フォルダの構成、ルールのファイルの一覧、新しいルールをどのファイルに書き足すか、を書いた入口になりました。今は81行です。

ちなみに、この分け方は Kindle 出版のフォルダとほぼ同じです。Kindle のほうは、最初からルールを分野ごとのファイルに分けて始めていました。アプリ側の手順書を分けたのも、同じ10月16日です。

失敗がルールになるまで

ルールのファイルは、最初から完璧に書いたわけではありません。ほとんどは、実際に失敗したことから生まれています。ここでは、アプリ開発で実際にあった失敗が、どんなルールになったかを紹介します。

例1：いつのまにか iPad 向けにもなっていた

1本目のアプリを審査に出す直前、App Store Connect（アプリを登録する管理画面）が iPad 用のスクリーンショットを求めてきました。iPhone 専用のつもりだったのに、プロジェクトを作るツールの初期設定で、iPad も対象になっていたのです。設定を直して、ビルドし直すことになりました。

これは「プロジェクトの初期設定」のファイルに、次のようなルールとして残りました。

- ターゲットの設定で iPhone 専用にする。プロジェクト全体の設定だけだと、
  ツールの初期値に負けて iPad も対象になり、iPad のスクショを求められる
  （2026-09-18: 1本目のビルド1で発生）

例2：ストアの言語が「英語」になっていた

別のアプリでは、App Store の言語の欄が「英語」と表示されていました。アプリの中身は日本語なのに、プロジェクトの開発言語が英語のままだったのが原因です。

これも「プロジェクトの初期設定」に、開発言語を日本語にする設定の一覧として足しました。新しいアプリを作るときのひな形にも入れたので、今は最初から日本語になっています。

例3：審査への返信が長すぎて入らなかった

審査の担当者から、決まった形の質問が届いたことがあります。Claude と一緒に英語で返信を書いたところ、約5,000文字になりました。ところが、返信を書き込むメモ欄には4,000文字までしか入りませんでした。

「審査」のファイルには、「メモ欄は4,000文字まで。英文は3,500文字以内に収める」と書きました。少し余裕を持たせた数字にしています。

例4：2つのアプリが同じシミュレーターを取り合った

アプリを2本並行して作っていたとき、確認中に画面が急に白くなったり、アプリが裏に回ったりすることがありました。アプリの不具合だと思って調べていたら、原因は別のところにありました。2本のアプリの作業が、同じシミュレーター（Mac の中で動く iPhone）を取り合っていたのです。

このときは、「プロジェクトの初期設定」に1つの節を足しました。

## シミュレーターはアプリごとに専用にする

なぜ：複数のアプリを並行して作ると、同じシミュレーターを取り合う。
相手がアプリを起動すると、確認中に画面が白くなったりする。
アプリの不具合と見分けがつかず、調査に時間を取られた（2026-10-13）

1. アプリごとに専用のシミュレーターを作るスクリプトを置く
2. ビルド・テスト・起動は、必ず専用のシミュレーターで行う

失敗はまず「学び」のファイルに書く

この4つは、どれもいきなりルールになったわけではありません。

失敗したら、まず「学び（lessons.md）」というファイルに、何が起きて何が分かったかを1行で書きます。たとえば例4は、最初はこう書きました。

- 2026-10-13: 2つのアプリが同じシミュレーターを取り合い、
  アプリの不具合と見分けがつかなかった（→ 専用シミュレーター）

そのあと手順として固まったものを、分野ごとのファイルへ移します。学びのファイルの行には「（→ 移した先）」を残しておくので、あとからたどれます。

学びのファイルの冒頭には、「手順として定着したものは各ルールのファイルに移し、ここには何が起きて何が分かったかを残す」と書いてあります。失敗の記録と、次から守る手順を、別の場所に置いておく形です。

学びのファイルには、失敗だけでなく、うまくいったことや数字（審査にかかった日数など）も書いています。今のところ、アプリ側の学びのファイルには、失敗が10件、うまくいったことが4件あります。

しばらく使ってみて

ルールを書きためるようになってから、ミスが減った気がしています。

数字で比べたわけではないので、「気がする」としか言えません。また、10個のファイルに分けたのはつい最近なので、分けたこと自体の効果はまだ何とも言えません。ただ、上の例のように一度つまずいた所は、ルールと新しいアプリのひな形に入っています。

この形は、新しい分野を始めるときにもそのまま使えます。この note も、同じ形の作業フォルダで書いています。入口の CLAUDE.md、分野ごとのルール、学びのファイル、1記事1フォルダのひな形です。この記事も、公開前に「書かないと決めたこと」が入っていないかを、Claude とスクリプトで確かめてから出しています。

おわりに

まとめると、この1か月半でやったことは次の3つです。

1つの手順書を、いつも守るものとその段階で読むものに分けて、10個のファイルにした
失敗はまず学びのファイルに書き、手順として固まったら分野のファイルへ移す
一度つまずいた所は、新しいアプリのひな形にも入れて、最初から避ける

作業フォルダそのものの作り方は、拙著『Claudeと作る、はじめてのKindle本』の第3章に書きました。CLAUDE.md に何を書くか、ルールのファイルをどう分けるか、決まった手順を名前で呼び出す「スキル」をどう作るか、などです。これから仕組みを作る方は、本のほうから読んでいただくと分かりやすいと思います（Kindle Unlimited でも読めます）。

次の記事では、この形にしてから、アプリ1本を企画して審査に出すまでの流れがどう変わったかを書く予定です。