アルバータ州政府がClaude Codeで4.66億行のコードを20時間走査 — 政府システム脆弱性の一括修復事例

Anthropicは2026年7月6日、カナダ・アルバータ州政府がClaude Codeでシステムのセキュリティレビューをおこなったケーススタディを公開しました。州のMinistry of Technology and Innovation(技術・イノベーション省)は2025年からClaude CodeのOpusとSonnetを使い、保有する4.66億行のコードを20時間で走査しています。脆弱性の修正と、開発中も続く継続的なセキュリティ点検の仕組みづくりまで進めた事例です。同じ規模のレビューを従来の手法でおこなうと約6.5年かかると、州のチームは見積もっています。

政府システムは税務・社会サービス・公共安全といった機微情報を扱う一方、コードが古く、文書も不完全で、体系的なレビューが後回しになりやすい領域です(重要インフラをAIで防御する取り組みでも、脆弱性発見の高速化が論点になっていました)。州政府が保有する全リポジトリを対象にした走査の事例として、Anthropicが詳細を公開しました。企業向けではAnthropic × KPMG提携や金融向けエージェント10種が先に出ており、今回は政府が対象になった形です。

数字

アルバータ州の事例を数字で見る

• 走査したコード

  4.66億行

  所要は約20時間。従来手法の見積もりは約6.5年

• 対象の規模

  約3,400リポジトリ

  約1,280アプリケーション。27省庁分

• 1リポジトリの平均

  約13.7万行

  4.66億 ÷ 3,400 の概算

• 1アプリの点検項目

  約95統制

  パスのたびに点検

20時間の走査は何をしたのか

走査の対象は、州の全省庁が使うシステムのすべてです。社会サービスから公共安全、山火事対応までを含みます。税務記録・調達情報・社会福祉のケースファイルといった機微情報が集まる一方、体系的なセキュリティレビューを一度も受けていないものが大半でした。累積した技術的負債(安全でないコード、未対応のバグ、古いソフトウェア)は数十億ドル規模とされています。

2025年に省内でチームが立ち上がり、システムをより安全で保守しやすくする仕事をClaudeと進める方針が決まりました。走査では約50体のエージェントが自律的かつ並列に動き、見る対象は次の3つです。

• コードの脆弱性
• 基盤インフラとデプロイ工程の弱点
• 技術文書の抜け

Claude CodeのOpusとSonnetを使い、全リポジトリを対象にしています。従来の自動走査ツールが見逃していた問題も、この走査で見つかったとのことです。複数のエージェントを同時に走らせる使い方は、サブエージェントの並列パターンで扱う型と同じ系統です。

コードの脆弱性やインフラだけでなく、技術文書の抜けも走査の対象に含めた点が特徴です。文書が不完全なまま運用されてきた政府システムでは、何が動いているのかを説明できないこと自体が、弱点になりうるためです。

2段階の走査ルーチン

手順

走査から修正までの流れ

1. 1

   ルールエンジンで一次走査

   各リポジトリを、既知のパターンを検出するルールエンジンにかけてフラグを立てます。

2. 2

   エージェントがフラグを再検証

   Claude Codeがフラグを見直し、指摘ごとに該当のファイルと行を示します。開発者がコードを開いて自分で確かめられる形です。

3. 3

   修正案・テスト・ビルド

   脆弱性が見つかると、Claude Codeは多くの場合、修正案の生成からテスト、ビルドまで進めます。自動テストが無い箇所では、先にテストを書きます。

4. 4

   省のエンジニアが承認

   どのパッチも、リリース前に省のエンジニアがレビューして承認します。

行番号付きの指摘なら、人間は検知の採否を、コードを見ながら決められます。

古すぎる、または複雑すぎて、そのまま直すのが非効率なコードは、新しい言語での作り直しに回ります。約25年前にJavaで手書きし、初回は5か月かかった助成金プログラムのポータルは、この方法なら最短で4〜5日で作り直せる例として挙げられました。ここでも、公開前にエンジニアが承認しています。

red team / blue teamエージェントの分担

走査に加えて、開発の全工程で動く審査用のエージェントも作られました。Claude Agent SDK上の構築で、役割は次のように分かれます。

くらべる

審査エージェントの役割分担

攻撃側

red team

アプリケーションを外から探ります。攻撃者の視点で、脆弱性がどう悪用されうるかを描き出します。

防御側

blue team

red teamの後に、国際的なセキュリティ標準に照らしながらアプリの防御を評価します。直すべきファイルを指す修復計画を書き出します。

このほか、コードの品質と、住民が目にする文章の明快さを調べるエージェントもあります。

大臣のコメントと、省が示した位置づけ

州のテクノロジー・イノベーション大臣であるNate Glubish氏は、「アルバータの人々は、人生で最も機微な情報のいくつかを政府に預けており、それを守るのは私たちの責任です」と述べています。AIで脆弱性を見つけて直したことで、従来の手法なら数年かかったことが数時間で終わった、というのが氏の説明です。

Anthropicの記事は、この取り組みを「政府機関がClaudeとClaude Codeを使って、大規模にシステムを守る例」として紹介しています。技術的負債とセキュリティ上の弱点は、アルバータに限らず、世界各地の州や連邦機関のシステムにもある問題だというのが前提です。そのため、州が公開した技術白書は、他の政府が同じ問題に取り組むための設計図の役割を持ちます。

数字から何が読み取れるか

4.66億行・20時間という数字の印象は強い一方、Anthropicの事例記事に載っていない数字もあります。検出した脆弱性の件数、深刻度の内訳、誤検知の割合、費用は記載がありません。同じことを自組織で試すときの見積もりは、これらがないと立てにくくなります。

載っている数字から言えるのは、次のような点です。

• 1リポジトリは平均で約13.7万行です。リポジトリごとの行数の分布は、事例記事に載っていません
• 6.5年という比較対象は、州のチームによる見積もりです。同じ作業を実際に走らせた実測ではありません
• 6.5年を暦の時間に直すと約5.7万時間で、20時間とは約2,800倍の開きです。ただし見積もりが何人分の作業時間なのかは、事例記事に書かれていません
• 約20時間は、Albertaの実装で全リポジトリの走査にかかった時間です。修正やレビューの時間は含みません

書き直しの短縮はどこまで当てはまるか

「25年前のJavaが4〜5日で」という数字には、条件が2つ付いています。Anthropicの記事は「一部の場面では」「最短で」と書いており、全システムがこの速さで作り直せるわけではありません。さらに、エンジニアのレビューと承認を通すことが前提です。

初回の5か月と再構築の4〜5日について、Anthropicの記事に工程ごとの内訳はありません。

自組織に当てはめるなら

事例の読み方は、立場によって変わります。

政府・自治体のIT部門

最初の分かれ目は、リポジトリの棚卸しができているかです。州の事例は、保有する全リポジトリが対象でした。台帳が整っていれば、走査のタスクとして立てやすくなります。台帳が無ければ、資産の洗い出しが先に来ます。

企業の情報システム・セキュリティ担当

既存のSAST / DASTの結果に誤検知が多いなら、2段階走査の再検証が参考になります。ルールエンジンの出力を、エージェントがファイルと行に紐づけて見直す順序です。red teamとblue teamの分業は、攻撃側の役と防御側の役を分け、防御側が評価と修復計画を出す構成で、開発工程に組み込む設計の例になります。人手のレビューを自動側に寄せる方向は、Claude Codeのセキュリティ・権限ガイドで扱うレビュー工程の話とも重なります。

事例の読み方は、手持ちの資産でも分かれます。

• 既存のSAST / DASTを導入済みで、検知件数が多すぎて追えない場合は、再検証を足して件数を絞る使い方が合います
• 導入済みの検知ツールが無い場合は、ルールエンジンによる一次走査を用意する段階から始まります
• 文書が足りないシステムが多い場合は、走査の対象に文書の抜けを入れる、という州の設計が使えます

レガシー資産を抱える開発者

古いコードを書き直す案件では、「いきなり直す」のではなく「テストを先に書く」順序が参考になります。自動テストが無い箇所ではClaudeがまずテストを書き、パッチが安全かどうかを確かめられる状態にしてから修正に進んでいます。

州全体への展開と、この事例の続き

人材育成と今秋の展開

州は、システム側の刷新だけでなく人の育成にも力を入れています。Alberta AI Academyは、政府職員数千人と一般市民1万人超が、プロンプトの書き方から企業向けアプリケーションの出荷までを学ぶ場として使われています。省は、このAcademyを足場に、単一チームの成果をAIを必要とするすべての省庁へ広げる考えです。

Albertaは、7月にエドモントンでindustry dayを開いて知見を共有すると発表しています。秋には、この進め方を州政府全体へ広げるプログラムを始めるとしています。

185本を16本に統合する計画

ある省では、本番で動く185本のレガシーアプリケーションを、Claude Codeで解析して中身を把握し、現代的な言語と作法で作った16本の再利用可能なアプリケーションに統合する計画があります。185本を16本にすると、約11.6本が1本に集まる計算です。狙いは、複雑さと保守コストを下げ、何年もかかる近代化の工程を速めることです。

統合の前に「各アプリが何をしているか」を解析する段階が入る点は、走査で文書の抜けを拾う設計と同じ向きです。中身を説明できないシステムは、直すのも束ねるのも難しいためです。

脆弱性の走査が既存コードを読む作業だったのに対し、統合は読んだ内容をもとに構造を作り替える作業になります。作業の質が違うぶん、エンジニアのレビューが効く場面も増えそうです。

Anthropicはこの事例の公開から1週間ほど後に、カナダの研究機関8機関への1,000万カナダドル拠出も発表しています。州政府の実装事例と、国内の研究への投資が、同じ国で並ぶ形です。

Claudeの役割の次の段階

今のところ、Claudeは省のコードの作成・レビュー・デプロイを支える役割です。省はこの先、新しいソフトウェアやツールをエンジニアと並んで一から作るAIエージェントへ、その範囲を広げる計画を示しています。Anthropicは、Albertaが文書化した進め方が他の政府の役に立つことを望むと述べ、引き続きAlbertaと協力するとしています。

まとめ

同じ手法を試す政府や企業が最初に見るのは、リポジトリの台帳がそろっているかと、修正をレビューして承認できる人員がいるかの2点です。走査は20時間で済んでも、修正を本番に出す関所は人間のレビューです。その承認の人手が、この方式で進められる速さの上限を決めます。