前回まで、Omnigentの構成を理解し、Pollyでコードのクロスレビューを動かしてきました。ただ、触っているうちに「合成の価値って、結局クロスレビューくらいでは?」という疑問が湧いてきました。並列にサブエージェントを走らせるだけなら、Claude Code単体でもできます。

この記事では、もう1つの同梱エージェント Debby を動かして、合成のまったく別の側面を体験します。Debbyは同じ問いを複数のモデルに投げて突き合わせ、議論させて統合まで持っていくエージェントです。「合成 = 並列」でも「合成 = クロスレビュー」でもない、第三の合成が見えてきます。

そもそもPollyとDebbyとは何か

先に用語を整理します。PollyもDebbyも、Omnigentに同梱されているサンプルのエージェント定義(YAML1枚)です。Omnigent本体の機能ではなく、「Omnigentでこういうエージェントが組めます」という公式のお手本が2つ入っている、という位置づけです。前回のアーキテクチャ回で見た通り、エージェントは name / prompt / executor(ハーネス)/ tools を書いたYAMLにすぎず、PollyもDebbyもその実例です。

2つは合成の別パターンを見せるために用意されています。

Pollyは、コーディングのオーケストレーターです。自分ではコードを書かず、タスクを分割して claude_code / codex / pi のサブエージェントに別々のworktreeで並列実装させ、別ベンダーにクロスレビューさせます。「実装を分割・並列化し、相互チェックする」合成です。

Debbyは、2つの頭を持つブレスト相手です。自分では答えず、あらゆる問いを claude と gpt の2つのサブエージェントに同時に投げて、両方の視点を並べます。debate スキルを読み込むと、2つが互いの回答を批評し合ってから統合に収束します。「同じ問いを複数モデルに投げて突き合わせる」合成です。

両者に共通するのは、脳自身は claude-sdk ハーネスで動いて指揮に徹し、実際の作業(実装 or 応答)を別のサブエージェントに委ねるオーケストレーター構造です。違いは目的だけ、Pollyがコード実装の分割・並列・レビュー、Debbyが同一問いの多モデル比較・議論です。名前は単なるサンプルの愛称で、同じ形式で自作すれば独自のオーケストレーターも作れます。

Debbyの構造を定義から確認する

動かす前に、Debbyのエージェント定義を読んでおきます。手元のcloneにあります。

cd ~/src/omnigent
cat examples/debby/config.yaml

定義から、Debbyの中身がはっきりします。脳は claude-sdk ハーネスで動き、自分では実質的な思考をしません。2つの純粋な応答役のサブエージェント、claude(claude-sdkハーネス)と gpt(codexハーネス)を持ち、あらゆる質問を両方に並列で投げて、それぞれの答えを並べます。debate スキルを読み込むと、2つに互いの回答を批評させ、指定ラウンド数だけ議論させてから統合します。

ここがPollyとの構造上の違いです。Pollyのサブエージェントは worktree でコードを書く実装役でしたが、Debbyのサブエージェントは同じ問いへの2つの応答役です。タスクを分割しているのではなく、同じ問いを複数ベンダーに並走させています。

前提として、Debbyの2つの頭は claude-sdk と codex ハーネスで動くので、ClaudeとOpenAIの両プロバイダーが必要です。前回のスモークで両方のサブスクを設定済みなら、そのまま動きます。

起動して2モデルに同時に問う

Debbyはコードを書かず問答するだけなので、gitリポジトリは不要です。使い捨てのディレクトリで起動します。

mkdir -p ~/work/debby-try && cd ~/work/debby-try
omni run ~/src/omnigent/examples/debby/

http://localhost:6767 にWeb UIが開きます。画面下に「Debby (Claude SDK)」と表示され、脳が claude-sdk で動いていることが分かります。

2モデルで差が出そうな問いを投げます。事実の一問一答より、判断や設計が絡む問いの方が、モデルの個性が出て面白いです。

Pythonで大量のCSVを集計する処理を書くとき、pandasとpolarsのどちらを選ぶべきか。
それぞれの立場で主張してください。

送ると、Debbyは自分で答えず、claude と gpt の両サブエージェントに同時にこの問いを投げます。右のAgentsパネルに、pandas-vs-polars-claude と pandas-vs-polars-gpt の2つがぶら下がり、それぞれ独立に考え始めます。定義通りの「自分では答えず両方に並列で投げる」挙動です。

ラウンド0: 2つの視点が並ぶ

両方の回答が揃うと、Debbyが2つの視点を並べて見せます。今回の結果は、方向性は一致しつつ力点が割れました。

両者とも、新規の大量CSV集計ならPolarsを第一候補に推し、決め手は遅延実行(scan_csv)によるpushdownで速度とメモリを両取りできる点、という点で一致しました。pandasの価値はエコシステムの厚みと既存資産の延長にある、という評価も共通です。

一方で力点は違いました。Claudeは「そもそもDuckDBという第三の選択肢がある」を強く推し、「速い=正しいとは限らない、まず実測せよ」という実験主義を打ち出しました。GPTは「CSVをやめてParquetに変える」という前処理の改善と、pandas 3.0のCopy-on-Write / PyArrow backendといったpandas側の最新改善を、より具体的に評価しました。

同じ問いでも、片方はDuckDBと実測主義、片方はParquet化とpandasの最新機能、と別の切り口が出てきます。

ここまでは、2モデルに別々に聞いて答えを並べただけ、とも言えます。正直、これだけなら手でコピペしてもできます。Debbyの本領は次です。

/debate: 議論が動く

空の画面にチップで出ている debate スキルを読み込みます。チャットに /debate と打つだけです。

これを実行すると、Debbyは先ほどの2つの回答を「ラウンド0」として、1ラウンドの相互批評を回します。それぞれに相手の回答を渡して、批評と自説のアップデートを依頼します。ここで議論が実際に動きました。

Claudeは3点を明確に譲歩しました。Parquet化の優先度、相互変換のcloneコスト、pandas 3.0 CoWの正確な段階。自説の弱点を素直に認めて、上流の視点を強化しています。GPTはClaudeの「断定」を定量面で削りました。性能倍率もメモリ倍率も「ワークロード依存」であり一般論として言い切りすぎだと戒め、pandasの最新改善を織り込むよう促しました。数字の扱いはGPTがより慎重でした。

そしてDuckDBで両者が完全合流しました。ラウンド0ではClaudeだけがDuckDBを名指しし、GPTは「Spark系 / DWH」と曖昧でしたが、ラウンド1でGPTもDuckDBを明確な第三候補に格上げし、両者が一致しました。

残った温度差は「汚いCSV」への構えだけでした。Claudeは「pandasの寛容さが実務で効く」を残し、GPTは「Polarsのstrict schemaで不整合を早期に炙り出せる」利点を対置。これは優劣ではなく設計思想の違いとして両論併記が妥当、という整理に落ちました。

統合: 単体では出ない結論へ

1ラウンドで実質収束したので、Debbyが両者を1つの結論に統合しました。2つの独立した視点が、批評を経て、次の3段階の意思決定フレームにまとまりました。

まず入力形式を疑う。同じCSVを繰り返し集計するなら、初回に一度Parquet化する。列指向・スキーマ付き・圧縮で、ライブラリ選択より大きな改善が出ることが多い(両者の合意点)。

次にエンジンを選ぶ。新規の列中心ETLならPolars(scan_csv / scan_parquet のlazy + pushdown)、数百MBまでの探索的分析やsklearn / 可視化との直結ならpandas、CSVが本当に巨大でSQLで直接集計したいならDuckDB。

最後に非技術要因で上書きする。保守性・引き継ぎ・チームスキルで最終判断する。

注意点として、性能の「数倍〜10倍」もメモリの「2〜5倍」もワークロード依存の目安であって保証ではないこと、Polars→pandasの変換は from_pandas でcloneが起き得るので途中でpandasに戻すほどPolarsの利得が目減りすること、が両者の合意として明記されました。

初回の2つの回答のどちらとも違う、より実務的で穴の少ない結論に到達しています。これが、単に2つ並べただけでは得られないものです。

並列とは別種の合成だった

ここで、前回まで抱いていた「合成 = クロスレビュー、あるいは並列」という理解が一段広がります。

サブエージェントを並列で走らせることの価値は「独立したタスクを同時に処理して速い」ことでした。並列そのものに価値があります。Debbyの /debate は「独立した2つの視点を突き合わせて、単体では出ない結論に到達する」でした。並列ではなく、異種のモデルを相互作用させることに価値があります。

つまり合成の本質は「並列できるか」ではなく「異種を混ぜて相互作用させられるか」です。サブエージェントを同じベンダー内で並列に走らせるだけならClaude Code単体でも足りますが、別ベンダーを1セッションに混ぜて、互いに批評させ、統合まで持っていく、というのはメタハーネスならではです。

モデル評価の道具としてのDebby

もう1つ、この画面はそのままモデルの挙動比較のログになっています。同じ問いへの初期回答の差、批評でどちらがどう譲歩したか、最終的にどこで一致してどこに温度差が残ったか。ClaudeはDuckDBと実測主義、GPTは数値の慎重さとpandas最新機能、といった個性が定性的に読み取れます。

2モデルのA/B比較を、手でコピペせず、しかも相互批評つきで1セッションで取れる。モデルの得意・不得意や応答スタイルの違いを日常的に見たい人には、そのまま評価の道具になります。事実の一問一答ではなく、判断が割れる設計問題を投げるほど、差がはっきり出ます。

まとめ

Debbyを通じて、合成には並列実装やクロスレビュー(相互チェック)とは別に、多モデルの議論と統合という側面があることを体験しました。同じ問いを複数ベンダーに投げ、/debate で相互批評させ、単体では出ない結論に収束させる。並列ではなく異種混合に価値がある、という合成の核心が、ここで一番はっきり見えます。

PollyとDebbyはどちらもYAML1枚のサンプルにすぎません。同じ形式で自作すれば、自分の用途に合わせたオーケストレーターを組めます。次は、この2つを土台に、制御(ポリシー)や自作エージェントへ進んでいきます。

参考リンク

はじめてのDatabricks

はじめてのDatabricks

Databricks無料トライアル

Databricks無料トライアル