一人の会社を18のClaude Codeで回す 「できた」は本人以外の証拠で確かめる
グロースマーケティング出身のBalance Zhao氏は、Claude Codeの18のセッションと約20の定時ジョブで一人の会社を回し、壊れた経験から得た教訓をGitHubで公開した。軸は、エージェント自身の「できた」を信じず、作業した本人ではない証拠で判定する決まりだ。
記事の内容を自社でどう進めるか、内容が固まっていない段階でも相談できます。仕事の相談
毎週 1 回、その週の記事から 5 本と実践の 1 本を選んでメールで届けます。ニュースレターを購読する(無料)

AIエージェントに仕事を任せるほど、「できました」という報告をどう扱うかが問題になる。グロースマーケティング出身のBalance Zhao氏は、Claude Codeの18のセッションと約20の定時ジョブで一人の会社を回し、壊れた経験から得た8つの教訓をGitHubで公開した。中心にあるのは、エージェント自身に「できた?」と聞かず、送信側のログや実際の状態といった、作業した本人ではない証拠で判定する決まりだ。
人に上げる用件は6つだけ
Zhao氏がGitHubで公開した一人の会社の設定と教訓のまとめによると、組織はHQ(本部の役のエージェント)と4人のリード(領域ごとの責任者の役)で組み、役割カードは45枚ある。いずれも10月28日時点の設定として書かれた数字だ。
エージェントが本人に上げてくる用件は、6つに絞った。悪い知らせ、プロダクトの判断、支出、取り消せない削除、自分のルールの変更、公開の6つだ。支出や削除のように取り返しのつかない操作と、外に出る公開が、人の手元に残る形になる。それ以外は、エージェントの側で片付ける。一人で18のセッションを見るには、人が判断する場面を先に決めておく必要があるというわけだ。
「完了」に5つの証拠を求める
Zhao氏は「完了」の定義を書いた第5章で、タスクを閉じる条件を5つの証拠と定めた。1つ目は、どの層が実際に間違っていたかという原因。2つ目は、回帰テスト(同じ不具合が戻った時に落ちるテスト)などの再発防止。3つ目は、同じ間違いがほかに無いかの総ざらいだ。4つ目は本番や実データでの通しの確認で、手元で一度動いただけでは足りない。5つ目は後片付けになる。どれか1つでも欠けていれば、タスクは閉じない。
同じ章には「A stopgap isn't a fix.」(その場しのぎは直しではない)とある。症状が消えただけでは完了と見なさず、本当の直しが入るまでタスクを開けたままにしておく決まりだ。まとめのページによると、6週間で扱った67件のタスクのうち、5つの証拠をすべてそろえて閉じたのは33件だった。差し戻しが8件、まだ開いているのが26件ある。67件のうち、5つの証拠をそろえて閉じられたのは半分ほどにとどまる。
判定役は問いごとに1つ
「問いごとに判定役は1つ」と題した第4章は、ある失敗から生まれた。2026年9月、Zhao氏のアカウントが週の利用上限に達し、定時のジョブが起動の時点で全部失敗した。困ったのは、その失敗を知らせるはずの報告のジョブも同じアカウントで動いていて、一緒に止まったことだ。Zhao氏が気付いたのは、上限が戻った9月16日に、プロダクト担当のリードが抜けを指摘した時だった。
そこで今は、定時の21件の配信が届いたかどうかを、モデルを呼ばないスクリプトが判定する。エージェントに聞けば、たいていは「届いた」と返ってくる。だが、その答えは作業した本人の見立てにすぎない。だから判定役が読むのは、配信を送った側が残したログだけだ。作業したエージェントに「届いた?」とは聞かない。つまり、見張る仕組みが見張られる側と同じアカウントに乗っていれば、止まる時は一緒に止まる。判定役をモデルの外に置いたのは、その穴をふさぐためだ。
ルールの半分近くは機械が止める
まとめのページによると、登録したルール170件のうち、破られた時に止めるスクリプトを持つのが82件、定時で検査するのが41件、運用の心がけだけに頼るのが47件ある。心がけだけのルールは、エージェントが忘れればそれで終わる。半分近くは機械が止め、4件に1件あまりは人の注意に任せている計算だ。さらに、ルールが実在するゲート(止める仕組み)に結び付いたままかを、別のスクリプトで検査している。ルールの数だけでなく、どれが本当に守らせる仕組みを持つかを数えている点が目を引く。
「直った」の前に証拠を出させる
Zhao氏は、Claude Codeのフックclaim-checkも公開した。エージェントが応答を終えようとすると動くStopフック(Claude Codeが決まった時点で呼ぶスクリプト)で、「直った」と言わせる前に証拠を出させる。10月28日に自分の5,429ターンを再生したところ、完了を主張した560ターンのうち112ターンに裏付けが無かった。過去のセッションの記録に、claim-checkの判定を当て直した結果だ。完了の報告の5件に1件は、根拠の無いまま出ていたことになる。
ただし、claim-checkは続けて止めることはしない。エージェントをループに閉じ込めないためだ。誤って止めた時は「誤検知はバグ」として扱う。裏付けの無い「できた」を減らしつつ、仕組みそのものが仕事の邪魔にならないようにしている。
数字はいずれも本人の申告で、第三者の裏付けはページに無い。こうして見ると、Zhao氏の会社は、エージェントの「できた」を信じる代わりに、送信側のログや5つの証拠、止めるスクリプトといった本人以外の証拠で回っている。
編集部の見方
取り入れるかは別として、まず理解するなら、エージェント自身に「できた?」と聞かず、送信側のログや実際の状態という、作業した本人ではない証拠で判定する点を見てみるといいかもしれない。Claude CodeやCodexで定時のジョブを回しているなら、届いたかどうかを誰が判定しているか、その判定役が見張る相手と同じアカウントに乗っていないかを書き出す手がかりになる。
出典
に確認(日本時間)
- GitHubで公開した一人の会社の設定と教訓のまとめ(github.com)
- 「完了」の定義を書いた第5章(github.com)
- 「問いごとに判定役は1つ」と題した第4章(github.com)
- claim-check(github.com)
この記事は役に立ちましたか
ありがとうございます
ありがとうございます



