DeNAがPC手配業務をAIで整理　要件定義から開発依頼までの進め方

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

公開日：2026年9月30日

3行解説

ニュースの概要

DeNAは2026年9月28日、社内のPC手配業務をAIと進めた取り組みを公開しました。対象は、申請受付から端末準備、資産台帳登録、利用者への引き渡しまでの一連の流れです。記事では、年間およそ2,000件の手配を扱うチームが、現状分析、ToBe設計、設計レビュー、開発依頼、切り替え段取りまでをAIと分担した経緯を説明しています。

何が新しいのか

新しい点は、AIを「文章を作る道具」としてではなく、業務改善の各段階で役割を変えて使っていることです。現状分析では社内ツールで業務フロー図を起こし、設計ではGeminiにホワイトボード写真を見せて意見をもらい、実装に近い段階ではClaude CodeとkintoneのMCPで本番のフィールド構成を読み取っています。さらに、GitHubとConfluenceも参照して開発依頼のチケット化まで進めています。

また、AIの指摘を受けて設計を見直した点も重要です。表計算ファイル連携の危険性、住所未入力時の督促方法、個人情報の分離など、運用で詰まりやすい論点が具体的に表面化しました。単なる自動化ではなく、業務の抜けや属人化を減らすための見直しに使っている点が、この事例の新しさです。

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

この事例で注目すべきなのは、AIが本番システムに触れる前の整理と、実システム接続が必要な段階を分けていることです。前半はチャットや画像入力で要件を固め、後半はkintoneのMCPで読み取り専用接続を使っています。導入判断では、この切り分けが重要です。業務整理だけなら始めやすい一方、実データや権限が絡むと、接続範囲と責任分界を先に決めないと運用が崩れやすいからです。

さらに、AIのレビューで「運用担当者の体がもちません」と指摘されたように、改善の成否は自動化率だけでは測れません。住所未入力の督促をSlack Botに寄せる、個人情報を別アプリに分けるといった変更は、現場負荷と情報管理の両方を見た結果です。日本企業の情シスでは、便利さよりも、誰が毎日見るのか、どこまで自動で止めるのかを先に決めるほうが実装しやすいと考えられます。

日本の現場で考えると

このニュースは、PC手配のような情シス業務だけでなく、申請、発注、台帳管理が別システムに分かれている現場に向いています。特に、担当者の経験に依存している業務や、転記が多い業務では、AIでフローを見える化する効果が出やすいでしょう。一方で、社外の取引先が自社システムに入れない場合や、個人情報を扱う場合は、AIで設計を詰めても接続方法そのものは別途考える必要があります。

また、切り替え時の段取りを事前・直前・当日・開始後に分けた点は、日本の現場では特に参考になります。新しい仕組みを入れても、古い申請フォームや案内が残ると混乱が起きます。自動化の検討では、業務そのものだけでなく、移行期間の案内、督促、例外処理まで含めて設計することが重要です。

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

• AIに任せる範囲は、要件整理までか、実システム接続までか。
• kintoneや既存台帳など、読み取り専用でつなぐ対象は何か。
• 社外の取引先が入れない前提で、どこを手作業に残すか。
• 個人情報を分ける場合、権限設計と運用手順をどうするか。
• 切り替え時に、古い申請経路をいつ止めるか。

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

記事では、改善後の実運用がどこまで定着したかはまだ明示されていません。また、Slack Botによる督促や個人情報分離の変更も、本文では「まだ動いていない」とされています。AI接続の範囲や、MCPを使った読み取り専用運用の詳細な制約も、導入判断には追加確認が必要です。

AIを業務整理に使うだけでなく、実システム接続や権限設計まで進めるときは、既存環境とのつなぎ方が重要になります。自社のIT運用でどこまで自動化できるかを考える材料として、周辺システムとの関係も含めて見直す価値があります。

出典: DeNA Engineering