【2026年8月】AI社員61体の運用でわかった9つの教訓

AI社員の定義やメリットを知りたい方は「AI社員とは」の解説へ、実際の組み立て方を知りたい方は「AI社員の作り方」5ステップへ進んでください。この記事では、その二つを繰り返しません。61体を社内で毎日動かした結果、何が起き、どのルールを変えたかだけを記録します。

61体を「9つの部署」に分けて初めて見えたこと

最初に、現在地をはっきりさせます。UravationのAI社員は、単一のチャット画面に61の名前を並べただけのものではありません。人間チームの下にAIマネージャーを置き、その下で担当業務を持つAI社員が動く組織です。2026年8月には「開発」「経営企画」「広報・マーケティング」「人事・研修」の4部門を追加し、現在の9部門になりました。

部門名、AIマネージャー名、役割名はUravationのAI社員組織図で公開している表記に合わせると、次のようになります。

※掲載は代表的なメンバーの一部です。部門名・役割名は2026年8月31日に公開ページで確認した表記です。

この構造にした理由は、見栄えのよい組織図を作るためではありません。61体の成果物をすべて人間が直接確認すると、人間側に確認待ちが集中するからです。AIマネージャーは、依頼をどの部下AIに渡すかを決め、戻ってきた成果物を関所で検品します。それでも外部へ出る操作は、人間の承認が入るまで止まります。この二段構えが、61体を「使える数」に変えた大きな分岐でした。

職務記述書は「説明書」ではなく仕事の境界線になった

教訓1：書いた分だけ働き、書かなかった部分は補ってくれない

AI社員を実運用して最初に突き当たったのは、モデルの賢さより指示の曖昧さでした。「よい感じに整理する」「必要なら対応する」「問題があれば知らせる」。人間同士なら周辺の文脈で補える表現も、AI社員にとっては判断基準が足りません。曖昧な職務記述書からは、曖昧な成果物が返ってきます。

そこで各AI社員について、少なくとも次の4項目を文章で固定しました。

実体はCLAUDE.mdやスキルファイルです。これは単なるプロンプト集ではなく、社員ごとの職務記述書として扱っています。AnthropicのClaude Code公式ドキュメントでも、CLAUDE.mdはセッションをまたいで読み込まれる持続的な指示の置き場とされています。Uravationでは、その仕組みを「何をするか」だけでなく「何をしてはいけないか」まで伝えるために使いました。

正直に言うと、職務記述書を書けばAIが何でもできるようになるわけではありません。むしろ逆です。書いていない仕事まで都合よく察してくれる、という期待を捨てられたことが運用上の前進でした。判断基準を言葉にできない仕事は人間に戻す。この割り切りがないと、AI社員の担当範囲だけが際限なく広がります。

教訓4：失敗をメモリに残さないと、次の実行ではまた初対面になる

同じ指摘をしたのに、次回また同じ失敗をする。これも実運用で何度も向き合う問題です。会話の中で一度注意しただけでは、その知見が次の仕事へ確実に引き継がれるとは限りません。

そこで、再発させたくない失敗は再発防止メモとして残し、次回の作業開始時に読み込ませる形へ変えました。記録するのは感想ではなく、「何が起きたか」「なぜ問題だったか」「次回は何を確認してから進むか」です。ルール本体にするほど普遍的な内容はCLAUDE.mdやスキルへ、特定の失敗から得た学びはメモリへ置きます。

ここで重要なのは、メモリを増やすこと自体を成果にしないことです。長い注意書きが増えるほど、必要な停止線が埋もれます。次の実行で実際に読まれ、行動が変わる場所へ、短く具体的に残す。この運用へ変えて初めて、失敗が「その場の注意」から「次回の品質」へつながりました。

【要注意】「できました」は完了の証拠ではなかった

教訓2：成功報告より、成果物の実在を先に見る

AI社員は、作業の最後に「できました」と報告します。しかし、その一文だけを完了条件にすると危険です。確認すべき対象は、報告文ではなく、成果物そのもの、処理ログ、反映先の現在状態です。

Uravationでは、完了を次の3層で確かめるように変えました。

1. 成果物の実在：指定された場所に、指定された形式の実物があるか
2. 処理の記録：途中で失敗や未処理がなく、どの処理が走ったか確認できるか
3. 反映結果：作ったファイルではなく、利用者が見る最終地点で変化を確認できるか

この確認は、人間が行う場合もあれば、品質チェックを担当するAI社員が行う場合もあります。大切なのは、実行役と検品役を同じ「できました」の中に閉じ込めないことです。検品役は、成功報告を信じるのではなく、別の入口から実物を見ます。

NISTのAI Risk Management Frameworkも、AI製品・サービス・システムの設計から利用・評価まで、信頼性を組み込むための枠組みを示しています。Uravationでの教訓を大げさに一般化するつもりはありませんが、「生成したこと」と「使える状態を検証したこと」は別だ、という点は一致します。

外へ出る直前だけは、人間の手を残した

教訓3：承認ワードを明文化し、承認権を人間側に固定する

メール、SNS投稿、記事公開、本番反映。これらは、下書きの品質が高くても、実行すれば社外や利用者に影響します。Uravationでは、AI社員が「送れる状態」「公開できる状態」まで準備することはあっても、最終承認は人間が持ちます。

運用を始めたころに痛感したのは、「たぶん承認だろう」という解釈をAI側にさせてはいけないことでした。承認とみなす言葉、承認ではない依頼、承認後に許される操作を文章で分けています。人間が内容を確認したあと、明文化された承認が届かなければ、AI社員は止まります。

これは担当者の注意力に頼るルールではありません。誤送信は気合いではなく仕組みで止める。そのための停止線です。確認を忘れない人を育てるより、確認がなければ操作できない職務記述書にするほうが、毎日の運用に残ります。

OpenAIのAIエージェント構築の公式ガイドでも、高リスク、機密性、不可逆性を伴う操作では人間の介入を組み込む考え方が示されています。また、経済産業省と総務省が2026年3月31日に公表したAI事業者ガイドライン第1.2版は、AIガバナンスとモニタリングの実践資料を公開しています。Uravationでは、これらを抽象的な方針で終わらせず、「外部へ出る前に止まる」という日常の操作へ落としました。

権限設計をもう少し技術面から確認したい方は、既存記事のAIエージェントの最小権限と停止手順も参考にしてください。本稿で伝えたいのは権限設定の方法ではなく、61体に増えても外部操作の最終承認を人間から手放さなかった、という運用上の事実です。

怖かったのは赤いエラーより「静かな失敗」だった

教訓5：定期ジョブは、動いた回数ではなく終了状態で見る

画面にエラーが出る失敗は、まだ見つけやすいんです。本当に怖いのは、定期ジョブが走ったように見えるのに、必要な成果物が更新されていない状態です。誰にも気づかれず、翌日も同じ状態が続く。これを私たちは「静かな失敗」として扱うようになりました。

対策は、定期ジョブの終了コードを記録し、失敗したときだけ通知することでした。ただし、終了コードだけで完全とは考えません。先ほどの完了確認と同じように、重要な仕事では成果物の現在状態も見ます。処理が正常終了していても、利用者が見る実物が古いままなら成功ではないからです。

通知の受け手も決めました。警告を出しただけでは、誰の仕事にもなりません。人に判断を求める通知には担当者を割り当て、単なる機械ログとは分けます。異常を検知する仕事と、異常を拾って判断する仕事は別です。

教訓7：人が読む通知を減らし、判断が必要なレーンだけを残す

AI社員が増えると、仕事だけでなく報告も増えます。すべての成功通知を人間のチャットへ流すと、重要な警告が日常報告に埋もれます。これは情報量の問題というより、判断の種類が混ざる問題でした。

そこで、定期ジョブの機械通知は専用チャンネルへ隔離し、人に判断を求めるレーンと分けました。正常時は静かにし、失敗時だけ知らせる仕事も増やしました。結果として人間が見るべきものは、「記録として残す報告」ではなく「いま判断が必要な例外」に近づきます。

通知を減らすと不安になるかもしれません。しかし、監視をやめたわけではありません。機械が読む記録は残し、人間の注意だけを節約します。この分離ができないと、AI社員を増やすほど人間の受信箱が忙しくなり、自動化の効果を確認作業が打ち消します。

並列化で速くなり、同時編集で事故が起きた

教訓6：仕事ではなく「所有するファイル」まで分ける

複数のAI社員を並列で動かすと、独立した仕事は早く進みます。一方、同じファイルを同時に触らせると、片方の変更がもう片方の変更を上書きする事故が起きます。「記事担当」「開発担当」と大きく分けるだけでは足りませんでした。

今は、誰がどのファイルを担当するかを先に分け、同じ対象にはロックを持たせます。同じ目的に向かう作業でも、編集対象が重なるなら順番に通す。並列にするのは、互いの成果物を上書きしない仕事だけです。

この考え方はAI社員固有ではありません。GitHub Actionsの公式ドキュメントでも、並列実行が衝突や資源消費を招く場合に同時実行を制御し、必要に応じて順番待ちさせる仕組みが説明されています。Uravationでは、それをジョブ単位だけでなく、担当ファイルの所有権にも当てはめました。

並列エージェントの仕組みや使い分け自体はサブエージェントの並列活用ガイドで扱っています。本稿の実録として残したいのは、「並列にできる」と「同時に触って安全」は別だという一点です。

コストの本丸は、トークン代より確認待ちだった

教訓8：安い実行を増やしても、人の検品が増えれば止まる

AI社員のコストを考えるとき、最初に目が向くのはトークン代です。もちろん、利用量の把握は必要です。ただ、61体を実運用して見えたボトルネックは、AIが処理する費用より、人間が成果物を一件ずつ開いて確認する時間でした。

AI社員が増えると、原稿、調査、書類、点検結果、下書きが同時に上がってきます。人間がすべての一次検品者になると、AI側の処理が終わっても確認待ちの列が伸びます。ここで「AIは速いのに、なぜ仕事が終わらないのか」という逆転が起きました。

そこで9体のAIマネージャーを、采配だけでなく関所として置きました。部下AIの成果物をマネージャーが先に検品し、人間に渡す前に不足、形式違い、停止条件への抵触を見ます。人間は、外部送信や公開などの最終承認と、マネージャーが判断できない例外へ集中します。

これは、人間の確認をゼロにする設計ではありません。人間の確認を、責任が伴う場所へ寄せる設計です。トークン代を細かく削るより先に、誰が何回見るのかを可視化したほうが、運用全体の詰まりを見つけやすくなりました。

なお、Uravationの61体運用にかかる月額総額は、2026年8月時点で公式に確認できる公開値がないため、本稿では記載しません。公開できる実録上の結論は、具体額ではなく「確認時間が先にボトルネックになった」という点です。環境、モデル、実行頻度が異なる他社へ、そのまま同じ費用感を当てはめることもできません。

61体への入口は、営業ではなく定型業務だった

教訓9：最初の1体は「毎日必ず発生する仕事」から選ぶ

いま61体いるからといって、最初から複数部門へ広げることを勧めているわけではありません。実運用から言えるのは、最初の1体は、毎日必ず発生し、入力と出力を言葉にしやすい定型業務がよいということです。

いきなり営業や対外送信を任せると、成果の評価に加えて、相手との関係、文面のニュアンス、送信責任まで一度に扱うことになります。それでは、AI社員の問題なのか、業務設計の問題なのかを切り分けにくくなります。

反対に、会議前の準備、受信内容の仕分け、定期的な点検のように、発生条件と完了条件が見える仕事なら、職務記述書の不足を発見しやすくなります。まずは「毎日ある」「終わった証拠が見える」「外部送信を伴わない」の三つが重なる業務で、停止線と検品を試す。この順番が、最初の1体を長く働かせるうえで現実的でした。

自社の業務を職務記述書へ落とす材料が必要なら、無料のAI社員構築スターターキットに、業務棚卸しと職務記述書のテンプレートをまとめています。自社で作る時間が取れず、停止線や監視を含めて設計したい場合は、AI社員構築代行の案内も確認できます。どちらも、いきなり外部送信を任せる前提ではありません。

9つの教訓を、変更した運用ルールで見直す

AI社員61体の運用についてよく聞かれること

61体を最初から同時に作ったのですか？

いいえ。本稿の教訓は、最初の1体を毎日発生する定型業務に置くことです。現在の61体という数だけをまねるのではなく、担当業務、入力、出力、止まる条件を言葉にできる1業務で、実行と検品が回るかを先に見ます。

AIマネージャーが最終決定まで行うのですか？

行いません。AIマネージャーの役割は「采配と関所」です。部下AIへ仕事を振り分け、成果物を検品します。メール送信、SNS投稿、公開、本番反映の最終承認は人間が持ちます。

AI社員の「完了」は何を見ればよいですか？

報告文ではなく、その仕事に応じた完了証拠を見ます。Uravationでは、成果物の実在、処理ログ、反映先の現在状態を確認します。すべてを毎回人間が見るのではなく、検品担当AIが先に確認し、責任を伴う箇所を人間へ渡す形も使います。

運用コストはトークン代を見れば足りますか？

足りません。Uravationの実運用では、トークン代より人間の確認時間が先にボトルネックになりました。モデル利用費だけでなく、誰が何回検品するか、どこで承認待ちになるかを見ないと、全体コストを捉えられません。具体的な月額総額は公開値がないため、本稿では推測しません。

最初の1体に営業メールを任せてもよいですか？

Uravationの運用知見では、最初から営業や対外送信を任せません。まずは毎日発生し、完了証拠が見え、外部送信を伴わない定型業務で、職務記述書、検品、停止線が機能するかを確かめます。

参考・出典

• AI社員一覧 — 株式会社Uravation。61体、9部門、AIマネージャーと各AI社員の公開役割を確認（参照日：2026年8月31日）
• 株式会社Uravation公式サイト — 61体・9部門で稼働中という現在表示を確認（参照日：2026年8月31日）
• How Claude remembers your project — Anthropic。CLAUDE.mdとメモリの公式仕様を確認（参照日：2026年8月31日）
• A practical guide to building agents — OpenAI。ガードレールと人間介入の考え方を確認（参照日：2026年8月31日）
• Concurrency — GitHub Docs。並列実行の衝突を避ける同時実行制御を確認（参照日：2026年8月31日）
• AI事業者ガイドライン第1.2版 — 経済産業省・総務省。AIガバナンス、モニタリング、活用資料の最新版を確認（公表：2026年3月31日、参照日：2026年8月31日）
• AI Risk Management Framework — NIST。AIの設計、利用、評価を通じたリスク管理の公式枠組みを確認（参照日：2026年8月31日）

結論：61体を支えたのは、賢さより停止線だった

AI社員61体の運用でわかったのは、数を増やす前に、仕事の境界と完了証拠を増やす必要があるということでした。職務記述書に書いたことだけを担当させ、「できました」を実物で検品し、外部操作の承認を人間に残す。失敗をメモリへ戻し、静かな失敗を監視し、同じファイルを同時に触らせない。これらは派手な機能ではありませんが、毎日止めずに動かすために残ったルールです。

自社へ持ち帰るなら、次の三つで十分です。

1. 毎日発生し、外部送信を伴わない定型業務を一つ選ぶ
2. 担当業務・入力・出力・止まる条件を一枚の職務記述書にする
3. 「できました」の代わりに、何を見たら完了かを決める

AI社員の全体像から確認する場合はAI社員とは何かの解説、自社での組み立てへ進む場合はAI社員の作り方を続けて読めます。実装を任せたい場合だけ、AI社員構築代行をご覧ください。

著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。
100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』（SBクリエイティブ）。
SoftBank IT連載7回執筆（NewsPicks最大1,125ピックス）。