4つのAIエージェントを使い分けるAIオーケストレーション——実際の運用と、つまずいた事故まで解説します

AIエージェントを仕事で使っている方は増えましたが、多くの場合は1つを選んで使い込む形だと思います。私たちはいま、Claude・Codex・Antigravity・Grokという4つのAIエージェントを、1つのプロジェクトの中で同時に動かしています。それぞれの得意分野が違うので、仕事の種類に応じて担当を変えるやり方です。このコラムでは、その運用の実際を、うまくいっている部分もつまずいた部分も含めて書きます。

得意分野は、思っていたよりはっきり分かれています

並行して使ってみて分かったのは、性能の優劣ではなく、向き不向きがはっきり分かれるという点でした。いまの役割分担はこうなっています。

• Claude——設計と判断を担当します。何をどう作るかを決め、ルールや禁止事項を書き、どの仕事をどのAIに振るかを判断します。全体の指揮を執る役です

• Codex——実装を担当します。仕様が固まったあとのコーディングや修正作業で力を発揮します。Claudeが仕様を書き、Codexが手を動かす形が多いです

• Antigravity——調査と監査を担当します。大量に読んで分析する仕事に向いています

• Grok——手元のパソコンの中で動く役です。長時間かかる収集や計測など、クラウドのAIでは成立しない仕事を引き受けます

振り分けの基準は、領域ではなく作業量と判断の重さにしています。「SEOだからこのAI」という決め方をすると外します。判断が重い仕事はすべてClaude、仕様が確定した小さい実装はCodex、量が多くて判断が軽い仕事はAntigravityかGrok、という分け方です。

最後の2つがなぜ分かれているのかは、あとの章で書きます。ここでは全体像として、次のような形になっていると考えてください。

いちばん意外だったのは、Antigravityの監査力でした

Antigravityは、正直あまり話題になっているイメージがありません。私たちも最初は補助的に考えていました。

ところが使ってみると、Google関連の領域で明らかに強いことが分かりました。GoogleのAIなので当然といえば当然なのですが、SEOやAIO、Googleマップ対策の仕様書を作らせると、精度がはっきり違います。

以前はClaudeとCodexの2つで仕様書を作り、互いに監査させていました。そこにAntigravityを加えたところ、それまででいちばん精度の高い最適化の監査が出てきました。同じ課題でも、見る角度が変わると拾えるものが変わります。

ただし、Antigravityには強い癖があります

良いことばかりではありません。Antigravityは、そのまま使うとかなり暴れます。

私たちが実際に経験したのは、指示していない範囲までファイルが書き換えられたり、公開中のサイトが消えたりするトラブルです。本人は「低リスクの修正」のつもりで、共有している土台部分に手を入れてしまう。悪意ではなく、判断の癖です。

ここで大事なのは、その癖を欠点として切り捨てないことでした。個性を把握したうえで、暴れられない仕組みを先に作るという考え方に切り替えました。

具体的には、使う前に禁止事項を文書にしました。デザインは触らない、本番環境とインフラは閲覧だけ、削除は一切しない、Gitの危険な操作は禁止、迷ったら止まって確認する。そのうえで、任せる仕事を3つの層に分けました。

• 完全に任せる層——調査や監査など、コードを1行も変更しない仕事です。ここは承認も要りません

• 条件つきで任せる層——小さな修正のみ。変更していい範囲を数値で決め、作業の前後に機械的な検査を通します

• 渡さない層——設計判断が要る仕事や、共有している土台に関わる変更です

この線引きをしてからは、強みだけを引き出せるようになりました。あわせて、AIの自己申告を信用しないという運用も決めています。「安全な変更です」という報告ではなく、実際の差分を見て判断します。

4つ目のGrokは、エディタの中に置いています

ここまで3つで回していたところに、4つ目としてGrokを加えました。他の3つと違うのは、置き場所です。

Grokは本来、ターミナルという画面で動かします。黒い背景にコマンドを打ち込んで操作する、あの画面です。それでも問題なく動くのですが、使うたびに画面を開いて、コマンドを打って起動するという手順が挟まります。

そこで私たちは、あえてCursorというコードエディタの中に入れて使っています。Cursorを立ち上げると、Grokも一緒に立ち上がってきます。あとはChatGPTやClaudeのアプリを開いたときと同じ感覚で、そのまま話しかけられます。

小さな違いに見えますが、ここは効きました。起動にひと手間かかるものは、だんだん使わなくなるからです。開いたらもうそこにいる状態にしておくと、ちょっと聞いてみるかという場面で自然に手が伸びます。

もうひとつ、Cursorは文章やコードを書くためのエディタでもあります。そのため、Markdownで書いた指示書やメモを、同じ画面でそのまま開いて直せます。指示を出す場所と、指示書を書く場所が分かれていません。書いては読ませ、直してはまた読ませる、という往復がその場で完結します。

この「手元にいる」ことは、使い勝手の話だけでは終わりませんでした。

クラウドのAIには、物理的にできない仕事があります

はっきり分かれたのは、外部のサイトから情報を集める作業をしたときです。

同じ収集処理を、まずクラウドで動くAntigravityに任せました。ところが、集めに行った先からアクセス制限をかけられて、途中で止まってしまいます。待ち時間を8秒まで延ばしても、制限にかかる頻度は下がりませんでした。

同じ処理を、手元のパソコンにいるGrokに実行させたところ、待ち時間2秒でも一度も制限にかからず、最後まで走りきりました。

原因は能力差ではありません。どこから通信しているかの違いです。クラウドのAIはデータセンターから接続します。データセンターのアドレスは、機械的な大量アクセスの発信元として警戒されやすく、制限を受けやすい。一方、手元のパソコンからの接続は、ふつうの利用者と同じ経路です。

この一件で、振り分けの基準に実行環境という軸を足しました。「量が多くて判断が軽い」までは同じでも、そこから先が2つに分かれます。

• クラウドで完結する調査・監査——Antigravityへ渡します。読む量が多いほど向いています

• 手元でないと成立しない実行——Grokへ渡します。外部サイトへの継続的なアクセス、パソコンの中にある環境や認証情報を使う処理、何時間もかかる計測や監視がここに入ります

「待っている時間が大半で、判断はほとんど要らないが、手元でないと動かない」——この形の仕事は、思っていたよりたくさんありました。これまでは人が張り付いて回していた部分です。

もうひとつ、Grokには第二意見の役も持たせています。指揮を執るClaudeの見落としを拾う相手が、他にいないためです。ただし採否を決めるのはClaudeで、Grokの指摘をそのまま採用することはしません。

挙動より先に確認すべきなのは、入力データの扱いです

もうひとつ、複数のAIを使うなら必ず押さえておきたいことがあります。入力した情報がAIの学習に使われるかどうかです。ここは挙動の癖より優先度が高い部分です。

ここで気をつけたいのは、契約の種類だけでは決まらないという点です。同じサービスでも、どの経路で使うか、そして有料か無料かで扱いが変わります。条件を1つだけ見て判断すると外します。

まず契約です。一般に、法人向けのプランは入力内容を組織の外の学習に使わない前提で設計されています。一方、個人向けのプランは、そのままだと学習に使われる前提になっていることがあります。料金を払って上位プランにしても、それだけで学習対象から外れるわけではありません。

次に経路です。ブラウザのチャット画面から使う場合と、開発者向けのAPIを通して使う場合とで、適用される規約が変わることがあります。ただし、「APIを通しているから安全」とは言い切れません。GoogleのGemini APIの場合、有料の枠で送った内容は学習に使われない一方、無料の枠は製品やモデルの改善に使われる前提になっています。同じAPIでも、枠が違えば結論が逆になります。

私たちがAntigravityで使っているGoogle AI Proは個人向けのサービスで、組織の中に情報を留める設定そのものは用意されていません。アプリ側の送信設定はオフにしたうえで使っていますが、送信設定を切ることと、学習に使われないことは別の話として扱っています。ここを同じものとみなすと、対策したつもりで抜けが残ります。

安全だと確認しきれないうちは、お客様から預かった情報や社外秘のコードは、その経路に入れない。判断がつかないときは、この順番で考えるのが確実です。

ClaudeとCodexについては、入力データを学習に使わない設定が用意されているため、その点は比較的安心して使えています。あとから加えたGrokについても、同じ観点で契約の種別と設定を確認したうえで使っています。新しいAIを1つ増やすたびに、この確認をやり直す必要があります。

なぜここにこだわるかというと、お客様の情報を扱う仕事では、予測が立たなくなるからです。自社の情報だけなら判断は自分たちで完結しますが、預かった個人情報や取引先の情報が学習に取り込まれると、それがどこでどう出てくるかを誰も追えなくなります。だから、顧客情報や社外秘の情報は学習に使わせない、というのがセキュリティ上の基本の考え方になります。

なお、各サービスの規約や設定項目は変わります。ここに書いたのは執筆時点で私たちが確認した内容なので、導入前にご自身で最新の規約を確認してください。個人向けプランを業務で使う場合は、次の3点をセットで見ておくことをおすすめします。

• 契約の種別——個人向けか、法人向けか

• 経路と枠——ブラウザから使うのかAPI経由か。API経由なら、無料の枠か有料の枠か

• アプリ側の送信設定——オフにできるか。ただし、それが学習の停止まで意味するかは別に確かめます

指示書はMarkdownで置いて、あとは読ませるだけです

複数のAIを使うと聞くと、管理が大変そうに感じると思います。実際、指示のたびに内容をコピーして別のAIに貼り付け、結果をまた戻して……という往復が発生するなら、確実に面倒になります。

私たちの場合、そうした煩雑さはほとんどありません。理由は、4つのAIが同じプロジェクトのファイルを共有しているからです。

流れはこうです。まずClaudeが、誰に何をやってもらうかを判断して、指示書をMarkdownのファイルとして書き出します。あとはそのファイルを別のAIに読ませれば、それだけで作業が始まります。各AIが自分でファイルを読みに行くので、人が間に立って伝言する工程がありません。

ただし、4つ目を加えたときに1つつまずきました。AIによって、自動で読みに行くファイルの名前が違うのです。Grok用のルールを書いたファイルを置いたのに、Grokがそれを読まず、他のAI向けのファイルだけを読んでいた、ということが起きました。担当範囲を書いた文書が本人に届いていない状態です。

これは新しいAIを迎えるたびに起こります。ルールを書いて置いたことと、相手がそれを読んでいることは別なので、増やしたら必ず読めているかを確かめてください。

結果として、4つを使い分けているという意識はあまりありません。頭を切り替えている感覚がなく、ひとつながりの作業として進みます。

分けているのは仕事だけでなく、消費枠もです

もうひとつ、実利の話も正直に書いておきます。

Antigravityを使い始めたきっかけは、性能の比較ではありませんでした。もともとGoogleのサービスを複数アカウントで使うために契約していたプランが、Google AI Proに変わったことで、Geminiのクレジットが毎月かなり余っている状態になっていたのです。

当時はClaudeとCodexの2本柱で回していて、重い作業が続くと週の上限に達して使えなくなることがありました。そこにAntigravityを加えたところ、そちらへ振った分だけClaudeとCodexの消費が減り、上限に当たる場面がほぼなくなりました。

Geminiのクレジットは枠が大きいので、かなり作業を振っても余裕があります。強みを活かした分担と、消費の分散が同時に成立した形です。

ただし、これはあくまで結果です。クレジットの都合で振り分け先を決めることはしません。安いほうに寄せると、判断が重い仕事を不向きなAIに渡すことになり、事故のもとになります。あくまで得意分野で振り、そのうえで偏りが減るなら好都合、という順番です。

複数を使う本当の理由は、変化についていくためです

ここまで役割分担の話をしてきましたが、複数のAIを使う理由はもうひとつあります。

この分野は変化が速く、モデルが更新されるたびに得意分野が入れ替わります。半年前の「このAIはこれが得意」という前提が、次の更新で変わることは珍しくありません。1つに絞っていると、その変化に気づけません。

4つを日常的に使っていると、同じ仕事を投げたときの差が自然に見えます。どれが最強かを決めるためではなく、いま何が変わったかに気づくために複数を使うというのが、続けている理由です。

まとめ——強みで振り分け、弱点は仕組みで抑えます

4つのAIエージェントを並行して使う運用は、性能を足し算するためのものではありません。

• 役割を分ける——設計と判断はClaude、実装はCodex、クラウドでの調査と監査はAntigravity、手元での実行はGrokに振ります

• 基準は領域ではない——読む量と判断の重さ、そして実行環境で決めます。「この分野だからこのAI」で決めると外します

• クラウドと手元を使い分ける——同じ処理でも、どこから通信するかで結果が変わります。能力の問題に見えて、環境の問題であることがあります

• 癖は仕組みで抑える——禁止事項を先に文書化し、任せる範囲を層で分け、自己申告ではなく実物で確認します

• データの扱いを先に確認する——契約の種別によって、入力内容が学習に使われるかが変わります。顧客情報を扱うなら、挙動の検証より先にここを見ます

• 指示はファイルで渡す——同じプロジェクトを共有していれば、Markdownの指示書を置くだけで作業が始まります

• 複数使う目的は変化への追随——最強を決めるためではなく、得意分野の入れ替わりに気づくためです

生成AIの導入そのものをどう始めるかは愛媛の中小企業が生成AI導入・ChatGPT活用を始めるときのコラムに、ChatGPTとClaudeを同じ条件で比較した検証は使い分けのコラムにまとめています。こうした運用の組み立てからご相談されたい場合は、AI導入・業務効率化支援もご覧ください。