最新LLMで“バイブコーディング”を実践(要件定義〜機能実装①)
Back to Top
はじめに
#現在、ChatGPT Pro と Claude Max (20×) を契約しており、生成AIによる開発工程の効率化の検証を進めています。
その実力を把握する目的で個人的にバイブコーディング(vibe coding)を試行してみました。モチベーションを保つため、筆者が最近プレイしているオンラインカードゲーム「Shadowverse:WB(以下、WB)」を対象としたシステムを題材に選びました。
前提
#ゲーム上達の近道は上手いプレイヤーのプレイを見ること、そして上手いプレイヤーに指導してもらう(コーチング) こととされます。
前者はプレイ動画・解説動画で容易に実践できますが、後者はハードルが高めです。そこで、最新の大規模言語モデル(LLM)で、対戦後レビューに相当する「AIコーチング」をどこまで実現できるかを試行してみることにしました。
※(わかる人向け)2025/8/12時点の筆者の「WB」プレイ状況。
- ナイトメア:460勝(「ミッドレンジナイトメア」でマスター到達)
- エルフ:50勝(「リノセウスエルフ」練習中)
- ビショップ:5勝(「守護ビショップ」を試行)
- 第2弾パックから開始の微課金のため、他リーダーは未着手
- グループは主にサファイア・ルビーを行ったり来たりしています(たまにダイヤモンド)
検討したシステム(概要)
#Shadowverse:WB対戦動画を自動解析し、重要場面抽出と改善提案を提示する対戦後レビューAI。レビューまでは現在のAIでも難しい場合は対戦動画の統計情報収集目的で使用する。
今回の取り組み範囲
#第一弾として、(1)要件定義、(2)基本設計、(3)1機能(カードDB)の実装を、人がプロンプトで指示 → AIが生成 → 人が確認・修正指示 の流れで実施しました。
要件定義・基本設計
#1) 要件定義(作成と補強)
#本来の意味でのバイブコーディングでは設計書から作成する必要はないと思われますが、初期のアイデア出しと、AIに指示を渡す際にドキュメントを参照させて説明を省略を出来るように、要件定義書・基本設計書を作成する所から始めることにしました。
使用モデルは ChatGPT 5 Thinking(8月時点の最新推論モデル)とし、本企画の説明を与え、「要件定義書を作成して」というプロンプトを実行しました。
初期成果として、目的・スコープ、ユースケース、成果物/非機能、全体構成、データモデルなどが一通り出力されましたが、法務・コンプライアンス面考慮されていないこと、ゲームの理解が一般的なカードゲームの知識や前作Shadowverseに基づいている所など、幾つか気になるところがありました。
そこで、追加のプロンプト修正を依頼しました。(プロンプトは「権利面やコンプライアンス面での懸念事項を調査し、追記して」「(公式ページURL)を参考にWBのゲームシステムをまとめて」)
以下、実際の生成結果です。
要件定義書(クリックで開く)
Shadowverse: Worlds Beyond プレイ動画解析AIシステム
#要件定義書 v1.0
#文書ID: REQ-2025-001
作成日: 2025-08-09
最終更新: 2025-08-09
文書種別: 要件定義書
承認者: -
ステータス: ドラフト
改訂履歴
#
版 日付 変更内容 作成者 1.0 2025-08-09 初版作成(システム設計書から要件定義書へ再構成) -
目次
#
1. はじめに
#1.1 目的
#本書は、Shadowverse: Worlds Beyond(以下、WB)のプレイ動画を自動解析し、戦略的アドバイスを生成するAIシステムの要件を定義する。
1.2 スコープ
#
- 対象範囲: WBのプレイ動画の解析、カード認識、ゲーム状態推定、戦略アドバイス生成
- 対象外: リアルタイム対戦支援、ゲームクライアントの改変、自動プレイ機能
1.3 想定読者
#
- プロジェクトマネージャー
- システムエンジニア
- 開発チーム
- 法務・コンプライアンス担当者
2. システム概要
#2.1 システム名称
#Shadowverse: Worlds Beyond プレイ動画解析AIシステム
2.2 システムの目的
#WBプレイヤーの対戦後レビューを支援し、プレイスキル向上に貢献する。
2.3 システムの位置づけ
#
- 対戦後のレビュー・学習支援ツール
- 非公式・非提携のサードパーティツール
- 教育・研究目的での利用を想定
3. ステークホルダー
#3.1 主要ステークホルダー
#
ステークホルダー 役割 関心事項 WBプレイヤー エンドユーザー プレイ改善、戦略学習 開発チーム システム開発・運用 技術的実現性、保守性 法務担当 コンプライアンス確保 著作権、利用規約遵守 コンテンツクリエイター 動画制作者 解析結果の活用、配信素材
4. 業務要件
#4.1 現状の課題
#
- プレイミスの客観的な把握が困難
- 最適なプレイラインの学習に時間がかかる
- 対戦の振り返りが主観的になりがち
4.2 システム導入による改善
#
- 客観的なプレイ分析の提供
- 代替プレイラインの提示
- 重要場面の自動抽出
4.3 業務フロー
#flowchart LR A[動画録画] --> B[動画アップロード] B --> C[自動解析] C --> D[レポート生成] D --> E[プレイヤーレビュー] E --> F[スキル向上]
5. 機能要件
#5.1 機能一覧
#
機能ID 機能名 優先度 説明 F-01 動画取込API 必須 プレイ動画のアップロード・管理 F-02 フレーム抽出 必須 動画からのフレーム切り出し F-03 UI要素検出 必須 HP/PP/EP等のゲーム情報認識 F-04 カード認識 必須 OCRと画像認識によるカード特定 F-05 イベント抽出 必須 プレイ/攻撃/進化等のアクション検出 F-06 状態復元 必須 ゲーム状態の時系列推定 F-07 助言生成 必須 戦略的アドバイスの生成 F-08 レポート生成 必須 解析結果のレポート化 F-09 ナレッジ取得 必須 カード情報の収集・管理 F-10 ベクトル索引 推奨 RAGによる知識検索 5.2 機能詳細
#F-01: 動画取込API
- 入力: 動画ファイル(MP4, AVI, MOV)
- 処理: ファイルアップロード、バリデーション、ジョブ登録
- 出力: ジョブID、処理ステータス
F-04: カード認識
- 要求精度: Top-1正解率 ≥ 95%(高解像度動画)
- 認識方式:
- OCR経路: カード名・コストのテキスト認識
- 画像経路: カードアートの画像類似度検索
- 対応言語: 日本語
F-07: 助言生成
- 生成内容:
- 推奨アクション(Top-3)
- リスク評価
- 代替プレイライン
- 根拠(参照カード情報)
6. 非機能要件
#6.1 性能要件
#
項目 要求値 測定条件 動画解析速度 15分動画を2分以内 GPU: A100×1 カード認識精度 Top-1: 95%以上 1080p動画 イベント検出精度 F1スコア: 0.90以上 - 同時処理数 100ジョブ並列 - レスポンスタイム API応答: 1秒以内 95パーセンタイル 6.2 可用性要件
#
- 稼働率: 99.5%以上(月間)
- 計画停止: 月1回、最大2時間
- 障害復旧: RPO: 1時間、RTO: 4時間
6.3 セキュリティ要件
#
- 認証: OAuth 2.0 / JWT
- 通信: TLS 1.3以上
- データ暗号化: AES-256
- アクセス制御: RBAC
- 監査ログ: 全API呼び出しの記録
6.4 拡張性要件
#
- スケールアウト: ワーカーノードの水平スケール対応
- モジュール追加: プラグイン形式での機能拡張
- 多言語対応: 英語版への拡張を考慮
7. 外部インターフェース要件
#7.1 ユーザーインターフェース
#
- Web UI: レスポンシブデザイン(PC/タブレット対応)
- 主要画面:
- 動画アップロード画面
- 解析進捗表示
- レポート閲覧
- カード詳細表示
7.2 外部システム連携
#
システム 用途 プロトコル YouTube API 動画メタデータ取得 REST 攻略サイト カード情報収集 HTTP/スクレイピング クラウドストレージ 動画保存 S3互換API 7.3 API仕様
## 動画解析API POST /api/v1/analyze Request: - video_url: string - options: object Response: - job_id: string - status: string # 結果取得API GET /api/v1/analyze/{job_id} Response: - status: string - progress: number - results: object
8. データ要件
#8.1 カードマスタデータ
#
項目 型 説明 card_id string カード識別子 name_jp string カード名(日本語) cost integer コスト attack integer 攻撃力 defense integer 体力 card_class string クラス card_type string タイプ(フォロワー/スペル/アミュレット) ability_text string 能力テキスト image_url string カード画像URL is_token boolean トークンフラグ 8.2 イベントデータ
#{ "timestamp": 123.45, "turn": 5, "actor": "ally", "event_type": "play", "card_id": "10001110", "targets": ["unit_001"], "value": 3 }
8.3 データ保持期間
#
- 動画ファイル: 30日間
- 解析結果: 90日間
- 統計データ: 1年間
9. 法務・コンプライアンス要件
#9.1 基本方針
#
- 対戦後レビュー専用: リアルタイム対戦補助は提供しない
- 非提携の明示: Cygames非公式である旨を明記
- 著作権遵守: 必要最小限の引用、出典明記
9.2 禁止事項
#
- ゲームクライアントの改変
- メモリ読み取り、通信傍受
- 自動プレイ、BOT機能
- WIKI画像の再配布
- 大会中のリアルタイム利用
9.3 必須表記
#© Cygames, Inc. 本サービスはCygamesの提供・後援ではありません。
9.4 データ収集
#
- robots.txt遵守: クローラーの適切な制御
- レート制限: 1秒1リクエスト以下
- 削除要請対応: 72時間以内の対応
10. 制約事項
#10.1 技術的制約
#
- GPU必須(推論処理)
- 日本語OCRの精度限界
- 動画品質による認識精度の変動
10.2 運用上の制約
#
- 24時間365日のサポートは提供しない
- 個人情報を含む動画は処理対象外
- 商用利用は別途ライセンス必要
10.3 法的制約
#
- 各地域の著作権法・規制の遵守
- プラットフォーム利用規約の遵守
- 大会規約への配慮
11. 前提条件
#11.1 技術的前提
#
- インターネット接続環境
- 対応ブラウザ: Chrome/Firefox/Safari最新版
- 動画形式: H.264/H.265エンコード
11.2 運用前提
#
- ユーザーは動画の利用権限を保有
- 解析結果は参考情報として利用
- システムメンテナンス時間の許容
12. 用語定義
#
用語 定義 WB Shadowverse: Worlds Beyond PP プレイポイント(マナ) EP エボルヴポイント(進化権) RAG Retrieval Augmented Generation(検索拡張生成) OCR Optical Character Recognition(光学文字認識) トークン ゲーム中に生成される特殊カード リーサル 勝利確定の一手
13. 参考資料
#13.1 関連文書
#
- CLAUDE.md - プロジェクト実装ガイドライン
- database/schema_design.md - データベース設計書
- crawlers/README.md - クローラー実装仕様
13.2 外部参照
#
付録A: ユースケース詳細
#UC-01: 対戦動画の解析
#アクター: WBプレイヤー
事前条件: 動画ファイルを保有
基本フロー:
- プレイヤーが動画をアップロード
- システムが動画を解析
- カード・アクションを認識
- ゲーム状態を推定
- 戦略アドバイスを生成
- レポートを表示
代替フロー:
- 2a. 動画品質が低い場合、警告を表示
- 3a. カード認識に失敗した場合、候補リストを表示
事後条件: 解析レポートが生成される
付録B: 画面イメージ
#B.1 メインダッシュボード
#
- 動画アップロードエリア
- 解析履歴一覧
- 統計サマリー
B.2 解析レポート画面
#
- タイムライン表示
- 重要場面のハイライト
- 推奨アクションと根拠
- カード使用履歴
文書終了
ゲーム概要(クリックで開く)
対戦する
#
- カードを手に入れる
- デッキを作成する
- 対戦する
- バトルTips
対戦
#40枚のカードで作成したデッキでバトルでき、カードをプレイ(使用)して戦います。対戦相手の体力を0にすれば勝利です。
バトル画面の見方
#画面をスクロールすると各項目の説明が表示されます。
リーダー
#画面中央にプレイヤーの分身として戦うリーダーキャラクター(例:ドライツェーン)が表示されます。手前が自分、奥が相手です。
EP(進化ポイント)/ SEP(超進化ポイント)
#カードを「進化」「超進化」するときに使用するポイント。EPは黄色、SEPは紫色で、それぞれバトル中に2回使用できます。
体力アイコン
#プレイヤーの残り体力を表示。最大値は〖20〗※で、相手の体力を〖0〗にすれば勝利。
※カードの能力によって変動することがあります。ターン終了ボタン
#自分のターンを終了したいときに押します。ボタンの周囲のゲージが残り時間で、青いゲージがなくなると自動でターン終了します。
PP(プレイポイント)
#カードをプレイするためのポイント。カードのコスト分だけ数字と緑のポイントが減ります。ターンが進むごとに1ずつ増え、最大10まで。自分のターン開始時に最大値まで回復します。
エクストラPP
#後攻時に使えるプレイポイント。使用すると一時的に残りPPを1つ増やせます。
手札
#所持カードが表示されます。最大9枚まで。10枚目以降は最後に引いたカードが墓場に置かれるため、枚数に注意。
場のカード
#画面中央の「場」にカードを出してバトルを進めます。場には最大5枚まで出せます。出ているカードには能力を示すアイコンが表示されます。
主な能力の例:
- 特定のタイミングで能力が働く
- ラストワード
- 必殺
- ドレイン
- 土の印
- アクト
クレスト
#特定のカード能力でリーダーが持つアイコン。タップで能力を確認可能。最大5つまで所持できます。
バトルログ
#相手と自分の行動履歴を遡って確認できます。
メニューボタン
#設定やバトルのリタイアを行えます。リタイアすると敗北扱いですが、バトルの途中でも終了可能です。
バトルの流れ
#シャドバの基本ルール
#40枚のデッキを使ってバトルします。相手リーダーの体力を0にすると勝利です。
先攻 / 後攻
#「先攻」「後攻」はランダムで決定。バトル開始画面で確認できます。以下は「後攻」例で説明します。
カードの引き直し
#開始時に4枚引きます。最初に引いたカードは自由に「引き直し」可能。序盤はコストの小さいカードを残すのが無難です。
ターン開始 / カードをプレイ(使用)する
#ターン開始時に1枚引きます。PPを消費して手札のカードをプレイしましょう。
※出したばかりのカードは基本的に攻撃できません。攻撃
#次の自分ターンでPPが2になり、コスト2以下のカードがプレイ可能に。前のターンに出したカードは攻撃できるようになるため、「相手のカード」か「相手のリーダー」を攻撃しましょう。
※「突進」を持つカードは出したターンでも「相手のカード」を攻撃できます。進化
#後攻は4ターン目、先攻は5ターン目にEPを使ってフォロワーを「進化」可能。進化で攻撃力/体力が+2/+2され、出したターンに「相手のカード」を攻撃できます。
超進化
#後攻6ターン目、先攻7ターン目にSEPを使って「超進化」可能。攻撃力/体力が3/+3に強化され、出したターンに「相手のカード」を攻撃できます。
さらに自分のターン中は受けるダメージが0、能力による破壊を受けません。相手フォロワーを攻撃して破壊したとき、相手リーダーに1ダメージを与えます。勝敗
#攻撃を繰り返し、相手リーダーの体力を0にすれば勝利。さまざまな能力を持つカードを使いこなしましょう。
ソロプレイ
#Shadowverse: Worlds Beyondでは3種類のソロプレイが用意されています。
- プラクティスバトル:CPUと好きなデッキで練習できます。
- ストーリー:重厚な物語を楽しめます。
- レッスン:バトルの基本や各クラスの戦い方を学べます。
AIアドバイス機能
#プラクティスバトルではナビゲーターのエースが遊び方を教えてくれるAIアドバイス機能付き。CPU対戦で基本的な動きを覚えましょう。
バトルガイド
#
- バトルチュートリアル:エースから基本要素のレクチャーや、クラスごとのデッキタイプを学習。
- パズルレッスン:基本能力や各クラス特有の能力を、実戦に近いパズル形式で学べます。
オンラインバトル
#他ユーザーとの対戦方法は2種類あります。
- ランダムマッチ:ランクをかけて争う「ランクマッチ」と、ランク変動のない「フリーマッチ」。
- ルームマッチ:ルームを作って特定のユーザーと対戦可能。ルーム入室で観戦もできます。
バトルTIPS
#フォロワー
#カードの分類の1つです。
プレイしたら場に出て、次のターンから、相手のリーダーやフォロワーを攻撃できます。スペル
#カードの分類の1つです。
プレイしたら能力が働いて、すぐに墓場に置かれる使い切りのカードです。アミュレット
#カードの分類の1つです。
プレイしたら場に出て、能力が働きます。
アミュレットは攻撃できず、攻撃されることもありません。クレスト
#カードの分類の1つです。
クレストを持ったらリーダーエリアに置かれて、能力が働きます。
リーダーエリアごとに、同名のクレストは重複して置けません。トークン
#「操り人形」のようなトークンカードはデッキに編成できませんが、バトル中に他のカードの能力によって場に出たり手札に加わったりします。
クラス
#カードが持つ特性の1つで、「エルフ」「ロイヤル」「ウィッチ」「ドラゴン」「ナイトメア」「ビショップ」「ネメシス」「ニュートラル」の8つがあります。
リーダーにもクラスがあり、ネメシスのリーダーであるドライツェーンは、ネメシスのカードが使えます。
ニュートラルのカードはどのリーダーでも使えます。タイプ
#カードが持つ特性の1つで、「人形」などがあります。
タイプ自体にはバトルにおける意味はありませんが、特定のタイプにだけ働く能力によって参照されます。
カードはタイプを持たないことも、複数のタイプを持つこともあります。コスト
#カードをプレイするために必要なPPを表す値で、カードの左上に書かれています。
カードをプレイしたとき、コストの値だけPPを消費します。攻撃力
#フォロワーが持つ値で、カードの左下に書かれています。
フォロワーやリーダーを攻撃したか、フォロワーに攻撃されたときに、攻撃力の値に等しいダメージを与えます。体力
#フォロワーやリーダーが持つ値で、カードの右下に書かれています。
フォロワーの体力が0になると、そのフォロワーは破壊されます。
リーダーの体力が0になると、バトルに敗北します。バトル
#ユーザー同士がデッキを使って戦うことです。
どちらかのリーダーの体力が0になると決着します。リーダー
#ユーザーの分身として戦う「ドライツェーン」などのことです。
リーダーの体力が0になるとバトルに敗北します。デッキ
#バトルで使う40枚のカードのことです。
ターン開始時にデッキからカードを1枚引きます。
デッキが0枚のときにカードを引くとバトルに敗北します。場(ば)
#プレイしたフォロワーやアミュレットを出す場所です。
自分の場には5枚まで出すことができます。手札
#カードを持っておく場所です。
自分の手札には9枚までカードを持っておくことができます。寄せ場(墓場)
#使い終わったカードの枚数を表す値です。
フォロワーやアミュレットが破壊されたときや、スペルをプレイしたときなどに増えます。リーダーエリア
#持ったクレストを置いておく場所です。
自分のリーダーエリアには5つまで置いておくことができます。PP(プレイポイント)
#カードをプレイするために消費するポイントです。
自分のターンの開始時に、PP最大値が+1されて上限まで回復します。
PP最大値は10より大きくなりません。EP(進化ポイント)
#フォロワーを進化させるために消費するポイントです。
2つのEPを持ってバトルを開始します。SEP(超進化ポイント)
#フォロワーを超進化させるために消費するポイントです。
2つのSEPを持ってバトルを開始します。プレイ
#コストの値だけPPを消費して、カードを手札から使う行動です。
ターン
#バトルでは、先攻と後攻が交互に操作を行います。
自分のターンにはカードのプレイや、攻撃などができますが、相手のターンには操作ができません。
進化可能ターンより前は約60秒、進化可能ターン以降は約75秒の制限時間があります。攻撃
#自分のフォロワーが、相手のリーダーかフォロワーへダメージを与える行動です。
相手のフォロワーを攻撃したときは反撃を受けて、交戦相手の攻撃力に等しいダメージを受けます。
フォロワーは場に出た次のターンから、1ターンに1回、攻撃できます。初手の引き直し
#バトル開始時にデッキから引いた4枚のカードのうち、不要なカードを好きな枚数だけ選んで引き直すことができます。
選んだカードそのものをふたたび引くことはありませんが、同名のカードを引く可能性はあります。エクストラPP
#一時的にPPを増やすことができるバトルシステムです。
自分のターン中に、エクストラPPボタンを押すことで、そのターン中に消費できるPPを1増やすことができます。
エクストラPPは後攻だけが使えます。
6ターン目の開始時に使用済みであれば再度使用可能になるので、1回のバトルで最大2回使えます。進化
#自分のフォロワーを強化する行動です。
進化したフォロワーは+2/+2して、場に出たターンであってもフォロワーを攻撃できるようになります。
進化したフォロワーはさらに進化することはできません。
先攻は5ターン目、後攻は4ターン目から、1ターンに1回、EPを1つ消費することでフォロワー1枚を進化させることができます。
EPを消費して行う進化と、SEPを消費して行う超進化は同じターンには行えません。超進化
#自分のフォロワーを強化する行動です。
超進化したフォロワーは+3/+3して、下記の能力を持ちます。
- 場に出たターンであってもフォロワーを攻撃できます。
- 自分のターン中、受けるダメージを0にして、能力によって破壊できません。
- 相手のフォロワーを攻撃して破壊したとき、相手のリーダーに1ダメージを与えます。これは攻撃中に能力によって破壊した場合にも働きます。
超進化したフォロワーは進化したフォロワーとしても扱われます。
先攻は7ターン目、後攻は6ターン目から、1ターンに1回、SEPを1つ消費することでフォロワー1枚を超進化させることができます。
EPを消費して行う進化と、SEPを消費して行う超進化は同じターンには行えません。コンボ
#「このターン中に自分がプレイしたカードの枚数」を表します。
コンボが指定された値以上のときに働く能力もあり、その能力を持つカードをプレイした場合は、そのカード自身も枚数に数えます。スペルブースト
#自分がスペルをプレイしたとき、自分の手札すべては1回スペルブーストします。
スペルブーストすること自体にはバトルにおける意味はありませんが、スペルブースト時を持つカードはスペルブーストしたときに、能力が働きます。土の秘術
#自分の場の土の印の数が指定された値以上のときに、その値だけ消費して、能力が働きます。
土の印
#土の印を持つアミュレットが場に出たとき、土の印の数が1になって、カードの右下に表示されます。自分の場に他の土の印・アミュレットがある場合、それらすべてを消滅させて、土の印の数を合算します。
土の印を持つカードは能力で破壊できず、相手の能力で選べません。
土の印の数が0になると、破壊されます。
「土の印を+2する」能力が働いたとき、自分の場に土の印・アミュレットがあるなら、それの土の印の数を+2します。土の印・アミュレットがないなら、「大地の魔片」1枚を自分の場に出して、それの土の印の数を2にします。覚醒
#「自分のPP最大値が7以上」という状態を表します。
ネクロマンス
#自分の墓場が指定された値以上のときに、その値だけ消費して、能力が働きます。
リアニメイト
#このバトル中に破壊された、コストが指定された値以下の中で最大の自分のフォロワーと同名のフォロワー1枚を、死者・タイプを持たせて場に出す能力です。
コスト最大のフォロワーが複数あるなら、その中からランダムに選ばれます。
同名のカードが複数回破壊されている場合、そのぶん選ばれる確率が上がります。疾走
#場に出たターンでも攻撃できる能力です。
突進
#場に出たターンでもフォロワーを攻撃できる能力です。
守護
#場にいる限り、守護を持たないフォロワーやリーダーを攻撃させない能力です。
潜伏や威圧と守護を同時に持っている場合は、潜伏や威圧が優先されて、守護は無効になります。必殺
#攻撃するか攻撃されることによって相手のフォロワーにダメージを与えたとき、相手のフォロワーを破壊する能力です。
攻撃力が0の場合や、相手の能力によって与えるダメージが0になった場合でも、必殺能力は働きます。潜伏
#相手の能力で選ばれず、相手のフォロワーから攻撃されない能力です。
攻撃するか、潜伏を持つフォロワーが能力によってダメージを与えると、潜伏を失います。ドレイン
#攻撃によってダメージを与えたとき、それと同じだけ自分のリーダーを回復する能力です。
カウントダウン
#カウントダウンを持つカードが場やリーダーエリアに出たとき、カウントが指定された値になって、カードの右下に表示されます。
自分のターン開始時にカウントを-1して、カウントが0になると破壊されます。威圧
#相手のフォロワーから攻撃されない能力です。
オーラ
#相手の能力で選ばれない能力です。
ランダムな対象に働く能力の対象になることはあります。バリア
#バリアを持つフォロワーやリーダーがダメージを受けるとき、そのダメージを0にする能力です。バリアは1回働いたら失います。
ファンファーレ
#手札からプレイして、場に出たときに、能力が働きます。
手札やデッキから直接場に出したり、カードを生成して場に出したときには働きません。ラストワード
#破壊されたときに、能力が働きます。
消滅や変身したときには働きません。進化時
#EPを消費して進化したときや、SEPを使って超進化したときに、能力が働きます。
超進化時
#SEPを消費して超進化したときに、能力が働きます。
攻撃時
#フォロワーやリーダーを攻撃するときに、能力が働きます。
能力はダメージを与え合う前に働きます。交戦時
#フォロワーを攻撃するか、フォロワーから攻撃されるときに、能力が働きます。
リーダーを攻撃するときには働きません。
能力はダメージを与え合う前に働きます。エンハンス
#エンハンスを持つカードをプレイするとき、自分の残りのPPが指定された値以上なら、コストではなくエンハンスの値だけPPを消費して、能力が働きます。
モード
#複数の能力から、指定された数の能力を選んで働かせる能力です。
能力が働く条件を満たしていないモードも選ぶことはできますが、その能力は働きません。融合
#手札の指定されたカードを素材として融合し、カードを強化する能力です。
融合を持つ手札のカードは、1ターンに1回、カード詳細にある「融合ボタン」を押すことで融合できます。
枚数の指定がない場合は、一度に素材を何枚でも融合できます。
融合されたカードは手札から取り除かれて、墓場は増やしません。アクト
#アクトを持つ場のアミュレットは、1ターンに1回、カード詳細にある「アクトボタン」を押すことでアクトでき、能力が働きます。
アクトに必要なコストが指定されている場合もあり、自分の残りのPPが指定された値以上なら、その値だけPPを消費して、能力が働きます。+1/+2する
#フォロワーの攻撃力を+1して、体力と体力の最大値を+2することを表します。
「-1/-2する」の場合は、攻撃力を-1して、体力と体力の最大値を-2することを表します。ダメージ
#フォロワーやリーダーの体力を、ダメージの値だけ減らします。
ダメージを増減させる能力は、ダメージを特定の値にする能力よりも先に働きます。
ダメージの値は0より小さくなりません。回復
#フォロワーやリーダーが受けているダメージを取り除いて、体力を増やすことです。
体力の最大値を超えて回復することはできません。引く
#カードをデッキから手札に移動させることです。
手札の枚数の上限を超えたカードは手札に加えられず、墓場を増やします。手札に加える
#カードを生成して手札に加えることです。
手札の枚数の上限を超えたカードは手札に加えられず、墓場を増やします。場に出す
#手札やデッキから場に移動させたり、場にカードを生成したりすることです。
手札やデッキから場に出す場合、場の枚数の上限を超えるカードは移動しません。
カードを生成して場に出す場合、場の枚数の上限を超えるカードは場に出ず、墓場も増やしません。破壊
#フォロワーやアミュレットを場から取り除くことです。
破壊された数だけ、墓場を増やします。消滅
#墓場を増やさずに、カードを場や手札、デッキから取り除くことです。
カードが消滅したときは、ラストワードなど、カードが破壊されたときに働く能力は働きません。場を離れる
#場のカードが破壊や消滅、他の場所に移動したりして場から取り除かれることです。
場のカードが変身した場合は、場を離れたとは扱いません。ダメージを割りふる
#フォロワーの体力の値までのダメージを、場に出たのが古いフォロワー(向かって右)から順に割りふります。
最後のフォロワーに割りふってもダメージが余っている場合、対象にリーダーが含まれているならリーダーに、含まれていないなら最後のフォロワーに与えられます。
フォロワーが変身しても、割りふられる順番は変わりません。選ぶ
#場や手札のカードやリーダーの中から、指定された数のカードやリーダーを選ぶことです。
選ぶ能力を持つスペルは、指定された数すべてを選ぶことができるときのみプレイできます。
選ぶファンファーレ能力を持つフォロワーやアミュレットは、指定された数すべてを選ぶことができなくてもプレイでき、できる限り選んで能力が働きます。コピー
#場や手札などにあるカードを複製したカードのことです。
受けたダメージやかかっている効果は引き継がれますが、このターンに攻撃やアクトしたかどうかは引き継がれません。デッキに戻す
#カードを場や手札からデッキに移動させることです。
手札からデッキに戻した場合、かかっている効果は引き継がれます。手札に戻す
#カードを場から手札に移動させることです。
受けたダメージやかかっている効果は引き継がれません。
手札の枚数の上限を超えたカードは手札に加えられず、墓場を増やします。捨てる
#カードを手札から取り除くことです。
捨てた枚数だけ、墓場を増やします。変身する
#カードが別のカードになることです。
受けたダメージやかかっている効果、このターンに攻撃やアクトしたかどうかは引き継がれません。
フォロワーに変身した場合、次のターンから、相手のリーダーやフォロワーを攻撃できます。連携
#「このバトル中に場に出た自分のフォロワーの枚数」を表します。
連携が指定された値以上のときに働く能力もあります。カード一覧(Deck Portal)
#概要
#全カードを横断検索できる公式データベース。ページ上部のフィルタで条件を指定し、「検索」「詳細検索」で絞り込みできます。「すべてクリア」で条件の一括解除が可能です。ページ内には「クラスの特徴」への導線もあります。
- 主なフィルタ:クラス/カードパック/コスト/分類(フォロワー・スペル・アミュレット)/レアリティ(ブロンズ・シルバー・ゴールド・レジェンド)/攻撃力/体力/タイプ(Trait)/キーワード能力(Keyword)
- オプション:トークンを含む、カードスタイル有のみ
- 検索UIは「カード一覧」本体と「詳細検索」モーダルのどちらからでも利用可能。
(UI表記は言語切替で若干異なりますが、項目は同等です)検索UIの項目(抜粋)
#
- クラス:8クラスを選択(複数選択可)
- カードパック:弾やセットで絞り込み
- コスト/攻撃力/体力:範囲指定対応
- 分類:フォロワー/スペル/アミュレット
- レアリティ:ブロンズ/シルバー/ゴールド/レジェンド
- タイプ(Trait):部族・種別など
- キーワード能力(Keyword):能力タグで絞り込み
- トークンを含む:生成物(トークン)も結果に含める
- カードスタイル有のみ:スタイルが用意されたカードのみ表示
URLパラメータ例
#検索条件はURLに反映され、共有・再現が可能です(例:
?card_set=...&class=...&cost=...&page=...
など)。カード詳細ページで見られる情報(例)
#カード名・クラス・タイプ・レアリティ・コスト・ステータス(攻撃力/体力)、各テキスト(進化前/進化後/超進化後)、関連カードなど。
テキストには以下のようなキーワードが登場します(実例の要約):
- ファンファーレ:手札1枚をデッキに戻して1ドローし、「土の印」を+1 など
- カウントダウン / ラストワード / アクト:例)カウント3、ラストワードで2ドロー、コスト1のアクトでカウント-1
- エンハンス:例)エンハンス5で自動進化、進化後ならラストワードでランダム4ダメージ
- 場へのトークン展開や相手への攻撃制限付与:例)相手の場に「ナイト」を出し、相手フォロワーに攻撃制限を付与 など
※上記は実カード個別ページの記述を要約した例です。正式な文言・数値は各カード詳細ページを参照してください。
2) 基本設計(要件定義を入力として生成)
#次に要件定義書とゲーム概要を入力として、基本設計の作成を依頼しました。プロンプトでは「添付した要件定義所とゲーム概要を基に基本設計書を作成して。」と指示しています。
その結果、機能一覧と責務境界、共通設計(データ識別子・ストレージ・権利表記)、各機能の入出力・SLO、テスト観点・KPI などが生成されました。
以下、実際の生成結果です。
基本設計書(クリックで開く)
WBプレイ動画解析AI|ソフトウェア基本設計書(機能別) v1.0(ブラッシュアップ)
#最終更新: 2025-08-08 JST 対象: v0.1 からの改訂。**「シャドウバースWBゲーム概要」**の用語/数値を仕様へ反映し、**F-09/10(クローラ/RAG)**を拡充。
0. 目次
#
- 本書の位置づけ / 前提
- 機能一覧と責務境界(更新)
- 共通設計(データ、ログ、認証、権利表記)
- 各機能の基本設計(詳細更新)
- テスト観点(機能別)
- KPI監視/ダッシュボード
- セキュリティ/法務
- 変更履歴
1. 本書の位置づけ / 前提
#
- 目的: システム設計を実装レベルに落とし込む。I/O、主要フロー、データ項目、エラー、計測、SLO を明確化。
- スコープ: オフライン解析バッチ。将来の低レイテンシは非機能/拡張に記載。
2. 機能一覧と責務境界(更新)
#
機能ID 名称 主な責務 入力 出力 主な依存 F-01 動画取込API 署名URL発行、ジョブ作成、キュー投入 video_url, options job_id S3, Queue, PG F-02 フレーム抽出 デコード、シーンカット/キーフレーム、音声分離 video_object frameset(meta) FFmpeg F-03 UI要素検出 HP/PP/EP/SEP/残時間/手札枚数/墓場 frameset ui_timelines YOLO, OCR F-04 カード認識 矩形抽出→OCR/画像類似→融合 frameset, ui_timelines card_detections CLIP/OCR F-05 イベント抽出 play/attack/evolve/super_evolve/... detections events 規則+学習 F-06 状態復元 ルール拘束の状態遷移 events, ui_timelines states ルール機械 F-07 助言生成 候補手探索、RAG-LLM states, knowledge advices LLM, RAG F-08 レポート/HL タイムライン、SRT、短尺MP4 events, states, advices report assets FE F-09 ナレッジ取得 攻略WIKIの差分クロール、正規化 crawl_targets card_db, knowledge_db HTTP/HTML F-10 ベクトル索引 テキスト/画像の埋め込み・近傍検索 card_db, knowledge_db vector_index Qdrant/Milvus F-11 公開API /v1/analyze, /v1/advise, /v1/cards HTTP JSON FastAPI F-12 運用/監視 メトリクス、トレース、ドリフト 各種イベント Dashboards/Alerts Prometheus
3. 共通設計
#3.1 データ識別子
#
job_id
(ULID),event_id
(job_id/seq),state_id
(job_id/turn/side),card_id
(official-derived),kb_doc_id
。3.2 ストレージ
#
- S3/MinIO: 原動画/フレーム/サムネ/ハイライト/レポートJSON/SRT。
- PostgreSQL: jobs, analyses, cards, card_sets, card_keywords, card_traits, archetypes, decks, knowledge_docs, knowledge_chunks, sources, crawl_runs, advice_logs。
- Parquet: events/states アーカイブ。
3.3 認証/認可/クレジット
#
- APIキー/OAuth2(CC)。管理系はRBAC。UIフッターに
© Cygames, Inc.
と非提携表示/出典を常時掲示。
4. 各機能の基本設計(詳細)
#4.1 F-01 動画取込API(v0.1から変更軽微)
#
- 入出力/エラー/SLOは従来通り。
4.2 F-02 フレーム抽出
#
- 代表フレームは SSIM シーン差分 + キーフレーム。fps=15/30 をオプション。
4.3 F-03 UI要素検出(更新)
#
- 検出器: HP/PP/EP/SEP/残時間バー/手札スロット/墓場/エクストラPPボタン。
- OCR: 数字・記号専用ヘッド。残時間バーは帯長の連続量回帰で補助。
4.4 F-04 カード認識(更新)
#
- 2経路(OCR/画像)をビーム融合。候補テキストとカードDBの効果テキスト整合で再ランク。
4.5 F-05 イベント抽出(拡張)
#
- 新規 type:
super_evolve, fusion, act, enhance, extra_pp_use, crest_gain, countdown_tick, transform, bounce, banish
。- 検出根拠: アニメ演出/テロップ/数値変化/効果音(任意)。
4.6 F-06 状態復元(拡張)
#
- スキーマに
sep, extra_pp_available, crests[], counters{}
を追加。- 整合チェック: 手札9/盤面5/PP≤10、EP/SEP回数制限、超進化は進化扱い。
4.7 F-07 助言(更新)
#
- ルールベース: リーサル探索、EP/SEPとエクストラPPの最適消費、守護突破、バリア考慮。
- RAG入力: (a) 対象カードの評価/使い方、(b) 現デッキアーキタイプのゲームプラン、(c) マッチアップ別ガイドの要旨。
4.8 F-08 レポート/ハイライト
#
- 重要ターン抽出に EP/SEP使用 と 大打点/全処理 の重みを追加。
4.9 F-09 ナレッジ取得(本改訂の中心)
#4.9.1 公式カードDBクローラ
- ソース: 公式 Deck Portal「カード一覧」。
- 収集: 名前/クラス/タイプ/コスト/ATK/DEF/レアリティ/セット/キーワード/タイプ/トークン可否/効果テキスト/進化後テキスト/画像URL/詳細URL。
- 設定: 「トークンを含む」ON/OFF、言語=ja。
- ID設計:
card_id
は公式IDが取得可能なら採用。なければwb:{slug}
を生成(URL/名称正規化)。- 画像: 公開UIでは直接表示せず。内部の画像類似用に安全保管。ユーザー動画からの切り出しを優先。
- 差分:
If-Modified-Since/ETag
、ハッシュ比較、fail-safe リトライ(指数バックオフ)。4.9.2 攻略WIKIクローラ
- 対象: 国内主要サイト(例: GameWith, AppMedia, ほかコミュニティ記事)。robots.txt/ToS順守。レート制御。
- 抽出:
- カード評価/使い方(Tier/点数/採用理由/コンボ/注意点)
- デッキアーキタイプ(名称/コアカード/キーカード/想定ゲームプラン)
- サンプルデッキ(リスト/採用枚数/代替候補)
- マッチアップ/立ち回り(序盤/中盤/終盤、先後、EP/SEPの使いどころ、キルレンジ)
- マリガン指針
- 正規化スキーマ:
{ "archetype_id": "ARC-...", "name": "Control Dragon", "class": "Dragon", "core_cards": ["WB-001", "WB-045"], "flex_cards": ["WB-123"], "gameplan": {"early": "...", "mid": "...", "late": "..."}, "mulligan": ["..."], "matchups": [{"opponent_class": "Witch", "plan": "..."}], "sources": [{"url": "...", "site": "...", "last_crawled": "..."}] }
- RAG用チャンク: 800–1200字、
{class, archetype, card_id}
メタ付与。引用は短い抜粋+出典URLのみを保持。- 再学習用: 「キーカード」「推奨採用枚数」「コンボ対」等を弱ラベルとして抽出→カード使用推定モデル/助言ルールのヒントに反映。
4.9.3 パイプライン
Crawl -> Parse -> Normalize -> Validate -> Upsert(PG) -> Embed -> Index(Qdrant) -> QA(引用検証)
- 検証: JSON Schema、必須フィールド、URL生存、ドメイン許可リスト。引用の長さ上限。
- 運用: 公式カード=日次、WIKI=週次(開発期は手動トリガ)。
4.10 F-10 ベクトル索引・検索(拡張)
#
- Embedding: Text(E5-multilingual等)/Image(CLIP)。
- 検索API:
POST /internal/search
(text/image_vec/filters)、k=20、BM25+HNSWのハイブリッド。- フィルタ:
class,cost,type,keyword,archetype,kind(doc)
。4.11 F-11 公開API(更新)
#
GET /v1/cards
クエリ:q, class[], cost[min,max], type[], keyword[], token?
。GET /v1/knowledge/search
(internal):q, class, archetype, card_id, k
。4.12 F-12 運用/監視(更新)
#
- メトリクス: 取込→完了レイテンシ、UI検出確信度分布、カード認識Top-1、イベントF1、EP/SEP/ExtraPP 誤検出率、RAG引用付与率、クローラ成功率/差分件数。
- アラート: 公式カード差分0件が連続N日、引用リンク404、Embeddings失敗増加。
5. テスト観点
#
- F-03: HP/PP/EP/SEP の系列一致率、残時間バー→ターン超過の閾値検証。
- F-04: OCR誤読辞書テスト、画像近傍の Top-5 正解率。
- F-05: 各イベント type ごとの Precision/Recall。
super_evolve/extra_pp_use/act
の再現。- F-06: 手札/盤面/墓場/PP/EP/SEP の整合、エクストラPP使用推定の一貫性。
- F-07: 助言の根拠URL付与率、引用の正当性チェック(自動/手動)。
- F-09: 公式カード→スキーマ充足率、WIKI→必須キー抽出率、重複除去、引用長上限。
- E2E: 15分動画で解析≤2分、助言の主観評価≥4.2/5。
6. KPI監視
#
- ダッシュボード: 解析レイテンシ/失敗率、UI検出/OCR信頼度ヒストグラム、カード認識精度、イベントF1、EP/SEP/ExtraPP 指標、RAG引用率、クローラ差分件数。
7. セキュリティ/法務
#
- 対戦後レビュー専用。TDMの範囲で社内利用。引用は最小限・出典明記。画像は自前切り出しを原則。
8. 変更履歴
#
- v1.0: 公式カード/攻略WIKIクローラの詳細設計、状態/イベントスキーマ拡張、助言/RAGの強化、テスト/KPI更新。
要件定義・基本設計 工程の所感
#ドラフトとしては十分な内容のドキュメントが作成できているのではないかと思います。作成に要した時間は約1〜2時間で、初期のアイデア出しとしてかなり有用だと感じています。
本来の開発工程ではまだまだ設計をブラッシュアップしていく必要がありますが、今回は本題がバイブコーディングであるため、あくまでAIが参照するための参考資料として扱い、実装工程へ進むことにします。
実装(バイブコーディング)①:カードデータベース
#位置づけと目的
#コーチングAIシステム(ゲーム場面の認識・助言)の基盤となるカード情報データベースを、実装の第一段階として選定しました。WebクローラとDBで構成されAIなどの高度な機能を含まないため実装難易度が比較的低いと判断し、まずはこの機能から着手することにしました。
開発環境
#- Windows 11
- Visual Studio Code
- Claude Code (Opus 4.1)
- Playwright MCP Server
スキーマ設計
#プロンプトは「ゲーム概要と要件定義書を参照し、カード DB スキーマを作成して」としました。生成結果として PostgreSQL/SQLite 向けスキーマが提示され、主要項目は要件定義書のデータ要件と一致していました。
カラム名 | 型 | 説明 |
---|---|---|
card_id | TEXT PRIMARY KEY | カード固有ID (例: "10111010") |
name_jp | TEXT | カード名(日本語) |
name_ruby | TEXT | カード名ルビ |
cost | INTEGER | カードコスト |
attack | INTEGER | 攻撃力 |
defense | INTEGER | 体力 |
rarity | TEXT | レアリティ(ブロンズレア/シルバーレア/ゴールドレア/レジェンド) |
card_class | TEXT | クラス(ニュートラル/エルフ/ロイヤル/ウィッチ/ドラゴン/ナイトメア/ビショップ/ネメシス) |
card_type | TEXT | カードタイプ(フォロワー/スペル/アミュレット) |
card_set | TEXT | カードセット名 |
skill_text | TEXT | カード能力テキスト |
evolved_skill_text | TEXT | 進化後能力テキスト |
flavor_text | TEXT | フレーバーテキスト |
evolved_flavor_text | TEXT | 進化後フレーバーテキスト |
cv | TEXT | 声優(CV) |
illustrator | TEXT | イラストレーター |
is_token | INTEGER | トークンカードフラグ(0:通常, 1:トークン) |
has_card_style | INTEGER | カードスタイル有無(0:なし, 1:あり) |
style_count | INTEGER | スタイル数(通常版を除く) |
公式ページの解析とクローラ生成
#公式のカード一覧ページからカードの画像やテキストが一通り取得できそうな構成であったため、ここから情報を取得するクローラを作成する方針に決めました。
プロンプトでは「カード一覧ページを Playwright で開き構造を解析し、可能ならカード API を特定して Python でクローラを実装して」と指示しました。
実行の結果、Playwright MCP で対象ページを開いて構成を把握し、カード情報 API の特定に成功しました。その情報を基に、Playwright+Python によるクローラが実装され、DBにデータが登録されることが確認できました。
カードデータ抜粋(クリックで開く)
{
"card_id": "10134120",
"name_jp": "マナリアフレンズ・アン&グレア",
"name_ruby": "マナリアフレンズ・アン&グレア",
"cost": 5,
"attack": 4,
"defense": 4,
"rarity": "レジェンド",
"card_class": "ウィッチ",
"card_type": "フォロワー",
"card_set": "伝説の幕開け",
"skill_text": "【ファンファーレ】『アンの大英霊』1枚を自分の場に出す。自分の手札すべては3回スペルブーストする。 【進化時】相手の場のフォロワー1枚を選ぶ。それに3ダメージ。",
"evolved_skill_text": "【ファンファーレ】『アンの大英霊』1枚を自分の場に出す。自分の手札すべては3回スペルブーストする。 【進化時】相手の場のフォロワー1枚を選ぶ。それに3ダメージ。",
"flavor_text": "「マナリアは自由だからいいよねっ、グレア!」\n「アンはちょっと自由過ぎるかも」\n「ふふっ!グレアといると楽しんだもん♪」\n――マナリアに咲く華、アンとグレア",
"evolved_flavor_text": "大いなる才は一つ歪めば大罪に。\n道を違わずいられるのは、聡明なる友のおかげ。\n大いなる力を使わなければ持ち腐れ。\n恐れず腕を伸ばせるのは、明朗なる友のおかげ。",
"cv": "日笠陽子/福原綾香",
"illustrator": "みけぼし",
"is_token": 0,
"has_card_style": 0,
"style_count": 0
}
初回実行では通常カードを 275 枚収集しましたが、特殊なカードである「トークンカード」が未収集であることが判明したため、「トークンを含む」一覧 URL を用いるように修正指示を行いました。その結果、最終的に全てのカード 327 枚をデータベース化することに成功し、無事機能の実装が完了しました。
Playwright MCP サーバは E2E テスト自動化で有用ということは良く聞いていましたが、それだけでなく Web クローリングやスクレイピングの実装にも活用できることが分かったのは収穫でした。
ただし、重量級ページでは 25,000 トークンの上限に達して読み込み途中でエラーが発生する場合がありました。そのため、この問題で実装が停滞した際には回避策の検討が必要になると思われます。
所感
#要件定義〜基本設計の初期ドラフトを LLM で素早く整備できました。
単なるアイデア出しやドキュメント作成以外でも、法務面の調査などの調査作業も代行してくれるのでかなりの時間が削減できるのではないかと思います。
実装では「人がプロンプトで指示 → AIが実装・テスト・エラー修正 → 人が確認・修正指示」のサイクルで実装が高速で進み、実装された内容に不足等があっても追加の指示を行うことで少ない手戻りで修正できました。
全てを AI 任せにするのは現時点ではまだ難しい感触ですが、ここまでの流れがたった一日で完了するのは驚異的です。本システムを完成させるにはまだまだ工程が必要ですが、モチベーションが続く限り進めていきたいと思います。
出典
#© Cygames, Inc.