🛡️

ハーネスは進化する ── Anthropic公式security-guidance pluginを、触る前に読んでみた

に公開
AI
Security
Claude
LLMOps
Anthropic
idea

はじめに

Anthropicが、/plugin install の1行で入る公式のsecurity pluginをreleaseしました。
security-guidance ── Claude Codeにinstallすると、Claudeが書いたコードを 別のClaude が裏でレビューしてくれる、という仕組みです。

何が嬉しいのか、を先に書いてしまうと、こんなところです。

  • AIがコードを書く速度に、人間のレビューが追いつかない という現場の悩みに、Anthropic自身が公式pluginで正面から答えてきた
  • 3段階のレビュータイミング（編集ごと / ターンごと / commitごと）で、コストとカバレッジが綺麗にトレードオフされている
  • 書いたClaude本人にレビューさせない（別contextのClaudeが見る）という、人間のコードレビューと同じ独立性の設計
  • どの層も書き込みやcommitを 物理的にブロックしない、書き手の自由と責任を最後まで残す設計
  • .claude/security-patterns.yaml で、自社固有の禁則ルールをdeterministicに追加できる
  • 全プランで使える（per-edit層はコスト0、end-of-turn / commit層はusage課金）、しかもOSS実装で中が読める

このあたりが、公式docを一本読み終えたあとに私の頭の中に残った、「嬉しさ」のリストです。

少し時系列を整理しておくと、私はちょうど今朝、Anthropic Managed Agentsのレビュー記事を書き終えたばかりでした。そのとき中心に据えたのが、Isabella He さんの "Harnesses should evolve alongside your agents." という一文です。そして夕方、まさにその「ハーネスが進化する」という発想を、Anthropicがもう一段別の文脈で実装してきたのが、このsecurity-guidance pluginでした。

公式doc:

https://code.claude.com/docs/en/security-guidance

この記事は、触れていない状態で書きます。あえてinstallする前の、最初の公式doc読み込みの感触を、自分の言葉で残しておきたかったのです。明日以降、実際にinstallして動かしたうえで「触ってみた」記事を別途書こうと思っていますが、まずは 「初読の整理」 をひとつの記事として残すことにしました。

この記事のながれ

  1. 偶然と、たぶん偶然ではないこと — ハーネスの議論の延長線として、このpluginを読む
  2. 同じ日に動いていた、別のレイヤの「ハーネス」 — 組織と人材のレイヤでも、ハーネスは進化している
  3. pluginが解こうとしている問題 — AI速度にsecurityレビューが追いつかない、という現場感
  4. 三層構造を読み解く — per-edit / end-of-turn / commit、それぞれが解放するもの
  5. 「別のClaude」が見るという設計 — レビュアーの独立性、自己採点しない構造
  6. おわりに — 技術・組織・人材、3層のハーネスを同じ速度で進化させる時代

1. 偶然と、たぶん偶然ではないこと

ここでは、このpluginが「ハーネスは進化する」という大きな流れの中で、どの位置にあるのかを整理してみます。

朝書いた記事の中で、私はIsabella He さんの "Harnesses should evolve alongside your agents." を、技術仕様の話だけではなく、Anthropic自身が組織としてagentの動かし方を再発明し続けるという宣言として読みました。そして記事の最後に、「ハーネスがエージェントと共に進化するのなら、自分自身の頭の中の枠組みも、同じように進化させ続けないといけない」と書きました。

その読み方が、半日後にearly testされる形になりました。Anthropicは今日、agentが書いたコードをagent自身（の別instance）にレビューさせる、という新しい種類のハーネスを公式pluginとしてreleaseしてきたのです。

これは「runtimeとしてのハーネス」だけでなく、「観察と再帰のハーネス」 の方向にも進化が伸びている、というシグナルなのではないかと、私は受け取りました。

ここで感じたこと: 朝のハーネスの記事と、夕方のsecurity-guidance pluginのニュースが、同じ「agent loopの進化」の異なる音 であることに気づいた瞬間、Anthropicがどこを向いて動いているか、の輪郭がまた一段はっきりした気がしました。半日違いで降りてきた二つの素材は、私の中ではきれいに同じ和音の中に響いて、しばらく頭の中で鳴り続けそうな気がしています。

2. 同じ日に動いていた、別のレイヤの「ハーネス」

ここでは、このpluginと同じ日に起きていた、もう少し別のレイヤの「ハーネス」の動きを並べてみます。今日（2026年5月27日）は、振り返ってみると、技術・組織・人材という3つのレイヤで同時にハーネスが進化した、しばらく覚えておきたい一日になりそうです。

実はこのsecurity-guidance pluginのニュースが流れてきたのと、ほぼ同じタイミングで、もう一つの大きな発表が流れていました。日本国内では、富士通とAnthropicの戦略的パートナーシップ締結のニュースです。

当社グループ全社員（約10万人）がAnthropicの「Claude」を自ら活用して、業務の高度化、高速化を実施しながら、AIを安心・安全に使える形を実践的に検証していきます。
── 富士通プレスリリース（2026年5月27日）

10万人規模の組織が、AnthropicのClaudeを業務に組み込んでいく。これはモデルそのものを動かす「技術ハーネス」ではなく、組織がAIをどう動かすか、という「組織のハーネス」 の話に見えました。

それから、人の流れもまた、同じレイヤを動かしている気がしています。

  • OpenAI共同創業者のAndrej Karpathyが、Anthropicへ（2026年5月19日、pre-training teamに合流）
  • 「OpenClaw」の開発者であるPeter Steinbergerが、OpenAIへ（2026年2月15日、"next generation of personal agents" を担当）

ここがちょっと味わい深いところで、OpenClawって元々は "Clawdbot" という名前でClaude上に作られた、いわばオープンソース版の「エージェント・ハーネス」なんですよね（Anthropicからの法務指摘で改名した経緯あり）。

そのオープンソース・ハーネスを設計した張本人がOpenAIに移り、AnthropicはAnthropicで、自社製の一級市民ハーネスとしてManaged Agentsをパブリックベータで送り出している。

同じ「エージェント・ハーネス」というレイヤで、誰がどこからどこへ動くか。AIの「次の数年」がどこで形作られていくのか、その地形が組み変わっている最中だと感じます。正直なところ、こうした流れの中に身を置けていること自体が、わくわくします。

ここで感じたこと: 朝に読んだIsabella Heさんの "Harnesses should evolve alongside your agents." という一文は、もしかすると 技術のハーネスだけを指していたわけではない のかもしれません。組織のハーネス（運用基盤・人材・知見）も、人材のハーネス（誰がどのチームでどのレイヤを動かしているか）も、同じスピードで進化させていく時代に入ってきている ── 言い換えれば、組織の意思決定も、人材の配置も、技術ハーネスと同じスピードで動かしていく時代に入った、ということなのかもしれません。半日違いで降りてきた一連のニュースを並べてみて、改めてそう感じています。

3. pluginが解こうとしている問題

ここでは、このpluginがそもそもどんな現場課題に手をつけているのか、を整理してみます。

公式docは、pluginの役割をかなり淡々と説明しています。意訳すると、「Claudeが書いたコードを、Claude自身が（別のcontextで）同じsessionの中でレビューして、見つけた問題を同じsessionの中で直す」というものです。Pull Requestまで届く前に、編集中の段階でsecurityレビューを差し込む、と言い換えてもよいかもしれません。

私自身、AI Solutions Architectとして、お客様と一緒にAIを使ったコード生成のワークフローを設計する場面が増えてきました。生成されたコードのsecurityをどう担保するか、という問いは、もはや「いつか考えること」ではなく「毎案件の前提条件」になってきています。

「injectionが紛れていないか」「pickle で危険なdeserializationをしていないか」「.innerHTML に外部入力をそのまま渡していないか」

こうした観点を毎ファイル・毎差分で手動で見るのは、AIが高速にコードを生み出す現実とは、率直に言って時間軸が合いません。

ここで感じたこと: このpluginの発想は、「securityレビューを後工程に置く」のではなく「書いている最中に挟む」というものでした。私の頭の中では、これは 「人間レビュアーの限られた時間と、AIの生成速度のミスマッチ」 を、別のAIを観察者として挟むことで埋めにきた設計に見えました。AIでAIを見る、と聞いた瞬間に少し身構えるところがあるのですが、後述する独立性の設計を読むと、その違和感はかなりほどけていきます。

4. 三層構造を読み解く

ここでは、pluginが用意した三つの検査層を、それぞれが「前の層から何を解放し、何を依然として残しているか」という観点で読み解いてみます。

公式docには、レビュータイミングが三つに分けて書かれています。

層 発火タイミング コスト 何を見るか
第1層 Claudeがファイルに書き込んだ直後 コスト0（model呼び出しなし） eval(、pickle、dangerouslySetInnerHTML 等、deterministicなpattern
第2層 turnの終わり usage課金あり そのturnのgit diff全体を別contextのClaudeがレビュー
第3層 Claudeがcommit / pushした時 usage課金あり、agentic 周辺コードまで読みに行く深いレビュー（rate limit 20/h）

ここで感じたこと: 三層の組み立てが、私には素直にきれいに映りました。第1層は速さと確実性のためにmodelを捨て、第2層は文脈を拾うためにmodelを呼び、第3層は周辺コードまで読みに行くためにagenticにする。全部を一段で完璧にやろうとしていない、という割り切りが、各段の役割をくっきりさせています。

これは、私が普段触っているクラウド / SREの世界で言う「defense in depth（多層防御）」と、ほぼ同じ発想に思えました。

第1層は、コスト0の代わりに、文字列マッチで見える範囲しか拾えません。eval( を書いたら必ず引っかかる確実性と引き換えに、業務ロジックの脆弱性は当然見つけられない、という割り切りです。それでも、deterministicに拾える種類のリスクを、deterministicに確実に拾う という設計は、第一段の役割としては十分に機能していると感じました。

第2層では、turnの終わりに そのturn中に変わったファイルdiffを、別contextのClaudeにレビューさせる 構造になっています。ここでdocが一文だけ、しかし強い言葉で書いていることがあります。

The plugin does not ask the same Claude instance that wrote the code to grade itself.

「コードを書いたClaude本人に、そのClaude自身をgradeさせない」。これは次の章で詳しく書きます。

5. 「別のClaude」が見るという設計

ここでは、このpluginがいちばん大切に作っている設計判断、レビュアーの独立性 について整理してみます。

公式docには、こう書かれています。

The per-edit check is a deterministic string match with no model involved. The end-of-turn and commit reviews run as a separate Claude call with a fresh context and a security-focused prompt: the reviewer starts from the diff, has no investment in the original approach, and is instructed only to find problems.

意訳すると、第1層はmodelなしのdeterministic check、第2層・第3層は fresh contextの別Claude が、security専用promptでdiffだけを見る。レビュアーは元のapproachへの投資もなく、問題を探すことだけを指示されている、という構造になっています。

ここで感じたこと: この一文に、今日いちばん心に残りました。人間のコードレビュー界隈で何十年も使われてきた「作者と別の人がレビューする」という大原則を、AnthropicはAIのレイヤで丁寧に再現してきたな、と感じたからです。一見すると当たり前の原則に思えますが、「AIがAIをreviewする」と聞いた瞬間に身構える人が多いことを考えると、ここを正面から設計してきたのは、私にとっては大きな判断に映りました。

AIが高速にコードを生む時代になっても、「自分が書いたものに点をつけるな」というレビューの大原則は、人間と同じやり方で適用される。

技術が変わっても、レビューの哲学は変わらない。むしろAIが速いからこそ、レビュアーの独立性は何重にも担保しておきたい — これは、私自身がお客様との会話の中で、繰り返し説明していくべきテーマだと、改めて感じました。

それからもう一点、私が個人的に好きな設計があります。このpluginは、どの層も書き込みやcommitを物理的にブロックしない、という点です。

None of the layers block writes or commits. Findings reach the writing Claude as instructions, Claude addresses them in the conversation

意訳すると、どの層も書き込みやcommitを 物理的には止めない。findingsは書く側のClaudeにinstructionとして渡され、Claudeが直すかどうかをjudgeする、という設計です。

ここで感じたこと: securityガードが厳格になればなるほど、書き手の自由が削られて、結果として 迂回されるようになる ── これはsecurityの現場で、何度も繰り返されてきた失敗だと思います。Anthropicがブロックしない設計を選んだのは、自由と責任のラインを動かさないための、賢明な判断だと私は受け取りました。書き手は最後まで自由で、その代わり最後まで責任を負う。AIが書く時代でも、ここの線は人間が書く時代と同じ場所にあるのだと、改めて感じています。

おわりに

ここまで、公式docを一本読んだだけの整理を書いてきました。まだinstallしていませんし、触ってもいません。それでもこのタイミングで書いておきたかったのは、今日このpluginを読んだエンジニアの頭の中の地図を、忘れないうちに残しておきたかったからです。

朝書いたManaged Agentsの記事で、私はIsabella He さんの "Harnesses should evolve alongside your agents." という一文を中心に据えて、「ハーネスがエージェントと共に進化するのなら、自分の頭の中の枠組みも、同じように進化させ続けないといけない」と書きました。

そして夕方、security-guidance pluginのニュースが流れてきて、Anthropicがまさにハーネスを進化させている瞬間に、こちらは記事を書きながら自分の頭の中の地図を更新していました。

それと前後して、富士通とAnthropicの戦略的パートナーシップが発表され、KarpathyさんやSteinbergerさんといった看板エンジニアが大手AIラボの間を移動しているニュースも流れてきました。

技術ハーネス・組織ハーネス・人材のハーネス、3つのレイヤが同じ日に動いていた

そんな日として、私はこれから先もしばらく覚えていると思います。

ハーネスが進化するのなら、それを読み解くエンジニアの言語もまた、進化させ続けないといけない

そんなことを、改めて感じています。

明日以降、Phase Bの作業と並行に、このpluginを実際にinstallして動かしてみる予定です。初読の整理と実体験の間に、どれくらいのズレが生まれるか、それをもう一本の記事として残せたら、と思っています。今回の整理はそのための足場として、まずはこのままここに置いておきます。

技術が変わっても、レビューの哲学は変わらない。
むしろAIが速くなる時代だからこそ、独立性と責任のラインを、何度でも丁寧に作り直す価値があるのだと思います。

そして同時に、日本の重要インフラ領域にAIを実装していく仕事に、より深く関わっていきたい

今日の一連の発表を見ていて、改めてそう感じています。

参考リンク

Discussion