メタデータとは？意味・例・削除方法｜写真・PDF・DBの中身を実物で

メタデータは、本体の「中」に埋め込まれるものと、本体の「外」で管理されるものに分けると整理しやすくなります。写真の EXIF や Word の作成者名は前者、ファイルの更新日時や Web サーバーが返すヘッダー、データベースの列の定義は後者です。

flowchart TD
    F[ファイル・データ] --> B[本体<br>画素・本文]
    F --> M[メタデータ<br>本体の説明]
    M --> I[中に埋め込む<br>EXIF・docProps]
    M --> O[外で管理<br>stat・HTTP・DB]

よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.5 LTS（カーネル 6.18）の上で、自分で作った JPEG（640×480）に ExifTool 12.76（Ubuntu の .deb を作業用フォルダーに展開して実行）でダミーの撮影情報と位置情報（北緯35.123456度・東経139.654321度。実在の撮影地ではない自作の値）を書き込み、ExifTool・Pillow 12.3.0・ImageMagick 6.9.12-98 で読み出しと削除をしました。Office ファイルは python-docx 1.2.0 で作った .docx を unzip で開いて中身を確かめ、LibreOffice 24.2.7.2 で PDF に変換して pdfinfo（poppler 24.02.0）・qpdf 11.9.0 で調べています。ファイルのメタデータは GNU coreutils 9.4 の stat、Web は Python 3.13.18 の http.server を 127.0.0.1 で起動して curl 8.5.0 で、データベースは作業用に起動した PostgreSQL 16.15 と SQLite 3.53.1 で、音楽ファイルは ffmpeg 6.1.1 と ffprobe、コミットの情報は git 2.43.0 で確かめました。iPhone・Android・Microsoft Office の画面操作は手元で動かせないため、Apple・Google・Microsoft の公式ヘルプで確かめた範囲だけを書いています。外部のサービスには何も送信していません。図は mermaid で描画を確かめています（確認日 2026年10月29日）。

メタデータとは（データについてのデータ）

この節では、メタデータの意味と、本体のデータとの関係が分かります。

メタデータとは、あるデータ（本体）について、その属性や関連する情報を記したデータです。「メタ」は「〜についての」「一段上の」という意味の接頭語で、英語の metadata も「data about data（データについてのデータ）」と説明されます。

図書館の本で考えると分かりやすくなります。本の中身（本文）が本体のデータで、書名・著者・出版社・出版年・分類番号・棚の場所を書いた目録カードがメタデータです。目録カードがあるから、本文を1冊ずつ読まなくても「2020年以降に出た、ある著者の本」を探せます。

メタデータがあると何ができるか

• 探す：撮影日・作成者・タグで絞り込む。パソコンのファイル検索、写真アプリの「場所」での表示、図書館の蔵書検索はメタデータを使っています。
• 正しく扱う：文字コード・ファイルの種類（MIME タイプ）・画像の向きを知って、正しく表示する。
• 管理する：誰がいつ作り、いつ更新したか、誰が読めるか（権限）を記録する。
• つなぐ：システム間でデータを渡すとき、列の意味や型を伝える。データカタログ（社内のデータの目録）もメタデータの集まりです。

注意点：本人が気づかずに渡ってしまう

メタデータは多くの場合、カメラやアプリが自動で書き込みます。本体は見えても、メタデータは画面に出ないことが多いため、写真をそのまま渡すと撮影場所が、文書をそのまま渡すと作成者名や社内向けのコメントが、相手に伝わることがあります。このあと各節で、実際に書き込んで読み出し、消すところまでを見ていきます。

メタデータの種類と例（記述・構造・管理）

この節では、メタデータの分け方と、身近な例が一覧で分かります。

米国の情報標準化機構 NISO の入門書『Understanding Metadata』は、メタデータを大きく「記述（Descriptive）」「構造（Structural）」「管理（Administrative）」の3つに分けています。記述メタデータは見つける・見分けるため、構造メタデータは複数の部品がどう組み合わさっているかを示すため、管理メタデータは作成日時や作成方法など資源を管理するための情報です。

IT の仕事では、データ管理の分野で「ビジネスメタデータ（業務上の意味・用語）」「テクニカルメタデータ（型・桁数・格納場所）」「オペレーショナルメタデータ（いつ処理されたか・件数）」と分けることもあります。呼び方は分野で違っても、「本体を説明する情報」という点は同じです。

身近な場所に置き直すと、次の6か所がよく出てきます。この記事ではそれぞれを実際に動かしています。

写真のメタデータ（EXIF）の中身を見る

この節では、写真に入っている EXIF の項目と、それを読み出す方法が実物で分かります。

EXIF（Exchangeable image file format）は、写真の中に撮影情報を埋め込むための規格です。日本のカメラ映像機器工業会（CIPA）が中心となって定めていて、2023年に公開された Exif 3.0 では UTF-8 の文字列も扱えるようになりました（IPTC の告知による）。

手元で 640×480 の JPEG を作り、ExifTool でダミーの値を書き込みました。位置情報は実在の撮影地ではない自作の値です。

exiftool -overwrite_original -Make="RJC" -Model="DummyCam 1" \
  -DateTimeOriginal="2026:10:29 10:15:30" -Artist="Taro Test" \
  -Software="test-writer 1.0" \
  -GPSLatitude=35.123456 -GPSLatitudeRef=N \
  -GPSLongitude=139.654321 -GPSLongitudeRef=E -GPSAltitude=12.3 \
  -Orientation#=6 photo.jpg
exiftool -G1 -a -s photo.jpg

読み出した結果のうち、EXIF に関わる部分です（グループ名が左の角かっこ）。

[IFD0]          Make                            : RJC
[IFD0]          Model                           : DummyCam 1
[IFD0]          Orientation                     : Rotate 90 CW
[IFD0]          Software                        : test-writer 1.0
[IFD0]          Artist                          : Taro Test
[ExifIFD]       ExifVersion                     : 0232
[ExifIFD]       DateTimeOriginal                : 2026:10:29 10:15:30
[GPS]           GPSVersionID                    : 2.3.0.0
[GPS]           GPSLatitudeRef                  : North
[GPS]           GPSLatitude                     : 35 deg 7' 24.44"
[GPS]           GPSLongitudeRef                 : East
[GPS]           GPSLongitude                    : 139 deg 39' 15.56"
[GPS]           GPSAltitude                     : 12.3 m
[Composite]     GPSPosition                     : 35 deg 7' 24.44" N, 139 deg 39' 15.56" E

位置情報は「度・分・秒」で入っています。-n を付けると地図アプリに貼れる10進数で出ます。

$ exiftool -s -s -s -n -GPSLatitude -GPSLongitude photo.jpg
35.123456
139.654321

ファイルの先頭に「Exif」の文字がある

EXIF は JPEG の先頭近くにある APP1 という区画（マーカー ff e1）に入っています。バイト列を表示すると、本体の画素より前に Exif の文字が見えます。

$ od -A d -t x1z -N 40 photo.jpg
0000000 ff d8 ff e0 00 10 4a 46 49 46 00 01 01 00 00 01  >......JFIF......<
0000016 00 01 00 00 ff e1 01 ac 45 78 69 66 00 00 4d 4d  >........Exif..MM<
0000032 00 2a 00 00 00 08 00 0b                          >.*......<

file コマンドでも「Exif Standard」と出ます。

$ file photo.jpg
photo.jpg: JPEG image data, JFIF standard 1.01, aspect ratio, density 1x1, segment length 16, Exif Standard: [TIFF image data, big-endian, direntries=11], baseline, precision 8, 640x480, components 3

Python（Pillow）で読む

プログラムから読むときは Pillow の getexif() を使います。位置情報は GPS 用の入れ子（IFD）に分かれているので、get_ifd() で取り出します。

from PIL import Image, ExifTags

im = Image.open("photo.jpg")
ex = im.getexif()
for k, v in ex.items():
    print(ExifTags.TAGS.get(k, k), "=", v)
gps = ex.get_ifd(ExifTags.IFD.GPSInfo)
for k, v in gps.items():
    print("GPS", ExifTags.GPSTAGS.get(k, k), "=", v)
lat = gps[2]
print("decimal lat", round(float(lat[0]) + float(lat[1]) / 60 + float(lat[2]) / 3600, 6))

Make = RJC
Model = DummyCam 1
Software = test-writer 1.0
Orientation = 6
Artist = Taro Test
GPS GPSLatitudeRef = N
GPS GPSLatitude = (35.0, 7.0, 24.4416)
GPS GPSLongitudeRef = E
GPS GPSLongitude = (139.0, 39.0, 15.5556)
GPS GPSAltitude = 12.3
decimal lat 35.123456

ImageMagick の identify でも読めます（identify -format '%[EXIF:Model]' photo.jpg で DummyCam 1）。Pillow の基本は関連記事「Python Pillowで画像処理｜リサイズ・トリミング・形式変換のコード集」で扱っています。

スマホ・パソコンの画面で見る

iPhone では「写真」アプリで写真の情報を表示でき、Apple の iPhone ユーザガイド「iPhoneで写真やビデオの情報を表示する」は、撮影された日付と時刻・カメラ固有のメタデータなどを表示できると説明しています。Android の Google フォトでも、写真の詳細に撮影場所が表示されます。画面の項目名は OS やアプリの版で変わるため、どの端末でも「写真を1枚開き、情報の画面に地図や地名が出ていないか」を見るのが手早い確かめ方です。パソコンなら、ExifTool のように画面の表示に頼らず中身を全部書き出せる道具が確実です。

写真のメタデータを削除する方法（位置情報だけ／全部）

この節では、写真のメタデータを消す方法ごとに、何が消えて何が残るか、画質や向きがどう変わるかが実測で分かります。

消し方は「位置情報だけ消す」「メタデータを全部消す」「画像を描き直して保存する」の3通りで、結果がそれぞれ違います。同じ写真を7通りに処理し、位置情報（GPS）・向き（Orientation）・機種名（Model）が残るかを ExifTool で調べました。

exiftool -overwrite_original -gps:all= a_gps.jpg                       # 位置情報だけ
exiftool -overwrite_original -all= a_all.jpg                           # 全部
exiftool -overwrite_original -all= -tagsfromfile @ -Orientation a_keep.jpg  # 全部消して向きだけ戻す
python3 -c "from PIL import Image; Image.open('photo.jpg').save('a_pil.jpg', quality=90)"
convert photo.jpg -strip a_im.jpg                                      # ImageMagick

photo.jpg        9745 bytes  GPS:1   Orient:Rotate 90 CW     Model:DummyCam 1
a_gps.jpg        9599 bytes  GPS:0   Orient:Rotate 90 CW     Model:DummyCam 1
a_all.jpg        9297 bytes  GPS:0   Orient:                 Model:
a_keep.jpg       9397 bytes  GPS:0   Orient:Rotate 90 CW     Model:
a_pil.jpg        9203 bytes  GPS:0   Orient:                 Model:
a_pil_exif.jpg   9633 bytes  GPS:1   Orient:Rotate 90 CW     Model:DummyCam 1
a_im.jpg         4667 bytes  GPS:0   Orient:                 Model:

「画素が変わるか」は、各ファイルを読み込んで画素の並びのハッシュを比べました。ExifTool で消したファイルは元と同じ値、Pillow と ImageMagick で保存し直したファイルは別の値になりました。

photo.jpg 23de3b77c3b5
a_all.jpg 23de3b77c3b5   ← ExifTool -all=。画素は同じ
a_pil.jpg c26bf79a55b0   ← Pillow で保存し直し。JPEG を圧縮し直している
a_im.jpg  07c74b285b2e   ← ImageMagick -strip。同じく圧縮し直し

全部消すと写真が横倒しになる理由

スマホは縦に構えて撮った写真も、画素は横長のまま保存し、「表示するときに90度回す」という指示を EXIF の Orientation に書くことがあります。Orientation まで消すと、回す指示が無くなり横倒しで表示されます。Pillow で表示上の大きさを確かめると、次のように変わりました。

photo.jpg  stored (640, 480) displayed (480, 640)   ← 縦長で表示
a_all.jpg  stored (640, 480) displayed (640, 480)   ← 向きの指示が消えて横長
a_keep.jpg stored (640, 480) displayed (480, 640)   ← Orientation だけ戻した

消したあとに確かめる手順

なお、写真に写っている看板や窓の外の景色から場所が分かることもあります。メタデータを消しても、写っている中身の情報は消えません。

スマホ・SNSで写真を送るときの位置情報

この節では、スマホのカメラの設定と、サイトやサービスに写真を上げるときに位置情報がどう扱われるかが分かります。

写真の位置情報は、撮るときに付けない設定にするのが最も確実です。Android について Google は「Android のカメラには位置情報が使われる？設定でオン、オフする方法」で、カメラアプリの設定で位置情報をオン・オフできること（手順はメーカーで異なる）を案内しています。同じページでは、位置情報を使って撮影した写真から、カメラが付けた位置情報を Google フォトで削除することはできず、削除できるのは Google フォトが推定で付けた「撮影場所（推定）」だと説明しています。

4行目は手元で確かめました。127.0.0.1 で起動した Web サーバーに位置情報入りの写真を置き、curl でダウンロードし直すと、元のファイルとバイト単位で同じで、位置情報もそのまま読めました。

$ curl --noproxy '*' -sS -o dl.jpg http://127.0.0.1:28124/photo.jpg
$ exiftool -s -s -s -n -GPSPosition dl.jpg
35.123456 139.654321
$ cmp photo.jpg dl.jpg && echo identical
identical

自分でサイトを作る側なら、利用者が上げた写真は保存前にメタデータを消す処理を入れておくと、利用者の位置情報を公開してしまう事故を防げます。SNS やチャットのサービスがアップロード時にメタデータを消すかどうかは、サービスと時期で変わり、公式に明記されていないこともあります。受け取る側の処理に任せず、送る側で消しておくのが確かです。

• 1自宅・学校・職場で撮った写真か位置情報が付いていれば、場所がそのまま伝わる
• 2情報の画面に地図や地名が出ていないか出ていれば位置情報が入っている
• 3送る・上げる前に位置情報を消したか撮影日時や機種名も気になるなら全部消して向きだけ戻す
• 4写っている物から場所が分からないか表札・看板・窓の外・制服などはメタデータとは別の話

Word・Excel・PDFのメタデータ（プロパティ）を確認・削除

この節では、Office ファイルの中にあるメタデータの正体と、Microsoft が案内している削除の手順が分かります。

Word（.docx）・Excel（.xlsx）・PowerPoint（.pptx）のファイルは中身が zip で、メタデータは docProps フォルダーの XML に入っています。python-docx で作成者・最終更新者・コメント入りの .docx を作り、unzip で開きました。

$ unzip -l quote.docx
  Length      Date    Time    Name
---------  ---------- -----   ----
     1738  2026-10-30 21:01   [Content_Types].xml
      734  2026-10-30 21:01   _rels/.rels
      793  2026-10-30 21:01   docProps/core.xml
     1132  2026-10-30 21:01   docProps/app.xml
     1696  2026-10-30 21:01   word/document.xml
   （中略）
     8324  2026-10-30 21:01   docProps/thumbnail.jpeg

docProps/core.xml が作成者などの基本のプロパティです。項目名は図書館の目録で使われる Dublin Core（dc:）の語彙を使っています。

<dc:title>見積書</dc:title>
<dc:creator>山田テスト</dc:creator>
<dc:description>社内用メモ：値引きは10%まで</dc:description>
<cp:lastModifiedBy>佐藤ダミー</cp:lastModifiedBy>
<cp:revision>3</cp:revision>
<dcterms:created xsi:type="dcterms:W3CDTF">2026-10-29T09:00:00Z</dcterms:created>
<dcterms:modified xsi:type="dcterms:W3CDTF">2026-10-29T09:30:00Z</dcterms:modified>

docProps/app.xml には作ったアプリの名前やテンプレート名が入ります。手元のファイルは Linux の python-docx で作ったのに、次のように出ました。

<Template>Normal.dotm</Template>
<Application>Microsoft Macintosh Word</Application>

python-docx が雛形として同梱している文書の値が、そのまま引き継がれているためです。メタデータは「誰が・何で作ったか」の証拠にはならないことと、雛形のファイルから作った文書は雛形の情報を持ち越すことが分かります。さらに docProps/thumbnail.jpeg（8,324バイト）は、エクスプローラーなどで表示するための縮小画像です。中身を書き換えたのに縮小画像だけ前の版のまま、ということも起こり得ます。

作成者だけ空にしても、他の項目は残る

python-docx で作成者・最終更新者・タイトル・コメントを空にして保存し直すと、次のようになりました。

<dc:creator></dc:creator>
<dc:description></dc:description>
<cp:lastModifiedBy></cp:lastModifiedBy>
<cp:revision>3</cp:revision>
<dcterms:created xsi:type="dcterms:W3CDTF">2026-10-29T09:00:00Z</dcterms:created>
<Application>Microsoft Macintosh Word</Application>

空にした項目以外（版の番号・作成日時・アプリ名・縮小画像）は残っています。社外に出す文書は、一部の項目を手で消すより、Office のドキュメント検査でまとめて確かめる方が漏れにくくなります。

Office の「ドキュメント検査」で消す（Microsoft 公式の手順）

Microsoft サポート「ドキュメントを検査して非表示のデータと個人情報を削除する」の手順は次のとおりです（Word の例）。削除した内容は元に戻せない場合があるため、Microsoft はコピーに対して行うよう案内しています。

1. 1コピーを作って開く［ファイル］→［名前を付けて保存］で別名にする
2. 2［ファイル］→［情報］→［問題のチェック］→［ドキュメント検査］ドキュメント インスペクターが開く
3. 3調べる項目を選んで［検査］「ドキュメントのプロパティと個人情報」など
4. 4消したい項目の［すべて削除］終わったら［再検査］で残りを確かめる

検査できる項目は、同じページで「コメント、変更履歴、バージョン、および注釈」「ドキュメントのプロパティと個人情報」「ヘッダー、フッター、透かし」「隠し文字」「カスタム XML データ」「非表示の内容」と説明されています。白い背景に白い文字で書いた文や、他の図形に隠れた図形は検査で見つからない、という注意も書かれています。

PDF のメタデータを見る（pdfinfo）

同じ .docx を LibreOffice で PDF にすると、Word のタイトルと作成者が PDF のメタデータに移りました。

$ pdfinfo quote.pdf
Title:           見積書
Author:          山田テスト
Creator:         Writer
Producer:        LibreOffice 24.2
CreationDate:    Fri Oct 30 21:01:51 2026 JST
Tagged:          yes
Pages:           1
Encrypted:       no
Page size:       612 x 792 pts (letter)
PDF version:     1.7

「PDF にしたから作成者は消えた」とは限りません。PDF の作成者・作成ソフト・作成日時は、PDF ビューアーの［文書のプロパティ］でも見られます。

PDFのメタデータ削除で残るもの（追記型の保存）

この節では、PDF のメタデータを消したつもりで前の値がファイルに残る場合と、確かに消す方法が実物で分かります。

PDF は、変更をファイルの末尾に書き足して保存する「増分更新」ができる形式です。ExifTool で PDF のメタデータを全部消すと、警告が出ました。

$ exiftool -all:all= p1.pdf
Warning: [minor] ExifTool PDF edits are reversible. Deleted tags may be recovered! - p1.pdf
    1 image files updated

pdfinfo からは Title・Author が消えましたが、ファイルの中を探すと、作成者の値（UTF-16 の16進数で書かれた「山田テスト」）が残っていました。ファイルの末尾を示す %%EOF も2つになり、元の内容の後ろに変更が書き足されていることが分かります。

$ grep -a -o 'Author[^/]\{0,40\}' p1.pdf
Author<FEFF5C71753030C630B930C8>
size 6821 %%EOF count 2

ExifTool には、書き足した変更を取り消す指定があり、実行すると消したはずの値が戻りました。

$ exiftool -pdf-update:all= p1.pdf
$ pdfinfo p1.pdf
Title:           見積書
Author:          山田テスト

ExifTool の公式ドキュメント（PDF Tags）も、PDF のメタデータの編集はすべて元に戻せること、前の情報はファイルから実際には消えないためセキュリティ上の問題になり得ることを書き、完全に消すには qpdf --linearize in.pdf out.pdf で書き直すよう案内しています。その手順で書き直すと、作成者の値はファイルのどこにも無くなりました。

$ exiftool -overwrite_original -all:all= p2.pdf
$ qpdf --linearize p2.pdf p2q.pdf
$ python3 -c "b=open('p2q.pdf','rb').read(); print('Author' in b.decode('latin1'))"
False

Word から PDF を作る場合は、先に Word 側でドキュメント検査をしてから PDF に書き出すと、PDF に作成者が移りません。

ファイルのメタデータ（stat・inode・タイムスタンプ）

この節では、ファイルの中身とは別に OS が管理しているメタデータと、コピーや名前の変更で何が変わるかが分かります。

ファイルの大きさ・更新日時・所有者・権限は、ファイルの中ではなく、ファイルシステムの管理領域（Linux では inode）に記録されています。Linux では stat で全部を見られます。

$ echo 'hello metadata' > note.txt
$ touch -d '2026-10-29 10:00:00' note.txt
$ stat note.txt
  File: note.txt
  Size: 15        	Blocks: 8          IO Block: 4096   regular file
Device: 0,28	Inode: 11788       Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2026-10-29 10:00:00.000000000 +0900
Modify: 2026-10-29 10:00:00.000000000 +0900
Change: 2026-10-30 21:02:07.814042591 +0900
 Birth: 2026-10-30 21:02:07.807829025 +0900

touch -d で変えられるのは Access（atime）と Modify（mtime）だけで、Change（ctime：メタデータが最後に変わった時刻）と Birth（作成日時）は実際の時刻のままです。更新日時は簡単に書き換えられるので、それだけで「いつ作ったか」の証拠にはなりません。

名前の変更・コピー・権限の変更で何が変わるか

$ mv note.txt memo.txt
$ stat -c 'inode=%i mtime=%y' memo.txt
inode=11788 mtime=2026-10-29 10:00:00.000000000 +0900

$ cp memo.txt c1.txt; cp -p memo.txt c2.txt
memo.txt inode=11788 mtime=2026-10-29 10:00:00.000000000 +0900
c1.txt   inode=11789 mtime=2026-10-30 21:02:07.836238384 +0900
c2.txt   inode=11790 mtime=2026-10-29 10:00:00.000000000 +0900

$ chmod 600 memo.txt
$ stat -c 'mode=%A mtime=%y ctime=%z' memo.txt
mode=-rw------- mtime=2026-10-29 10:00:00.000000000 +0900 ctime=2026-10-30 21:02:08.855829088 +0900

名前は inode ではなく、フォルダー（ディレクトリ）の側に「名前→inode 番号」の対応として記録されているため、名前を変えても inode 番号は同じです。ls -li の先頭の数字が inode 番号です。atime・mtime・ctime の細かい違いとオプションは、関連記事「Linux statコマンドの使い方｜atime・mtime・ctime早見表」で扱っています。

拡張属性（xattr）という置き場所もある

ファイルシステムによっては、名前と値の組を自由に付けられる「拡張属性」があります。Linux では user. で始まる名前で付けられます。

import os
os.setxattr("memo.txt", "user.source", b"dummy-crawler")
print(os.listxattr("memo.txt"), os.getxattr("memo.txt", "user.source"))
# ['user.source'] b'dummy-crawler'

拡張属性も本体とは別に付くメタデータで、ls -l や cat では見えません。対応していないファイルシステムに移したり、属性を保たない方法でコピーしたりすると失われることがあります。

Webのメタデータ（HTTPヘッダーとmetaタグ・OGP）

この節では、Web ページを開いたときにやり取りされるメタデータと、検索エンジンや SNS が読む meta タグが分かります。

Web では、サーバーが返す HTTP ヘッダーと、HTML の head に書く meta タグ・OGP・構造化データが主なメタデータです。127.0.0.1 で Python の http.server を起動し、curl でヘッダーだけを取りました。

$ curl --noproxy '*' -sS -I http://127.0.0.1:28124/index.html
HTTP/1.0 200 OK
Server: SimpleHTTP/0.6 Python/3.13.18
Date: Fri, 30 Oct 2026 12:02:29 GMT
Content-type: text/html
Content-Length: 801
Last-Modified: Thu, 29 Oct 2026 01:00:00 GMT

Content-type（種類）・Content-Length（大きさ）・Last-Modified（更新日時）は、どれも本文そのものではなく本文を説明する情報です。Last-Modified は、前の節の touch -d '2026-10-29 10:00:00'（日本時間）で設定したファイルの更新日時が、そのまま協定世界時で返ったものです。ファイルシステムのメタデータが HTTP のメタデータになっている例です。

ブラウザーは、この更新日時を覚えておき、次に開くとき If-Modified-Since を付けて「この時刻から変わったか」を尋ねます。変わっていなければ本文を送らずに 304 が返ります。

$ curl --noproxy '*' -sS -o /dev/null -w '%{http_code}\n' \
    -H 'If-Modified-Since: Thu, 29 Oct 2026 01:00:00 GMT' http://127.0.0.1:28124/index.html
304

キャッシュの指示（Cache-Control）の使い分けは、関連記事「Cache-Controlのno-cacheとno-storeの違いと正しい設定」で扱っています。

HTML の meta タグ・OGP・構造化データ

見本のページの head に、説明文・robots・canonical・OGP・JSON-LD を書き、取得した HTML から機械が読む部分だけを取り出しました。

meta {'charset': 'utf-8'}
meta {'name': 'description', 'content': 'メタデータを確かめるための見本ページです。'}
meta {'name': 'viewport', 'content': 'width=device-width, initial-scale=1'}
meta {'name': 'robots', 'content': 'noindex'}
link {'rel': 'canonical', 'href': 'https://example.com/sample/'}
meta {'property': 'og:title', 'content': 'メタデータの見本ページ'}
meta {'property': 'og:type', 'content': 'article'}
meta {'property': 'og:image', 'content': 'https://example.com/ogp.png'}
ld+json {'@context': 'https://schema.org', '@type': 'Article', 'headline': 'メタデータの見本ページ', 'datePublished': '2026-10-29'}

Google 検索セントラル「Google がサポートしているメタタグと属性」は、description・robots・viewport・charset などを対応するタグとして挙げ、keywords のメタタグは Google 検索では使われないと説明しています。OGP（Open Graph protocol）の公式サイトは、og:title・og:type・og:image・og:url の4つを各ページに必須のプロパティとしています。

タグごとのコピペ用の書き方は関連記事「HTML metaタグ一覧｜SEO・OGP・viewportのコピペ用テンプレート」で、Next.js の App Router で metadata を書く方法は関連記事「Next.jsのメタデータとSEO設定｜sitemap・OG画像まで実出力つき」で扱っています。この記事は「メタデータとは何か」の入口、それらの記事は書き方と実装、という分担です。

データベースのメタデータ（information_schema）

この節では、データベースが自分の表や列についての情報をどう持っていて、SQL でどう読むかが分かります。

データベースでは、表名・列名・型・NULL の可否・制約といった「データの定義」がメタデータです。データベース自身がそれを表として持っていて、SQL で読めます。作業用に起動した PostgreSQL 16.15 で表を作り、標準 SQL の information_schema から読みました。

CREATE TABLE customers (
  id      bigserial PRIMARY KEY,
  name    text NOT NULL,
  email   varchar(255) UNIQUE,
  created timestamptz NOT NULL DEFAULT now()
);
COMMENT ON COLUMN customers.email IS '連絡先（個人情報）';

SELECT column_name, data_type, is_nullable, column_default
  FROM information_schema.columns
 WHERE table_name = 'customers' ORDER BY ordinal_position;

 column_name |        data_type         | is_nullable |            column_default
-------------+--------------------------+-------------+---------------------------------------
 id          | bigint                   | NO          | nextval('customers_id_seq'::regclass)
 name        | text                     | NO          |
 email       | character varying        | YES         |
 created     | timestamp with time zone | NO          | now()
(4 rows)

制約も同じように読めます。列に付けたコメントは PostgreSQL 固有の関数で読みます。

   constraint_name   | constraint_type | column_name
---------------------+-----------------+-------------
 customers_email_key | UNIQUE          | email
 customers_pkey      | PRIMARY KEY     | id

$ SELECT col_description('customers'::regclass, 3);
 連絡先（個人情報）

PostgreSQL の公式ドキュメントは、information_schema を「現在のデータベースで定義されたオブジェクトの情報を持つビューの集まり」で、SQL 標準で定められているため移植性があり安定している、と説明しています。PostgreSQL 固有の情報は pg_catalog（システムカタログ）にあります。

統計情報もメタデータ

行数の見積もりなど、速く検索するための統計情報もメタデータです。表を作って1行入れた直後は、見積もりの行数が「まだ集めていない」を表す -1 で、ANALYZE を実行すると1になりました。

  relname  | reltuples | pg_size_pretty
-----------+-----------+----------------
 customers |        -1 | 48 kB

ANALYZE customers;
  relname  | reltuples
-----------+-----------
 customers |         1

SQLite では、表の定義が sqlite_schema に CREATE 文のまま入っていて、列の一覧は PRAGMA table_info で読めます。

[('table', 'customers', 'CREATE TABLE customers(id INTEGER PRIMARY KEY, name TEXT NOT NULL, email TEXT UNIQUE)'),
 ('index', 'sqlite_autoindex_customers_1', None)]
(0, 'id', 'INTEGER', 0, None, 1)
(1, 'name', 'TEXT', 1, None, 0)
(2, 'email', 'TEXT', 0, None, 0)

このメタデータを使うと、テーブル定義書を手で書かずに自動で作れます。SQL の例は関連記事「テーブル定義書の書き方とテンプレート DDLから自動生成するSQL」で扱っています。

音楽ファイルとGitのメタデータ

この節では、音楽ファイルの曲名などのタグと、Git のコミットに残る作者情報が分かります。

MP3 の曲名・アーティスト・アルバムは、ファイルの先頭にある ID3 タグというメタデータです。ffmpeg で3秒の音を作り、タグを付けて読み出しました。

ffmpeg -f lavfi -i sine=frequency=440:duration=3 \
  -metadata title="テスト曲" -metadata artist="ダミー楽団" \
  -metadata album="見本アルバム" -metadata track=1 \
  -c:a libmp3lame -b:a 128k song.mp3
ffprobe -v error -show_entries format=duration,bit_rate:format_tags -of default=nw=1 song.mp3

duration=3.030204
bit_rate=129509
TAG:title=テスト曲
TAG:artist=ダミー楽団
TAG:album=見本アルバム
TAG:date=2026
TAG:track=1
TAG:encoder=Lavf60.16.100

ファイルの先頭は ID3 の3文字で始まり、ExifTool では [ID3v2_4] のグループで読めました（ID3Size は155バイト）。タグを消すには ffmpeg -i song.mp3 -map_metadata -1 -c copy song_clean.mp3 を使いますが、消したあとも TAG:encoder=Lavf60.16.100 だけは残りました。ffmpeg が書き出すときに自分の名前と版を付けるためです。「消すための道具」が新しいメタデータを足すことがある点は覚えておくと役立ちます。

Git のコミットにも名前・メールアドレス・時刻が残る

Git のコミットは、変更の中身に加えて、作者（Author）とコミットした人（Commit）の名前・メールアドレス・日時を持っています。

$ git log --format=fuller
commit afc747f7b4081f9d17e24646ad0303b9dddac60f
Author:     Test User <test@example.com>
AuthorDate: Thu Oct 29 10:00:00 2026 +0900
Commit:     Test User <test@example.com>
CommitDate: Fri Oct 30 21:03:06 2026 +0900

    first

AuthorDate は --date で指定した値、CommitDate は実際に記録した時刻です。公開リポジトリに push すると、このメールアドレスも公開されます。GitHub Docs「コミットメールアドレスを設定する」は、個人のメールアドレスを出したくない場合に GitHub が提供する noreply アドレスを git config user.email に設定できること、設定を変えても変更前のコミットは前のアドレスのままであることを説明しています。

メタデータが残る・消えるよくあるつまずき

この節では、メタデータで起こりやすい失敗と、そのときに出る表示・原文が一覧で分かります。

ffmpeg の encoder タグは、-fflags +bitexact -flags:a +bitexact を足して書き出し直すと、手元の MP3 では ffprobe のタグが何も出なくなりました。形式や版で付く項目は変わるため、消したあとは必ず ffprobe や ExifTool で読み直して確かめます。

メタデータを消すか残すかの判断表

この節では、場面ごとにメタデータを消すべきか、残すべきかの目安が分かります。

メタデータは「消すほど安全」ではなく、検索・整理・正しい表示のために残す方がよい場面もあります。誰に渡すか、何に使われるかで決めます。

迷ったときは、次の順に考えると決めやすくなります。

1. 1誰に渡るか自分だけ・社内・取引先・不特定多数
2. 2何が入っているかを読むExifTool・pdfinfo・ドキュメント検査で一覧にする
3. 3個人や場所が分かる項目を消す位置情報・氏名・メールアドレス・社内コメント
4. 4表示や検索に要る項目は残す向き・タイトル・文字コード・OGP
5. 5消したあと読み直すPDF は書き直したファイルで確かめる

よくある質問

Q. メタデータとは簡単に言うと何ですか？ A. 「データについてのデータ」です。写真なら撮影日時・カメラの機種・位置情報、文書なら作成者・作成日時のように、本体を説明する情報を指します。

Q. メタデータの例を教えてください。 A. 写真の EXIF（撮影日時・位置情報）、Word の作成者・最終更新者、PDF の作成ソフト、ファイルの更新日時、Web ページの description や OGP、データベースの列名と型、音楽の曲名とアーティストなどです。

Q. メタデータとデータの違いは何ですか？ A. データは本体（写真の画素・文書の本文・表の行）、メタデータはその本体を説明する情報です。同じ情報でも、何を本体と見るかで立場が変わります。たとえば列の定義は、データベースを管理する道具から見れば本体のデータです。

Q. 写真のメタデータを削除するとどうなりますか？ A. 撮影日時・機種・位置情報が見えなくなり、写真アプリで日付順や場所で整理できなくなります。向き（Orientation）まで消すと、縦の写真が横倒しで表示されることがあります。位置情報だけを消す方法もあります。

Q. スクリーンショットにも位置情報は入りますか？ A. スクリーンショットはカメラで撮った写真ではないため、カメラの位置情報は通常付きませんが、端末やアプリによって付く情報は違います。気になるときは ExifTool などで中身を読むのが確実です。

Q. Word や Excel の作成者名はどこで消せますか？ A. Office の［ファイル］→［情報］→［問題のチェック］→［ドキュメント検査］で「ドキュメントのプロパティと個人情報」を削除します。Microsoft は、元に戻せない場合があるためコピーで行うよう案内しています。

Q. PDF のメタデータは消せますか？ A. 消せますが、ソフトによっては変更を末尾に書き足すだけで、前の値がファイルに残ります。手元では ExifTool で消したあと、qpdf で書き直して初めて作成者の値が無くなりました。

Q. ファイルの更新日時はメタデータですか？ A. はい。ファイルの中ではなく、ファイルシステムが管理するメタデータです。Linux では stat で見られ、touch で書き換えられるため、それだけで作成時期の証拠にはなりません。

Q. SEO のメタデータとは何を指しますか？ A. 主に HTML の head に書く title・meta description・robots・canonical と、OGP・構造化データ（JSON-LD）です。Google 検索は keywords のメタタグを使わないと公式に説明しています。

Q. データベースのメタデータはどうやって見ますか？ A. 標準 SQL の information_schema（tables・columns・table_constraints など）を SELECT します。PostgreSQL 固有の情報は pg_catalog、SQLite は sqlite_schema と PRAGMA table_info で見られます。

まとめ

• メタデータとは「データについてのデータ」。本体を説明する撮影日時・作成者・更新日時・型などで、記述・構造・管理の3つに分けられる。
• 写真の EXIF には位置情報が入ることがある。Web サーバーに置いただけでは消えず、送る側で消すのが確か。全部消すと向きも消えるので、位置情報だけ消すか向きを戻す。
• Office は zip の中の docProps にある。作成者だけ空にしてもアプリ名・作成日時・縮小画像が残るので、ドキュメント検査でまとめて消す。
• PDF は「消したのに残る」ことがある。増分更新で書き足しただけの場合があり、書き直して保存したファイルで確かめる。
• ファイル・Web・DB にもメタデータがある。stat の更新日時は HTTP の Last-Modified になり、DB の定義は information_schema で読める。消すか残すかは「誰に渡るか」で決める。

参考・出典

確認日はいずれも 2026年10月29日です。

• NISO「Understanding Metadata」：https://www.niso.org/publications/understanding-metadata
• IPTC「Exif 3.0 released, featuring UTF-8 support」：https://iptc.org/news/exif-3-0-released-featuring-utf-8-support/
• ExifTool「PDF Tags」：https://exiftool.org/TagNames/PDF.html
• Microsoft サポート「ドキュメントを検査して非表示のデータと個人情報を削除する」：https://support.microsoft.com/ja-jp/office/inspect-your-document-for-hidden-data-or-personal-information-356b7b5d-77af-44fe-a07f-9aa4d085966f
• Apple「iPhoneで写真やビデオの情報を表示する」（iPhone ユーザガイド）：https://support.apple.com/ja-jp/guide/iphone/iph0edb9c18f/ios
• Google「Android のカメラには位置情報が使われる？設定でオン、オフする方法」：https://www.android.com/intl/ja_jp/articles/70/
• Google 検索セントラル「Google がサポートしているメタタグと属性」：https://developers.google.com/search/docs/crawling-indexing/special-tags?hl=ja
• The Open Graph protocol：https://ogp.me/
• PostgreSQL 16 Documentation「The Information Schema」：https://www.postgresql.org/docs/16/information-schema.html
• GitHub Docs「コミットメールアドレスを設定する」：https://docs.github.com/ja/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-email-preferences/setting-your-commit-email-address

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。