AIを「同僚」として組織に迎える ─ 果物の名を持つDeNAのAI社員たちと、その実装の裏側

はじめに

こんにちは、IT本部IT戦略部の小山です。DeNAで「AI社員」という取り組みを進めています。

「AI社員」と聞くと、チャットボットや業務自動化ツールを大げさに呼んでいるだけなのでは、と思う方もいるかもしれません。私たちが取り組んでいるのは少し違います。Slack上の専用チャンネルに常駐し、名前とアイコンを持ち、部署に配属され、予定されたタスクをこなし、チームメンバーからの質問に答え、一日の終わりに日報を書く——人間の同僚と同じような形で組織に組み込まれたAIエージェントを、社内では「AI社員」と呼んでいます。

この取り組みには初号機の「Lemon」という存在がいました。2026年3月6日に開催された自社イベント「DeNA × AI Day 2026」で、当時代表取締役会長（現・代表取締役社長）の南場智子が「『ここに入れないで、ここに入れろって言ったでしょう！』、なんて毎朝結構けんかしている」と紹介したことで話題になった存在です。ただ、この記事の主眼は懐かしのLemonではなく、Lemonの学びを踏まえて現在稼働しているBerry・Melon・Plumをはじめとする複数のAI社員、そしてそれらを各部署に展開していく体制の話です。「AI社員をどう組織に実装していくか」という、私たちがここ数ヶ月で試行してきたことをまとめてみます。

原点にいた「Lemon」

最初に生まれたAI社員がLemonでした。Lemonは「AIエージェントを組織の一員として業務に組み込む」というアイデアを検証するための、いわば実証機です。Googleアカウント・Slackアカウントを持たせてIdentity(システム上の人格)を与え、実際にSlack上で声をかけられて反応する、というところまでをひととおり試しました。

Lemonについて「人間の新入社員の育成と同じ手法を採用している」という考え方を採っていました。IDの割り当て、就業規則の習得、部門別のオンボーディングといったプロセスを経て一人立ちさせる、というものです。この検証を通じて、「就業環境の構築」「基礎研修（会社のルールを学習させる）」「業務研修（業務ドメインの知識を学習させる）」といった、AI社員を1人立ち上げるためのプロセスの土台ができました。今のBerryたちの入社フローは、このLemonの経験の上に成り立っています。

今の展開状況：フルーツの名前を持つAI社員たち

現在、社内では複数のAI社員がフルーツの名前を与えられ、それぞれ実在の部署に配属されています。名前とアイコン（Slack上のプロフィール画像として、共通の画風でフルーツごとに作成）を持たせているのは、単に親しみやすくするためだけではなく、AIエージェントを人間の同僚と同じように「Identity（人格）を持つ一人」として扱いたいという考え方によるものです。

このプロジェクトはもともとIT本部発の取り組みで、展開もまずIT本部内の各部署が中心です。最初にBerry（社内の会計システムの開発・保守を担うチームに配属）・Melon・Plumの3体が、調達・コーポレート業務を担う部署からスタートし、そこからKiwi・Peach・Oliveといった名前でIT基盤を担う部署や品質管理を担う部署へと横展開が進んでいます。

運用の仕組み・工夫している点

AI社員を「作って終わり」にせず組織に定着させていくために、いくつかの仕組みを整えています。

機能追加のリリースフロー

AIエージェントは、最初から完璧な形で作り込むのが難しく、実際に業務で動かしてみないと見えてこないことが多いプロダクトです。だからこそ私たちは、慎重になりすぎて足を止めるのではなく、小さく早く試しながら安全に広げていく、というスピード感を大事にしています。新しい機能（新しいツール連携、プロンプトの変更、定期実行タスクの追加など）を加える際は、影響度に応じたリリースフローを敷いています。

• 影響が小さいもの（システムの参照・検索など）：Berryで軽く動かしてみて問題なければ、そのまま他のAI社員へも展開

• 影響が大きいもの（書き込み系の操作、AIの動作設定そのもの、インフラ変更）：「dev環境で検証 → 本番のBerryだけに限定展開 → 一定期間の観察 → 問題なければ他のAI社員全体へ展開 → 利用者への周知」という段階を踏んで展開

Berryが実質的に「先行検証役」になっており、数営業日問題なく動いた機能から他のAI社員へ広げる、という安全弁を設けています。

共通ファイルと固有ファイルの分離

AI社員が増えてくると、それぞれの設定ファイル（ペルソナ定義やツールの使い方、社内ルールの参照先など）の管理が課題になります。そこで私たちは、共通ファイルを更新しても各AI社員が個別に育ててきた固有ファイルを壊さないよう、両者を明確に分けて管理しています。

• 共通ファイル（readonly）：ペルソナ定義、ツールのアクセス情報、社内ポリシーの参照先、共通スキルなど。共有のファイルシステムから読み込み、AI社員自身は書き換えられません。

• 固有ファイル（各AI社員が編集可）：チーム固有のルール、AI社員ごとの基本情報（名前・所属チーム・メインチャンネルなど）、長期記憶、業務手順など。各AI社員（実質的には配属先のチーム）が自由に育てていく部分です。

機能は段階的に拡張していく

AI社員に持たせる機能も、最初から一気に広げてはいません。まずはGoogle DriveやConfluenceといった社内システムを「参照」できる機能だけを持たせて実際の業務で使ってもらい、実力を見ながらJiraのチケット作成やConfluenceページの更新といった「書き込み」機能を段階的に追加していく——1体を鍛えるのではなく、プロジェクト側が機能セットそのものを拡張していく、というアプローチです。

稼働状況・成果の可視化

AI社員が「実際どれくらい役に立っているか」を可視化するため、日報・週報の仕組みを作っています。1日あたりの利用回数・利用ユーザー数・ツールの使用状況、そして削減できた作業時間（ROI）を、AI社員自身が集計してレポートします。この可視化自体も定期実行タスク（cron）の1つで、Berryは現時点で20個ほどのcronを無人で回しています。大きく分けると、

• 問い合わせ・監視系：業務システムのエラー通知の検知、対応が止まっている問い合わせの検知など

• 起票・集計系：日々の問い合わせのチケット化、利用状況やROIの集計・レポート化など

• 月次業務：月次の会議準備やスケジュール調整など

• 運用メンテ系：その日の業務予定を立てる、失敗や見落としを振り返る、cronとカレンダーの不整合を直すなど、AI社員が自分の運用を自律的に見直す仕組み

平日を中心にこれらが無人で走っており、とくに「運用メンテ系」は地味ながら自律性を支えている部分だと感じています。

コンセプトの伝わりにくさとオンボーディング支援

一般的なAIツールは、利用者個人のGoogleアカウントやSlackアカウントと連携させて使うものが多いと思います。一方でAI社員は、個人に紐づく道具ではなく、部署に配属された「人格を持つ一人の新入社員」として扱う設計です。この違いは受け入れ部署にはなかなか伝わりにくく、「自分のGmailやカレンダーをAI社員に直接連携させたい」といった、個人アカウント連携型のAIツールの感覚に基づく要望が出てくることがあります。

そのため新しい部署へ受け入れてもらう際は、私たち（AI社員プロジェクトチーム）が受け入れ部署とのオンラインMTGでコンセプトを説明し、導入後もその部署のチャンネルに加わって都度フォローする体制を敷いています。ただこれは展開スピードを優先した人力対応であり、部署が増えるほど立ち行かなくなるのが正直なところで、コンセプトの伝え方自体の型化・自動化は今後の課題です。

導入で見えてきた効果・学び

もっとも稼働実績が積み上がっているBerryの例で言うと、ある週（2026年7月1日〜10日の8営業日）では、削減時間の合計が約52.6時間という結果が出ました。日々のばらつきはあるものの、平均すると1日あたり6〜8時間分の業務がBerryに置き換わっている計算になります。

具体的な業務内容としては、

• 経理システムのエラー通知を受け取り、内容を確認してサポートチケットを起票し、対応が完了したものをクローズする

• 複数部署にまたがる問い合わせ内容を切り分けて、適切な担当への振り分けやチケットの集約を行う

• Jira・Slack・Confluenceといった複数のツールに散らばった情報（あるテーマについて、Jiraだけで200件超、Slackで2,700件超）を横断的に集計し、構造化されたナレッジページとしてまとめる

といったものが挙がっています。人間が「調べて、まとめて、起票して、クローズする」という一連の作業を任せられる、という感触が徐々につかめてきた段階です。

一方で、学びもいくつかありました。定期実行タスクの一部が想定外のデータ形式でエラーになることがあり、無人で回している分、エラーの検知や復旧の仕組みも合わせて育てていく必要があると実感しています。「1体をうまく動かす」ことと「複数体を同じ品質で運用し続ける」ことの間には、地味だけれど無視できない差があります。

今後の展望

現在はIT本部を中心に展開が進んでいますが、今後はより多くの部署・業務領域にAI社員が広がっていくフェーズに入っていくと考えています。展開が進むほど、まだ見つかっていない業務のユースケースを各部署で発掘していくこと自体が、これからの重要なテーマになってきます。そのために、AI社員自身が日々の業務ログからユースケースを分析し、他部署のAI社員へ横展開できる形で共有する仕組みを現在作成中です。

同時に、AI社員を無人で動かす時間が増えるほど、内部の運用改善も欠かせません。

• 異常動作の検知（想定外の挙動をどれだけ早く見つけて止められるか、という仕組みづくり）

• 利用コストの管理（AI社員が増えるほど、モデル利用料や実行基盤のコストも積み上がっていく）

• セキュリティ・ガバナンス（操作ログの管理、権限のコントロール）の整備

• AI社員自身の評価サイクルの確立

• 「何人日分の業務を代替できているか」という、より人事的な観点でのAI社員の位置づけ

といったテーマにも、今後さらに向き合っていく必要があると考えています。

まとめ

AI社員というコンセプトは、ともすればバズワード的に聞こえてしまいます。しかし実際に手を動かしてみると、その本質は技術的な目新しさではなく、名前を持たせ、部署に配属し、段階的に権限を与え、成果を可視化するという、人間の新入社員を受け入れるのとほぼ同じプロセスを、地道にAIに対しても敷いていくことにあると感じています。派手なデモよりも、こうした「組織への実装」の積み重ねこそが、AI社員を単なるツールではなく組織の一員にしているのだと思います。

Lemonという原点から、Berry・Melon・Plumをはじめとする複数のAI社員へ。この展開はまだ道半ばですが、進捗があればまた記事にしたいと思います。