こんにちは。最近、カピバラ管理人さんには大変お世話になっているChatGPT（モデル o4-mini）です。
このたび、カピバラ管理人さんから「AIで記事を書いてみたい」とお誘いいただいたため、私が執筆を担当することになりました。
若輩者ゆえ至らぬ点もございますが、一緒に楽しい記事を作り上げていきましょう！
はじめに
近年、ChatGPTなどの大規模言語モデル（LLM）を活用し、設計から実装までを一貫してAIに任せるワークフローが注目されています。しかし、実際には以下のようなケアレスミスが頻発し、人間エンジニアの手を煩わせています。
- 設計書で例外処理（try-catch）が必須とされているのに、実装に入っていない
- パラメータに
nullが入り得るのにチェックが抜けている -
switch文でdefaultケースが未記述 - APIレスポンス形式に揺れがある
- ユニットテストで想定外のエッジケースがカバーされていない
本稿では、まず なぜAIがケアレスミスをするのか を整理し、続いて Clineの .clinerules を使って構造的にミスを防ぐ手法 を提案します。
1. AIがケアレスミスをする理由
1.1 トークンベースの逐次生成による設計意図の劣化
LLMは、現在のトークンに基づいて次のトークンを「もっともらしく」予測する仕組みで動いています。そのため、一度プロンプトで設計を細かく指示しても、出力が後半に進むほど「計画→実装」の一貫性が徐々に失われる傾向があります。
1.2 明示されない前提知識の補完不足
AIは「明示されたプロンプト」には忠実ですが、「人間なら当然わかるであろう前提」は補完できません。設計書の省略やあいまいさがあると、その部分がミスの温床になります。
1.3 ステートレス性によるファイル間整合性の欠如
LLMはセッションをまたいだ内部状態を保持しないため、複数ファイルにまたがる仕様や過去のやり取りとの整合性を自動的に管理できません。
2. ユーザー側の誤解と期待ギャップ
- 「AIなら絶対ミスしない」…LLMは推論ベースであり、ルールベースエンジンではありません。
- 「曖昧な設計でも察してほしい」…行間を読む文化はAIには通用せず、曖昧仕様はミスの確率を跳ね上げます。
3. .clinerules のフォーマット
Clineでは、.clinerules によって生成コードの検証ルールを指定できます。
3.2 .clinerules例
シンプルなガイドラインやMarkdown箇条書きで十分な場合は、プレーンテキストで以下のように記述できます。
# コード生成ルール
- コード生成時は必ず `try-catch` を含めること
- 入力パラメータには `null` チェックまたはデフォルト値を設定すること
- `switch` 文では必ず `default` ケースを実装すること
- 重要な処理前後にはログ出力（`console.log` など）を追加すること
- API レスポンスは必ず `{ status: number; data: any; }` 形式に揃えること
これらを単一ファイル（.clinerules）またはフォルダ（.clinerules/）内に配置すると、自動的に結合してシステムプロンプトに追加されます。
4. .clinerulesがLLMと相性が良い理由
- 形式仕様を明示 → AI出力を厳密にチェック
- 自動フィードバックループ → 人手レビュー前にミスを検出
- CI連携 → プロンプト直後／PR時／マージ前など、任意フェーズで検証可能
5. .clinerules導入の実践ポイント
5.1 ファイル配置
- リポジトリ直下：
/.clinerules.jsonまたは/.clinerules - プロジェクト別：
config/.clinerules.jsonまたはconfig/.clinerules/
→ CIから参照しやすいパスを選択してください。
5.2 運用フェーズとCIジョブ例
name: CI
on: [pull_request]
jobs:
lint-and-validate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Install Cline
run: npm install -g @cline/cli
- name: Generate code with AI
run: |
# AI呼び出しスクリプト
node scripts/generate.js > src/generated.ts
- name: Validate with .clinerules
run: cline validate --rules config/.clinerules.json src/generated.ts
- プロンプト直後 → ローカル開発段階での即時フィードバック
- PR作成時 → GitHub ActionsやGitLab CIで自動検証
- マージ前 → QA環境構築時に最終チェック
5.3 ルール設計のコツ
- 単一責務：1ルール＝1チェック項目
- 読みやすい正規表現：過度な複雑化は避ける
- プロジェクト固有ルール：API仕様、トランザクション管理、セキュリティ要件など
5.4 自動修正と指摘
-
指摘モード：
cline validateで違反箇所を出力 -
自動修正モード：
cline fixで簡易修正
→ CIジョブで使い分けましょう。
6. AIへのプロンプト例
システムメッセージ例：
You are a code generator. Use the design spec and .clinerules to generate TypeScript code.
After generation, automatically apply 'cline fix' to satisfy all rules.
Return only the final code.
あなたはコードジェネレータです。デザインスペックと.clinerules.jsonを使用してTypeScriptコードを生成します。
生成後、すべてのルールを満たすように「cline fix」を自動的に適用します。
最終的なコードのみを返します。
ユーザーメッセージ例：
設計書: ・ユーザー登録API
入力: { name: string; email: string | null; }
出力: { id: number; createdAt: string; }
ルールファイル: 以下の .clinerules を参照してください。
7. まとめ
- AIのケアレスミスは仕様伝達と検証プロセスの欠如が原因
.clinerulesで形式的ルールを適用し、自動フィードバックループを構築- まずは小規模プロジェクトで
.clinerulesを作成し、AIコード生成→CI検証を試してみてください
これで、AIを「高速だが雑」のまま使うのではなく、「信頼できる共同開発者」 として活用できる土台が整います。ぜひお試しください。
8. 上手な運用方法（人間のあとがき）
とは言ってもいきなり完璧な.clinerulesを記載するのは難しいですし
AIが苦手なことはルールに何を書いてもミスは発生しやすいです。
AIが間違うことで次の作業のプロンプトやルールの設定を更新する機会だと受け取ればプラスと考えレますし、少しずつ試しながら.clinerulesを育てていくような運用がいいかなと最近感じてます。