「この区画に、何台がどれだけ停まっていたか」。交通量調査でこの問いを受けたとき、成果物として何を納めるかは、たいてい集計表です。時間帯別の在車台数、区画別の平均停車時間、5分未満と5分以上の内訳。報告書に載るのはその形なので、そこから逆算して調査を設計します。
ところが、発注者から後で来る質問は、集計表では答えられないものが多い。「17時台に長く停まっていたのは同じ車ですか、別の車ですか」「30分以上停まっていた車だけ抜き出せますか」「区画をもう少し手前まで広げたら数字はどう変わりますか」。
集計表は、集計した時点で元の粒度を捨てています。捨てたものは、映像を見直さない限り戻ってきません。
この記事は、停車1件ごとに1行のデータ——いつ停まり、いつ出て、何秒だったか——を納品物に含めると、調査設計と検収の何が変わるかという話です。定義そのもの（「停車時間」という言葉が何を指すか）は別の記事で扱っているので、ここでは繰り返しません。この記事は、定義が決まった後に出てくるデータの形の話です。
巡回方式が記録しているのは「その瞬間の在車台数」
路上駐停車の実態調査は、長く巡回方式で行われてきました。調査員が1時間に1回まわり、車種別・時間別・区間別に地図上へ記録する。東京都道路整備保全公社の令和3年度路上駐車実態調査は、23区内52地区（500m×500m）で平日・休日各1日、この方式で実施されています（報告書）。今治市の駐車実態調査も1時間に1回の巡回、平日・休日とも8:00〜20:00の12時間観測です（調査結果）。
この方式が記録しているのは、巡回した瞬間に何台停まっていたかです。1台の車がいつ来ていつ出たかは、記録の単位になっていません。
これは手法の欠点ではありません。路上駐車の面的な発生状況を把握するには、区間ごとの在車台数が適切な指標です。目的が違うだけで、巡回方式は目的に対して合理的に設計されています。
一方で、「1台ごとの開始・終了時刻」が調査項目として存在しなかったわけでもありません。土木計画学研究の調査（堂垣・井上、2009）は、時間制限駐車区間での路上駐停車行動について1,394台を観測し、個々の駐停車ごとに駐車開始時刻・終了時刻・目的・車種など26項目を記録しています（講演集No.40）。
つまり「1件ごとの開始・終了」は、AI映像解析が持ち込んだ新しい概念ではありません。人を張り付ければ取れる項目で、実際に取られてきた。ただ、人を張り付ける前提だと、地点数と時間数がそのまま人日になります。取れるが、条件によっては受けられない。そういう項目です。
国の標準フォーマットにも、1件ごとの行はない
機械側の標準はどうか。国土交通省の「画像認識型交通量観測装置 機器仕様書」（令和8年1月版）を見ると、出力・集計フォーマットは別表で様式番号まで指定されています（国交省の一覧ページ）。
- 集計単位は5分間値と1時間値（2-5）
- ブラウザ表示と表計算形式への出力（CSV, EXCEL形式）。CSVは文字コードShift-JIS、改行コードCRLF、カンマ区切り、可変長（3-2(5)）
- フィールドは5分観測値・集計値が様式No.1〜54、1時間集計速報値が様式No.1〜24
- 内容は常時観測点コード、観測年月日、時間帯、上り下り別の車種別観測値と集計値、平均速度・占有率（当面は空欄として運用）、カメラプリセット位置や気象影響などのエラーフラグ
このフォーマットに、1台ごとの個別ログの列はありません。停車時間に相当する列もありません。
ここは誤解されやすい点です。この仕様書は道路管理用CCTVカメラや可搬カメラの映像から通過台数を観測する機器の仕様であって、駐停車調査のための仕様ではありません。停車時間の列がないのは不備ではなく、設計として当然です。仕様書を責める話ではありません。
問題になるのは、このフォーマットの発想のまま、停車を数える調査の納品物を設計してしまうときです。5分刻みの集計表という器に停車のデータを流し込むと、器に入らないもの——1台がいつ来ていつ出たか、同じ車か別の車か、観測窓の端で切れているかどうか——が、集計の時点で落ちます。落ちたことは集計表からは見えません。
同じ仕様書が、書き方の手本にもなっている
一方でこの仕様書には、停車のデータを設計するときにも効く作法が入っています。
- 判別できなかったものを0に混ぜない。「小型大型判別不能交通量」が独立した列として置かれています（5分値の様式No.8・17・28・37、1時間値のNo.8・18）
- 異常なら数字を書かない。5分値の集計値は、カメラプリセット位置のフラグが異常のとき空欄になります
- エラーフラグは3値。「0：正常，1：異常」に加えて「エラー判定不能の場合は空欄」
- 補完したことを残す。1時間集計速報値には「5分欠測処理フラグ」があり、0：処理不要／1：5分間値による拡大／2：5分間値不足により欠測扱い、を区別します
- 使えないと判断する閾値を先に決める。1時間のうち方向別5分間交通量が正常に観測できた時間の累計が45分以上なら、正常に観測できた時間の総交通量に 60分÷正常に観測できた時間（分）を乗じて補完値とする。45分未満ならその1時間は欠測とする（別表末尾）
停車を測る納品物でも、同じ作法が要ります。測れなかったのか、0だったのかの区別については別記事に書いたので、ここでは繰り返しません。
入力の範囲を広げても、精度を保証する範囲は広げていない
もう一つ、版の話を書いておきます。令和8年1月版は入力カメラ映像の条件を「24時間かつ、天候を問わない映像」としています（2-3(1)ウ。豪雨・豪雪・暴風雪・地吹雪・濃霧等で視界の確保が困難な場合と、映像のピントが合わない場合は除外）。旧版（令和元年6月の「案」）は「降雨・霧・積雪等のない晴天時の映像」でしたから、ここは広がりました。
ただし精度要件の時間帯は据え置きです。混雑時（7時〜9時）および非混雑時（9時〜16時）において、上下線別の自動車交通量が手作業による観測値（正解値）の±10%以内。それ以外の時間帯は「日中・晴天時と同等の映像品質が確保できていることを基本とするが、観測性能については別途協議とする」と書かれています（2-3(2)ウ）。
入力の範囲を広げても、精度を保証する範囲は一緒に広げていない。広げた分は協議事項として切り出してある。夜間や雨天を含む調査の見積を書くとき、この書き分けはそのまま使えます。
実測：夜間3分の映像から出した停車イベント
自社の実測で、実際にどういうデータが出るかを示します。
京都駅烏丸口のタクシープール、2026年4月16日19時12分から182.6秒（3分3秒）の映像です。区画は京都市がPoC打ち合わせで指定した計測範囲。保存済みの計測結果を再集計したもので、AIの推論はやり直していません。
出力した列はこの6つです。
| 列 | 内容 |
|---|---|
| vehicle_id | 車両ごとに割り当てた識別番号 |
| class | 車種（この映像では全件が一般車） |
| zone_id | 区画ID |
| stop_start / stop_end | 停車の開始・終了時刻（JST） |
| duration_sec | 停車時間（秒） |
ここで最初の注意点です。この形式は「1台1行」ではなく「1停車イベント1行」です。 同じ車が2回停まれば2行になりますし、1回の停車が計測上分断されれば、それも2行になります。この違いが、次に書く数字を生みます。
結合ルールを適用する前が36件、適用した後が27件。ユニークな車両は前後とも20台でした。件数は3割変わりますが、数えている台数は変わっていません。同じ車の分断されたセグメントが繋がっただけです。
最長の停車時間は119.7秒から133.0秒に伸びました。つまり、分断されたまま集計すると、長時間の駐停車を短く見積もります。
分断がなぜ起きるかというと、車両が他の車や柱で隠れると足元の判定点が失われるからです。この映像で結合された9組は、中断時間が1.97〜3.56秒、位置ずれが1.4〜10.0pxでした。
もう一つ。停車の判定閾値を変えると件数が動きます。同じ映像で、20pxで36件、25pxで34件、30pxで31件です。閾値を変えると数字が変わることは、隠さずに書くべき性質のものです。
そして打ち切り。27件のうち、映像の終端まで停まり続けていたものが5件、映像の先頭ですでに停まっていたものが3件ありました。合わせて8件、およそ3割です。この8件の停車時間は、真の停車時間ではなく下限です。観測窓を延ばせば伸びる可能性があり、縮む可能性はありません。
ちなみに、この映像で「5分以上の駐停車が何台か」は原理的に判定できません。映像が3分3秒しかないためです。答えは「0台」ではなく「判定不能」です（この区別は別記事にあります）。
どう決めたか
分断をつなぐルールを、数値で書く
同一の車両IDかつ同一区画の連続する2件について、次の両方を満たすとき1件に統合しています。
- 中断時間 ＝ 次の開始 − 前の終了 が 5秒以内
- 位置ずれ ＝ 前の終了位置と次の開始位置の距離が 20px以内
この5秒と20pxは暫定値です。目視台帳と突き合わせて妥当性を確認した実績はありません。実際に結合された9組は中断が最大3.56秒だったので、この映像では5秒という上限が効いていません（3.56秒と5秒の間に事例がない）。別の地点では効き方が変わります。
重要なのは値そのものより、この2つの数値が納品物に書いてあるかどうかです。書いていなければ、後から件数の妥当性を検証できません。
位置は、手ブレを補償した座標で測る
位置ずれを生の画素座標で測ると、カメラが動いた分だけ「動いていない車」が動いて見えます。この映像のカメラは3分間で269.7px流れていました。手ブレ補償を通した座標で測っています。
三脚を使えば済む話ではあります。ただ、既存の映像を後から解析する場合は、補償の有無で結合の判定が変わることを知っておく必要があります。
時刻は、映像内の経過秒ではなく実時刻で持つ
stop_start / stop_end は、撮影開始時刻に映像内の経過秒を足して算出しています。映像先頭からの経過秒のままだと、複数のカメラや複数日の記録を突き合わせられません。撮影開始時刻をどう取得したか（この例では動画ファイルのメタデータ）まで記録に残します。
閾値を一つに固定しない
「5分を超えたら駐車」という区分は、道路交通法上の駐車の定義（客待ち・荷待ち・貨物の積卸しなどによる継続的な停止。貨物の積卸しで5分を超えない時間内のものと、人の乗降のための停止を除く）に由来しています。ただし法令の定義は取締りのためのもので、調査の集計単位としてそのまま最適とは限りません。
貨物車の路上待機に関する研究（東京都道路整備保全公社 令和4年度提案公募型研究）では、荷役を伴わない路上駐車（休憩＋待機）が全体の50.7%を占め、平均駐車時間は10分未満とされる一方で30分以上の長時間駐車も残存する、という分布が報告されています（PDF）。分布が偏っていて裾が長いので、閾値を一つ決めると、その閾値の近くにある事例の扱いが結果を左右します。
1件ごとのデータを持っていれば、閾値は後から変えられます。集計してから閾値を変えたくなると、映像に戻ることになります。
仕様書と納品物で決めておく7項目
発注する側・受ける側どちらでも使えるように、確認項目の形にします。仕様書全体のチェックリストは通行量調査の仕様書に入れるべき10項目にまとめてあるので、ここは停車のデータ固有の項目に絞ります。
1. 行の粒度 納品するCSVの1行が何を表すか。1停車イベントか、1台か、集計値か。「1台1行」と書くと、1台が複数回停まったときの扱いが決まりません。
2. セグメント結合のルールと、その数値 分断された停車を繋ぐかどうか。繋ぐなら中断時間と位置ずれの上限値を数値で明記し、結合前後の件数を両方報告してもらう。件数が3割動くことがあります。
3. 時刻の基準 実時刻か映像内経過秒か。実時刻なら、撮影開始時刻をどう取得し、どう合わせたか。
4. 観測窓の端に接した停車の扱い 映像の先頭ですでに停まっていたもの、終端まで停まり続けていたものを、どう表現するか。「◯秒」ではなく「少なくとも◯秒」として区別できる形にしておく。何件が該当したかも報告項目に入れる。
5. 車両IDの意味 IDが何を識別しているか。ナンバーでも個体でもなく映像内の通し番号である場合、同じ車が長い遮蔽で別IDになりうることを明記する。ユニーク台数を数える根拠にできるかどうかが変わります。
6. 閾値を変えたときの件数 停車判定の閾値を動かしたときに件数がどう変わるかを、感度として納品物に含めるか。1本の数字だけだと、その数字が安定しているのか閾値の縁にあるのかが分かりません。
7. 欠測とみなす閾値 観測窓のうちどれだけ判定できなければ、その区画・時間帯を欠測として扱うか。国の仕様書が1時間あたり45分という閾値を先に決めているのと同じで、後から決めると、結果を見てから基準を動かせてしまいます。
なお、このデータを後から使えるかどうかは契約でも決まります。生データ・定義・記録の帰属と引き渡し形式についてはそのデータは誰のものかに書きました。
おわりに
検証できていない範囲を書いておきます。
上の数字は夜間3分3秒の1地点のものです。結合ルールの5秒・20pxは暫定値で、目視台帳との突合はこれからです。雨天・逆光の条件下での検証は進行中で、まだ結果を示せる段階にありません。24時間の連続した映像を通しで処理した社内実績もありません。区画・位置は映像の画素座標で扱っており、地図座標への重畳は縮尺検証が終わっていないため行っていません。
そのうえで、この記事で言いたかったことは一つです。集計表は、集計した時点で戻れなくなる。 1件ごとの行を残しておけば、閾値も区画も後から引き直せます。人手の調査でも26項目を記録していた時代があったのだから、器のほうを狭くする理由はありません。
仕様書に一行「停車イベントを1件1行のCSVで納品すること。結合ルールと閾値を明記すること」と書いておく。それだけで、来年の自分が映像を見直さずに済みます。