前回の「ひとり開発会社」の記事では、Claude Codeの汎用スキル11本で作った「本社」の話をしました。
今回はその続編、現場編です。舞台は配信中のiOSアプリ「Morphica」(写真をAIでスタイル変換するFlutter製アプリ)。作る話ではなく、運用する話 — 週次の数字集計、リリース準備、本番DBの変更確認といった「地味だけど毎週やってくる仕事」を、Claude Codeでどう回しているかを公開します。
この記事で分かること
- 配信中アプリの「現場」に置いているプロジェクト専用スキル11本の中身
- 週次KPIレポート(App Storeの売上+GA4)を1コマンドにした方法
- リリース準備・本番DB変更チェックなど、運用SOPのスキル化の実例
- 運用をAI化して分かった、効く場所と効かない場所
結論: AI化が一番効くのは「開発」ではなく「運用」だった
Claude Codeの話題は「どう作るか」に集中しがちですが、1年アプリを配信して思うのは、個人開発の体力を削るのは運用だということです。毎週の数字確認、リリースのたびの定型作業、本番を触るときの緊張感 — ここにこそ手順書(スキル)と自動化が効きます。
- 数字の集計は完全自動化: 売上・DL・イベント計測を横断した週次レポートが1コマンド
- リリース準備は1スキル: バージョン更新からリリースノート日英作成まで一括。人間の仕事はXcodeでアーカイブするだけ
- 本番変更は「安全判定」スキルを通す: 配信中の旧バージョンを壊さないかをAIに調査させてから実行
現場の組織図: Morphica専用スキル11本
前回の汎用スキルが「本社」なら、こちらはMorphica専属の「現場チーム」(.claude/skills/)です。
| 領域 | スキル | 仕事 |
|---|---|---|
| 開発 | /add-feature |
Clean Architectureの3層雛形+ルート登録+翻訳キーを一括生成 |
| 商品追加 | /create-style |
新しいAIスタイルをアプリ・Workers・LPの3面に横断追加 |
| 品質 | /test-gen /ui-review |
テスト自動生成/画面のUI・アクセシビリティレビュー |
| 多言語 | /localize |
日英の翻訳キー同時追加・未翻訳検出 |
| 障害対応 | /debug |
プロジェクト固有のエラー分類表・ファイル地図つきのバグ調査 |
| 本番安全 | /db-migration-check |
DB・Workers変更が配信中の旧バージョンに与える影響を判定 |
| リリース | /release-prep |
バージョンbump・リリースノート日英・お知らせSQL・記録更新・Xcodeチェックリスト |
| マーケ | /marketing /sns-marketer |
ASO・競合分析/SNS投稿文とコンテンツカレンダー |
| 即応 | /trend-response |
バズったAI画像ミームに48時間以内に対応する3段階SOP |
汎用スキルとの関係は「同じ目的なら専用を優先」。たとえば汎用の/diagnoseではなくMorphica専用の/debugを使います。専用側は「このアプリはどこで何が壊れやすいか」を知っているからです。
実例1: 週次KPIレポートを1コマンドに
毎週月曜の「数字確認」は、以前は App Store Connect と GA4 を行き来する30分仕事でした。今は:
node tools/kpi/fetch_kpi.mjsこれだけです。このスクリプトが、
- App Store Connect の salesReports API から日別DL数・課金units
- GA4(アプリとLPの2プロパティ)から画像生成数・シェア数・ストア送客など16イベントの前週比
- iTunes lookup から現在の★評価とレビュー数
を取得して、docs/reports/kpi/2026-08-08.mdのような前週比つきレポートを自動生成します。依存パッケージなしのNodeスクリプトで、認証(ASCの秘密鍵やGCPサービスアカウント)は環境変数から注入。取れなかったデータソースはスキップして、取れたものだけでレポートを作る設計です。
ポイントは、このスクリプト自体をClaude Codeに書かせたことです。ASCのJWT認証やGA4 Data APIの呼び出しは自分でゼロから書くと億劫な部類ですが、「この3ソースから週次レポートを作りたい」という要件から実装・修正までを任せました。一度できてしまえば、あとは毎週同じ数字の見方ができる — 計測の一貫性こそ、このシリーズの記事で実数を出せている土台です。
実例2: リリース準備を1スキルに
アプリのリリースは、コードが完成してからが長い。バージョン番号の更新、リリースノートの日英作成、アプリ内お知らせのSQL、記録の更新、提出前チェック — 毎回同じなのに、毎回どれかを忘れそうになります。
/release-prepは、これをリリーストレイン一括準備としてスキル化したものです。実行すると、バージョンbumpからリリースノート(日英)、お知らせSQL、ドキュメントの記録更新までを済ませ、最後にXcodeでの手動作業チェックリストを提示して止まります。
この「止まる場所」が設計のキモです。アーカイブとストア提出は人間の仕事(本番反映は必ず自分の手で)。AIは提出台までを完璧に整え、ボタンは自分で押す — この分担にしてから、リリース作業の抜け漏れがなくなりました。
実例3: 本番を触る前の「安全判定」
配信中のアプリで一番怖いのは、本番DB(Supabase)やAPI(Cloudflare Workers)の変更が、いまユーザーの手元で動いている旧バージョンを壊すことです。アプリはWebと違って、全員が最新版ではありません。
/db-migration-checkは、マイグレーションSQLやWorkersの変更を渡すと「現行版・旧版のコードがこの変更をどう受けるか」を調査して安全性を判定するスキルです。UGC審査リジェクト対応の記事で、審査用ビルドとは別に本番DBへモデレーション基盤を先行適用した話を書きましたが、あの判断もこのスキルで「現行版への影響なし」を確認してから実行しています。
実例4: 「48時間以内」をSOPにする
/trend-responseは少し毛色が違って、スピードそのものをスキル化した例です。SNSでAI画像のミームがバズったとき、48時間以内に「いま話題」枠の更新/固定スタイル追加/LP単発ページのどれで乗るかをTier判断して実行する3段階SOP。
これが成立する背景には、アプリ側の設計もあります。Morphicaは「いま話題」のプロンプトをLP上のJSONから読み込むので、ストア審査を通さずにアプリ内の推しコンテンツを差し替えられる。トレンド対応の速さは、AIの速さと「審査なしで変えられる場所を作っておく」設計の掛け算です。
運用AI化で分かったこと
正直な総括です。
- 効く場所: 集計(完全自動化)、定型準備(チェックリスト化)、安全確認(観点の網羅)。共通点は「正解の形が決まっている仕事」
- 効かない場所: 何を作るか、いつ出すか、どの数字を重く見るか。判断はAI化しない方がいい — というより、判断だけが自分の仕事として残るのが理想形です
- 新しく増えた仕事: スキルの手入れ。実装が変わればSOPも古びます。「スキルを直す」が運用の一部になりました
- 副産物: 手順が全部ドキュメント化されるので、数ヶ月ぶりに触るプロジェクトでも迷いません。スキルは未来の自分への引き継ぎ書でもあります
まとめ
- 個人開発の体力を削るのは開発より運用。そして運用は「正解の形が決まっている仕事」が多く、AI化と相性がいい
- Morphicaの現場は専用スキル11本+自動集計スクリプトで回っている: KPIは1コマンド、リリース準備は1スキル、本番変更は安全判定を通す
- 分担の原則は「AIは提出台まで、ボタンは人間」。本番反映と判断は自分に残す
- スキルは未来の自分への引き継ぎ書。配信中のアプリが1本でもあるなら、まず「毎週やっている作業」を1つスキル化してみてください
本社編(汎用スキルの作り方)は前回の記事へ。次があるとすれば監査編 — AIに既存コードの棚卸しをさせる話も、いずれ書きます。
