誤ったリリースを公開前に止めた2時間
2026年8月11日、VibeProの作業スレッドに記録されたタイムラインでは、0.2.0-beta.6の公開依頼からnpm公開とGitHub Releaseの確認完了まで2時間11分44秒かかりました。時間の大半を使ったのはnpmへの公開処理ではありません。公開前に見つかったGitHub Releaseの分類不具合を直し、その修正案に残っていた別の回帰リスクを、同じ作業を担当したエージェントとは別のレビューセッションで解消する作業でした。
確認できた事実
最初の修正はPR #450として日本時間19時12分にマージされました。その後、beta.6を通常版や「最新版」として公開する可能性があるGitHub Releaseの処理が公開経路に残っていることを確認し、公開を止めました。
PR #451では、beta.6の新規公開と今後処理するプレリリースをprerelease=true、latest=falseへ収束させました。作成時と更新時に同じ判定を使い、操作後のタグ、コミット、Releaseの状態が期待値と違えば失敗させる変更です。
過去のbeta.1からbeta.5の再分類は、この変更の対象外です。このページを作成した時点でも、それらはGitHub上で通常Releaseとして分類されたままです。
最初の修正案には、古い安定版を再実行したとき、より新しい安定版から「最新版」を奪う可能性が残っていました。別のレビューセッションでの指摘後、現在の最新版と公開対象のバージョンを比較し、古い安定版が最新版にならない条件までテストしました。PR #451のマージは日本時間20時48分でした。
PR #452で0.2.0-beta.6の公開準備をマージした後、公開ワークフローは成功しました。ワークフロー全体は約2分41秒、そのうちnpm公開とGitHub Releaseの収束処理は約29秒でした。
VibeProが寄与した範囲
VibeProが不具合を単独で自動検出したわけではありません。問題を見つけたのは、公開作業を進めたエージェントとレビューです。
VibeProが担ったのは、Story、Spec、検証、レビュー、PRの証跡を同じリポジトリに残し、公開前に止めた理由と修正後の確認項目を追える状態にすることでした。最初の修正案をそのまま公開せず、別の回帰条件まで確認できたことが、この事例で観測できた寄与です。
この事例から言えること
この一例だけで、不具合削減率や開発速度の一般的な効果は算出できません。確認できるのは、短い公開処理の前に判断と検証の時間を取り、誤ったRelease分類を利用者へ届けずに済んだことです。
VibeProは、AIエージェントを速く動かすだけの道具ではありません。変更の目的、実装、検証、レビューをつなぎ、公開してよいかを人とエージェントが判断できる材料を残すための作業基盤です。