📝

【Cursor / Cline】ほにゃららRulesの功罪:独自のカスタム設定に関する心理的バイアスについて

2025/03/23に公開
11

モチベーション(100%人間)

CursorやClineなどで.rulesを作成することが増えましたが
明確に何を作成すべきで何をすべきでないかはユーザー側の判断に委ねられていることが多いと感じています。
そこに対してそもそもの「作成することによる心理的バイアス」の有無や
「サービス側のPromptの考慮」の有無などについて明確に述べてみようかなと思いました。

以下AIと作った記事です。

はじめに

AIサービスが普及するにつれて、Custom Instructions(カスタム指示)やRulesといった「AIの挙動をカスタマイズする機能」が多くのプラットフォームで提供されるようになりました。一見すると便利に思えるこれらの機能ですが、その実際の効果と、私たちがそれを評価する際の心理的バイアスについては、十分な議論がなされていません。

本記事では、PKM(Policy-Knowledge-Mechanism)フレームワークを用いて、AIカスタム設定の本質を分析し、私たちがそれに対して抱きがちな心理的バイアスを明らかにします。
また、モデルの素の性能を重視するアプローチの利点についても考察します。

まず簡単なチェックから始めましょう。

自己診断チェックリスト

あなたのカスタム設定が実際に効果があるのか、それとも心理的バイアスに影響されているだけなのかを判断するための質問集:

  1. このカスタム設定の効果を、客観的に測定可能な指標で評価できるか?
  2. カスタム設定なしの状態と、ブラインドテスト(どちらがどちらか知らない状態)で比較したことがあるか?
  3. このカスタム設定が機能しなかった例も記録しているか?
  4. モデルのアップデート後も、この設定の効果を再検証しているか?
  5. この設定の「コスト」(メンテナンス、複雑性、柔軟性の低下など)を考慮しているか?

指標での確認やブラインドテストは組織などでrulesを決めるときに有用だと思います。
では、上記の自己診断でうまくいった人もそうでない人も
自分のPromptやRulesをPKMで分析してみましょう。

PKMフレームワークから見るカスタム設定

PKMフレームワークは、AIとのコミュニケーションを三つの機能的要素に分解して理解する枠組みです:

Policy(ポリシー)

  • 定義:AIの行動指針と制約を定義する要素
  • 例:倫理的境界、専門性の限界、表現スタイル規定

Knowledge(ナレッジ)

  • 定義:AIが利用可能な知識基盤を定義する要素
  • 例:事実情報、概念理解、ドメイン特化知識

Mechanism(メカニズム)

  • 定義:AIの思考・処理プロセスを定義する要素
  • 例:思考パターン、出力構成法、精度管理

このフレームワークを用いると、多くのカスタム設定は以下のように分類できます:

  1. Policy中心のカスタム設定

    • 例:「常に簡潔に答えること」「専門用語を使わないこと」
    • 問題点:モデル側のシステムプロンプトと矛盾すると予測不能な動作になりやすい
  2. Knowledge中心のカスタム設定

    • 例:「以下の専門情報を考慮に入れること」「自分の専門は〇〇である」
    • 利点:特定ドメインの正確性向上に効果的
  3. Mechanism中心のカスタム設定

    • 例:「段階的に考えを展開すること」「特定のフォーマットで回答すること」
    • 利点:出力の一貫性向上に効果的

詳しくはこちら(長いので続きを読んでから気になる場合は戻ってくるといいと思います)

https://zenn.dev/tesla/articles/0efaff25096435

カスタム設定と心理的バイアス

カスタム設定の効果を評価する際には、以下のような心理的バイアスが影響していることが多いです:

1. イリュージョン・オブ・コントロール(錯覚的な効果)

AIの挙動を「コントロールしている」という感覚自体が満足感をもたらします。これは実際の効果とは無関係に、主観的な満足度を高める要因になります。

  • コントロール感の満足感: 人間は本質的に環境をコントロールしたいという欲求があります。カスタム設定を行うことで「AIの動作をコントロールしている」という感覚が生まれ、それ自体が満足感につながります。

  • IKEA効果: 心理学で知られる現象で、自分で組み立てたものに対して不釣り合いな価値を感じる傾向があります。カスタム設定も同様に「自分で作った」という事実だけで価値が高く感じられます。

  • 所有感の影響: 自分が設定したルールは「自分のもの」という所有感が生まれ、それが実際の効果と関係なく満足度を高めます。

2. 確証バイアス(確認バイアス)

一度カスタム設定に時間を投資すると、その効果を過大評価し、肯定的な証拠のみに注目する傾向があります。

  • 選択的注目: カスタム設定の効果を評価する際、それが機能している例に注目し、機能していない例を無視または軽視する傾向があります。

  • サンクコスト効果: すでに時間や労力を投資したため、その投資を正当化するために効果を過大評価します。「これだけ時間をかけたのだから、効果があるはずだ」という思考パターン。

  • 成功の帰属バイアス: AIが良い結果を出した場合は「カスタム設定のおかげ」と考え、悪い結果の場合は「モデル自体の限界」と考える傾向があります。

  • 記憶の選択性: 人間の記憶は選択的で、カスタム設定が期待通りに機能した事例をより鮮明に覚えている傾向があります。

ソースを交えた詳しいものはこちらで(DeepResearch)
https://note.com/delta_ipsilon/n/naf47a811ce19

素のモデル性能を重視する利点

カスタム設定に頼りすぎず、モデルの素の性能を重視するアプローチには以下のような利点があります:

1. 透明性と予測可能性

カスタム設定がない状態でのパフォーマンスがわかれば、どんな状況でも一貫した挙動を期待できます。

2. 問題の切り分け

何か問題が発生した時、「モデル自体の限界なのか、カスタム設定の不具合なのか」という切り分けが不要になります。これにより、トラブルシューティングが大幅に簡略化されます。

3. メンテナンスコストの削減

モデルが更新されるたびにカスタム設定の有効性を検証し、調整する必要がなくなります。特に大規模なアップデート時には、この労力の節約は大きな価値があります。

4. 汎用スキルの構築

どのAIサービスでも活用できる普遍的なプロンプト技術の習得に集中できます。特定のサービスやモデルに依存しないスキルは長期的に価値があります。

とはいえ、ある程度KnowledgeやMechanismがある方が

  • 事業に関する専門的な判断に基づいて判断しやすい
  • 自分の仕事をワークフロー化して効率よく対応できる

という視点から、以下のようなバランスのとれたアプローチが重要だと考えます。

バランスのとれたアプローチ

現実的には、PKMフレームワークの観点から、効果的なカスタム設定と避けるべきカスタム設定を区別するアプローチが有効でしょう:

効果的なカスタム設定

  • Mechanism(思考プロセス) の明確化:特定の思考パターンや出力フォーマットを指定
  • Knowledge(知識) の補完:専門ドメインの知識や特定のコンテキスト情報を追加

例えばこちらはメカニズムのRuleの適用例なので、明確に効果がわかると思います
https://note.com/miyatad/n/ne9fb1575cddb

awesome-cursorrulesは技術スタックベースで分かれていることから、主にはKnowledgeの適用例が重視されていることがわかります
https://github.com/PatrickJS/awesome-cursorrules/tree/main

(※cursorrulesはdeprecatedになりましたが例として)
https://docs.cursor.com/context/rules-for-ai#cursorrules

避けるべきカスタム設定

  • Policy(行動規範) の上書き:モデルの基本的な行動原理に干渉するような設定
  • モデルの更新で無効になりやすい細かな調整
  • 複雑すぎて効果の検証が困難な設定

awesome-cursorrulesを一通り見てもらうと、この辺はかなり個人差があるというか
明確にこうすべき!という視点がないと思われます
(本当はデータで出したい気持ちがありますが個人記事なので今回は許して、そのうちやりたい...)

まとめ

AIカスタム設定には確かに価値がある場合もありますが、その評価は多くの場合、心理的バイアスの影響を受けています。PKMフレームワークを用いて設定の本質を分析し、自己の判断プロセスを意識的に点検することで、より合理的な選択ができるようになるでしょう。

局所最適化に振り回されず、長期的な視点でAIツールとの関わり方を考えることが、持続可能かつ効果的なAI活用の鍵となるのではないでしょうか。

追記

上記は人間側から考えたRulesの整備ですが、LLM側の立場からも整理しました。
https://zenn.dev/tesla/articles/ade9883b2f62c9

11

Discussion