Mercari が Claude Code を社内で安全に展開した方法

@hermes_code
日本語2 日前 · 2026年7月14日
836K
941
91
3
2.8K

TL;DR

この記事では、Mercari が Claude Code を展開するために構築したセキュリティフレームワークを詳しく解説します。危険なコマンドのブロックや機密ファイルの保護を実現する具体的な JSON 設定についても紹介します。

「便利なのはわかるんです。でも、社員のPCでAIが勝手にコマンドを実行するって、正直こわくないですか?」

AI活用サポートの現場で、経営者からいちばん多く出るのがこの声です。ChatGPTのようにブラウザの中で完結するAIなら、まだ怖くない。でもClaude Codeは、社員のパソコンの中でファイルを読み、コマンドを実行し、ネットにも取りに行きます。「使えば速くなるのはわかった。でも、事故ったら誰が責任を取るのか」。ここで止まっている会社は、たぶん少なくありません。

その不安に、大企業がひとつの答えを出しました。メルカリが、社内数百人規模でClaude Codeを配るときに使った「安全のための設定と配り方」を、勉強会で公開したんです。

しかも中身は、専用の高価な仕組みがないと組めない話ではありませんでした。設定ファイルを1枚用意して配るだけで、中小企業でもかなりの部分を真似できます。

メルカリが数百人に配れた理由は、高価な仕組みではなく「社員が外せない設定ファイル1枚」でした。中小企業でも、今日から同じことができます。

この記事では、そのメルカリの設計をできるだけかみ砕いて、「何を怖がるべきか」「メルカリはどう手綱をつけたか」「あなたの会社なら何から始められるか」の順で書きます。専門用語は初めて出てくるときに補足を入れるので、非エンジニアの経営者やPM(プロジェクトの進行役)の方も、そのまま読み進めてもらえたらと思います。

参照した発表資料はこちらです

(メルカリ・Claude Code組織配布のセキュリティ設定/Speaker Deck)。

設定の正確な書き方は、Anthropicの公式ドキュメントで裏を取りながら書いています。

なぜClaude Codeは「便利なのに怖い」のか

まず、怖さの正体をはっきりさせておきます。僕自身、ここがあいまいなまま設定だけ真似すると、何を守っているのか分からなくなると感じています。

Claude Codeが普通のチャットAIと違うのは、手元のパソコンの中で自分で動けることです。ファイルを検索して読む、書き換える、そしてシェルコマンド(黒い画面に打つ命令)を実行する。ネットにもアクセスできます。これは言い換えると、そのパソコンでできることは、AIにもだいたいできてしまうということです。

具体的に何がまずいか。パソコンの中には、たいてい「見られたら困るもの」が置いてあります。

  • クラウドやAPI(外部サービスと自動でやり取りする窓口)のパスワードにあたる情報(.envという設定ファイルや、~/.aws/credentialsなど)
  • サーバーにログインするための鍵(~/.ssh/の中身)
  • 消えたら困る大事なファイル

AIに悪気はありません。でも、あいまいな指示や、ネット上のあやしい文章に混ぜ込まれた命令(プロンプトインジェクションと呼ばれます)につられて、こうした秘密ファイルを読んでネットに送ってしまう、rm(ファイル削除コマンド)で大事なものを消してしまう、といった事故は起こりえます。Anthropicの公式ドキュメントも、こうしたリスクを前提に権限をしぼる設計を勧めています(権限設定・公式)。

つまり守りたいのは、ざっくり3つ。秘密情報を外に出さない、危ない操作を勝手にさせない、そもそも触れる範囲を狭める。メルカリの対策も、この3つに沿って読むと一気に分かりやすくなります。

メルカリがやった「5つの対策」を、かみ砕く

メルカリの発表は、大きく5つの対策としてまとめられていました。順番に、「何のためか」「どう実現するか」をセットで見ていきます。

なお前提として、発表スライドは考え方の説明が中心で、設定ファイルの細かい書き方まで全部が載っているわけではありません。なのでここでは、メルカリが示した方針を、Claude Codeの公式設定で実装するとこうなる、という形で書きます。キー(設定項目)の名前と書き方は、すべてAnthropic公式で確認したものです。

対策① 人間の確認を「飛ばせなく」する

Claude Codeには、いちいち確認を取らずに全部自動で進めるモードがあります。開発者が自分の実験用パソコンで使うぶんには便利ですが、会社で全員に配るときにこれを許すと、事故のブレーキが外れた状態になります。

そこでメルカリは、この「確認を飛ばすモード」を使えないようにしました。公式には、確認スキップを封じる設定としてpermissions.disableBypassPermissionsMode(と自動モードを塞ぐdisableAutoMode)が用意されていて、値を"disable"にすると、そのモードに入れなくなります。しかもこれを後述の「管理者設定」に置くと、社員が自分で解除できません(権限設定・公式)。

意味合いはシンプルで、「AIが手を動かす前に、必ず人間が一回OKを出す」を全社で強制する、ということです。

対策② 危ないコマンドは止める、あるいは必ず確認する

次に、コマンドそのものに手綱をつけます。たとえばcurl(ネットからデータを取ってくるコマンド)。これが自由に使えると、秘密ファイルを外部に送り出す通り道になりえます。

Claude Codeでは、特定のコマンドを禁止するdeny(拒否リスト)と、実行前に必ず確認させるask(確認リスト)を設定できます。書き方はこんな形です。

{

"permissions": {

"deny": [

"Bash(curl:*)",

"Bash(wget:*)"

],

"ask": [

"Bash(git push:*)"

]

}

}

Bash(curl:\)は「curlで始まるコマンドを全部ブロック」という意味です(末尾の:\は「その後ろは何でも」を表します)。ここで大事な注意がひとつ。公式は「curlをGitHub宛てだけ許可、のように引数で細かくしぼる書き方は破られやすい」と明言しています。リダイレクトなどで簡単にすり抜けられるからです。なので、ネット通信系は丸ごと止めて、必要な取得は別の安全な口に一本化するのが公式の勧めです(権限設定・公式)。この「別の安全な口」がWebFetch(Claude Codeに元から入っている、ネット取得専用の機能)で、行き先を許可制にできます。

対策③ 秘密ファイルを読ませない、システムをいじらせない

秘密情報そのものへのアクセスも塞ぎます。パスワード類が入りがちな.envファイルや、管理者権限で実行するsudo(システムを深く書き換えるコマンド)などです。

{

"permissions": {

"deny": [

"Read(.env)",

"Read(.env.*)",

"Read(\\/.ssh/\\)",

"Bash(sudo:*)"

]

}

}

Read(.env)と書くと、作業フォルダの下にある.envが、どの階層でも読めなくなります(Read(\\/.env)と同じ意味です)。ひとつ知っておくと安全なのは、この拒否リストはClaude自身のファイル読み取りや、cat(ファイル表示)のような分かりやすいコマンドには効きますが、AIが書いたスクリプトが裏でこっそりファイルを開く、みたいな回り道までは止めきれないという点です(権限設定・公式)。だから次の対策④が要ります。

対策④ サンドボックスで「触れる範囲」ごと囲う

拒否リストが「このコマンドはダメ」の1件1件の線引きなら、サンドボックス(砂場のように隔離された作業スペース)は、OSのレベルで壁を作るやり方です。作業フォルダの外は触らせない、許可したネット先以外にはつながせない、と物理的にしぼります。

{

"sandbox": {

"enabled": true,

"network": {

"allowedDomains": \"*.github.com", "[registry.npmjs.org"]

}

}

}

これを有効にすると、たとえAIがうっかり秘密ファイルに手を伸ばそうとしても、砂場の外なので届きません。公式は、拒否リスト(対策②③)とサンドボックスの両方を重ねて最終的な境界にする、と説明しています(サンドボックス・公式)。1件1件のルールと、囲いごと、の二重で守るイメージです。

ひとつだけ制約があります。サンドボックスが効くのはmacOSとLinux、それとWSL2(Windows上でLinuxを動かす仕組み)で、ネイティブのWindowsには対応していません。Windows主体の職場では、対策①〜③の権限設定を厚めにする、という判断になります。

対策⑤ 「守ってほしいこと」を毎回AIに読ませる

最後は、設定でガチガチに縛るのとは別の角度です。会社としてのセキュリティ方針を、AIが毎回目を通す指示書に書いておく。設定でブロックするのが「物理的な鍵」なら、こちらは「就業ルールの読み合わせ」に近いです。

技術的な仕込み方はいくつかあり、メルカリが具体的にどれを使ったかは資料からは断定できません。ただ、いちばん手軽なのは、作業フォルダの直下にCLAUDE.mdという名前のファイルを置き、そこに社内ルールを箇条書きしておく方法です。Claude Codeはこのファイルを毎回読み込みます。

セキュリティのお願い

  • .env や鍵ファイル(~/.ssh/ など)は開かない
  • 顧客情報・社外秘を外部サービスに送らない
  • 削除や公開の操作は、実行前に必ず人へ確認する

設定でブロックする対策①〜④が「物理的な鍵」なら、これは「毎朝の読み合わせ」です。鍵とルールの両輪で、初めて安心して任せられます。

今日できる1アクション: 上の3行をCLAUDE.mdに貼るだけでも、AIの動きに社内の常識が一枚かかります。設定ファイルより先に、これから始めても大丈夫です。

今日できる1アクション: いきなり全部は入れなくて大丈夫です。まずは.claude/settings.jsonという設定ファイルに、対策③の"Read(.env)"の1行だけ足してみてください。置き場所は、Claude Codeで作業するフォルダの直下に.claudeという名前のフォルダを作り(先頭のドットも含めて入力します。すでにあればそれを使います)、その中にsettings.jsonという名前でテキストファイルを保存すればOKです。全プロジェクトにまとめて効かせたいなら、ホームフォルダ直下の~/.claude/settings.jsonに置きます。秘密ファイルをAIに読ませない、という一番効く一手から始められます。

メルカリの本当のうまさは「配り方」にあった

ここまでが「何を設定するか」でした。メルカリの発表がとくに実践的だったのは、この設定を数百人にどう配るかまで踏み込んでいた点です。

普通、設定ファイルは各自のパソコンに置くもの(ユーザー設定)なので、社員が自分で書き換えられます。それだと「安全設定を配ったのに、誰かが外していた」が起きます。

そこでメルカリは、MDM(端末管理。会社が社員のパソコンをまとめて管理する仕組み)を使って、社員が上書きできない「管理者設定」を一斉に配布しました。Claude Codeには、個人の設定より優先され、本人には変更できない管理者設定の置き場所が用意されています。macOSなら/Library/Application Support/ClaudeCode/managed-settings.jsonという決まった場所です(設定ファイル・公式)。ここに対策①〜④を書いて配れば、現場で勝手に緩められません。

さらに賢いのが、エンジニアと非エンジニアで安全レベルを分けたことです。

  • エンジニア向け: ある程度カスタマイズできる、生産性を落としすぎない設定
  • 非エンジニア向け: いじる余地を減らした、いちばん安全な初期設定

同じツールでも、使う人のリテラシーに合わせて手綱の長さを変える。全員を最厳格でしばると現場が回らないし、全員を緩くすると事故る。その真ん中を、配る設定の出し分けで解いたわけです。

中小企業なら、ここから真似できる

「MDMなんて入れてないよ」という会社がほとんどだと思います。大丈夫です。メルカリの設計から、規模に関係なく効く部分だけ抜き出せます。

やることは、安全設定を書いた1枚のファイルを、配って置いてもらう。これだけです。MDMがあるなら管理者設定として強制配布、なければ「このsettings.jsonを.claude/フォルダに入れてね」と配って共有する。強制力は落ちますが、方向は同じです。

最小セットとして、対策①〜③をまとめるとこうなります。これを土台に、自社で足したい禁止コマンドを追記していくのがおすすめです。

{

"permissions": {

"disableBypassPermissionsMode": "disable",

"deny": [

"Bash(curl:*)",

"Bash(wget:*)",

"Bash(sudo:*)",

"Read(.env)",

"Read(.env.*)",

"Read(\\/.ssh/\\)"

],

"ask": [

"Bash(git push:*)",

"Bash(rm:*)"

]

}

}

上から順に、確認スキップを禁止、ネット通信と管理者操作をブロック、秘密ファイルを読み取り禁止、削除や公開操作は必ず確認、という並びです。中身が分からなくても、まるごとコピーして貼れば動きます。

非エンジニアの社員に配るなら、これに「作業フォルダの外は触らせない」サンドボックス(対策④)まで足した、いちばん安全な形をおすすめします。2つの設定を1つのファイルに並べると、こうなります。これをまるごと貼れば完成です。

{

"permissions": {

"disableBypassPermissionsMode": "disable",

"deny": [

"Bash(curl:*)",

"Bash(wget:*)",

"Bash(sudo:*)",

"Read(.env)",

"Read(.env.*)",

"Read(\\/.ssh/\\)"

],

"ask": [

"Bash(git push:*)",

"Bash(rm:*)"

]

},

"sandbox": {

"enabled": true,

"network": {

"allowedDomains": \"*.github.com", "[registry.npmjs.org"]

}

}

}

permissions(権限のルール)とsandbox(隔離の設定)を、カンマで区切って横並びに置いているだけです。許可するネット先(allowedDomains)は、自社で使うサービスに合わせて書き換えてください。サンドボックスはmacOSとLinux、WSL2で効きます。

僕がサポートの現場でいつも伝えているのは、完璧を目指して止まらないことです。メルカリのような多層防御をいきなり全部は組めなくても、.envを1行で守るだけで、事故の確率ははっきり下がります。

今日できる1アクション: 社内でClaude Codeを使い始める人が1人でもいるなら、上の最小セットをテキストで共有して、.claude/settings.jsonに貼ってもらってください。配布のリハーサルとしても、ちょうどいい大きさです。

落とし穴: 設定を配る前に知っておきたい3点

守りを固める話だからこそ、勘違いすると逆に危ない点があります。

  1. 「拒否リストを書いたから安全」ではない。対策③で触れたとおり、拒否リストはAIが書いたスクリプトの裏側の動きまでは止めきれません。curlを止めても、ほかの通信手段が残ることもあります。本気で囲うならサンドボックス(対策④)まで重ねる、という前提を忘れないほうがいいです。
  2. 引数でしぼる書き方に頼らない。curlをこのURLだけ許可、のような細かい条件つき許可は、公式自身が「破られやすい」と注意しています。危ないものは条件つきで許すより、丸ごと止めて安全な代替口を1つ用意するほうが堅いです。
  3. 設定を配って終わりにしない。管理者設定で強制できても、そもそも社員が別のあやしいツールを勝手に入れれば意味がありません。設定は「事故を減らす仕組み」であって、使い方の教育とセットで効きます。対策⑤の「ルールを読ませる」が最後に効いてくるのはここです。

中級者向けFAQ

Q. 個人利用でも、ここまで設定する意味はありますか?

あります。会社かどうかより、そのパソコンに秘密情報が置いてあるかどうかが基準です。フリーランスや個人開発でも、.envや~/.ssh/は必ず手元にあります。最低でも対策③の読み取り禁止は入れておくと安心です。

Q. 権限をしぼると、AIが仕事にならなくなりませんか?

しぼり方の問題です。読み取り専用のコマンド(lsやcatなど)は元から確認なしで動くので、日常の作業はほとんど止まりません。止まるのは、削除・公開・ネット通信のような「事故ると痛い」操作だけです。むしろ「危ないときだけ人が見る」に寄せると、安心して自動で回せる範囲が広がります。

Q. settings.jsonと管理者設定(managed-settings.json)は何が違いますか?

置き場所と強さが違います。プロジェクトの.claude/settings.jsonは誰でも編集できる共有設定、managed-settings.jsonは会社が配る、本人には変えられない設定です。個人や少人数なら前者で十分、「勝手に緩められると困る」段階になったら後者、という順で考えると分かりやすいです。

Q. Cursorや他のAIコーディングツールでも同じ考え方でいいですか?

守りたいもの(秘密情報・危険操作・触れる範囲)は共通なので、発想はそのまま使えます。ただし設定の書き方やサンドボックスの有無はツールごとに違うので、今回のsettings.jsonの記法はClaude Code専用と考えてください。他ツールを使うなら、それぞれの公式ドキュメントで同じ3観点を当てにいくのが近道です。

まとめ: 「使わせない」から「安全に配る」へ

僕がAI導入の相談を受けるとき、以前いちばん多かったのは「危ないから、まだ使わせられない」という声でした。でも、使わせない判断は、便利さもまるごと手放しています。

メルカリが見せてくれたのは、その二択から抜ける道でした。確認を飛ばせなくする、危ない操作を止める、秘密ファイルに触れさせない、砂場で囲う、ルールを読ませる。そのうえで、いじれない設定として全員に配る。「怖いから禁止」ではなく、「怖いところに手綱をつけて配る」に変える設計です。

  • 守る対象: 秘密情報を外に出さない / 危ない操作をさせない / 触れる範囲を狭める、の3つに整理する
  • メルカリの5対策: 確認スキップ禁止・危険コマンド制限・秘密ファイル禁止・サンドボックス・ルール読ませ
  • 配り方: 本人が上書きできない管理者設定で、リテラシーに応じて出し分ける

最後に、今日からの3ステップです。

  1. 自分のパソコンでRead(.env)を1行入れる: 秘密ファイルの読み取り禁止から。効果がいちばん大きい一手
  2. 最小セットを1枚のファイルにする: 上のpermissionsの例をベースに、自社で止めたいコマンドを足す
  3. 社内の1人に配って試す: .claude/settings.jsonに貼ってもらい、仕事が止まらないか一緒に確認する

最初の一歩は、.envを守る1行で十分です。完璧な多層防御は、そこから1枚ずつ重ねていけばいいと思います。「怖いから止める」を、「手綱をつけて任せる」に変える。その最初のファイルを、今日置いてみませんか?

参考リンク

YouMindで再制作

Turn one viral article into a full content workflow

Collect the source, decode the pattern, create assets, draft the story, and distribute from one AI workspace.

Explore YouMind
クリエイターのために

あなたの Markdown をきれいな 𝕏 記事に

自分の長文を投稿するとき、画像・表・コードブロックを 𝕏 向けに整形するのは手間がかかります。YouMind は Markdown 全体を、そのまま投稿できるきれいな 𝕏 記事に変換します。

Markdown → 𝕏 を試す

解読すべきパターンをもっと

最近のバイラル記事

バイラル記事をもっと見る