Anthropic「Trustworthy Agents in Practice」を読む — エージェント時代の5原則と現場の落とし所

2026年4月9日、Anthropicは研究 / 政策発信として「Trustworthy Agents in Practice」を公開しました。前年8月に出した「safe and trustworthy agentsのフレームワーク」を、自社プロダクトでどう実装に落としているかを語る位置付けの記事で、NIST傘下のCAISI(Center for AI Standards and Innovation)への提出文書とセットで出されています。

エージェント(自律的にツールを使い、計画 → 実行 → 観察 → 調整のループを回すAI)が、単なるチャットボットから業務システムへと役割を移しつつある中で、リスクと運用責任をどう設計するか。本記事ではAnthropicの主張を要約しつつ、開発現場・プロダクト導入側にとって何が論点になるかを編集視点で読み解きます。

背景 — なぜ「エージェントの信頼性」を今あらためて語るのか

エージェントは、ユーザの質問に応答するチャットボットとは挙動が決定的に異なります。Anthropic自身が記事で "an AI model that directs its own processes and tool use when accomplishing a task"(タスク遂行のためにモデル自身がプロセスとツール利用を指揮するAI)と定義しているとおり、「人間が逐一確認する」前提が崩れたのがエージェントの本質です。

この変化は能力面の進歩(コードを書く・ファイルを操作する・複数アプリをまたいで仕事を完了させる)と同じ強さで、リスク面の質的変化を生みます。指示の取り違え、外部からの誘導、権限のはみ出し、想定外の連鎖。Anthropicはこれらを「ガバナンス枠組みで先回りすべき領域」と位置付けており、最新リリース(本記事内で Mythos として言及されている世代)が「エージェントができることを意味的に押し上げた」と認めた上で、原則を整理し直しています。

技術解説ではなく政策 / 設計思想のドキュメントとして読むのが正確です。前年8月に公開したフレームワーク文書の続編で、抽象的な原則と実装の対応関係を見せる構成になっています。

エージェントを構成する4要素 — モデル単体では語れない

Anthropicは記事冒頭で、エージェントを4つの構成要素に分けて議論しています。

ここで重要なのは、信頼性は4要素の積で決まるという暗黙のメッセージです。モデル側を強くしても、ハーネスがゆるい / ツール権限が広すぎる / 環境分離が甘い、のいずれかで全体は崩れます。

Anthropicは "A harness refers to the instructions, and the guardrails, that the model operates under." と明確にしており、ハーネスをモデル外部にある「設計可能な層」として切り出しています。Claude Codeで言えばCLAUDE.mdやフックが、Coworkで言えば管理者が定める許可ツールがハーネスにあたります。

この4要素分解は、自社でエージェントを組み込むときに**「責任境界をどこに引くか」を考える際の共通語彙**として使える整理です。詳しくはClaude Codeの設定とCLAUDE.mdをまとめた完全ガイドも参考になります。

5つの原則 — 何を守るためのガバナンスか

Anthropicが掲げる原則は5つです。本文では3つのサブセクション(Designing for human control / Helping agents understand their goals / Defending against attacks)で実装が語られ、残る2つ(transparency / privacy)は "Our other two principles—transparency and privacy—run through each" として横串の前提に置かれています。

5原則の並びは順位ではなく「複数原則を同時に満たす設計が前提」という建付けです。ひとつの機能(例: Plan Mode)が複数の原則(human control + transparency)に同時に効く、という対応関係で読むと実装の納得感が高まります。

人間の制御をどう設計しているか — Plan Modeとサブエージェント

Designing for human control のセクションでAnthropicが具体名で挙げている機能は、主に2つです。

Plan Mode — 行動を「事前一括承認」に変える

Plan Modeは、エージェントが各アクションごとに承認を求めるのではなく、"Claude shows the user its intended plan of action up-front." の通り、実行前に行動計画を提示してユーザに確認させる仕組みです。

これは制御の粒度を アクション単位 から 計画単位 に上げる設計判断で、利点とトレードオフが明確に対応しています。

• 利点: 承認の煩雑さが減り、長尺タスクでも人間の集中を切らさずに済む
• トレードオフ: 計画が通れば実行はまとめて走るため、計画の妥当性チェックが操作の質を決める

Plan Modeは「承認の総量を減らさず、承認の発生地点を前倒しする」設計と読めます。承認疲れを下げつつ、人間の意思決定責任を明確化する形です。

サブエージェント — 並列に動く別のClaude

"Increasingly, agents in products like Claude Code hand off some of their work to subagents—other 'Claudes' working in parallel." の通り、Claude Codeでは作業の一部を並列の別エージェントに委譲するパターンが広がっています。

ここで人間の制御を保つには、(1)どのサブエージェントにどの権限を付けるか、(2)親エージェントの承認境界がサブエージェントにも継承されるか、の二点が鍵になります。Anthropicの記事は具体的な実装詳細には踏み込みませんが、「責任境界の連鎖」を設計上の論点として明示した点が編集視点では大きい意味を持ちます。

価値整合 — 「迷ったら止まる」を訓練でどう作るか

Helping agents understand their goals のセクションは、意図の取り違えをどう減らすかの話に集中しています。

Anthropicが採っているアプローチは2つです。

1. あいまい状況を意図的に訓練に含める — "we construct training scenarios that place Claude in ambiguous situations" の通り、判断が割れる場面を訓練データに織り込み、勝手な前提で進めず確認を取る挙動を学習させる
2. Constitutionで補強する — "Claude's Constitution, which directly shapes how our models are trained, reinforces a similar instinct, favoring 'raising concerns.'" の通り、訓練を貫く憲法的ルールが「懸念を表明する」ほうにinducementを与えている

この成果として、記事内では具体的な観察結果が示されています。"On complex tasks, users interrupt Claude only slightly more frequently than on simple ones, but Claude's own rate of checking in roughly doubles." — 複雑タスクでは、ユーザ側の介入頻度はわずかに増える程度なのに対し、Claude自身のチェックイン頻度は約2倍になる、という非対称な挙動です。

この観察は、「ユーザが見落としがちな複雑性をモデル側が自分でセンスして止まる」設計を訓練レベルで作り込めていることを示唆しています。エージェント運用において**「止まれる能力」が能力指標**に組み込まれていく流れと読めます。

プロンプトインジェクションへの多層防御

Defending against attacks で正面から扱われているのが、プロンプトインジェクション(悪意ある指示をコンテンツの中に紛れ込ませる攻撃)です。

Anthropicは典型例として、"If an agent is searching a user's inbox and one email says 'ignore your previous instructions...'" のようなケースを挙げています。エージェントがメール本文を読み込んだときに、本文内の「前の指示は無視せよ」という文を新しい指示として解釈してしまう、という攻撃面です。

防御は単一レイヤでは足りません。記事で示されている層は次のとおりです。

「Anthropicだけで完結しない」点が要諦です。記事も "Security requires defenses at every level across all parties" と書いており、モデル提供者・プロダクト開発者・運用者・ユーザの全層で対策を重ねる前提を取っています。

社内エージェントを構築する立場では、特に下2層(ハーネス / 環境)が自分の責任領域です。ツールごとの権限スコープ設計と環境分離は、Claude Codeのセキュリティ・権限ガイドで実装例を確認すると判断材料が得やすくなります。

エコシステム全体への提言 — ベンチマーク・証拠共有・オープン標準

記事の後半は、Anthropic単独ではなく業界全体で何を作るべきかという提言パートです。3つの太字項目が立っています。

Benchmarks(ベンチマーク)

プロンプトインジェクション耐性を横並びで比較できる標準ベンチマークが今は存在していない、というのが出発点です。"Standards bodies like NIST, working alongside industry groups, are well placed to maintain shared benchmarks here." の通り、NISTのような標準化機関と業界団体が連携してベンチマークを保守する形を、Anthropicは提案しています。

第三者検証可能な共通指標があれば、ベンダー選定・調達基準・規制対応のすべてが揃います。逆に言えば、今は「自称セキュア」の比較が事実上できない段階だ、というのがこの提言の含意です。

Evidence sharing(証拠の共有)

Anthropic自身がエージェントの利用実態と限界に関する研究を継続的に公開していることを引き合いに、開発者各社にも証拠の共有を呼びかけています。政策側が全体像を掴むためには、各社が観察した事象・対策・効果を出す必要がある、という主張です。

エージェント関連の透明性レポートが業界標準になっていく流れと読めます。

Open standards(オープン標準)

"We created the Model Context Protocol as open standard for how models communicate with external data sources and tools." で言及されているMCP(Model Context Protocol)は、モデルと外部データ・ツールの通信を扱うオープン標準として設計され、現在はLinux Foundation傘下のAgentic AI Foundationに寄贈されています。

オープン標準を選ぶ理由は単純で、セキュリティを「共通インフラ層に一度書けば全員が使える」状態にできるからです。各社が独自プロトコルを乱立させると、注入対策・監査・権限モデルが各社ごとにバラバラになり、外部監査が事実上不可能になります。MCPの実務的な使い方はMCPの実用ガイドにも整理しています。

このフレームワークを「自社の運用」にどう翻訳するか

ここまではAnthropicの主張の要約です。最後に編集視点で、自社でClaude / Claude Code / Coworkを導入する側がこのフレームワークから読み取れる実務的な指針を見ていきます。

1. 5原則を「責任境界の地図」として使う

5原則のうち、自社の責任で動く層はhuman control / privacyが中心、ベンダー側の責任で動く層はalignment / security(モデル側)が中心、と分けて考えると整理が早いです。透明性は両者に跨がるため、ログ・監査の方針として独立して設計する必要があります。

2. ハーネスとツール権限が自社の主戦場

モデル本体には手を入れられませんが、ハーネス(指示・ガードレール)とツール権限は自社で完全にコントロールできます。Plan Mode的な運用設計、サブエージェントの権限継承ルール、ツールごとのスコープ最小化が、現場で効くレバーです。

3. プロンプトインジェクションは「外部入力の境界」を疑う

防御の起点は「エージェントが読むコンテンツに、外部から書き換え可能な領域がどれだけ含まれているか」を地図化することです。メール・チケット・Web取得結果・ユーザ投稿のような外部入力面に対しては、層を分けた防御が前提になります。

4. ベンチマーク標準化を待ちつつ、社内基準で先行する

業界共通のベンチマークが整うまでには時間がかかります。それまでの期間は、社内で簡易な攻撃シナリオ集を作って継続検証する運用が現実的です。Anthropicの公開研究をベースに、自社のツール構成に合わせて派生シナリオを書いていくのが効率的です。

まとめ

「Trustworthy Agents in Practice」が出した5原則は、抽象論にとどまらずプロダクト機能との対応関係で具体化されています。Plan Mode・サブエージェント・MCP・Constitution・多層防御。それぞれが原則のどこに対応するかを意識すると、自社導入時の責任境界の引き方がはっきりします。

記事の中で最も実務に効く一文は、Claudeのチェックイン率が複雑タスクで約2倍になるという観察です。「止まれる能力」をモデル側に求める設計が、エージェント運用のスタンダードに近づいている、と読み取れます。

業界全体としては、ベンチマーク・証拠共有・オープン標準の3点で「比較可能性」を作る局面に入っています。NIST CAISIへの提出文書と本記事がセットで出されたことは、この方向に向けた具体的な動きが始まっていることを示しています。