Multi-LLMペーパートレーディングボット：Claude Opus vs Geminiアーキテクチャ

ある開発者が、Alpaca上で動作する自律型ペーパートレーディングボットを公開した。これは、役割を制限し、拒否権プロセスを文書化したマルチLLMアーキテクチャを採用している。プロジェクトは約4,900行のコードで構成され、5つのPythonモジュールから成り、GitHubで完全にオープンソース化されている。

アーキテクチャ: 3つの役割と制限されたスコープ

コマンダー（人間）: 資金管理権限と投資テーゼの承認を担当。資金に影響するすべての操作には人間の承認が必要。
ストラテジスト（Gemini Pro）: 投資テーゼの評価のみにスコープを限定。実装の選択、ブローカーSDKの選定、アーキテクチャの決定は不可。
リードエンジニア（Claude Opus 4）: すべてのコードを作成。ストラテジストの指示を監査し、工学的現実に適合しない指示に対して拒否権を行使。拒否は記録される。

どの役割も単独でデプロイすることはできない。すべての不一致は「ストラテジスト法典」に記録され、現在270以上のエントリがある。法典は撤回を隠さず、後で原則が変更された場合も、両方のバージョンが日付付きで残る。

マルチLLMが効果的な理由

作成者は、単一のLLMでは自己矛盾を起こす動機が働かないと指摘する。異なるベンダーの2つのLLMが制限されたスコープと文書化された拒否権パスを持つことで、実際のエンジニアリングレビュープロセスに近い仕組みが実現する。この摩擦により、問題は事後分析ではなく設計段階で顕在化する。

具体例: ブローカーSDKのフィールド不一致

ストラテジストの指示: ブローカーSDKの Position.created_at に14日間のポジション減衰クロックを固定する。クロード（エンジニア）が dir(Position) を実際のAlpaca SDKで確認したところ、該当フィールドは存在しなかった。代わりに状態管理台帳を実装し、教義の更新理由を「ブローカーが当初の評価で想定したフィールドを実際には提供していなかった」と記録。アーキテクチャレビュー中、クロードは最初の実装が複数のブローカー呼び出しにまたがって状態ロックを保持していたため、さらにリファクタリングを行った。両方の対応が法典に記録されている。