Raindrop Workshop レビュー: コーディングエージェントに eval を書かせるローカルトレース基盤
Give your coding agent the power to write and run agent evals.
ひと目でわかる
- これは何？
- エージェントのトークンとツール呼び出しをローカルで流し、Claude Code などのコーディングエージェントにそのトレースを読ませて eval を書かせる。MIT の TypeScript 製ツールが何を解決し、どこで向かないかを整理する。
- 誰に向いている？
- ローカルでエージェントを動かしながら失敗パターンを再現したい個人開発者や小規模チームは、curl -fsSL https://raindrop.sh/install | bash を一度試す価値がある。逆に、本番トラフィックの可観測性が主目的なら Workshop ではなく Raindrop Cloud 側を検討すべきで、両者は別物だ。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 24 日前です。
- 何の言語で書かれている？
- 主に TypeScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
エージェント開発で eval が後回しになる理由と、Workshop が置く前提
エージェントの挙動は、同じ入力でもツール呼び出しの順序や回数が変わりやすい。そのため「壊れた」と気づいたときには、どのステップで逸脱したのかがログから追えないことが多い。Workshop はこの追跡をローカルで完結させる道具として提示されている。README の表現を借りれば「the local debugger your agent is missing」であり、対象は自分のマシン上でエージェントを走らせて試行錯誤している開発者だ。
前提として押さえておきたいのは、Workshop が eval を実行するテストランナーではないという点だ。eval を書く主体は Claude Code などのコーディングエージェント側で、Workshop はそのエージェントが読める形でトレースを流し続ける。README には「Claude writes the eval, runs your agent, sees the failure, fixes the code, and re-runs until every assertion passes」とあり、失敗の観測と修正の反復をエージェントに委ねる設計になっている。つまり導入効果は、使っているコーディングエージェントがトレースを読んでコードを書き換えられる程度に依存する。
トレースがブラウザに届くまで: デーモン、SQLite、MCP の三点
構成は単純だ。インストーラが raindrop バイナリを入れ、raindrop workshop がローカルデーモンを起動する。デーモンは HTTP と WebSocket を RAINDROP_WORKSHOP_PORT（既定 5899）で待ち受け、UI は http://localhost:5899 で開く。トレースの保存先は SQLite で、既定は ~/.raindrop/raindrop_workshop.db。RAINDROP_WORKSHOP_DB_PATH で差し替えられる。
エージェント側の計装は /instrument-agent というスキル呼び出しで行う。README によれば、これをリポジトリ内でコーディングエージェントに実行させると Raindrop のトレーシングが入り、Workshop がブラウザで開く。以降はエージェントを動かすたびに、トークン、ツール呼び出し、スパンが発生と同時に UI へ流れる。ポーリングや再読み込みは不要と説明されている。
もう一つの入口が MCP だ。ローカル Workshop は workshop という名前の MCP サーバーを登録し、Raindrop Cloud 側は raindrop という別名で登録する。名前空間が分かれているため、両方を同じプロジェクトに入れても上書きし合わない。この分離は地味だが実用的で、ローカルで試してから本番観測に移る、という段階的な導入を壊さない。
導入手順: クローンせずにバイナリを入れ、/instrument-agent で計装する
README は「There is nothing to clone and nothing to build」と明言している。利用者向けの経路は次の一行だけだ。
curl -fsSL https://raindrop.sh/install | bash
インストーラは raindrop setup を実行し、ローカル Workshop デーモンを立ち上げる。そのあとコーディングエージェントをリポジトリで開き、/instrument-agent を実行する。設定を明示したい場合は raindrop workshop setup が .env を書いてから起動する。状態確認は raindrop workshop status、ローカル DB の削除は確認プロンプト付きの raindrop workshop reset。バイナリ更新は raindrop update だ。
環境変数は 3 つだけ公開されている。RAINDROP_WORKSHOP_PORT、RAINDROP_WORKSHOP_DB_PATH、そして SDK 側でトレースのミラー先を指定する RAINDROP_LOCAL_DEBUGGER である。3 つ目は既定が unset で、SDK の設定側で使うものだと説明されている。
本番トレースを手元のエージェントコードに当てたい場合は /setup-agent-replay を使う。README によれば、本番トレースを実際のエージェントコードに対して再生する HTTP エンドポイントを生成する。ソースからのビルド（bun install と bun run dev）は Workshop 自体を開発する人向けの経路で、試用目的では不要と繰り返し書かれている。
Raindrop Cloud との境界: デーモンを立てるか、立てないか
同じ raindrop バイナリが、ローカルとホスト版の両方を扱う。違いはデーモンの有無だ。Workshop はローカルデーモンと SQLite に閉じる。Raindrop Cloud は app.raindrop.ai に本番の AI 機能を流し、README には「no local daemon involved」とある。
Cloud 側の接続は raindrop cloud setup で行う。初回はブラウザが開いて OAuth サインインし、認証情報は ~/.raindrop にキャッシュされる。サインインだけを単独で実行するなら raindrop login、消すなら raindrop logout。cloud setup は未サインインのときだけ login を内部で呼ぶので、日常的には cloud setup だけを叩けばよい。このコマンドは組織の RAINDROP_WRITE_KEY を ./.env に書き、ホスト版 MCP サーバーと raindrop-setup、raindrop-investigate という 2 つのクラウドスキルをコーディングエージェントに導入する。
インストーラの一行から直接 Cloud に行くこともできる。curl -fsSL https://raindrop.sh/install | bash -s -- --cloud がそれで、この場合はローカルデーモンを起動しない。既存のローカル導入を壊さずに Cloud を外すには raindrop cloud uninstall、さらに ./.env から RAINDROP_WRITE_KEY を消すなら --wipe を付ける。
注意点として、raindrop setup を対話的に実行した場合だけ、最後に Cloud 接続を任意で提案される。CI やパイプ経由の非対話実行ではプロンプトが出ないため、その場合は raindrop cloud setup か --cloud の一行を使う必要がある。
対応範囲の広さと、その広さが意味しないもの
README が挙げる対応は言語 4 つ（TypeScript、Python、Go、Rust）、SDK は Vercel AI SDK、OpenAI Agents SDK、Anthropic SDK、Claude Agent SDK、LangChain、LangGraph、CrewAI、Mastra、Pydantic AI、DSPy、Google ADK、Strands、Agno、Deep Agents。プロバイダは AWS Bedrock、Azure OpenAI、Vertex AI。コーディングエージェント側は Claude Code、Codex、Devin、Cursor、OpenCode が並ぶ。
ただしこの一覧は「動く」ことの保証ではない。README はどの SDK のどのバージョンで検証済みかを示していないし、SDK ごとの計装方法の差にも触れていない。SDK の抽象度が高いほどトレースに載るスパンの粒度は粗くなるはずで、その粒度が自分のデバッグに足るかは実際に流してみないと分からない。対応表は候補を絞るための材料として読み、採用可否の根拠にはしないほうがよい。
もう一点、eval の生成品質はコーディングエージェントの能力に強く依存する。README は self-healing という語で反復を説明しているが、アサーションが通るまで回すループが何回で打ち切られるのか、失敗時にどこまでコンテキストが渡るのかは書かれていない。
向かないケース: 本番観測、チーム共有、長期の履歴管理
Workshop はローカルデバッガだと README 自身が位置づけている。したがって本番トラフィックの監視やアラートが目的なら、これは選ぶべき道具ではない。その用途は Raindrop Cloud 側が担う。
保存先が単一の SQLite ファイル（既定 ~/.raindrop/raindrop_workshop.db）である点も制約になる。複数人で同じトレースを見る、履歴を長期保管する、といった運用は README の範囲では想定されていない。raindrop workshop reset は確認付きでこの DB を削除するので、消したくないトレースは別途退避させる必要がある。
もう一つの落とし穴は、計装がコーディングエージェント経由であることだ。/instrument-agent や /setup-agent-replay はエージェント側のスキルとして実行される。つまりエージェントが編集したくないファイル、あるいはエージェントに触らせたくないリポジトリでは、この導線そのものが使いにくい。手作業で計装を書きたい人のための手順は README には用意されていない。
比較対象として OpenTelemetry を挙げておく。OTel はベンダ非依存のスパン規格とコレクタを持ち、送信先を後から差し替えられる。代わりに、計装コードを自分で書き、バックエンドを別途立てる必要がある。Workshop はその逆で、規格への準拠やエクスポータの選択肢は README からは読み取れないが、インストーラ 1 行とスキル 1 回で UI まで到達する。可搬性を取るか、初回の到達速度を取るかの違いだ。
保守コストと MIT ライセンスの意味
リポジトリの最終 push は 2026-08-22 で、同日に v0.1.21 が出ている。直前が v0.1.20（同日）、その前が v0.1.19（2026-08-14）なので、少なくともこの期間は短い間隔でリリースが続いている。ただし版番号は 0.1.x のままで、README にも安定版という記述はない。API や CLI の引数が変わる前提で追従するコストを見込んでおきたい。
更新自体は raindrop update の一語で済む。ソースからビルドした場合は bun install と bun run dev の経路になるため、更新のたびに手元でビルドし直す手間が発生する。README がビルド経路をコントリビュータ向けと明記しているのは、この差を利用者に踏ませないためだろう。
ライセンスは MIT。商用利用や改変、再配布を許す条件の一つとして、著作権表示とライセンス全文の保持が求められる。これはライセンス一般の話であって、Workshop に固有の追加条項があるかはリポジトリの LICENSE ファイルを直接確認する必要がある。なお Raindrop Cloud は別プロダクトであり、MIT の対象はあくまでこのリポジトリだと考えるのが自然だが、両者の関係を明記した記述は README にはない。
編集部の結論
ローカルでエージェントを動かしながら失敗パターンを再現したい個人開発者や小規模チームは、curl -fsSL https://raindrop.sh/install | bash を一度試す価値がある。逆に、本番トラフィックの可観測性が主目的なら Workshop ではなく Raindrop Cloud 側を検討すべきで、両者は別物だ。導入前に確認すべきは、自分のエージェントが対応 SDK 一覧に載っているか、そしてトレースを書き出す先が RAINDROP_WORKSHOP_DB_PATH の SQLite ひとつで足りるかどうか。ソースからのビルドは Workshop 自体を開発する場合だけの経路で、利用目的でクローンする必要はない。
コミュニティノート