一人でAIプロダクトを作るならAIにはもっと働いてもらいたい / I want AI to work harder

2025/08/08に開催された「AIAgent勉強会｜AIエージェントの開発Tips・活用事例を持ち変えるLT×3」の登壇資料です。
https://almondo.connpass.com/event/362663/

Transcript

1. 一人でAIプロダクトを作るなら AIにはもっと働いてもらいたい 2025/8/8 r.kagaya AIAgent勉強会
2. 自己紹介 @ry0_kaga 新卒でヤフー株式会社に入社、ID連携システムの開発やフルリプ レイスPJに取り組む

 2022年に株式会社ログラスに入社
 経営管理SaaSの開発、横断課題改善チームを経て、生成AI/LLM チームの立ち上げ、新規AIプロダクトのリードエンジニア的なこ とをやっていた その後に独立、現職 Asterminds Inc. 共同創業者・ソフトウェアエンジニア r.kagaya(@ry0_kaga)
3. 今日の内容 話すこR ` AI-Driven Development Lifecycle (AI-DLC2 ` 新規でプロダクトを作る時にAI-DLCを 取り入れるために考えたこと / 取り組 みの一部 話さないこR ` 開発したプロダクトそのものの€ ` 言語 / フレームワークなどの具体的な 技術スタックやTips 新規開発・個人開発の場面で持ち帰ってもらえるものがおそらく多い
4. セッション自体はオンライン 現地でデモデーがあり、動いてるプロダクトが必要 当時（6, 7月）は有給を半分程度は取得していた が、フルタイムで開発できるわけではない （今回はほぼ触れないですが）開発したのは社内の 報告業務の自動化AIエージェント 背景
5.  日中フルで使えるわけではな7  → 隙間時間の活用とAIにどれだけ自動的に働いてもらえるか  +AIではなく、AI+を考えた7  +AI：既存の家にスマートスピーカーを置S  AI+：最初からスマートホームとして設計 （デモデー向けではあるので、ある程度はプロセスや技術の素振りに使った 最初に考えたこと
6. "W 人間がAIをトリガーするのではなく、AI自身がトリガーする範囲を増や4 W そのためにAIが開発しやすいアーキテクチャや構成、設計をす7 3W その上で、人間（私）は今まで開発できなかった時間での開発にチャレンジする やりたかったこと
7. https://aws.amazon.com/jp/blogs/devops/ai-driven-development-life-cycle/ AWSのAI Driven Development Life Circle
8. https://aws.amazon.com/jp/blogs/devops/ai-driven-development-life-cycle/ AWSのAI Driven Development Life Circle 「AI initiates & directs the conversations with humans instead of humans initiating the conversation with AI」

 訳) 「人間がAIに指示するのではなく、AIが人間に提案し、会話を 主導する」
9. 3 中心的な考え方は「対話の方向性の逆転」。AIが主導し、人間が検g 3 AIが計画を提案、人間が重要な背景知識（コンテキスト）を提供し、監督と承` 3 設計をプロセスに組み込H 3 DDDのような設計技法をオプションとせず、プロセスの中心Q 3 新しい用語、高速化されたサイクルの提t 3 Bolts (ボルト): 週単位のスプリントに代わる、数時間〜数日単位の作業サイク& 3 Units of Work: エピックに代わる作業単 3 チームはコラボレーションに集中（モブセッションなど）
 AWSのAI Driven Development Life Circle https://aws.amazon.com/jp/blogs/devops/ai-driven-development-life-cycle/
10. AI-DLCを知ったのは最近

 しかし、同じようにAI主導の機会を増やせたら良いと考えた
11. 具体的に何をやったか

 正直、当初の野望に見合うことはしてない・できなかった （デモデーのために英語対応とか必要で...）
12. ざっくりイメーW Ȅ PRプレビュー環境を作 F„ Claude Code Actionと定期実行を仕込I @„ 特定Slackチャンネルのコメント（e.x. 〇〇の修正が必要） やエラーログを元にGithub Issueを作É y„ Github Issueを定期的にAIが選んでPR生É „ （後述）移動中に簡単なものは動作確認・レビュー AIトリガーでGithub IssueやPRを作成可能にする
13. > I'm convinced it isn't legal to start an AI startup without mentioning the data flywheel. 訳）私は、データ・フライホイールについて触れずにAIスタートアップを立ち上げるこ とは合法ではないと確信している。 O'reilly AI Engineering by Chip Huyenより抜粋 AIへの学習ループを回す
14. データ・フライホイールはこういうの（たぶん） https://vercel.com/blog/eval-driven-development-build-better-ai-faster
15. AI Driven Developにおいても学習ループを回すことは大事

 AIが半自動で回る仕組み、それを改善する部分も自動化したい
16. AIコードレビュー系ツールなどのように好みや観点を教えられるように
 ミニマム実装として、xxx.mdなどに観点を残す Step 1: 補助 Step 2: 承認 Step 3: 自律 人間が観点を手動で教える Claude.mdにたまに振り返る ように仕込んでおき、定期的 に人間が修正する AIから人間に新しく学ぶ観点 を提案する
 Github ActionsでIssueやPR のやりとりを元にmdファイ ルの修正提案をさせてみた AIが勝手に学んで修正できる 修正提案に留まらず、勝手に 観点ファイルを更新できるよ うにした シンプルに実装
17. 9 一応Step 3（AIが勝手に提案・マージ）までやっては見s 9 コードレビュー系であれば対して気にならなW 9 Issue作成 / PR実装の観点に違和感のある内容が数回潜り混んでた時点で、面倒に 感じ落としてしまっs 9 レビューのレビューのレビューの世 9 Slackコメントやエラーログから勝手にIssueが作られ、それが自動的に開発に進んで いくパイプラインは結構感動した（ベルトコンベアみたいにPRまで進む） 学習ループの設計は大事。運用を考えるともう少しメンテにコスト割きたいという感想 やってみての感想
18. AIのガードレールの話はされている（TDDやらpre-commit）
 加えて、学習・改善ループをいかに回すか？も重要 学習ループの半自動化 / AI活用ができていたら、
 今後のモデル進化にもさらに上手く乗れそう
19. 出来るだけAIコーディングと相性が良さそうな技術を中心に選びたかった 可能な限りllms.txtやMCPサーバーが提供されているものなど（Mastra, Convex, etc..
 ALL TypeScriptや関連ドキュメントまで含めたモノレポ構成にしたり、複数モデル・AI コーディングエージェントに技術選定させてよく出てくるライブラリを採用したり （それだけよく学習されているのでは？と考えた） AIが住みやすい環境を作る
20. 今回のデモデー向けの開発で一番効いたのはおそらくConveB b TypeScript-nativeのSupabase的なPE b DBスキーマ、API（クエリ/ミューテーション）までTypeScriptで書けるようにI/F・ 関数を提È b テーブル定義を更新するとDBも勝手に更新され b スキーマ不一致はエラーにな b MCPサーバーやllms.txtも提供 https://www.convex.dev/ AIが住みやすい環境を作る
21. b （数ヶ月前時点での個人的感想だが）SupabaseよりAIコーディングエージェントが エラー解消まで自律的に駆動してくれq b スキーマエラーも全てログに出るので、エラーが出たらひたすらAIに投げてたら普通 に開発には困らなÈ b DBマイグレも不要で、ホットリロードでサクサク開発できる https://www.convex.dev/ PoC/プロト開発の観点では本当に楽というのが感想。一方で本番運用時のコストやス ケーラビリティなどは未検証（今回はデモデーしか考えてない） AIが住みやすい環境を作る
22. Convex vs Supabase https://www.convex.dev/compare/supabase
23. と言っても、隙間・移動時間にSlack等から出来るだけ開発 進められるようにしたのr x 移動中にIssueを立てる。Issueプランニング用のGem を用意したり、スマホからCLI動かしたり、リモートデ スクトップに繋いでみたり.. x PRプレビュー環境を構築してたので、小さな動作確認 や細かいUI修正は移動中に行ったり.. （折り畳みスマホを買ったので、大きな画面を有効活用したかった。しかし、移動中まで 何かしてると普通に疲れるので、途中で辞めた..） 今までより開発に関われる時間を少しでも増やす
24. まとめ
25. 開発フローの自動E T エラー→イシュー→P4 T ログ→分析→提案 次のアーキテクチャやプロセス設計のパラダイ T AIを使うのではなく、AIのために設計すÀ T プロセスの改善ではなく、プロセスの再発明 個人的にAIネイティブな開発で燃えるのは開発パイプラインの自動化
26. d 出来るだけ人手をかけず / 隙間時間でプロダクトのMVPを作るための取り組みについ て話し‘ d AWSが提唱するAI-DLCがどうかはさておき、AIネイティブな開発プロセスには、プロ セスの改善ではなく再発明という発想が必要という想いを強くし‘ d AI⁨⁩ネイティブな開発プロセスにも、AIのガードレールに加えて、学習・改善ループを いかに回すか？も重 d 半自動化 / AI活用ができていたら今後のモデル進化にも上手く乗れるのではないか （終わってみたら会社設立前などのアーリー組は別にプロダクトデモ不要そうだった まとめ