【ITニュース解説】Federated Learning: Why Averaging Model Updates Works - and When It Fails

連合学習は、現代の機械学習が直面する大きな課題の一つ、つまりデータが様々な場所に分散していて、一箇所に集めるのが難しい、あるいは許されないという状況を解決するための技術だ。多くの機械学習では、全てのデータが一箇所に集められ、自由に扱えるという前提で動いているが、現実世界ではそうはいかない。例えば、個人のスマートフォンに保存されたデータ、病院の患者情報、銀行の取引記録、工場のセンサーデータなどは、移動にコストがかかったり、時間がかかったり、あるいは法律やプライバシーの観点から移動が厳しく制限されている。連合学習は、このような制約がある中でも、データを集約せずに機械学習モデルを訓練しようという試みである。

この技術の核心となるアイデアは非常にシンプルだ。データをモデルの元へ送るのではなく、逆に「モデルをデータの元へ送る」という発想で動く。具体的には、まずサーバーが現在の機械学習モデル（グローバルモデルと呼ぶ）を、学習に参加する個々のデバイスや機関（クライアントと呼ぶ）に送信する。各クライアントは、そのモデルと自身が持っているデータを使って、手元でモデルの訓練を行う。この時、クライアントは訓練に使ったデータそのものを外部に送信することはなく、訓練によって得られた「モデルの更新情報」や「新しいローカルモデル」だけをサーバーに送り返す。サーバーは、送られてきた複数のクライアントからの更新情報を集め、それらを平均することで、より良い「新しいグローバルモデル」を作り出す。この更新情報の平均化のプロセスは「Federated Averaging（FedAvg、連合平均化）」と呼ばれており、一見すると単純すぎて本当に機能するのか疑問に思えるかもしれないが、通常はうまく機能し、どのような場合に問題が生じるかを理解することが、連合学習を効果的に活用する鍵となる。

FedAvgが解決しようとしている問題は、主にデータの分散と異質性にある。もし全てのクライアントが、全体データセットの代表的なサンプルを持っていれば、この問題はそれほど大きくない。しかし実際には、クライアントが持つデータはそれぞれ異なる。例えば、ある病院の患者データと別の病院の患者データは異なるし、あるスマートフォンのユーザーが入力する単語と別のユーザーが入力する単語も違う。このように、データがクライアント間で均一でない状態を「非IIDデータ（独立同分布ではないデータ）」と呼び、これは連合学習の主要な課題の一つとなっている。

FedAvgの学習プロセスは、いくつかのラウンドに分けて進行する。まず、各ラウンドの最初に、サーバーは現在のグローバルモデルを、そのラウンドで選ばれた一部のクライアントに送信する。次に、選ばれた各クライアントは、サーバーから受け取ったグローバルモデルを初期値として、自身のローカルデータを用いて勾配降下法（SGD）などの最適化アルゴリズムを複数回実行し、自身のデータに最適化された「ローカルモデル」を得る。この際、クライアントが複数のローカルステップを実行する点が重要で、これによりサーバーとの通信回数を減らすことができる。これは、スマートフォンなどのデバイスが遅いネットワークに接続されていたり、一時的にしか利用できない場合に、通信が大きなボトルネックとなるため非常に有効な設計だ。最後に、各クライアントは訓練後のローカルモデル、またはモデルの更新情報だけをサーバーに送り返す。サーバーは、送られてきたローカルモデルをクライアントのデータセットサイズに応じて重み付けして平均し、次のラウンドの新しいグローバルモデルとして設定する。データセットサイズによる重み付けは、より多くのデータを持つクライアントの更新がグローバルモデルに強く反映されることを意味し、これは一般的に合理的な選択だが、時には問題を引き起こすこともある。

モデルのパラメータを平均化するだけで、なぜ効果的なモデルが生まれるのだろうか。特に深層学習モデルの場合、異なる初期値から訓練された二つのモデルを単純に平均しても、通常は性能の悪いモデルになってしまうことが多い。これは、同じ機能がモデル内部の異なる表現で実現されうるためだ。しかしFedAvgは、各クライアントが毎ラウンド同じグローバルモデルから訓練を開始し、ごく限られた数のローカルステップしか実行しないことで、この問題を回避する。これにより、ローカルモデルはグローバルモデルの「最適解の盆地（良い性能を示す領域）」から大きく離れずに済み、それらを平均してもなお意味のあるモデルが維持される。もしローカルでの訓練を過度に進めすぎると、この前提が崩れてしまうことがある。

連合学習における主要な失敗要因の一つが「クライアントドリフト」だ。データが非均一である場合、各クライアントのデータに合わせた最適解はそれぞれ異なる。ローカルでの勾配降下法は、グローバルな最適解ではなく、そのクライアント自身のデータの最適解へとモデルを引っ張っていく傾向がある。そのため、いくつかのローカルステップを経た後、個々のローカルモデルの平均が、全体にとって良いグローバルな解決策から逸れてしまうことがある。例えば、片方のクライアントのデータが主に猫の画像で、もう一方が犬の画像だと想像してみよう。それぞれのローカルモデルは、自身のクラス（猫または犬）については非常に得意になるが、もう一方のクラスについては苦手になる。これらのモデルを平均すると、猫と犬の両方において中途半端な性能のモデルになってしまう可能性がある。これは平均化の計算式の間違いではなく、ローカルの目的が一致しないときに生じる自然な結果である。

クライアントドリフトの兆候はいくつかある。例えば、各クライアント上での訓練損失は減少しているのに、全体の検証精度が停滞したり、変動が大きくなったりする場合だ。また、通信量を減らすためにローカルステップ数を増やしたにもかかわらず、かえってモデルの性能が悪化することもある。さらに、データ量が多い、あるいは頻繁に選択される一部のクライアントがグローバルモデルに過度に影響を与えたり、訓練後のクライアント間でモデルの性能に大きなばらつきが生じたりする場合も、クライアントドリフトが起きている可能性が高い。この問題への標準的な対策としては、ローカルステップ数を減らしてドリフトを抑える（ただし通信量が増える）、FedProxのようにローカルモデルがグローバルモデルから離れすぎないようにペナルティを加える方法、あるいはSCAFFOLDのようにドリフトを明示的に推定して補正する方法などがある。ただし、これらの対策は、追加の計算コストや複雑なチューニングが必要になる場合が多い。

連合学習の実際の運用では、従来のデータセンターにおける機械学習とは異なるリソースの制約がある。データセンターでは計算リソースがボトルネックとなることが多いのに対し、エッジデバイスでは通信コストが高く、デバイスの計算能力は多様で、一部のクライアントは途中でネットワークから切断されてしまう（ストラグラー）可能性もある。そのため、いくつかのトレードオフを考慮する必要がある。例えば、ラウンドあたりのローカルステップ数を増やすと通信帯域は節約できるが、クライアントドリフトが悪化し、ストラグラーによる遅延も増える可能性がある。また、ラウンドごとに多くのクライアントをサンプリングするとグローバル勾配の推定は良くなるが、より多くの調整コストがかかる。モデルサイズを大きくすれば精度は向上するかもしれないが、送信されるパラメータの量が増えるため、低速なネットワークや制約のあるクライアントが参加できなくなる場合がある。更新情報の圧縮や量子化、部分的参加などの技術も利用されるが、これらは最適化の挙動に影響を与え、ノイズを増やす可能性がある。

連合学習が「データがデバイスから離れないからプライベートだ」と主張されることがあるが、この主張はあまりにも強すぎる。モデルの更新情報はデータから派生するものであり、特定の条件下ではデータに関するかなりの情報を漏洩させることが分かっている。例えば、「勾配逆転攻撃」と呼ばれる手法では、小さなバッチの勾配情報から元の入力データを再構築できてしまう場合がある。「メンバーシップ推論」では、特定のデータがクライアントの訓練セットに含まれていたかどうかを推測できてしまう。悪意のあるサーバーや、侵害された集約サーバーは、現実的な脅威となり得る。そのため、実際のシステムでは追加の保護策が導入される。例えば、「セキュアアグリゲーション」は暗号技術を用いて、サーバーが個々のクライアントの更新情報ではなく、それらの合計値だけを知ることができるようにする。また、「差分プライバシー」は更新情報に意図的にノイズを加えることで、特定の単一データの影響を制限するが、これはモデルの精度低下という代償を伴う。クライアント側での「データ最小化」、例えば生データではなく特徴量のみを訓練に使用するといった工夫も、情報漏洩のリスクを減らすのに役立つ。これらのプライバシー保護策は無料ではなく、モデルの精度との間で慎重なバランスを取る必要がある。特に差分プライバシーを導入する際には、どの程度の精度を犠牲にして、どのようなプライバシー保証を得るのかを具体的に評価することが求められる。

連合学習は、以下のような特定の条件下でその複雑さを上回るメリットを発揮する。まず、法的な制約や契約によってデータがその場所から移動できない場合、例えば医療記録や金融取引データなどがこれに該当する。次に、データが非常に膨大であったり、広範囲に分散していて、物理的に一箇所に集めるのが困難な場合、センサーネットワークのデータなどが良い例だ。最後に、システムが分散環境で展開されており、中央集権的に訓練されたモデルが実際にデバイス上で使われる際に、データの分布にズレ（分布シフト）が生じてしまう場合にも有効である。

逆に、連合学習が不適切な状況も存在する。データをわずかな労力で集中化できる場合や、クライアント間のデータがほぼ均一である場合、あるいはクライアント管理、バージョン管理、クライアントごとのパフォーマンス監視、そして開発者からはデータが見えない環境でのデバッグといった、システム開発に十分なリソースを割けないチームにとっては、連合学習は良い選択肢とは言えない。これらのケースでは、強力なアクセス制御を備えた集中型トレーニングの方が、よりシンプルで高速、そして監査も容易となる。連合学習にコミットする前に有効なテストとして、もし集中化可能なデータがあるならば、それを人工的にクライアント間で分割し、実際の非均一性を模倣した環境でシミュレーションを行ってみるべきだ。もしこのシミュレーションでFedAvgが集中型トレーニングに比べて大幅に劣る結果になった場合、データが本当にアクセス不可能になったときに魔法のように性能が向上することはない。もし集中型トレーニングに近い性能を示すならば、残りの課題はアルゴリズム的な期待ではなく、システム構築上のエンジニアリングの問題となる。

一般的な落とし穴としては、全体の平均性能だけを見て、クライアントごとのパフォーマンスを見落とすことが挙げられる。全体的には良好に見えても、一部のクライアントで機能しないモデルは、実運用では失敗を意味する。また、中央集権化されたデータをランダムにクライアントにシャッフルして、あたかも均一なデータとしてチューニングしてしまうと、連合学習の難しさの核心である非均一性を隠蔽してしまうため、実環境での性能予測を誤る。実際のクライアントの境界やラベルの偏りによってデータを分割して評価することが重要だ。さらに、クライアントの利用可能性を無視することも問題である。例えば、夜間にオンラインになるクライアントと日中にオンラインになるクライアントでは、システム的な違いがあるため、選択バイアスが発生し、最適化される目的関数自体が変わってしまう可能性がある。プライバシー保護を訓練後に後付けで追加しようとすることも避けるべきだ。ノイズの追加やセキュアアグリゲーションは最適化の挙動に影響を与えるため、訓練設計と評価の段階から組み込む必要がある。最後に、より多くのラウンドを回せばクライアントドリフトが修正されると安易に仮定しないことだ。もしローカルな目的が根本的に食い違っている場合、同じ手順を繰り返しても、誰にとっても最適な解決策ではない妥協点に収束してしまう可能性がある。まずはドリフトの原因を診断し、その上で適切な対策を選択することが重要だ。

連合平均化が機能するのは、クライアントが共有モデルから出発し、自身のデータ上でわずかなステップしか動かず、その後平均化によって再び引き戻されるという、狭いが強力な条件をうまく活用しているからだ。このアプローチは、データを集中させることなく、通信効率を向上させる。しかし、ローカルでの訓練が過度に進みすぎたり、クライアント間のデータの不一致が大きすぎたり、あるいはプライバシーが技術的に確保されるものと誤解されたりすると、この仕組みは破綻する。したがって、連合学習の真の技術は、平均化の計算式そのものにあるのではなく、クライアントがどこまでドリフトすることを許容し、プライバシー保護のためにどの程度のノイズを加えるべきか、そしてクライアントごとのパフォーマンスをどれだけ正確に測定するかという、これらの難しい選択肢を適切に行うことにある。これらの選択を正しく行えば、連合平均化は一箇所に集めることのできないデータから学習するための実用的な方法となるだろう。しかし、これらを誤ると、平均化されたモデルは、結局どこでもうまく機能しないモデルを遠回しに表現する言葉に過ぎなくなるだろう。