最終更新日：
機械学習を活用したアプリ開発がさかんになるにつれて、そのようなアプリ開発に対して同じようなアプローチが有効なことに気づかれるようになりました。そこでBourke氏は、機械学習を活用したアプリ開発に共通した設計指針を明らかにするために、Apple、Google、Microsoft、Facebook、そしてSpotifyの設計ガイドラインを調べてみました。
調査した設計ガイドラインの詳細は以下の記事本文で解説していますが、それらに共通した設計手順とその手順を実行する際の指針をまとめると、おおむね以下のようになります。
- 問題の定義：解決すべきシステム工学上の問題を定義する。
- 機械学習活用の是非：定義した問題は、機械学習で解決するのが最適かどうか検討する。
- データの収集：機械学習に用いる学習データを収集する。
- システム設計：ユーザと機械学習機能のインタラクションを設計する。
- モデルリング：機械学習モデルを開発する（狭義の機械学習モデル開発）。
- 運用：製品/サービスリリース後のユーザからのフィードバック、モデルの改善方法、故障発生時の対応を決定する。
大手テック系企業の機械学習モデルに関するガイドラインは、機械学習モデルを開発するにあたっての指針や考え方を定めているだけなので、開発に使うツールや開発ノウハウは関連書籍を読んだり実際に経験したりして習得すべき、とBourke氏は述べています。
なお、以下の記事本文はDaniel Bourke氏に直接コンタクトをとり、翻訳許可を頂いたうえで翻訳したものです。また、翻訳記事の内容は同氏の見解であり、特定の国や地域ならび組織や団体を代表するものではなく、翻訳者およびAINOW編集部の主義主張を表明したものでもありません。
MLのコードは、パズルのほんの一部に過ぎない。
目次
機械学習がプロジェクトに役立つかもしれないとお考え？機械学習を生かすベストな方法を解説
「どのような機械学習プロジェクトに取り組めばいいのか」、と私はよく聞かれる。
そして私はたいてい、「あなたの好奇心による」と答える。
なぜそう答えるのか。
機械学習は非常に実験的なものなので、興味をもって弄り回すのが理解への一番の近道なのである。うまくいかないかも知れないことを試してみて、いろいろわかるのだ。
しかし、機械学習プロジェクトは、もはや魔法の産物ではない。この記事を読んでいる時に使っているデバイスは、おそらく、あなたが気づいていないさまざまな方法で機械学習を使用している（このあたりの事情は、後述のAppleの暗黙の機械学習を参照）。
そのため、今回の月刊ML（2021年4月号）（※訳註1）では、世界規模で機械学習を利用している企業が定めたさまざまな機械学習アプリの設計に関するベストプラクティスを集めてみた。
そして、それらに目を通してみると、機械学習アプリ設計を手がけるにあたって多くの重複があることに気付き始めるだろう。こうした重複に気づくのは良いことである。なぜなら、その重なりを自分のプロジェクトに生かせるからだ。
モデルや機械学習のコードの再生産性が高まるにつれ、「機械学習とはインフラストラクチャの問題である」という共通のテーマが見えてくる。
機械学習に関する共通のテーマとは、「どのようにすればデータをある場所から別の場所へ、最も速く、最も効率的な方法で転送できるのか」という既によく知られた問いかけにまつわることでもある。
自分の機械学習プロジェクトに取り組もうと考えている読者は、以下の各ガイドラインに目を通したうえで、「もっと学ぶ」のセクションにある教材を試してみよう。ただし、どんな教材も、自分で実験することで得られる知識に取って代わるものではないことを覚えておこう（実地の経験は、ガイドラインやそれに類するものに勝る）。
原註：この記事では、機械学習と人工知能（AI）という言葉を互換的に使用している。「機械学習システム」を「AIシステム」と読み替えられるし、その逆も可能だ。
Appleの機械学習のためのヒューマンインタフェースガイドライン
私は、少なくとも6つのAppleロゴが見える図書館で、AppleのMacBookを使ってこの文章を書いている。今朝、私の前にいた2人がiPhoneを使ってコーヒーの支払いをしているのも見た。
Appleのデバイスはいたる所にある。
そして、Appleのデバイスは写真の補正、バッテリー寿命の維持、Siriによる音声検索、クイックタイプ用の単語の提案など、さまざまな方法で機械学習を活用している。
Appleの機械学習のためのヒューマンインタフェースガイドラインでは、アプリのなかで機械学習を使うにあたって、同社が考えていることと開発者に推奨していることがシェアされている。
ガイドラインは2つのハイレベルな質問から始まって、その質問を紐解いていく。その質問とは、以下のようなものである。
- アプリにおける機械学習の役割は何か
- インプットとアウトプットは何か
アプリにおける機械学習の役割について、ガイドラインは次のように問いかける。実装したい機械学習は重要なもの（必要なもの）なのか、補完的なもの（あった方がいいもの）なのか。それはプライベートなものか、それともパブリックなものか。見えるのか見えないか。動的か静的か。
入力と出力については、ユーザが機械学習システムに何を入れるか、そして、そのシステムが何をユーザに見せるかについて説明している（この説明はMLモデルの入力と出力に似ているので、私はこの例えが大好きだ）。
ユーザはモデルに明確なフィードバックを与えるのか。例えば、モデルが正しいか間違っているかについて、そのモデルに伝えられるのか。それとも、暗黙のフィードバック（つまりユーザがアプリを使う以外の作業が求められないフィードバック）を収集するのだろうか。
機械学習があなたのアプリ/機能でどのような役割を果たすかを問うときに考えるべき質問。画像出典：Appleの機械学習のためのヒューマンインタフェースガイドライン
GoogleのPeople and AI Research (PAIR)
GoogleのAIのデザイン原則は、「People and AI Research（PAIR：人間とAIの研究）」というガイドブックに記載されている。
PAIRのガイドブックには、現場で遭遇するさまざまな機械学習の（たくさんある）用語をまとめた素晴らしい用語集もついている。このガイドブックでは、AIプロジェクトの設計を以下のような6つのセクションに分けて解説している。
ユーザのニーズと成功の定義
- AIができることと、開発したサービスを利用するユーザが求めることがどこで交わるのか。
- 自動化（面倒な作業をなくすこと）とAIによる機能拡張（改善）のどちらを採用するべきか。
- 理想的な結果とは何か。
データ収集と評価
- ユーザの要求をデータの要求に変換する（すべてはデータから始まる）。
- データはどこから収集するのか(責任を持って提供されているのか）。
- モデルの構築、適合、調整（良いモデルは良いデータから始まる）。
メンタルモデル（期待値の設定）
- ユーザは、MLシステムで何を実現できると思っているのか。
説明可能性＋信頼性
- AIシステムは確率的なもの（おかしな結果になることもある）なのだが、このことはどのように説明できるのか。
- MLモデルの判断方法について、ユーザはどのような情報を知るべきなのか（信頼できる説明レベルとして、例えば「ユーザの好みにもとづいて、その嗜好に応じた結果を見せている」のような信頼レベルの説明でよいのか）。
フィードバック＋コントロール
- システムを改善するために、ユーザはどのようにフィードバックできるのか。
エラーとグレースフルな故障
- 何が 「エラー」で、何が 「故障」なのか。(自動運転車が青信号で止まるのはエラーだが、赤信号で走るのは故障になる）。
- MLのシステムは完璧ではなく、いずれは故障するだろうが、故障発生時に何をするのか。
PAIRが論じるグレースフルな故障とは、機械学習システムに故障が発生してもその悪影響を限定的にしたり、ユーザからのフィードバックを得たりするノウハウの総称と解釈できる。
各セクションには、学んだことを実践するためのワークシートが付いている。
ガイドライン（特にPAIR）を読み進めていくと、「期待値を設定する」という説明の傾向に気づくだろう。この傾向は、MLシステムがどんな能力を持っているのかを率直に伝えることを訴えているのだ。MLシステムが魔法のようなものだと期待されてしまい（そんな期待を抱かれてしまうことが多いのだが）、その限界を知らなければ、ユーザは失望してしまうかも知れない。
Microsoftの人間とAIのインタラクションに関するデザインガイドライン
Microsoftの人間とAIのインタラクションに関するデザインガイドラインでは、この問題を4つの段階に分けて取り組んでいる。
- 初期状態（初めてシステムを使うユーザが知っておくべきことは何か）
- インタラクション中（ユーザがサービスを利用しているあいだにMLシステムは何をすべきか）
- エラー時（システムが間違った時、何が起こるか）
- 時間経過 (時間の経過とともにシステムがどのように改善されるか）
Microsoftのガイドラインを読むと、まるで実際にMLシステムを使っているかのように感じさせることに気つくだろう。こうしたMLシステムの使用に則したガイドラインは、AppleやGoogleのそれでも見られる。
MLシステムの使用に則した記述は次のようになる。問題の設定→解決策の作成（MLで解決するか、それともほかの方法にするのか）→期待値の設定→フィードバックを可能にする→間違ったときのメカニズムを持つ→時間をかけて改善する（そして最初のプロセス「問題の設定」に戻る）。
Microsoftの人間とAIのインタラクションカードのガイドラインは、初期段階に始まり、人が機械学習システムと対話する際の対処法までを網羅している。画像出典：Microsoftの人間とAIのインタラクションに関するデザインガイドライン
Facebookの機械学習のためのフィールドガイド
これまで解説した資料では、MLシステム全体にフォーカスするアプローチをとっていたが、Facebookの機械学習のためのフィールドガイドでは、よりモデリング面に焦点を当てている。
FacebookのMLシステム構築に関する動画シリーズでは、機械学習のモデリングプロジェクトを以下のような6つのパートに分けて解説している。
- 問題定義 – どのような問題を解決しようとしているのか。
- データ – どんなデータを持っているのか。
- 評価 – 何をもって成功とするのか。
- 特徴 – データのどの特徴が、成功の尺度に最も合致するのか。
- モデル – 問題とデータに最も適したモデルは何か。
- 実験 – これまでのステップをどのように反復し、改善していくのか。
しかし、（事前学習されたモデルや既存のコードベースなどの恩恵によって）機械学習のモデリング面がよりアクセスしやすくなるにつれて、機械学習の他のすべての部分に気を配ることが重要になる。
Facebookの機械学習に関するフィールドガイドを図示したものとして、「データサイエンスと機械学習をゼロからマスターする講座」の概要を流用した。このステップの拡張版にあたる私のブログ記事も読める。
Spotifyが提唱するMLを活用した製品設計の3原則
世界中の2億5千万人のユーザに音楽を提供するサービスをどのように構築するのか。
Spotifyのようなシステムを構築するには、まず、魔法を使う前に手作業から始め（原則3）、サービスを利用する人々がどこで摩擦に直面しているのか（原則1）を確認するために、適切な質問をし続ける（原則2）のだ。
上の文章は、Spotifyが作った機械学習を活用した製品設計の3原則をうまい言い回しでまとめたものだ。
原則1：摩擦を特定し、それを自動化する
開発したサービスの利用時に、目標達成のために苦労しているユーザがいれば、問題解決時に摩擦が生じていると見なせる。
Spotifyで新しい音楽を探しているユーザが、自分の好みに合う音楽を見つけられないことを想像してみよう。そのようなことが起こっていれば、誰かのユーザ体験が損なわれている。
Spotifyは以上のようなユーザ体験の失敗に気づいたので、機械学習を利用したレコメンデーションシステムを使って、毎週新しい音楽でリフレッシュされるプレイリスト「Discover Weekly（私が今聴いている曲）」を作った。
私のSpotifyの視聴体験を引き合いに出せば、聴いている曲が私の心を揺らすので、音楽レコメンデーションシステムを構築する際に以下に解説する他の2つの原則も守っているに違いない。
原則2：正しい質問をする
質問を繰り返そう。質問の重要性を知らないと、間違った方向に製品を設計してしまう可能性がある。
以上で解説してきた他のガイドラインにおけるステップと同様に、Spotifyのそれもサービスを使うユーザの視点から考えることを促している。ユーザ中心に考えることこそ、正しく質問することの目的なのだ。つまり、顧客が抱えている問題を見つけ出し、機械学習を使ってそれを解決できるかどうかを確認するのだ（※訳註4）。
Spotifyが音楽レコメンデーションシステムに機械学習を導入した当初は、ユーザのリスニング履歴を学習データとして採用していた。しかし、この学習データだと推奨される楽曲が万人向けなものとなり、ユーザの嗜好をあまり反映しないことが判明した。
以上の問題を解決するために、Spotify開発チームは「あるユーザがアーティスト、アルバム、プレイリスト、またはポッドキャストが好きとは何を意味しているのか」「ユーザが聴く楽曲の決定は、どのように行われるのか」「聴きたい楽曲を選択する前には、どんな情報が必要なのか」といった質問をして、その答えを探した。こうした答えにもとづいて優れたレコメンデーションシステムに関する仮説を立てたうえでさまざまなテストを実施後、機械学習を応用した。
原則3：魔法を使う前に手作業を行う
摩擦の原因とは何か。
その摩擦は、機械学習でなくても解決できるだろうか。
まずは、ヒューリスティック（どのように動作すべきか、に関して考えること）から始めてみるのはどうだろうか。
例えば、Spotifyで任意のユーザが興味を持っている新曲に関するプレイリストを作ろうとした場合、どのようにして新曲を分類するだろうか。
30日以上前の曲は新曲として分類しない、というアイデアを出発点にするのがヒューリスティックなアプローチである。
複数のヒューリスティックや仮説を（手作業で）検証した後であれば、機械学習が役立つかどうかを再検討できる。そして、実験を行ったことで、非常に良い情報を得られたと思うだろう。
アンドリュー・ンが述べた「ビッグデータからグッドデータへ」
アンドリュー・ンは、（AI企業の）Scaleが主催した最近のカンファレンスで、MLシステムにおけるビッグデータからグッドデータへの移行に関する講演を行った。そして、（AI企業の）Roboflowがその要点を見事にまとめてくれた。その要点はいずれも、これまで解説してきたことに通じるものだ。
私が気に入っている要点は以下の通りである。
- 実装までの道のりは、ゴールではなくスタート地点に至る道（概念実証と製品のギャップを埋める）
- ビッグデータからグッドデータへ（MLOpsの最も重要なタスクはMLプロジェクトのライフサイクルのすべてのフェーズで高品質のデータを確保することであり、すべての企業がビッグデータにアクセスできるわけではない）
- コードベースのアプローチを凍結し、データを反復する（多くの問題においてモデルは解決済みの問題である一方で、データこそが都度生じる問題で必要になるもの）。
ビッグデータと同様にグッドデータも重要であるという考えを述べるアンドリュー・ン。画像出典：Scale主催のTransformカンファレンスにおけるアンドリュー・ンによる「ビッグデータからグッドデータへ」のプレゼン動画
さらに学ぶ
上記はいずれも、MLを使ったシステムを構築するための考え方に関するガイドラインだ。それゆえ、そうしたガイドラインはツールやMLシステム構築の方法を必ずしも示しているわけではない。
以下は、以上のギャップを埋めるために私がおすすめする追加資料である。
追加資料のなかからひとつを選び、MLを活用したプロジェクトに取り組みながら、資料に書かれた内容や実験を読破して試してみよう。
- 機械学習のためのエンジニアリング・ベスト・プラクティス（Software Engineering 4 Machine Learning） – 機械学習コンポーネントを備えたソフトウェア・システムの開発に関する徹底したガイド。
- アンドリー・ブルコフが著した機械学習工学の著作（※訳註5）- 上述したガイドラインやステップの多くを網羅したワンストップショップ（※訳註6）のような本で、私はこの本を机の上に置いて参考にしている。
- CS329S：機械学習システム設計 – スタンフォード大学のコースで、機械学習を利用したシステムを設計するためのすべてのステップを網羅している。チップ・ヒューイェンが指導し、さまざまな機械学習企業のエンジニアがゲストとして講義を行っている（私もゲスト講師として参加した）。
- フルスタック・ディープラーニング – 機械学習はモデルを構築したら終わりではない（上記を読んで、モデルはシステム全体のごく一部であることがわかっただろう）。フルスタック・ディープラーニングでは、データの保存、データの操作、データのバージョニング（データが強調されている）、モデルの実装などのようなモデル構築にまつわる多くのステップと、それらを実行するためのさまざまなツールを紹介している。
- 「Made with ML」のMLOpsに関するカリキュラム – MLOps＝機械学習の運用。ナレッジサイト「Made with ML」のMLOpsとは、ゴク・モハンダスが徒弟制で作っているもので、「あなたにもできる方法で、MLを使ったサービスを構築する方法を紹介する」を謳っている。
- LJ Mirandaによるデータサイエンティストのためのソフトウェア工学スキルに関する優れたブログ記事 – モデルを（notebookで）構築することからフルスタックコードを書くことにまで特化したブログ記事について書くとしたら、これをおいて他にはない。
・・・
PS この記事の動画版をYouTubeでご覧いただけます。
［この記事は、私が書いている機械学習分野の最新・最高（ただし、常に最新ではない）に関する情報を含む月刊ニュースレターである「月刊ML」の2021年4月号に掲載されたものです］。
原文
『How the World’s Biggest Companies Design Machine Learning-Powered Applications』
著者
Daniel Bourke
翻訳
吉本幸記（フリーライター、JDLA Deep Learning for GENERAL 2019 #1取得）
編集
おざけん
