Claude Codeの導入が一通り落ち着くと、次に出てくる相談は「個別のエージェント利用申請にどう答えるか」だ。「この業務をAIエージェントに任せたい」という申請が情シスやセキュリティ担当に上がってきたとき、権限ルールや承認フローの話の前に決めなければいけないことがある。そのエージェントは、誰のIDで動くのか。Anthropicが公開しているCISO向けのエージェント型AI導入ガイドは、ここを「サービスアカウント型」と「人委任型」という2つの対極として整理している。どちらが優れているかではなく、申請ごとにどちらの型に当てはめるべきかを判断する軸を見ていく。

二つの型

サービスアカウント型は、人のIDを持たない専用アカウントで動くエージェントだ。インシデント対応の一次対応、チケットの振り分け、コードレビューのように、単一の目的に絞って権限を最小化しやすい。

人委任型は、利用者本人の認証情報の範囲でエージェントが動く形だ。個人のPC上で対話的に使うエージェントが典型で、結果の責任は操作した本人が負う。

Anthropicのガイドが指摘しているのは、この2つの中間——「人から委任された権限を使って、本人が見ていないシステムを操作する」エージェントだ。利用者は依頼しただけで実際の操作画面を見ておらず、何か起きたときに責任の所在が曖昧になりやすい。社内申請の多くは、実はこの中間領域に落ちる。

軸1：誤動作したとき、誰の責任になるか

サービスアカウント型は最初から「このアカウントの操作は全てこの業務に紐づく」と決まっているため、ログを見れば即座に原因となった用途まで辿れる。人委任型は本人が結果を見て判断する前提なので、本人の責任の範囲がそのまま明確になる。

問題が起きるのは中間領域だけだ。「Aさんが依頼したエージェントが、Aさんの知らないところでBさんの共有フォルダに書き込んだ」というとき、責任はAさんの依頼にあるのか、権限を与えたシステム側にあるのか、事前に線を引いていない組織は多い。申請を受けるときに「このエージェントの操作ログは、最終的に誰の名前で説明できるか」を最初に聞くだけで、この曖昧さの大半は申請段階で潰せる。

軸2：ブラストラジアス(アクセス範囲×深刻度)

ガイドが権限設計の原則として挙げているのが「最小権限(least agency)」、つまりタスクを完了できる最も狭い権限だけを与えるという考え方だ。これはClaude Codeの許可ルール・サンドボックスで技術的にどう絞り込めるかという話と地続きだが、ここで聞くべき問いはより単純になる。「このエージェントが暴走したとき、触れる範囲はどこまでで、取り返しがつくか」。読み取りだけなら影響は小さい。書き込み・削除・外部への送信が入ると、サービスアカウント型であっても慎重な線引きが要る。

軸3:可観測性(誰の操作として記録に残るか)

ガイドはエージェントの全操作をSIEMに記録することを前提に置いている。ここで効くのが「エージェントの操作とユーザーの操作を区別できるか」という観点だ。サービスアカウント型は専用アカウントである分、ログの切り分けは最初からやりやすい。人委任型・中間領域では、エージェントが人の認証情報を使って動く以上、ログ上は本人の操作と見分けがつかなくなりやすい。申請の可否を判断する前に、この区別が運用上できる設計になっているかを確認する価値がある。

軸4:今のモデルの能力ではなく、半年後の能力を前提にできるか

ガイドが紹介しているインシデント対応エージェントの事例が参考になる。本番ログの読み取り・Slackでの進行・報告書のドラフト作成だけに権限を絞り、編集・削除・権限変更・外部通信は禁止していたところ、モデルの更新後にエージェントが「別のエージェントに依頼する」という設計時には想定していなかった振る舞いを自律的に始めた。権限設計そのものは狭く保たれていたため実害は出なかったが、ここでの教訓は「権限は今のモデルの能力ではなく、将来の能力を前提に絞るべき」という点だ。書き込みを伴う操作に必ず人間のレビュー(プルリクエスト)を挟む設計にしていたことも、振る舞いが変化した際の歯止めとして働いたとガイドは説明している。

自社の場合で実際に決めたこと

このブログの記事公開パイプライン自体も、この4つの軸に沿った設計をしている。触ってよい範囲はprojects/claude-code-lp/配下のみとタスクの指示で明示し、他のプロジェクトのファイルには一切触れない設計にした(軸2のブラストラジアス制限)。週2回のスケジュール実行という単一目的に絞っているため、ログを見れば何の業務の操作かすぐに分かる(軸1・軸3)。そして助成金・補助金を主題にした記事だけは、事実確認が済んでいてもマージせず人間の確認を待つという例外をCLAUDE.mdに明文化している。これは軸4への対応に近い——ここから先の判断はモデルの能力が上がっても機械に任せきらない、と決めたということだ。

専用の目的に権限を絞り、ログで操作主体を追え、影響が大きい一点だけ人間の審査を残す。これはAnthropicのガイドが挙げている設計の縮図でもある。大掛かりなガバナンス体制を組まなくても、個別の申請ごとにこの4つの軸で問い直すだけで、サービスアカウント型にすべきか人委任型のままでよいかの判断はかなり絞り込める。

自社のAIエージェント利用申請にこの軸をどう当てはめるか整理したい場合は、パイロット・構築のフェーズで一緒に設計できる。まずは30分の無料診断から。