WordPressでNEWS配信システムを作る初心者向け実践講座｜第2回：NEWS候補1件に持たせる項目を設計する

第1回では、TECN NEWS候補管理 V1を作る目的と全体構想を整理しました。

TECN NEWS候補管理 V1は、WordPressで公開した記事を、いきなりNEWSとして表示するのではなく、いったん「NEWS候補」として整理し、担当者が確認・修正・承認できるようにするための小さな業務改善システムです。

この仕組みは、WordPressを単なるブログ投稿ツールとして使うだけではなく、固定ページ、ショートコード、PHP、カスタム投稿タイプ、カスタムフィールドなどを組み合わせて、実務に役立つミニシステムとして活用していく取り組みでもあります。

第2回では、その中でも特に大切な「NEWS候補1件に、どのような情報を持たせるか」を設計していきます。

システム作りというと、すぐに画面を作ったり、コードを書いたりしたくなるかもしれません。しかし、実際にはその前に「何を管理するのか」を決めておくことがとても重要です。

たとえば、NEWS候補として元記事タイトルだけを保存すればよいのか。元記事URLも必要なのか。カテゴリは持たせるのか。NEWSに表示する文面は別に作るのか。X投稿文案も管理するのか。表示先NEWSや承認ステータスはどうするのか。

こうした項目を先に整理しておかないと、後から「この情報も必要だった」「この状態を管理できない」「表示先を選べない」といった問題が出てきます。

そこで今回は、TECN NEWS候補管理 V1で扱う「NEWS候補1件」を、どのような情報の集まりとして管理するのかを考えます。

今回の達成目標は、コードを書くことではありません。WordPressの中に保存先を作ることでもありません。

まずは、NEWS候補1件に持たせる項目を整理し、V1で使う項目と、将来的に追加すればよい項目を分けることです。

ここが決まると、次回以降に作るカスタム投稿タイプやカスタムフィールド、固定ページ、ショートコードの設計がとても進めやすくなります。

小さなシステムでも、最初に項目を整理しておくことで、あとから作り直す手間を減らせます。

この第2回では、初心者の方にも分かりやすいように、NEWS候補1件を「どんな情報を入れる箱にするのか」という視点で、ひとつずつ整理していきます。

完成イメージ

TECN NEWS 表示サンプル

公開した記事をNEWS候補として整理し、担当者が確認したうえで、適切なNEWS枠に表示するイメージです。

在庫管理 / DX NEWS 2026/07/01

在庫管理システムを無料で試せるアピスmini活用記事を公開しました

WordPressとPHPを活用し、小さな業務改善システムを作る考え方を紹介しています。

LDAC / Bluetooth NEWS 2026/07/01

LDAC対応イヤホンの記事をNEWS候補として整理する仕組みを検討中

記事公開後に、LDAC / Bluetooth NEWSへ表示するかどうかを担当者が確認できるようにします。

どこの国NEWS 2026/07/01

注目ブランドの記事を「どこの国NEWS」として表示する候補に追加

ブランド・メーカー系の記事を、読者の関心に合わせてNEWS枠へ振り分けるイメージです。

下記はこれから作る　TECN　NEWSのデザインです。　これを自動挿入できるところまで順番に計画、仕様、設計、実装、利用、管理　まですべてを皆さんと共有します。　アピスmini ワードプレス版ですね。

H2-1 第2回で行うこと

第1回では、TECN NEWS候補管理 V1を作る目的と、全体構想を整理しました。

このシリーズで作っていくのは、単なるNEWS表示パーツではありません。WordPressで公開した記事を、いったんNEWS候補として整理し、担当者が確認・修正・承認したうえで、TECN NEWS、ダイソーNEWS、どこの国NEWS、LDAC / Bluetooth NEWS、在庫管理 / DX NEWSなど、適切なNEWS枠へ表示できるようにするための小さな業務改善システムです。

上に掲載した表示例は、その完成イメージです。

読者の方には、まず「最終的にこのようなNEWS表示を作っていくのだな」とイメージしていただければ十分です。

ただし、このような表示を作るためには、いきなり見た目のHTMLやCSSを作るだけでは不十分です。

NEWSとして表示する記事タイトルはどこから持ってくるのか。NEWS表示文は元記事のタイトルをそのまま使うのか、それとも担当者が修正できるようにするのか。どのNEWS枠に表示するのか。表示する、表示しないをどう判断するのか。X投稿文案も一緒に管理するのか。

こうした情報を先に整理しておかないと、あとから作り直しが多くなります。

そこで第2回では、TECN NEWS候補管理 V1で扱う「NEWS候補1件」に、どのような項目を持たせるかを設計します。

今回のポイントは、まだコードを書かないことです。

WordPressのカスタム投稿タイプを作るのも、ショートコードで一覧表示するのも、固定ページに管理画面を作るのも、もう少し後の工程です。

今回は、その前段階として、NEWS候補1件をどのような情報の集まりとして扱うかを決めます。

たとえば、最低限必要になりそうな項目としては、元記事タイトル、元記事URL、カテゴリ、NEWS表示文、表示先NEWS、表示フラグ、承認ステータス、X投稿文案、X投稿ステータス、メモなどがあります。

もちろん、最初からすべてを完璧に作る必要はありません。

V1では、毎日のNEWS候補確認が楽になることを優先します。便利そうな項目であっても、最初から入れると複雑になりすぎるものは、V2以降に回しても構いません。

小さく作って、実際に使いながら改善していく。

これが、TECN NEWS候補管理 V1の基本方針です。

第2回の達成目標は、NEWS候補1件に持たせる項目を整理し、V1で使う項目と、将来的に追加すればよい項目を分けることです。

ここが決まれば、次回以降に、WordPressの中にNEWS候補専用の保存先を作る準備ができます。

つまり第2回は、完成形のNEWS表示を実現するための、土台となる設計回です。

H2-2 NEWS候補1件とは何か

まず最初に、「NEWS候補1件」とは何かを整理しておきます。

TECN NEWS候補管理 V1で扱うNEWS候補1件とは、単に「記事タイトルを1つ保存する」という意味ではありません。

公開した記事を、NEWSとして表示するかどうか判断するための、1件分の管理データです。

たとえば、TECNサイトで新しい記事を公開したとします。

その記事を見たときに、担当者は次のような判断を行います。

この新着記事をTECN NEWSに表示するのか。

ダイソー関連の記事なので、ダイソーNEWSに表示するのか。

メーカーやブランドの記事なので、どこの国NEWSに表示するのか。

イヤホンや音響関連の記事なので、LDAC / Bluetooth NEWSに表示するのか。

在庫管理や業務改善の記事なので、在庫管理 / DX NEWSに表示するのか。

あるいは、今回はNEWSには表示しないのか。

このように、記事を公開した後には、「どこに表示するか」「どの文面で表示するか」「表示してよいか」といった判断が必要になります。

NEWS候補1件とは、この判断を行うために必要な情報をまとめたものです。

具体的には、元記事タイトル、元記事URL、カテゴリ、NEWS表示文、表示先NEWS、表示フラグ、承認ステータス、X投稿文案、メモなどをまとめて管理します。

つまり、NEWS候補1件は、記事そのものではありません。

記事をNEWSとして活用するための、運用管理用データです。

ここを分けて考えることが重要です。

元記事は、通常のWordPress記事として存在しています。

一方で、NEWS候補は、その元記事をどのNEWS枠に出すか、どんな文面で紹介するか、担当者が確認済みかどうかを管理するための別データです。

たとえば、元記事タイトルがそのままNEWSに向いているとは限りません。

記事タイトルはSEOを意識して少し長くなっていることがあります。

しかしNEWS枠では、もっと短く、読者がクリックしやすい文面にした方がよい場合があります。

そのため、元記事タイトルとは別に、NEWS表示文を持たせます。

また、記事のカテゴリだけで自動的に表示先NEWSを決めると、少しズレることがあります。

たとえば、在庫管理の記事であっても、TECN全体のおすすめに出したい場合があります。

逆に、カテゴリ上は該当していても、NEWSとしては出さない方がよい記事もあります。

そのため、表示先NEWSや表示フラグも、NEWS候補側に持たせます。

さらに、担当者が確認したかどうかも重要です。

NEWS候補が自動的に作成されたとしても、まだ人が確認していない状態で公開表示してしまうと、文面の違和感や表示先のミスが起きる可能性があります。

そこで、未確認、修正中、承認済み、非表示といったステータスを持たせます。

このように考えると、NEWS候補1件は、単なるリンク一覧ではなく、記事公開後の活用を管理するための小さな作業単位だと分かります。

TECN NEWS候補管理 V1では、このNEWS候補1件をきちんと管理できるようにすることを目指します。

最初から高度な自動化を行う必要はありません。

まずは、担当者がNEWS候補を見て、内容を確認し、必要な文面を修正し、どのNEWS枠に表示するかを判断できる状態を作ります。

そのための出発点が、「NEWS候補1件とは何か」を正しく定義することです。

H2-3 なぜ項目設計を先に行うのか

TECN NEWS候補管理 V1では、いきなり画面やコードを作り始めるのではなく、まずNEWS候補1件に持たせる項目を設計します。

これは、小さな仕組みを作る場合でも、とても大切な考え方です。

WordPressのカスタマイズでは、先に見た目を作りたくなることがあります。

固定ページを作る。

ショートコードを貼る。

一覧を表示する。

ボタンを配置する。

CSSで見た目を整える。

こうした作業は、実際に動いている感じが出るので楽しい部分です。

しかし、その前に「何を管理するのか」が決まっていないと、あとから作り直しが増えてしまいます。

たとえば、最初は元記事タイトルとURLだけを表示する簡単な一覧を作ったとします。

しかし運用を始めると、すぐに次のような要望が出てくる可能性があります。

NEWS表示文を元記事タイトルとは別に修正したい。

どのNEWS枠に出すかを選べるようにしたい。

表示する記事と表示しない記事を分けたい。

担当者が確認済みかどうかを管理したい。

X投稿文案も一緒に保存したい。

非表示にした理由をメモとして残したい。

こうした項目を後から追加することはできます。

しかし、最初に何も考えずに作ってしまうと、データの持ち方や画面の作り方を途中で見直す必要が出てきます。

たとえば、表示先NEWSを保存する項目がなければ、TECN NEWS、ダイソーNEWS、どこの国NEWS、LDAC / Bluetooth NEWS、在庫管理 / DX NEWSといった出し分けができません。

承認ステータスがなければ、担当者が確認したNEWS候補なのか、まだ未確認なのかが分かりません。

表示フラグがなければ、NEWS候補としては残しておきたいが、実際のNEWSには表示しない、という運用が難しくなります。

X投稿文案を保存する項目がなければ、せっかくNEWS候補を確認しても、SNS展開の作業を別管理にしなければなりません。

このように、項目設計を後回しにすると、運用上必要な情報が抜けやすくなります。

だからこそ、第2回ではコードを書く前に、NEWS候補1件にどのような項目を持たせるかを整理します。

項目設計というと、少し難しく聞こえるかもしれません。

しかし、考え方はシンプルです。

担当者がNEWS候補を確認するときに、何が見えていれば判断しやすいか。

担当者がNEWS表示文を修正するときに、どの項目を編集できればよいか。

NEWSとして表示するときに、どの情報が必要になるか。

将来的に自動化するときに、どの情報を残しておくと便利か。

このように、実際の作業を想像しながら必要な項目を洗い出していきます。

ただし、最初からすべてを詰め込みすぎる必要はありません。

V1では、毎日のNEWS候補確認が楽になることを優先します。

便利そうな項目であっても、初期段階で使わないものは、V2以降に回して構いません。

重要なのは、V1で使う項目と、将来的に追加したい項目を分けて考えることです。

この整理をしておくことで、次回以降の作業がかなり進めやすくなります。

カスタム投稿タイプを作るときも、カスタムフィールドを設定するときも、固定ページに表示する項目を決めるときも、今回の項目設計が土台になります。

つまり、項目設計は地味な作業ですが、TECN NEWS候補管理 V1を使いやすい仕組みにするための重要な準備です。

小さなシステムでも、最初に「何を管理するか」を決めておく。

これが、WordPressを実務に役立つミニシステムとして活用するための第一歩になります。

H2-4 元記事に関する項目を決める

まず最初に整理するのは、NEWS候補の元になる記事情報です。

TECN NEWS候補管理 V1では、WordPressで公開した記事を、いったんNEWS候補として管理します。

そのため、NEWS候補1件には、元になった記事がどれなのかを分かるようにしておく必要があります。

たとえば、NEWS候補一覧を見たときに、担当者が、

どの記事のNEWS候補なのか。

元記事のタイトルは何か。

元記事はどのURLにあるのか。

どのカテゴリの記事なのか。

といったことを確認できなければ、NEWSとして表示するかどうか判断しにくくなります。

そこで、まずは元記事に関する項目を整理します。

候補になる項目は、次のようなものです。

・元記事ID
・元記事タイトル
・元記事URL
・公開日
・投稿者
・カテゴリ

この中で、V1の初期段階で特に重要なのは、元記事タイトル、元記事URL、カテゴリです。

元記事タイトルは、担当者が「どの記事なのか」をすぐに判断するために必要です。

元記事URLは、実際に記事内容を確認するために必要です。NEWS候補一覧上でタイトルだけを見ても、内容までは分からないことがあります。担当者が元記事を開いて確認できるように、URLは必ず持たせておきたい項目です。

カテゴリも重要です。

TECNサイトでは、記事の内容によって、TECN NEWS、ダイソーNEWS、どこの国NEWS、LDAC / Bluetooth NEWS、在庫管理 / DX NEWSなど、表示先NEWSが変わります。

そのため、元記事がどのカテゴリに属しているかは、表示先NEWSを判断するための大切な材料になります。

一方で、元記事ID、公開日、投稿者は、V1の最初から必須にしなくても運用は可能です。

もちろん、将来的には元記事IDを持たせておくと便利です。

元記事IDがあれば、WordPress内で元記事とNEWS候補を正確に紐づけることができます。将来的に、新しい記事が公開されたときに自動でNEWS候補を作る場合にも、元記事IDは重要になります。

公開日も、NEWSとして表示する優先順位を決めるときに役立ちます。

たとえば、新しい記事を優先してNEWS候補一覧の上に表示したい場合、公開日を持っていると並び替えがしやすくなります。

投稿者も、複数人で記事を作成する運用になった場合には便利です。どの担当者の記事なのか、誰に確認すればよいのかを判断しやすくなります。

ただし、V1では最初からすべてを完璧に管理しようとしすぎない方がよいです。

今回の目的は、まずNEWS候補を一覧で確認し、必要な文面を修正し、どのNEWS枠に出すかを判断できるようにすることです。

そのため、V1初期の元記事情報としては、まず次の3つを優先します。

・元記事タイトル
・元記事URL
・カテゴリ

この3つがあれば、担当者はNEWS候補一覧を見ながら、どの記事をどのNEWS枠に出すべきかを判断できます。

そして将来的な拡張項目として、次の項目を検討します。

・元記事ID
・公開日
・投稿者

このように、V1で使う項目と、将来的に追加したい項目を分けて考えることが大切です。

小さく始めることで、実装も運用も分かりやすくなります。

まずは必要最低限の項目で動かし、実際に使いながら「やはり公開日も必要だ」「元記事IDで自動連携したい」となった段階で追加していけばよいのです。

TECN NEWS候補管理 V1では、このように段階的に項目を整理しながら、無理なく使える仕組みを作っていきます。

H2-5 NEWS表示に関する項目を決める

次に整理するのは、NEWSとして実際に表示するための項目です。

元記事に関する項目は、「どの記事をもとにしたNEWS候補なのか」を確認するための情報でした。

一方で、NEWS表示に関する項目は、「その記事をNEWSとしてどのように見せるか」を決めるための情報です。

ここは、TECN NEWS候補管理 V1の中でもかなり重要な部分です。

なぜなら、元記事タイトルをそのままNEWSに出せばよいとは限らないからです。

ブログ記事のタイトルは、検索されることを意識して長めに作ることがあります。

たとえば、SEOを意識した記事タイトルでは、検索キーワードを複数入れたり、対象読者が分かるように説明を加えたりします。

しかし、NEWS枠に表示する文面は、もう少し短く、分かりやすく、読者がクリックしやすい形にした方がよい場合があります。

そのため、TECN NEWS候補管理 V1では、元記事タイトルとは別に、NEWS表示文を持たせる方針にします。

NEWS表示文とは、実際にNEWS枠に表示するための短い紹介文です。

担当者が元記事を確認し、必要に応じて文面を修正できるようにします。

次に重要なのが、表示先NEWSです。

TECNサイトでは、記事の内容によって表示先が変わります。

たとえば、在庫管理や業務改善に関する記事であれば、在庫管理 / DX NEWSに表示するのが自然です。

メーカーやブランドの国籍に関する記事であれば、どこの国NEWSに表示するのが自然です。

イヤホンやBluetooth関連の記事であれば、LDAC / Bluetooth NEWSに表示するのが分かりやすいでしょう。

このように、記事の内容に合わせて、どのNEWS枠に表示するかを選べるようにする必要があります。

もし表示先NEWSという項目がなければ、すべての記事を同じNEWS枠に流すしかなくなります。

それでは、読者にとって関係の薄いNEWSが表示されやすくなります。

TECN NEWS候補管理 V1の目的は、記事をただ新着順に並べることではありません。

公開した記事を、読者の関心に合ったNEWS枠へ振り分けることです。

そのため、表示先NEWSは必須項目として考えます。

次に、表示フラグも必要です。

表示フラグとは、そのNEWS候補を実際に表示するかどうかを決める項目です。

たとえば、NEWS候補としては作成されたものの、今回はNEWSには出さない記事もあります。

あるいは、文面の確認が終わるまでは表示しない、という運用もあります。

このようなときに、表示する / 表示しないを切り替える項目が必要になります。

表示フラグを持たせておけば、NEWS候補としてデータは残しつつ、実際のNEWS表示には出さないという管理ができます。

さらに、将来的には表示開始日や表示終了日もあると便利です。

表示開始日があれば、指定した日からNEWSを表示できます。

表示終了日があれば、一定期間が過ぎたNEWSを自動的に非表示にできます。

ただし、V1の初期段階では、表示開始日と表示終了日まで入れると少し複雑になります。

まずは担当者が手動で表示する / 表示しないを切り替える運用で十分です。

そのため、V1で優先するNEWS表示項目は、次の3つです。

・NEWS表示文
・表示先NEWS
・表示フラグ

この3つがあれば、NEWS候補を実際のNEWS表示につなげるための基本は作れます。

NEWS表示文で、読者に見せる文面を管理します。

表示先NEWSで、どのNEWS枠に出すかを管理します。

表示フラグで、表示するかどうかを管理します。

そして、将来的な拡張項目として、次の2つを検討します。

・表示開始日
・表示終了日

このように、最初からすべてを自動化するのではなく、まずは担当者が確認しながら運用できる形を作ります。

小さく始めることで、操作も分かりやすくなり、実際の業務に合わせて改善しやすくなります。

TECN NEWS候補管理 V1では、NEWS表示に関する項目をこのように整理し、次回以降のカスタムフィールド設計につなげていきます。

H2-6 表示先NEWSの種類を決める

次に、表示先NEWSの種類を決めます。

TECN NEWS候補管理 V1では、公開した記事をすべて同じ場所に表示するのではなく、記事の内容に合わせて、適切なNEWS枠へ振り分けられるようにします。

ここが、この仕組みの大きなポイントです。

通常のブログでは、新しく公開した記事が新着記事一覧に並びます。

もちろん、それだけでも基本的な新着表示としては機能します。

しかし、TECNサイトのように複数のテーマを扱っている場合、すべての記事を同じNEWS枠に並べてしまうと、読者の関心と少しずれることがあります。

たとえば、在庫管理の記事を読んでいる人に、ダイソー商品のNEWSばかり表示されても、あまり自然ではありません。

反対に、ダイソー関連記事を読んでいる人に、業務改善システムの記事ばかり表示されても、興味を持ってもらえないかもしれません。

また、イヤホンやBluetoothの記事を読んでいる人には、LDAC / Bluetooth NEWSを表示した方が自然です。

メーカーやブランドの国籍に関する記事であれば、どこの国NEWSとして表示した方が、読者の関心に合いやすくなります。

このように、記事の内容に合わせてNEWS枠を出し分けることで、読者にとって関連性の高い情報を届けやすくなります。

V1では、まず次のような表示先NEWSを想定します。

・TECN NEWS
・アピスminiNEWS
・ダイソーNEWS
・どこの国NEWS
・LDAC / Bluetooth NEWS
・在庫管理 / DX NEWS
・TECNおすすめ
・非表示

TECN NEWSは、サイト全体として読者に知らせたい記事を表示する枠です。

特定カテゴリだけでなく、TECN全体として重要な記事や、アピスmini、業務改善、WordPress活用など、横断的に見せたい情報を出す場所として使います。

ダイソーNEWSは、ダイソー関連の記事を表示する枠です。

ダイソー商品、便利グッズ、比較記事、実際に使ってみた記事など、ダイソーに関心がある読者へ向けて表示します。

どこの国NEWSは、メーカーやブランドの国籍・企業情報・製品背景に関する記事を表示する枠です。

「このメーカーはどこの国のブランドなのか」「この製品はどこの会社が作っているのか」といったテーマの記事に向いています。

LDAC / Bluetooth NEWSは、イヤホン、ヘッドホン、Bluetooth、コーデック、音質関連の記事を表示する枠です。

LDACという表記は、似たようなスペルと間違えやすいので、記事本文や表示ラベルでは正式に「LDAC」として統一します。

在庫管理 / DX NEWSは、在庫管理、業務改善、アピスmini、WordPressを使ったミニシステム、業務効率化に関する記事を表示する枠です。

今回のTECN NEWS候補管理 V1自体も、この在庫管理 / DX NEWSやTECN NEWSに表示する候補になり得ます。

TECNおすすめは、カテゴリに関係なく、読者に見てほしい記事を横断的に出す枠です。

たとえば、無料ダウンロード、アピスmini、業務改善ノウハウ、シリーズ記事のまとめなど、複数カテゴリの読者に案内したい記事に使います。

そして、非表示も重要です。

NEWS候補として作成された記事であっても、必ずNEWSとして表示するとは限りません。

記事としては公開するが、NEWS枠には出さない方がよい場合もあります。

そのため、表示先NEWSの選択肢には、あえて「非表示」を用意しておきます。

これにより、NEWS候補としてデータは残しつつ、実際のNEWSには表示しないという運用ができます。

このように表示先NEWSを分けることで、TECNサイト内の記事活用がかなりしやすくなります。

記事を書いて終わりではなく、公開後にどこへ案内するか、どの読者に見せるかを考えながら活用できます。

V1では、まず担当者が手動で表示先NEWSを選ぶ形にします。

最初からシステムが完全自動で判断する必要はありません。

カテゴリや記事内容を見ながら、担当者が適切なNEWS枠を選べることが重要です。

将来的には、カテゴリやタグを見て、システムが表示先NEWSを仮選択することもできます。

たとえば、ダイソーカテゴリの記事であれば、初期値としてダイソーNEWSを選ぶ。

LDACやBluetooth関連の記事であれば、LDAC / Bluetooth NEWSを候補にする。

在庫管理やDX関連の記事であれば、在庫管理 / DX NEWSを候補にする。

このような自動おすすめは、V2以降で考えれば十分です。

V1ではまず、表示先NEWSを手動で選び、適切なNEWS枠へ振り分けられる状態を目指します。

この表示先NEWSの設計ができると、TECN NEWS候補管理 V1は、単なる新着一覧ではなく、記事公開後の活用を支える仕組みになります。

H2-7 承認・確認に関する項目を決める

次に、承認・確認に関する項目を決めます。

TECN NEWS候補管理 V1では、NEWS候補が作成されたからといって、すぐにNEWSとして表示するわけではありません。

いったん候補として保存し、担当者が内容を確認してから表示する流れにします。

この考え方は、とても重要です。

なぜなら、記事が公開された直後の状態では、まだNEWS表示に向いているかどうか分からないからです。

元記事のタイトルがNEWS表示には長すぎる場合があります。

表示先NEWSが適切かどうか、担当者が確認した方がよい場合もあります。

X投稿文案が少し硬い、あるいは短くした方がよい場合もあります。

また、記事としては公開していても、NEWS枠には出さない方がよいものもあります。

そのため、NEWS候補には、担当者が確認したかどうか、表示してよい状態かどうかを管理する項目が必要になります。

候補になる項目は、次のようなものです。

・承認ステータス
・確認日
・確認者
・メモ

この中で、V1で特に重要なのは、承認ステータスとメモです。

承認ステータスは、そのNEWS候補が今どの状態にあるかを示す項目です。

たとえば、V1では次のようなステータスを想定します。

・未確認
・修正中
・承認済み
・非表示

未確認は、まだ担当者が内容を見ていない状態です。

新しく作成されたNEWS候補は、まず未確認として扱います。

担当者は未確認の候補を見て、NEWSに出すべきか、どのNEWS枠に出すか、文面を直す必要があるかを判断します。

修正中は、文面や表示先を調整している状態です。

たとえば、NEWS表示文を少し短くしたい、X投稿文案を直したい、表示先NEWSを確認中、という場合に使います。

承認済みは、担当者が内容を確認し、NEWSとして表示してよいと判断した状態です。

実際のNEWS表示では、基本的にこの承認済みの候補だけを表示対象にします。

これにより、未確認の候補が勝手に読者向けに表示されることを防げます。

非表示は、NEWS候補としては残すが、NEWSには表示しない状態です。

たとえば、記事内容としては問題ないものの、NEWSとして告知する必要はない場合があります。

また、特定カテゴリのNEWS枠に出すには少し弱い記事もあります。

そのような場合に、非表示として管理します。

このように承認ステータスを持たせることで、担当者はNEWS候補一覧を見たときに、今どの候補を確認すべきか分かりやすくなります。

特に記事数が増えてくると、ステータス管理はかなり役立ちます。

未確認だけを表示する。

修正中だけを確認する。

承認済みだけをNEWSに出す。

非表示の候補は表示対象から外す。

こうした運用ができるようになります。

次に、メモも重要です。

メモは、担当者が判断理由や注意点を書いておくための項目です。

たとえば、

・タイトルを少し短くした方がよい
・ダイソーNEWSではなくTECNおすすめに出す
・X投稿は後日行う
・今回はNEWS非表示
・関連カテゴリへの内部リンク候補にする

といったメモを残せます。

小さな項目ですが、実務ではとても便利です。

特に複数人で運用する場合、なぜその判断をしたのかが分からなくなりがちです。

メモを残しておけば、あとから見返したときに判断の理由が分かります。

確認日や確認者も、将来的には便利な項目です。

確認日があれば、いつ担当者が確認したのか分かります。

確認者があれば、誰が承認したのか分かります。

ただし、V1の最初から確認日や確認者まで必須にすると、少し複雑になります。

まずは、承認ステータスとメモがあれば十分です。

V1では、次の2つを優先項目とします。

・承認ステータス
・メモ

そして、将来的な拡張項目として、次の2つを検討します。

・確認日
・確認者

このように整理しておくと、最初はシンプルに運用しながら、必要になった段階で管理レベルを上げることができます。

TECN NEWS候補管理 V1では、まず担当者が確認しやすいことを優先します。

最初から完璧な承認ワークフローを作る必要はありません。

重要なのは、未確認の候補がそのまま読者向けに表示されないこと。

そして、担当者が確認済みかどうかを分かりやすく管理できることです。

この承認・確認の項目を持たせることで、TECN NEWS候補管理 V1は、単なる表示一覧ではなく、安心して運用できるNEWS管理の仕組みに近づきます。

H2-8 X投稿に関する項目を決める

次に、X投稿に関する項目を決めます。

TECN NEWS候補管理 V1では、XへのAPI自動投稿は行いません。

理由は、X APIは料金や仕様変更の影響を受けやすく、最初から自動投稿まで組み込むと、仕組みが複雑になりやすいからです。

そのため、V1では安全でシンプルな運用を優先します。

具体的には、NEWS候補ごとにX投稿文案を作り、担当者が内容を確認してから、Xの公式画面で手動投稿または予約投稿する形にします。

これなら、API費用をかけずに、X投稿の作業を効率化できます。

ここで重要なのは、X投稿を完全自動化しなくても、投稿文案をあらかじめ用意しておくだけで、かなり作業が楽になるという点です。

記事を公開したあと、毎回ゼロからX投稿文を考えるのは意外と手間がかかります。

しかし、NEWS候補管理画面にX投稿文案が表示されていれば、担当者はそれを確認し、必要に応じて少し直し、コピーして投稿できます。

この流れにするだけでも、記事公開後のSNS展開がかなり進めやすくなります。

X投稿に関する候補項目としては、次のようなものが考えられます。

・X投稿文案
・X投稿ステータス
・X投稿予定日
・X投稿済み日
・X投稿メモ

この中で、V1で優先する項目は、X投稿文案とX投稿ステータスです。

X投稿文案は、Xに投稿するための文章です。

たとえば、新しく公開した記事を紹介する短い文面や、読者にクリックしてもらうための案内文を入れます。

NEWS表示文とX投稿文案は似ていますが、完全に同じにしなくても構いません。

NEWS表示文は、サイト内のNEWS枠に表示するための文面です。

一方で、X投稿文案は、SNS上で読者の目に留まりやすいように、少し話しかけるような文面にしてもよいです。

たとえば、NEWS表示文では、

在庫管理システムを無料で試せるアピスmini活用記事を公開しました

と表示し、X投稿文案では、

在庫管理をExcelだけで続けるのが大変になってきた方向けに、無料で試せるアピスmini活用記事を公開しました。小さく始める業務改善のヒントとしてご覧ください。

のように、少し説明を加えることもできます。

次に、X投稿ステータスです。

X投稿ステータスは、そのNEWS候補に対して、X投稿を行ったかどうかを管理するための項目です。

V1では、まず次のようなシンプルな状態で十分です。

・未投稿
・投稿済み
・投稿しない

未投稿は、まだX投稿していない状態です。

投稿済みは、担当者がXに投稿または予約投稿した状態です。

投稿しないは、NEWS候補としては管理するが、Xには投稿しない状態です。

このステータスがあると、あとから「このNEWSはXに投稿したのか」「まだ投稿していないのか」が分かりやすくなります。

X投稿予定日やX投稿済み日は、将来的には便利な項目です。

たとえば、投稿予定日があれば、いつ投稿する予定なのかを管理できます。

投稿済み日があれば、いつ投稿したのかを記録できます。

ただし、V1の初期段階では、そこまで細かく管理しなくても構いません。

まずは、X投稿文案を作り、投稿済みかどうかを管理できれば十分です。

X投稿メモも、複数人で運用する場合には便利です。

たとえば、

・午前中に投稿予定
・この記事は週末に投稿する
・今回はX投稿しない
・文面を短くする
・画像付き投稿にする

といったメモを残すことができます。

ただし、これもV1では必須にしすぎなくてよいです。

メモ項目はNEWS候補全体のメモとして持たせておけば、最初はそこに書けば十分です。

したがって、V1で使うX投稿関連の項目は、次の2つに絞ります。

・X投稿文案
・X投稿ステータス

将来的な拡張項目として、次の項目を検討します。

・X投稿予定日
・X投稿済み日
・X投稿メモ

このように整理しておくことで、V1ではシンプルに運用しながら、将来的にSNS運用を強化したくなったときに拡張できます。

TECN NEWS候補管理 V1では、X投稿を完全自動化することよりも、まずは担当者が投稿しやすい状態を作ることを優先します。

自動化しすぎず、人が確認できる余地を残す。

これが、初期段階では安全で使いやすい運用です。

H2-9 V1で使う項目と後回しにする項目

ここまで、NEWS候補1件に持たせる項目を、いくつかの種類に分けて整理してきました。

元記事に関する項目。

NEWS表示に関する項目。

表示先NEWSに関する項目。

承認・確認に関する項目。

X投稿に関する項目。

ここで一度、V1で使う項目と、後回しにする項目を整理しておきます。

最初からすべての項目を作ろうとすると、仕組みが複雑になります。

項目が多くなれば、入力画面も複雑になります。

担当者が確認する項目も増えます。

プログラム側の処理も増えます。

そのため、V1では「毎日のNEWS候補確認が楽になること」を最優先にして、必要な項目に絞ります。

V1で使う項目は、次の10項目です。

・元記事タイトル
・元記事URL
・カテゴリ
・NEWS表示文
・表示先NEWS
・表示フラグ
・承認ステータス
・X投稿文案
・X投稿ステータス
・メモ

元記事タイトルは、どの記事のNEWS候補なのかを判断するために使います。

元記事URLは、担当者が元記事を確認するために使います。

カテゴリは、表示先NEWSを判断する材料になります。

NEWS表示文は、実際にNEWS枠へ表示する文面です。

表示先NEWSは、TECN NEWS、ダイソーNEWS、どこの国NEWS、LDAC / Bluetooth NEWS、在庫管理 / DX NEWSなど、どのNEWS枠に出すかを選ぶための項目です。

表示フラグは、そのNEWS候補を実際に表示するかどうかを管理します。

承認ステータスは、未確認、修正中、承認済み、非表示などの状態を管理します。

X投稿文案は、Xに投稿するための文面です。

X投稿ステータスは、未投稿、投稿済み、投稿しないなどの状態を管理します。

メモは、担当者の判断理由や注意点を残すために使います。

この10項目があれば、V1としては十分に実務で使える形になります。

一方で、次の項目はV2以降に回してもよいです。

・元記事ID
・公開日
・投稿者
・表示開始日
・表示終了日
・確認日
・確認者
・X投稿予定日
・X投稿済み日
・X投稿メモ
・自動おすすめNEWS枠
・表示回数
・クリック数
・更新履歴

これらの項目は、あると便利です。

しかし、V1の最初から必須にすると、設計も実装も複雑になります。

たとえば、表示開始日と表示終了日があれば、NEWSの表示期間を自動管理できます。

しかし、最初は担当者が表示フラグを切り替えるだけでも十分です。

確認日と確認者があれば、誰がいつ承認したかを管理できます。

しかし、最初は承認ステータスとメモがあれば、最低限の確認管理はできます。

表示回数やクリック数があれば、どのNEWSが読まれているかを分析できます。

ただし、これはNEWS候補管理の初期段階ではなく、運用が回り始めた後に考える内容です。

大切なのは、V1でやることと、将来やることを分けることです。

この切り分けをしておくと、最初の実装が進めやすくなります。

また、読者にとっても「まずはここまで作ればよい」という到達点が分かりやすくなります。

TECN NEWS候補管理 V1では、まず10項目に絞ってスタートします。

そして実際に使いながら、不足している項目を追加していきます。

小さく始めて、必要に応じて育てていく。

これが、WordPressを使ったミニシステム作りではとても重要です。

H2-10 内部項目名を決める

次に、内部項目名を決めます。

ここまで整理してきた項目には、画面上に表示する名前があります。

たとえば、元記事タイトル、元記事URL、NEWS表示文、表示先NEWS、承認ステータスなどです。

これらは、担当者が画面上で見るための分かりやすい名前です。

しかし、実際にWordPressの中でデータを保存したり、PHPで処理したりするときには、プログラム内部で使う項目名も必要になります。

たとえば、画面上では「NEWS表示文」と表示していても、内部では news_text のような名前で扱います。

この内部項目名を先に決めておくと、次回以降の実装がかなり進めやすくなります。

V1で使う項目について、画面表示名と内部項目名を対応させると、次のようになります。

・元記事タイトル：source_title
・元記事URL：source_url
・カテゴリ：source_category
・NEWS表示文：news_text
・表示先NEWS：news_target
・表示フラグ：display_flag
・承認ステータス：approval_status
・X投稿文案：x_post_text
・X投稿ステータス：x_post_status
・メモ：memo

内部項目名は、できるだけ英数字で分かりやすくします。

日本語の項目名は、画面上では分かりやすいですが、プログラム内部で扱う名前としては少し使いにくい場合があります。

そのため、内部項目名は英語ベースにしておきます。

たとえば、元記事に関する項目は source という言葉を使います。

元記事タイトルは source_title。

元記事URLは source_url。

カテゴリは source_category。

このようにそろえておくと、後から見たときに「これは元記事側の情報だな」と分かりやすくなります。

NEWS表示に関する項目は news という言葉を使います。

NEWS表示文は news_text。

表示先NEWSは news_target。

このようにしておくと、NEWS表示に関する項目だと分かりやすくなります。

表示フラグは display_flag とします。

承認ステータスは approval_status とします。

X投稿文案は x_post_text。

X投稿ステータスは x_post_status。

メモは memo。

このように内部項目名を決めておくと、カスタムフィールドを作るときに迷いません。

また、ショートコードで一覧を表示するときも、どの項目を取り出せばよいかが分かりやすくなります。

注意点として、内部項目名は途中で頻繁に変えない方がよいです。

あとから項目名を変えると、保存済みデータやPHPコード、ショートコード側の処理も修正が必要になる場合があります。

そのため、最初にある程度分かりやすい名前を決めておくことが大切です。

もちろん、V1の段階なので完璧でなくても構いません。

ただし、あとから見ても意味が分かる名前にしておくことは重要です。

TECN NEWS候補管理 V1では、次回以降、この内部項目名をもとに、カスタムフィールドとしてデータを保存する方針で進めていきます。

つまり、このH2-10は、設計から実装へ進むための橋渡しになります。

画面上で何を見せるか。

内部ではどの名前で保存するか。

この両方を整理することで、次回のカスタム投稿タイプとカスタムフィールド設計に進みやすくなります。

H2-11 第2回のまとめ

第2回では、TECN NEWS候補管理 V1で扱う「NEWS候補1件」に、どのような項目を持たせるかを設計しました。

第1回では、NEWS候補管理 V1の目的と全体構想を整理しました。

そして今回は、その中の第2ステップとして、NEWS候補1件をどのような情報の集まりとして扱うかを決めました。

今回整理した内容は、大きく分けると次の5つです。

1つ目は、元記事に関する項目です。

元記事タイトル、元記事URL、カテゴリを持たせることで、どの記事をNEWS候補として扱っているのかを確認できるようにします。

2つ目は、NEWS表示に関する項目です。

NEWS表示文、表示先NEWS、表示フラグを持たせることで、どのNEWS枠に、どの文面で、表示するかどうかを管理できるようにします。

3つ目は、表示先NEWSの種類です。

TECN NEWS、ダイソーNEWS、どこの国NEWS、LDAC / Bluetooth NEWS、在庫管理 / DX NEWS、TECNおすすめ、非表示といった選択肢を用意することで、記事内容に合わせて適切なNEWS枠へ振り分けられるようにします。

4つ目は、承認・確認に関する項目です。

承認ステータスとメモを持たせることで、未確認、修正中、承認済み、非表示といった状態を管理できるようにします。

5つ目は、X投稿に関する項目です。

X投稿文案とX投稿ステータスを持たせることで、Xへの手動投稿や予約投稿を効率化できるようにします。

また、V1で使う項目と、V2以降に回す項目も分けました。

V1では、まず次の10項目に絞ります。

・元記事タイトル
・元記事URL
・カテゴリ
・NEWS表示文
・表示先NEWS
・表示フラグ
・承認ステータス
・X投稿文案
・X投稿ステータス
・メモ

この10項目があれば、NEWS候補を確認し、文面を修正し、表示先を選び、承認状態やX投稿状態を管理できます。

一方で、表示開始日、表示終了日、確認者、確認日、表示回数、クリック数などは、V2以降の拡張項目として考えます。

最初からすべてを作り込むのではなく、まずは毎日のNEWS候補確認が楽になることを優先します。

さらに、画面表示名だけでなく、内部項目名も整理しました。

source_title、source_url、source_category、news_text、news_target、display_flag、approval_status、x_post_text、x_post_status、memo という内部項目名を使うことで、次回以降のカスタムフィールド設計につなげやすくなります。

今回の設計ができたことで、次の工程に進む準備が整いました。

次回はいよいよ、WordPressの中にNEWS候補専用の保存先を作っていきます。

H2-12 次回はNEWS候補の保存先を作る

次回は、WBSの第3ステップに進みます。

第3ステップでは、NEWS候補をWordPressのどこに保存するかを決めます。

今回、第2回では、NEWS候補1件に持たせる項目を整理しました。

しかし、項目を決めただけでは、まだWordPressの中に保存する場所がありません。

そこで次回は、NEWS候補専用の保存先を作ります。

WordPressには、通常の記事や固定ページとは別に、独自のデータを保存するための仕組みがあります。

それが、カスタム投稿タイプです。

通常の記事は、WordPressの中では post として管理されています。

固定ページは、page として管理されています。

今回作るNEWS候補は、通常の記事でも固定ページでもありません。

元記事をNEWSとして活用するための、別の管理データです。

そのため、NEWS候補専用のカスタム投稿タイプを作ります。

イメージとしては、WordPressの中に「NEWS候補専用の箱」を作るようなものです。

その箱の中に、今回設計した元記事タイトル、元記事URL、NEWS表示文、表示先NEWS、承認ステータス、X投稿文案などを保存していきます。

第3回では、初心者の方にも分かりやすいように、次の内容を整理します。

・カスタム投稿タイプとは何か
・なぜNEWS候補専用の保存先が必要なのか
・通常の記事や固定ページと何が違うのか
・NEWS候補用のカスタム投稿タイプ名をどう決めるか
・Code Snippetsを使って登録する考え方

ここまで進むと、TECN NEWS候補管理 V1は、単なる構想から実際のWordPress上の仕組みに近づいていきます。

第2回で項目を設計し、第3回で保存先を作る。

この順番で進めることで、あとから作り直しの少ない、実務で使いやすいミニシステムにしていきます。