- Stripe、Ramp、Coinbase など主要エンジニアリング組織が独自に構築した社内コーディングエージェントは、類似したアーキテクチャパターンへと収束しており、それをオープンソースとして実装したフレームワークが Open SWE
- Deep Agents と LangGraph 上に構築されており、隔離されたクラウドサンドボックス・キュレーションされたツールセット・サブエージェントのオーケストレーション・開発者ワークフロー統合などの主要コンポーネントを提供
- 既存エージェントを fork せず、コンポジション方式で構築することで、基盤フレームワークのアップグレードと組織ごとのカスタマイズを同時に維持可能
- サンドボックスプロバイダー・モデル・ツール・トリガー・システムプロンプト・ミドルウェアなど、すべての主要コンポーネントをプラグイン型で置き換え可能
- 社内コーディングエージェント導入を検討するチームに、本番で検証済みのパターンに基づく出発点を MIT ライセンスで提供
本番導入で見つかった共通パターン
- Stripe の Minions、Ramp の Inspect、Coinbase の Cloudbot などのコーディングエージェントは、独立して開発されたにもかかわらず、似たアーキテクチャ上の意思決定へと収束
- 隔離された実行環境: 各タスクは専用のクラウドサンドボックスで実行され、厳密な境界の中でフル権限を付与。本番システムへのミスの影響範囲を隔離しつつ、各アクションごとに承認プロンプトなしでコマンド実行が可能
- キュレーションされたツールセット: Stripe のエンジニアリングチームによれば、エージェントは約 500 個のツールにアクセスするが、それは時間とともに蓄積したものではなく、慎重に選定・維持管理されたもの。ツール数よりも キュレーションの方が重要
- Slack 優先の呼び出し: 3 つのシステムはいずれも Slack を基本インターフェースとして統合しており、開発者は新しいアプリへコンテキストスイッチすることなく、既存のコミュニケーションワークフローから利用できる
- 開始時に豊富なコンテキスト: Linear の issue、Slack スレッド、GitHub PR から完全なコンテキストを取り込み、タスク開始前に提供することで、ツール呼び出しによる要件発見のオーバーヘッドを削減
- サブエージェントのオーケストレーション: 複雑なタスクを分解し、それぞれ独立したコンテキストと集中した責務を持つ専門的な子エージェントに委譲
Open SWE アーキテクチャ
-
1. エージェントハーネス: Deep Agents ベースのコンポジション
- 既存エージェントを fork したりゼロから構築したりするのではなく、Deep Agents フレームワーク上でコンポジションする方式。Ramp チームが OpenCode 上に Inspect を構築したアプローチに近い
- コンポジションの 2 つの利点:
- アップグレード経路: Deep Agents が改善されたとき（より良いコンテキスト管理、効率的な計画、最適化されたトークン利用）、カスタマイズを作り直すことなく改善を取り込める
- fork なしのカスタマイズ: 組織固有のツール・プロンプト・ワークフローを、コアエージェントロジックの変更ではなく設定として維持できる
- Deep Agents が提供するインフラ:
write_todos による組み込み計画、ファイルベースのコンテキスト管理、task ツールによるネイティブなサブエージェント生成、決定論的オーケストレーションのための ミドルウェアフック
-
2. サンドボックス: 隔離されたクラウド環境
- 各タスクは専用の隔離クラウドサンドボックスで実行され、フルシェルアクセス可能なリモート Linux 環境を利用
- リポジトリをクローンし、エージェントにフル権限を付与。エラーはその環境内に隔離される
- 既定でサポートされる サンドボックスプロバイダー: Modal、Daytona、Runloop、LangSmith。独自のサンドボックスバックエンド実装も可能
- 主な動作:
- 各会話スレッドごとに 永続的なサンドボックス を割り当て、後続メッセージでも再利用
- サンドボックスが利用不能になった場合は自動で再生成
- 複数のタスクをそれぞれ独自のサンドボックスで 並列実行
-
3. ツール: 蓄積ではなくキュレーション
- Open SWE は、絞り込まれたツールセットとともに、Deep Agents の組み込みツール（
read_file, write_file, edit_file, ls, glob, grep, write_todos, task）を提供
- 小さくキュレーションされたツールセットの方が、テスト・保守・推論がしやすい。組織内の追加ツール（内部 API、カスタムデプロイシステム、特殊なテストフレームワーク）は 明示的に追加 可能
-
4. コンテキストエンジニアリング: AGENTS.md + ソースコンテキスト
- 2 つのソースからコンテキストを収集:
- AGENTS.md ファイル: リポジトリルートにあればサンドボックスで読み取り、システムプロンプトに注入。規約、テスト要件、アーキテクチャ上の判断、チーム固有のパターンなどをエンコード
- ソースコンテキスト: Linear issue 全体（タイトル、説明、コメント）または Slack スレッド履歴を組み合わせて、エージェント開始前に渡し、追加のツール呼び出しなしでタスク固有コンテキストを提供
- リポジトリ全体の知識とタスク固有情報をバランスよく組み合わせる 二層アプローチ
-
5. オーケストレーション: サブエージェント + ミドルウェア
- 2 つのメカニズムを組み合わせ:
- サブエージェント:
task ツールで子エージェントを生成。メインエージェントは独立したサブタスクを、それぞれ独自のミドルウェアスタック・Todo リスト・ファイル操作を持つ隔離サブエージェントに委譲
- ミドルウェア: エージェントループの周辺で実行される決定論的フック
check_message_queue_before_model: エージェント実行中に到着した後続メッセージ（Linear コメント、Slack メッセージ）を次のモデル呼び出し前に注入。エージェント作業中にユーザーが追加入力できるopen_pr_if_needed: エージェントが PR 作成を完了できなかった場合、自動でコミット・PR 作成を行う セーフティネットToolErrorMiddleware: ツールエラーを適切に捕捉・処理
- エージェント的（モデル駆動）オーケストレーションと決定論的（ミドルウェア駆動）オーケストレーションを分離することで、信頼性と柔軟性のバランスを確保
-
6. 呼び出し: Slack、Linear、GitHub
- Slack: スレッドでボットをメンション。
repo:owner/name 構文で対象リポジトリを指定。エージェントはスレッド内で状態更新と PR リンクを返信
- Linear: issue に
@openswe コメント。エージェントは issue 全体のコンテキストを読み取り、👀 で確認した後、結果をコメントとして投稿
- GitHub: エージェントが作成した PR のコメントで
@openswe タグを付けてレビュー フィードバックを処理し、同じブランチに修正を push
- 各呼び出しは 決定論的なスレッド ID を生成し、同じ issue やスレッドの後続メッセージが同一の実行中エージェントへルーティングされる
-
7. 検証: プロンプトベース + セーフティネット
- エージェントに対し、コミット前にリンター・フォーマッター・テストを実行するよう指示
open_pr_if_needed ミドルウェアがバックストップとして機能し、エージェントが PR を開かずに終了した場合はミドルウェアが自動処理- 決定論的な CI チェック、ビジュアル検証、レビューゲートは 追加ミドルウェアとして拡張 可能
Deep Agents を使う理由
- コンテキスト管理: 長時間実行されるコーディングタスクが生成する大量の中間データ（ファイル内容、コマンド出力、検索結果）をファイルベースメモリへオフロードし、会話履歴にすべてを保持しない。大規模コードベースでの コンテキストオーバーフロー防止 に有効
- 計画の基本要素: 組み込みの
write_todos ツールで複雑なタスクの分解、進捗追跡、新しい情報に応じた計画適応を構造化。長期間にわたる マルチステップタスクに特に有用
- サブエージェントの隔離: メインエージェントが
task ツールで子エージェントを生成する際に隔離コンテキストを付与。異なるサブタスクの会話履歴が汚染されず、複雑な作業で より明確な推論 が可能
- ミドルウェアフック: エージェントループの特定箇所に決定論的ロジックを注入可能。メッセージ注入や自動 PR 作成など、確実に実行されるべき動作 の実装に活用
- アップグレード経路: Deep Agents は独立ライブラリとして活発に開発されているため、コンテキスト圧縮・プロンプトキャッシュ・計画効率・サブエージェントオーケストレーションの改善を、カスタマイズの再構築なしで Open SWE に取り込める
組織ごとのカスタマイズ
- Open SWE は完成品ではなく、カスタマイズ可能な基盤として設計されている。主要コンポーネントはすべてプラグイン型:
- サンドボックスプロバイダー: Modal、Daytona、Runloop、LangSmith の間で差し替え可能。内部インフラ要件に合う独自サンドボックスバックエンドも実装可能
- モデル: すべての LLM プロバイダーを利用可能。デフォルトは Claude Opus 4 で、サブタスクごとに異なるモデルを設定可能
- ツール: 内部 API・デプロイシステム・テストフレームワーク・監視プラットフォーム向けツールを追加可能。不要なツールは削除可能
- トリガー: Slack・Linear・GitHub 統合ロジックを変更可能。メール・Webhook・カスタム UI など新しいトリガー面も追加可能
- システムプロンプト: 既定プロンプトと AGENTS.md ファイル反映ロジックをカスタマイズ可能。組織固有のガイドライン・制約・規約を追加できる
- ミドルウェア: 検証・承認ゲート・ロギング・安全チェックのための独自ミドルウェアフックを追加可能
内部実装との比較
- Stripe、Ramp、Coinbase の内部システムと公開情報に基づいて比較すると、コアパターンは類似 している
- 違いは実装の細部、内部統合、組織固有ツールにあり、これはフレームワークを別環境へ適応させる際に想定される差異
はじめに
2件のコメント
みんな考えることはだいたい似ていますね……本当に春秋戦国時代ですね。
もうどこも社内向けコーディングエージェントを作っているから、そのためのフレームワークまで作ってしまったんですね。みんな動きが速い。
これをそのまま使うというより、内部で参考にした各社のパターンを見ておくのも良さそうです