vibecode-pro-max-kit：AI コーディングに仕様、記憶、マルチエージェント運用を足す
"vibecode-pro-max-kit の GitHub README は、インストールコマンド、non-destructive install の説明、RIPER-5 phases、agents / skills / hooks の数、書き込み先、安全機構の確認に使いました。"
"GitHub Spec Kit ドキュメントは、spec-driven development の Spec、Plan、Tasks、Implement の流れと、マルチエージェント統合の背景確認に使いました。"
"OpenAI Codex Skills ドキュメントは、Codex skills のディレクトリ構造、明示的または暗黙的な呼び出し、任意の scripts、references、assets の確認に使いました。"
AI でコードを書くときに制御を失いやすい場面は、派手なモデルの失敗よりも、たいてい小さな 3 つの問題です。コンテキストが切れる。計画がチャット履歴に散らばる。意思決定の跡が残らない。要件が変わるたびに、プロジェクト全体をもう一度説明することになります。
vibecode-pro-max-kit が解こうとしているのは workflow の問題です。AI coding agent を spec-driven engineering team に近づけます。先に仕様を書き、計画してから実行し、各ステップに監査できる記録を残す。チャット framework ではなく、CI/CD の代替でもありません。役割はもっと狭く、AI コーディングの意思決定を追跡できるようにすることです。
何を解決するのか
コンテキストの流失：長い会話が compaction で切られると、設計判断、境界条件、デバッグの考え方が消えます。次の変更では、もう一度説明するか、AI に推測させることになります。
計画と判断が記録に残らない：チャットから Markdown を書き出しても、構造化された文書にはなりません。チームレビューでは、なぜその案を選んだのか、どの選択肢を除外したのかが見えません。
マルチエージェントの引き継ぎコストが高い：1 つのタスクを複数ステップに分け、それぞれ別の agent に渡しても、引き継ぎは曖昧な自然言語に頼りがちです。誰がどのステップを担当するのか、出力形式は何か、受け入れ基準はどこかを人が見続ける必要があります。
この 3 つが重なると、AI コーディングは毎回最初からやり直す感覚になります。vibecode-pro-max-kit はそれらを 1 つの harness に入れます。spec が先にあり、plan が中央にあり、execution にはチェックポイントがあり、プロセスには記憶があります。
インストール手順と安全監査
インストールコマンド
README で示されているのは、リモート shell インストールです。
curl -fsSL https://raw.githubusercontent.com/withkynam/vibecode-pro-max-kit/main/install.sh | bashインストール後は Claude Code で vc-setup を実行します。Codex ユーザーは README の案内に従い /vc-setup を使います。これにより process/ ディレクトリが作成され、プロジェクト設定が初期化されます。
書き込まれるファイル一覧
現在の README は、このインストールを non-destructive と説明しています。既存の .claude/skills/、.claude/agents/、process/、settings.json を消すのではなく、kit-owned files だけを書き込み、更新します。それでもプロジェクトには次のディレクトリとファイルが置かれます。
| パス | 内容 |
|---|---|
.claude/agents | Claude Code 用 agent 定義。現在の README では 15 個 |
.claude/skills | Claude Code 用 skill 定義。現在の README では 33 個 |
.claude/hooks | ライフサイクル hooks。現在の README では 10 個 |
.codex/agents | Codex 用に mirrored された agents |
.agents/skills | Codex discovery 用に .claude/skills を指す symlink |
CLAUDE.md | Claude Code の orchestrator と routing rules |
AGENTS.md | ツール横断の agent と skill registry |
process/ | 計画ライフサイクルとプロジェクト記憶のディレクトリ |
README ではさらに、既存設定は .vibecode-backup/ にバックアップされ、既存の CLAUDE.md は CLAUDE.md.pre-vibecode として保存されると説明されています。既存の process/ はインストーラーが直接移行せず、vc-setup / vc-update が対話的に扱う形です。
安全監査の要点
本番リポジトリで直接 curl | bash しないでください。README が non-destructive と説明していても、リモート shell スクリプトは監査が必要です。.claude/、.codex/、CLAUDE.md、AGENTS.md など、影響の大きいパスに書き込むためです。
初回は次の流れが安全です。
- 非本番プロジェクトを fork または copy する
- その fork でインストーラーを実行する
git diffで書き込まれたファイルを確認する- 予期しない設定変更がないことを確認してから移行を検討する
バックアップの挙動が自分のリポジトリに合うかは、自分で確認する必要があります。とくに vc- prefix の独自 skill や agent があるプロジェクトでは、README の caveat に従って追加確認してください。
「non-destructive」は「リスクなし」ではありません。既存ディレクトリを消す確率を下げるだけで、サプライチェーン監査、権限分離、ロールバック準備の代わりにはなりません。チームプロジェクトでの最小限の安全策は、スクリプトを読む、コピーで実行する、reviewer に diff を見てもらうことです。
中心概念：spec-driven workflow
Spec Kit の背景
vibecode-pro-max-kit の中心にある考え方は、Spec Kit のような spec-driven development workflow です。流れは単純です。先に仕様を書き、それを計画に落とし、タスクへ分割し、最後に実装します。
各段階は Markdown artifact を生成し、次の段階に構造化されたコンテキストを渡します。
| フェーズ | 入力 | 出力 |
|---|---|---|
| Spec | 要件説明 | 境界、制約、受け入れ基準を含む仕様文書 |
| Plan | 仕様文書 | 手順、担当、依存関係を含む実装計画 |
| Tasks | 実装計画 | 具体的で検証可能なタスクリスト |
| Implement | タスクリスト | コード変更 + プロセス記録 |
この workflow 自体は新しいものではありません。ただし vibecode-pro-max-kit は、それをプロジェクトに組み込みます。agents、skills、hooks がすべてこのプロセスを中心に設計されています。
計画ライフサイクル
現在の README は RIPER-5 plan-first workflow を強調し、7 つの gated phases として説明しています。
| フェーズ | 何をするか | 成果物 |
|---|---|---|
| Research | 背景を集め、境界を確認する | research artifact |
| Spec | ユーザーストーリーと要件境界を書く | spec artifact |
| Innovate | 選択肢を比較し、取捨選択を記録する | alternatives / decision notes |
| Plan | 手順、責任、検証方法を細かくする | plan artifact |
| Validate | 実行前に計画とリスクを検証する | validation notes |
| Execute | タスクを実装し、過程を記録する | code changes + execution notes |
| Update-Process | 記憶を更新し、古い記録を整理する | process / context updates |
各フェーズは、次に進む前に明示的な承認を必要とします。ここが制御点です。人間が方向を確認してから、agent に続行させます。
Agents と skills
README は現在、15 agents、33 skills、10 hooks と書いています。これは 2026 年 6 月 23 日に確認した公式 README の表現であり、永久に固定された値ではありません。
skill の構造は Codex Skills と Claude Code skills に近く、各 skill は instructions 用の SKILL.md を持ち、任意で scripts/、references/、assets/ を含みます。skill は明示的に呼び出すことも、タスクが境界に合うときに暗黙的に使われることもあります。
もう 2 つの概念も重要です。
- context groups：テーマや機能ごとに整理したコンテキストブロック。毎回プロジェクト全体を読ませないための仕組み
- feature folders：機能単位のフォルダ。それぞれに spec と process material を持たせる考え方
安全機構の詳細
README には、注目すべき安全機構と workflow 機構がいくつかあります。
| 仕組み | 役割 | 使われる場面 |
|---|---|---|
| privacy guardrails | 機密情報が process files や output に入るのを防ぐ | agent output と process updates の前 |
| gated phases | agent がいきなりコードへ飛ぶのを止める | Research から Update-Process まで |
| check loops | 実行中に自己確認し、計画へ戻れるようにする | execution と validation |
| deviation protocol | 元の計画から外れた行動を記録する | plan 変更時、または execution がずれたとき |
| high-risk evidence pack | 高リスク判断に追加証拠を求める | しきい値に達したとき |
これらの仕組みは、AI が監督なしに高リスク判断をする可能性を下げます。ただし hooks と設定が正しく動いていることが前提です。hooks が無効化され、権限が広すぎ、チームが process/ を読まない場合、この仕組みは失敗し得ます。
向いている場面の判断表
| 場面 | 向き不向き | 判断理由 |
|---|---|---|
| 長期保守プロジェクト | 向いている | 記憶が process/ に残り、計画を監査できる |
| 複数人レビュー | 向いている | 判断が記録に残り、逸脱を追跡できる |
| 複雑な要件 | 向いている | マルチエージェント協調と段階的な細分化が効く |
| コンテキストを失いやすい | 向いている | spec-driven な構造が会話に形を与える |
| 一度きりのスクリプト | あまり向かない | workflow overhead が大きすぎる |
| 小さな修正 | あまり向かない | harness のコストが変更内容を上回る |
| すでに成熟した工程がある | 慎重に判断 | 既存の CI/CD や review flow と衝突する可能性がある |
| 外部 harness を入れたくない | 向かない | README、AGENTS.md、CLAUDE.md、process files がリポジトリを変える |
判断の中心は、workflow overhead に見合うかどうかです。長期、複雑、複数人協作のプロジェクトでは、overhead が監査性と協調効率に変わります。短期で単純な個人プロジェクトでは、overhead は純粋なコストです。
Spec Kit、Codex Skills、Claude Code との関係
Spec Kit：SDD、つまり spec-driven development の背景とプロセス枠組みを定義します。概念層であり、特定の agent に縛られません。
Codex Skills：OpenAI の skill directory 形式です。SKILL.md + scripts/ + references/ で、instructions、resources、scripts を再利用可能な workflow としてまとめます。
Claude Code skills：構造は似ており、SKILL.md と補助ファイルで構成されます。skill は再利用可能な workflow unit として、明示的または暗黙的に呼び出されます。
vibecode-pro-max-kit：これらの考え方をプロジェクトへインストールします。Spec Kit の代替ではなく、spec-driven workflow を agents、skills、hooks として実行できる形にし、Claude Code と Codex の project configuration に対応します。
移行コストとして、すでに .claude/agents、.claude/skills、CLAUDE.md、AGENTS.md がある場合は diff を確認し、自分たちのカスタム設定が失われていないかを必ず見ます。
初回試用フロー
README の考え方に従うなら、初回は本番外で試します。
ステップ 1：非本番プロジェクトを fork または copy する
main repository で直接作業しません。fork かローカルテストコピーを使います。
ステップ 2：インストールコマンドを実行する
curl -fsSL https://raw.githubusercontent.com/withkynam/vibecode-pro-max-kit/main/install.sh | bashステップ 3：vc-setup を実行する
Claude Code では vc-setup を実行します。Codex では README に従って /vc-setup を使います。これにより process/ が作成され、設定が初期化されます。
ステップ 4：書き込まれたファイルを確認する
git status
git diff .claude/ .codex/ .agents/ CLAUDE.md AGENTS.md process/書き込まれたファイルが想定どおりかを確認します。
ステップ 5：最初の spec-driven workflow を試す
「ログ出力 helper を追加する」のような簡単な依頼を agent に渡します。Research → Spec → Innovate → Plan → Validate → Execute → Update-Process の流れを観察し、各承認ゲートが発火するか確認します。
ステップ 6：結果を検証する
process/ に成果物があり、CLAUDE.md / AGENTS.md の変更が読めて、hooks と agents にエラーがないことを確認します。その後で実プロジェクトへの移行を検討します。
次のステップと関連読み物
公開済みの関連記事：
このシリーズで扱う予定の次のテーマ：
- マルチエージェント協調のトラブルシューティング checklist
- spec-driven project の実践ケーススタディ
vibecode-pro-max-kit を安全に試す 6 ステップ
本番ブランチに影響を与えず、vibecode-pro-max-kit が自分の AI コーディングプロジェクトに合うかを検証します。
⏱️ 目安時間: 1 day
- 1
ステップ 1: プロジェクトコピーを作る
fork、実験ブランチ、ローカルコピーを使います。本番 mainline でリモートインストールスクリプトを直接実行しないでください。 - 2
ステップ 2: インストーラーを監査する
先に `install.sh` を読み、どのディレクトリと設定ファイルを書き込むかを確認します。 - 3
ステップ 3: インストール後に diff を見る
インストール後、`.claude/`、`.codex/`、`CLAUDE.md`、`AGENTS.md`、`.agents/skills`、`process/` の変更を確認します。 - 4
ステップ 4: vc-setup を実行する
実際のプロジェクト構造、テストコマンド、規約、リスクを書かせます。空のプレースホルダーのまま受け入れないでください。 - 5
ステップ 5: 低リスクのタスクを選ぶ
最初は読み取り専用または低リスクの機能にし、PLAN 後に一度停止して確認を待たせます。 - 6
ステップ 6: 成果物をレビューする
plan、report、context、touched files を確認し、レビューしやすさが本当に上がったかを判断します。
FAQ
vibecode-pro-max-kit とは何ですか？
vibecode-pro-max-kit はどう使いますか？
本番リポジトリでいきなりインストーラーを実行してもよいですか？
Spec Kit とはどう関係しますか？
最初に試すならどんなプロジェクトが向いていますか？
誤った記憶はどう消しますか？
6分で読めます · 公開日: 2026年6月5日 · 更新日: 2026年7月14日
OpenClaw シリーズ: インストール、設定、セキュリティ、運用ガイド
検索からこのページに来た場合は、前後の記事もあわせて読むと同じテーマの理解がかなり早く深まります。
コメント
GitHubアカウントでログインしてコメントできます