可観測性は開発環境から、開発環境にもオブザーバビリティ導入のススメ

Observability Conference Tokyo 2025 (2025年10月27日) 登壇資料

登壇者
Yuzuru Ohira (@joe_yuzupi)
LayerX Ai Workforce事業部 テクニカルプロジェクトマネージャー

セッション概要
「本番環境のオブザーバビリティは大事」。誰もがそう言います。でも、日々の開発で「なんでこれ動かないんだ…」と途方に暮れた経験はありませんか？私たちは、開発環境こそオブザーバビリティ導入の第一歩だと信じ、私の所属するLayerXのAI・LLM事業部でその実践に挑んできました。

本セッションでは、オブザーバビリティがなかったことで起きた苦労したことや、そしてそれを乗り越えるために開発環境にオブザーバビリティを導入したことで、いかに開発が楽になったかをお伝えします。さらに、その小さな改善が最終的にサービスの品質向上にどう繋がったのか、具体的な事例を交えてお話しします。

Transcript

1. © LayerX Inc. 可観測性は開発環境から 開発環境にもオブザーバビリティ導⼊のススメ Observability Conference Tokyo 2025 Joe / LayerX
2. © LayerX Inc. 2 Joe (Yuzuru Ohira) About Me • 株式会社 LayerX Ai Workforce 事業部 テクニカルプロジェクトマネージャー • 某外資企業 → 2025/7~ 現職 • 愛知住み(今朝来ました🚄) • 趣味: ゴルフ(年間40ラウンド前後)
3. Ai Workforce について
4. © LayerX Inc. 4 会社紹介
5. © LayerX Inc. 5 出典: 3M. (2024). 3M 2023 Annual Report. U.S. Securities and Exchange Commission. https://www.sec.gov/Archives/edgar/data/66740/000130817924000309/mmm4298631-ars.pdf
6. 6 © LayerX Inc. 製造・自動車 ・法令、論文、規制情報の調査 ・機微情報の自動マスキングによる情報共有 ・製品が法令や規格に適合するかどうかのレビュー 金融 ・融資稟議書のドラフト作成、情報転記、内容レビュー ・取引先のリスクアセスメント、監査 ・広告ガイドライン審査 ヘルスケア ・法令 (薬機法) 、論文、規制情報の調査 ・社内プロジェクト (基礎研究、非臨床試験、治験等) の整理と共有 不動産 ・契約書からの情報抽出、情報転記、システム連携 ・法令、規制情報の調査 ・申し込み情報、アンケート情報の内容レビュー、情報転記 ⾦融や製造、ヘルスケア等の業界における様々な⽂書処理業務が中⼼。 Ai Workforceの主なユースケース ※トライアル中のケースも含みます。
7. ⽬次 Agenda • Join 時のオブザーバビリティ環境 • 解決したい課題‧おこなったこと • 得られたもの‧⾒つかった課題 • これから
8. 開発環境、⾒える化してますか？󰢧
9. © LayerX Inc. 9 開発体制 今⽇お話する開発環境の定義 ※⼀部ローカルについて触れる箇所があります
10. ⼊社時のオブザーバビリティ環境
11. © LayerX Inc. 11 検討⾃体はあったが導⼊まで進んでいない状況 オブザーバビリティの検討状況 ADR & Design Docの存在 他の優先タスクの取り組み ※画像引⽤: いらすとや
12. © LayerX Inc. 12 起きていた問題 機能とアーキテクチャの⼤刷新で様々な開発上の問題が浮上 https://prtimes.jp/main/html/rd/p/000000543.000036528.html
13. © LayerX Inc. 13 発⽣していた課題 • 元々開発が不安定と⾔われていてオブザーバビリティ⾃体の導⼊に対しての機運はあった • OpenAI に繋がらない、Redis や CosmosDB に接続できないなどありとあらゆる問題が発⽣していた • Azure 経験者が少ない中で上記のような事象に対しての効率的なトラブルシューティング⽅法が無 かった 具体的に起きていた問題 オブザーバビリティで解決し ようそうしよう
14. © LayerX Inc. 14 オブザーバビリティの意思決定 • 当初はある程度時間を使ってじっくりと実施していこうと考えていたが起きている問題が深刻そう かつこの状態が続くと⾜元⾮常に重くなってしまうので優先して解決する⽅向に舵を切った • 開発環境をライトに⼊れて本番環境をがっつり⼊れていくという選択もあったが開発環境でのオブ ザーバビリティがしっかり整理されていないと開発環境で不具合が起きた際にボトルネックになっ てしまうので重点的にケアする形で取り組んでいく • 開発環境でやれていれば本番環境にもスムーズにも導⼊できるかつ同じフローで⾒れるのでは！？ という仮説もあったため上記の判断に⾄った 先に開発環境のオブザーバビリティを⾼めるアクションをする 意思決定
15. とにもかくにも⾒える化
16. © LayerX Inc. 16 可視化 • ログやメトリクスよりも単⼀の情報をトレースすることの効果が⾼いことがある程度予測できてい たので APM を導⼊することを最優先で実施 • ログ⾃体を連携してしまうことで同じことが基盤を変えても起きてしまう可能性を考慮してあえて 連携しない選択をしている → 現在はある程度トレースの基盤が出来ていているのでログを連携してトレースとの相互連携がで きる状態を作ってもいいかなと考えている • APM としては Datadog APM を使⽤ APM や RUM を使った⾒える化 https://www.datadoghq.com/
17. © LayerX Inc. 17 Web(Next.js) どこに⼊れるべきか ⼀番効果がでる導⼊先はどこか？ Python  (API & AI Agent) Python(Worker) Python (Orchestrator) 全部⼊れるがてっとり早い
18. © LayerX Inc. 18 トレース最優先 • 開発環境はリクエストがあってもサンプリングによって⾃分の処理が収集されていないという状況 が起こる可能性が低いので⾃分がリクエストした処理が⾒やすい • トレーシングが単⼀のリクエストの情報アクセスのしやすさが⾼いのでトレースを優先することで 利便性が増すのではと考えた 開発環境のオブザーバビリティで優先するならトレース
19. © LayerX Inc. 19 オブザーバビリティ駆動開発 オブザーバビリティ駆動開発 https://www.honeycomb.io/blog/observability-driven-development トレースを⾒る どのようなスパンができるか 本番で⾒る スパンを作成する • どのようなサービスで、どのような新しいスパンが期待できるかを考えてみる • アーキテクチャは日々のコーディングの中で構築されるため、どのようなスパンが でるかを念頭に置くのは意図したアーキテクチャ実現に役に立つ • まず今あるトレースを見て、これから作る機能がどの部分に影響を与えるかを想 像する • この「差分を意識する」ことで、どのサービスや処理に新しいスパン（トレースの中 の個々の処理単位）を追加すべきかが見えてくる • もしトレース上で「見えない」箇所があるなら、それは 計測（ instrumentation）を追 加するタイミング • スパンに属性を追加し、必要に応じて新しいスパンを作成し、ローカル開発中にト レースを確認する • printfデバッグよりも時間がかかるかもしれませんがそこで設定されたものは 本番環境でも動作する • 機能がリリースされたら、本番環境でこれらのトレースを必ず確認する • 予期せぬことが起こったとき、ローカルデバッグで使⽤したすべてのコンテキ ストを本番環境に適⽤できる
20. 出てきた成果
21. © LayerX Inc. 21 • ⽇々新しいコードがメインブランチにマージされて機能が開発環境で変わっており社員でもその変 化を完全に追いきれていない状況が起きている⽇常の中で動かない、エラーが起きるというのは想 定される事態 • APM が導⼊されているおかげで⾃分のローカルやログのコンソールでここまではうまくいっている と⽬grep をしてデバックすることなく⼀連の処理としてここまでは動作していると問題の切り分け ができるので Datadog ⾃体で解決できなくても情報の整理ができるようになった • 上記の情報を個⼈の環境だけで⾒れる状態にせずチームメンバー全体で⾒れることによって情報共 有コストの低減も期待できる ◦ →⾃発的に⾒てくれている⼈も増えてきていますがまだ完全に浸透しきっていないので 改善できる点があります 開発サイクルで出てきた不具合の改善
22. © LayerX Inc. 22 • スピードを優先して機能提供をしていたので品質とトレードオフで開発をしている側⾯はスター トアップなので当然ある • 開発環境で事象⾃体が⾒えていてれば機能は提供されつつ改善も⾏えるというサイクルができる のでスピードと品質を⻑い⽬で⾒て犠牲にしない体質を作れる • 例) N+1 等 潜在的に問題になりそうな箇所の発⾒
23. © LayerX Inc. 23 デバック⾯のメリット デバック性の向上 • Ai Workforce は FDE や営業含めて事業部の⼈が開発環境等で積極的にプロダクトを触っている 背景があり期待通りに動作してないということが起きがちな環境である • LLM の応答性能などは開発環境でもわかりやすいのでそれらを把握したうえで開発するなども 考えることができる • 実際に処理が⾏われていた ID などを APM に連携しておくことでどの処理かわかるのでどこで エラーになっているかどこのタスクで処理が詰まっているのかなどがわかりやすい状態になっ た
24. © LayerX Inc. 24 計測の⼯夫 • トレースに対してカスタム属性を付与させることでトレース⾃体の情報の利便性を向上させる ◦ 例) リクエストID、ユーザーID、タスクIDなどを付与することでどの処理かの特定が容易に なった カスタム属性を使ったトレースの利便性向上 https://docs.datadoghq.com/tracing/trace_collection/custom_instrumentation/python/dd-ap i/?tab=decorator#adding-tags
25. © LayerX Inc. 25 Otel API • Span のカスタム計測や Span 属性のカスタム部分を Otel API で実装 • Datadog APM は Otel API のサポートをしており共存が可能なのであまり意識せずとも利⽤可能 • ローカルで Otel 計測することで近しい体験もできるように整備している Otel API を使った計測の柔軟性向上 https://docs.datadoghq.com/tracing/trace_collection/custom_instrumentation/python/otel/ https://zenn.dev/k6s4i53rx/articles/ddtrace-supports-otel-api
26. © LayerX Inc. 26 課題 • SLIにしたい箇所の計測 • Cursor などとの IDE 連携や Datadog MCP、ソースコード連携などでまだま だ利便性を⾼められる箇所はあるので 改善を進める • Datadog 利⽤者ガイドの作成などをし て利⽤時の疑問点を削減する取り組み を試しています 課題
27. © LayerX Inc. 27 これからやること • 観測範囲の拡⼤ ◦ RUMの本格運⽤（現在は試験的導⼊） • ログとトレースの相互連携 • 開発サイクル全体での活⽤ ◦ 開発環境で培ったノウハウを商⽤環境でも活⽤ ◦ 開発‧ステージング‧本番環境全体での統⼀的なオブザーバビリティ基盤の確⽴ • AI Agent のオブザーバビリティ これから
28. © LayerX Inc. 28 まとめ • 開発環境のオブザーバビリティを⾼めようという話をしました • 本番環境のオブザーバビリティはもちろん⼤事ですがその⾜回りを⽀えている開発段階でのオブ ザーバビリティも同様に⾮常に重要です • チームのメンバーの知る⼒が⾼まります • 開発環境のオブザーバビリティを整えていくことでそのナレッジがそのまま商⽤環境にも活⽤でき ます、明⽇から開発環境にもオブザーバビリティ投⼊しましょう まとめ
29. © LayerX Inc. 29 採⽤情報 ⼀緒に働く仲間を募集しています！ https://jobs.layerx.co.jp/business/aiworkforce/
30. © LayerX Inc. 30 カジュアル⾯談 カジュアル⾯談よりもカジュアルに話しましょう https://jobs.layerx.co.jp/opendoor/293cdd370bae8094b50be25 94fc11d76/