OpenScience を導入前に読む: 文献調査から再現実験までを1つの作業台に載せる設計

OpenScience が埋めようとしている「文献とコードの往復」という隙間

研究の現場では、文献を読む作業とコードを書く作業が別々の道具に分かれている。文献管理ツールは論文を溜めるが実験は回さない。ノートブックはコードを実行するが、引用済みの根拠と実行結果を同じ文脈に置かない。OpenScience はこの分断を1つの作業台にまとめようとしている。README の説明は「Give it a goal. It reads the literature, writes and runs code, runs the experiments, and writes up what it found.」であり、目的を与えると文献を読み、コードを書き実行し、実験を回し、結果を書き上げる、という一続きの流れを想定している。対象は、データ分析と文献調査と執筆を同一プロジェクトで行う研究者、およびその再現性を担保したいチームである。作業面はデスクトップアプリ、ブラウザワークスペース、ターミナルの3つが用意されている。

モデル接続が3経路に分かれている理由と、Ace の課金構造

この道具の実務上の分岐点は、どのモデルにどう接続するかである。README の表では Ace、自前プロバイダ、ローカルモデルの3つが並ぶ。Ace はサインインして資金提供ワークスペースを選び Wallet に入金する方式で、従量課金であり月額サブスクリプションはないと明記されている。課金の内訳も README に書かれている。Ace の有効化は 0 ドルのオーソリゼーションで、利用料はプロバイダが報告したコストに 5.5% の funding fee を1リクエストにつき1回加えたものになり、それ以外のマークアップはない。カード処理費は checkout 時に別掲される。ここで見落としやすいのが自動リロードの挙動で、購入済み Wallet 残高が 5 ドルを下回ると 20 ドルのリロードが走る。README は「Changing to your own provider does not turn off automatic reloads.」と明示しており、自前プロバイダに切り替えても自動リロードは止まらない。ローカルモデルは Ollama、LM Studio、その他の互換エンドポイントに接続する形で、Ace のモデル課金は発生しない。

導入コマンドと、プロジェクトを渡す単位

CLI とブラウザワークスペースを使う場合、README が示すのは npm install -g @synsci/openscience の後に openscience を実行する流れである。インストールせず試す用途には npx synsci という一段のランチャーも用意されている。既存プロジェクトに対しては openscience ~/research/my-project のようにパスを渡す。モデル接続の設定はターミナルから openscience keys add と openscience models で行い、ローカルエンドポイントは openscience local add で追加する。GUI 側では Customize → Models からアクセス方法を選ぶ。単発の指示は openscience run "..." で実行でき、openscience run --continue "..." とすると直前の文脈を引き継ぐ。デスクトップアプリは macOS、Windows、Linux 向けに配布されている。

skill は「手順の記述」であって「インストール済みの保証」ではない

README には数百の skill が同梱されていると書かれ、プロジェクト固有のワークフローを追加することもできる。ただし README 自身が注意を添えている。skill は手順を記述したものであり、そこから参照されるツールやサービスがすべて導入済みであることを意味しない。実務では、Customize で利用可否を確認してから大きなタスクに着手することになる。この点は設計上の割り切りとして読める。skill のカタログを広く見せる代わりに、実行時の前提条件は利用者側の確認に委ねている。文献検索、データ分析、再現実験、執筆という4領域のガイドが用意されているが、いずれも参照先のツールが手元にあることが前提になる。

再現実験を「主張・前提・予算」で区切る進め方

README が挙げる機能のうち、他と性格が異なるのが再現実験である。ここでは主張、前提条件、予算について合意したうえで、測定結果を比較するという手順が示されている。実行前に方法を固めたい場合は /plan から始める。タスクの例として README に載っているのは、data/samples.csv の欠損値と不整合なラベルを検査し、元データは変更せず、results/ に品質レポートとプロットを、再現に必要なコードとともに保存する、という依頼である。注目したいのは「Review sources, assumptions, code, and outputs before relying on a scientific conclusion.」という但し書きで、これは自動化された結論をそのまま科学的結論として扱うなという明示的な留保である。エージェントに実験を回させる道具でありながら、最終的な判断は人間側に残す設計になっている。

MCP 接続と SDK による拡張、そして向かないケース

拡張の入口は MCP 接続、カスタムエージェントとコマンド、プラグイン、SDK 連携の4つが README に列挙されている。既存の研究基盤や自作ツールを接続したい場合、この層を使うことになる。一方で、この道具が明確に向かない場面もある。第一に、外部へのデータ送信が一切許容できない環境。ローカルモデル経路は用意されているが、文献検索や Ace 経由の機能は外部サービスに依存する。第二に、単発のスクリプトを回したいだけの場合。openscience run は使えるが、文献・実験・執筆を1つの文脈に載せるという設計の利点は得られない。第三に、skill が参照するツールを自前で揃えられない場合、カタログの広さがそのまま実行可能範囲にはならない。

比較対象としての Jupyter と、設計思想の違い

近い用途の道具として Jupyter が挙げられる。Jupyter はノートブックという実行単位を持ち、セルを上から順に評価する。状態はカーネルに保持され、何をどの順で実行したかはノートブックの構造そのものが表す。OpenScience はこの逆で、目的を与えてエージェントに文献調査からコード生成、実行、レポート出力までを委ね、人間は /plan で方法に合意し、出力を検証する側に回る。再現性の担保方法も異なる。Jupyter ではノートブックとカーネル状態の一致を人間が管理する。OpenScience では「元データは変更せず、results/ に再現用コードとともに保存する」といった指示の粒度で成果物を固定する。どちらが優れているという話ではなく、実行の主導権を人間が持つか、エージェントに渡して検証に回るかという違いである。手元の解析を対話的に詰めたいなら Jupyter のほうが素直で、文献からレポートまでの一連を1つの依頼にまとめたいなら OpenScience の構造が効く。

Apache-2.0 の範囲と、更新頻度から見る保守コスト

ライセンスは Apache-2.0 で、リポジトリはアーカイブされていない。直近のリリースは v2.0.87、v2.0.86、v2.0.85 が同日の 2026-09-09 に並んでおり、パッチ番号が細かく刻まれている。最終 push も同日である。この更新の刻み方は、活発である一方で、固定したバージョンに留まる運用を難しくする。研究プロジェクトで再現性を重視するなら、openscience のバージョンをプロジェクト側で記録し、依存を固定する判断が要る。Apache-2.0 は特許許諾条項を含み、改変物の配布時には条件がかかるが、ここで法的助言はできない。組織の法務に確認すべき点は、Ace 経由の従量課金と Wallet の自動リロードが調達ルール上どう扱われるか、そして同梱 skill が参照する外部サービスとの契約が既存のものと衝突しないかである。

編集部の結論

向いているのは、文献・データ・コード・執筆が同一プロジェクト内で往復する研究ワークフローを持つチームで、モデル接続を Ace・自前キー・ローカルから選べる点を運用に活かせる場合だ。逆に、外部へのデータ送信が一切許容できない環境、あるいは単発のスクリプト実行だけが目的なら、このワークベンチの中心機能は使われない。導入前に確認すべきは、openscience keys add と openscience local add のどちらで運用するか、Wallet の自動リロードが自前プロバイダへ切り替えても止まらない仕様を許容できるか、そして使う予定の skill が参照するツールやサービスが実際に手元にあるか、の3点である。

公式情報源

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. synthetic-sciences/openscience on GitHub