Claude Code Agent Teams x GitHubを使って、プロダクトページの構築

Claude Code Agent Teamsを試してみました

今回は、Claude Code の Agent Teams 機能を使って、ちょうど作成しようと考えていたプロダクトページ作成をまとめて試してみました。 リサーチから構成作成、初稿、実装までを、AIエージェントのチームに任せる形です。

Agent Teams は、複数のエージェントが同時に起動し、それぞれが役割を持って協働する仕組みです。今回は in-process モードを使い、1つのターミナル内でエージェント同士がやり取りしながら進んでいく様子を見つつ作業しました。

いずれも、リサーチから構成案作成、ページ実装までを Agent Teams に任せています。

• 今回は Acsim のプロダクトページを対象にしています。

率直な感想として、かなり良かったです。 複数のエージェントが役割分担しながら並列で動くことで、「考える → 書く → 実装する」が途切れずに進みます。人間が細かく指示しなくても、一定の水準まで一気に持っていってくれる感覚がありました。

今回は、公開前に自分で少しだけ修正を入れています。 主に表現のトーン調整や、意図をより明確にするための微調整で、大きく書き直すような作業ではありませんでした。

この「最後のひと手間」についても、Agent Teams や skills を使ってレビュー機能を充実させていけば、かなりの部分はカバーできそうだと感じています。 レビュー観点をスキルとして定義しておけば、人が見るポイントはさらに減らせそうです。

---

今回のチーム体制 ― 12人のエージェント＋自分に役割の体制

Agent Teams を使ううえで、一番重要だと感じたのは チーム設計です。 各エージェントは独立したコンテキストウィンドウを持っており、メモリを直接共有できません。そのため、「誰が何を担当し、どの順番で成果物を受け渡すか」を最初にきちんと設計しておく必要があります。

感覚としては、ソフトウェア開発におけるパイプライン設計にかなり近いです。 ここが曖昧だと、個々のエージェントの性能が高くても、全体としてはうまく噛み合いません。

今回の構成は、以下のようにしました。

※すべてのエージェントは Claude Opus 4.6 で動作しています。Agent Teams ではエージェントごとにモデルを切り替えることもできますが、今回は挙動を揃えたかったため、同一モデルで統一しました。

このチーム設計で、特に良かったポイントは次の3つです。

リサーチを5人に分散したこと

5つのプロダクトページは、それぞれ必要となるドメイン知識が異なります。 このリサーチフェーズは並列化の効果が非常に高く、体感でも一番効いていました。

エージェントごとに関心領域が分かれているため、調査内容の被りが少なく、あとから strategist が整理しやすい状態で情報が集まります。

レビューを「3種類」に分けたこと

今回は reviewer を1体にまとめず、

• コンテンツレビュー
• 技術レビュー
• デザインレビュー

の3つに分けました。

strategist が作った成果物を、異なる観点から独立して検証する構造にしたことで、「それっぽいけどズレている」状態をかなり減らせた感触があります。 人間のチームで、編集・技術・デザインのレビューを分けるのと同じ考え方です。

それぞれのレビュアーは独立して動いていて、同じ成果物に対して別々の指摘を返してきます。 結果として、論点が自然に整理された状態で、人間が最終判断できるのはかなり楽でした。

実装フェーズを分業したこと

ページ本体の実装と、ヘッダーナビゲーションの追加は編集するファイルが異なるため、並列で進めました。 Agent Teams では複数エージェントが同じファイルを編集すると上書きが起きやすいため、ファイル単位で担当を分ける設計は重要です。

team-lead は全体を通してタスクを分解し、各エージェントの起動や役割の切り替えを管理していました。 人間が直接操作したのは、最初に team-lead に全体方針を伝えた1回だけです。

実際の作業中、人間は進捗を眺めながら次のフェーズを待つ時間がほとんどでした。 この「待つ時間」が生まれる感覚は、Agent Teams を使ってみて初めて実感できたポイントでもあります。

---

実際に構築した流れ

ここからは、今回のセッションで 実際に何が起きたのか を、時系列で追っていきます。 Agent Teams の特徴は、チーム設計以上に「動かしたときの挙動」によく表れます。

どのフェーズが並列で進み、 どこが直列になり、 人間が介入したのはどのタイミングだったのか。

ログをベースに、そのまま整理していきます。

3-1. 全体タイムライン

まずは、今回のセッション全体を俯瞰できるタイムラインです。

13:20  team-lead ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 13:50
         │
13:26    ├── researcher-1 ━━━━━ idle    (#294 業務フロー)
         ├── researcher-2 ━━━━━━ idle   (#295 改善方針)
         ├── researcher-3 ━━━━━━ idle   (#296 プロトタイプ)
         ├── researcher-4 ━━━━━━ idle   (#297 稟議書)
         ├── researcher-5 ━━━━━ idle    (#298 ドキュメント)
         │
13:29    ├── strategist ━━━━━ idle
         │
13:35    ├── reviewer-content ━━ idle
         ├── reviewer-tech ━━━━━ idle
         ├── reviewer-design ━━━ idle
         │
13:46    ├── header-engineer ━━ idle
13:48    ├── page-engineer ━━━━ idle
         │
13:50    └── team cleanup
         │                              ← Agent Teams ここまで（約30分）
         │
13:57    commit: 5ページ新設 + ヘッダー（+2,046行）
         │
14:10    人間レビュー開始（ブラウザで1ページずつ確認）
14:40    commit: コンテンツ品質改善 + メディア配置（+251 / -136行）
14:51    commit: テキスト修正 + デザイン改善（+122 / -76行）
         │                              ← 人間レビュー完了（約41分）
15:00    完了

大きく分けると、流れは以下の2つです。

• 前半：約30分（Agent Teams） リサーチ → コンテンツ策定 → 3種類のレビュー → 実装、までを自律的に実行

• 後半：約41分（人間） ブラウザでの最終確認と、仕上げの判断・修正

13:57 のコミットでは、5つのプロダクトページ新設とヘッダー追加が一気に入り、差分は +2,046行 です。 この時点で、ページとしてはすでに「読める・動く」状態になっていました。

その後、14:10 から人間レビューに入ります。 ここでは新しく作るというより、エージェントによる 3種類のレビュー結果を踏まえた最終判断が中心です。

• プロダクトの実態とズレていないか
• 誇大表現として残すべきでない表現はないか
• 実際にブラウザで見たときのバランスはどうか

こうした「コンテキストウィンドウの外側」にある判断を、人間が補います。

このタイムラインを見ると分かる通り、Agent Teams はレビューまで含めて自動化していますが、最終的な責任ある判断は人間に残る設計になっています。

次のセクションでは、このタイムラインの中身をさらに分解し、まず最初に走った リサーチフェーズ から詳しく見ていきます。

手順1: チーム体制の構築

実際の事例では、まずAIに次のプロンプトを投げました。

プロダクトページを構築したい。ai.acsim.appを参照し、必要なチーム体制案を教えて。
対象ページ：https://ai.acsim.app/
作りたいページ：ヘッダーにプロダクトを追加しその配下に
- ヒアリングから業務フロー生成
- 改善方針・改善計画策定をAIエージェントが支援
- プロトタイプの自動生成
- 稟議書に必要な情報を自動生成
- 設計書の自動生成

プロダクトの仕様は対象ページ配下からリサーチしてください

この初回の指示に対し、AIは以下の協働体制案を提案します。

• strategist（全体設計・コンセプトメイク担当）
• content writer（本文・説明文作成）
• tech reviewer（技術項目チェック）
• designer（ページレイアウト・UI確認）

さらに、追加で次のプロンプトを与えました。

リサーチやレビューも加えてほしい。レビューは技術、デザイン観点でもしてほしい

このやりとりを経て、AI側でチーム体制は以下のように拡張されました。

• researcher（サービスや競合調査を担当）
• strategist
• content writer
• tech reviewer
• designer
• reviewer-content（内容・論理チェック専任）
• reviewer-design（デザイン観点でチェック専任）
• reviewer-tech（技術観点でチェック専任）
• team-lead（全体統合・ファシリテーション）

手順2:リサーチする【AIが自動実行】

チーム体制構築後、以下で作業指示したらあとはチームが立ち上がってよしなに作業してくれました。

では作業開始してください。作業履歴はすべてGitHub Issueとして出力しながら進めて

spawnプロンプト設計：明確な役割分担と出力指示【AIが自動実行】

最初に、researcher エージェント5体を並列でspawnします。それぞれに以下のようなspawnプロンプトを与えました。

- 担当するプロダクトについて、公式サイトや競合、AI活用事例等をWeb検索し、見つけた関連情報を要約してください
- 情報ソースへのURLも明記してください
- 内容はGitHub Issueにコメントでまとめてください（タイトル・要点リスト・一次情報へのリンクを含めること）
- チームの他エージェントがこのIssueコメントを読んで以降のフェーズを担当します

WebSearch ×5 の並列実行と効率化【AIが自動実行】

researcherエージェントは5つのプロダクトごとに同時に起動され、Web検索タスクを分担します。
こうすることで、人間では時間がかかる情報収集フェーズも、約3分で全体のリサーチが一気に完了しました。

GitHub Issue を“共有メモリ”として活用した理由

Agent Teams ではエージェント同士でメモリを直接共有できないため、各researcherのリサーチ結果は個々のGitHub Issueにそれぞれコメントとして出力させました。

このようにしたことで、

• 全エージェントが同じIssueコメントを後から読み取れる
• 永続的・時系列で記録され、後工程のエビデンスにもなる
• フェーズ間でインプット/アウトプットが明確化する という利点が得られました。

idle通知 → 次フェーズへの滑らかな遷移

全researcherが自分のタスク完了後、「idle」ステータスをteam-leadへ通知します。
team-leadは全員の完了を確認してから、次フェーズ（コンテンツ策定やレビュー）担当エージェントをspawn。
これにより、完全自動でリサーチ〜次工程へのバトンリレーを実現しています。

手順3: コンテンツ設計【AIが自動実行】

このフェーズでは、strategist エージェントが、各 research エージェントによって集約された GitHub Issue のリサーチ結果コメントをもとに、各プロダクトページのコンテンツ骨子を一気に設計します。

ちなみに、ここは何も手動での作業はしていません。

具体的な進行は以下の通りです。

1. 情報集約

   • 5つのリサーチ結果（Issueコメント）を strategist が横断的に読み込み、要点・構成案を抽出します。
   • ここで各プロダクトの特徴や市場での位置づけ、競合との差別化ポイントを把握します。

2. コンテンツ構成の策定

   • 各ページごとに以下の主要セクションを定義します。
     • Hero（最初の打ち出しメッセージ、USP等）
     • Benefits（プロダクトの利点・導入効果など）
     • FAQ（よくある質問と回答）
   • 必要に応じて他のセクション（例：Use Case, CTA, 導入フロー等）も追加します。

3. 成果物の出力

   • 各ページごとに「セクション名＋要約説明」「見出し例」「箇条書きポイント」などの形でアウトラインを作成し、GitHub Issueにコメントとして投稿します。
   • これが次フェーズ（レビュー・実装）のインプットになります。

この工程自体も自動で実行され、strategist からのアウトラインが整ったところで、次の工程担当エージェントにバトンが渡されます。

手順4: レビュー【AIが自動実行】

このフェーズでは、各プロダクトページのアウトラインに対して reviewer エージェントがレビューを実施します。指摘や改善提案は「Critical」「Warning」「Good」の3段階評価で整理し、具体的な箇条書きフィードバックとしてGitHub Issueのコメントに記載します。

• Critical：必ず修正が必要な致命的な問題
• Warning：改善推奨だが必須ではない注意点
• Good：良かった点・評価ポイント

評価テーブル例

最終的な修正版コンテンツは、このレビュー結果コメントをもとにstrategist/engineer役が次フェーズに引き継ぎ、内容をアップデートしていく構造です。

指摘事項サンプル

このような形で「Critical（必須修正）」「Warning（改善推奨）」「Good（評価ポイント）」をセクション別に整理し、具体的な修正指示として残します。

手順5: 実装【AIが自動実行】

このフェーズでは、engineer エージェントが各プロダクトページの修正版アウトラインをもとに、実装コード（例: Next.js + TypeScript + MDX形式）を自動生成します。
実装のフローは header-engineer / page-engineer による分業体制を採用し、競合しない設計で並列に進みます。
ここではIssueコメントをもとに、具体的な構成例や記述パターンがガイドとして利用されています。

• header-engineer：共通ヘッダーやナビゲーション等のUI部品を実装
• page-engineer：Hero・Benefits・FAQ等の各ページの主要セクションをアウトラインに沿って実装

作成された実装コードはGitHub Issueに投稿され、最終コミットの差分も記録されます（どの箇所が生成・修正されたか明確化）。
この成果物を元に、後続の人間や追加エージェントが内容をレビュー・微調整できます。

• 各セクションごとに適切なコンポーネント／記法で実装
• テキスト・FAQ・箇条書きポイント等は、アウトラインから自動変換
• 必要に応じてCTAやナビゲーション等も自動記述

手順6: 人間による最終レビュー

最終フェーズでは、人間がAIエージェントによる各種レビュー（Issue上の指摘内容・改善提案コメント）を参照しながら、ブラウザでページ全体を確認・修正します。ここで実施するのは以下のような作業です。

• GitHub Issueに指摘事項を残していたため、それをAIに解析させて実際のWebページを確認
• 実際の表示や使用感を自分の目でチェックし、AIの見落としや表現のズレ、トーン/バランス等の最適化を実施
• 必要に応じて手動で微調整・リライト・画像/構成の組み替え等を行う

このように、「Issueに蓄積されたAIレビュー内容」を活用し、ページを人間視点で最終クオリティまで持ち上げていきます。

• ポイント:
  • Issueベース運用のため、他メンバーのレビューやフィードバックも容易に参照・連携でき、改善履歴もすべて残る。
  • 最終判断/責任は人間が担う、という安心感とコントロール性も確保できます。

全体フローと工程解説

---

パイプライン全体の効率分析

フェーズ別所要時間（例）

• 人間による最終レビュー（ブラウザで確認＆修正）は別枠で約41分

エージェント間のやり取りはGitHub上で完結

本プロジェクトにおけるエージェント同士の全てのやり取り（成果物の共有、指摘、レビュー、進行管理など）は、GitHub の機能（Issue、コメント、Pull Requestなど）を利用して行いました。

• 各エージェントは担当フェーズのアウトプットや指示をGitHub Issue上に投稿
• 課題、議論、レビュー、実装提案（PR）、修正依頼などもすべてGitHubに集約
• 履歴管理や経緯参照、監査も容易で、意思決定や担当者間の伝達漏れを防止

この方式を選んだ理由:

• すべてのやり取りがGitHub上に履歴として残る
• 意思決定の過程・レビューの指摘・最終成果物までを統一された場所で確認できる
• 外部サービスや追加ツールを使わず一元・時系列で把握しやすい

GitHub Issueは「コミュニケーションハブ」「決定記録」「実装差分の参照点」を兼ね、エージェント間の全プロセスを透明化しています。

まとめ

今回、Claude Code の Agent Teams x GitHubを使ってプロダクトページ作成をまとめて回してみて、いちばん印象に残ったのは、エージェントが「チーム」として自律的に動く体験でした。 リサーチ → コンテンツ策定 → レビュー → 実装が、パイプラインとして流れていき、思っていた以上に「任せられる」感覚があります。 実際に人が触ったのは、チーム体制の構築、及び最終成果物のレビューのみ。

一方で、個人的には途中で「ここはこうして」「この観点も見てほしい」と、もっと細かく口を出したくなる場面もありました。 今はチームリーダーに方針を渡すだけでも十分回りますが、個人的には自分もチームの一員として途中から参加できる（レビューに割り込む、方向性を微調整する、意思決定だけ担当する）ようになると、さらに面白くなりそうです。

今回のセッションでは最後に人間が仕上げをしましたが、ここも agents / skills でレビューを強化していけば、もっと滑らかにできる余地があります。 「一発で完璧にする」というより、回して課題を出し、次の設計に落とす、この改善サイクルに価値があると感じました。

まだ試せていないことも多いので、次はレビューの並列化や、プロダクト固有ルールを agents / skills に組み込むあたりから、もう少し深掘りしてみようと思います。