論文解説: CodeNib — コーディングエージェントにリポジトリの文脈を「配膳」する多ビューデータシステム

コーディングエージェントが毎タスクgrepで探し直す無駄を、リポジトリを「データベース」と見立てて解消するCodeNib（UCサンディエゴら）。字句・密・構造の3ビュー、差分更新、文脈配信ポリシーの実測を、限界まで含めて読み解く。

CodeNib: A Multi-View Data System for Serving Repository Context to Coding Agents

コーディングエージェントは毎回「初出社」している

優秀な新人が、毎朝記憶を失って出社するところを想像してください。腕は確かなのに、毎日オフィスの地図を書き直してから本題に取りかかる。

コーディングエージェント（LLMがgrepやファイル読み込みなどのツールでリポジトリを操作するプログラム）は、まさにこの状態です。タスクのたびに「あの関数はどこ？」を探し直し、集めた探索結果はタスクが終わると捨てられる。論文はこれを「切り離されたインデックス・言語サーバ・タスクローカルな履歴が、繰り返しの発見作業を強いている」と整理します（Abstract）。2026年7月28日公開のCodeNib（UCサンディエゴを中心とするチーム）は、これをデータベースの問題として捉え直した論文です。

発想の転換: リポジトリは「データベース」である

論文の核はシンプルな見立てです（§1）。コミットは不変のベースデータ、チャンク・転置リスト・埋め込み・シンボル関係はそこから導出されるビュー、エージェントの要求はビューごとのクエリ、プロンプトに入る文脈は上限つきの「配信結果」。

データベースには、集計結果を前計算して保存する実体化ビュー（materialized view）という古典技術があります。作るのは重いが問い合わせは速い、ただし元データが変わったら更新が要る。リポジトリの検索インデックスはコミットを元データとする実体化ビューそのものだ——これがCodeNibの直感で、課題も3つに整理されます（§1）。C1: 形の違うビューの結果を同じ位置に対応づける。C2: 編集は各ビューを別々に壊すので更新経路もビューごとに要る。C3: 前計算した証拠をコストが見える形でモデルの文脈に届ける。

3つのビューと「住所」の統一

CodeNibはソースコードを階層的な単位に切り出します（§4.1）。ファイルが $L_0$、クラスなどの型スコープが $L_1$、関数・メソッドなど呼び出し可能な定義が $L_2$。各単位はパス＋行範囲という「住所」を持ち、その上に3つのビューが載ります（§5）。

• 字句ビュー: BM25の転置インデックス（任意でZoektのトライグラム索引）。キーワードや識別子で引く
• 密ビュー: $L_0$ または $L_2$ 単位を埋め込みベクトルにしてFAISSに格納。意味の近さで引く
• 構造ビュー: ファイル・スコープ・定義を「含む」「参照する」などの型付きの辺で結んだグラフ。定義ジャンプや参照検索に使う

密ビューの検索は、クエリを同じ空間のベクトルにして内積の大きい順に取り出す操作です（コードや文をベクトルに変える仕組み自体は埋め込みを1から理解するを下地にしてください）。内積は2本のベクトルの「向きの近さ」のものさしで、次の部品で体感できます。

3つのビューはバラバラに作られますが、どの検索結果もリポジトリ相対のパス＋行範囲という同じ住所形式に正規化されます。そしてマニフェスト $M_c$ が、コミットごとに各ビューの保存場所・状態・できることを台帳として記録します（§5.4）。ベクトル索引の構築だけ失敗しても、BM25は生きたまま使える——ビューの独立性と台帳による発見可能性が設計の要です。

エージェント側の動きは擬似コードにするとこれだけです（論文Listing 1を要約）。

M = compile(checkout, ["bm25", "vector", "graph"])  # オフラインで構築し台帳に記録
views = load_views(M, needed)   # 実行時は既存ビューを開くだけ。構築はしない
runner = AgentRunner(views, M)  # 検索・定義・参照ツールとしてエージェントに公開