ハイRyS！💎
はじめまして。カバー株式会社 コマース本部 ファンサービス部 ホロプラス開発チームバックエンドエンジニアのHです。本記事では、タレントチャンネルの開発で「体験のコア」をチーム全員で共有し、ドキュメント駆動とAI活用でスピードと品質を両立した実践を紹介します。
はじめに
ホロプラスは、推しの最新情報・配信スケジュール・公式コミュニティでの交流を楽しめるホロライブ公式アプリです。私たちは今、タレントさんが日常的に使いたくなる場所をつくることに力を入れています。
その中核となるのが、9月に段階的にリリースしたタレントチャンネルです。このチャンネルは今後の機能拡張の基盤です。スレッドやコメントで原文／翻訳を切り替えできる自動翻訳を標準搭載しました。 これにより異なる言語圏のファンとタレントさんの間で直接的なコミュニケーションが生まれています。
なぜドキュメント駆動で進めたか
今回の開発は、これまでと異なる挑戦でした。タレントチャンネルでは「タレントさんが日常的に使いたくなる場所」という体験を、チーム自身で考えていく必要がありました。さらに、今後の多くの機能拡張の基盤となるため、拡張性を見据えた設計も求められました。
要件や設計、API仕様は従来から文書化していました。今回はさらに踏み込み、ドキュメント駆動で進めました。タレントさんが実際に使う場所だからこそ、PdM、デザイナー、エンジニアがチーム全体で「体験のコア」を理解し、認識を合わせながら開発を進める必要があったためです。これらを文書化して合意形成することで、体験のコアを守りつつ柔軟に拡張できる設計を実現します。加えて、AI活用で開発速度の向上も見込まれます。
どう進めたか
PRD：PdMと「体験のコア」を先に言語化
PRD（Product Requirements Document：製品要件定義書）は、プロダクトの目的や解決すべき課題、実現する価値を明文化したドキュメントです。
誰のどの課題を、どんな最小実行可能な価値（MVP）で解決するかを定義しました。「タレントさんが日常的に使いたくなる場」を最優先ゴールに据え、言語の壁や安全な公式コミュニティといった非機能要件の方向性を定めました。
バックエンドエンジニアとして特に注力したのが翻訳機能の詳細仕様です。ホロプラスは9言語に対応していますが、既存の多言語対応では言語ごとにコミュニティが分断されていました。例えば、ベトナム語で投稿されたファンの声は、タレントさんの目に届きません。タレントさんがすべての言語の投稿内容を把握し、言語の壁を越えて1つのコミュニティを形成するには、翻訳機能が不可欠でした。
また、既存のスレッド投稿は入力する要素が多く、タレントさんに日常的に使ってもらいにくい課題もありました。これらの課題を踏まえ、チャンネルのUI設計（翻訳切り替え体験・投稿の簡素化）や翻訳データの保持方法をPdMと議論し、技術的な実現可能性と体験価値のバランスを見極めながらPRDに落とし込みました。例えば、タレントさんが投稿しやすいよう既存の入力要素を省略・自動入力しつつ、翻訳内容の齟齬を防ぐためにプレビュー画面で全言語を確認できる仕様にしました。
PRDは一度作って終わりではありません。チーム全体でアプリを触りながらフィードバックを交換し、継続的に改善していきました。細かな仕様変更が生じても、体験のコアがぶれないようにする方針を貫きました。
Design Doc：実装前にアーキテクチャの合意
Design Doc（設計ドキュメント）は、技術的な設計判断とその理由を記録するドキュメントです。実装に入る前に、サーバーエンジニア間で設計方針・代替案・トレードオフを文章化し、レビューを通じて合意形成を行いました。これにより、実装中の手戻りを防ぎ、チーム内で設計の意図を共有できます。また、将来の拡張時にも、当時の判断基準を振り返ることができます。
Design Docで議論した具体例として、翻訳データの保持方法を紹介します。ホロプラスではスレッド／コメントをスケーラビリティの観点からDynamoDB（AWSのNoSQLデータベース）で運用しており、翻訳を既存テーブルに埋め込むか、別テーブルで管理するかを比較検討しました。
検討の結果、別テーブル管理を選択しました。主な理由は、いいねなど頻繁に更新される共通データと翻訳データを分離することで、書き込みコストを最適化できるためです。また、別テーブル内では全言語を1アイテムにまとめる構造を採用しました。言語ごとに別アイテムにすると、一括取得時に複数回のリクエストが必要になり効率が低下します。1アイテムにまとめる構造では1レコードのサイズが大きくなり可読性が下がりますが、一括取得効率を優先しました。
データ構造を図で表すと以下のようになります（Threadsは既存テーブル、Translationsは新規テーブル）：
投稿時は、元投稿と翻訳データの作成をトランザクション処理で行い、データ整合性を確保しました。トランザクションは通常の約2倍の書き込みコストがかかりますが、選択言語で翻訳が表示されないという問題はユーザー体験に直結するため、コストよりもデータ整合性を優先しました。
事前にDesign Docで合意形成したため、設計者と実装者が別でも実装が円滑でした。実装中の設計議論も減りました。
OpenAPI：実装前にクライアントとすり合わせ
OpenAPIは、REST APIの仕様を記述するための標準フォーマットです。ホロプラスの開発は、iOS/Androidアプリを担当するクライアントチームと、サーバーを担当するサーバーチームに分かれています。OpenAPIのYAMLをサーバーチームが先に作り、クライアントチームとレビューを実施しました。標準化されたAPI仕様から双方のコードを自動生成できるため、実装の齟齬を防ぎながら並行で開発を進められます。以前はサーバーチーム内でOpenAPIを作成してクライアントに共有する形だったため、実装時に手戻りが発生していました。今回は実装前にクライアントとレビューし、こうした齟齬を防ぎました。例えば、クライアントチームから「このフィールドはサーバー側で自動取得できるので不要では？」という指摘があり、不要なフィールドを削除しました。こうしたすり合わせにより、手戻りを減らしてタレントチャンネルをスピーディーにリリースできました。
openapi: 3.0.3
paths:
/talent-channel/threads:
post:
summary: タレントチャンネル用多言語スレッドの投稿
requestBody:
content:
application/json:
schema:
type: object
required: [title, body, original_language, translations, channel_id]
properties:
title:
type: string
body:
type: string
original_language:
type: string
example: ja
channel_id:
type: string
translations:
type: object
required: [ja, en, id]
properties:
ja:
type: object
required: [title, body]
properties:
title: { type: string, example: "お知らせ" }
body: { type: string, example: "本日のライブについて..." }
# en, id等も同様の構造
ドキュメント駆動 × AIコーディング
PRD／Design Doc／OpenAPIといった構造化された仕様を先に整備し、チーム間の認識を合わせました。そのうえで、Claude Code（AnthropicのAIコーディング支援ツール）にこれらをコンテキストとして与え、機能実装・テスト実装・セルフレビューを行いました。
チームではさまざまなコーディングAIを試しましたが、当時のコード生成の精度や機能面を踏まえ、Claude Codeをメインに採用しています。仕様を詳細に定義するほどAIが正確なコードを生成できるため、ドキュメント駆動はチームコミュニケーションとAI活用の両面で効果的だと実感しています。
AI活用は実装だけでなく、開発のさまざまな場面に広げました。例えば、PRDをコンテキストとして与えて「この要件に基づいてDesign Docの骨子を作成して」と依頼すれば、検討すべき設計の論点を洗い出してくれます。従来は数時間かかっていたDesign Docの骨子作成は、コマンド化により30分〜1時間程度で完了するようになりました。併せて、フォーマットも統一できました。さらに、PRDとDesign Docを両方コンテキストに含めることで、「実装に必要なタスクを洗い出してチケット形式で出力して」といった指示で開発タスクに分割できます。こうした繰り返し行う作業を、構造化されたコンテキストと指示をClaude Codeのコマンドとして保存することで、チーム内で再現可能な手順として共有し、チームの資産としました。Pull Request（PR）の作成も、従来より数倍の速度で行えるようになりました。
一方で、AI活用で速度を上げつつも、体験のコアに直結するインターフェース設計は妥協せず厳密にレビューしました。 開発速度が上がったことでPRレビュー件数も増えましたが、チーム全体で丁寧にレビューを行い、品質を確保しました。
まとめ
タレントさんが日常的に使いたくなる場所づくりを目指し、タレントチャンネルと自動翻訳を中核とした多言語コミュニティ基盤を構築しました。PRDで「体験のコア」を固め、Design Doc／OpenAPIで技術的な詳細を詰めるドキュメント駆動のアプローチにより、チーム間の認識合わせを行いました。ドキュメントを通じてチーム全体で認識を合わせることで、実装中の手戻りを防ぎました。また、AIとの組み合わせにより、Design Doc作成時間を数時間から30分〜1時間程度に短縮し、PR作成も数倍の速度で進められるようになりました。開発速度が上がる一方で、ユーザー体験の根幹となる設計は妥協せず厳密にレビューし、手戻りを最小限に抑えながら、体験のコアを守ってタレントチャンネルをスピーディーにリリースできました。今後は、この基盤の上に機能を継続的に拡張していきます。
