エージェントを役割別に分けたのに、「これ、誰の仕事？」と聞かれて答えられない業務が稼働中のまま残っていました。個人で運用しているAIエージェント組織で、2026年7月16日に棚卸しをしたときの話です。
この記事は、エージェントの作り方ではなく「仕事の持ち主の決め方」の記録です。やったことは、業務と担当エージェントの対応表を1枚置いて、新しい業務は着手前にそこへ1行登録する、というルールだけです。
環境と前提
- Claude Code + Markdownのみ（特別なフレームワークは使っていません）
- エージェントごとに人格書（Markdown）を
agents/配下に置き、秘書役のエージェントが依頼をルーティングする構成 -
agents/という置き場所と対応表の形式は私の自作の運用です。Claude Codeの機能や仕様の話ではありません
何が起きたか：分けたのに「持ち主のいない業務」が残った
最初は1つのエージェントに全部任せていました。コンテキストが膨らんで応答が的外れになったので、役割別に分け、秘書役が振り分ける構成に変えました。分割そのものは効きました。
ところが、分けたあとに困ったことが出ました。振り分け表（ルーティング）に載っているのは、私が最初に思いついた代表的な業務だけです。後から増えた業務は、誰の担当とも書かれないまま動き始めます。
2026年7月16日の棚卸しで見つかった「所属未定のまま稼働中」の業務は7つでした。記事の執筆、自律的な調査ループ、ある事業の調査系3業務、エージェント基盤の自己改修、インフラ保守です。どれも止まってはいません。動いているのに、問題が起きたときに誰が見る仕事なのか決まっていなかった、というのが厄介なところでした。
前職でも似た光景を見ています。経理担当が1人で月次決算を回していて、その人が休むと業務が完全に止まる職場です。手順が頭の中にしかないのが原因でした。AI組織の「所属未定」は、持ち主が頭の中にしかない（＝どこにも書かれていない）という意味で、同じ構造だと感じました。
対応表：1業務につき主務は必ず1つ
導入した対応表は、次の形式のMarkdownの表です（形式の見本であり、実際の表の抜粋ではありません）。
| 業務 | 担当（現状） | 人格書 | 状態 |
|---|---|---|---|
| 技術記事の執筆・自己採点 | writer | `agents/cmo/writer-agent.md` | ✅ |
| 定期ジョブの死活監視 | cto-agent | `agents/cto-agent.md` | ✅ |
| 価格差の日次チェック | （所属未定） | `agents/resale-agent.md` | 🔴 |
ルールは4つだけです。
- 新しい業務は、着手する前に表へ1行登録する。登録は内部作業なので確認なしで即実行する
- 複数部門にまたがる業務も、主務は1つに決める。連携先は備考に書く（責任の空白を作らない）
- 状態は3種類：✅配属済み／📋計画（業務が来たら配属）／🔴所属未定（すぐ決める）
- どこにも当てはまらない業務は、割り当てを勝手に汎用エージェントへ流さず、秘書に差し戻す
4つ目が一番効きました。「適当な汎用担当に流す」を許すと、表に載らない業務がまた静かに増えるからです。
担当を決める作業は自動化しやすく、自動化すべき
分析の仕事でも似たことがありました。売上データをBIツールにつなぎ、異常値を検知したらアラートが飛ぶようにしたところ、ある商品の売上急落に翌日には気づけるようになりました。価格改定で対応した結果、月100万円の売上回復につながりました。そのとき得た学びは「人間が判断すべきなのは打ち手の中身であって、変化を見張ることではない」です。
AI組織でも同じでした。秘書役は、依頼を受けたら（1）対応表に該当行があるか、（2）なければ登録して主務を決める、の順に動きます。誰が見るかを毎回悩む時間が消えました。
人格書にも「扱わない仕事」を書く
各エージェントの人格書は、話し方や専門分野を約50行で明文化しています。対応表を作ってから、ここに「担当しない仕事」も書くようにしました。担当の範囲が重なっていると、表では主務が1つでも、実行時に取り合いが起きるからです。
「野良ゼロ」の宣言は、一度間違えた
7月16日の夜に、7業務の所属を全部決めて「所属未定ゼロ」を宣言しました。配属済みは21業務でした。
しかし2026年7月26日に、未完了タスク約230件と全件突合したところ、対応表に行が無い業務がまだ大量にありました。受託スポット開発、ダッシュボード、書評サイト、学習支援、定期の調査、健康チェックなどです。再登録後の配属済みは42業務になり、倍近くに増えました。最初の棚卸しは、頭に浮かぶ範囲しか見ていなかったわけです。
そこで突合の入力を、記憶ではなく台帳に変えました。
| 突合の入力 | 見るもの |
|---|---|
| 動いている業務 | 未完了タスクの索引 |
| プロジェクト | プロジェクト一覧 |
| 定期ジョブ | ジョブ台帳 |
| 実際の配線 | launchd/crontabの実体 |
機械で止める層と、止められない層
人が忘れても止まる層を1つだけ作りました。定期ジョブの台帳です。ジョブの定義に owner を必須にし、owner が実在する人格書に解決できないジョブは、台帳のロード時に拒否する設計にしています。「所属未定のジョブ」を新しく作れなくするためです。なお、この記事では台帳の形式や検証コードは載せておらず、拒否の挙動を再現する手順も示していません。ここは私の運用の設計説明であり、動作の検証結果ではありません。
一方で、この仕組みには限界があります。
- 止められるのは定期ジョブの登録だけです。対話で頼んだ単発の作業や、台帳に載せずに手で動かすスクリプトは対象外です
- 見ているのは「担当先の人格書が実在するか」だけで、その担当が適切かどうかは判定できません
- 対応表に行を書く作業そのものは人（と秘書役）の運用です。書き忘れた業務は、月次の突合で見つけるまで残る可能性があります
つまり、完全に塞いだわけではありません。「新しい定期ジョブが無所属で増える経路」は止め、残りは突合と報告で拾う、という二段構えです。
手元で状態を確認する最小コマンド
対応表が形骸化していないかを見る、ごく簡単な確認です。表の形式が上の見本と同じであることが前提で、この記事を書いた時点では実行していません（出力は例です）。
# 所属未定(🔴)の行数。先頭が|の行だけ数える(ヘッダーや表内の凡例行も含む)。0が合格ライン
grep '^|' agents/ORG-MAP.md | grep -c '🔴'
# 表の「人格書」列(3列目)のパスが実在するか。見出し・説明文・{dept}等のプレースホルダーは対象外
awk -F'|' '/^\|/ && $4 ~ /`agents\/[^{}]*`/ {gsub(/[ `]/,"",$4); print $4}' agents/ORG-MAP.md | sort -u | while read f; do
if [ -f "$f" ]; then echo "OK $f"; else echo "MISS $f"; fi
done
出力は、各ファイルが実在するかどうかで変わります。上の見本の表なら、agents/cmo/writer-agent.md などが無い環境では MISS と表示されます。なお、このコマンドは執筆環境の制約で実行できておらず、出力例は載せていません。使う場合は、まず手元で試してから信頼してください。
注意点として、1つ目のコマンドは「先頭が | の行」を数えるだけで、Markdown表を構文解析しているわけではありません。ヘッダー行や、表内に書いた凡例の行に🔴があれば、それも数に入ります。表の外で、先頭が | ではない説明文だけが数から外れます。2つ目のコマンドは、各行が必ず | で始まる見本と同じ形式専用です（先頭の | を省略した表では列がずれ、何も検査できません）。また、人格書が3列目以外にある形式には対応しません。1セルに複数パスを書くと、個別には検証できず、連結された1つの文字列として扱われて MISS になる可能性があります。
運用で効いたチートシート
| 場面 | やること |
|---|---|
| 新しい業務の依頼が来た | 実行の前に対応表へ1行。主務を1つ決める |
| 担当が決まらない | 汎用担当に流さず、差し戻して決める |
| 複数部門にまたがる | 主務は1つ。連携先は備考へ |
| 新しい定期ジョブ |
owner を必須にし、実在しない担当は登録で弾く |
| 「ゼロ」を宣言する前 | 記憶ではなく台帳と突合する |
もう1つ、思わぬ穴がありました。AIへの操作を止める統制用スクリプトが8本あったのに、その保守担当が誰にも決まっていなかったのです。2026年9月27日に、点検専門の部門を新設して持ち主を決めました。「守る側」にも持ち主が要る、という当たり前のことを、表が空欄だったおかげで見つけました。
まとめ
- 後から業務が増える運用では、エージェントを分けても対応表に載らない業務が出る可能性がある。持ち主は表に書く
- 新しい業務は、着手前に1行登録する。主務は必ず1つ
- 「ゼロ」は記憶ではなく台帳との突合で確認する。機械で止められるのは定期ジョブの登録だけで、残りは運用で拾う
結局、いちばん効いたのは高度な仕組みではなく、「担当が決まるまで着手しない」という順序の固定でした。エージェント自体の出来を磨くより先に、仕事の持ち主を書いておくほうが、無人運転の安心感に直結しました。みなさんの組織では、分掌が決まっていない仕事が、いつ・どこで見つかりましたか。
今回は「持ち主を決める」ところまで書きました。決めた持ち主が実際に動いているかを定期的に確かめる月次の突合は、別記事で扱う予定です。
Claude Code や業務自動化まわりの実装で試したことを不定期に書いているので、続きが気になる方は フォロー をどうぞ。