もともと私の手元には、自分のサーバー上のデータベースにPythonで接続するモジュールがありました、ただこれが古いライブラリ前提で作られていて、最新の環境に上げようとすると動かない、という状態でずっと固まっていたんです

どうせ作り直すなら、ただの接続モジュールに戻すのはもったいない、せっかくなら Claudeから直接データベースを覗ける道具にしてしまえば便利なのでは? と思いついたのがきっかけでした

その「道具」がMCPサーバーと呼ばれるものになります、この記事では Claude Codeに伴走してもらいながら、自分専用のMCPサーバーを設計から公開まで作った体験を、コードの深い話は抜きにして広めに書いていきます

先に結論を言うと、プログラムをゴリゴリ書ける人でなくても、自分専用の道具は作れます、Claudeに設計から相談して、実装もレビューも任せて、最後に自分が確認するだけで形になりました

ジャベ雄

「自作」って聞くと身構えちゃうけど、やってることの大半は日本語の相談なんですよね

Claude Codeの拡張機構の全体像はClaude Codeの拡張機構入門の記事、AI周辺の用語はAI用語集でまとめているので、言葉でつまずいたらそちらも合わせてどうぞ

そもそもMCPって何 Claudeに道具を持たせる仕組み

まず言葉の整理から、MCP(エムシーピー)はClaudeに「外部の道具」を持たせるための拡張の仕組みの1つです

Claudeはそのままだと、賢く文章を考えたり相談に乗ったりはできても、「私のサーバーにあるデータベースを読んできて」みたいな手元の操作はできません、本体に手足が付いていないイメージです

そこで 道具(=MCPサーバー)を外付けしてあげると、Claudeが単体ではできない操作を、その道具を介してできるようになります、今回私が作ったのは「自分のサーバーのデータベースを読む道具」です

これをClaudeに登録しておくと、あとは日本語で 「このテーブルから昨日のデータを出して」と頼むだけで、Claudeが裏でデータベースへの問い合わせ(SQLという命令文)を組み立てて、結果を返してくれます

ジャベ雄

SQLを自分で書かなくていいの、ここが地味にうれしいんですよ

なぜ既製品でなく自作だったのか

ここで疑問が出ると思います、データベース用のMCPなんて世の中にすでにあるのに、なぜわざわざ自分で作ったのか? という話です

結論から言うと、既製品が私のサーバー環境にそのままでは繋がらなかったからです、この接続の壁が今回いちばんの分かれ道でした

実は最初、私は「わざわざ作らなくても、既にあるものを入れれば一発でしょ」と軽く考えていました、ところがいざ繋ごうとすると、データベースの接続情報を正しく入れているのに、どうやっても弾かれてしまう、ここで「あれ、これ普通のやり方では届かないやつだ」と気づいたわけです

Xserverは「二段構え」でつなぐ必要がある

私が使っているレンタルサーバー(Xserver)は、データベースに直接つなぐのではなく、いったん別のサーバーに安全な経路でログインしてから、その先のデータベースへ繋ぐという二段構えが前提になっています

この「安全な経路を一本通してから、その中を通ってつなぐ」やり方を SSHトンネルと呼びます、外から直接データベースを叩けないようにする、セキュリティ上ありがたい仕組みなんですが、繋ぐ側からするとひと手間多いわけです

一般的なデータベース用のMCPは、この SSHトンネルの機能を持っていません、だからXserverのような二段構えのサーバーには、既製品をそのまま当ててもつながらないんです

既製品は「参考にはするけど、そのままでは私の用途を満たさない」、これが自作に踏み切った理由になります、自分の環境にぴったり合う道具がないなら、作ってしまえばいいという発想です

Claude Codeに全工程を伴走させた流れ

ここからが記事の本題です、私は今回 「バイブコーディング」的に、ほぼ全工程をClaude Codeに伴走させて作りました、ノリと相談で進めていく感じの作り方ですね

AIでアプリを作る体験そのものについてはAIでアプリ開発に挑戦した体験記でも書いているので、雰囲気が気になる方はそちらも、ここでは「道具(MCP)を作るときの流れ」に絞ります

大きく分けると、壁打ち → 設計 → タスクごとに実装 → 最終レビュー → 公開という5ステップで進みました

「先にテストを書く」ってどういうこと

STEP3で「先にテストを書いてから本体を作る」と書きました、これは TDD(テスト駆動開発)という作り方で、ざっくり言うと「合格ラインを先に決めてから中身を作る」やり方です

料理で言えば、完成形の味見の基準を先に決めておいて、その基準を満たすように作る感じですね、こうすると 作ったものが意図どおり動いているかを毎回その場で確認できるので、後からのやり直しが減ります

大事なのは、この段取り自体もClaudeが提案して進めてくれた点です、私が「TDDでやって」と細かく仕切ったわけではなく、相談する中で自然とこの形に落ち着きました

ジャベ雄

「実装する人」と「チェックする人」を分ける、これ人間のチーム開発と同じ発想なんですよね

Claude・生成AIを学べる本PR

面倒なことはChatGPTにやらせよう

カレーちゃん・からあげ

Amazonで見る楽天で見る

実践Claude Code入門

西見公宏・吉田真吾・大嶋勇樹

Amazonで見る楽天で見る

Claude CodeによるAI駆動開発入門

平川知秀

Amazonで見る楽天で見る

私のおすすめからランダムで3冊を表示しています

最終レビューで「自分のバグ」が見つかった話

この章の話が今回いちばん学びになりました、各タスクのレビューはちゃんと通していたのに、最後の全体レビューで実際のバグが1つ見つかりました

中身を平たく言うと、読み取り専用のはずなのに、ある特殊な書き方をすると書き込み命令が通ってしまう抜け穴でした、「読むだけ」を守らせていたつもりが、すり抜ける経路が残っていたんです

怖いのは、これが 各機能ごとの個別レビューを全部すり抜けていた点です、1つひとつの機能を見ているときには気づけず、全体を改めて厳しい目で見直したときに初めて浮かび上がってきました

見つかったあとの流れはシンプルで、指摘 → 修正 → 再レビューでその抜け穴を塞ぎました、ここでもやっているのは「Claudeに直してもらって、もう一度別の目で確認する」という同じ進め方です

AIは賢いんですが、万能で無謬というわけではありません、だからこそ 作る工程とチェックする工程を分けて、最後に全体を見直す、この一手間が安心につながると実感しました

AIにデータベースを触らせるときの安全設計

今のバグの話とつながりますが、AIにデータベースを触らせるなら、安全側に倒した設計が要ります、ここは自作する人だけでなく、既製のMCPを使う人にも役立つ考え方なので少し丁寧に書きます

基本は「読み取り専用」にしておく

私が決めたのは 既定で「読むだけ」にするという方針でした、AIにデータベースを任せるとき、いちばん怖いのはうっかりデータを書き換えられたり消されたりすることです

だから道具の側で「ふだんは読むだけ、書き込みは明示的にスイッチを入れたときだけ許可する」という作りにしました、自分でも「今は書き込みOKにしているぞ」と意識しないと書けない、という ブレーキです

本当の安全弁はデータベース側にある

ただ、ここで大事な考え方があります、道具(アプリ)側のチェックは第一の防御線にすぎません

さっきのバグのように、アプリ側の「読むだけ」設定はすり抜ける経路が残っていることがあります、だから 本当の安全弁は、データベース側に「読み取りしかできない利用者」を用意することです

つまり、そもそも書き込み権限を持たないアカウントで繋いでおけば、仮にアプリ側のチェックを抜けても、データベースが「あなたには書き込み権限がありません」と弾いてくれます、二重のブレーキです

考え方としてはこうです、データベースには、つなぐための利用者(アカウント)を何種類か作れます、ふだんアプリやサーバーの管理に使うのは強い権限を持った利用者ですが、AIに渡すのは「読むことしかできない利用者」を別に1つ用意して、そちらだけを使わせるのが安心です

こうしておくと、構造はとてもシンプルになります、アプリ側の「読むだけ」設定が 第一の防御線、その奥でデータベース側の読み取り専用の利用者が 最後の安全弁として控える、という形です、手前のチェックがうっかり抜けても、いちばん奥で物理的に書き込めない、この奥行きが効いてきます

手順の細かい話は環境ごとに変わるので踏み込みませんが、方針として覚えておきたいのは 「アプリで頑張る」より「権限を持たせない」ほうが強いという一点です、できないように作ってあれば、そもそも事故が起きようがありません、ここは私自身が今回のバグで痛感したところでもあります

使った道具は「最新の保守されたもの」だけ

技術の中身には深入りしませんが、1点だけ、今回 古い(メンテが止まった)接続方式をやめて、今も保守されている方式に乗り換えられたのは大きな前進でした

使ったのは3つで、安全な経路(SSH)を扱う asyncssh、データベースとやり取りする aiomysql、Claudeと話す土台になる FastMCP、それぞれ「SSHを扱う道具」「データベースを扱う道具」「MCPを作る土台」くらいの理解で十分です

名前を覚える必要はありません、ポイントは 今も更新が続いているライブラリだけで動くようにできたこと、古いものに縛られて身動きが取れなかった状態から解放されたのが、地味にいちばん嬉しかったところです

実際に使ってみたらこうなった

道具が完成して、Claudeに登録したあと、さっそく試してみました、頼み方はいたってシンプルで、日本語で「このテーブルから昨日ぶんのデータを抽出して」とお願いするだけです

するとClaudeが裏で問い合わせ(SQL)を自分で組み立てて、結果を返してくれました、私はSQLを1行も書いていません、それでも自分がためているデータがちゃんと取れて、試したときは千件を超える実データが返ってきました

ジャベ雄

自分のデータに話しかけて答えが返ってくる感じ、ちょっと未来っぽくて楽しいんですよ

これで 自分専用の「自分のサーバーのデータベースをClaudeから覗く道具」が手に入りました、欲しかったのはまさにこれです、既製品では届かなかった一歩を、自作で埋められたという達成感もありました

使ってみて地味に効いたのが、データの中身を確認するためにいちいち管理画面を開かなくてよくなったことです、これまでだと「あのデータどうなってたっけ」と思うたびにブラウザでログインして画面をたどっていました、それが今は、Claudeに一言聞けば返ってくる、この距離の近さが思った以上に快適でした

しかも返ってきた結果について「この中で件数が多い順に並べて」とか「先週ぶんと比べてどう?」みたいに、そのまま会話で深掘りできます、データを取り出す道具と、それを読み解く相手が同じ場所にいる、この一体感がふつうのデータベース管理ツールとはひと味違う使い心地でした

もう少し具体の流れを書いておくと、たとえば あるテーブルに対して「ここから昨日ぶんを出して」と日本語で頼むと、Claudeがその指示を読み取って、裏で問い合わせ(SQL)を自分で組み立てます、私が見ているのは「昨日ぶんを出して」という自分の文と、しばらくして返ってくる結果だけです、途中の命令文を意識しなくていいのが、思った以上に身軽でした

ひとつ注意があって、取り出す件数が多いと、既定の上限で途中まで返って打ち切られることがあります、千件を超える量を一気に頼むと、最初のいくらかが返ってきて「ここまでで止めています」という挙動になる感じですね、全部ほしいときは「もっと多く返して」と上限を上げてもらうか、条件を絞って小さく取り直します、いきなり全件をどっと返さない作りは、安全側に倒すうえでもむしろ都合がよかったです

登録自体は数行で済む

「道具を登録」と書くと身構えるかもしれませんが、Claude Codeに道具(MCPサーバー)を教えるのは設定ファイルへの数行の追記です、ファイル名は .mcp.json で、ここに「どの道具を、どう起動するか」を書きます

イメージとしてはこんな形で、サーバーの名前と起動コマンドを書くだけです(中身は環境ごとに変わります)

{
  "mcpServers": {
    "my-db-tool": {
      "command": "（自作した道具を起動するコマンド）"
    }
  }
}

この設定ファイルが何者なのか、ほかにどんな設定ファイルがあるのかはClaude Codeの設定ファイル早見表にまとめています、.mcp.json の置き場所や役割が気になったらそちらをどうぞ

そして設定ファイルを触るのが怖い人へ、ここも Claude自身に「.mcp.jsonにこの道具を登録して」と頼んで書かせるのが楽です、書いてもらった内容を自分で確認してから反映すれば、手で打ち間違える心配も減ります

コードを書けなくても自分専用の道具は作れる

最後にまとめます、今回いちばん伝えたいのは Claude Codeを使えば、設計から実装、レビュー、公開まで伴走してもらいながら、自分専用の道具(MCP)を作れるということです

振り返ると、私が手を動かしたのは「何を作るか相談する」「設計書を読んでOKを出す」「最後の確認をする」あたりで、実装そのものはほとんどClaudeに任せていました、それでもちゃんと動くものが手に入ります

• いきなり書かせず、まず壁打ちで「何を作るか」を言葉にする
• 設計と実装はClaudeに任せ、人間は読んで判断する側に回る
• 「作る役」と「チェックする役」を分け、最後に全体を見直す
• AIにデータを触らせるなら「読み取り専用」を基本に、権限は大本で絞る
• 設定ファイルが怖ければ、Claudeに書かせて内容を確認してから反映する

そして今回の出発点を思い出してほしいんですが、私が作ったのは「既製品が自分の環境に合わなかった」からでした、世の中にある道具が自分の環境にハマらないときこそ、自作の出番です

プログラムをゼロから書ける必要はありません、やりたいことを言葉にして、相談しながら一緒に作っていく、その伴走役としてClaude Codeは頼りになります、興味が出たら、まずは小さな「自分専用の道具」から試してみてはどうでしょうか?

ジャベ雄

「これ既製品じゃ届かないな」って思った瞬間が、自作のスタートラインなんですよね

Claude・生成AIを学べる本PR

面倒なことはChatGPTにやらせよう

カレーちゃん・からあげ

Amazonで見る楽天で見る

実践Claude Code入門

西見公宏・吉田真吾・大嶋勇樹

Amazonで見る楽天で見る

Claude CodeによるAI駆動開発入門

平川知秀

Amazonで見る楽天で見る

私のおすすめからランダムで3冊を表示しています

最近は Claude Code を事務職や企画職の方にも配って、日々の作業を手伝ってもらう会社が増えてきましたよね

ただ、何の準備もせずにそのまま配ってしまうと、思わぬところで事故が起きやすいんです

例えば、認証情報の入ったファイルを読まれてしまったり、消したくないフォルダを巻き込んで操作されてしまったり、といった場面が考えられます

この記事では、Claude Code を一般の社員に配るときのガードレール設計を、情シスや管理者の目線で一通りまとめます、設定ファイルの中身も具体的なコード付きで紹介していきます

「会社で配る予定はないけど、個人で使っていて事故が心配」という慎重派の方にも、そのまま真似できる構成にしているので、肩の力を抜いて読んでみてください

Claude Code のセキュリティの全体像はClaude Code Desktop 初心者向けセキュリティ5選、設定ファイルそのものの整理はClaude Code 設定ファイル早見表でも扱っているので、土台から知りたい方は合わせてどうぞ

なぜ「初期設定なしで配る」と事故るのか

Claude Code は、お願いした内容に応じて自分でファイルを読み書きしたり、裏でコマンド(プログラム命令)を実行したりできます

この自走できる力が便利さの源なんですが、配り方を間違えると、同じ力がそのままリスクにもなります

とくに、コマンドや設定ファイルに慣れていない方が使う場合、こんな場面が起こりがちです

• パスワードやAPIキーの入った .env ファイルを読み込んで、その中身が会話履歴に残ってしまう
• デスクトップやドキュメントなど、消したくないフォルダの中で作業させてしまい、関係ないファイルまで巻き込む
• 「許可をバイパス」する設定をうっかり有効にして、確認なしで何でも実行できる状態になる
• 認証情報をそのまま Git にコミットして、社外に出してはいけない情報が共有リポジトリに載る

どれも「使う人が気をつければ防げる」と言えなくはないんですが、毎回・全員が気をつけ続けるのは現実的じゃないですよね

AIならではの落とし穴もある

ここまでは、普通のソフトでも起こりそうな事故の話でした、ただ、AIを使う以上は、AIならではのリスクも頭に入れておきたいところです

1つめが プロンプトインジェクション です、これは、AIに読ませた文章(PDF・メール・Webページなど)の中に、こっそり別の命令が仕込まれていて、AIがそれを指示として受け取り、変な動きをしてしまう手口です

押さえておきたいのは、AIにとって文章は「情報」であると同時に「命令」にもなりうるという点です、ここが、普通のシステムを入れるときとの大きな違いになります

2つめが 権限の渡しすぎ です、AIの回答がただ間違っているだけなら、人が気づいて止められます、でも、ファイルの削除・メール送信・外部への公開といった「実際に動く権限」まで渡していると、先ほどのプロンプトインジェクションと組み合わさったときに、そのまま実害につながってしまいます

対策の考え方はシンプルで、人と同じようにAIにも必要最小限の権限だけ渡す、そして消す・送るといった大事な操作の前には人が確認する、この2つです、このあと出てくる permissions の deny(禁止)と ask(都度確認)が、まさにこれを設定で実現する道具になります

3つめが コネクターやMCPの扱い です、Google DriveやSlackをつなぐコネクター、外部のツールとつなぐ MCP(外部連携の共通規格)は便利なんですが、つなぎ先の権限設定が雑だと、AI経由で本来見えてはいけない情報まで引き出せてしまいます

つなぐときは、読み込み(閲覧)は許可しても、書き込みは安易に許可しないというふうに、できることを分けて考えるのがおすすめです

だからこそ、使う人の注意力に頼らず、仕組み側であらかじめ守るという発想が大事になります

ハーネス(枠組み)で守るという考え方

ここで言うハーネスは、使う人を包む安全の枠組みくらいに考えてください、車のシートベルトのように、意識しなくても勝手に守ってくれる仕掛けのことです

具体的には、管理者があらかじめ設定ファイルや作業フォルダを用意しておき、使う人はその枠の中で操作する、という形を作ります

この記事で紹介するガードレールは、おおまかに次の6つです、上から順に効果が広いものになっています

1. managed-settings.json で、上書きできない管理ポリシーを配る
2. settings.json の permissions で、できる操作とできない操作を線引きする
3. セキュリティ系プラグインで、書かれたコードを自動でチェックする
4. 作業フォルダの固定で、どこでも実行できる状態を避ける
5. .gitignore の標準配布で、認証情報をうっかり共有させない
6. 初期CLAUDE.md の配布で、社内ルールを最初から読ませる

ここまでやると「ちょっと過剰かな」と感じる場面もあると思います、ただ、事故が心配な環境なら、最初は厚めに守っておいて、慣れてきたら緩めるくらいがちょうどいいんじゃないでしょうか

1. managed-settings.json で上書きできないポリシーを配る

ガードレールの土台になるのが managed-settings.json です、これは管理者が配る「上から決めた設定」で、使う人が自分の設定で上書きできないのが大きな特徴です

Intune や Jamf といった MDM(端末を一括管理する仕組み)を使って、全社員のパソコンに同じファイルを配る、という運用が想定されています

置き場所はOSごとに決まっている

managed-settings.json は、置く場所がOSごとに決まっています、2026年6月時点の公式ドキュメントだと次の通りです

同じ場所に managed-settings.d というフォルダを作って、複数の設定ファイルに分けて置くこともできます、チームごとにポリシーの断片を分担したいときに便利です

中身は通常のsettings.jsonと同じ書き方

ありがたいことに、ファイルの中身は普通の settings.json と同じ書き方で大丈夫です、管理者として「これだけは守らせたい」という最小限のポリシーから始めるのがおすすめです

{
  "permissions": {
    "disableBypassPermissionsMode": "disable",
    "deny": [
      "Read(.env)",
      "Read(**/.env)",
      "Read(**/.env.*)",
      "Read(**/*.pem)",
      "Read(**/*.key)",
      "Read(**/id_rsa)",
      "Read(**/credentials.json)"
    ]
  }
}

この例だと、認証情報が入りがちなファイルの読み込みをまとめて禁止しつつ、確認なしで何でも実行する「許可をバイパス」モードも封じています、それぞれの中身はこのあとの章で順番に説明します

managed-settings.json に書いた内容は、使う人の設定では上書きできません、なので本当に外してほしくない守りだけをここに集約するのがコツです

設定の優先順位を押さえておく

Claude Code の設定は何層かに分かれていて、ぶつかったときにどれが勝つかが決まっています、優先順位は上が強いです

大事なのは、禁止(deny)はどの層から付けても効くという点です、ある層で禁止したものは、別の層で許可しても解除されません

つまり管理者は、managed の層で禁止を盛っておけば、使う人がどんな設定をしても穴が開かない、という安心感が得られます

2. permissions で操作範囲を線引きする

次は、Claude Code が「何をしていいか」を細かく決める permissions の話です、ガードレールの中でも一番こまかく効くところです

permissions は3つのリストでできています、それぞれの役割はこんな感じです

判定の順番は deny → ask → allow です、最初に deny にあたれば、後ろで allow に書いてあっても禁止が優先されます、なので禁止したいものは deny に書くのが確実です

危険なコマンドを deny で止める

まず止めておきたいのが、影響範囲の大きいコマンドです、ファイルを一括で消すような命令や、ネットへ自由にアクセスする命令を deny に入れておきます

{
  "permissions": {
    "deny": [
      "Bash(rm -rf *)",
      "Bash(curl *)",
      "Bash(wget *)",
      "Bash(git push *)"
    ],
    "defaultMode": "default"
  }
}

Bash というのは、Claude が裏で実行するコマンド(プログラム命令)のことです、ここでは一括削除の rm、勝手なダウンロードに使われがちな curl と wget、共有リポジトリへの送信になる git push を止めています

WebFetch でアクセス先のドメインを絞る

WebFetch は、Claude がWebページを読みにいく機能です、ここを野放しにすると、どこへでも情報を取りにいけてしまうので、許可するドメインだけ絞るやり方が安心です

{
  "permissions": {
    "allow": [
      "WebFetch(domain:docs.claude.com)",
      "WebFetch(domain:github.com)"
    ],
    "deny": [
      "WebFetch"
    ]
  }
}

書き方は WebFetch(domain:許可したいドメイン) です、この例だと、ドキュメントとGitHub以外への読み込みを止めつつ、業務で必要なところだけ通せます

「許可をバイパス」モードを封じる

Claude Code には、確認をすっ飛ばして次々に実行する「許可をバイパス」モードがあります、便利ではあるんですが、慣れていない方が使うと、止める間もなく操作が進んでしまう危険があります

これを管理者側で封じるのが disableBypassPermissionsMode です、値を “disable” にすると、設定からもコマンドからもこのモードが使えなくなります

{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  }
}

さらに徹底したいなら、allowManagedPermissionRulesOnly を true にすると、許可・確認・禁止のルールを管理者の設定だけに限定できます、使う人が勝手に許可を増やすのを防げます

permissions まわりをもう少しじっくり知りたい方は、Claude Code 設定ファイル早見表で各ファイルの役割を確認しておくと、どこに何を書けばいいか迷わなくなります

3. セキュリティ系プラグインで自動チェックを足す

設定で操作を縛るだけでなく、書かれたコードそのものを自動でチェックする仕組みも入れておくと安心です、ここで役立つのが公式のセキュリティ系プラグインです

2026年5月に公開された security-guidance は、Claude が書いたコードに危なっかしいパターンが混じっていないかを自動で見てくれるプラグインです、たとえば外部からの入力をそのまま実行してしまう書き方などを拾ってくれます

導入は Claude Code Desktop のプラグイン画面から数クリックで済みます、無料で、どのプランでも使えて、入れたあとは自動で動いてくれるので、配る側としても手間がかからないのが嬉しいところです

security-guidance の検出パターンや、deny リストとの組み合わせ方はsecurity-guidance とは 使い方と運用のコツでくわしくまとめているので、入れる前にざっと目を通しておくと運用イメージがつかみやすいです

プラグインの配布元を管理者で固定する

プラグイン自体は便利なんですが、誰がどこから入れられるかを野放しにすると、出どころの怪しいものが混ざる心配もあります

会社で配るなら、managed-settings.json 側で「入れていいプラグインの棚」を絞っておくのがおすすめです、公式の棚だけ許可しておけば、使う人は安心して選べます

4. 作業フォルダを固定して「どこでも実行」を避ける

地味ですが効くのが、作業する場所をあらかじめ決めておくという対策です

Claude Code は、起動した場所のフォルダを起点に動きます、なので、もしデスクトップやドキュメントの直下で起動してしまうと、大事なファイルが並ぶ場所で操作が走ることになります

そこで、MDM で全社員のパソコンに 所定の作業フォルダ を自動で作っておく、という手を打ちます、たとえばこんな構成です

C:\Users\(ユーザー名)\ClaudeWork\
  ├─ .gitignore        ← 認証情報を除外するリスト
  ├─ CLAUDE.md         ← 社内ルールを書いた初期ファイル
  └─ work\             ← ここで作業する

このフォルダの中で作業してもらうように案内しておけば、関係ないファイルを巻き込むリスクをぐっと減らせます、後で出てくる .gitignore や CLAUDE.md も、最初からこの中に置いておけます

さらに、Claude が触れてよいフォルダを設定で限定したいときは、additionalDirectories という項目で、追加で使ってよい場所をリスト化できます、明示した場所以外には基本的に手を出させない、という運用も組み立てられます

5. .gitignore を標準配布して認証情報を守る

つづいて、.gitignore の標準配布です、これは認証情報のうっかり共有を防ぐための、地味だけど大事な一手です

.gitignore は、Git に「このファイルは管理しないでね(=共有リポジトリにもアップしないでね)」と伝えるためのリストです、ここに書いたファイルは、コミットの対象から外れます

パスワードやAPIキーが入る .env などをここに書いておけば、Git 経由で社外に出てしまう事故を防げます、配布する雛形はこんな内容で十分です

# 認証情報
.env
.env.*
*.pem
*.key
id_rsa
credentials.json

# ローカル設定
.claude/settings.local.json

# 一時ファイル
*.log
tmp/

ポイントは、これを全員に同じ内容で配ることです、一人ひとりに「.gitignore を書いてね」とお願いしても抜けが出ますが、雛形を配ってしまえば、最初から同じ守りが効きます

Claude・生成AIを学べる本PR

面倒なことはChatGPTにやらせよう

カレーちゃん・からあげ

Amazonで見る楽天で見る

実践Claude Code入門

西見公宏・吉田真吾・大嶋勇樹

Amazonで見る楽天で見る

Claude CodeによるAI駆動開発入門

平川知秀

Amazonで見る楽天で見る

私のおすすめからランダムで3冊を表示しています

6. 初期CLAUDE.mdを配って社内ルールを読ませる

最後は 初期CLAUDE.md の配布です、ここまでが仕組みで縛る守りだったのに対し、これは「Claud に最初から読ませておく社内ルール」という、もう一段やわらかい守りになります

CLAUDE.md は、Claude Code が作業前に読み込む指示書のようなファイルです、ここに会社のルールや禁止事項を書いておくと、毎回それを踏まえて動いてくれます

配布する雛形には、作業フォルダの説明・やってほしくないこと・困ったときの相談先あたりを入れておくと親切です

# 社内Claude Code 利用ルール

## 作業する場所
- 作業は ClaudeWork\work フォルダの中で行ってください
- このフォルダの外にあるファイルは、勝手に触らないでください

## やってほしくないこと
- .env や鍵ファイル(*.pem / *.key)の中身を会話に出さない
- 共有リポジトリへの送信(git push)はしない
- 設定ファイルを書き換えるときは、内容を私(利用者)に見せてから書く

## 困ったとき
- 操作に迷ったら止まって、情報システム部に相談してください
- 連絡先: jyoshi@example.com

ここで1つ気をつけたいのは、CLAUDE.md はあくまで「お願い」であって、強制力はないという点です

本当に守らせたい禁止は、これまで紹介した managed-settings.json の deny で仕組みとして縛る、CLAUDE.md は方針や心構えを伝える、という役割分担で考えると分かりやすいです

入力していい情報・ダメな情報を3段階で決める

ここまでは「操作」を縛る守りでした、もう1つ、配る前に決めておきたいのが 何を入力していいか の線引きです、これは設定ファイルではなく、社内ルールとして決めておくものになります

細かく決めすぎると運用が回らなくなるので、ざっくり3段階に分けるのがおすすめです

真ん中の「条件つきでOK」は、入力した内容がモデルの学習に使われない契約で、かつアクセス権が守られている範囲で、という前提つきです、Anthropicの公式ドキュメントによると、2026年6月時点では、Team・Enterprise・API といった法人(コマーシャル)契約では、Claude Codeに送ったコードやプロンプトを既定でモデル学習には使わない、とされています(ただし管理者が Developer Partner Program などに自分から参加した場合は、学習の対象になりえます)

それと、学習とは別の話として、やり取りの履歴は手元のパソコンにしばらく残ります(既定で30日ほど)、なので「原則NG」のパスワードや鍵は、学習に使われるかどうか以前に、最初から入力させないのが基本です、ここは前に紹介した deny の読み込み禁止や .gitignore と合わせて、二重で守る形になります

この3段階は、先ほどの 初期CLAUDE.md に書いておくと、配るだけで全員に同じ基準が共有できます、文章での共有はあくまでお願いなので、原則NGのものは deny でも止めておく、という合わせ技がおすすめです

設定のプライバシー画面で学習と位置情報を確認する

前の章は「契約として学習に使われるかどうか」という制度の話でした、ただ、個人プラン(Free・Pro・Max)の方が実際に学習を止めたいときは、設定画面のトグルを一度確認しておくのが早いです

場所は 設定 → プライバシー です、Claude Code Desktop の設定を開いて、左メニューの プライバシー を選ぶと、データの扱いに関する項目がまとまっています

この画面の「設定」という区画に、確認しておきたいトグルが2つ並んでいます

肝になるのが AIモデルの改善にご協力ください です、ここをオンにしていると、個人プランではチャットやコーディングセッションが将来のモデル学習に使われます(Claude Code 経由のやり取りも含みます)、オフにすると、それ以降の新しいやり取りは学習に使われなくなります

同じプライバシー画面を下にスクロールすると あなたのデータ という区画もあります、ここから、これまでのデータのエクスポートや、共有したチャット・アーティファクトの管理ができます、共有したまま忘れていた履歴を見直したいときに開いてみてください

ジャベ雄

契約で守られていても、個人プランはトグル1つで扱いが変わります、配る前にこの画面をそろえておくと安心です

個人でも真似したい最小セット

ここまで会社向けの話をしてきましたが、「うちは会社じゃないし、そこまではいらないかな」という方も多いと思います

そこで、個人で使う慎重派の方が真似する価値のある最小セットを、3つに絞ってまとめておきます

• settings.json の deny に .env 系と危険コマンドを入れる:認証情報の読み込みと一括削除を止める、これだけで事故の多くが防げます
• .gitignore に認証情報を書く:Git を使うなら、.env や鍵ファイルを最初に除外しておく
• 作業フォルダを1つ決める:専用のフォルダの中だけで Claude Code を使うようにして、大事なファイルから離す

managed-settings.json や MDM 配布は会社向けの仕組みですが、個人なら自分の settings.json に同じ deny を書くだけで近い効果が得られます、管理者がいない分、自分が管理者のつもりで一度だけ設定しておく、というイメージです

設定が不安なら Claude 自身に頼む手もある

「設定ファイルを自分でいじるのは怖い」という方は、Claude 自身に書いてもらうのも手です、やりたいことを言葉で伝えれば、中身を用意してくれます

たとえば、こんな感じで頼んでみてください

このプロジェクトの settings.json を作りたいです。
次の方針でお願いします。

・.env や鍵ファイル(.pem / .key)の読み込みを deny で禁止
・rm の一括削除と git push を deny で禁止
・「許可をバイパス」モードは使えないようにする

書き込む前に、設定内容を一度わたしに見せてから保存してください。

最後の「書き込む前に見せてね」の一言がポイントです、内容を確認してから保存すれば、知らないうちに変な設定が入る心配もありません

よくある質問

まとめ

事務職や企画職の方に Claude Code を配るときは、使う人の注意力に頼らず、仕組みで守るのが基本でした

この記事で紹介したガードレールを、もう一度おさらいしておきます

• managed-settings.json:MDMで配る、上書きできない管理ポリシー
• permissions の deny:危険コマンドと認証情報の読み込みを止める
• セキュリティ系プラグイン:書かれたコードを自動でチェックする
• 作業フォルダの固定:どこでも実行できる状態を避ける
• .gitignore の標準配布:認証情報の共有を防ぐ
• 初期CLAUDE.md:社内ルールを最初から読ませる

あわせて、AIならではのリスク(プロンプトインジェクションや権限の渡しすぎ)を頭の片隅に置きつつ、入力していい情報の線引きを社内で決めておくと、守りがぐっと固くなります

会社で配る予定がなくても、deny・.gitignore・作業フォルダの3つは個人でも真似する価値があります、慎重派の方ほど、最初に一度だけ仕込んでおくと、後がずっと気楽になりますよ

関連する話として、Claude Code Desktop 初心者向けセキュリティ5選では使い始めの守り方を、security-guidance とは 使い方と運用のコツではプラグインによる自動チェックをくわしく扱っています、合わせて読むと、自分の環境に合った守りを組み立てやすくなると思います

Claude・生成AIを学べる本PR

面倒なことはChatGPTにやらせよう

カレーちゃん・からあげ

Amazonで見る楽天で見る

実践Claude Code入門

西見公宏・吉田真吾・大嶋勇樹

Amazonで見る楽天で見る

Claude CodeによるAI駆動開発入門

平川知秀

Amazonで見る楽天で見る

私のおすすめからランダムで3冊を表示しています

Claude Code を触っていて、「AIが勝手に書いたコードに、地雷が混じってないか心配」と感じたことはありませんか？

2026年5月26日に Anthropic から公開された security-guidance は、その不安に正面から答える公式のセキュリティ系プラグインです

この記事では、Claude Code Desktop を使い始めた方〜慣れてきた方向けに、security-guidance が何をしてくれて、どう入れて、どう使えばいいのかを一通り解説します

ついでに、このプラグインだけでは守りきれない部分をどう補うか(deny リスト・自動モード・MCP の注意点など)も横展開で触れます

Claude Code のセキュリティ全体像はClaude Code Desktop 初心者向けセキュリティ5選、プラグインを支える土台はClaude Code 拡張機構入門でも扱っているので、合わせて読むと位置づけが立体的になります

そもそも security-guidance って何のプラグイン？

ざっくり言うと、Claude がコードを書いた瞬間に、その内容を別の Claude がセキュリティ目線でレビューしてくれる仕組みです

もう少し正確に言うと、Claude Code には「プラグイン」と呼ばれる拡張パッケージの仕組みがあり、その公式マーケットプレイス claude-plugins-official に並んでいる中の1つが security-guidance です

大事なポイントは次の3つです

• Anthropic 公式のプラグインなので、出どころの安心感が大きい
• 無料・全プラン対応、課金プランでなくても使える
• 導入後は裏で勝手に動く、毎回コマンドを打つ必要はない

公開直後から大きな注目を集め、Claude にコードを書かせる人ほど効きやすい性質のプラグインとして広く紹介されています

何ができる？ 3層のレビューでコードを見張る

security-guidance が偉いのは、3つのタイミングで深さの違うレビューを走らせてくれるところです

レイヤー1:ファイルに書き込んだ瞬間のパターン照合

Claude がファイルを編集するたびに、「危ない書き方」が含まれていないかを高速チェックします

ここは AI の追加呼び出しを伴わない、いわゆる文字列マッチによる照合なので、余分な利用料金は発生しません

「ファイルが書かれたら、その内容を辞書と突き合わせて怪しい言葉が出てきたら警告する」というイメージです

レイヤー2:ターンの終わりにまとめてレビュー

Claude が「はい、ここまでで一区切りです」と返した瞬間、そのターンで変わったファイルをまとめて 別の Claude にセキュリティレビューさせる動きが入ります

ここで言う ターンとは、こちらが1回メッセージを送って、Claude が動いて返事して、その応答が終わるまでの1往復のことです

このレイヤーは、文字列マッチでは見抜けない 権限まわりの抜け穴・脆弱な暗号化・想定外の入力経路みたいな話を拾ってくれます

裏で動くため、Claude の返答自体は遅くなりません、見つかった指摘は次の応答で「ここ直しておきますね」と本人(Claude)が修正してくれるイメージです

レイヤー3:コミットの直前にじっくりレビュー

Claude が git commit や git push を実行しようとしたタイミングでも、もう一段深いレビューが走ります

このレベルになると周辺コード(呼び出し元・サニタイズ処理など)まで読んだ上で「これは実際にヤバいやつ」か「文脈上は安全」かを判定してくれます

このおかげで 「形だけ見ると危なそうだけど、実は文脈的に大丈夫なコード」を誤検出しすぎないように調整されています

どんな脆弱性パターンを見つけてくれる？

レイヤー1(ファイル編集時)で照合される代表的なパターンを、噛み砕いて紹介します

専門用語が多めなので、それぞれ「要は何が問題なのか」をセットで書きます

eval() や new Function() :「文字列を実行コードにしてしまう」系

JavaScript の eval() や new Function() は、文字列をそのままプログラムとして実行する関数です

つまり、外部から渡された文字列がうっかり混ざると、悪意のあるコードがそのまま動いてしまう恐れがあります

child_process.exec() や os.system() :「コマンドをそのまま投げる」系

Node.js の child_process.exec() や Python の os.system() は、シェル(=Windowsで言うコマンドプロンプト的なもの)に命令文を渡す関数です

ユーザーが入力した値をそのまま結合してしまうと、想定外のコマンドが任意に実行される事態になります、いわゆるコマンドインジェクションです

dangerouslySetInnerHTML や innerHTML :「画面表示がそのまま乗っ取られる」系

React の dangerouslySetInnerHTML や、素の JavaScript の .innerHTML = は、HTML を直接埋め込む書き方です

ここに ユーザーが入力した文字列をそのまま入れると、スクリプトタグごと埋め込めてしまう=いわゆる XSS(クロスサイトスクリプティング)の温床になります

pickle :「保存したデータを読むだけのつもりが、コードまで動く」系

Python の pickle は、データを丸ごとファイルに保存して、後で読み戻すための仕組みです

便利な反面、信頼できないファイルを pickle で読み込むと、読み込み処理の中で任意のコードが実行される設計になっています、外部から受け取ったファイルを pickle で開くのは原則として避けるのがおすすめです

.github/workflows/ 配下の編集 :「GitHub Actions の権限を握る」系

GitHub Actions の設定ファイル(.github/workflows/ 配下の YAML)は、ビルドやデプロイの自動化を定義する場所です

ここを書き換えられると リポジトリ単位の権限を握られることになるので、Claude が触ろうとしたら一律で注意喚起されます

ほかにも document.write などの古い書き方をはじめ、いくつかの代表的な落とし穴に反応するようになっています

導入方法 Desktop ユーザーの最短ルート

Claude Code Desktop での導入は、3ステップで終わるかんたんさです

Desktop の「プラグイン」サブメニューは シンプルな作りで、上にインストール済みプラグインが並び、下に 「プラグインを管理」(歯車アイコン)と 「＋ プラグインを追加」のボタンがあるレイアウトです、迷う要素はあまりないので、追加のボタンから順に進めば security-guidance が一覧に並びます

使ってみるとどう動く？ 実際の見え方

導入直後は、基本的に 普段どおりに Claude を使うだけでかまいません

「コードを書いて」「ここを直して」とお願いしている裏で、上で説明した3層レビューが勝手に走っている感じです

レビューで何か見つかった時の会話の流れ

たとえば Claude が JavaScript で eval() を含むコードを書いたとします

すると次のターンの冒頭で Claude が 「security-guidance から指摘が来ました、eval は危ないのでこちらの書き方に直しますね」のような前置きと一緒に、安全な実装に書き換えてくれます

こちらが「セキュリティチェックして」と頼まなくても、コードに変更があった時点でレビューが走るのがこのプラグインの一番の旨味です

プロジェクト固有のルールも足せる

「うちのアプリでは admin ルートには原則として権限チェックを入れたい」みたいな プロジェクト固有のルールも、追加で食わせられます

プロジェクト直下に .claude/claude-security-guidance.md という Markdown を置き、普段の日本語で「これは NG」「ここは原則として通す」と書いておけば、レビュー時に追加のお作法として参照してくれます

そのほか、決まった文字列(例:本番用 API キーの先頭文字列)を機械的に検出したいときは .claude/security-patterns.yaml に独自の正規表現を書く手もあります

ファイル形式の細かい仕様(YAML スキーマ・JSON 形式での代替・User / Project / Project local の3階層での探索順など)は Anthropic 公式ドキュメントのAdd your own rulesセクションに一次情報がまとまっているので、独自ルールを本気で書き込むときはそちらが正本になります

他の安全対策と組み合わせる プラグイン以外の打ち手

security-guidance は強力ですが、これ単体で Claude Code のセキュリティが完成する訳ではありません

あくまで「書いた瞬間に一次レビューを挟む」というレイヤーなので、それと並行して整えておきたい安全策を横並びで紹介します

settings.json の deny リストで「触らせない」枠を作る

Claude Code には settings.json という設定ファイルがあり、ここに「触ったらアウトのファイル」を列挙できます

具体的には permissions.deny セクションで、見られたくない・書き換えてほしくないパスを指定する形です

最低限デフォルトで入れておきたいのは次のあたりです

• .env 系(APIキー・パスワードがよく入っているファイル)
• .pem .key(SSL 証明書・秘密鍵)
• id_rsa(SSH の秘密鍵)
• credentials.json(各種クラウドサービスの認証情報)

イメージとしては次のような書き方になります

{
  "permissions": {
    "deny": [
      "Read(./**/.env)",
      "Read(./**/*.pem)",
      "Read(./**/*.key)",
      "Read(./**/id_rsa)",
      "Read(./**/credentials.json)"
    ]
  }
}

これにより、security-guidance が 「書いた後」にレビューするのに対し、deny リストは 「そもそも触らせない」側のガードを担当します、役割が違うのでセットで使うと安心感が増します

「自動モード」と「許可をバイパス」は別物

Claude Code Desktop の挙動モードでよく混同されるのが、「自動モード」と「許可をバイパス」の2つです

名前が似ていて紛らわしいですが、中身はまるで違います

respectGitignore で .gitignore のファイルを除外する

地味に効くのが respectGitignore: true という公式オプションです

これを settings.json に入れておくと、プロジェクトの .gitignore に書かれているファイルが、そのまま Claude のファイル選択画面からも除外されます

.gitignore は 「Git に管理してほしくない=GitHub にもアップしないでほしい」リストで、もともと .env や ビルド成果物などが入っていることが多いので、それがそのまま Claude の対象外になるのはありがたい挙動です

MCP サーバーを入れる時の確認ポイント

もう1つ、忘れずに整えておきたいのが MCP 関連の確認です

MCP(Model Context Protocol)は、Claude に外部ツールやデータベースを使わせるための仕組みですが、MCP サーバーやプラグインはあなたの権限で任意のコードを実行できる高信頼コンポーネントです

つまり、出どころが怪しい MCP サーバーを入れるのは、得体のしれないソフトをインストールするのと変わりません

• 公式・有名なソース(Anthropic・大手 OSS プロジェクト)からのみ入れる
• 説明文だけで判断せず、READMEやコードに目を通す
• 必要が無くなった MCP サーバーは早めに無効化する

security-guidance 自体は Anthropic 公式なので信頼性の面で気にする必要はありませんが、「プラグインや MCP は全部安心」と勘違いしないのが大事です

このあたりの基本設計はClaude Code 設定ファイル早見表で全体像を整理しているので、深掘りしたい方はそちらもどうぞ

期待しすぎないこと プラグインの限界

ここまで読むと「もう security-guidance を入れておけば安心」と思いたくなりますが、過信は禁物です

正直に言うと、このプラグインは 「コードを書く瞬間によくあるパターンを止める」レイヤーであって、セキュリティ対策のすべてを引き受けてくれる訳ではありません

設計や仕様レベルの脆弱性は別途レビューが要る

例えば「そもそも認証フローがおかしい」「権限の設計が甘い」みたいな話は、文字列マッチでは見つかりません

ターン終了時やコミット時のレビューでは多少ひっかかる可能性はあるものの、設計や仕様レベルの問題は人間のコードレビューや設計レビューで拾うのが原則です

依存ライブラリの脆弱性は対象外

あなたが書いたコード自体は問題なくても、使っているライブラリに脆弱性があったというケースは多々あります

これは security-guidance のスコープ外で、別途 npm audit や Dependabot のような 依存関係チェックの仕組みを並走させるのが現実的です

レビュワーAIも見落とす

レイヤー2・3で動くレビュー側の Claude も、人間と同じく見落とすことがあります

「プラグインが何も言わないから安全」は思考停止のサインです、最終的にはコードを読む(=人間がレビューする)習慣も並行して持っておくのが望ましいです

内部にある上限とモデル設定も知っておく

もう少し細かい話として、レビューには 上限が設けられています、知っておくと「あれ動いてない?」となったときに切り分けやすいです

• ターン終了時のレビューは 1ターン最大30ファイルまで、しかも連続3回までで一旦止まります
• コミット時のレビューは 1時間に20回まで、それを超えると一時的に走らなくなります

大量変更や連続 commit を続けると、全部はカバーしきれないというのを頭の片隅に置いておくと安全です

初心者向けおすすめ運用フロー

「結局、何からやればいいの？」という方向けに、最初に押さえるステップを順に並べておきます

このあたりまで整えると、security-guidance を含めた多層の守りがだいぶ立体的になります

よくある質問(FAQ)

まとめ プラグイン1つで完結はしないけど、入れる価値は十分

security-guidance は、Claude にコードを書かせるなら入れない理由がほぼ無いくらいに気軽に導入できる公式プラグインです

大事なポイントをおさらいします

• Anthropic 公式・無料・全プラン対応、入れない理由はほぼ無い
• 3層レビュー(編集時・ターン終了時・コミット時)で多角的にチェック
• eval / 外部コマンド / XSS / pickle / GitHub Actions など典型的な落とし穴を拾う
• 書き込みを止める訳ではない、Claude にレビュー結果を渡して直してもらう設計
• deny リスト・自動モード・respectGitignore と組み合わせて多層防御に
• 設計・依存ライブラリ・未知の脆弱性は対象外なので過信しない

個人的には、「ちゃんと整えれば、Claude にコードを任せても怖くないラインまで来た」と感じます

Claude Code の安全策を一通り整理したい方はClaude Code Desktop 初心者向けセキュリティ5選、プラグインまわりの土台が気になる方はClaude Code 拡張機構入門、設定ファイルの全体像はClaude Code 設定ファイル早見表もどうぞ

security-guidance を入れたうえで、deny を整えて、自動モードで使う、この3点を押さえておくと、Claude Code との付き合い方がぐっと安心側に寄ります

Claude・生成AIを学べる本PR

面倒なことはChatGPTにやらせよう

カレーちゃん・からあげ

Amazonで見る楽天で見る

実践Claude Code入門

西見公宏・吉田真吾・大嶋勇樹

Amazonで見る楽天で見る

Claude CodeによるAI駆動開発入門

平川知秀

Amazonで見る楽天で見る

私のおすすめからランダムで3冊を表示しています

Claude Code Desktopを使い始めるとき、最初にぶつかる不安が「これって、勝手にファイル消されたりしないの？」「うっかりパスワード漏らさない？」という疑問じゃないでしょうか

結論から言うと、初期設定でちゃんと枠を作っておけば、かなり安心して使えるようになります

この記事では、Claude Code Desktopを始める非IT職の方向けに 最初の15分でやっておきたい最低限のセキュリティ対策を5つにまとめました

難しいプログラミング知識は不要、コピペで使える設定例も載せています

Claude自体の基本的な使い方はClaudeの使い方を初心者向けに解説した記事でまとめているので、まずそちらから読むとスムーズです

なぜClaude Code Desktopにセキュリティ対策が必要なのか

Claude Code Desktopはとても便利で、自分の代わりにファイルを読んだり、コードを書いたり、PCの中で色々な作業をしてくれます

でも裏を返すと、そこまでの権限をAIに渡しているということでもあります

もし何も設定せずに使っていると、たとえばこんなリスクがあります

• うっかり大事なファイルを削除されてしまう
• WordPressのパスワードがコードに書き込まれてGitHubに公開される
• 「やり直して」と言ったらgitの履歴が一気に消える
• 悪意のあるWebサイトを読み込んで、変な指示に従ってしまう

怖い話に聞こえるかもしれませんが、これは 初期設定をちゃんとやれば、ほぼ全部防げる話です

Claude Code Desktopのセキュリティは、ざっくり次の3層構造で守ります

1. 権限設定（settings.json）:「これはやらせない」を機械的に決める
2. プロジェクト指示（CLAUDE.md）：「こういう方針で動いてね」とAIにお願いする
3. 運用のルール：パスワードはコードに書かない、確認してからコミットするなど

本記事ではこの3層を、ひとつずつ整えていきます

対策1：設定ファイル「settings.json」の場所と用語を理解する

まずはClaude Code Desktopの本丸、権限を決める設定ファイルについて理解します

設定ファイルは3か所ある

Claude Code Desktopの権限設定は settings.json というJSONファイルに書きます、場所は次の3つです

個人ブログ運営のような自分1人の作業なら、まずは ~/.claude/settings.json（ユーザーフォルダ共通）に基本ルールを書いておけばOKです

ちなみに「JSONファイルを編集するのは怖い」という方は、Claudeに頼んで編集してもらうのが一番楽です、「~/.claude/settings.json に○○の設定を追加して」とお願いすればClaude Code Desktop自身がやってくれます

用語：allow / ask / deny / Bash とは

権限設定では、Claudeにやらせる操作を3つの態度に分けます

• allow（許可）：何も聞かずに実行してOK、安全な作業に使う
• ask（確認）：実行する前に「やってもいい？」と一度聞いてくる
• deny（拒否）:機械的に実行を止める、最強の鍵

そして「Bash」というのは、Claudeが裏で実行するコマンド（プログラム命令）のことです

自分で直接打つわけではなく、Claudeに「○○して」とお願いしたときに Claudeが必要に応じて使う仕組み、と思っておけば十分です

たとえば Bash(rm *) と書くと「Claudeが rm という削除コマンドを使おうとする操作」を指します

ファイル操作なら Read（読み込み）、Edit（編集）、Write（書き込み）といった種類もあります

このあと出てくる設定例を見るとイメージ湧くと思います

対策2：秘密の情報（パスワード・APIキー）を守る3ステップ

WordPressのパスワードや各種APIキー、こういう 秘密情報の漏えいはClaude Code Desktop利用時の事故で一番起きやすいトラブルです

守り方は3ステップで完結します

ステップ1：秘密情報は「.envファイル」に集約する

.env（ドット・イー・エヌ・ブイ）というファイル名で、プロジェクトフォルダの中に作ります

WP_BASE_URL=https://example.com
WP_USERNAME=admin
WP_APP_PASSWORD=xxxx xxxx xxxx xxxx xxxx xxxx
OPENAI_API_KEY=sk-xxxxxxxxxxxxxxxxxxxxxxxx

ポイントは パスワードやAPIキーを直接コードに書かない、そして このファイルだけにまとめておくこと

コードからはこのファイルを読み込むようにしておけば、後でパスワードを変えるときも .env を書き換えるだけで済みます

ステップ2：「.gitignore」でGitに含めない

.gitignore（ドット・ギット・イグノア）はGitに 「このファイルは管理しないでね（=GitHubにもアップしないでね）」と伝えるためのリストです

.env
.env.local
.env.*
/secrets/

これを入れておくと、うっかり git add や git push しても .env はGitHubに送信されません

逆にこれを忘れて公開リポジトリにパスワードを上げると 数分以内にbotが拾って悪用されることもあるくらいなので、最初に入れておくのを強く推奨します

ステップ3：settings.jsonでClaudeに読ませない

最後に、Claude自身が .env や秘密鍵を読まないように settings.json でブロックします

{
  "respectGitignore": true,
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(./secrets/**)",
      "Read(./**/*.pem)",
      "Read(./**/*.key)",
      "Read(./**/id_rsa)",
      "Read(./**/credentials.json)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/credentials)"
    ]
  }
}

こうしておけば 「.envの中身を見せて」とお願いしてもClaude側でブロックされます

リストには .env 系のほかに、.pem や .key といった秘密鍵ファイル、SSH接続用の id_rsa、Googleサービスで使われる credentials.json、SSH鍵フォルダやAWS認証情報フォルダなど、各種認証ファイルをまとめて拒否しています

うっかり「.envを開いて」「秘密鍵見せて」みたいなことが起きても、ここで止まる仕組みです

1行目の "respectGitignore": true はちょっと違うタイプの設定で、.gitignore に書いたファイルをClaudeのファイル選択画面から自動的に除外する機能を有効にします

ステップ2で .gitignore に登録した .env などが、そもそもClaudeの目に触れる場面を減らせる効果があります（デフォルトで true ですが、明示しておくと意図が伝わって安心です）

「.claudeignore」は公式じゃないので使わない

古い記事や一部のSNSで「.claudeignore というファイルを置けば除外できる」という情報を見かけますが、これは 2026年5月時点でAnthropic公式にはサポートされていません

Claude自身が「.claudeignore がある」と幻覚を起こすケースまであるくらいで、書いても効かないので注意

除外設定は settings.json の permissions.deny でやるのが正解です

対策3：危険な操作からプロジェクトを守る

次は「やられたら困る」コマンド系の防御です

自分が直接打つわけではないですが、Claudeが裏でやろうとする操作を制限する設定です

最低限denyしておきたいコマンド

{
  "permissions": {
    "deny": [
      "Bash(rm -rf*)",
      "Bash(git reset --hard*)",
      "Bash(git push --force*)",
      "Bash(git push -f*)",
      "Bash(DROP TABLE*)",
      "Bash(DELETE FROM*)"
    ],
    "ask": [
      "Bash(git push*)",
      "Bash(rm*)"
    ]
  }
}

それぞれが何を防ぐのかは下の表を見てください

「自分はそんなコマンド打たないから関係ないかも」と思うかもしれませんが、Claudeに「整理して」「やり直して」とお願いした時に裏でこれらが動く可能性があります

表の上3つは個人ブログ運営でも普通に出てくる話なので、特に押さえておきたいところです

便利だけど危険な設定

Claude Code Desktopの設定画面に 「バイパス権限モードを許可」というトグルがあります

名前のとおり すべての権限チェック（denyやaskを含む）をバイパスして、Claudeを中断なく動作させるための設定です

確かにlintエラーの修正やボイラープレートコード生成のような「安全と判断できる繰り返し作業」を快適にこなせる便利な機能で、画面の説明文にもそういった用途が書かれています

ただし同じ画面に 「データ損失、システム破損、またはデータ流出（プロンプトインジェクション攻撃など）を引き起こす可能性」と明記されているとおり、リスクのほうがはるかに大きい設定です

この設定をONにすると、画面下のモード切替メニューに 「許可をバイパス」モードが選択肢として現れる仕組みで、OFFの間は同じ位置にグレーアウトで表示されています

つまり このトグル自体が、危険モードを使えるかどうかの鍵になっているわけです、ONにしないことを強く推奨します

慣れて油断したタイミングほど事故が起きるので、面倒さよりリスクのほうが圧倒的に大きいです

「毎回確認が面倒だから」と感じる場合は、代わりに 「自動モード」を選ぶのがおすすめです

参考までに、画面下のモード切替メニューの中身はこんな感じです

自動モードは denyルールは守りつつ、多くの操作を自動進行してくれるモードなので、ガードレールを保ったまま快適に使えるバランスの良い選択肢になります

対策4：CLAUDE.mdで「お願いごと」を伝える

権限設定だけでなく、もう一段の保険として CLAUDE.md というファイルにルールを書いておきます

CLAUDE.mdの位置づけ

CLAUDE.md はプロジェクトフォルダの直下に置く Claudeへの常時指示書です

Claude Code Desktopが起動するたびに自動で読み込まれて、会話中の判断のベースになります

ただし注意点として、CLAUDE.md はあくまで 「お願いベース」です

settings.json のdenyのように機械的にブロックされる強制力はなく、Claudeが「これは例外的にやってもいいかな」と判断することもあります

なので 機械的に止めたいことは settings.json のdenyに書く、方針として伝えたいことは CLAUDE.md に書く、というすみ分けで考えてください

コピペで使えるCLAUDE.mdテンプレート

# プロジェクト方針

## 秘密情報の扱い
- APIキー・パスワードは原則 `.env` ファイルに入れる、コードに直接書かない
- `.env` の中身を画面に表示しない（cat や echo で出さない）
- ID・パスワードらしき文字列を見つけたら、コードに書く前に私に確認する

## ファイル操作
- ファイル削除は私の明示的な指示があるまでしない
- 削除する場合も、まず削除対象のリストを見せて確認を取ってから実行する

## Git操作
- main / master ブランチへの直接コミット・pushはしない、原則として別ブランチで作業する
- `git push` する前に「pushしていいですか？」と一度確認する

## 動作確認
- コードを変更したあとは、動作確認の手順を提示する
- 確認が取れていない変更を「完了」と報告しない

このテンプレを CLAUDE.md として保存して、プロジェクトフォルダに置くだけでOKです

自分の運用に合わせて項目を増やしたり、文言を調整したりして使ってください

ID・パスワードの自動検知について

「コードに秘密情報を入れようとしたら自動で止めてほしい」というニーズはよくあるのですが、Claude Code Desktop単体ではそういう自動検知機能はありません

上のテンプレに含めた「ID・パスワードらしき文字列を見つけたら確認する」という指示で ある程度は気づいてもらえます

ただし完璧ではないので、本格的に防ぎたい場合は Gitleaks や truffleHog といった専用ツールを併用するのが本筋になります（これは中級者向けなので別記事で扱います）

対策5：もう一歩進んだ安全策（＋α編）

ここまでの4つで最低限の防御はできているので、ここから先は 慣れてきたら追加で検討するものとして軽く紹介します

Plan Modeで事前確認

Claude Code Desktopには「Plan Mode」というモードがあります

これを有効にすると、Claudeは 実行する前に「こういう手順でやろうと思います」という計画だけを提示してくれて、こちらがOKを出すまで実際の作業には進みません

大きな変更や、初めての種類の作業のときには特におすすめです、Shift+Tabキーで切り替えられます

Hooksで自動チェック

「Hooks」は Claudeが何かする前後に自動で動く小さなスクリプトを仕込む機能です

たとえば「Claudeがコマンドを実行する直前に、危ないキーワードが含まれていたらブロックする」といった自動チェックを差し込めます

スクリプトを書く知識が必要になるので、これは本格的に運用したくなってきた頃の選択肢として覚えておく感じでOKです

サンドボックスで隔離する

「サンドボックス」は Claudeが触れる範囲を仮想的な囲いの中だけに制限する仕組みです

万一おかしな動きをしても、囲いの外には影響しないので安心度が一段上がります

ただし設定するにはDockerなどの専門ツールが必要で、非IT職の方やバイブコーディング的にサクッと使いたい方には少しハードルが高めです

「権限設定とCLAUDE.mdだけだとちょっと不安、もう一段固めたい」と感じたら検討する選択肢、くらいの位置づけで覚えておけば十分です

おまけ｜実はこれ全部Claudeに頼めます

ここまで読んで「いろいろ設定があって面倒そう」と感じた方、安心してください

実はこの記事で紹介した設定、ほとんどClaude Code Desktop自身にお願いできます、JSONファイルの編集なんて普段やらない人には腰が引ける作業ですが、AIに頼めば数分で全部終わります

Claudeに頼めること

• settings.json への deny や respectGitignore の追加
• .gitignore の作成と中身の追加
• CLAUDE.md のテンプレート作成
• .env.example（認証情報の枠だけ）の作成

コピペで使える依頼テンプレート

たとえばこんな感じで頼めばOKです

このプロジェクトのセキュリティ初期設定をしてほしい

1. ~/.claude/settings.json に以下を追加
   - "respectGitignore": true
   - .env や秘密鍵系（.pem / .key / id_rsa / credentials.json）の Read を deny

2. このプロジェクトに .gitignore を作って次を追加
   - .env / .env.local / .env.*
   - /secrets/

3. このプロジェクトに CLAUDE.md を作って次の方針を書く
   - 秘密情報の扱い（APIキー・パスワードは .env に集約、コードに直書きしない）
   - ファイル削除は明示的な指示があるまでしない
   - git push 前に確認を取る

4. .env.example を作って必要な環境変数の枠（値は空でOK）を用意

設定内容はそれぞれ私に提示してから書き込んでね

最後の 「設定内容はそれぞれ私に提示してから書き込んでね」がポイントです、変な設定が紛れ込まないよう一度確認できます

自分でやる必要があるもの

• .env の実際の値（パスワード・APIキー）：Claudeに値を入れさせると架空の文字列で埋めてしまうことがあるので、自分でコピペするのが安全
• 「バイパス権限モードを許可」トグル：GUI設定なのでClaudeでは触れない、デフォルトOFFなので「触らない」だけでOK

それでも理屈を先に学ぶべき理由

ここまで読んで「Claudeに頼めるなら、この記事を最初から読まなくてもよかったのでは?」と思うかもしれません

でも実は、記事で紹介した 「何のために何をやっているか」が分かっていることが大事です

Claudeも完璧ではないので、頼んだ内容と微妙に違う設定が出てくることもあります、そのとき 「想定通りか」を自分の目で確認できるのは、ここまで読んだ人だけの強みです

逆に「中身わからないけど全部任せた」状態だと、おかしな設定が混ざっていても気付けません

記事の知識 + Claudeへの依頼、この組み合わせが一番安全で速いやり方になります

まとめ｜最初の15分でやる5つの設定

長くなりましたが、要点を整理するとこんな感じです

1. settings.jsonで権限設定の仕組みを理解する（allow / ask / deny）
2. 秘密情報は.env + .gitignore + settings.jsonのdenyの3段構えで守る
3. rm -rf や git push –force などClaudeが裏で使う危険な操作をdenyに登録する
4. CLAUDE.mdでAIへの方針（お願いごと）を明文化する
5. 慣れてきたらPlan Mode・Hooks・サンドボックスなどで一段守りを固める

ポイントは 「機械的に止めたいこと」と「方針として伝えたいこと」をきっちり分けること

前者は settings.json のdenyで機械的にブロック、後者は CLAUDE.md でお願い、この使い分けができれば最低限のガードレールは整います

そして個人的に大事だと思うのが、「設定したから安心」じゃなくて、変更内容は毎回ちゃんと自分でレビューすること

AIが書いたコードや実行しようとする操作を、最後に自分の目で確認する習慣を持っておくと、設定の網を抜けた問題にも気付けます

Claude Code Desktopはとても強力なツールなので、安全に使う枠組みを最初に作っておけば、長く快適に付き合えると思います

Claude自体の基本的な使い方はこちらの記事で解説しているので、まだの方はぜひ合わせてどうぞ

Claude・生成AIを学べる本PR

面倒なことはChatGPTにやらせよう

カレーちゃん・からあげ

Amazonで見る楽天で見る

実践Claude Code入門

西見公宏・吉田真吾・大嶋勇樹

Amazonで見る楽天で見る

Claude CodeによるAI駆動開発入門

平川知秀

Amazonで見る楽天で見る

私のおすすめからランダムで3冊を表示しています

理由はさておきVBAのパスワードを解除したくなることってありませんか？

自分で作ったマクロにパスワードをかけたのに肝心の合言葉を忘れてしまって中身を直せない、なんて話は私も身に覚えがあります

古くはバイナリエディタで書き換える手もありましたが、今はVBAのプログラムを実行するだけでロックされたコードを確認できるようになっています

このページでは自分のファイル(自作マクロのパスワード忘れ)を救済する前提で手順をまとめます、他人や業務で受け取ったファイルへ無断で使うものではないので、そこだけ先にお伝えしておきますね

そもそもVBAのパスワード保護とは

手順に入る前に、なぜパスワードがかかっているのに回避できてしまうのかを軽く押さえておきます

VBAProject(マクロのコードを束ねている入れ物)にかけるパスワードは、ファイルの中身をガッチリ暗号化しているわけではなくて、エディタ上でコードを表示させないための制限に近い仕組みです

正しいパスワードを入れたかどうかをExcel側が確認して、合っていればコードを開く、という判定をしているだけなんですね

裏を返すと、その判定の部分に「もう正解が入りましたよ」と思い込ませることができれば、パスワードを知らなくてもコードが開けてしまうわけです

今回紹介するプログラムは、まさにこの判定をすり抜けるアプローチをとっています、つまりVBAのパスワードはセキュリティとしては弱めで、おまけ程度の鍵だと思っておくのが現実的です

解除手順

細かい操作はほとんどないので、サクッと4ステップにまとめました

保護解除プログラム

実際に使うプログラムはこちらなので、新規ファイルの標準モジュールにコピペでどうぞ↓↓

Option Explicit
   
Private Const PAGE_EXECUTE_READWRITE = &H40
   
Private Declare PtrSafe Sub MoveMemory Lib "kernel32" Alias "RtlMoveMemory" (Destination As LongPtr, Source As LongPtr, ByVal Length As LongPtr)
Private Declare PtrSafe Function VirtualProtect Lib "kernel32" (lpAddress As LongPtr, ByVal dwSize As LongPtr, ByVal flNewProtect As LongPtr, lpflOldProtect As LongPtr) As LongPtr
Private Declare PtrSafe Function GetModuleHandleA Lib "kernel32" (ByVal lpModuleName As String) As LongPtr
Private Declare PtrSafe Function GetProcAddress Lib "kernel32" (ByVal hModule As LongPtr, ByVal lpProcName As String) As LongPtr
Private Declare PtrSafe Function DialogBoxParam Lib "user32" Alias "DialogBoxParamA" (ByVal hInstance As LongPtr, ByVal pTemplateName As LongPtr, ByVal hWndParent As LongPtr, ByVal lpDialogFunc As LongPtr, ByVal dwInitParam As LongPtr) As Integer
 
Dim HookBytes(0 To 5) As Byte
Dim OriginBytes(0 To 5) As Byte
Dim pFunc As LongPtr
Dim Flag As Boolean
   
Private Function GetPtr(ByVal Value As LongPtr) As LongPtr
  GetPtr = Value
End Function
   
Private Sub RecoverBytes()
  If Flag Then MoveMemory ByVal pFunc, ByVal VarPtr(OriginBytes(0)), 6
End Sub
   
Public Function Hook() As Boolean
  Dim TmpBytes(0 To 5) As Byte
  Dim p As LongPtr
  Dim OriginProtect As LongPtr
   
  Hook = False
  pFunc = GetProcAddress(GetModuleHandleA("user32.dll"), "DialogBoxParamA")
  If VirtualProtect(ByVal pFunc, 6, PAGE_EXECUTE_READWRITE, OriginProtect) <> 0 Then
    MoveMemory ByVal VarPtr(TmpBytes(0)), ByVal pFunc, 6
    If TmpBytes(0) <> &H68 Then
      MoveMemory ByVal VarPtr(OriginBytes(0)), ByVal pFunc, 6
      p = GetPtr(AddressOf MyDialogBoxParam)
      HookBytes(0) = &H68
      MoveMemory ByVal VarPtr(HookBytes(1)), ByVal VarPtr(p), 4
      HookBytes(5) = &HC3
      MoveMemory ByVal pFunc, ByVal VarPtr(HookBytes(0)), 6
      Flag = True
      Hook = True
    End If
  End If
End Function
   
Private Function MyDialogBoxParam(ByVal hInstance As LongPtr, ByVal pTemplateName As LongPtr, ByVal hWndParent As LongPtr, ByVal lpDialogFunc As LongPtr, ByVal dwInitParam As LongPtr) As Integer
  If pTemplateName = 4070 Then
    MyDialogBoxParam = 1
  Else
    RecoverBytes
    MyDialogBoxParam = DialogBoxParam(hInstance, pTemplateName, hWndParent, lpDialogFunc, dwInitParam)
    Hook
  End If
End Function
   
Public Sub VBAProjectパスワード解除()
  If Hook Then
    MsgBox "VBAProjectのパスワード解除成功！", vbInformation, "Congratulations"
  End If
End Sub

このコードがやっているのは、Windowsがダイアログを出すときに呼び出すDialogBoxParamAという関数の動きを横取りすることです

VBAのパスワード入力ダイアログが出ようとした瞬間に「もう正解が返ってきたことにする」よう差し替えるイメージで、専門的にはAPIフックと呼ばれる手法ですね

差し替えのためにVirtualProtectやMoveMemoryといったメモリ操作の関数を使っていて、ここがエラーになりやすいので軽くだけ補足しておきます

掲載しているのは64bit版Excelに対応したPtrSafe版です、各宣言にPtrSafeが付いていて型がLongPtrになっているのがその印で、今どきのExcel(Microsoft 365含む)なら基本このまま動きます

もし古い32bit環境でコンパイルエラーが出る場合は、宣言の書き方を32bit向けに直す必要があります、このあたりはFAQでも触れるので、エラーで止まった方はそちらも見てみてください

操作動画

手順を動画化しただけですが、文字だけだと伝わりにくい時の参考にどうぞ

注意点

便利な手順ですが、いくつか性質を知っておかないと「あれ？元に戻ってる？」と戸惑うことになります

大事なのは、この手順を使ってもパスワードそのものが消えるわけではないという点です

あくまでメモリ上で一時的にダイアログを回避しているだけなので、上書き保存をしてもファイルを閉じて開き直すと、また同じパスワードが効いた状態に戻ります

そういう意味では「パスワードを解除する」というよりこっそり中身を覗くと言ったほうがしっくりくるかもしれないですね

もう一点、メモリを直接書き換える手法なので、環境によっては実行時にExcelが落ちることもあります

大事なファイルでいきなり試すのは怖いので、事前にコピーをとってから作業するのが安心です

ちなみに今回のAPIフック以外にも、古い.xls形式向けにバイナリエディタでvbaProject.binの中の「DPB」というキーを書き換える方法も知られています

こちらは仕組みとしては今でも紹介されていますが、書き換えをミスるとファイルが壊れる可能性があるので、扱いに慣れていないうちは今回のプログラム実行のほうが手軽だと思います、似た発想の「保護を後から外す」話として、PythonのExe化を逆コンパイルで覗く記事も書いているので興味があればどうぞ

PyInstallerでExe化したPythonを逆コンパイルする方法

使うときのマナー

仕組みを知ると応用したくなるところですが、使いどころは落ち着いて見極めたいですね

この手順が役に立つのは、自分で作ったマクロのパスワードを忘れてしまったような、自分のファイルを救済する場面です

一方で、他人が作ったファイルや業務で配布されたファイルにはパスワードをかけた人の意図があります、中を見たいときは作成者や権利者に許可をとるのが筋だと思います

このあたりは時点や状況によって考え方も変わりうるところなので、断定はしませんが、少なくとも無断で他人のロックを外して回るような使い方は避けておくのが無難です

よくある質問

つまずきやすいポイントをQ&A形式でまとめておきます

あとがき

VBAパスワードの解除方法は調べるといくつか出てきますが、今回のプログラム実行が一番手軽な気がします

仕組みとしてはパスワード入力の判定をすり抜けているだけなので、過信せず自分のファイルの救済に役立ててもらえたら嬉しいです

VBAの独学に効く本PR

Excel VBA塾【動画×本で学ぶ!】

たてばやし淳

Amazonで見る楽天で見る

パーフェクトExcel VBA

高橋宣成

Amazonで見る楽天で見る

Excel マクロ&VBA［実践ビジネス入門講座］完全版 第3版

国本温子

Amazonで見る楽天で見る

私のおすすめからランダムで3冊を表示しています