Cursorエージェント講座 超精度向上編。 Rulesテクニックであなたもエージェントマスターに！

どうもこんにちは！エクスプラザの生成AIエバンジェリストのmiyattiです！いやー最近めっきりCursor祭りですね！！！！

おかげさまで、Cursorエージェント超入門講座は１０００いいね超えという、自分としては見たことがないぐらい多くの人に読んでもらってほんとありがたいですし、本当に今Cursorが熱いんだな！！！！！と実感しますね！

ということで、今回は前回の「プロジェクト管理もストレスもAIがサポート！ノンエンジニアでもOKなCursorエージェント講座 実践編」

こちらの続編という感じで、前回紹介したCursorのRules機能のより、本格的、具体的なかきかたを、めちゃめちゃマニアックにお伝えしていきたいと思います！！！

Rulesというものを使い始めるだけでも「タスク管理モード」「アイデア発散モード」など多彩に動かせることをご紹介しました。しかし、

という声は多いでしょう。今回はRuleの書き方、しかもめちゃくちゃ精度がでる、思い通りにエージェントが動くルールの書き方をお伝えしていきたいと思います。その鍵は「YAML形式」でかくことです！！

このYAML形式というもので、“ちょっと構造的に書く”だけで、AIエージェントは思った以上にブレずにしっかり働いてくれるんです。

※　さて、今回は若干難易度ハードモードです！！！！でも、かなり丁寧に初心者向けに描くように心がけてはいるので、もしよければぜひ最後までおよみいただければー

YAMLって何？ かんたんな書き方

● YAMLは“人間にやさしい”マークアップ言語

YAMLとは「YAML Ain’t Markup Language」の略。（なんだそりゃ）

まぁ簡単にいうと、AIが理解しやすいようにきれいにかくためのフォーマット。ちょっと知ってる人ならjsonやxmlの仲間みたいなものと思ってくだされば。特徴としては

• 改行と空白（インデント）だけで階層を表現

• （XMLとかJSONみたいに）タグやカッコで囲まないため、人間が読みやすい

たとえばこんな例です：

menu: カレー
people: 4
steps:
  - name: buy_ingredients
    message: "食材を買いに行きましょう"
  - name: cook
    message: "カレーを煮込みましょう"

「menu」「people」といった種別みたいなもの（項目名）に対して、その中身（内容）を書いていくスタイルです。

これみて「うっ」となったかたもいるかもですが、「メニューはカレー、人数は4人、ステップとしては食材買いに行くステップと、カレーを煮込むステップ、ってのがあるからね」ってことがかいてあるだけです。

シンプルなデータ構造なら“書いてある通り”の意味になりやすいため、プログラミング未経験でも意外と扱いやすいのが強みです。

ではかんたんな（？）かきかた。（※一旦、エージェント構築の理論的なところを雰囲気つかみたいひとはここは飛ばしてもらっても大丈夫です）

● 超絶シンプルYAML書き方入門

1. まずは超短い例

# これはコメントです（行頭に # があると無視されます）

氏名: "鈴木太郎"    # “氏名”という項目に "鈴木太郎" を指定
年齢: 28            # 年齢という数値項目には 28 と記入
好物:
  - "ラーメン"       # リストの書き方：項目名の下に「-」で並べる
  - "カレー"
  - "寿司"

• 項目名: 内容 の形で書く

• リストっぽいのをかきたければ -（ハイフン）で始める

2. 階層構造で“まとまり”を表現

YAMLの強みは「階層」表現です。
例えば、ある会社の“従業員”データを管理するなら：

従業員:
  鈴木太郎:
    部署: "営業部"
    年齢: 28
    スキル:
      - "コミュニケーション"
      - "Excel分析"
  
  佐藤花子:
    部署: "開発部"
    年齢: 32
    スキル:
      - "プログラミング"
      - "UIデザイン"

「従業員」 の中に「鈴木太郎」と「佐藤花子」というまとめを作り、それぞれに情報をぶら下げる形。
Excelのように行列を作らなくても、テキストだけで階層的に表せます。

3. 改行＆インデントが命

YAMLでは「空白の数」「改行する位置」が構造を決めます。
下の階層をかくときは、左側にスペースを一定数いれる感じです。

住所:
  都道府県: "東京都"
  市区町村: "新宿区"
  番地: "1-1-1"

• 下の階層は2個分のスペースが主流らしい

● CursorのRulesファイルにも、YAMLはかけます

なんとなく書き方は理解されましたか？むずいですか？

まぁ困ったらCursorに「これいい感じのYAMLっぽいかんじにして」というとやってくれるので、やっていきましょう。

Cursorが利用する.mdcという拡張子のファイルは、Markdownをベースになってますが、実はYAMLを書いても問題なく認識してくれますのでご安心を（実はMDCというファイル形式自体がYAMLで描かれることも想定したMDファイルの拡張的なものだったりします）

Tipsとしては、MDCファイルのなかでこんな感じでかくと、YAMLとして色分けして表示されるので便利です（こうかかななくても動くは動く）

最初は「ん？プログラミングっぽい……」と身構えるかもしれませんが、ちょっとしたルールを間違えなければ、そこまで難しくありません。

ほんの少し慣れれば「これだけでAIが勝手に動いてくれるのか！」と感動できるはず。

ほんとにこんなに“YAML”が必要なの？自然言語じゃダメなの？

まぁ今回は正直めちゃくちゃめんどくせーはなしするんですけど、そうなので、まぁ

と思う方が多いのではないでしょうか。

実はこれ、AIエージェントの特性と大きく関わっています。人間にとっては自然言語だけで「○○して、終わったら××して」と伝えた方が楽に思えますよね。ところが、AIは自然言語だけだと勝手に誤読することが多いのです。

1）AIは自然言語が得意なようで苦手

近年のChatGPTブームで「AIは何でも理解してくれる」と感じるかもしれませんが、実際は曖昧な指示には弱い面があります。とりわけ順序や条件分岐が絡む場面では、以下のような混乱が起きがちです：

• 質問の順序を“気まぐれ”に変える

• ユーザーの確認を待たずに「このタスク終わり」と判断して先に進む

• “ここはもう要らない情報だろう” と勝手に省略する

結果、本来の手順を踏まずに飛ばしてしまうなどの“解釈ブレ”が頻発します。

2）「構造」化指示が得意

そこで活きるのが、YAMLによる“ステップごとのルール”の明示です。
「ここで何を聞き、この条件なら次はコッチ」とフローを形で書いておけば、AIは“解釈”という曖昧作業をほぼしなくて済むため、一貫した動きをしやすくなるんです。

MDCファイルにYAML形式で書いておけば、何度使ってもほぼ同じ順序でタスクを進め、同じ確認手順を踏んでくれるので、シンプルプロンプトのようなブレが減ります。

シンプルプロンプト vs. YAML例

たとえば、実際の記述方法がどれだけ違うか、夕飯準備の例を使って比べてみましょう。

例：夕飯準備をする場合

シンプルな指示（ちょっと不安定）

ユーザーから夕食のメニューと人数を聞いて、 
それから調理時間と食事時間を聞いて、
計画を立てて。 
それが終わったら確認を求めて、
OKなら買い物リストと手順書を作って。

一見すると「何が問題なの？」と思うほど、サッパリ書けていて便利そうです。
しかし、AIの解釈が入り込む余地が大きいため、以下のような事態が起こりがちです：

• 「どうせすぐOKだろう」と勝手に判断してファイル作成を進めてしまう

• 質問順序を飛ばし、メニューを聞かずに人数だけ聞く（または逆）

• ユーザーへの確認を省いて次フェーズに突入

結果、「あれ、まだ献立すら決まってないのに予算が設定された…」 など、意図しない進め方になりがち。
シンプルに書くほど“人間に優しい”感じがしますが、AIは曖昧なまま処理してしまうのです。

YAML形式（安定）

- name: "ask_menu"
  action: "ask_question"
  question: "今日の夕食メニューを教えてください"
  variable: "dinner_menu"

- name: "ask_people"
  action: "ask_question"
  question: "何人分を作りますか？"
  variable: "people_count"

- name: "confirm_plan"
  action: "confirm"
  message: "こんな献立でいいですか？"
  variable: "plan_ok"

- name: "create_recipe"
  action: "create_file"
  ...

一方、こうしたYAML形式でステップごとに明確に書いておけば、
「順番を飛ばさない」
「確認のないまま先に進まない」
「ファイル作成は最後に確実に行う」
といった厳密なフローを安定的に再現できます。

実際にこの形で動かすと、

1. 必ずメニューを聞く

2. 次に人数を聞く

3. ユーザーのOKを得てからレシピファイルを自動生成
   という手順を毎回同じように踏んでくれるため、ハチャメチャにズレる危険性がグッと減るのです。

ハンズオン：ゼロからYAML形式でRulesを作成する

Rulesを初めて作る方にとっては、「何から手をつければいいのか」が最大のハードルかもしれません。

ここでは、いつものように、ハンズオンやってみましょう。シンプルな「夕食準備エージェント」を題材に、初歩の初歩からYAMLで書かれたMDCファイルを組み上げる手順を解説します。いわば、「夕食の支度を頼むだけでサポートしてくれるAI秘書」を作る流れを一緒に体験してみましょう。

短い例ですが、このステップを押さえると「あ、MDCファイルってこんな感じで書けばいいんだ」と一気にイメージが湧くはずです。

※ 実際にどうやってRulesをCursorに作ればいいかについては前回の実践編の記事を参照してください！

さて、先にこのルールで、実際にエージェントがどんな感じで動くのか、をデモンストレーションします。

実際に手元でも動かしてみたい人は、Githubにあらかじめ完成させたRulesを公開しましたので、そちらを手元でCursorで動かしてみるといいと思います。

利用方法

1. Cursorの新規ウィンドウから簡単にセットアップできます：

   • Cursorを起動し、「New Window」を選択

   • 「Clone repo」を選び、このリポジトリのURLを入力

   • フォルダ指定のUIが表示されたら、右下の「Select as repository destination」ボタンをタップ

2. Chatパネルを開き「夕食の準備」と入力、対話的に夕食の計画が始まります

3. 新しく作成されたプロジェクトはDinnerフォルダに保存されます

ということでYAMLで書いたRules（MDCファイル）がどのように実際の会話を導くかを理解するために、実際の対話例を見てみましょう。以下は、作成した夕食準備エージェントを使用した実際のやり取りです：

1. 情報収集フェーズ

User: 夕食の準備をお願いします

Cursor: 夕食の準備をするにあたって、質問させてください。
今日の夕食のメニュー名を教えてください（例：カレーライス、パスタ、焼き魚定食など）

User: カレーです

Cursor: 食事人数は何名ですか？

User: 4人（大人二人子供二人

Cursor: 調理予定時刻はいつ頃ですか？（例：18:00）

User: 20時ぐらい

Cursor: 食事予定時刻はいつ頃ですか？（例：19:00）

User: 21時ぐらい

Cursor: 予算はいくらくらいですか？（例：2000円）

User: 特に決めてないけど、そこまで高くない感じで

Cursor: 食事で避けたい材料はありますか？（アレルギーなど）

User: ないです

Cursor: その他の要望はありますか？

User: ないです

この部分は、ルールに定義された質問セットが順番に実行されています。後でお伝えする「質問セットの分離」というテクニックの効果が明確に表れており、MDCファイルが一連の質問を順序立てて行い、ユーザーの回答を収集しています。

2. 確認と計画生成フェーズ

Cursor: 以下の内容で夕食準備プロジェクトを開始します：
- メニュー: カレー
- 人数: 4人（大人二人子供二人）
- 調理時間: 20時ぐらい
- 食事時間: 21時ぐらい
- 予算: 2000円（標準）
- アレルギー: なし
- 特別な要望: なし

よろしいですか？

User: はい

Cursor: [夕食準備計画、レシピ、タスクリスト、買い物リストの詳細な出力]

初期プランを作成しました。計画の詳細をご確認いただけますか？

User: 確認しました

ここでは：

1. 最初にconfirmアクションが実行され、ユーザーに情報の確認を求めています

2. 承認を得た後、複数のファイル（計画、レシピ、タスクリスト、買い物リスト）がテンプレートを使って生成されています

3. テンプレートには、質問フェーズで収集した変数（dinner_menu, people_countなど）が自動的に埋め込まれています

この部分は「テンプレートの分離」と「ファイル操作パターン」というテクニックの実践例で、ユーザーから収集した情報を使って構造化された計画を生成しています。

3. 改善フェーズへの誘導

Cursor: これから夕食の準備を進めるには以下のステップがあります：
1. 「夕食の計画改善」と言って計画を改善する
2. 「夕食の買い物」と言って買い物フェーズに進む

準備ができたら次に進んでください。

User: 夕食の計画改善

これはnotifyアクションというテクニックを使って次のステップへのガイダンスを提供し、ユーザーを新しいトリガーワード（「夕食の計画改善」）に誘導しています。MDCファイルの別のトリガーに続くように設計されており、ワークフローの流れを作っています。

4. フィードバック収集と計画改善

Cursor: 「カレー」の計画を改善します。どのような点を改善したいですか？

User: 美味しいカレーにしたい

Cursor: フィードバック収集を開始します。各質問に具体的に回答してください。準備はよろしいですか？

User: はい

Cursor: メニュー「カレー」に追加したい料理はありますか？

User: サラダです

[中略：フィードバック収集の質問と回答]

Cursor: [改善されたレシピ、タスク、買い物リストの出力]

プランの更新が完了しました。以下の改善を行いました：
1. カレーレシピの改善
   - 辛さを控えめにするため、甘口ルーの使用・はちみつ・牛乳の追加方法を記載
   - りんごの量を増やして甘みを強化
[...]

この部分は:

1. 「明示的な確認ステップの挿入」の例で、フィードバック収集前に準備確認をしています

2. 「フィードバック収集パターン」を使ってユーザーの希望を構造化して収集しています

3. 収集した情報に基づいて新しいテンプレートを適用し、改善された計画を生成しています

MDCファイルによって設計されたいい感じの対話フローにより、エージェントはユーザーを段階的に導き、必要な情報を収集し、構造化された出力を提供してるのがわかるかとおもいます。

では、実際にこう動くように作っていきましょう。

STEP 1: 目的と機能を自然言語で明確にする

まずはゴールをはっきりさせましょう。「そもそも、このエージェントに何をしてほしいのか？」を、できるだけストレートに書き出してみてください。

私が「夕食の準備」と言ったら、AIが以下のことをしてほしい：
1. 今日の夕食のメニュー、人数、調理時間などを質問してくれる
2. 集めた情報を確認してから計画を立ててくれる
3. 買い物リスト、レシピ、タイムラインをファイルにまとめてくれる
4. 必要に応じて計画を改善できるようにする

ここではまだMDCファイルに書きません。「自分の頭の中」かメモ帳などにまず整理してください。
“自然言語で書き出す”ことで、後ほどルール化するときに迷いが少なくなります。

STEP 2: トリガーワードとステップ名のリスト作成

次に、Cursorがどんなキーワードで動き出すのか（＝トリガー）と、大まかなステップ名をざっくり書いてみましょう。

# 夕食の準備トリガー
trigger: "夕食の準備"
steps:
  - name: "情報収集"
    # 詳細は後で記入
  
  - name: "確認"
    # 詳細は後で記入
  
  - name: "計画作成"
    # 詳細は後で記入
  
  - name: "次のステップ案内"
    # 詳細は後で記入

# 計画改善トリガー
trigger: "夕食の計画改善"
steps:
  - name: "改善点確認"
    # 詳細は後で記入
  
  - name: "フィードバック収集"
    # 詳細は後で記入
  
  - name: "計画更新"
    # 詳細は後で記入

ここでは、“サブステップのアクション”や条件はまだ書かず、「こういう順序で進むんだな」と俯瞰できる程度でOK。
まるでアウトラインを作る感覚です。

STEP 3: 必要な質問セットを定義する

いよいよ「何を聞くか？」を具体化しましょう。MDCファイルでは、質問事項をまとめた“質問セット”を別セクションとして書くことができます。

# 質問セットの定義
dinner_questions:
  - question: "今日の夕食のメニュー名を教えてください"
    key: "dinner_menu"
    required: true
  
  - question: "食事人数は何名ですか？"
    key: "people_count"
    required: true
  
  - question: "調理予定時刻はいつ頃ですか？（例：18:00）"
    key: "cooking_time"
    required: true
  
  - question: "食事予定時刻はいつ頃ですか？（例：19:00）"
    key: "dinner_time"
    required: true
  
  - question: "予算はいくらくらいですか？（例：2000円）"
    key: "budget"
    default: "2000円（標準）"
    required: false
  
  - question: "食事で避けたい材料はありますか？（アレルギーなど）"
    key: "allergies"
    default: "なし"
    required: false
  
  - question: "その他の要望はありますか？"
    key: "special_requests"
    default: "なし"
    required: false

• question はユーザーに対して実際に投げる文言

• key は回答を格納する変数名

• required が true なら回答を必ずとる

• default で初期値を用意しておくと便利

このステップで、「最低限何を聞けば夕飯準備が成立するか？」を洗い出しているわけですね。「ここもまだ迷ってる…」という場合は、あとから足したり消したりしてOKです。

STEP 4: 出力テンプレートの作成

続いて、AIが最終的に生成するファイルのひな形（テンプレート）を定義しましょう。
たとえば計画ファイルや買い物リストなど、人間が後で見やすい形にしておくのがコツです。

templates:
  dinner_plan_template: |
    # 夕食準備計画
    
    ## 基本情報
    - 日付: {{current_date}}
    - メニュー: {{dinner_menu}}
    - 人数: {{people_count}}
    - 調理時間: {{cooking_time}}
    - 食事時間: {{dinner_time}}
    - 予算: {{budget}}
    - アレルギー: {{allergies}}
    - 特別な要望: {{special_requests}}
    
    ## スケジュール
    1. 買い物: {{shopping_time}}
    2. 下準備: {{prep_time}}
    3. 調理開始: {{start_cooking_time}}
    4. 配膳: {{serving_time}}
    
  shopping_list_template: |
    # 買い物リスト
    
    ## {{dinner_menu}}用食材
    {{shopping_items}}

• {{...}} の部分は、先ほどの質問セットや後ほどAIが計算する変数を埋め込む場所

• Markdown形式で見出し（#、##など）を使うと可読性が高まる

「どんなフォーマットで出したいか？」は人それぞれ。たとえば箇条書きや表組みにするのもあり。
「人間がそのファイルを見たときに役立つデザイン」を意識すると、後の作業がグッと楽になります。

STEP 5: 各ステップの詳細化

ここからが本番。STEP 2で作成した骨組みに、具体的なアクション（action）や条件、変数などを書き込んでいきます。

# 夕食の準備トリガー
trigger: "夕食の準備"
steps:
  - name: "start_info_collection"
    action: "call"
    target: "dinner_questions"
    message: "夕食の準備をするにあたって、質問させてください"
  
  - name: "get_current_date"
    action: "execute_shell"
    command: "date +%Y-%m-%d"
    variable: "current_date"
    message: "現在の日付を取得しています..."
  
  - name: "confirm_dinner_plan"
    action: "confirm"
    message: |
      以下の内容で夕食準備プロジェクトを開始します：
      - メニュー: {{dinner_menu}}
      - 人数: {{people_count}}
      - ...
      
      よろしいですか？
    variable: "plan_confirmed"
  
  - name: "calculate_times"
    action: "execute"
    script: |
      # 時間計算ロジック
      # 例）夕食時間-60分を調理開始に、さらに-30分を下準備に…
      ...
    condition: "{{plan_confirmed}} == true"
  
  - name: "create_dinner_dir"
    action: "execute_shell"
    command: "mkdir -p Dinner/{{current_date}}_{{dinner_menu}}"
    variable: "dinner_dir"
    condition: "{{plan_confirmed}} == true"
  
  - name: "create_dinner_plan"
    action: "create_file"
    path: "{{dinner_dir}}/plan.md"
    template: "dinner_plan_template"
    message: "夕食準備計画ファイルを作成しました"
    condition: "{{plan_confirmed}} == true"
  
  - name: "plan_created"
    action: "confirm"
    message: "初期プランを作成しました。計画の詳細をご確認いただけますか？"
    variable: "review_plan"
    condition: "{{plan_confirmed}} == true"
  
  - name: "dinner_plan_next_steps"
    action: "notify"
    message: |
      これから夕食の準備を進めるには以下のステップがあります：
      1. 「夕食の計画改善」と言って計画を改善
      2. 「夕食の買い物」と言って買い物フェーズへ
    condition: "{{review_plan}} == true"

• action: "call" で質問セットを呼び出し

• execute_shell でシェルコマンド（日付取得やフォルダ作成など）

• confirm でユーザーのYes/Noをとり、variable: "plan_confirmed" に入れる

• condition を使って「plan_confirmed == true のときだけ次ステップへ進む」

細かい動作をこうして複数ステップに分割して書くことで、AIが飛ばし読みするリスクを最小限に抑えられます。

STEP 6: 改善フロー用のステップも同様に詳細化

今回の例では「夕食の計画改善」という別トリガーにも対応します。
計画を出した後、ユーザーが「少し味付けを変えたい」「別のレシピを足したい」と言うパターンですね。

trigger: "夕食の計画改善"
steps:
  - name: "start_improvement"
    action: "notify"
    message: "「{{dinner_menu}}」の計画を改善します。どのような点を改善したいですか？"
  
  - name: "start_feedback_collection"
    action: "confirm"
    message: "フィードバック収集を開始します。各質問に具体的に回答してください。準備はよろしいですか？"
    variable: "start_feedback"
  
  - name: "collect_plan_feedback"
    action: "call"
    target: "plan_feedback_questions"
    variable: "plan_feedback"
    message: "プランについてのフィードバックを収集します..."
    condition: "{{start_feedback}} == true"
  
  - name: "update_dinner_plan"
    action: "modify_file"
    path: "{{dinner_dir}}/plan.md"
    template: "dinner_plan_template"
    data: "{{plan_feedback}}"
    message: "夕食準備計画を更新しました"
    condition: "{{start_feedback}} == true"
  
  - name: "improvement_summary"
    action: "notify"
    message: |
      プランの更新が完了しました。
      ここが変更点: ...
      次は「夕食の買い物」と言えば買い物リストへ進めます！
    condition: "{{start_feedback}} == true"

このように別のシチュエーションでも、似た構造（質問→確認→ファイル編集）を踏むだけです。
“modify_file”アクションを使えば、既存の計画ファイルを部分的に書き換えることも容易になります。

STEP 7: フィードバック用の質問セットを追加

計画改善用のフィードバック収集では、また別の質問リストが要るかもしれません。
ここでも“お好みの質問”を並べてOKです。

plan_feedback_questions:
  - question: "メニュー「{{dinner_menu}}」に追加したい料理はありますか？"
    key: "additional_dishes"
    default: "なし"
    required: false
  
  - question: "辛さ・味付けなど変更要望はありますか？"
    key: "recipe_preferences"
    default: "なし"
    required: false
  
  - question: "他に気になる点や改良したいポイントがあれば教えてください"
    key: "other_feedback"
    default: "なし"
    required: false

STEP 8: 評価とテスト

MDCファイルが完成したら、実際にCursorで「夕食の準備」と呼びかけてみてください。

• ちゃんと最初に質問セットが起動するか？

• ユーザーがYes/Noを答えたら適切に次ステップへ？

• ファイル生成が想定通りに動くか？

• conditionが効いているか？

このチェックをこまめにしておくと、不備が見つかりやすいです。
とくにYAMLはインデントやコロンの付け忘れなどでエラーになりがちなので、最初は細かくテストするのがおすすめ。

STEP 9: リファクタリングと改善

テストしてみると、「質問文をもっと優しい言い回しにしたい」「この順番は微妙かも…」など、いろいろ気づく点が出てくるでしょう。

• 冗長な部分を簡略化

• 変数名の一貫性をチェック

• コメントを追記

• アクションの重複をテンプレ化

こうしたリファクタリングを繰り返すと、MDCファイルが整ってきて、AIの動作もいっそう安定します。

STEP 10: 拡張と応用

基礎ができあがったら、次は“もっと便利に”がキーワード。たとえば…

1. 買い物フェーズの専用トリガー

   • 「夕食の買い物」で呼び出し → 必要な食材リストや在庫確認

2. 調理手順ガイド

   • タイマー実行(execute_shell)で3分計ってアラームを出すなど

3. API連携でレシピ検索

   • クックパッドやGoogle検索的なものと絡めて、より多彩な提案

4. 複数メニュー提案

   • 「今日は3パターンの夕食アイデアを出して」といった分岐

5. エラー対策

   • もしユーザーが何も答えてくれない場合の対応、など

やりたいことが増えれば、MDCファイルも長くなるかもしれませんが、「ファイルを分割」したり「質問セットを共通化」したりすればOK。

最初の例がしっかり動くようになっていれば、拡張もスムーズにできます。

Ruleファイルで押さえておきたい5つの工夫

先ほどの夕食準備エージェントハンズオン例では、基本的なMDCファイル作成の流れをご紹介しました。ハンズオンの説明の中でも言及してきましたが、あらためて、Ruleファイルの作成Tipsをまとめます。

1）ステップをなるべく“細切れ”に

「シンプルに書いたほうが人間的にわかりやすいはず…」 という気持ちはわかりますが、AIは逆に、まとめられすぎた指示を自分勝手に省略しがち。
たとえば「質問→確認→ファイル生成→再確認」の流れを1ステップに詰め込むと、

• ユーザー確認をスキップしていきなりファイルを作る

• 「ここは何も聞かなくていいだろう」と独断で先に進む

など、“飛ばし”や“飛躍的勘違い”が起こりやすくなります。

具体例:

- name: "ask_menu"
  action: "ask_question"
  question: "夕飯のメニューは？"
  variable: "dinner_menu"

- name: "ask_people"
  action: "ask_question"
  question: "何人分作りますか？"
  variable: "people_count"

- name: "confirm_plan"
  action: "confirm"
  message: "このプランで良いですか？"
  variable: "plan_ok"

こんな具合に、1ステップ=1アクションに近い形で区切るほど、AIは混乱しにくくなります。
「見た目が冗長になりそう…」と思うかもしれませんが、省略すると逆にトラブル増というのがよくあるパターン。細かく切り分けるほど、ユーザーとAI双方にやさしい構造になります。

2）「確認ステップ」を入れて“暴走”を防ぐ

「ユーザーがYesと言う前に先に進んでしまう」――これはAIに限らず、仕事のできる（？）秘書がハイテンションに独走する感じにも似ています。
confirm アクションや condition を活用して、「OKでなければこの先には行かない」 というルールをしっかり組み込みましょう。

- name: "check_budget"
  action: "confirm"
  message: "予算は{{budget}}円ですがよろしいですか？"
  variable: "budget_ok"

- name: "create_plan"
  action: "create_file"
  template: "plan_template"
  condition: "{{budget_ok}} == true"

こんなふうに予算確認をユーザーが承認したら次へ、というスキームにすると、想定外に買い物リストを作られるなどの事故が減ります。

3）テンプレートや質問セットは別ファイルに分ける

ハンズオン例では、同じMDC内に質問セットやテンプレートを定義しました。ただ、プロジェクトが大きくなると1つのファイルが何百行にもなり、可読性がガタ落ちします。

おすすめ分割例:

• main.mdc：メインのフロー記述

• questions.yaml：複数の質問セットをまとめる

• templates.mdc（またはtemplates.yaml）：出力ファイルのテンプレート群

こうすることで、質問文を直すだけならquestions.yamlを開けば済むし、テンプレ変更はtemplatesのファイルだけいじればいい、という形にでき、保守や拡張がラクになるんです。

4）同じ質問を何度もしない工夫

ときどき「さっきアレルギー聞いたのに、また聞くの…？」というループ事故が起きることがあります。これには変数の状態やconditionが有効です。

- name: "ask_allergies"
  action: "ask_question"
  question: "アレルギーはありますか？"
  variable: "allergies"
  condition: "{{allergies}} == null"

• condition: "{{allergies}} == null"
  つまり**“allergiesに何も入っていない場合だけ”** 質問する

• もし既にユーザーが答えたなら同じ質問をスキップ

この仕組みは「変数のデフォルト値が設定済みか？」などでも応用でき、無駄なリピートを抑えてスマートにやり取りできます。

5）ルールファイルを機能ごとに分割してカオスを回避

「dinner_plan.mdc」「dinner_improvement.mdc」 のように、エージェントの機能やシーン別にファイルを切り分けると、巨大MDCを1ファイルに詰め込むよりも大幅に管理しやすくなります。

• 例えば、「夕食準備」と「買い物フェーズ」「調理フェーズ」を別々に

• あるいは「メイン.mdc」「feedback.mdc」など機能単位に

(＋)さらなる規模になると、「projectA_main.mdc」「projectA_feedback.mdc」「projectA_deploy.mdc」のようにプロジェクト・フェーズ・用途で自然に切り分けると、“変更したい部分”をサッと探して編集できるようになります。

カスタマイズしてみよう

わかったような、わからないような？という方はさきほど紹介したこちらのRulesを実際にDLしてカスタマイズしてみたりするところからはじめるのをおすすめします！

1. 質問内容のカスタマイズ

   • 質問を追加・削除してみる

   • デフォルト値や選択肢を変更する

2. テンプレートの修正

   • 出力フォーマットを自分好みに調整

   • 新しい変数を追加してテンプレートに反映

3. 新しいトリガーの追加

   • 例えば「朝食の準備」など、別のシーンでの活用

4. アクション追加

   • 栄養情報を取得するAPIとの連携

   • 画像生成ツールとの連携

応用アイデア

サンプルリポジトリを元に、以下のようなカスタマイズも考えられます：

• 料理レシピ検索機能の追加

• 食材の在庫管理システムとの連携

• 栄養バランス計算機能の実装

• 複数人での食事プラン調整機能

このリポジトリを通じて、YAMLファイルによるエージェント制御のノウハウを実践的に身につけていただければ幸いです。

「タスクに応じた適切なレベル」を選ぼう

まぁここまでいうと、YAMLかーめんどくさいなーAIめんどくさいからやめようーというひともでてくるかもしれませんが

というわけではない、という大切なポイントを押さえましょう。ケースバイケースです！

● ケース別の目安

• 単発の一問一答: シンプルプロンプトで十分
  例：「今日の天気教えて」「最新ニュースをまとめて」など、1ステップで事足りる場合

• 3～5ステップ程度の短い対話: ベースのYAML
  例：夕飯準備の例ぐらいの小～中規模のフロー

• 分岐が多い長期的プロセス: 本格的なYAML設計
  例：プロジェクト管理、複数ファイル自動生成、API連携など条件が複数重なる大規模な流れ

● バランス重視

「学習コスト＞メリット」となる状況なら、ムリにYAML化する必要はありません。
むしろ、まずはシンプルなチャット指示で試して、どうしても安定しないとなったら、一部を構造化してみる…というステップアップがおすすめです。

ただし、実務や大規模タスクで繰り返し同じ指示をするような場面だと、構造化しておくと圧倒的に安定します。
「何度も同じことで混乱する」より、一度YAMLでしっかり書いてしまうほうが長期的なストレス軽減に繋がるのは間違いないでしょう。

まとめ：もっと安定＆高精度なエージェントに育てよう

今回紹介した「夕食の準備」エージェントは、あくまでルール設計の一例です。実際にはビジネスシーンでのプロジェクト管理やAPI連携を使った自動化など多岐にわたって応用できます。

一見、YAMLを書くのは手間に思えますが、ほんの少し構造化するだけでCursorエージェントの“やる気”と“正確性”が段違いになります。

Cursorは自分好みに育てるほど、「あれ、AIがどんどん仕事をサポートしてくれる…？」 とその威力を実感できるはず。

ハンズオンで作った夕食準備エージェントなどを是非これらのヒントで磨き上げて、自分専用の“超安定AI秘書”を育ててみてください！！！！！

(おまけ)

さて、私のアカウントで最近よく話題にださせていただいている「俺の考えた最強のAIPMシステム」は、完全に今回紹介した内容の発展編となっております。もし、今回のようなルールズの使い方をさらにもうちょっと応用事例しりたいなーというかたいらっしゃいましたら、こちらもぜひぜひおためしくださいー。

（追記）

こちらのAIPMシステムについての新しい記事を公開しましたのでもしよろしければご覧ください

【最後にいつもの宣伝】 エクスプラザでは仲間を募集しています！！

「AIエンジニア」から「AIプロデューサー」まで多様なポジション

私が所属するエクスプラザは急拡大フェーズで、下記のような役割を担う仲間を募集しています。

詳しい募集要項や福利厚生などは、こちらの求人ページをご覧ください。

• LLMアプリケーションエンジニア（正社員）

• AI プロデューサー（正社員）

• リード AI プロデューサー（正社員）

• オープンポジション

エクスプラザってどんな会社？

生成AIの社会実装を担う、実装型コンサル＆プロダクト企業でして、2020年創業でまだメンバもーも10人強の若く会社ですが、AI技術とプロダクト開発の両輪を武器に、「生成AIの社会実装」を掲げる注目のスタートアップです。

カルチャーデックはこちら

2023年には松尾研究所とも資本業務提携し、さらに2025年以降は生成AIを全面強化していくタイミングになってます！

エクスプラザではこの記事でもとりあげたCursorをビジネス、エンジニア問わず全社で使い放題になりました！

この記事でCusrorの普段使い日本気になった皆様！是非私たちと一緒に、AIネイティブな社会をつくっていきませんか！！Cursorも使い放題ですし！w　ぜひぜひよろしくおねがいします！