GraphQL クエリ整形・SDLビルダー

公式graphql 16.14.2のLexer・Parserによる構文解析を用いて,GraphQLクエリおよびSDLを文字列リテラルを保持しながら整形・圧縮します.GUI操作によりtype,input,enum,unionのSDL雛形を生成可能で,Queryルート欠落を除くスキーマ整合性チェックに対応しています.スキーマに対するクエリ検証や外部API実行は行いません.

読み込み中...

このツールが向いている用途

操作欄に戻る ↑

クエリを構文解析して整形・圧縮し,フォームからSDL型定義を作成・検査できます.API実行前に文書を整理する用途に向いています.

まず試せること

サンプルクエリを貼り付けて2スペース整形と圧縮出力を比較するか、フォームからtype/input定義の生成を試します。

利用条件

実サーバーへのリクエスト送信やAPIスキーマ適合性検証は行いません。入力20万字・2万トークン・深さ128の上限があります。

ZeroToolsのブラウザ内処理とプライバシー

ZeroToolsは,入力内容を端末内で処理するツールを中心に提供しています.各ツールの対応範囲と制限を確認して利用してください.

データの取り扱い・プライバシー方針
第1章

公式のLexer・Parserを用いたGraphQLコードの整形

本ツールにおけるGraphQLクエリおよびスキーマ定義(SDL)の整形機能は,公式ライブラリである「graphql 16.14.2」のLexer(字句解析器)およびParser(構文解析器)を採用した構文解析処理によって実現されています.従来の正規表現置換や中括弧カウントによる処理とは異なり,クエリ(Query,Mutation,Subscription,Fragment)やスキーマ定義言語(SDL)の文法規則に従い,構文構造を解析してインデント階層を整えます.

開発の現場では,コンポーネント内にインラインで記述されたGraphQLクエリや,ネストされたスキーマ定義のインデントや改行が崩れてしまう場面が頻繁に生じます.本ツールを利用することで,ブラウザ上で手軽にコードの可読性を整えるワークフローを構築できます.ただし,本機能が実行するのはGraphQL構文の解析(Syntax Parse)のみであり,スキーマと照合してフィールドや型の妥当性を検証するクエリ検証や,外部APIへの通信・実行可能性の確認は行いません.

また,クライアントからサーバーに対してデータを要求・操作するためのクエリだけでなく,サーバー側の型システム全体を記述するためのSDL(スキーマ定義言語)の整形にも同一の構文解析エンジンで対応しています.クエリとSDLは用途こそ異なりますが,いずれも公式GraphQL仕様に準拠した字句・構文規則を共有しています.

本ツールの整形処理では,インデント幅として2スペースまたは4スペースのいずれかを選択でき,階層構造に応じた字下げが適用されます.文字列リテラルや複数行のブロック文字列については,Lexerのソースオフセットを用いて生の字句を切り出すことで,内部の改行や空白を保持したまま整形を行います.

処理規模の境界値として,入力テキストは最大200,000 UTF-16コード単位,コメントを含むトークン数は最大20,000トークン,区切り記号のネスト深度は最大128階層,結合前測定による出力バッファは最大2,000,000 UTF-16コード単位までに設定されています.

構文エラーのある入力に対しては中途半端な整形結果を出力せずエラー表示を行います.

第2章

ネットワークペイロード削減のための空白圧縮(Minify)

GraphQLを実運用環境で利用する際,クエリのファイルサイズや構文の簡潔さは無視できない要素となります.特にフロントエンドからAPIサーバーに対してHTTPリクエスト経由でクエリを送信する場合,可読性のために挿入された不要なインデントや連続するスペース,改行,そして開発用のコメントなどは,データ転送量を不必要に増加させる要因となります.

本ツールには,整形機能とは逆のアプローチとして,コメントや構文上意味を持たない余分な空白を除去するための空白圧縮(Minify)機能が搭載されています.このMinify処理においても,公式graphql 16.14.2の字句・構文解析エンジンが用いられており,安全なトークン分割に基づいて圧縮が行われます.

具体的な圧縮処理では,コード内に含まれるすべてのコメント(#以降の行末までの文字列)を完全に除去し,カンマや構文上必須ではない空白文字を徹底的に削除します.ただし,本ツールの圧縮処理はASTの論理的最適化を行うものではなく,文字列リテラルやブロック文字列の生字句(raw lexemes)およびトークンの順序と構造をそのまま保持しながら,安全に不要空白を切り詰める設計となっています.

そのため,波括弧や丸括弧,コロンなどの構文記号の周囲にある空白を最小限に抑制し,コンパクトな文字列へと変換します.圧縮されたクエリは,フロントエンドのソースコード内で文字列リテラルとして埋め込んだり,VariablesとともにJSONペイロードに格納してPOSTリクエストを送信したりする際に,ペイロードサイズを抑える用途に役立ちます.

ただし,ネットワーク上の実転送量はHTTPヘッダーやgzip/brotli等の通信圧縮設定にも依存します.

一方で,SDL(スキーマ定義言語)を圧縮するケースもあります.APIゲートウェイの設定や,インフラのプロビジョニングスクリプト,CIパイプラインにおいてスキーマ文字列を直接渡すような場面では,改行を含まないMinifyされたSDL形式が利用されることがあります.

本ツールでは,整形とコード圧縮を切り替えることで,可読性を高めたレイアウトと改行を詰めたデータ形式を用途に応じて選択できます.圧縮処理ではコメントが除去されるため,Minify後の出力から元のコメントを復元することはできません.入力された元テキスト自体はエディタ内に保持されます.

また,ソースコードやインデント設定を変更した際には,直前の出力が即座に非表示となり,再度実行するまで新しい結果が表示されない状態管理を行っています.入力上限200,000 UTF-16コード単位やトークン数20,000個などの制限はMinify時にも適用されます.

第3章

文字列リテラルとコメント保護の仕組みと限界

GraphQLのコード整形や空白圧縮を行う上で重要なのが,文字列リテラルとコメントの保護です.GraphQLコード内には,二重引用符で囲まれた通常の単一行文字列(String)や,トリプルダブルクォーテーションで囲まれた複数行のブロック文字列(Block String),さらにはハッシュ記号(#)で始まるコメントが存在します.

現在の実装では,公式Lexerが切り出したトークンのソース位置(開始・終了オフセット)に基づいて元テキストから生の字句を直接スライスして抽出しています.これにより,文字列内部に含まれる改行,スペース,二重引用符,エスケープされたトリプルクォートなどを構文要素と混同することなく識別し,指定されたフォーマット規則に従って整形や圧縮の対象へ組み込みます.

現在の本ツールでは,公式「graphql 16.14.2」のLexerとParserにより字句解析を行っており,置換プレースホルダーを用いずトークンのソースオフセットから元のスライスを直接取得する方式を採用しています.通常文字列やブロック文字列(Block String)は,内部に含まれるエスケープされたトリプルクォートや末尾の空白,改行に至るまで,元の字句スライスがそのまま保持されます.

整形処理においては,コメントも独立したトークンとして位置関係を維持したまま所定のインデント階層に配置されます.一方,空白圧縮(Minify)処理においては,コメントおよび冗長な空白・カンマが除去され,文字列リテラルやブロック文字列の内部データはそのまま出力されます.

処理は200,000 UTF-16コード単位や20,000トークンといった入力制限のもとで同期的に実行されます.

ただし,本ツールの処理範囲には明確な境界線が存在します.本ツールが提供するのは構文規則に基づく正確なフォーマットと圧縮であり,入力されたクエリが特定のGraphQLスキーマ上で実際に有効であるか,要求されたフィールド名や型が実在するか,あるいは実行時に正しく動作するかといったスキーマ照合や実行時バリデーションは行いません.

また,シングルクォートや不正なエスケープ,閉じていない文字列など,公式構文規則に違反する字句が含まれている場合はエラーとして処理を中断し,壊れた出力を生成しない厳格な設計となっています.開発者は,本ツールで構文の整形と圧縮を完結させた上で,実サーバーやGraphQLクライアントの型生成ツールと組み合わせて活用することが推奨されます.

第4章

区切り記号の対応確認とエラーフィードバック

GraphQLクエリやスキーマを編集している際に最も頻繁に発生するケアレスミスは,波括弧や丸括弧,角括弧の閉じ忘れや順序の誤り,あるいは不正な引用符の混入です.本ツールでは,過去の単純な括弧カウントによる曖昧な判定を廃止し,公式graphql 16.14.2のLexerおよびParserによる完全な構文解析(Syntax Parse)に基づいてエラーを検出します.

波括弧・丸括弧・角括弧([])の対応関係やネスト順序の不正,閉じていない引用符,トークンの構文違反などが存在する場合,構文解析エラーとして明確に検知され,処理は直ちに拒絶されます.構文エラーが発生した場合は部分的な整形出力を生成せず,誤ったコードの出力を防止します.

入力を修正した後は,再度処理ボタンを実行することで結果が再計算されます.

また,本ツールのエディタおよび設定UIにはリアクティブな状態管理が組み込まれています.ソースコードのテキスト入力内容を変更したり,2スペースまたは4スペースのインデント幅設定を変更した瞬間,以前に生成された古い結果画面や警告表示は即座に非表示(ハイド)となります.

これにより,編集前の古い整形結果を現在の入力結果と誤認して作業を進めてしまうトラブルを確実に防止します.入力されたGraphQLコードに構文エラーが含まれている間は,整形・圧縮結果のテキストエリアへの出力やコピー操作は一切行えず,常に正しく構文解析を通過したコードのみが出力対象となります.

入力が空文字の場合はエラーではなく空の出力として安全に処理されます.

構文解析および整形・圧縮が正常に完了した後は,「結果をコピー」ボタンをクリックすることで,生成されたコードをクリップボードに格納できます.このクリップボード操作は共有の非同期Clipboard API(await処理)を用いて安全に実行され,コピー完了時にはボタン上に成功のフィードバックが表示されます.

ブラウザの権限設定等によってコピーに失敗した場合にはエラーメッセージが表示されるほか,出力内容の変更やコンポーネントのアンマウント時には非同期状態やタイムアウトのクリーンアップが行われる安全設計となっています.この厳格な構文検査と確実なフィードバックにより,開発者は安心してコードを自らのエディタや実装プロジェクトへコピーして利用できます.

第5章

GUIを活用したSDL(スキーマ定義言語)ビルダー機能

本ツールのもう一つの大きな特徴が,直感的なGUI操作によってGraphQLのスキーマ定義(SDL)を構築できるスキーマビルダー機能です.GraphQLを導入したばかりの開発者にとって,正確なSDLの構文や型修飾子の組み合わせを手書きすることは構文ミスの原因となりやすい作業です.

この機能を使えば,フォームに型名を入力し,ドロップダウンやチェックボックスを選択するだけで,標準的なSDL形式の型定義テンプレートがリアルタイムで組み立てられます.初期状態としてあらかじめ提供されているPost定義やUser定義のサンプル構造を確認しながら,視覚的に型モデリングを進めることが可能です.

本ビルダーは,GraphQLの型システムにおける4つの主要な定義,すなわちオブジェクト型(type),入力型(input),列挙型(enum),そしてユニオン型(union)の構築に対応しています.各型の定義やフィールドの命名においては,GraphQLの公式構文規則に基づくASCII正規表現のバリデーションが行われ,先頭の二重アンダースコア(__)などのシステム予約語は拒絶されます.

入力文字を勝手に切り詰めて暗黙的に別名へ変換することは行わず,不正な名前はそのままエラーとして通知されます.各型名は組み込み型を含めて完全な大文字小文字の区別(Case-sensitive)のもとで一意性が検証されます.オブジェクト型や入力型では空のフィールドや同一型内での重複フィールド名は禁止され,入力型(input)のフィールドには入力型・列挙型・スカラー型のみが指定可能で,出力オブジェクト型を指定することはできません.

逆にオブジェクト型のフィールドに入力型を配置することも禁止されています.列挙型(enum)では大文字への自動変換を行わず入力された大文字小文字を厳密に保持し,true/false/nullや空値・重複は拒絶されます.ユニオン型(union)は空定義を許さず,重複のないオブジェクト型のみで構成する必要があります.

さらに,ビルダー内で参照されている型はスキーマ内に実在している必要があり,他から参照されている型を削除した場合はエラーが表示されコピーが無効化されます.型の説明文(description)の入力UIは型定義(Type)のみを対象としており,フィールド単位の説明文入力には対応していません.

入力された型説明文はJSON.stringify相当の処理を経てエスケープされたGraphQL StringValueとして出力されます.フィールドが0個の空のtypeや空のenum/unionは未完成エラーとして検知され,完成するまでSDLの出力やコピーは行われません.

生成されたSDLは公式のvalidateSchema等により検証されますが,型テンプレート出力の便宜上,Queryルート型の存在要件のみを例外として除外して検証されます.ビルダーの最大100型,型あたり100項目,説明文2,000 UTF-16コード単位,名前128文字という上限に加え,全体の200,000 UTF-16入力,20,000トークン,128ネスト,2,000,000 UTF-16出力の境界も適用されます.

第6章

簡易処理の範囲と最終検証

本ツールで提供されるGraphQLの構文解析,コード整形,空白圧縮,およびGUI SDLビルダーの処理は,すべてブラウザのJavaScript環境内で完結して実行されます.外部サーバーへのコード送信やリモートAPIの呼び出し,ファイル保存機能や永続化ストレージは一切使用せず,作業中のデータが外部ネットワークに送信されることはありません.

整形およびMinify機能においては,公式ライブラリである「graphql 16.14.2」のLexerとParserを採用しており,通常の単一行文字列やトリプルクォートによるブロック文字列(Block String),エスケープシーケンス,行末空白,コメントに至るまで,生の字句(RAW LEXEME)を忠実に尊重して処理されます.

かつてのプレースホルダー置換による識別子の誤認や文字列破壊の懸念は解消されています.

エラー検知に関しても,単純な括弧の個数比較にとどまらず,波括弧・丸括弧・角括弧([])のネスト順序や構文構造の整合性を公式Parserによって厳密に判定します.ただし,本ツールが実行するのは構文解析(Syntax Parse)のみであり,指定されたクエリが存在するGraphQLスキーマの型定義やフィールド構成に合致しているか,ディレクティブの引数が正しいか,あるいはフラグメント定義が網羅されているかといったスキーマ照合やクエリ実行検証を行うものではありません.

また,SDLビルダーにおいては,type,input,enum,unionの4種に特化したテンプレート構築を行い,公式のbuildASTSchemaおよびvalidateSchemaによる検証(Queryルート不在の例外を除く)を行いますが,Interface型やカスタムDirective定義,フルスキーマ全体の管理やサーバーの即時実行性を保証するものではありません.

本ツールには安定した動作を確保するための明確な処理上限が設けられています.クエリ整形・圧縮においては入力200,000 UTF-16コード単位,コメントを含むトークン数20,000,区切り記号深度128階層,結合前測定による出力2,000,000 UTF-16コード単位が上限となります.

SDLビルダーにおいても,最大100型,1型あたり100項目,説明文2,000コード単位,名前128文字などの上限があり,これらが複合して適用されます.構文エラーや未完成な定義が存在する場合,あるいは入力変更によって古い結果が無効化された状態では,出力のコピーは安全に制限されます.

本番環境に投入するクエリやSDLスキーマについては,実際の利用環境におけるGraphQLサーバーやCIパイプラインのバリデーションツールを用いて最終確認を行ってください.また,端末環境やブラウザ拡張機能の管理にも留意し,適切なセキュリティ基準のもとで運用してください.

よくある質問(FAQ)

A.
GraphQLクエリやスキーマ(SDL)の整形と圧縮には,公式ライブラリ「graphql 16.14.2」のLexerおよびParserを採用しています.構文木と字句解析に基づいて,2スペースまたは4スペースの正確なインデント整形や,コメント・不要空白を除去するMinifyを実行できます.ただし,本ツールが実施するのは純粋な構文解析(Syntax Parse)のみであり,特定のスキーマに対する型・フィールドの妥当性検証やAPI実行は行いません.
A.
公式graphql 16.14.2のLexerとParserを用いて字句・構文を解析するため,通常文字列や複数行のブロック文字列(Block String)の生字句(エスケープされたトリプルクォートや末尾空白を含む)を厳密に保持しながら圧縮を行います.コメントや構文上不要な空白・カンマのみを安全に削り,文字列リテラル内部のデータを改変することはありませんが,ASTの論理最適化を行うものではなく,実運用での利用前には対象のGraphQL環境で動作を確認することが推奨されます.
A.
公式Parserにより,波括弧・丸括弧・角括弧([])のネストや開閉順序の誤り,閉じていない引用符,構文違反などの構文エラーを厳密に検出します.構文エラーが存在する場合,中途半端な整形結果は出力されず,結果のコピーも制限されます.ただし,クエリ内のフィールドや引数が対象スキーマ上に存在するかどうかの型検証や実行可能性の検査は行われません.入力や設定を変更すると直前の結果表示は即座に非表示となります.
A.
type,input,enum,unionの4種類の型システム定義に対応した雛形を生成できます.初期状態として提供されるPostやUserの構造を参考にしながら,重複名や予約語(__),不正な参照の検査,空定義の防止,安全な説明文(description)の文字列化などを備えています.生成されたSDLは公式のbuildASTSchemaおよびvalidateSchema(雛形生成のためQueryルート不在要件のみ例外)によって検証されますが,InterfaceやDirective,サーバーでの即時稼働可能性を保証するものではありません.