vibecode-pro-max-kit：AI コーディングに仕様、記憶、マルチ Agent 協作を足す

AI コーディングで錯覚しやすいのは、最初の一手が速すぎることです。「webhook を追加して」と頼むと、Agent は数百行のコードをすぐ書けます。「ログインページを作って」と言えば、コンポーネントもすぐ並びます。問題は翌日に出ます。既存の認証パターンを忘れる。前回あるライブラリを却下した理由を忘れる。プロダクト、開発、責任者が同じ計画を見て確認できる成果物も残らない。

vibecode-pro-max-kit は、この不足を埋めるためのツールです。Claude Code や Codex などの AI coding agent の周りに、研究、案比較、計画、実行、テスト、レビュー、プロジェクト記憶の更新を追加します。新しいモデルや単発プロンプトというより、リポジトリに入れる spec-driven harness に近い存在です。

要点

• 長期運用、複数人レビュー、複雑な変更、Agent が文脈を失いやすいプロジェクトに向きます。
• 使い捨てスクリプト、小さな修正、すでに成熟した工程管理を持つチームには重い場合があります。
• README の導入方法はリモート shell コマンドです。初回は fork、実験ブランチ、プロジェクト副本で試してください。
• agents / skills の数は README 内でも表示差があります。導入前に現在のツリーを確認します。
• 価値の中心は、AI 作業の仕様、計画、証拠、文脈、レビュー記録を残すことです。

何がプロジェクトに入るのか

README のインストールコマンドは短いです。

curl -fsSL https://raw.githubusercontent.com/withkynam/vibecode-pro-max-kit/main/install.sh | bash

その後、Claude Code で次を実行します。

Run vc-setup

コマンドは短くても、変更範囲は小さくありません。README のツリーでは、.claude/agents、.claude/skills、.claude/hooks、.codex/agents、CLAUDE.md、AGENTS.md が入り、vc-setup が process/ を作ります。既存の .claude/ と CLAUDE.md はバックアップされますが、プロジェクト全体の開発フローに関わる変更です。

初回は main リポジトリで直接実行しないほうが安全です。プロジェクトをコピーし、クリーンなブランチを作り、install.sh を読み、実行後に完全な diff を確認してから、本体へ戻すか判断します。ファイルを書き、shell を実行し、hooks を入れる AI ツールは、CI スクリプトやコード生成器と同じ目線で審査する必要があります。

仕様駆動でコードの前に止まる

GitHub Spec Kit の説明は背景として分かりやすいです。まず何を作るかを定義し、段階ごとに詳細化し、AI coding agent に構造化された成果物から実装させる。基本の流れは Spec → Plan → Tasks → Implement で、各段階が Markdown artifact を作ります。

Alibaba Cloud - 開発者向けクラウドの第一候補、Lighthouse サーバー15%OFF、プロジェクトの迅速な立ち上げを支援

15%割引を入手 →広告

vibecode-pro-max-kit も近い発想ですが、よりリポジトリ内で継続運用する形です。README では research、innovate、plan、execute、quality pipeline、update process という流れを示します。実行前にプロジェクトと外部案を調べ、2〜3 個の方法を比較し、レビュー可能な plan を書いてから実装へ進みます。実装後は self-review、tester、code reviewer、code simplifier、git manager へつなぎます。

これは、AI がすぐコードを書き始めるチームに効きます。プロダクト担当は plan を見られ、開発者は影響範囲と実装方針を見られ、責任者は検証証拠を見られます。共通認識がチャット履歴ではなく、process/ の成果物として残ります。

プロジェクト記憶をファイルに置く

Agent memory にはブラックボックスに見えるものもあります。何かを覚えていることは分かっても、どこにあり、いつ変わり、どう削除するか分からない。vibecode-pro-max-kit はファイルベースのプロジェクト記憶を採ります。README では process/context/、context groups、feature folders、all-context.md のような router ファイルが説明されています。目的は、知識を領域ごとに整理し、現在のタスクに関係する部分だけを読ませることです。

利点は 2 つあります。まず、人が読めます。ある機能でキューを使った理由、cron を避けた理由、古い権限フィールドを再利用しなかった理由を、completed plans、reports、context ファイルで追えます。次に、Git で管理できます。誤った記憶、修正、ロールバックが履歴になります。

リスクもあります。誤った記憶は積み上がり、古い前提は後続タスクに影響します。README には context audit、update-process-agent、drift signal がありますが、チーム側の定期清掃は必要です。文書が多いほど良いわけではありません。役立つ記憶は、ルーティングでき、監査でき、削除しやすいものです。

マルチ Agent の役割分担

README の agent list には 12 個の役割があります。research、innovate、plan、execute、fast mode、update process に加え、debugger、tester、code reviewer、code simplifier、UI/UX designer、git manager です。見るべき点は、1 つのチャットに押し込みがちな役割を分けていることです。

複雑なタスクなら、まず vc-research-agent がコード事実を集め、vc-plan-agent が plan を書き、vc-execute-agent が plan に沿ってファイルを変更します。テストとレビューは、同じ会話の自己確認ではなく、別の役割とチェックリストで行います。vc-git-manager は touched files から論理的に commit を分け、無関係な変更を混ぜにくくします。

Agent が増えるほど、レビュー負荷も増えます。境界、入力、受け入れ証拠がさらに重要になります。弱い plan を 12 役に渡すと、12 個の読みにくい成果物になるだけです。要件、制約、受け入れ基準を先に固め、その後で並列化や分担を考えます。

セーフティゲートを見る

README で注目したいのは、長時間自律実行の宣伝より構造的な安全策です。privacy guardrails hook は .env、credentials、SSH keys、.pem へのアクセスをブロックします。実装の半分あたりで 50% check-in があり、plan から外れる場合は PLAN に戻ります。高リスク変更には evidence pack が必要です。

Railway - モダンなデプロイプラットフォーム、煩わしい運用から解放、数分で公開

今すぐ始める →広告

これらは、AI コーディングで怖い 2 つの問題を減らします。敏感ファイルを静かに読むこと、承認済み plan から静かに逸れることです。コードレビューや権限分離の代替ではありませんが、失敗を早めに見つけやすくします。

初回の試用タスクは、実務に近く低リスクなものが向きます。

このプロジェクトに読み取り専用のステータスページを追加するため、vibecode フローを使ってください。
まず現在の route、component、deploy 方法を research してください。
2 つの実装案と推奨理由を出してください。
plan を書いたら停止し、承認を待ってから execute に進んでください。
実行後は関連テストだけを走らせ、変更レポートを書いてください。

このタスクなら、harness がプロジェクトを読めるか、段階ごとに止まるか、plan と report が役に立つかを確認できます。データベース、支払い、認証、マイグレーションには触れません。

Spec Kit、Codex Skills、OpenClaw との関係

Spec Kit は、仕様を AI 補助開発の中心に置く SDD ツールキットです。Codex Skills は、SKILL.md、scripts、references、assets で再利用可能なワークフローをまとめる形式です。OpenClaw 系列は、agent の能力、ローカル記憶、ツール呼び出し、マルチ agent ルーティングに重点があります。

vibecode-pro-max-kit は、それらの中間にあります。spec-driven workflow、skills、agents、hooks、context memory、plan lifecycle を組み合わせ、リポジトリへ入れる harness にしています。Claude Code や Codex の周りに工程管理の骨格を足すもの、と考えると分かりやすいです。

すでに Spec Kit を使い、context、planning、review、memory ディレクトリがあるチームなら、全移行より構成の参考にするほうが合うかもしれません。OpenClaw や社内 agent 基盤がある場合は、権限、記憶形式、監査ログを比較してから重ねます。

試用チェックリスト

導入前に、次を確認します。

1. 本番 main ではなく、副本または実験ブランチでインストールする。
2. install.sh を読み、書き込むディレクトリを理解する。
3. インストール後に git diff を見る。特に CLAUDE.md、AGENTS.md、.claude/、.codex/。
4. vc-setup では、空の文脈ではなく、実際の構成、テストコマンド、規約、リスクを書かせる。
5. 最初のタスクは低リスクにし、PLAN から execute へ進む前に停止させる。
6. 実行後、touched files を確認し、無関係な変更を拒否する。
7. 生成された plan、report、context を人が読む成果物として確認する。
8. 1 週間後に context audit を行い、誤りや古い記憶を削除する。

すぐ走らせるより遅く見えますが、流程がレビューしやすくなったのか、単にファイルが増えただけなのかを判断できます。

Vultr - 高性能NVMeクラウドサーバー、世界32拠点、Dockerワンクリック展開対応

価格を見る →広告

維持するリズム

導入後は、最初の plan の見栄えだけで判断しないほうがよいです。3〜5 タスク後に、process/ が再利用できる資産になっているかを見ます。completed plan が意思決定を説明し、report が実際の diff に対応し、context が重複質問を減らし、backlog が忘れられた作業を残しているなら健康です。

毎週 active plans を整理し、大きな機能が merge された後は検証済みの結論だけを process memory に残します。毎月 context groups を見て、古い API、テストコマンド、アーキテクチャ前提を消します。AI 記憶は、完全に見えるのに古くなっている状態が一番危険です。

撤退方法も決めておきます。2 週間試して plan 品質が安定しない、context 維持が重すぎる、hooks が CI と衝突する場合は、有用な文書とルールだけ残して harness を外します。良いプロセスは置き換え可能であるべきです。

向くプロジェクト

このテーマが OpenClaw 実践シリーズに入る理由もここにあります。OpenClaw 型のツールは「Agent が何をできるか」に寄ります。vibecode-pro-max-kit は「Agent が動く前後に何を残すか」に寄ります。

関連して読む

マルチ Agent ルーティングは OpenClaw マルチ Agent ルーティング が参考になります。長期記憶と文脈管理は OpenClaw ローカル記憶システム も近いテーマです。Claude Code の日常フローを固定したい場合は OpenClaw と Claude Code ワークフロー もつながります。

vibecode-pro-max-kit は、AI コーディングを工程として扱うチームに向きます。ディレクトリ、ルール、役割、承認手順は増えます。その代わり、計画、文脈、検証証拠は見えやすくなります。小さなタスクには重く、複雑なプロジェクトでは効く可能性があります。