はじめに 1. 注目した次世代ツールの魅力 1.1 Oxlint ── 「今すぐ、設定ゼロで爆速化」 1.2 Biome ── 「これ 1 つで全てが片付く、究極の一本化」 1.3 Deno ── 「セットアップ不要、最高にクリーンな開発体験」 1.4 Ezno ── 「型チェックまで Rust 化する、超未来のコンパイラ」 2. Vue特有の壁： の静的解析問題 3. チームでの議論：「設定ファイル2つは本当に必要か？」 4. 結果 5. 今後の展望 まとめ はじめに フロントエンドエンジニアをしている伊藤と申します。 昨今は、Rust 製のツールが数多く生み出されており、Linter もその波に乗っていると思います。 弊社でも移行をしたブログを書いており、是非下記の記事も読んでみてください。 https://tech.revcomm.co.jp/ai-lint-formatter-oxc 史上稀に見る大波が来ている時代に、私も颯爽と波に乗ろうとしました。 そしてどういった結論に至ったかご紹介させていただきます。 注: 本記事の検証は2026年9月10日時点、Oxlint v1.82.0 / Biome v2.5.12 で行っています。この領域は変化が速いため、お読みいただく時点では状況が変わっている可能性があります。 1. 注目した次世代ツールの魅力 1.1 Oxlint ── 「今すぐ、設定ゼロで爆速化」 最大の魅力：既存のプロジェクトにノーリスクで追加できる メリット ESLint の 50〜100 倍高速 ： 数万行のコードも一瞬でスキャンが終わります。 設定ファイルが不要 ： インストールして実行するだけで、プロ級のバグ検出ルールが最初から動きます。 既存の ESLint と併用可能 ： 重い処理（バグチェック）は Oxlint に任せ、複雑なカスタムルールだけ ESLint に残す「いいとこ取り」ができます。 1.2 Biome ── 「これ 1 つで全てが片付く、究極の一本化」 最大の魅力：Linter と Formatter が融合したオールインワン構造 メリット ESLint と Prettier の多くの用途を一本化できる ： 個別にプラグインを組み合わせる煩わしさから解放されます（ただし後述の通り、Vue の <template> 部分は現状 ESLint との併用が前提になる場面が残っています）。 設定の衝突ゼロ ： Linter と Formatter が同じ思想で作られているため、「Linter と Prettier のルールがバッティングして動かない」という定番のストレスがありません。 圧倒的な構文解析の正確さ ： エラーがあっても壊れたコードを器用にパースし、親切なエラーメッセージを出してくれます。 1.3 Deno ── 「セットアップ不要、最高にクリーンな開発体験」 最大の魅力：最初からすべてが揃っている「環境」そのもの メリット ： ツール選定やインストールの手間がゼロ ： deno lint と deno fmt が最初から内蔵されています。 package.json に大量の依存関係を書く必要がありません。 標準で Web 標準に準拠 ： ブラウザと同じ API をそのままサポートしているため、環境ごとの差異に悩まされません。 Node.js との互換性も強力 ： 近年は Node.js のパッケージもそのまま動くため、敷居が非常に低くなっています。 注意: Deno は Linter 単体のツールではなく、ランタイムとツールチェーンそのものです。既存の Node.js プロジェクトに deno lint だけを差し込むのではなく実行環境ごと移行する話になるため、Oxlint / Biome / Ezno とは比較の土俵・移行規模が異なる点に注意してください。 1.4 Ezno ── 「型チェックまで Rust 化する、超未来のコンパイラ」 最大の魅力：JavaScript の限界を超える、圧倒的に賢く高速な型解析 メリット ： TypeScript（tsc）より遥かに高速 ： 現在、フロントエンド開発で一番時間がかかる「型チェック」のプロセスを Rust で爆速にします。 型推論がスマート ： コードの型をより深く、正確に推論してくれるため、開発者が型定義を細かく書く手間を減らせます。 バグを未然に防ぐ先進性 ： 副作用（Side Effects）の検知など、従来の TypeScript よりもさらに一歩進んだ安全なコード検証が可能です。 注意: ただし Ezno は本記事執筆時点（2026年9月）でまだ feature-complete ではなく、tsc との完全互換を目指しているわけでもありません。既存の大規模プロジェクトの型チェックをそのまま置き換えられる段階ではなく、将来性に注目したい実験的プロジェクトという位置付けです。 どれも高速性を売りにしており、React では非常に乗り換えやすく恩恵も受けられます！ 実際に私もローカルでBiomeの設定を試してみましたが、かなり早かったです。 ではそのまま導入して、Rust の恩恵を受けようとしました。 ただ、Vue になると少し話が変わってくるんです・・・ 2. Vue特有の壁： の静的解析問題 Vue は、HTML5 の標準仕様である <template> を、独自の便利な形に拡張して使っています。 要素に v-if や v-for を付けたり、 <template> を .vue ファイルの枠組みとして使ったりしています。 普段の開発をしている中で、 v-if や v-for を使わないケースはほぼないと思います。 当然ですが、それらの値もチェックしてくれると思っていました。 ただ、 <template> 内は、Oxlint, Biome ともにチェックしてくれないんです。 実際に最新版（Oxlint v1.82.0 / Biome v2.5.12、2026年9月時点）で試した結果を、以下のサンプルコードとあわせてご紹介します。 <template > < div > <!-- ❌ 1. 壁：Linterがここを見ないため、存在しない変数（タイポ）をスルーする --> < p > {{ userNema }} </ p > <!-- ❌ 2. 壁：Linterがここを見ないため、「下で使われている」と認識できない --> < p > {{ unusedMessage }} </ p > </ div > < / template> <script setup lang="ts"> import { ref } from 'vue' const userMessage = ref ( 'こんにちは' ) // 🔴 <script> 内は見ているので、「定義したのに使われていない！」と怒られる // （実際には上の template で使いたいのに、Linterが template を読めないせいで孤立する） const unusedMessage = ref ( 'これはエラーになります' ) < / s cript> Oxlint（v1.82.0） デフォルトでも vue-plugin オプションを付けても、このサンプルに対しては何も警告を出しませんでした。 userNema のタイポも unusedMessage の誤検知も発生しない代わりに、テンプレート側の静的解析自体がまだ行われていない、というのが実態でした。 Biome（v2.5.12） デフォルト設定ではスクリプト側の noUnusedVariables ルールが .vue ファイルにも適用され、 userMessage・unusedMessage の両方を「未使用」としてエラーにします( unusedMessage は実際にはテンプレート側で使われているので、これは誤検知です)。 ただし html.experimentalFullSupportEnabled を有効にすると、Biomeはテンプレート内での参照を認識できるようになり、 unusedMessage の誤検知は解消されました(本当に未使用な userMessage は引き続き正しく検出されます)。 一方で、フラグを有効にしてもテンプレート内の userNema のようなタイポを検出するルールはまだ無く、不正な変数参照を見逃す問題は解消されません。 上記の検証からわかる通り、テンプレート内の静的解析はRust製Linter単体ではまだ完結できません。Biomeは実験的フラグ付きで一部の誤検知を解消できるようになってきていますが、テンプレート内のタイポ検出のような踏み込んだチェックまでは、依然として eslint-plugin-vue に頼る必要があります。 つまり、必要なVue固有のルールと各ツールの対応状況次第では、OxlintまたはBiomeとESLintを併用する必要があるということです。 3. チームでの議論：「設定ファイル2つは本当に必要か？」 Rust製Linter を導入するか、一旦は ESLint のままにするか。 どちらを選択するか検討するため、メリット・デメリットを出してみました。 メリット 圧倒的な高速化 ： 従来のJavaScriptなどで書かれたLinter（ESLintなど）に比べ、数倍〜数十倍高速に動作します。大規模なコードベースでも ミリ秒単位 で処理が終わるため、CI/CDの実行時間を大幅に短縮し、開発者の待ち時間をほぼゼロにします。 開発の快適化 ： 保存時の自動整形や pre-commit フックでの実行が劇的に速くなります。 簡単な導入 ： Rust製ツールはコンパイル済みのシングルバイナリとして配布されることが多いため、環境構築やCIでのセットアップが非常にシンプルになります。 デメリット 二重管理 ：（一番の懸念） Rust製フロントエンドLinter（BiomeやOxcなど）は、 .vue ファイルの構文（HTMLテンプレートやVue固有の構文ルール）を完全にサポートしていません。 そのため、Vue固有のルール（ vue/valid-template-root など）をチェックするには、結局従来の ESLint（eslint-plugin-vue） を残さなければならなくなります TypeScript/JavaScript部分： 爆速のRust製Linter（Biomeなど）でチェック Vueファイル・テンプレート部分： 従来のESLintでチェック プラグインエコシステムの未熟さ ： 歴史のあるESLintなどのように、コミュニティが作った無数のサードパーティ製プラグインを自由に追加することが難しい場合があります。独自のルールを追加したい場合のハードルが高めです。 ルールや構文の追従ラグ： 言語（特にJavaScript/TypeScriptやPython）の新機能や新しい構文が登場した際、Rust側でのパーサ（構文解析器）の対応にわずかなタイムラグが生じることがあります。 4. 結果 結果は、デメリット部分の二重管理の懸念部分が大きく、現状のESLint（eslint-plugin-vue）で管理する方を選びました。 手元の計測で速度については、申し分ないことが立証済みでした。 導入するメリットも大いに感じているものの、2つのLinterを併用する点を上回るほどではないと判断しました。 5. 今後の展望 Biome は既に html.experimentalFullSupportEnabled フラグで Vue SFC の実験的サポートを始めており、Oxlint も vue-plugin オプションなどVue向けの機能を増やしてきています。 「サポートされるのを待つ」というよりも、「実験的サポートがどこまで安定するか・テンプレート内のタイポ検出のような踏み込んだチェックまでカバーされるか」を継続的にウォッチしていく、というのが今の立ち位置です。 各プロジェクトの現状を、ご紹介いたします。 Biome v2.4(2026年2月)で Vue・Svelte・Astro 対応を実験的機能からプロダクション標準に近づける取り組みが発表されました。既存のリンティングルールを強化し、HTMLライクな言語でも機能するようにする方針です。 https://biomejs.dev/ja/blog/roadmap-2026/#2026-roadmap Oxlint 公式ドキュメント上の制限の記載に、Vue も含まれており、改善してくれるはずだと思います。そして、改善のための issue があり開発が進められているのがわかります。 https://github.com/oxc-project/oxc/issues/23207 https://oxc.rs/compatibility.html そしてなんといっても、Oxlint の開発を支援しているのが Vue の開発者である Evan You さんが立ち上げた VoidZero という会社なんです。 現在のフロントエンドの「ツールの断片化（Linter、Formatter、テストツール、ビルドツールがバラバラで設定が面倒かつ遅い）」という課題を根本から解決するためVite+（ヴィートプラス）が開発され、その中に Oxlint も含まれています。 Vue の開発者が、Vue を見放すはずがないんです！弊社が Oxlint にするのも近いですね！ まとめ Rust 製のツールは非常に高速で、すぐにでも乗り換えたいと思ってしまいます。 ただ、メリット・デメリットや今後の展望を踏まえて、検討するのが大事だなと今回の移行作業を通じて感じました。 どのツールにするかもしっかり検討したいです。 AI で開発を行うと、簡単に実行できるため、検討するのをサボりがちになってしまいます。 そういう意味でも今回はいい勉強になったと思います。 お読みいただきありがとうございました。 次は、Oxlint に移行した話でお会いしましょう。

サイオステクノロジーは、OSS管理ツール「SCANOSS」の 日本国内初の代理店 です。 生成AIでコードを書く比重が上がるにつれ、「動くコードは手に入ったが、それを使っていいか」を確かめる工程が抜け落ちるようになりました。テストは通る。脆弱性スキャンを回していれば、それも通る。しかし、そのコードがどこ由来なのかを見る工程は、どちらにも入っていません。 AIが生成したコードに含まれるOSSは、読んで見分けることができません 。機械的な照合で見える範囲と、機械にも見えない範囲が残ります。 この記事でわかること : 生成されたコードの出所を、読んで見分けられない理由 OSSが混ざっていた場合に、ライセンス種別ごとに何が求められるか 何を見るツールがあり、そのうちコードを見るものはどれか 機械的な照合でも判定できない範囲 このコードにOSSは入っているか 次のコードを読んでください。JavaScriptで、文字列をUTF-8のバイト列に変換する処理です。 // convert string to array (typed, when possible) exports.string2buf = function (str) { var buf, c, c2, m_pos, i, str_len = str.length, buf_len = 0; // count binary size for (m_pos = 0; m_pos < str_len; m_pos++) { c = str.charCodeAt(m_pos); if ((c & 0xfc00) === 0xd800 && (m_pos + 1 < str_len)) { c2 = str.charCodeAt(m_pos + 1); if ((c2 & 0xfc00) === 0xdc00) { c = 0x10000 + ((c - 0xd800) << 10) + (c2 - 0xdc00); m_pos++; } } buf_len += c < 0x80 ? 1 : c < 0x800 ? 2 : c < 0x10000 ? 3 : 4; } // …（UTF-8バイト列への書き込みは中略）… return buf; }; このコードにOSS由来のものが混ざっているか、読んで判定できたでしょうか。 答えは、 このコード自体がOSS です。圧縮ライブラリ pako v1.0.11 の lib/utils/strings.js からの抜粋（MIT）で、後半のバイト列への書き込みは省略してあります。 pako — Copyright (C) 2014-2017 by Vitaly Puzrin and Andrei Tuputcyn / MIT License 見分けられなかったとしても、注意力の問題ではありません。理由は2つあります。 照合すべきOSSが多すぎる 1つ目は単純な話です。世に公開されているOSSのコードすべてと、目の前のコードを突き合わせる作業になります。人間の記憶で照合できる規模ではありません。 そして、これは「珍しく起きること」でもありません。ICSE 2025で発表された LiCoEval は、14のLLMに4,187件のコードを生成させ、既存のOSS実装と強く似ているものがどれだけ含まれるかを測っています。コード生成の性能が高い3モデル（GPT-4o / Claude 3.5 Sonnet / DeepSeek-Coder-V2）では、生成したコードのうち 0.88%〜2.01% が該当しました。14モデル全体で見ると 0.0%〜2.17% まで幅があり、最多はコード生成の性能で下位のCodestral（2.17%）、0件だったのは性能が中位のGLM-4-9B-Chatでした。なお、この測定の対象は2024年時点のモデル群です。モデルは入れ替わるので、この数値がそのまま今のモデルに当てはまるわけではありません。 数字だけ見ると小さく感じますが、 この値は下限 です。論文自身が測定の限界としてこう書いています。 Our striking similarity standard focuses on precision, potentially overlooking cases where LLMs generate code derived from open-source code but fall below our threshold （この判定基準は精度を重視しているため、OSS由来のコードを生成していても閾値を下回るケースは見落とす可能性がある） つまり、実際にはこれより多く起きている可能性があります。 出力に出所の情報が付かない 2つ目のほうが厄介です。人がOSSを持ってくるときは、由来を知っていて、多くの場合ライセンスファイルも一緒に付いてきます。生成された場合は、 何も付いてきません 。 同じLiCoEvalは、モデルが生成したコードについて、ライセンス情報を正しく示せたかも測っています。コピーレフトライセンス（次章で見るとおり、義務がもっとも重い種別）のコードで出所を正しく示せた割合は、GPT-4o・GPT-3.5 Turbo・GPT-4 Turbo・Gemini 1.5 Pro・DeepSeek-Coder-V2・Codestral のいずれも 0.0 。Claude 3.5 Sonnet の 0.4 が唯一の例外でした。 「性能の高いモデルを使えば避けられる」という話でもありません。0.0 が並んでいるモデルには、コード生成の性能で上位3モデルに入る GPT-4o と DeepSeek-Coder-V2 が含まれています。論文自身も、この種のスコアと生成性能が対応しないことに注意を促しています。 a high LICO score, particularly a score of 1 in the absence of any strikingly similar cases, is not meaningful if the model’s code generation performance is poor. Models producing erroneous or chaotic code may naturally avoid striking similarities （コード生成の性能が低いモデルでは、高いスコア（とくに似た事例が0件で満点になる場合）は意味を持たない。誤ったコードや混乱したコードを出すモデルは、そもそも強い類似を避けてしまう） つまりこの手のスコアは、性能が低いモデルほど良く見える向きに歪みます。 モデルを選び直して解決する問題ではありません 。 OSSが混ざっていたら、何をしないといけないのか 「AIが出力したコードの著作権をめぐる争いはまだ決着していないのだから、様子を見ればいい」と考えることもできます。実際、その論点に外から答えは出ていません。 Copilotの出力をめぐる集団訴訟（ Doe v. GitHub ）は、22件の請求のうち20件が地裁で却下され、契約違反とOSSライセンス違反の2件が係属中です。却下された著作権管理情報に関する請求は控訴され、2026年2月11日に第9巡回区で口頭弁論が行われ、判断を待っている状態です（2026年9月3日時点）。 ただし、 混ざっていた場合に何が求められるかは、AIとは関係なく、すでに明文で決まっています 。 種別 代表例 コードに取り込んだ場合に生じること permissive MIT / Apache-2.0 / BSD 著作権表示とライセンス文の 表示 。義務がゼロではありません 弱コピーレフト LGPL / MPL 表示に加えて、 そのOSS部分を改変したならソースの開示 強コピーレフト GPL / AGPL 結合した自社のコードにまで開示義務が及びうる 。AGPLはネットワーク越しに使わせる場合にも及びます 順に見ていきます。permissiveは「自由に使える」と理解されがちですが、表示の義務は残ります。表示を落とせば条件違反です。 弱コピーレフトは、そのOSS部分を改変したかどうかで変わります。改変して配布するなら、その部分のソースを開示することになります。 強コピーレフトは、影響範囲が自分のコード側に及びます。どこまでが「結合」なのかは配布形態や結合方法で変わるため、ここが最も判断の重い領域です。 ただし、同じ種別でも個別のライセンスごとに条件は違います。上の表は種別ごとに何が付いてくるかの傾向で、実際にどの義務が生じるかは、そのライセンスの条文と、結合の形や配布の方法で決まります。どのライセンスを通すかも、使う側が決めることです。 どちらも、どんなライセンスのものが混ざっているかが分かってからの話 です。 ツールは何をしてくれるのか 人間が読んで分からないのであれば、機械に照合させることになります。ただし「OSSライセンスを見るツール」とまとめられているものは、 何を見ているかがそれぞれ違います 。3つに分かれます。 以下は 何を見ている道具なのか の分類で、製品どうしの比較ではありません。冒頭に書いた立場のとおり、この分類には当社が扱う製品も入ります。 何を見ているか 道具 AI生成コードの混入 依存の宣言（manifestとlockfile） Dependency graph ／ dependency-review-action ／ Trivy 映らない ファイルの中のライセンスの記述 ScanCode Toolkit ライセンス文が残っていれば映る コード片の指紋 FossID ／ Black Duck ／ SCANOSS ここで映る 上から順に、見ている対象がコードの内側へ入っていきます。いちばん下の指紋の照合だけが、宣言にもライセンス文にも現れないコードそのものを見ます。この層は製品が限られており、公式ドキュメントで機能を確認できたのは上の3つでした [^1]。 表に載せていない道具にも触れておきます。依存しているパッケージの問題を知らせる仕組みとして広く入っているのが、GitHubの Dependabotのアラート です。 見ているのは、表のいちばん上の層です 。公式ドキュメントを確認した限り、Dependabotのアラートは脆弱性の検出に限定されていて、ライセンスを見る機能への言及がありません。 すでに何かを回しているから、ライセンスまで見えているとは限りません 。 AI生成コードの混入が問題になるのは、 表のいちばん下が扱う範囲 です。宣言されていないコードは、依存の宣言を見るツールには映りません。 [^1]: 同じ層で公式ドキュメントに記述を確認できたものとして、他に FOSSA （ファイル単位の指紋照合・確率的なマッチと明記）と Revenera Code Insight （source-code fingerprints）があります。本記事は各製品の精度・速度・価格の比較は行いません。 機械に任せれば終わりなのか ここまでで「機械に照合させればよい」という話になりますが、機械にも見えない範囲が残ります。 1つは、 手が入るほど当たらなくなる ことです。指紋の照合が強いのは、そのままの形に近いコードです。書き直されたり、別の言語へ移されたりするほど、照合の手がかりは減っていきます。これは特定の製品の性能ではなく、 指紋を照合するという方法そのものの性質 です。どこまで手が入ると外れるのかは、道具によって違います。 もう1つは、 似ていることが由来の証明にはならない ことです。LiCoEvalはこう書いています。 Text similarity alone cannot determine non-independent creation in LLM-generated code. LLMs can produce highly similar code even for unseen samples （テキストの類似度だけでは、LLMが生成したコードが独立創作でないとは判定できない。学習で見ていないサンプルに対しても、LLMは非常に似たコードを出せる） 似ているコードが出てきたとき、それが取り込みなのか、独立して書かれた結果なのかは、機械の出力だけでは決まりません。もちろん機械検出の製品が100%発見してくれるとも言えません。 ただし、限界があることは、機械に照合させない理由にはなりません。 比べる相手は「完璧な検出」ではなく、何も見ていない状態のほう です。完璧に検出できる道具が無いのはこの領域に限りませんが、それでも入れるのは、入れない場合との差が大きいからです。 分担で言うと、 機械が担うのは検出まで です。出てきたものが本当に取り込みなのかを決めるのは人の側に残ります。この分担を先に持っておくと、ツールの出力を「答え」ではなく「候補」として受け取れます。 手元で動かしてみる場合は、SCANOSS の CLI でローカルスキャンを試す手順を 別の記事 にまとめています。インストールからスキャン結果の読み方、SBOM の生成までを扱っています。 なぜこの確認が要るのか AIに書かせたコードは、スキャンにかけて判断するしかありません。 読んで見分けられない以上、出所を確かめる方法がほかに無いからです。 冒頭のコードに戻ります。あれがpako由来だと見分けられなかったのは、照合すべきOSSが多すぎるうえに、生成されたコードには出所が付いてこないからでした。人の目では、どちらも埋められません。書かれる量が増えても、埋まるようにはなりません。 そして、 確かめていないことは、混ざっていないことではありません 。混ざっていた場合に生じる義務は、すでに決まっています。スキャンしていないコードについて言えるのは「混ざっていない」ではなく、「 混ざっているかどうかを言えない 」だけです。生成の速度が上がるほど、その状態のコードが増えていきます。 機械が出せるのは候補までで、そこから先は人が判断します。それでも、候補が出てこなければ判断のしようがありません。 自分のコードに何が入っているかは、外の答えを待たなくても、確かめれば分かります。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 1人がこの投稿は役に立ったと言っています。 The post AI生成コードのOSSライセンス｜自動スキャンが必要な理由 first appeared on SIOS Tech Lab .

Antigravityは自分仕様にカスタマイズできる Antigravityの特徴のひとつが、エージェントの振る舞いをカスタマイズできることです。生成AIに毎回ゼロから指示を出していると、「このプロジェクトではこの書き方にしてほしい」「テストコードではこのルールを守ってほしい」といった同じ説明を何度も繰り返すことになります。