クイックサマリー: 本記事は、Claude Codeの作業セッションをZenn記事の下書きに変換する自作スキル「zenn-writeup」（旧称: article-writeup）の再設計プロセスを扱った実例解説です。対応CLIはClaude Codeで、AI生成記事の捏造・誤帰属を検出する「ファクトチェック機構」の設計パターンと、スキルそのものを作り直す判断基準が学べます。
Claude Codeで記事生成やドキュメント生成のスキルを自作したものの、「出力の品質がいまひとつ伸びない」「AIが書いた内容に事実と異なる記述が紛れ込む」と悩んでいませんか。機構を改善しても手応えが出ないとき、原因はスキルの性能ではなく、もっと手前の「前提」にあるかもしれません。
Zennで公開されたyusukekcode氏の記事「直したのはバグではなく前提だった」は、まさにこの課題に正面から向き合った開発記録です。ファクトチェック機構の追加という技術的な改善から始まり、最終的には「そもそも誰に何を書くのか」という前提の見直しに至るまでの過程が具体的に記録されています。
- AI記事生成スキルに「ファクトチェック機構」を組み込む設計パターン
- 捏造・誤帰属を実際に検出できた検証手順（既知の失敗ケースを使ったテスト）
- 自作スキルを「直す」か「作り直す」かの判断基準
- subagent-driven-developmentによる実装フローの実例
なお、zenn-writeupスキル自体は記事著者の個人スキルであり、2026年7月時点でパッケージとして一般配布されているものではありません。本記事では、その設計思想を自分のClaude Code環境に応用する方法を中心に解説します。
zenn-writeupスキルとは何か — 経緯と再設計の全体像
元記事によると、zenn-writeupは「Claude Codeでの作業セッションをそのままZenn記事の下書きに変換する」自作スキルです。当初はarticle-writeupという名称で運用されていましたが、再設計を経てスキル名がzenn-writeupへ、リポジトリの内部名称もwritingsからzenn-contentへと変更され、Zenn特化の設計に作り直されました。
再設計のきっかけは、重大な欠陥の発見でした。記事化のための振り返り・インタビュー内容をまとめた「ブリーフ」がその場限りで消えてしまう設計だったため、下書きに紛れ込んだ捏造や誤帰属（実際には別の人がやったことを自分がやったかのように書いてしまう記述）を後から検証する手段がなかったのです。
興味深いのは、この欠陥の修正自体はすぐに成功したにもかかわらず、著者の「良い記事が作れていない」という手応えのなさは解消されなかった点です。最終的な結論は「Zennの読者は開発者であり、セッションを物語やシリーズとして記事化しようとしていたこと自体が誤りだった」という前提レベルの見直しでした。1本の記事はそれ単体で読者の役に立つべき、という原則の再確認です。
ファクトチェック機構の設計 — 捏造2件を実際に検出した仕組み
本記事で最も実用価値が高いのは、AI生成記事の事実検証を仕組み化した部分です。設計の核心は次の2点にまとめられます。
- ブリーフの永続化: インタビュー・振り返りの内容をbrief.mdとしてファイルに保存し、検証の原本として残す
- 独立したファクトチェック工程: SKILL.mdにファクトチェックレビューの工程を新設し、ブリーフの原本と下書き本文を照合する
元記事では、この仕組みが機能するかを「既知の失敗ケース」で検証しています。過去に誤帰属が見つかっていた公開前の下書きに対してファクトチェックレビューを実行したところ、既知の誤帰属に加えて、それまで記録されていなかった捏造が2件新たに検出されました。さらに公開済みの過去記事2本を並列のサブエージェントで再検証した結果、1本から捏造2件が見つかり修正できたと報告されています。
なぜ既存のレビューでは検出できなかったのか
元記事の指摘で重要なのは、「読者目線・編集者目線のレビューは下書きの本文しか読まないため、捏造や誤帰属を検出できない」という構造的な限界です。本文だけを読むレビューが判定できるのは「良い文章かどうか」であって、「書かれている内容が事実かどうか」は別の仕事になります。この分離は、AI生成コンテンツを扱うすべてのワークフローに応用できる知見と考えられます。
自分のClaude Codeスキルに応用する手順
zenn-writeup自体は配布されていないため、ここでは公式ドキュメントに基づく一般的なClaude Codeスキルの仕組みを使って、同じ設計パターンを自分の環境に組み込む方法を示します。Claude Codeのスキルは、プロジェクト配下の.claude/skills/<スキル名>/SKILL.mdにMarkdownファイルを配置することで認識されます（詳細はClaude Code公式ドキュメントを参照）。
.claude/skills/my-writeup/
├── SKILL.md # スキル本体（工程の定義）
└── briefs/ # ブリーフの永続化先（例）SKILL.mdに組み込む工程の構成例
元記事の設計を一般化すると、記事生成スキルには次の工程を含めることが有効と考えられます。
- 工程1: ブリーフ作成 — インタビュー・振り返りの内容をbrief.mdとして必ずファイルに保存する（会話ログ任せにしない）
- 工程2: 下書き生成 — ブリーフを入力として下書きを生成する
- 工程3: 品質レビュー — 読者目線・編集者目線で本文を評価する
- 工程4: ファクトチェックレビュー — 工程3とは独立に、brief.mdの原本と本文を照合し、ブリーフに書かれていない事実の記述を検出する
ポイントは工程3と工程4を分けることです。1つのレビューに両方を任せると、文章品質の評価に引きずられて事実照合が疎かになる構造的リスクがあります。
実開発フローでの活用 — subagent-driven-developmentの実例
元記事は、再設計の実装プロセス自体もClaude Codeの実践例として参考になります。著者は設計書と実装計画を作成した上で作業を8つのタスクに分割し、subagent-driven-development（サブエージェントに実装を委譲し、レビューサイクルを回す開発フロー)で実装を進めたと述べています。
また、公開済み記事の再検証では並列のサブエージェントを活用しており、複数の成果物に同じ検証を一括適用する場面でのサブエージェント並列実行という定番パターンが実地で使われています。テクニカルライターであれば過去記事の一括ファクトチェックに、開発チームであればリリースノートやドキュメントの事実照合に、ブログ運営者であればAI生成下書きの公開前検証に、それぞれ同じ構造を転用できると考えられます。
もう一つ注目すべきは、AIとの「壁打ち」の使い方です。著者が「正直、このスキルが最良なものかわからなくなった」と率直に問いかけたところ、Claudeも「n=1の失敗事例だけを根拠に専用の仕組みを常設しようとしているのではないか」という自己懐疑を返し、これが機構の追加ではなく前提の見直しにたどり着く助けになったと記されています。改善案を積み増す前に、迷いそのものを言語化してAIに投げるという使い方は、スキル開発に限らず有効な実践と考えられます。
類似ツール・代替アプローチとの比較
Zenn記事の執筆を支援するツールは他にも存在します。zenn-writeupのアプローチが担う領域と、公式・準公式ツールの守備範囲は異なるため、併用が現実的です。
| ツール名 | 対応CLI・環境 | ライセンス | 最終更新 | 特徴 |
|---|---|---|---|---|
| zenn-writeup（本記事の題材） | Claude Code | 個人スキル（非配布） | 2026年（元記事公開時点） | 作業セッション→記事下書き変換。ブリーフ永続化＋ファクトチェック工程を持つ |
| Zenn CLI（zenn-editor） | Node.js（npm） | 公式リポジトリで確認 | 公式リポジトリで確認 | Zenn公式。ローカルでの記事作成・プレビュー・GitHub連携公開 |
| Zenn VSCode Web拡張（β） | github.dev（ブラウザ版VSCode） | 公式リポジトリで確認 | 公式リポジトリで確認 | Zenn公式のβ版拡張。GitHub上で記事の作成・プレビューが完結 |
Zenn CLIは公式ドキュメントによるとnpx zenn new:articleで記事の雛形（タイトル・絵文字・トピック等のFront Matter付きMarkdown）を生成できます。つまり「執筆環境の整備」はZenn公式ツールが、「内容の生成と事実検証」は自作スキルが担う、という役割分担になります。
注意点・制約 — 導入前に知っておくべきこと
- スキル本体は入手できない: zenn-writeupは記事著者の個人スキルで、GitHub等での一般配布は確認できません（2026年7月時点）。本記事で紹介した設計パターンを参考に自作する形になります
- ファクトチェック機構は万能ではない: 元記事でも、記事の主張の核を見直すべきだと気づいたのは「機構ではなく自分自身だった」と明記されています。機構が検出できるのは「ブリーフとの不一致」であり、記事の価値そのものは判定できません
- 外部通信・データ送信: この設計パターン自体はローカルファイル（brief.md）の照合で完結しますが、Claude Code経由の処理内容はAnthropicのAPIに送信されます。業務上の機密を含むセッションを記事化する場合は、所属組織のポリシーを確認してください
- n=1の教訓である点: 元記事自身が「n=1の失敗事例だけを根拠に専用の仕組みを常設しようとしているのではないか」という自己懐疑を記録しています。自分のワークフローに移植する際も、まず既知の失敗ケースで効果を検証してから常設化する順序が推奨されます
まとめ — 機構より先に前提を疑う
本記事の要点は次の3点です。
- AI生成記事の捏造・誤帰属は、本文だけを読むレビューでは検出できない。ブリーフ（原本）の永続化と、原本・本文を独立に照合するファクトチェック工程の分離が有効で、元記事では実際に捏造2件の新規検出に成功している
- 機構の改善で手応えが出ないときは、「そもそも誰に何を書くのか」という前提を疑う価値がある。元記事はスキル名の変更を伴うZenn特化の全面再設計に至った
- 迷いを率直に言語化してAIに投げる壁打ちは、無難な改善案の積み増しから抜け出すきっかけになり得る
元記事の全文はZennの原文で読めます。前作にあたるarticle-writeupスキルの進化についての記事と合わせて読むと、設計変遷の全体像が把握しやすくなります。スキルの自作方法についてさらに詳しくは、Claude Code公式ドキュメントのスキル関連ページを参照してください。
コメント