記事制作の進行管理テンプレートは、1記事を1行で管理し、「誰が、いつまでに、どの工程を進めるか」と「どこまで確認できたか」が分かる形にすると使いやすくなります。担当と締切だけでなく、原稿・画像・下書きの保存先、残課題、次の操作まで同じ記事IDで結び付けるのがポイントです。
複数の執筆者や編集者、AIを使って制作すると、原稿は完成していても画像が未確認だったり、下書き保存を公開完了と取り違えたりします。本記事では、企業のメディア担当者・編集責任者・記事制作事業者に向けて、そのまま項目を転記できる台帳例と更新ルールを紹介します。
以下の列構成・状態名・仮想例は、AWL編集部が提案する運用例です。特定ツールの必須仕様や、導入効果を実測した事例ではありません。
当メディアでは、ArticleOS（アーティクルOS）を活用した記事制作をGoogleスプレッドシートの記事マスターで管理しています。記事IDを軸に、制作状況・入稿状況・公開状況を分け、成果物の保存先やWordPress投稿ID、残課題を記録する方法です。本記事では、その管理項目も紹介しながら、次の担当者が作業を再開できる進行管理テンプレートの作り方を解説します。
当メディア運営会社のサービス｜ArticleOS
記事計画から制作・公開前確認までを、一つの流れに
当メディアで活用するArticleOSは、企業や媒体に合わせて記事制作の工程を組み立てるAI記事制作システムです。仕組みと提供内容を紹介しています。
記事制作の進行管理で最初にそろえる必須項目
まずは記事の識別情報、進捗、成果物、残課題を分けて用意します。項目を増やすことより、同じ言葉を全員が同じ意味で使い、最新の確認結果へたどれることが重要です。
1記事1行と、変わらない記事IDを基本にする
記事IDはタイトルや保存先が変わっても維持します。たとえば仮の管理番号「EDIT-001」を発行したら、原稿、画像の一覧、確認記録にもその番号を付けます。シートの行番号は並べ替えや追加で変わるため、記事の識別子には使いません。
同じテーマでも、比較記事と導入手順の記事では検索意図が異なる場合があります。一方、表現だけ違うタイトルで同じ内容を作る可能性もあります。台帳には主キーワードと「誰の、どの判断を助ける記事か」を短く残し、タイトルの一致だけで重複を判断しないようにします。
そのまま使える管理項目テンプレート
次の表の項目名を、表計算ソフトや管理ツールの列として転記できます。初期はこの範囲から始め、更新する人と用途が明確な列だけ追加してください。入力例は架空の企業記事を想定したものです。
| 管理項目 | 記録する内容・仮想例 | 入力のルール |
|---|---|---|
| 記事ID | EDIT-001 | 一度発行した値は変えず、重複させない |
| タイトル・主キーワード | 導入準備ガイド／導入準備 | 仮タイトルと確定タイトルを区別する |
| 検索意図・対象読者 | 担当者が導入前の準備を整理する | 記事の役割を1〜2文で記す |
| 予定URL | 計画で承認された掲載先 | 公開URLとは別に扱う |
| 優先度・制作順 | 高／3番目 | 理由と順序を別々に記録する |
| 現在の担当・確認担当 | 執筆担当A／編集担当B | 今動く人と次に確認する人を明確にする |
| 工程の期限・公開希望日 | 初稿10月23日／公開希望10月30日 | 年と必要な時刻・タイムゾーンをそろえる |
| 制作状況・入稿状況 | 原稿確認済み／未入稿 | 制作とCMS上の状態を混ぜない |
| 成果物リンク | 原稿、画像一覧、SEO情報、QA記録 | 現行版を開けるリンクを残す |
| 投稿ID・編集URL | 保存後に確認できた値 | 投稿前の推測値は入力しない |
| 公開状況・公開URL | 未公開／実公開後のURL | 希望日だけで公開済みにしない |
| 残課題・次の操作 | 表のSP表示確認／編集担当Bが確認 | 影響、担当、再開条件を含める |
| 作業識別子・開始日時 | 当日の作業番号と開始時刻 | 並行作業・引き継ぎを識別する |
| 最終確認日時・確認者 | 2026年10月23日15:00 JST／担当B | 実際に状態を確認した時点を残す |
成果物が多い場合は、1セルにすべて詰め込まず、原稿URL・画像フォルダーURL・QA記録URLを別列にします。逆に、毎回使わない項目を大量に追加すると更新漏れが起こりやすくなるため、運用後に必要性を見直します。
状態は「制作」「入稿」「公開」に分けて定義する
進捗の誤解を減らすには、状態名だけでなく、その状態へ進める条件を決めます。「完了」を1種類にまとめず、原稿の完成、CMSへの保存、公開判断を分けましょう。
状態名より「何を確認したら変えるか」を決める
次は台帳上の制作状況の定義例です。人によって解釈が変わる場合は、運用ルールの別シートに定義を置き、台帳では選択肢から入力する方法が使えます。各状態の前提が満たせないときは、未確認のまま次へ進めません。
| 制作状況 | その状態にする条件 | 次に行うこと |
|---|---|---|
| 未着手 | 企画は確定しているが、制作を始めていない | 担当・開始時刻を記録する |
| 制作中 | 現在の担当が調査・構成・執筆などを進めている | 現行の成果物と進行工程を残す |
| 確認待ち | 確認対象の版と依頼先が確定している | 確認担当が基準に沿って点検する |
| 修正中 | 修正事項と対応する担当が決まっている | 修正箇所を再確認する |
| 制作済み | 定義した原稿・付帯資料が保存され、内容を確認した | 入稿工程へ引き継ぐ |
| 保留 | 必要情報や承認など、再開条件が満たせない | 保留理由と解除条件を記録する |
「制作済み」の範囲はチームごとに定義します。本文だけを納品する仕事と、画像やSEO設定案まで担当する仕事では、完成条件が異なるためです。追加作業が発生したら、元の完成基準を黙って変えず、変更理由と対象工程を記録します。
WordPressの下書きと公開待ちを同一視しない
WordPress公式では、draftは下書き、pendingは公開権限を持つユーザーによる対応待ち、futureは予約公開、publishは公開という別の状態です。制作台帳で使う「公開待ち」という言葉だけでは、WordPressに保存されているか、公開承認が済んでいるかは分かりません。
そこで、入稿状況は「未入稿・入稿中・下書き保存確認済み」など、公開状況は「未公開・公開判断待ち・公開済み」などに分けます。予約公開を扱う組織では、予約日時と実際の公開結果も別に記録してください。予定の到来だけでは、公開が成功した証拠になりません。
たとえば、本文と画像を入れた下書きが存在しても、スマートフォンの表示確認が終わっていなければ、「下書き保存確認済み／公開判断待ち／SP表示未確認」と書けます。完成済みの工程を後戻りさせず、残る確認だけを可視化できます。
担当と期限は「次に動く人」が分かる形で管理する
各記事に現在の担当と次の担当、工程ごとの期限を設定すると、作業の受け渡しを確認できます。部署名だけでは誰が動くか曖昧になるため、実際に対応できる担当者や窓口を決めます。
記事の責任者と現在の作業担当を分ける
記事責任者は全体を追う人、作業担当は今の工程を実行する人です。兼任する場合も、役割を分けておくと、外注や複数人での制作へ移ったときに整理しやすくなります。承認権限そのものの設計と、この記事の台帳に記す「現在の担当」は別の論点です。
NISTのAIリスク管理フレームワークも、AIに関わる役割と責任、人による監督を明確にする考え方を示しています。ただし、本記事の列構成はNISTが指定する様式ではありません。AIを使うから責任がAIへ移るのではなく、確認する人が誰かを台帳へ落とし込む提案です。
チーム編成や外注からの移行まで整理したい場合は、記事制作を内製化するための体制づくりも参考にしてください。本記事では、決まった担当体制を記事ごとの行にどう記録するかへ焦点を当てています。
締切は「公開日だけ」にしない
公開希望日だけが決まっていると、初稿や画像の遅れが見えにくくなります。初稿提出、編集確認、修正、下書き確認の期限を必要な範囲で分け、次の工程が始まる条件も残しましょう。確認に必要な時間を無視して、すべて同じ日付にそろえる運用は避けます。
期限に間に合わない場合は、過去の期限を消して新しい日付だけにするのではなく、当初期限・見直し期限・変更理由を記録します。遅延の責任追及ではなく、「何の情報が遅れ、どの工程へ影響したか」を次回の計画に生かすためです。
複数人や自動処理が同じ台帳を使うなら、着手前に現在の担当と作業中の記録を確認します。誰かが対応中なら、その記事を重ねて制作しません。担当変更時は、引き継ぐ成果物と未完了工程を合わせて更新します。
成果物リンクは「保存先」だけでなく現行版と確認結果を残す
台帳のリンクは、次の担当者が実物を開けて初めて役立ちます。ファイル名やフォルダー名だけでなく、現在採用する版、保存確認の結果、CMS上の投稿IDを対応させます。
原稿・画像・SEO情報・QA記録を同じIDで結ぶ
原稿と画像が別の場所にあっても、記事IDが一致していれば関係を追えます。原稿の保存先、画像一覧、SEOタイトル・メタディスクリプション、確認記録を台帳からたどれるようにしましょう。画像は本文の挿入位置とファイル名、altを一覧化しておくと、取り違えを見つけやすくなります。
「最終」「最終2」「最新版」という名前だけで採用版を判断するのは避けます。台帳に現行版のリンクを1つ示し、版番号や更新日時、変更概要を付けます。古い原稿を残す場合は履歴として分け、どちらが入稿対象か曖昧にしないことが大切です。
保存先の権限も確認対象です。社内では開けても外部編集者には開けない場合があります。ただし、便利にするためだけに共有範囲を広げず、担当者に必要な最小限のアクセスを用意します。顧客の機密資料や認証情報を進行管理の自由記入欄へ貼り付けないでください。
保存後は、実物を読み戻して状態を更新する
保存ボタンを押しただけで「保存確認済み」にせず、保存先を開き直して対象記事と内容を確認します。下書きなら投稿ID、タイトル、本文、画像、カテゴリー、予定URL、SEO情報などを照合します。確認できない項目は、残課題として分離します。
AIを使って記事を作る場合、Googleは公開前の人による事実確認を重視し、本文だけでなくタイトル、メタディスクリプション、構造化データ、画像altも確認対象としています。原稿ファイルの校正と、CMSへ反映された内容の点検は別に記録すると、入稿時の欠落を見逃しにくくなります。
具体的な点検観点は、AI記事の事実確認・出典・納品前QAで確認できます。台帳側には全チェック項目を重ねて書くより、QA記録へのリンクと未解決の要点を残す方が管理しやすくなります。
残課題は「影響・担当・次の操作・再開条件」で書く
残課題欄には、困っている事実だけでなく、どこまで作業できていて、何がそろえば再開できるかを書きます。これにより、担当者が変わっても完成済みの原稿や下書きを再利用できます。
曖昧なメモを、行動できる記録へ変える
「要確認」「画像が変」「あとで対応」だけでは、読む人が最初から調べ直すことになります。問題のある対象、検出した現象、影響、確認担当、期限、次に行うことを短くまとめましょう。解消済みの課題は削除せず、対応結果と確認日時を残します。
| 曖昧な書き方 | 次に動ける書き方の例 |
|---|---|
| スマホ要確認 | 料金表のSP表示は未確認。下書き保存済み。編集担当Bが幅の狭い画面で横はみ出しを確認し、結果をQAへ記録する。公開判断はその後。 |
| 画像未完了 | 画像3のaltが未設定。画像ファイルは保存済み。入稿担当Aが既存画像にaltを設定し、再表示して確認する。再アップロードは不要。 |
| 出典がない | 提供条件を示す一次情報が未確認。該当段落の確定を停止。編集担当Bが公式資料を確認できること、または当該主張を削除する判断が再開条件。 |
| 投稿エラー | 保存結果が不明。投稿一覧と既存下書きを記事ID・タイトルで照合してから判断。存在確認前に同じ記事を新規投稿しない。 |
ここでの例は仮想例です。異常があっても安全に保存できる範囲の作業は進められますが、正確性を左右する事実、認証、保存失敗、重複の疑いなどは、影響する工程を止めて確認します。問題を記録したことと、公開してよいことは別です。
中断時には最後に確認できた状態を残す
作業を途中で止めるときは、「原稿のどこまで完了したか」「何を保存確認したか」「どの工程が未完了か」を記します。作業再開時はその記録と実物を照合し、保存済み原稿や画像があれば使い続けます。更新されている可能性があるため、過去の行番号や古いリンクだけに依存しません。
保存結果が不明なときは、再試行より先に状態を確認します。同じ画像を何度もアップロードしたり、同じ記事の下書きを作り直したりすると、採用版が分からなくなります。NISTのフレームワークが扱う継続的なリスク管理も参考に、運用中の未確認や障害対応を記録する設計にしましょう。
テンプレートを日々の制作で使う運用例
台帳は作って終わりではありません。工程の開始、受け渡し、保存確認、中断のタイミングで更新すると、予定と実態のずれを見つけやすくなります。
3記事の状況を、短い一覧で見比べる
次は前述の列を使った架空の運用例です。見やすさのため主要項目だけを抜き出しています。実際の台帳には成果物リンク、期限、確認日時も残してください。
| 記事ID | 制作／入稿／公開 | 現在の担当 | 次の操作・残課題 |
|---|---|---|---|
| EDIT-001 | 制作中／未入稿／未公開 | 執筆担当A | 公式条件を確認して比較表を完成。原稿前半は保存済み。 |
| EDIT-002 | 制作済み／下書き保存確認済み／公開判断待ち | 編集担当B | SP表示を確認。本文・画像は保存確認済み。 |
| EDIT-003 | 保留／未入稿／未公開 | 企画担当C | 既存記事との役割重複を確認。統合か独立かの判断後に再開。 |
この一覧なら、EDIT-002の原稿を再制作する必要はなく、EDIT-003を単純な執筆遅れとして扱う必要もありません。各記事に必要な次の一手が違うことが分かります。日々の確認では、全行を読み上げるより、期限超過・長い確認待ち・担当不明の行を優先して見ます。
AIへ渡す更新指示にも、更新範囲と根拠を含める
AIに台帳の整理を補助してもらう場合は、対象記事ID、現在値、変更してよい列、確認できた根拠をセットで渡します。未確認の値は推測で埋めず、既存の備考や設計を保持するよう指定します。実際の外部ファイル更新は、組織の権限と承認ルールに従ってください。
指示例は「対象はEDIT-002。確認できたのは下書き保存まで。入稿状況と投稿ID、最終確認日時だけを更新し、公開状況は未公開のままにする。未確認のSP表示は残課題へ追記する。更新後に同じIDの行を読み戻す」です。これは運用用の仮想例で、特定サービスが自動実行できることを示すものではありません。
制作工程全体を整理する場合は、AIによる記事制作の自動化と確認工程も参照できます。まずは少数の記事で入力負担と引き継ぎやすさを確かめ、実際に使わない列を減らすと継続しやすくなります。
記事制作の進行管理テンプレートの実例｜当メディアのArticleOS運用
ArticleOSは、当メディア運営会社が提供するAI記事制作システムです。ここでは、当メディアの制作運用で使用しているGoogleスプレッドシートの記事マスターを例に、記事計画と進捗、成果物、残課題をどう結び付けているかを紹介します。
以下の管理項目は、当メディアの記事マスターで確認できた列を整理したものです。記入例は掲載用の仮想例とし、内部の編集URLや保存先、未公開情報は転載していません。この台帳がArticleOSの専用管理画面や共通の標準機能として提供されるという意味ではありません。
Googleスプレッドシートを記事制作の台帳にする
記事マスターでは「共通記事ID」を軸に、カテゴリー、記事タイトル、主キーワード、予定URLと、制作の状態を同じ行に記録しています。タイトルだけで管理せず、記事IDから成果物や投稿先をたどれる形にする考え方です。
| 管理の目的 | 実際に使っている項目 |
|---|---|
| 記事を識別する | 共通記事ID、カテゴリー、記事タイトル、主キーワード、予定URL |
| 進捗を分ける | 制作状況、入稿状況、公開状況 |
| 成果物へたどる | 成果物URL、WordPress投稿ID、編集URL |
| 着手・保留を判断する | 自動選定、選定条件・保留理由 |
| 残る作業を引き継ぐ | 元備考・QA残課題 |
| 作業の時点を残す | 実行ID・担当、制作開始日時、最終確認日時 |
本記事前半の汎用テンプレートで提案した「工程の期限」「確認担当」などは、自社の体制に応じて用意する項目です。上表の実際の列構成と同一ではありません。実例の列をそのまま増やすより、自分たちが更新できる範囲と、必要な判断から選びましょう。
制作・入稿・公開を別々の列で管理する
記事マスターには「制作状況」「入稿状況」「公開状況」が別の列としてあります。原稿や画像を保存できたこと、WordPressに下書きが存在すること、記事が公開されていることを、一つの完了表示にまとめないためです。
掲載用の仮想例なら、「制作済み／下書き保存確認済み／未公開」と記録し、残課題に「表示確認と公開判断が未完了」と添えられます。保存済みの原稿を作り直すのではなく、まだ終わっていない確認へ進めます。実際に使う状態名と変更条件は、チームの運用ルールで定めてください。
成果物URLとWordPress投稿IDを対応させる
「成果物URL」には保存済みファイルへたどるための情報を、「WordPress投稿ID」「編集URL」にはCMS上の対象を記録します。これにより、原稿の保存場所と入稿先を同じ記事IDで対応させます。
予定URLは記事計画での掲載先、編集URLは実際の投稿を操作する場所で、役割が異なります。引き継ぐ際は、記録があることだけで完了とせず、成果物と投稿を開いて対象記事が一致するか確かめます。古い記録と実物が異なる場合は、確認時点を残して更新することが重要です。
保留理由とQA残課題を残す
当メディアの記事マスターには、「選定条件・保留理由」と「元備考・QA残課題」の列があります。着手できない理由と、制作・入稿後に残る確認を記録できる構成です。過去の記録には、保存済み成果物を保持し、未完了工程から再開するための経過も残しています。
掲載用の記入例は「原稿と画像は保存確認済み。WordPress下書きあり。料金表のスマートフォン表示が未確認。編集担当が表示を確認し、結果を記録してから公開可否を判断する」です。「要確認」だけにせず、維持できる成果物と次の操作を伝えます。
自動選定の列があっても、すべての記事を無条件で自動制作するという意味ではありません。既存成果物や投稿、保留理由を確認し、重複した新規制作を避ける判断と組み合わせます。
記事一覧と運用ルールを別シートに分ける
確認した記事マスターには、「01_記事マスター」「02_運用・参照元」「03_要確認」「04_サービス参照」の4シートがあります。ここではシート構成を紹介しており、各シートの詳細な設定や自動連携の仕様を示すものではありません。
自社で台帳を作る場合も、記事ごとの一覧と、状態の定義・更新方法などの共通ルールを分けると、同じ説明を各行へ繰り返す量を減らせます。一覧から必要な資料へたどれるようにし、ルールの変更時は影響する記事を確認する運用を検討してください。
ArticleOSを導入する場合の管理方法や連携先は、利用環境と担当範囲に応じて確認が必要です。本記事の台帳例を参考に必要項目を整理し、制作フローと合わせてどこまで支援を受けたいかを相談すると、対応範囲をすり合わせやすくなります。
当メディア運営会社のサービス｜ArticleOS
制作ルールと記事計画を、運用につながる仕組みへ
記事・画像・CTA・公開前QAまで、支援を受けたい工程を整理してArticleOSの対応範囲を確認できます。管理方法や連携先は個別にご確認ください。
記事制作の進行管理でよくある質問
管理ツールの種類よりも、状態の定義と更新責任をそろえることを優先しましょう。ここでは、テンプレート導入時に迷いやすい点を整理します。
スプレッドシートだけでも管理できますか？
少人数で運用し、必要な列と更新ルールをそろえられるなら、表計算ソフトを使う方法があります。複雑な依存関係や通知、アクセス管理が必要になったら、その要件を満たす管理ツールを検討します。専用ツールを入れるだけで更新漏れがなくなるわけではありません。
原稿が完成したら、進捗は100％にしてよいですか？
本文執筆だけの進捗なら、その定義で完了にできます。しかし画像、入稿、表示確認まで含めた記事制作全体の完了とは異なります。割合を使う場合も、何を分母にするかを決め、未完了の工程を別に見える状態にしてください。
AIが作った原稿も、担当者を設定しますか？
設定します。AIの出力を確認する人、修正する人、公開判断を行う人を明確にします。モデル名やツール名は制作方法の記録にはなりますが、確認担当者の代わりにはなりません。
残課題がある記事はすべて制作中へ戻しますか？
戻す必要があるとは限りません。制作済みの原稿や保存済みの下書きは保持し、未完了の確認を具体的に記録します。ただし、記事の中心事実に誤りがある場合は該当部分の修正が必要です。どの成果物を維持できるかを判断し、公開可否と分けて管理します。
公開後は台帳を更新しなくてもよいですか？
公開日時と実際のURLを確認して記録し、必要に応じて公開後の表示やリンクも点検します。その後の情報更新や修正を追う場合は、最終更新日と次回確認事項を残します。制作時の履歴をすべて消してしまうと、何を根拠に公開したかを追えなくなります。
まとめ｜次の担当者が迷わず動ける台帳にする
記事制作の進行管理では、記事IDを軸に、担当・期限・工程別の状態・成果物・残課題をつなぐことが基本です。特に、原稿完成と下書き保存、公開判断を分けて記録すると、終わった作業をやり直さず、必要な確認に集中できます。
まずは本記事の項目表を転記し、各状態へ進める条件と更新する担当を決めてください。残課題には影響・次の操作・再開条件を書き、保存先を実際に開いて確認するところまでを運用に含めましょう。
当メディアのArticleOS運用でも、記事IDを軸に制作・入稿・公開の状態と成果物を対応させています。大切なのは、管理項目を増やすことより、何を確認できていて、次に誰が何をするかを残すことです。まずは少数の記事で試し、実際の引き継ぎで必要になった項目を整えましょう。
当メディア運営会社のサービス｜ArticleOS
記事制作を、継続できる仕組みとして整えたい方へ
自社で管理する範囲と支援が必要な工程を整理したら、ArticleOSの提供内容をご確認ください。料金・契約期間などの導入条件も案内しています。
出典・参考情報
情報確認日：2026年10月20日。公式資料に基づく一般情報と、編集部による管理方法の提案を分けて掲載しています。
- WordPress.org「Post Status」：下書き・承認待ち・予約公開・公開の状態の区別。
- Google 検索セントラル「ウェブサイトでの生成AIコンテンツの使用に関するガイダンス」：公開前の事実確認とメタデータ等の点検。
- NIST「AI RMF Core」：AI利用に関わる役割・責任・継続的なリスク管理。本記事の台帳は公式指定様式ではありません。
