7月1日、AIは海ではなく東京で働き始めた

商船三井と日本IBMの共同発表が描く現場は、船のブリッジではない。中核は東京本社にある安全運航支援センター、SOSCである。世界を航行するMOL関連船舶の状況を24時間365日見守り、船長と運航管理者へ助言・是正提案を送る陸上の司令室だ。新基盤は2026年7月1日に運用を開始した。

目的は、増え続ける情報から「いま、どの船の、何が危ないか」を早く見つけることにある。台風、波、海氷、船位と速力、寄港地、海賊行為、紛争や航行警報は別々の速度、形式、地理単位で届く。担当者は同時発生する危険を横断して読み、重要度を付けなければならない。発表によれば、新基盤はこれまで分散していた気象・海象、運航、地政学情報を統合し、生成AIが過去の運航実績と現在情報からリスクを特定・抽出する。

2026年7月1日東京のSOSCで運用を開始。
24時間365日経験ある船長を含むSOSC要員が陸上支援。
3つの機能情報統合、AI判断支援、組織知の共有・分析。
930隻2026年3月末のMOLグループ運航船隊規模。AIの対象隻数ではない。

発表された三つの機能

層会社発表が確認する機能運航現場での意味
情報統合気象・海象、船舶運航、地政学情報をリアルタイムに統合し、一元可視化複数画面や文書を渡り歩く時間を減らし、同じ船・海域・時間へ情報をそろえる
AIアシスタント過去の運航実績と現在情報から、生成AIが直面リスクを特定・抽出動静監視、状況評価、対応の優先順位付けを補助する
ナレッジ過去の事故、対応事例、現場知を組織全体で共有・分析個人の記憶や部署のファイルを、次の判断で探せる知識へ変える

開発にはSOSCの運航知見、MOL INFORMATION TECHNOLOGY INDIAのAI技術、日本IBMのAI・データ活用の専門性を組み合わせ、IBM Garageの手法を使った。Garageは、利用者の課題定義から設計、開発、実装までを進める協働方法である。ここで重要な境界がある。共同発表は、特定のIBM基盤、watsonx、クラウド、基盤モデルを名指ししていない。「IBMが参加した」ことから製品名を推測してはならない。

これは船を操る生成AIではない。海と陸から届く情報を読み、危険候補と過去の教訓を、最終判断をする人間の前へ早く並べる生成AIである。

「世界の船舶運航に入った」の正確な意味

見出しの「船舶運航へ」は、ソフトが各船の舵や機関を直接制御するという意味ではない。発表はSOSC担当者が重要事象を把握し、AI分析と船長経験者の知見を組み合わせると説明する。SOSCは船長と運航管理者の判断を支援する。航路変更、減速、避航、待機を生成AIが自動実行するとは書かれていない。

したがって、MOLが同じ2026年3月に発表したMEGURI2040の自動運航船とは別の技術系列だ。MEGURIは船上認識、将来挙動予測、衝突回避、航路計画、陸上支援を統合し、国土交通省の自動運航船検査を受けた。一方、7月のAI基盤は、陸上で情報と知識を扱う意思決定支援である。自律性を論じる前に「どの機能を、誰から、どこへ移したか」を見る必要がある。

国際海事機関（IMO）のSOLASは、船長が安全・保安について最終責任を持つという原則を明確にする。陸上からのAI支援はこの権限を補強できるが、曖昧にもできる。「AI推奨に従った／従わなかった」ことが人事評価や事後責任へどう使われるかまで決めなければ、人間参加は画面上の承認ボタンだけになり得る。

生成AIは、従来の最適化と何が違うのか

船舶運航では、生成AI以前から数値モデルが働いてきた。気象予報、波浪モデル、性能曲線、燃料消費、到着予定、衝突危険度は、物理モデル、統計、最適化で計算する。MOLが2024年に採用したSofar OceanのWayfinderは、高精度の海象予報、船ごとの燃費モデル、市場・安全制約から速度と航路を提案する。40隻の試験で1航海平均約6%の燃料・GHG削減が確認されたとMOLは発表した。

生成AIの強みは、数値計算を置き換えることより、形式の違う大量の文章を読み、要点をまとめ、関係する事例を呼び出し、人に説明できる形へ変えることにある。海賊情報、港の通達、社内報告、事故記録、引継ぎ、自由記述のニアミスは表形式だけでは扱いにくい。船位と予報が示す危険海域へ、過去の似た対応例を結び付けるなら、生成AIは「検索と要約の摩擦」を下げられる。

しかし、流暢な文章は計算の正しさを保証しない。航路・余裕水深・燃料・復原性の数値は、検証された専用計算へ残すべきだ。生成AIが最適化結果を説明することと、生成AI自身が安全航路を計算したことは同じではない。今回の発表は内部構成を明らかにしておらず、両者の境界も未公表である。

2006年、四つの重大海難が始点になった

MOLの現在の安全史は、成功談だけで始まらない。会社は2006年、運航船でコンテナ船の機関室火災、自動車船の大傾斜、タンカーの原油流出、鉄鉱石船の座礁という四つの重大海難が起きたと総括している。個別には「MOL Initiative」「Cougar Ace」「Bright Artemis」「Giant Step」に関する事故で、Giant Stepの座礁では人命が失われた。

同年12月、MOLは「安全運航の原点に立ち返る」として管理体制強化策を公表した。実事故を再現するブリッジ・リソース・マネジメント訓練、訓練船、そして全運航船の位置・動静、気象と予報を一室で監視し、船長へ直接警告・勧告する24時間体制が柱に入った。翌2007年2月1日、SOSCが開設された。

ここで歴史を慎重に読む必要がある。2026年の生成AIが2006年の事故を防げた、と逆算して言うことはできない。原因、通信、データ、モデル、運用条件が違う。意味があるのは、事故情報と対応例を将来の判断へ使えるよう組織記憶にするという設計思想が、20年前の反省から続いている点だ。

最初のSOSCは、衛星の点と天気を見た

2007年のSOSCは、INMARSAT衛星で定期的に船位を取得し、Weathernewsの気象・海象リスク評価を監視し、荒天、津波、保安、航海上の警告を船、船舶管理会社、配船部署へ送った。緊急問い合わせのヘルプデスクでもあった。現在の標語は「Never leave the captain alone（船長を一人にしない）」で、経験ある船長を含む担当者が交代勤務する。

2009年、MOLとWeathernewsはFMS.Globeを公開した。全船の位置と気圧、台風、潮流、海水温、雲などをリアルタイム表示し、SOSCで使うFMS.SAFETYの情報を地球儀型画面へ映した。2023年の改装では、大型ビデオウォール、危機対応室、運航部門と階段でつながるオープンなSOSCへ更新した。データを中央へ集めても、担当者同士が相談できなければ判断は速くならないという、人間側の設計である。

現在のSOSCは、台風、冬季荒天、海氷・氷山、津波、海賊、ミサイル試射やロケット打上げなどを監視する。2026年1月にはLNG船Energy Advanceを使い、海賊船接近を想定して海上保安庁、国土交通省、ReCAAP情報共有センターなどと緊急通信訓練を行った。AIの画面だけで完結せず、官民の実通信網へつなぐ仕事である。

2017年、MOLとIBMはすでに事故データを読んでいた

両社の関係も2026年に突然始まったのではない。MOLと当時の商船三井システムズは2017年12月、IBM SPSS Modelerを使い、運航、乗組員、船舶検査など複数データから事故・不具合の相関や因果関係を分析する取り組みを始めた。乗組員が報告したヒヤリハットなど、自由記述へテキストマイニングを使う方針も示した。

これは大規模言語モデルによる生成AIではない。統計分析、機械学習、単語頻度や関係を扱うテキストマイニングの世代だ。それでも、2026年の基盤につながる問いは同じだった。事故報告を集めるだけでなく、異なるデータを組み合わせ、再発防止策を作り、その効果を検証できるか。

違いは、生成AIが自然文の入口を広げたことにある。検索語を厳密に知る担当者だけでなく、「この海域で似た警報が重なった過去事例」「この船型で荒天時に注意した対応」を対話的に探せる可能性がある。一方、質問の言い方で答えが変わり、存在しない説明をもっともらしく作る危険も加わった。

FOCUSは、船を陸から「診る」ためのデータを作った

MOLは2016年末にSmart Shipping推進室を設け、IoTとAIを安全、効率、自動運航へ使う体制を強めた。2019年にはFOCUS（Fleet Optimal Control Unified System）の最初のアプリ「Fleet Viewer」を公開。位置、気象・海象、機器状態など約6,000項目のセンサーデータを1分間隔で集め、船と陸が同じ状態を見る構想を説明した。

MOLは当時、海上の船を地域診療所、陸上の船舶管理を病院にたとえた。通信の限界で、陸は船を直接「診る」ことが難しかったからだ。FOCUSのクラウドデータは、故障兆候の分析、性能診断、運航効率、Fleet Guardianの予防保全へ広がった。2020年のLighthouseは、顧客へ動静、天気、海象、貨物、契約情報を提供した。

2026年の生成AIは、この蓄積の上に置かれる。ただし発表はFOCUS、SPIRIT、Wayfinder、Lighthouseが新基盤へ具体的にどう接続されたかを明記しない。「統合」と書かれていても、すべてのシステム・全項目が接続済みと断定はできない。

930隻という規模を、対象隻数と誤読しない

MOLの会社概要によれば、2026年3月末のグループ運航船隊規模は930隻、グループ会社611社、従業員11,567人である。AI基盤の意味を測る背景としては重要だ。異なる船種、船齢、管理会社、旗国、航路、通信環境をまたぐ情報整理は、数隻の実証とは違う。

しかし共同発表が言うのは「世界中を航行する当社関連船舶の安全運航を支援するSOSC」を中核にした基盤であり、930隻すべてが初日から生成AIの対象だとは書いていない。対象船・部署・利用者数、段階展開、地域、言語、データ更新頻度は未公表である。会社規模を製品の導入規模へ置き換えるのは、典型的な数字の膨張だ。

人とAIの判断連鎖

公開情報から確認できる流れは、①気象・海象、船舶運航、地政学情報を統合する、②過去実績と現在情報から生成AIがリスクを特定・抽出する、③動静監視・状況評価・優先順位付けを助ける、④SOSCの船長経験者が知見を組み合わせ、船長や運航管理者を支援する、というものだ。

実装上は、時刻と位置の整合、船名・IMO番号の照合、情報源の信頼度、同じ事象の重複排除、有効期限、海域ポリゴンと予定航路の交差判定が必要になるはずだ。だが、これらは一般に必要と考えられる編集部の分析で、MOL・IBMが内部アーキテクチャとして発表した事実ではない。

良い画面は、結論だけでなく根拠を戻せる。「危険」と表示するなら、どの気象予報の何時の更新、どの船位、どの港湾通達、どの過去事例を使ったかを示す。原文を一操作で開き、相反する資料とデータの鮮度も見せる。生成AIの文章を一次資料の代用品にしない設計が、安全支援では中核になる。

海運の生成AIで最も価値のある文章は、いちばん流暢な文章ではない。根拠、時刻、不確実性、担当者、次の確認行動を短く示す文章だ。

公表されたこと、まだ分からないこと

論点2026年7月1日時点
用途情報統合、リスク抽出、監視・評価・優先順位付け、過去知識の共有
運用場所東京の陸上SOSCが中核
人間の関与AI分析と船長経験者の知見を組み合わせ、船長・運航管理者を支援
開発MOL、MOL Information Technology India、日本IBM。IBM Garage手法
モデル／製品未公表：LLM名、IBM製品、モデル提供者、サイズ、調整方法
システム構成未公表：クラウド、検索拡張生成、ベクトルDB、接続システム、データ所在地
規模と性能未公表：対象隻数、利用者、検出率、誤警報、見逃し、処理時間、稼働率
統制未公表：承認フロー、監査ログ、保持期間、外部評価、インシデント報告
費用・契約未公表：開発費、運用費、契約期間、知財、モデル更新条件

未公表は欠陥の証拠ではない。安全やサイバー上、公開できない詳細もある。ただし、外部が効果を評価できる最低限の性能指標まで秘密なら、「判断の質と速度が上がった」という主張は検証できない。安全に関係するAIでは、攻撃者へ設計図を渡さずに、検出性能、重大な誤作動、監査体制、改善状況を公表する線引きが必要だ。

生成AIが間違える五つの経路

第一は、NISTが「confabulation」と呼ぶ、もっともらしい虚偽の生成である。実在しない事故例、古い港湾規則、誤った緯度経度を自然な文で出せば、単純なエラーより見抜きにくい。第二は鮮度。台風進路、航行警報、港の閉鎖、保安情報には期限があり、昨日正しかった答えが今日危険になる。

第三は情報の衝突だ。複数の予報モデルや当局情報が一致しないとき、AIが平均した一つの物語を作れば、不確実性が消える。第四は欠落。危険を誤って出す誤警報は目立つが、重大な船を一覧へ出さない見逃しは静かに残る。第五は自動化バイアス。忙しい担当者ほど整った要約を信頼し、原文確認を省きやすい。

対策は「人が見る」だけでは足りない。根拠へのリンク、更新時刻、信頼度、反対証拠、モデル・プロンプトの版、出力を採用・却下した理由を記録する。重大警報は専用ルールや二重確認と組み合わせる。AI停止時にも従来の監視を続けられる縮退運転が必要だ。

地政学資料そのものが攻撃入口になり得る

生成AIは外部文書を読むほど便利になるが、信頼できない入力と高権限の指示が同じ文脈へ入ると、プロンプトインジェクションの攻撃面が生まれる。NISTは、低信頼の入力を高信頼のプロンプトへ連結する弱点を悪用する攻撃と定義する。たとえば取得したウェブ文書に、システム指示を無視させる文が埋め込まれていても、人間には普通の通達に見えるかもしれない。

また、船位、予定航路、貨物、寄港、乗組員、事故、検査の情報を一か所で結ぶほど、システムは価値ある攻撃対象になる。誤情報注入、認証情報の窃取、モデル経由のデータ漏えい、権限の横移動、サプライチェーン更新の改ざんを想定しなければならない。

IMOの改訂「海事サイバーリスク管理ガイドライン」は、リスク戦略を作り、資産と脅威を特定し、保護し、検知し、対応し、復旧する機能を求める。AIだけの特別室ではなく、安全管理システムと既存のサイバー統制へ組み込む考え方だ。生成AIから船上制御への直接書き込みを避け、必要最小権限、ネットワーク分離、読み取り専用接続、情報源の許可リスト、出力の内容無害化を重ねるべきである。

「船長を一人にしない」が「船長を従わせる」にならない条件

SOSCの標語は、陸上が現場を置き換える宣言ではなく、孤立させない約束だった。船長は目の前の視界、船体の感触、乗組員、貨物、機器の実情を知る。陸上は広域の天気、他船、港、地政学、会社全体の事例を見られる。両者の非対称な情報を結ぶことが支援の価値である。

AIが間に入ると、陸上の助言が大量、高頻度、定型化する。警報が多すぎれば船橋の注意を奪い、本当に重要なものが埋もれる。従わないたびに説明を求める設計なら、助言は事実上の命令になる。逆に、船長が現場理由で却下した記録を学習と改善へ戻せば、モデルは海を知る。

訓練も「良い質問の書き方」だけでは不十分だ。誤りを見つける方法、情報源の鮮度、AIを使わない条件、異論の上げ方、通信断・システム停止時の手順、機密情報を入力してよい範囲を、船と陸で一緒に訓練する必要がある。経験者の技能をAIへ移すほど、次世代が判断理由を学べる設計も要る。

事故の知識は、検索できれば安全になるのか

過去の事故情報、対応事例、現場知を使うという第三の機能は、今回最も重い。事故報告は、原因を一つに絞れるデータではない。直接原因、背景、組織、疲労、設計、天気、通信、商業圧力が重なる。生成AIが短くまとめすぎれば、「乗組員のミス」という単純な物語へ戻る危険がある。

良い知識基盤は、最終報告だけでなく、適用船種、前提、反対証拠、是正措置、その後の効果、未解決点を保つ。個人名や医療・人事情報は目的に応じて削除・制限し、事故から学ぶことと責任追及・監視を分ける。古い事例は現在の設備・規則との違いを示さなければならない。

2006年の四つの海難をAIの学習材料と呼ぶだけでは、犠牲と教訓を道具化する。何を変え、どの再発経路を閉じ、どこがまだ弱いかを人間が説明し続ける必要がある。生成AIの役割は歴史を代筆することではなく、忘れにくくし、必要な瞬間に原資料へ戻すことだ。

速さと正確さは、別々に測る

MOLとIBMは「判断の質と対応速度」の向上を掲げる。実証するには、ログイン数や質問数より運航の指標が要る。重大事象が発生してから検知・確認・船への連絡までの時間、優先順位の一致、見逃し率、誤警報率、根拠リンクの完全性、古い情報の混入率、AIと当直者の不一致を測る。

一つの総合正解率は危険だ。軽微な誤警報を99件正しく除外しても、1件の台風接近を見逃せば安全上の価値は低い。船種、海域、言語、警報種類、昼夜、通信品質ごとに分け、重大度に重みを付ける。複数危機が同時に起きる「飽和状態」で、担当者の負荷が本当に下がるかも見る。

導入前の過去データでバックテストし、本番では一定期間のシャドーモードを置く。古い通達、偽の地政学文書、単位違い、同名船、位置飛び、通信欠落、プロンプト攻撃を赤チームで入れる。モデル更新後は同じ基準で回帰試験する。速く答えることではなく、正しい確認へ早く到達することがKPIである。

20年の進化を一本の表で読む

年節目運航支援の変化
20064重大海難、「原点に立ち返る」安全強化策全船位置・気象を24時間監視する構想
2007SOSC開設INMARSAT船位、Weathernews、警報、ヘルプデスク
2009FMS.Globe全船位置と世界の天気をリアルタイム可視化
2016Smart Shipping推進室IoT・AI・高度運航支援を組織化
2017IBM SPSSによる多次元事故分析運航・乗組員・検査・自由記述を横断
2019FOCUS Fleet Viewer約6,000項目を1分間隔で船陸共有
2020Lighthouse顧客へ動静・気象・貨物・契約情報を提供
2023SOSC改装ビデオウォール、危機対応室、運航部門と接続
2024Wayfinder採用海象と船性能から速度・航路を最適化
2026生成AI基盤を運用開始現在リスクと事故・対応知識を抽出、優先順位付け

この表は、生成AIを突然の革命ではなく、観測、通信、データ標準化、統計、センサー、可視化を積み上げた次段階として位置付ける。生成AIだけを買っても、正しい船位、時刻、気象、事故分類、責任ある当直がなければ安全基盤にはならない。

BLUE ACTION 2035の「安全」と「DX」

今回の取り組みは、MOLグループの経営計画「BLUE ACTION 2035」Phase 2で、安全とDXを軸に経営基盤を強くする施策と位置付けられた。会社は今後、関係各社と機能、対象業務を広げ、海運業界全体の安全性向上へ貢献するとする。

拡張には二つの道がある。一つは、より多くの船、船種、グループ会社、言語、危険分類へ横に広げること。もう一つは、事故調査、訓練、保守、配船、顧客対応など業務を縦に深くつなぐことだ。後者ほど権限とデータ目的が変わる。「安全のため」に集めた乗組員情報を、人事評価や生産性監視へ静かに転用しない統制が必要になる。

業界貢献を掲げるなら、自社固有のモデルやデータを公開しなくても、評価方法、匿名化した失敗パターン、警報分類、サイバー訓練、ヒューマンファクターの知見は共有できる。船級、旗国、IMO、他社が比較できる共通指標が育てば、一社のダッシュボードを越える。

次の発表で見たい成績表

まず、展開規模を明らかにしてほしい。対象船、船種、SOSC利用者、言語、接続データ、運用時間、従来手順との境界。次に、重大度別の検出率、誤警報率、見逃し、検知から連絡までの中央値と上位値、根拠提示率、古い情報率、システム停止時間を示す。

人間側では、AI提案の採用・修正・却下、船長とSOSCの不一致、警報負荷、確認時間、訓練結果を匿名集計する。安全成果では、AI単独の因果を誇張せず、危険回避、ニアミス、遅延、燃料、事故、救援の変化を長期で見る。重大な誤出力やサイバー事案について、どの基準で外部報告するかも必要だ。

モデル名を明かすことは優先順位が低い。重要なのは、更新のたびに何を再試験し、出力がどの原資料へ戻れ、誰が停止でき、停止中も船を支援できるかである。安全システムの成熟は、デモの流暢さではなく、例外と故障の扱いに表れる。

AIが一件の危険を発見したという物語より、何件を見逃し、何件を誤って上げ、誰が直し、次の版でどう改善したかという成績表の方が、海を安全にする。

船長を一人にしない、次の20年

2007年のSOSCは、衛星で得た船位の点と世界の天気を見て、船へ電話とメールを送る場所だった。2009年には地球儀へ全船を映し、2017年にはIBMの統計ソフトで事故・乗組員・検査・自由記述を横断し、2019年以降は数千項目のセンサーを船と陸で共有した。2026年、生成AIはそれらの上で、危険と過去の経験を人が読める短い形へまとめようとしている。

これは、海運の判断を機械へ渡す終点ではない。むしろ、なぜその船を先に見るのか、どの情報を信じたのか、いつ人が反対したのかを、以前より明確に残す機会である。うまく設計すれば、熟練船長の知恵を広げ、若い担当者の学習を助け、同時危機の見落としを減らせる。失敗すれば、流暢な要約が不確実性を隠し、中央の誤りを世界の船へ速く配る。

MOLとIBMは、技術的な第一歩より難しい段階へ入った。日々の当直で、AIが有用でも疑える存在であり続けることを証明する段階だ。「船長を一人にしない」という20年前の約束を守るなら、生成AIは新しい船長ではない。原資料、陸上の経験者、海上の船長を、危険が大きくなる前につなぐ、もう一本の通信線である。

出典・参考資料

編集注：本稿は2026年7月17日までに確認できた一次資料を中心に構成しました。「生成AIが船内に搭載された」「自動操船する」「930隻すべてを対象にした」とは表記していません。MOL・日本IBMは、モデル名、IBM製品名、クラウド、検索拡張生成の有無、対象隻数、精度、誤警報・見逃し、費用、監査・サイバー設計を発表していません。一般的に必要となるデータ処理・防御策は編集部分析として区別しています。ヒーロー画像は編集イラストです。為替表示は本号指定値「1 US Dollar = 162.39 Japanese Yen」です。