みなさんこんにちは、プラットフォーム開発本部第1開発部CSプラットフォームグループ（以降：PF開発本部、CSP）の渡部 @tenki_develop です。
PF開発本部はDMM内の会員基盤やレビュー基盤など、多くの事業部にて使用する共通基盤を提供することがミッションです。
私たちのPF開発本部では、AIの活用を部内全体で推進するAX 戦略（AI Transformation） が副本部長兼第1開発部部長・石垣さんから発表されました。目標は 「人でやっていた業務の50%をAIに置き換えた（協働）うえで、開発リードタイムへの変化を観測する」 ことで、そこから複数のプロジェクトが派生しています。
現在は以下の５件のプロジェクトが進行しています。
| プロジェクト | 概要 |
|---|---|
| pj-inq_automation | 本記事 |
| prj-doc_as_code | コードとドキュメントの距離を近くし、AIリーティングしやすい状態にする |
| pj-ai_cost | AIコストの見える化と計測を行う |
| pj-vibe_coding | AIスキルの標準化・育成を行う |
| prj-ai-pdm_pm_mg | PdM/PM/開発マネージャー領域のAI活用 |
私 (渡部) は pj‑inq_automation と pj‑doc_as_code に参加し、活動を進めています。
今回は、pj-inq_automationで実際にローンチした内容について、プロジェクトの概要や効果などDMMらしいAXの開発をご紹介できればと思います。
pj-inq_automationとは？
記事の冒頭でPF本部の役割についてご説明しました。次のスライドでは具体的な基盤の詳細について紹介します。
このように、PF本部が開発する共通基盤は関係する部署も多く、他の事業部のエンジニアから要望や質問を多数いただきます。 その結果、問い合わせ先のチームや緊急度に応じてワークフローが増え続け、最終的に合計 23 個 の質問・要望を受け付けるワークフローが存在していました。これは初めてPF本部に問い合わせを行うエンジニアにとって、非常に大きな心理的ハードルとなっていました。
そこで「AI の自動分類を用いてワークフローを一本化し、問い合わせ対応後のフィードバックも AI で完結できるようにする」ーーそんな構想でpj-inq_automationプロジェクトがスタートしました。
プロジェクトの概要
プロジェクトがどのように進んだか、赤裸々にご紹介します。
与えられたミッション
問い合わせ対応の時間を短縮し、事業部・PF開発本部のメンバーが本来の開発業務に集中できる時間を増やすこと
課題感
- 使用するワークフローが多い（23個）
- ワークフローごとに記載内容に微妙な差がある
- Aチームの問い合わせだと思ったら、実はBチームの持ち物だったことが判明し、たらい回しが発生する
- 初期対応完了までの時間がチームによって差がある
- お問い合わせ終了の定義が曖昧で、担当者と起案者の認識齟齬が発生している
PF開発本部の組織規模
PF 開発本部は 200 名以上の組織です。プロダクトごとに PdM が配置され、エンジニア同士は横断的につながり、DMM 内の要望や技術課題を迅速に解決しています。
日程感
スピード感重視のプロジェクトでした。
| 日付 | 工程内容 |
|---|---|
| 04/04 | プロジェクトキックオフ |
| 05/20 | ファーストリリース |
| 06/11 | 本格運用開始 |
今回作成したSlackBot
今回私たちが作成したSlackBotをご紹介します。Tenjin（天神） です。
Technological Entity Navigating Journeys Into Novelty.
（新たな世界への旅路を導く、技術に裏付けられた知性体）
の意味をとってTenjinと名付けました（ちなみに名付け親は私です）。
基本的な応答機能のほか、以下の機能を備えています。
| 機能カテゴリ | 概要 |
|---|---|
| Slackコマンド | ヘルプ表示機能 |
| 集計機能 | お問い合わせ情報を収集 |
| 特定の業務専用の実行 | 分類機能 / 評価機能 など特定のタスクフローを呼び出すことが可能 |
| 外部 API／MCP 連携 | （※ 現在は API のみ） |
など、汎用性の高い機能を持っています。
PRJのメンバー構成
| 役割 | 人数 |
|---|---|
| 運用チーム | - MG 1名 - 外部調整 / LLM精度調整 / プロンプトエンジニア 2 名 |
| エンジニアチーム | - MG 1名 - SlackBot / LLM / インフラエンジニア 1 名 （私はこちらです） |
計 5 名で、実装・精度調整・改善サイクルを回しています。
メンバーはプロジェクト当初からこちらの5名で実施しております。
１名のエンジニアがフルスタックで開発＋AIプロンプトチューニングなどのサポートも実施しました。
プロジェクトがもたらしたもの
ワークフローの選択が不要に
23個のワークフローができてしまった原因として、各チームの問い合わせ窓口と緊急事態用のワークフローなどをユーザー側に選択していただいた方が、早く連絡が取れるという理由で増加の一途を辿りました。しかしながら、管理やメンテナンスでは各チームに依存が発生し、全チームで安定したユーザー体験の一貫性を十分に確保できていない状況でした。
本PRJにてAIが問い合わせ内容の振り分けを自動的に行うワークフローへ一本化することで、特定チームの連絡以外でも統一的な問い合わせ対応が可能になりました。また、複数チームに跨ぐ問い合わせの場合は、AIが自動的に複数チームに振り分けすることにより、内部での連携もしやすい環境となりました。
また、利用者からの要望に応じて、リリース以後も以下の改善を行いました。
- 関係者欄の追加
- 記入して欲しい内容の明確化（説明の明確化）
ワークフロー中の必要事項がしっかりと記入されていれば、LLMが1つもしくは複数グループへ連絡を自動的に送信してくれます。こうして運用していく中で、ワークフローの完成度とAI分類の精度は比例する関係だったということが実感できました。
LLMを活用する最大のメリット
最大のメリットとして、ユーザー体験の向上とPF内部での効率化が挙げられます。
問い合わせユーザーにとって、1つのワークフローでPF開発本部のプロダクトチームに網羅した連絡ができる。PFメンバーにとっては、問い合わせの対応に集中ができる。また、問い合わせ終了後にAIによる評価をみて不足していた点などをセルフマネジメントができるという環境を構築できました。
AI活用にあたり、まず既存フローをすべて調査をしました。その結果、下記のような偶発的な発見がありました。
課題として....
- お問い合わせの窓口（Slackチャンネル）が複数あった
- PFとして対応が遅れているケースがあった
- クローズの定義が曖昧で認識齟齬が発生していた
ということを確認できました。
こちらに対しても、AI化する時に一緒に対応しました。
AXはプロセスを"AI"に置き換えるのではなく、"AI"前提のプロセスに作り変えるという点も目標にあったため、AI化にあったワークフローに変更するためいくつかの変更を実施いたしました。具体的な手法については下記に列挙いたします。
ガイドラインの策定
フローの再構築に伴い、問い合わせに対して「どのように対応するか？」 を明文化しました。 こちらは運用チームの方にお願いをして、SlackBotにて将来実現できる部分を含めたガイドラインを策定いただきました。
時系列としてはほぼ同じ時系列で動いていたのですが、ガイドラインが先で実装が後という流れでした。
これまでは問い合わせ先の案内が不明瞭だったのですが、こちらのガイドラインにて、問い合わせをするチャンネルを明確に定義しました。これにより利用者側の皆様に「ここに問い合わせれば問題ない！」という安心感をご提供できました。
クローズ定義問題
質問者が解決したタイミングでクローズできるよう、スレッドにクローズボタンを配置しました。
これまではPFメンバーが確認依頼を利用者に行い"「問題ない」"という返答をいただいた後にクローズするという流れで運用していました。しかし、利用者の方の返信忘れなどによりクローズできないままのチケットが散見されていました。今回の変更により、PFメンバーが確認依頼を行わずとも、利用者がクローズすると自動でチケットが閉じられます。
統計情報の分析・レビュー
週次にて分析を行うフローを実施しております。
緑は解決済み、赤は要確認、白は進行中を示します。
今後は、強制的に自動クローズなどのサポート機能を充実していく予定になっております。
集計日・締め日の関係上約 60% の解決率となっております。
こちらの集計をもとに、現在は以下のような新しい施策を検証運用中です。
- 問い合わせのクローズの確認合意が取れてなく長期間Openとなっている問い合わせが存在している
- 自動クローズの導入
- PF側の担当者の一次対応がガイドライン範囲より伸びている
- 自動通知の導入
精度保証について
SlackBotでの分類はワンショットプロンプト + Structured Output にて対応しております。
各チームの役割を書いたプロンプトが鍵で、初期はエンジニアが作成し、現在は運用チームへ移管済みです。
Google スプレッドシート管理により、メンテナンスを運用チームでも実施できるようにしています。
コスト感
本PRJにおいてのコスト感になります。
リリースまでのコストは以下のとおりです。
- 人的コスト
- エンジニア 1 名：初期導入 250 時間
- 運用チーム 2 名：初期導入 120 時間／週次対応 2 時間 - 基盤運用コスト（～2025/06/19）
- Azure：5,210 JPY
短納期を実現できた要因
いくつか大きな要因があります。大きく 2 点に分けてご紹介します。
技術的背景
私が所属しているCSPでは2023年にAzure OpenAIを用いた電話要約の環境を作成いたしました。現在は要約・分類や細かなアップデートなどを実施しております。
先日、東日本リージョンでGA（一般公開）したAzure Functions Flex Consumption Planに合わせたリライトを進めつつ、GPTモデルのメジャーアップデートを継続的に行っています。
今回はCSPにてAIのナレッジを、本PRJの問い合わせ自動振り分けAIにも活用できました。
しかしながら、今回のキーとなるSlackBotにおいては、開発当初は試行錯誤を重ねていました。
そこで、弊社内でSlackBotの最先端を走っているチームである博士チームの知見をお借りしました。
具体的には、必要な知識の習得をするため博士チームのコードやノウハウを勉強をする時間を1週間程度とりました。
Slack上にて疑問点を相談させていただくなど、お忙しい中対応をいただきました。博士チームの皆様、ありがとうございました。
実装面では、ミノ駆動さんから学んだ「変更容易性の高い設計」を活用しています。
developersblog.dmm.com
キーワードは AICospa（AI × Cost Performance）で、最小工数で価値を最大化することを意識しました。本プロジェクトも、実はAI エージェントにこだわらず、レガシーなワンショットプロンプトで実現しています。
以上のような形で、本プロジェクトをメインで進行しました。普段のCSP業務も継続しながらのプロジェクトだったため、２足の草鞋を履きながらの実施は大変でしたが、結果として多くの社員の生産性の向上に繋がったため、大きな達成感を感じました。
環境的背景
内部で運用していた23個のワークフローを1つに統合し、集計や品質向上へつなげる大きなアクションでした。
そのため MGレイヤーでは事前に多くの調整を要したものの、PF内部へ相談すればおおむね3営業日以内に回答を得られる迅速なご対応により、進行を大きく後押しできました。
（PF開発本部長からは、 ”将来的にはさらに迅速な連携を目指したい” とのコメントがありました）
月曜日に定例ミーティングを行っていますが、プロジェクト外の調整が必要な場合はおおよそ水曜日までに回答をいただいております。PF内でもご注目いただき、多大なご協力をいただきました。
エンジニアとして参画した私も、修正・改善が必要な箇所があった際には当日中、遅くとも翌営業日までに対応してリリースしました。スムーズにご利用いただけるよう努めております。
1ヶ月という短期間でファーストリリースにこぎつけられたのは、関係者の皆さまの知見とご協力のおかげです。また、エンジニアだけでなく実際に運用を担当するチームもメンバーとして参画したことで、エンジニアが開発に集中できる環境が整いました。あらためて、ご協力いただいた皆さまに感謝申し上げます。
今後に向けて
将来的にはAI Agentへ移管し、MCPやDocsAsCodeとの連携を見据えて複数プロジェクトに参画しています。
特にDocsAsCodeと連携をすることにより、人による一時回答や追加質問をAI Agentにて実施できればと考えております。最終的なゴールとしては、AIにて代行可能な部分を代わってもらい、人でしかできない価値を深めていくことになります。一人一人の生産性向上だけではなく、より人らしく価値を発揮できるためのパートナーとしていくべきと考えております。
今後につきましてぜひ続報をお待ちください🚀
まとめ
AIが実業務と高い親和性を発揮できる今日、AIありきの業務へ変化するためのプロジェクトに参画したことで、多くの知見を吸収できました。
- AX化するために既存業務の洗い出しができた
- 数値取得において共通の計測環境の構築ができた
- 利用者にとって共通の問い合わせ環境ができた（最大の価値）
今後に向けて
- プロジェクト連携において必要な下地ができた
- DocsAsCodeのフロント側の口として利用
- 自己解決までサポートする
今後は引き続きAX化について尽力するとともにDMMの組織にどんどん還元できたらと思っております！
