§ Village GazetteAI駆動開発

Claude Codeを「ひとり開発会社」にする｜自作スキルで部署を作った話

個人開発者は企画もQAもマーケも1人で兼任する。ならばClaude Codeのスキル機能で「部署」を作ればいい — 汎用スキル11本+プロジェクト専用スキルで組んだ「ひとり開発会社」の組織図と、運用して見えた設計原則(名前衝突・実数の単一ソース・最小権限)を公開します。

公開: 2026/8/11書いた人: ゆーき

#Claude Code#AI駆動開発#個人開発#スキル

個人開発者には部署がありません。企画も実装もQAもリリースもマーケも、全部自分です。

でもClaude Codeにはスキルという仕組みがあります。手順書(SKILL.md)を置いておくと/コマンドで呼び出せる機能 — これを使って、僕は自分の開発環境を「ひとり開発会社」にしました。汎用スキル11本+プロジェクト専用スキル群という構成で、数ヶ月運用しています。

この記事では、その組織図と、運用して見えてきた設計原則(名前衝突・実数の単一ソース・最小権限)を公開します。

この記事で分かること

Claude Codeのスキルを「部署」に見立てた実際の構成(11本の役割分担)
汎用スキルとプロジェクト専用スキルの2層構造と、名前衝突の罠
数値をハードコードしない「実数の単一ソース」パターン
何からスキル化を始めるべきか

結論: スキルは「優秀な部下」ではなく「業務マニュアル」

先に、運用して掴んだ本質を書きます。

スキルの正体は「特定の場面の業務マニュアル」です。AIが賢くなるのではなく、毎回同じ品質の手順で仕事をさせられるようになる
価値が出るのは繰り返し発生する定型業務(リリース・バグ調査・記事作成)。1回きりの作業をスキル化しても元は取れない
そして会社と同じで、部署が増えるほど規約(命名・権限・データの持ち方)が効いてくる。後半で紹介する設計原則が、実は一番の資産です

組織図: 汎用スキル11本の役割分担

~/.claude/skills/(ユーザーレベル=どのプロジェクトでも使える場所)に置いている「本社の部署」です。

部署	スキル	仕事
総務(環境構築)	`/setup-project`	プロジェクトを1コマンドで「会社」化。CLAUDE.md自動生成・ファクトファイル・hooks・CI雛形を一括導入
企画	`/spec`	要件をヒアリングして仕様書を作成
実装	`/scaffold`	既存アーキテクチャに合わせた機能の雛形を生成
QA	`/diagnose` `/gen-tests`	バグの原因を体系的に特定/既存テストのスタイルを模倣してテスト生成
品質・国際化	`/ui-audit` `/i18n` `/compat-check`	UIレビュー/多言語キーの同期/DB・API変更が配信中バージョンに与える影響判定
リリース	`/release`	バージョン更新・差分収集・リリースノート・記録更新を一括実行
広報	`/promo` `/sns`	ASO/SEO施策の提案/SNS投稿文の作成
人事	`/create-skill`	スキルを作るスキル。定型作業の発掘と、既存スキルの陳腐化点検

ポイントは人事部(/create-skill)の存在です。「この作業、3回目だからスキル化しよう」という判断や、「このスキル、実装が変わって古びてないか」の点検までスキル化しておくと、会社が自己増殖・自己修復するようになります。

2層構造: 本社(汎用)と現場(プロジェクト専用)

スキルの置き場所は2つあります。

ユーザーレベル ~/.claude/skills/ — どのプロジェクトでも使う汎用手順(上の11本)
プロジェクトレベル .claude/skills/ — そのプロジェクト固有の知識が要る手順

たとえばこのサイト(AppVillage)には記事作成の専用スキル/new-articleがあり、Morphica(AI写真変換アプリ)には/debug・/release-prep・/db-migration-checkなど11本の専用スキルがいます。汎用の/diagnoseとMorphica専用の/debugは役割が同じですが、専用側はプロジェクト固有のエラー分類表やファイル地図を持っているので、同じ目的なら専用スキルを優先というルールにしています。

罠: 同名スキルはユーザーレベルが勝つ

ここに1つ、実運用で効いてくる仕様があります。同名スキルはユーザーレベルが優先され、プロジェクト側を黙って隠します。うっかり汎用側にdebugという名前でスキルを作ると、Morphicaの専用/debugが呼べなくなる。

対策として、うちでは予約名レジストリを運用しています。各プロジェクトの専用スキル名と、Claude Code本体・プラグインが使う名前を一覧にして、「汎用スキルにこの名前を付けるの禁止」と明文化したものです。/create-skillが新しい専用スキルを作るたびに、このレジストリへ自動で追記します。会社で言う「命名規則の社内標準」ですね。

実数の単一ソース: 数字をスキルに書かない

もう1つ、運用の柱にしているのがファクトファイル(docs/project_facts.md)です。

売上・DL数・URL・キャンペーンID — こうした「実数」をスキルやドキュメントに直書きすると、更新のたびに古い数字がどこかに残ります。そこで:

実数は1ファイルに集約し、全スキルはそこを参照する(暗記も直書きも禁止)
書き込み権限は/releaseだけが持つ。他のスキルは読み取り専用
ファクトファイルが無いプロジェクトでは、スキルは「/setup-projectの実行をおすすめします」と一言添えて、コードの実読で続行する(ブロックはしない)

「読み書きの権限を分ける」のは会社の経理と同じ発想です。数字の更新経路が1本だと、マーケ資料もSNS投稿文も常に最新の実数で作られます。

最小権限: 読むだけのスキルにWriteを渡さない

各スキルには使えるツールをallowed-toolsで宣言させています。UIレビューやバグ調査のような「読んで報告する」スキルに、ファイル書き込みの権限は与えない。

これはAIの暴走対策というより、スキルの役割を設計として固定する効果が大きいです。診断部署が勝手にコードを直しはじめない — 修正はレポートを見た自分が判断して依頼する。会社の職務分掌と同じで、境界がはっきりしているほど1つ1つの仕事の質が安定します。

会社ごとバージョン管理する

~/.claude/ディレクトリ自体をprivateのgitリポジトリにして、スキルや規約を変更したら即コミットしています。

スキルは書いて終わりではなく、運用しながら手順を直し続けるものです。変更履歴がそのまま「会社の改善史」という資産になりますし、マシンを乗り換えてもcloneひとつで会社ごと引っ越せます。

実際の1日: この記事も「会社」の産物

たとえば新しいプロジェクトを始めるときの流れはこうです。

/setup-project   → CLAUDE.md・ファクトファイル・hooks を一括導入(会社設立)
/spec            → 作りたい機能の仕様書化(企画会議)
/scaffold        → 既存構成に合わせた雛形生成(実装開始)
/gen-tests       → テスト生成(QA)
/release         → リリースノート・記録更新(リリース)
/promo /sns      → 告知文の作成(広報)

そして今読んでいるこの記事も、AppVillageの専用スキル/new-article(記事の雛形作成・運用ルールの参照)を起点に書かれています。会社の業務フローの中から、会社紹介の記事が出てくる — ちょっと入れ子構造ですが、定型業務のスキル化が回っている実例です。