JSONの書き方｜商品素材データの作成・検査と納品前チェック

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

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

商品登録やWeb制作の副業で、商品名、説明文、画像のファイル名をまとめて渡す場面があります。そのときにJSONでの納品を指定されたら、まず「どの情報を、どんな型で、どこまで確認して渡すか」を決めましょう。括弧の形を覚えるだけでなく、依頼者が受け取って使える状態を具体的にすることが大切です。

この記事では、架空の商品3件と画像素材の情報4行を使い、JSONの書き方から納品前の検査までをつなげて説明します。先頭ゼロのある商品ID、説明文の引用符と改行、確認待ちのnullを扱い、読めるデータと引き渡してよいデータを分けて考えます。商品・素材名・承認状態はすべて教材用です。実在商品の台帳や受託実績ではなく、画像ファイル本体も含みません。

JSONを使うかどうかは納品先の指定によります。学習しただけで案件を得られる、収入が増えるといった保証はありません。ここで身に付けたいのは、自分が整えたデータの仕様と確認結果を相手に説明する力です。プログラムの実行例はNode.jsとPythonで検証した小規模教材であり、特定のショップへの取り込みを保証するものではありません。

JSON納品は、書き始める前の仕様合わせで決まる

CSVとJSONの形式比較の模式図。図中の商品例は本文の3商品データとは異なります。

「商品データ一式」を具体的な納品物にする

依頼が「素材を整理してJSONにしてください」だけなら、すぐ入力を始めると後から作り直しになりがちです。商品ごとに一つの画像だけなのか、正面・側面の複数画像を持つのか。商品説明は改行を残すのか。まだ確認されていない画像説明を空欄にしてよいのか。これらは記号の書き方より先に確認する内容です。

最初の打ち合わせでは、受け取りに使うシステムの仕様書や、使用が許可されたサンプルを見せてもらいます。既に決まった項目名があれば、その名前をそのまま使います。こちらが分かりやすいと思ってproduct_idをidに変えても、受け取る処理がproduct_idを探していれば目的を果たせません。日本語の説明資料と実際のキー名を対応させておくと、双方が確認しやすくなります。

この教材の納品単位は、商品3件を持つ一つのファイルです。先頭にschema_versionという仕様番号を置き、productsに商品の一覧を入れます。各商品にはproduct_id、title、description、tags、images、approvedを用意します。この名前や構成がJSON全体の決まりというわけではありません。これから作る教材の中で、説明と検査の基準をそろえるための取り決めです。

CSVとJSONは、受け取る側の使い方で選ぶ

全商品が同じ列を持ち、人が表計算ソフトで順番に入力するなら、CSVの方が扱いやすい場合があります。一方、商品ごとに画像の数が違い、一枚の画像にファイル名と説明をまとめて持たせたいなら、JSONの入れ子で所属を表現できます。形式の新しさや格好よさではなく、相手の作業に合わせて選びましょう。

ただし、複数画像があるから必ずJSONにする必要はありません。商品表と画像表を分けたCSVを相手が求めているなら、その構成に従います。指定のない案件で、相手が開けるかを確認せずJSONだけを送るのは避けたいところです。「このサンプルを御社の確認環境で読み込めますか」と少量を先に渡し、形式の合意を取ると手戻りを減らせます。CSVをPythonで読み書きする場合は、文字コード・列・書き出し後の確認手順も確認してください。

※表は横にスクロールできます。条件はこの教材の例です。

作業範囲と検収条件は別々に書く

素材データを作る仕事に、画像の撮影、加工、権利確認、商品説明の執筆がすべて含まれるとは限りません。たとえば「支給されたファイル名を転記する」と「画像を開いて説明文を作る」では必要な作業が違います。JSONにalt欄があることだけを理由に、画像の内容を想像して埋めてはいけません。入力する情報の提供元と、誰が最終判断するのかを確認します。

検収条件は「JSONファイルを渡した」で終わらせず、商品数、素材数、必須項目、確認待ちの扱いまで書きます。この教材では、商品3件と画像メタデータ4行がそろい、IDと文字が保持され、承認済みかつ全画像のaltが空白だけでない文字列の商品を準備完了とします。残りは確認待ちとして報告します。これは説明用の合意であり、一般的な契約上の検収基準を示すものではありません。

修正回数だけでなく、入力元が途中で変わった場合の扱いも決めておくと安心です。初回の誤入力修正と、依頼者による商品追加は作業の原因が違います。追加分を黙って元のファイルに混ぜるより、「商品が一件増えたため件数の基準も変わる」と先に共有すると、納品後の照合がしやすくなります。副業の限られた時間で対応するなら、確認待ちがある時点で一覧を出すことも大切です。

値と型をそろえ、商品IDの先頭ゼロを守る

先頭ゼロを含む商品IDを文字列で保持します。図の0007は半角二重引用符で囲んだ文字列です。

数字に見えても、識別用なら文字列にする

商品IDの0007は、計算するための数ではなく、商品を区別するための記号です。この教材では二重引用符で囲み、”0007″という文字列にします。7という数値に変えると先頭のゼロがなくなり、元の台帳や画像名との対応を取りにくくなります。表計算ソフトで既にゼロが消えている場合、JSONに変換しても元の桁数を自動で取り戻せるわけではありません。

数値として007と書く方法も使えません。JSONの数値表記では、このような先頭ゼロを付けた整数は受け付けられません。「ゼロを残したいから数値の前にゼロを足す」のではなく、項目の型を文字列として扱います。入力時、変換時、確認時のすべてで文字列という約束を守る必要があります。

桁数の大きな管理番号にも気を付けましょう。JavaScriptの通常の数値には正確に表せる整数の範囲があり、長い番号を数値として読み込むと別の値になる場合があります。この教材のNode.js検査でも、9007199254740993を数値として読むと元の十進表記を保持できないことを確認しました。管理番号を計算する予定がなければ、桁の大小にかかわらず仕様に合わせて文字列として渡す方が意図を明確にできます。

文字列、真偽値、nullを見た目で置き換えない

titleは文字列、approvedはtrueまたはfalse、確認前のaltにはnullを認める、というように型を項目ごとに決めます。”false”は文字列なので、falseという真偽値とは異なります。”null”も文字列であり、nullを表す特別な値ではありません。人の目で似て見えても、受け取る処理では別のものです。

商品0009はapprovedがfalseで、画像のaltがnullです。このデータ自体は正しいJSONとして表現できます。ただし、この教材では未承認で説明文も確認待ちなので、準備完了に数えません。構文を通すためにfalseをtrueへ変えたり、nullを適当な説明に置き換えたりすると、確認済みという情報を勝手に作ることになります。値の修正は元資料や担当者の回答を根拠に行います。

※表は横にスクロールできます。条件はこの教材の例です。

空文字・空配列・欠落に別の意味を持たせる

空文字の””、空配列の[]、null、項目がない状態は区別します。今回、商品0008のtagsは空配列で、タグがゼロ件であることを示します。tagsというキーごと省略する運用にはしていません。相手が必ずtagsを読む設計なら、空配列を渡すことで「一覧はあるが中身はゼロ」と伝えられます。

altについては、nullを「確認待ち」と定めます。空文字を同じ意味として認めるかどうかは別途決めることです。この教材の準備完了判定では、空文字や空白だけの文字列も合格にしません。一方、実際のWebページでは装飾目的の画像など、空の代替テキストが適切な場合があります。教材の納品条件を、そのまますべての画像のアクセシビリティ規則に置き換えないでください。

項目の省略は、情報が不要なのか、入力忘れなのかを判別しづらくします。依頼者が任意項目として省略を認めるなら、その条件を書きます。必須項目なら値が未確定でも合意した方法で状態を残します。「未定」「なし」「該当なし」をすべてnullに集約する前に、受け取る側が区別を必要としていないかを確かめましょう。

型の仕様は、きれいな一覧を作っただけでは機能しません。最初の一件を相手に見てもらい、「このIDは文字列のまま」「タグなしは空配列」「未確認のaltはnull」と具体例で確認します。その小さな合意が、後から大量のデータを直す負担を減らします。

配列と入れ子で、商品3件と画像4行を組み立てる

商品と素材情報の対応を示す模式図。「完成」は本文の教材上の準備完了を示し、本番への取り込みや公開の完了ではありません。

一つの商品と、商品の一覧を分けて考える

オブジェクトは、項目名と値を組にして中括弧で囲みます。商品一件の中で、商品名や説明文を別々の項目として持たせられます。配列は角括弧で囲んだ値の並びです。productsには商品オブジェクトを三つ入れます。まず一件を作って項目を確認し、その構成を二件目、三件目へ広げると、括弧の対応を追いやすくなります。

商品の中にあるimagesも配列です。商品0007には正面と側面の二件、0008と0009にはそれぞれ一件の画像情報を入れます。画像情報の一件はfilenameとaltを持つオブジェクトです。こうすると、ファイル名と説明文が同じ画像に属していることを構造で示せます。

ファイル名だけの配列と説明文だけの配列を別々に作り、同じ順番だから対応するという設計も考えられます。しかし、片方だけ並べ替えたり一件削除したりすると対応がずれます。この教材では、一枚分を同じオブジェクトに入れる方法を選びます。発注側の既存仕様がある場合は、その仕様を優先し、独断で構造を変えないでください。

教材の完成データを読み解く

次のデータは、確認待ちを含めた作業台帳の完成例です。すべてが公開可能という意味ではありません。商品0009の保留理由まで残しているので、後から何を確認する必要があるかを追えます。実際に試すときは、コード部分だけをUTF-8のテキストとしてfixture-products.jsonという名前で保存します。前後の解説文やコード枠の記号をファイルへ入れないようにします。

{
  "schema_version": 1,
  "products": [
    {
      "product_id": "0007",
      "title": "机の上の\"小物\"",
      "description": "一行目\n二行目",
      "tags": [
        "収納",
        "白"
      ],
      "images": [
        {
          "filename": "product-0007-front.png",
          "alt": "白い小物入れを正面から見た図"
        },
        {
          "filename": "product-0007-side.png",
          "alt": "白い小物入れを横から見た図"
        }
      ],
      "approved": true
    },
    {
      "product_id": "0008",
      "title": "布のポーチ",
      "description": "保存先の例: C:\\drafts\\assets",
      "tags": [],
      "images": [
        {
          "filename": "product-0008-front.png",
          "alt": "青い布のポーチ"
        }
      ],
      "approved": true
    },
    {
      "product_id": "0009",
      "title": "木のトレー",
      "description": "説明文は確認中",
      "tags": [
        "木製"
      ],
      "images": [
        {
          "filename": "product-0009-front.png",
          "alt": null
        }
      ],
      "approved": false
    }
  ]
}

この例では、商品数が3、imagesの合計件数が4になります。商品数と画像数が一致していないのは、商品0007に二枚分があるためです。納品前に「商品が3件あるから素材も3件」と判断せず、別の数として照合します。逆に、素材が4行あるというだけでは、商品0007に必要な二枚がそろった証明にはなりません。各商品の中身まで確認しましょう。

順番と所属を納品の約束に含める

配列の順番には意味を持たせられますが、その意味は受け渡しの仕様で決めます。たとえば「imagesの先頭を一覧用画像にする」と合意したなら、画像の並べ替えは表示結果に関係します。今回のデータは正面、側面の順で記載していますが、実際のショップがこの順序を採用するかは未検証です。ファイル名にfrontと書いたことだけで自動的にメイン画像になるとは考えないでください。

一方、オブジェクト内の項目を、titleが先だから優先される、といった前提で扱うのは避けます。仕様確認では項目名を使います。読みやすさのために全商品でキーの並びをそろえるのは有効ですが、相手の処理がその見た目の順序に依存する設計とは区別しましょう。JSONの型と構造の基本はRFC 8259の仕様で確認できます。

商品を増やすときは、括弧を複写しただけで安心せず、IDと素材の所属を確認します。前の商品をコピーして新商品を作ると、titleだけ直してproduct_idやfilenameを残すことがあります。三件の小さな教材でも、IDの一覧を先に書き出してから照合する練習をしておくと、転記の見落としに気付きやすくなります。

引用符・改行・バックスラッシュを壊さず書く

文字の役割を示す模式図。JSON入力は本文の半角二重引用符を使用します。

表示する文字と、ファイル上の表記を区別する

商品名に引用符が含まれるとき、文字列の境界に使う二重引用符と、その中に含めたい引用符を区別しなければなりません。教材のタイトルは、読んだ後には「机の上の”小物”」という文字になります。JSONのファイル上では、内側の引用符の前にバックスラッシュを付けます。このように特別な文字を表す書き方をエスケープと呼びます。

説明文の改行も同じ考え方です。文字列の内部にそのまま改行コードを入れる代わりに、ファイル上では\nと記載します。読み込んだ値の中では改行になります。文字列の外側で、項目ごとに行を分ける整形用の改行とは役割が違います。読みやすく整形したJSONの行数と、商品説明が表示される行数を混同しないようにします。

保存先の例として入れたC:\drafts\assetsは、バックスラッシュ自体を含みます。JSONの中で一つのバックスラッシュを表すには、二つ重ねて書きます。今回のパスは文字の扱いを説明する架空例で、利用者のパソコンにそのフォルダーがあることを示しません。パスの文字列が正しく保持されたことと、その場所にアクセスできることは別の確認です。

※表は横にスクロールできます。条件はこの教材の例です。

二重にエスケープしたときの違いを確かめる

説明文を別のシステムからコピーすると、既にエスケープされている場合があります。改行を表す\nを、さらに文字として残すよう変換すると、読み込んだ後もバックスラッシュとnが並び、改行になりません。逆に、エスケープされていない引用符を手作業で貼ると、文字列の終わりとして読まれて構文エラーになります。まず元データが「表示用の文字」なのか「JSONの一部」なのかを確認しましょう。

手作業で大量のバックスラッシュを足すより、値を保持したデータから標準のシリアライザーでJSON文字列を作る方が、記号の付け忘れを減らせます。JavaScriptならJSON.stringifyを使います。ただし、変換元の値が既に間違っていれば、その内容のまま出力されます。自動変換が商品情報の正しさまで判断してくれるわけではありません。

この教材のデータは、文字列、数値、真偽値、null、配列、オブジェクトだけで構成しています。プログラムの中で使える値がすべてJSONにそのまま入るとは考えないでください。たとえばundefinedや関数を含むJavaScriptのオブジェクトを渡すと、単純なデータの往復とは異なる結果になります。日付を独自の形式で扱う場合も、どの文字列表現にするかを別途合意します。

よく似た記号と末尾カンマを点検する

入力時には、二重引用符が文書作成ソフトの装飾的な引用符へ置き換わっていないかを見ます。値を囲む記号として使うのは半角の二重引用符です。一重引用符で囲む書き方や、最後の項目の後ろに余分なカンマを置く書き方は、この教材で使う厳密なJSONとしては通りません。解説用のコメントもJSONの本文には入れず、別の仕様書へ記載します。

エラーが出たら、まず最初に示された位置の少し手前を確認します。閉じ引用符や区切りのカンマが抜けると、実際の原因より後ろで読み取りが止まることがあります。ファイルを全部書き直す前に、最後に変更した商品一件を確認すると原因を絞れます。修正は元ファイルの控えを取ってから行い、構文が通った後にも値の確認を続けます。

構文・重複キー・納品条件を順番に検査する

検査の役割を示す模式図。入力するJSONは本文のコード例を参照してください。

JSON.parseで分かることと、残る確認

JSON.parseはJSON文字列を読み込むJavaScriptの機能です。末尾カンマ、一重引用符、数値007、undefined、NaN、コメントを含む六つの不正例について、今回のNode.js環境では構文エラーになることを確認しました。基本的な動作や例外はMDNのJSON.parseの解説で確認できます。

ただし、同じオブジェクトに同じキーを二度書いた場合は別の問題です。JSON.parseだけで重複キーを検出できるとは言えません。今回、{“id”:”old”,”id”:”new”}を読み込むと、後ろのnewが残ることを確認しました。読み込み後のオブジェクトだけを見ても、最初にoldがあったという情報は取り戻せません。

ここでいう重複キーは、一つのオブジェクト内でproduct_idを二度書くような問題です。別々の商品オブジェクトに同じproduct_idの値が付いている「商品IDの重複」とは異なります。前者は読み取り時点で検出する仕組み、後者は商品一覧を読み込んだ後で値を比較する仕組みが必要です。同じ「重複」という言葉でも、確認する場所を分けましょう。

重複キーは辞書へ変換される前に止める

この教材ではPython標準のjsonモジュールを使い、object_pairs_hookに検査用の関数を指定します。この仕組みで受け取ったキーと値の組を順番に確認し、既に出てきたキーがあればエラーにします。Pythonのデコーダーが標準設定だけで必ず重複を拒否する、という意味ではありません。重複を拒否するための検査をこちらで付けています。

次の短い例は、構文と重複キーを調べる読み取り部分です。fixture-products.jsonと同じ場所にcheck-json.pyとして保存し、Python 3が使える環境でpython3 check-json.pyを実行します。実行環境の準備が必要な人は、業務用パソコンの管理ルールを確認してから進めてください。検査のために、許可のない外部サイトへ仕事のデータを貼り付ける必要はありません。

import json
from pathlib import Path

def unique_keys(pairs):
    result = {}
    for key, value in pairs:
        if key in result:
            raise ValueError(f"duplicate key: {key}")
        result[key] = value
    return result

def reject_constant(value):
    raise ValueError(f"invalid constant: {value}")

text = Path("fixture-products.json").read_text(encoding="utf-8")
data = json.loads(
    text,
    object_pairs_hook=unique_keys,
    parse_constant=reject_constant,
)
print("構文と重複キーの検査を通過")

parse_constantでは、Pythonのデコーダーが既定で受け入れることのあるNaNなどを、この例では拒否するようにしています。object_pairs_hookの詳細と標準デコーダーの注意点はPython公式のjsonモジュール資料が根拠です。ここで扱うのは小さな教材の検査であり、巨大な入力や信頼できないファイルを安全に処理するための設計全体ではありません。

成功する例だけでなく、止まるべき例も試す

検査用のコードは、正常なファイルが読めたことだけで評価しません。重複があるのに通ったら、検査の目的を果たしていないためです。今回の確認では、最上位の重複、入れ子の重複、idとUnicodeエスケープ表記のキーが同じ名前になる重複の三例を検出しました。単に文字列の見た目を検索する方法ではなく、キーを解釈した結果で比較することが重要です。

※表は横にスクロールできます。条件はこの教材の例です。

構文と重複が通ったら、商品数、画像情報の件数、必須項目、型、IDを照合します。今回の基準は商品IDが0007、0008、0009で、それぞれ文字列のままであることです。もしIDが二件とも0007になれば、件数が三件でも合格ではありません。必要なIDがそろっているか、余計なIDが混ざっていないかまで見ます。

準備完了の判定では、approvedが真偽値のtrueであり、各画像のaltが空白だけではない文字列であることを確認します。今回の固定データでは0007と0008が該当し、0009は確認待ちです。なお、画像が必須の業務ならimagesが空でない検査も必要です。今回の三商品にはそれぞれ画像情報がありますが、条件式の一部だけをコピーして一般的な検品器にしないでください。

自作の検査を育てるなら、仕様変更と一緒に不正例も追加します。商品IDの桁数を変えた、altの確認方法を変えた、といった変更をコードだけで済ませず、何が合格するかを説明資料とそろえます。JSON Schemaなどによる型・必須項目の検証を導入する場合も、重複キーをどこで止めるかは別に確かめます。この教材ではJSON Schemaによる検査は実装していません。

再読込と検収メモで、受け取る人が判断できる状態にする

往復テストと検収メモの模式図。0007・0008は教材上の確認済み、0009は確認待ちです。

往復テストでは値の一致を確認する

読み込んだデータをJSONとして再出力し、それをもう一度読み込むことを、この教材では往復テストと呼びます。最初と最後の値が等しいかを比較します。整形用の空白や改行、文字のエスケープ表記は変わることがあるので、ファイルの文字列が一字一句同じかという確認とは目的を分けます。

今回の固定データでは、Node.jsでJSON.parseとJSON.stringifyを使った往復を確認しました。商品IDの先頭ゼロ、タイトル内の引用符、説明文の改行、バックスラッシュ、null、falseが保持されています。また、Pythonでも読み込み、再出力、再読み込み後の値の一致を確認しています。いずれも、この教材に含まれる値と実行環境での結果です。

次のコードはroundtrip.mjsとしてJSONファイルと同じ場所に保存し、Node.jsが使える環境でnode roundtrip.mjsを実行します。検証環境はNode.js 24.19.0、Python 3.12.14で、2026年10月7日（日本時間）に確認しました。実行後は「商品3件・素材情報4行・値の往復一致を確認」と表示されます。

import assert from 'node:assert/strict';
import { readFileSync } from 'node:fs';

const text = readFileSync('fixture-products.json', 'utf8');
const data = JSON.parse(text);
const restored = JSON.parse(JSON.stringify(data));
assert.deepEqual(restored, data);
assert.deepEqual(data.products.map(p => p.product_id),
  ['0007', '0008', '0009']);
assert.equal(data.products.length, 3);
assert.equal(data.products.reduce((n, p) => n + p.images.length, 0), 4);
assert.equal(data.products[0].title, '机の上の"小物"');
assert.equal(data.products[0].description, '一行目\n二行目');
assert.equal(data.products.description, '保存先の例: C:\\drafts\\assets');
assert.equal(data.products.images[0].alt, null);
assert.equal(data.products.approved, false);
console.log('商品3件・素材情報4行・値の往復一致を確認');

assertは、期待した結果と違う場合に処理を止めるための確認です。手順をなぞっただけでなく、0007の説明文が二行の値になっていることや、0009のaltがnullのままであることを具体的に確かめます。コードを変更して別の商品データへ使う場合は、件数や期待値もその納品仕様に合わせて変えます。

検収メモに件数と保留理由を残す

引き渡すときは、JSONファイルだけを送るより、短い説明を添える方が確認を進めやすくなります。対象の仕様番号、商品数、素材情報の件数、実施した検査、保留項目をまとめます。受け取った相手が何を確認すればよいか、次に誰が判断するのかが分かる内容にします。

今回なら「商品3件、画像情報4行。構文、重複キー、文字列ID、引用符・改行、往復一致を確認。0007と0008は教材の準備完了条件を満たし、0009は未承認かつalt未確認のため保留」と書けます。検査で判明した状態をそのまま伝え、確認待ちの商品を黙って削除しないことが大切です。三件の依頼に二件だけ返すと、何が起きたのか分からなくなります。

ただし、納品先が未承認商品を含むファイルを受け付けない場合は、全件の作業台帳と取り込み用のファイルを分ける方法を相談します。この記事の全三件のJSONを、そのまま本番へ読み込ませることは勧めません。受け取るシステムがapprovedを見て公開を止めるかどうかは、この教材では確認していないためです。保留の情報を入れたことと、本番反映を防げることは別です。

ファイル本体の受け渡しまで含めて確認する

保存名は、相手が識別できるものにします。たとえば商品素材の対象範囲と版を含め、変更前後を区別できるようにします。最新、最終、最終修正版という名前だけが増えると、どれを使うべきか判断しづらくなります。作業中の原本、検査した版、実際に渡した版が一致していることを最後に確かめましょう。日付や版番号の付け方は、ファイル名のルールと受け渡し前の確認で具体例を確認できます。

文字コードは、この教材ではUTF-8を使い、BOMは付けません。日本語が文字化けしていないか、保存したファイルを読み直して確認します。受取仕様に文字コードやBOMの指定がある場合は、相手の読み取り環境との互換性を確認します。画面上で文字が見えていることだけでは、送付するファイルが想定どおりの形式で保存された証明にはなりません。

ハッシュ値は、検査したファイルと渡したファイルが同じかを照合する助けになります。ただし、ハッシュが一致しても、商品名の誤りや画像の権利まで正しいとは言えません。内容の検査と、同じファイルであることの検査を分けます。また、送付先や共有範囲は依頼時に合意した場所に限定し、公開のサンプルへ業務データを流用しないようにします。

副業の練習では、説明できる一式を作る

学習成果として残すなら、正しいJSONだけでなく、項目仕様と検査メモを一緒に用意します。架空データであることを明示し、どの不正例を止められたか、どこまでは確認していないかを説明できる形にしましょう。実績として見せる場合も、受託した仕事や顧客の事例であるかのように装わず、自主制作の教材として示します。

最初からあらゆる納品形式を扱う必要はありません。まずは商品三件の所属、ID、文字、空欄の意味を自分で説明し、修正後に同じ検査をやり直せるようにするところから始めます。規模を増やすときは、その案件の仕様、入力の品質、受け取る環境に応じて確認項目を増やしていきます。

JSONの書き方を仕事につなげる入口は、記号を暗記することだけではありません。相手が求める形を確認し、情報の意味を保って作り、検査した範囲と残る判断を伝えることです。今回の三商品を使い、0009を無理に合格させず、確認待ちとして説明できるところまで練習してみてください。