仕様書No.1｜電力シェアリングNews 記事作成・Notion登録 標準運用仕様書

このページを記事作成・Notion登録の正本とする。 ChatGPTによる一括処理・個別処理・プログラム処理のいずれも、作業開始前に本ページと最新版Excelの「新定数表」を読み、登録前後のチェックリストを実行する。9サイトからの候補収集・一次情報確認を含む場合は、先に仕様書No.2｜9サイト巡回・候補抽出・一次情報確認を実行する。

文書管理

• 文書名：仕様書No.1｜電力シェアリングNews 記事作成・Notion登録 標準運用仕様書
• 版：1.9
• 制定日：2026年7月17日
• 適用先：管理ページ内「電力シェアリングNews」データベース
• 管理主体：株式会社電力シェアリング
• 分類コードの正本：最新版Excel「新定数表」（新定数タグの判定基準）、「検索URL」（候補収集対象サイト一覧）
• 資料の再取得方針：最新版Excelは、ユーザーから更新の指示があった場合、またはファイル名・バージョン表記の変更を確認できた場合にのみ再ダウンロードする。指示がない限り、既に取得済みの内容を使用し、毎回ダウンロードし直さない。Notionデータベースのスキーマ全体・選択肢一覧も、記事登録のたびに再取得しない（8.6のプロパティ正本を参照）
• 優先順位：本仕様書の最新版 ＞ 最新版Excel ＞ 個別作業時の追加指示 ＞ 過去の会話
• 変更方法：新しい恒常ルールが決まった場合、会話だけで終わらせず、本ページの版番号・変更履歴・該当箇所を更新する

1. 目的

企業・団体等の公式一次情報を収集し、重複と出典を確認したうえで、電力・再生可能エネルギー・蓄電池・環境価値等の専門ニュース記事を作成し、分類情報、公開日時、画像、出典リンクとともにNotionへ正確に登録する。

2. 標準処理フロー

1. 検索対象、対象期間、対象サイトを確定する。
2. ニュース発見サイトから候補を抽出する。
3. 候補ごとに発表主体の公式一次情報を探す。
4. 一次情報のURL、発表日、発表主体、対象事業、主要数値を確認する。
5. Notionでタイトル、企業名、案件名、一次情報URLを検索して重複を確認する。
6. 最新版Excelの「新定数表」を参照し、該当する新定数タグを判定する（最大3つの基本語を特定し、孫→子→親の階層を展開する）。
7. 約800字を標準としてタイトル・本文を作成する。
8. 一次情報上の画像または一次情報ページのスクリーンショットを取得する。
9. Notionの全プロパティと本文を設定する。
10. 登録前チェックを行い、合格した記事だけ登録する。
11. 登録後にページを再取得または表示確認し、リンク、画像、日時、分類を検査する。
12. 登録件数、除外件数、重複件数、保留件数と理由を報告する。

3. 情報源の採用基準

3.1 採用できる一次情報・探索順序

一次情報の探索では、まずPR TIMES、共同通信PRワイヤー、@Press、ValuePress!等の正規プレスリリース配信サービスを確認する。配信サービス側には、案件固有の写真・図表・キービジュアル等、記事化に適した画像が掲載されていることが多いため、発表主体の自社サイト（ホームページ）を直接確認するより先に、配信サービスを優先して確認する。

• 発表主体が正式に配信したPR TIMES、共同通信PRワイヤー、@Press、ValuePress!等のプレスリリース配信サービス上の記事
• 発表企業・共同事業者・官公庁・自治体・公的機関・業界団体の公式サイト
• 公式ニュースリリース、プレスリリース、ニュースルーム、適時開示
• 公式PDF、公式資料、公式の環境影響評価資料

プレスリリース配信サービスを一次情報として採用する条件：

• 配信ページに発表主体の正式名称が明記され、その企業・団体自身による発表であることを確認できる
• 発表日、案件名、主要事実、問い合わせ先等が掲載され、発表主体との関係を確認できる
• 配信サービスの正規記事URLであり、第三者による転載、引用、まとめ、ニュース化ページではない
• 共同発表の場合は、本文中の各社・団体の役割を確認できる
• 配信サービス側にこれらの条件を満たす発表が見つかった場合は、これを一次情報として採用する。発表主体の自社サイトは、配信サービス側に該当発表が見当たらない場合、配信サービス側の内容が不十分な場合、または自社サイト側により適切な画像・詳細情報がある場合にあわせて確認し、必要に応じて一次情報URLまたは画像を自社サイト側に差し替える

この規則は、スマートジャパン、EneHub、新聞等の特定の発見元に限らず、個別記事・一括処理・9サイト巡回を含むすべての記事作成に適用する。

3.2 二次情報の扱い

EneHub、新聞、通信社、専門メディア、まとめサイト等は「候補発見」にのみ使用する。記事本文、出典、画像の根拠には原則使用しない。一次情報が確認できない候補は登録せず、保留または除外とする。

3.3 共同発表

公式発表に複数の企業・団体が明記されている場合、関係する名称を広く取得し、「タグ」と「企業・団体」に反映する。本文では各社の役割を取り違えない。

3.4 スマートジャパン「プレスリリース一覧」の特別運用

スマートジャパンの候補収集では、通常のニュース一覧に加えて、次の「プレスリリース一覧」を必ず候補発見用インデックスとして巡回する。

1. プレスリリース一覧・1ページ目
2. プレスリリース一覧・2ページ目
3. プレスリリース一覧・3ページ目
4. プレスリリース一覧・4ページ目

運用規則は以下のとおりとする。

• 各回の巡回では末尾/1.htmlだけで終了せず、/2.html、/3.html、/4.htmlまで確認する
• 同一覧はJPubb提供情報を掲載した二次的な候補一覧であり、候補の発見にだけ使用する
• 一覧および一覧から遷移するITmedia／JPubb側の個別ページURLを、完成記事の「一次情報URL」または末尾の「出典」リンクに使用しない
• 一覧に記載された発表企業・団体名、見出し、発表日、案件名、主要数値を検索語として、発表主体の公式サイト、公式ニュースルーム、官公庁等の公式ページを探す
• 発表主体が公式配信したPR TIMES等は一次情報として優先的に採用できる。同内容が発表主体の自社サイトにもある場合でも、自社サイト側により適切な画像・詳細情報がある場合に限り自社サイトへ差し替える
• 公式一次情報上で、主体、発表日、案件名、主要数値および共同事業者を照合できた案件だけを記事化する
• 一次情報が確認できない案件は登録せず、「一次情報なし」または「保留」とする
• ITmedia／JPubb側の本文、画像、スクリーンショット、PDFを、記事本文、出典、画像URL、アイキャッチまたは本文画像に使用しない
• 本文画像は、確定した公式一次情報ページ、その公式添付画像、または公式PDFからのみ取得する
• 同一発表が通常のスマートジャパン記事や他の巡回サイトにも掲載されている場合は、一つの候補へ名寄せし、重複登録しない

4. 重複確認

次の順でNotion内を検索する。

1. 一次情報URLの完全一致
2. 正式案件名・発電所名・蓄電所名
3. 発表企業名と主要数値の組合せ
4. タイトルの主要語
5. 同一案件の過去記事

同じ一次情報・同じ発表内容の記事が存在する場合は新規登録しない。案件の進捗、着工、受電開始、運転開始、資金調達など発表事実が異なる場合は、別記事として登録できる。

5. タイトル規則

• ニュース記事として事実が一読で分かる形にする
• 原則：「【分類語】主体、行為・事業内容　主要規模・地域・時期」
• 発表、開始、締結、採択、着工、受電、運開、取得、参入等の動詞を明確にする
• 発表にない評価や断定、誇張表現を加えない
• 出力記事のタイトルとNotionの「名前」は同一にする
• 類似記事と区別できるよう、企業名、場所、MW・MWh、契約期間等の識別情報を含める

6. 本文規則

6.1 分量・文体

• 標準本文量：約800字
• 通常の許容範囲：おおむね700～900字
• 大型案件や制度記事で説明が必要な場合は、冗長さを避けながら必要量を追加できる
• です・ます調
• 専門家が判断できるよう、固有名詞、設備容量、蓄電容量、契約期間、運転開始時期、所在地、スキーム、関係企業の役割を具体的に記載する
• 一次情報にない数値や因果関係を推測で補わない

6.2 標準構成

第1段落：

「〇〇は、20XX年〇月〇日、〇〇を発表しました。」を基本形とし、発表主体、日付、発表事実、案件の要点を記載する。

第1段落直下：

採用可能な画像がある場合、一次情報由来の画像またはスクリーンショットを挿入する。

中見出し1：

設備、契約、事業スキーム等の具体的内容。

中見出し2：

背景、地域・市場上の意味、今後の予定。ただし一次情報で裏づけられる範囲に限定する。

末尾：

• 「出典：発表主体・資料名」
• 「電力シェアリングニュース記事一覧へ＞＞」

6.3 出典リンク

• 「出典」は必ずMarkdownハイパーリンクにする
• EneHub等の発見元ではなく、公式一次情報へ直接リンクする
• リンク切れ、リダイレクト、別記事への誤リンクがないか登録前に確認する
• 記事一覧リンクはすべてのニュース記事に付ける

7. 画像・スクリーンショット規則

7.1 優先順位

1. 一次情報ページ（配信サービスを優先確認した後の一次情報ページ）に掲載された事業・設備・図表・キービジュアル。JPEG/PNG等の画像ファイルとして直接取得できる場合は、その画像ファイルを直接ダウンロードして使用する
2. 発表企業が同じ発表に添付した公式画像。この場合も画像ファイルとして直接取得できるときはダウンロードを優先する
3. 画像ファイルとして直接取得できない場合に限り、一次情報HTMLページの該当部分をスクリーンショットする
4. 公式PDFの該当ページをローカルで画像化したもの

7.2 禁止事項

• EneHub、新聞、専門メディア等、二次情報サイトのスクリーンショットを本文画像に使わない
• 一次情報と無関係な一般画像や別案件の画像を使わない
• PDFのURLをWordPress等の外部プレビュー生成サービスへ直接渡さない
• 「Generating Preview…」のままになる外部プレビュー画像を使わない
• 画像の出所を推測しない

7.3 画像取得の必須フロー

• 通常ニュース記事は、原則として本文第1段落直下に一次情報由来の画像を最低1点挿入する
• 最初に、一次情報ページまたは同じ公式発表に掲載された写真、設備画像、図表、キービジュアルを探し、利用可能ならその画像を採用する
• 公式写真等がない場合は、一次情報HTMLページの発表見出し、案件概要、主要数値、図表等が分かる部分をスクリーンショットし、画像として挿入する
• HTMLに適切な対象がなくPDFしかない場合は、PDFを取得して該当ページをPNG/JPEGへ変換し、画像ファイルとしてNotionへアップロードする
• 画像URLを取得できても、本文への画像ブロック挿入を省略しない。画像URLプロパティと本文画像は別々に確認する
• 一次情報ページが取得不能、画像化不能などで画像を用意できない場合、その記事は登録完了扱いにせず「画像取得保留」とする。ユーザーが当該記事について画像なし登録を明示的に許可した場合を除き、画像なしの新規登録は禁止する。二次情報や無関係画像による代用は禁止する

7.4 画像の強制完了条件

• 本仕様書No.1の実行を指示された場合、Notionへ新規登録する全記事に、一次情報由来の画像ブロックを本文第1段落直下へ最低1点挿入する
• 「画像URL候補を見つけた」「画像ファイルを作成した」「画像URLプロパティへ入力した」だけでは完了としない。Notion本文内の画像ブロックとして保存され、再取得時に確認できることを完了条件とする
• 登録前に本文画像数 >= 1を検査し、0件なら登録処理を停止する
• 登録後にページを再取得し、画像ブロックが第1段落と最初の中見出しの間に存在することを確認する
• 一括処理では、Notion新規登録数 = 第1段落直下の画像確認済み記事数が成立しない限り、バッチ完了と報告しない
• 画像取得に失敗した記事は、成功記事と分けて保留件数・理由・再開地点を報告する
• 既存記事を修正する場合も同じ検査を適用し、画像が保存されたことを再取得で確認する
• 画像URLプロパティには、実際に使用した一次情報由来画像のURLのみを設定する

8. Notionプロパティ規則

8.1 必須項目

• 名前：記事タイトル
• 新定数タグ：最新版Excel「新定数表」の新定数列に基づき判定する（判定方法は9章）。カテゴリー・一般のタグへ分類目的の入力は行わない
• タグ：企業・団体、案件名、技術、制度等。複数選択
• 企業・団体：公式発表に記載された関係企業・団体をスラッシュ区切り等で記載
• 一次情報URL：公式一次情報の直接URL
• 発表日：一次情報の公式発表日時
• 公開日時：下記規則に従う日時
• 国家・地域：記事に関連する所在地のうち最も細かい国・地域名（判定方法は9.4）
• 都道府県：国家・地域が日本の場合で特定できるときのみ設定する（判定方法は9.4）
• 画像URL：採用画像がある場合のみ

8.2 記事種別

ユーザーから個別指定がないニュース記事は空欄とする。「ニュース」等を自動入力しない。解説・論考等を指定された場合だけ、指定された値を設定する。

8.3 タグ

• 公式発表に明記された関係企業・団体を可能な限りすべて登録する
• 既存選択肢に企業名がなければ、新しいタグ選択肢として追加してから記事へ設定する
• 同一企業の表記揺れを避け、既存の正式名称を優先する
• 企業・団体プロパティを設定しても、タグの登録を省略しない
• 案件に無関係な企業名を推測で追加しない

8.4 日時

発表日：

• 公式一次情報に記載された発表日時
• 時刻の記載がない場合は、標準時刻を明示的に設定する。通常は日本時間09:00とし、個別ルールがある場合はそれに従う

公開日時：

• 原則として公式発表日時、またはそれに準ずる案件発生日を設定する
• 過去月の記事を後日登録する場合でも、登録日現在の日時を設定しない
• 対象期間の上限を超える日時を設定しない
• 必ず時刻まで入力し、Notion/Superの降順ソートが安定するようにする
• 同時刻の記事が多数ある場合は、発表順が確認できる範囲で時刻をずらす。ただし日付を変えない

8.5 記事ランク

記事作成時にニュース価値を判定し、「記事ランク」へ 8、6、4のいずれかを入力する。いずれの基準にも届かない場合は、0を入れず空欄とする。

• 8｜トップ見出し級：サイト全体のトップ見出しになり得る最重要ニュース。日経新聞・電気新聞等でも主要な扱いを得る規模・制度的重要性・市場影響があるもの、またはそれに準ずる独自性・波及性を持つもの。例：国の重要制度変更、電力市場全体へ大きく影響する監督・規制判断、極めて大規模な投資・再編、業界構造を変える技術・事業。
• 6｜サブカテゴリートップ級：再エネ、電力取引、蓄電池、政策等のサブカテゴリーでトップ見出しになり得る重要ニュース。希少性が高い案件、相応に大規模な事業、地域・技術分野で先行性のある計画、業界動向を示す統計・制度情報など。
• 4｜トップページ最新ニュース級：トップページの「最新ニュース」に掲載する価値があるニュース。一定規模の設備導入、企業の具体的な事業開始、注目すべき市場価格、実証・技術導入等で、読者に有用な新規性・具体性があるもの。
• 空欄｜通常・低ニュース価値：ありふれた小規模案件、同種案件の反復、主要数値や独自性に乏しい発表。例として、小規模な蓄電所・設備の単純な新設で、市場・地域・技術への波及が限定的なもの。

判定は企業規模や媒体掲載の有無だけで決めず、①社会・市場への影響、②事業規模、③希少性・新規性、④政策・制度的重要性、⑤読者への実務的有用性、⑥他案件への波及性を総合評価する。二次情報媒体に掲載された事実だけを理由に加点しない。迷う場合は上位ランクを推定で付けず、一段下または空欄とし、判定根拠を作業記録に残す。

8.6 Notionプロパティ名・主要選択肢の正本（スキーマ再取得の抑制）

新規記事登録のたびにNotionデータベースのスキーマ全体（選択肢一覧を含む）を再取得しない。以下に、2026年7月24日時点で確認済みのデータソース「電力シェアリングNews」の正式プロパティ名と型を記録する。プロパティ名・型に変更があったとユーザーから指示された場合、または新しい選択肢が必要になった場合のみ、該当プロパティだけを個別に確認・更新する。

確認済みプロパティ一覧（※カテゴリー・新管理番号・ProjectTypeは廃止済みで使用しない）：

• 名前（title）
• 新定数タグ（multi_select）
• タグ（multi_select、企業・団体名等）
• 企業・団体（text）
• 一次情報URL（url）
• 発表日（date）
• 公開日付（date）※正式名称は「公開日付」であり「公開日時」ではない
• 国家（multi_select）※正式名称は「国家」であり「国家・地域」ではない
• 都道府県（multi_select）
• 画像URL（url）
• 記事ランク（number）
• 記事種別（select）
• ID記事＃（number）
• 主催者（text）
• 委員会名（text）
• 市場・制度名（text）
• 議事要旨F（text）
• 開催日（date）
• 回数（text）
• 処理状態（multi_select）
• 作成日時（created_time、自動）
• ENG（select）

新定数タグ・タグ・国家・都道府県は既存選択肢が多数登録されているため、記事ごとに使用予定の値だけをピンポイントで確認し（既存一致の確認または新規追加の実行）、プルダウン全件の取得は行わない。

9. 新定数タグの判定

分類は最新版Excel「新定数表」シートの新定数列の言葉を、Notion「新定数タグ」プロパティへ入力する方式に一本化する。カテゴリー・一般のタグ（企業・団体を除く）へ分類目的の入力は行わない。

9.1 基本原則

• 新定数表は「カテゴリーTier＃」列でTier100（親）／Tier110（子）／Tier120（孫）の階層を表す
• タイトルの語だけでなく、発表本文の事業実態に最も適合する新定数の言葉を判定する
• 判断が曖昧な場合は推測入力せず保留し、根拠を記録する

9.2 階層展開ルール

1. 記事内容に最も適合する新定数の言葉を1つ特定する（例：「再エネ税」）
2. 特定した言葉が孫（Tier120）の場合、その子（Tier110）および親（Tier100）の言葉もあわせてタグへ追加する
• 例：「再エネ税」（孫）→「再エネ政策規制」（子）→「政策規制」（親）の3つをタグに記録する
3. 特定した言葉が子（Tier110）の場合、その親（Tier100）の言葉もあわせてタグへ追加する（2つを記録）
4. 特定した言葉が親（Tier100）の場合、その言葉のみを記録する（1つ）

9.3 複数トピックへの対応

• 1記事の中に複数の異なる論点（例：政策規制と別の発電プロジェクト等）が含まれる場合は、それぞれについて9.2の展開ルールを適用する
• 最も適合する新定数の言葉（孫を基本とする）は最大3つまで特定できる
• 3つとも孫で、それぞれが子・親を伴う場合、タグは最大9つとなる

9.4 国家・地域、都道府県

• 記事に関連する所在地のうち最も細かい国・地域名を1つ「国家・地域」プロパティへ記録する（例：日本、アメリカ、EU、イギリス。EU加盟国固有の内容であれば、ドイツ等の国名をEUより優先する）
• 日本国内で都道府県が特定できる場合は「都道府県」プロパティへ記録する（例：神奈川県、北海道）

10. 登録前チェックリスト

一つでも重大項目に不合格がある場合は登録せず、保留理由を記録する。

11. 登録後チェックリスト

12. 一括処理の報告形式

処理完了後、次を報告する。

• 発見候補数
• 一次情報を確認できた件数
• 新規登録件数
• 重複除外件数
• 一次情報なし等の除外件数
• 保留件数と理由
• 画像あり／画像なし件数
• 修正または例外処理を行った記事
• 登録した記事のタイトル一覧

「対象期間の全件を処理した」と報告する場合は、対象ページを最後まで調査したことを確認する。少数件だけを処理して全件完了とはしない。

13. エラー処理

• Notionの未登録タグエラー：既存選択肢を壊さず、正式名称の選択肢を追加してから再登録する
• 利用上限・権限エラー：登録を続行したように見せず、未処理件数と再開地点を明示する
• リンク切れ：別の公式URL、公式PDF、公式アーカイブを探す
• 画像エラー：原因画像を削除し、一次情報由来の静止画像へ差し替える。適切な代替がなければ画像なしとする
• PDFのみ：ローカルで該当ページを画像化してアップロードする
• 分類不明：空欄で登録せず、Excelと過去事例を確認する
• 途中停止：処理済み、重複、除外、未処理を一覧化し、次回は未処理から再開する

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

以下を毎回、新規チャットまたは作業開始時に使用する。

「仕様書No.1｜電力シェアリングNews 記事作成・Notion登録 標準運用仕様書」の最新版と、最新版Excelの「新定数表」「検索URL」を最初に読み込んでください（既に読み込み済みで、ユーザーからの更新指示やバージョン変更の確認がなければ、再ダウンロードする必要はありません）。Notionのプロパティ名・型は本仕様書8.6の正本を優先し、データベーススキーマ全体の再取得は行わないでください。本仕様書を正本として、一次情報確認、Notion重複確認、約800字の記事作成、一次情報由来の画像処理、新定数タグの判定（孫→子→親の階層展開を含む）、国家・地域と都道府県の設定、公開日時、出典リンク、登録前後チェックをすべて実施してください。記事種別は指定がない限り空欄です。恒常ルールの変更があれば、作業終了前に本仕様書の版番号・変更履歴・該当箇所を更新してください。」

15. プログラム実装時の処理ロジック

16. 変更履歴

• 1.9（2026年7月24日）：確認済みのNotionプロパティ名・型・主要選択肢を本仕様書（8.6）に書き出し、記事登録のたびにNotionデータベースのスキーマ全体を再取得しない方針を明文化。あわせて、最新版Excelはユーザーからの更新指示またはバージョン変更の確認がある場合にのみ再ダウンロードする方針を追加。
• 1.8（2026年7月24日）：一次情報の探索順序を変更。PR TIMES等の正規プレスリリース配信サービスを、発表主体の自社サイト（ホームページ）より先に確認する方式へ一本化（配信サービス側に案件固有の画像が掲載されていることが多いため）。あわせて、本文画像はJPEG/PNG等のファイルとして直接取得できる場合はダウンロードを優先し、直接取得できない場合に限りスクリーンショットを撮影するルールを明文化。
• 1.7（2026年7月24日）：分類方式を全面刷新。新管理番号（6桁コード・名称）、新管理番号6桁、分類プロパティ（RE・ST・MA・GH・DC-・EL・PR・ProjectType）の記述を削除し、最新版Excel「新定数表」の新定数列を用いた「新定数タグ」方式に一本化。記事内容に最も適合する新定数の言葉を最大3つまで特定し、孫（Tier120）→子（Tier110）→親（Tier100）の階層を展開してタグへ追加するルールを新設（最大9タグ）。カテゴリー・一般タグへの分類目的の入力を廃止。あわせて「国家・地域」（最も細かい単位）と「都道府県」（日本の場合）のプロパティ設定ルールを追加。
• 1.6（2026年7月18日）：画像を用意できない記事を「画像取得保留」とし、明示的な例外許可がない限り画像なし登録を禁止。本文第1段落直下の画像ブロックを登録前後に強制検査し、新規登録数と画像確認済み記事数が一致しない限り完了報告を禁止する条件を追加。
• 1.5（2026年7月18日）：PR TIMES等の正規プレスリリース配信サービスを、発表主体自身の正式配信と確認できる場合は全記事共通で公式一次情報リンクとして採用可能と明文化。自社サイトに同一発表がある場合の優先、転載・まとめページの除外、確認条件を追加。
• 1.4（2026年7月18日）：スマートジャパンのJPubb提供「プレスリリース一覧」1～4ページを候補発見用に巡回する特別運用を追加。ITmedia／JPubbの一覧・個別ページは出典・一次情報URL・画像に使用せず、企業・団体等の公式一次情報または公式配信PR TIMESを検索・照合してから記事化する規則を明文化。
• 1.3（2026年7月17日）：通常記事の本文画像を原則必須化。一次情報の公式写真を優先し、ない場合は一次情報HTMLまたは公式PDFからスクリーンショットを作成して第1段落直下へ挿入する手順を明確化。
• 1.2（2026年7月17日）：記事ランクを新設。8＝全体トップ見出し級、6＝サブカテゴリートップ級、4＝トップページ最新ニュース級、基準未満＝空欄とする判定基準、登録前後チェック、実装ロジックを追加。
• 1.1（2026年7月17日）：文書を「仕様書No.1」として採番し、候補収集を定める仕様書No.2との連続運用に対応。n- 1.0（2026年7月17日）：これまでの恒常ルールを統合。一次情報限定、約800字、画像の一次情報限定、PDF外部プレビュー禁止、記事種別原則空欄、公開日時の時刻必須、蓄電池記事のEL空欄、新管理番号、未登録タグ追加、登録前後検査、一括処理報告を明文化。

追加規則：二次媒体リンク・画像の完全排除（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!等の正規プレスリリース配信サービスを、発表主体の自社サイト（ホームページ）より先に確認する。配信サービス側に案件固有の写真・図表・キービジュアルが掲載されていることが多いため、画像取得の観点からも配信サービスを優先探索する。
• 発表主体の自社サイトは、配信サービス側に該当発表が見当たらない場合、内容が不十分な場合、または自社サイト側により適切な画像・詳細情報がある場合にあわせて確認し、必要に応じて一次情報URLまたは画像を自社サイト側に差し替える。
• 本文画像は、JPEG/PNG等の画像ファイルとしてページから直接取得できる場合、その画像ファイルを直接ダウンロードして使用する。スクリーンショットは、直接ダウンロード可能な画像ファイルが存在しない場合に限る。

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

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

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

禁止・品質条件：

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

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