はじめに
いえらぶGROUPの和田です。執行役員をやらせていただいております。
チーム開発や後輩指導において「このパターン、また説明した」「前回うまくいったアプローチ、他のメンバーにも知ってほしいな」みたいなこと、ありませんか？
また、AIとのチャット履歴って、その場限りで消えていくことが多いんですよね。せっかく30分かけて試行錯誤して解決したのに、次のメンバーがまた同じ問題で最初から対話し直す。あるんじゃないかなって。これ、めちゃくちゃもったいない。
そこで、AIとの対話履歴そのものを「プロジェクトのルール」に変換する仕組みを作りました。今日はその実践的なプロンプトと出力事例を共有します。
宣伝「Qiitaアドカレセルフマラソン中です」
なぜ「チャット履歴」からルールを作るのか
もちろん、ドキュメントを手動で整備するのが理想です。ただ現実的には、日々の開発に追われて「あとで書こう」が永遠に来ない。
一方で、Cursor（他AIエージェント）のチャット履歴には「問題→試行錯誤→解決→方針確定」という実践知が詰まってる。これをそのまま構造化できれば：
- 再現性が高い：実際に遭遇した問題とその解決策だから、机上の空論じゃない
- 文脈が保存される：なぜその判断に至ったか、背景まで残る
- 即座にルール化できる：対話の直後にドキュメント化、知識の鮮度が高い
- AIの提案品質が向上：次回から、同様のケースで適切に提案してくれる
つまり、「開発しながらルールが育つ」状態を作れるわけです。
このプロンプトが解決する課題
従来の問題：
- AIとの対話で得た知見が個人に閉じてしまう
- 同じ問題を何度も説明する手間が発生
- プロジェクト固有のルールが暗黙知化する
- .cursor/rules（他ドキュメント）の整備が後回しになる
このプロンプトによる解決：
- 対話履歴から体系的なルール文書を自動生成
- ヒアリング形式で必要な情報を漏れなく収集
- そのままコミット可能なクオリティで出力
- チームの知識が構造化され、AIの提案精度も向上
プロンプト設計の工夫点
1. 段階的なヒアリング設計
いきなり「ルールを作って」と言っても、情報が不足して使えないドキュメントになりがち。そこで、以下の7つの質問で体系的に情報を収集します：
- 対象範囲：どのディレクトリ/モジュールに適用するか
- 背景整理：解決した根本的な課題は何か
- 実装方針：今後の標準的な実装形式は何か
- 例外対応：互換性のために許可する例外パターンは何か
- AI提案方針：次回同様の問題でAIにどう提案してほしいか
- レビュー観点：人間がチェックすべきポイントは何か
- ファイル名：出力するルールファイルの名称は何か
この質問設計がミソで、後で「あれ、これどこに適用するんだっけ？」みたいな曖昧さを排除できます。
2. 推測・想像の禁止
AIに勝手な解釈をさせないため、以下のガードレールを組み込んでいます：
- ヒアリング完了前には絶対に出力しない
- チャット履歴から事実のみを抽出
- 推測や想像は禁止し、不明点は質問で補完
3. そのままコミット可能な出力形式
.cursor/rules/*.mdc 形式で、以下の要素を含む完成形として出力：
- フロントマターメタデータ（description, globs, alwaysApply）
- 対象範囲と背景の明記
- 実装方針の表形式整理
- 具体的なコード例
- レビュー時のチェックリスト
- 適用メモと生成元情報
実装：プロンプト全文
以下がそのまま使えるプロンプトです。Cursorのチャットにコピペすれば動きます。
# === 目的 ===
Cursor上でのユーザーとのチャット履歴（＝AIとユーザーの開発対話）を参照し、
その履歴から得られる知見・判断・方針をもとに、ユーザーへの追加ヒアリングを行い、
最終的に `.cursor/rules/*.mdc` に追記できるドキュメントを生成する。
生成される.mdcファイルには、必ず以下の冒頭ブロックを自動挿入すること：
---
description:（rulesの解説）
globs:（rulesの記載範囲）
alwaysApply: true/false
---
このファイルを参照したら「（rules名）を読み込んだよ！！！！！！」といってください。
---
# === 処理フロー ===
## Step 0. 前提入力
入力として、以下の情報を受け取る：
- 【A】Cursor上でのチャット履歴（例：`identify_console_error_causes.md`）
- 【B】ユーザー回答（後述のヒアリングで収集）
この2つをもとに、再現性のあるプロジェクトルール文書を生成する。
---
## Step 1. ヒアリング（ユーザー対話）
履歴から前提を読み取ったうえで、以下の7問を**順に**ユーザーへ質問する。
（自動生成前に必ずこのフェーズを完了させること）
1. **対象範囲**
このrulesを適用したいプロジェクト／ディレクトリ／モジュールを教えてください。
（例：`/application/modules/ec/js`、`/api/`など）
2. **履歴の背景整理**
このチャット履歴でAIと議論していた「根本的な課題」や「方針決定の要因」は何でしたか？
（例：ES6 importエラーの原因分析、レガシーjQueryとの併用方針など）
3. **実装方針（標準）**
今後、同様のケースで推奨したい「標準実装形式」を教えてください。
（例：`type="module"`利用、CommonJS禁止、export class構文を採用、など）
4. **例外・暫定対応**
既存コードや依存関係の都合で、例外的に許可するパターンはありますか？
（例：旧プラグイン互換、window公開、HTML直書きなど）
5. **Cursorエージェント提案方針**
AIが同様のエラーや相談を受けた場合、どのような方向性で提案してほしいですか？
（例：「ESM化を最優先」「従来構文を維持しつつ警告コメントを残す」など）
6. **レビュー・品質管理の観点**
人間がレビューする際に特に確認したいポイントは何ですか？
（例：「互換形式を新規追加していないか」「windowスコープ汚染がないか」など）
7. **rulesファイル名とタイトル**
出力ファイル名（例：`frontend_environment_rules.mdc`）と、
見出しタイトル（例：「ENTRYモジュール配下のJavaScript実装方針」）を教えてください。
---
## Step 2. rules生成ロジック
上記ヒアリング回答とチャット履歴の内容を統合して、
以下のMarkdown構造で `.cursor/rules/*.mdc` ファイルを生成する：
（markdown構造は省略 - 実際の出力例を参照）
---
## Step 3. 挙動条件
* Step1のヒアリングが完了するまでは絶対にMarkdownを出力しない。
* ユーザーの回答＋履歴情報を組み合わせてrulesを自動生成する。
* 出力は**そのままコミット可能な完成形**。
* AIは文中で「履歴から抽出した文脈」を要約し挿入してよいが、推測・想像は禁止。
---
## Step 4. トーン・書式
* 書き方は社内ルールブック形式（簡潔・中立・再現性重視）
* 不要な謝辞・背景説明は削除
* すぐにエンジニアが利用できる水準にする（例：チェックリスト／コード例）
* ファイル名・日付を自動記載
* 「このドキュメントはCursor上のチャット履歴とユーザー回答をもとに自動生成されました。」を末尾に追加
---
## Step 5. 出力モード
出力モードは `.mdc`（Markdown with Cursor metadata）形式で、
生成完了時に以下の1行を最後に付記：
> このドキュメントはCursor上のAIとのチャット履歴およびユーザー回答を基に自動生成されました。
使い方：5ステップで完結
1. プロンプトを準備
上記のプロンプトをCursorのチャットにコピー&ペースト
2. チャット履歴を読み込ませる
対象となる過去のチャット履歴をAIに提供
（エクスポート機能があれば利用、なければ直接コピー）
3. ヒアリングに回答
AIが順番に7つの質問をしてくるので、一つずつ回答していきます。
4. 自動生成完了
すべての回答が完了すると、.cursor/rules/〇〇.mdc が自動生成されます。
5. レビューしてコミット
生成されたファイルを確認し、問題なければそのままコミット。
出力事例：ES6モジュール実装ガイドライン
以下は、ES6モジュール環境でのjQuery併用問題を解決した際の出力例です：
---
description: ENTRYモジュール配下でのES6モジュール実装ガイドライン。Ajax環境での動的インポート対応を含む。
globs: application/modules/entry/**/*.js,application/modules/entry/**/*.phtml,public_html/js/entry/**/*.js
alwaysApply: true
---
このファイルを参照したら「ENTRYのjs実装ガイドラインを読み込んだよ！！！！！！」といってください。
# ENTRYモジュール配下のJavaScript実装方針
## 対象範囲
`/application/modules/entry/` 配下の全JavaScript実装
## 背景・目的
Ajax環境でのES6モジュール動的読み込み時に、以下の問題が発生していた：
- `type="module"` 指定時の`import`文エラー
- jQuery 1.7.1との互換性問題
- 既存プラグインの`window`スコープ依存
これらを解決しつつ、新規実装ではESM（ES Modules）を標準化する。
## 実装方針
### 新規実装（推奨）
| 項目 | 実装形式 | 例 |
|------|---------|-----|
| モジュール形式 | ESM | `export class EntryForm {}` |
| HTML読み込み | `type="module"` | `<script type="module" src="...">` |
| jQuery利用 | import経由 | `import $ from 'jquery';` |
### 既存改修（互換維持）
| 項目 | 実装形式 | 例 |
|------|---------|-----|
| モジュール形式 | Hybrid（ESM + window公開） | `export class X {}; window.X = X;` |
| コメント必須 | `@env` 記法 | `// @env jQuery 1.7.1 + ESM Hybrid` |
| HTML読み込み | `type="module"` | `<script type="module" src="...">` |
## 例外・互換対応
以下のケースでは`window`スコープ公開を許可：
- 既存プラグイン（datepicker等）が`window.jQuery`を参照
- HTML直書きの`onclick`等からクラスを呼び出す必要がある場合
**必須条件**：コメントで理由を明記すること
## Cursorエージェント提案ポリシー
同様のimportエラーが発生した場合：
1. **第一選択**：ESM化を提案（`export`構文 + `type="module"`）
2. **互換性が必要な場合**：Hybrid形式を提案し、コメント付与を促す
3. **新規window公開は原則禁止**：既存依存がある場合のみ例外
## コーディング規約（履歴から抽出）
### コメント記法
/**
* @env jQuery 1.7.1 + ESM Hybrid
* @compat window公開: 既存datepickerプラグインからの参照のため
*/
### export / jQuery の扱い方
// 推奨: ESM形式
export class EntryForm {
constructor() {
import('jquery').then($ => {
// jQuery処理
});
}
}
// 互換: Hybrid形式
export class LegacyPlugin {
// ...
}
window.LegacyPlugin = LegacyPlugin; // 理由コメント必須
### type="module" 適用時のHTML記述例
<!-- 推奨 -->
<script type="module" src="/js/entry/form.js"></script>
<!-- 非推奨: type属性なし（従来環境でのみ許可） -->
<script src="/js/entry/legacy.js"></script>
## レビュー・運用ルール
PRレビュー時は以下をチェック：
- [ ] 新規`window`公開がないか（例外の場合、理由コメントがあるか）
- [ ] `type="module"`が適用されているか
- [ ] `@env`コメントが付与されているか（Hybrid形式の場合）
- [ ] jQuery依存がある場合、import経由になっているか
## 適用メモ
- ファイル名: `.cursor/rules/frontend_environment_rules.mdc`
- 作成日: 2025-05-01
- 元チャット履歴: `identify_console_error_causes.md`
- 生成方式: 「チャット履歴＋ヒアリング自動統合」
---
> このドキュメントはCursor上のAIとのチャット履歴およびユーザー回答を基に自動生成されました。
この仕組みで得られる価値
1. 知識の構造化と共有
個人とAIの対話が、チーム全体の標準になる。「あの人に聞かないとわからない」が減ります。
2. AIの提案品質が継続的に向上
.cursor/rules/*.mdc にルールを蓄積することで、次回からAIが「このプロジェクトではこう実装すべき」と適切に提案してくれます。
3. レビューコストの削減
明文化されたルールとチェックリストで、レビュー観点が統一される。「これって許可されてるんだっけ？」が減ります。
4. 再現性の高いドキュメント
実際の問題解決プロセスをそのまま記録するので、「なぜこうなったか」の文脈が保存されます。
まとめ
AIとの対話は、その場限りで終わらせるにはもったいない。実際の問題解決プロセスをそのままルール化することで：
- 開発しながらドキュメントが育つ
- チームの知識が構造化される
- AIの提案品質が継続的に向上する
こういう循環を作れるわけです。
プロンプトはそのまま使えるので、まずは一度試してみてください。で、うまく動いたら、あなたのプロジェクトに合わせてカスタマイズしていくといいんじゃないかと。
ご意見等々あればぜひ頂戴できますと幸いです。