コピーしました! # 競合分析(gemini 動画生成)
## 分析対象
- 対象: `competitors/` 配下の競合10本(`001`〜`010`)
- 取得日: 2026-04-03
- 注意: 各ファイルの要約本文が同型のため、**URL構造・ドメイン構成・品質スコア・除外理由**を主要エビデンスとして分析
## 検索意図(Search Intent)
### 主意図(最頻)
- **Geminiで動画生成を実行するために、公式仕様に基づく手順と利用条件を確認したい(実行前確認意図)**
- 根拠:
- `001_support-google-com_16126339.md`(Help): 利用要件・使い方の確認導線
- `002_gemini-google_video-generation.md`(公式プロダクトページ): 機能概要の一次情報
- `003_ai-google-dev_video.md`(Developer Docs): 実装者向け動画生成ドキュメント
### 副意図
- **生成品質を上げるためのプロンプト設計と運用ベストプラクティスを知りたい(品質改善意図)**
- 根拠:
- `006_cloud-google-com_video-gen-prompt-guide.md`: 動画生成向けプロンプトガイド
- `007_cloud-google-com_best-practice.md`: ベストプラクティス
- `005_cloud-google-com_veo-video-generation.md`: モデルリファレンス(Veo)
### 補助意図
- **最新提供状況・話題性を把握して意思決定したい(トレンド確認意図)**
- 根拠:
- `009_gizmodo-jp_gemini-veo-3.md`, `010_theverge-com_google-gemini-ai-photo-video-feature-availability.md`: ニュース系メディアでの提供状況・話題確認
- `_README.md` の除外理由: Android Central / TechRadar が「速報・キャンペーン寄り」で恒常意図から外れると明記
## 競合の共通見出しパターン(実質トピック)
### パターン1: 「公式一次情報への導線」
- 上位7/10がGoogle公式系ドメイン(`support.google.com`, `gemini.google`, `ai.google.dev`, `cloud.google.com`)で、まず正確性を担保する構成。
- 根拠: `001`〜`007`
### パターン2: 「概要 → 仕様 → 実践」の分割
- 1記事完結よりも、概要(overview)・モデル仕様(model-reference)・実践(prompt/best-practice)を分割提示する傾向。
- 根拠: URLパスの役割分担
- `004` `/video/overview`
- `005` `/model-reference/veo-video-generation`
- `006` `/video/video-gen-prompt-guide`
- `007` `/video/best-practice`
### パターン3: 「ニュース記事は補助的」
- 非公式メディアは下位順位かつ品質スコア3で、一次情報の補足に留まる。
- 根拠: `008`〜`010`(品質3)、`001`〜`004`(品質5)
## 差別化機会(Differentiation Opportunities)
### 1. 「利用者別の最短開始ルート」を1ページで統合する(最優先)
- 競合は情報がドキュメント単位で分散し、読者が遷移しないと行動に移せない。
- 実装案:
- `一般ユーザー向け(Geminiアプリ)` と `開発者向け(API/Vertex AI)` を分岐
- 各分岐で「準備→実行→品質改善」まで3ステップ化
- 根拠: `001`/`002`(一般向け)と `003`〜`007`(開発/運用向け)が分離
### 2. 「プロンプト改善の失敗例」を明示して実用性を上げる
- 競合はガイド提示はあるが、失敗パターン起点の改善導線が弱い。
- 実装案:
- NG例(被写体の曖昧指定、カメラワーク未指定、尺指定不足)→改善テンプレの対比表
- 根拠: `006`(prompt guide)と `007`(best practice)が存在するが、統合的な実践記事が不足
### 3. 「提供条件・利用可否チェック」を冒頭固定化する
- ニュース起点で読者が流入するため、可否条件を先に示さないと離脱/誤解が発生しやすい。
- 実装案:
- 記事冒頭に「利用可能プラン/地域/機能制限の確認項目」をチェックリスト化
- 根拠: `009`,`010` の話題性流入 + `001`,`004`,`005` の仕様依存
### 4. 「一次情報と二次情報の役割分離」を明記し信頼性を担保する
- 競合は公式/メディアが混在し、何を根拠にすべきか曖昧になりやすい。
- 実装案:
- 仕様・手順は公式(`001`〜`007`)のみを根拠化
- メディア(`008`〜`010`)は市場動向・補足として別枠扱い
- 根拠: ドメイン分布と品質スコアの明確な差
## 記事設計への引き継ぎメモ
- 冒頭: 利用可否チェック(プラン/地域/制限)
- 前半: 一般向けと開発者向けの2ルート導線
- 中盤: プロンプト改善テンプレ(NG→改善の対比)
- 後半: 運用ベストプラクティスと更新確認ポイント
## 主要エビデンス一覧
- 一次情報(高品質): `001`〜`007`
- 二次情報(補足): `008`〜`010`
- 収集方針・除外根拠: `competitors/_README.md`, `competitors/_sources.csv`