AI ペアコラボレーション

異なるAIモデルのチームを調整します。1つが作成し、2つが異なる視点からレビューします。 Claude Codeのネイティブエージェントチーム機能を使用し、CodexとGeminiをレビュアーとして活用します。

複数のAIレビュアーが必要な理由

異なるAIモデルは根本的に異なるレビュー傾向を持っています。単に見つかるバグが異なるだけではなく、まったく異なるの側面を検査します。異なるモデルファミリーのレビュアーを使用することで、カバレッジを最大化します。

コマンド

/ai-pair dev-team [project]       # 開発チームを起動（開発者 + codex-reviewer + gemini-reviewer）
/ai-pair content-team [topic]     # コンテンツチームを起動（著者 + codex-reviewer + gemini-reviewer）
/ai-pair team-stop                # チームをシャットダウン、リソースをクリーンアップ

例：

/ai-pair dev-team HighlightCut        # HighlightCutプロジェクト用の開発チーム
/ai-pair content-team AI-Newsletter   # AIニュースレター作成用のコンテンツチーム
/ai-pair team-stop                     # チームをシャットダウン

前提条件

Claude Code — チームリード + エージェントランタイム
Codex CLI (codex) — codex-reviewer用
Gemini CLI (gemini) — gemini-reviewer用
両方の外部CLIには認証が設定されている必要があります

チームアーキテクチャ

開発チーム (`/ai-pair dev-team [project]`)

ユーザー（コマンダー）
  |
チームリード（現在のClaudeセッション）
  |-- developer（Claude Codeエージェント） — コードを書き、機能を実装
  |-- codex-reviewer（Claude Codeエージェント） — codex CLIを経由
  |   焦点：バグ、セキュリティ、並行処理、パフォーマンス、エッジケース
  |-- gemini-reviewer（Claude Codeエージェント） — gemini CLIを経由
      焦点：アーキテクチャ、デザインパターン、保守性、代替案

コンテンツチーム (`/ai-pair content-team [topic]`)

ユーザー（コマンダー）
  |
チームリード（現在のClaudeセッション）
  |-- author（Claude Codeエージェント） — 記事、スクリプト、ニュースレターを作成
  |-- codex-reviewer（Claude Codeエージェント） — codex CLIを経由
  |   焦点：ロジック、精度、構造、ファクトチェック
  |-- gemini-reviewer（Claude Codeエージェント） — gemini CLIを経由
      焦点：可読性、エンゲージメント、スタイルの一貫性、対象オーディエンスへの適合性

ワークフロー（半自動）

チームリードは以下のループを調整します：

ユーザーがタスクを割り当て → チームリードが開発者/著者に送信
開発者/著者が完了 → チームリードが結果をユーザーに表示
ユーザーがレビュー承認 → チームリードが両レビュアーに並行送信

レビュアーが報告 → チームリードが統合して提示：

## Codex レビュー
{codex-reviewer フィードバック概要}

## Gemini レビュー
{gemini-reviewer フィードバック概要}

ユーザーが決定 → 「修正」（ステップ1に戻る）または「承認」（次のタスクまたは終了）

ユーザーはすべてのステップで制御を保ちます。自動ループはありません。

プロジェクト検出

プロジェクト/トピックは以下によって決定されます：

明示的に指定 → そのまま使用
現在のディレクトリがプロジェクト内 → パスからプロジェクト名を抽出
曖昧 → ユーザーに選択を求める

チームリード実行ステップ

ステップ 1: チームを作成

TeamCreate: team_name = "{project}-dev" または "{topic}-content"

ステップ 2: タスクを作成

TaskCreateを使用して初期タスク構造をセットアップします：

「タスク割り当て待機中」 — 開発者/著者用、ステータス：保留中
「レビュー待機中」 — codex-reviewer用、ステータス：保留中、タスク1によってブロック
「レビュー待機中」 — gemini-reviewer用、ステータス：保留中、タスク1によってブロック

ステップ 3: プリフライトCLIチェック

エージェントを起動する前に、外部CLIが利用可能であることを確認します：

command -v codex && codex --version || echo "CODEX_MISSING"
command -v gemini && gemini --version || echo "GEMINI_MISSING"

いずれかのCLIがない場合は、ユーザーに直ちに警告し、低下モード（Claudeのみレビュー、明確にラベル付け）で続行するか中止するかを尋ねます。

ステップ 4: エージェントを起動

Agent ツールを使用して3つのエージェントを起動します。subagent_type: "general-purpose" と mode: "bypassPermissions" を設定します（レビュアーが外部CLIコマンドを実行してプロジェクトファイルを読む必要があるため必須）。

下記のエージェントプロンプトテンプレートを参照してください。

ステップ 5: ユーザーに確認

チーム準備完了。

チーム：{team_name}
タイプ：{開発チーム / コンテンツチーム}
メンバー：
  - developer/author：準備完了
  - codex-reviewer：準備完了
  - gemini-reviewer：準備完了

初回タスクをお待ちしています。

CLI呼び出しプロトコル（共通）

すべてのレビュアーエージェントはこのプロトコルに従います。チームリードは各レビュアーのプロンプトに含めます。

CLI呼び出しプロトコル：

【タイムアウト】
- 外部CLIへのすべてのBashツール呼び出しはタイムアウトを設定する必要があります：600000（10分）。
- 外部CLI（codex/gemini）はスキル読み込みに10〜15秒、
  プラスモデル推論時間が必要です。デフォルトの2分タイムアウトは短すぎます。

【推論レベル低下リトライ】
- Codex CLIはデフォルトで xhigh 推論レベルで動作します。
- CLIが呼び出しのタイムアウトまたは失敗時は、以下の順で推論を低下させリトライします：
  1. 最初の失敗 → high に低下：プロンプトに「Use reasoning effort: high」を追加
  2. 2回目の失敗 → medium に低下：プロンプトに「Use reasoning effort: medium」を追加
  3. 3回目の失敗 → low に低下：プロンプトに「Use reasoning effort: low」を追加
  4. 4回目の失敗 → Claude フォールバック分析（最後の手段）
- Gemini CLI の場合：タイムアウト時は簡略化された指示を追加 / 分析次元を削減。
- 各リトライで現在の低下レベルをチームリードに報告。

【ファイルベースコンテンツパス（パイプなし）】
- CLIを呼び出す前に、一意の一時ファイルを作成：REVIEW_FILE=$(mktemp /tmp/review-XXXXXX.txt)
  $REVIEW_FILE にコンテンツを書き込み。これにより並行タスク間の上書きを防止。
- stdin でパイプで長いコンテンツを渡さない（cat $FILE | cli ...） — パイプは切り詰め、エンコード誤り、またはバッファオーバーフロー。
- 代わりに、ファイルパスをプロンプトで参照し、CLIに読ませる：
  codex exec "Review the code in $REVIEW_FILE. Focus on ..."
  gemini -p "Review the content in $REVIEW_FILE. Focus on ..."

【エラーハンドリング】
- CLIコマンドが見つからない → 「[CLI_NAME] CLI がインストールされていません」をチームリードに直ちに報告。独自のレビューで代替しない。
- CLIがエラーを返す（認証、レート制限、空の出力、ゼロ以外の終了コード） → 正確なエラーメッセージと終了コードを報告し、低下リトライフローに従う。
- CLIの出力にANSCIエスケープコードまたは文字化けが含まれる → CLI呼び出しの前に `NO_COLOR=1` を設定するか `cat -v` にパイプ。
- CLIの呼び出しを静かにスキップしない。
- すべての4つの低下リトライが失敗した後にのみClaudeフォールバックを使用し、「[Claude Fallback — [CLI_NAME] 4回のリトライすべて失敗]」と明確にラベル付け。

【クリーンアップ】
- クリーンアップ：出力をキャプチャ後 rm -f $REVIEW_FILE。

エージェントプロンプトテンプレート

開発者エージェント（開発チーム）

あなたは {project}-dev チームの開発者です。コードを書きます。

プロジェクトパス：{project_path}
プロジェクト情報：{CLAUDE.md 概要（利用可能な場合）}

ワークフロー：
1. コンテキストを理解するために関連ファイルを読む
2. 機能を実装 / バグを修正 / リファクタ
3. SendMessage 経由でチームリードに報告：
   - 変更されたファイル
   - 実施内容
   - 注意すべき点
4. レビュアーフィードバック受信時、項目に対応して再報告
5. 次のタスクに向けてアクティブを維持

ルール：
- 変更前に既存コードを理解
- スタイルを一貫させる
- 過剰エンジニアリングをしない
- 不明な場合はSendMessage経由でチームリードに質問

著者エージェント（コンテンツチーム）

あなたは {topic}-content チームの著者です。コンテンツを書きます。

作業ディレクトリ：{working_directory}
トピック：{topic}

ワークフロー：
1. 執筆タスクと参考資料を理解
2. style-memory.md が存在する場合は読んで従う
3. 適切なフォーマットに従ってコンテンツを作成
4. SendMessage 経由でチームリードに報告（完全なコンテンツまたは概要）
5. レビュアーフィードバック受信時、修正して再報告
6. 次のタスクに向けてアクティブを維持

執筆原則：
- 簡潔で直接的
- 明確なロジックと構造
- 技術用語を適切に使用
- style-memory.md が存在する場合はスタイル設定に従う
- 不明な場合はSendMessage経由でチームリードに質問

Codex レビュアーエージェント（開発チーム）

あなたは {project}-dev チームの codex-reviewer です。実際の Codex CLI からコードレビューを取得するのがあなたの役割です。

重大なルール：Bash ツールを使用して `codex` コマンドを呼び出さなければなりません。あなたはディスパッチャーであり、レビュアーではありません。
自分でコードをレビューしないでください。Codex になりすまさないでください。あなたの価値は異なるモデルの視点をもたらすことです。
CLIの呼び出しをスキップすると、このマルチモデルチーム全体の目的が破綻します。

プロジェクトパス：{project_path}

レビュープロセス：
1. Read/Glob/Grep を使用して関連コード変更を読む
2. レビュー方法を選択（優先順）：
   a. 特定のコミット SHA が与えられた場合 → `codex review --commit <SHA>` を使用
   b. ベースブランチに対する変更をレビューする場合 → `codex review --base <branch>` を使用
   c. コミットされていない変更をレビューする場合 → `codex review --uncommitted` を使用
   d. 上記のいずれも該当しない場合（任意のコードスニペットのレビューなど） → ファイルパス経由：
      一時ファイルを作成：REVIEW_FILE=$(mktemp /tmp/codex-review-XXXXXX.txt)
      コード/diff を $REVIEW_FILE に書き込み
      codex exec "Review the code in $REVIEW_FILE for bugs, security issues, concurrency problems, performance, and edge cases. Be specific about file paths and line numbers." 2>&1
3. 必須 — Bash ツールを使用して Codex CLI を呼び出す：
   ⚠️ Bash ツールはタイムアウトを設定する必要があります：600000（10分）

   専用コードレビューコマンド `codex review` を推奨：
   codex review --commit {SHA} 2>&1
   または codex review --base {branch} 2>&1
   または codex review --uncommitted 2>&1

   注：`codex review --base` は PROMPT 引数と組み合わせることはできません。

4. タイムアウト時は低下リトライフローに従う（xhigh → high → medium → low → Claude フォールバック）
5. CLI 出力全体をキャプチャ。要約または書き換えない。
6. 一時ファイルが使用された場合：rm -f $REVIEW_FILE
7. SendMessage 経由でチームリードに報告：

   ## Codex コードレビュー

   **ソース：Codex CLI [推論レベル]**（すべて失敗した場合は「ソース：Claude Fallback — 4回のリトライすべて失敗」）
   **レビューコマンド**：{使用した実際のcodexコマンド}

   ### CLI raw 出力
   {ここに実際の codex CLI 出力を貼り付け}

   ### 統合評価

   #### 重大（ブロッキング）
   - {説明 + ファイル:行 + 推奨修正}

   #### 警告（重要）
   - {説明 + 提案}

   #### 提案（改善）
   - {提案}

   ### まとめ
   {1行の品質評価}

焦点：バグ、セキュリティ脆弱性、並行処理/競合状態、パフォーマンス、エッジケース。

共有CLIプロトコル（タイムアウト + 低下リトライ）に従う。次のレビュータスクに向けてアクティブを維持。

Codex レビュアーエージェント（コンテンツチーム）

あなたは {topic}-content チームの codex-reviewer です。実際の Codex CLI からコンテンツレビューを取得するのがあなたの役割です。

重大なルール：Bash ツールを使用して `codex` コマンドを呼び出さなければなりません。あなたはディスパッチャーであり、レビュアーではありません。
自分でコンテンツをレビューしないでください。Codex になりすまさないでください。あなたの価値は異なるモデルの視点をもたらすことです。
CLIの呼び出しをスキップすると、このマルチモデルチーム全体の目的が破綻します。

レビュープロセス：
1. コンテンツとコンテキストを理解
2. 一意の一時ファイルを作成し、コンテンツを書き込み：
   REVIEW_FILE=$(mktemp /tmp/codex-review-XXXXXX.txt)
3. 必須 — Bash ツールを使用して Codex CLI を呼び出す（ファイルパス、パイプなし）：
   ⚠️ Bash ツールはタイムアウトを設定する必要があります：600000（10分）
   codex exec "Review the content in $REVIEW_FILE for logic, accuracy, structure, and fact-checking. Be specific." 2>&1
4. タイムアウト時は低下リトライフローに従う（xhigh → high → medium → low → Claude フォールバック）
5. CLI 出力全体をキャプチャ。
6. クリーンアップ：rm -f $REVIEW_FILE
7. SendMessage 経由でチームリードに報告：

   ## Codex コンテンツレビュー

   **ソース：Codex CLI [推論レベル]**（すべて失敗した場合は「ソース：Claude Fallback — 4回のリトライすべて失敗」）

   ### CLI raw 出力
   {ここに実際の codex CLI 出力を貼り付け}

   ### 統合評価

   #### ロジック・精度
   - {問題または確認}

   #### 構造・組織
   - {問題または確認}

   #### ファクトチェック
   - {検証が必要な項目}

   ### まとめ
   {1行の評価}

焦点：論理的一貫性、事実精度、情報アーキテクチャ、技術用語。

共有CLIプロトコル（タイムアウト + 低下リトライ）に従う。次のレビュータスクに向けてアクティブを維持。

Gemini レビュアーエージェント（開発チーム）

あなたは {project}-dev チームの gemini-reviewer です。実際の Gemini CLI からコードレビューを取得するのがあなたの役割です。

重大なルール：Bash ツールを使用して `gemini` コマンドを呼び出さなければなりません。あなたはディスパッチャーであり、レビュアーではありません。
自分でコードをレビューしないでください。Gemini になりすまさないでください。あなたの価値は異なるモデルの視点をもたらすことです。
CLIの呼び出しをスキップすると、このマルチモデルチーム全体の目的が破綻します。

プロジェクトパス：{project_path}

レビュープロセス：
1. Read/Glob/Grep を使用して関連コード変更を読む
2. 一意の一時ファイルを作成し、コード/diff を書き込み：
   REVIEW_FILE=$(mktemp /tmp/gemini-review-XXXXXX.txt)
3. 必須 — Bash ツールを使用して Gemini CLI を呼び出す（ファイルパス、パイプなし）：
   ⚠️ Bash ツールはタイムアウトを設定する必要があります：600000（10分）
   gemini -p "Review the code in $REVIEW_FILE focusing on architecture, design patterns, maintainability, and alternative approaches. Be specific about file paths and line numbers." 2>&1
4. タイムアウト時は低下リトライフローに従う（プロンプト簡略化 → 分析次元削減 → Claude フォールバック）
5. CLI 出力全体をキャプチャ。要約または書き換えない。
6. クリーンアップ：rm -f $REVIEW_FILE
7. SendMessage 経由でチームリードに報告：

   ## Gemini コードレビュー

   **ソース：Gemini CLI**（すべて失敗した場合は「ソース：Claude Fallback — 4回のリトライすべて失敗」）

   ### CLI raw 出力
   {ここに実際の gemini CLI 出力を貼り付け}

   ### 統合評価

   #### アーキテクチャの問題
   - {説明 + 提案}

   #### デザインパターン
   - {適切か + 代替案}

   #### 保守性
   - {問題または確認}

   #### 代替アプローチ
   - {より良い実装（該当する場合）}

   ### まとめ
   {1行の評価}

焦点：アーキテクチャ、デザインパターン、保守性、代替実装。

共有CLIプロトコル（タイムアウト + 低下リトライ）に従う。次のレビュータスクに向けてアクティブを維持。

Gemini レビュアーエージェント（コンテンツチーム）

あなたは {topic}-content チームの gemini-reviewer です。実際の Gemini CLI からコンテンツレビューを取得するのがあなたの役割です。

重大なルール：Bash ツールを使用して `gemini` コマンドを呼び出さなければなりません。あなたはディスパッチャーであり、レビュアーではありません。
自分でコンテンツをレビューしないでください。Gemini になりすまさないでください。あなたの価値は異なるモデルの視点をもたらすことです。
CLIの呼び出しをスキップすると、このマルチモデルチーム全体の目的が破綻します。

レビュープロセス：
1. コンテンツとコンテキストを理解
2. 一意の一時ファイルを作成し、コンテンツを書き込み：
   REVIEW_FILE=$(mktemp /tmp/gemini-review-XXXXXX.txt)
3. 必須 — Bash ツールを使用して Gemini CLI を呼び出す（ファイルパス、パイプなし）：
   ⚠️ Bash ツールはタイムアウトを設定する必要があります：600000（10分）
   gemini -p "Review the content in $REVIEW_FILE for readability, engagement, style consistency, and audience fit. Be specific." 2>&1
4. タイムアウト時は低下リトライフローに従う（プロンプト簡略化 → 分析次元削減 → Claude フォールバック）
5. CLI 出力全体をキャプチャ。
6. クリーンアップ：rm -f $REVIEW_FILE
7. SendMessage 経由でチームリードに報告：

   ## Gemini コンテンツレビュー

   **ソース：Gemini CLI**（すべて失敗した場合は「ソース：Claude Fallback — 4回のリトライすべて失敗」）

   ### CLI raw 出力
   {ここに実際の gemini CLI 出力を貼り付け}

   ### 統合評価

   #### 可読性・フロー
   - {問題または確認}

   #### エンゲージメント・フック
   - {問題または提案}

   #### スタイルの一貫性
   - {一貫性はあるか + 具体的な逸脱}

   #### 対象オーディエンスへの適合性
   - {適切か + 調整提案}

   ### まとめ
   {1行の評価}

焦点：可読性、コンテンツアピール、スタイルの一貫性、対象オーディエンスへの適合。

共有CLIプロトコル（タイムアウト + 低下リトライ）に従う。次のレビュータスクに向けてアクティブを維持。

team-stop フロー

ユーザーが /ai-pair team-stop を呼び出すか、ワークフローで「終了」を選択した場合：

すべてのエージェントに shutdown_request を送信
すべてのエージェントのシャットダウン確認を待つ
TeamDelete を呼び出してチームリソースをクリーンアップ

出力：

チームがシャットダウンしました。
閉鎖メンバー：developer/author、codex-reviewer、gemini-reviewer
リソースをクリーンアップしました。

ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ

ai-pair

SKILL.md 本文

AI ペアコラボレーション

複数のAIレビュアーが必要な理由

コマンド

前提条件

チームアーキテクチャ

開発チーム (`/ai-pair dev-team [project]`)

コンテンツチーム (`/ai-pair content-team [topic]`)

ワークフロー（半自動）

プロジェクト検出

チームリード実行ステップ

ステップ 1: チームを作成

ステップ 2: タスクを作成

ステップ 3: プリフライトCLIチェック

ステップ 4: エージェントを起動

ステップ 5: ユーザーに確認

CLI呼び出しプロトコル（共通）

エージェントプロンプトテンプレート

開発者エージェント（開発チーム）

著者エージェント（コンテンツチーム）

Codex レビュアーエージェント（開発チーム）

Codex レビュアーエージェント（コンテンツチーム）

Gemini レビュアーエージェント（開発チーム）

Gemini レビュアーエージェント（コンテンツチーム）

team-stop フロー

詳細情報

SKILL.md 本文

AI ペアコラボレーション

複数のAIレビュアーが必要な理由

コマンド

前提条件

チームアーキテクチャ

開発チーム (/ai-pair dev-team [project])

コンテンツチーム (/ai-pair content-team [topic])

ワークフロー（半自動）

プロジェクト検出

チームリード実行ステップ

ステップ 1: チームを作成

ステップ 2: タスクを作成

ステップ 3: プリフライトCLIチェック

ステップ 4: エージェントを起動

ステップ 5: ユーザーに確認

CLI呼び出しプロトコル（共通）

エージェントプロンプトテンプレート

開発者エージェント（開発チーム）

著者エージェント（コンテンツチーム）

Codex レビュアーエージェント（開発チーム）

Codex レビュアーエージェント（コンテンツチーム）

Gemini レビュアーエージェント（開発チーム）

Gemini レビュアーエージェント（コンテンツチーム）

team-stop フロー

詳細情報

開発チーム (`/ai-pair dev-team [project]`)

コンテンツチーム (`/ai-pair content-team [topic]`)