海運業界のシステム開発は、業務とデータの整理、小規模な実証、範囲に合う契約での本開発の順に進めると、過剰開発や現場の二重管理を抑えやすくなります。
業務が船上から陸上までつながるため、発注の流れを先に押さえておくと判断がぶれにくくなります。
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
海運業界のシステム開発が難しい理由
海運業界のシステム開発では、陸上のオフィス業務だけでなく、船上や港湾、倉庫、荷主、税関などを一つの業務プロセスとして捉える必要があります。
特に、通信品質と利用者の環境が場所ごとに大きく異なる点は、一般的な業務システムとの大きな違いです。
洋上と陸上の通信環境の違い
船上の通信速度や遅延、利用できる時間、通信費は、航行する海域や衛星通信の契約によって変わります。そのため、常時オンラインを前提にすると、入力内容が消えたり画面が止まったりして、紙へ戻るリスクがあります。
そこで、発注前にオフラインで使う機能、一時保存するデータ、通信回復後の差分同期の順序を要件に記載しておきます。
多様な関係者と国際業務のつながり
一つの案件には多くの関係者が関わり、船員や船長、運航担当、荷主、フォワーダーがそこに入ります。港湾作業員や倉庫、トラック会社、船舶代理店、税関の担当者も含まれます。そのため、部署ごとに異なる用語や締め切りを揃え、どこまでを誰が受け持つかを明確にします。
外国人船員が使う画面には、英語などの多言語対応が欠かせません。さらに、乗船や下船のたびに短時間で覚えられるUIと、その教育方法も検討する必要があります。
標準化されたデータ連携
社内外の関係者の間で情報をやり取りできるよう、次の仕様を揃えておきます。
- 連携仕様：港湾・税関EDIや社内ERPなど、各連携先の形式と更新時期
- 海事シングルウィンドウ：入港・滞在・出港の情報を一つの窓口で電子的にやり取りする仕組みです。
- データモデル：自社内だけで閉じず、外部システムでも再利用できる形を先に考えておきます。
IMOによると、海事シングルウィンドウは2024年1月1日から加盟国の港で義務化されました（出典：International Maritime Organization、2024年）。
海運業界のシステムに適した発注形態
海運業界のシステムでは、要件が固まった範囲を請負、変化の多い上流工程や運用改善を準委任で発注するのが現実的です。既存サービスで代替できる範囲は、SaaSの導入を組み合わせて対応します。
一社に丸ごと外注する方法もあります。ただし、発注者が業務知識と意思決定を手放すと、過剰なカスタマイズや責任の曖昧さを招きます。
SaaS・パッケージの導入
運航予定や船員管理、請求など、業務が標準化されている領域では、SaaSや業界パッケージを優先します。初期費用を抑えられ、更新やセキュリティ対策を自社だけで抱え込まずに済みます。
用船条件や航海採算、特殊貨物の安全確認を標準仕様に無理に合わせると、現場がExcelへ戻ってしまうおそれがあります。そのため、導入前にAPIやデータ出力、オフライン対応を確認し、海外利用や解約時のデータ返却も見ておきます。
フルスクラッチ開発の委託
独自の運賃計算や船舶ごとの制約などを標準サービスで表せない場合は、SI会社や開発会社へ委託します。自由度が高い一方で、要件を決める責任は発注者側にあります。
海運業務を理解しているかだけでは判断しきれないため、船や港を含む業務フローを、代理店や荷主との関係も含めて説明できるかを確かめます。類似のEDI連携と移行の実績があるかも、あわせて見ておきます。
段階発注によるハイブリッド化
段階発注は、業務整理と現状調査、小規模な実証、本開発と展開の順に進めます。最初は一航路または一港に対象を絞り、入港予定や荷役計画、トラック手配を検証します。
実証では、通信が途切れたときの入力と、復旧後の同期を確かめます。そこで得られた業務ルールをRFPに反映すれば、全社基幹を最初から作り込む場合に比べて、手戻りや過剰開発を抑えやすくなります。
海運業界のシステム開発を進める手順
発注前には、何を作るかだけでなく、どの業務をどの順番で変えるかを決めておく必要があります。障害は配船や荷役に加え、通関や請求にも連鎖します。そのため、移行と業務継続も開発計画と同じ重さで扱います。
現場ルールを標準化するAX
電話やFAXが残っていても、最初から全業務を高機能なシステムに置き換える必要はありません。まずは、関係者が判断している入港時期やサイロ・倉庫の空き、トラック手配、安全確認を洗い出します。
標準化するのは、定時連絡の時刻と入力担当、異常時の連絡先、確認済みの定義です。特に、火災や異物混入が安全に直結する港湾荷役では、チェックリストと連絡手順をそろえるだけでも要件の質が上がります。
現状業務とマスタの整理
業務フローを船上や運航部門、港湾などに分け、誰がいつ何を入力し、次の工程がどのデータを使うかを整理します。
マスタは、航路や港、船舶、貨物など、業務の基礎になるデータです。運賃や燃料油、為替などもその対象です。さらに、取引先や船員も整理しておきます。
マスタを開発会社に任せきりにすると、現場の用語とシステムの値がずれ、請求や採算が合わなくなります。そのため、項目名やコード、更新権限、履歴と廃止ルールは、発注者が自ら決めておきます。
一航路・一港のパイロットからの移行
全船と全港を一斉に切り替えると、問題の原因が仕様や通信などのどこにあるのか分かりにくくなります。まずは代表的な一航路で通し検証します。
- 入港から採算集計まで：情報収集や荷役計画、船陸同期、実績登録の一連の流れ。
- 通信断時の継続：通信が切れても業務が止まらないか確かめます。
- 利用者と外部環境：外国人船員の初回利用や、港湾側の別システムとの併用。
パイロットでは、機能の完成度よりも、通信や利用環境が異なる場所でも業務を続けられるかを重視します。
教育・運用・改善までの発注範囲
納品日に一度説明するだけでは、現場に定着しません。そのため、教育と運用の仕組みも発注範囲に含めます。対象は、短い動画や多言語マニュアル、船員交代時の引き継ぎです。さらに、問い合わせ窓口や障害時の紙運用、毎月の利用状況の確認も含みます。
導入後は、入力漏れや同期失敗、二重登録をKPIとして追います。処理時間や問い合わせ件数も指標にし、現場の声を改善につなげます。完成の時点は、二重管理が減り、安全と採算の判断が早くなったときとみなします。
RFPと要件整理で決めること
RFPは、同じ前提で提案と見積を比べるための発注条件です。機能一覧に加えて、業務背景や利用者、データ、制約を記載します。さらに、品質や移行、体制、見積条件も書き込みます。
業務目的と対象範囲の明記
目的は、「海運業務を効率化する」と書くより、入港予定の変更を関係者が同じ情報で確認できる、といった業務の言葉で表します。Voyageごとの収入・燃料・港費・為替を、締め後何日以内に把握するかも指標にします。
対象外も明記しておきます。たとえば、会計は既存ERPを使い、船員給与は別システムのままにする、といった形です。曖昧なRFPでは、提案時に安く見えた見積が後から膨らみやすくなります。
洋上・多言語・EDIの非機能要件
洋上での利用と外部連携の条件が漏れないよう、RFPに記載する要件をそろえます。
- 洋上利用：通信断の許容時間、端末内の保存件数、同期競合の解決方法を決めます。
- 利用環境：対応言語と文字サイズ、教育時間、権限の範囲。
- 安全性：監査ログとバックアップ、復旧目標、暗号化、脆弱性検査の扱い。
- 外部連携：APIとEDI標準のほか、時差、通貨、単位、タイムゾーンを確認します。
- 相互運用性：船、港、公的機関との情報交換を要件に含めます。
IMOは2025年5月に海事シングルウィンドウの設定ガイドラインを公開しました（出典：International Maritime Organization、2025年）。
データ移行と受入基準
既存のExcelや旧運航システムなどから移す年数と、重複や欠損を直す担当を決めます。
受入基準は、業務で検証できる形にしておきます。たとえば、通信断中の入力や二重送信の防止、既存帳票と一致する航海採算、多言語画面の主要操作などです。
IPAは、利害関係者と合意した要求を要件定義書に文書化することを示しています。口頭での合意で済ませず、記録に残す運用が大切です（出典：独立行政法人情報処理推進機構、2023年）。
海運業界のシステム外注における契約形態の選び方
契約は、作業の不確実性と成果物の明確さに合わせて選びます。確認するのは、成果物や検収、変更、責任の範囲です。
そのほか、知的財産やデータ返却、障害対応、再委託、終了条件も見ておきます。
範囲と成果物が固まった工程の請負契約
請負は、成果物と検収条件を定めやすい工程に向いています。たとえば設計や実装、試験などが該当します。確定した入港予定管理画面やAPI仕様、帳票などを納品対象にします。
港や契約条件の確認で要件が変わることがあるため、変更の受付や追加見積の単価、納期への影響は、契約か別紙に記載しておきます。優先順位の決め方も、契約か別紙で定めます。変更を無制限に含める契約は、負担と品質低下を招きます。
調査・要件定義・改善の準委任契約
現状調査や業務整理、RFP作成の支援など、作業を通じて要件を具体化する工程は、準委任と相性がよいです。発注者とベンダーがチームで動き、月ごとの作業時間と体制に応じて支払います。
準委任では、ベンダーに任せきりにしないことが前提です。発注者側にも、プロダクト責任者や現場代表、データ責任者を置きます。
IPAは、リスクやセキュリティ対応のコスト、どこまでを誰が受け持つかについて、共通の理解を持つことを重視しています（出典：独立行政法人情報処理推進機構、2024年）。
保守・SLAと責任の範囲
洋上で通信が切れたときに、システムや通信会社、船内端末のどこに問題があるかを切り分けられるよう、監視対象と連絡先を定めます。
確認するのは、復旧目標時間やバックアップ頻度、脆弱性対応です。さらに、休日の連絡体制やデータ保管地域、個人情報や船舶情報の扱い、第三者サービス障害時の対応も見ておきます。
サイバーポートでは、自社システムとのAPI連携で二重入力を解消した事例が公開されています。契約前には、港湾サービスのAPI仕様や料金、可用性、将来の仕様変更を確認します。
海運業界のシステム開発費用相場と内訳
海運業界のシステム開発費用は、利用者数よりも、対象業務や外部連携、データ移行によって大きく変わります。オフライン要件や海外展開、セキュリティ、運用体制も、費用を左右する要素です。
公的に定められた平均相場があるわけではありません。そのため、この記事の金額は予算を組む際の実務的な目安として扱い、必ず同じ前提の見積で比べます。
規模別の予算レンジ
対象範囲によって予算の幅が変わるため、規模ごとの検討レンジを示します。
- 小規模実証：一港・一航路のPoCや入力画面、簡易ダッシュボードを対象とし、調査と設計を含めて数百万円から1,000万円前後です。
- 複数部署：運航・荷役・請求の各業務に、認証や権限、帳票、連携、移行を含めると、1,000万円台から数千万円規模になりやすいです。
- 全社規模：船陸同期やEDI、航海採算、多国展開、全社基幹の刷新まで含めると、数千万円から1億円超も想定します。段階発注で投資効果を確かめます。
これらは、機能数とリスクを分けて考えるための予算の仮説です。相場を断定したものではありません。
初期費用とランニングコスト
初期費用には、現状調査や要件定義、UI設計、アプリ開発が含まれます。そのほか、API・EDI連携やインフラ構築、テスト、データ移行、教育も対象です。
別枠で見積もるのは、クラウドや衛星通信・回線、端末、ライセンスです。さらに、監視や保守、問い合わせ対応も見込みます。脆弱性対応やバックアップ、追加開発も忘れずに含めます。
保守費は、開発費の一定割合だけでなく、月ごとの人数と時間、障害対応や改善の範囲から確認します。また、船舶数やデータ量が増えたときに、その費用がどう変わるかも見ておきます。
過剰カスタマイズの抑制と費用管理
パッケージの標準機能を調べずに例外をすべて開発すると、費用だけでなく、テストと保守の負担も増えます。例外は、法令や安全上必須のもの、採算や顧客価値に直結するもの、一時的な慣習によるものに分けます。
一時的な慣習については、業務ルールそのものの標準化を検討します。一方で、船陸同期や外国語UIは維持し、汎用的な承認画面やマスタ管理は標準機能に寄せると、投資の配分がはっきりします。
委託先選定と見積比較のポイント
価格だけでなく、同じ業務成果を同じ品質と範囲で実現できるかを基準に選びます。評価するのは、質問の深さやリスクの指摘、標準化と個別開発の切り分け、定着計画です。
海運と連携に関する実績
船舶や港湾、物流、貿易などの業界と基幹システムの実績に加えて、通信断を含むエッジ・クラウド構成の実績も確認します。さらに、API・EDIや複数通貨、監査ログ、移行の実績も確かめます。
実績の担当範囲と利用者数、連携先を聞き、保守体制や失敗と改善策も確認します。同じ業務シナリオを示したうえで、通信断中の入港予定の変更と貨物データの二重送信に、どのような設計で対応するかを説明してもらいます。
見積項目の粒度をそろえた比較
見積は、要件定義や設計、開発、テスト、移行に分けてもらいます。教育やPM、インフラ、ライセンス、保守も、別々に示してもらいます。
そのうえで、作業量や単価、期間を並べ、前提と除外事項も比べます。「一式」と書かれた項目には、成果物と工数の説明を求めます。
安い見積では、データ整備や外部連携、オフライン試験、教育、リリース後の改善が抜けていないかを確認します。高い見積では、不要な機能や会議体が含まれていないかを見ます。
失敗リスクと撤退条件
切り戻しの条件と、旧システムとの並行期間を決めます。障害時の紙や電話での運用、データ復旧の手順も定めておき、サプライチェーンを止めないようにします。
要件追加の承認者や、予算超過を何％で経営会議に上げるか、パイロットを続けない条件も明文化しておきます。
大規模ERPの刷新では、他業界でも移行の遅延や調達の停止が事業に影響しました。そのため、段階移行やデータ照合、業務継続テストを見積項目に入れます。
よくある質問
発注や外注の場面でよく寄せられる疑問に、順に答えます。
海運業界のシステム開発にはいくらかかりますか？
目安としては、一港・一航路の小規模実証で数百万円から1,000万円前後、複数部門の業務システムで1,000万円台から数千万円ほどです。
EDIや船陸同期、航海採算、多国展開まで含めると、数千万円から1億円超を検討する場合もあります。費用は、機能や連携数、移行件数、オフライン要件、教育範囲によって変わります。そのため、前提と除外事項も合わせて比べます。
RFPは自社だけで作れますか？
目的や現状フロー、範囲のほか、データや利用者、制約も、自社が中心になって作ります。書式や技術要件、現行システム調査、概算、候補会社との質疑は、外部支援会社に委託できます。
役割分担としては、発注者が業務の判断を持ち、外部支援会社が情報を整理して見える形にする、という分け方が適切です。
洋上で通信が切れても使えるシステムにできますか？
可能です。ただし、すべてをオフライン対応にはせず、船上で必要な入力や参照、確認に絞ります。端末や船内サーバーに一時保存し、通信が回復したあとに差分同期する方式を検討します。
競合データの解決ルールや同期失敗時の再送、時刻の扱いのほか、暗号化や端末紛失時の消去、テスト海域も、RFPに明記します。
海運特化型ERPと汎用ERPはどちらを選ぶべきですか？
運航や用船、採算など海運特有の機能が必要であれば、海運特化型ERPを候補にします。一方で、会計や人事、購買は汎用ERPを使い、運航や港湾連携は周辺システムで補う構成も有効です。
候補は、航海や運賃・燃料・為替をデモで確かめて絞ります。あわせて、港湾EDI、通信断、多言語画面も試します。また、カスタマイズ費と将来の更新への影響も比べます。
何社から見積を取ればよいですか？
要件を整理したうえで、3社程度から同じRFPに基づく提案を取ると比べやすくなります。一方で、会社数を増やしすぎると、質疑や評価が浅くなります。
候補は、海運や物流への理解、通信・EDIの技術力、保守体制で絞り込みます。予算や担当者との相性も判断材料です。そのうえで、リスクや段階導入、定着まで説明できる会社を選びます。
まとめ
発注前の業務とデータの責任者
発注者は、現場ルールやマスタ、要件の優先順位を決める責任者を置きます。設計や開発を委託しても、業務上の判断まで外注しないことが成功の前提です。
小さく検証してからの全社展開
段階的に広げるかを判断できるよう、検証、発注範囲、業務継続の要点を整理しておきます。
- 段階検証：一航路・一港で通信断やEDI、教育、移行を確かめ、受入基準を満たしたあとに対象を広げます。実データをもとに見積条件を更新し、投資を管理します。
- 発注範囲：船上・港湾・陸上をつなぐ目的と現場ルール、マスタを整理したうえで、SaaSや個別開発、準委任、請負の範囲を分けます。
- 要件と継続性：差分同期や多国籍船員向けUI、港湾・税関EDI、Voyage単位の採算管理などの要件と、データ移行、業務継続の扱い。
2026年の港湾DXでは、国土交通省がサイバーポートを共通インフラとして、民間サービスや自社システムとの連携を進めています（出典：国土交通省、2026年）。そのため、外部の標準や将来の連携を見据えたRFPを作ることが大切です。
見積は、同じ前提で費用や範囲、品質、体制を比べます。発注者が業務とデータの責任を持てば、過剰開発や二重管理を抑えやすくなります。
参考・出典：International Maritime Organization「Maritime Single Window」、
International Maritime Organization「FAL related guidance」、国土交通省「港湾ロジスティクスの強化に向け港湾手続のデジタル標準化を推進」、
独立行政法人情報処理推進機構「情報システム・モデル取引・契約書」、独立行政法人情報処理推進機構「要件定義とは」、
Cyber Port・CONPASポータル（いずれも2026年8月確認）です。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。