AIに仕事を頼むとき、私たちは無意識に一人の万能アシスタントを期待しています。
調べて、まとめて、資料にして、チェックまでしてほしい、と。
でも考えてみると、これは人間には絶対に頼まない頼み方です。
実際の職場なら、調査担当、制作担当、レビュー担当と自然に分かれるはずの仕事を、AIには丸ごと押し付けている。
最近のAIエージェント開発の現場では、ここに変化が出てきています。
1人の万能AIに全部やらせるのではなく、複数のAIに役割を持たせてチームのように働かせる方法です。
自分の仕事を自分でチェックする限界～AIにも役割分担をさせる
システム開発を例にすると分かりやすいです。
1人のAIに、
- 仕様を考える
- 作業を分解する
- プログラムを書く
- テストする
- 自分で書いたコードをレビューする
ところまで全部やってもらうこともできます。
ただ、自分で作ったものを自分だけでチェックすると、どうしても見落としは出ます。
これは人間もAIもあまり変わりません。
そこで、役割を分けます。
- 全体を見て仕事を切り分ける「親方役」
- 渡された範囲を実装する「実装担当」
- 別の視点からチェックする「レビュー担当」
- そして、何を作るか決め、最終判断を下す「人間」
「人間＋AIアシスタント」というより、「人間＋AIチーム」という構図です。
親方が仕事を分け、子分が動く
筆者も実際の開発で、この方法を使っています。
普段の構成は、
親方役のAIが1体、実装や調査を担当するサブエージェントが4～6体程度。影響範囲の大きい変更では、さらに別の高性能AIにもレビューを依頼する
という形です。
親方はまず既存のコードや仕様を確認します。
そのうえで、
- 「この機能はここまで」
- 「触っていいファイルの範囲」
- 「この条件を満たしたら完了」
というところまで決めてから、サブエージェントへ仕事を渡します。
仕事が終わったら、親方が実際の変更内容を確認し、テストを走らせます。問題があれば実装担当へ差し戻して繰り返し。
データベース、認証、権限など、影響範囲の大きい変更では、さらに別の高性能なAIを呼んでレビューさせ、問題が見つかれば、また実装担当へ戻します。
会社と同じ構造です。
上司が仕事を切り分け、担当者が実作業を行い、最後に別の人がチェックする
AIだからといって、仕事の進め方まで特別なものになるわけではありません。
高性能AIを全員分そろえる必要はない
AIを複数使うと聞くと、
「それでは利用料金も何倍にもなるのでは？」
と思うかもしれません。
ここで効いてくるのが、モデルの使い分けです。
最近の軽量モデルは、範囲がはっきりしたコーディングなら十分に実用的です。
「安いモデル＝コードが書けないモデル」ではありません。
むしろ、何を変更するのか、どこまで触ってよいのか、何をもって完了とするのかが明確なら、軽量なモデルでもかなりしっかり仕事をしてくれます。
たとえば、このように分担します。
複雑な設計や重要な判断→ 高性能モデル
調査・実装・定型作業→ 軽量モデル
重要なレビュー→ 高性能モデル
高性能AIで軽量AIを挟む、ちょっとした「サンドイッチ構造」です。
部長クラスを何人も集めてデータ入力だけさせる会社がないのと同じ理屈です。
一番高性能なモデルをすべての作業に使うより、難しいところに計算資源を使い、明確な仕事は軽量モデルに任せるほうが合理的です。
そして面白いのは、仕事を上手に分けられるほど、高価なモデルを使う場面も減らせることです。
つまりコストを左右するのは、モデル選びそのものより、仕事の分け方だったりします。
会社をまたいでチームを組んでもいい
AIチームを作るとき、全員を同じ会社のモデルでそろえる必要もありません。
実際、コーディング用途ではOpenAIやAnthropicのモデルだけでなく、GrokやKimiなど、複数のモデルを用途やコストによって使い分ける例も見られます。
設計はこのモデル。
大量の実装は別のモデル。
最後のレビューはまた別のモデル。
そんな組み合わせもできます。
この流れを象徴するようなツールも出てきました。
OpenAIが公開している「Codex plugin for Claude Code」です。
名前の通り、Claude Codeの中からCodexを呼び出すためのプラグインです。
Claude Codeで実装し、Codexにレビューを頼む、という流れが一つのツールの中で完結します。
しかも普通のレビューだけでなく、「そもそもこの設計で良かったのか」を問い直す adversarial review まで用意されています。
もはや「ClaudeかCodexか」ではなく、「ClaudeとCodexをどう組み合わせるか」という話になっています。
AI同士は競合していても、使う側まで一社に絞る必要はありません。
得意な仕事を、それぞれ得意なAIに任せればいいのです。
マネジメントの仕事は消えない
もちろん、AIを増やせば自動的に仕事がうまくいくわけではありません。
実際にやってみると、ここは人間のチームとよく似ています。
仕事の切り分けが悪いと、複数のAIが同じファイルを同時に変更してしまいます。
指示が曖昧なら、それぞれが違う方向へ進みます。
何でも並列にすれば速くなるわけでもありません。
前の作業が終わらないと始められない仕事もあります。
そして、サブエージェントを増やせば、そのぶん利用量も増えます。
AIチームにもマネジメントが必要です。
誰に何を任せるのか。
どこまで任せるのか。
どこで確認を入れるのか。
この設計が雑だと、人数ならぬ「AI数」を増やしただけで、かえって面倒になります。
AIにも業務マニュアルを渡そう
同じ方法で何度も仕事をさせていると、もう一つ面倒なことが出てきます。
毎回、
- 「最初にこれを確認してください」
- 「この種類の変更では必ずテストしてください」
- 「この場合は別のAIにもレビューを頼んでください」
と説明する必要があることです。
そこで役立つのが「Skill」のような仕組みです。
人間の会社でいうなら、業務マニュアルや標準作業手順書に近いものです。
筆者が使っている親方役のAIにも、
- 最初に何を確認するか
- どう仕事を分割するか
- どんな作業を軽量モデルへ任せるか
- どんな変更では追加レビューを行うか
- 最後に何をチェックするか
といったルールを持たせています。
一度作っておけば、別の開発でも同じ進め方を再利用できます。
AIを使いこなすというと、良いプロンプトを書くことばかりに目が向きがちです。
良いプロンプトを書くことより、進め方そのものを仕組みにしてしまう方が結局は安定する、というのが実感です。
開発以外でもAIチームは作れる
ここまではシステム開発を例にしてきましたが、考え方そのものはほかの仕事にも使えます。
たとえば営業資料なら、
情報収集 → 構成 → 原稿作成 → 校正
社内文書なら、
文書検索 → 要約 → 根拠確認
マーケティングなら、
市場調査 → アイデア作成 → 原稿作成 → 表現チェック
といった形です。
全部を別々のAIにする必要はありません。
大事なのは、
「このAIに全部やってもらおう」
から、
「この仕事には、どんな役割が必要だろう」
へ考え方を変えることです。
モデル選びから、組み合わせ方へ
少し前まで、生成AIの話題では、
「ChatGPTとClaudeはどちらが賢いのか」
「一番性能の高いモデルは何か」
といった比較をよく見かけました。
もちろん、モデルの性能比較は今でも大切です。
でも、AIエージェントが実務に入り込んでくると、それだけでは足りません。
どの仕事を、どのAIに、どんな順番で渡すか。
高性能なAIに全体を考えさせる。
明確に切り分けた仕事は、軽量なAIへ渡す。
重要な成果物は、別のAIにチェックさせる。
必要なら他社のAIも混ぜる。
そして最後は人間が判断する。
AIがさらに高性能になれば、人間が一つひとつ手を動かす場面は減っていくでしょう。
その一方で、
「誰に何を任せ、どこで確認するか」を考える仕事
は残ります。
一人の優秀なAIを探して全部任せるのも一つのやり方ですが、
そろそろ自分の仕事に合った「AIチーム」を組んでみる、というのも選択肢に入れていい時期かもしれません。