業務課題を話すだけでデータ活用アプリが⾒つかる - RAG × Claude Codeで実現するアプリコンシェルジュの開発と品質評価

自己紹介

NTTドコモデータプラットフォーム部（以下DP部）矢野です。
DP部では社内データ活用プラットフォームPochiを展開しており、利用促進の取り組みとして、RAGを使ったコンシェルジュアプリを開発しました。本記事では、その開発の経緯と工夫点について、支援メンバーである静野さん・鶴薗さんに執筆いただきます。
NTTデータグループ技術革新統括本部 AI技術部の静野です。NTTドコモ様が全社展開するデータ活用プラットフォームPochiにおいて、LLM/Agent技術を活用した利用促進の取り組みを進めています。私からはユーザビリティ課題の発見から、Vertex AI RAG Engineを活用したコンシェルジュの開発、そして実運用で見えた改善ポイントと今後の展望まで、実践的な知見を共有させていただきます。

社内データ活用プラットフォームPochi*1とは

私たちDP部は社内のデータ民主化を目指し、StreamlitとGoogle Cloudで圧倒的に使いやすいデータ活用プラットフォームを開発・推進しています。このプラットフォームは、24年度は30万時間もの業務効率化を実現し、直近では5,000人以上の社員に利用が拡大しています。
ASCII.jp：NTTドコモ、Streamlit利用の“ポチポチ分析アプリ”開発で社内データ活用を促進 (1/3)

背景

Pochiの成長とユーザビリティの課題

Pochiは社内のデータ民主化を促進し、多くの社員が自らデータ分析・活用アプリを開発・利用できる環境を実現してきました。

しかし、この取り組みの普及に伴い、新たな課題が顕在化してきました。

アプリの数が徐々に増加したことで、ユーザーが自分の業務課題に合ったアプリを探す際に適切なものを見つけられなくなってきた
業務活用が高度化したことで複数アプリを組み合わせる必要があるケースも増えたが、ユーザーがどのアプリを組み合わせればいいのか判断できない

AIコンシェルジュが解決する課題

この課題を解決するため、私たちは「アプリコンシェルジュ」を開発しました。これは、ユーザーが自然言語で「d払いのユーザー行動を分析したい」「新店舗の出店地域を検討できるアプリはありますか？」といった質問を投げかけるだけで、AIが最適なアプリを推奨し、その使い方まで説明してくれるチャット形式のコンシェルジュです。

従来は、ユーザー自身がアプリ一覧を見て説明文を読み比べながら適切なアプリを探す必要がありましたが、コンシェルジュを使えば、業務課題を自然言語で伝えるだけで、最適なアプリを見つけ出してくれます。これにより、アプリ検索の時間を大幅に削減し、ユーザーは本来の業務分析に集中できるようになります。

コンシェルジュの機能とユーザー体験

私たちが目指したのは、「ホテルのコンシェルジュと対話するような体験」です。アプリの機能をただ列挙するのではなく、ユーザーの入力した内容を汲み取り、「このアプリなら、あなたの抱える〇〇という課題をこう解決できます」とユーザーの業務課題に合わせて説明します。このように、情報の見せ方を相手の関心事と直接結びつけることで、ユーザーが自分にとって価値あるツールだと直感的に理解できるようにし、迷うことなく適切なアプリに辿り着けるようにしました。

例えば、ユーザーが「dカードキャンペーンのエントリー有無で決済金額を比較分析したい」と入力すると、コンシェルジュは以下のようにやり取りを進めていきます。

要件の理解とヒアリング: ユーザーの課題を理解し、必要に応じて詳細を質問（例：データの対象期間、絞り込み条件など）
最適なアプリの提示: 要件を満たすPochiアプリを検索し、なぜそのアプリが課題解決に適しているかを簡潔に説明
使い方のガイド: 推奨したアプリの具体的な操作手順や活用方法を説明

特に重要なのは、AIが単にキーワードマッチでアプリを提示するのではなく、ユーザーの業務課題を理解した上で「本当にそのアプリで解決できるか」を吟味して推奨している点です。例えば、地域限定のアプリを提示する際には、ユーザーの課題がその対象範囲に含まれているかを確認します。

技術的な取り組み

アーキテクチャ

アプリコンシェルジュは、ユーザーの自然言語入力から最適なアプリを推薦するために、RAG（Retrieval-Augmented Generation）アーキテクチャを採用しています。

RAGアーキテクチャにより、単純なキーワードマッチングではなく、ユーザーの意図を深く理解した上でのアプリ推薦が可能になっています。具体的には、ユーザーの業務課題をVertex AI RAG Engineで関連するアプリのドキュメントから検索し、その結果をLLMに渡すことで、コンテキストに応じた柔軟な対話を実現しています。このように検索と生成を組み合わせることで、「本当にそのアプリで解決できるか」を吟味した提案が行えるようになりました。

RAG Engineの活用

RAGアーキテクチャを実現するにあたって、Vertex AI RAG Engineを活用しました。 Vertex AI RAG EngineとはGoogle Cloudで提供されているRAGアプリケーションを容易に構築できるフルマネージドサービスです。

RAGの構築に必要な以下のプロセスを自動化・簡易化し、迅速なRAGアプリケーションの開発を可能にします。

RAG Engineのサービスイメージ引用元: Vertex AI RAG Engine の概要

本サービスの機能を活用することで、通常であれば数週間を要するRAGインフラの構築・検証を行うことなく、プロジェクト開始からわずか数日でプロトタイプを完成させることができました。特に、「どうすればユーザーにとって最適なアプリを推薦できるか」「どのような対話体験が使いやすいか」といった本質的な課題に注力できた点は大きなメリットでした。

また、フルマネージドなインフラ構成であるため、運用開始後も保守やスケーリングを気にする必要がありません。ユーザー数が増加しても、RAG Engineが自動的に対応してくれるため、アプリケーションの機能改善に専念することができています。

アプリ説明書の自動生成

RAGアーキテクチャの要となるのが、アプリの情報を的確に伝える「アプリ説明書」です。コンシェルジュが適切な推薦を行うためには、各アプリの機能や使い方が網羅的かつ正確に記載された説明書が不可欠です。

この説明書の作成には、Claude Codeを活用しています。Claude Codeにアプリのgitリポジトリを探索させることで、人手では時間がかかる作業を自動化し、150近くあるアプリ全てについて統一されたフォーマットの説明書を効率的に生成しています。

アプリ説明書の構成は以下の通りです。

アプリの概要
このアプリでできること
機能別説明
- 機能名
- 投入可能データ
- 利用可能なデータ
- ユーザー入力パラメーター
- この機能でできること
- この機能の使い方

これらの章立てで情報を収集させ、1アプリにつき1つのアプリ説明書を生成しています。
以下がサンプルです。

# 販売状況抽出

## アプリURL
https://sales-extractor.xxx.jp/

## アプリ概要
支社、支店、店舗別の、特定の商品販売状況を取得・分析できるアプリケーションです。データベースから販売実績を抽出し、販売状況の実績値や分析ケースを示唆することで、効果的な施策検討や分析を支援します。

## このアプリで実現できること

支社、支店、店舗別の特定の商品の販売状況を数値で「見える化」し、戦略的な販売促進施策の立案を強力にサポートします！

**具体的なユースケース**
- **販売実績の現状把握**: 支社・支店・店舗別の指定された商品の販売状況をリアルタイムで確認
- **顧客デモグラ分析**: 購入者の性別・年代・契約種別等の属性分析でターゲット戦略を策定

## 機能一覧
- 販売状況取得 : 期間・組織（支社/支店/店舗）・商品指定での販売実績抽出と多角的分析
- 【CSV取り込み】ユーザー分析 : 特定ユーザーリストに対する商品購入状況の詳細分析

## 販売状況取得

### InputとOutput

#### 利用可能データ(社内DB等)
- **データベース**
  - SALES_RESULT（販売データ）
  - PRODUCT_MASTER（商品情報マスター）
  ...

#### 投入可能データ
この機能では外部ファイル投入は不可能です。

#### ユーザー入力可能パラメーター(ユーザーが画面から設定できるパラメーター)
- **抽出期間**: カレンダー形式での開始日・終了日指定（過去2年間から現在まで）
- **抽出粒度**: 支社/支店/店舗（ラジオボタン選択）
- **商品選択**: 商品を選択（リストから選択）
...

#### ユーザーがこの機能でできること
- **基本データ抽出**: 指定条件での商品販売実績データをCSV形式でダウンロード
...

### 使い方
1. **抽出条件設定**: 期間、組織粒度、チャネル、対象組織を選択
2. **抽出実行**: 「抽出開始」ボタンでデータベースからデータを取得
3. **結果確認**: 抽出結果の件数確認とサンプルデータ表示（30件）
4. **データダウンロード**: 「CSV を生成する」→「ダウンロード」でCSVファイル取得

RAG Engineではチャンクサイズ設定があり内部でチャンク分割が行われるため、文字数が必然的に大きくなってしまうアプリ説明書をそのままRAGコーパスに投入してしまうと、様々なアプリの情報が混じってしまいちぐはぐな回答をしてしまいます。

そのため、できる限り情報が分断されないようにするために、1つのアプリ説明書を以下の複数のJSONファイルに分割してコーパスに登録しています。

アプリ全体
機能別-使い方以外
機能別-使い方

また、各ドキュメントにはアプリ名とURLを記載しており、ドキュメントの構成と立ち位置の説明も記載しています。
これによってRAGの回答に正しい日本語のアプリ名とリンクを常に表示させることができるようになり、さらに同アプリ間の関連性が向上することで欲しい情報が見つけやすくなり、回答精度とユーザビリティが大きく向上しました。
このアプリ説明書は更新されたアプリに対して自動生成されるようにCloud Runで週次のワークフローを構築しています。

説明書の品質評価

アプリ説明書の自動生成を実現した次のステップとして、生成された説明書の品質を継続的に担保する仕組みが必要です。ここでは、CI/CDプロセスに組み込んだ品質評価の取り組みについて説明します。

品質評価の必要性

アプリ説明書の品質がアプリコンシェルジュの品質に大きく影響します。
アプリ説明書に記載されていなければ、コンシェルジュはその事項について回答することができません。例えばアプリの使い方の説明では、ユーザーが画面を開いて処理を完結するまでの手順を漏れなく正しく説明できていなければいけません。
また、アプリ説明書に実態とは異なる記載がされている場合、コンシェルジュはその誤った内容を堂々と説明します。その説明を受けたユーザーが実際にアプリを触った時に、受けた説明とアプリの実態が異なるとコンシェルジュへの信頼が大きく失墜してしまい、二度と使ってもらえないということになりかねません。
そのため、アプリ説明書の品質を担保することはコンシェルジュが解決したい課題のためには非常に重要で、CI/CDを回す上で必要不可欠なプロセスとなります。

品質評価の手法

現在社内では多種多様なStreamlitアプリが150近く存在しており、それらのアプリ説明書の品質を担保していくことはCI/CDを回す上で簡単ではありません。
そこで私たちはアプリ全体を様々な観点で分類し、代表となるアプリを選定してテストケースとし、生成時同様Claude Codeを使用してAIによる評価を実施しています。

評価観点は①説明書の記載が正しいこと（アプリの実態通りであること）だけでなく、②説明書に記載されるべき内容が網羅的に記載されていること、の2点を観点としました。このような観点にした理由は上述の通りで、リポジトリの情報をアプリ説明書として検索できる形に落とし込んだ上で、その説明がアプリ実態に即していることと網羅的に情報が揃っていることが今回のコンシェルジュに求められていることだからです。
これらの2つの観点について評価するために、実施方針を2つに分けて ①説明書視点の評価 と ②アプリコード視点の評価、双方向からの評価として実施しています。それぞれの評価でさらに章ごとに5段階で基準を設け、最終的にはそれらのスコアを集計して品質の評価をしています。

この品質評価によって現状のアプリ説明書についての課題を明確にし、説明書の正確性や網羅性が向上した結果、コンシェルジュはユーザーの質問に対してより詳細な使い方まで案内できるようになりました。 temperatureの設定がないClaude Codeを使用している関係で評価結果はプロンプトで制御していても多少変動してしまい調整が難しかったですが、3点以下と4点以上で概ね品質の毀損は分類できるようになったため、現在はこちらを大きな目安として評価を実施しています。

まとめと今後の展望

アプリコンシェルジュは公開後1か月で約150人に利用され、利用者アンケートでも「アプリコンシェルジュに関してほしい回答が得られた：91％」と高い評価を得ています。ユーザーが自然言語で業務課題を伝えるだけで最適なアプリに辿り着けるという、当初の目標は達成できたと考えています。

一方で、さらなる改善ポイントもいくつか見えてきました。特に複数アプリを組み合わせて利用するケースでの回答精度には改善の余地があると考えています。また、提案されたアプリのユーザーインターフェースが複雑でユーザーが離脱してしまうケースもあり、アプリ検索だけでなく利用開始までのスムーズなユーザー体験設計が必要だと感じています。

今後はコンシェルジュのユーザー体験の向上を図りつつ、データ分析・活用プロセスそのものを代替するエージェントの開発にも取り組んでいきます。これにより、データをビジネス価値につなげるハードルをさらに下げ、真の意味でのデータ民主化を実現したいと考えています。

また、本記事で解説したアプリ説明書の自動生成をバッチ処理としてワークフロー化する取り組みについては別記事にてご紹介させていただいておりますので、併せてご参照いただければと思います。

*1:Pochiは社内の開発コードネームです