仕様書No.2｜9サイト巡回・候補抽出・一次情報確認 標準運用仕様書

このページをニュース候補収集の正本とする。 本仕様書No.2で9サイトから候補を抽出し、公式一次情報を確認できた案件だけを、仕様書No.1｜記事作成・Notion登録へ引き渡す。仕様書No.2だけで記事登録を完了したものとしてはならない。

文書管理

• 文書名：仕様書No.2｜9サイト巡回・候補抽出・一次情報確認 標準運用仕様書
• 版：1.7
• 制定日：2026年7月17日
• 前工程：本仕様書No.2
• 後工程：仕様書No.1｜電力シェアリングNews 記事作成・Notion登録 標準運用仕様書
• 巡回先の正本：最新版Excel「検索URL」シート
• 資料の再取得方針：最新版Excelは、ユーザーから更新の指示があった場合、またはファイル名・バージョン表記の変更を確認できた場合にのみ再ダウンロードする。指示がない限り、既に取得済みの内容を使用し、毎回ダウンロードし直さない。Notionデータベースのスキーマ全体・選択肢一覧も、候補確認のたびに再取得しない（仕様書No.1 8.6のプロパティ正本を参照）
• 対象期間の標準：実行日を含む直近7日間（日本時間）
• 優先順位：仕様書No.2最新版 ＞ 最新版Excel「検索URL」 ＞ 個別実行指示 ＞ 過去の会話

1. 目的

指定された9つのニュースサイトを漏れなく巡回し、直近1週間に掲載された電力・再生可能エネルギー・蓄電池・環境価値・脱炭素等の候補を収集する。候補ごとに発表企業・団体の公式一次情報を確認し、Notion重複確認を通過した案件だけを、仕様書No.1の記事作成・分類・画像処理・Notion登録工程へ渡す。

9サイトの記事本文や画像を転載することが目的ではない。9サイトはニュース候補の「発見元」であり、記事の根拠、出典、本文画像は公式一次情報に限定する。

2. 正式な巡回対象9サイト

1. 電気新聞
2. スマートジャパン
3. エネハブ
4. 環境ビジネスオンライン
5. メガソーラービジネス
6. 新エネルギー新聞
7. 日本経済新聞
8. 日刊工業新聞
9. サステナブルJapan

Excelの「検索URL」シートが更新された場合は、仕様書No.2の版番号と本一覧も更新する。

3. 処理の全体像

フェーズA：対象期間の確定

• 標準は、実行日の日本時間00:00を基準とした当日を含む7暦日
• 例：7月17日に実行する場合、7月11日00:00～7月17日23:59
• ユーザーが開始日・終了日を指定した場合は、その期間を優先する
• 各サイトの掲載日を候補抽出の基準とする
• 公式一次情報の発表日は、候補掲載日より前の場合がある。記事の「発表日」には、引き続き公式一次情報の発表日時を記録する
• 記事の「公開日時」は、下記「フェーズA-2：公開日時の設定」に従って決定する

フェーズA-2：公開日時の設定

記事作成・Notion登録時の「公開日時」は、次の二段階ルールで決定する。

1. 直近7日以内の発表：記事を生成する日時（日本時間）から過去7日以内に公式一次情報が発表された案件は、「公開日時」に記事作成・登録を実行した現在日時を設定する。これにより、新着記事としてサイト上部に表示させる
2. 7日を超える過去の発表：公式一次情報の発表から記事生成日時までが7日を超える案件は、「公開日時」に企業・団体等が公式発表した日時を設定する

判定基準は以下のとおりとする。

• 発表時刻まで確認できる場合は、記事生成日時から遡る168時間以内を「7日以内」とする
• 発表日しか確認できない場合は、日本時間の暦日で記事生成日を含む直近7日間を「7日以内」とする
• 公式発表時刻が不明な場合でも、「発表日」自体を現在日時へ変更してはならない。現在日時を設定するのは「公開日時」だけとする
• 「作成日時」はNotionへの実際の登録日時、「発表日」は公式一次情報の日時、「公開日時」は本ルールで決定した表示順制御用日時として、それぞれ区別する
• ユーザーが個別案件について公開日時を明示した場合は、その指定を優先する

フェーズB：9サイトの巡回

各サイトについて、次を最後まで確認する。

1. トップページ、ニュース一覧、最新記事一覧を開く
2. 対象期間内の記事を抽出する
3. ページ送り、もっと見る、日付別一覧がある場合は、期間境界まで確認する
4. タイトル、掲載日、記事URL、概要、記載企業・団体、案件名を記録する
5. 有料記事や本文を読めない記事でも、見出しから公式発表を特定できる場合は候補に残す
6. 同一サイト内の重複、更新記事、再掲をまとめる

1サイトで少数件を見つけただけで巡回完了としない。対象期間より古い記事へ到達したこと、または当該期間の一覧を最後まで確認したことを巡回完了の条件とする。

フェーズB-2：候補件数とバッチ目標

• 各サイトについて、対象期間内の候補を原則3件以上確認する。3件未満の場合は、一覧の期間境界、ページ送り、関連カテゴリ、検索結果まで確認し、実際に3件未満であることを記録する
• 9サイト合計では、一次情報確認前の候補を十分広く収集し、1回のバッチでNotion新規登録10件以上を目標とする
• 10件に達しない場合、別サイトの同一発表、単なる転載、一次情報なし、既存重複を水増ししてはならない
• 1巡目で登録可能案件が10件未満の場合は、対象期間内を再検索し、企業名・案件名・主要数値・公式発表日を使った補完検索を行う
• 補完検索後も10件未満の場合は、品質条件を緩和せず、確認サイト数、候補数、重複数、一次情報なし数、最終登録数および不足理由を報告する
• 「各サイト3件」は調査目標であり、各サイトから必ず3件登録するという意味ではない。完成記事は公式一次情報と重複条件を通過したものに限る

フェーズC：9サイト横断の名寄せ

複数サイトが同じ発表を扱っている場合は、次のキーで一つの候補に統合する。

• 発表企業・団体
• 正式案件名、発電所名、蓄電所名
• 所在地
• MW、MWh、契約量等の主要数値
• 発表日
• 公式一次情報URL

発見元サイトは複数記録してよいが、作成する記事は原則1件とする。

フェーズD：適切性の判定

候補は次の基準をすべて満たす場合に採用候補とする。

• 電力、再エネ、蓄電池、送配電、電力市場、PPA、環境価値、Scope 2、水素、アンモニア、SAF、EV、データセンター、AI電力需要、資源・LNG、GX等、最新版Excelの分類対象に関係する
• 具体的な発表事実がある
• 発表主体、案件、制度、数値、時期等のいずれかにニュース価値がある
• 単なる一般論、広告、製品紹介、イベント告知だけではない
• 電力シェアリングNewsの既存記事と同一発表ではない
• 公式一次情報を確認できる、または確認可能性が高い

次の候補は原則除外する。

• 一次情報が特定できない観測記事、匿名情報、噂
• 二次記事だけを要約しなければ成立しないもの
• 発表事実のないコラム、転載、ランキング
• 電力・脱炭素との関係が極めて弱い一般企業ニュース
• 同一発表の重複記事
• 発表主体や主要数値を一次情報で裏づけられない記事

フェーズE：公式一次情報の探索

候補ごとに、次の順で公式情報を探す。ただし、PR TIMES等の正規プレスリリース配信サービスは、案件固有の画像が掲載されていることが多いため、下記1～4より先に確認する（詳細は本ページ末尾の追加規則を参照）。

1. 発表企業・団体のニュースルーム、プレスリリース
2. 共同発表企業の公式サイト
3. 官公庁、自治体、公的機関、取引所、系統運用機関等の公式発表
4. 適時開示、法定資料、公式環境影響評価資料
5. 発表主体が正式に配信したPR TIMES、共同通信PRワイヤー、@Press、ValuePress!等の正規プレスリリース配信ページ
6. 公式PDF

プレスリリース配信サービスは、特定の発見元に限らず、9サイトから発見したすべての候補について公式一次情報として採用できる。ただし、次をすべて確認する。

• 配信ページに発表主体の正式名称が明記され、企業・団体自身による正式発表である
• 発表日、案件名、主要事実、問い合わせ先等から発表主体との関係を確認できる
• 配信サービスの正規記事であり、第三者転載、ニュース記事、引用、まとめページではない
• 発表主体の自社サイトに同一発表がある場合でも、配信サービス側により適切な画像・詳細情報があれば配信サービス側を優先する
• 自社サイトに未掲載、検索不能、リンク切れ、または配信サービスのみで正式発表している場合は、配信サービスの正規URLを一次情報URLおよび出典リンクに使用できる

検索語は「企業名＋案件名」「企業名＋主要数値」「発電所名／蓄電所名」「発表日」「site:公式ドメイン」等を組み合わせる。

一次情報と認定する前に、次を照合する。

• ドメインが発表主体または公的機関の公式ドメインである
• タイトル、企業名、案件名、主要数値が候補と一致する
• 発表日が確認できる
• 共同事業者の役割が一致する
• PDFの場合、公式サイトからリンクされているか、公式ドメイン上にある
• 二次サイトが保存した画像やPDFではない

フェーズF：一次情報の確認結果

各候補を次のいずれかに分類する。

• 確認済み：公式一次情報が開き、発表内容を照合できた
• 重複：Notionに同一発表の記事が存在する
• 一次情報なし：合理的な検索を行っても確認できない
• 不一致：見つかった公式情報が二次記事の内容と一致しない
• 保留：サイト障害、リンク切れ、判定材料不足等で即時判断できない
• 対象外：分類対象やニュース価値の基準を満たさない

「確認済み」だけを仕様書No.1へ引き渡す。

4. Notion重複確認

公式一次情報を確認した後、仕様書No.1の重複確認規則に従い、次を検索する。

1. 一次情報URL
2. 正式案件名、発電所名、蓄電所名
3. 発表企業・団体名と主要数値
4. タイトルの主要語
5. 同一案件の進捗段階

同一案件でも、契約締結、着工、受電開始、商業運転開始、資金調達等、発表事実が異なる場合は別記事として扱える。単なる二次サイト側の見出し変更は別記事にしない。

5. 仕様書No.1への引渡し情報

確認済み候補ごとに、最低限次の情報をまとめる。

• 候補ID
• 発見元サイト名
• 発見元記事タイトル
• 発見元掲載日
• 発見元URL
• 公式発表主体
• 共同発表企業・団体
• 公式一次情報タイトル
• 公式一次情報URL
• 公式発表日時
• 案件名
• 所在地
• 主要数値
• 発表事実の種類
• 想定カテゴリー
• 想定分類
• 画像候補の有無
• Notion重複確認結果
• 採用・除外・保留
• 判定理由

発見元URLは調査記録として保持できるが、完成記事の出典リンク、本文画像、画像URLには使用しない。

6. 仕様書No.1との連続実行

仕様書No.2で「確認済み・重複なし」となった候補について、停止せず次の順で仕様書No.1を実行する。

1. 最新版Excelの「新定数表」を読み、最も適合する新定数を最大3つまで特定する。特定した新定数が孫（Tier120）の場合は子（Tier110）と親（Tier100）を、子（Tier110）の場合は親（Tier100）をあわせて特定し、仕様書No.1のプロパティ「新定数タグ」へ設定する（最大9タグ）
2. 約800字の記事本文を作成
3. 公式一次情報由来の画像を選定し、取得・画像化まで完了する。画像を用意できない候補は仕様書No.1へ登録実行せず「画像取得保留」とする
4. タイトル、本文、各Notionプロパティを組み立て、本文第1段落直下へ画像ブロックを最低1点配置する
5. 仕様書No.1の登録前チェックリストを全件実行
6. Notionへ登録
7. 登録後にNotionページを再取得し、本文第1段落直下の画像ブロックを確認する
8. Notion新規登録数 = 画像挿入・再取得確認済み記事数を照合する
9. 一括処理結果を報告

途中で利用上限、権限、タグ選択肢、画像取得等のエラーが発生した場合は、処理済み・未処理・再開地点を明示し、完了したように報告しない。

7. 巡回チェックリスト

7.1 サイト単位

7.2 候補単位

8. 件数管理と取りこぼし防止

処理中は次の件数を保持し、最終的に一致させる。

全発見候補数
= 確認済み候補数
+ 重複数
+ 一次情報なし
+ 不一致
+ 保留
+ 対象外

さらに、確認済み候補数は次と一致させる。

確認済み候補数
= Notion新規登録数
+ 仕様書No.1工程での保留・エラー数

9サイトのうち未巡回サイトが一つでもある場合、「9サイトの処理完了」と報告しない。

9. 結果報告フォーマット

対象

• 実行日時：
• 対象期間：
• 巡回サイト：9／9

集計

• 発見候補：
• 横断重複統合後：
• 一次情報確認済み：
• Notion重複：
• 一次情報なし：
• 対象外：
• 保留：
• Notion新規登録：
• 画像あり：
• 画像なし：

サイト別

各サイトについて「確認した期間」「発見候補数」「一次情報確認済み数」「採用数」「備考」を記録する。

記事別

登録記事のタイトル、公式一次情報URL、公開日時、新定数タグ、画像有無を一覧化する。除外・保留候補は理由を付ける。

10. 自動化・プログラム用ロジック

11. ChatGPT／作業エージェント用の開始指示

「仕様書No.2｜9サイト巡回・候補抽出・一次情報確認」の最新版、仕様書No.1、最新版Excelを最初に読み込んでください（既に読み込み済みで、ユーザーからの更新指示やバージョン変更の確認がなければ、再ダウンロードする必要はありません）。Notionのプロパティ名・型は仕様書No.1 8.6の正本を優先し、データベーススキーマ全体の再取得は行わないでください。Excelの検索URLシートにある9サイトを、指定期間または日本時間の直近7日間について期間境界まで巡回してください。候補を横断名寄せし、公式一次情報を確認し、Notionの重複を確認してください。確認済み・重複なしの案件だけを仕様書No.1へ引き渡し、記事作成、分類、一次情報由来の画像処理、Notion登録、登録後検査まで連続して実行してください。9サイト未巡回、一次情報未確認、登録後未検査の状態で完了とは報告しないでください。」

12. 変更履歴

• 1.7（2026年7月24日）：最新版Excelはユーザーからの更新指示またはバージョン変更の確認がある場合にのみ再ダウンロードする方針を追加。Notionデータベーススキーマ全体・選択肢一覧も候補確認のたびに再取得しないことを明文化（仕様書No.1 v1.9と整合）。
• 1.6（2026年7月24日）：一次情報の探索順序を変更。PR TIMES等の正規プレスリリース配信サービスを、発表主体の自社サイト（ホームページ）より先に確認する方式へ一本化（配信サービス側に案件固有の画像が掲載されていることが多いため）。あわせて、本文画像はJPEG/PNG等のファイルとして直接取得できる場合はダウンロードを優先し、直接取得できない場合に限りスクリーンショットを撮影するルールを明文化（仕様書No.1 v1.8と整合）。
• 1.5（2026年7月24日）：仕様書No.1への引渡し後の分類手順を変更。「分類と新管理番号を確定」を廃止し、最新版Excel「新定数表」に基づき最も適合する新定数を最大3つ特定し、孫（Tier120）→子（Tier110）→親（Tier100）の階層を展開して仕様書No.1の「新定数タグ」プロパティへ設定する方式に一本化（仕様書No.1 v1.7と整合）。
• 1.4（2026年7月18日）：仕様書No.1への連続実行で本文画像を強制完了条件化。画像を用意できない候補は登録せず保留とし、新規登録数と第1段落直下の画像再確認済み件数が一致しない限りバッチ完了を禁止。
• 1.3（2026年7月18日）：PR TIMES等の正規プレスリリース配信サービスを、発表主体自身の正式配信と確認できる場合は全候補共通で公式一次情報として採用可能と明文化。自社サイト優先、第三者転載・まとめページ除外、確認条件を追加。
• 1.2（2026年7月18日）：公開日時の設定ルールを追加。公式発表が記事生成日時から7日以内なら公開日時を作成時の現在日時とし、7日超なら公式発表日時を使用する。発表日・作成日時・公開日時の役割を明確化。
• 1.1（2026年7月17日）：各サイト原則3件以上の候補確認、1バッチ10件以上の新規登録目標、10件未満時の補完検索と不足理由報告を追加。品質・一次情報・重複条件は維持。
• 1.0（2026年7月17日）：Excel「検索URL」の9サイトを正式な巡回対象として制定。直近7日間の候補抽出、横断名寄せ、適切性判定、一次情報確認、Notion重複確認、仕様書No.1への引渡し、連続登録、件数照合、完了条件を明文化。

追加規則：二次媒体リンク・画像の完全排除（2026年7月19日）

• スマートジャパン、ITmedia／JPubbの「プレスリリース一覧」および個別転載ページ、環境ビジネスオンライン、eNeHub、新聞・専門メディア等は、候補発見と検索語の取得にだけ使用する。
• 上記の二次媒体URLを「一次情報URL」「画像URL」「出典リンク」「アイキャッチ」「本文画像」「スクリーンショット」に設定することを禁止する。「プレスリリース」「powered by JPubb」等と表示されていても一次情報とは認定しない。
• 採用可能なのは、発表企業・共同発表者・官公庁等の公式サイト、または発表主体自身が正式配信したPR TIMES、共同通信PRワイヤー、@Press、ValuePress!等の正規配信ページに限る。
• 配信サービスを使う場合は、発表主体名、発表日、案件名、主要数値、問い合わせ先等を照合し、単なる第三者転載でないことを確認する。企業公式サイトに同一発表がある場合でも、配信サービス側により適切な画像・詳細情報があれば配信サービス側を優先する。自社サイト側の内容・画像が明確に充実している場合に限り、自社サイトへ差し替える。
• 画像とスクリーンショットは、確定した一次情報URLと同一ドメインのページ、同じ公式発表の添付画像・公式PDF、または認定済み正規配信ページからのみ取得する。
• 登録前に、一次情報URL・出典URL・画像URL・本文画像URLのドメインを検査し、発見元・二次媒体ドメインが一つでも残っていれば登録または更新を停止する。
• 登録後にページを再取得し、4種類のURLに二次媒体が残っていないことを確認する。

追加規則：一次情報探索順序と画像ファイル直接取得の優先（2026年7月24日）

• 一次情報の探索は、PR TIMES、共同通信PRワイヤー、@Press、ValuePress!等の正規プレスリリース配信サービスを、発表主体の自社サイト（ホームページ）より先に確認する。配信サービス側に案件固有の写真・図表・キービジュアルが掲載されていることが多いため、画像取得の観点からも配信サービスを優先探索する。
• 発表主体の自社サイトは、配信サービス側に該当発表が見当たらない場合、内容が不十分な場合、または自社サイト側により適切な画像・詳細情報がある場合にあわせて確認する。
• 本文画像は、JPEG/PNG等の画像ファイルとしてページから直接取得できる場合、その画像ファイルを直接ダウンロードして使用する。スクリーンショットは、直接ダウンロード可能な画像ファイルが存在しない場合に限る。

追加規則：画像の視認性・訴求力に関する優先順位（2026年7月19日）

完成記事の画像は、単に一次情報由来であるだけでなく、読者が案件内容を直感的に理解できることを重視する。次の順序で候補を探索し、上位候補が利用可能な場合は下位候補を採用しない。

1. プロジェクト・設備・現場の公式写真：発電所、蓄電所、工場、設備、建設現場、施設外観等、記事対象そのものが分かる写真
2. 仕組みを示す公式図表：事業スキーム図、契約・電力供給フロー、システム構成図、地図、配置図、工程図、主要数値を視覚化したグラフ
3. 公式キービジュアル：同じ公式発表に掲載された案件固有のイメージ、完成予想図、関係者写真等
4. 一次情報の該当部分を切り取ったスクリーンショット：案件写真、図表、主要数値、プロジェクト名称等が大きく読み取れる範囲へ適切にクロップする
5. 文字中心のプレスリリース画面：上記1〜4が存在しない、取得できない、または権利・技術上利用できない場合に限り、タイトル、発表主体、発表日、要点が読める範囲を切り取って使用する

禁止・品質条件：

• ページ全体を縮小した、本文文字が大量に並ぶ「引き」のスクリーンショットを標準画像として選ばない
• 写真やスキーム図が一次情報内に存在するのに、取得の容易さだけを理由としてタイトル画面やページ全体を採用しない
• クロップ後も対象物・図表・主要文字が小さすぎて判読できない画像は不合格とする
• ナビゲーション、広告、Cookie表示、余白等が大部分を占める画像は使用しない
• 二次媒体の写真・図表・スクリーンショットは、視認性が高くても使用しない
• 登録前チェックで「画像の一次性」に加えて「写真・図表の探索実施」「優先順位」「判読性」「記事内容との一致」を確認する
• 画像候補の選定記録には、採用種別を「設備写真／現場写真／スキーム図／グラフ／キービジュアル／部分スクリーンショット／文字中心スクリーンショット」のいずれかで記録する
• 文字中心スクリーンショットを採用した場合は、上位候補を採用できなかった理由を作業記録へ残す

自動処理では、ページ全体のスクリーンショットを最初に生成する方式を禁止し、先にHTMLの画像要素、OG画像、公式添付画像、図表、PDF内の写真・図表を探索する。採用候補をクロップ・表示確認した後にNotionへ挿入し、本文第1段落直下で十分な大きさと判読性があることを再確認する。