😽

AIコーディングで「保活手帳」というアプリをリリースした

に公開
React
TypeScript
Claude Code
Kiro
idea

土曜日に「保活手帳」という、保育園や幼稚園の見学のときに使いやすい質問を管理できるアプリをリリースしました。

https://hokatsu-techo.com/

開発を始めた背景

今年、娘の保活が再度始まりまして、2回目の保活ということもあり、「見学のときこういうこと聞いたらいいな」というポイントもある程度あったのですが、いざその質問リストを管理しようとしたときに、使いやすいものがなくて困ったというのが発端です。

メモ帳に書いたりもしましたが、字が汚くて「これなんて書いたんだっけ？」となることも多々あり………。ちょうど、AIコーディング道場の題材にできるような小さい個人開発のネタを探していたというのもあって、チャレンジしてみることにしました。

AIコーディング道場って？

AIコーディングでソフトウェアエンジニアの仕事が加速しています。この時代の大きな変わり目において、いち早く、より上手にAIを活かしてソフトウェアエンジニアリングを実践するために「AIコーディング道場コミュニティ」が立ち上がり、アイデアの発想から2ヶ月で商用サービスをリリースすることを目標に、30名弱の道場生が日々AIコーディングを実践しています。

AIコーディングを体得する近道は、自分自身でAIコーディングを実践してそれなりの規模のサービスを設計・開発することです。とはいえ課題が山積しているのも事実です。この勉強会では、実際に本番を意識したアプリ・サービスを開発している道場生や、メンターをしているエンジニアから、「十分によく動き、役にたつソフトウェアをAIとともに開発している中で得られた課題や知見」を共有する目的で開催されます。

私は2期生として7月から参加しています。時間を決めてがっつり個人開発と向き合える時間を作れるのでとてもよいです！（娘のお世話しつつだから、フル参加はできていませんが・・・！）

生成AIを使ってあれこれやってみるようになってからちょっと自分の今後のキャリア的なものを考えるようになって、フロントエンドだけでじゃなく、その他の領域にも自分の興味関心を拾っていくきっかけを作りたかったというのもあり、参加を希望しました。

リリースまでの日数的には

  • 大体毎日1時間くらい
  • AIコーディング道場の日は約2時間
  • 日々の隙間時間

で1ヶ月半弱くらいです。

やったこと

Claude Codeを使ってほぼ全てAIコーディングです。
今回は作りたいものが明白だったので、最初からKiroで要件定義・設計書・実装計画を作成しました。

なお、リリース時期を優先したので主に開発前半は半分くらいしかコード見てません。さすがに後半になるにつれて目につく箇所が増えてきて、わかる範囲で修正指示を飛ばしたりしましたが、コードの品質的には50点もいかないと思います。

できなくて悔しいので、追々ClaudeなりChatGPTなりの学習モードも駆使しながらリファクタリングを行って、自分の力にしていきたい所存です。

足りてないなぁと痛感したところ

  • 出てきたコードに対して「なんか変」という感覚はあるけど、それを具体化できない
    • 「冗長じゃない？」とか「なんかこのコードまわりくどい気がする」みたいなふわっとした指示になりがち
  • テスト周りの根本的な知識不足。テストケースの策定はもちろんのこと、「なんかモック多くない？」くらいしかわからず、具体的な修正指示ができない
    • 基本的な書き方は知ってるけど、具体的にどう使っていくのかの経験値が圧倒的にない

楽しいなと思ったところ

  • プロンプト考えること。今回サブエージェント初めて作ったけど、うまく動いてHAPPY
  • 使い勝手を考えること。どうやったら使いやすくなるかな、とかそういうやつ

もっとできるようになりたい分野

  • テストケース考えたり、設計すること
    • 今回は全部AIにやらせたけど、ちょっとずつ勉強して差し替えていくつもり
  • UX、というかIA
    • 提供したものをより使いやすくしていくの楽しいし興味深い。IAは特に考えられるようになりたい

お勉強がんばります。

そんな私の感想は置いておいて、今回のAIコーディングでまた新しいものを取り入れたので、「これが私のAIコーディングだ！！！」を書き残しておきます。

Claude Codeの困りごと

  • CLAUDE.md を無視する
  • 関数コンポーネントとクラスコンポーネントが混在する（統一性がない）
  • 修正のはずなのに新規ファイルを作って機能重複させてわからなくする

先述の通り前半はガンガン行こうぜ状態だったので、特に新規ファイルで重複させてきてたのは結構困りました。自分で修正してもなんか反映されない………何で？って聞いたらファイル違います！って言われて白目剥きました。そのあたりからちゃんと見ないと逆に時間かかるなと思って見るようになってます。

困りごとを踏まえての対応

  • CLAUDE.md は読まれたらラッキーと割り切る
    • ↑を前提として、スラッシュコマンドやサブエージェントを活用する
  • わからんコードはClaudeのチャットの学習ツールを使って読み解く

CLAUDE.md は読まれたらラッキーと割り切る

読まなくてイライラするなら、最初から読まれないのを前提にする方がいいです。
途中で一時期ヤケになってこんな感じで必要最低限なCLAUDE.md にしたこともありましたが、これはこれで後から指摘が面倒になり、結局ほどほどに戻しています。

ヤケになったときのCLAUDE.md 

あなたはフルサイクルエンジニアです。要件定義書と設計書に従い、実装計画を実行してください。

要件定義書、設計書、実装計画は以下のファイルのことです。  
各資料を参照するように指示をした時は、以下のファイルの内容を参照して下さい。

- `.kiro/specs/nursery-visit-qa-app/requirements.md` - 要件定義書
- `.kiro/specs/nursery-visit-qa-app/design.md` - 設計書
- `.kiro/specs/nursery-visit-qa-app/tasks.md` - 実装計画

タスクを実行する時は、設計書を常に確認してください。設計書に書かれていないことは実行しないでください。

GitHubにコミットする時は、`.kiro/steering/commit-message.md` のコミットルールに従ってください。

今のCLAUDE.md

https://github.com/chiilog/nursery-faq-list-app/blob/main/CLAUDE.md

スラッシュコマンドやサブエージェントの活用

どちらも途中から導入しました。
CLAUDE.md を読まないなら、コードを作るとき or 作ったあとで守らせたらいいじゃない、というアプローチです。

カスタムスラッシュコマンド

  • LintやTypeScriptの型チェック、それからJSDocの整備をする /check コマンド
    • JSDocはTDDでやって、って指示するとコメントに高確率で // TDD ｳﾝﾀﾗｶﾝﾀﾗ みたいなコメントが残るのが気に食わなくて追加
  • 変更をConventional Commitsで適切な粒度でコミットさせる /pr-create コマンド
  • t-wadaさんのTDD手法に沿ってTDDでファイルつくる /tdd コマンド

/tddでファイル作って、/checkでチェック通して、/pr-createでPR用のブランチをつくる。という流れです。

ちなみに、/pr-createでプルリクエスト作成「して」までしてないのは、Claude Codeにgit pushの権限を与えていないからです。

こちらの記事を参考に、denyリストはがっつり入れています。

https://izanami.dev/post/d6f25eec-71aa-4746-8c0d-80c67a1459be#insights

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [],
    "deny": [
      "Bash(sudo:*)",
      "Bash(rm:*)",
      "Bash(rm -rf:*)",
      "Bash(git push:*)",
      "Bash(git reset:*)",
      "Bash(git rebase:*)",
      "Read(.env.*)",
      "Read(id_rsa)",
      "Read(id_ed25519)",
      "Read(**/*token*)",
      "Read(**/*key*)",
      "Write(.env*)",
      "Write(**/secrets/**)",
      "Bash(curl:*)",
      "Bash(wget:*)",
      "Bash(nc:*)",
      "Bash(npm uninstall:*)",
      "Bash(npm remove:*)",
      "Bash(psql:*)",
      "Bash(mysql:*)",
      "Bash(mongod:*)",
      "Bash(sed:*)"
    ]
  }
}

sed コマンドでコードをめちゃくちゃにされることにブチギレまくってるのでsedも入れておくのをおすすめします。

allow のリストにはMCPが色々入りますが、git addとgit commitは入れません。こいつはコンテキスト内で一度でも「コミットして」とか言うとそれを覚えていて、続きで「作業だけしてね」って明記しても作業が終わったらコミットします。やめろっつってんの！

サブエージェント

  • DRY原則とKISS原則の観点からコードをレビューする dry-kiss-code-reviewer
  • SOLID原則の観点からコードをレビューする solid-reviewer
  • React公式ドキュメントに準拠した、Reactのコードを専門的にレビューする react-reviewer
  • TypeScript公式ドキュメントに準拠した、TypeScriptのコードを専門的にレビューする typescript-reviewer
  • QAエンジニア視点でテストの網羅性、バグ検出力、品質を包括的にレビューする qa-reviewer

solid-reviewerは最近足したのでこれから活躍させます。

これらのサブエージェントはこのポストから着想を得ました！

https://x.com/taroro_tarotaro/status/1950191026213113896

公式ドキュメントが推奨する書き方に沿ってればまあトンデモコードになることにはなかろう………？という考えからです。時々ReactのレビュワーとTypeScriptのレビュワーが真逆のこと言い始めるけども。

そんなときは説明を聞いて、妥当な方を選びます。（よくあるのはuseCallbackの有無）

https://x.com/harumak_11/status/1949714099434385748

こちらの方のように並列で動かすことも考えたのですが、私の性に合ってるのは都度起動（どう変更されたか見るのが割と好き）なので今のところ都度「xxx を使ってレビューして」で行っています。

設計原則の名前、実は最近知りました。どういうことをするっていうのは部分的に身についてるけど、名前を知らなかったという謎ケースです。

とはいえ、まだ上澄みみたいな知識レベルなので、設計原則についても理解を深めていきたい今日この頃です。プロンプト作るのにも役立ちそうですし。

Claudeのチャットの学習ツール

こんな感じで、ファイル内のコードをﾍﾞｯ！！！とチャットに貼り付けて、ちょっとずつ読み解きます。

Claude Codeも学習モードに変えたらできる気はするけど、コード変更と受け取って作業始めるので油断なりません。

あと、なんとなくチャットのClaudeの方が説明上手な気がする………？単にCLI上で説明されても字がちっちゃくて見づらいだけかも。（目がしょぼしょぼするのはこれが原因か！？）

「ここはこういう理解であってる？」とか、とっ散らかった言葉でも拾ってもらえるのがありがたいです。人に説明できない時点で理解できてないってことだぞと教えられているので、とっ散らかったものを整理するのにもすごーーーーく役に立ちます。

学習モードにしつつGitHubリポジトリ参照もできそうな気配はするので、近いうちにもっと使い込んでみたいなと思っています。足りないまみれなのでね！可処分時間も全然足りないので効率よく学びたい気持ちがあります。

今後の動き

冒頭で反省している通り、何もかも足りてない＆わかるようになりたいものが多いので、50％の出来のコードをちょっとずつリファクタリングしたり、どういうUIだったら使いやすいかな？を追求していこうと思っています。

組み込みたいなとおもっているもの

ハードル高いのが残ってますがちょっとずつ組み込んでいきたい。

  • DB実装
    • まじでカケラも知識がないのでこれを実装するまでが長そうな気配
  • ソーシャルログイン
    • 夫婦でリスト共有したりしたい
  • 独自テンプレート機能
    • システム提供のテンプレート機能は絶賛開発中だけど、ユーザーが自分でテンプレート作れる機能もつけたい
  • 課金
    • ↑を有償で提供したい

Discussion