ODD（運行設計領域）

概要

ODD（Operational Design Domain／運行設計領域）は、「自動運転システムがどのような条件のときに動いてよいか」をあらかじめ決めておく、運行可能範囲の定義です。場所・道路種別・天候・時間帯・交通状況・インフラ条件などを組み合わせて、「ここまでなら自動運転で走らせてよい」という線を引きます。

公式ストアAmazon.co.jp毎日お得なタイムセール。日用品からガジェットまで幅広くチェック。タイムセールを見る →

ODD（運行設計領域）は、自動運転システムの「守備範囲」を決める設計書です。どの道路種別を、どの速度域で、どの天候・時間帯・混雑状況のときに、どのセンサ・地図・インフラがそろっていれば自動運転を許可するのかを言語化し、図と表で整理します。代表的なKPIは、ODD内走行比率（日次・%）、ODD逸脱警告率（件/1,000km）、ODD起因の運休・減便時間（月次・h）、ODD定義変更頻度（回/四半期）などで、サービスレベルと安全を両立させるための「運行ルールの物差し」として扱います。

自動運転というと「どこでも・いつでも・完全自動」というイメージを持たれがちですが、実務の世界では、必ずODDという枠の中で設計・認可・運行が行われます。ODDを丁寧に定義し、監視し、少しずつ拡張していくことで、安全と利便性のバランスを着実に高めていくことができます。この記事では、ODDを法律用語や学術用語として眺めるだけでなく、実際のサービス設計・ダイヤ策定・運行判断の現場でどう使っていくかを軸に解説していきます。

このページで分かること

ODD（運行設計領域）の基本的な定義と、SAE自動運転レベルとの関係
ODDを構成する主な要素（場所・道路・天候・時間帯・交通状況・インフラ条件など）の整理の仕方
「限定エリアの自動運転サービス」を設計するときに、ODDをどのようなステップで決めていくかの流れ
運行中にODDを監視し、逸脱しそうなときにどう検知・警告・停止するかという運用の勘所
ODDに関する代表的なKPIと数値の目安、よくある誤解とその避け方
ジオフェンス、SAEレベル、システム境界、SOTIF（安全性の概念）など、関連用語との違いと接点

この用語が必要になるシーン

レベル3／レベル4の自動運転サービスを企画し、「どこまで自動運転を認めるか」を検討するとき
自治体・事業者・メーカーが参加する会議で、「この路線ならどの区間・どの時間帯を自動運転にするか」を合意したいとき
安全審査や認可申請の場で、「このシステムはどのODDの範囲で安全性評価されていますか」と問われたとき
運行ダイヤ・管制ルール・オペレーターのマニュアルを作成する際に、「自動運転を止めるべき条件」を明文化したいとき
サービス開始後に、降雪や工事区間の増加を受けて「ODDを狭める／広げる」判断をする必要が出てきたとき
事故・ヒヤリハットの検証で、「事象がODDの内側だったのか外側だったのか」を整理したいとき

PayPayポイントYahoo!ショッピング – LINEアカウント連携でPayPayポイント毎日5%！ネット通販Yahoo!ショッピングは幅広い品ぞろえと、最新のお買い得ネット通販情報が満載のオンラインショッピングモール。PayPay残高も使えてさらにお得！Yahoo!で見る → 基本の定義と用語整理

ODD（運行設計領域）は、もともとSAE J3016で定義された概念で、「特定の自動運転システムが機能するよう設計された運転環境の集合」を指します。少し砕いて言うと、「このシステムは、どんな道路・どんな天気・どんな時間帯・どんな交通状況のときに、どこまで責任を持ちますか？」をはっきりさせる枠組みだと考えると分かりやすくなります。

重要なのは、「車そのもの」ではなく「機能ごと」にODDが定義される点です。同じ車両でも、高速道路の車線維持機能と、住宅街の自動運転シャトル機能では、ODDがまったく違います。また、ODDは配車アプリや管制システム、インフラ側のセンサー・信号情報なども含めた「システム全体」を前提に決められます。

ODD（Operational Design Domain）／運行設計領域：自動運転システムが機能するよう設計された運行条件のセット。環境条件・道路条件・時間帯・地理範囲・インフラ条件などの組み合わせ。
SAE自動運転レベル：人とシステムの役割分担を0〜5のレベルで表現した指標。レベル3/4では、「レベル」とセットでODDが定義されます。
ジオフェンス：地理的な範囲（地図上の区域）の制限。ODDの一部にあたりますが、ODDはさらに天候・時間帯・インフラ条件なども含みます。
機能安全・SOTIF：ISO 26262やISO 21448などで扱われる、自動車システムの安全性に関する枠組み。ODDは、どのような状況を設計対象とするかを決める入口として機能します。
ADS（Automated Driving System）：自動運転機能そのもの。ODDは「どんなADSを」「どんな条件で」動かすかを決める設計情報です。

仕組み・アーキテクチャの全体像

ODDをシステムとして眺めると、「定義」「判定」「監視・記録」「変更管理」の4つのレイヤに分かれます。まず、机上の設計としてODDを定義し、その定義をもとに車載システム・地図・クラウド・管制システムが「今はODDの内側か外側か」を判定します。その判定の結果をログとして残し、必要に応じてODD自体の見直しにつなげていきます。

車載側では、センサ（カメラ・LiDAR・レーダーなど）と高精度地図、GNSS、車両速度や挙動などの情報から、「現在の道路種別」「レーン形状」「勾配」「制限速度」「交通密度」「視程」「路面状況」などを推定します。これに加えて、V2X（路車間通信）やインフラからの情報（信号機の状態、工事情報、気象情報など）を取り込むことで、ODD判定の精度を高めていきます。

クラウドや管制システム側では、運行エリアの地図データや道路交通情報、気象情報をもとに、「ODDを満たす区間」を時間軸も含めて管理します。運行前には「本日このダイヤはODD内で運行可能か」をチェックし、運行中はリアルタイムに状況を監視しながら、必要に応じて減速・経路変更・運休の判断を下します。

最後に、ログ・ヒヤリハット・事故情報・ユーザーからのフィードバックなどをもとに、ODD定義を定期的に見直します。センサ性能向上やインフラ整備によって拡張できる領域もあれば、想定以上のリスクが見つかって縮小すべき領域もあります。ODDは一度決めたら終わりではなく、「運行データに基づいて進化させる設計情報」として扱うことが実務的です。

Pro向け特化PCOZgaming Pro向け特化パソコン業界最安プロレベルのスペックがこの価格。OZgamingの最新カスタムPCで、あらゆる作業を根底から効率化しよう。OZgaming公式で見る → 代表的な構成パターン

ODDの切り取り方にはいくつかのパターンがあります。ここでは、実際のプロジェクトでよく見られる三つのパターンを取り上げます。

パターンA：エリア限定・時間帯限定シャトル特定の街区や工業団地内など、明確に区切られたエリアで、日中の一定時間のみ自動運転シャトルを運行するパターンです。ODDは「○○地区内の専用ルート」「7:00〜19:00」「降雨量◯mm/h未満・積雪なし」といった形で、比較的シンプルに表現できます。実証実験や初期サービスでよく採用される構成です。
パターンB：高速道路・自動車専用道路限定の自動運転機能乗用車のレベル3システムなどに多いパターンです。ODDは「高速道路・自動車専用道路に限定」「渋滞時のみ（◯km/h以下）」「雨・雪・視程が一定以上」というように、道路種別と速度域を中心に定義されます。この場合、地理的なジオフェンスよりも「道路の種別判定」と「交通状況の判定」が鍵になります。
パターンC：段階的に拡張されるODD初期はエリア・時間帯・天候をかなり絞り込んでおき、運行実績とデータの蓄積に応じて少しずつ条件を緩和していくパターンです。たとえば「まずは晴天の日中のみ」から始め、次に「小雨・曇天も含む」、さらに「夜間も一部区間で解禁」という具合にレベルを上げていきます。安全性評価のプロセスとセットで運用しやすい形です。

メリットとトレードオフ

メリット：安全議論の前提がそろうODDを明文化すると、「どこまでを設計・検証の対象にするのか」がはっきりします。これにより、センサ構成・アルゴリズム・冗長系・シミュレーション条件などの議論が整理され、安全性評価や認可審査の土台が明確になります。
メリット：運行判断を標準化できる天候・交通状況・工事情報などをODDに紐づけておけば、「どの条件になったら運休／減便／手動運転へ切り替えるか」をルール化できます。担当者ごとの勘と経験に頼らず、客観的な基準で意思決定できる点は、事業者・自治体・利用者のいずれにとっても安心材料になります。
メリット：サービス拡張のロードマップが描きやすいODDを軸にすると、「今のサービスがどこまでカバーしていて、今後どこまで広げたいのか」を地図や表で示せます。これにより、センサの追加・インフラ整備・ダイヤ改定・規制との調整など、投資の優先順位づけが行いやすくなります。
トレードオフ：ODDを広げすぎると開発負荷とリスクが跳ね上がる「雨でも雪でもどこでも走りたい」と欲張るほど、必要なセンサ性能・アルゴリズムの複雑さ・試験パターン数が膨大になり、安全性評価が追いつかなくなります。特にレベル3では、ODD外に出たときのドライバー引き継ぎも含めて検討する必要があり、条件を盛り込みすぎると実現性が下がります。
トレードオフ：ODDを狭くしすぎるとサービス価値が伝わりづらい一方で、ODDを過度に保守的にすると、「ほとんどの時間は自動運転が使えない」という状況になりがちです。安全側の判断は重要ですが、利用者が期待するサービスレベルとのバランスを取りながら、段階的にODDを拡張していく姿勢も求められます。
向かないケース：ODDを明確に切れない業務・環境雪国の山岳路で除雪状況が日々大きく変わる場合や、工事・行事で通行条件が頻繁に変わる中心市街地など、「条件があまりにも流動的で毎日書き換えないといけない」ような場面では、ODDを詳細に定義するよりも、現場裁量を前提にした支援システムとして位置づけたほうが現実的なケースもあります。

要点

ODDは、自動運転システムの「守備範囲」を決める設計情報であり、安全性評価・認可・運行判断・ダイヤ設計の共通土台となります。
場所・道路種別・天候・時間帯・交通状況・インフラ条件などを組み合わせて、「ここまでなら自動運転を許可する」という線を引きます。
ODDは一度決めたら終わりではなく、運行データやヒヤリハット、技術進歩に応じて、少しずつ更新・拡張していく「生きたルール」として扱うことが重要です。

公式ストアAmazon.co.jp毎日お得なタイムセール。日用品からガジェットまで幅広くチェック。タイムセールを見る → 実務の勘所

まずは「地図＋表」でラフに描く最初から完璧なODD仕様書を作ろうとすると動けなくなります。地図上に「自動運転候補ルート」を描き、そこに「天候」「時間帯」「速度」「インフラ条件」を簡単な表で紐づけるところから始めると、関係者間でイメージを合わせやすくなります。
安全チームと運行チームの両方が読める言葉にする技術仕様だけでODDを書くと、運行現場や自治体担当には伝わりにくくなります。逆に「晴れの日の昼だけ」といったざっくり表現だけだと安全審査に耐えません。「技術用語」と「現場用語」を並記し、誰が読んでも同じ解釈になるような表現を心がけると安心です。
「ODD外に出そうになったとき」の振る舞いを具体的に決めるODD定義とセットで、「ODD外に近づいたときに、システムはどう警告し、どのくらい前に減速・停止するのか」「オペレーターやドライバーに何を求めるのか」を決めておきます。ここの設計が曖昧だと、レベル3/4のレベル分け自体が揺らいでしまいます。
変更履歴と理由を必ず残す実証・本番を通じてODDを見直すたびに、「どの条件を」「なぜ変えたのか」「どのデータに基づくのか」を簡潔に記録しておきます。後から振り返るときや、第三者への説明、監査対応にとって大きな助けになります。
想定外の事象をODDレビューに必ずフィードバックするヒヤリハットや軽微な接触など、「ギリギリで回避できた」事象こそ、ODDの見直しに直接つながります。事故調査だけでなく、「ヒヤリハットレビュー会」を定期開催し、ODD定義に反映させる場を意識的に作っておくと、現場知と設計知がつながります。

設計・実用観点観点使われる場所・シーン代表例設計上の要点自動運転システムの要件定義、SAEレベルの決定、安全性評価・認可申請の準備・対象とする道路種別（高速／都市幹線／生活道路など）の選定・天候・視程・路面状態・時間帯など、環境条件の範囲をどこまで含めるかの議論・センサ構成・冗長構成・インフラ協調（V2X／専用レーン／路側センサ）の有無とODDのすり合わせ・想定シナリオとODDの対応表作成（例：この交差点タイプは含める／含めない）運用/保守ダイヤ策定・運行可否判断・一時運休／減便判断・ODD変更の承認プロセス・天候情報（降雨量・積雪量・路面温度・視程など）を取り込んだ運行可否ダッシュボード・工事・事故・イベント開催に伴う一時的なODD縮小と、迂回ルートの設定・ODD変更時の社内承認フロー（技術・運行・法務・広報）と利用者への告知方法・ヒヤリハット／事故レビュー会でのODD再検討と、マニュアル・教育資料の更新 KPI

ODD内走行比率（日次・%）：1日あたりに自動運転システムが走行した総距離のうち、「ODD条件を満たしていた状態で自動運転モードだった距離」の割合。日次集計でP50/P95を確認し、季節や天候の影響を見ます。初期導入では50〜70%、成熟すると80〜90%を目指す、といった目安設定が考えられます。
ODD逸脱警告率（件/1,000km）：ODD外に近づいたために発生した警告・自動減速・モードダウンの回数を、走行距離1,000kmあたりで集計した指標。週次・月次でP95を管理し、1〜数件/1,000km程度に抑えることを目標とするケースが多いです。
ODD起因の運休・減便時間（月次・h）：悪天候やインフラ状態の悪化など、ODDを満たせないことを理由に運休・減便した時間の合計。月次で合計時間とP95路線を確認し、「安全側の判断は維持しつつ、過度にサービスを止めていないか」を評価します。
ODD変更頻度（回/四半期）：ODD定義（エリア・天候条件・時間帯など）を変更した回数。多すぎる場合は設計が安定していないサイン、少なすぎる場合は改善機会を逃しているサインとも言えます。四半期に数回程度を目安に、「計画的なアップデート」と「緊急避難的な変更」を区別して管理します。
ODD違反ゼロ運行日数（連続日数）：ODD外での自動運転モード継続や、マニュアルで禁止された条件での運行が一度も発生しなかった連続日数。SLOとして「30日連続達成」を目標にするなど、組織全体での意識づけに使えます。

公式ストアAmazon.co.jp毎日お得なタイムセール。日用品からガジェットまで幅広くチェック。タイムセールを見る → 代表的な規模感・数値の目安

エリア・距離の目安典型的なレベル4シャトルでは、数km〜十数km程度のルートをODDとして定義し、数カ所の乗降ポイントと数十本/日のダイヤを組む構成がよく見られます。一方、レベル3の高速道路自動運転機能では、数百km以上の高速道路ネットワークがODD対象となることもあり、その場合は「地理的範囲」よりも「道路種別」と「交通状況（渋滞時のみ等）」がODDを決める主因になります。

天候・視程条件の目安初期導入フェーズでは、「降雨量◯mm/h未満・降雪なし・視程◯m以上」といった比較的保守的な条件から始めるケースが多いです。徐々に実績を積み、センサやアルゴリズムの性能が確認できてくると、「小雨・みぞれ」「視程低下時の減速運行」など、条件付きでODDを拡張していくことが現実的な進め方です。

速度域の目安街中シャトルでは、20〜40km/h程度の低速域にODDを絞ることで、万一の事象が起きた際のリスクを抑えつつ運行が可能になります。高速道路のレベル3システムでは、「渋滞時（たとえば60km/h以下）限定」からスタートし、その後徐々に速度上限を引き上げるアプローチが取られることもあります。

ODD拡張のスピード感実証から本格運行に移行するまでの数年〜十数年のスパンで見ると、ODDは「毎年少しずつ広がっていく」イメージになります。ただし、事故・大きなヒヤリハット・規制強化などにより、一時的に縮小されることもあります。数値目標として、「年間でカバー時間・カバー距離を10〜20%ずつ拡大するが、安全KPI（事故・ヒヤリハット・ODD逸脱警告率）は悪化させない」といった二軸の目標設定がよく検討されます。

運用とトラブルシュートの勘所

ODDログを「場所＋時間＋理由」で残すいつ・どこで・なぜODD外と判断されたのかを記録しておくと、あとから「この条件はもう少し攻められる」「ここは逆に危ないので縮小すべき」といった議論がしやすくなります。単なる「運休の有無」だけでなく、「理由」を必ずログに残す文化を作ることが大切です。
現場判断とシステム判断のズレをチェックする運行管理者やドライバーが「これは危ないから止めよう」と判断したケースが、システムのODD判定では「OK」とされていた、というズレは貴重な学習材料です。逆に、システムが頻繁に警告するが、現場から見ると安全側に寄りすぎている場合もあります。両者のギャップを定期的にレビューする場を設けると、ODD定義の質が上がります。
異常時には「ODD外に出ていないか」を必ず確認するヒヤリハットや軽微な接触が発生したとき、その状況がODDの範囲内だったのか、もともと想定していなかった範囲なのかを切り分けることが重要です。ODD内なら「設計や検証の見直し」、ODD外なら「ODD定義・運行ルール・教育の見直し」というように、対策の方向性が変わってきます。
ODD縮小の影響をサービス側とセットで評価する安全上の理由からODDを縮小する判断は尊重されるべきですが、その結果として「最終バスが運休になり帰れない人が増える」「買い物難民が増える」といった社会的影響も生じます。可能な範囲で代替手段を検討しつつ、安全と利便性のバランスを説明できるようにしておくと、関係者の納得感が高まります。
縮小→改善→再拡張のサイクルを前提にする一度縮小したODDは「もう戻らない」のではなく、「いったん安全側に寄せて、改善策が整ったら再拡張するもの」として位置づけておきます。そうすることで、現場からの「縮小提案」が出やすくなり、安全側の判断がしやすくなります。

Pro向け特化PCOZgaming Pro向け特化パソコン業界最安プロレベルのスペックがこの価格。OZgamingの最新カスタムPCで、あらゆる作業を根底から効率化しよう。OZgaming公式で見る → 関連技術との関係・違い

SAE自動運転レベルとの関係SAEレベルは「人とシステムの役割分担（誰が運転主体か）」を表す指標であり、ODDは「そのシステムがどんな条件のときに働けるか」を表します。たとえばレベル3は「ODDの内側ではシステムが主体、ODD外や限界時には人が引き継ぐ」、レベル4は「ODD内ならシステムが主体で、ODD外に出た場合もシステム側で安全停止まで責任を持つ」といった関係になります。

ジオフェンスとの違いジオフェンスは位置情報に基づく「地理的な範囲」を区切る考え方で、ODDの一部です。ジオフェンスだけをODDだと誤解すると、「同じエリア内であれば豪雨・大雪でも動けてしまう」設計になりかねません。ODDでは、地理的な範囲に加えて、天候・時間帯・道路種別・インフラ・交通法規など、より広い条件をセットで扱います。

機能安全・SOTIFとの関係機能安全（ISO 26262）はハードウェア・ソフトウェアの故障時の安全性、SOTIF（ISO 21448）は故障がなくても認識限界などから生じる危険を扱います。ODDは、「どのような環境・シナリオを前提として安全性を評価するか」の前提条件を定める役割を持ち、機能安全やSOTIFの分析を行う前提として位置づけられます。

HDマップ・V2Xとの関係高精度地図（HDマップ）やV2Xは、ODDを広げるための有力なツールです。たとえば「地図整備が済んだエリアだけをODDに含める」「V2X協調信号がある交差点だけ右折自動運転を許可する」といった設計が可能になります。一方、インフラに依存しすぎると、故障時やサービスエリア外でODDを縮小せざるを得ないため、冗長性とのバランスが重要です。

導入ステップとチェックリスト

1. 検討フェーズ：ユースケースとステークホルダーの整理まず、「誰のために」「どのような移動を」「どのエリアで」提供したいのかを文章と図で整理します。同時に、自治体・事業者・メーカー・保険会社・警察・地域住民など、ODDに関係するステークホルダーを洗い出します。
2. 設計フェーズ：ODD候補の作成と安全評価地図と表を使ってODD候補を作り、安全チームと運行チームでレビューします。このとき、「この条件が抜けていないか」「この条件を含めるとセンサ・アルゴリズム・試験の負荷がどれくらい増えるか」をセットで検討します。
3. PoCフェーズ：限定ODDでの試験運行まずは最も保守的なODD（晴天・日中・低速・単純ルートなど）で試験運行を行い、センサログ・ヒヤリハット・利用者の声などを集めます。この段階で、ODDログのフォーマットやダッシュボード、アラーム設計も固めていきます。
4. 本番導入フェーズ：運行ルールと教育の整備ODD定義を運行マニュアル・オペレーター教育・自治体との覚書・利用者向け案内など、さまざまな文書・ツールに落とし込みます。「自動運転が使えるとき／使えないとき」を、技術に詳しくない人にも伝わる言葉で説明できる形にしておきます。
5. 運用レビュー・拡張フェーズ：データに基づくODDの見直し定期的にODD関連KPI（ODD内走行比率・逸脱警告率・運休時間など）とヒヤリハット事例をレビューし、「どこを広げるか／どこを絞るか」を検討します。その結果をODD仕様書・マニュアル・教育・対外説明に速やかに反映させ、PDCAのサイクルを回していきます。

よくある間違い

ありがちな見方：ODDは「どこを走れるか」という地図情報だけを決めればよいと思ってしまうおすすめ：地理的な範囲だけでなく、天候・時間帯・道路種別・速度域・インフラ条件・交通状況など、少なくとも数カテゴリに分けて整理します。ジオフェンスはODDの一部にすぎない、と意識しておくと安全です。
ありがちな見方：安全のためにとにかくODDを広く取っておけばよいと考える（「どこでも動くなら安全だろう」）おすすめ：ODDを広げるほど設計・検証すべき条件が増え、結果として安全性評価が粗くなるリスクがあります。まずは絞り込んだODDから始め、データに基づいて少しずつ拡張するアプローチを基本にします。
ありがちな見方：ODDは技術仕様書に書いておけばよく、現場のマニュアルや利用者向け案内にはあまり関係ないと考えるおすすめ：ODDは運行判断や利用者への説明にも直結します。「いつ・どこで・どのように自動運転が止まる可能性があるか」を、現場と利用者にも分かる形で伝えることが、信頼確保につながります。
ありがちな見方：事故やヒヤリハットが起きたとき、「技術側の不具合」か「運転者のミス」かだけに注目してしまうおすすめ：事象がODD内だったのか外だったのかを必ず確認し、「想定外の環境だったならODD側の見直し」「想定内なら設計・運用側の見直し」と整理します。誰か一人の責任にするのではなく、ODD定義も含めたシステム全体で考える視点が大切です。
ありがちな見方：ODD縮小は「後退」であり、できるだけ避けるべきものだと感じてしまうおすすめ：ODD縮小は、リスクが見えた時点で早めに安全側に寄せるための健全な対応です。縮小→改善→再拡張のサイクルを前提に設計しておくと、現場から「危ないから一度範囲を絞ろう」という提案が出やすくなります。