導入の背景と共通設計
制作を継続する中で、書き手による解釈の差や、レビュー・担当者間のやり取りが負担になっていました。AIが実務で使える水準になったことを受け、工程ごとに導入しました。
作成と確認を分け、細かい単位で人がレビューし、改善点を仕組みに戻します。採否・優先度・表現の最終判断は人が担います。
- 目的ごとに工程を分ける
- 小さな単位で人が確認
- 修正の理由を言語化
- 次回の指示・基準へ反映

通常記事の制作工程

| 工程 | 設計したこと |
|---|---|
| 企画 | 過去記事DBから候補を抽出し、採否と優先度を人が判断 |
| 構成 | 中心の問い・扱わない範囲・根拠・主張の強さを先に確認 |
| 執筆 | 節ごとに主張・根拠・言いすぎの危険を明示 |
| チェック | 読者への配慮と、誤字脱字・表現を分けて確認 |
| 分業 | ライター本人の言葉で理解を確認し、意図のずれを調整 |
判断を共有するサンプル
本文を書く前に、主張と理解をそろえる
執筆前カード
- この節で伝えたい主張
- 根拠として使う記事・事例・発言
- 一般化や言いすぎの危険
- 根拠が弱く、断定を避ける点
理解確認シート
- 扱う論点を提示
- 書き手本人の言葉で理解を記録
- ディレクターが採否・表現の強弱を確認
- 確認後に構成・本文へ進む
制作時の考え方を示すために再構成した例です。実際の原稿やプロンプトの転載ではありません。
確認する目的ごとに工程を分ける
構成前の4つの確認
- 中心となる問い
- 扱わない範囲
- 根拠の中心
- 独自の主張をどこまで出すか
レビューの返し方
- Must/Wantで優先度を示す
- 該当する表現を示す
- 読者にどう受け取られるかを説明
- 実務の具体性を保った代案を示す
制作時の考え方を示すために再構成した例です。実際の原稿やプロンプトの転載ではありません。
取材・イベント・メール・SNSへの展開
| 対象 | AIの役割 | 人の役割 |
|---|---|---|
| 取材・イベント | 文字起こし、記事化の補助 | 不明瞭箇所・誤変換、公開範囲、内容の確認 |
| メール | たたき台への修正案と理由 | 切り口と最終文面の判断、修正点の反映 |
| SNS | 訴求候補と文面3案 | 要素の選択、整形、文字数・内容の最終確認 |

運用中の改善と不具合対応
記事ごとに出た修正指示を反映して、次回の指示を更新してきました。単発の生成結果にとどまらず、同じ修正を繰り返さないための運用です。
2026年7月には、それまで動いていた仕組みが指示に従わなくなる問題が発生しました。本人の切り分けではモデル更新に伴う指示の受け取り方の変化があり、参照元と指示の置き場所を整理して対応しました。
工程ごとの変化と全体評価
形式ごとの作業時間・レビュー往復・制作体制の変化は、親ページの全体評価に整理しています。AIによる工程改善と、要約型への見直しなどAI以外の変更を分けて扱っています。
制作体制・工数を含む全体評価へ →