VSCodeのJSON整形が効かない時の解決方法｜3つのチェック完全版

運営：Next Life運営局（株式会社Rush up）　会社概要｜編集方針

VSCodeでJSONを整形したいだけなのに、ショートカットも設定も試したのに「反応しない」「自動整形だけ効かない」「1行JSONが読めない」といった状態で止まっていないでしょうか。多くの解説は、Shift+Alt+Fなどのコード整形ショートカットやformatOnSaveの有効化だけを紹介して終わります。しかし現場で問題になるのは、その一歩先です。拡張機能どうしの競合でJSONだけ整形されなかったり、ワークスペース設定がユーザー設定を上書きして「自分のPCだけ結果が違う」状態になったり、Prettier導入でレビューや本番設定が崩れるリスクです。
本記事では、VSCode標準機能でのJSON整形方法から、自動整形の安全な設定、1行JSONの整形とminify、JSONを表形式に近づけて読む実務的なアプローチまでを一気通貫で整理します。さらに、サクラエディタやEmEditor、Excel、Visual Studioとの使い分け、中小企業のWeb・SNS担当が避けるべき「3つの事故」と、チームで整形ルールを標準化するチェックリストまで網羅します。ここまで押さえておけば、「VSCode JSON整形」で二度と迷子にならず、JSONを触るたびに発生していた無駄な手戻りとリスクを確実に減らせます。

VSCodeでJSONを一発で整形する基本ワザとショートカットを最速でマスターする

「APIのレスポンスが1行でギッシリ」「LINEや広告の設定ファイルがぐちゃぐちゃ」。そんなとき、ここで紹介する3ステップだけ押さえておくと、現場のストレスが一気に下がります。

JSONファイルの開き方と「言語モードJSON」へ切り替える手順

まず、整形が効かない原因のひとつが「VSCodeがJSONだと認識していない」ケースです。見た目がそれっぽくても、言語モードが違うとフォーマット機能が動きません。

1. VSCodeでファイルを開く

   • メニューから「ファイル → 開く」で目的のファイルを選びます。
   • 拡張子が.jsonでない設定ファイル（例: .txtや.conf）もそのまま開きます。

2. 言語モードを確認

   • 画面右下のステータスバーに表示される「Plain Text」「HTML」などの部分をクリックします。
   • 一覧から「JSON」または「JSON with Comments」を選択します。

3. 自動判別させたい場合

   • 拡張子を.jsonに変更すると、多くのケースで自動的にJSONとして認識されます。
   • どうしても拡張子を変えられない設定ファイルは、都度この手順で切り替える方が安全です。

現場では、この言語モードを合わせるだけで「整形できない」という相談の3割は解決している印象があります。

ドキュメント全体を整形する操作方法やショートカットで作業を一気に加速させるコツ

JSONとして認識できたら、次は一発整形です。Windowsを前提にしますが、MacやLinuxでもほぼ同じ感覚で使えます。

全体整形の基本操作

• 画面上でファイルを開いた状態で

  • 右クリック → 「ドキュメントのフォーマット」で整形
  • またはメニュー「表示 → コマンドパレット」で「フォーマット」を検索して実行

キーボードショートカット（Windows）

• ドキュメント全体を整形

  • Shift + Alt + F

このショートカットがスムーズに打てるようになると、JSONの確認スピードが体感で2〜3倍に上がります。

よく使う操作なので、ショートカットの整理もおすすめです。

操作内容	ショートカット (Windows)	備考
ドキュメント全体を整形	Shift + Alt + F	JSON以外の言語でも有効
コマンドパレットを開く	Ctrl + Shift + P	「format」入力で候補を表示
保存	Ctrl + S	formatOnSave設定時は整形も実行

これらは「settings」で後からカスタマイズできますが、まずは標準のまま手に覚えさせた方が、チーム内で操作を共有しやすくなります。

選択範囲だけをピンポイントでJSON整形したい時に使える裏ワザフォーマット

運用の現場では、「JSON全体」ではなく「一部だけ」触りたい場面がよくあります。たとえば、巨大な設定ファイルの中の一部分だけ改行やインデントが崩れているケースです。

選択範囲だけ整形する基本手順

1. 整形したい範囲をドラッグで選択

   • オブジェクトや配列の{から}までを丁寧に選ぶと、構造がきれいに揃います。

2. 選択した範囲に対してフォーマットを実行

   • 右クリック → 「選択範囲のフォーマット」
   • または Ctrl + K → すぐに Ctrl + F を続けて押す（2段階ショートカット）

3. 他の部分を壊さないか軽く確認

   • 差分ビューやGitの変更履歴で、余計な行が動いていないかをチェックします。

全体整形と部分整形の使い分け

シーン	おすすめ	理由
初めて開く1行JSON	全体整形	まずは構造全体を一気に把握したいから
既存プロジェクトの一部修正	選択範囲の整形	他メンバーのインデントルールを崩さない
チームでPrettierを導入済み	ルールに合わせる	defaultFormatterと競合しないようにする

私の視点で言いますと、レビューの現場で事故が起きやすいのは「ほんの1行直したつもりが、全体整形で数百行の差分が出てしまった」ケースです。部分整形のショートカットを押さえておくと、余計な差分を出さずにJSONをきれいに保てるようになります。VSCodeのフォーマット機能と、後で導入するPrettierなどの拡張をどう組み合わせるかが、運用効率と安全性を大きく左右します。

整形できないや反応しないVSCodeのJSONが動かない時のチェックポイント大全

JSONをきれいにそろえて一息つきたいのに、ショートカットを押しても無反応。現場で一番ストレスが高いのがこの瞬間です。ここでは「5分で原因を突き止めて復旧する」ことだけに絞って整理します。

JSON整形が突然効かなくなった時にまず確認したい3つの鉄板設定ポイント

多くの現場で、原因はこの3つに集約されます。まずは設定を疑う方が速いです。

1. 言語モードがJSONになっているか
2. 保存時自動整形が無効化されていないか
3. 使用フォーマッターがおかしな状態になっていないか

ポイントを表にまとめると、次のようになります。

チェック項目	確認場所	典型的な症状
言語モード	右下の言語表示	整形してもインデントが変わらない
formatOnSave	設定画面「テキストエディター」>「フォーマット」	保存しても何も変わらない
defaultFormatter	設定画面「拡張機能」>「フォーマット」	人によって見た目がバラバラ

特に、言語モードが「JSON」ではなく「プレーンテキスト」や「JavaScript」になっているケースは本当に多いです。右下の表示をクリックして「JSON」に切り替えてから、再度フォーマットショートカット(Windowsなら Shift+Alt+F)を試してみてください。

保存時自動整形が効かない場合は、設定で「Editor: Format On Save」がオフになっていないかを確認します。JSONだけ自動整形したい場合は、settings.jsonにjsonセクションを切るパターンがよく使われますが、書き間違いがあると全体が無効になるので要注意です。

拡張機能が悪さをしてJSONだけ整形されない時のスマートな切り分け術

「昨日までは動いていたのに、今日から急におかしい」という時は、拡張機能の更新や追加が犯人であることが多いです。私の視点で言いますと、ここを雑に扱うとトラブルが長期化します。

手早く切り分ける手順は次の通りです。

• 一時的にすべてのフォーマッター系拡張(Prettierなど)を無効化する

• VSCode標準機能だけで整形を試す

• 問題なければ、拡張を1つずつ有効化して再テストする

これで「どの拡張がJSON整形に影響しているか」を特定できます。特に、Prettierと別のフォーマッターが両方インストールされていると、editor.defaultFormatterの取り合いになり、ファイルごとに挙動が変わることがあります。

さらに一歩踏み込むなら、コマンドパレットから「フォーマットドキュメント(…でフォーマット)」を実行して、どのフォーマッターが候補に出ているかを確認すると、競合の構図が見えやすくなります。「このプロジェクトではどれを使うか」をチームで固定しておくと、後から入ったメンバーによる設定事故を防ぎやすくなります。

ワークスペース設定とユーザー設定の“優先度の罠”でハマる典型パターンを見破る

中小企業の現場で特に多いのが、「自分の設定を変えているのに、プロジェクト側の設定に上書きされている」パターンです。VSCodeには設定の優先度があり、ざっくり言うと次の順で強く効きます。

強さ	設定の種類	影響範囲
強	ワークスペース設定(.vscode/settings.json)	プロジェクトフォルダ内だけ
中	ユーザー設定	自分のVSCode全体
弱	デフォルト設定	何も上書きされていない部分

よくあるのは、ワークスペース側に「JSONはこのフォーマッターを使う」「formatOnSaveはオフ」という設定が書かれていて、ユーザー側でいくらオンオフしても結果が変わらないケースです。

見破るコツは2つあります。

• 設定画面で項目右側のアイコンを確認し、どのレベルの設定が効いているかを見る

• プロジェクト直下の.vscode/settings.jsonを開き、jsonセクションやformat関連を目視で確認する

ワークスペース設定を不用意に削除すると、他のメンバーの作業にも影響します。まずは内容を読み取り、「JSONだけ特定のフォーマッターに固定している理由」がないかをチームで確認してから変更するのが安全です。

整形が効かない時は、焦ってPCやエディタを疑いがちですが、多くは「設定」「拡張」「優先度」のどれか1つで説明がつきます。上の3ステップを順番にたどれば、ほとんどのケースは現場でも5分以内に復旧できます。

保存時自動で整形しJSONをミスから守るVSCode設定や考え方

JSONを手で改行しているうちは、どれだけ注意してもヒューマンエラーは消えません。保存した瞬間にきれいに揃う環境を一度作ると、API設定やタグ埋め込みの事故が目に見えて減ります。ここでは「今すぐ再現できる」手順から「チームで破綻しない」考え方までまとめます。

VSCodeの設定画面から保存時自動整形をオンにするまでのステップバイステップ

まずは標準機能だけで自動整形を有効化します。WindowsでもMacでも流れは共通です。

1. 画面左下の歯車アイコンから「設定」を開きます
2. 検索窓に format と入力します
3. 「Format On Save」にチェックを入れます
4. 同じく「Editor: Default Formatter」で使用するフォーマッターを確認します（空欄ならVSCode標準）
5. JSONファイルを開き、1行を少し崩して上書き保存し、自動で整形されるか確認します

うまく動かない場合は、拡張機能のPrettierなどが defaultFormatter を上書きしているケースが多いです。この場合、settingsの「テキストエディター > フォーマット」でどの拡張が選ばれているかを必ずチェックします。

JSONだけ自動整形にするか全ファイル対象にするか迷った時の判断基準

「全部のファイルで自動整形するか」「JSONだけに限定するか」は、現場のリスクとレビュー体制で決めます。迷った時は、次の比較が目安になります。

パターン	メリット	デメリット	向いている現場
JSONだけ自動整形	API設定やconfigだけ安全に保護できる	言語ごとにsettingsを分ける手間がある	非エンジニアもJSONを触るチーム
全ファイル自動整形	コード全体が一定のフォーマットで揃う	既存コードのdiffが激増しやすい	エンジニア比率が高く、lintルールが明確なチーム

JSONだけ自動整形したい場合は、設定画面右上の「settings.jsonを開く」から、言語ごとの設定ブロックを使います。jsonセクションにだけ “editor.formatOnSave”: true を指定し、他の言語はオフのままにしておくと、既存プロジェクトのdiff爆発を防げます。

私の視点で言いますと、まずはJSONだけを自動整形にして「事故を減らす感覚」をつかんでから、必要に応じて対象言語を増やしたほうが、現場のストレスは明らかに小さいです。

自動整形を入れる前に決めておきたい「チーム内整形ルール」の作り方

実務で一番問題になるのは、「誰が保存しても同じ形に整形されるかどうか」です。API仕様よりも、フォーマッター競合でレビューが崩壊しているケースをよく見かけます。導入前に、最低でも次の3点はチームで揃えてください。

• フォーマッターを一つに決める

  VSCode標準かPrettierかを決め、「JSONは必ずこのフォーマッター」と明文化します。複数インストールしても、defaultFormatterは一つに固定します。

• どこで設定するかを統一する

  「ユーザー設定で変えてよい範囲」「ワークスペース設定で固定する項目」を分けます。JSONの自動整形やインデント幅などは、ワークスペース側のsettingsでリポジトリに含めると安全です。

• 設定ファイルをドキュメントとして扱う

  .vscode/settings.jsonに、整形方針のコメントやREADMEへのリンクを残します。新メンバーが入った時に、「なぜこの設定なのか」が1分で分かる状態にしておくと、独自にフォーマットを変えられるリスクが減ります。

特に、中小企業のWebやSNS担当がLINEのメッセージテンプレートや計測タグの設定JSONを触る場合、1つのカンマ抜けで配信が止まる世界です。自動整形は単なる見た目調整ではなく、「設定ミスを未然に消すセーフティネット」として設計しておくことが、後から効いてきます。

標準機能かPrettierかで迷った時のVSCodeのJSON整形フォーマッター賢い選び方

「とりあえずきれいになればOK」と選んだフォーマッターが、数カ月後にレビュー崩壊や本番事故の火種になるケースは少なくありません。ここでは、JSON整形で迷子にならないための“現場基準”をまとめます。

標準フォーマッターやPrettierの違いを一目でつかむリアル比較ポイント

最初に押さえたいのは、「どちらが正しいか」より「チームにとってどちらが安全か」です。代表的なポイントを整理します。

観点	VSCode標準フォーマッター	Prettier拡張
対応範囲	JSONや一部言語中心	JSONに加えJS/TS/HTML/CSSなど広範囲
設定の複雑さ	少ない settings だけで完結	設定項目が多く、defaultFormatter指定が必須級
チームでの再現性	VSCodeが同じならほぼ同一	バージョンや設定差で結果が変わりやすい
目的	必要最低限の整形	プロジェクト全体のコードスタイル統一
想定ユーザー	非エンジニア含む混在チーム	開発ルールが固まったエンジニアチーム

単発でJSONファイルだけ整形したい担当者（LINE設定や計測タグのdata確認など）が多い環境なら、標準フォーマッターで十分なケースが大半です。
逆に、フロントエンド開発者が多く、既にpackage.jsonやリポジトリでPrettier設定を共有しているなら、JSONもPrettierに寄せた方がレビューがスムーズになります。

JSON用にPrettierを導入する時にハマらないための設定やdefaultFormatterの押さえどころ

Prettierを入れたのに「JSONだけ意図しない整形になる」「保存時に整形されない」と相談される場面では、ほぼ毎回同じ落とし穴があります。

押さえておきたいポイントは次の3つです。

• VSCode側で「どの言語にどのフォーマッターを使うか」をsettingsで明示する

• JSONだけPrettierにするか、全言語Prettierにするかを最初に決める

• formatOnSaveとdefaultFormatterの組み合わせをチームで共有する

代表的な設定パターンのイメージを挙げます（実際にはsettingsで調整します）。

方針	メリット	リスク
JSONは標準、コードはPrettier	設定ファイルの事故が起きにくい	言語ごとの整形結果が微妙に違う
全言語Prettier	スタイル統一が楽	誤設定で設定JSONも大きく書き換わる
JSONだけPrettier	APIスキーマなどをコードと揃えやすい	他PCで標準フォーマッターに戻ると差分多発

私の視点で言いますと、「とりあえず全部Prettier」は中小企業の混在チームほど避けた方が安全です。まずはJSONは標準フォーマッター、将来Prettierに寄せるならプロジェクト単位で合意を取る、という二段階で進めるとトラブルが激減します。

フォーマッターを増やしすぎて誰のPCでも結果が変わる“カオス現場”を回避する方法

実務で一番やっかいなのは、「自分のVSCodeではきれいでも、他の人が保存した瞬間に差分の山ができる」状態です。これは、複数の拡張フォーマッターが競合し、Code側がどれを使うか判断しきれていない時に起こります。

カオスを防ぐためのチェックリストを用意しました。

• フォーマッター拡張を必要最小限にする

  • JSON関連はPrettierと標準に絞り、類似拡張はアンインストールか無効化

• 言語ごとのdefaultFormatterを明文化する

  • JSON、JavaScript、TypeScriptなど主要言語だけでも一覧にしておく

• formatOnSaveの有無をプロジェクト単位で固定する

  • 「このワークスペースではオン、それ以外はオフ」のルールを決める

• settingsの優先度を理解して運用する

  • ユーザー設定よりワークスペース設定を優先し、個人差を吸収する

特に、共有PCで誰かが独自に拡張を追加したり、Shiftなどショートカットでその場しのぎの整形方法を覚えてしまうと、「誰がどの設定で保存したか」自体がブラックボックスになりがちです。

現場で安定させたいなら、次のような運用をおすすめします。

• プロジェクトのREADMEに「使うフォーマッター」と「インストール必須拡張」を明記

• 最初にVSCodeをセットアップする担当が、settingsと拡張リストをテンプレ化

• 新メンバーは、そのテンプレを取り込んでから個人カスタマイズを行う

ここまで整理しておくと、「整形できない」「改行がおかしい」といった相談は、ほぼ設定レベルの話に分解できます。フォーマッター選びを“好み”で終わらせず、チームの安全装置として設計しておくことが、JSONを扱う現場では何より効いてきます。

1行のJSONをきれいに整形したい時や逆に1行へminifyしたい時の実務テクニック

「APIレスポンスが1行の壁」になっている現場はとても多いです。ここを5分で突破できるかどうかで、トラブル調査のスピードも変わります。

APIレスポンスなど1行のJSONをVSCodeで瞬時に読みやすく整形するシンプル手順

APIテストツールやjQueryのajaxログからコピペしたJSONは、だいたい1行で詰まっています。VSCodeなら追加の拡張なしで一瞬で整形できます。

1. 1行JSONをファイルに貼り付ける（拡張子は.jsonがおすすめ）
2. 右下の言語モードが「JSON」になっているか確認
   なっていなければクリックして「JSON」を選択
3. 編集画面で全体を選択（Ctrl+A）
4. フォーマット実行
   • ショートカット: Shift+Alt+F（Windows）
   • 右クリック →「ドキュメントのフォーマット」

整形されない場合は、以下の順で確認すると早いです。

• 別のフォーマッターがdefaultFormatterに設定されていないか

• settingsで「フォーマット無効」にしていないか

• JSONが実は壊れていて、最後のカンマやクォートが欠けていないか

特にAPIのエラーメッセージは、JSONの途中にHTMLやtextが混ざることがあり、そこがバグの温床になります。

JSONを1行に圧縮するminifyのスマートなやり方や壊してはいけないポイント

逆に「タグに埋め込むために1行化したい」「ログ出力を軽くしたい」という場面ではminifyが必要です。現場では次の2パターンを使い分けています。

上から順に試すと安全です。

• 標準フォーマットでminify

  1. 一度きれいに整形
  2. 右下の「スペース/タブ」をクリックし、インデント幅を小さくする
  3. すべての改行を削除（Ctrl+H → 改行を空文字に置換）

• 拡張機能（Prettierなど）のminify機能

  • PrettierのsettingsでprintWidthを極端に大きくし、ほぼ1行化する
  • JSON専用にワークスペースsettingsで調整し、他言語のCodeには影響させない

壊してはいけないポイントは「中身を変えないこと」です。スペースや改行は消しても構いませんが、以下は絶対に触らないようにします。

• クォートの種類（"と'を勝手に変更しない）

• 数値を文字列に変える、nullを空文字にする

• 末尾のカンマを勝手につける/消す拡張を混在させる

私の視点で言いますと、LINEの設定や計測タグのscriptに埋め込む時に、ここをミスって計測が一晩止まるケースを何度も見ています。

正規表現や簡易ツールを組み合わせて整形と1行化を自由に行き来するワークフロー

「読む時は整形」「貼る時は1行」の往復を、手作業でやると必ずどこかで事故が起きます。再現性のあるワークフローを決めておくと、安全度が一気に上がります。

代表的なフローを表にまとめます。

シーン	おすすめ手順	注意するsettings/拡張
APIレスポンスを読む	貼る → 言語モードJSON → Shift+Alt+F	defaultFormatterをJSON向けに固定
scriptに埋め込む	まず整形 → 内容チェック → 正規表現で改行削除	文字コードとエスケープを確認
ログを軽くしたい	フォーマット → 自動テストで検証 → minify	Prettierなどのバージョンをチームで統一

正規表現での往復も便利です。

• 整形 → 1行化

  • 検索: r?ns*
  • 置換: 空文字

• 1行 → 整形

  • 1行を貼る → Shift+Alt+Fでフォーマット

ポイントは「必ず整形 → 内容チェック → minify」の順番を固定することです。先にminifyしてしまうと、ミスが見えずに本番へ流れ込みます。

小規模チームほど、誰かが入れた拡張やsettingsの違いでフォーマット結果が変わりがちです。JSONだけは「このフォーマッターとこのワークフローで扱う」と決めておくと、トラブル対応のスピードと安心感がガラッと変わります。

JSONを表形式で見たい人のためのVSCode活用術や他ツールとのおいしい使い分け

VSCodeだけでJSONを“表っぽく”読みやすくするための実践アプローチ

「APIレスポンスをExcelみたいにパッと眺めたいのに…」という場面はよく起きます。専用ツールを入れる前に、まずは手元のエディタでどこまで寄せられるかを押さえておくと、現場のスピードが一段変わります。

VSCodeだけで“表っぽく”読むときの基本は、縦の揃え方と階層の見せ方です。おすすめの設定と操作は次の通りです。

• 折りたたみ機能で階層をブロック化

  • オブジェクトや配列の行頭にある三角マークで、不要な階層を閉じる

• エディタを縦に分割し、元データと抽出用ファイルを2画面表示

• 検索で "id": や "name": をハイライトし、横並びの“列”として読む

• 必要なキーだけを複数選択（Alt+ドラッグ）して、一気にコピペ

この4つを組み合わせると、「テーブルっぽく項目ごとに目で追う」ことができるようになります。私の視点で言いますと、非エンジニアの担当者には、まずこの“なんちゃって表ビュー”を教えると、JSONへの抵抗感がかなり下がります。

JSON整形に強いサクラエディタやEmEditorやExcelの得意分野とVSCodeとの棲み分け

どのツールも万能ではないので、「何をするときにどれを出すか」を先に決めておくと迷いません。代表的な組み合わせを整理すると、次のような棲み分けになります。

ツール	得意な用途	苦手・注意ポイント
VSCode	整形、差分確認、Git連携、拡張機能	表形式の集計・ソート
サクラエディタ	軽い整形、マクロで単純変換	JSONバリデーション、拡張性
EmEditor	大容量ログ、CSVとJSONの混在解析	チーム設定の共有
Excel	単純なJSONを表として確認・フィルタ	階層が深いJSON、構造崩れリスク

サクラエディタやEmEditorは、「とにかく軽く開いて眺めたい」「ログとしてガッと検索したい」ときに強い選択肢です。一方で、設定ファイルの変更やAPI仕様のレビューはVSCode側に寄せると、Git履歴やレビューコメントとセットで扱えるため、後戻りしやすくなります。

Excelは「1階層目だけを表にして、ざっくり一覧化したい」ときには便利ですが、入れ子構造が深くなると一気に破綻します。運用現場では、Excelは“見るだけ”、編集はVSCodeと線引きしておくのがおすすめです。

VisualStudioなど他エディタからVSCodeへ乗り換える時に押さえたいチェックポイント

もともとVisual Studioや他の統合開発環境を使っているチームがエディタを切り替えるときは、「JSONの扱い方」だけ先に揃えておくと移行がスムーズです。最低限チェックしておきたいのは次の3点です。

• 整形ルールの統一

  • インデント幅（2か4）、ダブルクォートかシングルか、末尾カンマの扱い

• フォーマッターの責任分担

  • VSCode標準か、Prettierなど拡張かをJSONだけでも明文化

• プロジェクト単位の設定ファイルの場所

  • .vscode/settings.json にJSON用設定をまとめ、個人設定との差を最小化

以前からVisual Studioで整形していた現場では、「誰がどのツールで整えたか」が混在し、レビュー時に差分がノイズだらけになるケースをよく見ます。移行のタイミングで、“JSONはVSCodeで整形してからコミットする”という一文をチーム規約に入れるだけでも、後々のトラブルはかなり減らせます。

中小企業のWebやSNS担当がVSCodeでJSONを触るときに避けたい「3つの事故」

「ちょっと設定をいじっただけ」のつもりが、翌朝アクセスがゼロ、LINEの配信が止まる…。現場では、JSONの1文字ミスが売上や問い合わせに直結します。まずは、押さえておきたい3つの典型事故を整理します。

事故パターン	起きる場面	主な原因	最低限の防ぎ方
設定停止系	LINEやタグ配信が止まる	JSONの構文エラーや余計な整形	テスト環境＋整形前後の差分確認
レビュー崩壊系	PRや承認が進まない	フォーマッター乱立	プロジェクトごとのformatter固定
設定汚染系	他案件まで影響	共有PCのVSCode設定変更	ワークスペース設定の徹底

設定JSONをうっかり書き換えてLINEや計測タグが止まる“よくある悲劇”と防ぎ方

よくあるのは、LINE公式アカウントやタグマネージャのWebhook設定をVSCodeで開き、整形した瞬間に余計な改行やカンマを混入させてしまうパターンです。テスト送信をしないまま本番反映し、翌日になって「通知が一件も来ていない」と気づくケースは珍しくありません。

防ぐポイントは次の3つです。

• 本番用の設定ファイルは必ずバックアップコピーを取ってから編集

• 整形前後のdiffをGitや拡張機能で1文字単位で比較

• 反映前に、最低1回はテスト送信やテスト計測を実行

私の視点で言いますと、特に非エンジニアが触る設定ほど、「どのフォーマッターで整形したか」をメモしておくことで、トラブル時の切り分け速度が大きく変わります。

フォーマッター変更でレビューが崩壊するケースとその前に打てる予防線

Prettierや標準機能など複数のフォーマッターが混在すると、コードレビュー画面がほぼ全行差分になり、肝心のロジック変更が埋もれます。原因は単純で、開発者ごとにVSCodeのdefaultFormatterやインデント設定がバラバラなことが多いです。

予防線として、最低限ここだけは揃えます。

• プロジェクト単位で「公式フォーマッター」を1つ決める

  (例: JSONは標準フォーマッター、JavaScriptはPrettier)

• .vscode/settings.jsonにformatterとタブ幅を明記

• 「保存時自動整形」を入れる前に、チーム全員の設定を一度棚卸し

項目	個人で好きに決める	チームで固定すべき
カラーテーマ	○
フォントサイズ	○
JSONフォーマッター		○
インデント幅		○

共有PCやチーム環境でVSCode設定をいじる前に必ず決めておきたいルール集

共有PCでありがちなのが、「誰かがユーザー設定をいじった結果、他案件の整形ルールまで一括変更される」事故です。ワークスペース設定とユーザー設定の優先度を理解せずに触ると、JSONだけ意図しないフォーマットになり、「昨日まで動いていたのに」が発生します。

共有環境では、次のようなルールを事前に決めておくと安全です。

• VSCodeの設定変更は原則ワークスペース側だけで行う

• settings.jsonを直接編集する人を役割として明確化

• 変更した設定は、READMEや社内Wikiに日時と理由を記録

• 共有PCでは、怪しい動作が出たら一度拡張機能を全部オフにして検証

この3つの事故を押さえておくだけでも、「JSONを整形したら、なぜかビジネスが止まった」という高コストなトラブルはかなり減らせます。整形のテクニックと同じくらい、「どこまでいじってよいか」をチームで決めておくことが、中小企業の現場では強い武器になります。

JSON整形を「一人のスキル」から「チームの標準」へ進化させるためのチェックリスト

JSONの整形は、上手い人が1人いれば回る作業に見えて、実はチーム全体の事故率を左右する「インフラ設定」に近いポジションです。ここでは、現場でその差がはっきり出るポイントをチェックリスト化します。

プロジェクト単位で決めておくべき整形ポリシーやVSCode設定のチェック項目

まず、最低限そろえておきたい項目を一覧にします。

• どのフォーマッターを使うか（標準かPrettierか）

• 保存時自動整形をオンにするか、手動だけにするか

• JSONだけ特別ルールにするか、他言語とそろえるか

• 設定の変更範囲を「ユーザー」か「ワークスペース」に限定するか

• 本番用設定ファイルを誰が触ってよいかの権限ルール

次のような表にして、プロジェクト開始時に合意しておくと混乱が激減します。

項目	推奨レベル	メモ例
フォーマッター	Prettier / 標準のどちらかに統一	JSONも同じにする
自動整形	JSONのみオン	code-settingsで制御
設定の適用スコープ	原則ワークスペース	個人設定での上書き禁止
本番系設定ファイルの編集	担当者＋レビュアの2名に限定	PRレビューを必須にする

チーム全員が同じsettingsファイルを共有し、「このプロジェクトではこのrules」という状態にしておくことが、細かなstyle議論を減らし、レビューを内容チェックに集中させるコツです。

新メンバーが入っても迷子にならないJSON整形ドキュメントの作り方のヒント

新しい担当者が参加した瞬間に、整形ルールが崩れるケースはよくあります。原因の多くは「ローカルPCにだけ正解が入っていて、言語化されていない」ことです。

そこで、次の3セットを1つのドキュメントとしてまとめておくと効果的です。

• スクリーンショット付き手順書

  • VSCodeの設定画面でどこを触るか
  • JSONファイルで実際に整形するまでの流れ

• 設定ファイルサンプル

  • .vscode/settings.jsonのサンプル
  • 使ってよい拡張機能リスト（Prettierなど）

• NG例と理由

  • ユーザー設定でdefaultFormatterを勝手に変えない
  • 他の拡張機能でJSONを自動整形しない

特にNG例は、実際に起きた事故ベースで書くと腹落ちしやすくなります。「この変更でLINE配信が止まった」「計測タグのdataが欠落した」といったレベルまで落とし込むと、形式的なルールではなく、自分ごととして受け取ってもらえます。

Rushupの支援現場で重視している「運用効率や安全性」の視点から見たJSON整形のツボ

私の視点で言いますと、JSON整形で最も効くのは「きれいにする技術」ではなく「壊さない仕組み」をつくることです。具体的には次の3点を徹底します。

• 標準機能で動く状態をまず担保する

  • 拡張機能が増える前に、Shift+Alt+Fで正しく整形できるかを確認
  • 動かない場合は、ワークスペース設定を一度リセットしてから検証

• 設定変更の影響範囲を明示する

  • settings.jsonを編集する時は、「このプロジェクトだけ」「全プロジェクトに影響」のどちらかをコメントで明記
  • Pull Requestのテンプレートに「整形ルールの変更有無」を追加

• 非エンジニアが触るJSONを特に守る

  • LINE公式アカウント、広告タグ、SaaSのWebhook設定など、1文字のミスで売上に直結する部分は、
    • 専用フォルダ
    • 固定フォーマッター
    • レビュー必須
      の3点セットで管理

現場では「誰がどの設定で整形したか」が見えない状態が、トラブルの温床になります。整形のHow toを共有するだけでなく、どこまでを個人の自由にして、どこからをチームの標準にするかを決めてしまうことが、結果的に運用効率と安全性を両立させる一番の近道になります。

この記事を書いた理由

著者 – 伊藤 和則（nextlife事業部 責任者）

本記事は生成AIによる自動生成ではなく、業界歴15年の運営責任者の実体験と現場経験に基づき制作しています。ご安心の上閲覧ください。

中小企業のWebやSNS運用を支援する中で、VSCodeのJSON整形が原因のトラブルを何度も見てきました。ショートカットを覚えれば解決すると思われがちですが、実際には「誰かのPCだけ整形結果が違う」「保存時だけJSONが動かない」「Prettier導入後に設定ファイルが壊れた」と相談される場面が続きました。私自身も、PCのログイン不可や各種管理画面のインサイトが突然見えなくなったことをきっかけに、設定ファイルの扱い方を徹底的に見直した経験があります。JSONは1つのカンマや整形ルールの違いで、計測タグやLINE連携が止まることがあります。現場で実際に起きた「小さな設定ミスが大きな損失になる」パターンを整理し、VSCodeの標準機能から拡張機能の選び方、チームでのルール作りまで、一連の流れとして押さえられる形にまとめたかったのが本記事の出発点です。特に専任エンジニアがいない企業でも、安全にJSONを扱えるようにしておくことが、今後のAI活用や自動化の土台になると考え、細部の手順やチェックポイントまで書き切りました。