アプリの個人開発、公開、運用してみて思う今後のアプリ開発の個人的見解
1. 作ったもの
「irotsuna（いろつな）」というiOSアプリを、企画からApp Store公開、その後の運用まで1人でやっています。
テキストで説明したり、写真を撮ったりすると、生成AIがぬりえ用の線画を作ってくれるアプリです。「うちの犬」「好きな景色」のような自由なお題でも、線画に変換できます。
できた線画は、印刷して紙で塗ることも、アプリの中でそのまま塗ることもできます。アプリ内で塗る機能は無料です。塗った作品はアプリ内に投稿できて、いいねやコメント、フォローで交流もできます。対応言語は日本語と英語の2つです。
ブランドスローガンは「ぬりえで、誰かとつながろう。」です。
「AIが線画を作る → 紙でもアプリでも塗れる → SNSに投稿してつながる」という一連の流れを、最初から最後まで持っているアプリは、調べた範囲では他に見つかりませんでした。 既存の塗り絵アプリは、画面の中だけで完結するものが多いです。「印刷して手で塗る」というアナログな工程を、AIとSNSに橋渡しした点が、自分の中では一番こだわった部分です。
App Store：https://apps.apple.com/app/id6782540224
公式サイト：https://irotsuna.com
2. 作ったきっかけ
きっかけは祖母でした。祖母はいつも、自分で塗ったぬりえを楽しそうに見せてくれます。その様子を見て、ぬりえほど老若男女が手軽に楽しめるものはないんじゃないかと思いました。言葉を超えた、いい交流にもなりそうだなと。
祖母のぬりえを、もっと多くの人に見てもらいたい。閉じられた環境から解放されて、同じようにぬりえをする人たちとつながってほしい。そう感じたのが、作ろうと決めた一番の理由です。
ちょうど生成AIが線画やイラストを作れるようになってきたタイミングでもありました。このAIをアプリに組み込めば、祖母だけでなく誰かの「作ってみたい」「塗ってみたい」を手伝えるかもしれない。そう思って、具体的に動き始めました。
システム開発の仕事は5年やってきましたが、ほとんどは受託や自社サービスの一部分を担当する形でした。「企画から公開、運用まで全部自分でやる」経験はなかったです。Claude Codeを使えば1人でもどこまで進められるのか、自分で試しておきたい気持ちもありました。
3. 市場調査とターゲット、設計までの進め方
思いつきだけで進めず、まずは市場調査から始めました。このあたりはGeminiと一緒に進めています。国内外のiPad市場の相場、デジタルと紙のぬりえの割合、各国でのプリンターの普及率などを調べました。AIぬりえの市場も近年増えていて、全体の市場も今後伸びる見込みだとわかりました。
次にターゲットです。祖母がきっかけだったこともあり、最初は高齢の方を中心に考えていました。ただ、AIやデジタル塗り絵は、その年代だけに絞ると相性があまり良くないとわかりました。そこで年齢層を広げて、ターゲットを決め直しています。外に出す文章では「シニア向け」「高齢者向け」のような年齢のラベルは使わず、「大人のための」「自分時間に」と言い換えるルールも、この時に決めました。
そのあとはClaude Codeで要件定義から進めています。開発手法は、AIでPDCAを高速に回しながら作りたかったので、アジャイルにしました。まず土台になるMVP（最小限の機能を持った最初の版）を作るために、基本設計と詳細設計をしています。画面設計などUI部分はFigmaで自分で作りました。
CLAUDE.md（Claude Codeに読ませるプロジェクトのルールを書くファイル）を整えたのも、この設計のタイミングです。ドキュメントの概要と進捗を正しく管理させる、というところから書き始めました。詳しくは5章に書きます。
手元に残っている資料の日付で追うと、こんな流れでした。
時期やったこと2026年1月末要件定義スライドの初版2月簡易ワイヤーフレーム3月上旬〜中旬画面一覧、ロゴ、UIの修正版、仕様書（v6まで改訂）、データ構造図、アーキテクチャ図3月18日コードを書き始める
4. 使った技術
必要な機能を一通り揃えるため、技術はこのように選びました。
分類技術アプリFlutter／Dart、Riverpod（状態管理）、Freezed（データモデル生成）、go_router（画面遷移）バックエンドFirebase Functions v2（26本）、Cloud Firestore、Firebase Auth（Apple ID／Google認証）、Cloud Storage、Firebase Cloud Messaging（プッシュ通知）、Secret Manager（APIキーの管理）生成AIBFL FLUX（flux-2-pro：テキストから線画、flux-kontext-pro：写真から線画）課金RevenueCat、App Storeのアプリ内課金（月額サブスク＋都度課金）公式サイトWordPress（Xserver）、自作テーマ、GitHub Actions＋rsyncによる自動デプロイSNS自動投稿X API v2、Pinterest API v5品質管理GitHub Actionsでのテスト自動実行（整形チェック・静的解析・テスト）
Firebase Functionsが26本というのは、処理を1つずつ小さく分けて作った結果です。「線画を作る」「投稿する」「サブスクの状態を確認する」「通知を送る」「SNSに投稿する」といった単位です。最初から大きく作らず、必要になったら1本追加する、という進め方をしました。
生成AIは、最初からFLUXだったわけではありません。はじめはOpenAIの画像生成（DALL-E 3→gpt-image-1）で作っていました。ここでつまずいたのが、「写真を送って線画に変換する」機能です。人物や犬の写真を送ると、元の構図や被写体の形（顔の向き、ポーズ）が崩れて、まったく別物の線画になってしまうことが何度も起きました。プロンプトを工夫しても改善しきれず、ここで1週間ほど足踏みしました。
試しにBFL社のFLUX（写真の構図を保ったまま描き直すモデル）に切り替えたところ、元の構図のまま線画化できるようになりました。1枚あたりの原価は約6円です。その後、テキストからの生成もFLUXに揃えています。とりあえず動くAIで作って、精度で困ったら別のAIに乗り換える。この身軽さは、1人開発だからこそでした。
5. Claude Codeで個人開発を進めるために整えたこと
Claude Codeには、コードを書くこと以外にもかなり任せました。ただ丸投げにはせず、プロジェクトのルール（CLAUDE.md）を最初に決めて、そのルールの中で動いてもらう形にしています。
任せたのは、こういう作業です。
Flutter・Firebaseのコードを書く（画面、API連携、データモデルなど）
エラーが出たときの原因調査と修正
テストコードの作成
GitHub Actionsのデプロイ設定
公式サイト（WordPressテーマ）の実装とSEO設定
ブログ記事の執筆と画像生成、投稿
SNS自動投稿の仕組みづくり
逆に、自分で決めたのはこのあたりです。
どんな機能をどの順番で作るか
AIの線画がどう見えるべきか（UI・UXの最終判断）
課金プランの価格と内容
個人情報・画像データの扱い方（どこに何を保存するか）
外に出す言葉づかい（使わない表現の線引き）
ここからは、irotsunaに限らず、個人開発でAIに任せる範囲を増やすときに効いた話です。CLAUDE.md、タスク管理、進捗管理、エージェント構成の4つを順に書きます。
CLAUDE.md：プロジェクトのルールブック
「このプロジェクトでは何を作っていて、どういう方針で、何をしてはいけないか」を書いておくと、AIが毎回同じ前提で動いてくれます。実際に書いていた内容は、だいたい次のとおりです。
プロジェクトの概要、技術構成、使っている外部サービスの一覧の場所
開発の手順（テストを先に書く、大事な処理には日本語で「なぜそうしたか」のコメントを書く）
通信の流れや大事な処理を変えたら、システムの流れ図（Mermaid）も必ず更新する
APIキーなどの秘密情報は、ログに出さない・コミットしない
フォルダごとの信頼度（「コードが一番正確」「仕様書は主な参照先」「初期の資料は古いので判断に使わない」）
マーケティング資料の場所と、外向けの文章で使ってはいけない表現
アプリ本体と公式サイトを別々のGitリポジトリで管理していること、それぞれの操作手順
特に効いたのが「フォルダごとの信頼度」です。開発初期のワイヤーや古い仕様書が残っていると、AIがそれを読んで、今の実装と違う判断をすることがありました。「ここは参考程度」と書いておくだけで、こうしたズレがかなり減りました。逆に、CLAUDE.md自体が古くなるとAIもずれます。機能を追加したら必ずCLAUDE.mdも直す、というのを習慣にしています。
タスク管理と進捗管理
「今日やりたいこと」を短く伝えて、できあがったものをその都度確認するやり方が、一番失敗が少なかったです。要件をあいまいなまま一気に頼むと、思っていたものと違う実装になることがありました。
進捗は PROGRESS.md というファイルに、完了したことを積み上げて残しています。「完了済みの項目は絶対に消さない」というルールも、CLAUDE.mdに書きました。何をすでに任せて、何が残っているかを、AIも自分も都度見返せるようにするためです。保留にしたタスクは、理由と再開の条件（例：「本番キーを設定したら必ず対応」）まで書いておきます。そこまで書いておくと、数週間後に自分が読んでも迷いません。
エージェント構成とカスタムコマンド
よく使う決まった作業は、毎回手で指示しなくて済むように、カスタムコマンド（スラッシュコマンド）として登録しました。
コマンド中身/basic-test分析 → テスト作成（失敗を確認）→ 実装 → テスト通過 → 整理 → コミット、を1機能・1バグ修正ごとに実行/blog-articleマーケ戦略と既存記事を確認 → テーマと公開日を提案 → 日本語版と英語版のペアを、1ペアにつき1つのエージェントで並行して作成/blog-upload公開待ちの記事を一覧化 → 画像ファイルの抜けをチェック → 確認を取ってからWordPressへ予約投稿 → 投稿ログを更新 → コミット
ブログで「1ペアにつき1エージェント」にしたのには理由があります。1つのエージェントで何本も書かせると、後半の記事ほど文章が似てきたり、前の記事の内容が混ざったりしたからです。作業ごとに頭の中（コンテキスト）を分けると、品質が安定しました。
デジタル塗り絵機能のような大きめの追加は、設計書・仕様書を専用のサブフォルダに切って実装しました。うまくいかなかったら、そのフォルダへの参照を外すだけで元に戻せる形です。失敗しても戻せると決めておくと、思い切って任せやすくなります。
テストを先に書く順番も、最後まで徹底しました。実装前にテストを書いて失敗を確認し、通る最小限のコードを書いて、整理する。あとから「動いているはずなのに崩れた」が減ったので、ここは個人開発でも省かない方がいいと思っています。
6. 公開までと、公開後の改善
コードを書き始めたのが2026年3月18日、App Storeで正式に公開したのが7月4日です。企画を始めた1月末から数えると、公開まで半年弱かかりました。Android版も準備していましたが、Google Playの開発者情報の公開要件の関係で、最初はiOSだけで出すことにしました。
公開後も改善を続けていて、主なバージョンはこうなっています。
時期バージョン主な内容2026年7月4日1.0.0正式公開7月4日1.1.0ギャラリー検索の強化8月2日1.2.0通知まわりの不具合修正、端末の言語で日本語/英語を自動で切り替え8月16日1.3.0デジタル塗り絵機能（バケツ塗り・ブラシ・スポイト・消しゴム・やり直し）、英語対応の完成8月下旬〜9月1.3.1〜1.4.1以降ブラシ7種、塗りパターン、バケツ塗りが広がるアニメーションなど、塗り心地の改善
アプリ本体のコミットは100件以上、公式サイト側も約80件になりました。特に8月は、公開後に見えてきた課題をまとめて直したので、1か月で60件以上のコミットをしています。
7. 運用：公開してからが本番だった
公開して一番感じたのは、作るより知ってもらう方がずっと難しいということです。1人だと、毎日SNSに投稿したり、ブログを書いたりする時間はとても取れません。そこで、運用もできるだけ仕組みにして、自動で回るようにしました。
7-1. 公式サイト（LP）をWordPressで自作
公式サイト（irotsuna.com）は、WordPressのテーマを自分で作っています。アプリの公開と同じ日に、サイト用のGitリポジトリも作りました。
SEOの設定は1つのファイルに集約しています。最初はSEO用のプラグインを入れていましたが、ページごとに設定がバラバラになり、どこで何が出力されているのか追えなくなりました。プラグインは無効にして、タイトル・説明文・SNS用の画像設定・構造化データを、テーマの functions.php でまとめて管理する形に変えました。
日本語と英語の切り替えは、URLの末尾に ?lang=en を付ける形です。画面の文字だけでなく、検索エンジン向けのタイトルや説明文も英語に変わります。サーバーのキャッシュが言語の切り替えを邪魔する問題が出たので、その対策も入れました。
無料で印刷できるぬりえのページも用意しました。「塗り絵 無料 印刷」は検索される回数が多いのに、上位のサイトが比較的小規模だとわかったからです。花・動物・季節・マンダラなど15テーマ、計210枚の線画をFLUXでまとめて作り、WordPressにページを一括で作るスクリプトも書きました。
アプリを入れる前に体験してもらえるよう、サイト上でも線画を作れるページ（/try/）を置いています。こちらは原価がかかるので、同じ接続元からは1日1回までに制限しました。
7-2. デプロイと修正のパイプライン
修正を「直す → 確かめる → 反映する」まで、なるべく手作業を挟まずに流れるようにしました。
公式サイト：main ブランチにpushすると、GitHub ActionsがSSH経由でXserverにファイルを同期します。pushから1〜2分で本番に反映されます
アプリ本体：pushやプルリクエストのたびに、GitHub Actionsでコード生成・整形チェック・静的解析・テストを自動で実行
不具合の修正：/basic-test で「テストを書いて失敗を確認 → 直す → テストが通る → コミット」までを1セットで回す
リリース作業：Claude Codeに頼むのはバージョン番号を上げるところまで。ビルドとApp Storeへの提出は自分の手でやる
公式サイトの自動デプロイは、初日につまずきました。XserverのSSHが標準とは違うポート番号を使っていることに気づかず、接続エラーでしばらく止まっていました。
不具合の修正は、直すたびに既存のテストも全部流します。直したつもりで別の場所を壊す、ということが減りました。リリースだけ手作業に残しているのは、審査に出すものは最後に自分の目で確かめたいからです。
7-3. XとPinterestへの自動投稿
アプリに投稿された線画を、Firebaseの定期実行（Cloud Functions）で、XとPinterestに毎日自動で投稿しています。
投稿先タイミング件数X毎日 19時・20時・21時1時間に1枚、1日3枚Pinterest毎日 9時1日5枚
Xは、仕事を終えた人がスマホを見る夜の時間帯に合わせました。投稿文も「本日もお疲れ様でした☕️」「夜のひとり時間に🕯️」のような、夜に溶け込む雰囲気のものを何パターンか用意して、毎回ランダムに選んでいます。線画のお題（例：「桜」）がある場合は、文面の中にお題を差し込みます。
同じ線画を二度投稿しないよう、投稿済みのものにはデータベース上で印を付けています。1件失敗しても、残りの投稿は止まりません。毎週月曜の深夜には、投稿したもののいいね・リポスト・表示回数（Pinterestは保存数・クリック数）を自動で集めて記録しています。どんな線画の反応がいいかを、後から見られるようにしました。
7-4. ブログ記事の自動化（一度作り直しました）
検索からの流入を増やすため、ブログ（irotsuna.com/blog/）も運用しています。ここは一度、仕組みを作り直しました。
最初は、Cloud Functionsの中でOpenAIのモデルに記事を書かせて、そのまま自動で公開する形でした。完全自動で楽ではあったのですが、文章がどうしても機械的で、同じような言い回しが続きます。中身を確認しないまま公開されてしまうのも不安でした。
そこで、この仕組みはやめて、次の形に変えています。
/blog-article で、記事のテーマと公開日をClaude Codeが提案し、自分が確認する
日本語版と英語版のペアごとにエージェントを立ち上げ、本文の執筆、FLUXでの画像3枚の生成、ファイル作成までを任せる
記事はフォルダ単位（本文・公開日などの情報・画像）でGitに保存する
/blog-upload で、画像の抜けをチェックし、自分が確認してからWordPressに予約投稿する
記事には文体ガイドを用意して、キャラクター2人の会話を入れて読みやすくしました。日本語の記事と英語の記事を1日ずつ交互に公開していて、これまでに42本（日本語21本・英語21本）を公開しています。
当初はGitHub Actionsから自動で投稿する予定でした。ただ、Xserverのファイアウォールに外部からの接続を止められたため、投稿だけは手元のPCから実行しています。全部をクラウドで自動化できなくても、人が確認する1ステップを挟む形の方が、結果的に安心して回せています。
7-5. SEO・ASOの戦略づくり
ブログやぬりえページを闇雲に増やさないよう、キーワード調査をもとにした戦略資料も作りました。
「塗り絵 無料 印刷」「ぬりえ 無料」：検索される回数がとても多いのに、上位のサイトが小規模で、入り込む余地がある
「大人の塗り絵」「塗り絵 効果」「塗り絵 ストレス解消」：ブログ記事の中心テーマ
「AIぬりえ」「AI coloring pages」：今はまだ検索数が少ないものの、競合がほとんどいないので先に取りにいく
「paint by number（数字で塗るデジタル塗り絵）」：別ジャンルの人が流入して離脱が増えるので、あえて使わない
この資料をCLAUDE.mdから参照できるようにしておくと、ブログやストアの説明文を書いてもらうときに、毎回同じ方針で書いてくれます。
7-6. 団体へのメールでの紹介
正直に書くと、ダウンロード数は思ったほどのペースでは伸びていません。そこで最近は、個人への発信だけでなく、レクリエーションやアクティビティに関わる団体に、メールでアプリを紹介し始めました。
送り先は、メールアドレスを公開している団体に絞った。国内は各都道府県のレクリエーション協会、海外はアメリカの州ごとのアクティビティ専門職の協会など
送信は、Node.jsのスクリプトで、公式ドメインのメールアドレスから送る
迷惑メール扱いされないよう、送信元を証明するDNS設定（SPF・DKIM・DMARC）を整え、本文は飾りのないテキストにして、配信停止の方法も必ず書いた
送信済みの記録を残して二度送らないようにし、1通ごとに少し間を空けて送る
本番の前に、自分宛てにテスト送信して見え方を確認した
文面は「打ち合わせしませんか」ではなく、「App Storeから無料で試せます」という案内だけにしています。相手の時間を取らせず、気になった人が自分で触れる形にしたかったからです。これまでに、国内外あわせて46の団体に送りました。
7-7. 運用の全体像
今は、だいたいこんな形で回っています。
頻度自動で回っていること人がやること毎日Xに3枚、Pinterestに5枚の自動投稿—毎日予約しておいたブログ記事の公開（日本語・英語を交互に）—毎時人気の投稿の順位の再計算—毎週月曜XとPinterestの反応を集めて記録反応を見て改善を考える毎月1日有料会員の生成回数のリセット—記事を足すとき執筆・画像生成・予約投稿までテーマと公開日の確認、投稿前の確認修正するときテスト・整形チェック・サイトへの反映何を直すかの判断、アプリのビルドと審査提出
8. 課金を入れて学んだこと
企画から開発まで通して、一番つまずいたのは課金まわりでした。手作業が必要になる部分が多く、しかも何をしているのか分からないままだと設定がうまくいきません。RevenueCatやApp Store Connect側の設定は、Claudeに聞きながら、全体の仕組みを理解しつつ進めました。
サブスクの「復元」（機種変更・再インストール時に購入状態を戻す仕組み）を最初に組み込んでおかないと、後からの修正が大変になる
App Storeの審査では、サブスクの説明文や解約方法の案内が画面内にきちんとあるかを細かく見られる
テスト用のサンドボックス環境と本番環境で動きが変わることがあるので、申請前に両方で確認する
購入やサブスクの更新・期限切れは、RevenueCatからの通知（Webhook）を受けて、サーバー側で会員の状態を書き換える。アプリ側の情報だけを信じない
課金の形も、最初から月額サブスクだけに決めつけませんでした。今は、初回は無料で3枚まで作れて、月額370円のプランなら毎月15枚。使い切ったら5枚250円・10枚480円で追加できる形です。月額を迷っている人にも、まず少し試してもらえる入り口を作りたかったからです。
都度課金を入れたときは、未使用のクレジットが積み上がると法律上の届出が必要になる可能性がある（資金決済法）ことも調べました。どのくらいの残高になったら見直すか、その目安を進捗ファイルに残しています。
動くものを作るより、審査に通って安心して使ってもらえる形にする方に時間がかかる。これが課金まわりの実感です。
9. これからのアプリ開発についての個人的見解
ここまでやってみて思うのは、これから個人でアプリを作る人にとって、コードを書く部分の負担はさらに軽くなっていくということです。実際、Flutter・Firebaseのコードや、デプロイ設定、テストコードまでは、Claude Codeにかなり任せられました。
もう1つの発見は、運用も同じように仕組みにできるということです。SNS投稿、ブログ、サイトの更新、団体へのメールまで、1人では手が回らないはずの作業が、今は自動で回っています。個人開発の弱点は「作ったあとに人手が足りない」ことでしたが、そこもAIで埋められるようになってきました。
一方で、自分の役目として最後まで残ったものもあります。市場調査からターゲットを決める判断、UI・UXがどう見えるべきかの最終判断、課金プランの作り方、外に出す言葉の選び方、失敗したときにどう戻すかの設計です。ブログの自動生成を一度やめたように、全部自動より「要所で人が確認する」方がうまく回る場面も多いです。ここは今後もしばらく変わらない気がしています。
CLAUDE.mdやタスク管理、進捗管理、エージェント構成といった「AIに何を任せて、何を自分で決めるかの土台」。これを先に整えておくほど、1人でも遠くまで作り切れて、運用まで続けられる実感があります。
今は、この経験を使って、業務の自動化（スプレッドシートの転記、問い合わせ対応、LINEの自動応答など）やアプリ開発のご相談をココナラで受けています。「これ作れる？」「自動化できる？」という方は、気軽にご相談ください。
