医用画像管理システム（PACS）開発の進め方/やり方/流れや方法/手法/工程/手順

医用画像管理システム（PACS）開発は、画像を保存するサーバーを選ぶだけではなく、撮影から読影、レポート承認、電子カルテ参照、長期保管、障害時の診療継続までを一つの業務基盤として設計する取り組みです。成功のポイントは、要件整理から定着までを6つのフェーズに分け、患者IDの安全性・既存画像の連続性・現場の表示速度を優先順位付きで確認することです。

本記事では、医用画像管理システム（PACS）の開発・導入の進め方を、要件整理、製品・方式の選定、設計開発、テスト、稼働、定着の順に解説します。2026年時点の公的な調達要件や公開価格を参考にした費用レンジ、RFPや見積書で確認したい項目、クラウド・オンプレミス・ハイブリッドの判断基準もまとめています。新規導入だけでなく、旧PACSの更新や複数施設の画像統合を検討する担当者にも使える内容です。

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

医用画像管理システム（PACS）開発の全体像

PACSは、X線、CT、MRI、超音波、内視鏡などの画像をDICOM規格で受信・保存・検索・表示・配信するシステムです。実際の開発では、PACS単体ではなく、HIS・電子カルテ、RIS、モダリティ、レポート、画像診断AI、地域連携や遠隔読影のサービスをつなぐ「画像診療の基盤」として考える必要があります。

PACSの中心機能は、検査画像を患者・検査単位で管理し、必要な医師が適切なタイミングで参照できるようにすることです。Viewerには多断面再構成、比較表示、計測、ハンギングプロトコル、動画・3D表示などが含まれる場合があります。一方、RISは検査予約や受付、実施、読影進捗など放射線部門の業務を管理し、VNAは複数のPACSや施設に分散した画像・PDF・JPEGなどを中立的に統合保管する役割を担います。名称だけで機能を比較せず、どのシステムが患者情報、検査情報、画像、レポートの正本を持つのかを整理することが重要です。

標準パッケージは短期間で導入しやすく、既存の運用を大きく変えずに始めたい施設に向いています。クラウドPACSはサーバー更新や遠隔参照、施設間連携、災害対策を考えやすい方式です。オンプレミスは院内ネットワークを使った高速表示や細かな設備管理に適し、ハイブリッドは直近画像を院内キャッシュ、長期保存画像をクラウドに置くように役割分担できます。独自の業務や複数ベンダーの統合が主目的でない限り、最初からフルスクラッチを前提にせず、標準機能と追加開発の境界を見極めることが費用とリスクを抑えます。

医用画像管理システム（PACS）の進め方・開発工程

PACSの導入は、製品デモを見てすぐ契約するより、現状調査と要件整理から始める方が安全です。特に画像診療は、通常の読影だけでなく救急、病棟、外来、カンファレンス、他院画像の持ち込みなど複数の例外運用が存在します。次の6フェーズを一つの計画としてつなぎ、各フェーズの完了条件を決めてから次へ進みます。

最初に、モダリティの種類と台数、年間検査件数、1検査あたりの画像容量、保存年数、同時接続数、読影端末の場所を棚卸しします。続いて、HIS・電子カルテ・RIS・レポート・AI解析・他院画像取り込みとの連携、旧PACSの保守期限、既存データの形式と件数を確認します。現場ヒアリングでは「画像を表示できるか」だけでなく、救急検査を何秒以内に見たいか、過去画像を何年分比較するか、承認前のレポートを誰が閲覧できるかまで具体化します。

要件はMUST、SHOULD、WANTに分けます。MUSTには患者ID取り違え防止、画像と患者情報の紐付け、既存モダリティの接続、バックアップ復元、監査証跡、障害時の代替手順を置きます。将来のAI、地域連携、モバイル参照などはWANTに分け、導入初日から必要か、稼働後に追加できるかを確認します。鳥取大学の2026年2月の調達要件でも、DICOMのC-STORE・C-FIND・C-MOVE・C-GETに加えて、DICOMweb、IHE Radiology、MWL、MPPS、FHIR DiagnosticReport、既存機器との継続接続、データ移行などが明記されています（出典: 政府公共調達データベース、2026年）。

選定では、製品カタログの機能数よりも、自院の業務シナリオを同じ条件で比較します。候補ベンダーには、救急CTの撮影終了からViewer表示まで、前回画像との比較、電子カルテからの起動、他院CDの取り込み、読影レポートの承認・差し戻し、ネットワーク断時の閲覧というシナリオを提示します。実データに近い匿名化画像を使い、CT・MRIの表示速度、画像の欠損、患者属性の表示、DICOMタグ変換、ログの確認までPoCで検証します。

クラウドを選ぶ場合は、初期費用だけでなく、保存容量、転送量、最低利用期間、追加Viewer、データ搬出、回線二重化、障害時の代替参照を確認します。オンプレミスでは、サーバー・ストレージ・バックアップ・保守更新・設置場所・電源・空調を含めます。ハイブリッドでは、院内キャッシュに置く期間、クラウドへ送るタイミング、キャッシュ消失時の再取得時間、院内とクラウドの責任分界をRFPに書きます。方式の結論は「クラウドが安全」「オンプレミスが速い」と一律に決めず、診療継続、予算、拠点数、ネットワーク品質で判断します。

設計では、患者・検査・シリーズ・インスタンスのデータ構造、患者IDの採番と名寄せ、DICOMタグの変換ルール、モダリティからの受信経路、Viewerの表示権限、レポートの状態遷移を決めます。特に患者IDの修正手順は、誤紐付けを検知した場合の隔離、承認者、修正履歴、関連レポートへの反映まで含めて設計します。画像解析AIを組み込む場合も、解析結果を診断の代替とせず、どの画面に補助情報として表示するか、承認済みの結果を誰が確認するかを定めます。

連携設計では、HIS・RISとの患者属性・検査予約連携、MWL、MPPS、レポート連携、DICOMweb、他院画像の取り込みを一覧にします。各連携について、送信元、送信先、プロトコル、再送条件、エラー通知、テストデータ、障害時の手作業を記録します。要件定義書や基本設計書を誰が保有するか、仕様変更の承認者は誰か、稼働後の問い合わせ窓口はどこかも契約前に合意します。ここが曖昧だと、開発終盤に「それは別途費用です」となりやすいためです。

テストは、画面が表示されるかだけで終わらせません。単体テスト、連携テスト、性能テスト、セキュリティテスト、移行テスト、障害復旧テスト、受入テストを分け、合否基準を事前に設定します。DICOMの受信・検索・取得、圧縮画像、動画、マルチフレーム、PR・SR・SEGなどの解析結果、文字化け、患者属性の欠落を確認します。異なるメーカーのCT・MRI・超音波・内視鏡を接続し、既存モダリティで撮影した画像を新PACSに継続して送れるかを検証します。

受入テストでは、診療放射線技師、放射線科医、救急担当、医療情報部門、事務担当がそれぞれ実際の操作を行います。患者IDの入力ミス、検査キャンセル、再撮影、他院画像の持ち込み、レポート差し戻し、夜間の障害連絡など、通常業務から外れたケースを含めます。テスト結果は、再現手順、影響範囲、暫定対応、修正期限、再テスト結果まで記録します。合格していない重要シナリオを残したまま、稼働日だけを優先しないことが医療安全につながります。

既存画像の移行は、PACS更新の成否を左右する工程です。移行対象を、DICOM Study・Series・Instance、患者・検査ID、レポート、キー画像、PR・SRなどに分け、対象期間と除外条件を明確にします。移行前後で検査件数、シリーズ数、画像枚数、容量を照合し、救急・術前・経過観察など重要症例を抽出してサンプル読影します。単にファイルがコピーされているかではなく、患者名、患者ID、検査日、モダリティ、シリーズ、過去比較が正しく見えるかを確認します。

切替方式は、一括切替、段階切替、旧PACSとの並行運用から選びます。診療を止められない病院では、繁忙期を避けた切替時間、旧PACSを参照専用で残す期間、紙や一時保存への退避、ネットワーク断時の読影手順、ベンダーの現地待機体制を決めます。クラウドの場合は、回線障害時に院内キャッシュを閲覧できるか、クラウド側の障害時に最低限の検査情報を確認できるかを確認します。稼働判定会議では、未解決課題を重要度別に並べ、診療影響のある課題は解消または代替手順の訓練を完了させます。

稼働初日はゴールではなく、運用を安定させるスタートです。診療放射線技師、医師、看護師、事務職員、医療情報部門ごとに、日常操作、例外操作、障害時の連絡先、患者ID訂正、他院画像取り込み、レポートの承認ルールを教育します。操作マニュアルは機能一覧ではなく、「救急CTを確認する」「前回画像を呼び出す」「誤紐付けを報告する」といった業務シナリオで作ると定着しやすくなります。

運用開始後は、画像受信エラー、表示時間、未読レポート、患者ID訂正件数、問い合わせ件数、容量増加率、バックアップ・復元テストの結果を定期的に確認します。厚生労働省は2026年6月に「医療情報システムの安全管理に関するガイドライン 第7.0版」と、医療機関・薬局向けのサイバーセキュリティ対策チェックリストを公開しています（出典: 厚生労働省、2026年6月）。監査ログのレビュー、脆弱性対応、アカウント棚卸し、復元訓練、契約終了時のデータ返却確認を、PACSの定期運用に組み込みます。

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

PACSの価格は、モダリティ台数、年間検査件数、保存年数、画像容量、Viewer同時接続数、HIS・RIS連携、データ移行、冗長化、教育、保守の範囲で大きく変わります。公開価格が少ないため、以下はPACS単独の公定価格ではなく、リサーチノートで確認した公開情報と業務システムの類似相場を組み合わせた推定レンジです。予算化では、初期費用と月額費用を別々に見るのではなく、契約期間をそろえた総保有コストで比較します。

小規模診療所や健診施設がクラウド・パッケージを導入する場合、初期費用は0万〜300万円程度、ランニング費用は月額5.5万〜30万円程度、導入期間は1〜3か月が一つの目安です。中小病院で複数モダリティと電子カルテ・RIS連携を行う場合は、初期費用300万〜1,500万円程度、月額10万〜50万円程度、または保守年額が初期費用の10〜20％程度となるケースを想定します。期間は3〜9か月程度ですが、既存画像の移行量や切替条件で延びます。

中〜大規模病院でPACS、RIS、VNA、冗長化、大量移行を含める場合は、初期費用1,000万〜5,000万円超、ランニング費用は年額数百万円から、期間は6〜18か月程度が推定レンジです。フルスクラッチまたは大規模な統合基盤では、3,000万〜1億円超、12〜24か月以上となる可能性があります。これらは個別案件の見積価格ではなく、要件を置いた場合の予算検討用のレンジです。施設規模や画像量を確認せずに、特定の金額を「相場」として断定することはできません。

キッセイコムテックのPAXiS-Xは、2019年の提供開始情報で月額55,000円からと案内されていますが、保管容量で増減するサービス価格であり、2026年の医療機関向け見積を示すものではありません（出典: キッセイコムテック、2019年）。PSPのクラウドPACS NOBORIは、専用アプライアンスをレンタル提供して初期投資ゼロとする方式を案内していますが、実際の月額は施設規模、容量、Viewer、連携、保守範囲で変わります（出典: PSP株式会社、確認時点2026年）。

また、2025年に公表された上場企業資料には、提供側企業がPACSのクラウド化に約600万円を投じる計画が記載されていますが、これはサービス提供側の開発・クラウド化投資であり、医療機関の導入費ではありません（出典: 上場企業資料、2025年7月）。公開情報は、価格の下限や市場の投資規模を考える材料にはなりますが、自院の予算をそのまま決める根拠にはなりません。見積では、画像容量の増加、移行対象年数、追加連携、データ搬出、教育、夜間対応を分けて確認します。

オンプレミスでは、サーバー、ストレージ、バックアップ、予備機、OSやミドルウェアの更新、保守要員、電源・空調、災害対策の費用が発生します。クラウドでは、保存容量、転送量、長期保存、追加Viewer、AI解析、外部連携、回線、サポートレベルが月額や従量料金に影響します。ハイブリッドでは、院内キャッシュとクラウド保管の双方について、容量拡張・機器交換・再取得・保守の費用を確認します。

3年または5年の総保有コストを試算するときは、初期費用、月額・年額、画像移行費、連携費、端末・モニター費、教育費、監視・保守費、障害対応費、契約終了時の搬出費を同じ表に並べます。月額が安く見えても、最低利用期間や容量超過、データ搬出が高ければ、更新時の選択肢が狭くなることがあります。価格の安さだけでなく、診療を止めないために必要な費用が含まれているかを確認します。

医用画像管理システム（PACS）の見積もりを取るポイント

見積の精度は、ベンダーに渡す情報の具体性で決まります。「PACSを導入したい」という依頼だけでは、各社が異なる前提で提案するため、金額も比較できません。少なくとも現行構成、対象施設、モダリティ、検査件数、保存年数、利用者数、連携先、移行対象、稼働希望日、障害時の目標、将来拡張をRFPに記載し、同じ業務シナリオと回答形式で提案を求めます。

機能面のチェックリストは、DICOM Storage・Query/Retrieve、DICOMweb、MWL・MPPS、Viewerの表示・計測・比較・3D、レポート作成・音声認識・承認、他院画像取り込み、VNA、遠隔読影、AI連携を含めます。運用面では、患者IDの入力・訂正、権限、監査ログ、バックアップ、復元、障害通知、容量監視、パッチ適用、24時間365日のサポート、教育、問い合わせの責任分界を確認します。必須条件には「対応可」だけでなく、標準機能か追加開発か、実績のある接続方式か、検証環境で再現できるかまで回答してもらいます。

データ移行のチェックリストは、対象期間、対象モダリティ、画像・レポート・キー画像の種類、件数照合、欠損時の扱い、移行中の新規検査、サンプル読影、旧環境の保管期間、移行後の責任範囲を含めます。契約終了時のチェックリストは、データの所有権、標準形式での返却、返却費用、返却期限、削除証明、設計書・設定値・ログの引き渡し、他社へ切り替えるときの支援を確認します。これらを契約書や仕様書に残すことが、ベンダーロックインを避ける具体策です。

相見積もりでは、価格を一番に並べるのではなく、医療安全、業務適合性、連携実績、移行計画、性能、セキュリティ、運用支援、拡張性、契約条件の順に評価します。例えば、同じ「電子カルテ連携」でも、起動だけなのか、患者属性・検査情報・レポートを双方向で連携するのかで工数は変わります。同じ「クラウド対応」でも、二拠点保管、暗号化、回線障害時のキャッシュ、障害復旧目標、データ搬出まで含むかで意味が異なります。

評価会議には、医療情報部門だけでなく、診療放射線技師、放射線科医、救急部門、事務、情報セキュリティ、経営企画を参加させます。候補を3社程度に絞ったら、同じ匿名化データと業務シナリオでデモ・PoCを行い、評価者ごとの点数とコメントを残します。デモの印象だけで決めず、未対応機能、追加費用、前提条件、納期、導入後の体制を比較表に記録します。

追加費用になりやすいのは、古いモダリティの接続、特殊なDICOMタグ、名寄せ・患者ID訂正、他院画像や非DICOMファイルの取り込み、過去レポート移行、想定を超える画像容量、AI・音声認識・遠隔読影の追加、端末や高精細モニター、夜間切替、教育の追加です。見積書では「一式」や「別途」を残さず、数量、単価、前提、除外範囲、変更時の単価を記載してもらいます。

納期リスクには、現場の承認遅れ、連携先ベンダーの調整、移行データの品質、回線工事、医療機器側の検証期間があります。対策として、意思決定者と承認期限を決め、データサンプルを早期に渡し、連携先を含む合同テストを設定します。契約前に、要件変更の手続き、遅延時の再計画、受入基準、瑕疵対応、保守開始日を明確にしておくと、金額と責任の境界が見えやすくなります。

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

PACS開発では、費用だけでなく、クラウドの安全性、導入期間、既存画像の移行、AIの扱いについて質問が多く寄せられます。ここでは、導入前に意思決定しやすいよう、結論を先に回答します。

どちらが一律に優れているわけではなく、診療継続、ネットワーク品質、拠点数、更新負担、予算で選びます。クラウドは初期投資やサーバー更新の負担を抑え、二拠点保管や施設間連携を組み込みやすい一方、回線障害、データ搬出、月額増加を確認する必要があります。オンプレミスは院内での高速参照や設備統制に向きますが、機器更新、バックアップ、災害対策を自院で管理します。直近画像を院内、長期保存をクラウドに置くハイブリッドも現実的な選択肢です。

すべて移行するかは、保存義務、参照頻度、容量、移行費用、旧システムの保守期限を比較して決めます。移行する場合は、患者・検査ID、画像枚数、容量、レポート、キー画像、PR・SRの対応を確認し、件数照合と重要症例のサンプル読影を行います。全件移行しない場合も、旧PACSを参照専用で残す期間、旧環境のバックアップ、必要画像を取り出す手順、契約終了時のデータ返却を決めておく必要があります。

小規模診療所や健診施設で標準機能を中心に導入する場合は1〜3か月、中小病院で複数連携と移行を行う場合は3〜9か月、中〜大規模病院でPACS・RIS・VNAや大量移行を含める場合は6〜18か月程度が目安です。フルスクラッチや複数施設の統合では12〜24か月以上になる可能性があります。これは一般的な想定レンジであり、要件確定、ベンダー調整、データ品質、テスト合格、切替時期によって変わります。

AIは病変候補の検出、トリアージ、計測、過去画像との比較などを支援できますが、導入すれば読影や診断が自動化されるわけではありません。診断・治療・予防を目的とする機能は、医療機器プログラムとして承認・認証の有無、対象画像、利用条件、解析結果の責任者を確認します。富士フイルムの医療クラウドサービスには、AI技術を活用した画像診断支援の導入事例がありますが、実際の効果は対象検査、読影フロー、教育、結果確認の手順で変わります（出典: 富士フイルム、確認時点2026年）。PoCでは、精度だけでなく、結果が届くタイミングと読影者の操作負担を測定します。

医用画像管理システム（PACS）開発のまとめ

医用画像管理システム（PACS）の進め方で最も重要なのは、製品を先に決めるのではなく、画像診療を止めない要件を先に決めることです。要件整理ではモダリティ、件数、容量、保存年数、連携先、例外運用を棚卸しし、選定では匿名化した実データと業務シナリオで比較します。設計・開発では患者ID、DICOM、連携、権限、監査ログ、責任分界を具体化し、テストでは移行画像、表示速度、障害復旧、現場の受入まで確認します。

発注前は、(1)MUST条件とWANT条件が分かれている、(2)既存モダリティ・HIS・RIS・レポート・AIの連携範囲が決まっている、(3)患者ID取り違え防止と監査証跡を検証できる、(4)移行対象と件数照合・サンプル読影の方法がある、(5)クラウド・オンプレミスの障害時手順がある、(6)初期・月額・移行・教育・保守・搬出費が分離されている、(7)受入基準と稼働判定者が決まっている、(8)契約終了時のデータ返却条件がある、という8項目を確認します。

次の一歩は、関係者を集めて現行PACSの構成図と画像データ量を確認し、MUST条件を10項目以内に絞ることです。その後、匿名化した代表画像と業務シナリオを用意し、複数社に同じRFPを渡します。PoC、移行テスト、受入テスト、教育、稼働後の評価指標までを一つの工程表に置くと、導入後に「使われない」「画像が探せない」「想定外の追加費用が出る」という事態を防ぎやすくなります。

費用レンジは、診療所・健診施設のクラウドやパッケージで初期0万〜300万円程度、中小病院で300万〜1,500万円程度、中〜大規模病院で1,000万〜5,000万円超という推定です。ただし、公開価格は個別条件で変わり、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を創業。