ツラミをAIに直させ続けたら、開発ワークフローが激変した話
前回の記事でAIエージェントの開発ワークフロー管理ツール「Releash」を紹介しました。
Releashは開発開始から三週間、記事の公開から4日の間にも急速に成長しています。
その開発経緯と、そこから得られた知見を振り返ります。
レビューが辛かった
きっかけはdiffレビューの体験でした。
Claude Codeに実装を任せて、終わったらdiffを確認してフィードバックを送る。この繰り返しがとにかく煩雑でした。
PRでレビューコメントを書いてAIに読ませる方法や、Difitのようなツールでローカルのdiffを確認する方法はありました。
ただ、どれも断片的です。
diffの確認とフィードバックの送信が別々のツールに分かれていて、統合された体験になっていない。
「差分を見て、気づいた点をエージェントに伝える」を一箇所で完結させたい。
これが出発点でした。
AIに任せて作ることにした
感じたツラミを解決するツールが見つからなかったので、自分で作ることにしました。
方針として、エージェントの挙動には一切干渉しないことを決めました。
CLIエージェントの自由度をそのまま活かし、「レビューと軽い操作を提供する土台」に徹する。
CLIエージェントは進化が最も早い領域で、Hooks、Skill等の仕組み化手段も豊富です。
エージェント本体の進化は各ベンダーに任せて、自分は運用体験だけを整えればいい。
保守の手間を最小にしたかったので、設計は「gitとファイルシステムを見るだけ」にしました。
独自のDBやクラウドサービスは持たず、設定はTOML1つ。
マイグレーションもサーバー運用も利用料金も発生しません。
特定のエージェントにもロックインされず、Claude Code、Aider、Cline等と自由に組み合わせられます。
この割り切りは、AIに実装を任せる上でも都合がよかった。
構造が単純なほどAIの精度は上がります。
そこまでAIに任せられるなら、もっと踏み込めるのではないか。
ちょうどこの頃、「汎用アプリは廃れ、個人に最適化されたアプリをAIに作らせる時代が来る」と言われ始めていました。
AIが実装を担えるなら、万人向けの汎用ツールに合わせる必要はない。
自分のワークフローに最適なツールを、AIに作らせればいい。
本当にそれが成り立つのか、自分の手で確かめたいと思いました。
そこで、自分はコードを書かないという制約を課しました。
問題をIssueに書き、エージェントに実装させ、diffをレビューしてフィードバックを送る。
このサイクルだけで開発を回す実験です。
使う、辛い、直す、のループを回し続けた
MVPができた後、Releash自体の開発をReleash上で行うことにしました。
自分が最初のユーザーです。
CLIエージェントの成熟により実装フェーズは安価になっていました。
不満に気づいたらIssue化し、エージェントに投げ、diffをレビューする。
早ければ数分で改善が手元に届きます。
このサイクルの軽さが、ツールを勝手に育てていきました。
1つが軽いなら、同時に複数回せばいい。
エージェントを並列で走らせる運用が日常になると、実装以外の工程が目立ち始めます。
worktreeの作成、エージェントの起動、指示の記述、diffの確認、PRの処理。
準備と回収の手間が並列数に比例して膨れ上がる。
worktreeの手動管理が面倒でした。
アプリ上で作成から削除まで完結させて解決。
セットアップが楽になると、今度は複数のターミナルを巡回してエージェントの状態を確認する手間が気になり始めます。
Hooksで状態を検知し、どのエージェントが待機中かを一覧で把握できるようにして解決。
SSHでモバイルからアクセスする運用の手間が気になってきました。
スマホからアクセスできるリモートUIを組み込み、確認から指示出しまで完結させて解決。
エージェントにタスクの背景を伝える手間も出てきました。
タスクリストから命名規則で紐づいたworktreeを作り、Skillでタスク情報を直接渡す仕組みで解決。
1つ直すと次の辛さが見える。
使って、直して、また使う。
リポジトリ作成から17日間で、Issue 222件、PR 133件を処理しました。
ロードマップを引いたわけではありません。
このアプリはこの課題を解決するものだ、という一貫したテーマもありません。
目の前の辛さに反応し続けていたら、エディタもターミナルも開かなくなっていました。
GitHubでIssueを書く。
ReleashでIssueからworktreeを作る。
SkillでIssueの情報をエージェントに渡し、足りなければ追記する。
Issueが明確になればエージェントに実装させ、diffをレビューしてフィードバックする。
PRを作成させ、CIの結果を見て、マージする。
これを多いときは20本同時に回している。それでも必要なのはブラウザとReleashだけ。
ワークフロー全体を統合する「個人に最適化されたアプリ」が、いつの間にか出来上がっていました。
AIに任せる開発の条件
振り返ると、これが成り立ったのには前提がありました。
1. ドメインが狭いこと
ドメインが広ければ問題の分解だけで時間を取られる。
ビジネスロジックが絡むシステムでは、Issueを1つ書くために必要な文脈が膨大になります。
このスタイルでは開発の中心がIssue作成とレビューになるので、問題を明確に定義できる狭さが前提でした。
2. 知見が公開されていること
知見が閉じた領域では解決手段の探索コストが跳ね上がる。
社内固有の仕様やニッチな技術では、AIの参照先自体が存在しません。
公開されたOSSの解決策を出発点にできるか、自分が専門家として導けるか。
どちらかがなければこのループは回りませんでした。
3. アーキテクチャが単純であること
アーキテクチャが複雑なら試す、作る、レビューする、の全ての速度が落ちる。
変更の影響範囲が読めなければレビューに時間がかかり、ループが重くなります。
単純な構造を維持し続けることで、AIが仕様や実装箇所を早く正確に把握でき、ループの速度を保てました。
この3つが揃っていたからこそ、AIに任せる開発は機能しました。
おわりに
引き続き、Releash自体をReleash上で開発していきます。
不便を感じたらすぐ直す。このサイクルを回し続けます。
フィードバックやIssueはいつでも歓迎です。
ただ、それ以上に見たいのは、各々が自分のワークフローに最適化したツールを作り、公開し、互いに参照しあう世界です。
みなさんの最強のオレオレツールを楽しみにしています。
Discussion