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

コンテナ管理システムの発注・外注では、港湾コンテナターミナルの本船・ヤード・ゲート・荷役機器をどこまで一体化し、停止時にも業務を続けられる状態までを契約範囲に含めるかが成否を分けます。単なる在庫管理画面ではなく、TOS（Terminal Operating System）として業務、データ、設備、セキュリティを同時に設計することが重要です。

本記事では、港湾向けのコンテナ管理システムを前提に、パッケージ・クラウド・スクラッチの発注形態、RFPと要件整理、準委任・請負などの契約、2026年時点の費用相場、委託先の選び方、見積比較のポイントを解説します。DockerやKubernetesなどITインフラのコンテナ管理とは検索意図が異なるため、港湾、内陸デポ、ターミナルの担当者が発注判断に使える内容に絞ります。

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

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

コンテナ管理システムは、コンテナ番号と蔵置場所を記録するだけの台帳ではありません。船舶の入港予定やBay Plan、ヤードの空き状況、ゲートの搬出入予約、クレーンや構内車両への作業指示、危険品・リーファーの状態、NACCSやCyber Portなどの外部連携を結び、現場の判断を支える業務基盤です。発注前に「どの画面を作るか」から始めると、業務の責任分界や停止時の手作業が抜けやすくなります。

最初に、ゲート滞在時間、トラックの待機時間、1時間あたりの荷役量、ヤード占有率、荷繰り回数、リーファー確認にかかる工数、搬出許可の照合ミス、障害からの復旧時間を現状値として計測します。例えば「ゲートを効率化する」という目的は、「予約済みトラックの受付から入場許可までを平均何分にするか」「通信断時には何分以内に代替手順へ切り替えるか」まで具体化すると、提案内容と受入基準に変換できます。

最新の動向として、国土交通省は港湾物流手続を電子化するCyber Portの利用登録社数が2026年2月1日時点で1,065社になったと公表しています（出典：国土交通省「サイバーポート（港湾物流）の利用登録社数が1,000社を突破！」、2026年）。外部サービスを使う場合も、導入した事実ではなく、問い合わせ時間や書類処理時間、データ入力の重複がどれだけ減るかをKPIに置くことが大切です。

同じコンテナ管理でも、港湾ターミナル、内陸デポ、空コンテナヤード、倉庫では必要な機能が異なります。本船・バース・荷役計画が中心ならTOS、ヤード内の車両や作業の管理が中心ならYMS、配車や輸送計画が中心ならTMSとの境界を整理します。港湾TOSの機能をそのまま内陸デポへ持ち込むと、不要な機能と費用が増えるため、対象業務を最初に線引きします。

また、ターミナルオペレーターだけでなく、船社、港湾管理者、海貨業者、通関業者、陸運会社、倉庫、設備保守会社が関わります。誰がコンテナ属性を登録し、誰が搬出を承認し、誰が誤登録を訂正し、誰が障害時に判断するかを業務フローへ書きます。複数組織が費用を負担する場合は、共通機能と個別機能、データ所有者、問い合わせ窓口を先に合意しておくと、契約後の追加要求を抑えられます。

コンテナ管理システムの発注形態はどれを選びますか？

発注形態は、クラウドTOSやSaaSを利用する方法、TOSパッケージに個別連携を加える方法、既存TOSを改修する方法、独自要件をスクラッチ開発する方法に分けて考えます。判断基準は初期費用だけではありません。港内ネットワークが停止したときの業務継続、設備との接続、法令や帳票変更への追随、データ移行、24時間の保守、契約終了時の移行まで含めて5年程度の総費用で比較します。

パッケージは、船舶・バース・ヤード・ゲート・作業指示・在庫・請求など、TOSに共通する機能を利用できるため、要件を一から作る負担を下げられます。複数ターミナルで運用実績がある製品なら、例外処理や権限、監査ログの考え方も確認しやすくなります。KalerisはNavis TOSについて、世界490超のターミナルで利用されていると説明しています（出典：Kaleris「Ports Terminals」、2026年確認）。ただし、海外製品の数字を国内案件の成功保証と解釈せず、日本の港湾手続や保守体制を個別に確認します。

標準機能と自社業務の差が大きい場合は、アドオンや個別改修が増えます。デモでは画面の見た目ではなく、Bay Planの取込、危険品の搬出制御、リーファーの温度異常、コンテナの誤配置、作業機器の通信断、訂正履歴、旧データの参照まで実データに近いシナリオで確認してください。バージョンアップ時に個別改修が壊れないかも、発注前に質問すべきポイントです。

クラウド型は、サーバーの調達や更新、バックアップ、遠隔監視を自社だけで抱えにくく、拠点追加や利用者増加にも対応しやすい方式です。社内ポータル、予約受付、照会、帳票、外部連携から小さく始め、在庫や荷役計画を段階的に広げる場合に適しています。一方で、港内の無線や専用ネットワークが切れたときに、現場端末が何を表示し、何をローカル保存し、どの時点で再送するかを設計しなければなりません。

確認項目は、データの保管場所、APIとファイル連携の制限、バックアップの世代、RTO・RPO、認証方式、ログの保存期間、脆弱性対応、再委託先、解約時のデータ返却です。Cyber Portの利用料金は2026年4月から1社あたり月額6,600円で、事業所数やユーザー数によらず一律ですが、これは港湾物流手続の共通サービス利用料であり、TOS本体の開発・連携・運用費とは別です（出典：国土交通省「サイバーポート（港湾物流）の有料化の開始について」、2025年）。

独自のヤード配置最適化、複数港をまたぐ在庫管理、特殊な貨物属性、ガントリークレーンやRTGとの制御連携など、製品の標準機能では競争力を出せない場合はスクラッチが候補です。業務に合う画面と処理を作れる反面、仕様決定、テストデータ作成、設備接続、24時間監視、脆弱性対応、開発者交代のすべてを長期的に管理する必要があります。

最初から全機能を一括開発せず、コンテナ在庫、ゲート受付、照会、作業実績を第一段階とし、予約、外部連携、荷役最適化、機器自動化を後から加える段階導入が現実的です。スクラッチを発注するなら、ソースコード、設計書、データ辞書、API仕様、設定値、テスト成果物、第三者保守の可否、契約終了時の移行支援まで納品範囲に含めます。

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

RFPは、開発会社へ機能一覧を渡して価格を聞く資料ではありません。発注の背景、対象ターミナル、現行業務、課題、目標KPI、対象データ、連携先、非機能要件、移行、教育、保守、提案体制、見積条件を同じ前提で比較するための資料です。正常な搬出入だけでなく、予約なしの車両、コンテナ番号の読み取り失敗、搬出許可の不一致、危険品情報の更新遅れ、リーファー温度異常、機器停止、通信断を先に書くと、提案の実力が見えます。

業務要件には、本船・バース・荷役計画、ヤード配置、荷繰り、ゲート搬出入、予約、危険品、リーファー、作業指示、機器状態、請求、監査を含めます。データ要件には、コンテナ番号、サイズ、重量、貨物属性、蔵置場所、搬入搬出イベント、許可状態、温度、操作履歴、訂正履歴を含め、保存期間と正本データの所在も定めます。コンテナ番号を外部照会の唯一のIDにすると、入力ミスや再利用時の追跡が難しくなるため、内部IDと外部表示を分ける設計も検討します。

連携要件は、APIかファイルかだけでなく、連携頻度、締め時刻、タイムアウト、再送、重複防止、エラー通知、手動リカバリを指定します。NACCS、Cyber Port、CONPAS、船社、海貨、通関、運送会社、会計・請求、BIとの間で、誰がどのデータを正とするかを一覧化します。画面要件では、高齢のドライバーや現場作業員が短時間で操作できること、OCRやバーコードの失敗時に有人対応へ移れることまで確認します。

提案書とデモ画面だけで選定せず、代表的なBay Plan、ヤード配置、ゲート予約、危険品、リーファー、搬出許可、作業指示を使ってPoCを行います。比較するのは、処理できた機能数だけではありません。現場担当者が迷わず使えるか、例外発生時に原因を追跡できるか、通信断から復旧した後に二重登録が起きないか、既存業務を止めずに移行できるかを評価します。

PoCの費用、期間、利用データ、成果物、製品版への反映範囲を事前に書面で定めます。無償デモでは製品の標準機能だけが示され、個別連携や運用設計が隠れることがあります。PoCで追加開発が必要になった機能は、標準設定、アドオン、個別開発、運用で代替のどれに当たるかを分類し、本見積の前提へ反映させます。

契約形態と発注後の進め方を分けて設計します

要件が固まっていない企画・現状分析・RFP作成支援では準委任契約、仕様と成果物が確定した開発では請負契約、クラウド利用や監視では利用契約・保守契約を組み合わせる方法が一般的です。すべてを一つの契約に押し込むのではなく、工程ごとに責任、成果物、検収、変更手続きを分けると、発注者と受託者の認識差を管理しやすくなります。

準委任契約では、稼働時間だけでなく、参加する専門家、会議体、作成資料、レビュー方法、課題管理、報告期限を明記します。現場ヒアリング、業務フロー、データ辞書、RFP、PoC評価報告を成果物として定めると、要件定義支援の価値を評価しやすくなります。請負契約へ移る条件も、要件、画面、連携、非機能、移行、受入基準が合意された状態として文書化します。

請負契約では、システム、設計書、テスト結果、移行ツール、操作マニュアル、運用手順などの納品物と完成の定義、検収期間、契約不適合への対応、遅延時の扱いを定めます。仕様が曖昧なまま全工程を請負にすると、受託者がリスクを価格へ上乗せするか、変更のたびに追加請求となりやすい点に注意します。変更要求は、影響範囲、費用、納期、品質、セキュリティを記録して承認する手続きを作ります。

コンテナ番号、船荷情報、貨物属性、運送会社やドライバーの情報、操作ログを扱う場合は、データの種類、利用目的、保管場所、アクセス権、暗号化、ログ保存期間、返却・消去、監査権限を契約に含めます。クラウド、OCR、通知、監視、設備連携の事業者へ再委託する場合は、再委託先の承認や報告、国外移転の有無、事故時の連絡経路を確認します。

港湾分野では、サイバー攻撃だけでなく、災害、設定ミス、機器故障、通信断などによるサービス停止も想定します。国土交通省の「港湾分野における情報セキュリティ確保に係る安全ガイドライン」は2026年5月に第3版へ改定され、サービスの継続と障害発生時の迅速な復旧を含む考え方を示しています（出典：国土交通省「港湾分野における情報セキュリティ確保に係る安全ガイドライン（第3版）」、2026年）。SLA、第一報の期限、復旧目標、代替運用、バックアップ、脆弱性修正、演習、損害分担をRFPと契約の両方に反映します。

受入基準を「担当者が使えること」とだけ書くと、検収時に判断が分かれます。搬入コンテナの到着、ゲート受付、蔵置場所の決定、荷役完了、搬出許可、請求までの一連のイベントが正しく記録されること、訂正履歴を追えること、権限のない担当者が承認できないことを確認可能な条件に変換します。高齢のドライバーや夜勤担当者を含む実際の利用者に操作してもらい、入力負荷と誤操作も評価します。

テストは、正常系、異常系、権限、性能、セキュリティ、移行、バックアップ復元、通信断、機器停止、ランサムウェアを想定した代替運用に分けます。マレーシアのPort of Tanjung Pelepasは2024年12月にNavis N4 4.0を稼働させ、既存運用を止めない計画的な切替を発表しました（出典：Port of Tanjung Pelepas「Port of Tanjung Pelepas goes live with Kaleris 4.0 Terminal Operating System」、2025年）。国内の規模にそのまま当てはめるのではなく、無停止に近い切替、設備接続、変更管理を受入条件に含める参考にします。

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

専用TOSは公開定価が少なく、費用はターミナルの規模、コンテナ取扱量、拠点数、標準機能との差、外部連携、荷役機器、現場端末、データ移行、24時間運用、セキュリティ、教育で大きく変わります。以下は2025〜2026年時点で公開価格が限られることを踏まえ、発注前の予算仮説として使うレンジです。市場平均や確定価格ではないため、同じRFPを複数社へ渡して再見積もりを取ります。

共通サービスを利用し、社内ポータル、権限設定、最小限のAPI・帳票連携に絞る場合は、初期費用300万〜1,000万円、期間3〜6か月程度を仮置きします。標準化されたクラウドTOSを小〜中規模ターミナルへ導入し、ヤード・ゲート・在庫、移行、教育まで含める場合は3,000万〜1.5億円、期間9〜18か月程度が目安です。TOS本体、共通サービス料金、現場機器、ネットワークは分けて計上します。

複数ターミナル、NACCSやCyber Port、船社・運送会社、クレーンなどの機器連携、冗長化、24時間保守まで含めると1億〜3億円、18〜30か月程度を見込みます。大規模な自動化、複数港、独自のヤード最適化、デジタルツイン、スクラッチ開発を含めると3億〜10億円超、24〜48か月となる場合があります。一次Q&Aで示された稼働後のTOS改修2,000万〜3,000万円規模の事例からも、稼働後の追加改修だけで数千万円になる可能性を予算に残しておく必要があります（出典：リポジトリ内「コンテナ管理システム」一次Q&A、2026年）。

見積では、要件定義・業務設計、アプリの設定・開発、外部連携、機器・ネットワーク、データ移行、試験、教育、稼働支援、保守運用を分けて提示してもらいます。初期費用の仮説配分は、要件定義10〜15%、アプリ開発・設定25〜40%、外部連携15〜25%、機器・ネットワーク10〜25%、移行・教育・試験10〜20%程度です。案件の構成によって変動するため、比率ではなく金額と作業範囲を確認します。

ランニング費用には、クラウド利用料、ライセンス、監視、ヘルプデスク、夜間障害対応、脆弱性診断、バックアップ、現場端末、通信、バージョンアップ、追加改修を含めます。5年間の総保有コストで比較し、初年度だけ安い提案を選ばないことが大切です。Cyber Portの月額6,600円のような共通サービス料金を見つけても、TOSの開発費や連携費が不要になるわけではないため、見積書の対象範囲を必ず切り分けます。

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

委託先は、会社の知名度や提示価格だけで選ばず、TOSの業務理解、港湾設備・OTとの接続、貿易データ連携、24時間障害対応、国内の保守体制を確認します。TOS製品を持つ会社、港湾設備に強い会社、大規模SIに強い会社、リーファーやIoTに強い会社では、得意領域が異なります。候補を選んだ後は、自社のターミナル規模と課題に近い担当者を提案チームへ含められるかを聞きます。

実績確認では、港湾やコンテナというキーワードだけでなく、本船・ヤード・ゲート・機器のどこを担当したか、パッケージ導入か個別開発か、何拠点で使われているか、稼働後の保守を誰が担うかを確認します。導入事例の顧客名を開示できない場合でも、取扱量の規模、ユーザー数、連携先、移行方式、障害対応の体制を匿名化して説明できるかで経験を見極められます。

ベンダーへは「同じような画面を作れますか」と聞くより、「Bay Planの変更が荷役指示へ反映されるまでの責任分界はどこですか」「通信断後の再送と重複防止は誰が実装しますか」「リーファー異常を誰が何分以内に確認しますか」と質問します。見積に含まれない作業、第三者製品のライセンス、現地立会い、夜間切替、旧システムの並行稼働も一覧にしてもらいます。

複数社の見積を比較するときは、総額を並べる前に、対象拠点、ユーザー数、コンテナ取扱量、連携本数、機器台数、データ件数、テスト回数、教育日数、稼働支援期間、保守時間をそろえます。A社は機器連携を含み、B社は別途、C社は発注者作業としている可能性があるため、安い金額がそのまま有利とは限りません。標準機能、設定、アドオン、個別開発、外部サービス、手作業の区分を同じ表現で出してもらいます。

評価配点は、業務適合性、非機能・セキュリティ、連携・移行、導入体制、保守、費用、将来拡張に分けます。費用を最も重くすると、要件漏れと追加請求のリスクを取り込んだ提案を選びやすくなります。提案比較の最後には、候補会社と要件の差分を確認し、重要な差分だけを追加PoCへ回します。発注者側の業務責任者、情シス、法務、現場、経理が同じ評価表で判断することが、契約後の手戻りを減らします。

よくある質問

コンテナ管理システムの発注では、製品機能や価格以外にも、発注者側の準備、契約の責任分界、稼働後の運用が疑問になりやすいです。ここでは、特に問い合わせの多い判断を直接回答します。

最小限の共通サービス利用とAPI・帳票連携なら300万〜1,000万円、標準化されたクラウドTOSなら3,000万〜1.5億円、複数拠点・機器連携を含む大規模TOSなら1億〜3億円程度を初期予算の仮説にします。自動化やスクラッチ開発では3億〜10億円超となる可能性もあります。公開価格ではなく、規模、連携、機器、移行、保守の条件で変わる推定値なので、同じRFPで2〜3社へ確認してください。

自社で作成できますが、現場、情シス、法務、経理、設備保守、外部連携の担当者を集め、業務フローと例外処理を整理する必要があります。要件定義の経験が不足する場合は、準委任で第三者の支援を受けながらRFPを作り、発注者がKPI、優先順位、責任分界、受入基準を決めます。開発会社にRFP作成を任せる場合も、特定製品に有利な条件になっていないかを複数社の質問で確認します。

要件が変わりやすい現状分析、RFP作成、要件定義、PoCは準委任、完成する仕様と納品物が決まった開発は請負が基本的な検討対象です。実際には、要件定義を準委任、開発を請負、クラウドと保守を利用・保守契約に分けます。契約形態そのものより、成果物、検収、変更、障害、再委託、データ、知的財産、終了時の移行を明記できているかが重要です。

認証・権限、ネットワーク分離、暗号化、操作ログ、バックアップ、脆弱性診断、パッチ適用、再委託先、インシデント第一報、復旧目標、代替運用、復旧訓練を確認します。2026年改定の港湾分野向け安全ガイドラインを参照し、サービス継続の観点でRFPを作成してください。機能が動くことだけでなく、通信断やサイバー攻撃を想定し、紙・手動・別系統の運用へ切り替え、復旧後に正確に再同期できるかを検収します。

まとめ

コンテナ管理システムの発注・外注では、最初に港湾TOSとしての対象範囲とKPIを決め、本船、ヤード、ゲート、荷役機器、外部連携、セキュリティ、BCPを同じ業務シナリオで整理します。発注形態は、パッケージ、クラウド、既存TOS改修、スクラッチを、初期費用だけでなく5年間の運用、バージョンアップ、障害対応、契約終了時の移行まで比較します。

RFPには正常系だけでなく、許可不一致、誤配置、通信断、機器停止、リーファー異常、サイバー攻撃などの例外と、誰が判断し、どう復旧するかを記載します。要件定義・PoCは準委任、仕様確定後の開発は請負など、工程ごとに契約を分け、再委託、データ所有権、SLA、受入基準、ソースコードと設定の引き渡しを明文化します。見積は金額の安さではなく、含まれる範囲と除外項目をそろえて比較することが大切です。

まずは現行のゲート待機時間、荷繰り、入力作業、障害対応を計測し、関係者と業務・データ・責任分界を一枚にまとめます。その資料をもとに複数社へRFIやRFPを出し、実データに近いPoCで操作性、連携、復旧、移行を確認すれば、自社のターミナルに合う委託先と発注条件を選びやすくなります。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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