Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Avatar for uuta uuta
July 15, 2026

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

Avatar for uuta

uuta

July 15, 2026

Other Decks in Technology

Transcript

  1. 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に再依頼
  2. 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が固まっていないか監視する
  3. Insight - いかにAgent同士のStateを管理するかが今後の肝になりそう? ◦ 作業が終わったら誰がStateを更新するか ▪ 今回の運用では、LauncherやPM (Agent)、PR watcher、WatchdogがDBを更新する運用 ▪

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