Agent on KnightLiブログ

DeepSeek V4 FlashでGodotゲームDemo：数セントでどこまで動くのか

Wed, 06 May 2026 09:22:18 +0800

DeepSeek V4 Flash をGodotゲームDemoの開発に使うと、どこまでできるのか。

焦点ははっきりしている。実行でき、観察でき、物理効果を備えた小さなGodot Demoを作れるのかという点だ。

結論から言えば、動く。商用レベルの品質ではないが、ゲームプレイのプロトタイプや物理インタラクションDemoとしては十分に使える。さらに重要なのは、コストが非常に低く、アイデアの素早い検証に向いていることだ。

Demoの表現

このDemoの中心は物理インタラクションだ。

直感的に確認できる効果は次の通り。

ロープを切断できる。
箱が地面に落ちる。
質量を大きくすると、箱の衝突がより激しくなる。
ロープには比較的はっきりした弾性がある。
摩擦と弾性を調整すると、箱に明確な滑りや反発が出る。

見た目の挙動からすると、これは単に「Godotスクリプトを数本生成した」だけではない。実行でき、物理挙動を観察できる小型プロトタイプになっている。

使える度合い

このDemoの価値は「動く、見られる、直せる」ことにある。完全なゲームでも、そのまま商用化できるプロジェクトでもないが、いくつかの点は示している。

DeepSeek V4 Flash はGodot Demoの基本目標を理解できる。
AI Agentは要求を実行可能なプロジェクトに変換できる。
Godotの物理インタラクションのような非Web系タスクも、低コストなプロトタイプ段階に入っている。
個人開発者にとって、アイデアを素早く「見えるもの」に変えられる。

正式なゲームを作るにはもちろん不十分だ。しかし「この遊びは面白いのか」「物理効果はだいたい作れるのか」を検証する目的なら、このDemoはすでに使える。

コスト面の意味

注目すべきなのは、画面がどれだけ精緻かではなく、コストだ。

Godotの物理Demoが数セント程度のモデルコストで実行可能な形になるなら、その意味はプロのゲーム開発を置き換えることではない。プロトタイプの試行錯誤コストを大きく下げることにある。

以前なら、小さなゲームアイデアを検証するだけでも、Godotを理解し、スクリプトを書き、シーンを組み、物理パラメータを調整する必要があった。いまはAI Agentに実行可能な版をまず作らせ、人間が方向性を判断できる。

インディー開発者にとって、この種の低コストな試行は役に立つ。

ゲームプレイのコンセプトを素早く検証する。
他人に見せる一時的なDemoを生成する。
Godot APIや物理システムを探索する。
アイデアを実行可能な初版プロジェクトに変える。
方向性が固まる前の手書きコードコストを減らす。

DeepSeek V4 Flashの表現

注目したいのは、使っているのが DeepSeek V4 Flash であり、より高価で重いフラッグシップモデルではない点だ。

低コストなプロトタイプという位置づけでは、十分よく機能している。最強でも、最も安定しているわけでも、プロダクション工程の納品に最適なモデルでもないが、予算に敏感で、方向性を素早く試したい場面では魅力がある。

向いている場面

DeepSeek V4 Flash + Agent + Godot がより向いているのは、次のようなタスクだ。

小規模なゲームプレイプロトタイプ。
物理効果Demo。
UIまたはインタラクションのコンセプト検証。
教材用サンプル。
Godotプロジェクト構造の理解補助。
実行可能な初版プロジェクトの生成。

一方で、次のようなタスクを直接任せるのには向いていない。

大規模なゲームアーキテクチャ。
複雑なキャラクターコントローラー。
ネットワーク同期。
商用プロジェクトの中核コード。
高精度な物理シミュレーション。
人間のテストを経ない自動コミット。

言い換えれば、第一稿や実験場には向いているが、プロダクション工程の責任者には向いていない。

何を示しているのか

これは、AIコーディングがWeb、スクリプト、バックエンドAPIから、ゲーム開発やインタラクティブプロトタイピングへ広がり続けていることを示している。

かつてゲーム開発の参入障壁は高かった。特にエンジン、スクリプト、アセット管理、物理システムが絡み合うと、初心者は詰まりやすい。いまはモデルとAgentツールで先にプロジェクトを組み立て、開発者はゲーム性の判断や効果の調整に集中しやすくなっている。

この変化は、主に三つの影響をもたらす可能性がある。

第一に、ゲームプロトタイプが安くなる。多くのアイデアは完全開発まで待たずに、まず実行可能なDemoとして検証できる。

第二に、インディー開発者がより試しやすくなる。Godotを知らない人でも、AIの助けでプロジェクト構造と基本フローに触れられる。

第三に、モデルの安定性がより重要になる。ゲーム開発はコードが動くだけでは足りない。効果が自然で、操作感がまともで、パラメータを制御できる必要がある。今後、実際の画面や実行状態とよりうまく結びつけられるモデルほど、この種のタスクに向く。

まとめ

DeepSeek V4 FlashでGodot Demoを作ることは、一言で言えばこうだ。完璧ではないが、十分安く、十分速く、プロトタイプには十分向いている。

商用ゲームにはまだ遠いが、非常に低いコストで小さなゲームアイデアを検証する目的なら、すでに価値がある。

個人開発者にとって現実的な使い方は、ゲーム全体をAIに任せることではない。まずAIに動く工程を出させ、その後の判断、取捨選択、磨き込みを人間が担当することだ。この使い方なら、DeepSeek V4 Flashのような低コストモデルはかなり魅力的になる。

DeepSeek-V4 Preview 公開：1M コンテキスト、2 モデル構成、API 移行の注意点

Fri, 24 Apr 2026 22:39:46 +0800

DeepSeek は 2026-04-24 に DeepSeek V4 Preview Release を公開しました。公式ニュースページを見ると、今回の更新の軸はかなりはっきりしています。1M context、V4-Pro と V4-Flash の 2 モデル構成、Agent 向けの専用最適化、そして API 側のモデル移行です。

一言でまとめるなら、今回のリリースの本質は、DeepSeek が単に「より強いモデル」を目指しているだけではなく、超長コンテキストと Agent 能力をそのまま実運用に載せやすい形へ進めていることです。

1. 今回公開されたもの

公式ページによると、DeepSeek-V4 Preview は主に次の 2 つのラインで構成されています。

DeepSeek-V4-Pro
DeepSeek-V4-Flash

それぞれの公式説明も非常に分かりやすいです。

DeepSeek-V4-Pro：1.6T total / 49B active params
DeepSeek-V4-Flash：284B total / 13B active params

名前を見るだけでも、今回は単一モデルの更新ではなく、高性能側と高コスト効率側を同時に展開していることが分かります。

V4-Pro はより高い性能上限を重視しており、公式は世界トップクラスのクローズドモデルに競合できるとしています。一方の V4-Flash は、速度、効率、コストをより重視した位置づけで、レイテンシや API 料金に敏感な用途に向いています。

2. `1M context` が今回いちばん目立つポイント

公式ページで最も印象的な表現の 1 つが、「Welcome to the era of cost-effective 1M context length.」 です。

DeepSeek は今回、単に長コンテキスト対応をうたっているだけではありません。1M context をこの世代の標準能力として打ち出しています。ページでも次のように明記されています。

1M context は公式 DeepSeek サービス全体の標準になった
V4-Pro と V4-Flash はどちらも 1M context をサポートする

重要なのは、これが単に「より多くの token を詰められる」という話ではないことです。実際には次のような作業に直結します。

大規模コードベースの理解
長文書の Q&A や情報整理
複数ターンにまたがる Agent ワークフロー
複数ファイル、複数ツール、複数段階にまたがる複雑なタスク

コンテキストウィンドウが十分に大きければ、途中で文脈を落として何度も読み直すことが減ります。これは Agent コーディングや複雑な知識作業で特に重要です。

3. `V4-Pro` が主に強調していること

公式ページの表現を見ると、DeepSeek-V4-Pro が強く押し出しているのは次の 3 点です。

Agentic Coding 能力
世界知識
推論能力

ページでは、V4-Pro が Agentic Coding ベンチマークでオープンソース SOTA を達成したこと、世界知識では現行のオープンモデルの中で最上位クラスであり Gemini-3.1-Pro にのみ後れを取ること、さらに数学、STEM、コーディングで現行のオープンモデルを上回り、トップクラスのクローズドモデルに対抗できることが示されています。

つまり V4-Pro は、単純な質問応答モデルというより、高難度推論、複雑なコーディング、長いタスクの遂行に寄せた設計です。

4. `V4-Flash` は単なる縮小版ではない

もう 1 つ注目すべき点は、DeepSeek が V4-Flash を単なる廉価版として扱っていないことです。むしろ、実務的な多くのタスクでは十分に強いモデルであることを前面に出しています。

ニュースページによると、V4-Flash は：

推論能力が V4-Pro にかなり近い
シンプルな Agent タスクでは V4-Pro と同等の性能を持つ
パラメータ規模が小さく、応答が速く、API 価格も低い

つまり今回は、「1 つが旗艦、もう 1 つが入門」という極端に分かれた構成ではなく、次のような役割分担に近いです。

V4-Pro：より高い性能上限を狙う
V4-Flash：より低いレイテンシと優れたコスト効率を狙う

開発者にとっては、このほうが実際には使いやすい構成です。多くの本番タスクで必要なのは、理論上最強のモデルではなく、十分に強く、十分に速く、十分に安いモデルだからです。

5. Agent 最適化がかなり前面に出ている

今回の発表でもう 1 つ明確なのは、DeepSeek が V4 を Agent シナリオへ積極的に寄せていることです。

公式ページでは、DeepSeek-V4 が次のような主要 AI Agent とシームレスに統合されていると紹介されています。

Claude Code
OpenClaw
OpenCode

加えて、DeepSeek 自身も社内の agentic coding に V4 を使っていると述べています。

これは、対象が単なるチャットや通常の補完ではなく、コードを読み、構造を理解し、ツールを呼び出し、結果を生成し、その一連の流れをつなぐ長いワークフローになっていることを意味します。

最近 coding agent を追っているなら、この点は見逃しにくいです。モデル提供側の競争軸が、ベンチマークだけではなく「本当にワークフローに組み込めるか」へ広がっているからです。

6. 構造的な工夫は長コンテキスト効率のため

技術面では、公式ページは今回の構造的な工夫を次のようにまとめています。

token-wise compression
DSA (DeepSeek Sparse Attention)

方向性は非常に明快です。長コンテキストを、より安く、より高効率にし、計算コストとメモリコストをできるだけ抑えることです。

ニュースページでは完全な技術詳細までは踏み込んでいませんが、少なくとも DeepSeek が単純に計算資源を増やして長ウィンドウを支えているだけではなく、長コンテキスト効率のためのアーキテクチャ最適化も行っていることは読み取れます。

実際の利用者にとっては、単にコンテキスト数値が大きいことよりも、こちらのほうが重要な場合が多いです。なぜなら実用性を決めるのは、1M が使えるかどうかだけではなく、次のような点だからです。

速度が実用範囲に収まるか
コストが許容範囲に収まるか
長コンテキスト処理が実際に安定するか

7. API はすでに利用可能だが、モデル切り替えに注意

公式ページでは、今回の API が当日から利用可能であることも明記されています。

切り替え方法も比較的シンプルです。

base_url はそのまま
モデル名を deepseek-v4-pro または deepseek-v4-flash に変更する

さらに、両モデルが次をサポートするとされています。

1M context
Thinking / Non-Thinking の 2 モード
OpenAI ChatCompletions
Anthropic APIs

つまり、すでに DeepSeek API を使っているなら、移行の難しさはそれほど高くありません。主な作業はモデル名の差し替えと挙動確認です。

8. 旧モデルの終了時期も明確に書かれている

開発者にとって、この発表の中で見落とせない情報の 1 つが旧モデルの終了通知です。

公式には：

deepseek-chat
deepseek-reasoner

が 2026 年 7 月 24 日 15:59 UTC 以降に完全に廃止され、アクセス不能になると書かれています。

またページでは、現在この 2 つのモデルは実質的に deepseek-v4-flash の非思考 / 思考モードへルーティングされているとも説明されています。

そのため、もし今もプロジェクト内で deepseek-chat や deepseek-reasoner を直接参照しているなら、正式終了直前まで待つのではなく、今のうちに移行計画を進めるべきです。

9. この発表をどう読むべきか

今回の更新をいくつかの要点に圧縮すると、次のようになります。

DeepSeek は 1M context を高級機能ではなく標準機能へ変え始めている
2 モデル戦略がより明確になった。1 つは性能上限、もう 1 つは速度とコスト効率
Agent 能力がかなり中心的な位置に置かれている
API の移行経路は比較的シンプルだが、旧モデルの終了時期には早めの対応が必要

一般ユーザーにとっては、長文書、長いコード文脈、長い作業フローを 1 回のコンテキストに収めやすくなるのが分かりやすい変化かもしれません。
開発者にとってより重要なのは、すでに Agent、コードアシスタント、情報整理、複雑な自動化ワークフローを作っているなら、この世代のモデルは明らかにそうした用途を意識して設計されているという点です。

今回の DeepSeek の発表は、単なる通常のモデル更新というより、次の製品方向をより明確に示したものだと見たほうが自然です。超長コンテキスト、Agent 最適化、そして実用的な API 運用性です。

AI用語解説: Agent、MCP、RAG、Token をわかりやすく整理する

Thu, 23 Apr 2026 13:13:40 +0800

AI に触れ始めたばかりのとき、人を遠ざけやすいのはモデルそのものより、会話の中に次々出てくる用語です。Agent、MCP、RAG、AIGC、Token はどれも見覚えはあっても、やさしく説明されないと本当の意味まではつかみにくいものです。

この記事では、よくある入門向けの説明の流れに沿って、AI で頻出する 10 個の用語を覚えやすい形にまとめます。学術的に厳密に説明することよりも、日常的な AI の話題についていける基本イメージを作ることを目的にしています。

10 個の代表的な AI 用語は何を意味するのか

1. Agent: 会話だけでなく実行もする AI

Agent は、実際に作業を進めてくれる AI アシスタントだと考えると分かりやすいです。

普通のチャットボットは、質問すると答えるという形にとどまりがちです。Agent はそこから一歩進み、タスクを分解し、手順を組み立て、ツールを呼び出し、最後に結果を返します。資料整理、調査、文書生成のような依頼でも、助言だけで終わらず、一連の動作をつないで実行することがあります。

だから Agent の本質は、話せるかどうかではなく、動けるかどうかにあります。

2. OpenClaw: PC に常駐する AI アシスタント

ここでの OpenClaw は、PC の中に住む AI アシスタントのようなものとして説明されています。

この種のツールは、デスクトップ操作に近い AI 支援だと考えると分かりやすいです。文字入力を受け取るだけでなく、画面を見たり、ローカルツールを呼び出したり、手順に沿って作業したりすることがあります。一般的な Web チャットと比べると、実際の操作能力がより重視されます。

Agent が実行型 AI という抽象的な概念だとすれば、こうしたデスクトップ型アシスタントは、その考え方の PC 上での具体例だと言えます。

3. Skills: Agent に追加する能力パック

Skills は、Agent の機能モジュールや操作ルールだと捉えられます。

同じ Agent でも、どの Skills を持つかによって得意分野が変わります。文章作成寄りのものもあれば、データ整理向けのものもあり、コード処理に向いたものもあります。スマートフォンのアプリに少し似ていますし、再利用できるワークフロー集にも近いです。

つまり、モデルそのものが急に賢くなったというより、背後にあるルール、ツール、手順が明確になった結果だと言えます。

4. MCP: AI が外部ツールにつながるための共通方式

MCP は Model Context Protocol の略です。

身近な比喩で言えば、AI の世界における Type-C 端子のようなものです。以前はモデルを別々のツールにつなぐたびに個別実装が必要になりがちでしたが、共通プロトコルがあると接続方法を標準化しやすくなります。

多くの人にとって大事なのは、MCP が「モデルが答えられるかどうか」の話ではなく、「モデルが外部ツールや外部リソースに安全かつ安定して接続するにはどうするか」の話だという点です。

5. ガチャ: AI 生成にはランダムさがある

「ガチャ」という表現は、AI 画像生成、動画生成、クリエイティブ用途でよく使われます。

意味はシンプルです。同じプロンプトで、同じ方向性を指定しても、毎回まったく同じ結果になるとは限りません。すごく良い結果が出ることもあれば、明らかに崩れることもあります。そのため、何度も生成して当たりを引く感覚がゲームのガチャにたとえられます。

ここで押さえておきたいのは、AI 生成は固定的な公式ではなく、確率的な揺らぎを含んだプロセスだということです。

6. API: アプリとモデルをつなぐ入口

API は Application Programming Interface の略です。

プログラム同士がやり取りするための標準的な入口だと考えると分かりやすいです。自分のアプリ、スクリプト、エディタからモデルサービスを呼び出すときは、実質的に API を通じてリクエストを送り、結果を受け取っています。

モデルサービスをレストランにたとえるなら:

メニューは API ドキュメント
注文は API リクエスト
厨房から料理が返ってくるのはモデルの応答

そのため、見た目は違うツールでも、裏側では何らかの API を呼んでいることが多いです。

7. マルチモーダル: AI は文字だけを扱うわけではない

マルチモーダル とは、AI が文字の読み書きだけに限られず、複数の種類の情報を扱えることを指します。

たとえば画像を見たり、音声を理解したり、動画を解釈したり、画像を生成したり、リアルタイムの音声や映像のやり取りを支えたりできます。文字しか扱えなかった初期のモデルと比べると、「見る・聞く・話す・書く」に近い能力を併せ持つ方向へ進んでいます。

だからこそ、今の AI 製品は単なるテキスト入力欄だけでは語れなくなっています。

8. RAG: 先に資料を探し、そのうえで答えを作る

RAG は Retrieval-Augmented Generation の略です。

これはとても実務的な課題に向いています。モデルの学習データには時点の限界があり、社内の最新資料、サポート記録、業務ルールを自動では知りません。RAG は、まず指定した資料群から関連情報を探し、その内容を踏まえて回答を生成する考え方です。

価値が出やすい点は主に 3 つあります。

回答が実際の資料に寄りやすくなる
どの資料を根拠にしたか追いやすい
新しい資料を追加すれば知識を更新しやすい

そのため、企業向けナレッジベース、AI カスタマーサポート、社内 Q&A では RAG がよく使われます。

9. AIGC: AI が作るコンテンツ全体を指す言葉

AIGC は AI Generated Content の略です。

これは単独のツール名ではなく、AI が生成したコンテンツ全般を指す総称です。文章、画像、音声、動画などが含まれます。AI ライティング、AI イラスト、AI による短尺動画制作、AI 音声生成などはすべて AIGC の枠で理解できます。

大事なのは、この言葉が特定のモデルではなく、コンテンツの作り方そのものを指していることです。

10. Token: モデルが内容を処理するときの計量単位

Token は、モデルがテキストを処理するときの基本的な計量単位だと考えられます。

これは 1 文字や 1 単語と完全に一致するわけではありませんが、実用上は計算量や課金の共通単位として捉えて問題ありません。入力でも Token を消費し、出力でも Token を消費し、保持しているコンテキストも同じように Token を使います。

だから多くのモデルサービスがコンテキスト長、コスト管理、プロンプト圧縮を強調するのは、結局どれも Token と深く関係しているからです。

Claude Code のマルチエージェント協調: Subagents と Agent Teams はどう使い分けるか

Wed, 22 Apr 2026 21:35:52 +0800

Claude Code でマルチエージェント協調を考えるとき、最も混同しやすいのが Subagents と Agent Teams です。どちらも「複数の Agent を動かして一緒に作業する」ように見えますが、実際には想定している使い方が異なります。簡単に言えば、前者は独立したタスクを切り出して処理するのに向いており、後者は複数の Agent が同じテーマについて継続的に協力し、相互に検証しながら進めるのに向いています。

もし Skill を使ったことがあるなら、まずは次のように理解すると分かりやすいです。

Skill は手順やルールを定義する
Subagent や Agent teammate は実際の作業を行う

つまり重要なのは、どちらが「上位」かではなく、どの種類の協調課題を解きたいのかです。

Subagents: サイドタスクを切り出す

Subagents は、現在のセッションから一時的に送り出す分身に近い存在です。各分身は独自のコンテキストウィンドウを持ち、作業後は結果の要約だけを返します。そのため、メインの会話は大量の中間ログや出力で埋まりにくくなります。

この仕組みには、実務上かなり分かりやすい利点があります。

メインスレッドがきれいなままで、テストログや検索結果、長い出力で汚れにくい
相互依存のない調査や実行タスクを並列化できる
「結果だけ返してくれればよい」タイプの仕事に向いている

元記事では、Claude Code には次の 3 種類の組み込み Subagent があると説明されています。

Explore: 読み取り専用で、コードベースの高速検索に向く
Plan: 読み取り専用で、plan mode 中のバックグラウンド情報収集に向く
General-purpose: 読み書き可能で、探索と編集を組み合わせる仕事に向く

カスタム Subagent

組み込みのものだけでは足りない場合は、自分で Subagent を定義できます。やり方はシンプルで、Markdown ファイルを用意するだけです。

.claude/agents/: 現在のプロジェクトでのみ有効
~/.claude/agents/: すべてのプロジェクトで有効

ファイル形式は次のようになります。

---
name: code-reviewer
description: Expert code review specialist. Proactively reviews code for quality, security, and maintainability. Use immediately after writing or modifying code.
tools: Read, Grep, Glob, Bash
model: inherit
---
You are a senior code reviewer ensuring high standards of code quality and security.

When invoked:

1. Run git diff to see recent changes
2. Focus on modified files
3. Begin review immediately

Review checklist:

- Code is clear and readable
- Functions and variables are well-named
- No duplicated code
- Proper error handling
- No exposed secrets or API keys
- Input validation implemented
- Good test coverage
- Performance considerations addressed
Provide feedback organized by priority:

- Critical issues (must fix)
- Warnings (should fix)
- Suggestions (consider improving)

Include specific examples of how to fix issues.

ここで特に重要なのは description です。Claude はこの説明を見て、いつこの Subagent を呼ぶべきか判断します。説明が正確であるほど、呼び出しの精度も上がりやすくなります。

ほかにも知っておくと便利な設定項目があります。

tools: 使用できるツールを制限する
model: sonnet、opus、haiku、inherit から選ぶ
permissionMode: 編集権限や権限プロンプトの挙動を制御する
memory: Subagent に対話をまたぐ記憶ディレクトリを与える

一時的にだけ使いたい場合は、CLI 経由で定義することもできます。

claude --agents '{
  "code-reviewer": {
    "description": "Expert code reviewer. Use proactively after code changes.",
    "prompt": "You are a senior code reviewer. Focus on code quality, security, and best practices.",
    "tools": ["Read", "Grep", "Glob", "Bash"],
    "model": "sonnet"
  }
}'

Subagents が向いている場面

Subagents が特に向いているのは、たとえば次のような仕事です。

テストを実行し、数千行のログではなく失敗要約だけをメイン会話に返す
相互依存しない複数モジュールの調査を並列に進める
「問題を見つける」と「修正する」を単純なパイプラインに分ける

たとえば次のような指示です。

`1`	`Research the authentication, database, and API modules in parallel using separate subagents`

`1`	`Use the code-reviewer subagent to find performance issues, then use the optimizer subagent to fix them`

一方で、タスクが何度も往復しながら調整を要する場合、複数段階で大量の文脈を共有する場合、あるいは変更が一つ二つのファイルに集中している場合は、Subagent を立てるよりメイン会話で直接処理したほうが楽なことが多いです。

Agent Teams: 複数の独立セッションで協調する

Agent Teams は別のレイヤーの機能です。1 つのセッション内で分身を出すのではなく、完全に独立した複数の Claude Code インスタンスを起動し、共有タスクリストを中心に協調させます。しかも、メンバー同士が直接メッセージを送り合うこともできます。

そのため、単なるサイドタスク処理というより、本当に小さなチームを作る感覚に近いです。

元記事では、これはまだ実験機能であり、先に有効化が必要だと説明されています。

{
    "env": {
        "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
    }
}

これを settings.json に追加すると、Claude に対して目的に応じた team を組ませることができます。たとえば次のような形です。

1
2
3

I'm designing a CLI tool that helps developers track TODO comments across
their codebase. Create an agent team to explore this from different angles: one
teammate on UX, one on technical architecture, one playing devil's advocate.

Agent Teams の構成

Agent Team は主に次の 3 つで構成されます。

Team lead: あなたが使っているメインセッション。編成、割り振り、要約を担当する
Teammates: 複数の独立した Claude Code インスタンス
Task list と Mailbox: 共有タスクリストとメッセージ経路

Subagents との最大の違いは、teammates 同士が直接やり取りできることです。毎回 lead を経由する必要はありません。タスク状態は通常 pending、in progress、completed の間を移り、1 つ終えた teammate は次のタスクを引き取ることもできます。

Agent Teams が向いている場面

複数視点からの検討、結論への異議申し立て、仮説同士の競合、あるいはモジュール単位の並列開発が必要なときは、Agent Teams のほうが適しています。

記事では次のような典型例が挙げられています。

同じ PR を複数 reviewer が並列でレビューし、それぞれ異なる観点を見る
同じ bug に対して複数の Agent が異なる仮説を立て、互いに反証する
フロントエンド、バックエンド、テストが別々の領域を並列で進める

たとえば並列コードレビューでは、次のように指示できます。

Create an agent team to review PR #142. Spawn three reviewers:
- One focused on security implications
- One checking performance impact
- One validating test coverage
Have them each review and report findings.

また、討論型のデバッグでは次のような使い方ができます。

Users report the app exits after one message instead of staying connected.
Spawn 5 agent teammates to investigate different hypotheses. Have them talk to
each other to try to disprove each other's theories, like a scientific
debate. Update the findings doc with whatever consensus emerges.

この種の仕事に共通しているのは、単に 1 つの答えが欲しいのではなく、複数の Agent が判断を持ち寄り、前提を揺さぶり合いながら、より確かな結論に収束していくことです。

どう使い分けるか

手早く判断したいなら、次のように覚えると分かりやすいです。

結果だけ持ち帰ればよいなら Subagents
議論や相互検証が必要なら Agent Teams

もう少し整理すると、主な違いは次の通りです。

通信方法: Subagents は主にメイン会話へ結果を返すが、Agent Teams はメンバー同士で直接やり取りできる
調整方法: Subagents はメイン会話側のオーケストレーションに依存しやすいが、Agent Teams は共有タスクリストをもとに各メンバーが自律的に動ける
Token コスト: Subagents のほうが軽く、Agent Teams は各 teammate が独立インスタンスのため高くなりやすい
向いている仕事: Subagents は独立性が高く結果志向の仕事向き、Agent Teams は議論や相互検証が重要な仕事向き

実運用で気をつけたいこと

Agent Teams は強力ですが、だからといってすべてのタスクで team を組むべきというわけではありません。記事では特に次のような現実的な注意点が挙げられています。

token 消費が明らかに大きい
複数 teammate が同じファイルを同時に編集すると、上書き競合が起きやすい
teammate が多すぎると調整コストが増え、成果が伸びるとは限らない

そのため、比較的安全な進め方としては次のようになります。

まずは 3〜5 人程度の teammate から始める
モジュールやファイル単位で仕事を分け、編集衝突を避ける
lead が早まって teammate の仕事に手を出し始めたら、先に待つよう明示する

また、現時点の実験版には次のような制約もあります。

/resume と /rewind で in-process teammates を復元できない
タスク状態が遅れて反映され、手動での更新が必要になることがある
1 人の lead が同時に扱える team は 1 つだけ
teammate がさらに子 team を作ることはできない

まとめ

この 2 つの機能は、互いの代替ではありません。解いている協調課題そのものが違います。

目的が「サイドタスクを並列化し、メインの文脈をきれいに保つこと」なら、まずは Subagents を使うのが自然です。目的が「複数の Agent に小さなチームのように協力させ、議論し、相互検証させること」なら、Agent Teams が向いています。

実際のタスクで一度試してみると、違いはかなり早く体感できます。片方は文脈の分離と結果回収に強く、もう片方は多視点での協調と継続的なやり取りに強い、という違いです。