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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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