8つの代表的な設定ファイル形式はどう選ぶべきか: INI、XML、JSON、YAML、TOML から Markdown まで

Wed, 22 Apr 2026 21:48:37 +0800

コードを書く人、サーバーをいじる人、ゲーム設定を調整する人、あるいは各種ツールチェーンを保守する人にとって、設定ファイルは避けて通れません。

実際、プログラムを本当に壊すのはアルゴリズムでもフレームワークでもなく、設定の 1 行であることが少なくありません。スペースが 1 つ足りない、カンマが 1 つ多い、あるいは値の書き方がシステムの想定から外れている。代表的な設定ファイル形式を並べて考えると、自然と次の問いに戻ってきます。

人間が書きやすい形式はどれか
機械が読みやすい形式はどれか
AI Agent の時代に、設定ファイルそのものの役割は変わるのか

この記事は、その問いを簡潔に整理したものです。

01 設定ファイルとは、結局「人」と「機械」の調停である

設定ファイルをうまく言い表すなら、人間とプログラムの間で交わされる一種の「行動契約」だと言えます。

その価値は明快です。業務ロジックを書き直さなくても、再コンパイルしなくても、数行のテキストを書き換えるだけで、サイトの挙動、アプリのロジック、デプロイ方法、あるいはゲームのグラフィックや隠し設定まで変えられます。

ただし、その契約には最初から矛盾があります。

人間が欲しいのは、たとえば次のようなものです。

読みやすく、書きやすく、階層がわかりやすいこと
コメントを書けて、あとから見返しやすいこと
できるだけ重複を減らし、再利用やモジュール化がしやすいこと
小さなミスで即死しないこと

しかし機械が気にするのは、ほぼ次の 2 点です。

解析が速いこと
ルールが厳密で、型が明確で、曖昧さが少ないこと

だから設定ファイル形式は常に「人間に優しいか」「機械に優しいか」の間で引っ張られます。人間に読みやすい形式ほど、機械にとっては解析が面倒になりやすい。機械にとって処理しやすい形式ほど、人間には編集時の事故が起こりやすいのです。

02 INI: 単純でわかりやすいが、表現力は低い

まずは INI です。

長所はとてもわかりやすいです。

構造が単純
セクションとキー・バリューの組み合わせで直感的
コメントを書ける
ゲーム設定や基本的な環境変数のような軽量設定に向く

古いゲーム設定をいじったことがある人や、手動でツールのパラメータを触ったことがある人なら、一度は見たことがあるはずです。

ただし INI には明確な限界もあります。構造が平坦すぎるため、複雑なネストや配列を自然に表現しにくいのです。加えて、厳密な型システムを持たないことが多く、多くの値は結局ただの文字列として扱われ、最終的な解釈はプログラム側に委ねられます。

そのため INI は、軽作業には便利な古い道具車のようなものです。小さな用途なら快適ですが、複雑なプロジェクトになると急に力不足になります。

典型的な INI 設定はこんな形です。

[server]
host=127.0.0.1
port=8080

[feature]
enable_cache=true

03 XML: 厳密で安定しているが、とにかく書くのが重い

次は XML です。

古い Java プロジェクトを保守したことがある人や、閉じタグだらけの巨大設定ファイルを見たことがある人にはおなじみでしょう。

XML の長所は次の通りです。

階層構造が明確
コメントが書ける
ルールが厳密
schema と組み合わせると強力な検証ができる

つまり、機械は実際に読み込む前に、型、出現回数、構造制約などをかなり正確に把握できます。安全性の感覚はとても強いです。

一方で、人間にとっての負担も非常に大きいです。

タグが冗長
視覚ノイズが多い
ファイルがすぐ膨らむ
閉じタグを 1 つ落とすだけで全体が壊れやすい

XML は、印鑑が揃った正式な契約書のようなものです。機械には好かれますが、人間の保守はしんどい。最近の新規プロジェクトでは優先されにくくなりましたが、古いシステムや厳密性重視の場面ではまだ完全には消えていません。

同じ設定を XML で書くと、たとえばこうなります。

<config>
  <server>
    <host>127.0.0.1</host>
    <port>8080</port>
  </server>
  <feature>
    <enable_cache>true</enable_cache>
  </feature>
</config>

04 JSON: データ交換の王者だが、手書き設定には少し窮屈

現代開発で JSON を避けて通るのはほぼ不可能です。

JSON に対する典型的な評価はこうです。データ交換形式としては非常に強い。しかし、人間が手で保守する設定ファイルとしてはやや窮屈です。

その強みは次の通りです。

オブジェクトと配列の構造が明確
ネットワーク送信に向く
パーサーが成熟している
Web API やフロントエンド・バックエンド通信に適している

特に XML と並べると、その軽さは非常に目立ちます。同じ構造なら JSON のほうが短く、ネットワーク上でやり取りしやすいことが多いです。

ただし弱点もはっきりしています。標準 JSON はコメントを書けません。

加えて、文法も厳格です。

key は必ずダブルクォート
最後の要素に trailing comma は不可
記号を 1 つ落としただけで壊れる

そのため JSON は API やサービス間通信には最適でも、人間が説明を書きながら頻繁に編集する設定ファイルには必ずしも向きません。

たとえばこんな形です。

{
  "server": {
    "host": "127.0.0.1",
    "port": 8080
  },
  "feature": {
    "enable_cache": true
  }
}

05 YAML: 読みやすいが、インデントと暗黙型変換が怖い

Docker、CI/CD、Kubernetes、自動デプロイに触れたことがあるなら、YAML と無縁ではいられません。

最大の魅力は、見た目のきれいさです。

波括弧や引用符が少ない
インデントで階層を表せる
コメントを書ける
anchor による再利用もできる

そのため第一印象の読みやすさでは、YAML は JSON よりずっと人間向きに感じられることが多いです。

しかし問題もまさにそこにあります。複雑さを隠してしまうため、実運用では次の 2 つの事故が頻発します。

インデント地獄
暗黙の型変換

インデントの問題はわかりやすく、スペースが 1 つ多い・少ないだけで設定が壊れます。さらに厄介なのは暗黙型変換で、普通の文字列に見える値が勝手に真偽値などに解釈されることがあります。

だからこそ YAML は「見た目はいいのに、触ると痛い」形式として語られがちです。人間の可読性は高い一方で、機械の解析は意外に複雑で、パーサー実装差も起こりやすいのです。

同じ設定を YAML で書くと、たとえばこうなります。

server:
  host: 127.0.0.1
  port: 8080

feature:
  enable_cache: true

06 TOML: 可読性と確定性のバランスを取る形式

TOML はしばしば「現代的なバランス解」と見なされます。

魅力は、INI の直感性と JSON の型の明確さをある程度両立している点です。

コメントを書ける
構造がわかりやすい
型が比較的明示的
日付や時刻の表現が自然
YAML のような暗黙型変換の罠が少ない

現代のツールチェーンでも採用例が増えており、Python の pyproject.toml はその代表です。

もちろん万能ではありません。深いネストになるとやや冗長になり、パス形式の表記を何度も書くのが面倒です。ただし中小規模のプロジェクト設定、ツール設定、パッケージ管理設定なら、かなり安定した体験が得られます。

コメントを書けて、意味が明確で、機械にも無理がない形式を探すなら、TOML はかなり有力です。

典型的な TOML はこんな形です。

[server]
host = "127.0.0.1"
port = 8080

[feature]
enable_cache = true

07 `.conf` と Apache 設定: 汎用形式ではなく、ドメイン固有の文法

強調しておきたいのは、.conf を見て「統一された形式」だと思ってはいけない、ということです。

.conf は単に configuration の拡張子であって、中身の書き方はシステムごとの流儀に依存します。つまり .conf は広いカテゴリ名であって、ひとつの標準構文ではありません。

その例として Apache 設定は非常にわかりやすいです。

一部は単純な 1 行ディレクティブ
一部はスコープ付きタグ構造
Web サーバーという特定領域では非常に自然

強みは運用現場との相性の良さで、権限、ルーティング、VirtualHost などを自然に記述できます。ただし自分のエコシステム向けの性格が強く、汎用設定形式としての広がりはあまりありません。

この種の設定は、汎用フォーマットというより、特定ドメイン向けの DSL に近いものです。

たとえば最小の Apache 風設定は次のようになります。

Listen 80

<VirtualHost *:80>
    ServerName example.com
    DocumentRoot "/var/www/html"
</VirtualHost>

08 Protocol Buffers: 工業級の強い型、安全性は高いが敷居も高い

Protocol Buffers は、もはや「手で設定ファイルを書く」というより、正式なデータ定義とシリアライズ方式です。

強みは非常に大きいです。

強い型
明確な schema
前方・後方互換性が高い
バイナリ転送がコンパクト
機械処理が高速

その代わり、導入コストも高いです。

まず .proto を書く必要がある
ツールとコンパイル工程が必要
小さなプロジェクトにはやや重い

そのため「小さなツールの設定をしたいだけ」という用途には向きませんが、大規模システム、RPC、分散システム、長期進化するプロトコルには非常に向いています。

書き方も「構造を定義し、そこからコードを生成する」前提です。

syntax = "proto3";

message ServerConfig {
  string host = 1;
  int32 port = 2;
  bool enable_cache = 3;
}

09 AI Agent時代には、Markdownが再び「設定方式」になるかもしれない

この話の中で最も面白いのは、Markdown まで設定形式の候補に入ってくることです。

従来のプログラマ視点では奇妙に聞こえるかもしれません。Markdown は普通、文書形式だからです。しかし対象が厳密なパーサーではなく、大規模言語モデルや AI Agent になると、この考え方は意外と筋が通っています。

なぜなら、従来のプログラムは厳密な構文と固定フィールドに依存していましたが、大規模モデルは意味、構造、文脈の理解を得意とするからです。彼らにとっては、

見出しは階層
箇条書きは手順
太字は強調
自然言語そのものがルールの器

になります。

つまり設定対象が「融通の利かないパーサー」から「意味を理解できる Agent」へ変わると、Markdown のような人間向けの構造化テキストこそ、より自然な設定手段になり得るのです。

これはとても重要な転換です。従来のソフトウェア時代では、人間が機械に合わせるために設定形式が存在していました。しかし AI の時代には、機械のほうが人間の表現へ寄ってきています。

たとえば Agent へのタスク設定は、こんなふうにそのまま書けてしまいます。

# 任务目标

为新用户写一封欢迎邮件。

## 要求

- 语气友好
- 不超过 150 字
- 提到产品的 3 个核心功能

## 禁止事项

- 不要承诺不存在的功能
- 不要使用夸张营销语气

10 では、どう選べばいいのか

ここまでの話を圧縮すると、だいたい次のように整理できます。

とにかく単純で軽く、平坦な設定がほしい: INI
強い構造、強い検証、旧システム互換がほしい: XML
ネットワーク転送や API 交換が中心: JSON
高い可読性とクラウドネイティブな運用設定がほしい: YAML
現代的で安定した汎用設定体験がほしい: TOML
特定システム内部のルールを書く: .conf / Apache 系 DSL
工業級のプロトコル設計と長期進化を重視する: Protocol Buffers
AI Agent 向けに自然な表現で指示したい: Markdown

つまり「最良の設定ファイル形式」は 1 つではありません。誰のために書くのかで変わります。

人間の保守のためか
機械の高速解析のためか
サービス間通信のためか
あるいは AI Agent の理解と実行のためか

まとめ

設定ファイルの歴史は、結局のところ、人間と機械が「理解コスト」をどちらに載せるかを何度も再配分してきた歴史です。

昔は人間が機械に合わせるしかなかったため、括弧、インデント、引用符、厳密な構文を覚える必要がありました。今は大規模言語モデルや Agent システムが成熟しつつあり、機械のほうが自然な表現を理解し始めています。その結果、「設定」という行為そのものも変わり始めています。

将来、多くの場面で設定ファイルは固定構文ではなく、構造化された意図の記述へと変わっていくかもしれません。それでも当面は、JSON、YAML、TOML、INI、XML が共存し、それぞれ最も向いた役割を担い続けるでしょう。

JSON on KnightLiブログ