reviewtask 開発で得たバイブコーディングの気づき

reviewtask という OSS をバイブコーディング開発した時に得た知見の話です。
今では既に認知されているエージェントハーネスや、スキルの配布、エージェントハーネスをツール側に持たせるなど、どんな環境でもある程度の精度を出せるようにした工夫の話などをしています。

Transcript

1. C O N N P A S S · 2 0 2 6 0 0 1 / C O V E R 速く書ける時代に、 レビューとエージェントをどう制御するか。 東川 諒央 勉強会 reviewtask 開発で 得た バイブコーディング の気づき S P E A K E R S E S S I O N V E N U E
2. 東川 諒央 / Ryo Higasigawa x.com/biwakonbu x.com/ryo_vibecoding github.com/biwakonbu 自己紹介 S P E A K E R 東川 諒央 / Ryo Higasigawa 株式会社coroutine 代表取締役 技術顧問・AI 伴走 / フルスタック / 大学講 師 AI 開発と Vibe Coding の実践を発信 C O M P A N Y coroutine AI 開発・ウェブ開発の技術パートナー 技術顧問・AI 伴走支援 AI 開発ツールを用いた開発実務支援 M E D I A note Ryo Higasigawa｜AI 開発 × Vibe Coding ツール・ワークフロー・失敗事例を体系化。 P R O M P T 2025/07 の話題 t_wada 降霊術で AI に PR レビューしてもらう 実験。 0 0 2 東川諒央 — C O R O U T I N E V I B E C O D I N G · / 0 1 4
3. T E R M reviewtask とは T O O L PR レビューを task にする CLI GitHub Reviews / CodeRabbit / Codex を取得 AI で actionable task に変換 .pr-review/ に reviews / tasks / config を保存 ` ` P R I N C I P L E 大事にしたもの 指摘を取りこぼさない 再実行しても状態を壊さない AI に任せるが、 人間が判断を残す reviewtask workflow reviewtask # fetch + analyze reviewtask show # next task reviewtask start <task-id> reviewtask done <task-id> 0 0 3 東川諒央 — C O R O U T I N E V I B E C O D I N G · / 0 1 4
4. 構造: reviewtask の仕組み 0 0 4 東川諒央 — C O R O U T I N E V I B E C O D I N G · / 0 1 4
5. 実行時: エージェントはどう動くか 0 0 5 東川諒央 — C O R O U T I N E V I B E C O D I N G · / 0 1 4
6. 設計: CLI を外部 harness にする 0 0 6 東川諒央 — C O R O U T I N E V I B E C O D I N G · / 0 1 4
7. 2025/08 に起きていたこと 0 1 エージェント側の未熟さ GitHub コメントをう まく取得できない 解決済みスレッドを 閉じきれない 同じ指摘が再 task 化される 0 2 gh 直読みの限界 gh 出力を直接読ま せる運用 レビュー量が増える と読み込みに失敗 取得成功までの時間 が伸びる ` ` 0 3 レビュー側の量とノイズ 50 件超のレビューが 付く 対応すべきものと不 要なものが混ざる ひとつずつ読むと数 時間かかる C A U T I O N 当時の課題感 バイブコーディングで速く実装できるほど、 レビューの取得、 分類、 完走制御が人間とエージェントの手元 に滞留する。 0 0 7 東川諒央 — C O R O U T I N E V I B E C O D I N G · / 0 1 4
8. ロングランで壊れる制御入力 C A U T I O N 戦っていた問題 制御情報が会話コンテキストにしかないと、 長時間実行と compaction で直前の観察・判断理由・次の操 作が失われる。 0 0 8 東川諒央 — C O R O U T I N E V I B E C O D I N G · / 0 1 4
9. 開発中の工夫 — 状態を外へ出す 0 1 入力 GitHub Reviews / CodeRabbit の指摘を、 毎 回読み直す対象ではなく task source にす る。 0 2 状態 .pr-review/ に reviews / tasks / status を置き、 会話コンテキストから切り離す。 0 3 次の操作 show / start / done で、 エージェント に渡す作業単位を小さく保つ。 0 4 完了条件 検証、 commit、 thread resolve、 next task ま でを workflow として固定する。 T I P 設計の狙い compaction されても、 何を見て、 どう判断し、 どこまで閉じたかがファイルに残る。 0 0 9 東川諒央 — C O R O U T I N E V I B E C O D I N G · / 0 1 4
10. 気づき 1 — レビュー処理が次のボトルネック 0 1 速度差が出る バイブコーディングで実装 速度が上がるほど、 人間の レビューは追いつかず、 おざ なりになる。 0 2 レビューを育てる CodeRabbit などのレビュ ーツールを採用し、 他の AI レビューも併用して指摘の 確度を上げる。 0 3 次の詰まり 数千行級の PR に 50 件超 のレビューが付き、 今度は レビュー取得・調査・完走 が難しくなる。 C A U T I O N ボトルネックの移動 書く速度の問題ではなく、 レビューを正しく集め、 調査し、 最後まで閉じる workflow が問題になる。 0 1 0 東川諒央 — C O R O U T I N E V I B E C O D I N G · / 0 1 4
11. 気づき 2 — レビューは正解ではなく候補 0 1 AI も人間も外れる レビューは完璧な判定ではない。 誤読、 過剰 指摘、 スコープ外の提案は普通に混ざる。 0 2 外れを恐れすぎない 確度の高いことしか言えないレビューは、 見 落とし候補を出せず信頼度が下がる。 0 3 受け手が検証する 指摘をそのまま直すのではなく、 妥当性を確 認して対応する task を決める。 0 4 対応結果を残す 対応したものは commit に残し、 対応しない ものは理由を PR コメントに残す。 T I P レビューの使い方 多少外れても候補を広く出してもらい、 受け取った側が検証、 分類、 記録して workflow に乗せる。 0 1 1 東川諒央 — C O R O U T I N E V I B E C O D I N G · / 0 1 4
12. reviewtask は実は agent harness だった 2 0 2 5 / 0 8 当時使っていた制御入力 custom instructions custom slash commands workflow template Agent Skills 的な仕組み ` ` ` ` ` ` H A R N E S S CLI が担っていた制御 次に触る task を提示する 状態を更新して作業を進める 検証・commit・resolve まで誘導する 任意の操作を連続実行させる 言語化できていなかった設計 当時は harness という言葉は流行っておらず、 自分も言語化できていなかった。 ただ、 `reviewtask` はエ ージェントハーネスの概念を組み込んだ CLI ツールだった。 Q U O T E 0 1 2 東川諒央 — C O R O U T I N E V I B E C O D I N G · / 0 1 4
13. T E R M CLI の state machine で制御する S T A T E ツール側に状態機械を置く task の状態を持つ 次の instruction を返す verify 後に次状態へ進める A C T I O N エージェント側は指示に従う 指示された task を処理する 結果を CLI に返す 次の instruction を受け取る tool-driven agent control show -> instruction -> agent action -> done -> verify/update -> next T I P 今回の学び 使用する CLI に状態機械を持たせ、 ツールから指示を返す方法でもエージェントを制御できる。 0 1 3 東川諒央 — C O R O U T I N E V I B E C O D I N G · / 0 1 4
14. まとめ 0 1 4 東川諒央 — C O R O U T I N E V I B E C O D I N G · / 0 1 4