受託開発の現場でClaude Codeを使うためのサブエージェント・スキル・運用標準の一式を、「Claude Code プロジェクトパック」としてGitHubで公開しました（MIT License）。個々の機能や導入手順はリポジトリのREADMEに譲り、本コラムでは、その設計の土台にある考え方を書きます。なぜ受託開発とAI駆動開発の組み合わせは難しいのか。その難しさを、私たちはどのような判断で仕組みに変換したのか。そして、なぜ隠さず公開することにしたのか。導入を検討する際の判断材料として使ってください。
先日、受託開発の現場でClaude Codeを使うためのサブエージェント・スキル・運用標準の一式を、「Claude Code プロジェクトパック」としてOSS公開しました。MIT Licenseです。IPA共通フレーム2013の工程構造に対応し、要件定義から納品までをカバーしています。
GitHubリポジトリ: https://github.com/CT-masato-hino/claude-code-project-pack
私たちはFDE（前方展開エンジニア）として企業の開発現場に入る仕事をしていますが、この数年、AI駆動開発が止まる場面に繰り返し立ち会ってきました。
止めるのは技術ではありません。検収、稟議、監査、多段請負の責任分界。つまり受託開発という商習慣です。
デモは成功します。実装は確かに速くなります。しかし数ヶ月後には、決まって同じ問いに突き当たります。
多くの組織でAI導入がPoCで止まるのは、AIの能力が足りないからではなく、AIの出力を商習慣に接続する部分が誰の仕事でもないからです。
ツールは配られ、利用ガイドラインも書かれた。研修も実施した。しかし、接続の設計は空白のまま残ります。この空白はセミナーや事例集では埋まりません。個々の案件の工程と成果物の中で、ひとつずつ決めていくしかない類のものだからです。
パックの中身は、この空白を現場で埋め続けた結果を汎用化したものです。以下、設計の土台にある考え方を順に説明します。
パック全体を貫く前提はひとつです。
受託開発の商品は「動くコード」ではなく、「顧客が検収できる状態」である。
受託の商流では、コードが動くことと案件が終わることのあいだに長い距離があります。工程ごとの成果物、版数と承認記録、要件からテストまでのトレーサビリティ、そして検収。
この距離は、AIに「いい感じにやって」と指示しても埋まりません。誰が何を担保するかを、先に決めておく必要があります。
この前提に立つと、作り込むべき場所も変わります。パックには派手な機能がひとつもありません。その代わり、受託の品質と信頼が実際に決まる地味な場所に、担当エージェントと判定基準を配置しています。
いずれも、生成AIの華やかな活用事例には出てこない領域です。しかし受託開発を経験した方なら、プロジェクトの信頼がこうした場所で決まることをご存知のはずです。AIの実装力が上がるほど、差がつくのはむしろこの周辺になります。
もうひとつ、この前提から導かれるのがトレーサビリティの扱いです。
パックでは機能ID→受入基準→設計書項番→テスト番号を全成果物で連結し、断絶を機械的に検出します。「この納品コードは誰が書き、誰がレビューし、どのテストで検証されたか」という監査の問いに、成果物IDから辿って答えられる状態を維持する。
この背骨があってはじめて、AI駆動開発の速度とエンタープライズの監査要件は両立します。
現場にAIを入れて最初に確認できた事実は、AIの失敗パターンに新しさがない、ということでした。
いずれも、人間のプロジェクトで長年観察されてきた失敗と同型です。異なるのは速度だけ。人間の新人が1週間かけて間違った方向に進むところを、AIは30分で間違った成果物を積み上げます。
この観察から、2つの設計方針を導きました。
パックにはQCD（品質・コスト・納期）の統制基準を21項目定義していますが、その多くはプロジェクトマネジメントの教科書にある原則です。一部を抜粋します。
| ID | 基準 | 既定値 |
|---|---|---|
| Q-11 | AI成果物の生成と検証の分離 | 100%。自己レビュー禁止 |
| Q-09 | セキュリティCritical/High | 0件。受容には顧客合意の記録が必須 |
| C-02 | 工数消化率と進捗率の乖離 | +10%で警告、+20%で人間へエスカレーション |
| D-01 | 進捗の定義 | 成果物完了基準の0か100のみ。「90%完了」は受理しない |
すべての基準に「測るエージェント」と「合否を判定する者」を分けて割り当て、基準IDを引用しない合否宣言は無効としています。目新しい理論より、受託の現場で長く生き残ってきたルールを採用しました。
人間相手には徹底しきれなかったこれらの原則が、AI相手にはツールの設定として完全に強制できます。
パック内の統制はすべて、「守ってほしい」ではなく「破れない」形で実装しています。
「90%完了を信じるな」という教訓は、何十年言い続けても人間の組織からは消えませんでした。それが機械には設定ひとつで強制できる。AI統制の本質は新技術への対応ではなく、道具がようやく追いついた古典の実装だと私たちは考えています。
なお、基準には逆方向の点検も組み込みました。週次のQCDレポートが3週連続すべて緑なら、基準が形骸化していないかを疑って点検します。守られない標準を量産することが、統制の最大の失敗だからです。
受託の案件の多くは、要件が固まらないまま始まります。「モックだけある」「あれと同じものを作ってほしい」「ビジネス目的しか決まっていない」。要件確定を待ってから着手できる案件のほうが少数派です。
AIにとってこれは最も危険な条件です。AIは空白を埋める能力に長けているため、曖昧な指示を与えると、もっともらしい仮定で隙間を埋めた成果物を返します。
そして受託で最も高くつく事故は、この「勝手な仮定」が数週間後の結合テストや顧客レビューで発覚することです。
正攻法は「曖昧さをなくしてから進む」ですが、現実には間に合いません。パックでは次の方針を採りました。
曖昧さは消せない。消す代わりに、IDを振って管理する。
具体的にはこう動きます。
これにより曖昧さは、いつ表面化するか分からないリスクではなく、残数を数え、影響範囲を追い、解決のたびに消し込める管理対象になります。
同じ発想で、案件の始まり方そのものも類型化しました。パックの初期化スキルは、契約の形とは別に「スタート地点に何があるか」を判定し、初動を切り替えます。
曖昧なスタートを例外ではなく前提として扱う。これが受託の現実に合わせた設計だと考えています。
パック全体の構造を決めているのが、AI駆動開発の重心の変遷を捉えた4層モデルです。
| 層 | 重心の時期 | 内容 |
|---|---|---|
| プロンプト | 〜2024 | 1回の指示の最適化 |
| コンテキスト | 2025 | 何を見せるかの情報設計。CLAUDE.md、ドキュメントの正本管理 |
| ハーネス | 2026年初頭〜 | 許可設定やhooksで、1回の実行を安全にする装備 |
| ループ | 2026年6月〜 | ハーネスを装備したエージェントを、自動で回し続ける仕組み |
パックはこの4層すべてを受託開発向けに配置していますが、最も重要なのは個々の実装ではなく、下の層を整備しないまま上の層に手を出すことを統制で禁じている点です。
典型的な失敗は、ドキュメントの正本管理（コンテキスト層）が崩壊している組織が、エージェントの自動運転（ループ層）から始めようとするものです。
何が正しい仕様かをAIが判別できない状態で自動化すれば、間違った成果物が自動で量産されます。下の層に穴があるままの自動化は、事故を高速化する装置にしかなりません。
この4層は、自組織の成熟度診断としても使えます。自社は今どの層まで整備できているか。飛ばそうとしている層はないか。この問いに答えるだけでも、AI駆動開発への投資判断の解像度は大きく上がるはずです。
また、最上位のループ層には専用の統制を用意しました。自動で回り続ける仕組みには、停止手段、実行回数の上限、無人時間帯の制約、人間によるチェックポイントが不可欠です。「自動化できるか」と「無人で回してよいか」は別の問いであり、後者には常に統制側の答えが要ります。
AI活用の事故は、悪意からではなく善意の近道から起こります。
納期に追われたエンジニアが権限確認をバイパスする。デバッグのために秘密情報をプロンプトに貼り付ける。便利そうな出所不明のMCPサーバーを接続する。いずれも「早く終わらせたい」という善意の産物です。
注意喚起の文書を配っても、この種の事故は防げません。パックでは3つの層で対処しています。
1. 技術的な禁止
破壊的な操作や秘密情報へのアクセスは、許可設定のdenyリストとhooksで機械的に塞ぎます。禁止事項を覚えてもらうのではなく、実行できなくします。
2. 組織的な統制
Claudeの利用プラン別に統制手段を整理しました。Enterpriseプランなら組織ポリシーで強制する。Teamプランなら共有設定と検知で補う。個人プランは統制手段そのものが乏しいため、業務利用の可否自体を人間が判断する。
「どのプランでも同じガイドラインで運用する」という建て付けは、統制としては機能しません。
3. 報告の免責
秘密情報を誤って入力してしまった、といった事故の自己申告は責めない。隠蔽だけを重大違反とする。これを標準文書に明文化しました。事故そのものより、事故が報告されない組織のほうがはるかに危険だからです。
セキュリティ統制は導入の最後に回されがちですが、実際には最初に決めるべき項目です。統制のないまま現場展開が進むと、後から「今まで良かったものが禁止される」という摩擦が生まれ、定着はさらに難しくなります。
ここまでの仕組みを、なぜ競争優位として隠さず公開するのか。理由は3つあります。
第一に、方法論はいずれ標準化されるからです。
エージェントの統制手法は、今後数年で業界標準が固まっていきます。標準になるのは、公開され、使われ、揉まれたものです。であれば、日本の受託開発の商習慣――検収、多段請負、工程成果物――を織り込んだ版を、早い段階で公開しておきたいと考えました。英語圏のベストプラクティスには、この商習慣が含まれていません。
第二に、私たちの事業は方法論の販売ではないからです。
パックは案件ごとのテーラリングを前提に設計しており、そのまま使えるものではありません。案件規模に応じてエージェントを統合・分割し、QCDの閾値を顧客標準に合わせ、既存の開発標準と整合させ、現場に定着させる。この後半戦こそが支援の本体であり、ドキュメントを渡すだけでは進まない領域です。方法論を公開しても、この価値は減りません。
第三に、公開が最も確実な証明だからです。
「AI駆動開発ができます」という言葉は、いまや誰でも名乗れます。実際にどのような統制で、どのような成果物を、どのような基準で作っているのか。それを確認する手段を相手に渡すには、中身を全部見せるのが最短でした。
発注先を検討する立場の方には、私たちに限らず、候補となるベンダーへこう質問することをおすすめします。
「AIが作った成果物の検証は、誰がやる設計になっていますか」
生成と検証の分離、進捗の定義、曖昧さの管理。この語彙で会話が成立するかどうかで、デモの先まで設計しているベンダーかどうかは判別できます。
中身の詳細はGitHubリポジトリを参照してください。
GitHubリポジトリ: https://github.com/CT-masato-hino/claude-code-project-pack
一式まとめて置いてあるため、立場別に入口を示しておきます。
| 立場 | 最初に読むもの | 確認できること |
|---|---|---|
| 経営・事業責任者 | READMEの「4層モデル」 | 自社が今どの層にいて、どの層を飛ばそうとしているか |
| PM・PMO | docs/standards/qcd-standards.md | 「順調です」を排除する21基準と週次運用の手順 |
| 現場エンジニア | .claude/agents/ の定義1本と docs/flow-map.md | エージェントを「基準の担保者」として配線する構造 |
| セキュリティ・情シス | docs/standards/ai-security-baseline.md | 事故パターン10項目、プラン別統制、報告免責の設計 |
| SES・受託開発の経営層 | docs/tailoring-guide.md | AI活用を単価交渉と事業転換の材料にする道筋 |
全体像を先に掴みたい場合は、docs/flow-map.md の図4枚（工程×エージェント、ドキュメントの流れ、運用ループ、仮定のライフサイクル）から読むのが早いと思います。
導入にあたっての注意はひとつです。このパックはそのまま使うものではありません。
案件ごとにテーラリングする前提で設計されており、規模別の調整方法をガイドに明記しています。全部入りが適合するのは中規模案件のみで、小規模は統合し、大規模は複製と統制強化で対応します。
一方で、削ってはいけない項目も4つ定めています。
これらは削った瞬間から品質が劣化し、しかも劣化に気づけなくなる性質のものです。テーラリングとは何でも軽くすることではなく、削れるものと削れないものを見分けることだと考えています。
テーラリングと組織への定着は、ドキュメントだけでは進まない領域です。Chapter Techでは、エンタープライズ企業向けの導入・統制設計をエンタープライズDX & FDE支援サービスで、SES・受託開発企業のAI駆動開発シフトをDelivery Scope+の並走モデルで支援しています。導入前の相談はお問い合わせからどうぞ。
最後に一点だけ。READMEの結びに書いた通り、このパックは定型を引き受けるための道具であり、プロジェクトを左右する構造化できない部分――顧客の声色の変化、決裁者が目を止めた資料のページ、メンバーの停滞――は自動化の対象外です。
仕組みが定型を巻き取るのは、人がそちらに向き合う時間をつくるためです。この前提ごと、使ってもらえればと思います。