OpenAIのスキル定義で開発品質を自動化する理由。Claude Code実践者が語るコード規約の強制術

AIエージェントの拡張機能が9000個を超えた。

外部ツールを無数に繋いでも、開発スピードは一定の範囲内に留まる。

AI開発の主戦場は「何ができるか」から「どうやらせるか」に移行した。

チームの暗黙知をAIに強制するスキル定義の時代だ。

これはAST解析を用いてAIの行動を縛る、ガバナンスの手法だ。

AIの機能拡張からプロセス定義へのパラダイムシフト

AIの能力を外部システムへと広げる動きが加速している。

公式の拡張機能は123個に達し、コミュニティ主導のものを含めると9000以上の機能が公開されている。

SlackやNotion、Jiraをはじめとする500以上のSaaSとAIを連携させることは、一般的な技術となった。

OWASP Top 10の基準に基づくセキュリティスキャンや、複数エージェントによる並列コードレビューもコマンド一発で実行できる。

機能開発を7つのフェーズに分割し、要件定義からプルリクエスト作成までを段階的に進めるワークフローも存在する。

コミットメッセージの自動生成からレビュー対応まで、一連の作業をAIが代行する仕組みも整った。

機能面での進化は飽和状態にある。

外部データへのアクセス権をAIに与えるだけでは、開発チームに競争優位性は生まれない。

最前線の開発現場では、AIに対して「チーム固有のルール」を教え込む動きがある。

外部ツールと接続するためのプラグインと、作業の手順を規定するスキル。この2つの概念が分離されている。

プラグインは、AIに新しい手足を与えるものだ。

Google Driveのファイルを読み込んだり、メールの受信トレイをスキャンしたりする機能拡張を指す。

一方、スキルはAIにチームのルールブックを渡す行為だ。

「週次レポートは必ずこのフォーマットで出力しろ」「顧客対応のメッセージはこのトーンで統一しろ」という、チーム固有のプロセスを規定する。

同じタスクであっても、10の会社があれば10通りのアプローチが存在する。

営業チームには、アカウントデータを引き出し、利用状況をチェックし、レビュー資料を準備するという手順がある。

毎回AIに対して、その手順を説明するのは効率が悪い。

スキルを定義すれば、AIはチームのプロセスをなぞるようになる。

外部ツールの情報を使って、チームの標準プロセス通りに処理を完結させる。

このプラグインとスキルの掛け合わせが、AIエージェント開発のスタンダードになる。

※この記事は、Claude Codeで1人SaaS開発しているしんたろーが、海外AI最新情報を開発者目線で解説する「AI活用Tips」です。

プラグインとスキルを分かつ「組織知の自動化」

プラグインによる機能拡張は容易だ。

しかし、スキルを定義し、AIにルールを守らせるのは難易度が高い。

実際の開発現場では、AIに対する指示書がすべての動作の前提となる。

Claude Codeにおける「CLAUDE.md」のような、プロジェクトのルートに配置されるシステムプロンプトファイルだ。

この指示書の品質が、AIの出力品質とプロジェクトの進行速度を100%決定づける。

「どのくらい精度の高い指示が書けているか」を、客観的な数値として評価する仕組みが求められている。

しんたろー：
Claude Codeでコードを書いていると、指示書の質の差がプロジェクトに直結すると感じる。
「よしなにやって」で動くのは最初の3日だけで、プロジェクトが育つと曖昧な指示はバグとして返ってくる。

これまで、指示書の品質評価は単純なキーワードチェックに過ぎなかった。

「テスト」という単語が含まれているかを確認する程度の処理だ。

それでは、AIに対する指示の「質」や「意図」は測れない。

キーワードの有無ではなく、指示の構造そのものと、テキストの密度を解析するアプローチが必要になる。

ここで重要になるのがAST（抽象構文木）解析を用いた品質評価だ。

Markdown形式の指示書を単なるテキスト文字列としてではなく、プログラムが理解できる構造データとして評価する。

例えば、Markdownのヘッダー階層構造をプログラムでチェックする。

H1の直下にH4が来るような不適切なネストが存在すれば、指示の構造が破綻していると見なして評価を下げる。

ASTトークンの深さを計算し、その変化量が大きければ減点していくロジックだ。

AIは構造化されたドキュメントを好むため、人間が読みにくい階層構造は、AIにとってもノイズになる。

さらに、指示の「具体性」をテキスト密度で定量的に分析する。

「適切に」「きれいに」「ちゃんと」といった、解釈のブレを生む曖昧な言葉を排除する。

曖昧な言葉の出現回数と、具体的なコマンドの密度を計算してスコア化する。

これはAIの振る舞いをコードで制御するメタプログラミングの領域だ。

しんたろー：
プロジェクトで「適切にエラーハンドリングして」という指示を控えるようになった。
AIに「適切」の判断を委ねると、毎回違うライブラリを勝手に持ってくることがある。

現在、指示書の品質を測るためのSPECIAという6つの評価軸が提唱されている。

このフレームワークが、AIガバナンスにおける基準になる。

* Structure（構造）: AST解析によるMarkdownの階層品質。

* Precision（具体性）: テキスト密度と曖昧語の排除。

* Efficiency（効率）: トークン推定による冗長性の排除。

* Coverage（網羅性）: プロジェクトに必要なカテゴリの網羅性。

* Integrity（整合性）: 矛盾する指示やアンチパターンの検出。

* Adherence（準拠度）: AIモデルの公式ベストプラクティスへの準拠。

この6次元の指標で指示書を評価し、チームのルールをAIのスキルとして定着させる。

これが「組織知の自動化」の姿だ。

AIエンジニアリングが実務の必須要件になる

このパラダイムシフトは、開発スタイルに影響を与える。

便利なAIツールを導入するだけのフェーズは終わった。

これからの開発者には、チーム内に眠る暗黙知をAIが理解できる形式へと変換するスキルが求められる。

AIエンジニアリングという職能が必須になる。

外部SaaSとの複雑な連携は、MCP（Model Context Protocol）を使えば一元的に管理できる。

プロジェクトのルートディレクトリに設定ファイルを置くだけで、API連携の準備は完了する。

重要なのは、そのパイプの中に「どんなルール」を流し込むかだ。

既存の静的解析ツールでは拾いきれないチーム固有のコーディング規約を、自然言語で定義する必要がある。

プロジェクトの既存コードから規約を学習させ、AI向けのルールを生成するアプローチも有効だ。

会話の文脈をベクトル検索可能な形式で永続化し、過去の設計判断の経緯をAIに記憶させる仕組みも求められる。

しんたろー：
MCPサーバーの設定ファイルをリポジトリにコミットすれば、チーム全員が同じ環境でAIを動かせる。
環境構築の手間が省けるため、導入を検討している。

デザインファイルからフロントエンドのコンポーネントを生成するワークフローも一般的になる。

その際、単にコードを出力させるだけでなく、チーム独自のデザインシステムに準拠させることが「スキル」の役割だ。

曖昧な指示を許容しない、強固な仕組みを作ることが求められる。

指示書をCI/CDパイプラインで自動的にAST解析し、スコアが基準値に満たない場合はAIの実行をブロックするようなガバナンスが必要になる。

「特定のキーワードが含まれているか」ではなく「情報がどう構造化されているか」をコードレビューの基準にする。

AIに対する指示書そのものが、ソースコードと同等以上のレビュー対象になる。

チーム内で「AIが期待通りに動かない」という不満が出た場合、それはツールの性能不足ではない。

チームのスキル定義が甘く、ルールが言語化されていない証拠だ。

属人化していた暗黙のルールを言語化し、構造化されたMarkdownファイルに落とし込む。

この作業が、AI時代の開発速度と品質を引き上げる解決策だ。

よくある質問（FAQ）

Q1: プラグインとスキルの使い分けの基準は？

プラグインは「外部データやツールへのアクセス」が必要な場合に使用する。Google Driveのファイル取得やSlackへの通知など、AIの手足を拡張する機能だ。一方、スキルは「チーム固有の作業手順やルール」をAIに強制したい場合に使用する。週次レポートのフォーマット指定や、特定のレビューフローの徹底だ。両者を組み合わせることで、外部から取得したデータをチームの標準プロセスに沿って処理する自動化パイプラインが実現できる。

Q2: CLAUDE.mdの品質を上げるにはどうすればいい？

単にキーワードを羅列するのではなく、Markdownの構造（AST）を意識した論理的な記述が重要だ。ヘッダーの階層構造を保ち、H2からH4へ飛ぶような不自然なネストを避ける。「適切に」「きれいに」といった曖昧な表現を排除し、具体的なコマンドや期待される出力形式を定義する。SPECIAフレームワーク（構造、具体性、効率、網羅性、整合性、準拠度）を指標に記述を見直すことで、AIが迷わずタスクを遂行できる指示書になる。

Q3: MCPサーバーを導入するメリットは？

MCP（Model Context Protocol）を導入すると、AIと外部SaaS間の接続プロトコルが標準化される。個別の拡張機能をバラバラに設定する手間が省け、プロジェクトルートの設定ファイルで一元管理できる。これにより、チーム開発において環境の再現性と保守性が向上する。複雑なSaaS連携を伴う開発や、複数人で同じAIコンテキストを共有する場合には、有効なアーキテクチャだ。

まとめ

AIに「何ができるか」という機能の数を追いかけるのは終了した。

チームの暗黙知を構造化し、AIにルールを強制するプロセス定義こそが、次の開発の勝敗を分ける。

👉 ThreadPostでSNS運用を自動化する