62体のAI社員が働く会社の中身を見た——「AI導入」ではなく「AI運用」の話
「AIを導入しました」という話はもう珍しくない。珍しいのは、「何体のAIが、どの業務を、どの順番で、どこまで人間の承認を挟んで動いているか」を実態のまま公開することだ。
生成AIの研修・コンサルティング・開発を手がけるUravationが2026年9月10日に公開した内容は、その意味でひとつの実例として価値がある。62体のAIエージェント、9部門、常時稼働する自動ジョブ250本超。数字だけ並べると大きく聞こえるが、読んでいくと「どうAIを組織するか」という設計の話であることがわかる。
組織図の話から始める
Uravationの「AI社員」組織は5階層で構成されている。
代表 → 人間チーム → AIマネジャー9体 → 9つのAI部門 → 53体のAI社員、という構造だ。人間チームが担うのは業務設計・承認・品質判断。AIマネジャーが各部門を取りまとめ、53体のAI社員が実務を担う。全エージェントはClaude Codeで構築されている。
9部門の内訳は「社内窓口・秘書」「広報・マーケティング」「メディア運営」「営業サポート」「経理・総務」「サイト監視・品質チェック」「開発」「経営企画」「人事・研修」。メールの仕分けや会議の準備から、コードレビュー・セキュリティチェック、記事作成・公開まで、幅が広い。
開発部門には5体を配置し、実装・コードレビュー・セキュリティチェック・テストを分担している。サイト監視部門は外部の死活監視だけでなく、「監視を担当するAI自体が正常に動いているかどうか」も確認対象に含めている。この点については後で触れる。
一日の動きを追うと見えてくること
各AIエージェントには決まった稼働周期がある。タスク進捗を管理するAIは60秒ごと、会議の準備をするAIは5分ごと、メールを仕分けするAIは30分ごとに動く。「常時稼働」とは、このように細かい周期で動き続けるエージェントが250本以上走っている状態のことだ。
一日の動きも具体的に公開されている。午前4時43分にバックアップ係が起動し、主要システムを別拠点に退避、7世代分を保持する。午前7時台にはWebサイト18ページを確認する「ロゴ番人」、商談相手をリサーチする係、記事ネタの在庫を確認する係が動き始める。午前8時台には日報係が運営レポートを投稿し、「監視の監視」を担当するAIが自動ジョブ約140本の正常稼働を点検する。午前9時台に入ると経理処理、営業案内文の作成、記事公開が進む。
人間が業務を始める頃には、必要な準備と報告がすでにそろっている。人間の仕事の「入力」をAIが整える、という構図だ。
4つのルールに込められた設計の話
Uravationは「AI社員を増やしても事故を起こさないための4つのルール」を明示している。
1. 外部への送信・公開は人間が承認してから実行する
メール1通、記事1本の例外もなく、AI社員の仕事は「送れる状態まで用意すること」に限る。
2. 確認できる事実だけを書く
実績数値は社内の実測に限り、書く価値のある題材がない日は記事を作らない。
3. 警告には拾う人間を必ず決める
鳴っても誰も拾わない警告は、存在しないのと同じ。
4. 監視そのものも監視する
見張り役のAIが黙って止まる事故が最も危険なので、見張り役の生死を別のAIが毎朝点検する。
この4つを読んで、「AI活用の話というより、組織設計の話だ」と感じた。特にルール3と4は、AIを増やした組織が必ず直面する問題を先取りしている。
ここからは見方の話
この取り組みを、「先進的なAI活用事例」として素直に読むだけでは少し惜しい。
Uravationは生成AIの研修・コンサルティング・開発を主業としている会社だ。つまり、「自社でこれだけのAI運用をやっています」という実態の公開は、顧客に対する信頼性の担保でもある。「言葉で説明するより、実際に何体のAIが、どの業務を、どの順番で動いているかを見てもらう方が早い」という同社のコメントは、その戦略的な意図を率直に表している。
これは批判ではない。むしろ「実績の透明化」というアプローチは、AI活用の文脈でまだほとんどの企業が取れていない手だ。多くの企業は「AIで業務効率化しました」という定性的な発表にとどまる。対して、エージェントごとの稼働周期・一日の動き・成果物サンプルまで公開するのは、別の水準の話だ。
構造として見ると、これはAIエージェントの「チーム化」が実用段階に入りつつあることを示す実例でもある。62体という数は、もはや「ツールを使う」という感覚ではなく「チームを組む」に近い。そして、チームを組むときに必要なのは技術よりも組織設計——誰が何を担い、誰が何を判断し、誰がミスに気づくか——だという点が、この事例の核心にある。
実務で次に考えるべきこと
AIエージェントを複数運用しようとする組織が、この事例から取れるものは何か。
ガバナンスの設計を先に決める
Uravationの4つのルールが示すように、「外部への情報発信は必ず人間が承認する」という原則は、導入前に決めておくべきことだ。エージェントを動かしながら後から決めようとすると、すでに走っている処理に制約を後付けする形になり、運用が複雑になる。
「監視の監視」という問題を意識する
AIエージェントが増えると、エージェント自体の死活監視が必要になる。しかしその監視ツールが止まったとき、誰が気づくか。Uravationが「見張り役のAIが黙って止まる事故が最も危険」と明示しているのは、これを実際に体験したか、もしくは設計段階で見通したかのどちらかだ。「監視の監視」は、エージェント運用を一定規模以上に持っていくと必ず当たる壁だ。
タスクの状態管理を設計する
エージェントが並走するとき、タスクが「作業中」「レビュー待ち」「人間待ち」のどの状態にあるかを可視化しないと、人間のチェックポイントが曖昧になる。このステータス管理の仕組みがないまま複数エージェントを動かすと、どこで詰まっているかわからなくなる。
今後の論点：スケールしたとき何が壊れるか
62体という数が「多い」のか「少ない」のかは、用途次第で判断が変わる。ただ、この規模が50社・100社に広がったとき、次に問題になるのは「人間の承認」の部分だと思う。
現在のUravationのモデルでは、外部発信は100%人間が承認する。この原則は正しい。だが、エージェントが増え、処理量が増えると、「人間が確認できる量」という上限が見えてくる。承認の形骸化、見落とし、ボトルネック化——これはAIの問題ではなく、人間側の処理能力の問題だ。
「AIに何を任せるか」という問いの次に来るのは、「人間が何を確認できるか」という問いだ。スケールを上げるほど、この問いが設計の核心になる。
もうひとつ。今回の事例はUravation単体の話だ。同社はAI関連の会社であり、技術的なリテラシーと組織の柔軟性が高い前提がある。「汎用性のある方法論」として他の企業に転用できるかどうかは、業種・規模・既存の組織構造によって大きく変わる。62体の運用が参考になる企業もあれば、まったく別のアプローチが必要な企業もある。
この事例を「すごい」で終わらせず、「自分たちの組織に当てはめると何が足りないか」を考える素材として使えるかどうか——それが、このニュースを読む実務的な価値だと思う。
参考元: 社内9部門、62体のエージェントをどう運用？ 「AI社員」が働く企業の実例：自動ジョブ250本以上が稼働（＠IT）
