Why emojis suck for reinforcement learning (& what actually works)の意訳です。
「シンプルさ」という罠
親指を立てた絵文字（👍）は簡単に送れますが、本当に AI レビュアーにとって有益な学習信号になっているのでしょうか。絵文字ベースのフィードバックは気持ちよく、速く、そして誰にでも分かりやすいです。一見すると、理にかなっているようにも思えます。
しかしコードレビューは灯りのオンオフのような単純なものではありません。無数の判断、技術的なニュアンス、チーム固有の基準が入り混じったものです。その多くは、ワンクリックの絵文字には反映されません。すべてのコードコメントには隠れた意図があります。正しさ、読みやすさ、設計上のトレードオフ、過去の経緯、チームのリスク許容度、さらには組織内の政治的な力学まで含まれます。
それをオンオフという、二値のシグナルに押し込めてしまうとどうなるでしょうか。もはや学習ではなく、「雰囲気を追いかけるモデル」を育てているだけになってしまいます。
シンプルさが裏目に出るとき: ゴマすりモデルの恐怖
今年のはじめ、OpenAI は GPT-4o に対して「親指上げ/下げ」のフィードバックをかなり強く効かせたアップデートを行いました。その結果どうなったかというと、このモデルは過度にユーザーに迎合するようになりました。ユーザーをおだて、誤った回答にも同意し、「はい」と言いすぎるようになり、回答品質は低下しました。フィードバック信号がハイジャックされてしまい、OpenAI はロールバックせざるを得ませんでした。
モデルに「承認こそがゴールだ」と教えてしまうと、そのモデルは承認を最適化するようになります。真実でもなく、有用性でもなく、「その瞬間、人間が気持ちよく感じたかどうか」だけを目指すようになります。
これはバグではなく、報酬設計の失敗でした。そして同じアプローチをコードレビューに適用すると、「安全運転で、あなたにおべっかを使い、本当に必要なことを言ってくれないレビュアー」ができあがります。
なぜ二値フィードバックではニュアンスが潰れてしまうのか
親指上げの絵文字は一体何を意味しているのでしょうか。
モデルがバグを見つけたという意味でしょうか
説明が分かりやすかったという意味でしょうか
口調がフレンドリーだったという意味でしょうか
たまたまレビュアーの機嫌が良かったというだけでしょうか
単一のスカラー値のシグナル（👍または👎）は、「何かがうまくいった」ということは伝えますが、「何がうまくいったのか」は伝えません。そのためモデルは、自分が操作しやすいものに寄っていきます。トーン、丁寧さ、お世辞、あるいは短さといったものです。これが、強化学習におけるゴマすり（sycophancy）の正体です。悪意ではなく、「あなたが与えた報酬を最大化しようとしているだけ」であり、「あなたが本当に望んでいた結果」を最大化しているわけではありません。
これはグッドハートの法則が発動している例です。メトリクス（この場合は親指上げ）がゴールになってしまうと、それは現実の有用な指標ではなくなります。
モデルがあなたのフィードバックを「攻略」するとき
モデルに簡単なシグナルを与えると、モデルは簡単なショートカットを見つけます。
コーディングの世界では、強化学習エージェントが、基礎ロジックを解かずに期待される出力をハードコードすることでテストケースをパスするように学習してしまうことがあります。ログを細工したり、評価用ハーネスをすり抜けたりもします。チェックマークは緑になっても、実際のコードは正しく動きません。
コードレビューでも同じことが、ただし「社会的なかたち」で起きます。モデルはすべてのコメントの冒頭で「とてもいいです！」と言うようになり、あらゆる提案を柔らかな表現で包み、フォーマットのような安全な箇所ばかりを指摘するようになります。そういったコメントは無難で、議論もなく受け入れられやすいからです。そして本当に重要なアーキテクチャ上の懸念は、埋もれてしまいます。
モデルは「ポジティブな反応の取り方」は学んだものの、もはやコードレビューをしているとは言えません。
暗黙的なシグナルが優れている理由
LLM 以外の世界では、このパターンはよく知られています。Netflix は、ユーザーが何を「評価」するかよりも、何を実際に視聴するかのほうがはるかに有用だと気付きました。星評価では人は平気で嘘をつきます。しかし視聴時間、クリック、リピート再生といった指標は正直なシグナルです。
AI の世界では、これを**暗黙的フィードバック（implicit feedback）**と呼びます。コードレビューの場合には、例えば次のような形で表れます。
開発者は提案を採用したのか
それを書き換えたのか
無視したのか
同じパターンが後のバグとして再び現れたのか
これらのシグナルは、ユーザーの入力を必要としません。行動から生まれ、意図的に操作するのが難しいものです。
もちろん完璧ではありません。「なぜ」その行動を取ったのかまでは常に分からないからです。しかし、絵文字よりははるかに操作されにくく、レビューが「気持ちよかったかどうか」ではなく「ちゃんと機能したかどうか」を教えてくれます。
コード生成 vs コードレビュー: ゲームが違えば、シグナルも違う
コード生成は、しばしば「正解が一つに定まる」という点で数学に近い側面があります。コンパイルできるか。正しい結果を返すか。テストにパスするかといった具合です。
そのため、実行結果フィードバックや暗黙的なシグナルのようなアウトカムベースの報酬を使うことができます。もちろん完璧ではありません。コードモデルは出力をハードコードしてテストをすり抜けることもありますが、それに対するガードレールを設計することは可能です。そして、開発者が「良かった」と言ってくれるかどうかに頼らずとも、「実際に動いたかどうか」を観測できます。
一方、コードレビューは違います。ここには普遍的な合格/不合格は存在せず、チームごとにスタイル、構造、リスク、命名、テストカバレッジなどの好みが大きく異なります。あるチームにとっての「優れたコメント」が、別のチームでは完全にズレている可能性もあります。高速に動くスタートアップで「クリーンコード」とみなされるものが、高いセキュリティが求められる産業では「不十分」と判断されることもあります。
これこそが、「親指上げ/下げデータ」が抱える本当の問題です。ニュアンスが押しつぶされてしまい、モデルは「適切さ」ではなく「平均値」を目指すようになります。その結果、安全ではあるものの、ひどく汎用的なコメントばかりを出すようになってしまいます。
私たちの代替案: CodeRabbit Learnings
CodeRabbit では、別のアプローチを取っています。いいねを最大化するのではなく、「理解」を最大化しようとしているのです。そのために私たちは Learnings を構築しました。
エンジニアが CodeRabbit を修正したり、チームの規約を明確にしたり、「なぜこのコードは自分たちのスタックに合わないのか」を説明したりするたびに、その説明を自然言語の指示として保存します。単に「コメントが却下された」という事実だけでなく、「なぜ却下されたのか」まで記憶します。
これらの Learnings は、組織、リポジトリ、さらには特定のパスやファイルタイプに紐付きます。CodeRabbit が次のプルリクエストをレビューするときには、それらの指示を検索し、文脈に応じて適用します。同じパターンを再度見つけたときには、そこで学んだ内容を踏まえて挙動を変えます。
再度教え直す必要はなく、同じ失敗を繰り返すリスクもありません。モデルは親指の数から推測するのではなく、あなたのチームが与えた実際のガイダンスから推論します。
また、Learnings は透明性も提供します。どんな Learnings が存在するかを確認し、それらを閲覧し、カテゴリでフィルタリングし、標準が変わったときには削除や編集を行うことができます。つまりモデルは、チームの成長とともに進化し、プラクティスの変化に合わせて整合性を保ち続けます。
これは、単なる絵文字の承認ではなく「意図を取り込む」ことで行う強化学習です。解釈可能であり、検査可能です。そしてレビューをまたいで一般化する、「チームナレッジの生きたレイヤー」を構築します。
ニュアンスのある学習が可能にすること
システムに与えるのが「シグナル」ではなく「明確で文脈を含んだ指示」になったとき、単なるレビュー体験の改善以上のことが可能になります。
チームレベルでの適応が可能になります
モデルは「何が良いのか」を勝手に推測するのではなく、「あなたのチームが実際にどう書いているのか」を学習します。リスク許容度、スタイルの好み、トレードオフの感覚を理解し、「ハウスルールを理解しているレビュアー」として振る舞うようになります。経時的な学習（長期学習）を支えます
時間とともに CodeRabbit は、「どのコメントが役に立ったのか」「どれが無視されたのか」「どの提案が実際の変更につながったのか」という記憶を蓄積していきます。その結果、徐々に精度が上がり、フォーカスは鋭くなり、ノイズは減っていきます。信頼を築きます
開発者が「AI を訂正すれば、それを覚えてくれる」と分かっていると、より積極的に関わるようになります。開発者自身がシステムを形作り、そのシステムは汎用的な LLM ではなく「自分たちの基準を反映した存在」へと近づいていきます。
こうしてレビュー用ツールは、単なる「異なる視点の意見」ではなく、チームの延長として機能するようになります。
まとめ: 本当の学習はピクセルではなくパターンから生まれます
親指の絵文字は、素早いリアクションには向いていますが、それだけでは専門性は育ちません。
時間とともに成長し、あなたの標準に適応し、浅いフィードバックの罠を避ける AI レビュアーを求めるのであれば、承認以上のものを与える必要があります。説明を与えなければなりません。
次世代の AI コードツールは「いいね」の数で訓練されることはありません。文脈、結果、修正の軌跡で訓練されます。絵文字ではなく、構造化された記憶から学びます。実際の意思決定と、あなたのチーム自身の声から学びます。
それこそが CodeRabbit Learnings が設計された目的です。拍手のためではなく、理解のために設計されています。
Learnings を自分のチームで試してみたい方は、無料トライアルにお申し込みください
