Claude Codeを安全に使うならsettings.jsonを先に決める｜非エンジニアPdMの事故防止メモ

ClaudeCode #settingsjson #セキュリティ対策 #AI活用 #業務自動化 #権限管理 #安全運用 #MCP #非エンジニア #Note

はじめに

Claude Codeを使い始めると、最初に気になるのは「何ができるか」よりも「どこまで任せてよいか」です。

特に、非エンジニアの立場で業務に入れるときは、便利さより先に安全性が見えてきます。読むだけなら気楽でも、ファイルを更新する、外部サービスにつなぐ、コマンドを実行する、となった瞬間に一気に慎重になります。

この動画を見て一番強く感じたのは、Claude Codeの安全運用は、気合いではなく設定で作るものだという点でした。settings.json は飾りではなく、AIに渡す権限の境界線です。

結論

結論から言うと、Claude Codeを安全に使うなら、先に settings.json で「読める範囲」「書ける範囲」「外部につながる範囲」を決めておくのが先です。

AIを信用するかどうかを先に考えると、議論が感情論になります。そうではなく、最初にルールを置く。すると、実行のたびに迷いにくくなります。

非エンジニアの実務では、次の順番が現実的です。

1. まず読むだけの範囲を広げる

2. 次に書き込みの確認方法を決める

3. 最後にMCPや外部サービスの接続を必要最小限にする

この順番にしておくと、AIの便利さを試しながら、事故の入口だけを先に閉じられます。

目次

1. なぜ設定が先なのか

2. 従来の課題と目指す姿

3. settings.json で決める3つの境界

4. つまずきやすい落とし穴

5. 明日試すアクション

従来の課題と目指す姿

この表の左側は、AIを「使えるかどうか」で見ている状態です。右側は、AIを「安全に使い続ける仕組み」に変えた状態です。

settings.jsonで最初に決める3つの境界

settings.json で最初に見るべきなのは、細かいオプションの数ではありません。境界です。

1. 読み取り境界

まず決めたいのは、どこまで読ませるかです。

非エンジニアの業務では、最初から全部をつなぐ必要はありません。まずは、読み取りだけで成立する対象を広げるほうが安全です。

• 議事録

• 仕様メモ

• 既存の手順書

• 参照だけで済むナレッジ

ここで大事なのは、「読める」ことと「勝手に動かせる」ことを分けることです。読める範囲が広いほど便利ですが、同時に見えてはいけない情報まで触れないように線を引く必要があります。

2. 書き込み境界

次に決めるのは、どこまで書かせるかです。

AIがいちばん事故を起こしやすいのは、出力そのものより、上書きや削除の場面です。だから、最初は書き込みを「必ず確認」に寄せるのが無難です。

ここでは、考え方の例としてこんな整理ができます。

{
  "permissions": {
    "read": "allow",
    "write": "confirm",
    "delete": "deny",
    "network": "confirm"
  }
}

これは実際のClaude Codeの固定スキーマをそのまま示すものではなく、運用の考え方を表した例です。要点は、全部を許可しないことです。

非エンジニアの現場では、「書けるようになったら便利」よりも、「勝手に書かれない」ことのほうが重要です。便利さは後で足せますが、事故は後で消せません。

3. 接続境界

最後に、MCPや外部サービス接続の境界を決めます。

外部連携は、設定できること自体が価値ではありません。業務で必要な相手だけをつなぐことが価値です。

• 参照だけで足りるサービスは読み取り専用にする

• 変更が必要なサービスは個別に承認する

• 本番系や重要データには最初から広くつながない

この境界を曖昧にすると、AIは「賢い」より先に「広く届く」存在になります。業務の安全性を考えるなら、届く範囲を狭く、確認を厚くするのが正解です。

非エンジニアの実務での使い方

この考え方は、机上のルールではありません。日々の作業にそのまま落ちます。

たとえば、非エンジニアPdMの現場では次のような使い方が多いはずです。

• 会議メモを要約して、決定事項だけ抜き出す

• 仕様の差分を見て、どこが変わったかを読む

• 既存の運用ルールを要約して、抜けを探す

• 問い合わせメモを整理して、エンジニアに渡せる形にする

このとき、Claude Codeに最初から書き込みを許す必要はありません。まずは読むだけで成果が出る作業を任せる。次に、下書きの生成だけをさせる。最後に、限定された書き込みを許す。これで十分です。

実際の指示も、最初は短くてかまいません。

このフォルダの仕様メモを読んで、変更点だけ3行でまとめてください。
ファイルは変更しないでください。
確認が必要な箇所があれば、そのまま列挙してください。

この議事録を、決定事項・保留事項・次アクションの3つに分けてください。
外部サービスには接続しないでください。
書き込みはせず、下書きだけ見せてください。

こうした短い指示でも、設定側で読取境界が明確なら安心して回せます。逆に、設定が曖昧だと、同じ指示でも「どこまで触るか」が毎回変わります。

引き継ぎでの見せ方

導入時に相手へ見せるなら、設定の詳細より、次の一言のほうが伝わります。

この言い方だと、技術に詳しくない人にも伝わります。しかも、後から運用を見直すときに「広い」「狭い」「最小限」という基準が残ります。

設定レビューの観点

設定を見直すときは、次の順番で確認するとブレにくいです。

1. いま読める情報は業務上ほんとうに必要か

2. 書き込みの前に人が確認する運用になっているか

3. つないだ外部サービスに不要な権限がないか

4. 本番や重要データに近いところまで届きすぎていないか

5. 誰がルールを更新するか決まっているか

この5つが通れば、細かい実装差分があっても大筋は守れます。逆に、ここが抜けると、設定があっても事故は起きやすいです。

つまずきやすい落とし穴

安全運用でよくある失敗は、派手な機能を増やすことではなく、境界が崩れることです。

落とし穴1: 便利そうな接続を全部つなぐ

最初は便利に見えますが、後で何がどこにつながっているのか追えなくなります。

AI活用は、接続数を増やすゲームではありません。業務上の意味がある接続だけを残すほうが、結果的に使いやすいです。

落とし穴2: 書き込み確認を省略する

小さな修正だと思っていたものが、ファイル全体の上書きに変わることがあります。

特に、説明文の改善や設定の追記のような軽い作業ほど、実際には影響範囲が広いことがあります。ここは慎重に見たほうがよいです。

落とし穴3: ルールが人によって違う

誰かは読取専用、誰かは全許可、という状態だと、同じツールなのに別物になります。

これは運用の問題です。導入時に「どこまで許可するか」を文章にしておくと、後で迷いにくくなります。

落とし穴4: 事故のあとに考える

一番もったいないのは、問題が起きてから境界を考えることです。

安全の設計は、何も起きていないうちにしか効きません。だからこそ、設定を先に見る価値があります。

明日試すアクション

明日やることは、難しい設定の見直しではありません。小さく始めます。

1. Claude Codeで読むだけの対象を1つ決める

2. settings.json の考え方を「読取」「書込」「接続」に分けてメモする

3. 変更を伴う操作は、必ず確認するルールを1行で書く

4. 社内共有するなら、MCPや外部接続は必要最小限にする

5. 1on1があるなら、「何を止めるか」を先に聞く

この5つは、導入を止めるためのチェックリストではありません。むしろ、安心して使い続けるためのスタート地点です。

確認したいこと
・読むだけで十分な範囲はどこか
・書き込み前に人が見るべきものは何か
・外部接続はどれだけ必要か
・止めるべき操作はどれか
・このルールを誰が更新するか

このメモを最初に作っておくと、後からAIの使い道を広げるときにも判断しやすくなります。

そのまま使える確認メモ

社内で使うなら、こんなチェックメモを1つ置いておくと便利です。

Claude Code導入前チェック
・読むだけで十分な範囲を決めたか
・書き込みは確認制になっているか
・外部接続は必要最小限か
・本番データへの接続は避けているか
・停止条件を人が説明できるか

このメモは、設定の正しさを証明するものではありません。ただ、運用のズレを早めに見つけるには十分です。現場では、このくらいの軽さのほうが回ります。

まとめ

Claude Codeの安全運用は、AIを疑うところから始めるより、先にルールを決めるほうがうまくいきます。

settings.json は、AIの能力を抑え込むためのものではありません。業務で使うときの事故を減らし、確認すべきところを人に戻すためのものです。

非エンジニアの現場では、全部を自動化するより、「どこまで任せて、どこで止めるか」を先に決めたほうが実務に乗ります。設定を先に作ることは、遠回りに見えて、いちばん早い安全策です。