.clinerulesに何を書けば満足できるか?

2025/03/05に公開

はじめに

rulesに何を書けば理想のコードに行き着くのかを工夫していますが、やればやるほどシンプルにする方が色々いいんじゃないか?と思ってきています。

この仮定を確認するためDDD(ドメイン駆動開発)のサンプルコードを生成してみた、という試みです。

生成したコードのリポジトリ

https://github.com/tKwbr999/agent-ddd

利用言語はGoです。

言語未指定の場合はtypescriptのコードになりましたが、typescriptの知見がほとんどなく評価できなかったため、使い慣れたgoを指定しました。また、フレームワークの指定はしていません。指定することで余計なtoken消費があることを懸念したためです。

このリポジトリで試したこと

このリポジトリは、DDD(ドメイン駆動設計)の様々なルールを検証するために作成されました。
clineによる自動生成で全くコードに触れずmain関数の実行を確認するまでをひと区切りとしています。
modelにはgemini-2.0-flash-thinking-exp-01-21を利用しています。

各プロジェクトでclineに指示したプロンプト

(対象ディレクトリ)にgoでDDDのサンプルを実装して

プロジェクト構成

このリポジトリは、主に3つのプロジェクトで構成されています。

  • none-rules-ddd: DDDのルールを特に適用していないシンプルなプロジェクトの例です。
  • generated-ruled-ddd: ルールを適用して生成されたDDDプロジェクトの例です。claude-3.7-sonnetでDDDのルール生成してます。
  • simple-rules-ddd: シンプルなDDDのルールを適用したプロジェクトの例です。ディレクトリ構成と開発手法だけ端的に書いてます。

各プロジェクトで試したことの詳細は、それぞれのプロジェクトのディレクトリ内にあるREADMEやコードを参照してください。

消費トークン

各列の説明:

  • プロジェクト: プロジェクト名
  • ファイルサイズ: プロジェクトのファイルサイズの合計
  • Tokens (Prompt): プロンプトトークン数
  • Tokens (Completion): 生成トークン数

一覧表

プロジェクト ファイルサイズ Tokens (Prompt) Tokens (Completion)
none-rules-ddd 1.6 MB 937.0k 6.1k
ruled-ddd 768 kB 6.4m 14.2k
simple-rules-ddd 399 kB 1.3m 8.7k

コード評価

各プロジェクトの内容を参照し、コード品質とトークン消費量をclineにて評価してもらいました。

  • none-rules-ddd

    • コード品質: DDDルール非適用のため、ドメイン層とインフラ層の分離が不明確。コードの見通しは良くない。
    • トークン消費量: ファイルサイズ大のため、プロンプトトークン数が多くなっている。
  • ruled-ddd

    • コード品質: DDDルール適用で生成されたコード。ドメイン層、アプリケーション層、インフラ層が分離されており、コード品質は高い。
    • トークン消費量: コード生成にトークンを消費したため、プロンプトトークン数が非常に多い。
  • simple-rules-ddd

    • コード品質: シンプルなDDDルールを適用。none-rules-dddよりコードの見通しは良いが、ruled-dddほどの厳密な分離はなし。
    • トークン消費量: ファイルサイズとコード量がruled-dddより少ないため、トークン消費量は比較的少ない。

コスパを重視したrulesの記載内容の考察

simple-rules-ddd に記載したrulesは、必要最低限のルールに絞っているため、コード生成にかかるトークン数を抑えつつ、一定のコード品質を担保できると考えられます。

特に、ディレクトリ構成と手法を限定することで、生成されるコードの一貫性を保ち、保守性を高める効果が期待できます。

一方で、より複雑なドメインロジックを実装する場合には、ruled-ddd のように、より詳細なルールを適用した方が、より高品質なコードを生成できる可能性はあります。しかし、その分トークン消費量が増加するため、コストと品質のバランスを考慮してrulesを記述する必要があるとわかります。

結論

こだわりの強さが承認される環境では細かく設定をした方がよさそう。

ただ、複数プロジェクトの掛け持ちとか、技術的な決裁権がないとか、他にリードしている人がいるような場合は開発手法だけをシンプルにまとめた方が汎用性が高そう。

GitHubで編集を提案

Discussion