背景
自治体が公開しているオープンデータの中には、シェープファイル形式で配布されているものが多くあります。
ところが、実際に利用しようとすると仕様上の不備により扱いづらいケースが少なくありません。
その問題点を指摘したところ、多くの反応が寄せられました。
行政のオープンデータのとあるシェープファイルが
— asahina (@asahina820) August 5, 2025
・prjファイルがない
・座標系が書かれてない
・エンコーディングがShift-JIS
の3連コンボで大横転しました
ここからは、寄せられた知見や実務経験をもとに、シェープファイルの仕様上の特徴や問題点を掘り下げて整理してみます。
シェープファイルの仕様
シェープファイルとは
シェープファイル（Shapefile）は、ESRI社が提唱したベクター形式の地理空間データフォーマットです。1998年に仕様が公開されて以降長年使われ、現在も行政のオープンデータで多く見られます。
ちなみに表記は「シェープファイル」、「Shapefile」が正しい記載です。「Shapeファイル」、「ShapeFile」などは誤った記載なので注意しましょう。
基本構成
シェープファイルは1つのファイルではなく、複数のファイルが組み合わさって成り立っています。
-
必須ファイル
-
.shp：図形の情報 -
.shx：図形のインデックス情報 -
.dbf：属性データ（フォーマットはdBASE IV形式）
-
-
補助ファイル（任意）
-
.prj：図形の持つ座標系の定義情報（WKT形式） -
.cpg：文字コード（エンコーディング）を記録 - その他
.sbn.sbxなど空間インデックス関連
-
画像引用: シェープファイル - ESRIジャパン
よくある問題点
シェープファイルは仕様が公開されており、既存のソフトウェアでも広くサポートされているフォーマットですが、いくつか問題点があります。
それらを取り上げたSwitch from ShapefileというWebサイトがあったりします。
ここでは、日本のオープンデータ（シェープファイル形式）でよく見られる問題点について取り上げます。
PRJファイルがない
実は、シェープファイルの仕様書には.shp、.shx、.dbfの3つの必須ファイルしか定義されていません。
.prjはArcMap登場時のEsri独自拡張のようです。参考
そのため、CAD由来のシステムや昔からある業務システムでは座標系をユーザーに見せず、.prjファイルが出力されないことはよくあるそうです。
しかし .prjが欠けていると、利用者はデータの座標参照系を判断できません。
本来は、配布元が座標参照系を明記すべきですが、実際にはその情報が添えられていないケースも多々あります。その場合は、利用者が座標系を推測して設定する必要があります。
文字コードがShift_JIS
シェープファイルの属性データを格納する .dbfは dBASE IV フォーマットを利用しています。この仕様書には「文字コード」そのものについての定義はなく、どのエンコーディングを使うかはソフトウェアに依存しています。
そのため、従来から使われているシェープファイルはShift_JISで作成されていることが多いです。
また、.dbfの属性はバイト数制限があるため、Shift_JISとUTF-8で扱える日本語の文字数が異なります。Shift_JISの方が日本語を多く格納できるため、UTF-8で出力し直すと文字数制限を超えてしまい、フィールド名や属性値が途中で切れてしまう場合があります。
Webや現代のOS（LinuxやmacOSなど）標準では、UTF-8が事実上のデフォルトになっています。
シェープファイルについても、文字化けを回避し、国際化に対応するため、UTF-8を利用することが推奨されます。実際、主要なGISソフトウェアでもこの方針が採用されています。
ArcGIS 10.2.1 から、シェープファイルの作成・出力時のデフォルトの文字コードが UTF-8 に変更されました。
参考：シェープファイルの文字コードに関する注意 - ESRIジャパン
その他のつらみ
- 複数ファイルで構成される（.shp, .shx, .dbf など）
- 必要なファイルが欠けやすく、.shp だけが渡されるケースが頻発する
- フィールド名の文字数制限が厳しい
- 英数字は最大10文字、日本語は最大5文字まで
-
例のように
C23_001といった短縮記号が多用され、可読性が低い
- ファイルサイズの制限
- 各ファイルは最大2GBまで
- 大容量データには不向き
- ジオメトリの混在不可
- 1ファイルにつき1種類（点・線・面のいずれか）しか格納できない
- 3Dデータに非対応
などなど・・
QGISでの対応策
.prjファイルが付属していない、または文字コードがUTF-8ではないシェープファイルは、QGISを使って以下の方法で変換が可能です。
座標参照系の割り当て
.prj ファイルが欠けている場合、QGISは座標参照系（CRS）を「未定義」として読み込みます。
[レイヤプロパティ] → [ソース] → [設定されたCRS] から、正しいCRS（例：EPSG:6668 JGD2011 / 平面直角座標系XX系など）を手動で指定します。
配布元が座標参照系を明記していないケースは、経験上、その地域に対応する平面直角座標系を割り当てると正しく表示されることが多いです。
文字コードの指定
QGISでは、シェープファイルを読み込む際に文字コードを選択できます。
日本の行政オープンデータは Shift_JIS で配布されていることが多いため、デフォルトのUTF-8で文字化けした場合は、[レイヤプロパティ] → [ソース] → [エンコーディング] から 「Shift_JIS」 を指定すると正しく表示されます。
再保存して利用する
正しくCRSと文字コードを設定できたら、その状態を維持したままシェープファイルをエクスポートしておくと安心です。
さらに、GeoPackage（.gpkg） や GeoJSON といった別のフォーマットに変換しておくと、ファイル分割や文字数制限といったシェープファイル特有の問題を回避できます。
推奨される代替フォーマット
このように、Shapefileにはファイル分割の煩雑さ・サイズ上限・属性の制約など多くの「つらみ」があるため、以下のような代替フォーマットを利用することが推奨されます。
GeoJSON
GeoJSONは、JSONベースのベクタデータフォーマットです。
仕様はRFC 7946に定義されています。
座標参照系はEPSG:4326（WGS84、地理座標系）を利用します。
また、テキスト形式のため人間が直接内容を確認でき、Webアプリケーションとの親和性が非常に高いのが特徴です。
GeoPackage (.gpkg)
GeoPackageは、OGC（Open Geospatial Consortium）の国際標準として策定されたフォーマットです。
内部はSQLiteをベースにしており、単一ファイルでベクタデータとラスタデータを同時に格納できます。
FlatGeoBuf
FlatGeoBufは、FlatBuffersを基盤とした高性能なバイナリエンコード形式です。
大容量の静的データを効率的に扱えるよう設計されており、従来のフォーマットと比べて高速な処理性能を発揮します。
さらに、コンテンツやメタデータにサイズ制限がなく、ストリーミング配信やランダムアクセスといった現代的なユースケースにも適しています。
まとめ
シェープファイルはGIS黎明期を支えた功労者ですが、必須でないPRJ・文字コードの混在・容量制限など、現在のオープンデータには不向きな点が目立ちます。
利用者がシェープファイルの「座標系を設定し直す」「文字化けを直す」といった作業を繰り返すのは、大きな負担となり、せっかくのオープンデータが十分に活用されない原因になってしまいます。
これからは、GeoPackageやGeoJSONなどのフォーマットを利用することで、行政のオープンデータはもっと扱いやすくなり、利用者・配布者にとって大きなメリットが生まれると考えます。