Open Interpreter：オープンソースAIコーディングエージェントガイド

別のモデル向けに作られたコーディングエージェントの中でオープンウェイトモデルを動かしたことがあるなら、それが最善策ではないとご存じでしょう。

たいてい、モデルはツールのスキーマを誤読し、止めるまで同じ失敗したコマンドを繰り返します。元のモデルに戻すと、同じタスクが問題なく進むことがよくあります。原因は多くの場合モデルそのものではなく、その周囲のエージェントハーネスです。プロンプトやツール形式が別の誰か向けに調整されているからです。

Open Interpreterは、Claude CodeやKimi Codeのように、各モデルが調整されたハーネスをエミュレートすることでこれを解決します。ターミナルから実行できるオープンソースのAIコーディングエージェントで、現在版はOpenAIのCodexを基にしたRustプロジェクトです。以前のPython製コンピュータアシスタントとは別物です。

この記事では、インストール、モデルとハーネスの設定、ハンズオンのコーディングワークフロー、そしてOpen InterpreterとClaude Code、OpenCode、Codexの比較を順に解説します。

AIエージェントが初めてですか？当社のIntroduction to AI Agentsコースに登録し、午後のひとときで基礎を学んでください。

Open Interpreterとは？

Open Interpreterは、AIモデルにあなたのプロジェクトと、開発者が使うツールへのアクセスを与えます。

やることを英語で説明するだけで、エージェントがコードに取り組みます。次のことが可能です。

• ファイル: コードを読み取り、編集します
• コマンド: シェルコマンド、スクリプト、ビルド手順を実行します
• リポジトリ: Gitに対応しており、プロジェクト履歴の確認や変更差分の表示ができます
• 開発ツール: テストランナーやリンターを使って自分の作業を検証します
• マルチステップタスク: 初期調査からテスト済みの修正まで、これらのアクションを連鎖させます

本プロジェクトはApache 2.0ライセンスのオープンソースです。特定のモデルプロバイダに限定されておらず、ホステッドモデル、オープンウェイトモデル、ローカル実行モデルを接続できます。

メインリポジトリは2026年9月時点でGitHubスターが68,000超です。

Open Interpreterの仕組み

Open Interpreterは次のループで動作します:

1. タスク: 望むことを記述します（例：「失敗しているテストを直して」）
2. 調査: モデルがプロジェクト構造と関連ファイルを読みます
3. 計画: タスクに必要なツールやアクションを決定します
4. 編集: ファイルを読み取り、変更します
5. コマンド: テストスイートなどのシェルコマンドを実行します
6. 評価: 変更が有効か出力を確認します
7. 反復: タスクが完了するかあなたの入力が必要になるまで、手順2〜6を繰り返します

権限設定によっては、一部の手順は事前承認が必要です。セキュリティの章で解説します。

より視覚的な概要はこちらです:

Open Interpreterの動作

覚えておきたいのは、モデルと直接会話するわけではないという点です。Open Interpreterは、アクティブなハーネスのプロンプトとツール定義で整形したタスクをモデルに送信します。モデルはツール呼び出しを要求し、Open Interpreterがあなたのコードベースに対してそれらを実行します。その結果が次のステップのためにモデルへ戻されます。

モデルとハーネスは別レイヤーなので、残りのセットアップに手を加えずどちらか一方を変更できます。

Open Interpreterのインストール方法

Open Interpreterはスタンドアロンのバイナリとしてインストールされます。Pythonやpipは不要です。

古いブログ記事でpip install open-interpreterを実行するよう指示されている場合、それはレガシーのPython版を指しています。本記事で扱うRust製のコーディングエージェントはそのコマンドでは入りません。

また、マシンにGitを入れておくとよいでしょう。GitがなくてもOpen Interpreterは動作しますが、Gitがあるとリポジトリを意識したセッションや差分表示が可能になります。

macOSとLinux

ターミナルからインストールスクリプトを実行します:

curl -fsSL https://www.openinterpreter.com/install | sh

スクリプトはプラットフォームに合ったリリースをダウンロードし、~/.local/binにinterpreterコマンドを配置します。

Windows

PowerShellを開いて次を実行します:

irm https://www.openinterpreter.com/install.ps1 | iex

Linux風のセットアップを好むならWSLもサポートされています。その場合はWSLのターミナル内でmacOS/Linux向けのコマンドを実行してください。

インストールの確認

ターミナルを再起動して新しいPATHを反映させ、バージョンを確認します:

interpreter --version

バージョン番号が表示されればインストール成功です。

Open Interpreterのバージョン確認

インタラクティブセッションを起動

任意のディレクトリからセッションを開始します:

interpreter

ショートエイリアスのiでも同じコマンドを実行できます。

Open InterpreterはターミナルUIを開き、英語でタスクを説明できます。初回起動時はモデルプロバイダの接続を求められます。次のセクションではOllama経由でローカルモデルを使うので、今はスキップして構いません。

Open Interpreterのインタラクティブセッション

セッションを終了するには/exitと入力します。

Open Interpreterの使い方

コーディングエージェントを理解する最速の方法は、タスクを与えて挙動を見ることです。

このセクション全体では小さな習慣トラッカーのプロジェクトを使います。関数が1つ、テストファイルが1つ、そしてバグが1つあります。

デモプロジェクトを作成

このプロジェクトは、ある習慣における連続実行日の最長ストリークを計算します。たとえば連続して運動した日数を数えます。

まずプロジェクトフォルダと仮想環境を用意します:

mkdir habit-tracker && cd habit-tracker
python3 -m venv .venv
source .venv/bin/activate
pip install pytest

次のコードでhabits.pyを作成します:

def longest_streak(dates):
    """Return the longest run of consecutive days.

    Each date is a 'YYYY-MM-DD' string, for example "2026-03-14".
    Duplicate dates count once.
    """
    days = sorted(set(dates))
    if not days:
        return 0

    longest = current = 1
    for previous, today in zip(days, days[1:]):
        if int(today[8:10]) - int(previous[8:10]) == 1:
            current += 1
            longest = max(longest, current)
        else:
            current = 1
    return longest

続いてtest_habits.pyを作成します:

from habits import longest_streak


def test_streak_within_one_month():
    dates = ["2026-03-01", "2026-03-02", "2026-03-03", "2026-03-10"]
    assert longest_streak(dates) == 3


def test_duplicate_dates_count_once():
    dates = ["2026-03-01", "2026-03-01", "2026-03-02"]
    assert longest_streak(dates) == 2


def test_streak_across_month_boundary():
    dates = ["2026-01-30", "2026-01-31", "2026-02-01"]
    assert longest_streak(dates) == 3

関数にはバグがあります。どこかは指摘しません。見つけるのはエージェントの仕事です。

.gitignoreを追加し、仮想環境やキャッシュをリポジトリから除外します:

.venv/
__pycache__/
.pytest_cache/

ではコミットしましょう:

git init
git add .
git commit -m "Initial commit"

このコミットでクリーンな出発点ができます。後で、エージェントが何を変えたか正確に確認できます。

テストを実行してバグを確認します:

python -m pytest

習慣トラッカーのテスト結果

2つは通り、1つは失敗しています。これがOpen Interpreterが解決すべき問題です。

ローカルモデルでOpen Interpreterを起動

まずOllamaをインストールして起動してください。ツール呼び出しをサポートするモデルが必要なので、次を取得します:

ollama pull qwen3-coder:30b

次にプロジェクトフォルダからOpen Interpreterを起動します。同じターミナルを使用し、仮想環境に入っているpytestをエージェントが使えるようにします:

interpreter --oss --local-provider ollama -m qwen3-coder:30b

各フラグの意味は次の通りです:

• --oss: ローカルのオープンソースプロバイダを使用

• --local-provider ollama: LM StudioではなくOllamaを選択

• -m qwen3-coder:30b: この実行で使うモデルを指定

/statusを実行すると、アクティブなプロバイダ、モデル、サンドボックスモード、承認ポリシーを確認できます。

ローカルのOllamaモデルでのOpen Interpreterセッション

バグの調査を依頼

まだ編集はさせたくありません。まず診断を依頼します:

The tests in this project are failing. Find the cause and explain how you'd fix it. Don't edit any files yet.

多くの場合、エージェントは回答する前にファイルを読み、テストを実行します。コマンドはサンドボックス内で動作し、サンドボックス以上のアクセスが必要な場合は先に承認を求めます。

Open Interpreterの出力

提案された修正を確認

承認する前に説明文を読みましょう。

正しい診断は、関数が「日」だけを比較しているため、月替わりでストリークが途切れるというものです。適切な修正は、Pythonのdatetimeモジュールのdate.fromisoformat()などを使い、日付全体で比較することです。

診断が誤っている場合は、エージェントがコードを編集する前に同じセッション内で修正してください。

Open Interpreterの修正提案

ファイル編集とテスト実行を任せる

計画に問題がなければ、修正を実装させます:

Apply the fix to habits.py, then run the tests.

エージェントはファイルを編集し、pytestを再実行します。3つすべてのテストが通ることを確認します。

修正後は全テスト合格

差分を確認

テストが通ったからといって、必ずしもバグが解消されたとは限りません。テスト側がバグを回避するよう変更された可能性もあります。コードの確認は必要です。

/diffをセッション内で実行し、作業ツリーの変更を確認します。終了後にgit diffを実行しても構いません。

Open Interpreterが行った変更の差分

正確な差分はモデルによって変わるため、上の例と行単位で一致しないかもしれません。変更が気に入ればコミットし、そうでなければ元のファイルを復元します:

git restore habits.py

要はこういうことです。問題を説明すると、エージェントが調査・修正し、あなたは変更がコードに取り込まれる前にすべてをレビューします。

Open Interpreterのモデル

Open Interpreterでは、モデルは持ち込みです。

すべてのリクエストは次の3レイヤーを通過します:

リクエストのレイヤー

接続できるものは次の通りです:

• ホステッドモデル: OpenAIやAnthropicなどの商用モデル（サインインまたはAPIキー）
• API経由のオープンウェイトモデル: Kimi K3やDeepSeekなど（自社プロバイダまたはOpenRouterのようなゲートウェイ経由）
• ローカルモデル: OllamaまたはLM Studio経由で手元ハードウェア上で動かすモデル（どちらもAPIキー不要の内蔵プロバイダ）

プロバイダ一覧は公開モデルカタログから生成され、ツール呼び出し対応のモデルのみが残ります。期待するモデルが見当たらない場合、たいていはこの要件が理由です。

ollama-cloudに注意してください。これは別のホステッドプロバイダで、リクエストはマシンの外に出ます。ローカル実行なのは内蔵のollamaだけです。

モデルの切り替え

モデルは3つのレベルで切り替えられます:

• セッション内: /modelでプロバイダ、モデル、推論努力度を選択

• 単発の実行: 先ほどのセクションのように-mフラグで指定

• デフォルト設定: 設定ファイルに記載

/statusで現在有効なプロバイダとモデルをいつでも確認できます。

プロバイダ設定

Open Interpreterは~/.openinterpreter/config.tomlから設定を読み込みます。前セクションのOllama設定をデフォルトにするには次の2行を追加します:

model_provider = "ollama"
model = "qwen3-coder:30b"

これでinterpreterはこのモデルで起動し、フラグは不要になります。

ホステッドプロバイダは環境変数からAPIキーを読みます。例えばDeepSeekはDEEPSEEK_API_KEYを参照します:

export DEEPSEEK_API_KEY="your-api-key"

OpenAI互換エンドポイントをカスタムプロバイダとして追加することもできます:

model_provider = "my-provider"
model = "my-model"

[model_providers.my-provider]
name = "My Provider"
base_url = "https://api.example.com/v1"
env_key = "MY_PROVIDER_API_KEY"
wire_api = "chat"

wire_apiはエンドポイントが期待するリクエスト形式を指定します。OpenAI互換のChat Completionsならchat、OpenAI Responses APIならresponses、Anthropic系のエンドポイントならmessagesを使います。

信頼済みプロジェクトは、プロジェクト固有の.openinterpreter/config.tomlを持つこともでき、ユーザー設定を上書きします。コマンドラインフラグはその両方を上書きします。どの値が優先されるか不明な場合は、/debug-configで有効な設定とその由来を確認してください。

モデルとハーネスが両方重要な理由

モデルはエージェントがあなたのコードをどれだけ理解できるかを左右します。ハーネスはモデルがタスクとツールをどう認識するかを決めます。

どちらも必要です。優れたモデルでも、ミスマッチなハーネスではツール呼び出しが不正になり、結果の解釈も誤ります。逆に、良いハーネスでもコード理解が弱いモデルを補うことはできません。

そのためOpen Interpreterは、モデル選択時にハーネスも選びます。例えば:

• Claude系モデルはclaude-codeハーネス

• Kimi系はkimi-code

• Qwen系はqwen-code

• DeepSeek系はclaude-code-bare

その他のモデルファミリでは、/harnessでハーネスを自分で選べます。

ここで覚えておくべきは、結果が弱いからといって必ずしもモデルが弱いとは限らないことです。モデルを変える前に、同じモデルで別のハーネスを試してください。詳しくは次のセクションで扱います。

Open Interpreterのエージェントハーネス

ハーネスのエミュレーションこそ、現行版Open Interpreterの存在理由です。

エージェントハーネスは、モデルをエージェントに変えるための周辺すべてを指します。含まれるのは:

• 指示文: 振る舞いやツール使用のタイミングなどを定めるシステムプロンプト
• ツール: ファイルの読み書きやコマンド実行など、モデルが取れる行動と各呼び出しの厳密なスキーマ
• 対話パターン: ツール呼び出しと結果を会話にどう挿入するか、どの時点で入力を求めてループを止めるか
• 実行環境: コマンドの実行場所、アクセス可能範囲、承認が必要な操作

平たく言えば、ハーネスはモデルがタスクをどう捉え、意思決定がどう行動に変わるかを決めます。

Open Interpreterには組み込みのハーネスモードがいくつかあります。よく使うのは次の通りです:

• native: Codex由来のOpen Interpreter独自ハーネス

• claude-code: AnthropicのClaude Codeのプロンプトとツール面をエミュレート

• kimi-code: MoonshotがKimiモデル向けに推奨するKimi CodeハーネスのRust再実装

• qwen-code: AlibabaのQwen Code CLIをQwenモデル向けにエミュレート

• swe-agent: GitHubのIssue解決向けに作られた研究用エージェントSWE-agentをエミュレート

全リストにはclaude-code-bare、kimi-cli、deepseek-tui、zcode、minimalなどの派生もあります。手元のバージョンで使えるものはセッション内で/harnessを実行して確認してください。

ハーネスはセッション中に/harnessで切り替えられ、~/.openinterpreter/config.tomlでデフォルトを設定できます:

harness = "kimi-code"
harness_guidance = true

harness_guidanceは、ハーネスが許す場合に信頼性ガイダンスを追加します。厳密なエミュレーションを望むならfalseにしてください。harnessを設定しない場合、前節で見たようにモデルファミリに基づきOpen Interpreterが選択します。

ハーネスが重要な理由

多くのベンダは、特定のエージェント構成でコーディングモデルをチューニングし、それに合う推奨ハーネスを公開します。

モデルはそのハーネスに慣れます。プロンプトスタイル、ツール名、ファイル編集形式、ツール結果の返り方を学習します。

たとえば置換編集に最適化されたモデルを、フルパッチを期待するハーネスで動かすとします。モデルは変更内容を分かっていても、常に誤った形式で記述し続けます。エージェントループは進捗なくトークンを消費します。

ツール結果も同様です。モデルが見たことのない形式で結果が返ると誤読します。ターンごとにハーネスがモデルの推論を削除する場合、思考するモデルは自分の計画を見失います。

つまり、重みを変えずとも同じモデルがエージェントによって良くも悪くも見えるのです。コーディングベンチマークが各ランで使用ハーネスを明記するのもこのためです。

先端モデルは不慣れなハーネスから回復しがちですが、小型・低コストモデルは難しいことが多いです。Open Interpreterはすべてのモデルを1つの形式に押し込むのではなく、モデルに合わせて形式を変えます。

デモプロジェクトで自分でも試せます。git restore habits.pyで元に戻し、/harnessでハーネスを切り替え、同じプロンプトを再度与えてください。ステップ数や編集形式の違いを比べてみましょう。

Open Interpreterの主な機能

この記事で既に多くを見てきました。日々の開発での効用をあらためて整理します。

リポジトリ対応のコーディング

Open InterpreterはGitリポジトリ内で動作し、プロジェクト構造を読み取り、変更履歴を追跡します。

ここで役立つスラッシュコマンドが2つあります。/diffは作業ツリーの変更を表示し、/reviewはコミット前のバグやリグレッションをエージェントにチェックさせます。セッションを開かずに同じレビューを実行することも可能です:

interpreter exec review --uncommitted

セッションも保存されます。作業途中で止めても、interpreter resume --lastで中断地点から再開できます。

ターミナルとコマンド実行

エージェントはテストスイート、リンター、ビルドスクリプト、パッケージマネージャなど、あなたが使うのと同じコマンドを実行します。macOS、Linux、Windowsでネイティブのサンドボックス内で動作します。

長時間のコマンドはバックグラウンド実行できます。/psで一覧し、/stopで停止します。

スクリプトやCIでは、interpreter execでインタラクティブUIなしにタスクを実行できます:

interpreter exec "fix the failing test"

モデルの柔軟性

/modelでいつでもプロバイダとモデルを切り替えられます。切り替え後も設定、AGENTS.md、スキルは有効です。

プロフィールが役立ちます。日常作業は安価なモデル、コードレビューは強力なモデル、のように使い分ける設定が可能です:

[profiles.review]
model_provider = "deepseek"
model = "deepseek-v4-pro"
sandbox_mode = "read-only"

必要に応じてinterpreter --profile reviewで起動します。

ハーネスの切り替え

/harnessはモデルを変えずに、タスクの見え方を変えます。ツール呼び出しでモデルが苦戦するとき、より大きなモデルに移る前にまず試すべき手段です。

MCPとツール

Model Context Protocol（MCP）は、もともと想定されていないツール（ドキュメントサーバやデータベースなど）へエージェントを接続します。設定にサーバを追加します:

[mcp_servers.docs]
command = "npx"
args = ["-y", "your-docs-mcp-server"]
default_tools_approval_mode = "prompt"

/mcpで設定済みサーバとそのツールを確認できます。default_tools_approval_modeにより、そのサーバのツール使用時に確認を求めます。

逆方向も可能です。interpreter mcp-serverでOpen InterpreterをMCPサーバとして公開し、interpreter acpでAgent Client Protocol対応エディタ内で動作させられます。これはエディタとコーディングエージェントを接続するオープン規格です。

スキルとAGENTS.md

AGENTS.mdは、リポジトリに置くMarkdownファイルで、エージェントが各タスクで読むプロジェクト規約です。習慣トラッカーなら次のようになります:

# AGENTS.md
- Run the tests with python -m pytest before you finish a task.
- Use the Python standard library only. Don't add new dependencies.

/initを実行すると、エージェントが初版を書いてくれます。

スキルは再利用可能なワークフローで、プロジェクト内.agents/skillsまたはユーザー用~/.agents/skillsのフォルダとして配置します。タスクが一致すると自動でスキルを拾います。/skillsで利用可能なものを確認します。

いずれも共通フォーマットなので、対応する他のコーディングエージェントでも同じファイルが使えます。Open Interpreterはフックにも対応し、セッションの所定ポイントであなたのコマンドを実行できます。/hooksでレビューして信頼設定を行います。

サンドボックスと承認

エージェントができることは、次の2つの設定で制御します:

• サンドボックスモード: read-only、workspace-write、danger-full-access

• 承認ポリシー: untrusted、on-request、never

サンドボックスが可能範囲を、承認ポリシーが確認のタイミングを決めます。workspace-writeとon-requestなら、エージェントはプロジェクトの編集やテスト実行ができますが、それ以上のアクセスが必要なときは事前に確認します。

両者は/permissionsや-s、-aフラグで変更できます。両方を迂回する--yoloフラグもあり、ドキュメントでは危険と明記されています。詳細はセキュリティの章で扱います。

ローカルおよびオープンモデル向けのOpen Interpreter

Open Interpreterは、低コストモデル向けに構築されたコーディングエージェントを自称しています。

大手の専有コーディングエージェントは自社モデル中心の設計です。Open Interpreterは、専有モデル、ホステッドのオープンウェイトモデル、ローカルモデルのいずれでも1つのエージェントで扱えます。

オープンウェイトモデル

Kimi、DeepSeek、GLM、Qwenのようなオープンウェイトモデルは重みが公開されています。サードパーティプロバイダ経由でも、自前ハードウェアでも利用可能です。

利点は2つ。ホステッドのオープンウェイトモデルは、先端の専有モデルよりトークン単価が低いことが多い点。そして同じモデルが重みのある場所ならどこでも動くため、ホストに縛られない点です。

Open InterpreterにはKimi K3、DeepSeek、GLM向けの専用プロバイダガイドがあり、これらのモデルファミリに合うハーネスを自動選択します。

ローカル推論

OllamaとLM Studioは内蔵プロバイダで、APIキーやトークン課金なしに手元マシンでモデルを動かせます。

代わりに必要なのはハードウェアです。MacBook Pro M1 Max（ユニファイドメモリ64GB）でdevstral-small-2を試したところ、モデルだけで26GBを消費しました。Ollamaのデフォルトのコンテキスト長はエージェントループには小さすぎ、128kトークンではメモリ使用量が増減を繰り返し、セッションが停滞しました。

コーディングエージェントには大きなコンテキストウィンドウが必要です。システムプロンプト、ツール定義、ファイル内容、コマンド出力をすべて収める必要があるからです。OllamaはCodex系エージェントに少なくとも64kトークンを推奨しています。コンテキストを大きくすると、モデル本体に加えてメモリ使用量がさらに増えます。

コストとプライバシー

Open Interpreter自体はあなたのマシンで動きますが、モデルは必ずしもそうではありません。

コードの行き先はプロバイダ次第です:

• ローカルプロバイダ: プロンプト、ファイル内容、コマンド出力はマシン外に出ません
• ホステッドプロバイダ: モデルがオープンウェイトでも、それらはプロバイダのサーバへ送られます

設定、セッション、ログはプロバイダに関係なく~/.openinterpreter以下にローカル保存されます。

より細かな制御が必要なら、自前の推論サーバを指すカスタムプロバイダを追加できます。OpenAI互換APIのサーバであれば動作します。例えば自社GPUでvLLMをデプロイすれば、インフラは自社管理のホステッド構成にできます。

ツール使用のパフォーマンス

オープンモデルのツール呼び出し能力には差があります。不正な呼び出し、ループ、早期停止、コマンド出力の無視といった形で弱さが現れます。

適切なハーネスは助けになりますが、マルチステップの計画ができないモデルそのものは救えません。特に小型ローカルモデルで問題が顕著です。

新しいモデルを実プロジェクトに適用する前に、この記事の習慣トラッカーのような小さなリポジトリで試してください。弱点が見えたら、まず大きなモデルに行く前に別のハーネスを試しましょう。

選択肢を手短にまとめると次の通りです:

ローカル／オープンモデル向けのOpen Interpreterの選択肢

Open Interpreterと他のAIコーディングエージェントの比較

Open Interpreterは他のターミナル系コーディングエージェントと多くを共有します。違いはツールの所有形態と、想定しているモデルにあります。

Open Interpreter vs. Claude Code

Claude CodeはAnthropicのターミナル型コーディングエージェントです。まず所有形態が異なります。Claude Codeはプロプライエタリ、Open InterpreterはApache 2.0のオープンソースです。Open Interpreterは全てのコードを読めて改変できます。

次にモデル選択。Claude CodeはClaudeモデル向けに作られています。他プロバイダのAnthropic互換エンドポイントを指定できますが、ハーネスはClaude向けのままです。Open Interpreterはモデル選択を中核機能と捉えています。

ハーネスの比較が興味深いところです。Claude Code自体が、Open Interpreterがエミュレートするハーネスの1つです。claude-codeモードでは、任意のモデルがOpen Interpreterのランタイム内でClaude Codeスタイルのプロンプトとツールを得ます。UIやスラッシュコマンドはOpen Interpreterのままなので、モデルだけ変えた同一製品というわけではありません。

両ツールともターミナルファーストで、インタラクティブセッションと、スクリプトやCI用の非インタラクティブモードがあります。プロジェクト指示文は、Claude CodeがCLAUDE.md、Open Interpreterが共通のAGENTS.md形式を読みます。

エコシステムはClaude Codeが大型です。IDE拡張、デスクトップ・Webアプリ、プラグインマーケットプレイス、サブエージェント、SDKが用意されています。Open Interpreterは新しく、MCPやスキル、AGENTS.md、Agent Client Protocolといった共有規格に依存し、独自エコシステムを持ちません。

Claudeモデルで最も磨かれた体験を望むなら、Claude Codeが無難です。専有ツールを避けたい、あるいは他のモデルを使いたいならOpen Interpreterを選びましょう。

Open Interpreter vs. OpenCode

OpenCodeは最も近い存在です。どちらもオープンソースでターミナルファースト、そして多くのモデルプロバイダに対応します。

モデル対応は紙の上では似ています。OpenCodeは75以上のプロバイダをサポートし、Open Interpreterは公開モデルカタログから一覧を生成します。どちらもOllama経由のローカルモデルを扱います。

ターミナル体験はやや異なります。OpenCodeは独自TUIにLanguage Server Protocol（LSP）を統合し、型エラーなどの診断情報をモデルに返せます。Open InterpreterのTUIはCodex由来です。

設定形式は、OpenCodeがopencode.json、Open Interpreterがプロフィール付きのconfig.tomlです。

エージェントアーキテクチャが主な違いです。OpenCodeはクライアント・サーバ型で、TUIはローカルサーバのクライアントの1つで、他のクライアントも接続可能です。組み込みのbuildとplanエージェントがあり、カスタムエージェントやサブエージェントにも対応。モデルファミリごとにシステムプロンプトを調整しますが、ツールとループはOpenCode独自です。Open Interpreterはさらに踏み込み、ツールスキーマやメッセージ形式を含むハーネス全体を差し替えます。新しいビルドにはopencodeハーネスモードも含まれます。

開発面では、OpenCodeはチームとコミュニティが独自に構築するコードベースです。Open InterpreterはCodexのフォークに基づいており、ランタイムの大部分は上流由来です。これはトレードオフです。Open InterpreterはCodexのサンドボックスやランタイムを活用できる一方、OpenCodeはスタック全体を自ら制御します。

Open Interpreter vs. Codex

この2つは一般的な意味では競合しません。Open InterpreterはCodexのフォークです。

Rustランタイム、TUI、サンドボックス、承認、AGENTS.md、スキル、MCP、execモード、主要なスラッシュコマンドを共有します。Open Interpreterを実行したところ、セッション再開のヒントにcodex resumeと出る場面すらありました。

CodexはOpenAIのモデル中心に設計されたエージェントです。--ossやカスタムプロバイダでローカルモデルもサポートしますが、デフォルト体験はOpenAI志向です。

Open Interpreterは次の方向にCodexを拡張しています:

• ハーネスのエミュレーション: モデルファミリごとにプロンプト、ツールスキーマ、メッセージ形式を合わせる

• プロバイダ対応: 生成されたプロバイダカタログと、Kimi K3、DeepSeek、GLM向けの専用ガイド

• Chat Completions: --chat-completionsフラグでOpenAI互換プロバイダを利用

• Codex SDKのオーバーライド: Codex SDK上のアプリをOpen Interpreter経由で動かせる

Open Interpreterは設定とセッションを~/.openinterpreterに保存するため、Codexのインストールと競合しません。

OpenAIモデルが中心ならCodexが適しています。その他のモデルを使うなら、同じワークフローでそれらをより良く扱えるOpen Interpreterが向いています。

簡単におさらい:

Open Interpreterと他のAIコーディングエージェントの比較

Open Interpreterのセキュリティと権限

チャットボットの最悪は無視できる「悪い回答」です。しかしコーディングエージェントはマシン上でコマンドを実行し、ファイルを読み書きし、ネットワークにも到達します。モデルの誤った判断やプロンプトインジェクションは実害を引き起こし得ます。プロンプトインジェクションとは、READMEやウェブページなど、エージェントが読むコンテンツ中に隠れた指示のことです。

Open InterpreterはCodexランタイムのセキュリティモデルを継承しています。サンドボックス（可能範囲の制限）と承認ポリシー（確認のタイミング）の二層構造です。

コマンド実行とファイルシステムアクセス

エージェントが実行するコマンドはすべて、macOS、Linux、WindowsのOSレベルサンドボックスを通ります。サンドボックスモードは3つです:

• read-only: 読み取りのみで変更不可

• workspace-write: プロジェクトフォルダ内でのファイル編集とコマンド実行が可能

• danger-full-access: サンドボックスなし

workspace-writeでは、書き込みはアクティブなワークスペースに制限されます。コード修正はできますが、マシン上の他の場所は編集できません。

ネットワークアクセス

workspace-writeモードでは、デフォルトでコマンドにネットワークアクセスがありません。これによりダウンロードをブロックし、コードの外部送信を防ぎます。

パッケージのインストールなど、ネットワークが必要な場合もあります。設定で有効化できます:

sandbox_mode = "workspace-write"

[sandbox_workspace_write]
network_access = true

必要なプロジェクトにのみ有効化してください。

承認

承認ポリシーは、どのタイミングで確認を挟むかを決めます:

• untrusted: 信頼リストにないコマンド実行前に確認

• on-request: サンドボックスを超えるアクセスが必要なときに確認

• never: 確認なし

バージョン管理されたプロジェクトでは、workspace-write＋on-requestが無難なデフォルトです。プロジェクト内で作業し、範囲外へ行くときは確認します。万一の際はGitで戻せます。

--yoloはサンドボックスと承認をともに無効化します。コンテナやVMなど使い捨て環境でのみ使用してください。

認証情報と秘密

エージェントが実行するコマンドはシェル環境を継承します。APIキーを環境変数に置いている場合、そのコマンドから見えてしまいます。

shell_environment_policyで制限できます:

[shell_environment_policy]
inherit = "core"
exclude = ["AWS_*", "*_TOKEN"]

coreはHOMEやPATHなど基本的な変数のみを渡し、excludeはパターンに合致するものを除外します。

ファイルもリスクです。read-onlyでも、プロジェクト内の.envファイルはエージェントから読めます。ホステッドプロバイダの場合、エージェントが読むものはすべてプロバイダのサーバへ送られます。

サンドボックスは被害を抑えますが、保証ではありません。最後の安全網として扱ってください。

エージェントを自動で動かす前に、/statusでサンドボックスモードと承認ポリシーを確認してください。

Open Interpreterの進化

冒頭がpip installで始まるOpen Interpreterの記事を見かけても、誤りではありません。別プロジェクトの説明です。

オリジナルのOpen Interpreterは2023年にPythonプロジェクトとして登場し、言語モデルがあなたのマシンでPython、JavaScript、シェルコードを実行できました。ChatGPTのCode Interpreterのオープンソース代替として知られ、後の版ではデスクトップ操作も追加されました。

現行のメインプロジェクトはCodexをベースにしたRustでの書き直しで、一般的なコンピュータ操作ではなく、コーディングエージェントとハーネスのエミュレーションに焦点を当てています。

Python版は消えたわけではありません。コミュニティフォークとしてendolith/open-interpreterとして継続しています。

両者は同じ名称、同じGitHubリポジトリ履歴、同じinterpreterコマンドを使うため、混同しやすい点に注意してください。

ただし明確な見分け方があります:

• pip install open-interpreter: レガシーのPython版

• curlまたはPowerShellインストーラ: 現行のRust版

Open Interpreterの長所と制約

Open Interpreterはすべての環境に最適なツールではありません。適する場面とそうでない場面を整理します。

長所

• オープンソース: Apache 2.0ライセンスで、コード全体を閲覧・監査・フォーク可能

• モデル選択: ホステッド／オープンウェイト／ローカルモデルを1つのエージェントで使い、セッション途中でも切替可能

• 複数のエージェントハーネス: モデルが調整された環境に近づけられ、同様の機能を持つエージェントは多くありません

• ターミナルネイティブの開発: 既存のシェルやGitのワークフローに馴染み、execモードはスクリプトやCIでも機能

• オープンで低コストなモデル: プロジェクトがそれらを中心に構築され、専用ガイドと適合ハーネスが用意される

• 拡張性: MCP、スキル、フック、AGENTS.md、Agent Client Protocol、Codex SDKオーバーライドにより他ツールと連携可能

制約

• モデル品質のばらつき: エージェントの性能は背後のモデル次第で、マルチステップ計画ができないモデルはハーネスでも救えない

• ローカルモデルは強力なハードウェアが必要: テストではdevstral-small-2だけで26GBを消費。エージェントに必要な大きなコンテキスト前の時点で

• セットアップ工数が増える: プロバイダ、コンテキスト長、ハーネス、サンドボックス設定を自分で管理。Codexの名残やOllamaモデルのメタデータ警告など粗さも残る

• コマンド実行のリスク: サンドボックスと承認はリスクを減らすが、排除はしない

• コードは結局レビューが必要: テスト合格は正しい修正の保証ではないため、各差分を読む必要がある

まとめ

Open Interpreterは、選んだモデル（ホステッド、オープンウェイト、ローカル実行のいずれでも）と連携するオープンソースのコーディングエージェントです。

ワークフローはシンプルです。モデルとハーネスを選び、エージェントにプロジェクトを指し示し、タスクが終わるまで調査・編集・コマンド実行を任せます。その後、成果物をレビューします。

ハーネスのエミュレーションが差別化要因です。Open Interpreterは全モデルを一つの構成に押し込まず、モデルに合わせて構成を変えます。これが決定打になる場合があります。仕上がりの良し悪しはモデルが、変更可能範囲は権限が決めます。あなたのレビューが、変更がコードベースに入る前の最終チェックです。

AIエンジニアの認定取得に関心がある場合は、Associate AI Engineer for Developersトラックに登録し、自分のペースでAIの世界へ踏み出してください。