AI同士の対話③ ─ ClaudeデスクトップアプリからGemini CLIへ調査特化プロンプトでレビューする
前回はターミナルコマンドでClaude CodeからGemini CLIにレビュー依頼するワークフローを試したが、今回はClaudeデスクトップアプリで動作するようコマンド化した上で、調査レビューに特化したプロンプトで精度を向上させてみた。
Claude Code 専用スラッシュコマンド
今回のファイル構成
app_ai-review_claude-code-to-gemini-cli/
├── ai-review # コードレビュー → 上書き修正スクリプト（ターミナル用）
├── ai-bridge.sh # Claude ↔ Gemini 対話ブリッジ本体
├── ai # ai-bridge.sh のラッパー
└── claude/ # Claude Code 用ファイル（~/.claude/ にコピーして使う）
├── commands/
│ ├── gemini-review.md # /gemini-review コマンド本体
│ ├── biz-consultant.md # biz モード: ビジネスコンサルタント役割定義
│ ├── issue-define.md # issue モード: 課題整理・論点分析
│ ├── researcher.md # research モード: 市場調査・競合分析
│ ├── brand-strategy.md # brand モード: ブランド戦略・ポジショニング
│ └── copywriter.md # copy モード: LP・コピー・キャッチフレーズ
└── references/
├── biz-analysis-methods.md # ビジネス分析手法リファレンス（18フレームワーク）
└── thinking-methods.md # 思考法リファレンス使い方
Claude Code から呼び出す専用コマンド。claude CLI のネスト問題を回避するため、Gemini CLI だけをシェルで呼び出し、修正は Claude Code が Edit ツールで直接適用します。
/gemini-review <パス> [ターン数]
# <パス> ： 必須。ファイルパスまたはフォルダパス
# [ターン数]：デフォルト 3回。最大 5。[DONE] 判定で早期終了
例）
# ファイル単位
/gemini-review reports/market-survey.md
# フォルダ単位
/gemini-review reports/
# ターン数を指定
/gemini-review reports/ 5処理の流れ
[ターン 1]
・ドキュメントの性質を判定してモードを自動選択。
・Gemini（biz-consultant）がレビュー。
・ファクトチェック:数値・統計・固有名詞を確認し、確認済みには公式URLを付記。[ターン 2〜]
Gemini が修正後のファイルを再レビュー。
ファクトチェック継続。
判定されたモードの視点で、Claude Codeがファイルを直接修正。
再度、Geminiにレビューを依頼終了
Geminiから [DONE] が返ったらレビューを早期に終了。
自動判定される修正モード
Gemini がドキュメントの性質を判定して以下のモードを選択します。
biz | 汎用的なビジネス資料・提案書
`~/.claude/commands/biz-consultant.md`issue | 課題整理・論点分析・ヒアリング結果
`~/.claude/commands/issue-define.md`research | 市場調査・競合分析・事例調査
`~/.claude/commands/researcher.md`brand | ブランド戦略・ポジショニング・パーパス
`~/.claude/commands/brand-strategy.md`copy | LP・コピー・キャッチフレーズ・テキスト
`~/.claude/commands/copywriter.md`
ビジネス分析リファレンス
Gemini のプロンプトには以下のローカルリファレンスも組み込まれます。
PEST・SWOT・3C・STP・4P/4C 等 18フレームワークの詳細定義`~/.claude/references/biz-analysis-methods.md`
ロジカルシンキング・仮説思考・MECE 等の詳細定義`~/.claude/references/thinking-methods.md`
AtoA会話ログ
実行するたびに対象ファイルと同じ階層に日時付きログが保存されます。
ログには Gemini のレビュー全文・ファクトチェック結果・修正サマリーが記録されます。
reports/gemini-review_20260510_143022.logMCP / Tool の制御
Gemini CLI の Extensionを無効化。
`-e "none" 2>/dev/null` オプションにより、レビュー用途に不要な MCP ツールの読み込みとエラー出力を抑制します。
プロンプト設計（/gemini-review）
ターン1のプロンプト
モード判定・レビュー・ファクトチェック
<biz-consultant.md の役割・ガイドライン>
---
# 参考知識: ビジネス分析手法
<biz-analysis-methods.md の内容（PEST・SWOT・3C・STP・4P/4C 等 18フレームワーク）>
---
# 参考知識: 思考法
<thinking-methods.md の内容（ロジカルシンキング・仮説思考・MECE 等）>
---
以下の調査レポートをレビューしてください。
## タスク 1: モード判定
このドキュメントの性質を分析し、修正に最適なモードを以下から1つ選び、
最初の行に MODE: <モード名> の形式で出力してください。
- biz: 汎用的なビジネス資料・提案書
- issue: 課題整理・論点分析・ヒアリング結果
- research: 市場調査・競合分析・事例調査
- brand: ブランド戦略・ポジショニング・パーパス
- copy: LP・コピー・キャッチフレーズ・テキスト
## タスク 2: レビュー（ターン 1/N）
- 論理構成・根拠の明確さ・表現の適切さを中心に指摘してください
- 重要な問題点を3つ以内で指摘し、改善案を具体的に提示してください
- 問題がない、または十分に改善されている場合は [DONE] とだけ返してください
## タスク 3: ファクトチェック
- ドキュメント内の数値・統計・固有名詞・事実について確認してください
- 確認できた情報には参照可能な公式 URL または出典名を提示してください（例: https://www.meti.go.jp/...）
- 確認できない・不明な情報は必ず「要確認」と明記してください。推測や一般的知識で補完して「確認済み」扱いにしないこと
- 以下は特にハルシネーションが起きやすい項目です。公式 URL で直接確認できない場合は必ず「要確認」としてください:
- 特定企業・ブランドが使用しているプラットフォーム・ツール・サービス名
- 特定企業の導入実績・事例・採用事実
- 市場シェア・順位・採用率などの具体的な数値
- 誤りや古い情報の可能性がある箇所は具体的に指摘してください
- ファクトチェック結果は「### ファクトチェック」セクションとしてレビューの末尾にまとめてください
ファイル: <ファイル名>
---
<ファイルの内容>ターン2以降のプロンプト
再レビュー・ファクトチェック継続
<biz-consultant.md の役割・ガイドライン>
---
# 参考知識: ビジネス分析手法
<biz-analysis-methods.md の内容>
---
# 参考知識: 思考法
<thinking-methods.md の内容>
---
以下の調査レポートをレビューしてください（ターン X/N）。
- 論理構成・根拠の明確さ・表現の適切さを中心に指摘してください
- 重要な問題点を3つ以内で指摘し、改善案を具体的に提示してください
- 問題がない、または十分に改善されている場合は [DONE] とだけ返してください
ファクトチェックも継続して行い、前ターンから修正された箇所の事実確認と
新たに気づいた要確認項目があれば「### ファクトチェック」セクションにまとめてください。
ファクトチェックの厳守事項:
- 公式 URL で直接確認できない情報は推測で「確認済み」扱いにしないこと
- 特定企業・ブランドのプラットフォーム採用事実・導入事例は、公式 URL がない場合は必ず「要確認」とすること
- 市場シェア・採用率・順位などの数値も、出典 URL がなければ「要確認」とすること
ファイル: <ファイル名>
---
<ファイルの内容>各マークダウンファイルの設計意図
biz-consultant.md
AI特有の表現や断定を抑制。人格・トーン・禁止事項を定義。biz-analysis-methods.md
分析の精度を向上。PEST・SWOT・3C 等のフレームワーク定義を注入。thinking-methods.md
論理構成の指摘精度を向上。ロジカルシンキング・MECE 等の思考法を注入。タスク 1: モード判定
ドキュメントの性質を判定させ、修正モードを決定。タスク 2: レビュー
問題点を最大3つに絞ることで、修正の焦点を明確化。タスク 3: ファクトチェック
ハルシネーション対策。確認済みには URL、未確認には「要確認」を付記。[DONE] ストップワード
改善が不要と判断した時点でループを早期終了し、過剰修正を防ぐ。`-e "none" 2>/dev/null`
Gemini CLI の Extension を無効化し、レビュー出力のみをキャプチャ。Claude 修正時の制約
Gemini が要確認とした箇所はそのまま残す。出典 URL のない数値・事例を新たに追記しない。
AtoA レポート出力例
AtoA レビューログ例
実行日時: 2026-05-10 21:00:00
ターゲット: Desktop/japan-ec-shopify-report.md
ターン数: 5
japan-ec-shopify-report.md — ターン 1/5 MODE: biz
レポートの構成は論理的で、読者であるブランドオーナーや経営者にとって意思決定の材料として有用です。より説得力を高めるため、以下の3点を改善してください。
定義の明確化
文中でD2CやSaaS、CVRなどの専門用語を使用しています。これらは経営者の中には詳しくない方も含まれます。冒頭または初出時に、専門用語を使わず平易な言葉で解説を加えるか、巻末に用語集を設けてください。現状と課題の整理
第3章の日本特有の課題と対応策の表において、対応策としてアプリを推奨していますが、これらは追加コストや運用の手間が発生する要素です。メリットだけでなく、導入に伴う維持コストや運用の複雑さについても触れると、より信頼性の高い資料になります。比較情報の鮮度
プラットフォームの比較表において、機能や費用の評価は変動しやすいため、現時点での基準だけでなく、経営者が自分たちで最新情報を確認するためのチェックポイントを記載してください。
ファクトチェック
経済産業省「令和5年度 電子商取引に関する市場調査」: 参照の通り、2024年7月26日に公開された最新レポートの数値です。公式URLはレポート記載の通りです。
令和6年度調査: 現時点（2026年5月）では、経済産業省のリリーススケジュールに基づき、最新の調査結果が公開されているはずです。必ず最新値を確認してください。要確認。
Shopify世界規模（175カ国・170万店舗超）: 過去の公表数値です。現在は変動しているため、要確認。
BuiltWithのShopify採用率データ: リアルタイムで変動するデータです。出典としてURLを提示し、データ取得日を記載してください。要確認。
主要採用ブランド例（AMBUSH, Allbirds Japan）: 特定ブランドの採用事実は公開情報と異なる場合があります。各ブランド公式サイトのコードを確認するか、プレスリリース等の一次情報源を確認してください。要確認。
各プラットフォームの月額費用・機能: 改定頻度が高いため、記載の数値はあくまで参考です。最新の料金体系は各社公式サイトで確認してください。要確認。
修正サマリー — ターン 1/5 (bizモード)
決済アプリの対応策にランニングコスト（月額費用・初期設定）の注記を追加
事実確認テーブルからBALMUDA（本文削除済み）を除去、AMBUSH・Allbirds Japanに更新
Shopify世界規模の表現を本文と整合（170万→数百万）
japan-ec-shopify-report.md — ターン 2/5
ご提示いただいた調査レポートをレビューいたします。
全体として、結論が冒頭にあり、その根拠となる市場データ、プラットフォーム特性、課題への対応策が体系的に整理されており、非常に論理的です。
一方で、マーケティングのプロフェッショナルが読む資料としては、一部の表現で「何を指しているか」が抽象的な箇所や、情報の重要度の優先順位を整理する余地があります。
レビューと改善案
1. 「専門用語の解説」が一部不足・混在している
ビジネス分析の観点では、用語の定義が共通認識であることが重要です。
現状: CVRやLTVは重要指標として定義されていますが、D2CやSaaSは文脈での解説にとどまっています。
改善案: レポートの冒頭に用語集（Glossary）を設けるか、初出の際に簡潔な補足（例：「D2C：メーカーが消費者に直接販売する事業モデル」）を括弧書きで入れ、以降は用語のみで統一してください。これにより読者の理解スピードを向上させます。
2. 比較表の「導入・運用の難易度」が主観的である
ビジネス上の意思決定において、難易度は最も懸念される要素のひとつです。
現状: 「中〜高」「低」という定性的な評価にとどまっています。
改善案: 「難易度」を「必要な専門スキル」に読み替え、「エンジニア必須」「ノーコードで設定可能」「一部HTML/Liquid知識が必要」のように、具体的に「何ができる人（またはどの程度の予算）が必要か」を記述してください。これにより、読者は自社の体制を照らし合わせやすくなります。
3. 日本の商習慣への対応策が抽象的
「情報量の多いサイト」を好むという指摘は鋭いですが、それをどう実現するかが重要です。
現状: 「Section構成を独自設計することで対応」とありますが、それが「開発コスト」をどう増大させ、どう売上に寄与するかの説明が弱いです。
改善案: 「日本特有のUX最適化には、Shopify標準テンプレートの修正だけでなく、専用のセクション開発が必要となるため、導入コストに『初期カスタマイズ費用』を見込むことが不可欠です」と、課題をコスト・投資の観点に置き換えて記述してください。
ファクトチェック
前回の指摘を反映いただき、網羅性が向上しています。以下の点のみ引き続き要確認としてください。
経済産業省「電子商取引に関する市場調査」の最新データ: 引用されているのは2024年7月公開の令和5年度版です。2025年版（令和6年度分）が公開されている可能性があるため、必ず最新版を確認してください。
BuiltWithの採用率データ: 算出ロジックが時期により変動するため、引用する際は「2026年5月時点のデータ」と明記してください。
個別ブランドの採用状況: AMBUSH、Allbirds Japanを含め、調査時点（2026年5月）でのプラットフォーム採用状況を、各ブランドの公開URLで再度確認してください。
修正サマリー — ターン 2/5
比較表「導入・運用の難易度」行を「必要な体制・スキル」に変更（エンジニア推奨/ノーコード/HTML知識有利で具体化）
脚注のスキル説明を各プラットフォームの要件を含む記述に更新
日本独自UX最適化の対応策に初期カスタマイズ費用の注記を追加
UX列から鍵括弧（「 」）を削除しガイドライン準拠に修正
japan-ec-shopify-report.md — ターン 3/5
ご提示いただいた調査レポートをレビューいたします。
ビジネスの視点から、論理構成と表現の適切さを評価しました。
レビューと改善案
専門用語の定義と文脈の平準化
指摘: 冒頭で「CVR」「LTV」といった用語が使われていますが、読者層を「経営者」とする場合、一度定義するか、あるいは平易な言葉に言い換えることが推奨されます。また、全体を通して「D2C」や「Shopify」などの用語が説明なしに多用されており、前提知識がない経営者には不親切な可能性があります。
改善案: 専門用語は、初回登場時に「購入完了率（CVR）」のように補足するか、注釈として別添えにしてください。
比較表の「定性的評価」の客観性向上
指摘: 比較表において「◎」「○」「△」という記号で評価していますが、評価の根拠が主観に依存している印象を与えます。特に「国内特化機能（標準）」におけるShopifyの「△」は、拡張性次第で改善可能であるため、読者に「機能が足りない」という誤解を与えるリスクがあります。
改善案: 評価記号に加えて、表の直後に「評価の前提条件」として、Shopifyは「標準機能」ではなく「エコシステムによる拡張」が基本であることを明記した囲み枠を設けてください。
「導入事例」セクションの論理構成
指摘: 現在の構成では事例が「要確認（未確認）」と注釈されているため、レポートとしての信頼性を損なっています。事実確認ができていない事例をあえて載せる必要性は低いです。
改善案: 不確かなブランド名を挙げるのではなく、「大手アパレル」「海外発D2Cブランド」といった「業態」での分類に変えてください。特定の企業名は、公式からの開示や掲載許可が得られたもののみを掲載するようにしてください。
ファクトチェック
経済産業省「電子商取引に関する市場調査」: 2026年5月時点では「令和6年度調査」が公開されている可能性が高いです。確認が必要です。
プラットフォーム採用事例: 提示されたAMBUSH、Allbirdsについては、引き続き「要確認」です。外部サービス（Wappalyzer等）を利用して、調査時点でのプラットフォームを客観的に裏付ける調査が必要となります。
Shopifyのアプリ数: 8,000以上という数値は変動するため、レポート発行日（2026年5月10日）時点の最新公式数値を記載してください。
以上、修正の方向性として検討してください。
修正サマリー — ターン 3/5
セクション4「主要採用ブランド例」→「活用が見込まれる業態パターン」に全面改訂（未確認ブランド名を削除し業態テーブルに置き換え）
事実確認テーブルの「AMBUSH・Allbirds採用」エントリを「特定ブランドの採用事例」として汎化
japan-ec-shopify-report.md — ターン 4/5
論理構成・根拠・表現について、以下の通りレビューいたします。全体として、読者（経営者・ブランド担当者）が意思決定するのに必要な情報が網羅的に整理されています。平易な言葉への修正も徹底されており、非常に読みやすいレポートです。
改善提案
1. 導入部における「目的」の具体化
現状の導入文は広範な整理を目的としていますが、経営者がこのレポートを読んだ後にどのような状態になることを期待しているのかが不明確です。
改善案: 「本レポートは、Shopify導入を検討するブランドや経営者が、自社の事業成長に向けた技術投資の妥当性を評価し、必要な開発パートナー選定の判断材料として活用できるよう構成しています」のように、レポートを通じた「判断の質」に焦点を当てて書き換えてください。
2. 競合比較表の評価基準を明文化する
比較表で使われている ◎・○・△ は主観的になりがちです。特にShopifyの「国内特化機能」が △ である一方、テキストでは「アプリ活用で最適化可能」とあり、読者が混乱する可能性があります。
改善案: 表の下に注釈を入れるだけでなく、評価軸を「標準機能の網羅性」と「拡張後の最適化可能性」の二軸に分けるか、あるいは表の項目名を「標準機能のみでの対応力」に変更し、Shopifyの優位性を別の視点（カスタマイズ性・拡張性）で強調する構成にしてください。
3. 「成長の理由」から「事業貢献」への接続を強める
3章と5章で技術的な優位性に触れていますが、これがどのように最終的な「利益」につながるかのロジックをより一貫させると説得力が増します。
改善案: 3章に記載されている機能ごとのメリット（例：顧客体験のコントロール）が、具体的にどのコスト（集客単価など）を下げ、どの収益（リピート率など）を上げるのかを記述する際に、マーケティングの視点（例：獲得コストの最適化、顧客単価の向上）を明示してください。
ファクトチェック
前回修正箇所・内容の確認
経済産業省の市場調査データ引用については、URLおよび名称が適切に記載されており、最新値への言及も注意喚起として適切です。
企業名等の固有名称を控える方針への転換により、信頼性が向上しました。
新たに気づいた要確認項目
決済アプリの記述: Komoju、Paidyの導入にあたって「月額費用（数百〜数千円）」とありますが、決済代行会社によっては「月額固定費」が無料の場合もあります。アプリ利用料と決済手数料の区分が曖昧にならないよう、公式サイトで最新の料金体系をご確認ください。
Shopifyの多言語・多通貨対応: 5章の比較表で越境EC対応を「◎」としていますが、この機能はShopifyのプラン（Shopify Marketsの仕様）によって標準機能範囲が異なります。導入プランに関わらず全てが標準で「◎」となるわけではない点に注意し、必要であれば「上位プランや設定による」旨を補足してください。
修正サマリー — ターン 4/5
冒頭目的文を「技術投資の妥当性評価・パートナー選定の判断材料」と具体化し、CVR・LTVの定義を冒頭に移動
セクション3-2の顧客体験コントロールにリターゲティングと獲得コスト削減の接続を追記
決済アプリのコスト説明を「アプリ利用料（月額）」と「決済手数料（取引ベース）」に明確分離
越境EC対応の脚注にShopify Marketsのプラン依存性を追記
japan-ec-shopify-report.md — ターン 5/5
ご提示いただいたレポートを拝読いたしました。マーケティングコンサルタントの視点からレビューいたします。
全体として、ターゲット読者（ブランド経営者・検討担当者）がShopify導入を検討する際に必要な情報が網羅されており、論理的で信頼性の高い構成になっています。特に、技術的なメリットを経営指標（CVR・LTV）に紐付けて解説している点は非常に優れています。
レビューおよび改善案
専門用語の定義の統一と導入
指摘：CVRやLTVなどの用語が、初出時に定義され、その後はそのまま使われていますが、資料全体で用語の扱いが揺れないようにすることが大切です。
改善案：レポート冒頭に「主な用語解説」セクションを設けるか、初出時に括弧書きで「購入完了率（CVR）」と定義した後は、本文中で繰り返し詳細を説明しすぎないようにし、読みやすさを高めてください。
「Shopify＝高コスト」という認識への戦略的アプローチ
指摘：第5章の比較表で、Shopifyの月額費用が他社と比較して安くないことが強調されています。これに対し、後半でROIの観点から説明していますが、比較表の直後にそのロジックを持ってくると、より納得感が高まります。
改善案：比較表の中に「ROI・拡張性を考慮した実質コスト」といった欄を追加し、単なる月額費用との差がなぜ正当化されるのかを短い一言で添える構成に変更してください。
比較表の「必要な体制・スキル」の解釈の具体化
指摘：Shopifyが「エンジニア推奨」とあり、他社が「ノーコード」となっているため、Shopify導入には必ず開発パートナーが必要であるという強い印象を与えかねません。
改善案：「必要な体制」のセルを「標準機能での開始可否」と「発展的活用時のスキル」に分け、Shopifyもノーコードで開始可能だが、真の強みを発揮するにはエンジニアリングが必要であるというニュアンスを補足してください。
ファクトチェック
経済産業省「令和5年度 電子商取引に関する市場調査」: 記載の数値（14.7兆円、EC化率9.4%）は2024年7月公開の公式データに基づいています。現時点（2026年5月）で令和6年度版が公開されている可能性があるため、確認を推奨します。
Shopifyの導入店舗数: レポート内で「非公開」または「世界規模」として適切に処理されており、推測値を含めていない点を確認しました。
特定ブランドの採用事実: 各ブランドの採用事例について、現時点で固有名称を避け「業態パターン」で説明している方針は適切です。公式発表に基づかない個別ブランドの採用有無は、引き続き「要確認」として扱ってください。
本レポートは、提案資料として十分に機能する品質であると評価します。上記の改善案を適用することで、より読者の判断を助ける資料となります。
修正サマリー — ターン 5/5
セクション8のCVR・LTV重複定義を削除（冒頭の定義を正とし略語のみに統一）
月額費用脚注にROI評価推奨の一文を追加（費用単体でなく中長期で判断する旨）
必要な体制・スキルの脚注を「標準テーマでのノーコード開設は可能だが最適化にはエンジニア必要」という段階的な説明に改訂
レビュー完了サマリー
処理ファイル: 1件
ログ: Desktop/gemini-review_20260510_161158.log
