かりんだよ
5周年記念ライブツアーに向けて、
ファン参加型のWebアプリをAIコーディングツールで作っています。
セットリストを投稿したり、RPG風の遊びやスタンプを楽しんだりできるサイトです。
詳しい仕組みは1本目を見てね
配信はこちら
開発には主にClaudeを使いました！
最初はCursorだったのですが、途中でClaude Codeに移行しました。
2026年8月20日の最初のコミットから10月1日まで、約6週間。
実際に作業した日は15日ほどで、
コミットは60件になりました。
毎日ではなく、音楽活動今回は特にミュージカル稽古の合間にまとめて進めています。
この記事では、AIへ何を頼み、どこまで任せ、どう確認したかを書きます。
10月1日時点の記録で、全8会場15公演のツアー初日は10月17日。
アプリを作れたことと、
会場で運用できたかどうかはまだ別です、、
テスト配信は上手くいっただろうか、、
作りたい体験を、会話しながら仕様にする
作りたかったのは、
ファンのみなさんがセットリストに関わって、
一緒にライブを作ってる感覚になれる場所。
そこから宮本佳林の活動も広がるといいなと。
ただ、最初から技術を全部理解して、
完成形を一度に指定できたわけではありません。
欲しい体験を説明して、AIから質問や提案を受けて、仕様を決め直す。
その繰り返しで、最初の言葉だけでは決まっていなかった部分が見えてきました。
機能を増やす時期と、点検する時期
作業を振り返ると、大まかに4つの時期がありました。というかあったんだって！
| 時期 | 主に進めたこと |
|---|---|
| 8月下旬 | Workersへの移行、投稿、ホーム画面、楽曲管理、引き継ぎコード |
| 9月上旬 | 着せ替え、ペット、背景、称号などの世界観 |
| 9月中旬 | AIレビュー、バグ修正、管理セッション、iOS Safariへの対応 |
| 9月下旬〜10月1日 | QR、スタンプ、救済機能、配信テストの準備 |
機能を追加していると、
どうしても「できることが増えた」に目が向きます。
後半は機能を横断して、止まりそうなところや仕様の食い違いを探す時間を取りました。
コミット数や変更行数は作業の記録ですが、
品質の証明にはなりません。
楽曲マスタのようなデータも変更行数に含まれるので、数字だけでは分からないところです。
困ったことをCLAUDE.mdのルールにする
開発中のルールは、
リポジトリ直下のCLAUDE.mdにまとめています。
毎回の会話だけでは抜けやすいので、
作業開始時に参照する前提にしました。
- 作業はstagingブランチで行い、私の明示的な指示なしに本番へ反映しない
- 実装前に現状を調べ、計画を報告して、私が確認してから進める
- 原因が分からないまま推測で修正しない
- レイアウト変更は1項目ずつ、その都度確認する
- 崩れたら直前の状態へ戻してから、原因を報告する
- 楽曲名や人名など、指定した表記を守る
これは、実際に困ったことから増えていったルールです。
複数のレイアウトを一度に直すと、崩れた原因が分かりにくい。
文字を少し大きくするだけでも、
折り返しが増えて別の部分へ影響することがあります。
AIが一度にたくさんコードを書けても、
私が一度に確認できる量には限界があります。
変更を小さくして、その量に合わせて進めたほうが修正しやすくなりました。
本番は指示だけでなく、権限も分ける
本番については「触らないで」と書くだけでなく、ツール側の権限でもAIが直接読み書きできないようにしています。
AIが本番DBの確認クエリを実行しようとして、権限で止まったこともありました。
そのときはコマンドを提示してもらい、私が実行して、必要な範囲の結果を戻す形にしています。
本番の情報が必要でも、そのまま操作権限まで渡さず、人間が内容を確認する手順にしました。
もちろん、私が実行すれば間違いがなくなるわけではありません。コマンドの内容も確認が必要です。
それでも、AIが調査から変更まで進める途中に、本番操作の境界を置く意味は大きいと感じています。
AIレビューでも、戻れる状態を残す
複数のAIへレビューを回すスクリプトも用意しました。レビュー前後にコミットを残してから、
自動修正を進めています。
どこが変わったかを見られること、修正前へ戻れることを大事にしています。
直したことで別の問題が起きる可能性もあるので。
セッションをまたぐときの引き継ぎメモには、終わったこと、残っていること、守ってほしいことを残しています。
ただ、複数のAIが同じ結論でも、それだけで正しいとは限りません。
画面の見た目やブラウザでの操作、会場での使い方は、コードの指摘だけでは判断しきれませんでした。
自分の要望そのものを見直したこともある
印象に残っているのは、スタンプを取れなかった人への対応です。
「本番の日付を公演日に戻せたら助けられるのでは」と一旦考えました。
でもAIから、アプリ全体の時計を動かすと投票やお知らせにも影響すると説明されました。
私がしたかったのは、困った人のスタンプを取れるようにすることです。
そこで、スタンプに範囲を絞った救済機能にしました。
時間や対象の細かい仕組みは1本目に書いたとおりです。
自分の最初の案と違っていても、目的に合っているなら検討する価値があります。
技術に詳しくない私にとって、影響する範囲を説明してもらってから選べたことが助けになりました。
私の違和感から、仕様を確認し直す
配信テストの準備中、AIがスタンプQRを「会場ポスターに貼るもの」と説明しました。
でも、私が考えていたのは物販カードのQRです。
調べると、運用ドキュメントにはポスター、コード内のコメントには物販カードと書かれていました。
実装は購入履歴との照合ではなく、QRと取得期間で判定する仕組みでした。
「どこかに書いてある」だけで正しいとせず、ドキュメント、コメント、実装、私の意図を分けて確認する必要がありました。
会場に常設するQRは称号、物販カードのQRは公演スタンプ、と役割をそろえ、スタンプ数によって得られる称号の対応も見直しました。
既存の条件の仕組みを使えたため、名前や画像などの表示データを変えるマイグレーションで対応できました。
細かいコードが分からなくても、配り方が自分の考えと違うことには気づける。
そこで違和感を伝えたことが、確認し直すきっかけになりました。
「失敗したらどうなるか」まで点検する
テスト配信前の総点検では、参加を止めてしまう問題も見つかりました。
| 見つかった問題 | 利用者への影響 |
|---|---|
| 自動復元でTurnstileトークンが抜けていた | 復元リクエストが403で失敗する |
| 通信失敗や429を未登録と同じように扱っていた | 登録画面に戻され、情報が消えたように見える |
| QRの通信失敗を「無効なコード」と表示していた | 正しいQRを読み直す判断ができない |
| スタンプ取得の制限が1分8回だった | 続けて読み取ると、再試行の余地が足りない |
最後の例では、1分以内に8回読み取ると、成功した操作だけで枠を使い切ってしまいます。
通常の取得期間や運用場面に加え、読み直す余地も考える必要がありました。
機能が画面にそろっているだけでは、こうした問題は分かりません。
どこから入るか、通信が失敗したらどうなるか、そのあと何をすればいいかまで追うことで見えてきました。
エラー表示も、参加を続けられるかどうかに直接関わっていました。
実はこのブログ書いたあとに
負荷試験しなきゃじゃない！？となり
やりながらブログ書いてます、、！
APIまとめられるところはまとめてもらったり
AIくんにはかなり働いてもらいながらブログ書いてます
印刷するQRは、画像の中身まで確認する
QR画像を読み取って調べたら、外部の短縮サービスを経由してトップページへ行くQRだったこともありました。スタンプ用のリンクではないので、読み取れてもスタンプは取得できません。
そこで、短縮サービスを経由しない直接のリンクから作り直しました。QRは見た目だけでは中身が分からない、、
印刷前に、対象の環境、公演、取得までの動きを確認する必要があると学びました。
AIにコードを見てもらうだけでなく、実際に配る画像や、利用者がたどる入口も確認する。
会場で使うアプリでは、そこも開発の範囲でした。
AIに任せても、自分が決めることは残る
非エンジニアの私でも、具体的なアプリを形にできる範囲が広がったと感じています。
コードを書いてもらうことや原因を調べることで、AIには大きく助けられました。
でも、誰にどう使ってもらいたいか、どの不便を許容するか、本番でどこまで操作できるようにするかは、私が決める必要がありました。
AIの説明をそのまま正解にすると、自分の意図と違う仕様でも進んでしまいます。
変更を小さくする、本番の権限を分ける、戻れる状態を残す、利用者の操作を確認する。
これからもこの手順を続けたいです。
会場で確かめることはまだありますが、ファンのみなさんに楽しんでもらえるように、自分の意図を伝えることと、出来上がったものを確認することを大事にしていきます。
本番、上手くいくといいなぁ！！