週刊AIニューストピック 2026年10月17日:人の速度を前提にした設計は、もう持たない

はじめに

今週は、一見関係のない2つの話が、同じ方向を向いていました。

1つは、Anthropicが、ソース管理の基盤を、自社製に作り替えた話です。もう1つは、国内で相次ぐ情報漏えいと、そこにAIが関わっている可能性の指摘です。

共通しているのは、人が操作する速度を前提にした設計が、AIの速度では持たなくなってきていることです。

今週の要点

• Anthropicは、社内のリポジトリを、Gitのミラーで運用してきました。ただ、それでは限界になり、「Scion」という独自のソース管理を作って、移行しました。
• Scionは、社内向けのシステムで、一般に公開する予定はありません。一方で、設計の考え方は、公開しています。
• 背景は、AIがコードを書く速度の急上昇です。1日にマージされる変更が、5月の約2,500件から、9月には3万件超になりました。
• 人の手の運用を前提にした、既存のGitのプラットフォームも、いずれ設計を見直す場面が出てくるかもしれません(筆者の見方です。下で、Anthropicの発言と分けて書きます)。
• インフラ屋として、意識しておきたい点が、3つあります。
• 一方で、国内のサイバー攻撃は、落ち着いていません。Webシステムとアプリ(API)が、狙われています。

Anthropic、ソース管理を自社製の「Scion」に作り替えた

Anthropicは、10月13日に公式のEngineeringブログで、ソース管理の基盤を、自社製のシステム「Scion」に全面移行したと公表しました(10月15日に追記あり)。

きっかけは、コードの量です。2026年5月は、1日にマージされる変更が、平均で約2,500件でした。9月には、1日3万件を超えました。ブログでは、AIがコードを書く速度が上がった結果、ボトルネックが、人間の規模で作られた開発基盤(ソース管理、ビルド、CI)に移った、と説明しています。

Gitでは、巨大なモノレポ(1つのリポジトリに、全コードを置く方式)が、次のような状態でした。

• メインブランチの履歴だけで、約100GB。圧縮した作業コピーが、25GB超。
• CIのために、1日に約2,500万回のチェックアウト。素朴にGitで取得すると、1日に600PB超の通信になる計算。
• その対策として、最盛期には、数百台のGitミラーを運用。ただ、マージの量が増えるほど、運用が難しくなった。

ブログによると、Scionは、7人のチームが、5か月で作り上げ、モノレポを全面移行しました。その結果、Gitミラーの基盤に比べ、CPUとメモリの必要量が200分の1になり、CIのチェックアウトは、分から秒に縮まったとされています。

設計の考え方

ブログが挙げる設計の原則から、インフラ屋の目線で、目を引く点を3つ挙げます。

• クライアントは、常にオンラインと考える。 Gitは、オフラインでも作業できるよう、全クライアントが完全な履歴を持つ設計です。ところが、実際のクライアントの大半は、エージェントやCIのジョブで、常にオンラインです。その前提を捨てて、サーバーが履歴や差分の問い合わせに答える形にしました。
• すべての機能を、APIで提供する。 CIのジョブが、リポジトリを手元に持たなくても、差分や変更履歴を、サーバーに聞けます。
• 水平に拡張できる構成にする。 全体が1か所に集約されない設計で、各層のキャッシュヒット率は、99%を超えるとされています。

汎用のGitの代替ではない、という注意書き

重要な点があります。Anthropic自身が、「Scionは、Gitの汎用の代替には適していない」と明記しています。

この考え方が意味を持つのは、数万人のエンジニア、またはエージェントの群れが、大量にコードを書く、巨大なモノレポだけです。ほかの会社に提供する予定もありません。一方で、今後6〜12か月で、同じ種類の問題が、より一般的になるだろうと見ています。そのため、考え方を共有して、GitHubやGitLab、OSSのコミュニティと協力したい、としています。

「Gitを捨てた」という話ではありません。巨大なモノレポで、Gitのミラー運用が限界に達した、という事例です。Scionは、社内向けのシステムで、一般には公開されません。ただし、設計の考え方は、ブログで公開されています。

Git側は、どう変わるのか

ここは、Anthropicの発言と、筆者の見方を、分けて書きます。

Anthropicの発言(ブログより)

• この種の問題は、今後6〜12か月で、より一般的になると予想している。
• GitHub、GitLab、OSSのコミュニティと協力して、開発者のニーズの変化を支えたい。
• Gitのサーバー側は、クライアントと同じ構造である必要はない。Scionのような、サーバー側のAPIを、Gitのプラットフォームが提供する道もある。

つまり、「Gitを置き換える」ではなく、「Gitのサーバー側を、AIの速度に合わせて作り替える余地がある」という提案です。

筆者の見方

人の手の運用を前提に作られた、既存のGitのプラットフォームも、AIのコード生成が一般に広がれば、いずれ設計を見直す場面が出てくるかもしれません。ただし、これはAnthropicが言っていることではなく、筆者の推測です。Scionの規模の問題が、一般の現場に来るまでには、まだ時間がありそうです。

インフラ屋にとっての意味

多くの現場には、Scionの規模の問題は、すぐには来ません。ただ、ここから、自分の現場に引き直せる、意識しておきたい点が、3つあります。

• AIがコードを書く量が、数倍に増えたとき、CI/CDの基盤は、耐えられるか。 ビルドの待ち行列、チェックアウトの負荷、ランナーの台数。
• マージキューやテストの考え方は、変えなくてよいか。ブログでは、エージェントの規模では、グローバルなロックを前提にしたマージキューが、成り立たないと書かれています。代わりに、マージ後・デプロイ前の自動テストに投資した、とのことです。
• エンジニアの仕事は、何か。ブログでは、「Claudeに『ノー』と言うのが、エンジニアの役割になることが多かった」と述べています。全体の設計と、トレードオフの判断は、人が担う、という整理です。

今週のセキュリティ状況

先週の記事で、情報漏えいを取り上げました。その後も、状況は動いています。ここでは、確認できた範囲で整理します。件数は、いずれも発表時点の数字で、調査が進むと変わることがあります。

件数の推移

セキュリティ会社のマクニカは、国内法人のWebシステムからの個人情報の漏えいを、独自に集計しています。2024年は62件、2025年は84件、2026年は10月6日時点で119件で、今年の119件のうち、81件が7月以降に公表されたものです。さらに、NHKは、2026年に不正アクセスで漏えいした可能性のある個人情報が、のべ1億6,500万人分余りにのぼると、マクニカのまとめとして報じています。

今週の主な発表(各社の公式発表を確認)

• ソースネクスト(10月15日): 会員情報を管理するシステムへの不正アクセスで、22,519,960件の顧客情報が、流出した可能性があります。10月13日に不正アクセスを確認し、調査の結果、10月9日ごろから、会員情報を取得するAPIが、不正に利用されていたことが分かった、としています。クレジットカード情報は、対象のシステムに保存されておらず、流出の対象に含まれない、とのことです。
• バーガーキング(ビーケー・ジャパン)(10月15日): 公式アプリの会員情報、約1,118万件が流出しました。不正アクセスは10月2日から7日にかけて行われ、10月13日に判明した、としています。クレジットカード番号は、保持しておらず、ログインパスワードの漏えいは、現時点で確認されていない、とのことです。
• メドレー(10月15日公表、16日更新): 医療機関業務支援システム「@link(アットリンク)」と、患者向けアプリなどで、第三者による不正アクセスを確認し、10月14日深夜から、サービスを一時停止しています。個人情報への影響は、対象の項目や医療機関の範囲を、確認・精査中で、今週末から週明けに、概ね特定できる見通し、としています。
• 日本経済新聞社(10月16日): システム開発に使うクラウドサービスへの不正アクセスで、同日時点で約183万件が漏洩、と発表しました。ただし、内訳は、氏名、メールアドレスなどのいずれかを含む個人情報が約15万件で、残りの約168万件は、単体では個人を特定できない識別子のみ、とされています。クラウドサービスにアクセスするための認証情報が窃取された、としています(日本経済新聞の自社報道)。

件数は、いずれも発表時点のもので、調査が進むと変わることがあります。

JPCERT/CCの注意喚起(10月8日公開、9日更新)

JPCERT/CCは、「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」(JPCERT-AT-2026-0030)を出しています。普段から断続的に発生しているランサムウェア攻撃とは別の、大量の個人情報の漏えいにつながっている、特に増加しているおそれのある攻撃の類型を、取り上げています。

確認されている手口は、次の4つです。

• ケースA: さまざまなソフトウェアの、既知の脆弱性を探索して悪用を試みる。設定ファイルやバックアップファイルの窃取も含む。
• ケースB: スマートフォンアプリを解析して、APIの接続先とキーを特定し、API経由で不正な操作を行う。
• ケースC: BIツール「Metabase」の、SQLインジェクションの脆弱性の悪用。
• ケースD: 公開Webサーバーから届くアプリケーションサーバーに、Webシェルを設置する。

一般利用者向けのアプリだけでなく、BIツールや従業員向けの管理システムなど、不特定多数のアクセスを想定していないシステムも、被害にあっています。

対策として、APIのリクエスト数の制限、非公開APIを含むアクセス制御、必要最小限のトークン権限、不要な機能の公開停止、保存期間を過ぎたデータを残さない、などが挙げられています。

AIの関与について

先週の記事では、攻撃にAIが使われているという指摘は、「可能性」の段階だと書きました。今週、NHKは「AIエージェント使用の証拠見つかる」と報じました。この内容を、確認できた一次のレポートで見ると、次のとおりです。

サイバーセキュリティクラウドが10月9日に公開したレポートでは、観測した攻撃で、同一とみられる攻撃者が、約40分間で326のIPアドレスを使い分け、1,200件を超えるアクセスを行っていました。人の手では考えにくい量ですが、攻撃ツールのような機械的な規則性はなく、応答を見ながら、手を変えていました。このことから、「応答に応じて判断できる仕組み、たとえばAIなどが使われている可能性がある」としています。

ただし、同社はレポートの中で、「これは観測された振る舞いからの推測であり、AIの利用を直接示す痕跡を確認したものではありません」と明記しています。マクニカも、AIが使われたことを示すログや痕跡は確認されていないとしています。

つまり、現時点の状況は、「AIが使われた確定の証拠」ではなく、「AIのような振る舞いが観測された」段階です。

(出典: ソースネクスト、ビーケー・ジャパン、メドレー(アットリンク)、日本経済新聞、JPCERT/CC 注意喚起、マクニカ セキュリティ研究センター、サイバーセキュリティクラウド レポート、NHK(のべ1億6,500万人分))

確認しておきたい点

• Scion: 数字(1日3万件超、200分の1など)は、Anthropic自身の発表です。第三者の検証は、確認できていません。
• 個別企業の件数: 各社の公式発表を確認しましたが、いずれも調査中で、「可能性」の段階のものを含みます。日本経済新聞社の件は、同社の自社報道を、一次として確認しています。
• AIの関与: 観測された振る舞いからの推測で、直接の痕跡は、確認されていません。

(出典: Anthropic Engineering「Redesigning source control at Anthropic」)

インフラ現場にとっての意味

2つの話に共通する問いは、「人の速度を前提にした設計は、AIの速度に耐えられるか」です。

開発基盤では、AIがコードを書く速度に、ソース管理、ビルド、CIが追いつくか。セキュリティでは、人の手では難しい速度と手数で探索してくる攻撃に、人が見るだけの監視で追いつくか。

先週の記事で書いた、「持たない・消す」「ログを取って見る」「権限を最小にする」は、今週のJPCERT/CCの対策とも、重なります。ただし、今週の注意喚起が示すのは、Webシステムとアプリ、そしてAPIが狙われているという点です。先週の記事で、触れきれなかった部分でもあります。自社が公開しているWebシステム、スマートフォンアプリ、BIツールなどの管理画面を、あらためて棚卸ししてみる価値があります。

先週の記事: 「うちは大丈夫?」と聞かれたら:情報漏えいに備える、3段構えの対策

次のアクション

• 開発基盤: 自社のCI/CDで、いちばん詰まりやすい箇所(チェックアウト、ビルドの待ち、マージ)を、洗い出してみる。AIによるコード量が、数倍になったと仮定して、どこから壊れるかを、考えておく。
• セキュリティ: JPCERT/CC の注意喚起を読み、自社が公開しているWebシステム、アプリのAPI、BIツールなどの管理画面を、一覧にする。そのうえで、アクセス制御、リクエスト数の制限、不要な公開の停止を、点検する。