一人SIerを実現するAI駆動開発フレームワーク — Claude Code × Skills × 自動Gate判定
2026/07/04 更新
auditスキル追加（攻撃的監査）：「設計どおりに動くか」ではなく「攻撃者ならどう壊すか」の視点でコードを検査するスキル。IDOR・並行処理・偽の成功・エラー握り潰し等のチェックリストで領域を分割し、別エージェントによる反対尋問で誤検出を排除します。詳しくは → Fable 5を分析したら、定額のOpusでもかなり再現できた話- レベル2セキュリティCI（無料ツールのみ）：Gitleaks / TruffleHog / Semgrep / Trivy / OSV-Scanner / Socket / OWASP ZAPをCIパイプラインに統合
- オンデマンドSkill 3つ追加：
security-report（セキュリティ証跡）、quality-report（品質レポート）、delivery（納品ドキュメント一式 + Gamma連携）- スタックプロファイル：言語/FW非依存化。Laravel、Node.js等でも利用可能に
- PRテンプレート：AI生成コードの利用チェック付き
はじめに
受託見積もり6,000万円規模のSaaSを、本業の合間に1人で1ヶ月で開発しました。
……という話を別の記事に書いたのですが、「具体的にどうやっているのか」という質問を多くいただきました。
▶ 受託見積もり6,000万円のSaaSを、本業の合間に1ヶ月で作った（note）
この記事では、1人でシステム開発を受託し、品質とセキュリティを担保しながら回すための具体的なフレームワークを公開します。Claude CodeのCLAUDE.md + Skills機能を使って、「要件定義→設計→実装→テスト→レビュー→セキュリティ検査→納品」の全パイプラインをAIで回す仕組みです。
全体アーキテクチャ
パイプラインフロー
要件定義（対話型）
→ [ユーザー承認]
→ 設計
→ [Gate 1]
→ 実装＋テスト設計（並列）
→ テストコード生成
→ [Gate 2]
→ レビューガイド
→ 人間レビュー
→ [セキュリティCI（自動）]
→ 納品ドキュメント生成（オンデマンド）
SIerの実際の業務フローを踏襲した、ウォーターフォールとアジャイルのハイブリッド構成です。バックログから1機能ずつ取り出して処理するのはアジャイル的ですが、各機能の中では要件定義→設計→Gate→実装→Gateという順序を厳格に守ります。
まず要件定義をユーザーが承認してから設計に入り、設計完了後にGate 1で「この設計で要件を満たせるか」をチェックします。Gate 1を通過してはじめて実装に取りかかり、実装+テスト完了後にGate 2で「設計通りに作られているか」を確認します。Gate判定でNGが出たら自動で該当工程に差し戻し、3回リトライしてもダメなら人間にエスカレーションします。
また、セッションが中断した場合でも、project_status.yamlやバックログ、設計書などのドキュメントを参照して続きから再開できます。AIのコンテキストが途切れても、成果物がファイルとして残っているので作業が巻き戻ることはありません。
10個のSkills
パイプラインを構成するSkillsは、メインパイプライン用7つとオンデマンド用3つの合計10個です。
メインパイプライン（順序実行）：
| # | Skill | 役割 |
|---|---|---|
| 0 | requirements |
要件定義（対話型。ユーザー承認まで次に進まない） |
| 1 | orchestrate |
パイプライン制御・状態管理・セッション再開・スタックプロファイル初期化 |
| 2 | design |
設計書生成 |
| 3 | consistency-check |
Gate 1 & Gate 2（整合性チェック） |
| 4 | implement |
ソースコード + テストコード生成 |
| 5 | test-design |
テスト仕様書生成 |
| 6 | review-guide |
テスト手順書 + レビュー対象マップ生成 |
オンデマンド（納品時に実行）：
| # | Skill | 役割 |
|---|---|---|
| 7 | security-report |
セキュリティ検査の証跡レポート生成 |
| 8 | quality-report |
テスト結果・カバレッジ・Gate通過状況の品質レポート生成 |
| 9 | delivery |
納品ドキュメント一式の集約（上記2つを内包） |
CLAUDE.md：オーケストレーターの心臓部
CLAUDE.mdにはパイプラインの制御ルールを定義します。コーディング規約やセキュリティルールはここには書かない。それは各Skillの責務です。
CLAUDE.mdの役割は3つだけ。
- パイプラインの順序と状態管理
- Gate判定のルール
- 差し戻しのルール
状態管理
.orchestrator/project_status.yamlで現在の進捗を管理します。
project:
name: "プロジェクト名"
tech_stack:
language: "Python"
framework: "FastAPI"
database: "PostgreSQL"
current:
feature_id: "F-001"
phase: "implement" # requirements / design / gate1 / implement / test_design / gate2 / review_guide / done
iteration: 0
features:
F-001:
name: "タスク追加"
status: "in_progress"
gate1_iterations: 0
gate2_iterations: 0
Claude Codeのセッションが切れても、次回起動時に「前回の続きからお願いします」と言えば、このファイルを読んで続きから再開します。
Gate判定
Gate 1（設計レビュー）: 設計完了後、要件カバレッジ・矛盾・曖昧性をチェック
Gate 2（整合性チェック）: 実装＋テスト完了後、設計書⇔コード⇔テストの突合
各Gateのやり直し上限は3回。超えたらユーザーにエスカレーション
AIに全て任せるのではなく、Gateで品質を担保する仕組みです。3回ダメなら「AIでは解決できない可能性がある」と判断して人間に戻す。この割り切りが重要です。
各Skillの解説
requirements：要件定義（対話型）
このSkillには重要な前提があります。
このフェーズはAIだけでは完結しない。
ユーザーが顧客から聞いた情報を入力し、AIが構造化・抜け漏れチェック・確認質問を返す対話型のフェーズ。
AIが勝手に要件を推測して補完してはいけない。
つまり**「わからないことはわからない」と言わせる設計**です。AIが「一般的にはこうだから」で要件を埋めてしまうと、後工程で全部崩れます。
フローはこうです：
- 生情報の受け取り（会話メモでも「こういうの作りたい」の一言でもOK）
- ヒアリングシート生成（不足情報を質問としてまとめる）
- 要件の構造化（機能一覧、受入条件、スコープ外の明示）
- セルフチェック（受入条件の具体性、Tier判定の妥当性、未決事項の影響）
- ユーザー承認（「承認」と言うまで設計に進まない）
特にセルフチェックでは、こういう報告が返ってきます。
要件定義書を作成しました。セルフチェック結果:
- 受入条件の具体性: ✅ OK
- 機能間の依存関係: ✅ OK
- Tier判定: ⚠️ F-003の決済機能がTier中になっています。高にすべきでは？
- 未決事項: ⚠️ 1件あり（メール送信のSMTP設定）。設計には進めますが、実装前に確定が必要です。
- スコープ: ✅ OK
orchestrate：パイプライン制御 + スタックプロファイル初期化
パイプラインの実行順序を制御するのに加え、プロジェクト初期化時にスタックプロファイルを生成します。
このフレームワークは特定の言語やフレームワークに依存しません。「設計→実装→テスト→レビュー」の観点はフレームワークが所有し、具体的なコマンドやイディオム（起動方法、テスト実行、外部作用のfake手順等）はスタックプロファイルに分離しています。
templates/stack-profiles/
├── _template.md # プロファイルの契約（全言語共通の観点）
├── laravel.md # リファレンス例
├── fastapi.md # リファレンス例
└── README.md
初期化時にorchestrate Skillがプロジェクトの技術スタックに合わせて.orchestrator/stack-profile.mdを生成し、以後のdesign / implement / test-design / review-guideはこれを参照します。同梱のプロファイル例が古くなっても、Claude Codeが現行バージョンとの食い違いに気づけばプロジェクト側のプロファイルを更新する設計です。
design：設計書生成
設計書は機能ごとに docs/design/F-XXX.md に出力されます。ポイントは以下の3つ。
エラーカテゴリの強制チェック：
### エラーカテゴリチェック
- [x] バリデーションエラー
- [x] ビジネスロジックエラー
- [ ] 認証・認可エラー（該当なしの場合は理由を記載）
- [x] 外部サービス障害
- [x] インフラ障害（DB・ネットワーク）
「適宜」「必要に応じて」等の曖昧表現は使用禁止。具体的に書かないとGate 1で弾かれます。
受入条件トレーサビリティ：
## 受入条件トレーサビリティ
| 受入条件 | カバー箇所 |
|---------|-----------|
| "タイトル必須で作成できる" | メインフロー Step 2, API仕様 |
| "空の場合エラーを返す" | エラーフロー, バリデーション |
要件定義の受入条件が設計のどこで対応されているかを追跡します。漏れがあればGate 1で検出されます。
consistency-check：Gate判定
Gate 1とGate 2の2つのモードがあります。
Gate 1（設計レビュー）のチェック項目：
| チェック | NG時 |
|---|---|
| 要件カバレッジ | 受入条件の反映漏れを指摘 |
| 仕様の矛盾 | 矛盾箇所を指摘 |
| 曖昧性 | 「適宜」「必要に応じて」を検出 |
| トレーサビリティ | 参照先が実在し内容が一致するか |
| エラーカテゴリ | 4カテゴリが検討されているか |
Gate 2（整合性チェック）のチェック項目：
| チェック | NG時 |
|---|---|
| 機能実装カバレッジ | 設計書の全機能がコードにあるか |
| 余剰コード | 設計書にない処理がないか |
| API仕様一致 | エンドポイント・リクエスト・レスポンスが一致するか |
| テストカバレッジ | テスト仕様書が全受入条件をカバーしているか |
| 依存パッケージ整合 | importしているパッケージがrequirements.txtにあるか |
| Docker実行可能性 | ビルド・起動できる構成か |
| Tier判定妥当性 | 決済・個人情報を扱う機能が低Tierになっていないか |
FAILの場合は「どこをどう直すか」と「修正先（design / implement / test-design）」を具体的に指定して差し戻します。
implement：ソースコード + テストコード生成
実装後に設計書の末尾にマッピングを自動追記します。
## 実装マッピング（自動追記）
| 設計の参照先 | 実装ファイル | 概要 |
|------------|------------|------|
| API仕様: POST /api/tasks | src/api/tasks.py | APIビュー |
| DB変更: tasksテーブル | src/models/task.py | モデル定義 |
これによって設計書を見れば実装ファイルの場所がわかる状態が維持されます。
テストコードの品質ルールとして特に重要なのは：
-
APIレスポンスの検証は全フィールド完全一致（
"field" in bodyの部分一致は禁止。フィールドの追加・削除を検出できないため） - テストデータはハードコード（ランダム生成禁止。再現性を保証）
- 1テスト関数で1テストケース
test-design：テスト仕様書生成
テスト仕様書は実装コードを参照しない（テストファースト思想）。設計書の受入条件から逆算してテストケースを生成します。
全受入条件がいずれかのテストケースでカバーされていることを保証するため、カバレッジマッピングを含みます。
## 受入条件カバレッジ
| 受入条件 | カバーするテストケース |
|---------|---------------------|
| "タイトル必須で作成できる" | TC-F001-001 |
| "空の場合エラーを返す" | TC-F001-002, TC-F001-003 |
review-guide：テスト手順書生成
このSkillの設計思想は一行で表現できます。
読者は対象システムの前提知識がゼロの人である。
手順書に書かれた通りに上から順にやれば、誰でもテストとレビューが完了できる粒度で書く。「わかるだろう」を一切前提に置かない。
例えば環境構築手順はこのレベルです：
### Step 1: Dockerコンテナを起動する
1. ターミナル（コマンドプロンプト）を開く
2. 以下のコマンドを入力してEnterを押す：
cd プロジェクトのパス
3. 以下のコマンドでDockerコンテナを起動する：
docker compose up --build -d
4. 以下のメッセージが表示されれば成功：
✔ Container xxx Started
5. エラーが出た場合 → 「トラブルシューティング」セクションを参照
なぜここまでやるかというと、納品先の担当者がエンジニアとは限らないからです。一人SIerとして受託する場合、納品物の検収をする人が非エンジニアの場合もあります。
Tier制：リスクベースのレビュー最適化
全機能を同じ深度でレビューするのは非効率です。決済処理と静的ページを同じ粒度でレビューする必要はありません。
このフレームワークでは review_tier_definition.yaml で5段階のTier制を定義しています。
| Tier | 対象 | レビュー方針 | テスト要件 | 人間承認 |
|---|---|---|---|---|
| S | 決済・認証・個人情報 | 全行レビュー | ユニット+結合+手動、カバレッジ90% | 必須 |
| A | DB変更・外部API・バッチ | ビジネスロジック重点 | ユニット+結合、カバレッジ80% | 必須 |
| B | CRUD・バリデーション | 差分レビュー | ユニット推奨、カバレッジ60% | 不要 |
| C | UI・静的ページ | 動作確認のみ | 画面確認のみ | 不要 |
| D | 設定・ボイラープレート | ビルド確認のみ | ビルド通過のみ | 不要 |
自動Tier判定
各Tierにはキーワードとリスクシグナルが定義されています。例えばTier Sのキーワードには payment, stripe, authentication, jwt, personal_data, 決済, 認証, 個人情報 などが含まれています。
実装コードとAPI仕様からキーワードを自動照合し、該当するTierを判定します。複数Tierに該当する場合は、最も高いTierを採用します。判定に迷ったら1つ上のTierを採用する安全側倒しの設計です。
さらに6軸のリスク評価（金銭的損失、個人情報、法的責任、可逆性、影響ユーザー数、複雑度）で追加判定します。
# highが4個以上 → Tier S
# highが2-3個 → Tier A
# highが1個 → Tier B
# highが0個 → Tier C or D
オーバーライド条件
自動判定とは別に、強制的にTierを上げる条件も定義しています。
- 本番データベースへの直接操作 → Tier S強制適用
- 本番環境へのデプロイ → 最低Tier B
- 新規外部サービスとの初回連携 → 最低Tier A
セキュリティ（レベル2 / 無料ツールのみ）
一人SIerで受託する場合、「品質は信頼できるのか」の次に聞かれるのが「セキュリティは大丈夫なのか」です。
このフレームワークにはAI駆動開発向けのセキュリティパイプラインが組み込まれています。使用するツールはすべて無料で、言語非依存で動作します。
各ツールの選定理由や比較は以下の記事で詳しく解説しています。ここではフレームワークに組み込んだ実践構成を示します。
▶ AI駆動開発のセキュリティツール、結局なにを入れればいい？（Qiita）
セキュリティの構成
コミット前（ローカル）
└── Gitleaks — シークレット（APIキー・パスワード等）の検出
PR時（GitHub Actions: Security Level 2）
├── TruffleHog — シークレットの二重チェック
├── Semgrep — SAST（静的解析。AI生成コード特化ルールあり）
├── Trivy — コンテナ/IaC/ライセンスのスキャン
├── OSV-Scanner — 既知脆弱性（CVE）のチェック
└── SBOM生成 — CycloneDX形式で成果物として保存
リポジトリ設定（手動で有効化）
├── Dependabot — 依存パッケージの自動更新
├── Secret scanning — GitHubネイティブのシークレット検出
└── Socket — slopsquatting（偽パッケージ）対策
手動実行
└── OWASP ZAP — DAST（動的アプリケーションセキュリティテスト）
なぜAI駆動開発にセキュリティが特に重要か
AIが生成するコードには、人間が書くコードとは異なるリスクがあります。
- 幻覚パッケージ: 存在しないパッケージ名をimportするコードを生成する可能性がある。攻撃者がその名前で悪意あるパッケージを登録する（slopsquatting）リスクがある
- 古いパターンの再現: トレーニングデータに含まれる古い・脆弱なコードパターンを再現する可能性がある
- シークレットの混入: サンプルコードからAPIキーやパスワードをそのまま持ってくる可能性がある
SemgrepのAI Security / Shadow AIパック、Socket、Gitleaks/TruffleHogの組み合わせで、これらのリスクを自動検出します。
PRテンプレート
AI生成コードの利用状況を可視化するため、PRテンプレートにAI利用チェックを含めています。
## AI利用チェック
- [ ] このPRにはAI生成コードが含まれる
- [ ] AI生成コードのセキュリティレビューを実施した
- [ ] AI生成コードのライセンス互換性を確認した
品質ゲートとしての運用
セキュリティCIの結果は、ブランチ保護ルールでSecurity (Level 2)をRequiredに設定することで、合格しないとマージできない品質ゲートとして機能します。
既存プロジェクトに導入する場合は、過去の負債で無関係なPRまで赤になることを避けるため、SECURITY_GATE_MODE=report（助言モード）で導入し、既存指摘を棚卸ししてからblockに切り替える段階的な導入を推奨しています。
納品ドキュメント生成
一人SIerが顧客に「何を作り、どう品質・セキュリティを担保したか」を説明するための成果物を、パイプライン完了後にオンデマンドで生成します。
納品ドキュメントを作成してください
この一言でdelivery Skillが以下をdocs/delivery/に一括生成します。
| 成果物 | 内容 |
|---|---|
index.md |
納品物一覧＋担保方法の要約 |
design_summary.md |
顧客向け設計サマリー（提供機能・構成） |
quality_report_*.md |
テスト件数・合否・カバレッジ・Gate通過・既知の不具合 |
security_report_*.md |
セキュリティ検査内容と証跡（SBOM・ライセンス等） |
presentation_*.md |
顧客説明用スライド（Gamma取り込み用Markdown） |
Gammaでプレゼン資料にする
presentation_*.mdはGammaへの取り込みを前提に、---（水平線）でスライドを区切った形式で生成されます。
- GammaでImport → Markdownを選択
-
presentation_*.mdを貼り付け／アップロード - テーマを選んで微調整
- PPT / PDFにエクスポートして顧客に提示
コードを書いて、テストして、セキュリティ検査して、納品資料まで作る。この全工程がClaude Codeの中で完結します。
使い方
セットアップは簡単です。
git clone https://github.com/high-tech-r/orchestrator-skills.git
cd orchestrator-skills
pip install pre-commit && pre-commit install # コミット前のシークレット検出
claude
プロンプトに要件を入力します。
以下の要件でオーケストレーションを開始してください。
プロジェクト名: 予約管理API
技術スタック: Python / FastAPI / PostgreSQL
機能:
- F-001: 予約作成（日時・名前・メールアドレス必須、確認メール送信）
- F-002: 予約一覧取得（日付フィルタ、ステータスフィルタ）
- F-003: 予約キャンセル（キャンセルメール送信、24時間前まで）
あとはClaude Codeが各Skillを順番に実行してパイプラインを回します。Gate判定でNGが出れば自動で差し戻し、人間の判断が必要な場面では「承認してください」と聞いてきます。
技術スタックは任意です。Python / FastAPIに限らず、Laravel / Node.js / Go / Java など、スタックプロファイルを差し替えるだけで対応できます。
セッションが切れた場合は：
前回の続きからお願いします
project_status.yamlを読んで続きから再開します。
既存プロジェクトへの組み込み
新規プロジェクトだけでなく、既にあるリポジトリにも後付けできます。
必須ファイル（オーケストレーション本体）：
CLAUDE.md # 既存にCLAUDE.mdがあるなら上書きせずマージ
.claude/skills/ # 10スキル + Tier定義。フォルダごとコピー
任意ファイル（セキュリティ）：
.pre-commit-config.yaml / .gitleaks.toml # シークレット検出
.github/workflows/security.yml / dast-zap.yml # CIパイプライン
.github/PULL_REQUEST_TEMPLATE.md # AI利用チェック
.zap/rules.tsv # ZAP抑制ルール
.claude/settings.json # 機密ファイルのAI遮断
落とし穴と対策
「簡単なシステム」ほど要件が膨らむ
requirements Skillでスコープ外を明示的に定義させることで対策しています。
## 前提・除外事項
- スコープ外: スマートフォンアプリの開発、既存システムからのデータ移行、SEO対策
最初の段階で「やらないこと」を合意しておくことが、スコープクリープの最大の防御線です。
AIが勝手に要件を補完する問題
requirements Skillに明記してあります：
AIが勝手に要件を推測して補完してはいけない。
「一般的にはこうだから」で埋めない。
「わからないことはわからない」と明示し、ユーザーに確認する。
これを書かないと、AIは「たぶんこうだろう」で要件を埋めてしまい、Gate 1を通っても顧客の意図とずれた設計になります。
Gate判定が永遠にループする問題
各Gateのリトライ上限を3回に設定しています。3回FAILが続いたら「AIでは解決できない可能性があります」とエスカレーション。無限ループを防ぐ安全弁です。
インフラコスト
サーバー: 0円（自宅の既存PC + Cloudflare Tunnel）
Claude Code: Proプランの範囲内（API従量課金不要）
セキュリティCI: 0円（全ツール無料枠）
GitHub: 0円（無料枠）
合計: 月額数千円程度
まとめ
このフレームワークの核心は4つです。
- CLAUDE.mdでパイプラインを制御し、状態管理とGate判定で品質を自動担保する
- 10個のSkillsで全工程を標準化し、案件ごとの属人性をゼロにする
- Tier制でレビュー深度を最適化し、リスクに応じたメリハリをつける
- 無料ツールだけでセキュリティCIを構成し、納品時には証跡付きレポートまで自動生成する
この仕組みがあれば、エンジニアは**「何を作るか」の判断と、Gateを通らなかった問題の解決**に集中できます。設計・実装・テスト・セキュリティ検査・納品資料作成という工程はAIが担い、人間は設計判断と品質検証に専念する。
これが、従来数十人でやっていたことを1〜2人で実現する仕組みの正体です。
フレームワークはMITライセンスで公開しています。フォーク・改変・再配布は自由です。
この記事で紹介したフレームワークの背景にある「なぜそれが可能なのか」「開発現場にどんな影響があるのか」については、以下の記事で詳しく書いています。