Anthropic AIネイティブSDLC、監査ループ再設計

Anthropic は 2026年7月21日、Deputy CISO の Jason Clinton 氏による AI-native software development lifecycle の解説を公開した。記事で目を引くのは、同社の merged code の約80%を Claude が書いているという数字だ。しかし、実務上の焦点は「AI がどれだけ書けるか」ではない。AI が大量にコードを書き、レビューにも入るとき、SDLC のどこで安全性を確認し、誰が承認し、どのログで説明するかという統制設計である。

これは日本の開発組織にとって近い話になっている。Claude Code 2.1.216 の worktree 隔離 では、AI コーディングエージェントが触る checkout や symlink の境界が論点になった。Claude containment と権限境界 では、sandbox、egress、credential、MCP の実行境界を扱った。今回の記事は、それらを個別機能ではなく、計画、生成、CI、デプロイ、監視、ガバナンスを貫く SDLC 全体の問題として読む材料になる。

さらに Claude CISO ガイド が示したように、AI エージェントの導入判断は「ゼロリスクか」ではなく、リスクを見える範囲に閉じることへ移っている。AI-native SDLC は、その判断を開発現場のループに落とし込む話だ。

事実: AnthropicはSDLCの各段階を作り替えている

Anthropic の説明では、同社の開発速度は 2021年から2025年までと比べ、エンジニアあたりの四半期出荷コード量で大きく伸びた。Claude は coding assistant から primary creator and reviewer へ変わり、社内版 Claude Tag がコードの merge にも関わる。人間は、細かな実装すべてを書くより、意図を設定し、方向を決め、最終責任を持つ側へ寄っている。

この変化に対し、Anthropic は SDLC を plan、code、test/CI、deploy/CD、monitor、governance に分け、各段階で防御を組み直している。

Plan では、project security review を Claude で補助し、社内 policy、過去判断、関連 system の knowledge index につないでいる。重要なのは、設計書だけを入力にするのではなく、会話、過去レビュー、コードベースなど、実際に判断材料が存在する場所へ security agent を近づける点である。

Code では、CLAUDE.md や org-wide skills に secure coding guideline を埋め込む。つまり、脆弱性をあとで見つけるだけではなく、AI がコードを書く瞬間に指示とレビューを入れる。生成後の一括レビューではなく、生成中に閉ループを作る発想だ。

Test/CI では、人間のレビューだけに依存せず、複数の agentic review と deterministic review を組み合わせる。Anthropic は、PR が開かれた時点で複数の review agent が狭い焦点ごとに確認し、リスクの高い領域では人間の承認を残す構成を説明している。

Monitor では、alert triage、root cause、postmortem draft、場合によっては修正案作成まで Claude が関与する。ただし、同じ agent が自動で production へ修正を deploy するのではなく、権限と identity を分ける。ここが最も重要だ。AI が速く動けるほど、役割分離を曖昧にすると事故時の説明が難しくなる。

分析: レビュー担当者ではなくレビュー経路を設計する

ここからは分析である。

日本企業が AI コーディングを広げるとき、最初に考えがちなのは「誰が AI の書いたコードをレビューするか」だ。しかし Anthropic の記事を読む限り、本質はレビュー担当者の増員ではない。AI が生成量を増やすと、人間のレビュー待ちがすぐに詰まる。重要なのは、どのリスクをどの gate で、どの agent と deterministic tool と人間で見るかを決めることである。

低リスクな UI 修正、文言変更、社内ツールの小改修まで、すべて senior engineer が手作業で見る設計は続かない。一方で、認可、課金、個人情報、顧客データ、監査ログ、外部送信、権限変更を含む差分を AI 承認だけに寄せるのも危険だ。必要なのは、コードベースや機能をリスク tier に分け、レビュー経路を変えることだ。

たとえば、通常領域では SAST、test、AI reviewer、人間の spot check を組み合わせる。高リスク領域では、人間承認、セキュリティレビュー、追加テスト、変更後の監視を必須にする。AI reviewer は「人間の代わり」ではなく、特定の観点を高頻度に見る reviewer pool として扱うほうが現実的である。

この考え方は、日本企業の委託開発にも効く。外部ベンダーや offshore チームが AI コーディングを使う場合、提出物の量は増えるかもしれない。しかし、発注側のレビュー能力が変わらなければ、速度は品質リスクに変わる。契約や開発標準に、AI 生成コードの検証ログ、使った tool、review agent の結果、human approval の記録を含める必要がある。

AI-native SDLCで点検すべき5つの境界

第一に、生成時の指示境界である。CLAUDE.md、AGENTS.md、repo guideline、secure coding rules、禁止 API、認可パターン、ログ方針を、AI が実装前に読む場所へ置く。文章として規程に書くだけでは足りない。AI コーディングツールが実際に参照するファイル、skill、hook、template に反映する必要がある。

第二に、実行環境の境界である。Anthropic は remote VM、egress allowlist、identity boundary を重視している。日本企業では、開発者 laptop、VDI、devcontainer、cloud workspace、CI runner、委託先端末が混在しやすい。AI agent がどこで shell を動かし、どの file を読み、どの network に出られるかを、開発環境ごとに表にしたほうがよい。

第三に、レビューの境界である。AI reviewer を1つ置くだけでは、モデルの盲点がそのまま残る。Anthropic は複数 agent を狭い観点に分ける構成を説明している。日本企業でも、認可、入力検証、secret、外部送信、依存関係、データ保持、日本語仕様との整合、アクセシビリティなど、観点ごとの review を分けるほうが設計しやすい。

第四に、監視と incident response の境界である。AI が alert を読んで postmortem を書くことは有用だが、production 修正まで同じ identity に持たせると危ない。incident triage agent、code fix agent、deploy approver は分けるべきだ。agent 同士が Slack や GitHub 上で連携する場合も、それ自体を権限経路として扱う必要がある。

第五に、監査ログの境界である。AI がどの issue、PR、file、tool、MCP、CI job、production log を読んだか。何を提案し、どの reviewer が承認し、どの gate を通ったか。これらが SIEM や監査基盤へ残らなければ、内部統制として説明しにくい。Anthropic と NEC の大規模 Claude 展開 のように利用者が増えるほど、個人の使い方ではなく組織の証跡設計が重要になる。

Datadog事例が示す検証ボトルネック

同じ 2026年7月21日に公開された Datadog の Claude Code 事例も補助線になる。Datadog では、AI coding tools を production code に使い、Claude Code が大きな割合を占める。記事の焦点は、agent がコードをたくさん書くことではなく、agent が生成したものをどう repeatable、verifiable、controllable にするかである。

Datadog の Temper は、agent に任意の application code を直接書かせるのではなく、仕様を出させ、deterministic kernel が検証して実行物へ変換する考え方として説明されている。ここから得られる教訓は明確だ。agentic 開発のボトルネックは、生成速度ではなく検証可能性に移る。

日本企業がここから学ぶべきことは、AI コーディング導入の評価指標を「何行書けたか」「何時間短縮したか」だけにしないことだ。仕様が残るか、テストが再現できるか、失敗時に最小反例へ縮められるか、承認された artifact と実行される artifact がずれないかを見る必要がある。

これは金融、医療、製造、公共、通信のような領域で特に重要だ。高信頼ソフトウェアでは、AI がコードを書いた事実より、検証と承認の証跡を残せるかが本番導入を左右する。AI-native SDLC は、単なる開発生産性施策ではなく、内部統制とソフトウェア品質保証の再設計である。

日本企業が今週決めるべき実務

まず、AI コーディングの対象 repo を risk tier に分ける。tier 1 は認可、課金、個人情報、production data、外部送信、監査ログ、セキュリティ境界を含む repo。tier 2 は顧客影響のある通常プロダクト。tier 3 は社内ツール、ドキュメント、検証環境。tier ごとに、使える agent、必要な review、CI gate、承認者を変える。

次に、生成前の指示ファイルを整える。Claude Code なら CLAUDE.md、他ツールなら AGENTS.md や repository instruction に、禁止事項と必須手順を置く。たとえば、認可変更は既存 helper を使う、PII を log に出さない、migration は rollback を含める、外部送信は allowlist を使う、test を追加してから完了報告する、といった実務ルールだ。

3つ目は、CI で agentic review と deterministic review を分ける。lint、typecheck、unit test、SAST、secret scanning は deterministic gate として残す。その上で、AI reviewer は「仕様とのずれ」「認可漏れ」「テスト不足」「攻撃者入力の経路」「日本語 UX の誤解」など、人間のレビュー補助として使う。AI reviewer の結果も、単なるコメントではなく evidence として保存する。

4つ目は、監視側の agent identity を分ける。alert triage agent が production log を読めるとしても、コード push、deploy、secret access は別にする。postmortem draft を書く agent、修正 PR を作る agent、merge を承認する人間を分けることで、AI の速度を活かしつつ blast radius を固定できる。

5つ目は、SIEM と監査ログの schema を決める。最低限、user、agent、session、tool、repository、file path、command、network destination、approval、CI result、merge decision を追えるようにする。AI 利用のログは、プロンプト全文を保存すればよいという話ではない。個人情報や機密情報の保持リスクを考えながら、説明責任に必要な metadata を設計する。

まとめ

Anthropic の AI-native SDLC 記事は、Claude Code の利用事例紹介ではなく、AI が開発工程の主要な実行主体になったときのセキュリティ設計を示す記事である。merged code の約80%という数字は派手だが、日本企業が注目すべきなのは、plan、code、CI、deploy、monitor、governance を通じて、生成、検証、承認、監査を閉ループ化する発想だ。

日本の開発組織は、AI コーディングを「便利な補助ツール」から「統制対象の開発経路」へ扱い直すべきだ。誰が書いたかだけでなく、どの指示で生成され、どの agent が確認し、どの deterministic gate を通り、誰が承認し、どのログで追えるか。ここを設計できる企業ほど、AI の速度を品質と説明責任に変えやすい。

出典

• How Anthropic secures its AI-native software development lifecycle - Claude by Anthropic, 2026-07-21
• Zero Trust for AI agents - Claude by Anthropic, 2026-05-27
• How Datadog built a universal machine tool for Claude Code - Claude by Anthropic, 2026-07-21