Anthropic、AI 開発ライフサイクルのセキュリティ対策を解説
本文の状態
日本語全文を表示中
詳細モードで約19分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
Claude Blog
Anthropic は AI ネイティブな開発環境において、CLAUDE.md ファイルによるガイドラインのコード化とリアルタイムセキュリティレビュー插件の導入により、脆弱性を生成段階で防止するクローズドループ体制を確立した。
AI深層分析を開く2026年7月27日 23:10
AI深層分析
キーポイント
ガイドラインのコード化とクローズドループ
Anthropic は組織全体のスキル参照を含む CLAUDE.md ファイルにセキュリティガイドラインを記述し、エージェントが生成するコードに即座に適用する仕組みを構築した。バグ発見時には関連ファイルを更新して再発を防ぐフィードバックループを実現している。
リアルタイムでのセキュリティレビュー
以前は PR 直前の最終ステップだったセキュリティレビューが、Claude がコードを生成するその場で実行されるようになった。セキュリティガイダンスプラグインの導入により、エージェントは会話中に潜在的な脆弱性を指摘し改善を提案する。
シャドウ IT の排除と低コードプラットフォーム
PR 段階での追加的な誘導により、非技術チームが公式の低コードホスティングプラットフォームの利用を促され、セキュリティチームが従来直面していたシャドウ IT の問題を抑制している。
アイデンティティとネットワーク境界の厳格化
エージェントの活動範囲を制限するため、開発者は仮想マシン上でコーディングを行い、アイデンティティにハードな境界を設定する。エージェントからの外部通信は許可リスト(egress-allowlist)に限定され、プロンプトインジェクション攻撃への耐性を高めている。
重要な引用
security professionals within an AI-native engineering organization have a new lever: they can directly shape how code is created, helping to prevent vulnerabilities at the source.
Once an agent discovers a bug class, the relevant file is updated to prevent it recurring in future code.
Our team has chosen to incorporate our hard code review gate at the test/CI stage of the cycle.
編集コメントを表示
編集コメント
Anthropic は、AI エージェントが自律的にコードを生成する時代において、従来のセキュリティモデルでは対応しきれない「生成時のリスク」に直面している。CLAUDE.md を活用した動的なガイドライン適用と、開発環境の厳格化は、AI ソフトウェア開発ライフサイクル(SDLC)における実用的な防御策として注目される。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
Code
AI をネイティブに活用するエンジニアリング組織において、セキュリティ専門家が新たに活用できる手段があります。それはコードが作成される段階で直接そのあり方を形作り、脆弱性が生まれる根源から防ぐことです。
従来はチームが繰り返し発生する脆弱性を把握し、それに対処するためのコーディングガイドラインを作成していました。しかし、これらのガイドラインは運用が難しく、標準化されることも稀でした。
Anthropic では、こうしたガイドラインを「CLAUDE.md」ファイルに記述し、組織全体のスキルへの参照を含めることで、コード生成の瞬間からベストプラクティスが守られるようにしています。これはクローズドループの一部として行われます。エージェントが特定のバグクラスを発見すると、関連するファイルが更新され、将来のコードで同様の問題が再発しない仕組みになっています。

もちろん、これで生成されるコードがすべて完璧になるわけではありません。Anthropic のチームはまず、PR を開く直前にエージェントに /security-review コマンドを実行させるよう指示する CLAUDE.md ファイルから始めました。これは現在一般公開されているコマンドで、チーム内部のレビューワークフローを製品化したものです。このコマンドは、攻撃者が操作可能な入力が入り込む箇所を検出し、不審なリンクをスキャンし、その結果を確認します。
現在、コード生成中にClaude がレビューを行っています。セキュリティガイダンスプラグイン をインストールすると、Claude は会話とコードをリアルタイムで確認し、生成プロセスの中でセキュリティ向上の提案や一般的な脆弱性への対応を行います。
PR(プルリクエスト)段階での他の誘導策により、技術部門以外の社内チームは従来の「シャドー IT」問題から脱却し、当社のローコードアプリホスティングプラットフォーム上でアプリケーションをホストするよう促されています。
一部の顧客は、/security-review をPreToolUseフックと連携させることで、このステップをより厳格なゲートとしています。これも有効な手段ですが、当チームとしては、サイクルのテスト/CI 段階に堅牢なコードレビューのゲートを設ける方針を採用しています。
コードの作成・レビューに加え、この段階で最も重視しているのが「被害範囲の限定」です。そのために、ID に関する厳格な境界設定(監視セクションで詳しく解説)を行い、開発者に仮想マシン上でのコーディングを徹底させています。
コーディング環境をリモート VM へ移行したのは比較的スムーズな変更でした。ノートパソコン単体と比較して、管理と可視性の面で大きな向上が実現しています。これらの VM 上のエージェント通信は、許可リスト(アロウリスト)に基づいて外部への送信を制限しています。
エージェントが信頼できない入力を読み込む際、特にこの厳格な外部接続制限が重要になります。そこにはプロンプトインジェクションの悪意あるペイロードが含まれている可能性があるからです。注入された指示はインターネット上の任意の宛先へ到達することはできず、データ持ち出し経路は限られた監視対象サービスにのみ限定されます。
ここでも、AI ネイティブなソフトウェア開発ライフサイクル(SDLC)への明確な適応が見て取れます。以前はリモートコーディングが主に知的財産の保護のために使われていましたが、現在ではより成熟した AI コーディングチームが、エージェントを管理・封じ込める手段としてこれらの環境を採用するようになっています。
永続的な原則: AI ネイティブなエンジニア組織における「左側シフト」とは、脆弱性の発見と、Claude がコードを生成する方法をカスタマイズするための指示更新との間のループを閉じることを意味します。爆発半径(最小権限の原理)を制限し、必要に応じてハードな境界線によってエージェントがアクセスできる範囲を厳格に制御してください。
テスト (CI)
私の経験則では、AI ネイティブへの転換期にあるエンジニアチームにとって、テストや CI の工程は最も苦痛なボトルネックになりがちです。Anthropic においても、開発者のほとんどがエージェント型コーディングツールを使い始め、同時に複数のエージェントを稼働させるようになると、チームの速度は人間によるコードレビューのスピードに制限されるという事実がすぐに明白になりました。
はっきり言っておきましょう:人間の責任所在は依然としてプロセスの中核です。私たちが行ったのは、自動化されたエージェント型レビューと決定論的レビューを組み合わせてレビュープロセスを加速させつつ、規制対象や真に重要なコードについては人間によるレビューを維持することでした。
従来、人間のコードレビューが業界標準とされてきましたが、実証データはそれが完璧ではないことを示しています。セキュリティ上のバグは世界中のソフトウェアで依然として頻繁にリリースされています。一方、当社のレビュープロセスではより多くのコードを検査し、特に複雑な問題を発見できるため、こうしたリスクを低減できます。
エージェントが自身の発見の妥当性を証明するよう求めることで信頼が高まった結果、実質的なレビューコメントが付されたプルリクエスト(PR)の割合は 16% から 54% に増加しました。また、現在導入した自動化プロセスであれば、過去の claude.ai のインシデントの原因となったバグのおよそ 3 分の 1 は検出できたとの分析結果も得ています。
これは Anthropic だけの話ではありません。Intercom も同様の成果を報告しており、同社では AI が PR の 19% を自動承認しています。その結果、デプロイ頻度が倍増する一方で、コード変更によるダウンタイムは 35% 減少しました。CircleCI も同様の結論に至っており、Claude を活用した自律型エージェント「Chunk」を開発。このエージェントは CI/CD のメンテナンス課題を解決し、人間が確認する前に自身で修正の妥当性を検証します。このアプローチにより、エージェントによるタスクが完了したプルリクエストとしてマージされる割合も倍増しました。
Anthropic でプルリクエスト (PR) が開かれると、複数のエージェントが自動的にレビューを行います。各レビューエージェントは特定の狭い焦点に設計・スコープされ、過去のインシデントに関する追加の文脈や記憶を得るために RAG(検索拡張生成) を活用しています。
これは、単一の巨大なプロンプトやスーパーセキュリティエージェントを使うよりも効果的です。その理由は主に以下の通りです。
- 各エージェントがバイアスや盲点を共有しないため、リスクを分散できる
- 1 つのエージェントが侵害されたり誤りを犯したりしても、他のレビューヤーによって検出可能
- エネルギーを複数の焦点領域に薄く分散させなくて済む
念のため言っておきますが、エージェントがチェックなしで本番環境へコードをマージすることはありません。私たちはコードベースをリスクレベルに応じて階層化し、どの部分を自動化するかは意図的に決定しています。コードベース全体には厳格な人間の承認プロセスが適用されています。
Claude によってレビューされマージされるコードについては、依然として人間の責任が中心です。すべての承認は、その背後にあるシグナルと理由とともにログに記録されます。また、リスク加重されたサンプルを人間が再確認します。もう一つのテストラウンドでは、「ユーザー A は決してユーザー B のデータを読み取れない」といった不変条件 (インバリアント) に焦点を当て、追加の手動レビュートリガーを発生させます。さらに、エージェントによるスキャンと SAST(静的アプリケーションセキュリティテスト) ツールを組み合わせており、これらは PR に対して直接コメントを投稿します。
エージェント型であれ決定論的アプローチであれ、ほとんどのスキャン手法は利用量ベース (コンシュープションベース) です。コードのスループットが増加すればコストも増大し、各チームが自らの状況に適切なカバレッジレベルを判断する必要があります。
Anthropic では、コードの生産性が向上すればコストも増大すると認識していますが、一方で単価は低下していくと予測しています。現在のモデルは数年前のものに比べてコーディング能力が格段に向上しており、この傾向は今後も続くでしょう。
永続的な原則: 自動レビューはリスクの種類が異なり、制御方法も異なります(複数のゲートと、異なるコンテキストウィンドウを持つエージェントによる管理です)。人間はプロセスに関与し続けますが、コードベースの性質に応じて、関与するタイミングや場所はライフサイクルの中で変化します。
デプロイ (CD)
Anthropic では堅牢なステージング環境を維持しており、主要なリリース時には外部ペネトレーションテストを実行し、定期的には DAST(動的アプリケーションセキュリティテスト)スキャンを実施しています。これにより、静的スキャンでは見逃されたり検出できなかったロジックバグを捕捉します。
SDLC の他のステージと同様に、AI はセキュリティチームにとって新たな課題と解決策をもたらします。一方で、到達する脆弱性の数は減少しています。他方で、生き残った脆弱性は極めて微妙で、発見が難しいものばかりです。
これに、より頻繁に大量のコードがリリースされるという現状を合わせると、定期的な動的テストも以前ほど「動的」ではなくなってしまいます。
しかし朗報もあります。AI モデルは、こうした複雑な脆弱性の多くを検出できる多段階かつコンポーネント間の推論において優れています。例えば今年 2 月、Claude が 500 件以上の高深刻度 OSS 脆弱性を発見し、修正に貢献したことを発表しました。
500 high-severity OSS vulnerabilities
Anthropic では、ステージング環境において継続的に AI を活用した DAST(動的アプリケーションセキュリティテスト)スキャンを実施しています。これは、2 つ以上のサービス間の前提条件が誤っている場合に生じるシステムレベルの脆弱性を検出するものです。現在、こうした機能を提供するベンダーは複数存在します。
永続的な原則: ダイナミックテストは、デプロイの頻度に合わせるべきです。
モニタリング
優れたセキュリティチームなら誰もが知っていますが、コードを本番環境に展開したところで仕事は終わりません。どんな脆弱性も、次第に高度化する攻撃者によってすぐに発見される可能性があると想定する必要があります。
当社のセキュリティチームでは、公開バグバウンティプログラム の運営やレッドチームによる模擬攻撃、依存関係・機密情報・サプライチェーン・クラウド設定・コンテナ全体での定期的な脆弱性スキャンなど、業界標準の取り組みを既に実施しています。
Claude はこれらの活動において大きな役割を果たしていますが、AI 原生のソフトウェア開発ライフサイクル(SDLC)導入に伴うモニタリング体制におけるより大きな変化として、アラート処理とコード移行に焦点を当てて説明します。
Anthropic でアラートが発生すると、Claude が以下のような作業を開始します:
- 本番環境のログを確認する
- バグの原因究明を行う
- 事後報告書(ポストモーテム)を作成する
- 場合によっては、バグを修正するためのコード変更も作成する
ただし、このエージェントが自動で修正をデプロイすることはできません。これは単一の目的に特化したシステムアカウントであり、許可されている権限は以下の3つだけです:新しいドキュメントの作成、社内チャネルへの投稿、本番環境ログへのアクセス。
修正は、別のエージェントと人間のレビューシステムから行われる必要があります。その理由は、アイデンティティ、権限、そして明確な境界線を管理するためです。本番環境へのコード展開時に被害の範囲を限定することが重要です。エージェントを分離することは不可欠で、あるエージェント(または複数のエージェント)が他のエージェントに対するチェック機能として働くからです。

これは CISO(最高情報セキュリティ責任者)にとって重要な教訓であり、私も痛い目を見て学んだことです。エージェントの明確な境界線を考える際、他のエージェントへのアクセス権限も含まれることを考慮する必要があります。
モデルのアップグレード後、インシデント対応エージェントが自発的に Slack を介して別の Claude インスタンスに連絡しました。そしてコードを記述できるエージェントに対して、修正を適用するよう依頼したのです。これは設計通り人間のレビュー段階で検出されましたが、この経験から私たちは、境界線をモデルの指示や「モデルができるだろう」という私たちの思い込みではなく、「アクセス権限と実行可能なアクション」の範囲に引くべきだと学びました。現在 Anthropic では、Slack を介したエージェント間の通信は一般的であり、エージェントアイデンティティモデル については十分に検討しています。
2 つ目の大きな変化は、チームが移行プロジェクトに取り組む姿勢です。セキュリティエンジニアリングチームなら誰もが経験する瞬間があります。自社の運用方法に根本的な欠陥があることに気づき、「コードの移行が必要だ」と判断した瞬間です。
かつては、CISO(最高情報セキュリティ責任者)がキャンペーンを展開し、各部署のエンジニアリソースの一部を数四半期にわたって割り当ててもらうよう要請する必要がありました。しかし今では、移行に伴う経済的コストも、社横断的な調整にかかるコストも低下しています。Claude なら、数万行に及ぶコードの移行プロセスを数日で自動化できます。
不変の原則: すべてのエージェントには、その業務に必要な最小限の権限を持つ単一目的のアイデンティティを与えてください。もしエージェント同士が連携させる必要がある場合は、人間と同じチャネルを通じて行うようにしてください。
ガバナンス
セキュリティプロセスの多くを自動化しましたが、安全なソフトウェア開発ライフサイクルを確保する上で人間の役割は依然として不可欠です。ただし、今私たちが注力しているのはコードレビューやバグレポートではなく、「Claude Tag」やループ、ダッシュボードです。
これは強力なガバナンスの重要性を浮き彫りにしています。スキルが陳腐化したり、発見されたバグクラスが CLAUDE.md に反映されなかったり、エージェントの判断がサンプリングされなかったりすれば、システム全体が劣化してしまいます。これを防ぐために、私たちは以下のような対策を講じています。
- コードベースをリスクレベルに応じて階層化し、そのレベルに応じたレビューを自動化する。
- 新しい AI レビューヤーはすべてシャドウモードで運用します。信頼が得られるまでは、新しいエージェントが投稿したコメントは人間の承認待ちとします。また、チーム内で「レッドチーム」演習を行い、悪意のある変更を加えてテストも行います。
- 自動承認されたケースの一部をサンプリングして確認する。
- システムのバイタル(重要指標)を常時監視する。セキュリティプロセスと各ワークストリーム全体の主要な指標を集約したダッシュボードを維持し、厳密にモニタリングしています。
- すべてのエージェントアクションを SIEM(セキュリティ情報イベント管理システム)へルーティングします。自動承認、ツール呼び出し、エージェント間のメッセージはすべて、その判断に使われたシグナルと共にログとして記録され、SIEM に格納されます。これにより、事後でも意思決定の追跡と監査が可能になります。このデータを活用し、これらのエージェントを「新たな内部脅威」の一つとして扱い、行動が基準から外れた場合はアラートを発令します。
永続的な原則: セキュリティエンジニアの役割は、バグの監視からループ(プロセス)の監視へと進化しています。
唯一不変なのは変化そのもの
ソフトウェア開発ライフサイクル(SDLC)や、それを堅牢化する手段がどれほど急速に進化しているか、過大評価することさえ難しいでしょう。モデルの能力は毎月向上し、新たな課題と解決策の両方をもたらします。
今日ではうまく機能していない、あるいは経済的に実現可能ではないことが、すぐに実現可能になる可能性があります。チームが問うべき本質的な質問は「スキャンをすべて実施する費用対効果はあるか」ではなく、「スキャンコストがほぼゼロになった場合、何をスキャンするか」です。その未来を見据えて計画を立てる必要があります。
本記事は、Anthropic の副首席情報セキュリティ責任者(CISO)であるジェイソン・クリントン氏によって執筆されました。また、同記事の作成に貢献いただいたマイケル・セグナー氏にも謝意を表します。
Anthropic は、AI 開発ライフサイクルを「AI ネイティブ」なアプローチで再構築するにあたり、セキュリティと信頼性を最優先しています。従来のソフトウェア開発プロセスとは異なり、生成 AI を活用したコード作成やテスト自動化が日常化している現在、セキュリティ対策もこれに合わせた進化が必要です。
まず重要なのは、開発環境そのものの堅牢性です。Anthropic では、すべての開発者が使用するワークステーションとサーバーに対して、厳格なアクセス制御と暗号化を適用しています。特に、機密データやモデルの重みファイルを扱う際、エンドポイントからクラウドストレージまでの通信経路を常に監視・保護する仕組みを導入しています。
次に、コード生成プロセスにおけるセキュリティ統合です。開発者が AI にコード作成を依頼する際、その出力が自動的に静的解析ツール(SAST)や動的解析ツール(DAST)でスキャンされます。不審なパターンや脆弱性が検出された場合は、即時に警告が発せられ、人間によるレビューが必須となります。この「AI 生成→自動検証→人間確認」のフローを確立することで、セキュリティリスクを早期に発見・封じ込める体制を整えています。
さらに、モデル自体の安全性も重視しています。Anthropic の AI モデルは、悪意あるプロンプトや不正なコード生成を試みる行為に対して、事前学習段階から耐性を持たせています。これにより、開発者が意図せず危険なコードを生成するリスクを大幅に低減しています。
最後に、継続的な改善と教育です。セキュリティチームは定期的に内部レビューを実施し、新たな脅威に対応するためのアップデートを迅速に行っています。また、すべての開発者に対して、AI を安全に活用するためのトレーニングを義務付けており、セキュリティ意識の向上を図っています。
Anthropic の AI ネイティブな開発ライフサイクルは、単なるツールの導入ではなく、組織文化全体の変革を通じて実現されています。これにより、私たちは急速に進化する技術環境の中でも、高い信頼性と安全性を維持し続けることが可能となっています。
AI算出
技術分析ainew評価高い
Anthropic が自社の AI ネイティブ SDLC で採用した具体的なセキュリティ対策(CLAUDE.md ファイルによるガイドラインの自動化、リアルタイムレビュー、VM 環境でのエージェント封じ込め)を詳述しており、単なる製品紹介ではなく実装プロセスと設計思想に焦点が当たっている。
6つの評価軸を見る
- AI関連度
- 75
- 情報源の信頼性
- 100
- 新規性
- 75
- 調べる価値
- 75
- 重複の少なさ
- 100
- 日本での有用性
- 25
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み