別府に住んでいて、家に温泉を引いている。 かけ流しなので、蛇口で湯量を調節して湯船の温度を保っている。
この蛇口が前から固くなりかけていたのだけれど、夏に湯量を絞ったまましばらく放置していたら、とうとう固着して回らなくなってしまった。
固着した蛇口の直し方を調べていろいろ試したものの、どれもうまくいかなかった。 まだ暖かかったので、そのうちなんとかしようと後回しにした。
そうしたら急に寒くなった。 湯量が少ないままなので、湯船に溜めてもすぐに冷めしまう。 温泉に入れない。別府に住んでいるのに。
慌てて蛇口お分解して中の部品を直接回そうとしたけれど、びくともしない。
諦めてプロに頼んだら、その場で蛇口を交換して一瞬で直してくれた。 あれだけ悩んだのはなんだったのか。 最初から頼めば良かったねとなった。
自分でなんとかしようとして寒い思いをするくらいなら、さっさとプロに頼るべし。
2026年11月6日、Lauren Tan (@poteto) が X にこう書き出す投稿をしました。
hot take: you don't need a software factory, and i don't love the term. it's just marketing
同じ日のうちに Factory の CTO である Eno Reyes が、同意するところは多いが中心の主張には同意しない、と応じました。 2日後には Jeffrey Lee-Chan が The software factory is the next extinct wrapper という記事を出しています。 Software Factory として売られている機能は、コーディングエージェントの進歩によって3〜6ヶ月のうちに大半の人が必要としなくなる、という予測です。
Tan、Reyes、Lee-Chan が「Software Factory」で指しているものは一致していません。 以下は2026年11月9日時点の公開資料に基づく整理です。
「Software Factory」と書かれているとき、差しているものは少なくとも三つあります。
| 使われ方 | 指しているもの | 例 |
|---|---|---|
| 製品の分類名 | 売り手が自社の製品を説明するときの呼び名 | Warp、Factory、8090、GitLab |
| 開発の進め方 | バグ報告や顧客の声を受けて実装からリリースまで進め、本番で起きたことを次の作業に戻す一連の仕組み | Factory の定義、Prinevo の整理 |
| エージェントの編成 | 指揮役のエージェントや複数の工程を常に置くのか、スキルと基準だけで済ませるのか | Warp のドキュメント、Lee-Chan の記事 |
Factory は会社の名前でもあります。 同社の解説も 「software factory」は概念の名前で、Factory はその一実装の会社と製品だと分けて書いています。
The Beat の整理によると、「Software Factory」という語は GitLab、Harness、Opsera、Uber などが使っていて、米国防総省は何年も前から使っています。 OpenAI は自社の製品を「Codex as a platform」と呼び、この語を使っていません。 2026年11月2日時点で、この語は共有されたマーケティング用語になっている、というのが The Beat の見立てです。 一方で、使用量の料金を API 価格への上乗せ率として明示しているのは、Warp と SuperPlane という小さな売り手だけだそうです。
2026年9月から11月にかけて、次のような批判が出ています。
| 論者 | 主張 | 根拠 |
|---|---|---|
| Lauren Tan | Software Factory は不要で、言葉自体がマーケティングにすぎない。必要なのは良いソフトウェア工学と、トークンを正しい場所に使うこと。決定論的な処理を増やすほど良く、トークンの消費も減る | 短い投稿のみで、数値や事例は示していない |
| Jeffrey Lee-Chan | モデルが強くなるほど、モデルの外側に足す仕組みは要らなくなる。製品が売りにしているエージェントの調整は3〜6ヶ月で大半の人に不要になり、残るのは自社のスキルと基準だ | 自身の WorldAI 開発で、約1週間、1日約100件の PR をマージした（以前は約20件）という自己報告 |
| Auditless Research | 本来は開発のループが自動で閉じる仕組みを指すはずだが、いま売られている製品はそうなっていない。多くの組織の制約はレビューの人手なのに、ベンダーへの依存が生まれるプラットフォームを先に売っている | Factory の説明の引用と、クラウド移行期のベンダー依存との比較 |
| Irfan Suleman | 1980年代の日本と米国防の Software Factory は、数えやすい成果を追って行き詰まった。2026年のものが違うのはエージェントそのものより、社内の知識を機械が読める形に整える点だ | 過去の事例の記述と、Uber が公表した数字 |
| Pekka Enberg | エージェントをクラウドの sandbox で自律的に動かす流れは、自分の働き方と逆だ。隔離は OS に任せ、ソースコードは人が読む | 自身の開発経験。Software Factory の製品への反論として書かれたものではない |
Tan が問題にしているのは用語そのものです。 Lee-Chan は製品の寿命、Auditless は売り方、Suleman は測るもの、Enberg は働き方。
Lee-Chan の方針は「front-load alignment, back-load verification」（先に認識を揃え、検証は後ろに寄せる）です。
残すと書いているのは権限の境界とテスト、実際のユーザージャーニー、証拠、マージとリリースの権限です。
公開している pr-lifecycle スキル（2026年11月9日時点の main）にも、独立レビュー、SHA に紐づく証拠、完了の認定とマージ権限の分離が書かれています。
Reyes によると、ほとんどの人は Software Factory と呼べるシステムを実際には持っていません。 AI で出荷を楽にしただけの状態を見て、Software Factory という種類のシステムがそもそも存在しないと考えている、という見立てです。
Software Factory とは、すべての作業が通るプロセスを標準化することで、人が書いても AI が書いても同じ検証を通す、と Reyes は書いています。 Factory の場合は Slack のスレッドや Sentry のアラートなどのシグナルから始まります。 最初の検証は Droid（同社のエージェント）のレビューとセキュリティレビューです。 続いて「a risk judge that can't see who wrote it」（誰が書いたか見えないリスク判定）、CI、ライブプレビューでの QA を通します。 本番で壊れたら原因の PR まで辿ります。
目標は「regret-free merge rate」（後悔しないマージの割合）です。 同時に「Most of our changes still get a human stamp.」（大半の変更にはまだ人の承認が入る）とも書いています。
Factory と Warp も、公式の説明では無条件の自律を謳っていません。
| Factory | Warp | |
|---|---|---|
| 定義 | バグ報告や顧客の声を受けて、計画、実装、テスト、レビュー、リリース、監視まで回し続けるループ。モデルを選べること、組織が自分で管理できること、学習し続けることを条件にする | foreman（指揮役のエージェント）が品質方針を満たす最短の手順を選ぶ。不要な工程は飛ばし、やり直しが必要なら前の工程に戻す |
| 人の関与 | 自律は時間をかけて段階的に進めるもので、最初から人手なしで動いている組織はないとする。小さなタスクは通常のセッションで、複数の機能にまたがる作業は Mission で扱う | 仕様の承認と、不明点の確認で人を待つ。マージするかどうかはチームが決める |
| 計測と改善 | 開発の全工程を計測し、障害を原因の PR まで辿れるようにする | 設定はファイルで管理して PR でレビューする。自動で出た改善案も PR として届き、人が確認するまで採用されない |
| 数字の扱い | 顧客が報告した数字は特定の作業での結果で、一般的な生産性の向上を示すものではないと明記している | 自社のタスクの約30%を Software Factory で自動化しているという自己報告 |
Reyes の説明する標準化については、Lee-Chan が、基準はスキルとガードレールに書けるので Software Factory を製品として買わなくてもよい、と応じています。
Sohit Kumar の Software Factory vs Coding Agent は、コーディングエージェントとその周りのデリバリーの仕組みを分けます。 この仕組みは共有の文脈、担当者、ハンドオフ、検証の証拠からなります。 自作か製品かは問わず、「Start with the bottleneck you can observe」（観測できるボトルネックから始める）と勧めています。 Prinevo というベンダーの記事です。
Addy Osmani の Your coding agents made you a manager は Software Factory という語を弁護していません。 書いてあるのは、合否がはっきり出る自己検証と証拠、目的、制約、対象外、完了条件を書いた指示、修正を重ねても直らなければセッションを捨てること。 プロンプトやスキルは依頼で、強制は hooks や deny ルールが担うという区別と、並列の数は検証が追いつく速さまでという話もあります。
Steve Yegge は「I have given up on building reusable harnesses」（再利用できるハーネスはあきらめた）と書いています。 一方で、ゲーム Wyvern のために自前の Software Factory である Wheelhouse を動かしています。 Wheelhouse は計画、実装、レビューで役割とモデルを分けていて、憲法と450の法的文書を持ち、規模は約60万行（ほとんど bash）です。 Wyvern の作業の20〜25%は Wheelhouse 自体の保守だそうです（いずれも Yegge 自身の報告）。
Lee-Chan はこれを、再利用できる製品より案件に固有の判断に価値がある例として引いています。
Reyes、Lee-Chan、Osmani、Warp と Factory の公式は、書き方は違っても、検証と証拠と完了の条件を前提にしています。 人の関与も残っていて、Factory では大半の変更に人の承認が入り、Warp の既定ではマージをチームが決め、Lee-Chan はマージの権限を残します。
割れているのは次の五つです。
| 争点 | 批判する側 | 反対の立場 |
|---|---|---|
| 用語そのもの | 単なるマーケティング用語だ（Tan、The Beat） | 実際に作った人が少ないので、存在しないと思われている（Reyes） |
| 汎用の製品は残るか | 3〜6ヶ月で大半の人に不要になる（Lee-Chan） | 全工程の計測や、品質方針に沿った手順の選択を製品が担う（Warp、Factory） |
| 何を約束しているか | 経営層には「infinite loop with 0 people」（人手ゼロで回り続けるループ）を売りながら、実際の mission は有限だ（Auditless） | 自律は段階的に進めるもので、最初から人手なしで動いている組織はない（Factory） |
| 何を測るか | PR 数のように数えやすいものを追うと失敗する（Suleman） | 後悔しないマージの割合を目標にし、本番の障害を原因の PR まで辿る（Reyes） |
| どこに作るか | 自社のスキルと基準に書けば足りる（Lee-Chan） | 案件専用のシステムとして作る（Yegge）、自作でも製品でもよいが担当者と検証の証拠は要る（Prinevo） |
出回っている数字のほとんどは自己報告です。 Lee-Chan の 100 PR/日、Warp の約30%、Suleman が引く Uber の数字。 The Beat が留保つきで紹介している CampusIQ の PR あたり約29ドルも、トークン代だけで集計期間の記載がありません。 どれも欠陥率を示す数字ではありません。
Lee-Chan の予測どおりなら、2027年の春には大半の人が Software Factory の製品を必要としなくなっているはずです。 そのころこの語がどう使われているのか、気になりますね。
Uber と CampusIQ の数字、歴史の話は Suleman と The Beat の記事経由で、元の文献の中身までは確かめていません。
形式手法を勉強し始めたので、道具を触る前に考え方だけ自分用にまとめておきます。
テストで分かるのは、試した入力で正しく動いたことだけです。
ソート関数を [3, 1, 2] や [] で試して通っても、同じ値が並ぶ [2, 2, 1] やとても長い配列のことは何も言えない。
形式手法は、プログラムや設計の性質を数学の言葉で書いて「どんな入力でも成り立つ」と言い切るための方法の総称です。 ソート関数なら「どんな配列を渡しても、返る配列は昇順に並び、要素は入力と同じものが同じ数だけある」を、すべての配列について確かめます。
テストは試した点を調べて、形式手法は全体を調べる。 そのぶん、性質を曖昧さなく書く手間と、全体を調べきるための計算や証明の手間がかかります。
仕様は何が正しいかを曖昧さなく論理式で書いたもの、実装は実際に動くコードです。 検証が確かめるのは「実装が仕様を満たすか」だけ。
銀行口座の出金処理なら、仕様は「出金後の残高 ＝ 出金前の残高 − 出金額」と「残高は負にならない」のように書けます。 検証が通れば、実装はこの2つを必ず守ると言えます。
ただ、仕様に「手数料を引く」を書き忘れていたら、手数料を引かないコードも検証を通ります。 検証済みは「仕様どおり」という意味で、「バグがない」という意味じゃない。 何を仕様として書いたかは、結局人が読んで確かめるしかない。
処理を始める前に成り立っているべき条件が事前条件、処理が終わった後に成り立つと約束する条件が事後条件です。
この組を書く代表的な記法がホーア論理の三つ組 {P} C {Q} で、「P が成り立つ状態で C を実行し、C が終われば、Q が成り立つ」と読みます。
「x が 5 なら、1 足した後は 6」と「出金額が残高以下なら、出金後も残高は負にならない」はこう書けます。
{ x = 5 } x := x + 1 { x = 6 }
{ amount ≤ balance } balance := balance - amount { balance ≥ 0 }
amount ≤ balance がなければ事後条件は守れないので、事前条件は呼び出す側が守るべき約束でもあります。
ソート関数なら、事前条件はなし（どんな配列でもよい）、事後条件は「出力は昇順」かつ「出力は入力の並べ替え」。 「出力は昇順」だけを書くと、常に空配列を返す関数も合格してしまう（最悪）。
不変条件は、ある範囲の中でいつ見ても成り立っている性質で、2種類あります。
ループ不変条件は、ループの各回の始めに必ず成り立つ性質です。
配列 a の合計を求めるループ（i を 0 から n まで進め、s に足していく）なら、「各回の始めで s = a[0] + … + a[i-1]」がそれ。
ループが終わったとき i = n なので、そこから s が全体の合計だと導けます。
システム不変条件は、システムがどの状態にあっても成り立つ性質です。 銀行なら「どの口座の残高も負にならない」「全口座の残高の合計は、入金の合計から出金の合計を引いたものに等しい」など。
証明の中心は、多くの場合この不変条件を見つけることです。 ループや状態遷移は何回繰り返されるか分からないけど、1回進めても壊れない性質が見つかれば、何回繰り返しても成り立つと言える（数学的帰納法と同じ形）。
ただ、守りたい性質そのままだと1回進めただけで壊れることがあって、もう少し強い性質を探す必要があるらしい。 ここに人の工夫が要ります。
信号機の交差点で考えます。
安全性は「悪いことは決して起きない」性質で、「東西と南北の信号が同時に青になることはない」のようなものです。 違反するなら、違反に至る有限の手順（反例）を示せます。
活性は「良いことはいつか必ず起きる」性質で、「赤で待っている車線は、いつか必ず青になる」のようなものです。 違反は「ずっと青にならない」という無限の実行なので、確かめ方が安全性より難しくなります。
ずっと全部赤の信号機は、事故は起きないけど誰も勧めません。 安全性だけだと何もしないシステムが合格してしまうので、両方書きます。
大きく3種類あります。
システムを状態と状態の移り変わりで表し、到達できる状態を全部たどって性質を調べます。 信号機なら、色の組み合わせと切り替わりの規則を書いて、到達できるすべての組み合わせで「同時に青」がないかを見る。
全自動で、性質が破れれば反例を出してくれます。 ただ、変数や並行に動く主体が増えると状態の数がかけ算で増える（状態爆発）ので、口座は2つ、利用者は3人のように小さく絞って調べます。 代表例は TLA+ の検査器 TLC です。
Quint も仕様を書いて調べる言語で、モデルと性質を書くと TLC や Apalache でモデル検査できます（quint verify）。
ランダムに動かすシミュレータ（quint run）も付いていて、こちらは違反を見逃すことがあるけど、見つけたら反例を出してくれます。
ソフトウェアのモデリング言語だと Alloy もあります。
ループの回数や手順の長さに上限を決めて、その範囲を全部調べる有界モデル検査（Biere ら、1999年）もあります。 C や C++ 向けの CBMC や Rust 向けの Kani がこれで、上限を超える振る舞いは保証しません。
「性質を破る入力は存在するか」を、制約を満たす値を探す問題として解きます。
出金処理なら「amount ≤ balance かつ balance - amount < 0 を満たす整数はあるか」と聞く。
「ない（unsat）」と返れば性質はどんな整数でも成り立ち、「ある（sat）」と返れば具体的な値が反例として返ります。 多くは自動で答えが出るのだけれど、式の種類によっては「分からない（unknown）」が返ります。
代表例は Z3 と cvc5 です。 プログラムの検証器の内部でもよく使われていて、検証機能付きの言語 Dafny や Rust 向けの Verus は Z3 を使います。 CBMC は SAT ソルバー（SMT の土台にある、真偽値だけを扱うソルバー）を基本に使います。
性質の証明は人（最近は LLM も）が一歩ずつ書きます。 その一歩一歩の正しさを、証明チェッカーが機会的に確かめます。 ソート関数なら「出力は昇順」を、配列の長さについての帰納法で証明していく。
有限に絞る必要がなく、無限の入力や任意の大きさのシステムについて言い切れます。 その代わり証明の道筋は人が与えることになるので、手間はとても大きい。 代表例は Rocq（旧 Coq）、Lean、Isabelle です。
既存のファズテスト（ランダムな入力を流すテスト）を仕様にして、Claude が 123 のライブラリで「64MB 未満のどんな入力でもテストが落ちない」ことを Rocq で証明した報告も出ています。
| 手法 | 自動化の度合い | 言える強さ | 手間 | 代表ツール |
|---|---|---|---|---|
| モデル検査 | 全自動 | 絞った有限の範囲で全部 | 小（モデルを書く） | TLC、Quint、CBMC、Kani（有界） |
| SMT ソルバー | ほぼ自動（unknown あり） | 解ければ全入力で成立 | 小〜中（制約に落とす） | Z3、cvc5 |
| 定理証明 | 人が道筋を書く | 無限の範囲でも言い切れる | 大 | Rocq、Lean、Isabelle |
どんなプログラムについても性質が成り立つかを必ず正しく判定する道具があればいいのだけれど、それは作れないことが証明されています。
停止性問題は、任意のプログラムがある入力で止まるかどうかを必ず正しく判定するプログラムは存在しない、という定理です（Turing の1936年の論文が元になっています）。 ライスの定理は、「0 を返すことがあるか」「配列の外を読むことがあるか」のような振る舞いの性質も、自明でないものは一般には判定できないと言っています（Rice、1953年）。
そのため、どの手法もどこかで諦めています。
| 手法 | 諦めたもの | 残るもの |
|---|---|---|
| モデル検査 | 調べる範囲を有限に絞る | 範囲の中は全自動で答えが出る（外は保証しない） |
| SMT ソルバー | 「分からない」と答えることを許す | 答えが出たときは正しい |
| 定理証明 | 証明を自動で見つけること | チェッカーは与えられた証明が正しいかを機械的に判定できる |
| 分野 | 内容 | 例 |
|---|---|---|
| 命題論理 | 真か偽かが決まる文を「かつ（∧）」「または（∨）」「でない（¬）」「ならば（→）」でつなぐ | 東西が青 → 南北は赤 |
| 述語論理 | 変数を含む条件と「すべての（∀）」「ある（∃）」を加える | ∀口座 a. 残高(a) ≥ 0 |
| 集合と関数 | 状態の範囲や対応を書く | 信号の色の集合 {赤, 黄, 青} |
反例探しは「∃口座 a. 残高(a) ＜ 0」が成り立つかを調べることに当たります。 ソートの「入力の並べ替え」は、「各値の出現回数を数える関数が、入力と出力で等しい」と書ける。
大学初年度の論理と集合の範囲で足りる気がします。 読み書きできれば十分で、難しい定理を覚える必要はなさそう。
| 用語 | 意味 |
|---|---|
| 健全性（soundness） | 道具が「成り立つ」と言ったら本当に成り立つこと。健全でない検証器は間違った証明を通してしまう |
| 完全性（completeness） | 成り立つ性質なら道具が必ず「成り立つ」と言えること。誤った警告や「分からない」がない |
| 証明チェッカー | 書かれた証明の一歩一歩が論理的に正しいかを機械的に確かめるプログラム。信頼すべき部分を小さく保てる |
| 形式モデル | CPU、OS、プロトコルなど現実のシステムを数学の言葉で書いたもの。モデルと現実のずれは検証の外に残る |
実用的な検証器は健全性を優先して、完全性はあきらめることが多いらしい。 バグ検出ツールの文脈では「報告したバグは本物」を健全性と呼ぶこともあって、分野で向きが逆になるのはちょっとややこしい。
本文の出典も含めて、どれも概要をさらっただけで、中身はちゃんと読めていません。
Kindle Oasis で本を開こうとしたら「Item Not Available」と出て開けなかった。別の本も、その次の本も同じで、ライブラリにある本がぜんぶ開けなない。
Grok bot に相談したら、Reddit などから似た症状の報告を集めてきてくれた。端末の空き容量が極端に少ないと起きる、いわゆる「スペースバグ」というのがあるらしい。
設定 → 端末オプション → 端末情報で見てみると、たしかに空き容量がほとんど残っていない。症状も似ているので、これではということで Grok bot が挙げた手順を試すことにした。
まず機内モードにして、電源ボタンを 40 秒ほど長押しして強制再起動する。
そのあと Mac に USB でつなぎ、ドライブとして認識されるまで数分待ってから、安全に取り外して再起動する。USB でつなぐだけで何が変わるのかはよく分からない。
最後は Wi-Fi に戻して同期し、日時が合っているかも確認した。
これで本が開けるようになりました。
Grok bot からは、これでも直らなければ手動でアップデートするか、登録解除して再登録する、最悪は工場出荷リセットという案も出ていた。リセットすると端末内の本は消えるので、そこまで行かずに済んでよかった。
端末内ストレージの一覧情報（インデックス）が壊れていたんじゃないか、というのが Grok bot の見立て。ちゃんとした原因は分かっていない。
任天堂の宮本茂さんが、文化勲章の受章が発表される前日の記者会見で生成 AI について聞かれ、「作る」ことと「作業する」ことを分けて考えている、と話していた。 何かを作るときはまず大きな構成を作る。そこから先の、空いている穴を埋めたりきれいに仕上げたりするのが「作業」だという。
ワープロやコンピューターがレタリングのような技術的な部分を引き受けたことで、レイアウトのセンスのような個人のデザイン能力は表に出てきた。 生成 AI で起きているのもそういうことだ、とも言っていた。
面白いのはその続きで、宮本さんは「作業って楽しいんです」と言う。 作業をしていると作っている満足感があって、怖いのはその作業に満足して「けっこういいものができた」と勘違いしている自分だ、と。
ここしばらくもやもや考えていたことに、ちょうど名前をもらえた気がした。
木を切る人は、コードを書くこと自体が目的の人。 きれいな設計や、問題を解いているときの没入、手に馴染んだ道具で精度よく仕上げる職人性に喜びがある。
家を建てる人は、プロダクトを作ってユーザーに届けることが目的の人。 コードは家を建てるための木材加工で、手段にすぎない。
一人の中に両方いることがほとんどで、どっちに比重があるかの違いだと思う。（僕もコードを書くのはふつうに好き） 宮本さんの言葉に寄せると、木を切るのが「作業」、どんな家を建てるかを決めるのが「作る」にあたる。
AI で急に安くなったのは、木を切るコストのほうです。 手斧がチェーンソーになり、さらにプレカット工場になったくらいの変化で、寸法を伝えれば加工済みの部材が届く。
一方で、どんな家を誰のために建てるかという問いは変わらない。 施主と話して要件を決め、間取りを設計し、安全基準を満たしているかを検査する仕事は、部材の加工が速くなっても消えない。 部材が大量に届くぶん、検査の比重はむしろ上がる木がする。
先日、友人たちと AI レビューの話をしたときも、AI レビューだけで回すのはまだ怖いという点では全員一致していた。 落としどころは、高リスクな変更を機械的に見つけてそこだけ人が見る、というあたり。 「SWE はもともと不確実性との戦いだった」と言っていた人がいて、木を切る部分が機械化されてもそこは残るんだろうなと思う。
木を切る人にとって、この変化は喪失として届きやすい。 手を動かして解く時間が減って、自分が何者なのかが揺らぐ。
家を建てる人にとっては、加工待ちが消えて設計や対話に時間を使える解放として届く。 同じ道具の変化が、目的をどこに置くかで逆の意味になる。
Baldur Bjarnason の「Software developers are not okay」 は、前者の側から書かれた文章だと思う。 開発者の燃え尽きや離職の広がりを、人員を減らして働き手の交渉力を削ぎたい経営側のインセンティブで説明している。 主流のソフトウェア開発はこの先も良くならないだろうから、業界の外の将来も考えたほうがいい、と結んでいる。
彼も木工の比喩を使っている。 電動工具は作り手の思い入れを減らさなかった。 けれど LLM は自動化というより委任に近く、作り手を成果物から切り離してしまう、という。
その切り離しの感覚は、木を切ることに目的を置いた人の視点としては正確だと思う。 ただ、それをソフトウェア開発者全体の結論に広げているところには同意できない。 委任で切り離されるのは木からであって、家からではない。部材の加工を工場に頼んでも、家を建てた実感はなくならないはずです。
かといって、木を切る人を「目的を取り違えた人」と読むのも違う。 職人性への愛着はこれまで品質を支えてきたし、喪失感は本物だ。
宮本さんの「作業って楽しいんです」は、その裏返しなんだと思う。 そして家を建てる側も、作業の満足感を「作った」実感と取り違えうる。AI が出してきた大量の部材を眺めて家が建った気になるのは、たぶん僕のほうだ。
家を建てる側の仕事は、たぶんこんな形に分かれていく。
棟梁と設計者の仕事は、宮本さんの言う「作る」そのものだ。 検査官は、友人たちと話した落としどころ（高リスクな変更だけを人が見る）にそのままあたる。
道具を作る層は、安定した場所ではない。 Anthropic は、意図分類器や固定の多段パイプライン、多数のサブエージェントといった構造の多くが、モデルにはもう要らない仕事をしていた事例を報告している。道具そのものも、モデルに吸収されていく。
職人の領域については、友人の一人が「決定的に作れるものは決定的に作りたい。HSM 周りのように、良いモデルだけでは解決できないところもある」と言っていた。
では、家を建てる側に回れば安泰かというと、そうでもない。 部材の加工が速くなれば、一件あたりに必要な人数も減る。 Baldur の議論の中心にある雇用の問題に、この比喩は答えていない。
境界もきれいには引けない。 アーキテクチャやデータモデルの設計は、木を切ることと家を設計することの両方に属している。
いちばん引っかかっているのは育成です。 設計の目は、木を切る経験で育っていた面がある。木の癖を知らない設計者が、プレカット部材の不具合を見抜けるのかは分からない。
判断力を育てていた手作業を自動化が取り上げる、ということはほかの分野でも起きてきた。 木を切ったことのない人の育て方には、そこに糸口がありそうだと思って少し調べた。
航空では、American Airlines の Warren Vanderburgh 機長が 1997 年の訓練講義で、操縦室で一番多い質問は「What's it doing now?」だと言った。 そして、画面のマゼンタ色の経路線と自動化に頼りきった操縦士を「Children of the Magenta」と呼んだ。 勧めたのは自動化を捨てることではなく、状況に応じて自動化のレベルを下げることと、条件が許すときは手で飛んで腕を保つことだった（AOPA の解説）。
2013 年には FAA が SAFO 13002「Manual Flight Operations」 を出して、手で飛ぶ機会を運航方針と訓練へ組み込むよう、航空会社へ求めている。 現場の機長が言っていたことを、16 年後には規制当局も文書で求めたことになる。
外科では Matt Beane の研究がある。 ロボット手術になって執刀医が一人で手術できるようになり、研修医の実技時間は開腹手術に比べて 10〜20 分の 1 になった。それでも腕を上げた研修医は、シミュレーターや手術動画を使った反復を、承認された訓練の外で自主的にこなしていた。 Beane はこれを shadow learning と呼んでいる（UCSB の紹介記事）。
建築では、Sherry Turkle の『Simulation and Its Discontents』が、鉛筆で設計しなくなった建築学生を描いている。 若い設計者たちが、師匠世代の持つ建物や身体についての暗黙知を必死に取り込もうとしている、とも書いている。 分野としてどう応じたかまでは確かめきれていない。
プログラミング自体にも前例がある。 John Backus の回想によると、1954 年当時のプログラマーは効率のよいプログラミングは自動化できないと確信していた。 FORTRAN チームは、手書きに近い効率のコードを出せなければ受け入れられないと考え、言語設計よりコンパイラの出力効率に力を注いだ。道具の側が品質を示して信頼が移った例なので、ほかとは少し性格が違う。
どの分野でも、答えは昔の手作業に全部戻ることではなかった。 判断力を育てる作業を選んで、訓練として意図的に残す方向だった。
ソフトウェアに当てはめると、このあたりだと思う。
最後のは、Beane が著書『The Skill Code』で言っていることでもある。
コードの書き方は、AI でこれからも変わっていくと思う。 ただ、プロダクトを作ってユーザーに届けるという目的のほうは変わっていない。
僕は家を建てる側に軸足を置いて、木を切る作業は道具に任せる範囲を広げていくつもりです。 （とはいえ手で木を切るのも楽しいので、そこは趣味として残しておきたい）
気をつけたいのは、宮本さんの言う勘違いのほうだ。 部材が速く大量に届くと、それだけで何かを作った気になりやすい。届いた部材でどんな家が建ったのか、住む人にとっていい家なのかを見る目は、道具に任せられない。
その目をどこで養うのかは、まだ分からない。 木を切る経験の少ない人がどこで検査の目を身につけるのか。僕自身も、木を切る時間が減ったあとで今の目を保てるのか。 自動操縦を切って手で飛ぶ時間を、自分たちのチームではどう作ればいいのか考えている。
コーヒー豆はほとんどオンラインで買っています。 ただ、買うのはいつも知っているお店ばかりで、同じところをぐるぐる回っていた。
それもちょっともったいない気がして、2024年の秋くらいから全国の焙煎所を調べて、まだ買ったことのないお店から取り寄せる活動を始めました。都道府県をひとつずつ埋めていく感じで、いまも続けています。
買ったお店がだいぶ増えてきたので、地図にまとめたサイトを作りました。
載せているのは通販で買ったお店だけで、店頭やカフェで買った分は入れていません。 いまのところ64軒、43都道府県で、通販での購入は117回。残りは富山、福井、鹿児島、沖縄。
ピンを押すと、そのお店で買った豆と感想が出ます。何度も買っているお店には回数が付くので、自分がどこに偏っているのかが一目で分る。STYLE COFFEE だけ27回で、ひとりだけ桁が違う。
都道府県の塗りつぶしもあって、色の付いていない県を眺めて次に買うお店を探すのに使っています。
地図は Leaflet と 国土地理院の淡色地図 で描いていて、データは Notion に付けていた記録と注文メールを付き合わせて JSON にしました。
富山、福井、鹿児島、沖縄で通販をやっている焙煎所を知っている人がいたら教えてください。
以前の記事でClaude CodeをAgent Safehouseのsandboxに入れて使っていると書いたけど、nonoに乗り換えた。
きっかけはLinuxマシンでもClaude Codeを動かすようになったこと。Safehouseはsandbox-execをラップするやつなのでmacOS専用で、Linux側は素のままになっていた。nonoはmacOSではSeatbelt、LinuxではLandlockを使ってカーネルレベルでアクセスを制限してくれる。しかも設定は同じJSONのプロファイルで書ける。MacとLinuxで同じsandboxを1つの設定で管理できるのが決め手だった。
MacはHomebrewで入る。
brew install nono
Linuxはインストールスクリプトが用意されている。Debian・Fedora・Archのパッケージもあるので、詳しくは公式のインストール手順を見てください。LandlockのためにLinuxカーネル5.13以降が必要です。
curl -fsSL https://nono.sh/install.sh | sh
あとはnono runでコマンドを包むだけ。
nono run --profile claude --allow-cwd -- claude
Safehouseとの一番の違いは、ポリシーをJSONのプロファイルで宣言的に書くところ。プロファイルはextendsで継承できて、registryで配布されているnolabs-ai/claudeを土台にできる。~/.claudeへの書き込み許可や~/.ssh・キーチェーン・シェル履歴の拒否といったClaude Code向けの基本設定が最初から入っている。中身はnono profile show nolabs-ai/claudeで確認できます。
自分のプロファイルはこれを継承して、手元で使うディレクトリやソケットを足していく。OSごとの差分はplatform_overridesに書く。
{ "extends": "nolabs-ai/claude", "filesystem": { "allow": ["$HOME/.cache"], "read": ["$HOME/.config/git"] }, "platform_overrides": { "linux": { "filesystem": { "allow": ["$HOME/local/src"] } }, "macos": { "filesystem": { "allow": ["$HOME/Library/Developer/Xcode/DerivedData"], "unix_socket": ["$HOME/.gnupg/S.gpg-agent"] }, "unsafe_macos_seatbelt_rules": [ "(deny file-write* (subpath \"/Users/sixeight/.config/nono\"))" ] } } }
（実際はこの何倍もあるので、雰囲気だけ）
allowが読み書き、readが読み取り専用で、Safehouseの--add-dirsと--add-dirs-roにそのまま対応する。型付きの設定で表現できないものはunsafe_macos_seatbelt_rulesに生のSBPLを書ける。Safehouseのときに.sbファイルで足していたルールはここに移した。
Safehouse時代の設定は、168行のシェルスクリプトと.sbファイル9個の寄せ集めになっていた。これをnonoのプロファイル1枚と短いsafeラッパーに置き換えた。対応はだいたいこんな感じ。
| Safehouse | nono |
|---|---|
--add-dirs / --add-dirs-ro |
filesystem.allow / filesystem.read |
.sbで足したUnixソケットの許可 |
unix_socket / unix_socket_dir |
.sbで足したそれ以外のルール |
unsafe_macos_seatbelt_rules |
--enable=clipboard |
何も書かずに通った |
worktree用の--add-dirs |
safeから--allowで渡す |
safeラッパーも書き直した。worktreeのためにメインリポの.gitへ書き込みを許可するのは前回と同じで、nonoでは--allowで渡す。
args=(run -s --profile claude --allow-cwd)
git_info="$(git rev-parse --show-toplevel --git-common-dir 2>/dev/null || true)"
if [[ "$git_info" == *$'\n'* ]]; then
git_root="${git_info%%$'\n'*}"
git_common_dir="${git_info##*$'\n'}"
[[ -d "${git_root}-worktrees" ]] && args+=(--allow "${git_root}-worktrees")
if [[ "$git_common_dir" != ".git" ]]; then
args+=(--allow "$(dirname "$git_common_dir")")
fi
fi
exec nono "${args[@]}" -- "$cmd" "$@"
Linux側はこれだけで動いた。Macはこれまで通すために積み上げてきた例外が多いぶん、いくつかハマった。
HOMEでは起動できない。nonoは自分の状態を~/.local/state/nonoに置いていて、それを含むディレクトリ（HOMEや~/.local/state）は許可できない。HOMEでClaude Codeを起動することがたまにあるので、safeではHOMEのときだけ--workdir ~/.config/claudeでsandboxに入り、中でcd ~している。~/.local/stateもまるごとは許可できないので、gh・mise・pnpmなど必要なものだけ個別に許可した。
sandboxの入れ子ができない。SwiftPMやxcodebuild、Codexは自前でsandbox-execをかけようとする。けどnonoのSeatbeltの中ではネストできず、sandbox_apply: Operation not permittedで落ちる。それぞれのsandboxを外すshimを書いてPATHの先頭に置いた。外側のnonoの制限はそのまま効いているので問題ないと判断している。
case "${1:-}" in
build | test | run | package)
exec "$real_swift" "$1" --disable-sandbox "${@:2}"
;;
esac
exec "$real_swift" "$@"
gpg署名。nolabs-ai/claudeは~/.gnupgを拒否するグループを含んでいる。その中のロックファイルへの書き込みは型付きの設定（bypass_protectionとallow_file）では通らなかった。生のSBPLで書いたら通った。sandbox内のgpgはgpg-agentを起動できないので、safeで事前にgpgconf --launch gpg-agentしておく必要もある。
Unixソケット。tmuxやcolimaのdockerなど、ソケットにconnectするものはunix_socketで明示的に許可しないと繋がらない。
/tmpに書けない。書き込めるのは/tmp/claude-$UIDだけなので、Pythonのtempfileがカレントディレクトリにフォールバックしてリポジトリに一時ディレクトリを残していた。safeでTMPDIRをそこに向けて解決した。
拒否されたパスを調べるときはnono why --self --path <path> --op readをsandboxの中から叩くと理由を教えてくれるので便利。
あと、sandboxの中から自分のプロファイルを書き換えられると、次の起動で権限を広げられてしまう。なので~/.config/nonoへの書き込みは拒否している。Safehouseのときと同じで、プロファイルの変更はsandboxの外からやる。
MacとLinuxで同じsafe claudeが同じように動くようになって、めちゃくちゃ楽になった。
