シェア
はてブ
機械学習モデルの精度を左右する「ハイパーパラメータ最適化」。この領域において、今やデファクトスタンダードの地位を確立しているOSSが「Optuna」です。業界における影響力は計り知れず、関連論文の引用数は1万件を超えています。
世界中で愛用されるこのツールですが、その始まりは大規模なプロジェクトではありませんでした。実は、ある一人のエンジニアが「自分が使いたいから」という動機で生み出した、個人開発のソフトウェアだったのです。
生みの親は、当時Preferred Networksに在籍しており、現在はSakana AIで活躍する秋葉拓哉さん。なぜ、一人のエンジニアが生み出したツールが、世界の景色を変えることができたのでしょうか。そこには、技術的な実力はもちろんのこと、時代の変化を見極める鋭い戦略眼がありました。本記事では、開発の裏側にあった思考を探ります。
研究者とエンジニアの素養を持った自分なら、きっとより良いツールを作れる
――「Optuna」が登場した背景から伺わせてください。当時、既存のハイパーパラメータ最適化ツールが存在していた中で、なぜあえて新しいツールを作ろうと考えたのでしょうか？
理由はシンプルで、大きく分けて2つあります。
一つは、純粋に私自身が使いたかったからです。当時、自分の用途に合ったツールが見当たらず、既存のものに不満を感じていました。どれもソフトウェアとしての完成度がいまひとつ。「自分が欲しいと感じるツールは、きっと他の誰かにとっても価値があるはずだ」という思いが開発の原動力になりました。
もう一つは、「このソフトウェアを作る上で、自分が適任な人間だ」と思えたことです。当時の状況や自分のスキルセットを客観的に見たとき、「自分なら、今あるものよりも優れたツールを作れる」という確信がありました。
既存のツールは、ハイパーパラメータ最適化という専門性の高い分野であるがゆえに、アルゴリズムの研究者が開発を主導するケースが多かったのだと思います。彼らは数理的な理論には強いですが、どうしてもソフトウェアエンジニアリングの側面は弱くなりがちでした。
一方、私は研究者としてのバックグラウンドがあり、最新の論文を読み解いたり、自ら論文を執筆したりするアカデミックな素養があります。また、プログラミングコンテストでの実績や、実務での開発経験もあり、堅牢で使いやすいソフトウェアを設計・実装するエンジニアリングのスキルも持っています。
研究とエンジニアリング、その両方の強みを掛け合わせることで、より実用的なツールを作れるはずだと思い、「Optuna」の開発に着手しました。最初は完全に個人プロジェクトとして、業務外の時間を使って開発していました。
――最初から、納得のいく設計にできましたか？
いえ、他の方に見せるまでに、「Optuna」のコードベースは複数回書き直しています。1回目、2回目とプロトタイピングを重ね、試行錯誤を繰り返しました。そして3度目の正直で確信を持てたタイミングで、初めて会社に提案し、正式なプロジェクトとして認めてもらいました。
――何を重視して、改良を加えたのでしょうか？
当時の目玉機能として想定していたのが、学習プロセスの途中で見込みのない試行を打ち切る「枝刈り（Pruning）」です。従来のブラックボックス最適化ソフトウェアは、設定したハイパーパラメータでの学習が「完全に終了した後」に結果を見て、次のパラメータをどうするか判断していました。
ですが、もし学習の初期段階で「このやり方ではダメだ」とわかれば、最後まで待たずに途中で打ち切って、次の試行に移ったほうが効率的ですよね。当時、この機能が標準で備わっているソフトウェアはほとんど存在しませんでした。だからこそ、これを「Optuna」のコア機能にすれば差別化できると考え、実装しました。
――「途中で打ち切る」というアイデアは、当時の研究トレンドや論文から着想を得たのでしょうか？
その通りです。実は、これこそが「今、新しいツールを作るべきだ」と決断したもう一つの理由でもあります。
先ほど、自分が使いたかったから、自分なら作れると思ったから、という理由をお話ししましたが、それらは以前からずっと感じていたことでした。しかし、開発に踏み切ったのは、ハイパーパラメータ最適化の世界にパラダイムシフトが起きつつあると感じたからです。
私は常に論文をチェックしているのですが、当時、枝刈りの手法に関する情報が出始めていました。「これは間違いなく次の潮流になる」と直感しました。技術的なパラダイムシフトが起きるタイミングは、既存の勢力図が入れ替わる絶好のチャンスです。いち早くこの領域を取りに行けば、次のスタンダードになれるかもしれないと考え、勝負に出ました。
「速く行く」ための独走と、「遠くへ行く」ためのチーム構築
――「Optuna」のような新しいソフトウェアの着想を得るには、やはり先行研究や最新情報のキャッチアップは必要なのでしょうか？
そうですね、そのソフトウェアで何を目指すかにもよりますが、大きな成果を出したいのであれば、不可欠だと思います。周囲と同じ情報だけで戦おうとすると、どうしても純粋な「自分のアイデアの質」だけの勝負になってしまいますから。
成功確率を上げるには、「他の人がたどり着いていない情報」か、あるいは「独自の信念」を持っていることが重要です。たとえば、世の中の9割の人が「Aがいい」と言っているときに、自分だけは「Bのほうが絶対にいい」と確信して賭けられるかどうか。もちろん、その判断を行うためには、日頃から自分の技術力を磨いておき、審美眼を養うことも必要です。
――その後、Preferred Networksの他のメンバーも開発に加わるようになります。どのような経緯でチーム開発へと移行したのでしょうか？
当時、Preferred Networksで同僚だった佐野正太郎さんが、偶然にもこのプロジェクトに強い興味を持ってくれたんです。佐野さんはデータ分析コンペティションの「Kaggle」に取り組んでいたこともあり、ハイパーパラメータ最適化という分野自体に関心があったようです。彼が「一緒にやりたい」と言ってくれて、そこからチーム開発が始まりました。
よく引用される有名な格言に、「速く行きたければ一人で行け、遠くへ行きたければみんなで行け」というものがありますよね。実はこれ、アフリカのことわざと言われていますが、実際にはそんなことわざは現地に存在しないらしいです（笑）。ただ、出典はどうであれ、この言葉の本質は真理だと思っています。
私からのアドバイスとしては、もし0→1でシステムを立ち上げるなら、最初期の設計や実装を行う段階では、たとえ優秀なメンバーが他にいたとしても、「一人でやる」ことをお勧めします。「速く行く」ためには、コミュニケーションコストを極限まで下げる必要があるからです。
一人ならドキュメントを書く必要もありませんし、設計をガラッと変える際も誰の許可もいりません。最初の設計や実装方針が固まる前に複数人で手分けをしてしまうと、認識のすり合わせに膨大な時間がかかり、結果として開発スピードが落ちてしまいます。
しかし、ある程度形になって、そこから開発をスケールさせたり、プロダクトとして長く生き残るものにするためには、一人では限界がきます。「遠くへ行く」ためには、チームの力が必要です。
ある程度コアな部分が固まり、「ここはもう設計が変わらない」という境界線が見えてきた段階で、人を増やすべきです。リーダーとなる人間は、なるべく早く「他人に任せられる状態」を作り出し、そこから徐々にチーム開発へとシフトしていく。これが、新しいソフトウェアを開発する上で手堅い進め方ではないかと思います。
そうして佐野さんや他の方々が加わってくれたおかげで、「Optuna」は個人のツールから組織のプロジェクトへと進化していきました。
「1→100」が得意なメンバーたちがツールの成長を支えた
――「Optuna」の大きな特徴の一つに、実行時に探索空間を定義するDefine-by-Run形式のAPI採用があります。これは、Preferred Networksが開発したディープラーニングフレームワーク「Chainer」の思想をハイパーパラメータ最適化に持ち込んだものだと思いますが、どのような意図があったのでしょうか？
おっしゃる通り、当時Preferred Networksが開発していた「Chainer」が高く評価されていたため、同様の思想を取り入れようというアイデアでした。ただ正直に言いますと、ユーザーにとっての使いやすさの視点だけでなく、「既存のハイパーパラメータ最適化ツールと差別化しなければならない」というプレッシャーの影響があったようにも思います。
――結果として、その判断はどうだったと振り返っていますか？
ユーザーからは「コードを書きやすい」と好評をいただいたので、外側のAPIデザインとしては成功でした。しかし、内部の実装においては、この設計にしたことで開発の進行につれて複雑さを抱え込むことになり、開発チームには迷惑をかけてしまったなと反省しています。
実はこれ、先ほどお話しした枝刈りの話とも繋がっています。当時、私が感銘を受けた「Hyperband: A Novel Bandit-Based Approach to Hyperparameter Optimization」という論文がありました。
その論文は印象的な主張をしており、「賢いアルゴリズムでパラメータを探索するよりも、見込みのない試行を途中で枝刈りするほうがずっと重要だ」と説いていたんです。極端に言えば、「枝刈りさえ最強なら、提案ロジック自体は適当でもいい」と。私はその論文が提唱するパラダイムシフトにある程度期待していた部分がありました。
Define-by-Run形式は、探索空間が動的に変わるため、賢い探索アルゴリズムを実装するのには少し工夫が必要になります。ですが、「探索アルゴリズムが適当でいいなら、Define-by-Runでいいじゃないか」と判断しました。
ところがその後、研究が進むにつれ、「枝刈りがあってもなお、探索アルゴリズムも高度なほうが良い結果が出る」という流れになってきたんです。「Hyperband」の原著論文も改訂されるにつれ著者らが主張を徐々に軟化させていきました（笑）。
――それは大きな誤算ですね。Define-by-Runのまま、賢いサンプリングを実装するのは難しいわけですよね？
そうです。探索空間が事前に確定していない中で高度なアルゴリズムを動かす必要が出てきたため、内部実装の難易度は跳ね上がりました。それでも、チームメンバーたちは本当に優秀でした。既存の使いやすいAPIや構造を壊すことなく、裏側でうまくつじつまを合わせ、高度な機能を実装してくれたんです。これは私一人では到底できないことでした。
私は自分のことを、何もないところから形を作る「0→1」が得意な人間だと認識しています。しかし、そこから完成度を高め、広く普及させていく「1→100」のフェーズにおいては、私よりも優れた人が他にいます。
「Optuna」に関しても、私がコンセプトと最初の実装を作りましたが、その後、辛抱強く機能を改善し、世界中で使われるレベルまで育て上げてくれたのは、間違いなくPreferred Networksのメンバーたちです。彼らの貢献なくして今の「Optuna」はありません。
とはいえ、最初の「1」がダメだったら、いくら頑張っても「100」にはなりません。だから、良い柱を立てることには貢献できたのかなと自負しています。
ユーザーが求めるのは、必ずしも最先端の機能ではない
――「Optuna」のリリース後、当初の想定と現実で「違ったこと」はありましたか？
予想と異なった部分はもちろんありました。例を挙げると、メインのターゲットとして想定していたディープラーニング領域での使われ方です。Preferred Networksはディープラーニングの会社ですから、社内では日々大量のモデルが作られています。私は、この開発効率向上に寄与したいと思って「Optuna」を作りました。
ですが、ディープラーニングの学習は、1回完了するまでに時間がかかります。「自動探索で何十回も試行を繰り返すのを待つ間にエンジニアは他の仕事を進めておく」という慣習は、「早く結果を知りたい」という気持ちに抗うのが難しい部分もあってか、あまり浸透しませんでした。
私が思い描いていた「『Optuna』がディープラーニング開発を完全に自動化し、他社よりも効率的に良いモデルを生み出していく」というストーリーは、当初の想定ほどには実現しませんでした。
ですが、嬉しい誤算もありました。ディープラーニング以外の領域に、予想もしなかった大きな需要があったことです。たとえば、社内の創薬チームや材料探索のチームです。彼らはディープラーニングのような巨大なモデルではなく、もう少し計算コストが低く、試行回数の多いシミュレーションや実験を行っていました。
「1回のループが短い」あるいは「試行錯誤の回数がものを言う」という彼らの課題と、「Optuna」の特性がマッチしていました。また、機械学習の文脈でも、ディープラーニング以外の比較的軽量なモデルでは盛んに使われるようになりました。当初私が目指していたのとは違う場所でしたが、「Optuna」はさまざまな分野で有用性を見出され、そこで不可欠なツールとして定着していきました。
また、枝刈り機能の使われ方も想定と違いました。私が「これが目玉になる！」と意気込んで実装した枝刈り機能は、実際にはそれほど多くのユーザーには使われていないんです。
――意外ですね。なぜなのでしょうか？
やはり、少し機能として複雑だからだと思います。多くのユーザー、特にライトユーザーの方々が求めていたのは、高度な機能よりも「とにかく簡単に動くこと」や「最初からある程度の成果が出ること」でした。
もちろん、枝刈り機能も「Optuna」の強力な武器の一つですし、詳しい方に紹介するときには大きなアピールポイントになります。しかし、爆発的な普及の要因が、私が必死に実装した最先端のアルゴリズムではなく、もっと手前の「使いやすさ」にあったというのは、開発者として非常に大きな学びでした。
――自分の作ったツールが想定外の使われ方をしている。そうした事態に直面した際、作り手として意識すべきことは何でしょうか？
基本に立ち返るようですが、「ユースケースを徹底的に知る」ことに尽きると思います。実際にユーザーと話をして、なぜそこで使われているのか、どんな価値を感じているのかを深掘りする。私たちも社内で徹底的にヒアリングを行いました。
ユーザーは、作り手が想像もしなかったような課題解決にツールを使っていることがよくあります。その「現場の事実」を真摯に観察し、そこから学ぼうとする姿勢さえあれば、当初の計画が外れたとしても、プロダクトをより良い方向へ進化させることができるはずです。
次世代へ託す、「世界で使われるOSS」を作るための戦略
――「Optuna」というOSSを、世界的なデファクトスタンダードにまで育て上げた経験は、ご自身のキャリアや技術への考え方にどのような影響を与えましたか？
計り知れないほど大きな影響がありました。
自分でゼロから設計したソフトウェアを、世界中で使われるレベルまで育て上げる経験はなかったので、それがうまくいったことは強烈な自信になりました。
また、成功体験だけでなく、多くの反省や学びを得られたことも財産です。「あの設計や機能は、今思うとこうすべきだった」というフィードバックのサイクルを、プロダクトの成長とともに何周も回すことができました。
――そうした努力が実を結び、今は世界のトップレベルで活躍されているのですね。
余談ですが、かつて学生時代の私は、競技プログラミングにしか興味のない人間でした。ですが、Preferred Networksの前身であるPreferred Infrastructureでインターンをした際に、優秀な先輩たちを目の当たりにして人生観がガラッと変わったんです。
世の中を便利にするようなソフトウェアを作りたいと思いました。そして、「この人でなければ作れない」と言われるようなソフトウェアを生み出す人たちが、とにかくかっこよく見えました。
特に影響を受けたのは、Googleの伝説的なエンジニアであるJeff Deanさんや、自然言語処理の分野で有名な工藤拓さん、Preferred Networksの岡野原大輔さんです。例えば工藤さんが作られた形態素解析エンジン「MeCab」は、私の理想に非常に近いソフトウェアでした。
分かち書きの性能が素晴らしく、処理速度も速い。高度な専門的アルゴリズムが、極めて品質の高いソフトウェアとして実装されている。「プログラミングもできて、研究分野の理論も理解していて、それを形にできる。こういう人に自分もなりたい」と強く憧れました。
だからこそ、今こうして自分がインタビューを受ける側になり、もし誰かの目標になり得ているのだとしたら、本当に感慨深いですね。
――これから「世界で使われるOSS」を生み出したいと考える人へ、アドバイスを送るとしたら？
もし私が今、もう一度ゼロから挑戦するとしたら、まず「タイミングとトピック選び」を最重要視します。これはOSSに限らずビジネスでも同じですが、成長している領域、あるいは激しい変化が起きている領域のほうが、参入障壁が低くチャンスが多いからです。
そして、個人や少人数のプロジェクトであれば、ある程度のリスクを取ってでも「尖った仮説」を持つべきです。すでに大企業や既存のソフトウェアが覇権を握っている領域で、同じようなものを作っても勝ち目はありません。彼らがまだ手を出していない、不確実性の高い領域にあえて踏み込む必要があります。100人が100人とも「正しい」と言うようなアイデアは、合理的すぎてすぐにレッドオーシャンになりますから。
最後に、これらを支える基礎として「コンピュータサイエンスの知識」を大切にしてください。OSS開発に限らず、基礎理論を知っていればいるほど、最終的に出来上がるソフトウェアの品質は確実に良くなります。
このインタビューが、次の世代の方々の力になれたら嬉しいです。
取材・執筆：中薗昴
取材協力：針原佳貴（AWSジャパン）
撮影：本多香
