# AIエージェントに「社内の型」を教える｜新規プロジェクトの環境構築をスキル化して自動化した話｜株式会社テクノスフィア

> リポジトリ作成・課題管理・Wiki整備という新規プロジェクト立ち上げの定型作業を、Claude CodeのAgent Skillsで自動化した実践記録。スキルの作り方、公式ツールによる定量評価（スキルあり100% vs なし70.8%）、社内ナレッジをAIに教える際の設計ポイントを解説します。

URL: https://technosphere.co.jp/blog/ai-agent-project-setup-skill

** 目次
1. はじめに：プロジェクト立ち上げという「儀式」
2. Agent Skills（スキル）とは
3. 何をスキルにしたか：環境構築の3点セット
4. 効果を数字で確かめる：スキルあり vs なし
5. 社内ナレッジをAIに教えるときの設計ポイント
6. よくある質問（FAQ）
7. まとめ
   ** 本記事について

本記事は、当社が社内で実際に運用しているAIエージェント（Claude Code）の取り組みの記録です。記事中の会社名・プロジェクト名の例はすべて**架空のもの**に置き換えています。仕組みの考え方はツールを問わず応用できます。

## はじめに：プロジェクト立ち上げという「儀式」

 受託開発の会社では、新しい案件が決まるたびに同じ準備作業が発生します。ソースコードを置く**リポジトリの作成**、進捗を管理する**課題管理システムのプロジェクト登録**、情報を集約する**社内Wikiのページ作成**。1つ1つは難しくありませんが、命名規則・階層構造・書くべき項目といった「社内の型」が関わるため、意外と手間がかかります。

 そして、この手の作業は**毎回微妙にブレます**。リポジトリ名の付け方が人によって違う、課題管理には登録したがWikiは後回しのまま、概要欄が空っぽ——。立ち上げ時のわずかなブレが、数ヶ月後の「あの資料どこ？」につながります。

 当社ではAIエージェント（Claude Code）を開発業務に組み込んでいますが、今回この立ち上げ作業一式を「**スキル**」としてAIに教え込みました。結果、**「〇〇社の新しい案件、△△を作ることになった。環境を整備して」というひと言**で、3点セットが社内の型どおりに揃うようになりました。

## Agent Skills（スキル）とは  （図: 社内ルールをまとめた本が光の粒になってAIロボットに流れ込むイメージイラスト）

 スキルとは、AIエージェントに特定の作業の**手順書・テンプレート・参照資料をパッケージとして渡す仕組み**です。Claude Codeでは「Agent Skills」という公式機能として提供されており、Markdownで書いた手順書（SKILL.md）と付属資料をフォルダに置くだけで使えます。

 ポイントは、スキルには**発動条件となる説明文**を書いておけることです。「新しい案件を始める」「環境を作って」といった依頼が来たとき、AIは自分でスキル一覧から該当するものを見つけて読み込み、その指示に従って作業します。ユーザーがスキルの存在を意識する必要はありません。

 言い換えると、スキルは**「ベテラン社員の頭の中にある暗黙知を、AIが読める形式知に変換したもの」**です。一度書けば、誰がAIに依頼しても同じ品質・同じ型で作業が行われます。新人でもベテランと同じ運用ができる、というのが実務上いちばん大きな効果でした。

## 何をスキルにしたか：環境構築の3点セット  （図: リポジトリ・課題管理ボード・Wikiの3つの島が光の橋でつながり、ロボットが旗を立てているイメージイラスト）

今回のスキルには、次の4つの知識を詰め込みました。
| 教えた内容 | 例 |
|  **命名規則** |  リポジトリ名は「顧客名＋内容」の英語小文字。例えば架空のアクメ社の「サイネージ動画再生システム」なら `acme-signage-player` |
|  **階層構造** |  課題管理は「顧客の会社」を見出しプロジェクトとして作り、その配下に案件を作る2階層。Wikiも同じく会社ページ→案件ページの階層 |
|  **書くべき中身** |  会社の見出しには「どんな会社か」の概要（Web検索で裏取りした事実のみ）、案件には「何を作るのか」の要約。テンプレートを同梱 |
|  **安全ガード** |  実行前に必ず計画（命名・階層・概要文の案）を提示して承認を得る。後から変更できない識別子があるため |

 大事なのは、これらを頭から書き下ろしたのではなく、**先にAI自身に社内の既存プロジェクトを調査させた**ことです。既存の命名の実例、見出しプロジェクトの書きぶり、Wikiの階層——「いま社内で実際に使われている型」を集めてからスキルに固めたので、出来上がった瞬間から過去の資産と綺麗に並びます。

 もう1つ、地味に効くのが**実在の設定値を焼き込む**ことです。「グループを追加する」ではなく「グループID 10を開発者ロールで追加する」と書いておく。AIが毎回調べ直す必要がなくなり、実行が速く確実になります。

## 効果を数字で確かめる：スキルあり vs なし  （図: 下書き・比較・計測・改善の4ステップを循環する評価ループのイメージイラスト）

 スキルは書いて終わりではなく、**効果を測って改善するループ**を回しました。Claude Codeにはスキル開発用の公式スキル「skill-creator」があり、テスト用の依頼文を「スキルあり」「スキルなし」の2つのAIに与えて出力を比較・採点する仕組みが同梱されています。

 今回は「新規顧客の案件」「既存顧客への案件追加」という2つのテストシナリオを用意し、命名規則・階層構造・既存ページを壊さない判断など**10項目の採点基準**で機械的に採点しました。結果は次のとおりです。
| 構成 | 合格率 | 主な失点 |
|  **スキルあり** |  **100%（10/10）** |  — |
|  スキルなし |  70.8% |  リポジトリ名の揺れ、メンバー登録の慣例漏れ、概要欄の記載漏れ、既存Wikiページの扱いに未言及 |

 興味深いのは「スキルなし」でも70.8%取れている点です。AIは社内の他のドキュメントからかなりの型を推測できます。しかし**残りの約3割——命名の一貫性や暗黙の慣例——こそが、数ヶ月後に効いてくる部分**です。この差分を数字で確認できたことで、スキル化の価値に確信を持って運用に載せられました。

 なお評価はすべて「計画の提示まで」で行い、テスト中に本物のリポジトリやプロジェクトは一切作られない設計にしています。本番システムに触れる作業のテストでは、この安全設計が必須です。

## 社内ナレッジをAIに教えるときの設計ポイント

今回の取り組みで得られた、スキル設計の勘所をまとめます。
- **先に実態を調査する**——ルールを頭で書くのではなく、既存の実例をAIに集めさせてから型に固める。理想論ではなく「いま動いている慣例」を写し取る
- **取り返しのつかない操作にはガードを置く**——変更不可の識別子や外部サービスへの書き込みは、計画提示→承認→実行の2段階にする
- **「なぜ」を書く**——「グループを追加する（しないと他のメンバーから見えないため）」のように理由を添えると、AIは例外的な状況でも意図に沿って判断できる
- **効果は測る**——スキルあり/なしの比較採点で、思い込みではなく数字で価値を確認する。採点基準そのものも資産としてスキルに同梱しておく
- **過去の失敗をチェックリストにする**——一度踏んだミスをスキルの注意事項に書き足していくと、組織として同じ失敗を二度としなくなる

## よくある質問（FAQ）   Q. Agent Skills（スキル）とは何ですか？ A. AIエージェントに、特定の作業の手順書・テンプレート・参照資料をパッケージとして渡す公式の仕組みです。依頼内容に応じてAIが自動的に該当スキルを読み込み、社内の規約どおりに作業します。 Q. スキルの効果はどうやって測ったのですか？ A. 同じ依頼文を「スキルあり」「スキルなし」のAIに与えて出力を比較し、10項目の採点基準で採点しました。結果はスキルあり100%、なし70.8%でした。 Q. AIが勝手にリポジトリやプロジェクトを作ってしまう心配は？ A. スキル側に「実行前に必ず計画を提示して承認を得る」ガードを組み込んでいます。後から変更できない識別子を含む操作は、承認なしでは実行されません。

## まとめ

 新規プロジェクトの環境構築という「小さいが毎回発生し、ブレると後で効いてくる」作業を、AIエージェントのスキルとして型に固めました。ひと言の依頼で3点セットが揃い、効果は比較採点で**+29ポイント**と数字でも確認できました。

 スキル化の本質は自動化そのものより、**散らばっていた社内の暗黙知が、レビュー可能・改善可能な文書になる**ことだと感じています。属人化した手順書きから始めて、評価ループで磨く——このパターンは環境構築に限らず、見積作成やデプロイ手順など幅広い定型業務に応用できます。

 当社では、こうしたAIエージェントの業務組み込み・社内ナレッジのスキル化を自社で日常的に実践し、そこで得た知見をお客様のシステム開発・業務自動化にも展開しています。「うちの定型業務もAIに任せられないか？」という段階のご相談も歓迎です。