第6章 §1

ai-workspace-standards のローカルインストールとプロジェクトスキャフォールディング

ワークスペースをローカルにセットアップし、既存のvariant(バリアント)でプロジェクトをスキャフォールディングする方法を扱うリファレンス  |  公式ドキュメント: ai-workspace-standards

対象リポジトリai-workspace-standards
対象ブランチmain
参照ドキュメントURLgithub.com/5throck/ai-workspace-standards
資料収集日2026-07-14
バージョン確認方法git --version、bun --versionでローカルツールのバージョンを確認する。ワークスペース自体はtemplates/VERSIONと各variant(バリアント)のtemplate-vX.Y.Zタグでバージョンを管理する。
改訂時の確認事項リポジトリのCONSTITUTION.md、scripts/new-project.ts、scripts/list-template-versions.tsが変更されていないか、元のリポジトリで再確認する。

全体構成の概要

ai-workspace-standards/                (ワークスペースルートとしてクローン)
├── CONSTITUTION.md                    共有標準 — 最初に読むべきファイル
├── CLAUDE.md / GEMINI.md / AGENTS.md  プラットフォーム別の動作・エージェントロスター
├── templates/                         variant(プロジェクトテンプレート)の集合
│   ├── co-develop/                    ソフトウェア開発6段階パイプライン
│   ├── co-design/                     UI/UX 5段階ワークフロー
│   ├── co-work/                       一般協業/ドキュメント6段階ワークフロー
│   └── ...                            co-security、co-consult、co-deckなど
├── scripts/                           new-project.tsなどの運用スクリプト(TypeScript、bunで実行)
└── Projects/                          <プロジェクト名>/形式の個別プロジェクト(それぞれ独立したgitリポジトリ)

Variant全11種類の一覧

Variant目的
co-abapSAP ABAP開発 — ABAPベースのエンタープライズアプリケーション開発
co-work一般協業/ドキュメント — 共通の非同期ワークフロー
co-consult戦略コンサルティング — 顧客課題の診断と提案書作成
co-deck betaプレゼンテーション — リサーチから印刷用PDFまでの11段階パイプライン
co-developソフトウェア開発 — 6段階開発パイプライン
co-designUI/UXデザイン — 反復的なデザインワークフロー
co-securityセキュリティレビュー — レッドチーム/侵入テストワークフロー
co-gameゲーム開発 — Vanilla TypeScriptによるHTML5 Canvasゲーム
co-export beta輸出入貿易コンサルティング
co-hr beta人事・労務関係 — 労働法コンプライアンス、HRM/HRD、組織設計コンサルティング
co-news beta上場企業を対象とする経済・金融ジャーナリズム — 国プロフィル(KR)ベースの開示・商法リサーチ

リポジトリ構成の見取り図 — clone後に最初に確認すべき5箇所

git cloneでワークスペースルートにリポジトリを複製した後、最初に確認すべき中核ディレクトリ5箇所を順番に見ていく。この順序は第5章で扱った「ランタイムフロー」と一致する。

  1. CONSTITUTION.md — 最初に読むべきファイル。ワークスペース全体の共有標準(ガバナンス、PRワークフロー、マルチエージェント原則)が定義されている。
  2. CLAUDE.md / GEMINI.md — 使用しているAIコーディングツールに対応するファイルを確認する。プラットフォームごとの動作方式(フック、スラッシュコマンド、エージェントディスパッチルール)が定義されている。
  3. AGENTS.md — このワークスペースで呼び出し可能なエージェントロスター。「誰がどの役割を担うか」を一目で確認できる。
  4. templates/ — 利用可能なvariant全11種類がこのディレクトリの下にある。各variantフォルダを開き、エージェント構成とガバナンスパイプラインを確認する。
  5. scripts/ — new-project.tsがここにある。このスクリプトがvariant(バリアント)を実際のプロジェクトとして複製する中核コマンドである。
この見取り図は、第4章の実習でエージェントに実際に触れる前に、「このリポジトリに何が入っているのか」の感覚をつかむための短い案内である。実習の際はまずこの5箇所だけを開いてみて、残りの構成は必要になったときに随時戻って確認する進め方でよい。

1. ローカル環境の準備

git clone。ワークスペースルートへクローン

ai-workspace-standardsは、一般的なライブラリのようにプロジェクトの中に組み込むのではなく、ワークスペース自体のルートとしてクローンして使うように設計されている。例えばWindowsではC:\git、macOS/Linuxでは~/gitのような場所にこのリポジトリをクローンすると、その配下に作るすべてのプロジェクトがCONSTITUTION.mdの共有ルールを自動的に継承する。

もしこのルールを無視して、特定のプロジェクトフォルダの中に(例:my-project/ai-workspace-standards/のように)サブモジュールとして組み込んでしまったらどうなるだろうか。new-project.tsのようなスクリプトは「ワークスペースルートから実行されたか」を自ら確認するが、この前提が崩れるためスキャフォールディング自体が拒否されたり、パス計算がずれて見当違いの場所にプロジェクトが生成されたりする。さらに、そのプロジェクトだけが共有ルールを継承し、後で作る他のプロジェクトは一切ルールを共有できなくなるため、そもそも「ワークスペース全体が同じ標準を使う」というこのリポジトリの存在意義自体が崩れてしまう。

git clone https://github.com/5throck/ai-workspace-standards.git C:\git
cd C:\git

bun。ランタイムのインストール

ワークスペースのすべての運用スクリプト(scripts/*.ts)はTypeScriptで書かれており、bunで実行する。別途.sh/.ps1版は存在しないため、bunのインストールを先に済ませておかないとスクリプトを実行できない。

bun --version
git --version

💡 要点: 両方のコマンドが正常にバージョンを出力すれば、ローカル環境の準備は完了である。

セッション開始チェックリスト

CONSTITUTION.mdが定めるセッション開始チェックリストは、次の順序に従う。

  1. gitフックのパス設定: git config core.hooksPath .githooks
  2. CONSTITUTION.mdを読む: ワークスペースの共有標準を確認する
  3. プロジェクトのdocs/context.mdを読む: プロジェクト設定を確認する
  4. AGENTS.mdを読む: 該当プロジェクトのエージェントロスターを確認する
  5. memory/YYYY-MM-DD.mdを確認: 前回のセッションで残されたコンテキストを確認する
  6. docs/context.mdが指定するskillをロードする

2. プロジェクトスキャフォールディングコマンド

bun scripts/list-template-versions.ts。利用可能なvariantの確認

新しいプロジェクトを作る前に、ワークスペースにどのvariantがあり、それぞれどのバージョンがタグ付けされているかをまず確認する。

bun scripts/list-template-versions.ts

bun scripts/new-project.ts。既存のvariant(バリアント)からプロジェクトを生成

最もよく使うコマンドである。variantを一つ選び、プロジェクト名とともに実行すると、templates/<variant>/の全構成(エージェント定義、スキル、コマンド、ガバナンスパイプライン)が新しい独立リポジトリとして複製される。

bun scripts/new-project.ts "my-project-name" --variant co-develop

特定のバージョンを固定してスキャフォールディングしたい場合は、--versionを併せて指定する。

bun scripts/new-project.ts "my-project-name" --variant co-develop --version 1.4.0
オプション説明備考
--variant 使用するプロジェクトテンプレート(co-develop、co-design、co-workなど)を指定する 省略した場合は対話形式で選択するか、デフォルト値を使用する(スクリプトの動作による)
--version 該当variant(バリアント)の特定のtemplate-vX.Y.Zタグを固定して使用する 省略すると最新バージョンを使用する

スキャフォールディング 独立gitリポジトリ 共有標準の継承

スキャフォールディングされたプロジェクトは、ワークスペースルートとは別の独立したgitリポジトリとして生成される。ワークスペースルートのファイルと新規プロジェクトのファイルを同じ作業/コミットで混在させて修正しないよう注意する。

新規variant(バリアント)を自分で作りたい場合

既存のvariantでは不十分で、まったく新しいドメインチーム構成が必要な場合は、create-variantスキルとbun scripts/create-l3-scaffold.ts <variant-name> --domain <type>コマンドを使って、Projects/<variant-name>/の下に独立したPhase Aプロトタイプをまず作成できる。このプロトタイプは、正式なtemplates/のvariant(バリアント)へ昇格(promote)されるまで自由に発展させることができる。この流れの詳細な手順と昇格手順については、第11章(新規作成D-1)と第12章(昇格P-1)で扱う。

3. 参考リンク

ai-workspace-standards mainブランチ基準 | 2026年7月