こんにちは、健ちゃんです。
突然ですが、先日の話から。僕の手元では8つの案件が同時に動いていました。動画、AI動画、3Dモデル、音楽ゲーム、TCG本体、TCG Web、攻略PDF、そして記事企画です。それなのに、僕が見ていたチャットは8つではなく、たった1つだったんです。さて、これはどうやったのでしょうか。
AIへ仕事を分けたのに、なぜか自分が楽にならない。もしあなたがそう感じているなら、原因は作業そのものではありません。巡回、報告の回収、「次にどのチャットを見るか」の判断が、あなたに残っているからなんです。
この記事では、その判断ごとAIへ渡す「社長室」という運用を、1日試して分かった限界まで含めてお話しします。
なお、この運用の原型はルクさんが公開してくれたものです。ルクさん、ありがとうございます！
AIを増やしたら、管理する僕のほうが忙しくなった
複数のAIセッションを走らせれば走らせるほど疲れる。あるあるですよね。でもその原因は、画面の数ではありません。「次にどれを見るか」を決める判断と、話題を切り替えるたびのコンテキストの入れ替えなんです。
僕も最初は、複数セッションを1画面へ並べて表示する機能を使っていました。一覧できると把握感が高まるので、一見よさそうに見えるんですね。
ところが実際にやってみると、結局は自分でいろいろなセッションを見に行ってしまいます。これは社長が自分の足で現場を巡回しているのと同じで、どこへ行くかを考えるだけであなたのエネルギーが減っていくんです。
つまり、AIを増やして楽になるためには、作業だけでなく「巡回と選択」もAIへ渡す必要があります。そのための窓口が今回の社長室です。
「社長室」は、使い捨てのサブエージェントではない
もしかしたらサブエージェントの話でしょう、と思った方がいるかもしれません。違うんです。
サブエージェントは、いま開いているセッションから立ち上げて、1つのタスクを渡し、終わったら消える使い捨ての存在です。一方、社長室が束ねるのは、履歴を持ってずっと働き続けている「継続セッション」たちなんですね。
僕の場合、社長室はローカルコマンドを実行できるClaude Codeデスクトップアプリへ置きました。そこからClaudeの継続セッションと、Codexの継続セッションの両方を、秘書役のAIにまとめて管理させています。
Claude CodeからCodexを動かす最小手順
意外だったのは、ClaudeからCodexの継続セッションへも指示を飛ばせたことです。最小構成なら、Codex CLI標準のcodex queueをClaude Codeから実行します。
必要なのは、Codex CLI、指示先となる既存セッションのUUIDまたは正確な名前、ローカルコマンドを実行できるClaude Codeの3つです。通常のClaudeチャットから、コマンドを貼るだけでは動きません。
まずClaude Codeのターミナルで、queueが使える版かを確認します。そのうえで、対象と本文を表示して確認し、既存セッションへ指示を積みます。
codex queue --help
codex queue --thread "<セッションUUIDまたは正確な名前>" \
--message "そのまま記事制作を進めてください。"
送ったらCodexの画面で対象セッションを開き、送信文が利用者メッセージとして追加されたことを目で確認します。CLIが成功を返しただけで、到達確認を終えないのがポイントです。
補助CLI codexsessは僕専用の未配布ツール
僕は見回りと誤送信防止のために、~/bin/codexsessという1ファイルの補助CLIも使っています。これはCodexの標準機能でも公開済みツールでもなく、今回の運用用に用意したものです。
codexsess list --since 180 --json
codexsess read <thread-id> --full
codexsess send <thread-id> "そのまま記事制作を進めてください。"
codexsess send --confirm <確認トークン>
codexsess read <thread-id> --full
この補助CLIでは、listで既存セッションを探し、readで対象を確認します。sendの1回目はまだ送信せず、宛先、直近のやりとり、本文、確認トークンを出します。人間が確認してから--confirmで送り、最後にもう一度readで到達を確かめる流れです。
codexsessはどう作ったか
実体は、Pythonの標準ライブラリだけで書いた1ファイルのCLIです。すでに動いているCodex app-serverのUnixドメインソケットへWebSocketで接続し、セッションの一覧と履歴を読みます。外部サーバーや外部APIは使いません。
設計で大切にしたのは、「読む経路」と「送る経路」を分けることです。一覧と履歴はapp-serverのthread/listやthread/readなどから取得します。一方、指示の送信は内部RPCへ直接書き込まず、標準のcodex queueを呼び出します。
誤送信を防ぐため、送る前に宛先、直近の履歴、本文を表示します。そこで15分だけ有効な1回限りの確認トークンを発行し、確認後に初めて送信する二段階方式にしました。
送信後は、履歴を最大200項目まで読み直し、同じ本文の利用者メッセージが増えたことも確認します。コマンドが成功したことと、相手へ届いたことを分けて確かめるためです。
ただし、app-serverのソケットや読み取り用RPCは、公開された安定APIとして保証されたものではありません。自作する場合も、環境依存の読み取り補助として扱い、送信は標準CLIへ任せるのが安全です。
補助CLIがない場合
codexsessがない環境でも、人間がセッションIDを渡し、Claude Codeからcodex queueで指示を送れます。到達確認は、人間がCodexの対象セッションを画面で開いて行います。
一方、一覧取得と自動見回りはできません。そこまで任せるには、利用中の仕組みで同等の「一覧・読取・確認付き送信」を用意する必要があります。
僕の環境では、秘書役のClaudeがlistとreadで定期的に見回り、判断待ちや成果物を拾います。これでClaude Codeの窓を離れず、既存のCodexセッションも同じ社長室から動かせるんです。
継続セッションが2つ3つのうちは自力で回せます。しかし10個へ近づくと、もう手に負えません。あなたのセッションが増えて疲れ始めたら、それが社長室を作るタイミングです。
人間は1件だけ見て、AIは裏で並行する
窓口を1つにしたら仕事が詰まるのでは、と思いますよね。詰まらないために今回僕が導入したのが、**「フォーカスセッション」**です。
僕が秘書とやりとりする案件は、常に1件だけ。ほかの案件から報告が上がってきても、秘書はそれを預かっておき、いまの話へ割り込ませません。人間のコンテキスト切り替えは高くつくので、切り替えの回数そのものを減らすんです。
では、いつ次へ移るのか。案件の完了時ではありません。担当のAIが再び動き始めた時点です。やりとりが必要なのは担当が止まっているときだけなので、動き出したらもう見守る必要はなく、次の止まっている案件へ移れます。
次にどれを見るかは、秘書が提示します。ただし優先順位そのものは僕が決めて渡しておく。判断の基準は人間が持ち、基準の適用はAIがやる、という分担です。
例外は1つだけ設けました。課金が走り続けている、誤送信や誤公開が起きそう、といった取り返しのつかない事態だけは、フォーカス中でも割り込ませます。逆に言えば、それ以外は待たせて構わないんです。
PCを急がせるより、人間を止めない
複数のAIが同じマシンで働くと、今度はPCが重くなります。僕のマシンは非力なIntel Macなので、ここも秘書の仕事にしました。
きっかけは、動画変換のffmpegでした。単体のプロセスがCPUの584%を占有していて、僕の操作がもたつくほど重くなっていたんです。
正直に言うと、これは秘書が先回りで見つけたのではなく、僕が「重たい」と申告してから発見されました。だからこそ、以後はCPUとメモリの監視をルール化しています。
対処には nice コマンドを使います。これはCPUの使用率へ上限をかけるものではなく、スケジューリングの優先度を下げるものです。バックグラウンドの処理は遅くなりますが、人間の操作が優先されるようになります。
ここには1つの割り切りがあります。ボトルネックはPCではなく人間だ、という前提です。AIの処理が多少遅れても、あなたの手と集中が止まらないほうが、全体としては前へ進むんですね。
1日では「効率化できた」とは言えない
さて、都合の悪い結果も正直に書きます。1日運用した結論は「作業効率はまだ上がっていないが、自分の消耗は減った」でした。
当日の感触は僕のXの投稿にも残しています。長期で効くかどうかは、まだ検証できていません。
効率が上がらない理由ははっきりしています。秘書のオーバーヘッドです。伝言を挟む分だけ時間とトークンを消費するので、その分を上回るメリットが出ない案件では割に合いません。
向かない案件もあります。3Dモデル開発のように、人間の手作業が頻繁に入る仕事です。僕の操作をAIだけでは代替できないため、間に秘書が入ると伝言が化けて、逆に混乱する場合があるんですね。
実は、この記事も一度それを経験しています。構成案が秘書経由の伝言で意図と違う形になり、差し戻しになりました。伝言の精度が結果を左右する仕事では、直接やりとりするほうが速いんです。
だからあなたが判断すべきは「社長室を使うか」ではなく「どの案件へ使うか」です。AIが自走できる案件には効き、人間が主役の案件には効かない。この線引きさえ持てば、消耗の削減だけを先に受け取れます。
まず3案件で試す
いきなり8案件で始める必要はありません。継続して動いている案件を3つ選ぶところから始めてください。
設定するルールは4つだけです。開くチャットは社長室1つ。案件の優先順位はあなたが決めて渡す。フォーカスは担当が動き出したら次へ移す。割り込みは取り返しのつかない事態だけ。
この4つで、僕が1日で得た効果の骨格は再現できます。
消耗が減ったと感じたら案件を足す。伝言が化けて混乱した案件は素直に外す。そうやってあなたの仕事に合う形へ育てていくのが、いちばんの近道です！
付録：社長室を始めるプロンプト
この運用には、セッション間でメッセージを送り合える仕組みが必要です。僕はローカルコマンドを実行できるClaude Codeデスクトップアプリを使っています。通常のClaudeチャットへプロンプトを貼るだけでは、Codex CLIや負荷監視の機能は追加されません。
準備できた機能に合わせて、以下のプロンプトへ実際の道具名、案件名、優先順位を書き込んでください。使えない操作を、できるものとして扱わせないことが大切です。
最初はチャットが1つしかないことへ違和感があるかもしれません。でも、だんだん慣れます。
あなたは「社長室」の窓口役（社長秘書）です。私は社長として判断だけを行います。
以下のルールで、複数のAI作業セッションを管理してください。
## 最初に確認する道具
- Claudeセッションの一覧・読取・送信に使える機能: （実際の名前を書く）
- Codexセッションへの送信: `codex queue --thread <IDまたは正確な名前> --message <本文>`
- Codexセッションの一覧・読取: （`codexsess`または、実際に用意した同等機能を書く。無ければ自動見回りしない）
- 成果物をこの窓へ提示する機能: （実際の名前を書く）
- 押して選べるダイアログを出す機能: （実際の名前を書く）
- CPUとメモリを確認する機能: （実際の名前を書く）
- 書かれていない機能や、利用できない機能を、あるものとして扱わないでください。
## 役割
- あなたの仕事は「割り振る・見回る・報告する」の3つです。実作業は各担当セッションに任せ、あなた自身は作りません。
- 私に見せる成果物や判断材料は、担当に作らせてこの窓へ運んでください。要約だけで判断を求めず、実物（画像・動画・差分）を添えてください。
- 担当へ依頼するときは、次の4点を必ず伝えてください。
- 依頼の目的、正しい素材、完成条件
- 一区切りついたら、この窓へ報告すること
- 判断が必要になったら、そこで手を止めてこの窓へ上げること
- 担当から私へ直接質問せず、判断事項はこの窓へ残すこと
## セッションの扱い
- 仕事を割り振るときは、一覧機能が使える場合だけ既存セッションを確認してください。一覧機能がない場合は、私からセッションUUIDまたは正確な名前を受け取り、送信後に対象のCodex画面を開いて到達確認するよう私へ依頼してください。
- 停止中のセッションは「終了」ではなく「手が空いている」と扱ってください。
- 新しいセッションを立ててよいのは、私が指示したときだけです。必要だと思ったら、立てる前に確認してください。
## フォーカスセッション
- 私と今やり取りしている案件を「フォーカスセッション」と呼びます。
- フォーカスが移るまで、他のセッションの報告は手元に溜め、私へ出さないでください。
- フォーカス案件の担当が動き始めたら、完了を待たずに次の止まっている案件へ移ってください。
- 私自身の作業が次に必要な案件は、担当が動き始めてもフォーカスを移さず、私の作業が終わるまで保持してください。
- 次の案件は、私が渡す優先順位に従って選んでください。
優先順位: （ここへあなたの案件と順位を書く）
- 例外は「放置すると取り返しがつかないもの」（課金が走り続ける、誤送信・誤公開、素材の消失など）だけです。これはフォーカス中でも割り込んで報告してください。
## 待ちの扱い
- 私へ判断を仰いだら、返事を待たずに次の案件を進めてください。待ちは並行できます。
## 見回り
- 各担当の報告を待つだけでなく、停止中または報告不能のセッションを能動的に見回ってください。
- 特にCodex側からこの窓へ自動報告できない環境では、一覧と最新メッセージを定期的に読み、判断待ち、成果物、異常を拾ってください。一覧・読取機能が無ければ、自動見回りをできるものとして扱わないでください。
- `codexsess`を用意した環境では、`list`で候補を探し、`read`で対象を確認し、`send`の下書き、宛先、本文を人間が検査してから`--confirm`で送り、もう一度`read`で到達確認してください。
- `停止中`や`isRunning: false`を終了扱いしないでください。既存セッションは再開できます。
## 報告のルール
- 私へ報告してよいのは、(1)判断を仰ぐとき、(2)見るべき成果物があるとき、(3)緊急事態、の3つだけです。
- 判断が必要な報告は、「状況」「結論」「2〜3択とおすすめ」「次の一手1つ」の順に書いてください。
- 選択肢を出すときは、可能なら押して選べるダイアログで提示してください。
- 私が次に判断・確認することのない経過報告（「担当へ伝えました」など）は出さないでください。
- 私へ1件を報告している間、ほかの通常報告を混ぜないでください。次の一手は1つだけ示してください。
## 負荷監視
- CPUとメモリの負荷を定期的に測り、CPU占有率が80%を超えるか、メモリの空きが20%を切ったら、原因のプロセスを特定して警告と対処案を出してください（閾値は環境に合わせて調整してください）。
- 重い処理は優先度を下げて走らせ、私の前面の作業を妨げないでください。処理の完了が遅くなることは構いません。
## してはいけないこと
- 公開、送信、削除、上書き、課金を伴う処理は、必ず私の承認を得てから実行してください。
- 既存の生成物を消したり上書きしたりしないでください。
メルマガ
元エンジニアがAIについて、実践を元に発信しているメルマガです！ ぜひご登録ください。
