Cellar - coding agent が JVM dependency の API を調べるための CLI
AI coding agent が JVM project を書くとき、よく詰まるのはかなり具体的な点です。Project がある library に依存していることは分かっていても、type、method、parameter signature が本当にどうなっているか分からない。Model に API を推測させるのは危険です。HTML docs を解析させるのは遅く不安定です。Source を読ませるにも、URL と version が合っている必要があります。
今日紹介する VirtusLab/cellar は、この隙間を扱う command line tool です。Maven artifact や現在の JVM project の public API を調べ、type signature、members、docs、origin を Markdown として出力します。GitHub page では現在およそ 63 stars、8 forks。主な言語は Scala、license は MPL-2.0 です。Repository は 2026 年 2 月 22 日に作成され、2026 年 5 月 27 日にも更新されています。Release page は現在 v0.1.0-M9 を指しています。
プロジェクト概要
| 項目 | 内容 |
|---|---|
| リポジトリ | VirtusLab/cellar |
| Stars | 約 63 |
| Forks | 8 |
| 主な言語 | Scala |
| ライセンス | MPL-2.0 |
| 作成日 | 2026 年 2 月 22 日 |
| 最近の更新 | 2026 年 5 月 27 日 |
| 最新 release | v0.1.0-M9 |
「API を調べる」を安定した command にする
Cellar の価値は、新しい documentation site を作ることではありません。API lookup を scriptable な terminal command にすることです。External Maven coordinate を調べることも、現在の project の classpath を自動認識して project code と dependencies を調べることもできます。
たとえば cellar get-external org.typelevel:cats-core_3:2.10.0 cats.Monad で外部 type を調べられます。Project root では cellar get --module core cats.Monad のように、現在の project context から symbol を見られます。Result は Markdown で、type signature、flags、members、docs がまとまっており、そのまま LLM や debug note に渡しやすい形です。
これは agent に自由検索をさせるより制御しやすいです。Command input には artifact、package、symbol が明示され、output format も安定しています。再現可能な code generation workflow では、「一つの command で必要な API fact を取る」ほうが、Web page を雑に集めるより組み込みやすいです。
Scala 3、Scala 2、Java class を扱う
Cellar は JVM ecosystem の三種類の artifact を中心に扱います。Scala 3 の TASTy はもっとも手厚く、signatures、flags、companions、sealed hierarchies、givens、extensions、docstrings を取得できます。Scala 2 pickles は best-effort で、type information が不完全な場合があります。Java .class file については、signatures と members を比較的よく取得できます。
この範囲は現実的です。JVM project で AI agent が間違えやすいのは、「loop が書けない」ことではなく library API の誤用です。Scala 2 と Scala 3 の artifact name を混同する、存在しない method を思い込みで呼ぶ、overload の argument order を間違える。Cellar は、agent が prompt 内の記憶だけで補完する前に、実際の artifact に問い合わせる道を作ります。
AI だけの道具でもありません。人間の developer が terminal で、ある dependency がどの type を公開しているか、package 下にどんな top-level symbol があるか、method name がどこに出るかを確認する用途にも合っています。
二つの mode：project 内と external dependency
Cellar の command は project-aware と external の二系統に分かれます。
Project-aware command は project root で実行します。Mill、sbt、scala-cli を自動検出し、classpath を抽出して project code と dependencies を検索します。主な command は get、list、search です。Mill と sbt では --module が必要で、scala-cli では module parameter を使いません。
External command は Maven coordinate に直接向きます。get-external、list-external、search-external、get-source、deps などです。Agent が完全な project environment を持っていない状態で public dependency を調べたいときや、script で version を固定したいときに向いています。
この二つの mode は自然な利用経路を覆っています。既存 project を編集するなら現在の classpath を見る。ある library を理解したいだけなら Maven artifact を見る。Agent にとっても、どちらも「Web docs を見てきて」と頼むより制約しやすいです。
Output は LLM context を意識している
Cellar の README は、stdout に Markdown content を出し、diagnostics は stderr に出すと説明しています。この分離は agent にとって重要です。多くの CLI は人間には便利でも、progress、warning、colored UI、result が混ざり、model に渡す前に cleaning が必要になります。
Cellar の output は context material として扱いやすいです。Heading で symbol を示し、code block に signature を置き、members と docs を続けます。List、search、dependency tree の command も境界が明確です。Codex、Claude Code、自作 agent runner に tool として渡すなら、この stdout/stderr の整理と Markdown format は glue code を減らします。
さらに --limit、--hide-inherited、--group-inherited などの option があります。Output size や inherited members の並べ方を制御できるので、一回の lookup で context を埋め尽くしにくくなります。Agent workflow では、tool output の量を制御できること自体が大事です。
Installation は engineering tool らしい
Cellar には複数の install path があります。推奨は Coursier で contrib channel の native binary を入れる方法です。Nix で直接実行または profile install することもできます。Manual install では GitHub release の native binary を download します。Source build には JDK 17+ と Mill が必要です。
この選択肢から見ると、Cellar は一般 desktop user より Scala/JVM developer に寄っています。対象を考えると自然です。Team がすでに sbt、Mill、scala-cli、Coursier、Nix を使っているなら、Cellar は既存 toolchain に入りやすいです。
注意点として、external coordinate は完全な artifact name で書く必要があります。README では :: shorthand は未対応とされています。Scala 3 なら org.typelevel:cats-core_3:2.10.0、Scala 2.13 なら org.typelevel:cats-core_2.13:2.10.0 のように明示します。人間には少し長いですが、agent には曖昧さが少ない形です。
向いている場面
Cellar は次のような場面に向いています。
- AI coding agent が code generation 前に JVM dependency の実 API を確認したい。
- Scala project で TASTy、package、extension、given、companion information を調べたい。
- Java / Scala mixed project で type members を terminal から素早く見たい。
- API lookup を script や agent tool に固定し、Web search 依存を減らしたい。
- Code review で、ある method call が現在の dependency version に本当に存在するか確認したい。
- LLM prompt に必要な signature だけを入れ、長い documentation page を渡したくない。
主に JavaScript、Go、Rust を書いているなら、Cellar は目的外です。Boundary はかなり明確です。JVM artifact、Maven coordinate、Scala / Java type information。その狭さがあるからこそ、general search より信頼しやすい tool になっています。
注意したい境界
Cellar はまだ若い project です。Star と fork は多くなく、release も milestone version です。重要な CI や production workflow に組み込む前に、小さな project で lookup accuracy、speed、cache behavior、build tool compatibility を確認したほうがよいです。
Scala 2 support も慎重に見る必要があります。README は Scala 2 pickles を best-effort と説明しており、type information が不完全な場合があります。複雑な Scala 2 type encoding に大きく依存する project では、Cellar output だけを唯一の根拠にしないほうが安全です。
また、Cellar が解くのは「実 API を調べる」問題です。API を正しく使う semantic judgment までは代替しません。Method が存在すること、signature、members は分かりますが、error handling や business context の判断は model や developer 側に残ります。
まとめ
VirtusLab/cellar は小さく焦点の合った tool です。JVM dependency の API lookup を、Web page や推測から切り離し、安定した terminal command にします。AI coding agent にとっては、より信頼できる context source になります。Scala / Java developer にとっても、artifact と project symbol を素早く見る CLI として使えます。
魅力は機能を大量に並べることではなく、agent が間違えやすい一段を狭くしている点です。まず実際の signature を調べ、それから code を書く。Coding agent が大きな JVM codebase に深く入っていくほど、この種の「model に正確な局所事実を渡す」tool は重要になります。