KubeCon Europe 2026からAIを生成するデータのBoM(DBoM)が重要だと訴えるExpansoのCEOにインタビュー

アムステルダムで開催されたKubeCon＋CloudNativeCon Europe 2026から、生成AIにおいて結果の正しさを検証するためにはモデルのニューラルネットを生成する元となるデータが何からできているのか、データのBill of Materials（DBoM）を継続的に利用することが重要だと訴えたセッションを紹介した。この稿ではそのセッションを行ったExpansoの創業者兼CEOのDavid Aronchick氏のインタビューをお届けする。

簡単に自己紹介をお願いします。

Aronchick：私はExpansoという会社の創業者でCEOですが、以前はGoogleでGKEのプロダクトマネージャーをやっていました。その後はMicrosoftで機械学習のストラテジーを担当していました。他にはKubeFlowのプロジェクトの立ち上げにも参加しました。Expansoを作った背景は、Kubernetesに関わったのがきっかけでした。Kubernetesは宣言的にアプリケーションを定義して実行するためのプラットフォームですが、機械学習に関わる間にその発想をデータに応用できないか？ と考えたからです。つまりKubernetesはこのアプリケーションにはコンテナとしてこういうリソースが必要で接続する他のサービスはこれで、という感じに宣言的に定義して実行するんですが、それを機械学習のデータに対しても同じようにできないか？ と考えたんです。

しかしやってみるとデータというのはアプリケーションのソースコードとはかなり異なっていて簡単には実現できないということがわかったんですね。例としてPOSデータを使って説明しましょう。そのPOSデータには売上の情報が入っていますが、なぜか1時間だけ空白があったとします。その空白はもしかすると何らかのシステムに関するトラブルがあったのかもしれないし、ハリケーンが来ていたので店を閉じたのかもしれません。それを理解するにはそのデータだけでは無理なのです。つまりそのデータがどういう状況で作成されたのか？ という文脈、コンテキストが必要なのです。

インタビューに答えるDavid Aronchick氏

つまりデータだけではなくそのデータの属性や誰が何時作ったのか？ というメタデータのようなものが付随していないと意味がないということですか？

Aronchick：そうです。しかし普通のエンタープライズ企業であれば、そういう情報は社内のシステムの中で保持されているかもしれません。私はそれをオープンで標準的なスキーマデータとして社会の中で流通できるようにしたかったんです。つまりデータとそのスキーマデータ、セッションではデータBoM（DBoM）と命名して使っていましたが、それを使うことでそのデータの属性が公開され、交換できるようになるわけです。

実際にExpansoがビジネスとして成り立っているのはどういう仕組みですか？ オープンで標準的なスキーマを交換できるようにしたからと言ってあなたの会社が儲かるとは思いづらいんですが。

Aronchick：ExpansoはDBoMに関わるツールのライセンスを売上としています。Expansoはデータパイプラインのツールで、DBoMをサポートしています。DBoMのスキーマデータ仕様はMakotoという名称で公開しています。URLとしてはUseMakoto.devというサイトで、日本人のあなたにMakotoの意味を説明する必要はないかもしれませんが、真実という意味を持っていることからその単語を使いました。データのサプライチェーンにSLSAと同様のアシュアランスレベルを定義して使うことを意図しています。

●参考：https://usemakoto.dev/

実際にもう少し詳しく教えてください。セッションでも解説していたチャットボットが間違った回答をするという例で生成AIが使うデータが公式の情報だけではなくSalesforceに残っているドキュメントなどを使ってしまうことで間違った回答を生成してしまうという例です。あの例ではSalesforceのデータに高い優先度をつけていたことで間違ってしまうわけですが、その観点で考えると学習で使われていたデータがどこから来ているのか？ を確実に把握することができれば、間違った回答もその大元は何か？ を把握できる、つまり修正できるということになりますよね？

Aronchick：そうです。生成AIが間違った時にどうやって対処するのか？ についてはさまざまなトライアルが行われていますし、これからもホットなトピックになると思います。生成AIに与えるプロンプトを良くするのか、出力結果をガードレイルに応じてチェックするのか、手法はさまざまです。一つ確実に言えることは、その間違ったデータがどこから来たのかを知ることができれば、確実に改善は可能になるということです。そして機械学習に関わっている時に多くの論文を読んでいて気付いたことですが、実際にその論文で使われている実験データは「何時」「誰が」「どのようにして生成したのか？」を確認する方法というのがないんですよ。つまりその論文に書かれていることを信じるしかないんです。

あぁ、それはわかります。私も2026年1月にシンガポールで行われたAAAI-26に参加したんですが、合計で3万件もの論文が応募されて採択されるんですが、大量にレビューしなければいけないので生成AIでレビューを行うということが事前に公開されていたんです。その結果、少なくない数の論文にレビューする生成AIを騙すプロンプトが仕込まれていたということが紹介されていました。しかしそもそもの実験データがどういうコンテキストで作られたのかを、当事者以外は信用するしかないんですよね。でも例えば論文のPDFのグラフをクリックしてそのデータを誰が作ったのか？ を確認できれば良いはずですよね。

Aronchick：その通りです。そしてデータは変化する、つまり固定された状態ではなく状況に応じて変化していくものをスナップショット的に切り取るケースもあります。そうするとそれが何時の時点のデータなのか？ を確認する必要も生じてきます。なのでアーティファクトのSBoMよりもより厳密に確認できる必要があります。ここではデータリネージ（Data Lineage）という考え方が重要になってきます。データがETLを経て生成AIに学習されるまでの過程をちゃんと追跡できれば、保証期間が30日なのか365日なのか、どのデータからその数値が導き出されたのか？ を特定することができるからです。

この発想は生成AIの改善のための良いアイデアだと思いますが、それを実現するためには多くのベンダーからの賛同や協力が必要ではないですか？ SBoMにしてもさまざまなベンダーや業界団体が協力して推進していますが、ユーザー企業での利用はまだまだ進んでいないと思いますし。

Aronchick：このアイデアを即座に実現できるとは思っていませんが、今回のKubeConで多数の参加者から興味を持ってもらえたと思います。このインタビューもその一つですし、あなたもセッションの後にすぐに質問にきてくれましたよね？ あれから本当に多くの人と話をしてデータに関してコンテキストを利用することが重要だというコンセプトは理解してもらえたと思います。

The Linux FoundationやCNCFのようにオープンソースとコミュニティを支援する組織に標準としてホストしてもらうという発想は？

Aronchick：この発想から出てきた成果物を1社で独占するのは悪いアイデアだと思います。なのでLFやCNCFのような団体と協力して誰もが使えるような公共物として実現すると良いなとは思っています。ただし、まだこの努力は始まったばかりで最終的なゴールまではやるべきことはいっぱいあります。

最後にチャレンジは何ですか？

Aronchick：多くの人はデータについてBoMが必要だということには気付いています。データそのものではなくてその属性を一緒に処理しないと問題が起こるということに気付いているんです。そして私が公開したMakotoもDBoMも仕様（Specification）でしかないんです。なので問題が存在してそれを解決するために必要な仕様が完成してもそれをシステムに組み込む方法や経験、そしてツールが必要になります。それを使って改善点を見つける、ツールや仕様を実際に改善するというループが継続的に起こらないと社会には拡がらないんです。なのでまだ始まったばかりですが、その継続的なループを起こすというのがチャレンジだと思います。

Microsoft、Googleで多くの経験を持つベテランのエンジニアが、ターンキーのソリューションではなくデータに関する問題点を解決するために地味な仕様作りから始めたデータBoMに関しては、会期中に大きな注目を集めたようでこのインタビューを行うにも時間調整が難しかった。生成AIの検証のためにも必要なアプローチであることやデータの由来を要求するデジタル主権などの方向にも関係してくると思われる。引き続き注目していきたい。