English はじめる

チケットを渡す。
朝には、プルリクエスト。

Haiyo は、チケットごとに計画、失敗するテスト、実装、レビュー、検証までを進めます。隔離された git worktree で、並列に、あなたが席を外している間に。戻ってくるのは、根拠がそろったドラフトPRです。

はじめる 1件のランを追う
サンプルデータによるイラスト — アプリの画面ではありません スクロールして1件のチケットを追う ↓
01 — 1つのラン

1枚のチケットを、最初から最後まで。

00

チケット

ラン

storefront ワークスペース

⑂ main

ログインAPIにレート制限を追加

⑂ agent/add-rate-limiting-to-the-login-endpoint
待機中
0%
待機中
計画
テストを書く
実装
検証
出荷
チケット待ち…
受け入れ条件
60秒以内の6回目のログイン試行で 429 を返す
時間枠が過ぎるとカウンターがリセットされる
他のルートには影響しない
systemIdle — waiting for a run
変更ファイル 3件
rateLimit.tssrc/server/middleware · +14
auth.tssrc/server/routes · +2 −1
rate-limit.test.tstests/api · +42
src/server/middleware/rateLimit.ts
アプリの実際の画面をもとに作成 · サンプルデータ · 時間は短縮 再生中 スクロールで進む ↓
02 — フリート

チャットではなく、バックログのために。

ランに張り付く必要はありません。仕事をキューに入れて離れ、戻ったときには目を通す価値のあるPRだけが短いリストになっています。以下はアプリの3つのパネルの再生です。

実行できるチケットは並列上限まで自動で起動します。優先度の高い順、同じなら古い順。依存先のあるチケットは待機し、依存先が終わるとその計画とPRを文脈として引き継いで始まります。

  • ランごとに専用の git worktree とブランチ。並列でもぶつかりません。
  • 「すべて実行」で依存グラフ全体を順に処理。循環する依存はリンクの時点で拒否されます。
  • 途中でアプリを閉じても、最後に完了したステージから再開します。

完了したランはプロジェクトをまたいで1つのキューに集まり、あなたの判断が必要なものほど上に並びます。各行に影響範囲、条件の達成数、信頼度。ワンクリックで承認するか、言葉で修正を依頼すれば同じPRが更新されます。

  • リスクは実際の差分から算出します。ファイル数、変更量、認証・決済・マイグレーション・CIへの影響。
  • 修正依頼は再実装・再検証され、同じドラフトPRに push されます。

タスクごとのトークン上限と金額上限、フリート全体の1日の上限、沈黙したランを止める停止タイムアウトを設定できます。失敗は分類され、再試行・一時停止・保留へと振り分けられます。

  • 1日の上限に達しそうなら次のランを保留し、理由を伝えます。黙って使いすぎることはありません。
  • 1件がブロックされても、関係のないチケットは止まりません。
storefront ボード並列上限 3 · P0 優先
0/3 実行中すべて実行
バックログ 0
進行中 0
最終レビュー 0
完了 0
Inbox人の確認を待つ完了ラン
レビュー待ち 0件
Control tower推定コスト・上限・フリートの失敗
本日 0 件
Spend today
$0.00 of $12.00 cap
Failures by class
Flaky0retry
Missing credentials0held
Rate limited0resumes
Stuck · paused · held
次のランを保留 — 本日の上限に達する見込みです。「毎日の依存パッケージ更新」は、上限のリセット後か、上限を引き上げると開始します。
03 — ユースケース

こんな仕事を、任せられる。

8つの仕事。どれも、いまアプリに入っている機能で動きます。

01

夜のうちにバックログを片づける

退勤前に、範囲のはっきりしたチケットをキューへ。アプリは開いたまま、Mac はスリープさせずに。優先度順に並列で進み、朝は ToDo リストではなくドラフトPRから始まります。

10チケット → 3件ずつ → 9:00 に Inbox
02

Issue にラベルを貼るだけでPR

Issue の取り込みをオンにして、GitHub の Issue に autopilot ラベルを付けると、自動でタスクになります。ドラフトPRには Closes #N が入り、PRのリンクは Issue にも書き戻されます。Linear と Jira からの取り込みにも対応。

ラベル付け → タスク作成 → Issue にPRリンク
03

依存するステップで機能を出す

機能を互いに依存するタスクに分割。各タスクは上流の完了を待ち、その計画とPRを土台にして始まります。ゼロからやり直すことはありません。

API → UI → ドキュメント · すべて実行
04

仕様書をタスクグラフに

要件定義を貼り付けると、受け入れ条件と依存関係つきのタスクに分解され、依存の順に1つのバッチとして実行されます。

仕様書 → タスク + 条件 → 依存順に1バッチ
05

誰も直さない不安定なテストを直す

6回に1回落ちるテストを指定するだけ。再現し、原因を直し、テスト一式とブラウザE2Eが通ったときだけ出荷します。スクリーンショットつき。

失敗 → 原因特定 → 30回連続成功 → 証拠
06

メンテナンスを定期実行に

チケットにスケジュール（数時間ごと、または毎日決まった時刻）を設定すると、アプリが開いている間、自分で再キューされます。依存パッケージの更新、Lint の負債、テストの見直しに。

「毎日の依存パッケージ更新」 · 06:00
07

PRを言葉で直す

少し違う？ 直してほしいことを書くだけ。エージェントが再実装し、チェックを再実行し、同じドラフトPRを更新します。新しいブランチも、文脈の消失もありません。

「ステータスでも絞り込んで」 → 再実行 → 同じPRを更新
08

アイデアから、公開中の Web アプリへ

アイデアを言葉で書くだけで新しいプロジェクトを開始。スタックは1つに決め打ち（Vite + React、Hono on Cloudflare Workers）。マージ後にデプロイし、公開URLを確認します。

アイデア → 雛形 → PR → デプロイ → 公開確認
04 — 実行例

返ってくるもの。

4件の実行例。アプリの実際の形式によるドラフトPRが3件と、完了と認めなかった1件です。

サンプルデータです。ステータス行、リスクの理由、テスト計画、根拠つきの条件、信頼度つきのレビュー — この構成は、アプリがすべてのドラフトPRに書き込むものです。PR本文の見出しや定型部分はアプリが英語で生成し、チケットに関わる文章はチケットの言語で書かれます。

05 — 安全性

自律的に。ただし、下限は固い。

手放しで任せられることが核心です。安全は、毎回「承認」を押させることではなく、技術的な下限で担保します。

受け入れ条件

1つずつ、根拠つきで採点。

別のレビューが条件ごとに達成・未達を判定します。検証できない条件は未達として扱い、PRにブロッカーとして明記します。

信頼度

「高」は簡単には出ない。

条件が1つでも未達、またはレビュー不合格なら「低」。高リスクの差分や条件なしの場合は「中」が上限です。

隔離

ランごとに専用の worktree。

作業コピーにも他のランにも触れません。却下すればブランチは巻き戻ります。

予算

警告ではなく、止める上限。

タスクごとのトークン・金額の上限を設定すると、超えた時点でエージェントを途中停止します。1日の上限でキューを保留し、停止タイムアウトで沈黙したランを止めて理由を記録します。

破壊的な操作

必ず人の承認を待つ。

何かを削除するインフラ変更は、どの自律レベルでも承認待ちになり、設定で外すことはできません。ロールバックが自動で行われることはありません。

ローカル

あなたの Mac で動く。

作業は自分のリポジトリ内の git worktree で、既存の GitHub ログインのまま行われます。エージェントの環境からは不要な認証情報を取り除きます。

自律レベル

どこまで任せるかを選ぶ。

1つの設定で、マージ・デプロイ・インフラの挙動がまとめて切り替わります。個別のスイッチはその下で引き続き調整できます。

FLOORどのレベルでも、インフラの破壊的な変更はあなたの承認を待ちます。
06 — はじめる

チームメイトに渡すチケットを、そのまま。

ステップ 1

アプリをインストール

Apple シリコンと Intel の両方で動くユニバーサル版。初回セットアップがマシンを自動でチェックします。

ステップ 2

チェックを通す

  • Git必須
  • GitHub CLI（ログイン済み）必須
  • AIコーディングエージェント（サインイン済み）必須
  • プロジェクトのツールチェーン必須
  • Docker、Playwright任意
ステップ 3

プロジェクトを追加し、チケットを書く

フォルダを選ぶ、GitHub リポジトリをクローンする、またはアイデアから始める。Issue を取り込むかブリーフを書いて、TDDランを開始 を押します。

FAQ を読む 早期アクセス · macOS
07 — FAQ

よくある質問。

マージまでされますか？

完了したランは、根拠つきのドラフトPRで終わります。その先は自律レベル次第です。「すべて承認」ではあなたなしにマージされることはなく、「監督つき」は自動マージの判断を記録するだけ。「自律」は、信頼度が高くすべての条件を達成し、差分が低リスクでサイズの上限内、CI が実行されて合格し、変更ファイルがすべて自動マージを許可したカテゴリに入っているときだけマージします。初期状態ではどのカテゴリも許可されていないため、選ぶまではマージされません。

コードはどこに送られますか？

リポジトリはあなたの Mac に残ります。ランはその中の git worktree で動きます。AI モデルは担当するチケットに必要なコードを参照し、GitHub はブランチとドラフトPRを受け取ります。

テストのないプロジェクトでも使えますか？

使えます。実装の前に、テストのステージが実際のテストファイルをプロジェクトに書き込みます。実行していないテストを「成功」と表示することはありません。

ランが止まったり、失敗したりしたら？

停止タイムアウトを設定すれば沈黙したランはウォッチドッグが止め、上限を設定すれば使いすぎも止まります。失敗はすべて分類されます。不安定なテストは回数を限って再試行、認証情報の不足や曖昧なチケットはタスクを保留して必要なものを具体的に知らせ、レート制限は自動で一時停止・再開します。レビューで受け入れ条件をすべて確認できなかった場合は、PRを作る前に止まり、どの条件かを知らせます。

コードを書く前に計画を承認できますか？

できます。計画の後とPR作成の前に、2つの任意の関門を置けます。どちらで却下してもブランチは巻き戻ります。PRができた後は、言葉で修正を依頼すれば同じPRが更新されます。