Sentryのシステム開発の発注/外注/依頼/委託方法について

Sentryの発注は、監視対象の整理、RFPでの条件明記、PoCからの段階導入の順に進めると、障害検知から復旧確認までの運用につながります。発注形態や契約、費用、委託先の選び方も、この順番に沿って決めていくと進めやすくなります。

▼全体ガイドの記事
・Sentryのシステム開発の完全ガイド

Sentryのシステムを発注する前に知っておきたい全体像

Sentryのアプリケーション層監視機能として、エラー監視、Tracing、Logs、Session Replayを並べた図。
監視機能を組み合わせて本番障害を調べます。

Sentryの発注で成果を出すには、アカウント作成やSDK追加に加えて、検知後の確認、対応開始の基準、修正後の復旧確認まで運用を設計することが欠かせません。

Sentryが担うアプリケーション層の監視

SDKで集める情報を把握しておくと、Sentryが本番障害の調査にどう役立つかを判断できます。

  • 収集対象:例外、画面の不具合、API遅延、リリース後のクラッシュ
  • 調査情報:スタックトレース、環境、OS・ブラウザ、リリース番号、ユーザー影響

これらがそろうと、再現しにくい本番障害の調査に役立ちます。Sentryでは、エラー監視、Tracing、Logsを組み合わせられます。さらに、Session ReplayやRelease Health、Uptime、Cron監視も使えます。

一方で、サーバーのCPU、メモリ、ネットワーク、データベースの監視は、Sentryだけで賄えるとは限りません。そのため、CloudWatch、Datadog、Prometheusなどと役割を分けます。

SlackやGitHubとの連携も組み合わせられ、Sentryはコードとユーザー体験に近い観測を担います。

発注書には、導入したツールの名前より、重要業務のエラー検知、担当者への通知、原因調査、修正確認を成果として書きます。

Sentry本体と周辺の仕組みに分けた発注範囲

見積の項目は、Sentry本体、周辺の運用、既存システム改修に分けて並べます。

  • Sentry本体:契約・初期設定、SDK実装、source map・リリース情報連携
  • 監視設計:タグ、ユーザー影響、PIIのマスキング
  • 運用周辺:通知・チケット連携、ダッシュボード、運用手順書
  • 既存システム改修:必要な場合はSentry関連費用と分けて計上

初回見積が安く見えても、範囲が曖昧なままだと、後から追加作業が生じることがあります。たとえば、モバイルやバッチ対応、権限設定、通知調整、個人情報の確認が、途中で追加になる場合があります。

納品するものの境界を先に決めておくと、どこまでを誰が受け持つかが見えて、相見積もりも比べやすくなります。

Sentryの発注形態の選び方

発注形態は、実装だけを頼む型、設計から導入までを一括で委託する型、継続的に伴走してもらう型に分けられます。

発注先は、アプリ構成と障害対応の成熟度を踏まえて選ぶことが大切です。価格だけで決めると、必要な監視範囲が後から足りなくなることがあります。

SDK導入だけを依頼するスポット型

社内に開発責任者と運用担当者がいて、設定方針も決まっているなら、SDK導入や通知連携だけを頼めます。この方法では、1つのWebサービスでPoCを行います。

PoCでは、development、staging、productionの環境を分けたうえで、リリース番号、source map、基本的なエラー通知を短期間で確かめます。

実装だけを頼むと、送信データの範囲やIssueの所有者が曖昧になりやすいです。そのため、対象の言語とサービス、完了条件を先に決めます。テスト項目と設定の引き渡し方法も、発注時に決めておきます。

要件整理から実装までを一括委託する型

フロントエンドやAPIに加えて、非同期ジョブ、モバイル、バッチまで監視する構成が複雑な場合は、一括委託が向いています。委託先は、アプリの処理とインフラ構成をあわせて確認します。

一括委託では、重要なユーザージャーニー、エラーの重大度、通知先、リリース運用をまとめて設計できます。要件定義と実装で納品するものを分けたうえで、設計レビューを中間の成果物として扱います。

全サービスへ一度に広げず、次の手順で進めます。

  1. 代表サービスでPoCを行う
  2. 設計を承認する
  3. 段階的に展開する

この順で進めると、不要なイベント送信や過剰な通知設定を抑えやすくなります。

導入後のSRE・運用まで伴走してもらう型

障害対応の担当者が足りない場合や、24時間に近い運用を求める場合は、導入後の調整やオンコール設計まで含む伴走型が候補になります。

契約には、Issueの一次確認者、重大障害の連絡経路、営業時間外のエスカレーション、月次改善会議を含めます。伴走型は月額費用が発生しやすい一方で、通知疲れや未対応Issueを減らしやすい点が強みです。

一次対応を自社で行うか、受託会社が一次切り分けまで担うかは、先に決めておく必要があります。そのうえで、対応時間、除外対象、緊急連絡先を契約書と運用手順書に書きます。

ポイント

発注形態は、社内の体制とアプリ構成、障害対応の成熟度で選びます。体制があれば実装だけの依頼、構成が複雑なら一括委託、障害対応まで任せたいなら伴走型が候補です。

SentryのRFPと要件整理で決める事項

SentryのRFPに記載する要件として、監視対象と重要業務フロー、送信データ、成果物、受入条件を並べた図。
前提と完了時の確認内容を同じ書式で揃えます。

RFPには、ツール名だけでなく、業務上の目的と検知後の行動を書きます。

たとえば、「受注登録の失敗を検知する」「本番リリース後のクラッシュ率を確認する」のように書きます。また、「決済画面の顧客情報をSentryへ送信しない」といった制約も書き込みます。

目的を具体的に共有しておくと、各社が異なる前提で見積もることを防げるため、監視対象と重要業務フローを中心に、送信データ、成果物、完了条件を同じ条件で示します。

監視対象と重要業務フローの一覧

監視対象は、システム名、サービス名、言語、実行環境を一覧にします。加えて、担当チーム、リポジトリ、デプロイ方法も書き出します。

業務フローは、ログイン、検索、受注、決済を中心に、在庫更新、申請承認、通知送信も含めて洗い出します。停止や誤動作が売上や顧客対応に影響する業務フローから、優先して扱います。

各フローには、許容エラー率、検知する例外、許容レスポンスタイムを設定し、通知時間帯、一次担当、復旧目標も決めます。また、イベント数も先に測っておく必要があります。量が分からないままプランを選ぶと、超過料金や通知ノイズを見積もりに反映できません。

送信データと個人情報の扱い

RFPには、送信データと国外クラウド利用時の確認事項を次のとおり書きます。

  • 送信しない情報:氏名、メールアドレス、顧客番号、Authorizationヘッダー、決済情報
  • 国外利用時の確認:法令、プライバシーポリシー、社内規程、委託先・再委託先、保存場所、保持期間

Sentryには、エラーメッセージやURL、ユーザー情報、リクエスト情報、画面操作の記録が含まれることがあります。そこで、SDKのbeforeSendなどでマスキングや除外を行い、テスト環境で漏えいがないかを確かめます。なお、個人情報保護委員会の「外国にある第三者への提供編」は、2025年12月に一部改正されています。

基本は、個人データを送らない最小化です。そのうえで、法務と情報システム部門の確認を、RFPの工程に組み込みます。

RFPに書く成果物と完了条件

RFPでは、納品するものと、受入時に確認する状態を分けて書きます。

  • 成果物:プロジェクト設定、SDK、環境分離、source map、release、タグ、Issue所有ルール
  • 受入条件:正しい環境・リリース・担当者の表示、重大度別通知、個人情報のマスキング

通知設定やダッシュボード、PIIマスキングは、成果物に含めるかを明記します。テスト結果、運用手順書、教育資料についても、同じ扱いにしてください。

設定ファイルやIaC、GitHub連携の権限について、誰が所有するかを決めておきます。そのうえで、テスト用のエラーを発生させ、修正後のIssueまで確かめます。

業務フローごとに受入テストを用意しておくと、発注側が納品の可否を判断できます。

ポイント

RFPには、ツール名より業務上の目的と検知後の行動を書きます。監視対象や送信データ、完了条件を同じ条件で示すと、各社の見積を同じ土台で比べられます。

Sentryの外注で選ぶ契約形態と責任分界

Sentryの導入では、請負契約、準委任契約、保守・運用の月額契約を組み合わせるケースが多くなるため、契約の前に、検収する成果、協力して進める作業、障害発生時の担当を分けて整理しておきます。

成果物が明確な場合の請負契約

対象サービス、実装範囲、通知連携、テスト、手順書といった納品物と完成条件が明確なら、請負契約を検討できます。検収日まで決まっていれば、予算と進捗を管理しやすくなります。

既存コードの品質やイベント量が分からないまま固定価格にすると、想定外の追加作業につながることがあります。そこで、対象サービスの増加や非対応言語の追加は、追加費用の条件として書いておきます。

既存認証の変更、SAMLやSCIM、個人情報対応の再設計、24時間運用への変更は、別途協議の対象になることがあります。これらの条件は、契約書や見積に書いておきます。

要件が動く場合の準委任契約

監視対象や通知基準をPoCで確かめながら決める場合は、準委任契約で設計、調査、改善を進められます。費用は、稼働時間や担当者の役割をもとに計算します。

週次では、成果の報告、課題一覧、次週の作業予定を確認します。あわせて、どの意思決定を支援し、何を改善したかを記録します。

Issue数、重大アラートの未対応時間、通知の誤検知、マスキング確認などの指標を設けると、伴走の価値を測れます。

保守契約の対応時間と責任範囲

保守に含める作業は、アラート調整、ダッシュボード更新、SDK・連携先の変更、月次レポート、一次切り分け、緊急連絡のそれぞれについて明記します。

Sentryにエラーが届いたとしても、アプリ修正、データベース復旧、顧客説明まで委託先が担うとは限りません。そのため、営業時間内に限るか、夜間や休日も含めるかを決めておきます。

一次応答の目標時間、重大度ごとの連絡方法、再委託の可否、設定とデータの返却方法を決めます。費用面では、Sentry利用料と保守費、クラウド・通知費を別項目に分けます。

ポイント

検収する成果が明確なら請負、要件が動くなら準委任、運用を続けるなら月額の保守契約を組み合わせます。どの契約でも、委託先の担当範囲を契約書に書きます。

Sentryのシステム開発にかかる費用相場と見積の内訳

費用は、Sentry公式の利用料と、設計・実装・運用の費用に分けて考えます。公式の料金はプランと利用量で変わり、開発費は監視対象数、連携の複雑さ、個人情報対策、運用時間によって変わります。

次に示す開発費は、Sentry固有の公的な平均価格ではなく、リサーチノートに基づく導入工数の推定です。

公式のSentry利用料金と利用量・プラン

プラン料金は、Sentry公式Pricing(2026年8月確認)に基づいています。

  • プラン料金:Developerは無料、Teamは月額26米ドル、Businessは月額80米ドル、Enterpriseは個別見積
  • 基本枠:月5万件のError、5GBのLogs、500万Span、50件のSession Replay
  • 追加費用:超過分は従量課金。プロファイリングやSeerのAIデバッグも追加の場合あり

1米ドル150円で単純に換算すると、Teamは約3,900円、Businessは約12,000円になります。ただし、実際の円での負担は、為替、税、請求条件、年払い割引によって変わります。

見積には、エラーやログ、Span、Replay、Cron、添付ファイルの予測量を入れます。あわせて、超過したときの上限管理も含めます。

監視範囲ごとの導入・実装費のレンジ

導入費は、監視するサービス数や組み込む機能によって変わります。そのため、範囲ごとの費用感を並べて比べます。

  • 1サービスのPoC:SDK導入を含め20万〜80万円程度
  • 小規模Webの本番導入:フロントエンド・API・バッチを含め80万〜300万円程度
  • 複数サービス:Tracing、Logs、通知、CI/CD、PII対策を含め300万〜1,000万円程度
  • エンタープライズ構成:複数組織、SSO、監査、24時間運用を含め1,000万〜3,000万円以上の可能性

これらは、業務システムの開発規模や人月単価、監視設計・連携・セキュリティの工数から推定した数字です。特定の会社の定価でも、Sentry公式の開発費でもありません。

金額は、監視対象が1つか10個か、モバイルを含むか、既存CI/CDを流用できるかで変わります。マスキングの範囲も、金額に影響します。

このレンジは予算の検討に使い、そのうえで、確定の金額は同じRFPをもとに複数社から見積を取ります。

対応時間と改善範囲で分けた保守・運用費

月々の負担は、運用支援の内容や対応時間によって変わります。そのため、契約範囲と費用を照らし合わせて確認します。

  • 軽い運用:アラート調整やダッシュボード更新で月額5万〜30万円程度
  • 継続支援:一次切り分けや定例改善を含め月額30万〜150万円以上
  • 24時間対応:オンコールや障害対応は人数、時間帯、SLA、対象サービスによる個別見積

保守・運用費の数値は、類似する監視・運用支援からの推定で、公式の保守料金ではありません。

通知を絞りすぎると重大障害を見逃すおそれがあります。一方で、すべてのWarningを通知すると、担当者が見なくなることもあります。

重大Issueの未対応時間、再発数、誤検知、イベント量、利用料を月次で確かめる改善作業も、見積に含めておきます。

ポイント

予算は、Sentry公式の利用料と開発・運用費を別々に立てます。前提を揃えた見積を比べ、金額の差を説明できる会社を選んでください。

Sentryの委託先選定と見積比較の観点

Sentry委託先の選定観点として、使用言語・SDK、source map・release番号、PIIマスキング、設定と履歴を示した図。
実装経験から運用の継続性まで確認します。

Sentryを組み込んだアプリ開発と障害対応を理解している会社を選びます。社名が公開されているかより、近い言語・構成・運用体制で設定を引き継げるかを確かめます。

技術力とSentry実装の深さ

技術経験と監視範囲の説明力は、次の観点から確かめます。

  • 実装経験:使用言語・SDK、source map、release番号、Issue自動グルーピング、Ownership Rules
  • 連携と保護:GitHub・Slack、Tracingのサンプリング、PIIマスキング

障害調査に必要な情報の設計を説明できる会社が、候補になります。ただし、Sentryだけで、OSやネットワーク障害の原因まで分かるとは限りません。そこで、CloudWatchや既存APMのログとTrace IDをどう結び付けるかを聞いておきます。

また、どのツールを一次の画面にするかも確かめます。業務フローごとに観測範囲を説明できるかどうかを見ます。

同じ条件で項目別に見た見積書の比較

比較表は、作業範囲、見積条件、費用区分に分けて並べます。

  • 作業範囲:初期設計、SDK、環境、連携、セキュリティ、テスト、文書、教育、保守
  • 見積条件:時間、人数、単価、期間、前提、除外、追加費用条件
  • 費用区分:Sentry利用料、クラウド費、通知サービス費を委託費と分ける

安い提案では、source map、PII対策、モバイル、バッチ、受入テスト、手順書が除外されていないかを見ます。

高額な提案では、24時間対応や専任者、複数環境、SAML・SCIM、監査対応のなかに、不要な範囲が含まれていないかを見ます。

各社に同じ質問をして、金額だけでなく前提条件と成果物の差を比べます。

運用責任と引き継ぎのしやすさ

提案会社には、障害対応を次の流れで説明してもらいます。

  1. 障害の一次切り分け
  2. 担当チームへの割り当て
  3. 修正とリリース
  4. 復旧確認と事後報告

重大度、対応時間、通知先、休日対応、再委託、責任者が不在のときの代替手段も確かめます。ここが曖昧なままだと、導入後に問題が表面化することがあります。

Sentryプロジェクトの管理者、リポジトリ、IaCは、発注者が管理できる形にしておきます。ダッシュボードと通知先も、発注者が直接扱える状態にします。手順とテストデータも、引き継げる形で残します。

委託先や担当者が変わっても、設定と履歴を引き継いで運用できることを、契約と受入条件に含めます。

ポイント

委託先は、Sentryを組み込んだアプリ開発と障害対応を説明できる会社から選びます。見積は作業範囲と前提条件を項目ごとに並べ、金額だけで比べないことが大切です。

外注後にSentryを定着させる運用の進め方

Sentryは、導入した時点で成果が完成するものではありません。最初の数週間でIssueを分類し、通知の優先順位や所有者、対応期限を決めて、運用を整えていきます。

開発チームが毎日の作業のなかでSentryを見る流れを作っておく必要があります。

重大度と業務影響で絞るアラート

通知先を分けるため、障害を業務影響と対応優先度で分類します。

  • 即時対応:顧客が操作を完了できない障害、売上・決済に影響する障害
  • 復旧対応:復旧が必要な性能劣化
  • 次回対応:次回リリースで直す低優先度の不具合

Issueの所有者を自動で割り当て、重大度ごとに、Slack、メール、チケット、オンコールの経路を変えます。

たとえば、公式Customer Storiesでは、Boltが平均検知時間を99%短縮した例と、Supabaseが週次クラッシュを60分の1にした例が紹介されています。

これは各社の公開事例であり、同じ効果が全企業に保証されるわけではありません。そのため、自社の検知時間、未対応時間、再発率を基準値として測っておきます。

月次レビューでの費用と品質の見直し

月次レビューでは、品質と利用量、新機能の適用前提を確かめます。

  • 品質指標:重大Issue数、平均検知・復旧時間、未対応Issue、再発率、リリース後のクラッシュ
  • 利用状況:通知の誤検知、イベント量、プラン超過
  • 新機能情報:2026年のSeer Agentオープンベータ、AIエージェント向けAPI文書の拡充

数値だけでなく、どの業務フローでユーザーに影響が出たかも見ます。加えて、修正が再発防止につながったかも確かめます。

AIデバッグやAgent tracingを使うなら、コードやイベントデータの送信先、追加料金、権限、社内のAI規程を確認しておく必要があります。

特に、新機能を追加する前には、現在の運用で解決できていない課題をはっきりさせます。

よくある質問(FAQ)

料金や依頼範囲、個人情報、既存の監視との違いは、発注の前によく質問されます。代表的な疑問への答えを、質問ごとに示します。

Sentryの導入だけを外注するといくらかかりますか?

リサーチノートに基づく推定では、1サービスのSDK導入から環境分離、基本アラート、送信確認までのPoCは、20万〜80万円程度が検討の目安になります。

既存システムの調査や、source map、PIIマスキング、GitHub・Slack連携、受入テストの有無によって変わります。そのため、定額だとは言い切れません。

Sentryは無料プランだけで業務システムに使えますか?

小規模な検証や個人開発であれば、無料のDeveloperが候補になります。一方、チーム運用や外部連携、権限管理が必要なら、有料プランも比べます。イベント量や保持期間、SSOの要否も、プラン選びに関わります。

公式Pricingでは、Teamが月額26米ドル、Businessが月額80米ドルです。基本枠を超えたときや追加機能を使うときは別に料金がかかるため、実際のイベント量を測ってから判断します。

Sentryへ顧客情報を送っても問題ありませんか?

顧客情報はそのまま送らず、SDKのフィルタリングやマスキングで、データを最小限にします。

確認するのは、氏名やメール、認証情報、決済情報のほか、保存リージョン、保持期間、再委託、社内規程です。個人情報保護委員会のガイドラインを踏まえて、法務やセキュリティの担当者とも確認します。

CloudWatchやDatadogがあればSentryは不要ですか?

必要かどうかは、監視する層によって変わります。CloudWatchやDatadogでインフラやログを見られるようにしていても、アプリのIssueやスタックトレースが不足することがあります。

Sentryでは、リリース後のクラッシュやユーザー操作の文脈を確かめられます。そのうえで、既存ツールとの責任範囲や、データの重複、観測の不足を見て採用を決めます。

発注先を選ぶときに最初に聞くべき質問は何ですか?

まずは、近い構成でのSDK実装や、source map・release運用、個人情報マスキング、既存監視との連携、導入後の一次対応について聞きます。

成果物や完了条件、対象外の作業、設定の所有権、保守時間、委託先を変えるときの引き継ぎ方法も確かめておくと、提案を比べやすくなります。

まとめ:運用まで含めたSentryのシステム発注の比較軸

費用は、契約料金と、要件整理やSDK実装の費用に分けて考えます。連携、セキュリティ、運用設計の費用も、別々に見積もります。

まず重要業務と監視対象を決め、RFPに成果物、受入条件、送信データ、通知先、どこまでを誰が受け持つかを書きます。

目安として、1サービスのPoCは20万〜80万円程度、小規模本番導入は80万〜300万円程度です。さらに、複数サービスや運用設計を含む場合は、300万〜1,000万円程度が推定のレンジです。

これらはリサーチノートの工数から算出した目安です。確定の見積を作るときは、イベント量、対象範囲、既存システム、個人情報対策、対応時間を含めます。

委託先は、原因調査からインフラ監視との役割分担、通知の優先順位、障害対応、引き継ぎまで説明できる会社を選びます。

複数社の提案を比べ、月次改善まで含めて、チームがSentryを使い続けられる体制を整えます。

▼全体ガイドの記事
・Sentryのシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。