まずは「全部自動化」ではなく、依頼の入口を作る
今いちばん困るのは、ChatworkやSlackに依頼が散らばり、どれが開発対応で、どれが数字確認で、どれが人間確認なのかが混ざることです。
だから最初のループは、作業を勝手に完了するよりも、依頼を受け取り、分類し、必要な場所に渡すところから始めます。
Codexは司令室、Claudeは作業員として分ける
Codex側は、チャット監視、分類、通知、状態確認に向いています。 一方で、調査や修正のように時間がかかる作業は、Claude Codeのworkerへ渡した方が分けやすいです。
この分担にすると、Codexは入口で詰まらず、Claude workerは自分の担当だけに集中できます。
Chatwork / Slack
エラー文、スクショ、不具合相談、数字確認が届く場所。
Codex
読む、分類する、危険度を見る、workerへ渡す、最後に小澤さんへ知らせる。
Claude Code
調査、再現、軽微修正、テスト、PR用の説明づくりを担当する。
.ops
依頼、状態、判断、作業ログを残す場所。あとから追えることを優先します。
agmsg
CodexとClaude workerの伝言。重い状態管理ではなく、作業依頼や完了通知に使います。
.ops は記録、agmsg は伝言。役割を混ぜない。人間確認を残す場所を先に決める
依頼捌きループで怖いのは、勝手にマージ、デプロイ、広告停止、入稿まで進むことです。 ここは最初から自動化の外側に置きます。
自動で進めるのは、調査、再現、軽微修正、テスト、説明資料づくりまで。 最後の意思決定は小澤さんが見てOKを出す形にします。
読む
依頼内容、スクショ、エラー文、関連repoを確認する。
直す
再現、原因特定、軽微修正、テストまで進める。
確認
PR説明、差分、再発防止を小澤さんへ渡す。
本文と画像の担当を固定する
すぅさん型に寄せるなら、画像は「全部説明する場所」ではありません。 画像はあくまで、本文で読んだことを一枚で掴ませる場所です。
理由と判断基準を書く
なぜこの仕組みが必要か、どこまで自動で良いか、危ない操作は何かを説明します。
流れと関係性を見せる
5秒で見て分かるように、短いラベル、カード、矢印だけで構成します。
| 項目 | さっきの版 | 作り直し版 |
|---|---|---|
| 主役 | システム構成と運用判断 | 読んで理解する流れと図解 |
| 構成 | 結論、KPI、比較、手順に近い | 本文、図、本文、図の説明記事型 |
| 画像 | 1枚の大きな関係図 | 章ごとの短い横長図 |
| 向いている場面 | 方針を素早く確認したい時 | 初見の人に仕組みを伝えたい時 |
2つの見え方
どちらが正解というより、用途が違います。 仕組みを決める時はさっきの版、誰かに共有して理解してもらう時はこの版が合います。
