Loop 親子関係の全体像

まずはこの絵だけでOK。親が拾って、子が動き、状態は .ops に残します。

親は「全部やるAI」ではない

`iraisabaki` は、ChatworkやSlackを見て、対応が必要そうな投稿を拾います。そこから「これは不具合」「これは記事改善」「これは画像広告」「これは人間判断」と分けます。

重要なのは、親が重い作業を抱えすぎないことです。親は 受付・分類・記録・通知 に集中して、専門作業は子workerに渡します。

Chatwork、Slack、手入力の相談が入ってくる場所です。

どのworkerに渡すかを決める司令室です。

不具合、記事、画像広告などの専門作業を進めます。

1件の依頼は、投稿 → 受付 → 分類 → 作業 → 承認の順で流れます。

依頼を拾う、分類する、タスクに残す、調査案を作る。ここまでは自動で進めてもリスクが低いです。

逆に、PRマージ、本番反映、Chatwork本部屋への返信、入稿、予算変更は止めます。ここは 小澤さんのOKが出てから 進める場所です。

段階	自動でよいこと	止めること	理由
受付	Toやmentionを拾う、候補を抽出する	本部屋へ即返信する	誤検知時にチームへ変な返信が飛ぶのを防ぐため。
分類	不具合、記事、画像、運用、質問に分ける	曖昧な相談を勝手に作業開始する	仕事の種類を間違えると、別workerが無駄に動くため。
作業	調査、改善案、軽微な検証、Brief作成	本番反映、マージ、入稿、予算変更	影響範囲が大きい操作は人間承認が必要なため。
報告	My ChatやMac通知で小澤さんに知らせる	チームへ確定回答を送る	最終文面や説明の温度感は確認した方が安全なため。

loop名は「業務の回り方」、worker名は「実際に動く係」です。

`article-first-view-improvement` は、記事LPのファーストビュー改善をどう回すかという loop名 です。数字を見る、改善対象を選ぶ、改善案を出す、承認後に更新する、という業務の流れを指します。

`kizi-worker` は、そのloopの中で実際に動く 作業係 です。記事の数字を見て、どのFVをなぜ変えるか、改善案としてまとめます。

業務テーマ	loop名	worker名	親から渡す条件	最初のゴール
不具合対応	`team-error-to-fix`	`fuguai-worker`	WebUI、CLI、ETL、Cloud Run、repo系の不具合。	調査、軽微修正、テスト、PR説明まで。マージは承認後。
記事FV改善	`article-first-view-improvement`	`kizi-worker`	記事LPの数値悪化、FV離脱、MCVR低下、改善依頼。	どの記事のどのFVを、なぜ変えるかを改善案にする。
静止画広告	`owned-static-ad-generation`	`gazou-worker`	自社運用の画像広告で、次の訴求や冒頭案が必要な時。	訴求案、画像生成プロンプト、規制チェック、確認用まとめ。

親がまだ安定していない状態で子workerを増やしすぎると、入口が散らばります。なので、まず親の受付精度を固めてから、記事と画像のworkerを別セッションで作るのがよさそうです。

Chatwork / Slackを拾い、分類し、Briefする親ループを安定させます。

記事FV改善の候補を作るworkerです。別ワークツリー向きです。

静止画広告の訴求案、画像案、規制チェックを進めるworkerです。

`loop` は業務の循環、`worker` はその循環の中で動く担当者です。 `iraisabaki` は親として入口をまとめ、`kizi-worker` や `gazou-worker` は親から渡された1件だけを処理します。