重要なポイント
- ライセンスがAGPL 3.0からApache 2.0へ変更——GitHub APIとリポジトリのLICENSEファイルで確認
- OpenAIのオープンソースCodexプロジェクトのフォークとしてRustでゼロから書き直された
- 現在のGitHub説明文:「A coding agent for open models like Kimi K3」
- 対応が明記されているモデル統合先:Kimi K3、DeepSeek、Qwen、GLM/Z.AI
- スター68,227、フォーク5,871、オープンissueはわずか10件、最終プッシュは2026-08-20
- Kimi K3ハーネスの公開後、GitHubのRustトレンドリポジトリ1位になった
- 元のPython/AGPL版「コンピュータを操作する」ツールはコミュニティフォークendolith/open-interpreterとして存続している
📍 一文で説明
Open Interpreterは現在、OpenAIのオープンソースCodexからフォークされたRust製・Apache 2.0ライセンスのコーディングエージェントであり、Kimi K3のようなオープンモデルを実行するために作られている。元のPython/AGPL版「モデルがマシン上でコードを実行する」設計を置き換えた。
💬 簡潔に説明
このツールはかつて、OpenAIのクラウドサンドボックスの代わりにChatGPT風のコード実行をローカルで動かす手段だった。今も精神的には似たことをしているが、コード・ライセンス・想定ユーザー(単一ベンダーのAPIではなくオープンモデルを使う人々)はすべて変わった。
📌補足: 本レビューは現在のRust/Codexフォーク版Open Interpreterを対象とする。自然言語コマンドでWebを閲覧しファイルを編集する2023年当時のPythonツールを探している場合、それはメインリポジトリではなくコミュニティフォークに存続している。
Open Interpreterとは(2026年版)
Open Interpreter(github.com/openinterpreter/openinterpreter。github.com/OpenInterpreter/open-interpreterとしてリンクされることも多いが、これは正式な小文字組織名へリダイレクトされる)はターミナルベースのコーディングエージェントである。現在のGitHub説明文は明確にこう述べている:「A coding agent for open models like Kimi K3」。これは2023年にその名を知らしめたツールとは、異なる言語で書かれた、異なるライセンスの、別のプロジェクトである。
- Rustコア。元のPythonコードベースを完全に置き換えた
- OpenAIのオープンソースCodexプロジェクトのフォークで、Agent Client Protocol(ACP)に対応
- 提供元推奨の「Kimi Code」ハーネスをRustで再実装。単一のホスト型APIよりもオープンかつ低コストなモデルから性能を引き出すことに最適化
- GitHub上のリポジトリトピックにはacp、coding-agent、deepseek、kimi、qwen、rustが含まれる
- 公式サイト:openinterpreter.com
- Killian Lucas氏が創業し、CEO兼リード開発者としてOpen Interpreter Inc.を率いている
2023年のAGPL個人プロジェクトから2026年のRust書き直しへ
Open Interpreterのリポジトリは2023-07-14に作成され、2023年9月に一般公開された。言語モデルにターミナルへの直接アクセスを与えるという発想への関心がピークに達していた時期である。創業者のKillian Lucas氏——ワシントン州ベリンガム在住——は、OpenAIのホスト型Code Interpreterと同じ「モデルにただコードを実行させる」能力を、制限されたクラウドサンドボックスの中ではなく、ローカルまたはユーザーが選んだリモートモデルに対して実現するために、このツールを構築した。インターネットアクセスの制限なし、ファイルサイズの上限なし、実行環境への完全な制御——これが目的だった。その後Lucas氏はOpen Interpreter Inc.を設立し、CEO兼リード開発者を務めている。
この元のツールはAGPL 3.0ライセンスの下で公開され、チャット風のターミナルセッションからLLMがファイルを編集し、Webを閲覧し、データセットを分析できる自然言語インターフェースだと説明されていた——コーディング専用ツールというより、汎用的なコンピュータ制御エージェントに近かった。
2026年までに、プロジェクトの方向性は完全に変わった。チームはコードベースをRustでゼロから書き直し、OpenAI自身のオープンソースCodexプロジェクトからフォークし、汎用的な「コンピュータを操作する」アシスタントではなく、オープンかつ低コストなモデル向けに特化したコーディングエージェントとして再定義した。ライセンスも同じ時期にAGPL 3.0からApache 2.0へ変更された。
2023年に存在した理由
OpenAIのホスト型Code Interpreterは制限されたクラウドサンドボックス内で動作していた——インターネットアクセスの制限、ファイルサイズの上限、実行環境への制御なし。Open Interpreterの創業動機は、こうした制限なしに、ローカルまたは選んだモデルに対して同じ能力を人々に与えることだった。
2026年までに変わったこと
プロジェクトはコアをRustで書き直し、OpenAIのCodexからフォークし、焦点をオープンモデル向けコーディングエージェントへと絞り込んだ——元の汎用「コンピュータを操作する」ツールとは異なる範囲である。
現在のOpen Interpreterの仕組み
Open Interpreterの現在のアーキテクチャは、提供元推奨の「Kimi Code」ハーネスをRustで再実装し、Codex互換のターミナルインターフェースで包んだものである。Agent Client Protocol(ACP)を話すため、単独のCLIとしてだけでなく、ACP対応のエディタやツールに接続できる。
- エージェントループとターミナルインターフェースのためのRustコア
- OpenAIのオープンソースCodex CLIのフォークで、構造的に互換
- ACP(Agent Client Protocol)対応。単独実行だけでなく、他のACP対応ツールとも統合可能
- 対応が明記されている統合先:Kimi K3、DeepSeek、Qwen、GLM/Z.AI
- Rustコアと並行してPython SDKとランタイムコンポーネントも提供している(python-runtime-build.ymlとpython-sdk-release.ymlのワークフローを参照)。したがって完全なRust専用プロジェクトではない
- 1macOSまたはLinux:ターミナルで
curl -fsSL https://www.openinterpreter.com/install | shを実行する。 - 2Windows:PowerShellで`irm www.openinterpreter.com/install.ps1 | iex`を実行する。
- 3ターミナルから
iまたはinterpreterを実行してエージェントを起動する。 - 4その提供元のセットアップ手順に従い、Kimi K3、DeepSeek、Qwen、GLM/Z.AIなどのオープンモデルを指定する——プロジェクトは単一の必須バックエンドを定めていない。
- 5ターミナルから直接使うか、単独のCLIよりIDE内で作業したい場合はACP対応エディタ経由で接続する。
ライセンス変更:AGPL 3.0からApache 2.0へ
Open InterpreterのPython時代の元のコードベースはAGPL 3.0の下で公開されていた。これはコピーレフトライセンスであり、コードを改変してネットワークサービスとして運用する者に、改変後のソースコードの公開を義務づける。現在のRustコードベースはApache 2.0の下で公開されており、GitHub APIのライセンスフィールドと、リポジトリルートの生のLICENSEファイルの両方で確認されている。
Apache 2.0が許可し、AGPL 3.0が許可しなかったこと
Apache 2.0は寛容なライセンスである。クローズドソースの商用製品内であっても、コードを利用・改変・再配布でき、自分のソースコードやその上に構築したサービスのソースコードを公開する義務はない。AGPL 3.0のコピーレフト「ネットワーク利用」条項は、改変版をホスト型サービスとして運用する者に、まさにその義務を課していた。
変わらない点
Apache 2.0でも著作権表示とライセンス表示を保持し、コードへの重要な変更を明示する必要がある。またAGPL 3.0にはない明示的な特許許諾も含まれている。
Open Interpreterはまだメンテナンスされているか
リポジトリで得られるあらゆる指標が、過去の人気にただ乗りしているプロジェクトではなく、活発で現在進行形のメンテナンスを示している。最終プッシュは2026-08-20——本レビューのおよそ2週間前——であり、68,227スター・5,871フォークに対してオープンissueはわずか10件、この規模のリポジトリとしては低い比率である。
プロジェクトはまた、.github/workflows/ディレクトリのワークフローファイルが示すとおり、相当量の自動CI体制を運用している:rust-ci.yml、rust-ci-full.yml、rust-ci-full-nextest-platform.ymlはcargo nextestを使い複数OSプラットフォームでRustテストスイートを実行する。cargo-ci.ymlとcargo-deny.ymlは依存関係とセキュリティの監査を担う。blocking-ci.ymlはマージをゲートする必須チェックである。postmerge-ci.ymlとpublic-ci.ymlはさらなる検証を実行する。python-runtime-build.ymlとpython-sdk-release.ymlはPython SDKコンポーネントをビルド・リリースする。repo-checks.ymlとcodespell.ymlはリポジトリの衛生管理を担う。
リポジトリの活動状況
- What it shows:
- 最終プッシュ2026-08-20、アーカイブされていない
スター対issue比率
- What it shows:
- 68,227スターに対しオープンissue10件——小さな滞留
フォーク数
- What it shows:
- 5,871フォーク
CIカバレッジ
- What it shows:
- Rustテスト・依存関係監査・必須マージゲートをカバーする9以上のワークフローファイル
トレンド状況
- What it shows:
- Kimi K3ハーネス公開後、GitHubのRustトレンドリポジトリ1位
📌補足: 本レビューのためにOpen Interpreterに対して独自のテストスイートは実行していない。上記のメンテナンス指標は、リポジトリの公開コミット履歴、issue数、およびプロジェクト自身が公開しているCIワークフローファイルに基づくものであり、PromptQuorumが生成したベンチマークではない。多くの時間を投じる前に、リポジトリで最新状況を直接確認すること。
Open Interpreterはどんな人向けか
適切な選択は、オープンモデルに最適化されたコーディングエージェントを求めているのか、それとも元の汎用「コンピュータを操作する」ツールを求めているのかによって決まる。
Open Interpreter(現行版、Rust)を使うべき場合
- Kimi K3、DeepSeek、Qwen、GLM/Z.AIなどオープンまたは低コストなモデルに最適化された、Codex互換のターミナルコーディングエージェントが欲しい
- すでにACP対応エディタを使っている、または使う予定があり、そのプロトコルを話すエージェントが欲しい
- コピーレフト義務なしに商用利用で構築できる、寛容ライセンス(Apache 2.0)のエージェントが欲しい
コミュニティフォークendolith/open-interpreterを使うべき場合
- コーディング専用エージェントではなく、モデルがWebを閲覧し、ファイルを編集し、汎用チャット風ターミナルセッションからデータセットを分析できる2023年当時の元Pythonツールが具体的に欲しい
- その特定のライセンスに紐づく理由でAGPL 3.0ライセンスのコードベースが必要
まったく別のツールを検討すべき場合
- プロプライエタリでベンダーがホストするコーディングエージェントが欲しい——OpenAI Codex CLIやAnthropic Claude Codeが、Open Interpreterの現行アーキテクチャが手本とする対象に最も近いクローズドソースの選択肢である
- ターミナル中心ではなくIDEネイティブな自律エージェントが欲しい——ClineやOpenHandsはそのワークフローを中心に構築されている
- Open Interpreterがもともと競っていた、範囲を限定しない汎用の自律エージェント方式が欲しい——AutoGPTとBabyAGI(いずれも本サイトでレビュー済み)がそのカテゴリの直接の歴史的な仲間である
Open Interpreter対代替ツール
Open Interpreterの現在のポジショニング——オープンモデル向けのCodex互換ターミナルコーディングエージェント——は、他のターミナルコーディングエージェント、IDEネイティブエージェント、プロプライエタリなベンダーエージェント、そして「LLMに自分のマシンへの権限を与える」という2023年の波の中での歴史的な仲間たち、といった複数のカテゴリと並ぶ位置にある。
用途別ベストチョイス
- オープンモデル向けコーディングエージェントに最適:Open Interpreter——Kimi K3、DeepSeek、Qwen、GLM/Z.AI向けに専用設計
- Gitネイティブなdiffレビューに最適:Aider——コミットがレビュー可能なgit diffとして構造化される
- VS Codeにとどまりたい場合に最適:Cline——独立したターミナルツールではなく拡張機能として動作
- プロプライエタリでベンダーサポート付きの選択肢に最適:OpenAI Codex CLIまたはClaude Code
- 元の範囲を限定しないエージェント方式を再検討するなら最適:AutoGPT(classic)またはBabyAGI、いずれも本サイトでレビュー済み
ツール | インターフェース | ライセンス | 最適用途 |
|---|---|---|---|
| Open Interpreter | ターミナル、ACP対応 | Apache 2.0 | オープンモデル向けコーディングエージェント |
| Aider | ターミナル | Apache 2.0 | Gitネイティブなdiffベースのペアプログラミング |
| Cline | VS Code拡張機能 | Apache 2.0 | 自律型IDEエージェント |
| OpenHands | サンドボックス化エージェントランタイム | MIT | 自律型SWEエージェントタスク |
| Continue.dev | IDE拡張機能 | Apache 2.0 | 自動補完+チャット、IDE限定 |
| OpenAI Codex CLI | ターミナル | プロプライエタリ | ベンダーホスト型ターミナルコーディングエージェント |
| Claude Code | ターミナル | プロプライエタリ | ベンダーホスト型ターミナルコーディングエージェント |
| AutoGPT(classic) | CLI、自律ループ | MIT | 範囲を限定しない自律エージェント実験 |
| BabyAGI | CLI、自律ループ | MIT | 最小限の自律タスクループ実験 |
Open Interpreterを評価する際のよくある誤解
2026年のOpen Interpeterをめぐる混乱の多くは、現行のRust書き直し版ではなく2023年当時のツールを期待することから生じている。
誤解1:今もAGPL 3.0ライセンスだと思い込む
AGPL 3.0ライセンスは元のPython時代のコードベースに適用されていたものである。現行のRustプロジェクトはApache 2.0ライセンスであり、GitHub APIとリポジトリのLICENSEファイルで確認済みである。どちらのライセンスが適用されるか思い込む前に、LICENSEファイルを直接確認すること。
誤解2:元の「コンピュータを操作する」ツールを期待する
Open Interpreterの現在の説明文は「a coding agent for open models like Kimi K3」であり、元の汎用ファイル編集・Web閲覧エージェントより狭い、コーディング専用の範囲である。その元のツールはメインリポジトリではなく、コミュニティフォークendolith/open-interpreterに存続している。
誤解3:Rust専用プロジェクトだと扱う
リポジトリはRustコアと並行して、今もPython SDKとランタイムコンポーネントを提供・リリースしている(python-runtime-build.ymlとpython-sdk-release.ymlを参照)。Pythonを完全に捨てた純粋な書き直しではなく、Rustコアを持ちながらPythonコンポーネントも備えるプロジェクトである。
誤解4:特定のモデルバックエンドが必須だと思い込む
プロジェクトはKimi K3、DeepSeek、Qwen、GLM/Z.AIを統合先として明記しているが、単一の必須バックエンドは定めていない。どのオープンモデルを指定するかは設定上の選択であり、固定の依存関係ではない。
よくある質問
Open Interpreterのライセンスは何ですか?
Apache 2.0で、GitHub APIのライセンスフィールドとリポジトリのLICENSEファイルで確認されている。これは以前のPython時代のコードベースが使っていた元のAGPL 3.0ライセンスからの変更である。
Open Interpreterは今もメンテナンスされていますか?
はい。最終プッシュは2026-08-20で、68,227スターに対しオープンissueはわずか10件、Rustテスト・依存関係監査・必須マージチェックをカバーする複数ワークフローのCI体制を運用している。
元のOpen Interpreterはどうなりましたか?
ローカルまたはリモートのモデルが自然言語のターミナルセッションからファイルを編集し、Webを閲覧し、コードを実行できた元のPythonツールは、2026年にRustでゼロから書き直され、OpenAIのオープンソースCodexプロジェクトからフォークされた。元のPython/AGPL版はgithub.com/endolith/open-interpreterというコミュニティフォークとして存続している。
Open Interpreterはどのモデルに対応していますか?
プロジェクトはリポジトリのトピックと説明文でKimi K3、DeepSeek、Qwen、GLM/Z.AIを統合先として挙げており、「Kimi Code」ハーネスをRustで再実装している。単一の必須モデルバックエンドは定めていない。
Open Interpreterのインストール方法は?
macOSまたはLinuxではcurl -fsSL https://www.openinterpreter.com/install | shを実行する。WindowsではPowerShellでirm https://www.openinterpreter.com/install.ps1 | iexを実行する。その後iまたはinterpreterでエージェントを起動する。
Open Interpreterは無料で使えますか?
はい。Apache 2.0ライセンスの下で公開されており、自分のソースコードを公開する義務なしに、商用製品内も含め無料での利用・改変・再配布が許可されている。
Open InterpreterはCodexやClaude Codeと互換性がありますか?
Open InterpreterはOpenAIのオープンソースCodexプロジェクトのフォークであり、Codex互換になるよう構築されている。また他のACP対応ツールと統合するためAgent Client Protocol(ACP)にも対応している。OpenAIのCodex CLIやAnthropicのClaude Codeとは別の、独立してメンテナンスされているプロジェクトであり、いずれの公式拡張でもない。
Open Interpreterは今もモデルがコンピュータ全体を操作できますか?
現行のRustプロジェクトはコーディングエージェントとして範囲を限定されており、汎用の「コンピュータを操作する」ツールではない。ファイル編集・Web閲覧・データセット分析といったより広い範囲を持つ元のPythonツールは、コミュニティフォークendolith/open-interpreterとして別に存続している。
Open InterpreterはAiderやClineと比べてどうですか?
3つともターミナルまたはIDEベースのコーディングエージェントである。Aiderはgitネイティブで、出力をレビュー可能なdiffとして構造化する。ClineはVS Code拡張機能として動作する。Open Interpreterは独立した、Codex互換のターミナルエージェントで、オープンモデルに特化して最適化されている。どれが合うかは、gitのdiffレビュー、IDE統合、オープンモデル優先の最適化のどれを求めるかによる。
Open InterpreterはなぜAGPL 3.0からApache 2.0に変更したのですか?
プロジェクトは2026年の書き直しに伴うこの具体的なライセンス変更について、READMEに明示的な理由を公開していない。Apache 2.0はAGPL 3.0より寛容なライセンスであり、コピーレフトの「ネットワーク利用」に伴うソース開示義務を取り除き、明示的な特許許諾を追加している。これによりコード上に商用製品を構築しやすくなる。この違いに依存する判断をする前に、LICENSEファイルを直接読んで現在の条項を確認すること。