SWPF WEB DATA COLLECTOR

ITEM ANALYSIS（商品・収集データ解析）操作ガイダンス

作成日: 2026-08-12
対象: SWPF WEB DATA COLLECTOR / ITEM ANALYSIS
対象者: 非エンジニアの一般ユーザー、運用担当者
確認対象ソース: yahooauction202608120109keyword_context(1).zip

0. 想定対象者

本ガイダンスは、WEB DATA COLLECTORで収集したITEM（商品、記事、APIデータなど）から、必要な情報を自動的に取り出す ITEM ANALYSIS を設定・確認する一般ユーザーを対象としています。

プログラムを書く知識がなくても、目的に合うPluginを選び、掲載しているJSON例をコピーして必要な部分だけ変更できるように説明します。

分野	想定する知識
WEB DATA COLLECTOR	ログインして収集結果を確認できる
ITEM	収集された商品・記事など1件のデータであることを理解している
JSON	詳しい知識は不要。例をコピーして変更できれば利用可能
正規表現	`REGEX`を高度に利用する場合のみ必要
AI	`KEYWORD_CONTEXT`の結果を後段AIで評価する場合に利用

1. ITEM ANALYSISとは

ITEM ANALYSISは、WEB DATA COLLECTORが収集したITEMの内容から、必要な情報だけを取り出したり、条件に合うかを判定したりする機能です。

たとえば、ヤフーオークションの商品説明から次の情報を取り出せます。

シャッター回数
「ジャンク」という言葉があるか
「状態：良品」の「良品」部分
型番や日付など決まった形式の文字列
「広告」「受付終了」などの機械的な分類
「動作確認」「動作未確認」などを含む文章だけをAI判定用に抜き出す

flowchart LR A[WEB DATA COLLECTORで収集] --> B[ITEM] B --> C[ITEM ANALYSIS] C --> D[必要な値だけ抽出] C --> E[キーワード判定] C --> F[関連文章を抽出] D --> G[一覧表示・検索・AI等で利用] E --> G F --> H[AIへ必要部分だけ渡す]

ITEM ANALYSISは、元の商品ページを直接解析するのではなく、すでに収集済みのITEMデータを対象にします。

2. ITEM ANALYSISの全体構成

ITEM ANALYSISは、主に次の流れで動作します。

flowchart TD A[Collected ITEM] --> B[Analysis Definition] B --> C[解析対象の項目を選ぶ] C --> D[Pluginを選ぶ] D --> E[Plugin固有の条件で解析] E --> F{結果} F -->|見つかった| G[SUCCESS] F -->|見つからない| H[NOT_FOUND] F -->|設定・処理エラー| I[FAILED] G --> J[ITEM ANALYSIS結果に保存] H --> J I --> J

2.1 用語の関係

用語	一般ユーザー向けの意味
ITEM	収集した商品・記事・APIデータ1件
Analysis Definition	「何を、どう解析するか」をまとめた設定
Output	1つの解析結果。1つのDefinitionに複数設定可能
Plugin	実際の解析方法
KEY	解析結果の名前。例: `shot_count`
source_field	ITEM内のどの項目を解析するか
source_transform	解析前にHTMLタグを除くか

3. Analysis Definition画面とは

Analysis Definitionは、ITEM ANALYSISの設定単位です。

1つのAnalysis Definitionに、複数の解析結果（Output）をまとめて設定できます。

例として、1つの商品説明から次の2つを同時に取得できます。

商品説明 description_html
  ↓
Output 1: shot_count
  → シャッター回数を取得

Output 2: operation_context
  → 動作確認に関係する文章を取得

flowchart TD A[Analysis Definition] --> B[共通の解析対象 description_html] B --> C[Output 1 REGEX] B --> D[Output 2 KEYWORD_CONTEXT] C --> E[shot_count = 5700] D --> F[動作関連文章の配列]

4. Analysis Definition一覧画面

Analysis Definition一覧には、主に次の項目が表示されます。

表示項目	内容
Label	人が見て分かりやすい設定名
Definition code	Analysis Definition自体の識別コード
Outputs	このDefinitionが作る解析結果KEY
Site	対象SITE MASTER
Profile	対象SITE PROFILE
AUTO RUN	収集後の自動解析を行うか
Enabled	このDefinition自体が有効か
RUN NOW	対象ITEMを手動で解析する

4.1 Outputsの見方

たとえば一覧に次のように表示されている場合、

shot_count, operation_context

1つのAnalysis Definitionから2種類の解析結果が作られることを意味します。

4.2 RUN NOW

RUN NOW は、保存済みのAnalysis Definitionを使って、条件に一致する最新ITEMを解析キューへ投入します。

flowchart LR A[RUN NOW] --> B[確認画面] B --> C[対象ITEMを解析キューへ投入] C --> D[ANALYSIS EXECUTION] D --> E[ITEM ANALYSIS結果]

注意: RUN NOW は実際の解析結果を保存する処理です。後述の「この設定で1件解析する」とは用途が異なります。

5. Analysis Definition編集画面の各項目

5.1 Label

人が見て分かりやすい名前です。

例:

中古カメラ商品解析

5.2 Definition code

Analysis Definitionそのものを識別するコードです。

例:

camera_item_analysis

解析結果の名前ではありません。

解析結果の名前は、JSON内の outputs[].key で設定します。

5.3 Site

このAnalysis Definitionを適用するSITE MASTERを指定します。

- Any site - の場合はSiteを限定しません。

5.4 Profile

対象SITE PROFILEを指定します。

SiteとProfileを両方指定した場合、ProfileはそのSiteに所属している必要があります。

5.5 Run after collection enabled

ONにすると、Collection完了後の新規・変更ITEMがAnalysis Queueへ投入されます。

flowchart LR A[Collection完了] --> B{新規・変更ITEMか} B -- Yes --> C{AUTO RUNがONか} C -- Yes --> D[Analysis Queueへ] C -- No --> E[自動解析しない] B -- No --> E

5.6 Enabled

Analysis Definition全体の有効・無効です。

OFFの場合、そのDefinitionは通常の解析対象として利用できません。

5.7 Weight

一覧上の並び順などに使用される数値です。通常ユーザーは、特別な並び順が必要な場合だけ変更します。

5.8 Note

管理用コメントです。

解析処理には使用されません。

6. ANALYSISDEFINITIONJSONとは

ANALYSISDEFINITIONJSON に、実際の解析方法を設定します。

基本形は次のとおりです。

{
  "source_field": "description_html",
  "source_transform": "HTML_TO_TEXT",
  "outputs": [
    {
      "key": "shot_count",
      "plugin": "REGEX"
    }
  ]
}

一般ユーザーは、ゼロからJSONを作るよりも、本ガイダンスの目的別サンプルをコピーし、項目名やキーワードだけ変更する方法を推奨します。

7. 共通設定 `source_field`

source_field は、ITEM内のどの項目を解析するかを指定します。

例:

"source_field": "description_html"

これは、収集済みITEMの description_html を解析対象にするという意味です。

ほかにも、収集定義によって次のような項目を対象にできます。

title
description_html
detail_page_title
current_price

実際に使える名前は、そのSITEの収集結果に存在するフィールド名によって変わります。

8. 共通設定 `source_transform`

source_transform は、解析前に元データをどのように変換するかを指定します。

利用できる値は2種類です。

値	動作
`NONE`	元データをそのまま使う
`HTMLTOTEXT`	HTMLタグを削除し、HTML Entityを文字へ戻す

8.1 通常の文章解析

HTMLタグ自体が不要なら、一般的には次を使用します。

"source_transform": "HTML_TO_TEXT"

8.2 KEYWORD_CONTEXTでHTMLの段落を利用する場合

KEYWORD_CONTEXT で <div>, ,   などのHTMLブロックを「文章の区切り」として利用する場合は、必ず NONE を使用します。

"source_transform": "NONE"

理由は、HTMLTOTEXT を先に実行するとHTMLタグが削除され、どこが段落の境界だったか分からなくなるためです。

flowchart TD A[description_html] --> B{HTMLの境界を使うか} B -- No --> C[HTML_TO_TEXT] B -- Yes --> D[NONE] D --> E[KEYWORD_CONTEXT input_format=HTML]

9. 1つのDefinitionに複数Outputを設定する

トップレベルの sourcefield と sourcetransform は、各Outputへ共通設定として引き継がれます。

{
  "source_field": "description_html",
  "source_transform": "HTML_TO_TEXT",
  "outputs": [
    {
      "key": "shot_count",
      "plugin": "REGEX"
    },
    {
      "key": "has_junk_word",
      "plugin": "KEY_EXISTS"
    }
  ]
}

Output側に sourcefield または sourcetransform を書いた場合は、Output側が優先されます。

flowchart TD A[トップレベル設定] --> B[Output] C{Output側にも同じ設定がある?} C -- No --> D[トップレベルを利用] C -- Yes --> E[Output側を利用]

10. 現在利用できるITEM ANALYSIS Plugin

現行ソースコードで利用できるPluginは次の6種類です。

Plugin	一般ユーザー向けの用途
`KEY_EXISTS`	指定した言葉があるかを確認
`KEYNEXTINTEGER`	指定語の後ろにある整数を取得
`KEYNEXTTEXT`	指定語の後ろにある文字列を取得
`REGEX`	決まったパターンから値を高精度に取得
`REGEX_CLASSIFY`	文字列パターンで機械的に分類
`KEYWORD_CONTEXT`	キーワードを含む関連文章だけを抜き出す

flowchart TD A{何をしたい?} A -->|言葉の有無| B[KEY_EXISTS] A -->|後ろの整数| C[KEY_NEXT_INTEGER] A -->|後ろの文字| D[KEY_NEXT_TEXT] A -->|形式を厳密指定| E[REGEX] A -->|定型ルールで分類| F[REGEX_CLASSIFY] A -->|AI用に関連文章を抽出| G[KEYWORD_CONTEXT]

11. KEY_EXISTS ― キーワードがあるか確認する

11.1 こんな場合に使用

「ジャンク」が書かれているか
「故障」が書かれているか
「送料無料」があるか
「PR」「広告」があるか

11.2 設定例

{
  "source_field": "description_html",
  "source_transform": "HTML_TO_TEXT",
  "outputs": [
    {
      "key": "has_junk_word",
      "plugin": "KEY_EXISTS",
      "keys": [
        "ジャンク",
        "故障"
      ]
    }
  ]
}

11.3 結果

「ジャンク」が見つかった場合:

VALUE = true
MATCHED KEY = ジャンク
STATUS = SUCCESS

どの言葉も見つからない場合:

VALUE = false
STATUS = SUCCESS

「見つからない = エラー」ではありません。

12. KEYNEXTINTEGER ― キーワードの後ろの整数を取得する

12.1 こんな場合に使用

シャッター回数：5700回

から、

だけを取得したい場合です。

12.2 設定例

{
  "source_field": "description_html",
  "source_transform": "HTML_TO_TEXT",
  "outputs": [
    {
      "key": "shot_count",
      "plugin": "KEY_NEXT_INTEGER",
      "keys": [
        "ショット回数",
        "シャッター回数"
      ],
      "max_distance": 100
    }
  ]
}

12.3 max_distance

キーワードの後ろを何文字まで探すかです。

省略時は30文字です。

flowchart LR A[シャッター回数] --> B[後ろ最大100文字を確認] B --> C[最初の整数を取得]

12.4 注意

このPluginが数値として直接探す形式は、半角数字 0-9 と半角カンマです。

文章中に別の数字が近くにあると、意図しない数字を取得する可能性があります。条件を厳密にしたい場合は REGEX を使用します。

13. KEYNEXTTEXT ― キーワード直後の文字列を取得する

13.1 例

状態：良品

から、

良品

を取得します。

13.2 設定例

{
  "source_field": "description_html",
  "source_transform": "HTML_TO_TEXT",
  "outputs": [
    {
      "key": "condition_text",
      "plugin": "KEY_NEXT_TEXT",
      "keys": [
        "状態",
        "コンディション"
      ],
      "max_distance": 100
    }
  ]
}

13.3 自動的に除かれる先頭記号

キーワード直後の次のような区切りは取り除かれます。

空白 / 全角空白 / : / ： / = / ＝ / - / －

その後、最初の改行までを値として取得します。

14. REGEX ― 決まった形式から高精度に値を取得する

REGEX は、現在のPlugin群の中で最も柔軟な値抽出方法です。

14.1 シャッター回数の例

{
  "source_field": "description_html",
  "source_transform": "HTML_TO_TEXT",
  "outputs": [
    {
      "key": "shot_count",
      "plugin": "REGEX",
      "pattern": "(?:ショット回数|シャッター回数|シャッタ回数)[\\s\\S]{0,100}?(?<![0-9０-９])([0-9０-９][0-9０-９,，]*)(?![0-9０-９,，])",
      "group": 1,
      "flags": [
        "u"
      ],
      "normalizers": [
        "FULLWIDTH_TO_HALFWIDTH",
        "REMOVE_COMMA",
        "TO_INTEGER"
      ]
    }
  ]
}

14.2 一般ユーザーが変更する箇所

通常は、検証済みのPatternをそのまま使い、次の箇所だけ目的に合わせて変更することを推奨します。

key
source_field
必要に応じて検索対象の語
max相当の文字数部分

正規表現の書式を不用意に変更すると、取得漏れや誤取得につながります。

15. Normalizer ― 取得した値を整える

Normalizerは、取得した値を保存しやすい形へ変換します。

現行実装で利用できる名称は次のとおりです。

Normalizer	動作
`TRIM`	前後の空白を削除
`REMOVE_COMMA`	`,` と `，` を削除
`FULLWIDTHTOHALFWIDTH`	全角数字を半角数字に変換
`TO_INTEGER`	整数に変換
`TO_DECIMAL`	小数に変換
`TO_UPPER`	英字を大文字化

15.1 重要: `REMOVE_COMMA` が正式名称

使用する名称は、

REMOVE_COMMA

です。

REMOVE_COMMAS

ではありません。

15.2 数値の整形例

元の文字: ５,７００
  ↓ FULLWIDTH_TO_HALFWIDTH
5,700
  ↓ REMOVE_COMMA
5700
  ↓ TO_INTEGER
整数 5700

16. REGEX_CLASSIFY ― 定型文字列で分類する

REGEX_CLASSIFY は、複数のRuleを上から順番に確認し、最初に一致した分類値を返します。

16.1 例

{
  "source_field": "description_html",
  "source_transform": "HTML_TO_TEXT",
  "outputs": [
    {
      "key": "content_type",
      "plugin": "REGEX_CLASSIFY",
      "rules": [
        {
          "pattern": "(?:PR|広告|Sponsored)",
          "value": "ADVERTISEMENT"
        },
        {
          "pattern": "速報",
          "value": "BREAKING"
        }
      ],
      "default": "NORMAL",
      "flags": [
        "u"
      ]
    }
  ]
}

flowchart TD A[対象文章] --> B{PR/広告/Sponsored?} B -- Yes --> C[ADVERTISEMENT] B -- No --> D{速報?} D -- Yes --> E[BREAKING] D -- No --> F[NORMAL]

16.2 優先順位

別の priority 項目はありません。

JSONに書いたRuleの上から順が、そのまま優先順位です。

16.3 適していない例

動作未確認品は返品対象外です

のように、同じキーワードでも文章全体の意味によって商品の状態が変わる用途には不向きです。

その場合は KEYWORD_CONTEXT で関連文章を抽出し、AIへ渡す方法を推奨します。

17. KEYWORD_CONTEXT ― AI判定用の関連文章だけを抜き出す

KEYWORD_CONTEXT は、今回追加されたPluginです。

指定キーワードを含む最小の文章・行・HTMLブロックだけを抽出します。

このPlugin自体は、商品の状態を「正常」「未確認」などに決定しません。

flowchart LR A[長い商品説明] --> B[KEYWORD_CONTEXT] B --> C[動作確認を含む文章] B --> D[ジャンクを含む文章] B --> E[返品対象外を含む文章] C --> F[AI] D --> F E --> F F --> G[意味を判断]

18. KEYWORD_CONTEXTを使う理由

商品説明全体をAIへ送ると、関係のない説明も大量に含まれます。

KEYWORD_CONTEXT を使うと、必要なEvidence（判断材料）だけを先に取り出せます。

18.1 入力例

外観はきれいです。
当店では写真機器専門家による丁寧な検品、動作確認を行っております。
付属品は写真をご覧ください。
※ジャンク品・動作未確認品・付属品の不良は返品対象外です。
発送は2営業日以内です。

18.2 抽出対象キーワード

動作確認
動作未確認
ジャンク
返品対象外

18.3 抽出結果

当店では写真機器専門家による丁寧な検品、動作確認を行っております。

※ジャンク品・動作未確認品・付属品の不良は返品対象外です。

関係のない「外観」「付属品」「発送」の文章は出力しません。

19. KEYWORD_CONTEXTの推奨設定

中古カメラの商品説明を対象にする例です。

{
  "source_field": "description_html",
  "source_transform": "NONE",
  "outputs": [
    {
      "key": "operation_context",
      "plugin": "KEYWORD_CONTEXT",
      "input_format": "HTML",
      "keywords": [
        "動作確認済",
        "動作確認済み",
        "動作確認OK",
        "動作確認",
        "動作未確認",
        "未チェック",
        "ジャンク",
        "通電確認",
        "AF確認",
        "オートフォーカス確認",
        "各部正常",
        "正常動作",
        "返品対象外"
      ],
      "delimiters": [
        "HTML_BLOCK",
        "NEWLINE",
        "。"
      ],
      "unique": true,
      "case_sensitive": true,
      "max_results": 50
    }
  ]
}

20. KEYWORD_CONTEXTの設定項目

項目	必須	省略時	内容
`source_field`	Yes	-	解析するITEM項目
`source_transform`	Yes相当	`NONE`	HTML境界を使う場合は `NONE`
`keywords`	Yes	-	探す言葉の一覧
`input_format`	No	`TEXT`	`TEXT` または `HTML`
`delimiters`	No	`NEWLINE`, `。`	文章を区切る方法
`unique`	No	`true`	同じ文章の重複を1件にまとめる
`case_sensitive`	No	`true`	英字の大文字小文字を区別する
`max_results`	No	`50`	最大出力件数。1～500
`trim`	No	`true`	各文章の前後空白を削除する
`include_keywords`	No	`true`	結果にヒットしたキーワード一覧を付ける

21. KEYWORD_CONTEXTの区切り方

利用できる区切りは3種類です。

21.1 `NEWLINE`

改行ごとに文章を分けます。

外観良好
動作確認済
付属品あり

キーワードが 動作確認 なら、

動作確認済

だけが対象です。

21.2 `。`

日本語の句点で文を分けます。

外観は綺麗です。動作確認済です。付属品は写真の通りです。

結果:

動作確認済です。

。 は結果に残ります。

21.3 `HTML_BLOCK`

HTMLの表示上の段落・行・表セルなどを区切りとして扱います。

例:

<div>外観良好</div>
<div>動作確認済です</div>
<div>付属品あり</div>

結果:

動作確認済です

22. HTML_BLOCKで区切りになるタグ

現行実装では、次のタグが境界として扱われます。

br
p
div
li
ul
ol
tr
td
th
section
article
header
footer
h1 ～ h6
blockquote
pre
hr

一方、strong, span, a などの装飾用のインラインタグは境界にはしません。

そのため、

<strong>動作</strong>確認済です

は、

動作確認済です

として連続した文章になり、動作確認 を検出できます。

23. HTML入力時に除外される内容

KEYWORDCONTEXT の inputformat = HTML では、次の非表示領域は先に取り除かれます。

script
style
noscript

たとえば、

<script>var x='動作確認済';</script>
<div>商品説明</div>

の場合、JavaScript中の「動作確認済」は商品説明本文としてヒットしません。

24. 同じ文章に複数のキーワードがある場合

入力:

※ジャンク品・動作未確認品・付属品の不良は返品対象外です。

キーワード:

ジャンク
動作未確認
返品対象外

3件に分けるのではなく、文章1件として返します。

{
  "keywords": [
    "動作未確認",
    "ジャンク",
    "返品対象外"
  ],
  "text": "※ジャンク品・動作未確認品・付属品の不良は返品対象外です。"
}

keywords の並び順は、実際にはAnalysis Definitionの keywords[] に定義した順を保ちます。

25. 重複文章の扱い `unique`

`true`

同じ文章がページ内に複数回存在しても、1件にまとめます。

"unique": true

`false`

同じ文章が2回あれば、2件とも残します。

"unique": false

一般的な商品説明のAI前処理では true を推奨します。

26. `case_sensitive`

英字の大文字・小文字を区別するかです。

true

AF CHECKED

と

af checked

を別の文字として扱います。

false

大文字・小文字を区別せず検索します。

日本語中心のサイトでは通常 true のままで問題ありません。

27. `max_results`

抽出結果が異常に増えないよう、最大件数を設定します。

"max_results": 50

現行実装で指定できる範囲は、

1 ～ 500

です。

上限を超える結果があった場合は、先頭から指定件数だけを返し、結果情報の truncated が true になります。

28. `include_keywords`

通常は true です。

"include_keywords": true

結果:

{
  "keywords": ["動作確認"],
  "text": "動作確認済です。"
}

false にすると、ヒットしたキーワード一覧を付けず、文章だけ返します。

{
  "text": "動作確認済です。"
}

AIに「どの語で抽出されたか」も渡したい場合は true を推奨します。

29. KEYWORD_CONTEXTは意味を判定しない

ここは重要です。

次の文章があった場合、

※ジャンク品・動作未確認品・付属品の不良は返品対象外です。

KEYWORD_CONTEXT は、

ジャンク商品である

あるいは

動作未確認商品である

とは判定しません。

あくまで、

この文章が判断材料として関連している

というところまでを担当します。

flowchart TD A[KEYWORD_CONTEXT] --> B[関連文を抽出] B --> C[AIまたは後段処理] C --> D{文章の意味を判断} D --> E[CONFIRMED] D --> F[NOT_CONFIRMED] D --> G[UNKNOWN]

この役割分担により、複雑な例外ルールを大量の正規表現へ詰め込む必要がなくなります。

30. Pluginの使い分け

やりたいこと	推奨Plugin
「ジャンク」があるかだけ知りたい	`KEY_EXISTS`
「シャッター回数」の後ろの整数を取りたい	`KEYNEXTINTEGER`
「状態：」の後ろの文字を取りたい	`KEYNEXTTEXT`
型番・数値などを厳密に取りたい	`REGEX`
「PRなら広告」など定型分類したい	`REGEX_CLASSIFY`
動作状態の判断に必要な文章だけ集めたい	`KEYWORD_CONTEXT`
文章の意味・意図を最終判断したい	AI

31. 「この設定で1件解析する」テスト

Analysis Definition編集画面には、

この設定で1件解析する

ボタンがあります。

これは、現在フォームに入力している設定を使い、対象範囲の最新ITEM 1件だけで解析結果を確認するテスト機能です。

31.1 保存前でも確認できる

現在フォームに入力中のJSONを使用してテストします。

31.2 解析結果は保存されない

このテストは、通常の collectoritemanalysis 解析履歴を作成しません。

つまり、

設定確認用のプレビュー

です。

flowchart TD A[JSONを編集] --> B[この設定で1件解析する] B --> C[最新ITEM 1件を選択] C --> D[通常解析と同じPlugin処理] D --> E[モーダルに結果表示] E --> F[DBの解析履歴には保存しない]

32. 1件解析テスト結果モーダルの見方

テストすると「1件解析テスト結果」モーダルが開きます。

32.1 対象ITEM情報

表示される主な項目:

項目	内容
ITEM ID	テスト対象ITEMのID
External ID	収集元サイト上の識別値
Title	ITEMの表示名
Definition code	現在のDefinition code
Site ID	対象Site
Profile ID	対象Profile
Observed at	ITEMの観測日時

32.2 解析結果一覧

列	意味
KEY	`outputs[].key`
PLUGIN	使用したPlugin
STATUS	SUCCESS / NOT_FOUND / FAILED
VALUE	最終結果
RAW VALUE	加工前の取得値
MATCHED KEY	ヒットしたキー（対応Pluginのみ）
ERROR	エラー内容

32.3 解析対象テキスト

Source field と Source transform、および変換後の解析対象を確認できます。

「思った文章が解析されていない」場合は、まずここを確認します。

32.4 JSON結果

モーダル下部には、ITEM情報、解析結果、設定内容を含むJSON全体が表示されます。

通常ユーザーは表形式だけでも確認できますが、詳細調査やAI連携時にはJSONが役立ちます。

33. STATUSの意味

ITEM ANALYSISでは主に3つの状態があります。

STATUS	意味	エラーか
`SUCCESS`	正常に結果を返した	No
`NOT_FOUND`	正常に解析したが対象が見つからなかった	No
`FAILED`	設定・Plugin実行でエラーが発生	Yes

flowchart TD A[Plugin実行] --> B{正常に処理できた?} B -- No --> C[FAILED] B -- Yes --> D{対象が見つかった?} D -- Yes --> E[SUCCESS] D -- No --> F[NOT_FOUND]

33.1 KEY_EXISTSだけは非ヒットでもSUCCESS

KEY_EXISTS は「存在するかどうか」自体が結果なので、見つからない場合も、

VALUE = false
STATUS = SUCCESS

です。

33.2 KEYWORD_CONTEXTの非ヒット

キーワードに一致する文章が1つもない場合は、

STATUS = NOT_FOUND

です。

34. KEYWORD_CONTEXTの結果の読み方

結果例:

[
  {
    "keywords": [
      "動作確認"
    ],
    "text": "当店では写真機器専門家による丁寧な検品、動作確認を行っております。"
  },
  {
    "keywords": [
      "動作未確認",
      "ジャンク",
      "返品対象外"
    ],
    "text": "※ジャンク品・動作未確認品・付属品の不良は返品対象外です。"
  }
]

34.1 VALUE_TYPE

KEYWORD_CONTEXT の結果は複数件を含められるため、

ARRAY

として扱われます。

34.2 metadata

主に次の情報があります。

項目	内容
`input_format`	TEXT / HTML
`segment_count`	分割後の文章数
`match_count`	実際に返した結果件数
`truncated`	max_resultsで切り捨てたか

35. 保存して実際に解析する

設定確認が終わったら、Analysis Definitionを保存します。

その後、主に2通りで解析します。

35.1 自動解析

Run after collection enabled = ON の場合、Collection完了後の新規・変更ITEMがAnalysis Queueへ投入されます。

35.2 手動解析

Analysis Definition一覧の RUN NOW を使用します。

flowchart TD A[Analysis Definition保存] --> B{実行方法} B -->|自動| C[Collection完了] C --> D[新規・変更ITEMをQueue] B -->|手動| E[RUN NOW] E --> F[条件に一致する最新ITEMをQueue] D --> G[Analysis Execution] F --> G G --> H[ITEM ANALYSIS結果保存]

36. ANALYSIS EXECUTION画面

手動実行や自動実行は、ANALYSIS EXECUTION単位で進捗を確認できます。

主な列は次のとおりです。

列	内容
ID	Analysis Execution ID
Profile	対象Profile
Definition	実行したAnalysis Definition
Trigger	MANUALなどの実行理由
Status	実行状態
Targets	対象ITEM数
New/updated targets	新規・変更ITEM数（MANUAL時は `-`）
Processes	Queueへ投入した処理数
Completed	完了した処理数
Success	成功数
Failed	失敗数
Results	保存された解析結果件数へのリンク
Started	開始時刻
Completed at	完了時刻

Results が1以上の場合、件数リンクから、そのExecutionの解析結果を確認できます。

37. ITEM ANALYSIS結果一覧

ITEM ANALYSIS一覧では、ITEMごとに解析結果KEYが仮想列として表示されます。

例:

ITEM                        shot_count    operation_context
OLYMPUS E-M1 ...            5700          [{...},{...}]

同じITEM・同じKEYに複数履歴がある場合は、基本的に最新結果が一覧表示されます。

37.1 NOT_FOUNDの表示

一覧の仮想列では、NOT_FOUND は - として表示されます。

37.2 FAILEDの表示

FAILED は FAILED と表示されます。

37.3 配列結果

KEYWORD_CONTEXT のような配列結果は、JSON文字列形式で表示されます。

38. ITEMごとの解析結果画面

1つのITEMについて、

最新の解析値
過去の解析履歴

を確認できます。

Latest analysis values

各KEYの最新値を横並びで確認します。

Analysis history

過去の解析結果を時系列で確認します。

履歴には主に次が表示されます。

KEY / RESULT / PLUGIN / STATUS / ANALYZED / DETAIL

Detail を開くと、その解析結果の詳細JSONを確認できます。

39. Analysis result detailの見方

詳細画面では主に次を確認できます。

ITEM ID
Analysis Definition ID
Analysis KEY
Plugin ID
Status
作成日時
Error message
SOURCESNAPSHOTJSON
ANALYSISDEFINITIONJSON
ANALYSISRESULTJSON

39.1 SOURCESNAPSHOTJSON

解析時にどのsource_fieldを使用し、どのような値を解析対象にしたかを確認するための情報です。

39.2 ANALYSISDEFINITIONJSON

その解析結果を作った時点の設定です。

後でDefinitionを変更しても、「当時どの設定で解析したか」を確認できます。

39.3 ANALYSISRESULTJSON

Pluginが返した詳細結果です。

障害調査、誤抽出調査、AI連携の確認で重要です。

40. 中古カメラ解析の推奨構成

中古カメラでは、数値と文章を同じ方法で処理せず、用途に応じてPluginを分けるのが分かりやすくなります。

flowchart TD A[商品説明] --> B[REGEX] A --> C[KEYWORD_CONTEXT] B --> D[シャッター回数 確定値] C --> E[動作状態に関係する文章] E --> F[AI] F --> G[動作確認済 / 未確認 / 不明など]

40.1 推奨JSON例

{
  "source_field": "description_html",
  "source_transform": "NONE",
  "outputs": [
    {
      "key": "shot_count",
      "plugin": "REGEX",
      "source_transform": "HTML_TO_TEXT",
      "pattern": "(?:ショット回数|シャッター回数|シャッタ回数)[\\s\\S]{0,100}?(?<![0-9０-９])([0-9０-９][0-9０-９,，]*)(?![0-9０-９,，])",
      "group": 1,
      "flags": [
        "u"
      ],
      "normalizers": [
        "FULLWIDTH_TO_HALFWIDTH",
        "REMOVE_COMMA",
        "TO_INTEGER"
      ]
    },
    {
      "key": "operation_context",
      "plugin": "KEYWORD_CONTEXT",
      "input_format": "HTML",
      "keywords": [
        "動作確認済",
        "動作確認済み",
        "動作確認OK",
        "動作確認",
        "動作未確認",
        "未チェック",
        "ジャンク",
        "通電確認",
        "AF確認",
        "オートフォーカス確認",
        "各部正常",
        "正常動作",
        "返品対象外"
      ],
      "delimiters": [
        "HTML_BLOCK",
        "NEWLINE",
        "。"
      ],
      "unique": true,
      "case_sensitive": true,
      "max_results": 50
    }
  ]
}

この例では、トップレベルは NONE にしてHTMLを保持し、shotcount Outputだけ HTMLTO_TEXT で上書きしています。

41. 設定前に確認する推奨手順

flowchart TD A[Collected ITEMを開く] --> B[取りたい元データの項目名を確認] B --> C[目的に合うPluginを選ぶ] C --> D[サンプルJSONをコピー] D --> E[source_field / key / keywords等を変更] E --> F[この設定で1件解析する] F --> G{期待した結果か} G -- No --> H[解析対象テキスト・STATUSを確認] H --> E G -- Yes --> I[保存] I --> J[RUN NOWまたは自動実行] J --> K[ITEM ANALYSIS結果を確認]

42. 一般ユーザー向けチェックポイント

確認項目	確認内容
source_field	実際にITEMに存在する項目名か
source_transform	HTML境界が必要か
Output key	他のOutputと重複していないか
plugin	目的に合ったPluginか
keywords / keys	誤字や不要語がないか
max_distance	近くの別数値・文章を誤取得しないか
REGEX pattern	検証済みのものか
KEYWORD_CONTEXT delimiters	HTML/改行/句点のどれで分けるか
1件解析テスト	保存前に期待結果が出るか
AUTO RUN	収集後に自動実行したいか
Enabled	Definitionが有効になっているか

43. よくある設定ミス

43.1 KEYWORDCONTEXTなのに `HTMLTO_TEXT`

誤り例:

"source_transform": "HTML_TO_TEXT",
"input_format": "HTML"

HTMLタグが先に削除されるため、HTML_BLOCK の境界を利用できなくなります。

推奨:

"source_transform": "NONE",
"input_format": "HTML"

43.2 Normalizer名が `REMOVE_COMMAS`

誤り:

"REMOVE_COMMAS"

正しい名称:

"REMOVE_COMMA"

43.3 Output keyが重複している

同じDefinition内で、

"key": "shot_count"

を2回定義することはできません。

43.4 Plugin名の誤字

Plugin IDは正確に指定します。

KEY_EXISTS
KEY_NEXT_INTEGER
KEY_NEXT_TEXT
REGEX
REGEX_CLASSIFY
KEYWORD_CONTEXT

43.5 SiteとProfileの組み合わせが違う

選択したProfileが、選択したSiteに所属していない場合は保存できません。

44. 表示・結果がおかしい場合

症状	最初に確認する場所
「この設定で1件解析する」で対象がない	Site/Profile範囲に最新ITEMがあるか
VALUEが空	STATUSを確認
STATUSがNOT_FOUND	source_field、キーワード、Patternを確認
STATUSがFAILED	ERRORまたは技術情報を確認
KEYWORD_CONTEXTが長文1件になる	delimitersを確認
HTMLの段落で分かれない	`sourcetransform=NONE`, `input``format=HTML`, `HTML_BLOCK` を確認
同じ文章が何度も出る	`unique=true` を確認
英語キーワードが大小文字でヒットしない	`case_sensitive=false` を検討
数値にカンマが残る	`REMOVE_COMMA` を確認
全角数字が整数にならない	`FULLWIDTHTOHALFWIDTH` → `TO_INTEGER` を確認

45. 現行実装と設計資料の差異・補足

本ガイダンスは、仕様書だけでなく、添付された2026-08-12版ソースコードを確認して作成しています。

一般ユーザーが誤解しやすい差異・補足は次のとおりです。

45.1 ITEM ANALYSIS Pluginは現在6種類

仕様書前半には「現行5種類」と記載がありますが、添付された今回のソースには KEYWORD_CONTEXT がすでに実装されているため、現在利用可能なPluginは6種類です。

45.2 KEYWORD_CONTEXTのHTML解析はDOM/DomCrawler方式ではない

設計資料では、将来的な推奨としてDOM / Symfony DomCrawler利用案が記載されています。

しかし現行ソースは、

script/style/noscript除去
→ 対象ブロックタグを内部区切りへ置換
→ strip_tags
→ html_entity_decode

という方式で実装されています。

一般ユーザーの設定方法には影響しませんが、「現行実装」と「設計上の推奨」を区別する必要があります。

45.3 ARRAY型はすでに実装済み

設計資料では valueType() へのARRAY追加を「推奨変更」としていますが、添付ソースではすでに、

is_array($value) → ARRAY

が実装されています。

そのため KEYWORD_CONTEXT の配列結果は正式に ARRAY として返されます。

45.4 `REMOVE_COMMA` が正式名称

現行ソースで認識するNormalizerは REMOVE_COMMA です。

45.5 1件解析テストはDBへ解析履歴を保存しない

現在の「この設定で1件解析する」は、通常解析と同じOutput実行処理を再利用しますが、collectoritemanalysis への保存は行いません。

設定確認用として安全に利用できます。

46. 操作のまとめ

flowchart TD A[Analysis Definition一覧] --> B[追加または編集] B --> C[Label / Site / Profileを設定] C --> D[ANALYSIS_DEFINITION_JSONを設定] D --> E[目的に合うPluginを選択] E --> F[この設定で1件解析する] F --> G{結果OK?} G -- No --> H[source / STATUS / VALUEを確認] H --> D G -- Yes --> I[保存] I --> J{実行方法} J -->|自動| K[Run after collection enabled] J -->|手動| L[RUN NOW] K --> M[ANALYSIS EXECUTION] L --> M M --> N[ITEM ANALYSIS結果] N --> O[必要に応じてDetail確認]

ITEM ANALYSISでは、まず「何を知りたいか」を決め、その目的に合うPluginを選ぶことが最も重要です。

特に中古商品のように、数値は機械的に取得できても、文章の意味は文脈によって変わる場合は、

REGEX等で確定値を取得
＋
KEYWORD_CONTEXTで判断材料を抽出
＋
AIで意味を判定

という役割分担が分かりやすく、保守しやすい構成です。

47. 目的別クイックリファレンス

「ジャンク」と書いてあるかだけ知りたい

KEY_EXISTS

シャッター回数を取りたい

高精度: REGEX
簡易: KEY_NEXT_INTEGER

「状態：良品」の良品を取りたい

KEY_NEXT_TEXT

「広告」「速報」を分類したい

REGEX_CLASSIFY

「動作確認」「ジャンク」等の周辺文章だけAIへ渡したい

KEYWORD_CONTEXT

文脈から商品の実際の動作状態を判断したい

KEYWORD_CONTEXT → AI

WEB_DATA_COLLECTOR_ITEM_ANALYSIS_入力ガイダンス

SWPF WEB DATA COLLECTOR

ITEM ANALYSIS（商品・収集データ解析）操作ガイダンス

0. 想定対象者

1. ITEM ANALYSISとは

2. ITEM ANALYSISの全体構成

2.1 用語の関係

3. Analysis Definition画面とは

4. Analysis Definition一覧画面

4.1 Outputsの見方

4.2 RUN NOW

5. Analysis Definition編集画面の各項目

5.1 Label

5.2 Definition code

5.3 Site

5.4 Profile

5.5 Run after collection enabled

5.6 Enabled

5.7 Weight

5.8 Note

6. ANALYSISDEFINITIONJSONとは

7. 共通設定 source_field

8. 共通設定 source_transform

8.1 通常の文章解析

8.2 KEYWORD_CONTEXTでHTMLの段落を利用する場合

9. 1つのDefinitionに複数Outputを設定する

10. 現在利用できるITEM ANALYSIS Plugin

11. KEY_EXISTS ― キーワードがあるか確認する

11.1 こんな場合に使用

11.2 設定例

11.3 結果

12. KEYNEXTINTEGER ― キーワードの後ろの整数を取得する

12.1 こんな場合に使用

12.2 設定例

12.3 max_distance

12.4 注意

13. KEYNEXTTEXT ― キーワード直後の文字列を取得する

13.1 例

13.2 設定例

13.3 自動的に除かれる先頭記号

14. REGEX ― 決まった形式から高精度に値を取得する

14.1 シャッター回数の例

14.2 一般ユーザーが変更する箇所

15. Normalizer ― 取得した値を整える

15.1 重要: REMOVE_COMMA が正式名称

15.2 数値の整形例

16. REGEX_CLASSIFY ― 定型文字列で分類する

16.1 例

16.2 優先順位

16.3 適していない例

17. KEYWORD_CONTEXT ― AI判定用の関連文章だけを抜き出す

18. KEYWORD_CONTEXTを使う理由

18.1 入力例

18.2 抽出対象キーワード

18.3 抽出結果

19. KEYWORD_CONTEXTの推奨設定

20. KEYWORD_CONTEXTの設定項目

21. KEYWORD_CONTEXTの区切り方

21.1 NEWLINE

21.2 。

21.3 HTML_BLOCK

22. HTML_BLOCKで区切りになるタグ

23. HTML入力時に除外される内容

24. 同じ文章に複数のキーワードがある場合

25. 重複文章の扱い unique

true

false

26. case_sensitive

true

false

27. max_results

28. include_keywords

29. KEYWORD_CONTEXTは意味を判定しない

30. Pluginの使い分け

31. 「この設定で1件解析する」テスト

31.1 保存前でも確認できる

31.2 解析結果は保存されない

32. 1件解析テスト結果モーダルの見方

32.1 対象ITEM情報

32.2 解析結果一覧

7. 共通設定 `source_field`

8. 共通設定 `source_transform`

15.1 重要: `REMOVE_COMMA` が正式名称

21.1 `NEWLINE`

21.2 `。`

21.3 `HTML_BLOCK`

25. 重複文章の扱い `unique`

`true`

`false`

26. `case_sensitive`

27. `max_results`

28. `include_keywords`

43.1 KEYWORDCONTEXTなのに `HTMLTO_TEXT`

43.2 Normalizer名が `REMOVE_COMMAS`

45.4 `REMOVE_COMMA` が正式名称