デフォルトでマイニングされたルールが届くのが遅すぎる理由
コードレビューは、ほとんどのチームで標準が強制される場所であり、手戻りによって機能します。誰かがある方法でコードを書き、以前にそれが失敗するのを見たことがあるレビュアーがそれを指摘し、書き直されます。知識の伝達は本物ですが、それは作業の後に発生します。
人間の開発者の場合、このループは許容範囲内です。レビュアーが一度修正すれば、開発者は通常それを覚えています。しかし、エージェントがコードを書く場合、このループは閉じません。間違った方法でコードを書いたエージェントは、来週もまた間違った方法で書くでしょう。なぜなら、レビューに関する内容がエージェントの知識の一部にならないからです。一度ではなく、何度も手戻りのコストを支払うことになります。
Rule Minerは、これを改善し、より可視化します。改善されるのは、標準が1人のシニアエンジニアの頭の中にあるのではなく、明示的な成果物になるからです。可視化されるのは、レビューで繰り返し指摘されている事項のリストを確認できるようになるからです。Qodoは、何が対象となるかについて正確に定義しています。「開発者に受け入れられ、コード変更につながったコメントのみが考慮されます。」マイニングされた各ルールは、実際に繰り返し適用された修正を表しています。
シグナルの重み付けは、これらのルールが何であるかを示しています。Qodoは「変更されたコードに対する各レビュアーの所有権を推定し、それに応じてコメントを重み付けするため、ルールはそのコードに最も精通している人々の標準を反映します。」繰り返されるフィードバックは「ルール候補に昇格」し、「影響を受けるコードの強力な所有権を持つレビュアーからのコメントであれば、単一のコメントでも対象となる場合があります。」クラスタリングにより、「管理するパスにスコープされたエリア固有のルール」が生成されます。そしてシステムは自己修正します。「ルールが有効になると、それが生成した却下された提案は時間の経過とともにシグナルを減少させるため、ノイズは自然に消えていきます。」
これは、完全にレビュアーを対象とした、よく設計された学習ループです。作成者（ますますエージェントになりつつある存在）はその中に含まれていません。
代わりに試みられること
レビューフィードバックから手動で AGENTS.md を作成する。 誰かが3ヶ月分のプルリクエストを読み、規約を指示ファイルにまとめます。これは一時的には機能しますが、誰もその作業を繰り返さないため、やがて機能しなくなります。6ヶ月後、そのファイルは去年の春の標準を記述したものになり、その失敗は目に見えません。古い指示ファイルは、最新の指示ファイルとまったく同じように見えるからです。これが、エージェントが指示ファイルを無視する理由で説明されているドリフトの問題です。
Qodoのマイニングされたルールを手動で指示ファイルにコピーする。 ソースが維持されているため、上記よりはマシです。しかし、Rule Minerは動き続ける（「2週間ごとに学習を続け、1回の実行につきリポジトリごとに最大5つの新しいルールを生成する」）のに対し、手動のコピーは更新されないため、メンテナンス面では悪化します。手動の同期ステップを伴う2つの信頼できる情報源（Source of Truth）は、実質的に1つの信頼できる情報源と1つのバグが存在する状態と同じです。
レビューで指摘する。 ほとんどのチームが採用している、ありのままのデフォルト状態です。人間にとっては問題ありませんが、エージェントにとってはコストが高くなります。
エージェントがコードベースから規約を推測すると仮定する。 エージェントは目に見えるローカルパターンのマッチングは得意ですが、禁止事項を推測するのは苦手です。コード内のどこにも「あの障害の後、その方法でやるのをやめた」とは書かれていません。パターンの欠如は、ルールとして読み取ることはできません。
解決策：マイニングされたルールを作成者の前に置く
ステップ 1: 実際に何がどのウィンドウでマイニングされたかを確認する
連携を設定する前に、何が存在するかを確認します。マイニングされたルールは、Review StandardsページのRulesタブに「ソースタイプが Mined Pattern」として表示され、人間が書いたルールと区別されます。リポジトリに何も表示されない場合は、何かが壊れていると仮定する前にトリガー条件を確認してください。最初の実行は「Qodoに接続した後にリポジトリで最初のプルリクエストが開かれたときにトリガーされ、接続時に自動的には実行されません。」そして、ルールは「最初の実行から数時間以内」に表示されます。
数よりも重要な2つの境界線があります。
1つ目はウィンドウ（期間）です。Qodoは「Rule Minerは、リポジトリが接続される前の活動を含む、リポジトリの最近マージされた最大約1,000件のプルリクエストのインデックス付きウィンドウを利用します」と述べており、さらに重要な部分を率直に語っています。「これはリポジトリの完全な履歴ではありません。」活発なリポジトリの場合、1,000件のマージされたプルリクエストは数ヶ月分に相当することがあります。チームが確立し、その後違反しなくなった標準（これこそが成功の姿です）は、最近誰もそれを指摘する必要がなかったという理由だけで、そのウィンドウの完全に外側にある可能性があります。Qodoは、出力が少ないことは不具合ではないと明言しています。「リポジトリが完全に健全であっても、生成されるルールがわずか数個、あるいはまったくない場合もあります。」
2つ目はアクティベーション（有効化）であり、これは日付に依存します。Qodoのドキュメントによると、Rule Minerはデフォルトで有効になっており、「2026年9月1日以降にQodoの使用を開始した組織の場合、生成されたルールは自動的にアクティブになります」が、「その日付より前にオンボードされた組織の場合、生成されたルールは、強制される前にレビューのためにまず Rules > Suggestions に提案として表示されます。」両方の設定は変更可能です（「Mine rules from code review history」と「Auto-approve rule miner suggestions」は、ポータル設定の Context タブの Review standards セクションにあります）。しかし、どちらのデフォルト設定になっているかによって、マイニングされたルールがすでにレビューに影響を与えているか、それともキューで待機しているかが決まります。思い込む前に確認してください。
ステップ 2: Agentic Toolboxをインストールし、Get Rulesが利用可能であることを確認する
Agentic Toolboxは、すでに使用しているエージェントの内部にこれらの機能を組み込むためのQodoの仕組みです。公式の説明では、「Qodoのコード理解、コーディング標準、およびレビュー機能を既存のコーディングエージェントに提供します」であり、「コーディングエージェントを置き換えるものではなく、Qodoと直接やり取りする必要もありません。」
インストールは、Qodoのインストールエンドポイントからの1行のスクリプト（ドキュメントにはmacOS、Linux、Windows PowerShell用の形式が記載されています）で行われ、Node.js 20以降が必要です。パイプ経由のインストールと同様に、実行前にスクリプトを確認してください。次に何が起こるかについて知っておくべき2つの点があります。「インストーラーはツールボックスをインストールし、サポートされているエージェント環境向けに利用可能なQodoツールを設定します。」そして「QodoアカウントがなくてもAgentic Toolboxをインストールできますが、エージェントが実際にツールを実行するには、Qodoにサインアップまたはログインする必要があります。」ツールボックスとGet Rulesはどちらもベータ版としてドキュメント化されています。
Get Rulesは、いくつかのインターフェースを通じて公開されています。Claude Codeプラグイン、Codexプラグイン、Kiroプラグイン、CLI、エージェントスキル、および「任意のMCP互換クライアントまたはエージェント」向けのMCPサーバーです。チーム全員が同じクライアントを使用しているわけではない場合、セットアップが特定のエディタのプラグインシステムに縛られないため、MCPパスを選択するのが望ましいです。
Qodoに接続されたリポジトリで、これから開始するタスクにどのルールが適用されるかをエージェントに尋ねることで、動作を確認します。返ってくる内容は、複数のスコープを組み合わせたものであるはずです。Qodoのドキュメントによると、Get Rulesは「グローバルルール、リポジトリ固有のルール、およびコンテキストに応じたガイダンスを組み合わせます」とあり、FAQでは「リポジトリ固有のルールに加えて、適用可能なグローバルルールも含まれます」と明記されています。リポジトリルールしか表示されない場合は、組織レベルのスコープがまだ接続されていない可能性があります。
実行しないことについても注意が必要です。「Get Rulesはコードを変更しますか？ いいえ。Get Rulesはエージェントに適用可能なガイダンスを提供するだけです。」これは読み取り専用の処理です。
ステップ 3: 指示ファイルにいつ問い合わせるべきかを記述する
エージェントが一度も呼び出さないツールは、インストールしていないのと同じです。これは多くの人がスキップし、その結果「機能が動作しない」と結論付けてしまうステップです。
Qodo'sのドキュメントには次のように直接書かれています。「コーディングエージェントは、Agentic Toolboxの指示がエージェント指示ファイルに含まれている場合、より効果的にそれを使用できます。Qodo Agentic Toolboxの指示を AGENTS.md や CLAUDE.md などのエージェント指示ファイルに追加し、エージェントがワークフロー全体でツールボックスを効果的に使用できるようにしてください。」彼らはこのためのデフォルトのテンプレートを公開しています。
重要なのはトリガーです。ルールは、最初の失敗の後ではなく、実装が始まる前にロードされる必要があります。QodoのFAQにはその意図が記載されています。「ルールは実装が始まる前にロードされるため、エージェントはレビュー中に問題を発見するのではなく、コード生成中にそれらを使用できます。」指示ファイルにエントリを追加する目的は、それをあなたがリマインドするのではなく、エージェントの習慣にすることです。利用可能な機能としてではなく、コードを書くための前提条件として記述してください。
運用の詳細として、ツールボックスは自動的に更新されます。「対話型の使用中、Agentic Toolboxは定期的にアップデートを確認し、バックグラウンドで新しいバージョンをインストールします。」そしてデフォルトでは「すでにQodoスキルをインストールしているコーディングエージェント環境に、新しくリリースされた推奨スキルを追加します。」「所有している、またはカスタマイズしたスキルを上書きすることはありません」という適切な挙動をしますが、あなたが何もしなくてもツールの機能範囲が広がる可能性があります。
MemoryLakeでの設定方法
Get Rulesは、コードレビューを通過した標準に関するループを閉じます。しかし、それだけでは到達できない第2のカテゴリが存在し、それこそがチームに最も大きなコストをもたらすものです。
Qodo自体のフレームワークが、その境界線を明確に示しています。Rule Minerは、マージされた約1,000件のプルリクエストという限定されたウィンドウ内で、「開発者に受け入れられ、コード変更につながったコメント」に対して機能します。レビューコメントの形をとらなかった、チームが決定したすべての事項はその対象外です。会議で行われたアーキテクチャの決定、インシデントのポストモーテム（事後分析）からの結論、顧客が課したベンダーの制約、差分（diff）に記録が残っていない理由で2回試して断念したアプローチなどです。これらはレビューのルールとして強制することはできず、ウィンドウ内にも存在しません。
MemoryLakeは、そのもう半分を保持します。これは、リポジトリやレビュープラットフォームの外部にあるストアであり、稼働しているどのエージェントからでもMCPやAPIを介して読み取ることができ、静かに古くなるのではなく、修正されることを前提に構築されています。
ステップ 1: APIキーを作成する
キーを生成し、約30秒で最初のリクエストを送信できます。1つのキーでチームが使用するすべてのエージェント環境をカバーできるため、知識が特定のプラットフォームの所有物になるのを防ぐことができます。
ステップ 2: 最初の記憶（メモリー）をアップロードする
レビューでは決して見られなかった決定事項（ポストモーテム、アーキテクチャ決定記録（ADR）、全員が参照しているものの誰も読み返さないデザインレビューなど）がすでに含まれているドキュメント、画像、ファイルをドロップします。
ステップ 3: AIとエージェントを接続する
Claude、Codex、OpenClaw、およびその他のエージェントに、MCPまたはAPI経由でアクセスを許可します。Get Rulesと組み合わせることで、エージェントは両方の側面（レビューが強制する標準と、レビューで議論されることのなかった意思決定）を持ってタスクを開始できます。
実践においてこれがもたらす変化
レビューでの指摘事項が減少する理由は、いたってシンプルです。エージェントがコードを書く前にそれらについて知らされているため、レビュアーが指摘していたような間違いをしなくなるからです。Qodoはこれを目標として掲げています。ルールを「コードの最初の1行目からのガードレール」にすることです。
2週間のマイニングペースは、単に蓄積されるだけでなく、複利効果を生み出し始めます。新しいルールは、誰かが指示ファイルを更新するのを待つことなく、自動的に作成者に届きます。そのため、「私たちがこれを学んだ」から「エージェントがこれを知っている」までのギャップは、有志の更新を待つ時間ではなく、1回のマイニングサイクルになります。
オンボーディングのあり方が変わります。新しく入ったエンジニアのエージェントは、初日から他の全員と同じマイニングされた標準を受け取り、さらにマイニングウィンドウより前の意思決定も取得できます。これは「暗黙知（tribal knowledge）」という言葉が存在する理由そのものであり、誰かが離職したときにAIのコンテキストを維持することと同じ問題です。
そして、マイニングウィンドウが隠れた負債になることもなくなります。古い意思決定がプルリクエストのインデックスではない場所に存在していれば、それらが直近1,000件のマージから外れてしまっても問題ありません。
マイニングされたルールとエージェント側での取得に関するベストプラクティス
どのアクティベーションのデフォルト設定になっているかを確認する。 自動承認（Auto-approve）がオンの場合、マイニングされたルールはすでに適用されています。オフの場合、それらはSuggestionsにキューイングされています。この挙動は、組織がいつオンボードされたかによって異なります。
一括承認する前にSuggestionsキューを確認する。 マイニングされたルールはレビューの挙動を反映しているため、標準として望ましくないレビュアー個人の好みが含まれている場合があります。
単一のクライアントプラグインよりもMCPを優先する。 Get Rulesは、Claude Code、Codex、Kiroプラグイン、およびMCPサーバーとして提供されています。MCPであれば、エディタを変更しても使い続けることができます。
ツール呼び出しを前提条件にする。 エージェントが使用するかもしれない機能としてではなく、コードを書く前に実行することとして AGENTS.md に記述してください。
マイニングされたルールを手動で指示ファイルにコピーしない。 Rule Minerは生成を続けますが、手動のコピーは更新されません。複製するのではなく、取得するようにしてください。
結論
Rule Minerは、ほとんどのエンジニアリング標準が「レビュアーの記憶の中にしか存在しない」という正確な観察に基づいて構築されており、受け入れられ繰り返されたレビューフィードバックを、適切な重み付けと自己修正シグナルを備えた明示的なルールに変換するという有用な処理を行います。ギャップがあるのは配置です。レビュー標準はレビュー時に実行されますが、作成者が修正されたことを記憶しないエージェントである場合、それはループの逆の端にあたります。
Get Rulesはそれを修正するピースであり、セットアップは実質3つのステップです。何がどのウィンドウでマイニングされたかを確認し、ツールボックスをインストールして、次の四半期も使い続けているであろうインターフェース経由でGet Rulesが利用可能であることを確認し、指示ファイルでその呼び出しをオプションではなく前提条件にすることです。
そして、ウィンドウについて現実的に考えてみてください。1,000件のマージされたプルリクエストは、レビュー履歴としては多いかもしれませんが、チームが知っていることのほんの一部にすぎません。レビューコメントにならなかった決定事項（会議、インシデント、顧客の制約、2回の失敗した試みなど）こそ、人々が最も頻繁に再説明するものです。これらには独自のストアが必要であり、それを用意すれば、レビューが強制する標準と、レビューが関与しなかった意思決定が、コードの最初の1行目を書く前に同時に届くようになります。