結論：AIは調査を速めるが、本番変更の責任は引き受けない
Anthropicは2026年7月6日、カナダ・アルバータ州政府によるClaude Code活用事例を公開しました。公表内容では、州政府のチームが約50のagentを並列に動かし、4億6,600万行のコードを20時間で評価しました。対象組織は約1,280のapplicationと3,400のcode repositoryを維持していると説明されています。
さらに、applicationごとに約95のsecurity controlsを確認し、人のreview・承認を経てpatchを適用する運用や、ある省庁の185のlegacy applicationを16の再利用可能なapplicationへ集約する計画が紹介されています。
これらはAnthropicが公開したcase studyの数値です。独立した監査報告ではなく、すべての企業で同じ速度、精度、費用、成果が出るという意味ではありません。
中小・中堅企業が学ぶべき点は「AIなら数億行を読める」という見出しではなく、次の順番です。
- 資産とrepositoryを把握する
- AIのアクセスと機密を分ける
- 脆弱性・技術的負債の候補を人が検証する
- patchをreview・試験してから本番へ出す
- 維持、修復、統合、再構築、廃止を業務単位で選ぶ
この記事は、古い基幹・業務システムの仕様書がなく、保守会社変更や刷新判断ができない経営者、CIO、情シス、事業責任者向けです。
NOCODE EXIT
Bubble／kintone の限界、スクラッチ移行で解消しませんか？
ノーコードの肥大化・応答遅延・カスタマイズ限界を Laravel+Vue 移行で根治。概算費用・移行期間・データ移行設計・並行稼働プランをその場で確認できます。
事例で公表された内容と、断定できないこと
横にスクロールして確認できます
| 公表された内容 | 断定できないこと |
|---|---|
| 4億6,600万行を20時間で評価 | 全行を人と同じ深さで理解したこと |
| 約50agentを並列利用 | 小規模企業でも同じ費用・環境で再現できること |
| 約95security controlsを各applicationで確認 | すべての脆弱性を発見・修復したこと |
| 人がpatchをreview・承認 | AI生成patchが無条件で安全なこと |
| 185から16applicationへ集約する計画 | 集約が完了し、効果が確定したこと |
公表値を自社の稟議へ使う場合は「ベンダー事例」と明記し、自社の小規模trialで工数、発見率、誤検知、review負荷を測ります。
AIコード解析で起きる5つの失敗
- 行数を進捗にする。 重要業務、外部接続、data、変更頻度を見ず、読んだ量だけを報告します。
- AIの説明を仕様書とみなす。 実際の運用、例外処理、手作業、契約条件がコード外にあります。
- 脆弱性候補を一括修正する。 古い依存や暗黙仕様を壊し、本番障害を起こします。
- 本番repositoryを広く渡す。 秘密情報、個人情報、顧客コード、委託先権利を確認しません。
- 最新言語への書換えを目的にする。 維持費、障害、売上、変更速度が改善するかを測りません。
FREE DOWNLOAD
AI導入チェックリスト（PoC 失敗要因 10項目）
情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。
GXO式「AIレガシー刷新5ゲート100点」
横にスクロールして確認できます
| ゲート | 配点 | 満点の証拠 | レッドフラグ |
|---|---|---|---|
| 資産・業務 | 20 | application、repo、owner、利用者、売上、停止影響を紐づける | repo数だけを数える |
| 機密・権利 | 20 | code、data、secret、license、委託契約、AI利用条件を確認 | 全repoを一括upload |
| 解析・検証 | 20 | 対象、control、誤検知、見落とし、人reviewを記録 | AI結果を確定扱い |
| 変更・復旧 | 25 | test、差分review、段階release、rollback、証拠がある | AI patchを直接merge |
| 経営成果 | 15 | 保守費、障害、変更時間、統合、廃止の効果を測る | 書換え行数をKPI化 |
合計点に関係なくAI解析・自動修正を止める条件
- repositoryに本番secret、個人情報、顧客から預かったcodeが残る
- AIサービスの保存・学習・処理地域・再委託を確認していない
- testがなく、主要業務の正解を説明できない
- patchを承認する保守担当・業務担当がいない
- rollback、backup、ログ保全がない
この場合はcodeを外部AIへ渡さず、資産台帳、secret除去、test作成から始めます。
仮想記入例：25年前の受発注システム
横にスクロールして確認できます
| ゲート | 得点 | 不足 |
|---|---|---|
| 資産・業務 | 14/20 | 夜間batchのownerが不明 |
| 機密・権利 | 9/20 | code内secretと委託契約を未確認 |
| 解析・検証 | 12/20 | AI要約はあるが誤検知記録なし |
| 変更・復旧 | 8/25 | test coverageが低くrollback未訓練 |
| 経営成果 | 7/15 | 保守費は把握、障害損失は未計算 |
| 合計 | 50/100 | 自動修正を止め、調査だけに限定 |
まずsecret scanと契約確認を行い、受注、在庫引当、出荷、請求、取消のgolden testを作ります。AIには読取専用で限定moduleを解析させ、人が仕様仮説と実動作を照合します。
最初に作る資産台帳
横にスクロールして確認できます
| 項目 | 確認内容 |
|---|---|
| Application | 名称、目的、利用部門、利用者数 |
| Business | 売上、停止許容時間、繁忙期、手作業代替 |
| Repository | URL、branch、言語、最終変更、owner |
| Runtime | OS、middleware、database、cloud／on-prem |
| Interface | API、file、batch、mail、EDI、device |
| Data | 個人、決済、機密、保存期間、backup |
| Security | internet、認証、権限、未修復、log |
| Contract | 保守、license、source権利、再委託 |
| Decision | 維持、修復、統合、再構築、廃止 |
AI解析ベンダーへ要求する12の証拠
- AIが読めるrepositoryと読めない範囲
- code、prompt、outputの保存・学習・削除条件
- secret、個人情報、顧客codeの除外方法
- agent数、並列処理、費用上限
- 解析するsecurity controlと根拠
- 誤検知・見落としの検証方法
- 仕様仮説から元codeへ戻れる参照
- patchごとの人reviewと業務承認
- test生成物と既存testの区別
- 段階releaseとrollback
- 納品する台帳、仕様、差分、runbook
- AIサービス変更・終了時の再現性
90日で決めること
- 1〜2週：全資産の粗い台帳と上位リスク10件
- 3〜4週：限定moduleのAI解析、人review、golden test
- 2か月目：修復候補3件を検証環境で変更し、工数と精度を測定
- 3か月目：維持、修復、統合、再構築、廃止の5分類と概算費用
GXOのシステム開発セカンドオピニオンでは、ブラックボックス化したシステムの資産・契約・見積・刷新順序を整理します。セキュリティ起点は脆弱性診断、AIコード解析のデータ・権限・評価はAI導入可否アセスメントへ接続します。
FAQ
AIで仕様書を自動生成すれば引継ぎできますか
出発点にはなりますが、実運用、例外、外部連携、手作業、契約を業務担当と照合する必要があります。AI生成文書だけを正本にしません。
全repositoryを一度に解析した方が効率的ですか
機密、契約、費用、review能力が整っていなければ危険です。重要度の高い限定moduleで精度と運用を確認してから広げます。
AIが作ったpatchを使ってよいですか
人の差分review、security review、業務test、段階release、rollbackが揃う場合に限定します。高影響システムへ直接適用しません。
出典・確認日
- Anthropic「Government of Alberta uses Claude to find and fix cybersecurity vulnerabilities」（2026年7月6日公開、2026年7月14日確認）
- アルバータ州政府の技術white papers（2026年7月14日確認）
4億6,600万行、20時間、約50agent、約95controlsなどはAnthropicのcase studyに基づく公表値です。独立監査済みの一般的性能として扱わず、自社trialで確認してください。本記事の配点と仮想例はGXO独自です。
