OSS

概要 GitHubは2026年4月3日、GitHub Copilotのクラウドエージェント向けに組織レベルのランナー制御機能を発表した。これにより組織の管理者は、デフォルトランナーの設定を全リポジトリに一括適用できるようになり、さらに個別リポジトリによる設定変更をロックする「強制適用」機能も利用可能になった。 従来、Copilotクラウドエージェントがタスクを実行する際の開発環境は、各リポジトリのcopilot-setup-steps.ymlファイルを通じてリポジトリ単位で設定する必要があった。そのため、組織全体での一貫した実行環境の維持が難しく、管理コストも高くなっていた。 主な機能と活用シーン 今回追加された機能は大きく2つある。1つ目はデフォルトランナー設定で、個別のセットアップなしに標準ランナーを組織内の全リポジトリへ自動的に適用できる。2つ目は強制ロック機能で、リポジトリ側から組織が定めたデフォルト設定を上書きできないようにする。 具体的なユースケースとしては、パフォーマンス向上のためにより高スペックなGitHub Actionsランナーを組織全体に展開すること、内部リソースへのアクセスが必要な場合にセルフホストランナーへの実行を強制すること、セキュリティおよびコンプライアンスポリシーを一貫して適用することなどが挙げられる。 背景と今後の展望 今回の機能はCopilotクラウドエージェントの一連の改善の一部として提供されており、同時にファイアウォール設定やコミット署名機能も発表されている。組織規模でのAIエージェントの活用が広がる中、実行環境の標準化とセキュリティポリシーの一元管理は重要な課題となっており、今回の機能追加はその解決に向けた取り組みといえる。詳細な設定方法はGitHubの公式ドキュメント「Configuring runners for GitHub Copilot cloud agent in your organization」で確認できる。

概要 JetBrainsが開発するKotlin/Java向けビルドツール「Amper」のバージョン0.10が2026年3月31日にリリースされた。今回のリリースでは、JDKの自動プロビジョニング、MavenプロジェクトからAmperへの半自動変換ツール、カスタムKotlinコンパイラプラグインのサポートという3つの主要機能が追加されている。GradleやMavenの代替を目指すビルドシステムとして、実用性と移行容易性の面で大きく前進した内容となっている。 JDK自動プロビジョニング これまで開発者が手動で行う必要があったJDKのインストール・設定を、Amperが自動化する機能が追加された。デフォルトではJDK 21が自動的にダウンロード・インストールされ、module.yamlにてバージョンやディストリビューション（ZuluやTemurinなど）を明示的に指定することも可能だ。JAVA_HOME環境変数が設定されている場合はそちらが優先される。この機能により、プロジェクトのクローン直後にJDKのセットアップなしで即座にビルドを開始できるゼロコンフィグレーションなワークフローが実現した。 Mavenプロジェクト変換ツール 既存のMavenプロジェクトをAmperへ移行しやすくするため、./amper tool convert-projectコマンドで動作する半自動変換ツールが導入された。このツールはpom.xmlを読み込み、対応するAmperの設定ファイルを自動生成する。layout: maven-like設定によりMavenのディレクトリ構造をそのまま維持できるため、ファイルの再配置が不要で、完全な書き直しではなく段階的な移行が可能だ。maven-compiler-pluginのようなよく知られたMavenプラグインはAmperのネイティブ設定に変換され、その他のプラグインはmavenPluginsセクションに追加されてAmperによるビルド中に実行される。 今後の展望 本リリースはAmperが実験的なツールから実用的なビルドシステムへと進化する過程における重要なマイルストーンといえる。なお、今回追加された機能の利用にはIntelliJ IDEA 2025.3.4または2026.1以降と最新のAmperプラグインが必要となる。JetBrainsはMavenエコシステムとの互換性を高めながら、開発者の初期セットアップの摩擦を減らす方向で開発を継続している。

概要 2026年4月初旬、セキュリティ研究者はnpmレジストリに公開された36個の悪意あるパッケージを発見した。これらはすべて strapi-plugin- という命名パターンを持ち、正規のStrapi CMSプラグインに見せかけていた。strapi-plugin-cron、strapi-plugin-database、strapi-plugin-server など実在しそうな名前を使い、すべてバージョン3.6.8として統一して公開されていた。4つのソックパペットアカウント（umarbek1233、kekylf12、tikeqemif26、umar_bektembiev1）が13時間という短期間のうちに一斉にアップロードしており、組織的な攻撃の痕跡が明白だった。SafeDepの動的分析パイプラインが strapi-plugin-events を最初に検出し、C2通信シグナルおよび秘密情報の探索行動が確認されたことで調査が始まった。 攻撃チェーンの技術的詳細 このサプライチェーン攻撃は npm install の実行時に postinstall.js スクリプトが自動的に起動することで始まる。SafeDepの分析によれば、8段階（他の調査では11段階）に及ぶ攻撃チェーンが展開される。 まず Redis RCEとして、CONFIG SET コマンドを悪用し、crontabエントリ、PHPウェブシェル（/app/public/uploads/shell.php）、SSHキーを注入する。続いてブロックデバイスへのアクセスを試みてraw diskを読み取り、Dockerコンテナ脱出を経てリバースシェル（ポート4444でbash、ポート8888でPython）を展開する。 情報窃取フェーズでは、.env ファイルやStrapi設定ファイル、PEM/keyファイルを収集し、Redisの完全ダンプとKubernetesシークレットを抽出する。また、ハードコードされた認証情報（user_strapi / 1QKtYPp18UsyU2ZwInVM）でPostgreSQLへの不正接続も試みる。最終的に /tmp/.node_gc.js への永続インプラントを書き込み、144.31.107.231:9999 のC2サーバーと通信を確立する。C2エンドポイントは /c2/<id>/（約5分間のC2コマンドポーリング）、/db/<id>/（データベース窃取）、/shell/（3秒間隔の永続シェルセッション）に分かれており、インプラントが残存している限り攻撃者は継続的なリモートアクセスを維持できる。 標的と攻撃者の意図 攻撃者が特定の企業を狙っていたことは、コード内に埋め込まれた手がかりから明らかだ。暗号資産決済プラットフォームであるGuardarianに関連するモジュール名や、HOT_WALLET、COLD_WALLET、MNEMONIC といったウォレット関連の文字列の探索が確認されている。また、永続インプラントの書き込み条件がホスト名「prod-strapi」に限定されていることから、攻撃者がターゲットの本番環境構成を事前に把握していた可能性が高い。Jenkins CI/CDパイプラインへの言及もあり、開発インフラ全体を侵害しようとする意図がうかがえる。 見分け方と推奨される対応策 正規のStrapiパッケージは @strapi/ スコープ付きで公開されているが、悪意あるパッケージはスコープなしで公開することで開発者の信頼を悪用していた。このタイポスクワッティングおよびブランドなりすましの手口は、依存関係を機械的にインストールする開発者にとって見分けにくい。 侵害が疑われる場合、/tmp/.node_gc.js、/tmp/vps_shell.sh、/app/public/uploads/shell.php の存在確認と削除、crontabにおける node_gc 参照の除去、IPアドレス 144.31.107.231 への通信遮断を直ちに行う必要がある。また、JWT シークレット、データベース認証情報、APIキーを含む全認証情報のローテーションが推奨される。予防策としては、npm audit や Snyk、Dependabot の導入、組織ポリシーによるスコープなしパッケージの拒否設定が有効だ。

概要 TigerFSは、PostgreSQLデータベースをディレクトリとしてマウントし、ls、cat、find、grepなどの標準Unixコマンドでデータを操作できる実験的なオープンソースファイルシステムだ。TigerData（旧Timescale）がMITライセンスのもとGitHub（timescale/tigerfs）で公開したこのツールは、APIやSDKを介さずにデータベースとやり取りできる新しいアプローチとして開発者の注目を集めている。AIエージェントがデータベースの状態を共有・管理する用途でも活用できる設計になっており、AI開発との親和性も意識されている。 2つの動作モード TigerFSは「ファイルファースト」と「データファースト」の2つのワークフローをサポートしている。ファイルファーストモードでは、開発者がファイルをディレクトリ構造（todo / doing / done など）で整理し、アトミックな書き込みと自動バージョニングによって並行アクセスや状態管理を実現する。AIエージェントが複数の状態を共有する際に特に有用なアプローチだ。 データファーストモードでは、既存のPostgreSQLデータベースをマウントして、Unixツールでデータを探索できる。ファイルシステムのパスにフィルタやソート条件を含めることでデータベースクエリに変換されるため、SQLを書かずにデータを取得・確認できるのが特徴だ。 技術的な詳細 LinuxではFUSE、macOSではNFS経由でマウントに対応しており、外部依存なしで動作する。各ファイルはデータベースの1行に対応し、ACID保証が維持される。あらゆるPostgreSQLインスタンスやマネージドサービスと連携可能で、既存のデータベース環境にそのまま組み込める点も評価されている。開発者コミュニティからはパフォーマンス特性や制限事項への関心が寄せられており、小規模データセットの管理や設定ファイル的な用途において有用との声も上がっている。 展望 TigerFSはまだ実験的なプロジェクトとして位置づけられているが、データベースへのアクセスを「ファイル操作」という直感的なインターフェースで統一するというコンセプトは、特にAIエージェントがファイルシステムを通じてデータを読み書きするユースケースで新たな可能性を示している。SQL不要のデータ探索を実現するこのアプローチが、今後どのような形で発展するか注目される。

概要 Neovimは2026年3月29日、メジャーリリースとなるv0.12.0を公開した。今回の最大のハイライトは、外部ツールへの依存を不要にする組み込みパッケージマネージャー vim.pack の導入だ。これまでlazy.nvimやpacker.nvimといったサードパーティのプラグインマネージャーに頼っていた管理フローを、Neovim本体で完結できるようになった。コミュニティからの反応はGitHub上で525件以上のリアクションを集めるなど、非常に好評を博している。 LSP・補完の大幅強化 LSPまわりの改善も今回の目玉だ。補完候補にカラーシンボルのプレビューやインライン補完が追加されたほか、新しい対話型コマンド :lsp によってLSPクライアントを一元管理できるようになった。コードレンズが仮想行として表示されるよう変更されたことで視認性も向上した。さらに textDocument/diagnostic・ textDocument/documentColor・ワークスペース診断・動的登録など多数のLSP仕様への対応も追加されている。デフォルトキーバインドには grt（型定義へジャンプ）と grx（コードレンズ実行）が新たに加わった。 Lua APIの拡充とHTTP対応 Lua APIにも注目すべき追加がある。vim.net.request() の追加により、外部ライブラリを使わずにNeovim内から直接HTTPリクエストを発行できるようになった。そのほか vim.list.unique()・vim.list.bisect() などのリスト操作関数、vim.text.diff()（旧 vim.diff）、フローティングウィンドウへのステータスライン表示・タブページ間移動のサポートなども追加された。新オプションとして 'autocomplete'・'pummaxwidth'・'pumborder'・'busy' などが導入されている。 パフォーマンス改善と実験的Zigビルド パフォーマンス面では、i_CTRL-R によるレジスタ挿入が従来のユーザー入力シミュレーション方式から貼り付け方式に変わり約10倍高速化。LPeg実装によりglobパターンマッチングが約50%高速化された。LSPはトークンリクエストを表示中のビューポートに限定するよう最適化され、帯域幅の節約にも貢献している。また実験的機能としてZigベースのビルドシステムが導入された。 破壊的変更と注意点 既存の設定に影響する破壊的変更もいくつか含まれる。vim.diagnostic.disable() などの旧来のDiagnostics APIが削除され、JSONのnull値が nil から vim.NIL に変更された。セマンティックトークン関数が start()/stop() から enable() にリネームされるなど、プラグイン開発者は対応が必要になる場合がある。Windowsでは外部コマンド実行時にカレントディレクトリを検索しなくなるセキュリティ強化も施された。アップグレード前に公式チェンジログでの確認が推奨される。

概要 分散バージョン管理システムGitの最新メジャーフィーチャーリリースであるGit 2.52が公開された。今回のリリースの最大の特徴は、WITH_RUSTビルドフラグを介してRustで書かれたコードがGitリポジトリに初めて統合されたことだ。現時点では任意の選択肢だが、Git 3.0ではRustが必須依存関係となる予定であり、今回はその布石となる重要なマイルストーンと位置付けられる。Git 3.0は2026年末のリリースを目標としており、2.52はそれに向けた大規模な準備作業を含む。 Rustコードの初統合 Git 2.52ではWITH_RUSTビルドフラグを指定してビルドすることで、Rustで実装された内部機能を利用できる。現時点でRustが担うのは主にパックファイル処理で使われる可変長整数エンコード・デコードだが、CコードからRustヘルパーを呼び出すためのインフラが整備された。Rustがなくてもビルド・動作は可能で、Cのフォールバック実装が提供される。また、SHA-256相互運用性に関連する一部のコードもRustで実装が進められている。将来的にGit 3.0ではRustがビルド時の必須要件になる計画だ。 新コマンドと機能強化 Git 2.52では複数の新コマンドが追加された。git last-modifiedは指定パスに最後にコミットした祖先コミットを表示するコマンドで、GitHubの内部ツール「blame-tree」に由来する。リポジトリ履歴を一度だけ走査して追跡済みパスを除去していく設計により、従来のgit ls-tree + git log --max-count=1の組み合わせと比較して約5.5倍の速度向上を実現する。大規模リポジトリやモノレポで特に恩恵を受けやすい。 実験的なgit repoコマンドも追加された。git repo infoはオブジェクトフォーマット（SHA-1またはSHA-256）や参照タイプなどリポジトリレベルの設定を表示し、git repo structureはコミット・ツリー・ブロブ・タグ・参照のカウントなどリポジトリの構造統計を示す。参照管理関連ではgit refs list・git refs exists・git refs optimizeの各サブコマンドも追加されている。 パフォーマンス面ではgit describeが約30%高速化され、スパースチェックアウト環境のクリーンアップを行うsparse-checkout cleanサブコマンドや、ワイルドカードパス指定をBloomフィルタで扱えるようにする改善も含まれる。リポジトリのメンテナンス戦略としてgeometric戦略が追加され、パックファイルを等比数列的な大きさで管理することでCPUとI/Oのオーバーヘッドを削減できる。 SHA-256相互運用性とGit 3.0への道 Git 3.0の主要目標の一つはデフォルトハッシュをSHA-1からSHA-256へ切り替えることだ。Git 2.52ではSHA-1とSHA-256のリポジトリが相互にプッシュ・プルできるようにするための基盤整備が始まった。完全な相互運用性はGit 3.0を目指しているが、今回の作業はその大きな一歩となる。また、git initがデフォルトブランチとしてmainを使うようにする変更や、既存ユーザーへの移行ヒント表示といった準備も進んでいる。ビルドシステム面でも全オブジェクトを単一のlibgit.aアーカイブに統合する整理が行われ、Mesonビルドシステムへのドキュメントサポートも追加された。

概要 GitHubは2026年4月2日、GitHub Issues向けに改良した意味ベース検索（Improved Search for GitHub Issues）を正式に一般提供（GA）へ移行したと発表した。本機能は2026年1月のプレビュー提供を経て2月に拡張され、今回の正式リリースに至った。従来のキーワードマッチングに依存した検索とは異なり、自然言語による概念的な理解を基に関連イシューを発見できる点が特徴で、検索に成功したケースでは上位3件以内に目的のIssueが含まれる割合が66%から75%へ改善されたと報告されている。 主な機能 本機能には主に以下の要素が含まれる。 自然言語検索: キーワードの完全一致がなくても、意味的に関連するIssueを返す。 検索スコープ: 個別リポジトリ内、および Issues ダッシュボードを通じた複数リポジトリ横断の両方に対応。 ハイブリッド検索: 意味ベースとキーワードマッチングを組み合わせた検索モードを提供し、概念的に類似した結果と完全一致の結果を同時に返す。フィルターのみや引用符付きの検索語を使用した場合は従来の字句検索が適用される。 関連度順ソート: 結果はデフォルトで関連度順に表示される。 REST/GraphQL APIからの利用 既存のAPIエンドポイントに新しいパラメータを追加することで、この機能を利用できる。 REST API: /search/issues エンドポイントに search_type=semantic（意味ベース）または search_type=hybrid（ハイブリッド）を指定する。 GraphQL API: searchType 引数に SEMANTIC または HYBRID を指定する。 なお、意味ベース検索およびハイブリッド検索のクエリにはレートリミットが適用され、1分あたり10リクエストまでに制限される。 その他の改善 今回のリリースでは検索機能のGA化に加え、テンプレート編集の改善、「@」メンションを用いたアサイニーフィルタリング、複数リポジトリ修飾子の処理改善、折りたたみセクション内でのMermaidダイアグラム描画サポートなども同時に提供されている。

概要 Microsoftは2026年4月2日、AIエージェント向けのランタイムセキュリティフレームワーク「Agent Governance Toolkit」をオープンソースとして公開した。フライト予約やコード実行、インフラ管理など自律的に動作するAIエージェントの普及に対し、ガバナンスの仕組みが追いついていないという課題に応えるもので、MITライセンスのもとGitHubで提供される。2025年12月に公開された「OWASP Top 10 for Agentic Applications」が示すゴールハイジャックやツール悪用、サプライチェーンリスクなど10のリスクすべてに対応するよう設計されており、EU AI Act（2026年8月施行）やコロラド州AI法（2026年6月施行）といった規制要件への対応も視野に入れている。 7パッケージ構成のアーキテクチャ Agent Governance ToolkitはPython・TypeScript・Rust・Go・.NETに対応した7つのパッケージで構成され、pip install agent-governance-toolkit[full]で一括インストール、または個別に導入できる。各パッケージの役割は次のとおりだ。 Agent OS: すべてのエージェントアクションを実行前にインターセプトするステートレスなポリシーエンジン。p99レイテンシは0.1ms未満。YAML・OPA Rego・Cedarのポリシー言語に対応。 Agent Mesh: Ed25519暗号化による分散型識別子（DID）を用いたエージェントID管理と、エージェント間信頼プロトコル（IATP: Inter-Agent Trust Protocol）を実装。0〜1000スケールの動的トラストスコアリングで5段階の信頼ティアを管理する。 Agent Runtime: CPUの特権レベルにヒントを得た動的実行リングと、マルチステップトランザクション向けのサガオーケストレーション、緊急エージェント停止機能を備える。 Agent SRE: SLO・エラーバジェット・サーキットブレーカー・カオスエンジニアリングなど、SREのプラクティスをエージェントに適用。 Agent Compliance: EU AI Act・HIPAA・SOC2への対応状況を自動検証し、OWASP Agentic AI Top 10のエビデンスも収集。 Agent Marketplace: Ed25519署名によるプラグインのライフサイクル管理とサプライチェーンセキュリティを担う。 Agent Lightning: 強化学習トレーニングにおいてポリシー違反ゼロを実現するポリシー強制ランナーと報酬整形機能を提供。 幅広いフレームワークとの統合 既存のエージェントフレームワークをリライトすることなく統合できる点が特徴で、LangChain・CrewAI・Google ADK・Microsoft Agent Framework・OpenAI Agents SDK・LangGraph・PydanticAI・LlamaIndexなどに向けたアダプターやプラグインが提供されている。またAzure Kubernetes Service（AKS）へのサイドカーコンテナとしての展開、Microsoft Foundry Agent ServiceやAzure Container Appsへの統合もサポートされている。 設計思想と今後の方向性 設計の柱として、カーネルやサービスメッシュ・SREの既存知見の活用、セキュリティをデフォルトとした実行パスへの組み込み、水平スケーリングと監査可能性を実現するステートレスアーキテクチャ、そして静的な信頼ではなく動的トラストスコアリングの4点が挙げられている。リポジトリには9,500件以上のテストが整備されており、ClusterFuzzLiteによる継続的ファジング、SLSA準拠のビルドプロベナンス、OpenSSF Scorecardによるセキュリティスコア追跡なども実装されている。Microsoftは将来的にOWASP・Linux Foundation AI & Data Foundation・CoSAIといったコミュニティ団体のもとにプロジェクトを移管することを目指しており、「エージェントガバナンスは単一ベンダーが管理するには重要すぎる」とコメントしている。

事の発端：.npmignoreの記述漏れによる大規模リーク 2026年3月31日、AnthropicがClaude Codeのnpmパッケージ（バージョン2.1.88）を更新した際に、重大なパッケージング上のミスが発生した。.npmignoreの記述が不完全だったため、59.8MBのソースマップがパッケージに同梱されてしまい、約1,900ファイル・512,000行にのぼる未難読化のTypeScriptソースコードが誰でもダウンロードできる状態で公開された。 このリークで明らかになった内部実装には、コンテキストウィンドウの制限を乗り越えるための「自己修復メモリアーキテクチャ」、KAIROSと呼ばれる永続的なバックグラウンドエージェント機能、OSSプロジェクトへの隠密コントリビューションを行う「Undercover Mode」など、これまで公開されていなかった機能が含まれていた。セキュリティ研究者は、内部データフローの詳細が露わになったことで、従来のジェイルブレイク手法に依存しない新たな攻撃ベクターが生まれると警告している。 GitHub史上最速成長リポジトリの誕生 このリークに着目したのが研究者のSigrid Jin（GitHubアカウント: instructkr）だ。彼はリークされたコードを参照しつつ、プロプライエタリなコードを一切使用しない「クリーンルーム実装」として、PythonとRustによる再実装プロジェクト「Claw Code」を立ち上げた。プロジェクトは公開後急速に成長し、初期の数日間で72,000スター・72,600フォークに到達した後、10万スターを突破。GitHub史上最も速く成長したリポジトリの一つとなった。 プロジェクトの製作者は「ハーネス、つまりコンテキストの流れ方、ツールの接続方法、意思決定の仕組みこそが本当のエンジニアリングが宿る場所だ」とコメントしており、LLMと開発ツールを結ぶ透明で監査可能なインフラを提供することを目的として掲げている。Python実装のワークスペースコード、テストディレクトリ、CLIユーティリティが公開されており、本番環境向けのRust実装も開発中だ。 AnthropicのDMCA対応とセキュリティへの波及 Anthropicはリーク発覚後、GitHubに対してDMCAによる削除要請を行い、リークコードを直接含むリポジトリの排除に動いた。しかし、Claw CodeはクリーンルームのPython/Rust実装として設計されているため、単純なDMCA対象にはなりにくいとみられている。 一方、この騒動に便乗する形で、Vidar StealerやGhostSocksといったマルウェアを仕込んだ、Claude Codeのリークコードを装った偽リポジトリが流通し始めたことも報告されている。人気リポジトリへの注目を悪用したサプライチェーン攻撃のリスクが顕在化しており、ユーザーは公式GitHubリポジトリ（github.com/instructkr/claw-code）以外のソースからダウンロードしないよう注意が必要だ。今回の事件は、npmパッケージ管理における.npmignoreや.filesフィールドの設定ミスが引き起こすリスクを改めて業界に示すものとなった。

概要 ESLint v10が正式にリリースされ、長期にわたる移行期間を経てフラットコンフィグへの完全移行が完了した。最大の破壊的変更は、旧来の.eslintrc設定システムの完全廃止だ。互換レイヤーとして提供されていたLegacyESLintが削除され、Linterクラス上のdefineParser()・defineRule()・defineRules()・getRules()といったメソッドも取り除かれた。またshouldUseFlatConfig()は無条件でtrueを返すようになった。まだ.eslintrcを利用しているチームはv10へのアップグレード前に移行を済ませる必要があり、公式の移行ツールnpx @eslint/migrate-config .eslintrc.jsonを使えばeslint.config.mjsファイルを自動生成できる。 技術的な変更点 設定ファイルの探索ロジックも改善された。従来はカレントワーキングディレクトリを起点に検索していたが、v10ではリントするファイルのディレクトリから順に検索するよう変更された。これによりパッケージごとに異なるルールを持つモノレポ構成での利便性が高まる。 JSX識別子を変数参照として認識する機能も追加された。これによりJSXのみで使用されるコンポーネントがno-unused-varsルールで誤検知される問題が解消され、@eslint-react/jsx-uses-varsなどのコミュニティワークアラウンドが不要になる。テスト基盤面ではRuleTester APIにrequireMessage・requireLocation・requireDataの新オプションが追加され、プラグイン開発者がより厳密なテスト定義を書けるようになった。 Node.jsの対応バージョンは^20.19.0 || ^22.13.0 || >=24に絞られ、v21.xおよびv23.xは非対応となった。 エコシステムと競合状況 移行に際してエコシステム側の課題も浮き彫りになった。eslint-plugin-reactやNext.jsが標準で使用するeslint-config-nextがv10のピア依存宣言に初期対応していなかったため、Reactを利用する開発者の間でインストール時の競合が発生した。コミュニティからは「フラットコンフィグの発想は良いが移行パスが難しかった」という声も上がっており、プラグインごとの実装差異が不安要素として挙げられている。 競合ツールとしてはRust製のBiomeやOxlintが台頭しており、OxcはCPUコア数によっては50〜100倍の性能改善をうたっている。ただしルールカバレッジの面ではESLintの広大なエコシステムに及ばないため、既存のルールセットへの依存度によって乗り換えの判断が分かれる状況が続いている。