はじめに
「モデルの精度は出た。ではこれをどう本番で回し続けるのか」——この問いに、統計やアルゴリズムの本はほとんど答えてくれません。
本書『信頼性の高い機械学習 ―SRE原則を活用したMLOps』は、まさにそこだけを扱った一冊です。まえがきの冒頭にある宣言が、本書の性格を端的に表しています。
本書は、機械学習がどのように機能するかについての本ではありません。機械学習を機能させる方法について書かれた本です。
著者陣は、Google、Apple、Microsoft などで大規模な広告ターゲティングや検索・推薦システムを構築・運用してきたメンバーです。SRE の名著『SRE サイトリライアビリティエンジニアリング』の発起人である Niall Richard Murphy 氏、機械学習における技術的負債の論文で知られる D. Sculley 氏、Google で ML SRE を率いる Todd Underwood 氏らが名を連ねています。
「MLシステムが壊れるほど壮大で魅力的な方法のほとんどを直接目撃する機会に恵まれてきた」と自嘲する彼らが、その屍の山から何を学んだかを書き残した本、と言い換えてもよいでしょう。
本記事では、システム設計・アーキテクチャに関心のあるエンジニアの視点から、本書の構成と特に示唆に富んだ論点を整理します。
書誌情報
| 項目 | 内容 |
|---|---|
| 原題 | Reliable Machine Learning: Applying SRE Principles to ML in Production |
| 著者 | Cathy Chen、Niall Richard Murphy、Kranti Parisa、D. Sculley、Todd Underwood |
| 訳者 | 井伊篤彦、張凡、樋口千洋（異業種データサイエンス研究会） |
| 出版社 | オライリー・ジャパン（原書2022年 / 邦訳2024年） |
| 構成 | 全15章 |
本書の立ち位置
アルゴリズム以外の全部
本書は自らを「アルゴリズム指向ではなくシステム全体指向」と定義しています。扱うのは、データを正しく責任を持って扱うこと、信頼できるモデルを構築すること、本番環境へのスムーズかつ可逆的な道筋を確保すること、更新の安全性、コスト、性能、ビジネス目標、組織構造——といった「厄介で複雑、そして時にはフラストレーションのたまる作業」です。
MLモデルの作り方を書いた資料は山ほどあるが、MLシステムの作り方を書いた資料は少ない、という問題意識が根底にあります。この区別は本書全体を貫く軸なので、最初に押さえておくとよいでしょう。
なぜ SRE というレンズなのか
既存のML本の多くは「MLをより速く、より生産的にする」ことを約束しますが、「MLを信頼性高くする」ことを語る本はほとんどない、と著者らは指摘します。
そこで持ち出されるのが SRE です。SLO、エラーバジェット、段階的ロールアウト、障害対応、ポストモーテムといった、ミッションクリティカルなシステム運用のために積み上げられてきた原則群を、MLシステムに適用するとどうなるか。ただしこれは単純なリフト&シフトではない、と釘を刺します。共通する部分は多いものの、懸念事項・課題・解決策は実際にはかなり異なる、というのが本書の出発点です。
YarnIt という架空の題材
本書は全編を通じて、yarnit.ai という架空のオンライン毛糸店を例に議論を進めます。編み物・かぎ針編みの製品をサプライヤーから仕入れ、サイトに掲載し、世界中に販売する——という比較的シンプルなビジネスです。
このお店に ML を入れようとした瞬間、検索ランキング、推薦、ダイナミックプライシング、カート放棄予測、在庫と発注の自動化、不正検知、マージン改善……と複雑さが一気に噴き出します。抽象論に流れがちなMLOpsの議論を、常に具体的な事例に引き戻す仕掛けとしてよく機能しています。
全体構成
本書は大きく三部構成として読めます。
第1部：概要と一般原則（1〜6章）
MLライフサイクル全体の俯瞰から始まり、データ管理、モデルとは何か、品質評価、特徴量と訓練データ、公平性・プライバシー・倫理という、以降の全章に影響する土台を扱います。
第2部：モデルとそのライフサイクル（7〜10章）
訓練システム、サービング（運用）、監視と可観測性、そして継続的ML。技術的な中核部分です。
第3部：組織への統合（11〜15章）
障害対応、製品との関わり方、組織設計、組織事例、実践ケーススタディ。ここが本書の特徴的な部分で、「ML障害の解決は、必ずしもエンジニアリングだけで行うものではない」という主張が展開されます。
各章の要点
1章 はじめに — MLループ
MLアプリケーションは決して完成しない、という指摘から始まります。
思考実験がわかりやすいので引用します。モデルの性能が閾値に届かなければ、当然チームは原因を探して改善します。逆にうまく機能した場合はどうなるか。組織は期待を膨らませ、「もっとやればもっと良くなるのでは」と考えます。どちらに転んでも、やることは同じ——パイプラインを直し、特徴量を変え、データを足し引きし、モデルを作り直す。最初のモデルは出発点に過ぎません。
MLライフサイクルは以下のループとして提示されます。
- データ収集と分析
- ML訓練パイプライン
- アプリケーションの構築と検証
- 品質と性能の評価
- SLOの定義と測定
- ローンチ
- 監視とフィードバックのループ → 1に戻る
このうちローンチの節で示される注意点が、設計の観点から特に重要です。
- コードとしてのモデル：モデル投入はコード投入と同じリスクを持つ。連休前にモデルをローンチしない
- ゆっくりとローンチする：ユーザーとサーバーの2次元で被害を抑える
- リファクタリングではなくリリース：一度の変更は最小に。MLでは些細なリファクタでも原因追跡が困難になる
- データ層でロールアウトを分離する：新旧のコードパスでログを混ぜない
- ローンチ中のSLO測定、ロールアウトのレビュー
「データ層でロールアウトを分離する」については、決済システムでの実話が紹介されています。新機能ロールアウト中にエラーが出たのでロールバックしたら、エラーが100%になってパニックになった、という話です。原因は、新バージョンが書き込んだ新フォーマットのログを、ロールバック後の旧バイナリが読めなかったこと。そのままロールアウトを完了させていればエラーは消えていた、という皮肉なオチです。ステートフルなシステムのロールバック計画は、データ層まで含めて考える必要があります。
監視については、3つの階層が提示されます。
| 階層 | 内容 | 難易度 |
|---|---|---|
| システムの健全性 | ゴールデンシグナル（レイテンシ、トラフィック、エラー、飽和） | ML以前と変わらない |
| 基本的なモデルの健全性 | モデルサイズ、読み込み成否など、中身を知らずに測れるもの | 文脈非依存で価値が高い |
| モデルの品質 | ドメイン固有のシグナル | 最も難しい |
2章 データマネジメント
データの段階（作成・取り込み・前処理・保管・管理・分析）と、信頼性（耐久性、一貫性、バージョン管理、性能、可用性）、保守性（セキュリティ、プライバシー、ポリシーとコンプライアンス）を扱います。
着手順が実務的です。ポリシーとガバナンス、データ変換パイプラインの一元化、そして特徴量ストアを含むインフラ。「データサイエンスチームが組織のあちこちで特注の変換パイプラインを作っている」状態は将来の技術的負債になるため、早めにサービスとして集約すべきだと説きます。
3章 MLモデルの基礎
モデルアーキテクチャ / モデル定義 / 訓練済みモデル という3層の区別が導入されます。これは11章の障害対応で「どれが変化したのか」を切り分ける際に効いてきます。脆弱性の所在も体系的に列挙されています。
- 訓練データ：不完全な適用範囲、偽相関、コールドスタート、自己実現的予言とMLのエコーチェンバー、世界の変化
- ラベル：ラベルノイズ、誤ったラベル、不正・悪意のあるフィードバック
- 訓練方法：過学習、安定性の欠如、深層学習特有の問題
章のまとめにある一文が本書全体のテーゼでもあります。
モデルの動作は、形式的な（プログラムの）仕様ではなく、データによって決定されます。
4章 特徴量と訓練データ
特徴量ストアの設計、アノテーション作業の品質計測、能動学習、メタデータシステム（データセット・特徴量・ラベル・パイプラインそれぞれ）を扱います。アノテーションを「人間が行う作業」ではなく「独自のシステムを必要とする工程」として捉え、最終的には特徴量ストアに統合すべきだと述べている点が特徴です。
5章 モデルの確実性と品質の評価
確実性（soundness）テストと品質テストを明確に分けているのがポイントです。
- 確実性テスト：新バージョンがシステムを壊さないか。フォーマット互換性、計算・メモリ・レイテンシのリソース要件が許容範囲か
- 品質テスト：予測性能が向上しているか。ホールドアウト、段階的検証、ゴールデンセット、ストレステスト分布、細分化された分析、反実仮想テスト
CI におけるビルド検証とテスト検証の分離に近い発想で、この2つを組み合わせて初めて本番投入への信頼が確立される、という整理です。
6章 公正さ、プライバシー、倫理的なMLシステム
公平性の定義と達成、プライバシーの技術的・制度的対策、責任あるAI（説明性、有効性、社会的・文化的妥当性）を扱います。印象的なのは「終着点ではなくプロセスとしての公平性」という節タイトルと、次の一文です。
人が認識できる変更は、計算技術よりも理解しやすく、透明性が高いことが多いです。
会議で懸念を口にできる状態を作る、レッドチームを設ける、倫理指針をローンチ承認のチェックリストとして使う——といった、制度側からの介入が推奨されています。
7章 MLモデル訓練システム
本書で最も密度が高く、設計者にとって示唆に富む章です。11個の信頼性原則が並びます。
- ほとんどの障害はMLの障害ではない
- モデルは再訓練される
- モデルは複数のバージョンを持つ（しかも同時に）
- 良いモデルもいずれ悪くなる
- データが利用できなくなる
- モデルは改善可能であるべき
- 特徴量は追加、変更される
- モデルの訓練が速すぎる
- リソースの活用は重要
- リソース利用率は効率ではない
- 機能停止には復旧も含まれる
いくつか補足します。
1. ほとんどの障害はMLの障害ではない
長期にわたって障害を調べると、ほとんどはMLに特有ではなく、分散システム一般のソフトウェア・システム障害だった、という経験則です。「訓練システムがデータを読む権限を失ったのでモデルが何も学習しなかった」「本番にコピーしたバージョンが想定と違った」といった、拍子抜けするほど普通の障害が並びます。
だから対策の順序も明快で、まずソフトウェアのバージョニングとデプロイ、権限とデータアクセス、データ更新ポリシー、複製システム、検証を固める。ML固有の作業に取りかかる前に、分散システムとしての信頼性を全部やる、という順番です。
4. 良いモデルもいずれ悪くなる
バックアッププランとして、まず非ML（あるいはより単純なML）のフォールバック実装を作ることが挙げられます。推薦モデルが使えないときは単に人気商品を出す、といったヒューリスティックです。ただし本書はここで一歩踏み込みます。この方式はMLモデルの上限を縛ってしまう。MLがヒューリスティックよりはるかに優れたものになれば、どんなバックアップも十分ではなくなる。導入初期には妥当な選択肢だが、本気でMLを活用するなら脱却すべきだ、と。そして重要な指摘が続きます。
モデル品質の問題は、運用技術上の問題であると同時に、モデル開発上の問題でもあります。
モデル開発と運用の間に、固定された防波堤は存在しない。この境界の曖昧さこそが、MLシステム設計の難しさの中核だと感じました。
8. モデルの訓練が速すぎる
分散訓練でパラメータサーバ的な構成をとる場合、複数の訓練タスクが同時にモデルを参照・更新することで競合状態が生まれ、モデルの一部が過剰に動いてしまう。結果、速く訓練すると品質が下がり、遅く訓練すると良くなる、という直感に反する現象が起きます。
検出方法は身も蓋もありません。同じモデルを速く・遅く訓練して品質指標を比較する、という「不便で苛立たしい現実的なテスト」しかない、と書かれています。
9〜10. リソース利用率と効率は別物
リソース利用率は「支払ったリソースをどれだけ使えているか」であり、無駄の逆数です。一方で効率は「生み出した価値をコストで割ったもの」。コストの測り方には金額連動とリソース連動があり、クラウド価格の変動に左右されない後者（CPU秒・GPU秒）が改善プロジェクトの評価には向く、と整理されます。
そして釘を刺されます。
私たちの目的はモデルを訓練することではなく、組織と顧客に何らかの変化をもたらすことが目的です。
効率という概念を持たない組織は、最終的に時間と労力の配分を誤る。多少不正確でも改善可能な尺度を持つ方がはるかにましだ、というのが結論です。
8章 サービス運用
まず問うべき質問から入ります。どんな負荷か、レイテンシ要件は何か、どこで動かすのか（ローカル / 自社サーバ / クラウド / デバイス）、どんなハードウェアが必要か、モデルはどう保存・ロード・バージョン管理・更新されるか、本番の特徴量パイプラインはどうなるか。その上で、オフライン運用（バッチ推論）、オンライン運用、サービスとしてのモデル、エッジでの運用という4つのアーキテクチャが利点・欠点つきで並びます。
「8.4 精度重視か回復性重視か」の節が示唆的です。回復力のあるモデルは正解率やAUCで最適ではないかもしれないが、幅広いデータで良好に動き、過剰適合が少なく、長期的には性能が優ります。つまり常時監視と再訓練を必要としない。運用コストまで含めて評価軸を持つべきだ、という主張です。
回復力の評価方法として、交差検証における標準偏差の小ささ、長期運用時のエラー率の類似性、テストと検証のエラー率の乖離の小ささ、入力ドリフトによる影響度合いが挙げられています。
9章 モデルの監視と可観測性
MLの監視が難しい理由として、技術的な難しさよりも先に「認識の問題」が挙げられているのが面白い点です。
モデル開発者の多くは、開発時に適用しているのと同じ検査要件を、本番稼働中にも適用できるし適用すべきだ、と認識していない。指標を最適化のために使うことはできても、検出のために使うという発想がない、という指摘です。
技術的な難しさとしては、開発環境で本番を再現することの困難さ（アーキテクチャの多様性、ログ操作の不可能性、そして何よりデータ分布の違い）が挙げられます。
スキューの整理も有用です。MLでは統計的な意味での「歪み」より、同期されているべき2つのデータストリーム間の対応の失敗を指すことが多い。中でも運用上問題になりやすいのが訓練運用間スキュー（training-serving skew）で、訓練時と運用時の特徴量の差異、データのギャップ、フィードバックループが主因とされます。
監視戦略の推奨事項をまとめると以下のようになります。
- 実績値がほぼリアルタイムで取れるなら、それが最良のシグナル。取れないなら部分情報を組み合わせて全体像を作る
- モデル性能統計を公開する。予測不能時、信頼度が大幅に低い時、フォールバックパスの呼び出し過多はすべて監視対象
- 入力データの分布を継続追跡する（PSI、KLダイバージェンス、ワッサースタイン距離など）
- サービング側は4つのゴールデンシグナルで扱う
- 警告は指標選定と閾値設定が本体。誤ると全員が警告に溺れ、認知的注意を奪われる
訓練の監視については「キャッチアップ時間」という概念が紹介されます。20時間かかるモデル構築を24時間ごとに回している状況で、8時間走って4時間止まったらどうなるか。残り12時間に対して必要な訓練は12時間——既に期限ぎりぎりです。現在時刻+追いつくまでの時間が閾値を超えたら警告する、という設計は素直に真似できそうです。
また、運用時の説明可能性の黄金律として「個別推論レベルの説明可能性」が挙げられます。なぜこの特定のトランザクションが拒否されたのか、を答えられること。予測ID を記録し、後から実測値をバックフィルして比較できる形にしておく、という実装指針も具体的です。
10章 継続的なML
継続的に再訓練され続けるシステムについて、6つの洞察が示されます。
- 外界の出来事が私たちのシステムに影響を与えるかもしれない
- モデルは、フィードバックループを通じて、将来の訓練データに影響を与える可能性がある
- 時間的影響は、いくつかのタイムスケールで発生する可能性がある
- 危機対応はリアルタイムで行われなければならない
- 新たなローンチには、段階的なローンチと安定したベースラインが必要である
- モデルはただリリースするのではなく、管理しなければならない
危機対応の戦略として、訓練の停止、フォールバック（縮退運用）、ロールバック、不良データの除去、ロールスルー（改善を待つ）の5つが提示されます。
選択の判断軸として提示される問いが鋭いです。「モデルが壊れているのか、それとも今すぐはるかに困難な要求を処理するよう求められているだけなのか」。判別方法として、ゴールデンセットでオフライン再評価し、性能が急落していればロールスルーは誤り、と示されます。
A/Bテストについての注意も重要です。科学実験ではAとBは独立ですが、継続的MLではモデル自身が訓練データを生成するため独立ではありません。本書はこれを、ウールのセーターを着た人が暖かくて嬉しくなり、綿のセーターの人にスープを作りに行ってしまう実験にたとえています。
そして章の結論は、こうです。
全てのモデルが最終的には再訓練され、強力な標準を整備することは長期的にはどの組織にも利益をもたらすため、全てのMLシステムは継続的なMLシステムとして考えるのが最も適切です。
11章 障害対応
本書のハイライトのひとつです。YarnIt を舞台にした3つの障害事例が、検出から解決、フォローアップまで一気通貫で描かれます。
事例1：探しても何も見つからないケース
運用エンジニアの Ariel が、検索結果上位5件のクリック率を可視化したところ、62%あった数値が3週間前から下がり始め、54%まで落ちていることを発見します。
調査していくと、モデル構成にもデータにも変更はない。ところがゴールデンセットの結果が3週間、異様に安定している。本番のモデルを見ると、3週間前から更新されていない。訓練が完了していない。訓練プロセスはログの到着を待っている。ログフィーダープロセスがメモリ不足で数分ごとにクラッシュしている——ここまで来て、ようやく根本原因に到達します。
「ほとんどの障害はMLの障害ではない」という7章の原則が、そのまま物語になっているのがよくできています。症状はモデル品質の劣化、原因は OOM。この距離の遠さこそがMLシステムの障害対応の難しさです。
フォローアップとして挙げられるアクションも実践的です。
- 本番モデルの「年齢」を監視する（ウォールクロック年齢とデータ年齢の両方が機械的に測定可能）
- 新しいモデルを持つための要件を決め、パイプライン各段に時間を配分する
- ゴールデンセットの結果が「変わりすぎる」だけでなく「変わらなすぎる」ときにも警告する
- 訓練率を監視し、期限に間に合わない予測が立った時点で警告する
- そして最も重要なのが、上位5件クリック率そのものの監視
「変わらなすぎるときに警告する」は、ヘルスチェックの設計としてすぐ応用が効きそうです。
障害の分析軸として、アーキテクチャと基礎条件 / 影響開始 / 検出 / トラブルシューティングと調査 / 影響 / 解決策 / フォローアップ、という7項目が提示されており、これはポストモーテムのテンプレートとしてそのまま使えます。
章のまとめの一節が、本書全体の主張を凝縮しています。
MLモデルが機能することが組織全体にとって重要だということです。したがって、モデルとデータの品質は組織内の全員の使命でなければなりません。
ML障害のトラブルシューティングには、財務、サプライヤー管理、広報、法務まで巻き込まれうる。だから ML運用エンジニアは、エンジニアがビジネスを理解し、ビジネス側が技術を理解している状態を作らねばならない、と締めくくられます。
12章 製品とMLの関わり方
MLプロジェクトのフェーズ（発見と定義、ビジネス目標設定、MVP、モデルおよび製品開発、開発、サポートと保守）と、構築 vs 購入の判断軸を扱います。順序が明快で、まずビジネス問題を具体的に理解し、次にそもそもMLが本当に必要かを評価し、必要なら買うか作るかを決める。技術的詳細に直接飛び込むな、という戒めが繰り返されます。
13章 MLの組織への統合
「MLは魔法ではありません」から始まる組織リスクの列挙が容赦ありません。メンタルモデルの慣性、異なる組織文化でのリスクの表面化、サイロ化したチームの限界。
組織設計は戦略・構造・プロセス・報酬・人材の5軸で整理されます。まとめで示される問いが実務的です。
- 組織は何を重視しているのか（関心のないことで変化を推進しても、リソースは得られない）
- 今日、人々は何をしているのか。それをどう変える必要があるのか
- 古いことではなく新しいことを行うのは、どれほど簡単になるのか
3つ目が特に効きます。新しいやり方が古いやり方より難しければ、全員が重要性に同意していても変化は遅く困難になる。正しいことを行いやすくし、間違ったことを行いにくくする——設計の話としても組織の話としても通用する原則です。
14章 実践的なML組織の事例
3つの組織パターンが、人材・プロセス・報奨・標準手順の観点で比較されます。
| パターン | 特徴 |
|---|---|
| 中央集権型MLインフラと専門知識 | 明確な焦点を持つ専門チーム。横断コラボレーションが前提 |
| 分散型MLインフラと専門知識 | 専門知識が各チームに分散。重複や不足が生じ、孤立した意思決定が一貫性のない顧客体験を生む |
| ハイブリッド（中央集権インフラ＋分散モデリング） | 共通ユースケースは中央集権化、特定ニーズは個別開発 |
成功への最大の障壁として挙げられるのは技術ではなく、リーダーシップのリスク耐性です。MLで前進するにはリスクを取り、うまく機能しているプロセスや成功しているチームの行動を変える必要がある——場合によっては成功している事業ラインを危険にさらすことも意味する、と踏み込んでいます。
15章 ケーススタディ：MLOpsの実践
実際の組織による6つの事例（プライバシーとデータ保持ポリシーへの対応、トラフィックに影響を与える連続的なMLモデル、鋼材検査、NLPのプロファイリングとステージング負荷テスト、広告クリック予測、MLワークフローの依存関係テスト）が収録されています。各事例が「背景 → 問題と解決策 → 教訓」で統一されているため、自組織との差分を測りやすい作りです。
設計者として持ち帰りたいこと
1. MLシステムは「境界を引けないシステム」である
通常のシステム設計では責務の分離が武器になりますが、本書は繰り返し、MLではそれが成り立たないと述べます。モデル品質の問題は運用の問題でもあり開発の問題でもある。障害対応には法務や広報まで関わりうる。1章の結語も「MLの分野では、利害関係の厳密な分離は実現不可能であり、有用ではありません」と明言しています。
これは設計の敗北ではなく、前提条件として受け入れるべき性質なのだと理解しました。境界を引けない以上、境界の代わりに共有された可観測性と共有された言語を用意する必要がある、というのが本書の答えでしょう。
2. 「変化しないこと」も異常である
事例1で最も鮮烈だったのが、ゴールデンセットの結果が「安定しすぎている」ことが障害のシグナルだった点です。通常の監視は「値が閾値を超えたら」で設計しますが、継続的に学習し続けるべきシステムでは、変化していないこと自体が停止のサインになります。データの鮮度、モデルの年齢、指標の分散——動いているはずのものが動いていないことを検知する設計は、ML以外でも応用範囲が広そうです。
3. 効率の分母と分子を定義しておく
7章の「リソース利用率は効率ではない」は、ML以外の文脈でも刺さります。CPU使用率が上がっても、それが価値を生んでいなければ意味がない。分子（価値）を何で測るかを先に決めておかないと、測りやすい分母だけを最適化してしまいます。本書は分子の候補として、訓練された特徴量の数、処理した事例の数、訓練した実験的モデルの数といった実務的なプロキシを挙げます。完璧でなくてよいので改善可能な尺度を持て、という姿勢が現実的です。
4. フォールバックには「卒業」がある
ヒューリスティックなフォールバックは導入初期には正しいが、本気でMLを活用するなら脱却すべき、という指摘は考えさせられました。安全策が能力の上限を規定してしまう構図は、ML以外の設計判断にも見られます。フォールバックを設計するときは同時に、それを外す条件も決めておくべきなのでしょう。
こんな人におすすめ
- 強く勧めたい人：MLモデルを本番に載せた（載せる）立場の方、SREやプラットフォームエンジニアとしてMLシステムの運用を引き受けた方、分散システムの信頼性設計をMLという特異なワークロードに応用したい方
- 得るものがある人：MLの導入可否を判断する立場の方（12〜14章）、データ基盤の設計に携わる方（2章と4章）
- 期待が外れる人：モデルアーキテクチャやアルゴリズムの詳細を求める方。本書は意図的にそこを扱いません
本書は「どの順番で読んでもかまわない」と明言しており、章間の相互参照が豊富です。差し迫った課題がある章から入るのが正解でしょう。
併読するとよさそうな本
本書は SRE 系の書籍を明示的に参照しています。『SRE サイトリライアビリティエンジニアリング』（障害管理は14章、ローンチは32章）、『サイトリライアビリティワークブック』、『SLO サービスレベル目標』（警告と閾値の設計は8章）、『セキュアで信頼性のあるシステム構築』（信頼性とセキュリティの不可分性）あたりです。
MLシステム設計側からは『機械学習システムデザイン』（Chip Huyen）が推薦の言葉を寄せており、補完関係にあります。技術的負債の観点では、D. Sculley らの論文「Hidden Technical Debt in Machine Learning Systems」が本書の思想的な出発点です。
まとめ
本書を読み終えて残るのは、「MLシステムとは、世界とコンピュータシステムの間のインターフェイスである」という11章の定義です。
MLの失敗は、具体的には、世界そのものとそれに関する重要な事実、世界を表現するMLシステムの能力、世界を適切に変化させるシステム全体の能力という3つの要素の間にミスマッチが生じたときに起こります。
この3要素のミスマッチという捉え方は、MLの障害がなぜ検出しづらく、なぜ組織横断的な対応を要求するのかを、うまく説明しています。世界は変わり続けるので、システムは追随し続けなければならず、追随できているかどうかは外から見てわかりにくい。だから可観測性が要り、SLOが要り、フィードバックループが要る。
そして著者らが2章の冒頭で掲げた目標——「最初に複雑さを十分に列挙し、読者が単に『これは簡単だ』と思うのを思いとどまらせること」——は、十分に達成されていると感じました。
MLシステムに関わる設計者にとって、地図として手元に置いておく価値のある一冊です。