7月18日、Salesforce Engineeringが「How to Build Self-Improving AI Systems with Automated Feedback Loops」と題した記事を公開した。PRレビューのフィードバックを自動収集してAIジェネレーターを自己改善させるシステムの設計と実装を詳述した内容で、特筆すべきは6サイクル実行したうち実際に改善を適用したのは2サイクルのみ、残り4サイクルは信号不足で自己中断したという収束の実証だ。無限に変異し続けるのではなく、コミュニティ標準への収束として安定するこのアーキテクチャの詳細を以下に紹介する。

繰り返されるレビューコメントは「未文書化の要件」だ

コードレビューで何度も同じ指摘が繰り返される——これはツールの問題ではなく、アーキテクチャの問題だ。エキスパートのレビューコメントは一つのPRを直すが、その知見は次の貢献者には届かない。

Salesforceチームはこの問題に対し、「繰り返されるレビューコメントはもはやコメントではなく、未文書化の要件だ」 という考えに至った。十分な頻度で同じ指摘が現れるなら、それは人間のレビューに属するのではなく、システム自体に組み込まれるべきだ。

そこで彼らが構築したのが creating-sf-skill、いわゆる「スキルを生成するメタスキル」だ。ここで言う「スキル」とは、Salesforce AgentForce のエージェントが実行できる個別の能力単位を指す。各スキルは SKILL.md というMarkdownファイル（フロントマターによるメタデータと参照ファイルを含む構造化されたディレクトリ）として管理され、オープンソースの sf-skills リポジトリ でコミュニティが共同管理している。creating-sf-skill はユーザーの意図を受け取り、この SKILL.md 形式の完全なスキルディレクトリを生成するジェネレーターだ。レビュアーが繰り返し指摘していた命名規則（gerund形式）、スコープ境界、トリガー精度などの規約をすべてエンコードしている。

結果として、以前は3日かかっていたマージが2日に短縮された。コメントの性質も変わり、基本構造への12件のコメントから、既存スキルとのトリガー重複や制約の根拠といった本質的な問題への指摘にシフトした。

3層評価フレームワーク：「改善しているか」をどう測るか

ジェネレーターが改善しているかを証明するのは簡単ではない。一つの評価軸では不十分で、彼らが行き着いたのは3層評価フレームワークだ。

Tier 1: トリガー精度
生成されたスキルが実環境で正しく発火するかを検証する。80以上の競合スキルが同時にロードされた状態で、20クエリ（発火すべき10件・発火すべきでない10件）をSonnetサブエージェントが独立評価する。「紙の上では優秀だが実際には機能しない」問題を捕捉する層だ。

Tier 2: 構造バリデーション
リポジトリの実際のCIスクリプト validate-skills.ts が持つ21のルール——kebab-case命名、フロントマター形式、説明文の文字数、バージョン形式、スキル間の競合検出——を同じスクリプト・同じルールで実行する。完全な決定論的検証だ。

Tier 3: LLM-as-Judgeによるルーブリック評価
構造では測れない意味的な品質をLLMエージェントが採点する。ここで重要なのは「決定論的に測れるものはスクリプトで、文脈と判断を要するものだけLLMに委ねる」 という原則だ。両者は互いを代替しない。

フィードバックループの設計：週次で自動実行、最大5件の改善に制限

評価フレームワークで「どの程度良いか」は分かる。しかし「どこが足りないか」を教えるのはPRのレビュープロセスだ。この2つをつなぐのがフィードバックループの役割だ。

ループは週次のスケジュール実行として動く。オーバーフィッティング（特定レビュアーの個人的スタイルへの過剰適合）を防ぐため、実行には条件がある。マージ済みスキル作成PRが15件以上あること、かつ improvement-loop ラベルのついたオープンPRがないこと。

実行フローは、複数PRのインラインコメントの収集から始まり、著者返信・bot応答・CIノイズのフィルタリングを経て、LLMがパターンを重複排除し頻度×深刻度で優先度スコアを算出する。既存ルールで対応済みかを確認し、未対応であれば編集エージェントが修正を適用する。この際、1サイクルあたり最大5件の改善・100行の変更に制限して影響範囲を抑える設計だ。3層評価を通過したら、参照PRを含む説明文付きのドラフトPRを生成して人間レビューへ送る。

6サイクルで「直すものがなくなった」——収束の実証

最も注目すべき結果は、システムが自己限定的に収束した点だ。6サイクルを実行したが、実際に改善を適用したのは2サイクルのみ。残り4サイクルは信号不足で自己中断した。

• サイクル1：5件のソースPRから3つの高頻度パターンを発見。スコープ境界ルールの欠如、ハードコードされたリポジトリ名、ツール固有の言語——週10回書かれていたようなコメントが対象だった。
• サイクル6：閾値を超えたパターンの性質が変化。SKILL.md 本体には手を加えず、best_practices.md や pr_checklist.md といった周辺ファイルのみを編集。コア指示は安定していた。

この収束メカニズムには自然な減衰が働いている。ジェネレーターが改善する→生成スキルへのレビューコメントが減る→1サイクルあたりの信号が減る→閾値を超えるパターンが減る→変更量が減る→収束。コミュニティ標準への収束として安定するため、無限に変異し続けることがない。

そしてサイクル7で収束の条件が崩れた。フロントマターの規約変更により、1ウィンドウ内で5件のPRが同じ古い指示を指摘した——サイクル1以来の頻度スパイクだ。システムは人間の介入なしに34件のPRをスキャンし、5件の改善を適用して再収束した。

同じアーキテクチャをコードレビューボット自身に適用

このアーキテクチャはコードレビューボットにもそのまま適用できる。スキルへの人間コメントを掘り出す代わりに、ボット自身の出力への人間の反応を掘り出す。どの提案が黙って修正され、どれが異議を唱えられ、ボットが見逃した問題は何か。

初サイクルで4件の改善がベストプラクティス参照と深刻度キャリブレーションに適用された。ボットは「人間が実際に気にすること」を学習し、気にしないことへの指摘をやめていく。

このアーキテクチャが機能する条件

ただし適用できる前提条件がある：

• 最低信号量：サイクルウィンドウ内に15件以上のレビュー済み成果物が必要。それ未満では特定レビュアーのスタイルへの過剰適合が起きる。
• 構造化・検証可能な出力：Tier 2が機能するには「正しさ」の機械的定義が少なくとも一部存在する必要がある。自由形式の散文のみを生成するエージェントには適用できない。
• 機能しないケース：PRが形式的に承認されるだけで信号のないレビュー文化、または「良さ」が純粋に主観的で測定可能な代理指標がない出力。

構造的な契約（フロントマター、ファイルレイアウト、命名規則）と意味的な要件（指示の品質、制約の明確さ）の両方を持つ成果物が、このアーキテクチャの最適な対象だ。

詳細はHow to Build Self-Improving AI Systems with Automated Feedback Loopsを参照していただきたい。