source-verification

情報源の裏取り(source-verification)

集めた情報の価値は「どこから来たか」と「今も有効か」で決まる。このスキルは、情報源を信頼性で格付けし、バージョン・日付を確認し、重要な主張を一次情報で裏取りするための手順を定める。技術選定・障害調査・実装調査など、外部情報に基づいて判断するあらゆる場面で使える。

目的は「情報を集めたこと」ではなく「その情報が判断に使える確度で正しいと言えること」を担保することにある。

情報源の信頼性階層

情報源には信頼性の階層がある。上を優先し、下位の情報は取っ掛かりや理解の補助に留め、最終判断の根拠にするなら上位で裏取りする。

1. 一次情報(最優先) — 公式ドキュメント・公式リポジトリ・公式ブログ・RFC/仕様書・標準規格。その技術の「正」となる情報。
2. ソースコードそのもの — 実装の実態を最も正確に反映する。ドキュメントと挙動が食い違うときはコードが正しいことが多い。
3. 技術書・査読論文 — 体系的だが、出版時点の情報である点に注意。
4. 個人ブログ・Qiita/Zenn・Stack Overflow — 理解の補助や実例として有用。ただし著者の環境・バージョン依存が強く、誤りも混じる。裏取り必須。
5. AI生成回答・まとめサイト(最下層) — 出発点にはなるが、それ自体を根拠にしない。必ず一次情報に当たる。

下位の情報でヒントを得たら、対応する一次情報に遡って確認するのが基本動作。

必須チェック:日付とバージョン

技術情報は古くなる。特に挙動がバージョンで変わる領域(ライブラリのAPI、クラウドの仕様、料金、EOL)では、次を必ず確認する:

• その情報が いつの時点 のものか(記事の公開日・更新日)
• 対象の バージョン が、今回検討している版と一致するか
• 検索上位に 古い情報が残り続けている 可能性を疑う(「最新」を装った古い記事は多い)

日付・バージョンが不明な情報は、その旨を明記して扱う。「たぶん今も同じ」で済ませない。

裏取りの手順

重要な主張ほど厳格に裏取りする。特に判断を左右する項目 — 性能値・制約・上限・ライセンス・料金・EOL・セキュリティ・非推奨(deprecated)情報 — は一次情報の確認を必須とする。

1. 主張を特定する — 「何を事実として使おうとしているか」を1文に切り出す。
2. 情報源を格付けする — 上の階層のどこに当たるかを見る。下位なら一次情報を探す。
3. 一次情報で確認する — 公式ドキュメント/仕様/コードで裏を取る。Web検索で見つけたら、必ずその一次ソースまで辿る。
4. 日付・バージョンを確認する — 上のチェックを通す。
5. 結果をラベリングする — 下記のいずれかを主張に添える。

裏取りの結果ラベル:

• [確認済み] — 一次情報で裏が取れ、バージョン・日付も有効。
• [要確認] — 下位情報のみ、または裏取り未了。判断の根拠にする前に確認が必要。
• [不明] — 情報が見つからない、または食い違いがある。埋めるために推測しない。

やってはいけないこと

• 一次情報に当たらず、ブログやAI回答の内容をそのまま結論の根拠にする。
• 日付・バージョンを確認せず「現在も同じ」と仮定する。
• 裏が取れない項目を、それらしく推測で埋める(空欄や「要確認」のままにする方が正しい)。
• 出典を確認しないまま断定的に書く。

簡単な例

主張: 「このライブラリのデフォルトのタイムアウトは 30 秒」

このスキルの動き:

1. 主張を切り出す(デフォルトタイムアウト = 30秒)
2. 情報源を見る — 個人ブログ発なら下位、要一次確認
3. 公式ドキュメント/ソースコードで該当設定を確認
4. そのドキュメントが対象バージョンのものか確認(v2 の記事を v3 の検討に使っていないか)
5. 一致すれば [確認済み]、公式が見つからなければ [要確認] としてそのまま報告

「たぶん30秒くらい」と丸めて事実のように扱わないこと。数値・制約は特に厳密に。