並列作業の全体像

このゲームは、複数のAIエージェントが同時に開発しています。 この文書は、その仕組みが何でできていて、何がどう流れるのかを人間の読み手へ示します。

規則そのものは agent-ops/parallel-work.md が持ちます。 あちらはエージェントが従う取り決めで、こちらは全体像だけを扱います——同じ説明を二度書かないため、細かい条件はあちらへのリンクに留めます。

この形へどうやって辿り着いたかは HowWeGotHere.md。 作り方はそのつど変わっており、並列作業はそれ以前の段が作ったもの全部の上に立っています。 ただしその多くは、並列のために作ったものではありません——試験も、画面を確かめる道も、絵の 自動化も、1人のエージェントに書かせる時点で要ります。これは種類の話で、量は別です——盤面を 回す仕組みを試す分の試験は、並列化そのものが生んでいます。

1. 何が要るのか

要るのは、1人で書くなら要らないものです。

• 衝突しないこと。 同時に書く相手が居るので、触る先が重なると互いの足元を壊します。
• 判断を集めること。 決めるのは人間ですが、人間の手数を最小にしないと使われなくなります——指示はスマホから来ます。
• 品質が揃うこと。 書き手が毎回違うので、放っておけば揃いません（10節）。人間なら「前もこう書いたから」で揃うところが、セッションは毎回まっさらです。
• 失敗が見えること。 取りこぼしは「気づけないこと」として現れるので、放っておくと成功と区別が付きません。

以下の登場人物と仕組みは、全部これらのために在ります。 逆に言えば、どれにも効かないものは置いていません。

2. 登場人物 — どんなエージェントが居るか

役を分けている基準は、やっていることではなく「何に書けるか」と「何で立つか」です。 掘り起こし役と棚卸し役はどちらも読んで issue へ出す役ですが、既にある issue を書き換えられるのは棚卸し役だけです（掘り起こし役が書けるのは、自分で立てる新しい issue と、その一覧が二重に立っていた周のコメント1つだけです）。下の表の4列目（どう走るか）は基準ではありません——「何に書けるか」から出てくる帰結です（「立ち方は『何に書けるか』が決めている」）。

誰が誰を立てるか

flowchart LR
    Human["🧑 人間"]
    Task["⏰ このPCのタスク（モデルではない）"]
    Daemon["🤖 デーモン（モデルではない）"]
    Adviser["💬 相談役"]
    Triage["📋 棚卸し役"]
    Analysis["📊 分析係（一次）"]
    Trend["📈 分析係（二次）"]
    Policy["🧭 価値観を畳む係"]
    Reviewer["🔬 レビュアー"]
    Worker["⚙️ 作業者"]
    SelfReview["🩺 自己レビュー役"]
    Digger["⛏️ 掘り起こし役"]
    RefAudit["🔎 参照を検める係"]
    Patrol["🔧 盤面を見回る係"]
    Payoff["📐 割に合っているかを見る係"]
    Values["📮 値の死を告げる係"]

    Human -->|"新しいセッションを立てて話しかける"| Adviser
    Task -->|"ログオンと毎時。生きていれば何もしない"| Daemon
    Daemon -->|"未整理の issue があるとき"| Triage
    Daemon -->|"読まれていないスメルがあるとき"| Analysis
    Daemon -->|"読まれていない分析があるとき"| Trend
    Daemon -->|"棚卸ししていない記録があるとき"| Policy
    Daemon -->|"着手できる kind:task があるとき"| Worker
    Daemon -->|"判定のラベルが無い緑のPRがあるとき"| Reviewer
    Daemon -->|"ゲームの仕事の供給が、作業者の枠に満たないとき"| Digger
    Daemon -->|"検めていない参照か、変わったファイルがあるとき"| RefAudit
    Daemon -->|"健全かどうかによらず"| Patrol
    Daemon -->|"割に合っているかによらず"| Payoff
    Daemon -->|"このPCの gh が死んでいて、自分で issue を書けないとき"| Values
    Worker ==>|"PRを作る前に1本"| SelfReview
    Analysis ==>|"PRを作る前に1本"| SelfReview
    Payoff ==>|"PRを作る前に1本"| SelfReview
    Trend ==>|"PRを作る前に1本"| SelfReview
    RefAudit ==>|"PRを作る前に1本"| SelfReview
    Adviser ==>|"PRを作る前に1本"| SelfReview

どれも、条件が出た瞬間に立ちます。 相談役の条件は「人間が相談したくなったこと」で、そのとき人間はもうそこに居るので、機械の引き金を置いても待つだけになります。

デーモンを起こす係と、盤面を見回る係は、立つ条件が背反です。 前者が手を出すのはデーモンが居ないときだけ（走っていれば daemon.sh start は何もしません）、後者が立つのは居るときだけ（立てるのがデーモン自身です）。同じ原因に両方が別々の手を出す形は、錠ではなくこの背反で消えています（board-design.md 2.21.1節）。

作業者とレビュアーを立てるのはモデルではありません。 daemon.sh が一定の間隔で GitHub から盤面を引き、打つ手を board-move.mjs が決めます（8節）。人が1本もセッションを立てていなくても、投入・レビュー・直しの再開・マージは進みます。

デーモンを起こす者だけは、デーモンの外に居ます。 落ちれば盤面は1ミリも動かないので、そこを盤面の中の仕組みで見張ると落ちたときに見張りも立ちません。起こすのはこのPCのタスクスケジューラで、ログオンのときと毎時に daemon.sh start を打つだけです——モデルは1つも動かず、生きていればあちらが自分で引き返します（board-design.md 2.19節）。

太い矢印がサブエージェントで、残りはセッションです（下の「立ち方は『何に書けるか』が決めている」）。サブエージェントは自己レビュー役だけで、どこにも書かず、親へ結論を返すだけです。枠で囲っていないのは、PRを出す側なら誰のセッションの中にも立つからです。

盤面を見回る係だけは、直しをPRに載せません。 盤面が詰まっている間はPRがマージされないので、載せると直しが届きません（出どころ: ユーザーの指示・2026-09-06）。

PRを出すのは主に作業者と相談役で、どちらも1セッション＝1ブランチ＝1PRに閉じます。一次と二次の分析係・参照を検める係・割に合っているかを見る係も、記録のPRを1本ずつ出しますが、記録だけの差分なので、作業者の枠には数えません（8節の CHORE）。棚卸し役・レビュアー・掘り起こし役・価値観を畳む係・値の死を告げる係は作業ツリーへ書かないので、何本立てても互いの足元を壊しません。自己レビュー役はPRを出す側のチェックアウトをそのまま使いますが、読むだけなので同じです。

周期で立つ係の引き金は、「仕事があるか」と「前に立ててから間隔が空いたか」です（board-design.md 2.17節）。間隔そのものは board-move.mjs の CYCLES が係ごとに持ちます——ここへ書き写すと、写しだけが古くなる先が増えます。件数のしきい値は置きません——溜まるまで待つ形にすると、1件のまま来ない日が続いたときにそれが放置され、しきい値そのものが「そこまでは残ってよい」の宣言になります。上の表で周期の係に書いた「何で立つか」は、このうち仕事の側だけです——見回る係だけは、盤面が健全かを確かめるのが仕事なので、それがいつでも在ります。

値の死を告げる係だけは、盤面の周の外から立ちます。 立てるのは1周を回す側ではなく、毎時の値の見回りです——盤面が動くのに要る値を見張る係を、その値を要る周の中に置くと、値が死んだ周に見張りも動きません（board-design.md 2.22.1節）。

掘り起こし役に実装させないのは、報告と反映を同じ役に持たせないためです。 掘り起こし役が出すのは材料で、それを配るのはデーモン、手を動かすのは配られた作業者です。棚卸し役だけが既にある issue の更新権限を持ちますが、書き換えるのは型であって中身ではありません（原文を消させない）。

立ち方は「何に書けるか」が決めている

別セッションにするかサブエージェントにするかは、役の性質ではなく、上の表の「何に書けるか」から出てきます。

どこかに書く役は、別セッションです。 書く先で理由が分かれます。

• ファイルへ書く（作業者・相談役・一次と二次の分析係）— 専用の作業ツリーが要ります。同じチェックアウトを共有すると、整形のフックや git の状態を互いに壊します。
• GitHubへ書く（レビュアー・棚卸し役・一次と二次の分析係・掘り起こし役・価値観を畳む係）— 書いたものが記録として残り、それが次を動かす合図になります（判定のラベル・## 未整理・チェックボックス）。合図を読むのはデーモンか人間で、書いた側が生きている必要はありません。親と運命を共にするサブエージェントには置けません。

どこにも書かない役だけが、サブエージェントにできます。 報告の行き先が親しかないので、渡し方を決める余地がそもそもありません。読んだ量は子の文脈に留まり、親へ返るのは結論だけです。

「読むだけならサブエージェント」ではありません。 レビュアーも棚卸し役も読む仕事ですが、どちらも別セッションです。書いているものが何を買っているかで決まります。

💬 相談役 — 人間が立て、合意した分だけをPRにする

引き金は「人間が相談したくなったこと」で、それは既にあります。 機械が先回りして立てても、人間が来るまで待つだけなので、取りこぼしはありません。新しいセッションを立てて話しかけてください。

• 担当を宣言しません（7節）。列挙はどこから読み始めるかの手がかりで、相談役はそれを対話した人間から直接受け取っているからです。残るのは実際の衝突だけで、コストはリベース1回です。
• PRは合意できた分だけです。議論の途中では書きません。マージ前に合意が増えたら、同じPRへ足します（1セッション＝1ブランチ＝1PRを崩しません）。マージされた後に続きが出たら、新しいセッションを立ててください。
• 合意が仕様書の節へ落ちるPRは、判断待ち になります。 【確定】 の印が増えるので、機械の関門（6節）に掛かるためです。これは正常で、そのマージが「差分への承認」にあたります——チャットで合意したのは文面で、まだ差分は見ていません。取り決めの置き場（agent-ops/**）にも、PRにする限りは同じ関門が掛かります——needs-user-review.sh の射程は、印の条件が掛かる文書と同じ1つです（DocumentStyle.md 10節）。ただし、あの置き場は main へ直接 push してよいので、そちらへ載せた合意には関門が掛かりません——PRが無い差分には掛かる先がありません。この文書のように印を置かない文書では、そもそも印が動かないので鳴りません。

⛏️ 掘り起こし役 — 探すのではなく、数える

立つのは、ゲームの仕事の供給が作業者の枠に満たない周です（board-design.md 2.17・2.18.1・2.18.3節）。在庫の数では立ちません——スメルを拾う役の入力はPRが出るたびに生えるので、「配れる kind:task が尽きた」で見ると、整備の issue が在庫を満たし続け、この役は立てられません。尽きてからでも遅すぎます——0で見ていた間、在庫は少数のまま滞留してこの役は一度も立たず、空いた枠は整備で埋まり続けました。見つからない周が続いても、間隔（CYCLES）のぶんは空けます。渡す本文は dig-prompt.md。

「仕事を探せ」とは言いません。 そう言われたエージェントは必ず何か見つけるので、出力の質が観点の質と同じになり、観点を毎回考える人が要ることになります。機械が起こす役なので、その人は居ません。

完成の定義に載っているもの － 既に issue になっているもの ＝ 掘り起こすもの。

探索は無限ですが、定義に照らした穴は有限です。 だから残りは減っていき、ゼロになったら「もう無い」と言えます。 観点を毎回変える必要はありません——同じものを数えても、残りが減るので出力は毎回変わります。

数えるのは、残りの作業量を答えられるものだけです（agent-ops/policies.md「未実装のものの扱い」。「無くても完成を宣言できるもの」は Someday.md に分けてあります）。

• 未決事項・今後の検討課題 の節
• 【未実装】 の印
• 収支の穴。生成済みの stats/balance.yaml を読みます——表は main への push のたびに workflow が作り直すので、npm run stats:balance で作り直さずに読むだけで足ります。コンテンツ不足が本命のボトルネックです（agent-ops/parallel-work.md の「コンテンツを後回しにしない理由」）

出口は分かれていて、掘り起こし役自身が振り分けます。 全部を訊く側へ回すと、この役を起こしても盤面が動きません——判断待ち の付いた issue は誰にも配られないので、配れるものが1件も増えないからです。

• やると決まっているもの（段0を通った 【未実装】・収支の穴）→ issue を立てる。棚卸し役が分類して盤面へ戻ります。
• やるかどうかから訊くもの（未決事項と、段0を通っていない 【未実装】）→ チェックの一覧を1本立てます（判断待ち を付けるので、答えが埋まるまで誰にも配られません。board-design.md 2.17.2節）。未決は「まだ決めていないこと」であって「やると決めたこと」ではないので、そのまま配ると乗り気でないものが実装されて戻ってきます（agent-ops/parallel-work.md「未決は「やるかどうか」から訊く」）。

「残り0件」は失敗ではなく、正しい報告です。 人間が知りたいのは「ゴールが近いのか」で、それに答えられるのは数だけです。

印にも測定にも載らないもの——「面白さが足りない」の類——は、掘り起こし役には見つかりません。 それは相談役の領分です。掘り起こし役は完成の定義に照らして残りを数え、相談役は完成の定義そのものを動かします。 前者は数えるだけなので機械が起こせて、後者は人間が要ります。

誰が issue とPRに触るか

判断も仕事も issue の上に載ります。 誰がどこへ書けるかは、上の表の「何に書けるか」がそのまま現れます。

flowchart TB
    Human["🧑 人間"]
    Daemon["🤖 デーモン"]
    Adviser["💬 相談役"]
    Digger["⛏️ 掘り起こし役"]
    Triage["📋 棚卸し役"]
    Analysis["📊 分析係（一次）"]
    Trend["📈 分析係（二次）"]
    Worker["⚙️ 作業者"]
    Reviewer["🔬 レビュアー"]

    subgraph Issues["issue"]
        New["未整理<br/>（結論がまだ揃わない）"]
        Task["kind:task<br/>担当・完了条件・拠り所"]
        Ask["判断待ち<br/>（人へ訊く issue。1問1本）"]
        Brake["#1515 手綱"]
    end
    PR["PR<br/>（## 仮決め を先頭に持つ）"]

    Human -->|"自分の言葉で書く"| New
    Human -->|"チェックを付けて 判断待ち を外す＝確定"| Ask
    Human -->|"チェックを外す＝投入を止める"| Brake
    Human -->|"PRを止めている印を外す＝書き直させる"| PR
    Brake -.->|"毎周読む"| Daemon
    Daemon -->|"goal:game の供給が枠に満たなければ立てる"| Digger
    Digger -->|"やると決まっているものを立てる"| New
    Digger -->|"やるかどうかから訊くものを、チェックの一覧にして立てる"| New
    Adviser -->|"合意できた分を書く"| PR
    Daemon -->|"マージする"| PR
    Daemon -->|"未整理があれば立てる"| Triage
    New -.->|"まとめて読む"| Triage
    Triage -->|"分類する・投入できる形へ書き換える"| Task
    Triage -->|"申告を読んで順序を張る"| Task
    Triage -->|"確定の宣言に反する判断が要るとき1本立てる"| Ask
    Task -->|"デーモンが1件渡す"| Worker
    Worker -->|"Closes #N を書く"| PR
    Worker -->|"気づいた別件を立てる"| New
    Worker -->|"仮決めした箇所を訊く（進みながら）"| Ask
    Worker -->|"確定の宣言に反する変更が要るとき1本立てる（進めずに）"| Ask
    Reviewer -->|"結論をコメントする"| PR
    Daemon -->|"読まれていないスメルがあれば立てる"| Analysis
    PR -.->|"マージ済みのスメルを読む"| Analysis
    Analysis -->|"手を打つべきものを立てる"| New
    Analysis -->|"記録を出す"| PR
    Daemon -->|"読まれていない分析があれば立てる"| Trend
    Analysis -.->|"回ごとの記録を横断して読む"| Trend
    Trend -->|"回をまたぐ形に根本対策を立てる"| New
    Trend -->|"記録を出す"| PR

リポジトリの記録にも書く役が居ます——相談役がユーザーから受け取った判断を agent-ops/decisions/ へ、作業者が確定した仕様を docs/** へ（9節）、一次の分析係がその回の帯で繰り返し現れた形を agent-ops/analysis/ へ、二次の分析係が回をまたいでいる形を agent-ops/analysis/summary/ へ。

3. issue は種類ごとに役割が違う

同じ「issue」でも、中身も寿命も読み手も違います。

盤面の issue は写しで、手を決める材料ではありません。 走っているセッションもPRのラベルも GitHub 側の事実なので、board.sh もデーモンも毎回引き直します——写しを持つと古くなったことに誰も気づけないので、本文にはいつ時点かを一緒に書きます（board-design.md 2.20.1節）。

issue は、棚卸し役が分類してから配られる

人間は自分の言葉で issue を書きます。 担当も完了条件も付きません——書式を覚えることは判断ではないので、型を人間の側へ要求しません。

そのまま投入すると、PRの範囲が宣言されていないまま差分が返り、レビュアーは範囲外へ伸びたかを機械的に判定できず、全部が判断待ちに落ちます。そこで棚卸し役が分類します（そのまま／翻訳／分解／束ねる／返却、のいずれかの出口。書き換えたときも原文は消しません）。

棚卸し役が出す結論は kind: と goal: の各1つです——kind: は何であるか（1セッションで片付く作業単位（kind:task）か、投入する先が無い常設の盤か）、goal: は何へ向かうか（下の「向かう先」。常設の盤には要りません）。未整理とは、この結論が揃っていないこと——分類がまだのものと、kind:task なのに向かう先を名乗っていないものの両方です。分類の値を数え上げて「そのどれでも無い」という否定の列挙では表しません。出口が増えるたびに条件を書き換えることになり、書き忘れた出口の issue が毎周また拾われるからです。

常設の盤の値は、その本文を機械がどう扱うかで分かれます（board-design.md 2.17.5節）。盤面がユーザーの答えとしてチェックを拾うのは、そのうち答えを受ける盤からだけです。ラベルの名前が、機械の扱いをそのまま名乗ります——名乗らせないと、機械が本文を読んでいることを誰も想像できないまま、下ろす者の居ないチェックが ## 確定待ち に居座ります。

「もう成り立たない issue」に専用のラベルは作りません。 それは task ではなくなった のではなく task だが、もう要らないと思う、と人へ返した 状態なので、置き場は分類ではなく配ってよいかの軸（判断待ち）です。棚卸し役は kind:task を付けたうえで [返却] のコメントを1つ置き、そこから先は作業者が人へ返すときと同じ道を通ります。

エージェントが自分で立てた issue には origin:agent が付きます。 人もエージェントも同じアカウントで書き込むので、GitHub の側からは見分けられません（user も author_association も同じ値になります）。そこでエージェントが自分で名乗ります——起票のときに一緒に渡すので、後から付け直す手は要りません（別の手が要る形にすると、付け忘れた issue が「人が立てた」として数えられます）。人が立てた issue には何も付きません（印が無いことが「人が立てた」を表すので、人間の側の手数は増えません）。この軸は数えるためのもので、盤面は読みません。

向かう先は別の印（goal:game / goal:upkeep）で名乗ります（board-design.md 2.18.1節）。盤面はこちらを読んで、完成へ近づける仕事を整備より先に配り、整備へ回す作業者の枠を切り（board-design.md 2.18.2節）、完成へ近づける仕事の供給が枠に満たない周に掘り起こし役を立てます（同 2.18.3節）。既定はありません——goal:game を持つものだけが完成へ近づける仕事で、名乗らなければ整備として並びます。名乗り漏れを最後に拾うのは棚卸し役です（同 2.17.1節。kind:task なのに goal: の無い issue は未整理として拾われ、印が付くまで盤面が NOTE で告げ続けます）。配る手前では止めないので、印が付くまでのあいだは整備として並びます。

分類が済んだ issue は、そのまま配られます。 棚卸し役は 判断待ち を付けません——人の手番に入る印を、判断の要らないところへ付けないためです（board-design.md 2.13.1節）。付けたぶんだけ、外すタップが増えます。順序（blockedBy）を張るかどうかを決めるのも棚卸し役です——なぜその順序かを知っているのは issue を立てた側だけなので、立てたセッションが本文の ## 順序 節で申告し、棚卸し役がそれを読んで決めます。張る手そのものはワークフローが持ちます——依存の API はセッションの側の道具に無いので、棚卸し役は待つ側の issue へ [順序] #<先に要るほう> の後 とコメントし、board-labels.yml がそれを張ります。申告の無いものに順序は作りません——推定を許すと、触る先が重なっているだけの組まで直列に落ちます。

人へ訊くときは「断定文」で書く

「どうしますか」とは書けません。 決まっていない箇所は仮決めして進むのが既定なので、具体的な案は常に手元にあります。だから太字の1文が、そのまま仕様書へ書ける形になっていて、人間は同意するものにチェックを付けて、判断待ち を外すだけで済みます。ラベルを外すところまでが答えです——機械が見ているのはラベルで、チェックのほうは見ていません（parallel-work.md「チェックだけでは、機械は拾わない」）。

答えが無いことは「否」ではありません（見ていない・今は決めない、も同じ）。暫定が既定なので、放置されたままで何も壊れません。

4. 1つのタスクが流れる道

sequenceDiagram
    participant H as 🧑 人間
    participant T as 📋 棚卸し役
    participant D as 🤖 デーモン
    participant W as ⚙️ 作業者
    participant R as 🔬 レビュアー
    participant G as GitHub

    H->>G: issue を自分の言葉で書く
    D->>G: 盤面を引く（一定の間隔で）
    D->>T: 未整理があり、前に立ててから半日空いたので、棚卸しを1本立てる
    T->>G: 分類し、担当・完了条件・拠り所を書く（kind:task）
    D->>W: セッションを立て、issue の URL を渡す
    Note over W: 決まっていない箇所は<br/>止まらず仮決めして進む
    W->>W: 🩺 サブエージェントに差分を読ませる<br/>（レビュアーと同じ観点。直すのは自分）
    W->>G: PR（先頭に Closes #N と ## 仮決め）
    W->>G: 気づいた別件は直さず issue に
    Note over W: PRを出したら仕事は終わり<br/>CIもレビューも見張らない
    D->>R: 判定のラベルが無く緑なので、レビューを1本立てる
    R->>G: 判定をコメントで返す（1行目が結論）
    G->>G: board-labels.yml が1行目をラベルへ変える

    alt 直し待ち／CIが赤／コンフリクト／見た目が無い
        D->>W: 書いたセッションを起こして直させる
        W->>G: 直しを push（ラベルは push で外れる）
        Note over D,R: 本文だけを直して戻ってこなければ<br/>もう1周レビューへ渡す<br/>（レビューへ渡せない形は担当の issue へ返す）
    else 通してよい かつ 緑
        alt 人の手番で止まっている
            D->>G: マージを出さない
            H->>G: 承認（画面からマージする）／却下（直してほしいことを書いてラベルを外す）
        else 止まっていない
            D->>G: マージ（人間は通らない）
        end
    end

PRを出したセッションは、そこで仕事が終わりです。 CIもレビューも見張らせません——見張らせると、自分を起こす道具が要り、それらは自動承認できないので、そのまま人間のタップに化けます。 待つのはデーモンの仕事です。

直すのは、レビュアーではなく元を書いた作業者です。 文脈を持っているのはそちらで、レビュアーが push すると1つのPRを2つのセッションが握ることになります。

後片付けは、マージした手からは切り離してあります。 マージするのは merge-pr.sh、後片付け（積まれていたPRの差し戻し → 本体のチェックアウトを新しい main へ進める）は tidy-merged-pr.sh で、マージ済みのPRを見つけた周に別の手として打ちます——ユーザーはPRを画面からマージするので、繋いだままだとその回はどれも走りません。 セッションを畳むのも同じ理由で別の手（ARCHIVE）です。

盤面が管理しているのは、セッションではなく開いているPR

人間は、盤面を通さずにセッションを立てます（相談役がそうですし、思いついた仕事を直接頼むこともあります）。それでも仕組みから外れません。 どの経路で立ったセッションでも、PRを出した瞬間に上の道へ載ります。

• デーモンはそのPRに気づきます。 引いてくるのは開いている全PRで、誰がどう立てたかは見ません（8節）。
• レビューが立ちます。 dispatch-review.sh はPR番号だけで立ち、誰が書いたかを見ません。
• 差し戻す相手が分かります。 セッションは自分のIDを名乗る決まりで、コミットに Claude-Session: https://claude.ai/code/session_<ID> のトレーラが入ります。盤面はそれを読みます——本文の脚注は書き直した拍子に落ちますが、トレーラは残ります。

だから、立てる前に申告する必要はありません。 PRを出す前のセッションに対して盤面がすることは、投入も畳みも衝突判定も含めて何もないからです。申告を要求すると、思いついたときに立てる気楽さがそこで消えます——そして申告し忘れた分は静かに落ちます。

名乗り忘れは、CIが赤くします（tests.yml の 名乗り）。トレーラを持つコミットが1本も無いPRは、そこで止まります——赤いPRを盤面はレビューへもマージへも出しません。 促すだけにしないのは、書き忘れが既に実害を出しているからです。中身の誤りを見るジョブとは分けてあります——名乗り忘れは中身の話ではないので、直し方も直す人も別です。

人間が直接立てたセッションを、機械は畳みません。 話している最中かもしれないからです。ただし差し戻しの send_message は割り込ませます——それは判断の取り消しではなく、中身が正しいかの話で、[デーモン] の印が付くので出どころを取り違えません。

5. 人間が受け持つのは、判断そのものだけ

規則の上ではPRを承認するのは人間ですが、全部が回ってくるわけではありません。 回るのは2つだけです（6節）——機械が引いた線（確定の宣言が増えた／消えた）に触ったPRと、レビュアーが「人の判断が要る」と判定したPR。実測（2026-08-29）では、当時の機械の線で直近25本のうち5本が止まり、そこに倍率がゲームへ入った3本すべてが入りました。

機械の線は「モデルには決めさせないもの」を名指ししたものです。 「これは通してよい」とモデルが裁量で判断できる形にすると、越えられる関門は越えます。だから機械の側は、越え方まで人間の手に固定してあります——通すなら画面からマージします（後片付けはマージした手から切り離してあるので、それでも走ります）。承認のためのラベルはありません——通してよいのならマージすればよいだけで、そのためにラベルを1つ付けさせる理由がないからです。

flowchart LR
    A["何もしない<br/>＝承認"] --> Done["緑になった時点で入る"]
    F["画面からマージする<br/>＝承認"] --> Done
    B["直してほしいことを書いて<br/>PRを止めている印を外す"] --> Fix["書いた本人が起き、通らなかった分をやり直す"]
    C["判断待ち の issue にチェック<br/>＋ラベルを外す＝確定"] --> Mark["仕様書へ【確定】が付く"]
    D["相談役と話す"] --> Decide["合意がPRになる"]

覚えることは1つです——ラベルを外す＝動いてもらう、自分で終わらせる＝閉じる（issue）かマージする（PR）。 issue でもPRでも、判断待ち の外し方は同じ意味です——同じラベルの外し方が場所によって別の意味を持つと、覚えることが2つになります（board-design.md 2.13.1節）。付けたのがレビュアーか機械かも、見分ける必要がありません。

既定はマージで、手を動かすのはほぼ止めるときだけです。 手数の多い入口は使われなくなり、使われない仕組みは無いのと同じだからです（11節）。マージが止まっているPR（判断待ち が付いたもの）だけは、通すほうにも1手（画面からのマージ）が要ります。 相談役との対話だけは手数が掛かりますが、そこで扱うのはまだ形になっていない判断なので、短くはできません。そのPRが関門に掛かるかどうかは、合意がどこへ落ちたかで決まります（2節）。

作業セッションは、人間へ問いかけません。 人間はそのセッションを見ないので、訊いた側は答えの来ない相手を待ち続けます。決まっていない箇所は仮決めして進み、仮決めすらできないときだけ、仕事を issue へ返して終わります——1行目を [返却] <なぜ返すか> にしたコメントを置くと、issue に 判断待ち が付き、人間が外すまで誰にも配られません。返さないまま止まったセッションは、盤面が一度起こして、それでも動かなければ代わりに返します。 成果が issue の側にしか出ない（PRを作れない）仕事を終えたときは、[完了] <何を済ませたか> を置きます——issue が閉じ、終えたセッションは畳まれます。人間の手番には入りません。詳細は board-design.md 2.15節。

却下がラベルの出し入れなのは、GitHubのレビュー機能が使えないからです。 セッションは人間の資格情報で push するので、PRの作者が全部その人になり、自分のPRには Approve も Request changes も出せません。

理由はコメントに書けば足ります——「−5 で」だけで構いません。足りなければ、起こされたセッションがPRのコメントで訊きます。ただしコメントだけでは止まりません——デーモンが読むのはラベルだけなので、止める意思はラベルを外すことで表します。 外れたことは出来事としてワークフローが拾い、却下 のラベルへ訳されます（外れている状態は書けません——外れていることと、最初から付いていないことが同じに見えるからです）。

6. 止める線は機械が引き、差分はレビュアーが読む

PRの先頭には必ず ## 仮決め 節があります。 「なし」と書くのも仕事のうちで、書かせないと「仮決めが無かった」のか「書き忘れた」のかが区別できません。

ただし、申告だけでは止める線になりません。 直近25本（2026-08-29 の実測）で ## 仮決め に中身のあったPRは 22本。全部を人間へ回せばタップを1回増やすだけの関門になり、本当に判断が要るものが埋もれます。実際に付いた 判断待ち は 0本——受け取る側が使えていませんでした。

そこで、判定を次のように割ってあります。

出されたPRの差分を読むのはレビュアーです。 読むこと自体はPR1本につきセッションを1本立てれば済み、盤面が受け取るのは「通してよい」か「直しが要る」かだけで足ります。1つのセッションが多数のPRを読む形にすると、読むほど文脈が埋まって後の判断が痩せます。 確定節の射程に変更が掛かっただけのPRを機械で止めないのも同じ理由で——実測では大半が「【未実装】 を外して実装した」もので、確定した中身は動いていませんでした——全部を止めると、またタップを1回増やすだけの関門になります。

機械に残してあるのは、誤検知が構造的に無い1つだけです。 【確定】 は「覆すには人間の判断が要る」という宣言そのものなので、ユーザー以外がそれを増やしたこと自体が、定義上ユーザーの判断を要します——既に壊した実績のある操作は機械で止める、にあたります。

触ったファイルの線では引きません。 ファイルの線は「触ったか」しか見ないので、スキーマの description を変えただけの差分と、文法を1つ足した差分が同じに見えます——止めた理由と ## 仮決め の中身が一致せず、通すかを決める側は「何を判断すればよいのか」を読み取れません。区別できるのは差分を読む者だけなので、レビュアーが持ちます。

決めきれなかった問いも ## 仮決め に書かせます。 セッションから人間へ届く場所はPR本文しか無いので、書かなければその問いは誰の目にも触れずに消えます——実際に一度、「日暮れ後の戻り道に窯まで要求してよいか」という問いが最後の要約にだけ残り、そのまま入りました。

7. 担当は手がかりとして列挙し、衝突は避けない

タスク issue に書く ## 担当 は、調べ始める場所の手がかりです。触ってよい範囲ではありません——直すのに必要だと判断したファイルは、挙がっていなくても変更できます。触ってはいけないファイルも書きません。

1ファイル重なることは、直列にする理由になりません。 重なりの度合いを見ずに直列へ落とすと、鎖が伸びた分がそのまま遅れになります。重なっている相手を名指しもしません——盤面が書けるのはファイル名だけで、受け取った側はそれを見ても触る先を変えないので、知らせても作業が変わりません。ぶつかれば git が相手を教えます。

代わりに、ぶつかった実績を控えます。 describe-conflict.sh が「どのファイルで・どのPRと」を出し、デーモンがそれを帳面へ残します。錠を足すべき資源は、起きた衝突から決めます。

層で切った領域の地図は持ちません。 効くのはファイルの衝突にだけで、文書は主題で並ぶため軸が直交します。同時に1本しか動かせない資源——GPUや、動かしながら書き換えられないデーモン——だけがラベルの錠になります。 条件は agent-ops/parallel-work.md の「同時に走らせてよいか」。

列挙を要求しているのは作業者だけです。 手がかりが無いと、どこから読み始めればよいかを毎回ゼロから探すことになります。触ったファイルの一覧でPRの範囲を測ることはしません（出どころ: ユーザーの指示・2026-09-07）——囲いにすると、越えたかどうかの判定と申告が要ります。相談役のPRには手がかりも要りません（どこを読むかは対話した人間が知っています）。重なったときはリベース1回を払います。

8. 盤面を回すのはデーモンで、モデルではない

daemon.sh が一定の間隔で GitHub から盤面を引き、1周に1手だけ打ちます。 1周の中身（引く・決める・打つ）は board-round.mjs が持ち、そのうち打つ手を決めるのは board-move.mjs で、盤面を受けて手の並びを返すだけの純粋な関数です（GitHubも CCR も触らないので、単体で試せます）。

機械で判定できることは、レビュアーを立てる手前で弾きます。 コンフリクトと、画面が変わるのに ## 見た目 節が無いこと——どちらも差分と本文から機械で読めるので、レビュアーのセッションを1本使ってから差し戻すのは無駄です。弾いたぶんはレビューの観点からも消してあります。両方に置くと、レビュアーが読む番には既に直っているものを挙げることになります。

コンフリクトも書いた本人へ差し戻します。 デーモンには解消できません（判断が要ります）が、取り込みは書いた本人にできるので、赤と同じ mend に畳んであります——この3つは起こされた側がやることが同じ（PRを見て直す）だからです。逆に reject と look を分けてあるのは、やることが違うからです。

人の手番の印は、効き目を1つずつ持ちます。 PRに付いた 判断待ち が止めるのはマージだけ、収束せず が止めるのはレビューだけで、どちらの下でも、差分そのものへ向いた差し戻し（却下・## 見た目 の欠け・レビューの 直し待ち）は出ます——人の返事を待たなくても直せるからです。出さないのは、main が動いて生まれたコンフリクトとCIの赤だけ——答えを待つ間ずっと生まれ続けるうえ、直しても答えは近づきません（board-design.md 2.13.8節）。どちらを越えるのも画面からのマージで、人が外せばそれは差し戻しになります（5節）。印そのものは push で全部外れ、必要なら次の周に導出し直されます。外す走りが転んだ回は、盤面が同じ札を落としてもらいます（UNLABEL。board-design.md 2.13.7節）。

どこで走らせるかは、issue に書いてある

セッションが立つ先は2つあります——クラウドと、このPC（ブリッジ）。既定はクラウドで、issue に env: のラベルが付いていればそこへ投入します（board-design.md 2.16節）。

触ってよい範囲は、どちらで走っても同じです。 分けているのはクラウドではできない仕事だけ——手元の画面やこのPCにしか無いものを使う仕事と、走ってみて承認で詰まった仕事です。GitHub を触ることは理由になりません——gh と生の REST こそ無いものの、既存の issue の本文もラベルも、クラウドから用意された道具で書き換えられます（棚卸し役もクラウドで立ちます）。

だから渡す指示も投入先で変えません。 受け取る側は自分がどちらで走っているかを知らないので、場所で切った制約を混ぜると当たらないほうへも届きます（.claude/** を触るなと書いた行が、そこを直すために立てたブリッジのセッションへ届き、着手した時点で仕事をせずに返した実例があります）。

走ってみて初めて分かることは、走った側が申告します。 承認で拒否されて進めない、そのPCでしか確かめられない——クラウドのセッションが issue へ [ブリッジ] <理由> とコメントすると、board-labels.yml が env:bridge を付け、盤面が配り直します。

同じ手を、同じ盤面へ二度打たない

打った手は指紋とともに控えてあります。 差し戻しの指紋は種類・PR番号・headRefOid から作るので、push があるまで同じ手は出ません（例外は同じ版へレビューの「直しが要る」が増えたときと、main が動いたとき。agent-ops/board-design.md 2.13.6節・2.14.2節）——種類を入れてあるので、同じ差分へ mend の後に reject が来ても落ちません——直しを頼んだ相手が返事をする前に、毎周ふたたび叩くことがなくなります。レビューも同じで、同じ差分へ2本目のレビューは立ちません。

指紋が変わることだけが、同じ手を打ち直す条件です。 時刻の比較は使いません——起動時刻を基準にすると、立て直すたびにその谷間で起きたことが丸ごと落ちます（前身の見張りで、レビューの結論2件が2時間放置され、ユーザーがタップした答え13件が誰にも届きませんでした）。

判定のラベルも push で自分から消えます（board-labels.yml）。判定は「その差分についてのもの」なので、差分が変われば偽になります。偽になるべき状態を、自分では消えない場所に書かない——これが盤面の作り全体を通した決め事です（agent-ops/board-design.md）。

止めるのは、手綱のチェックを外すこと

デーモン自体は止めません。 止めるとレビューもマージも一緒に止まります。投入だけを止めたいときは、手綱の issue のチェックを外します（brake.sh が毎周読みます）。外れている間はその種類の手だけが打たれず、残りはそのまま流れます。

デーモンが止まっていることは、盤面にもラベルにも出ません。 知らせる代わりに、落ちたら起こす者を1つ置いてあります（このPCのタスク。2節）——この係は知らせるのではなく直します。 人が自分で確かめたいときは daemon.sh の status を打ちます。

そのタスク自体が走らなくなったときだけは、拾う者が居ません（誰もログオンしていない間は起きません）。この口座から動かせるものが全部このPCの上にあり、外から見ている者が1つもないためです。見張りを足しても、足した見張りが同じPCで走るので同じ場所へ戻ります。ここだけは人の目が要ります（board-design.md 2.19.3節）。

現在地は、見に来た側が盤面で訊く

デーモンは人を起こしません。 見に来た側が自分から現在地を訊く道具が要ります。それが盤面（board.sh）と tail ~/daemon.log で、デーモンが手を出していないものだけが残って見えます。

盤面は開いているPR・kind:task の issue・翻訳前の ## 未整理・畳んでいないセッション・確定待ちのチェックを、突き合わせた1つの表にして出します。依存（blockedBy）と「もう投入したか」を必ず引くのが要点で、手で gh を叩くとその2つが省かれ、塞いでいた issue が閉じても誰も気づかない／同じ issue へ二重に投入することになります。

9. 受け取った判断は、その場で書き留める

人間の考えは人間の頭の中にしかありません。 同じことを二度訊かずに済むよう、受け取った判断はその場で書き留め、棚卸しで一般則へ畳んで次のセッション以降の既定にします。

一般則の行き先は、この表に挙げたものだけではありません。 題材の決まっている判断は、文書の 書き方・コーディング規約といった、その題材の方針を持つ文書へ入ります（一覧は policy-review skill「行き先」）。

受け取った判断は、その場では、発言の原文とそれをどう読み取ったかを、別の節に分けて履歴へ残す だけです（混ぜると、エージェントの読みがユーザーの判断そのものとして読まれます）。一般則へ畳むのは 🧭 価値観を畳む係（2節）の仕事で、そこで初めて「場面（AとB）・選ぶ方・重視していること」の形に なります。1件だけを見て「これは一般則か」は判断できないので、その判定を後ろへ回してあります。

係が出すのは候補までで、既定にするかはユーザーが決めます。 候補はチェックボックスの issue に 並び、チェックの付いたものだけが、後から配られる別のセッションの手で方針の文書へ入ります ——候補を出す仕事と、チェックを読んで書く仕事を1本に混ぜません。 混ぜると、諾否を待つあいだ セッションが止まります。

記録するのは着手前です。 着手後や応答の最後では、会話が要約された時点で判断の文脈が失われた後になります。

10. 品質を一定にするために要った仕組み

書き手が毎回違うので、揃えなければ揃いません。 人間なら「前もこう書いたから」で揃うところが、 セッションは毎回まっさらです。放っておくとばらつく所を1つずつ塞いだ結果が、次の層です。

flowchart TB
    subgraph L1["入口で揃える（書き始める前）"]
        H1["SessionStart フック<br/>価値観を全文流し込む"]
        H2["PostToolUse フック<br/>書いたファイルを整形する"]
        H3["PreToolUse フック<br/>選択肢での質問を拒む／<br/>コマンドに目的を書かせる"]
    end
    subgraph L2["形を守る（npm test）"]
        T1["層の境界<br/>知らないと言った層が本当に知らないか"]
        T2["誰も輸入していない export"]
        T3["試験の種類の境目<br/>赤が出たときどこを見るかが決まる"]
        T4["説明と宣言の対応<br/>宙に浮いた docコメント"]
        T5["文書の中の名前<br/>消えた名前を指していないか"]
    end
    subgraph L3["中身を守る（npm test）"]
        C1["生成物の鮮度<br/>定義を変えて再生成し忘れたら赤"]
        C2["解析が黙って空を返さないか"]
        C3["宣言漏れの検出<br/>重さ・明るさ・死因を名乗っているか"]
    end
    L1 --> L2 --> L3

何がばらつくので、何を置いたか

先回りできたものと、後から要ったもの

同じ形で並べます。 効いている仕組みほど失敗として現れないので、踏んだ失敗だけを並べると、 うまくいっている側が全部消えます。

分かれ目は「失敗の形を先に名指しできたか」です。 層の腐りや説明の取り残しは数えれば見えるので 先に塞げました。見えないものは、一度踏むまで形が分かりません。

だから、見張りを足したら赤くなるのを見る

「緑」は「壊れていない」と「見ていない」のどちらでもありえます。 見張りが失敗する形は 「気づけないこと」なので、効いていない見張りは、緑であることと区別が付きません。

入力をわざと壊して赤くなるのを見てから報告する、という決まりがあるのはこのためです。

11. 使われない仕組みは、無いのと同じ

人間に回す部分は最小にして、自己完結させます。

• 人が関与せずに回る形にできるなら、そちらを選びます。 関与が要るのは判断そのものだけです。
• 判断を仰ぐときは、リポジトリを開かずに答えられるだけの文脈を添えます。 手元にあるからと省くと、答えが返ってきません。
• タップを1回増やすだけの関門は、無いのと同じにします。 だから判断が動かないPRはデーモンがそのまま通します。

同じことが、盤面を回す側にも効きます。 手で gh を叩く手順は、省ける確認から順に省かれます——省かれた確認は、省かれたことすら見えません。 そこで、決まりきった並びは scripts/daemon/（デーモンが回すもの）と scripts/agent/（人やセッションが自分で打つもの）に畳んであります。

畳んだのは往復だけではありません。 1サイクル10〜14回だった gh の呼び出しが5〜7回になったのは結果で、狙いは省かれていた確認が必ず通ることです。判断が要るのは差分を読むところと指示文を書くところだけなので、そこは畳んでいません。