AIへの指示ルールは増やすほど良い？モデルの進化に合わせた「引き算」の考え方
AIを使ったコーディングでは、AIにプロジェクト固有のルールや情報を伝えるために「ハーネス」を用意することがあります。本記事で言う「ハーネス」とは、CursorやGitHub Copilotなどのコーディング支援ツールに読み込ませるコンテキスト情報やルール定義ファイルのことで、具体的には.cursorrulesやAGENTS.mdといった形で管理されるものを指します。
既存のコードの書き方や設計方針、プロジェクト内のルールなどをあらかじめAIに理解させておくことで、その案件に合ったコードを生成しやすくするための仕組みです。
こうしたハーネスは、AIの出力を安定させるうえで役立ちます。一方で、AIそのものの性能が上がっていくにつれて、「どこまで細かくルールを作り込む必要があるのか」も変わってきています。
一度作ったハーネスをそのまま使い続けるのではなく、AIの進化に合わせて不要になったものを減らしていく。今回は、そんな「引き算」の考え方について整理します。
目次
そもそもハーネスは何のために作るのか
AIにコーディングを依頼するとき、AIはそのプロジェクト固有の事情を最初から知っているわけではありません。
たとえば、以下のような内容は案件ごとに異なります。
- どのようなHTML構造にするのか
- CSSをどのようなルールで書くのか
- 既存のコンポーネントをどう利用するのか
- ファイルやクラスをどのように命名するのか
- プロジェクト内で避けるべき実装は何か
そこで、AIが作業するときに必要なルールや情報をあらかじめ整理し、参照できるようにしておきます。AIがまだ十分に文脈を読み取れなかった頃は、こうした情報を細かく用意することが、生成結果の精度を高めるために重要でした。
AIの性能が上がると、以前必要だった指示が不要になることもある
AIは継続的に性能が向上しています。たとえば、GPT-4からGPT-4oへの移行や、Claude 2からClaude 3シリーズへの進化に伴い、コードベース全体の文脈を読み取る精度が大幅に向上した事例があります。こうした背景には、モデルのコンテキストウィンドウの拡大や、コードベース全体を参照・インデックス化する機能の強化があります。
以前は細かく説明しなければ意図したコードを生成できなかった内容でも、現在のAIでは、既存コードを読み取っただけである程度判断できるケースが増えています。そのため、以前作ったハーネスの中には、現在のAIにとっては必要以上に細かい指示になっているものもあります。
もちろん、プロジェクト固有のルールまでなくせるわけではありません。しかし、AIが自分で判断できる部分まで細かく指示し続けると、ハーネスそのものが大きくなり、管理する情報も増えていきます。
また、AIを単発の指示に応答させるだけでなく、複数の作業を自律的に進める「AIエージェント」として活用する場面も増えています。エージェントとして動かす場合、ハーネスはその場その場の指示だけでなく、一連のタスクを通じて参照され続けるコンテキストとしての役割を持つため、不要な情報が残っていると判断のブレにつながりやすくなります。
AIの性能が上がるほど、「何を追加するか」だけでなく、「何を残す必要があるのか」を考えることが重要になります。
ハーネスは一度作ったら完成ではない
ハーネスを作ると、それ自体が一つの成果物として扱われがちです。しかし、AIが短期間で変化していくことを考えると、一度作ったハーネスをそのまま長期間使い続けるのは必ずしも適切ではありません。
数か月前には必要だったルールが、現在のAIではそのルールがなくても問題なく処理できる場合があります。逆に、AIの使い方やプロジェクトの進め方が変われば、新しいルールが必要になることもあります。
そのため、ハーネスは「完成させて終わり」ではなく、AIや開発環境の変化に合わせて見直していくものとして考えた方がよいでしょう。
追加するだけでなく、削って試す
ハーネスを改善するときは、問題が起きるたびにルールを追加していく方法が分かりやすいかもしれません。ただし、追加を繰り返していると、いつの間にか大量のルールが蓄積してしまいます。
そこで必要になるのが、逆にルールを減らしてみることです。たとえば、ある指示を外した状態でAIにコードを生成させ、結果がほとんど変わらないのであれば、その指示はすでに不要になっている可能性があります。
削除や簡略化を検討しやすい指示の例としては、次のようなものが挙げられます。
- 汎用的なコーディングのベストプラクティスに関する記述（最新モデルが標準で踏まえているもの）
- 利用しているフレームワークやライブラリの慣習的な書き方（最新モデルが学習済みで自動認識できるもの）
- 既存コードのパターンから十分に推論可能な命名規則や構造のルール
「このルールは昔必要だったから残す」のではなく、現在のAIでも本当に必要なのかを確認する。こうした見直しを繰り返すことで、ハーネスをシンプルな状態に保つことができます。
プロジェクトごとに必要なハーネスは異なる
ハーネスをどこまで作るべきかに、すべての案件で共通する正解があるわけではありません。新規開発なのか、長く運用されている既存サイトなのかでも必要な情報は変わります。また、コーディング規約が厳密に決まっている案件と、比較的自由度の高い案件でも違います。
そのため、社内でAI活用を標準化する場合でも、すべてのプロジェクトに同じハーネスをそのまま当てはめるのではなく、共通化できる部分と案件ごとに調整する部分を分けて考える必要があります。
共通する基本ルールはまとめつつ、必要に応じてプロジェクト固有の情報を追加する。その方が、ハーネスを管理しやすく、案件ごとの違いにも対応しやすくなります。
AIの変化が速いからこそ、定期的な見直しが必要になる
AI関連の技術は変化が速く、数か月前の方法がそのまま最適とは限りません。新しいモデルが登場すれば、これまで細かく指示していた内容をAI自身が判断できるようになることもあります。そのため、AI開発の環境を整える際には、最初にどれだけ作り込むかだけでなく、その後どのように更新していくかまで考えておく必要があります。
ルールを追加した理由が今も残っているのか。AIの性能が変わったことで不要になったものはないか。逆に、新たに必要になった情報はないか。定期的に確認することで、現在のAIに合った状態を維持できます。
ハーネスは「足し算」だけでなく「引き算」で考える
AIを業務に取り入れる際は、出力のばらつきを抑えるために、さまざまなルールを追加したくなります。もちろん、必要な情報を整理してAIに渡すことは重要です。一方で、ルールが増え続ければ、それを管理するための手間も増えていきます。
AIが進化しているからこそ、「以前必要だったから」という理由だけでルールを残し続けるのではなく、現在も本当に必要なのかを確認することが重要です。
必要なものは残し、不要になったものは減らす。これからのAI活用では、作り込む技術と同時に、適切に引き算していく設計も求められそうです。
よくある質問（FAQ）
Q. AIコーディングにハーネスは必ず必要ですか？
必ずしもすべてのケースで大がかりなハーネスが必要とは限りません。新規開発やシンプルな実装であれば、AIだけでもある程度対応できる場合があります。一方、既存サイトや独自の開発ルールがあるプロジェクトでは、必要な情報を整理してAIに参照させることで、既存環境に合ったコードを生成しやすくなります。
Q. ハーネスにはどのような情報を入れればよいですか？
既存コードの構造やコーディング規約、利用しているコンポーネント、プロジェクト固有のルールなどが候補になります。ただし、情報を増やすこと自体を目的にせず、AIが作業するために必要なものに絞ることが重要です。
Q. 一度作ったハーネスはどのくらいの頻度で見直すべきですか？
決まった頻度があるわけではありませんが、利用するAIモデルを変更したときや、生成結果の傾向が変わったときは見直すタイミングです。以前必要だったルールを外しても問題なく生成できるようであれば、削除や簡略化を検討できます。
LYZONが提供するWebサービス
Webに関するお悩みは、まずLYZONへ
構築・運用・AIまで、Webに関わる課題をワンストップで対応。まず何ができるかをご覧ください。
2017年にWebデザイナーとしてLYZONに入社。
現在はアートディレクターとしても活動中。
