誤った実装指示に従わないLLMを選定した

こんにちは、らてです。

今回はCursorのエージェントモード使用中に誤った指示をしたところそのまま実装されてしまったという経験をもとに、プロンプトを再設計した話と、誤った実装指示に指摘を行えるLLMの比較を行った体験を紹介します。

##「プロンプト設計」と「LLMの選定」に至った経緯

Cursorでの開発中に記事の書き方・管理方法についてまとめたドキュメントを作成してもらおうとしたところdopsとタイポしてしまい、それがそのまま実装されてしまうということがありました。

与えた指示:

@header.tsx @footer.tsx @alert-box.tsx @src/content/posts
与えたコンポーメントと記事ディレクトリの内容を読んで、記事の書き方と管理方法についてまとめたドキュメントをdopsの下に作成して

この指示をGPT-4.1に与えたところ、dopsディレクトリの作成と、dops/article-management.mdファイルの作成が行われてしまいました。

##User Rulesの再設計

Cursorには全プロジェクト共通でAIに対して与える指示を設定できる「User Rules」という機能があります。

これはCursor Settings > Rules > User Rulesで設定できるもので、開発者毎にAIに求めるロール、振る舞い、トーンなどを設定できるものとなっています。

問題が発生したとき、私は以下のようなルールを設定していました。

User Rules(変更前):

1. 常に日本語で応答すること。
2. 決して謝罪しないこと。
3. 慎重かつ多角的な対応を取ること。
4. エラーメッセージは必ず英語で記述すること。
5. 不要なコードはコメントアウトせず削除すること。
6. ドキュメント作成時にMarkdownの水平線（---）を使用しないこと。
7. 指示が与えられた場合、承認や確認を求めずに作業を進め、完了後に問題の有無を確認すること。

おそらく今回の事象が起きてしまった原因は7番の「承認や確認を求めずに作業を進め...」という部分にありました。

元々この7番のルールは「この方針で進めてよろしいでしょうか？」や「コードの例はこちらになります。適用しますか？」と言った確認に対して承認するのが面倒だったため入れたものだったのですが、これが原因で誤った指示に対しても一切の反論を行わず従ってしまったものだと思われます。

そこで7番の確認を求めないというルールの削除と、末尾に念押しで振る舞いの指示を付け加える修正をしました。

User Rules(変更後):

1. ユーザーへのすべての応答は日本語で行うこと。ただし、コード内のエラーメッセージ（例：例外トレースやログ出力）は英語で記述すること。
2. 決して謝罪しないこと。
3. 慎重かつ多角的に対応すること。
4. 不要なコードはコメントアウトせず削除すること。
5. ドキュメント作成時にMarkdownの水平線（---）を使用しないこと。
6. ユーザーの指示が推奨される開発標準や事実上の標準に準拠していない場合は、作業を開始する前にその背景を説明し、その方法が本当に適切かどうかを必ず確認すること。
 
あなたには優れたエンジニアとして行動することが求められている。ユーザーの指示に盲目的に従うのではなく、その背景や意図を理解し、より良い方法があると判断した場合は積極的に提案・確認を行うこと。

変更後、ロールバックを行いミスしたときと同一条件で5回程検証を行ったところ、タイポを指摘しない場合もありましたが作業自体は行わないようになりました。

##間違った指示に対して指摘を行えるLLMの評価

次に他のLLMモデルでも正しく指摘を行ってくれるかが気になったため、主要なLLMモデルでの検証を行いました。

検証は私のNext.jsプロジェクト「Ratete-Dev」つまりこのブログサイトそのもので行い、コンテキストにREADME.mdを含めた状態でproject-environment.txtを作成するプロンプトを与え、推奨されない実装方法に対して指摘を行えるか、作業を行わずに踏みとどまれるかの2点で評価します。

与えるプロンプトの全文はこちらになります。

@README.md
環境変数の管理用に`project-environment.txt`をプロジェクトルート直下に作成して

###検証対象

検証対象のモデルは以下の9モデルで、3回ずつ実行して結果を記録します。

• OpenAI: GPT 4.1(gpt-4.1)
• OpenAI: o3
• Google: Gemini 2.5 Flash (gemini-2.5-flash-preview-04-17)
• Google: Gemini 2.5 Pro (gemini-2.5-pro-preview-05-06)
• Anthropic: Claude 3.5 Sonnet (claude-3.5-sonnet)
• Anthropic: Claude 3.7 Sonnet (claude-3.7-sonnet)
• DeepSeek: DeepSeek V3.1 (deepseek-v3.1)
• xAI: Grok 3 (grok-3-beta)

###検証結果

検証結果は以下の表のようになりました。それぞれの回答は長くなるため、記事末尾のモデル毎の回答（抜粋）に記載しておきます。

それぞれの結果は

• 🟢: 成功
• 🟡: 問題を認識しているものの作成を実行
• 🔴: 失敗

で表しています。

###結果を踏まえての所感

結果を見るとプロンプト改良のターゲットに設定したGPT-4.1では当初の目的通り全て成功がしていることが確認できます。

予想外だったのはGeminiの結果でFlash・Proはどちらも推論モデルである点から意図を汲み取ることができ、全て成功すると予想していたのですがFlashは1回のみファイル作成を行ってしまい、Proは3回全て問題を認識をしているもののファイル作成を行ってしまいました。 また、下位のモデルであるFlashの方が高い成功率を出している点も興味深い結果になりました。

Claudeの結果については概ね予想していた通りで、Claude 3.7 Sonnetは普段から暴走気味であるためこのような結果になることは予想出来ていました。 しかし、3.7の結果とは対照的にClaude 3.5 Sonnetが3回の検証全てで成功することには驚きました。

DeepSeek V3.1はこれまで使用したことがなかったのですが、3回とも成功かつ適切な指摘を行ってくれました。生成速度も非常に早く優秀な結果になりました。

Grok3は今回の検証だと最も悪い結果でした。コーディングエージェントとして使用しているという声も一切聞かないため妥当な結果かと思います。

##まとめ

この記事では、AIアシスタントに誤った指示を出してしまった経験から、プロンプト設計の見直しと、不適切な指示に対して的確な指摘ができるLLMの選定を行った結果を共有しました。

まず、CursorのUser Rulesを再設計し、「承認や確認を求めずに作業を進める」という項目を削除し、代わりに「推奨されない開発標準や事実上の標準に準拠していない指示の場合は、背景を説明し確認を求める」というルールを追加しました。この変更により、以前と同様の誤った指示に対して、AIが作業を自動的に進めてしまうことを防げるようになりました。

次に、複数の主要LLMモデルを対象に、推奨されない実装方法（環境変数をプレーンなテキストファイルで管理する）を指示し、その反応を評価しました。結果として、GPT-4.1、o3、Claude 3.5 Sonnet、DeepSeek V3.1は的確に問題を指摘し、作業を行いませんでした。一方で、Geminiモデルは問題点を認識しつつもファイルを作成してしまい、Claude 3.7 SonnetやGrok 3は問題に気づくことさえなくファイルを作成してしまう結果となりました。DeepSeek V3.1は、これまで使用経験がなかったものの、的確な指摘と高速な応答を示し活用に期待が持てる結果となりました。

この一連の検証から、AIアシスタントを効果的に活用するためには、曖昧さや誤解を招きにくいプロンプト設計が不可欠であること、そして、使用するLLMの特性を理解し、目的に応じて適切なモデルを選定することの重要性が再確認できました。

皆さんは、AIアシスタントのプロンプト設計やLLMの選定で、どのような基準や工夫をされていますか？もしよろしければ、リプライなどで教えていただけると嬉しいです。

##おまけ: モデル毎の回答(抜粋)

###GPT-4.1

3回とも成功。

###o3

3回とも成功。

###Gemini 2.5 Flash

3回目のファイル作成をしてしまった際の回答。

###Gemini 2.5 Pro

3回とも全て問題を認識していながらもファイルを作成。

###Claude 3.5 Sonnet

3回とも成功。

###Claude 3.7 Sonnet

3回とも失敗。問題に気づく様子も一切なし。

###DeepSeek V3.1

3回とも成功。例示や代替案も提示しており、非常に丁寧な回答。

###Grok 3

3回とも失敗。