AIを使って記事を作り始めると、本文を書くこと以上に「これは下書きか、公開してよい状態か」が分かりにくくなることがあります。ツールが増えるほど、タイトルだけ作った記事、画像待ちの記事、確認済みだと思っていた記事が混ざりやすくなるためです。
この記事では、Google Sheetsでブログ運用を記録するための、無理のない3表構成を紹介します。自動公開を実現する方法ではありません。誰が何をどこまで確認したかを残し、公開や公開済み記事の変更を人間が判断しやすくするための設計です。
AIに記事制作を任せる範囲と、人間が公開判断を持つ理由は、AIでWordPressブログ運営を自動化して分かったことで説明しています。本記事では、その運用方針を前提に、台帳の作り方だけに絞ります。
1枚の表だけでは、何が分かりにくくなるのか
最初は「タイトル」「公開日」「URL」だけでも管理できます。ただ、記事数や更新が増えると、次の情報を同じ列に詰め込みがちです。
- 記事が今どの段階にあるか
- 公開や更新の承認を得たか
- 何を変更し、反映後に何を確認したか
これらは似ていますが、答える問いが違います。1枚の表にすべて書こうとすると、一覧性を優先すれば経緯が消え、経緯を残せば一覧が読みにくくなります。そこで、役割ごとに3表へ分けます。
3つの表に分ける
| 表 | 主な問い | 最低限あるとよい項目 |
|---|---|---|
| 記事台帳 | この記事は今どこにあるか | 記事ID、タイトル、状態、公開URL、最終確認日 |
| 公開ワークフロー | 今回の公開・更新を実行してよいか | 要求する操作、承認状態、期待する変更、実施結果 |
| 記事変更履歴 | 何を、なぜ変更したか | 変更理由、変更箇所、確認結果、実施日 |
| ① 記事台帳 現在地を確認 |
→ | ② 公開ワークフロー 実行の承認を確認 |
→ | ③ 記事変更履歴 変更理由を確認 |
ART-014 のような共通の記事IDで3表をつなぐ |
||||
記事台帳は「現在地」を見る表
記事台帳は、企画から公開後の評価までを1行で追うための表です。読者向けのタイトル、主要キーワード、公開URL、最終確認日を並べておくと、次に確認すべき記事を探しやすくなります。
状態列は、自由入力より選択肢を決めておくと表記ゆれを抑えられます。Google Sheetsではデータの入力規則からセル内プルダウンを作成でき、不一致の入力を拒否するか警告にするかも選べます。Google公式ヘルプを確認したうえで、最初は次のような少数の状態から始めると十分です。
企画 → 執筆中 → レビュー待ち → 承認済み → 下書き反映済み → 公開済み → 評価待ち
この遷移は一例です。投稿を予約するか、既存記事の更新が多いかによって、必要な状態は変わります。
たとえば架空の記事 ART-014 を「承認済み」として下書きへ反映したら、記事台帳の状態を「下書き反映済み」にします。同じ ART-014 の公開ワークフローには「公開」の承認状態と、公開後にURLを開いて確認した結果を残します。こうすると、一覧では現在地を、ワークフローでは今回の操作の根拠を、混同せずに見られます。
公開ワークフローは「実行してよいか」を見る表
公開ワークフローには、記事そのものの情報を繰り返し書きません。今回の操作について、次の3点を残します。
- 何をするか（下書き作成、公開、公開済み記事の更新など）
- 何が変わる予定か
- 実行後の読み戻しで何を確認したか
たとえば公開済み記事を更新する場合、タイトル・本文・説明文のどれを変えるのかを先に書きます。そのうえで、承認の有無と、更新後に公開状態やURLが想定どおりかを記録します。
ここで重要なのは、AIが「公開してよさそう」と提案したことと、公開を承認したことを同じ扱いにしないことです。AIや自動化ツールが下書き作成や状態変更を提案しても、最終承認と公開実行、反映後の確認は人間が行う運用にします。
また、シート上の状態を更新しても、WordPressなどの投稿状態そのものは変わりません。台帳は投稿先の代わりではなく、確認と判断を記録するためのものです。
記事変更履歴は「後から理由を追う」表
記事台帳の状態が「公開済み」であっても、その後にタイトル、本文、内部リンク、画像などを更新することがあります。公開ワークフローだけでは、数週間後に「なぜこの表現を変えたのか」が追いにくくなります。
そこで変更履歴には、変更の目的と対象を短く残します。例としては、「読者の疑問に答える節を追加」「内部リンクを追加」「公開ページの表示を確認」といった粒度です。
Google Sheetsにはファイル全体の版の履歴や、セルごとの編集履歴を確認する機能があります。ただし、履歴だけでは変更の意図や確認結果までは自動的に説明してくれません。運用上の理由と確認結果を残したい場合は、変更履歴表を別に持つ方が見返しやすくなります。Google公式ヘルプでも、版の履歴とセルの編集履歴を確認する方法が案内されています。
3表をつなぐのは、記事IDのような共通キー
表を分けると、「どの公開ワークフローが、どの記事のものか」が分からなくなる心配があります。そこで、各表の先頭に同じ記事IDを置きます。
記事IDは連番でも、任意の短い識別子でも構いません。大切なのは、記事台帳・公開ワークフロー・変更履歴で同じ値を使い続けることです。URLやタイトルは変更されることがありますが、識別子を固定しておけば、複数の表を横断して確認できます。
公開用の画面や画像を作る場合は、実在のID、アカウント名、メールアドレス、内部URLをそのまま載せないようにします。架空の例に置き換えるだけで、仕組みは伝えられます。
状態が実態とずれたときの扱いを決めておく
自動処理や手作業が途中で止まると、表だけが先に「公開済み」になったり、逆に公開済みなのに表が「下書き」のまま残ったりします。状態列は実態を保証するものではありません。
不整合を見つけたら、状態だけを先へ進めるのではなく、実際の投稿状態と公開ページを読み戻します。その結果を公開ワークフローまたは変更履歴に残してから、記事台帳の状態を更新します。
この順番にしておくと、「シート上では完了していたのに公開ページが違った」という見落としを減らしやすくなります。
検知の機会も決めておくと続けやすくなります。たとえば公開ワークフローを完了にする前に必ず公開ページを開く、週に一度は公開URLと記事台帳の状態を見比べる、といった小さな確認を運用に組み込みます。
| ① 下書き | → | ② 内容確認 | → | ③ 承認 | → | ④ 公開操作 | → | ⑤ 公開ページ確認 |
最初は小さく始める
個人で少数の記事だけを管理するなら、最初から3表すべてを細かく作る必要はありません。まずは記事台帳と公開ワークフローの2表から始め、公開済み記事の更新が増えた段階で変更履歴表を追加してもよいでしょう。共有して使う場合は、承認状態や記事IDを誰が更新するかも先に決めておくと、記録の意味がぶれにくくなります。
列も増やしすぎないことが大切です。毎回更新できない列は、最初は作らない方が台帳が信頼できます。運用を続けながら「確認で困ったこと」を見つけ、その都度1列ずつ足す方が、表は実務に合いやすくなります。
まとめ
Google Sheetsの台帳は、公開を自動化するためだけのものではありません。記事の現在地、今回の承認、変更の理由を分けて記録すると、AIや複数のツールを使う場合でも、公開判断を人間側に残しやすくなります。
まずは記事台帳、公開ワークフロー、変更履歴の役割を分け、同じ記事IDでつなぐことから始めてみてください。自分の運用に合わない列や状態は、無理に増やさず調整するのが続けやすい方法です。
コメント