| name | source-verification |
| description | 技術調査で集めた情報の信頼性を評価し、一次情報で裏取りするためのスキル。情報源を信頼性の階層で格付けし、日付とバージョンを確認し、重要な主張が一次情報に基づくかを検証する。技術選定・障害調査・実装調査など、外部情報(公式ドキュメント・ブログ・Q&A・AI回答など)を根拠に判断する場面全般で使う。「この情報は正しい?」「裏取りして」「出典は?」「本当にそう?」「エビデンスは」といった語が出たとき、また Web検索で得た情報をそのまま結論の根拠にしようとするときは必ずこのスキルを使い、推測や古い情報を事実として扱わないようにすること。 |
情報源の裏取り(source-verification)
集めた情報の価値は「どこから来たか」と「今も有効か」で決まる。このスキルは、情報源を信頼性で格付けし、バージョン・日付を確認し、重要な主張を一次情報で裏取りするための手順を定める。技術選定・障害調査・実装調査など、外部情報に基づいて判断するあらゆる場面で使える。
目的は「情報を集めたこと」ではなく「その情報が判断に使える確度で正しいと言えること」を担保することにある。
情報源の信頼性階層
情報源には信頼性の階層がある。上を優先し、下位の情報は取っ掛かりや理解の補助に留め、最終判断の根拠にするなら上位で裏取りする。
- 一次情報(最優先) — 公式ドキュメント・公式リポジトリ・公式ブログ・RFC/仕様書・標準規格。その技術の「正」となる情報。
- ソースコードそのもの — 実装の実態を最も正確に反映する。ドキュメントと挙動が食い違うときはコードが正しいことが多い。
- 技術書・査読論文 — 体系的だが、出版時点の情報である点に注意。
- 個人ブログ・Qiita/Zenn・Stack Overflow — 理解の補助や実例として有用。ただし著者の環境・バージョン依存が強く、誤りも混じる。裏取り必須。
- AI生成回答・まとめサイト(最下層) — 出発点にはなるが、それ自体を根拠にしない。必ず一次情報に当たる。
下位の情報でヒントを得たら、対応する一次情報に遡って確認するのが基本動作。
必須チェック:日付とバージョン
技術情報は古くなる。特に挙動がバージョンで変わる領域(ライブラリのAPI、クラウドの仕様、料金、EOL)では、次を必ず確認する:
- その情報が いつの時点 のものか(記事の公開日・更新日)
- 対象の バージョン が、今回検討している版と一致するか
- 検索上位に 古い情報が残り続けている 可能性を疑う(「最新」を装った古い記事は多い)
日付・バージョンが不明な情報は、その旨を明記して扱う。「たぶん今も同じ」で済ませない。
裏取りの手順
重要な主張ほど厳格に裏取りする。特に判断を左右する項目 — 性能値・制約・上限・ライセンス・料金・EOL・セキュリティ・非推奨(deprecated)情報 — は一次情報の確認を必須とする。
- 主張を特定する — 「何を事実として使おうとしているか」を1文に切り出す。
- 情報源を格付けする — 上の階層のどこに当たるかを見る。下位なら一次情報を探す。
- 一次情報で確認する — 公式ドキュメント/仕様/コードで裏を取る。Web検索で見つけたら、必ずその一次ソースまで辿る。
- 日付・バージョンを確認する — 上のチェックを通す。
- 結果をラベリングする — 下記のいずれかを主張に添える。
裏取りの結果ラベル:
- [確認済み] — 一次情報で裏が取れ、バージョン・日付も有効。
- [要確認] — 下位情報のみ、または裏取り未了。判断の根拠にする前に確認が必要。
- [不明] — 情報が見つからない、または食い違いがある。埋めるために推測しない。
やってはいけないこと
- 一次情報に当たらず、ブログやAI回答の内容をそのまま結論の根拠にする。
- 日付・バージョンを確認せず「現在も同じ」と仮定する。
- 裏が取れない項目を、それらしく推測で埋める(空欄や「要確認」のままにする方が正しい)。
- 出典を確認しないまま断定的に書く。
簡単な例
主張: 「このライブラリのデフォルトのタイムアウトは 30 秒」
このスキルの動き:
- 主張を切り出す(デフォルトタイムアウト = 30秒)
- 情報源を見る — 個人ブログ発なら下位、要一次確認
- 公式ドキュメント/ソースコードで該当設定を確認
- そのドキュメントが対象バージョンのものか確認(v2 の記事を v3 の検討に使っていないか)
- 一致すれば [確認済み]、公式が見つからなければ [要確認] としてそのまま報告
「たぶん30秒くらい」と丸めて事実のように扱わないこと。数値・制約は特に厳密に。
