🔎 JSONPath テスター

JSON データに対して JSONPath クエリ ($.store.book[*].author など) をリアルタイムで評価。フィルタ・再帰下降・ワイルドカード対応。

完全無料登録不要ブラウザ完結 5 言語対応ダークモード

🔒 プライバシーについて

・すべての処理はあなたのブラウザ内で完結します
・入力データは一切サーバーに送信されません

JSON データ

JSONPath クエリ

結果

📚 JSONPath 構文ヘルプ

$ — ルートオブジェクト

@ — 現在のノード (フィルタ内)

.field / ['field'] — 子要素アクセス

.. — 再帰下降 (任意の深さ)

* — ワイルドカード (全要素)

[index] — 配列の index 指定

[start:end:step] — 配列スライス

[a,b,c] — 複数 index/フィールド

[?(@.price < 10)] — フィルタ式

[?(@.tags)] — フィールド存在判定

📖 つまずきやすいポイント

JSON に対して JSONPath クエリをリアルタイムに評価し、マッチした値と件数を表示します。再帰下降・ワイルドカード・スライス・フィルタ式に対応し、処理はブラウザ内で完結します。JSONPath は 2024 年に RFC 9535 として標準化されるまで、正式な仕様が存在しませんでした — それまでの 17 年間、各実装が 2007 年の記事を独自に解釈していたので、同じ式が実装によって違う結果を返します。

ケース	何が起きるか	どうする
同じ式が実装によって違う結果になる	曖昧さが残っていたのは主に 3 か所です — 再帰下降とインデックスの組み合わせ (`$..book[0]` が「各配列の先頭」なのか「全 book を集めた配列の先頭」なのか)、結果が常に配列なのか、単一の値のときは値そのものを返すのか、そしてフィルタ式で存在しないフィールドを参照したときの挙動です。実装を乗り換えた瞬間に結果が変わるので、「ライブラリを更新したら急に動かなくなった」という形で表面化します — 式は変えていないので、原因の見当がつきません。	RFC 9535 準拠を明示しているライブラリを選んでください — 2024 年以降のものは「準拠」と書いてあります。既存のコードでは、使っているライブラリのドキュメントで実際の挙動を確認するしかありません。実務上の助言としては、曖昧さが出る書き方を避けるのが最も確実です — 再帰下降 `$..` の直後にインデックスを書かない、結果は常に配列として受け取り、`[0]` はコード側で取る、フィルタは存在確認と組み合わせる (`?(@.price && @.price < 10)`)。この 3 つを守れば、実装の違いにほとんど影響されなくなります — JSONPath を式の中で凝らせるほど、移植性は下がります。
フィルタ式が動かない	数値の比較 `?(@.price < 10)` は多くの実装で動きますが、文字列の比較でクォートの種類が問題になります — `?(@.category == 'fiction')` のシングルクォートを受け付けない実装、逆にダブルクォートを受け付けない実装の両方が存在します。RFC 9535 は両方を許していますが、それ以前の実装はどちらか片方だけということがあります。さらに厄介なことに、比較演算子の前後の空白の有無で失敗する実装や、`==` ではなく `=` を要求する実装もあります — そしてエラーメッセージは出ず、単に 0 件が返ります。	クエリを一気に書かず、段階的に絞り込んでください — `$` で全体を見て、`$.store`、`$.store.book`、`$.store.book[]`、最後にフィルタ、という順に確かめれば、どの段階で 0 件になったかが分かります。これはこの種のクエリ言語で最も速いデバッグ方法です — 0 件という結果だけを見ても、タイポなのか、データが無いのか、構文が通っていないのかを区別できないからです。フィルタが原因だと分かったら、クォートの種類を入れ替える、演算子の前後の空白を削る、`==` と `=` を試すという順で当たってください。複雑なフィルタが必要な段階になったら、JSONPath ではなくコードで書くほうが読みやすく、テストもできます。*
JSONPath と JMESPath と jq を混同する	名前も見た目も似ていますが、この 3 つは別の言語で、構文の互換性はほとんどありません。AWS CLI の `--query` は JMESPath (`Reservations[].Instances[].InstanceId` のように `$` を使わない)、`kubectl -o jsonpath` は Kubernetes 独自の方言 (`{}` で囲み、`$` を省略でき、`range` という独自構文がある)、jq は完全に独自のクエリ言語 (パイプ、変数、関数定義まである) です。ネットで見つけた式をそのまま貼って動かない原因の多くがこれで、「JSONPath の記事」だと思っていたものが実は JMESPath だった、ということが普通に起こります。	使う前に「これはどの言語か」を確認してください — 見分け方は簡単で、`$` で始まれば JSONPath、`$` が無く `[]` や `\|` を使えば JMESPath、`.field` や `select()` やパイプが並べば jq です。もう 1 点、JSONPath は読み取り専用です — 値の書き換え、構造の組み換え、集計はできません。「取り出した後に加工したい」なら jq を使ってください — jq は変換言語なので、`map`・`group_by`・`reduce` まで揃っています。用途の目安としては、設定ファイルから値を 1 つ取り出すなら JSONPath、シェルで JSON を加工するなら jq、AWS を触るなら JMESPath です — 選べる場面なら、その環境で既に使われているものに合わせるのが最も摩擦が少ないです。

JSONPath を使う前に、そもそも必要かを考えてください。プログラムの中で JSON を扱うなら、パースしてからネイティブの構造として辿るほうが、型が付き、エラーの場所も分かり、テストも書けます — data.store.book.filter(b => b.price < 10) のほうが、$.store.book[?(@.price<10)] という文字列に埋め込まれた式より確実に読みやすく、IDE の補完も効きます。JSONPath が本当に有効なのは、クエリを実行時に決めたいとき — 設定ファイルで抽出条件を指定する、ユーザーがマッピングを定義する、ログの検索条件を保存する、といった「クエリがデータである」場面です。その場合は、外部から受け取ったクエリの扱いに注意してください — JSONPath 自体はコード実行を含みませんが、再帰下降 $.. を巨大な JSON に対して実行されると、CPU とメモリを消費させられます。入力サイズと式の複雑さの両方に上限を設けてください。

📖 使い方

1

JSON を貼り付け

左側のテキストエリアに JSON データを貼り付けます。サンプルボタンですぐ試せます。
2

クエリを入力

$ から始まる JSONPath 式を入力すると、リアルタイムで結果が更新されます。フィルタやワイルドカードも使えます。
3

結果を確認

マッチした値の配列が右側に整形表示されます。件数とエラーも同時に表示されます。

❓ よくある質問

JSONPath とは何ですか？

XML の XPath に相当する JSON 用のクエリ言語です。$ をルートに、ドット記法・ブラケット記法・フィルタ式で値を抽出します。

フィルタ式 [?(@.price < 10)] はどう書きますか？

@ は現在のノードを指し、==, !=, <, <=, >, >=, &&, || などの比較・論理演算子が使えます。文字列はシングルクォートで囲みます。

再帰下降 (..) は何に使いますか？

深い階層にあるすべての一致を探したいときに使います。$..author は構造のどこにあっても author フィールドを集めます。

🔗 関連ツール

🐛 このツールで問題が発生しましたか？

完全無料・登録不要。再現手順だけでも結構です。届いたご報告は運営者に直接届き、修正の参考にします。