Claude Codeを社内で使い始める。初期設定と安全設計

Claude Codeのように開発の作業を任せられる環境は、便利さが分かりやすい領域だと思います。
コードを書く、ファイルを編集する、コマンドを実行する。
ここまで任せられるので、作業は明確に速くなります。

ところが、その便利さの前に決めておくことがあります。
権限が広いぶん、事故が起きたときの影響も大きいからです。

ということで、使い始める前に決めておく初期設定について書いていきます。
内製化そのものの全体設計は社内AIツールの内製化。現場が自分で作れる組織にするまでにまとめてあります。

便利さの前に決めることと、最低限の初期設定4項目

この環境が他と違うのは、権限が広いという点です。
できることは、ファイルを読む・ファイルを書き換える・コマンドを実行する、の3つです。

なかでも最も影響が大きいのが「コマンドを実行する」で、システムに対する操作ができるからです。
便利さの理由もここにあって、テストの実行、環境の構築、自動化の実行がここに入ります。
だから最初の設定は、この「コマンドを実行する」の範囲を決めることになります。

決めずに使い始めると、誤ってファイルを削除する、想定外のコマンドが実行される、といった事故が起きます。
一度事故が起きると、全面的に禁止する方向に振れて、便利さのほうも失われます。
設定そのものは、4項目に絞れると思います。

ひとつは作業する場所を限定することで、どのフォルダの中で作業するかを決めて、その外には触れない設定にします。
2つ目は実行してよいコマンドを決めることで、許可するもの・確認を求めるもの・禁止するものに分けます。
あわせて、変更の記録が残る状態にすることで、何をいつ変えたかを追える形にします。
最後に、元に戻す手段を用意することで、バックアップあるいは変更の履歴です。

このなかで最も重要なのが、作業する場所の限定です。

ここさえ設定すれば、外は壊れないので大半のリスクが消えます。
コマンドの設定では、「禁止するもの」のほうを明示しておきます。
削除、権限の変更、外部への送信の3つが該当します。

変更の記録と元に戻す手段は、元に戻せる状態を作るためのものです。
元に戻せる状態があれば、緩めてよい範囲が広がるからです。

作業する場所を限定し、実行してよいコマンドを決める

最も重要な設定なので、ここは詳しく書きます。
やることは、作業するフォルダを決めて、その中だけで動く設定にすることです。

本番のデータやコードの場所ではなく、作業用のコピーのほうで作業します。
これが最も確実な対処で、何をしても本番が壊れない状態になります。
そのうえで、本番に反映する操作のときだけ人が確認する形にします。

作業用の場所の作り方は単純で、本番からコピーを作ってそこで作業し、確認してから反映します。
この形にすると確認を大幅に減らせるのは、作業用の場所では自由に動かしてよくなるからです。
順序が重要で、確認を減らす前に、まず作業用の場所を作ります。
検証にダミーのデータを使う話は本番データを使わずに検証する。ダミーデータを作る文化をつくるで扱っています。

コマンドのほうは、どう分ければいいのでしょうか？
「許可」「確認」「禁止」の3段階に分けます。
「許可」するのは、ファイルを読む・内容を確認する・テストを実行する・新しくファイルを作る操作で、確認なしで実行してよいものです。

「確認」を求めるのは、ファイルを書き換える・依存するものを追加する・設定を変更する操作で、1回の確認を挟みます。
「禁止」するのは、削除・権限の変更・外部への送信・システム全体に影響する操作です。
禁止するものを明示するのが最も重要で、とくに「外部への送信」、つまりデータが外に出る操作が最も見落とされます。

禁止の設定が実際に効いているかどうかも確認します。
一度試してみて、きちんと止まることまで見ておきます。
あわせて設定は標準化して配ります。
各自が自分で設定する形にすると、緩めすぎる人が必ず出るからです。

扱ってよいデータの線引きと、権限をどこまで緩めるか

扱うデータについても、3つの区分を決めておきます。
自由に扱ってよいものは、公開されているもの・サンプルのデータ・ダミーのデータです。
作業用の場所でのみ扱ってよいものは、社内のコード・社内の資料・設定の情報です。
扱ってはいけないものは、個人情報・認証情報・顧客から預かったデータ・未公表の重要な情報です。

この区分を明示するのが最も重要になります。
とくに認証情報が注意を要するところで、コードの中にそのまま書かれていることがあるからです。
だから使い始める前に、認証情報がコードに書かれていないかを確認します。

検証にはダミーのデータを使い、本番のデータは使いません。
この3区分は、1枚の紙にまとめて配ります。
扱う情報の階層の考え方は現場が作ったツールが業務データに触り始めたら。個人利用と法人利用の境界でも扱っています。

権限は、どこまで緩めればいいのでしょうか？
基準は1つで、「元に戻せるか」です。

緩めてよいのは、読むだけ・新しく作る・元に戻せる変更です。
絞るべきなのは、消す・外部に送る・権限や設定を変える操作です。
元に戻せる状態を作れば、緩めてよい範囲そのものが広がります。

逆に確認が多すぎると使われなくなりますし、確認自体が形式的になっていきます。
この「確認しているつもりで、確認していない」状態がいちばん危険です。
目安としては、1つの作業で確認が5回を超えたら設定を見直します。
ただし見直す方向は確認を減らすことではなく、確認が不要な範囲を広げること、つまり作業用の場所のほうを広げることです。

事故時の復旧手段と、社内展開の順序

備えがないと、そもそも緩めることができません。
復旧の手段を4つ用意しておきます。

何が起きたかを確認する手段（操作の記録）、元に戻す手段（バックアップや変更の履歴と、その手順の文書）、影響の範囲を確認する手段、報告の経路の4つです。
報告の経路については、「報告しても責めない」と明示しておきます。
隠されるくらいなら、早く上がってきたほうがいいからです。

元に戻す手順のほうは、実際に一度試しておきます。
「バックアップから戻せます」と言っていても、試していなければ必要なときに戻せません。
年に一度、30分あれば足りる作業です。
試した記録を残しておくと、手順が古くなっていないかの確認にもなります。

展開は一斉には配らず、3段階に分けて進めます。

「段階1」で情シスと一緒に設定を作ります。
4項目の設定と、3区分の線引きの2つです。

「段階2」で1〜2人だけで試します。
開発の作業が分かる人を選んで、設定がきちんと効いているかを確認する段階です。

「段階3」で開発や技術的な作業をする人に対象を広げて、ここで止めます。
この道具については、全社に配る必要はないと思います。
段階1が最も重要で、情シスの合意なしには進みません。

提案の順序としては、元に戻せる状態を先に作って、それから緩める範囲を提案する形にします。
管理外の操作、データの流出、システムの破壊という情シスの懸念は正当です。

作業する場所の限定が、最も説明しやすい対処になります。
権限の設計そのものは内製環境の権限設定をどう整えるか。安全と速度を両立させるにまとめてあります。

配る対象の基準は3つです。
開発や技術的な作業をする、自動化の仕組みを作る、設定の意味を理解していることです。
最後が重要なのは、設定の意味を理解していないと勝手に緩められるからです。

だから配る前に、設定の意味のほうを説明します。
何が許可されていて、何が禁止されているのか。
そのうえで変えてよい範囲を明示して、「作業する場所は自分で広げてよい」「禁止の設定は変えない」といった形にします。

設定が変えられたことに気づける仕組みがあれば、入れておきます。
利用状況を確認して、配ったが使われていない場合は外します。

よくある失敗

設定を決めないまま使い始めるのが、いちばん多い失敗です。
事故が起きて、そこから一気に全面禁止の方向へ振れることになります。

作業する場所を限定しないのも失敗で、これが最も重要な設定になります。
禁止するものを明示しないのも同じで、とくに「外部への送信」が最も見落とされます。

確認を減らす前に緩めるのも失敗です。
元に戻せる状態を先に作るという順序が重要です。
確認が多すぎる状態を放置すると、確認が形式的になり、使われなくなります。

復旧の手順を試さないのも失敗で、必要なときに戻せないので年に一度は試します。
各自に設定を任せるのも失敗で、緩めすぎる人が出るので標準の設定を配ります。

全員に配るのも失敗です。
設定の意味を理解していない人が使うと、勝手に緩められます。

開発の作業を任せる範囲は、品質と責任で線を引く

初期設定は4項目で、基準は「元に戻せるか」です。
ただし、その先にどこまでの作業を任せるかという判断が残ります。
定型的な処理、テストの実行、設定の変更といった簡単な作業なら問題ありません。
ところが業務に組み込む段階になると、設計そのものが変わってきます。

必要になるのは、作ったものの品質の確認・保守できる状態・止まったときの影響の想定・責任の所在、の4つです。
最も見落とされるのが、止まったときの影響の想定です。
業務に組み込んだものが止まると、そのまま業務が止まるからです。

さらに、事業として提供するものを作る場合は、設計が全く変わります。
社内で使うものと外に提供するものでは前提が違うので、この判断には専門性が必要になります。

私たちが提供しているAIプロダクト開発の伴走支援では、こうした開発の範囲の設計から、PoCやMVPとしての実装までを一緒に進めています。
使い始めたが、どこまで任せるかの判断で止まっている場合は、進め方の参考になるかもしれません。

作業する場所を区切れば、大半のリスクは消える

Claude Codeの初期設定は、4項目に絞れます。
作業する場所を限定する（最も重要で、これだけで大半のリスクが消えます）、実行してよいコマンドを3段階で決める、変更の記録が残る状態にする、元に戻す手段を用意する。

作業用のコピーで作業して、本番に反映する操作だけを人が確認します。
これが最も確実な対処で、確認そのものを大幅に減らせます。

コマンドは「許可」（読む・確認する・テスト・新規作成）、「確認」（書き換え・依存の追加・設定変更）、「禁止」（削除・権限の変更・外部への送信・システム全体への影響）の3段階です。
禁止を明示するのが最も重要で、外部への送信が最も見落とされます。
データは3区分で、個人情報・認証情報・顧客から預かったデータ・未公表の情報を「扱ってはいけないもの」として明示します。

使い始める前に、認証情報がコードの中に書かれていないかも確認しておきます。
権限の基準は「元に戻せるか」という1点だけです。
確認が形式的になるのが最も危険なので、1つの作業で5回を超えたら見直して、確認が不要な範囲のほうを広げます。

復旧手段は4つ用意して年に一度実際に試し、「報告しても責めない」と明示します。
展開は、情シスと設定を作る（最も重要）→1〜2人で試す→対象を広げる、の3段階です。
全員には配らず、設定の意味を理解している人に限定します。

情シスと一緒に、作業する場所を限定する設定は、もう形にできましたか。