TOOLSET-01

AIチームで動かす仕事の作り方

道具セット：マルチエージェントオーケストレーション

複数のAIエージェントを役割分担して動かす実践の記録です。ツールを組み合わせることで、何が変わったか。2026年5月時点の運用をそのまま書いています。

こんな人向け
  • AIツールはひとつ試したことがある
  • 「AIが組み合わさって動く」がどういうことか知りたい
  • 実際に使っている現場の話が読みたい
SECTION 01

このページの立ち位置

よりみち研究部の実践記録のひとつです。

道具箱（toolkit.html）は個々の道具の説明書です。経験値の棚（research.html）は発見や振り返りの記録です。このページ（道具セット）は、複数の道具をどう組み合わせて動かすかのレシピにあたります。

道具箱（TK） 経験値の棚 道具セット（このページ）
何か 道具の説明書 発見の記録 組み合わせのレシピ
読み方 必要なとき辞書的に 振り返りに 全体の流れを見たいとき
SECTION 02

チーム構成図

「誰に頼むか」をその都度考えず、あらかじめ役割を決めておく仕組みです。上から順に指示が流れ、担当エージェントが受け取って動きます。

キリイモさん（代表）
↓ 指示・判断依頼
クロコ（管理・判断）
↓ 担当領域ごとに振り分け
エミリー
整理・今日やること
カイ
戦略・方向性
ソウ
発信文・翻訳
リー
リサーチ・調査
コディー
定型処理・外注
コトリ
画像たたき台
アカリ
画像仕上げ

クロコが担当領域の判断をまとめて受け持つことで、キリイモさんは「誰に頼むか」を都度考えなくて済む設計にしています。

SECTION 03 — 実例

発信文ができるまで

X（Twitter）の投稿文を作る場合を例に、流れを見てみます。

FLOW — X投稿文の作成
  1. ① キリイモさん「X投稿したい」と伝える
  2. ↓ クロコが判断：発信文・SNS関連 → ソウへ
    担当領域がすでに決まっているため、選ぶ手間がない
  3. ↓ ソウが投稿文の案を作成して返す
  4. ↓ キリイモさんが確認し、「いいね」「修正して」などを伝える
    明示的な指示が出るまで次の処理には進まない
  5. ↓ 必要なら整形処理などは コディー へ外注
  6. ↓ 完成・確認後に公開
指示が出るまで動かない設計が前提になっています。「それでいい」「よさそう」だけでは次のステップに進みません。「やって」「進めて」のように動詞でカチッと締まった言葉を合図にしています。

なぜクロコが「ソウへ」と判断するかというと、担当領域をあらかじめ決めているからです。ひとつひとつ選ばなくていい分、判断コストが下がります。

SECTION 04 — 実例

リサーチから活動記録へ

新しい分野を調べてサークル活動の記録にする場合の流れです。

FLOW — リサーチ〜記録化
  1. ① キリイモさん「○○について調べてほしい」と伝える
  2. ↓ クロコが判断：リサーチ・調査 → リーへ
  3. ↓ リーが調査・構造化して報告する
    出典URLと箇条書きで整理して返す
  4. ↓ クロコが記録化（活動ログ・HTMLページへの反映）
「調べる人」「記録する人」「判断する人」が分かれているため、それぞれの作業が混在しません。クロコが一度に複数のことを抱えなくて済む設計です。

役割が明確に分かれているほど、誰がどこでつまずいているかが把握しやすくなります。この分離が、チーム全体の見通しを保つ鍵になっています。

SECTION 05

この仕組みで変わったこと

  • 1 「何を誰に頼むか」を毎回考えなくなった。担当領域があらかじめ決まっているため、指示が来たらクロコが自動で振り分ける。選ぶコストがなくなった分、判断を使う場面に集中できる。
  • 2 意図しない動作が減った。明示的な指示が出るまで動かない設計にしたことで、「勝手に処理が進んでいた」という事態を防ぎやすくなった。
  • 3 Claude Codeの使用量を管理職の判断に集中できた。定型処理（HTMLの整形・スクリプト生成・ファイル変換など）は別のAPIへ外注する設計にしたことで、より判断が必要な作業にリソースを向けられるようになった。
  • 4 指示の粒度が下がった。エージェントごとに得意領域があるため、「ざっくり」でも動く。「発信したい」だけでソウに振り分けられる。細かく指定しなくてよくなった。
SECTION 06

注意点と限界

この仕組みは万能ではありません。以下の点は正直に書いておきます。

  • △ モデルの仕様は変わる。この記録は2026年5月時点のものです。AIのバージョン更新・サービス仕様の変更により、同じ動作が保証されるわけではありません。
  • △ 「誰に頼むか」の設計には最初にコストがかかる。チームの役割を決めて、言語化して、実際に動かして検証する工程が必要です。設計なしにいきなり複数エージェントを使っても効果は出にくい。
  • △ ルールを言語化しておかないと想定外の動作が起きる。「何をしてよくて、何をしてはいけないか」をあらかじめ決めておかないと、エージェントが期待と違う動きをすることがある。経験から積み上げたルールが運用の背骨になっています。
この仕組みを使ってどんな発見があったか、具体的な記録は 経験値の棚 に残しています。