要約
- ダイニーではSentry（エラーモニタリング／トレーシング／セッションリプレイ）とClaude Code＋Sentry MCPを活用中
- トレーシングとAI連携により、不具合調査の効率化とユーザー影響度の素早い判断を実現
- Ichizokuの伴走支援により、トレーシングなど高度機能の活用が進み、運用レベルが向上
飲食業界のDXを推進するダイニーの取り組み
株式会社ダイ二ーは、日本の飲食業界のデジタルトランスフォーメーションを牽引するSaaS企業です。多くの導入実績のある同社のサービスは、約11000店舗（ダイニー全サービス） が飲食店が利用し、のべ2,500万ユーザー以上の方が利用しています。また、店舗の現場業務と顧客データ、デジタルマーケティングをシームレスに連携させ、独自の価値を提供しています。
サービス紹介サイト：https://dinii.jp/
同社の長期的なビジョンは、飲食店のデジタル化にとどまらず、運営を自動運転のように円滑にするシステム開発を目指しています。そのため、社内でのAI活用への積極的な投資や「外食AIサミット 」の開催によって飲食店経営の新たなスタンダードを共創することを目的に、業界内の対話の促進、AIを利用した機能構築などに取り組んでいます。ダイニーにとって重要なのは、積極的なイノベーションだけでなく、Sentryを活用した強固なフルスタック可観測性の確保と、中核となるプラットフォームが顧客との契約を確実に果たすことにあります。
TypeScript統一とモノレポで支える開発基盤
ダイニーでは全プロダクトの開発言語をTypeScriptに統一し、モノレポ構成で一元管理しています。バックエンドはNestJS、フロントエンドはReactおよびNext.js、モバイルはReact Nativeと、全領域で技術スタックを揃えることで、開発効率と保守性の向上を図っています。さらに、これらすべての領域にSentryのSDKを組み込み、横断的な監視基盤を整備しています。
組織面では、以前は単一チームで全プロダクトを扱っていましたが、事業拡大に伴い領域別のチームに分割されています。一方で、横断的に技術基盤を担うプラットフォームチームが存在します。
「私はプラットフォームチームの一員として、複数プロダクトの品質やアーキテクチャを見ています。特にフロントエンド領域ではコードオーナーとしてレビュー責任を担い、全体の品質担保に関与しています。」（プラットフォームチーム 畑田氏）
人間の勘に依存していたコードレビューと調査
Sentryのトレーシング機能を本格的に活用する以前は、フロントエンドとバックエンドのイベントの関連性を経験や勘に頼って判断していました。ある程度は機能するものの、暗黙知に依存した運用になりやすく、特に複雑な不具合の調査では精度や再現性に課題がありました。
また、AIを活用した分析を行う際にも、イベント同士の明確な紐付けがないことで誤認識が発生する可能性がありました。人であれば経験則で補える部分もありますが、AIにとっては構造化されていない情報は扱いづらく、結果として分析の精度にばらつきが生じていました。
こうした状況の中で、トレーシングによる明示的な関連付けが求められていました。
「人間の感覚でなんとなく紐付けていた部分は多かったと思います。ただ、それが必ずしも正しいとは限らないという不安は常にありました。」（畑田氏）
また、Sentryの活用において、近年大きく変わったポイントの一つが、Claude CodeとMCPを組み合わせた調査フローです。従来は、SentryのUI上でイベントを一つひとつ確認しながら、必要な情報を手動で探していく必要がありました。ログやトレースを横断的に見ながら原因の手がかりを探す作業は、一定の時間と労力を要するものでした。
現在では、Sentry MCPをClaude Codeから利用することで、こうした調査プロセスが大きく変わっています。必要な情報の取得や関連イベントの分析を自動的に進めることができるため、人間がUIを操作し続ける必要がなくなり、調査の初動が大幅に効率化されました。
「以前はUIを操作しながらイベントを見ていましたが、今は待っていれば必要な情報が揃うようになりました。」（畑田氏）
既存導入からの再評価で見えたSentryの価値
畑田氏が入社した時点でSentry自体はすでに導入されていましたが、当初は基本的なエラーモニタリングが中心で、高度な機能は活用されていませんでした。そのため、Sentryの本来の価値を十分に引き出せている状態ではなかったと振り返ります。
その後、トレーシング機能を有効化したことで、イベント間の関係性が明確になり、従来は見えなかった因果関係が可視化されるようになりました。その結果として、これまで見落とされていた関連性や、複雑な問題の構造が把握しやすくなっています。
トレーシングの導入にあたっては、すでにSDKが組み込まれていたこともあり、大きな障壁はありませんでした。基本的には設定を有効化するだけで利用でき、導入コストは非常に低かったと感じています。
一方で、サンプリングレートの設定については、イベント数やリクエスト頻度をもとにAIと壁打ちしながら決定しました。コストとデータ量のバランスを見ながら最適化するプロセスはありましたが、それ以外に大きな課題はなく、スムーズに運用へ移行できたとのことです。
「導入というよりは、単にフラグをオンにしただけという感覚でした。それくらいシンプルに、スムーズに進みました。」（畑田氏）
トレーシング導入後、社内から大きな混乱や課題の声は特に上がっておらず、各メンバーがAIと組み合わせながら自然に活用できています。実際に詰まったというフィードバックがないこと自体が、スムーズに使われている証拠だと感じているとのこと。
トレーシングとリプレイで実現した判断コストの削減
現在は、エラーモニタリングに加えてトレーシングやセッションリプレイを活用しています。特に、バックエンドのエラー発生時にユーザー影響を即座に判断できる点が大きな価値となっています。
例えば、エラー発生時にトレースから紐づくセッションリプレイを確認することで、ユーザーが問題なく操作できているかを即座に把握できます。その結果、調査や対応の優先度を迅速に判断でき、調査コストを削減できています。
また、プラットフォームチームでは定期的にSentryのダッシュボードを確認する運用を行っており、継続的な品質改善にもつながっています。全体として、特別なトレーニングなしでも自然に使われており、チームへの浸透度の高さがうかがえます。
「私個人の利用頻度は高いです。エラー調査時に、トレースとセッションリプレイを組み合わせており、ユーザー影響の有無が迅速に判断できています。ユーザー影響がないと判断できた時点で深掘りをやめられるので、調査の無駄がかなり減りました。」（畑田氏）
分析基盤との連携とプロアクティブな改善への期待
今後の期待としては、イベントデータをより高度に活用できる分析基盤との連携を挙げています。現在はBigQueryなどで他のプロダクトデータと組み合わせた分析を行っているため、Sentryのデータも同様に統合的に扱える仕組みがあると有用だとのことです。
Sentryが単なるエラーモニタリングにとどまらず、蓄積されたイベントやコードベースをもとに、潜在的な問題を自動検出し、改善提案やプルリクエスト生成まで行うような仕組みにも期待しているとのこと。
「定常的な変更がない領域でも異常を検知し、能動的に改善を促してくれると、今後の開発体験を大きく変えると感じています。」（畑田氏）
Ichizokuの伴走支援が後押しした活用の深化
最後に、IchizokuのSentry導入支援に関する評価を伺いました。
ダイニーではIchizokuのサポートによって、Sentry活用が単なるツール導入にとどまらず、段階的に深化していきました。もともとは基本的な機能の利用にとどまっていたものの、トレーシングの有効化など、実際に価値のある機能を適切なタイミングで提案・支援を受けられたことで、運用の幅が広がっています。
「サポートがなければ、トレーシングも活用しきれずに何となく使い続けていたと思います。」と畑田氏は振り返ります。ツール単体ではなく、活用の仕方を含めて支援を受けられたことが、現在の運用レベルにつながっていると実感してくれています。
ありがとうございました！