AI agentworkのworkflowを構築 してみた。そしてFable 5 

根本的にやりたかったこと - 実装の自動化 - レビューの自動化 

前提 - Agent同士での通信のためにtmuxを使用（CodexでもClaude Codeでも双方向に画面をキャプチャできる） - ~/dotfiles/skills をローカル環境に用意し、シンボリックリンクで下記に配置することでCodexとClaude Code両方で同じskills を使用できるようにしている - ~/.agents/skills - ~/.claude/skills 

v0.1 – 自分がAIの子守役としてpromptを投げ続ける - GitHub issuesでPBIの設計 - タスク分解（Agentを使用） - Agentにタスクを読んでもらう - Agentが他のAgentに実装をお願いするようタスクを依頼（tmux上で） - 監視、終わったかチェック - 終わったら review-diff skillを起動して、3つのAgentがそれぞれの観点でdiffをチェック、.mdに吐き出し - 監視、終わったかチェック - 終わったら結果を見て、問題ありそうだったら実装agentに再依頼、問題なかったらPR作成 - PR上でgeminiがコメントを残したらPM用agentに再依頼 

手動でやるのめちゃくちゃ面倒臭い 

手動でやるのめちゃくちゃ面倒臭い 

v0.2 – workflowの自動化 やりたいこと - issueのlabelをstatus:readyにすると自動的に実装が開始される - reviewがあらかた終わった状態で PRがマージ可能な状態になる 

v0.2 – workflowの自動化 

v0.2 – workflowの自動化 - Launcher（5分ごとに起動） - status:readyのissueを選ぶ - status:in_progressに変更 - tmuxを起動し、PMにpromptを送信して作業を開始する - DBを更新する - PM (Agent) - Lancherから指示を受け取り、実装担当Agentに作業を依頼。実装が終了したらreview依頼。reviewが終わったらPR 作成してDB更新。 - PR watcher（5分ごとに起動） - DBとPRを監視し、レビューコメントがついた場合に対処できるようにPM用のAgentに送信する - Watchdog（1分ごとに起動） - PMが固まっていないか監視する 

Insight - いかにAgent同士のStateを管理するかが今後の肝になりそう？ ○ 作業が終わったら誰がStateを更新するか ■ 今回の運用では、LauncherやPM (Agent)、PR watcher、WatchdogがDBを更新する運用 ■ DBだけをソースとするのではなく、実際にGitHubやtmuxを見に行く運用 ○ Stateは何で管理するか（適切な論文がなく、yamlの管理は上書きされる懸念があったためPostgreSQLを今回は採 用した） - workflowは必ずしも抽象化できない（組織によって微妙に仕事の進め方や粒度が異なるが、workflowはそれらに強く紐づい ているので、組織の考え方によってカスタマイズが必要） - 実際一度作ってみると側で見守る必要がなくなったので、結構楽ちん。今のところ、途中で失敗して進捗がわからなくなったと いうことがない。 - 役割は明確にしておくこと。PM担当、実装担当、ある1つのレビュー観点担当という形で分けることで、自己正当化バイアスを 極力避けることができる。 - 受け入れ条件の明確化は必須。ここがブレると徒労に終わる ○ 1問1答形式でAgentに質問してもらうと、受け入れ条件を固められて良い 

そしてFable 5 Fable 5がリリースされ、元々作っていた webアプリケーションのリプレイスが3日 程度で70%ぐらい進んだ。 Fable 5は自律して実行できる時間が長 く（1時間弱とか）、タスクを細かく切って issueごとに進めること自体がボトルネッ クかも？？みたいな感じもした ここはworkflow使ってない 

そしてv0.3へ - 怒涛のように現れ、そして消えてしまったFable 5 - Fable 5を使用している間はworkflowはほぼ使用していなかったが、消えてしまった今は保険になる - 長時間自律的に稼働できることを間近で見て、sub-issueで細かく切りすぎずに、phaseごとにまとめて実行させるようにすれ ば実装時間が短縮できる気配。実際これを実装して、30-40分程度は途切れずに稼働できる状態になった