BisectBundle

誰のための案か

オープンソースの保守担当と小さな開発組。現状は GitHub・GitLab の課題に記録を貼るか、CI の成果物をメールで送るか、再現のための仮想マシンの丸ごとの複製を求めて凌いでいる(代わりは手作業の課題と長いやりとり)

どんな困りごとか

時間と注意の損失。振り分けとやりとりで技術者の時間を食い(不安定なバグ 1 件で 3〜20 時間になることも多い)、リリースが遅れる。仮想マシンの丸ごとの複製や機密の記録を共有しなければならないときは、法務や基盤の面の痛みにもなる

どう作るか

圧縮した一式を作る小さな CLI(git のプラグイン)と、任意で 1 ファイルの Web の閲覧画面へのアップロード(常駐でも自前でも)。閲覧画面は失敗するテスト、正確な git の範囲、1 回の操作の再現スクリプト、再生できる CI のジョブの YAML の断片を見せる

どう稼ぐか

払うのは小さな開発組とオープンソースの保守担当(組織経由)。価格は、常駐の一式の保管と非公開の閲覧画面で保守担当 1 席あたり月 $10〜30、または自前設置でリポジトリ 1 つあたり年 $150。払う理由は技術者の時間が浮きリリースが速くなるから。無料の選択肢が使えないのは、圧縮した記録や添付には動く固定された再現スクリプトが入っておらず、環境を手で組み直す必要があるから。この製品は、無料の添付に無い、再現できる実行スクリプトと CI の断片をまとめる

なぜまだ無いのか

既存勢は作らない。多くの言語と CI の組み合わせで動く、安全で最小の再現の一式を組むには、慎重な囲いと言語ごとの仕組みが要り、製品への重い投資になるからだ。保守担当は代わりに散らかった添付を受け入れている。個人なら、よくある場合(よく使われる実行環境と Docker ベースの CI での単体テスト・CI の不安定さ)に絞り、言語を足していける小さな仕組みで、仮想マシンを丸ごと動かさずに決まった一式を作って隙間を埋められる

最初の利用者

最初の 10 人は、人気のオープンソースのリポジトリの保守担当と小さな基盤の組。すぐに元が取れ(振り分けの往復が止まる)、GitHub・GitLab で見つけてもらいやすく、有料の保守の時間を節約して課題の質が上がるので採用する(課題に「再現の一式」を見せられる)

作る規模

2 人 × 10 週(裏側と画面の開発者 1 人と、多言語のシステムの技術者 1 人)。記録とリポジトリの状態を集める CLI、Node・Python・Go・Java の実行の仕組み(Docker の囲いでテストを走らせる)、一式の形式、小さな常駐の閲覧画面とアップロードの API、CI の断片の生成を含む。大きな仮想マシンの複製への対応、独自の企業の SSO の連携、Windows 専用の仮想マシンの再現は除外

一番のリスク

大手の CI の事業者か GitHub・GitLab が、自前の「最小の再現を作る」道具か、ネイティブの「再現の一式」の成果物の形式と無料の閲覧画面を足せば、常駐の収益と任意のアップロードの価値が崩れる

的中の条件(3 つすべて必要)

• 一式の生成: (a) 固定したコミットのハッシュと使った git の範囲、(b) 最小にした失敗するテストのファイルと、CI に似たイメージの Docker の中で 120 秒以内に失敗を再現する 100 行未満の再現スクリプト、(c) そのジョブを再現する ci.yml の断片を含む 1 つの .bbundle.zip を出す。落としてスクリプトを走らせ、手元で失敗を再現すれば確かめられる
• 常駐の閲覧画面: 上げた一式の URL を渡すと、Web の画面が (1) 失敗するテストの出力、(2) 再現に要る正確な差分、(3) スクリプトを再生して 3 分以内に終了コードを返す 1 回の操作の「遠隔の囲いで走らせる」ボタンを描く
• 一式の最小化: 失敗するテストとリポジトリを渡すと、最小にしたチェックアウト(ソースは最大 5MB、直接の依存は固定してキャッシュ)と、最初の実行で同じ失敗の終了コードを出す再現できる Dockerfile を作る。大きさと再現性は、知らない人が 6 か月以内に試せる

的中の判定(6ヶ月後)

GitHub の公開リポジトリが 1,000 スターに達するか、Product Hunt の日間 5 位以内での公開で、常駐の閲覧画面への登録が 200 組織以上(判定日 2027-03-29)

AI自己確度 55/100 — 判定条件を満たす見込みの自己申告で、事業の成功率ではありません