【組織のAI活用#238】Claude Codeのデフォルトが自動モードに。導入企業の情シスが押さえておきたいこと

こんにちは！寺田です。

現在は、デジタル関連会社のAI推進者などのAI活用者のコミュニティである「AI Digital Community (ADC)」の代表理事や、顧客事業の「×AI化」をサポートするFURIKAKE Partners(株)と組織のAI活用を支援するプロダクトを提供するAI Portalize(株)の代表取締役を務めており、様々な側面から組織のAI活用をサポートしています！

今回は「Claude Codeのデフォルト権限モードが自動モードに変わる件」について、情報システム部門（情シス）やセキュリティ担当の方が何を押さえておくべきかを整理してまとめてみました。

社内でも「これはどう捉えればいいのか」という話になったのですが、私自身は今回の変更で安全性はむしろ高まる方向だと考えています。ただし、そのためには会社側でいくつか設定しておく必要があります。

まず、何がどう変わるのか

8月14日から、Claude Codeのデフォルトの権限モードが「自動モード」に変わります。対象はPro・Max・Teamプランで、新規セッションから適用されます。

これまでのClaude Codeは、コマンドを実行するたびに人へ「これを実行していいですか」と確認していました。自動モードでは、その確認の代わりに、一つひとつの操作を専用の判定器に通す形になります。

判定器が止めるのは、取り返しがつかない操作、破壊的な操作、そして自分の作業環境の外に向かう操作です。止められた場合、Claudeは安全な代替手段を探すか、あらためて人に確認します。

無制限に自動で進むわけでもありません。3回続けて止められるか、セッション全体で20回止められると、手動承認モードに戻る仕組みになっています。

なお、すでに自分で既定のモードを設定している場合、その設定は維持されます。会社が管理設定で既定を指定している場合も変わりません。影響を受けるのは「特に何も設定していない人」ということになります。

「毎回確認する」ほうが安全とは限らない

今回の変更の背景にあるのは、「承認疲れ」という考え方です。何十回も確認を求められると、人は流れ作業で許可してしまう、というものです。

Anthropicが公開しているデータでは、次のような結果が示されています。

• ユーザーは提示された確認の97%を承認している

• 1,053人のテスターによる検証で、危険なコマンドを人が見抜けたのは13.6%にとどまったのに対し、自動モードは89%を止めた

• 人が見抜ける割合はセッションが長くなるほど落ち、当初17%が50回の確認を過ぎると5%まで低下した。一方で自動モードが止める割合は変わらなかった

私が重要だと思うのは最後の点です。人の確認は回数が増えるほど劣化するのに対し、判定器は劣化しないという部分です。

なお、これはAnthropic自身による検証結果なので、第三者の評価ではない点は踏まえておく必要があります。

非エンジニアが使う場面ほど、この変更は効いてきます

ここが、組織のAI活用という観点でいちばん大きいところだと思っています。

社内でAI活用が広がっていくと、コマンドの危険性を自分で判断できない人がClaude Codeを使う場面が増えていきます。

そうした方にとって、「このコマンドを実行していいですか」と聞かれても、判断する材料がありません。結果として、内容を吟味せずに許可を押し続けることになります。先ほどの「97%を承認している」という数字は、まさにこの状態を表しています。

判定器が代わりに止めてくれるのであれば、そのほうが安全なケースは多いはずです。

逆に言えば、自分で危険性を判断できるエンジニアにとっては、この変更の恩恵は相対的に小さいものです。今回の変更は、AI活用を非エンジニアに広げていく組織ほど意味が大きいと捉えています。

情シスの役割は「使わせない」ではなく「枠を決めて配る」

そのうえで情シスの立ち位置を考えると、今回の変更で問われるのは利用可否の判断ではなく、枠組みの設計だと思っています。

これまでは、危険な操作を止める最後の砦が「現場のユーザーが承認画面で判断すること」でした。今後はそこが判定器に置き換わります。

ただし、判定器が見ているのは、タスクの範囲を超えた操作や、外部に情報を持ち出そうとする操作といった、どの会社にも共通する危険です。自社の本番データベースの接続情報がどのファイルに置いてあるか、といった自社固有の事情までは知りません。

もう1つ実務的に大きいのが、判定器は初期状態では作業中のフォルダと、そのリポジトリに設定された接続先しか信頼しないという点です。

つまり、自社のソース管理サービスへの反映や、チームで使っているクラウドストレージへの書き込みは、「外部に持ち出そうとしている」と判断されて止まります。安全側に倒れる設計ではありますが、何も設定しないままだと日常業務が止まる場面が出てきます。

汎用的な危険は判定器に任せ、自社固有の事情は情シスが設定として渡す。この切り分けが、今回いちばん整理しておきたいところです。

情シスとして設定しておきたい3つのこと

Claude Codeには、組織の管理者が全ユーザーへまとめて配布できる設定の仕組みがあります。ここでは「何のために設定するのか」「設定すると何ができるようになるのか」という観点で、押さえておきたい3つを紹介します。

なお、細かい書き方は公式ドキュメントにまとまっていますが、項目名だけを見てもイメージしづらいと思うので、目的から説明します。

1. 絶対にやらせない操作を決めておく

何のために設定するのか。判定器の判断より前に評価され、判定器にもユーザーの意図にも上書きされない、最後の砦を作るためです。

自動モードの判定器は、あくまで汎用的な判断をするものです。「本番環境に触るな」「この経路でデータを外に出すな」といった自社固有の禁止事項は、ここで明示しないと守られません。

設定すると何ができるか。指定した操作は、ユーザーが「これをやって」と明示的に指示しても実行されなくなります。会社として越えられては困る一線を、確実に止められる状態になります。

2. 必ず人を挟む操作を決めておく

何のために設定するのか。自動モードは使いつつ、要所だけは必ず人が確認する状態を作るためです。

設定すると何ができるか。指定した操作については、自動モードのままでも必ず確認画面が表示されます。判定器が自動で許可することはできません。

たとえば、外部への反映や公開に近い操作をここに入れておけば、「普段の作業はスムーズに進むけれど、外に出る瞬間だけは人が見る」という運用にできます。全部を止めるか、全部を任せるかの二択にしなくて済むのがポイントです。

現場から「自動モードだと不安だ」という声が上がったときも、ここを厚くすることで折り合いをつけられます。

3. 自社の「信頼していい範囲」を教えておく

何のために設定するのか。先ほど触れたとおり、判定器は初期状態で自社の環境を知らないためです。

設定すると何ができるか。自社のソース管理組織、社内のドメイン、業務で使うクラウドストレージ、社内システム、社内向けのパッケージ配布先などを登録しておくと、それらへの操作は「外部への持ち出し」と判断されなくなります。

これをやらないと、社内の正常な業務まで止まってしまい、「自動モードは使いものにならない」という評価になりかねません。逆にきちんと登録しておけば、日常業務は止めずに、本当に外部へ出ようとする操作だけを止めるという状態に近づきます。

登録は難しい書式ではなく、「うちのソース管理はここ」「社内で使っているストレージはこれ」といった説明を、新しく入った社員に環境を説明するときの言葉づかいでそのまま書く形です。最初から完璧に埋める必要はなく、止められた場面を見ながら足していけば十分です。

あわせて知っておきたい3点

1つ目は、設定の置き場所に決まりがあることです。信頼範囲の設定は、プロジェクトの中に置かれた設定ファイルからは読み込まれません。リポジトリに紛れ込んだ設定によって、勝手に許可の範囲を広げられることを防ぐためです。会社として配る設定は、組織向けの管理設定に置く必要があります。

2つ目は、「絶対にやらせない」と「なるべくやらせない」が別物だということです。個人が自分の設定で追加した許可は、組織側の緩やかな禁止を上回ることがあります。ここは絶対に越えさせたくない、という線は、必ず1つ目の「絶対にやらせない操作」のほうで指定してください。

3つ目は、プロジェクトの方針書も判定器が読むことです。Claude Codeがプロジェクトごとに読み込む方針ファイルの内容は、判定器も同じように読みます。「この環境では強制的な上書きをしない」といった方針をそこに書いておけば、Claude本体と判定器の両方に同時に効きます。全社の設定は情シスが、プロジェクト固有の作法は現場が書く、という分担ができます。

私の見解として、この変更は受け入れてよいと考えています

あらためて整理すると、私は今回のデフォルト変更をそのまま適用してよいと考えています。理由は3つです。

1つ目は、あくまでデフォルト値であり、ユーザーがセッションごとに変更できることです。合わない場面では手動に戻せます。

2つ目は、危険な実行の判断に慣れていない人ほど、ガードレールに任せたほうが安全なことです。社内でAI活用が広がるほど、この比重は大きくなっていきます。

3つ目は、人の確認は疲労で劣化するのに対し、判定器は劣化しないことです。

ただし、これは「何も設定しなくていい」という意味ではありません。判定器が守ってくれるのは汎用的な危険までで、自社固有の危険は情シス側で指定しておく必要があるという前提つきです。

まずは自社の現状を確認するところから

社内でのアプリ開発が増えてくると、このあたりの整備は避けて通れなくなります。

とはいえ、最初から完璧な設定を用意する必要はありません。まずは自社がどのプランで使っていて、今どのモードで動いているのかを確認する。そのうえで「絶対にやらせない操作」と「必ず人を挟む操作」の2つだけでも決めておく。それだけでも、状況はかなり変わります。

なお、組織としてまとめて設定を配れるのは、チーム向け・法人向けのプランになります。個人プランのまま業務で使っている場合は、情シスとして統制をかける手段がない点も押さえておきたいところです。

ぜひ、社内でClaude Codeを使っているのが誰で、今どのモードで動いているのかを確認するところから始めていただければなと思います！

読んでいただきありがとうございました！
過去のAI関連記事はこちらです！

ちなみに、組織におけるAIの推進についてまとめた本も出版させていただいております。もしよければご覧ください。