評価工程を飛ばすと、実務では次のような事故が起きます。いずれも「集めた情報をそのまま信じた」ことが原因です。

• 誤ったIOCの適用：古い・誤検知混じりのIOCリストをそのままブロックリストに投入し、正規サービスを遮断してしまう
• 誤帰属（misattribution）：単一系統の情報だけで攻撃者を断定し、レポートの信用を失う
• 循環報道への追随：複数ソースで確認したつもりが、実はすべて同じ元ネタのコピーだった（3章で詳述）

この図の評価ゲートが本記事のテーマです。ゲートを通った情報だけが分析（5章のACH）に進み、最後は確度表現（6章）を添えて報告される——この一連の流れは、情報機関の「インテリジェンスサイクル」を実務向けに簡略化したものです。

運用で効く原則は4つです。

• 独立採点の徹底：「B社の誤報」＝B4はふつうにあり得ます。信頼できる出どころだから中身も正しい、とはしない。逆に、出自不明のリーク（F）でも中身が独立に検証できれば F1〜F2 になります。
• 「1」の要件は独立確認：同じ発信元の再掲・転載を何件集めても「1」には昇格しません（3章の循環報道）。
• FとFは恥ではない：「判断不能」を正式な評価として記録できるのがこの体系の強みです。不明を無理に2や3にしない。
• 格付けは更新する：情報源の的中・誤報の履歴を蓄積し、定期的に信頼性評価を見直す。評価は一度きりのラベルではありません。

MISPならタグ2つで運用に乗る

脅威インテリジェンス共有プラットフォームのMISPには、Admiralty Codeがそのまま公式タクソノミー（admiralty-scale）として収録されています。イベントや属性に次の形式のタグを付けるだけで、チーム全体で同じ物差しの格付けを共有できます。

# 情報源の信頼性：B（通常は信頼できる）
admiralty-scale:source-reliability="b"

# 情報の確からしさ：2（おそらく真実）
admiralty-scale:information-credibility="2"

厄介なのは、連鎖の途中で「Aによると」「関係者によると」のような出典表記が脱落・変形していくことです。末端のDだけを見た調査者には、系譜をたどる手がかりがほとんど残っていません。そこで、次の4つの技術で系譜を復元します。

脅威インテリジェンスの現場でも、あるベンダーのレポートが報道→ブログ→まとめと再引用され、同じIOCが「複数ソースで確認済み」に見えてしまう例は珍しくありません。数えるべきは「ソースの数」ではなく「独立した系統の数」です。

証拠の保全も評価の一部です。ページは消え、投稿は編集されます。取得した瞬間にアーカイブ（魚拓）を作り、スクリーンショットには取得日時を残し、ダウンロードした検体・データはハッシュ値を控える。この3点セットを習慣にすると、後日「その情報は本当に存在したのか」を問われても立証できます。

実例：自社を騙るフィッシングサイト、設置者は誰か（架空シナリオ）

整合の「数」だけ見るとH1とH2は拮抗しますが、矛盾の少なさで見るとH1が残ります。さらにH2を支える証拠のうちE4はF6（判断不能）なので重みを最小にします。結論の書き方はこうなります——「設置者は無差別型のフィッシング業者である可能性が高い（likely）。ただしE5（役員名を含むパス）が独立した証拠で標的性を裏付けた場合、本結論は見直す」。結論・確度・覆る条件の3点セットです。

ACHが対抗しようとしている認知バイアスは、OSINT調査者の職業病でもあります。代表的な3つを覚えておいてください。

運用ルールも標準化されています。実務にそのまま持ち込める3つを紹介します。

• 用語セットを混ぜない：ICD 203は、1つの成果物の中で異なるセットの用語を混用しないよう明示しています。日本語で書く場合も、上表の「日本語の目安」列のような対応表をチーム内で固定しましょう。
• 確度（likelihood）と信頼度（confidence）を区別する：確度は「その事象が起きている・起きる見込み」、信頼度は「その判断を支える情報基盤の強さ（high／moderate／low）」。「確度はlikelyだが、単一系統の情報に依存しているため信頼度はlow」という報告が正しい形です。
• 結論には4点セットを添える：判断＋確度＋根拠（と情報ギャップ）＋覆る条件。5章のACHの出力とそのまま接続します。

CTI（サイバー脅威インテリジェンス）の世界でも、FIRST.orgのCTIカリキュラムが「不確実性の伝達」を独立した必修項目として扱っており、この確度表現はセキュリティ実務の標準教養になりつつあります。

よくある質問