DeNAの1on1をAIで支援 - 新卒チームが開発した「すごマネ」の挑戦

はじめに

はじめまして、新卒エンジニア研修にて「1on1 支援ツール “すごマネ”」のプロダクトオーナーを務めた八尋です。

本記事は、主に以下のような方々に向けて書いています。

効率的な 1on1 の進め方や声掛けに悩んでいる方
1on1 に対する AI 搭載サービスのアプローチを知りたい方
「AI オールイン」を掲げる弊社で、新卒が開発した AI サービスを知りたい方

この記事では、私たち新卒チームが約 2 ヶ月かけて開発した AI 支援ツール “すごマネ” をご紹介し、上記のような課題意識やご関心に順番にお応えしていきます。企画の背景から技術的な挑戦まで、私たちの学びの軌跡をぜひご覧ください。

DeNA における 1on1 と、“すごマネ"が目指したもの

DeNA では、新卒メンター制度があり、その一環としてメンター／上長と新卒との 1on1 は新卒社員育成の重要要素として位置づけられ、全社で積極的に実施されています。

しかし、私たちが研修の中で先輩社員にヒアリングを行う中で、「1on1 について学ぶ仕組み」「メンターが自身の 1on1 の仕方を改善する仕組み」が十分に整っているとは言い難い状況が見えてきました。

1on1 を「メンター」の立場で行う場合、その多くは「新卒などの新しいメンバーの育成がアサインされたとき」に実施されます。しかし、そのタイミングで「1on1 の進め方」や「効果的な声掛け」などについて十分な教育体制が整えられておらず、各自が手探りで自分なりの 1on1 を構築していくことが常態化しているようでした。

もちろん、「自分と相手に合った形での 1on1」を独自に考え、運用していくことは歓迎されるべきです。しかし、「守破離」という言葉があるように、独自のカスタマイズを加えるためには、まず共通化された基礎を身につけることが大切です。

そこで私たちは、「メンターとメンティーによる 1on1 を、”確かな成長支援” の場へと進化させる」 ために、主に 「1on1 をはじめたばかりのメンター」 に対して機能提供を行うことに決めました。

“すごマネ” の機能

“すごマネ” には、大きく分けて 2 つの機能があります。

1. 1on1 前のコンディションアンケート

1on1前に送付されるコンディションアンケート

この機能のコンセプトは、「メンティーが安心して本音を話せる土台作りをサポートすること」です。

1on1 の前に、メンティーへ Slack 上で“コンディションアンケート”を自動送信します。アンケートは、「今日のコンディション」「話したいこと」などの設問を用意し、基本は選択式、必要に応じて自由記述も可能にしています。

この回答内容を 1on1 開始前にメンターに送付することで、メンターはメンティーの状況を事前に把握でき、1on1 中の時間配分や話題づくりの参考になるほか、細かな変化にも気付きやすくなります。

2. 1on1 後の AI によるフィードバック

1on1後に送付されるフィードバック

DDeNA では全社で Google Workspace が利用できるため、Google Meet を利用した会議では議事録と文字起こしの自動生成を行うことができます。

私たちはこの文字起こしデータをもとに、1on1 の進め方や声掛けについて AI によるフィードバックを生成し、メンターに送付する機能を開発しました。

このフィードバックは、1on1 に関する資料として作成されていた社内ドキュメントをベースとして生成され、1on1 内で話されたことのサマリやメンティーのネクストアクションに加え、「メンターが次回の 1on1 で実践できる具体的なアクション」を「Try」として提案します。

「Try」の生成にあたっては、抽象的で納得感のないアドバイスでは、実践につながりません。そこで、以下の 4 つの項目に分けて Try を生成するようにしました。

提案: 次に何をすべきか、具体的な行動の提示
根拠: なぜその提案が有効なのか、明確な理由の提示
発言例: すぐに使える具体的な発言の提示
期待される効果: そのアクションによって期待できる変化の提示

フィードバックによって、メンターは自分の 1on1 を客観的に振り返るとともに、より良い形で声掛けを行う方法を知ることができます。この「振り返り → 改善」の PDCA サイクルを促すことが、「1on1 を “確かな成長支援” の場へと進化させる」ための機能となります。

他にも、日常的に使ってほしいプロダクトだからこそ、見せ方や操作感などはストレスを与えず、かつ無視されないような工夫を行いました。すでに何人かの社員に利用していただきましたが、「ありがたい」「使い続けたい」などの良い評価を多くいただいているため、今後はさらに展開範囲を広げていきたいと考えています。

“すごマネ” を支えるアーキテクチャ

ここからは、開発を担当したメンバー 4 人で “すごマネ” を技術的な視点から深掘りしていきます。

“すごマネ” の開発において、私たちはアーキテクチャの選定を慎重に行いました。

新卒研修プロダクトという特性上、開発期間が限られ、参加メンバーの技術レベルも多様という制約がありました。こうした状況下で私たちが Layered Architecture を採用した理由は、主に以下の 3 点に集約されます。

1. 保守性と拡張性の確保

開発プロセスでは、ヒアリングを重ねる中でプロダクトオーナーによる大幅な仕様変更がたびたび発生し、仕様は常に流動的でした。

私たちは、こうした変化に柔軟に対応し、プロダクトオーナーの意向を最大限プロダクトに反映させることを重視しました。

Layered Architecture では、各層の責務が明確に分離されているため、機能追加や変更時の影響範囲が限定されます。その結果、高い保守性を維持しながら、ビジネス要求の変化に迅速に対応できる拡張性を確保することができます。

2.テスト容易性の向上

各層を独立してテストできるため、ビジネスロジックと外部システム連携を明確に分離できます。また、モックを利用したテストも容易に行えます。

3.チーム開発の促進

Layered Architecture は、明確な責務分離と「上位層から下位層へ」という一方向の依存関係を定めます。

これは、さまざまなバックグラウンドを持つ開発者が、共通の設計思想に基づいて迷いなく開発を進めるための強力な指針となりました。

結果として、設計の共通理解が深まり、開発効率とコードの一貫性が向上しました。

“すごマネ” のアーキテクチャ概要

Layered Architecture は、アプリケーションの機能を複数の「層（Layer）」に分割し、それぞれに特定の役割を担わせる設計パターンです。

その核となるのは、責務の分離と、上位層は下位層に依存するがその逆はないという一方向の依存関係です。これにより、システムの複雑さを管理しやすくなり、変更に強い構造を築けます。

“すごマネ” では、この思想に基づき、以下の 4 層で構成されるアーキテクチャを採用しました。上位（依存されない側）の層から順に紹介します。

Domain Layer:
- ビジネスの核となるルールやエンティティを定義します
Application Layer:
- ユーザーの操作に対応するユースケースを実装します
Presentation Layer:
- 外部からのリクエストを受け付け、レスポンスを返します
Infrastructure Layer:
- データベースや外部 API との連携など、技術的な詳細を担います

Layered Architecture 各層の役割

ここからは、 “すごマネ” における各層の具体的な役割と構成について解説します。

Domain Layer

システムの核となる層で、ビジネスロジックとルールを定義します。

他のどの層にも依存せず、純粋なビジネス概念を表現することに専念します。

責務:
- エンティティ定義
  - ユーザー、ミーティング、レポート といったドメインの主要なオブジェクトのデータ構造と振る舞いを定義します
- ビジネスルール実装
  - 「経験学習モデル」のような “すごマネ” 独自のビジネスロジックを実装します
- インターフェース定義
  - データ永続化（リポジトリ）や外部システム連携（ゲートウェイ）のためのインターフェースを定義します
  - 具体的な実装は Infrastructure Layer に委ねます（依存関係逆転の原則）
特徴:
- この層を純粋に保つことで、ビジネスの本質的なロジックが技術的な詳細から分離され、システムの理解とメンテナンスを容易に行えます

Application Layer

ユーザーの具体的な操作（ユースケース）を実現する層です。Presentation Layer からの指示を受け、Domain Layer のオブジェクトやロジックを組み合わせて処理を実行（オーケストレーション）します。

責務:
- ユースケース実装
  - 認証管理、ミーティング管理、AI によるレポート生成、アンケート管理、Slack 通知など、具体的なアプリケーション機能を実装します
- エラー変換
  - Infrastructure Layer から渡された技術的なエラー（例: DB 接続エラー）を、「ミーティングの作成に失敗しました」のようなビジネス文脈のエラーに変換し、上位層に伝えます

Infrastructure Layer

データベースや外部 API との連携など、技術的な詳細をすべて担う層です。

Domain Layer で定義されたインターフェースを実装し、Application Layer から利用されます。

責務:
- 永続化の実装
  - Domain Layer で定義されたリポジトリインターフェースに基づき、Google Cloud Firestore へのデータ保存・取得処理を実装します
- 外部サービス連携
  - Google Workspace API、gRPC 経由の AI サービス、Google Cloud KMS（暗号化）、Google Cloud Pub/Sub（非同期処理）などとの具体的な通信を実装します
- エラーハンドリング
  - 発生した技術エラーにスタックトレースを付加し、Application Layer へ伝達します
特徴
- 技術的な関心事をこの層にカプセル化することで、Domain Layer や Application Layer を特定の技術から独立させ、将来の技術変更に強くしています

Presentation Layer

ユーザーインターフェースや外部システムとの窓口となる層です。リクエストを受け取り、Application Layer のユースケースを呼び出し、その結果をレスポンスとして返します。

責務:
- リクエストの受付と検証
  - HTTP リクエストを受け取り、必要なパラメータを検証します
- ユースケースの呼び出し
  - リクエストに応じて、適切な Application Layer のサービスを呼び出します
- レスポンスの返却
  - Application Layer からの実行結果を、JSON 形式の API レスポンスや HTML として整形して返します

研修におけるアーキテクチャ設計の意義

私たちが “すごマネ” 開発で本格的なアーキテクチャ設計に取り組んだのは、単に「動くものを作る」だけでなく、「持続可能で高品質なプロダクトをチームで開発する」という経験を、新卒という早い段階で積むことこそが重要だと考えたからです。

この挑戦は、チーム開発に大きな価値をもたらしました。

Layered Architecture の明確な責務分離と依存関係のルールは、各メンバーが自身の担当範囲と他の部分との関わりを理解するうえで大きな助けとなりました。

その結果、チーム全体で設計の共通認識が生まれ、コードレビューの効率化や実装の不整合削減につながりました。全員がアーキテクチャという共通の指針に従うことで、コードの品質は自然と維持され、保守性と拡張性の高い開発が実現できたのです。

そして何より、この経験は新卒の私たちにとって貴重な成長の機会となりました。

アーキテクチャの理論を知識として学ぶだけでなく、自ら手を動かしてその原則を適用する過程で、複雑なシステムをいかに設計し、管理していくかという実践的な思考力が養われました。

この経験は、私たちが将来どのような開発に携わるうえでも必ず役立つ、礎となる学びになったと確信しています。

フィードバック生成における LangChain（RAG）の活用

“すごマネ” では、フィードバック生成時に LangChain と RAG を活用しています。

本章では、この部分の技術的な紹介をさせていただきます。

生成内容の全体像

生成内容は、メンティーとメンターで異なります。

1on1 が終わると、それぞれのコンテンツが自動的に生成、送信されます。

メンティー向け
- 1on1 サマリ
  - 1on1 の要点をまとめたもの
- ネクストアクション
  - 会話内容から抽出された、次に取るべき具体的な行動計画
メンター向け
- 1on1 サマリとネクストアクション（メンティーと同様）
- 次回の 1on1 で実践できるアクション（Try）
  - 社内で蓄積された「1on1 ガイドライン」というナレッジドキュメントに基づき、メンターの次回の取るべき行動を具体的に提案します

サマリとネクストアクションの生成アーキテクチャ

サマリとネクストアクションの生成は、比較的シンプルな LLM を活用したフィードバック生成の流れです。

コアとなるのは、LangChain フレームワークと Google の Vertex AI です。

入力コンテンツ：

Google Meet API 経由で取得した 1on1 文字起こし
過去のフィードバック
- 以前の 1on1 で生成されたサマリやアクション
- これを参照することで、会話の文脈や過去の経緯を LLM がより深く理解し、一貫性のあるフィードバックを生成できます

生成プロセス：

サマリとネクストアクションの生成には LangChain の LLMChain を利用しています
文字起こしと過去のフィードバックを整形し、一つのプロンプトにまとめて Vertex AI （Gemini 2.5-flash）に渡すことで、サマリとネクストアクションを一度のリクエストで効率的に生成させています

RAG による「試すべき行動（Try）」の生成

メンター向けの「試すべき行動（Try）」を生成するには、標準的な LLM の知識だけでは不十分です。

LLM は広範な公開情報で学習されていますが、1on1 に特化したノウハウや組織固有のクローズドな情報については知識を持たないため、そのまま質問を投げても、1on1 改善に繋がるようなフィードバックが得られません。

この問題を解決するために RAG を用います。

RAG は、LLM に質問を投げる前に、まず外部の知識源（今回は社内ナレッジを markdown 化したドキュメント）から関連性の高い情報を検索（Retrieval）し、その検索結果をプロンプトに埋め込んで LLM に渡す（Augmented Generation）アーキテクチャです。

これにより、LLM は与えられたコンテキスト（検索結果）に基づいて回答を生成するため、ドキュメントの内容に裏付けられた具体的なアウトプットの出力が可能になります。

RAG の処理ステップは以下の 2 つに大別されます。

1.ベクトルデータベースの構築

RAG の「検索」部分を高速に実現するため、事前に「1on1 ガイドライン」を検索可能な状態にしておく必要があります。

前処理として、ドキュメントを意味のあるまとまり（チャンク）に分割し、Vertex AI の Embedding モデル（text-multilingual-embedding-002）で数値のベクトルに変換します。そして、そのベクトル群から FAISS（Facebook AI Similarity Search／高次元ベクトル空間において、特定のベクトルに類似したベクトルを極めて高速に検索するためのライブラリ）を用いて、高速な検索インデックスを構築します。

この事前処理により、ドキュメントの内容が意味的に近いもの同士が物理的にも近い距離に配置されたベクトル空間データとして保存され、効率よく類似検索が可能になります。

2.検索と生成

1on1 の文字起こし内容を基に、ガイドラインに問い合わせるための検索クエリを LLM に生成させます。

次に、そのクエリをベクトル化し、事前に構築した FAISS のベクトルデータベースから、関連性の高いガイドラインの抜粋（チャンク）を複数検索します。

最後に、検索で得られたチャンクをコンテキスト情報としてプロンプトに埋め込み、「ガイダンス情報を参考にして、次の 1on1 で試すべき行動を提案してください」といった指示とともに Vertex AI に渡します。

この一連の流れにより、ナレッジに基づき、具体的で質の高い「試すべき行動（Try）」をメンターに提案できるようになります。

Output Parser を用いた LLM 出力の整形

LLM は非常に強力ですが、その出力は基本的に単なる文字列です。しかし、アプリケーションでこのデータを扱うには、JSON や特定のオブジェクトといった構造化された形式が必要です。

プロンプトで「JSON 形式で出力してください」と指示するだけでは、フォーマットが崩れたり、意図しない説明文が混じったりと、後続処理の安定性に欠けます。この問題を解決するために、LLM からの応答を安定的してパースするためのパーサーレイヤーを構築しました。

まずは LLM からの生のテキスト応答をクリーンアップする処理から始めます。応答に含まれがちな Markdown のコードブロックや、その他の余分なテキストを除去し、純粋な JSON 文字列を抽出します。

次に、この JSON 文字列を、責務ごとに分割された専用のパーサークラスで処理します。例えば、「メンター向けのトライ」の応答を処理するパーサや、「サマリ」と「ネクストアクション」を処理するパーサがあります。

これらのクラスは、抽出された JSON の構造を検証し、必須キーの存在チェックなどを行ったうえで、あらかじめ定義された Pydantic モデルや Python のデータ構造（dict や list）へと変換します。

このアプローチにより、LLM からの応答に多少出力形式の揺らぎがあっても、パーサーがロバストに解析し、最終的にはクリーンで構造化されたデータを得ることができます。アプリケーションの後続処理は、LLM の生の出力を意識することなく、常にクリーンで型安全なデータを扱えるため、システム全体の安定性向上につながります。

以上が、本プロダクトに採用した LangChain（RAG）のコアとなる仕組みです。

“すごマネ” のインフラ構成

インフラの全体像

“すごマネ” のインフラは、Google Cloud Platform（GCP）を基盤として構築されています。

主要なコンポーネントとして、スケーラブルなコンテナ実行環境である Cloud Run、外部からのアクセスを制御する Load Balancer、プライベートネットワークを構築する VPC（Virtual Private Cloud）、認証・認可を担う IAP（Identity-Aware Proxy）、メッセージキューイングを行う Pub/Sub などを組み合わせています。

これらの要素が連携することで、安定したインフラ基盤と高いセキュリティ、そして優れたコスト効率を実現しています。

具体的な構成は、以下の図のようになっています。

インフラ構成図本章では、“すごマネ” を稼働させるにあたってどのような要件があったか、何を考えてこのような構成にしたかをご紹介します。

特に、セキュリティ強化とコスト最適化に大きく貢献している以下の 2 点について重点的にお伝えできればと思います。

セキュリティの強化
- IAP と Cloud Run の Ingress 設定により、外部からの不正アクセスを厳しく制限
  - Cloud Run へのアクセス経路を VPC 内部と Load Balancer 経由に限定することで、強固なセキュリティを実現
コストの最適化
- Direct VPC Egressの活用と名前解決専用の DNS コンポーネントの導入
  - Cloud Run 間の通信を VPC を経由して直接通信させ、不要なデータ転送コストを削減しつつ、安定したセキュアな内部通信を確保

セキュリティを考慮したアクセス制御

“すごマネ” のインフラ設計において、セキュリティは最も重要な要素の一つです。“すごマネ” はカレンダーの予定や Google Drive のファイルなど、ユーザーの Google アカウントに紐づいたさまざまなデータを取り扱います。

そこでユーザーが安心して利用できる環境を提供するため、アクセス経路に対して多層的なセキュリティ対策を講じています。

まず、外部からのアクセスに対しては、Load Balancer に IAP による認証制限を導入しています。これにより、“すごマネ” にアクセスする際には、弊社の Google Workspace に紐づいたアカウントによる認証が必須となります。

この認証を通過したリクエストのみがシステム内部へと進むため、Load Balancer の配下にある Cloud Run へのアクセスが保証され、不正なアクセスを防ぐ強力な第一歩となります。

さらに、Cloud Run 自身の Ingress 設定も厳しく制限しています。

具体的には、Cloud Run が外部からの直接リクエストを受け付けず、VPC 内部からのアクセス、または Load Balancer からのリクエストのみを許可するように設定しています。

これは、「伝えたいポイント」の一つである「Cloud Run のリクエストを VPC 内部と Load Balancer のみにしたことによるセキュリティの強化」を実現するための核となる設定です。この構成により、Cloud Run への不必要な外部からの露出を最小限に抑え、攻撃面を大幅に縮小しています。

加えて、各 Cloud Run サービスへのリクエスト実行権限は、サービスアカウントを用いて厳密に制限しています。これにより、アクセス制御はネットワークレベルだけでなくサービスアカウントレベルでも二重に保護されるため、万が一ネットワークレベルのセキュリティが突破されても、システム内部への侵入を困難にし、強固な防御体制を築いています。

Cloud Run と VPC の通信最適化

Cloud Run 同士や、Cloud Run から VPC 内部の他のサービスへの通信は、セキュリティとコスト効率を両立させるために工夫を凝らしています。

Cloud Run 同士を VPC を介して通信させる際、従来は VPC Access Connector を使用することが主流でしたが、コネクタのVMインスタンスを立てる必要があるため常時使われない Cloud Run との組み合わせでは必要以上にコストがかかります。

“すごマネ” はトラフィックに波があるプロダクトであり、コストの観点で Access Connector とは相性が悪いです。そこで昨年 GA されたVPC Direct Egressを使い、VPC を介した Cloud Run 同士の通信を実現しています。

VPC Direct Egressでは Cloud Run が直接 VPC のネットワークにアクセスするため

コネクタの VM インスタンスが不要
ネットワークパフォーマンスがコネクタの VM インスタンスに依存しない（高パフォーマンス）

というメリットがあります。

一方で Cloud Run を迅速にスケールアップするために一つのサービスごとに 16 個のブロック/28のサブネットで IP アドレスを予約するため、VPC Subnet のアドレスが Access Connector と比べて多数消費するというデメリットもあります。

“すごマネ” の規模では

Max Instance の設定により Cloud Run サービスが16 個以上にスケールアウトすることは無い
3 つの Cloud Run が 16 個確保しても、アドレス空間が/24と十分な大きさであるため、IP アドレスが枯渇することは無い

以上の理由から VPC Direct Egress を使用できると判断しコスト削減のために用いる設計としました。

また、Cloud Run に割り当てられるドメイン（*.run.app）は通常パブリックな DNS サーバーで名前解決されます。その結果、通信したい Cloud Run へはグローバルな IP でアクセスしようとするため、内部通信ではないと判定され、ネットワークレベルでブロックされる問題が発生します。

この問題を解決するため*.run.appをprivate.google.com の範囲で名前解決するようVPC 内部に DNS を配置しました。これにより、 Cloud Run が別の Cloud Run へ通信しようとした際、private.googleapis.comの範囲で名前解決がされ、内部通信として処理できるようになりました。

Pub/Sub の利用

“すごマネ” では、Backend サービスから Slack Bot へのメッセージ送信を非同期で行うためにPub/Subを利用しています。これは、GCP が提供するフルマネージドなメッセージキューイングサービスです。

メッセージ送信にマネージドなキューを使うことで

Slack Bot と Backend が疎結合になる
再送処理を Pub/Sub へ任せることができる

といった恩恵を受けることができ、システムの安定性とスケーラビリティを確保しています。これにより、Backend サービスはメッセージを Pub/Sub に Publish するだけでよく、メッセージの送信が成功したかどうかを待つ必要がなくなり、全体のパフォーマンス向上にも貢献しています。

これらを利用し、全社の1on1での運用に耐えうる、安定したシステム稼働基盤を構築しています。

おわりに

今回は新卒エンジニア研修において、約2か月かけて開発した「1on1 支援ツール “すごマネ”」の企画背景から技術的な実装まで、幅広くご紹介させていただきました。

現在、“すごマネ” は既に複数の社員の方々にご利用いただき、嬉しいフィードバックをいただいています。今後はさらに利用範囲を拡大し、DeNA 全社の1on1品質向上に貢献していきたいと考えています。

「メンターとメンティーによる 1on1 を、“確かな成長支援” の場へと進化させる」 という私たちのビジョンが、一人でも多くの方の成長に寄与できることを願っています。

最後に、この研修を通じて感じたのは、DeNA のエンジニアリング文化における 「挑戦を後押しする環境」 の素晴らしさです。

新卒メンバーであっても、本格的なアーキテクチャ設計から最新技術の活用まで、妥協なく取り組むことを支援していただけたからこそ、“すごマネ” を完成させることができました。

最後までお読みいただき、ありがとうございました。