AIエージェントプラットフォームに向けた第一歩～アプリソースコードを用いたRAGコーパス自動更新～

1. 自己紹介

NTTドコモデータプラットフォーム部（以下DP部）黒須です。社内データ活用プラットフォームPochiのチームで、主にGoogle Cloudを活用したインフラ設計・構築・運用を担当しております。

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

2. 背景

2025年12月現在、プラットフォーム上では130以上のアプリが動いております。アプリの数が多くなってきたため、Vertex AI RAG Engineを用いて、ユーザーの要望に対して最適なアプリをレコメンドする仕組み(以下アプリコンシェルジュ)を構築しております。

アプリコンシェルジュでは、各アプリの説明書（以下アプリ説明書）を基にしたRAGコーパスを活用しています。アプリ説明書は、Claude Codeを用いて各アプリのソースコードから生成しております。アプリコンシェルジュやアプリ説明書の具体的な説明については今後発表される記事をご参考ください。

本記事ではアプリ説明書の生成からRAGコーパス反映までを、Google Cloudを活用して自動化した仕組みについて紹介いたします。以降の章では、全体構成と工夫した点について紹介いたします。

3. 全体構成

Cloud Run jobsとCloud Run functions、Workflowsを活用して以下のアーキテクチャを作成しました。
Cloud Schedulerを使って週次でWorkflowsを実行し、RAGコーパスを更新しております。

Cloud Schedulerが週次でWorkflowsを起動
Cloud Run functionsが処理を実行
- 直近7日間で更新のあったアプリのソースコードをアプリ説明書作成用のCloud Storageに格納
Cloud Run jobsが処理を実行
- 格納された資材をもとにClaude Codeでアプリ説明書をMarkdown形式で作成
- Markdown形式で作成されたアプリ説明書をJSON形式に変換したあとRAGコーパスに反映

4. 工夫した点

4.1 アプリのソースコード取得で工夫した点

Cloud Run functionsでアプリのソースコードの取得については実施しております。
プラットフォーム上で動作するアプリはすべてCloud Buildでビルドされているため、Cloud BuildのAPIを用いて最新のビルド資材を取得することにいたしました。

以下のコードで週次で直近1週間の本番環境で成功したビルドの一覧を取得しております。ビルド環境変数でステージを管理しているため、絞りこみが楽です。

from google.cloud.devtools import cloudbuild_v1

filter_conditions=[]
filter_conditions.append(f'create_time>="{start_time_str}"')
filter_conditions.append(f'create_time<="{end_time_str}"')
filter_conditions.append(f'substitutions._STAGE="prod"')  # 本番環境のビルドに絞る
filter_conditions.append(f'status="SUCCESS"')
filter_string = " AND ".join(filter_conditions)

client = cloudbuild_v1.CloudBuildClient()
request = cloudbuild_v1.ListBuildsRequest(
    parent=parent,
    project_id=project_id,
    filter=filter_string
)
page_result = client.list_builds(request=request)

ビルド一覧を取得した後に、各アプリの最新のビルド資材を解凍して、アプリ説明書作成用のCloud Storageバケットに格納しております。元々はGitHubからアプリのソースコードを取得しておりましたが、Cloud Buildのビルド資材を使うことでGoogle Cloud内で処理を完結することができ、セキュリティ面でのリスクを低減できました。

4.2 アプリ説明書作成で工夫した点

Cloud Run jobs でアプリ説明書作成用のCloud Storageバケットをマウントし、Claude Code 対応のカスタム Docker イメージ上から Pythonで Claude Code を呼び出すことでアプリ説明書を自動生成しています。

Claude Code 公式開発コンテナを参考に、運用・セキュリティ上不要な機能を削除した最小構成の Dockerfile を作成しました。また、Claude Code の権限を制限する設定ファイルをリポジトリで settings.json として管理し、Docker build 時にコンテナ内へ .claude/settings.json として配置することで挙動を制御しています。

4.3 ワークフローを安全に運用するために工夫した点

解析しやすいログ設定として、ワークフローの実行ログは Cloud Logging 上で一元的に閲覧できるようにしています。標準的な Python のログ設定だけでは Cloud Logging 側で全ログが default に集約され、重要度の切り分けが難しくなります。そこで Cloud Logging 用の Python ライブラリを導入し、アプリ側から適切なログレベル（INFO / WARNING / ERROR）を付与して送出できるようにしています。その結果、Cloud Logging のレベルフィルタによる絞り込みが可能となり、障害調査や原因切り分けが容易になりました。

中間生成物を確認しやすくする工夫として、Claude Code がアプリ説明書を生成する際にプロンプトに基づきどのような手順で作成したかを示す生成プロセスログを同時出力することを活用しています。Cloud Storage バケット内を用途別に階層化し、生成プロセスログ・アプリ説明書 Markdown・RAG コーパス登録用 JSON（アプリ説明書 Markdown を変換したもの）を分離しました。

llm-output/
├── logs/YYYYMMDDhhmm/app-name.log      # Claude Code の生成プロセスログ
├── manual/app-name/YYYYMMDDhhmm/*.md   # 生成された説明書 Markdown
└── rag_source/YYYYMMDDhhmm/*.json      # RAG コーパス登録用 JSON

この構造により、中間成果物の健全性確認と差分比較が容易になり、異常検知後の調査時間の短縮やプロンプトの改善にも役立ちます。

リトライ処理については、アプリ説明書生成とRAGコーパス更新の2つの場面で実装しています。アプリ説明書生成では、各アプリのソースコードのサイズなどの要因で失敗することがあったため、単純なリトライ処理を実装しています。リトライをしても失敗した場合は、他のアプリの生成処理は続行され、失敗したアプリに対して通知がされます。一方、RAGコーパス更新では、Vertex AI のレート制限エラーが頻出したため、指数関数バックオフを取り入れています。

ロールバック機能については、RAG コーパスの更新が失敗するとアプリコンシェルジュに影響が出るため実装しています。RAG コーパス更新用 JSON ファイルはタイムスタンプ付きディレクトリ構造で過去バージョンを保持しており、問題発生時には直前の正常なタイムスタンプのファイルへ自動ロールバックします。

5. 取り組みの効果と今後の展望

アプリコンシェルジュについては2025年12月時点で累計600名以上のユーザーに利用いただいており、本取り組みにより最新のアプリ情報を用いて、ユーザーに最適なアプリをレコメンドできるようになりました。今後はAIエージェントを活用したプラットフォームへの進化を目指しており、アプリのソースコードからアプリ説明書を作成するだけでなく、MCPサーバーの作成なども検討しております。そのため今後のプラットフォームの進化に向けて本取り組みは重要な役割を果たすと考えております。

本記事で紹介したワークフローの検討・実装については業務委託先メンバーの井出さんに多大なるご協力をいただいており、井出さんにも執筆協力いただきました。この場を借りて感謝申し上げます。