現在は 2026年1月25日、日曜日の午後です。
Multi-Agents: 対抗生成翻訳
昨日、CZON の軽量な OpenCode 翻訳統合を完了し、基本的な対抗生成モデルを実装しました。
この翻訳タスクでは、翻訳タスクと審査タスクが導入されています。両者が対抗生成を行い、翻訳モデルは翻訳結果の生成を担当し、審査モデルは翻訳結果が合格かどうかを審査します。審査モデルが翻訳結果を不合格と判断した場合、翻訳モデルに再生成を要求し、合格する翻訳結果が生成されるまで繰り返します。（現在、無限ループを防ぐため最大反復回数は10回に設定されています）
この翻訳設計は、従来のワンショット LLM 翻訳と比較して、時間とトークンの効率性を犠牲にしています。しかし、決定的な利点があります：翻訳品質を大幅に向上させ、以下の問題を解決できることです。
- 翻訳内容の欠落問題: 一部の翻訳モデルは原文の一部の内容を漏らし、翻訳結果が不完全になることがあります。審査モデルは翻訳結果に原文のすべての内容が含まれているかをチェックし、翻訳の完全性を保証します。
- 長文翻訳の一貫性の問題: 一部の翻訳モデルは長文を処理する際、前後の一貫性が失われる場合があります。審査モデルは翻訳結果の一貫性をチェックし、翻訳結果が全体として統一されていることを保証します。
- 不自然でぎこちない表現の問題: 一部の翻訳モデルが生成する翻訳結果は、不自然でぎこちなく感じられることがあります。審査モデルは翻訳結果の流暢さを評価し、翻訳結果が目標言語の表現習慣に合致していることを保証します。
結果から見ると、翻訳品質の優先度は明らかにトークン効率や時間効率よりも高くなっています。CZON のように高品質な翻訳が必要なシナリオでは、対抗生成モデルは優れた選択肢と言えます。
Multi-Agents メモリ最適化
各 Agent に対して個別にプロセスを起動することはできません。各プロセスは少なくとも 100MB 程度のメモリを消費するため、複数の Agent を同時に実行するとメモリ不足に陥る可能性があります。より良い方法は、すべての Agent を単一のプロセス内に統合して実行し、メモリオーバーヘッドを削減することです。OpenCode 公式は Server と Client を分離しており、1つの serve プロセスでポート（デフォルトは 4096）をリッスンし、複数の Client がこのポートに接続して対話する方式を採用できます。これにより、すべての Agent を単一の Server プロセス内で実行し、Client はリクエストの送信とレスポンスの受信のみを担当することが可能になります。
この方法であれば、メモリ不足によるクラッシュを起こすことなく、数百の翻訳タスクを同時に起動することをサポートできるはずです。
Multi-Agents の制御と制約
業界には主に二つのアプローチがあります。一つは Agent が Agent を制御する方法、もう一つは Script が Agent を制御する方法です。
違いは、Agent による Agent の制御はソフト制約であり、Agent は自身の判断に基づいて他の Agent からの指示を実行するかどうかを決定できます。一方、Script による Agent の制御はハード制約であり、Agent は Script の指示に厳密に従って実行しなければなりません。
ソフト制約の利点は柔軟性にあり、欠点は信頼性に欠けることです。ハード制約の利点は信頼性にあり、欠点は柔軟性に欠けることです。
ソフト制約の問題はよく見られます。Agent 内にワークフローが定義されていても、Agent がそのワークフローに従ってタスクを実行せず、予期せず早期に終了してしまい、結果が期待通りにならないことがあります。一方、ハード制約の問題は、Script がすべてのシナリオを網羅できない可能性があり、Agent が特定の特殊な状況を処理できないことです。
これら二つは一見相容れないように見えますが、実際には、Orchestrator Agent を使用して Script を生成し、他の Agent にその Script に従ってタスクを実行させることで、両方の利点を組み合わせることができます。これにより、柔軟性と信頼性の両方を兼ね備えることができます。初期段階では、Agent の動作を制御するために Script を手動で記述することさえ可能です。完全な制御こそが最大の柔軟性なのです。
したがって、Script が Agent を呼び出す際の摩擦を十分に小さくし、一行のコードでスケジューリングを実現できるようにし、それによって複雑なマルチエージェントの協調作業を実現する必要があります。
Anthropic の Multi-Agent に関する記事では、サブエージェントの出力はメインのオーケストレーターに返すのではなく、ファイルシステムに書き込むことが望ましいと述べられています。したがって、Script が Agent を呼び出す際には結果を返す必要はなく、Agent に結果をファイルシステムに書き込ませ、他のモジュールがファイルシステムから結果を読み取るようにすれば良いと考えられます。
さらに、Script は JS などの一般的な言語に統合することができ、ライブラリを利用することで、Orchestrator Agent がまず Script をエンコードし、その後 Script が他の Agent を呼び出してタスクを実行することを実現できます。DSL を使わずに、DSL を超えることができます。
Multi-Agents エコシステム: OpenCode vs Claude Code
OpenCode のエコシステムは Claude よりも明らかにオープンです。OpenCode は HTTP API（または SDK）を通じて Agent を呼び出し、Agent Session の状態を確認し、Agent の出力結果を取得することを許可しています。これにより、OpenCode Agent を私たちのシステムに統合し、複雑なマルチエージェントの協調作業を実現することがより容易になります。一方、Claude はこれとは逆の道を進み、生態系を閉鎖しようと努めており、Anthropic が提供するインターフェースを通じてのみ Claude Agent を呼び出すことを許可し、ユーザーの自由度を制限しています。
