ANGEL Dojoに参加してみました〜開発編〜 - ENGINEERING BLOG ドコモ開発者ブログ

1. はじめに

1.1. 自己紹介

こんにちは、NTTドコモ第一プロダクトデザイン部の李、安立、木村、第二プロダクトデザイン部の吉田、サービスイノベーション部の千歩です！

〜活動内容紹介編〜では、私たちが参加したANGEL Dojoの活動概要、Working Backwardsによる企画、そして開発したAI審査アシスタント「mody」についてご紹介しました。

1.2. 本記事のテーマと、読んでほしい人

本記事は、その続編として、modyの開発期間（約3ヶ月）でいかに迅速かつ高品質な開発を実現できたか、その技術的な側面に焦点を当てて深掘りします。

内製化、AWSのモダンアーキテクチャ、そして生成AIをチーム開発でどう活用できるか、これらのテーマに興味があるエンジニアの方にぜひ読んでいただきたい内容です。

1.3. 開発したシステム「mody」の再確認

私たちが開発した「mody」は、広告やコンテンツの審査業務を効率化するためのAI審査アシスタントです。

従来、コンテンツの審査は目視で行われており、以下の大きな課題がありました。

膨大な作業量: 審査対象となるコンテンツの量が膨大で、時間がかかる
コンプライアンスリスク: 景品表示法や社内ガイドラインに基づくチェック項目が多岐にわたり、見落としのリスクがある

modyは、審査プロセスにAIを組み込むことで、人間が確認する前に以下の自動処理を行います。

違反チェック: 社内ガイドラインや景表法違反の疑いがある箇所を自動検出
ハイライトと根拠提示: 違反となる表記に対し、違反理由とともに該当箇所をハイライト表示

1. はじめに
2. システム全体概要とアーキテクチャ
- 2.1. modyを支えるアーキテクチャの全体像
- 2.2 3つの視点で設計したアーキテクチャ
3. modyのコア機能：生成AIを「審査担当の同僚」としてエージェント化
4. Amazon Q DeveloperによるAI駆動開発の実践
5. まとめと内製化への次の一歩
- 5.1 ANGEL Dojoで得た技術的知見の集約
- 5.2. おわりに

2. システム全体概要とアーキテクチャ

2.1. modyを支えるアーキテクチャの全体像

modyのシステムアーキテクチャは、短期開発かつ将来的な運用を見据え、AWSのマネージドサービスをフル活用しました。

2.2 3つの視点で設計したアーキテクチャ

私たちは、１つのチームでユーザーの声を聴くところからサービスの実装・運用まで、全領域を実行しました。内製化を支えるため、以下の3つの観点を重視してアーキテクチャを設計しました。

視点	目的	具体的な設計思想
Biz（利用者視点）	利用者が使い続けられる仕組み	利用者がカスタマイズ可能で、ノウハウを蓄積できるUI/UX。審査項目の増減にノーコードで対応できる仕様。
Dev（開発者視点）	高い生産性の維持	マネージドサービスやIaC（Infrastructure as Code）を活用し、開発速度を最大化する。
Ops（運用視点）	迅速な障害対応	オブザーバビリティ（可観測性）を確保し、障害時の状況把握と対応を迅速化する。

この設計思想により、開発者だけでなく、利用者・運用者それぞれの目線で持続可能なシステム基盤を構築しました。

3. modyのコア機能：生成AIを「審査担当の同僚」としてエージェント化

Strands AgentsによるAI審査ロジックの構築 今回のプロダクト開発では、LLM を「ただの API」ではなく、“審査担当の同僚”として扱うための土台として Strands Agents を採用しました。

Strands Agents は、AWS が公開している「LLM エージェント用のフレームワーク」で、LLM（Claude など）に対して「こういう役割で動いてね」「この情報を使って判断してね」といった指示をまとめて扱えるツールです。

開発期間が約 3 ヶ月と限られていたため、1 から AI 審査ロジックやワークフローを自作する余裕はありませんでした。

そこで、私たちは次の戦略を取りました。

「モデル呼び出しの細かい制御」や「周辺の制御ロジック」は Strands に任せる。
私たちは「どんな観点でレビューするか」「どんな出力があると審査担当者が助かるか」といった本質的な部分に集中する。

実際には、テキストやバナー画像と、社内ルール・景表法のポイントをセットで Strands に渡すと、AI が「怪しそうな表現」とその理由を一覧で返してくれる、という形で使っています。開発者からは、「審査したい内容を文章で説明して投げると、JSON で結果が返ってくる箱」が 1 つあるイメージです。

Strands Agents は当時リリースされたばかりの「攻めた選択」でしたが、このおかげで文書審査・画像審査など複数の機能を同じパターンで素早く増やすことができ、限られた期間で開発スピードを一気に上げることができました。

4. Amazon Q DeveloperによるAI駆動開発の実践

modyの高速開発を実現した最大の要因は、Amazon Q Developerを“チームメイト”として、設計〜実装〜テストまで並走させたことです。このセクションでは、バックエンドとフロントエンドの両面から、AI-DLCの実践事例をご紹介します。

4.1. コード生成AI活用の「結論」

バックエンド開発でコード生成AIを集中的に試した結論としては、以下の通りです。

上手く使いこなせれば、生産性は確かに上がるが、使いこなせないと、生産性は上がらないどころか、下がることもある

生産性向上に貢献した具体的な「AIとの付き合い方」として、私たちは「品質確保のためのAI活用」と「知識ギャップを埋めるためのAI活用」に注力しました。

4.2. 品質への貢献：単体テストを効率的に設計・コード化

短期開発で品質を維持するため、単体テストの整備は必須でした。私たちは、このタスクにAIを積極的に活用しました。

AIチームメイトへの「オンボーディング」

いきなり Q chat にテストコード生成を頼むのではなく、まずは前提条件を共有するところから始めました。

テスト自動化用オンボーディング.md: pytest 前提・AWS リソースはモック必須など、テスト方針と制約をまとめたもの。
プロジェクト概要が分かるREADME.md: 構成や開発フローをまとめたもの。

これら 2 つのファイルを Q chat に渡し、「今後のテストコード生成や提案は、このルールに従ってください」と伝えることで、Q Developer に“mody プロジェクトのルールブック”を読ませる形で AI オンボーディングを行いました。

テストケースの展開とモックコードの自動生成 今回バックエンドで採用した技術スタック（Python / FastAPI / SAM / Terraform）は、どれも私（李）は実務経験がないものでした。

単体テストの設計においても、人間と AI の役割分担を明確にしました。人間が「正常 2〜3 件＋異常 2〜3 件」の代表パターンだけを設計し、AIに「この代表パターンをベースに、他のケースも広げてください」と依頼。さらに「Cognito / DynamoDB / S3 などの呼び出しは、モック前提でテストコードを提案してください」と指示することで、人間は“仕様レビューと補強”に集中しました。

結果として、約 8 時間の作業で mody の全 API に対する単体テストを一通り整備（173 件）することができました。

4.3. 学習とレビューへの貢献：AIが書いたコードを「AIに解説してもらう」

チーム開発において、「AI にコードを書かせる」だけでタスク完了ではなく、「自分が依頼して生成されたコードを理解し、チームメンバーに説明できるようになる」ことまでがタスクだと考える必要があります。レビューを通らないコードはリリースできないからです。

使ったことのない技術や、エージェント型ツールが一気に吐き出した大量のコードを、人間だけで短時間に読み解くのは現実的ではありません。

そこで、以下の方法で「AI が書いたものを AI に説明してもらう」使い方をしました。

生成されたコードに対して AI に要約や解説を依頼する。
Mermaid でシーケンス図や依存関係図を書いてもらう。

これにより、短時間でコードの全体像を把握でき、チームメンバーにも自信を持って説明できるようになりました。また、AI に解説させる過程で、「当初の設計意図」と「実際に生成された実装」のズレが見つかることがあり、レビューに出す前の段階で不整合に気づけるという副次的な効果もありました。

4.4. チームの課題解決：外国人エンジニアの「言語とスキル」の壁をAIで乗り越える

開発途中で、実務経験がほぼゼロの新しい技術スタックへのキャッチアップと、外国人エンジニアとしての日本語でのコミュニケーションという二重の壁に直面しました。

学習への貢献：コードと対話するAI学習

短時間でキャッチアップするため、ドキュメントを読むよりも、コード生成 AI やチャット型 AI に対して「この書き方はアンチパターンにならないか？」などと質問を投げながら、コードを読み書きしつつその場で学ぶスタイルを取りました。自分が今書いているコードに対する AI のフィードバックをもらうのが最も効率的でした。

コミュニケーションへの貢献：「母国語→AI→日本語」フロー

レビュー依頼や設計メモを作成する際、以下のフローを取りました。

まず母国語（韓国語）で、自分の意図や設計方針を書き出す。
それを AI に渡して「レビュー依頼用の日本語に整えてください」と頼む。

また、チャット型 AI に「質問や意図は韓国語で書き、回答は日本語で返してもらう」という使い方も積極的行いました。これにより、自分の考えを「一番考えやすい言語」で整理しつつ、チームにそのまま共有できる「日本語のアウトプット」を同時に得られ、言語とスキルのギャップを AI で埋め、チームの成果に貢献できるという手応えを得ました。

5. まとめと内製化への次の一歩

5.1 ANGEL Dojoで得た技術的知見の集約

ANGEL Dojoでの開発を通じて、私たちは以下の技術的知見とプラクティスを確立しました。

アーキテクチャ: Biz/Dev/Opsの三視点で設計し、AWSマネージドサービスとIaCで高速開発基盤を構築した。
AI活用（機能）: Strands Agentsを活用し、LLMを「同僚」として扱うことで、短期間で複雑な審査ロジックを実装できた。
AI活用（開発）: Amazon Q Developerを「チームメイト」として位置づけ、AIオンボーディングや擬似コードベースの依頼、AIによるコード解説を通じて、生産性とコード品質を両立させた。
外国人エンジニアのAI活用: スキルアップには「コードと対話するAI学習」、チームへの貢献には「母国語→AI→日本語」のコミュニケーションフローが極めて有効であった。