セッション一覧

株式会社ispecは、医療機関様向け/医療システムベンダー様向けに、既存の病院システムのクラウド化を推進するプラットフォーム『CloudSail』を開発・提供しています。このプラットフォームでは、自社でセットアップをした小型のサーバーを医療機関様にお配りをし、その上でクラウドと連携をするためのコンテナアプリケーションを動かせるようにすることで、オンプレミスとクラウドのハイブリッドな環境の橋渡しをしています。 本講演では、病院システムというセキュリティやネットワークの要件に制約がある中で、どのような技術を組み合わせてハイブリッド環境における可用性や安定性を維持しているか、についてお話をします。 特に、ハイブリッド環境においてクラウド・ネイティブ技術の活用の実例としてエッジ版kubernetesであるk3sとHelm を活用したアプリケーション実行基盤、OpenTelemetryを用いたオブザーバビリティ・パイプラインについて深掘りをし、クラウド・ネイティブ技術のこれまでになかったユースケースと実運用から見えてきたリアルな課題についてご紹介します。

多数の OSS で構成されているコンテナイメージは、近年急増する脆弱性を狙ったサプライチェーン攻撃の主要な標的となっています。 一方で、イメージスキャンやアラートを導入しても、脆弱性や依存関係の多さから対応が後回しになってしまったり、修正対応が開発者の大きな負荷となっているケースも少なくありません。 このような課題に対し、脆弱性や依存関係を最小化したデフォルトで安全なコンテナイメージ「Hardened Container Images」の採用が注目を集めています。 本セッションでは、Docker が 2025 年 12 月に Apache 2.0 ライセンスのオープンソースとして無償提供を始めた「Docker Hardened Images (DHI)」を一つの実践例として、コンテナイメージにおける脆弱性がなぜ削減しづらいのか、そして Hardened Container Images がどのように「後追いではない」サプライチェーンセキュリティを実現できるのかを解説します。

サービスを継続的に運用するにあたり、定期的な負荷検証はとても大事です。例えばあるリリースで、あるエンドポイントにN+1クエリが含まれてしまった場合、たった数行のコードがサービスダウンを起こしてしまうこともあります。 しかし、継続開発されているサービスは常に新しいコードが生まれ、その新しいコードに対してのシナリオを開発し続けることは容易なことではありません。 上記の課題に対して、AIを用いて課題解決を行い、継続的に負荷検証をできる状態にした事例を共有します。

「クラウドネイティブ＝Kubernetes」という風潮の一方、物理サーバーやVMを運用し続けなければならない環境は数多く存在します。そうした環境では、SSHによる手作業やプッシュ型スクリプトによるデプロイが蔓延し、運用負荷とアタックサーフェス拡大が課題となっています。 本セッションでは、Non-Kubernetes環境で「宣言的」かつ「ゼロダウンタイム」な継続的デプロイを実現するOSS「Dewy」を紹介します。Dewyはプル型アーキテクチャにより各ホストが自律的にレジストリを監視し、Kubernetesのエッセンスを既存サーバー環境にもたらします。 さくらのクラウドでの実用事例として、プル型移行によるアタックサーフェスの最小化、フック機能を活用したDBマイグレーションの自動化、コンテナモードによるランタイム管理の抽象化という課題解決を深掘りします。 Kubernetesを導入せずとも、自律性・宣言的・セキュアというクラウドネイティブの原則を既存インフラへ適用できる、その実践知を共有します。

組み込み製品のアーキテクチャは長らく、ハードウェアとソフトウェアが密結合した姿が一般的でした。しかし、AIの活用や継続的なアップデート要求が高まる現在、その変革が急務となっています。 本講演では、制約の多い産業エッジに「なぜKubernetesが必要なのか？」という背景と現在地を紐解きます。さらに、Linux Foundationで始動した産業エッジの相互運用性を確保する新プロジェクト「Margo」を解説。 「産業エッジ×Kubernetes」がもたらすハードとソフトの分離、そして新たな開発者体験の全貌を語ります。 【対象者】 ・産業エッジ向け組み込み製品のエンジニア ・多数のエッジ機器の統合管理に悩むインフラ担当者 ・OT/IT融合の最新動向を知りたいアーキテクトや技術企画の方 【得られる知見】 ・産業エッジ×Kubernetesの必然性と、エッジ特有の課題に対する現在地 ・新標準「Margo」が目指すベンダーフリーな連携の仕組み ・クラウドのアジリティを組み込みに持ち込む次世代の開発アプローチ

閉域ネットワークなどセキュリティ要件を吸収するエンタープライズのクラウド共通基盤の上で、アプリの開発導線を整えることが私たちのミッションでした。 私たちはCDKカスタムコンストラクトで基盤の制約を吸収しセキュリティ基準も担保。 GitHub Packagesでの組織内配布、GitHub Actions Reusable WorkflowsによるCI/CD共通化により、開発者はアプリを書くだけで済む仕組みを構築しました。 設計で最も苦労したのは疎結合性の設計です。 共通基盤との接続やVPCの扱いなど基盤固有の制約はコンストラクトが吸収し、開発者は意識不要。 それでいて案件固有のカスタマイズにも対応できる柔軟性を維持しました。 TypeScriptの型補完で何が設定できるか一目で分かるだけでなく、ドキュメントやSkills・MCPによるAIコンテキスト配布も整備。 クローン時点でAIがベストプラクティスを理解済みの状態に。環境構築は2〜3週間から約2時間に短縮。 「誰もが躓く部分が取り除かれ、開発に集中できる」という声が届いています。 どのように開発者体験を高めたかを共有します。

スピーカーは現在アーリーステージのB2Bスタートアップに所属し、一人目のSRE・インフラエンジニアとして2年半活動してきました。入社当初の組織は、十数名規模の開発チームで、スケールするインフラ構築やエラー通知の改善など、プロダクト開発を前に進めることが最優先のフェーズでした。 そんな環境でSREという肩書きを持つ自分に求められた役割は、GoogleのSRE本に書かれているような理想像とは異なります。現実には、クラウドインフラの構築や開発環境の整備、監視や通知の整備、セキュリティチェック、場合によっては脆弱性診断のハンドリングまでインフラに直接的に関わらないことも含めてなんでもやる人として取り組むことが必要でした。 本セッションでは、この2年半で自分が取り組んできたことを具体的に紹介しながら、なぜそうしたのか、そこからどんな学びが得られたのかを整理してお話しします。また、アンチパターンとされがちな属人化をあえて戦略的に選んだ場面について、その背景とトレードオフ、AIの活用など共有したいと思います。

ペアーズは日本・韓国・台湾に展開する中で、日本向けと海外向けの二重開発により仕様差分が拡大し、保守面で非常に課題を感じていました。その結果、開発速度と品質の両立が難しくなっていました。 本セッションでは、グローバル展開戦略を推進する1 Application 化を軸にした Re:Architect の戦略と実践知を紹介します。 Applicationやデプロイ基盤は統一する一方、データは国・リージョン単位で分離するといった、データストア、国際化、キャッシュ設計の具体例を通じて、グローバル展開で速度と信頼性を両立するための設計判断と実装のポイントを共有します。

「OSSがあるなら自作するな」——CNCFを中心に成熟したエコシステムがこの常識を支え、多くの現場に恩恵をもたらしてきました。しかし採用したOSSの一部しか使っていなかったり、誰も面倒を見ず負債になったりするケースは少なくありません。さらにingress-nginxの廃止やKubeSphereのOSS版撤退のように、OSSの存続も約束されていません。 それでもOSSに頼るしかありませんでした。しかしAIコーディングが急速に発展し、書いた仕様が動くことが日々現実になっています。私自身も、AIコーディングでKubernetes Operatorをわずか4時間で実環境のテストまで完成させ、実運用に至りました。必要な機能だけをAIで実装し、CLAUDE.mdとSpecを残せば、誰も面倒を見なくなっても次の人がメンテできます。以前は自作がアンチパターンでしたが、今は自作しないことがアンチパターンかもしれません。 ではいつ自作し、いつOSSを使うべきか。本セッションでは「使う機能は何割か」「コミュニティは生きているか」「チームでメンテできるか」の3軸で、現場で使える判断フローと基準を共有します。

docker build したイメージを push したあとにコンテナレジストリの中身を覗いたことはありますか？ 実はあなたが何も設定しなくても「誰が・いつ・どうビルドしたか」を記録する Provenance が自動でイメージに同梱されていて、更にCI に数行足すだけで、SBOM や暗号署名も追加することができます。 これらを活用すれば、本番障害時に「このイメージはどの commit からビルドされたか」を CI ログを遡ることなく即座に特定でき、新たな CVE が公表された際には SBOM で影響するイメージを一括で把握できます。署名があれば「正規の CI を通っていないイメージはデプロイさせない」という運用も実現できます。 本セッションでは、イメージの内部構造の読み方、CI への署名導入手順、レジストリ内のメタデータ確認方法を実演を交えて解説します。 「自分の構築したイメージの安全性を自分の手で確認・強化できるようにしてコンテナイメージの運用をよりセキュアにしたい」という人にオススメです。

Observabilityは本番だけの話ではありません。サンエーでは、開発フェーズからDatadogを組み込み、“作りながら観測する”モダン開発を実践しています。 本セッションでは： • Datadog選定時に重視した技術要件 • Bibeコーディング時にパフォーマンス問題を即検知できた事例 • 小売特有のドメイン設計を反映したタグ戦略 をテーマに、リアルな知見をファイアーサイドチャット形式でお届けします。 SRE、Platform Engineer、アプリケーションエンジニア必見のセッションです。

社内のナレッジマネジメントシステムをクラウドネイティブなコンテナ基盤へ移行した実践事例を公開！ 共有の心理的障壁を下げるリアクション機能や検索性を高めるタグ付け機能、生成AI連携による自動要約機能など、現場が「使いたくなる」工夫を紹介します。 インフラ組織の生産性を変える攻めのシステム刷新の全貌と、グローバルでノウハウを共有できる機能などさらなる発展を見据えた構想を開発の裏側と共にお届けします。

弊社組織では社内共通基盤のプラットフォームを構築しており、100個ほどのマイクロサービスが稼働しています。そしてこれらを200人のエンジニアで日々開発していて、弊社SREは15名でこのマイクロサービスの運用・問い合わせに対応していますが、こうした日々のタスクに追われて本来の目的あるSRE Enablingがなかなか進んでいません。その時間を捻出するため、我々はTry&Errorを繰り返しながら運用にAIを実装してきました。今回はそういった泥臭い実装例をお話したいと思います。 本セッションでは、以下のトピックについてお話します。AI活用に悩まれているSREの方に是非きいていただきたいです！ - Linear x Codex/Devinで全microserviceのTerraform Module updateを効率よく行う - AIによるレビューで200 PR/dayの50%は自動化 - 問い合わせ・トラブルシューティングをAIにやってもらうために必要なskills - Production Readiness Check(PRC)のEvidence確認もAIにやってもらおう

システムの疎結合化や重い処理の負荷分散などの目的で、ジョブキューが用いられます。ここで、素朴にキューサービスの前後のアプリケーションにトレースを計装するだけでは、トレースがキューサービスを跨げず途切れてしまうことがあります。 SLI/SLOの設計では、ユーザ体験に即したものであることが重要視されます。ユーザー目線で期待するレイテンシーで操作が行われているかを知るには、キュー内に滞留している時間も含めEnd-to-endで計測できる状態になっている必要があります。 今回は題材としてAmazon SQSを介した非同期処理・バッチ処理を取り挙げ、一連の処理を観測しやすくするOpenTelemetryトレースの計装方法をご紹介します。 - コンテキスト伝播の仕組み - カスタムプロパゲーターの実装 - トレースのスパンリンクの活用 またこれを発展させ、End-to-endのレイテンシーをメトリックとして計測できるようにする手法も解説します。 ジョブキューやマイクロサービスを含むアーキテクチャにおいて、サービスを跨いだトレーシングやSLI計測に課題があると考える人向けのセッションです。

「PRのに応じて検証環境を柔軟に増やしたりしたいな」「検証環境アクセスまでのリードタイムが開発のボトルネックになる」このようなもどかしい経験を持ったことはないでしょうか？特に我々のように500名超規模の開発体制やAIでのコーディングスピードの上昇によって、結果的に検証環境がボトルネックになると感じることがしばしばあります。この課題を解決するため、PR単位でephemeralな検証環境を払い出す仕組みをArgoCD ApplicationSet とGithub Actions等を活用して構築しました。 構築の中で、開発者が本当に必要としているのか使ってもらえるのかを見極めるためにDBのスキーマ変更やWorkerの検証機能はスコープから外し、それ以外のWebアプリケーション機能だけに絞る意思決定をし、フィードバックを重視した開発を行いました。 本セッションではArgoCD ApplicationSetを活用したApplication生成パターン、PR作成のライフサイクルに連動して作られる検証環境のライフサイクル管理の実装、そして必要なものを作るための取捨選択についてお話しします。

「Cattle, not Pets」はKubernetesアプリ設計の常識ですが、その前提となる高可用性サービスに頼れないステートフルアプリ(Git/P4、CI・開発環境、レガシー等)は多くの組織に残っており、それらをVMから脱却させるにはK8sのReadWriteOnce(RWO) PV+シングルレプリカPodで「飼う」しかないケースがあります。 本講演ではこのトピックを掘り下げた次の内容をお話します。 ・Kompoxの紹介: マルチクラウドK8sアプリ運用ツール https://docs.kompox.dev/edge/ja/ ・K8sの宣言的管理・自動復旧・API駆動インフラを活用したcompose.yml中心のアプリ開発ワークフロー ・HPAやローリングアップデートと無縁なRPO≈0・SLO 99.9%の割り切った可用性設計 ・AKSにおけるRWOのAZ制約・デタッチ・スナップショット挙動の現実 ・CRD/Operator化とPaaS展開構想 K8sの能力をあえて使わないことがステートフルアプリ設計の現実解になり得ることを、汎用的な設計パターンとして持ち帰りいただけます。

Pairsチームでは、本番運用中のGoサービスにおいて、非cgroup-awareなコンテナ挙動に起因するCPUスロットリングの課題に継続的に向き合ってきました。Goランタイム・Linux・Kubernetesそれぞれのスケジューラの関係を踏まえつつ、NginxやHAProxyなど周辺ミドルウェアの特性も含めて検証と改善を重ねた結果、CPUスロットリングを大幅に低減し、コンテナの安定性とパフォーマンス、監視運用の精度を向上させました。 本セッションでは、GOMAXPROCS設定時にHAProxyがボトルネック化して障害が発生した実例、その解消プロセス、監視と設定強化、そしてGo 1.25のContainer-aware GOMAXPROCSを踏まえた安全な運用方針までを、実際の意思決定とトレードオフとともに共有します。 参加者が自環境で活用できるよう、CPUスロットリング関連メトリクスの見方と改善の進め方を具体的に持ち帰れる内容にします。

本セッションでは認証認可サーバー開発をユースケースに、クライアントサーバー間の複雑なリクエスト／レスポンスを再現するモックを実装し統合テストを自動化する、CI/CD実現に向けた取り組みを共有します。 クラウドネイティブな開発プロセスではテストを自動化し、CI/CDパイプラインへ組み込むことが重要です。中でも統合テストでは外部接続を検証するためにモックサーバーを使用するケースがありますが、一般的なオープンソースのモックサーバーはリクエストを受けてレスポンスを返す用途が中心で、モック自身がリクエストを送信するケースは少なく、認証認可のようにサーバー間で複数回の通信が発生するシナリオを十分に再現できないことがあります。 そこで、SpringBootを用いてステートフルな通信を再現し、テスト可能なモックを実装。テストシナリオはOpenAPIライクなYAML形式で定義し、生成AIを活用した高速なテストコード作成とも親和性の高い仕組みを実現しました。 デモンストレーションとして生成AIを用いたテストコード作成から、Dockerでの環境構築とテスト実施まで紹介します。

クラウドネイティブなデータベースへの進化の歴史は、そのまま「分散システムにおける物理制約との戦い」であり、スケーラブルなシステム設計の最高の教科書です。 従来のRDBMSはコンピュートとストレージの密結合が限界を生んでいました。これを打開したAmazon Auroraは、「THE LOG IS THE DATABASE」の思想で分離でスケーラビリティを、 Google SpannerやNewSQLは、TrueTime APIやPaxos/Raftの分散合意アルゴリズムで分散環境の強整合性を獲得し、トレードオフとしてレイテンシーを犠牲にしました。 個別の要素技術や論文は知られていても、「どのような課題を乗り越え、結果としてどのようなトレードオフを選び現在に至ったのか」という全体像は意外にも体系化されていません。 本セッションでは点在する論文や技術仕様を線で繋ぎ合わせ、巨大な分散システムがいかに物理制約を克服してきたかDeep Diveします。「なぜスケールし、何を犠牲にするのか」この理解はDB選定の枠を超え、マイクロサービス等あらゆる分散システム設計の指針となるはずです。

「またコンテナの話、しようか」——2018年に『コンテナ・ベース・オーケストレーション』（翔泳社）を共著してから8年、一人はIBMでObservabilityを、もう一人は雪国でGPUデータセンターを作っていた。2025年に再会した2人は、本物のコンテナ（型データセンター）の中にいた。 新潟県湯沢町のコンテナ型データセンターにNVIDIA H100（空冷）、H200・B200各8基（液冷）を収容し、Rancher K8sでGPUクラスターを構成。地下水（井水）による液冷で業界最高水準のエネルギー効率を目指します。 NVIDIA DCGMとOpenTelemetryを使ってGPUの可視化はInstanaで本番運用稼働中。Schneider Electric in-row冷却のSNMP MIBから風量を取得しGPU温度とOpenTelemetry Collectorで繋ぐことに挑戦中。液冷はPoC準備中。実績と途中経過を正直に共有。DCGM・SNMP×OTelの設計判断と失敗を持ち帰れます。登壇資料は公開予定。 SRE・インフラエンジニア・Platform Engineerを対象。

CloudNative の普及により、Kubernetes をはじめとするコンテナ基盤を本番環境で運用するチームが増えてきました。しかしその一方で、従来の境界防御を前提としたセキュリティ設計はこうした環境ではうまく機能しません。 ワークロードは動的に生成・破棄され、内部通信も信頼できず、どこから守るべきかを判断できない状態に陥りがちです。その結果、対策は増えていくのに設計だけが複雑化していきます。 本セッションでは、SaaS アーキテクチャを例に Kubernetes 環境の脅威モデリングを段階的に実践します。STRIDE フレームワークによる脅威の洗い出し、リスクアセスメントによる対策の優先順位決定、そしてその結果を具体的な設計にどう落とし込むかまでの一連のプロセスを紹介します。

インフラエンジニア、DevOpsエンジニア、SREなど呼び方は様々ですが、サイボウズにも、製品開発が利用する開発環境や、お客様に提供する本番環境の基盤を支えるチームがあります。私たちは、その基盤の、開発、運用、保守、そして信頼性向上に力を注いできました。基盤の安定性や運用には長年の経験がありましたが、組織全体の取り組みや事業インパクトの高い活動に対して、組織として十分に接続できていませんでした。 サイボウズの開発は、2024年から組織全体でよりインパクトの高い活動ができるよう、「アラインメント強化」というテーマを掲げてきました。我々のチームも、従来の受け身な体制から、役割を再定義してより社内利用者や事業への意識を持てるように、「プラットフォームエンジニアリング部」を立ち上げました。 このセッションでは、サイボウズの開発組織とプラットフォームエンジニアリング部の立ち上げについて紹介します。EMの立場から、事業・組織とプラットフォームエンジニアリング部のアラインメントをどのように強化したか、その具体的な取り組みと成果について共有します。

生成AIの活用により、コードやIaCの生成は加速し、変更量は増加しています。しかし変更が増えるほど、信頼性を安定的に維持する難易度も高まります。レビューやチェックリストに基づく確認は人の認知やコミュニケーションに依存しやすく、変更が継続的に増える環境では確認コストの増大やレビューの集中につながり、信頼性リスクが埋もれやすくなります。 本セッションでは、Production Readiness ChecklistやSecurity Checklistなどの組織ポリシーのうち静的に評価可能な項目を抽出し、Policy as CodeとしてCIや実環境に組み込むことで、信頼性を人の認知に過度に依存せず保ち続ける設計と、その実践の現在地を共有します。開発者が常にポリシーを強く意識しなくても、自然と組織ポリシーを満たす状態に近づく構造をどのように設計してきたのか。ConftestやKyvernoを用いた実装例に加え、誤検知との向き合い方、ポリシーの強度設計、既存リソースの是正方針など、形骸化せず機能し続けるガードレールを実現するための工夫を紹介します。

プラットフォームエンジニアリングは、2022年ごろからDevOpsの次のアプローチとして注目を集めてきました。調査では、2026年までに大企業の80%がプラットフォームエンジニアリングの取り組みを開始すると予測されています。しかし実際には、「プラットフォームチームを作ったが誰も使わない」「ツールを導入したが定着しない」といった失敗が後を絶ちません。 失敗の多くは、本質を理解しないまま取り組みを始めてしまうことが原因です。プラットフォームエンジニアリングとは単なるツール導入ではなく、開発者の認知負荷を下げ、組織全体の能力を高める仕組みづくりです。その考え方は、Webサービス企業だけのものではありません。製造業をはじめとする日本全国の企業においても、DXの推進や内製化の加速に不可欠なアプローチとして広がっています。 本セッションでは、プラットフォームエンジニアリングとは何か、なぜ今あらゆる業種・規模の組織に必要なのかを基礎から解説します。小さく始めるための具体的なステップや、AI時代における重要性の変化についてもお話しします。これから取り組みたい方にとって最初の一歩となるセッションです。

Coding Agentの普及により開発速度が向上する一方、Platform側にはAI特有の「予測不能かつ大量の変更」を受容する強力なガードレール設計が求められています。 本セッションでは、データアプリケーション開発向けIDPの実例から、攻め（生産性）と守り（統制）を両立する実践的プラクティスを解説します。 ・Repo,CI/CD: アプリ/基盤層分離と、自律的変更を安全に届けるGitOpsパイプライン ・Test: 欠陥予防（Shift Left）と本番実トラフィックでの検証（Shift Right）の統合 ・Observability: AIによる副作用の早期検知と根本原因特定を担うFull-stack Observability しかしこれだけ強固に実装しても...障害は発生します！Agentもガードレールも銀の弾丸ではありません。実際の障害事例を交え、完璧な統制を盲信するのではなく「Platform as a Product」の思想のもと、Human in the LoopによるAIとの協調やガードレール自体の継続的改善にどう向き合うべきか、リアルな運用知見を共有します。

我々のプロダクトではジムや介護施設などの現場にカメラとエッジデバイスを設置し、AIによる混雑分析や危険検知ソリューションを提供しています。 事業急拡大に伴うデバイス台数の増加に対し、従来のエッジ環境の監視・運用手法では限界が見えていました。 そこで、クラウド環境で活用を検討していたNew Relicをエッジデバイスへと展開しました。 ネットワーク不安定化によるデータ欠損や、デバイス停止といったエッジデバイス特有の課題に対し、監視の徹底による早期検知と自動リカバリの仕組みを段階的に構築しました。 現在は、1,700台を超えるエッジデバイスを安定運用しながら、開発チームが本来の責務である新機能開発に集中できる体制を実現しています。 本講演では、この半年間の試行錯誤の軌跡と、監視強化/運用自動化によってチームの働き方がどう進化したかをお話しします。

「わたしがやっていることは、果たしてSREと呼べることなのだろうか？」 インフラのコード化やサーバーの構築・運用を日々こなしながらも、どこかアプリ開発やプロダクトの信頼性から切り離されているような感覚を、わたしは抱いていました。 そんな折、わたしたちのチームでは、突発的なDBの高負荷をきっかけに、負荷試験・速度改善の取り組みを始めることに。 エンタープライズ向けの監視ツールはありませんでしたが、そこは「あるものでやる。ないものは作る。」 Pythonライブラリの「Locust」でテストを作り、Google Cloud APIを叩く独自のスクリプトを書いてメトリクスとログを抽出する、自前の試験実行・結果確認の仕組みを構築しました。 生成AIの力も借りつつ結果を分析する中で、オブザーバビリティが上がっていき、アプリ開発やプロダクトの信頼性(SRE)との距離も縮まりました。 本セッションでは、負荷試験を通じて「積み上げ式」にオブザーバビリティを構築し、システムの「コンテキスト」をエンジニアリングし続ける、その活動から得られた知見とノウハウを共有します。

「挑戦するエンジニアのプラットフォームをつくる」をビジョンに掲げるファインディでは、2025年以降の急激なプロダクト増加に伴い、Enablingの実践や、複数サービスを横断するログ管理と運用のスケールが急務となりました。 本セッションでは、複数サービス間に散在するログを統一・集約するために実施したアーキテクチャ選定の裏側を公開。AWS OrganizationsとCloudWatch LogsのCentralizationを活用した統制の取れたログ集約設計に加え、CloudWatch Unified Data Managementを用いてAmazon S3 Tablesへログを統合し、Grafanaで可視化するモダンなログ分析基盤の構築について解説します。 「マルチプロダクト環境におけるログ基盤のアーキテクチャをどう設計すべきか」とお悩みの方に、明日からのシステム構築や組織づくりに活かせるヒントをご紹介します。

検出・調査・修復を自動化するAI SREの考え方は、パフォーマンスエンジニアリングにも有効です。AIワークロードは、予測不能なリクエストと巨大な計算コストが直結する推論、パラメータの組み合わせ爆発が性能を支配する学習、いずれも従来のSREの常識が通用しない課題を抱えています。本セッションではこれらの課題を概観した上で、自動プロファイリング・ボトルネック検出・改善・検証のサイクルを自律的に回すパフォーマンスエンジニアリングの実践アプローチをデモを交えて紹介します。

「セキュリティ更新を急いで適用したい。でも、勝手に変えて本番環境を壊したくない。」 エンタープライズのプラットフォーム運用では、「強制アップデート」と「チームの自律」の衝突が避けられません。統制が厳しい環境では影響確認・メンテナンス調整により「変更しづらい／変更できない期間」が発生し、更新の待ち行列が生まれます。これは単なる自動化で解決できる問題ではなく、環境ごとに変更可能タイミングが異なるという構造の問題です。 当社ではAWS Control Tower環境でセキュリティ共通製品をService Catalogで提供しています。当初はフルサービス型で一括更新していましたが、テナント数の増加に伴い待ち行列が膨らみ、改善サイクルも停滞しました。そこで「世代管理と責任分界」を上乗せし、管理アカウントへの強制アップデートとテナントのセルフサービス更新を使い分ける「ハイブリッド運用」に辿り着きました。 本セッションでは、運用モデルの意思決定、更新を回すCI/CDとカタログ運用の仕組み、そして単一世代提供の失敗から得た教訓を共有します。

# 概要 障害訓練やってますか？ やりたいですか？ やりましょう。メリットしかないです。 弊社ではHWを扱ったプロダクトを提供している関係で、障害発生時のトラブルシューティングは困難を極めます。 どれだけ時間をかけて設計しても穴はあります。想定外のことは発生します。 メンバーのスキル差は様々です。いつ何時なにが発生するかわかりません。 物理からクラウド、そして人災まで、あらゆる障害や問題に対処するための訓練を日頃から行っています。 まだまだ試行錯誤の最中ではありますが、おおむね1年以上の運用における現在の整理とこれからについてご紹介します。 # 対象者 ・複数のプロダクト/複数カテゴリにまたがるサービスを提供しているスタートアップのエンジニア ・Opsを意識し出したエンジニア # ざっくり内容 ・ビットキーでなぜ障害訓練が必要であったか / そのキッカケや理由 ・障害訓練とは？ 障害訓練の効能 ・ビットキーにおける障害訓練の運用例 ・便利なツール群 / なぜ我々はそれを使わなかったか

工場IoT管制センターは、デンソー全拠点が使うIoT基盤・アプリ・仮想インフラ・NW（VM払い出し120件/年）を一元運用する組織です。これまで、開発チームが「付加価値のない作業だけでも自動化して渡そう」としてきた結果、Ansible＋GitLab CIやTerraform＋手動SSH Applyと自動/手動のまだら作業が雪だるま式に増え、理解・維持が属人化、増え続ける申請対応に苦しんでいました。 私たちは、若手4名中心のクロスチームで、MVPとして「VM払い出しフローをE2E棚卸し→GitLab CI＋Terraform/Ansibleへ統一」から取組み、手動SSHゼロ化とリードタイム40％短縮の成功を足がかりに、残り50超のアイテムを「開発チームからの依頼を集約・対応する“セルフサービスの運用プラットフォーム”」として開発するロードマップを策定。再び属人化させないため、アジャイル＋ペアプロを“仕事の型”として、スキル移転が自ずと進む開発の進め方を徹底。 半年でMVP本番ローンチ、3か月後には若手自走し、課題形成から技術習得・横展開できるマインドへ転換させたステップを共有します。

様々なAIツールが群雄割拠する昨今、GMOペパボ社内でも Gemini や Claude を始めとする AI ツールが急速に普及しています。講演者も AI エージェントを活用して業務を行っていますが、AI をさらに活用できないかと日々考えています。 昨今、Ambient Agent という概念が知られ始めました。これは「AI が人間の指示を待つことなく自律的に稼働する」という性質のものです。 この Ambient Agent を実現するためのピースを、自作のプラットフォームを構築することにより実現しました。 本講演では、Ambient Agentic Workflow を実現するために必要な要素の分解と、それぞれの要素を実現する手法の提案、さらに手法を実装したプラットフォームの具体的な技術要素と社内へのプラットフォーム普及事例をすべて紹介いたします。 以下のような方々に聞いていただけると幸いです。 - AI エージェント活用による生産性を一段階上げたいと考えている - 全社的なエージェントの普及ができず困っている - 個々人のAI活用レベルに差ができて困っている

「コピペを減らそう」という善意で作り始めたTerraformモジュールが、数ヶ月後には「誰も触りたくない魔境」に変わっていませんか？大量の variable や複雑な count ブロック。私たちは「将来の変更を楽にする」はずが、実際には「実装を理解するための重いコンテキスト」を未来に強いているだけかもしれません。 本セッションでは、魔境化の主因を「テンプレート（共通化）」と「カプセル化（隠蔽）」の混同にあると定義し、以下の設計指針を提示します。 ホワイトボックス・テンプレート（共通化）： 透過性を重視し、クラウド仕様を隠さない設計 ブラックボックス・コンポーネント（隠蔽）： 異なるチームの利用者に「意図」のみを伝える設計 「トポロジーを動的に変えてはいけない」など、明日からチームで使える論理的な設計判断を提供します。 【ターゲット】 - 自作モジュールのメンテに疲弊している方 - dynamic ブロックの乱用に論理的な「待った」をかけたい方

「問い合わせ対応だけじゃなく、信頼性にも関わりたい！」 これはマネーフォワードのCREが直面した切実な思いです。 問い合わせフローの整備や自動化といった日々の「守り」を極める一方で、システム根幹の信頼性を高めていきたいと思うようになりました。 現在はSRE活動を取り入れた「NEXT CRE」へ進化するべく、泥臭い挑戦の真っ只中です。 SLO/CUJの策定やDatadogでの可観測性標準化に加え、注力したのが「パフォーマンスチューニングの民主化」です。 高度な専門性が求められ属人化しがちなボトルネックに対し、AIとRSpecを掛け合わせたアプローチを導入。誰もが容易にパフォーマンス改善に取り組める環境を構築しました。 同時に、AIを活用した問い合わせ対応の効率化も推し進め、SRE活動へ注力するためのリソースを自ら創出しています。 運用中心のチームがゼロからSREに踏み出すとき、何から着手し、どんな壁にぶつかるのか？「今の枠を越えて面白いことがしたい」とくすぶるエンジニアの皆様へ、明日からの実践のヒントになるリアルな軌跡を持ち帰っていただければと思います。

Platform Engineeringの取り組みは増えていますが、実際には小規模な改善活動に留まり、組織全体の変革にまで至らないケースも少なくありません。規模が大きくなるほど、プラットフォームチームは各部署から様々な期待や課題を引き受ける存在となり、スコープが拡散してしまうリスクがあります。本セッションでは、複数のモダナイゼーション支援事例をもとに、Platform Engineeringが組織に飲み込まれる構造を整理します。その上で、プラットフォーム実装、アーキテクチャ戦略、レガシー刷新の責任境界を明確に分離するスコープ設計思想を紹介し、プラットフォームを組織の資産として残すための実践的な方法を共有します。Platform Engineeringをスケールさせたいエンジニア、アーキテクト、技術リーダーにとって、ゴール設計と責任境界を見直すための視点を提供します。

デプロイ時にPodがUnhealthyとなり、一時的にサービスが利用不可となる障害が発生しました。原因はオンラインDDLと長時間SQLの競合によるMySQLメタデータロック待機です。 本セッションでは、障害の再発防止に向けたアプリ側との対話とガードレール構築の取り組みを解説します。 対話では、安全重視のlock_wait_timeoutを提案するSREと、マイグレーションの成功率を重視する開発者の議論を経て、着地点を見出す過程を説明します。また高負荷プロダクトの有識者を交え、リスクの高い変更を判定するための基準を定量化した背景も共有します。 こうした基準を定めても、知見が点在し風化しては再発を防げません。そこで、AIで情報を整理しBackstageへ集約することで、開発者が迷わずにルールを参照できる環境を整えました。さらにGitHub Actionsを活用し、スキーマ変更が検知された際にプルリクエストへ自動で警告を掲示するガードレールを実装しました。 開発者に過度な意識を強いることなく、安全な道へ自然に誘導する開発者体験と信頼性を両立させるための実践的な仕組みを共有します。

マイクロサービスアーキテクチャは各サービスの独立性によりスピーディな開発を可能にします。 しかし現実には、言語ランタイムEoL対応やCVEセキュリティ対応、リリース承認取得などがサービスの数だけ繰り返し発生し、本質的な新規開発の工数を逼迫させることがあります。筆者もクラウドネイティブ開発の支援で、この何度も発生する重たい定型作業によってやりたい開発がしにくくなる状況に何度も直面しもどかしい思いをしてきました。 この課題こそPlatform Engineeringが解決すべき領域です。 「SREで自動化すればいいのでは？」と思うかもしれませんが、SREはエンドユーザー目線で信頼性を担う活動であり、開発者目線で開発体験を向上させるPEの方が効果的なことがあります。 また「PEってk8sありきでしょ？GAFAのような先進的な大企業やイケてるメガベンチャーの話では？」と思われがちですが、k8sがなくても同じ考え方を適用できます。 本セッションでは、「PEは自分たちとは違う世界の話だ」と思っている方にPEをより身近に感じてもらえるよう、今日から始められる初歩的なアプローチや考え方を共有します。

現在hacomonoはアプリ量産によって事業拡大を狙っており、私のチームではKubernetesを利用したGitOpsベースのSelf-service基盤を構築することでアプリ開発支援に挑戦しています。 しかしGitOpsで扱いづらいマネージドサービスの扱いに課題を感じていました。 そこでCrossplaneを採用し、あらゆるリソースをカスタムリソースに抽象化することでGitOpsで完結する基盤を目指しました。 これにより複数のIaCを使って数百行記述する必要のあったリソースが数~数十行のmanifestで扱えるようになりました。 一方、Crossplaneの運用負荷/学習コストが高いことや、抽象化に時間がかかること、抽象化による柔軟性の低下等の新たな課題も感じています。 本セッションではCrossplaneを採用するに至った背景や、実際に運用して感じたメリデメ、抽象化によって得られるものと失うもの等を実体験に基づいて共有します。 Kubernetesとマネージドサービスとの連携に課題を感じている方やCrossplaneの導入を検討している方等に知見を提供します。

我々は必要のないことに時間をかけてないか？と疑問を持ったのは、CSに「解約の原因はエラーレートではなく機能不足です」と言われたときでした。 SREもDevも時間は有限です。Devチーム数がSRE数を超えると、SREが平等にリソースを割くのは難しくなります。 GoogleのProduct-Focused Reliability for SREでは「ビジネスやユーザーにとって最も重要なことに焦点を当て、優先順位を付ける」と提唱しています。精度の高いSLOは優先度を決定でき、それがリソース最適化に寄与します。 この理論に加え、SREとDevが別々のSLOに責任を持つことで同じ目標を共有する組織設計論を話します。組織が大きくなると発生する、受託のような関係を回避しつつ、SREもDevも互いに本番環境に対してバランスを取れる状態が、今後求められる姿です。 本セッションでは、理論について話しつつ ・精度の高いSLOとは ・複数SLOでSREもDevも責任共有する状態とは ・SREが支援係になりすぎないようにするには 3年以上にわたり運用してきたCUJテンプレートと実際のSLO例も共有します。

「夜寝ているとき、アラートで起こされたけど一瞬閾値を越えただけで特に起きる必要はなかった」 「とにかく大量のアラート通知・エラー通知が届いて疲れてしまった」 開発・運用していてこのような経験はありますか？スピーカーはあります。本セッションでは改めて「アラート通知」について考えます。 1.通知の進化を振り返る 何を監視し何を通知するか、進化の系譜について整理します。また、それぞれの監視・通知手法をどう使うかについても触れます。 2.通知、難しい スピーカーが関わっているシステムを例に挙げ、通知の難しさについて整理します。例えば、マルチテナントSaaSにおける通知であったり、多すぎる通知について紹介します。 3.通知を再設計する アラート通知に疲れている聴講者が持ち帰って活用できそうなアクションについて整理します。例えば、通知からログやダッシュボードへの切り替えであったり、通知に含める内容、通知の掃除について紹介します。 現代では「アラート通知」はエンジニアにとって身近であることが多いものだと思います。通知について改めて学ぶことで、自分やチームの負荷を減らし、システムを健康