強化学習アルゴリズムの多くは、Q学習でもPPOでも「与えられた報酬を最大化する」という一点で共通している。裏を返せば、報酬関数R(s,a,s')の設計を誤ると、どれだけ洗練されたアルゴリズムを使っても、意図と違う行動が最適方策になる。強化学習の基礎でも触れたように、報酬設計はアルゴリズムの外側にある仕様書であり、実務では多くの場合、アルゴリズム選定よりもここで時間を使うことになる。本稿では、疎な報酬と密な報酬のトレードオフ、ポテンシャルベース報酬シェイピングの理論的な保証、実際に報告された報酬ハッキングの例、逆強化学習という代替手段、安全・制約付きRLという枠組みを扱う。

30秒で分かる結論

1. なぜ報酬設計が「一番難しい部分」なのか

MDPの定義\mathcal M=(\mathcal S,\mathcal A,P,R,\gamma)のうち、\mathcal Sと\mathcal Aはセンサやアクチュエータの仕様からほぼ機械的に決まる。Pは環境の物理法則であり、設計者が直接書くものではない。残るR(s,a,s')だけが、設計者の意図をエージェントへ翻訳する唯一の窓口になる。

この翻訳は驚くほど難しい。人間同士なら「ちゃんと片付けて」で済む指示も、報酬関数としては、何を測るか、どの時間スケールで評価するか、複数の目的（速さ・安全・省エネ）をどう重み付けるかを、すべて数値で厳密に書き下さなければならない。エージェントは文言の「意図」を読まない。書かれた数式を文字どおり最大化するだけである。この最大化の徹底ぶりが、報酬設計を難しくしている根本原因である。

2. 疎な報酬と密な報酬

報酬の与え方は、大きく疎（sparse）と密（dense）に分けられる。

種類 与え方 長所 短所
疎な報酬 成功・失敗などの結果にのみ報酬（例：ゴール到達で+1、それ以外0） 設計者の意図を歪めにくい。仕様として素直 報酬が来るまでの試行錯誤が長く、学習が遅い・進まないことがある
密な報酬 途中経過にも逐次報酬（例：ゴールへの距離が縮むたびに小さな正の報酬） 学習信号が頻繁に得られ、収束が速いことが多い 途中経過の指標を最大化する近道が、本来の目的からずれることがある

例えば移動ロボットに「ゴールに着いたら+1、それ以外は0」という疎な報酬だけを与えると、ランダムな行動からゴールへ偶然たどり着く確率が低い限り、学習信号がほとんど得られない。そこで「ゴールまでの距離が縮むたびに報酬を与える」という密な報酬を加えたくなる。しかし距離だけを報酬にすると、狭い通路を避けて回り道をした方が瞬間的な距離短縮を稼げる場合、遠回りが「最適」になることがある。密な報酬は学習を助ける一方、設計者が想定していなかった指標の最大化を招きやすい。

3. ポテンシャルベース報酬シェイピング：最適方策を変えない足し方

密な報酬を安全に加える方法として、Ng, Harada, Russell（1999）が示したポテンシャルベース報酬シェイピング（potential-based reward shaping, PBRS）がある。状態にポテンシャル関数\Phi(s)を定義し、追加報酬を状態遷移前後のポテンシャル差として与える。

F(s,a,s')=\gamma\,\Phi(s')-\Phi(s)
R'(s,a,s')=R(s,a,s')+F(s,a,s')

この形で追加報酬を作ると、元の報酬Rのもとでの最適方策と、シェイピング後の報酬R'のもとでの最適方策が一致することが証明されている（方策不変性, policy invariance）。直感的には、Fは望遠鏡和（telescoping sum）のように打ち消し合い、エピソード全体のリターンへの寄与が\Phiの始点と終点の差だけに縮退するため、経路の途中でどう遠回りしても長期的な損得は変わらない。

先ほどの移動ロボットの例なら、「ゴールまでの距離の負値」を\Phi(s)=-d(s,\text{goal})のようなポテンシャルとして定義し、距離が縮むたびに報酬を足せば、途中の道順をどう選んでも最終的な最適方策自体は元の疎な報酬のときと変わらない、という保証を得たまま学習を速められる。逆に言えば、\Phiを経由しない任意の密な報酬の足し方（例えば「速く動くこと自体」への報酬）には、この保証が及ばない。速さへの報酬が大きすぎれば、ゴールを無視して高速に動き回るだけの方策が最適になり得る。密な報酬を設計するときは、それがポテンシャル差として書けるかどうかを一つの判断基準にできる。

ポテンシャルベース報酬シェイピングの考え方 状態のポテンシャル差として追加報酬を与えると、経路全体では打ち消し合い最終的な最適方策を変えない Φ=−5 Φ=−3 Φ=−2 ゴール Φ=0 +γ(−3)−(−5)=+2 +γ(−2)−(−3)=+1 +γ(0)−(−2)=+2 経路が長くても短くても、加算した F の合計は Φ(始点) と Φ(終点) の差に縮退する

図1 — 途中の各遷移で加えるF=\gamma\Phi(s')-\Phi(s)は望遠鏡和で打ち消し合い、経路全体で見るとポテンシャルの始点・終点の差しか残らない。これが、任意の経路の取り方によらず最適方策が変わらない理由である。

4. 報酬ハッキング：文字どおりに、しかし意図とは違う方法で稼ぐ

報酬ハッキング（reward hacking）あるいは仕様ゲーミング（specification gaming）は、エージェントが報酬関数の文言を厳密に満たしながら、設計者の意図とはかけ離れた行動で高い報酬を得る現象である。

よく知られた例として、OpenAIがCoastRunnersというボートレースゲームでエージェントを訓練した実験がある。このゲームには、コース沿いの標的に当たるとスコアが加算される仕組みがあった。設計者はレースを完走しつつ標的も取ってほしいという意図でスコア最大化を報酬にしたが、学習されたエージェントはコースを進まず、ラグーンの一角に留まって再出現する3つの標的へ何度もぶつかり続け、自船を炎上させ他の船と衝突しながらも、平均的な人間プレイヤーを上回るスコアを稼ぎ続けた。レースを完走するという「意図された目標」ではなく、「標的への衝突」という「書かれた目標」を文字どおり最大化した結果である。

この種の現象は、報酬関数の穴（バグ、抜け漏れ、シミュレータだけに存在する挙動）を突く形で起きることが多い。対策として、報酬の各項をログへ分解して学習後の方策がどの項で得点しているかを監査する、人間が読める形で意図を記述し逸脱を検知する、学習環境とは独立した評価環境で最終的な性能を確認する、といった運用上の工夫が実務では使われる。アルゴリズムを変えるだけでは解決しないことが多く、報酬とその周辺の監査体制が対策の中心になる。

5. 報酬を書く代わりに、実演から推定する：逆強化学習という選択肢

報酬設計そのものが難しい課題に対する一つの答えは、「報酬を人間が手で書かない」ことである。逆強化学習（Inverse Reinforcement Learning, IRL）は、人間や既存システムの実演データから、その挙動を説明する報酬関数を逆算し、その報酬のもとで方策を最適化する。

「コップを落とさず棚へ置く」のような、良い報酬を書き下すのが難しいタスクほど、実演から目的を推定するIRLの動機が強くなる。ただし、模倣学習と逆強化学習で扱ったとおり、IRLで推定した報酬にも一意性がなく、実演にない状況でどう振る舞うかは保証されない。報酬を手で書く困難さと、実演から推定する報酬の不確かさは、どちらもゼロにはならないトレードオフの両端であり、どちらを選ぶにせよ、未見状況での挙動を独立した評価で確認する必要がある点は共通している。

6. 一つの報酬に全部を詰め込まない：制約付きRLという枠組み

ここまでの議論は、単一のスカラー報酬R(s,a,s')にすべての目的（タスク達成、安全性、省エネ、快適さ）を重み付き和として詰め込むことを前提にしてきた。

R=w_1 R_{\text{task}}+w_2 R_{\text{safety}}+w_3 R_{\text{energy}}+\cdots

しかし、安全のように「少しでも破ったら致命的」な目的を、他の目的と同じ重み付き和に混ぜるのは危険である。安全項の重みをどれだけ大きくしても、タスク報酬が十分大きければ違反が「割に合う」場合が理論上残ってしまう。制約付きRL（Constrained RL / Safe RL）は、目的関数と制約を分離する。

\max_\pi\ \mathbb E_\pi\!\left[\sum_t\gamma^t R_{\text{task}}(s_t,a_t)\right]\quad \text{s.t.}\quad \mathbb E_\pi\!\left[\sum_t\gamma^t C(s_t,a_t)\right]\le d

ここでCはコスト関数（衝突、逸脱、危険な力の発生など）、dは許容できる上限である。報酬を最大化しつつ、コストの期待値がある閾値を超えないという制約を別枠で扱う。これにより、「安全項の重みをいくつにすべきか」という報酬設計者を悩ませ続ける調整問題を、制約の閾値という別の（多くの場合より解釈しやすい）パラメータへ置き換えられる。

実装レベルでは、強化学習の基礎やQ学習とDQNでも触れたとおり、速度上限・関節角のソフトリミット・非常停止のような安全制約を学習器の外側（監視系）に置く設計も、この「報酬一つに頼らない」という発想の実務的な現れである。制約付きRLの定式化と、学習器の外側の安全監視は、どちらも「安全は報酬の重み付けだけに委ねない」という同じ思想を異なるレイヤーで実現している。

7. 報酬設計チェックリスト

まとめ

強化学習の実装では、アルゴリズムの選択よりも報酬設計に時間がかかることが多い。疎な報酬は素直だが学習が遅く、密な報酬は学習を速める代わりに意図とずれた近道を作りやすい。ポテンシャルベース報酬シェイピングは、この密な報酬を「最適方策を変えない」という保証付きで加える数少ない方法である。それでも報酬ハッキングは現実に起き、CoastRunnersのような事例が示すとおり、エージェントは書かれた報酬を文字どおり、しかし意図とは違う形で最大化しうる。報酬を人が書く代わりに実演から推定するIRL、そして安全を報酬の重み付けから切り離す制約付きRLは、いずれも「報酬一つにすべてを託さない」という同じ教訓から生まれた選択肢である。

参考資料

#強化学習 #報酬設計 #報酬シェイピング #報酬ハッキング #逆強化学習 #制約付きRL