2026 年 5 月、InfoQ が GitHub Enhances CodeQL with Declarative Security Modeling for Faster, More Flexible Analysis を公開し、CodeQL に宣言型のセキュリティモデルが導入され、SAST（静的アプリケーションセキュリティテスト）のクエリ作成・更新が 従来の 5 〜 10 倍速になることが発表されました。これまで「専任のセキュリティエンジニアでないと書けない」と言われた CodeQL クエリが、受託の現場で運用できる現実的な領域に入ったと言えます。
弊社では、SaaS / 業務システム / EC など機微情報を扱う受託案件で SAST を案件横断で組み込む取り組みを進めています。本記事では、CodeQL の宣言型モデルを受託で運用する設計指針、案件横断のセキュリティ知見再利用、契約条項を整理します。
何が変わったのか
CodeQL の宣言型セキュリティモデリングは、以下の 3 つの根本的な変化をもたらします。
| 項目 | 旧 CodeQL | 宣言型モデル |
|---|---|---|
| クエリ記述 | 手続き的に書く | YAML で意図を宣言 |
| 学習コスト | 数週間〜数ヶ月 | 数日 |
| 言語横断 | 言語ごとに書き直し | 同一モデルで複数言語 |
| カスタマイズ | 上級者向け | 受託エンジニアでも可能 |
特に 「言語横断」が大きな変化で、TypeScript / Python / Go / Java / C# を 1 つの脅威モデルでカバーできる点は、複数言語が混在する受託案件で強い武器になります。
これは ソースコード secrets 監査を受託で運用する で扱った “案件横断のセキュリティ自動化” と同じ方向性で、「クエリが書けない」という参入障壁が下がったことの意味は大きいです。
受託で組む CodeQL 運用の 4 階層
弊社では、案件横断で CodeQL を運用するために以下の 4 階層を構築しています。
[Tier 1: 標準クエリセット]
├ OWASP Top 10 / CWE Top 25 を全案件適用
├ 認証 / セッション / 入力検証 / SSRF / SQLi
└ 月次でアップデート
[Tier 2: 業界別クエリセット]
├ EC: 決済 / 在庫操作 / 個人情報マスキング
├ 医療: HIPAA 相当 / アクセスログ強制
├ 金融: PCI-DSS 相当 / 監査ログ
└ SaaS: テナント分離 / RBAC
[Tier 3: 顧客固有クエリ]
├ 顧客固有の脅威モデルを宣言型でモデル化
├ 案件専用 GitHub Org に配置
└ ペアプロでセキュリティチームと共同作成
[Tier 4: 自動修正 PR]
├ 検出 → 修正 PR 自動作成
├ 人間レビュー必須のラベル付与
└ 修正パターンを Tier 1 〜 2 に逆輸入特に Tier 4 の自動修正 PR は、Claude Code Auto Mode との組み合わせで実装難度が劇的に下がりました。これは Claude Code Auto Mode を受託で安全運用する で扱った Approval Gates の仕組みを、「セキュリティ修正」という最も承認が必要な領域に適用した形です。
案件横断のセキュリティ知見を「資産化」する
宣言型モデルの最大の利点は、セキュリティ知見を企業の知的資産として蓄積できることです。弊社では以下の運用を標準化しています。
| 知見の種類 | 蓄積先 | 共有範囲 |
|---|---|---|
| 業界共通の脅威モデル | 共有リポジトリ | 全案件 |
| 言語固有のパターン | 言語別パッケージ | 該当言語の全案件 |
| 顧客固有のクエリ | 案件専用リポ | 該当案件のみ |
| ベストプラクティス | 社内ドキュメント | 全エンジニア |
特に 「業界共通の脅威モデル」は 「EC 業界向けにセキュリティを強化したい」といった案件で、初期構築コストを 1/3 に圧縮します。これは受託の 「過去案件の知見を新規案件に再利用する」コア競争力を、CodeQL の宣言型モデルがそのまま機械可読化してくれる構造です。
受託契約に書く「SAST 運用条項」
CodeQL を案件に組み込む受託契約では、以下の条項を明記します。
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| 対象スコープ | リポジトリ・ブランチ・除外パス | 既存コードの扱い |
| クエリセット | 標準 + 業界 + 顧客固有の組み合わせ | 業界クエリの妥当性 |
| 検出時 SLA | High / Medium / Low の対応期限 | 期限の現実性 |
| 自動修正 PR | 自動 PR の生成範囲と承認者 | 承認権限者の指名 |
| 誤検知の扱い | False Positive のチューニング責任 | 改善ループ |
| 月次レポート | 検出件数 / 修正済 / 未対応 | レポート形式 |
特に 「検出時 SLA」は最初に明文化しないと、「そのうち直します」が永続化します。High = 24h、Medium = 7 営業日、Low = 30 日といった具体数値で合意します。
これは AWS セキュリティエージェントによる継続的ペンテスト で扱った継続的セキュリティと同じ思想で、「検出すること」より「期限内に対応すること」を契約の本体にします。
価格モデル — CodeQL 運用を含めた受託パッケージ
CodeQL 運用を含めた受託パッケージは、以下のレンジで提供しています。
| プラン | 初期 / 月額 | 対象 | 内容 |
|---|---|---|---|
| SAST Lite | 50 万円 / 8 万円〜 | 既存案件への後付け | Tier 1 標準クエリ + 月次レポート |
| SAST Standard | 180 万円 / 25 万円〜 | 中小企業の業務システム | Lite + Tier 2 業界クエリ + Tier 4 自動修正 PR |
| SAST Enterprise | 500 万円〜 / 75 万円〜 | 上場・規制業界 | Standard + Tier 3 顧客固有 + 24h 検出対応 |
特に SAST Standard は 「セキュリティチームを内製せずに継続的 SAST を回したい」中小企業の典型的なニーズに刺さるレンジです。
ハマりやすい 5 つの落とし穴
最後に、CodeQL を受託で運用するときに踏みやすい落とし穴を共有します。
落とし穴 1: 検出だけして修正フローがない
「検出件数」だけを KPI にすると、修正が後回しになり脆弱性が積み上がります。修正完了率を主 KPIにし、検出件数は副次指標とします。
落とし穴 2: 全案件に同じクエリを適用
EC 案件と業務システム案件では脅威モデルが違います。全案件一律のクエリは、ノイズと見落としを同時に生みます。Tier 2 の業界クエリを必ず適用します。
落とし穴 3: 誤検知のチューニングを怠る
False Positive を放置すると、開発チームが警告を無視する文化が定着します。誤検知 → クエリ調整 → 配信 のループを 2 週間以内に回します。
落とし穴 4: 自動修正 PR を即マージ
Claude Code が生成した修正 PR を 「セキュリティ修正だから即マージ」するのは危険です。最低 1 人の人間レビュー + テスト合格を必須にします。
落とし穴 5: 顧客 PM がレポートを見ない
弊社だけがレポートを見る運用は、重大脆弱性の発覚が遅れます。月次でレポートを顧客 PM と一緒に振り返るミーティングを契約に組み込みます。
まとめ — 「セキュリティ専任が書く」から「受託が運用する」へ
CodeQL の宣言型セキュリティモデリングは、「専門家しか書けない SAST」から 「受託エンジニアが運用できる SAST」への転換点です。受託の現場で 「業界横断の脅威モデルを資産化する」という競争力を、宣言型モデルが現実のものにしました。
弊社では SAST Lite / Standard / Enterprise の 3 段階で CodeQL を組み込んだ受託パッケージを提供しています。「セキュリティ監査を継続的に回したい」「脆弱性検出はあるが修正フローが回らない」というご相談は お問い合わせフォーム からお気軽にどうぞ。
