こんにちは。認証チームのいまひろです。
これまで認証チームでは、Claude Codeを活用した開発の仕組み化について、複数の記事で紹介してきました。
- Claude CodeでJiraのチケット駆動開発を強固に加速させる！
- Claude Codeの新機能で改善されるJiraのチケット駆動開発 - コマンドの再利用とプラグインによるチーム標準化
- サブエージェントのジレンマを解決する：外部状態ファイルパターンによる独立性とフィードバックの両立
- Jiraのサブタスクを活用した複数Claude Codeセッションの協調作業
- Claude Codeプラグインと知識ベースで実現するチーム標準化と知識の永続化
これらの取り組みを続ける中で、私たちが構築・運用してきたプラグインの本質は何なのかを改めて考えてみました。今回は、その結果として見えてきた「開発プラクティスのコード化（Development Practices as Code）」という概念について紹介したいと思います。
「X as Code」の系譜の中で考える
ソフトウェア開発の世界では、手動で行っていた作業をコードとして定義し、自動化・標準化するという流れが繰り返し起きてきました。
IaC（Infrastructure as Code） は、その最も象徴的な成功例です。かつてはサーバーの構築やネットワーク設定を手動で行い、手順書に頼っていました。IaCはこれをTerraformやCloudFormationといったコードで定義することで、「誰が実行しても同じインフラが構築される」再現性を実現しました。
CI/CD（Pipeline as Code） も同様です。ビルド・テスト・デプロイのプロセスをGitHub ActionsやJenkinsfileといったコードで定義することで、品質ゲートを標準化しました。「誰がマージしても同じパイプラインが動く」── これがCI/CDの本質的な価値だと思います。
こうした「X as Code」の潮流は、現在では Everything as Code（EaC） という包括的な概念に発展しています。2025年の研究では25種類もの「as Code」プラクティスが体系化されており、IaCやCI/CDに加え、Policy as Code（ガバナンスルールのコード化）、Security as Code（セキュリティ制御のコード化）、Docs as Code（ドキュメントのコード化）など、あらゆるものがコード化の対象になっています。
私たちがClaude Codeプラグインで実現しようとしていることも、この「X as Code」の延長線上にあると考えています。
| 概念 | コード化する対象 | 実現されること |
|---|---|---|
| IaC | インフラ構成 | 誰が実行しても同じ環境が構築される |
| CI/CD（Pipeline as Code） | ビルド・テスト・デプロイ | 誰がマージしても同じ品質ゲートが適用される |
| Claude Codeプラグイン | 開発プラクティス | 誰が作業しても同じ開発プロセスが再現される |
IaCがインフラの属人性を排除し、CI/CDがデリバリーの属人性を排除したように、プラグインは開発の進め方そのものの属人性を排除しています。
なお、この「開発プラクティスのコード化」に対応する確立された名称は、現時点ではまだ存在していないように思います。既存の「X as Code」が主にインフラやパイプラインといった技術的な構成物をコード化の対象としているのに対し、プラグインがコード化しているのは人間の判断や振る舞いを含む開発プロセスです。AIエージェントの登場によって初めて実用的になった領域であり、EaCの新たなフロンティアと言えるかもしれません。
「コード化」されているものの正体
では、具体的に何がコード化されているのか。認証チームのプラグインを整理すると、大きく4つの領域があることが分かりました。
1. チーム開発規約のコード化
最初の領域は、チーム内で決めている開発規約です。
「READMEに書いてあるけど守られない」「口頭で伝えている」── どのチームにもこういったルールがあるのではないでしょうか。認証チームでは、これらをプラグインの rule.md に明示的に定義しています。
ブランチ命名規則
feature/{チケット番号}
Jiraのチケット番号をブランチ名に含めることで、チケットとの紐付けを明確にしています。親チケットが存在する場合は親チケット番号を使用するルールにより、複数サブタスクの変更が同一ブランチにまとまるようにもしています。
リポジトリごとのブランチ戦略
| リポジトリ | ベースブランチ | PR先 |
|---|---|---|
| repo_a | develop |
develop |
| repo_b | main |
main |
| その他 | メインブランチ | メインブランチ |
チーム内で「このリポジトリはdevelopにPRを出す」「このリポジトリはmainに出す」といった暗黙の了解がありましたが、プラグインにテーブルとして定義することで、新しいメンバーやClaude Codeが迷わず正しいブランチに向けてPRを作成できるようになりました。
コミットメッセージの形式
{チケット番号}: {変更内容}
PRの作成ルール
- draftで作成する
- 日本語で作成する
- タイトルは
{チケット番号}: {Jiraのタイトル}形式 - 冒頭にJiraのURLを記載
これらは一つ一つは些細なルールですが、積み重なるとチーム全体の統一感に大きく影響します。ドキュメントに書くだけでは「読んだ人は守る、読んでいない人は守らない」というばらつきが生じますが、プラグインに定義すれば、Claude Codeが常にルールに従って動作します。
つまり、「チームの約束事」が、ドキュメントではなく実行可能な命令になるということです。
2. 開発プロセスのコード化
2つ目の領域は、チケットに取り組む際の開発プロセスです。
開発者によっては、チケットを受けたときに自然と以下のような手順を踏むかもしれません。
- チケットの内容を理解する
- 過去に似たような対応がなかったか思い出す
- 関連するコードを調査する
- 実装方針を考える
- テストを書く
- 実装する
- PRを出す
しかし、この「自然と踏んでいる手順」は属人的で、必ずしもチーム全員が同じ手順で動いているわけではありません。
認証チームでは、これらのプロセスをプラグインのコマンドとして定義しています。
plan-ticket：計画のコード化
1. Jira情報の取得
↓
2. 知識ベースの検索（過去の知見を参照）
↓
3. コードベースの調査
↓
4. 実行計画の作成と提示
↓
5. ユーザーのフィードバック待ち
↓
6. 承認後：サブタスクの分割
↓
7. Jiraチケットへのプラン内容の出力
step-subtask：実装のコード化
サブタスク単位の実装も、以下の手順が定義されています。
- サブタスクの選択と着手
- Gherkinテストの参照（必ず最新化してから）
- 実装とPR作成
- 実装完了後のGherkinテスト見直し
- 知識保存の検討
これにより、属人的かつドキュメントのみで定義されていた仕事の進め方が再現可能な開発プロセスになります。
3. 知識管理サイクルのコード化
3つ目の領域は、チームの知識管理です。
開発で得られた知見は、意識的に管理しないと個人の頭の中に留まったまま失われてしまいます。認証チームでは、この知識管理のサイクル全体をプラグインでコード化しています。
検索（タスク開始時）
タスクの内容に特定のキーワード（認証、バッチ、Terraform等）が含まれている場合、作業開始前に自動で知識ベースを検索します。
| キーワード | 検索対象 |
|---|---|
| SAML, 認証, MFA | auth/ |
| バッチ, worker, job | batch/ |
| AWS, Terraform, K8s | infrastructure/ |
活用（作業中）
見つかった知識を参照しながら、コードベースの調査や実装を進めます。
蓄積（作業完了時）
作業中に新たな知見を得た場合、Claude Codeが自動的に保存を提案します。提案にはトリガー条件が設定されており、「調査による新たな発見」「問題解決のノウハウ」「判断基準の整理」などが該当します。
特に、Epic配下の複数チケットに共通するパターンを発見した場合は、即時保存提案が行われるようになっています。
4. リポジトリ固有の文脈のコード化
4つ目の領域は、各リポジトリに固有の文脈知です。
チームで複数のリポジトリを扱っていると、「このリポジトリではこうする」という暗黙のルールが自然と生まれます。
| リポジトリ | ルール |
|---|---|
| repo_a | Serena MCPの利用が必須（コード探索・実装・調査すべて） |
| terraform | コミット前に terraform fmt -recursive . を実行 |
| schema | コミットメッセージはREADME.mdを参考に作成 |
| gherkin | 参照時は必ず git pull origin main で最新化してから |
また、Terraformの設定を行う際に参照すべきプロバイダドキュメントのURLなども定義しています。
これらは「そのリポジトリを長く触ってきた人の頭の中にある知識」です。新しいメンバーが加わった際に「これ、忘れないでね」と口頭で伝えていたような情報が、プラグインに定義されることで確実に適用されます。
プラグインによるコード化がもたらすもの
ここまで4つの領域を紹介しましたが、これらをプラグインとしてコード化することで、以下のような変化が生まれました。
属人性の排除
モブプログラミングを主体とする認証チームでは、ドライバーが交代することが日常的です。プラグインで開発プロセスやルールがコード化されていることで、誰がドライバーを担当しても同じ品質で開発が進むようになりました。
プラグインに定義されたルールは、Claude Codeが自律的に従うべき指示であると同時に、人間にとってはチームの標準手順を確認するリファレンスにもなっています。
継続的な改善のスピード
プラグインはGitHubのプライベートリポジトリで管理されているため、ルールの変更やワークフローの改善はコミット一つで全メンバーに展開されます。
「ルールを変更 → ドキュメントを更新 → 全員に周知 → 各自が設定を変更」という従来のフローが、「プラグインにコミット → 自動反映」に短縮されます。改善のサイクルが速くなるため、チームとしてフットワーク軽く軌道修正を重ねることができます。
ルールの実行可能性
ドキュメントに書かれたルールは「読んだ人が意識して守る」必要がありますが、プラグインに定義されたルールはClaude Codeが自動的に実行します。
例えば、「PRはdraftで作成する」「コミットメッセージはチケット番号から始める」といったルールは、プラグインに書くだけでClaude Codeが毎回確実に守ってくれます。人間の注意力に依存しないため、ルールの遵守率は格段に向上しました。
まとめ
認証チームがClaude Codeプラグインで構築してきたものを改めて俯瞰すると、それはチームの開発プラクティスのコード化でした。
| 領域 | コード化される対象 | これまでの状態 |
|---|---|---|
| 開発規約 | ブランチ戦略、コミット規則、PRルール | READMEや口頭伝達 |
| 開発プロセス | 計画、実装の手順 | 属人的な暗黙知 |
| 知識管理 | 検索→活用→蓄積→整理のサイクル | 意識的に回さないと機能しない |
| リポジトリ文脈 | リポジトリ固有のルールと参照先 | 経験者の頭の中 |
ドキュメントに書かれた規約、熟練者の頭の中にあるワークフロー、チームに蓄積される暗黙知 ── これらをAIエージェントが実行可能な形式としてコード化することで、誰が（人間でもAIでも）作業してもチームの作法を守った開発が再現されます。
IaCがインフラ構成を、CI/CDがデリバリーパイプラインをコード化してきたように、プラグインは開発プラクティスそのものをコード化しています。「Everything as Code」の系譜の中で、AIエージェントの登場によって初めて実用的になった新しい領域 ── 開発プラクティスが「努力目標」から「実行可能なコード」に変わることで、チーム全体の開発品質が底上げされる。それが、プラグインによるコード化の本質的な価値だと感じています。
Claude Codeの進化とともに、コード化できる領域はさらに広がっていくと思います。認証チームとしては、引き続き全体最適の視点から、AIと人間がそれぞれの強みを活かして協調する開発体制の改善を続けていきたいと考えています。
