--- title: "DICOMとは？タグ構造・DIMSE通信とDICOMweb・PACS連携の落とし穴を実装者目線で解説【2026年8月時点】" url: "https://www.issoh.co.jp/tech/details/16828/" published: 2026-08-23 updated: 2026-08-23 categories: ["プロトコル"] publisher: "株式会社一創" --- # DICOMとは？タグ構造・DIMSE通信とDICOMweb・PACS連携の落とし穴を実装者目線で解説【2026年8月時点】 DICOM（Digital Imaging and Communications in Medicine）は、CTやMRIが吐き出す画像の「ファイル形式」と、装置とサーバの間で画像をやり取りする「通信手順」を、1つの規格にまとめて定義したものです。画像フォーマットの話だと思って読み始めると途中からネットワークプロトコルの仕様書に変わるため、構造を掴まないまま実装に入ると迷います。この記事では、タグとVRで組み立てるデータ要素、UID階層、転送構文、C-STOREやC-MOVEといったDIMSE通信サービス、HTTPベースのDICOMwebまでを、受託開発でPACS連携を組む立場から整理しました。日本語氏名の文字化けや匿名化の抜けなど、実装で踏み抜きやすい箇所も扱います。 ## まとめ：DICOMの二層構造と2026年時点でDIMSEとDICOMwebを選び分ける結論 DICOMの正体は二層です。第一層が画像とメタ情報を1つのファイルに詰める「データ形式」、第二層が装置間でそれを送受信する「通信サービス」。後者はTCP上の独自プロトコル（DIMSE）と、HTTP上のREST（DICOMweb）の2系統に分かれます。この二層を混同したまま設計に入ると、「ファイルは読めるのに装置から受信できない」という詰まり方をします。 連携方式の結論を先に示します。院内のモダリティやPACSと直接つなぐ経路は装置側がDIMSEしか話せないことが多く、C-STOREとC-FINDに対応したゲートウェイを置くのが現実解です。一方、クラウド保管・Webビューア・AI推論への引き渡しは、PS3.18のDICOMweb（QIDO-RS／WADO-RS／STOW-RS）へ寄せると認証・監査・スケールをWeb APIの流儀で設計できます。既存装置はDIMSE、新規面はDICOMweb、その境目にゲートウェイ。これが2026年8月時点で最も無理のない切り分けになります。 ## DICOMが定める画像形式と通信手順の二層構造および規格全22パートの読み方 どのパートに何が書いてあるかを知らないまま全文を追うと時間を失います。適用範囲と版の考え方から押さえましょう。 ### 医用画像の形式と通信を1つの規格で束ねたDICOMの成り立ちと適用範囲 DICOMは、米国放射線学会（ACR）と米国電機工業会（NEMA）が1980年代に策定したACR-NEMA規格を出発点とし、1993年のバージョン3.0で現在の名称と構造になりました。国際規格としてはISO 12052に対応します。対象は画像だけではありません。患者・検査・シリーズのメタ情報、読影レポートに相当する構造化レポート、被ばく線量記録、放射線治療のプランや線量分布まで同じデータモデルに載ります。会計・オーダ・処方などの文字情報は守備範囲外で、そちらはHL7系の規約が担当します。 ### PS3.1からPS3.22までのパート構成と年複数回という改訂サイクルの把握 規格はPS3.1からPS3.22までのパートに分かれ、PS3.9とPS3.13は廃止済みです。実装で開くのはおおむね5つ。データ要素の符号化はPS3.5、データ辞書はPS3.6、メッセージ交換はPS3.7、ネットワーク層はPS3.8、WebサービスはPS3.18に置かれています。仕様書は年に複数回改訂され、2026年8月時点の現行版は2026c版でした。版が固定された紙の規格ではないため、実装時はcurrentの版で条項を確認し、社内の設計書にも参照した版を書き残してください。 ### 厚生労働省標準規格HS011としての位置づけと国内の周辺規格との関係 日本国内では厚生労働省標準規格HS011「医療におけるデジタル画像と通信（DICOM）」として採択され、周辺の規格とセットで要件が降りてきます。可搬媒体での画像受け渡しを定めたHS009（IHE統合プロファイル「可搬型医用画像」）、放射線データ交換のHS016、HIS・RIS・PACS間の予約や照射録の連携指針であるHS017、被ばく線量管理のHS035が代表格です。要件定義に「DICOM対応」とだけ書かれていても、実際にはHS017のオーダ連携やHS009のCD/DVD出力まで含むことがあります。範囲は見積もり前に切り分けておきましょう。 ## タグとVRで構成するデータ要素の内部構造とUID階層の設計上の注意点 DICOMファイルは、ヘッダと画素データが前後しているのではなく、同じ形の要素が延々と並ぶ構造です。規則が分かれば、パーサの挙動もライブラリのAPIも読み解けます。 ### ファイルメタ情報から本体へ至る格納順序とプライベートタグの扱い方 先頭には128バイトの空きがあり、続いて「DICM」の4文字が置かれます。その直後がファイルメタ情報で、グループ番号0002の要素だけが集まった領域。ここは版に関わらず明示VRのリトルエンディアンで符号化され、(0002,0010)のTransferSyntaxUIDが本体の読み方を宣言します。本体は、タグ・VR（値表現を示す2文字）・値長・値というデータ要素がタグの昇順に並んだ列です。患者氏名は(0010,0010)でVRはPN、画素は(7FE0,0010)です。グループ番号が奇数のタグはメーカー独自のプライベートタグで、(gggg,0010)などのプライベートクリエータ文字列と併せて読まなければ意味が決まりません。 ### 検査から画像までを一意に結ぶUID階層とSOPクラスUIDの対応関係 情報モデルは、患者・Study（検査）・Series（シリーズ）・Instance（画像1枚）の4階層です。StudyInstanceUIDは(0020,000D)、SeriesInstanceUIDは(0020,000E)、SOPInstanceUIDは(0008,0018)に入り、いずれも数字とドットだけの最大64文字になります。発番は組織が取得したルートOIDの配下で行い、世界中で重複しないことが前提。画像の種類はSOPクラスUIDで表され、CT画像は1.2.840.10008.5.1.4.1.1.2、MR画像は1.2.840.10008.5.1.4.1.1.4、二次取り込みは1.2.840.10008.5.1.4.1.1.7です。受け入れ可能なSOPクラスは装置のコンフォーマンスステートメントに明記されているため、設計の初期に入手してください。 ## 転送構文の選択で決まる圧縮方式と受け入れ側との互換性を守る判断基準 転送構文は、バイト順・VRの明示有無・画素の圧縮方式をまとめて指定するUIDです。連携が失敗する原因の多くが、この1行の不一致に集約されます。 ### 主要な転送構文UIDと非圧縮・可逆・非可逆の対応関係の早見表 PS3.6の登録簿から、実装で遭遇する頻度が高いものを抜き出しました。最初の疎通は、どの装置も受け付ける暗黙VRリトルエンディアンで取るのが定石です。 | 転送構文 | UID | 画素の扱い | | ----------------- | ----------------------- | -------- | | 暗黙VR リトルエンディアン | 1.2.840.10008.1.2 | 非圧縮・既定 | | 明示VR リトルエンディアン | 1.2.840.10008.1.2.1 | 非圧縮 | | RLE Lossless | 1.2.840.10008.1.2.5 | 可逆 | | JPEG Baseline | 1.2.840.10008.1.2.4.50 | 非可逆・8ビット | | JPEG Lossless SV1 | 1.2.840.10008.1.2.4.70 | 可逆 | | JPEG 2000 可逆のみ | 1.2.840.10008.1.2.4.90 | 可逆 | | JPEG 2000 | 1.2.840.10008.1.2.4.91 | 可逆・非可逆 | | HTJ2K 可逆のみ | 1.2.840.10008.1.2.4.201 | 可逆・高速復号 | | HTJ2K | 1.2.840.10008.1.2.4.203 | 可逆・非可逆 | 明示VRビッグエンディアン（1.2.840.10008.1.2.2）は廃止扱いですが、古い装置から届くことがあります。受信側ライブラリの対応可否は実機テスト前に確認しておきましょう。 ### HTJ2Kを含む圧縮方式の採用条件と診断用途で非可逆を避ける線引き 圧縮方式は「保管費用」ではなく「読影に耐えるか」で決めます。可逆圧縮は画素値が完全に復元でき、CT・MRでおおむね元の1/2から1/3程度に収まるため、診断用の一次保管はここから外さないのが安全です。非可逆のJPEG Baselineは12ビット階調のCT原画には向かず、参照用の派生画像やWeb表示に用途を限ります。2022年に追加されたHTJ2K系（.201から.203）はJPEG 2000と同じ画質特性のまま復号を大きく速められ、Webビューアのタイル配信と相性が良い方式です。ただし受信側が未対応なら1バイトも受け取れません。非可逆を診断目的で許容するかは施設の運用規程と学会指針に従う判断で、要件定義で明文化してもらいます。 ### プレゼンテーションコンテキスト拒否で送信が失敗する典型の切り分け 接続交渉では、送信側が「このSOPクラスを、この転送構文の候補で送りたい」という組（プレゼンテーションコンテキスト）を提示し、受信側が採用する転送構文を1つ選びます。候補が噛み合わなければそのコンテキストは拒否され、接続は張れているのに画像だけが通りません。多いのは、装置がJPEG 2000のみで送る設定なのに受信側が非圧縮しか受けない構成、受け入れSOPクラスをCTとMRに絞っていて二次取り込み画像が弾かれる構成です。切り分けは、まずC-ECHO（Verification SOPクラス、1.2.840.10008.1.1）で疎通を確認し、次に交渉ログの拒否理由コードを読む順序が早道になります。 ## C-STOREからC-MOVEまでのDIMSE通信サービスとアソシエーション設計の実務 DIMSEは、TCP接続の上でDICOM独自のメッセージをやり取りする層。HTTPに慣れた実装者ほど接続の張り方でつまずきます。 ### AEタイトルとポート104および11112を決めるネットワーク設計の要点 DICOMのノードはAEタイトル（最大16文字）で識別され、IPアドレスとポートの組と併せて相手先を特定します。PS3.8は、単一のDICOMエンティティを持つシステムにウェルノウンポートの104番を強く推奨し、特権ポートを使えない環境向けに登録済みの11112番を挙げています。勘所は、AEタイトルを装置ごとに一意にして台帳化すること。受信側は登録済みAEタイトルからの接続だけを許可する構成が一般的なため、開発機と本番機で同じAEタイトルを使い回すと、検証中の画像が本番PACSへ流れ込みます。 ### C-FINDの問い合わせ階層とC-MOVEが折り返し接続を必要とする構造 主要サービスは、疎通確認のC-ECHO、画像を送るC-STORE、条件検索のC-FIND、転送指示のC-MOVE、同一接続で受け取るC-GETの5つです。C-FINDはStudy Root（1.2.840.10008.5.1.4.1.2.2.1）などの情報モデルを指定し、患者ID・検査日・モダリティといったキーを空欄で送って値を返してもらいます。厄介なのはC-MOVE（1.2.840.10008.5.1.4.1.2.2.2）。要求元は宛先AEタイトルを指示するだけで、実際の画像はPACS側が別のアソシエーションを張って送信先へC-STOREします。つまりPACSから要求元への逆方向接続が発生し、NAT配下やクラウド側からの取得では届きません。同一接続内で返すC-GETは回避策になりますが、対応装置は多くないのが実情です。 ### モダリティワークリストとMPPS・ストレージコミットメントの役割分担 画像を送る前後にも標準化された手続きがあります。モダリティワークリスト（1.2.840.10008.5.1.4.31）は、検査オーダの一覧をC-FINDで装置に取りに行かせ、患者IDや氏名の手入力を排除する仕組みです。取り違え防止の効果が大きく、国内案件では実質的な必須要件になります。検査の開始と終了はMPPS（1.2.840.10008.3.1.2.3.3）のN-CREATEとN-SETで通知。保管責任の移管を扱うのがストレージコミットメント（1.2.840.10008.1.20.1）。送信側は保管完了の応答を受け取ってから装置内の画像を削除します。この応答は非同期で返ることがあり、待ち受け側の実装を忘れると削除できない画像が装置に溜まり続けてしまうのです。オーダの発生源となるシステムの全体像は、[電子カルテの種類と選び方を整理した記事](https://www.issoh.co.jp/column/details/15243/)で確認できます。 ## QIDO-RSとWADO-RSで組むDICOMwebとDIMSEの使い分けの設計指針 PS3.18は、同じ情報モデルをHTTPの上に載せ直したWebサービス群を定義しています。DIMSEを置き換えるものではなく、外向きの面を作るための選択肢です。 ### 3つのWebサービスが担う照会・取得・保存のURI階層とメディア型 DICOMwebのStudies Serviceは、studies、series、instances、framesという階層のURIでリソースを表します。照会にあたるQIDO-RSはGETで条件を渡し、application/dicom+json を返す仕組みです。取得のWADO-RSもGETで、multipart/related にapplication/dicomの本体を入れて返すほか、メタ情報だけのJSON、レンダリング済みのJPEGやPNG、フレーム単位の部分取得にも対応します。保存のSTOW-RSはPOSTでファイルを送る役割、ワークリストはUPS-RSが担当。認可はOAuth 2.0、監査はアクセスログと、Web APIの設計資産をそのまま持ち込めます。REST設計の考え方は[REST APIとGraphQLの違いを整理した記事](https://www.issoh.co.jp/tech/details/3591/)が参考になります。 ### DIMSEとDICOMwebを比較して連携方式を決めるための判断観点 両者は排他ではなく、経路ごとに選びます。判断軸は次の4点に集約されます。 | 観点 | DIMSE | DICOMweb | | ------- | ---------- | ----------- | | 下位プロトコル | TCP上の独自手順 | HTTPS上のREST | | 装置側の対応 | ほぼ全機種 | 新しめの製品が中心 | | NAT越え | C-MOVEで逆接続 | クライアント発信で完結 | | 認証と監査 | AEタイトル管理が主 | トークンとログで統一 | 装置から画像を集める内向きの経路はDIMSE、集めた画像を配る外向きの経路はDICOMweb。この原則で線を引くと、責務の切れ目がネットワーク境界と一致します。 ### クラウド保管とAI推論連携でDICOMwebを選ぶ条件とゲートウェイ構成 クラウド側に画像を置く構成では、院内からの送信をDIMSEで受け、オブジェクトストレージへ格納し、外部へはDICOMwebで見せる三段構えが扱いやすくなります。院内のゲートウェイがC-STORE SCPとして画像を受け取り、非同期にSTOW-RSでクラウドへ転送する形です。AI推論に渡す場合も、推論側にDIMSEを話させるよりWADO-RSでフレーム単位に取得させるほうが軽くなります。条件は2つ。院内から外向きのHTTPS通信が許可されていること、画像の外部保管について施設の規程上の手当てが済んでいることです。どちらかが欠けるなら院内完結のDIMSE構成に留めます。連携基盤の設計・実装は[API開発・システム連携の受託](https://www.issoh.co.jp/service/system/api/)として相談を受けている領域です。 ## PACS連携の実装で踏み抜きやすい文字コード・匿名化・容量設計の落とし穴 ここからは、仕様書を読んだだけでは避けにくい実務の穴を4つ挙げます。いずれも結合テストの終盤で発覚すると手戻りが大きい箇所です。 ### 日本語氏名を壊さない文字集合指定と3コンポーネント表記の扱い 患者氏名が化ける原因は、(0008,0005)のSpecificCharacterSetの解釈漏れです。国内の装置では、漢字にISO 2022 IR 87、半角カナにISO 2022 IR 13を組み合わせたエスケープシーケンス方式が現役で、UTF-8を示すISO\_IR 192に対応していない機器も残っています。さらにPN型の値は「英数字表記＝表意文字表記＝表音文字表記」の3成分をイコール記号で区切り、姓と名はキャレットで分ける構造。単純な文字列として1カラムに入れると、フリガナ検索も姓名の分割も後から作り直しです。取り込み側のデータモデルは、3成分を分けて保持する前提で設計してください。 ### 患者IDとUIDの重複・再発番が引き起こす検査分散と突合の破綻 同じ患者が外来・健診・救急で別々のIDを持つ施設は珍しくありません。DICOM側は(0010,0020)のPatientIDを素直に信じるため、IDが分かれていれば過去画像は別人として並びます。統合するなら、施設のマスタ側で名寄せした結果をゲートウェイで書き換えるのか、参照時に突合するのかを先に決めておきましょう。UIDにも同じ注意が要ります。匿名化や再送のたびにUIDを新規発番する実装では、同じ画像が別インスタンスとして重複保管され、原本との対応が追えません。画像部門システム全体の構成と導入判断は、[PACSの仕組みと導入判断をまとめた記事](https://www.issoh.co.jp/column/details/16201/)で整理しています。 ### 焼き込み文字とプライベートタグが残る匿名化の抜け道と検証手順 研究用途やAI学習でデータを外部に出すとき、タグの削除だけでは個人情報は消えません。PS3.15の付属書Eが定める秘匿プロファイルは削除・置換の対象タグを網羅していますが、抜けるのは2箇所。1つは画素に文字が焼き込まれた画像で、(0028,0301)のBurnedInAnnotationがYESの超音波や透視画像が該当します。もう1つがメーカーのプライベートタグで、機種によっては氏名や検査コメントが入ります。検証は、匿名化後のファイルを全タグ走査して残存文字列を洗い、サンプル画像を目視確認する二段構えにしてください。 ### 転送量と保管容量から逆算する回線帯域とバッチ設計の見積もり方 容量設計を後回しにすると、稼働後の増設で慌てます。CTの1検査は薄いスライスを含めると数百MB規模、病理のホールスライド画像はGB規模です。回線側は、1検査を院外へ送り切る所要時間で判断しましょう。500MBの検査を実効50Mbpsで送れば単純計算で約80秒かかり、これが連続すると日中帯の帯域を食います。夜間バッチへ寄せるか、可逆圧縮で転送量を落とすかを要件定義の段階で決めておきます。 ## DICOM対応を自前実装せず既存ライブラリと製品へ寄せる条件と見送る場面 最後に判断です。DICOM対応と聞いて、パーサから書き起こす前提で見積もる必要はほとんどありません。 ### dcm4cheやOrthancなど既存実装を採る条件と自前実装が残る範囲 DIMSEのスタックはゼロから書かないのが原則です。Javaならdcm4che、C++ならDCMTK、Pythonならpydicomとpynetdicom、.NETならfo-dicomが実績のある選択肢で、軽量なサーバとして立てるならOrthancがDICOMwebとRESTの両方を備えています。自前で書く価値が残るのは業務ロジック側だけ。AEタイトルと施設マスタの対応管理、患者IDの名寄せ規則、匿名化ポリシーの適用、転送のリトライと監査ログです。逆に、タグのパースや接続交渉を自作すると、装置ごとの方言に延々と対応し続けることになります。 ### 診断用途のビューア開発を通常の受託案件として見送るべき判断基準 判断を言い切ります。診断や治療方針の決定に用いる画像表示・画像処理の機能を、一般的な業務システム開発の枠組みで受託するのは見送るべきです。医療機器プログラムに該当する場合、薬機法上の承認・認証や製造販売業の体制が前提となり、品質管理体制も通常の開発とは別物になります。該当性は機能と用途で変わるため、企画段階で規制に詳しい専門家と発注元の薬事担当を交えた確認工程を必ず挟みましょう。受託側が引き受けられるのは、参考表示に限定した院内向けの閲覧機能、あるいは画像の保管・転送・変換といった診断判断に踏み込まない基盤部分まで。制度側の全体像は[医療DXの現在地をまとめた記事](https://www.issoh.co.jp/column/details/13779/)で確認できます。 ## DICOMの実装検討でよく挙がる質問と受託開発の現場からの実務的な回答 要件定義や見積もりの場で繰り返し聞かれる論点を5つ挙げ、判断できる粒度で答えます。 ### DICOMファイルの拡張子は必ず .dcm ですか？ いいえ、拡張子は規格上の必須要件ではありません。判定は先頭128バイトの後に続く「DICM」の4文字で行うのが確実です。可搬媒体で受け渡す場合はIHEの可搬型医用画像プロファイルに従って拡張子なしのファイル名が使われることもあり、ルートのDICOMDIRファイルが目次の役割を果たします。取り込み処理は先頭バイト列で判定するように実装してください。 ### DICOMとHL7 FHIRはどう使い分けますか？ 扱う対象が違います。画像と画像に付随するメタ情報はDICOM、患者基本情報・オーダ・検査結果・処方といった文字情報はHL7系の担当です。国内では処方情報や診療情報提供書のFHIR記述仕様が厚生労働省標準規格として並び、画像はHS011のDICOMが受け持ちます。両者をつなぐ場合、FHIRのImagingStudyリソースからStudyInstanceUIDを参照し、実体はWADO-RSで取りに行く構成が一般的です。 ### PACSがなくてもDICOM画像を扱えますか？ 技術的には可能です。ファイル自体はライブラリで読めますし、Orthancのような軽量サーバを立てれば、C-STOREの受信とDICOMwebの公開までは小規模構成で成立します。ただし長期保管の可用性、監査ログ、電子カルテとのオーダ連携、被ばく線量管理まで求められるなら、PACSが担ってきた機能を自前で作り直すことになります。自作範囲は検査件数と保管要件で判断してください。 ### C-MOVEが失敗するときは何を確認すればよいですか？ 確認は3点です。まず送信先AEタイトルがPACS側に登録されているか。C-MOVEはPACSが登録済みのAE情報を元に接続するため、未登録なら要求は受理されても転送が始まりません。次に、PACSから要求元へ向かう方向のファイアウォールが開いているか。最後に、要求元がC-STORE SCPとして待ち受けているかどうかです。解決しない場合は転送構文の不一致を疑います。 ### DICOM画像を機械学習の学習データに使う際の注意点は何ですか？ 3つあります。第一に匿名化で、タグ削除に加えて焼き込み文字とプライベートタグの残存を検証します。第二に、非可逆圧縮された画像を混ぜると圧縮由来の劣化を特徴として学ぶ恐れがあるため、可逆または非圧縮の原本を使う設計に。第三に、施設をまたぐデータでは撮影条件や再構成カーネルの差が大きく、装置ごとのメタ情報を管理項目として保持する必要があります。二次利用の同意と倫理審査の状況も着手前に確認してください。 ## 関連記事 - [PACSとは？仕組み・電子カルテ連携・容量設計から導入判断まで解説【2026年版】](https://www.issoh.co.jp/column/details/16201/)：本記事の規格を運用する画像部門システムの全体像と導入判断。 - [電子カルテとは？種類・メリットと失敗しない選び方・開発判断を解説【2026年】](https://www.issoh.co.jp/column/details/15243/)：モダリティワークリストの元になる検査オーダの発生源。 - [医療DXとは？定義・3本柱・2026年度改定から進め方と受託開発の判断まで解説](https://www.issoh.co.jp/column/details/13779/)：標準規格の採択や情報連携の制度的な背景。 - [REST APIとGraphQLの違いと使い分け｜選定基準と運用コスト](https://www.issoh.co.jp/tech/details/3591/)：DICOMwebの上に業務向けAPIを重ねる際の設計判断。 - [API開発・システム連携（株式会社一創）](https://www.issoh.co.jp/service/system/api/)：PACSやモダリティと基幹システムをつなぐ連携基盤の設計・開発。 --- 出典: [DICOMとは？タグ構造・DIMSE通信とDICOMweb・PACS連携の落とし穴を実装者目線で解説【2026年8月時点】]()（株式会社一創）