無料JSON→Go構造体コンバーター

仕組み

1. JSONを貼り付け: 入力フィールドに任意のJSONオブジェクトまたはネストされた構造を入力します。
2. Go structを取得: 適切なフィールド名、型、JSONタグを持つ同等のGo struct定義が瞬時に生成されます。
3. コピーして使用: structコードをコピーしてGoプロジェクトに貼り付け、JSONデータの逆シリアライズを開始します。

なぜJSON → Go structコンバーターを使うのか?

複雑なJSONレスポンスのGo structを手動で書くのは退屈でエラーが発生しやすく、特にAPIが数十のフィールドを持つ深くネストされたオブジェクトを返す場合は顕著です。JSON → Goは、JSONの形状を解析し、JSONフィールド名と一致する適切なjson:"…"タグ付きの正しく型付けされたGo structを生成することで、これを自動化します。これは、REST APIを使用、Webhookペイロードを処理、または任意のJSONデータソースで作業する際のGo開発を高速化します。

機能

• ネストされたstruct生成: 深くネストされたJSONオブジェクトはネストされたGo struct定義に変換されます。
• 型推論: 文字列、数値、ブール、配列、null値は適切なGo型に関連付けられます。
• JSONタグ: すべてのフィールドには、元のJSONキーに一致するjson:"fieldName"のstructタグが含まれます。
• 配列処理: JSON配列は適切な要素型のGoスライスになります。
• ポインタ型: nullableなJSONフィールドはポインタ型(例: *string)で表されます。

よくある質問

null値はどのように処理されますか?

JSONのnullフィールドは、Goでポインタ型(例: *string、*int)に変換され、nilと実際の値の両方を表すことができます。これは、APIレスポンスのオプションまたはnullableフィールドを正しく処理します。

JSONに一貫性のない型がある場合は?

JSONオブジェクト間で同じフィールドが異なる型で表示される場合(実際のAPIで頻繁)、コンバーターはinterface{}(モダンなGoではany)を推論することがあります。これらのフィールドを確認し、必要に応じてカスタム型アサーションを追加します。

完全な逆シリアライズコードを生成しますか?

ツールはstruct定義を生成します。逆シリアライズするには、標準のencoding/jsonパッケージでjson.Unmarshal(data, &myStruct)またはjson.NewDecoder(r.Body).Decode(&myStruct)を使用します。

Go と JSON の小史

Go は 2009 年 11 月に Google で Rob Pike、Robert Griesemer、Ken Thompson によって発表されました。encoding/json パッケージは Go 1.0(2012 年 3 月)以前に標準ライブラリに収まりました。Go の JSON パースはリフレクションに基づきます: 構造体を宣言し、フィールドに json:«name» タグを付け、json.Unmarshal が構造体とバイトの両方を走査します。このパターンは生産的すぎて、大規模 API の構造体を手書きすることがすぐに退屈になりました。Matt Holt は 2014 年に mholt/json-to-go を JavaScript 専用ツールとして構築し(まだ mholt.github.io/json-to-go で維持されています)、ブラウザ内で正規表現ベースの JSON 解析を使用しています。quicktype(David Siegel、2017)はこのアイデアを TypeScript、Rust、Swift、Kotlin、Python、Java を含む 23 言語に一般化しました。パフォーマンス重視の easyjson(Mail.ru、2016)はコンパイル時に marshalling コードを生成することでリフレクションをスキップし、ホットパスで encoding/json より 4-5 倍高速です。Go 1.18(2022 年 3 月)はジェネリクスを追加し、一部の marshalling ヘルパーを簡素化しましたが、構造体タグの慣用句は変えませんでした。Go 1.21(2023 年 8 月)は実験的な encoding/json/v2 パッケージを追加(2024 年時点でまだ議論中)、サイレントな型ミスマッチや遅いリフレクションなどの長年の落とし穴の修正を目指しています。

Struct vs map[string]interface{}: どちらがいつ意味を持つか

• 既知の形には型付き構造体が勝ちます。 API を制御するか安定したスキーマがある場合、構造体はコンパイル時のフィールド検査、IDE オートコンプリート、2-3 倍高速なパースを提供します。構造体への json.Unmarshal は認識するフィールドのみに触れ、不明な JSON キーを静かに無視します(decoder.DisallowUnknownFields を呼び出さない限り)。
• 任意の JSON にはマップが勝ちます。 map[string]interface{}(Go 1.18+ では map[string]any)は非常に可変な形状を扱います, 多くのソースからの webhook ペイロード、プラグイン設定、MongoDB ドキュメント。トレードオフ: 各アクセスに型アサーション(data[«age»].(float64))が必要で、数値はデフォルトで float64 にパースされ、大きな整数の精度が失われます。
• ハイブリッド: 既知フィールドは構造体に、不明はマップに。 パースを遅延するために json.RawMessage を使うか、catch-all フィールド Extra map[string]interface{} `json:«-,inline»` を追加します(go-restful のようなライブラリの助けを借りて)。Stripe と Twilio の Go SDK は後方互換性のある API レスポンスにこのパターンを使います。
• パフォーマンスギャップ。 ホットパス(例: 毎秒 10,000 webhook イベントをパース)は生成された marshaller の恩恵を受けます: easyjson、ffjson、go-json、sonic(ByteDance、2022、JIT を使ってランタイムでマシンコードを生成, Go で最速の JSON ライブラリ)。構造体ベースのジェネリックパースはおそらく 100-200 MB/s 処理しますが、sonic は 1-2 GB/s 処理します。
• 大きな JSON にはストリーミング。 1 GB の JSON ファイルはメモリに収まりません。json.Decoder.Token() はトークンごとに読み取ります。json.Decoder.More() は配列要素を一度に一つずつ走査します。ログファイル、大きなデータセット、ND-JSON ストリーム(行ごとに 1 つの JSON オブジェクト、OpenSearch、BigQuery、ChatGPT API で使用)にはストリーミングを使用してください。

JSON-to-Go 変換が実際に時間を節約する場所

• REST API 統合。 Stripe、GitHub、Slack、Notion はすべて深くネストされた JSON を返します。サンプルレスポンスを取り json-to-go に貼り付けると最終構造体の 80-90% が生成されます。節約した時間を残りの 10%(時間フォーマット用のカスタム unmarshaller、omitempty セマンティクス、オプショナルなポインタフィールド)に使ってください。
• Webhook ハンドラ。 典型的な Stripe webhook ペイロードは 80-200 フィールドで 3-5 階層のネストがあります。Go 構造体を手で入力するのに 30-60 分かかります; json-to-go 経由でサンプルペイロードを貼り付けるのに 30 秒。
• 設定パース。 JSON 設定ファイル(AWS Lambda、Docker Compose compose.json、devcontainer.json で TOML よりも好まれる)は Go 構造体にきれいにマップします。encoding/json は同じ構造体でファイルの読み書き両方を扱います。
• gRPC と Protobuf ブリッジ。 生成された Go protobuf 型には json タグが含まれます。protobuf と JSON 間でトランスコードするとき(gRPC-Gateway、Buf、Connect)、json-to-go は JSON ワイヤフォーマットから Go 側をスケッチするのに役立ちます。
• データベースの JSONB カラム。 PostgreSQL jsonb、MongoDB ドキュメント、MySQL JSON カラム。database/sql ドライバは []byte を返し、それを構造体に unmarshal します。ジェネレータはスキーマオンリードテーブルの最初のパスを加速します。
• テスト用フィクスチャデータ。 実際のプロダクション JSON レスポンスがテストフィクスチャになります。json-to-go はアサーションのために unmarshal する構造体を提供します。testdata/ ディレクトリ(Go 1.10 以降の慣習)と組み合わせて、テストを現実に近く保ちます。
• CSV-to-JSON-to-struct パイプライン。 データエンジニアリングタスク用: CSV を読み、検査用に JSON に marshal し、構造体を取得するために json-to-go に貼り付け、その後型付きパイプラインを書く。スプレッドシートから列の型を推測するよりはるかに高速です。

構造体生成後の一般的なミス

• time.Time 処理を忘れる。 encoding/json は RFC 3339 形式(2026-05-13T12:34:56Z)を想定しています。ほとんどの API はこれを配信しますが、一部は Unix タイムスタンプ(Stripe)、タイムゾーンなしの ISO(古い Microsoft API)、またはカスタム文字列を使用します。非 RFC-3339 の場合、UnmarshalJSON メソッドを持つカスタム型を定義してください。
• float64 デフォルトでの整数オーバーフロー。 interface{} にパースされた JSON 数値は float64 になります; 2^53 を超える数値は精度を失います。Stripe 顧客 ID、Twitter snowflake、Discord ユーザー(すべて 64 ビット)は構造体内に json.Number または int64 を必要とします。interface{} での安全なパースには json.Decoder.UseNumber() を使用してください。
• omitempty の誤解。 omitempty はゼロ値(空文字列、0、nil ポインタ、空 slice/map)の場合に marshal 時にフィールドを省略します。これは「unmarshal でオプショナル」を意味しません。値 0 の int フィールドは欠落と区別できません; API がフィールドを省略したかゼロを送ったかを知る必要がある場合は *int を使用してください。
• フィールド名の大小文字ミスマッチ。 Go フィールドは marshal されるためにエクスポート(大文字化)されている必要があります。デフォルトの JSON 名は Go 名のリテラルなので、UserID はタグなしでは JSON で «UserID» になります。ジェネレータは Go の PascalCase と JSON の camelCase を橋渡しするために json:«userId» タグを追加します。タグを忘れることは、コードが「自分自身で動作する」が外部 API に対して失敗することを意味します。
• ポインタ型の過剰使用。 ジェネレータは安全のため時々 *string や *int をデフォルトにします。これによりすべてのアクセスで nil チェックが必要になります。API がフィールドが常に存在することを保証する場合(API ドキュメントを読む)、値型を使用して間接参照をスキップしてください。
• レスポンス間の不整合な型。 一部の API はあるレスポンスで tags: []string{«foo»} を返し、別のレスポンスでは文字列として tags: «foo» を返します。純粋なコード生成はこれを橋渡しできません。両方のケースを処理するカスタム UnmarshalJSON を書くか、interface{} にフォールバックして可変性を文書化してください。
• 不明フィールドの静かな破棄。 デフォルトでは、json.Unmarshal は構造体にない JSON キーを無視します。これはしばしばバグです: API がフィールドを追加し、あなたのコードはそれを知りません。ドリフトをキャッチするためにテストで decoder.DisallowUnknownFields() を使用してください; プロダクションでは寛容に保ってください。

その他のよくある質問

これは標準的な mholt/json-to-go とどう違いますか?

同じコアアルゴリズム: JSON をパース、各フィールドの最初の出現から型を推論、バッククォート内でタグ付けされたフィールドを持つ構造体を生成。この実装はあなたのブラウザで完全に動作し、analytics やネットワーク呼び出しはありません; 標準版は mholt.github.io/json-to-go でホストされ、これもブラウザのみですが異なるドメインです。出力は入力の ~95% で一致するはずです; エッジケース(混合型配列、深くネストされた匿名構造体)はわずかに異なる場合があります。正確な mholt 出力が必要な場合はそれを使用してください; JSON がデバイスを離れないというプライバシー保証が必要な場合はこれを使用してください。

なぜ一部のフィールドは interface{} として生成されるのですか?

3 つの一般的な理由。第一に、ソース JSON のリテラル null: ジェネレータは単独の null から有用な型を推論できないため、interface{} にフォールバックします。実際のスキーマがわかったら型付きポインタ(*string、*int)に置き換えてください。第二に、混合型配列: [1, «two», true] は型付き slice になれません。第三に、サンプル内で完全に欠落しているフィールド、可能であればより代表的な JSON を貼り付けてください。Go 1.18+ では interface{} をよりすっきりとしたエイリアス any に置き換えることができます; 型レベルで同一です。

この構造体を介して JSON をデータ損失なしで往復できますか?

通常は、注意事項付きで可能です。encoding/json はフィールド値を保持しますが、フィールド順序は保持しません(JSON 仕様はフィールド順序が無関係であると述べています; Go マップは意図的にランダム化されます)。数値精度: 2^53 を超える int64 は Go int64 で安全に往復しますが、float64 にキャストするか JavaScript(例: ブラウザ中間者)を経由すると桁を失います。不明な JSON フィールドは unmarshal-そして-remarshal で静かに削除されます, 往復の忠実性が重要な場合は map[string]json.RawMessage catch-all で保持してください。

encoding/json の代わりに生成された構造体コード(easyjson、sonic)をいつ使用すべきですか?

デフォルトは encoding/json, 95% のサービスに十分で、言語に同梱されています。プロファイルを取り、JSON marshalling が CPU フレームグラフで合計時間の >10% に現れるときに easyjson または sonic に切り替えてください。典型的な切り替えポイント: 毎秒数千リクエストを処理する HTTP サービス、GB/時を取り込むログアグリゲータ、リアルタイムストリーム。どちらの代替も同じ構造体定義とタグを保つため、フィールド宣言を変更せずに交換できます。

私の JSON はサーバーに送信されますか?

いいえ。JSON パースと Go コード生成の両方があなたのデバイスの JavaScript で実行されます。貼り付ける間に DevTools の Network タブを開いてください; ゼロの送信リクエストが表示されます。プロプライエタリ API レスポンス、顧客データフィクスチャ、PII を含む webhook ペイロード、および NDA でカバーされるすべてに対して安全です。