Open Source Summit Japan 2025 初参加レポート

Thumbnail

はじめに

こんにちは、Backlog Unit の @simochee です。
2025 年 12 月 8 日〜10 日に開催された Open Source Summit Japan 2025 へ参加しましたので、そのレポートをお届けします。

わたしは、普段から個人開発をしています。開発の過程で多くのオープンソースソフトウェアを使っているため、グローバルなオープンソースコミュニティはどのようなものか興味があって参加しました。

Open Source Summit Japan とは

Open Source Summit Japan | LF Events は、Linux Foundation が主催するオープンソースに関するカンファレンスです。
*「Open Source Summit は、プロジェクトの垣根を越えてアイデアを交換し、オープンソース・コミュニティを支えるすべての人々と出会うための、極めて重要な交流の場です」*と謳われています。特定の技術や開発手法のみでなく、オープンソースに関わる幅広いテーマが扱われます。
2025 年は東京の虎ノ門ヒルズフォーラムで開催されました。

生成 AI・機械学習を掘り下げた AI_dev: Open Source GenAI & ML Summit Japan | LF Events や、自動車に特化した Automotive Linux Summit | LF Events も合同で開催されました。

また、当日のセッションは Open Source Summit + AI_dev + Automotive Linux Summit Japan 2025 プレイリストで公開されています。

参加まで

今回、OSS Summit Japan へ参加するまでに準備したことを紹介します。

用語

まず、OSS Summit Japan はウェブサイトから問い合わせ、当日のセッションまですべて英語で行われます。
加えて、グローバルなイベント特有の用語が多く使われていたため、事前に調べてなんとなく理解しておきました。

よく見かけた用語をまとめます。

用語 意味
LF Linux Foundation(主催している組織)の略称
Venue 会場
Registration 参加登録。チケットの購入なども含む
Attendee (一般)参加者
Early Bird 早期割引価格
Yen Advantage 日本円で支払う場合の割引価格

参加登録

今回、 Early Bird + Yen Advantage の組み合わせでチケットを購入しました。

Yen Advantage を適用するプロモーションコードを発行するためには、Linux Foundation のイベントチームへメールで問い合わせる必要があります。
わたしは以下のような文面でメールし、その日のうちに割引のプロモーションコードが送られてきました。

Dear Linux Foundation Events Team,

I am inquiring about the possibility of purchasing a yen-advantaged ticket for the upcoming OSS Summit.

I am a resident of Japan and, due to the current exchange rate, the cost of the ticket in Japanese yen is significantly higher. I am hoping you can help me with this financial burden.

Please provide me with more information on how to proceed with the purchase using a yen-advantaged rate.
Thank you for your time and consideration.

Best regards,

あとは OSS Summit Japan のウェブサイトからアクセスできるチケットサイトでプロモーションコードを入力し、チケットを購入しました。

参加セッション選び

セッションは 7 つのルームで同時に開催されるため、事前に参加したいセッションを選んでおきました。

Open Source Summit + AI_dev: Open Source GenAI & ML Summit + Automotive Linux S Schedule では、参加したいセッションを My Schedule に追加できる機能があったため、福岡から東京に移動する間でピックアップしました。

セッションのテーマの幅が広かったのですが、各セッションの概要を事前に確認できていたことで当日はスムーズに参加できました。

会場の様子

会場は 4 階と 5 階に分かれており、それぞれにセッションルームが配置されていました。

メインホールは 5 階にあり、かなり広々としていて、特にキーノートセッションでは多くの参加者が集まっていました。

多くの参加者が集まる広々としたメインホールの様子。前方のスクリーンにはプラチナスポンサーの企業ロゴが表示されているメインフロア (5階)


Open Source Summit Japanのイベント会場に設置された、スポンサー一覧とフロア案内のボードスポンサー一覧とフロア案内

個人的に心配だった英語のセッションも、すべてのセッションで文字おこしとリアルタイム翻訳が提供されていたため、大体の内容を理解できました。
ただ、他の参加者と会話するのは難しかったので、しっかり英語力を身に付けてから参加したほうがより楽しめると感じました。

印象に残ったセッション

OSS Summit Japan 2025 を通して、特に印象に残ったセッションを紹介します。

Panel: OSPOjp: Ways To Level up OSPO Stages With Knowledge and Strategies From Local Meetup Japan

セッション資料: OSPOjp-WaysToLevelup-OSPO_Stages20251208

このセッションでは、企業などの組織がオープンソースとどのように向き合い、その活動を成熟させていくべきかについて、日本でのローカルな活動事例を交えて語られました。

コンプライアンスのその先へ行けないジレンマ

特に印象に残ったのは、多くの企業が陥りがちな「OSS Pitfall Loop(落とし穴のループ)」という話です。

スライドタイトル「多くの組織には全体的なOSS戦略がなく、コンプライアンス等に限定されている」。中心には「OSSの落とし穴ループ」という循環図があり、1.貢献の推奨、2.経営層による価値への疑問、3.活動の削減指示、4.プロジェクトと組織双方がダメージを受ける、という4段階の負のサイクルが描かれています。左側には、評価基準がない中で板挟みになり困惑する社員のイラストが添えられています。セッション資料より: Many orgs have no overall open source strategy (or it's limited to licensing & compliance)

企業が OSS を活用しようとするとき、まずはライセンスやセキュリティといったコンプライアンスの整備から始まります。
ところが、多くの企業がこの「守りのルール作り」だけで燃え尽きてしまうのだそうです。
リスク管理ばかりでは、経営層には「コストセンター」としか映りません。
その結果、さらなる活動への投資が得られず、コミュニティ貢献や戦略的な活用といった次のステージに進めないまま縮小してしまいます。

コンプライアンスは大事だが、それだけやっていても未来はないという現実は、開発現場の視点からも非常に納得感のある、耳の痛い話でした。

OSPO – 組織を成熟させるための地図

この停滞した状況を打破し、組織を次のステージへ引き上げるための機能として紹介されたのが OSPO (Open Source Program Office)です。

OSPO という言葉は OSS Summit Japan 2025 で初めて耳にした用語でした。
はじめは「OSS を管理する部署」というイメージでしたが、セッションを通じて大きく変わりました。OSPO は単なる監査役ではなく、組織がコンプライアンスの壁を越えて、OSS から価値を生み出す体質へ変えるための推進役であると理解しました。


「Maturity model of OSS / OSPO activities」と題された階段状の図解。横軸に「OSPOレベル」、縦軸に「実行能力」をとり、組織の成長を5つのステージで示しています。 下から順に、ステージ0:Adoption、ステージ1:Legal Education、ステージ2:Community Education、ステージ3:Engagement、そして最高位のステージ4:Leadershipへと進化する過程が描かれています。セッション資料より: Maturity model of OSS / OSPO activities

スライドで示された成熟度モデルを見ると、確かに初期段階ではガバナンスや教育が主たる役割です。
しかし、組織の成熟に合わせて、その役割は社外コミュニティとの関係構築や戦略的な意思決定の支援といった攻めのアクションへと明確にシフトしていくことが示されています。

これまでチャレンジしてきたオープンソース活動がどのステージにあるのかを振り返り、次に目指すべき姿を考える上で非常に参考になる枠組みだと感じました。

サプライチェーンを支える「My OSPO is for Your OSPO」

「My OSPO is for Your OSPO」というタイトルのスライド図解です。ソフトウェアのサプライチェーン(Lib Provider、SW Vender、App Creator)において、それぞれの組織にある「OSPO」が相互に連携している様子が描かれています。セッション資料より: My OSPO is for Your OSPO

また、セッション中で語られる「My OSPO is for Your OSPO」という言葉にはハッとさせられました。

これは、ある企業の OSPO が自社製品の依存関係やライセンスを適切に管理することは、その製品を利用する他の企業(サプライチェーンの先にある企業)の OSPO にとっても助けになるという考え方です。
面倒な管理業務も、巡り巡ってエコシステム全体の信頼性を支える貢献になるという視点は、これからの開発活動における大きなモチベーションになると感じました。

参考資料

Cherry Blossom and Compliance – An Intro To the EU CRA

セッション資料: Cherry Blossom and Compliance – OSSJ2025

このセッションでは、欧州で施行された EU Cyber Resilience Act (CRA: サイバーレジリエンス法)の概要と、それがオープンソース・コミュニティや企業にどのような影響を与えるのかが解説されました。

EU CRAとSaaS開発者としての視点

CRA は、EU 市場で提供される「デジタル要素を持つ製品(PDE)」にセキュリティ基準を課す法律です。私の所属するチームでは日本から世界へ SaaS を提供しており、欧州のユーザーも多いため「自分たちのサービスも規制対象になるのでは?」と身構えて聴講しました。

しかし、セッションを聴き進めると、CRA の主な対象は「製品(パッケージソフトウェアや組み込みデバイスなど)」であり、純粋な SaaS(サービスとしてのソフトウェア)は基本的に対象外であるという整理でした。
SaaS は別途「NIS2 指令」などの枠組みで管理されるため、今回の CRA 施行によって直接的な開発フローの変更を迫られるわけではないと分かり、ひとまず安心しました。

規制の本質とビジネスへの影響

CRA が求めているのは、リスク評価や依存関係の透明性、そして脆弱性への迅速な対応です。
たとえ直接の規制対象でなくても、これらは現代の開発において「当たり前」の品質と言えます。
特に、脆弱性発見から 24 時間以内の報告義務といった厳しいスケジュール感は、企業の CFO が頭を抱えるレベルのリスクとして紹介されており、法的な強制力の重さを実感しました。

オープンソースを使う立場としての関わり

個人開発や業務で多くの OSS を利用する身として印象深かったのは、欧州のセキュリティ強化という厳格な法規制の中に「オープンソース」という存在が明確に組み込まれていたことです。


「Who am I?」というタイトルのスライド画像。左側に「Manufacturer」「Open source steward」「Maintainer/contributor」という3つの役割が箇条書きで並んでおり、それぞれに対応する説明が矢印で示されています。Manufacturerには「Conformance」「Vulnerability reporting」「Incident reporting」、Open source stewardには「Few obligations (Support and reporting)」、Maintainer/contributorには「No change!」と記載されています。セッション資料より: Who am I?

CRA では、個人のコントリビュータには直接の法的責任を問わない一方で、「Open Source Steward(OSS スチュワード)」という概念を導入しています。
このように、法律の枠組みの中に OSS の特性に合わせた役割が定義されたことは、公的な場でオープンソースの重要性が正式に認められ、考慮されているように見えて非常に感慨深かったです。
法規制が単なる足かせではなく、OSS がソフトウェア・エコシステムの不可欠な一部として扱われていることを再認識する良い機会になりました。

最後に、「オープンソースは透明性が高いため、実は CRA への適応はクローズドな製品よりも容易である」というポジティブな締めくくりが印象的でした。セ
ッションの締めにはコンプライアンスをテーマにした「俳句」まで披露され、複雑で堅苦しい法律の話が、とても身近で親しみやすいものに感じられた素晴らしい発表でした。

「Cyber-process strong, Protected by design now Thank you, CRA」というテキストが上部に配置されたスライド画像。背景には富士山、赤い太陽、紅葉のイラストが描かれ、中央左寄りには葛飾北斎の「神奈川沖浪裏」をモチーフにゴジラやUFOを加えた「Godzilla Great Wave Wall」のポスター画像が挿入されています。セッション資料より: Cyber-process strong, Protected by design now Thank you, CRA

Open Standards for Data Contracts and Products Are the Backbone of AI

セッション資料: 251208 Taming the Chaos – Open Standards for Data Contracts and Products are the Backbone of AI (9.0.13)

このセッションでは、AI の普及に伴って重要性が増しているデータの品質を、いかにオープンな標準規格を用いて管理していくかというテーマが語られました。

データ契約という新しい概念

このセッションで私が最も大きな衝撃を受けたのは、データ契約(Data Contract)という概念を知ったことです。

これまでのデータ活用では、エンジニアがデータソースから場当たり的にデータを抽出し、分析基盤に流し込むことが一般的でした。
しかし、この方法ではデータ提供側が断りなくスキーマを変更してしまうと、利用側のパイプラインや AI モデルが突然壊れてしまうという問題が頻発します。

データ契約とは、データの構造、品質、利用規約、SLA などをソースコードのように定義し、提供者と利用者の間で交わされる明文化された合意のことです。
Web 開発における API ドキュメントや IDL(インタフェース定義言語)のような役割をデータの世界にも持ち込むという考え方は、ソフトウェアエンジニアとして非常に腑に落ちるものでした。

インターフェースを標準化しようとする動き

「ODCS: Architecture and Content」と題された、Open Data Contract Standard (ODCS) v3.1.0の構成図です。図の中央には「Required(必須)」と「Optional(任意)」に色分けされた12のコンポーネントが配置されており、それらを囲むように上部に「Contributors(提供者)」、下部に「Consumers(利用者)」や「Enterprise-level」のシステムがレイヤー構造で描かれています。セッション資料より: ODCS: Architecture and Content

さらに興味深かったのは、このデータ契約を特定のプラットフォームに依存させず、オープンな標準として定義しようとする活動であるOpen Data Contract Standard (ODCS)が活発に行われているという点です。

セッションでは、PayPal をはじめとする企業が関わっている BITOL (Business Information Transparency Open Layer)などの取り組みが紹介されました。

「Data Product」と題された、データプロダクトの内部構造と外部連携を示すアーキテクチャ図です。セッション資料より: Data Product

「データは単なる副産物ではなく、製品(Data Product)として扱うべきである」という主張、そしてその製品仕様を標準化されたインターフェースで公開するというアプローチは、AI 時代のデータ基盤において背骨となる重要な考え方だと感じました。

データエンジニアリングと聞くと、これまではどこか自分たちのアプリケーション開発とは切り離された領域のように感じていました。
しかし、データ契約というインターフェースを介して双方がコミュニケーションをとる世界観は、普段私たちがマイクロサービスの間で API を定義して開発しているスタイルそのものです。

「良い AI は良いデータからしか生まれない」という当たり前の事実を、根性論ではなく「標準化と契約」というエンジニアリングの手法で解決しようとするオープンソースコミュニティの力強さを感じたセッションでした。

参考資料

おわりに

OSS Summit Japan 2025 は、普段なかなか目に付かないオープンソースの世界に触れられる貴重な機会でした。
全体を通して、オープンソースコミュニティが直面している課題(特に法整備や企業との連携)について、深く考えさせられました。

印象に残ったセッションでは取り上げませんでしたが、 Living With Legacy: How Bosch Built an OSPO and How You Can… Nikola Babadzhanov & Marcel Kurzmann で話された「コミュニティとは、1 人ではなく少なくとも 2 人で構成される」という言葉も、当然のことですが改めて心に響きました。

これまではコミュニティに属することが少なかったため、今後は積極的に参加していきたいです。

より良いチームワークを生み出す

チームの創造力を高めるコラボレーションツール

製品をみる