FBI Sentinel 9·11から25年の組織改革の教訓

9・11以降、FBIが得た核心的な教訓は、ツールよりも先に業務構造を変えるべきだという点だ。分散した情報と遅れた検証はVCFの失敗につながり、Sentinelは短い開発サイクルと現場からのフィードバックを導入した後、2012年に全面展開された。

この記事の数値と年表は、2004年の委員会報告書と2012～2014年のSentinel監督記録に基づいている。

9・11以前にFBIが見逃した兆候

FBIには、攻撃前に検討に値する手がかりが存在した。問題は、手がかりが異なる組織やシステムに分散していたことだ。現場の情報が本部の判断につながる経路も弱かった。約3,000人が死亡した2001年の攻撃は、この断絶を浮き彫りにした。

代表的な事例は、フェニックス・メモとミネアポリスの捜査だった。フェニックスの捜査官は2001年7月、飛行学校の動向を報告した。ミネアポリスの捜査官らは、ザカリアス・ムサウィの所持品の捜索を進めた。この2つの情報は、攻撃計画を示す統合的な警報には発展しなかった。

9・11調査委員会は、情報共有だけを問題視したわけではない。分析能力と管理体制の欠陥も併せて指摘した。以下の文は、報告書の関連箇所を韓国語で表現したものを訳したものである。

「FBIは、自らがすでに保有している情報さえ十分に把握していなかった。」—『9/11調査委員会報告書』

この事例を単なるデータ不足と捉えると、本質を見失う。情報があっても検索できなければ活用できない。責任者がいなければ、複数の手がかりを結び付けることも難しい。反対意見を上げる経路が弱ければ、警告はさらに容易に消えてしまう。

×

分析担当者がデジタル業務フローの停滞点と改善策を検討している。

VCFとSentinelの進行年表

FBIによる電子事件管理への移行は、2つのプロジェクトを経て進められた。VCFは実際の業務に導入されないまま、2005年に中止された。Sentinelも初期にはスケジュールと費用の管理に苦しんだ。しかし、2010年の再編後、2012年に全面展開へと到達した。

VCFには約1億7,000万ドルが投入されたとされる。ただし、監査文書ごとに契約費と関連プロジェクト費の範囲が異なる。したがって、この金額をFBI全体の近代化費用と捉えてはならない。VCF自体が事件管理システムとして稼働できなかったことは明らかだ。

Sentinelの当初のプロジェクト規模は4億2,500万ドルだった。プロジェクトは複数の段階に分けられていたが、スケジュールの遅延が積み重なった。2010年には、従来の計画では完遂が難しいとの判断が下された。FBIは範囲を再分割し、開発の統制を内部に移した。

VCFと再編後のSentinelの比較

2つのプロジェクトの違いは、ソフトウェアの名称よりも検証方法にあった。VCFでは、完成した成果物の確認が遅れるという問題が大きかった。再編後のSentinelは、動作可能な単位を頻繁に公開した。現場ユーザーからのフィードバックも次の開発サイクルに反映した。

これをアジャイルという1つの方法論の勝利だけと見るのは不十分だ。FBIはプロジェクトの範囲と指揮系統も併せて見直した。内部の技術人材の役割も拡大した。短い開発サイクルは、こうした変化を機能させる手段だった。

AI導入状況別の整理

AIを適用する場所によって、先に改善すべき業務は異なる。文書検索にはメタデータとアクセス権限が必要だ。意思決定支援には根拠と承認手続きが必要だ。自動化には例外的な状況を処理する担当者が必要だ。

まず、1つの業務を開始から終了まで図示する必要がある。次に、待ち時間と重複入力を示す。AIはボトルネックが確認された箇所に限定的に適用する。結果は精度だけでなく、修正コストまで測定しなければならない。

AI時代に加わった知識構造の問題

生成AIは、分散した情報をもっともらしく結び付けることができる。しかし、アクセスできない文書は結び付けられない。古い文書が多ければ、古い回答を生成する可能性がある。互いに矛盾する規定について、自ら責任を負うこともできない。

そのため、AI時代のナレッジ管理を保存量で評価するのは難しい。文書ごとに作成者と適用期間を表示する必要がある。廃棄の有無と承認状態も区別しなければならない。回答から原文の根拠を再び見つけられるようにする必要がある。

次の項目は、モデル選定前に点検できる。

• 同じテーマの規定が複数のリポジトリに重複しているか
• 最新文書と廃棄文書を区別できるか
• 機密情報に役割別のアクセス権限が適用されているか
• AIの回答の根拠文書とバージョンを確認できるか
• 誤った回答を報告し、修正する担当者がいるか
• 人が必ず承認すべき業務が定義されているか

この観点は、過去のFBI事例にはなかった新たなリスクも示している。過去には、情報を検索できないことが大きな問題だった。今では、誤って結び付けられた情報が急速に拡散する可能性がある。検索可能性と検証可能性を併せて設計しなければならない。

よくあるミスと誤解

第一に、9・11を単なる情報不足の事件として説明してはならない。複数の手がかりは存在したが、併せて分析されなかった。組織構造と判断手続きも結果に影響を与えた。データの収集量を増やすだけでは、同じ問題を防ぐのは難しい。

第二に、VCFの失敗をウォーターフォール方式だけに還元してはならない。要件管理と契約監督にも問題があった。ユーザー参加と技術的な統制も十分ではなかった。開発手法は複数の原因のうちの1つだった。

第三に、Sentinelがアジャイルを採用したことで自動的に成功したと考えてはならない。プロジェクト範囲の再調整とリーダーシップの変化が並行して行われた。内部人材もより大きな責任を担った。方法論は責任構造の代わりにはならない。

第四に、世界貿易センターの崩壊を確定的な「14秒」という1つの数字で説明すると、不正確になる可能性がある。2つのタワーは、衝突と崩壊の時点がそれぞれ異なっていた。崩壊時間も測定基準によって表現が異なる。核心的な教訓とは無関係な単一の数値は、慎重に扱わなければならない。

組織に適用する実行手順

AIの導入は、小さな業務単位で検証する方が安全だ。目標はツールの利用率ではなく、業務成果で定めるべきだ。失敗を早期に発見するための中止基準も必要だ。次の手順は、1つの業務を試験する際に使用できる。

1. 反復が多い、または遅延が頻発する業務を1つ選びます。
2. 入力情報と最終承認者を記録します。
3. 現在の処理時間とエラーの種類を測定します。
4. AIが担う範囲と人が担う範囲を分けます。
5. 小規模なユーザーグループに先行導入します。
6. エラーと修正時間を次のサイクルに反映します。
7. 基準を満たした場合に限り、適用範囲を拡大します。

成果指標を利用回数だけで定めないでください。処理時間と手戻り量を併せて確認してください。重大なエラーがどれほど早く発見されたかも確認してください。現場からのフィードバックが実際の変更につながったかどうかも記録する必要があります。

FBI事例が残した組織への問い

この事例は、AIが組織の既存の習慣を増幅し得ることを示している。情報が孤立している組織では、AIも不完全な文脈しか与えられない。承認段階が不明確であれば、迅速な生成が手戻りを増やす。検証を先延ばしにすれば、エラーも大規模に蓄積する。

組織は、まず3つの問いに答えることができる。

• 必要な情報を誰が保有しているか
• 異なる兆候を結び付ける責任者は誰か
• 小さな失敗をいつ発見し、止めることができるか

FBIのSentinel事例の核心は、特定の開発手法を再現することにあるのではない。不確実性を小さく分け、頻繁に確認するという運用原則にある。AIツールも同じ統制下に置かなければならない。組織の学習速度が導入速度を上回る必要がある。