AI社員を24時間動かす前に、まず「仕事の信号機」を作った｜Central Job Queue実装記
AIに仕事を任せれば、あとは勝手に24時間働いてくれる。
そんな仕組みを作れたら面白いと思い、私はAIエージェントや「AIソフトウェア工場」の事例を追いかけてきました。
ただ、実際に自分の実験室へ取り入れてみると、最初に必要だったのは、もっと賢いAIではありませんでした。
必要だったのは、「今どの仕事をしてよいのか」「次に何をしてよいのか」「どこで人間の承認が必要なのか」を機械的に管理する仕組みでした。
そこで作ったのが、Central Job Queue（中央ジョブキュー）です。
この記事では、実際の実装で使っている正式な専門用語はあえて残します。専門家にはその方が正確で、初心者は意味を知りたい言葉だけ用語集で確認できるからです。分からない言葉が出たら、初心者用語集を参照してください。
30秒で結論
AIを自走させるときに難しいのは、文章を書かせることやコードを書かせることだけではありません。
本当に難しいのは、複数の仕事がある中で、
- 同じ仕事を二重に始めない
- まだ調査段階の仕事を勝手に実行しない
- 監査で問題が出た仕事をそのまま完了扱いしない
- 公開、課金、認証情報、実売買などは人間の承認なしに進めない
という「仕事の交通整理」です。
私の実験室では、この交通整理をAIの会話や記憶に任せず、状態機械（state machine）としてコード化しました。状態機械とは、仕事を「未着手」「実行中」「確認中」「完了」などの状態に分け、どの状態からどこへ進めるかをルールで固定する仕組みです。
きっかけは「AIを24時間働かせる」事例だった
外部のAI開発事例を見ると、複数エージェントがタスクを拾い、コードを書き、レビューし、次の仕事へ進む「AIソフトウェア工場」の考え方があります。
この発想自体は魅力的でした。
ただし、そのまま真似すると危ないとも感じました。
AIが「次はこれをやります」と自由に決め続けると、重複作業、終わらない再試行、承認が必要な作業への越境が起きやすくなります。
そこで、外部事例の構成をコピーするのではなく、「仕事の状態を外部で管理する」という考え方だけを取り入れ、実験室用に最小実装しました。
Central Job Queueで仕事を状態に分けた
実装したキューでは、仕事を次のような状態で管理します。
最初に、Research SCOUTなどが見つけた仕事はDISCOVERED（見つけた段階）として登録します。
仕事全体の流れを日本語で言うと、「見つける → 実行してよいと判断する → 作業する → 動作を確認する → 監査する → 正式版へ取り込む準備をする → 結果を観測・記事化する → 完了」です。
正式な状態名では、DISCOVERED → READY → IN_PROGRESS → VALIDATION → VP_REVIEW → MERGE_READY → OBSERVING / ASSET_GATE → DONE と呼んでいます。
途中で問題が見つかった場合は、REWORK（やり直し）、BLOCKED（外部条件などで進めない）、HOLD（意図的に保留）、OWNER_GATE（オーナー承認待ち）へ分岐します。
重要なのは、「AIがやりたいと言ったから実行する」のではなく、状態が実行可能かをコード側で確認してから進めることです。
実際の実装では、次に自動選択できるのはREADYまたはREWORKだけです。
つまりResearch SCOUT（外部情報から、実験室で試す価値がある「仕事の種」を探す調査役）が新しい仕事を見つけても、いきなり実行されません。まずDISCOVEREDとして記録され、別の判断工程を通ってREADYになったものだけが実行対象になります。
安全のために入れた3つの仕組み
1つ目は、Work_ID（仕事ごとの管理番号）の重複を許さないことです。
同じWork_IDが2件あればfail-closed（異常や不明点があれば安全側に倒して処理を止める設計）にします。
AI自動化では「似た仕事を別のAIがもう一度始める」だけでも、時間とAPI（外部サービスや機能をプログラムから呼び出す窓口）の利用量が増えます。重複を機械的に止めるだけでも、かなり重要だと分かりました。
2つ目は、Owner Gate（オーナー本人の承認待ち）です。
公開、課金、規約同意、認証情報、実売買など、人間が決めるべき仕事は自動承認されません。
OWNER_GATEへ入ると、過去の承認状態もリセットされます。
「一度許可したから次回もOK」という扱いにしない設計です。
3つ目は、監査結果と実際のコードを結びつけることです。
監査担当はPASS（問題なし）、REWORK（修正して再確認）、ESCALATE（AIだけでは決めず人間へ上げる）のいずれかを返しますが、自由文だけで状態を変えられるわけではありません。
VP_REVIEW（監査工程）の判定には、確認したHEAD SHA（監査したコードの版を特定する識別値）とEvidence Ref（判断根拠をたどるための証拠参照）を要求します。
つまり「監査AIが良さそうと言った」ではなく、「どのコードを、どの証拠で確認したか」まで残す設計にしています。
E2Eテスト（最初から最後まで通すテスト）で3つの分岐を確認した
Central Job Queueには、実際の状態遷移を確認するE2E（End-to-End）テストも作りました。E2Eテストは、部品ごとではなく「仕事を受け取ってから次の状態へ進むまで」の一連の流れをまとめて確認するテストです。
テストでは、監査結果に応じて仕事が3つの方向へ分かれることを確認しました。
まず、PASS（問題なし）の場合です。
日本語で言うと、「実行してよい → 作業する → 動作を確認する → 監査する → 正式版へ取り込む準備ができる」という流れです。
正式な状態名では、READY → IN_PROGRESS → VALIDATION → VP_REVIEW → MERGE_READY と呼んでいます。
次に、REWORK（修正が必要）の場合です。
これは「失敗したので終わり」ではありません。同じWork_ID（同じ仕事番号）のまま修正工程へ戻し、直したあとでもう一度確認します。新しい仕事として作り直さないので、最初の依頼から修正後まで同じ仕事として追いかけられます。
最後に、ESCALATE（AIだけでは決められない）の場合です。
この場合はOWNER_GATE（オーナー本人の判断待ち）へ移し、自動実行から外します。つまり、AIが迷ったまま勝手に先へ進まず、「ここからは人間が決める」と止める仕組みです。
このテストで確認したかったのは「AIが正しい答えを出すか」ではありません。
間違い、再作業、人間判断が必要なケースでも、システムが勝手に先へ進まないことです。
自動化で価値があったのは「賢さ」より境界線だった
この実装をして、AI自動化への見方が少し変わりました。
最初は、AI社員を増やせば自走が進むと思っていました。
しかし実際には、AI社員を増やす前に、
何を仕事として登録するか。
いつ実行可能にするか。
誰が監査するか。
どこで人間に戻すか。
失敗した仕事をどう再処理するか。
を固定する方が重要でした。
AIは文章生成やコード生成には強いですが、会社のルールまで自由に決めさせると運用が不安定になります。
そこで、判断できる範囲を狭くし、状態遷移や禁止条件は通常のコードで守る。
この組み合わせの方が、少なくとも私の実験室では扱いやすくなりました。
Research SCOUTとも接続した
現在はResearch SCOUTが見つけた候補をCentral Job Queueへ渡す橋渡しも実装しています。
ここでも新規候補はDISCOVEREDから始まります。
発見しただけで実装を始めない。
同じWork_IDがあれば重複登録しない。
キューの状態はOwner Cockpit（オーナー向けの状況確認画面）や日次締めでも確認できるようにする。
この流れを作ることで、「調査しただけ」「実装しただけ」「記事にしただけ」がバラバラに残るのではなく、1つのWork_IDで追いかけやすくなりました。
まだ「完全自動会社」ではない
ここは誤解されたくないところです。
Central Job Queueを作ったからといって、AIが24時間すべてを自由に実行する会社が完成したわけではありません。
自動公開、自動課金、規約同意、認証情報の変更、Live（実時間の本番運用）／Broker（証券会社などの取引接続先）／実注文や資金移動は、このキューの状態だけでは実行できません。
むしろ今回の実装は、「自動化するために、あえて自動化しない境界を作る」ためのものです。
外部の成功事例を見ると、つい「同じAIを入れれば同じことができる」と考えがちです。
でも実際に取り入れてみると、重要だったのはAI製品そのものより、仕事の状態、証拠、監査、人間承認をどう設計するかでした。
まとめ
「AIを24時間働かせる」という発想から、私の実験室ではCentral Job Queueを実装しました。
ただし、作ったのは何でも自動で動く仕組みではありません。
- 発見した仕事と実行可能な仕事を分ける
- 重複Work_IDを止める
- 監査結果をコードと証拠に結びつける
- 再作業を明示的に戻す
- 人間の承認が必要な仕事はOWNER_GATEで止める
という、AI社員のための「仕事の信号機」です。
AI自動化を進めるほど、AIに何をさせるかだけでなく、「何を勝手にさせないか」をコードにする価値が大きくなる。
これが、外部のAIソフトウェア工場の考え方を実際に取り入れて、自分の環境で実装してみて得た一番大きな学びでした。
実際にAIへ仕事を依頼するときのテンプレート
この記事で紹介したOwner Gate・完了条件・証拠の考え方を、AIへ依頼する際のチェック項目にまとめた「業務契約書」テンプレートをnoteで公開しています（有料300円）。無料部分で内容を確認してから購入を判断できます。
次に読む｜仕組みを作ったあと、本当に放置できたか測った
仕事の状態と停止条件を作った次は、「AIを増やせば速くなるのか」を同じ安全タスクで実測しました。Owner-PC直行とCodex経由を3回ずつ比較し、完遂・重複・介入・timeout・所要時間を記録しています。
※この記事は、AI自動化・資産型副業実験室で実際に行った設計・実装の記録です。特定のAIサービスや自動化方式の成果を一般化して保証するものではありません。