# アムダールの法則 ## 定義 アムダールの法則(Amdahl's law)とは、処理の一部しか高速化(並列化)できない場合に、全体の高速化には上限があることを示す法則である。改善対象が全体の実行時間に占める割合を P(0〜1.0)、改善対象の高速化率(倍率)を S とすると、全体の高速化率 R は R = 1 / ((1 - P) + P/S) で表される。S を無限大に近づけた極限で、全体の高速化率の上限 Rmax は Rmax = 1 / (1 - P) に収束する。すなわち、全体の33%しか占めない処理をどれだけ高速化しても、全体の高速化率は最大で 1/(1-0.33) ≈ 1.5倍にしかならない。改善対象が複数個ある場合や追加のオーバーヘッドが発生する場合には、各処理の時間割合 Pi・高速化率 Si とオーバーヘッド割合 O を用いた拡張式が使われる。(Source: [[@2026__技術評論社__実践的パフォーマンスエンジニアリングによるAI高速化 - Chapter 2 パフォーマンス計測]] §2.2.2) 『詳解 システム・パフォーマンス』第2章はアムダールの法則を並列化のスケーラビリティモデリングとして紹介し、C(N) = N/(1 + α(N−1)) という別の定式化を用いる。C(N) は N(CPU数やユーザー負荷などのスケーリングパラメータ)に対する相対的な能力・容量、α(0≦α≦1)はどれぐらいシリアルかを表すパラメータである。AI 高速化本の P/S 形式(改善対象の時間割合と高速化率から全体高速化率の上限を導く)と、こちらの C(N) 形式(スケーリングパラメータ N の増加に対する相対容量の頭打ちを描く)は数学的に同型だが、前者は「単発の改善施策の効果上限」、後者は「並列度・負荷を増やしたときのスケーラビリティプロファイル(線形→競合→頭打ち)」という異なる読み方をする点で相補的である。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 2 メソドロジ]] §2.6.3) ## 横断的知見 - **同じ数式が「改善施策の上限」と「スケーラビリティの頭打ち」という異なる目的に使われる**: AI 高速化本([[@2026__技術評論社__実践的パフォーマンスエンジニアリングによるAI高速化 - Chapter 2 パフォーマンス計測]])は改善対象の時間割合 P と高速化率 S から全体高速化率の理論上限 Rmax=1/(1-P) を導き、個々の最適化施策への投資判断(この処理を高速化する価値があるか)に使う。一方『詳解 システム・パフォーマンス』第2章(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 2 メソドロジ]] §2.6.3)は同じ法則を C(N)=N/(1+α(N−1)) というスケーラビリティモデルとして提示し、CPU数やユーザー負荷 N を増やしたときの相対容量の頭打ち(ニーポイント)を予測するキャパシティプランニング用途に使う。両者は α=P/(1-P) 等の対応関係で数学的に同値と考えられるが、出典間で目的(単発施策の評価 対 スケールアウト計画)が明確に分かれている点は、ひとつの古典的法則が文脈によって全く異なる意思決定に使われる例として横断的に興味深い。 - **アムダールの法則は「競合」、USL は「競合+コヒーレンス」という関係にある**: 『詳解 システム・パフォーマンス』第2章は、視覚的に観測されるスケーラビリティプロファイル(線形・競合・コヒーレンス・ニーポイント・シーリング)のうち、アムダールの法則が「競合」のみをモデル化し、[[ユニバーサルスケーラビリティ法則]](USL)がコヒーレンスパラメータ β を追加して「競合+コヒーレンス」(頭打ち後の実際の下降)まで捉えると整理する。AI 高速化本はアムダールの法則単体(上限のみ、下降なし)しか扱っておらず、USL 相当の下降モデルには言及がない。AI ワークロードのスケーラビリティ分析(例: 分散学習のノード数増加によるスループット低下)に USL 型のモデルが適用された例は、現時点で ingest したソースには見当たらない。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 2 メソドロジ]] §2.6.4) - **数式を伴わない「実務での限界到達の物語」が、第三の応用領域(CI/CDビルド)として横断的知見に加わる**: 既出の2ソースはいずれも数式(P/S形式・C(N)形式)を中心にアムダールの法則を提示するのに対し、[[@2026__OReilly__Observability Engineering 2E - Chapter 18 Observability for CI-CD Pipelines]] はHoneycombのビルド系システムの実例として、2020〜2025年にmainブランチへの週次PR着地数が10〜20件から100件超へ増加しコード行数がおよそ倍増する中で、「並列ワーカーを増やしても改善が頭打ちになった」という体験を通じてアムダールの法則の限界を数式なしで描写する。同章はこの限界到達を「もはや並列ワーカーを追加したりビルドステップを短縮したりするだけでは前進できない」到達点と表現し、キャッシュ戦略全体の再設計という定性的な対応策(Docker Bakeへの移行)を導く根拠として使う。既出2ソースが「法則の数理モデル自体」を扱うのに対し、本章は「法則が実務上の意思決定(いつ並列化への投資を諦めてアーキテクチャ変更に舵を切るか)にどう使われるか」という運用的な読み方を追加しており、理論と実務適用のギャップを埋める具体例になる。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 2 メソドロジ]], [[@2026__OReilly__Observability Engineering 2E - Chapter 18 Observability for CI-CD Pipelines]]) ## 未解決の問い - Honeycombの事例のように「並列化の限界に到達した」ことを定性的に認識するのではなく、既出2ソースのP/S形式やC(N)形式でCI/CDのビルド時間を定量的にモデル化した場合、キャッシュ戦略への投資判断はどれだけ早期に(定量的に)下せるようになるか。 - AI ワークロードにおける改善対象の複数化(データローダ・学習本体・集団通信など)を式(2.3)の拡張アムダールの法則で扱う際、各処理間の依存関係(オーバーラップ)をどこまでモデル化できるか。 - ルーフラインモデル([[Rooflineモデル]])による理論性能の上限評価と、アムダールの法則による全体高速化率の上限評価は、パフォーマンスエンジニアリングの意思決定においてどのように組み合わせて使うべきか(前者は個別処理の改善余地、後者は改善対象選定の妥当性を評価する、という役割分担が成り立つか)。 - P/S 形式と C(N) 形式の対応関係(α=P/(1-P) 等)を厳密に導出すると、両者は完全に同値になるか、それとも N の意味(並列度 対 改善倍率)の違いにより一部の状況で乖離するか。 - AI/ML の分散学習ワークロードのスケーラビリティ低下を、[[ユニバーサルスケーラビリティ法則]]([[詳解 システム・パフォーマンス 第2版]]が扱うコヒーレンス項つきモデル)で分析した実例はあるか。 ## 関連 - ソース: [[@2026__技術評論社__実践的パフォーマンスエンジニアリングによるAI高速化 - Chapter 2 パフォーマンス計測]] / [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 2 メソドロジ]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 18 Observability for CI-CD Pipelines]] - 概念: [[Rooflineモデル]] / [[ユニバーサルスケーラビリティ法則]] / [[CI-CDオブザーバビリティ|CI/CDオブザーバビリティ]] - エンティティ: [[実践的パフォーマンスエンジニアリングによるAI高速化]] ## 出典 - [[@2026__技術評論社__実践的パフォーマンスエンジニアリングによるAI高速化 - Chapter 2 パフォーマンス計測]](§2.2.2、式2.1〜2.3、図2.2) - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 2 メソドロジ]] §2.6.3 - [[@2026__OReilly__Observability Engineering 2E - Chapter 18 Observability for CI-CD Pipelines]]("History of Improving Build Times at Honeycomb")