OpenResearch 解析：Claude Code を研究 agent に変えるローカルファーストのワークスペース

技術分解：AI 技術フレームワークの解析——説明、分析、技術評価、価値判断、実運用。著者：永亮

---

2026 年 9 月 18 日、alphaXiv/OpenResearch は GitHub で 4,941 個のスター（9 月 18 日時点）、305 個のフォーク、42 個のオープンイシューを獲得しており、MIT ライセンス、リポジトリは 2026 年 6 月 7 日に作成されました——2 か月強で 5000 星近くを獲得し、README には Trending 1 位のバッジ（trendshift）が掲載されています。その目的は一言で言えば、新しい研究 agent を一から作るのではなく、既に使用している Claude Code、Codex、OpenCode、Cursor を研究 agent に改造し、それらにローカルファーストのワークスペースを提供することです——文献レビュー、仮説、実験、研究レポートはすべてバージョン管理されたアーティファクトとなります。この記事では、6 つの項目に分けて解説します：何か、どうインストールするか、ソースコード層の三種の神器、冷静な視点、価値はあるか、結論。

1. これは何ですか

OpenResearch の自己位置づけは、README の 1 行目に記されています。「The local-first workspace for research agents and autoresearch」。2 行目はさらに率直です——「Turn your coding agents into research agents」。この動詞に注目してください：turn、つまり改造であり、replace（置換）ではありません。これは一つの現実を認めています。研究エージェントに必要な推論とツール呼び出しの能力は、コーディングエージェントは既に持っています。欠けているのは、研究という行為特有の構造です——実験は再現可能でなければならず、仮説には系譜（血縁）が必要で、証拠はコンテキスト内に残り、成果はレビュー可能でなければなりません。汎用のコーディングエージェントがいきなり研究に取り組む場合、最もよくある失敗は質問に間違って答えることではなく、異なる方向の変更を一つのディレクトリに混ぜたり、一度動いた結果を引用可能な結論として扱ったりすることです。OpenResearch が補おうとしているのは、まさにこの層の構造です。

技術スタックそのものが、この位置づけの注釈（裏付け）となっています。リポジトリ全体で 515 個のファイル。Rust は 3.63MB（115 個の .rs ファイル）を占め、ローカルランタイムと harness 管理層を担っています。TypeScript は 1.38MB（89 個の .tsx と 47 個の .ts）で、254 個のファイルからなる ui/ ダッシュボードを支えています。JavaScript は 204KB 以上で、その多くはビルドスクリプトです。Python はわずか 49KB、40 個のファイルで、demo とスクリプト側に分散しています。トップレベルのディレクトリは ui/、src/、demo/、agent-skills/（29 個のファイル）、macos/、docs/——これは「ローカルプロセス + ブラウザインターフェース + スキルパック + ネイティブアプリシェル」という構造であり、デスクトップ環境も網羅されています。

README は機能を 6 行の表に凝縮しています：並列探索（各研究方向ごとに独立したエージェントセッション、分離された git worktree を配備）、再現可能な実験（git ネイティブの実験ツリー、各 run は不変のアーカイブ）、コンテキスト内の証拠、エージェントの選択（各セッションで harness やモデルを変更可能）、計算リソースの選択（ローカル、独自クラスタ、ホスティング）、ローカル所有権。この 6 項目は機能チェックリストではなく、設計宣言です——それぞれが、汎用コーディングエージェントが研究を行う際の具体的な失敗に対する回答となっています。6 項目目の「ローカル所有権」が単独でリストアップされていることに注目してください：アーティファクトとデータは独自の git リポジトリに残ります。これはこのカテゴリにおいて、機能ではなくスタンス（立場）です。

2. インストールと使い方

インストールはコマンド一つです：

curl -LsSf https://openresearch.sh/install.sh | sh

インストール完了後、orx up を実行すると、ローカルダッシュボードが http://127.0.0.1:4791 で起動します。以降の操作は基本的にブラウザ上で行います：セッションの開始、実験ツリーの確認、証拠の確認など。コマンドラインツールは orx です。対応プラットフォームは macOS 11 以上、Linux（ワンクリック）、Windows beta（Git for Windows 必須）です。beta 表記はそのままであり、安定性は自己評価してください。また、git に強く依存しているため、Windows では事前に Git for Windows が導入されていることを確認してください。モデル側は LM Studio、oMLX、Ollama、または任意のカスタム OpenAI 互換エンドポイントに接続可能で、各社のクラウド API を直接使用することもできます。ローカルモデルに接続することは、オフラインでも完全なワークフローを実行できることを意味し、これはデータに敏感な研究にとって必須の要件です。

使い方は2つのレイヤーに分かれます。手動レイヤー：ダッシュボードで複数のセッションを開き、各セッションはそれぞれの研究の方向性に対応します。それぞれの agent が個別に走り、それぞれのコードを記述し、あなたはツリービューでどの方向性から結果が出たかを確認します。自動レイヤーは Autoresearch と呼ばれます：アイデアを一つ与えると、agent が自ら「アイデアの提案→コードの修正→実験の実行→証拠の確認→次のステップの決定」というサイクルを完走します。複数の agent が並列で推進し、実験ツリーは各ステップの系譜が追跡可能であることを保証します。

実行面には、特筆すべきスイッチがあります：orx up --remote user@host。同一のコミット済みコードスナップショットを、ローカル、SSH リモートマシン、Slurm クラスター、K8s、Ray、HuggingFace Jobs、Modal、Tinker、またはホストされた環境で実行できます——ブラウザとデータはあなたのノート PC に残し、計算のみをリモート GPU に投げます。ローカルに固定の計算能力がない人にとって、このスイッチはそれが単なるおもちゃかどうかを決定づけます：科学研究の実験における計算能力の大部分は学習（トレーニング）にあり、ノート PC は結果を見るだけに留まるからです。

三、ハードコア分解：ソースコード層の3点セット

これは本文の目玉だ。README は「local-first」「隔離」「再現性」と謳っているが、こうした言葉はどのツールも言うことだ。ソースコードを開いてみると、3つのことが非常に具体的に実装されている：実験ツリーと worktree の分離、playbook 注入メカニズム、agent-skills のモジュール化だ。行番号まで特定できる。

3.1 実験ツリーと worktree の分離

研究用 agent の最大のリスクは「混ざり合う（串味）」ことだ：異なる方向の agent が同じディレクトリでコードを変更し、互いに上書きし合い、最終的にどの結果がどのコードに由来するのか誰も言えなくなる。OpenResearch の答えは src/local/git.rs の ensure_session_worktree にある——各セッションの起動時に独自の git worktree を持つことを保証する。ソースコードのコメントは原則を非常に明確に書いている：「one opencode serve child per chat session, cwd=私有 worktree」。1つのセッションにつき1つの agent 子プロセス、作業ディレクトリはプライベートな worktree であり、ファイルシステムレベルで2つの方向が分離されているため、agent 間で自覚的な調整は一切不要だ。

worktree の上にあるのが実験ツリーだ。すべての実験 run はツリー上の1つの commit に対応し、不変のアーカイブとなる——run 終了後、そのコード、設定、入力は二度と変わらず、後の比較は生きたコードの塊ではなく、履歴スナップショットとの対話になる。この設計の価値は、論文を書く瞬間に発揮される：すべての数値は再生可能なツリーに遡ることができ、査読者が再現するには、そのツリーを checkout して再実行すればよい。ここでは git はバージョン管理の付属品ではなく、実験データ構造そのものだ——これこそが「git 原生」という3文字の真の重みである。

3.2 playbook 注入：各 agent に脳みそを入れ替える

コーディング agent を改造する最初の関門はシステムプロンプトだ。OpenResearch は、ユーザーに各ツールの設定ファイルで研究用の手順を手書きさせるのではなく、SYSTEM_PROMPT.md という研究用 playbook を内蔵している——orx up 時に各 agent のネイティブチャネルを通じて各セッションに注入される。3つのチャネルはソースコード内でそれぞれの着地点を持つ：Claude Code はコマンドライン引数を使用し、src/local/claude.rs:481 での呼び出し時に --append-system-prompt-file を付ける；Codex は developerInstructions フィールドを使用する；OpenCode は config の instructions リストを使用する。同一の playbook、3つの harness、それぞれが自らが認める口から流し込む——これが「turn your coding agents」の工学における真の意味だ：ハイジャックもパッチも当てず、ネイティブなメカニズムを使い、agent は自分が通常通り作業を始めているだけだと思っている。

playbook 自体は静的なテキストではない。playbook_md() は src/local/opencode.rs:179 にあり、レンダリング時に {token} プレースホルダーの束を置換する：プロジェクトの事実、現在の状態、計算リソースのデフォルト値、アーティファクトのパスだ。つまり、OpenResearch 内で起動される同じ Claude Code セッションが受け取るのは、自分がどのプロジェクトにいるか、アーティファクトがどこにあるか、デフォルトでどこで計算を実行するかを知っている研究用のロールカードであり、汎用的な「あなたは有用なアシスタントです」というものではない。コンテキストエンジニアリングはセッションの最初の1秒から始まっており、ユーザーが毎回手動で背景を説明するあの数百文字を省略できる。

3.3 agent-skills：12のモジュールからなる研究スキルパック

2番目の関門はスキルです。チャットができるだけでは不十分であり、科学研究には独自のプロセスがあります：文献レビューのやり方、実験のアーカイブ方法、図表の作成方法、レポートの書き方などです。agent-skills/ ディレクトリの下には、プロセスごとに12のモジュールが分かれています：orx-agent-delegation（エージェント間でのタスク委任方法）、orx-compute（計算リソースのスケジューリング）、orx-create、orx-customize、orx-evidence（エビデンス管理）、orx-experiment-tree（実験ツリー操作）、orx-figures（図表生成）、orx-git、orx-instances（実行インスタンス管理）、orx-lit-review（文献レビュー）、orx-paper（論文執筆）、orx-reports（レポート生成）。各モジュールには SKILL.md が1つずつあり、冒頭には4つの cardinal rules（基本原則）が記載されています——まず科学研究の「一線（レッドライン）」を確立してから、作業の進め方について論じます。セッション内では orx skill <name> を通じて必要に応じてロードされ、使用するものだけを取得し、すべてをコンテキストに詰め込むことはありません。

この3点セットが描く全体像は次の通りです：worktree の分離により物理的な混同を防ぎ、playbook の注入により各セッションが最初の1秒から科学研究のルールに従うことを保証し、12のスキルモジュールによりエージェントが文献レビューと実験のアーカイブをそれぞれどのように行うべきかを把握できるようにします。harness 管理層は src/local/harness/ の下にあり、claude.rs、codex.rs、cursor.rs、opencode.rs、opencode_v2.rs、detect.rs の6つのファイルからなり、AgentHost（axum ベースのローカルサービス）によって統一的に管理されています——マルチエージェントの並列実行とは、複数のプロセスが無秩序に走ることではなく、1つのローカルホストによる統一的スケジューリングであり、detect はマシンにインストールされている利用可能な harness を特定する役割を担います。この層を Rust で記述するのは合理的な選択です：ホストプロセスは長時間稼働し、複数の子プロセスを同時に管理する必要があるため、メモリ安全性と並行性モデルの両方が活かされます。

四、冷静な視点

まず、基準を明確にしておこう。4,941 star は 2 か月余りの成果であり、README には Trending 1 位のバッジが掲げられているが、これは事実の陳述に過ぎない。しかし、star の増加速度とツールが実用的かどうかは別問題だ。2 か月のプロジェクトであり、42 個の open issues が積まれており、515 個のファイル内のインターフェースやコマンドはまだ流動的だ。今日書いた接続方法が明日には変わっている可能性がある——MIT ライセンスは最悪の事態をカバーしてくれるので、仮にプロジェクトの更新が止まっても、手元のバージョンを使い続けることはできる。

第二に、「ローカルファースト（Local-first）」は長所でもあり、限界でもある。アーティファクト、エビデンス、コードがすべてローカルの git 内にあり、所有権が明確で、オフラインで実行でき、ローカルモデルに接続する際はデータがマシンの外に出ない——これらは、未公開データや未発表の結果を扱う人々にとって必須の要件であり、投稿前の作業は本来クラウドに上げるべきではない。しかし逆に、現時点では中央集権的な共有レイヤーがない：チームでのコラボレーション、結果の公開、マシン間の同期は、すべて自分で git の既存の仕組みを組み合わせて行う必要があり、ツール自体が代行してくれるわけではない。GitHub 式のコラボレーションに慣れている人は、ここで何かが欠けていると感じるだろう。

第三に、Autoresearch の自律性は、宣伝通りに受け取るべきだ。README の記述は「アイデアを出す→コードを修正する→実験を実行する→エビデンスを見る→次のステップを決定する」となっており、方向性は信頼できるが、各サイクルの品質は接続したモデルと与えた計算リソースに依存する。agent が方向を間違えた代償は、実験ツリー全体の計算リソースを無駄にすることだ。それを自動化された研究アシスタントとして使うのは可能だが、独立した結論を導き出せる研究者として使うのは、現時点ではまだ無理だ。

第四に、Windows はまだ beta だ。Mac または Linux をメインで使っている人にとっては気にならないかもしれないが、Windows ユーザーは、git 環境と beta 状態を受け入れられるかをよく考えておく必要がある。

五、価値はあるか

ユーザー層ごとに見てみましょう。ML、システム、あるいは実験の実行が必要な研究分野に従事しており、すでに Claude Code や OpenCode を使用している人にとって、これは最もスムーズな導入経路です：ツールの移行も、習慣の変更も必要ありません。orx up を実行するだけで、既存のエージェントに研究のための「骨格」——実験ツリー、worktree の分離、playbook、スキルパック——が追加されます。これらはすべて既に用意されており、学習コストはほぼゼロです。ローカルでモデルを実行する必要がある人（データや予算に敏感な層）にとっては、LM Studio、oMLX、Ollama に直接接続できるため、計算リソースの支配権が完全に確保されます。リモートで計算リソースを利用する人にとっては、orx up --remote という 1 つのコマンドで計算処理を外部に委ね、ローカルにはブラウザとアーティファクトのみを残すことができます。この形態は、ノート PC 上で無理やり処理を実行するよりもはるかに健全です。

導入を見送るべきケースも明確です：実験的な研究を行わず、論文を読んでノートを取るだけの人は、12 のスキルモジュールの大部分を使用しないため、「牛刀をもって鶏を割く（大袈裟すぎる）」ことになります。使い慣れたノート作成のワークフローだけで十分です。チームでのコラボレーション需要が高く、結果の一元管理を必要とする人にとっては、ローカルファーストのアーキテクチャはニーズと逆行しています。「エージェントが自動的に論文を書いてくれる」と期待している人にとって、Autoresearch はプロセスの補助であり代筆サービスではないため、期待が外れると失望することになります。さらに、MIT ライセンスでありローカルで実行可能というこの 2 つの条件により、試行錯誤のコストは非常に低くなっています。インストールして、小さな再現タスクでワークフローを一度試してみれば、自分に合うかどうかは半日で分かります。これが、この種のツールを試す最もコストパフォーマンスの高い方法です。

結論

OpenResearch は長く避けられてきた問いに答えを出しました：研究 agent は必ずしも一から新しく作る必要があるのか？その答えはノーです——Claude Code、Codex、OpenCode、Cursor の推論とツールの能力はすでに十分であり、不足しているのは研究の構造です。そして、その構造はエンジニアリングによって補うことができます。ソースコード内でこの判断は非常に具体的に実装されています：ensure_session_worktree は各セッションにプライベートな worktree を持たせ、SYSTEM_PROMPT.md は --append-system-prompt-file（claude.rs:481）、developerInstructions、config instructions という3つのネイティブチャンネルを経由して各セッションに注入され、playbook_md() はレンダリング時にプロジェクトの事実と計算リソースのデフォルト値を埋め込み、12個の agent-skills モジュールは orx skill によってオンデマンドでロードされ、harness 層は AgentHost によって一元的にスケジューリングされます。実験ツリーは git 上に構築され、各 run は不変のアーカイブであり、再現性は単なる約束からデータ構造へと変わります。現在コーディング agent を使って研究を行っている人にとって、これは現在最も完全な「作り直すのではなく改造する」ソリューションです。また、研究 agent のエンジニアリングを行っている人にとっては、「ローカルファースト」をスローガンから行番号レベルへと落とし込む方法を示しています。

参考ソース

• alphaXiv/OpenResearch README（GitHub；位置づけ、インストール、6大能力表、Autoresearch、実行面）
• OpenResearch ソースコード（ローカル clone）：src/local/git.rs（ensure_session_worktree）、src/local/claude.rs:481（—append-system-prompt-file）、src/local/opencode.rs:179（playbook_md）、src/local/harness/（claude.rs / codex.rs / cursor.rs / opencode.rs / opencode_v2.rs / detect.rs）、agent-skills/（12個の SKILL.md）
• リポジトリデータ：4,941★、fork 305、issues 42、MIT、作成日 2026-06-07（2026-09-18 現在）