YAML JSON コンバーター

YAMLとJSON形式を簡単に変換

YAMLをJSONに変換したい？JSONをYAMLに？ここで解決できる。 設定ファイル、API、インフラコードを触ったことがあるなら、この状況わかるはず。KubernetesのマニフェストはYAMLなのにAPIはJSONを要求してくる。CI/CDパイプラインの出力はJSONだけどドキュメントにはYAMLが必要。同僚から送られてきたJSON設定、整形しないと読めない。 いつもの解決策？「yaml json 変換 オンライン」でググって、最初に出てきたサイトにペースト。でも待って、そのデータにはAPIキー、DBパスワード、内部エンドポイント、本番環境の設定が含まれてるかも。それを見知らぬサーバーに送って大丈夫？ YAML JSON Converterはそのトレードオフが嫌で作った。ブラウザ内で完結する。データはサーバーに一切送られない。アップロードなし、トラッキングなし、心配なし。 YAML→JSON変換 左にYAMLをペースト、右にJSONが出る。即座に。ボタンをクリックする必要もなければ、サーバーの応答を待つ必要もない。タイプしながらリアルタイムで変換される。 YAMLのあらゆる機能に対応： - マルチドキュメント（---区切り） - アンカーとエイリアス（&anchor、*alias） - 複雑なネスト構造 - 複数行文字列（|と>の両方） - すべての標準データ型 よくある使い方： KubernetesとDockerの作業。起動しないデプロイメントをデバッグ中。YAMLマニフェストをJSONに変換すれば、タイプミスしたネストキーが見つかる。jsonlintやIDEのJSONバリデータに食わせられる。構文エラーを探すとき、JSONの方がブラケットの対応が追いやすい。 API開発。RESTエンドポイントはJSONを返すけど、ドキュメントはYAMLで書いてる。サッと変換すれば一貫性を保てる。OpenAPI仕様、Swagger定義、APIドキュメント——手作業で書き直さずにフォーマット切り替え。 AnsibleとTerraform。Infrastructure as CodeはYAMLだらけ。JSONしか受け付けないツールに設定を渡さないといけないことがある。プログラムで設定を生成して、出力構造を確認したいこともある。 GitHub ActionsとGitLab CI。パイプライン設定はYAML。何か壊れたとき、JSONに変換するとCIシステムがパースしてる正確な構造が見える。あの謎のインデントエラーがどこに隠れてるか見つけやすくなる。 JSON→YAML変換 同じ話、逆方向。JSONをペースト、適切にインデントされたYAMLを取得。 データ構造は完璧に保持される。数値は数値のまま。ブーリアンはブーリアンのまま。ネストされたオブジェクトは正しいインデントレベルで出力。変な型変換やデータ損失なし。 よくある使い方： 設定を人間が読めるように。JSONは機械には良いけど人間には辛い。圧縮されたJSONをYAMLに変換すれば、急に読めるようになる。コメントを追加できる（JSONはコメント非対応）、セクションを整理できる、メンテナンス可能になる。 API出力からKubernetesリソースを作成。kubectl get deployment -o jsonはJSONを返す。バージョン管理用にYAMLマニフェストとして保存したい？ペースト、変換、完了。 ドキュメント作成。YAMLの方がドキュメントで読みやすい。JSON APIレスポンスをYAMLに変換して、READMEやwikiにクリーンな例として載せる。 設定の移行。JSONベースの設定システムからYAMLに移行？既存の設定を手作業で書き直す代わりにまとめて変換。 フォーマット検証 コンバーターは構文チェッカーとしても使える。不正なYAML？不正なJSON？どこに問題があるか正確にわかる。 検出できるもの： - JSONのカンマ抜け - YAMLのタブ/スペース混在（定番のミス） - 閉じてないブラケットやブレース - 不正なエスケープシーケンス - 重複キー - 型の不一致 アプリがクラッシュしてエラーログを漁るより、はるかに速い。 なんでオンラインコンバーターじゃダメなの？ プライバシー。それが全てのポイント。 オンラインコンバーターはデータをサーバーにアップロードする。「すぐ削除します」と言っても、データはインターネットを通じてどこかの会社のインフラに送られた。ログに残ってるかも。どこかにキャッシュされてるかも。分析やAI学習に使われてるかも。 変換してるものを考えてみて： - データベース接続文字列 - APIキーとシークレット - 内部サービスのURL - 本番環境の設定 - 認証トークン - プライベートリポジトリのパス どれもマシンから外に出るべきじゃない。 YAML JSON ConverterはブラウザでJavaScriptを使ってすべてローカル処理する。データを処理するサーバーなんて持ってない、必要ないから。変換ロジックは君のコンピュータで動く、うちのじゃなくて。 これはプライバシー機能じゃない——アーキテクチャそのもの。文字通りデータを見ることができない、届かないから。 オフライン対応 拡張機能を一度インストールすれば、どこでも使える。インターネット不要。 飛行機で作業中？問題なし。外部ネットワークアクセスのないセキュア施設？問題なし。信用できない怪しいwifiのカフェ？問題なし。 コンバーター全体がローカルで動く。インストールしたら、ネットワーク接続は関係ない。 本当に無料 プレミアムプランなし。「機能をアンロックするにはアップグレード」なし。使用制限なし。透かしなし。広告なし。 自分たちのために作って、他の人にも役立つかもと思っただけ。それだけ。 誰が使ってる？ KubernetesのYAMLとJSONをデバッグ、検証、API呼び出しのために変換するDevOpsエンジニア。APIレスポンスを設定ファイルに変換するバックエンド開発者。異なるビルドツール用にJSON設定を変換するフロントエンド開発者。YAMLベースとJSONベースのパイプラインツール間で設定を移動するデータエンジニア。 ランダムなウェブサイトに認証情報をペーストしたくないセキュリティ意識の高い開発者。データ取り扱いが重要な規制産業で働く人。クライアントの設定を扱い、機密性を真剣に考えるフリーランサー。 データシリアライゼーションフォーマットの関係を学ぶ学生。両方のフォーマットで例が必要なチュートリアルライター。ただ速くてシンプルな、余計なもののないコンバーターが欲しい人。 技術仕様 対応するYAML機能： - YAML 1.1と1.2互換 - マルチドキュメントストリーム（---） - アンカー（&）とエイリアス（*） - マージキー（<<） - 複合キー - すべてのスカラー型（文字列、整数、浮動小数点、ブーリアン、null） - ブロックとフローコレクション - リテラル（|）と折りたたみ（>）ブロックスカラー - タグによる明示的な型指定 対応するJSON機能： - 完全なJSON仕様準拠 - ネストされたオブジェクトと配列 - すべてのプリミティブ型 - Unicodeサポート - 適切なエスケープシーケンス処理 拡張機能によるファイルサイズ制限なし。実用的な制限はブラウザのメモリ次第。数万行のファイルでも問題なくテスト済み。 Chrome 114以降が必要。Windows、Mac、Linux、ChromeOS——Chromeが動くところならどこでも動く。 キーボードショートカット 一日中設定を変換してると速度が大事： - ペーストと変換は即座（Ctrl/Cmd+Vだけ） - ワンクリックで出力をコピー - 両パネルをクリアして最初から 入力するフォームなし、設定するオプションなし。ペースト、コピー、完了。 Web版もある 拡張機能をインストールしたくない？yaml-json.tools-ai.orgで同じコンバーターをWebアプリとして使える。同じプライバシー保証——すべてブラウザで動く。 拡張機能は頻繁に使うなら便利。Web版は他の人のマシンにいるときや、まず試してみたいときに。 代替手段との比較 vs. オンラインコンバーター（yaml-online-parser、json2yaml.comなど） データをアップロードする。うちはしない。それが根本的な違い。公開されてるサンプルデータを変換するなら、オンラインツールで問題ない。マシンから出るべきでないものを変換するなら、ダメ。 vs. コマンドラインツール（yq、jq） CLIツールは強力だけど、インストールと学習曲線が必要。YAML JSON Converterはインストールしてすぐ使える。ビジュアルインターフェースで入力と出力が同時に見える。ちょっとした一回限りの変換に向いてる。スクリプトやバッチ処理ならCLIツールの勝ち。 vs. IDEプラグイン IDEプラグインはエディタ内で動くから便利。でもその特定のIDEに縛られる。YAML JSON ConverterはChromeが動くところならどこでも動く、どのエディタを使ってても。 vs. プログラミング言語ライブラリ（PyYAML、js-yaml） フォーマット変換のためにコードを書くのは、ほとんどのユースケースでやりすぎ。大きなシステムの一部としてプログラム的にやるならライブラリを使う。ただ何かをサッと変換したいなら、これを使う。 よくある質問 コメントは扱える？ YAMLコメントはJSONへの変換時に削除される（JSONはコメント非対応）。JSONからYAMLへの変換はコメントなしのクリーンな出力になる。コメントを保持したいなら、JSONを経由しないYAML対応ツールが必要。 YAMLのエイリアスとアンカーは？ 完全対応。アンカーとエイリアスは変換時に解決されるので、JSON出力には展開されたデータが含まれる。 複数ドキュメントを変換できる？ できる。マルチドキュメントYAML（---で区切り）はJSON配列に変換される、各要素が1ドキュメント。 ファイルアップロードオプションはある？ 今のところペーストのみ。ほとんどの設定ファイルはコピペの方がファイルダイアログより速いくらい小さい。 キーの順序は保持される？ される。入力のオブジェクトキー順序は出力でも維持される。 YAML/JSONが巨大だったら？ 動くけど、すべてブラウザで処理されるので、非常に大きなファイルは処理に時間がかかるかも。巨大なファイルには、代わりにストリーミングCLIツールを検討して。 典型的なワークフロー Kubernetesデバッグ： 1. kubectl get deployment myapp -o yaml > myapp.yaml 2. コンバーターにペースト 3. JSON構造を見て問題を特定 4. YAMLで修正、適用、繰り返し APIドキュメント： 1. APIからJSONレスポンスを取得 2. YAMLに変換 3. 注釈付きでドキュメントに追加 4. 読者にとってクリーンな例に 設定の移行： 1. 既存のJSON設定をエクスポート 2. まとめてYAMLに変換 3. 各セクションを説明するコメントを追加 4. バージョン管理にコミット CI/CDトラブルシューティング： 1. GitHub Actions / GitLab CI YAMLをコピー 2. JSONに変換 3. 構造が期待通りか検証 4. 隠れた構文エラーを発見 プライバシー詳細 収集するもの：なし。 保存するもの：なし。 送信するもの：なし。 拡張機能が要求する権限はストレージのみ——セッション間でテーマ設定（ライト/ダークモード）を記憶するため。閲覧履歴、他のタブ、コンバーターインターフェース以外のものにはアクセスしない。 アナリティクスなし、トラッキングピクセルなし、使用テレメトリなし。何人が使ってるか、何を変換してるかも分からない。設計上そうしてる。 サポートとフィードバック バグ発見？機能要望？フィードバックは歓迎。実際に毎日このツールを自分たちで使ってるから、ちゃんと動かし続けるモチベーションがある。 サーバーインフラが必要な機能を追加する予定はない、プライバシーファーストの設計が台無しになるから。でも変換ロジック、UI、対応フォーマットの改善は常に検討中。 実際の使用シーン 開発者が実際にどう使ってるか： 深夜2時の本番障害。何か壊れてて、見た目は問題なさそうなYAML設定をにらんでる。JSONに変換して、より厳格なバリデータに通すと、あの狂いそうだった見えない文字とか変なインデントが見つかる。ベッドに戻れる。 新しい職場のオンボーディング。使ったことないツールを使うチームに入った。設定は全部YAMLだけど、JSONでしか仕事したことない。サッと変換すれば、YAMLの構文を深く学ばなくても構造が理解できる。 クライアントへの納品。コントラクターでプロジェクト納品中。クライアントは特定のフォーマットで設定がほしい。送る前に全部変換するのに2秒。 コードレビュー。誰かが巨大なYAMLファイルを提出した。一時的にJSONに変換して、エディタのJSON折りたたみとナビゲーション機能を使う。複雑なネスト構造のレビューがはるかに楽。 レガシー移行。古いシステムはJSON設定、新しいシステムはYAMLがほしい。何百ものファイルを手作業で変換する（そしてタイプミスを入れる）代わりに、ちゃんとまとめて変換。 フォーマットの説明 これらのフォーマットに詳しくないなら、簡単に説明： YAML（YAML Ain't Markup Language）は人間が読みやすいように設計されてる。インデントで構造を表す（Pythonみたいに）。手で読み書きしやすいから設定ファイルで人気。コメントOK。Kubernetes、Docker Compose、Ansible、ほとんどのCI/CDツールがYAMLを使う。 JSON（JavaScript Object Notation）は機械が読みやすくデータ交換しやすいように設計されてる。ブレースとブラケットで構造を表す。構文は厳格（カンマが大事、コメント不可）。APIは基本JSON。JavaScriptがネイティブでパースする。ほとんどのプログラミング言語にJSON組み込みサポートがある。 両方とも同じ基本データ構造を表せる：オブジェクト/マップ、配列/リスト、文字列、数値、ブーリアン、null。変換はデータ的にロスレス、ただしYAMLコメントは落ちる（JSONが対応してないから）。 エラーメッセージ 入力に問題があると、コンバーターは何が悪いか正確に教えてくれる： YAMLエラー： - 「行Xでインデントエラー」—— タブとスペースが混在、またはインデントが不一致 - 「未知のエイリアス」—— 存在しないアンカーを参照した - 「重複キー」—— 同じキーが1つのオブジェクトに2回出現 - 「不正な文字」—— あるべきでないものがある JSONエラー： - 「位置Xで予期しないトークン」—— 大抵カンマ抜けか余分なカンマ - 「終端されていない文字列」—— クォートを閉じ忘れ - 「プロパティ名の後に':'が必要」—— オブジェクト構文が間違ってる - 「入力が予期せず終了」—— 閉じブラケットかブレースが足りない これらのメッセージが問題の場所を正確に指す。当てずっぽうより速い。 ダークモード コンバーターはライトとダーク両方のテーマに対応。デフォルトでシステム設定に合わせるか、手動で切り替え。ダークモードは深夜のデバッグセッションで目に優しい。 インターフェースデザイン 2つのパネルが横に並ぶ。左が入力、右が出力。タイプしながら変換される——ボタン不要。 インターフェースは意図的にミニマル。絶対使わないオプションだらけのツールバーなし。ウィザードなし。設定なし。ただペーストして結果を得る。 パネルサイズは仕切りをドラッグして調整できる。書いてるときは入力を大きく、結果を見るときは出力を大きく。 出力パネルのコピーボタンで変換データが即座にクリップボードに。 言語サポート 英語と日本語のインターフェースが利用可能。拡張機能がブラウザ言語を検出して適切な翻訳を使う。 需要に応じて言語を追加できる。コア変換機能はUI言語に関係なく動く——YAMLとJSONはどこでも同じ。 アップデート 拡張機能はChromeの拡張機能システムで自動更新。手動ダウンロードなし、バージョンチェックなし。常に最新の変換ロジックとバグ修正がある。 頻繁には更新しない——これは常に新機能が必要なツールじゃない。更新するときは： - バグ修正 - パフォーマンス改善 - YAML/JSON仕様の新しいエッジケース対応 - フィードバックに基づくUI改善 インストール 1. このページで「Chromeに追加」をクリック 2. インストールプロンプトを確認 3. YAML JSON Converterアイコンがツールバーに出現 4. 何か変換したいときにクリック それだけ。アカウント作成なし、メール確認なし、オンボーディングフローなし。インストールして使うだけ。 拡張機能をツールバーにピン留めすると素早くアクセスできる。そこにあると、どれだけ頻繁に必要になるか驚くはず。 ツール別の活用方法 Kubernetes kubectl get系コマンドの出力はJSON/YAMLを選べる。でもマニフェストはYAMLで書くのが普通。デバッグ時にJSONに変換すると構造が見やすい。Helm chartのvalues.yamlも同様。 Docker Compose docker-compose.ymlの構文確認にJSONバリデーションが使える。複数のcomposeファイルをマージするとき、構造の比較にも便利。 Ansible playbookとroleの設定はYAML。変数ファイルをJSONでエクスポートして他ツールと連携するケースも。逆にJSONで定義された外部データをYAMLに取り込むことも。 Terraform .tfファイルはHCLだけど、terraform showの出力はJSON。state管理やプランの比較でJSONを扱うことが多い。 GitHub Actions workflow.ymlのデバッグ。複雑なmatrix設定やconditionalを確認するときにJSONに変換すると見通しが良くなる。 GitLab CI .gitlab-ci.ymlも同様。extends使いすぎて構造がわからなくなったらJSONで展開してみる。 CircleCI config.ymlのorb展開後の構造確認に。 開発者タイプ別の使い方 インフラエンジニア 日常的にKubernetes、Terraform、Ansibleを触る。設定ファイルの99%はYAML。たまにJSONしか受け付けないAPIやツールがある。そういうときにサッと変換。 バックエンドエンジニア APIはJSONで喋る。でもドキュメントやサンプルはYAMLの方が読みやすいことも。OpenAPI仕様書の編集で両フォーマットを行き来する。 フロントエンドエンジニア package.jsonは触るけどYAMLはあまり馴染みがないかも。でもCI/CD設定やdocker-composeを触る機会が増えてきた。フォーマット間の変換で理解を助ける。 フルスタックエンジニア 全部触る。だからこそ、どっちのフォーマットにも対応できるツールが必要。 データエンジニア ETLパイプラインの設定はYAMLが多い（Airflow、Dagster）。データスキーマ定義はJSONスキーマ。両方を扱う。 SRE/プラットフォームエンジニア インフラ設定の大半はYAML。でもモニタリングツールやアラート設定でJSONを使うことも。Grafanaダッシュボードとか。 よくある間違いと対処法 YAMLでタブを使ってしまう YAMLはスペースのみ。エディタの設定を確認。変換エラーが出たらまずこれを疑う。 JSONでケツカンマ 配列やオブジェクトの最後の要素にカンマをつけると不正。JavaScriptでは許容されるけどJSONは厳格。 YAMLで文字列をクォートし忘れ yesとかnoとかonとかoffは予約語。文字列として使いたいならクォートで囲む。 JSONでシングルクォート JSONはダブルクォートのみ。シングルクォートはエラー。 YAMLのアンカー参照ミス &で定義したアンカーを*で参照。スペルミスすると「unknown alias」エラー。 パフォーマンスについて 小さいファイル（数百行） 一瞬で変換。タイプしながらリアルタイムで結果が見える。 中規模ファイル（数千行） 問題なし。体感的な遅延はほぼない。 大きいファイル（数万行） 動くけど少し時間がかかるかも。ブラウザのメモリ次第。本当に巨大なファイルならCLIツール（yq/jq）の方が適切。 ただし、大抵の設定ファイルは大きくても数千行。このツールで十分対応できる範囲。 セキュリティポリシーが厳しい環境での利用 金融機関 顧客データや取引情報を含む設定は外部に出せない。完全ローカル処理だから安心。 医療機関 患者情報に関わるシステム設定。HIPAA的な観点でも、データがブラウザから出ないのは重要。 政府機関 内部システムの設定情報。クラウドサービスにアップロードNG環境でも使える。 防衛産業 言うまでもない。オフライン動作必須の環境にも対応。 他のブラウザ拡張機能との違い 多くのYAML/JSONツール拡張機能は、実はバックエンドサーバーを使ってる。UIだけがブラウザで、変換処理はクラウド。 YAML JSON Converterは純粋にクライアントサイドで動作。ネットワークリクエストを見れば一目瞭然——送信してない。 これは技術的な選択であり、プライバシーへのコミットメント。 具体的な変換例 YAML入力例： server: host: localhost port: 8080 ssl: true database: url: postgres://db.internal:5432/myapp pool_size: 10 JSON出力： {"server":{"host":"localhost","port":8080,"ssl":true},"database":{"url":"postgres://db.internal:5432/myapp","pool_size":10}} 逆方向も同様。JSONをペーストすればきれいにインデントされたYAMLが得られる。 マルチドキュメントYAML YAMLは---で複数ドキュメントを1ファイルに含められる。Kubernetesでよく見るパターン。 --- apiVersion: v1 kind: ConfigMap ... --- apiVersion: v1 kind: Secret ... これをJSONに変換すると、配列になる： [{"apiVersion":"v1","kind":"ConfigMap"...},{"apiVersion":"v1","kind":"Secret"...}] それぞれのドキュメントが配列の要素に。 アンカーとエイリアス YAMLの強力な機能。同じ値を複数箇所で使いたいとき： defaults: &defaults timeout: 30 retries: 3 production: <<: *defaults host: prod.example.com development: <<: *defaults host: localhost JSONに変換すると、エイリアスは展開される： {"defaults":{"timeout":30,"retries":3},"production":{"timeout":30,"retries":3,"host":"prod.example.com"},"development":{"timeout":30,"retries":3,"host":"localhost"}} 展開後の実際のデータ構造が見えるから、デバッグに便利。 複数行文字列 YAMLには複数行文字列の書き方が2種類： リテラルブロック（|）：改行を保持 description: | This is line 1. This is line 2. 折りたたみブロック（>）：改行をスペースに変換 description: > This is a long description that wraps. JSONに変換すると、それぞれ適切にエスケープされた文字列に。 特殊な値の扱い YAMLには特殊な値がある： null/~：JSONのnullに true/false/yes/no/on/off：JSONのtrue/falseに .inf/-.inf/.nan：JSONでは文字列に（JSON仕様に対応する値がないため） これらの変換ルールを知っておくと、予期しない結果を避けられる。 日時の扱い YAMLは日時をネイティブサポート： created_at: 2024-01-15T10:30:00Z JSONには日時型がないので、文字列として出力される： {"created_at":"2024-01-15T10:30:00Z"} これはJSON仕様の制限。ISO 8601形式の文字列として扱われる。 バイナリデータ YAMLはBase64エンコードされたバイナリをサポート： data: !!binary | R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7 JSONに変換すると、Base64文字列として出力される。 コメントについて YAMLの大きな利点の1つはコメント： # This is a comment server: port: 8080 # Default port JSONに変換するとコメントは消える。JSON仕様がコメントをサポートしてないから。 コメントを保持したいなら、JSONを経由せずにYAMLを直接編集するしかない。 インデントスタイル YAML出力のインデントは2スペースで統一。これは最も一般的なスタイル。 4スペースや別のスタイルが必要なら、出力をコピーしてエディタで整形し直す必要がある。大抵の場合2スペースで問題ない。 キーの順序 変換時にキーの順序は保持される。YAMLで書いた順番でJSONに出力される。 ただしJSONオブジェクトは仕様上順序を保証しないので、JSONをパースするプログラム側で順序が変わる可能性はある。このツール自体は順序を維持する。 Unicode対応 日本語、中国語、韓国語、絵文字、あらゆるUnicode文字が使える。 message: こんにちは世界 emoji: 🎉 JSONに変換しても正しくエンコードされる。 エスケープ処理 JSONの特殊文字（ダブルクォート、バックスラッシュ、制御文字）は自動でエスケープ： YAMLで： path: C:\Users\name JSONで： {"path":"C:\\Users\\name"} 手動でエスケープを気にする必要なし。 空の値 空のオブジェクトや配列も正しく変換： empty_object: {} empty_array: [] null_value: null JSONでも同様に： {"empty_object":{},"empty_array":[],"null_value":null} ネストの深さ 深くネストされた構造も問題なし。10段、20段のネストでも正確に変換。 ただし、あまりに深いネストは可読性の問題。そもそも設定の構造を見直した方がいいかも。 エラー時の動作 入力が不正なとき、出力パネルにエラーメッセージが表示される。元のデータは変更されない。エラーを修正すれば、また正常に変換される。 部分的に正しい入力でも、エラー箇所を特定しやすいようにメッセージを表示。 なぜブラウザ拡張として作ったか Webアプリでも同じ機能は提供できる。でも拡張機能には利点がある： ワンクリックアクセス。ツールバーのアイコンをクリックするだけ。URLを覚えたりブックマークを探したりする必要なし。 オフライン動作の確実性。Webアプリはサービスワーカーでオフライン対応できるけど、拡張機能の方が確実。一度インストールすれば、ネットワーク状態に関係なく動く。 コンテキスト統合。将来的には、ページ上で選択したテキストを右クリックから直接変換、みたいな機能も追加できる。Webアプリでは難しい。 とはいえ、拡張機能をインストールしたくない人のためにWeb版も用意してる。yaml-json.tools-ai.org で同じ機能が使える。 技術的な実装について 変換エンジンはjs-yamlライブラリを使用。長年の実績があり、YAML 1.1/1.2仕様に準拠。 UIはPreactで構築。Reactと互換性がありつつ、バンドルサイズが小さい。拡張機能では重要なポイント。 スタイリングはTailwind CSS。ダークモード対応が簡単で、一貫したデザインを維持しやすい。 ビルドにはViteを使用。高速で、開発体験も良い。 プライバシーを重視する理由 開発者として、自分が使いたいツールを作った。 コードやconfig情報は機密性が高いことが多い。本番環境のDBパスワード、APIキー、内部システムのエンドポイント。これらを外部サービスにアップロードするのは、たとえ一時的でも気持ち悪い。 「削除します」と言われても、ログに残ってないか、キャッシュされてないか、バックアップに含まれてないか——全部確認する術がない。 ローカル処理なら、そもそもその心配がない。データはブラウザのメモリに一時的に存在するだけで、どこにも送信されない。タブを閉じれば消える。 これが最もシンプルで確実なプライバシー保護。 開発者の日常ツールとして IDE、ターミナル、ブラウザ。開発者の三種の神器。 このツールはブラウザに常駐する。設定ファイルをコピーして、アイコンをクリックして、ペーストして、結果をコピー。5秒で終わる作業。 毎日使うものだからこそ、シンプルで速くて信頼できるものがいい。余計な機能はいらない。アカウント登録もいらない。広告もいらない。ただ動けばいい。 フィードバックの取り入れ方 バグ報告や機能要望は歓迎。でもプライバシーを損なう機能は追加しない。 例えば「変換履歴を保存してほしい」という要望があったとする。便利かもしれないけど、履歴を保存するということは、どこかにデータを永続化するということ。それはやらない。 「クラウド同期」も同様。デバイス間で設定を共有したい気持ちはわかるけど、それにはサーバーが必要。サーバーがあれば、データがそこを通る可能性がある。だからやらない。 この制約の中で、できる限り良いものを作る。それがこのツールの方針。 似たようなツールを探してる人へ 「yaml json 変換」「json yaml コンバーター」「yaml to json online」「json to yaml converter」「yaml validator」「json formatter」「yaml beautifier」「json to yaml free」「yaml parser online」「convert yaml to json」 これらで検索してここにたどり着いたなら、正解。 「kubernetes yaml to json」「docker-compose json」「ansible yaml convert」「terraform json output」「github actions yaml debug」「gitlab ci config converter」「helm values yaml」「openapi yaml json」 インフラ/DevOps系のキーワードで来た人も、正解。 「offline yaml converter」「private json converter」「local yaml to json」「no upload yaml converter」「secure json yaml」 プライバシー重視で検索してきた人、まさにそのために作った。 使ってみて インストールは無料、使用も無料、制限なし。 30秒でインストールできる。試してみて、気に入らなければ削除すればいい。Chromeの拡張機能管理から簡単に消せる。 気に入ったら、そのまま使い続けてくれればいい。アップデートも自動だから、何もしなくていい。 開発作業の小さな改善になれば幸い。 チーム開発での活用 チームで開発してると、メンバーによって好みのフォーマットが違うことがある。 「俺はJSON派」「私はYAML派」——どっちが正しいとかじゃない。状況によって使い分けるのが現実的。このツールがあれば、フォーマット間の変換がボトルネックにならない。 コードレビューで「このYAML読みにくい」と言われたら、JSONに変換して共有。逆も同様。コミュニケーションの摩擦を減らせる。 ドキュメント作成での活用 技術ドキュメントを書くとき、サンプルコードは読者に合わせて選ぶ。 YAMLに慣れてる読者向けにはYAML例を、JSON好きな読者向けにはJSON例を。両方載せるのがベストだけど、手作業で両方書くのは面倒。片方を書いて変換すれば、一貫性のある両フォーマットのサンプルが得られる。 OpenAPIやSwaggerのドキュメントでよくあるパターン。 学習リソースとして YAMLを学んでる人にとって、JSONとの比較は理解を深める良い方法。 同じデータ構造がYAMLとJSONでどう表現されるか、並べて見ることで違いがわかる。インデントの意味、配列の書き方、オブジェクトの表現——視覚的に比較できる。 逆にJSONに慣れてる人がYAMLを学ぶときも同様。知ってるフォーマットから新しいフォーマットへの橋渡しになる。 スクリプトとの連携 このツールはGUIだけど、CLIツールと組み合わせて使うことが多い。 1. CLIでデータを取得（kubectl get、aws cli、gcloud） 2. 出力をコピーしてこのツールにペースト 3. 変換結果を確認、必要なら加工 4. 加工したデータをCLIに戻す GUIとCLIのいいとこ取り。全部CLIでやるより、視覚的に確認できるステップが入る方が安心なこともある。 APIテストでの活用 REST APIをテストするとき、リクエストボディはJSON。でも複雑なリクエストを書くのに、YAMLの方が楽なことがある。 YAMLで書いて、JSONに変換して、curlやPostmanに貼り付け。特にネストが深いリクエストで有効。 エディタとの使い分け VSCodeやJetBrains IDEにもYAML/JSONの変換機能はある。でも拡張機能の方が便利なケースがある。 エディタを起動してない状態で、サッと変換したいとき。Slackで送られてきたYAMLをその場で確認したいとき。ブラウザで見てるドキュメントのサンプルを変換したいとき。 ブラウザは常に開いてる。だから拡張機能が便利。 トラブルシューティングの定番手順 YAML/JSONで問題が起きたときの定番手順： 1. まずこのツールにペースト 2. エラーが出たら、エラーメッセージを読む 3. エラーの行番号を確認 4. 元のデータを修正 5. 再度ペーストして確認 これを繰り返す。エラーメッセージが具体的だから、原因特定が速い。 なぜシンプルなUIなのか 機能を削ぎ落としたデザインには理由がある。 変換ツールに求めるのは、速さと正確さ。設定画面を開いて、オプションを選んで、実行ボタンを押して——そんな手順は要らない。 ペーストしたら変換される。それだけ。認知負荷ゼロ。 「もっとオプションが欲しい」という声もあるかもしれない。でもオプションを増やすと、デフォルト以外の設定で変換したときに「あれ、前と違う」となる。シンプルなら、いつも同じ結果。予測可能性は重要。 最後に YAMLとJSONは現代の開発のどこにでもある。設定ファイル、APIレスポンス、インフラ定義、CIパイプライン——常にこれらのフォーマット間を移動してる。 ほとんどの開発者はオンラインツール（プライバシーリスク）か一回限りのスクリプト（時間の無駄）を使う。もっと良いものが欲しかった：速くて、プライベートで、シンプル。 YAML JSON Converterがそのツール。アカウントなし、アップロードなし、トラッキングなし。ただペースト、変換、コピー。 インストールして、試して、必要になるまで忘れておく。そしたらブラウザのツールバーにすぐそこにある。 データは君のもののまま。