導入
お疲れ様です。
だいせんせーです。
ソフトウェア開発では、「似たようなコードを何度も書く」場面が頻繁に登場します。
特に Repository パターンを採用しているプロジェクトでは、エンティティごとにほぼ同じ CRUD 操作を実装するケースが多いのではないでしょうか。
たとえば、以下のような関数群です。
- create（作成）
- update（更新）
- save（作成 or 更新 / upsert）
- find（単一レコード検索）
- list（複数レコード検索）
- delete（削除）
これらをエンティティごとに毎回手書きしていると、
実装コストが高いだけでなく、細かなミスや書き方のブレが発生しやすくなります。
従来であれば go generate などを使ってテンプレート化する方法もありましたが、
- テンプレートが複雑になりがち
- 分岐や条件が増えると可読性が下がる
- テンプレート自体の保守が大変
といった課題もありました。
こうした背景の中で注目されているのが、
LLM（大規模言語モデル）と Agent Skills を組み合わせたアプローチです。
Agent Skills とは何か？
この記事で紹介する「Agent Skills」は、
Claude Code における仕組みを例にした概念です。
簡単に言うと、
「特定のマークダウン（SKILL.md）＋補助スクリプト等を1つのモジュールとしてまとめ、LLM が再利用可能な“スキル”として呼び出せるようにしたもの」
という位置づけになります。
スキルは以下のような特徴を持ちます。
- 再利用可能
- プロジェクト固有の設計やルールを内包できる
- 単なるコード生成ではなく「意図を持った変換・生成」ができる
たとえば、
- 「このプロジェクト標準の Repository を生成する」
- 「既存コードをプロジェクトの CRUD 規約に合わせてリファクタリングする」
といった用途を、1つのスキルとして定義できます。
skill creator によるスキル生成
さらに便利なのが、公式で提供されている skill creator というツールです。
これは、
- Git diff
- Pull Request の変更内容
などを入力として、
「この変更内容を一般化して、再利用可能なスキルとして抽出してほしい」
という形で LLM に指示できる仕組みです。
つまり、実際に動いているコード/すでにレビューを通った実装をベースに、安全にテンプレート化できるというのが大きなポイントです。
実践：Agent Skills の導入手順
実際の流れは、以下のようなステップです。
1. スキル用ディレクトリの準備
プロジェクト直下に、以下のような構成を用意します。
.claude/
└─ skills/
└─ skill-creator/この skill-creator が、スキルを生成するためのモジュールになります。
2. Git diff / PR を入力としてスキル化
次に、既存の Repository 実装（例：ProductRepository など）に対するGit diff や PR の変更内容を skill creator に渡します。
プロンプトのイメージは以下のようなものです。
この変更内容を一般化して、
他のエンティティでも使える Repository 生成スキルを作ってください。3. SKILL.md の生成
生成されたスキルには、以下のような SKILL.md が含まれます（具体例）。
name: repository-generator
description: Generate or refactor repository layer code following the project's standard pattern.
Use when creating new entity repositories (Product, Order, etc.) or refactoring existing repository code
to match the standard CRUD pattern with Prisma, neverthrow, and AppContext.
# Repository Generator
## Overview
Generate type-safe repository layer code following this project's standard pattern ...
ここには、
- スキルの名前
- 使うべきタイミング
- 前提となる技術スタック
- 実装方針や制約
といった情報が明示的に書かれます。
4. 別エンティティへの適用
作成したスキルを使って、
- TaskRepository
- OrderRepository
- UserRepository（共通部分のみ）
などを生成・リファクタリングする実例も紹介されています。
この段階では、
「Task エンティティ用の Repository を、このプロジェクト標準で生成して」
といった高レベルな指示で済むようになります。
この手法をプロジェクトに導入するメリット
1. 再現性のあるテンプレート化
CRUD のように構造がほぼ決まっているコードは、
スキルとして切り出すことで再現性の高い生成が可能になります。
「毎回ゼロから考える」状態から脱却できます。
2. 品質・スタイルの統一
- 命名規則
- エラーハンドリング
- トランザクション管理
- テナント（organizationId / teamId）制御
といった細かい部分も、スキル側に集約できます。
結果として、
人による実装差分が減り、レビューコストも下がるという効果が期待できます。
3. LLM によるコード生成の精度向上
単に「LLM にコードを書かせる」だけだと、
- 古い書き方が混ざる
- プロジェクト方針とズレた実装が出る
- 不要な処理が増える
といった問題が起きがちです。
スキルとして文脈と制約を与えることで、修正前提の生成から、ほぼそのまま使える生成に近づきます。
4. 将来的な保守・拡張にも強い
スキルは「育てる資産」です。
- 新しいエンティティが増えたとき
- Repository の設計方針が変わったとき
- マルチテナント仕様が拡張されたとき
にも、スキルを更新すれば全体に波及させられます。
導入時の注意点・考慮事項
一方で、注意すべき点もあります。
独自ロジックの扱い
UserRepository などに特殊な検索条件/業務ロジック依存の関数
が含まれている場合、それをそのままテンプレート化すると
汎用性が下がってしまいます。
「共通部分だけをスキル化する」線引きが重要です。
初期コストは存在する
- SKILL.md の設計
- テンプレート変数の整理
- 適用テスト
など、最初の整備にはそれなりのコストがかかります。
ただし、中長期的には十分回収できる投資と言えます。
何でもテンプレート化しない
すべてをスキル化すれば良いわけではありません。
変更頻度が高い部分/ドメイン固有で揺れやすい部分は、あえて手書きを残す判断も必要です。
まとめ
本記事で紹介したのは、
「コードを毎回書く」から「よく使うパターンをスキルとして再利用する」へのシフト
という考え方です。
特に Repository 層のように、
構造が似ている/数が増えやすい/品質差が出やすい
レイヤーでは、
LLM × Agent Skills の相性は非常に良いと感じます。
テンプレート化の設計や運用ルールをきちんと整えれば、
開発速度・品質・保守性のすべてを底上げできるアプローチです。
