Internet Infrastructure Review（IIR）Vol.69
2026年3月

近年、システム間で共通の時刻同期を高精度に共有することを前提とするシステムが増えています。例えば携帯電話に代表される移動体通信システム、電力システムでのスマートグリッド、高頻度取引を行う金融システムなどです。これらのシステムは内外の連携において厳密な同期を要求します。時刻もしくは同期精度が不十分な場合、通信制御の不成立、制御信号の誤動作、データの不整合などが生じる可能性があります。

表-1に、産業ごとの時刻同期要求精度の例を示します。

これらのシステムでは、マイクロ秒〜ナノ秒単位の精度が要求されます。これはNTPの精度（一般的なインターネット経由の環境ではミリ秒単位）よりも3桁以上高い精度です。このような高精度時刻同期要求を背景として、IEEEにより PTP（Precision Time Protocol, IEEE 1588） が策定されました。

PTPはネットワーク経由でのリアルタイムクロックの同期を目的としてIEEEによって標準化されました。IPv4、IPv6及びIEEE 802.3 Ethernet上で用いることができます。当初IEEE1588- 2002として2002年に規格化されましたが（PTPv1）、その後IEEE1588-2008でPTPv2が定義されました。PTPv2はPTPv1 との互換性はありません。IEEE1588-2008は更に2019年にIEEE1588-2019として改訂されています。これは非公式にPTPv2.1と呼ばれることがあります。

PTPはサブマイクロ秒レベル、つまりマイクロ秒未満の同期精度をサポートし、一部拡張プロファイル（White Rabbitなど）ではサブナノ秒単位の精度を達成できます。

NTPは階層化された構造（Stratum）で時刻が配信されます。一方PTPは各ノード（PTPインスタンス）が最適なクロックをBMCAと呼ばれるアルゴリズムで選び出した上で、より高精度の時刻を持つMasterから、補正が必要とされるクロックを持つSlaveへ時刻同期が行われる仕組みになっています。PTPインスタンス同士は自律的に時刻同期システムを構成するように設計されています。

なお本稿では規格表記に従いMaster/Slaveという用語を用いますが、最近ではLeader/Followerという表記を使うことが増えています。

なおclockIdentityの生成には、EUI-48のMACアドレスから生成する方法がよく使われています。

表-6のように、MACアドレス前半のOUI （Organizationally Unique Identifier）部分と後半のEI （Extension Identifier）部分に"FF-FE"を挿入する方法です。

AnnounceメッセージはPTP PortがMaster状態にあるPTP インスタンス（PTP GMもしくはPTP BC）のみが送信します。設計によってPTP GMが冗長化されていた場合、上記のアルゴリズムから誰が最良のGMかをそれぞれのPTP GM自身が判断し、自身の状態を遷移させます。選出されなかったPTP GMは、Announceメッセージの送出を停止します。故障や回線断などにより、当初選出されたPTP GMからのAnnounce が流れなくなった場合、選出されなかったPTP GMがBMCA プロセスを経てAnnounceメッセージを送出し始めます。PTPではこのように切り替わりが達成されています。

PTP BCは通常、PTP GMから同期を受け、他のPTPインスタンスにAnnounceメッセージを送出します。しかし、PTP GMとの同期が失われた場合、Announceメッセージ内の各種パラメータを更新し、自身のクロックを基準として同期を提供していることを通知します。例えば、これまで上流のPTP GMの値が設定されていたgrandmasterIdentity は、自身のclockIdentityに書き換えられ、clockClassもHoldover状態を示す値に変更されます。このように直前まで同期していた情報を基に、自身のクロックで時刻同期を継続する状態を「Holdover」と呼びます。PTP機器ではこのHoldoverの精度を維持するため、高性能なクロックを搭載することが多いです。

ここではGrandmaster ClockとLocal Clockの関係を説明します。もしGrandmaster ClockとLocal Clockが完全に同期していた場合、補正をする必要はありません。しかしこの前提ではいずれのクロックも高精度であることが求められ、高価なものとなってしまいます。そもそもフリーランの上完全に同期するということは不可能です。同期を実現するためにすべてのクロックに時刻源としてGNSSを用いることも考えられますが、配線やコストの問題がつきまといます。実際にはより正確な（≒高価な） Grandmaster Clockと、単体では正確性が確保できないが安価なLocal PTP Clockを組み合わせた上で、Slave側のLocal Clock を生成するという図式が一般的です。このときGrandmaster Clockには原子時計もしくはそれに類する精度のクロックが求められる一方、Local PTP ClockにはGrandmaster Clockを時刻源とした補正が常に必要とされます。

ここからは同期方法について説明します。同期方法はone-step（1-step）とtwo-step（2-step）の2つのバリエーションがあります。表-7と図-2で、2-stepを例に解説します。

t2-t1を計算することで、Master PTPインスタンス送出からSlave PTPインスタンス受信にかかった往路の時間を算出できます。このときネットワーク遅延（meanPathDelay）及び2 つのクロックの時刻差（offsetFromMaster）が加わった結果、t2となります。これより

となり、

と導き出されます。

またt4-t3を計算することで、Slave PTPインスタンス送出からMaster PTPインスタンス受信にかかった復路の時間を算出できます。つまり

となります。このときoffsetFromMasterは「Slave−Master」の時刻差として定義されるため、復路では符号が反転します。これより

が導き出されます。

更に（1）式と（2）式より、

となります。この2つの値を用いてSlave PTP Clockは同期を行います。

（1）（2）式を見ると分かるように、片方向測定だけではネットワーク遅延とクロック差が混ざってしまいます。往復測定し、式に当てはめることでこれらを分離することができます。

この2つの値、meanPathDelayとoffsetFromMasterを連続的に計算することで、Slave PTPインスタンスはMaster PTP インスタンスの持つクロック（Grandmaster Clock）と自らのクロック（Local PTP Clock）との同期を図ります。この手法により、ネットワーク遅延を考慮した同期が可能になります。プロファイルによりますが、この計算サイクルは1秒に0.5回から128回までの間隔を設定することができます。

ところでなぜわざわざMaster PTPインスタンスはSyncとFollow_Upを分けて配信するのでしょうか？これはPTPが求める正確性を実現するための重要な仕組みです。Master PTPインスタンスは「Syncメッセージを送出する」ことと、「そのメッセージが実際にネットワークへ送信された瞬間の時刻t1を正確に計測・記録する（タイムスタンピング）」という2つの処理を行う必要があります。

Syncメッセージは上位レイヤーで生成されますが、この時点では実際にネットワークにメッセージが送出される正確なタイミング（t1）は未確定です。上位層でタイムスタンピングしてしまうと内部処理の遅延がt1に印加されてしまい、「t2 - t1」によって求められる値に誤差を及ぼします。この問題を避けるため、Syncメッセージ送信後に実際の送信時刻をタイムスタンプとして取得し、その値をFollow_Upメッセージとして別途通知する方式が定義されています。この手法を2-stepといいます。

ハードウェアによるタイムスタンピングがサポートされている場合、実際にメッセージがネットワークに送出される直前もしくはその瞬間にタイムスタンピングを行うことができるようになります。この手法を用いることで、より高精度な時刻同期が可能になります。

高精度な時刻同期を実現するためには、多くの場合このようなMAC層もしくはPHY層によるハードウェアタイムスタンプを用いた実装が採用されます。PTP対応機材では専用のハードウェアやPTP対応NICを用いることが一般的です。

Syncメッセージが生成されてネットワークに送信される際、実際の送信時刻が確定したタイミングでハードウェアが送信直前に正確なタイムスタンプをフレームに挿入する方式が1-stepです。この方式ではSyncメッセージ単体で正確な送信時刻t1を伝えることができるため、Follow_Upメッセージは不要となります。この様子を図-3に示します。

このように高精度な時刻同期を実現するPTPですが、その性能を確保するためにはネットワークでの対応も必要になります。理想的には、PTPで同期するPTPインスタンス間の経路上すべての機器がPTP対応であることが望まれます。このように構成されたネットワークはPTP aware networkと称されます。PTPインスタンス間にPTP非対応の装置が介在すると、その装置での内部処理やバッファリングによってパケットのジッタ（PTPの用語としてはPacket Delay Variationと呼ばれます）が発生し、PTPインスタンス間で正確な同期を維持することが困難になります。このように構成されたネットワークは、慣習的にPTP unaware networkと呼ばれています。

各PTPインスタンスはネットワークを介して同期情報をやり取りします。PTP BCは時刻を再生成して下流に配布するため、PTP TCは転送遅延を補正するために配置されます。PTP BCやPTP TCでは正確な時刻同期のため、上述のハードウェアタイムスタンピングが採用されることが多いです。

ここで気を付けたいのは、PTPのパケットがPTP BCやPTP TC では「特別扱い」される、つまり他のパケットと異なる処理が施されるということです。

PTP BCでは、受け取った時刻同期情報に基づきLocal PTP Clockが維持されます。つまりPTP BC内部で新しく時刻が生成されます。この時刻情報を基に、いわゆる下流に時刻同期が提供されます。このときIngressポートで受信したPTPパケットとEgressポートで送信されるPTPパケットは違うものになります。

一方PTP TCはtransparentという名称のとおり、PTPパケットはポート間を通過します。ただしその際にPTP TC機器内で処理にかかった時間を計測しています。その値をCorrectionField （ 遅延時間が記録されているフィールド）に加算した上で、パケットを転送します。受信側のPTPインスタンスは、CorrectionFieldの値を参照して遅延補正を行います。

PTP BCやPTP TCの下流から見ると単にPTPパケットが送信されてくるように見えますが、実際にはPTP BCやPTP TCによって正確な時刻情報が再生成・補正されています。この補正処理こそが、PTPネットワークでの高精度な時刻同期を実現する上で非常に重要な点です。

一方PTP非対応のL2スイッチでは、パケットはそのまま転送され、タイムスタンプの補正は行われません。従ってPTPの高精度な時刻同期性能を確保したい場合、ネットワーク構築において表-8に挙げる点に注意する必要があります。

PTPは基本的に「安定したネットワーク」を前提とします。meanPathDelayを算出する際の「足して2で割る」という計算方法もその考え方を反映しています。つまり「行きも帰りもパケットの伝達にかかる時間は同じ」ということを想定しているわけです。これをネットワークの対称性と呼びます。ところがこのような前提では「不安定なネットワーク」の場合にPTPで期待される精度を満たすことが困難になります。

実際、パケット伝送時間を対称に保持することが難しい場合があります。インターネットのように多くのノードの挙動タイミングが一致しない共用ネットワークや、映像伝送のようにトラフィックの流れる方向が不均衡な場合などです。映像伝送とPTP伝送を組み合わせた場合の類型を図-5に示します。

左から右へ向かう通信（往路）はStream TXからStream RXへの通信、PTP GMからPTP OCへの通信から構成されます。また、右から左へ向かう通信（復路）はPTP OCからPTP GMへの通信のみとなります。

一般的に映像伝送は、PTPメッセージよりもはるかに多くの通信量を発生させます（おおむね数千倍）。このため通信量は「往路＞復路」となるため、往路の負荷が高くなり、中間機器における処理時間に偏差が生じ、伝送遅延が非対称になります。

また、インターネットのような公衆網の場合、常に通信量の変動が発生します。つまり、揺らぎが常時発生することになります。そして揺らぎの発生頻度や大きさは、そのネットワークによって個々の形を取って発現します。公衆網での揺らぎの例を2つ紹介します。IIJのバックボーン（図-6）、及びIIJのフレッツ接続サービスで東京〜大阪間でのジッタ計測データ（図-7）です。

このように揺らぎがあるネットワークでPTPを動かすと、アルゴリズムによる計算結果が安定に向けて収束していきません。その結果、PTP OC側では精度が担保できないとして「同期できない（PTP unlock）」と判断されてしまいます。

もっとも規格上に同期に関する精度が定義されているわけではありません。PTP対応機器では「PTP lock」「PTP unlock」という表記がされることが多いのですが、あくまでその実装が内部的に定義したPTPの状態のことを指しています。「同期に足る精度が得られない」という判定がなされたとき「PTP unlock」という表示がされるということです。つまり同じネットワークを経由していても、機器によってPTP lockの条件は異なります。

本節では、従来PTPでは困難だった、公衆網越しの時刻同期に対するIIJのアプローチを紹介します。

従来のPTPは設計上、閉域かつ高品質なネットワークを前提としていました。これを公衆網へ拡張しようという試みが、ここで紹介するRPTPです。RPTPとはResilient PTPの略で、PTPを不安定な公衆網上でも伝送することを目指した技術です。RPTPの特徴は、PTP GMから受け取ったパケットからジッタ成分を排除し、正しくLocal PTP Clockを生成するアルゴリズムです。RPTP機器はPTPのプロトコル仕様を一切変更せず、アルゴリズムによるフィルターをSlave側で適用しています。これにより、既存のPTP GMなどに手を加えずに使うことができるのがRPTPのメリットです。RPTPはPTP unaware network上においても、実用的な精度でPTP時刻同期を成立させることを目指した設計になっています。

RPTPは表-9の2つの技術要素から構成されています。

前述のようにRPTPは、通常のPTPにおけるoffsetFromMaster の計算を改良したアルゴリズムです。RPTPでは、PTPの受信時刻t2、t3の代わりに、EVEによって生成される仮想時刻x2、x3を使用します。x2とx3は、ADAMによって遅延揺らぎを除去した予測値（安定化された受信・送信時刻）です。このx2、x3を用いて（x2 - t1）及び（t4 - x3）を求め、それらの実測値と「最小遅延となった値（最小値）」から、往路・復路それぞれのオフセット予測値を回帰直線として導き出します。最小値を使うのは、遅延が最小であった瞬間が真の遅延に最も近いと考えられるためです。

また、EVEでは「回帰直線を計算するための仮想クロック」と「オフセット値を計算するためのカウンタ」が独立して動作します。この2系統の時間基準を使う設計により、遅延揺らぎが大きい公衆網でも安定したオフセット推定が可能になります。ADAMは、これらのデータを解析して回帰直線を生成し、徐々に精度の高い予測値に収束させるアルゴリズムです。

このようにRPTPはアルゴリズムであり、PTPの1つの応用技術と言えます。PTPのプロトコル自体に手を加えるものではないため、標準化活動を目指すものではありません。特定領域におけるPTPの課題解決策として、今後の展開を考えています。

IIJはこのRPTP技術に対し、RPTP Allianceのメンバーとして技術普及に努めています。RPTPは元々ネットワークアディションズで開発されたものですが、この他にメディアリンクス、セイコーソリューションズ、そしてIIJがRPTP Allianceに参画し、活動を続けています。IIJはネットワークを持つ強みから、実ネットワークにおけるRPTPの実証実験に数多く参加しています。

RPTP対応製品（DB3200）はPTP BCとして実装されています。上流側ポートで届く、PTP unaware networkで揺らいだPTPのタイミングをいわば「整流」する役目を持ちます。つまり、下流に対して整流済み、揺らぎのないPTP時刻同期を可能とするものです。

また、DB3200はPTP BCとしてPTP時刻同期を提供するだけではなく、1PPSや10MHz、48kHzといった、これまで同期の世界で用いられてきた周波数も供給することができます。これらの周波数はPTP時刻同期によってDB3200の内部で作られます。これにより、公衆網を経由しても正確な時刻や安定した周波数が提供できるようになりました。

RPTP Allianceは様々な領域で実証実験を展開していますが、ここではIIJのリソースを用いたPoCを紹介します（図-8）。IIJ横浜第一データセンターと大阪間をフレッツ光クロス回線で結び、回線上にL2VPNを構成します。大阪のPTP GMよりPTPを流し、VPN経由で届いたパケットを横浜のDB3200において受信、RPTPによる補正を行いました。

RPTPが特に目指しているのが、遠隔地へ公衆網を用いてPTPの同期を図ることです。公衆網は当然PTP unaware networkですし、PTPが必要とするIPマルチキャストも通信できません。このままではPTPの通信が成立しないため、公衆網上でL2VPNを構成することで遠隔地とのPTPパケットのやり取りができるように工夫しています。

PTPの正確性を計測する方法はいくつかありますが、この実験では1PPSによる観測を行いました。

PTPやGNSSをはじめとした「同期業界」では「1PPS」という信号がリファレンスとして使われます。これは「1 pulse per sec」の略で、言葉のとおり1秒の境界でパルスが立ち上がる信号のことです。この方式を用いて、クロックのタイミングを1PPSとして入出力します。この立ち上がりの精度については様々な規定や慣行があり、それにより正確性が担保されています。タイミングを測るためのアプローチですが、機器間で正確なタイミングを伝達する場合に広く用いられています。IEEE1588ではモニタリング用途の例として1PPS出力が例示されています。図-9ではPTP GM及びDB3200の1PPS出力を1PPSロガーへ入力し、比較観察しています。PTP GMの1PPS をリファレンスとし、DB3200の1PPS出力がどのくらい揺らぐかで、RPTPの性能を測るわけです。どちらも時刻情報源としてGNSSを用いているため、比較が可能になっています。

PTPはこのように汎用性を持っており、RPTPなどの手法で更にユースケースを広げることが可能だと言えます。

最後に、そもそもの話題である「時刻」について説明します。

PTPやNTPで配布されているのは「epoch（基準時刻、エポック）からの経過時間」です。「何年何月何時何分何秒」という暦時刻ではなく、表-10のとおりepochを基準とした時刻が用いられています。

CFAbsolute TimeはApple Cocoa Core Data timestampなどとも呼ばれ、Apple系のOSが利用しています。またFILETIMEはWindows系のOSで利用されています（Windows NT 3.1より）。

Unix timeとCFAbsolute Timeは負の値を取れます。つまりepochより以前の時刻が表現できます。身近なOSやアプリケーションでもそれぞれepochやうるう秒への対応、構造が異なることが分かります。

PTPやNTPで用いられるepochは必ずしも絶対時刻（暦の時刻）である必要はありませんが、システムが複数存在することを前提とすると、すべてのシステムが同一の時刻源で同期されていることが好ましいことは言うまでもありません。そこで用いられるのが国際標準となっている時刻系です（表-11）。

時刻についてはUTC（Coordinated Universal Time、協定世界時）が世界的な基準時刻として、幅広く用いられています。

もっとも、世界のどこかに基準となるUTCの時計がリアルタイムで動いているわけではありません。国際単位系（SI）を実現するための組織、国際度量衡局（Bureau international des poids et mesures、BIPM）がUTCを管理しています。BIPMは各国の標準機関が運営する原子時計のデータを取得し、月次で各国機関が管理する時刻系のずれを発表しています。それらのデータを基に算出される時刻が国際原子時（Temps Atomique International）となります。

UTCはこのTAIを基礎として、地球の自転に基づく時刻（UT1） との差が大きくならないよう、うるう秒による調整を行ったものです。うるう秒は1秒の単位でUTCに挿入されるもので、結果UTCはTAIより遅れた時刻になります。うるう秒の挿入は1972年から2017年までの間27回実施されました。UTCが1972年に再定義された際はUTC=TAI-10秒でしたが、この挿入の結果2025年時点ではUTC=TAI-37秒という関係になっています。

うるう秒の存在は、UTCは連続した時刻スケールではないことを意味します。従って、時刻同期機構においてはUTCとTAI を区別して考える必要があります。

日本では情報通信研究機構（NICT）、国立天文台、産業技術総合研究所が原子時計を用いて時刻を管理しており、BIPMへもデータを供給しています。また、NICTはUTC（NICT）を元にした日本標準時（JST）を維持しており、更に長波帯を用いた標準電波（JJY）や光電話回線を利用した光テレホンJJY、更にインターネットに接続されたNTPサービス（ntp.nict.jp）で日本標準時を配布しています。

「時刻配布システム」として世界的に幅広く用いられているのがGNSS（全球測位衛星システム、Global Navigation Satellite System）です。GNSSは米国GPS、ロシアGLONASS、EUのGalileo、日本のみちびき（QZSS）などの総称です。GNSSの役割として位置測定や航法がありますが、3つ目の重要な役割として高精度な時刻配信があります。これらの衛星には原子時計が搭載されており、GNSSによる時刻同期を用いれば、地球上のほとんどの場所で精度の高い時刻を得ることができます。NTPやPTPの基準信号として広くGNSSが用いられるのはこのためです。なお、GPS、Galileo、みちびきではうるう秒を含まない連続時刻（TAI系、もしくはTAIと一定オフセットの時刻系） が採用されており、更にGalileoやみちびきはGPSと時刻が同一となるように設計されています。

ただしGNSSは外部要因により電波受信が不安定もしくは不可能となる可能性があり、近年その対策が求められるようになっています（受信時のパルチパス排除、ジャミング・スプーフィング対策、EMI対策など）。

PTP機器はもちろん、標準時システムやGNSS衛星でも時刻精度を維持するために高性能なクロックが搭載されています。高精度時刻同期装置には、周波数の安定度と精度の高いクロックが不可欠です。表-12に代表的なクロックの種類を示します。

これらの発振器はいずれも一定の周波数信号を生成します。生成された周波数を基準とし、分周やカウントを行うことで例えば「1秒」や「10MHz」といった時間や周波数の基準目盛りを作り出すわけです。クロックには「周波数の安定性」「周波数の正確性」が求められますが、複数のクロックを同期させる場合には、これらに加え「位相」が一致することが重要となります（図-10、図-11）。

時刻同期の本質は、複数のクロックの周波数及び位相が一致した状態を確立した上で、共通のepochを基準とする絶対時間カウンタを共有することにあります。

ここまでPTPの概要とIIJの取り組みを説明してきました。PTPはミッションクリティカルなシステムにおいて非常に重要な「時刻同期」を担っています。一方で、事実上PTP aware network上でしか高精度な同期精度を得られず、幅広く展開できない制約もありました。RPTPの試みによって、より広範囲にPTPのユースケースを増やしていきたいと考えています。

謝辞：本稿の執筆に当たりRPTP Allianceのメンバーの皆様より、技術的な議論及び実証に関する多くの知見をいただきました。ここに感謝の意を表します。