Claude Code、Codex、Muse、Grok Bot…みんなの AI エージェントの使い方を調べて、おすすめのチートシートを作ってみた

開示: この記事は Grok Bot と一緒に書きました。調査と図の作成は Grok Bot が行い、私の使い方と関心は私の経験と発言によります。他の人の使い方は、X の公開投稿と Web の記事から集めています。

はじめに

みなさんは、AI エージェントをどう使っていますか？

Claude Code、Codex、Cursor、Gemini CLI、それに Hermes Agent や OpenClaw、Muse、Grok Bot など、AI エージェントを動かす製品や仕組みが一気に増えました。この記事では、それらを「道具」と呼びます（一般にはハーネスとも呼ばれます）。1 つを使い込む人もいれば、tmux でいくつも並べる人、司令塔の AI エージェントに他の AI エージェントを束ねさせる人、仕事と私用で分ける人もいます。

ただ、ユーザ本人が「こう組み合わせている」と書いた話は、個人の投稿に散らばっていて、全体の傾向はなかなか見えません。そこで、まず私の使い方を書き、X と Web から他の人の使い方を集めました。次に、AI エージェントが作業を繰り返す単位（エージェンティックループ）を説明し、そのうえで、集めた使い方を型に分けて数えました。最後に、どこまで任せるかを整理し、ユーザのタスクに合う型を Yes/No で選べるチートシートを付けました。

サマリ

この記事は、道具の比較ではありません。ユーザの仕事の構造から、AI エージェントの構成を選ぶための整理です。結論は次のとおりです。

• 型を分ける鍵は 2 つです。1 つは、作業文脈を隔離して並列に進めるかどうか。もう 1 つは、分解と統合の責任を、ユーザと AI エージェントのどちらが持つかです。この 2 つは別の観点なので、組み合わせられます。たとえば、リポジトリごとに tmux でセッションを分け、各セッションの中で、AI エージェントに分解と統合を任せる形です。
• 効くのは、AI エージェントを何本動かすかより、各 AI エージェントが、担当する作業の成否を確かめられるかどうかです。並列は、ユーザが複数のループを見るための手段にすぎません。
• 任せる範囲は、確かめられるか、戻せるか、方向が変わる判断か、の 3 つで区切ります。
• 外側でユーザが方向を決め、内側で AI エージェントが試す、二重のループとして整理しました。
• 構成の選び方は、Yes/No で答えるチートシート（後ろの「Yes/No で選ぶ構成のチートシート」の節、図 14）にまとめました。6 つの問いに答えると、ユーザのタスクに合う型が見つかります。

読む場所は、目的に合わせて選べます。ユーザのタスクに合う構成をすぐ選びたい方は、Yes/No で選ぶ構成のチートシートの節へ進んでください。結論の根拠を知りたい方は、調べ方の節と、三つの軸と軸 A の型の節から読んでください。運用の勘所を知りたい方は、閉じていない問題と二重のループの節と、任せる範囲の線引きの節が近道です。

私の使い方

最初に断っておくと、私の仕事は R&D 系で、しかも個人作業が中心という、少し特殊な事情があります。一般のエンジニアは、1 つか少数の開発リポジトリを、複数人で読み書きすることが多いと思います。私の場合は、リポジトリをいくつも一人で持っているので、その前提で読んでください。

私は仕事の開発を、Git のリポジトリ単位で回しています。1 つのリポジトリに、tmux の中の Claude Code を 1 つ割り当て、それを複数のリポジトリで並列に動かします。セッションを束ねるオーケストレーターや管理ツールは使いません。各タスクの進捗は、私が確認します。

一方、メールや予定など、仕事と関連の薄いプライベートな作業は、Muse と Grok Bot に任せています。

図 1: 私の使い方。仕事はリポジトリごとに tmux の Claude Code を 1 つ、進捗の確認は私。私用は Muse と Grok Bot

調べ方

X の公開投稿と Web の記事を、日本語と英語の両方で調べました。検索語は、Claude Code や Codex などのツール名に、tmux、並列、worktree、司令塔、使い分け、add-dir、複数リポジトリ、親ディレクトリ、Obsidian、調査、執筆などを組み合わせたものです。すべての例に出典のリンクを付け、英語の投稿は意味を保って日本語に直しています。

数えるのは、使い方の一次報告です。ユーザ本人が、実際に使っている構成を「こう使っている」「試した」と書いた投稿や記事を指し、同じ人は 1 件にまとめました。公式の説明、道具の紹介、ニュース、一般的な助言、構成が読み取れない感想は除いています。「併用している」と書くだけで、どの道具が何を担うか、どう受け渡すかが読み取れない投稿も、構成が読み取れないものとして除いています。採用は 54 件、除外は 40 件です。型の判定は、後の「三つの軸と軸 A の型」に書いた順に行い、最初に当たった型に 1 件だけ数えます。そのため、複数の型に当たる報告は順の早い型に入ります。たとえば、tmux 並列型と司令塔型を組み合わせた報告は、順の早い司令塔型に入ります。判定の順は、型ごとの件数に影響します。「使いこなしている人の共通点」などで引く Cherny さん、Karpathy さん、Hashimoto さん、Yegge さん、Willison さんの発言は、ループの設計を調べる過程で別に集めたもので、件数には入れていません。

エージェンティックループという単位

AI エージェントは、チャットのように一度答えて終わりではありません。ユーザから作業を受け取ると、AI エージェントが状況を集め、手を打ち、結果を確かめます。足りなければ、また状況を集め直します。この一周を繰り返すことが、Anthropic の言うエージェンティックループです（以下、ループ）。Anthropic は、AI エージェントはたいてい、環境からのフィードバックを手がかりに、LLM がツールを使う繰り返しにすぎない、と説明しています（Building effective agents）。Claude Code の公式説明も、同じ一周を、状況を集める、手を打つ、確かめる、の三段階に分けています（How Claude Code works）。

図 2: エージェンティックループ。ユーザが作業を頼み、AI エージェントが環境の結果を見て、次の手を決める

このあとで定義する型は、このループが同時にいくつ動くか、誰がループに仕事を割り振るかの違いです。たとえば、tmux 並列型では、ユーザが独立したループを並べます。司令塔型では、司令塔の AI エージェントが割り振ります。ループそのものの設計は、型を見たあとの「ループの設計と任せる範囲」で書きます。

三つの軸と軸 A の型

採用した報告には、3 つの軸で型を付けました。

• 軸 A（開発の組み立て）: 開発の仕事を、どの AI エージェントが、誰の指示で、どう進めるか。開発の報告 24 件に、1 件につき 1 つの型だけを付けます。
• 軸 B（仕事と私用の切り分け）: 仕事と日常で、相手の AI エージェントを分けているか。
• 軸 C（1 本のセッションの相手）: 1 本のセッションが何を相手にするか。

軸 B と軸 C は軸 A のどれとでも重なるので、別に数えます。3 つの軸と軸 A の 6 つの型を、1 枚にまとめると次のとおりです。

図 3: 開発の組み立て（軸 A）、仕事と私用の切り分け（軸 B）、1 本のセッションの相手（軸 C）

軸 A の判定は、次の順で最初に当たった型に決めます。

• クラウドへ渡す型。主たる作業が、手元ではなくクラウド上の AI エージェントのセッションで進む。
• 司令塔型。ユーザが直接話す相手は司令塔の AI エージェントで、他の AI エージェントへの割り振りは、ユーザではなくその司令塔が行う。
• 親エージェントと子ツール型。ユーザが直接話す相手は AI エージェントが 1 つで、その AI エージェントが別の AI エージェントや LLM をツールとして呼び出す。
• 道具の使い分け型。ユーザが 2 つ以上の異なる道具を同時に使い、どの道具が何を担うかを分け、道具同士の受け渡しはユーザが行う。
• tmux 並列型。同じ役割のセッションが同時に複数動き、割り振りと確認はユーザ（ユーザが操作する管理ツールを含む）。使う道具が違っても、道具ごとの役割分担が書かれていなければ、同じ役割とみなす。
• 単一セッション型。ユーザが直接話す AI エージェントは 1 つで、上のどれにも当たらない。

並列や他の AI エージェントの記述がない開発の報告は、単一セッション型にしています。

軸 A の型のうち、tmux 並列型と司令塔型の違いは、主に 2 つの観点で説明できます。1 つは、作業文脈をどう分けるかです。独立したセッションを並べて同時に進めるかどうかで、隔離と並列の問いにあたります。もう 1 つは、分解、委譲、統合の責任を誰が持つかです。AI エージェント自身が統合の責任を持つのが司令塔型、ユーザが各セッションを束ねて統合するのが tmux 並列型です。この 2 つの本質的な違いは、並列かどうかではなく、統合の責任の持ち主にあります。2 つは別の観点なので排他的ではなく、複数のリポジトリを tmux で並べ、各リポジトリの中で司令塔型の AI エージェントが複数のサブエージェントを動かす、という組み合わせもあり得ます。ほかの型は、別の違いで決まります。クラウドへ渡す型は作業が動く場所、道具の使い分け型は使う道具の違いです。

調査事例に見られた構成の分布

件数は、開発の一次報告 24 件を、採用した分類規則に従って、軸 A の型ごとに数えたものです。軸 B と軸 C は別に数えるので、ここには入れていません。

図 4: 開発の組み立てについて、採用した一次報告の件数

• tmux 並列型: 7 件
• 道具の使い分け型: 5 件
• 司令塔型: 5 件
• 親エージェントと子ツール型: 4 件
• 単一セッション型: 3 件
• クラウドへ渡す型: 0 件。主たる作業をクラウドに渡している報告は、件数に入れた中にはありませんでした。

報告は、tmux 並列型の 7 件から単一セッション型の 3 件まで、型にまたがって分布しています。tmux 並列型が 7 件、道具の使い分け型と司令塔型が各 5 件、親エージェントと子ツール型が 4 件です。1 つの型に集中しているわけではありません。軸 B（仕事と私用の分離）は 7 件で、うち 1 件は、軸 A では道具の使い分け型です。

件数は、検索に引っかかった報告の数であって、世論調査ではありません。使われている割合ではなく、書かれやすさを映します。1 本のセッションで静かに使う人は、その使い方を「単一セッション」とは書かないので、単一セッション型は少なく出ます。軸 C も同じで、複数リポジトリ横断とリポジトリなしは、その値を狙って探した報告が大半です。単一リポジトリは、書いても話題になりにくい既定の使い方なので、少なく出ています。検索のヒット数は、1 つの投稿に複数のツール名が出て型が重なるため、件数には使っていません。

タスクセットの 3 つの場合

型の利点と欠点は、型だけでは決まりません。ユーザがどんなタスクの集まり（タスクセット）を抱えているかで、同じ特徴が利点にも欠点にもなります。そこで、タスクセットを 3 つの場合に分けて読みます。

• 1 つのタスク。ユーザが取り組むのは、1 つのプロジェクトの 1 つの仕事です。
• 複数のタスク・似た領域。タスクは複数ありますが、同じプロジェクトや近い分野で、読むコードや前提が重なります。
• 複数のタスク・違う領域。分野の違うタスクが並び、前提や用語が重なりません。

例として、次の単一セッション型を考えます。1 本のセッションに作業を集めると、文脈が混ざるのではないかと心配になります。1 つのタスクなら、その心配はありません。似た領域の複数のタスクなら、前の判断や読んだコードを次のタスクが使えるので、文脈の共有は利点になります。違う領域の複数のタスクなら、無関係な経緯が混ざって邪魔になり、欠点になります。以降の型の節では、利点、欠点、向くタスクセットを、この 3 つの場合で書きます。

単一セッション型

ユーザが直接話す AI エージェントは 1 つです。並列も、他の AI エージェントの呼び出しも、司令塔もありません。出力先は、リポジトリに限りません。何を相手にするかは、軸 C で別に見ます。

図 5: 単一セッション型

atware のエンジニアは、親ディレクトリから複数のリポジトリを見せる方法を試したうえで、作業対象のリポジトリから Claude Code を 1 つ起動する形に落ち着いた、と書いています（Zenn）。GA テクノロジーズのエンジニアも、複数のリポジトリを同じ階層に並べて、1 つのセッションから使っています（Zenn）。

利点と欠点

• 利点: 文脈が 1 本に集まるので、前の判断や読んだものを次の作業が使えます。構成が単純で、ユーザが見る場所も 1 つです。ユーザが直接話すので、何が正解かユーザにも分からない課題でも、途中で方向を直せます。OpenAI の実務ガイドは、まず単一の AI エージェントの能力を最大化し、複数にするのは指示が複雑すぎる場合などに限る、と勧めています（A practical guide to building agents）。
• 欠点: 作業を足すほど文脈が膨らみ、関係のない経緯が混ざります。進められる作業は同時に 1 つだけで、AI エージェントの待ち時間は、そのままユーザの待ち時間になります。
• 向くタスクセット: 1 つのタスクなら問題ありません。似た領域の複数のタスクでは、文脈の共有が効きます。違う領域の複数のタスクでは、文脈が混ざって不利です。

tmux 並列型

同じ役割のセッションが、同時に複数動きます。単位は tmux のペインや git worktree で、割り振りと進捗の確認はユーザです。Herdr のような管理ツールを使っていても、操作しているのがユーザなら、この型に入れます。

図 6: tmux 並列型

この型を決めるのは、セッションが並んでいることよりも、割り振りと統合の責任をユーザが持つことです。作業文脈を隔離して並列に進めることと、統合の責任を誰が持つかは、別の観点です。各セッションの内側で司令塔型の AI エージェントがサブエージェントを動かせば、tmux 並列型と司令塔型を組み合わせた形になります。

koki_n22 さんは、Claude Code や Codex を 2〜4 セッション、tmux で並列に動かしていた、と書いています。道具ごとの役割分担は書かれていないので、tmux 並列型に数えています。困っていたのは起動ではなく、どれが終わったか、どれが許可待ちかを見に行く手間で、そのあと Herdr に移っています（Zenn）。じょうさん（@joe_re）は、tmux で複数の Claude Code を起動する一人として、監視ソフトを公開しました（投稿）。su8 さん（@__su888）は、tmux と worktree で Claude Code を 6 並列し、外出先のスマホから使う構成を書いています（投稿）。

私の仕事側の使い方は、この型です。ただし束ねる管理ツールは使わず、進捗は私が見ます。各セッションは、リポジトリごとに独立したループです。ユーザである私が割り振りと確認を担います。Claude Code には、セッション同士が SendMessage などのメッセージで情報を渡し合う機能があります（Message your other Claude Code sessions）。AI エージェント同士が部分的にやり取りすることはあっても、大規模にメッセージを交換する使い方はしていません。

利点と欠点

• 利点: セッションごとに文脈が分かれるので、違う領域のタスクを混ぜずに同時に進められます。Claude Code の公式ドキュメントも、衝突を避けるために worktree で分ける方法を載せています（worktree を使用して並列セッションを実行する）。ユーザは各セッションの判断を直接見られ、セッション同士のやり取りも、ユーザが仲立ちするのが基本です。
• 欠点: 確認の速さが、ユーザの上限になります。Simon Willison さんは、最初は並列に懐疑的だった理由を、レビューが律速だから、と書いています（Embracing the parallel coding agent lifestyle）。koki_n22 さんが困っていたのも、同じ点でした。各セッションに確かめる手段がないと、未確認の出力が増えやすくなります。
• 向くタスクセット: 違う領域の複数のタスクに向きます。似た領域の複数のタスクでも、worktree で分ければ使えます。1 つのタスクでは、並べる理由が薄くなります。

道具の使い分け型

ユーザが、2 つ以上の異なる道具を同時に使い、どの道具が何を担うかを分けます。道具同士の受け渡しはユーザが行い、AI エージェントが他の AI エージェントを呼び出すことはありません。

図 7: 道具の使い分け型

分担のしかたは、報告ごとに違います。@_moto___ さんは、Cursor を日常の編集、Codex を長時間の自律作業、Claude Code をコードベースの理解が要る修正に使い分けています（投稿）。@mc99873 さんは、ファイル 1 枚の修正を Cursor、リポジトリ横断のリファクタを Claude Code に分けています（投稿）。

Dimitris Kiriakakis さんは、Claude Code と Codex と Cursor を毎日並べて動かしている、と書いています。許可の待ち行列も、ユーザが一つにまとめています（DEV Community）。この方は、会議の予定や請求は Grok Bot に任せてもいるので、軸 B にも入ります。

Qiita のコータローさんは、Claude Code をメイン、Codex CLI をサブにして並行運用しています。定型的で方針が固まった実装は、コータローさんが引き継ぎ資料を用意して Codex に渡します。Codex が積んだ結果は、Claude Code とコータローさんが 1 件ずつ確かめ、本番への適用と push の判断はコータローさんが行います（Qiita）。Codex を呼び出すのはコータローさん自身なので、この型に数えています。

利点と欠点

• 利点: 道具ごとの得意な作業を使い分けられ、一方の利用量を温存できます。受け渡しのたびにユーザが結果を見て方向を決められるので、正解が開いた課題にも使えます。
• 欠点: 受け渡しの負担が、ユーザに集まります。Kiriakakis さんが許可の待ち行列を一つにまとめているのも、その表れです。道具の間で文脈は引き継がれないので、渡すたびにユーザが前提を伝え直すことになります。
• 向くタスクセット: 1 つのタスクの中で、実装、レビューのように工程ごとに道具を替える場合に向きます。似た領域の複数のタスクでも使えます。違う領域のタスクを多く抱えると、受け渡しの回数が増え、負担が大きくなります。

親エージェントと子ツール型

ユーザが直接話す相手は、AI エージェントが 1 つです。その親が、別の AI エージェントや LLM をツールとして呼び出します。上に常駐の司令塔は置きません。

司令塔型との違いは、呼び出し方ではなく、子にどれだけの自律と責任を渡すかです。親エージェントと子ツール型では、境界のはっきりした部分処理だけを子に渡し、判断と統合は親が持ちます。仕組みだけでは型は決まりません。たとえば、Claude Code が Codex を MCP で呼ぶ構成は、調べ物のような部分処理を渡すだけなら、親エージェントと子ツール型です。独立した目標を持つ子タスクを渡し、結果の統合までさせるなら、同じ仕組みでも司令塔型になります。

図 8: 親エージェントと子ツール型

yujmatsu さんは、Claude Code を親、Codex を codex mcp-server 経由の子としてつなぐ手順を、実際に検証して書いています（Zenn）。その後、OpenAI 公式の Claude Code 向けプラグインも出ています（Qiita での紹介）。雑記.com の記事は、「量が多くて判断が軽い部分だけ、自宅の GPU に下請けさせたい」として、Claude Code や Codex から自宅のローカル LLM を MCP で呼んでいます（記事）。

手順を書いた記事は多い一方で、毎日の運用を書いた報告は、ユーザが仲立ちする使い分け型より少なめでした。

利点と欠点

• 利点: コピペの往復が減り、親の文脈を保ったまま、作業の一部を子に切り出せます。量が多く判断が軽い作業は、安い（または手元の）モデルに渡せます。Willison さんは、Claude Code のサブエージェントが、新しい文脈の別のループとして並列に動くことを、実行例で示しています（Claude Code sub-agents）。
• 欠点: 子は親の文脈を持たないので、よく定義された質問以上のことは任せにくくなります。Cognition の Walden Yan さんも、2025 年 6 月時点の Claude Code では、サブエージェントが並列には動かず、おもに質問への回答に使われている、と書いています（Don’t Build Multi-Agents）。
• 向くタスクセット: 親が 1 つの成果物の文脈を持つ、1 つのタスクに向きます。似た領域の複数のタスクでも使えます。違う領域のタスクを親に集めると、親の文脈が混ざります。正解が開いた課題では、子に渡す部分を、確かめられる作業に絞ります。

司令塔型

ユーザが直接話す相手は司令塔の AI エージェントです。他の AI エージェントへの割り振りは、ユーザではなく、その司令塔が行います。司令塔は Hermes や OpenClaw でも、マネージャー役の Claude Code でも同じ型にします。

この型を決めるのは、並列度の高さや呼び出し方ではなく、AI エージェントが分解、委譲、統合の責任を持つことです。司令塔は、それぞれ目標を持つ子タスクを渡して、部分成果を評価し、次の作業に使いながら、結果を統合します。子タスクどうしに依存があってもかまいません。たとえば、A の調査結果を受けて B に実装させ、C にレビューさせる、という順序を、司令塔が管理します。子に渡す自律と責任の大きさが、親エージェントと子ツール型との違いです。独立した作業文脈を並べるかどうかは別の観点で、司令塔型は tmux 並列型と組み合わせられます。

図 9: 司令塔型

Pyae Sone さんは、ユーザが話す相手を Hermes にし、実装は Claude Code または OpenCode に渡す構成を書いています。小さいローカルモデルは実装せず、意図を読んで受け渡し、報告する、と役割を分けています（DEV Community）。日本語では、マネージャー役の Claude Code が、開発者役のセッションへ tmux send-keys で指示を送る実験があります（株式会社 tolv のブログ）。dbd_fish さんは、PM 役のペインに指示を出すと、各ペインの Claude Code が並列に動く構成を書いています（Zenn）。

利点と欠点

• 利点: ユーザは司令塔とだけ話せば済み、割り振りを任せられます。メッセージ経路から手元のマシンを動かせることや、司令塔は小さいモデルで足り、実装だけ強いモデルに渡せることも、選ぶ理由として書かれています。広く調べる作業では、効果が数字に出ています。Anthropic は、Claude Opus 4 を司令塔、Claude Sonnet 4 をサブエージェントにした調査機能が、単体の Opus 4 を内部の調査評価で 90.2% 上回った、と報告しています（How we built our multi-agent research system）。
• 欠点: 同じ記事は、Anthropic の Research の構成で、トークンの使用量が通常のチャットの約 15 倍だったと報告しています。これはその構成での報告で、司令塔型一般の費用ではありません。Cognition の Walden Yan さんは、AI エージェントの行動には、書かれていない判断が乗るので、別々の AI エージェントが矛盾した判断をすると、あとで組み合わせてもうまくいかない、と指摘し、複数の AI エージェントを既定にしないよう勧めています（Don’t Build Multi-Agents）。複数の AI エージェントを組み合わせたシステムの失敗を、1,600 件超の実行記録から整理した研究も、失敗を、システム設計の不備、AI エージェント間の食い違い、タスク検証の不備の 3 類にまとめています（Why Do Multi-Agent LLM Systems Fail?）。また、司令塔は課題を委譲できる単位に分けて作業役に渡し、部分成果を評価して、次の作業に使い、統合します。そのため、タスクを委譲できる単位に分解でき、その部分成果を司令塔が評価して次に使えることが前提です。評価の基準は、出典の照合のような暫定的なものでも、探索は進められます。ただ、評価の基準を置けない課題や、分け方そのものが決まらない課題では、統合の責任をユーザが持つほうが確実です。
• 向くタスクセット: 1 つの大きなタスクを、委譲できる単位に分け、その部分成果を司令塔が評価して次の作業に使える場合に向きます。子タスクどうしに依存があっても、司令塔が順に管理できます。似た領域の複数のタスクでも使えます。Anthropic は同じ記事で、ほとんどのコーディング作業は、調査より並列化できる部分が少ない、とも書いています。正解が開いた課題でも、部分成果を確かめて次の探索に使えるなら、司令塔型は使えます（上の Anthropic の調査機能）。評価の基準は暫定的でかまいません。部分成果を確かめて次に使えない課題や、委譲できる単位に分けられない課題や、1 つの成果物を書く作業は向きにくく、そうした課題では、ユーザが外側のループで方向を決め、統合の責任を持ちます（「閉じていない問題と二重のループ」を参照）。違う領域のタスクを 1 つの司令塔に集めると文脈が混ざるので、tmux 並列型でセッションを分け、各セッションの内側で司令塔型を使う形が合うと私は見ています。

クラウドへ渡す型

主たる作業は、手元ではなく、クラウド上の AI エージェントのセッションで進みます。ノートを閉じても続き、結果があとから戻ります。

図 10: クラウドへ渡す型

主たる作業をクラウドに渡している報告は、件数に入れた中にはありませんでした。手元と併用する使い方は、ループの設計を調べる過程で見つかっています。Boris Cherny さんは、手元の端末で Claude Code を 5 本動かしながら、claude.ai/code でも 5〜10 本を並列に走らせ、手元のセッションを Web に移すこともある、と書いています（スレッドの最初の投稿）。Simon Willison さんは、Claude Code と Codex CLI に加えて、スマホから起動する非同期の作業に Codex Cloud を使っています（記事）。どちらも、手元の端末と並べてクラウドを使う報告です。この型の条件は、主たる作業がクラウドで進むことなので、この 2 人の発言は件数に入れていません。

利点と欠点

• 利点: 手元を空けられ、ノートを閉じても作業が続きます。Devin の公式説明は、長いリファクタ、ブラウザ操作、CI のように、手元では回しにくい作業を渡す使い方を挙げています（Devin の公式説明）。
• 欠点: 結果は終わってから戻るので、途中で方向を直しにくくなります。
• 向くタスクセット: 手元から切り離せる、独立した作業に向きます。1 つのタスクの中の重い工程にも、違う領域の複数のタスクのうち 1 つを渡す使い方にも合います。ユーザが方向を何度も決め直すタスクは、結果が終わってから戻るので向きません。正解が開いた課題でも、部分的な成果を確かめて次に使える作業なら渡せます。

仕事と私用の切り分け（軸 B）

軸 B は、開発の組み立てとは別の軸で、軸 A のどの型とも重なります。仕事（開発や、経緯を長く持たせたい業務）と、私用（メール、予定、健康、日常）で、相手の AI エージェントを分けている報告を数えました。

図 11: 仕事と私用の切り分け。開発の組み立てとは別に数える

この軸の一次報告は 7 件でした。日常や秘書役を Muse に分ける報告が 5 件（@Tech_Pochi さん、@x_ikachan さん、@oboroge9 さん、@s2vsuc さん、まさおさん）あります。Grok Bot の役は、仕事の経緯やルールを持たせる相手（@Tech_Pochi さん）、専門分野の相談役（@x_ikachan さん）、試したいものを投げる先（@oboroge9 さん）と、報告ごとに少しずつ違います。Kiriakakis さんは、会議の予定や請求を Grok Bot に任せていて、日常を Muse に寄せる分け方には当てはまりません。

@Tech_Pochi さんは、「日常のスケジュール管理や簡単な調査は Muse、長期で専門の経緯やルールを持たせたい仕事は Grok Bot のような使い分けにしています」と書いています（投稿）。@s2vsuc さんは、Grok Bot の使いすぎが気になり、健康管理を Muse に移した、と書いています（投稿）。

私の私用側も、この軸に入ります。メールや予定など、仕事と関連の薄い作業は Muse と Grok Bot です。

仕事か私用かで数えましたが、7 件の分け方を読むと、相手を分ける理由として効いているのは、仕事か私用かそのものより、継続的に管理する成果物（リポジトリなど）があるかどうかだと、私は読んでいます。私用でも、趣味のプログラミングならリポジトリが要ります。仕事の相談でも、成果物を持たないやり取りには、図 14 の「アシスタント」にあたる使い方が合うことがあります。

利点と欠点

• 利点: 経緯やルールを長く持たせたい仕事と、日常の用事が混ざりません。用途に合った相手を選べます。
• 欠点: 相手が増え、どちらに頼むかをユーザが決める手間が生じます。仕事と私用の境にある作業は、置き場に迷います。
• 向くタスクセット: 仕事と私用は領域が違うので、違う領域のタスクを、相手を分けて持つ方法そのものです。

1 本のセッションの相手（軸 C）

軸 C は、1 本のセッションが何を相手にするかです。ここまでの型は、1 本のセッションが 1 つのリポジトリを相手にする、と読めてしまいます。実際には、ユーザが親ディレクトリや /add-dir で、複数のリポジトリを 1 本のセッションに見せることがあります。調査、文書、メールのように、リポジトリが相手ではない仕事もあります。値は、単一リポジトリ、複数リポジトリ横断、リポジトリなしの 3 つです。

図 12: 1 本のセッションの相手（軸 C）。ユーザが頼む相手の AI エージェントが、リポジトリ 1 つか、複数か、リポジトリではない作業か

件数は、単一リポジトリが 5 件、複数リポジトリ横断が 14 件、リポジトリなしが 20 件、本文から読み取れなかったものが 15 件で、合計 54 件です（件数の読み方は「調査事例に見られた構成の分布」の末尾を参照）。リポジトリなしのうち 5 件は、軸 B の報告から値を付けた、Muse や Grok Bot の使い方です。

複数リポジトリ横断では、GA テクノロジーズのエンジニアが、5 つのプロダクトを同じディレクトリに並べ、Claude Code の 1 セッションから横断して使っている、と書いています（Zenn）。@820zacky さんは、複数のリポジトリを含むワークスペースで、Claude Code に障害の調査をさせています（投稿）。@VLeavitskiy さんは、/add-dir でフロントとバックの両方のリポジトリを同時に扱えると気づいた、と書いています（投稿）。

リポジトリなしでは、@osamu_aranami さんが、経営者として Claude Code を 2 週間使い、市場調査、補助金の調査、議事録の構造化に役立てた、と書いています（投稿）。Obsidian の Vault のフォルダで Claude Code を動かして、調査から執筆まで進める報告も、複数あります（たとえば gyoii さんの note）。

開発ではない使い方は、軸 A の件数に入れていません。調査や執筆の相手として AI エージェントを 1 本だけ使う人は多いのですが、その使い方を「単一セッション」とは呼ばず、「調査」や「ノート」の話として書きます。

利点と欠点

• 利点: 単一リポジトリでは、文脈が絞られ、変更の範囲も読みやすくなります。複数リポジトリ横断では、変更の影響を 1 本で見渡せます。リポジトリなしでは、調査や文書のような仕事にも使えます。
• 欠点: 複数リポジトリ横断は、見せる範囲が広がるぶん、文脈が散ります。リポジトリなしの仕事は、テストのような確かめる手段を作りにくく、成否の判断がユーザに戻ります。
• 向くタスクセット: 1 つのタスクと似た領域の複数のタスクは、単一リポジトリか横断で足ります。違う領域の複数のタスクは、相手ごとにセッションを分けるほうが、文脈が混ざりません。

ループの設計と任せる範囲

型を問わず、使い勝手を左右するのは、各ループの中で成否を確かめられるかどうかです。

使いこなしている人の共通点

うまく使っている人に共通しているのは、AI エージェントを何本並べるかより、一つ一つのループの中で、AI エージェントが成否を確かめられるようにしている点です。

• Boris Cherny さん（Claude Code の作者）は、手元の端末で Claude Code を 5 本、claude.ai/code でも 5〜10 本を並列に走らせています。ほとんどのセッションを計画モードで始め、計画が固まるまで往復します。いちばんの助言は、Claude Code に、担当した作業の成否を確かめる手段を渡すことで、その確かめるループがあると最終結果の質が 2〜3 倍になる、という趣旨を書いています（スレッドの最初の投稿）。
• Andrej Karpathy さんは、何をするかを指示するより、成功の基準を渡し、テストを先に書かせて通るまでやらせるとよい、という趣旨を書いています。一方で、AI エージェントの群れ（swarm）への期待は、今のところ盛りすぎだ、とも言っています（投稿）。
• Mitchell Hashimoto さんは、AI エージェントを 1 つだけ動かしています。失敗のたびに AGENTS.md やテスト用のスクリプトを足し、同じ失敗を繰り返させないようにしています（My AI Adoption Journey）。
• 反対の極端が、Steve Yegge さんの Gas Town です。Claude Code を 20〜30 束ね、作業の割り振りまで仕組みにしています。この記事の型に当てはめると司令塔型です（Welcome to Gas Town）。

並列は、ユーザが複数のループを同時に見るための手段です。効き目の本体は、各ループの中で AI エージェントが成否を確かめられる設計にあります。ただ、公開された短い投稿では、何本並べたかは見えやすく、AI エージェントにどんな確かめ方を渡したかは見えにくくなります。

ループを回す Claude Code の仕組み

Claude Code には、このループをユーザの代わりに回し続ける仕組みがいくつかあります。

• /goal: ユーザが「test/auth のテストが全部通り、lint もきれい」のような完了条件を書きます。AI エージェントが 1 ターン終えるたびに、別の小さなモデルが、条件を「満たした」「まだ」「満たせない」のどれかで判定します。この判定のモデルは、コマンドを実行せず、ファイルも読まず、会話に残った情報だけから判定します。「まだ」なら、ユーザが何も言わなくても次のターンに進みます。中身は、ターンの終わりに呼ばれる Stop フックを包んだものです（公式）。
• Ralph Loop: Geoffrey Huntley さんが、いちばん単純な形は Bash のループだ、と説明して広めた技法で、いまは Anthropic verified のプラグインとして Claude のマーケットプレイスに載っています。AI エージェントが終わろうとするたびに、Stop フックが止めて同じプロンプトを渡し直します。完了の合言葉が出るか、--max-iterations の上限に達するまで続きます（Huntley さんの解説、プラグイン）。
• /loop: 決まった間隔で次のターンを始めます。デプロイや CI の完了を待つような見張り向けです（公式）。待つのが /loop、働かせるのが /goal という使い分けになります。
• /verify: テストや型チェックで済ませず、AI エージェントがアプリをビルドして動かし、結果を見て確かめるスキルです（公式）。ループの中の「確かめる」を強くします。

/goal と Ralph Loop の違いは、完了を誰が判定するかです。Ralph Loop では、作業している AI エージェント自身が「終わった」と宣言します。/goal では、作業している AI エージェントとは別のモデルが判定します。ただし、「別のモデルが判定する」ことと、「成果物が独立に検証される」ことは違います。/goal の判定は、AI エージェントが会話に出した内容の確認で、成果物そのものを別の手段で確かめるわけではありません。たとえば「テストが全部通る」は、AI エージェントがテストを実行して結果を会話に出すから判定できます。独立した検証が要るなら、テストや CI、/verify のように、成果物を実際に動かして確かめる手段を、完了条件に組み込みます。

このほか、/autofix-pr は、クラウドのセッションが PR を見張り、CI の失敗やレビューのコメントのたびに直して push します。/batch は、大きな変更を 5〜30 の独立した単位に分け、単位ごとに worktree とサブエージェントを立てます。こちらは司令塔型に近い形です（コマンド一覧）。

「できるまでやれ」という指示の限界

「できるまでやれ」とプロンプトに書けば、それで十分ではないか。そう思う人もいるはずです。半分は、その通りです。「〜ができるまで実施して。問題があれば、フィードバックのループを回して直して。最大 5 回まで」と書くだけでも、ループは回ります。ただ、差が出る所が 2 つあります。

1 つ目は、何をもって成功とするかです。「できるまで」とだけ書くと、できたかどうかの判断が AI エージェントの感覚任せになり、まだなのに「できました」と言って止まることがあります。そこで、ユーザが先に、機械で白黒がつく条件と、それを確かめる手段を用意します。テストが全部通る、画面を開くと期待どおりに動く、数値が基準以上になる、といった条件です。この確かめる手段を課題ごとに作ることが、手間のかかる本体です。

2 つ目は、誰がループを止めるかです。プロンプトに「最大 5 回」と書いても、守るかどうかは AI エージェントの自己申告に任されます。途中で勝手に終わることも、回数を数え間違えることもあります。Stop フックを使う Ralph Loop は、AI エージェントの外から、終わろうとするのを止めて戻し、上限の回数もフック側で数えます。

閉じていない問題と二重のループ

ここまでは、成果を機械で判定できる課題の話でした。ただ、機械で確かめられることと、探索空間が閉じていることは別です。探索空間が開いていて、ユーザにも何が正解か分からない課題でも、テストや型検査のように、部分的な検証を自動化できることはあります。区別すべきなのは、最終的な正解が事前に分かるかではなく、部分的な成果を確かめて、次の探索に使えるかです。最終判断まで人抜きで閉じられるかは、別の問題です。逆に、探索空間が狭くても、文章の読みやすさや画面の使い心地のように、評価に人間の主観が要ることがあります。実際には、ユーザにも何が正解か分からない課題が多くあります。Cherny さんは、ほとんどのセッションを計画モードで始め、計画が固まるまで AI エージェントと往復します。Karpathy さんは、大事なコードを横の IDE で見て、Karpathy さん自身の手でも直します。どちらも、正解が開いている部分を自動のループに任せていない例だと読めます。

もう一つは、粒度です。大きな最終ゴールをそのまま一つの成功条件にすると、判定があいまいになり、途中で道を外れても気づけません。Anthropic も、作業を決まった段に分けて、段のあいだに確認の関門を置くやり方（プロンプトの連鎖）を、AI エージェントに丸投げする前に試す型として挙げています（Building effective agents）。

そこで、私は次のように整理しています。ユーザが大きなゴールを段に分け、各段の到達点を、確かめられる形で書きます。AI エージェントは、その段の中だけでループを回します。段と段のあいだで、方向が合っているかをユーザが判断します。ユーザが回す外側のループと、AI エージェントが回す内側のループの、二重のループです。これは私の推論です。開かれた問題での回し方を書いた報告は少なく、文献から直接言えることではありません。

図 13: 二重のループ。外側はユーザが方向を判断し、内側は AI エージェントが段の中で繰り返す

ユーザがループの内側に引き込まれる失敗

よくある失敗は、外側で判断すべきユーザが、AI エージェントの試行錯誤の内側に引き込まれ、細かいことのたびに答えさせられる状態です。原因は 3 つあると私は考えています。

• 段の完了条件が、確かめられる形で書かれていません。AI エージェントは「これで合っていますか」とユーザに聞くしかなくなります。
• AI エージェントが単独で決めてよい範囲が、決まっていません。命名やライブラリの選び方まで、毎回聞かれます。
• AI エージェントが、コマンドを走らせるたびにユーザへ許可を求めます。内側のループが、毎回ユーザを通ります。

対策は、それぞれの裏返しです。段ごとに完了条件を渡します。CLAUDE.md や AGENTS.md に「この範囲は聞かずに決めてよい。聞くのは方針が変わるときだけ」と書いておきます。安全なコマンドは許可リストに入れます。私のような tmux の並列は、この切り分けができて初めて成り立ちます。内側のループから毎回呼ばれると、5 本どころか 2 本でも、ユーザが追いつきません。

任せる範囲の線引き

どこまで AI エージェントに任せるか。私は、成否を確かめる手段がある範囲までは AI エージェントに渡し、方向を決める判断はユーザに残す、と考えています。線を引く基準は 3 つです。

• 確かめられるか。テストやベンチ、画面の確認で白黒がつく作業は、AI エージェントに任せます。確かめる手段を作れない作業は、ユーザが判断します。
• 戻せるか。worktree やブランチの中の変更は任せます。本番への反映、データの削除、外への送信、費用のかかる計算資源の確保は、ユーザが判断します。
• 方向が変わる判断か。実装の細部、命名、ライブラリの選択、エラーの直し方は任せます。問いの立て方、どの仮説を追うか、どこで打ち切るかは、ユーザに残します。

この線は、一度決めて終わりではありません。確かめる手段が増えるたびに、外へ広げていくものです。Hashimoto さんが失敗のたびにテストと AGENTS.md を足しているのは、この線を押し広げる作業だと読めます。

Yes/No で選ぶ構成のチートシート

ユーザのタスクに合う構成は、次の 6 つの問いに Yes か No で答えると見つかります。最初に、継続的に管理する成果物があるかを聞きます。そのあとで、独立した作業文脈を同時に進めたいか（隔離と並列）と、委譲できる単位に分け、部分成果を評価して次に使えるか（統合の責任を AI エージェントに任せられるか）を、別の問いとして聞きます。この 2 つは別の観点なので、答えによっては、tmux で並べたセッションの中で司令塔型を使う組み合わせになります。問い 4 は、tmux でセッションを分けた場合は各セッションの中で、分けない場合は 1 つの文脈の中で聞きます。問い 5 は、セッションを分けない場合だけ聞きます。分けた場合は、各セッションの中で使える使い方として、図の注記で示しています。

図 14: Yes/No で選ぶ構成のチートシート（私の整理）

図の行き先は、本文の型の名前と同じです。AI エージェントが全体を割り振るなら司令塔型（問い 4）、一部だけを子の AI エージェントに渡すなら親エージェントと子ツール型（問い 5）です。「アシスタント」は、軸 A の型ではなく、成果物を持たない用事を頼む使い方で、仕事と私用の切り分け（軸 B）の行き先にあたります。

問い 1: 継続的に管理する成果物

• 意味: ユーザが、作っては直し続けるものを持っているかを聞いています。リポジトリのコードや、調査ノート、原稿の文書が、これにあたります。
• Yes の例: 仕事の開発のリポジトリ。趣味のプログラミングのリポジトリ。Obsidian の Vault のフォルダで、調査から執筆まで進めるノート。
• No の例: メールの返信、予定の調整、日常の調べ物のように、1 回頼めば終わる用事。

問い 2: 独立した作業文脈を同時に進めたいか

• 意味: 作業文脈は、AI エージェントとのひと続きの会話が覚えている前提や経緯のことです。互いに前提を共有しない作業を、別々の会話として同時に走らせたいかを聞いています。
• Yes の例: 私のように、リポジトリごとに別のタスクがあり、リポジトリごとに tmux の Claude Code を 1 つ割り当てる場合。koki_n22 さんのように、Claude Code や Codex を 2〜4 セッション並べる場合。
• No の例: 1 つのプロジェクトの 1 つの仕事を、順に進める場合。似た領域のタスクで、前の判断を次の作業が使いたい場合。

問い 3: 独立した作業をクラウドに任せたいか

• 意味: ユーザの手元を空けて、独立した作業を、クラウド上の AI エージェントに渡して進めたいかを聞いています。ノートを閉じても作業が続き、結果があとから戻ります。
• Yes の例: 長いリファクタ、ブラウザ操作、CI のように、手元では回しにくい作業。
• No の例: ユーザが結果を見ながら、方向を何度も決め直す作業。

問い 4: 委譲できる単位に分け、部分成果を評価して次に使えるか

• 意味: 2 つのことを同時に聞いています。1 つは、タスクを、別の担当に委譲できる単位に分けられるかです。子タスクどうしに依存があってもかまいません。たとえば、A の調査結果を受けて B に実装させ、C にレビューさせる、という順序は、司令塔の AI エージェントが管理できます。もう 1 つは、その部分成果を、司令塔の AI エージェントが評価して、次の作業に使えるかです。評価の基準は、テストのように確定したものでなくてもかまいません。出典の照合のような暫定的な基準でも、探索は進められます。最終的な正解が事前に分かっている必要もありません。Anthropic の Research のように、開いた調査でも、サブエージェントの結果を司令塔が見て、次の調べ方を決められます。両方が Yes なら、分解と統合を AI エージェントに任せられるので、司令塔型です。どちらかが No なら、ユーザが束ねます。ただし、最終判断まで人抜きで閉じられるかは別の問題で、方針や打ち切りの判断は、ユーザに残ります。問い 5 との違いは、任せる範囲です。問い 4 は全体の分解と統合を司令塔に任せられるかを聞き、問い 5 は、全体はユーザと親が持ったまま、一部だけを切り出して子に渡せるかを聞きます。tmux でセッションを分けた場合は、各セッションの中について、同じ問いを聞きます。そのときも、セッションどうしの統合は、ユーザが持ちます。
• Yes の例: 「test/auth のテストが全部通る」のように、テストで部分成果を確かめられる変更を、委譲できる単位に分けて進める場合。大きな変更を 5〜30 の独立した単位に分け、単位ごとにサブエージェントを立てる /batch の使い方。A の調査結果を受けて B に実装させ、C にレビューさせる、という順序を司令塔が管理する場合。広く調べる作業を、サブエージェントに分け、出典の照合のような暫定的な基準で結果を確かめながら進める場合。
• No の例: 文章の読みやすさや画面の使い心地のように、評価の基準を置けず、人が見て決める判断が中心の作業。1 つの成果物を書く作業。依存が強く、分け方そのものが決まらない設計変更。部分成果を確かめる手段がなく、次の作業に使えない課題。

問い 5: 調べ物や検証など、一部だけ切り出して渡せるか

• 意味: 問い 4 で全体は任せられないと分かったあとに、全体のうち一部だけを切り出して、子の AI エージェントに渡せるかを聞いています。渡すのは、量が多くて判断が軽い作業や、よく定義された質問です。ユーザが直接話す相手は、親の AI エージェント 1 つのままで、子への受け渡しは親が行います。正解が開いた課題でも、渡す部分を、確かめられる作業に絞れば使えます。
• Yes の例: コードベースの中から該当の箇所を探す調べ物や、ライブラリの仕様の調査を、子に渡して、要約だけを親の文脈に戻す場合。テストの実行結果やログの確認のような検証を、子に渡す場合。
• No の例: 設計の方針や、どの仮説を追うかの判断のように、切り出すと文脈が欠ける作業。渡す部分に何が正解か決まっていない作業。

問い 6: 工程ごとに道具を替えたいか

• 意味: 1 つの作業の中で、実装、レビューのように工程が分かれ、工程ごとに別の道具（Claude Code、Codex など）を使いたいかを聞いています。受け渡しはユーザが行います。
• Yes の例: コータローさんのように、Claude Code をメインにして、実装を Codex に渡し、レビューと本番への適用は Claude Code とユーザが行う場合。@_moto___ さんのように、日常の編集は Cursor、長時間の自律作業は Codex、深い修正は Claude Code に分ける場合。
• No の例: 1 つの道具で足りる場合。受け渡しの手間を増やしたくない場合。

おすすめの型の具体像

• アシスタント: メールや予定の整理、日常の調べ物のように、成果物を持たない用事を頼む使い方です。
• クラウドへ渡す型: 長いリファクタや CI のような独立した作業を、ノートを閉じたあとも進めたい使い方です。
• 司令塔型: テストなどで出来を判定できる大きな変更を、独立した単位に分け、結果の統合まで AI エージェントに任せる使い方です。
• 親エージェントと子ツール型: 1 つの AI エージェントと直接話し、その AI エージェントが、量が多くて判断が軽い作業や、よく定義された質問だけを、子の AI エージェントや LLM に渡す使い方です。
• tmux 並列型 ＋ 各セッション内で司令塔型: リポジトリごとにセッションを分け、各リポジトリの中では、AI エージェントに分解と統合を任せる使い方です。
• tmux 並列型: 私のように、リポジトリごとにセッションを分け、各セッションの進捗と統合を、ユーザである私が見る使い方です。
• 道具の使い分け型: 日常の編集は Cursor、長時間の自律作業は Codex のように、作業の種類や工程ごとに道具を替え、受け渡しをユーザが担う使い方です。
• 単一セッション型: 1 つのプロジェクトを、1 つの AI エージェントと直接やり取りしながら進める使い方です。

型ごとの利点と欠点の比較

次の表は、各型の「利点と欠点」の節に書いた内容を、私が○△×で整理したものです。○ は向く・有利、△ は条件次第、× は向かない・不利を表します。表の行は型ごとの特徴で分けたもので、司令塔型と tmux 並列型は組み合わせられます。「正解が開いた課題への適合性」の列では、正解が未知であることと、部分的な検証ができることは両立する、と考えて読みます。○ は、正解が未知でも進めやすい型です。△ は、部分成果を確かめて、次に使えることが条件の型です。× は向かない型です。最終判断まで人抜きで閉じられるかは、別の問題です。同じ「正解が開いた課題」でも、単一セッション型は、ユーザが 1 本の AI エージェントと直接話して方向をその場で直せるので ○、tmux 並列型は、ユーザの注意が複数のセッションに分散し、各セッションへの方向づけが薄くなりやすいので △ としています。

型	1 つのタスク	似た領域の複数のタスク	違う領域の複数のタスク	ユーザの負担の軽さ	同時に進む作業の量	正解が開いた課題への適合性
単一セッション型	○	○	×	○	×	○
tmux 並列型	×	△	○	×	○	△
道具の使い分け型	○	○	×	×	△	○
親エージェントと子ツール型	○	○	×	○	△	△
司令塔型	△	△	×	○	○	△
クラウドへ渡す型	△	△	○	△	△	△

行を横に読むと、単一セッション型と親エージェントと子ツール型は似た領域までのタスクセットに、tmux 並列型は違う領域に向きます。司令塔型とクラウドへ渡す型は、正解が開いた課題への適合性は △ です。条件は、部分成果を確かめて、次に使えることです。司令塔型は、負担の軽さと同時に進む量が ○ である代わりに、タスクを委譲できる単位に分解でき、その部分成果を司令塔が評価して次に使えることが前提です。費用も増えやすく、Anthropic の Research の構成では、トークンの使用量が通常のチャットの約 15 倍という報告があります。

私の位置

私の使い方を型に当てはめると、仕事の開発は軸 A の tmux 並列型、私用は軸 B の仕事と私用の分離です。親が子を呼ぶ形、司令塔、クラウドへ渡す形は使っていません。軸 C では、仕事が単一リポジトリ、Muse と Grok Bot に任せる私用がリポジトリなしです。

タスクセットで見ると、私の仕事は、リポジトリごとに別のタスクが並ぶ形です。タスクごとに文脈を分けられる tmux 並列型が合うのは、このためです。2 つの観点で言い直すと、私は、作業文脈をリポジトリごとに隔離して並列に進め、統合の責任はユーザが持っています。各セッションの内側で AI エージェントに統合を任せる司令塔型は、組み合わせとして使えます。

ループの言葉では、ユーザである私が、独立したループを複数並べて見ています。ループごとにリポジトリが違うので文脈は混ざらず、AI エージェント同士のメッセージのやり取りは部分的で、大規模ではないので、伝言のあいだに判断が食い違うことも起きにくくなります。一方で、確かめる負担は私一人に集まります。各ループの中で AI エージェントが成否を確かめられるよう、完了条件と任せる範囲を先に決めておくことが、並列を成り立たせる条件だと考えています。

調べて分かったのは、組み合わせの単位が「どのモデルが強いか」より、「どの作業を、どの AI エージェントに振るか」に移っていることです。並列の本音は、起動ではなく状態の把握です。仕事か私用かで数えた軸 B で効いていたのは、継続的に管理する成果物の有無だったと、私は読んでいます。

まとめ

• 私は、仕事をリポジトリごとの tmux の Claude Code で並列し、進捗は私が見ます。私用は Muse と Grok Bot です。1 本のセッションの相手は、仕事が単一リポジトリ、私用がリポジトリなしです。
• 開発の組み立て（軸 A）の一次報告は、tmux 並列が 7 件、道具の使い分けと司令塔型が各 5 件、親エージェントと子ツール型が 4 件、単一セッション型が 3 件と、複数の型に分布していました。仕事と私用の切り分け（軸 B）と、1 本のセッションの相手（軸 C）は、別の軸として数えました。軸 B は仕事か私用かで数えましたが、相手を分ける理由として効いていたのは、継続的に管理する成果物の有無だったと、私は読んでいます。軸 C では、複数リポジトリ横断やリポジトリなしの使い方にも報告がありました。
• 型の利点と欠点は、ユーザのタスクセットと、委譲できる単位に分け部分成果を評価して次に使えるかどうかで決まります。文脈を共有して得をする型（単一セッション型など）と、文脈を分けて得をする型（tmux 並列型など）があります。作業文脈の隔離と並列、統合の責任の持ち主は別の観点で、司令塔型と tmux 並列型は組み合わせられます。
• 図 14 のチートシートの価値は、製品の比較ではなく、仕事の構造から AI エージェントの構成を逆算できることにあります。
• 使いこなしている人に共通するのは、並列の本数より、各ループの中で AI エージェントが成否を確かめられる設計でした。並列は、ユーザが複数のループを見るための手段です。
• 任せる範囲は、確かめられるか、戻せるか、方向が変わらないか、の 3 つで線を引きます。ユーザが段を切って外側で判断し、AI エージェントが段の中で回す二重のループとして整理しました。