Site Reliability Engineer（SRE）
Confirmed on the employer's own hiring board on Oct 23, 2026. First seen by Alion on Oct 6, 2026.
Site Reliability Engineer（SRE）
Description
## 信頼性を、運用の頑張りではなく、エンジニアリングで高める。
1年でサービス規模は約3倍になりました。その先に必ず来る壊れ方に、起きる前に手を打つ。繰り返す運用作業はコードに置き換え、障害が起きても原因をすぐに説明できる状態をつくる。
**Bring OutのSREは、AIを活用するプロダクトと開発組織が、速くリリースしながら顧客の信頼を守れるよう、信頼性・Observability・自動化の基盤を設計し、つくるエンジニアです。**
アラートやチケットを処理する役割ではありません。どの信頼性指標を改善し、どの運用作業をなくし、開発者にどんな基盤を提供するのか。それを自分で決め、ソフトウェアで実現していく仕事です。
## なぜ今、このポジションなのか
Bring Outは、商談・社内会議・サービス現場の対話データをAIで解析し、経営判断に使える一次情報に変えるプロダクトを提供しています。エンタープライズ企業を中心に導入が広がり、サービス規模はこの1年で約3倍に成長。SUBARU、日本M&Aセンター、パソナ、NTT西日本など、大手20社以上に利用いただいています。
顧客が預けているのは、社内会議や商談という最も機密性の高いデータです。1社が複数の部門・拠点で使うことが前提のため、顧客が1社増えても負荷は1社分では増えません。可用性とパフォーマンスの毀損は、機能の欠陥以上に信頼を損ないます。
一方で、これまで基盤レイヤーは、組織としてのオーナーシップが明確になっていませんでした。責任の所在が曖昧な領域が生まれ、その制約が機能開発のボトルネックになり、システム原価の改善にも全体を見て手を打つ人がいない状態でした。そこでBring Outは、開発組織を「アプリケーション開発」と「基盤・SRE」の2層に整理し、LLM・課金・対話分析にオーナーシップを持つPlatformチームを新設します。SREはPlatformチームの一員として、LLMを含む基盤全体の信頼性に責任を持ちます。
SREは現在1名が在籍しており、今回の募集で1名を増員し、2名体制にします。
すでに兆候が出ている課題もあります。
- データベースの瞬間的なCPU上昇と、接続数の余裕不足
- ストレージ容量の継続的な増加
- 文字起こし用GPUの調達リスク
- LLMを含むAI処理のレイテンシとコストの増加
「いずれ顕在化する」課題ではなく、すでに見えている課題です。完成した基盤を運用するのではなく、在籍するSREと役割を分担しながら、これからのBring Outの信頼性の土台を設計していただきます。
## お任せしたいこと
まずは、システムの状態を見える化し、守るべき水準を決め、LLMを含む基盤のスケールに先回りすることに集中していただきます。そのうえで、自動化と開発者体験の改善へ領域を広げていきます。
### Observabilityの整備
- 「Monitoring」中心だった運用を、システムの内部状態を説明できる「Observability」へ引き上げる
- ログ・メトリクス・トレースを統合し、障害時に原因を追える状態をつくる
- アラートを見直し、対応が必要なものだけが確実に届く設計にする
「アラートは鳴っているが、何が起きているかは分からない」を終わらせることが、最初のゴールです。
### SLI/SLOの導入
- 可用性・レイテンシ・処理の完了時間など、顧客体験に直結する指標をSLIとして定義する
- 開発チームやビジネスチームと、運用すべき水準をSLOとして合意する
- SLOの状況を、リリースや改善の優先順位を決める判断材料として使える状態にする
数値を決めることより、「この水準で運用する」と組織に納得してもらうプロセスの設計が難所になります。
### キャパシティプランニングとスケーリング
- データベース、ストレージ、文字起こし用GPUの負荷を予測し、増強・調達の計画を立てる
- 特に調達リードタイムのあるGPUについて、需要の予測と発注判断を担う
- データベースのパフォーマンス改善や、接続数・負荷のボトルネック解消を進める
### LLMの運用管理
LLMの運用管理は、SREの担当領域です。プロダクトの中核にあるAI処理を、信頼性とコストの両面から管理します。
- LLM APIや文字起こし処理のレイテンシ、エラー率、レート制限、トークン消費量、コストを可視化し、管理する
- 外部APIの遅延や障害に備えて、リトライ、フォールバック、キューイングを設計・実装する
- モデルやプロバイダの変更を、品質・レイテンシ・コストへの影響を確かめながら安全に進められる仕組みをつくる
- 処理量の増加に対して、品質を保ちながらコストが線形に増えない構成をつくる
### 基盤起因の障害の再発防止
オンコール・インシデント対応のプロセスはTechnical Supportチームが持ちます。SREは、基盤が原因の障害について、技術的な原因究明と再発防止策の実装に責任を持ちます。
- インシデント時に、Technical Supportチームや開発チームと連携して基盤側の調査を担う
- 振り返りで特定した基盤側の課題について、再発防止策を実装まで見届ける
- 調査に必要なダッシュボードやランブックを整え、次の障害で原因に早くたどり着ける状態をつくる
### その先に広げていく領域
基盤の見える化と水準が整い始めたら、次のテーマにも取り組んでいただきます。
- **トイル削減と自動化**：繰り返す運用作業を、コード、セルフサービス、自動修復に置き換える。AIによるアラート要約や調査支援、ランブックの自動化も検証する
- **開発者体験の向上**：IaC、CI/CD、デプロイの仕組みを整え、各チームが自律的に安全にリリース・運用できる基盤を提供する
- **アクセス権限とセキュリティ**：過剰な特権を見直し、一時付与や最小権限、シークレット管理の仕組みを整える
- **コストと非機能要件の意思決定**：システム原価を可視化し、可用性・パフォーマンス・コストのどれをどの順で守るかを決め、その判断を組織に説明する
## 大切にしたい指標
信頼性は、何も起きないことでは測れません。顧客が安心して使い続けられているか、障害から学び、同じ問題を繰り返していないかを重視します。
- **SLO達成率**：定義した水準を、実際に守れているか
- **障害の検知・復旧までの時間**：顧客が気づく前に検知できているか。基盤側の原因特定にどれだけかかっているか
- **原因が分からない障害の比率**：Observabilityが機能しているかの実質的な指標
- **基盤起因の障害の再発率**：再発防止策が実装まで到達しているか
- **システム原価**：処理量や売上の伸びに対して、インフラとAI処理のコストが線形に増えていないか
- **トイルの量**：手作業の運用が、自動化によって減っているか
具体的な目標は、入社後にベースラインを計測したうえで一緒に設定します。
## 向き合う技術
| 領域 | 技術 |
| バックエンド | Node.js / TypeScript / Python / GraphQL |
| データストア | PostgreSQL / AWS S3 / DynamoDB |
| インフラ | AWS / Terraform / Docker / GitHub Actions |
| 可観測性 | Datadog等のObservabilityツール（導入・拡充はこのポジションの担当領域） |
| AI処理 | LLM API、文字起こし用GPU |
すべての技術に最初から精通している必要はありません。本番環境で起きていることを根拠に基づいて説明し、ソフトウェアで改善できることを重視します。
Requirements
## 信頼性を、運用の頑張りではなく、エンジニアリングで高める。
1年でサービス規模は約3倍になりました。その先に必ず来る壊れ方に、起きる前に手を打つ。繰り返す運用作業はコードに置き換え、障害が起きても原因をすぐに説明できる状態をつくる。
**Bring OutのSREは、AIを活用するプロダクトと開発組織が、速くリリースしながら顧客の信頼を守れるよう、信頼性・Observability・自動化の基盤を設計し、つくるエンジニアです。**
アラートやチケットを処理する役割ではありません。どの信頼性指標を改善し、どの運用作業をなくし、開発者にどんな基盤を提供するのか。それを自分で決め、ソフトウェアで実現していく仕事です。
## なぜ今、このポジションなのか
Bring Outは、商談・社内会議・サービス現場の対話データをAIで解析し、経営判断に使える一次情報に変えるプロダクトを提供しています。エンタープライズ企業を中心に導入が広がり、サービス規模はこの1年で約3倍に成長。SUBARU、日本M&Aセンター、パソナ、NTT西日本など、大手20社以上に利用いただいています。
顧客が預けているのは、社内会議や商談という最も機密性の高いデータです。1社が複数の部門・拠点で使うことが前提のため、顧客が1社増えても負荷は1社分では増えません。可用性とパフォーマンスの毀損は、機能の欠陥以上に信頼を損ないます。
一方で、これまで基盤レイヤーは、組織としてのオーナーシップが明確になっていませんでした。責任の所在が曖昧な領域が生まれ、その制約が機能開発のボトルネックになり、システム原価の改善にも全体を見て手を打つ人がいない状態でした。そこでBring Outは、開発組織を「アプリケーション開発」と「基盤・SRE」の2層に整理し、LLM・課金・対話分析にオーナーシップを持つPlatformチームを新設します。SREはPlatformチームの一員として、LLMを含む基盤全体の信頼性に責任を持ちます。
SREは現在1名が在籍しており、今回の募集で1名を増員し、2名体制にします。
すでに兆候が出ている課題もあります。
- データベースの瞬間的なCPU上昇と、接続数の余裕不足
- ストレージ容量の継続的な増加
- 文字起こし用GPUの調達リスク
- LLMを含むAI処理のレイテンシとコストの増加
「いずれ顕在化する」課題ではなく、すでに見えている課題です。完成した基盤を運用するのではなく、在籍するSREと役割を分担しながら、これからのBring Outの信頼性の土台を設計していただきます。
## お任せしたいこと
まずは、システムの状態を見える化し、守るべき水準を決め、LLMを含む基盤のスケールに先回りすることに集中していただきます。そのうえで、自動化と開発者体験の改善へ領域を広げていきます。
### Observabilityの整備
- 「Monitoring」中心だった運用を、システムの内部状態を説明できる「Observability」へ引き上げる
- ログ・メトリクス・トレースを統合し、障害時に原因を追える状態をつくる
- アラートを見直し、対応が必要なものだけが確実に届く設計にする
「アラートは鳴っているが、何が起きているかは分からない」を終わらせることが、最初のゴールです。
### SLI/SLOの導入
- 可用性・レイテンシ・処理の完了時間など、顧客体験に直結する指標をSLIとして定義する
- 開発チームやビジネスチームと、運用すべき水準をSLOとして合意する
- SLOの状況を、リリースや改善の優先順位を決める判断材料として使える状態にする
数値を決めることより、「この水準で運用する」と組織に納得してもらうプロセスの設計が難所になります。
### キャパシティプランニングとスケーリング
- データベース、ストレージ、文字起こし用GPUの負荷を予測し、増強・調達の計画を立てる
- 特に調達リードタイムのあるGPUについて、需要の予測と発注判断を担う
- データベースのパフォーマンス改善や、接続数・負荷のボトルネック解消を進める
### LLMの運用管理
LLMの運用管理は、SREの担当領域です。プロダクトの中核にあるAI処理を、信頼性とコストの両面から管理します。
- LLM APIや文字起こし処理のレイテンシ、エラー率、レート制限、トークン消費量、コストを可視化し、管理する
- 外部APIの遅延や障害に備えて、リトライ、フォールバック、キューイングを設計・実装する
- モデルやプロバイダの変更を、品質・レイテンシ・コストへの影響を確かめながら安全に進められる仕組みをつくる
- 処理量の増加に対して、品質を保ちながらコストが線形に増えない構成をつくる
### 基盤起因の障害の再発防止
オンコール・インシデント対応のプロセスはTechnical Supportチームが持ちます。SREは、基盤が原因の障害について、技術的な原因究明と再発防止策の実装に責任を持ちます。
- インシデント時に、Technical Supportチームや開発チームと連携して基盤側の調査を担う
- 振り返りで特定した基盤側の課題について、再発防止策を実装まで見届ける
- 調査に必要なダッシュボードやランブックを整え、次の障害で原因に早くたどり着ける状態をつくる
### その先に広げていく領域
基盤の見える化と水準が整い始めたら、次のテーマにも取り組んでいただきます。
- **トイル削減と自動化**：繰り返す運用作業を、コード、セルフサービス、自動修復に置き換える。AIによるアラート要約や調査支援、ランブックの自動化も検証する
- **開発者体験の向上**：IaC、CI/CD、デプロイの仕組みを整え、各チームが自律的に安全にリリース・運用できる基盤を提供する
- **アクセス権限とセキュリティ**：過剰な特権を見直し、一時付与や最小権限、シークレット管理の仕組みを整える
- **コストと非機能要件の意思決定**：システム原価を可視化し、可用性・パフォーマンス・コストのどれをどの順で守るかを決め、その判断を組織に説明する
## 大切にしたい指標
信頼性は、何も起きないことでは測れません。顧客が安心して使い続けられているか、障害から学び、同じ問題を繰り返していないかを重視します。
- **SLO達成率**：定義した水準を、実際に守れているか
- **障害の検知・復旧までの時間**：顧客が気づく前に検知できているか。基盤側の原因特定にどれだけかかっているか
- **原因が分からない障害の比率**：Observabilityが機能しているかの実質的な指標
- **基盤起因の障害の再発率**：再発防止策が実装まで到達しているか
- **システム原価**：処理量や売上の伸びに対して、インフラとAI処理のコストが線形に増えていないか
- **トイルの量**：手作業の運用が、自動化によって減っているか
具体的な目標は、入社後にベースラインを計測したうえで一緒に設定します。
## 向き合う技術
| 領域 | 技術 |
| バックエンド | Node.js / TypeScript / Python / GraphQL |
| データストア | PostgreSQL / AWS S3 / DynamoDB |
| インフラ | AWS / Terraform / Docker / GitHub Actions |
| 可観測性 | Datadog等のObservabilityツール（導入・拡充はこのポジションの担当領域） |
| AI処理 | LLM API、文字起こし用GPU |
すべての技術に最初から精通している必要はありません。本番環境で起きていることを根拠に基づいて説明し、ソフトウェアで改善できることを重視します。
Preferred Experiences
- Datadog、OpenTelemetry、Prometheus等を使ったObservabilityの設計・導入経験
- SLI/SLOやエラーバジェットの設計・運用経験
- PostgreSQL等のデータベースのキャパシティプランニング、パフォーマンスチューニングの経験
- LLM APIやGPUを使うAIワークロードの運用、監視、コスト最適化の経験
- GitHub Actions等のCI/CDや、開発者向けセルフサービス基盤の構築経験
- IAMポリシー、最小権限、シークレット管理などのアクセス制御設計の経験
- 生成AIを使った運用自動化（アラート要約、障害調査支援、ランブックの自動化など）の経験
- 急成長期のSaaSやスタートアップでのインフラ運用経験
歓迎要件のすべてを満たす必要はありません。これまでどんな障害に向き合い、何を仕組みに変えてきたかを、ぜひ聞かせてください。
We are looking for
### 「起きてから直す」より「起きる前に手を打つ」ことに関心がある方
兆候の段階で手を打ち、顧客が影響を受ける前に解決したい。原因がアプリケーション側にあれば、開発チームのコードまで踏み込んで追いかけられる方です。
### トレードオフに、自分のスタンスを持ち込める方
可用性・パフォーマンス・コストは、同時に最大化できません。「すべて両立させます」ではなく「この順で守ります、理由はこうです」と言い切り、その判断に責任を持てる方を歓迎します。
### 新しい技術を、自分の手で確かめてから持ち込める方
ツールや手法を、記事を読むだけでなく自分で検証してから導入したい。AIも、自動化の手段として積極的に使いながら、最終的な判断責任や変更の管理、監査可能性を手放さない方です。
### 人を責めず、仕組みで解決したい方
障害の振り返りで人を責めない。SLOを押し付けるのではなく、開発チームとの合意として作れる。オーナーのいない領域に自ら踏み込みつつ、抱え込まずに仕組みとして残せる方です。
**壊れてから直す運用から、壊れにくく、壊れてもすぐ直せる基盤へ。**
Bring OutのSREとして、成長を支える信頼性の土台を一緒につくりませんか。
Working Conditions
Salary
応相談
・候補者様の ご経歴 / スキル によって柔軟に条件を検討
・半期ごとにミッションシートを設定し評価を実施
※ストックオプション付与の可能性有り
Location
リモートワーク
Job Type
正社員／契約期間の定めなし
Work hours
・フレックスタイム
- 始業 8:00から10:30まで
- 終業 15:00から20:00まで
- コアタイム. 10:30から15:00まで
- 労働時間 月160h + みなし残業40h以内
※実態として、チームMTG等の都合で9:30-17:00位に稼働している従業員が場合が多い、未就学児のお子さんを持つ家庭が多く、夜に稼働している方は少ない
休日
- 週休2日（土日）、祝日
- 有給休暇 年間10日
- 年末年始休暇(12月29日から翌年1月3日まで)
- 慶忌休暇
Probation period
・試用期間は入社年月日より3カ月です。
Benefits
- 社会保険完備
- 健康診断（年1回）
- 育休産休制度
- 交通費支給
- 出先での会議の場合の会議室代全額支給
- リモートワーク手当（ヘッドセットなどの準備として最大2万円補助）
- PC支給（ビズ15万円以内、開発20万円以内）