この研究は AI IDE ルール をそれ自体ひとつのソフトウェア成果物として扱い、それについて二つの問いを立てる。ルールはどのようなカテゴリーに分かれるのか、そしてどのように進化するのか。動機は、ルールが新たに登場した成果物であるにもかかわらず、その分類法は小さなサンプルから導かれたか単一の IDE に限られたものであり、何がルールの変更を促すのか、またルールを変更することに測定可能な効果があるのかを調べた研究がなかったことにある。
手法は混合研究法である。マイニングの側では、著者らは 1,000 件という検索結果の上限を回避するために時間分割の戦略を用いて GitHub Repository Search API に問い合わせ、採用・除外のキーワードと該当するルールファイルの有無で絞り込み、残った各プロジェクトの README または説明文が AI IDE を使って開発されたことを明言しているかを手作業で確認した。その結果、当初の 25,587 件から 83 のプロジェクトが得られ、それらに含まれる 325 のルールファイルから、7,310 件の個別のルールが手作業で切り出された。調査の側では、2025 年 6 月から 2026 年 1 月の間にルールファイルへの変更をコミットした開発者のメールアドレスを収集し、英語と中国語の質問票を送付した。スクリーニング不合格の回答とストレートライニングの回答を除外した後、30 か国からの 99 件の有効回答が残った。
続いて三つの分析が行われる。7,310 件のルールに対するオープンコーディングから、5 つの主要カテゴリーと 25 の副カテゴリーからなる階層的な分類法が得られた。進化の分析では、117 のルールファイルのコミット履歴から変更された 1,894 件のルールを抽出し、雑務的な編集のみのものを除いた 1,540 件を残して、そのうち要因を判定できた 504 件について、背後にある要因を 6 つの理由カテゴリーに分類した。さらに縦断的なコンプライアンス評価として、160 件のルールについて、各ルールの変更の前後 5 コミットにわたってソフトウェア成果物がそのルールにどの程度従っているかを追跡した。これには、各絞り込み段階で人手によるラベル付けと照らし合わせて検証された LLM-as-a-Judge のパイプラインを用いた。
要点
- ルールの分類法は、アーキテクチャと設計、コード実装、開発ワークフローとプロジェクト管理、品質保証、AI 協働の仕様の 5 つの主要カテゴリーからなり、それらは 25 の副カテゴリーに細分される。
- 収集されたルールは具体的なカテゴリーに集中している。ルールが最も多いのはコード実装（26.28%）と開発ワークフローとプロジェクト管理（25.96%）で、最も少ないのは AI 協働の仕様（11.49%）である。単独で最大の副カテゴリーはワークフローの規約で 9.29%、次いでテスト戦略が 8.76% である。
- 調査対象の開発者による評価は逆の順になる。平均重要度の評価が最も高いのはアーキテクチャと設計（5 点満点中 4.16）で、最も低いのは品質保証（3.79）である。品質保証はルールの数が多いにもかかわらずである。副カテゴリーのレベルで評価が最も高い三つは、システムアーキテクチャ（4.25）、設計上の参照と制約（4.19）、AI のコンテキスト管理（4.17）である。このうち一つ目と三つ目は、収集されたルールのそれぞれ 2.67% と 1.76% を占めるにすぎず、論文自身の考察が描き出すのはこの対比である。
- 論文は、副カテゴリーの平均重要度とその標準偏差との間に統計的に有意な負の相関があると報告しており、これを開発者が最も重要と評価するルールほど合意が高いことを示すものと解釈している。ただし、1〜5 の尺度による天井効果が部分的に影響している可能性にも触れている。
- ほとんどの開発者はルールを一から書いてはいない。71.72% は AI でルールを生成してから手直ししており、48.48% は AI がミスをしたときにだけルールを追加する。
- ルールは頻繁に変更され、追加が支配的である。ほとんどのカテゴリーで最も頻繁な操作は追加で、典型的には 50〜80% を占める。変更率が最も高いのはビジネスロジック（39.42%）とディレクトリ構造（37.15%）で、最も低いのはロギングの基準（6.90%）、パフォーマンス最適化（6.97%）、セキュリティプラクティス（7.24%）である。後者の二つでは、変更がある場合は削除が支配的で、それぞれ 65.22% と 61.90% を占め、パフォーマンス最適化の修正率は 0% であった。
- ルールが変更される理由について、マイニングしたコミットの証拠と調査での自己申告は食い違う。マイニングのデータでは拡張（29.17%）とコンテキストの充実（26.59%）が変更の半分以上を占め、修正は 6.35% にすぎない。一方、調査では回答者の 77.78% が修正を主なきっかけとして挙げている。論文はこのギャップをネガティビティ・バイアスに帰している。AI の誤りを直すことは、日常的な拡張よりも強い印象を残すというのである。
- ルールを更新すると、ソフトウェア成果物の平均コンプライアンスは 49.14% から 72.13% へと 22.99% 向上し、論文はこの変化を統計的に有意なものと報告している。効果が最も大きいのは具体的で静的に検証可能なルール ── 依存関係の管理は 64.82%、テスト戦略は 52.73% の向上 ── で、最も小さいのは抽象的なルールであり、プロジェクトのドキュメントは 6.25%、システムアーキテクチャは 3.33% の向上にとどまる。
- コンプライアンスはルールを導入したコミットで最も高くなり（76.03%）、その後のコミットで 65% 前後まで低下する。論文はこれを、ルールが古くなることと、コンテキストウィンドウの複雑さが増すことに帰している。
補足
論文が実務者に示す推奨は、測定したギャップから導かれている。フォーマットや構文のチェックはコンテキストウィンドウを費やさずに従来のリンターに任せること。非機能要件を抽象的な自然言語で記述するのを避け、具体的なコードパターンに変換するか、静的解析ツールに任せること。ルールファイルには追加するだけでなく、定期的にリファクタリングして刈り込むこと。そして、高レベルな記述ではなく、特定のファイルパスやコードの構文に結びついた明示的な発動条件を持つルールを書くことである。
ツール開発者への推奨はその裏返しである。依存関係グラフ、抽象構文木、コミット履歴からアーキテクチャ上の制約を自動的に抽出し、開発者が重視しながらめったに書かない高レベルのルールが書かれるようにすること。.eslintrc や tsconfig.json のような既存の設定ファイルを解析してルールの制約に変換し、開発者にそれを重複して書かせないようにすること。修正は追加として蓄積していくため、ルールファイルに対する矛盾の検出と重複排除の機能を提供すること。そして、開発者の高レベルな意図を、モデルが実際に従う低レベルでアトミックな制約へと分解することである。
著者らは妥当性への脅威を四つのカテゴリーにわたって記録している。内的妥当性については、オープンコーディングには主観的な判断が含まれ、これは二人のコーダーによる協議に基づく合意で緩和されている。LLM による絞り込みにはハルシネーションのリスクがあり、これは人手による正解データと照らし合わせて検証された、三つのモデルの多数決によるアンサンブルで緩和されている。また、縦断的なコンプライアンス分析は時間的な傾向を観察するものであって因果関係を立証するものではない。改善は同じコミットにおける開発者の手作業による調整から生じた可能性も同様にあるからである。構成概念妥当性については、リポジトリの特定はキーワードの一致に頼っており、AI IDE を使いながらそれを明言していないプロジェクトを取りこぼしている。ルールの切り出しには境界の曖昧さが伴う。そしてリッカート尺度には天井効果のリスクがある。外的妥当性については、データセットは主に TypeScript と Web 開発のプロジェクトで、個人開発者か 1〜3 人のチームによって作られたものであるため、知見は大規模なエンタープライズシステムに汎化しない可能性があり、エコシステムそのものも急速に変化している。コンプライアンスのサンプルには別の注意点があり、外的妥当性ではなく内的妥当性の下に記録されている。サンプルは、自動化されたスクリプトが偽陽性なしに遵守を測定できる 160 件のルールに絞り込まれており、著者らが指摘するとおり、そのためにディレクトリ構造や依存関係の管理のような静的に検証可能なカテゴリーが支配的になっている。したがって、その改善はより抽象的なルールには汎化しない可能性がある。