コンテナ管理システム開発の発注/外注/依頼/委託方法について

コンテナ管理システムの発注は、発注目的をKPIで定め、対象と関係者の範囲を決めるところから始まります。そのうえで発注形態を検討し、RFPとPoCで提案を比べ、契約と受入条件を固めます。見積は金額だけでなく、委託先の近い実績と障害時の復旧体制まで同じ評価表で比べます。

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

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

コンテナ管理システムの発注で最初に決めること

コンテナ管理システムは、番号と蔵置場所を記録する台帳にとどまりません。船舶予定、Bay Plan、ヤードの情報を、ゲート予約や荷役機器とつなぎます。

危険品やリーファーの管理、NACCSやCyber Portとの連携も含みます。

港湾TOS（Terminal Operating System）として、業務、データ、設備、セキュリティを設計します。

画面の機能から決めると、誰が何を受け持つか、停止時に手作業へどう切り替えるかが抜けやすくなります。

発注目的のKPI定義

まず、現状を測るKPIを決めます。ゲート滞在、トラック待機、1時間あたりの荷役量のほか、ヤード占有率や荷繰り回数も測る対象になります。

• 現場作業：リーファー確認の工数と、搬出許可の照合ミス
• 障害対応：障害からの復旧時間と、代替手順への切替時間

「ゲートを効率化する」という目標を数値にするため、予約車両の受付から入場許可までの平均時間を定めます。

通信断のときに何分で代替手順へ移るかも、受入基準に入れておきます。

外部サービスを使う場合も、KPIには問い合わせや書類処理、重複入力がどれだけ減るかを置きます。外部サービスの利用そのものは目的にしません。

対象ターミナルと関係者の範囲

対象施設と業務によって、システムの境界は変わります。選定の前に、施設、システム境界、業務と責任の違いを整理します。

• 対象施設：港湾ターミナル、内陸デポ、空コンテナヤード、倉庫ごとに必要な機能
• システム境界：本船・バース中心はTOS、構内車両中心はYMS、配車中心はTMSを候補とする
• 業務と責任：登録、搬出承認、訂正、障害時判断それぞれの担当

たとえば、港湾TOSを内陸デポにそのまま導入すると、不要な機能と費用が増えます。

関係者には、ターミナルオペレーター、船社、港湾管理者が含まれます。

海貨と通関、陸運と倉庫、設備保守会社も関わります。

複数の組織が費用を負担する場合は、共通機能と個別機能、データの所有者、窓口を合意しておきます。

業務フローには、どこまでを誰が受け持つかを書き込みます。

コンテナ管理システムの発注形態の選び方

発注形態は、クラウドTOS・SaaS、TOSパッケージへの連携追加、既存TOS改修に加え、スクラッチ開発まで含めて考えます。

形態ごとに、港内ネットワーク停止時の業務継続、設備接続、法令や帳票変更への追随を比べます。さらに、データ移行や24時間保守、契約終了時の移行も含め、5年程度の総費用をそろえて比較します。

標準化と導入実績を重視するときのパッケージ

パッケージでは、船舶、バース、ヤードなどの共通機能を使えます。ゲートや作業指示、在庫、請求も含まれるため、要件を一から作る負担を抑えられます。

KalerisはNavis TOSが世界490超のターミナルで使われていると説明しています（出典：Kaleris「Ports Terminals」、2026年確認）。

実績のある製品では、例外処理、権限、監査ログの確認がしやすくなります。

海外での導入実績は、そのまま国内案件の成功と見なさず、国内の港湾手続や保守体制を案件ごとに見ます。

標準機能との差が大きいほど、アドオンや改修が増えます。デモは画面の見た目より、実業務のシナリオで判断します。

• 貨物・ヤード：Bay Plan取込、危険品搬出制御、誤配置への対応
• 現場・設備：リーファー温度異常と、機器の通信断への対応
• 履歴・更新：訂正履歴と旧データ参照、更新時の個別改修への影響

クラウドの拡張性と港内の通信断への備え

クラウド型は、サーバーの調達・更新やバックアップ、遠隔監視を自社だけで抱え込まずに済む方式です。

拠点や利用者が増えても対応でき、ポータルなどから始めて段階的に広げられます。

• 拡張：ポータル、予約、照会、帳票、外部連携から始め、在庫や荷役計画へ広げられる
• 通信断：端末表示、ローカル保存、再送のタイミング
• 運用・安全：保管場所、API・ファイル制限、バックアップ、RTO・RPO、認証、ログ、脆弱性、再委託、解約時返却まで確認する
• 共通サービス：Cyber Port料は港湾物流手続向けで、TOSの開発・連携・運用費とは別

国土交通省が2026年に公表した「サイバーポート（港湾物流）の利用登録社数が1,000社を突破！」によると、2026年2月1日時点の利用登録社数は1,065社です。

Cyber Portの利用料は、2026年4月から1社あたり月額6,600円で、事業所数やユーザー数によらず一律です。

独自の荷役・設備要件が競争力に直結する場合のスクラッチ開発

スクラッチは、独自要件に価値がある場合に選ぶ選択肢です。判断に関わる要点は、項目ごとに整理します。

• 適用条件：独自ヤード最適化、複数港在庫、特殊貨物、クレーン・RTG制御が競争力になる場合
• 長期管理：仕様、テストデータ、設備接続、24時間監視、脆弱性、開発者交代を管理する
• 段階導入：在庫、ゲート、照会、作業実績から始め、予約・連携・最適化・自動化を追加する
• 引き継ぎ：ソース、設計書、データ辞書、API、設定、テスト成果物、第三者保守、終了時移行を納品範囲に含める

現場の例外処理から始めるRFPと要件整理

RFPは、機能一覧と価格を求めるだけの資料にとどまりません。背景や対象、業務、課題を先に示し、KPIからデータ、連携、非機能まで書きそろえます。さらに、移行、教育、保守、体制を含め、見積条件まで書き込みます。

正常な搬出入に加えて、例外の場面も含めると、提案力を比べられます。

例外の場面は、たとえば予約なし車両、番号読取の失敗、許可の不一致です。ほかに、危険品情報の遅れやリーファー異常、機器停止、通信断も入れます。

RFPの業務・データ・連携・非機能の章立て

業務、データ、連携、画面の要件を分けると、抜けを点検できます。項目ごとに、書く内容を示します。

• 業務：本船・バース・荷役計画、ヤード、荷繰り、ゲート、予約、危険品、リーファー、機器、請求、監査
• データ：番号、サイズ、重量、貨物属性、場所、イベント、許可、温度、操作・訂正履歴
• 連携：API・ファイル、頻度、締め時刻、タイムアウト、再送、重複防止、通知、手動復旧
• 画面・非機能：高齢のドライバーや現場作業員が短時間で操作できること、失敗時の有人対応、保存期間、正本データ、セキュリティ、移行、保守

番号だけを外部照会のIDにすると、入力ミスや番号の再利用があったときに追跡しにくくなります。内部IDと外部表示を分ける設計も検討します。

NACCS、Cyber Port、CONPASの正本データを決めます。

船社や海貨、通関とのあいだでも、正本の扱いを決めます。運送、会計・請求、BIとのあいだも、同じ考え方で正本を定めます。

OCRやバーコードが読めなかったときに、人が対応する手順も定めます。

提案比較の前に行う実データのPoC

実データを使ったPoCで確かめ、提案書やデモだけで選ばないようにします。比較では、次の観点をそろえます。

• 業務データ：Bay Plan、ヤード配置、ゲート予約、危険品、リーファー、搬出許可、作業指示の実データ
• 実運用：操作の迷い、原因追跡、通信復旧後の二重登録、業務を止めない移行を評価する
• 実施条件：費用、期間、データ、成果物、製品版への反映範囲を事前に書面化する
• 見積反映：追加機能を標準設定、アドオン、個別開発、運用代替に分類する

無償デモでは、個別連携や運用設計が見えないこともあります。

PoCで確かめた分類を、本見積の前提に反映します。

契約形態と発注後の進め方の設計

企画や現状分析、RFP支援は準委任、仕様確定後の開発は請負、クラウドや監視は利用・保守契約で組み合わせる方法が一般的です。

工程ごとに責任や成果物、検収、変更手続きを分けておくと、発注者と受託者の認識の差を管理できます。

要件定義の準委任と、確定した開発の請負

契約は工程と成果物に合わせて分け、準委任から請負へ移る条件もあらかじめ文書にしておきます。

• 準委任：専門家、会議体、資料、レビュー、課題管理、報告期限を決め、ヒアリング・フロー・辞書・RFP・PoC報告を成果物にする
• 請負：システム、設計書、テスト、移行ツール、マニュアル、運用手順と完成定義、検収、契約不適合、遅延の扱いを定める
• 変更管理：仕様が曖昧なまま全工程を請負にすると、価格へのリスク上乗せや変更時の追加請求が起きやすい。影響、費用、納期、品質、セキュリティを記録して承認する

準委任では、定めた成果物によって支援の価値を評価でき、稼働時間だけで測らずに済みます。

要件や画面、連携の合意に加え、非機能、移行、受入基準の合意も、請負への移行条件にします。

契約に入れる再委託・データ・障害時の責任

契約では、データや再委託、停止時の継続責任を整理します。特に、次の範囲を明記します。

• データ：番号、船荷、貨物、運送・ドライバー情報、ログの目的、保管、権限、暗号化、保存、返却・消去、監査
• 再委託：クラウド、OCR、通知、監視、設備連携先の承認・報告、国外移転、事故連絡を確認する
• 事業継続：攻撃、災害、設定ミス、故障、通信断を想定し、SLA、第一報、復旧目標、代替運用、バックアップ、修正、演習、損害分担を定める

2026年改定の港湾安全ガイドラインは、サービス継続と、障害発生時の迅速な復旧を含む考え方を示しています。

実運用のシナリオと障害復旧まで確認する検収

検収条件は、実運用を通して確認できる形にします。そのうえで、試験により利用性や記録、復旧を評価します。

• 業務記録：搬入から請求までのイベント記録と訂正履歴の確認
• 利用・権限：承認権限を試し、ドライバーや夜勤担当者の入力負荷と誤操作を評価する
• 障害対応：正常・異常、性能、セキュリティ、移行、復元、通信断、機器停止、攻撃時の代替運用を試す

搬入コンテナの到着からゲート受付、蔵置場所の決定までと、荷役完了から搬出許可、請求までのイベントを記録します。

権限のない担当者が承認できないことも、確認できる条件にします。

海外の例では、Port of Tanjung Pelepasが2024年12月にNavis N4 4.0を稼働させ、既存運用を止めない計画的な切替でした（出典：Port of Tanjung Pelepas資料、2025年公表）。

国内の規模にはそのまま当てはめず、無停止に近い切替や設備接続、変更管理の受入条件を考える参考にします。

コンテナ管理システムの費用相場と見積の見方

専用TOSは公開されている定価が少なく、費用は規模や取扱量、拠点によって変わります。さらに、標準機能との差や連携、設備の範囲で金額が変わり、端末、移行、保守、教育の内容でも差が出ます。

ここに示す数字は2025〜2026年時点の予算仮説です。公開価格が限られ、市場平均や確定価格とは言えないため、同じRFPで複数社に見積もりを依頼します。

導入範囲別の初期費用の幅

費用と期間の幅は、導入範囲によって変わります。下の金額は、初期予算を置く際の仮説として扱います。

• 共通サービス中心：300万〜1,000万円、3〜6か月程度
• 標準クラウドTOS：3,000万〜1.5億円、9〜18か月程度
• 複数ターミナル・機器連携：1億〜3億円、18〜30か月程度
• 大規模自動化・スクラッチ：3億〜10億円超、24〜48か月程度

最小構成は、社内ポータルと権限、最小限のAPI・帳票連携です。

標準TOSの例は小〜中規模向けで、ヤードやゲート、在庫を含みます。また、移行と教育も入ります。

複数ターミナルや、NACCSやCyber Portなどの外部連携、船社・運送会社との連携まで含む場合は、上位レンジです。加えて、クレーンなどの機器連携、冗長化、24時間保守まで含めると、上位レンジの見積になります。

大規模な自動化、複数港、独自のヤード最適化、デジタルツイン、スクラッチ開発を含めると、3億〜10億円超、24〜48か月となる場合があります。

TOS、共通サービス、機器、ネットワークの費用は、分けて示してもらいます。

稼働後改修2,000万〜3,000万円規模の事例もあります。ほかに、追加改修だけで数千万円となる可能性も、予算に残しておきます（出典：リポジトリ内「コンテナ管理システム」一次Q&A、2026年）。

開発費に加えて連携・移行・保守を分けた比較

見積の内訳をそろえておくと、総額のどの箇所で差が生じたかを判断できます。費目ごとに、金額と作業範囲を示してもらいます。

• 設計・開発：要件定義10〜15%、アプリ設定・開発25〜40%
• 外部・設備：連携15〜25%、機器・ネットワーク10〜25%
• 導入作業：移行・教育・試験10〜20%程度

比率は案件の構成で変わるため、割合だけで判断しないようにします。

ランニング費用には、クラウド利用料やライセンス、監視、ヘルプデスクが含まれます。さらに、夜間障害対応や脆弱性診断、バックアップも対象です。

端末や通信、更新、追加改修も加えて、5年間の総保有コストで比べます。初年度の安さだけで選ばないようにし、月額6,600円のCyber Port料とTOSの費用は切り分けて見ます。

委託先の選定と見積比較で確認すべきポイント

知名度や価格だけでなく、TOS業務や港湾設備・OT、貿易データを確かめます。さらに、24時間対応と国内保守も見ます。

TOS製品、港湾設備、大規模SI、リーファー・IoTなど、得意分野は会社ごとに異なります。

そのうえで、自社に近い規模と課題を持つ担当者を提案チームに含められるかを聞きます。

対象業務と責任範囲で見る実績

同じ導入実績でも、担った範囲や規模によって自社案件との近さは変わります。そのため、経験の中身は、担った範囲、導入と運用、規模と接続に分けて見ます。

• 担当範囲：本船、ヤード、ゲート、機器のどこを担ったか
• 導入と運用：パッケージか個別開発か、拠点数、保守担当
• 規模と接続：取扱量、利用者、連携先、移行方式

顧客名を出せない場合は、匿名化しても説明できるかを確認します。取扱量やユーザー数、連携先、移行方式、障害対応体制が対象です。

Bay Plan変更を荷役指示に反映させる責任、通信断後の再送と重複防止、リーファー異常の確認時間を質問します。

見積の外にある作業や、第三者ライセンス、現地立会い、夜間切替、旧システムとの並行稼働も一覧にします。

金額より前に見る見積の前提条件と除外項目

見積額を比べる前に、前提条件と評価軸をそろえ、確認する内容を分けて整理します。

• 見積前提：拠点、ユーザー、取扱量、連携、機器、データ、試験、教育、支援、保守時間
• 費用区分：標準機能、設定、アドオン、個別開発、外部サービス、手作業
• 評価軸：業務適合、非機能・安全、連携・移行、体制、保守、費用、将来拡張
• 追加確認：重要な要件差はPoCへ回し、関係部門が同じ評価表で判断する

機器連携を含む会社もあれば、別料金や発注者作業とする会社もあります。

安い金額が、そのまま有利とは限りません。

費用だけを重く見ると、要件漏れや追加請求のリスクを見落としやすくなります。

比較には、業務や情シスに加え、法務、現場、経理も参加します。

よくある質問

費用、RFPの準備、契約の分け方、セキュリティの確認について、よくある疑問に答えます。

コンテナ管理システムの発注費用はいくらですか？

初期費用は、共通サービス中心で300万〜1,000万円、標準クラウドTOSで3,000万〜1.5億円が仮説になります。複数ターミナルや機器連携を含む場合は1億〜3億円、大規模な自動化やスクラッチは3億〜10億円超となる場合があります。

規模や連携、設備、移行、保守で変わる推定値で、公開価格ではありません。同じRFPで2〜3社へ確認してください。

RFPは自社だけで作成できますか？

自社で作れますが、現場や情シス、法務に加えて、経理、設備保守、連携の担当者を集め、業務と例外を整理します。

• 経験が不足する場合：準委任で第三者の支援を受ける
• 発注者が決めること：KPIと優先順位、責任の分け方、受入基準
• 開発会社に依頼する場合：特定の製品に有利な条件になっていないかを、複数社への質問で確かめる

準委任契約と請負契約はどちらが適していますか？

現状分析やRFP、要件定義、PoCは準委任、仕様確定後の開発は請負が基本的な検討対象です。クラウドと保守は、利用・保守契約に分けます。

契約形態だけでなく、成果物や検収、変更、障害の扱いも明記します。さらに、再委託やデータ、知的財産、終了時の移行も含めます。

港湾システムの外注でセキュリティは何を確認しますか？

認証や権限、分離を確認します。暗号化やログ、バックアップの扱いも見ます。そのうえで、診断の状況とパッチ、再委託先の扱いを確かめます。

障害時には、第一報と復旧目標を確認します。代替運用と訓練も見ます。

2026年改定の港湾安全ガイドラインを参照します。また、通信断や攻撃を想定し、紙や手動、別系統へ切り替えたうえで、復旧後に再同期できるかを検収します。

まとめ

発注前に一枚にまとめるKPIと責任の分け方

発注準備から選定までは、次の流れで進めます。

• 範囲とKPI：港湾TOSの対象、本船・ヤード・ゲート・機器、連携、セキュリティ、BCPを整理する
• 方式と契約：各方式を5年間の運用、更新、障害対応、終了時移行まで比べ、工程ごとに責任を定める
• 比較と検証：例外対応を含むRFPを作り、複数社の提案と実データのPoCを評価する

関係者の間で業務とデータの責任を決めておくと、発注条件を同じ前提で比べられます。

委託先の実績と復旧力まで比べる見積

RFPと契約では、例外時の判断や復旧、再委託、データを明文化します。さらに、SLAや受入、ソースと設定の引き渡しも書き込みます。現行の待機や荷繰り、入力、障害対応を測り、その数値を複数社へ出すRFIやRFPの資料にまとめ、実データに近いPoCで操作、連携、復旧、移行を確かめます。

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

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

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