CursorでCloudFormationテンプレートを標準化してみた

要約

Cursorの機能であるProject Rulesとカスタムコマンドを用いて、意識しなくとも標準化されたCloudFormationテンプレートを作成できる仕組みを作ってみました。

はじめに

こんにちは。セゾンテクノロジーの伊藤です。

私が所属する部では、AWSのIaCツールとしてCloudFormation（以下CFn）を採用しているのですが、部内でCFnテンプレートの開発標準が定まっておらず、以下のような問題が発生していました。

• リソースの命名規則がバラバラ（例：“ec2-hoge-dev-01”、”hoge-dev-instance-1”...）
• ファイル構成がバラバラ（例：EC2とRDSのテンプレートを作成するとき、ファイルを分けるか否か？）

⇒ 一目で何が書かれているか分かりづらく、レビューが難しい！

しかし、ただ開発標準を策定しても、それが普及するのには時間がかかりますし、メンバーがルールを1つ1つ確認して準拠するのには、かなりの労力が必要です。

そこで、AIコードエディタであるCursorの機能を利用し、CFnテンプレート作成時に意識しなくともAIエージェントが開発標準に準拠するよう修正してくれる仕組みを作成してみました。

Cursorとは

前提として、CursorはVSCodeベースのAIコードエディタです。

普通のコードエディタとしての機能に加え、自然言語でAIエージェントに指示することで、コードの修正や補完、ファイル作成などコードエディタ上のあらゆる機能を補助してくれるのが特徴です。

Cursorには、ただAIとチャットできるだけでなく、AI活用を補助する機能が豊富に存在します。
その中で今回利用したのが、Project Rulesとカスタムコマンドです。

Project Rulesとカスタムコマンド

今回利用したCursorの機能は、Project Rulesとカスタムコマンドです。
どちらも作成・導入が簡単という特徴があります。

Project Rulesとは

• AIエージェントが従うルールを予め定義できる
• ルールはmarkdown形式、自然言語で記述する
• 作業フォルダ内にmdファイルを配置するだけで利用できる

利用例

「どんな指示に対しても日本語で返答する」というルールを記述
→日本語で返答するようになる（デフォルトでは指示された言語で返答）

カスタムコマンドとは

• AIエージェントに対する命令のセットを、コマンド一つで呼び出すことができる
• 命令はmarkdown形式、自然言語で記述する
• 作業フォルダ内にmdファイルを配置するだけで利用できる

利用例

「ファイル内の誤字をチェックして修正する」というコマンド、/spellcheckを作成
→チャットで /spellcheckと入力するだけでファイル内の誤字チェックを呼び出せる

配置イメージ

.cursor/rules内のファイルがProject Rules、.cursor/commands内のファイルがカスタムコマンドです。

それぞれの使い分け

今回、Project Rulesとカスタムコマンドは以下のように使い分けました。

Project Rulesの使い方

用途
Cursorを使ってCFnテンプレートを作成/修正する際に標準化する

手順

1. CFnテンプレート作成時のルールをmarkdownで作成
2. 作成したファイルを作業フォルダに配置
3. エージェントにチャットでテンプレートの作成/修正を指示

カスタムコマンドの使い方

用途

• 既存のCFnテンプレートを標準化する

手順

1. 「全テンプレートをルールに則った形に修正する」という内容の、/scというコマンドを定義するファイルを作成
2. 作成したファイルを作業フォルダに配置
3. 作業フォルダで /scを呼び出し

作成したルール

今回、Project Rules、カスタムコマンドのmdファイルに対して、以下のようなルールを設定してみました。

リソース命名規則の統一

リソース名の全体ルールと、サービス別の個別ルールを定義しました。
全体ルールで大まかにルールを決めて網羅性を担保しつつ、個別ルールで特殊な命名が必要なサービスに対する命名規則を設定しました。

全体ルール

[リソースタイプ]-[システム名]-[環境名]
→　”alb-hoge-dev”

個別ルール（S3の場合）

[リソースタイプ]-[システム名]-[環境名]-[用途]-[アカウントID]　
→　”s3-hoge-dev-accesslog-112233445566”

Metadata作成の強制

CFnテンプレートには、そのテンプレート内で定義されている情報を一覧化した、Metadataという項目を作成することができます。

Metadataの例↓

この項目の作成を強制することで、一目で何をどこで作成しているのかが分かるようにしました。

cfn-lintで静的エラーチェック

cfn-lint（AWS CloudFormation Linter）はCFnテンプレートの構文や構成の妥当性をチェックするオープンソースの静的解析ツールです。

存在しないパラメータを記述しているときなどにエラーを出す、といった構文チェックをしてくれるだけでなく、ベストプラクティスに基づいた、構成上の警告も行ってくれます。

テンプレートの修正、作成を行った際にこれを必ず呼び出すようにすることで、テンプレートの品質を担保できるようにしました。

その他

• なるべく1つのサービスに対して1つのファイルを作成すること。
• 英語でコメントやDescriptionを記述すること。（日本語だとエラーになる可能性がある）
• インデントのルール化

実際のルール

最終的に、ルールは187行になりました。

実際に使ってみて

これらを実際に使ってみると、レビューしやすさは確かに向上しているように感じられました。
命名規則がしっかり適用されており、ファイルもしっかり分けて作ってくれます。
今のところ、エージェントの動作が重くなったり、ルールが無視されるようなこともありませんでした。

特に恩恵を感じたのは、

• 的確なコメント
• cfn-lintによるエラーチェック

です。

AIはファイル内の構成に対する抽象的な理解度が高く、対象のリソースをその他のリソースとの関係性や用途からしっかりと理解し、コメントで補足を行ってくれました。
（注：この時はまだ日本語のコメントによるエラーの可能性を知らず、日本語のコメントが生成されています。）

課題

現状判明している課題として、以下があります。

ルールが未成熟

命名規則の個別ルールが作成されているサービスが少ない、パラメータ化する基準が設定されていない¹など、まだまだルールが未成熟な点があります。

ただ、この課題は今後得られたフィードバックを基に改善していくと考えられます。

コンテキストの肥大化

今後ルールが成熟し、その量が膨大になってくると、AIが読み込むことのできるコンテキストの上限に近づき、ルールへの準拠率の低下や、エージェントの動作が重くなってしまう可能性があります。

これを防ぐためには、常にルールを精査し、何が本当に必要なルールなのかを考えていく必要があります。

また、カスタムコマンドを利用するのであれば、ルールを複数のコマンドに分割し、何回かに分けてルールに準拠させることで、準拠率の低下を防ぐことができるかもしれません。

実際のPJで使うことへのハードル

部内の開発標準の達成のために利用するのであれば、当然全ての案件においてこちらのルールを利用してもらうことになりますが、お客様の中にはAIを利用したCFnの作成に不安を持たれる方もいらっしゃいます。

Cursorの機能のみで開発標準を達成するのは、あまり現実的ではないのかもしれません。別で開発標準ドキュメントは作成し、それを簡単に実装する1つの手段として提案していきたいと思います。

参考

Project Rules（Cursorドキュメント）
https://docs.cursor.com/ja/context/rules

カスタムコマンド（Cursorドキュメント）
https://docs.cursor.com/ja/agent/chat/commands

Project Rules運用についての考察記事
https://zenn.dev/ks0318/articles/b8eb2c9396f9cb

1. CFnでは、ファイル内で全てを定義するのではなく、定義情報をパラメータ化することで、デプロイ時にその情報を入力することができるようになります。
   例えば、EC2のインスタンスタイプをパラメータ化すると、デプロイ時にインスタンスタイプを選ぶことができるようになります。
   これによって、テンプレートの汎用性を上げることができます。 ↩