アルバータ州政府のClaude Code活用が示す行政AIセキュリティ｜レガシーコードをどう安全に近代化するか

目次

---

1. 行政システムの安全対策は、棚卸しから実装へ移り始めた

レガシーシステムのセキュリティ対策で、もっとも難しいのは「問題があると分かっているのに、全体を見切れない」ことです。古いコード、断片的な設計書、担当者の異動、複数ベンダーの保守、十分でない自動テスト。こうした条件が重なると、脆弱性診断は重要だと分かっていても、対象範囲を広げるほど現場の負荷が増えてしまいます。

Anthropicは2026年7月6日、カナダのアルバータ州政府がClaude Codeを使い、政府システムのコードレビュー、脆弱性発見、修正、継続的なセキュリティレビューに取り組んだ事例を公開しました。公式発表によると、同州政府のチームは約4億6,600万行のコードを20時間で評価し、約1,280のアプリケーションと3,400のコードリポジトリを対象にしました。これは、AIエージェントが単なる開発補助を超えて、レガシー資産の安全性を点検する実務基盤になり始めていることを示しています。

ただし、この事例を「AIが自動でセキュリティを解決する」と読むのは危険です。重要なのは、AIエージェント、ルールベースの検査、人間のレビュー、テスト作成、継続監視を組み合わせた点です。この記事では、アルバータ州政府の事例を手がかりに、企業や行政がレガシーコードを安全に近代化するための考え方を整理します。

2. アルバータ州政府で何が行われたのか

Anthropicの公式発表では、アルバータ州政府のTechnology and Innovation省が、2025年からClaude Codeを用いて政府システムの安全性と保守性を改善してきたと説明されています。同省は27の州政府省庁のシステムを支えており、税務記録、調達情報、社会サービス関連のケースファイルなど、機密性の高い情報を扱うシステムも含まれます。

特徴的なのは、対象規模と進め方です。チームはClaude CodeとClaudeのOpus、Sonnetモデルを使い、約50のエージェントを並列に動かしてコードベースを調べました。処理は二段階で、まず既知パターンをルールエンジンで検出し、その後Claude Codeが検出結果を確認し、開発者が検証できるように該当ファイルと行を示す流れです。アルバータ州政府の実装ではこの処理に約20時間を要し、同チームは従来型の進め方なら約6.5年かかり得たと見積もっています。

さらに、検出で終わっていない点も重要です。脆弱性が見つかった場合、Claude Codeは修正案の生成、テスト、ビルドまで支援しました。安全な修正を確認するための自動テストが不足している場合には、先にテストを書く形も取られています。古すぎる、または複雑すぎるコードについては、より保守しやすい言語や構成への再構築も検討されました。公式発表では、約25年前にJavaで手作業開発された補助金関連ポータルが、4日から5日程度で再構築できた例にも触れられています。

3. AIエージェントが脆弱性レビューを変える理由

従来のセキュリティ診断では、対象範囲を決め、スキャナーを走らせ、結果を人が読み、優先順位を付け、修正チケットに落とし込む必要があります。これは重要な作業ですが、大規模なレガシー環境では結果が大量に出て、対応が詰まりやすくなります。特に、コードが古い、設計書が不足している、テストがない、担当者が少ない場合、検出結果だけが増えても修正まで進みません。

AIエージェントの価値は、この「検出から修正までの距離」を縮められる点にあります。アルバータ州政府の事例では、Claude Codeが単に警告を出すだけでなく、該当箇所を示し、修正案を作り、必要に応じてテストを補いました。つまり、脆弱性レビューをレポート作成で終わらせず、開発チームが実際に手を動かせる単位へ変換しています。

もう一つの価値は、継続レビューです。アルバータ州政府のサイバーセキュリティチームは、開発プロセス全体で動く専門エージェント群も構築しました。外部攻撃者の視点でアプリケーションを調べるレッドチーム型エージェント、防御状況を国際的なセキュリティ標準に照らして評価するブルーチーム型エージェント、コード品質や住民向け文書の明瞭さを見るエージェントなどです。公式発表では、各アプリケーションが1回のパスでおよそ95のセキュリティ制御に照らして確認されるとされています。

4. 人間承認を前提にした運用設計

この事例で見落としてはいけないのは、AIが修正を提案しても、出荷前には同省のエンジニアがレビューし承認していた点です。AIエージェントによるセキュリティ対応は、速度を上げる一方で、誤検知、過剰修正、既存仕様の破壊、監査上の説明不足といったリスクも持ちます。特に行政や金融、医療のように重要な情報を扱う領域では、AIの判断をそのまま本番へ流す設計は避けるべきです。

人間承認を機能させるには、レビューしやすい成果物が必要です。単に「修正しました」と表示されても、開発者は判断できません。どの脆弱性に対する修正か、どのファイルを変えたか、どのテストが追加されたか、どの標準に照らして問題があるのか、残るリスクは何か。AIエージェントは、こうした情報をレビュー単位でまとめられるように設計する必要があります。

企業で導入する場合も同じです。AIがプルリクエストを作る、CIでテストを走らせる、セキュリティチェック結果を添付する、人間が承認してからマージする。こうした既存の開発統制にAIを載せることで、便利さと説明責任を両立しやすくなります。逆に、チャット画面だけで修正を依頼し、変更履歴やレビュー経路が残らない運用は、後から原因調査ができなくなります。

5. 企業が学ぶべき判断基準

アルバータ州政府の事例は行政向けですが、企業のレガシーシステムにもそのまま通じます。古い業務アプリ、保守担当が減った社内ツール、テストが薄い基幹周辺システム、長年更新されていない公開Webアプリ。こうした資産は、多くの企業に残っています。AIエージェントを使う価値はありますが、いきなり全社コードを自動修正するのではなく、段階的に始めるべきです。

最初の判断基準は、対象範囲です。機密度が低く、テストやレビューの仕組みがあるアプリケーションから始めると、失敗時の影響を抑えながら学習できます。次に、検出だけにするのか、修正案まで出すのか、テスト生成まで任せるのかを分けます。最初は検出と説明に絞り、精度と現場の信頼が見えてから修正支援へ進むほうが安全です。

三つ目は、成果指標です。AIが何件指摘したかだけでは、価値は測れません。重要度の高い脆弱性の解消数、レビュー時間の短縮、テストカバレッジの改善、再発率、リリース前に検出できた問題の割合を見る必要があります。アルバータ州政府の事例でも、単に短時間でスキャンしただけでなく、修正、継続レビュー、職員教育まで含めて取り組みが設計されています。

6. 注意点

AIによるコードセキュリティ支援は強力ですが、導入には注意が必要です。第一に、AIはセキュリティ専門家の代替ではありません。既知パターンの検出や修正案の作成は得意でも、業務仕様、法的要件、リスク許容度、組織の責任分界は人間が判断する必要があります。特に、個人情報、決済、行政手続き、医療、重要インフラに関わるシステムでは、AIの提案を専門家が確認する体制が不可欠です。

第二に、コードをAIに渡す時点でデータ保護の設計が必要です。ソースコードには、業務ロジック、接続情報の痕跡、脆弱性、顧客情報の扱い方が含まれます。クラウドAIを使うのか、閉域環境で動かすのか、ログをどこに残すのか、学習利用の扱いはどうなるのかを確認しなければなりません。AIエージェントの権限は、最小権限を基本にし、対象リポジトリや実行コマンドを制限するべきです。

第三に、テストがない環境での自動修正は危険です。古いシステムほど、仕様がコードの中にしか残っていないことがあります。この場合、正しそうな修正が業務上の例外処理を壊す可能性があります。AIに修正させる前に、既存挙動を固定するテスト、リリース前の確認手順、ロールバック手順を整えることが先です。

最後に、AIエージェントの成果を過大評価しないことです。アルバータ州政府の発表は大きな成果を示していますが、その背景には対象範囲の整理、内部チームの設計、継続レビューの仕組み、職員教育があります。ツールだけを導入しても同じ結果は出ません。AIを速く動かすほど、運用設計、人間承認、監査ログの重要性も増します。

7. まとめ

アルバータ州政府のClaude Code活用事例は、AIエージェントがレガシーコードのセキュリティ対策を現実的に前進させる可能性を示しています。約4億6,600万行のコードを20時間で評価したという数字は目を引きますが、本質は速度だけではありません。検出、根拠提示、修正案、テスト、レビュー、継続監視を一つの運用へつなげた点にあります。

企業や行政が学ぶべきことは、AIに任せ切ることではなく、AIが得意な探索と生成を、人間の責任ある判断、既存の開発統制、セキュリティ標準、監査ログに接続することです。レガシーシステムの安全対策は、すべてを一度に刷新するより、対象を絞り、レビュー可能な形でAI支援を入れ、継続的に改善するほうが現実的です。

OpenBridgeでは、AIエージェント、RAG、ローカルLLM、業務システム連携、セキュリティ設計を組み合わせ、企業ごとの開発・運用体制に合わせたAI導入を支援しています。コードレビューAIやレガシーシステム近代化を検討する際は、モデル性能だけでなく、権限、テスト、人間承認、ログ、継続改善まで含めて設計することが重要です。