zenn-editorial-judgment

name	zenn-editorial-judgment
description	Zenn/Dev.to 記事で著者（shimo4228）の編集判断を再現する判断ゲート集。執筆タイムライン順に — 書く前の記事タイプ判定（how-to / 立場表明 / ツール実測レポート）と装置（掴みの形式・判断表・任意のわかること行）の採否、粒度判断（分割より統合）、軸ずれ検出（自分の環境の出来事は素材であって軸でない。内部語彙の密度が検出器）、執筆中の著者事実の確認・数値の実測主義・訳語運用・フレーム再交渉、レビュー通過後の構造自己審問（一般則と筆者事情の区別・骨格宣言・判断の地図は前方・比較対象を dismiss しない）・通読ゲート・レビュー指摘の採否、主張型記事の業界 Deep Research 裏取りとクレーム校正。Use when — 新規記事の構成案を作る前（タイプ判定が最初）、改稿するとき、レビュー指摘の採否を決めるとき、「軸がずれてる気がする」「この記事は誰向けか迷う」とき、全レビューエージェント通過後の最終著者パス。NOT for — 文体・実用軸 5 ルール・段落密度 → zenn-practical-writing、価値観の背景 → zenn-authorial-values、タイトル生成 → headline-craft / seo-optimizer、機械チェック → quality-gate、公開手順 → publish-article。
user-invocable	true
origin	shimo4228

zenn-editorial-judgment — 著者の編集判断ゲート集

根拠: ADR-0006。各ゲートの「なぜ」は zenn-authorial-values（価値観 8 項）が正本 — ここには再掲しない。

執筆タイムラインに沿って「いつ・何を判断するか」を並べる。これは著者判断の再現装置であり、機械 gate ではない（quality-gate に組み込まない — 装置を義務化するとチェックリストを埋めるための部品追加が起きる。それ自体がこのスキルが防ぐ失敗）。

---

Phase 0: 記事タイプの事前判定（構成案より前・最初のゲート）

構成案を書く前に「この記事は読者の問題を解決する記事か、著者の立場を表明する記事か」を 1 行で宣言する。タイプで装置の採否が変わる。

タイプ	例	装置（掴みの形式・判断表・診断コマンド・任意のわかること行）
how-to / reference	手順・逆引き・設定ガイド	原則すべて採用（zenn-practical-writing の既定）
ツール実測レポート	新ツールを使ってみた実測	採用。ただし軸は「読者がこのツールを試す判断に使えるか」（下記「軸の設定」）
立場表明・マニフェスト	シリーズ #0、宣言、思想の表明	全部外す。声（ですます・低認知負荷）だけ適用。導入は告白・宣言から始めてよい。構成は writing-ecosystem の「エッセイの 4 段構成（Hero's Journey 型）」が使える

• 立場表明に読者問題フレームを被せない — 問題文に著者の造語（「〜縛り」「〜の軸」）が入っていたら、読者の問題を捏造している危険信号（実例: small-llm-by-choice #0 の二段階修正）
• how-to でも装置は判断で採否を決める。チェックリストを埋めるために部品を足さない
• タイプによらず、導入の既定は「引き込み（掴み）→ 緊張 → 解決 → Higher Ground」（正本: zenn-practical-writing「導入の設計」/ writing-ecosystem「エッセイの 4 段構成」。2026-07-30 Kaguura 原則の取り込み）

粒度判断も同時に行う: 隣接ネタが既にあるなら、分割より 1 本への統合を第一候補にする（「シリーズにするより質の高い記事を投稿する方が信頼される」）。シリーズ化は分量が本当に 1 本に収まらないときの手段であり、完結編が初作を supersede した前例がある（memory article-quality.md シリーズ重複メモ）。

判定: 構成案の冒頭に「タイプ: ◯◯／装置: 採用・免除／統合候補: あり・なし」を 1 行書いたか。

軸の設定: 自分の環境の出来事は素材であって軸でない

素材が「自分の環境で起きたこと」のとき、それを証拠として使う別の主語を探す（例: 「自作 hook に穴があった」→ 主語をツールに移すと「このスキャナは自然言語の指示ファイルまで監査対象にする」の実証になる）。

• 内部語彙の密度を検出器に使う — 造語・内部略語・自分のファイル名・finding 番号が本文に多いほど、軸が自分側に寄っている。軸を読者側に付け替えるとこれらは自然に落ちる（実測: 16 個の finding 番号と 3 種の内部語が軸変更で全消滅）
• 軸を変えたら素材の取捨も変わる — 新しい軸に効かない素材は落とし、軸に効く素材（例: 「レポートの推奨をそのまま採らなかった」はツールの使い方の話）を残す

判定: 内部語彙（造語・内部略語・内部ファイル名・番号）をリストアップし、「読者の判断に使える主語」に付け替えて消えるか確認したか。

執筆中の判断

フレーム再交渉

執筆過程で著者の思考が整理され、核心が変わることがある。核心のズレを検知したら、ドラフト構成案に固執せずフレーミングの修正を積極提案する（構成案は着手前の承認物だが、writing-as-thinking の産物が勝る。実例: Chaos Engineering → fault injection testing へのクレーム軌道修正、承認ゲート記事の全面再構成）。

著者の事実の確認（捏造検知）

記事中の「私」の記述 — 著者の行動・呼称・経緯・環境 — は事実でなければならない。著者がした覚えのないことをもっともらしく書かない。素材に根拠のない「私」の記述（「私はこれを◯◯パターンと呼んで運用しています」「iPhone で音声入力」等）を書く前にユーザーに確認する。良い提案なら記事に書く前にまずハーネスに取り入れて実態を作る（→ values 7 項「記事とハーネスの整合」）。

数値の実測主義

記事に載せる数値（所要時間・件数・カバレッジ）は実測値のみ。特に時間見積もりは書かない（「Claude の時間見積もりはいつも何倍も長い」）。集約カウントは記憶や下書きから引き写さず、執筆時に live コマンドで再実測する。

具体性の取捨（伝わりやすさ軸）

実名・実データの使用許可が出ても、それは「公開して問題ないか」の判断。「記事にどこまで書くか」は独立に「この論点を支えるのに必要な最小限の具体性は何か」を先に問う。insider-context な用語（ADR 番号・内部関数名・フィールド名）は論点を支える分だけ残す。「具体的にすぎて情報過多になるなら無理に出さなくていい」。

訳語・用語の運用

zenn-practical-writing「専門用語の緩和策 7 手」の運用補足:

• 訳語ライフサイクル — 英語専門語は初出で「原語（日本語訳）」の対応を作り、以降は日本語側を使う（Verdict → 判定、holistic → 全体論的、draft → 下書き）
• 同一物同一語 — 同じ対象の言い換え（「自前ログ」と「既存のログ」）は別物に読まれる。1 語に統一する
• 界隈の現行語彙に合わせる — 読者が検索・購読で使っている語（telemetry 等）を採用する。造語か既存概念かを常に区別し、既存概念なら系譜を初出で明示する

判定（執筆中まとめ）: 根拠のない「私」の記述ゼロ・実測していない数値ゼロ・訳語対応の未定義語ゼロを書きながら維持しているか。核心が変わったと感じたらユーザーに再フレーミングを提案したか。

レビュー後: 構造の自己審問（最終著者パス）

レビューエージェント（editor / fact-checker / zenn-clarity-reviewer / codex-review）は文単位の欠落は拾うが、「記事が何をした話なのか」という骨格の歪みは拾えない。全レビュー通過後に著者パスとして自問する:

1. 一般則と筆者事情を区別しているか — 「〜で決まります」（法則の宣言)は筆者の判断なら「〜で考えました」に。結論の成立条件を明示し、対比表の片側が自分の設計なら列ヘッダに「筆者の」と書く
2. 冒頭キャッチは用語最小限か — 略称・技術用語・売り文句をキャッチに置かない。「可視化」レベルの平易語に落とす
3. 「やったことの骨格」を導入で宣言しているか — 「やったことは 2 つです」形式で行為の全体像を冒頭に平文で置く。これがないと各論が何の一部か読者が組み立てられない
4. 判断の地図（借りる/見送るの一覧表）は前方にあるか — 判断軸の直後に置き、各論を「地図の ✅ の実装」として読ませる演繹構成にする
5. 比較対象を dismiss していないか — 標準を見送る話は「価値がない」に読ませず、「自分の設計を測る物差しとして機能した」という収穫を明示する

通読ゲート: 著者（またはその代行としての自分）が前から順に読み、初出時点で意味の取れない語・節がないか検品する。「私はまだ記事を全部読んでおらず、前から読み進めているが、そこで意味がわからないということは多くの読者も疑問を持つはず」— 途中で立ち止まった箇所は読者の脱落点。

レビュー指摘の採否: 大幅な構成変更後は全エージェント再レビュー、小修正は差分レビューと使い分ける。指摘は全部飲まず、もっともらしい一般論と実運用で確定した固有の判断がぶつかったら、根拠を明文化して後者を取る（→ values 5 項）。

判定: 自問 5 点 + 通読を実施し、レビュー指摘ごとに採用/却下と根拠を記録したか。

主張型記事の裏取り（architectural argument）

業務経験・自環境の経験を一般化して技術設計を主張する記事では:

1. 業界フレームで Deep Research — Anthropic "Building Effective Agents" / OpenAI "A Practical Guide to Building Agents" / Microsoft "Three Tiers of Agentic AI" / Gartner・Thoughtworks の予測批判 / 関連 arXiv 一次資料に必ず当たる
2. verdict（STRONG / MODERATE / WEAK）で一般化を弱める — 過度な一般化には spectrum を認める段落を足す。中核主張が業界 consensus と整合か反かを冒頭で位置づける
3. 経験範囲と業界視点を語彙で分ける — 「私の経験から見える」と「業界 consensus」を区別する
4. 優劣比較でなく必然性論に純化する — 同じタスクで比較実験していない限り「A > B」は根拠なし。「B が必要な状況とは何か」の構造的観察に落とす
5. 引用フレーズは原文一字一句確認 — 「明記している」と書くなら原文を確認する
6. クレーム校正 — 手法名・概念名を名乗るときは正典の要素との対応表で自己判定し、部分適合なら控えめな名前に落とす（実例: Chaos Engineering と言えるか自問 → 正典 4 要素中 1.5 → fault injection testing にクレーム修正。将来拡張の含みは残してよい）

判定: 主張型の節ごとに、出典（一次資料）・経験/業界の語彙区別・必然性論への純化を確認したか。

---

Related

• zenn-authorial-values — 各ゲートの「なぜ」（価値観 8 項）の正本
• zenn-practical-writing — 書き方の正本。Phase 1 の前に本スキルの Phase 0 を通す（立場表明では装置チェック免除）
• .claude/agents/zenn-clarity-reviewer.md — 初見読者の明瞭性（機械側の検査。本スキルの自己審問はその後の著者パス）
• quality-gate — 機械的受け入れ gate（本スキルは統合しない — ADR-0006 Decision 3）
• memory feedback_* 群 — 各ゲートの生事例（originSessionId 付き一次資料）
• 根拠: ADR-0006