ランチから帰ってきたら実装が終わっている。 queue コマンドで広がった、開発と生活の余白

みなさん、ありがとうございます！

フォローといいね、本当にありがとうございます。感謝です！感動です！

「こんなの誰が使うんだろう」と思いながら作っていたものを、こんなに応援してもらえるとは思っていませんでした。

前回の記事を書いたときは v0.56.0 でした。「マイナーバージョンを 55 回上げてきました」と書きました。あれから、また 56 回 更新しました。つまり今は v0.112.0 です。トータルで 111 回。頑張りすぎやろ……（笑）。

今回の目玉は queue コマンドです。これが今回の記事で一番伝えたいこと。

ランチから帰ったら、実装が終わっていた

最近の開発スタイルはこうです。

午前中に AI と仕様を相談しながら、kickoff で Issue を 10 本以上まとめて作る。「この機能」「あのリファクタリング」「ここのテスト追加」——思いつく限りのタスクを全部 Issue にしてしまう。

それを queue に積んで、ランチに行く。

帰ってきたら、 Telegram に通知が何件も来ていて、実装が進んでいる。場合によっては 1〜2 時間ほったらかしにできます。他の仕事もできるし、新しい企画を考えることもできる。パソコンの前から離れていい。

これ、ほんまに生活が変わりますよ。

queue とは何か

queue は fullrun の連続実行コマンドです。

前回の記事で fullrun の話をしました。「fullrun してと一声かけたら、計画・実装・テスト・ PR 送信・マージまで全部やってくれる」という、1 Issue を処理するワークフローです。

これ、単体でも十分すごいんですが——複数の Issue を順番に処理させたい、という欲が出てきた。当然の流れですよね。

queue に Issue 番号を並べると、 AI が順番に fullrun を回してくれます。 fullrun が 1 本終わったら次の Issue へ、それが終わったらまた次へ。完全に自律した連続実行です。失敗が起きたらそこで止まる（fail-fast）ので、変なものが積み上がっていく心配もない。

ポイントは ステップ 1 の仕様検討です。10 本以上の Issue を一気に作るとき、僕は必ず AI と一緒に考えます。「この機能、どういう仕様にする？」「この順番でいい？依存関係はある？」という対話を経てから Issue を作るので、 queue に積む前に方向性が整理されている状態になっている。土台をちゃんと作ってから、あとは AI に全部任せる——この構図が今の開発スタイルです。

kickoff が自動で Issue を分割してくれる

さらに便利になったのが、 kickoff の自動分割機能です。

「この大きな機能をまとめて実装して」と kickoff に伝えると、 AI がスコープを評価して「これは複数の独立した作業に分けた方がいい」と判断した場合、自動的に Issue を複数に分割してくれます。そしてその場で queue #N1 #N2 #N3 ... というコマンドを提示して止まる。

つまり、「大きな依頼を 1 回する → Issue が 10 本に分かれる → queue に流す → ランチ」というフローが自然につながっています。人間がいちいち考えんでええねん。

実行中は Issue に in-progress ラベルが付く

実行中の Issue には自動で in-progress ラベルが付きます。 GitHub を開けば「今どれを処理しているか」が一目でわかる。複数の Issue が並んでいるときに、どこまで進んでいるかを追いかける手間が省けます。

fullrun との違い、伝わりますか

「fullrun があれば十分じゃない？」と思うかもしれないので、もう少し説明します。

fullrun は「1 つの Issue を処理する」コマンドです。 queue がないと、 1 つ終わるたびに自分が次の Issue を指定して fullrun を実行しなければならない。終わったのを確認して、次を実行して、また確認して……これが地味にめんどくさいねん。

queue があると、最初に並べさえすれば、あとは全部連続して流れる。10 本積んだら 10 本連続で走る。人間が介在するタイミングがほぼなくなるというのが、体験として全然違います。

AI コーディングの話で「社長になって全部任せた」と書きましたが、 queue は「社長が月次で方針を決めたら、あとは現場が全部動く」に進化した感じです。

使いすぎて 5 時間リミットに引っかかった

queue で一気に回していたら、 Sonnet だけで 5 時間リミットに引っかかりました。嬉しい悲鳴というか、使いすぎやん、という問題です。

queue で何本も連続実行するということは、それだけ AI の稼働時間も増えるということで。気づいたら制限に到達していました。「上限を意識しながら積む本数を調整する」という本末転倒な作業が生まれかけましたが（笑）、そっちじゃないなと。というわけで、プロンプトを調整してトークン使用量を抑える方向で対応しました。無駄な出力を削り、余計な確認をなくして、 AI が使うトークンを必要最小限にする。今は以前よりずっと気にならなくなっています。

土日も基本ずっと自動化と効率化のことを考えているんですが、これはもう完全に習性ですね。普通やんな？

今回の更新、それ以外の話

queue がメインなんですが、他にも色々入っています。ざっと紹介します。

特に Windows 対応は、実際に kit を使ってくれたレビューアさんから「動かない！」という報告をいただいて発覚したものです。ありがとうございます。

josh init を叩いたら ENOENT エラーで落ちる——原因は、 Windows の node_modules/.bin/tsx が Unix の sh スクリプトで直接実行できないというもの。 process.platform === 'win32' を判定して tsx.cmd を使うように修正しました。絶対そうなるやん！という当たり前のことを改めて痛感しました（Mac だけで開発していた人間の見落とし、言い訳）。

PR クローズ時に Issue が同時にクローズされないことがあった問題も修正しています。根本原因を辿ったら、 gh pr create を直接叩いたときに closes #N の参照が PR 本文に入らないケースがあった。なので今は josh git 経由でしか PR を作れないよう強制しています。 josh git は必ず closes #N を本文に含めるので、 Issue が確実に閉じる。「たまに動く」ではなく「必ず動く」。こういう揺らぎをゼロにしていく地味な作業が、長い目で見ると大事です。

.NET の頃から、ずっとやっていた

前回の記事の補足になりますが——「共通実装を共通ライブラリ化する」という発想、 .NET の頃からやっていました。

社内ライブラリを作って Web で公開して、協力会社さんに使ってもらっていた時期があって。懐かしい。

あの頃も「同じことを何度も書くのがめんどくさくて」ライブラリにまとめて配布していた。 .NET から TypeScript になって、社内配布から npm になって、チーム向けから全世界向けになっただけで、根っこにある動機は変わっていない。

「単純作業アレルギー」の話にも書きましたが、これが僕の原点なんだと思います。

これがプロダクトだった

前回の記事で「まだアプリを作っていないんだけど」と書いたんですが——最近、考え方が変わりました。

「プロダクトを作っていないな、早くやらなきゃ」と焦っていた時期がありました。でも、ふと思ったんです。

このパッケージ自体が、プロダクトやったんや。

使ってもらえている。バグを報告してもらえている。改善を続けている。これって、プロダクト開発そのものですよね。アプリじゃなきゃプロダクトじゃない、という思い込みがあっただけで、 npm パッケージだって開発者向けのプロダクトです。これでいい。これがプロダクト。 そう腹をくくったら、ちょっと楽になりました。

パソコンが普及したように。スマホが普及したように。 AI もサブスクでみんながお金を払う時代がやってくる。そのとき、僕が今やっていることが「特別なことではなく普通のこと」になる。それは寂しいかというと——むしろ楽しみです。今こうして積み上げているものが、その時代の自分の実力につながる気がしているから。

そのプロダクトは、github.com/joshuafolkken/kit で全部オープンにしています。コーディング規約・テスト方針・リファクタリングルールから、 queue や fullrun の裏で動く TypeScript スクリプト、 GitHub Actions のワークフローまで。「こういう構造か」「ここはこうした方が良くない？」という視点でぜひ覗いてみてください。 Issue や PR、本当に歓迎です。

みなさんはどうしてる？

タスクを積んでほったらかし、という開発スタイル——みなさんはどこまで「任せる」ようにしていますか？

queue みたいな連続実行の仕組みや、 AI への仕様の渡し方、「介入するタイミング」の判断基準など、いろんなやり方があると思います。一緒に考えましょう！

ボツタイトル供養

• ランチに行ったら実装が終わっていた。 queue コマンドで変わった開発リズム
• kickoff で 10 本、 queue で全自動。パソコンから離れていい開発スタイルになった話
• 「積んで離れる」という選択。 @joshuafolkken/kit の queue コマンドとその仕組み
• 1〜2 時間ほったらかしにできる。 queue による連続 fullrun の話
• 前回から 56 回更新した。でも今回の目玉は queue コマンド一択
• Sonnet だけで 5 時間リミット。 queue を使いすぎた話と、 kit v0.112.0 の近況
• AI に 10 本のタスクを積んで、ランチを食べに行く生活が始まった