Takenori-Kusaka/pit-in-template：AI 協調型软件开发流程模板

ピットイン方式 準拠テンプレート

ピットイン方式(正式名称: AI協調型ソフトウェア開発プロセス標準)に沿って開発するためのプロジェクトテンプレートです。

マシンは人間より速い。それでも、決められた場所では必ず人間が触る。

F1 のピット作業は 18〜20 名が2秒以下で終えます。レースそのものは止まりません。決められた場所でだけ人の手が入ります。AI が実装を主導する開発でも、この形は変わりません。

始め方

プロセスを先に覚える必要はありません。次の5手順で始めます。

1. GitHub 上部の Use this template から新しいリポジトリを作り、手元へ clone する
2. Claude Code でリポジトリを開く。開いた時点で、いまの状態と次の一手が自動で入る(.claude/settings.json の起動時のフック)
3. /pit を実行する
4. 出力の [次のコマンド] を実行する。最初は /process-init(プロセス構成を決める設問。専門用語には言い換えが添えてある)
5. [人の判断待ち] が出たら、表示された席の人が判断して記録する。終わったら、また /pit に戻る

以降も「/pit → 出力に従う」を繰り返します。次の一手は、構成・判定記録・機能仕様・ブランチの状態から機械が出します(scripts/gate/next.mjs)。AI に判定させません。人の判断を要する段階(ゲートの判定、席の責任者の任免、受入基準へ戻る判断、出荷の実行)では、AI の担い手は先へ進まず、待つ席と受信箱のラベルを示して止まります。体制の変化点(責任者の交代、モデルの世代交代)の後に失効した検出率の測定値、後継不在の席、依存先の欄の空欄、席の責任者本人の力量の未確認、実環境の統制の未確認も、/pit が担当の席と次の一手を添えた注記として出します(段階は止めません)。出荷の直前の集約まで待たずに届きます。

以下は、各段階の中身の説明です。

まず何をするか

1. このテンプレートからリポジトリを作る

GitHub 上部の Use this template から新しいリポジトリを作ります。

コード knowledge graph の graft のグラフは、「始め方」の5手順に含めません。製品のコードが無い初期化の直後には、探索するものが無いためです。コードが増えた後、AI の担い手が graft ask で空のグラフに当たると、手順(.claude/skills/graft/SKILL.md)に従って次のコマンドで作ります。手元で先に作っておいてもかまいません。

npx -y @nanonets/graft@0.12.1 build

グラフ(/graft/)は clone ごとのローカルキャッシュで、commit しません。以後はどのコマンドも差分だけを取り込みます。

2. プロセス構成を決める

Claude Code でリポジトリを開き、次を実行します。

/process-init

チーム規模・事業ステージ・品質要求・安全重要度・開発形態などを8問で聞かれます(1〜2名のときだけ聞く1問を含む)。設問には、専門用語を使わない言い換えが添えてあります。回答から、あなたの状況に合ったプロセス構成が生成されます。

最初のコミットは PR で入れます。生成物と基盤を、ブランチ(例: chore/process-init)で PR にし、本文の末尾の段落(トレーラ)に Spec: setup を書きます。本文は .github/PULL_REQUEST_TEMPLATE.md から作り、「リスク区分」の節に区分を1つだけ残します(G-5 の pr-rules が、変更の種類に依らず確かめます)。node では、先に npm install でロックファイルを作り、同じ PR に含めます(CI の npm ci が要するため)。main へ直接コミットしません。独立レビュー(G-6)を適用する体制では、PR を経ないコミットが出荷判定の証跡で欠落になります。

G-5 を手元で確かめるときは、CI と同じ範囲を実行するコマンドを使います。個々の検査を手で選ぶと、CI より狭い範囲を見て「0件」と誤ることがあります。

node scripts/gate/g5-local.mjs                       # PR の検査(pr-rules)も含めるなら --base origin/main --pr <PR の JSON>

3. 開発を始める

以降は、/pit が出す次の一手に従います。使うスキルは次のとおりです。各スキルの最後の手順も、次の一手を出します。

/pit              次の一手を出す            → 全段階
/spec-write       受入基準を書く          → G-2 / G-4
/task-breakdown   実装計画へ分解する       → G-4
/implement        AI が実装する            → G-5
/human-verify     人が差分を検証する        → G-6 の前段
/artifact <種別>  成果物を作る・見直す      → テンプレ00〜11(例: /artifact 05)
/gate <ゲート>    ゲート判定を記録する      → G-1〜G-8・SG(例: /gate G-4)。/gate-record も同じ
/adr-write        設計判断を記録する        → G-3
/process-change   体制の変化点を反映する    → 人の増減・交代、運用形態、AI の担い手、ステージ移行

/artifact と /gate は入口が短く、種別・ゲートごとの補助ファイル(.claude/skills/artifact/artifacts/・.claude/skills/gate/gates/)を1枚だけ読みます。next.mjs の出力の「読む:」が、その所在を指します。

有効なゲートの判断は process.config.json を正本とします。next.mjs は構成を読み、あなたの構成で有効でないゲートの判定待ちを出しません。構成を読まないスキル(/spec-write など)もあります。

ブランチ保護を適用する

初期化の出力に、適用するルールセットのコマンドが出ます。適用は人が行います(エージェントは実行しません)。

gh api repos/{owner}/{repo}/rulesets --input .github/rulesets/checks-only.json

あわせて、スカッシュのコミットのメッセージを「PR の題名と本文」にします。PR の様式の末尾の段落(トレーラ)が、コミットのトレーラとして残ります。

gh api -X PATCH repos/{owner}/{repo} -f squash_merge_commit_title=PR_TITLE -f squash_merge_commit_message=PR_BODY

ルールセットを使えない場合: 私有リポジトリでルールセット(ブランチ保護)を使えるかは、GitHub のプランに依ります(2026-10 時点で、無料のプランでは公開リポジトリに限られます)。使えない場合、G-5 が落ちた PR も、G-5 を経ない直接の push もマージを止められません。このテンプレートが代わりに行えるのは事後の検出だけです。出荷判定(G-7)の証跡の集約が、gate-g5 の成功を持たない PR(結果の記録が無い PR を含む)と、トレーラ Risk・Verification を持たない PR を経ないコミットを、欠落として失敗させます。止めることはできず、出荷の時点まで気づかない点を受け入れて運用してください。

4. 体制が変わったら

人が増える・減る・交代する、AI の担い手のモデルや指示資産が変わる、運用形態を変える、ステージが移る。こうした体制の変化点は、/process-init の再実行ではなく /process-change で反映します。最初のゲート判定より前に行います。

/process-change

構成の差分、失効する例外と適合性確認、未達・逸脱の発生、残作業が表示されます。

全席が未記入の状態(初期化の直後)からの記入も任免です。初期化の直後(どの席にも責任者が記入されたことがない状態)の初回の記入は、体制の人数に依らず、名簿と全席を1回の変化点で出し、その変化点で D-0 表1「体制と運用形態」の決定者の席(既定は事業決裁者)に記入する人の記名と理由で受け付けます。組織上の任命権者を先に名簿へ置き、その記名で席を埋めることもできます。人が全員離脱して全席が空いた状態は、初回の記入に当たりません。

3名以上の体制で、兼務を禁じる2つの席(開発者と独立レビュア、開発者と出荷判定者、出荷判定者と事業決裁者、AI 維持管理者と AI 運用担当者。10名以上では、価値責任者と技術判断者)の責任者を同じ人にする変更は、拒否されます。1〜2名の体制では、逸脱として記録し、表示し続けます(出荷判定者と事業決裁者の兼務は、保証の開示の項目1 に「異議を書く者と、残存リスクを受容する者が同一である」と出ます)。

納期だけの変更は変化点に数えません。起票された場合は「構成の変更なし」と記録します。提供者の障害や利用上限で AI が使えない期間も変化点に数えませんが、期間とその間の扱い(人へ戻した / 止めた)を記録し、出荷判定の証跡へ出します。

人数の境界の通過、運用形態の変更、承認権限の一時制限の発動、AI の担い手の識別の変更、独立レビュー(G-6)が成立から未達・成立しないへ変わる変化、出荷判定者の席の責任者の交代は、出荷判定者の席の責任者へ即時に知らせる対象です。出荷判定者の交代では前任者にも(前任者が体制から外れていれば D-0 表1 の決定者へ)、品質保証部門の通知先(governance.qaNotice。任意)を定めていればそこへも知らせます。通知先と通知日を、変化点の記録へ残します。通知する者と通知先が同一人物の場合(1人体制など)は、入力を求めず「通知する者と通知先が同一」と記録します。未記入の通知は、出荷判定の証跡の集約が記録の欠落として扱います。

構成を書き換えるのは /process-change だけです

process.config.json を手で編集しないでください。アダプタ、カバレッジの下限、確認者の調達先といった個別の値も、/process-change(種別 settings)で変えます。

変化点の記録(changeLog[])の各記録は、適用後の構成の要約値と、直前の記録の要約値を持ちます。手で書き換えた構成、記録を経ない再生成、記録の書き換え・切り詰めは、契約検査(verify-gate-contract)が検出して失敗させます。PR では、基底ブランチの構成とも比べます。PR を経ない体制に備えて、既定ブランチ(main)への push でも契約検査を走らせ、push の直前のコミットの構成と比べます(gate-g5.yml)。push の後に失敗しても変更は取り込まれているため、出荷判定の証跡の集約も同じ整合を確かめ、不整合を記録の欠落として扱います。回答と名簿の矛盾(回答は「確認者なし」なのに、独立レビュアの席へ別の人を記入している、など)も検出します。

要約値ごと書き換える改ざんは、ローカルの検査だけでは検出できません。過去の記録の書き換えは、基底ブランチとの比較で止まります。構成を手で書き換えたうえで、要約値を計算し直した記録を追記する偽造は、基底ブランチとの比較も通ります。要約値は鍵を持たないため、記名した本人が決定したことを証明しません。これを止めるのは、構成が強制層であること(変更には AI 維持管理者の承認を要する)と、人による PR の確認です。

D-0 体制図(docs/D-0-governance.md)のうち、構成から導ける欄(責任者の表と名簿、担い手と運用形態、委任の範囲、改訂履歴、版)は、/process-change が書きます。体制図と構成へ、同じ内容を二重に書く必要はありません。人が書くのは、決定の理由と記名だけです。D-0 の検査(check-d0)が、生成した欄と構成の一致を確かめます。

このテンプレートの更新より前に生成した構成(要約値を持たない構成)は、契約検査が失敗します。最初の /process-change で要約値の連鎖が始まります。手順は /process-change の「旧い構成からの移行」にあります。

process.config.json は、人の名簿と、席(ロール)ごとの責任者・運用形態を持ちます。

責任者・決定した人・適合性確認の実施者と承認者は、人の名簿と照合されます。AI の名義(モデル名、agent、bot、AI の表記を含む名義)と、名簿に無い名義は拒否されます。同じ語を含む実在の氏名は、人が確認して nameConfirmed: true を書いた場合に限り通り、「名義の機械検査を人が上書きした」と表示されます。名簿が無いあいだ、席を委任にできず、統制を緩める向きの決定は受け付けられません。

名義の検査は、語の一致によるものです。役職名や、別の文字種で書いた名義は検出できません。名簿のアカウントの記載が正しいか(架空の2人目が書かれていないか)も、機械では確かめません。名簿は人が記入するものとし、内部監査で確かめます。

委任しても、判定者は席の責任者(人)のままです。移るのは判定の時点です。出荷判定者・事業決裁者・AI 維持管理者・AI 運用担当者の席は委任できません。独立レビュー(G-6)の判定の時点が事後へ移るのは、独立レビュアの席が委任で、規則に該当し、リスク区分が R3 と記録された変更だけです。

委任した変更のマージの経路

委任には2つの形があります。どちらに当たるかは、機械の規則で判定します。

開発者の席だけの委任で、独立した人が事前に承認した変更は、出荷判定の証跡で「独立した人の確認あり」に数えます。「人の事前確認を経ていない変更」には数えません。この語は、G-6 の判定を事後へ移した変更だけを指します。トレーラ Delegated: <規則ID> は、変更ごとの検証を担い手へ委ねたことの識別として、別に数えます。独立した人の事前の承認が無い委任の変更は、G-6 を事後へ移した変更と、それ以外(独立した人の確認を経ていない変更。独立レビューを適用する体制では欠落)に分けて表示します。トレーラ Delegated を持つ変更のリスク区分が R3 でなければ、委任の範囲の逸脱として欠落です。

開発者の席の委任の範囲の変更では、担い手が PR の「検証方法と結果」へ実行結果の証拠を書きます。レビュアは、その欄が担い手の記載であることを理由に差し戻しません。テンプレートの既定の権限設定(.claude/settings.json の許可リスト)に gh pr ready はありません。権限設定は強制層であり、組織が許可を足すまでは、委任の変更も人が Draft から Ready にします。担い手は設定を変えずに、Ready にしてよい状態であることを人へ報告します。許可を足した組織では、担い手が Ready にします。人確定・協働の変更では、欄を書くのも Ready にするのも人です。

以下は、G-6 を事後へ移す委任の経路です。該当の判定は実装しています。マージの実行は、既定で無効です。無効のあいだ、この形の変更も協働として扱い、人の承認を待ちます。

判定するのは、委任の7条件のうち、変更ごとに機械で判定できるものです。

強制層・構成の正本・判定の記録(.claude/**、.github/**、process.config.json、scripts/gate/**、docs/gates/** など)に触れる変更は、規則に当たっても常に対象外です。手元では、入力を JSON で渡して判定を試せます。

node scripts/gate/check-delegation.mjs --input scripts/gate/fixtures/delegation-eligible.json
node scripts/gate/test-check-delegation.mjs

マージの実行を有効化する手順(組織が行います。エージェントは行いません)

1. 必須承認を回避できる権限を持つ、専用のトークンを用意する(GitHub App、または専用の機械アカウント)。人の個人トークンを使わない
2. そのトークンの主体を、ブランチ保護(ルールセット)のバイパスの一覧へ加える
3. リポジトリのシークレット DELEGATED_MERGE_TOKEN へトークンを登録する
4. リポジトリの変数 DELEGATED_MERGE_ENABLED を true にする
5. 試験用のリポジトリで、該当する変更と該当しない変更を流し、期待どおりに動くことを確かめる

有効化すると、該当した変更はワークフローがスカッシュでマージします。機械は承認のレビューを付けません。PR へ「人の事前確認を経ていない変更(G-6 の判定を事後の抜き取りへ移した変更)として、規則 により先へ進めた。承認ではない」と記録し、コミットへトレーラ Delegated: <規則ID> と Risk: R3 を残します。出荷判定の証跡は、この変更を「人の事前確認を経ていない変更」に数え続けます。止めるときは、変数を true 以外へ戻します。

有効化する組織が負う責任

• このワークフローは、2026-10-01 時点で、実際の GitHub 上で実行して確かめていません(手動実行の経路、開発者の席の責任者の承認を確かめる経路を含む)。確かめたのは、フィクスチャによる判定と、模擬の入力による手順までです。有効化の前に、手順5 を必ず行ってください
• バイパスの権限を持つトークンは、規則に該当しない変更もマージできます。トークンの保管、権限の範囲、失効は、組織の責任です。このワークフロー以外から使える場所へ置かないでください
• 確約範囲とコア指定のパス(delegation.protectedPaths)のキーが無い構成では、どの変更も委任の範囲に該当しません。パスを登録するか、該当するパスが無いことを確かめたうえで空の配列を宣言してください(/process-change)。空の配列が正しいか(確約範囲とコア指定が本当に無いか)は、機械で確かめません。宣言した者の責任です
• トレーラとリスク区分は、行為する側の申告です。判定は、規則の対象のパスと照合しますが、規則の範囲の内側で何を変えたかは読みません。規則の範囲を狭く保つこと、事後の抜き取り(条件6)を実際に行うことは、席の責任者の責任です
• ワークフローと判定のスクリプトは強制層です。変更は、AI 維持管理者の承認を要します(state:needs-platform)。PR の先頭を checkout する手順や、承認を付ける手順を足さないでください
• 受託では、委任を適用するかどうかを契約で合意します。合意の無い委任の変更を、納品へ含めないでください

委任の期間ごとの保証の開示

委任で先へ進めた変更は、G-7・G-8 を変更ごとには行わず、期間ごとの保証の開示で扱います(標準 第4章 G-7・G-8)。出荷の範囲によらず、期間を指定して出します。

node scripts/gate/aggregate-evidence.mjs --period-from 2026-09-01 --period-to 2026-09-30

• 出力先は evidence/period-<起点>_<終点>/。7項目に加えて、G-6 を事後へ移した変更ごとの事後の抜き取りの記録(G-6 の判定記録で、確定の形態が「委任」、「対象」が当該の PR)を出す
• 期間の開示への受容と異議は、G-8 の判定記録の「対象」へ期間を 2026-09-01〜2026-09-30 の形で書いて記録する。「対象」に書く日付は起点と終点の2つだけとし、その間を期間の区切り(〜、~、-、から)でつなぐ。2つの日付を別の文脈で含むだけの記録は対応づけない。判定者の記名(名簿の人。AI の名義でない)と、判定の結果(通過 / 差し戻し)も確かめる。結果が差し戻しの記録は、期間の開示を受容していないものとして欠落にする。記録が無い、異議の欄が空欄、事項に当たるのに理由が無い場合も、記載の欠落としてジョブが失敗する。記録を書いた後に、同じ期間で集約し直す
• 期間は、コミットの日付(committer date)を手元の時刻帯の日付に直して切る。切り方は開示に書く。ワークフローの実行環境の時刻帯は UTC である
• 定期の実行はワークフロー assurance-period(既定は月次。前月の1日から末日)。期間は事後の抜き取りの周期に合わせて改める
• 期間の開示は、委任を使っている構成(委任の席、または承認済みの委任の規則がある構成)に限り出す。起点の時点・期間中・現在の構成のいずれにも無く、期間中にトレーラ Delegated を持つコミットも無い場合は、「委任を使っていないため、期間の開示は要らない」と出して成功で終える(scripts/gate/period-needed.mjs)
• このワークフローは、2026-10-01 時点で、実際の GitHub 上で実行して確かめていません。確かめたのは、手元での集約までです
• 抜き取りの数と頻度が第8章を満たすかは、機械では判定しません

出荷判定の証跡の集約が確かめる範囲

scripts/gate/aggregate-evidence.mjs(ワークフロー ship-evidence)は、記録と基準を突合します。品質レポートの冒頭の「G-7 の基準ごとの確認範囲」に、基準1〜9 のそれぞれについて、機械が確かめた結果か、「機械では確かめていない。出荷判定者が次の記録と突合する」かを出します。

変更ごとの扱い:

• PR の記録は gh で引く。リポジトリは --repo <owner/name>、環境変数 GITHUB_REPOSITORY(CI)、git remote の GitHub の URL の順に決める。手元で決まらない場合は、その旨を欠落として出す(このとき、件名に PR の番号を持つコミットはすべて PR を経ていないコミットとして数えられる)
• PR の変更として数えるのは、PR のマージコミット(GitHub の mergeCommit)と一致するコミットだけ。件名に (#N) があっても、一致しないコミット(main へ直接入れたコミット、git revert の既定の件名など)は PR を経ていないコミットとして扱う。マージコミットを取得できない PR の番号を持つコミットも同じ。件名に番号を持たないコミットは、GitHub にコミットと PR の関係を問い合わせる
• マージの方式: スカッシュとマージコミットは扱える(マージコミットの方式では、取り込んだコミットを PR の構成要素として数えない)。リベースは、マージコミットから第1の親をたどり、PR のコミットと件名・作成日時が順に一致する場合に限り、1件の PR として数える。一致しない場合は、PR を経ていないコミットとして扱う(安全側)。実際の GitHub 上では確かめていない
• 独立した人の確認に数えるのは、第4章 G-6 の4条件(名簿の人・作成を指示した者でない・構成上 G-6 が成立・承認した者自身の挙動要約)を満たす承認だけ。承認はレビュアごとの最後の状態で数える。G-6 の判定記録(「対象」が当該の変更、結果が通過。確定の形態が「委任」の記録を除く)も承認に数える
• G-6 を適用する体制では、独立した人の確認を経ておらず、G-6 を事後へ移した変更でもない変更は、記録の欠落(PR を経ていないコミットを含む)。技術負債台帳の区分「例外」の行(対象・状態・承認した者・理由・期限)が対応づけば欠落にせず、未回収の例外として項目5 へ出す。G-6 が未達の体制では件数として開示し、R1 の変更だけ例外承認を要する
• 構成の初期化(process.config.json が設定済みになったコミット)より前の履歴(pre-init)は、変更の件数に数えず、欠落にもしない。ただし、製品のコード(記録の置き場の外)を変えたコミットは、件数を保証の開示の項目1・5 に出し、品質レポートに一覧を出す。テンプレート由来の初期コミット(親を持たず、テンプレートのファイルだけを持つコミット)は一覧から除き、件数だけを出す。初期化より前のコミットは、独立した人の確認・リスク区分・検証の記載を確かめない。/process-init のコミット自身は対象(トレーラ Risk・Verification を書く)
• 構成の整合(要約値の連鎖、回答と名簿の矛盾など)を集約の時点でも確かめ、不整合を欠落にする。PR を経ない体制で、手での書き換えを出荷までに検出するため。要約値ごと書き換えた偽造は検出できない
• 出荷の範囲の PR(またはリリース)に未解除の停止の申し立て(state:stop-requested)があれば、集約を失敗させる(保留)。解くのは解除の記録だけ。AI の担い手の自律実行の停止は機械では止めない(指示文)
• 組織の外へ渡す開示(assurance-disclosure.external.md)には、人の氏名・アカウントと、自由記述(変化点の概要、台帳の内容、一時緩和の理由、宣言と実態のずれ)を出さない。席の名前と件数で示す

導入前の検証(採用を判断する前)

採用の判断の時点の証拠は、採用者が自分のリポジトリで行う導入前の検証の記録です(標準 附属書I I.11)。

node scripts/gate/adoption-trial.mjs init      # 合否の基準の様式を docs/adoption-trial/criteria.md へ写す。採用者が書いてコミットする
node scripts/gate/adoption-trial.mjs seal --manifest <リポジトリの外の注入の記録>    # 目隠しの欠陥注入を封じる
node scripts/gate/adoption-trial.mjs tally --manifest <同>                           # 見つける者の記録(コミット済み)と突き合わせ、docs/adoption-trial/seeded-errors.json へ(コミットする)
node scripts/gate/adoption-trial.mjs env-check --by <氏名>   # 実環境の統制(ルールセットの適用・PR のレビューの取得・ship-evidence の成果物)を、採用者のリポジトリの実環境の gh で読み、docs/adoption-trial/env-check.json へ(コミットする)
node scripts/gate/adoption-trial.mjs run       # 場面集11件(一時の複製)・実環境の統制の記録・演習の記録・成立判定 → docs/adoption-trial/record-<日時(秒まで)>.md
node scripts/gate/adoption-trial.mjs verify <記録>   # 記録の末尾の要約値を再計算し、人が書く欄の外が書き換えられていないことを確かめる

• 合否の基準がコミットされていない、記入日時がコミットより後、コミットの後に書き換えた場合は、run は実行しない
• 実環境の統制の確認(要件⑦)は、場面集とは別の事実。場面集は一時の複製と模擬の gh で止まることを確かめる。実環境でマージを止めるブランチ保護が効いているか、gate-g5 が PR のレビューを読めるか、ship-evidence が成果物を取れるかは、env-check を採用者が実環境の gh で実行して確かめる(読むだけ。GitHub へ書き込まない)。模擬の gh・未認証では各項目が「読めない」と出て、記録の節3・出荷の集約の項目4・/pit に「未確認」が残る(未達のゲートと同じ扱い。消えない)。確認済みの記録も、構成の承認者の数やルールセットが変われば未確認へ戻る。記録には API の応答の識別(ルールセットの id、レビューの id、gate-g5 の実行の id と URL、取得時刻)が入り、識別の無い確認済みは「実環境の証拠を欠く」として未確認に倒れる(査察が GitHub の画面と突合する鍵)
• 場面集は、リポジトリの一時の複製で、実際のゲートの検査(check-pr・aggregate-evidence・generate-profile)に通す。本物の gh は呼ばない
• 製品のコードが無いリポジトリ(このテンプレートそのもの)での記録には「採用者の環境の証拠ではない」と出る。記録は1件の測定(E2)
• 見つける者の誰かが注入した者と同じ層、見つける者の記録がコミットされていない層は、docs/adoption-trial/seeded-errors.json に blind: false と理由だけを書く(出荷の集約は未測定として扱う)。測定の記録は記録の置き場に出るのでコミットする。出荷の集約は docs/adoption-trial/seeded-errors.json を読み、記録の置き場に記録があるとき evidence/seeded-errors.json を読まない(測定時点が新しくても採らない。evidence/ は .gitignore の下にあり、clone した CI の集約に届かない)。method と blind: true の印の無い記録、コミットされていない記録、測定時点が判定の日より後の記録は「出所を検証できない」として数えない。実施日が今日より後の演習は数えない。同じ名前の記録があれば上書きせずに止まる
• G-6 を2名で行う体制(構成 review.reviewerCount が 2)では、人の層を2名で見つける(findings-human.json の finders[] と findings[].by)。検出率は和集合、各人の検出数は参考値。AI の層の記録には測定した担い手の識別(モデル・指示資産の版)が入り、識別が変わると出荷の集約は失効として扱う
• node scripts/gate/org-assurance.mjs を単体で実行すると、層1 の有効性・必須行の空欄・構成と記録から出せる成立条件・組織継続の状態(単一障害点と受容)だけを出す(--json も可。層1 が無効、または D-0 表4 に空欄があれば exit 1)。変更ごとの成立判定は出荷の集約が出す
• verify は記録の全文(節10 の後ろを含む)を対象にし、人が書く欄と要約値の行の値だけを伏せる。節10 の後ろへ所見を書き足した記録は不一致になる。以前の実行の後に基準を改めたかは、runs/ と git の履歴(記録のコミットの時刻)の両方で判定する
• 記録の節0(実施者、下流の指標の基準値、検証の期間の工数の実績、理解の確認の記録、人事評価の規程と様式の写しの所在)と節9 の受容者・期限は、採用者が書く。類型E の結果は、記録の節4 の案内に従って D-0 表7 へ人が転記する
• 記録(docs/adoption-trial/)、演習の報告書(docs/drills/)、退出の予行の記録(docs/exit-rehearsal.json)、層1 の改版(docs/quality-assurance-policy.md)は記録だけのコミットとしてコミットする(出荷の集約の記録の置き場)。評価用の基準集合は評価の入力であり、PR で入れる

このテンプレートが持っているもの

.
├── PROCESS-PROFILE.md      人が読むプロセス構成書(/process-init が生成)
├── process.config.json     機械が読むプロセス構成
├── CLAUDE.md / AGENTS.md   恒久層コンテキストの入口
├── .claude/
│   ├── settings.json       強制層。コマンドの許可・確認・拒否の一覧と、フックの登録
│   ├── hooks/              書き込みの遮断(強制層・自己修正のロック中のテスト)
│   └── skills/             入口の /pit + 作業スキル8種 + graft(コード探索)
├── .github/
│   ├── workflows/          gate-g5 / gate-entry / ship-evidence / ai-review ほか
│   ├── rulesets/           ブランチ保護(プロファイル別)
│   └── PULL_REQUEST_TEMPLATE.md
├── adapters/               言語ごとの検査コマンド(node / python / go / none)
├── scripts/gate/           ゲートの実装(Node 22、依存パッケージなし)
├── templates/              成果物テンプレート12種
├── context/                恒久層コンテキスト(用語集・判断記録・設計標準)
├── specs/                  機能仕様(F-NNN)
└── docs/gates/             ゲート判定記録

コードの探索は graft を通す

graft がリポジトリを tree-sitter で解析し、シンボルと呼び出し関係のグラフを /graft/ に置きます。エージェントは grep や全文 Read の前に、ask / grep / callers / skeleton / blast / map でグラフを引きます。LLM も API キーも使わず、費用はかかりません。

hook・statusLine・.mcp.json は入れていません。graft init は hook と statusLine を .claude/settings.json に、MCP サーバーを .mcp.json に書き込みます。既定では ~/.claude/settings.json と ~/.claude.json にも書いて、その端末で開く全リポジトリへ波及させます。そのため graft init は実行しません。MCP で使いたい人は、各自の local scope に登録します(手順は SKILL.md)。

版は 0.12.1 に固定しています。0.13.0 以降は、C のビルド環境が無い Windows 端末で起動できないためです(trailhq/Graft#323)。

graft は匿名の利用統計を送ります。止めるときは npx -y @nanonets/graft@0.12.1 telemetry disable を実行するか、環境変数 DO_NOT_TRACK=1 を設定してください(端末単位の設定で、リポジトリには含まれません)。

言語に依存しません

CI が固定するのはゲート契約だけです。

• 必須ステータスチェックの名前は gate-g5
• 出荷判定の証跡は evidence/evidence.json のキー構造

実際に走るテスト・静的解析・ライセンス検査のコマンドは adapters/<stack>.json から差し込みます。同梱するアダプタは node / python / go / none の4種です。プロセスの骨格が言語に汚染されません。

ゲートのスクリプトは Node 22 の標準機能だけで動きます。依存パッケージのインストールは要りません。

8つのゲート

G-4 と G-5 はどの構成でも省略できません。それ以外は事業ステージ・規模に応じて簡略化または省略されます。省略した項目は PROCESS-PROFILE.md に理由つきで残ります。

1人で開発する場合

1人 + AI エージェントという構成も想定しています。ただし正直に書きます。

独立レビュー(G-6)だけは、AI で埋められません。

標準は「AI の確認を、独立した人の確認に数えない」と規定しています。独立は責任者(人)の単位で定義するためです。責任者が同一人物なら、AI を何体に分けても、モデルの系統を変えても、独立は成立しません。AI を担い手に置いて得られるのは、文脈と入力の分離までです。生成物の確認を生成器へ委ねる構成は、自動化バイアスによって見落としを増やす方向に働きます。

G-6 の判定基準5項目のうち、4項目は開発者(検証)として自分で実行できます。埋まらないのは「作成を指示した本人でない」の1項目だけです。作成時に抱えた思い込みを、抱えていない人が見ること。1人ではこれが成立しません。

2人の体制では、作成を指示していない側の人が確認すれば G-6 は成立します。相手も作成の指示に関与した変更と、1人の体制では、確認者を外部に置きます。

置けない場合、このテンプレートは G-6 を**省略(omitted)ではなく未達(unmet)**として扱います。独立レビュアの席の責任者が、開発者の席の責任者と同一人物になった場合も、未達として反映します。

未達は消えません。PROCESS-PROFILE.md の冒頭に常時表示され、出荷判定の証跡にも必ず載ります。隠す経路をテンプレートは持っていません。

未達に似ているが違うもの: 代償措置つきの逸脱

出荷判定(G-7)は、1〜2名では価値責任者が兼ねる構成になります。標準は「開発ライン × 出荷判定者」の兼務を禁止していますが、判定と基準の突合は単独でも実行できます。欠けるのは判定者の独立性だけです。

そこでこの構成は未達ではなく、**代償措置つきの逸脱(deviations[])**として扱います。

逸脱も消えません。代償措置(判定記録の必須化、リリース後の抜き取り確認、D-0 への明記)を満たすことが運用の条件で、体制が3名以上になるまで表示され続けます。根拠は標準の第3章 3.5.2 と ADR-0029 です。

1人で全部の席の責任者を兼ねると、「AI 維持管理者 × AI 運用担当者」の兼務禁止も成立しません。1〜2名の体制では、これを拒否せず、逸脱として記録し、表示し続けます(標準 第3章 3.5)。代償措置は定められていません。G-7 の例外をこの組へ広げたものではありません。3名以上の体制では、この兼務は拒否されます。

未達を埋める方法

標準が認めるのは、作成を指示した本人以外の人による確認だけです。確認者を人の名簿(people[]。外部の人は external: true)へ記入し、独立レビュアの席の責任者にします。決まるまでのあいだは、調達先を node scripts/init/set-review-sourcing.mjs --gate g6 --sourcing "<調達先>" で記入してください(process.config.json を手で編集しません。記入は変化点の記録へ残ります)。

• 2人の体制では、作成を指示していない側の人が確認する。回答 q-external-reviewer を「確認者あり」へ改め、独立レビュアの席の責任者を相手にする(席を書き換えるだけでは、未達のまま残る)
• リポジトリを公開し、コミュニティのレビューを受ける
• 他の個人開発者と相互レビューの取り決めをする
• 有償のコードレビューを利用する
• 確認者を置けたら /process-change で体制の変化点として反映する

埋まらないまま進める場合

軸A の「事後監査への切替」が使えます。判定を消すのではなく、リリース前からリリース後の抜き取りへ時点を移す調整です。これは、委任(標準 第5章 5.5.4)を 1〜2名の体制へ適用したものです。対象にできるのは、標準変更カタログへ登録した変更種別(依存パッチ・表示文言・スタイル・既定値内の設定変更)に当たる変更に限られ、委任の7条件をすべて満たす必要があります。

1. 案件の安全重要度が CL0 で、規制業に該当しない
2. 変更がリスク区分 R3 で、登録した変更種別に当たる。該当は機械の規則で判定する
3. 自動検査(G-5)が全項目を通過し、変更箇所の挙動を既存のテストで検出できる
4. 単独で取り消せる。かつ取り消しの手順を実行した実績がある
5. 確約範囲とコア指定に触れない
6. 独立レビュアの席の責任者が、事後に抜き取りで確かめる。逸脱を検知したら協働へ引き下げる
7. 人の事前確認を経ていない変更(G-6 の判定を事後へ移した変更)として、変更単位で識別できる(コミットのトレーラ Delegated:)

7条件の前に、登録の前提があります(標準 第5章 5.5.4)。変更種別を標準変更カタログへ登録するときは、種別ごとに次の3点を記録します。3点の記録が無い種別は登録できません(/process-change が拒否します)。

機械が確かめるのは記入の有無だけです。内容が根拠として足りるかは、登録する者(B-4、または D-0 表1「体制と運用形態」の決定者)が判定します。連続運用の期間は根拠になりません。

切り替えても未達は解けません。1人の体制では、抜き取るのは責任者本人です。本人による抜き取りは、独立した確認に数えません。その旨が出荷判定の証跡(保証の開示)へ出ます。

ai-review ワークフローを同梱していますが、独立レビュー(G-6)の代替ではありません。

• PR へコメントするだけ。承認(approve)は行わない
• 必須ステータスチェックにしない。合否条件にすると自動化バイアスを招くため
• 出力は検出の層であり、監査の入力として使える。判定そのものには数えない
• レビューへ渡すのは仕様・受入基準・差分とする。作成側の説明文を、判断の前に渡さない(入力の分離)
• 記録には「AI レビュー通過」ではなく、指摘の内容と採否を残す

テンプレート更新時の既存案件への影響と運用ルール

本テンプレートリポジトリ（pit-in-template）の様式（templates/*.md）やスクリプトは、日々標準（Process Compass）の進歩に合わせてアップデートされます。

1. 既に初期化済みの既存案件への追随について

• 自動追従は行われません。/process-init で生成・複製された案件側の templates/ や .claude/ の各設定ファイルは、本テンプレートを更新しても自動的には反映されません。
• 既存案件に最新の様式や検証ルールを取り込むかどうか、どのタイミングでどこまで取り込むかは**各案件（プロジェクト）の技術判断（G-3/例外承認等）**に委ねられます。
• この取り込み判断そのものを、必ず ADR（判断記録） または PROCESS-PROFILE.md の「標準からの差分」に記録するよう促してください。

2. 既に記入・完了された判定記録の扱い（遡及改変の禁止）

最新のテンプレート様式を取り込む際、以下の運用規律を厳格に順守してください。

• 過去の判定の痕跡を消さない:
  • 旧様式（例：CL記号体系を用いたテンプレ9など）で既に記入され「通過」した過去の判定記録について、最新様式（ISO 12100準拠等）へ遡って書き換えることは厳禁です。修正は「次回の見直しタイミング」で行ってください。
  • 単一値で書かれた既存の ADR も同様にそのまま残し、次回の決定から新しい様式（幅表記など）を適用してください。
• 過去の欠落を捏造（埋め戻し）しない:
  • 旧テンプレートに「決断の記録」欄がなかったため、過去の G-8・例外承認などに記録が残っていない場合、それを「あったこと」にするために埋め戻しを行ってはなりません。
  • ADR-0028 に従い、**「未達」**としてそのまま記録してください。
  • 注意: これは案件開発チームの落ち度ではなく、配布していたテンプレート（正本側）の様式に不備があったためです。「標準に従っていなかった」ではなく、「当時のテンプレート様式に欠落があったため、誠実に未達として処理した」と扱ってください。

関連

• 📖 ピットイン方式とは — AI が実装する時代の開発プロセスを、一枚の図で理解する — 全体像の概要(Zenn)
• ピットイン方式 標準本文
• テーラリング(第8章)
• CI/CD ゲート構成
• Process Compass リポジトリ

ライセンス

• ドキュメント(*.md、templates/): CC-BY-4.0
• コード(scripts/、.github/、設定ファイル): MIT

このテンプレートから作ったリポジトリのライセンスは、あなたが自由に決められます。