AIに開発を頼むと、前回説明した設計や同じファイルを何度も読み直す。会話を分けると経緯を失い、続けるとコンテキストが膨らむ。この困りごとに、コードの地図と検索できる記憶を組み合わせるのが、オープンソースのRubiです。
2026年10月19日3時20分10秒（日本時間）にv0.4.0が公開され、Claude Codeを中心とした仕組みから、Codex、Gemini CLI、Cursorなどへ接続する導入経路が広がりました。この記事ではv0.4.0を対象に、何を省けるのか、料金の数字をどう読むか、日本語でどこにつまずくかを解説します。
ふくふくの小さな検証では、日本語の質問だけで関連メモを取得できない例と、異なる日本語見出しが一つのメモへ結合される例がありました。後者は見出しに異なる英字の識別名を付けると分離できました。まず使い捨てのプロジェクトで試してください。実LLMでの費用削減や、各開発アプリとの実接続は今回未検証です。
Rubiは何をする？ 毎回の調べ直しを減らす補助ツール
Rubi自体は新しいLLMではありません。開発プロジェクトの構造、設計判断、過去の不具合、次に行う作業をファイルとして持ち、AIが必要な情報へ到達しやすくする道具です。提供元の説明では、プロジェクト内の.rubi/にMarkdownで保存します。特別なデータベースを前提にせず、人も中身を確認できます。
| 持たせる情報 | 仕事での例 | 狙い |
|---|---|---|
| コードの地図 | 請求処理がどのモジュールにあるか、どのファイルが多く参照されるか | 最初から広い範囲を探索する回数を減らす |
| 判断と理由 | 同じ請求書番号を二度処理しない理由 | 別の会話で同じ設計判断をやり直さない |
| 関連付け | 返金の注意点とbilling.tsを結ぶ | 検索語が完全には一致しなくても関連情報をたどる |
| 引き継ぎ | 完了した修正、未確認のテスト、次の一手 | 短い会話へ移っても再開しやすくする |
たとえば請求処理の修正で、「どのファイルか」「なぜこの条件分岐があるか」を毎回探しているなら、効果を確かめやすい題材です。逆に、単発の短い質問や、記憶に残す判断がほぼない作業では、メモを書く負担のほうが増える可能性があります。
検索の仕組みは「単語・ファイル名・つながり」
検索実装は、単語の一致を重み付けするBM25、質問に含まれるファイル名や関数名、関連する記憶へたどるグラフ検索を組み合わせます。意味が近い言い換えを考える役目は主に接続するAI側です。Rubi単体で日本語の意味を理解する埋め込み検索が付いている、という説明ではありません。
この区別は実用上大切です。「返金」と「払い戻し」が同じ意味でも、記録と質問を結ぶ手掛かりがなければ見つからないことがあります。rubi_contextoへ質問と関連語を渡し、rubi_registrarで判断を記録し、rubi_salvar_handoffで引き継ぎを残す、という使い方になります。ツール名や一部メッセージはポルトガル語です。
「37%削減」は何の数字？ 実測・試算・増加を分ける
提供元のREADMEには複数の削減率が出てきますが、同じ条件の結果ではありません。以下は提供元が報告する研究・検証結果であり、ふくふくで再測定した数字ではありません。結果と限界の説明に条件が掲載されています。
| 報告されている数字 | 測ったもの・計算したもの | 読むときの注意 |
|---|---|---|
| 約37%の費用減 | 284件の実セッションのコンテキスト推移を使った早期圧縮のシミュレーション | 実際にRubiを入れて支払額が37%減った実験とは異なる |
| 再読込37%減、所要時間17%減、費用6%減 | 準備済みの記憶グラフを読む短いセッションのA/B結果 | 全体90セッションの検証内の比較。FlaskとHono、提供元の条件に依存する |
| 約26%の費用減 | 上の変化を別の実利用の費用構成に当てはめた予測 | 実測ではない |
| 費用15%増 | 探索後の回答ごとに記憶を書かせた比較 | 記録にも呼び出しとトークンが必要。現在の既定値は記録頻度を抑える方向へ変更 |
提供元のA/Bで使う記憶グラフは、先の比較条件で同じ評価課題に取り組ませたときの5〜6件の記憶から作られています。未知の実務へ導入した直後の効果とは区別してください。同じ「読む量が減った」でも、キャッシュの効き方や出力の量によって請求額は変わります。定額プランの利用枠、APIの支払額、処理時間も別の指標です。Rubiを導入したから利用枠が同じ割合で増えるとは言えません。まずは同じ仕事で、探索回数・再開時の正確さ・実際の利用量を比べるのがよいでしょう。
v0.4.0で増えた接続先。対応表の「確認済み」にも段階がある
リリース説明では、接続スクリプトがMCPサーバー、指示ファイル、一部の自動フックを設定します。MCPはAIアプリから外部ツールを呼ぶための接続方式です。すべてのアプリで全機能が同じように動くわけではありません。
| 利用先 | 提供元が説明する範囲 | 導入時に見ること |
|---|---|---|
| Claude Code | 記憶、地図、検索の自動注入、引き継ぎ、早期圧縮など | プラグインの設定と早期圧縮の設定は別手順 |
| Claude Desktop | 記憶検索と引き継ぎ。提供元は実接続を確認済みと記載 | Claude Code向け自動フックや早期圧縮がそのまま付くわけではない |
| Codex | MCPと地図・検索フック。提供元は実接続を確認済みと記載 | 今回の編集部検証は設定ファイル生成とMCP処理まで |
| Gemini CLI | MCPとフックを設定 | 提供元の表では資料に基づく設定。実接続検証済みとは区別 |
| Cursor、Copilotなど | MCPと指示ファイルを通じて利用 | 指示に従うかはモデルにも依存。一部クライアントは設定断片を手で貼る |
本体はMITライセンス、実行にはNode.js 18以上が必要です。提供元はWindows・macOS・Linux向けのテストを用意しています。ふくふくで確認したOSはmacOSです。Rubiの検索処理そのものに独自のモデルAPIは不要ですが、接続するAIがメモを作成・参照する際の利用料やプラン制限は別にかかります。
ローカルLLMでも使える。ただし「接続できる」と「使いこなせる」は別
対応表は、ツール呼び出しに対応したローカルモデルも候補にしています。提供元のOllama上のqwen3:4bの試験では、ツールを呼び記憶を保存できた一方、注入した文脈を無視することがあったと記載されています。8B以上を勧める記述はありますが、サイズだけで品質を保証するものではありません。
ローカル運用では、同じファイルを読む量が減れば待ち時間やメモリの負担を減らせる可能性があります。ただし、今回その速度改善は測定していません。重要な判断を正しく記録するか、古い決定を更新できるか、検索結果を実装へ反映できるかを、自分のモデルで確かめる必要があります。
記憶ファイルがローカルにあることと、外部へ何も送られないことも別です。クラウドモデルへ地図やメモを渡せば、その内容は推論入力に入ります。社内の秘密や顧客情報を保存する前に、利用するクライアントとモデルの送信先を確認してください。
日本語で再現した二つのつまずき
2026年10月19日、v0.4.0のコミット8bbdca6をmacOS・Node.js 23.11.0で確認しました。提供元のテスト14件は成功しています。加えて、架空の請求処理を使って記憶の登録と検索を直接実行しました。LLMに回答させた試験ではなく、Rubiの保存・検索処理の試験です。
| 入力・操作 | 確認した結果 | 試すときの工夫 |
|---|---|---|
| 「請求書の二重処理を防ぐ」を記録し、「同じ請求書が再送されたときはどうする？」で検索 | 関連メモが返らなかった | 質問だけでなく、関連する識別名を付ける |
| 同じ質問に関連語billing・refundInvoiceを追加 | 関連付けたsrc/billing.tsを経由して、目的のメモが返った | ファイル・関数との関連付けを保存時から行う |
| 別の判断「認証はセッション方式にする」を日本語だけの見出しで追加 | 両方がdecisao-noという一つの記憶になり、内容が結合された | 見出しに異なる英字の識別名を含める |
| 見出しをbilling-refund＋日本語、auth-session＋日本語として別領域へ登録 | 二つの記憶として分かれた | 作成されたファイル数と本文を確認する |
原因の一つは記憶IDの生成処理です。英小文字と数字以外を除く処理があるため、日本語だけの異なる見出しが同じ識別子へ落ちる場合があります。また検索の文字分割には日本語の単語分割がなく、今回の質問は長い一まとまりとして扱われました。日本語の保存自体が不可能なのではなく、区別と検索に注意が必要です。
今回の回避策は、この二例で確認した範囲に限ります。すべての日本語メモが正しく分離・検索される保証ではありません。AIに任せきりにせず、英字の識別名を含むタイトル、関連ファイル、検索時の関連語をセットで試してください。
まずは設定を変えず、コードの地図だけ試す
いきなり普段の開発環境へ常設する必要はありません。次はv0.4.0を取得して、使い捨ての小さなGitプロジェクトでコード地図を作る例です。Node.jsとGitが使えるターミナルで、まだ同名のフォルダがない作業用ディレクトリから実行します。
git clone --depth 1 --branch v0.4.0 https://github.com/YURIBEDRAN/rubi.gitmkdir rubi-democd rubi-demogit initmkdir srcprintf 'export function refundInvoice() { return true; }\n' > src/billing.tsnode ../rubi/scripts/indexar.mjs .cat .rubi/mapa.mdsrc/billing.tsを含む地図が生成されたら、まず内容が合っているか見ます。次にAIアプリへつなぐ際は公式導入手順に進みます。Claude Codeはプラグイン、Claude Desktopはリリースにあるrubi.mcpb、Codexなどその他の対応クライアントはconectar.mjsを使う経路です。conectar.mjsの--so-mostrarは変更内容を表示するためのオプションなので、実際の書き込み前に確認できます。
接続スクリプトはMCP設定や指示ファイル、一部ではフックを変更します。バックアップを作る実装でも、何を加えるかは先に見てください。早期圧縮の導入スクリプトはClaude Codeのユーザー設定へ書き込みます。今回の試験では、普段の開発アプリにこれらを常設していません。
接続後は、この小さな引き継ぎから評価する
次の指示は編集部が用意した試用案です。モデル経由でこの文章どおり成功するかは未検証です。保存を頼んだ後、作成されたMarkdownを開き、新しい会話で同じ内容を取り出せるか確認してください。
Rubiに設計判断を1件記録してください。
見出し：billing-refund 請求書の二重処理を防ぐ
本文：同じ請求書番号の再送では、返金処理を二度実行しない。
関連ファイル：src/billing.ts
記録後は作成された記憶のIDと保存先を示してください。
次に、Rubiで「同じ請求書が再送されたときはどうする？」を調べてください。検索の関連語としてbillingとrefundInvoiceも渡してください。見つからない場合は推測せず、その旨を伝えてください。続いて別の識別名で認証のメモを登録し、請求処理の記憶へ混ざらないことを見ます。引き継ぎには「終わったこと」「未確認のこと」「次に読むファイル」「次に実行する検査」を残します。会話が短くなっても、未確認事項を完了扱いしないことが基準です。
| 比べる項目 | Rubiなし／ありで残す記録 |
|---|---|
| 再開の正確さ | 前回の判断理由と未完了事項を正しく取り出したか |
| 読む量 | 同じ仕事で開いたファイルと探索回数 |
| 負担 | メモ作成・修正・誤検索の対応に使った時間 |
| 利用量 | 入力、キャッシュ読み、出力、API費用またはプラン枠を混同せず記録 |
| 品質 | 最終的な変更とテストが同じ基準を満たしたか |
.rubi/の記憶はチームでGit共有することも想定されています。既定の除外対象は派生インデックスと自動セッション記録であり、すべての判断メモを隠す設定ではありません。共有前に保存内容を確認し、個人用にする場合はプロジェクト側で.rubi/を除外する運用を選びます。
導入の判断は「安くなったか」だけで終えない
Rubiで注目したいのは、会話を短くしても判断の根拠を残せるという設計です。料金だけを追って大切な条件を忘れたり、記憶を書きすぎて負担を増やしたりすれば逆効果になります。まず一つの小さな仕事で、正しく再開できるかと記録の手間を比べる。それがv0.4.0を評価する現実的な入口です。
確認日：2026年10月19日。主な参照先は公式README v0.4.0、リリース、公開テストです。14件の基礎テストと架空データの日本語保存・検索を確認し、実LLMの費用・速度、日本語回答品質、各アプリでの実接続は測定していません。