競合分析（gemini deep research）

1. 分析対象と前提

対象: competitors/ 配下の 10 記事（取得日: 2026-03-29）
データ状態: 各ファイルは「記事本文」ではなく「要約メモ」中心
そのため本分析は、要約テキスト・メタ情報（順位/ドメイン/品質スコア）に基づく構造分析

根拠データ（抜粋）

公式一次情報: 8/10（gemini.google 1件、support.google.com 1件、blog.google 6件）
国内解説/ニュース: 2/10（www.ai-souken.com、www.gizmodo.jp）
品質スコア分布: 5点=3件、4点=5件、3点=2件

参照: 001〜010 各ファイルの front matter と「収集テキスト（要約）」

2. 検索意図（Search Intent）

主検索意図（最頻）

定義確認意図（Know）
「Gemini Deep Researchとは何か」「何ができるか」を短時間で把握したい。
根拠: 001 で「最短で定義を提示できる一次情報」と明記。
実用手順意図（Do）
利用条件・対応プラン・基本手順・注意点を確認して、実際に使い始めたい。
根拠: 002 で利用条件/手順/注意点が中心テーマ。

副次意図（比較・更新追従）

最新アップデート把握意図
どの時期に一般提供・機能改善されたかを時系列で理解したい。
根拠: 004（2025年3月機能更新）、007（2.5 Pro Experimentalでの改善）。
活用高度化意図
プロンプト設計や調査計画改善で出力品質を上げたい。
根拠: 005（活用ティップス）、006（Workspace連携）。
実装分岐意図（App vs API）
アプリ利用とAPIエージェント構築の違いを理解したい。
根拠: 008 が開発者向け実装観点を主題化。

3. 競合の共通見出しパターン（要約から抽出）

注記: 競合ファイルに本文見出し（H2/H3）が不足しているため、要約内容から見出しテーマを抽出。

パターンA: 「まず定義」

想定見出し: 「Gemini Deep Researchとは」「何ができるか」
出現根拠: 001, 003, 009, 010
競合の傾向: 定義と価値訴求はあるが、国内実務への落とし込みは薄い。

パターンB: 「使い方/条件」

想定見出し: 「使い方」「利用条件」「対応プラン」「注意点」
出現根拠: 002, 005
競合の傾向: 公式手順の説明はあるが、失敗例・回避策の具体性が不足。

パターンC: 「アップデート時系列」

想定見出し: 「最新情報」「2025年以降の変更点」
出現根拠: 004, 007
競合の傾向: 断片的な更新紹介になりやすく、変更前後比較が弱い。

パターンD: 「業務/開発への接続」

想定見出し: 「Workspace連携」「APIでの実装」
出現根拠: 006, 008
競合の傾向: 高度テーマはあるが、読者レベル別の導線（非エンジニア/エンジニア）が分離されていない。

4. 差別化機会（Differentiation Opportunities）

機会1: 一次情報偏重を補う「日本語実務判断フレーム」を追加

背景: 競合の 8/10 が Google系一次情報で、正確性は高い一方、読者の現場判断材料が不足。
施策: 「このケースなら使う/使わない」の判断表（目的・必要精度・調査時間・運用体制）を提示。
根拠: 001〜008 は機能説明中心、009/010 は概説止まり。

機会2: 「App利用」と「API実装」を明確に二層化

背景: 競合はアプリ文脈と開発文脈が混在し、対象読者が曖昧。
施策: 記事内を「業務利用者向け」「開発者向け」に分割し、必要知識・成果物・工数を比較。
根拠: 002（利用条件）、008（APIエージェント構築）が別々に存在。

機会3: 更新履歴を「変更前後」で可視化

背景: 更新記事はあるが、読者が「何が変わったか」を一目で追いにくい。
施策: 「日付/変更点/影響/確認先」の更新ログ表を記事内に設置。
根拠: 004, 007 は更新情報ソースとして有効だが比較表現が不足。

機会4: 失敗パターンと対処（プロンプト・出典確認）を先回り提示

背景: ティップスはあるが、失敗条件の具体例が弱い。
施策: 典型失敗（質問が広すぎる、検証範囲不明、出典未確認）と改善プロンプト例をセットで提示。
根拠: 005 が品質改善の必要性を示すが、失敗ケース体系化は見えない。

5. 構成作成への示唆（次工程向け）

導入で「定義」だけで終わらず、直後に「使うべき状況/使わない状況」を置く。
本文を 業務利用（App） と 開発利用（API） の2レーンで設計し、読者迷子を防ぐ。
2025年以降の更新を時系列で整理し、古い情報との差分を明示する。
最後に「実務導入チェックリスト（条件・制約・検証手順）」を置き、行動に接続する。

6. 根拠ファイル一覧

competitors/001_gemini-google_deep-research.md
competitors/002_support-google-com_15719111.md
competitors/003_blog-google_google-gemini-deep-research.md
competitors/004_blog-google_new-gemini-app-features-march-2025.md
competitors/005_blog-google_tips-how-to-use-deep-research.md
competitors/006_blog-google_deep-research-workspace-app-integration.md
competitors/007_blog-google_deep-research-gemini-2-5-pro-experimental.md
competitors/008_blog-google_deep-research-agent-gemini-api.md
competitors/009_ai-souken-com_gemini-deep-research-overview.md
competitors/010_gizmodo-jp_gemini-deep-research.md

# 競合分析（gemini deep research）

## 1. 分析対象と前提

- 対象: `competitors/` 配下の 10 記事（取得日: 2026-03-29）
- データ状態: 各ファイルは「記事本文」ではなく「要約メモ」中心
- そのため本分析は、要約テキスト・メタ情報（順位/ドメイン/品質スコア）に基づく構造分析

### 根拠データ（抜粋）

- 公式一次情報: 8/10（`gemini.google` 1件、`support.google.com` 1件、`blog.google` 6件）
- 国内解説/ニュース: 2/10（`www.ai-souken.com`、`www.gizmodo.jp`）
- 品質スコア分布: 5点=3件、4点=5件、3点=2件

参照: `001`〜`010` 各ファイルの front matter と「収集テキスト（要約）」

## 2. 検索意図（Search Intent）

### 主検索意図（最頻）

1. **定義確認意図（Know）**  
   「Gemini Deep Researchとは何か」「何ができるか」を短時間で把握したい。  
   根拠: `001` で「最短で定義を提示できる一次情報」と明記。

2. **実用手順意図（Do）**  
   利用条件・対応プラン・基本手順・注意点を確認して、実際に使い始めたい。  
   根拠: `002` で利用条件/手順/注意点が中心テーマ。

### 副次意図（比較・更新追従）

1. **最新アップデート把握意図**  
   どの時期に一般提供・機能改善されたかを時系列で理解したい。  
   根拠: `004`（2025年3月機能更新）、`007`（2.5 Pro Experimentalでの改善）。

2. **活用高度化意図**  
   プロンプト設計や調査計画改善で出力品質を上げたい。  
   根拠: `005`（活用ティップス）、`006`（Workspace連携）。

3. **実装分岐意図（App vs API）**  
   アプリ利用とAPIエージェント構築の違いを理解したい。  
   根拠: `008` が開発者向け実装観点を主題化。

## 3. 競合の共通見出しパターン（要約から抽出）

注記: 競合ファイルに本文見出し（H2/H3）が不足しているため、要約内容から見出しテーマを抽出。

### パターンA: 「まず定義」

- 想定見出し: 「Gemini Deep Researchとは」「何ができるか」
- 出現根拠: `001`, `003`, `009`, `010`
- 競合の傾向: 定義と価値訴求はあるが、国内実務への落とし込みは薄い。

### パターンB: 「使い方/条件」

- 想定見出し: 「使い方」「利用条件」「対応プラン」「注意点」
- 出現根拠: `002`, `005`
- 競合の傾向: 公式手順の説明はあるが、失敗例・回避策の具体性が不足。

### パターンC: 「アップデート時系列」

- 想定見出し: 「最新情報」「2025年以降の変更点」
- 出現根拠: `004`, `007`
- 競合の傾向: 断片的な更新紹介になりやすく、変更前後比較が弱い。

### パターンD: 「業務/開発への接続」

- 想定見出し: 「Workspace連携」「APIでの実装」
- 出現根拠: `006`, `008`
- 競合の傾向: 高度テーマはあるが、読者レベル別の導線（非エンジニア/エンジニア）が分離されていない。

## 4. 差別化機会（Differentiation Opportunities）

### 機会1: 一次情報偏重を補う「日本語実務判断フレーム」を追加

- 背景: 競合の 8/10 が Google系一次情報で、正確性は高い一方、読者の現場判断材料が不足。
- 施策: 「このケースなら使う/使わない」の判断表（目的・必要精度・調査時間・運用体制）を提示。
- 根拠: `001`〜`008` は機能説明中心、`009`/`010` は概説止まり。

### 機会2: 「App利用」と「API実装」を明確に二層化

- 背景: 競合はアプリ文脈と開発文脈が混在し、対象読者が曖昧。
- 施策: 記事内を「業務利用者向け」「開発者向け」に分割し、必要知識・成果物・工数を比較。
- 根拠: `002`（利用条件）、`008`（APIエージェント構築）が別々に存在。

### 機会3: 更新履歴を「変更前後」で可視化

- 背景: 更新記事はあるが、読者が「何が変わったか」を一目で追いにくい。
- 施策: 「日付/変更点/影響/確認先」の更新ログ表を記事内に設置。
- 根拠: `004`, `007` は更新情報ソースとして有効だが比較表現が不足。

### 機会4: 失敗パターンと対処（プロンプト・出典確認）を先回り提示

- 背景: ティップスはあるが、失敗条件の具体例が弱い。
- 施策: 典型失敗（質問が広すぎる、検証範囲不明、出典未確認）と改善プロンプト例をセットで提示。
- 根拠: `005` が品質改善の必要性を示すが、失敗ケース体系化は見えない。

## 5. 構成作成への示唆（次工程向け）

- 導入で「定義」だけで終わらず、直後に「使うべき状況/使わない状況」を置く。
- 本文を `業務利用（App）` と `開発利用（API）` の2レーンで設計し、読者迷子を防ぐ。
- 2025年以降の更新を時系列で整理し、古い情報との差分を明示する。
- 最後に「実務導入チェックリスト（条件・制約・検証手順）」を置き、行動に接続する。

## 6. 根拠ファイル一覧

- `competitors/001_gemini-google_deep-research.md`
- `competitors/002_support-google-com_15719111.md`
- `competitors/003_blog-google_google-gemini-deep-research.md`
- `competitors/004_blog-google_new-gemini-app-features-march-2025.md`
- `competitors/005_blog-google_tips-how-to-use-deep-research.md`
- `competitors/006_blog-google_deep-research-workspace-app-integration.md`
- `competitors/007_blog-google_deep-research-gemini-2-5-pro-experimental.md`
- `competitors/008_blog-google_deep-research-agent-gemini-api.md`
- `competitors/009_ai-souken-com_gemini-deep-research-overview.md`
- `competitors/010_gizmodo-jp_gemini-deep-research.md`