Skill: JavaScript Fact Checker

このスキルを使用して、33 JavaScript Concepts プロジェクトのコンセプトドキュメンテーションページの技術的正確性を検証します。JavaScriptに関する誤った情報を広めないようにするためです。

使用時期

• 新しいコンセプトページを公開する前
• 既存のコンテンツに大きな編集を加えた後
• コミュニティへの貢献をレビューする時
• JavaScriptの新機能でページを更新する時
• 既存のコンテンツの定期的な精度監査

防止する対象

• 誤ったJavaScriptの動作主張
• 古い情報 (現在の方法として提示されたES6前のパターン)
• 記述された出力を生成しないコード例
• 破損または誤解を招く外部リソースリンク
• 事実として述べられている一般的な誤解
• 普遍的なものとして提示されたブラウザ固有の動作
• 不正確なAPI説明

---

Fact-Checking 方法論

完全なファクトチェックのために、以下の5つのフェーズを順に実行します。

Phase 1: コード例の検証

コンセプトページ内のすべてのコード例は、正確性について検証する必要があります。

ステップバイステップのプロセス

1. ドキュメント内のすべてのコードブロックを特定する

2. 各コードブロックについて：

   • コードとすべての出力コメント（例：// "string"）を読む
   • JavaScriptの環境でコードを精神的に実行するか、テストする
   • 出力がコメント内で述べられていることと一致することを確認する
   • 変数名とロジックが正しいことを確認する

3. 「間違った」例（❌でマークされた例）について：

   • 実際に間違った/予期しない動作を生成することを検証する
   • それが間違っている理由の説明が正確であることを確認する

4. 「正しい」例（✓でマークされた例）について：

   • 述べられているとおりに機能することを検証する
   • 現在のベストプラクティスに従っていることを確認する

5. プロジェクトテストを実行する：

   # すべてのテストを実行する
   npm test
   
   # 特定のコンセプトのテストを実行する
   npm test -- tests/fundamentals/call-stack/
   npm test -- tests/fundamentals/primitive-types/
   

6. テストカバレッジをチェックする：

   • /tests/{category}/{concept-name}/を確認する
   • 主なコード例のテストが存在することを検証する
   • テストカバレッジのない例にフラグを立てる

コード検証チェックリスト

チェック項目	検証方法
console.logの出力がコメントと一致	コードを実行するか精神的にトレース
変数が正しく命名・使用されている	ロジックを読む
関数が期待値を返す	実行をトレース
非同期コードが記載された順序で解決	イベントループを理解
エラー例が実際にスロー	try/catchでテスト
配列/オブジェクトメソッドが正しい型を返す	MDNを確認
typeofの結果が正確	一般的なケースをテスト
厳密モードの動作が関連する場合は記載	例がそれに依存するかチェック

注意すべき一般的な出力ミス

// これらの一般的なミスに注意してください:

// 1. typeof null
typeof null        // "object" ("null"ではない!)

// 2. 配列メソッドが新しい配列を返すのか変更するのか
const arr = [1, 2, 3]
arr.push(4)        // 4 (長さ) を返す、配列ではない!
arr.map(x => x*2)  // NEW配列を返す、変更しない

// 3. Promise解決の順序
Promise.resolve().then(() => console.log('micro'))
setTimeout(() => console.log('macro'), 0)
console.log('sync')
// 出力: sync, micro, macro (sync, macro, microではない)

// 4. 比較結果
[] == false        // true
[] === false       // false
![]                // false (空の配列はtruthy!)

// 5. thisのバインディング
const obj = {
  name: 'Alice',
  greet: () => console.log(this.name)  // undefined! アロー関数はthisがない
}

---

Phase 2: MDNドキュメント検証

JavaScript API、メソッド、動作に関するすべての主張は、MDNドキュメンテーションと一致するべきです。

ステップバイステップのプロセス

1. すべてのMDNリンクをチェックする：

   • ドキュメント内の各MDNリンクをクリック
   • リンクが200を返す (404ではない) ことを確認
   • リンク先のページが参照されているものと一致することを確認

2. API説明を検証する：

   • メソッドシグネチャをMDNと比較
   • パラメータ名とタイプをチェック
   • 戻り値タイプを検証
   • エッジケースの動作を確認

3. 非推奨APIをチェックする：

   • MDN上で非推奨警告を探す
   • 非推奨のメソッドが現在のものとして教えられていないか確認

4. ブラウザの互換性の主張を検証する：

   • MDNの互換性テーブルとクロスリファレンス
   • より広いサポートデータについてCan I Useをチェック

MDNリンクパターン

コンテンツタイプ	MDN URL パターン
Web APIs	https://developer.mozilla.org/en-US/docs/Web/API/{APIName}
グローバルオブジェクト	https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/{Object}
ステートメント	https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/{Statement}
オペレータ	https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/{Operator}
HTTP	https://developer.mozilla.org/en-US/docs/Web/HTTP

MDNに対して検証する項目

主張タイプ	チェックする内容
メソッドシグネチャ	パラメータ、オプションパラメータ、戻り値の型
戻り値	正確な型と可能な値
副作用	変更するのか？何に影響するのか？
例外	スローできるエラーは？
ブラウザサポート	互換性テーブル
非推奨ステータス	非推奨警告はあるのか？

---

Phase 3: ECMAScript仕様準拠

細かいJavaScriptの動作については、ECMAScript仕様に対して検証します。

仕様をチェックする時期

• エッジケースと異常な動作
• 「JavaScriptがどのように機能するか」についての主張
• タイプ強制ルール
• オペレータの優先順位
• 実行順序の保証
• 「常に」「決して」「保証される」などの単語を使用している主張

仕様をナビゲートする方法

ECMAScript仕様は以下にあります: https://tc39.es/ecma262/

コンセプト	仕様セクション
タイプ強制	Abstract Operations (7.1)
等価	Abstract Equality Comparison (7.2.14), Strict Equality (7.2.15)
typeof	The typeof Operator (13.5.3)
オブジェクト	Ordinary and Exotic Objects' Behaviours (10)
関数	ECMAScript Function Objects (10.2)
thisバインディング	ResolveThisBinding (9.4.4)
Promise	Promise Objects (27.2)
イテレーション	Iteration (27.1)

仕様検証の例

// 主張: "typeof null は 'object'を返すバグです"
// 仕様が言う: typeof null → "object" (Table 41)
// 歴史的背景: JS 1.0からの既知の癖
// 判定: ✓ 正しい、ただし「バグ」と呼ぶのは若干形式的でない

// 主張: "Promiseは常に非同期に解決する"
// 仕様が言う: Promise reaction jobsはキューに入る (27.2.1.3.2)
// 判定: ✓ 正しい - 解決されたPromiseでもマイクロタスクをスケジュール

// 主張: "===は==より高速である"
// 仕様が言う: パフォーマンスについて何も言わない
// 判定: ⚠️ ニュアンスが必要 - これは実装に依存

---

Phase 4: 外部リソース検証

すべての外部リンク（記事、ビデオ、コース）は検証する必要があります。

ステップバイステップのプロセス

1. リンクのアクセス可能性をチェックする：

   • 各外部リンクをクリック
   • ロード可能であることを確認（404、ペイウォールではない）
   • 別のURLへのリダイレクトを記録

2. コンテンツの正確性を検証する：

   • 明らかなエラーがないかリソースを確認
   • JavaScriptに焦点を当てている（C#、Python、Javaではない）
   • アンチパターンを教えていないか確認

3. 公開日をチェックする：

   • 時間に敏感なトピック（async、modules等）については、最近のコンテンツを推奨
   • ES6+のトピックについて、2015年以前のリソースにフラグ

4. 説明の正確性を検証する：

   • リソースが実際にカバーしているものと説明が一致するのか？
   • 説明は具体的か（汎用的ではないか）？

外部リソースチェックリスト

チェック項目	パス基準
リンクが機能する	200を返す、コンテンツが読み込まれる
ペイウォールなし	無料でアクセス可能（または明確にマーク）
JavaScriptに焦点を当てている	主に他の言語についてではない
古くない	最新のJSトピックについては2015年以降
正確な説明	説明が実際のコンテンツと一致
アンチパターンなし	悪いプラクティスを教えていない
信頼できるソース	知られた/信頼できるクリエイターから

外部リソースの危険な兆候

• ES6+のトピックについて至るところでvarを使用
• Promiseやasyncについてのコンテンツにコールバックを使用
• jQueryを最新のDOM操作として教える
• JavaScriptについての事実上のエラーを含む
• ビデオは2時間以上で、タイムスタンプリンクがない
• コンテンツが主に他の言語についてである
• 非推奨と記載せずに非推奨APIを使用

---

Phase 5: 技術的主張監査

JavaScriptの動作に関するすべての散文的な主張をレビューします。

検証が必要な主張

主張タイプ	検証方法
パフォーマンス主張	ベンチマークまたは注意が必要
ブラウザの動作	どのブラウザかを指定、MDNをチェック
歴史的主張	日付/バージョンを検証
「常に」または「決して」のステートメント	例外が記載されているか確認
比較（XとY）	両方を正確に検証

技術的主張の危険な兆候

• 例外が記載されていない「常に」または「決して」
• ベンチマークなしのパフォーマンス主張
• ブラウザを指定しないブラウザ動作主張
• 違いを過度に簡略化している比較
• 日付がない歴史的主張
• 仕様リファレンスなしの「JavaScriptがどのように機能するか」についての主張

検証する主張の例

❌ "async/awaitは常にPromiseより優れている"
→ 検証: 常にではない - Promise.all()は並列操作に優れている

❌ "JavaScriptはインタープリタ言語である"
→ 検証: 最新のJSエンジンはJITコンパイルを使用

❌ "オブジェクトは参照によって渡される"
→ 検証: 技術的には「共有による渡し」 - 参照は値によって渡される

❌ "===は==より高速である"
→ 検証: 実装に依存、仕様で保証されていない

✓ "JavaScriptはシングルスレッドである"
→ 検証: 正しい (メインスレッド)(Web Workersは別)

✓ "Promiseは常に非同期に解決する"
→ 検証: ECMAScript仕様により正しい

---

一般的なJavaScript誤解

これらの誤解が事実として述べられないようにしてください。

タイプシステムの誤解

誤解	現実	検証方法
typeof null === "object"は意図的である	JS 1.0からのバグで互換性のため修正不可	歴史的背景、TC39議論
JavaScriptには型がない	JSは動的型付け、型なしではない	ECMAScript仕様で型を定義
==は常に間違っている	== nullは両方のnullとundefinedをチェック、有効な使用法がある	多くのスタイルガイドがこのパターンを許可
NaN === NaNが偽なのは「誤り」	IEEE 754浮動小数点仕様によって意図的	IEEE 754標準

関数の誤解

誤解	現実	検証方法
アロー関数は短いシンタックスにすぎない	this、arguments、super、new.targetがない	MDN、ECMAScript仕様
varはファンクションスコープにその値とともにホイスト	宣言のみがホイスト、初期化ではない	コードテスト、MDN
クロージャは特別なオプトイン機能	JSのすべての関数はクロージャ	ECMAScript仕様
IIFEは廃止された	一回限りの初期化に有用	最新のコードベースでも使用

非同期の誤解

誤解	現実	検証方法
Promiseは並列で実行される	JSはシングルスレッド; Promiseは非同期、並列ではない	イベントループの説明
async/awaitはPromiseと異なる	Promiseの上のシンタックスシュガー	MDN、任意のthenableをawaitできる
setTimeout(fn, 0)は即座に実行される	現在の実行+マイクロタスク後に実行	イベントループ、コードテスト
awaitはプログラム全体を一時停止	非同期関数のみを一時停止、イベントループを一時停止しない	コードテスト

オブジェクトの誤解

誤解	現実	検証方法
オブジェクトは「参照によって渡される」	参照は値によって渡される（「共有による渡し」）	リアサイン テスト
constはオブジェクトを不変にする	constはリアサインを防止、変更ではない	コードテスト
JavaScriptのすべてはオブジェクト	プリミティブはオブジェクトではない（ラッパーはある）	typeofテスト、MDN
Object.freeze()は深い不変性を作成	浅い - ネストされたオブジェクトはまだ変更可能	コードテスト

パフォーマンスの誤解

誤解	現実	検証方法
===は常に==より高速	実装に依存、仕様で保証されていない	ベンチマークは様々
forループはforEachより高速	最新のエンジンは両方を最適化; ユースケースに依存	ベンチマーク
アロー関数は高速	パフォーマンスの違いなし、動作が異なるだけ	ベンチマーク
DOM操作を回避することは常に高速	バッチ変更の方が個別より遅い場合がある	ブラウザ、ユースケースに依存

---

テスト統合

プロジェクトのテストスイートを実行することは、ファクトチェックの重要な部分です。

テストコマンド

# すべてのテストを実行する
npm test

# ウォッチモードでテストを実行
npm run test:watch

# カバレッジ付きでテストを実行
npm run test:coverage

# 特定のコンセプトのテストを実行
npm test -- tests/fundamentals/call-stack/
npm test -- tests/fundamentals/primitive-types/
npm test -- tests/fundamentals/value-reference-types/
npm test -- tests/fundamentals/type-coercion/
npm test -- tests/fundamentals/equality-operators/
npm test -- tests/fundamentals/scope-and-closures/

テストディレクトリ構造

tests/
├── fundamentals/              # コンセプト1-6
│   ├── call-stack/
│   ├── primitive-types/
│   ├── value-reference-types/
│   ├── type-coercion/
│   ├── equality-operators/
│   └── scope-and-closures/
├── functions-execution/       # コンセプト7-8
│   ├── event-loop/
│   └── iife-modules/
└── web-platform/              # コンセプト9-10
    ├── dom/
    └── http-fetch/

テストがない場合

コンセプトにテストがない場合:

1. レポートで「テストカバレッジが必要」とフラグを立てる
2. コード例が正しいか手動で検証
3. フォローアップタスクとしてテストを追加することを検討

---

検証リソース

主要ソース

リソース	URL	使用目的
MDN Web Docs	https://developer.mozilla.org	APIドック、ガイド、互換性
ECMAScript仕様	https://tc39.es/ecma262	権威的な動作
TC39提案	https://github.com/tc39/proposals	新機能、ステージ
Can I Use	https://caniuse.com	ブラウザ互換性
Node.jsドキュメント	https://nodejs.org/docs	Node固有API
V8ブログ	https://v8.dev/blog	エンジン内部

プロジェクトリソース

リソース	パス	使用目的
テストスイート	/tests/	コード例の検証
コンセプトページ	/docs/concepts/	現在のコンテンツ
テスト実行	npm test	すべてのテストを実行

---

Fact Check レポートテンプレート

このテンプレートを使用して調査結果を記録します。

# Fact Check レポート: [コンセプト名]

**ファイル:** `/docs/concepts/[slug].mdx`
**日付:** YYYY-MM-DD
**レビュアー:** [名前/Claude]
**全体ステータス:** ✅ 検証済み | ⚠️ 軽微な問題 | ❌ 重大な問題

---

## エグゼクティブサマリー

[2-3文の調査結果の要約。ページが全体的に正確かどうかを述べ、重大な問題があればハイライト]

**実行されたテスト:** はい/いいえ
**テスト結果:** X合格、Y失敗
**チェックされた外部リンク:** X/Y有効

---

## Phase 1: コード例検証

| # | 説明 | 行 | ステータス | メモ |
|---|------|------|--------|-------|
| 1 | [簡潔な説明] | XX | ✅/⚠️/❌ | [メモ] |
| 2 | [簡潔な説明] | XX | ✅/⚠️/❌ | [メモ] |
| 3 | [簡潔な説明] | XX | ✅/⚠️/❌ | [メモ] |

### コード問題の発見

#### 問題1: [タイトル]

**場所:** XX行
**重大度:** 重大/主要/軽微
**現在のコード:**
```javascript
// 問題のあるコード

問題: [何が間違っているかの説明] 正しいコード:

// 修正されたコード

---

Phase 2: MDN/仕様検証

主張	場所	ソース	ステータス	メモ
[主張]	XX行	MDN/Spec	✅/⚠️/❌	[メモ]

MDNリンク状態

リンクテキスト	URL	ステータス
[テキスト]	[URL]	✅ 200 / ❌ 404

仕様の不一致

[ECMAScript仕様と一致しない主張がある場合、詳細を記載]

---

Phase 3: 外部リソース検証

リソース	タイプ	リンク	コンテンツ	メモ
[タイトル]	記事/ビデオ	✅/❌	✅/⚠️/❌	[メモ]

破損したリンク

1. XX行: [URL] - 404 Not Found
2. YY行: [URL] - ドメイン期限切れ

コンテンツの懸念

1. [リソース名]: [懸念事項 - 例：古い、言語間違い、アンチパターン]

説明の正確性

リソース	説明は正確か?	メモ
[タイトル]	✅/❌	[メモ]

---

Phase 4: 技術的主張監査

主張	場所	判定	メモ
"[主張]"	XX行	✅/⚠️/❌	[メモ]

修正が必要な主張

1. XX行: "[現在の主張]"
   • 問題: [何が間違っているか]
   • 提案: "[修正された主張]"

---

Phase 5: テスト結果

テストファイル: /tests/[category]/[concept]/[concept].test.js 実行されたテスト: XX 合格: XX 失敗: XX

失敗したテスト

テスト名	期待	実際	関連するドキュメント行
[テスト]	[期待]	[実際]	XX行

カバレッジギャップ

ドキュメント内で対応するテストがない例:

• XX行: [テストされていない例の説明]
• YY行: [テストされていない例の説明]

---

問題のまとめ

重大（公開前に修正必須）

1. [問題タイトル]
   • 場所: XX行
   • 問題: [説明]
   • 修正: [修正方法]

主要（修正すべき）

1. [問題タイトル]
   • 場所: XX行
   • 問題: [説明]
   • 修正: [修正方法]

軽微（あると良い）

1. [問題タイトル]
   • 場所: XX行
   • 提案: [改善]

---

推奨事項

1. [優先度1]: [具体的で実行可能な推奨事項]
2. [優先度2]: [具体的で実行可能な推奨事項]
3. [優先度3]: [具体的で実行可能な推奨事項]

---

検証チェックリスト

• すべてのコード例で正しい出力を検証
• すべてのMDNリンクをチェックして有効確認
• API説明がMDNドキュメンテーションと一致
• ECMAScript準拠を検証（該当する場合）
• すべての外部リソースリンクが利用可能
• リソース説明がコンテンツを正確に表現
• 一般的なJavaScript誤解が見つからない
• 技術的主張が正確でニュアンスがある
• プロジェクトテストを実行してレビュー
• レポートが完成し、引き継ぎの準備ができている

---

署名

検証者: [名前/Claude] 日付: YYYY-MM-DD 推奨: ✅ 公開可能 | ⚠️ 最初に問題を修正 | ❌ 大幅な修正が必要

---

## クイックリファレンス: 検証コマンド

```bash
# すべてのテストを実行
npm test

# 特定のコンセプトのテストを実行
npm test -- tests/fundamentals/call-stack/

# リンク切れをチェック（リンクチェッカーがある場合）
# インストール: npm install -g broken-link-checker
# 実行: blc https://developer.mozilla.org/... -ro

# JavaScriptクイックREPL
node
> typeof null
'object'
> [1,2,3].map(x => x * 2)
[ 2, 4, 6 ]

---

サマリー

コンセプトページをファクトチェックする時:

1. 最初にテストを実行 — npm testはコードエラーを自動的にキャッチ
2. すべてのコード例を検証 — 出力コメントは現実と一致する必要がある
3. すべてのMDNリンクをチェック — 破損したリンクと不正確な説明は信頼性を損なう
4. 外部リソースを検証 — アクセス可能で正確、JavaScriptに焦点を当てている必要がある
5. 技術的主張を監査 — 誤解と根拠のないステートメントに注意
6. すべてをドキュメント化 — 一貫した、徹底的なレビューのためにレポートテンプレートを使用

忘れずに: 私たちの読者は私たちが正しいJavaScriptを教えることを信頼しています。誤った情報の1つでも、何年も忘れるのに時間がかかる混乱を引き起こす可能性があります。ファクトチェックを真摯に受け取ってください。