Open DuetでAIエージェントを自社運用する：チーム構成と承認設計の実際

Open Duetの登場：ウェイトリスト制への自律的な回答

「Open Duet」は、名前付きのAIエージェントに役割と作業フォルダを与え、協力してタスクを進めさせるオープンソースのワークスペースだ。Apache License 2.0で公開されており、リポジトリの説明ではClaude Duetのオープンソース・セルフホスト型の代替をうたっている（Anil-matcha/open-duet · GitHub）。2026年11月3日にX上でトレンド入りした（x.com）。なお、READMEは「活発に開発中」で、チーム機能などは変化の途中にあると明記している。

Open Duetの本質は「チーム型AIエージェントをローカルまたは自社サーバー上で動かせる基盤」にある。各エージェントには名前・役割指示・専用ワークスペース・メモリを付与でき、リードエージェントがスペシャリストエージェントにタスクを委譲できる（READMEは「チームへの委譲は新機能」としている）（Anil-matcha/open-duet · GitHub）。単一のAIに全タスクを委ねるのではなく、役割分担と委譲の仕組みが設計レベルで組み込まれている点が、一般的なチャットAPIとの根本的な違いだ。

企業がAIエージェントを業務に組み込もうとする際、外部SaaSに依存するモデルでは自社データが第三者インフラを経由すること、APIキー管理の煩雑さ、ベンダーロックインのリスクが常に伴う。Open Duetはこの問題を、セルフホストという選択肢で正面から解決しようとしている。

単一のAIに全部任せる形と何が違うのかは、AIエージェントと生成AIの違いで説明しています。

関連記事AIエージェントはどう選べばいい？

自社運用の設計核心：モデル選択・役割定義・承認粒度

Open DuetをAIエージェントとして自社運用する際に最初に設計すべきは「チームリードに何を使うか」だ。GitHubのREADMEによれば、委譲役のリードエージェントにはClaudeまたはCodexが必要と明記されている（Anil-matcha/open-duet · GitHub）。Open Duet自体にはAIモデルも契約も含まれないため、使うエンジンのアカウントやAPIキーは自分で用意して管理する必要があり、これがセルフホスト構成の前提条件になる。

READMEが挙げる対応エンジンは、Claude CodeまたはCodex CLI、Gemini CLI、AntigravityまたはCursor経由のGoogle Gemini、ACP対応のコマンドラインエージェント、OpenRouter、OpenAI互換API（OllamaやLM Studioなど）で、利用できる機能はエンジンによって異なる。委譲役のリードに限ってはClaudeまたはCodexが必要になる。一般にClaudeは自然言語の推論・文書生成・複雑な指示の理解に強みを持ち、Codexはコード生成タスクに特化した設計をとる。リードエージェントに何を置くかは、チームに割り当てるタスクの性質で決まる判断になる。

自社運用の構成として核心になる3つの設定軸を以下に整理する。

• エージェントの役割定義：名前・役割指示・専用ワークスペース・メモリをエージェントごとに設定する。「リサーチ担当」「コード生成担当」「レビュー担当」のように分割することで、単一エージェントより出力の焦点を絞りやすい。
• ルーティン機能：スケジュール実行・外部トリガー・手動実行の3種類を設定できる。定型業務を自動化しつつ、例外時のみ人が介入する運用フローを構成できる。
• ユーザー承認設定：アクション前の承認を「Ask first（毎回確認）」「Accept edits（編集は自動受け入れ）」「Plan only（計画のみ生成）」から選択できる。自動化の度合いとリスク許容度に応じた調整が可能なこの設定は、業務組み込みの際の重要な判断軸になる。

自社環境でこの構成を動かすことの実質的な意味は、機密データを外部のSaaSプラットフォームに送らずに済む点にある。APIリクエストはアプリケーションコードから直接各モデルプロバイダーのエンドポイントに向かうため、エージェントのオーケストレーション層が自社サーバー上に留まる。完全なオフライン動作にはならないが、データのルーティング先を自社が把握・制御できる構成だ。

セルフホスト型 vs SaaS型：選択の判断軸

AIエージェントを自社で運用する構成が実務的に意味を持つのは、次の条件が重なる場面だ。処理対象のデータに顧客情報・社内文書・未公開の製品仕様など機密性の高いものが含まれる場合。特定のSaaSベンダーのロードマップやAPI仕様変更に業務フローを縛られたくない場合。エージェントの動作ロジックを自社のセキュリティポリシーに合わせて完全にコントロールしたい場合。これらの条件のいずれかが強く当てはまるなら、セルフホスト型を検討する根拠になる。

AIエージェント基盤の選択軸：セルフホスト型 vs SaaS型

観点	セルフホスト型（Open Duet等）	SaaS型（クラウドサービス）
データの経路	自社サーバー上でオーケストレーション	ベンダーのインフラを経由
初期構築コスト	高い（インフラ設計・設定が必要）	低い（即時利用開始が可能）
承認・制御の粒度	コードレベルで自由に設計可能	ベンダーが提供する設定範囲に限定
モデルの差し替え	APIキーの変更で対応しやすい	ベンダーの対応モデルに限定される
運用保守	自社で担う必要がある	ベンダーが担う
ベンダーロックイン	低い	高い
セキュリティ対応	脆弱性対応・アクセス制御を自社が担う	ベンダーが主体的に対応
機能のアップデート	OSSの更新を自分で追う必要がある	ベンダーが自動適用

自社の技術チームがインフラ運用を担える規模であれば、セルフホスト型はコントロールの自由度という点で明確な優位がある。一方、運用保守リソースがない組織ではSaaS型の方が現実的な選択になる。どちらが優れているという問題ではなく、組織の状況と受容できるリスクの範囲で判断すべき問題だ。ただしREADMEによれば、現在のサーバー版は実験的で、オーナー1人とペアリングした端末での利用を想定しており、複数人の組織で共用する用途には向かない。組織導入の前提としては、この点を必ず確認したい。

チーム型AIエージェントの動作を支える技術的な背景として、機械学習の基礎を事前に把握しておくと、エージェントの挙動の限界を正確に評価しやすくなる。

自社運用にあたっての注意点と現実的な限界

Open Duetを自社でAIエージェントとして運用する際には、いくつかの現実的な制約を事前に理解しておく必要がある。

開発段階であること：2026年11月2日時点でOpen Duetは活発に開発中のプロジェクトだ。OSSプロジェクトの仕様は予告なく変更される可能性があり、本番環境への組み込みには安定性の継続的な評価が前提になる。APIの破壊的変更やセキュリティ修正を追い続ける体制を社内に確保できるかどうかが、導入可否の判断軸になる。

APIコストは発生する：セルフホストはオーケストレーション層のコストを省けるが、ClaudeやCodexのAPIコストは利用量に応じて発生する。エージェントがループ状に動作したり、大量のトークンを消費するプロンプト設計になると、想定外のコストが積み上がるリスクがある。承認設定を「Plan only」から始め、段階的に自動化範囲を広げる進め方が費用管理の観点から無難だ。

セキュリティは自社責任：SaaSと異なり、脆弱性への対応・アクセス制御・ログ管理はすべて自社が担う。エージェントがファイルシステムやネットワークにアクセスできる構成を取る場合、権限の最小化（Least Privilege）を徹底しないと、誤操作や意図しないデータ削除のリスクが生じる。

効果測定の設計が必要：AIエージェントを業務に組み込む際、その効果を定量的に測る仕組みを最初から設計することが重要だ。一般財団法人プロンプト協会の調査分析（prompt.or.jp）は、AI導入の効果測定において導入前のベースライン計測と比較指標の定義が前提になると整理している。エージェント導入後に「何が変わったか分からない」状況を避けるために、計測設計を構築と並行して進めることが稟議・社内承認の根拠形成につながる。

規制・コンプライアンスの確認：処理するデータの種類によっては、個人情報保護法・金融規制・医療情報の取り扱い規制など、日本の法規制への適合確認が必要になる。オープンソースツールはコンプライアンス対応を自社で完結させる責任を伴う。

AIエージェントの自律性を高めるほど、人間による監視・承認のポイントを意図的に設計することの重要性が増す。Open Duetの承認設定機能はそのための手段のひとつだが、設定で解決できない判断については、エスカレーションフローを業務プロセスとして別途定義しておく必要がある。

明日から試せる実務的な一歩

Open Duetを検討するにあたり、最も現実的な出発点は「小さく試して評価する」構成だ。本番データを使わず、社内の非機密な定型タスク（ドキュメントの要約・コードレビューの補助・定期レポートの下書き生成など）を対象に、まず2エージェント構成で動作を確認する。承認設定は「Ask first」から始め、各アクションの前に人間が確認できる状態を維持することが初期段階では重要だ。

具体的な手順の起点としては、GitHubリポジトリのREADMEが現時点での一次情報となる（Anil-matcha/open-duet · GitHub）。開発が活発なため、記事執筆時点の情報と実際のリポジトリの内容が異なる可能性がある。最新のREADMEとIssueを確認した上で構成を判断することを強く推奨する。

PoC（概念実証）を経て、効果が確認できたタスクから段階的に自動化範囲を広げる。その際、前述の効果測定設計を先に固めておくことで、導入判断の根拠を定量的に積み上げられる。「使ってみたら便利だった」という属人的な評価ではなく、稟議や社内承認に耐える根拠を揃えることが、組織への本格展開を可能にする前提条件だ。

エージェントが自律的な判断に活用する強化学習の仕組みを理解しておくと、エージェントの挙動設計と限界の評価がより具体的になる（強化学習の解説）。

---

参考文献

• x.com　https://x.com/i/trending/2117293628175323619
• Anil-matcha/open-duet · GitHub　https://github.com/Anil-matcha/open-duet
• prompt.or.jp　https://prompt.or.jp/blog/measuring-ai-implementation-im-c8p