Claude Codeのセキュリティは大丈夫？企業導入の不安と、事故を防ぐ設計【2026年最新】

「Claude Code、セキュリティは大丈夫？」——先に結論を言うと、この不安は「禁止」ではなく「設計」で解けます。何を渡してよいか、どこまで任せるか、どの経路を塞ぐかを先に決めれば、安心して現場に配れます。

「入力した情報が学習されるのでは」「社員の誰かが、機密を貼ってしまうのでは」。導入を検討する会社で、この心配は必ず出ます。

実際、私たちが商談やセミナーで接する企業でも、最多の懸念はセキュリティです。金融系の企業からも、全社導入にあたって一番のネックはセキュリティだという声をいただきました。

私たちDAIJOBUは、脆弱性診断を専門にし、かつ自社で毎日Claude Codeを使い倒している会社です。その目で見ると、よくある答え「企業向け契約なら学習されないから安心」は、一番浅い層しか見ていません。

本当に事故が起きるのは、もっと別の経路です。そしてその経路は、「機密を入力しない」というよくある注意だけでは塞げません。

実際、私たち自身のヒヤリでは、人の目には見えない"透明な指示"が仕込まれていたことがあります。気づいた社員は、ひとりもいません。それでも事故にならなかったのはなぜか——実話は記事の後半でお話しします。

この記事では、教科書的な安心材料ではなく、使い込んだ会社にしか見えない「本当の穴」と、その塞ぎ方をお渡しします。

本当の穴は契約の外側にあります。だから「禁止」ではなく「設計」で塞ぐ——この記事はその設計を書きます。

この記事の要点は3つ

1. 「学習されるのでは」という不安は、契約の3点確認（学習利用・保存期間・利用状況の可視化）でほぼ片付く
2. 本当のリスクは契約の外側にある3つ——読ませた中身に指示が仕込まれる（プロンプトインジェクション）／秘密情報が文脈に載る／権限を渡しすぎる
3. 塞ぎ方は禁止ではなく設計。①端末（Sandbox）②コード設定（CLAUDE.md・Permissions・Hooks）③運用ルール ④人の4層で重ねる

この記事でわかること

• 多くの人が心配する「学習される」不安の正しい片付け方（ここは実は簡単）
• 脆弱性診断のプロが見る、AIエージェント特有の「本当の穴」3つ
• 国際的な枠組み（NIST AI RMF／OWASP）で押さえる、「何を管理すべきか」の全体像
• DAIJOBUが毎日回している安全装備の実物（4層構造＝端末・コード設定・運用ルール・人）
• 事故が起きる「瞬間」の具体例と、その備え
• 導入前にベンダーへ確認すべき質問（そのまま使えるリスト）

目次

1. 「学習される」不安は、3点の契約確認で片付く
2. 脆弱性診断のプロが見る、Claude Codeの「本当の穴」3つ
3. その使い方、大丈夫ですか？自社への「3つの質問」
4. 稟議で必ず聞かれる「世の中の標準は？」に3分で答える｜NIST・OWASP
5. DAIJOBUの安全装備の実物｜守りは「4つの層」でできている
6. 事故が起きる「4つの瞬間」と、実際にあったヒヤリ
7. 「禁止」が一番危ないという逆説｜シャドーAIが生まれる仕組み
8. なぜDAIJOBUが、ここまで具体的に語れるのか
9. 導入前にやること5つ｜小さく始めて、線引きを先に置く
10. よくある質問（FAQ）
11. まとめ

「学習される」不安は、3点の契約確認で片付く

まずは、いちばん多い心配から片付けましょう。「社内の機密を入れたら、外部に残って、よその会社への回答に使われてしまうのでは」——この不安です。

ここで言う「学習」とは、入力した内容をAIが覚えて、別の人への回答に反映してしまうこと。たしかに、そう聞くと不安になりますよね。

ただ、結論から言うと——ここは契約の確認だけで、ほぼ片付きます。

この3点の外側に、AIエージェント特有の穴が残ります。

拍子抜けされるかもしれませんが、カギは契約の種類です。ふだん個人で使うチャットサービスと、会社として結ぶ企業向けの契約とでは、入力したデータの扱いがそもそも違います。企業向けなら「入力を学習に使わない」「一定期間で削除する」といった条件が、はじめから用意されているのが一般的です。

とはいえ、条件はプランや設定によって変わります。「うちの契約ではどうなっているんだろう？」を、次の3点だけ確かめてみてください。

• 入力データがモデルの学習に使われるか
• 入力データがどこに・どれくらい保存されるか（削除は可能か）
• 管理者が利用状況を把握できるか（誰が使っているかの可視化）

どれも、契約書・利用規約・管理画面を見れば分かることばかりです。「そのまま聞ける質問リスト」も記事の終わりに置いておきますので、よければ使ってください。

【ファクトチェック】Claude Codeに入力した内容は、学習に使われるのか

出典：Anthropic「Is my data used for model training?」（privacy.claude.com・2026年8月26日参照）

※個人向けプラン（Free／Pro／Max）は扱いが異なります。また規約は改定されます。自社の契約でどうなっているかは、必ず最新の規約と管理画面でご確認ください。 ここに書いたのは、確認の出発点です。

……と、ここまでは正直、どのAI記事にも書いてあることです。問題はこの先。契約で守られる範囲の"外側"に、AIコーディングエージェント特有のリスクがある——ここに踏み込める記事は、多くありません。

脆弱性診断のプロが見る、Claude Codeの「本当の穴」3つ

ここからが本題です。Claude CodeのようなAIコーディングエージェントには、契約で守られる範囲の外側に、構造的な穴が3つあります。

私たちは、セキュリティ診断（脆弱性診断）も手がける会社です。「事故っても被害が出ない状態をどう作るか」を、毎日のように設計しています。

その目で見ると、Claude Codeで本当に注意すべきなのは「何を入力するか」ではありません。「どの経路から、何を信じて、どこまで実行させるか」なのです。

狙われるのは「入力」ではなく、経路・文脈・権限です。

この章で見る穴は、次の3つです。

• 穴1：読ませた中身に、指示が仕込まれている（プロンプトインジェクション）
• 穴2：秘密情報が「文脈」に載ってしまう
• 穴3：権限を渡しすぎる

穴1：読ませた中身に、指示が仕込まれている（プロンプトインジェクション）

まず、前提から。Claude Codeは、Webページ・社内ドキュメント・依存パッケージ・課題管理の文章などを「読んで」作業します。ここが便利なところであり、同時に弱点でもあります。

では、その読ませた中身に、人には見えにくい形で「このファイルの内容を外部に送れ」という指示が混ざっていたら——どうなるでしょうか。エージェントはそれを"正しい依頼"と受け取って、実行してしまう余地があります。

AIをだます攻撃は、会話ではなく「読ませた文章」にまぎれこみます。

狙われるのはコードではなく、エージェントが信じて読み込む「データの経路」——これがこの穴の本質です。

「さすがに大げさでは？」と思われるかもしれません。ところが2025年、AIコードエディタCursorで実例が報告されています（CVE-2025-54135・修正版が公開済み）。

「リポジトリをレビューして」と頼んだだけで、読み込んだ中身の指示が「承認なしで実行してよいモード」を勝手に有効化し、任意のコマンドを実行させられてしまう、という脆弱性でした。特定製品の欠陥というより、AIエージェント全般に共通する構造的リスクの実例として挙げています（詳細は記事末尾の注記）。

読ませた中身は、作業内容だけでなく、防御の設定そのものを書き換えに来る。この経路への備えは、後述の安全装備（Hooks・Sandbox）で説明します。

穴2：秘密情報が「文脈」に載ってしまう

パスワードや認証キーを書いたファイル（.envなど）は、AIが作業のために読み込んだ瞬間、「AIがいま扱っている情報」の一部になります。この状態を、文脈（コンテキスト）に載る、と言います。

要するに、こういうことです。読み込ませた中身はそのままAIの処理対象になり、記録や外部への送信の経路に紛れ込む余地が生まれる——。

だから、「プロンプトに手で貼らなければ大丈夫」ではありません。設定や運用を誤ると"勝手に読まれて載る"。この経路を塞ぐ設計が要ります。

穴3：権限を渡しすぎる

「確認なしで何でも実行してよい」に設定すると、作業はぐっと速くなります。正直に言えば、これはとても快適です。

ただ、この設定が穴1・穴2と組み合わさると、ファイルの削除・上書き・外部送信まで自動で通ってしまいます。速さと引き換えに、事故の「一撃」が大きくなるのです。

この3つに共通するのは、「AIが賢いか」の話ではなく、設計の話だということ。だからこそ、禁止ではなく設計で解けます。

では、何をどう設計すればいいのか。その前に少しだけ、自社の現在地を確かめてみませんか。30秒で終わります。

その使い方、大丈夫ですか？自社への「3つの質問」

Claude Codeをいま導入済みの方も、検討中の方も。次の3つ、答えられますか？

1. 顧客リストや売上——データベースの中身を、"そのまま"AIに貼っていませんか？ 自分は貼っていなくても、社員の誰かが、今日やっているかもしれません。
2. 「何を渡してよくて、何がダメか」。全社員が即答できますか？ 線引きの1枚がないなら、その判断は毎回、各自の"感覚"に任されています。
3. 誰が・どのAIに・何を入れているか、会社として把握できていますか？ 把握できない利用は、実は「禁止した会社」ほど増えます（この逆説は後述します）。

3つとも「はい」と言い切れる会社は、ほとんどありません。答えに詰まったとしても、それが普通です。

大事なのは、個人の注意力を責めることではありません。全員が即答できる状態を「設計」で作ることです。本記事の後半で、私たちが毎日回している設計をそのまま出します。

とはいえ、その前にひとつ。社内で導入を通そうとすると、必ずと言っていいほど聞かれる質問があります。「で、世の中の標準ではどうなってるの？」——ここを先に片付けておきましょう。

稟議で必ず聞かれる「世の中の標準は？」に3分で答える｜NIST・OWASP

自社だけの独自ルールで走り出す前に、世の中の標準的な整理を押さえておく。地味に見えて、これが社内説明（稟議）を一気に楽にしてくれます。

世界でいちばん広く参照されているのが、米国NISTのAI RMF（AI Risk Management Framework 1.0）という枠組みです。難しそうな名前ですが、中身はシンプルで、AIのリスクを次の4つで回しましょう、という話です。

もう一つ、生成AI特有の脅威を実務目線で整理したものが、OWASPの「GenAI LLM Top 10」（2026年版）です。本記事で挙げる「穴1（プロンプトインジェクション）」は、そこで最上位の脅威として扱われています。

……とはいえ、お気づきかもしれません。ここまでは「何を管理すべきか」という枠組みの話です。現場で本当に知りたいのは、その次ではないでしょうか。「で、明日から何を設定すればいいの？」——ここです。

ここから先が、私たちが毎日回していて、研修でそのままお渡ししている「実物」です。

DAIJOBUの安全装備の実物｜守りは「4つの層」でできている

Claude Codeを安全に使うために、分厚いルールを1枚配っても、残念ながら現場は読んでくれません。本当に効くのは、人の注意力に頼らないことです。

ここから挙げるのは機能の一覧ではなく、私たちが自社で毎日その中で仕事をしている、そのまま設定できる実物です。守る場所を4つの層に分け、下の層ほど仕組みで固定する——これが全体の設計です。

守りは4つの層に分かれていて、どの層が抜けたかで事故の形が決まります。

この章では、次の順にお話しします。

• 事故の大きさを決める「4つの因子」の掛け算（ものさし）
• 4つの層の全体像——①②は仕組みで固定、③④は運用で回す
• ①端末・②コード設定：忘れても効き続ける2層の実物
• ③運用ルール・④人：回し続けて効かせる2層の決めごと
• 4層のどこが抜けると、どの事故になるか（対応表）

事故の大きさは「4つの因子」の掛け算で決まる

層の設計に入る前に、私たちが研修でも使っている"ものさし"をひとつ、ご紹介させてください。事故の大きさは、「扱う情報」×「持つ権限」×「自動化の範囲」×「外部との接続」の掛け算で決まります。

少しイメージしにくいので、日常のものにたとえてみます。扱う情報は、金庫の中身の重さ（顧客名簿なのか、ただのメモ書きなのか）。権限は、合鍵を何本渡すか（読むだけか、消せる・送れるか）。

自動化は、運転をどこまで任せるか（一手ずつ確認するか、丸ごと任せるか）。外部接続は、知らない人と話す量（閉じた環境か、ネットに繋がっているか）です。

そして、ここが希望のあるところなのですが——足し算ではなく、掛け算です。つまり、どれか1つを小さくするだけで、事故全体が小さくなります。

足し算ではなく掛け算です。どれか1つを小さくすれば、事故全体が小さくなります。

重い情報を扱う作業では合鍵を減らす。丸ごと任せたい作業では、扱う情報を軽くする。これから挙げる安全装備は、この4つの因子をそれぞれ小さくする仕掛けです。

守りは、4つの層に分かれている

ここが、この記事でいちばんお伝えしたい部分です。

安全装備の話は、たいてい「Permissionsがあって、Hooksがあって、Sandboxがあって……」という機能の一覧になりがちです。でも、それを聞かされても「で、うちは何が足りていないの？」は分からないままではないでしょうか。

私たちは、守る場所を4つの層で捉えています。

1. 端末——そもそも、どこで動かすか
2. コード設定——人の注意力に頼らず、設定で止める
3. 運用ルール——設定では書ききれない判断を、決めごとにする
4. 人——最後の判断と検収を、誰が持つか

この分け方には、実務上の意味があります。①と②は、いちど設定すれば人が忘れても効き続けます。③と④は、回し続けないと効きません。

つまり、できるだけ下の層に寄せるほど、運用は楽になり、事故は減ります。「ツールを入れたから安全」でも「気をつけているから安全」でもなく、4層のどこが抜けているかで、起きる事故の形が決まるのです。

この捉え方は、商談でも効いています。「承認ばかり押して、結局事故になるのでは。最後は人だから、エンジニア向けの道具では」——素材メーカーの情報企画担当の方の言葉です。

事故の大半は下の層の構造で止め、残りを人がカバーする。この設計を説明すると、見方が変わりました。人の注意力を最後の砦にしないのが、4層の思想です。

①端末（Sandbox）｜そもそも、動ける範囲を箱で囲う

いちばん下の層でやるのは、シンプルです。AIが手を伸ばせる範囲そのものを、物理的に狭めてしまいます。

Sandbox（サンドボックス）で、AIが動ける範囲を箱の中に限定します。仮に読ませた中身に悪意ある指示を仕込まれても、箱の外には出られない。人の注意力ではなく、環境そのものに"最後の砦"を持たせる考え方です。

あわせて、.envなど"読ませたくないもの"は、そもそも読ませない設定にします。

この層が効いていると、上の層で何かをすり抜けられても、被害の範囲が箱の中で止まります。逆にここが抜けていると、たった1回の判断ミスが、そのまま本番や顧客データに届いてしまいます。

②コード設定｜人の注意力に頼らず、設定で止める

判断の基準も禁止事項も、設定ファイルに書いて配ります。人が忘れても効き続ける形にしておくためです。

CLAUDE.md｜判断の基準を、AIが必ず読む場所に書く

人が覚えておくルールは、いつか必ず忘れられます。悪気があるわけではなく、忙しいからです。だからルールは、AIが必ず読む設定ファイル（CLAUDE.md）に書いて配ってしまいます。書くのは、たとえば次の4つです。

• 外部送信を設定側でも止める：AIは下書きまで。勝手に送れない形にする
• 情報の線引き：渡してよい（公開情報・社内共有済みの資料）／加工すれば渡せる（顧客名・取引先＝マスクすれば使える）／渡さない（個人情報そのもの・認証情報・持ち出しが契約で禁じられているもの）
• 顧客DB・個人情報の"生データ"は、そのまま渡さない（必要な部分だけマスク・抽出してから使う。「DBの中身を丸ごと貼る」が一番危ない）
• .env・鍵・トークン・顧客情報はGitに上げない（.gitignoreで除外。漏れたときは「鍵を作り直す」に従う）

この線引きが1枚あるだけで、現場は「これは入れていいんだ」と判断でき、安全側に倒れつつ使えます。

Permissions｜権限を3段階に仕分ける

「全部AIに任せる」でも「全部人が見る」でもなく、操作を3つに仕分けます。

• allow（そのままやってよい）：読み取り・検索
• ask（必ず人に聞く）：外部への送信・削除・コミット・プッシュ（権限変更・本番の変更・決済・公開も、ここに入れます）
• deny（そもそもやらせない）：破壊的な操作・本番データベースの削除・機密の公開

人数の多い組織に配るときは、さらに一段絞ります。研修では、外部ツール接続の権限を読み取り専用から始め、設定ファイルを先に配るやり方を案内しています。

Hooks｜危ない操作は、実行される前に自動で止める

どんなに丁寧に決めたルールも、人はうっかり破ってしまうことがあります。ですから、設定側でも塞いでおきます。

• 危険なコマンドの阻止：削除・上書きなどを、実行する前に止める
• Secret Scan（機密の自動検閲）：顧客名・金額・鍵などを、記録に残る前に自動でブロックする
• 安全装置そのものを守りの対象にする：Hooks自体もコードとしてレビューし、防御の設定を現場の判断で勝手に緩められない形にする

最後の項目が、この層のいちばん大事なところです。守りの設定そのものを、現場の判断で緩められる状態にしない。穴1で挙げた「承認なし実行モードを勝手に有効化された」実例は、まさにここを突かれています。

③運用ルール｜設定では書ききれない判断を、決めごとにする

設定で表現できるのは「やってよい／だめ」までです。「この場面ではどう判断するか」は、決めごととして持つしかありません。

• 聞かれたら、中身を見てからOKを出す：「このコマンドを実行していいですか？」に反射で「はい」を押さない。迷ったら手を止める
• 大きな変更は、計画を先に出させる：「プランモード」で計画を確認してから進める。一度に大きく変えない
• 外部送信は許可制：AIがやるのは下書きまで。人が確認して、はじめて送信する
• ぜんぶgit管理：誰が何を変えたかを追えて、いつでも元に戻せる。「起きても戻せる」状態を先に作る
• 秘密が漏れたら、鍵を作り直す：一度上げてしまった秘密は履歴に残る。消して終わりにしない

この層は、設定と違って「回し続けないと効かない」のが特徴です。だからこそ③に置く項目はできるだけ少なくし、設定で固定できるものは②に降ろす——これが運用を軽くするコツです。

④人｜最後の判断と検収を、誰が持つか

いちばん上の層は、人です。そしてここだけは、仕組みに置き換えられません。

判断と検収は、人に残します。私たちが「AIが全部やります」と言わないのは、この層があるからです。AIは下書きと実行を担う。それでよいと決めるのは、人。

この線を曖昧にしたまま自動化を広げると、①〜③をどれだけ固めても、責任の所在が消えます。

もう一つ、危ない瞬間を知っている人がいるかどうかが、この層の厚みを決めます。次章で挙げる「事故が起きる瞬間」は、まさにこの層に効かせるための知識です。

4層のどこが抜けると、どの事故になるか

4層で捉える利点は、自社に足りていないものが特定できることです。

冒頭の穴1（プロンプトインジェクション）に、この4層を当ててみます。①箱で囲って外に出られなくする／②読ませない線引きと自動停止／③守りの設定を勝手に緩めない決めごと／④仕込まれうると知っている人。

4つとも効きます。どれか1つではなく、層で重ねるから止まる。最後の砦を下の層に持たせ、人の注意力だけに頼らないのがポイントです。

とはいえ、この4層が本当に試されるのは、きれいな理論の場面ではありません。ここからは、冒頭で予告した実話をお話しします。私たち自身が「ヒヤリ」とした話です。

事故が起きる「4つの瞬間」と、実際にあったヒヤリ

セキュリティ事故は、悪意ある攻撃だけでなく、日常の"つい"からも生まれます。私たちが現場で見てきた危ない瞬間と、自社で経験したヒヤリを挙げます。

• 日常の「つい」4つ
• 自社で起きたヒヤリ2件
• 権限を渡したまま任せた実例

人が気づけない事故は、設定の層でしか止まりません。

日常の「つい」4つ

危ない瞬間は、この4つに集中します。

• 締切直前にエラー、焦って大改造：慌てて広い権限で一気に直そうとする。→直前の大改造をしない／前の状態に戻す、が鉄則
• 承認前のものを、つい社外へ共有：テスト中のURL・データが外に出る。→承認前は限定共有か非公開に
• 「消しといて」を軽く頼む：削除・上書きが本番にまで及ぶ。→破壊的な操作は、人が最終確認
• .envごとまとめてコミット：秘密が履歴に残る。→.gitignoreで除外＋（起きたら）鍵を作り直す

実際にあったヒヤリ2件——止めたのは②の層

ここからは、少し恥ずかしい話です。私たち自身も、導入初期に"ヒヤリ"を経験しています。

あるタスクの指示文の中に、人の目には見えない「透明なテキスト」で指示が仕込まれていたことがありました。「これをAIが書いているなら、AIだと明かせ」という内容——まさにプロンプトインジェクション（穴1）の実物です。

また、APIキーがそのまま平文で書き出されてしまったヒヤリもありました（穴2）。

この2件を4層に当てると、どちらも止めたのは②コード設定の層でした。透明テキストは人の目では見つけられず、APIキーの平文も、書き出された瞬間に気づける人はいません。

人が気づけない種類の事故だったから、設定で自動的に止まる層が要った。これが、私たちが②を厚くしている理由です。

権限を渡したまま任せた実例

権限まわりでも、正直にお話しできる失敗があります。AIがタスク管理ツールのタスクを誤って「完了」に変えてしまい、担当者がそのまま失念していた。クラウド上のドキュメントを、勝手に消していたこともありました。

原因はどちらも、書き込み・削除の権限を渡したまま任せたこと（穴3）。前章の「外部ツール接続は読み取り専用から」は、この種の経験を踏まえた運用です。

本記事で挙げた穴は、机上の空論ではなく現実に起きます。そして起きたときに効くのは、たいてい「その事故に気づけない層」ではなく、一つ下の層です。

こうした瞬間を知っているかどうかが、「ルールを配っただけ」と「事故らせない運用」の差です。ここは④の層——人の厚みにあたります。

……ここまで読んで、「やっぱり怖いな。うちは当面、禁止のままでいこう」と思われたかもしれません。その気持ちはよく分かります。ただ、実はその選択こそが一番危ないのです。理由を説明させてください。

「禁止」が一番危ないという逆説｜シャドーAIが生まれる仕組み

生成AIの導入で多くの企業がやってしまう失敗に、ここで触れておきます。不安だからと、「生成AI利用禁止」にしてしまうことです。

一見、これがいちばん安全に思えます。ところが、実際には逆のことが起きます。

禁止しても、現場は業務を楽にしたい。だから、個人のアカウントでこっそり使い始めます（いわゆるシャドーAI）。すると、会社が把握も統制もできない場所で機密が入力されることになる。禁止したことで、かえって一番危ない状態が生まれるのです。

禁止しても需要は消えません。隠れて使われるほうが、ずっと危ないからです。

そもそも、使いたい需要は禁止では消えません。セキュリティ最優先の医療機関からも「事務作業は絶対に自動化したい」という声を聞きます。

だから、「禁止」ではなく「安全に使える道を用意する」ほうが、結果的にセキュリティは高まります。正しく使える環境と線引きを会社が示せば、現場はわざわざ危ない抜け道を使いません。

4層で見ると、禁止は①端末・②コード設定・③運用ルールをすべて空にしたまま、④人にだけ「使わない」と約束させている状態です。人の意志だけで支える守りは、締切の前で折れます。

禁止を解除するときの順番は「生成AI禁止」が一番危ないのはなぜかに、線引きを文書と設定にどう振り分けるかは生成AI社内ガイドラインの作り方にまとめました。

「そうは言っても、なぜそこまで言い切れるの？」——もっともな疑問だと思います。種明かしをさせてください。

なぜDAIJOBUが、ここまで具体的に語れるのか

セキュリティの一般論なら、正直、誰にでも書けます。それでも私たちがここまでの解像度で踏み込めるのには、2つ理由があります。

• 理由1：自社が毎日この設計の中で使っているから
• 理由2：セキュリティ診断が本業だから

理由1：自社が毎日この設計の中で使っているから

DAIJOBUでは、エンジニアだけでなく営業・採用・バックオフィスを含む20名以上が日常業務でClaude Codeを使い、業務別のカスタムエージェントを約30種実装しています。

上で挙げた線引き・運用ルール・技術装置は、机上の理想ではなく、実際に回している運用そのものです。研修では、この実物を（社外秘をマスクした上で）そのままお渡しします。

私たちのLPでは、運用中のCLAUDE.mdや.claude/設定の一部をマスクして公開しています。

たとえば営業・事務では、「メールを読み取って返信の下書きまでをAIが作り、送信は必ず人が行う」といった業務別エージェントを用意しています。AIは下書きまで、送信・実行の最終判断は人に残す——これが、安全に自動化する型です。

研修で教えるのも、外部講師ではありません。会社そのものをAIエージェントで経営している実務者が、講師に立ちます。

「1週間分の資料作成が1日に」「4週間分の事務作業が1日に」。そうした変化を自分の業務で先に体験した人間が、そのやり方を移植します。

大事なのは、この生産性を本記事の安全設計の"内側"で出しているということです。速さのために安全を緩めたのではなく、安全設計が先にあるから、安心して速くできる——この順番です。

使い倒していること、そしてセキュリティが専門であること。だから「安全に配れる状態」から作れます。

理由2：セキュリティ診断が本業だから

DAIJOBUは、セキュリティ診断（脆弱性診断）も手がける会社です。

「事故っても被害が出ない状態をどう作るか」を日常的に設計しているため、権限の線引きや機密の扱いを、実装レベルで一緒に固められます。

この強みは、受注の現場でも効いています。AIの制限やセキュリティの不安から、「どう使っていいか分からず、進められない」大手企業は少なくありません。

そうした会社が「セキュリティのわかる会社によるAI研修」という点に着目し、非常に速く導入を意思決定した例があります。不安が解けると、決断は速いのです。

この「使い倒している×セキュリティが専門」の掛け算だからこそ、言えることがあります。AI導入で本当に難しいのは、AIを賢く使うことではなく、「安全に配れる状態」を先に作ることです。

私たちの研修は、まさにそこを一緒に作ります。第1回を終えた時点で、受講者の80%以上が自分のPCでClaude Codeを起動できるところまで持っていきます。

最後に、ひとつ正直に書いておきます。この記事で公開したのは、私たちの安全設計の「考え方」までです。

実際にどんな検査パターンを・どこに仕込み・どの操作を止めているか——その具体構成は、公開していません。攻撃側へのヒントになるからであり、受講企業にそのままお渡しする"実物"だからです。

中身は言えませんが、結論だけは言えます。社名の通り、ここは「大丈夫」にしてあります。

さて、ここまでお読みいただいた方が気になるのは、「で、うちは明日から何をすれば？」だと思います。やることを5つだけに絞って、お渡しします。

導入前にやること5つ｜小さく始めて、線引きを先に置く

セキュリティを理由に止まっている場合、進め方はシンプルです。

完璧なガイドラインを待たず、線引きを先に置いて小さく始めます。

この章でお渡しするのは、次の2つです。

• 導入前に進める5つのステップ
• そのまま使える、ベンダーへの確認質問リスト

1. 企業向けの契約・設定を確認する（学習利用・保存期間・可視化の3点。次のリストを使う）
2. 情報の線引きを1枚作る（渡してよい／加工すれば渡せる／渡さない）
3. 権限を3段階に仕分ける（読み取りはallow／送信・削除・コミットはask／破壊操作はdeny）
4. 自動で止める仕組みを1つ入れる（機密ファイルを読ませない設定から始めるのが早い）
5. 小さく試す（1部署・数名から始めて、運用しながらルールを調整する）

よくあるのが、いきなり全社の完璧なガイドラインを作ろうとして、いつまでも始まらないパターンです。それよりも、薄いルールで小さく始めて、走りながら整えるほうが、ずっと現実的だと思います。

この線引きや安全設計を研修の中で一緒に作る場合の費用感は、Claude Code研修の費用相場｜料金の決まり方・助成金・費用対効果までで解説しています。

ベンダーへの確認質問リスト（そのまま使えます）

よくある質問（FAQ）

商談やセミナーで特によく聞かれる7つに、結論からお答えします。

• 入力した情報は、他社の回答に使われるか
• 外部のWebやファイルを読ませて大丈夫か
• プロンプトインジェクションは防げるか
• AIが勝手にファイルを消さないか
• 顧客DBをそのまま読ませてよいか
• まず何から決めればよいか
• セキュリティ設計まで研修で一緒にやれるか

Q. 入力した社内情報が、他社の回答に使われることはありますか？

A. 企業向けの契約では、入力データを学習に使わない条件が用意されているのが一般的です。

ただし契約プランと設定で変わるため、自社の契約でどうなっているかを必ず確認してください。確認方法は、本文の「確認質問リスト」をお使いください。

Q. AIに、外部のWebやファイルを読ませても大丈夫ですか？

A. 読ませた中身に不正な指示が仕込まれている可能性（プロンプトインジェクション）があります。

"信頼できないデータ"を読ませるときは、権限を絞る・確認を挟む設計にします。サンドボックスや機密ファイル保護と組み合わせれば、被害が出ない形で使えます。

Q. プロンプトインジェクションは、防げますか？

A. ここは正直にお伝えします。「注入を100%防ぐ」確実な方法は、現時点では存在しないとされています（OWASPも最大級の脅威として挙げています）。

AIは「命令」と「読まされた文章」を同じ経路で受け取るため、入口で完全に見分けるのが難しいからです。

だから私たちは、発想を変えて「注入されても事故にならない」設計にします。権限を絞る／危険な操作は人が確認／サンドボックスで囲う／機密をそもそも読ませない。

本文の「事故の大きさ＝情報×権限×自動化×外部接続」の掛け算のうち、注入以外の因子を小さくしておく。これが「あらかじめの設計」が効く理由です。

Q. AIが勝手にファイルを消したりしませんか？

A. 影響の大きい操作（書き換え・削除・外部送信など）には、人の確認を挟む設計にできます。

読み取りや下書き作成は自由に、重要な操作だけ承認を挟む、という線引きが基本です。

Q. 顧客データベースの中身を、そのままAIに読ませてもいいですか？

A. 生データをそのまま渡さないのが基本です。個人情報や取引条件を含むデータは「渡さない」に分類し、必要な部分だけをマスク・抽出してから使います。

「DBの中身を丸ごと貼る」は、社員の誰かが善意でやってしまいがちな、いちばん危ない使い方です。

Q. まず何から決めればいいですか？

A. 情報の線引き（渡してよい／加工すれば渡せる／渡さない）を1枚作ることからです。これがあるだけで、現場が安全に判断できるようになります。

Q. セキュリティの設計まで、研修で一緒にやってもらえますか？

A. はい。DAIJOBUの研修では、機密の扱い・権限・確認のお作法・技術的な安全装置を、自社の実運用をベースに一緒に固めます。詳しくは初回無料体験講座でご相談ください。

まとめ

長い記事にお付き合いいただき、ありがとうございました。最後に、要点だけ振り返ります。

• 「入力が学習される」不安は、企業向け契約の3点確認（学習利用・保存期間・可視化）で多くが片付く
• 本当に注意すべきは、AIエージェント特有の3つの穴——読ませた中身の指示（インジェクション）／秘密情報が文脈に載る／権限の渡しすぎ
• 国際的な枠組み（NIST AI RMF・OWASP）が示すのは「何を管理するか」まで。現場で効くのは、その次の「明日、何を設定するか」
• 事故を防ぐのは4つの層——①端末（Sandboxで箱に囲う）②コード設定（CLAUDE.mdの線引き・権限3段階・Hooksの自動停止）③運用ルール（反射でOKしない・計画を先に・gitで戻せる）④人（最後の判断と検収）
• ①②は仕組みで固定でき、③④は回し続けないと効かない。だから、できるだけ下の層に寄せる
• 「禁止」が一番危ない（シャドーAIを生む）。安全に使える道を用意するほうが、セキュリティは高まる
• 試金石は、「何を渡してよいか」を全社員が即答できるか。できないなら、線引きの1枚から始める
• 完璧なガイドラインを待たず、小さく始めて走りながら整える

あらためて。DAIJOBUは、Claude Codeを全社で毎日使い倒している会社であり、かつセキュリティ診断（脆弱性診断）も手がける会社です。

「事故っても被害が出ない状態」を実際に設計・運用しているやり方を、そのままお渡しします。「禁止」で止まっている状態から、「安全に、翌週から使える」状態へ進めるお手伝いをします。

初回無料体験講座（30分・オンライン・最大5名）。自社のセキュリティ懸念に合わせて、安全装備の一部を実際にお見せしながら、課題のヒアリングまでその場でお出しします。

無料体験講座を申し込む ▶

サービス資料のダウンロード（約18ページ）もご用意しています。

サービス資料をダウンロードする ▶

出典・注記

• 入力データの扱い（学習利用・保存期間）は、利用するサービスの契約プラン・設定・提供元の規約によって異なります。本記事は一般的な考え方を示すものであり、具体的な条件は必ず提供元の最新の規約・契約でご確認ください。
• 本文で挙げた運用ルール・安全装備（CLAUDE.md／Permissions／Hooks／Sandbox／git）は、DAIJOBUの自社運用と、研修でお伝えしている設計を抽象化したものです。具体的な設定内容は、セキュリティ上の理由から公開していません。社内運用の実績（20名以上が日常業務で運用、業務別カスタムエージェント約30種）は、DAIJOBUの自社実績です。研修第1回終了後に受講者の80%以上が自分のPCでClaude Codeを起動できた実績、および本文中の時間短縮の体験談は、DAIJOBUの研修受講者・自社での実績であり、結果を保証するものではありません。
• 本文で触れた「読み込んだ中身に仕込まれた指示で承認なし実行モードが有効化された脆弱性」は、2025年にAIコーディング支援ツールで報告・修正された事例を一般化したものです（特定製品の欠陥を指すものではなく、AIエージェント全般に共通する構造的リスクとして記載しています）。該当する実例として、AIコードエディタCursorで、外部から渡した指示が設定ファイルを書き換え、承認なしの自動実行を有効化できる脆弱性（CVE-2025-54135、2025年に修正版公開）が報告されています。プロンプトインジェクションが「確実な防止策が存在しない」との指摘は、OWASP GenAI Security Project「GenAI LLM Top 10」（2026年版）の見解に基づきます。
• 本文で紹介した4つの機能（統治・マッピング・測定・管理）は、米国NIST「AI Risk Management Framework（AI RMF 1.0）」に基づくものです。日本語訳は日本のAIセーフティ・インスティテュート（AISI）が公開しています。最新の内容は原典をご確認ください。
• 本文中の企業の声は、DAIJOBUの商談・セミナーアンケートに実際に寄せられたものを匿名化（業種表現）して掲載しています。ヒヤリの実例はDAIJOBU社内で実際に発生した事象です。

※本記事は2026年8月26日時点の情報にもとづきます。

この記事について DAIJOBUは、セキュリティ診断（脆弱性診断）も手がけ、かつClaude Codeを全社で日常運用している会社です。本記事は、その両方の実務知見をもとに、「禁止ではなく設計で、安全に使えるようにする」視点でClaude Codeのセキュリティを解説しています。