入力 (.proto スキーマ)

出力 (JSON サンプル)

このツールについて

Protocol Buffers のスキーマを持っていて、テスト用フィクスチャ、OpenAPI のサンプル、gRPC のスタブレスポンスなど、そのメッセージがどんな JSON になるかの例が必要なとき。長い .proto ファイルから JSON の形を手で書くのは面倒でミスも起きがちです。このツールはスキーマを読み、最後に宣言された message（通常の「外側の」型）を拾い、それに対応する JSON オブジェクトをフィールド単位で出力します。

出力は公式の proto3 デフォルト値を使います。string と bytes は空文字列、数値型は 0、bool は false、repeated は []、map は {}、enum フィールドはゼロ値の enum 定数。ネストされたメッセージは再帰的に展開されます。64 ビット整数は proto3 JSON マッピング仕様に合わせて JSON 文字列として出力されます — JS の Number に int64 を入れると精度を失うためです。

すべてブラウザ内でローカルに完結します — .proto のアップロードなし、サーバへのスキーマ送信なし、AI 推論呼び出しもなし。syntax/package/import のディレクティブ、コメント（行・ブロック）、ネストされた message と enum のブロック、oneof、map<K, V>、repeated、optional、フィールドオプション（読み込みはするが無視）を扱う、自前のパーサーが動いているだけです。protobufjs 系のフルランタイムが必要なら別問題ですが、「このスキーマから JSON の形を出して」だけなら、こちらの方が速いです。

使い方

3 ステップ。出力された JSON はそのままフィクスチャ・サンプルブロック・リクエストボディに貼れます。

.proto スキーマを貼り付ける

左のエディタにスキーマを入れます。先頭の syntax = "proto3"; はあっても無くても構いません — パーサーは気にしません。コメント・package 宣言・import 文はすべてきれいにスキップされます。複数のメッセージがある場合、パーサーはトップレベルで最後の message（典型的な外側／合成型）をルートとして使います。

別のメッセージを変換したい？そのメッセージをファイルの末尾に移動してください。スキーマにはネスト型、enum、oneof ブロックを含められ、すべて解決されます。

Convert を押す

緑の Convert ボタンをクリックします。パーサーがスキーマをトークン化し、メッセージツリーを構築し、ルートメッセージを辿って各フィールドに proto3 のデフォルトを出力します。ネストされたメッセージはインライン展開されます。repeated フィールドは要素の形を示すヒントとして 1 要素の配列を出します — 空配列だと構造が見えないためです。

JSON を使う

結果をテストフィクスチャ、OpenAPI のサンプルブロック、gRPC-Web のモック、リクエスト／レスポンスの形が必要などこへでもコピーします。キーは .proto のフィールド名と完全一致しています — codegen が camelCase にするなら後で変えてください。

実際に時間が浮く場面

テスト用に gRPC レスポンスをスタブ化

サービスハンドラが Protobuf レスポンスを返す。ユニットテストはメッセージの形に合った JSON フィクスチャが必要。<code>.proto</code> を貼って JSON を取り、フィクスチャフォルダに置くだけ。30 個のフィールドを手で書いて 1 個忘れる、はもう無し。

gRPC-gateway 用の OpenAPI サンプル

Protobuf サービスを REST として公開するために grpc-gateway 等を使っていますか？各オペレーションには JSON サンプルが要ります。.proto メッセージを JSON スケルトンに変換し、spec の example キーに貼り込みます。

JSON Schema の出発点を作る

<code>.proto</code> 契約に合う JSON リクエストをバリデーションしたい。まず JSON サンプルに変換し、それを JSON Schema 推定ツールに渡せば、数秒で出発点となるスキーマが手に入ります。

API クライアントでリクエストボディを埋める

HTTP に転コードした gRPC API を Postman や curl でテスト中？ .proto を貼り、JSON スケルトンをリクエストボディにコピーし、本当に送りたい値を埋めるだけ。

よくある質問

.proto スキーマはどこかに送信されますか？

いいえ。パースは JavaScript で完全にブラウザ内で行われます。メッセージ名、フィールド名、package パス — スキーマの何も端末から出ません。DevTools の Network タブを開きながら Convert をクリックして確認してください。リクエストはゼロです。

proto3 と同じく proto2 も扱えますか？

おおむね可能です。パーサーは required や optional といった proto2 のシンタックストークンを処理しますが、出力値は proto3 のデフォルトを使います（proto3 JSON マッピングの仕様に従っています）。[default = ...] で明示的なデフォルトを指定した proto2 ファイルでも、そのデフォルトは出力には反映されません。

どのメッセージを変換するかはどう決めていますか？

ファイル内でトップレベルに最後に宣言された message を使います。実際のスキーマでは外側／合成型は依存先の後に宣言されることが多く、これで欲しいものに合致します。違うものが選ばれる場合は、変換したいメッセージが最後になるようファイルを並べ替えてください。

なぜ int64 値は出力で文字列なのですか？

JSON は IEEE-754 ダブルしか持たず、2^53 を超えると精度が落ちるためです。公式の proto3 JSON マッピングは int64、uint64、fixed64、sfixed64、sint64 を JSON 文字列としてエンコードするよう求めています。当ツールはそれに従っています。

oneof、map、repeated はどうなりますか？

3 つとも動作します。oneof フィールドは普通のフィールドとして解析されます（JSON オブジェクトには 1 つ選ばれずに全部含まれます — 通常は要らないものを削除します）。map<K, V> は空の {} オブジェクトを出力します。repeated は要素の形を示す 1 要素配列を出力します — 実データに合わせて複製・削除してください。

import を辿りますか？

いいえ。import 文は認識はしますがスキップされます。ファイル間のメッセージ型は出力では null に解決されます。クロスファイル解決が必要なら、import 元から該当メッセージを同じ入力にコピペしてください。

どれくらい大きいスキーマを扱えますか？

数万行でも問題ありません。すべてローカルなので、アップロードもレートリミットもネットワーク遅延もありません。

Protobuf から JSON への変換ツール