記事一覧

本記事では、AIコーディングアシスタントに対して開発者がどのような情報を提供しているのかを、大規模に分析した研究を紹介します。

CursorやGitHub CopilotなどのAIコーディングアシスタントは、現在、多くの開発現場で利用されています。そこで注目されているのが、Cursorが提供する「cursor rules」のようなルールファイルです。

今回は、cursor rulesを含む数百件のオープンソースリポジトリを分析した事例から、開発者がAIに伝えるべきだと考えているプロジェクトの文脈情報の全体像を明らかにしていきます。

背景

LLMの性能は、どのようなコンテキストが与えられるかによって大きく左右される、という前提があります。実際、LLMはプロンプトだけでなく、その前後にある文脈的な情報の影響を強く受けることが、これまでの多くの研究によって示されています。

この傾向は、ソフトウェア開発のように複雑な文脈が伴う場面で、より顕著に表れます。というのも、開発者が書くコードは単体で完結することはほとんどなく、既存のプロジェクト内に組み込まれる前提で書かれるのが一般的だからです。また、実際の開発現場では複数人が協力して作業を進めるため、コーディングスタイルや設計の方針、命名規則など、一定のルールを共有し、それに従う必要があります。こうしたルールを無視してしまうと、コードの読みやすさや保守のしやすさが損なわれてしまいます。

つまり、AIにコード生成を依頼する際には、単に「こういう機能を作ってほしい」と指示するだけでは不十分です。プロジェクトの構造やチーム独自のルールなど、背景にある情報もあわせて伝えることで、はじめて実用的なコードが得られるのです。

このような課題に対応するために、CursorをはじめとするAIコーディングアシスタントでは、プロジェクトに固有の方針や制約を開発者が記述できる「ルールファイル」の仕組みが導入されています。たとえばCursorでは、この機能を「cursor rules」と呼び、セッションをまたいでもAIに一貫した指示を与えられるようになっています。ただし、開発者が実際にどのような情報をルールファイルに書き込んでいるのかについては、これまで網羅的な調査は行われていませんでした。

そこで下記では、そうした「AIに与えるコンテキスト」の実態調査結果を取り上げます。

プレミアム会員限定の記事です

記事の購読には、アカウント作成後の決済が必要です。

  • 全記事・論文コンテンツを無制限で閲覧可能
  • 平日毎日更新、専門家による最新リサーチを配信