過去1年間、多くのエンジニアリング組織が開発チームと連携する内部コーディングエージェントを構築してきました。Stripe は Minions、Ramp は Inspect、Coinbase は Cloudbot を開発しました。これらのシステムは、Slack、Linear、GitHub などの既存のワークフローに統合され、エンジニアが新しいインターフェースを採用する必要はありません。独立して開発されたものの、それらは類似したアーキテクチャパターンに収束しています：分離されたクラウドサンドボックス、厳選されたツールセット、サブエージェントオーケストレーション、開発者ワークフロー統合です。この収束は、本番エンジニアリング環境で AI エージェントを展開するための共通要件を示唆しています。
本日、Open SWE をリリースします。これは、これらのパターンをカスタマイズ可能な形で捉えたオープンソースフレームワークです。Open SWE は Deep Agents と LangGraph 上に構築され、これらの実装で観察されたコアアーキテクチャコンポーネントを提供します。あなたの組織が内部コーディングエージェントを検討している場合、これは出発点として役立ちます。
プロダクション展開からのパターン
Stripe、Ramp、Coinbase はすべて独自の内部コーディングエージェントを構築しています。Kishan Dahya 氏は、これらのコーディングエージェントが行ったさまざまなアーキテクチャ上の決定について素晴らしい記事を書いています。以下に要約し、Open SWE がそれらの次元でどのように比較されるかを詳しく見ていきます。
- 分離された実行環境：タスクは専用のクラウドサンドボックスで実行され、厳格な境界内で完全な権限を持ちます。これにより、本番システムへのミスの影響範囲を隔離し、エージェントがアクションごとに承認を求めることなくコマンドを実行できるようになります。
- 厳選されたツールセット：Stripe のエンジニアリングチームによると、エージェントは約500のツールにアクセスできますが、これらは時間の経過とともに蓄積されるのではなく、慎重に選択され維持されています。ツールの厳選は量よりも重要であるようです。
- Slack ファーストの起動：3つのシステムすべてがプライマリインターフェースとして Slack と統合し、開発者が新しいアプリケーションにコンテキストスイッチすることなく、既存のコミュニケーションワークフローで作業できるようにします。
- 起動時のリッチコンテキスト：これらのエージェントは作業を開始する前に、Linear の Issue、Slack スレッド、GitHub PR から完全なコンテキストを取得し、ツール呼び出しによる要件発見のオーバーヘッドを削減します。
- サブエージェントオーケストレーション：複雑なタスクは分解され、それぞれが独立したコンテキストと明確な責任を持つ専門の子エージェントに委任されます。
これらのアーキテクチャ上の選択は、複数のプロダクション展開で効果的であることが証明されていますが、組織は特定のコンポーネントを自身の環境と要件に適応させる必要があるでしょう。
Open SWE のアーキテクチャ
Open SWE は、同様のアーキテクチャパターンのオープンソース実装を提供します。以下は、フレームワークが観察されたパターンにどのようにマッピングされるかです。
- エージェントハーネス：Deep Agents 上に構成：Open SWE は既存のエージェントをフォークしたりゼロから構築したりせず、Deep Agents フレームワーク上に構成されています。このアプローチは、Ramp のチームが OpenCode 上に Inspect を構築した方法と同様です。構成には2つの利点があります：アップグレードパス（Deep Agents が改善された場合、カスタマイズを再構築せずに改善を組み込める）と、フォークなしのカスタマイズ（組織固有のツール、プロンプト、ワークフローをコアエージェントロジックの変更ではなく設定として維持できる）です。
- サンドボックス：分離されたクラウド環境：各タスクは独自の分離されたクラウドサンドボックスで実行されます。これは完全なシェルアクセスを持つリモート Linux 環境です。リポジトリがクローンされ、エージェントは完全な権限を受け取り、エラーはその環境内に封じ込められます。Open SWE はすぐに使える複数のサンドボックスプロバイダーをサポートしています：Modal、Daytona、Runloop、LangSmith。独自のサンドボックスバックエンドを実装することもできます。
- ツール：厳選、蓄積ではない：Open SWE は厳選されたツールセットを提供します：シェルコマンドの実行、ウェブページの取得、API 呼び出し、Git コミットと PR の作成、Linear チケットの更新、Slack スレッドへの返信、および Deep Agents の組み込みツール。小さく厳選されたツールセットは、テスト、保守、推論が容易です。組織に追加のツールが必要な場合（内部 API、カスタムデプロイシステム、専用テストフレームワーク）、明示的に追加できます。
- コンテキストエンジニアリング：AGENTS.md + ソースコンテキスト：Open SWE は2つのソースからコンテキストを収集します。AGENTS.md ファイル（リポジトリのルートに存在する場合）はサンドボックスから読み取られ、システムプロンプトに注入されます。このファイルは、すべてのエージェント実行が従うべき規約、テスト要件、アーキテクチャ上の決定、チーム固有のパターンをエンコードできます。ソースコンテキスト：完全な Linear Issue（タイトル、説明、コメント）または Slack スレッド履歴が、エージェントが開始する前に組み立てられ渡され、追加のツール呼び出しなしでタスク固有のコンテキストを提供します。この2層アプローチは、リポジトリ全体の知識とタスク固有の情報のバランスを取ります。
- オーケストレーション：サブエージェント + ミドルウェア：Open SWE のオーケストレーションは2つのメカニズムを組み合わせています。サブエージェント：Deep Agents フレームワークは task ツールを介して子エージェントを生成することをサポートします。メインエージェントは独立したサブタスクを、それぞれが独自のミドルウェアスタック、TODO リスト、ファイル操作を持つ分離されたサブエージェントに委任できます。ミドルウェア：決定論的ミドルウェアフックがエージェントループの周りで実行されます。例としては、モデル呼び出し前にフォローアップメッセージを注入する、自動的に PR を開くセーフティネット、ツールエラーの処理などがあります。このエージェント（モデル駆動）と決定論的（ミドルウェア駆動）オーケストレーションの分離は、信頼性と柔軟性のバランスに役立ちます。
- 起動：Slack、Linear、GitHub：Open SWE は Slack を主要な起動インターフェースとして採用します。Slack では、任意のスレッドでボットをメンションし、repo:owner/name 構文でリポジトリを指定できます。Linear では、任意の Issue に @openswe とコメントします。GitHub では、エージェントが作成した PR のコメントで @openswe をタグ付けすると、レビューフィードバックに対応し、同じブランチに修正をプッシュします。各起動は決定論的なスレッド ID を作成し、同じ Issue またはスレッドへのフォローアップメッセージは同じ実行中のエージェントにルーティングされます。
- 検証：プロンプト駆動 + セーフティネット：エージェントはコミット前にリンター、フォーマッター、テストを実行するように指示されます。open_pr_if_needed ミドルウェアはバックストップとして機能し、エージェントが PR を開かずに終了した場合に自動的に処理します。検証レイヤーは、決定論的 CI チェック、ビジュアル検証、レビューゲートを追加のミドルウェアとして追加することで拡張できます。
Deep Agents を選ぶ理由
Deep Agents は、このアーキテクチャを構成可能で保守可能にする基盤を提供します。コンテキスト管理：長時間実行されるコーディングタスクは大量の中間データを生成する可能性があり、Deep Agents はファイルベースのメモリを使用して大きな結果を会話履歴に保持するのではなくオフロードすることで、コンテキストオーバーフローを防ぎます。計画プリミティブ：組み込みの write_todos ツールは、複雑な作業を分解し、進捗を追跡し、新しい情報に基づいて計画を適応させる構造化された方法を提供します。サブエージェントの分離：メインエージェントが task ツールを介して子エージェントを生成すると、そのサブエージェントは独自の分離されたコンテキストを取得し、異なるサブタスクが互いの会話履歴を汚染しません。ミドルウェアフック：エージェントループの特定のポイントで決定論的ロジックを注入できます。アップグレードパス：Deep Agents はスタンドアロンライブラリとして積極的に開発されているため、コンテキスト圧縮、プロンプトキャッシュ、計画効率などの改善をカスタマイズを再構築することなく Open SWE に取り込むことができます。
組織向けのカスタマイズ
Open SWE は完成品ではなく、カスタマイズ可能な基盤として意図されています。すべての主要コンポーネントはプラグ可能です：サンドボックスプロバイダー、モデル、ツール、トリガー、システムプロンプト、ミドルウェア。カスタマイズガイドでは、各拡張ポイントを例とともに説明しています。
内部実装との比較
以下の表は、公開情報に基づいて Open SWE を Stripe（Minions）、Ramp（Inspect）、Coinbase（Cloudbot）と比較したものです。コアパターンは似ていますが、実装の詳細、内部統合、組織固有のツールに違いがあります。
はじめに
Open SWE は現在 GitHub で利用可能です。インストールガイドでは、GitHub アプリの作成、LangSmith のセットアップ、Linear/Slack/GitHub トリガー、本番デプロイについて説明しています。カスタマイズガイドでは、組織に合わせてサンドボックス、モデル、ツール、トリガー、システムプロンプト、ミドルウェアを交換する方法を示します。フレームワークは MIT ライセンスであり、フォーク、カスタマイズ、内部デプロイが可能です。その上で興味深いものを構築した場合は、ぜひお聞かせください。
複数のエンジニアリング組織が内部コーディングエージェントを本番環境に正常にデプロイしています。Open SWE は、同様のアーキテクチャパターンのオープンソース実装を提供し、さまざまなコードベースとワークフローに合わせてカスタマイズできるように設計されています。私たちはまださまざまなコンテキストで何が機能するかを学んでいる最中ですが、このフレームワークはこのアプローチを探求するチームの出発点を提供します。