Protobuf フォーマッター
乱れた .proto スキーマを貼り付けてください。インデントを揃え、スペースを統一し、空行を整えます — コメントは置いた場所そのままです。
入力（.proto スキーマ）
出力（整形済み .proto）
このツールでできること
インデントが混在していたり、フィールド宣言が詰まっていたり、コピペ由来の空行がランダムに入っていたりする Protocol Buffers スキーマを貼り付けて、リポジトリのほかのコードと同じ見た目にしたい — そんなときのためのツールです。このフォーマッターはファイルを書き直し、波かっこ階層ごとに 2 スペースのインデント、= の前後にちょうど 1 スペース、, の後に 1 スペース、ブロック間の連続した空行は最大 1 行までに揃えます。コメントは // 行コメントも /* ... */ ブロックコメントも、置いた場所そのままに残ります。
スキーマをパースしたり検証したりはしません。つまり buf format やエディタの「ドキュメントの整形」が拒否しそうな、ちょっと壊れた入力でも動きます。.proto のどこかに構文エラーがあっても、その周りのファイルは整形されます。代わりにできないこと：フィールドの並び替え、import 順の正規化、未使用オプションの削除 — 本格的なパーサーベースのフォーマッターのような正規化はできません。それが必要なら、ビルドパイプラインで buf format を回してください。
すべてブラウザ内で動きます — アップロードもレートリミットもなく、スキーマがどこかに送られることもありません。スキーマに社内のパッケージ名や型名、外部 API に渡したくない情報が含まれているときに便利です。ブラウザのメモリに収まるサイズなら何でも扱え、数万行でも 1 秒以内に整形が終わります。
使い方
3 ステップ。タイピングを止めてから約 300 ms で出力が更新されます。
.proto スキーマを貼り付ける
左のエディタにスキーマを入れます。syntax、package、import ディレクティブ、message ブロック、ネストした enum、oneof、map<K, V> — すべて処理されます。混在した改行コード（CRLF）は出力時に LF に正規化されます。
フォーマッターは並び替えを一切しません — フィールド、import、オプションは書いた順のまま残ります。正規順序が欲しい場合は、後から buf format を実行してください。
整形後の出力を確認する
右側に：同じスキーマが、{ 階層ごとに 2 スペースのインデントで表示されます。} で始まる行は出力前にデインデントされます。連続した空行は 1 行に縮められます。行末の空白は削除されます。コメントは相対位置を含めて文字どおり保持されます。
結果を使う
エディタに戻すか、formatted.proto としてダウンロードします。protoc から見ると、出力は入力とバイト等価 — 変わるのは空白だけ — なので、ワイヤフォーマットや生成コードの違いを気にせずそのまま戻せます。検証するには protoc --descriptor_set_out=before.pb input.proto を入力に対して、同じものを整形後の出力に対して実行してください。デスクリプタは一致します。
実際に時間を節約できる場面
チャットやドキュメントから貼り付けた .proto をきれいにする
チームメンバーが Slack にスキーマの断片を貼り付けて、インデントは崩れていて、それを自分のリポジトリに入れたい。ここに放り込んで整形版をコピーし、ファイルに貼り付けるだけです。エディタで「全選択 → 再タブ化」をするより速いです。
古いリポジトリ全体の .proto を統一する
ファイルごとにインデントがバラバラの Protobuf リポジトリを引き継いだとき。各ファイルをこのフォーマッターに通して、整形コミットを 1 つだけ入れて、CI で buf format を有効にして以後維持します。
生成された .proto をすばやく確認する
コードジェネレータ（JSON Schema → Protobuf、OpenAPI → Protobuf）の中には、有効ではあるけれど見た目が悪いスキーマを吐くものがあります。出力を整形して目視確認し、ジェネレータをそのまま使うか手で直すかを決められます。
protoc や buf をインストールできないとき
ロックダウンされたマシン、ゲストネットワーク、あるいはブラウザで PR をレビューしているだけ — そんな状況でも、Protocol Buffers のツールチェインを入れずに同じ読みやすい出力が得られます。
よくある質問
スキーマはどこかに送信されますか？
いいえ。フォーマッターは JavaScript として完全にブラウザ内で動作します。スキーマに関する情報 — メッセージ名、パッケージパス、コメント — は何ひとつマシンの外に出ません。DevTools を開いて貼り付けながら Network タブを見れば、リクエストがゼロなのが確認できます。
コメントは保持されますか？
はい — // の単行コメントも /* ... */ のブロックコメントも、置いた場所そのままに残ります。独立した行のコメントは相対位置を維持し、フィールド行末のトレーリングコメントはそのフィールドにくっついたままです。コメントが原形のまま生き残るように、あえて行ベースのアプローチを選んでいます。
buf format との違いは？
buf format はスキーマを構文木にパースしてから再出力します。それによってオプションの正規順序や enum の表記統一など、より強い保証が得られますが、スキーマがきれいにパースできることが前提です。このフォーマッターは行ベースなので、buf が拒否するような少し壊れた入力にも動き、正規順序を強制しません。完成済みコードには buf format を、編集途中のスキーマやサードパーティの断片にはこちらを使ってください。
スキーマの意味を変えますか？
いいえ — 変わるのは空白だけです。protoc から見れば、入力と出力のどちらからでも同じ FileDescriptorProto が生成されます。protoc --descriptor_set_out=before.pb input.proto を入力と整形後ファイルそれぞれに対して実行して比較すれば検証できます。バイナリのデスクリプタは、source-info の span 変更（リフレクション用メタデータであってワイヤフォーマットではない）を除いて完全に一致します。
インデント幅 — 2 スペースから変えられますか？
出力は波かっこ階層ごとに 2 スペース固定で、Protocol Buffers の公式スタイルガイドの慣習に合わせています。4 スペースやタブが必要なら、出力を sed やエディタのタブ変換に通してください。フォーマッターの出力を正規形に固定することで、チームごとの設定の食い違いを避けられます。
CRLF の改行コードに対応していますか？
はい — 入力の CRLF（\r\n）は出力時に LF（\n）に正規化されます。保存ファイルで CRLF が必要な場合は、エディタが保存時の改行コード設定に応じて再エンコードします。
関連ツール
Protobuf スキーマを扱っているなら、これらと相性が良いです：