> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kodus.io/llms.txt
> Use this file to discover all available pages before exploring further.
# カスタムプロンプト
> 各カテゴリとサジェストの書き方に合わせて Kody のレビュープロンプトをカスタマイズし、チームのニーズに合わせます
カスタムプロンプトにより、Kody がコードを分析し、結果を伝達する方法を完全に制御できます。各レビューカテゴリで AI が何を探すか、チームの基準とコミュニケーションスタイルに合わせてサジェストをどのように提示するかをカスタマイズします。
組織内のすべてのリポジトリのカスタムプロンプトを設定します
## カスタムプロンプトを使用する理由
Kody のレビューをチームのユニークなコーディング標準、アーキテクチャパターン、ベストプラクティスに合わせます
BYOK 使用時に特定の AI モデルの強みに最適化されたプロンプトを作成します
プロジェクトにとって最も重要な問題に Kody の注意を向け、ノイズを減らします
重大な問題には詳細に、軽微な問題には簡潔に — Kody のサジェストの提示方法をカスタマイズします
## カスタムプロンプトの仕組み
カスタムプロンプトは 2 つのレベルで動作します：
### カテゴリプロンプト
各レビューカテゴリで Kody が何を探すかを定義します：
**フォーカス：** コードの正確性と実行上の問題
デフォルトのカバレッジ：
* 実行エラー（未処理の例外）
* 誤った結果（不正な出力）
* リソースリーク（ファイル、接続、メモリ）
* 状態の破損（無効なオブジェクト/データ状態）
* ロジックエラー（不正な制御フロー）
* 競合状態（並行アクセスの問題）
**最大長：** 2000 文字
**フォーカス：** セキュリティの脆弱性とデータ保護
デフォルトのカバレッジ：
* インジェクションの脆弱性（SQL/NoSQL/コマンド/LDAP）
* 認証/認可の欠陥（チェックの欠如、権限昇格）
* データ漏洩（ログ/レスポンス内の機密データ）
* 暗号の問題（弱いアルゴリズム、ハードコードされたキー）
* 入力検証のギャップ（サニタイズ/境界チェックの欠如）
* セッション管理（予測可能なトークン、有効期限の欠如）
**最大長：** 2000 文字
**フォーカス：** 速度、効率、リソース最適化
デフォルトのカバレッジ：
* アルゴリズムの複雑さ（O(n)が可能な場合のO(n²)）
* 冗長な操作（重複する計算、不要なループ）
* メモリの無駄（大きなアロケーション、リーク）
* ブロッキング操作（クリティカルパスでの同期 I/O）
* データベースの非効率性（N+1、インデックス欠如、フルスキャン）
* キャッシュミス（利用可能なキャッシュの活用不足）
**最大長：** 2000 文字
### サジェストプロンプト
Kody が各サジェストを伝達する方法を制御します。これにより、PR コメントに表示されるメッセージの形式とトーンがカスタマイズされます：
```
新しいファイル 'create-or-update-issues-parameter.dto.ts' は
会社の命名規則に従っていません。Kody ルールによると、すべての新しいファイルは
camelCase を使用する必要があります。標準に準拠するために、
ファイルを 'createOrUpdateIssuesParameter.dto.ts' に名前変更してください。
```
カスタムプロンプトは、Kody にサジェストメッセージの書き方を指示します。プロンプトは重大度レベル、問題の説明、提案されたコード、および Kody ルール違反かどうかについてのコンテキストを受け取ります。Kody はこのコンテキストとプロンプトを使用して各サジェストに適切なメッセージを生成します。
チームのニーズに基づいて、重大な問題には詳細な説明を、軽微な問題には簡潔なフィードバックなど、トーン、詳細レベル、コミュニケーションスタイルをカスタマイズできます。
## 外部参照
すべてのカスタムプロンプト（カテゴリ、サジェスト、PR サマリー）は、Kody がアクセスできるコードベースの実際のファイルへの参照をサポートします。更新を保存すると、Kody は自動的に外部参照を検出し、将来のレビューのために解決します。
* 編集中のリポジトリのファイルを指定するには `@file:path/to/file.ts` を使用します。Kody はまずローカルでパスを見つけようとします。
* 別のリポジトリのファイルを参照する場合やグローバルレベルでプロンプトを編集する場合は `@repo:org/project` を含めます。
* モデルが確実に正しいファイルを見つけられるように、プレースホルダーではなく正確な blob スタイルのパスを優先してください。
* 保存後、Kody はバックグラウンドで参照を処理します。解決が完了したことを確認するために、プロンプトエディタ横のステータスインジケーターを確認してください。
## ベストプラクティス
### コンテキストに特化する
```
バグカテゴリプロンプト：
Java サービスのヌルポインタ例外、
DAO 層のデータベース接続の未クローズ、
非同期イベントハンドラーの競合状態に焦点を当てます。
try-finally ブロックでの適切なリソースクリーンアップを確認します。
```
```
バグカテゴリプロンプト：
コードのバグを探します。
問題と障害を確認します。
```
### プロンプト間の冗長性を避ける
各カテゴリは明確なフォーカスを持つべきです。異なるプロンプト間で同じ指示を繰り返さないでください。
**バグカテゴリ：**
Java サービスの実行の正確性、ヌルポインタ例外、リソースのクリーンアップに焦点を当てます。
**セキュリティカテゴリ：**
API エンドポイントの SQL インジェクション、XSS、CSRF に焦点を当てます。入力のサニタイズとパラメータ化クエリを検証します。
**パフォーマンスカテゴリ：**
データ処理での N+1 クエリ、データベースインデックスの欠如、非効率なループに焦点を当てます。
**結果：** 各プロンプトは明確で重複しないフォーカスを持っています。
**バグカテゴリ：**
ヌルポインタ、SQL インジェクション、遅いクエリを確認します。
**セキュリティカテゴリ：**
SQL インジェクション、ヌルポインタ、パフォーマンス問題を探します。
**パフォーマンスカテゴリ：**
遅いクエリ、ヌルポインタ、セキュリティの脆弱性を見つけます。
**問題：** すべてのプロンプトが重複しており、モデルを混乱させてレビュー品質を低下させます。
### 例の使用に注意する
```
データベースクエリの SQL インジェクションを検出します：
- SQL 文でのraw文字列の連結
- クエリ文字列内のユーザー入力
- パラメータ化クエリまたは ORM の欠如
- サニタイズなしの動的クエリ構築
```
これはパターンを広く説明し、複数のバリエーションを捕捉します。
```
このような SQL インジェクションを検出します：
query = "SELECT * FROM users WHERE id = " + userId
```
モデルはこの正確なパターンのみをフラグし、以下を見逃す可能性があります：
* テンプレートリテラル：`SELECT * FROM users WHERE id = ${userId}`
* 文字列フォーマット：`f"SELECT * FROM users WHERE id = {userId}"`
* その他の SQL インジェクションベクター
### サジェストをスキャンしやすくする
サジェストプロンプトでは、開発者が一度に多くをレビューするため、メッセージをスキャンしやすくします：
```
明確な構造でサジェストを書きます。クリティカルな問題には
🚨 絵文字で始め、問題を述べ、「修正：」に続いてコードを示します。
他の重大度には、シンプルに保ちます —
問題と提案されたコードだけです。
開発者が何をすべきかすぐに理解できるよう、
重要な情報を最初に置きます。
```
明確な階層、重要な情報を最初に
```
問題とその重要性を説明します。本番環境で問題を引き起こす可能性があるため、
開発者は問題を解決する提案されたコード変更を適用することで修正する必要があります。
```
スキャンしにくく、アクションが埋もれている
### コンテキストを有意義に使用する
本当の理由がある場合にのみサジェスト形式を差別化します：
```
Kody ルール違反には厳格なトーンを使用します：
「**チーム標準**：[問題]。必須：[コード]」
標準のサジェストにはより親しみやすいトーンを使用します：
「[問題]。提案：[コード]」
言語の違いにより要件レベルが明確になります。
```
明確な区別：ルールは要件、サジェストは推奨
```
Kody ルールには、問題の前に "[RULE]" プレフィックスを追加します。
サジェストには、問題の前に "[SUGGESTION]" プレフィックスを追加します。
それ以外は同じようにフォーマットします。
```
ラベルを追加するだけでは価値がない
## ユースケース
**シナリオ：** HIPAA コンプライアンス要件を持つ医療アプリケーション
**カスタムセキュリティプロンプト：**
```
データ処理での HIPAA コンプライアンスに焦点を当てます：
- ログやエラーでの PHI（保護された健康情報）の漏洩
- 保存中および転送中の PHI の暗号化の欠如
- 患者データへの不十分なアクセス制御
- PHI アクセスの監査ログのギャップ
- データ保持違反
- 患者の同意確認の欠如
```
**メリット：** Kody は一般的なセキュリティレビューが見逃す可能性のあるコンプライアンス固有の問題を捕捉します。
**シナリオ：** 特定のパターンを持つ React/Node.js アプリケーション
**カスタムバグプロンプト：**
```
React と Node.js の一般的な落とし穴に焦点を当てます：
- useEffect/useMemo での依存配列の欠如
- 非同期ハンドラーでの未処理のプロミス拒否
- イベントリスナーのクリーンアップによるメモリリーク
- 状態更新での競合状態
- エラーバウンダリの欠如
- Express ミドルウェアでのキャッチされていない例外
```
**メリット：** レビューはスタック固有の落とし穴にレーザーフォーカスされます。
**シナリオ：** コスト最適化のために BYOK 経由で Gemini 2.5 Flash を使用
**カスタムパフォーマンスプロンプト：**
```
アルゴリズムの効率とリソース使用量を分析します。
以下の形式で特定の問題をリストします：
1. 問題のタイプと場所
2. 現在の複雑さ
3. 最適化の提案
4. 期待される改善
優先順位：データベースクエリ、ループ、メモリアロケーション。
```
**メリット：** Gemini が非常に得意とする構造化された出力形式で、レビュー品質が向上します。
**シナリオ：** クリティカルな問題には詳細な説明を、軽微な問題には簡潔なフィードバックを望む
**カスタムサジェストプロンプト：**
```
サジェストを書く際は、重大度に基づいて詳細レベルを調整します：
クリティカルな問題には："🚨 クリティカル：" に続いて問題を記述します。
"これは即座の対応が必要です。" という行を追加します。
次に "修正：" プレフィックスで修正を提供します。
高い重大度には："⚠️" 絵文字を使い、問題を述べ、
"修正：" プレフィックスで修正を示します。
中程度と低い重大度には：簡潔に保ちます —
問題を述べ、余分な説明なしに提案されたコードを直接示します。
```
**メリット：** クリティカルな問題は追加のコンテキストを得て、軽微な問題は簡潔に保たれ、レビュー効率が向上します。
**シナリオ：** チームは最小限のアクション可能なフィードバックを好む
**カスタムサジェストプロンプト：**
```
直接的で簡潔にしてください。1 文で問題を述べ、
すぐに "修正：" プレフィックスで修正を示します。
追加のコンテキストや説明はありません。
```
**メリット：** すべてのサジェストが短く、要点を押さえています。
**シナリオ：** ジュニア開発者は詳細な説明から恩恵を受ける
**カスタムサジェストプロンプト：**
```
サジェストを 3 つの部分で構成します：
1. **問題：** 問題を明確に述べる
2. **なぜ重要か：** 重大度に基づいて影響を説明する：
- クリティカル：本番障害またはセキュリティの脆弱性を引き起こす可能性がある
- 高：バグやパフォーマンス問題につながる可能性がある
- 中/低：コード品質と保守性を向上させる
3. **修正：** 推奨されるコード変更を示す
説明を教育的にし、なぜ重要なのかを開発者が学べるよう助けます。
```
**メリット：** すべてのサジェストに重要性についての教育的なコンテキストが含まれます。
**シナリオ：** Kody ルールは厳格な要件、サジェストは推奨
**カスタムサジェストプロンプト：**
```
タイプに基づいて異なるトーンを使用します：
Kody ルール違反には：
- 太字で "**チーム標準違反**" で始める
- 問題を述べる
- "これは文書化されたチーム標準に違反しています。" を追加する
- コードに続いて "必須修正：" を示す
標準のサジェストには：
- 問題を直接述べる
- コードに続いて "提案される改善：" を示す
- 親しみやすく推奨的なトーンを使用する
```
**メリット：** 必須ルールとオプションのサジェストを明確に区別します。
## トラブルシューティング
**症状：** カスタマイズ後に低価値のサジェストが多すぎる
**解決策：**
* プロンプトをより具体的でフォーカスしたものにする
* 無視したいパターンに対して除外を追加する
* [サジェスト制御](/how_to_use/ja/code_review/configs/suggestion_control)で最小重大度しきい値を上げる
* カテゴリプロンプト間の冗長性を確認する
**症状：** Kody が検出すべき問題を検出しない
**解決策：**
* プロンプトが狭すぎたり例に特化しすぎていないか確認する
* カスタマイズしなかったカテゴリに問題が該当するか確認する
* デフォルトにリセットして問題が検出されるか試す
* 問題が異なる重大度で分類されている可能性を検討する
**症状：** 同じタイプの問題が時々フラグされ、時々されない
**解決策：**
* プロンプトが明確で曖昧でないことを確認する
* 異なるプロンプト間の矛盾する指示を取り除く
* 特定しすぎた例を使用していないか確認する
* プライマリ/フォールバックの異なるモデルが異なる能力を持つかどうかを検討する
**症状：** カスタムプロンプトを使用したいが、どこから始めればよいかわからない
**解決策：**
* まず 1 週間デフォルトのレビューを実行する
* 誤検知または見逃した問題のパターンに注目する
* それらのパターンに関連する特定のプロンプトのみをカスタマイズする
* 明確なニーズが見えるまで他のプロンプトはデフォルトのままにする
## よくある質問
設定した場所によって異なります：
* **グローバル設定：** 組織内のすべてのリポジトリに適用されます
* **リポジトリごとの設定：** そのリポジトリのグローバル設定をオーバーライドします
これにより、必要に応じてリポジトリ固有のオーバーライドを使用しながら、組織全体の標準を持つことができます。
はい。設定の任意のプロンプトをクリックしてデフォルトのコンテンツを表示します。
変更は新しいレビューにのみ影響します。`@kody start-review` で再実行して新しいプロンプトを既存の PR に適用します。
いいえ。カスタムプロンプトは意図的な変更を確保するために Web のみです。他の設定（無視パス、ブランチ）は `kodus-config.yml` を使用できます。
明確で具体的なニーズがあるプロンプトのみカスタマイズしてください。改善の恩恵を受けるために他はデフォルトのままにしてください。1〜2 個のプロンプトから始めてください。
シームレスに機能します。モデルの強みに合わせてプロンプトを調整してください。プライマリとフォールバックの両方が同じカスタムプロンプトを使用します。
**カテゴリプロンプト**は各レビューカテゴリで Kody が何を分析するかを制御します。**サジェストプロンプト**は Kody がチームに結果をどのように提示するかを制御します。両方を独立してカスタマイズできます。
はい。サジェストプロンプトは太字、斜体、コードブロック、リンクを含む標準的なマークダウン形式をサポートします。
Kody はデフォルトのサジェスト形式にフォールバックし、設定でエラーを通知します。
はい。`isKodyRule` 変数を使用して、同じプロンプト内でルールとサジェストに対して異なるメッセージを作成します。