こんにちは、ウォンテッドリーでインフラエンジニアをしている田中です。
ウォンテッドリーは 2025年10月27日に開催された Observability Conference Tokyo 2025 にスポンサーとして協賛し、 Infra Squad のメンバー4名が現地でイベントに参加しました。この記事ではイベントレポートとして、現地の様子とスポンサーセッション発表の裏側、そして私たちが得た学びをご紹介します。
イベント直前にもストーリーを投稿しているので、こちらもぜひご覧ください。
「OpenCensusと歩んだ7年間」というタイトルでお話ししました。
OpenCensus と分散とレーシングを題材に7年前の導入当時から現在までを振り返り、オブザーバビリティに関する取り組みと知見を紹介しました。またオブザーバビリティの枠を超え、新しい技術や仕組みをどう取り入れていくかという発展的なテーマも扱うセッションにしました。分散トレーシングは私が新卒でウォンテッドリーに入社したばかりの2018年に導入を担当したプロジェクトでした。その後も継続的にメンテナンスの担当をしており、個人的な思い入れが深かったため社内のメンバーにお願いして登壇の枠を譲ってもらいました。
このテーマを選んだ理由は2点あります。第一に、私が7年間関わってきた中で分散トレーシングやオブザーバビリティに関するエコシステムの整備はここ数年で大きく進んでおり、導入のハードルが下がったことで試しやすい状態になっていると感じています。第二に、この移り変わりの中で OpenCensus という大きなエコシステムが廃止されるという珍しい出来事も経験しました。多くの難しさがありましたが、この経験で得た知見をコミュニティの一員として共有することに大きな意味があると考え準備を進めました。
発表では導入当時から運用の課題までを中心にお話ししました。課題として紹介した OpenCensus からの移行や途切れたトレースの対策については時間の関係で今回は話しきることができませんでしたが、社内で対策を進めているので、また次の機会にお伝えできると嬉しいです。
セッション終了後に開催された Ask the Speaker では、ウォンテッドリーの取り組みに興味を持ってくださった方から直接質問をお受けしました。本来の趣旨とは異なるかもしれませんが、A, Bトラックの登壇者の方々ともオブザーバビリティについて深く議論でき、これは大きな学びとなりました。私自身、知見が十分でなかった自動計装などについて多角的な視点から議論を深められ、今後のインフラ基盤の方針を考える上で貴重な知見を得られました。
今回のカンファレンスは全体を通してハイレベルなセッションばかりでした。その中でも特に印象に残ったセッションについて、イベントに参加したメンバーから紹介します。
キーノートセッションでは、現代の複雑なシステムに対してオブザーバビリティをどう活用すべきかについて具体的な実践例を交えて紹介されていました。オブザーバビリティはビジネス成功をサポートするための手段であり、これを実現するためにはSREやオブザーバビリティチームとしての立場にこだわるのではなく、ユーザーが直面している課題に目を向けることが重要です。そのため、オブザーバビリティの導入はまずユーザー体験を測定することから始めるべきであり、「誰かがシステムを利用するたびに、その人にとっての成功とは何か」を深く考えて組織全体で導入・展開することを支援するのが最も効果の高い活動だと再確認しました。
より実践的な内容としては、これまでのメトリクスやログ中心のアプローチではコスト増と認知的な複雑さが増すという課題を指摘されていました。この課題に対して「データを減らす」という方針が提示され、複数のログをただ出力するのではなく、必要な属性をすべて持ったトランザクションごとの1つのイベントを生成すべきという具体例が提示されていました。この点は、私もオブザーバビリティの取り組みを進める中で感じていたことだったため共感できました。さらに、コストを最適化しつつ要件を満たすカギとして、サンプリング戦略について紹介がありました。システムを通過するトラフィックの大半が正常で似通っていることを踏まえ、すべてのエラーと遅いトランザクションは100%記録し、正常なトラフィックを削減する Tail-based sampling について述べられていました。
総じて、今回のキーノートセッションからウォンテッドリーで推進しているオブザーバビリティの考え方や活用方針が間違っていないことを確認できました。さらに、コストを管理しながら必要なデータを保持するという Tail-based sampling 戦略のベースとなる考え方はデータ活用の戦略全般に応用が利きそうで、新しい知見として大変学びになりました。今回学んだ知見をもとに、オブザーバビリティを単なるコスト削減ではなく投資として捉え、さらなる価値の最大限を目指して取り組んでいきたいと感じました。
このセッションを聴こうと思ったのは、私自身が「我々は本当にオブザーバビリティツールを使い切れているのか」と疑問を抱いていたからです。特に登壇者の「オブザーバビリティツールでモニタリングをしていただけなのではないか」という問いかけに胸を打たれ、私たちの現場でも同質の悩みがあると感じました。日々の運用では問題が起きたときだけダッシュボードを開き、解決を優先して経験で埋め合わせることが少なくありません。このセッションは、そうした「問題対応の計器」に閉じた使い方を離れ、オブザーバビリティを開発者の理解と好奇心を育てる装置として日常に織り込む視点を与えてくれました。
登壇者の @maru さんは LINEヤフーでSREをされています。LINE アプリ内のワークロードは読み取りが支配的で、他のサービスから取得したコンテンツを集約・UIとしてレンダリングしており、突発的なアクセスや想定外のアクセスにも耐える必要があるそうです。「あけおめスタンプ」などがイメージしやすいですね。オブザーバビリティの基盤自体は一通り整えていたものの、日常的に活用する文化までは根づいておらず、主にトラブル時だけ参照する傾向がありました。さらにリリース後しばらく大きな障害が起きなかったことで、観測指標のキャリブレーション機会が得にくく、ツールが「健全性監視のためのモニタリング」に寄りがちで、開発者のメンタルモデル更新につながりにくいという課題感があったそうです。
発表の中では、Embedded 型の SRE チームとして開発チームに参加する中での気づきと取り組みが共有されました。中でも私が大きな学びを得られた部分について紹介します。
まず、SRE と開発者でメンタルモデルが異なるという整理が腑に落ちました。開発者はコードや仕様を起点に理解を組み立て、SRE はダッシュボードを起点に健全性を把握します。このようなシステムを理解するためのアクションの差はメンタルモデルの形成に影響しており、DevOps のサイクルの違いと一致していることに気づいたそうです。このように整理すると、実際にユーザーが触る環境や計器の多くは Ops のサイクル側にあるため、オブザーバビリティは自然と Ops で拡充されやすいのだと説明されていました。その結果として、開発者が日常の開発で触れる機会は乏しく、障害やリリースといった限られた場面で必要な分だけ使う状態にとどまりがちです。こうした前提に対して、開発者がシステムをより正しく理解するには、オブザーバビリティを Dev のサイクルの中で使えるようにする必要がある、という考えに至ったそうです。
さらに、Alert rule as Code の実践はすぐにでも取り入れたい学びでした。アラートを Terraform などでコードとして管理し、ポリシーチェックを CI に組み込むことで、ルールが暗黙知化せず変更履歴も追跡できます。開発環境でも動く軽量なアラートを整えておけば、違和感の早期検知が日常の開発に自然に接続されます。合わせて、レイテンシーをヒストグラムで扱い、時系列が爆発しないよう必要な領域だけ解像度を高める工夫や、スクレイピング間隔を短くして検知を俊敏にし、明白な異常は自動ロールバック、判断が割れる場面はデプロイ一時停止と通知で人が介在する、といった運用設計も、観測を意思決定に直結させる具体策として参考になりました。ユーザー体験は正常と異常の二値ではなくグラデーションであるという前提で、キャッシュやフォールバック、タイムアウト、SLO を意図を持って設計し直す姿勢も実務的でした。
これらの示唆を踏まえ、我々の組織でもすでにある仕組みを有効活用しながら、開発者がオブザーバビリティでシステムを理解し、分解し、再構築できる体験を推進し続けたいと感じました。具体的には、弊社でもすでに実現できているPRのプレビュー環境や、リリース時のダッシュボード確認（Canary Release）を、開発者のサイクルにより深く組み込む取り組みを進めたいと考えました。また、すぐに実施できる負荷試験のインフラや問題発見のしやすいメトリクスの整備など、開発者が「遊べる」環境作りも進めていくことで、オブザーバビリティが開発者の好奇心を支える当たり前の土台が整備され、DevOps を深化させることができるのではないかと感じました。
今回のカンファレンスで個人的に印象的だったセッションの一つが、オブザーバビリティの成熟度を体系的に評価し、チームの改善に繋げていくという取り組みでした。
登壇者が紹介していた組織の課題は、とても共感できるものでした。チーム間でオブザーバビリティへの理解や実践レベルにばらつきがあり、運用が属人化してしまう。結果として、同じ問題が繰り返されてしまう。これはどんな組織でも起こりうる話だと思います。
そこで彼らは、CMMI（Capability Maturity Model Integration）をベースにした独自の評価フレームを作成し、以下の6項目を設定し、アンケートを通じて各チームの評価をこないました。
成熟度は5段階で整理され、「今の自分たちはどのレベルにいるのか」を可視化できるようになっていました。さらに、各レベルでの評価結果に基づき、レベル別の改善アクションプランを用意。これにより、次に何を改善すべきかが明確になり、チームごとのフェーズに合った取り組みが可能になったそうです。
特徴的だったのは、完璧を求めず、レベル+1を目指すというスタンスでした。たとえば、あるチームでは「アラート最適化と障害対応」のスコアが低かったため、アラートルールの棚卸しや深刻度の分類、対応優先度の明確化といった具体的なアクションを実施していました。
さらに印象的だったのは、そこから生まれたチームの変化です。監視がうまくいっていないと漠然としていた課題が、「アラート最適化がレベル1だから動的閾値を導入しよう」と、より明確な改善につながるようになったそうです。また、評価結果をもとに自然に建設的な議論が生まれ、「なんとなく改善しなきゃ」から「次はここを良くしよう」へと、チーム全体の意識が変わっていったそうです。
日々の業務の中で改善活動の優先度を上げるのは難しいものですが、このように現状を可視化し、小さな改善を積み重ねていく文化は非常に素晴らしいと感じました。
今回のカンファレンスはどのセッションも面白く、オブザーバビリティの最新動向と実践的な知見を幅広く学ぶことができました。その中でも特に実践的な学びに繋がった「LLM オブザーバビリティにおけるトレースの拡張」を紹介します。
LLM アプリケーションの開発・運用が広がる中で、従来のオブザーバビリティの考え方をどのように適用すべきか、という問いに直面している方も多いのではないでしょうか。このセッションでは、LLM 特有のオブザーバビリティの課題と、OpenTelemetry におけるセマンティック規約 (Semantic Convention for GenAI Systems) の取り組みについて紹介されていました。
LLM アプリケーションは従来のシステムと比べて特徴的な課題を持っています。まず、LLM は非決定的な性質を持つため、同じ入力に対して出力が一定ではなく、テストやデバッグが困難です。さらに、キャッシュ、ツール呼び出し (Tool Calling)、RAG (Retrieval-Augmented Generation) といったコンポーネントが増えがちで、タスクによって複数の LLM を使い分けたり、フォールバックや負荷分散の仕組みも必要になります。加えて、トークン消費によるコスト管理も重要な要素となります。
こうした複雑性に対応するため、OpenTelemetry では生成 AI 向けのセマンティック規約が定義されつつあります。この規約では、イベント (モデルへの入力や応答の記録)、メトリクス (トークン数など)、スパン (モデルスパン、エージェントスパンなど) を構造化して記録する方法が提案されています。特定のサービス (Amazon Bedrock など) 向けの規約も一部定義されており、エコシステム全体での標準化が進められています。
ウォンテッドリーではすでに生成 AI を活用した機能を本番環境で運用しています。(詳細な話は、弊社開催の Wantedly Tech Night #13 - Amazon Bedrockを用いたコンテンツモデレーションとプロフィール自動生成 でも紹介しました。ぜひあわせて登壇資料をご覧ください。) この生成 AI 機能の品質を向上させるためにも、オブザーバビリティが必要ではないかと考えていました。以前参加した Datadog Summit Tokyo 2025 でも Datadog LLM Observability の便利さを実感していたのですが、現状では Ruby がサポートされておらず、実際の導入に踏み切れずにいました。しかし、今回のセッションで OpenTelemetry による標準化が進んでいることを知り、将来的には Datadog APM を活用しつつ、LLM 特有の計装部分だけ別のツールを組み合わせるといった柔軟な構成も可能になるのではないかと期待が持てました。
登壇者と 1 対 1 で質問できる機会である、セッション後の Ask the Speaker でも質問させていただき、私たちのユースケースに基づいた具体的な計装方法について深く議論できました。たとえばオブザーバビリティのために LLM Gateway (LiteLLM) を利用する方法や、LLM を中心としたオブザーバビリティツールとしても利用できる Langfuse を教わりました。また、Ruby での OpenTelemetry + LLM での計装ライブラリである openllmetry-ruby も紹介していただき、実務で活用できそうな知見をいただけたのは大きな収穫でした。
このセッションを通じて、LLM オブザーバビリティは従来のオブザーバビリティとは異なる考え方が必要であり、OpenTelemetry を中心としたエコシステムでの標準化が進んでいることを学びました。今後さらに LLM を活用したサービスを展開していく中で、適切な計装とモニタリングの仕組みを早期に整備することが重要だと感じました。具体的な計装手法まで知れ、非常に有意義なセッションでした。
Observability Conference Tokyo 2025は、非常に刺激的で貴重な学びの場となりました。スポンサーとしてだけでなく、参加者としてもレベルの高い議論に触れられたことは、新しい知見が得られただけでなく、私たちのオブザーバビリティに対する理解を深めることにも繋がりました。今回のカンファレンスを通じて、私たちの先進的な取り組みが業界のトレンドと一致していることも確認でき、大きな自信となりました。今後もさらに一歩踏み込んだ改善を進め、コミュニティに還元していきたいと思います。
このような貴重な機会を提供してくださった関係者の皆様に感謝申し上げます。次回があれば、ぜひまた参加したいと考えています。
ウォンテッドリーでは、技術負債の解消や開発プロセスの改善はもちろん、エンジニア一人ひとりがより価値の高い仕事に集中できる環境を提供することを目指しています。私たちは、このようなチャレンジに共感し、共に次世代のプラットフォームを作り上げてくれるSREやDevOps Engineerを募集しています。少しでも興味をお持ちいただけましたら、「話を聞きに行きたい」ボタンからぜひお気軽にご連絡ください。
/assets/images/7052304/original/49100b17-5866-4cec-b50b-a37ea73565e9?1638782149)
/assets/images/5673658/original/767e046d-422d-44e3-ac17-74af4a96146e?1709547072)
/assets/images/7053725/original/28d1b135-13b4-4f46-895f-d5f5fb5ae243?1624246858)
