Each language version is independently generated for its own context, not a direct translation.
この論文は、**「AI プログラミング助手（Cursor など）に、開発者がどんな『お守り』や『マニュアル』を書いているのか」**を調査した研究です。
一言で言うと、**「AI に『こうやって働いてね』と教えるための『開発者のメモ』を分析した」**という話です。
以下に、難しい専門用語を避け、日常の例え話を使って分かりやすく解説します。
🍳 料理の例え：AI は「天才シェフ」だが、レシピは必要
想像してください。あなたが**「どんな料理でも作れる天才シェフ（AI）」を雇ったとします。
でも、このシェフには「あなたの家の冷蔵庫の中身」も「あなたの家族の好み」も「いつもの味付け」**も分かりません。
- 失敗例： シェフに「パスタを作って」とだけ言うと、彼は「スパゲッティ・ボロネーゼ」を作りますが、あなたの家族は「トマトソースが苦手」で、冷蔵庫には「牛乳しかない」状態かもしれません。
- 成功例： 事前に「うちの冷蔵庫には牛乳しかないこと」「トマトは嫌い」「いつもはパスタよりリゾット風にする」「塩分控えめで」という**メモ（ルール）**を貼っておけば、シェフは完璧な料理を作れます。
この論文は、世界中の開発者が**「AI シェフに貼っているメモ（Cursor Rules）」を 401 件も集めて分析し、「どんなメモが書かれているのか」**を分類しました。
🔍 発見された 5 つの「メモの種類」
開発者が AI に残しているメモは、大きく分けて 5 つのタイプに分類されました。
1. 🏢 プロジェクト情報（「このお店はどんな店？」）
- 内容： 「このアプリは何を作るものか」「使う技術は何か（Python か JavaScript か）」など。
- 例え： 「この店はイタリアンレストランです。材料はオーガニック限定です」というお店の紹介文のようなもの。
- 目的： AI が「何を作ればいいか」の全体像を理解するため。
2. 📏 慣習・ルール（「ここはこう書く決まり」）
- 内容： 名前付けのルール、コードの書き方、ファイルの置き場所など。
- 例え： 「店内では靴を脱いでください」「メニューは左から右へ並べる」というお店のルールやマナー。
- 目的： 誰が作っても同じような見た目で、整理されたコードになるようにするため。
3. 📜 ガイドライン（「こうあるべきだ」という指針）
- 内容： テストの重要性、セキュリティ対策、パフォーマンス重視など、高レベルなアドバイス。
- 例え： 「料理は必ず味見をしてから出すこと」「火傷しないように注意すること」という職人の心得やベストプラクティス。
- 目的： 品質を高く保ち、失敗を防ぐため。
4. 🤖 AI 向け指示（「あなたへの特別な注文」）
- 内容： 「推測せずに確認して」「この役割（ペルソナ）になりきって」「出力はこういう形式で」といった、AI への直接的な命令。
- 例え： 「シェフさん、あなたは『健康志向の料理人』という役になりきってください。もし材料が足りなければ、勝手に変えずに私に聞いてください」というシェフへの具体的な注文。
- 特徴： 人間向けのマニュアルにはない、AI 特有の指示です。
5. 📝 具体例（「見本」）
- 内容： 「良いコードの例」「悪いコードの例」。
- 例え： 「こんな料理の盛り付けが理想です（写真付き）」という見本写真。
- 目的： 言葉で説明するより、見本を見せた方が伝わるため。
💡 面白い発見（調査結果）
この研究でわかった面白いことは以下の通りです。
言語によってメモの量が違う：
- Python や JavaScript（自由な言語）を使うプロジェクトは、AI が迷わないように**「詳しいメモ」**を多く書きます。
- Java や Go（厳格な言語）を使うプロジェクトは、言語自体が厳しすぎるため、AI が勝手に推測しやすいので、メモは少し少なめです。
- 例え： 自由な料理（和食など）は「味付けは適当で」と言えないのでレシピが必要ですが、厳格な料理（寿司など）は「米の温度は 30 度」と決まっているので、余計な説明が不要な感じです。
コピー＆ペーストが多い：
- 約 3 割のメモは、他の人のメモやテンプレートをそのままコピーしています。
- 例え： 「有名なシェフのレシピ本」をそのまま貼っているような状態です。
新しいプロジェクトほど「AI への注文」が多い：
- 最近作られたプロジェクトほど、「AI への特別な指示（ペルソナ設定など）」を多く含んでいます。
- 例え： 新しいお店は「新しいシェフへの注文」に熱心ですが、昔からあるお店は「いつものやり方」で済ませている感じです。
🚀 この研究が教えてくれること（今後の展望）
この研究は、**「AI と人間がより仲良く働くためにはどうすればいいか」**を教えます。
AI に「何を知っているか」を教える：
開発者は「AI はすでにコードを読んでいるから、同じことを書かなくていい」と思っているかもしれません。でも、AI は「文脈（コンテキスト）」を正しく理解していないことが多いです。開発者は、「AI がすでに知っている情報」と「新しく伝えるべき情報」の区別を学ぶ必要があります。
自動生成ツールの進化：
「どんな言語や分野なら、どんなメモが必要か」がわかったので、**「プロジェクトに合わせて自動で最適なメモ（ルール）を作ってくれるツール」**が作れるようになります。
教育の必要性：
初心者は「何を書けばいいか」が分からないことが多いです。この研究でわかった「5 つのメモの種類」を教育に使えば、誰でもすぐに AI と仲良く働けるようになります。
まとめ
この論文は、**「AI という新しいパートナーと働くために、人間がどんな『メモ』を書いているか」を分析し、「より良いメモの書き方」**を見つけ出そうとしたものです。
AI に「天才」になってもらうには、人間が「良い上司（または良い注文主）」になって、適切な指示を出すことが重要だというメッセージが込められています。
Each language version is independently generated for its own context, not a direct translation.
論文「Beyond the Prompt: An Empirical Study of Cursor Rules」の技術的サマリー
本論文は、大規模言語モデル（LLM）を活用したコーディング支援ツール（特に Cursor IDE）において、開発者がプロジェクト固有の文脈をどのように「Cursor Rules（.mdc ファイル）」として記述しているかを初めて大規模に実証的に調査した研究です。
以下に、問題定義、手法、主要な貢献、結果、および意義について詳細をまとめます。
1. 研究の背景と問題定義
LLM のコード生成能力は、単なるプロンプトだけでなく、提示される文脈（コンテキスト）の質と量に大きく依存します。ソフトウェア工学の分野では、既存プロジェクトのアーキテクチャ、コーディング規約、チームの慣習などを LLM に理解させることが不可欠です。
近年、Cursor IDE などのツールでは、開発者がプロジェクト全体に適用される永続的な指示（ルールファイル）を記述する機能が導入されました。しかし、以下の点について未解明なままです。
- 開発者が実際にどのような文脈を重視してルールを記述しているのか？
- プロジェクトの種類やプログラミング言語によって、記述される内容に偏りがあるのか？
- 従来のドキュメントと、LLM 向けの指示（プロンプトエンジニアリング）の境界はどのように変化しているのか？
これらの不明瞭さは、AI ツールの設計改善や、開発者が効果的にツールを利用するための指針不足につながっています。
2. 研究方法論
本研究は、オープンソースコミュニティで利用されている401 のリポジトリを対象とした質的・量的な混合研究です。
- データ収集: Sourcegraph を用いて、
.mdc 拡張子を持つファイル（Cursor Rules）を含む GitHub のパブリックリポジトリを収集し、英語で記述された実用的なルールファイルを 401 件抽出しました。
- データセット: 2008 年から 2025 年にかけて作成されたリポジトリで、TypeScript (51.4%)、Python (15.0%)、Go (6.0%) などが主要言語です。
- 分析手法:
- 質的コーディング: 30 のリポジトリを標本抽出し、人間のアナリストがテーマ分析（Thematic Analysis）を行い、コード体系（Taxonomy）を構築しました。
- LLM 支援コーディング: 構築したコード体系に基づき、LLM（Gemini-2.5-flash）を用いて残りの全データ（401 リポジトリ、約 69,409 行）を自動ラベリングしました。人間による評価との一致率（Cohen's Kappa）は 0.64〜0.71 であり、信頼性を確保しています。
- 統計分析: プログラミング言語、アプリケーションドメイン、リポジトリの年齢などによる文脈提供の差異を分析しました。
3. 主要な貢献：文脈の分類体系（Taxonomy）
開発者が記述する文脈を、以下の5 つの主要カテゴリと20 の詳細コードに分類しました（Table 1 参照）。
- Project（プロジェクト情報）:
- 技術スタック、環境設定、アーキテクチャ概要、ファイル構造、最近の変更点など。従来のドキュメント（README など）に近い内容です。
- Convention（規約）:
- コードスタイル、命名規則、フレームワーク固有の慣習、ディレクトリ構成など。プロジェクト内の統一性を保つためのルールです。
- Guideline（ガイドライン）:
- 品質保証（テスト、デバッグ）、設計原則（関心の分離）、パフォーマンス、セキュリティ、コミュニケーション手法など。より抽象的なベストプラクティスです。
- LLM Directive（LLM 向け指示）:
- 本研究で特に注目されたカテゴリ。 LLM 自体の振る舞いを制御する指示です。
- Behavior: 確認質問をする、推測を避ける、自己検証を行うなど。
- Workflow: 思考プロセスのステップを指定する（例：まず分析し、次に計画する）。
- Persona: 「Python の専門家として振る舞う」などの役割定義。
- Formatting/Granularity: 出力形式や詳細度の指定。
- Example（例）:
4. 主要な結果と知見
RQ1: プログラミング言語による違い
- 静的型付け言語（Go, C#, Java）: 型システムが厳格であるため、LLM への追加文脈（特に型に関するもの）は比較的少ない傾向にあります。
- 動的型付け言語（JavaScript, PHP）: 型チェックがランタイムで行われるため、より多くのガイドラインやプロジェクト文脈を提供する傾向があります。
- PHP: 多様なコーディングスタイルが存在するため、他の言語に比べて最も多くの文脈（平均 207 コード）が提供されていました。
- C#: 企業向けやゲーム開発で使われるため、LLM 向けの指示（Behavior など）が相対的に多い傾向が見られました。
RQ2: アプリケーションドメインによる違い
- 複雑なプロジェクト（データ分析、システム基盤）: 具体的な「例（Example）」を多く提供し、LLM に複雑なワークフローを理解させようとしています。
- LLM エージェント開発: 予測不可能なタスクが多いため、「ガイドライン（Guideline）」や「LLM 指示」が重視されます。
- Web 開発: 情報源が豊富であるため、プロジェクト固有の文脈（Project）は相対的に少ない傾向があります。
RQ3: ルールの再利用性
- 全コード行の約**28.7%**が重複していました。
- 「LLM 指示」や「規約」の分野では、コミュニティのテンプレート（
awesome-cursorrules など）や依存関係のドキュメントからのコピペが頻繁に行われています。
- これは、開発者が新しいツールに対して「何を記述すべきか」を模索し、既存の成功事例を流用している現状を示しています。
RQ4: 文脈の共起性
- 多くの開発者は単一の項目だけでなく、複数のカテゴリを組み合わせて包括的な文脈を提供しています（全カテゴリを含むリポジトリが約 25%）。
- しかし、LLM を混乱させないよう、1 リポジトリあたりのユニークなコード数は中程度（中央値 9 程度）に抑えられている傾向があります。
RQ5: 時間的変化（リポジトリの年齢）
- 新しいリポジトリ: LLM の能力や限界を理解しており、**「LLM 指示（LLM Directive）」**をより多く含んでいます。
- 古いリポジトリ: 従来のドキュメントをそのまま流用する傾向が強く、LLM 特有の指示は少ないです。
- 時間が経過するにつれて、プロジェクト詳細の記述は減り、維持管理に必要なガイドラインや LLM 指示に焦点が移る傾向が見られました。
5. 意義と将来への示唆
本研究は、AI コーディング支援ツールの設計と利用において以下の重要な示唆を与えます。
- 文脈の透明性（Context Transparency）の向上:
- 開発者は AI が既にアクセスできる情報（外部ドキュメントなど）を重複して記述しているケースが多く、文脈予算の無駄遣いになっています。AI が「何を知っていて、何を知っていないか」を可視化する UI やフィードバック機能の必要性が示唆されました。
- 文脈を考慮したルール生成ツールの開発:
- 現在のルール生成はテンプレートベースですが、プロジェクトの言語やドメインに最適化されたルールを自動生成するツールの可能性が示されました。
- 教育とベストプラクティスの確立:
- 開発者が「LLM 指示」の重要性に気づき始めたことは、プロンプトエンジニアリングの教育が効果的であることを示しています。しかし、まだ多くの開発者が従来のドキュメント記法に依存しているため、LLM 向けドキュメントのベストプラクティス（例：LLM の振る舞いをどう制御するか）の普及が必要です。
- 効果の定量化:
- 現在のルールは開発者の直感に基づいており、どの文脈タイプが実際のタスク成功率に寄与するかは未解明です。今後の研究では、異なる文脈タイプがコード生成の品質に与える影響を定量的に評価することが求められます。
結論
本論文は、開発者が LLM と協働する際に「何を、どのように」指示しているかを初めて体系的に解明しました。得られた分類体系は、より文脈を理解し、開発者の意図を正確に汲み取る次世代の AI コーディングアシスタントを設計するための基礎データとなります。また、開発者自身が AI を効果的なパートナーとして活用するための指針ともなり得ます。