CREとは｜カスタマーリライアビリティエンジニアの仕事内容とSREとの違い

CREとは｜顧客側の信頼性を引き受けるエンジニア職

CREとは、Customer Reliability Engineering（顧客信頼性エンジニアリング）の略で、顧客が自社サービスを安定して使えている状態をエンジニアリングで作る職種です。障害が起きていなくても、顧客の設定ミスや使い方の誤りで「このサービスは不安定だ」と感じられるなら、CREの課題になります。

条件として、CREが成立するのはサービスの技術的難易度が高い領域です。SaaS、クラウド基盤、API提供型のプロダクトなど、顧客側にも実装や運用設計が求められる製品で置かれることが多い役割です。

例外もあります。toC向けのシンプルなアプリでは、CREという独立した役割を置かず、サポート部門とプロダクトチームの連携で処理するケースが一般的です。

CREの定義と「信頼性の対象」

信頼性という言葉は同じでも、誰にとっての信頼性かで職種が分かれます。

CREが扱うのは、真ん中の行です。顧客のアーキテクチャやリトライ設計まで踏み込んで、「なぜその顧客だけエラー率が高いのか」を突き止めます。

Googleが2016年に提唱した背景

CREという職種は、Googleが2016年10月に発表しました。Google Cloud公式ブログによると、掲げられたミッションは「顧客の不安をゼロに近づける」という単純なものです。

仕組みとして特徴的なのは、責任を共有する枠組みを作った点でした。顧客のページャーが鳴るとGoogleのページャーも鳴る。インシデント時には同じ war room に入る。その代わり顧客側にも、本番稼働前レビューの通過、監視体制の維持、ポストモーテムへの参加といった義務が課されます。

エラーバジェットの考え方も共有されます。可用性99.9%なら、1か月あたりの許容ダウンタイムは約43分です。この枠内に収まっている間は新機能をリリースしてよく、超えたら安定化に専念する。顧客とベンダーが同じ数字を見て判断する、という設計思想です。

この「同じ数字を見る」という発想が、CREという職種の出発点にあたります。ただし、ここまで踏み込んだ共同運用はGoogleの原型に近い形であり、国内企業では共同オンコールやwar room参加を前提としないCRE求人も少なくありません。

ミニFAQ｜職種の前提

Q. CREはGoogle固有の職種ですか。

いいえ。発祥はGoogleですが、現在は国内のSaaS企業・インフラ事業者が自社の文脈で定義し直して採用しています。Googleの原型そのままとは限りません。

Q. 「CRE」は不動産用語のCREと同じですか。

別物です。不動産分野では Corporate Real Estate（企業不動産）の略としてCREが使われます。求人検索でノイズが混ざりやすいので、「CRE エンジニア」「Customer Reliability」で絞ると精度が上がります。

CREとSREの違い｜守る対象と立つ位置が分かれる

CREとSREの違いは、信頼性の向き先です。SREは自社システムの内側に立ち、CREは自社と顧客の境界線に立ちます。

条件を付け加えると、使う技術やスキルセットには重なりが多い職種です。SLO、監視、ポストモーテム、自動化。道具箱はほぼ同じで、使う相手が違います。

SREの方法論そのもの（SLI/SLOの設計手順、エラーバジェットの運用、トイル削減の進め方）は、SREとは？仕事内容・年収・必要スキルとDevOpsとの違いをエンジニア視点で解説で体系的に扱っています。本記事では職種としてのCREの輪郭に絞ります。

両者が重なる領域と、分かれる瞬間

重なるのはインシデント対応の最中です。障害が起きれば、SREは復旧を、CREは顧客への影響説明と暫定回避策の提示を同時に進めます。

分かれるのはその後です。SREは再発防止のために自社システムを直します。CREは「同じ問い合わせが二度と来ない状態」を作るために、ドキュメント、製品仕様、顧客側の設計のどこを直すかを判断します。

障害対応の標準的な流れとポストモーテムの書き方は、障害対応の手順とポストモーテムの書き方｜一次対応から再発防止までにまとめています。

混同しやすい5職種の整理｜関与フェーズで並べる

信頼性と顧客接点が絡む職種は、名前が似ていて区別が付きにくいものです。関与するフェーズで並べると見通しが良くなります。

求人票の職種名を見分けるときは、この表のように関与フェーズで整理すると判断しやすくなります。「この募集はどの行に近いか」を当てはめると、職種名の揺れに惑わされにくくなります。

テクニカルサポートエンジニアとカスタマーエンジニアの詳しい違いは、テクニカルサポートエンジニアとは｜仕事内容・年収とカスタマーエンジニアの違いで解説しています。

CREの仕事内容｜5つの活動

CREの業務は、問い合わせ処理ではなく問い合わせの発生源を潰すことに重心があります。日々の一次対応はサポート部門が担い、CREはその上流に立つ構図が一般的です。

顧客のSLO設計と運用レビュー

顧客が自社サービスをどの水準で使いたいのかを、数字で合意します。可用性、レイテンシ、エラー率。どこまでを許容するかを決めておくと、障害時の判断が速くなります。

本番稼働前のレビューを入れる企業もあります。構成、リトライ設計、タイムアウト値、監視の有無。ここで指摘できた分だけ、稼働後のトラブルが減ります。

高難度の技術支援と恒久対策

サポート部門でエスカレーションされた難問を引き取ります。ログの読み解き、再現環境の構築、原因の切り分け。

重要なのはその先です。原因を特定したら、同じ事象を再発させない手を打ちます。製品側の修正依頼、ドキュメント追記、監視ルールの追加、顧客向けの設定ガイド。恒久対策まで進めないと、CREの価値は出ません。

プロダクトへのフィードバック

顧客の詰まりポイントは、製品の改善材料そのものです。CREは問い合わせの傾向を集計し、「どの機能のどの挙動が誤解を生んでいるか」を開発チームに持ち込みます。

単発の要望を右から左に流すのではなく、件数と影響度を付けて優先度の議論に乗せる。この翻訳作業がCREの腕の見せどころです。

サポート基盤の自動化とツール開発

調査用の管理ツール、ログ検索の仕組み、顧客向けの診断スクリプト。サポート部門が自力で解決できる範囲を広げるほど、エスカレーションは減ります。

ドキュメントとナレッジの整備

トラブルシューティングガイド、設計のベストプラクティス、既知の制約一覧。「書けば問い合わせが減る」ものを見極めて書きます。

ミニFAQ｜業務範囲の補足

Q. CREは顧客先に常駐しますか。

国内の事業会社では、自社プロダクトの顧客を担当する内勤型が中心です。定例ミーティングやインシデント時のみ顧客と同席する形が多く、常駐前提の募集は限られます。

Q. 営業やカスタマーサクセスと同行しますか。

技術的な論点がある商談や導入支援では同行するケースがあります。ただし売上目標を直接持つ構成は一般的ではありません。

日本企業におけるCREの実態｜求人から見る職務範囲の幅

日本のCRE求人は、本記事では同じ職種名でも中身を大きく3タイプに整理できます。2026年10月時点で国内事業会社の公開求人（SaaS・メディア・EC・ホスティングなど数社、十数件程度）の募集要項を読み比べた筆者の整理で、市場全体の断定ではなく公開求人で観測できた範囲の傾向です。

同じ「CRE」でも、SRE寄りの募集ではオンコールシフトが前提になり、プロダクト寄りの募集では実装比率が高くなります。入社後のギャップはここで生まれます。

求人票で確認すべき5項目

1. オンコールの有無と頻度 — 月あたり何週のシフトか。手当の有無もあわせて確認します

2. 一次対応を持つかどうか — サポート部門が別にあるか、CREが直接受けるか

3. コードを書く比率 — 「ツール開発あり」の実態が月数時間なのか常時なのか

4. 顧客との接点の深さ — 定例あり／障害時のみ／原則なし

5. 評価指標 — 解決件数で測るのか、再発率や製品改善で測るのか

5項目のうち1と5は、面談で必ず聞いておきたいところです。評価指標が解決件数だけの場合、実態はテクニカルサポートに近いと考えたほうが無難です。

CREに必要なスキルとなり方

多くの求人では、技術的な深さと、それを顧客の言葉に翻訳する力の両立が求められます。ただし比重は企業により異なり、サポート寄りの体制では説明力が、SRE寄りの体制では技術の深さが重く見られる傾向があります。

技術スキル

• クラウド基盤（AWS／Google Cloud／Azureのいずれか）の運用経験

• ログ・メトリクスからの原因切り分け。監視SaaSの実務経験があると強みになります

• SQLとBIツールでの問い合わせ傾向分析

• スクリプト言語での自動化（Python、Go、シェルなど）

• ネットワーク、認証、API設計の基礎知識

可観測性まわりの土台を固めたい場合は、New Relicとは｜オブザーバビリティの基本・Datadogとの違い・案件動向やOpenTelemetryとは｜可観測性標準の仕組み・導入の流れ・案件動向が入口になります。

非技術スキル

技術的に正しい説明と、顧客が納得する説明は違います。インシデントの最中に、何が起きていて、いつ復旧見込みで、顧客側で何をすべきかを、過不足なく伝える力が要ります。

文章力も実務能力のうちです。ポストモーテムや設計レビューのコメントは、書いたものがそのまま成果物になります。

移行の4ルート

上の期間は、現職で近い業務を一部兼務しながら準備できる場合のかなり粗い目安です。実際の所要期間は現職の裁量、兼務可否、応募先の採用要件で大きく変わります。異職種への移行を順序立てて進める考え方は、エンジニアの職種転換｜開発からSRE・データ職へ移る順序と段階で整理しています。

CREの年収・単価｜公的統計と公開求人の両面から見る

はじめに前提を置きます。CREという職種名に対応する公的統計は存在しません。そのため、近接職種の公的統計と、公開求人の提示レンジを分けて見る必要があります。

厚生労働省の職業情報提供サイト（job tag）では、システムエンジニア（受託開発）の平均年収が約578.5万円と示されています（令和7年 賃金構造基本統計調査に基づく数値）。ただしこれは受託開発SEの統計であり、SaaS企業のCREを直接示す数値ではありません。あくまで周辺職種の水準を測る物差しとして見てください。

正社員の提示年収レンジ

2026年10月時点で確認した国内事業会社の公開求人ベースでは、提示年収は概ね400万〜800万円台が中心でした。母集団はCRE職の公開求人（SaaS・メディア・EC・ホスティング等、数社・十数件程度）の募集要項に記載されたレンジで、市場全体の相場ではありません。

大規模サービスを抱える企業では、1,000万円を超える提示が出るケースもあります。該当するのは、大規模SaaSやクラウド基盤での運用改善を経験し、重要顧客との技術折衝を主担当で回せる層です。観測できた範囲では、その水準の募集はクラウド基盤の運用経験に加えて、顧客折衝の実績とデータ分析（SQL・BIツール）の両方を要件に挙げていました。技術だけ、あるいは対人スキルだけでは届きにくい帯です。

フリーランス・業務委託での扱い

業務委託で「CRE」という職種名の公開案件が出るケースは限られます。顧客との信頼関係を前提とする役割のため、社員ポジションとして置かれやすいという事情があります。

近い実務を業務委託で探すなら、入口はSRE案件や運用保守案件です。単価感はSREフリーランスの単価相場｜DevOps案件の月額レンジと参入目安、オンコールを含む契約条件の実情は運用保守・オンコール案件のフリーランス実情｜単価相場・手当・契約が参考になります。案件そのものはフリコンの案件一覧から職種・技術のタグで絞り込めます。

自分の経験でどのくらいの単価を狙えるかを確かめたい方は、無料のフリーランスエンジニア単価診断で市場単価の目安を確認できます。単価を体系的に上げる考え方は【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？で整理しています。

よくある失敗と、参画前チェックリスト

失敗1：職種名だけで判断して入社する

「CRE」で募集されていても、実態がテクニカルサポートの延長というケースはあります。前述の3タイプ分類に当てはめ、どの重心かを確認してから応募してください。

失敗2：恒久対策まで進めずに疲弊する

問い合わせ対応だけを回し続けると、件数は減りません。1件対応するごとに「製品・ドキュメント・監視のどこを直せば再発しないか」を1行でも記録に残す。この積み上げが効いてきます。

失敗3：顧客の環境を把握しないまま回答する

SREとCREの最大の違いは、顧客の利用環境という変数が入る点です。同じエラーでも、顧客のリトライ設計やタイムアウト値によって原因は変わります。環境のヒアリング項目をテンプレート化しておくと、初動が速くなります。

失敗4：オンコールの条件を確認せずに契約する

業務委託でSRE寄りのCRE業務を受ける場合、夜間対応の範囲と手当は契約書で確認してください。口頭合意のまま稼働を始めると、実働と報酬が合わなくなります。

参画前チェックリスト

• 一次対応を自分が持つのか、サポート部門が持つのか確認した

• オンコールの頻度・時間帯・手当を書面で確認した

• 評価指標が「解決件数」以外の軸を含んでいるか確認した

• 製品チームへのフィードバック経路が仕組みとして存在するか確認した

• 担当顧客数と、1顧客あたりに使える時間の目安を聞いた

• 使用している監視・ログ基盤の名称を把握した

• 既存のナレッジベースが整備されているか見せてもらった

7項目のうち、最初の3つは入社・参画後の負荷に直結します。面談で必ず押さえてください。

まとめ

CREは、自社サービスの稼働ではなく顧客の利用状態に責任を持つ職種です。SREと同じ道具を使いながら、立つ位置が顧客との境界線にある点が違います。

• CREの守備範囲は「顧客が安定して使えているか」。SREは自社システムの内側を見る

• Googleが2016年に提唱した、顧客とベンダーがSLOとエラーバジェットを共有する枠組みが出発点。ただし国内企業では各社の体制に合わせて役割定義が分かれている

• 日本の求人は「サポート寄り」「SRE寄り」「プロダクト寄り」の3タイプ。職種名ではなく責任範囲で判断する

• 観測できた公開求人の提示年収は400万〜800万円台が中心（市場全体の相場ではない）。1,000万円超の帯は技術とデータ分析、顧客折衝の3点セットが前提になりやすい

• 業務委託で「CRE」名義の公開案件は限られる。入口はSRE案件や運用保守・オンコール案件

• 応募前にオンコール条件・一次対応の所在・評価指標の3点を確認すると、入社後のギャップを減らせます

次の一歩としては、気になる求人を3社ほど並べて、本記事の3タイプ分類と5項目チェックに当てはめてみてください。同じ職種名の募集がまったく違う仕事であることが、はっきり見えるはずです。

参照した一次情報は以下のとおりです。

• Google Cloud Blog｜Introducing Google Customer Reliability Engineering

• Google｜Site Reliability Engineering（書籍 目次）

• 厚生労働省 job tag｜システムエンジニア（受託開発）