最初に見る全体図
左から右へ進むほど自動化が深くなります。 いまは「受付ルーター」と「不具合検知の部品」ができていて、worker実行と承認後の返信はこれからです。
1. 入口を拾う
- 試作済みChatwork複数部屋を読む
- 試作済みSlack MCP入力を同じ形に揃える
- できたTo / 佐川 / 小澤 宛を候補にする
2. 捌いて記録する
- できたカテゴリ分類をする
- できたJSONLのタスクに残す
- 試作済みMy ChatにBriefを送る
3. workerへ渡す
- 次不具合系だけ
team-error-to-fixへ渡す - 次
.opsに状態を残す - 別WSClaude worker / agmsg 連携を作る
いまの現在地
仕様、プロトタイプ、テスト、Automation登録までは進んでいます。 ただし、定期監視は PAUSED なので、まだ「裏で勝手に動いている」状態ではありません。
親ループはある
inbox-to-action がChatwork / Slackの入口をまとめる親ループです。
不具合子ループもある
team-error-to-fix がWebUI / CLI / ETL / Cloud Run系を扱います。
テストは通過済み
Router、monitor、reply package のテストは前回 50件通過 しています。
登録はあるが停止中
Automationは15分間隔で登録されていますが、現在は両方 PAUSED です。
実際の処理フロー
ここで大事なのは、ChatworkやSlackをClaude workerに直接読ませすぎないことです。 Codex側で軽く絞って、必要な1件だけ worker に渡す形にします。
outputs/inbox-to-action/tasks
team-error-to-fix に渡す
できていること / まだできていないこと
「作った」と言える範囲は、受付・分類・タスク化・Briefの試作です。 「完全なloop」と言うには、定期稼働、worker実行、承認後フローが残っています。
| 領域 | 状態 | できていること | まだ必要なこと | 進める場所 |
|---|---|---|---|---|
| iraisabaki | 試作済み | Chatwork / Slackを同じ受付ループにまとめる設計と実装があります。 | 実データでのdry-run、誤検知調整、稼働ON判断が必要です。 | このワークツリー |
| Chatwork監視 | 試作済み | 複数部屋、To判定、My Chat Brief の道筋があります。 | どの部屋を常時監視するか、通知の粒度を決めます。 | このワークツリー |
| Slack MCP | 次 | MCP結果を受け取る ingest があります。 | 実際に読むchannel候補、mention判定、thread扱いを詰めます。 | このワークツリー |
| Codex Automation | 停止中 | inbox-to-action-router と team-error-to-fix-watcher が15分間隔で登録されています。 |
いまはPAUSEDです。ONにする前にdry-run結果を確認します。 | このワークツリー |
| team-error-to-fix | 試作済み | 不具合っぽい投稿の検知と、解決報告パッケージ作成があります。 | 調査・修正・PR作成を自動で走らせるworkerが未実装です。 | 別ワークツリー推奨 |
| .ops / agmsg | 設計中 | 役割分担の方針は決まっています。 | タスク状態のschemaと、CodexからClaude workerへ渡す契約が必要です。 | 別ワークツリー推奨 |
| 記事FV改善 | 別WS | 候補としては明確です。 | MCVR / FV離脱率 / Beyond API 更新範囲を別設計にします。 | 別セッション |
| 自社静止画広告 | 別WS | 数字確認から画像案生成までのloop候補があります。 | 案件別の規制、画像生成、入稿前承認を分けて設計します。 | 別セッション |
| 制作司令室 | 後で | 日次判断、台本、動画依頼、入稿までの構想があります。 | 人間の判断点が多いので、小さいloopに分解します。 | 別セッション |
どこを別ワークツリーにするか
同じファイルを触りやすいものは分けすぎない。 逆に、worker実装や記事改善のように大きくコードが動くものは別ワークツリーにします。
iraisabakiのMVP。Chatwork / Slackを拾って、分類し、タスク化し、小澤さんへBriefするところまでを固めます。
最優先fuguai worker。原因調査、軽微修正、テスト、PR作成、承認待ちまでを作ります。
開発workerkiji worker。記事FVの数値確認、改善案、Beyond APIでの更新候補作成を扱います。
記事改善cr worker。自社運用の静止画広告で、数字確認、訴求案、画像生成、規制チェックまでを扱います。
広告制作daily-creative-command-center は大きいので、数字判断、台本化、動画依頼、入稿判断に分けてから作ります。
まだ重い分け方のルール
受付だけは一箇所に寄せます。 ChatworkとSlackを別々に賢くしすぎると、同じ依頼が二重にタスク化されやすいからです。
逆に、repo修正や記事更新、広告画像生成はそれぞれ触るファイルとリスクが違います。 ここは別ワークツリーで走らせた方が、衝突しても戻しやすいです。
次にやること
次は「便利そう」よりも「安全に回る」を優先します。 いきなり全自動返信ではなく、まずは拾って、分類して、小澤さんに短く知らせるところまでです。
-
1. Chatwork / Slackのdry-runをもう一度見る
直近の投稿で、拾うべき依頼と無視すべき雑談が分けられるか確認します。
-
2. AutomationをONにするか決める
登録済みの
inbox-to-action-routerは15分間隔です。まずは受付だけONがよさそうです。 -
3. .opsとagmsgの最小契約を作る
workerに渡す内容、状態、完了報告の形だけ決めます。ここを決めるとClaude workerに渡せます。
-
4. fuguai workerを別ワークツリーで作る
不具合の調査、軽微修正、テスト、PR作成、承認待ちまでを作ります。
残っているloop候補
今は全部を一気に作らない方がよいです。 受付ループを先に安定させてから、下のworkerを足していく形がきれいです。
iraisabaki
Chatwork / Slackの依頼受付、分類、タスク化、Brief通知。まずここを本丸にします。
fuguai worker
WebUI / CLI / ETL / Cloud Runなどの不具合対応。PR前で止める形が安全です。
kiji / cr worker
記事FV改善と自社静止画広告。数字を見るので、広告運用ルールと承認点を別に設計します。