-- Views
February 21, 26
スライド概要
OWASP Sendai Day 2026のトークセッション
LLMで開発する時代のセキュリティ 入門編 速さの裏にあるリスクと、開発環境のガードレールで守る方 法 Azara | X: @a_zara_n | GitHub: a-zara-n 2026.02.21 OWASP Sendai Day 2026 01
CAREER 2021年 セキュリティベンダー入社。脆弱性診断・AWS / GCP クラウドセキュリティ診断などの プロフェッショナルサービス業務に従事。クラウドセキュリティ診断サービスの立ち上げ・リサー チ・講演活動を行う。 Azara / Norihide Saito セキュリティエンジニア SELECTED TALKS 2025 AVTokyo — From Browser to Cloud Administrator(Cognito XSS → 特権昇格) 2025 BSides Tokyo — MCP Security introduction 2025 セキュリティ・ミニキャンプ 広島 — 設計・開発・テストにおけるセキュリティ実践 2024 BSides Las Vegas — Content-Type-based attack research 🌐 海外 2024 JSAC (JPCERT/CC) — クラウドインフラへの攻撃とログ調査デモ 24-25 セキュリティキャンプ全国大会 — 講師(2024・2025) 2023 AWS Dev Day — S3・Cognito・Lambda のアンチパターンとセキュリティ・バイ・デザイン COMMUNITY & RECOGNITION Security JAWS — 講演・CTF 作問 セキュリティ・キャンプ — 講師 CloudSec JP — 立ち上げ・運営 AWS Community Builder 2025(Security) FOCUS クラウドセキュリティ @a_zara_n オフェンシブセキュリティ LLM / AI 開発 Web セキュリティ a-zara-n 02
Agenda — リスクを知る — LLMを使った開発の現在地 メリットとデメリット 最近の危ない事例集 なぜ危ないのか — LLMの構造的特性 — 守り方を学ぶ — ガードレール思考 — 3層で自動的に守る 設計と技術負債の加速 開発環境の隔離とデータ管理 — まとめ — まとめ 01 02 03 04 01 02 03 01 03
01 LLMを使った開発の現在地 2021年から2025年にかけて、AIコーディングツールは4つのフェーズで進化し た 01 02 コードの続きを提案するだけでなく、ファイル操作・コマンド実行を自律的にこなすエージ ェントへ 外部サービス・他のLLMとの接続が可能になった新世代のワークフロー 補完型 → エージェント型 MCP連携で外部ツールと協調 04
AIコーディングツールの進化 01 現状と特性 02 リスクと事例 03 対策・ガードレール 2021 2024 補完型 エージェント型 GitHub Copilot コードの続きを提案 Cursor, Windsurf ファイル操作・コマンド実行 2023 チャット型 ChatGPT, Claude.ai 対話でコードを生成 2025 エージェント型 + MCP Claude Code, Codex CLI MCP(外部ツール・LLM間接続 規格)連携 05
エージェント型ツールの特徴 01 現状と特性 02 リスクと事例 03 対策・ガードレール 従来の「コード補完」とは根本的に違う エージェント型が「できること」 ファイルシステムへの読み書き シェルコマンドの実行 複数ファイルにまたがる変更 テストの実行と結果に基づく修正 外部ツール連携(MCP: LLMと外部サービスを接続する標準規格) LLMに「手足」が生えた 考えるだけでなく、ファイルを触り、コマンドを叩き、外部と通信できる。これは革命的な 変化であり、開発の生産性を根本から変える。 ユーザーが「作って」と言えば、ファイルを読み、コードを書き、テストを実行し、修正ま で自律的に完了させる。 そして、これが新しい課題を生むことになる。 ※ MCP (Model Context Protocol): Anthropicが提唱。LLMが外部ツール・データ・他のLLMと連携するための 標準規格。 06
02 メリットとデメリット 速さの恩恵と、その裏に隠れたコスト 01 02 プロトタイピング・定型作業の自動化。アイデアから動くコードまでの時間が桁違いに短縮 される エージェントがマシン上で自律動作することで、従来は存在しなかったリスクが発生する 開発速度の劇的な向上 新たな攻撃面の出現 07
メリットとデメリット 01 現状と特性 02 リスクと事例 03 対策・ガードレール メリット 言語化できれば初速が速くなった 考えたこと・やりたいことさえ言葉にできれば、あとはエージェントが動く デメリット 「動くコード」≠「正しいコード」 プロトタイピング速度の劇的向上 コンパイル・テストは通るが、セキュリティ・設計に問題のあるコードが量産される リスク 不慣れな技術スタックへの参入障壁低下 生成されたコードの意図や設計判断を開発者が十分に理解しないまま取り込む アイデアから動くコードまでの時間が桁違いに短縮 知らないフレームワークでも、エージェントが補助しながら進められる 定型作業の自動化 テスト生成・リファクタリング・ドキュメント作成などの反復作業を委譲 → 「作る速さ」が根本的に変わった ブラックボックス化 人間が知らないこと(認知負債) 今後の脆弱性・セキュリティ課題の根幹になり得る 新たな攻撃面の出現 エージェントがマシン上で自律動作することで、従来は存在しなかったリスクが発生 する → 「知らないこと」のツケが、セキュリティリスクになる 08
03 最近の危ない事例集 公開スキルの3つに1つに穴がある 01 スキルのサプライチェーン 攻撃 Claude Code スキルの武器化・ ToxicSkills包括監査・CVE — スキルエ コシステム全体が攻撃面になっている 02 03 AI生成コードの約45%にセキュリティ欠 陥。SQLi・XSS・ハードコード秘密鍵 が量産される IDE経由でコンテキストに混入した .env が外部に流出。複数の主要ツールでCVE またはセキュリティ警告が報告 LLM生成コードの脆弱性 認証情報の漏洩 04 OpenClaw — 21,000イ ンスタンスが露出 セルフホスト型エージェントの93.4%が 認証バイパス状態でインターネットに露 出 09
公開スキルの3つに1つに穴がある 01 現状と特性 02 リスクと事例 03 対策・ガードレール 36.8% AIエージェント向けスキルのうち セキュリティ欠陥が見つかった割合 (2026年2月時点) 皆さんが今日からインストールしよう としているものの3つに1つに穴があ る。 うち13.4%はクリティカルレベル。76件は確認 済みの悪意あるペイロード。 出典: Snyk ToxicSkills Report (2026年2月5日) / 調査対象: ClawHubおよびskills.shに公開されている3,984スキル 10
事例1-A: Claude Code Skillsの武器化 01 現状と特性 02 リスクと事例 03 対策・ガードレール デメリット該当: ④ 新たな攻撃面の出現 1 正規スキルを改変 2 ユーザーが承認 3 見えるコードは無害 4 setup.shをダウン ロード 5 実行(審査なし) 外部コードをDL・実行する関数 をひっそり追加 一度だけ承認すると以降は確認 なしに実行可能 ユーザーには無害なMarkdown のみが見える。実際に実行され るshellコードはそこに含まれて いない 外部サーバーからランサムウェア 本体を取得 GIF完成と同時に、裏ではファイ ルが暗号化済み 構造的問題:スキルは一度承認されると、以降の確認なしにファイル操作・追加コードのDL・外部接続を実行可能。npmの悪意あるパッケ ージと同じ構造。 ▶ あなたの現場では: Claude Code や Cursor にスキルを追加する前に、SKILL.md の内容を確認しましたか? npm の知らないパッケージを入れないの と同じ基準を適用してください。 Tips: Anti AI マルウェア マルウェア自体がAIセキュリティスキャナを騙すためにプロンプトインジェクションを埋め込む手法がすで に実際に観測されている(Check Point Research, 2025年6月)。AIが「無害」と誤判定するよう設計された新 世代の回避技術であり、AIを使ったセキュリティ対策もすでに攻撃対象になっている。 出典: Cato Networks — MedusaLocker via Skill 出典: Cato Networks (2025年12月3日) / Axios独占報道 (2025年12月2日) — Anthropic公式「GIF Creator」スキルをわずかに改変しMedusaLockerランサムウェアを実行 11
事例1-B: ToxicSkills — スキルエコシステムの汚染 01 現状と特性 02 リスクと事例 03 対策・ガードレール デメリット該当: ③ 人間が知らないこと(認知負債) ④ 新たな攻撃面の出現 調査規模 セキュリティ欠陥あり 確認済み悪意ペイロード 攻撃手法の特徴 3,984スキルを包括監査 ClawHub + skills.sh 1,467件(36.8%) クリティカル: 534件(13.4%) 76件 調査時点で8件は公開のまま放置 91%がプロンプトインジェクシ ョン+従来型マルウェアの複合 攻撃 2.9%が実行時に外部からコード を動的取得 2026年1月のスキル投稿数は1日50件未満。2月初旬には1日500件超(10倍増)。審査が追いつかない構造的問題。 出典: Snyk ToxicSkills Report 出典: Snyk ToxicSkills Report (2026年2月5日) — ClawHub・skills.sh(スキルの公開レジストリ、npmのようなもの)に公開されている3,984スキルを包括監査 12
事例1-C: Claude Code本体のCVE 01 現状と特性 02 リスクと事例 03 対策・ガードレール デメリット該当: ③ 人間が知らないこと(認知負債) 用語: CVE=脆弱性ID / CVSS=深刻度スコア(0〜10、9以上は緊急) / CWE=脆弱性種別 / RCE= 遠隔コード実行 CVE-2025-54794 — パス制限バイパス(CVSS v3.1: 9.1 / v4.0: 7.7) プレフィックスマッチングを使ったパス検証の欠陥により、作業ディレク トリ外のファイルにアクセス可能。プロンプトインジェクションと組み合 わせると重大化。パッチ済み(v0.2.111) CVE-2025-54795 — コマンドインジェクション(CVSS 3.1: 9.8 / v4 CNA: 8.7) コマンド解析の欠陥により確認プロンプトをバイパスし、任意コマンドを 実行可能。パッチ済み(v1.0.20) 出典: Cymulate InversePrompt 分析レポート いずれも修正済みだが、ツール本体にも脆弱性が存在するという事実が重 要。スキルだけでなく、ツール自体を常に最新版に保つ必要がある。 出典: Cymulate InversePrompt分析 (2025年8月4日) — いずれもパッチ済みだが、ツール本体にも脆弱性が存在するという事実が重要 13
事例2: LLM生成コードの脆弱性 01 現状と特性 02 リスクと事例 45% 03 デメリット該当: ① 「動くコード」≠「正しいコード」 AI生成コードに セキュリティ欠陥 (Backslash Security調査、複数モデル平均) 対策・ガードレール ② ブラックボックス化 上位の脆弱性パターン(CWE分 類) バッファオーバーフロー SQLインジェクション ハードコードされた認証情報 コマンドインジェクション XSS(クロスサイトスクリプティング) 不適切な入力値検証 / 暗号の誤用 Backslash Security調査(Infosecurity Magazine経由)/ 7モデル × CWE上位10種 / ナイーブなプ ロンプトで評価 参考: CrowdStrike Hidden Vulnerabilities in AI-Coded Software 以前より改善されてはいるが、セキュリティ要件を明示しない限り安全なコードは 生成されにくい。 ▶ あなたの現場では: LLMが生成したコードを、手書きコードと同じセキュリティ基準でレビュ ーしていますか? 出典: Infosecurity Magazine / Backslash Security調査 (2025年4月25日) / CrowdStrike: Hidden Vulnerabilities in AI-Coded Software (2025年11月20日) 14
事例3: 認証情報の漏洩 01 現状と特性 02 リスクと事例 03 対策・ガードレール デメリット該当: ③ 人間が知らないこと(認知負債) AIコーディングツールが秘密情報を漏洩するメカニズム 公開脆弱性 — ツール自体も攻撃対象 2025年12月、主要AIコーディングツール全体で30以上の脆弱性が一斉に報告された(The Hacker News)。LLMが生成するコードだけでなく、ツール自体が攻撃対象になってい る。代表的な3件を以下に示す(性質は異なる)。 IDE経由の漏洩 コンテキストウィンドウに .env の内容が載ると、外部APIへの送信に混入するリ スク Windsurf事例 リポジトリ内に仕込まれた悪意あるファイル経由でプロンプトインジェクションが 発動。プライベートコードと秘密情報が外部に流出 ツール OpenAI Codex CLI GitHub Copilot Cursor CVE CVE-202561260 CVE-202564660 CVE-202561590 主な影響 コマンドインジェク ション 不適切なアクセス制 御(RCE) コードインジェクシ ョン(RCE) ▶ あなたの現場では: 開いているエディタのコンテキストに .env や AWS キーが含まれていま せんか? 出典: Knostic (2025年11月26日) / The Hacker News: 30+ Flaws in AI Coding Tools (2025年12月6日) 15
事例4: OpenClaw — 安全でないデフォルト設計の危険 01 現状と特性 02 リスクと事例 03 対策・ガードレール デメリット該当: ④ 新たな攻撃面の出現 インターネット露出 認証バイパス状態 スキルレジストリ汚 21,000以上のイ ンスタンスが無 防備な状態でイ ンターネットに 露出 露出インスタン スの93.4%が認 証なしでアクセ ス可能な状態 悪意あるスキル 約800件(レジス トリの約20%) Censys観測 / 2026年2月 ClawdHunter v3.0 / 2026年2月 Snyk ToxicSkills Report / 2026年2月5日 ※ CVE-2026-25253(CVSS 8.8 / CWE-669): スキルレジストリへの不正リソース転送を可能にす る脆弱性 — Snyk / 2026年2月5日 出典: Bitsight / VentureBeat OpenClawは有用だ。AIエージェントが自律的にツールを呼び出 し・タスクを実行できる設計はAGI的なワークフローの実現にお いて強力であり、GitHubスター18万超・コミュニティで急速に普 及した理由がある。 だからこそ攻撃者に狙われる。普及度が高い=露出インスタンス が多い=単一のスキャンで大量のターゲットを得られる。有用な ツールは攻撃者にとっても価値が高い。 出典: Censys(21,000露出)/ Maor Dayan / ClawdHunter(93.4%)/ Snyk(800件)/ VentureBeat (2026年1月31日) / Bitsight (2026年2月9日) / CrowdStrike (2026年2月4日) / Infosecurity Magazine (2026年2月19日) — 各数値は調査主体・時点が異なる 16
04 なぜ危ないのか LLMの構造的特性 01 02 セキュリティ要件を明示しない限り、LLMはそれが「存在しない」として扱う LLMは学習データ範囲でしか回答できない。さらにコードの出所が人間・LLM・外部スキル の混在になり、信頼境界が不明確になる 「言わないことはやらない」 人間の知識が上限 / 信頼境界の曖昧化 17
特性1: 「言わないことはやらない」
01
現状と特性
02
リスクと事例
03
対策・ガードレール
新入社員に「ユーザー管理APIを作って」とだけ言って、認可チェックまで実装してくれる 詳細な指示:「削除APIを実装して。管理者ロール必須、自己削除は403、論理
と思いますか? 人間と同じで、言わなければやりません。
削除でdeletedAtに日時を入れて」
曖昧な指示:「ユーザー管理APIを作って」
// 認可チェックなし
app.delete('/api/users/:id', async (req, res) => {
// ← ここに requireRole('admin') が必要 // [!code warning]
// ← ここに自己削除チェックが必要 // [!code warning]
await db.user.delete({
where: { id: req.params.id }
});
res.json({ success: true });
});
// → 誰でも任意のユーザーを削除できる
app.delete('/api/users/:id',
requireRole('admin'), // [!code hl]
async (req, res) => {
if (req.params.id === req.user.id) { // [!code hl]
return res.status(403).json({
error: 'Cannot delete yourself'
});
}
await db.user.update({ // [!code hl]
where: { id: req.params.id },
data: { deletedAt: new Date() } // [!code hl]
});
res.json({ success: true });
}
);
// → 要件どおりの安全な実装
18
特性2・3: 人間の知識が上限 / 信頼境界の曖昧化 01 現状と特性 02 リスクと事例 03 対策・ガードレール 特性2: 人間の知識が上限 LLMは学習データの範囲で回答する。最新の脆弱性パターンやプロジェクト固 有のセキュリティ要件は知らない。 SQLi・XSS など有名パタ ーン 新しい攻撃手法・ゼロデ イ ビジネスロジック固有の 欠陥 状況 出力しにくくなってきた ✓ 学習データにないため対応でき ない ✗ そもそも仕様を知らない ✗ 特性3: 信頼境界の曖昧化 従来の開発 コードを書くのは人間 レビュー範囲が明確 信頼境界が明確 LLM開発 人間・LLM・外部スキルの混在 誰が何を信頼しているか不明確 信頼境界が曖昧 事例集のすべてはこの「信頼境界の曖昧化」から発生している。 セキュリティを理解している人 → 強力なツール セキュリティを理解していない人 → 脆弱性に気づけないまま本番に出る 「LLMがセキュリティを担保してくれる」は幻想。 19
05 ガードレール思考 3層で自動的に守る 01 02 03 Hooks / notify — LLMが「やらかす前」に止める最初の 防衛線 Semgrep + gitleaks — commit/push時に必ず通るゲー ト Nx module boundary rules — 設計レベルで「壊れた依 存」を自動検知 LLMツール固有 git hooks(ツール非依存) アーキテクチャ制約 20
3層ガードレールの全体像 01 現状と特性 02 リスクと事例 03 対策・ガードレール どのツールが書いたコードでも、3層のどこかで必ず止まる多層防御。重要なのは1つを完璧にすることではなく、重ねて穴を塞ぐこと。 LLMが生成した コード › ① LLMツール固有 ① ツール固有 ツールを変えると効かなくなる。ツール非依存の層と組み合わ せて使う。 Hooks / notify 実行前ブロック › ② git hooks Semgrep / gitleaks commit ゲート › ③ アーキテクチャ制約 モジュール境界ルール 設計レベル自動検知 ② git hooks 人間が書いたコードにも効く。今日から始めやすい最初の一 手。 › 本番環境へ ③ アーキテクチャ 導入コストは高いが最も根本的。設計段階で壊れた依存を弾 く。 各層の詳細は次のページ以降 → 21
ツール固有 × git hooks 01 現状と特性 02 リスクと事例 03 対策・ガードレール ツール固有の制御とツール非依存のgit hooksを組み合わせることで、LLMが何を使っていても必ずどこかで止まる多層防御を構成できる。 LLMツール固有 ツール Claude Code Hooks Codex notify git hooks(ツール非依存) 仕組み で 書き込みをブロッ ク/ で Semgrep を自動実行 自律実行の結果を人間が確認してからマー ジ PreToolUse .env PostToolUse ツール依存なので、ツールを変えたら効かなくなる点に注意。 ツール Husky Semgrep gitleaks lint-staged 役割 git hooks の管理 SQLi・XSS・ハードコード秘密鍵の検知 認証情報の混入検知 変更ファイルのみに絞って高速実行 LLMツールが何であっても、git commit の瞬間に必ず通るゲート。 22
アーキテクチャ制約 01 現状と特性 02 リスクと事例 03 対策・ガードレール LLMは「動くコード」を生成するが、「依存方向を守るコード」は意識しない ツール Nx module boundary rules ESLint import rules ArchUnit 対象 JS / TS Deptrac JS / TS Java / Kotlin PHP dependency-cruiser 言語非依存 役割 モジュール間の依存方向を定義し、違反をCIで検 知 禁止されたインポートパスを検出 レイヤー・依存方向ルールをJUnitテストとして定 義・強制 レイヤー定義と依存ルールをYAMLで設定・CI で 強制 依存グラフを可視化・検証(JS・TS・Java 等) LLMが量産する典型的な違反例: domain 層に外部ライブラリへの依存が混入 infrastructure が application 層をスキップして domain を直接操作 循環依存の発生 設計をコードで表現し、自動で強制する仕組みが不可欠。 23
アーキテクチャ制約 01 現状と特性 02 リスクと事例 03 対策・ガードレール CLAUDE.md — 制約を「常に読み込まれるルール」として宣言する CLAUDE.md の仕組み プロジェクトルートの CLAUDE.md は Claude Code が自動で読み込む .claude/CLAUDE.md やサブディレクトリの CLAUDE.md も対象 毎回プロンプトで伝えなくても、常にルールとして適用される 記載すべき制約の例 アーキテクチャ: domain 層は外部ライブラリに依存しない セキュリティ: 秘密鍵はハードコード禁止、環境変数必須 ビジネスロジック: 金額計算は Decimal 型を必ず使用 禁止パターン: eval() / innerHTML の直接使用禁止 # CLAUDE.md(プロジェクトルート) ## アーキテクチャ制約 - domain 層は infrastructure に依存しない - 循環依存は禁止 ## セキュリティ要件 - 秘密鍵・APIキーはハードコード禁止 - SQL は必ずプリペアドステートメント - 認可チェックはミドルウェア層で実施 ## ビジネスロジック - このシステムは B2B 決済サービス - 金額計算は Decimal 型を必ず使用 - 取引履歴は 7 年間保持が法的要件 コードレベルの強制(Nx / ESLint / ArchUnit)と組み合わせる 生成段階(CLAUDE.md)+ コミット段階(git hooks)+ CI 段階(コード検証)で多層防御 24
06 設計と技術負債の加速 LLMは「速く」書く。だが「正しく」書くかは設計次第 01 02 「考える時間」を省略してコードを出す。設計なしに使うと、負債が従来の開発より加速度 的に蓄積する コードを書く人から、制約を定義しLLMの議論を舵取りする人へ 設計なしのLLMは技術負債を加速させる 人間の役割の変化 25
設計なしのLLMが加速させる技術負債 01 現状と特性 開発速度 思考プロ セス アウトプ ット 認知負債 02 リスクと事例 03 対策・ガードレール 従来の開発 ゆっくり書く 書く過程で認可・バリデーション・秘密鍵管理 を自然に検討 安全なコード LLMによる開発(設計なし) 高速生成 「考える」ステップが省略される 書いた人が理解している 生成コードを理解しないままマージ → 誰も把握できないコ ードが蓄積 SQLi・認可不備・秘密鍵ハードコードが混入する可能性 認知負債とは:生成コードを十分に理解しないままマージし続けることで「誰もシステム全体を把握していない」状態が蓄積し、将来のセキュリティイン シデントの温床になる。 対策の核心:LLMにコードを書かせる前に、人間が設計・セキュリティ要件・アーキテクチャ方針を文書化する 26
07 開発環境の隔離とデータ管理 機微情報とLLMエージェントを同居させない 01 02 03 開発作業をEC2上で行い、ローカルマシンと分離。IAMで 制御、破棄可能な環境 ローコストなセキュアアクセス。ポート開放不要でApple Silicon環境をそのまま活用 最も手軽に始められる環境分離。LLMの操作範囲をコン テナ内に限定し、ホストのファイルシステムと分離する AWS EC2でクラウド隔離 Mac Mini + Cloudflare Tunnel Dockerコンテナで分離 27
開発環境の隔離:3つのアプローチ 01 現状と特性 02 リスクと事例 03 対策・ガードレール LLMエージェントには、タスクに必要な情報と権限だけを与えるのが基本原則だ。本番DBの接続情報・SSHキー・VPN設定を開発マシンに同居させない。万が一ツールが 騙されても、アクセスできる範囲を最小化しておけば被害は限定される。 方法1: AWS EC2 方法2: Mac Mini 方法3: Docker コンテナ ✓ マシンスペックの柔軟な調整 ✓ IAM で機微情報のアクセス制御 ✓ 汚染されたら即破棄・再構築 ✓ 本番 VPC と完全分離 ✓ Apple Silicon 環境そのまま活用 ✓ EC2 よりランニングコスト低 ✓ ポート開放不要(Identity-based) ✓ MLX 等ローカルモデル実行向き ✓ LLM の操作範囲をコンテナ内に限定 ✓ ~/.ssh / ~/.aws をマウントしない設計 ✓ 軽量・高速・破棄可能 ✓ devcontainer で CI/CD と一体化 接続: SSM / Tailscale コスト: インスタンス費用(使用時のみ) 接続: Cloudflare Tunnel コスト: Mac Mini 本体(買い切り) 接続: devcontainer / Docker Desktop コスト: 無料(Docker Desktop は個人無料) クラウド完全隔離 — エンタープライズ向け ローカルサーバー分離 — 個人・スタートアップ向け 最も手軽 — 今日から始められる Docker 実践例: docker run --rm -it --network none -v $(pwd)/code:/workspace mydev-image — コードだけをマウントし、 ~/.ssh や ~/.aws を渡さない。 --network none で外部通 信も遮断。プロンプトインジェクションが発動しても被害はコンテナ内に封じ込められる。 共通原則: ローカルPCに機微情報を置かない / 開発環境と日常環境を分離する / プロンプトインジェクションが成功しても被害範囲をコンテナ・VMに封じ込める 28
08 まとめ 今日持ち帰ってほしい4つのこと 29
4つの持ち帰りメッセージ 1. LLMは「言わないことはやらない」 セキュリティ要件と設計方針は明示的に文書化し、LLMに渡す。暗黙知に頼る開発はザルになる。 2. ガードレールは3層で敷く LLMツール固有(Hooks=実行前検査 / notify=安全確認)+ git hooks(Semgrep=コード脆弱性検査 / gitleaks=秘密情報漏洩検出)+ アーキテクチャ 制約(Nx 等)。人間のレビューだけではLLMの出力速度に追いつけない。 3. 機微情報とエージェントを同居させない エージェントはローカルで自律動作する。EC2やMac Miniで開発環境を分離し、本番データ・VPN接続とLLMの操作範囲を切り離す。 4. 人間の役割は変わる コードを書く人から、制約を定義しLLMの議論を舵取りする人へ。設計力と文章力がこれまで以上に重要になる。 LLMは使い続けるべきツールです。だからこそ、ガードレールを先に敷く。 30
今日から24時間以内にできること 01 現状と特性 02 リスクと事例 03 対策・ガードレール Step 1 — gitleaks を pre-commit に入れる(所要: 約30分) 秘密情報(APIキー・パスワード)のコミット漏洩を自動検出。まずこれだけでいい。 ① brew install gitleaks | その他: バイナリを PATH に置く ② printf '#!/bin/sh\ngitleaks git --pre-commit --staged\n' > .git/hooks/pre-commit && chmod +x .git/hooks/pre-commit Step 2 — CLAUDE.md / spec にセキュリティ要件を1行書く(所要: 5分) 「認可チェックを必ず実装すること」だけでも LLM の出力品質が変わる。 Step 3 — 開発マシンの .env と本番接続情報を棚卸しする(所要: 10分) 「何がローカルにあるか」を把握するだけで、LLM エージェントへの露出リスクが見えてくる。 31
Q&A 32
参考文献 ★ = 特に読んでほしい一次資料 スキル / サプライチェーン攻撃 ★ Snyk: ToxicSkills — Malicious Agent Skills Supply Chain Compromise — 2026年2月5日 ★ CrowdStrike: Hidden Vulnerabilities in AI-Coded Software — 2025年11月20日 The Hacker News: 30+ Flaws in AI Coding Tools — 2025年12月6日 OpenClaw関連 ★ Cato Networks: Weaponizing Claude Skills with MedusaLocker Conscia: The OpenClaw Security Crisis(93.4% auth bypass / Maor Dayan / ClawdHunt er v3.0) Cymulate: InversePrompt CVE-2025-54794 & CVE-2025-54795 — 2025年8月4日 VentureBeat: OpenClaw proves agentic AI works. It also proves your security model do esn’t. — 2025年12月2日 Bitsight: OpenClaw Security Risks(30,000+インスタンス観測) — 2025年12月3日 ★ Axios: Researcher tricks Claude into deploying MedusaLocker ransomware Snyk: From SKILL.md to Shell Access in Three Lines of Markdown — 2026年2月3日 LLM生成コードの脆弱性 / 認証情報漏洩 ★ Infosecurity Magazine: Popular LLMs Found to Produce Vulnerable Code by Default — 2025年4月25日 ★ Knostic: How AI Assistants Leak Secrets in Your IDE — 2026年2月18日 ★ — 2026年1月31日 — 2026年2月9日 CrowdStrike: What Security Teams Need to Know About OpenClaw — 2026年2月4日 Cyberpress: Over 21,000 OpenClaw AI Instances Found Exposing(Censys観測) — 2026年2月2日 Infosecurity Magazine: Researchers Reveal Six New OpenClaw Vulnerabilities — 2026年2月19日 — 2025年11月26日 33