AI-Codereview-Gitlab: GitLab の webhook に LLM を挟むセルフホスト型レビューBot
基于大模型(DeepSeek,OpenAI等)的 GitLab 自动代码审查工具；支持钉钉/企业微信/飞书推送消息和生成日报；支持Docker部署；可视化 Dashboard。
ひと目でわかる
- これは何？
- GitLab の Push / Merge Request イベントを webhook で受け、DeepSeek や OpenAI などの LLM に diff を投げて Note に書き戻す Python 製ツール。Apache-2.0 のオープン版と、別配布の Pro 版が併存する構成を README から読み解く。
- 誰に向いている？
- GitLab をセルフホストしていて、レビュー初動の負荷を下げたい小規模チームには向く。逆に、GitLab SaaS 側から自前サーバーへ到達できない構成や、LLM の送信先を統制したい組織、diff 以外の文脈を読ませたい場合は、agentic モードのコストとサンドボックスの挙動を先に確認すべきで、そのまま導入するのは勧めない。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 4 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
誰のどの作業を減らすツールなのか
レビューの待ち時間と、指摘の書き漏らしが問題になる場面を狙っている。README は「コードをマージまたはコミットする際に、素早く知的なレビューを行う」と説明しており、開発者がレビューコメントを書く前に、機械が diff を読んで Note を残す流れを想定している。対象は GitLab 上で Merge Request と Push を運用しているチームで、レビュアーが常時張り付いていない小規模構成ほど効果が出やすい。逆に、レビュー方針が属人的に固まっていて、コメントの文体や粒度に強い統一感を求める組織では、後述する Review Style の切り替えが逆効果になる。
webhook から Note 書き戻しまでの流れ
仕組みは README の「原理」に短く書かれている。GitLab 側で Merge Request または Push が起きると webhook が発火し、本システムのエンドポイントを呼ぶ。受け取った側は LLM にコードを渡して審査させ、結果を該当の Merge Request または Commit の Note に書き戻す。エンドポイントは /review/webhook で、GitLab の Webhook 設定では Push Events と Merge Request Events のみをチェックするよう指示されている。他のイベントを有効にすると、想定外のペイロードがこのエンドポイントに流れ込む。認証は2段構えで、.env の GITLAB_ACCESS_TOKEN が優先され、未設定の場合に webhook の Secret Token が使われる。トークンの権限範囲は README に明記がないため、必要権限は自分の GitLab 側で確認する必要がある。
Docker Compose で立ち上げるまで
Docker 経路は README の手順どおりで、git clone したあと conf/.env.dist を conf/.env にコピーし、docker-compose up -d で起動する。検証は2つのポートで行う。http://your-server-ip:5001 にアクセスして "The code review server is running." が返れば主サービス、http://your-server-ip:5002 で審査ログのページが見えれば Dashboard が起動している。Python 経路では Python 3.10+ の環境で pip install -r requirements.txt を実行し、python api.py と streamlit run ui.py --server.port=5002 --server.address=0.0.0.0 を別々に起動する。設定キーは LLM_PROVIDER が要で、README の例では deepseek を指定し、対応値として zhipuai、openai、deepseek、ollama が挙げられている。SUPPORTED_EXTENSIONS はカンマ区切りの拡張子リストで、ここに無い種類のファイルは審査されない。既定例には .md と .sql も入っており、ドキュメントやマイグレーションまで LLM に送られる点は意識しておきたい。
通知と日報は設定キーで切り替える
審査結果の配信先は钉钉、企业微信、飞书の3つで、README が具体的なキーを出しているのは钉钉の部分である。DINGTALK_ENABLED を 1 にし、DINGTALK_WEBHOOK_URL にグループのカスタムロボットの URL を入れる。企業微信と飞书は「設定は同様」とだけ書かれ、詳細は doc/faq.md に委ねられている。日報機能は GitLab だけでなく GitHub と Gitea の Commit 記録も対象とされており、複数ホストのコミットを1つの日次サマリにまとめる想定が見える。Dashboard は Streamlit 製で、Code Review の記録、プロジェクト統計、開発者統計を表示する。ここで扱う統計の粒度や保持期間は README に記述がなく、運用前に自分の環境で確認する項目になる。
Review Style は運用に効くか、ノイズになるか
出力の文体を4種類から選べる。専門型、皮肉型、紳士型、幽默型という区分で、README は皮肉型の例として「このコードは足で書いたのか」に相当する調子の文言を挙げている。文体の切り替えは仕組みとしては軽いが、組織での受け取られ方は重い。MR のコメント欄は後から検索され、レビューの記録として残る場所なので、皮肉型を選ぶと過去ログの印象が固定される。一方で、指摘が形式的になりがちなチームでは、あえて砕けた文体にしたほうが読まれるという判断もあり得る。README はどの文体がどの状況に向くかまでは踏み込んでいない。設定値の名前も README には明示されていないため、切り替え方法はリポジトリ内の設定を確認する必要がある。
agentic モードの代償: ディスク、トークン、時延
REVIEW_STRATEGY を agentic にすると、LLM が read_file とサンドボックスの run_command を呼べるようになり、REPO_CACHE_DIR 配下にクローンしたコードベースを自律的に探索する。既定は diff_only で、この場合は従来と同一の挙動だと README は説明する。agentic 側のコストは README 自身が数値を出している。プロジェクトあたり 10MB から 2GB のクローン、ディスクは 50GB 以上を推奨、1 セッションのピークで約 500MB のメモリ、トークンは 1 レビューあたり平均 5k から 50k で diff_only の 3 倍から 10 倍、時延は 30 秒から 5 分。AGENT_MAX_ITERATIONS の既定は 20 である。shell はコマンドの許可リストと拒否リスト、パス越界チェック、30 秒タイムアウトの3つで制限され、既定では ls、cat、grep、find、git log などの読み取り系のみが通る。AGENT_SHELL_ALLOWLIST と AGENT_SHELL_BLOCKLIST で調整できるとされているが、緩めた時点でこの防御は設定者の責任に移る。clone、fetch、LLM、ツール呼び出しのいずれかで失敗すると diff_only に自動降格し、最低限 diff_only 相当の結果は返る設計になっている。
向かない場面と、隣にある選択肢
第一の制約はネットワークの向きである。README は「GitLab が本システムに到達できること」を求め、内網環境が制限されている場合は外網サーバーへの配置を勧めている。つまり GitLab 側から自前ホストへ HTTP で届かない構成では、この仕組みはそのままでは動かない。第二に、LLM へコードを送る経路そのものが統制対象になる組織では、LLM_PROVIDER の切り替えだけでは要件を満たせない可能性がある。Ollama を選べばローカル推論に寄せられるが、agentic モードのトークン量と時延を考えると、どのモデルで回すかは費用対効果の判断になる。代替として README が案内するのは、同じ作者による Code Review Pro 版で、install.sh を curl で流す導入手順が示されている。ただし Pro 版の中身の差分は doc/pro.md に委ねられており、README からは機能差の具体が読み取れない。もう一つの近い選択肢は、GitLab CI のジョブとして LLM 呼び出しを書く方法で、こちらは webhook 用の公開エンドポイントを立てずに済む代わりに、レビュー結果を Note に書き戻す処理を自分で実装することになる。
Apache-2.0 の範囲と、更新に伴う確認コスト
ライセンスは Apache-2.0 で、リポジトリはアーカイブされていない。直近のリリースは v1.5.1、v1.4.3、v1.4.2 の順で、v1.5.1 は 2026-06-29、最終 push は 2026-07-23 と記録されている。更新のたびに確認すべき点は、agentic モードの既定値とサンドボックスの許可リストである。README は既定で読み取り系のみと書いているが、この種のリストは変更されやすい箇所で、AGENT_SHELL_ALLOWLIST を明示的に設定していない場合、既定の変化がそのまま実行環境に反映される。REPO_CACHE_DIR のディスク消費も同様に、クローン対象の増加に伴って膨らむ。ライセンス面では Apache-2.0 が特許条項と変更表示の義務を含むが、本記事は法的助言ではない。Pro 版がどのライセンスで配布されるかは README の範囲では分からないため、業務で使う場合は doc/pro.md と配布物のライセンス表記を自分で確認する必要がある。
編集部の結論
GitLab をセルフホストしていて、レビュー初動の負荷を下げたい小規模チームには向く。逆に、GitLab SaaS 側から自前サーバーへ到達できない構成や、LLM の送信先を統制したい組織、diff 以外の文脈を読ませたい場合は、agentic モードのコストとサンドボックスの挙動を先に確認すべきで、そのまま導入するのは勧めない。導入前に見るべきは conf/.env の LLM_PROVIDER と SUPPORTED_EXTENSIONS の2つで、前者を誤ると課金先が変わり、後者を絞らないと md や sql までレビュー対象に混ざる。
コミュニティノート