jqの使い方｜JSONから対象を抽出し、件数・合計・確認待ちを照合する

※本記事にはPRを含む場合があります。

こんにちは。『脱会社員』脱サラを応援し続けるブログ、運営者の『なかびー』です。

受け取ったJSONから指定の案件だけを抜き出したい。合計時間は出せたけれど、どの記録を数えたか説明できない。そんな場面では、表示を整えるだけでなく、対象の条件と判断できない値を分けて残すことが必要です。特に、時間が0の記録、空欄に相当する値、数字に見える文字列を同じ扱いにすると、件数や合計を取り違える原因になります。

この記事では、jqを使って架空の作業記録8件を「採用」「確認待ち」「対象外」に分類し、案件Aの採用3件・75分を原本へ戻って検算する手順を解説します。コマンドを実行するだけで終わらず、確認待ちの理由、抽出が0件になる場合、入力そのものが不正な場合を分け、保存した結果と引き継ぐ説明をそろえるところまで扱います。

対象は、すでにjqを利用できる環境で、小さなJSONファイルの抽出や集計を確認したい方です。新規インストール、外部APIからの取得、顧客データの送信は行いません。教材は既存のjq 1.7で実行し、別の計算方法でも分類と合計を照合していますが、実案件での納品実績や受け手の検収を示すものではありません。

各章の画像は、条件や分類の関係を説明するために作った写真調の図解です。実際のターミナル画面や顧客の記録と混同せず、具体的な値と操作例は本文の教材表・コードで確認してください。まずは「何を数え、何を数えず、何を確認待ちにするか」を言葉で決めるところから始めましょう。

抽出する条件と残す証拠を最初に決める

作業を説明する概念写真です。実際のjq画面や顧客データではありません。

整形と集計の仕事を混同しない

JSONを受け取る仕事では、ファイルを読みやすく表示できた段階で作業が終わったように感じることがあります。しかし、依頼が「案件Aの完了した作業時間を確認したい」であれば、整った表示だけでは答えになりません。案件、状態、時間の値を確かめ、どの記録を合計に入れたのか説明できる一覧が必要です。見やすさと、対象が正しいことは別々に確認します。

jqはJSONを入力として扱い、必要な値を取り出したり、条件に合う記録をまとめたりするための道具です。本記事では機能の全一覧を覚えるのではなく、架空の作業記録八件を三つに分ける小さな実務を練習します。採用する記録、確認が必要な記録、今回の対象ではない記録を残し、その内訳と合計が原本に戻って説明できるところを完成条件にします。

ここで扱うのは、すでに利用できるjqがある環境でのローカル処理です。この記事の教材は既存のjq一・七で実行し、別の方法でも結果を照合しました。ソフトの新規導入、実際の受注データの取得、外部サービスへの接続は行っていません。図中の写真は作業を表す概念画像で、ターミナルの実画面や顧客の作業記録ではありません。

採用する条件を短い文章にする

依頼を受けた時点では、質問を二つに分けると整理しやすくなります。一つは「どの案件と状態を数えるのか」、もう一つは「時間の値が条件に合わない記録をどう扱うのか」です。前者だけが決まっていても、後者を自分の判断で補えば結果が変わります。今回は両方を教材の約束として明示しました。実務で後者が未定なら、算入した場合としない場合の数字を勝手に確定値として出さず、確認待ちの対象を先に伝えます。

時間がnull、文字列、負の数になっている記録は、案件と状態の条件に合っていても、今回は合計に入れません。ただし、勝手に零へ置き換えたり、消したりするのでもありません。確認待ちの一覧へ移し、どの値がどの約束に合わなかったかを残します。「計算できないから除外した」という一言だけでは、あとで依頼元が判断を戻せなくなるためです。

案件Bや未完了の記録は、値が読み取れても今回の対象外です。これは記録が誤っているという意味ではありません。ある抽出の対象外であることと、データそのものが不良であることを分けると、不要な修正依頼を減らせます。この教材では、対象外と確認待ちを別の配列に保存して、両方を一つの「削除した件数」にまとめない設計にします。

元ファイルと結果を別々に残す

記録したいのは、入力ファイル、実行した条件、使ったjqの版、出力先、確認した結果です。すべてを大きな報告書にする必要はありません。短いメモでも、どの原本にどの条件を使ったかが追えることを優先します。作業日だけを書いておく方法では、同じ日に複数の修正版を受け取ったときに、どちらを処理した結果か分からなくなります。

また、他人のJSONを練習用のオンライン画面へ貼り付けることを前提にしません。JSONの中には、見た目が単なる番号でも案件管理上の情報が含まれることがあります。今回は架空データをローカルで処理し、外へ送らずに検算する流れです。実データを使う場合の共有先や保存場所は、依頼内容と許可された範囲に合わせて別途確認してください。

八件の入力を読み、型と識別子を確かめる

作業を説明する概念写真です。実際のjq画面や顧客データではありません。

一つの記録と一覧全体を分ける

教材のtasks.jsonは、八つのオブジェクトを一つの配列に入れた形式です。それぞれの記録にはid、project、status、minutesという四つの項目があります。idは記録を追うための識別子、projectは案件、statusは状態、minutesは分単位の時間です。この形を先に読むことで、一覧全体にかける処理と、一件ずつの記録にかける条件を混同しにくくなります。

表が画面に収まらない場合は横にスクロールして確認してください。数値・記録は架空教材です。

[
  {
    "id": "T001",
    "project": "A",
    "status": "done",
    "minutes": 30
  },
  {
    "id": "T002",
    "project": "A",
    "status": "done",
    "minutes": 45
  },
  {
    "id": "T003",
    "project": "B",
    "status": "done",
    "minutes": 20
  },
  {
    "id": "T004",
    "project": "A",
    "status": "pending",
    "minutes": 15
  },
  {
    "id": "T005",
    "project": "A",
    "status": "done",
    "minutes": null
  },
  {
    "id": "T006",
    "project": "A",
    "status": "done",
    "minutes": "25"
  },
  {
    "id": "T007",
    "project": "A",
    "status": "done",
    "minutes": 0
  },
  {
    "id": "T008",
    "project": "A",
    "status": "done",
    "minutes": -5
  }
]

表のT001は案件A、done、三十分です。T002は同じ案件と状態で四十五分、T007は零分です。零は未入力を表す記号として使っているのではなく、この教材では記録された数値として扱います。現場で零分の扱いが異なるなら、同じフィルターをそのまま流用しないでください。データに意味を与える約束は、道具の初期設定ではなく仕事の条件です。

T005のnull、T006の文字列の二十五、T008の負の五は、それぞれ違う状態として用意しました。見た目だけで二十五を数値と決めたり、負の五を絶対値に直したりすると、原本にない判断が入り込みます。本記事では型や値を勝手に補正せず、確認待ちへ分けます。扱いやすい値へ変える前に、なぜその値になっているかを確かめる余地を残します。

文字列の番号を数に変えない

確認表を作るときには、idに加えて元の行の順序も残しておくと、原本と見比べやすくなります。ただし、順序を識別子の代わりにしないことが前提です。今回の採用結果はT001、T002、T007という入力時の順に並びます。並べ替えを加える必要が出たときは、結果の順番が原本と変わることを明記し、照合はidで行います。結果の三番目を「原本の三件目」と読み替えないための小さな工夫です。

idのT001からT008は、そのまま文字列として使います。番号らしい部分だけを取り出して数値にする必要はありません。抽出後の一覧で元のidを残しておけば、依頼元から一件だけ質問を受けたときも、その記録に戻れます。表示順の一番目、二番目だけで説明すると、並べ替えや追加のたびに指している記録が変わってしまいます。

入力の確認では、八件あることに加えてidの重複がないことも確かめます。重複がある場合に先頭の一件だけを残すか、二件とも残すかは別の業務判断です。本教材は八つの異なるidを前提としているため、重複していたらその前提が崩れたと分かる検査を置きます。識別子を確認することと、重複記録を自動で削除することは同じ操作ではありません。

八件という件数を検査に書いているのも、固定された練習用入力だからです。毎日件数が変わる実務ファイルにそのまま使うと、正しい九件の入力を異常と判断してしまいます。実務へ広げるときは、受領した件数や仕様に合う検査へ変えます。今回の八件確認は汎用の品質保証ではなく、用意した教材が想定どおりかを確かめるためのものです。

構文と仕事の条件を別に検査する

JSONとして読み込めることと、今回の抽出に必要な項目がそろっていることも別です。たとえば、一覧の代わりに一つの文字列が入っていても、JSONとしては成立します。そこで教材では配列であること、各記録がオブジェクトであること、idと案件と状態が文字列であること、minutesという項目があることを確認します。これでも全業務の検証を終えたことにはなりません。

minutesをすべて正しい数値に限定して入口で落とさないのは、確認待ちの記録も一覧として返したいからです。入口でファイル全体を止める検査と、読み取った後で一件ずつ保留へ分ける検査は、目的が違います。今回は構造が分かる八件を受け取り、その中の時間の問題を明示する設計です。読めない原本を無理に部分採用する設計ではありません。

条件に合う記録と確認待ちを分けて抽出する

作業を説明する概念写真です。実際のjq画面や顧客データではありません。

条件式を保存して読み返せる形にする

掲載するフィルターでは、時間の妥当性をvalid_minutesという一つの判定にまとめます。採用側と確認待ち側で別々の時間条件を書くと、片方だけ直したときに間に落ちる記録が生まれる可能性があります。同じ判定を使い、確認待ちではその否定を使う形にすると、今回の条件の関係を読み返しやすくなります。短い名前を付けたこと自体が検証ではないので、実際の三分類とidの対応は別に確かめます。

長い条件を毎回一行のコマンドへ書き込むと、引用符を直す途中で条件まで変えてしまうことがあります。この教材では処理をpartition.jqというファイルへ保存し、コマンドではそのファイルと入力を指定します。公式マニュアルにもフィルターをファイルから読む方法が示されています。条件の本体を独立させると、何を実行したかを後から読み比べやすくなります。

今回の条件では、まず時間が数値かを確かめ、数値の場合だけ零以上かを調べます。文字列やnullを数値と直接比べて意図しない判定にしないための分岐です。実務で「数らしい文字列も使ってよい」と合意している場合は、変換の規則と失敗時の扱いを別に決めます。今回は変換そのものをしないので、元の文字列の二十五は確認待ちに残ります。

以下が教材のpartition.jqです。値の訂正はせず、三つの分類と件数・合計を出力します。

def valid_minutes: if (.minutes | type) == "number" then .minutes >= 0 else false end;
. as $all
| {input_count: length,
   accepted: map(select(.project == $project and .status == "done" and valid_minutes)),
   review: map(select(.project == $project and .status == "done" and (valid_minutes | not))),
   excluded: map(select(.project != $project or .status != "done"))}
| . + {accepted_count: (.accepted | length), review_count: (.review | length), excluded_count: (.excluded | length), total_minutes: ((.accepted | map(.minutes) | add) // 0)}

案件名はコマンドの引数でAとして渡します。フィルターの中で案件Aを何度も直接書き換える代わりに、一か所の指定で比較対象を選べる形です。ただし、変数にしたから条件が正しくなるわけではありません。入力する案件名を間違えれば、間違った対象の結果が正確に計算されます。実行前には対象案件の指定と依頼内容を照合します。

三つの箱に同じ記録を重ねない

採用の配列には、案件と状態が一致し、時間の条件も満たす記録を入れます。確認待ちの配列には、案件と状態は一致しているものの、時間の条件を満たさない記録を入れます。対象外の配列には案件または状態が今回の条件と違う記録を入れます。この三つに分けることで、案件が違う記録を時間の不備として相手へ返すことを避けています。

T003は案件Bなので、二十分という値が正しくても対象外です。T004は案件Aですがpendingなので、十五分を今回の合計へ入れません。一方、T005からT008のうち問題のある三件は、案件Aのdoneという条件までは満たしています。この違いを説明できると、依頼元は「対象を広げたい」のか「時間を確認したい」のか、次の判断を分けられます。

三つの配列の件数が八件へ戻ることに加えて、idの重なりがないことを確認します。件数だけを足して八になっても、一件が二つの箱へ入り、別の一件が抜けている可能性はあります。教材では採用、確認待ち、対象外のidを元の八件と対応させて照合します。合計の数字が合ったという一点だけで、分け方全体を合格にしないことが大切です。

保留を勝手に補正しない

確認待ちのT005はnull、T006は文字列、T008は負の数です。どれも今回の合計にそのまま使わない点は同じですが、返す質問は同じではありません。未記録なのか、文字として入力されたのか、訂正や差し引きを表しているのかを確認する必要があります。事情を確かめずに一律で零にすれば、結果は出しやすくても原本の意味を変えてしまいます。

返答を受けた場合も、いまの結果ファイルだけを書き直すのではなく、合意した修正版の入力を別名で残して処理をやり直します。元のT006が本当に二十五分でよいと確認されたとしても、その判断をいつ誰から受けたかが分からなければ、後の検算で説明が途切れます。練習では実際の返答を作らず、三件は確認待ちのままにしておきます。

抽出に使った条件を変更したときは、新しい結果と古い結果を別の版として扱います。たとえばpendingも含める変更は、単なる見た目の修正ではありません。対象の範囲が増えるため、件数も合計も変わり得ます。「最新版」という名前だけで上書きを繰り返すより、条件の変更点を短く残して、比較できる二つの結果を保持するほうが安全です。

件数と合計を元の八件へ戻って検算する

作業を説明する概念写真です。実際のjq画面や顧客データではありません。

七十五分になる内訳を確認する

合計を手で確認する際は、原本の時間だけを上から全部足すのではなく、先に採用idを確定してからその値を読み取ります。元の八件には別案件や確認待ちが混在しているからです。T001の三十分、T002の四十五分、T007の零分を列挙したうえで七十五分と照合すれば、条件の確認と計算の確認を二段階に分けられます。数字だけが偶然一致した可能性を減らすために、内訳の列挙を省略しないようにします。

教材で採用されるのはT001、T002、T007の三件です。時間は三十、四十五、零なので、合計は七十五分になります。零分の記録を含むため、採用三件と「時間が正の数の記録二件」は一致しません。この二つを取り違えると、集計結果に三件と書かれているのを誤りだと判断したり、零分の記録を消したりする原因になります。

出力には合計だけでなく、採用した記録の配列も残します。七十五という数字だけを渡すと、T003の二十分を含めたのか、T006の二十五を変換したのかを相手が確認できません。記録一覧と合計を同じ結果に持たせておけば、集計の対象と値を一緒に見られます。相手に不要な項目がある場合は、削る前に必要な照合手段を相談します。

本記事の実行ではjqの結果をPythonによる別の条件式と照合し、採用idと七十五分が一致することを確認しています。これは架空の八件に対するローカル検算です。実際の勤怠、報酬、請求額、売上を確認したという意味ではありません。教材のminutesは練習用の小さな整数であり、そのまま給与計算などの正確性を保証する例には使いません。

八件の行き先をすべて説明する

表が画面に収まらない場合は横にスクロールして確認してください。数値・記録は架空教材です。

対象外の二件は、この教材では別案件と未完了に一件ずつ分かれています。結果を読む人が内訳を知りたい場合は、元のprojectやstatusを見れば理由に戻れます。必要なら説明用の列を加える設計もできますが、最初から多くの分類を足すより、今回の判断に必要な三分類を確実に確認することを優先します。分類が細かいほど品質が高いとは限りません。

確認待ち三件を結果から隠すと、七十五分が案件Aの完了時間の総額のように見えてしまいます。正しくは、今回の条件で採用できた三件の合計が七十五分で、別に確認待ち三件が残っています。報告文ではこの二つをセットで示します。未確認の時間があるのに「案件Aは七十五分で確定」と表現しないことが、数字を扱う仕事で重要な区別です。

空の結果と失敗を見分ける

案件指定をZへ変えた追加試験では、入力八件は同じまま、採用零件、確認待ち零件、対象外八件になりました。この場合の合計零分は、対象に合う記録がない結果として計算したものです。一方、構文不正のJSONでは読み込みに失敗しています。どちらも画面に欲しい明細が出ない場合がありますが、確認できた事実はまったく違います。

表が画面に収まらない場合は横にスクロールして確認してください。数値・記録は架空教材です。

対象が零件のときは、まず案件指定と入力の範囲を確かめます。本当に対象がないのか、案件名の表記が違うのか、別の日の原本を使ったのかを順番に確認します。結果を増やすために条件を緩めるのは、依頼の意味を変える操作です。対象がないという結果にも価値があるため、期待した件数に合わせて条件を変更しないでください。

また、処理が正常に終わったという終了状態だけで内容の正しさを決めないようにします。条件が間違っていても、文法として正しければ実行は完了し得ます。逆にエラーが返ったときは、出力ファイルが作られていたとしても中身を完成成果として渡しません。入力の読取り、条件の適用、結果の検算という三段階を、それぞれ別の確認事項として扱います。

条件と結果を保存して同じ入力で確かめ直す

作業を説明する概念写真です。実際のjq画面や顧客データではありません。

コマンドとフィルターを一式にする

check.jqの確認には終了状態を使う指定を付けていますが、終了状態だけを短絡的に合格印へ変換しません。教材の検査式が真であることは、八件という形と項目の前提が一致したという意味です。その後に確認待ち三件が出ることは矛盾ではありません。入口で確認する構造の条件と、集計へ採用する時間の条件を分けてあるためです。この段階差を作業メモへ一行添えると、後から結果を読む人が戸惑いにくくなります。

成果物として残すのは、入力のtasks.json、条件を書いたpartition.jq、入力を確認するcheck.jq、実行結果のresult-A.jsonです。名前を分けることで、何を受け取り、どう処理し、何が出たかが整理できます。コマンドは後の例にまとめていますが、実行する前にファイルの置き場所と名前を自分の環境で確かめてください。記事の表示例を実行済みの証拠にはしません。

次は教材ディレクトリ内での実行例です。出力先は必ず入力と異なる名前にします。後続処理へ進む前に、直前の検査が成功したことを確認してください。

jq --version
jq -e -f check.jq tasks.json
jq --arg project A -f partition.jq tasks.json > result-A.json
jq --arg project Z -f partition.jq tasks.json > result-Z.json
jq . result-A.json

check.jqはこの8件の教材専用です。件数が変わる実務データへそのまま適用しないでください。

type == "array" and length == 8
and all(.[]; type == "object" and (.id|type)=="string" and (.project|type)=="string" and (.status|type)=="string" and has("minutes"))
and ([.[].id]|unique|length)==8

ファイルからフィルターを読む形にしても、すべての環境差がなくなるわけではありません。ターミナルの種類、出力の保存方法、文字コードの扱いなどは確認が必要です。本文の実試験はローカルのシェル環境で行いました。Windowsの各シェルで同じ表示になることまで実測したとは記していません。未確認の環境へ渡すときは、その環境で小さな教材を先に試します。

jqの版を控えるのは、新しい版なら必ず正しいという意味ではありません。後で同じ処理を確認する際、どの道具で行ったかを説明するためです。今回の公式資料は実行した一・七に対応する説明を参照し、別の版の追加機能を実測した扱いにしていません。版を上げる必要がある場合は、仕事の環境や許可範囲を確認して別の変更として扱います。

出力を開き直し入力の保持を確かめる

出力を保存したら、別の読取りでJSONとして開き直します。作業中のターミナルに見えていた内容と、実際に保存されたファイルが同じとは限らないからです。今回の教材では保存した結果を再読取りし、採用件数、確認待ち件数、対象外件数、合計、採用idを確認しました。保存ファイルを確認しないまま、画面上の結果だけを成果として渡さないようにします。

同時に、入力ファイルを変更していないことも確認します。今回の処理は抽出と結果の作成であり、原本の時間や状態を編集する仕事ではありません。原本の内容が変わっていれば、同じ結果を再現できる前提が崩れます。ファイルの内容を比較する方法やハッシュを控える方法など、作業規模に合うやり方で、使った入力を特定できるようにします。

なお、ハッシュが一致したことは業務内容の正しさを保証しません。同じバイト列のファイルを確認する手段であって、そこに書かれた時間が実際の作業時間か、状態が最新かまでは分かりません。本記事では、原本を取り違えないための確認と、記録の内容に対する判断を別々に扱います。機械的な一致だけで確認待ちを完了に変えないことが大切です。

改訂の前後を比較できるようにする

入力が差し替わったら、新しい入力に同じ条件を適用したのか、条件も変えたのかを分けて記録します。二つを同時に変えると、結果が増減した理由を追いにくくなります。可能なら入力の変更と条件の変更を一段階ずつ確認し、どちらが結果に影響したかを説明できる状態にします。これは処理を遅くするためではなく、やり直しの原因を狭くするためです。

たとえば、依頼元が対象案件をAからBへ変更した場合は、案件指定の変更です。T006の時間を数値に訂正した場合は、原本の変更です。どちらも結果の数字が変わる可能性がありますが、確認する相手や理由は異なります。改訂メモに「修正しました」とだけ書かず、対象条件を変えたのか、入力の訂正を反映したのかを短く示してください。

本教材ではそうした訂正を受けたことにはしていません。Aの結果と、空結果の試験用Zの結果を作り、元の八件はそのまま保持しています。架空の依頼元から承認を得た、実案件で納品して評価された、作業時間を短縮できたといった実績はありません。確認した操作と、今後実務で確かめる必要があることを分けた教材として使ってください。

渡す前に未確認と次の判断を短くまとめる

作業を説明する概念写真です。実際のjq画面や顧客データではありません。

合計だけではなく条件を添える

受け渡すファイルの数も多ければよいわけではありません。相手が結果だけを必要とするなら、作業用の一時ファイルを無差別に渡す必要はありません。一方、条件の確認や再現が必要な案件では、入力の参照先とフィルター、結果の対応を残す価値があります。どこまでを納品物に含めるかは依頼の範囲で決め、原本や確認待ちを勝手に公開する判断には広げません。本記事の一式は練習と確認のための構成です。

受け渡しの説明は、「案件A、done、数値で零以上の時間を採用し、三件で七十五分。確認待ち三件、対象外二件」といった形にします。これなら、数字の対象と残件を同じ文で伝えられます。「合計七十五分です」だけでは、何を除外したかが分かりません。相手が判断するために必要な条件を、結果の数字から切り離さないようにします。

• 対象：案件A、状態done、時間が数値で0以上。
• 結果：採用3件・75分、確認待ち3件、対象外2件。
• 未確認：実案件への適用、実データの正確性、受け手での確認。

確認待ちの質問は、idと元の値を添えて行うのが基本です。T005は時間がnull、T006は文字列、T008は負の値なので、どの扱いが正しいかを確認したい、と分けて示します。値を直す提案をする場合も、原本をすでに変更したように書かないでください。提案、相手の回答、修正反映、再検算はそれぞれ別の段階です。

結果ファイルの場所や名前も、対象の版とともに伝えます。メールや共有フォルダーなど実際の受け渡し先は、本記事では操作していません。ファイルがローカルに保存できたことと、相手へ届いて開けたことも別です。実務では指定された方法で渡し、必要な場合には受領や表示を確認しますが、未確認の受領を完了報告に含めないようにします。

作業範囲を広げる前に小さく検証する

八件でできた処理を、大きなファイルへそのまま適用する前に、入力の形や値の種類が同じかを確かめます。別のシステムが出力したJSONでは、一覧の中にさらに別の一覧が入っていたり、時間が秒で記録されていたりすることがあります。ファイルの拡張子が同じというだけで、同じ条件を使えるとは限りません。対象の構造と単位を先に照合します。

また、データを抽出する処理が得意でも、そのデータをどこへ送ってよいか、誰が確認してよいかは別の問題です。便利な共有先を勝手に追加したり、実データを外部の検査サイトへ投入したりしないでください。今回の練習は、架空データを既存のローカル環境で処理し、結果を保存するところまでです。操作できることと、許可されていることを分けます。

小さな一式を説明できることを完成にする

最後に、自分で三つの質問へ答えてみてください。七十五分へ入っているidはどれか、確認待ちの三件をまだ足していない理由は何か、案件Zの零件と構文不正の失敗はどう違うか、という質問です。コマンドを見ずに答えられなくても構いません。保存した入力、条件、結果をたどって説明できるなら、記憶だけに依存しない確認手順ができています。その状態を目指すほうが、結果の数字だけを覚えるより実務に応用しやすくなります。

最初から多くの機能を詰め込む必要はありません。配列を受け取る、条件で分ける、対象の値を足す、件数とidを照合する、保存した結果を開き直す。この流れを一つの教材で確実に行い、次に必要な条件が出たときだけ拡張します。処理を短くする工夫より先に、読み返した自分や他の人が何をしているか理解できる構成を選びましょう。

1. 原本と対象条件を固定する。
2. 構造を確認し、三分類を出力する。
3. 件数・id・合計を照合する。
4. 結果を開き直し、未確認を添える。

JSONそのものの記法や型の違いから確認したい場合は、関連記事の作成・検査ガイドから戻ることができます。本稿の役割は、その後に受け取ったデータを扱い、対象を選ぶ条件と未確認を可視化することです。数字を出す作業と、数字を信頼してよい範囲を説明する作業をセットにして、納品前の確認を進めてみてください。

公式資料と関連記事

• jq 1.7公式マニュアル：ファイルからのフィルター読取り、引数、型、配列操作などの確認。
• jq公式チュートリアル：入力から値を取り出す基本の確認。本記事は外部APIへ接続していません。
• JSONの書き方と納品前チェック：記法・型・構文から確認したい場合の関連記事。

公式資料は2026年10月16日（日本時間）に確認。実教材の実行環境はjq-1.7です。掲載した分類と検算は架空データに対する確認であり、受注・収益・実案件の検収完了を示すものではありません。