2026年10月8日に、NIST AI RMF Core、NISTのdeployed AI monitoring report、Google SREのmonitoring chapterを再読しました。AI監視は機能・運用・人の要因・セキュリティ・コンプライアンス・広い影響を分けて考え、ドリフト、分散ログ、人手監視の負担も残ります。SREのlatency・traffic・errors・saturationと尾部遅延、アラート後の人の調査も確認しました。この記事の6 KPIは編集運用の出発案で、0件や短縮率を安全性・品質の証明とは扱いません。
AIで下書きが速くなっても、人の確認や訂正まで増えれば、運用全体が良くなったとは判断できません。公開する量、品質を守る工程、同じ失敗の再発を分けて見ます。
この記事は、文章を企画・下書き・レビュー・公開するチーム向けの設計例です。モデルそのものの性能評価、法令への適合、安全性の認定を六つの数字で代用するものではありません。
30秒で要点
- 六つの指標を出発点に、開始と終了、分母、観測期間、記録担当を先に決めます。
- 速さは品質とセットで見ます。差し戻しの減少だけで、確認が十分だったとは判断しません。
- 要確認箇所は根拠と照合して完了を記録します。未確認の下書きは保留し、公開分の集計と分けます。
- 週次15分は振り返りの案です。重大な問題の対応や必要な調査を、その枠へ押し込みません。
KPIを決める前に、何を守るかをそろえる
NIST AI RMF Coreは、用途やリスクに合う測定、責任の明確化、測れない範囲の記録、継続した見直しを扱っています。ここで示す六つは、その考え方を編集運用へ落とす本記事の出発案です。NISTが指定した必須セットではありません。また、NISTの2026年3月公表記事は、運用監視と人間要因などを別の区分で整理しています。記事の六つの区分と、以下の六つのKPIは別物です。APIが応答したことと、読者へ渡す内容が正しかったことを分けて確かめます。
表が収まらない場合は、横にスクロールできます
| 指標の候補 | 見たいこと | 単独で判断しない点 |
|---|---|---|
| 公開までのリードタイム | 企画から公開までの時間 | 未完了・保留が集計から落ちていないか |
| 差し戻し回数 | 修正の反復とレビュー負荷 | 確認を省いたために減っていないか |
| 重大事故 | 重大度と影響、対応状況 | 件数、影響記事数、観測期間を混ぜない |
| 要確認箇所 | 根拠の照合と保留の状態 | タグを消すだけで確認済みにしない |
| 公開後訂正 | 誤りや誤解が外へ出た経路 | 通常更新と誤りの訂正を分ける |
| 例外集 | 再発への対策と利用 | カード追加数だけで学習成果を認めない |
用途によって、情報漏えい、偏り、権限逸脱、総費用などの確認も必要です。測れる項目だけを選んで、測れない重要なリスクを消さないようにします。
1. 公開までのリードタイム：開始点と未完了を残す
「企画開始→公開完了」か「下書き開始→公開完了」かを決め、比較の途中で変えません。経過時間と人が手を動かした時間も別に記録すると、確認待ちと作業負荷を分けやすくなります。
平均だけでなく、中央値や長くかかった案件の内訳も確認します。Google SREの監視の説明は、平均に隠れる遅い側や、成功と失敗の遅延を区別しています。ここでは編集工程への類推として、公開済みだけが速く見えても、保留が増えていないかを同時に見る考え方を使います。
20〜30%短縮を一律の目標にしません。まず同程度の長さ・難しさ・確認範囲の仕事で基準を取り、改善の余地を探します。モデルや手順を変えた前後で仕事の構成が違えば、時間差をAIの効果と即断できません。
2. 差し戻し回数：理由と確認量を一緒に見る
一つの下書きを「修正して戻す」ごとに一回など、数え方を決めます。小さなコメント十個と十往復を混同しないことが大切です。公開できた本だけの平均にせず、保留や中止に至った仕事も別欄に残します。
次の三分類は、改善箇所を選ぶ出発点として使えます。
表が収まらない場合は、横にスクロールできます
| 理由 | 確認すること |
|---|---|
| 事実・条件の誤り | 資料、日付、条件、根拠の読み違い |
| 構成・分かりにくさ | 読者の疑問、順番、説明の不足 |
| トーン・表現 | 用語、言い切り、読者との距離 |
差し戻しが多い原因は、前提や例外の不足だけとは限りません。難しい案件の増加、レビュー基準の変更、確認の質が上がった場合もあります。分類ごとの件数と、確認に使った時間を見て、少数の実例を読み直します。AIは優秀な新人と例外集の作り方が次の設計に役立ちます。
3. 重大事故：件数、影響記事、追跡期間を分ける
重大度は用途に合わせて先に決めます。価格・規約・条件の重大な誤り、出典のない数値の断定、専門的判断が必要な領域の不適切な断定、公開不可情報、誇大な保証表現などが候補です。すべてを同じ重さとして機械的に数えません。
記録は次の二つに分けます。
- 事故イベント件数：一件の問題として調査・対応した単位。
- 影響記事の割合：同じ公開群のうち重大な問題が見つかった記事数を、重複を除いて公開本数で割る。
同じ記事で問題が二つ見つかっても、影響記事は一つです。公開した週と問題を発見した週も別になります。「この公開群を、公開後の同じ期間だけ追跡した」集計と、「今週発見した問題」の一覧を混ぜないようにします。
未発見・未調査・追跡期間の短い記事があることも残します。観測した事故が0件でも、真の事故リスクが0とは言えません。問題が見つかった際の報告、公開停止や訂正、再確認の担当を決めておきます。AIに任せる範囲で、確定・約束を人が担う設計を確認してください。
4. 要確認タグ：照合済み率と残存率を区別する
要確認タグは、確認すべき主張と根拠を結ぶ目印です。消去操作ではなく、資料と条件を照合した記録によって完了とします。前提設計とAI時代の文章品質管理が確認の土台になります。
同じ対象群の全要確認箇所を分母にする場合、二つの率は次の定義です。
表が収まらない場合は、横にスクロールできます
| 指標 | 計算 |
|---|---|
| 照合済み率 | 照合済み箇所数 ÷ 全要確認箇所数 |
| 残存率 | 未確認箇所数 ÷ 全要確認箇所数 |
図の架空例は、締切時点の20下書きに計60箇所の要確認があり、58箇所を照合済み、2箇所を未確認としたものです。照合済み率は96.7%、残存率は3.3%になります。同じ分母なら両者の合計は100%です。箇所が0なら率を出さず「対象なし」と記録します。
この例では、公開した18本にある54箇所は全て照合済みです。保留した2本に、照合済み4箇所と未確認2箇所があります。全体の96.7%を公開許可の基準にしません。 公開する成果物に必要な確認が終わったかを個別に確かめます。保留を集計から消すと確認負荷も見えなくなるため、残存の件数、対象の下書き、担当と期限を残します。
5. 公開後訂正：通常更新と誤りの訂正を分ける
「公開後に何回編集したか」だけでは、品質は判断できません。新情報を加える通常更新と、誤りや読者の誤解を直す訂正を分けます。
表が収まらない場合は、横にスクロールできます
| 理由 | 記録する例 |
|---|---|
| 事実誤り | 価格・条件の誤りと、確認を通過した経路 |
| 表現の誤解 | 断定の強さ、条件の省略、対象の曖昧さ |
| 情報の古さ | 変更が起きた日、発見日、更新までの期間 |
訂正イベント件数と、訂正が必要だった記事の割合も分けます。同じ公開群・同じ追跡期間で比較し、重複を除いた記事数を使います。新しい記事は発見の機会がまだ短いため、そのまま古い記事と同条件にはできません。
6. 例外集：追加数の先に、使われ方と再発を見る
新規カード数は、対策を記録した量です。これをそのまま「学習率」とは呼びません。カードを増やしても、必要なときに使われず、同じ問題が続く場合があります。
カードには、起きた条件、問題、確認する資料、次回の対応、担当を残します。週次・月次の追加数に加え、実際に参照した仕事、同じ型の再発、未解決の対策を確認します。類似カードを月に一度まとめる案から始めても、頻度は蓄積量に合わせて変えます。例外集の作り方で具体化できます。
数字の組み合わせから、調べる仮説を選ぶ
表が収まらない場合は、横にスクロールできます
| 観測した変化 | 調べる候補 |
|---|---|
| 時間は短くなったが重大事故が増えた | 確認や権限の変更、入力資料、仕事の難しさ、追跡期間 |
| 差し戻しが減らない | 理由の偏り、前提・例外の不足、基準の変更、案件構成 |
| 公開後訂正が増えた | 更新日、数値・条件の照合、確認工程、古い公開群の発見 |
これは原因を確定する表ではありません。対象の実例を読み、手順や担当の変化と照らしてから次の改善を選びます。
週次15分の振り返りを、対応の代わりにしない
小さなチームなら、次の表を事前に埋め、週次15分程度の会議で改善案を一つ選ぶところから始められます。調査、再確認、訂正に必要な時間は別に確保します。重大な問題は定例を待たず対応します。
表が収まらない場合は、横にスクロールできます
| 項目 | 記録欄 |
|---|---|
| 対象群・期間・追跡期間・担当 | ____ |
| 公開本数／保留本数／中止本数 | ____ / ____ / ____ |
| リードタイムの開始・終了、平均・中央値、未完了 | ____ |
| 差し戻し回数・理由・レビュー時間 | ____ |
| 重大事故件数／影響記事数／対応状況 | ____ |
| 要確認箇所の全数／照合済み／残存、担当・期限 | ____ |
| 公開後訂正件数／影響記事数、通常更新 | ____ |
| 例外集追加／利用／再発／未解決対策 | ____ |
| 今週試す改善、悪化時の停止・見直し条件 | ____ |
例えば、価格の確認担当を決める、資料の入口を整理する、再発した条件を例外カードへ加える、といった一つの変更を選びます。一つに絞るのは小さく比較するための案で、同時に対応すべき重大な問題を放置する理由にはしません。
次の設計へつなぐ
品質の確認事項はAI時代の文章品質管理、確認の段階とコメントはAIレビューの設計、権限はAIに任せる範囲、再発への対策は例外集の作り方で整理できます。
指標の名前を増やす前に、対象群・分母・期間・担当をそろえます。速さ、確認負荷、公開後の影響を一緒に見て、続ける変更と見直す変更を判断してください。