コンテナ管理システム開発の進め方/やり方/流れや方法/手法/工程/手順

コンテナ管理システムの開発は、船舶・ヤード・ゲート・荷役機器を一つの業務データでつなぎ、現場KPIと継続運用を先に決めて段階導入することが成功の要点です。

本記事では、港湾コンテナターミナル向けのTOS(Terminal Operating System)を対象に、開発の進め方、費用相場、見積もりの確認ポイント、発注前の準備、導入後の運用までを解説します。「コンテナ管理システム」という言葉はDockerやKubernetesなどITインフラのコンテナ管理を指す場合もありますが、ここではコンテナ貨物を扱う港湾・ターミナルの業務システムを扱います。

▼全体ガイドの記事
・コンテナ管理システム開発の完全ガイド

コンテナ管理システムとは何ですか?全体像

港湾コンテナターミナルの管理システム

コンテナ管理システムは、どのコンテナを、どこに置き、いつ、どの機器で扱い、誰に引き渡すかを一元管理する業務基盤です。一般にはTOSと呼ばれ、在庫を表示するだけでなく、本船計画、ヤードの蔵置、ゲートの受付、作業指示、貿易手続き、監査までをイベント単位でつなぎます。

TOS・YMS・TMS・Cyber Portの違いを整理します

TOSはターミナル内の本船・ヤード・ゲート・荷役機器を統合する中心システムです。YMSはヤードの車両や構内作業、TMSは輸送計画や配車に重点があり、対象業務が重なる部分もあります。Cyber Portは民間事業者間の港湾物流手続きを電子化するデータプラットフォームであり、TOSそのものの代替ではありません。国土交通省の資料では、Cyber Portは帳票作成や情報連携に加えてNACCS連携機能を備え、2021年度の実証で最大60%の時間削減効果が確認されています(出典: 国土交通省「サイバーポート(港湾物流分野)の概要と目指す姿」、2025年)。したがって、TOSの業務データをCyber PortやNACCSへ連携する設計として捉えると、役割分担を誤りにくくなります。

主要機能は現場の一つのシナリオで確認します

要件の洗い出しでは、機能を単独で並べるより、「輸入コンテナが本船から荷卸しされ、ヤードに蔵置され、トラック予約を経て搬出される」という一連のシナリオで確認します。本船・バース管理では入港予定、Bay Plan、積卸し順を扱い、ヤード管理ではコンテナ番号、サイズ、重量、貨物属性、危険品区分、リーファーの電源状態、蔵置場所を扱います。ゲートでは予約、受付、OCRやバーコード、PSカード認証、搬出許可の照合を扱い、機器連携ではガントリークレーン、RTG、構内シャーシなどへの作業指示と実績収集を扱います。

特に重要なのは、現在の状態だけでなく、誰がいつ何を変更したかを履歴として残すことです。搬出許可の更新、危険品情報の変更、リーファー温度の異常、通信断からの復旧は、後から原因を追える必要があります。コンテナ番号を外部照会の唯一の識別子にせず、内部ID、取引ID、イベントIDを分けて設計すると、複数の船社や通関業者とのデータ連携でも情報の取り違えを防ぎやすくなります。

最初に決めるのは機能一覧ではなくKPIと責任分界です

開発の起点は「最新のAIを使うこと」ではなく、現場の待ち時間や荷繰りをどこまで改善するかです。ゲート滞在時間、1時間あたりの取扱量、ヤード占有率、不要な荷繰り回数、リーファー監視にかかる工数、障害から復旧するまでの時間を現状値と目標値で記録します。例えばゲート待機を短縮したい場合、予約枠、到着情報、受付端末、搬出許可照合のどこがボトルネックかを分けて測定しなければ、導入後の効果を説明できません。

また、船社、ターミナルオペレーター、港湾管理者、海貨業者、通関業者、陸運会社、倉庫会社のどこがデータを登録し、承認し、保管するかを決めます。複数組織が関わるため、費用負担と障害時の責任を後回しにすると、システムは動いても業務が止まります。要件定義書には機能だけでなく、入力責任、承認責任、データ所有権、利用停止時の代替手順まで記載します。

コンテナ管理システム開発の進め方

システム開発の要件定義と計画

コンテナ管理システムは、要件定義、方式選定、設計・開発、連携テスト、現場訓練、段階リリース、運用改善の順に進めます。港湾業務は24時間止めにくく、既存システムや機器が多いため、画面を先に作る進め方ではなく、業務シナリオと例外処理を先に固めることが大切です。

要件定義では30項目を業務シナリオで確認します

要件定義では、現状業務、目標KPI、利用者権限、コンテナ属性、ロケーション、イベント履歴、本船・バース、Bay Plan、ヤード配置、ゲート予約、搬出許可、危険品、リーファー、作業指示、機器状態、OCRやバーコード、外部API、EDI、NACCS、Cyber Port、会計・請求、BI、監査ログ、バックアップ、通信断、障害復旧、セキュリティ、データ移行、教育、受入条件という観点を確認します。これらは単なるチェックリストではなく、「どの担当者が、どの端末で、どの情報を入力し、次の作業者が何を判断するか」に落とし込む必要があります。

続いて、通常時と例外時の業務フローを作ります。搬出許可が未確定のままトラックが到着した場合、危険品情報が後から更新された場合、リーファーの温度が閾値を超えた場合、ゲート端末と中央サーバーの通信が途切れた場合、機器が停止した場合を実データに近い条件で再現します。ここで判断者と承認者を決めておくと、開発後に「システムは警告したが誰も対応しなかった」という事故を減らせます。

パッケージ・クラウド・スクラッチをPoCで比較します

方式選定では、パッケージ導入、クラウドTOS、スクラッチ開発、共通プラットフォームと個別アドオンの組み合わせを比較します。パッケージは導入実績と標準機能を活用しやすい一方、現場業務を製品に合わせる必要があります。クラウドは冗長化や更新を行いやすい一方、港内ネットワークが切れた場合の継続運用、設備系ネットワークとの分離、データ所在、接続費用を確認します。スクラッチは独自のヤード計画や機器制御に合わせやすい一方、初期費用、保守要員、バージョンアップ、属人化の負担が大きくなります。

比較のために、実際のBay Plan、ヤード配置、コンテナ属性、予約データを使ったPoCを行います。デモ用のきれいな画面だけでなく、搬出入、荷繰り、異常通知、通信断、機器停止、権限外操作、復旧後の再送を試します。KalerisはNavis TOSが490以上のターミナルで使われていると案内していますが、世界的な導入数がそのまま自社港の適合性を意味するわけではありません。国内の保守体制、NACCSやCyber Portへの連携、機器メーカーとの責任分界まで確認します。

テスト・教育・段階リリースで現場定着を進めます

テストは画面単位ではなく、船舶の入港予定から荷卸し、蔵置、予約、ゲート搬出、請求までを一つの業務シナリオとして実施します。単体テスト、連携テスト、性能テスト、セキュリティテスト、障害復旧テスト、ユーザー受入テストを分け、何をもって合格とするかを事前に決めます。例えば、搬出許可が未承認のコンテナをゲートで通さないこと、二重登録を検知できること、通信復旧後にイベントを欠落させないことを、受入条件に明記します。

教育では、管理者向けの機能説明だけでなく、ゲート担当者、ヤード担当者、荷役機器のオペレーター、ドライバー、夜間当直者の操作を分けて訓練します。高齢のドライバーや繁忙時間帯の担当者でも迷わない画面、入力ミスを減らすバーコードやOCR、手動に切り替える紙帳票を用意します。最初から全機能を切り替えるのではなく、在庫・照会・ゲートを先行し、次に予約・外部連携、最後に荷役最適化や自動化へ進めると、変更の影響を抑えやすくなります。

更改の場合は、マレーシアのPort of Tanjung Pelepasが2024年12月にNavis N4 4.0を稼働させ、顧客サービスを止めずに切り替え、週末の稼働で最大48基のクレーンを12時間シフト運用した事例が参考になります(出典: Port of Tanjung Pelepas発表、2024年)。海外の大規模港の成果をそのまま日本の案件へ当てはめるのではなく、切替リハーサル、現場機器の接続確認、旧システムとの並行運用、ロールバック条件を見積もりに含めることが重要です。

コンテナ管理システムの費用相場とコストの内訳

コンテナ管理システムの費用見積もり

専用TOSは公開価格が少なく、ターミナルの規模、取扱量、自動化レベル、連携先、機器台数、24時間運用、冗長化、移行範囲で金額が大きく変わります。以下の金額は2025〜2026年時点で公開された共通サービス料金と、類似する物流・基幹システムの見積構造から置く初期予算の仮説です。実際の発注では、同じRFPを複数社へ渡して再見積もりを取る必要があります。

導入パターン別の初期費用と期間の目安

共通サービスの利用と最小限のAPI・帳票連携であれば、初期費用は300万〜1,000万円、期間は3〜6か月が一つの仮説になります。これは社内ポータル、データ変換、権限設定、接続試験を主な範囲とする場合で、TOS本体や現場機器の刷新は含みません。

標準化されたクラウドTOSを小〜中規模ターミナルへ導入する場合は、3,000万〜1.5億円、9〜18か月程度を見込みます。ヤード・ゲート・在庫、標準連携、データ移行、教育、運用設計まで含める範囲です。TOSパッケージに複数ターミナル、NACCS、Cyber Port、荷役機器を接続する場合は、1億〜3億円、18〜30か月程度の仮説になります。大規模自動化、複数港、独自最適化、クレーンやRTG連携、デジタルツインまでスクラッチで構築する場合は、3億〜10億円超、24〜48か月になる可能性があります。

なお、国土交通省はCyber Port(港湾物流)の利用料金を2026年4月から1社あたり月額6,600円としています。事業所数やユーザー数にかかわらず一律ですが、利用開始後の通算100取引まで、または月間10取引以下の月などは無料範囲があります(出典: 国土交通省「サイバーポート(港湾物流)の利用登録社数が1,000社を突破」、2026年)。この料金は手続きの共通プラットフォーム利用料であり、TOSのライセンス、導入、個別連携、機器、保守の費用とは分けて考えます。

費用は開発費だけでなく運用継続費まで分解します

見積書では、要件定義・業務設計が10〜15%、アプリ開発やパッケージ設定が25〜40%、外部連携が15〜25%、機器・ネットワーク・現場端末が10〜25%、データ移行・教育・試験が10〜20%程度という配分を仮置きすると、金額の偏りを確認しやすくなります。これは市場平均ではなく、案件の範囲を比較するための推定配分です。機器の更新や既存TOSのライセンス条件によっては、連携費や現場費が大きく増えます。

稼働後は、クラウド利用料、ライセンス、監視、ヘルプデスク、夜間対応、脆弱性診断、バックアップ、ログ保管、端末やネットワークの更新、データ連携の変更、教育、バージョンアップが発生します。一次Q&Aで示された事例では、稼働後のTOS改修・バージョンアップだけで2,000万〜3,000万円規模になったとされています。個別事例であり市場平均ではありませんが、改修費だけでも数千万円になる可能性を示す材料です。保守費は初期費用の年10〜20%程度を仮置きし、何が含まれるかを契約前に分けて確認します。

セキュリティとBCPを別料金にしないことが大切です

港湾のTOSでは、ランサムウェアや不正アクセスで停止した場合にも、船の荷役やゲート受付を継続できるかが重要です。バックアップ環境、ネットワーク分離、特権ID管理、多要素認証、脆弱性診断、操作ログ、監視、復旧訓練、紙や手動での代替手順を初期費用と運用費に分けて提示してもらいます。安い見積もりでも、障害時の待機要員や復旧試験が含まれていなければ、実運用の総額は高くなります。

国土交通省の「港湾分野における情報セキュリティ確保に係る安全ガイドライン」は2026年5月に第3版へ改定され、政府統一基準群や最新の関連ガイドラインを踏まえた内容になっています(出典: 国土交通省「港湾分野における情報セキュリティ確保に係る安全ガイドライン(第3版)」、2026年)。発注時は、ガイドラインへの対応を「セキュリティ対策一式」と曖昧にせず、対象資産、責任者、点検頻度、インシデント時の連絡、復旧目標時間として見積項目に分解します。

コンテナ管理システムの見積もりを取る際のポイント

システム開発会社との見積もり比較

見積もりの精度は、開発会社の計算方法だけでなく、発注側がどこまで前提をそろえられるかで決まります。現行業務の資料、連携先の一覧、データ件数、機器台数、繁忙期、許容停止時間を出し、必須要件と将来要件を分けて提示します。候補会社には、同じ前提で初期費用、期間、保守費、除外項目、追加変更の単価を出してもらいます。

RFI・RFPには現場データと例外条件を入れます

発注前には、ターミナルの平面図とヤード区画、バース数、クレーンやRTGなどの機器一覧、1日・月間の取扱量、船舶の寄港パターン、コンテナの種類、危険品やリーファーの扱い、ゲート数、トラック予約の方法、既存画面、帳票、インターフェース仕様、データサンプルを用意します。個人情報や機密情報が含まれる場合は、マスキングしたデータでPoCを行えるようにします。

RFPには、通常の入出庫だけでなく、搬出許可の遅延、コンテナの再配置、危険品情報の更新、温度アラート、機器の停止、通信断、二重登録、誤操作、夜間の承認者不在を記載します。さらに、最大同時接続数、ピーク時の処理時間、復旧目標時間、データ保持期間、監査ログ、認証方式、APIの再送、障害時の手動運用、受入テストの合格条件まで書くと、会社ごとの見積範囲を比較しやすくなります。

複数社は価格だけでなく責任分界と保守体制で比較します

候補会社は、TOS製品に強い会社、港湾設備やOTに強い会社、NACCSや貿易データ連携に強い会社、リーファーやセンサーに強い会社というように、得意領域を分けて評価します。Kaleris、Tideworks、INFORMのようなTOS製品ベンダーだけでなく、JFEエンジニアリングのようにガントリークレーン遠隔操作化やTOS高度化に取り組む会社、NTTデータのように貿易情報連携の知見を持つ会社など、案件の境界に応じて候補を組み合わせます。

JFEエンジニアリングは国土交通省の2023年度港湾技術開発制度で、ガントリークレーンの遠隔操作化と、TOS高度化によるリーファーコンテナ管理の効率化・荷役安全性の確保が採択されたと発表しています(出典: JFEエンジニアリング「国土交通省令和5年度港湾技術開発制度に採択」、2023年)。これは製品の優劣を断定する情報ではありませんが、TOSと設備・安全を一体で考える際の比較軸になります。契約前には、24時間の障害対応、国内拠点、再委託先、機器メーカーとの責任分界、データの所有権、設定やソースコードの引き渡し条件を確認します。

契約と受入条件で追加費用と停止リスクを抑えます

契約では、固定価格で確定する範囲と、要件変更で追加になる範囲を分けます。APIの仕様変更、船社や通関業者の接続追加、機器更新、帳票変更、法令対応、データ移行のやり直し、夜間の現地対応が、どの単価と承認手順になるかを決めます。再委託の可否、障害時の連絡順、SLA、損害の扱い、脆弱性が見つかった場合の修正期限、契約終了時のデータ返却も確認します。

受入条件は「画面が表示されること」では不十分です。ピーク時の性能、権限外操作の拒否、搬出許可の照合、イベント履歴の完全性、機器からの実績収集、通信断からの復旧、バックアップからの復元、紙や手動への切替、夜間当直者の訓練完了を条件に含めます。切替日には、旧環境へ戻す基準、判断責任者、現場への告知、問い合わせ窓口を決めておくと、問題が起きたときに現場判断だけへ負担を集中させずに済みます。

よくある質問(FAQ)

コンテナ管理システムに関するよくある質問

最後に、発注前によく寄せられる疑問へ回答します。費用や期間はターミナルの規模と連携範囲で変わるため、ここでは判断の基準と見積もりの読み方を中心に説明します。

コンテナ管理システムの開発期間はどのくらいですか?

共通サービスと小規模なAPI・帳票連携なら3〜6か月、標準的なクラウドTOSの導入なら9〜18か月、複数ターミナルや機器連携を含む大規模案件なら18〜48か月程度が初期計画の目安です。要件定義、データ移行、現場教育、並行運用、切替リハーサルを含めずに開発期間だけを提示している場合は、稼働日を別に確認します。

パッケージとスクラッチ開発はどちらが良いですか?

標準的な業務を早く安定させたい場合はパッケージやクラウドTOSが比較しやすく、独自のヤード計画や機器制御を中核競争力にしたい場合はスクラッチや個別アドオンが候補になります。ただし、最初から全面スクラッチにせず、TOSコアを標準機能で導入し、港湾固有の連携をAPIアダプターとして分離する方法もあります。実データを使ったPoCで、現場の例外処理と将来の拡張費を比較して決めます。

Cyber Portの月額6,600円だけでコンテナ管理できますか?

できません。月額6,600円はCyber Port(港湾物流)の共通プラットフォーム利用料であり、TOS本体のライセンス、ターミナル内の在庫・ヤード・ゲート管理、機器連携、移行、教育、保守は別途必要です。Cyber Portの帳票やNACCS連携をTOSと接続する場合は、API仕様、データ変換、エラー時の再送、接続試験を個別の見積項目として確認します。

通信断やランサムウェアで停止した場合はどうしますか?

平常時から、停止時に継続する業務と止める業務を分け、紙帳票やローカル端末などの代替手順を用意します。バックアップからの復元、イベントの再送、二重登録の解消、権限の再確認、機器との再接続を定期的に訓練し、復旧目標時間と判断責任者を決めます。セキュリティ対策を導入時だけの作業にせず、監視、脆弱性対応、教育、復旧訓練を保守契約に含めることが重要です。

まとめ

コンテナ管理システム開発のまとめ

開発で押さえるべき要点

コンテナ管理システムの開発では、港湾コンテナターミナルの本船・ヤード・ゲート・機器を別々にデジタル化するのではなく、コンテナの状態と作業イベントを一つの流れで管理することが大切です。まずゲート滞在時間や荷繰り回数などのKPIを決め、船社、ターミナル、海貨、通関、陸運などの責任分界を整理します。

次に、要件定義で業務シナリオと例外処理を洗い出し、パッケージ・クラウド・スクラッチをPoCで比較します。費用は、標準連携の数百万円規模から、大規模自動化・複数港の数億円規模まで幅があり、Cyber Portの利用料とTOS本体、機器、移行、教育、保守を分けて見積もります。初期費用だけでなく、改修、脆弱性対応、夜間障害、バックアップ、切替リハーサルまで含めて総額を比較します。

最後に、在庫・照会・ゲートから段階的に導入し、通信断や機器停止を含む受入テストを行います。AIやデジタルツインは、イベントログとデータ品質が整ってから追加するほうが、投資効果を検証しやすくなります。現場が止まらないこと、安全に復旧できること、関係者が使い続けられることを、開発会社選びと契約の中心に置いてください。

発注前に次に行うこと

まず現行フローとKPI、連携先、機器一覧、データサンプルをそろえ、必須要件と将来要件を分けたRFI・RFPを作成します。そのうえで、実データに近いPoC、障害復旧テスト、保守体制の確認を行い、価格だけでなく責任分界と運用継続性を基準に発注先を決めます。

▼全体ガイドの記事
・コンテナ管理システム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。