一人でAIプロダクトを作るなら AIにはもっと働いてもらいたい 2025/8/8 r.kagaya AIAgent勉強会 

自己紹介 @ry0_kaga 新卒でヤフー株式会社に入社、ID連携システムの開発やフルリプ レイスPJに取り組む

 2022年に株式会社ログラスに入社
 経営管理SaaSの開発、横断課題改善チームを経て、生成AI/LLM チームの立ち上げ、新規AIプロダクトのリードエンジニア的なこ とをやっていた その後に独立、現職 Asterminds Inc. 共同創業者・ソフトウェアエンジニア r.kagaya(@ry0_kaga) 

今日の内容 話すこT A AI-Driven Development Lifecycle (AI-DLCD A 新規でプロダクトを作る時にAI-DLCを 取り入れるために考えたこと / 取り組 みの一部 話さないこT A 開発したプロダクトそのものの€ A 言語 / フレームワークなどの具体的な 技術スタックやTips 新規開発・個人開発の場面で持ち帰ってもらえるものがおそらく多い 

セッション自体はオンライン 現地でデモデーがあり、動いてるプロダクトが必要 当時（6, 7月）は有給を半分程度は取得していた が、フルタイムで開発できるわけではない （今回はほぼ触れないですが）開発したのは社内の 報告業務の自動化AIエージェント 背景 

C 日中フルで使えるわけではなc C → 隙間時間の活用とAIにどれだけ自動的に働いてもらえるか4 C +AIではなく、AI+を考えたc C +AI：既存の家にスマートスピーカーを置 C AI+：最初からスマートホームとして設計 （デモデー向けではあるので、ある程度はプロセスや技術の素振りに使った 最初に考えたこと 

C 人間がAIをトリガーするのではなく、AI自身がトリガーする範囲を増やB &C そのためにAIが開発しやすいアーキテクチャや構成、設計をす9 ÇC その上で、人間（私）は今まで開発できなかった時間での開発にチャレンジする やりたかったこと 

https://aws.amazon.com/jp/blogs/devops/ai-driven-development-life-cycle/ AWSのAI Driven Development Life Circle 

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が人間に提案し、会話を 主導する」 

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

AI-DLCを知ったのは最近

 しかし、同じようにAI主導の機会を増やせたら良いと考えた 

具体的に何をやったか

 正直、当初の野望に見合うことはしてない・できなかった （デモデーのために英語対応とか必要で...） 

ざっくりイメーx ’d PRプレビュー環境を作Á 8d Claude Code Actionと定期実行を仕込Y qd 特定Slackチャンネルのコメント（e.x. 〇〇の修正が必要） やエラーログを元にGithub Issueを作I ad Github Issueを定期的にAIが選んでPR生I Çd （後述）移動中に簡単なものは動作確認・レビュー AIトリガーでGithub IssueやPRを作成可能にする 

> 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への学習ループを回す 

データ・フライホイールはこういうの（たぶん） https://vercel.com/blog/eval-driven-development-build-better-ai-faster 

AI Driven Developにおいても学習ループを回すことは大事

 AIが半自動で回る仕組み、それを改善する部分も自動化したい 

AIコードレビュー系ツールなどのように好みや観点を教えられるように
 ミニマム実装として、xxx.mdなどに観点を残す Step 1: 補助 Step 2: 承認 Step 3: 自律 人間が観点を手動で教える Claude.mdにたまに振り返る ように仕込んでおき、定期的 に人間が修正する AIから人間に新しく学ぶ観点 を提案する
 Github ActionsでIssueやPR のやりとりを元にmdファイ ルの修正提案をさせてみた AIが勝手に学んで修正できる 修正提案に留まらず、勝手に 観点ファイルを更新できるよ うにした 観点の学習・チューニング機構をシンプルに実装 

3 一応Step 3（AIが勝手に提案・マージ）までやっては見s 3 コードレビュー系であれば対して気にならな` 3 Issue作成 / PR実装の観点に違和感のある内容が数回潜り混んでた時点で、面倒に 感じ落としてしまっs 3 レビューのレビューのレビューの世 3 半自動的にIssueが作られ、それが自動的に開発に進んでいくパイプラインはクオリ ティはさておき、結構感動した（ベルトコンベアみたいにPRまで進む） 学習ループの設計は大事。運用を考えるともう少しメンテにコスト割きたいという感想 やってみての感想 

AIのガードレールの話はされている（TDDやらpre-commit）
 加えて、学習・改善ループをいかに回すか？も重要 学習ループの半自動化 / AI活用ができていたら、
 今後のモデル進化にもさらに上手く乗れそう 

出来るだけAIコーディングと相性が良さそうな技術を中心に選びたかった 可能な限りllms.txtやMCPサーバーが提供されているものなど（Mastra, Convex, etc..
 ALL TypeScriptや関連ドキュメントまで含めたモノレポ構成にしたり、複数モデル・AI コーディングエージェントに技術選定させてよく出てくるライブラリを採用したり （それだけよく学習されているのでは？と考えた） AIが住みやすい環境を作る 

今回のデモデー向けの開発で一番効いたのはおそらくConvey b TypeScript-nativeのSupabase的なPW b DBスキーマ、API（クエリ/ミューテーション）までTypeScriptで書けるようにI/F・ 関数を提h b テーブル定義を更新するとDBも勝手に更新され& b スキーマ不一致はエラーにな& b MCPサーバーやllms.txtも提供 https://www.convex.dev/ AIが住みやすい環境を作る 

P （数ヶ月前時点での個人的感想だが）SupabaseよりAIコーディングエージェントが エラー解消まで自律的に駆動してくれ P スキーマエラーも全てログに出るので、エラーが出たらひたすらAIに投げてたら普通 に開発には困らな2 P DBマイグレも不要で、ホットリロードでサクサク開発できる https://www.convex.dev/ PoC/プロト開発の観点では本当に楽というのが感想。一方で本番運用時のコストやス ケーラビリティなどは未検証（今回はデモデーしか考えてない） AIが住みやすい環境を作る 

Convex vs Supabase https://www.convex.dev/compare/supabase 

と言っても、隙間・移動時間にSlack等から出来るだけ開発 進められるようにしたの€ b 移動中にIssueを立てる。Issueプランニング用のGem を用意したり、スマホからCLI動かしたり、リモートデ スクトップに繋いでみたり.. b PRプレビュー環境を構築してたので、小さな動作確認 や細かいUI修正は移動中に行ったり.. （折り畳みスマホを買ったので、大きな画面を有効活用したかった。しかし、移動中まで 何かしてると普通に疲れるので、途中で辞めた..） 今までより開発に関われる時間を少しでも増やす 

まとめ 

開発フローの自動F H エラー→イシュー→P! H ログ→分析→提案 次のアーキテクチャやプロセス設計のパラダイ H AIを使うのではなく、AIのために設計すÁ H プロセスの改善ではなく、プロセスの再発明 個人的にAIネイティブな開発で燃えるのは開発パイプラインの自動化 

9 出来るだけ人手をかけず / 隙間時間でプロダクトのMVPを作るための取り組みについ て話し‘ 9 AWSが提唱するAI-DLCがどうかはさておき、AIネイティブな開発プロセスには、プロ セスの改善ではなく再発明という発想が必要という想いを強くし‘ 9 AI⁨⁩ネイティブな開発プロセスにも、AIのガードレールに加えて、学習・改善ループを いかに回すか？も重0 9 半自動化 / AI活用ができていたら今後のモデル進化にも上手く乗れるのではないか （終わってみたら会社設立前などのアーリー組は別にプロダクトデモ不要そうだった まとめ