Claude Codeで4億6600万行を20時間点検した政府事例【古いシステム改修はAIに任せられるか】

Claude Codeで4億6600万行を20時間点検した政府事例は、古いシステム改修に悩む会社にとってかなり強いニュースです。
ただし、読むべきポイントは「AIが全部直した」ではありません。大事なのは、AIに読ませる範囲、根拠の残し方、人間が承認する場所を先に決めていた点です。

社内ツール、WordPress周辺の独自コード、Shopify連携、古いExcel/VBA、担当者だけが知っているWebアプリ。
こうした小さな資産も、放置すると保守の不安が積み上がります。関連する基本チェックは、AIで作ったコードのバグ検査でも扱っています。

Claude Codeで4億6600万行を20時間点検した政府事例とは

Anthropicは2026年7月6日、カナダのGovernment of AlbertaがClaude Codeを使い、政府システムのレビュー、脆弱性発見、修正を進めた事例を公開しました。

公式事例によると、同州のMinistry of Technology and Innovationは27省庁のシステムを担当し、対象には約1,280アプリケーションと約3,400リポジトリが含まれます。その中で、同州チームは466 million lines of codeを20時間でスキャンしました。日本語にすると4億6600万行です。

出典: Anthropic「Government of Alberta uses Claude to find and fix cybersecurity vulnerabilities across government systems」(英語)

この数字だけを見ると、Claude Codeが古いシステムを一気に片付けたように見えます。
けれど、公式事例でより重要なのは運用設計です。約50体のエージェントが並列で動き、ルールエンジンとClaudeの判断を分け、見つけた内容を開発者が確認できる形にしていました。

同州チームは、この種のレビューを従来のやり方で進めると約6.5年かかった可能性があると推定しています。
これは「どの会社でも20時間で終わる」という意味ではなく、読む対象と確認手順を整えれば、AIが保守の入口を大きく速めるという読み方が近いでしょう。

Claude Code政府事例の本質は二段階監査

Claude Code政府事例の本質は、AIが自分の勘だけで脆弱性を探したことではありません。まず普通のプログラムで既知の危険パターンを検出し、その後にClaudeが各フラグを確認する二段階の流れです。

Government of AlbertaのGit Insightsホワイトペーパーでも、リポジトリ内では固定ルーチンが走り、ルールエンジンが既知パターンを出し、AIエージェントがその結果を確認すると説明されています。AIが問題を報告する時は、ファイル名、行番号、重大度、理由、直し方を示し、開発者が実際のコードで確認できる形にします。

出典: The Velocity White Papers「Git Insights」(英語)

この構造なら、Claude Codeの指摘は「それらしい文章」ではなく、担当者が開ける場所と理由を持った確認項目になります。
社内でAIレビューを使う場合も、AIのレビュー結果を証跡として残す設計が欠かせません。

注意したいのは、二段階監査でもAIの判断は最終判断ではないことです。
Anthropic公式事例でも、パッチが出荷される前に同省エンジニアがレビューし、承認したと説明されています。つまり、Claude Codeはレビュー候補と修正案を速く出す役であり、本番の責任まで引き受ける役ではありません。

Claude Codeを古いシステム改修に使う前に分ける仕事

古いシステム改修でClaude Codeを使うなら、最初に「読む」「分類する」「直す」「出す」を分けます。ここを混ぜると、AIが便利に見えるほど危険になります。

段階	AIの役割	人が見ること
読む	ファイル構成や古い依存関係を確認	対象が本番か検証環境か
分類する	脆弱性候補、テスト不足、未整理コードを分ける	業務影響の大きさ
直す	修正案とテスト案を作る	仕様と例外処理
出す	リリース手順の案を作る	承認、バックアップ、戻し方

特に、Git管理されていないコードや、担当者だけが本番場所を知っているシステムでは、改修より先に棚卸しが必要です。
AIに触らせる前に、どのファイルが現行版か、バックアップはどこか、失敗時に誰が戻すかを決めます。

社内データを含むコードなら、読み取り範囲も重要です。顧客情報、APIキー、トークン、契約条件が混ざる可能性がある場合は、生成AIに社内データを読ませる前の保全ルールを先に置いてください。

Claude Codeは、公式FAQでローカルのターミナルで動き、ファイル変更やコマンド実行前に許可を求めると説明されています。
ただし企業運用では、それだけで十分とは考えず、権限、ログ、承認者、対象ブランチを別に決める必要があります。

出典: Anthropic「Claude Code」(英語)

中小企業がClaude Code政府事例を真似るなら1リポジトリから

中小企業がClaude Code政府事例から学ぶなら、50体のエージェントや4億6600万行を真似る必要はありません。
最初の単位は1リポジトリで十分です。対象は、売上や顧客対応に関係しつつ、いきなり本番更新しなくても読めるコードが向いています。

この試験で見るべき成果はAIの指摘数ではなく、人間が根拠を追えて、現場が修正判断できる形になっているかです。
指摘が100件出ても、ファイル名も理由も曖昧なら実務には使いにくい状態です。

• READMEや仕様メモが不足している場所
• 古いライブラリ、古い言語、放置された設定
• テストがない処理、手作業でしか確認できない処理
• APIキーや個人情報が混ざる可能性がある場所
• 本番反映前に人間承認が必要な変更

AIエージェントにどこまで任せるかは、閲覧、提案、実行で分けると判断しやすくなります。
承認点の置き方は、AIエージェントの承認フローと同じ考え方です。

Claude Code 4億6600万行事例を経営判断に使う条件

Claude Code 4億6600万行事例を経営判断に使う時は、導入可否をツール名だけで決めないほうが安全です。必要なのは、古いシステムのどこにリスクがあり、何を見える化すれば意思決定できるかという順番です。

アルバータ州の事例では、レビューエージェントが継続的にセキュリティ確認を行い、約95のセキュリティ統制を各パスで確認すると説明されています。
これは単発のコード読みではなく、運用の中に監査を組み込む発想です。

出典: The Velocity White Papers「Red, Blue, Green, and Yellow Agents」(英語)

Claude Agent SDKの公式ドキュメントでは、Claude Codeと同じエージェントのループやツールを使い、ファイル読取、コマンド実行、検索、編集などを組み込めるとされています。
便利な反面、社内で使うなら権限と監査ログの設計が必要です。

出典: Claude Code Docs「Agent SDK overview」(英語)

中小企業での判断基準は、コードや仕様の現物を安全に読めること、AIの指摘にファイル名、行番号、理由が付くこと、修正を人間が承認して戻せる手順があることの3つです。

古いシステム保守をAIで進める全体像は、システム保守のAI活用にも近いテーマです。
Claude Code政府事例は、その延長線上にある大規模な実証例として見ると、自社に縮小しやすくなります。

結論はシンプルです。Claude Codeで4億6600万行を20時間点検した事例は、古いシステム改修にAIを使える可能性を示しました。
けれど、真似るべきなのは規模ではありません。読む範囲を絞り、根拠を残し、人間が承認できる形にすることです。

FAQ