人手も予算も足りない分野では、A.I. に対する最大の不安が、むしろ導入のいちばん強い追い風になるかもしれない。人の仕事を置き換えるというより、人が少ないままでもできることを増やす。その性質のおかげで、ミュージアムのスタッフは、もっと面白い問題に時間を使えるようになる。MLOps は深層学習の界隈でもまだ先端寄りの話で、ミュージアムでは文字どおり聞いたこともない、という扱いだろう。それでも私は、ミュージアムという仕事場に固有の条件こそ、この技術スタックを導入する見返りを大きくすると考えている。さらに、オープンソース・コミュニティと関わることで、内製の技術力不足は補えるし、私たちが使う道具について対話し、批判的に考える場としてのミュージアムの役割も見えてくる。そこでこの記事では、技術者ではない読者に向けて、次の点を扱う。
-
ミュージアムの技術エコシステムが抱える主な課題
-
機会 - なぜミュージアムに MLOps なのか
-
ケーススタディ
-
MLOps の具体像
-
xOps(DevOps、DataOps、MLOps)の概要
-
アーキテクチャ上の原則、ツール群、ベストプラクティス
-
提言
ここではコレクション管理と、それに関連するユースケースを軸に考える。ただし、ここで扱う原則やプロセスの感触は、組織内の技術エコシステムにある他のシステムにも応用できるはずだ。
ミュージアムの技術エコシステムが抱える主な課題
ミュージアムの技術担当者がよく挙げる課題のひとつは、ミュージアムの技術プロジェクトに必要な時間と労力が誤解されがちなことだ [1]。驚く話ではない。ミュージアム分野のデジタル人材不足はかなり深刻で、Arts Council England の対象組織の 37% が「デジタル面で目指すことを実現するうえで、能力と知識の不足が大きな障壁になっている」と答えている [2]。技術的な見通しが足りないままプロジェクトの範囲を切ったり、見積もりを外したりすれば、結局みんなが疲弊する。これはミュージアム業界だけの問題ではない。IT の内部でさえ、技術領域は広すぎるし、変化も速すぎる。ブロックチェーン、ネイティブアプリ開発、Web 開発、クラウド技術、サーバーレス、複合現実、データサイエンス、機械学習、アルゴリズムなどは、どれも IT やデジタルという大きな括りには入るが、実際には互いにかなり違う、専門性の高い技能だ。
内製の開発者がおらず、調達プロセスがウォーターフォール型開発を前提にしている組織では、相互に連携しない、ばらばらのシステムを抱え込みがちだ。過去から引き継いだレガシーが原因の場合もあるし、ベンダー側に相互運用性を仕事の進め方へ組み込む動機がない場合もある。そのしわ寄せは下流に出る。同じ作業があちこちで重複する。ある場所で更新した内容が別の場所には自動で反映されない。人によって参照している文書の出どころが違い、混乱が起きる。
自分の宝箱なのに、その鍵を持っていないようなものだ。何かを探しに行くたび、自分の資産へアクセスするだけで料金を取られる。もっと悪いことに、その宝箱がどこにあるのかさえ、はっきり分からないかもしれない。たとえ文書化がきちんとしていても、ベンダー A、B、C がそれぞれ別のシステムを作り、保守しているなら、彼らに互いに協力する理由はほとんどない。共同作業が必要になった途端、責任の押し付け合いになることもある。だからといって、ミュージアムがテクノロジー企業になるべきだと言っているわけではない。むしろ重要なのは、前提としてある制約を理解し、理想の到達点を描いたうえで、そこへ向かう最適な経路を設計することだ。
MLOps とは何か
MLOps は、「実験室」的な条件でモデルを作る科学研究に対して、その裏側を支えるエンジニアリングの領域だ。コンピュータビジョンの PoC [3] を本番運用へ持っていくために欠けていた材料、と言ってもいい。
「AI のすべてには、……概念実証から本番化までのギャップがあります。機械学習プロジェクトの全体像は、モデリングだけではありません。適切なデータを見つけ、デプロイし、監視し、データを[モデルへ]戻し、安全性を示す。[モデルを]デプロイするために必要なことをすべてやる、ということです。これはテストセットで良い成績を出すことを超えています。幸か不幸か、機械学習の私たちが得意なのはそこなのですが。」— Andrew Ng
機会 - なぜミュージアムに MLOps なのか
まず何より、ミュージアムで MLOps に取り組む大きな理由は、下の図 1 [4] が示すように、投資対効果を最大化し得る A.I. 技術を実運用に乗せるためだ。

図 1. ミュージアムとの関連性と、必要な労力・コストの軸に配置した、主要な AI サブカテゴリ。
ブロックチェーンやメタバースのように大きく期待された技術は、設計上できそうなことの幅に比べて、現実的なユースケースの幅がまだ追いついていない。そのぶん、実用化の時間軸も先にある。一方で A.I. は、MATANA2 企業群ではすでに大規模に導入され、主流化できる段階まで来ている。下の図 2 を見ると、ミュージアム分野と特に相性のよい A.I. イノベーションの多くが、いま Gartner の言う「啓発期(Slope of Enlightenment)」にあることが分かる。図 3 の NFT や Web3 など、ほかの新興技術とは対照的だ。
図 2. …「今後 2 年から 5 年で主流採用に達すると見込まれるイノベーション……。これらを早期に採用すれば、大きな競争優位とビジネス価値を生み、AI モデルの脆弱性に伴う問題を和らげられる」。
図 3. 2022 年の新興技術は、進化・拡張する没入型体験、人工知能による自動化の加速、技術者による提供体制の最適化という 3 つの主要テーマに分けられる。
導入を阻んできたものと、PoC から積み上がった知見の結果として、かつて研究チーム総出でなければできなかったことが、いまでは少人数でも手が届くようになった。ミュージアムは、MLOps を通じてこうしたイノベーションを活用しやすい位置にいる。理由は、そのデータと用途に固有の性質にある。コールドスタート問題、議論の場が必要であること、そして最後に、だが決して小さくない理由として、内製の人手と技術力が不足していることだ。
コールドスタート問題は、ミュージアムではとりわけ切実だ。そもそも多くのデータが存在しない。つまり、既存の訓練データが潤沢にあるわけでも、そこから学べる高性能なパイプラインがあるわけでもない。だからこそ、データセット作成、ラベリング、デプロイ、本物のデータを集めてシステムへ戻すところまでをひとつのパイプラインとして実運用に乗せる MLOps の役割が重要になる。このプロセスをできるだけ端から端まで自動化すれば、少ないリソースでより多くのことができる。
MLOps の具体像
考え方はこうだ。数人のチームと何台かのゲーミング PC があれば、作品に自動でアノテーションを付ける A.I. モデルは作れる。さらに、そのモデルを MLOps で本番運用に乗せれば、堅牢なシステムに仕上げるために必要な追加のファインチューニングも進められる。結果として、ミュージアムのコレクションはずっとアクセスしやすく、発見されやすいものになる。
以下は、色を自動抽出し、検索できるようデータベースへ追加するデモだ。
Art API 更新:色を抽出し、コレクションへ追加 19.11.2022
アーキテクチャ上の原則、ツール群、ベストプラクティス
- クラウドベース
- オープン API
- フェデレーテッドアクセス
図 4. DevOps と MLOps のツール概観。
初出は PubPub の erniesg.pubpub.org/pub/gcdzise9。


