DeNAがAI社員を本番運用へ　Berry先行展開と権限分離の実装

編集: グリットアーツ編集部

公開日：2026年10月12日

3行解説

ニュースの概要

DeNAは2026年8月4日、社内で進めている「AI社員」の取り組みを技術記事で公開しました。AI社員は、Slack上の専用チャンネルに常駐し、名前とアイコンを持ち、部署に配属され、質問対応や日報作成などを担うAIエージェントです。初号機のLemonで検証した後、現在はBerry、Melon、Plumをはじめとする複数のAI社員を、IT本部内の各部署へ展開しています。

記事では、機能追加のリリースフロー、共通ファイルと固有ファイルの分離、参照機能から書き込み機能への段階拡張、稼働状況やROIの可視化など、実運用の仕組みが説明されています。Berryは会計システムの開発・保守チームに配属され、先行検証役としても使われています。

何が新しいのか

新しい点は、AIを単なるチャットツールではなく、部署に配属された同僚として扱う運用設計を、実際の社内業務に落とし込んでいることです。Lemonでの実証を踏まえ、現在はBerryを先行検証役にして、影響の小さい変更はまずBerryで試し、書き込み系や設定変更のような影響の大きい変更は、dev環境から本番のBerry限定展開へ進めています。

また、設定管理も特徴的です。ペルソナ定義やツールのアクセス情報、社内ポリシー参照先などの共通ファイルはreadonlyにし、チーム固有ルールや長期記憶などは固有ファイルとして分けています。これにより、全体の統制を保ちながら、部署ごとの育て方を残す構成になっています。

さらに、成果の見える化も進んでいます。Berryでは、8営業日で約52.6時間の削減が示され、Jira、Slack、Confluenceを横断して情報を集約する使い方も確認されています。AIを入れた結果を「便利だった」で終わらせず、利用回数や削減時間まで追っている点が、実運用のニュースとして重要です。

グリットアーツ編集部の分析

この記事で実務上の価値が高いのは、Berryを先行検証役にしている点です。AIエージェントは、参照だけなら比較的導入しやすい一方、Jira起票や設定変更のような書き込み系は、誤操作がそのまま業務影響になります。DeNAはそこを分け、影響度に応じて展開順を変えています。これは、AI基盤を本番運用する際の現実的な安全策です。

もう一つ重要なのは、共通ファイルと固有ファイルを分離していることです。共通設定を一括で直せる一方、各AI社員の長期記憶やチーム固有ルールは壊しにくい。複数エージェントを増やすほど、設定の一元化だけでは運用が崩れやすくなるため、この分離は保守性に直結します。AIを増やすほど、モデル性能よりも運用設計が差になることがよく分かる事例です。

日本の現場で考えると

日本企業でこの方式を入れる場合、まず課題になるのは「誰の業務を、どこまでAIに任せるか」の線引きです。Slackや社内文書を参照するだけなら受け入れやすいですが、チケット起票、会議調整、設定変更まで広げると、権限管理と監査の設計が必要になります。特に、部署ごとに運用ルールが違う会社では、共通設定と個別設定の分離がないと展開が止まりやすいでしょう。

向いているのは、問い合わせ整理、ナレッジ集約、定型の起票や集計のように、手順が比較的明確な業務です。一方で、例外処理が多い業務や、承認責任が重い操作は慎重に見るべきです。AI社員を「人に近い形」で扱うなら、利用者教育やオンボーディングも必要で、個人アカウント連携型のAIツールとは別物として説明する手間がかかります。

導入・検討時に確認したいこと

• 参照だけの機能と、書き込み系の機能をどう分けて段階導入するか。
• Berryのような先行検証役を置く場合、合格条件と観察期間をどう決めるか。
• 共通ファイルと固有ファイルの権限を、誰がどこまで変更できるか。
• 操作ログ、異常動作検知、権限コントロールをどう監査に耐える形で残すか。
• 利用回数や削減時間を、ROIとしてどう集計し、継続判断に使うか。

現時点で分かっていないこと

記事からは、AI社員の利用コストの具体的な増え方や、障害時の停止条件は分かりません。また、どの程度の権限までを標準化しているか、部署横断での展開ルールをどこまで自動化できているかも未確定です。今後の運用拡大では、このあたりが導入判断の分かれ目になります。

AIエージェントを業務に組み込むには、機能より先に運用設計が問われます。自社のAI基盤や権限管理、段階導入の進め方を整理したい場合は、検討材料として読み替えてみてください。

出典: DeNA Engineering