feat(builtins): add API client generation consistency rules

生成クライアント（Orval等）が存在するプロジェクトで手書きAPI呼び出しとの混在を検出するナレッジとポリシーを追加

builtins/ja/knowledge/frontend.md

@@ -156,6 +156,21 @@ const Parent = () => {
 | 複数コンポーネントで共有 | Context or 状態管理ライブラリ |
 | サーバーデータのキャッシュ | TanStack Query等のデータフェッチライブラリ |
 
+## APIクライアント生成
+
+プロジェクトがAPIクライアント生成ツール（Orval、openapi-typescript等）を採用している場合、新規APIエンドポイントとの接続には必ず生成されたクライアントを使用する。
+
+| パターン | 判定 |
+|---------|------|
+| 生成ツールが存在するのに axiosInstance/fetch を直接使用 | REJECT |
+| 生成ツールの設定を確認せずにAPIフックを手書き | REJECT |
+| 生成ツールが存在しないプロジェクトで直接呼び出し | OK |
+
+確認手順:
+1. プロジェクトにAPI生成設定があるか確認（orval.config.ts, openapi-generator 等）
+2. 既存の生成済みクライアントの使用パターンを確認
+3. 新規エンドポイントは生成パイプラインに追加し、生成されたフックを使う
+
 ## データ取得
 
 API呼び出しはルート（View）コンポーネントで行い、子コンポーネントにはpropsで渡す。

builtins/ja/policies/ai-antipattern.md

@@ -63,6 +63,22 @@ AIは同じパターンを、間違いも含めて繰り返すことが多い。
 - ここに属しているように感じるか?
 - プロジェクト規則からの説明のない逸脱はないか?
 
+## インテグレーションパターンの一貫性
+
+同じ種類のAPI接続（REST呼び出し等）がプロジェクト内で異なる方式で実装されていないか確認する。
+
+| パターン | 例 | 判定 |
+|---------|-----|------|
+| 生成クライアントと手書きクライアントの混在 | A画面はOrval生成フック、B画面はaxiosInstance直接 | REJECT |
+| 同じデータ取得パターンの異なる実装 | A画面はuseQuery+axios、B画面は生成フック | REJECT |
+| データ型の定義方式の混在 | A画面は生成された型、B画面は手書きの型 | REJECT |
+
+検証アプローチ:
+1. 変更差分のAPI呼び出し方式を確認
+2. 同じ目的の既存コードがどの方式で書かれているか grep で確認
+3. プロジェクトにAPI生成設定（orval.config.ts等）があるか確認
+4. 不整合がある場合、プロジェクトの標準パターンへの統一を指摘する
+
 ## スコープクリープ検出
 
 AIは過剰に提供する傾向がある。不要な追加をチェック。