このサイトは、2011年6月まで http://wiredvision.jp/ で公開されていたWIRED VISIONのコンテンツをアーカイブとして公開しているサイトです。

山路達也の「エコ技術研究者に訊く」

地球と我々の未来の行方を左右するかもしれない、環境系技術研究の現場を訪ねる。

ネットワーク技術が実現するエコ物流 (1)

2008年6月17日

  • 1/2
  • 次のページ

CO2などの温室効果ガスを削減するための取り組みがさまざまな分野で始まっている。そのうち、運輸関係において温室効果ガス削減に効果があるといわれているのが、共同集配を始めとしたエコ物流だ。この共同物流を効率化するための「プログラミング言語」を、国立情報学研究所の佐藤一郎教授が開発したという。プログラミングとエコ、この二つはいったいどう結びつくのだろう?

なかなか広まらないエコ物流

──エコ物流のためのプログラミング言語を開発されたということですが、これはどういう用途に使われるのでしょうか?

このシステムは、共同集配を効率的に行って、トラックの数や移動距離を減らすことを目指しています。そうすることで、燃料を節約できますし、CO2の排出量を抑えられることになります。

例えば、自動車組み立て工場と、そこに納品する複数の部品工場があったとしましょう。従来の物流ですと、個々の部品工場がトラックを用意して組み立て工場に納品していました。これだとトラックは部品工場ごとに必要になりますし、帰りの便が空っぽになってしまうという無駄があります。

一方、ミルクランという共同集配方式では、トラックが複数の部品工場を巡回して部品を集め、組み立て工場に向かうことになります。

こうした共同集配は、すでにいくつかの企業が運用を開始しています。しかし、参加している事業者がせいぜい2、3社で、それ以上にはなかなか広がっていないのが現状です。

[拡大版を見る]

既存方式とミルクラン方式の比較。ミルクランの方が無駄な移動を少なくできる。

──どうして、共同集配は広まらないのでしょう?

実際の物流では集配のタイミングや順番などさまざまな制約がありますから、現在は事業者同士で話し合いを行って最適な経路や便数を調整しています。そうした調整を人手で行うには、2、3社が限度なのです。

しかし、多くの企業が参加できるようにするには、路線バスのようにさまざまな便が運行され、行きたい経路を自由に選べるようにする必要があります。

経路情報をシンプルに記述

──そのためのプログラミング言語を開発したと。

トラックの経路や集配時間などの条件をプログラム化してしまおうと考えました。そうするには、まず経路を表現するためのプログラミング言語が必要になります。

例えば、A、Bという2つの集配先があった場合、AからBに回らなければいけない場合と、AとBのどちらを先に回ってもよいことがあるでしょう。私の開発した言語では、前者の場合は「A;B」、後者は「A%B」と表します。これ以外にも、到着時間の指定や所要時間などの指定が可能です。

[拡大版を見る]

集配条件の記述例。複雑な経路指定をシンプルに記述できる。

──既存の言語はこういう用途に向かないのですか?

汎用的な言語では、経路を表す以外にもさまざまな機能を備えていますから解析するのが難しくなります。また、いろいろな書式で書けてしまうと、同じ経路の記述も人によって変わってきてしまいます。

もう1つのメリットは、表現のコンパクトさにあります。RFIDタグや二次元バーコードなどに経路情報を埋め込むのも簡単になるわけです。

サーバーに問い合わせて最適なトラック便を選択

──運用の流れは具体的にどのようになるのですか?

まず、トラック運行事業者には、運行しているトラックの経路をこの言語で記述してもらい、「トラック選択サーバー」に登録してもらいます。といっても、トラックの運行計画書さえあれば自動的に適切な記述に変換されますから、運行事業者に必要なのは登録に使う端末だけです。

一方、荷主や集配先は、集配条件をこの言語で記述し、トラック選択サーバーに送信します。トラック選択サーバーが問い合わせを受けると、登録されているトラックの中から条件に該当する便を選択して表示するという仕組みです。複数便が存在する場合は、移動時間や移動距離の短い順に表示されることになります。

Googleなどの検索エンジンではWebページを検索対象にしていますが、このシステムはトラックの選択に特化していると考えるとわかりやすいでしょう。

──システムによる検索が行われるのは、荷主がトラックの便を選択する時だけなんですね。

そうです。荷主が経路情報をRFIDタグや二次元バーコードに埋め込んでコンテナなどに貼っているなら、それをスキャンするだけでどのトラック便に乗せるべきかが即座にわかります。

システム自体は、集配中の状況に対して一切関知していません。トラックの運行事業者は登録した計画通りに運行することになります。個人向けの宅配便と異なり、業務向けの物流では運行計画書通りにトラックを走らせることになっていますから、これで問題はないでしょう。

──渋滞や事故が起こった時はどうするのですか?

経路記述言語には、渋滞や事故時の代替経路を記述することができますし、到着時間に幅を持たせることもできます。ただし、事故が起きた時に何でもかんでもリカバリーできるようにしようとすると、システムのコストが膨れあがってしまいますから、そういう仕様にはしていません。現在の物流でも、事故などの例外的な状況には対応させていませんし、現実的に対応させる必要もないでしょう。

──このシステムでは、どういう利用者を想定しているのでしょう?

経路をプログラムとして記述できるメリットは、どのようなトラック運行事業者でも荷主でも共同集配に参加できるということです。現在の共同道集配は非常にクローズドになっていますが、それをオープンにする仕掛けといえます。

人手で経路を選択する手法では、多くの事業者が参加する共同集配は実現できないでしょう。私の研究がベストな解かどうかは別にして、何らかの形で経路を記述して、自動的に経路を選択するようにしなけばならないと思います。

──物流のためのプログラミング言語と聞いて、巡回セールスマン問題(セールスマンが決められた都市を一度ずつ回る場合の最短経路を算出する問題)を連想しました。

巡回セールスマン問題は計算量が膨大な、非常に難しい問題です。また、ベストな解があったとしても、その通りにトラック便が走っていなければどうしようもありません。現実には、最短経路を見つけるのはあまり意味がないんですよ。

[拡大版を見る]

システムの全体像。運行事業者側は、ほとんど設備投資が必要ない。

  • 1/2
  • 次のページ
フィードを登録する

前の記事

次の記事

山路達也の「エコ技術研究者に訊く」

プロフィール

1970年生まれ。雑誌編集者を経て、フリーの編集者・ライターとして独立。ネットカルチャー・IT・環境系解説記事などで活動中。『進化するケータイの科学』、『弾言』(小飼弾氏との共著、アスペクト)、『マグネシウム文明論』(矢部孝教授との共著、PHP新書)など。ブログは、こちら

過去の記事

月間アーカイブ