Warestack
Warestack · コーディング · 生産性向上
WarestackはGitHubにデリバリーガバナンスを足すツールだ。プルリクエストとデプロイをチームの文書化された基準と照合し、抜けを現場でそのまま知らせる。
Warestack について
About
Warestackとは
多くのチームはデリバリーのルールをwikiに置き、レビューする人の記憶に頼っている。Warestackはそのルールを、GitHubプルリクエスト上で走るチェックに変える。承認の欠落、ひも付いていない作業項目、ロールバック手順のないマイグレーション、変更可能時間外のマージを見つけ、結果をGitHubのチェックとして書き出す。コメントには何が見つかったかと次の一手が出る。
守備範囲はわざと狭い。Warestackはコードを読まない。見るのは変更がどう届けられたか、誰が承認したか、何にひも付いているか、根拠が残っているかだ。チェックは決定論的に動き、マージの経路に言語モデルは置かないと提供元は明言している。ボタンの近くにボットを置けと言われたときに効く話である。
同じルールが、人が開いたプルリクエストにもAIコーディングエージェントが開いたものにも適用される。承認ルールは人間だけを数えるので、ボットが自分の仕事を承認しても条件は満たせない。制約は対応範囲にある。WarestackはGitHubから始まり、Slack、Linear、Jiraは後からつなぐ形なので、GitLabやBitbucketのチームはまだ使えない。
導入の流れ
- 組織の管理者権限でGitHub MarketplaceからWarestackを入れ、試験用に1〜3個のリポジトリを選ぶ。
- カタログのルールをいくつかレポートモードで有効にする。基準の文書を普通の言葉で貼り付け、各ルールが何を読むかを確認してもよい。
- Slack、Linear、Jiraのいずれかをつなぎ、指摘が担当者の付いたライブカードとして届くようにする。チェックのタブに埋もれさせない。
- 2〜3週間レポートを見たあと、シグナルがきれいだったリポジトリでブランチ保護にWarestackのチェックを要求する。
AIツール情報
Warestackの料金、対応プラットフォーム、性能を簡単に確認できます。
こんな人におすすめ
このツールが最も力を発揮するユーザー、タスク、シーン。
ユーザー
- デリバリー基準を文書で持っているのに守られているか見えないエンジニアリングマネージャー。レポートがリポジトリ単位の景色を、表計算なしで出す。
- 共用リポジトリを預かるプラットフォーム担当やDevOps。ルールを1本のパスに絞れば、マイグレーションの方針を必要な場所だけで動かせる。
- 監査を控えたセキュリティ担当やコンプライアンス担当。評価した変更ごとに承認者、チェック、ひも付いた課題、デプロイの詳細が1件の記録に残る。
タスク
- ブランチ接頭辞ごとに承認を要求する。本番ブランチには独立した承認者を付け、機能ブランチは開いたままにできる。
- 作業項目のないプルリクエストを見つける。ブランチ名のチケット番号は候補でしかなく、証拠にはならない。チェックは先にLinearやJiraで照合する。
- 止まったレビューを動かす。チェーンが依頼したレビュアーに声をかけ、次に担当者、誰も出なければSlackへエスカレーションする。
- 変更管理の証拠をそろえる。記録を普通の言葉で問い合わせ、行を開いて確認し、監査人向けにCSVで出す。
シーン
- コーディングエージェントを入れ始め、レビュアーが読み切れない数のプルリクエストが来るチーム。エージェントの変更も人間と同じ承認とひも付けのルールを通る。
- 誰が何を承認したかの抽出可能な記録を求められるSOC 2やVantaの監査。記録は変更ごとに残り、保存期間は契約に従う。
- 全社展開の前の試験導入。数個のリポジトリで4週間レポートモードを回し、そのあとマージブロックを入れるか決める。
主な機能
普通の言葉で書くルールと、名前の付いた根拠
基準を書くと、Warestackが確認のために何を読むかを示す。変更されたパス、プルリクエストの本文、レビュー、ひも付いた作業項目のいずれかだ。保存された解釈には版が付き、新しいチェックリストに合わせて解釈し直し、新しい版を採るか前の版を残すかを選べる。根拠が欠けていれば、支えられない合格ではなく「未評価」を返す。
リポジトリの指示がルールブックになる
ルールはCLAUDE.md、Cursorのルール、リポジトリ内の指定ポリシーファイルを指せる。評価のたびにプルリクエストの基準リビジョン時点のファイルを読むので、その変更に効いていた方針どおりにチェックが動く。エージェントだらけのリポジトリを扱いやすくするのはこの部分だ。コーディングツール向けに書いた指示が、そのまま守るべき対象になる。
指摘に手を動かすチェーン
ルールはマーク、アクション、ブロックの3段階で動く。真ん中のモードでは、チェーンが指摘を受け取って何かをする。Slackにライブカードを開く、レビュアーに声をかける、反応がなければ担当者に知らせる、Linearの課題に書き込む。経路は一度組めば、印を付いたプルリクエストすべてで同じように動く。
フォルダ単位まで絞れる適用範囲
ルールはチーム、リポジトリ、リポジトリ内のパスのいずれかで有効にする。ロールバック手順のルールはcontrol-plane/db/migrations/だけで走らせ、財務承認のルールは請求サービスだけに置ける。新しいリポジトリは作られた時点でチームのルールを引き継ぐので、一覧を手で足す手間が消える。
別スイッチとしてのマージブロック
まずルールが報告する。マージのブロックはリポジトリごとの設定で、GitHubのブランチ保護にWarestackのチェックを要求するまで切ったままだ。決めるのは提供元ではなく自分たちである。この順番があるから試験導入が現実的になる。数週間は指摘を眺め、そのあとで一部を本当の関所にできる。
レポート、デプロイ記録、監査の痕跡
普通の言葉で質問し、答えの後ろの行を開き、CSVに書き出し、Slackやメールへの定期配信を組める。デプロイレビューと本番デプロイには専用のルールと記録があり、マージ済みのプルリクエストまでたどれる。同じコンソールがMCPサーバーも公開しているので、Cursor、Claude、Codexは作業中にライブのスペースを読める。
メリットとデメリット
メリット
- マージの経路にモデルを置かない決定論的なチェックは、リスクを点数化するAIレビューよりセキュリティ担当への説明がしやすい。
- 最初がレポートモードなので、ブロックしたマージをめぐって議論になる前にプルリクエストコンプライアンスが上がる。
- 人間もエージェントも同じ基準で扱われ、ボットの承認は人間の承認として数えない。
- パス単位の適用範囲により、1本のルールが組織の全リポジトリに広がらない。
- 無料プランは5リポジトリまで使用料なしで使え、実際の仕事で試すには足りる。
デメリット
- 対応するコードホストはGitHubだけで、GitLabやBitbucketのチームは今のところ対象外だ。
- Proは1スペース月49ドルの予定表示のままで、条件が確定するまで予算を組みにくい。
- コードは読まないので、正しさと設計の確認には人間のレビュアーか別のAIレビュー製品が要る。
- 導入には組織の管理者権限を持つ人と、実際に書き下ろされた基準の文書が前提になる。
よくある質問
コードの中身ではなく、変更がどう届けられたかを見る。よくあるルールは、承認の欠落、ひも付いていない作業項目、大きすぎるプルリクエスト、数日前に依頼されたままのレビュー、ロールバック手順のないマイグレーション、許可時間外のマージを探す。
関連コンテンツ
Warestackに関連するツール、スキル、記事を探す。
Warestackの代替ツール
Base Code
Base44 (Wix) · コーディング · 生産性向上Base CodeはBase44の共有クラウド開発環境だ。既存のGitHubリポジトリに対する変更をチャットで伝え、プレビューで確認し、プルリクエストとして返せる。
Google EmbeddingGemma 2
Google DeepMind · ライティング · 画像 · コーディングGoogle EmbeddingGemma 2 は 7 億 4000 万パラメータのオープンなモデルで、テキスト、コード、画像、音声、動画フレームを同じ 768 次元空間のベクトルに変え、スマートフォンやノート PC 上で動く。
GitGlow
GitGlow · コーディング · 生産性向上GitGlow は自分のコードと AI エージェントの変更を一つのレビューにまとめるデスクトップ Git クライアントだ。出荷前に、マシンから何が出ていくのかを確かめられる。