Girder

Girder

Girder は、ファイル全体ではなく、必要なコードだけをエージェントに提供することで、AI コーディングエージェントのコンテキストを節約します。 リポジトリのセマンティックグラフをローカルに構築するため、Claude Code、Codex、Cursor などのエージェントは、無関係なコードでコンテキストウィンドウを埋めることなく、正確な関数、定義、呼び出し元、呼び出し先、タスクのコンテキストを取得できます。アカウントもクラウドへの依存も不要で、単一の静的バイナリとして動作します。

npx -y girder-mcp setup

このコマンドを実行するだけで、Claude Code、Codex、Cursor が検出され、設定されます。

最新の安定版リリース：v0.4.0（Apache-2.0）。 コントリビューションについては、CONTRIBUTING.md をご覧ください。

トークン数ではなく、測定した出力バイト数（トークナイザーは使用していません）：

• girder context ... --json --source-only の CLI 標準出力（MCP の get_source） とファイル全体の読み取りを比較：ソースサイズの十分位ごとに抽出した 10 個の関数で、 バイト数を 97.85% 削減 （測定方法と限界について）。
• girder names ... --json の CLI 標準出力（MCP の find_definition）と通常の grep を比較：10 個の識別子で、バイト数を 97.98% 削減 （測定方法）。
• 1 つのノードに対して、ソース、呼び出し元、呼び出し先、テスト、影響範囲を まとめて取得する 1 回の呼び出しである orient と、それと同等の個別の呼び出しを 連ねた場合を比較：10 個のピン留めされたリポジトリにまたがる 15 タスクの コーパスで、48,814 バイト対 101,302 バイト、15 回対 78 回の呼び出し （測定方法）。

2 つの割合は CLI の出力を測定したものです。MCP のトランスポートによるオーバーヘッドは測定していません。

Girder を支援する

Girder は、コーディングエージェントが消費するコード量を減らせるよう、独立して開発されています。ファイル全体の読み込みやリポジトリの繰り返し検索ではなく、正確なセマンティックコンテキストを提供します。スポンサーシップは、コンテキスト効率、セマンティックグラフの正確性、エージェント連携、再現可能なベンチマーク、メンテナンスの資金に役立ちます。Girder は失敗や制限を含め、測定結果を公開しています。Girder によってコンテキスト、計算資源、または開発時間を節約できた場合は、継続的な開発を支援してください。

資金調達目標： 継続的なメンテナンス、リリース、ベンチマーク、Girder のコンテキスト効率向上の取り組みを続けるため、月額 $1,000 を目指しています。スポンサーシップの使途をご覧ください。

実際に取得した出力です（正確な出典については docs/observations/release-prep/をご覧ください）。

$ girder context demo-project --nodes crate::greeter::shout_greeting --json --source-only
{
  "nodes": [{
    "language": "python",
    "path": "crate::greeter::shout_greeting",
    "source": "def shout_greeting(name):\n    return format_greeting(name).upper()"
  }]
}

ファイル全体ではなく、1 つの関数のソースコードだけを正確に返します。これこそが、Girder がエージェントのコンテキストウィンドウに提供する中核的な機能です。

言語の状況を、同等性ではなくありのままに示します： Rust と Python はそれぞれ、固定された 3 つのリポジトリで 100 件の呼び出し箇所の監査を完了しており、そのサンプル内に不健全な回答はありませんでした。どちらも Must が 1 件、Unknown が 99 件という結果でした。精度に関する根拠は限られています（測定）。TypeScript は測定とゲート設定が行われていますが、明確に開発中です。別途開示されているノード ID の衝突メカニズムが依然として存在します（it()／describe() の説明文字列が重複すると、互いのグラフノードが通知なく上書きされる可能性があります。詳しくはdocs/observations/stage3-typescript-audit/をご覧ください）。Go の Stage 3 監査は未完了です。それぞれの正確な測定済みの制限については、 docs/typescript-support.mdと docs/go-support.mdをご覧ください。

同じグラフを基盤として構築された追加機能として、変更影響の保守的な分析とテスト選択も含まれています： test-impact は、同じセマンティックグラフを使って、変更の影響を受ける可能性があるテストを示します。影響がないと判断できないテストは、通知なく除外するのではなく、含める方向に動作します。実際に取得した出力：

$ girder test-impact . --quiet
test-impact: 82 unresolved call-evidence boundaries found; this selection is the conservative must∪may∪unknown union — pass --classified to see why each test is included
test_farewell
test_format_greeting
test_shout_greeting_delegates_to_format_greeting

このテスト選択で何が証明でき、何が証明できないかについては、ステータスをご覧ください。

価格とライセンス： Girder はApache License 2.0のもとで無料のオープンソースソフトウェアとして提供されています。現在、有料プランはなく、ライセンスキーもアカウントも不要です。ライセンスをご覧ください。

懐疑的な読者のための根拠： docs/evidence-index.mdには、上記の主張を裏付ける、コミット済みのすべての監査、測定、敵対的な調査結果へのリンクがあります。最終的な数値だけでなく、過程で見つかり修正されたバグも含まれています。

インストール

Rust のツールチェーンが不要な、ビルド済みバイナリ：

curl -fsSL https://raw.githubusercontent.com/dhishwasher/Girder/main/install.sh | sh
girder --version

またはソースから：

cargo install --path crates/aether-app
girder --help

これにより、デフォルトのヘッドレスプロファイルがビルドされ、girder バイナリが ~/.cargo/binにインストールされます（このディレクトリがPATHに含まれていることを確認してください）。GPU、ディスプレイ、ネットワーク、API キーは不要です。

Windows インストーラー

各 Windows リリースには、Girder-<version>-setup.exeも含まれています。現在のユーザーの %LOCALAPPDATA%\Programs\Girder にインストールされ、Girder がユーザーのPATHに追加され、スタートメニューにショートカットが作成されます。管理者アクセスは求められません。インストール後、更新されたPATHが反映されるよう、新しいターミナルを開いてください。インストーラーにはデスクトップ GUI が含まれており、スタートメニューのショートカットから起動できます。アーカイブと npm インストールでは、引き続きヘッドレス CLI が提供されます。

インストーラーはまだコード署名されていないため、初回起動時に Windows SmartScreen の警告が表示されます。GitHub のリリースからインストーラーをダウンロードしたら、ダブルクリックして、「Windows によって PC が保護されました」というダイアログで詳細情報を選び、アプリが Girder であり、発行元が不明と表示されていることを確認してから、実行を選択してください。これらの詳細が一致しない場合は、キャンセルしてください。

競合製品とのベンチマーク

20 タスクの小規模なクロス言語ベースセットでは、Girder は 5/20、Ripwire は 7/20 を達成し、敗北しました。しかし、両製品が成功した 60 回の試行では、 Girder の返却バイト数は 35,764 バイト、Ripwire は 158,514 バイトで、 同じ呼び出し回数（それぞれ 120 回）において Girder は 77.4% 少ない結果でした。 GitNexus は採点できませんでした。この測定マシンではインストールに 1 GiB の固定上限を 超える容量が必要だったためです。これは制約のあるホストでのインストール容量についての 事実であり、品質に関する主張ではありません。

このベンチマークで完全な正確性を達成した製品はなく、総合的に最良の製品を 示すものでもありません。手法、言語別の結果、および上記の数値からは 明らかにならない点については、全編の レポートを ご覧ください。

AI コーディングエージェントから利用する

girder mcp は、読み取り専用のグラフコマンドを Model Context Protocol 経由で提供します。 これにより、エージェントはコードをコンテキストウィンドウに読み込まずに、 コードベースについて質問できます。

変更をプレビューしてから、検出されたエージェントを設定します。

npx -y girder-mcp setup --dry-run
npx -y girder-mcp setup

setup は Claude Code（~/.claude またはホームディレクトリ内に既存の プロジェクト .mcp.json がある場合）、Codex（~/.codex またはホームディレクトリ内の CODEX_HOME）、Cursor（~/.cursor）を検出します。検出された各エージェントの 文書化された設定に girder MCP エントリをマージし、Claude Code と Codex には ネストされた PreToolUse および PostToolUse フックをインストールします。 Pre フックは構造化された Read、read_file、mcp__.*__read_file イベントに対応し、 post フックは Claude の Edit|Write|NotebookEdit および Codex の apply_patch|Edit|Write という編集名に対応します。シェルコマンドは意図的に解析しません。 Cursor はフックを文書化していますが、ブロックせずに助言的なコンテキストを追加できる pre-read フックはありません（preToolUse と beforeReadFile で許可、拒否、または 入力の書き換えのみが可能で、事後に additional_context を返すのは postToolUse と sessionStart だけです）。そのため、setup は Cursor に MCP と プロジェクトルールを登録しますが、フックは登録しません。汎用 MCP クライアントには 共通の設定パスがないため、未検出として報告されます。Setup がホームディレクトリの 外に書き込むことはありません。既存の他製品の girder エントリは、--force を 指定した場合も変更されません。girder setup --uninstall は setup が所有する変更のみを 削除します。

最初に方向づける指示。 MCP に加えて、setup は各クライアント固有の方法で共通の 短い指示をインストールします。これにより、エージェントは広範な読み取りや grep の前に Girder の orient を呼び出し、Girder の判断に確信がない場合はその旨を伝え、 推測するのではなくソースを読んで確認するようになります。

クライアント	指示の保存場所	備考
Claude Code	~/.claude/CLAUDE.md 内の区切られたブロック	Claude Code はユーザーとプロジェクトの CLAUDE.md ファイルをコンテキストに連結します
Codex	$CODEX_HOME/AGENTS.md 内の区切られたブロック（デフォルトは ~/.codex/AGENTS.md）	空でない AGENTS.override.md がある場合はスキップされ、その旨が報告されます。Codex はその場合 AGENTS.md を無視するためです
Cursor	現在のプロジェクト内の .cursor/rules/girder-orient.mdc。girder setup --project を指定した場合のみ	プロジェクトルールは alwaysApply: true を設定した .mdc ファイルです。Cursor はユーザールールのファイルパスを文書化していないため、書き込みは行われません

このブロックには目印が付けられ、girder-setup-state.json に記録されます。setup を 再実行しても変更はなく、--uninstall はファイルを完全に元の状態に戻し、編集済みの ブロックには手を加えず、--no-instructions を指定するとこの手順はスキップされます。 上記の形式は、2026-10-06 に各クライアント独自の文書に照らして確認済みです。 出典と引用は docs/observations/stage4-clients/ にあります。 どの形式で何がインストールされるか。 ビルド済みまたはインストール済みのバイナリから girder setup を実行すると、MCP、フック、インストラクションがインストールされ、インストール済みのバイナリ（<path-to-girder> mcp .）を起動するMCPエントリが書き込まれます。これにより、クライアントは起動時にパッケージをダウンロードせず、ローカルの Girder を実行します。npx -y girder-mcp setup は 公開済み パッケージのセットアップを実行します。インストラクションが含まれるリリースが公開されてから、インストラクションが一度だけインストールされます。セットアップを npx の一時キャッシュから実行すると、安定したバイナリパスがないため、エントリは npx -y girder-mcp . のランチャー形式にフォールバックし、その旨がセットアップで通知されます（Girder をインストールしてから girder setup を実行すると、ローカルバイナリに切り替わります）。

パッケージ化されたフックランチャーは、各イベントをピン留めされたネイティブの girder hook 実行ファイルに転送し、エラー時も処理を継続します。単独の PreToolUse JSON だけが stdout に転送されます。編集後のネイティブ診断は stderr に出力され、MCP は引き続き独自の stdout で JSON-RPC を使用します。読み取り時のアドバイザリーは、project.aether がすでに存在する場合にのみガイダンスを提供します。編集後のアドバイザリーは、保存済みのグラフスナップショットを使用し、プロジェクトのスキャンや再ビルドは行わず、変更されたファイルの最後に解析されたバージョンについて説明します。設定パス、所有権、手動での JSON フォールバックについては、セットアップとクライアントパスのガイドを参照してください。

セットアップで検出できないクライアントや、手動で設定する場合は、クライアントのドキュメントに記載されている MCP 設定にエントリを追加してください。クライアントごとの配置場所は次のとおりです。

クライアント	場所	形式
Claude Code	プロジェクトの .mcp.json またはユーザーの ~/.claude.json	JSON mcpServers.girder（下記）
Cursor	プロジェクトの .cursor/mcp.json またはユーザーの ~/.cursor/mcp.json	JSON mcpServers.girder（下記）
Codex	~/.codex/config.toml（または信頼済みプロジェクトの .codex/config.toml）	TOML テーブル。JSON の後に記載
その他の MCP クライアント	そのクライアントのドキュメントに記載されている MCP 設定	同じ command と args

JSON 形式：

{
  "mcpServers": {
    "girder": {
      "command": "npx",
      "args": ["-y", "girder-mcp", "."]
    }
  }
}

Codex では代わりに TOML テーブルを使用します。

[mcp_servers.girder]
command = "npx"
args = ["-y", "girder-mcp", "."]

バイナリがすでにインストールされている場合、"command": "girder", "args": ["mcp", "."] を使うと npm を完全に省略できます。任意のクライアントに手動でインストラクションを設定するには、npm/instructions/orient-first.md のテキストを、ドキュメントに記載されているインストラクションファイル（CLAUDE.md、AGENTS.md、または Cursor の .mdc ルール）に貼り付けてください。

Girder 0.2.6 以降では、girder mcp . --watch または npx -y girder-mcp . --watch で、キャッシュされたグラフ生成を利用できます。サーバーは検証済みのグラフ生成を1つメモリに保持し、変更されたファイルを増分解析します。コミット済みのウォッチャー測定では、ファイル抽出の98.70%を再利用しながら、45回すべての変更後に新規のコールド解析と一致しました。この主張は、解析を再利用しながらコールド解析時の解決結果を維持することに限定されます。ウォッチャーの結果と制限事項を参照してください。

ツールは7つあり、すべて読み取り専用で無料です。

ツール	回答できる内容
get_source	ファイル全体ではなく、特定の関数のソース。
find_definition	完全一致する識別子の宣言箇所。部分文字列検索ではありません。
search_code	名前がわからない場合に、説明に一致する関数。
ask_codebase	グラフをたどって呼び出し元、呼び出し先、影響範囲を特定します。
impacted_tests	変更の影響が及ぶ可能性がある保守的なテストの集合。下記のアドバイザリーを参照してください。
review_changes	作業ツリーで変更された内容を、テキストではなく意味として説明します。
orient	1回の呼び出しで、1つのノードのソース、呼び出し元、呼び出し先、テスト、影響を示します。

何を節約でき、何を節約できないか

orient は、get_source ＋ ask_codebase（呼び出し元、呼び出し先、影響範囲）＋ impacted_tests が個別に答える内容を、通常なら5〜6回の呼び出しに分かれるところ、1回にまとめます。固定した10個のリポジトリにまたがる15タスクのコーパスでは、この1回の呼び出しに使われた合計バイト数は、置き換えられる呼び出しの連鎖より少なく（48,814対101,302、比率0.48）、ラウンドトリップを78回から15回（タスクごとに1回）に削減しました。また、開示された2つの欠陥を修正した後は、ゲート付きチェック37件すべてが合格しています。最初の実行で、impacted_tests --quiet がRust/Python以外のテスト名を黙って除外していることがわかりました（orient 自身のテストカバレッジのセクションにはこの不具合がなかったため、発見につながりました）。このフィルターは現在削除されています。自然言語の intent 入力には、引き続き search_code の精度が引き継がれます。このコーパスでは、intentタスク3件すべてで誤ったノードが特定されましたが、今回の修正では変更されておらず、対象範囲外です。一方、当初は3件とも検出できなかった orient の信頼度ヒューリスティックは、候補スコアを付けて3件すべてに "confidence": "low" のフラグを付けるようになりました。ただし、次点候補のスコアが近い場合は、正しい特定にもフラグが付くことがあります。docs/orient-tool.md と、コミット済みのポリシー／元の観測結果／修正後の観測結果を参照してください。

事前にコミットされた追加の測定値が2つあります。どちらもトークンではなく、コマンド出力のバイト数を数えたものです（トークナイザーは実行していません）。

• girder context ... --json --source-only（MCP の get_source が呼び出す処理）と、単純にファイル全体を読み込む場合の比較：ソースサイズの十分位数ごとにサンプリングした10個の関数で、CLIの標準出力バイト数が97.85％減少し、10件すべてでより少ないバイト数でした（docs/context-vs-read-cost.md）。
• girder names ... --json（MCP の find_definition が呼び出す処理）と、単純なgrepの場合の比較：10個の識別子で、CLIの標準出力バイト数が97.98％減少しました（docs/names-cost.md）。

MCPのトランスポートオーバーヘッドとトークン数は測定していません。

どちらも単一リポジトリでの測定です。傾向は構造に由来します。ファイルはその中の関数よりはるかに大きく、grepはすべての出現箇所を返す一方、find_definition は宣言だけを返します。ただし、正確な削減率を別の環境にそのまま当てはめることはできません。

これらの比較では、grep検索と範囲を限定したファイル読み込みを適応的に選ぶ、有能なエージェントの性能は測定していません。エージェントによるgrepのコストに関する主張は、ここでは裏付けられていません。

その後実施した、ローカルの1.5Bモデルを使ったエージェントによるgrepのキャンペーンは未完了のまま終了し、両方の回答が正しい組み合わせは得られませんでした。比較上のコスト優位性も、フロンティアモデルの動作も立証していません。

impacted_tests の結果は参考情報です。無関係なテストも選びすぎるほか、動的ディスパッチの形状によっては、依然として解決できないものがあります。Girderが呼び出し箇所を証明できない場合、固定されたポリシーでは、安全にスキップできると推測するのではなく、関連テストを含めることが求められています。そのため、現在測定されている影響は、テストを黙って見落とすことではなく、過剰に含めることです（代表的なポリモーフィックディスパッチのケースでは、再現率 1.000、適合率 0.667）。ディスパッチ解決の根本的な不足は未解決のままです。選択時にテストが黙って除外されなくなっただけです。測定結果と変更点の詳細は、docs/core-representative-mutations.mdを参照してください。変更が安全だと判断する前に、完全なテスト実行を行う必要があります。

テストを余分に選ぶとCPU時間がかかります。一方、関連するテストを見落とすと、リグレッションが見つからない可能性があります。

サーバー起動時にプロジェクトルートが固定されるため、別のディレクトリにアクセスするツール呼び出しはできません。GIRDER_MCP_TIMEOUT_SECONDS（デフォルトは120）で各呼び出しの制限時間を設定できます。非常に大きなリポジトリでは値を増やしてください。

以下ではすべて、girder が PATH 上にあることを前提としています。ソースチェックアウトからインストールせずにビルドする場合も、girder の代わりに cargo run -p aether-app -- を使えば同じように実行できます。

クイックスタート

# Full end-to-end demo — no GPU, display, or API key required:
girder

# Run the test suite:
cargo test --workspace

リポジトリを分析する

CLI を使って、リポジトリのセマンティックグラフを構築してクエリを実行します：

# Build the semantic graph from a project and save it as <dir>/project.aether:
girder analyze sample-project

# Inspect a saved graph and a node's impact set:
girder inspect sample-project/project.aether crate::lib::add

# Graph-semantic rename — follows Calls edges (not text search) and rewrites
# only the real callers, then saves the updated graph:
girder refactor sample-project rename crate::lib::add plus

# Emit graph context, a real Plan Format v2 authoring schema, and a plan
# skeleton as one JSON object — for pasting into any external chat model.
# See "External authoring" below for the full loop to a verified, applied edit:
girder context demo-project --nodes crate::greeter::farewell "add an exclamation mark to the farewell" --json

# Validate/inspect/execute a plan file directly:
girder plan validate my-plan.json
girder plan explain my-plan.json
girder plan run my-plan.json --dry

# Semantic code review vs HEAD (typed mutations, not text diffs):
girder review sample-project --since HEAD~1

# Conservative test selection: find every test that might be reachable
# from changed functions:
girder test-impact sample-project --run

# Knowledge-graph query — answer a question by traversing the semantic graph:
girder query sample-project "what would break if I change add?"
girder query sample-project "what calls sum_list?"
girder query sample-project  # interactive REPL (reads stdin)

# Full help:
girder --help

外部オーサリング：girder context + plan run --authored

girder do は、組み込みのプロバイダー（OpenAI、Anthropic、Ollama、またはオフラインの MockProvider）を自動的に利用します。girder context と plan run --authored は、同じワークフローをモデルとの境界で分割するため、このコードベースに API 統合がまったくないモデルを含む、あらゆるチャットモデルで検証済みのグラフ編集を作成できます。

読み取りのみで、オーサリングはしませんか？ --source-only を追加してください。以下のデフォルト出力には Plan Format v2 のスキーマとプランの骨組みが含まれています。これは固定の約 6 KB で、編集をオーサリングするモデルには必要ですが、コードを読むだけのモデルには不要です。10 個のノード中 2 個ではファイル全体を読むよりコストが高く、小さなノードではファイルの 15.6 倍でした。--source-only を指定すると、この構造を省き、同じ 10 個のノードでファイルを読む場合より 97.85% 低コストになることが実測されています（docs/context-vs-read-cost.md）。 base_commit を固定する必要がないため、Git リポジトリも不要です。

オーサリングのループ：

# 1. Emit graph context, a real Plan Format v2 authoring schema, and a plan
#    skeleton (base_commit, on_failure, the mandatory tests.impacted check)
#    as one JSON object:
girder context demo-project --nodes crate::greeter::farewell \
  "add an exclamation mark to the farewell" --json > context.json

# 2. Paste context.json into any chat model. Ask it to fill in the plan
#    skeleton's step (id, description, edits) so the step satisfies the
#    schema exactly, and save its response as plan.json — the schema is the
#    literal Plan Format v2 the executor loads, not an approximation of it,
#    so a model that follows it produces a file that loads without
#    translation.

# 3. Run and verify it. `plan run` has no project-directory argument — the
#    root is always the current directory, so run this from inside
#    demo-project/. --authored applies the same harness guarantees `do`
#    applies internally to a model-authored plan: on_failure is forced to
#    rollback_plan, a tests.impacted check is injected if the plan doesn't
#    already carry one, and a zero-step plan is refused outright rather than
#    passing vacuously. --authored-by <name> records who authored it in the
#    written report:
(cd demo-project && girder plan run ../plan.json --authored --authored-by claude-opus-5)

実行が成功すると、編集内容が実際のツリーに適用され、.girder/reports/ の下にレポートが書き込まれます。チェックに失敗すると、ツリーは自動的に base_commit にロールバックされるため、信頼できない外部モデルによる不正な編集が中途半端に反映されることはありません。plan_schema() の正確な構造（各編集／チェック種別に対応する oneOf 判別可能ユニオンで、planfile::schema のデシリアライザーのフィールドと一つずつ一致します）により、ステップ 2 の信頼性が確保されています。これによって解消された不具合と、それを証明するラウンドトリップテストについては、docs/core-gap-analysis.md のギャップ 17 を参照してください。

デモの対象：demo-project/。sample-project/ は使用しないでください

girder do と plan run --authored は、sample-project/ を対象として指定すると、実行を拒否し、代わりに demo-project/ で実行するようエラーで案内します：

$ girder do sample-project "uppercase greet's return value"
error: sample-project/ is a pinned measurement fixture (see gap 18/21 in
docs/core-gap-analysis.md) and refuses authored writes; run demos against
demo-project/ instead

sample-project/ は、グラフアドレス方式のオーサリングコスト測定コーパス用に、特定のクリーンなソースコミットを対象として tools/authoring_task_check.py と tools/plan_executor_oracle.py が読み込む、固定されたベースラインです。一時的な作業対象ではありません。実際に書き込む（ドライランではない）オーサリングをここで行うと、測定ハーネスが依存する同じファイルが変更されます。これは 3 日間隔で 2 度発生し、フィクスチャのずれが見つかるまで、壊れた判定プログラムのデバッグに丸 1 日を費やしました。詳細は docs/core-gap-analysis.md のギャップ 18 を参照してください。demo-project/ は、同じことが二度と起きないように用意されています。tools/ や docs/ のどこからも読み込まれない、小さく使い捨て可能な Python プロジェクトで、実際に書き込む（ドライランではない）オーサリングにも安全です。読み取り専用コマンド（context、search、analyze、test-impact）は引き続き sample-project/ に対して実行できます。拒否されるのは、書き込みを行う 2 つのコマンドのみです。

ワークスペース

クレート	役割
aether-graph	稼働中のセマンティックグラフ：ノード／エッジ、影響分析、.aether のシリアライズ。信頼できる唯一の情報源です。
aether-builder	tree-sitter からグラフへのマッピング、インクリメンタルな編集同期、構文ハイライト用スパン。
aether-ai	AiProvider トレイト、オフラインの MockProvider、OpenAI／Anthropic のライブプロバイダー、マルチプロバイダーの Router、プロバイダー拡張ポイント。
aether-app	girder バイナリ：MCP サーバーとグラフ CLI。

ワークスペースには、エージェントスウォーム、コラボレーション、トレーサーと DAP アダプター、拡張機能、デスクトップ GUI などの旧サブシステムも含まれています。これらは公開ツールの一部ではなく、デフォルトでは無効で、--features legacy を指定した場合にのみビルドされます。

ステータス

Girder は、コーディングエージェント向けのセマンティックグラフ MCP サーバーおよび CLI です。 以下の測定結果は、グラフの現在の動作と限界を示しています。

検証済みの コア信頼性測定 では、影響を受けるテストの選択と、分離されたランタイム実行を比較しています。範囲を限定したベースラインでは、Rust と Python の適合率／再現率はいずれも 1.000/1.000 です （以前の 0.667 だった Rust の適合率の不具合は解消されています）。これは小規模なフィクスチャでの結果であり、代表的なリポジトリでの優位性を主張するものではありません。また、反証となる証拠も併せて検証されています。実際の依存関係でポリモーフィックディスパッチに変異を加えた場合、現在の再現率は 1.000、適合率は 0.667 です （docs/core-representative-mutations.md）。2026-10 の修正により、ディスパッチを解決できない場合に、選択からテストが黙って除外されることはなくなり、代わりに保守的な和集合にフォールバックするようになりました。根本にあるディスパッチ解決の不備は変わっておらず、修正されたのは黙って見落とす症状だけです。このため、テスト選択は確定的なものではなく、参考情報として文書化されています。

実装済みの機能：

機能	内容
セマンティックグラフ	ノード／エッジ、Rust のエイリアス／戻り値／スコープ付きパターン／Cargo エントリーポイントを考慮した機能および Python のエイリアス／nullable アノテーション／コンストラクターを考慮したファイル間の呼び出し解決、リテラルを考慮したマクロ呼び出し、影響範囲 BFS、類似性エッジ、厳密なバージョン管理付き .aether 永続化とソース照合
セマンティックレビュー	型付き差分（追加／変更／削除されたノードおよびエッジ）、影響範囲、テスト不足レポート
保守的なテスト選択	変更された関数からの呼び出しグラフ到達可能性、任意の --run
プロジェクト契約	ソース範囲、グラフパス、テストランナー、エージェント出力を対象とする検証済み girder.toml
ソースへの反映	作成したプランの編集とグラフの名前変更コミットにおいて、復旧可能なジャーナル付きトランザクションを通じて、検証済みのソースとグラフを反映
候補の検証	使い捨てのプロジェクトコピー、任意の bubblewrap 分離、Cargo のビルド／テスト、設定済みチェック、キャンセル／タイムアウト、上限付き診断情報、スナップショットに紐づくコミットゲート
外部での作成	girder context は、グラフのコンテキストと、外部のチャットモデル向けの実際の Plan Format v2 スキーマを出力します。plan run --authored は、結果に対してロールバック／影響テストの保証を再適用します

測定済みの基本機能の比較、現在の正確性を示す証拠、優先順位付きの未解決リスクは、 docs/core-gap-analysis.md で管理されています。

ライセンス

このリポジトリにある Girder のソースは、Apache License, Version 2.0 の下でライセンスされています。このライセンスの条件に従う限り、商用利用、変更、再配布、フォーク、ホスト型サービスでの利用が許可されます。正式なライセンス条文は LICENSE を参照してください。

以前公開された v0.3.2 npm パッケージとリリースバイナリは、公開時の BUSL ライセンスが引き続き適用されます。公開済みのリリースは変更されません。現在の v0.4.0 npm パッケージとリリースバイナリには Apache-2.0 が適用されます。

現在、有料プランはなく、提供されているすべてのツールに利用制限はありません。アカウントもライセンスキーも不要です。以前のリリースで発行された署名済みライセンスキーをすでにお持ちの場合、当時そのキーで利用可能になった機能は引き続き利用できます。ライセンスキーの仕組み自体（GIRDER_LICENSE_KEY または OS ごとのキーファイル。オフラインで検証され、ホームへの通信はありません）は、過去の互換性を保つためだけに残されています。

以前のリリースには、公開時の条件が引き続き適用されます。これは遡及的な再ライセンスではありません。貢献に関する条件は CONTRIBUTING.md を参照してください。