【2026年最新】Claude Codeのセキュリティ基礎｜非エンジニアが知るべき8つの事故と6つの原則
aikanri-admin
この記事の内容
「Claude Codeで業務効率化ツールを作ってみた」「会話するだけで動くものができて感動した」——非エンジニア経営者の間で、こうした声が急速に増えています。プログラミング知識ゼロでもシステムが作れてしまう時代。これ自体は、ビジネスにとって間違いなく大きなプラスです。
ただし、ここで一度立ち止まって考えてほしいことがあります。それ、セキュリティは大丈夫ですか？
「動くものが作れた」ことと「安全に動かせる」ことは、まったく別の話です。実際、AI時代に入ってから、本人に悪気がないのに大事故を起こしてしまうケースが各所で増えています。APIキーを間違えて公開してしまい100万円の請求が届く、AIに全権限を渡した結果社内ファイルが一晩で全削除される、ディープフェイクのビデオ会議で38億円を送金してしまう——これらはすべて現実に起きた事例です。
代表菅澤
AI鬼管理山崎
この記事で分かること:
Claude CodeをはじめとするAIエージェントは、これまでのチャットAIとはまったく別物です。PCのファイルを読み書きできる、外部サービスに接続できる、長時間自動で動き続ける——この特性があるからこそ事故の規模がケタ違いに大きくなります。「なんとなく使っている」は、もう通用しません。
01 WHY NOW なぜ今「非エンジニア向けのセキュリティ基礎」が必要なのか 「作れる人」と「守れる人」が別になった時代
まずは大前提からお話しします。なぜ、わざわざ非エンジニア向けにセキュリティの話をするのか。その理由は、AIの登場によって「作れる人」と「守れる人」の組み合わせが崩れたからです。
これまでの常識:「作る人＝守る知識を持っている人」
これまで、システムを作るのは専門のエンジニアの仕事でした。セキュリティ対策も、基本的には同じエンジニアが担っていました。つまり、「作れる人」と「セキュリティの知識を持っている人」はほぼ同一人物だったのです。
もちろん、それでも事故は起こりました。ただし、最低限の基本知識（APIキーを公開しない、権限を最小限にする、など）は作り手の常識として共有されていました。
AI時代の変化:「作れるけど、守り方を知らない」人が急増
Claude Codeの登場で状況は一変しました。プログラミング知識ゼロの経営者・営業担当・マーケターが、会話するだけで動くシステムを作れるようになった。これ自体は素晴らしいことです。
しかし同時に、「作れるけど守り方を知らない」という新しい層が一気に生まれました。「動いた！嬉しい！」の裏で、APIキーが漏れている、権限が緩すぎる、機密情報が外部に流れている——そんなリスクを抱えたまま運用が進んでしまう。
代表菅澤
国も警告:IPAの「情報セキュリティ10大脅威2026」
「大げさに言ってない？」と思われるかもしれませんが、IPA（情報処理推進機構）という国の組織が公式に警告しているレベルの話です。
📚 用語解説
IPA（情報処理推進機構）：経済産業省所管の独立行政法人で、日本の情報セキュリティ政策の中核を担う組織。毎年「情報セキュリティ10大脅威」を発表しており、これは企業の情報セキュリティ対策の事実上の公式ガイドラインとして扱われています。
2026年版では、「AIの利用を巡るサイバーリスク」というカテゴリが新設され、組織向け脅威の第3位にいきなりランクインしました。それまで存在しなかったカテゴリが、登場初年度からトップ3に入る——これがどれほど異例かは、セキュリティ業界を知っている人ほど驚いたトピックです。
| 比較軸 | 従来（AIなし） | AI時代（Claude Code等） |
|---|---|---|
| 作れる人 | エンジニアのみ | 非エンジニアも作れる |
| 守り方の知識 | 作る人が自動で学んでいた | 作れても守り方は別途学ぶ必要 |
| 事故の規模 | 限定的（担当範囲のみ） | 大規模（PC全体・外部サービス連携） |
| 自動化の速度 | 人間が1手ずつ | AIが自律的に数時間連続稼働 |
| 国の位置付け | 一般的な脅威の一つ | IPA 10大脅威2026で組織向け3位 |
AI鬼管理山崎
AI時代は「作れる人」と「守れる人」が別になりました。国（IPA）も組織向け脅威の3位にAI関連リスクを位置付けています。「知らなかった」では済まない時代です。
02 SELF-MADE INCIDENTS 【自分が起こす事故】4つの典型パターン 悪意なく事故る — それが最も危険
ここからは具体的な事故事例に入ります。まずは「自分が起こしてしまう」タイプの事故4つ。これらは、悪意のある第三者ではなく、使っている本人のうっかりミスで起こります。だからこそ、知っているだけで大半は防げます。
SELF-MADE INCIDENTS — 4 PATTERNS
APIキー漏洩
APIキーをコードに直書き→GitHub公開→自動スキャンで発見→不正利用→高額請求。数万〜数百万の被害。
AIへの過剰権限付与
全権限を渡したAIが暴走し、ファイル全削除や誤送信を実行。「綺麗に掃除しておきました」事件など。
シャドウAI
会社未承認のAIツールに機密情報を投入。学習に使われるリスクと、情報抜き取り目的の野良ツールのリスク。
Gitリポジトリ誤公開
デフォルト「公開」設定のまま機密を含むコードをpush。Anthropic社も2026年3月に51万行流出の大事故。
事故①:APIキーのハードコーディングによる漏洩
1つ目は、もっとも頻発していて、もっとも金額的被害が大きい事故です。
📚 用語解説
APIキー：外部サービス（Google Maps、決済システム、AIモデルなど）を使うための「鍵」。これを知っている人は誰でもそのサービスを利用できてしまう、パスワードのようなものです。APIキーの利用料金はキーを発行した人に請求されます。
📚 用語解説
ハードコーディング：APIキーのような重要情報を、プログラムのコード本体に直接書き込んでしまうこと。例え話でいえば、家の鍵を玄関ドアの前にテープで貼って外出するような状態です。
Claude CodeやChatGPTに業務ツールを組ませると、親切心からAPIキーをコード内に直接書き込むことがあります。経理の「Freeeから明細を自動取得」「マネーフォワードに仕訳を投げる」、営業の「HubSpotから商談リストを抽出」、採用の「応募者データをSmartHRに連携」——どれも業務効率化の小さなスクリプトですが、全部APIキーを使います。ここが抜け穴になります。
このコードをそのままGitHub（プログラムをみんなで共有する場所）に公開してしまうと、世界中の攻撃者が自動スキャンでAPIキーを見つけ出します。数分〜数十分単位の話です。見つかった瞬間から、勝手にクラウドサービスが使われ、請求はあなたに来ます。
経営現場でよく目にする「うっかり漏洩」パターンはこちらです。
| 業務領域 | よくある依頼 | 埋め込まれるAPIキー | 漏れたときの主な被害 |
|---|---|---|---|
| 経理 | 「Freeeの明細を毎週Sheetsに転記して」 | Freee / マネーフォワードAPIキー | 仕訳データの閲覧・改ざん、取引先情報漏洩 |
| 営業 | 「商談リストを毎朝Slackにまとめて」 | HubSpot / Salesforce APIキー | 顧客リスト・売上予測・案件ステータス流出 |
| 採用 | 「応募者の職務経歴を要約して」 | SmartHR / OpenAI APIキー | 候補者の個人情報・年収・評価の漏洩 |
| マーケ | 「Google広告のレポートを自動生成して」 | Google Ads / Meta広告APIキー | 広告費の不正消費、入札データの競合流出 |
(APIキー直書き)
うっかりpush
数分で発見
不正利用
高額請求
APIキー漏洩の被害度
APIキーは従量課金のものが多く、攻撃者は乗っ取った瞬間から最大レートで叩き続けます。OpenAIやGoogle Cloud系のAPIは1日あたり数十万円単位の請求が積み上がる構造で、発見が1日遅れるごとに被害が倍々に増えていくのが実態です。発行側の利用規約で保護されるケースもありますが、原則は「管理責任は発行者」。クレジットカード上限まで引き落とされてから気づくパターンが多発しています。
代表菅澤
あなたの会社で動いている自動化スクリプト・GASシート・社内ツールを1つ開いて、「api_key」「Bearer」「sk-」などの文字列でCtrl+F検索してみてください。ヒットしたら、そのキーは今すぐローテーションが必要です。ハードコーディングされた時点でいつ漏れても不思議ではない状態です。
事故②:AIへの過剰な権限付与による暴走
2つ目は、AIエージェントならではの事故です。便利さを優先するあまり、AIに強すぎる権限を渡してしまうケース。
例え話でいえば、入社初日の新人に、金庫の鍵と社長の印鑑をまるごと渡してしまうようなもの。普通の会社では絶対にやらないことを、AIに対してはカジュアルにやってしまう人が多いのです。
具体的には:
便利ですが、AIが指示を勘違いしたり誤動作したときの被害規模が跳ね上がります。重要ファイルの全削除、機密ファイルの誤送信、取り返しのつかない操作が人間が気づく前に進行します。
モードで起動
自律稼働
or 誤動作
(削除・送信)
データ消滅
AI過剰権限による暴走の被害度
経営現場で実際に起こりうる、背筋が凍るシナリオを並べてみます。
| 部門 | 意図した依頼 | AIが過剰権限で起こしうる誤動作 |
|---|---|---|
| 経理 | 「不要な過去PDFを整理して」 | 月次処理中の当月分請求書PDFを「不要」と判断して削除 |
| 営業 | 「商談リストを最新化して」 | 他部門が編集中の受注確定CSVを古いバージョンで上書き |
| 採用 | 「応募終了の候補者を整理して」 | 一次面接予定の現役候補者を「応募終了扱い」で削除 |
| マーケ | 「広告配信を最適化して」 | 深夜に予算上限を突破する入札単価で配信実行、翌朝請求額が10倍に |
| 開発 | 「ステージング環境を整理して」 | 接続先を間違えて本番DBを初期化、顧客データ全消失 |
削除・送信・送金・契約・公開——この5つは「やり直せない」カテゴリです。AIに実行権限を渡す前に、必ず「これは取り返せるか？」と自問する習慣をつけてください。取り返せない操作は人間承認を必須にすべきで、ここだけは効率を捨てる覚悟が必要です。
代表菅澤
AI鬼管理山崎
事故③:シャドウAI（会社未承認のAIツール利用）
3つ目は、組織で起こる事故です。
📚 用語解説
シャドウAI：会社が正式に承認していないAIツールを、社員が個人判断で業務に使ってしまうこと。「シャドウIT」のAI版として、2025年頃から注目されている組織的セキュリティ課題です。
ここで怖いのは、「悪気がない使い方ほど頻度が高い」という構造。経営者が気づかない現場では、こんな使われ方が日常化しています。
| 部門 | 現場で発生しているシャドウAI | 流出するリスクがある情報 |
|---|---|---|
| 採用 | 面接直前に応募者の職務経歴書を無料版ChatGPTに貼って「要点まとめて」 | 応募者の氏名・年収・職歴・スキル・評価 |
| 経営企画 | 経営会議の録音を無料文字起こしサービスに投入 | 未発表の事業計画・役員発言・KPI |
| 営業 | 提案前の競合調査で、顧客名入りのRFPを野良AIに要約させる | 顧客企業名・予算・意思決定プロセス |
| マーケ | Xで流れてきた「便利なAI広告ツール」を無許可でインストール | 広告アカウントの権限・クリエイティブ素材 |
| 法務 | 契約書レビューを個人契約の無料AIに依頼 | 契約相手・金額・独占条項・秘密保持範囲 |
それぞれ、本人は「ちょっと便利になるから」というだけの軽い気持ちです。でも、流出する情報は一度外に出たら取り戻せないものばかり。
無料AIサービスの多くは、利用規約上「入力されたデータを学習に使う」ことを明記しています。つまり、あなたの応募者データが半年後に他社の面接官に対する回答として出力される可能性がある。これは情報漏洩というより情報提供に近い性質の問題です。
代表菅澤
シャドウAIの被害度
シャドウAIを防ぐには「禁止」より「承認済みリストを整備する」方が効果的です。社員が「これならOK」と判断できる明確なホワイトリストがあれば、野良ツールに手を出すインセンティブが消えます。
事故④:Gitリポジトリの誤公開
4つ目は、Claude Codeを使い始めた方に特に多い事故です。
📚 用語解説
Gitリポジトリ：プログラムのソースコードや設定ファイルを保存しておく場所。Claude Codeでバイブコーディング（会話ベースの開発）を始めると、ほぼ確実にこれを使うことになります。公開（パブリック）と非公開（プライベート）のどちらかを選んで作成します。
問題は、GitHubのデフォルト設定が「公開（パブリック）」であること。Claude Code初心者が何気なくリポジトリを作り、機密情報を含むコードをpushすると、インターネット全体に公開されてしまいます。
経営現場で起こる「誤公開」には、次のようなパターンがあります。
| ケース | どう起こるか | 外部から検索可能になる情報 |
|---|---|---|
| 外注エンジニア納品 | 業務委託先が自分のGitHubアカウントに納品物を置いたまま退出 | 顧客名・社内ワークフロー・テスト用実データ |
| 社内ツールの公開忘れ | 経理の自動化スクリプトを作って「とりあえずpush」 | 仕訳ルール・取引先コード・口座情報の一部 |
| ブログ用サンプルコード | 広報担当が技術ブログ用にサンプルコードを公開 | APIキー・データベース構造・内部API仕様 |
| バックアップ目的のミス | 「消えたら困るから」と個人リポジトリにバックアップ | 顧客リストCSV・契約書テンプレ・営業資料 |
とくに怖いのが外注の納品物です。自分たちが依頼した業務ツールが、外注エンジニアの学習ポートフォリオとして公開されているケースは実際に存在します。依頼時に「成果物の保管場所を明示する」「納品後に外注側のローカルから削除する」といった契約を入れておかないと、気づかないうちに自社情報がネット上にストックされ続けます。
Claude Codeを開発しているAnthropic社自身が、2026年3月に同じ種類の事故を起こしました。社内管理システムの設定ミスで3,000件以上のファイルが公開状態に。さらに数日後、Claude Code本体のソースコード（51万行・2,000ファイル）がネットに流出。4万回以上コピーされ、派生ツールが乱立する事態に発展しました。AIを作るプロ中のプロでも、設定ミスで大事故を起こす——この事実は「中小企業のうちは関係ない」と思っていると痛い目を見る裏付けです。
AI鬼管理山崎
Gitリポジトリ誤公開の被害度
4つの事故すべてに共通するのは「悪気なく事故る」点です。知らないだけで防げるものがほとんど。逆に言えば、知っていれば大半の事故は回避できます。
03 EXTERNAL ATTACKS 【外部からの攻撃】4つの代表的な手口 悪意ある第三者があなたのAIを狙ってくる
次は、外部の攻撃者があなたやあなたのAIツールを狙ってくるタイプ。こちらは知識がないと気づくことすら難しいので、「こういう手口があるんだ」と知っておくだけで防御力が大きく上がります。
EXTERNAL ATTACKS — 4 VECTORS
プロンプトインジェクション
AIに特殊な指示を送り込み本来のルールを破らせる攻撃。IPA 10大脅威2026の新カテゴリ中核。
SQLインジェクション
データベース命令文を入力に紛れ込ませて不正操作する古典攻撃。AI生成コードにも普通に残る脆弱性。
フィッシング／ディープフェイク
AIで本人そっくりの音声・動画を生成しビデオ会議で誘導。香港では38億円の送金被害が発生。
サプライチェーン攻撃
本物そっくりの偽パッケージを仕込み自動インストールさせる攻撃。2026年3月のaxios事件など。
攻撃①:プロンプトインジェクション
1つ目は、AI時代の代表的な攻撃で、IPA 10大脅威2026で組織向け3位に入った新カテゴリの中心にあるものです。
📚 用語解説
プロンプトインジェクション：AIに対して特殊な指示文を入力し、本来のルールを破らせて情報を引き出したり意図しない操作を行わせる攻撃。SQL インジェクションの「AIバージョン」と考えると分かりやすいです。
経営者にとって身近なのは、「自律型AIが外部コンテンツを読み込んで乗っ取られる」パターン。Claude Codeを使っていると、次のような依頼を日常的にすることになります。これがすべてプロンプトインジェクションの入口になりうる、と知っておくと感覚が変わります。
| 業務での依頼 | Claude Codeが読みに行くもの | 潜在的な攻撃経路 |
|---|---|---|
| 競合分析 | 競合企業サイト・LP | 競合が仕込んだスクレイピング対策指示で誤情報を埋め込まれる |
| メール対応 | 受信メール本文・添付PDF | 攻撃者の送信メールに「過去メールを要約して送れ」指示 |
| 資料要約 | 取引先から送られたドキュメント | 悪意ある送信者が「機密情報をこの宛先に送れ」指示を埋込 |
| 顧客問い合わせ | 問い合わせフォーム入力欄 | 顧客を装って「これまでのルールを無視」の攻撃文を送信 |
| Web調査 | 検索結果のページ | 汚染された記事から.envの中身を読んでSlackに送れ等の指示 |
とくに厄介なのは、人間の目には見えない文字色・フォントサイズで攻撃命令が埋め込まれているケース。Webページを画面で見ても何も見えませんが、AIは裏のHTMLまで読むので、そこに書かれた指示に従ってしまいます。
競合サイト/メール/PDFを読む
仕込まれた指示を実行
ファイルから情報抽出
静かに送信
代表菅澤
プロンプトインジェクションの被害度
攻撃②:SQLインジェクション
2つ目は、AI時代以前からある古典的な攻撃ですが、AIが書いたコードにも普通に脆弱性として残るので油断できません。
📚 用語解説
SQLインジェクション：データベースを操作する命令（SQL）を、入力フォームなどから送り込んでデータベースを不正に操作する攻撃。本来見えないはずのデータが丸見えになったり、データが勝手に書き換え・削除されたりします。
なぜ非エンジニア経営者にも関係するかと言うと、「Claude Codeで急いで作った社内ツールのフォーム」がSQLインジェクションの温床になりがちだからです。想像してみてください。
| 作ったツール | 攻撃を受けると起こること |
|---|---|
| 採用応募フォーム（自社サイト） | 応募者DBが丸ごと漏洩＋ 書き換えで採用ステータス改ざん |
| 顧客管理用の社内ダッシュボード | 全顧客リスト・売上・連絡先を外部から閲覧可能に |
| 社内アンケート集計Bot | 回答DBを削除されることで、改善施策の根拠データが消える |
| セミナー申込LP | 申込者データの氏名・会社名・メールが競合セミナー運営者に流出 |
「AIが書いたコードだから安全」は幻想です。むしろAIは既存の脆弱なコードパターンも学習しているため、注意していないと普通に脆弱なコードを出してきます。「動くから公開した」の直後に事故るのが、このパターンの典型です。
外部公開するフォーム・ページを作ってもらう時は、指示に必ず次の3点を入れましょう。(1)「SQLインジェクション・XSS対策を入れて」、(2)「入力値のバリデーションを全項目に入れて」、(3)「本番公開前にセキュリティ観点でこのコードをレビューして」。明示しないと、Claude Codeは動くだけの最低限のコードを出してくることが多いです。
攻撃③:ソーシャルエンジニアリング／フィッシング／ディープフェイク
3つ目は、AI時代になって被害規模が桁違いに増えた分野です。
📚 用語解説
ソーシャルエンジニアリング：システムの脆弱性ではなく、人間の心理的隙を突いてパスワードや機密情報を盗み出す攻撃。フィッシングメール、偽サイト、なりすまし電話などが典型例です。
これまでのフィッシングメールは「片言の日本語」でバレバレでした。「今すぐiTunesカードを買ってください」のような明らかに怪しいメッセージが多かったので、注意していれば避けられました。
ところが、攻撃者側もAIを使うようになったことで状況は一変。
| 項目 | 従来 | AI時代 |
|---|---|---|
| 日本語品質 | 片言・違和感あり | ネイティブと区別困難 |
| 偽サイト作成 | 技術者が時間をかけて作成 | AIで数分で生成 |
| 音声・動画 | 基本存在しない | ディープフェイクで本人そっくりを再現 |
| ターゲット | 無差別メール | 個別最適化されたスピアフィッシング |
特に日本の中小企業で現実的に起こりうるのが、次のようなシナリオです。「うちは大企業じゃないから狙われない」は通用しません——中小企業は金額が小さくても守りが薄いので、攻撃の費用対効果がむしろ良いターゲットです。
| 手口 | 使われる材料 | 狙われやすい業務 |
|---|---|---|
| 社長音声なりすまし電話 | YouTube・セミナー登壇の動画音声 | 経理担当への「至急振り込み」指示 |
| 取引先役員のメール偽装 | 名刺交換会の写真・LinkedIn写真 | 「口座変更のお願い」による請求書詐欺 |
| ディープフェイクZoom会議 | Webサイト役員紹介の動画 | M&A・業務提携を装った機密情報引き出し |
| AIライティング偽メール | 公開プレスリリース・採用ページ | 採用合格通知を装ったフィッシング |
2024年、香港のある企業で、攻撃者がCFO（最高財務責任者）になりすましてビデオ会議を開催。参加者のCFO・他の同僚は全員ディープフェイクで作られた偽物で、本物の参加者は対象従業員1人だけ。その場で「この口座に振り込んで」と指示され、2,500万ドル（約38億円）が送金されてしまいました。日本でも同様の手口は確実に起きうるので、他人事では済みません。
役員の顔・声収集
ディープフェイク生成
開催
指示
確認なく送金
ディープフェイク詐欺の被害度
「社長名義で緊急の金銭指示が来たら、事前共有した合言葉（コードワード）を電話で確認するまで実行しない」——このルールを全社共有するだけで、ディープフェイク詐欺の9割は防げます。合言葉は四半期ごとに変えるのがおすすめ。手間に見えて、1回のミスで失う金額を考えれば安い保険です。
AI鬼管理山崎
攻撃④:サプライチェーン攻撃
4つ目は、Claude Codeなどの自律型AIを使っているとき特に危険な攻撃です。
📚 用語解説
サプライチェーン攻撃：あなたが使うプログラム部品（ライブラリ・パッケージ）そのものにウイルスを仕込む攻撃。あなたが信頼して使っている部品が、実は危険物だった——という状況を作り出します。
Claude Codeは「この機能を使うには〇〇というパッケージをインストールしてください」と提案してくることがあります。経営者視点で怖いのは、「便利そうだからとりあえずYes」を押した瞬間に汚染コードが会社PCで動き出す構造です。
攻撃者が仕掛ける典型的な罠を整理します。
| 攻撃手法 | 仕組み | Claude Code利用時の危険度 |
|---|---|---|
| タイポスクワッティング | 本物の名前を一文字だけ変えた偽パッケージ（axios → axioss） | 人間のタイポよりAIのハルシネーションで引っかかる方が多い |
| AIハルシネーション先読み | AIが間違えて言いがちな名前で事前に偽物を用意 | 全承認モードで即座にインストール→乗っ取り成立 |
| 正規パッケージの乗っ取り | メンテナーのアカウント侵入→正規版にウイルス混入 | 正規名で入れても汚染版という防ぎようがない事態 |
| MCPサーバーの偽装 | 「Notion連携MCP」を装って個人開発者が公開 | Claude Code側で権限を与えた瞬間に情報が送信される |
MCPサーバーは個人開発者でも自由に公開できます。「Notion連携」「Slack連携」といった公式っぽい名前でも、実は個人が数日で作った野良ツールということが珍しくありません。社員が業務自動化のつもりで導入→Slackログが外部サーバーに送信、というケースは今後確実に増えていきます。
Anthropicのソースコード流出と同じ日に、超有名プログラム部品「axios」（週1億回ダウンロード、世界のクラウド環境の80%で使用）のメンテナーアカウントが北朝鮮系ハッカーに盗まれ、ウイルス入りバージョンが3時間だけ公開される事件が発生。3時間でも相当な数がダウンロードされ、Claude Codeで自動インストールされた環境もあったと考えられています。「名前が有名=安全」の前提が崩壊した象徴的な事件です。
代表菅澤
npm auditなどで脆弱性スキャン」。うちのクライアント支援でも、この2点を入れるだけで体感的な事故率は大きく下がっています。偽パッケージ公開
インストール提案
自動インストール
or 情報抜取
サプライチェーン攻撃の被害度
4つの攻撃に共通するのは「あなたが直接操作していなくても被害が発生する」点です。プロンプトインジェクションはAIが読み込んだだけ、サプライチェーン攻撃はパッケージを入れただけで成立します。受け身の姿勢では守れません。
04 PRINCIPLES セキュリティ設計の6原則 — 判断の「物差し」を持つ 新しいサービスが出た時に「安全か？」を自分で判断する基準
ここまで事例を見てきました。では、次々と出てくる新しいAIサービスやツールを、どう判断すればいいのでしょうか。
答えは「セキュリティ設計の原則」を知っておくこと。1970年代にアメリカの研究者が提唱し、半世紀経った今でもセキュリティ業界の基本として使われている考え方です。新しいツールを前にしたとき、この原則に照らして判断できるようになれば、自走力が一気に上がります。
6 SECURITY PRINCIPLES
最小権限の原則
「採用担当に経理DBの編集権限は渡さない」と同じ発想。タスクに必要な最低限だけ。
多層防御
オフィスビルの入館証→フロア認証→部屋の鍵→金庫の4層と同じ。どこかで止まる構造。
フェイルセーフ・デフォルト
稟議が通るまで実行しない。組織の意思決定ルールをAI運用にも持ち込む。
攻撃面の最小化
使っていない支社・窓口を閉じるのと同じ。未使用APIキー・退職者アカウントの即時削除。
被害範囲の最小化
部門ごとに権限を分離し、事故が起きても1部門で止まる設計。出口の設計。
職務分離
経理の「申請者と承認者は別人」ルール。AIにも同じで、実行者と承認者を必ず分ける。
6つの原則を順に見ていきます。
原則①:最小権限の原則（Principle of Least Privilege）
システムやユーザーには「そのタスクに必要な最低限の権限だけ」を与える、というもっとも基本的な原則。経営者にとっては「職務権限規程」をAIにも当てはめると考えると腹落ちしやすいです。
例えばAIに「CSVファイルを集計して」と頼むなら、必要な権限は「そのCSVを読む権限」と「結果を出力する権限」だけのはずです。それなのにPC全体の削除権限まで渡しているケースが多すぎる、というのが現状です。
経営者の視点で「職務権限」に置き換えると、次のような対応関係になります。
| 会社の職務権限 | 同じ発想のAI権限設計 |
|---|---|
| 採用担当が経理DBを直接編集できない | AIが依頼タスク以外のファイルに書き込めない |
| 支店長が本社の取締役会資料を閲覧できない | AIがプロジェクトフォルダ外のデータを読めない |
| 新入社員は承認権限を持たない | AIが単独で「送信・削除・送金」を実行できない |
| 退職者のアカウントは即日停止 | 使わなくなったAPIキー・MCPはすぐ削除 |
代表菅澤
原則②:多層防御（Defense in Depth）
1枚目の壁が破られても、2枚目・3枚目で止められるように守りを何重にも重ねる考え方。
ビルの入館証→フロア認証→部署の電子錠→金庫室の鍵——これだけ重ねていれば、どこかで悪意ある訪問者は止まります。どれか1つだけで100%安全にしようとせず、不完全な対策を何層も重ねて確率を下げる——これが実務でワークする発想です。
具体的にAPIキー管理でこの原則を適用すると、次のような多層構造になります。
除外
マネージャーで
本体保管
どれか1つでも破られても、次の層で止まる。すべて破られる確率は限りなく低くなります。「100点の対策は存在しない」という現実を受け入れたうえで、不完全な対策を何層も重ねるという大人の発想です。
原則③:フェイルセーフ・デフォルト（Fail-safe Defaults）
ひと言で覚えるなら「迷ったら拒否が初期設定」。
設定し忘れたとき、勝手に「許可」になるのか「拒否」になるのか——その初期設定をどちらにしておくか、という話。デフォルト拒否を選ぶのが原則です。
例えば:
AI鬼管理山崎
——これ、本当に多いんですが、フェイルセーフの原則から見ると完全にアンチパターンです。「迷ったらNo」に変えるだけで、事故確率は劇的に下がります。
原則④:攻撃面の最小化（Attack Surface Reduction）
「攻撃者が侵入できる窓口」を減らす考え方。経営の感覚で言うなら「拠点・アカウント・ツールを増やすほど管理コストと侵入経路が増える」という普通の話です。
| 対象 | 「攻撃面が広い」状態 | 「攻撃面が狭い」状態 |
|---|---|---|
| 拠点・アカウント | 退職者のアカウントが残り続けている | 退職日当日に全サービスで停止 |
| 社内ツール | 3年前の検証用SaaS契約がそのまま | 使っていないSaaSは即解約 |
| AIサービス | 無料登録した野良ツール10個が口座連携中 | 会社承認済みの2-3サービスに集約 |
| APIキー | 発行履歴が誰も管理していない | スプレッドシートで全件把握＋月次棚卸 |
| WordPressプラグイン | 「便利そう」で入れた30個 | 必要な5-10個に絞る |
IT・AIの世界でこれをやると、「使っていないものを全部閉じる・消す」という話になります。
原則⑤:被害範囲の最小化（Blast Radius）
もし侵入されたとしても、被害がどこまで広がるかを前提に設計しておく原則。直訳すると「爆発の影響範囲」です。
原則①（最小権限）が「入り口」の話だとすると、原則⑤は「出口」の話。侵入されないよう頑張るのは当然として、侵入されても被害を局所化できる設計にしておく発想です。
「毎回APIキーを取得するのが面倒だから、GoogleもClaudeも全部同じキーを使い回している」——絶対にダメです。1つ漏れると全サービスが道連れになります。サービスごとに別キーなら、被害は漏れたサービス1つに限定できます。
原則⑥:職務分離（Separation of Duties）
1人（1つの存在）に全部任せず、役割を複数に分けてチェックし合う考え方。
経理で分かりやすい例:
| 役割 | 誰が担当 |
|---|---|
| お金の申請 | 経理担当 |
| 承認 | 社長・部門長 |
| 実行 | 経理担当 |
1人が申請・承認・実行をすべて握っていたら、横領し放題になります。だから役割を分ける——これがAI時代にも当てはまります。
| AIへの任せ方 | 職務分離の観点 |
|---|---|
| AIが申請・実行・承認すべて勝手にやる（全承認モード） | 原則違反 |
| AIが実行候補を提案→人間が承認→AIが実行 | 原則OK |
代表菅澤
6原則の名前を暗記する必要はありません。大事なのは「新しいツールが出た時にこの観点で見る」引き出しを持つこと。デフォルトで非公開か、権限は絞れるか、漏れた時にどこまで広がるか、人間が承認を挟めるか——これだけ見れば大半の判断はつきます。
05 ACTION PLAN 明日から実践できる6つのアクション 知識を行動に変える具体ステップ
最後に、明日から今日から実践できる具体アクションを6つ紹介します。すべてをいきなり完璧にやる必要はありません。1つずつ順番に導入していってください。
今日中
APIキーを.envで分離
もっとも優先度が高いアクション。コードに直書きされたAPIキーを.envに移し、.gitignoreで除外する。
今日中
AIに会社の秘密を教えない
会社未承認AIへの機密投入を即停止。ホワイトリスト運用に切り替え。
今週中
AIの提案を検証するクセをつける
全承認モードを切り、コマンドや提案パッケージの意味を「何するコマンド？」と聞く習慣を作る。
今週中
AIに全権限を渡すのを止める
PC全体・クラウド管理者・送金系の権限を外す。必要な時だけ、範囲を限定して付与。
今月中
公開前に第三者レビュー
作ったツールを公開する前にエンジニアや外部専門家にチェックしてもらう仕組みを作る。
継続
セキュリティ基礎を学び続ける
IPA 10大脅威を年1回通読、AIセキュリティニュースを定期チェック、Claude Codeに月1で自己診断依頼。
アクション①:APIキーとコードを分離する運用を徹底する
最優先のアクションです。2段階に分けて設定します。
コード本体にAPIキーを直接書かず、専用の.envファイルに保存する。Claude Codeに「APIキーをハードコーディングしないで、.envに分けて」と指示すれば対応してくれます。
.gitignoreファイルに.envを追記して、GitHubへのアップロード対象から除外する。これをやらないと.envをファイル名を変えただけで安全になると誤解しがちなので要注意。
1Passwordなどのパスワードマネージャーに本体を保管し、.envからは「住所だけ参照する」形にすると、.envが漏れても鍵本体は守られます。
設定で.envの読み取り禁止を明示的に指定する。プロンプトインジェクション経由で抜かれるのを防ぐ重要な一手。
「.envと.gitignoreの使い方教えて」「APIキー管理のベストプラクティスを教えて」とClaude Codeに聞けば、丁寧に説明してくれます。ただし聞かないと勝手にやってくれないので、最初に必ずリクエストすること。
アクション②:AIに会社の秘密を教えない
会社が承認していないAIサービスに、以下のような情報を入力しないでください。
有料版でも危険なものは普通にあります。料金と安全性は別問題です。そもそも「機密情報を他社のサーバーに送信する」行為自体にリスクがあるという視点で判断しましょう。機密情報を扱う場面では、PC内だけで完結するローカルLLM（オープンソースの言語モデルをPC内で実行する方式）の活用も選択肢に入れてください。
アクション③:AIの提案を鵜呑みにしない
AIが「このパッケージをインストールしてください」「このコマンドを実行してください」と提案してきたら、内容を理解してから実行する。これが第3のアクションです。
といっても、毎回全部調べるのは現実的ではありません。最低限、以下は覚えておきましょう。
| よく出るコマンド | 何をする | 安全度 |
|---|---|---|
ls / dir | ファイル一覧を表示 | ◎（読み取りのみ） |
cat / type | ファイル内容を表示 | ◎（読み取りのみ） |
git status | Git状態確認 | ◎ |
rm / del | ファイル削除 | △（取り返しつかない） |
git push --force | リモート強制上書き | ×（他人の作業を吹き飛ばす） |
sudo / 管理者実行 | 管理者権限で実行 | ×（何でもできてしまう） |
curl (外部ダウンロード) | 外部からデータ取得 | △（何を取ってくるか注意） |
分からないコマンドが出てきたら、Claude Code自身に「これは何をするコマンド？」と聞くのが最速・最安全です。
アクション④:AIに全権限を渡さない
全承認モード（--dangerously-skip-permissions）は原則オフ。必要な時だけ、必要な範囲で権限を付与してください。
AI鬼管理山崎
アクション⑤:公開前に第三者の目を入れる
非エンジニアがClaude Codeで作ったツール・システムを社内や社外に公開する前に、分かるエンジニアや情報セキュリティ担当者にレビューしてもらうこと。
非エンジニアでは絶対に気づけない脆弱性が潜んでいることが多いからです。動いたことに感動して「公開しちゃおう」となりがちですが、ここをスキップすると事故ります。
外部のセキュリティレビューサービス（スポットで数万円〜）を活用するか、AI鬼管理のようなClaude Code伴走支援で定期レビューを組み込むのが現実解です。1回の事故で数十万〜数百万の損失が出ることを考えれば、レビュー投資は十分に元が取れます。
アクション⑥:継続的にセキュリティ基礎を学ぶ
セキュリティの世界は攻撃手法が日々進化しています。昨日まで安全だったツールが、今日は危険になる——普通にある世界です。
【部門リーダー向け】週次・月次の定期チェック項目
アクションは一度やれば終わりではありません。経営者・部門リーダーが週次/月次で回すルーティンに落とし込むと、事故率が継続的に下がります。
| 頻度 | 部門リーダーがやること | 所要時間 |
|---|---|---|
| 毎週月曜 | 前週に発行したAPIキー・権限変更を一覧確認 | 10分 |
| 毎週月曜 | Claude Codeの確認プロンプト「毎回Yes」が習慣化してないかヒアリング | 15分 |
| 毎月初 | 未使用SaaSアカウントの棚卸し・解約判断 | 30分 |
| 毎月初 | 退職者リストと全サービスのアカウント一覧を突合 | 30分 |
| 四半期 | IPAの最新セキュリティ情報を部門会議で共有 | 20分 |
| 四半期 | ディープフェイク詐欺用の合言葉をローテーション | 5分 |
6つのアクションすべてを初日にやる必要はありません。アクション①（APIキー分離）だけは今日中に、それ以外は1週間〜1ヶ月で順番に。「完璧より実行」です。
06 BY COMPANY SIZE 【経営者ケース別】規模・業種別の最初の30日プラン 自社にフィットする優先順位を1枚にまとめる
6原則と6アクションだけだと、「で、結局うちは何から？」という問いが残りがちです。ここでは会社規模と業種ごとに、最初の30日で何を優先すべきかを1枚にまとめました。AI鬼管理の現場支援で、実際に使っている優先順位です。
【規模別】会社の人数で変わる優先順位
3 SIZE PATTERNS
1人社長・数人規模
全権限が社長1人に集中。最優先は「自分がミスした時の復旧手段」。オフサイトバックアップ＋合言葉ルール。
10-30人規模
部門が出始める段階。ホワイトリスト・共有ドライブの権限分離・承認フロー整備が最優先。
30-100人規模
ガバナンスが必要になる境目。情シス専任または外部セキュリティ顧問、ログ監視、インシデント対応手順。
A. 1人社長・数人規模の30日プラン
全権限を持っている自分自身が最大のリスクです。誰もレビューしてくれない前提で、自分の操作ミスを前提にした防御を組みます。
Day 1
全APIキー棚卸し＋.env分離
自分のPC・スプレッドシートにあるAPIキー全件をリストアップ→.envへ移行→.gitignoreに追加。
Day 2-3
外部バックアップの多重化
全ファイルをクラウド(Google Drive/iCloud)＋外付けSSDに二重バックアップ。AI暴走で消えても復旧できる体制。
Day 7
全承認モードをオフ
便利さと引き換えに、壊滅的リスクを負うモードを切る。確認プロンプトは「迷ったらNo」。
Day 14
ディープフェイク用合言葉を取引先と共有
主要取引先・家族と「お金関連の緊急連絡に使う合言葉」を決めておく。四半期ごとに変更。
Day 30
外部顧問に1回レビュー
自分の目だけでは必ず抜けが出る。1人社長こそ外部の目を入れるべき。月1回のスポットレビューから。
B. 10-30人規模の30日プラン
ルールを作って社員に守らせるフェーズ。経営者が細部を見切れなくなる規模なので、仕組みで守る発想に切り替えます。
Day 1-3
承認済みAIサービスのホワイトリスト作成
社員が使って良いAI（Claude/Claude Code/ChatGPT Enterprise等）を明示。それ以外は事前申請制。
Day 7
共有ドライブ・GitHubの権限分離
「全員アクセスフォルダ」をやめ、部門別に権限を分離。経理の情報が営業に見えない構造に。
Day 10
APIキーの発行台帳を作成
誰が・いつ・どのサービスのキーを発行したか、スプレッドシート1枚で一元管理。月次棚卸の土台。
Day 14
全社向けセキュリティ研修（1時間）
シャドウAI禁止、APIキー管理、ディープフェイク警戒の3点。この記事のSection 2-3を使い回してOK。
Day 21
退職時チェックリスト整備
退職日当日に全SaaS・GitHub・クラウドアカウントを停止する標準手順を総務/人事と共有。
Day 30
月次レビュー会を開始
経営・現場リーダーで月1回、APIキー棚卸・未使用SaaS解約・インシデント確認を15分でレビュー。
C. 30-100人規模の30日プラン
専任または外部の情シス機能が必要になる規模。個人の注意力ではカバー不能なので、監視と対応手順を整備します。
Day 1-7
情シス担当 or 外部顧問を決定
社員1人分の時間 or 月額顧問契約でセキュリティ責任者を明示。「誰の仕事か曖昧」が最大の事故要因。
Day 14
ログ監視ツールの導入
Claude Codeの実行ログ、GitHub pushログ、クラウドアクセスログを一元で見られる状態に。
Day 21
インシデント対応手順書の作成
APIキー漏洩・AI暴走・ディープフェイク等の5パターン別に、「誰が何をするか」を1枚にまとめる。
Day 30
机上訓練（シミュレーション）
「もしAPIキーが漏れたら？」「もしAI暴走でデータが消えたら？」を経営会議で30分議論。手順の穴を炙り出す。
【業種別】リスクの重みが特に高いポイント
| 業種 | とくに警戒すべきリスク | 最優先アクション |
|---|---|---|
| 士業（税理士/弁護士/社労士） | 顧客の個人情報・財務情報・機微情報の流出 | シャドウAI完全禁止＋業務委託契約の守秘義務条項更新 |
| EC・D2C | 顧客リスト・クレカ情報・売上データの漏洩 | LP/フォームのSQLi対策＋決済系APIキー厳重管理 |
| SaaS・IT受託 | 納品コード内のAPIキー流出・リポジトリ誤公開 | GitHub組織アカウント化＋納品物のセキュリティレビュー必須化 |
| 製造業 | 設計図面・取引先情報・生産スケジュールの漏洩 | 共有ドライブ権限の厳密分離＋外部アクセス経路の棚卸し |
| 人材・採用 | 応募者の個人情報・面接評価の流出 | 応募者情報を扱うAIのホワイトリスト化＋プライバシーポリシー整合性 |
| コンサル・広告代理 | クライアントの未発表戦略・競合情報の漏洩 | クライアント別のフォルダ/権限分離＋NDA対応AIのみ使用 |
代表菅澤
規模・業種によって最初にやるべきことは全く違います。1人社長は「自分のミス前提の復旧」、10-30人は「ルール＋権限分離」、30-100人は「専任＋監視」。業種は一番価値のある情報資産から逆算して優先順位をつけます。
07 FIELD INSIGHTS 【AI鬼管理の現場で見た】Claude Code導入後の失敗5選 他社の失敗は自社の教科書 — 実際にあった5パターン
AI鬼管理では月数十社の経営者と一緒にClaude Code導入・運用支援をしていますが、そこで何度も繰り返し見るパターンがあります。ここでは、表には出しづらい「実際の現場で起きている失敗5選」を共有します。動画や他社記事ではあまり語られない、導入3ヶ月後にジワジワ効いてくるタイプの事故です。
失敗①:「動くから放置」で半年後に漏洩発覚
もっとも多いパターンです。Claude Codeで小さな業務自動化ツールを作って、「動いてる！便利！」でそのまま半年。誰もコードを読み返さない結果、APIキーが直書きされたスクリプトが共有ドライブでずっと生き続けます。
「漏洩の瞬間」は分からないので、気づくのはクラウド利用料金の異常や取引先からの指摘があった時。この時点で被害は3-6ヶ月分になっています。
daily-report-20260410-reviewed20260715.pyのように、スクリプトのファイル名に最終レビュー日を入れる運用に。月次棚卸で「3ヶ月以上レビューされていないもの」をリストアップするだけで、この失敗は激減します。
失敗②:全承認モードを「便利だから」と社員全員に横展開
経営者が自分で全承認モードを使って「これは便利だ！」と感動→社員にも同じ設定を推奨→社員の誰かがプロンプトインジェクションにハマって事故、というパターン。
経営者はAIのリスクを理解した上で便利さを享受しているのに対し、社員は何も知らずに便利さだけ受け取るので、事故確率が桁違いに上がります。
AI鬼管理山崎
失敗③:外注の納品物を自社で読まず、ブラックボックス化
非エンジニア経営者にありがちですが、外注エンジニアが作ったClaude Code用の社内ツールを「動いてるからいい」で中身を一切読まないケース。納品物にAPIキーが直書きされていたり、外注先の自前サーバーにログが送信される実装だったり、というブラックボックスリスクが発生します。
特に悪質なのが、外注エンジニアが退職・契約終了した後もバックドアが残っているパターン。納品時に気づかず、半年後に「前の人がまだシステムにアクセスできる状態だった」と発覚します。
「このコードにAPIキーハードコード・バックドア・外部送信処理・過剰な権限要求がないかレビューして」とClaude Code自身に検査させる。1分でチェックできて、外注レビュー代わりとしては十分実用的です。
失敗④:セキュリティ研修が1回きりで形骸化
導入時に1回だけセキュリティ研修をして、その後半年以上アップデートなし。でも攻撃手法は日々進化するので、半年経つと研修内容が古くなります。さらに、新入社員は研修を受けていない状態で業務に入ります。
結果、「研修はやりました」の既成事実だけが残り、実態は最新の攻撃に対応できない状態になります。
| 形骸化する研修 | 機能する研修 |
|---|---|
| 初回の全社1時間 | 月次15分 × 全社員 |
| パワポスライドの読み上げ | 最新の事故事例ニュースを毎月共有 |
| 受講履歴を記録するだけ | 理解度テスト＋不正解者への再学習 |
| 情シス担当者のみ更新 | 全部門リーダーが当番制で話題提供 |
失敗⑤:インシデント発生時のエスカレーション先が不明
「もしAPIキー漏洩が発覚したら、誰に最初に連絡する？」「もし社員がディープフェイク詐欺に遭ったら、止める手順は？」——これに即答できない組織が多いです。
事故は発生後最初の数時間が勝負です。連絡先が曖昧だと、「誰に言えば？」「とりあえず自分で何とか」と対応が遅れ、被害が拡大します。
(1) 第一報先（社長直通 or 情シス責任者）、(2) 二次連絡（顧問弁護士・外部セキュリティ業者）、(3) 停止手順（該当サービスのAPIキー無効化方法）——この3点を1枚の紙にまとめて全社員に配布。紙で配るのがポイント（PCが乗っ取られた時にも見られる）。
代表菅澤
導入時よりも運用3ヶ月後〜1年後がリスクのピークです。「動いているから大丈夫」の慣れが最大の敵。月次レビュー・研修の更新・インシデント手順——この3つを運用に組み込めば、失敗5選はほぼ防げます。
まとめ ── 100%の防御はない、でも知識があれば防げる
ここまでの内容を振り返ります。
代表菅澤
AI鬼管理山崎
「動くものが作れた」の次は「安全に運用できる」へ。ここを乗り越えれば、Claude Codeは本当にあなたのビジネスの強力な武器になります。
NEXT STEP
この記事の内容を、あなたのビジネスで
実践してみませんか？
AI活用を自社で回せるようになりたい方
AI鬼管理
Claude CodeやCoworkの導入支援から、業務設計・ルール作成・社内浸透まで実践ベースで伴走します。「自分たちで回せる組織」を作りたい経営者向け。
学ぶ時間はない、とにかく結果がほしい方
爆速自動化スグツクル
業務ヒアリングから設計・開発・納品まで丸投げOK。ホームページ、LP、業務自動化ツールを最短即日で構築します。
| AI鬼管理 | 爆速自動化スグツクル | |
|---|---|---|
| こんな方向け | 社内で回せる状態を作りたい 外注に依存しない組織を作りたい | 学ばなくていいから結果だけ欲しい とにかく早く自動化したい |
| 内容 | AIの使い方・業務設計・自動化の作り方を 実践ベースで叩き込む | 業務をヒアリングし、設計から ツール・システムを丸ごと納品 |
| 一言で言うと | 自分で作れるようになる | 全部任せられる |
| AI鬼管理を詳しく見る | スグツクルを詳しく見る |
よくある質問
Q. Claude Codeを使っているだけでハッキングされることはありますか？
A. 正規のClaude Codeそのものは、Anthropicが運営する信頼できるアプリケーションです。ただし、プロンプトインジェクションで仕込まれた悪意ある指示を読み込むと、意図しない操作をしてしまう可能性があります。また、サプライチェーン攻撃で汚染されたパッケージを自動インストールする経路もあります。全承認モードを避け、確認プロンプトで必ず内容を見ることが最大の防御になります。
Q. APIキーが漏れていないかを確認する方法はありますか？
A. GitHubで自分のリポジトリを開き、コード検索で「api_key」「API_KEY」「secret」などのキーワードで検索してみてください。ヒットしたら即座にそのキーを無効化（ローテーション）し、新しいキーに差し替えます。また、GitHubにはSecret scanningという機能があり、既知の形式のAPIキーが含まれていると自動で警告してくれます。無料で利用できるので有効化を推奨します。
Q. 機密情報を含むプロジェクトでもClaude Codeは使えますか？
A. 使えます。ポイントは3つ。（1）機密ファイルを閲覧禁止設定にしてClaude Codeから見えないようにする、（2）APIキーなど秘密情報はパスワードマネージャーに保管し.envから参照だけする、（3）GitHubを使う場合はプライベートリポジトリにする。さらに厳格な用途では、外部通信を遮断できるローカルLLMの併用も検討してください。
Q. 全承認モードを使ってしまっていますが、今すぐ止めるべきですか？
A. 業務で使っているなら、今すぐ止めるのを強く推奨します。全承認モードは「時間短縮」と「壊滅的事故のリスク」のトレードオフで、短縮される時間は1日数十秒〜数分、失う可能性のある金額・データは数十万〜数百万円相当です。確認プロンプトが面倒なら、「このディレクトリ内での読み取りは自動承認」のような細かい権限設定で妥協するほうが安全です。
Q. ディープフェイクへの対策は個人でも可能ですか？
A. 可能です。重要なのは意思決定のプロトコルを変えること。送金・契約・パスワード共有などの重要判断は、必ず別経路（対面・電話・社内チャット）で二重確認するルールを全社で共有してください。特にビデオ会議中に「今すぐ送金を」と指示されたら、一度切って別経路で確認——これだけで香港38億円事件のような大事故は防げます。
Q. IPAの情報セキュリティ10大脅威はどこで確認できますか？
A. IPA（情報処理推進機構）の公式サイトで毎年1月末〜2月頃に発表されています。「IPA 情報セキュリティ10大脅威」で検索すればすぐ見つかります。PDFで無料公開されており、組織向け・個人向けに分かれています。経営者の方は組織向けを年1回通読するだけでも、判断基準が大きく変わります。
Q. 社員にシャドウAIを使わせないためには、どんなルールを作れば良いですか？
A. 「禁止リスト」より「承認済みホワイトリスト」の方が機能します。社内で利用OKのAIサービスを明示し（例：Claude、ChatGPT Enterprise、Gemini for Workspace）、それ以外は事前申請制に。同時に、「承認リストにないと困るケース」の申請フローを軽量化しておくと、無理に禁止する必要がなくなります。AI鬼管理のコンサルでも、ここは必ず最初に整備する領域です。
Q. 非エンジニア経営者として、どこから学び始めるのがおすすめですか？
A. この記事のアクション①（APIキー分離）を今日やり、アクション②〜⑥を1週間〜1ヶ月で順番に実装するのが現実的な最短コースです。体系的に学びたい場合は、AI鬼管理のClaude Code伴走支援で、設定レビュー・事故予防・社員教育までまとめて整備するのが効率的です。1人で全部調べるより、既に事故事例を持っている人に伴走してもらう方が数倍速く安全に到達できます。
Q. 1人会社・フリーランスですが、そこまで厳密にやる必要はありますか？
A. 「厳密に」ではなく「自分のミス前提で守る」視点で必要最低限を固めましょう。具体的にはSection 6-Aの30日プラン（APIキー棚卸し・オフサイトバックアップ多重化・全承認モードオフ・合言葉ルール）の4点だけで十分です。1人だからこそ、自分が事故を起こした時に助けてくれる人がいません。復旧できる備えを優先する、というのが1人事業者のセキュリティの本質です。
Q. 士業（税理士・社労士）ですが、Claude Codeを業務で使うのはそもそも問題ありませんか？
A. 使用自体は問題ありませんが、顧客の個人情報・財務情報を扱う性質上、Section 6-「業種別」で挙げた注意点を徹底する必要があります。最低限、(1)シャドウAI完全禁止、(2)API経由利用で学習に使われないモードに固定、(3)顧客別フォルダの権限分離、(4)業務委託契約の守秘義務条項にAI利用を明記、の4点は必須です。不安がある場合は業界団体（日税連・連合会）のAIガイドラインも併せて確認してください。
Q. 社員にシャドウAIを使わせないためには、どんなルールを作れば良いですか？
A. 「禁止リスト」より「承認済みホワイトリスト」の方が機能します（Section 6-Bの30日プランでも推奨）。社内で利用OKのAIを明示し（例：Claude、Claude Code、ChatGPT Enterprise、Gemini for Workspace）、それ以外は事前申請制に。同時に、「承認リストにないと困るケース」の申請フローを軽量化しておくと、無理に禁止する必要がなくなります。運用が続くホワイトリストのコツは「3ヶ月に1回は追加申請がある」ぐらいの更新頻度を保つこと。固定化すると形骸化します。
Q. 外注エンジニアが納品したツール、自分で中身が読めないのですがどうすれば？
A. Section 7の失敗③で触れた通り、Claude Code自身にレビューさせるのが最も実用的です。納品物のフォルダを開いて「このコードにAPIキーハードコード・バックドア・外部送信処理・過剰な権限要求がないかレビューして」と指示するだけ。1分で終わります。さらに厳密にやりたい場合は、月1万円程度から受けられる外部セキュリティレビューサービスもあります。AI鬼管理では、外注納品物のセキュリティ監査もまとめて伴走可能です。
Q. インシデントが実際に起きてしまった場合、何から動けばいいですか？
A. 順序は、(1) 被害拡大の停止（該当APIキーの即時無効化・該当アカウントのログアウト全端末）、(2) 被害範囲の特定（何が漏れた・消えた・送信されたかをリスト化）、(3) 関係者への連絡（顧客・取引先・必要に応じて個人情報保護委員会）、(4) 再発防止策の策定——この順番が鉄則です。(1)(2)を同時並行でやるために、Section 7の失敗⑤で触れた「紙のエスカレーション手順書」を事前に作っておくのがポイント。事後に調べながらでは絶対に間に合いません。
AI鬼管理へのお問い合わせ
この記事を読んで気になった方へ。
AI鬼管理の専門スタッフが、御社に最適な
業務自動化プランを無料でご提案します。
