opensrc は AI コーディングエージェントに npm パッケージのソースを渡す CLI だ

エージェントが読めるのは型定義まで、という壁

AI コーディングエージェントに npm パッケージの使い方を尋ねると、返ってくる答えは node_modules に入っている .d.ts と README をなぞったものになりやすい。型シグネチャは分かっても、境界条件の処理やエラーの握り方は見えない。opensrc が狙うのはこの隙間である。README の冒頭には「Give coding agents access to any package's source code」とあり、目的はエージェントの文脈をソースコードまで広げることに絞られている。対象は npm に限らない。README の例では pypi:requests のようにプレフィックスを付けて PyPI を指しており、パッケージ表では npm、PyPI、crates.io、GitHub の 4 つが取得元として挙げられている。読者は、エージェントに「このライブラリは実際にどう動くのか」を読ませたいが、リポジトリを手で clone して回るのは避けたい、という層になる。

opensrc path が返すのはパスであって中身ではない

opensrc の中心は opensrc path という 1 つのサブコマンドである。README の Quick Start は、このコマンドをコマンド置換の内側で使う形だけを示している。rg "parse" $(opensrc path zod) は取得したソースツリーを ripgrep に渡し、cat $(opensrc path zod)/src/types.ts は特定ファイルを開き、find $(opensrc path pypi:requests) -name "*.py" は Python パッケージのツリーを探索する。つまり opensrc 自身は検索も要約もしない。ソースをローカルに落とし、そのルートパスを標準出力に 1 行返す。探索は rg、cat、find といった既存のツールに委ねる設計だ。README は「fetches on first use, then returns the cached path instantly」と述べており、初回だけ取得が走り、2 回目以降はキャッシュ済みパスが即座に返る。エージェント側から見ると、ツール呼び出しのたびにネットワーク往復が発生しない点が効く。CLI 本体は Rust で書かれ、リポジトリは Turborepo と pnpm workspaces のモノレポ構成を取る。

インストールと最初の 3 コマンド

導入は npm install -g opensrc の 1 行である。CLI readme へのリンクが README に置かれているため、フラグの全量はそちらを見る必要があるが、Quick Start に載っている範囲はこれで動く。npm install -g opensrc の後、opensrc path zod を実行すれば zod のソースツリーのパスが返る。pypi:requests のようにレジストリのプレフィックスを付ければ PyPI を対象にできる。表記のないものは npm として扱われると読める。ソースからビルドしたい場合は Rust 側の手順が README にあり、cargo build --manifest-path packages/opensrc/cli/Cargo.toml で CLI を、cargo test で同じマニフェストを指定してテストを実行する。開発環境は Node.js 24+ と pnpm 11 が前提で、pnpm install の後に turbo build または turbo dev を走らせる。ドキュメントサイトは apps/docs 配下の Next.js アプリで、cd apps/docs してから pnpm dev で起動する。

キャッシュが前提なので、鮮度と容量は自分で管理する

README が明言しているのは「初回取得のあとはキャッシュパスを即座に返す」という挙動だけである。キャッシュの保存先、無効化の方法、バージョンを上げたときに何が起きるかは、この素材からは確認できない。ここは利用前に潰しておくべき空白だ。opensrc path zod はパッケージ名しか受け取らない例しか示されておらず、特定バージョンを指定する構文も README には出てこない。エージェントに読ませる対象が更新されても、キャッシュが古いままであれば古い実装を読ませることになる。もう 1 つの制約は取得元への到達性である。opensrc path pypi:requests は PyPI に、npm のパッケージは npm レジストリに出ていく。外部レジストリへ接続できない環境では、この取得経路そのものが成立しない。opensrc はソースを同梱するのではなく、実行時に取りに行く道具だと理解しておくべきである。

自分で clone する運用との差はどこにあるか

代替手段として最も素直なのは、対象リポジトリを git clone してエージェントに読ませる方法である。違いは解決の単位にある。clone はリポジトリ単位で、どのパッケージを読むかを人間が決めてパスを管理する。opensrc はパッケージ名を指定するとソースツリーのルートを返すので、依存関係の一覧から機械的に引ける。npm と PyPI と crates.io を同じ opensrc path の書式で扱える点も、複数言語の依存を 1 つのエージェントに読ませるときには効く。ただし clone が勝つ場面もある。特定のコミットやブランチを固定したい場合、clone なら git checkout で済むが、opensrc の README にはバージョンやコミットを指定する手段が示されていない。再現性を厳密に固定したいなら clone のほうが素直である。逆に、エージェントに渡すパスを短く保ちたいなら opensrc のほうが記述量は少ない。

Apache-2.0 とモノレポの保守コスト

ライセンスは Apache-2.0 で、リポジトリ全体に適用される。特許条項を含む条項の解釈は案件ごとに異なるため、ここでは条項の中身には触れない。実務上確認すべきは、社内で再配布する形を取るのか、CLI として呼び出すだけなのかという利用形態のほうである。保守の観点では、CLI が Rust、ドキュメントサイトが Next.js という 2 つのツールチェーンを 1 つのリポジトリに抱えている点に触れておきたい。CLI 側だけを追う場合でも、リポジトリを丸ごと扱うなら Rust ツールチェーンと Node.js 24+、pnpm 11 の両方が必要になる。README が示す検証コマンドは cargo fmt、cargo clippy -- -D warnings を含むため、フォークして手を入れるなら clippy の警告をゼロに保つ運用が前提になる。リリースは v0.7.1 から v0.7.3 まで 2026 年 4 月から 6 月にかけて刻まれており、0.x 系のまま細かく版を上げる進め方だと読める。

導入を決める前に確かめる 2 点

最初に確かめるのは、opensrc path が対象パッケージで実際に何を返すかである。README の例は zod と pypi:requests の 2 つだけで、パッケージによってはソースが同梱されておらず取得が空振りに終わる可能性が残る。手元の依存をいくつか選び、opensrc path の出力を ls で確認するのが早い。次に、初回取得がどのホストへ出ていくかを把握しておく。npm と PyPI と crates.io と GitHub の 4 つが取得元として挙げられている以上、プロキシや許可リストの設定はこの 4 つを前提に組む必要がある。エージェントに依存パッケージの実装を読ませる価値があり、かつ取得元への到達性が確保できるなら、opensrc path を 1 行挟むだけで読ませる対象が変わる。逆に、依存の内部実装を読む必要がない作業しかしないなら、opensrc を入れてもエージェントの出力は変わらない。

編集部の結論

opensrc が向くのは、エージェントに node_modules の型定義や dist ではなく実際の実装を読ませたい開発者である。逆に、依存パッケージの内部実装を読む必要がない用途や、取得元を自前で固定したい閉域環境では、opensrc path が返すキャッシュパスに依存する構成は持ち込みにくい。導入前に確認すべきは、opensrc path が対象パッケージでどのパスを返すか、そして初回取得がどのレジストリへ出ていくかである。

公式情報源

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. vercel-labs/opensrc on GitHub