はじめに
TRIAL＆RetailAI Advent Calendar 2025 の12日目の記事です。
昨日は@yang_zaiqi さんの「AI時代のチームリーダー進化論」という記事でした。
AI時代のリーダーに求められる役割やスキルを非常に明確に示し、「AIを使う側」から「AIと協働する側」への進化を強く促す内容でした。特に、AIを“チームメンバー”として組織設計に組み込む発想が、これからの開発組織にとって必須だと実感させられます。
さて、自分は今年“今の自分の変化”をテーマに書いてみたいと思いました。
バックエンドエンジニアとして働き始めた頃は、
「データベースから値が返ってきた！すごい！」と毎日が発見の連続でした。
正直、log.debug() を入れておけばだいたいの状況は把握できるし、
それ以上の観測は必要ないと思っていました。
でも開発に慣れていくにつれ、
アプリの速度改善や、ボトルネックの特定、リクエストの流れの把握といった
“より本質的な問題” に向き合う場面が増え、
「ログだけでは見えない世界がある」
ことに気づきました。
メトリクスを取るだけでシステムの振る舞いが数値として見えるようになり、
トレースを入れるだけで1つのリクエストがどのサービスを通り、
どこで遅れているのかまで丸見えになる。
そして、そうした仕組みを OTel を入れるだけで実装できる という事実が
自分の中で大きな転換点になりました。
私の所属するチームでは、
@WithSpanを付けて、トレースをしっかり追えるようにする
という運用ルールがあり、自然と OpenTelemetry（以下 OTel）に触れる機会は多かったです。
しかし正直なところ、
- 何が収集されているのか
- どこに送られているのか
- Collector が何をしているのか
といった部分を理解しないまま使っていました。
今回はそんな私が、
「OTel をちゃんと“使いこなす”側にまわるための学習メモ」
としてまとめた内容です。
同じように OTel を勉強し始めた方の助けになれば幸いです。
1. 「よく分からん」から始まった
最初に OTel を触ったとき、正直こんな気持ちでした。
トレース？ログ？メトリクス？どう違うの？
Collector？Exporter？なぜ必要なの？
@WithSpan を付けたら何が起きてるの？
……まったく分かっていませんでした。
そんな状態だった私が理解する突破口になったのが、Udemy の
OpenTelemetry Foundations: Hands-On Guide to Observability
という講座でした（英語ですが、進めやすくて理解しやすかったです）。
教材の中に hello-telemetry というサンプルがあり、これを自分の PC で動かしてみて初めて、
あっ、メトリクスって “こうやって見える” のか！
と理解が進みました。
この記事では初心者でも実践レベルで理解できるように
「Counter を入れると Collector には何が見えるのか」
を軸に解説します。
2. トレースはサクッとだけ（今回メインじゃない）
▶ NotebookLM トレース動画
※ NotebookLM での再生には Google アカウントへのログインが必要です。
トレースがどのように記録され、Span がどう繋がるかを短くまとめた動画です👇
3. メトリクスとは？（初心者でもつまずかない最短理解）
▶ NotebookLM メトリクス動画
※ NotebookLM での再生には Google アカウントへのログインが必要です。
メトリクスの概念（Counter・Gauge・Histogramなど）が直感的に理解できる動画です👇
4. 実践：Python-service に Counter を入れてみる
教材では、Python サービス（compute-service）に以下の Counter が追加されています。
compute_request_count = meter.create_counter(
name='app_compute_request_count',
description="Counts the requests to compute-service",
unit='1'
)
これは何をしている？
- 名前：
app_compute_request_count - 内容：/compute_average_age にリクエストが来るたびに「+1」
- 種類：Counter（単調増加）
どういう効果がある？
実際にサービスを起動し、/compute_average_age に 2 回アクセスすると
Collector の debug exporter に次のように表示されます。
Descriptor:
-> Name: app_compute_request_count
-> Description: Counts the requests to compute-service
-> Unit: 1
-> DataType: Sum
Value: 2
→ 「このサービスに 2 回アクセスがきた」ことが分かる。
= これがメトリクスの“見える化”の最初の感動ポイントです。
5. Java サービス（tomcat-service）にも Counter がある
Java の方にも Counter が定義されています。
LongCounter dbRequests =
meter.counterBuilder("app.db.db_requests").build();
dbRequests.add(1);
これは何をしている？
- DB操作が行われるたびに「+1」
- アプリ内部の“DBアクセス回数”を可視化するためのメトリクス
Collector ではこう見えます：
Descriptor:
-> Name: app.db.db_requests
Value: 5
→ 「このサービスは DB処理を 5 回行った」が一目で分かる。
Python と Java、言語は違っても
メトリクスの形は完全に統一される のが OpenTelemetry の強みです。
6. OpenTelemetry Collector が何をしているか（超シンプル解説）
Collector は「アプリ → Collector → 可視化ツール」の中心に立つ役割です。
今回の設定では debug exporter が有効なので、
Collector が受け取ったメトリクスがログとして出力されます。
2025-12-06T13:55:22.911Z info Metrics
{"resource": {"service.name": "otelcol-contrib"}, "otelcol.signal": "metrics", "metrics": 1, "data points": 1}
この JSON は 構造化ログ（structured log） と呼ばれ、
機械が読みやすい形式でメトリクスの情報が流れてきます。
👇 下図は「アプリ → Collector → Exporter（ログ）」という
メトリクスが Collector を通って流れるイメージを、ChatGPT で作成した図です。
7. 構造化ログとは？（初心者でも理解できる最短説明）
構造化ログとは “JSON形式のログ” のことです。
普通のログ：
DB connected
構造化ログ：
{
"timestamp": "2025-12-06T13:55:22.911Z",
"level": "info",
"event": "Metrics",
"service.name": "otelcol-contrib",
"metrics": 1,
"data_points": 1
}
構造化ログのメリット：
- 検索しやすい
- 可視化しやすい
- ログ集約ツール（Cloud Logging など）で扱いやすい
- チーム全体で統一的なログが書ける
Collector の出力はこの構造化が中心なので、
分析しやすいログとしてそのまま活用できます。
8. 実務の話：Quarkus はこのあたり全部自動でやってくれる
今回の hello-telemetry では Python/Java のコードに Counter を書きましたが、
実務でよく使われる Quarkus では、この手のメトリクスがほぼ全自動で収集されます。
依存関係を追加するだけで以下が測定される：
- HTTP リクエスト数 / レイテンシ
- DB コネクションプールの使用数
- JVM メトリクス（ヒープ使用量・スレッド数など）
- アプリの稼働状況
- Micrometer 形式のメトリクス
- 構造化ログ（JSON）
つまり、アプリに何も書かなくても
http_server_requests_seconds
jvm_memory_used_bytes
など、よく使う実務メトリクスは依存関係を入れるだけですべて自動で揃うようになっています。
私自身、まさに今 Quarkus への置き換えを進めながら理解を深めている最中です。
まだ検証段階ではありますが、Quarkus の自動計測機能と OTel の相性はとても良さそうだと感じており、
このあたりはまた別の記事としてまとめていけたらと思っています。
9. まとめ：OpenTelemetry を理解する一番の近道
今回 Python と Java の両方で Counter を動かし、
Collector の構造化ログを直接見たことで、
- Counter は「回数」を表すシンプルだが強力なメトリクス
- 言語が違っても同じ形式で Collector に届く
- Collector の debug 出力が一番の教材
といった基本がつながりました。
さらに Jaeger / Prometheus / Grafana をローカルで動かし、
UI でトレースやメトリクスの流れを確認できたことで、
理解が “知識” から “実感” に変わったのも大きかったです。
職場では GCP を利用しているため、
今後は GKE や Cloud Monitoring と組み合わせて、
- アプリ独自のメトリクスを送る
- ダッシュボードを構築する
- 必要なアラートを発報する
といった、より実務に近い形で OTel の活用を深めたいと思っています。
OpenTelemetry は「アプリが何をしているか」を数字で見える化する強力なツール。
この記事が、これから OTel を学び始める方の一歩になれば嬉しいです。
さいごに
明日は@WANG_YUQUAN さんの『「問題を自分で解決する」から「チームで問題を解決できるようにする」へ—— クリティカルシンキングで再考するエンジニアチームマネジメント』という記事です。
普段、つい「自分でなんとかしなきゃ」と抱え込みがちなので、
チームで問題解決する視点を学べるこの記事を読むのが今から楽しみです！
RetailAIとTRIALではエンジニアを募集しています。
興味がある方はご連絡ください！