FableとSol、AstraとOpusをまたいだエージェント連携の設計メモ

異なるベンダーのAIモデルを役割分担させて連携させるという考え方は理にかなっているが、実装段階で大きな課題に直面する。Fableやsolなど異なるエンジン間のセッションでは、コンテキストが一切引き継がれない。一方が読んだファイルも思考過程も、もう一方には届かない。この構造は、転院時に前医の診療情報提供書を紹介先の医師に渡すのと同じ。ファイルやタスク履歴も紙の上で完結させないと、後続のエンジンが判断を誤る。引き継ぎ書の質が、システム全体の品質を決める基本的な事実だ。

設計上の工夫をいくつか紹介するなら、まず共通ルールを「AGENTS.md」などに集約し、司令塔と実行者の役割を明確に分ける。実行者に渡すタスク票には「変更してよいファイル」「やらないこと」「止まる条件」の三項目を必ず記載する。Solのような粘り強いモデルの場合、ついでの改善に走るリスクが高いため、範囲外への行動を明示的に禁止する必要がある。さらに機械的なガードとして、委任スクリプトが環境変数AGENT_ROLE=workerをセットすることで、実行者による再委任を即座にエラーで返す。文章ルールと環境変数による二重構造が、予想外の暴走を防ぐ。

実務への含意は意外と単純だ。「どちらのエンジンが優れているか」で選ぶのではなく、「どちらの側に既存の設定やスキルが蓄積されているか」で使い分けるのが現実的である。Fable→Solは正解が明確なコーディングタスク向き、Astra→Opusは既存スキルや設定が絡む文章業務向きといった棲み分けが実務では有効だ。複数モデルの価値は、比較競争ではなく「引き継ぎ書」の仕組みで初めて引き出される。