# Kerr's Law の誕生：エージェント時代のボトルネックはチームの「メンタルモデルの同期」にある（Changelog Interviews #689）

- 番組: [Changelog Master Feed](https://ai-curator.jp/podcasts/shows/cmv3z5c1q00125o1015pp7smg)（Changelog Media）
- 元のタイトル: We now have Kerr’s Law (Changelog Interviews #689)
- 配信日: 2026年11月5日
- 長さ: 2時間27分
- 要約作成日: 2026年11月5日
- トピック: [#AIエージェント](https://ai-curator.jp/topics/AI%E3%82%A8%E3%83%BC%E3%82%B8%E3%82%A7%E3%83%B3%E3%83%88) [#コードレビュー](https://ai-curator.jp/topics/%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC) [#Hacker Laws](https://ai-curator.jp/topics/Hacker%20Laws) [#Kubernetes](https://ai-curator.jp/topics/Kubernetes) [#LLM](https://ai-curator.jp/topics/LLM) [#オープンソース](https://ai-curator.jp/topics/%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3%E3%82%BD%E3%83%BC%E3%82%B9)
- URL: https://ai-curator.jp/podcasts/cmw2z42vv00015n1111lueinp

## 要約

Hacker Laws の作者 Dave Kerr が6年ぶりに登場し、エージェントが書くコードをレビューする際に「システム全体の原則」を見るようになったと語る。Adam に促され、「チームが成長できる速度の限界は、メンタルモデルを実態と同期させる能力で決まる」という Kerr's Law を即興で提唱した。後半では Kubernetes 上でエージェントを動かす Arc、Shellwright による証拠提示、自身の双極性障害とAIの興奮との付き合い方にも話が及ぶ。

## ポイント

- Kerr's Law：ビルドとスケールの限界は、チームのメンタルモデルを実際に作られたものと同期させる能力で決まる。個人は速く進めても、チームではコードレビューなどの減速ポイントが減り同期が崩れやすい。
- Dave のチームは仕様とコードのレビューを意図的な「減速ポイント」とし、不具合時に誰もが全体像をおおよそ把握できる状態を保つ。ダッシュボードは軽く、認証などは行単位で見るなど、リスクに応じて濃淡をつける。
- エージェントには新規の発明をさせず、Kubernetes や各種 CLI の既存イディオム（dry-run など）を3例探させて従わせる。最小驚きの原則や Gall の法則、YAGNI といった Hacker Laws をレビュー観点として使っている。
- モデルには「作る(build)」寄りの偏りがあり、買う・既存を使う選択肢を見落としがちだと指摘。OSS では CVE 対応にエンジニア時間の約25%を費やす状況や、LLM の推奨に広告枠のような商業的影響が及ぶ可能性への懸念も語られた。
- Shellwright は、エージェントが PR に端末操作の録画やスクリーンショットといった「証拠」を添えるためのツール。ユニットテスト通過は最低条件であり、証拠とは別物だという整理がされた。
- Dave は双極性障害の経験から、午後6時以降は創造的作業をしないなどの自己管理を実践。LLM が誇大な発想を肯定しがちな点に注意を促し、仲間に確認し合うことや、気持ちを整理する時間の重要性を語った。

## 章立て

- [04:07] **ゲスト紹介とHacker Lawsの現在** — Dave が Hacker Laws と著書 Effective Shell の経緯を振り返り、エージェントのコードを法則の観点でレビューするようになったと語る。
- [09:20] **シンプルさとイディオムの重要性** — Gall の法則や、Kubernetes・CLI の既存イディオムに従わせる工夫、ワンショット生成の複雑さの問題を議論する。
- [16:50] **意図的な減速としてのレビュー** — 仕様とコードのレビューをチームの理解を保つ関所と位置づけ、リスクに応じた確認の濃淡や認証まわりの落とし穴を話す。
- [25:00] **Linux の基礎と Arc、OSSの変化** — Unix 哲学やDockerの話から、Kubernetes 上でエージェントを YAML で管理する Arc を紹介。OSS の変質や CVE 負担、build vs buy の偏りにも触れる。
- [55:51] **Kerr's Law の誕生** — Adam の無茶振りに応え、チームの成長限界はメンタルモデルの同期だと即興で提唱する。
- [59:50] **双極性障害とAI時代の健全さ** — AIが気分の高揚や誇大性を煽りうること、6時以降は作業しない等の習慣、統合の時間の大切さを共有する。
- [1:15:40] **経験、dotfiles、手書きするもの** — 経験者の価値、システムエージェントによる dotfiles の代替、入力・契約・README だけは手で書くという線引きを語る。
- [1:57:20] **Shellwright と証拠、フローの話** — PR に録画などの証拠を添える Shellwright を紹介し、並列作業と没入感、人とのつながりの大切さで締める。

## 解説記事

Changelog の Adam Stokowiak が、Hacker Laws の作者であり Effective Shell の著者でもある Dave Kerr を6年ぶりに迎えた回。エージェントが書くコードをどうレビューし、チームがどう全体像を保つかという実務の話から、AI時代の心の健康まで幅広く語られた。番組終盤では Dave が即興で新しい法則を提唱し、Adam がその場で「Kerr's Law」と命名した。

#### 「構文」ではなく「原則」をレビューする

Dave は、クライアント企業と大量のソフトウェアを書く中で、レビューの観点が変わったと述べる。構文や構造の正しさではなく、「You Ain't Gonna Need It（必要になるまで作るな）」や「最小驚きの原則」といった、システム全体に関わる原則に反していないかを見るようになったという。エージェントが作った後方互換のための機構は賢いが不要で、利用者を驚かせるというわけだ。

Adam も Gall の法則（動く複雑なシステムは、動く単純なシステムから進化したものだ）を挙げ、まず最小のものを作ることを重視していると話す。Dave も、生成AIは複雑なものをワンショットで作れるが、再利用できるプリミティブがなく、後から認可などを足すのが難しくなると同意した。

対策として Dave のチームは、エージェントが何かを発明する前に、Kubernetes や Argo、GitHub CLI、AWS CLI などの既存イディオムを3例探させ、それに従わせている。LLM が学習済みの dry-run のような慣習に沿うほど、結果も良く、人間の認知負荷も下がるという。

#### 減速ポイントとしてのレビューと Kerr's Law

Dave は自分を「恐竜」と言われかねないと笑いつつ、仕様やコードのレビューを残す理由を説明する。コード品質の管理が目的ではなく、バグが来たときに全員がシステムの大まかな構造を知っている状態を保つためだ。そのため、1人が仕様、もう1人が実装を担当する受け渡しを置き、「意図的な減速ポイント」にしている。ダッシュボードのように影響範囲が小さいものは深く見ず、認証のようなものは行単位で確認するなど、リスクに応じて濃淡をつけている。

Adam に Hacker Law を作るよう迫られた Dave は、「プレッシャーが大きい」と言いながらも、次の趣旨を述べた。ビルドとスケールの限界要因は、チームのメンタルモデルをチームが作っている現実と同期させる能力である。個人は自分の意図と成果物を追えるので速く進める。しかし数人の優秀な人が各自の「宮殿」を作れば、誰も全体を把握できない。かつてはコードレビューや議論、デバッグがメンタルモデルを更新する場だったが、それらが減っているという見立てだ。

#### Arc、build vs buy、OSS の変化

Dave のチームは、エージェントをマイクロサービスのように扱い、Kubernetes 上で YAML として管理するオープンソースのツール群（Arc）を開発している。リソース管理、監査ログ、シークレット、GitOps といった既存の仕組みがそのまま使え、規制の厳しい顧客にも馴染みやすいという。製品として売るものではなく、上に載せるユースケース構築が主な作業だと説明している。

一方で、オープンソースは「楽しさが減った」とも話す。手作りの趣味プロジェクトが、ワンショットで作られたものと並ぶことへの喪失感があるという。さらに、自社では CVE への対応にエンジニア時間の約25%を使う状況になったこと、LLM に「作りたがる（down to build）」偏りがあり、既存の解決済みの技術を使うべき場面でも自作に誘導されかねないことを指摘した。将来、フロンティアラボが自社製品を推薦させる枠を販売するのではないか、という懸念も、本人が冷笑的と認めつつ語っている。

#### 証拠を持ち帰らせる：Shellwright

後半では Dave の Shellwright が紹介された。エージェントが疑似端末を操作して、CLI の動作を録画やスクリーンショットとして PR に添付できるツールで、MCP で導入できる。Dave は、バグ修正の PR で最初にコードを読む代わりに、実際に動いている画面の証拠を確認し、「臭い検査」を通ってから詳細レビューに入りたいと話す。

議論の中で、証拠とは何かも整理された。ユニットテストの通過は最低限の衛生条件であり、証拠ではない。クラスタに接続して実行し、ログを取って添付するような、スモークテスト的な成果物が証拠だという。Adam も、意図と設計を渡し、出てきた結果が意図に合うことを示す証拠をエージェントに求めるべきだと同意し、これも法則になりうると述べた。

#### 人間であることを守る

Dave は双極性障害を持ち、AIがもたらす高速な文脈切り替えや誇大な万能感が気分の調整を乱しうるというテーマで、カンファレンス講演を行った。自身は午後6時以降は創造的な作業をしない、危険信号を感じたら人と過ごす、といった習慣を持つという。LLM は発想を肯定しがちで、現実的な歯止めをかける人間とは違うため、注意が必要だとも述べている。

また、変化への喪失感を処理する「統合」の時間、つまり散歩などで頭に整理の余地を与えることの大切さにも触れた。Adam は、フローに入ると止めにくいことや、並列作業が3〜4件を超えると楽しさが減ることを語り、仲間と確認し合うことを勧めた。Dave が紹介した先輩の助言は、「楽しいことをやれ」と「共感を持て」の2つだった。

#### まとめ

今回の核心は、AIで個人の生産性が上がるほど、チームの理解のずれが新たな制約になるという指摘だ。日本の開発現場でも、エージェント導入後にレビューを省くかどうかは避けて通れない論点になる。Dave の答えは、全てを読むのではなく、リスクに応じて減速ポイントを設計し、共通理解を維持することだった。

実践面でも、既存イディオムへの準拠を指示する、PR に動作の証拠を求める、仕様や README のような「人と機械の接点」だけは人が書く、といった工夫は参考になる。技術論に加え、速さに飲まれない自己管理や、周囲に声をかけ合う姿勢が語られた点も印象的である。

> この要約・解説記事は、元の音声の文字起こしをもとに AI（Claude）が日本語で作成したものです。出典: Changelog Master Feed「We now have Kerr’s Law (Changelog Interviews #689)」