私たちは、AIエージェントのスキルをプロンプト集ではなく、チームで運用できる開発資産として扱うべきだと考えています。
コーディングエージェントをチームで使い始めると、よい指示、よいレビュー観点、よい作業手順が少しずつ増えていきます。最初は個人のメモでも十分ですが、案件や職能をまたいで再利用しようとすると、どれが最新版で、誰が直してよくて、何に依存しているのかが分かりにくくなります。
Chabitでは、社内向けの agent-skills リポジトリを作り、AIエージェントのスキルをソース、依存関係、検証、生成物に分けて管理しています。狙いは、便利な言い回しを集めることではありません。AIが同じ型で動ける作業単位を増やし、チームの開発OSとして育てることです。
焦点は、スキルをどう作り、どう共有し、どうチームに定着させるかです。AIが速く動けるほど、人間側には「何を正とし、どの手順で進め、どこで検証するか」を再利用できる形にする仕事が残ります。
スキルは、繰り返し使える作業の入口です
スキルは、AIに渡す文章だけではなく、特定の仕事を終えるための入口です。
たとえば、レビュー、資料作成、リポジトリ診断、図版生成、Issue整理といった仕事には、それぞれ前提、入力、出力、参照資料、使ってよいツール、確認すべきリスクがあります。ここを毎回の会話で説明すると、成果はその場の文脈に依存します。
スキルとして管理する価値は、言い回しを保存することではありません。作業の境界を定義し、必要な参照情報を近くに置き、完了条件を揃えることにあります。
私たちは、スキルを「AIへのお願い」ではなく「AIがたどれる小さな業務プロセス」として扱います。書くべきものは強い命令文ではなく、目的、入力、出力、制約、確認観点、関連する素材です。
最初の1つは、よく頼む作業から作る
スキル化の出発点は、特殊な自動化ではなく、チーム内で何度も頼んでいる作業です。
たとえば「PRのレビュー観点を洗い出す」「週次の変更を要約する」「公開前のOGPとCTAを確認する」「リポジトリのAI利用ルールを点検する」といった作業は、スキル化しやすい対象です。毎回の説明が似ていて、入力と出力がある程度決まっていて、人間が最後に判断する仕事から始めると、チームで使うイメージが湧きやすくなります。
最初に決めるのは、細かなプロンプトの文面ではありません。どの入力を渡すか、何を成果物と呼ぶか、どの正典を読むか、どの条件を満たしたら完了かを決めます。
社内で試すときは、小さく始めます。まず1つの作業をスキルにし、同じチームで数回使い、足りなかった前提やレビュー観点をPRで直します。この繰り返しを通すと、個人の「うまくいった使い方」が、チームで直せる資産になります。
共有は、プロンプトを配るのではなくPRで育てる
チームで共有するなら、プロンプト本文をチャットに貼るより、変更履歴が残る場所で育てるほうが安定します。
Chabitの agent-skills では、利用者が使う完成スキルと、保守するためのソースを分けています。スキルの改善は、通常の開発と同じようにPRで扱います。何を変えたのか、どの作業に効くのか、既存スキルに影響があるのかをレビューできるからです。
共有の単位は、スキル名、用途、入力、出力、完了条件です。利用者は完成スキルを呼び出せばよく、保守する人はソース側で依存関係や共通部品を直します。
この分け方をすると、スキルを使う人は細かい設計を知らなくても始められます。一方で、チームとしては「このレビュー観点は共通部品に寄せよう」「このスキルはまだdraftにしよう」「この古い手順はdeprecatedにしよう」と判断できます。
使う人に見せるものと、育てる構造を分ける
agent-skills では、利用者が見る完成品と、保守するための設計情報を分けています。
利用者が直接使うのは skills/ にある完成スキルです。一方で、スキルを作る側は _src 配下で Application、Intermediate、Primitive というレイヤーを扱います。
Application は、単体で価値を生む完成スキルです。レビュー、週次サマリー、ドキュメント作成のように、利用者がそのまま呼び出せる単位です。
Intermediate は、複数のPrimitiveを組み合わせる中間部品です。たとえば、差分を読む、品質観点を組み立てる、カタログを検査する、といった共通処理を束ねます。
Primitive は、もっとも小さな再利用ブロックです。ほかに依存せず、複数のスキルから使える最小単位の手順を置きます。
この構造があると、利用者は完成スキルだけを見ればよく、保守する側は重複や依存を管理できます。スキルの数が増えても、似た手順をそれぞれの SKILL.md に手で貼り付け続ける必要が減ります。
ビルドパイプラインで、属人化を検出する
スキルを運用資産にするには、レビューだけでなく機械的な検証が必要です。
agent-skills のビルドは、validate、lint、resolve、expand、copy、index、hash という流れで進みます。スキーマに合っているか、タグや名前空間が登録されているか、レイヤールールに反していないか、依存関係が解決できるかを順番に確認します。
validate は、各スキルや部品が必要なメタデータを持っているかを見ます。id、layer、description、version、status、tags といった情報が揃うことで、あとから検索し、影響範囲を追いやすくなります。
lint は、リポジトリの運用ルールを見ます。Primitive がほかに依存していないか、Application が低レイヤーへ直接寄りすぎていないか、タグ辞書や名前空間から外れていないかを確認します。
resolve と expand は、依存関係を解いて完成スキルへ展開します。人間が編集するソースと、AIが実行時に読む完成スキルを分けることで、保守性と使いやすさを両立します。
index と hash は、カタログ化と冪等性の確認です。同じ入力から違うスキルが出る状態では、チームの共通資産として安心して育てられません。
ライフサイクルを持たせると、スキルを壊さずに育てられる
スキルは一度作って終わりではなく、使いながら育てるものです。
agent-skills では、draft、stable、deprecated、removed という状態でライフサイクルを分けます。まだ実験中のもの、本番利用に向くもの、置き換え先を示して退役させるもの、削除するものを同じ棚に混ぜないためです。
バージョンも同じ考え方です。小さな修正、後方互換のある追加、破壊的な変更を分けて扱うことで、ほかのスキルや利用者への影響を判断しやすくします。
この設計は、スキルの品質を一気に完成させるためではありません。むしろ、最初は小さく作り、使いながら直し、依存先を壊さずに成熟させるための設計です。
AIエージェントの利用は、現場で試すほど新しいパターンが見つかります。だからこそ、スキルにもIssueやPRと同じように、所有者、状態、変更履歴、検証の考え方が必要になります。
スキルリポジトリは、プロジェクトのSSoTと接続して効く
スキルリポジトリは、AI駆動開発における再利用可能なSSoTです。
プロジェクト固有の文脈は、それぞれのリポジトリの AGENTS.md やドキュメントに置きます。一方で、レビューの進め方、ドキュメントの作り方、GitHub Issueの整理、リポジトリ診断の観点などは、複数プロジェクトで共通化できます。
ここを個人のプロンプト集にすると、うまくいった手順が人に閉じます。スキルリポジトリにすると、チームで直し、検証し、ほかの案件へ持ち運べます。
ただし、スキルリポジトリだけでAI駆動開発は完成しません。各プロジェクトには、事業目的、ドメイン用語、設計判断、品質ゲート、権限、公開前のリスクがあります。共通スキルは、それらのプロジェクト固有SSoTを読み、正しい作業に変えるための実行単位です。
私たちは、共通化するものと現場に残すものを分けます。共通化するのは、作業の型、レビュー観点、検証手順です。現場に残すのは、事業判断、顧客文脈、公開可否、最終責任です。
Chabitは、プロンプトを資産化するところから開発体制を設計する
AIエージェントをチームに入れるとき、最初に整えるべきものはツールの使い方だけではありません。
どの情報を正とするか。どの作業をAIに任せるか。どのゲートで止めるか。どのスキルを共通化し、どの文脈をプロジェクト側に残すか。ここまで決めると、AI活用は個人の工夫からチームの開発OSへ近づきます。
agent-skills リポジトリは、そのための社内実装です。スキルをプロンプト集で終わらせず、依存関係、検証、ライフサイクルを持つ運用資産として扱います。
Chabitのテクニカルディレクションでは、コーディングエージェントの導入そのものではなく、チームが継続して使える開発体制を設計します。スキル、SSoT、ワークフロー、品質ゲートを一体で整えることで、AIの速さをレビュー可能な成果へ変えていきます。
関連する過去記事
関連サービス
- AI駆動開発ブーストプログラム: コーディングエージェントを個人利用で終わらせず、SSoT、スキル、品質ゲート、実案件パイロットまで含めて開発OSとして定着させます。
- テクニカルディレクション: 技術選定、開発体制、レビュー、CI、AIエージェント活用を一体で設計し、チームで再現できる開発フローへ整えます。
