「通信屋と交通屋のITS四方山話」
(完全版)
by Akahane & Yoshikai


[交通屋]
交通屋の私からすると,ITSが脚光を浴びるようになってから,通信,情報,データベース,車両走行制御,あるいは各種センシング技術の分野から,様々な要素技術やそれらを組み合わせたハードウェアシステムが,交通分野に脈絡もなくポンポンと投げ込まれているという見方をしがちです.
通信屋さんから見て,ITSの世界での交通屋,あるいは交通工学とは,どんな存在なのでしょうか?

[通信屋]
従来,通信屋は情報はビット単位でカウントしていて,情報の「意味」や「価値」まで踏み込んで検討してきていません.シャノンの情報理論の限界であることは認識しているのですが,その方がシステム設計が簡単だし,ディジタル化さえできれば全ての情報が処理できたからです. しかし,マルチメディアといった場を考えると,そうも言ってられなくなって,メディア毎の料金をバイト単位に見積もったりし始めています.
例えば,「テキスト」は本とか新聞とかの紙媒体で流通・消費されると,1KBあたり0. 1〜100円,「漫画・イラスト」は同様に紙媒体流通で1KBあたり0.01〜0.1円くらい,「音楽」はCD媒体で1KBあたり0.001〜0.01円,「写真集」など高精細静止画も紙媒体で1KBあたり0.001〜0.01円,「動画・ビデオ」はMPEG圧縮で評価して購入で1KBあたり0.001円前後,レンタルで0.00001〜0.0001円なんて見積もりを出して,情報と料金のマッピングを取ったりしています.

[交通屋]
電光掲示板(可変情報板)で混雑情報を表示するときに,1文字あたりや1文あたり何円かかるかなどと考えたこともありませんでした.もっとも,電光掲示板などで提供する情報に関しては,「情報提供料」などを個別に収受する訳ではないですから,明確に意識する必要もなかったのでしょうが….

[通信屋]
いや,私もバイト単位の見積もりが,これからもオールマイティだとは考えていません.本来,情報とは,このフォーラムでも議論されているように,使う人によって価値が決まるものであり,こんな升で決められるものではなく,アプリケーション(ここでは混雑情報)からの評価が必要と思っています.
その意味で,いつだったか「交通工学の議論が上流であり,通信屋は下流だ.」と申し上げました.

[交通屋]
意外です.私は「交通工学は下流側に位置していて,上流から次々と流れてくるITS技術を,訳も分からずに拾い集めている」ような印象を持っています.交通と通信のそれぞれで自分の立場を受動的にとらえているところなどは,お互いに少し滑稽ですね.

[通信屋]
このフォーラムでの議論をフォローしていて,通信屋・情報処理屋として口を出したくなるような論点がいくつかありました.例えば,均一な交通情報をユーザー毎にカスタマイズする議論がありましたが,我々はこの辺りの技術的な知見・ノウハウをかなり持っていますので,「ディープな議論」にも参加できると思います.
但し,本当に交通情報をカスタマイズしてユーザーに提供したほうが良いのかどうかは,要議論だと思います.ハイテクになってユーザーが喜ぶことは希で,シンプルな方が良いことが多いのは,良く経験することです.
このフォーラムで現在議論されている「混雑情報」ではありませんが,北海道での実験で峠の積雪の深さを情報として流していても,ドライバーは平気で大雪の峠に車の乗り上げ,そのまま立ち往生してしまうケースが多々発生していましたが,インターネットで画像情報をそのまま流したら,同じ積雪状態なのに,だれも運転しなくなったそうです.

[交通屋]
少し話の方向からずれてしまうかも知れませんが,「道路案内標識」で表示されている地名でも,似たような例があります.「これはいくら何でもローカル過ぎやしないか?!」と思うような地名が案内に使われているために,標識が一番の対象とすべき地理不案内なドライバーはかえって混乱してしまうようなことも珍しくありません.
たぶん,道路網を熟知した人が,これまた熟知したドライバーから異論が出ないように考え抜いた結果が,地理不案内な人間にはかえって分かり難い標識を生んでいるのだろうと想像しています.

[通信屋]
渋滞・混雑情報にしても,同じかもしれません.道路に沢山のカメラをセットし,何もシステム側はせずに,垂れ流しで提供し,判断は,ユーザーが自身で判断するというのも,正解ではないでしょうか?
アメリカやヨーロッパで道路状況の画像をそのまま送っていますが,その効果を評価したレポートは無いのでしょうか?

[交通屋]
欧米ではどうなのか良く知りませんが,日本だと道路にカメラを設置して,伝送回線を引っ張り,画像を表示するところまでは通信屋さんの領域で,その画像がどんな風に効果を上げているか調査・分析するのは交通屋ですよね.でも,交通屋としては,ただ画像を垂れ流すのでは不足で,もうひとひねり,あるいはふたひねりしないと,効果評価する気にもならないのではないかと思います.
電光掲示板の混雑情報が渋滞の緩和にどれほどの効果を上げているかが分析されはじめたのも,ここ数年のことでしょう.もっとも,それまでは都市高速上で混雑情報を見ても,道路網自体が未整備だったために,それによって経路を変更するような余地がほとんど無く,ただ気休めに過ぎなかったこともありますが….

[通信屋]
経路誘導情報類は,多分,走行履歴や個人の好み等からカスタマイズされる方が良いと思います.

[交通屋]
そうでしょうね.それから交通の目的や,通行料金との絡みでその人の懐具合なんかも関係してきそうです.
ところで,情報・通信というと,交通屋はいわゆる「交通情報」あるいは「混雑情報」のような,ドライバーなり利用者なりが直接受信して判断に役立てるような内容を想起しがちです.
でも,情報・通信の分野で前提とされているのは,車車間通信のような走行制御,つまり衝突回避のような安全分野の課題の比重が,少なくとも現状では大きいような気がしますが,それは誤解でしょうか?

[通信屋]
ITSに関わりをもっている情報・通信関係の各分野に応じて,答えが変わってくると思います.
いわゆる無線領域を中心に検討を進めてきた人たちは,車車間での車輌制御みたいな領域がまずターゲットにありまして,そこでは「情報の意味」まで,踏み込んだ検討は不要です.
が一方では,車輌内での情報提供に応じて何らかの判断をする場合を,情報・通信系ではターゲットにしている人たちもおります.その人たちは,情報の内容そのものも研究対象にしなければ,どうにも検討が進みません.
現状でどちらの割合が多いかというと,前者ではないかと感じています.が,後者のタイプが,絶対に増えると確信しています.

[交通屋]
交通屋の隣近所がが増えそうで,楽しみです.
もうひとつ質問があります.いわゆる交通情報は,もともとは車に帰属するべきものではなく,移動の主体である人,あるいは輸送される物について回るべきものと思います.そんなシームレスな情報メディアは,本当に実現可能なのでしょうか?
また,それが実現可能であっても,シームレスであるがために,あるいはそうなると交通情報に限定されたメディアでは無くなるがために,現状の交通情報専用のメディアには無い制約のようなものが出てくる可能性はないのでしょうか?

[通信屋]
本質を突いたご質問と思っています. 私が交通屋さんの議論に参加している理由も,同じ疑問を持っているからです.私の最終ターゲットは,ITSに関連する情報をシームレスに接続・処理して,適切な端末(車や,携帯など)側に渡すネットワーク・アーキテクチャを作ることです.
通信屋の立場から言いますと,何でもかんでも車に無条件で渡して,そこで判断させれば良いとの議論には賛成できかねます. 判断の主体は,車かも知れませんが,恐らくインフラ側での交通情報の収集と共に,ある程度の編集・処理が絶対必要だし,情報の優先制御や配信方法の選択なども必要となるはずです.その時に,「交通情報の意味・内容」の理解をシステム全体で実現する必要があります.

[交通屋]
同感です.フォーラムの大部屋でも議論されている,「利用者均衡」と「システム最適」を如何に案配すべきかといった議論にも通じる問題提起です.

[通信屋]
だいたい車で判断するという議論自体,少し変で,本当の判断は,ドライバーであり,ユーザーにとってその情報がどう生かされるかを議論すべきですよね.そうすれば,ユーザーは自転車に乗っているかもしれないし,歩いているかもしれない.

[交通屋]
私もITSの究極の目標のひとつは,いわゆるインターモーダリティーによる人や物の移動の最適化だと思っています.そこでは,交通・輸送手段は文字通り手段でしかなく,あくまでも主体は人,あるいは物です.

[通信屋]
要はユーザーとインフラ側の機能分担と,その為の情報処理がテーマとなりますし,恐らく,そこでの情報は単なる交通情報・混雑情報のためのシステム・アーキテクチャではなく,ITS全体での情報を対象にしたメディアフリーなものになるはずです.
そんなマルチメディア情報を扱うためには,まず,情報自体について知らねばなりません. ディジタル化された情報の扱いについては,通信・情報屋は知っているのですが,情報の意味は,それぞれのアプリに応じて違うために,ここのアプリ毎に勉強しなければなりません. 交通工学での勉強は,まさにそのためのものです.

[交通屋]
交通屋としても,交通情報の中身が,通信システムにどのように関わって来るのか,教えていただきたいところです.



Copywrited by Japan Society of Traffic Engineers