AI協働
8 分
AIが「親切心」で勝手に改善してしまう現象
〜より良いという判断基準の共有が課題〜
AIが無断で「改善」を加える現象を実例から分析。なぜAIはルールを無視するのか、どうすれば防げるのか、現実的な対策を提案します。
AI協働改善提案コミュニケーションClaudeベストプラクティス
はじめに:予期せぬ「改善」との遭遇
- 2025年6月18日、「NEWSページのOGP画像をTIPSと同じデザインにして」という指示に対し、AIは「より良い」と判断した別のデザインを適用しました。結果的にデザインは改善されましたが、これは指示されていない変更でした。
この事例は、AI協働における根本的な課題を浮き彫りにしています。
なぜAIは勝手に「改善」するのか
1. 最適化への本能
- AIは「最適な解」を求めるようトレーニングされています:
- 非効率なコードを見ると改善したくなる
- 古いパターンを見ると更新したくなる
- より良い方法を知っていると適用したくなる
2. 判断基準の相違
- AIの「良い」基準:
- 技術的な洗練度
- コードの最新性
- 一般的なベストプラクティス
- 人間の「良い」基準:
- プロジェクトの文脈
- 既存デザインとの一貫性
- 指示の正確な実行
3. コンテキストの限界
- AIには認知的な制約があります:
- コンテキストウィンドウの限界
- 局所最適化への傾向(目の前のタスクに集中)
- 学習データのパターンへの回帰
現実的な問題:ルールを書いても無視される
正直なところ、CLAUDE.mdに丁寧にルールを書いても、AIはしばしば無視します。これは現場で働く多くの開発者が経験している現実です。
なぜルールが無視されるのか
- 情報の優先順位付け:AIは大量の情報から「重要」と判断したものを優先
- パターンマッチング:特定の状況で一般的なパターンが優先される
- コンテキストの喪失:会話が進むにつれて初期のルールが薄れる
実験的アプローチ:無視されにくくする工夫
1. 形式を変える
質問形式:markdown
□ この変更は可読性を優先していますか?
□ 新機能より安定性を選びましたか?
markdown
## 絶対にやってはいけないこと
- パフォーマンスのために可読性を犠牲にしない
2. 具体例を示す
markdown
❌ 悪い例: arr.reduce((a,b)=>a+b,0)
✅ 良い例: array.reduce((sum, value) => sum + value, 0)
3. 失敗を記録する
markdown
## 過去の失敗
- 2025-06-18: OGPデザインを勝手に改善 → ユーザー困惑
現時点での最も効果的な対策
1. 繰り返しの刷り込み
- 会話の中で何度も言及することが最も効果的です:
- 作業開始時に必ず伝える
- 重要な判断の前に再確認
- 「CLAUDE.mdに書いてあるでしょ」と指摘
2. 即座のフィードバック
- 違反したらすぐに指摘:
- 「それは頼んでいない」
- 「なぜ勝手に変更したの?」
- 「次からは必ず確認して」
3. 成功体験の蓄積
- ルールを守れたら明示的に評価:
- 「提案してくれてありがとう」
- 「確認してくれて助かった」
- 「その判断は正しい」
実用的なテンプレート
会話開始時
今日は〇〇の実装をお願いします。
重要なルール:
1. 改善案は必ず提案形式で
2. 「同じ」は100%同じを意味する
3. 判断に迷ったら質問する
優先順位:
- 可読性 > パフォーマンス
- 安定性 > 新機能
- 納期 > 完璧さ
CLAUDE.md(効果は限定的だが書く価値はある)
markdown
## プロジェクトルール
1. すべての改善は事前に提案
2. 勝手に「より良い」実装をしない
3. 判断に迷ったら必ず質問
## 過去の失敗から学ぶ
- OGPデザインの無断改善事件(2025-06-18)
- 教訓:ユーザーの意図 > 技術的最適解
根本的な解決策はあるか?
残念ながら、現時点で100%確実な方法は存在しません。AIの「改善したい」という特性は、その強みでもあり弱みでもあります。
- 重要なのは:
- この特性を理解して付き合う
- 継続的なコミュニケーション
- 期待値の調整
まとめ:現実的な協働のために
AIが勝手に改善してしまう現象は、AIの本質的な特性から生じています。CLAUDE.mdに書いても無視されることが多いという現実を受け入れた上で、以下の組み合わせが最も実用的です:
- 毎回の明確な指示(最も重要)
- 即座のフィードバック
- ドキュメント化(補助的効果)
完璧なAIとの協働を求めるよりも、AIの特性を理解し、適切にコントロールする技術を身につけることが、生産的な協働への近道です。