最近、Codexで同時に動かす仕事が増えた。
記事を書く。
公開後を確認する。
サイトを直す。
別の担当がレビューする。
会話の一覧を見れば、タスクの数は分かる。
ただ、「今、誰が何をしているか」「どの役割が待っているか」は、一覧を眺めても頭に入りにくかった。
そこで、自分の事業で使う28の役割を6部署へ置き、2.5Dのオフィスとして見えるようにした。
名前はTask Control Room Company。
Codexの公式機能ではなく、自分のローカル運用に合わせて作ったprivateな管理画面です。
この記事では、タスクを正本化した方法そのものではなく、その上に「AI会社」の画面を作った理由と、定期監視をやめるまでの失敗を、実画面と一緒に残します。
タスクの正本化については、先に書いたCodexを事業運用に使って分かった、AI時代のタスク管理へまとめています。
複数のCodexタスクは、一覧だけでは仕事の流れが見えなかった
Codexは、与えた文脈を読み、作業を進め、検証まで担えるコーディングエージェントです。
OpenAIの公式ガイドでも、単発の補助ではなく、設定して改善していくチームメイトのように扱う考え方が紹介されています。
ただし、複数のCodexタスクをどう部署へ分け、誰が作業中かをどう見せるかは、OpenAIの標準機能ではありません。
ここから先は、自分が実際の事業運用に合わせて作った仕組みです。
最初は、Codexのタスク名と最後の返答を見れば十分だと思っていた。
実際には、執筆担当が下書きを作り、プロデューサーが確認し、公開担当へ渡し、公開後は集計や告知へつながる。
仕事は一つの会話だけで閉じません。
一覧には、それぞれの会話が並ぶ。
でも、自分が知りたいのは会話の数ではなく、会社全体で何が動き、どこが待ちになり、どの役割へ次に渡るかでした。
28の役割を部署へ分け、AI会社として配置した
画面には、28の登録役割を置いています。
人数は同時稼働数ではありません。
記事、メディア運営、集計、発信、経理、開発など、仕事の入口を安定させるために登録している役割の総数です。
役割は、経営・管制部、モノえらび編集部、メディア編集部、集客・分析部、経理部、開発・基盤部の6部署へ分けた。
中央にはAI COREを置き、部署同士が別々の島にならないように線でつないでいます。
実画面の業務内容には未公開情報が混ざるため、スクリーンショットでは必要な箇所だけをぼかしています。
部署、席、状態、人数は実際の画面のままで、架空の社員や稼働状態へ置き換えてはいません。
2.5Dの机や人物を置いたのは、会社らしく見せるためだけではない。
部署の距離とまとまりを、文字の表より先に理解できるからです。
どの役割が孤立しているか。
どこに担当が集まりすぎているか。
集計と発信が実装部門から離れて見えるか。
画面を縮小したとき、役割設計そのものの違和感が見えるようになりました。
拡大すると、担当と現在の作業が見えてくる
全体画面は構造を見るためのものです。
一つの部署を選ぶと、表示倍率が上がり、席、PC、社員名、担当する役割が読めるようになります。
自分は、役割名だけではなく社員名も付けました。
「ライターA」よりも、「ルーペが書き、トープが確認する」と見えたほうが、受け渡しを覚えやすかったからです。
ここで大切なのは、名前を付けて人間のように扱いすぎないことでもあります。
画面上の社員は、責任や判断を持つ人間の代わりではない。
役割、使用モデル、依頼時に動くのか、誰と連携するのかを理解するためのinterfaceです。
以前、長くなったCodexタスクを新しいタスクへ移したときも、履歴を丸ごと複製するより、現在有効な役割と再開点を渡すほうが安定しました。
その考え方は、Codexの長期タスクを安全に移行する手順にもまとめています。
稼働中の社員は、光と作業内容で分かるようにした
状態は、working、waiting、idleを基本にしています。
稼働中の役割は席やモニターが光り、現在の短い作業名が吹き出しに出る。
画面上部の「現在稼働中」にも、freshな報告だけを並べます。
この画像では、通常作業の中で自然に2名がworkingを報告していました。
撮影のために別のタスクを起こしたり、状態を作ったりはしていません。
稼働中の人数は、成果量の点数ではない。
0名なら何も生まれていない、5名なら順調、という意味にはしません。
確認したいのは、今の役割分担と実際の動きが食い違っていないかです。
たとえば、記事公開を待っているのに執筆担当がworkingのままなら、報告の更新が漏れているかもしれない。
逆に、作業が終わった役割がidleへ戻れば、次の担当へ渡す時点が分かります。
社員詳細には、現在と直近の活動履歴を残す
社員を選ぶと、状態、現在、直近の結果、モデル、勤務形態、連携先が開きます。
その下には、開始、待機、完了といった直近の活動履歴を時刻と一緒に残しています。
公開画像では、内部の識別子、未公開の作業名、履歴の詳細をぼかしました。
実際の画面にも、会話本文、prompt、response、tool出力、認証情報は保存していません。
表示するのは、状態を判断するための短いmetadataだけです。
活動履歴があると、「今はidle」という一点だけでなく、その前に何を完了し、どの時点から待っているかを追えます。
一方で、履歴を監査ログの代わりにはしていません。
成果物の正しさは、記事、コード、公開HTML、検証記録など、それぞれの正本で確認します。
監視のためにAIを動かす設計は失敗だった
最初は、会社画面を新しく保つために、定期的な監視タスクを動かそうとしました。
各担当を巡回し、状態を集め、表示を更新すれば、いつでも最新の会社が見えると思ったのです。
ところが、観測のためのタスクが増えた。
新しい会話が作られ、同じ状態を確認するために文脈を読み、変化がなくてもtokenを使う。
仕事を進めるAIと、仕事を見張るAIが別々に動き始めました。
画面は新しく見える。
でも、その鮮度を保つためにタスク一覧が散らかる。
これは、タスク管理を整えるために別のタスク管理を増やしている状態でした。
特に困ったのは、「報告が新しい」と「実行中である」が同じではないことです。
監視側が直前の会話を見つけても、その処理が今も動いているとは限らない。
外から推測した表示をリアルタイム監視のように見せるのは、正確ではありませんでした。
状態変化時だけ報告するイベント駆動型へ変えた
そこで、専用のcron、heartbeat、polling、タスク巡回をやめました。
通常の仕事を担当する本人が、作業開始時にworking、確認や外部反映を待つときにwaiting、close時にidleを報告します。
同じ状態のままなら、定期更新しない。
意味のある状態変化が起きたときだけ、短いmetadataを送ります。
報告は6項目から始められます。
| field | meaning |
|---|---|
| agent | 安定した担当ID |
| department | 役割の所属 |
| state | working / waiting / idle |
| current | 現在の短い作業名 |
| recent | 直近の結果 |
| observedAt | 報告した時刻 |
実装の細部より先に、何を報告しないかも決めました。
認証値、会話全文、promptとresponse、transcript、SQLite本文は送らない。
画面に必要なのは仕事内容の要約であり、作業の中身を複製することではありません。
この画面はリアルタイム監視ではない
状態報告から70分を超えると、Company画面ではstaleとして「観測待ち」へ戻します。
古いworkingを、そのまま稼働中として見せ続けないためです。
これはOSのprocessや、modelの実行状態を直接監視しているわけではありません。
画面が示すのは、各担当が最後に報告した状態と、その鮮度です。
分かるのは、誰が何を担当し、最後にどんな状態を報告し、次の受け渡しがどこにあるか。
分からないのは、処理の内部進捗、回答品質、成果物の正しさ、いま何%まで終わったかです。
見えないものを推測して埋めない。
この境界を置いたことで、Company画面を安心して判断の入口に使えるようになりました。
AI会社は、複数のAIを運用し続けるためのinterfaceになった
AI会社らしい画面は、なくても仕事はできます。
状態だけなら表でも表示できる。
それでも自分は、部署、席、人物、光のある画面を残しました。
複数のCodexタスクを毎日扱うと、正確さだけではなく、見続けられることも大切になる。
会社全体を縮小して眺め、気になる部署へ寄り、社員の履歴を開く。
その流れが自然だと、状態確認を面倒な監視ではなく、短い運用判断として続けられます。
今回分かったのは、AIを増やすだけでは会社らしい運用にならないことでした。
役割を決め、状態を短く報告し、古い報告を古いと表示し、成果物の正本と分ける。
見た目は、その運用を理解しやすくする最後の層です。
AIエージェントの全体像を初めて整理する読者向けに、この記事では『60分でわかる！ AIエージェント 超入門』を紹介します。
自分の実使用品ではなく、役割分担や活用範囲を基礎から確認するための入門書として選びました。
