テラスカイ系クオン、脆弱性の検知から修正案作成まで自動化へ

ニュースの要点

テラスカイのグループ会社クオンは2026年10月30日、システムの脆弱性の検知から、修正コードの取り込みを求める提案の作成までを自動化する「cuonology security」を、12月から提供すると発表しました。中堅・大企業の情報システム部門や、運用支援を担うセキュリティ会社を対象とします。

顧客自身のAWSとGitHubの環境で動かし、攻撃者の視点からの動的検査、課題の起票、別の開発基盤と連携した修正案の作成をつなぎます。担当者はコードのレビューと最終承認に注力する設計で、修正案の自動作成を、本番環境への自動適用とする説明ではありません。

目的は、検知後に残る人手の作業を減らすことです。対象のソースコード管理単位ごとの年間契約とサポート契約を基本とし、導入支援などは追加できます。価格や顧客での削減率は公表していません。

ニュース出典: Cuon・テラスカイ（当事者配信）「脆弱性「検知」から「修正PR作成」までを自動化 AIセキュリティソリューション「cuonology security」提供開始」（2026年10月30日）

イノベーション総研の考察

イノベーション総研は、検知した問題を知らせるだけでなく、修正の提案まで進める提供範囲に注目します。作業をつなぐほど、顧客の運用へ深く入れる一方、誤った変更を適用しないための確認が重要になります。自動化の終点と、人が責任を持つ工程を区別して読む事例です。

アラートを増やす仕組みから、直す作業へつなぐ

問題の発見と、顧客が修正を終えることの間に残る仕事を見ます。

今回の提供は、動的な検査、課題の起票、開発基盤と連携した修正案作成までを対象にします。ソースコードの取り込みを求める提案は、開発現場でプルリクエストと呼ばれるものです。提案を作ることと、確認を終えて本番へ反映することは別の段階です。

検知するだけでは、顧客に修正する人や時間がなければ問題が残ります。新規事業の担当者の方は、利用者が次に行う作業まで含めて提供範囲を考えられます。ただし、修正案を出す件数が増えても、人の確認が追いつかない場合があります。発見から提案までの速さだけでなく、最終的に適用された修正と、差し戻しの理由を追う必要があります。

AIへ任せる判断と、決めた手順で動かす処理を分ける

すべてを同じAIへ委ねず、後から判断の根拠を確認できる構成かを確かめます。

原典では、検知データの取得や振り分け、抑制、検証は、あらかじめ決めた規則に従うスクリプトが担います。言語モデルは優先度の判断と課題本文の生成に使い、修正コードの生成は連携する開発基盤が担う説明です。AIの判断と根拠は、課題の本文やAWS側の検知結果に記録するとしています。

これは役割を分けた構成の説明であり、誤検知がなくなることや、修正が常に正しいことの証明ではありません。導入の検証では、誤って抑制した結果がないか、優先順位の変更を追えるか、提案を採用しなかった理由が残るかを確かめたいところです。人の最終承認を残すなら、承認に必要な情報が揃うことも提供価値になります。

顧客環境で動くことと、外部通信が不要なことは違う

データを置く場所だけでなく、動かすための接続条件を確認します。

クオンは、ソースコードや検知結果を外部サーバーへ転送・蓄積せず、顧客自身のAWSとGitHub環境で稼働すると説明しています。一方、対応環境の注記はAWSとGitHubへの接続が前提で、外部通信を遮断した閉域環境では動作しないと明記しています。通信先の一覧と許可リストによる運用へ対応する説明です。

そのため、施設内だけで完結する構成や、通信をすべて断ったまま利用できる商品とは区別する必要があります。契約を検討する側は、コードや検知情報を扱う場所と、通信を認める先、アクセス権限、ログを確認する役割を対応させたいところです。顧客環境で動くという一言だけでは、導入できる条件は決まりません。

年間契約後に残る利用権と、更新の支援を分ける

ソフトを使えることと、新しい問題へ対応し続けることの費用は別です。

提供形態は、対象リポジトリ単位のライセンスとサポートを基本とします。リポジトリは、ソースコードや変更履歴を管理するまとまりです。契約期間中に提供されたバージョンは期間後も継続利用できる一方、更新やサポート、同じメジャーバージョン内の修正パッチについては契約上の条件が示されています。

利用を続けられるからといって、将来の脅威や接続先の変更へ無償で対応し続けるとは読み取れません。導入する側は、コード管理の分け方で課金対象がどう変わるかと、更新・支援を継続する費用を確認する必要があります。提供会社側も、ライセンスの販売と、人が環境を整え運用を支える仕事を分けて採算を見ることが重要です。

自社での運用から、顧客の多様な環境へ移せるかを追う

次に必要なのは、修正の提案が顧客の実際の承認と適用まで届く証拠です。

クオンは自社開発環境での運用成果をもとに開発したとしていますが、顧客ごとの実績や削減率は示していません。複数のAWSアカウントをまたぐ機能には、監査用アカウントやログ集約基盤などの条件があります。導入支援や開発基盤との連携構築も追加の支援範囲です。

顧客が違えば、コードの品質、変更を認める手順、接続権限も変わります。検証では、修正案の採用率だけでなく、承認待ちの時間、再検査、導入準備と保守を含む総工数を追う必要があります。12月の提供後、顧客の確認負担と提供側の支援工数がどう変わるかが、この自動化を広げられるかの判断材料になります。

まとめ

クオンは、脆弱性の検知から修正提案までをつなぐサービスを12月に提供する予定です。人のレビューと承認は残り、顧客環境で稼働しても外部接続が前提です。リポジトリ課金、契約後の利用権、更新と支援の条件を分け、提案が適用されるまでの負担と総費用で事業の継続性を確かめる必要があります。

関連記事: 仮説検証の進め方 ／ 新規事業の仮説の立て方