SPECA の今後の方向性 (hirorogo 個人の見解)
これは hirorogo 個人の構想で、Nyx Foundation の公式ロードマップではありません。
1. 複数 AI エージェント環境への対応
現在は Claude Code を前提に設計していますが、Codex CLI や Gemini CLI でも同じフレームワークを動かせるようにしたいです。
ハーネス設計で複数モデル・プロバイダに対応できるようにすれば、Anthropic の認証インフラへの依存も分散できます。Claude と Codex で役割分担させる選択肢（例：Claude が proof-attempt 推論、Codex が大量コード書き換え提案）も面白そうです。同じ仕様・同じターゲットに両方走らせて出力を比較するアンサンブル評価も、multi-agent harness があればできるようにしたいです。
2. コミュニティ駆動型マーケットプレイス
仕様ファイル → property mapping をコミュニティ内で共有・再利用できる場を作りたいです。複数の監査人が同じプロトコルのマッピングを作れば、質の高い定義が自然に増えていきます。
Ethereum 周りには既に大量の過去 audit データがあります（Code4rena、Sherlock、CodeHawks など）。これらをまとめて取り込み・整理することで、新規参加者が「既存マッピングを投入してすぐ動かせる」状態を目指しています。
どうせなら、誰でも自分の書いたセキュリティプロパティをアップロードしたり、自分の audit 結果を共有したりできる場にしたいです。投稿された property や結果がそのまま次の監査の材料になり、共有が増えるほどエージェント側もだんだん強くなっていく、という形を作れたら良いと思っています。
3. コミュニティ × 企業のハイブリッド戦略
コミュニティの強みは、マッピング共有・多様な対象への初動の早さです。一方で、大規模インフラ・社内の蓄積データ・継続的な R&D 投資といった部分は、業界の大手企業と組んでこそ進められる領域です。
コミュニティが集めた事例を企業側の解析体力で深掘りし、企業側のデータや精度評価をコミュニティへ返す、という形にしていきたいです。どちらか片方だけでは届かない部分を、それぞれが補う関係が理想だと思っています。
4. 再帰的自己改善ループ
既存の Phase B prompt iteration loop をさらに発展させ、過去の audit 結果から SPECA 自身のプロンプトとフィルタ定義を自動で改善できるようにしたいです。精度が高かった property mapping や false positive が多かったパターンを学習することで、モデル性能だけに頼らない改善ができるはずです。
収束しない場合に備えて、threshold やプロンプトを自動で調整して試し直すメタ層も必要だと考えています。circuit breaker や budget は既存ですが、その一段上の「self-healing orchestrator」を構想中です。
5. 自動クロール監査エージェント
GitHub などの公開リポジトリを定期巡回して、候補バグを自動検出・報告するエージェント群を作りたいです。bug bounty 活動を半自動化することで、手作業の負荷を減らしながらより多くのプロジェクトをカバーできます。
スクレイピング部分は Scrapling のような bot 検知耐性のある HTTP クライアントを tool 化して組み込みたいです。過去事例とのパターンマッチも tool 化対象で、監査中に「過去の類似コントラクトでこういう事例があった」を自動 lookup できるようにして、根拠付けまで自動化するのが目標です。
監査ターゲットの種類 (DeFi コントラクト / Ethereum クライアント / C++ ライブラリ / ZK サーキット 等) を自動判定して、それに合った過去事例・バグ事例・関連仕様書を勝手に集めてくる仕組みも作りたいです。「同じ DeFi なら過去の reentrancy 事例の集合」「同じ consensus client なら過去の consensus bug の集合」のように、ターゲットの category に応じた dataset を勝手にたくさん引いてきて、初動から使える状態にしたいです。
6. GUI だけで操作できるインターフェース
現状の SPECA は CLI / TUI 中心で、Claude Code や uv のコマンド操作に慣れている人を前提にしています。ターミナルを開かずブラウザだけで監査の起動・進捗確認・結果ブラウズができる GUI 版も用意したいです。
speca-cli の TUI を Web 化する形でも、別実装でローカル Web サーバ + ブラウザ UI を提供する形でも良いと思います。CLI に詳しくない人にも使えるよう、入口を増やすのは早めに着手したいテーマです。
7. コミュニティと専門家の知見をデータセット化
コミュニティが SPECA を回して出した audit 結果は、そのままベンチマーク用データセットになります。さらに、専門家が誤検知を修正した過程や、検出漏れ箇所への注釈 も、人間の判断をデータ化する上で価値が高い素材です。
Section 4 の自己改善ループと組み合わせることで、モデル単体の性能に頼らない改善が続けられると思います。専門家のレビュー過程を匿名化してデータセットに取り込むパイプラインも組んでみたいです。
過去に audit された類似コントラクトのデータセットを作り、新規ターゲットが来たときに similarity search で関連事例を引ける tool も組み込みたいです。初見ターゲットでも、過去事例の文脈から audit を始められる状態にするのが目標です。
これらの構想は段階的に実装していく予定です。SPECA がコミュニティと企業の両面で成長し、AI エージェントによるセキュリティ監査の手法として定着していけたら良いと思っています。