高度化ロードマップ

これまで§1〜§4で扱ってきたのは、ai-workspace-standardsの現在の実装である。本節はその逆――まだ実装されていないが、リポジトリが向かっている5つの方向を扱う。インフラレベル(コンテナ連携・メモリ集約・variant配布の自動化)の3つと、ガバナンスレベル(ボイラープレート戦略・モデルティア戦略)の2つに分かれる。

コンテナ基盤サービス連携

現在、各バリアント(variant)からスキャフォールディングされたプロジェクトは、ローカルワークスペース内でClaude Code/App、AntigravityといったAIコーディングツールと直接連携する形でのみ動作する。しかし実際の企業環境では、プロジェクト単位で独立したサービスとして配備しなければならない場合が多い。

高度化の核心は、スキャフォールディングされたプロジェクトがDockerまたはKubernetes環境で**Open WebUIのようなフロントエンドサービスと連携し、個人単位でサポートされる**必要があるという点である。各ユーザーが自分に割り当てられたエージェントチームをブラウザインターフェースを通じて呼び出し、結果を確認し、セッション間でコンテキストを維持できる形態である。

メモリの集約と整理

現在、各L3プロジェクトは独立したmemory/YYYY-MM-DD.mdファイルを維持している(第5章§4で扱った)。このファイルは当該プロジェクトのセッション間コンテキストを記録するが、プロジェクトが増えるほどメモリファイルも散在し、ワークスペース全体レベルでのインサイトの把握が難しくなる。

高度化の第2の軸は、個別プロジェクト単位に散らばっているメモリファイルを**集約して整理できる機能**が必要だという点である。例えば「先週すべてのプロジェクトでエージェントチームがどのようなパターンのエラーに頻繁に遭遇したか」「どの役割の組み合わせが最も頻繁に使われたか」といったワークスペースレベルのトレンド分析が可能になるべきである。

variant配布方式の進化

現在のvariant配布はnew-project.tsによるローカルスキャフォールディングが中心であり、テンプレートの更新がL2に自動的に伝播しないフォークモデルに従っている。この方式は意図した差異を保存できるという利点があるが、運用の観点では、テンプレートのバグ修正やセキュリティパッチを各プロジェクトに一つずつ手動で反映しなければならない負担を生む。

高度化の方向としては、(a) フォークモデルの利点を維持しつつ、セキュリティパッチや重要なバグ修正のみを選択的にL2へ伝播できる**同意ベース(consent-based)の受信モデル**、(b) バリアント(variant)を中央レジストリで管理し、new-project.tsがネットワーク経由で最新バージョンを取得する**非同期配布パイプライン**が挙げられる。

上記の3つがインフラレベルの高度化の方向だとすれば、以下の2つはガバナンスレベルの高度化の方向である――§1と§4で扱ったボイラープレート戦略・モデルティア戦略が現在どのような限界を抱えており、どの方向へ洗練され得るかを扱う。

ボイラープレート戦略の高度化

§1・§4では、LOCKED・MERGE・PRESERVE・SYNC_IF_NEWER・PRUNEの5分類を「何を固定し、何を開放しておくか」の判断基準として扱った。現在この分類はupgrade-project.tsのコード内にファイルパス単位でハードコーディングされている――あるファイルがLOCKEDなのかMERGEなのかは、スクリプトを直接書き換えなければ変わらない。この方式はリポジトリが管理するファイルの種類が少ないうちは問題にならないが、組織ごとに「このファイルもLOCKEDとして扱いたい」「このMERGEファイルは我々の組織では完全にPRESERVEに開放したい」といった例外が増えるほど、スクリプト自体をフォークせざるを得ない負担につながる。

高度化の方向は、この分類をコードではなく宣言的なマニフェストに移すことである。例えば、ワークスペースのルートにboilerplate-policy.jsonのようなファイルを置き、各組織が自らのLOCKED/MERGE/PRESERVEの境界をファイルパターン単位で再定義できるようにする方向が議論されている。こうなればupgrade-project.tsはハードコーディングされた分類表の代わりにこのマニフェストを読み込んで動作するようになり、組織はスクリプトに手を加えることなく、自らのセキュリティ・ガバナンス基準に合わせて境界を調整できる。

モデルティア戦略の高度化

§1・§4では、tierの割り当てがagents/*.mdのfrontmatterに静的に固定されており、L0で変更された場合もupgrade-project.tsのSYNC_IF_NEWERを通じてのみ伝播することを見た。この方式の限界は、ティア割り当てが「役割」だけに紐づいており、実際の作業の難易度や組織のコスト予算を反映できないという点である。例えばcode-writerの役割は常にmediumだが、実際にはプロジェクトごとにcode-writerが扱うコードベースの複雑さは大きく異なる。現在の構造では、この違いを反映するには人が直接各プロジェクトのagents/*.mdを手作業で修正しなければならない。

高度化の方向としては、(a) セッションログや/costデータを根拠に「この役割は直近N回のセッションで繰り返しリトライが発生している→highへの引き上げを推奨する」といった運用データに基づくティア推奨、(b) ワークスペース全体または組織単位で「今月の予算はこの程度なので、high ティアの割り当てはN個の役割に制限する」といったティア予算上限ガバナンスが挙げられる。いずれの方向も、現在の「静的割り当て+手動オーバーライド」モデルを維持しながら、その上に可観測性(observability)と組織のポリシーを重ねる拡張である。