
内製環境の権限設定をどう整えるか。安全と速度を両立させる
2026/09/01
執筆:寺田昇平
AI Portalize株式会社 代表取締役/AI Digital Community 代表理事
仕組みとコンサルティング伴走支援の両面で、組織のAI活用の加速を支援。
Claude Codeのような内製の環境を整えるとき、安全側に振りすぎて使われなくなることが、よく起きます。
権限設定を、どこまで絞るかが論点です。
すべての操作に確認を求める設定にすると、確認のためのクリックが延々と続きます。
現場は「面倒だから使わない」と判断し、せっかくの環境が置物になります。
では逆に緩めればいいのでしょうか?
そう単純でもありません。
緩めすぎると意図しない操作が実行され、一度事故が起きると今度は全面的に禁止する方向へ振れてしまいます。
この両立について、整理してみます。
内製化そのものの進め方は社内AIツールの内製化。現場が自分で作れる組織にするまでにまとめてあります。

毎回の確認が多いと現場は使わなくなる
確認が多いと、何が起きるのでしょうか?
構造から見ていきます。
まず、確認が形式的になり、内容を読まずに承認するようになって、確認そのものの意味がなくなります。
次に、作業のリズムが崩れ、数秒で終わる操作のたびに確認を待たされるだけで集中が切れます。
やがて、そもそも使わなくなります。
確認を待つより手作業のほうが速いと判断されるからです。
なかでも最初の「形式的な確認」が最も危険です。
確認しているつもりで確認していない状態は、確認がない状態より悪く、確認したことになっているぶんだけ始末が悪くなります。
だから設計の方向は、確認を減らして確認すべきものだけ確認する形になります。

Claude Codeの権限設定は「元に戻せるか」で線引きする
その線引きは、どこで引けばいいのでしょうか?
判断の基準は「元に戻せるか」の一点で、ここさえ決まればほとんどの場面は判断できます。
緩めてよいのは3種類あり、読むだけの操作はファイルを読む、内容を確認するといったもので、何も変わらないので確認は要りません。
新しく作る操作も、既存のものが壊れないので緩めて構いません。
記録が残っていて戻せる変更も、同じく緩めてよい範囲に入ります。
絞るべきものも3種類あり、既存のものを消す操作、つまり削除と上書きは元に戻せません。
送信・公開・外部サービスへの連携といった外部に送る操作も、取り返しがつきません。
権限や設定を変える操作は、影響の範囲が広いことが理由になります。
配布物には、この基準だけを書きます。
条件を増やすほど読まれなくなるので、1行で済ませたほうが実際に守られます。
ここが設計の要点なのですが、元に戻せる状態を先に作れば、緩めてよい範囲そのものが広がります。
やることは3つで、まず変更の記録が残る仕組みを使い、何をいつ変えたかが分かる状態にします。
また、作業する場所を分け、本番のデータではなくコピーで作業して確認してから反映します。
さらに、定期的なバックアップも組みます。
日次で別の場所にコピーを作っておきます。
なかでも作業場所を分けることが、最も効きます。
コピーで作業する形にすれば何をしても本番が壊れないので、確認を大幅に減らせるからです。
だから順序としては、確認を減らす前にコピーで作業する形を作り、そのうえで本番に反映する操作だけに確認を集中させます。

権限は3階層で設計し、第1階層を広く取る
具体的な設計は、3階層で考えます。
第1階層は自由に操作してよい範囲で、自分の作業用の場所やコピーしたデータがここに入り、確認はありません。
第2階層は確認を入れる範囲で、共有の場所への書き込みや本番への反映について、1回の確認を挟みます。
第3階層は他の人のレビューを通す範囲で、権限の変更・外部への公開・削除は、ここで人が見ます。

要点は、第1階層を広く取ることです。
ここが狭いと作業のたびに確認が発生してしまうので、第1階層で完結する作業そのものを増やしていきます。
コピーで作業する、自分の場所で試すというふうに、環境の設計しだいで第1階層の範囲は広げられます。
また、第3階層には例外を作りません。
「今回は急ぐので」を一度認めると、基準そのものが意味を失います。
作りすぎずに小さく回す進め方は内製開発は超最小単位で回す。作りすぎて失敗しないためにで扱っています。
効果の確認として測るのは、確認の回数、作業の完了までの時間、事故の件数の3つです。
確認の回数が減って事故が増えていないなら成功で、確認の回数だけを見ていると緩めすぎている可能性を見落とします。
あわせて、確認を読んでいるかも見ます。
内容を読まずに承認していないかは本人に聞くしかありませんが、1つの作業で確認が5回を超えているようなら、設定を見直す目安になります。
事故の復旧手段を決め、設定は標準の形で配る
備えがないと、そもそも緩めることができませんが、何がここで要るのでしょうか?
決めておくのは4つで、何が起きたかを確認する手段として操作の記録を残し、「何がいつ変わったか」が分かる状態にしておきます。
元に戻す手段も要り、バックアップから戻すのか記録から戻すのかを決めて手順を文書にしておきます。
影響の範囲を確認する手段では、他の人の作業に影響していないかを見ます。
報告の経路では、誰に報告するかを決めておきます。
「報告しても責めない」と明示することも重要です。
報告されないと対応が遅れて被害が広がるので、隠されるくらいなら早く上がってきたほうがいいという考え方です。
さらに、復旧の手順は実際に試しておきます。
「バックアップから戻せます」と言っていても、試していなければ必要なときに戻せません。
年に一度、30分あれば足ります。

設定のほうは、各自が自分で設定する状態だと3つの問題が起きます。
設定が分からず初期の状態のまま使ってしまい、確認が多くて使わなくなる人が出ます。
面倒なので全部を許可してしまい、緩めすぎる人も出ます。
さらに、基準が変わっても各自の設定は変わらず、更新が反映されません。
だから標準の設定を配り、配る形はそのまま使える設定のファイルと設定の意味を説明する1枚の2つです。
何が許可されていて何が確認を求められるかを理解していないと、勝手に変えられてしまいます。

あわせて、変えてよい範囲も明示します。
「第1階層の範囲は自分で広げてよい」「第3階層は変えない」という形です。
そして更新の経路も作り、標準の設定が変わったら通知して貼り直してもらいます。
多い失敗は、確認を減らす順序を間違えるところから始まる
すべての操作に確認を求めることが、最初の失敗です。
確認が形式的になっていき、最終的に使われなくなります。
元に戻せる状態を作る前に確認を緩めてしまうことも、よくある失敗です。
元に戻せる状態を先に作るという順序が、ここでは重要になります。
第1階層を狭く取ることも失敗で、これをやると作業のたびに確認が発生します。
第3階層に例外を作ることも失敗で、一度認めると基準が意味を失います。
復旧の手順を試さないことも失敗です。
必要なときに戻せないので、年に一度は試します。
各自に設定を任せることも失敗です。
分からず初期の状態で使うか、逆に緩めすぎる人が出ます。
情シスに「緩めたい」とだけ提案することも失敗です。
これはまず受け入れられないので、元に戻せる状態を先に作ってから提案します。
安全な環境整備は、情シスとの協働で設計する
この領域は、情シスとの合意なしには進みません。
管理外の操作が行われる、データが壊れる、外部に情報が出る。
情シスの懸念はそもそも正当です。
「緩めたい」という提案は、情シスから見ればリスクだけが増えるように見えます。
だから「元に戻せる状態を先に作る」という順序で提案します。
バックアップ、作業場所の分離、操作の記録を整えたうえで、緩める範囲のほうを提案します。
あわせて第3階層だけを情シスが見る形にすると、すべてを見るよりも情シス側の負荷が下がります。
現場のツールが業務データに触り始めたときの線引きは現場が作ったツールが業務データに触り始めたら。個人利用と法人利用の境界で扱っています。
難しいのは、両者の関心が違うところです。
推進担当は速度を上げたく、情シスは安全を守りたい。
どちらも正当な関心で、そのうえで「元に戻せる状態を作る」ことは両者の関心を同時に満たすので、ここが合意の起点になります。
ただし実装には技術的な設計が必要で、バックアップの仕組み、作業場所の分離、操作の記録を整えるのは情シスの領域になります。
さらに組織によって使っているサービスも既存の権限設計も規程の内容も違うので、汎用の設計をそのまま当てることはできません。
私たちが提供しているAI推進の伴走支援では、こうした環境の整備を情シスと一緒に設計するところから進めています。
安全側に振りすぎて使われない、という状態で止まっている場合は、進め方の参考になるかもしれません。
元に戻せる状態を先に作れば、緩めてよい範囲が広がる
確認が多いと確認が形式的になり、作業のリズムが崩れ、やがて使われなくなります。
最初の「形式的な確認」が最も危険なので、確認を減らして確認すべきものだけ確認する方向で設計します。
線引きの基準は「元に戻せるか」の一点です。
緩めてよいのは読むだけ・新しく作る・元に戻せる変更で、絞るべきは消す・外部に送る・権限や設定を変えるの3つです。
あわせて、元に戻せる状態を先に作ります。
変更の記録、作業場所を分けてコピーで作業すること、バックアップの3つで、確認を減らす前にここを済ませます。
権限は3階層で、第1階層を広く取り、第2階層は1回の確認、第3階層は人が見ます。
第3階層に例外は作りません。
復旧手段は4つ決めて年に一度実際に試し、「報告しても責めない」と明示します。
設定は標準の形を配り、意味を1枚で説明して、変えてよい範囲を明示します。
情シスへの提案は、元に戻せる状態を先に作ってから緩める範囲を出すという順序を守ると、合意が得やすくなります。
まずは自分の作業について、1つの作業で何回確認が発生しているかを数えてみてください。
すぐ使える業務アプリが300以上
開いてそのまま使えて、AIで自社用にも直せます。15の分野から、やりたい作業で探せます。業務アプリを見る
執筆:寺田昇平
AI Portalize株式会社 代表取締役/AI Digital Community 代表理事
仕組みとコンサルティング伴走支援の両面で、組織のAI活用の加速を支援。
お知らせ・組織AI推進ナレッジ一覧










