OpenAIが並列エージェントのトークン増を明記、事務所の使い分け3論点

OpenAIが公式文書で、並列エージェントのトークン消費増を明記しました。

複数のAIエージェントを同時に走らせる使い方が、主要な開発ツールで既定の機能になっています。その一方で、OpenAIはCodexのサブエージェント解説のなかで、サブエージェントを並べて動かすやり方は同等の単独実行よりもトークンを多く消費すると書いています。速くなる話と安くなる話は別だ、という整理が提供元の文書に明記された形です。士業事務所でAIの利用枠や費用を見ている立場からすると、機能そのものよりもこの一文のほうが実務に効いてきます。本記事では公表資料に書かれている事実を整理したうえで、事務所側で何が論点になるかを3つに分けて見ていきます。

公式文書に書かれた並列エージェントの仕組み

サブエージェントとは、親のAIが仕事を分割して専門の子エージェントを同時に立ち上げ、その結果を1つの応答にまとめて返す使い方のことです。OpenAIのサブエージェント設定ドキュメントによれば、現行のCodexではこのワークフローが既定で有効になっており、親のAIが子の起動から指示の振り分け、結果待ち、スレッドの終了までを受け持ちます。

そのうえで同ドキュメントは、子エージェントはそれぞれが独自にモデルを動かしツールを呼ぶため、並列のワークフローは同等の単独実行よりトークンを多く消費すると述べています。速度と消費が別々に動くという意味で、これは機能の宣伝ではなく代償の説明です。

なぜそれでも並列に分けるのかについては、文脈の劣化という別の理由が挙げられています。探索のメモ、テストのログ、スタックトレース、コマンドの出力といった途中経過が会話に積み上がると、必要な情報が埋もれる「コンテキストの汚染」と、関連の薄い情報で会話が埋まって性能が落ちる「コンテキストの腐食」が起きるという整理です。背景資料としてはChromaのcontext rotに関するレポートが参照先に挙げられています。途中経過を子に押し出し、親には要約だけを戻すことで、親の会話を要件と判断に集中させるという考え方です。

速くなる仕事と、慎重に扱う仕事が分けて書かれている

注目したいのは、並列化を勧める範囲が公表資料のなかで限定されている点です。同ドキュメントは、出発点としては探索、テスト、トリアージ、要約といった読み取り中心の作業に並列エージェントを使うよう示し、書き換えを伴う並列ワークフローについてはより慎重に扱うよう促しています。理由として、複数のエージェントが同時に編集すると衝突が起き、調整の手間が増えることが挙げられています。

設定値の側にも同じ方向の注意書きが並びます。同時に開いておけるスレッドの上限は既定で6、子がさらに子を生む入れ子の深さは既定で1です。深さを上げると、広い委任の指示が繰り返しの分岐に変わり、トークンの消費と待ち時間、手元の資源の消費が増えるとドキュメントは説明しています。上限の設定は同時に開くスレッドの数を抑えるだけで、深い再帰にともなうコストと予測しにくさは消えない、とも書かれています。

見積もりの立てにくさはCodexの料金ページでも触れられています。似て見える作業でも消費量は変わりうるとして、モデルの選択、文脈、推論、ツールの利用、検索、キャッシュがいずれも消費に影響するため、プロンプトの長さだけでは信頼できる見積もりにならないと説明されています。推論の深さを上げると応答時間とトークンの消費がともに増えることも、サブエージェントの解説側に書かれています。

士業事務所から見た3つの論点

第一に、速さと消費は別の勘定だという点です。並列にすれば待ち時間は縮みますが、消費される枠は同じ契約から減っていきます。読み取り中心の作業には向き、書き換えを伴う作業には慎重に、という切り分けが提供元の文書に書かれている以上、資料の下読みや論点の洗い出しと、成果物そのものを書かせる工程は、同じ「AIに任せる」でも別の設計として扱う余地があります。AIエージェントの実行制御をどう置くかを整理した記事も、この切り分けの土台になります。

第二に、承認の出どころが増える点です。サブエージェントは親の現在のサンドボックス設定をそのまま引き継ぐとドキュメントは述べており、対話型の利用では、見ていない別スレッドから承認の要求が上がってくることがあると説明されています。非対話の実行では、新たな承認が必要になった動作は失敗して親側にエラーとして戻ります。事務所に置き換えれば、誰がどの画面を見て承認を押すのかという話で、権限とログの境界をどう決めるかの延長線上にあります。並列で走っている分だけ、確認の場所が散らばることになります。

第三に、効果の測り方です。似た作業でも消費が変わると提供元自身が書いているのですから、机上の試算で年間の削減時間や費用を置いても、運用と噛み合わない可能性があります。AI導入の効果をどう測るかで扱った実測の考え方や、本番移行で確認の段階をどう置くかの整理と合わせて、小さく回して実績値を取る段階に置いている事務所もあります。なお、複数のAIを同時に走らせたときに何が起きうるかという別の角度からは、100体規模の実験で観察された挙動も参考になります。

入力データの取り扱い

士業事務所にとっては、消費量より先に入力したものがどう扱われるかが導入可否を分けます。OpenAIはエンタープライズ向けのプライバシー説明で、ChatGPT Enterprise、Business、Edu、およびAPIについて、入力と出力をモデルの訓練や改善に使わないと説明しています。個人向けの契約ではデータの利用に関する説明ページのとおり設定に依存します。

サブエージェントを使うと処理の経路は増えますが、今回のドキュメント自体は学習利用や保存期間に触れていません。したがって並列にしたことで扱いが変わるのかどうかは、公表資料からは確認できません。契約しているプランと管理者側の設定を確認する作業が別に残るという理解になります。顧問先の情報を扱う場面では、税理士法第38条の秘密を守る義務や弁護士法第23条の秘密保持の権利および義務が背景にありますが、個別の入力や運用がこれらの条文との関係でどう評価されるかは有資格者の判断領域なので、本記事では踏み込みません。ツール選定の場で何を聞くかはベンダーへの確認項目にまとめています。

今後の動きと当面の確認点

OpenAIは表形式の一括処理にサブエージェントを使う仕組みも実験的な位置づけで公開しており、1行につき1体の作業エージェントを立ち上げ、結果をまとめて出力する使い方が説明されています。1体あたりの既定の制限時間は1800秒で、結果を報告せずに終了した行は出力側でエラーとして記録されます。件数の多い定型確認を機械的に流す方向に進んでいることがうかがえますが、件数がそのまま消費に乗る構造でもあります。

当面は、並列を使う作業と使わない作業を分けているか、入れ子の深さを既定のままにしているか、承認を誰がどこで押すかが決まっているか、そして消費の実績を記録しているか、という4点を点検している事務所があります。記録の残し方についてはAI利用ログを監査証跡にする考え方が参考になります。

まとめ

OpenAIは公式文書で、並列エージェントが単独実行よりトークンを多く消費することと、入れ子を深めると消費と待ち時間が増えることを明記しました。読み取り中心の作業には向き、書き換えを伴う作業には慎重に、という切り分けも提供元の側から示されています。速さの話と費用の話を分けて設計し、承認の場所と消費の実績を先に決めておく段階だといえます。

参考文献

※士業のチカラでは、生成AIの導入支援から運用最適化まで、貴事務所の業務に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://shigyonochikara.jp/contact/

引用元: OpenAI Developers

本記事の作成体制について

本記事は士業のチカラ編集部が、公表されている一次情報のみを根拠に作成しています。法令の条文はe-Gov法令検索の原文で、行政の見解は各府省庁の公表資料で、それぞれ確認したうえで記載しています。引用元は本文中および参考文献にすべて明示しています。

本記事には特定の資格者による監修は入っていません。個別の事案について法令の当てはめや手続の可否を判断する必要がある場合は、当該分野の有資格者にご相談ください。本記事は一般的な情報提供を目的としたものであり、個別具体的な法律判断・税務判断・労務判断を提供するものではありません。

記載内容に誤りを見つけられた場合は、お問い合わせよりご指摘ください。確認のうえ速やかに訂正し、訂正履歴を記事内に残します。編集方針の詳細は運営者情報をご覧ください。