医用画像管理システム（PACS）開発の発注/外注/依頼/委託方法について

医用画像管理システム（PACS）の発注・外注では、安い製品を探すだけでなく、診療を止めずに画像を移行し、電子カルテやRIS、モダリティまで含めて安全に運用できる委託先を選ぶことが重要です。PACSの発注先は、施設規模、検査件数、保存年数、既存機器、読影体制によって適した形が変わります。

この記事では、医用画像管理システム（PACS）を発注・外注・委託する際の進め方を、発注形態の選択、RFPと要件整理、契約形態、費用相場、委託先の選定、見積比較、移行と稼働後の確認まで順番に解説します。公開価格が限られるPACSだからこそ、金額の大小だけで判断せず、見積書の範囲と将来の運用費まで比較できる状態を作ります。

▼全体ガイドの記事
・医用画像管理システム（PACS）開発の完全ガイド

医用画像管理システム（PACS）の発注・外注で最初に決めること

PACSは、画像を保存するサーバーだけの仕組みではありません。撮影装置から画像を受け取り、患者・検査単位で検索し、読影し、レポートを作成し、電子カルテや院内外の関係者へ届ける画像診療の基盤です。そのため、発注の起点は「どの製品を買うか」ではなく、「どの業務を、どの水準で、誰が支えるか」を決めることです。

まず、現行PACSで困っている場面を、機能名ではなく業務の事実で整理します。たとえば「過去画像が表示されるまで長い」「他院から届いた画像を手作業で登録している」「検査予約と患者情報の入力が二重になっている」「読影レポートの承認状況が分からない」といった表現です。放射線科だけでなく、放射線技師、医師、医事担当、情報システム担当、経営側から聞き取り、通常業務と例外業務を分けて記録します。

目的が「サーバー更新」だけに見えても、実際には検査量の増加、診療科間の画像共有、遠隔読影、災害時の継続運用、AIの追加利用などが隠れていることがあります。目的を一文で「既存画像と新規画像を安全に管理し、必要な検査を診療現場が遅延なく参照できる状態にする」のように定義すると、不要なカスタマイズを抑えやすくなります。

PACSと一緒に確認する対象は、CT・MRI・X線・超音波・内視鏡などのモダリティ、RIS、HIS・電子カルテ、レポート、画像診断支援AI、VNA、地域連携、バックアップ、認証基盤です。PACS側の画面が高機能でも、RISから患者情報が正しく渡らなければ入力の二重化が残ります。逆に、クラウドPACSの保管機能が優れていても、院内ネットワークや画像の事前取得が不足すれば読影時の待ち時間が問題になります。

発注書やRFPでは「PACS導入一式」とだけ書かず、対象となるモダリティ台数、年間検査件数、保存期間、同時接続数、既存データ量、読影端末数、連携先、必要な稼働時間を記載します。これらが決まっていない状態で取った見積は、会社ごとに前提が異なるため比較できません。

PACSの発注形態はパッケージ・クラウド・スクラッチをどう選びますか？

結論から言うと、標準的な画像診療を短期間で安定させたい場合はパッケージまたはクラウドPACSが第一候補です。既存システムや独自業務に合わせた差別化が経営上重要で、標準機能では対応できない場合に限り、追加開発やスクラッチを慎重に検討します。方式の選択は初期費用だけでなく、移行、保守、障害対応、契約終了後のデータ搬出まで含む総保有コストで行います。

標準パッケージは、PACSに必要な画像管理、Viewer、検索、権限管理などが検証済みで、要件が標準業務に近い施設ほど導入しやすい方式です。クラウド型は院内に大規模なサーバーやストレージを所有しなくてよく、機器更新や遠隔地との共有を委託しやすい点が特徴です。PSP株式会社の公式サービスページでは、東日本と西日本の二拠点でデータを多重保管し、レンタル機器により初期投資ゼロを実現する方式が示されています。ただし、初期投資ゼロは総額ゼロという意味ではなく、月額、容量、接続、移行、契約期間、データ搬出費を確認します。

クラウドを選ぶ場合は、院内からクラウドへの回線障害を想定します。直近画像を院内キャッシュに置くのか、障害時に最低限の画像を閲覧できるのか、復旧目標時間と復旧目標時点をどう定義するのかを、サービス説明だけでなくSLAと運用手順で確認します。

オンプレミス型は院内ネットワークで大容量画像を扱いやすく、回線に依存しにくい反面、サーバー、ストレージ、バックアップ、監視、更新、保守要員を自院側で持つ必要があります。ハイブリッド型は直近画像を院内で高速に参照し、長期保存画像をクラウドへ置くなど、診療の速度と災害対策を組み合わせやすい方式です。

選定時は「クラウドかオンプレミスか」を先に決めるのではなく、検査件数、画像のサイズ、保存年数、夜間・休日の読影、複数施設の連携、回線の冗長性を並べます。たとえば、複数拠点の画像を横断検索したい病院グループはクラウドの利点が大きく、院内で大量のCT画像を連続表示する施設はキャッシュや回線設計の検証が重要です。

スクラッチ開発や大規模な追加開発は、独自の読影フロー、複数ベンダーの統合、VNAによる非DICOM画像の集約など、標準製品だけでは業務を合わせにくい場合に有効です。一方、PACSは医療画像の標準仕様、モダリティ接続、Viewerの性能、長期保存、セキュリティ更新が必要なため、画面を作れる開発会社なら十分とは限りません。

外注先にスクラッチ部分を任せる場合は、DICOMの受信・検索・取得・保存、監査ログ、患者IDの同定、障害時の復旧、データ移行を誰が設計し、誰が試験し、誰が保守するのかを明確にします。独自コードの著作権、ソースコードや設計書の引き渡し、第三者保守の可否、担当会社が撤退した場合の引き継ぎ条件も、発注前に確認する項目です。

RFPと要件整理は医用画像管理システムの発注前にどう進めますか？

RFPは、候補会社に同じ前提で提案と見積を出してもらうための依頼書です。PACSでは製品カタログを転記するより、現場の業務シナリオと非機能要件を具体化することが成果につながります。最初からすべてを完璧に決める必要はありませんが、比較に必要な前提は発注者側でそろえます。

棚卸しでは、モダリティのメーカー・機種・台数、DICOM接続方式、検査件数、画像容量、保存年数、旧PACSのデータ形式、レポートやキー画像の有無を記録します。患者IDや検査IDのルールが部門ごとに異なる場合は、移行前に名寄せや重複の扱いを決めなければなりません。CDやDVD、他院から持ち込まれた画像、JPEG・PDF、非DICOM画像も対象に含めるか確認します。

移行要件には、全件移行か直近年だけの移行か、移行中も旧PACSを使うか、検査・シリーズ・インスタンスの件数照合をどう行うかを記載します。サンプル画像で表示、計測、比較、レポート参照まで確認し、移行後に読影医が「必要な画像がない」とならないようにします。データ移行費が見積に含まれているか、失敗時の再移行費が誰の負担かも、RFPの質問項目にします。

MUSTには、診療継続に直結する要件を置きます。たとえば、患者IDの取り違えを防ぐ仕組み、モダリティからの画像受信、必要な過去画像の検索、電子カルテからの起動、権限管理、監査証跡、バックアップ、障害時の代替運用です。WANTには、将来のAI連携、スマートフォン参照、地域連携、3D高度解析などを置き、初期導入に含めるか、拡張余地だけ確保するかを判断します。

優先順位を付けずに要件を増やすと、各社が別々の追加機能を見積もり、価格差の理由が分からなくなります。候補会社には、MUSTを満たせない場合の代替案、WANTを後から追加する場合の費用単位、標準機能と個別開発の境界を回答してもらいます。要件定義の段階で「必須」「できれば」「今回は対象外」を明示することが、発注後の追加費用を抑える基本です。

技術要件には、DICOMのC-STORE、C-FIND、C-MOVE、C-GET、DICOMwebのQIDO-RS、WADO-RS、STOW-RS、MWL、MPPSなど、必要な接続方式を記載します。DICOM公式は、DICOMwebを医用画像のWeb標準として説明し、既存のDIMSEサービスへのプロキシとして実装できるとしています。2026年2月に公表された鳥取大学の放射線部門システム調達でも、DICOM標準、DICOMweb、IHE Radiologyの主要プロファイルへの対応が要件に含まれていました（出典: 政府公共調達データベース、2026年）。

性能要件は「速い」ではなく、通常時と混雑時の目標を定義します。たとえば、検査検索の応答時間、過去画像を開くまでの時間、同時読影者数、夜間の一括受信量、クラウド障害時の切替時間などです。セキュリティでは、多要素認証、権限の最小化、アクセスログ、暗号化、脆弱性対応、バックアップ復元、委託先の監視範囲を明記します。厚生労働省の「医療情報システムの安全管理に関するガイドライン第7.0版」は2026年6月に改訂され、契約や保守委託機関に関する資料も公開されているため、RFPと契約の確認軸にします（出典: 厚生労働省、2026年）。

PACSの契約形態と責任分界はどこまで決めますか？

PACSの外注契約では、開発・導入・移行・保守・クラウド利用が一つの契約に見えても、責任と料金の発生条件は別々です。契約書、提案書、要件定義書、仕様書、SLA、運用手順書の優先順位を決め、どの文書が正式な合意内容かを明確にします。

要件と成果物が固まっている導入や開発には、請負契約が適することがあります。請負にする場合は、納品物を「PACS一式」とせず、設定書、連携仕様、移行結果報告、テスト記録、操作マニュアル、教育記録、バックアップ・復元手順、設計書などに分解します。検収では、正常系だけでなく、患者IDの修正、通信断、重複受信、旧画像の検索、権限外アクセス、復元テストなどを含めます。

追加要件が出たときの変更管理も必須です。誰が変更を承認するか、費用と納期への影響を何営業日で提示するか、緊急の診療継続対応をどう扱うかを決めます。発注者側の確認遅れや第三者システムの仕様変更が、納期遅延や追加費用になる条件も、曖昧なまま残さないようにします。

要件定義、現状調査、PoC、ベンダー調整、運用改善など、作業を進めながら内容を具体化する部分は、準委任契約で専門家の稼働を委託する形が合う場合があります。ただし、準委任だから成果が不要になるわけではありません。会議体、作成する資料、レビュー回数、意思決定事項、月次の報告、課題管理表などを合意し、活動の成果を追えるようにします。

要件定義だけを準委任で依頼し、その後の導入を別会社へ発注する場合は、設計書とRFPの引き渡し条件を確認します。要件を作った会社と導入会社が違うと、前提の説明に時間がかかるため、成果物の粒度、第三者利用の許可、レビュー記録、未決事項の扱いを事前に定めると引き継ぎが安定します。

医用画像は、契約終了後も診療記録として扱う期間が続きます。契約書には、データの所有・利用権限、保存期間、バックアップの扱い、移行時のデータ形式、搬出方法、搬出費用、消去証明、ログの引き渡し、第三者への再委託、障害時の連絡先を記載します。クラウド利用料だけを見て契約すると、終了時の移行費やデータ取り出し制限が後から問題になることがあります。

厚生労働省の第7.0版に関連して公開されている「医療情報システムの契約における当事者間の役割分担に関する確認表」も、責任分界を確認する材料になります。自院が担う設定・教育・アカウント管理と、委託先が担う監視・脆弱性対応・復旧・報告を区別し、口頭説明ではなく契約文書に落とし込みます（出典: 厚生労働省、2026年）。

医用画像管理システム（PACS）の費用相場と見積内訳

PACSは、製品価格や導入条件が公開されていないケースが多く、施設規模や画像容量によって見積が大きく変わります。以下は、公開価格、公開調達要件、業務システムの一般的な相場を組み合わせた記事用の推定レンジです。PACS市場全体の公定価格ではないため、予算の初期検討に使い、最終的には同じ条件のRFPで個別見積を取得します。

小規模診療所や健診施設が標準パッケージまたはクラウド型を導入する場合、初期費用は0万〜300万円程度、ランニング費用は月額5.5万〜30万円程度が一つの検討レンジです。中小病院で複数モダリティ、電子カルテ・RIS連携、データ移行を含める場合は、初期費用300万〜1,500万円程度、月額10万〜50万円程度、または保守費用が初期費用の年10〜20％程度となるケースを想定します。

中〜大規模病院でPACS、RIS、VNA、冗長化、大量移行を含める場合は、初期費用1,000万〜5,000万円超、ランニング費用は年額数百万円からとなる可能性があります。フルスクラッチや複数施設を統合する基盤は、初期費用3,000万〜1億円超、導入期間12〜24か月以上を見込むことがあります。いずれも施設条件による推定です。

公開例として、キッセイコムテックが2019年に案内したハイブリッドクラウド型PAXiS-Xには月額55,000円からという表示がありました。ただし、これは容量などで変動する過去の公開例で、2026年の導入価格を保証するものではありません。また、PSPのクラウドPACS NOBORIは初期投資ゼロのモデルを示していますが、月額利用料や施設ごとの構成費用が発生します。公開価格は比較の起点にとどめ、現在の見積条件と分けて扱います（出典: キッセイコムテック、PSP株式会社）。

見積書では、PACSライセンス、Viewer、同時接続数、ストレージ、サーバーや専用機器、モダリティ接続、HIS・RIS・電子カルテ連携、レポート、AI、バックアップ、監視、セキュリティ、データ移行、端末・モニター、現地作業、教育、保守を分けて表示してもらいます。項目が一式でまとめられている場合は、数量、単価、期間、前提条件、対象外を質問します。

クラウドは初期費用が小さく見えても、保存容量、転送量、追加ユーザー、AI処理、長期保存、データ搬出、最低利用期間で総額が変わります。オンプレミスは初期の機器・設置費が大きくなりやすく、数年ごとの更新、保守部品、バックアップ媒体、電源・空調まで必要です。5年程度の利用期間を置き、初期費用と月額・年額を合算して比較すると、方式間の差を把握しやすくなります。

相見積もりで最も注意したいのは、安い提案が要件を満たしていないのか、単に別項目を除外しているのか分からない状態です。候補会社には、同じRFPに対して標準範囲、オプション、前提未確定、対象外を色分けしてもらいます。追加費用が発生する条件を、データ量の増加、モダリティ追加、連携仕様の変更、休日作業、移行リトライ、回線変更などに具体化します。

比較表を作るときは、価格だけでなく、導入期間、移行対象、SLA、障害時の代替手順、教育時間、問い合わせ窓口、契約更新条件、データ搬出費を同じ列にします。初期費用が安くても、毎月の容量課金や高額なオプションを加えると5年総額が逆転することがあります。反対に、高い提案でも移行・教育・保守が含まれていれば、発注者側の追加作業が少なくなる可能性があります。

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

委託先は、知名度や営業資料の印象だけでなく、自院と似た規模・モダリティ・連携環境で導入した経験を確認します。製品を持つメーカー系ベンダー、クラウドPACS事業者、医療ITに強いSIer、要件定義や複数社調整を支援する独立系会社では、得意な責任範囲が異なります。

実績を聞くときは「病院への導入実績があります」だけで終わらせません。自院に近い病床規模、モダリティ数、年間検査件数、クラウド・オンプレミスの方式、HIS・RIS・レポート連携、旧PACSからの移行件数、稼働後の保守体制を確認します。可能であれば、同意を得た導入先の担当者に、切替時の停止時間、想定外の追加費用、稼働後の問い合わせ対応を聞きます。

また、提案時の営業担当と、実際に要件定義・移行・保守を担当する人が同じとは限りません。責任者、医療連携の担当者、DICOMやネットワークの担当者、導入後のサポート責任者を示してもらい、担当者の交代や再委託のルールも確認します。

デモ画面の印象だけで委託先を決めると、実運用の問題を見落とします。匿名化または検証用に準備した実データに近いCT・MRI画像を使い、患者検索、前回画像との比較、MPR、計測、レポート作成、電子カルテからの起動、他院画像の取り込み、権限別の表示を同じ手順で試します。大量画像の受信中に読影できるか、回線を制限したときにどう動くかも確認します。

PoCでは、成功条件を数値で決めます。検索にかかる時間、検査の登録誤り、移行した件数と不一致件数、画像表示の再現性、障害時の復旧時間、利用者教育後の操作完了率などです。候補会社に自社のシナリオを渡し、標準機能、設定、追加開発、運用変更のどれで実現するのか回答してもらうと、見積の根拠も読みやすくなります。

面談では「この機能はありますか」だけでなく、「その機能を使うために別契約や追加ライセンスが必要ですか」「旧PACSの全件移行を誰が担当しますか」「移行データの照合結果をどの帳票で報告しますか」「患者IDの不一致が見つかったとき誰が修正しますか」と質問します。回答が提案書、見積書、契約書のどこに記載されるかも確認します。

さらに、「サービス終了や事業譲渡が起きた場合の通知期間」「契約終了後のデータ搬出形式と費用」「障害が診療に影響した場合の連絡と報告」「脆弱性が判明した場合のパッチ適用」「AI機能の承認・認証の範囲」を確認します。AIについては診断を自動化する機能と、読影支援・トリアージ・計測などを分け、医療機器プログラムとしての承認・認証が必要かを委託先に説明させます。

発注後のPACS導入は移行・教育・切替までを計画します

PACS導入は、契約締結で終わりではありません。現状調査、要件定義、設計、設定・開発、連携試験、移行リハーサル、利用者教育、稼働判定、本番切替、安定化支援という流れで進めます。病院では診療を止められないため、切替日から逆算して、誰が何を確認するかを計画書に落とします。

データ移行は一度で完了する前提にせず、対象データの抽出、変換、取り込み、件数照合、サンプル読影を複数回行います。CTやMRIだけでなく、レポート、キー画像、マーク、動画、非DICOM画像、患者属性の扱いも確認します。移行中に新しい検査が発生するため、差分移行や切替直前の最終同期をどう行うかを決めます。

切替前には、旧PACSを参照専用で残す期間、紙や別媒体で記録する場合の手順、回線断・サーバー障害・認証障害時の連絡網を準備します。復旧テストでは、バックアップが存在することだけでなく、実際に画像を復元して検索・表示できることまで確認します。切替後の問い合わせ窓口を一本化し、現場からの改善要望を優先度付きで管理すると、稼働直後の混乱を抑えられます。

教育は一度の操作説明会で終わらせず、放射線技師、読影医、依頼医、事務担当、情報システム担当に分けます。画像の検索・比較・計測・レポート作成、患者IDの修正申請、他院画像の取り込み、障害時の連絡、権限申請など、職種ごとの実務シナリオを使います。マニュアルは画面説明だけでなく、例外時に誰へ連絡するかまで含めます。

稼働後は、画像受信エラー、表示遅延、未登録検査、権限エラー、容量、バックアップ、監査ログを定期的に確認します。月次の運用会議で、障害件数、復旧時間、問い合わせ内容、追加要望を見直し、契約更新前には5年総額とデータ搬出条件を再確認します。PACSは長期利用する基盤だからこそ、導入プロジェクトと運用改善を別の活動として継続させます。

医用画像管理システム（PACS）の発注・外注でよくある質問

ここでは、発注前に特に質問されやすい内容をまとめます。費用や方式に唯一の正解はないため、自院の検査量と業務要件に置き換えて確認してください。

小規模なクラウド・パッケージで初期0万〜300万円程度、中小病院で300万〜1,500万円程度、中〜大規模病院で1,000万〜5,000万円超という推定レンジがあります。ただし、これは公開価格と業務システム相場を組み合わせた目安で、PACSの公定価格ではありません。画像容量、モダリティ、移行、連携、Viewer、AI、冗長化、教育、保守を分けた見積を取得してください。

クラウドだから自動的に安全、またはオンプレミスだから安全とは言えません。データの多重保管、暗号化、認証、監査ログ、脆弱性対応、バックアップ復元、回線障害時の代替運用、委託先の監視体制を確認し、厚生労働省のガイドラインと自院の運用規程に照らして判断します。クラウド事業者の説明に加え、契約書とSLAで責任分界を確認することが重要です。

すべて移行するか、直近数年分だけ移行するかは、保存義務、参照頻度、費用、旧システムの保守期限、画像の完全性を踏まえて決めます。全件移行なら、画像だけでなく患者・検査ID、レポート、キー画像、動画、移行後の照合まで対象にします。段階移行なら、旧PACSを参照専用で残す期間、旧環境のバックアップ、契約終了後の閲覧方法を明記し、移行しないデータを放置しないことが大切です。

候補の得意領域を見極めるため、少なくとも複数社へ同じRFPを提示し、価格だけでなく方式、移行範囲、連携、保守、契約終了条件を比較します。社数を増やしすぎると質問と評価に時間がかかるため、最初は自院の要件に合う候補を絞り、PoCや詳細提案へ進む会社を選ぶ方法が現実的です。相見積もりの目的は最安値を探すことではなく、前提とリスクを可視化することです。

まとめ：PACSの発注・外注は業務要件と契約条件をそろえて比較します

発注前は、(1)解決したい業務、(2)モダリティ・HIS・RISなどの連携範囲、(3)画像とレポートの移行対象、(4)診療を継続するための性能・障害対応、(5)契約終了時のデータ搬出を一枚の資料にまとめます。この五つがそろうと、候補会社の提案条件をそろえやすくなり、見積の抜けや追加費用の境界も確認しやすくなります。

いきなり製品デモを予約するのではなく、放射線科、医師、情報システム担当、事務担当へヒアリングし、代表的な検査と困っている例外運用を整理します。その内容をRFPにして複数の候補会社へ渡し、同じ業務シナリオのデモやPoC、移行方法、5年総額、契約条件を比較してください。自院だけで要件整理が難しい場合は、医療システムに詳しい第三者へ要件定義や比較支援を委託する方法もあります。

医用画像管理システム（PACS）の発注では、最初に解決したい業務と対象範囲を決め、現行環境・データ移行・連携先を棚卸しします。そのうえで、標準パッケージ、クラウド、オンプレミス、ハイブリッド、追加開発の中から、診療継続性と運用体制に合う方式を選びます。RFPではMUSTとWANTを分け、DICOM、HIS・RIS連携、性能、監査、バックアップ、障害時の代替運用を試験方法まで含めて記載します。

費用は、公開例や業務システム相場を参考にした推定レンジとして扱い、ライセンス、連携、移行、端末、セキュリティ、教育、保守、データ搬出を分解して5年総額で比較します。委託先の実績は、社名の知名度より自院と似た条件での担当範囲、移行責任、障害対応、契約終了時のデータ返却を確認します。診療を止めない切替と、稼働後の改善まで契約・運用計画に含めることが、PACS外注を成功させるポイントです。

▼全体ガイドの記事
・医用画像管理システム（PACS）開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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