メインコンテンツまでスキップ
機能 › 開発の管理メニュー：開発の管理 › レビュー

レビュー

レビューは、AI が作った PR を人が読んで確かめる所です。AI が先に一次の見立てと資料をそろえ、人は判断の要る所だけを読みます。AI の承認は、承認の数に入れません。

画面すること
レビューの机待ちの列から PR を開き、AI の見立てと点検の結果を見て、承認するか直しを頼む
PR のまとめと引き継ぎ一度に出た 100 本ほどの PR を、矛盾と論点を片付けてから固めた束にして渡す
レビューの学び指摘に学びの印を付け、同じ学びが重なったら開発ルールの候補にする

入れる順・担当の範囲・マージの仕方は、PR の地図とマージにあります。

レビューの机​

レビューの机。待ちの列に PR が並び、右に選んだ PR の AI の要約と点検の結果とレビューの資料が出ている
レビューの机。待ちの列と、選んだ PR の見立て画面設計（開発中）・数字は見本
所中身
待ちの列PR ごとの題・セル・関わるページ・CI・担当・待った時間。「自分の受け持ち」「割り当てなし」「全部」で切り替える
頭の数割り当てのない PR・受け持ちの PR・承認待ちの PR・平均の待ち時間
AI の要約何を作ったか、どの決めに合わせたか、仮のままの所はどこか
点検の結果CI・試験・監査・関わるページと画面
レビューの資料開発ルール・マージの手順・使った MCP とスキル・試験の動かし方
  • 承認とマージは GitHub で行います。机の「GitHub で承認」「GitHub で開く」から、その PR へ移ります。
  • 「直しを頼む」を押すと、頼みが連絡箱で元のスレッドへ届きます。T9 や別のスレッドが代わりに直すことはしません（連絡箱）。
  • 画面の試験の結果は、PR の check beesbuild/e2e に書きます。trace と動画は BeesBuild の中だけで開きます。

AI の一次の見立て​

AI が PR を先に読み、要約と指摘を出します。指摘には、関わる開発ルールの id を付けます。

AI の承認は、マージの承認の数に入れません。ただし、AI の一次レビューで重さ「高」の指摘が出た PR は、自動マージの対象から外れます（自動マージの条件）。

開発ルールの点検​

PR ごとに、開発ルール（rules.json）に照らして 3 段で点検します。

段誰が中身
1機械lint・型・試験・約束の型・持ち場・点検の台本。「必ず」の決まりに外れた PR は T9 が入れない
2AI一次レビュー。指摘に決まりの id を付ける。承認の数に入れない
3人判断の要る所を読み、承認する

点検の結果は、PR・head の sha・決まりの id・結果・証拠・誰が見たか（機械・AI・人）を 1 件ずつ持ちます。決まりごとの守られた率にまとめ、開発ルールを育てる段（スキル）と開発の速さに渡します。

言葉の違う指摘​

ハブの言葉の設定で 2 つの言葉を選んだ時（例：日本語とベトナム語）は、指摘の元の言葉と日本語の訳を並べて見せます。既定は日本語だけです（指示書）。

PR のまとめと引き継ぎ​

PR のまとめと引き継ぎ。集める・矛盾を見る・論点に答える・直す・固めた束・エンジニアへの 6 段と、矛盾と論点の一覧、引き継ぎの資料、依頼文が並んでいる
PR のまとめと引き継ぎ。矛盾と論点を片付けてから渡す画面設計（開発中）・数字は見本

ゼロから作ると、一度に 100 本ほどの PR が出ます。そのまま渡すと、読む順もぶつかる所も分かりません。BeesBuild は、渡す前に束を固めます。

  1. 集める：出た PR を集めます。
  2. 矛盾を見る：AI が、PR どうしの矛盾（同じ表に別の名前で列を足している、ある PR の試験が別の PR の後では通らない、など）と、人が決める論点を洗い出します。
  3. 論点に答える：論点は決める部屋の形で人の番に出ます（人の番と決める部屋）。
  4. 直す：答えと矛盾に合わせて、作ったスレッドが PR を直します。
  5. 固めた束にする：束に版を付けます（v1、v2 …）。
  6. エンジニアへ渡す：依頼文を付けて、担当の範囲に分けて渡します（担当の範囲と引き継ぎ）。

束に付く資料​

資料中身
使った物の一覧MCP・スキル・技術
依存の図と順塊の依存の図と、マージとデプロイの順（HTML）
塊ごとのテストの手順それだけで試せる塊ごとの、短い手順
人が試すデータ塊ごとに置く。要らないコードとファイルは消し、消した物の一覧を残す
決めた事の一覧決める部屋で答えた論点

GitHub の PR の一覧では見えない「先に要る物」を、塊ごとにまとめて見せるのが束の役目です。

依頼文と案内の置き場​

  • 依頼文は、ハブの言葉の設定で作ります。2 つの言葉を選んだハブでは、両方の言葉で作ります。
  • 宛先は役で書きます。名前は、送る時に人が入れます。
  • 案内は GitHub（PR の説明）と Undam（旧 Xroid Work）のスレッドに置きます。Slack は下書きまでで、送るのは担当の人です。

依頼文の例です（数は見本）。

レビューのお願い（束 v3・PR 104 本）
資料：docs/handoff/v3/index.html（依存の図・順番・テストの手順）
順番：① 土台 → ② 会員 → ③ 課金 → ④ 画面 → ⑤ 知らせ → ⑥ 管理
まず ③ 課金の 9 本からお願いします。人が試すデータは test-data/v3/ にあります。

レビューの資料​

PR の資料。読む順の案内、関わる設計のページと点検の証拠、押すだけのモック、PR に毎回付く物が並んでいる
PR ごとに付く、押すだけで開く資料画面設計（開発中）・数字は見本

PR ごとに、押すだけで開く資料を AI が作ります。人は読むだけです。

資料中身
読む順の案内設計のページ → 決めた事 → 中心の変更 → 試験 → 画面、の順と、目安の時間。飛ばしてよい物（生成物・lockfile など）も書く
関わる設計のページ設計書の章・画面のキャンバスの画面・決めた事・試験の決まり
点検の証拠画面の写し（前と後）・動画・単体の試験と E2E・画面の比べ・守りの点検
押すだけのモック試す用のデータだけを使い、本番につながない見本。PR にリンクで付く
この PR の順とゴール道の中の位置と、どのゴールに要る PR か
見る観点触った持ち場・関わる開発ルールの id・危ない所・見なくてよい物
  • BeesBuild を入れていない人のために、要点は PR の説明（Markdown）にも書きます。PR の説明のいちばん上には、資料を開く 1 行が入ります（PR の地図とマージ）。
  • 非公開のリポジトリの資料を GitHub Pages で出すことはしません。Pages を非公開にできるのは GitHub Enterprise Cloud だけだからです。
  • 画面の操作を試験にする下書きの PR も、ここで受けます（ブラウザーと画面の操作）。

レビューの学び​

指摘ごとに、学びの印を 1 回押すだけで付けます。AI が先に案を出し、エンジニアが押して確定します。

印意味GitHub だけで付ける時行き先
ダメ直す指摘の頭に [NG]開発ルール（rules.json）と悪い例
良い続ける[GOOD]手本（references/patterns.md）と、資料の良い例
質問聞きたい[Q]学びの記録だけ
好み決まりにしない[NIT]学びの記録だけ
  1. 印を付ける：レビューの机で、指摘に印を押します。
  2. 直す前と後を組にする：指摘の所の差分と、スレッドが直した commit の差分を組にして残します。参照で持ち、大きなコードは写しません。
  3. 決まりの候補にする：同じ学びが 3 回（2 つ以上の PR で）出たら、開発ルールの決まりの候補になります。決め方は、開発ルールの輪に従います（スキル）。
  4. 効き目を数える：決まりにした後に同じ学びが出た数（再発の数）を週ごとに数え、週次レポートに出します（開発の速さ）。
  • 印は任意です。印の無い指摘は AI が分け、週次レポートで 5 分ほどでまとめて確かめられるようにします。
  • レビューした人どうしを比べる数は出しません。

データの形​

型中身
HbReviewItemレビューの待ちの 1 件
HbPrRefPR への参照
HbPrBundlePR の束（版・塊・資料）
HbConsistencyCheck矛盾と論点
HbHandoffPackage依頼文（言葉はハブの言葉の設定）
HbRuleCheck開発ルールの点検の結果（PR・head の sha・決まりの id・結果・証拠・機械か AI か人か）
HbTestRun試験の走り
HbReviewLessonレビューの学び（印・直す前と後・回数・状態）

次に読む​

PR の地図とマージ順・道・ゴール・担当の範囲・自動マージ開発の速さレビューの能力と週次レポートスキル学びを開発ルールへ戻す輪