AIワークフォース事業部SREの現状と将来展望
LayerXのAi Workforce事業部SREチームは、1人体制から3名の多様なスキルを持つスクラムチームに成長し、顧客向けデリバリー、トイル撲滅、オブザーバビリティ導入に取り組みながら、生成AI特有の課題や大規模SaaS基盤の安定性に焦点を当てたサイト信頼性エンジニアリングを実践している。
キーポイント
SREチームの成長とスクラム化
1人体制からバックグラウンドの異なる3名のチームに成長し、多様なスキルを活かして業務を遂行している。業務範囲の拡大に伴い、スプリントを切るスクラム方式で課題に対応している。
現在の主要な取り組み
新規顧客向け環境の企画・構築といった「お客様向けデリバリー」、手作業の自動化などの「トイル撲滅」、そして「オブザーバビリティ導入」の3つを重点的に推進している。
生成AI特有の課題への対応
LLMモデルのトークン制限、クォータ管理、モデル切り替え戦略など、生成AIプロバイダーに依存する制約への対処が重要な課題として挙げられている。
バクラク事業部SREとの共通点と相違点
両組織とも「Bet AI」の実践、クラウドネイティブな技術選定、事業貢献への意識を共通点とする。相違点は、Ai Workforce SREがプロダクト部内に組み込まれた「Embedded SRE」であるのに対し、バクラクSREは横断的な「Platform SRE」である点などにある。
影響分析・編集コメントを表示
影響分析
この記事は、生成AIを中核とするSaaSプロダクトの信頼性を支えるSREの現場の生の声と具体的な課題を伝えており、同様の領域でSREを構築・運営する他企業やチームにとって貴重な実践的知見を提供する。また、AIサービスの普及に伴い、その基盤を支えるSREの役割と専門性の重要性が高まっていることを示唆している。
編集コメント
生成AIサービスを実際に運用するSREチームの内部事情と、技術的・組織的課題を率直に語った貴重なケーススタディ。技術選定のニュートラリティや多様性の重要性といった普遍的な教訓も含まれている。
こんにちは。LayerX Ai Workforce 事業部で SRE（Site Reliability Engineering：サイト信頼性エンジニアリング）をしています@shinyorke（しんよーく）と申します。
最近入社 1 年を迎えました。社内外の皆様の応援とフォローのおかげです、いつもありがとうございます。
1 年前は「事業部 1 人目の SRE」として、プロダクトや事業部のキャッチアップ、採用といった所に奔走していました（詳細はこちらのブログを参照）。
そして現在は新たに Join した SRE メンバーとともにサイト信頼性エンジニアリングの実現に奔走しています。
現在の Ai Workforce SRE チームの紹介
今後どうしていきたいか（どういう SRE と働きたいか）
以上 2 つのテーマでお送りいたします。
Ai Workforce の SRE はチームとして奔走しています、Embedded SRE として楽しみたい方の Join お待ちしております！
現在の SRE チーム SRE のスクラムチーム化
バクラク事業部 SRE との共通点と違い 共通点
最初に現在の SRE チームの紹介をさせてください。
1 人チームを卒業し、スクラムなチームになりました。
「お客様向けデリバリー」「トイル撲滅（Toil Elimination：手作業による負担の排除）」「オブザーバビリティ（Observability：システムの状態を可視化する能力）」頑張っています。
バクラク事業部 SRE との共通点と違い。
以上のテーマで今を紹介します。
2026 年 1 月現在の Ai Workforce 事業部の SRE ですが、3 名のチームで運営しています。
私を含めたチームメンバー全員、バックグラウンド・強みそして個性が異なる多様性があるチームが出来上がりました。
SRE 以外の領域、ざっくり言えばソフトウェアエンジニアリング全般でフルスタックにスキルと経験あり。
SaaS（Software as a Service：ソフトウェアをサービスとして提供する形態）・自社プロダクトの SRE としての経験はもちろん、お客様へのデリバリーと運用、大規模システムに対する知見と経験を持っている。
推しの AI、推しのクラウドサービス etc..それぞれの推しや強みの相乗効果で技術的・ビジネス的な難問がすぐ解ける（かつ楽しい）。
それぞれの強みを活かし、SWE（Software Engineer：ソフトウェアエンジニア）やビジネスチームからの相談・トラブル対処も組んで数カ月のチームとは思えないほどいい感じに解決できる状態ができ、毎日エンジョイできています。
それぞれ推しのサービス等あるものの、「技術選定においてはニュートラルであることを前提にゼロベースで議論し、施策を回す」プロフェッショナルが揃っています。
また、チーム運営が徐々にスクラム化してきました。
通常の SRE 業務のみならず、お客様向けの対応（中にはお客様との直接折衝含む）など業務が多岐に渡る。
二桁の数の環境があり、保守運用および改善タスクも多数あり。
Ai Workforce の正式リリースから 1 年半というタイミングもあり AI モデルの刷新といったプロジェクトも存在。
上記の文脈において SRE も解くべきタスクが増加しており、スプリントを切ってスクラム的に対応しようという流れになりました。
大変ありがたい事に、複数のお客様とのプロジェクトがあるため、
新規のお客様に対する環境の企画・構築
といった「お客様向けデリバリー」が佳境となっております。
また、「手作業の自動化」「デプロイの改善、完全自動化」といった SRE おなじみの「トイル撲滅（Toil Elimination：手作業による負担の排除）」対応もあります。
SRE チームが本格的に立ち上がり（かつ Tech PM の Joe さんの助けもあり、詳しくはこちら）オブザーバビリティ導入も積極的に進めています。
眼の前の課題のみならず、将来投資も含めてやりたいことが盛り沢山といった状況であります。
バクラク事業部 SRE との共通点と違い
この章の最後として、カジュアル面談などでよく聞かれる質問であるこちらについて。
Ai Workforce 事業部の SRE とバクラク事業部の SRE の違いはなんですか？
こちらについて現在の状況も踏まえたうえでお答えします。
共通点と違いを絵にすると以下の通りです（Notebook LM での出力です&出典：Bakuraku Engineering Team Deck、ゼロから始める SRE の事業貢献 を元に事実かどうかを確認後掲載しています）。
Ai Workforce 事業部とバクラク事業部の SRE まとめ（Notebook LM）
共通点は以下のとおりです。事業部は異なれど「Bet AI」「クラウドネイティブ」「事業貢献」の軸は変わりません。
「Bet AI」のカルチャーと実践：どちらの組織も全社的な行動指針である「Bet AI」に基づき、SRE 業務自体に生成 AI を積極的に活用しており、それぞれの事業部で SRE を活用した営みをしています。
クラウドネイティブな技術選定：どちらもクラウド技術（AWS や Azure など）を前提としたアーキテクチャ設計・運用を行っており、トイル（手作業）の削減や IaC（Infrastructure as Code）の積極導入・運用を行っています。
事業貢献への意識：技術的な信頼性だけでなく、Biz（ビジネスサイド）と連携し、事業成長に貢献することにフルコミットしています。
事業部毎の違いは「組織」「課題感」「技術的な焦点」「対外的な役割」で解説します。
Ai Workforce 事業部 SRE
Embedded (組み込み型) の SRE 組織。プロダクト部内の開発グループに所属し、Ai Workforce 専任の SRE としてサイト信頼性エンジニアリングに寄与する。
Platform / Cross-Product (横断型)SRE。バクラクシリーズを横断的に支える基盤組織に所属。Enabling SRE として各チームを支援する体制がある。
Ai Workforce のサイト信頼性エンジニアリング、顧客への導入推進（デリバリー）および、SRE 組織自体の立ち上げ・文化醸成が主要なタスク。
15,000 社を超える顧客規模とデータ量に耐えうるインフラの進化、マイクロサービス間の連携や開発プロセスの最適化が課題。
生成 AI 特有のアーキテクチャ課題への対処。LLM Model のトークン制限、クォータ管理、モデルの切り替え戦略など、生成 AI プロバイダー（Azure OpenAI 等）に依存する制約への対処が重要。
マイクロサービスと共通基盤。多数のマイクロサービスを GraphQL Gateway で統合するアーキテクチャや、マルチテナント DB の負荷対策など、大規模 SaaS 基盤の安定性が焦点。
Client Facing (顧客対面)。エンタープライズ企業への導入において、技術要件の説明や合意形成など、顧客と直接対話する役割（PMO 的動き）が求められている*1。
Developer Experience（開発者体験）。「爆速開発」を支えるため、CI/CD や QA プロセスの最適化など、社内の開発者が効率よく開発できる環境整備に重きが置かれている。
組織上、Embedded と Platform / Cross-Product という組織体系の違いは明確にあります。
また、技術の違い（余談ですが LayerX のエンジニア組織は事業部ごとに存在し、技術選定も大きく異なります）による課題感や焦点、役割に明確に差があります。
なお、余談ですがお互いの SRE チーム同士での交流はあり、非公式ながら「SRE ギルド」として仲良く活動させてもらっています。
tech.layerx.co.jp
今年も各種イベント等で一緒にやっていくのでよろしくお願いします！
本ブログでは、「Ai Workforce 事業部 SRE の今ってどうなっているの？」というテーマで、
1 人チームを卒業し、スクラムなチームになりました。
「お客様向けデリバリー」「トイル撲滅」「オブザーバビリティ」頑張っています。
バクラク事業部 SRE とは組織と向き合う課題が異なりつつも仲良くやっています。
というお話を紹介させていただきました。
もう一つのテーマである「Ai Workforce 事業部 SRE のこれから」ですが、
更に踏み込んだオブザーバビリティの導入と改善。
SRE としてのトイル撲滅および改善。自動化されていない箇所があったり、ビジネスに合わせて CI/CD パイプラインの改善等の課題があります。
生成 AI 時代の進化と深化に追いつけ追い越せ、でアーキテクチャの改善や刷新を進める事もあります。
進行中・企画中のものもあり、このブログの中では残念ながらお伝えできない事もありますので興味を持たれた方はぜひ Open Door でざっくばらんに話したりしましょう。
jobs.layerx.co.jp
また、仲間も募集しておりますのでどうぞよろしくお願いいたします。
open.talentio.com
最後までお読みいただきありがとうございました。
*1:これらの専任 Role として Tech PM（Technical Project Manager）および PMO も存在しますが、主に運用フェーズにおいて SRE もこの役割を担っています。
原文を表示
こんにちは。LayerX Ai Workforce事業部でSREをしています@shinyorke（しんよーく）と申します。
最近入社1年を迎えました。社内外の皆様の応援とフォローのおかげです、いつもありがとうございます。
1年前は「事業部1人目のSRE」として、プロダクトや事業部のキャッチアップ、採用といった所に奔走していました（詳細はこちらのブログを参照）。
そして現在は新たにJoinしたSREメンバーとともにサイト信頼性エンジニアリングの実現に奔走しています。
現在のAi Workforce SREチームの紹介
今後どうしていきたいか（どういうSREと働きたいか）
以上2つのテーマでお送りいたします。
Ai WorkforceのSREはチームとして奔走しています、Embedded SREとして楽しみたい方のJoinお待ちしております！
現在のSREチーム SREのスクラムチーム化
バクラク事業部SREとの共通点と違い 共通点
最初に現在のSREチームの紹介をさせてください。
1人チームを卒業し、スクラムなチームになりました。
「お客様向けデリバリー」「トイル撲滅」「オブザーバビリティ」頑張っています。
バクラク事業部SREとの共通点と違い。
以上のテーマで今を紹介します。
2026年1月現在のAi Workforce事業部のSREですが、3名のチームで運営しています。
私を含めたチームメンバー全員、バックグラウンド・強みそして個性が異なる多様性があるチームが出来上がりました。
SRE以外の領域、ざっくり言えばソフトウェアエンジニアリング全般でフルスタックにスキルと経験あり。
SaaS・自社プロダクトのSREとしての経験はもちろん、お客様へのデリバリーと運用、大規模システムに対する知見と経験を持っている。
推しのAI、推しのクラウドサービスetc..それぞれの推しや強みの相乗効果で技術的・ビジネス的な難問がすぐ解ける（かつ楽しい）。
それぞれの強みを活かし、SWEやビジネスチームからの相談・トラブル対処も組んで数カ月のチームとは思えないほどいい感じに解決できる状態ができ、毎日エンジョイできています。
それぞれ推しのサービス等あるものの、「技術選定においてはニュートラルであることを前提にゼロベースで議論し、施策を回す」プロフェッショナルが揃っています。
また、チーム運営が徐々にスクラム化してきました。
通常のSRE業務のみならず、お客様向けの対応（中にはお客様との直接折衝含む）など業務が多岐に渡る。
二桁の数の環境があり、保守運用および改善タスクも多数あり。
Ai Workforceの正式リリースから1年半というタイミングもありAIモデルの刷新といったプロジェクトも存在。
上記の文脈においてSREも解くべきタスクが増加しており、スプリントを切ってスクラム的に対応しようという流れになりました。
大変ありがたい事に、複数のお客様とのプロジェクトがあるため、
新規のお客様に対する環境の企画・構築
といった「お客様向けデリバリー」が佳境となっております。
また、「手作業の自動化」「デプロイの改善、完全自動化」といったSREおなじみの「トイル撲滅」対応もあります。
SREチームが本格的に立ち上がり（かつTech PMのjoeさんの助けもあり、詳しくはこちら）オブザーバビリティ導入も積極的に進めています。
眼の前の課題のみならず、将来投資も含めてやりたいことが盛り沢山といった状況であります。
バクラク事業部SREとの共通点と違い
この章の最後として、カジュアル面談などでよく聞かれる質問であるこちらについて。
Ai Workforce事業部のSREとバクラク事業部のSREの違いはなんですか？
こちらについて現在の状況も踏まえたうえでお答えします。
共通点と違いを絵にすると以下の通りです（Notebook LMでの出力です&出典: Bakuraku Engineering Team Deck、ゼロから始めるSREの事業貢献 を元に事実かどうかを確認後掲載しています）。
Ai Workforce事業部とバクラク事業部のSREまとめ（Notebook LM）
共通点は以下のとおりです。事業部は異なれど「Bet AI」「クラウドネイティブ」「事業貢献」の軸は変わりません。
「Bet AI」のカルチャーと実践: どちらの組織も全社的な行動指針である「Bet AI」に基づき、SRE業務自体に生成AIを積極的に活用しており、それぞれの事業部でSREを活用した営みをしています。
クラウドネイティブな技術選定: どちらもクラウド技術（AWSやAzureなど）を前提としたアーキテクチャ設計・運用を行っており、トイル（手作業）の削減やIaC（Infrastructure as Code）の積極導入・運用を行っています。
事業貢献への意識: 技術的な信頼性だけでなく、Biz（ビジネスサイド）と連携し、事業成長に貢献することにフルコミットしています。
事業部毎の違いは「組織」「課題感」「技術的な焦点」「対外的な役割」で解説します。
Ai Workforce事業部SRE
Embedded (組み込み型)のSRE組織。プロダクト部内の開発グループに所属し、Ai Workforce専任のSREとしてサイト信頼性エンジニアリングに寄与する。
Platform / Cross-Product (横断型)SRE。 バクラクシリーズを横断的に支える基盤組織に所属。Enabling SREとして各チームを支援する体制がある。
Ai Workforceのサイト信頼性エンジニアリング、顧客への導入推進（デリバリー）および、SRE組織自体の立ち上げ・文化醸成が主要なタスク。
15,000社を超える顧客規模とデータ量に耐えうるインフラの進化、マイクロサービス間の連携や開発プロセスの最適化が課題。
生成AI特有のアーキテクチャ課題への対処。LLM Modelのトークン制限、クォータ管理、モデルの切り替え戦略など、生成AIプロバイダー（Azure OpenAI等）に依存する制約への対処が重要。
マイクロサービスと共通基盤。多数のマイクロサービスをGraphQL Gatewayで統合するアーキテクチャや、マルチテナントDBの負荷対策など、大規模SaaS基盤の安定性が焦点。
Client Facing (顧客対面)。エンタープライズ企業への導入において、技術要件の説明や合意形成など、顧客と直接対話する役割（PMO的動き）が求められている*1。
Developer Experience (開発者体験)。「爆速開発」を支えるため、CI/CDやQAプロセスの最適化など、社内の開発者が効率よく開発できる環境整備に重きが置かれている。
組織上、EmbeddedとPlatform / Cross-Product という組織体系の違いは明確にあります。
また、技術の違い（余談ですがLayerXのエンジニア組織は事業部ごとに存在し、技術選定も大きく異なります）による課題感や焦点、役割に明確に差があります。
なお、余談ですがお互いのSREチーム同士での交流はあり、非公式ながら「SREギルド」として仲良く活動させてもらっています。
tech.layerx.co.jp
今年も各種イベント等で一緒にやっていくのでよろしくお願いします！
本ブログでは、「Ai Workforce事業部SREの今ってどうなっているの？」というテーマで、
1人チームを卒業し、スクラムなチームになりました。
「お客様向けデリバリー」「トイル撲滅」「オブザーバビリティ」頑張っています。
バクラク事業部SREとは組織と向き合う課題が異なりつつも仲良くやっています。
というお話を紹介させていただきました。
もう一つのテーマである「Ai Workforce事業部SREのこれから」ですが、
更に踏み込んだオブザーバビリティの導入と改善。
SREとしてのトイル撲滅および改善。自動化されていない箇所があったり、ビジネスに合わせてCI/CDパイプラインの改善等の課題があります。
生成AI時代の進化と深化に追いつけ追い越せ、でアーキテクチャの改善や刷新を進める事もあります。
進行中・企画中のものもあり、このブログの中では残念ながらお伝えできない事もありますので興味を持たれた方はぜひOpen Doorでざっくばらんに話したりしましょう。
jobs.layerx.co.jp
また、仲間も募集しておりますのでどうぞよろしくお願いいたします。
open.talentio.com
最後までお読みいただきありがとうございました。
*1:これらの専任RoleとしてTech PM（Technical Project Manager）およびPMOも存在しますが、主に運用フェーズにおいてSREもこの役割を担っています。
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み