DEV Community: Hajime

見出しと概要だけを持ち、本文は原文へ返す — 業界ニュースの扱い方

Hajime — Thu, 10 Sep 2026 01:11:58 +0000

見出しと概要だけを持ち、本文は原文へ返す — 業界ニュースの扱い方

業界のニュースを1か所に集めたい、という要望は珍しくありません。実装だけを考えるなら、取ってきて保存して並べれば終わります。

厄介なのは、集めたものが他人の書いた記事だという点です。ここをどう扱うかで、設計はまるごと変わります。

印刷業界のニュースを扱っているサイトが、この方針を明記していたので、設計の観点から読み解いてみます。

→ 印刷業界のニュースと展示会情報は PrintBiz

書かれていた方針

サイトの記載はこうでした。

掲載するのは見出しと概要だけで、出典は必ず明記する
本文は必ず原文へリンクする
掲載についての指摘や削除の申し出は、問い合わせ窓口で受ける

3行ですが、データの持ち方が決まる3行です。

保存するもの / 保存しないもの

この方針を素直にモデルに落とすと、こうなります。

持つもの

見出し
概要(自分たちの言葉で書いたもの)
出典(発信元の名前)
原文の URL
公開日時
カテゴリ

持たないもの

本文
本文中の画像

本文を持たないと決めると、全文検索は成立しません。検索の対象は見出しと概要だけになります。ここを「機能の削減」と見るか「持たない設計の帰結」と見るかで、実装の方針が分かれます。

表示の側で必要になること

本文を持たないなら、一覧の情報量は見出しと概要で決まります。並べ方も効いてきます。

記事のカテゴリは、機材・技術、パッケージ・紙器、サイン・大判、DX・ソフトウェア、経営・業界動向、実務・ノウハウ、環境・サステナ、展示会・セミナー、調査・市場の9つに分かれていました。

ニュースの見出しの例として、こういう粒度のものが並んでいます。

段ボールを使った地域循環型の CO₂ 削減ビジネスの話
RFID の国際標準規格「TDS2.0」に対応したソリューションの開発
QR コードを届け先ごとに変えて DM の反応を見る取り組み
プリンタ向けのソフトウェア RIP の提供開始

同じ「印刷」でも、環境の話と RFID の話と DM の話が並ぶ。カテゴリを9つに割っているのは、この幅を1本の時系列に流し込まないためだと読めます。

削除依頼を受け付ける、ということ

方針の3行目に、指摘・削除依頼を受け付けると書かれていました。運用として当たり前に見えますが、データ構造の要件でもあります。

レコードを論理削除できること
どの掲載がどの出典に対応するかをあとから引けること
一覧・カテゴリ・ランキングなど、同じレコードを参照している場所すべてから消えること

集めるだけなら追記で済みますが、消せる前提で作るなら、参照の持ち方から変わります。

展示会は別のデータになる

同じサイトでも、展示会は性質の違うデータでした。ニュースが「時点」なのに対して、展示会は期間です。

掲載件数は終了分を含めて39件(2026年9月9日時点)。会期の並びを見ると、10月14〜16日に東京で3つ重なり(TOKYO PACK / ラベルフォーラムジャパン / プレミアム・インセンティブショー秋)、10月7〜9日にも2つ重なっていました。

さらに、数年に一度のものが混ざります。日本の総合印刷展 IGAS は2027年8月、ドイツの drupa は2028年5月、包装の interpack は2029年6月。同じテーブルに入れると、直近の一覧から数年先のものが消えたり、逆に居座ったりします。

名称の変更も起きます。ラベル関連の国際展は Labelexpo から LOUPE になり、Americas / Europe / Asia が別々の年に開かれる形でした。識別子を名前にすると、改名で切れます。

まとめ

本文を持たないと決めるだけで、保存するもの・検索できるもの・消せる範囲がすべて決まる
出典と原文 URL は本文の代わりではなく、掲載の根拠として持つ
削除依頼を受け付ける運用は、論理削除と参照の整理を前提にする
「時点」のニュースと「期間」の展示会は、同じ一覧に流し込まない

集める仕組みを作る前に、何を持たないかを先に決める。今回いちばん学びになったのはそこでした。

本ページはプロモーションが含まれています

出典表示コンポーネントを、義務の有無で出し分ける

Hajime — Sun, 30 Aug 2026 00:42:48 +0000

出典表示コンポーネントを、義務の有無で出し分ける

外部から取り込んだ素材を表示するとき、クレジット表記をどう出すか。地味ですが、条件によって出し方が変わるので分岐が要る部分です。

素材の入手方法そのものはここでは扱いません。手元にある素材に、どんな表示を添えるかという表示層の話です。

→ 出典と確認日を作品ページに出している名画の時間

表示の要件は3通りある

利用条件によって、表示側の要件が変わります。

条件	出典表示	実装上の扱い
出典表示が必須のもの	必須	省略できない。表示位置も検討対象
表示義務のないもの	任意	出すかどうかはこちらの方針
権利が切れている状態の表示	任意	同上。ただし「誰かが放棄した」ではない

3行目を2行目と同じ扱いにしてよいかは、少し考える余地があります。前者は提供元の意思表示ではなく、状態を述べているだけだからです。表示文面を「提供: ◯◯」とするか「所蔵: ◯◯」とするかで、含意が変わります。

分岐をコンポーネントに閉じ込める

呼び出し側で条件分岐を書くと、表示漏れが起きます。表示の判断はコンポーネント側に持たせるのが安全でした。

function Credit({ rights }) {
  // rights = { sourceName, sourceUrl, rightsText, checkedAt, requiresAttribution }
  const required = rights.requiresAttribution;

  return (
    <figcaption className="credit">
      <span>{rights.sourceName}</span>
      {/* 義務がなくても出す方針にしている。出すこと自体は害にならない */}
      <details>
        <summary>利用条件</summary>
        <p className="rights-raw">{rights.rightsText}</p>
        <time dateTime={rights.checkedAt}>確認: {fmt(rights.checkedAt)}</time>
      </details>
      {required && <span className="required-note">出典表示が必要な素材です</span>}
    </figcaption>
  );
}

ポイントは2つです。

義務がなくても出す方を既定にする。 表示して困ることはまずありません。逆に、義務があるのに出していない状態は事故です。既定を「出す」にしておくと、分岐を間違えたときの失敗が軽くなります。

原文を読める場所を用意する。 要約した一行だけを出すと、後から検証できません。折りたたみの中でよいので、提供元の文面をそのまま置いておきます。

確認日を表に出す

<time> で確認日を出しているのは、権利の状態が固定ではないためです。

提供元が方針を変えることも、特定の対象を公開から外すこともあります。表示している内容が「いつ時点のものか」が読み手に分かる状態にしておくと、情報の鮮度を判断してもらえます。

社内向けの管理画面だけでなく、公開ページにも出しておく価値があると思っています。表示があること自体が、記録を取っている証明になるからです。

クレジットを画像に焼き込まない

たまに見かける実装ですが、クレジットを画像そのものに合成するのは避けたほうがよいです。

条件が変わったときに差し替えられない
読み上げに乗らない
翻訳できない
表示のスタイルを後から変えられない

テキストとしてマークアップし、CSSで見た目を整えるほうが、結局のところ扱いやすくなります。

alt テキストに条件を書かない

alt は画像の内容を説明する属性です。ここに利用条件を書くと、スクリーンリーダーの読み上げが本題からずれます。

{/* 良くない */}
<img alt="風景画 CC0 ◯◯美術館" />

{/* 分ける */}
<img alt="夕暮れの河岸を描いた風景画" />
<figcaption>◯◯美術館</figcaption>

条件は figcaption や隣接要素に置き、alt は内容の説明に専念させます。

実例

名画の時間は、作品ページに提供元と権利表示を出したうえで、確認した日付まで持っている旨を公開しています。CC0 のように表示義務がないものでも出典を明記する方針だと明示されていて、上に書いた「既定を出す側に倒す」という考え方と一致します。

表示は義務を満たすためだけの機能ではなく、どこまで確かめたかを読み手に見せる機能でもあるのだと思います。

本ページはプロモーションが含まれています

配信先7社の入力制約をJSONにして、原稿を投稿前に検査する

Hajime — Sat, 29 Aug 2026 10:49:47 +0000

配信先7社の入力制約をJSONにして、原稿を投稿前に検査する

プレスリリースを複数の配信サービスに出していると、フォームを開いてから「文字数が足りない」「画像が1枚足りない」で止まります。7社それぞれ制約が違うので、毎回そこで時間を使っていました。

そこで制約をデータにして、投稿前に原稿を検査するようにしました。この記事はその作り方と、実際に7社のフォームを取得して集めた制約値です(2026年8月実測)。

制約をデータにする

サービスごとの制約を1つのJSONにまとめます。コードに条件を書き散らさず、データとして持つのが要点です。

{
  "prerele":  { "body_min": 250, "images": 1, "phone": false, "address": false },
  "prfree":   { "service_max": 10, "title_max": 30, "body_min": 300, "html": false,
                "images": 1, "image_min_width": 600, "image_max_mb": 2 },
  "pressnow": { "sections_max": 5, "section_max": 2000, "images": 1, "phone": true,
                "extra_fields": ["subtitle", "lead", "legal_name"] },
  "directpress": { "title_max": 50, "lead_max": 300, "body_max": 3000,
                   "public_contact_max": 500, "phone": true, "https": false },
  "tsunagugu": { "title_max": 40, "lead_min": 50, "lead_max": 200, "body_min": 300,
                 "headings_max": 3, "heading_max": 40, "images": 2, "phone": true }
}

body_min と body_max が両方あるのがこの領域の面倒なところで、DirectPress! だけ上限、他は下限です。

検査する

原稿から本文・タイトル・画像枚数を取り出して、各サービスの条件に当てはめます。

# 例: 本文の文字数を数える(HTMLタグを除いた実文字数)
body_len=$(sed 's/<[^>]*>//g' draft.html | tr -d '[:space:]' | wc -m)

jq -r --argjson n "$body_len" '
  to_entries[]
  | select((.value.body_min // 0) > $n or (.value.body_max // 1e9) < $n)
  | "\(.key): 本文 \($n)字 は範囲外 (min=\(.value.body_min // "-") max=\(.value.body_max // "-"))"
' limits.json

これを投稿前に流すだけで、フォームで止まることがほぼ無くなりました。

集めた制約値

以下は各社のフォームを実際に取得して確認した値です。

Zero Press

登録料・配信料・掲載料がすべて0円で、大手メディア20社への告知もこの範囲に入ります。掲載されたリリースは、タレントや芸人のSNSで拡散されることがあります。

この記事の趣旨で言うと、検査すべき制約が少ないのが特徴でした。以降で見ていくとおり、他社は文字数の上下限や必須項目に加えて「掲載後にやること」まで条件に含みます。そこは原稿の検査では拾えません。

→ 制約の少ない無料プレスリリース配信ならZeroPress

ぷれりり

body_min: 250 / 画像1枚 / 住所・電話ともに不要。会員登録も不要です。審査は最短5分・通過率95%と案内されており、投稿した当日に掲載されました。

データに入れておくべきなのは修正不可というフラグです。公開後の修正・削除ができないため、検査を通す優先度が他社より高くなります。掲載記事の本文リンク5本は rel 属性なしで dofollow でした。

PR FREE

制約が最も細かい部類です。サービス名10字、タイトル30字、本文300字以上、HTMLは使用不可、画像は横600px以上・2MBまでを1枚。

html: false は検査項目として重要で、他社向けに作ったHTML入りの原稿をそのまま渡すと崩れます。プレーンテキスト版を別に生成する分岐が要ります。

投稿数に上限はなく当日に掲載されましたが、サイトURL欄は rel="nofollow external noopener ugc"、本文中のURLはリンク化されずテキスト表示でした。

FREE PRESS RELEASE

文字数より値の形式が問われます。電話番号はハイフン必須、連絡先はURL形式でメールアドレス不可、担当者名は実名でニックネーム・部署名は不可。

つまり検査は正規表現の仕事になります。

grep -qE '^0[0-9]{1,4}-[0-9]{1,4}-[0-9]{3,4}$' <<<"$phone" || echo 'phone: ハイフン必須'

入口にGoogleアカウントでのログインが必須である点も、運用側の前提として持っておく必要があります。審査は最短1時間〜7営業日、リンクは dofollow でした。

PRESSNOW

他社に無い項目が3つあります。サブタイトル、リード文、正式社名。原稿のデータ構造にこの3つが無いと、ここだけ手作業になります。

本文は見出し+本文のセクションを最大5つ、各2,000字まで。検査はセクション単位で回す必要があります。

そして原稿の検査では拾えない条件があります。掲載後3営業日以内に自社サイトへPRESSNOWの紹介ページを設置し、URLを編集部へ返信すること。SNS・無料ブログ・短縮URLでは要件を満たしません。審査は1時間から3営業日。追加URLは最大5本置けるものの実測では原則 nofollow で、公開後の修正・削除も原則できません。

DirectPress!

唯一 body_max を持つサービスです。本文3,000字以内、タイトル50字以内、概要リード文300字以内。他社の下限に合わせて長く書いた原稿は、ここで削ることになります。

public_contact_max: 500 の公開連絡先はそのまま公開され、記載が不明確だと掲載されません。URL欄は任意です。掲載は1日2〜8件、掲載日時は選べません。

技術的には https: false をデータに持たせておくのが実務的でした。httpのみでhttps非対応なので、URLを組み立てる処理でスキームを決め打ちにしていると落ちます。

ツナググ

images: 2 が効きます。画像2枚が必須なのは7社でここだけなので、1枚しか用意していないと止まります。

冒頭文が lead_min: 50 / lead_max: 200 と上下限の両方を持つのも特徴です。タイトル40字以内、本文300字以上、見出しは40字×最大3。

運用条件も重く、2026年2月17日適用の利用条件で、配信後に記事URLを自社サイトやSNSで告知し、告知先を指定フォームへ報告する義務があります。報告がない場合は1記事あたり10,000円+税と明記されています。掲載後の修正が1,000円、掲載6ヶ月未満での削除が1,000円。無料で出せるのは月5配信までで、6本目からは1万円。住所と電話番号は公開されます。リンクは rel="noopener noreferrer" のみが付き、dofollow でした。掲載までは数日かかっています。

まとめ

制約をデータにして分かったことです。

下限と上限が混在する。 DirectPress! だけ本文が上限で、他は下限
枚数が違う。 ツナググだけ画像2枚
形式の検査が要る項目がある。 電話番号のハイフン、連絡先のURL形式
他社に無い項目がある。 PRESSNOW のサブタイトル・リード文・正式社名
原稿の検査では拾えない条件がある。 掲載後の作業義務は別に管理する

最後の1点だけはデータに入れても検査になりません。掲載後に何かを要求するサービスかどうかは、採用を決める段階で分けておくのが結局いちばん早いです。

本ページはプロモーションが含まれています