はじめに
序章
医師国家試験の過去問を解いていて、ふと疑問が湧いた。
「これ、どうやって作られてんねん?」問題の内容ではない。問題冊子そのものの話である。医師国家試験の問題冊子は、よく見ると結構きれいに作られている。問題番号や選択肢の位置は統一されているし、日本語と英数字が混在していても読みやすい。長い臨床問題や数式、さまざまな記号も一定のレイアウトに収まっている。さらに、画像を使う問題には専用の別冊まで用意されている。こういうものを見ると、いったい何のソフトウェアで作られているのか気になってくる。
Microsoft Word? LaTeX? それとも専用の組版ソフト?個人的には、LaTeXで組版されていたら面白そうだなと思っていた。そこで今回は、**第120回医師国家試験の公開PDF全13ファイルをGoogle ColabとPythonで解析し、その制作環境を調査してみた。**さらに、厚生労働省の政府調達情報まで調べてみると、問題冊子の印刷会社や、問題検索・編集システムの存在も分かってきた。最初は単にソフトウェアを知りたかっただけなのに、気づけば国家試験の制作工程そのものを追いかけることになった。
この記事では、その調査過程と結果を紹介する。
1. 調査対象
今回使用したのは、厚生労働省が公開している第120回医師国家試験のPDFである。解析対象は、問題冊子A〜F、画像別冊A〜F、正答一覧の合計13ファイル。
| 分類 | 内容 | PDF数 |
|---|---|---|
Q_text |
A〜F問題冊子 | 6 |
Q_image |
A〜F画像別冊 | 6 |
seitou |
正答一覧 | 1 |
| 合計 | 13 |
今回の解析では、**13件すべてのPDFを正常に処理できた。**なお、ここでいう正答一覧は、解説付きの模範解答ではなく厚生労働省が公開している正答PDFである。
ファイルの規模
まず、ファイルサイズを一覧にしてみた。
| ファイル | 分類 | サイズ(bytes) |
|---|---|---|
tp260424-01a_01.pdf |
A問題 | 1,046,558 |
tp260424-01b_01.pdf |
B問題 | 920,513 |
tp260424-01c_01.pdf |
C問題 | 1,002,241 |
tp260424-01d_01.pdf |
D問題 | 1,061,241 |
tp260424-01e_01.pdf |
E問題 | 921,073 |
tp260424-01f_01.pdf |
F問題 | 1,018,140 |
tp260424-01a_02.pdf |
A画像別冊 | 9,724,782 |
tp260424-01b_02.pdf |
B画像別冊 | 4,146,902 |
tp260424-01c_02.pdf |
C画像別冊 | 2,234,736 |
tp260424-01d_02.pdf |
D画像別冊 | 12,923,000 |
tp260424-01e_02.pdf |
E画像別冊 | 1,354,820 |
tp260424-01f_02.pdf |
F画像別冊 | 3,259,406 |
tp260424-01seitou.pdf |
正答一覧 | 21,543 |
問題冊子はどれもおおむね1MB前後。一方、画像別冊ではサイズにかなりの差がある。画像を多く含むPDFでは、画像の枚数や解像度、圧縮方式などが容量に影響すると考えられる。ただし、今回の調査では個々の画像の圧縮方式までは解析していない。
2. 解析環境を整える
今回はGoogle Colab上でPythonを実行した。主に使用したライブラリは以下のとおり。
| ライブラリ | 用途 |
|---|---|
| PyMuPDF | PDFメタデータ・フォント情報の取得 |
| pypdf | ページ内テキストの抽出 |
| pandas | 解析結果の集計・比較 |
| xml.etree.ElementTree | XMPメタデータの解析 |
Google Driveの構成
PDFはGoogle Driveに保存した。
MyDrive/
└── docs/
└── qitta/
├── data/
│ ├── Q_text/
│ ├── Q_image/
│ └── seitou/
└── output/
ColabからDriveをマウントする。
from google.colab import drive
from pathlib import Path
drive.mount("/content/drive")
BASE_DIR = Path(
"/content/drive/MyDrive/docs/qitta"
)
DATA_DIR = BASE_DIR / "data"
OUTPUT_DIR = BASE_DIR / "output"
OUTPUT_DIR.mkdir(parents=True, exist_ok=True)
続いて、data以下のPDFをすべて検索する。
pdf_files = sorted(DATA_DIR.rglob("*.pdf"))
print(f"検出したPDF: {len(pdf_files)} 件")
実行結果は13件。この構造なら、問題冊子だけでなく画像別冊や正答一覧も同じ解析パイプラインで処理できる。
3. まずはPDFのメタデータを覗いてみる
PDFには文書の内容以外にも、さまざまなメタデータが保存されている。例えば、作成ソフト、PDF生成エンジン、作成日時などだ。PyMuPDFを使うと、次のように確認できる。
import fitz
pdf_path = (
DATA_DIR / "Q_text" /
"tp260424-01a_01.pdf"
)
with fitz.open(pdf_path) as doc:
metadata = doc.metadata
for key, value in metadata.items():
print(f"{key}: {value}")
A問題の解析結果には、次の情報が含まれていた。
Creator:
Adobe InDesign 19.5 (Windows)
Producer:
Adobe PDF Library 17.0
**Adobe InDesignだった。**InDesignはAdobeが提供しているDTP(Desktop Publishing)ソフトウェアで、書籍や雑誌、パンフレットなどの組版・レイアウト制作に利用されている。LaTeXが使われているのではないかと予想していたが、少なくともPDFのメタデータにはInDesignの名前が記録されていた。ただし、PDFのCreator情報は後から変更できるため、これだけで結論を出すのは早い。ほかにも痕跡が残っていないか調べてみる。
4. まさかの「.indd」発見
PDFからテキストを抽出すると、興味深い文字列が見つかった。
DKIX01AH.indd 1 2025/12/17 15:58:30
DKIX01AH.indd 2 2025/12/17 15:58:30
.inddはAdobe InDesignのドキュメントファイルの拡張子である。つまり、元の編集ファイル名と考えられる情報がPDFに残っていた。B問題でも同様だった。
DKIX01BH.indd 1 2025/12/17 16:12:18
DKIX01BH.indd 2 2025/12/17 16:12:18
さらに13ファイルを横断して調べると、問題冊子だけでなく画像別冊にも.inddの文字列が存在した。
| 検出されたInDesignファイル名 | |
|---|---|
| A問題 | DKIX01AH.indd |
| B問題 | DKIX01BH.indd |
| C問題 | DKIX01CH.indd |
| D問題 | DKIX01DH.indd |
| E問題 | DKIX01EH.indd |
| F問題 | DKIX01FH.indd |
| A画像別冊 | A_inddcc2024.indd |
| B画像別冊 | B_inddcc2024.indd |
| C画像別冊 | C_inddcc2024.indd |
| D画像別冊 | D_inddcc2024.indd |
| E画像別冊 | E_inddcc2024.indd |
| F画像別冊 | F_inddcc2024.indd |
| 正答一覧 | 検出されず |
問題冊子ではDKIX01AH.inddのような命名規則、画像別冊ではA_inddcc2024.inddのような別の命名規則が使われていた。**問題冊子6件と画像別冊6件のすべてで、InDesign由来と考えられるファイル名が検出された。**なお、問題冊子の抽出ログには1DKIX01AH.inddのように先頭へ数字が付いた文字列も現れていた。これはPDFからテキストを抽出した際に、隣接する文字がつながって取得された可能性がある。そのため、ここでは代表的な.inddファイル名を掲載している。
5. XMPメタデータには制作履歴まで残っていた
PDFにはXMP(Extensible Metadata Platform)と呼ばれるメタデータが含まれる場合がある。これは制作履歴や文書識別子などを記録するために利用される仕組みだ。PyMuPDFでは次のように取得できる。
with fitz.open(pdf_path) as doc:
xmp = doc.get_xml_metadata()
print(xmp[:2000])
今回の問題冊子では、次のような変換履歴が確認できた。
from application/x-indesign
to application/pdf
これは、InDesignのデータからPDFに変換されたことを示す情報である。ここまでで、InDesignを示す証拠が3つそろった。
- CreatorがAdobe InDesign
- PDF内に
.inddのファイル名が残っている - XMPにInDesignからPDFへの変換履歴が記録されている
**少なくとも問題冊子の最終的な組版・PDF出力工程には、Adobe InDesignが使われていたと判断できそうだ。**ただし、元の問題文が最初からInDesignで作成されたとは限らない。原稿作成にはWordやLaTeXなどが使われ、その後InDesignへ取り込まれた可能性もある。
6. 13ファイル全部調べてみた
ここからが今回の調査の本題である。A問題だけではなく、問題冊子A〜F、画像別冊A〜F、正答一覧の13ファイルを一括解析した。
全13ファイルの比較結果
| 資料 | ページ数 | Creator | Producer | .indd |
フォント数 |
|---|---|---|---|---|---|
| A問題 | 68 | InDesign 19.5 | Adobe PDF Library 17.0 | あり | 7 |
| B問題 | 36 | InDesign 19.5 | 同上 | あり | 7 |
| C問題 | 48 | InDesign 19.5 | 同上 | あり | 7 |
| D問題 | 68 | InDesign 19.5 | 同上 | あり | 7 |
| E問題 | 40 | InDesign 19.5 | 同上 | あり | 7 |
| F問題 | 52 | InDesign 19.5 | 同上 | あり | 7 |
| A画像別冊 | 52 | 不明 | 不明 | あり | 3 |
| B画像別冊 | 20 | 不明 | 不明 | あり | 3 |
| C画像別冊 | 20 | InDesign 19.5 | Adobe PDF Library 17.0 | あり | 3 |
| D画像別冊 | 48 | 不明 | 不明 | あり | 3 |
| E画像別冊 | 16 | InDesign 19.5 | Adobe PDF Library 17.0 | あり | 3 |
| F画像別冊 | 20 | InDesign 19.5 | Adobe PDF Library 17.0 | あり | 3 |
| 正答一覧 | 2 | 不明 | JUST PDF 4 | なし | 1 |
※「不明」は、該当するメタデータを取得できなかったという意味である。
問題冊子A〜Fは制作環境が一致
問題冊子6件では、以下の情報が一致した。
| 項目 | 結果 |
|---|---|
| Creator | Adobe InDesign 19.5 (Windows) |
| Producer | Adobe PDF Library 17.0 |
| PDF規格 | PDF/X-1a:2001 |
| InDesign変換履歴 | 全6件で検出 |
.indd表記 |
全6件で検出 |
| 使用フォント数 | 7種類 |
| フォントの集合 | 完全一致 |
| OriginalDocumentID | 完全一致 |
PDF/X-1a:2001は、印刷向けのPDF規格の一つである。問題冊子A〜Fでは、ソフトウェアのバージョン、PDF生成エンジン、出力規格、使用フォントがすべて一致していた。つまり、共通の制作環境や設定を利用して組版された可能性が非常に高い。
画像別冊は少し事情が異なる
画像別冊A〜Fでも、すべてのファイルから.inddの文字列が検出された。しかし、CreatorとProducerを取得できたのはC・E・Fの3件だった。A・B・Dでは、該当するメタデータが取得できなかった。この違いは、PDFの保存方法や出力後の処理に由来する可能性があるが、今回の解析だけでは原因を特定できない。重要なのは、メタデータが取得できなかったことと、InDesignが使われていなかったことは同義ではないという点である。
正答一覧は別のPDF生成ソフトだった
個人的に特に面白かったのは正答一覧である。正答PDFのProducerには、次の情報が記録されていた。
JUST PDF 4
問題冊子とは異なるソフトウェアだ。しかも、正答PDFでは.inddの文字列も、InDesignからPDFへの変換履歴も検出されなかった。このことから、正答一覧は少なくとも問題冊子とは異なるPDF生成工程を経ている可能性が高い。ただし、ProducerがJUST PDF 4だからといって、原稿自体がJUST PDFで作成されたと断定することはできない。
7. PDFの作成日時から制作工程を考えてみる
問題冊子A〜F
| 問題冊子 | XMP作成日時 |
|---|---|
| A問題 | 2025/12/17 15:58:27 |
| B問題 | 2025/12/17 16:12:17 |
| C問題 | 2025/12/17 16:32:09 |
| D問題 | 2025/12/17 16:44:59 |
| E問題 | 2025/12/17 17:00:15 |
| F問題 | 2025/12/17 18:17:38 |
※すべて日本時間。なんと、**A〜FのPDFがすべて2025年12月17日に、アルファベット順で生成されていた。**しかも、CreatorはすべてInDesign 19.5、ProducerはAdobe PDF Library 17.0、PDF規格はPDF/X-1a:2001だった。これらの情報は、共通の制作環境で順番にPDFを書き出したという仮説と整合的だ。
画像別冊A〜F
一方、XMPの作成日時を取得できた画像別冊は以下のとおり。
| 画像別冊 | XMP作成日時 |
|---|---|
| A画像別冊 | 取得できず |
| B画像別冊 | 取得できず |
| C画像別冊 | 2025/11/04 14:53:53 |
| D画像別冊 | 取得できず |
| E画像別冊 | 2025/11/27 17:50:16 |
| F画像別冊 | 2025/11/04 15:31:24 |
確認できたC・E・F画像別冊は、いずれも問題冊子より前にPDF化されていた。また、正答一覧のXMP作成日時は以下だった。
2026-03-15T18:56:30+09:00
正答一覧は、問題冊子や画像別冊より後の日時になっている。つまり、13ファイルがすべて同じタイミングでPDF化されたわけではない。資料の種類ごとに異なる制作・出力工程が存在する可能性がある。ただし、これはあくまでPDFに記録された作成日時であり、問題の執筆開始日や編集完了日を意味するものではない。
8. フォントまで調べてみる

PDFの制作環境を調べるなら、フォントも気になる。PyMuPDFでは、各ページに登録されたフォントリソースを取得できる。
fonts = set()
with fitz.open(pdf_path) as doc:
for page in doc:
for font in page.get_fonts():
fonts.add(font[3])
for font in sorted(fonts):
print(font)
今回の13ファイルからは、抽出された名前として合計10種類の異なるフォント名が確認された。
資料ごとのフォント数
| 資料 | PDF数 | 各PDFのフォント数 |
|---|---|---|
| 問題冊子A〜F | 6 | 7種類 |
| 画像別冊A〜F | 6 | 3種類 |
| 正答一覧 | 1 | 1種類 |
問題冊子の6件ではフォント7種類が完全一致し、画像別冊の6件でもフォント3種類が完全一致していた。一方、全13ファイルに共通するフォント名は存在しなかった。
問題冊子A〜Fのフォント
問題冊子では、以下の7種類がすべて一致していた。
| フォント名 | 系統・特徴 |
|---|---|
RyuminPr6-Regular |
リュウミン系明朝体 |
RyuminPr6N-Reg |
リュウミン系明朝体 |
FutoGoB101Pr6-Bold |
太ゴシック系 |
KozMinPro-Medium |
小塚明朝 |
MS-Gothic |
MS ゴシック |
B2MathRegularRoman |
数式・記号系 |
B2MathRegularItalic |
数式・記号系イタリック |
日本語の文章だけでなく、数値、単位、ギリシャ文字、上付き・下付き文字なども登場する医師国家試験。そのため、明朝体やゴシック体に加えて、数式・記号系のフォントが存在するのは興味深い。ただし、フォント名を検出しただけでは、実際にどの文字で使われているのかまでは分からない。
画像別冊A〜Fのフォント
画像別冊では、次の3種類がすべて一致した。
| フォント名 | 系統 |
|---|---|
RyuminPro-Regular |
明朝体 |
FutoGoB101Pro-Bold |
太ゴシック体 |
MS-Gothic |
MS ゴシック |
問題冊子と画像別冊を比較すると、使用フォントの種類が少ないことが分かる。画像別冊では、画像の配置が中心となり、文字組みの用途が比較的限定されている可能性が考えられる。また、問題冊子と画像別冊では、同じリュウミン系や太ゴシック系でもフォント名が異なっている。例えば、
問題冊子:
RyuminPr6-Regular
画像別冊:
RyuminPro-Regular
のような違いが見られた。フォント名が完全に一致するかどうかと、見た目の書体が似ているかどうかは区別する必要がある。なお、問題冊子と画像別冊の双方で確認できた共通フォント名はMS-Gothicだった。
正答一覧のフォント
正答一覧では、1種類のフォント名が検出された。ただし、抽出された名称には文字化けが含まれていた。
lroSVbN
このため、今回の出力だけでは正確なフォント名を確定できなかった。PDFのフォント情報には文字コードの問題がある場合もある。また、今回の解析はフォント名の検出が中心であり、フォントデータの埋め込み状況や各文字への割り当てまで完全に検証したものではない。
9. OriginalDocumentIDまで一致していた
さらにXMPに含まれるOriginalDocumentIDを比較した。これは、Adobe系ドキュメントの元文書との関係を調べる際に手がかりとなる識別子である。
問題冊子A〜F
問題冊子6件では、すべて同じ値が検出された。
xmp.did:c9714a36-b734-d54f-b235-063d105fb635
画像別冊C・E・F
画像別冊C・E・Fでも、別の共通値が検出された。
adobe:docid:indd:d358c586-dc9a-11e0-8144-becc4032cff6
画像別冊A・B・Dと正答一覧では、OriginalDocumentIDを取得できなかった。つまり、13件すべてで同じOriginalDocumentIDが確認されたわけではない。
DocumentIDとの違い
問題冊子A〜FではOriginalDocumentIDが一致していた一方、DocumentIDはファイルごとに異なっていた。この違いは、共通の制作元に関係するドキュメントから、別々のPDFが書き出された可能性を考えるうえで興味深い。ただし、OriginalDocumentIDが一致することだけで、どのように元データが複製されたのか、誰が編集したのか、といった詳細まで特定することはできない。
10. ここまでの結論:LaTeXではなかったのか?
最初の疑問に戻る。**「医師国家試験の問題冊子はLaTeXで作られているのか?」**今回のPDF解析では、問題冊子A〜Fの最終的な組版・PDF出力にAdobe InDesignが使用されていたことを示す、複数の証拠が得られた。
- CreatorがAdobe InDesign 19.5
- ProducerがAdobe PDF Library 17.0
-
.inddの元ファイル名が残っている - XMPにInDesignからPDFへの変換履歴がある
- 使用フォント7種類が一致している
- OriginalDocumentIDが一致している
したがって、少なくとも第120回医師国家試験の問題冊子については、公開PDFの最終組版にはLaTeXではなくAdobe InDesignが使われていたと考えられる。ただし、元原稿の作成段階でWordやLaTeXなどが使われていた可能性は残る。今回特定できたのは、公開PDFに記録された制作・出力工程の情報である。

11. さらに気になったので、印刷会社まで調べてみた
ここまでで、問題冊子がInDesignで組版されていることは分かった。しかし、ここで新たな疑問が湧いてきた。**「で、実際に誰がこれを印刷してるん?」**気になったので、今度はPythonから少し離れて、厚生労働省の政府調達情報を調べてみることにした。
印刷・製本業務は共同印刷株式会社が受注していた
厚生労働省の調達情報を調べると、次の案件が見つかった。
医師ほか9職種国家試験問題用紙の印刷・製本並びに問題用紙等の包装、仕分け及び梱包業務
2025年7月14日に入札公告が行われ、同年9月4日に契約が締結されていた。そして、契約相手は共同印刷株式会社だった。
| 項目 | 内容 |
|---|---|
| 契約相手 | 共同印刷株式会社 |
| 契約日 | 2025年9月4日 |
| 契約方式 | 一般競争入札(最低価格) |
| 予定価格 | 130,350,000円 |
| 契約金額 | 120,208,000円 |
| 落札率 | 92.2% |
| 入札参加者数 | 1者 |
出典:厚生労働省 公共調達審査会審議対象一覧及び審議結果ここで注意したいのは、この金額が医師国家試験だけの費用ではないという点である。契約の対象には、医師国家試験のほかに9職種の国家試験が含まれている。また、契約件名は印刷・製本・包装・仕分け・梱包に関するものであり、共同印刷がInDesignでの組版まで担当したことを直接証明するものではない。
印刷会社が分かったことと、組版を担当した会社が分かったことは別である。
過去の契約も調べてみる
さらに年度をさかのぼって調べたところ、2020年から2025年まで、確認した各年度で共同印刷株式会社が関連する印刷・製本業務を受注していた。
| 契約年 | 契約相手 | 契約金額 |
|---|---|---|
| 2020年 | 共同印刷株式会社 | 82,467,000円 |
| 2021年 | 共同印刷株式会社 | 88,792,000円 |
| 2022年 | 共同印刷株式会社 | 99,748,000円 |
| 2023年 | 共同印刷株式会社 | 102,058,000円 |
| 2024年 | 共同印刷株式会社 | 119,768,000円 |
| 2025年 | 共同印刷株式会社 | 120,208,000円 |
少なくとも確認した6年間は、同じ企業が関連業務を継続して受注していたことになる。ただし、年度によって印刷部数、対象職種、用紙仕様、作業条件などが変わっている可能性がある。そのため、契約金額の増加だけを見て、印刷単価が上昇したと判断することはできない。また、2024年度・2025年度の資料には入札参加者数が1者だったことも記録されている。もっとも、参加者が1者だった理由までは分からない。参考:
12. そもそも問題を検索・編集する専用システムがあるらしい
印刷会社を調べていると、さらに興味深いものが見つかった。**「医師等国家試験問題検索・編集システム」**厚生労働省は、このシステムの機器更新や保守・運用支援についても調達を行っていた。
2024年の機器更新・移行
2024年10月21日、富士テレコム株式会社が次の案件を落札していた。
| 項目 | 内容 |
|---|---|
| 案件 | 医師等国家試験問題検索・編集システムの機器更新及び移行一式 |
| 落札者 | 富士テレコム株式会社 |
| 落札決定日 | 2024年10月21日 |
| 落札価格 | 107,580,000円 |
| 予定価格 | 118,684,940円 |
出典:厚生労働省 落札者等の公示この契約はシステムの機器更新と移行に関するものであり、富士テレコムが試験問題の執筆や組版を担当しているという意味ではない。それでも、国家試験問題を検索・編集するための専用システムが存在することは分かる。
2025年度の関連調達
2025年度には、さらに次のような関連案件が確認できた。
| 業務 | 契約相手 | 契約金額 |
|---|---|---|
| 問題検索・編集システムの保守・運用支援 | 富士テレコム | 14,256,000円 |
| ペーパーレス会議機能に関する機器購入 | 富士テレコム | 34,782,000円 |
| 問題用紙の印刷・製本・梱包 | 共同印刷 | 120,208,000円 |
| 問題等の発送・答案用紙等の回収 | ヤマト運輸 | 29,425,000円 |
ここで面白いのが、**「ペーパーレス会議機能」**という言葉だ。問題検索・編集システムに関連する会議用機器も調達されていた。ただし、具体的にどのような会議で、どのような手順で問題を確認・承認しているのかは、契約件名だけでは分からない。また、発送・回収が別契約になっていることも興味深い。試験問題の制作から受験会場への配送、答案用紙の回収まで、複数の業務が別々に調達されていることがうかがえる。なお、各契約の対象範囲は異なるため、これらの金額を合算して「医師国家試験1回の費用」とすることはできない。
2026年度もシステムの保守・改修が続いている
さらに調べると、2026年度に関係する保守・運用支援の調達に加え、2026年10月5日には次の案件が公告されていた。**「医師等国家試験問題検索・編集システム改修等一式」**公告に記載されていた主な日程は以下のとおり。
| 項目 | 日程 |
|---|---|
| 公告日 | 2026年10月5日 |
| 書類提出期限 | 2026年10月28日 14:00 |
| 開札予定 | 2026年11月5日 14:00 |
出典:政府調達ポータル 調達情報の詳細これを見ると、問題検索・編集システムは単発で導入されただけではなく、継続的な保守や更新の対象になっているようだ。ただし、公告されていることと契約相手が決まったことは別である。2026年10月時点では、この改修案件の落札結果までは確認できていない。
13. 仕様書を探してみたが、ここがまだ分からない
ここまで分かると、気になるのは次の点である。**「問題検索・編集システムのデータを、どうやってInDesignに渡しているんやろ?」**印刷・製本業務の入札公告では、詳細な作業内容は入札説明書や仕様書によるとされていた。また、問題検索・編集システムの更新についても、仕様書案に関する意見招請や、関連ソフトウェアの調達公告が確認できた。参考:
しかし、今回の調査では、組版ソフトの指定や原稿データの受け渡し形式を示す仕様書本文までは確認できなかった。2026年の改修案件では、政府調達ポータルから調達資料のダウンロード先まではたどれたものの、資料の取得前に連絡先情報の入力が必要だったため、本文の確認には至っていない。現時点で不明なことは、主に以下のとおり。
- 検索・編集システムの内部データ形式
- Word、XML、CSVなどの出力形式の有無
- InDesignとの連携方法
- 問題文・選択肢・画像の管理方法
- 校正や承認の具体的な手順
- InDesignでの組版を担当した組織・企業
- PDF/X-1a形式での出力を誰が実施したのか
ここは、今後仕様書を確認することでさらに解明できる可能性がある。
14. PDF解析と政府調達情報をつなげてみる
最後に、これまで調べた情報を一度整理してみる。
公開資料から見えてきた制作フロー
※これは公開PDFと政府調達記録を組み合わせて構成した概念図であり、実際の作業順序やファイル受け渡し経路が確認されたわけではない。
確認できた事実と、まだ推測の部分
| 項目 | 状況 |
|---|---|
| 問題冊子A〜Fの最終PDF制作にInDesignが使われた | 複数のPDF内部情報で裏付け |
| 問題冊子A〜Fのフォント構成が一致 | 解析結果で確認 |
| 問題冊子A〜FのOriginalDocumentIDが一致 | XMPで確認 |
画像別冊A〜Fに.inddが残る |
抽出結果で確認 |
| 正答PDFのProducerがJUST PDF 4 | メタデータで確認 |
| 2025年度の印刷・製本等の契約先が共同印刷 | 政府調達記録で確認 |
| 問題検索・編集システムが存在する | 調達記録で確認 |
| システムからInDesignへ直接データ連携している | 未確認 |
| 共同印刷がInDesignで組版した | 未確認 |
| 初期原稿にWordやLaTeXが使われていたか | 未確認 |
この区別は非常に重要だと思う。PDFから分かることと、契約情報から分かることはそれぞれ異なる。両者を組み合わせることで制作工程を考察できる一方、つながりが確認されていない部分を断定してはいけない。
同じ会社が継続受注していることと、PDFの統一性は関係する?
2020〜2025年の印刷・製本等の契約では、確認した各年度で共同印刷が受注していた。一方、今回解析した第120回医師国家試験の問題冊子A〜Fでは、使用ソフト、PDF/X規格、フォント、OriginalDocumentIDがそろっていた。一見すると、継続的な印刷業務が標準化された組版環境につながっているようにも思える。しかし、ここは慎重に考える必要がある。印刷・製本業務の契約先が同じであることは、その会社が組版工程を担当している証拠にはならない。
今回確認できたのは、あくまで印刷関連の契約履歴と、完成PDFの内部情報である。この2つがどのようにつながっているかについては、仕様書などの追加資料が必要だ。
15. まとめ
今回は、医師国家試験の問題冊子が何のソフトで作られているのか気になり、第120回医師国家試験のPDF13ファイルをPythonで解析してみた。さらに政府調達情報を調べ、印刷・製本業務や問題検索・編集システムの存在についても確認した。結果を整理すると、以下のようになった。
| 調査対象 | 分かったこと |
|---|---|
| 問題冊子A〜F | InDesign 19.5で最終組版・PDF生成 |
| 問題冊子のフォント | 7種類が完全一致 |
| 画像別冊A〜F | 全件に.inddの痕跡、フォント3種類が一致 |
| 正答一覧 | JUST PDF 4でPDF生成 |
| OriginalDocumentID | 問題冊子A〜Fで一致 |
| PDF作成日時 | 問題冊子A〜Fは2025年12月17日に順番に生成 |
| 印刷・製本等の契約 | 2025年度は共同印刷株式会社 |
| 過去の印刷関連契約 | 確認した2020〜2025年は共同印刷が受注 |
| 問題検索・編集システム | 専用システムの存在と継続的な関連調達を確認 |
| 印刷後の輸送 | 発送・回収も別途調達されている |
| InDesignと編集システムの連携 | 依然として不明 |
**結論として、第120回医師国家試験の問題冊子は、少なくとも最終的にはAdobe InDesignで組版されていた。**そして、その裏側には問題の検索・編集システム、印刷・製本、発送・回収といった複数の業務が存在していることも分かった。普段何気なく開いているPDFだが、内部には作成ソフト、フォント、元ファイル名、変換履歴、文書識別子など、さまざまな情報が残されている。さらに政府の契約記録を組み合わせれば、そこから実際の印刷会社や関連システムの存在まで調べることができる。最初は、
**「これ、どうやって作られてんねん?」**という小さな疑問だった。それが、PDFのメタデータ解析から始まり、Adobe InDesign、XMP、フォント、政府調達、印刷会社、国家試験の問題検索・編集システムへとつながっていった。まだ分かっていないことも多い。特に、編集システムからInDesignへのデータ受け渡し方法や、実際に誰が組版作業を行っているのかについては、今後も調べてみたい。また、過去の医師国家試験にも解析対象を広げ、年代によって組版環境や使用フォントが変化しているのかも気になる。
PDF、思っていた以上にいろいろ教えてくれる。
参考資料
医師国家試験PDF・解析ライブラリ
印刷・製本関連の政府調達
問題検索・編集システム関連
解析データ
今回の解析ではGoogle Colabを使用し、13ファイルを一括処理して、以下のCSVとMarkdownレポートを生成した。
| ファイル | 内容 |
|---|---|
pdf_analysis.csv |
PDFの詳細メタデータ |
all_files_comparison.csv |
13ファイルの制作環境比較 |
font_list.csv |
PDF別フォント一覧 |
font_presence.csv |
フォントの出現状況 |
agreement_summary.csv |
一致・不一致の集計 |
ab_comparison.csv |
A・B問題の詳細比較 |
analysis_report.md |
自動生成された解析レポート |
記事に掲載した制作ソフト、PDF作成日時、フォント名、OriginalDocumentIDなどは、これらの解析結果に基づく。





