Greptileとは？seat廃止後の料金・使い方・CodeRabbitとの違い【2026年10月】

Greptile（グレプタイル）は、プルリクエストの差分だけでなくリポジトリ全体を索引化したうえでレビューコメントを付けるAIコードレビューツールです。2026年10月に料金体系が変わり、チーム向けのProプランは1人あたりの月額（seat料金）をやめ、1クレジット1ドルを前払いして組織全体で使う方式になりました。

この記事では、改定後の料金とクレジットの数え方、GitHubへの導入手順、PRに付くレビュー結果の読み方、.greptile/ による設定、CLI 3.7とClaude Codeプラグイン、CodeRabbitやGitHub Copilotとの違いを、2026年10月23日時点の公式情報をもとに整理します。

まとめ：Greptileの料金と導入判断の要点（2026年10月）

• 料金：Starterは無料（開発者1人・月50クレジット）。Proはseat料金なしで1クレジット1ドルの前払い、残高は組織全体で共有します。Enterpriseは個別見積もりです。
• クレジット：完了したレビュー1回ごとにBaseが1、Plusが3、Apexが10を消費します。残高が尽きると新しいレビューは止まります。
• 改定の影響：旧Pro（1seat月30ドルで50クレジット込み）と比べると、レビューを受ける開発者1人あたり月30クレジット未満なら安く、30ちょうどで同額、それを超えると高くなります。
• 連携：GitHub.com・GitLab.com・Bitbucket Cloud・Cursor Originは全プランで使えます。GitHub Enterprise ServerなどはEnterprise契約が前提で、Azure DevOpsは対応表にありません。
• 手元での利用：CLI（npmの greptile、10月18日公開の3.7.0）でpush前のブランチをレビューでき、Claude Code・Codex向けプラグインもあります。CLIレビューはトライアル中か有料プランが条件です。
• 設定：新規導入はディレクトリ単位で効く .greptile/ フォルダが推奨です。指摘の量は strictness（1〜3）と commentTypes で絞れます。

Greptileの仕組みとv5での変更点

Greptileは、リポジトリのファイル・関数・依存関係をグラフとして索引化し、PRの変更がどこに波及するかを追ってからコメントを付けます。差分に現れない呼び出し元の破壊や、別ファイルで定義された型との不整合を拾えるのがこの方式の狙いです。関連リポジトリを最大7つまで参照させる「Repo Clusters」（2026年6月2日公開）もあり、共通SDKや型定義を別リポジトリに切り出している構成でも文脈を渡せます。

v5の並列エージェントとモデルの使い分け

2026年8月5日に全ユーザーへ有効化されたGreptile Agent v5は、「1つのバグ仮説を1つのエージェントが調べる」形に作り直され、それらを並列に走らせます。公式ブログのv5発表によると、本番環境でのA/Bテストでレビュー時間の中央値が5分4秒から2分25秒へ、作成者が対応したコメントの割合が52%から66%へ変わりました。いずれも開発元自身の計測値なので、自社リポジトリで試す前の目安として扱うのが妥当です。

「どのAIモデルで動いているか」については、7月22日に実験機能のModel Inversionが加わっています。コミット履歴・ブランチ名の接頭辞・PRタイトルからコーディングエージェントが書いたPRを判定し、Claudeが書いたPRはGPTに、GPTが書いたPRはClaudeにレビューさせる仕組みです。書いたモデルとは別のモデルの方がバグを多く見つけるという開発元の研究に基づいています。

v5の前後には次の機能も加わりました。

• Security Agent（7月28日）：Opengrepの静的ルール、依存関係の既知脆弱性チェック（SCA）、AIによる連鎖的な攻撃経路の検出を組み合わせたセキュリティレビュー。全ユーザーで既定で有効
• TREX（6月15日にパブリックベータ）：PRブランチをサンドボックスで実行し、失敗時のログや画面をコメントに添付する。1回3クレジットがレビューとは別にかかる

Greptileの対応言語と精度の確認方法

公式サイトのFAQでは、Python・JavaScript・TypeScript・Go・Elixir・Java・C・C++・C#・Swift・PHP・Rustの12言語を「完全対応」とし、それ以外の多くの言語は「応答の質がやや下がる」としています。KotlinやRubyのリポジトリで使う場合は、トライアル中に普段の規模のPRを数本通して、指摘の精度を確かめてから契約するのが安全です。

開発元の会社概要とシリーズB

開発元は2023年にSoohoon Choi、Daksh Gupta、Vaishant Kameswaranの3人が創業した米サンフランシスコの企業で、Y Combinatorの2024年冬期（W24）バッチ出身です。2025年9月23日にBenchmark主導で2,500万ドルのシリーズAを発表し、2026年10月19日にはMenlo Ventures主導で5,000万ドルのシリーズBを調達したと発表しました。評価額は7億5,000万ドルで、同じ発表の中で「GitHubで毎日作られるPRの1%超をレビュー・テストしている」と述べています。

Greptileの料金プランとクレジットの消費量

2026年10月23日に確認した公式料金ページのプランは次の3つです。Proには14日間の無料トライアルがあります。

Proにはこのほか、学習とカスタムコンテキスト、Knowledge Base MCP、複数リポジトリの参照、チーム分析ダッシュボード、Jira・Linear・Notion連携が含まれます。年契約・複数年契約の割引は営業との個別交渉です。

2026年10月の改定で変わった点

Internet Archiveに残る2026年10月21日（UTC）保存の料金ページでは、Proは「1seatあたり月30ドル・50クレジット込み・追加は1クレジット1ドル」でした。10月23日には「seat料金なし・1クレジット1ドルの前払い・組織全体で共有」に置き換わっており、変更は10月22日前後です。公式の変更履歴（changelog）には10月23日時点でこの改定の記載がなく、既存の契約がいつ新方式へ移るかの案内も料金ページにはありません。契約中のチームは請求画面で適用時期を確認してください。

公表価格から計算すると、改定前にseatとして数えられた開発者1人分の費用は、50クレジットまでは使った量にかかわらず30ドル、50を超えた分は30ドルに1クレジット1ドルを足した額でした。改定後は使った数がそのままドルになるので、月30クレジット（Baseレビュー30回）未満なら改定後が安く、30で同額、31〜50では改定後が最大20ドル高く、50を超えると常に20ドル高くなります。レビューをたまにしか受けないメンバーが多いチームほど、改定で安くなります。

運用面では、課金の考え方が後払いから前払いに変わった点が大きく効きます。課金の説明ページでは、残高が尽きると新しいレビューは追加購入まで止まるとしています。Settings → Billing の自動チャージ（Automatic recharge）を有効にしておかないと、月末にレビューが止まったことに気づかないままマージが進むおそれがあります。改定前の解説にある「seatの数え方」「超過は作成者ごと」「Flex Usage Limitで支出上限」は、新しい課金の説明ページから消えています。

Base・Plus・Apex・Autoのクレジット換算と推奨設定

レビューの深さは4段階から選びます。Plus・Apexは2026年9月25日に追加されました。

数えるのは完了したレビューの回数で、PRの本数ではありません。autoReview に push を含めると、同じPRへのpushごとにレビューが走り、その都度クレジットが減ります。TREXは、少なくとも1つのテストフローが成功か失敗まで到達したときだけ3クレジットが加算されます。

レビュー段階の説明で公式が勧めるのは、既定をAutoにし、本番ブランチ向けのPRと30ファイル超のPRをApexにするルールを足す設定です。たとえば月200本のPRを、pushごとの再レビューなし・全部Baseで回せば200クレジット（200ドル）です。ところが全PRが main へ直接入るトランクベース開発で「本番ブランチ向けはApex」を当てると、200本すべてが10クレジットになり2,000ドルに跳ね上がります。前払い制では残高の減りが速いほどレビュー停止も早まるので、最初の1か月は既定をBaseに固定し、ラベル security や大きなPRだけApexにして実績を見てから広げる方が見積もりを外しません。

OSS無料枠とスタートアップ優遇の条件

OSS向けの無料枠は、申請ページのFAQによると、スターが50以上でOSI承認ライセンスの公開GitHub・GitLabリポジトリが対象で、商用製品の一部ではないコミュニティプロジェクトであることが条件です。企業が自社製品のために公開しているOSSは対象外になりうるので、申請前に問い合わせておくと手戻りがありません。スタートアップ優遇は、シリーズA前かつ直近12か月の売上が200万ドル未満の企業が対象で、月500クレジットが6か月間無料になります。

対応コードホスティングとGitHubの導入手順

対応するコードホスティングは、Greptileのクラウド版かEnterprise契約かで分かれます。

Azure DevOpsは2026年10月時点の対応表に載っておらず、接続手順も案内されていません。Azure ReposでPRを回しているチームは、導入前に営業窓口へ確認するか、Azure DevOpsに対応しているCodeRabbitを候補にしてください。Cursorのコードホスティング機能についてはCursor Originの使い方とGitHubとの違いで解説しています。

GitHubで初回レビューを受けるまでの流れ

GitHubの「Installed GitHub Apps」に表示される greptile-apps は、GreptileのGitHub App「Greptile Apps」です。公式のクイックスタートの手順は次のとおりです。

1. app.greptile.com にメール・Google・GitHub・GitLabのいずれかでサインアップする
2. Code Providers で Connect（または Add Provider）を押し、GitHub Cloud を選ぶ
3. GitHub側でインストール先のアカウントか組織を選び、全リポジトリか選択したリポジトリへのアクセスを許可する
4. Greptileに戻ってGitHubの組織を選び、Link を押す
5. レビューさせるリポジトリを選んで Enable を押す（プロバイダーを接続しただけではレビューは始まらない）
6. PRを1本作り、約3分待ってサマリーと行コメントを確認する

レビューが走り始めるとPRに👀、終わると👍のリアクションが付きます。😕が付いたら失敗なので、@greptileai とコメントして再実行します。ドラフトPRは既定でスキップされ、ダッシュボードの「Review draft pull requests」をオンにすると対象になります。

PRに付くレビュー結果の読み方

Greptileのレビューは、PR全体のサマリーコメントと、該当行へのインラインコメントの2種類で届きます。サマリーは2026年9月16日に作り直され、それ以前の解説記事にある「Important Files Changed」の表やレビューフッターは表示されなくなりました。現在のサマリーには次の要素が入ります。

• 冒頭の信頼度スコア（0〜5）と短い結論
• 重大度順に並んだ未解決の指摘（Findings）の一覧と、各コメントへのリンク
• 変更内容の説明と、必要に応じた図（API連携はシーケンス図、スキーマ変更はER図、クラス階層はクラス図、処理の流れはフロー図）
• 指摘がなかった場合は「What we checked」（確認した範囲）

未解決の指摘は、スレッドを解決するまで再レビュー後のサマリーにも残ります。差分の外にある問題は、サマリーとは別のコメントで投稿されます。図は返信や @greptileai generate a class diagram for this PR のように種類を指定して作り直させることもできます。

信頼度スコアと重大度バッジの判断基準

レビューの構成を説明する公式ページでは、スコアと重大度を次のように定義しています。

スコアは変更の重さを加味して付くため、決済機能の3/5は社内スクリプトの3/5より深刻だと公式も注記しています。運用ルールにするなら、「P0が1件でもあればマージ不可、P1は作成者が直すか直さない理由をスレッドに書く、P2だけなら作成者の判断に任せる」のようにバッジで線を引き、スコアは人間のレビュアーが読む順番を決める目安に使う方がぶれません。

多くのインラインコメントには適用できる修正案が付きます。サマリーの「Fix All」ボタンは、未解決の指摘をまとめて、設定しておいたエージェント（Claude Code・Codex・Cursorなど）へ渡します。

@greptileai コメントでの操作と学習

PR上で @greptileai（@greptile でも可）とコメントすると、その場でレビューが走ります。質問や指示を続けて書くこともできます。

@greptileai
@greptileai review this draft
@greptileai review this at apex
@greptileai check for memory leaks

コメントで指定できるのはレビュー段階の引き上げだけで、設定より下げることはできません。Apexを指定したレビューは10クレジットを消費します。

Greptileは、指摘への👍・👎、返信、チームのレビューコメント、そして最初と最後のコミットの間で指摘が直されたかどうかから、チームの好みを学習します。公式はチームの基準に合うまで「2〜3週間ほど継続的なリアクションが必要」としています。意図的なコードを指摘されたときは、👎だけで済ませずに理由を返信すると、次回以降の判断材料として残ります。

6月26日にベータ公開されたAuto-approve（5/5で指摘ゼロのPRの自動承認）を使う場合は、有効にした直後にリスクの上限（Cap risk level）を設定してください。Auto-approveの説明ページによると、上限を設定しないと認証・秘密情報・課金・DBマイグレーション・CIまで含むCriticalが上限になり、5/5のレビューを通ったPRはすべて承認されます。公式も、まずドキュメント・テスト・スタイル変更に限るLowから始めるよう勧めています。

.greptile/ によるレビュー設定と指摘の量の調整

2026年5月12日から、設定は .greptile/ フォルダが推奨になりました。リポジトリ直下だけでなく任意のディレクトリに置け、親から子へ設定が継承されます。同じディレクトリに greptile.json と .greptile/ が両方あると、greptile.json は無視されます。

.greptile/
├── config.json   # 厳しさ・対象PRの絞り込み・構造化ルール
├── rules.md      # 自然文で書くレビュー基準
└── files.json    # レビュー時に読ませるスキーマや設計書

次は config.json の例です。項目の一覧は公式のファイルリファレンスにあります。

{
  "strictness": 2,
  "commentTypes": ["logic", "syntax"],
  "effort": "base",
  "autoReview": ["open", "push"],
  "includeBranches": ["main", "release/*"],
  "disabledLabels": ["wip-*"],
  "excludeAuthors": ["dependabot[bot]", "renovate[bot]"],
  "ignorePatterns": "dist/**\n**/*.generated.*",
  "rules": [
    {
      "id": "no-console",
      "rule": "本番コードでは console.log を使わず logger を使う",
      "scope": ["src/**"],
      "severity": "medium"
    }
  ]
}

指摘の量を絞るstrictness・commentTypes・フィルター

ダッシュボードで変えられる設定の多くは config.json にも書けますが、commentTypes のようにファイルでしか指定できない項目もあります。strictness などはファイルに書いた値がそのリポジトリでダッシュボードより優先され、レビュー段階は原則として各設定のうち最も高い段階が採用されます（最初に一致したルールがAutoのときだけは、そのPRの段階をGreptileが選びます）。

• strictness の既定は2。commentTypes は logic（バグ・誤動作）、syntax（動かないコード）、style（命名・複雑さ）。指定した種類だけが残るので、スタイルの指摘が多すぎるときは style を外す
• autoReview：open・push・rebase の順に、後ろの契機は前の契機を含む。[] なら自動レビューを止め、コメントでの起動だけにする
• フィルター：labels・disabledLabels・includeAuthors・excludeAuthors・includeBranches・excludeBranches はglobが使え、includeKeywords・ignoreKeywords はPRタイトルと説明文を見る

注意したいのは excludeAuthors です。指定すると、既定で除外されている dependabot[bot] や renovate[bot] のリストを置き換えるため、自社のボットだけを書くとDependabotのPRがレビュー対象に戻り、クレジットを消費します。除外を続けたいボットも並べて書いてください。

ルールは scope でglob指定したファイルだけに適用されます。子ディレクトリから打ち消すには id を付けておき、子の disabledRules で指定します。子ディレクトリで同じ設定値を書くと親の値を上書きしますが、ルールと files.json の参照先は親子で足し合わされます。実際に効いている設定は、CLIの greptile config <ファイルパス> で、ダッシュボードの設定と組み合わせた結果を確認できます。

Greptile CLI 3.7とClaude Code・Codexプラグイン

PRを作る前に手元のブランチをレビューしたい場合はCLIを使います。CLIの導入ページのトラブルシューティング節にあるとおり、CLIレビューには有効なトライアルか有料プランが必要で、Starterの無料枠はPRレビューだけが対象です。

CLIのインストールとレビューの実行

npm install -g [email protected]    # Node.js 22以上。本記事は3.7.0で確認
greptile login
greptile init                    # このリポジトリでGreptileが有効か確認し、管理者なら有効化
git checkout feature/retry
greptile review --branch main --instructions "リトライ処理のエラー処理を重点的に"

2026年10月18日公開のnpm版3.7.0で --help を実行して確認したサブコマンドと、review の主なオプションは次のとおりです。レビュー対象はコミット済みの変更だけで、未コミットの変更とバイナリは含まれません。

• init：リポジトリの有効化状態の確認と有効化（OAuthサインインが必要で、APIキーでは有効化できない）
• config [path]：.greptile/ とダッシュボード設定を合成した、実際に効く設定の表示
• skills：コーディングエージェント向けのGreptile製スキルを .agents/skills などへ入れる
• environment：TREXがテストを実行する環境の構築スクリプト・環境変数・ネットワーク許可の管理
• review --plus・--apex：レビュー段階を上げる。指定しなければBase
• review --json：summary・confidence・securitySummary・comments などを1つのJSONで出力
• review --agent：プレーンテキストで出力し、確認プロンプトやブラウザでのサインインを出さない
• review --diff：指摘を変更箇所の横に並べて表示する（3.7.0のヘルプに記載）

以前の解説で紹介されている greptile onboard は、3.7.0では一覧に表示されない非推奨コマンドになりました。greptile onboard --help には「非推奨の対話式セットアップ」とあり、初期設定が必要なコマンドを実行すると、同じ流れが必要に応じて自動で始まります。

greptile review status は終了コードでレビューの状態を返すので、Gitフックやスクリプトの条件分岐に使えます。0がレビュー完了、1がレビューなしまたはエラー、2が入力の誤り、3が実行中、4が失敗、5が取り消しです。コミットの無い空のリポジトリで実行すると、HEADを解決できずに終了コード2で止まることを手元で確認しました。終了コード0は処理の完了を示すだけで、指摘がないことは保証しません。CIでは greptile login の代わりに環境変数 GREPTILE_API_KEY を渡します。

Claude Code・Codexプラグインと MCPサーバー

Claude Code（v2.1以降）向けのプラグインは次の2行で入ります。Codex向けは codex plugin marketplace add greptileai/codex-plugin から始めます。

/plugin marketplace add greptileai/claude-plugin
/plugin install greptile@greptile-claude-plugin

Claude Codeプラグインの説明ページによると、プラグインにはPRの指摘を読み出して修正に使うMCPサーバーと、PRなしで作業ブランチをレビューするCLIが同梱されています。/greptile:review main focus on error handling のように基準ブランチと観点を渡して手元のブランチをレビューし、結果をMCP経由でClaude Codeに読ませて直す、という往復をエディタから離れずに回せます。認証はOAuthで、MCPとCLIのトークンは別々に管理されます。MCPは /mcp メニューから、同梱CLIは /greptile:login から認証します。

「greptile api」で探している場合は注意が必要です。以前のGreptileはコードベースに質問できるAPIを前面に出していましたが、2026年10月時点のドキュメント索引にそのAPIリファレンスの項目はありません。現在の外部連携はMCPサーバーとCLIのAPIキー認証が窓口です。

CodeRabbit・GitHub Copilotとの違いと選び方

CodeRabbitの単価と枠は公式のプラン説明によるもので、月払いなら$30〜$90です。毎時5〜12回は標準の補充速度で、短期間にレビューを多く受けると適応的な制限で補充が遅くなります（Essentialsは直近7日で60回以上なら毎時1回）。GitHub Copilotのコードレビューは、モデルとのやり取りに使うAI creditsとは別に、文脈の収集やツール実行でGitHub Actionsの実行時間を消費します。AI creditsは既定では、自動で依頼されたレビューならPR作成者、手動で依頼したレビューなら依頼した人に計上されますが、管理者が課金先をリポジトリを所有する組織に切り替えることもできます。組織・企業では含まれる量を超えた追加利用が既定で有効なので、止めたい場合はAI Controlsで無効にします。プラン別の単価はGitHub Copilotの料金とAI Credits移行後のプラン比較にまとめています。

Greptileは自社サイトで、50件の実バグを含むPRを5製品に通した2025年のベンチマークを公開し、検出率をGreptile 82%、CodeRabbit 44%としています。評価対象のPRと採点を開発元が用意した比較なので、そのまま採否の根拠にするより、同じPRを両方に通して自分たちで確かめる方が確実です。前払い制になった今は、14日間のトライアル中に過去のバグ修正PRを数本Base・Apexの両方で流し、実際のバグを見つけたかとクレジット消費を並べると、段階ごとの費用対効果を自社のコードで判断できます。

選び分けの目安は次のとおりです。

• Greptile：変更の影響が複数ファイルや複数リポジトリへ波及しやすいモノレポ、PRの本数より1本あたりの深さを重視するチーム。レビューを受ける頻度がメンバーによって大きく違うチームは、seat料金がなくなったことで費用を抑えやすい
• CodeRabbit：開発者単位の月額で費用を固定したいチームや、Azure DevOpsでPRを回しているチーム。導入と設定はCodeRabbitの導入手順と.coderabbit.yaml設定、手元でのレビューはCodeRabbit CLIの使い方を参照
• GitHub Copilot：すでにCopilotを契約しており、追加の契約を増やしたくないチーム。依頼方法はGitHub Copilotのコードレビューで解説しています

Claude Codeの公式レビュー機能を使う構成はClaude Code「Code Review」の仕組みと料金、OSSを自前で動かす選択肢はPR-Agentの使い方とGitHub Actions導入にまとめています。どのツールでも、レビューをCIのどこで走らせ、どの結果でマージを止めるかという設計は残ります。CI/CDへの組み込みから相談したい場合は、DevOps・CI/CD導入支援で承っています。

導入前に確認したいデータの扱いと向かない場面

Security Practicesによると、クラウド版はAWS上で動き、推論には外部のLLMプロバイダーを使います。コードを扱うプロバイダーの一覧はTrust Centerのサブプロセッサーページに載っており、LLMプロバイダーとはデータを保持しない契約（ゼロデータリテンション）を結んでいます。コードは暗号化されたファイルシステムに保存され、GitHubやGitLab側でアクセス権を取り消した時点で削除されます。管理者が組織を削除した場合は24時間以内に本番系から削除され、バックアップも原則30日以内に破棄されます。SOC 2 Type IIのレポートはTrust Centerから請求できます。

見落としやすいのはAI学習の扱いです。同じページには、個人や顧客を特定する情報を除いた「匿名化データ」をモデルの学習に使うことがあると明記されています。止めたい場合は、組織の管理者が Organization Settings の Data & Privacy で「Help us improve Greptile」をオフにします。社内規程で外部AIへの学習利用を禁じている組織は、導入初日にこの設定を確認してください。LLM自体を自社の管理下に置く必要があるなら、Enterpriseのセルフホスト版（Docker Composeは開発者100人まで、それ以上はKubernetes）で推論先を自社で指定する構成になります。

逆に、次の条件に当てはまるなら導入を見送るか、別のツールを優先した方がよい場面です。

• Azure DevOps（Azure Repos）にリポジトリがあり、ミラーも置けない
• 全員が毎月50回以上レビューを受け、pushごとの再レビューも必要。改定後は1人あたりの費用が改定前より上がり、月額も固定できない
• Kotlin・Rubyなど公式の完全対応12言語に入らない言語が中心で、トライアルで精度を確かめる時間を取れない
• 不要な指摘が続いても、フィードバックやルール調整に時間を割けない。チームの基準に合わせた改善が進まない

AIレビューで置き換えられない設計判断や、レビュー観点そのものの決め方はコードレビューの目的・観点・進め方で整理しています。

Greptileについてよくある質問

Greptileの料金はいくらですか？

2026年10月23日時点で、Starterは無料（開発者1人・月50クレジット）、Proはseat料金なしで1クレジット1ドルの前払い、Enterpriseは個別見積もりです。Baseレビュー1回が1クレジット、Plusが3、Apexが10です。10月21日までのProは1seat月30ドル（50クレジット込み）でした。

Greptileは無料で使えますか？

使えます。Starterプランは無料で、開発者1人・月50クレジット（Baseレビュー50回分）までです。CLIでのレビューは対象外で、トライアルか有料プランが必要です。チームで使う場合はProの14日間無料トライアルがあり、公開OSSは申請が承認されれば無料になります。

GreptileはBitbucketやAzure DevOpsに対応していますか？

Bitbucket CloudはGreptile Forgeアプリで全プランから接続でき、Bitbucket Data CenterはEnterprise契約で対応します。Azure DevOpsは2026年10月時点の対応表に含まれていません。

GreptileのCLIは何ができますか？

push前のブランチを greptile review でレビューし、結果を画面・JSON・プレーンテキストで出力できます。3.7.0では greptile init でリポジトリを有効化し、greptile config で実際に効く設定を確認でき、greptile review status の終了コードをGitフックに使えます。

Greptileに送ったコードは学習に使われますか？

セキュリティページでは、匿名化したデータをモデルの学習に使う場合があるとしています。組織の管理者が Organization Settings の Data & Privacy で「Help us improve Greptile」をオフにすると、学習への利用を止められます。

関連記事

• CodeRabbitの導入手順と.coderabbit.yaml設定・料金と分担の決め方
• GitHub Copilotのコードレビュー｜依頼方法・自動化・日本語化と料金
• Claude Code「Code Review」完全ガイド｜自動コードレビューの仕組み・料金・/code-reviewコマンドの使い方【2026年7月版】
• PR-Agentとは？使い方・GitHub Actions/Docker導入と料金【v0.48対応】
• コードレビューとは？目的・観点・進め方と実装現場の運用設計を解説