Takumi byGMOはどこまで先進的か：AIネイティブAppSec基盤の技術評価
結論
2026年9月2日時点の公開情報を総合すると、Takumi byGMOは「AIをSASTへ付けた製品」ではない。Whitebox、Blackbox、Graybox、AI Pentest、Autofix、Supply Chain対策、CI runtime観測を、AIエージェント中心のAppSec基盤へまとめようとしている製品群なのだ。1234
最大の強みはLLMのモデル名ではなく、探索と検証を分離し、ブラウザやshellを使うエージェントを隔離環境で動かし、可能な判定を決定論的な仕組みへ戻す「AIハーネス」にある。Next.jsのCVE-2025-30218では、GitHub Advisory DatabaseがRyotaKとtakumi-san.aiを発見者として記録しており、実在するOSSで未知の脆弱性を発見した外部証跡もある。5
ただし、技術的先進性と製品成熟度は分けて見る必要がある。ベンダー公表の精度、提供直後の機能、公開されていない評価条件だけでは、大規模環境での再現性や運用負荷まで判断できない。現時点の結論は「全面移行」ではなく、既存SASTと並走させる本格PoCの有力候補なのだ。
| 領域 | 技術評価 | 成熟度の見方 |
|---|---|---|
| Whitebox / SAST | 4.4 / 5 | 意味論・業務ロジックへ踏み込む。決定論的SASTとの併用が妥当 |
| Blackbox / DAST | 3.9 / 5 | agenticな探索と再現は強い。最新精度はPoCで確認 |
| Graybox | 4.5 / 5 | 静的候補を実環境で再現する方向は有力。運用実績は要確認 |
| AI Pentest | 4.5 / 5 | 目標指向の攻撃経路探索まで広げる。実行境界と安全性が重要 |
| CI/CD・Supply Chain | 4.5 / 5 | Guard、Runner、cicd-sensor連携が製品の守備範囲を広げる |
| AIハーネス | 4.6 / 5 | 探索・実行・検証・隔離の分離が最大の特徴 |
| 総合 | 4.2 / 5 | 技術的に先進的。導入判断は自社golden setによる実測が必要 |
この点数は公開情報に基づく筆者の相対評価であり、第三者認証や統一ベンチマークの結果ではない。
SASTではなく、AIによるSecurity Reviewとして見る
TakumiのWhiteboxは、コードを一度にLLMへ渡して脆弱性を質問するだけの仕組みではない。製品資料は、リポジトリの機能を把握し、認証や購入履歴など対象を絞り、実装と仕様の文脈から認可不備やBusiness Logic Flawを調べる使い方を示している。6
この方式の価値は、SQL InjectionやXSSの構文的な兆候だけでなく、Broken Authorization、認証フロー、アプリケーション固有の制約違反へ探索範囲を広げられる点にある。一方、LLMを用いる診断には結果の揺らぎがあり、高速で決定論的なCodeQLやSemgrepと同じ性質ではない。
したがって、当面の構成は次の補完関係がよい。
- CodeQLやSemgrep: 既知パターンを高速かつ決定論的に検査
- Takumi Whitebox: 機能文脈、データフロー、認可、業務ロジックを意味論的に調査
- 人間: 重要な境界条件、仕様解釈、受容リスクを最終判断
Takumiが公表する高いRecallは製品評価の材料になるが、データセット、複数回実行時の分散、比較条件が十分に再現できなければ、その数値だけで既存SASTより優れるとは断定できない。外部の脆弱性クレジットと、自社コードでの再現試験を別々の証拠として扱う必要があるのだ。
Blackboxでは、発見数より検証方法を見る
Blackbox機能は、URLと診断条件からブラウザ操作やHTTPレベルの攻撃を行い、DOM-based XSS、Request Smuggling、自然言語の解釈を要するロジック不備などを対象にする。公式ページは、ソースコードなしのBlackboxと、コードを併用するGrayboxを同じ動的診断の系統として説明している。2
AIエージェントが「脆弱性らしい」と述べるだけでは、実務のfindingにはならない。重要なのは、別セッションとの応答差、時間差、callback、実ファイル内容、実際の画面遷移など、観測可能な結果へ戻せるかである。探索をLLMへ任せても、最終判定を再現可能な証拠へ寄せる設計なら、hallucinationを診断結果へ直結させにくい。
ただし、アーキテクチャが優れていることと、最新エンジンのRecall、Precision、False Positive Rateが十分であることは別問題である。Blackboxは設計評価を高く置きつつ、実効精度をPoCで測るべき領域なのだ。
GrayboxはTakumiの競争力になり得る
Grayboxは、Whiteboxで見つけた候補をBlackbox側の実行環境で検証する。公式ページも、ソースコードプラットフォームと連携し、WhiteboxとBlackboxをagentic workflowとして組み合わせ、Blackbox engineをvalidatorに使うと説明している。2
この結合は両方式の弱点を補う。
| 方式 | 得意なこと | 弱点 |
|---|---|---|
| Whitebox | 実装全体から候補を発見する | 実際に攻撃可能かをコードだけでは確定しにくい |
| Blackbox | 実環境でexploitabilityを確認する | 外部から攻撃点を見つけられなければ試せない |
| Graybox | コードから候補を見つけ、実環境で再現する | 対象環境、認証、テストデータ、安全な実行条件が必要 |
単独のSASTやDASTより、静的なDiscoveryと動的なValidationの閉ループがTakumiの差別化になり得る。ただし、公式ページではBlackboxとGrayboxの提供開始を2025年11月12日としている。新機能という理由だけで成熟度を低く見積もるのではなく、導入社数、継続運用期間、失敗時の復旧、再現性を質問票とPoCで確認するのが妥当なのだ。7
AI Pentestは目標指向だが、自由度がリスクにもなる
GMO Flatt Securityは2026年6月、TakumiのAIペネトレーションテスト機能を発表した。これは単にDASTを長時間動かすのではなく、機密情報への到達やRCEなどの目標に向かい、偵察、発見、攻撃、次の足掛かりという探索を繰り返す方向を示すものなのだ。4
この種のAutonomous Offensive Securityでは、発見能力と同じくらい次が重要になる。
- 対象URL、IP、cloud accountなどのscopeを強制できるか
- 破壊操作を禁止・最小化・許可するpolicyがあるか
- 認証情報や取得データをどこへ保存するか
- 実行直前にscopeとpolicyを再確認するか
- 緊急停止、監査ログ、再現手順を提供できるか
製品が高い自由度を持つほど、契約上の許可と技術的なguardrailを一致させる必要がある。研究上の先進性だけで本番利用を決めてはいけない領域なのだ。
APIとCI/CD統合は実用段階へ進んでいる
Takumi APIは、workflowの起動、結果取得、Webhookによる完了通知を提供する。WebhookはStandard Webhooks方式の署名を採用し、at-least-once deliveryを前提とするため、受信側はwebhook-idで冪等に処理する必要がある。89
Bot認証はGitHub Actions OIDC、GitLab CI OIDC、custom OIDC、API keyに対応する。OIDCではjobごとの短命なcredentialを使えるため、長期API keyをCIへ保存せずに済む。custom OIDCはbetaであり、仕様変更の可能性も含めて採用判断する必要がある。10
APIが存在することと、製品の全操作がAPI-firstであることは同義ではない。PoCでは、必要なassessment種別、Autofix、再診断、例外処理、finding exportが実際にAPIから完結するかを確認するのだ。
Guard、Runner、cicd-sensorが守備範囲を広げる
2026年3月に発表されたGuardは、依存パッケージ取得時に悪性packageを阻止する。RunnerはCI/CD内のprocess、network、DNS、file accessを観測し、buildとtestの実行実態を追う。これによりTakumiは、コードと稼働Webアプリだけでなく、software supply chainとCI runtimeへ範囲を広げた。3
さらにRunnerはOSSのcicd-sensorと連携し、専用runnerへ全面移行しなくてもtrace logを集約できる。2026年9月1日には、組織あたり月3,000分までtrace logを受け付けるfree tierが公開された。上限到達後はログ受け付けが止まる一方、CI job自体は継続すると明記されている。11
製品群を一つの流れへ置くと、狙う範囲が見えやすい。
| 開発工程 | Takumiの機能 | 主な目的 |
|---|---|---|
| 依存パッケージ取得 | Guard | 悪性packageの流入を阻止 |
| CI実行 | Runner / cicd-sensor | process・network・file accessを観測 |
| ソースコード | Whitebox | 脆弱性候補とlogic flawを探索 |
| 稼働アプリ | Blackbox | 外部から攻撃と再現を実施 |
| コード＋稼働環境 | Graybox | 静的候補のexploitabilityを検証 |
| 侵害目標 | AI Pentest | 複数段階のattack pathを探索 |
| 修正 | Autofix | 修正案やPull Requestへ接続 |
この水平展開を踏まえると、TakumiはSAST/DAST製品というより、AI-native Application Security Platformを目指していると捉える方が正確なのだ。
AIハーネスを高く評価する理由
Takumiの実行基盤「Sunaba」に関する公開講演では、KVMとFirecrackerのmicroVMを使い、LLMを制御するBrainとtool実行環境のComputeを分離する設計が示された。顧客コードや攻撃コードを実行するAI agentでは、モデルが常に安全なcommandを生成すると期待するのではなく、失敗を前提に実行境界を作る必要がある。12
評価すべき要素は次の組み合わせである。
- repositoryを機能単位へ分けるcontext設計
- 探索、仮説生成、検証の役割分離
- browser、shell、HTTP log、callbackなどのTool Use
- 動的なexploit validation
- 可能な判定を決定論的なOracleへ戻す設計
- BrainとComputeを分けるsandbox
これは「security用system promptを付けたLLM」より明確に深い。一方で、使用モデル、routing、最新版のevaluation framework、障害率は公開情報だけでは十分に分からない。そのため5点満点にはしないのだ。
世界市場での現在地
Takumiを技術的に高く評価しても、世界首位とまでは断定できない。XBOWは自律的なWeb pentestを中核にし、短命なagentによる探索と決定論的validatorを分離している。公開された実戦規模と攻撃自律性では、専業のXBOWに分がある。13
一方、Takumiの特徴は、SAST、DAST、Graybox、Pentest、Autofix、package proxy、CI runtime monitoringを同じ製品群へ広げている点にある。成熟したAppSec vendorと比べる場合も、単一機能の検出率だけでなく、既存ecosystem、対応言語、governance、API範囲、運用実績まで分けて比較する必要がある。
PoCでは自社の既知脆弱性をgolden setにする
導入時は、Takumiだけへ全面移行せず、既存SASTと同じ実アプリで並走させる。過去に人間が発見した認可不備、logic flaw、Injection、XSS、SSRFなど20〜50件を、許可されたtest環境にgolden setとして用意するのだ。
| 指標 | 確認する内容 |
|---|---|
| Recall | 既知の脆弱性を何件再発見できたか |
| Precision | 報告のうち、再現できる脆弱性が何件か |
| 再現性 | 同じ条件の複数回実行で結果がどの程度揺れるか |
| 実行時間 | commit、release、定期診断のcadenceに収まるか |
| 単価 | 1件の有効findingを得るまでの費用と人手 |
| 修正品質 | AutofixのPRが脆弱性を消し、既存機能を壊さないか |
| 運用統合 | Webhook、ticket、SIEM、例外管理へ接続できるか |
| 安全性 | scope外通信、破壊操作、秘密情報の露出が起きないか |
現在のTakumiは「様子見する製品」より「本格PoCで実測する製品」に近い。最大の不確実性は技術構想ではなく、最新engineの実効精度と大規模運用時の成熟度なのだ。