2026年10月8日に、NIST AI RMF Core、NISTのAI RMFページ、OpenAIのevaluation best practicesを再読しました。NISTはgovern・map・measure・manageをAIライフサイクルへ継続的に適用し、測れない範囲、責任、文書化、独立レビューも扱います。OpenAIは目的・データセット・指標・比較・継続評価に加え、典型・境界・敵対的ケースと人のラベル付けを挙げています。この記事のGate・Quality・Polishは編集上の分類案で、確認率やAIのタグだけを公開許可へ変換しません。
AIの下書きを見て「何か違う」と感じても、直すべき場所と理由が伝わらなければ、作成者も確認者も同じ修正を繰り返しがちです。一方、確認項目を決めたからといって、AIの誤りや資料の不足が消えるわけでもありません。
文章を社外へ公開するチームなら、最初に「誰に何を伝える原稿か」「どの誤りを防ぐか」「どの品質が必要か」「誰が公開を決めるか」をそろえます。この記事は、そのための編集上の設計例です。チェックリストだけで品質や速度を保証する手法ではありません。
30秒で要点
- Gate・Quality・Polishは、確認項目の優先度を整理する三層の案です。Gateだけで公開できるとは扱いません。
- 要確認タグは補助です。タグのない重要な数値・条件・断定も確認範囲に入れます。
- コメントには項目、具体的な直し方、根拠とその条件を添えます。
- 作成・照合・編集・公開判断を分け、保留や独立確認の限界を記録します。
三層に分ける前に、公開条件を決める
一般向けの記事と、契約条件や安全に関わる説明では、必要な確認が異なります。読者、使われ方、誤りの影響、必要な専門確認を先に決めます。AIの下書きが読みやすくても、条件や根拠が誤っていれば、そのまま公開する理由にはなりません。
NIST AI RMF 1.0のGOVERN 2とMEASURE 1・2は、責任の明確化、用途に合う評価、測定できない範囲、独立した評価の関与を扱います。ここでの三層やタグは、それを文章編集へ応用する本記事の案です。NISTが指定した分類や認証手順ではありません。参照する1.0は2023年1月26日公開の資料です。NISTの公式概要は、2026年10月4日の確認時点で改訂中と表示しています。確認日を資料の新規公開日と混同せず、改訂版が出たと仮定して書き換えません。
表が収まらない場合は、横にスクロールできます
| 層 | 確認すること | 公開判断との関係 |
|---|---|---|
| Gate：重大な問題 | 重要な事実、条件、権限、公開不可情報 | 問題や重要な未確認が残れば保留 |
| Quality：必要な品質 | 読者が理解し、条件を誤解せず判断できる説明 | 用途に必要な水準は公開前に満たす |
| Polish：任意の磨き込み | 必須でない表現の洗練や追加例 | 重要な確認を圧迫しない範囲で選ぶ |
専門用語の説明や読者が使える表現は、場合によっては必要なQualityです。「磨き込み」と分類したことを理由に、読者に必要な配慮を落とさないようにします。
1. Gate：重要な未確認を公開へ持ち越さない
以下は確認項目の出発点です。社内の公開基準や必要な専門判断に合わせて追加・変更します。
- [ ] 価格・条件・規約の主張を、対象と確認時点まで含めて照合した
- [ ] 数値・統計の出典と分母、単位、対象期間を確認した
- [ ] 法務・医療・金融などで必要な専門確認を、一般的な文章チェックで代用していない
- [ ] 成果保証、根拠のない断定、過大な効果説明がない
- [ ] 公開不可情報や、公開許可がない固有情報を含めていない
- [ ] 一次資料の内容と矛盾せず、資料から言えない範囲を明示した
重要な未確認があれば公開を保留します。資料を補う、主張の範囲を狭める、確認できない主張を削るなどして直し、最終の原稿を改めて確認します。「要確認」と書き添えただけで、そのまま社外へ公開してよいことにはなりません。
権限と責任の設計はAIに任せる範囲の決め方、資料と文章品質の関係はAI時代の文章品質管理と合わせて点検できます。
2. Quality：読者が判断できる説明をそろえる
事実が正しくても、必要な条件が見つからない文章では、読者が誤った使い方をする可能性があります。次の項目を、原稿の目的に合わせて確認します。
- [ ] 目的と読者の問いが冒頭で分かる
- [ ] 前提・制約・適用できない条件が分かる
- [ ] 結論、理由、手順、確認する点がつながっている
- [ ] 抽象語だけで済ませず、具体例とその範囲を示している
- [ ] 次に取る行動が分かり、必要な情報へ進める
- [ ] 本文、表、図、FAQの説明が矛盾しない
Qualityの合格水準は、公開前に決めます。読者が条件を誤解しやすい説明を残したまま、Gateだけを理由に公開しないことが大切です。
3. Polish：任意の改善を必須確認と分ける
表現を短くする、見出しを整える、例を増やすなどの磨き込みは有用な場合があります。ただし、必要な確認を後回しにしてまで増やすものではありません。
- [ ] 必須の説明を落とさず、冗長な文を整理する
- [ ] 用語の説明が足りているかを見直す
- [ ] 見出しから、その節で分かることが伝わる
- [ ] 具体例が対象読者に合う
- [ ] 読者の疑問や反論に、根拠の範囲で答える
このうち必須の分かりやすさに関わる項目はQualityへ移します。三層は仕分けの道具であり、項目の名前だけで重要度が決まるわけではありません。
要確認タグは、確認対象を絞り切るためのものではない
AIには不確かな箇所へタグを付けるよう指示できます。しかし、AIが不確かさを自覚せず、タグを付け忘れる可能性もあります。レビュー担当は全文から重要な主張を拾い、タグの有無と別に根拠を調べます。
表が収まらない場合は、横にスクロールできます
| タグの例 | 人が残す確認記録 |
|---|---|
| 【要確認：価格／条件】 | 公式条件、対象プラン、確認日、適用範囲 |
| 【要確認：規約／法務】 | 文書の該当箇所、必要な専門確認、担当 |
| 【要確認：数値／出典】 | 一次資料、分母・単位・期間、計算 |
| 【要確認：公開可否】 | 公開権限、含められない情報、判断者 |
| 【要確認：最新性】 | 公開・更新日、確認した版や条件 |
タグを外すときは、「資料と照合した」「条件付きに直した」「未確認の主張を削除した」など、何をしたかを残します。タグを消す操作だけを照合完了と数えません。
OpenAIの評価設計ガイドも、用途に合う評価、人の判断、通常の例だけでなく境界や不利なケースを扱います。これはモデルやシステムの評価についての資料で、タグ方式を指定したものではありません。編集運用では、タグのない問題も見つけられるかを人が点検する案として使います。架空12主張の例：タグ数と照合状況を混ぜない
ある下書きから確認対象の重要な主張を12件拾った、という教材例です。実測値ではありません。
表が収まらない場合は、横にスクロールできます
| 集計の軸 | 内訳 | そこから分からないこと |
|---|---|---|
| タグの有無 | タグ有5件、タグ無7件 | どの主張が照合済みか |
| 根拠との照合 | 照合済み10件、重要な保留2件 | 確認範囲に漏れがないか |
照合済みは10/12＝83.3%ですが、重要な保留2件が残るなら公開を保留します。確認率の高さを公開許可の代わりにしません。そもそも12件の拾い方に漏れがないかも別に点検します。
コメントは「項目・修正・根拠」で具体化する
「もっとプロらしく」だけでは、直す場所と合格条件が分かりません。次の三点を結ぶと、修正の意図を共有しやすくなります。
表が収まらない場合は、横にスクロールできます
| 項目 | 書くこと |
|---|---|
| どの条件か | Gate／Quality／Polishと該当項目、原稿内の場所 |
| どう直すか | 削除、条件の追加、計算の修正、説明順の変更など |
| 何を根拠にするか | 一次資料の該当範囲、確認日、そこから言えないこと |
例えば「Gate・数値の条件。『必ず半減』を削り、この資料の対象と期間に限った結果へ修正。参照は公式報告の該当節。別の現場への効果は未確認」と伝えます。これはコメントの書き方の例で、実際の半減結果を主張するものではありません。
形式をそろえても、参照資料の読み違いや誤った修正は起こりえます。直した後の本文、図、FAQを再確認します。
役割を分け、自己確認と独立確認を区別する
下の表は責任を見える形にする最小の例です。各作業の実行・最終責任・相談・共有をすべて割り当てた完全なRACI表ではありません。
表が収まらない場合は、横にスクロールできます
| 役割 | 主な仕事 | 権限と限界 |
|---|---|---|
| Owner | 確認結果と用途を踏まえた公開判断 | AIの自己判定だけで公開しない |
| Fact-check | 数値・条件・根拠の照合 | 確認できない範囲を残す |
| Editor | 構成、説明、図とFAQの整合 | 事実の正しさや専門判断を見た目で代用しない |
| AI | 下書き、整形、確認候補の提示 | 自らの出力の公開許可を自分で与えない |
一人で複数の役割を担う場合も、工程ごとに記録を分けられます。ただし、その自己確認を独立レビューとは呼びません。影響の大きい事項は必要な専門家や別担当に確認を求め、確認できなければ保留する範囲を決めます。
週次KPIから、原因を決めつけずに改善点を探す
レビューが重い理由は、手順、資料、モデルの誤り、仕事の難しさ、人手など複数ありえます。サインと原因を同一視しないことが大切です。
表が収まらない場合は、横にスクロールできます
| サイン | 点検する候補 |
|---|---|
| 差し戻しが多い | 依頼条件、資料、AIの誤り、コメントの曖昧さ |
| Gateの問題が見つかる | 公開条件、照合範囲、担当・権限、資料の読み違い |
| 公開後訂正が増える | 無タグの確認漏れ、資料更新、最終原稿の再確認 |
| 確認待ちが長い | 未確認の種類、外部依存、担当の負荷、仕事の構成 |
同じ対象と期間で、差し戻し、保留、確認時間、公開後訂正を見ます。差し戻しの減少だけで品質改善を認定せず、確認量を減らしたためではないかも調べます。重大な問題を週次の会議まで待つ必要はありません。
公開責任と測定をつなぐ
最初の一原稿で、公開条件、重要な主張の一覧、根拠、保留、確認担当を記録してみます。必須確認を減らすことを前提にせず、何が重複し、どこで情報待ちになっているかを点検します。
権限はAIに任せる範囲、文章の条件はAI時代の品質管理、分母と保留の集計はAI運用のKPIへ進めます。依頼の不足は質問テンプレ、再発防止の記録は例外集を参考に、用途に合う手順へ調整してください。