scrape

ジョブスクレイパー

---

仕組み

このスキルは、.agents/skills/ にあるインストール済みのポータル検索 CLI (フォールバックとして WebSearch も併用) を使い、プロフィールのクエリで求人ポータルを検索します。 過去に見た求人および応募トラッカーと重複を排除し、新しく一致した求人を簡単な適合度評価とともに提示します。

呼び出し

ユーザーは次のような発言でこのスキルを起動します:

• 「新しい求人を探して」
• 「求人をスクレイプして」
• 「新しい募集はある?」
• 「/scrape」

任意の引数:

• フォーカス領域。例: 「/scrape data science」または「/scrape geophysics」
• 「broad」ですべての検索カテゴリを実行。例: 「/scrape broad」
• 「health」でポータルのヘルスチェック (ステップ 4.75) のみを実行し、求人の検索・重複排除・提示は行いません - 例: 「/scrape health」、または「/scrape health jobnet」で無効化されていても 1 つのポータルを検査します

---

実行ステップ

ステップ 0: 状態の読み込み

1. job_scraper/seen_jobs.json を読み込みます (存在しない場合は作成します - {"seen": {}} で開始)
2. job_search_tracker.csv を読み込み、すでに応募済みの企業+職種を抽出します
3. search-queries.md (このディレクトリ) を読み込み、検索戦略を確認します

ステップ 1: 検索

search-queries.md (このディレクトリ) を読み込み、検索戦略を確認します。デフォルトでは、優先度の高い上位 3 つのクエリカテゴリを実行します。ユーザーが「broad」と指定した場合は、すべてのカテゴリを実行します。ユーザーがフォーカス領域 (例: 「data science」) を指定した場合は、そのカテゴリのクエリを優先します。

主要な検索手段として、インストール済みの CLI ツールを使用します。 CLI スキルを持たないポータル、またはシステム上で bun が利用できない場合にのみ、WebSearch にフォールバックします。

1a. bun の可用性を確認

bun --version

これが失敗した場合 (bun がインストールされていない場合)、すべてのポータルで 1c (WebSearch フォールバック) に進み、ステップ 5 の出力にフォールバックした旨を記録します。

1b. CLI ツールを実行 (主要 - 可能な場合はこれらを並列で実行)

.agents/skills/*/SKILL.md の下にあるすべての SKILL.md を読み込むことで、インストール済みのすべてのポータル CLI スキルを検出します。各ファイルには、そのポータルの正確な CLI フラグと使用例が記載されています。各ポータルが独自に文書化したインターフェースを使用してください - フラグを推測しないでください。 このアプローチにより、/add-portal で追加された新しいポータルも、このファイルを変更することなく自動的に含まれます。

enabled トグルを尊重します。 ポータルの SKILL.md の frontmatter で enabled: false が設定されていない限り、そのポータルは有効です (キーが存在しない場合は有効、つまりデフォルト)。無効なポータルはそれぞれスキップし、ステップ 5 のサマリー用に記録します。これにより、フォークではポータルをインストールしたまま、そのディレクトリを削除せずに実行を休止できます。

有効な各ポータルスキルについて:

1. その SKILL.md を読み込み、正しい bun run … の呼び出しとサポートされているフラグを確認します。
2. search-queries.md のクエリ用語を、そのポータルのフラグ形式 (例: --key、--search-string、--query、フィルターコード - ポータルの SKILL.md が指定するもの) に変換します。
3. ポータルがサポートする新しさのフィルターフラグ (--jobage、--since <YYYY-MM-DD> など - ポータルごとに文書化されているとおり) を使って、過去 14 日に範囲を限定します。新しさのフラグがないポータル (jobdanmark にはありません) も同様に範囲を限定します: どのポータルの検索出力にも date フィールドがあるため、クライアント側でフィルタリングします - 呼び出しが返った後、date が 14 日より古い結果を除外し、ポータルの SKILL.md が文書化していないフラグを決してでっち上げないでください (CLI は未知のフラグを拒否します)。--order PublicationDate は並べ替えであり、並べ替えはフィルターではありません - それ以上良い方法を提供しないポータル (jobnet) では、これを --limit と組み合わせるのは妥当な近似ですが、それでも同様にクライアント側の日付フィルターを適用します。
4. ポータルの上限フラグを使って、1 回の呼び出しあたり約 20 件の結果に制限します。
5. 機械可読な出力のために --format json を使用します。

可能な場合は Agent ツールを使って、すべてのポータル CLI 呼び出しを並列で実行します。すべての results 配列をステップ 2 用の単一のプールに収集し、各結果をそのソースポータルスキルでタグ付けしたままにします (ステップ 2 の detail 検索用)。

CLI ツールが非ゼロのコードで終了した場合は、エラーメッセージをログに記録して続行します - 検索全体を中止しないでください。

1c. WebSearch のフォールバック

以下の場合は WebSearch を使用します。

• search-queries.md に記載されているポータルのうち、.agents/skills/ の下に対応するディレクトリがないもの
• CLI の実行時に失敗するポータル
• bun が利用できない場合（Step 1a が失敗した場合）

これらのポータルについては、search-queries.md にあるサイト固有のクエリ文字列をそのまま WebSearch のクエリとして使用します。

フォールバックの各結果には、WebSearch から取得したことを示すタグを付けます。インストール済みポータルの CLI が失敗し、その代替としてフォールバックを使用した場合は、ポータルのタグも残します。Step 4 ではこれをエントリーの source として保存し、Step 5 では今回フォールバックを使用したポータルを報告します。

Step 2: 取得と解析

Step 1 で見つかった有望な結果ごとに、以下を行います。

CLI の結果の場合： 検索結果には、タイトル、会社、勤務地、日付、URL がすでに含まれています。詳しく確認する価値のある求人については、そのポータルの detail コマンド（SKILL.md を参照してください。フラグを推測しないでください）で詳細を取得し、主な応募要件、応募締切、説明の短い抜粋を抽出します。

掲載終了の検出： linkedin-search detail は isActive も返します。false は、掲載ページ自体に LinkedIn の「応募受付終了」バナーが表示されていることを意味します。求人はインデックス登録後、取得されるまでの間に掲載終了したことになります（期限切れの LinkedIn URL は、類似した募集中の求人にリダイレクトされるため、検索結果に幽霊のような求人が含まれることがあります）。このような求人を記録せずに除外してはいけません。Step 4 で job_scraper/seen_jobs.json に "status": "expired" としてエントリーを書き込み、Step 5 の表示からは除外します。エントリーがなければ、求人を一度も見つけていない場合と区別できません。記録されたステータスがあることで、後から幽霊求人の報告を自己診断できます。isActive: true はそのバナーがないことを示すだけで、求人が募集中である証拠ではありません。締切や無効な URL の確認は引き続き /rank の役割です。

WebSearch の結果の場合： 求人掲載 URL に対して WebFetch を使用し、同じ項目を手動で抽出します。HTTP 403 が返された場合は、諦める前に .claude/skills/job-application-assistant/09-web-research.md に従って、curl でブラウザー用ヘッダーを付けて再試行してください。銀行や企業のサイトの多くは、ブラウザーには通常どおりコンテンツを提供しながら、WebFetch のユーザーエージェントを拒否します。

実際に求人掲載ページへ移動できる URL を保存してください。 一覧ページの URL に #fragment を付けたもの（.../jobs/ciso/#ikerian）は求人掲載ページではありません。正常に取得できても、無関係な求人タイトルが返されるため、後続の /rank と /apply の実行が毎回そのエントリーで失敗します。WebSearch で一覧ページしか見つからない場合は、雇用主の採用サイトで職種を検索してその URL を保存するか、フラグメント付きリンクを保存せずに候補を除外します。

候補ごとに、以下を行います。

• URL が job_scraper/seen_jobs.json の既存エントリーのいずれかと一致する場合は、そのエントリーのキーにかかわらずスキップします。これにより、従来のヘルパーより前のキー規則で保存された求人との重複排除の継続性を保ち、新しいエントリーでは Step 4 の標準キーを使用できます。
• それ以外の場合、会社名とタイトルの組み合わせがすでに job_scraper/seen_jobs.json に存在する場合はスキップします。
• 会社名と職種の組み合わせが job_search_tracker.csv にすでに存在する場合はスキップします。

Step 2.5: 大量掲載の検出（今回の実行内）

ユーザーに注意喚起として知らせる価値のある求人配信パターンです。雇用主を非難するものではありません。求人の配信方法を示すだけで、会社が正当かどうかを判断するものではありません。このパターンだけでは、何か問題があることの証明にはなりません（企業が複数の都市で同じ職種を正当に募集することもあります）。ユーザーが時間をかけるかどうか判断する際に考慮できるようフラグを付けます。このパターンを理由に適合度を下げたり、結果をひそかに除外したりしないでください。

今回の実行で得られた候補のうち、同じ会社のもの、または URL やタイトルに表示された同じ req/job ID を共有するものが 2 件以上あり、説明が実質的に同一で、都市・勤務地・タイトルだけが異なる場合は、別々の行として表示しないでください。1 行にまとめ、たとえば「6 都市（BR、MX、GT）で同一内容を掲載」のように、その広がりを記載します。

ステップ 3：適合性の簡易評価

新しい求人ごとに、簡易的な適合性チェックを行います（04-job-evaluation.md に記載された完全な評価ではなく、簡単な目安です）。

• 適合度：高：職務内容があなたの中核的なスキルに直接関係している
• 適合度：中：職務内容があなたの経験に隣接している
• 適合度：低：不足しているスキルを大幅に補う必要がある

言語に関する例外ルール： 適合度を割り当てる前に、求人情報を 04-job-evaluation.md の言語ゲートと照合します（必須言語が CLAUDE.md の「Languages」テーブルにまったく記載されていない場合）。必須言語がまったく記載されていなければ、スキルの適合度にかかわらず例外的に低とし、ハイライトの箇条書きにもその言語を明記して、ほかの点では良好に見える適合度に埋もれないようにします。記載済みの言語について、求められるレベルが記載されたレベルより高い場合は、例外ルールの対象ではありません。適合度は通常どおり評価しますが、求人の要件を引用し、記載されたレベルと並べて、その求人のハイライト（ステップ 5）に注意点の箇条書きを追加して、差が見えるようにします。

ステップ 4：重複排除と保存

1. ヘルパーを使って各エントリのキーを生成します。その場でスラッグ化してはいけません。

python3 tools/job_key.py --company "<company>" --title "<title>" --url "<url>"

1 行で、その求人情報の正規キーが出力されます。キーは求人情報から決定論的に生成されなければなりません。スラッグ化の方法が実行ごとに異なると、同じ求人が重複して保存され、このステップの重複排除の目的が失われます。ヘルパーは長いタイトルを上限まで切り詰め、スラッグ全体のハッシュで上限時の衝突を回避します。そのため、切り詰められたタイトルは実行間で安定し、異なる長いタイトルが衝突することもありません。python3 tools/job_key.py --audit は、このルールより前に作成された既存の状態ファイル内のエントリを報告します。キーの書き換えはトラッカー内の企業名と職種名の照合を壊すため、報告のみを行い、キーは書き換えません。

2. 取得したすべての求人（新規とスキップしたものの両方）を、次の構造で job_scraper/seen_jobs.json に追加します。

{
  "seen": {
    "<key from tools/job_key.py>": {
      "title": "...",
      "company": "...",
      "url": "...",
      "first_seen": "YYYY-MM-DD",
      "posted_date": "YYYY-MM-DD" | null,
      "deadline": "YYYY-MM-DD" | null,
      "fit": "high/medium/low",
      "status": "new/skipped/ranked/expired/unreachable",
      "portal": "<source portal skill, e.g. jobindex-search>",
      "source": "cli/websearch"
    }
  }
}

portal フィールドには、求人を取得した CLI スキルを記録します（ステップ 1b では結果にポータルごとのタグがすでに付いているため、そのタグをここに保存します）。このフィールドが追加される前に書き込まれたエントリにはフィールドがありません。ヘルスチェック（ステップ 4.75）では、URL のドメインと各ポータルのベース URL を照合してエントリを特定するため、後から補完しないでください。

source フィールドには、エントリの取得元を記録します。ステップ 1b のポータル CLI の出力なら cli、ステップ 1c のフォールバックなら websearch です。これにより、実行時の要約がなくなった後でも、実在しない求人の報告を診断できます。保存済みのエントリの URL が後日何も表示しなくなった場合（または別の求人を表示するようになった場合）、そのエントリがライブ CLI の出力に基づくのか、数週間古い可能性のある検索インデックスに基づくのかで意味は大きく異なります。また、ここにエントリがないのに求人が提示されている場合は、捏造を示唆しますが、これはルール 1 で禁止されています。このフィールドが追加される前に書き込まれたエントリにはフィールドがありません。取得方法は記録されていないため、後から補完しないでください。

/rank は、このスキーマを項目の追加によって拡張します。ランク付けされたエントリには、rank_score（総合スコア、0～100）、rank_verdict（適合度の区分。例：「strong fit」）、rank_date（ランク付けした日付の ISO 形式）、拒否条件のフィールド location_verdict と language_gate（どちらも PASS/FAIL/FLAG）、PASS 以外の理由となった要件を引用した language_note、およびスコアリングエージェントの所見をそのままコピーした strengths/gaps（それぞれ 1～3 件の箇条書き）が含まれます。status フィールドには "ranked" が設定されます。エントリを書き換える際に、これらのフィールドを削除しないでください。strengths/gaps の追加前にランク付けされたエントリには、これらのフィールドがない場合があります。読み取り側はこれらのフィールドがなくても処理できるため、推測で補完しないでください。判定名の変更前にランク付けされたエントリでは、location に PASS/FAIL/FLAG の旧形式の値が入っている場合があります。location_verdict がない場合は、それを判定として読み取ってください。新しいエントリでは、location は常に場所であり、判定ではありません。 deadline は /rank 拡張ではなく基底フィールドです。ステップ2の詳細取得はすでに応募締切を抽出しているため、求人が最初に検出されたときに書き込まれ、スコアリングエージェントが異なる値を返した場合は /rank のステップ4によって更新されます。null は、その求人情報に締切が記載されていないことを意味します。キーが存在しない場合は、そのエントリがこのフィールドより前のものであることを意味します - どちらの場合も締切を推測しないでください。また、推測によるバックフィルも行わないでください。

posted_date は、求人情報自体の公開日であり、ステップ2の契約がすべてのポータル CLI の検索出力ですでに保証している date フィールドから取得されます。ステップ1bはその日付を使って実行対象を直近14日間に絞り込み、その後その日付を破棄するため、下流のどこも、昨日公開された求人と2年前に公開された求人を区別できません - first_seen はこのスクレイパーがそのエントリを最初に検出した日時であり、雇用主が投稿した日時ではありません。これを永続化することで、実行後にステップ1bのウィンドウを監査できるようになり、/rank に比較検討できる鮮度シグナルを提供できます。何も読まない文章に日付を書き記して再発見する必要もなくなります。このギャップは実際に発生しました。2024-05-13 付けの freehire-search の求人がスクレイピングされ、133件中1位で Strong Fit とランク付けされましたが、そのスコアリングノート自体が、この求人情報は「long stale」である可能性があると指摘しながらも、それに対処できるものは何もありませんでした。null は、そのポータルがその結果に対して日付を返さなかったことを意味します（求人情報が日付を省略した場合、CLI は date: null を出力します）。キーが存在しない場合は、そのエントリがこのフィールドより前のものであることを意味します - どちらの場合も投稿日を推測しないでください。また、推測によるバックフィルも行わないでください。

3. seen リスト（URL または 会社名+タイトルで照合）またはトラッカーにまだ含まれていない求人のみを提示します。

ステップ4.5: 紹介コンタクトリンクの生成（High および Medium Fit のみ）

今回の実行で fit が high または medium のすべての求人（low-fit の求人はスキップ）について、2つの LinkedIn 人物検索 URL を生成し、ユーザーが紹介や温かい紹介（warm intro）を依頼できるリクルーターやチームメンバーを見つけられるようにします。これは意図的にリンク生成ステップであり、自動検索ではありません。スクレイピングなし、サードパーティ API なし、実行時の依存関係や認証情報は一切不要です。

A. リクルーター / 人材採用（紹介パス）

https://www.linkedin.com/search/results/people/?keywords=<url-encoded "<Company Name> recruiter">&origin=GLOBAL_SEARCH_HEADER

B. 役割/チームのピア（情報提供を目的としたアウトリーチ / 温かい紹介パス）

https://www.linkedin.com/search/results/people/?keywords=<url-encoded "<Company Name> <role keyword>">&origin=GLOBAL_SEARCH_HEADER

<role keyword> には、求人タイトルから取った短いキーワードを使用します - たとえば「AI Program Manager」というタイトルの求人は "<Company Name> AI Program Manager" になります。

どちらのリンクも、ユーザー自身が開いて閲覧するためのものです - LinkedIn の人物検索結果ページをプログラムで取得したりスクレイピングしたりしないでください。連絡先を捏造したり、特定の人物が見つかったと主張したりしないでください。これらは検索リンクであり、結果ではありません。

ステップ 4.75：ポータルのヘルスチェック

スクレイパーベースのポータル CLI は、いつの間にか動作不良になります。ポータルのマークアップが変更されると、パーサーは通常、結果がゼロ件だったり、フィールドが null や文字化けした状態だったりして終了コード 0 で終了します。Step 1c のフォールバックはハードエラーの場合にしか実行されないため、動作しません。このステップでは、実行ですでに得られている情報から、その兆候を検知します。

追加リクエストなしで確認します。 Step 1b で実行された有効な各ポータルについて、以下を確認します。

• 劣化スキャン： 今回の実行で返された結果を調べます。判定基準：すべての結果で company が null または空、タイトルが空、デコードされていないエンティティ（&）や HTML 断片がタイトルに含まれている、URL がポータルを指していない。いずれかに該当する場合、パーサーは部分的にしか機能しておらず、/scrape が気付かれないまま不正なデータを収集しています。
• 実績履歴： この実行のすべてのクエリでポータルが結果を 0 件返した場合、job_scraper/seen_jobs.json にそのポータルの過去のエントリがあるか確認します（portal フィールドを使うか、このフィールドが追加される前のエントリについては URL ドメインを照合します）。以前の実行では求人を返していたのに、今回は何も返さないポータルは要注意です。同じクエリが以前は機能していたためです。

疑わしい場合の追加確認（回数制限あり）。 疑わしいポータルに対して、1 回だけセンチネルプローブを実行します。ポータルに記載された search を、独自の SKILL.md に記載された例のクエリ（スキル登録時に正常に動作したことが確認済みのクエリ）と、ポータルの上限フラグを 3 に設定して実行し、--format json を指定します。結果が何も返らない場合のみ、一般的な単語を 1 つ使ってもう 1 回だけ再試行します。その場合に限り、判定を故障とします。429 またはブロックページは、故障の証拠にはなりません。ポータルを**判定不能（レート制限）**として記録し、間隔を空けて、再試行しないでください。

判定。 正常なポータルについては何も表示しません。表も行も出力しません。それ以外は、Step 5 の概要にヘルス行として表示します。

プローブ専用モード（/scrape health）。 Step 1～4 とこのステップの追加確認をスキップします（スキャン対象となる新しい実行がないため）。代わりに、インストール済みのすべてのポータルを直接プローブします。デフォルトでは有効なポータルが対象で、無効なポータルは明示的に指定された場合（例：/scrape health jobnet）のみ対象になります。各ポータルに対して上記のセンチネルプローブを実行し、返された結果に劣化の判定基準を適用します。さらに、ユーザーが明示的に診断を求めているため、正常な各ポータルの最初の結果に対して detail を 1 回取得します（説明文がデコード済みの読みやすいテキストである必要があります。取得に失敗した場合は劣化に判定を下げます）。このモードでは正常なものも含め、すべてのステータスを報告します。実行量には上限があり、ポータルごとに検索 1 回、再試行は最大 1 回、詳細取得は最大 1 回です。

Step 5: 結果を提示する

新しい求人を適合度の高い順に並べた表で提示します。Step 1b でポータルをスキップした場合（enabled: false）、除外したことが黙って見過ごされないよう、以下の skipped (disabled): 行で報告します。スキップしたポータルがない場合は、この行を省略します。この実行でいずれかのポータルの結果が Step 1c のフォールバック（bun が利用できない、または CLI の実行時に失敗した場合）によるものなら、fallback (websearch): 行で報告します。フォールバックの結果は古くなっている可能性のある検索インデックスから取得されるため、どの行にその注意事項が当てはまるか、読者に知らせる必要があります。すべてのポータルで CLI が実行された場合は、この行を省略します。Step 4.75 でポータルの状態に劣化、障害、または判定不能が見つかった場合は、疑わしいポータルごとに health: 行を1行追加します（正常なポータルの行は不要です）。報告の後、そのポータルの enabled: false を設定して、修正されるまで /scrape の実行対象から外し、Step 1c のフォールバックで対応することを提案します。切り替えの編集はユーザーの確認を得てから行い、スキル内のほかの項目は絶対に編集しないでください。

## New Job Matches - YYYY-MM-DD

Found X new positions (Y high, Z medium, W low match).

skipped (disabled): <portal-name>, <portal-name>

fallback (websearch): <portal-name>, <portal-name>

health: <portal-name> - degraded (company null on all 12 results); parsing anchors in .agents/skills/<portal-name>/url-reference.md
health: <portal-name> - broken (0 results for the SKILL.md test query and a broader retry); parsing anchors in .agents/skills/<portal-name>/url-reference.md

| # | Fit | Title | Company | Location | Deadline | URL |
|---|-----|-------|---------|----------|----------|-----|
| 1 | High | ... | ... | ... | ... | [Link](...) |

If Step 2.5 flagged a mass-posting pattern, note it in the Title cell (e.g. "Frontend Developer (posted in 6 cities)") rather than burying it. Do the same for a declared-language-insufficient-level flag from the Language Gate (e.g. "Backend Engineer ⚠ fluent English required") - both are signals the user should see at a glance, not just in the detail highlights below.

### High-Match Highlights
For each high-match job, add 2-3 bullet points:
- Why it matches your profile
- Key requirements to check
- Any red flags (including mass-posting signals from Step 2.5)

### Contacts
For each high/medium-fit job from Step 4.5, add a short contacts block with the two
LinkedIn search links:
- Recruiters/TA search link, for the referral path
- Role/team-peer search link, for the warm-intro / informational-outreach path

提示した後、次のように尋ねます。

「これらの求人について、詳しく評価したいものはありますか？番号を指定してください。」

ユーザーが番号を選んだ場合は、job-application-assistant スキルのワークフローを実行します（まず適合度を評価し、承認された場合は CV とカバーレターを作成します）。

新しい求人が多数（およそ8件以上）見つかった場合は、/rank も提案します。/rank は、すべての新しい求人を適合度の評価基準全体に照らして一括採点し、順位付けした候補リストを返すため、長い表を目視で確認するより効率的です。(/rank は job_scraper/seen_jobs.json の ranked、expired、unreachable のステータス値を設定します。重複判定では、これらすべてを確認済みとして扱ってください。)

Step 6: トラッカーを更新する（任意）

ユーザーがいずれかの求人に応募することを決めた場合、トラッカーの行は job-application-assistant Step 3b によって記録されます。このステップには Step 5 からすでに移行するため、ここで行を重複して追加しないでください。ユーザーがこの手順を通さずに応募したと述べた場合に限り、/outcome Step 1 のヘッダーと照合してから更新するルールに従って行を追加します。

---

重要なルール

1. 求人情報を捏造しないでください。 実際の CLI 検索・詳細出力、または WebSearch/WebFetch の結果に含まれる求人のみを提示します。
2. 重複を確実に排除してください。 提示する前に、必ず job_scraper/seen_jobs.json と job_search_tracker.csv の両方を確認します。
3. 設定された地域を優先してください。 転居が必要な求人、または明らかに通勤可能範囲外の求人は除外します。
4. 募集中の求人のみを対象にします。 締め切りが過ぎた求人や、募集終了と記載された求人は除外します。
5. 詳細情報の取得は効率的に行ってください。 検索結果すべてに対して detail や WebFetch を実行しないでください。まずタイトルやスニペットで候補を絞り、可能性の高い求人だけを取得します。
6. 検索は並行して実行します。 ポータルの CLI 検索は並行して実行し、CLI でカバーできない範囲を補う場合にのみ WebSearch を使用します。
7. 人の情報を自動で検索しないでください。 紹介者の連絡先（Step 4.5）は LinkedIn の検索リンクに限ります。LinkedIn の人物検索結果ページをプログラムで取得またはスクレイピングしてはいけません。
8. ヘルスチェックは範囲を限定し、事実に忠実に行ってください。 Step 4.75 で実施できるのは、ポータルごとにプローブ1回、再試行1回、および（health モードで）詳細情報の取得1回までです。目的は診断であり、広範な巡回ではありません。レート制限は、障害の証拠にはなりません。ヘルス判定の根拠は、観測された CLI 出力のみです。テストできなかったポータルは、推測で判断せず「判定不能」と報告します。ヘルスチェックで編集できるのは enabled トグルのみであり、編集は確認を得てから行います。
9. 分布の傾向を指摘し、非難はしないでください。 多数の求人を一斉に掲載しているというシグナル（Step 2.5）は、求人情報の配信状況を示すものであり、雇用主が詐欺だと断定するものではありません。企業を詐欺的、または信用できないと名指ししてはいけません。観察結果を提示し、判断はユーザーに委ねます。