WordPressで「投稿→確認→完了」を業務フローにする。状態をつなげた考え方

2026年10月5日

BUILD

WordPressの社内ポータルに投稿、コメント、検索を用意しても、それだけでは「誰が確認し、いつ終わったか」まではつながりません。

実際の運用では、管理担当者が文書を発行し、対象者が確認し、必要な確認がそろったら完了します。未完了の文書はHOMEに残し、完了後は入口から外しつつ記録は残す形にしました。

この記事では個別画面の制作手順ではなく、WordPressの投稿を「発行→対象決定→確認→完了」という業務フローへ変えた考え方を整理します。

機能があっても、次の人へ渡らなかった

最初のポータルには、記事を投稿し、カテゴリーで整理し、コメントでやり取りする基本機能がありました。しかし、業務文書として使うと、別の情報が必要になります。

通常の「公開済み」という投稿状態だけでは、これらを表せません。そこで、投稿の公開とは別に、業務上の状態をつなげました。

実装前に、利用者が経験する流れを次の5段階にしました。

画面ごとに機能を考えるのではなく、一つの投稿が最後までどう進むかを先に置きました。これにより、発行フォーム、詳細画面、HOME、カテゴリー一覧の役割を決めやすくなります。

業務文書では、一般的な記事タイトルと本文を毎回入力するより、文書の種類に合う専用フォームの方が扱いやすい場面がありました。

たとえば、タイトル、文書番号、参照先URL、PDFなど、文書ごとに必要な項目を用意します。「投稿」ではなく「発行」と表示し、必須項目が足りない場合は実行できないようにしました。

発行UIは、権限のある管理担当者だけに表示します。ボタンを隠すだけでなく、保存処理側でも権限を確認する前提です。

発行すると、WordPressの投稿が作られます。同時に、確認対象など業務に必要な追加情報を投稿メタへ保存します。投稿メタは、一つの投稿へひも付けて独自の値を保存するWordPressの仕組みです。

最初は、確認画面を開くたびに、現在登録されている利用者と所属グループから対象者を計算していました。

この方法では、文書を発行した後に新しい利用者を追加すると、過去文書の確認対象まで増えます。発行当時にはいなかった人が、未確認者として表示される問題です。

そこで、発行時点の対象ユーザーIDを投稿メタへ保存し、それ以降は保存済みの一覧を使う形へ変更しました。

方式	過去文書への影響
画面を開くたび現在ユーザーから計算	利用者追加で対象が変わる
発行時点のユーザーIDを保存	発行後も対象が変わらない

業務フローでは、「現在の組織状態」だけでなく、「その文書が発行された時点の状態」を残す必要があると分かりました。

対象者が文書を開くと、自分が確認対象かどうかと、現在の確認状況が分かります。確認操作を行った利用者は確認済みとして記録します。

利用者ごとの確認だけでなく、チーム単位で確認状況を見る文書もありました。その場合も、文書種別ごとに対象の決め方を変え、必要な確認がそろったかを同じ流れで判定します。

重要なのは、確認ボタン単体を作ることではありません。発行時に保存した対象と、実際に確認した利用者を比較し、残りがいるか判断できることです。

HOMEには、対応が必要な未完了文書を表示します。新着5件のような件数制限は使いませんでした。新しい文書が増えても、古い未確認文書が押し出されないようにするためです。

必要な確認がそろうと、その投稿はHOMEカードから外れます。ただし、投稿自体は削除しません。カテゴリー一覧や検索から、過去の記録として確認できます。

「完了したので削除する」のではなく、「今見る入口から外し、履歴として残す」と考えました。

この仕組みは、一つの画面だけでは成立しません。利用者が進む順番に、各画面へ役割を持たせました。

HOMEは全投稿を保存する場所ではなく、現在行動が必要なものへの入口です。記録を残す役割は、投稿と一覧・検索が受け持ちます。