バックプロパゲーション：AIがエラーの『犯人』を追跡する方法（連鎖律付き）
1. 導入：犯人はここにいる
前回の記事で、微分が 「パラメータをどの方向に動かせばエラーが減るかを示すコンパス」 であることを学びました。
しかしディープラーニングには致命的な問題があります。それはモデルが とても深い（Deep） ということです。
入力層から出力層までのレイヤーは数十、数百に及びます。
例：出力層で「やっちゃった！結果が正解と10も離れている！」とエラー（Loss）が発生。
問題：誰が悪いのか？
入力層近くのパラメータが原因でバタフライ効果が起きたのか、出力層直前のパラメータが最後にトラブルを起こしたのか、分かりません。
そこでディープラーニングは巧妙に犯人を探します。それが 「直後の人を責める（Chain Rule）」 技術です。
2. 連鎖律（Chain Rule）："責任転嫁"の数学的定義
数学の教科書では連鎖律をこう書きます。
$$\frac{dz}{dx} = \frac{dz}{dy} \cdot \frac{dy}{dx}$$
開発者の目にはただの数式に見えますが、組織管理の観点では「責任の分配」です。
想像してみてください。Aチームリーダー（入力） -> B部長（隠れ） -> C社長（出力） の承認ラインがあります。
- C社長（出力層） がプロジェクトを台無しにした（エラー発生）。
- C社長は全責任を取りたくないので分析します。"B部長が提出した報告書が台無しだったから私の結果も台無しだ"（$\frac{dz}{dy}$：私の結果がBのせいでどれだけ台無しになったか）。
- B部長は不満です。"いや、Aチームリーダーが基礎データを変に渡したから私の報告書も変になったんだ"（$\frac{dy}{dx}$：私の結果がAのせいでどれだけ変になったか）。
結局 Aチームリーダーがプロジェクト全体（z）に与えた悪影響（$\frac{dz}{dx}$）は、（CがBを責めた量） × （BがAを責めた量） で計算できます。
これが 微分の連鎖律（Chain Rule） です。遠く離れた原因（A）と結果（z）の関係を、中間段階の 掛け算 で結びつけるのです。
3. バックプロパゲーション：逆に燃えるデバッグ
この "責任転嫁" プロセスをシステム全体に拡張したものが バックプロパゲーション です。
- Forward（順伝播）：データを入れて結果を出します。（まずは仕事を終える）
- Loss Calculation：正解と比較してどれだけ外れたかを計算します。 （事故発生）
- Backward（逆伝播）：出力層から入力層へ向かって「あなたのおかげでエラーがこうなった」と言いながら逆行します。
開発者にとっては、スタックトレース（Stack Trace）を底辺から逆に読んでバグの根本原因（Root Cause）を探す プロセスと完全に同じです。
最後のエラーメッセージ（Loss）を見て、その関数を呼んだ人、さらにその人を呼んだ人…と逆行しながら git blame を叩くイメージです。
4. PyTorch の Autograd：自動化された監査チーム
numpy でディープラーニングを作るとき、最も苦痛なのはこの微分式を手で導出してコードに落とし込むことです。 （行列微分で脱毛します。）
PyTorch が偉大なのは、この複雑な "責任転嫁" を Computational Graph（演算グラフ） という地図に描き、自動で処理 してくれるからです。
- あなたが
loss.backward()を呼ぶ瞬間、 - PyTorch の Autograd エンジン（監査チーム） が出動します。
- グラフの終端から始めて、すべてのノードを逆に訪れ、連鎖律（掛け算）を実行します。
- そして各パラメータ（Weight）に "あなたの責任分（Gradient）は0.003だ" と貼り付けます。
私たちはその貼り付けられた値だけを修正（optimizer.step()）すれば良いのです。
5. まとめ：しかし責任が消えてしまったら？（Vanishing Gradient）
この完璧に見えるシステムにも致命的な弱点があります。
責任を転嫁し転嫁し（掛け算を続けて）、層が深くなると責任が 0 になってしまう現象が起きます。
"私の責任ではない" × 0.1 × 0.1 × 0.1 … を続けると、前方のレイヤーには "修正するものがない（Gradient = 0）」 という誤った信号が伝わることもあります。
これが有名な 勾配消失（Vanishing Gradient） 問題です。ディープラーニングの冬を呼び込んだこの問題を、現代のAIはどう解決したのでしょうか？（ヒント：ReLU と ResNet）
コメントはありません。