はじめに
こんにちは、SRE部 検索基盤SREブロックの花房です。2025年12月8日〜10日の3日間、東京の虎ノ門ヒルズで開催された「Open Source Summit Japan 2025」に参加しました。
オープンソースの技術とコミュニティをテーマとする本カンファレンスでは、AI・Cloud Native・Observability・Automotive Linuxといったトレンド技術や、コミュニティ運営に関連するリーダーシップ・組織論など、多岐にわたる領域の発表がありました。また、カンファレンスの中ではLinuxとGitの生みの親であるLinus Torvalds氏のインタビュー形式の基調講演があり、それを間近で聴けたことはエンジニアとして忘れられない貴重な体験になりました。
本記事では、カンファレンスの参加レポートを会場の様子や印象に残ったセッションを交えてお届けします。
目次
Open Source Summit Japanとは
Open Source Summit Japanは、オープンソースをテーマとする国際カンファレンスです。オープンソースに関わるメンテナ・コントリビュータ・開発者・運用担当者が参加し、最新の技術動向やベストプラクティス、実践的なソリューションをお互いに共有します。また、技術面だけでなく、オープンソース技術を社会やビジネスにどのように役立てていくかも議論されます。そのため、コミュニティリーダーやビジネスリーダーにより、オープンソース活用における成功事例や推進方法も共有されます。
本カンファレンスはLinux Foundationが主催しており、日本だけでなく海外でも開催されています。スポンサーにはオープンソースを活用する企業が名を連ねており、今年は以下の企業がスポンサーとして参加していました。
以上のように、役割を超えて多くの参加者・スポンサーが集まり、オープンソースに関する知見共有やネットワーキングが行われる場となっています。
特徴
本カンファレンスの特徴はセッショントラックの多さです。
オープンソースに関連する分野や技術領域は多岐にわたるため、今回は以下の8トラックに細分化してセッションが開催されました。
- Automotive Linux Summit
- Cloud & Containers
- Linux
- Open Source Leadership
- Operations Management
- OSPOCon
- Safety-Critical Software
- Zephyr
さらに、本カンファレンスに留まらず、それぞれの技術領域に特化した以下の関連イベントも同時開催されました。
- Cloud Native Community Japan
- OpenSearchCon Japan 2025
- Rust Global: Tokyo
- Zephyr Project Meetup
OpenSearchCon Japan 2025の参加レポートは以下で公開しています。
来年も東京での開催が予定されていますが、上記のように扱われるトピックの範囲が非常に広いため、参加する場合は事前に興味のあるトピックやセッションを絞り込んでおくことをおすすめします。当日、どのセッションに参加するかを決めるのは大変だと感じました。
会場の様子
本カンファレンスは、2025年12月8日〜10日の3日間、東京の虎ノ門ヒルズフォーラムで開催されました。
基調講演を含む各セッションは、5階のメインホール、5階の2部屋、4階の4部屋の計7部屋で行われました。各部屋ではリアルタイム翻訳を利用でき、英語が苦手な方でも参加しやすい環境が整っていたと思います。
受付とSolutions Showcaseエリアは5階にありました。Solutions Showcaseエリアでは休憩時やランチタイムに食事が配布され、時間帯によっては非常に混雑するため注意が必要です。
セッションレポート
特に印象に残ったセッションを紹介します。
Securing the Invisible Hands: Policy and Guardrails for AI-Driven Infrastructure
本セッションでは、人間の介入なしでAIエージェントにインフラを管理させる場合のセキュリティ確保の方法について、具体的なアーキテクチャとオープンソースツールの紹介を交えて解説されました。
AIエージェントは、プロビジョニングからスケーリングに至るまでインフラの管理も担えるようになってきています。しかし、現状の課題として人間による変更のレビューが必須になってしまい、AIエージェントに全てを任せることはできません。AIは想定外の挙動をしたり、人間と同様に設定ミスを作り出したりしてしまうことがあるためです。また、攻撃者によりAIエージェントが操作され、脆弱性を埋め込むなど悪意のある行動を取らされる可能性もあります。
AIエージェントは有用ですが人間が常に動作をチェックする必要があるため、そこがボトルネックになってしまいます。また、人間の介入がないと不正な設定や悪意のある行動の影響が瞬時に拡散し、抑えられなくなってしまいます。さらに、AIの変更スピードにリアルタイムで対応するようなモニターやポリシーがないために、異変に気付くことが遅れる、もしくは気付けないという問題も発生します。
上記の課題に対する解決策は以下の2つです。
- セキュリティポリシーの宣言的定義と適用
- リアルタイム監視とワークロードの隔離
1つ目の解決策では、ポリシーをコードとして管理し、専用ツールによって常にインフラで有効な状態にしておきます。ツールは、Kubernetesリソースに対してはKyvernoやOPA、クラウドリソースに対してはCrossplaneが存在します。以下の図のように役割が分かれます。
Kyvernoでは、新規リソースの内容がコード管理されたポリシーに従っているかを判定し、不正なリソースが作成されることを未然に防ぎます。Crossplaneでは作成後のリソースのポリシー違反を検知した場合、ポリシーに従うように自動修正する機能が存在します。これらの機能により、AIにより生成された不正な設定がそのまま適用されることを自動的に防ぎます。
2つ目の解決策では、ワークロードの不審なアクションをリアルタイムで検知し、即座にネットワーク的に隔離することで被害の拡散を防ぎます。例えば、Falcoがワークロードの不審なアクションを検知した際、IstioやNetwork Policiesを利用してワークロード自体や侵害されたサービスを即座に隔離します。これにより、悪意のある行動やAIにより生成された脆弱性の拡散を自動的かつ迅速に防ぎます。
本セッションで紹介されたアーキテクチャとツールは、AIエージェントが自律的かつ安全にインフラを管理できる環境を実現していました。以下が全体像を図にしたものです。
Crossplane, Kyverno, Falco, Istioといったツールはオープンソースという点ですぐに導入できます。そのため、AIネイティブで安全なインフラを実現するためのハードルは高くないと感じました。また、本セッションの内容は、AIエージェントだけでなく人間によるインフラ変更にも有効だと考えます。AIほどのスピードは出せませんが、不正な設定や悪意のある行動は人間にも起こり得るためです。
本セッションで紹介されたアーキテクチャは、AI時代のインフラ管理の最先端であり、今後のスタンダードになっていくであろうと感じました。
Scaling GitHub Actions To the CNCF
本セッションでは、CNCF (Cloud Native Computing Foundation)におけるGitHub Actions Self-hosted Runnerの導入事例について紹介されました。
CNCFに所属するオープンソースプロジェクトは230を超えており、そのほとんどがソースコード管理とCIのプラットフォームとしてGitHubを利用しています。CIワークロードに関しては、CNCFのGitHub Enterpriseアカウントに集約しており、共通のインフラを利用しているような状態でした。そのような中で、GitHubから無料提供されていた「Large Runner」が2025年6月から有償化されるというアナウンスが、1年前である2024年6月にありました。有償化されるとCIの費用の全てがCNCFのアカウントにかかります。そこで、CI用のインフラをCNCFが所有しているオンプレ環境であるEquinix Metalに移行する話もあったようですが、Equinix Metalはサービス終了予定になったため行き場がなくなってしまいました。そのため、CNCFではCIを支えるインフラの新規構築が急務となりました。
CNCFは検討の結果、Kubernetes上でGitHub Actions Self-hosted Runnerを運用する方法を採用しました。ツールとしては、Action Runner Controller (ARC)を利用しています。ARCはオープンソースのKubernetes Operatorで、その名の通りGitHub ActionsのSelf-hosted Runnerを運用管理してくれます。さらに、Argo CDを用いたGitOpsによりARCやKubernetesクラスタを管理しています。これにより、オープンソースプロジェクトのメンテナー自身が各々のSelf-hosted Runner環境をアップデートできる仕組みが整備されました。
ARCの導入後、新たな問題が発生しました。ARCはコンテナ環境でCIワークロードを実行しますが、オープンソースプロジェクトによってはコンテナでは動作しない、マシンレベルの仮想化や低レイヤーのネットワーク設定が必要なワークロードも存在しました。既存のARCはコンテナ環境を前提としていたため、CNCFではVM環境でCIワークロードを実行できるような仕組みを追加しました。さらに、CIワークロードで利用するための独自のVMイメージを構築するツールも開発しています。
最終的に以下の図のような構成になりました。
CNCFでは、ARCや独自のCIワークロード用VMを活用してGitHub Actions Self-hosted Runnerを運用しています。ARCとArgo CDを組み合わせることでスケール性とメンテナンス性を両立し、各プロジェクトのメンテナーも使いやすいプラットフォームを構築していることが参考にすべき姿だと感じました。また、独自のVMイメージを構築するツールはオープンソースで公開されているため、ぜひ試してみたいと思いました。このようにオープンソースで公開しているとユーザに気軽に試してもらえるため、自分で作成したツールも、たとえニッチなものであってもオープンソースとして公開していきたいと思いました。
You Never Know When You Need a Fork: Lessons Learned Building Valkey
本セッションでは、Redisをフォークして「Valkey」を立ち上げた際に実施した内容について紹介されました。
Redisのライセンス変更に伴いValkeyが誕生した当時、Redisの運営体制は不透明でクローズドでした。デプロイは独自の環境かつRedis Inc.だけが実施可能であり、ベンチマークテストも同様のクローズドな独自システムで行われていました。会議や意思決定もクローズドな場で行われ、コミュニティの活動は活発になりにくい状況でした。
そこで、Valkeyはフォーク前までのコミュニティの形は残し、全ての開発プロセスをオープンにするという運営体制を築きました。さらに、3つの工夫によりオープンであることの維持と継続的なリリースを実現しました。
- ブランチとタグの保護ルールの有効化: リリースの際には必ずPRをオープンして変更を誰かにチェックされるという文化を作り出す
- ドキュメントのバージョン管理と更新の自動化: リリースやコントリビューションの方法、セキュリティに関する情報が常に最新の状態で公開される
- Valkeyのパッケージ提供先とビルドスクリプトのメンテナンス: Valkeyが各パッケージとして問題なく再配布されるようにすることで、Valkeyに触れる人が増え、コミュニティの発展に繋がる
Valkeyのメンテナがコミュニティを非常に大事にしていることから、大規模なオープンソースはコミュニティなしで成り立たないことを改めて実感しました。また、コミュニティに還元するにはリリースを継続的に続ける必要があり、そのためにはコミュニティをオープンにして誰もがプロジェクトに参加しやすく、活発にし続けることが重要だと感じました。
Panel: OSPOjp: Ways To Level up OSPO Stages With Knowledge and Strategies From Local Meetup Japan
本セッションは、日本におけるOSPO (Open Source Program Office) 活動のナレッジと戦略を共有することを目的として開催されました。
企業でOSS貢献に取り組む際、推奨されているため貢献を始めるものの、他の取り組みよりも優先度を下げてしまい続かないことは多々あると思います。OSS活動の課題として、組織のOSS戦略が欠如していると、メンバーが貢献の価値を証明できずOSS活動を縮小してしまう「OSSの落とし穴ループ」に陥ることがあります。
解決策の1つは、組織内にOSPOを設置し、成熟度モデルに基づいて組織の意識を「利用のリスク管理」から「貢献の価値創出」へとシフトさせることです。OSPOとは、組織のオープンソース運用の中核を担う専門部署です。具体的な活動としては、オープンソース活用の戦略やポリシーを作成し適用すること、オープンソースに関するトレーニング、外部のオープンソースコミュニティとの関係構築などが挙げられます。
以下の図ではOSSおよびOSSコミュニティ活動のメリットを成熟度ごとに示しています。成熟度が上がると、そのメリットが組織内に留まらずエコシステムへとより範囲が広くなります。
以下の図ではOSSに対するマインドセットを成熟度ごとに示しています。成熟度が上がると、組織のマインドセットはOSSのリスクから価値創出へと変化します。
以下の図では組織内でのOSPOの役割を成熟度ごとに示しています。成熟度が上がると、ルール整備や教育から組織内外の関係構築や戦略的な意思決定のサポートへと変化します。
OSPOの在り方は組織によって様々で正解はありませんが、以上が既存のナレッジから構築された成熟度モデルでした。「OSSの落とし穴ループ」を脱するために参考となるモデルです。
本セッションを通して、OSPOとは何か、その役割と価値について知ることができました。パネルディスカッション形式で、日本でOSPOを実践している方々の話を伺うこともでき、非常に貴重で学びになる時間でした。今後、自身のオープンソース活動を展開していく上で本セッションの内容を活かしていきたいと思います。
おわりに
本記事では、「Open Source Summit Japan 2025」の参加レポートをお届けしました。
3日間、オープンソースの世界に没頭し、刺激を受け続けた貴重な機会になりました。技術の最前線に触れられるだけでなく、コミュニティ運営やビジネスでの活用方法など多角的な知見を得ることができ、非常に有意義だったと感じています。また、長期的に「どのようにオープンソースと関わっていくか」を考えるきっかけにもなりました。今後は、オープンソースの戦略的な活用に加え、コミュニティへの還元・貢献の頻度を増やしていきたいと考えています。
ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからご応募ください。
