2026 年 5 月 23 日、Zenn に AI コーディングエージェントの本当の攻撃面は設定ファイルだった が公開され、開発者コミュニティで大きな反響を呼びました。TrustFall / Kiro RCE など 2026 年に表面化した AI コーディングエージェントのセキュリティ事故は 「LLM の出力が悪意ある」のではなく .cursor/ .kiro/ .continue/ .claude/ などの設定ファイルが RCE / クレデンシャル窃取の入り口でした。著者はこれらを OSS ツール Sigil で検査可能にする取り組みも紹介しています。
受託で中堅企業の AI コーディングエージェント導入を支える立場では、これは 「LLM ガードレールばかり気にして、足元の dotfile が無防備」という典型課題に、最初に塞ぐべき具体的な攻撃面が明確化されたことを意味します。これまで AWS セキュリティエージェント Pentest 受託 で扱った クラウド側のエージェント攻撃面、Kubernetes 自律 AI エージェントセキュリティ受託 で扱った 本番ランタイム保護、Mini Shai-Hulud npm Worm IR 受託 で扱った OSS サプライチェーン、GitHub 内部リポ侵害 + VSCode 拡張受託 で扱った 開発者エンドポイント統治とは、全く別ベクトルの脅威モデルです。本記事は 「dotfile / 設定ファイル系の攻撃面」を 組織導入前に塞ぐ受託パッケージを整理します。
なぜ「設定ファイルが真の攻撃面」なのか
| 観点 | LLM 出力経由（想定済み） | 設定ファイル経由（盲点） |
|---|---|---|
| 侵入口 | プロンプトインジェクション | .cursor/ .kiro/ の任意設定 |
| 脅威 | データ漏洩 / 誤回答 | RCE / クレデンシャル窃取 |
| 発動条件 | 人間が悪意ある質問送信 | リポジトリ clone のみで発動 |
| 既存対策の効果 | ガードレール / 監視 | ほぼ無効 |
| 検知の難しさ | プロンプト履歴で追跡可 | dotfile 変更が見過ごされやすい |
| 影響範囲 | 当該セッションのみ | 開発者端末全体 |
| 悪用される心理 | 攻撃者目線で利用 | 「設定」だから信頼してしまう |
つまり AI コーディングエージェントの dotfile 群は 「実行コードを内包する設定ファイル」であり、OSS サプライチェーン攻撃の新しい主戦場になりました。
受託案件で活きる 3 つの構造変化
構造 1: 「LLM ガードレール一辺倒」から「dotfile 監査」へ
これまで AI コーディングエージェント導入時のセキュリティ議論は 「LLM プロンプト / 出力のガードレール」に集中していました。Sigil 系ツールによる dotfile / 設定ファイル監査は 「LLM が動く前段」を構造的に塞ぎます。これは GitHub 内部リポ侵害 + VSCode 拡張受託 で扱った 開発者エンドポイント統治を、dotfile レイヤまで拡張するステップです。
構造 2: 「個人ベースのエージェント導入」から「組織標準の設定ファイル統治」へ
エンジニア個人が Cursor / Claude Code / Continue / Gemini CLI を自由に導入し、各自の dotfile を書く現状は、組織として攻撃面が無秩序に拡大します。組織標準の 設定ファイルテンプレート + 監査 + 配布を確立することで、「許可された設定だけが動く」統制が可能になります。
構造 3: 「リポジトリ単体の信頼」から「dotfile 込みのリポジトリ信頼」へ
git clone した瞬間に リポジトリ内の .vscode/ .cursor/ .kiro/ が読み込まれる現代のエディタ / エージェントは、OSS リポジトリの dotfile が信頼境界になりました。これは Mini Shai-Hulud npm Worm IR 受託 で扱った 「npm install 任意実行」と同型の 「git clone 任意実行」問題です。
受託で提供する「AI コーディングエージェント設定ファイルハードニング」5 フェーズ
フェーズ 1: 現状診断（2 週間）
- 組織内で使われている AI コーディングエージェント棚卸し
- dotfile / 設定ファイルの種類 / 配置場所棚卸し
- 個人別 / プロジェクト別の設定差異把握
- 既存セキュリティポリシーとのギャップ分析
- Sigil 等の OSS ツールでの初期スキャン
フェーズ 2: ハードニング設計（2 週間）
- 組織標準 dotfile テンプレート策定
- 許可リスト / 禁止リスト（コマンド実行 / ファイルアクセス / ネットワーク）
- 開発者端末配布方式（dotfile マネージャ / IDE 設定同期）
- リポジトリ取り込み時の自動スキャン CI
- 異常検知ルール（Sigil + EDR 連携）
フェーズ 3: PoC 構築（2〜3 週間）
- パイロットチーム 10〜20 名で配布
- 既存リポジトリの dotfile スキャン
- 異常検知 / 通知フローの動作確認
- 開発者ヒアリング（利便性とのトレードオフ）
- 改善反映
フェーズ 4: 本番展開（3〜4 週間）
- 全社開発者への配布 + 強制適用
- CI に dotfile スキャンを必須化
- 監査ログ統合（EDR / SIEM）
- 緊急時の例外申請フロー
- 開発者向けトレーニング
フェーズ 5: 月次運用レビュー（継続）
- 新エージェント / 新 dotfile 形式への追従
- スキャン結果 / 異常検知件数のレビュー
- 許可リストの見直し
- 開発者フィードバック反映
- 新規脅威動向のキャッチアップ
受託向け技術スタック標準セット
| レイヤ | 推奨技術 | 代替 |
|---|---|---|
| dotfile スキャン | Sigil（OSS） | 自作 ESLint ルール |
| CI 統合 | GitHub Actions / GitLab CI | CircleCI / Jenkins |
| dotfile 配布 | chezmoi / yadm | dotbot |
| IDE 設定統合 | Settings Sync / Profile | 自前 dotfile 管理 |
| EDR / 監視 | CrowdStrike / SentinelOne | Microsoft Defender |
| SIEM | Splunk / Datadog / Sentinel | Elastic |
| シークレット検出 | TruffleHog / Gitleaks | Trivy |
| コンテナ Dev 環境 | Devcontainers / Codespaces | Coder |
どの案件に必要か / 不要か
| 必要な案件 | 不要な案件 |
|---|---|
| AI コーディングエージェント全社導入中 | 個人検証フェーズ |
| 開発者 30 名以上 | 5 名以下 |
| OSS リポジトリ多用 | 内製コードのみ |
| ISMS / SOC2 監査対応中 | 規制対象外 |
| 過去にサプライチェーン事故経験あり | 未経験（だが備えたい） |
受託契約に書く 6 つの条項
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| 対象エージェント | Cursor / Claude Code / Gemini CLI 等 | 利用状況の網羅 |
| 対象 dotfile 群 | .cursor/ .kiro/ .claude/ 等 | 個人設定の境界 |
| 強制適用範囲 | 全社 / 部門 / プロジェクト | 業務影響 |
| 例外申請プロセス | 申請 → レビュー → 期限付き許可 | 業務継続性 |
| 検知 → 通知 SLA | 検知〜通知時間 | インシデント体制 |
| 退場時引き渡し | テンプレート + スキャンルール + ランブック | 自社運用継続性 |
価格モデル — AI コーディングエージェント設定ファイルハードニングパッケージ
| プラン | 金額 | 対象 | 内容 |
|---|---|---|---|
| 診断 / PoC | 100 万円〜（4 週間） | 棚卸し + Sigil スキャン + ハードニング設計 | レポート + テンプレート |
| Lite | 35 万円〜 / 月 | 開発者 30〜80 | 月次レビュー + 新エージェント対応 |
| Standard | 75 万円〜 / 月 | 開発者 80〜200 | + 全 CI 統合 + EDR 連携 |
| Enterprise | 150 万円〜 / 月 | 開発者 200〜 | + 24h 監視 + 専任セキュリティエンジニア |
| 初期配布構築 | 280 万円〜（一括） | 全社 dotfile 配布 + CI 統合 | 全プラン共通オプション |
顧客側 ROI 試算（開発者 100 名 / リポジトリ 300 / Cursor + Claude Code 併用想定）
| 項目 | 既存（個人任せ） | ハードニング導入後 | 差分 |
|---|---|---|---|
| 設定ファイル経由 RCE 想定損害 | 1,800 万円 / 年 | 200 万円 / 年 | -1,600 万円 |
| クレデンシャル窃取想定損害 | 1,200 万円 / 年 | 150 万円 / 年 | -1,050 万円 |
| インシデント調査工数（年） | 480h | 80h | -400h |
| 監査対応工数（年） | 320h | 80h | -240h |
| 開発者教育工数（年） | 240h | 80h | -160h |
| 年間効果 | — | — | 約 3,300 万円相当 + 統制可視化 |
時給 8,000 円換算でも 年間 2,700 万円超の純削減効果。Standard プラン（年額 900 万円）でも 4 ヶ月以内で回収可能です。
ハマりやすい 5 つの落とし穴
落とし穴 1: 「dotfile は触らない文化」を放置
「個人の dotfile は触らない」を文化として残すと、統制が永遠にかかりません。業務利用するエージェントの dotfile は組織管理対象と契約 / 規程レベルで定義します。
落とし穴 2: 禁止リスト中心の運用
「危険なコマンドを禁止」では 新しい攻撃手法に追従できません。許可リスト（明示的に許す設定のみ）を運用方針とします。
落とし穴 3: CI スキャンを警告止まりにする
警告だけ出して CI を通してしまうと、結局誰も対応しません。スキャン違反は強制ブロック + 例外申請フローにします。
落とし穴 4: OSS リポジトリ clone 時の自動実行を放置
git clone → code . で dotfile が自動読み込み + 任意コマンド実行される現状を放置すると、OSS 依存しか使わない開発者でも被害を受けます。開発者端末の IDE 設定で「ワークスペース信頼」を必須化します。
落とし穴 5: 新エージェント追加時の追従漏れ
毎月のように新しい AI コーディングエージェントが登場します。月次キャッチアップ + テンプレート更新を契約に組み込みます。
90 日アクションプラン
| 週 | アクション |
|---|---|
| Week 1〜2 | エージェント / dotfile 棚卸し + Sigil 初期スキャン |
| Week 3〜4 | ハードニング設計 + 組織標準テンプレート策定 |
| Week 5〜7 | パイロットチーム配布 + 改善反映 |
| Week 8〜10 | 全社段階展開 + CI 統合 |
| Week 11 | EDR / SIEM 連携 + 監査ダッシュボード |
| Week 12〜13 | 開発者トレーニング + 月次運用レビュー立ち上げ |
まとめ — 「LLM ガードレールの前に、dotfile を塞ぐ」が新標準
AI コーディングエージェントの真の攻撃面は LLM 出力ではなく設定ファイルでした。受託で中堅企業の AI 開発統制を支える立場では、組織標準 dotfile + Sigil スキャン + CI 強制 + 月次更新を一体で設計する 「AI コーディングエージェント設定ファイルハードニング基盤」 が新しい主力サービスになります。
弊社では 診断 / Lite / Standard / Enterprise の 4 段階で本パッケージを提供しています。「Cursor / Claude Code を全社展開予定」「設定ファイル経由の事故が怖くて導入が止まっている」「ISMS / SOC2 監査で AI 開発統制を問われる」というご相談は お問い合わせフォーム からお気軽にどうぞ。
