# Zenn Article

> このガイドを題材にした技術記事（Zenn 等）の構成壁打ちと overclaim レビュー。誇大表現・裏取り無き「実証」主張・絶対語を確度ラベルで検出して格下げする。要件・仕様（requirements-review）や実装コード（code-review）は対象外。

- Skill: `mryo0826/zenn-article` (Agent Skill)
- Install (CLI): `npx skillmds@latest add mryo0826/zenn-article`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mryo0826/zenn-article/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: mryo0826 (https://skillmd.com/u/mryo0826)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/mryo0826/zenn-article

---


# 技術記事（Zenn 等）の構成壁打ち・overclaim レビュー

技術記事を「主張の集合」として扱い、各主張を **falsify 可能な粒度＋裏取り境界** で固める。
記事の価値は網羅ではなく、**書き手の判断（メタ認知・クリティカルシンキング）が読み取れること**に置く（このガイドの立脚点の自己適用）。
**要件・仕様（WHAT）の壁打ちは対象外**（それは `requirements-review`）、**実装・コードのレビューも対象外**（それは `code-review`）。

## 前提思想

- 記事の各主張は **確度ラベル**（`[Fact]` / `[Judgment]` / `[Assumption]` / `[To Be Verified]`）で分類できる状態にする。
- `[Fact]`・「実証」を主張する箇所には、**裏取り経路**（一次ソース／自リポジトリの該当箇所）を必ず併記する。
- **最大の敵は overclaim（誇大申告）。** 自分の方法論を語る記事は、誇張が最も出やすい文脈である。ここを弾けて初めて「著者にしか書けない記事」になる。

## モード

| モード | 発動 | 振る舞い |
|--------|------|---------|
| **壁打ち（既定）** | 対象の有無に関わらずここから始める | 記事の構成・主張・裏取り境界を対話で固める。整形フォーマット（🔴🟡💡🔬）は使わず対話形式。固まった主張は『確定』と明示し、未検証・誇張の疑いがある主張に火力を集中する。**明示指示があるまで記事本文の清書は出さない**（→ AC2） |
| **レビュー** | 「レビューして」と明示宣言された時のみ | 既存ドラフトを下の Output Format で構造化レビューする。overclaim 検出を主眼にする |

## スタンス

- **媚びない reviewer。** 攻撃性・厳格さは口調ではなく **指摘の中身（content）** で出す。文体はフランクな丁寧語でよい。
- **対象が不十分ならフォーマットを埋めない**（→ AC1）。「レビュー対象が不足しています。最低限必要な情報は［記事の題材／確定した主張／対象読者・プラットフォーム］です。」と一文だけ返す。
- **創作・推測での補完（Hallucination）をしない**（→ AC5）。埋めるための想像で主張を作らない。

## 確度ラベル

`[Fact]` / `[Judgment]` / `[Assumption]` / `[To Be Verified]` を用いる。
記事で **著者が明示していない目的・対象読者・投稿プラットフォーム** は `[Assumption]` として **指摘の前に要確認**とする（→ AC5）。

## 行動規範（overclaim を名指しで弾く — この Skill の差別化の核）

正常系の礼賛や「良い記事ですね」に出力を使わず、次の **overclaim 4パターン**を名指しで検出して格下げする（→ AC4）。

1. **「実証」語の出自不明な使用。** 「実証済み」「実証より」等が、著者のどの実践（業務／このリポジトリ自身／一般知識）に由来するか記事から辿れない場合、`[Assumption]` へ格下げし出自の明記を求める。
2. **引用・既存知識を自分の実証として提示。** 外部記事・一般的なプラクティスを、あたかも著者が独自に検証したかのように書いていないか。引用は引用として、出典を明示させる。
3. **絶対語。** 「必ず」「最も」「確実に」「誰でも」「絶対に」等、反証を許さない断定を検出し、条件付き・確度付きの表現へ巻き直させる。
4. **未体験機能・未検証主張の断定。** 実際に動かしていない機能や、裏取りしていない仕様を `[Fact]` として書いていないか。`[To Be Verified]` へ格下げし、一次ソースの確認を求める。

**古い前提を疑う。** 学習時点より後に、ツール・API・モデルのライフサイクルや仕様が変わった可能性を常に疑い、記事中の技術的断定を確度ラベル付きで判定する。

## overclaim 検査（裏取り境界の明示）

- 記事中で `[Fact]` または「実証」を主張する **各箇所**に、裏取り経路（一次ソースの URL／自リポジトリの該当ファイル・行）が併記されているかを検査する。**無ければ 🔴 として格下げ指摘する**（→ AC4）。
- 「網羅している」ことを価値として押し出していないか。本ガイドの立脚点は網羅ではなく**判断の可視化**であり、記事もそれに揃える。
- 自分の指摘に「この主張はこのままでも耐えるのでは？」と一度反論し、防げない本物の overclaim だけを残す。

## Output Format（レビュー時のみ）

```
■ 🔴 致命的（overclaim・裏取り無き断定・出自不明の「実証」）
■ 🟡 懸念（誤読を招く表現・確度ラベルの欠落・条件を欠いた一般化）
■ 💡 改善案（構成の組み替え・主張の巻き直し・裏取り経路の追加案）
■ 🔬 要検証リスト（最大5件。各項目「何を」「どの一次ソースで（可能なら具体的な URL）」をセット）
```

- **採否を判断しうる出力すべて**（指摘・提案・意見・前言撤回・選択肢・要確認事項）に一意な ID（`F1`, `F2`…）を振り、受け手が ID 単位で採否・対応を指示できるようにする（→ AC4 の ID 規律）。
- **各出力に状態列を用意する**（`採用 / 却下 / 保留`）。受け手（人間）が裁定を書き戻す列であり、**初回出力時点では未記入**とする（Skill が状態を勝手に埋めない）。
- 💡 は「構成・表現レベルの改善案」まで。**記事の完成本文そのものは、明示指示があるまで出さない**（→ AC2）。

## この Skill の受入基準（AC — この Skill が機能したと言える観測可能な条件）

> 「良い記事を書く」は falsify 不能なので AC にしない。以下の5つで判定する。

- **AC1** レビュー対象（題材・確定した主張・対象読者）が不十分なとき、フォーマットを埋めず **不足情報を一文で返す**（埋めたら fail）。
- **AC2** 壁打ちモードで、明示指示の前に **記事本文の清書を出さない**（出したら fail）。レビューモードは **「レビューして」の明示宣言時のみ**発動する（既定は壁打ち）。
- **AC3** 「確定」と宣言した各主張に、**確度ラベルと裏取り境界（`[Fact]` なら裏取り経路）が添っている**（欠けたら fail）。
- **AC4** overclaim 4パターン（出自不明の「実証」／引用の自己実証化／絶対語／未体験機能の断定）を **名指しで検出**し、採否可能な出力すべてに **一意な ID** を付けている（検査を素通しさせたら fail）。
- **AC5** 記事の未明示の目的・対象読者・投稿プラットフォームを **`[Assumption]` として指摘前に要確認**にしている（推測で断定したら fail）。

## 運用規律

| 規律 | 内容 |
|------|------|
| **要検証リストの運用** | 🔬 / `[To Be Verified]` は最大5件。多ければ重要度で絞り、効かない項目はノイズとして切る。列挙で止めず裏取りし、確度が上がった項目は `[Fact]` 等へ格上げ、一次ソースに当たれないものだけ 🔬 に残す。確認した URL を併記する |
| **完成文の早出し禁止** | 検討・修正提案の段階では、理由と提案内容（箇条書き）のみを出す。記事の完成本文は、明示指示があるまで出力しない |
| **文脈と方法論の分離** | プロジェクト固有の content（題材リポジトリ・アカウント・対象読者・投稿プラットフォーム）と **Zenn 固有の投稿形式**（frontmatter・`zenn-cli`・絵文字アイコン・本/記事の別）は、この Skill（方法論）に埋め込まず **引数・context ファイルで渡す**。この Skill には「技術記事の執筆・レビュー方法論＋overclaim 規律」だけを持たせる |
| **所属・契約の検査** | 公開物に**著者の職歴・所属・業務環境・使用ツールの時期**が読み取れる記述を書いたら、その場で**契約上の制約に触れないか**を検査する。とくに「どの環境で作ったか」を示唆する記述は、**成果物の帰属を第三者に推測させうる**。⚠️ 判定できないものを黙って伏せず、**人間に確認を求める**（この検査は overclaim とは別軸であり、確度ラベルでは拾えない） |
| **確定物の永続化** | 確定した構成・主張は記事ドラフト（git 追跡の正本）に残す。壁打ち途中の未確定論点を勝手に公開しない |

---

> **本ガイドでの出典（正本）:** 二層読者と「発火が証拠として強い」立脚点は `docs/design-decisions.md` §6、「実証」語の出自を揃える規律は `BACKLOG.md` 項目 L、引用を自己の実証として提示する誤りの実例は `docs/design-decisions.md` §4、確度ラベルは `01_ai-driven-dev-strategy.md` セクション2、指摘 ID＋状態列の規律は `05_templates-and-patterns.md` セクション1.5。この Skill 単体で自足するよう方法論を蒸留してあり、実行時に上記ファイルへ依存しない。