メインコンテンツへ移動
AIチュートリアル

Solo to Team チュートリアル：協働スキルパックを導入し、1人で複数のAIアシスタントを統括する

このチュートリアルでは、Solo to Team スキルパックの導入方法、4つの中核スキルを解説します。さらに、1つの小さなタスクを通して「派遣、引き受け、回収、検証、判断」という協働の流れを実践し、複数ホストの設定、自動化の限界、応用方法についても説明します。

約21分で読了
Solo to Team チュートリアル：協働スキルパックを導入し、複数のAIを1人で統括

プロジェクト概要

Solo to Team · 一人でチームを作る、リポジトリ名 solo-to-team-skills は、「一人が全体を管理し、複数の長期運用 AI アシスタントを使う」場面を想定した中国語協働スキルパッケージです。AI を自動的にチーム編成するものではなく、タスクを依頼し、進捗を確認し、証拠を照合したうえで、人が最終判断を下すための再現可能な方法を提供します。

現在のプロジェクト状態は v0.9-draft で、今後も変更されます。Codex、WorkBuddy、DeepSeek Harness、Cursor、CodeBuddy、Kimi Work、千問辦公などのホストで、限定的な実運用検証を完了しています。Grok Bot は手動設定が必要です。Claude Code についてはプラグイン構造を準備済みですが、初回リリースのサポートにはまだ含まれていません。

「サポート」とは、指定されたインストール方法と呼び出し方法が実際に通った記録があることを意味します。すべてのタスクを安定して完了できることや、4つのスキルすべてが各ホストで個別に検証済みであることを意味しません。

このプロジェクトが解決する問題

複数の AI アシスタントが協働する際、本当に制御不能になりやすいのは、モデルの能力ではなくプロセスです。タスクを出した後に誰も確認しない、実行者が「完了した」と言っても証拠がない、検収と成果物の受領を混同する、あるいは操作説明が作成者にしか理解できない、といった問題が起こります。

Solo to Team は、協働プロセスを次の一本の流れに整理します。

目標提示 → 分担 → 引き継ぎ → 照合 → 判断

  • 目標提示：何をするのか、成果物をどこに置くのか、いつ納品するのか、何をもって完了とするのかを明確にします。
  • 分担：依頼する前に「受領待ち」を登録し、実行者、受領者、期限時の確認担当者を明記します。
  • 引き継ぎ：「受注済み」と「成果物受領済み」を分けて記録し、メッセージを受け取っただけで完了とみなすことを防ぎます。
  • 照合：現在のバージョンに対応する有効な証拠を確認します。変更された部分や失敗した部分は、必ず再検証します。
  • 判断：承認するか、差し戻すか、方針を変更するかを人が決定します。

4つのコアスキル

dispatch-accept-verify

表示名は「依頼した仕事を受け取る」で、分担と引き継ぎを担当します。タスクを依頼する前に「受領待ち」を登録し、受注、成果物の受領、検収完了を分けて記録します。検収を完了するか、承認を得て取り消すまで、タスクを未完了一覧から削除してはなりません。

evidence-before-done

表示名は「仕事を渡す前に証拠を揃える」で、照合を担当します。完了という結論は、現在のバージョンに対応する証拠に基づく必要があります。たとえば成果物を開いて確認する、再計算する、コマンドを実行する、元の手順をもう一度実行する、といった方法があります。

beginner-ops-writing

表示名は「初心者向け操作説明」で、背景を知らない人でも実行できる手順を作成するために使います。主な原則は、1回に1ステップだけ書くこと、対象を一意に指定すること、完了後に何が表示されるべきかを説明することです。ログイン、支払い、削除、正式な送信など、本人が実行すべき操作は「本人が行ってください」とだけ書き、代行方法を設計してはいけません。

ops-case-notes

表示名は「匿名化運用記録」で、実際の運用から得た匿名化済みの2つの事例を収録しています。実際の問題、改善方法、結果、未解決の制限事項を記録しており、プロセスに不備が見つかった際の振り返りに使えます。

開始前の準備

まずリポジトリをダウンロードまたはクローンし、ローカルに skills/ ディレクトリが存在することを確認します。このディレクトリには4つのスキルサブディレクトリがあり、それぞれに SKILL.md が含まれている必要があります。

git clone YOUR_REPOSITORY_URL
cd solo-to-team-skills

クローン先の URL は、プロジェクトが正式公開された後の実際のリポジトリ URL に置き換えてください。圧縮ファイルをダウンロードして入手した場合は、直接展開して使用することもできます。

インストール時は、以下の原則に従ってください。

  • skills/スキル名/ ディレクトリ全体をコピーし、SKILL.md だけをコピーしないでください。
  • dispatch-accept-verify はディレクトリ内のテンプレートにも依存します。本文だけをコピーすると、登録行テンプレートが失われます。
  • dispatch-accept-verify と evidence-before-done は同時にインストールすることを推奨します。
  • evidence-before-done は単独でも使用できます。
  • beginner-ops-writing と ops-case-notes は任意の組み合わせであり、インストールしなくても主要な依頼・受領フローには影響しません。

ホストを選択してインストール

Codex

Codex で検証済みの方法では、リポジトリに付属する .agents/plugins/marketplace.json を使用します。まず Codex CLI をインストールしてログインし、プロジェクトのルートディレクトリで次を実行します。

cd /path/to/solo-to-team-skills
codex plugin marketplace add "$(pwd)"
codex plugin add solo-to-team-skills@solo-to-team-skills

コマンドがゼロ以外のステータスを返した場合は、.agents/plugins/marketplace.json を含むパッケージのルートディレクトリが現在のディレクトリかどうかを確認して停止してください。インストール後、新しいセッションを開始するか、codex exec でスキルを呼び出します。

codex exec -s workspace-write --skip-git-repo-check -C "$(pwd)" 'スキル dispatch-accept-verify を使用して、T044_dispatch_line.md に受領待ちの登録行を1行書いてください'

インストールを取り消すには、次を実行します。

codex plugin remove solo-to-team-skills@solo-to-team-skills
codex plugin marketplace remove solo-to-team-skills

Cursor

必要なスキルディレクトリ全体をユーザースキルディレクトリにコピーします。

mkdir -p ~/.cursor/skills/
cp -R skills/dispatch-accept-verify ~/.cursor/skills/
cp -R skills/evidence-before-done ~/.cursor/skills/

その後、Cursor Agent でスキル名を指定して呼び出します。cursor agent --print 形式の CLI も使用できます。新しいワークスペースで非対話実行する場合、ホストから --trust の使用を求められることがあります。この引数はワークスペースを信頼することを意味し、安全機構を無効にするものではありません。

WorkBuddy と CodeBuddy

この2つは名称が似ていますが、同じホストではないため、インストール先を混用できません。

  • WorkBuddy：~/.workbuddy/skills/ またはプロジェクト内の .workbuddy/skills/ にコピーします。SKILL.md を含むスキルディレクトリまたは zip を画面からアップロードすることもできます。
  • CodeBuddy：~/.codebuddy/skills/ またはプロジェクト内の .codebuddy/skills/ にコピーし、画面または CLI で名前を指定して呼び出します。

詳しくは、WorkBuddy Skills ドキュメント と CodeBuddy Skills ドキュメントを参照してください。

DeepSeek Harness

スキル全体をプロジェクトの .dsh/skills/、ユーザーディレクトリの ~/.dsh/skills/、または .agents/skills/ にコピーし、その後 Harness を再起動または更新します。プロジェクトでは、dsh plugin add はこれらのスキル本文をインストールする方法ではないことを明記しています。

使用前に DeepSeek アカウントまたは API を自分で用意する必要があります。本プロジェクトはキーを提供しません。詳しい仕組みは DeepSeek Harness Skills ドキュメントを参照してください。

Kimi Work

README で実際に検証したのは Kimi Work のデスクトップ版であり、Kimi Code CLI ではありません。macOS の検証環境では、スキルディレクトリは次の場所です。

~/Library/Application Support/kimi-desktop/daimon-share/daimon/skills/

コピー後、Kimi Work の画面で / を入力してスキルを選択します。このパスはコミュニティでの実践に基づくもので、公式には zip、Markdown、リンク、ストアからのインストール方法が提供される可能性もあります。現在の説明は Kimi Skills 公式ページを基準にしてください。

千問辦公 QwenWork

スキルディレクトリを次の場所にコピーします。

~/.qwenworkcn/skills/

その後、デスクトップ版で / を使ってスキルを選択するか、会話中で直接名前を指定します。千問辦公と通義霊碼は同じ製品ではないため、同じインストール先を使用してはいけません。詳しくは QwenWork Skills ドキュメントを参照してください。

Grok Bot

Grok Bot はローカルディレクトリへのインストールを使用しません。スキルの SKILL.md を開き、会話中で本文をプライベートスキルとして保存するよう依頼します。その際、ファイル先頭の name と description を使用してください。4つのスキルはそれぞれ個別に保存する必要があります。

dispatch-accept-verify を保存する際は、登録行テンプレートもプライベートスキルに貼り付ける必要があります。この方法はプライベートスキルを保存できる Grok Bot のみに適用され、他の Grok 製品でも同じ設定が使えることを意味しません。

Claude Code

リポジトリには .claude-plugin/plugin.json と marketplace 構造が用意されていますが、現在は「構造は準備済み、動作確認は未完了」の状態です。そのため、初回リリースのサポート対象とはみなせません。自分で試す場合は、Claude Code 公式プラグインドキュメントの最新のインストール方法に従ってください。

初回実行：小さなタスクから始める

最初から複雑なプロジェクトを複数のアシスタントに任せないでください。まずは、結果を簡単に確認できる小さなタスクを1つ選びます。たとえば、指定された入力から会議記録を整理するタスクです。プロジェクトには examples/ のメインサンプルと、完全な手順確認用資料 examples/walkthrough-meeting-notes/ があり、「入力の指定、成果物の生成、証拠の確認、人による検収、修正依頼」を練習できます。

ステップ1：目標を明確に書く

タスクの内容、成果物の場所、納期、完了基準をアシスタントに伝えます。プロンプトは次の構成にできます。

dispatch-accept-verify を使用して、このタスクを管理してください。
タスク：指定された入力から会議記録を整理する。
成果物の場所：指定されたワークスペースのファイル。
納期：合意した時間。
完了基準：内容が入力と一致し、必要な項目が揃っており、私が開いて確認できること。
まず「受領待ち」の登録行を1行作成してください。

ステップ2：「受領待ち」を登録する

依頼する前に登録行を作成し、少なくともタスクの状態、実行担当者、受領担当者、期限時の確認担当者、成果物の場所、納期を明確にします。リポジトリ内の templates/task-register-line.md を直接コピーすることを推奨します。完全なフィールドを自分で推測しないでください。

ステップ3：受注と成果物を分けて記録する

実行アシスタントがタスクの引き受けを確認した後、「受注済み」と記録します。成果ファイルが実際に返却された後に、「成果受領済み」と記録します。この2つの状態は統合できません。「誰かが作業を引き受けた」ことは「成果が納品された」ことを意味しないためです。

ステップ4：証拠で確認する

evidence-before-doneを呼び出し、完了の結論に対して現在のバージョンに対応する証拠を提示するようアシスタントに求めます。

evidence-before-done を使用して、現在の成果を確認してください。
最終ファイルを開き、元の要件と照合して項目ごとに確認してください。
変更した部分や失敗した部分があれば、再度確認してください。
証拠、未達項目、推奨する結論を列挙し、私の代わりに直接承認しないでください。

証拠には、ファイルを開いた後の内容確認、コマンドの出力、再計算の結果、または元の操作手順をもう一度実行した結果などがあります。確認後に成果が変更された場合、影響を受ける部分は再確認する必要があります。変更のない部分は、前回の確認結果を再利用できます。

ステップ5：人が検収する

証拠に基づいて、承認、差し戻し、または方向転換を判断します。人が検収の合格を確認した後にのみ、「検収済み」と記録します。要件を満たしていない場合は、差し戻しの理由を明確に記載して実行アシスタントに修正させ、その後、再び証拠を取得します。

「成果受領済み」は「検収済み」ではありません。証拠が現在の成果と一致し、人が承認の判断を下して初めて、タスクは本当に完了したことになります。

初心者に推奨する学習順序

  1. まずexamples/にある主要な例を読む。
  2. examples/walkthrough-meeting-notes/に従い、差し戻しと修正を含む小さなタスクを1回完了する。
  3. テンプレートは1つだけ学ぶ：templates/task-register-line.md。
  4. まずメモ帳や表計算ソフトで、「受領待ち → 受注済み → 成果受領済み → 検収済み」を練習する。
  5. 方法に慣れたら、対応しているAgentホストにスキルをインストールし、名前で呼び出す。

この方法自体に、複雑なプログラミング能力は必要ありません。タスクを明確に書き、実行担当者を割り当て、結果を確認できれば、共有記録から始められます。

応用方法

登録項目を既存のボードに接続する

すでにタスクシステム、電子スプレッドシート、またはプロジェクトボードを使用している場合は、登録行の項目を既存のフローに接続できます。重要なのはどのツールを使うかではなく、受領待ちのタスクを一目で確認でき、受注、成果受領、検収完了を別々の状態として扱うことです。

複数のアシスタントの役割を明確にする

スキルパッケージは手順と記述方法を提供し、ホストはセッションの開始、コマンドの実行、ファイルの読み書き、さらに定期的なリマインダーやアシスタント間のメッセージ送信機能があればそれらを担当します。人は目標の設定、優先順位の決定、危険な操作の承認、最終判断を担当します。

フローを構築するときは、次の項目を順に確認できます：

  • ホストは複数のセッションまたは子アシスタントを同時に起動できるか。
  • ホストはアシスタント間でメッセージを送信できるか。
  • ホストに定期的なリマインダーまたは起動機能があるか。
  • 自動リマインダーがない場合、誰が時間どおりに手動で確認するか。
  • 最終検収と危険な操作を誰が本人として確認するか。

影響を受けた部分だけを再確認する

成果を修正した後、すべての確認を一律にやり直す必要はありません。変更のない部分については前回の証拠を再利用できますが、変更した部分、失敗した部分、または変更の影響を受けた部分はすべて再確認する必要があります。これにより、信頼性を維持しながら重複作業を減らせます。

beginner-ops-writing で手順を作成する

ログイン、支払い、本人確認など、人が実行しなければならない工程では、beginner-ops-writingを呼び出し、手順を1回に1つの操作へ分解し、操作対象と期待される結果を明確にします。危険な操作に関しては、「本人が実行してください」とだけ提示し、アシスタントに人による承認を回避させようとしてはいけません。

ops-case-notes で振り返る

受注漏れ、検収漏れ、または同じ失敗の繰り返しが発生した場合は、ops-case-notesを参照します。振り返りを記録する際は、方法に関する情報を残します：実際の問題、採用した改善方法、実際の結果、未解決の制限事項。同時に、個人の連絡先、認証情報、内部パス、マシン情報は削除します。

必ず理解しておくべき自動化の境界

このパッケージのプラグイン一覧にあるhooks: {}は、自動起動機能を提供しないことを示します。スキルをインストールしても、アシスタントがこの方法に従って作業できるようになるだけで、システムが自動的に作業を割り当てたり、定期的に催促したり、セッション間でメッセージを転送したり、自動的に受領通知を返したりするわけではありません。

  • ホストに定期実行機能がある場合は、ホストの機能で指定時刻に確認できます。
  • ホストに定期実行機能がない場合は、人が時間どおりに確認する必要があります。
  • アシスタント間の通知、グループチャット、共有ファイルの読み書きはホストに依存します。
  • 支出、ログイン、支払い確認、正式な送信、削除などの操作は、人の承認が必要です。
  • 受け入れ、差し戻し、方向転換の最終決定は、常に人が行います。

READMEに記載された約10分という時間は、設計目標の1つにすぎず、検証済みの保証として記述してはいけません。既存のCursor CLIの測定は、ホストへのインストールとログインが済み、リポジトリが取得済みで、プロンプトが事前に準備されている条件で、スキルのコピーから登録行の出力まで約29.6秒でした。これは、初めて利用するユーザーがホストをゼロからインストールし、タスク全体を完了するまでに必要な総時間を示すものではありません。

インストールが本当に成功したかを判断する方法

プロジェクトは、2つの明確な基準を示しています：

  1. インストールして呼び出せる：取得、インストール、または設定を完了し、スキル名で呼び出して確認可能な登録行を生成できる。
  2. 実際の小さなタスクを1件完了できる：目標、役割分担、引き継ぎから、証拠の確認と人による判断まで進み、実際の成果、証拠、検収結論を残せる。

現在、8つのホストにはそれぞれ1例ずつ、限定的なタスクの検収記録があります。しかし、これは安定性の証明にはならず、すべてのタスクを完了できることも証明しません。プロジェクトでは、チーム全体のエラー率が低下したことや、催促回数が減少したことを対照実験で確認できていません。そのため、利用時には人による監督を維持してください。

まとめ

Solo to Teamの価値は、完全に自動化されたAIチームを作ることではなく、明確で、確認可能かつ移行可能な協働方法を提供することにあります。まずdispatch-accept-verifyとevidence-before-doneをインストールし、1件の小さなタスクで「受領待ち、受注、成果受領、証拠確認、人による検収」を練習してから、複数のアシスタントや既存のボードを段階的に接続します。どのホストを使う場合でも、同じ原則を守る必要があります：アシスタントは実行と証拠の提示を担当し、人は目標、承認、最終判断を担当します。