AI駆動開発 2026年10月11日

62体のAI社員、9部門、250本の自動ジョブ──Uravationの「AI組織」公開から読む、次の実務設計

AIエージェントを「業務に使っている」という話は増えた。ただ、その中身を具体的に公開している企業はまだ少ない。何体が、どの業務を、どの周期で、どこまで自律的に動いているのか。そこまで見せている事例はなかなかない。

Uravationが2026年9月10日に公開した「AI社員62体の一覧と組織図」は、その点でかなり異質だ。数字がある。体制図がある。一日のタイムラインがある。「AIを活用しています」という発表ではなく、実態の開示に近い。

深夜4時43分から始まる「AI社員」の一日

公開資料によれば、Uravationのバックアップ担当AIは午前4時43分に動き始め、主要システムを別拠点に退避させ、7世代分を保持する。人間がまだ眠っている時間に、AIが黙々とストレージを書き換えている。

午前7時台になると、Webサイト18ページを点検する「ロゴ番人」、その日の商談相手を調べるリサーチ係、記事ネタの残量を確認する在庫番人が動き出す。8時台には日報係が運営レポートを投稿し、「監視の監視」を担当するAIが自動ジョブ約140本の正常稼働を点検する。9時台には経理ミラー係が請求書・領収書を整理し、SDR係が営業先への案内文を作成し、出稿係が各メディアへの記事公開を進める。

人間チームが業務を始める頃には、必要な報告と準備がそろっている。この流れが毎日繰り返されている。

組織図を先に理解する

62体の内訳は、AIマネジャー9体と、9部門に所属する53体のAI社員だ。組織は「代表→人間チーム→AIマネジャー9体→9つのAI部門→53体のAI社員」という5階層で構成されている。

9部門の名称と役割は以下の通りだ。

社内窓口・秘書：24時間チャット常駐、会議準備、メール仕分け、議事録作成
広報・マーケティング：外部向けコミュニケーション支援
メディア運営：各メディアへの記事公開
営業サポート：商談相手の下調べ、案内文・お礼メールの作成
経理・総務：請求書・領収書の整理、制度改定の確認
サイト監視・品質チェック：Webサイトの死活監視、記事の鮮度確認
開発：実装、コードレビュー、セキュリティチェック、テスト（5体配置）
経営企画：経営情報のサポート
人事・研修：採用・育成関連の業務支援

全エージェントはClaude Codeで構築されている。常時稼働する自動ジョブは250本以上。タスクは「作業中」「レビュー待ち」「人間待ち」といった状態に分けて管理されており、複数のAIが並走することを前提とした設計になっている。

「自動ジョブ250本以上」が意味すること

エージェントの数も興味深いが、もっと注目したいのは実行周期の設計だ。タスクの進捗を管理するAIは60秒ごと、会議の準備をするAIは5分ごと、メールを仕分けするAIは30分ごとに動く。業務の性質に応じて粒度が変えられている。

これは「AIを使っている」という状態ではなく、AIの動作を前提としたプロセス設計がなされているということだ。人間が都度起動するのではなく、AIが決められた周期で自律的に動き、人間はその結果を受け取るか、判断が必要な案件にだけ関与する。

特に目を引くのが「監視の監視」という設計だ。Webサイトや自動ジョブを監視するAIが存在するだけでなく、その監視AIが正常に動いているかを別のAIが毎朝点検する仕組みがある。「見張り役のAIが黙って止まる事故が最も危険」という認識が、この設計を生んでいる。

普通のシステム監視でも同じ発想はあるが、AIエージェントの文脈でここまで明示的に言語化している事例は珍しい。

ここからは見方だが──「AI組織設計」という次のフェーズ

ここからは事実の整理ではなく、この事例をどう読むかという話だ。

Uravationの事例が示しているのは、AIの活用が「ツール導入」から「組織設計」のフェーズに入り始めた、という変化だと思う。

「ChatGPTを社員に使わせる」「Copilotを導入する」という段階では、人間の仕事の補助としてAIが使われる。人間がタスクを持ち、AIがその一部を肩代わりする構図だ。

Uravationのモデルはそこから一段違う。AIが担う業務の範囲を先に定義し、実行周期を決め、状態管理の仕組みを作り、人間が介入すべきポイントを設計する。「何をAIに任せるか」ではなく「何を人間に残すか」を考えているように見える。

人間チームの役割として明示されているのは「業務設計、承認、品質判断」の3つだ。AIが処理し、人間が受け取り、必要なら判断して承認する。この分業の構造が先に設計されている。

これは個人や小チームでAIを便利に使う話とは、設計の出発点が違う。

4つのルールが実務設計の核心だ

Uravationが公開した4つのルールは、AI組織運用の実務設計として読むと非常に密度が高い。

1. 外部への送信・公開は人間が承認してから実行する
メール1通、記事1本、例外なし。AI社員の仕事は「送れる状態まで用意すること」に限られる。

2. 確認できる事実だけを書く
実績数値は社内の実測に限り、書く価値のある題材がない日は記事を作らない。

3. 警告には拾う人間を必ず決める
鳴っても誰も拾わない警告は存在しないのと同じ、という言葉は、実際にシステム運用をやったことがある人間には刺さる。

4. 監視そのものも監視する
見張り役が止まったとき、誰が気づくか。それを別のAIが担う。

この4つは、AIを「たくさん動かす」ことへの答えではなく、「たくさん動かすときに何が壊れるか」への答えだ。

特に2番目のルールは、AIコンテンツ生成の現場への示唆が大きい。「毎日記事を出す」「毎日投稿する」という量的な目標ではなく、「確認できる事実のみ、ネタがなければ作らない」という制約を先に設けている。AIで大量生成しようとすると、品質より量を優先してしまう引力がある。その引力に事前にルールで抵抗している。

実務に落とすと、何を考えるべきか

この事例を受けて、実際に組織でAIを使っている人、あるいはこれから設計しようとしている人が考えるべきことを整理しておく。

「何体使っているか」は本質ではない

62体というのは一つの数字に過ぎない。問いは「何を人間に残したか」だ。承認フローをどこに置くか、警告の受け取り手を誰にするか、状態管理をどう設計するか。体数より設計の中身の方が重要だ。

小規模でも設計の思想は応用できる

62体の運用は自社でいきなりできないとしても、「AIが処理する→人間が確認・承認する→外部には出さない」というフローの設計は、5体でも10体でも適用できる。むしろ少ない段階で設計の癖をつけておかないと、体数が増えたときに破綻する。

次に問題になるのはコストと評価軸だ

常時250本以上の自動ジョブが稼働しているということは、それだけのAPIコストが継続的に発生しているということでもある。「トークン単価は下がったが請求額は増えた」という話は他の文脈でも出てきている。エージェントの体数が増えるほど、コスト管理と費用対効果の可視化は難しくなる。Uravationは自社のコンサルティング・研修事業と合わせた事業判断として動かしているのだと思うが、他の企業がそのまま横展開できるかは別に考える必要がある。

また、AIマネジャー9体が「各部門を取りまとめる」という設計になっているが、AIマネジャー自体の判断品質をどう評価するか、という問いはまだ答えが出ていない領域だ。エージェントが増えれば増えるほど、「誰がエージェントの仕事ぶりを評価するか」という責任の所在が曖昧になりやすい。Uravationのモデルでは人間チームがその責任を持つ構造になっているが、人間チームの工数がどの程度かかっているかは公開されていない。