bbizinets.life
JSONで改行がそのまま書けない理由|\nエスケープの仕組みと実務での解決策
開発環境

JSONで改行がそのまま書けない理由|\nエスケープの仕組みと実務での解決策

# JSONで改行がそのまま書けない理由|\nエスケープの仕組みと実務での解決策

結論:JSONで改行は「特殊な文字」として扱われる

JSONのテキストを手で書いていて、こんな状況になったことはありませんか?

{
  "body": "1行目
2行目"
}

これをJSONとして読み込もうとすると、エラーになります。改行を入れたいなら \n と書かなければいけない——そうは知っていても、「なぜそうなのか」がわからないままだと、また別の場面で詰まることがあります。

理由はシンプルで、JSONの仕様では文字列の中に生の改行文字(Enterキーで入力される文字)を入れることが禁止されているからです。 改行を表現したいときは \n という「エスケープシーケンス」を使って、「これは改行を意味する記号です」と明示する必要があります。

この記事では、なぜそういうルールになっているのかを説明し、実務で詰まったときの確認方法・根本解決策までをまとめます。JSON改行エラーが出て動かない場合、最短解決は本文を別ファイルに分離することです。詳しくは後述します。

JSON改行エラーを最短で解決する方法

「理由よりまず動かしたい」という方は、先にこちらを読んでいただくと楽になると思います。

JSON改行エラーの最短解決策は、本文をJSONの外に出すことです。具体的には、article.json にはメタデータだけを入れ、本文は body.md という別ファイルに分離する方法です。こうすることで、改行・記号・エスケープを全て気にせず自由に書けるようになります。分離の手順は後述の「実務での根本解決」セクションで詳しく解説します。

JSONの仑5構造から理解したい方は、次のセクションへ進んでください。

JSONで改行が使えない仕様の話

「改行くらい普通に書けばいいのに」と思いますよね? 私も最初はそう感じていました。

JSONの文字列ルール

JSONの仕様(RFC 8259)では、文字列はダブルクォートで囲まれた範囲と定義されています。そしてその範囲内に入れてよい文字について、明確なルールがあります。

ルールの核心は「制御文字はそのまま書いてはいけない」です。

改行文字(ラインフィード、文字コードで U+000A)は「制御文字」に分類されます。制御文字とは、画面に表示される文字ではなく、テキストの動作を制御するための文字のことです。Enterキーで入力される改行も、タブキーで入力されるタブ文字も、どちらも制御文字です。

JSONの設計者たちがこのルールを設けた背景には、JSONがテキストとしてネットワーク越しに送受信されることを前提にしているという理由があります。改行文字がJSONの中に直接入っていると、通信途中でデータが分断されたり、受け取ったプログラムが「どこまでが1つの値か」を正しく解釈できなくなる可能性があります。だから「制御文字は使わない、使いたいなら記号に置き換えて書く」というルールになっています。

なぜ他のフォーマットは改行を書けるのか

Markdownやプレーンテキストは改行をそのまま書けます。HTMLも通常のテキスト内容に改行を含められます。これらと何が違うのかというと、JSONは「データ構造を表現するフォーマット」として設計されているからです。

人間が読む文章を格納するためではなく、プログラム同士がデータをやり取りするための構造を定義するフォーマット——そのため、曖昧さのない厳密な構文ルールが採用されています。改行禁止もその一環です。

`\n`になる仕組み——エスケープとは何か

改行を \n と書く、この \n が「エスケープシーケンス」です。仕組みを理解しておくと、他の場面でも応用が利きます。

エスケープとは「別の表現に置き換えること」

「エスケープ」という言葉は、プログラミングでは「特別な意味を持つ文字を、別の表現に変換すること」を指します。

JSONでは、文字列の中に直接書けない文字を \ (バックスラッシュ)+アルファベットの組み合わせで表現します。

実際の文字 | エスケープ表記 | 意味
--- | --- | ---
改行(Enterキー) | `\n` | ラインフィード
タブ | `\t` | 水平タブ
`"` | `\"` | ダブルクォート
`\` | `\\` | バックスラッシュ自体

\n の n は「newline(改行)」の頭文字です。「バックスラッシュの後にnが来たら、それは改行文字として解釈してください」というルールがJSON仕様で決まっています。

なぜこの記法が必要か

バックスラッシュ1文字と n という2文字の組み合わせを「改行1文字」として扱うことで、JSONファイルそのものはすべて「見た目に現れる文字だけ」で書けるようになります。ファイルをテキストエディタで開いたときに、改行が見えない形で混入していることがなくなります。

これはデータの取り扱いをシンプルにする設計です。JSONを処理するプログラムは「\n を見たら改行に変換する」というルール1つを守るだけでよくなります。

よくあるエラーと原因

JSONに改行を直接書いたとき、どんなエラーが出るのか——実際のエラー文と原因を整理します。

Unexpected token エラー

Node.jsやブラウザのコンソールでJSONをパースしたとき、改行が直接入っていると次のようなエラーが出ます。

SyntaxError: Unexpected token

または

SyntaxError: Bad control character in string literal in JSON at position XX

「position XX」の数字は、エラーが起きた文字の位置(先頭から何文字目か)を示しています。この数字を手がかりにVSCodeで問題箇所を探すことができます。

エスケープミスによるエラー

\n を書いたつもりが、実際には \\n と書いてしまっていたケースもよくあります。

  • \n → 改行として解釈される(正しい)
  • \\n → バックスラッシュ+n という2文字の文字列として解釈される(意図と違う)

逆に、テキストをそのままJSONに流し込んだとき、文章中に \ が含まれていると \\ にエスケープされていないせいでエラーになることもあります。

私が実際にこれで詰まったのは、Claudeが生成したMarkdown本文をそのままJSONのフィールドに埋め込もうとしたときです。本文中にコードブロックの ` や \ 記号が含まれていて、JSONとして不正な文字列になっていました。エラーメッセージを見ても最初はどこが問題かわからず、30分ほど原因を探しました。

VSCodeで確認・修正する方法

JSONファイルに問題がある場合、VSCodeで素早く確認・修正できます。どうやって確認すればいいか、迷ったことはありませんか?

方法① 検索・置換で\nを確認する

VSCodeの検索(Ctrl+H)で、正規表現モードをオンにすると改行文字そのものを検索できます。

検索ボックスに \n と入力して正規表現モード(.* アイコン)をオンにすると、ファイル内の実際の改行位置がハイライトされます。これで「JSONの文字列値の中に生の改行が入っていないか」を確認できます。

もし文字列内に改行が見つかったら、置換ボックスに \\n と入力して置換します。これで生の改行文字が \n というエスケープ表記に変換されます。

検索(正規表現):\n
置換:\\n

ただしこれはファイル全体の改行を置換するため、JSONの構造的な改行(各キーの間の改行)も置換してしまいます。文字列値の内部だけを対象にしたい場合は、より絞り込んだ正規表現が必要です。

方法② JSON整形・バリデーションで確認する

VSCodeのコマンドパレット(Ctrl+Shift+P)から「Format Document」を実行すると、JSONの構文エラーがある場合に赤いエラー表示が出ます。また、VSCodeのステータスバー右下に「JSON」と表示されているときは、JSON構文のバリデーションが自動で走っています。エラーがあると波線が表示されるので、その箇所を確認します。

実務での根本解決:JSONに本文を入れない

エスケープの方法を覚えることは大切ですが、そもそもJSONに長いテキスト本文を入れない設計にするのが、根本的な解決策です。

body.mdに分離する

私がbizinets.lifeの記事管理で実際に採用している方法です。記事のメタデータ(タイトル・slug・seoDescriptionなど)はJSONに入れますが、本文はMarkdownファイル(body.md)として別ファイルに分離します。

articles/
  my-article/
    article.json   ← メタデータのみ
    body.md        ← 本文(改行・記号を自由に書ける)
    eyecatch.svg

article.json の中身はこうなります。

{
  "title": "記事タイトル",
  "slug": "my-article",
  "seoDescription": "120文字以内の説明文"
}

本文は body.md に直接Markdownで書きます。改行も記号も、エスケープを気にせず自由に書けます。

なぜこの設計が有効か

判断基準として整理するとこうです。

  • JSONフィールドの値が1行・短いテキストか → JSONに書いてよい
  • JSONフィールドの値が複数行・Markdownを含むか → 別ファイルに分離する
  • edit_file でJSONを直接修正する予定があるか → 本文は分離した方がエラーが起きにくい

長い本文をJSONに入れると、エスケープミス・edit_file の exact matchエラー・ファイルが重くなることによるパース遅延など、副次的な問題が連鎖しやすくなります。「JSONはメタデータ専用、本文は別ファイル」という設計にするだけで、これらの問題をまとめて回避できます。

よくある質問

Q: JSONではなくJavaScriptで書けば改行を直接入れられますか?

JavaScriptのオブジェクトリテラル(const obj = { key: "value" })では、ES2015以降のテンプレートリテラル(バッククォートで囲む記法)を使えば改行を直接入れられます。ただしJSONとJavaScriptオブジェクトは別物です。JSON.parse() や外部ファイルとしての .json は厳密なJSON仕様に従うため、改行の直接記述はできません。

Q: AIが生成したテキストをJSONに入れるとよくエラーになります。なぜですか?

AIが生成するテキストには改行・ダブルクォート・バックスラッシュが頻繁に含まれます。これらをJSONの文字列値としてそのまま埋め込もうとすると、エスケープが必要な文字が必ず混入します。AI生成テキストをJSONに入れる場合は、プログラム側で JSON.stringify() を通すか、テキスト自体を別ファイルに分離することをおすすめします。

JSONに本文を入れるかどうかは、設計の判断の問題でもあります。
ファイル構成と役割分担の考え方を整理したい方は、

→ bizinets.bizの判断軸ページで整理しています

まとめ

仕様のルールとしては「制御文字は文字列内に直接書けないため、\n というエスケープ表記に置き換える必要がある」です。JSONがデータ構造の厳密な表現を目的としているため、このようなルールになっています。

JSONファイルを直接編集していて edit_file で詰まることがある方には、「Claudeのedit_fileができない原因と解決策」も参考になると思います。JSONエスケープと改行コードの問題がまとめて解説されています。

また、WSL環境でJSONファイルを扱っている場合、改行コードの混在は /mnt/c 配下のファイルシステム構造に起因することがあります。「WSLで/mnt/cが遅い理由と解決策」で背景ごと理解しておくと、同じトラブルを繰り返しにくくなると思います。

今日できる一歩は、自分が扱っているJSONファイルを開いて「文字列の中に複数行のテキストが入っていないか」を確認することです。もしあれば、body.md への分離を検討してみてください。

JSONに本文を入れるかどうかは、設計の判断の問題でもあります。ファイル構成や役割分担の考え方を整理したい方は、bizinets.bizの判断軸ページが参考になると思います。

bizinets.biz

記事を読んで「もっと知りたい」と思ったあなたへ

bizinets.biz では、ビジネスの仕組みづくりを体系的に学べるコンテンツを用意しています。まずは一度、覗いてみてください。

bizinets.biz へ行く →

関連記事