Zipkinのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

Zipkinのシステム開発は、分散したサービス間のリクエストを追跡できる状態に整え、障害の切り分け時間を短くするための可観測性基盤を段階的に作る進め方です。

ただDockerでZipkinを起動するだけでは、本番運用で必要な計装範囲、ストレージ、サンプリング、権限、バックアップ、OpenTelemetryとの接続方針まで決まりません。本記事では、要件整理、方式選定、設計・開発、テスト、稼働、定着の6フェーズに分けて、判断基準、費用の考え方、見積もり時のチェックポイントを具体的に解説します。

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

Zipkinのシステムとは何ですか？全体像を確認します

Zipkinは、マイクロサービスや分散システムを通過する1つのリクエストを追跡するオープンソースの分散トレーシングシステムです。販売管理やERPのように業務データを処理するシステムではなく、遅延やエラーがどのサービスで発生したかを可視化する運用基盤です。

たとえば、利用者が注文画面を開くと、APIゲートウェイ、認証、注文、在庫、決済、通知の各サービスが連携します。画面が遅いとき、ログだけでは複数サービスの処理時間を追いにくい場合があります。Zipkinでは、処理全体をtrace、個々の処理をspanとして記録し、共通のtrace IDを手掛かりにタイムラインを確認できます。DBの待ち時間、外部APIの応答、リトライの発生箇所を同じ画面で把握できる点が特徴です。

ログは発生した出来事の詳細、メトリクスはCPU使用率や応答時間などの時系列の数値、トレースは1リクエストが複数の処理を通過した経路を表します。Zipkinだけで監視が完結するわけではなく、メトリクスで異常を検知し、トレースで遅い経路を絞り込み、ログで具体的なエラー内容を確認する役割分担が現実的です。導入前に「何を検知し、何を追跡し、どのログへ結び付けるか」を決めることが重要です。

構成要素は、アプリに組み込むtracerまたはinstrumentation、spanを送るReporter、受信するZipkin collector、検索用API、Web UI、保存先のstorageです。OpenZipkin公式のアーキテクチャでも、計装したアプリがHTTPやKafkaなどでcollectorへ送信し、collectorが保存・索引化したデータをquery serviceとWeb UIが参照する構成が示されています（出典: OpenZipkin公式アーキテクチャ、2026年確認）。

検証環境ならDockerで9411番ポートのZipkinを起動し、2〜5サービスをつなぐ方法で十分な場合があります。一方、本番ではCassandra、Elasticsearch、MySQLなどの選択肢、バックアップ、保持期間、負荷分散、UIの認証を別途設計します。公式情報にもWeb UIに組み込み認証がない旨が示されているため、ネットワーク制御や認証プロキシを含めて要件化する必要があります。

Zipkinのシステム開発の進め方を6フェーズで解説します

Zipkin導入は、ツールを先に決めると計装漏れや過大なデータ量が起きやすくなります。先に業務上の課題と対象範囲を定め、PoCで確かめ、本番設計へ広げる順番が安全です。ここでは、企画だけで終わらせず運用担当への引き渡しまで含めた6フェーズを説明します。

最初に「Zipkinを入れること」ではなく、解決したい業務課題を文章にします。たとえば「注文APIの95パーセンタイル応答時間を確認できるようにする」「障害の平均切り分け時間を短くする」「重要業務フローの何割でtraceを検索できるようにする」といった指標です。現状の障害対応で、検知から原因特定まで何分かかっているかを測っておくと、導入後の効果を評価しやすくなります。

要件整理のチェック項目は、対象業務、入口となるAPI、関係するサービス、利用言語、フレームワーク、メッセージング、外部SaaS、現在のログ基盤、想定リクエスト数、必要な保持日数です。さらに、誰がどの時間帯に見るのか、個人情報やアクセストークンをspanに入れないルール、障害時の連絡先も決めます。ここで「全サービスを初日から計装する」と決めず、利用者影響の大きい2〜5サービスから始めると検証しやすくなります。

方式選定では、Zipkin OSSを自社運用するか、商用APMを使うか、両者を比較します。自前Zipkinはデータの保管場所や検索環境を管理しやすく、ライセンス費用を抑えやすい反面、ストレージ、可用性、アップデート、UIの認証、障害対応を自社で担います。SaaSは運用負担や検索機能を抑えやすい一方、取り込み量、保持期間、ユーザー数、ホスト数などの料金条件とデータ所在を確認する必要があります。

新規案件では、アプリをOpenTelemetryで計装し、OpenTelemetry Collectorを受け口にする構成が有力です。Collectorはreceiverで受信し、processorでサンプリングや属性削除を行い、exporterでZipkinや商用バックエンドへ送れます。OpenTelemetry公式も、Collectorはテレメトリの受信・処理・複数宛先への送信を担うベンダー中立の実装と説明しています（出典: OpenTelemetry Collector公式ドキュメント、2026年確認）。将来バックエンドを変更する可能性があるなら、アプリと保存先を直接結び付けない設計が判断材料になります。

設計では、trace contextをどの通信経路で引き継ぐかを決めます。同期HTTPだけでなく、Kafkaなどの非同期メッセージ、バッチ、リトライ、外部API、ジョブキューを洗い出し、親子関係が途切れる箇所を確認します。JavaやSpringならBrave、Micrometer Tracing、OpenTelemetry SDKなどが候補になり、Node.js、Python、Goでも対応ライブラリを選べますが、フレームワークの自動計装範囲は事前検証が必要です。

同時に、service.name、環境名、バージョン、HTTPメソッド、ステータス、エラー、trace IDのログ出力形式を標準化します。サンプリングは全リクエストを保存するのではなく、通常時はhead samplingで一定割合を採取し、障害や高レイテンシーを残したい場合はtail samplingも検討します。URLのクエリ、顧客名、メールアドレス、認証ヘッダーをそのまま属性へ入れない設計にし、TLS、RBAC、保存期間、バックアップ暗号化も設計書へ含めます。

テストでは、画面にトレースが表示されるだけで合格にしません。正常な注文処理、遅いDB、外部APIのタイムアウト、HTTPエラー、リトライ、サーキットブレーカー、非同期処理の遅延を再現し、どのspanを見れば原因を判断できるかを確認します。ログのtrace IDからZipkinのtraceを検索できること、Zipkinのtraceから該当ログへ戻れることも試験項目にします。

負荷試験では、通常時だけでなくピーク時のspan数、collectorのCPU・メモリ、storageの書き込み、検索応答時間、アプリへのオーバーヘッドを測ります。採取率を100パーセントから下げた場合に、重要なエラーが残るかも確認します。バックアップから復元できるか、権限のない担当者がtraceを閲覧できないか、機密情報がタグやログに混入していないかまでテストして初めて、本番投入の判断ができます。

稼働時は、まず開発環境、次にステージング、最後に本番の一部サービスという段階リリースが安全です。いきなり全サービスへ計装すると、データ量の急増や属性名のばらつきが見えにくくなります。最初の本番対象は、利用者影響が大きく、入口から下流まで追跡しやすい業務フローを選び、採取率、保持日数、検索権限、障害時の連絡先を運用手順書に明記します。

稼働後に見るべき指標は、collectorの受信・送信失敗、storageの使用量、trace検索の応答時間、spanの欠落率、アプリのレイテンシー、月間データ量です。サンプリングを変えたときの費用と診断能力の変化も記録します。Zipkin UIに認証がない構成では、社内ネットワークだけに閉じる、認証プロキシを置く、VPNやゼロトラスト経由にするなど、組織のセキュリティ標準に合わせた公開範囲が必要です。

定着の鍵は、Zipkinの画面を置くだけでなく、障害対応の標準手順にtraceを組み込むことです。アラートを受けた担当者が、サービス名と時間帯からtraceを検索し、最も遅いspan、エラーのspan、関連ログ、デプロイ履歴を確認する流れをランブックにします。月1回程度の障害訓練で、trace IDを使った調査が実際にできるかを確かめると、担当者による使い方の差を縮められます。

運用引き継ぎでは、構成図、計装対象一覧、属性の命名規則、サンプリング方針、保持期間、バックアップと復元手順、アップデート計画、問い合わせ先を納品物に含めます。OpenTelemetryが2025年12月にZipkin exporter仕様を非推奨化し、既存の安定版は少なくとも2026年12月までセキュリティ修正などの対象とされています（出典: OpenTelemetry「Deprecating Zipkin Exporter」、2025年12月公開・2026年確認）。新規開発ではOTLPまたはCollectorを軸にし、既存構成は影響範囲を見ながら段階移行する方針が現実的です。

Zipkinのシステム開発にかかる費用相場とコストの内訳

Zipkin単体の国内受託開発価格を示す公的な統計は確認できません。そのため以下は、業務システム全般の相場と、Zipkinが担う範囲が業務システム全体より狭いことを踏まえた編集用の推定レンジです。対象サービス数、開発言語、Kubernetesの有無、既存ログ基盤、保存量、SLA、夜間対応によって大きく変わるため、固定価格として断定せず、見積もりの初期目安として利用します。

学習・PoCなら、Dockerでの起動、2〜5サービスの基本計装、正常系と異常系の確認、簡単な報告書までを含めて50万〜200万円程度が編集用の推定レンジです。期間は2〜6週間程度が一つの目安です。小規模本番では、5〜20サービス、認証、TLS、永続ストレージ、バックアップ、ダッシュボード、手順書まで含めて300万〜800万円程度、期間は1〜3か月程度を想定します。

20〜100サービスを対象に、OTel Collector、Kubernetes、サンプリング、負荷試験、既存計装からの移行まで行う中規模本番では、800万〜2,000万円程度、3〜6か月程度の推定レンジになります。複数クラスタやリージョン、高可用性、長期保持、SIEM連携、24時間運用まで求める大規模案件では、2,000万〜5,000万円以上、6〜12か月以上になる可能性があります。いずれもサービス数と運用要件を分けて確認する必要があります。

費用の中心は、Zipkinサーバーのライセンスではなく、要件整理、アプリ計装、Collector設定、ストレージ設計、セキュリティ、負荷試験、運用教育の人件費です。業務システム一般の技術者単価として1人月50万〜150万円程度を参考にする場合、PoCは1〜2人、小規模本番は2〜4人、中規模以上はPM、SRE、アプリ開発者、インフラ担当を含む混成体制で工数を見積もります（出典: NotebookLM「業務システム全般_16」の一般相場整理、2026年確認）。

特に見落とされるのは、サービスごとに異なるフレームワーク、非同期処理、外部API、ログ形式を合わせる作業です。計装のコード変更だけを見て見積もると、テストと運用設計の費用が後から増えます。見積書では、要件定義、計装、Collector、storage、UI・認証、試験、ドキュメント、教育を分離してもらうと、削る範囲と残すべき範囲を判断できます。

OSSを使っても、クラウドやサーバー、ストレージ、バックアップ、監視、アップデート、保守担当者の費用は発生します。自己運用の月額は、小規模で20万〜60万円、中規模で60万〜200万円程度を編集用の推定レンジとします。初期開発費の年15〜25パーセントを保守費の参考にする考え方もありますが、トレース量が増えるとストレージ費が大きく変わるため、年率だけで決めないことが大切です。

商用サービスとの比較では、New Relicが月100GBまでのデータ取り込みを無料とし、超過分のOriginal Dataを1GBあたり0.40ドルと公開しています（出典: New Relic公式料金ページ、2026年確認）。Grafana Cloudの新規顧客向けApplication Observabilityは、2026年2月13日以降、ホスト時間に加えてトレースなどを1GBあたり0.50ドルとする料金モデルを案内しています（出典: Grafana Cloud公式料金ページ、2026年確認）。DatadogもAPMホスト料金や取り込みGB、Indexed Spansの保持日数別料金を公開しています。

これらは米ドル建てや契約条件、為替で変わるため、日本円の月額を断定できません。自前運用とSaaSを比較するときは、1日あたりのspan数、平均spanサイズ、採取率、保持日数、検索対象期間、利用者数を同じ前提で試算します。100パーセント採取から10パーセント採取へ変更するとデータ量は単純には減りますが、重要なエラーを残せるかは別途検証が必要です。

導入方式と将来性を判断するチェックポイント

Zipkinを残すか、商用APMへ寄せるかは、無料か有料かだけで決められません。障害対応に必要な検索、運用体制、データの保管場所、既存ツールとの連携、将来のサービス追加を同じ評価軸で比べます。短期のPoCはZipkin OSS、長期の標準化はOpenTelemetryとOTLPを軸にし、保存先を柔軟に選ぶ考え方が現実的です。

自前運用に向くのは、クラウドやKubernetesを管理でき、保存先やネットワークを自社の基準で細かく制御したい企業です。SaaSに向くのは、短期間でログ・メトリクス・トレースの相関を始めたい企業、24時間の基盤運用を自社だけで担いにくい企業です。ただしSaaSでも、テナントのリージョン、契約終了時のデータ返却、保持期間、アクセス監査、従量課金の上限を確認する必要があります。

OpenTelemetryのZipkin exporter仕様は2025年12月に非推奨となり、公式の移行案はアプリからOTLPを送りZipkinのOTLP ingestionを使う方法、またはOpenTelemetry Collectorを経由する方法です。既存のZipkin exporterを直ちに廃止する必要はありませんが、新規の言語SDKで実装が必須ではなくなっているため、今後の保守を考えると古い設定だけを標準にしない方が安全です。

移行は、まず現行のexporter、ライブラリ、trace context、属性名、保存先を棚卸しします。次にCollectorへ一部サービスを向け、Zipkinを出力先として動作を確認し、最後にOTLP対応のバックエンドやSaaSを比較します。切り戻し先、二重送信の期間、データ量の上限、障害時のサポート範囲を決めてから全体へ広げると、移行による観測不能期間を抑えられます。

Zipkinのシステム開発で見積もりを取る際のポイント

見積もりの精度は、Zipkinの知識だけでなく、対象システムの現状をどれだけ具体的に伝えられるかで決まります。開発会社へ相談する前に、サービス構成と通信経路、目標KPI、データ量、セキュリティ条件、運用体制を整理します。価格だけでなく、何を納品し、誰が運用できる状態まで支援するかを比較することが重要です。

最低限、サービス数と名称、言語・フレームワーク、実行環境、Kubernetesの有無、1秒あたりのリクエスト数、ピーク時間、1日あたりのspan量、採取率、保存日数を記載します。分からない項目は「未計測」と書き、PoCで計測する工程を見積もりに含めます。HTTP、Kafka、バッチ、外部APIの通信経路、現在のログ基盤、trace IDをログへ出せるかも、計装工数を左右する情報です。

成果物も、Zipkinサーバー一式だけでなく、構成図、設定ファイル、計装コード、属性命名規則、ダッシュボード、アラート、負荷試験報告書、セキュリティ確認表、運用手順書、教育を分けて書きます。特に「本番で見る画面」「障害時の一次切り分け」「バックアップからの復元」が納品範囲に入っているかを確認します。

複数社へ依頼するときは、対象サービス数、保持日数、24時間対応の有無、OpenTelemetryとZipkinの役割、SaaS利用の可否を同じ条件で提示します。提案の比較軸は、計装・Collector設計、JavaやSpringとKubernetesへの対応、ログ・メトリクスとの相関、OSSとSaaSの中立性、セキュリティ、運用引き継ぎ、SLAです。Zipkin専用の公開実績だけを求めるのではなく、分散トレーシングや可観測性基盤を本番で運用した経験を質問します。

提案会社には「重要なエラーをどの採取率で残すか」「spanに機密情報が混ざったときどう削除するか」「storage障害時にアプリへ影響させないか」「OTLPへ移行する場合にどこを変更するか」を確認します。質問への回答が製品名だけで、データ量や運用手順に触れていない場合は、導入後の追加費用や属人化が起きる可能性があります。

トレースのタグ、baggage、URL、ヘッダーに個人情報、アクセストークン、セッションID、接続文字列、内部ホスト名が混ざると、障害調査用のデータが情報漏えいの原因になります。OWASPのLogging Cheat Sheetでも、アクセストークン、パスワード、暗号鍵、決済情報などはそのまま記録せず、マスク、削除、ハッシュ化、暗号化を検討するよう示されています（出典: OWASP Logging Cheat Sheet、2026年確認）。属性の許可リストとマスキング試験を見積もりに含めることが必要です。

性能面では、全量採取によるアプリのオーバーヘッド、collectorのキュー詰まり、storage容量の枯渇、検索遅延を想定します。運用面では、証明書更新、バックアップ復元、バージョンアップ、障害時のエスカレーション、退職や異動時の権限変更を決めます。これらを「別途相談」とせず、設計・試験・運用支援のどこまで含むかを書面に残すと、発注後の認識違いを防げます。

Zipkinのシステム開発でよくある質問（FAQ）

ここでは、導入を検討する担当者から特に多い質問に回答します。PoCの範囲、費用、OpenTelemetryへの対応を先に確認すると、自社に必要な進め方を判断しやすくなります。

モノリスでも、外部API、複数DB、キュー、バッチなどをまたぐ処理の遅延を追跡したい場合は役立ちます。ただし、単一サービス内の処理だけを確認したいなら、既存のAPMや詳細ログで十分な場合もあります。まず重要な業務フローを1つ選び、Zipkinでなければ解決できない課題かをPoCで確かめることが適切です。

いいえ、OSSのライセンス費用が基本的に無料でも、計装、Collector、storage、クラウド、監視、バックアップ、試験、教育、保守の費用が発生します。PoCなら50万〜200万円、小規模本番なら300万〜800万円程度という推定レンジがありますが、これはサービス数や運用条件から作った目安です。自社のspan量と保持日数を計測し、初期費用と月額費用を分けて見積もる必要があります。

短期的に既存の安定版を使うことは可能ですが、新規設計ではOTLPまたはOpenTelemetry Collectorを軸にする方針が安全です。OpenTelemetryはZipkin exporter仕様を非推奨化し、既存安定版のセキュリティ修正などを少なくとも2026年12月まで継続する方針を示しています。新規案件では、アプリとバックエンドの間にCollectorを置く構成、またはZipkinのOTLP ingestionへ送る構成を比較し、将来の移行計画まで決めてください。

まとめ：Zipkinのシステム開発は運用定着まで設計します

最後に、Zipkin導入を成功させるために押さえておきたい要点と、最初に着手すべき準備を整理します。

Zipkinのシステム開発では、要件整理で目的とKPIを決め、選定でOSS・SaaS・Collectorの役割を分け、設計・開発で計装、trace context、属性、保持期間、セキュリティを固めます。その後、正常系と異常系のテスト、段階リリース、監視、障害訓練、手順書による定着までを一つのプロジェクトとして進めることが重要です。

費用はZipkinのライセンスだけでなく、計装工数、storage、データ量、クラウド、監視、バックアップ、保守で決まります。PoCの推定レンジをそのまま本番費用とせず、サービス数、1日span数、採取率、保持日数、SLAを前提にして複数社へ同じ条件で相談してください。新規設計はOTLPやCollectorを軸にし、既存Zipkinは切り戻し可能な段階移行にすると、将来の選択肢を残せます。

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

会社紹介

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

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

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