# Fact Check Ja

> 日本語の技術記事に書く事実を一次情報で裏取りするスキル。数値、性能、バージョン依存の挙動、他ツールとの比較、「できない」という断定、時間で変わる事実など、間違っていると読者が損をする主張を洗い出し、公式ドキュメントや手元の再現で確認する。レビューだけの依頼ではファイルを書き換えず確認カードで返し、修正を頼まれた範囲だけ本文へ反映する。確認できなかったものは主張の範囲を狭めて書き直す。企画カードの「要確認」を消すとき、下書きの技術レビューをするとき、公開前に古くなった記述を見直すときに使う。「この数字合ってる?」「裏取りして」「ソースある?」「この記述まだ有効?」と言われたときも使う。文章の読みやすさは writing-ja、記事の構成と品質バーは blog-writing-guide-ja の担当である。

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

---


# fact-check-ja — 記事の事実を一次情報で確認する

記事の信頼は、一箇所の間違いで落ちる。読者は誤りを見つけた時点で、残りの正しい部分も疑い始める。
このスキルは、記事に書く事実のうち、外したときに読者が損をするものを選び、一次情報で確認し、確認できなかったものを正直な書き方へ戻す。

扱うのは事実の裏取りである。文の読みやすさは `writing-ja`、記事の構成と品質バーは `blog-writing-guide-ja` が担当する。

## どこから来て、どこへ渡すか

- `blog-idea-grilling` の企画カードにある「境界と要確認事項」は、この工程で消す。
- `blog-writing-guide-ja/references/review.md` の技術レビュー(技術的な主張、コードサンプル、数字とベンチマーク、アーキテクチャの説明)は、この手順で確認する。
- 確認結果は、記事本文の書き直しか、`blog-writing-guide-ja` へのレビュー指摘として返す。

## 実行モード

依頼内容から、作業を始める前にどちらかを決める。迷ったらレビューモードにする。書き換えは元に戻せないが、確認カードは読んでから編集を頼み直せる。

- **レビューモード** — 「確認して」「見てほしい」「合ってる?」のように確認だけを頼まれたとき、または「文章は直さなくていい」と明示されたとき。ファイルは変更せず、判定と修正案を確認カードで返す。
- **修正モード** — 本文の書き換えまで明示的に頼まれたとき。依頼された範囲だけ本文へ反映する。範囲の指定がないなら、反証と不正確だけを直し、古い・根拠不足・検証不能は確認カードで提案にとどめる(確定していない書き換えを本文に入れない)。

## 検証条件を決める

主張を抜き出す前に、記事がどの時点・どの前提を語っているかを確認する。ここを飛ばすと、公開当時は正しかった記述を現在の仕様と照合して誤って「反証」と判定する。

- 記事の公開日、または想定している時点
- 記事が説明する製品・ライブラリのバージョン
- OS、ランタイム、エディション、設定などの前提環境
- 現行仕様を説明する記事か、特定バージョンの記録か、体験談か
- 新規記事の公開前確認か、公開済み記事の更新か(`blog-ops/references/update-post.md` の改訂判断と対応する)

front matter の日付や本文の記述から分かる範囲で決め、分からない部分は確認カードに前提の制約として残す。

## 確認する対象を絞る

全文を検証しようとすると終わらない。間違いのコストが高い主張から順に確認する。

優先して確認するもの。

- **数値と性能** — ベンチマーク結果、レイテンシ、削減率、料金。記事の主張を支える根拠そのものになっている
- **バージョン依存の挙動** — 「vX から使える」「デフォルトで有効」。読者の手元のバージョンが違えば再現しない
- **否定と断定** — 「できない」「対応していない」「必ず〜になる」。一つの反例で崩れるうえ、読者が選択肢を捨てる判断に使う
- **他ツール・他社との比較** — 相手側の仕様を誤解したまま書くと、記事の信用と相手への公正さを同時に失う
- **セキュリティと課金に関わる記述** — 読者が実害を受ける
- **時間で変わる事実** — 価格、無料枠、サポート状況、推奨手順。執筆時点で正しくても公開時に古い

確認対象を選ぶ基準は、主観か観測可能かであって、書き手自身の話かどうかではない。好み・印象・価値判断(「使いにくいと感じた」「この設計が好きだ」)は真偽を外部から判定できないので確認対象外にする。一方、書き手自身の体験でも、実行時間、件数、バージョン、設定、ログ、エラー内容のように記録で確認できる具体的な主張は確認対象にする。「自分の環境ではメモリ使用量が40%減った」は書き手の観測だが、その40%という数字自体は検証できる。

## 主張に応じた情報源

一次情報の強さは、確認する主張の種類によって変わる。どれか一つを常に最上位に置かず、主張に合う情報源を選ぶ。

| 確認したいこと | 情報源 |
|---|---|
| 仕様上どう動くべきか | 仕様、RFC、標準 |
| 公式に案内されている使い方 | 公式ドキュメント(参照したバージョンと URL を記録する) |
| いつ・どのバージョンで変わったか | リリースノート、変更履歴、公式のアナウンス |
| 現在どう実装されているか | ソースコード、テストコード |
| 特定の環境でどう動くか | 条件(回数、環境、負荷)を記録した手元の再現 |
| 調査の手掛かり | Issue、Discussion。単独では最終判定にしない。既知の誤りや古い議論の場合がある |

根拠にしないもの。個人ブログや要約サイトの記述、検索結果のスニペット、そして自分の記憶。記憶は特にバージョン依存の挙動と価格で古くなりやすく、しかも古いことに気づけない。確認したつもりで確認していない状態がいちばん危ない。

## 再現時の安全

記事のコードやコマンドには、削除、外部への書き込み、課金、本番操作、認証情報の要求が混ざりうる。動くかどうかを確かめたい気持ちより、実行の安全を先に判断する。

- 対象リポジトリに AGENTS.md や実行規約があれば先に確認する
- 本番環境、実データ、実アカウントでは実行しない
- 認証情報や個人情報を渡さない
- 削除、課金、公開、外部への書き込みを伴う処理は実行しない
- 安全に隔離された環境で実行できると判断できる場合だけ再現する。判断できないなら実行せず、検証不能として何を確認すれば再現できるかを書く

## 進め方

1. **検証条件を決める。** 前節の手順で、記事の時点・バージョン・前提を確認する。

   完了: 何を前提に確認するかを説明できる。

2. **主張を一覧にする。** 下書きまたは企画カードから、確認対象の優先順位に当たる主張を抜き出す。原文の引用と行番号を残す。

   完了: 確認する主張と、確認対象外にした主張を区別して説明できる。

3. **一つずつ一次情報に当たる。** 主張ごとに、どの資料の、どの記述が根拠かまで特定する。「公式ドキュメントに書いてある」では後から検証できないので、URL、参照日、対象バージョンまで記録する。

   手元で再現できるものは、「再現時の安全」に沿って判断できる場合だけ再現する。数値は測り直すか、元の計測条件を記事に書けるところまで確認する。

   完了: 各主張に、次節の判定のいずれかと、その根拠が付いている。

4. **判定に応じて返す。** 実行モードがレビューモードなら確認カードに修正案として書く。修正モードなら、依頼された範囲の本文を直す。ここを飛ばすと、確認しただけで何も変わらない。

   完了: レビューモードなら確認カードが、修正モードなら本文が、確認結果と矛盾しない状態になっている。

5. **確認カードを返す。** 何を確認し、何が変わり(または変わる提案をし)、何が未解決かを書き手に渡す。

   完了: 書き手が、公開してよいか、追加で調べるかを判断できる。

## 判定

**確認済み** — 根拠と一致している。読者が自分で追えるよう、根拠へのリンクを本文か脚注に置く。バージョンや計測条件が結論を左右するなら、それも本文に書く。

**不正確** — 主張の骨子は正しいが、成立条件や例外が抜けている。条件を補うだけで直る。「Xは遅い」に「大量データ(10万件以上)を扱う場合は」のような条件を足す。

**反証** — 根拠と明確に矛盾している。書き直しは必須で、提案ではない。誤りが記事の主張の土台なら、主張そのものを見直す必要があるため、書き手に判断を返す。

**古い** — 公開当時または執筆時点では正しかったが、現在の一次情報と食い違う。時間で変わる事実(価格、無料枠、サポート状況、推奨手順)で起きる。反証と違い、書き手の誤りではないので、その前提で確認カードに書く。

**根拠不足** — 断定の強さを支える証拠が見つからない、または証拠が主張ほど強くない。反証ではない(矛盾する根拠はない)ことに注意する。

**検証不能** — 環境、非公開情報、実行の安全性の判断がつかないなどの理由で確認できなかった。

**確認対象外** — 好み、印象、価値判断など、真偽を外部から判定できないもの。

不正確・古い・根拠不足・検証不能はいずれも、確認できなかった、または部分的にしか確認できなかった主張である。共通して、次の方針で本文または確認カードへ反映する。

- 一般化していたものを、観測した範囲や成立条件に戻す。「Xは遅い」→「自分の環境の N 件のデータでは、Xに M ミリ秒かかった」
- 断定を、書き手の判断として書く。「Yは使えない」→「今回の要件では Y を採用しなかった。理由は〜」
- 確認方法と時点ごと読者に渡す。「公式には記載がない。手元の vN.N.N ではこう動いた」「2026年3月の公開時点では正しかったが、2026年8月現在は変わっている」

それらしい説明で埋めない。削るのは最後の手段にする。これは `writing-ja` の「事実、推測、判断を混ぜない」と同じ考え方を、外部の裏取りの側から適用したものになる。根拠が足りないときに主張を弱めるのは、記事の価値を下げる妥協ではない。書き手が実際に知っている範囲を正確に渡すことが、読者にとっての価値になる。

## 出典と時点の書き方

- リンクは、トップページではなく該当ページの深い URL にする。読者が探し直さずに済む
- バージョンが挙動を決める記述には、確認したバージョンを本文に書く
- 時間で変わる事実には観測時点を書く。「現時点では」ではなく「2026年8月時点では」。公開後に読む人が、情報の古さを自分で判断できる
- 公式ドキュメントに記載がないことを確認したなら、そう書いてよい。「記載を見つけられなかった」と「存在しない」は別の主張なので、書き分ける

## 確認カード

```markdown
## 確認カード

対象: [記事またはドラフトのパス]
実行モード: [レビュー / 修正]
検証条件: [記事の時点・バージョン・前提。特定できなければ「未特定」と書く]
確認日: [YYYY-MM-DD]

### 反証・不正確(要修正)

- 主張: 「[原文の引用]」([ファイル:行])
  - 判定: [反証 / 不正確]
  - 根拠: [URL、バージョン、または再現結果]
  - 実際: [一次情報が示す内容]
  - 対応: [修正モードで書き直した内容、またはレビューモードでの修正案]

### 古い・根拠不足・検証不能(書き方を調整)

- 主張: 「[原文の引用]」([ファイル:行])
  - 判定: [古い / 根拠不足 / 検証不能]
  - 当たった資料: [調べた範囲と、見つからなかったこと、または当時の根拠]
  - 対応: [狭めた主張、時点を明示した書き方、または書き手の判断としての書き方]

### 確認済み

- 「[主張の要約]」— [URL] ([バージョン / 参照日])

### 確認対象外

- [対象と、確認対象から外した理由]
```

## 一次情報に当たれない環境のとき

ネットワークや対象環境が使えないなら、推測で埋めずにそう報告する。確認できなかった主張を「確認済み」に混ぜないことがこの工程の値打ちなので、検証不能として残し、どの資料に当たれば確認できるかを書き手に渡す。書き手が自分で確認するか、公開を遅らせるかを選べる状態にする。

## 完了条件

抜き出した主張がすべて判定され、レビューモードなら確認カードに修正案が、修正モードなら本文に反映(または明確な提案)がある状態になっている。
一件でも判定が付いていない主張が残っているなら、まだ終わっていない。