iOS エンジニアが Cursor Rule を上手に使ってみた話（2025/06）

はじめに：AIは「部下」か、それとも「パートナー」か？

AIによるコーディング支援がすっかり当たり前になりましたね。多くの開発者がその便利さを享受する一方で、私たちは新しい問いと向き合っています。それは、「AIをどうやって、単なる指示待ちのツールから、自律的に考え、プロジェクトを一緒に進めてくれる『パートナー』に育て上げるか？」という問いです。

目の前のタスクをこなしてもらうだけなら、簡単な指示で十分かもしれません。でも、設計の意図を汲み取り、コードの品質を守り、長い目で見て開発をぐんと楽にしてくれる、そんな頼れるパートナーに育てるには、私たち人間側にも「AIとの対話のしかた」が問われているのではないでしょうか。

この記事では、私が約1ヶ月かけてじっくり育ててきた、CursorのAIと上手に協力していくためのルールたち、特にその中心となる「フェーズベース・ワークフロー」という考え方をご紹介します。これは、AIに「何を」「どういう順序で」考えてもらうかを決め、開発プロセス全体をスムーズに進めるための、いわば「作戦図」のようなものです。さらに記事の後半では、この考え方をiOS開発の現場でどう活かしているか、ビルド自動化のスクリプトを例に具体的にお話しします。

この記事が、あなただけの優秀なAI開発パートナーを育てるための、何かのヒントになれば嬉しいです。

この記事の要点

この記事では、AIを単なるコーディングツールから、自律的に考えてプロジェクトを一緒に進めてくれる「パートナー」へ育てるための、具体的なアイデアをお届けします。

• 思考をステップに分ける AIの作業を「解析」「準備」「実行」「検証」という4つの分かりやすいステップに分解する 「フェーズベース・ワークフロー」 を取り入れてみましょう。こうすることで、AIが今何をしているのかが分かりやすくなり、私たちも、どの段階でどんな支援をすればよいか判断しやすくなります。
• 知識を外付けする プロジェクトごとの設計思想やコーディング規約といった専門知識は、 「ドメイン・ルール」 として外に切り出しておきます。AIは、決まった手順と専門知識をその都度組み合わせることで、状況に応じたベストな判断ができるようになります。
• 一緒に成長する仕組み AIが「あれ、ちょっと違ったかな？」と自ら気づき、ルール自体を賢く修正していく 「自己改善プロセス」 を取り入れるのがポイントです。人間からのフィードバックを元に、ルールがどんどん賢く育っていきます。
• 具体的なツールと繋ぐ こうした抽象的なルールを、iOS開発のビルド自動化スクリプトのような具体的なツールと繋げることで、AIのパワーを最大限に引き出す方法も見ていきましょう。

この一連の仕組みを通して、AIとの協力関係を次のレベルに引き上げるための、考え方のヒントをお伝えできればと思います。

全体像：ルール構造の鳥瞰図

私たちが目指すAIとの協力体制を理解するために、まずは全体像から見ていきましょう。以下の図は、ユーザーからの指示を起点に、AIがどのように思考し、各ルールを参照するかの流れを示したものです。

中心に位置するのが、すべての指示を受け付ける司令塔でもあるagent-workflow-controllerです。ここからタスクは4つの明確なフェーズ（Core Workflow）に分解され、各段階で必要となる専門知識（Knowledge Base）が参照されます。さらに、この構造自体を改善していくための自己改善プロセス（management）も組み込まれているのが特徴です。

以降の章で、これらの各要素がどのように連携し、AIの思考を導いていくのかを詳しく解説していきます。

第1章：すべての基本となる「司令塔」ルール

開発プロジェクトが混沌とする原因の多くは、「誰が」「何を」「いつ」やるのかが不明確なことにあります。AIとの協業においてもそれは同じです。そこで、私のルールシステムの心臓部として機能するのが、たった一つの司令塔ルール、agent-workflow-controllerです。

なぜ「単一の入り口」が重要なのか？

この司令塔ルールは、AIが受け取るすべての指示を最初に処理する、唯一の「受付窓口」です。なぜこれが重要なのでしょうか？

1. 秩序の維持 すべてのタスクが同じ入り口を通ることで、作業の優先順位付けや進め方に一貫した基準を適用できます。場当たり的な指示が飛び交うことを防ぎ、プロジェクト全体に秩序が生まれます。
2. 責任の明確化 司令塔の役割は「ワークフローの交通整理」に特化しています。具体的な実装方法やテスト方針といった「どうやるか」は、後続の専門ルールに委譲します。これにより、問題が発生した際にどこを修正すればよいかが明確になります。
3. 拡張性の確保 新しいツールを導入したり、開発プロセスを変更したりする際も、この司令塔ルールとの「接続方法」を定義するだけで済みます。システム全体が疎結合に保たれ、変化に強い構造を維持できるのです。

司令塔は、AIに対して「君はまず、この手順で考えなさい」という思考のOSをインストールするようなもの。これにより、AIは単なるコマンド実行機から、プロジェクトの文脈を理解するパートナーへと進化します。

第2章：タスクを分解する「フェーズベース・ワークフロー」

司令塔が受け取ったタスクは、次に4つの明確なフェーズに分解されます。これは、複雑なソフトウェア開発を、人間が理解しやすい一連のステップに変換するための極めて強力な思考法です。

Phase 1: Analysis (解析) - 何をすべきか明確化

最初のステップは、ユーザーの指示の意図を正確に理解することです。「このバグを直して」という一言の裏には、どのような背景があり、根本原因は何で、どのような影響範囲が考えられるのか。AIはここで、コードベースや関連ドキュメントを調査し、タスクの全体像を把握します。

Phase 2: Preparation (準備) - どう進めるか計画

タスクの全体像が見えたら、次に行うのは計画立案です。どのような手順でコードを修正し、どのファイルを変更し、どのようなテストを追加すべきか。この段階で具体的な作業計画（ロードマップ）を立てることで、手戻りを防ぎ、AIの作業の透明性を確保します。

Phase 3: Execution (実行) - 計画に基づき実装

いよいよ実装です。しかし、やみくもにコードを書くのではありません。Phase 2で立てた計画に基づき、一つ一つのステップを着実に実行します。変更は小さく、頻繁に。これにより、予期せぬ問題が発生しても、原因の特定が容易になります。

Phase 4: Verification (検証) - 正しくできたか確認

コードを書き終えたら、それが本当に正しく動作し、既存の機能を破壊していないかを確認します。ビルド、テスト、静的解析などを自動で実行し、品質基準を満たしていることを客観的に証明します。このフェーズがあるからこそ、私たちは安心してAIの提案を受け入れることができるのです。

このフェーズベースのアプローチは、AIの作業プロセスを「ブラックボックス」から「ホワイトボックス」へと変え、私たち開発者がAIの思考を理解し、適切に導くことを可能にします。

第3章：専門知識を注入する「ドメイン・ルール」

これまで解説した司令塔とフェーズベースのワークフローは、いわばAIの思考の「骨格」です。しかし、これだけでは高品質な成果物は生まれません。次に必要となるのが、プロジェクト固有の規約や設計思想といった「血肉」、すなわちドメイン（専門分野）ルールです。

私のルール群では、domains/ ディレクトリ以下に、専門分野ごとのルールファイルを配置しています。

• coding-implementation.mdc: コーディング規約、命名規則、エラーハンドリング方針など
• module-architecture.mdc: モジュール間の依存関係、API設計の原則など
• testing-quality.mdc: テストの書き方、モックの利用法、カバレッジ基準など
• ui-implementation.mdc: UIコンポーネントの利用法、SwiftUIのベストプラクティスなど

これらのドメインルールは、主にワークフローのPhase 2（準備）とPhase 3（実行）から参照されます。

例えば、AIが新しい機能を実装する際、司令塔はまずフェーズベースのワークフローを起動します。そしてPhase 2の計画段階で、AIはmodule-architecture.mdcを参照して「どのモジュールにコードを追加すべきか」を判断し、coding-implementation.mdcを読んで「どのような命名規則でクラスを設計すべきか」を学びます。

このように、汎用的なワークフローと専門的な知識を分離することで、AIは「何をすべきか（フェーズ）」と「どうやるべきか（ドメイン）」を明確に区別して思考できるようになります。これは、AIに「わが社のエースエンジニア」の思考様式をインストールするようなものです。

第4章：ルール自身を育てる「自己改善プロセス」

ルールは一度作ったら終わりではありません。プロジェクトは変化し、チームの知見は蓄積され、AIの能力も日々向上します。開発パートナーであり続けるためには、ルール自体が環境の変化に適応し、成長していく仕組みが必要です。

そのために設けているのが、management/ ディレクトリと、その中核をなす自己改善ルールでもある rule-enhancement.mdc です。

この仕組みは、PDCAサイクルにおけるAction（改善）を担います。

例えば、AIが私たちのコーディング規約に沿わないコードを生成したとします。その際、私たちは単にコードを修正するだけでなく、「なぜルールから逸脱したのか？」を問いかけ、rule-enhancement.mdc を起動するよう指示します。

指示を受けたAIは、自らの過ちを分析し、「coding-implementation.mdc の記述が曖昧だった」あるいは「新しい規約が追加されたのに未反映だった」といった根本原因を特定します。そして、AI自らの手で、関連するルールファイルを修正するのです。

この自己改善プロセスを持つことで、私たちのルールシステムは、日々の開発業務を通じて自動的に洗練されていきます。人間からのフィードバックを糧に、AIが自ら賢くなっていく。これこそが、AIを単なるツールから真のパートナーへと育てる鍵なのです。

第5章：実践編 - スクリプト連携でiOS開発を加速する

ここまでは、AIの思考法を定義する概念的なルールを中心に解説してきました。この章では、より実践的な活用例として、私がiOS開発で実際に利用している「ビルドとテストの自動化」をご紹介します。

AIにビルドを委ねるということ

iOS開発において、ビルドは頻繁に発生するものの、決して創造的とは言えない作業です。私たちは、この時間をより本質的な課題解決に費やすべきです。そこで、私はビルドとテストの実行をAIに委譲しています。

しかし、単に xcodebuild コマンドを実行させるだけでは不十分です。それでは、AIは単なるコマンドランナーに過ぎません。真のパートナーとなってもらうためには、AIが「いつビルドすべきか」を判断し、「結果をどう解釈するか」までを理解している必要があります。

賢いビルドスクリプトと連携する

そのために用意したのが、プロジェクト専用のカスタムビルドスクリプトです。このスクリプトは、単にビルドを実行するだけではありません。

1. 変更検知: まず git status などを利用し、監視対象のパッケージに変更がなければ、ビルド自体を賢くスキップします。これにより、不要なビルド時間を徹底的に削減します。
2. 最適化されたビルド: xcodebuild を直接実行するのではなく、キャッシュを最大限に活用するオプションを付与して呼び出します。
3. 詳細な結果レポート: ビルドが失敗した場合、ログの中からエラー箇所を抽出し、原因の可能性（例：「モジュールの依存関係エラー」など）まで分析して報告します。

例えば、以下のようなスクリプトをイメージしてください。

#!/bin/bash

# 1. 変更検知
# 監視対象のパッケージに変更がなければ、処理を終了
if git diff --quiet HEAD -- path/to/your/package; then
    echo "変更はありません。ビルドをスキップします。"
    exit 0
fi

# 2. 最適化されたビルド
# キャッシュを活用し、不要な処理をスキップ
xcodebuild build \
  -scheme "YourAppScheme" \
  -derivedDataPath ".derived_data" \
  | tee build.log

# 3. 詳細な結果レポート
if [[ ${PIPESTATUS[0]} -ne 0 ]]; then
    echo "❌ ビルド失敗"
    # build.log からエラー箇所を抽出し、要約して報告
    grep "error:" build.log
    exit 1
else
    echo "✅ ビルド成功"
fi

AIは、「ビルド・デプロイに関するルール」に基づき、コード変更後の検証フェーズで必ずこのスクリプトを呼び出します。

この連携により、私は「ビルドして」と指示する必要すらありません。コードの修正を終えれば、AIが自動的に検証プロセスを開始し、ビルド結果を人間が分かりやすい形で要約して報告してくれます。失敗すれば、エラー箇所と解決のヒントまで提示してくれるのです。

このように、決まりきった作業をAIに任せ、その結果の分析までお願いすることで、私たちは頭のメモリを節約し、もっと創造的な作業に集中できるようになるのです。

おわりに：あなただけのAIパートナーを育てる旅へ

この記事でご紹介した「フェーズベース・ワークフロー」と自己改善するルールシステムは、一見すると少し難しく感じるかもしれません。でも、その根底にある考え方はとてもシンプルです。それは、「AIに思考の型を教え、対話を通じて共に成長していく」という、ただそれだけのこと。

このアプローチの面白いところは、特定の言語やフレームワークに縛られない普遍的な点です。あなたがiOSエンジニアでも、Web開発者でも、あるいはデータサイエンティストでも、ご自身の開発プロセスを「ステップ」に分け、守ってほしい「ルール」を言葉にすることで、AIとの連携はもっとスムーズになるはずです。本記事で紹介したiOSのビルド自動化のように、抽象的な「ルール」と具体的な「スクリプト」を組み合わせれば、その効果はさらに高まるでしょう。

もし、どこから手をつけていいか迷ったら、まずはこんな小さな一歩から始めてみてはいかがでしょう。

1. あなたの頭の中をのぞいてみる あなたがコードを書く前に、頭の中で自然とやっていること（情報集め、設計、実装、テストなど）を、一度言葉にして書き出してみる。
2. 小さなお願いごとをしてみる 例えば、「コミットする前には、必ずこのコマンドを実行してね」といった、ごく簡単なルールを一つだけ作って、AIにお願いしてみる。
3. フィードバックをプレゼントする AIがルールを守れなかった時に、ただ直してもらうだけでなく、「どうして上手くいかなかったんだと思う？」と問いかけ、ルール自体を一緒に見直すきっかけを作ってみる。

AIは、私たちに新しい「考える道具」を与えてくれました。彼らを単なる作業員として見るのではなく、対話し、教え、共に成長するパートナーとして迎え入れてみませんか。その先には、きっと今よりもっと創造的で、わくわくするような開発の未来が待っている。私はそう信じています。