■ 1. 並列エージェント開発で壊れるもの
- 壊れるのは調整:
- Claude Code や Codex を複数並列で走らせ Godot のゲームを作る開発で、最初に壊れるのはコードではなく調整
- 誰が何をしているか分からなくなり、同じファイルを二人が触る
- 報告が口頭(プロンプト)で流れて消え、リーダー役が「たぶん出来てるだろう」で受け入れてしまう
- 記事の位置づけ:
- この記事は人間が読むことを想定していない
- 調整を仕組みで固定する 2 つのツールと、Herdr + git worktree 上の環境全体を再現できるレベルで解説する
- MyKanban:
- リーダーエージェントがチケットを起票し、worktree ごとの worker エージェントに指令を出すスキルと CLI
- 報告書をレビューして完了/差し戻しを判断する Kanban + Jira 的ワークフローを提供する
- GodotPlayOnCodexOnHerdr:
- サンドボックスの中の worker が自力ではできない「実機の見た目」の検証を worker 自身に返す Godot GUI ブローカー
- Herdr プラグインとスキル allow-godot-window のセット
■ 2. leader と worker の役割分担
- 役割は 2 つだけ:
- leader は main チェックアウトにいて、ボード全体を担当する
- worker は自分専用の git worktree にいて、チケット 1 枚だけを担当する
- leader のやること:
- 計画、起票、dispatch、レビュー判定、統合を担当する
- プロダクトコードを自分では書かない
- 終点は done
- worker のやること:
- 実装、検証、報告書の提出を担当する
- done に動かさない、他の worktree を触らない
- 終点は review
- 境界を仕組みで守る理由:
- 判定を worker に任せると自己採点になる
- 実装を leader が始めると全体が止まる
- 自己採点の禁止:
- 完了判定を worker にさせないルールが、このワークフロー全体でいちばん効いている
■ 3. 構成要素
- Herdr:
- 「Agent multiplexer that lives in your terminal」を名乗る OSS(Apache-2.0)
- tmux 的な workspace / pane 管理に加え、pane 上のエージェントをソケット API から操作できる
- pane split、agent start、agent prompt、agent read、worktree create といった API を使う
- --kind は integration 名(claude, codex, copilot, cursor 等)で、リーダーを Claude Code、worker を Codex とする混成もできる
- git worktree による隔離:
- worker 1 人に worktree 1 つを割り当てる
- チェックアウトは ~/.herdr/worktrees/
/<チケット名>、ブランチは kan/<チケットID>- で統一する - リポジトリの隣に置かないのは、ビルド成果物やエディタ設定が main チェックアウトと混ざらないようにするため
- 共有ボードを成立させる性質:
- linked worktree の中では .git はファイルだが、git rev-parse --git-common-dir は常に共有の .git を指す
- ここにボードを置くことで、全 worktree から見える単一の調整領域をコミット履歴を汚さずに得られる
- MyKanban の構成:
- SKILL.md、bin/kanban(Python 3 標準ライブラリのみの CLI)、references/ の 3 点のみ
- references には workflow.md(状態機械、DoR/DoD、レビュー判定基準)、herdr.md、cli.md を置く
- Claude Code と Codex は同じ SKILL.md 規約なので、1 つのディレクトリを両方に symlink できる
- 配布方針:
- どちらもリポジトリからダウンロードして使う前提にはしていない
- SKILL.md は 2 本とも記事の付録に全文を書き下してある
- kanban CLI(4,099 行)と GUI ブローカー(511 行)は、同等品を実装できる粒度の仕様と主要部の抜粋で代替する
■ 4. セットアップ
- 前提環境:
- macOS、git、Python 3.8+、Herdr 0.7.5+
- Godot プラグインを使うなら /Applications/Godot.app と Xcode Command Line Tools
- MyKanban の登録:
- ディレクトリを 1 つ作り、SKILL.md と bin/kanban と references/*.md を自分で置けば動く
- ~/.claude/skills と ~/.codex/skills の両方に同じディレクトリを symlink し、修正を 1 箇所で済ませる
- bin に PATH を通し、スキル本文からも自分のシェルからも kanban を呼べるようにする
- allow-godot-window の登録:
- SKILL.md、herdr-plugin.toml、godot_broker.py、capture_window.swift の 4 ファイルを置く
- capture_window.swift はアーキテクチャ依存のバイナリになるため、コミットせず配置先の Mac で swiftc でビルドする
- symlink 名はリポジトリ名ではなく frontmatter の name に揃える
- herdr plugin link でその場で登録し、コピーの二重管理をしない
- allowlist の設定:
- Godot を起動してよいプロジェクトの置き場所を config.json の allowed_roots に書く
- 実際にプロジェクトを置く場所だけに絞るのが要点
- ボードの初期化:
- プロジェクトで kanban init --wip-in-progress 3 --base main を実行する
- Herdr の中で Claude Code を立ち上げ「MyKanban で並列に進めて」と言えばスキルが発火する
■ 5. 設計の核: ボードを .git/kanban に置く
- ボードの実体:
- board.json(設定)、HANDOFF.md(セッション申し送り)、events.jsonl(追記専用の監査ログ)
- tickets/、briefs/、reports/、reviews/ はラウンドごとに
-r .md の連番で、過去の分を上書きしない - .git 配下に置く意味 1:
- 全 worktree から同じボードが見える
- CLI が共有 .git を解決するので、worker は自分の worktree で kanban を叩くだけでよい
- .git 配下に置く意味 2:
- コミットにも push にも混ざらない
- ボードはこのマシン上の進行中の調整状態であって成果物ではない
- 残したい決定はコードやコミットメッセージに落としてから done にする規律になる
- 状態機械:
- backlog → ready → in_progress → review → done という Jira を簡略化した形
- 差し戻し先として changes_requested、needs_info、blocked、spike 起票がある
- worker が動かせるのは review まで、done に動かせるのは leader だけ
- CLI の大原則:
- すべて素のテキストで、cat で読め緊急時は手で直せる
- 採番と WIP 判定だけ .lock の flock で排他する
- VCS 依存はバックエンド 1 層に閉じ込め、jujutsu では .jj/repo 相当を使う
- 不正な状態遷移(worker による done、DoR 未達の ready、WIP 超過)は拒否する
■ 6. 起票と受入基準
- 受入基準が指示書の本体:
- 差し戻しの大半は起票時の手抜きが原因なので、AC は機械判定できる文言まで落とす
- 「エラーが出ない」ではなく「SCRIPT ERROR を含む行が 0 件」のように grep できる言い方にする
- 曖昧な AC は worker に推測で実装させ、その推測をレビューで否定することになる
- チケットの分割単位:
- 実装計画をそのまま渡さず、1 worker が 1 worktree で完結できる単位に割る
- 良い分割は触るファイルが重ならないこと
- 重なるなら 1 枚にまとめるか、依存で直列化する
- 数値にできない狙いの扱い:
- 「危険を突っ切る手触り」のような体感目標は --context に 1 行で入れる
- 隣のチケットとの境界の責務も --context に入れる
- どちらも worker が仕様の穴を踏んだときの判断基準になる
- 体感目標の無い起票で worker が差し戻し覚悟の独自判断を迫られた記録がある
- 検証コマンドの事前実行:
- --verify のコマンドは指示書にそのまま載り、kanban ready --check が配る前にリーダーの環境で 1 回走らせる
- 通るかは問わず、まだ実装されていないので通らないのが正常
- 見ているのは「存在しないコマンド」と「返ってこないコマンド」で、配れば worker 全員が同時に同じ罠にかかる
- 依存の宣言:
- --depends で依存を張ると、未完了の依存を持つチケットは kanban next に出てこない
- 順序を頭で覚えておく必要がなくなる
- Definition of Ready:
- kanban ready が目的、AC、size、scope の充足を検査して落とす
- --force はあるが、ここで通した曖昧さは必ず後で差し戻しとして返ってくる
■ 7. dispatch とペイン分割
- dispatch の一括処理:
- worktree 作成、ペイン分割、エージェント起動、指示書送信を 1 コマンドで行う
- worker の CLI はチケット単位で --kind により選べる
- 同一タブに並べる理由:
- 既定でリーダー自身のタブを分割して worker を並べる
- 別 workspace に散らすと止まっている worker に気付くのが遅れる
- 1 画面で全員を見張れるのが狙い
- 分割規則:
- 一番面積の大きいペインを、長い辺の側で半分に割る(同着なら左上優先)
- worker が 1・3・7 人のとき全ペインが正確に同じ大きさになり、途中の人数でも面積比は 2 倍以内に収まる
- 端末のセルは縦横比およそ 1:2 なので、幅が高さの 2 倍あたりを境に縦割りと横割りを切り替える
- 80x20 セルを確保できなくなったら同じ workspace の新しいタブへフォールバックする
- 画面の広さが実質的な並列度の上限になる
- ペイン起動待ち:
- ペインを作った直後に 1 秒待つ(board.json の pane_settle)
- Herdr は端末を確保した時点で pane split に答えるが、中のシェルはまだ rc を読んでおり、この間の入力は食われる
- エラーは出ず、ペインは空のまま・ボードは dispatch 済みという一番嫌な壊れ方をする
- 送信の確認:
- herdr の agent prompt はテキストを入力欄に置いたまま送信されないことがある
- dispatch と recall は working への遷移を確認し、駄目なら Enter を追送し、それでも駄目なら警告して申し送りに残す
- 送信確認の 20 秒後にエージェントがまだ生きているかも見届け、消えていれば終了コード 4 で落ちる
- TUI が落ちる場合:
- 対話 TUI は指示書を読む前に落ちることがあり、そのとき終了コードもログもセッション記録も残らない
- --exec は起動スクリプトを書いて流すので、出力はログに、終了コードはその末尾に残る
- エージェント名の接頭辞:
- worker 名にはプロジェクト接頭辞を付ける(starshooter-kan-001)
- Herdr のエージェント名前空間はセッション全体で 1 つなので、素の kan-003 は並行プロジェクトと衝突する
- 実際に別プロジェクトの worker に指示書が配達された事故がある
■ 8. 指示書(brief)
- ファイルで渡す理由:
- dispatch は briefs/
-r .md を書き出し、worker には「これを読め」とだけ送る - 数百行の日本語をシェル引数で渡すとクォートで静かに壊れる
- worker が後から読み返せる場所に残したい
- 指示書が worker に課すこと:
- 何よりも先に kanban ack で着手を宣言する
- 作業は自分の worktree の中だけで行い、他の worktree や main に触らない
- status: done に自分で動かさず、終点は review まで
- 報告書には主張ではなく証拠を書き、実行したコマンドとその出力を貼る
- 証拠のない報告は内容が正しくても調査差し戻しになる
- できなかったことは「実質やったのと同じ」に言い換えず、できなかったと書く
- 共通文の差し込み:
- board.json の brief_notes は全指示書に差し込まれ、プロジェクト共通の制約と実測値を書く
- リーダーの未検証の仮定は、並列体制では人数ぶんに増幅される
■ 9. worker の着手宣言と報告
- 着手宣言(ack)が要る理由:
- Herdr が端末の見た目から返す working は、起動途中の TUI でも未送信のプロンプトでも返る
- この表示を信じたまま 21〜28 分の空転が繰り返し起きた
- kanban ack はボードを通る唯一の着手信号なので、忙しそうに見えるだけの TUI には作れない
- 宣言が猶予(既定 180 秒)を超えて無ければ、kanban wait が指示未達の疑いとして即座に報告する
- 報告書の必須 6 セクション:
- 概要、受入基準の検証、実行した検証、変更点、逸脱と判断、残課題
- 逸脱と判断は「特になし」で済ませない
- セクションを省くと提出時に弾かれ、記事のデモでも実際に弾かれた
- 証拠の要求:
- AC 1 件につき 1 行、判定と証拠(実行したコマンド or ファイル:行)を対応させる
- 「動作確認済み」だけの記述は証拠にならず調査差し戻しになる
- 一時ファイルの命名:
- 報告書の一時ファイル名はプロジェクト識別子で始める
- チケット ID は別プロジェクトでも同じ番号が振られ、/tmp は共有なので、ID だけの名前は過去プロジェクトの残骸と衝突する
- 疑問が出たとき:
- 仕様に疑問が出たら推測で進めず、kanban handoff に書いて止まる
■ 10. leader の待機とレビュー判定
- 待つのはボードであってターミナルではない:
- エージェントの idle は完了を意味せず、質問して止まっているだけかもしれない
- review に移ったことだけが「報告が出た」という信号
- wait が毎ポーリングで検査する 3 つの事実:
- worker が消えた(終了コード 4)
- 承認や質問の UI で止まっている(誤検出を避けるため 2 回連続で観測してから、終了コード 5)
- ack が猶予を超えて無い(終了コード 6)
- 当てはまればタイムアウトを待たずに中断し、どの worker かと次の一手を出す
- ack 検査だけが映せる障害:
- 前の 2 つは herdr が端末の見た目から出す答えなので、「居て忙しそうに見えるのにプロンプトが届いていない」障害には盲目
- 再送は kanban recall --force で行い、文面に「差し戻しではない」と明記されるので存在しない指摘を探しに行かない
- 差分を先に見る:
- review に来たら、報告書を読む前に自分で kanban diff を見る
- 報告書を先に読むと、その筋書きに沿って差分を眺めてしまう
- 順序を逆にするだけで見落としが減る
- 判定の 3 つの問い:
- 主張は検証可能か、証拠が付いているか → 無ければ --needs-info(調査の差し戻し、コードは触らせない)
- AC を満たしているか、範囲外の変更が無いか → 満たさなければ --rework(実装の差し戻し)
- 自分に判断材料があるか → 決められなければ --spike(調査チケットを自動起票し親を blocked に)
- 3 つとも問題なければ --accept
- 順序が重要な理由:
- 証拠のない報告から AC 充足は判断できない
- 1 を飛ばして 2 を判断すると印象で受け入れることになる
- 差し戻しの書き方:
- 何をすれば受け入れられるかを必ず書く
- 指摘だけだと次のラウンドでも同じ報告が返ってくる
- needs-info と spike の使い分け:
- 同じ worker がその worktree で答えられるなら --needs-info
- 別の場所を調べる必要があるなら --spike
- spike が done になると親は自動で ready に戻る
- コンフリクト時:
- 解決は worker に返すほうが安全で、文脈を持っているのは worker
■ 11. accept と merge の分離
- 受け入れたことと本流に入ったことは別の事実:
- --accept でチケットは done になるが、マージは自動ではない
- accept は未統合のコミットが残っていればその場で数えて見せる
- 統合の入力はコミットだけ:
- worktree からファイルを直接コピーするのは一見速くて最も危険な近道
- 並行中の worker のファイルは任意の時点で中間状態にある
- コード以外の成果物(生成した音声、シーン、アセット)は差分に見えないまま落ちる
- コミットは worker が「ここが完成形だ」と宣言した唯一の地点なので、そこからしか取らない
- 同じ原因で起きた 2 つの事故:
- 効果音が 1 本も入っていないビルドを完成として通知した
- worker が書き直す前の草稿を統合していた
- cleanup が止まる条件:
- 未取り込みの報告が .kanban-outbox/ に残っているとき(--force で rescued/ へ退避後に削除)
- done なのに未統合のコミットがあるとき
- 消える可能性のあるものは消させないのが原則
- 片付けの効用:
- 分割モードの worker を片付けるとペインが閉じて残りが広がる
- 詰まってきたら終わった worker から片付けるのが画面を保つコツ
- 履歴の追跡:
- 全経緯は events.jsonl に追記され kanban log で追える
- kanban doctor が迷子の worktree、WIP 超過、宙に浮いた依存、未統合の done、取り残された報告を検査する
■ 12. エージェント CLI のサンドボックスとの戦い
- 一番手強いのはエージェント CLI 自身のサンドボックス:
- 並列エージェント運用で手強いのは herdr でも git でもない
- 同じ環境を組む人が必ず踏む
- worker はボードに書けないのがデフォルト:
- エージェント CLI は書き込みを自分のワークスペースに閉じ込め、さらにリポジトリの .git/ を別扱いで守る
- これは履歴や hook を書き換えられないための保護
- ボードは .git/kanban にあるので必ず引っかかる
- 読み取りは通るため指示書は読め、失敗するのは最後の kanban report だけという一番たちの悪い壊れ方をする
- claude の逃がし方:
- 作業ディレクトリ外への書き込み拒否と .git/ の承認必須が止める
- --add-dir <ボード> と --allowedTools "Bash(
:*)" を渡す - codex の逃がし方:
- --sandbox workspace-write の書き込み可能ルートが checkout だけで、共有 gitdir は EPERM になる
- 同じ理由で linked worktree の git commit も落ちる
- --sandbox workspace-write と --add-dir <共有ディレクトリ> は必ずセットで渡す
- --add-dir は追加で書けるようにする場所の指定なので、書き込みが許可されていない既定の権限では黙って無視されるか起動に失敗する
- 引数の受け渡し:
- kanban dispatch は kind ごとに必要な引数を worker の起動コマンドに足す(board.json の agent_args)
- 引数を拒否されたら引数なしで起動し直すので、dispatch がこれで失敗することはない
- アウトボックス:
- ボードに書けなかった報告は worker の worktree の .kanban-outbox/ に退避される
- リーダー側の kanban が次に走ったとき自動で取り込まれ review に移る
- 退避は成功であり、同じ報告を出し直さない、退避を消さない、諦めて黙って終了しないと指示書に明記してある
- アウトボックスにも書けないときは、報告書の全文を自分の応答本文に書く
- preflight:
- 使い捨てのチェックアウトを作り、worker を起こすのと同じコマンドでプローブを流す
- チェックアウトに書けるか、そこでコミットできるか、ボードに届くかを配る前に確定させる
- 失敗がいちばん遅く現れるために必要で、worktree はでき指示書は読め実装も終わってから最後だけが落ちる
- 4 体に配ってから気づいて 4 体が同時に同じ 3 枚の壁にぶつかり、3 体が独立に同じ回避策を発明した記録がある
- 急いでいるときほど、配る前に測る
- setup_cmd:
- 新しいチェックアウト直後に走るコマンドを board.json に設定する
- Godot の .godot import キャッシュや node_modules など、コミットされないが無いと動かないものを配る
- これが無いと worker には全アセットが壊れて見え、製品バグか環境かの切り分けに時間が溶ける
■ 13. Godot GUI ブローカー
- 見た目の検証が必要な理由:
- 数値の AC は「実装されたこと」しか検証できない
- 「意図が満たされたこと」は見ないと分からない
- worker はサンドボックスの中にいて自力ではウィンドウを出せない
- 放っておくと「コード上は正しいので確認済み」という報告が返り、ゲーム開発ではこれが致命的
- 型付きアクションだけを貸す設計:
- エージェントに渡すのは launch / capture / stop の 3 アクションだけ
- 実行パス、argv、環境変数、キャプチャ先はすべてブローカー側が決める
- herdr-plugin.toml の command には引数を渡す口が無い
- スキルは open、launchctl、Apple Events、Godot 実行パス、生ソケット、sh -c などの代替経路を明示的に禁じる
- シェルのサンドボックスは緩めないまま、窓を出す能力だけを貸し出す
- 起動対象の制限:
- 起動できるのは allowlist 配下の project.godot を持つプロジェクトだけ
- プロジェクトはフォーカスされたペインの cwd から最も近い project.godot を持つ祖先へ遡って解決し、allowed_root より上には出ない
- プラグインアクションは引数を取れないため、ハンドルではなく呼んだペインのプロジェクトで対象を引く
- キャプチャの制限:
- ScreenCaptureKit のヘルパに渡るのはブローカーが握っているウィンドウだけ
- 画面全体は撮らず、他のワークスペースの中身は写らない
- capture_window.swift は指定した 1 ウィンドウだけを PNG に落とす 95 行のヘルパ
- インスタンス管理:
- インスタンスは (workspace, project) ごとで、worktree を分けた並列 worker が同時にそれぞれの窓を出せる
- 同一 (workspace, project) の 2 枚目は already_running で拒否する
- PID が使い回されていた場合は緩い判定で stale なファイルがプロジェクトを塞ぎ続けるのを防ぐ
- TTL(既定 180 秒)を過ぎたら SIGTERM → SIGKILL で自分のプロセスグループだけを回収する
- エラーの返し方:
- エラーはすべて {"error": {"code": ..., "message": ...}} の JSON で返る
- worker はコードをそのまま報告書に貼れる
- 毎回 focus する理由:
- アクションの直前に必ず herdr agent focus を実行する
- 飛ばすと別の worker の worktree を起動して撮る
- 撮れた画はそれ自体としては正しく見えるので、間違いに気づく手がかりがない
- 撮り直す前に必ず stop する理由:
- 前のインスタンスが生きていると launch が素通りする
- capture が前の窓の古い PNG を同じパスで返す
- 直したのに直っていないように見え(逆にも見え)、修正の検証が丸ごと無効になる
- 報告の作法:
- 撮れた PNG は自分の目で開いて確認し、パスと何を確認したかを書く
- 撮れなかったら返ってきたエラーをそのまま書き、「コード上は正しいので確認済み」に言い換えない
- 撮れていないと分かってさえいれば、リーダーが代わりに撮れる
■ 14. kind ごとの書き分けとモデル選択
- 手順挿入の 3 条件:
- リポジトリに project.godot がある
- allow-godot-window スキルが導入済み
- worker がエージェントのペインに載っている
- kind による書き分け:
- スキルを名前で起動できるのは Claude Code だけなので、claude にはスキル起動構文を出す
- codex や grok にはブローカーを直接叩く生コマンドを出す
- 一律にスキル構文で書いた回では、非 Claude の worker が「そんなスキルは無い」と窓を諦め、5 体全員が見た目を未検証のまま返した
- 経路は最初から通っているのに教え方だけが Claude 専用だったせいで失われた、いちばん惜しい失敗
- 書き分けは CLI 側に押し込み、リーダーは --kind を選ぶだけで済む
- 非対話 worker の制約:
- --exec のペインはコマンドを走らせているだけで herdr のエージェントではないため、この経路を使えない
- その場合の指示書は「見た目の確認はリーダーに依頼し、未検証と明記する」に切り替わる
- 見た目が効く成果物では、--exec の速さと実機確認のどちらを取るかをチケット単位で決める
- モデル選択の基準:
- 機械的に検証し切れる size S の chore や rename や定型修正は安いモデルで十分
- デバッグ、アルゴリズム、複数モジュールを跨ぐ変更はコードに強い kind か上位モデル
- 迷ったら既定のままにし、選定に悩む時間がモデル差の節約を食い潰さないようにする
- 決めた基準は HANDOFF.md に書き、セッションを跨いで同じ基準で配る
- レビュー基準は下げない:
- 安いモデルは報告書の証拠が薄くなりがちだが、3 つの問いは据え置く
- 下げると「安く実装して高く直す」ことになる
- 原因がモデルの力不足にありそうなら粘らずに cleanup し、一段上のモデルか別 kind に配り直す
- 差し戻し 1 往復は dispatch 1 回より高いので、往復が始まった時点で安いモデルの節約は消えている
■ 15. 運用してみて分かったこと
- 並列度の決め方:
- 並列度は「同時に何人動かせるか」ではなく「同時に何件まともにレビューできるか」
- WIP 上限 3〜4 を超えるとレビュー待ちが溜まり、worktree 間のコンフリクトが増え、リーダーの吟味が雑になる
- 分割レイアウトでは画面の広さ(floor(幅/80) × floor(高さ/20) ペイン)も同じ上限を示す
- review の滞留が最も高くつく:
- worker は次の仕事を持てず、worktree は生きたまま、main はその間も動く
- review は最優先で捌く
- 端末の見た目を信じない:
- idle は完了ではなく、working は着手ではない
- 完了はボードの review、着手はボードの ack だけで判定する
- この置き換えで、21〜28 分かかっていた「プロンプト未達」の発見が数分に縮んだ
- リーダーの文脈もボードに残す:
- セッションの申し送りは HANDOFF.md に書き、セッションを終える前と長い作業の区切りで更新する
- 文脈が切れた新しいリーダーは kanban board → HANDOFF.md → kanban show の順で復帰できる
- チケットごとの申し送りは全ての状態遷移、割当、レビューが自動で積まれる
■ 16. まとめ
- 並列エージェント開発で壊れるのは調整であり、全 worktree から見える 1 つのボード(.git/kanban)に固定する
- leader は判定、worker は実装と報告を担い、終点を分けることで自己採点を防ぐ
- 報告書は主張ではなく証拠であり、レビューは「検証可能か → AC → 判断材料」の順で通す
- accept と merge は別の事実であり、統合の入力はコミットだけにする
- サンドボックスとは戦わず、必要な許可を dispatch が渡し、駄目ならアウトボックスで受ける
- Godot の見た目の検証は、型付きアクション 3 つだけの GUI ブローカーで worker 自身に返す
- 人間相手との共通点と相違:
- Kanban も Jira ももともと人間どうしの調整が壊れないための仕組みだった
- 相手がエージェントになっても壊れ方は驚くほど同じで、処方箋もほぼ同じ
- ただし「端末の見た目を信じない」「証拠を要求する」あたりの締め付けは、人間相手より強めにする必要がある