はじめに
コーディングエージェントを使った開発に限らずですが、「このパターン、またハマった」「前回AIと話してうまくいった方法、他のメンバーにも共有したいな」みたいなことって多くないですか？
実際、AIとのチャットで得られた知見って、その場限りで終わってしまうことが多いんですよね。せっかく時間かけて試行錯誤したのに、同じ問題で次のメンバーがまた最初から対話し直す。これ、めちゃくちゃもったいない。
そこで、AIとの対話履歴そのものを「チームの知識ベース」に変換する仕組みを作りました。今日はその実践的なプロンプトを共有します。
なぜ「AI対話履歴」からルールを作るのか
もちろん、ドキュメントを手動で整備するのが理想です。ただ現実的には、日々の開発に追われて「あとで書こう」が永遠に来ない。
一方で、Cursorのチャット履歴には「問題→試行錯誤→解決→方針確定」という実践知が詰まってる。これをそのまま構造化できれば：
- 再現性が高い：実際に遭遇した問題とその解決策だから、机上の空論じゃない
- 文脈が保存される：なぜその判断に至ったか、背景まで残る
- 即座にルール化できる：対話の直後にドキュメント化、知識の鮮度が高い
つまり、「開発しながらルールが育つ」状態を作れるわけです。
仕組みの全体像：4ステップで完結
プロンプトの構造は以下の4ステップ：
Step 0: 前提入力
AIに以下を渡します：
-
チャット履歴（例：
identify_console_error_causes.md） - ユーザー回答（次のステップで収集）
Step 1: 体系的ヒアリング
AIが順番に7つの質問を投げかけます。この質問設計がミソで、後で「あれ、これどこに適用するんだっけ？」みたいな曖昧さを排除します。
- 対象範囲：どのディレクトリ/モジュールに適用するか
- 背景整理：解決した根本的な課題は何か
- 実装方針：今後の標準的な実装形式は何か
- 例外対応：互換性のために許可する例外パターンは何か
- AI提案方針：次回同様の問題でAIにどう提案してほしいか
- レビュー観点：人間がチェックすべきポイントは何か
- ファイル名：出力するルールファイルの名称は何か
例えば、ES6モジュールとjQueryの共存問題を解決したケースなら：
-
対象範囲：
/application/modules/entry/js -
背景整理：
type="module"でのimportエラー、Ajax環境での動的読み込み対応 -
実装方針：ESM推奨、
export class構文を採用 -
例外対応：旧プラグイン互換のため
window公開は許可（コメント付き）
みたいな感じ。
Step 2: ルール生成
ヒアリング内容とチャット履歴を統合して、.cursor/rules/*.mdc 形式のMarkdownを自動生成します。
生成されるファイルはそのままコミット可能な完成度。重要なのは：
- チャット履歴から具体例を抽出
- 「新規実装」「既存改修」「共通モジュール」などに分類した表を作成
- レビュー時のチェックリストも自動生成
Step 3: 品質保証
プロンプトには以下のガードレールを組み込んでます：
- ヒアリング完了前には絶対に出力しない
- 推測や想像を排除し、事実ベースで記述
- AIは履歴から文脈を要約してよいが、勝手な解釈は禁止
実装：メタプロンプトの全文
以下がそのまま使えるプロンプトです。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（開始）============
---
description: ENTRYモジュール配下でのES6モジュール実装ガイドライン。Ajax環境での動的インポート対応を含む。
globs: application/modules/entry/**/*.js,application/modules/entry/**/*.phtml,public_html/js/entry/**/*.js
alwaysApply: true
---
このファイルを参照したら「ENTRYのjs実装ガイドラインを読み込んだよ！！！！！！」といってください。
# {タイトル}
## 対象範囲
{回答1}
## 背景・目的
{回答2}
（チャット履歴中の具体的エラー・原因・議論要約を自動抽出）
## 実装方針
{回答3}
- チャット履歴中の対応例・サンプルコードを再掲
- 「新規実装」「既存改修」「共通モジュール」などに分類した表を生成
## 例外・互換対応
{回答4}
## Cursorエージェント提案ポリシー
{回答5}
- 同様エラー発生時に提案すべき修正パターン
- モジュール形式を推奨する条件と、互換形式を残す条件を明文化
## コーディング規約（履歴から抽出）
- コメント記法（例：`@env jQuery 1.7.1 + ESM Hybrid`）
- `export` / `jQuery`の扱い方
- `type="module"`適用時のHTML記述例
- import/export構文例
## レビュー・運用ルール
{回答6}
- チェックリスト形式で出力（例：「[ ] 新規window公開なし」「[ ] コメント付与済み」）
## 適用メモ
- ファイル名: `.cursor/rules/{回答7}`
- 作成日: {現在日付}
- 元チャット履歴: {履歴ファイル名}
- 生成方式: 「チャット履歴＋ヒアリング自動統合」
============markdown（終了）============
---
## Step 3. 挙動条件
* Step1のヒアリングが完了するまでは絶対にMarkdownを出力しない。
* ユーザーの回答＋履歴情報を組み合わせてrulesを自動生成する。
* 出力は**そのまま.mdcとしてコミット可能な完成形**。
* AIは文中で「履歴から抽出した文脈」を要約し挿入してよいが、推測・想像は禁止。
---
## Step 4. トーン・書式
* 書き方は社内ルールブック形式（簡潔・中立・再現性重視）
* 不要な謝辞・背景説明は削除
* すぐにエンジニアが利用できる水準にする（例：チェックリスト／コード例）
* ファイル名・日付を自動記載
* 「このドキュメントはCursor上のチャット履歴とユーザー回答をもとに自動生成されました。」を末尾に追加
---
## Step 5. 出力モード
出力モードは `.mdc`（Markdown with Cursor metadata）形式で、
生成完了時に以下の1行を最後に付記：
> このドキュメントはCursor上のAIとのチャット履歴およびユーザー回答を基に自動生成されました。
---
使い方：5ステップで完結
1. プロンプトを準備
上記のメタプロンプトをCursorのチャットにコピー&ペースト
2. チャット履歴を読み込ませる
対象となる過去のチャット履歴（例：identify_console_error_causes.md）をAIに提供
3. ヒアリングに回答
AIが順番に7つの質問をしてくるので、一つずつ回答していきます。
4. 自動生成完了
すべての回答が完了すると、.cursor/rules/〇〇.mdc が自動生成されます。
5. レビューしてコミット
生成されたファイルを確認し、問題なければそのままコミット。
実際の出力例
以下は、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. 再現性の高いルール
「あの時どうやって解決したっけ？」が、具体的なコード例とチェックリストで残る。
2. チーム全体への知識共有
個人とAIの対話が、チームの標準になる。
3. AIの提案品質が向上
次回から、AIが「このプロジェクトではこう実装すべき」と適切に提案してくれる。
4. レビューコストの削減
明文化されたルールとチェックリストで、レビュー観点が統一される。
まとめ
AIとの対話は、その場限りで終わらせるにはもったいない。実際の問題解決プロセスをそのままルール化することで：
- 開発しながらドキュメントが育つ
- チームの知識が構造化される
- AIの提案品質が継続的に向上する
こういう循環を作れます。
プロンプトはそのまま使えるので、まずは一度試してみてください。うまく動いたら、あなたのプロジェクトに合わせてカスタマイズしていくといいんじゃないかと。
いえらぶでは一緒に最速でサービス開発する仲間を募集しています
AIを活用しまくっているのは、つまるところ業界に対して1つでも多く・早くプロダクトを提供するのが目的です。共感してくれる方を広く募集しています。
カジュアル面談しましょう
DMいつでもお待ちしております。採用拘わらず、AIについてでもマネジメントについてでも、何でもお話ししたいです。
新卒採用サイト
大学生向けインターンシップ「いえらぶAIブートキャンプ」募集ページ