はじめに
普段Gensparkを使っていたところ、画面に 「GenTeam」 というメニューがあることに気づきました。
何だろうと思って開いてみると、人と複数のAIエージェントが同じワークスペースで会話しながら、タスクを分担して進められる仕組みのようです。
調査を担当するAI、コードを確認するAI、人がレビューする、といった形で役割を分けられそうで、開発作業でも使い道がありそうだと感じました。
そこで今回は、Gensparkの公式情報を確認しながら、GenTeamがどのような仕組みなのかを備忘録として整理してみます。
※本記事は2026年9月6日時点の公式情報をもとに整理しています。実際のエージェント連携やローカル環境との接続については、まだ十分な実機検証を行っていないため、公式に確認できた機能と筆者が考えた検証案を分けて記載します。
※本記事中の図は、公開情報をもとに筆者が独自に作成したものであり、Genspark公式の資料ではありません。
この記事でわかること
- GenTeamとは何なのか
- GenTeamの会話空間と、エージェントの実行環境の関係
- 技術調査・コード確認・人のレビューを分担する考え方
- タスクやSkillsを使って、依頼手順を整理する考え方
- 「ローカル実行」「記憶」「コスト」を読むときの注意点
1. まず「相談する場所」と「作業する場所」を分けて考える
GenTeamには、チャンネル、DM、スレッド、タスク管理が用意されています。エージェントは役割を持ち、人やほかのエージェントと会話できます。
ここで着目したいのは、会話が集まる場所と、実際に作業を実行する場所を分けられることです。
公式ヘルプでは、エージェントを作るときに最初に聞かれるのが「そのエージェントをどこで動かすか」であり、この選択によってエージェントが到達できる範囲と、その作業の費用を誰が負担するかが決まると説明されています。用意されているのは次の3種類です。
| 実行環境 | 主な用途 | Gensparkクレジット |
|---|---|---|
| Gensparkのクラウドコンピュータ（既定） | 調査、資料作成など。セットアップ不要 | 消費する（エージェント作成者のクレジット） |
| 自分のPC | Claude Code / Codex CLIを通じたローカルファイルやコードの操作 | 消費しない |
| Genspark Claw / OpenClaw | 既存のClaw環境をエージェントとして接続 | 消費しない |
出典：公式ヘルプ：GenTeam（Creating agents / Credits）
ここで見落としやすいのが、クレジットの負担者です。公式ヘルプでは、クラウドエージェントの実行ごとに消費されるのはそのエージェントを作成した人のGensparkクレジットだと説明されています。
つまり、自分が作ったクラウドエージェントをチャンネルで他のメンバーが呼び出した場合も、減るのは作成者側のクレジットです。共有ワークスペースで使う以上、この点は最初に把握しておきたいところです。
一方、自分のPCやClaw / OpenClaw環境で動くエージェントは、Gensparkのクレジットではなく、自分のハードウェアと自分のモデルアクセスを使って動くと説明されています。
そのため、Gensparkクレジットを消費しないことと、総費用がゼロであることは別です。利用するモデルやCLI側の契約・料金は別に考える必要があります。
なお、自分のPCで動かす場合は、左側の「Computers」から対象のPCを追加し、ローカルエージェントを作成するときに作業ディレクトリを指定する流れになります。接続先のCLIは、公式ヘルプの記載時点ではClaude CodeとCodex CLIで、今後さらに対応が増える予定とされています。
つまり、GenTeamを開発作業に当てはめると、例えば次のような分担を考えられます。
- Web調査はクラウド側のエージェント
- リポジトリの確認は手元PCのエージェント
- 判断と承認は人
以下は、この考え方を図にした筆者の構成案です。製品内部の通信経路を示すものではありません。
同じチャンネルから依頼できても、エージェントが参照できるファイルや利用できるツールまで同一とは限りません。
役割を決める際は、誰に何を頼むかだけでなく、その作業に必要な入力がどこにあるかも合わせて考える必要があります。
2. 開発で試すなら「調査 → コード確認 → 人のレビュー」
最初から多数のエージェントを用意するより、まずは成果物の受け渡しが見える小さな作業から試したいです。
例えば、あるライブラリの更新を検討する場面です。
以下は実行結果ではなく、筆者が考えた運用例です。
| 担当 | 依頼する仕事 | 次の担当に渡すもの |
|---|---|---|
| 調査エージェント | 公式リリースノートから変更点を拾う | 出典URL、対象バージョン、影響しそうなAPI |
| 手元PCのエージェント | リポジトリ内で該当APIの使用箇所を探す | ファイル名、該当箇所、変更案 |
| 人 | 調査内容と実際のコードを照合する | 採用する変更と、その判断理由 |
この分け方なら、例えば次のようなケースを切り分けやすくなりそうです。
- 調査内容そのものが誤っていた
- 調査内容は正しいが、自分のコードへの当てはめを誤った
- 変更案は妥当だが、業務上の理由で今回は採用しない
調査担当への依頼例
@researcher
対象ライブラリの現行バージョンと更新先バージョンを指定します。
公式ドキュメントとリリースノートから、破壊的変更を調べてください。
出力には次を含めてください。
- 変更対象のAPI
- 変更内容
- 出典URLと対象バージョン
- 確認できなかった点
一般論と、このバージョンで確認できた事実を分けてください。
コード確認担当への依頼例
@engineer
調査担当の報告をもとに、この作業ディレクトリで
影響する可能性のあるコードを確認してください。
今回はファイルを変更せず、次を報告してください。
- 該当ファイルとコードの位置
- 影響すると判断した根拠
- 変更する場合の方針
- 確認に使うテスト
調査結果に不足があれば、推測で埋めず質問してください。
最初の検証では、ここまでを完全に自動化する必要はないと考えています。
まず人が調査結果を確認し、次の担当に渡す。その中で「毎回どの情報を渡しているか」が見えてきたら、その受け渡しを後から自動化する方が安全です。
3. 会話だけで終わらせず、完了条件を決める
GenTeamのタスクは、To Do → In Progress → In Review → Done の状態で管理でき、チャンネル単位・ワークスペース単位のタスクボードから状態や担当者で絞り込めると説明されています。
公式ヘルプでは、エージェントがタスクを引き受け、専用スレッドに進捗や結果を投稿し、レビューへ進める流れが説明されています。また、1つのタスクに同時に割り当てられる担当者は最大1名で、人にもAIエージェントにも同じように割り当てられます。担当が重複しない作りになっている、という説明です。
ただし、タスクの状態がDoneになることと、成果物が正しいことは別です。
先ほどのライブラリ更新調査なら、依頼時に次のような完了条件を添えておきたいです。
レビューへ進める条件：
1. 変更点に公式の出典URLが付いている
2. 対象バージョンが明記されている
3. 影響箇所がファイル単位で示されている
4. 未確認事項が列挙されている
5. コード変更やテストを実施したかどうかが区別されている
人が確認しやすい成果物を先に定義しておけば、「調べました」という返答から追加で情報を聞き出す作業を減らせます。
AIエージェントを増やすことよりも、どの状態になったら次の担当へ渡してよいかを決めることの方が、最初は重要かもしれません。
4. Skillsは、うまくいった依頼手順を再利用する場所として考える
公式では、Skillsは「特定の仕事のために作られた、再利用可能なAIツール」と説明されています。GenTeam側のヘルプでは、エージェントに与えたSkill（プレイブック）に従って動く、という書かれ方をしています。
同じ指示を毎回書き直すのではなく、うまくいった手順や出力構成をSkillとして残し、繰り返し利用できます。
保存の仕方も難しくはなく、うまくいったワークフローについてSuper Agentに「これをスキルとして保存して」と伝える形で登録できると説明されています。共有については、個人単位のPeer Shareと、組織全体へ公開するTeam Publish（Team Plan）が用意されています。
先ほどの例なら、次のような手順は再利用したくなります。
- 公式情報を優先して調べる
- 対象バージョンを必ず明記する
- 出典URLを付ける
- 確認できなかった点を分ける
- 推測と確認済みの事実を分ける
個人的には、次の順序が試しやすそうです。
- まず通常の依頼文で1件進める
- 人が追加確認・修正した点を記録する
- 次回も必要な手順だけを抜き出す
- 再利用する手順をSkillにまとめる
最初から長い手順書を作るより、実際の作業で必要になった確認項目を積み上げる方が、エージェントの役割との対応も明確になります。
外部サービスとの接続を加える場合も、「GitHubと接続できるか」だけでなく、例えば次のように入出力の粒度を決めておきたいです。
- PRのどの情報を読むのか
- Issueやコメントまで参照するのか
- 最終的に何を成果物として返してほしいのか
なお、この例での外部サービス連携は未検証です。
5. 「ローカル」「記憶」を強く解釈しすぎない
自分のPCで実行しても、データがPC内に閉じるとは限らない
公式ヘルプでは、自分のPCに接続したエージェントはClaude CodeまたはCodex CLIを通じて、指定した作業ディレクトリの中でファイルの読み書き、コマンド実行、コード作成などを行うと説明されています。
ここで切り分けて考えたいのが、処理を実行する場所と、モデル推論の通信先は同じ話ではないという点です。
「ファイル操作やコマンド実行が自分のPCで行われる」という説明だけから、モデル推論までPC内だけで完結すると判断するのは避けた方がよさそうです。実際、公式ヘルプ側も「自分のハードウェアと自分のモデルアクセスを使う」という書き方をしており、モデルへのアクセスがあること自体は前提になっています。
導入時には、少なくとも次を別々に確認する必要があります。
- ファイルを読み書きする場所（指定した作業ディレクトリの範囲）
- 利用するClaude Code / Codex CLIの設定
- モデルに送信する情報と、その送信先
- チャンネルに投稿するコード・ログ・成果物
- 利用するモデルやサービス側の契約・データ取り扱い条件
これはGenTeam固有の通信仕様を断定するものではありません。
「ローカルエージェント」という言葉だけでデータの送信範囲を判断しないための整理です。機密コードを扱う場合は、実際に利用するCLI、モデル、接続先、契約条件まで含めて確認する必要があります。
なお、エージェント側の設定として確認できることも公式ヘルプに記載があります。エージェントのプロフィールでは、利用するAIモデル、DMを送れる相手、接続済みサービスのうちどれにアクセスさせるかを指定でき、Workspaceタブからはそのエージェントが扱っているファイルを読み取り専用で確認できるとされています。権限の範囲を狭めたい場合は、この辺りから見ていくのがよさそうです。
履歴や記憶があることと、重要事項を明示することは両立する
公式には、エージェントが指示・好み・文脈を継続して記憶し、チャンネルの過去の会話や共有ファイルも参照できると説明されています。後からチャンネルに追加したエージェントでも、それ以前のやり取りを読める、という説明もあります。
これは、毎回ゼロから説明し直さなくてよいという意味で便利です。
一方で、重要な設計判断まで会話履歴だけに任せるのではなく、短い「決定メモ」として残しておく方が、人にもエージェントにも確認しやすいと考えています。
例えば次のような形です。
決定：今回はライブラリ更新を見送る
理由：置き換え対象のAPIがあり、先に回帰テストが必要
再検討条件：対象テストが追加され、更新ブランチで成功すること
こうしたメモがあれば、「前に何を決めたか」を探す対象が明確になります。
長期的にAIへ仕事を任せる場合ほど、記憶に期待するだけでなく、重要な判断を短く構造化して残すことが効いてきそうです。
6. 最初の検証は、公開サンプルの読み取りから
実際に試す際は、公開サンプルの小さなリポジトリを使い、「READMEとコードの不一致を探す」程度の作業から始める予定です。
コード修正まで一気に依頼せず、まず次の点を観察したいです。
| 観察すること | 記録する内容 |
|---|---|
| 調査結果を次の担当へ渡せるか | 再説明が必要だった情報 |
| 正しいコードを参照できるか | ファイル名と根拠の正確さ |
| タスクとして追えるか | 担当、進捗、レビュー時の成果物 |
| 人の作業が減るか | 依頼・受け渡し・確認にかかった時間 |
評価したいのは、単に「AIの回答が速いか」だけではありません。
人が情報を運び直す手間と、成果物を確認する手間がどう変わるかを見たいと考えています。
もし、AIを3つ使うことで回答は増えたものの、人の確認作業も3倍になったのであれば、期待した分担にはなっていません。
逆に、調査結果・コード上の根拠・未確認事項が一定の形式で集まり、人は最終判断に集中できるのであれば、GenTeamのような共有ワークスペースを使う意味が見えてきます。
まとめ
Gensparkを使っていて何気なく見つけたGenTeamですが、調べてみると、単に複数のAIと会話するだけではなく、役割や実行環境を分けながら仕事を進めるための仕組みとして設計されていることが分かりました。
個人的には、次の4点がポイントだと感じました。
-
会話する場所と作業する場所を分けられる
- クラウド、手元PC、Claw / OpenClawのエージェントを同じワークスペースで扱える
-
開発では「調査 → コード確認 → 人のレビュー」のように役割を分けると試しやすい
- どこで判断を誤ったか追いやすくなる
-
役割より先に、成果物と完了条件を決めることが重要
- TaskやSkillsは、その運用を定着させる手段として使えそう
-
「ローカル」「記憶」「クレジット非消費」は、それぞれ別の観点として確認する
- 実行場所だけでデータ送信範囲や総コストまで判断しない
- クラウドエージェントのクレジットは作成者側から消費される
最初から「複数AIが自律的に全部やってくれる」ことを目指すより、まずは小さな読み取り作業で、調査 → コード確認 → 人によるレビューくらいの流れから試すのがよさそうです。
その中で、人が毎回補足している情報が見えてきたら、そこをTaskやSkillsに寄せていく。
何気なく見つけた機能でしたが、GenTeamはAIエージェントそのものの性能だけでなく、複数のAIと人の間で仕事をどう受け渡すかを考える仕組みとして見てみると面白そうです。
まだ実機で十分に検証できていない部分もあるため、今後実際に試してみて、どこまで作業を分担できるのか確認してみたいと思います。
参考（公式情報）
- GenTeam Help Center
- Skills Help Center
- Genspark Claw Help Center
- Credits Guide Help Center
- GenTeam（製品ページ）
確認日：2026年9月6日