1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AI時代の記事チェックリストが増えすぎたとき、残す項目と削る項目の決め方

1
Posted at

AI時代の記事チェックリストが増えすぎたとき、残す項目と削る項目の決め方

増えすぎた確認項目を、使えるチェックリストへ戻す

記事の誤りを防ぐためにチェックリストを作ると、最初は安心できます。日時、料金、場所、人物名、引用、画像、リンク、SNS。訂正や失敗のたびに項目を足していくと、いつの間にか一覧が長くなります。

長いチェックリストは、項目が多いほど安全になるとは限りません。読むだけで時間がかかり、関係のない項目にも印を付け、重要な確認が埋もれるからです。AIへ渡しても、条件が多すぎると、どこで止まるべきかが見えにくくなります。

そこで私は、項目をただ増やすのではなく、残す、記事別へ移す、まとめる、削るの4つに分けて見直します。

この記事では、チェックリストを短くすること自体を目的にせず、読者への影響が大きい確認を確実に実行できる形へ戻す方法を紹介します。

チェックリストの目的を先に決める

チェックリストは、知っている注意点をすべて保存する場所ではありません。作業中に忘れると困る確認を、実行できる順番で置く道具です。

私は、公開前チェックリストの目的を次のように決めます。

公開前に、読者へ影響する誤りと公開範囲の間違いを見つける。
確認できない場合は公開を止め、人間が判断する。

この目的から外れる情報は、チェックリストではなく手順書、用語集、記事別メモへ置けます。

たとえば「取材先との連絡経緯」は大切な記録ですが、毎回の公開直前に全文を読む項目ではありません。一方、「日時と料金を一次情報と照合した」は、読者の行動へ直接影響するため、公開前に残す価値があります。

チェックリストは知識の倉庫ではなく、公開前に実行する確認

まず、使われていない項目を見つける

見直しは、項目を読んだ印象だけで決めません。直近の記事で実際に使った結果を見ます。

各項目へ、次の情報を付けます。

記録 確認すること
対象 どの記事で使うか
根拠 何の失敗やリスクから生まれたか
実施 直近の記事で本当に確認したか
発見 誤りや差分を見つけたか
完了条件 何をもって確認済みとするか
代替 別の項目や自動検査で確認できないか

たとえば「リンクをよく確認する」では、何をしたら完了か分かりません。「本文の外部リンクを開き、目的のページが表示されることを確認する」なら実行できます。

また、半年間一度も使っていないからといって、すぐ削るわけではありません。頻度が低くても、公開範囲や個人情報の確認は、見逃したときの影響が大きいからです。

4つの行き先へ分ける

項目は、残すか削るかの二択にしません。

残す:すべての記事で、公開前に必要
記事別へ移す:特定の種類の記事だけで必要
まとめる:同じ確認を別の言葉で繰り返している
削る:目的がなく、完了条件もなく、他の確認で代替できる

たとえば、次のように分けます。

元の項目 判断 反映先
公開範囲が全体公開か確認する 残す 共通チェック
取材音声の話者名を照合する 記事別へ移す 取材記事チェック
数字を確認する / 日付を確認する / 料金を確認する まとめる 数値・日時・料金を一次情報と照合
全体的によく読む 削る 具体的な校正項目で代替

記事別へ移すことは、重要度を下げることではありません。必要な場面でだけ表示し、確実に実行しやすくする整理です。

確認項目を残す、記事別へ移す、まとめる、削るに分ける

残す項目は「頻度」と「影響」を分けて考える

よく起きる誤りだけを残すと、頻度は低いが重大な事故への備えがなくなります。そこで、発生頻度と見逃したときの影響を分けます。

頻度 影響 扱い
高い 大きい 共通の必須項目に残す
高い 小さい まとめるか自動検査へ移す
低い 大きい 公開ゲートとして残す
低い 小さい 記事別メモへ移すか削る

個人情報、未公開情報、公開範囲、直接引用の誤りは、毎回起きなくても影響が大きい確認です。一方、句読点の揺れや空行の数は重要ではありますが、自動検査や文章校正へ移しやすい項目です。

ここで「AIが確認するから削る」とは考えません。AIの出力も確認対象です。機械的に判定できるものを自動検査へ移し、人間には意味や公開可否の判断を残します。

重複した項目を1つの確認動作へまとめる

チェックリストが長くなる原因の1つは、同じ問題を別の表現で追加することです。

- [ ] 日付を確認した
- [ ] 開催日を確認した
- [ ] 受付開始日を確認した
- [ ] 画像内の日付を確認した
- [ ] SNSの日付を確認した

これを1行へ縮めるだけでは、対象が消えてしまいます。そこで、確認動作と対象をセットにします。

- [ ] 確定した日時を、本文・画像・SNS下書きで全文検索し、一次情報と照合した

必要なら、手順書に検索対象や確認方法を書きます。チェックリストには短い実行項目、手順書には詳しい方法、記事別メモには今回の値を置きます。

チェックリスト:何を確認するか
手順書:どう確認するか
記事別メモ:今回、何と照合したか

役割を分けると、チェックリストを短くしても確認内容を失いません。

自動検査へ移せる項目を分ける

毎回同じ方法で判定できる項目は、スクリプトやツールへ移せます。

  • 画像URLが指定本数あるか
  • リンクがHTTPエラーになっていないか
  • タグ数が上限以内か
  • 禁止語や仮置き文字が残っていないか
  • タイトルと管理表が一致しているか
  • 同じ日に公開候補が複数ないか

ただし、自動検査が成功しても、記事の事実が正しいとは限りません。URLが開くことと、そのページが主張の根拠になることは別です。

人間に残すのは、次のような意味の判断です。

  • 出典が主張を本当に支えているか
  • 「予定」を「決定」と書いていないか
  • 引用が発言の意味を変えていないか
  • 公開してよい情報か
  • 訂正や公開を実行してよいか

AIやスクリプトは確認量を減らせますが、Human Approvalの代わりにはしません。

AIには削除案と根拠を出してもらう

AIへ「チェックリストを短くして」とだけ頼むと、重要な項目まで文章上の重複として消す可能性があります。

私は、判断表を作らせます。

次のチェックリストを整理してください。

各項目について、次を表にしてください。
- 現在の文言
- 対象となる記事
- 防ぎたい誤り
- 完了条件
- 重複する項目
- 残す / 記事別へ移す / まとめる / 削る の提案
- 提案理由

条件:
- 個人情報、未公開情報、公開範囲、直接引用、Human Approvalは削除しない
- 根拠が不明な項目は削除せず「確認待ち」にする
- 最終的な削除や運用変更は行わない

AIには候補の整理を任せ、人間が影響を判断します。削除理由を残せば、後から「なぜこの確認がないのか」を説明できます。

削除ではなく、1回休止する方法もある

必要性が分からない項目は、すぐ完全削除せず、一定期間だけ休止できます。

項目:記事内のすべての見出しを20文字以内にする
状態:休止
理由:誤り防止との関係が薄く、記事ごとの表現を制限するため
確認期間:次の5記事
再開条件:長い見出しが原因で表示や理解に問題が出た場合

休止中も履歴には残します。ただし、公開前の実行リストからは外します。次の数記事で問題がなければ削除し、問題が出れば具体的な完了条件を付けて戻します。

この方法なら、「念のため」で永久に残る項目を減らせます。

見直し後は小さなチェックリストで試す

一度に完全版を作ろうとせず、次の記事で使います。

整理、試用、記録、更新の小さな循環でチェックリストを育てる

## 共通の公開前チェック

- [ ] タイトル、本文、管理表が一致している
- [ ] 数値・日時・料金・固有名詞を一次情報と照合した
- [ ] 引用を元資料と照合し、意味を変えていない
- [ ] 個人情報・未公開情報・認証情報が含まれていない
- [ ] 画像、リンク、タグを自動検査した
- [ ] 公開範囲、投稿先、実行内容を人間が承認した

取材記事なら、ここへ取材用の項目を追加します。アプリ紹介なら、動作確認日や対象Versionを追加します。すべての記事へ同じ長い一覧を押し付けません。

実施後は、次の3点だけ記録します。

見つけた問題:
使わなかった項目:
次回の変更:

問題を見つけた項目は残す候補です。使わなかった項目は、対象が違ったのか、不要なのかを分けます。新しい項目を追加する場合は、既存項目へまとめられないかを先に確認します。

チェック数を成果にしない

20項目すべてに印が付いていても、根拠を見ずに流れ作業で確認したなら安全とは言えません。反対に、6項目でも、重要な事実と公開境界を確実に確認できるなら実用的です。

見るべきなのは、項目数ではなく次の状態です。

  • 各項目に防ぎたい誤りがある
  • 完了条件を説明できる
  • 必要な記事で表示される
  • 自動検査と人間の判断が分かれている
  • 確認できないときに止まれる
  • 変更履歴とHuman Approvalが残る

チェックリストを短くするのは、確認を省くためではありません。重要な確認へ注意を戻すためです。

まとめ

記事のチェックリストが増えすぎたら、残すか削るかだけで決めません。

  • 最初にチェックリストの目的を固定する
  • 実際に使った結果と完了条件を見る
  • 残す、記事別へ移す、まとめる、削るに分ける
  • 発生頻度と見逃したときの影響を分ける
  • チェックリスト、手順書、記事別メモの役割を分ける
  • 機械的な判定は自動検査へ移す
  • AIには削除ではなく判断表を作らせる
  • 不明な項目は休止して次の記事で試す
  • 項目数ではなく、止まれる確認になっているかを見る

AIは重複の発見や分類を助けてくれます。しかし、どのリスクを受け入れ、どの確認を公開ゲートに残すかは人間の判断です。

長い一覧を守ることより、重要な項目を本当に実行できることを優先する。そうすると、チェックリストは反省の置き場ではなく、次の記事を安全に公開するための道具へ戻ります。

次回は、AIと人間で公開前チェックを分担するとき、どこまで自動化し、どこをHuman Approvalとして残すかを整理します。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?