Monohakobi Techno Forum 2019 レポート
「⾃律船の実現に向けたシステム・インテグレーション」
公開⽇: 2020 年 1 ⽉ 22 ⽇

Monohakobi Techno Forum 2019レポート

自律船の実現に向けたシステム・インテグレーション
MTI 安藤英幸

MTIでは，毎年11月に研究開発成果の報告会，Monohakobi Techno Forum(MTF)を行っていますが，昨年2019年は，11月25日(月)に東京，11月29日(金)に広島で，MTF2019として開催しました。1
MTF2019では「システムインテグレーション 〜自律船を目指して〜」を基調テーマとし，計6件の講演と1件のパネルディスカッションを行いました。
このレポートでは，当日の講演，パネルディスカッションの内容を踏まえ，自律船の実現に向けた課題を，主に操船，航海関係の機能に関するシステム・インテグレーションをどう進めるかと言う視点で整理したいと思います。また，レポートの後に，東京会場のパネルディスカッションの討議記録を補足資料として掲載しますので，合わせてご参照ください。

1. システム・インテグレーター
自律船を実現するには，多くのデータ点数を扱う大規模な自動化システムが必要になりますが，これを取りまとめる役割がシステム・インテグレーターになります。
一般の船舶におけるコンピューターを利用するシステムに関する規則として，2016年6月に改定されたIACSの統一規則，UR E22 Rev.2(On Board
Use and Application of Computer based systems)の中で，システム・インテグレーターの役割は次のように定義されています。1)(以下，IACSの統一規則UR E22 Rev.2より抜粋。)

1. Monohakobi Techno Forum 2019 レポート
https://www.monohakobi.com/ja/company/news/news_20191204/
1

Monohakobi Techno Forum 2019 レポート
「⾃律船の実現に向けたシステム・インテグレーション」
公開⽇: 2020 年 1 ⽉ 22 ⽇

System integrator
The role of system integrator shall be taken by the yard unless an alternative
organization is specifically contracted/assigned this responsibility. The system
integrator is responsible for the integration of systems and products provided bysuppliers into the system invoked by the requirements specified herein and forproviding the integrated system. The system integrator may also be responsiblefor integration of systems in the vessel.
If there are multiple parties performing system integration at any one time asingle party is to be responsible for overall system integration and coordinating
the integration activities. If there are multiple stages of integration different
System Integrators may be responsible for specific stages of integration but asingle party is to be responsible for defining and coordinating all of the stages ofintegration.
(以上)
この定義のポイントをまとめると，以下のようになります。
lシステム・インテグレーターの役割は，契約/指名に基づき何れかの組織が担うか，それ以外の場合には造船所が担う。

lシステム・インテグレーターは，統合された全体システムの要求仕様に基づき，サプライヤーが提供するシステムや製品を，統合する責任を担う。

l

複数のシステム・インテグレーションが何れかのステージ(設計，建造，コミッショニング，保守)で同時に行われている際には，一つの組織が，それら複数のシステム・インテグレーションの全体を取りまとめ，コーディネーションを行う責任を持つ。

l

複数のシステム・インテグレーターが，何れからのステージ(設計，建造，コミッショニング，保守)で，特定のシステム・インテグレーションの役割を担う場合においても，一つの組織が，全てのステージを通して，
それら異なるシステム・インテグレーションを取りまとめ，コーディネー
ションを行う責任を持つ。

2

Monohakobi Techno Forum 2019 レポート
「⾃律船の実現に向けたシステム・インテグレーション」
公開⽇: 2020 年 1 ⽉ 22 ⽇

このように定義されるシステム・インテグレーターの役割，責任は，コンピューターシステムを船舶に搭載する上での一般的な考え方で，そうした本船搭
載のコンピュータシステムの最たるものと言える自律船の実現における，シス
テム・インテグレーターの役割を考える上でもベースになると思います。
今回のパネルディスカッションの冒頭で，日本海事協会(以下，NK)の松本俊之・所長による講演で，NKが今年(2020年)1月に発行の「自動運航，自律運
航に関するガイドライン (Ver. 1.0)」2)の概要について紹介を頂きました。自律船の設計開発，船舶への搭載，船舶の運用の各ステージにおいて，実施するべき作業，システム・インテグレーターを始めとする主要な関係者，検証されるべき内容を明確にするもので，先のIACS UR E22 Rev.2とも非常に親和性の高い形で，システム・インテグレーター(システム統合者)の役割が定められています。

2. 日本の海事産業におけるシステム・インテグレーター
さて，従来，日本の海事産業では，船の設計，建造，コミッショニングまでを統括するのは造船所，その後の保守，運用は，船主であり船舶管理会社が統括する仕事，と明確に別れていますので，先のIACS UR E22Rev2に記載されている最後の点である，「一つの組織が，全てのステージを通して，それら異なるシステム・インテグレーションを取りまとめ，コーディネーションを行う責任を持つ」と言う要件は，どのように実現するかは業界としての課題と言えます。
今回のMTF2019の主題として，「システム・インテグレーション〜自律船を目指して」を取り上げたのは，正に，この認識を共有し，これをどのように解決していくかの議論を始めるきっかけとしたい，と言う背景からでした。
今回のパネルディスカッションの中で，各パネリストからは次のようなコメントがありました。

「機器メーカーだけでもなく，造船所だけでもなく，海運だけでもなく，三位一体となった形でシステム・インテグレーションを考えていかなくてはいけない。
今まで，こうした三位一体でのシステム・インテグレーションと言うのはやったことがかつて無いわけですので，こういったものについて安全性を3

Monohakobi Techno Forum 2019 レポート
「⾃律船の実現に向けたシステム・インテグレーション」
公開⽇: 2020 年 1 ⽉ 22 ⽇

検証すると言う役割が船級協会にあると思いますけれども，こういった意
義で，こういった大きな枠組みでシステム・インテグレーションを捉えていくのが船級の大きな課題かと思います。」(NYK小山智之・常務)「基本的には，全体のシステムが，A地点からB地点に貨物を運ぶことに必要なコンピテンスを正しく有しているか，十分な安全上の完全性を伴っているか，が保証される必要があると考えます。それを担保するのがシス
テム・インテグレーターの仕事だと考えます。そしてシステム・インテグ
レーターの仕事は，システムを構成するサブシステムも含めた責任を持つことだと思います，と言うのも，自律船システムでは，航海計画，操船機
能，推進機能などのサブシステムに大きく依存しており，それらのシステ
ムが正しく動作し，相互に連携して動作することが自律オペレーションに必要だからです。
ここでチャレンジになるのは，既に今日，何度も議論になりますが，誰がownershipの役割を担うかと言うことです。ClassNKの松本さんは，(冒頭のプレゼンの中で)建造の段階，運航の段階，それぞれのフェーズで異なる
ownershipが存在すると言う説明をされましたが，私から見るとこのownershipは，あまり明確ではなくて，まだその明確でないownershipを誰が取るかは海事業界においてオープンな状況で，disruptionが起こって，誰かがそこで手をあげてownershipを取ると言っても良い状況のように思います。現状ownershipを持っていない誰かが，そのownershipを取りに行くと言うこともあり得る状況だと思います。
今後どのようになっていくか，皆さんは目にすることになるでしょう。自分にとっては，誰がそのownershipを取りに行くのが正しいことかはわかりませんが，ベンダーが仮にownershipを自分が担おうとしない場合には，誰かが間違いなくその役割を取りにいかなくては行けないと言うことは確かだと思います。それは造船所かもわかりませんし，別のシステム・インテグレーターかもわかりません。ただ，現在の造船所の全てが，そうした役割を担うコンピテンスや能力を持っているとは思いませんし，そうしたコンピテンスや能力をこれから持つように変わっていかないといけない，ビジネスを続けるために必要だと思う造船所もあると思います。そうした状況においては，現在，そうしたシステムを持つOEMが，システム・インテグレーターとしてその役割を担おうとすることは自然な流れだとも4

Monohakobi Techno Forum 2019 レポート
「⾃律船の実現に向けたシステム・インテグレーション」
公開⽇: 2020 年 1 ⽉ 22 ⽇

思いますし，ただ，それにはPROS/CONSがあって，と言うのも，海事産
業のエコシステムが，多分に数社のOEMに依存し，ロックインする形になるからです。
私から見ると，今日現在，この自律船の話題がどのような形に今後落ち着いていくのかをはっきり見通すことは非常に難しいですし，まだ多くのオープンな課題，変化する余地があると言うことは間違いないと思います。
そこに投資をしていく面白いタイミングであろうとは思いますし，チャレ
ンジをしながら成長をしていく状況にあるのだと思います。」(DNV-GL
Maritime スティアン・エリック・スーリ日本支社長)「我々も，非常にこのシステム・インテグレーターは重要だと思っていまして，最初の頃，自律船の話が出てきた時は，どちらかと言うとシステムの技術的なところにフォーカスして，人間がやっている作業をシステムがやれるかどうか，と言うことが，船級としても安全上も重要なことだと言うことでスタートしました。けれども，色々な方と色々とお話をしていると，特に船の場合，非常に作業，やるべきことが，例えば，操船を一つとっても，他のこととリンクしていますので複雑多岐にわたる。そうした中で，誰がどういった形で全体としてキッチリ自動化システムを使って安全運航を，自動化システムとしての安全性に責任を持ってやっていただくのか。多分，いろんなやり方があるのだと思います。三位一体の形で協力してやることもあれば，大きいところがガチッと抑えてやる，色々な形態がある。ただ，その場合に，どのような形であっても安全に自動化システム
がきちんと運航し，管理される，これをしっかり見ていくのが我々の仕事だと思っています。ここは是非皆さんの色んな意見を聞きながら，安全性の考え方を作っていきたいと思っています。これは我々だけではく，DNVGLさんも含めて，船級の共通の使命だと思っています。」(ClassNK 松本俊之・所長)「欧州では，先程，皆さんが仰ったように，KongsbergやWartsilaが船全体のシステム・インテグレーションに乗り出していると認識しています
けれども，日本では，大規模なシステム・インテグレーションと言うのはこれまであまりされてきていないのではないか，と思っていまして，航海計器，機関諸々含めて一つのシステムを動かすためのインテグレーション
5

Monohakobi Techno Forum 2019 レポート
「⾃律船の実現に向けたシステム・インテグレーション」
公開⽇: 2020 年 1 ⽉ 22 ⽇

に関するそもそも知見とか技術者の確保というところから必要なのかなと考えています。今日，プレゼンの中で，BEMACの村上室長からありました日本版のシステム・インテグレーションも面白いと思いましたし，そも
そも海運会社も含めたシステム・インテグレーションと言うところまで
は，欧州でも進んではいないのではないかと考えていますので，日本において，海運会社も含めてすべてのステークホルダーを入れた全体で，日本でのシステム・インテグレーションの日本でのあり方を議論するには良いタイミングに来ているのではないかな，と思っていまして，今日のセミナ
ーもすごく良いタイミングで行われていると思います。」(船舶技術研究協会 野間智嗣氏)
また，パネルディスカッションに先立つ講演の中で，BEMACの村上誠・室長からは，日本の海事業界に即したあり方として，船のライフサイクルを通して関わる，サービス・インテグレーターと言うあり方の提言がありました。

図1. ライフサイクル収益を高めるサービスインテグレーターの育成3)
以上のように，自律船に代表される高度なシステムを実現する上では，設計開発〜運用までを通して，コーディネートを行う役割が必要であり，そのあり方として，“三位一体”，“サービスインテグレーター”と言った具体的な提案もありました。また，様々な形が出るであろう中で，何れの形で実現されるにせよ，それを船級がしっかり支えていく必要がある，こうした指摘もありました。先ずは，今回のNKのガイドラインのような形で，誰がそうした役割を担
6

Monohakobi Techno Forum 2019 レポート
「⾃律船の実現に向けたシステム・インテグレーション」
公開⽇: 2020 年 1 ⽉ 22 ⽇

うにせよ，設計開発，搭載，保守・運用と言った各ステージで，やるべきタス
クや必要なツールを明らかにし，こうしたプロセスを実際の実証を通じて，ブラッシュアップしていくことが，開発する技術（プロダクト）そのものと同等の重要さを持つのだろうと思われます。

3. 自律船に固有の課題
次に，コンピュータを利用した高度なシステムのうち，自律船に固有の課題についても触れたいと思います。自律船と言っても，様々なレベルがあり，こ
こでは，今回のパネルディスカッションと同じく，次のような想定で考えたいと思います。

想定する自律船：航海・湾内操船・離着桟を，船上の操船者の監視の下で，高度に自動化したシステムが担う有人の自律船。
これは，こうした有人の自律船のあり方が，比較的，近い将来の実現が予想される形であること。また，完全自律船(=無人)や遠隔操船などを想定すると，達成するべきシステムの複雑さ・高度さが増して，解決するべき課題が広がること。と言った理由です。
まず，実際にこうした自律船の機能を使って，運航の現場を担う実務者の立場からご発言頂いた，日本郵船・小山常務のコメントを紹介したいと思います。

「まず，システムに完全なものはあり得ないと認識しており，不具合が生じた場合には船内操船者，或いは，リモートコントロールステーションのスタッフが介入する必要があると思いますが，懸念点は３つくらいあると思っています。
1つ目は，システムは意図通りに動いていたとして，航行上の危険があることをシステムが完全に認識することが果たして出来るのか？1つ2つの船を避けて行くのは良いのですけれども，その行動によってまた新たな危険が生じないか，それが連続しておきたとき，あるいはその自船の行動によって周囲の船舶がまた違った動きを取るとき，予めシステム側が予測していなかった動きをしたときに，確実に判断出来るのかと言うところが心配です。
7

Monohakobi Techno Forum 2019 レポート
「⾃律船の実現に向けたシステム・インテグレーション」
公開⽇: 2020 年 1 ⽉ 22 ⽇

今，そうした判断を人間がやっているのですけれども，これだけ人間があたふたとやっているものを，簡単に，コンピュータの方が早くて正確だと言うものの，果たして，どのようにアルゴリズムが達成出来るのか？まだそういったものを見ていないと思いますから，心配としてあります。
2つめに，そう言ったものが的確に判断出来たとして，危ないよと言った
ときに，システムだけでワークすれば良いのですけれども，フォールバッ
クの役割として人間が入らなくてはいけないときに，十分に時間的余裕がある時期に知らせてくれるのか？と言う心配があります。十分に前広にと言うことは，まだ，危険かどうかを判断する前に，もしかしたら「危険だよ」というような形で知らせてくれれば人間としてはありがたいわけですけれども，おそらくコンピュータの世界は，なかなかそう言うふうには切り分けられないと思いますので，そこに懸念があります。
それから，システムそのものが不具合に陥った際に，それを確実に認識できるか？(システムが)「僕は間違っていました。不具合でございます。」と，言うことが確実に出来るのか？間違えたときの代替え手段は用意されているのか，と言うことが懸念されます。」 (NYK小山智之・常務)
以上の3つのコメントは，アルゴリズムを開発する，あるいはシステムを作る技術者にとっては，かなり難しい課題を提示されていると思います。やはり実際に船長が信頼できるレベルのシステムを作ることが，非常に難しい，深遠な問題だと言うことを改めて認識させられます。
まず，1つ目の指摘に関連しますが，周囲の船舶の現在の行動が正しく把握出来たとして，それに基づいて，近い将来の行動が予測出来たとして，そこで最適な航路，スピードを判断する，これは問題として定義し，解決するロジッ
クを行うことは可能であろうと思うのですが，次の自分が取った行動によって，それを受けて相手が違った手を取る，となると（現実には，もちろんそのとおりですが，問題を解く上では，何手先まで読むかと言った問題に映る），
相手が一般の船舶の船長の操船の場合も，自律船の場合も，両方あると思いますが，その判断を，幅を持って予測して，それぞれの可能性において，次に自分の取る手を考える，と途端に探索する解空間が途方も無く広がる，と考えられます。この場合，本来は，相手とのコミュニケーションによって相手の意志を確認するとか，常識的に考える(この常識に基づく判断と言うのが，非常にロジック化するのがやっかいな代物ですが)とか，何かしら，解空間を枝刈りし8

Monohakobi Techno Forum 2019 レポート
「⾃律船の実現に向けたシステム・インテグレーション」
公開⽇: 2020 年 1 ⽉ 22 ⽇て，探索する解空間を現実的に，圧倒的に，小さくする手段が必要になりそうです。
また，アルゴリズムの評価の話も出てきます。これは，仮にこうしたアルゴリズムが出来たとして，その完全性，信頼性をどのように試験，評価するのか。実船でやっていたのでは，圧倒的に時間がかかってしまうので，何らか，
シミュレーションの世界でアルゴリズムが，経験を重ね，実時間よりも圧倒的に短い時間でトレーニングされるし，また，評価，検証される，そうした両面でのシミュレーションの活用が必要になってくる話と考えられます。
そして2つ目のフォールバックに関する指摘は，Human-MachineInteraction（人間と機械の相互作用）の話です。特に，従来のHumanMachine と違い，今回はMachineの方が，自律船と言うことでIntelligent
Machineですから，Human-Intelligent Machine Interactionと言う，正にこれからの新しい研究分野の話でもあり，また，人間と機械のチームワークの話
で，認知科学や組織論，海事分野で言えば，Intelligent Machineが加わった，
Bridge Resource Management (BRM)，こうした研究の話で，今後，現実的にとても重要な分野になってくると思います。
更に3つ目ですが，システムが自身の不具合を見つけることが出来るのか？
アルゴリズムの冗長性などによって担保するしか無いのではないかと思いますが，これはスペースシャトルなど宇宙分野では聞く話ですが，同じ問題を複数の異なるアルゴリズムに解かせて，多数決で勝った回答を採用する，と言った類の話とも関連しますが，システムの不具合を見つける方法を用意しておくことが，どうやら，トータルなシステムの安全性には必要な様子です。
また，NYKの小山氏のここでの指摘は，主に「避航操船の判断」を想定したものですが，認知プロセスにおいて，”判断”の前の”状況認識(situationalawareness)”についての懸念も，DNV-GLのスーリ氏から指摘がありました。

「私の見解，DNV-GLの見解としては，従来の船舶と比較して，自律船のシステムの信頼性，完全性を考える場合，ファンダメンタルな課題として，“状況認識(situational awareness)”があると考えます。システムが正確な状況認識を出来ているのか？システムが正しい状況認識を出来ている
か，どのように証明するのか？と言う課題があると考えています。
自律船のシステムを開発する場合，例えば，最初数年の間はとても上手く動作するシステムを構築したとして，突然，これまでに遭遇したことのな
9Monohakobi Techno Forum 2019 レポート
「⾃律船の実現に向けたシステム・インテグレーション」
公開⽇: 2020 年 1 ⽉ 22 ⽇

い状況におかれ，システムがどう解釈したら良いか分からないような状況にあるときに，突然，トラブルに見舞われる。それは非常に大きな課題
で，海事業界として乗り越えるべき大きなチャレンジだと考えます。また，おそらく自動車産業でも同じ問題があると思いますので，双方の業界において類似するチャレンジがあると言えるでしょう。しかしながら，海事産業と自動車産業の主たる違いは，システムが正しい状況認識を出来ていることを保証するためには，システムをトレーニングする必要があり，
もちろん，シミュレーションを繰り返すことによってシステムのトレーニングは出来ますが，現実にセンサーがどのように挙動するかが分からなけ
れば，全体のシステムの保証も出来ないわけで，そうするとシステムのト
レーニングにおいて，経験に経験を重ねてトレーニングするしかない，と言うことになります。この点について自動車産業は，様々なプロジェクトがあり，テスラを例に取ると，基本的に全てのテスラの車が，データを収集するための技術を備えており，途方も無いスケールでのデータ収集を行っています。これは今日の海事産業ではまだ起こっていないと思います。
これが実際にシステムの状況認識を保証する上での海事産業の課題だと思います。これは海事産業が自律船の安全性を担保する上でのファンダメン
タルな課題だと思います。」(DNV-GL Maritimeのスティアン・エリッ
ク・スーリ日本支社長)
人間が操船する場合においても，操船事故の原因は，“不十分な見張り”，つまり“状況認識(situation awareness) ”のエラーにある，と言うことが言われており，これは航空分野でも，Mica Endsleyが行った調査では，ヒューマンファクターに起因するアクシデントの実に88%が，状況認識(situation awareness)のエラーに起因するとされています。4) 自律船の場合にも，どのように操船するかの“判断”の前に，機械の認知プロセスとしてセンサーあるいはセンサーとコンピ
ューターによって，正しく周囲の状況認識を行えるか，と言うことが非常に重要になると考えられますが，行動のロジック以上に，状況認識のシステムの完全性，信頼性を評価することは，難しいタスクになりそうです。
DNV-GLのスーリ氏は，更にそうした困難な状況を見越して，その先の課題
として，センサーの挙動を確認するためには，経験に経験を重ねてトレーニン
グするしかないことを指摘し，また，その点において，途方も無いスケールでのデータ収集で先を行く，自動車産業の例を示し，海事産業でもこうした取り組みが必要では無いか，と言う指摘をしています。

10

Monohakobi Techno Forum 2019 レポート
「⾃律船の実現に向けたシステム・インテグレーション」
公開⽇: 2020 年 1 ⽉ 22 ⽇

以上は，今回想定した，“航海・湾内操船・離着桟を，船上の操船者の監視の下で，高度に自動化したシステムが担う有人の自律船”と言う前提に立てば，状況認識にしろ，操船判断にしろ，何かしら不具合があった場合には，船上で監視する操船者が，システムの状態を把握し，オーバーライド出来るようになっていれば，ループの中に人間を入れた“Human in the Loop”の全体システムとしては成立する筈なので，上に述べた”状況認識”や”判断”の課題は課題として
しっかり認識しつつも，現実的に，段階的にstep by stepで一つ一つ技術的な課題を克服していく必要があるのではないか，と思います。
技術的に見ると，こうした数々の難題がありますが，これらが統合システムの中で上手く解決された状態でなければ，結局，ユーザーに不安を与え，信頼されない，道具として用をなさない，と言うことになりかねません。現状の自律船の技術は，まだまだそうしたトータルな期待に答えられるレベルにはなっているとは言えませんので，やはり，機械が果たせる役割を限定し，その限定の範囲の中のことは，十分に達成する，例えば，オートパイロットやDPSと言った自動制御システムのように，等身大の期待値をこなせるシステムを目指すべきなのだろうと思います。
今回のパネルディスカッションの中でも，これに関連して，日本船舶技術研究協会(船技協)の野間氏からも次のようなコメントがありましたので紹介します。

私も，とある船に乗った時に，自動システムを動かした時に，船員さんが，「いや，もう怖くて，変えたいんだよ。」と言ってすぐにマニュアルに戻したんですね。そういう事象に遭遇いたしまして，そもそもシステムを乗っている船員さんが信頼出来るのか，と言う点がかなり大きいのかな，とその時に感じました。
個人的には，想定される自律船のレベルであれば操船者が常にバックアップしていると言う状況であれば，そこまで安全が揺らぐとは考えていないですけれども，これは前提として，システムが今どう状況を判断して，何をしようとしているのか，と言うのを常に船上の操船者に示すことが出来
ることが前提と考えています。

11

Monohakobi Techno Forum 2019 レポート
「⾃律船の実現に向けたシステム・インテグレーション」
公開⽇: 2020 年 1 ⽉ 22 ⽇

4. 自律船のコンセプト設計におけるリスク評価
自律船のコンセプト設計の段階において，ハザード特定(HAZID)や故障影響
解析(FMEA)と言ったリスク評価を十分に行うことは，後の工程からの手戻り，運用時の設計上の不具合を回避する上で非常に重要です。特に，高度な自動化によって機械の役割が増し，人に期待される，フォールバックの引き受け手の役割を期待するなど，機械と人の役割分担のあり方は，このコンセプト設
計の段階での決定に依存するため，ユーザーである運航者も関わった形でのコ
ンセプト設計とリスク評価が非常に重要になります。
図2は，MTIの沓名弘二氏が，今回の講演の中で紹介したもので5)，自動化シ
ステムのコンセプト設計において，コンセプト策定とリスク評価(HAZIDとFMEA)のサイクルを回し，相対的な安全性評価(Safety Equivalent)に基づいて，コンセプト策定を進めるプロセスを示しています。自律船だからと言って，既存船でも達成できないような安全レベルを求めるのは合理的でないため，基本的には，同等以上の安全性があるかの相対評価を，こうしたリスク評
価の中で進めていく考え方が示されています。

図2.自動化システムのコンセプト策定のプロセス

12

Monohakobi Techno Forum 2019 レポート
「⾃律船の実現に向けたシステム・インテグレーション」
公開⽇: 2020 年 1 ⽉ 22 ⽇

図3には，こうした安全に関するリスク評価結果の一例で，上下に２つのリスクマトリクスが書かれていますが，上が既存船，下が高度支援システムを搭載した船のリスクマトリクスになっています。(リスクマトリクスの横軸は発生
頻度，縦軸は被害の規模。)
このリスク評価結果では，開発を進める有人自律船のコンセプトを導入する
場合に，ターゲットであった最大のリスク要因であるヒューマンファクターに基づく事故のリスクは軽減し，一方で，高度なシステムの導入によるマンマシ
ンインターフェースに関する新たなリスクが発生している，と言う結果になっています。
今後，更に，インターフェースの工夫や，トレーニング等のリスク軽減措置を検討していく必要がありますが，全体的には，システムの導入により期待した，事故の削減につながる効果が期待される役割を，新しい支援システムが果たすことになると期待されます。

図3. 既存船と高度システム搭載船の相対安全性評価 (safety equivalent)13

Monohakobi Techno Forum 2019 レポート
「⾃律船の実現に向けたシステム・インテグレーション」
公開⽇: 2020 年 1 ⽉ 22 ⽇

5. シミュレーターによるソフトウェアの信頼性評価
さて，今回のMTF2019では，DNV-GLのKristine Bruun Ludvigsen氏から，"Open Simulation Platform – a collaborative effort to facilitate
system integration"と題して講演して頂きました。6) この講演の中では，今後のシステム・インテグレーションを行う上での課題として，制御用のソフト
ウェア・プログラムを接続，シミュレーション同士の接続(co-simulation)を行
うプラットフォームの取り組みについての紹介でした。
このテーマは，まずはその前に，シミュレーターによる制御システムのテスト(HIL: Hardware in the Loop)の話があって，次に，ハードウェアはエミュ
レーションした上での制御ソフトウェアのテスト(SIL: Software in the Loop)の話があって，そうしたHILやSILを異なるプラットフォーム間で連携するときの課題として，Co-Simulationのプラットフォームが必要になる，と言う話になると思いますが，制御ソフトウェアのテスト，評価と言うのは，今後，非常に重要な課題になってくることはほぼ間違いが無いと思います。一般的な入力，出力，入力と出力の関係が，ある程度，限られた範囲で表現出来る，例えば，ポンプのモーター制御のような，テストケースを予め全て記述出来るような場合のテストと，先に述べた，自律船の“状況認識”や“操船判断”のような，
ほぼ無限とも思えるような状況では，まだまだ正しいやり方が決まったわけではなく，今後，大いに研究が必要なテーマだと思われます。
Kristine Bruun Ludvigsen氏は，プレゼンの中で，自律船の操船システムを評価する際の構想(図4)を説明しました。今後，シミュレーターを使っての操船システムの評価のあり方は，特に”状況認識”や”操船判断”のような，非常に複雑な情報システムの評価にとって重要になると考えられます。

14

Monohakobi Techno Forum 2019 レポート
「⾃律船の実現に向けたシステム・インテグレーション」
公開⽇: 2020 年 1 ⽉ 22 ⽇

図4 Test System for Autonomous Navigation System 4)
ところで，このシミュレータを使った操船システムをどのように評価するか，と言う点について，日本海洋科学の中村紳也氏は，自身の船長としての現場での操船経験，これまでの自律避航プログラムの開発の経験に基づき，“相手船に不安を与えない操船”と言う視点で，操船を評価する”評価領域図”に基づく提案を，これまでに多くのシミュレーター試験での実験を通して，操船の実務者が不安に感じない操船と評価式のチューニングを行ってきており，こうした研究成果を今回のMTF2019でも紹介頂きました。7)15

Monohakobi Techno Forum 2019 レポート
「⾃律船の実現に向けたシステム・インテグレーション」
公開⽇: 2020 年 1 ⽉ 22 ⽇

図5. 中村紳也, 自動避航システムの安全性評価・認証に向けての“評価領域図”の提案
これは上記のKristine Bruun Ludvigsen氏による図4の中の，”Test
Evaluation”の箱に位置づけられる，操船の安全性評価を行う上での一つの有用な提案です。中村氏らによるこの評価式の詳細は，昨年11月のNorwayでの自律船に関する国際会議(The International Conference on Maritime
Autonomous Surface Ships (ICMASS))で公表されており8)，今後，国際的にも，操船方法の評価のあり方として，こうした日本の長年の研究の成果を提案し，お互いの認識，評価の基準を合わせて行く必要があるでしょう。

6. 新しい役割
さて，自律船が実現される将来を考えた場合に，従来とは違う新しい役割にはどう言ったものがあるか。パネルディスカッションで議論を行いました。以下に，パネリストの皆さんからのコメントを紹介したいと思います。

16

Monohakobi Techno Forum 2019 レポート
「⾃律船の実現に向けたシステム・インテグレーション」
公開⽇: 2020 年 1 ⽉ 22 ⽇

自分自身で三位一体と言いましたが，欧州系のように一つのメーカーさんがシステムインテグレーションしてくれるところはおそらく日本にはいな
いし，造船所も，先程仰っていましたが，十分ではないとなると，海運会
社はものを作れないし，それではどうしましょうと言うことになりますので，先程お話しがありましたように，皆が肩を寄せ合いながらやりましょうか，と言うやり方も一つだし，もしかしたら，そうした三位一体のシス
テム・インテグレーションというものをコーディネーションしてくれるよ
うな，そう言ったサービスプロバイダーのような，また違ったものが出てくるのかな，そうしたものが必要でないのかな，と考えたりもします。
(NYK小山智之・常務)

システム・インテグレーターに関する新しい役割と責任と言うことだと，
一つDNV-GLあるいは船級の役割として明確にあるだろうと思うのはファ
シリテーターの役割と思います。船級協会には多くの知見があり，プロシージャがあり，外部からシステム・インテグレーションをアクティブにサポートする役割を果たすことができると考えています。
また，自律船の未来では従来と異なる役割の仕事が必要になると思います。もちろん，すべてを予測することは非常に難しいですが，自律船のオ
ペレーションを考えると，例えば，メンテナンスや修理なども，現在のようにオンボードの乗組員によるメンテナンスや修理が期待できなくなるので，別のトータルな仕組みやそのための体制が必要になると思います。また，例えば，遠隔操船の場合には陸のコントロールセンターが登場する場
合にも新しい役割と責任，協業の新しいあり方を必要になります。法的な側面でも，事故が起こった場合の責任の所在なども課題になります。また，様々なデータを見る必要が出てくるでしょう。航海のデータ，周辺の環境のデータ，こうしたことも新しい仕事になると思います。このように非常に多くの役割と責任が生じるのではないでしょうか。(DNV-GL
Maritimeのスティアン・エリック・スーリ日本支社長)繰り返しになると思いますけれども，システム・インテグレーターには色々なやり方があると思います。欧州のやり方もあれば，日本のやり方もあると思います。大事なことはどちらのやり方であっても良いので，必要な安全性について，共通のバックグランドと言うか，プラットフォームと17

Monohakobi Techno Forum 2019 レポート
「⾃律船の実現に向けたシステム・インテグレーション」
公開⽇: 2020 年 1 ⽉ 22 ⽇

言うか，そういったものを作るのが，船級協会やIACSの仕事だと思います。是非そういうところで，世界の皆さんと議論をしながら，皆さんに使っていただける最低限の形を決めて，色々な形のインテグレーターが発展していく形ができれば良いと思います。(ClassNK 松本俊之所長)

自動運航船がはじまると，システムは一つではなくて，様々なシステムができてくると思いますが，少なくともこれらに対応する規則体系が必要になると思いますし，先程，松本所長からもありましたけれども，評価方法の確立と言うのもとても大事なことでして，これらの検討が重要だと思います。
それから，それ以外ですけれども，先程MTIの柴田さんからありましたけ
れども，船のサイバーセキュリティー，本船だけで良いのか，隣で運航する船と通信をするようになったときに，隣の船のサイバーセキュリティー
をどう考えるか。また，陸上の施設とも常時接続になりますけれども，本船だけの対応で済むのかと言ったところの議論も大事になってくると思います。(船舶技術研究協会 野間智嗣氏)

7. まとめ今回，MTF2019での講演，パネルディスカッションの内容を中心に，自律船の実現に向けた課題として，システム・インテグレーションを中心に整理を行いました。
自律船に関しての一貫したコンセプト（哲学，思想）を持ち，そのコンセプ
トに基づいて，設計開発〜建造〜運用のライフサイクルを通して必要なコーディネーションを行うことは，高度なシステムの実用上は不可欠のことではありますが，現状，そのノウハウ，経験，組織体制を単独で持つ組織は，おそらく存在しないと思います。自律船の開発に力を入れる欧州でも，そこまでの見通しは無いでしょう。状況認識や操船判断など，自律船特有の技術的課題も数多く残っています。方法論，ツールなどの道具を整えていく必要もあり，技術的な課題だけでも，数多くのチャレンジがあります。

18

Monohakobi Techno Forum 2019 レポート
「⾃律船の実現に向けたシステム・インテグレーション」
公開⽇: 2020 年 1 ⽉ 22 ⽇

日本では，単独の会社が，自律船を実現しようと言う形にはなっておらず，
オープンコラボレーションで，得意分野を持ち寄ってこの問題に取り組む方向になると考えられます。今後，業界内での議論，実証事業などでの経験を通して，自律船を実現する上での課題を明らかにし，それを業界で共有し，得意分
野を持ち寄り，解決を進め，必要なものは産学で取り組んだり，海外との連携も進めたりしながら，社会的に受け入れられる形で，段階的に新しい技術が取り込まれていくように進めて行くべきではないかと思います。

参考文献

1. IACS, UR E22 Rev.2, On Board Use and Application of Computer based systems,
June 20162.

日本海事協会, 自動運航，自律運航に関するガイドライン(Ver. 1.0), January2020

村上誠, “インテグレーションを実現する新たな協調に向けて”, Monohakobi
Techno Forum 2019 (講演) https://www.monohakobi.com/ja/wpcontent/uploads/2019/11/MTF2019_04_BEMAC_Murakami.pdf
4. Endsley, M. R., A taxonomy of situation awareness errors. In R. Fuller, N.
Johnston, & N. McDonald (Eds.), Human Factors in Aviation Operations (pp. 287292). Aldershot, England: Avebury Aviation, Ashgate Publishing Ltd., 1995
3.

5. 沓名弘二, “自律操船の実現に向けて”, Monohakobi Techno Forum 2019 (講演)https://www.monohakobi.com/ja/wpcontent/uploads/2019/11/MTF2019_01_Kutsuna_v.pdf
6. Kristine Bruun Ludvigsen, "Open Simulation Platform – a collaborative effort tofacilitate system integration", Monohakobi Techno Forum 2019 (講演)https://www.monohakobi.com/ja/wpcontent/uploads/2019/11/MTF2019_07_DNV-GL_Kristine.pdf
7. 中村紳也, 「自動避航操船システムの安全性評価・認証基準の提案〜人間が操船する相手船に不安を与えない自動避航操船〜」, Monohakobi Techno
Forum 2019 (講演), https://www.monohakobi.com/ja/wpcontent/uploads/2019/11/MTF2019_02_JMS_Nakamura_v2.pdf
8. Shinya Nakamura. et.al, "Study on Automatic Collision Avoidance System andMethod for Evaluating Collision Avoidance Maneuvering Results", ICMASS 2019,
Norway, Nov 201919