Celmis

セルフホスト型コードインテリジェンス — コードベースに質問し、プルリクエストをレビューし、監査人が求めるエビデンスを作成する

celmis-labs.github.io · ドキュメント · クイックスタート · 結果

Celmis はリポジトリを一度だけ読み取り、そのシンボルグラフを保持します。その他すべて — 質問、レビュー、依存関係の監査、生成ドキュメント — は、そのグラフを読む別の方法です。docker compose のもとで1台のマシン上で動作し、背後には任意のモデルプロバイダーを置けます。設定した呼び出し以外は、ネットワークの外に出るものはありません。

最も古い伝承では、Kelmis は製錬者でした — 鉄の加工を担ったとされる3人のイデー山のダクテュロイの一人で、槌の Damnameneus と金床の Acmon と並んでいました。ここで還元を行うのはインデックスであり、その結果を加工するのはサーフェスです。

diff のみのツールにはできないこと

2つのリポジトリにまたがる質問をすると、回答は両方を引用します：

これは検索結果ではありません。ゲートウェイと決済サービスは共通コードのない別々のリポジトリですが、回答は両者の間の呼び出しチェーンを追跡し、さらに促されなくても、Kafka のトピック名が両方にハードコードされていて、一方を変更するともう一方が静かに壊れることに気づきます。

構造的に差分のみを読むレビュアーはそんなことは言えません。もう一方のリポジトリを開いたことがないからです。

Related MCP server: OpenCodeHub MCP Server

人々がこれで行う7つのこと

最初の3つは、コードレビューツールがまったくやらないことです。そして、これがレビュアーではなくプラットフォームである理由です。一度インデックスを作成し、そのインデックスを、作業のどの側からでも読むことができるのです。

3つの数字

最後の数字は意図的に不面目なもので、そのまま残しています。これは下記のサーフェスの1つ — 分離された単一リポジトリのPRに対するプルリクエストレビュー — を測定したもので、そのセットにはシンボルがコンシューマを持つための兄弟サービスが存在しないため、この製品が中心に据えているものはその数字にまったく含まれていません。表、誤りと判定されたすべての所見の監査、およびその両方を再現するコマンドは 結果 にあります。

目次

• diff のみのツールにはできないこと

• 人々がこれで行う7つのこと

• 3つの数字

• クイックスタート

• 最初のユーザーと管理者

• リポジトリを接続する

• コードに問い合わせる

• プルリクエストレビュー

• 依存関係、SBOM、エビデンスパック

• ここから修正する

• 誰が何を見られるか

• 言語とフォーマット

• 決定的チェック — モデルなし、誤検知なし

• Claude Code や他の MCP クライアントを接続する

• 結果

• 誤検知の監査

• テストリポジトリ

• 設定

• 運用

• ローカル開発

• CLI リファレンス

• アーキテクチャ

• トラブルシューティング

• プロジェクト構成

• 由来と権利

クイックスタート

必要なもの

Postgres と Qdrant はバンドルされています — 外部クラスターの用意は不要です。Docker フローでは Python や Node.js のインストールは必要ありません。

起動する

git clone <your-fork-url> celmis
cd celmis

# Generates .env and fills every secret in the format each one needs.
# Idempotent: run it again after a pull and it fills only the new blanks.
./scripts/init-env.sh

docker compose --env-file .env up -d

# Wait for healthy — first boot pulls three images and applies migrations
docker compose ps

http://localhost を開いてください。

ここでは何もビルドされません。3つのイメージは、CELMIS_REGISTRY で指定されたレジストリから、CELMIS_TAG のタグで、linux/amd64 と linux/arm64 向けにプルされます — Apple Silicon と ARM サーバーの両方でネイティブイメージが得られます。それらを実行するマシン上でビルドすると、api だけで485秒と4.2GBのディスクを要すると測定されました。そのため、インストールがコンパイルを意味することはもうありません。

ポートは3000ではなく80です。リバースプロキシがアプリとその API を1つのオリジンに配置し、API を /backend 配下で提供します。これはデプロイの好みではありません。ブラウザバンドルは相対パスを要求します。それは、公開された1つのイメージが、ビルドされた環境だけでなく、すべてのインストール環境にサービスを提供できる唯一の方法です。

Celmis を実行するのではなく、Celmis の上で開発するには、dev オーバーレイを追加するとローカルビルドが復活します：

docker compose -f docker-compose.yml -f docker-compose.dev.yml up -d --build

init-env.sh --check は、何も書き込まずに、まだ空の項目を報告します。

これはキャプチャされたセッションのレンダリングであり、画面録画ではありません — 中の数値は、2026年8月26日にその実行が生成したもので、compose の出力はインストールレポートの logs/03-up.log からの逐語的なものです。写真ではなく描画であるのは、実行中のスタックの隣で2つ目のスタックを起動できないためです: docker-compose.yml が container_name を固定しているため、名前が衝突します。

停止する

docker compose down       # stop, keep your data
docker compose down -v    # stop and DELETE every volume

最初のユーザーと管理者

/login のサインアップフォームは、スタックが健全になるとすぐに動作します。そのアカウントは通常ユーザーです。サインアップしても管理者権限は付与されません。最初に申し込んだ人にもです。

代わりに、グローバル管理者は環境から来ます: .env 内の CELMIS_MASTER_EMAIL と CELMIS_MASTER_KEY（パスワードとして）でサインインします。ボックスを実行している人が管理者です。これは、最初にフォームに到達した人ではなく、セルフホストインストールが望むモデルです。このパスは、両方の変数が設定されていない限り存在せず、その使用はすべて監査ログに記録されます。

通常アカウントを昇格させるには：

docker compose exec api analyzer auth make-admin you@example.com

リポジトリを接続する

1. 設定 → LLM セットアップ — プロバイダーキーを貼り付けます。キーはデータベースに触れる前に CREDENTIAL_MASTER_KEY で暗号化され、UI が再び表示するのは最初と最後の4文字だけです。

2. 接続 — GitHub、GitLab、または Bitbucket のトークンを追加します。自分のアカウントではなくマシンアカウントを使用してください。個人トークンは自分が見えるすべてのリポジトリに到達でき、トークンはバックアップ、ログ、スクリーンショットに残ってしまうからです。

3. リポジトリ → 追加 — プロバイダーからリポジトリを選択するか、clone URL を貼り付けます。インデックス作成はキューに入り、ジョブは同じページに表示されます。

インデックス作成は、同じチェックアウトから2つのものを構築します: シンボルグラフ（定義、呼び出し、インポート — レビューエージェントが推論の基盤とするもの）と、Qdrant 内の埋め込み（Q&A が取得するもの）です。12万シンボルのリポジトリは、4コアで約1分かかります。

23の言語がこのグラフにパースされます。パーサーのない言語のファイルは、黙ってスキップされるのではなく、その旨が明示されます — analyzer graph-stats は、読み取られたものと読み取られなかったものを一覧表示します。

コードに問い合わせる

チャットでの質問に対し、指定したリポジトリから file:line 引用 付きで回答します。回答は、作成されながらストリーミングされます。

リポジトリをプロジェクトにグループ化すると、質問はそのグループに対して行われます：

回答は実際のコードを引用しますが、それは質問者が見ることを許可されているコードだけです。そのため、リポジトリを所有するチームの外部の人に質問を渡しても安全です。誰が何を見られるか を参照してください。

プルリクエストレビュー

エージェントは diff を読み、所見を GitHub、GitLab、Bitbucket に投稿します。このインターフェースのスクリーンショットで示すのではなく、レビューは投稿された場所にそのまま残されています — 実プロジェクト上の50件のプルリクエストで、コメントは書かれた対象の行に付いたままです。それらは テストリポジトリ の下に一覧表示され、そこでの出力は未編集です。下の監査が誤りと判定した所見も含めてです。

グラフが構築されている場合、レビューには diff に表れない情報も含まれます。変更対象のシンボルを他に誰が呼び出しているか。別のリポジトリからの呼び出しも含みます。グラフが構築されていない場合でもレビューは動作します — ただ、より狭い問いに答えるだけです。ベンチマークが測定したのはその点です。

ベンチマークが偽陽性と判定したすべての所見は、ソースリポジトリで issue として起票され、判定付きで公開されています。79件中33件は、ゴールドセットに含まれていない実際の欠陥であることが判明しました。その成果は 偽陽性の監査 にあります。各所見についてコードとパーマリンクが付いているため、どれについても異議を唱えることができます。

依存関係、SBOM、エビデンスパック

依存関係の監査は決定的です。ツールがインストールされている場所ではネイティブ監査ツール、それ以外では OSV を使い、モデルは関与しません。言語モデルは、キーを与えれば要約を書きますが、何が脆弱かを判断するのはモデルではありません。

すべての監査から2つのファイルが生成され、どちらも LLM キーは必要ありません:

• SBOM — すべての依存関係とそのバージョン、パッケージ URL、既知の脆弱性をまとめた CycloneDX インベントリ。「SBOM を送ってください」と言うときに人々が指しているのはこのファイルです。

• エビデンスパック — 監査を提出用にまとめたもの。すべての SBOM、すべての所見、過去の実行のタイムライン、各ファイルの sha256 が含まれ、第三者が 私たちを信頼することなく 後から何も編集されていないことを確認できます。後から内容を変更できるフォルダは何の証明にもなりません。それをエビデンスにするのはマニフェストです。

それらに加えて、生成された技術ドキュメント — コードから書かれたモジュール PRD、機能ドキュメント、統合ガイド — があり、これらはお客様が保持でき、サブスクリプション終了後も機能し続けます。

なぜ今なのか。 2026年9月11日から、EU サイバーレジリエンス法は、製造者に対し、現に悪用されている脆弱性を24時間以内に ENISA へ報告することを義務付けます。正式な SBOM 義務は2027年12月に施行されますが、まずコンポーネントレベルの可視性がなければ24時間の問いに答えることはできません — 影響を受けるものを報告するには、内部に何があるかを知る必要があるからです。

Celmis はコンプライアンス適合を主張しませんし、今後も主張しません。 Celmis が生み出すのは提出に必要な成果物です。提出が適切かどうかは弁護士の判断であり、そうでないと示唆するツールは誤った安心感を売っているにすぎません。

監査ページが声を大にして言うもう一つのこと。それは誰も探さない失敗です。誰もスキャンしていないエコシステムは、クリーンなエコシステムとまったく同じように脆弱性ゼロと報告します。 カバレッジは所見の横に表示されます。どの監査ツールが各結果を生成したか、そしてより有用なことに、何が未チェックのままで、なぜなのか。

ここから修正する

何かを見つけることはループの半分です。組み込みの Claude Code セッションがインストール環境の内部で実行され、チェックアウトを編集します。ランナーはコミットし、ブランチをプッシュし、プルリクエストを開きます。

依存関係監査の脆弱性には、Fix with Claude ボタンが付いています。これは空のチャットを開くのではありません。リポジトリ、パッケージ、両バージョン、ジョブの境界を、あらかじめ記述された状態でセッションに渡します:

実際の所見 — 既知の脆弱性がある lodash 4.17.11 — を使った、このようなループの一例を最初から最後まで示します。Start session からプルリクエストが開かれるまで 220秒、5ターンで完了します:

Read package.json
  → "Only package.json has lodash; no requirements.txt/pyproject/go.mod exist here."
Edit package.json: "lodash": "4.17.11" → "4.18.0"
mcp__exec__run: cat package.json | grep -A2 lodash; ls
  → "Confirmed no other manifest files exist, so no other changes were needed."

GitHub 上で、それがプッシュしたブランチと、開いたプルリクエスト:

その diff に ない ものを見てください。axios 0.21.1、minimist 1.2.0、node-fetch 2.6.0 は、すぐ上と下の行にあります — どれも古く、同じ監査でフラグが付いていたのに、すべて手付かずです。タスクはマニフェストのみと指定しており、通りすがりにさらに3つ片付けてしまうエージェントは、レビューする結果として、より良いものではなく、より悪いものになっていたでしょう。

これはスクリーンショットではなく、実際のプルリクエストです: celmis-demo-gateway#6 — ブランチ celmis-agent/b8960e01、コミット1件、+1/-1。

そのトランスクリプトの中の2つの詳細は、diff よりも価値があります。エージェントは他のマニフェストがないと 仮定 しませんでした — 確認のためにサンドボックス内でコマンドを実行しました。また、タスクは「マニフェストのみ。無関係な依存関係には触れない」というものだったため、変更は正確に1行だけです。

ランナーが許可すること、許可しないこと

これを決めるのはプロンプトではなくランナーです。エージェントに何かを許可する前に読む価値があるのは、この部分です:

• 独自のシェルはありません。 Bash、WebFetch、WebSearch、ノートブック編集は許可されていません。コマンドはサンドボックスコンテナを通じて実行されます。このコンテナは独自の uid と読み取り専用のルートファイルシステムを持つ独立したサービスです。

• Git はランナーの仕事です。 エージェントがコミットやプッシュをすることはありません。作業が完了したとき — または Finish & push を押したとき — ランナーがコミットを作成し、ブランチをプッシュし、PR を開きます。デフォルトブランチに対しては決して行われません。

• プロバイダーの制限は一時停止であり、損失ではありません。 上記の実行の最初の試行は、セッション途中で週次のアカウント制限に達しました。セッションは終了しませんでした。paused に移行し、14日間作業を再開可能な状態で保持し、一般的な失敗ではなくプロバイダー自身のメッセージを表示しました。2つ目のキーで完了しました。

• セッションは視聴可能です。 出力はリプレイ付きで SSE 経由でストリーミングされるため、再接続すると白紙から始まるのではなく、中断したところから再開します。

接続はセットアップトークンで、ユーザーごとまたはワークスペースごとに保持されます。API は一度保存されたトークンを返すことはありません — トークンがあるかどうかと、まだ機能するかどうかだけを返します。

誰が何を見られるか

アクセスはリポジトリごと、チームごとに解決され、Q&A、グラフ、検索、MCP のすべての面を一度に管理します:

これこそが、隣接チームのケースを、約束ではなく実際に機能させるものです。リポジトリを読み込み、相手チームに質問する権限を付与し、読んではならないパスを拒否します。相手は回答を得られます。それらのファイルはソースの時点で拒否され、すでに含まれていたレスポンスから除外されるのではありません。

言語と形式

17のグラフモジュールに加え、モジュールがない言語向けに tree-sitter タグクエリによる汎用パスを用意しています:

コード — Python、TypeScript、JavaScript、Go、Java、C#、C++、PHP、Vue、さらに汎用パスを通じてその他にも対応。

インフラストラクチャ — Dockerfile、docker-compose、Helm、Kubernetes マニフェスト、Terraform、CI ワークフロー。これはほとんどのコードインテリジェンスツールが飛ばす部分であり、関数から、それを実行するサービス定義へと質問がまたがることができる理由です。

決定的チェック — モデルなし、偽陽性なし

以下のすべてのチェックはファイルを読むことで判定されます。何かが間違っていると判断するのに言語モデルは関与しないため、偽陽性率はチューニングではなく設計上ゼロです。

その区別こそが要点です。偽陽性が20%前後になると、開発者はツールのコメントをまったく読まなくなります。1件なら数秒の注意で済みますが、1000件あれば、ツールの言うことをすべて飛ばすことを覚えたチームという代償を払うことになります。ここでモデルは説明と優先順位付けに使われ、検出には決して使われません。

通常の CVE スキャンは意図的にこのリストに含めていません。OSV-Scanner がすでにそれを行っており、無料で、事実上の標準です。Celmis はそれを実行し（さらに各エコシステム独自の監査ツール: pip-audit、npm audit、govulncheck、cargo audit も実行します）、その結果を機能としてではなく入力として扱います。

コンプライアンスについて。 Celmis は監査が求める成果物を生成します — CycloneDX SBOM、依存関係インベントリ、タイムスタンプ付きの所見履歴、各所見の根拠となるエビデンス。Celmis はあなたの提出が適切であるとは主張しません。正直に主張できるツールはありません。監査人が何を受け入れるかは、あなたの業種、法域、あなた自身の統制に依存します。成果物を作り、それを評価するのが仕事の人に委ねましょう。

Claude Code とその他の MCP クライアントを接続する

Celmis はインデックスを MCP 経由で公開するため、エージェントは手元にないチェックアウトを grep する代わりに、シンボルの検索、API サーフェスの読み取り、コンシューマーの検出ができます。

HTTP 経由 (実行中のスタックはこれを /mcp/ で提供します):

# Mint a token (or issue one from Settings → MCP in the UI)
docker compose exec api analyzer mcp issue-token \
  --scopes "read:graph read:groups" --duration 86400

// ~/.claude.json  (or .mcp.json in a project)
{
  "mcpServers": {
    "celmis": {
      "type": "http",
      "url": "http://localhost:8000/mcp/",
      "headers": { "Authorization": "Bearer <the token you just minted>" }
    }
  }
}

stdio 経由、HTTP を介さずに:

{
  "mcpServers": {
    "celmis": {
      "command": "docker",
      "args": ["compose", "exec", "-T", "api", "analyzer", "mcp", "serve"]
    }
  }
}

エージェントが尋ねられること

HTTP マウントは 18のツール を提供します。それらは、grep では答えられない質問に答えます:

2つのトランスポートは同じセットではありません。 stdio上のanalyzer mcp serveは、13個の古いグラフ型ツール（find_symbol、find_callers、query_graph）を提供します。HTTPマウントは上記の18個を提供します。どちらも他方の部分集合ではありません — 必要なツールに合わせてトランスポートを選んでください。

各ツールが必要とするスコープと障害モードを含むステップバイステップガイドは、.claude/skills/celmis-mcp/SKILL.mdにあります。このリポジトリが開かれているとき、Claude Codeが自動的にそれを読み込みます。

エージェントが要求できるもの

1回のsearch_symbols呼び出し、1つのコントラクトシンボルで、2つのリポジトリから2つの言語で結果が返ってきます — どちらもチェックアウトしていないクライアントに対してです。diffが決して越えられない境界を、これは当たり前にします。

18個のツールは、Streamable HTTPで/mcp/に提供され、/api/と同じベアラートークンで認証されます：

cross_repo_edgesは理解する価値があります。なぜなら、それがこの製品がシンボルグラフを持つ理由だからです。diffのみのレビュアー — 上記のベンチマーク表のすべてのツール（グラフが空のときのこれも含む）— は、関数シグネチャが変更されたことを伝えられます。しかし、別のリポジトリのサービスがまだ古い形を呼び出していることは伝えられません。そのリポジトリを開いたことがないからです。リポジトリを一度グループ化すれば、その質問に答えられるようになります：

> which services outside this repo call PaymentGateway.charge?

これが、私たちのベンチマーク順位が製品を過小評価している理由でもあります（説明ではなく）。ベンチマークセットは孤立した単一リポジトリのプルリクエストなので、エッジが越えるべき兄弟リポジトリがありません。能力は本物で、ベンチマークはそれを見ることができません — これはベンチマークについての言明であり、鵜呑みにすべき主張ではありません。MCPクライアントを自分のグループに向けて確認してください。

結果

CelmisはMartian Code Review Benchのオフラインセットで実行されました：50件の厳選されたプルリクエスト、173件の人間が書いたゴールデンコメント、LLMジャッジによってゴールドセットに対してスコアリングされました。e0db376でgemini-3.6-flash、温度0.1、推論トークンなしで測定しました。

F1はジャッジによって4.8ポイント変動します。順位はまったく変動しません — 3つすべてで17位です。3つのすべてで私たちの下位：CodeRabbit（19/25/23）、Greptileの全バージョン（26–29）、Kodus（21/23/21）、Copilot、Claude Code、Gemini、CodeAnt。

実行全体のコストは**$5.88** — プルリクエストあたり$0.118 — で、153件のフィンド（欠陥114、セキュリティ27、コントラクト6、構造6）を生成し、PRあたり3.06件でした。

この比較が公平である理由。 Martianはベンチマークリポジトリに49ツールの自社評価を同梱しています。同じ3つのジャッジ、同じ50 PR、同じゴールデンに対して生成されたものです。私たちは誰も再スコアリングしていません：彼らの行は公開されたまま採用され、私たちの行が追加されています。テーブル全体を再現するには：

python3 autoloop/offline_table.py anthropic_claude-sonnet-4-5-20250929

オフラインは公開リーダーボードではありません。 Martianは2つのベンチマークを実行します。公開リーダーボードはオンラインのものです — 開発者が実際に修正した内容でスコアリングされた200,000件の実プルリクエスト。この表はオフラインのものです — ゴールドセットに対してスコアリングされた50件の厳選PR。これらは異なるものを測定しており、数値は交換できません。「ツールXがMartianで1位」という形式の主張は、通常オンラインの表、異なる指標、または異なるジャッジを指しています。

この数値に含まれていないもの。 グラフは50 PRすべてで空でした（graph_statusはnull、ドリフトはすべて空）。ベンチマークセットが孤立した単一リポジトリのプルリクエストだからです — シンボルがコンシューマーを持つための兄弟サービスがありません。この製品がシンボルグラフを持つ理由であるクロスリポジトリのドリフトは、上記のスコアにまったく貢献していません。ここでは測定できず、この表から主張することもありません。実際のコードで動作を見るにはテストリポジトリを参照してください。

誤検知の監査

ベンチマークスコアリングには構造的な下限があります：ジャッジは私たちのコメントを有限の人間が書いたゴールデンのリストと照合するため、アノテーターが書き留めなかった正しいフィンドは構造上誤りとしてカウントされます。私たちは79件すべてを測定されたコミットのソースで開き、それぞれに判定を割り当てました。

誤検知としてスコアリングされた79件のフィンドのうち、33件はゴールドセットに含まれない実際の欠陥、38件は本当に誤り、8件はコードから判断できませんでした。これにより、この実行の真の適合率は測定された48.0%ではなく69.7%から75.0%の間になります — しかし、この修正された数値は上記の表の何とも比較できません。なぜなら、他のツールを同じ方法で監査した人は誰もおらず、彼らの誤検知にもほぼ確実に同様の割合で実際の欠陥が含まれているからです。他のツールとの比較には、測定された48.0%が正直な数値です。それは全員に同じ方法を適用したものだからです。

38件の本当に誤ったフィンドのうち24件は4つの根本原因を共有しており、そのどれも「モデルが弱い」ではありません — 4つすべてはモデルに何が表示されたかに関するものです。最大のものは、同じファイル内で宣言されているがエージェントが受け取った抜粋の外にある識別子です：26行上にあるメソッドパラメータ、3行目にあるインポート、18行目にあるattr_reader。

完全なレポートには、79件それぞれについて、主張、そのコミットでのコード、判定、推論、パーマリンクが記載されているため、どの判定も同じ証拠を目の前にして異議を唱えることができます。

テストリポジトリ

上記の実行のすべてのレビューは、今もライブで公開されています。これらは実際のプロジェクトからの実際のプルリクエストで、履歴ごとフォークされ、Celmisが書いたインラインコメントが付いています：

最初に開く価値があるもの：

• keycloak#17 — Keycloakのテストストレージプロバイダーにおけるnull参照外しとリカバリーコードのインデックス化に関する質問

• grafana#16 — Legacyメトリクスに対して記録されたStorage障害。そのファイル内の同じミスの3つのインスタンスのうちの1つ

• cal.diy#11 — 非同期コールバック付きのforEach。削除がfire-and-forgetになり、周囲のtryが何も捕捉しない

• sentry#11 — 1つのKafkaコンシューマーPRに対する7つのインラインコメント

あなたは未編集の出力を読んでいます。上記の監査が誤りと判断したフィンドも含めてです。スコアリング後に何も削除されていません。

設定

./scripts/init-env.shは.env.exampleから.envを書き込み、すべてのシークレットを生成します。サンプルは各シークレットを意図的に空で出荷しています：以前のバージョンは生成コマンドを変数の横に置いていましたが、dotenvファイルにはインラインコメントがなく、それをコピーしたすべてのインストールがリポジトリに印刷されたマスターパスワードで実行されました。

設定はdocker-compose.ymlのenvironment:ブロックを通じてのみコンテナに到達します — イメージは.envを持ちません。そこに名前がない変数は、.envが何と言おうとコードのデフォルト値を取ります。GET /healthzは、プロセスが実際に解決したとおりのレビュークロックを報告します。これが、何が届いたかを確認する方法です。

クロックは.env.exampleでセットとして文書化されており、それらを結びつける不変条件があります：

REVIEW_LLM_TIMEOUT_SECONDS × (1 + RETRY_FACTOR)  ≤  REVIEW_TIMEOUT_SECONDS

一方を上げると、もう一方も追従する必要があります。テストがそれを強制します。

運用

docker compose logs -f api            # follow the API
docker compose exec api analyzer graph-stats <repo>   # what parsed, what did not
./scripts/backup.sh                   # Postgres + volumes
./scripts/restore.sh <archive>

Admin → Monitoring には、キュー深度、ワークスペースごとの支出、エージェントごとのモデル設定が表示される。Usage & cost は支出を画面ごとに分類するため、バッチのドキュメントビルドがチャットとして表示されることはない。

サーバーへのデプロイは ./scripts/deploy-on-server.sh v0.1.0 を サーバー上で実行する。公開済みのイメージをプルし、Caddy の背後でスタックを起動して、AGPL フッターがリンクするビルドをスタンプする。この操作には、そのマシン以外の環境で資格情報は一切不要である。docs/ORACLE_CICD.md か、通常の VM 向けの docs/HETZNER.md を参照。

ローカル開発

# Postgres and Qdrant from compose, everything else on the host
docker compose up -d postgres qdrant

python -m venv .venv && source .venv/bin/activate
pip install -e ".[dev]"

alembic upgrade head
uvicorn src.api.main:app --reload --port 8000

cd web && npm install && npm run dev     # http://localhost:3000

pytest -q                # the suite
ruff check .             # lint, ratcheted at zero
cd web && npx tsc --noEmit

CLI リファレンス

analyzer は pip install -e . でインストールされる。Docker 内では docker compose exec api analyzer … を使用する。すべてのコマンドで --help が使える。

グループ化されたサブコマンド: analyzer repo、analyzer group、analyzer auth、analyzer mcp、analyzer scip。

アーキテクチャ

                      ┌──────────────┐
   GitHub / GitLab ──▶│   webhook    │──┐
   Bitbucket          └──────────────┘  │
                                        ▼
   Browser ──▶ web (Next.js) ──▶ api (FastAPI) ──▶ Postgres   jobs, policies, audit
                                     │              Qdrant     embeddings
                                     │              sandbox    untrusted execution
                                     ▼
                              model provider
                       (direct, or via a LiteLLM gateway)

• Postgres はジョブ、ポリシー、実行履歴、支出、監査ログを保持する。永続的なジョブキューはテーブルであり、デキューは SELECT … FOR UPDATE SKIP LOCKED で行われる。ワーカーは事前に所要時間を推測するのではなく、作業中にリースを更新する。

• Qdrant は埋め込みベクトル（embeddings）を保持する。インストールごとに1つのコレクションを持ち、ワークスペースの分離はフィルターで強制される。

• sandbox は、信頼できないもの（テストスイート、ビルドなど）を、独自の uid と独自のネットワーク上で実行する。データベースもキーもなく、ルートは読み取り専用である。

• LiteLLM はオプションである。LITELLM_PROXY_URL と LITELLM_MASTER_KEY を一緒に設定すると、すべての呼び出しがゲートウェイ経由になる。どちらかを空のままにすると、プロバイダーキーが直接使用される。

トラブルシューティング

コンテナが起動しない。 docker compose logs <service> を実行する。API は起動時に、どのオプション機能が利用できないかとその理由を報告する。静かに失敗することはない。

レビューが何も生成しない。 GET /healthz で解決されたクロックを確認し、次に docker compose logs api | grep agent_ を実行する。各エージェントは経過時間、モデル、失敗コードをログに記録する。

障害ではなくタイムアウト。 local_timeout は、プロバイダーが応答する前にこのインストール自体の期限が経過したことを意味する。REVIEW_LLM_TIMEOUT_SECONDS を引き上げること。これは意図的にプロバイダー障害として報告されない。

Q&A が何も引用しない。 リポジトリがインデックスされていないか、埋め込みなしでインデックスされている可能性がある。Repositories に各リポジトリの状態が表示される。analyzer graph-stats <repo> で何が解析されたかを確認できる。

サンドボックスが常にビジー状態である。 SANDBOX_SLOTS は同時に実行されるジョブ数であり、メモリを消費する調整ノブである。SANDBOX_SLOT_WAIT は、呼び出し元が再試行を促されるまでキューで待つ時間である。

プロジェクト構成

src/
  api/          FastAPI app, routers, schemas
  review/       PR review — agents, orchestrator, providers, policies
  indexing/     parsers, symbol graph, embeddings
  qa/           retrieval and answer composition
  generation/   documentation vault
  llm/          provider clients, error taxonomy, cost ledger
  sync/         git providers, the durable job queue, workers
  sandbox/      the isolated execution server
  mcp_server/   the MCP surface
  security/     redaction, patterns, log filtering
web/            Next.js UI (App Router, 16 locales)
tests/          5200+ tests
deploy/         Caddy overlay and the LiteLLM gateway config
docs/           deploy guides and the end-to-end walk-through
bench/          benchmark harness and results

由来と権利

このリポジトリは、約10万行以上に及ぶ単一のルートコミットを持つ。これは、出自が不明なコードドロップがプロベナンススキャナーに対して示す形であり、肩をすくめて済ませるのではなく説明が必要な形である。その説明は存在する: PROVENANCE.md がライセンスの立場とコードの出自を述べている。開発はこのコミットより前に非公開で行われており、その成果は、ここにあるものをビルド、監査、フォークするために一切必要ない。

そのファイルは事実の記録であり、ライセンスではない。ライセンスは AGPL-3.0 であり、例外が1つある: ee/ の配下にあるもの、およびファイル名に .ee. を含むファイルには、代わりに LICENSE_EE が適用される。ee/ には現在、製品コードはない。境界線が最初のタグより前に引かれたのは、後から追加すると、すでに無限定の AGPL のもとで成果を送ってきたすべてのコントリビューターに再確認を求めることになるからだ。

ここで出荷されるすべてのものは AGPL である。商用に見える部分（監査コンソール、使用量と支出、コンプライアンスチェック、インストール指標）も含めて。セキュリティコントロールがエンタープライズ専用になることは決してない。監査ログは AGPL のもとで書かれ、今後もそうあり続ける。新しいコードの置き場所については CONTRIBUTING.md を参照。