AIと1ヶ月、企画からリリースまでClaudeで個人開発した全記録
はじめに
先日、連続ドラマをクール単位で管理・記録・番付する「ドラマのじかん」というアプリをリリースしました。
思い付いたのが2026年6月11日で、リリースしたのが2026年7月17日です。週末 + 平日夜で約1ヶ月、131コミットでした。企画・キービジュアル決め・UIデザイン・アーキテクチャ設計・実装・ストア素材作成・LP制作まで、ほぼすべてを Claude と一緒に進めました。
難しいことや目新しいことは何も行っていませんが、どのように開発を進めていったのかを残しておこうと思い、この記事を書くことにしました。
なぜ作ったか
昔から日本のドラマが好きで1クールに5本前後、連続ドラマを並行して観ています。この本数になると何曜日の何時に何をやっているか覚えられず、リアルタイムで観るつもりが放送時間を過ぎていた、ということが何度かありました。
軽く探した限りではドラマに特化したアプリが見つからず、自分に合うものがなかったので作ることにしました。自分が毎日使うものであり、仕様に迷ったときに「自分ならどちらが嬉しいか」で決められるので、個人開発の題材としても適していると思いました。
ただ、ドラマのリマインダだけだと淡白なアプリになってしまいそうだったので、企画から Claude に相談してみることにしました。
企画はスマホのチャットで終わった
最初に相談したのは2026年6月11日で、Claudeアプリでのチャット上でのやり取りでした。エディタどころかPCも開いていません。スマホで送ったのは次の3文でした。
自分が見ているテレビドラマが何曜日の何時なのかがよくわからなくなるので、それを管理するスマホアプリを作りたいと考えています。
ただ、普通に作るだけでは面白味のない地味なアプリになってしまいそうなので、元の要件をベースにして使いたくなるようなアプリを提案してください。
個人の趣味の開発の範疇なので、高額なAPIやサーバー費用はかけたくないです。
「やりたいこと」「悩み」「制約」を元に相談しました。個人開発でお金をかけたくなかったので、特に制約は最初に定義しておいてよかったかなと。
そして、返ってきたのは下記の3案。
- 「今夜のドラマ」通知特化型 — 放送30分前のローカル通知とホーム画面ウィジェットを主役にする
- コレクション型 — 1話見るたびに記録し、本棚やカレンダーが埋まっていく。完走率や「積みドラマ」の可視化
- クール終わりの「番付」生成 — 今期観たドラマをランク付けして画像1枚にまとめ、SNSで共有する
この時点で、私が最初に考えていた「放送時間を管理するアプリ」からは少し飛躍していました。特に2と3は自分の発想にはありませんでした。企画から相談して正解でした。
AIの推奨案には従わなかった
3つの案を出したあと、Claude はこう続けていました。
個人的には「1の通知・ウィジェットを土台に、2の記録要素を少し乗せる」のが開発量と満足度のバランスが良いと思います。
つまり3の番付は落とす提案です。開発量を考えれば妥当な判断だと思います。
ただ、ここは従わず3つとも入れることにしました。「番付」という言葉の独自性が強く、アプリの個性やシェアにつなげられると考えたからです。地味なアプリにしたくない、という懸念への解決策にもつながると思いました。
結果として、番付はこのアプリの特徴にもなっているのかなと思います。シェア画像もそれなりに作り込みました。
AIは妥当な案を出しますが、判断材料は持っていないので人間が決める部分だと思います。特に個人開発では自分の作りたいものを作ることが何より大事！
デザイン、UIの方向性決め
企画書の作成後、同じチャットでワイヤーフレーム、配色、キービジュアルを決めていきました。
まず全7画面のワイヤーフレームを作成し、次にメイン画面の配色案を3方向で出してもらいました。
A. プライムタイム — 夜9時の消灯した部屋。深い藍に、今夜の時刻だけがランプ色に灯る
B. ラテ欄 — 新聞のテレビ欄を赤ペンで囲む原体験。新聞紙色 + 明朝体 + 手描き風の赤丸
C. クール衣替え — 差し色がクールごとに季節色へ切り替わる、明るい丸ゴシック
ビジュアル化されると一気にテンション上がりますね…！
Bは世界観としては一番強く、番付という紙文化との相性も良い案でしたが、新聞のテレビ欄はさすがに最近だと馴染みがなさすぎると判断して外しています。
A案を選び、そのままキービジュアルまで作りました。「夜の街にぽつぽつ灯る窓 = みんながドラマを待っている時間」というモチーフで、窓と同じランプ色で「21:00」が光る構図です。
このキービジュアルは、アプリのベースとなっています。アプリのUI、アイコン、ストアキャプチャ、LP、OGP画像。すべてこの「夜に灯る明かり」から派生しています。早い段階でトーンが1枚の絵で固定されていたので、以降のフェーズでのデザインを決める良い助けとなっていました。
競合調査
続けてチャット上で競合調査も行いました。
まとめると、競合は「記録・レビュー型」「エピソードトラッカー型」「番組表・配信型」の3タイプに分かれていて、放送時間の管理と視聴の記録を1つのアプリで扱っているものがないという整理でした。この内容は事前に自分で軽く調べた結果ともあっていました。
弱点も同時に判明しました。コストを掛けないやり方だとデータソースが乏しく、公式番組データによる放送時間変更への自動追従は再現できない、という点でした。最終的にはこの弱点への回答として、休止日を自身で登録できたり、あとからサーバー上のデータを更新できる機能を実装しています。
Claude Code への引き継ぎ
最後に、ここまでの資料を Claude Code に渡すためのプロンプトを作ってもらいました。要件定義 → 技術設計 → 画面仕様 → API定義 → テスト計画 → リリース計画 → CLAUDE.md を順に作らせる、という7ステップの長文プロンプトが出てきました。
ただし、API定義とテスト計画は趣味レベルの個人開発でAPI定義書やテスト仕様書まで厳密に用意する必要はないと感じたので（そもそもこのレベルの開発でAPI定義が必要なのかもよくわからない）、途中で落としています。最終的に残っているのは、企画書・競合調査・アーキテクチャ・開発計画の4つです。
ここまでが 6/11 から 6/13 の3日間で、まだコードは1行も書いていません。
Pencil で全画面をデザインする
企画が固まった次にやったのは、実装ではなくUIデザインです。チャットで作ったモックだけで実装に入ると、実装後のデザイン調整で手戻りが出ると考え、先に全画面を作ることにしました。
最初は Figma を検討していましたが、少し前に知り合いが話していた Pencil を思い出して調べ、こちらにしました。下記の3点が良さそうに感じました。
- 2026年6月時点で無料で使えたこと
- MCP経由でClaude Codeから操作しやすそうであること
- デザインファイルをリポジトリに置いてGitで管理できること
無料かつ Claude Code から直接デザインを読み書きできるという点が決め手でした。
Git管理については、.pen の中身がJSONなので git diff がそのまま読めます。デザインを変更したコミットで、どのノードのどの値が変わったのかが差分として出てきます（コンフリクト解消とかはさすがに厳しそうですが、差分を確認できるのはある程度安心材料）。
- "fontSize": 12,
+ "fontSize": 14,
デザインファイルも用途により分割
designs/ というディレクトリを作り、 .pen ファイルを用途ごとに複数作りました。
designs/
├── dorama_wireframe.pen # 低忠実度(画面要素の洗い出し)
├── dorama_app.pen # 高忠実度(本番のUI)
└── dorama_material.pen # ストア素材・OGPなど
最初に作ったのは dorama_wireframe.pen です。本格的にアプリの画面を作っていく前にどんな画面があるのかをざっくり決めたかったので、まずワイヤーフレームレベルのデザインを作りました。
そのあと、事前に決めていたキービジュアルに沿って dorama_app.pen でアプリのUIを決めていきます。
操作はすべて Claude Code 上のチャットです。MCP経由で Pencil を操作させ、企画書やワイヤーフレームを参照させながら「この画面を作って」と指示していく形でした。デザインツールは自分ではほとんど触っていません。
ハマりどころはあったが、Claude 自身で解決
順調に進んだわけではなく、MCP経由の操作でトラブルもありました。代表的なのは、作ったはずのデザインがデータ上は存在するのに描画されない現象と、画像書き出しが特定条件で失敗する現象です。このあたりの詳細と回避策は、ツール固有の話なので別記事にまとめます。
Pencil MCP でハマった話 — ファイルは一つにまとめよ
これらの問題、および回避策については実際のところ私はほぼ把握していなかったりもします。Claude Code が詰まりながら自力で解決しその結果をメモリに書き残していたので、同じ症状が再発したときには、メモリを参照して回避策を実行していました。今回この記事を書くにあたってClaudeに聞いてみて、ようやくそういうことだったのかと理解したくらいです。
（デザイン作ってるときに、「なんかClaude苦戦してるなー」くらいには思っていました）
実装前に一旦デザイン完了
全画面のデザインを終わったら、実装です。手戻りが嫌だったので、基本的にデザインを先に固めておきました。
とはいえ、実装中にデザインを一切触らなかったわけでもなく、実際に動かしてみて調整した箇所はあります。それでも、画面の構成そのものを実装後に作り直すことはなかったので、手戻りを減らしたいという最初の狙いは達成できたんじゃないかと思っています。
開発前の環境づくり
実装に入る前の最後の準備が、Claude Code の作業環境づくりです。CLAUDE.md と エージェントスキル の2つを用意しました。
CLAUDE.md は少なめ
このプロジェクトの CLAUDE.md は空行含めて27行で、構成は下記のようにしています。
# ドラマのじかん
## アプリ概要 … 何のアプリか、ローカル完結・サーバー費ゼロの方針
## アーキテクチャ … docs/アーキテクチャ.md への参照
## デザイン資料 … .pen ファイルの場所と扱い方
## 開発メモ … コード生成・検証コマンド、関連ドキュメントへのパス
## コード修正後のレビュー方針 … 後述
よく言われているベストプラクティスに沿って、CLAUDE.md はどんな作業でも必ず必要になる情報だけを入れました。
たとえばアーキテクチャの詳細は、実装のタイミングでしか使わないので本体には「詳細は docs/アーキテクチャ.md」と参照だけ書き、中身は別ファイルにしています。デザインなども同じ扱いです。必要なときに Claude が自分で読みに行ってくれるはずです。
（今思うと、コード修正後のレビュー方針についても実装時の参照するファイルとして別でも良かったかもしれません。）
エージェントスキルは公式のものから Claude に選ばせた
Flutter/Dart には公式のエージェントスキル集がありますが、全部入れる必要はないので、公式のエージェントスキル一覧を Claude に提示して、このプロジェクトに合うものを選ばせました。
結果的に下記の7つが Claude によって選ばれました。
- flutter-apply-architecture-best-practices
- flutter-add-widget-test
- flutter-add-widget-preview
- flutter-fix-layout-issues
- flutter-implement-json-serialization
- flutter-setup-declarative-routing
- flutter-use-http-package
正直ここについてはどれほど効果があったかよくわかっていませんが、なんとなく安心感はありました。
コードレビューはAIにやらせる、をルールにする
普段仕事でもコードを見ているので、趣味の個人開発では極力コードを見たくありませんでした。
なので、基本的にAIエージェントが書いたコードは別のエージェントにレビューさせる運用をとっていたのですが、毎回同じ指示をしていることに気づいたので、CLAUDE.md にルールとして追記しました。
コード修正を行った際、フラグ切り替えや軽微な文言修正など明らかに影響範囲の小さい変更を除き、コミット前に code-review skill（別エージェントによるレビュー）を実行すること。
大きめの機能実装の際は割と指摘が入っていたように思えます。
ルールにしても、たまに守られない
ただ、CLAUDE.md に書いたにもかかわらず、レビューが実行されないこともたまにありました。
今回はそこまでやっていませんが、確実に強制したいなら hooks を使うなどしたほうが良さそうです。
アーキテクチャと開発計画をファイルに残す
コードを書き始める前に、docs/アーキテクチャ.md と docs/開発計画.md の2つを作りました。
アーキテクチャ
構成はクリーンアーキテクチャ + Riverpod です。ここは Claude に選ばせず、自分で指定しました。Flutter は仕事で使っていたので、慣れた構成をそのまま採っています。とはいえ Flutter の公式ドキュメントがレイヤー分離を推奨しているので、指示しなくても同様の提案が返ってきたような気はしています。
書いた アーキテクチャ.md には、レイヤと依存方向、ディレクトリ構成、Riverpod での DI、ユースケースの運用ルール、テスト方針までが入っており、AIエージェントが安定してコードを書ける基盤になっていたと思います。95ファイルまで増えた今も、レイヤ構成は崩れていないはず…！（多分）
開発計画はフェーズ分けで
開発計画.md はフェーズ0〜4の構成です。
- フェーズ0 — 基盤（プロジェクト設定、DB、テーマ）
- フェーズ1 — 管理（リアタイ視聴中心のMVP）
- フェーズ2 — 記録・消化
- フェーズ3 — 番付・振り返り
- フェーズ4 — 仕上げ・リリース準備
企画の3案（通知・記録・番付）がそのままフェーズ1〜3に対応しています。ファーストリリースで全部やらなくても成立するように、という企画時の整理が計画にそのまま引き継がれた形です。
コードのレイヤー単位ではなく、機能単位で進めるようにしたことによって、少しづつアプリで触れる機能が増えて楽しかったです。
実装は計画ファイルの更新といっしょに
開発計画.md の git 履歴を見ると、ほぼすべての機能コミットと一緒に計画のファイルも更新され続けていました。Claude が律儀に「機能を1つ実装したら計画の該当項目にチェックを付けて同じコミットに含める」という運用を続けていました。偉い！
セッションをまたいでも「どこまで終わっていて、次に何をやるか」が常にファイルに残っているので、新しいセッションを開いて「開発計画の続きから」と言うだけで再開できます。平日の夜とかの頭を使いたくないときでも機械的に指示を出せて楽でした。
決めないことも書いておく
とはいえ、開発計画には「未決事項（着手時に判断）」という部分もありました。たとえば通知とウィジェットの実装範囲は、OS別の対応コストが読めなかったので「フェーズ2で要否判断」とだけ書いて先へ進んでいます。
作って触ってから決めたものもあります。分かりやすいのが番付で、最初は1位から順に並べる線形の順位で実装しましたが、実際に触ってみるとしっくり来ず、途中で S/A/B のティア型に作り直しました。
feat: 番付を線形順位からティア(S/A/B)型に作り直し
計画段階で無理に決めず、動くものを触ってから決める。今回はこれで結果的にうまく回りました。
実装フェーズでは判断を行う毎日
実装直前の壁
実装に入る直前、企画時に決めていた方針が覆りました。作品データの取得元です。
企画時は「TMDB API が無料で使える」という前提でしたが、本格着手の前に実際に TMDB を調べたところ、欲しい日本の連続ドラマのデータがほとんどありませんでした。海外ドラマは充実しているのですが、日本のクールドラマとなると全然無かったです。
そこで再度 Claude に相談したところ、Wikipedia を参照するという提案が返ってきました。おそらく自分では思いつかなかった案です。でも確かにと思い試作のデータ取得スクリプトを作り走らせてみると、思った以上の精度で取れたので、そのまま採用しました。
最終的な構成は下記となりました。
- GitHub 上でスクリプトを定期実行し Wikipedia からクールごとの作品情報を取得して JSON に整形
- その JSON をリポジトリに置き、GitHub Pages で配信
- アプリは作品追加のときだけその JSON を参照する
データが取れずお蔵入りアプリになるところでしたが、なんとかなりました。
コードは書かない、読まない
最近では珍しくないですが、このプロジェクトで私はコードをほぼ書いていませんし、読んでもいません。開発計画に沿って「次の項目を進めて」と指示し、実装が終わるのを待ち、動いたものを触って確認するということを続けていました。もともとコードを書くこと自体より考えて作ることが好きなので、良い時代になったなんて思ったり。
判断はまだまだ人間がやるべきこと
実際に悩んだのは下記とかです。
- 登録後のドラマデータは元データの更新に追従するべきか
- 番組表の見せ方
- 番付のデザイン
どれも正解がコードの中にない問題で、どんな仕様が良いかはAIには決められません。何より自分のためのアプリなので、自分が嬉しい仕様にしました。
実機で使って見つかる問題
実際に自分で使い始めると、バグがちらほらと…。
- 放送時刻が過ぎたドラマが、ホーム画面ウィジェットに残り続ける
- 選択したクール以外のドラマまで表示される
どちらも「時間の経過」や「クールをまたぐデータ」が絡む問題で、短時間の動作確認では再現しにくいものです。このあたりは事前に厳密に定義しておくのは難しいので、実際に使ってみたうえで人間の違和感センサーに頼るところなのかもしれません。
ストア素材も Pencil で作る
実装が落ち着いたら、ストア申請に必要な素材づくりです。アプリアイコン、ストアキャプチャ、Google Play 用のフィーチャーグラフィック、すべて Pencil で作りました。
アプリアイコンは50案以上作った
一番悩んだのがアプリアイコンで、細かい違いを含めると50案以上作りました。正直今のアイコンも完全にしっくりは来ておらず、他のグラフィカルの出力が得意なAIモデルのほうが良いのかもしれません。
とはいえ、デザインセンスの無いエンジニアの私がこれだけの案考えるのは到底無理なので、助かった点でもあります。
ストアキャプチャ
ストアキャプチャは実機のスクショではなく Pencil 上で実装を忠実に再現して作る方法をとりました。画面内のドラマを架空の作品にしたく、デザインツールで組む方が調整しやすいからです。
そしてAIが出してきたものに対して追加指示を行い、多少個性を出すようにしてみました。
プライバシーポリシーとサポートページ
ストア申請に必要なプライバシーポリシーとサポートページは、Claude で作成されたものを、別途事実かどうかだけ精査しました。正直プライバシーポリシーとか何書いていいかよくわからないですし。
ストア申請
タイムラインは下記です。
| 日付 | 出来事 |
|---|---|
| 7/9 | iOS・Android 同日に審査提出 |
| 7/10 | iOS リジェクト(Guideline 2.1)→ 当日中に返信 |
| 7/11 | iOS 審査通過 |
| 7/16 | Android 審査通過 |
| 7/17 | 両OS同時リリース |
iOS 版がリジェクトされる
iOS で一度リジェクトされ、内容は Guideline 2.1「Information Needed」でした。バグや規約違反ではなく、審査を進めるための追加情報の要求です。実機での画面録画、テスト済みデバイスの一覧、アプリの目的、外部サービスの一覧など7項目を求められました。
この対応も Claude に相談しながら行ったので楽でした。昔は中身を翻訳して理解して対策を考えて…とかだったので。
ただ、内容的には「よくわからんからアプリの操作動画送って」のようなものだった気がするので、「自分で操作すればいいのでは」と思ったりもしました。AIの影響でストア申請が増え審査が大変になって簡略化したいんですかね…？
Android 版は審査が長い
Androidの審査が通るまで1週間…。
リリースは両OSで揃えたかったのでAndroidの審査を待ち、最終的に7/17に両OS同時に公開しました。
LPを作る
最後にアプリのLPを作りました（実際は開発の空き時間とかに少しずつ進めていましたが）。
個人開発でLPを作る人は多数派ではない気もしますが、私の場合は個人の成果物をひとつの場所にまとめておきたい気持ちがあるので毎回作ることにしています。1年前に作った別アプリ(しょくめも)でもLPを作っていました。
Claude 用のプロンプトを Claude に書かせる
単に使ってみたいという単純な動機で、LPは Claude Design で作ってみることにしました。
まず Claude Design 用のプロンプトを Claude Code で作りました。アプリのリポジトリには企画書もキービジュアルの定義も揃っているので、「それらを踏まえたLP生成用プロンプトを作って」的な指示でそれっぽいアウトプットになりそうなプロンプトが出てきました。
ただ、Claude Design に慣れていないこともあり、最終的な調整は Claude Code 側で行いました。
ちなみにAIが作ったことが丸わかりのデザインにはしたくなかったのですが、LPに時間をかけすぎるのは違うので妥協しました。
まとめ
かかった費用
この開発のために新たに払った費用は 0円 です。すべて既存のコストの範囲に収まっています。
- Claude Pro プラン: 月 $22（契約済）
- Apple Developer Program: 年 $99（契約済）
- Google Play 開発者登録: 払い切りであり、過去に登録済
- ドメイン: 年 ¥2,000 ほど（取得済）
- サーバー費 (GitHub Pages): 0円
- LP (Firebase hosting): 無料利用の範囲
次も続けたいこと
企画からAIと壁打ち
やりたいこと・悩み・制約の3つを伝えたおかげで、よりブラッシュアップした企画が現実的な方法でまとまりました。
キービジュアルを早い段階で作成
最初に雑に依頼して作ったビジュアルが、最後までデザインの軸になっていました。
進捗と決定をファイルに残す
特に開発計画をファイルにして実装のたびに更新していたので、1ヶ月ずっと同じ流れで開発を続けられました。
次は改善したいこと
（Pencil を使うのであれば）penファイルは一つに
Pencil はMCP経由でアクティブなタブしか読めずファイルの切り替えが毎回手間になるため、一つのファイルにまとめたほうが良さそうです。
さいごに
振り返ってみると、やっていたのは「ドキュメントを整える」「規約を明文化する」「決定と進捗を残す」という、チーム開発で昔から言われてきたことでした。相手が人間からAIに変わっても、うまく協働するためのやり方は変わらないものですね。
そうして作った「ドラマのじかん」は、今自分のスマホで毎日動いています。ドラマ好きの方はぜひ使ってみてください！
あとがき
この記事自体ももちろん Claude と一緒に書いています。
「こんな記事を書きたい」と伝えた上で、必要な情報を適宜確認してもらうようにしました。「ドラマのじかん」自体のリポジトリで立ち上げたセッションのため情報も揃っており、インタビュー形式で質問に答えていくだけでこの長文の記事ができました。
さすがにそのままだとAIっぽさが出まくっていたので、だいぶ文体は調整しましたが執筆コストもハードルもだいぶ下がった気がしています。
Discussion