JSON⇔TOML変換の使い方｜テーブル・配列テーブルの対応と限界
公開日：2026年9月29日 更新日：2026年9月15日 運営：シルギア（Analyzegear, Inc.） 対象ツール：JSON⇔TOML変換
TOMLとJSONを相互変換するとき、多くの人がつまずくのは「同じデータのはずなのに書き方がまるで違う」という点です。JSONの入れ子オブジェクトはTOMLでは [table] という見出しに変わり、オブジェクトの配列は [[array]] という繰り返しブロックになります。この記事では、TOMLの成り立ちから、このツールが行う変換の規則、そして「変換できるものと、割り切って文字列にするもの」の境界までを、実際の入出力で確かめながら整理します。すべての変換はブラウザ内で完結し、入力データがサーバーに送られることはありません。
TOMLとは何か、なぜ設定ファイルで使われるか
TOMLは Tom's Obvious, Minimal Language の略で、「人が読み書きしやすい設定ファイル」を目指したフォーマットです。RustのパッケージマネージャCargoが使う Cargo.toml、Pythonの pyproject.toml など、開発ツールの設定で広く採用されています。特徴は、キーと値を key = value の形で1行ずつ並べ、区切りをカンマや波括弧に頼らず改行と見出しで表すところにあります。INIファイルの読みやすさを保ちつつ、入れ子や配列といった構造化データを厳密に表現できるのが強みです。
JSONは機械同士のデータ交換で圧倒的に使われますが、波括弧とカンマが多く、コメントも書けないため、人が手で編集する設定ファイルには向きません。逆にTOMLは人の編集に強い一方、APIのレスポンスのような用途では扱いづらい。だからこそ「JSONで持っているデータをTOMLの設定に落とす」「既存のTOML設定をJSONとして読み込む」という橋渡しが必要になります。
JSONとTOMLの構造の違い
JSONの世界は、オブジェクト（キーと値の集まり）、配列、文字列、数値、真偽値、nullという少数の型でできています。TOMLもキーと値という骨格は同じですが、決定的に違うのは「入れ子を波括弧の深さで表さず、見出し行で表す」点です。JSONで owner の中に name があるとき、TOMLでは [owner] という見出しを書き、その下に name = "太郎" と並べます。さらに深い入れ子は [a.b] のようにドットでつないだ見出しになります。
もう一つ重要なのは、TOMLのルート（最上位）は必ずテーブル、つまりキーと値の集まりでなければならないことです。JSONは最上位に配列 [1, 2] や単一の値 5 を置けますが、これらはTOMLに直接置き場所がありません。そのため本ツールでJSON→TOML変換を行うとき、最上位が配列や単独の値だとエラーになります。変換したいときは、いったんオブジェクトで包んでキーを与えてください。
テーブル・配列テーブル・インラインテーブルの変換規則
JSON→TOMLでは、値の種類を見て置き場所を振り分けます。規則は次の通りです。
- スカラーと最上位の並び：文字列・数値・真偽値、そしてスカラーだけの配列は、見出しの前に key = value として並びます。たとえば ports: [80, 443] は ports = [80, 443] というインライン配列になります。
- 入れ子オブジェクト→[table]：オブジェクトは [owner] のような見出しセクションに変換され、深い入れ子は [owner.address] とドットでつながります。
- オブジェクトの配列→[[array]]：全要素がオブジェクトの配列は、テーブル配列として [[servers]] というブロックが要素数だけ繰り返されます。
TOML→JSONの向きでは自前パーサが働き、基本文字列 "..."・リテラル文字列 '...'・複数行文字列、10進および 0x・0o・0b の整数（桁区切りのアンダースコア可）、浮動小数、真偽値、多行・入れ子の配列、テーブルとネスト見出し、波括弧のインラインテーブル { x = 1 }、ドットキー a.b = v、そして # コメントまで解析します。閉じ忘れやキー重複があると、行番号付きのメッセージで原因を知らせます。
変換例で確かめる、往復しても構造は保たれる
具体例として {"title":"x","owner":{"name":"太郎"},"ports":[80,443]} を変換してみます。JSON→TOMLの結果は次のようになります。
- title = "x"
- ports = [80, 443]
- （空行）[owner] の下に name = "太郎"
ここでこの出力をもう一度TOML→JSONに通すと、title、ports（80と443の配列）、owner（nameが太郎）というキーと値の対応が完全に復元されます。つまりデータの構造（どのキーにどの値がぶら下がるか）は往復しても保持されます。ただし元のJSONでは owner が2番目、ports が3番目でしたが、TOMLでは見出しより前にスカラーを書く仕様のため、往復後は ports が先、owner が後ろへ移動します。順番は変わっても中身の対応は崩れない、と理解しておくと安心です。
対応範囲の限界と割り切り
変換には、型の対応がつかないための割り切りがあります。もっとも大きいのが日時と特殊な数値です。
- 日時は文字列で保持：TOMLにはオフセット付き日時・ローカル日時・日付・時刻という日時型がありますが、JSONに相当する型が無いため、TOML→JSONでは文字列になります。たとえば date = 1979-05-27T07:32:00Z は "1979-05-27T07:32:00Z" という文字列です。日付だけ・時刻だけ・スペース区切りの日時も同様に文字列として読み取ります。
- inf・nanは文字列で保持：TOMLの浮動小数 inf や nan もJSONで表せないため、"inf"・"nan" という文字列になります。
- JSONのnullは空文字列に：逆向きのJSON→TOMLでは、TOMLに null がないため null を空文字列 "" に置き換えます。nullを厳密に区別したい場合は、変換前に扱いを決めておいてください。
これらは、多くの設定ファイルを扱う実用上は問題になりにくい割り切りですが、日時をそのまま日時として再利用したい、数値のinfを保ちたい、といった場面では変換後の確認が欠かせません。ごく特殊な記法や規格の細部までは網羅していない点も踏まえ、複雑な設定は結果を目視で確かめてから使うのが安全です。
使い方の手順と、つまずきやすい注意点
操作は次の流れです。まず「JSON → TOML」か「TOML → JSON」で方向を選び、入力欄に変換したいテキストを貼り付けます。入力と同時に自動変換され、「変換する」ボタンでも実行できます。TOML→JSONではインデント幅（スペース2/4・タブ・最小化の1行）を選べるので、用途に合わせて整形できます。結果は「結果をコピー」でクリップボードへ、「ダウンロード」で .toml / .json ファイルとして保存できます。仕組みがつかみにくいときは「サンプルを入れる」で、テーブル・テーブル配列・配列を含む例を読み込んで挙動を確かめるのが近道です。
つまずきやすいのは次の3点です。第一に、JSON→TOMLで最上位が配列や単一値だとエラーになること。オブジェクトで包んで対処します。第二に、往復でキーの順番が変わりうること。中身の対応は保たれるので、差分を取るときは順序ではなく構造で比べます。第三に、日時やinf/nanが文字列化される点。設定を戻すときにクォートの有無が変わっていないか確認しましょう。変換に失敗したときは、行番号付きのエラーメッセージが引用符やカンマの閉じ忘れ、キーの重複といった原因を指し示すので、そこを起点に直すと早く解決します。