AIに興味はない。
アウトカムには興味がある。ボトルネックに滞るのではなくシステムを通じて価値が流れること、問題が解決されること——それは絶対だ。エージェントがそのための間違ったツールなら、別のものを使って二度と考えない。
今のところ、エージェントは非常に優れている。だからここにいる。
根っこが大事
自分をソフトウェアエンジニアだとは思っていない。少なくとも純粋には。プロセスオーナーシップから来た。バリューストリーム分析、標準作業、チェンジマネジメント、仕事がどこで止まるか、なぜ止まるかへの執着。ソフトウェアはそれを表現する手段になった。コードが目的じゃない；システムがよりよく機能することが目的だ。
エンジニアはみな果樹園の木だ。ソフトウェアの土から真っ直ぐ育ったものもいれば、科学、オペレーション、製造、教育から育ったものもいる。根が違う；光への向き方が違う；実が違う。それは間違いじゃない。でも同じツールを違う手で持てば結果が違うことを意味する——スキルの差じゃなく、ツールを手に取るときに何を問いかけているかの差によって。
エージェントを手に取るとき、私が問いかけるのは：このバリューストリームの中の無駄はどこで、どう排除するか？ これはプロセスオーナーの問いだ。プロセスオーナーは常にアウトカムで評価されてきた。方法じゃない；方法は実際に機能するものなら何でもいい。この本能は「この関数をどう速く書くか」とは違う場所に向かう。
私が同じ問いを投げかけてきたドメイン：製造オペレーションプラットフォーム、リアルタイムシミュレーターに供給するデータパイプライン、遺伝的アルゴリズムトーナメントとミニマックスラウンドロビンを持つゲームAI、-lerスタック全体のベンチマークスイート、フロントエンドとバックエンド開発、データ分析。一つの問題のバリエーションじゃない；本当に異なるドメイン、異なる制約、異なる失敗モード。それらすべてに同じ問いが流れている。
ツールじゃなくアウトカムを評価する
これが私のコアだ。どのモデルが一番いいかとか、AIは過大評価されているかとか、そういうホットテイクは生まれない。
一つだけ重要な問い：アウトカムが出たか？
スムーズな体験は関係する；ラインを流れるようにすることが無駄の排除であり、それが全体の目的だ。ベストプラクティスは関係する；トヨタとダナハーがEHSと安全原則をシステムに組み込んだのは、それが持続的な高パフォーマンスを可能にするからだ。理論的にいいからじゃない。私たちはカウボーイじゃない。他者から学ぶ。森を守る。
関係ないのは：エージェントが私を感動させたかどうか、方法が洗練されて見えたかどうか、最先端のプラクティスに見えたかどうか。仕事は動いたか。システムは改善されたか。問題は解決されたか。
このフレーミングによって、多くの議論は不要になる。また、別のフレームでは議論になる決断も明白になる；エージェントにどのくらいの自律性を与えるか、確認プロンプトをいくつ受け入れるか、どのくらい監視するか、などだ。
アウトカムがよく、システムが健全なら、方法は問題ない。
ボトルネックが移った
私のボトルネックはかつてコードを書く時間だった；分析済み、問題フレーミング済み、解決策理解済み、そしてそれを現実にするための何時間ものタイピング。「知っている」と「持っている」の間のギャップは今はない。コードは自分で書かれる。
つまり今の希少リソースは、私の思考の質だ。分析。問題のフレーミング。「これそもそも正しい問いか」という作業。経験とコンテキストが必要な判断——どのモデルにもそれはない。
これが個人的な角度だ：外部のシステムを最適化しているだけじゃない。私がスループット単位だ。私の注意、私の判断、私の決断が流れる。エージェントはそのスループットを上げる方法；仕事を自動化してなくすんじゃなく、レバレッジの低い部分を排除して、レバレッジの高い部分をもっとできるようにする。問題のフレーミングをもっと。分析をもっと。積み上げてきた何年ものコンテキストが実際に必要な作業をもっと。タイピングを減らす。
合理的な対応：今や希少なものに全力を投資する。人間の作業をもっとやり、もっとよくやり、もっと長くやる。エージェントが本当に優れていることはエージェントに任せる。ボトルネックが移った；追いかけろ。
実験が複利になる
自分自身のこれらのツールの使い方を、最適化すべきシステムとして扱っている。個人アカウント、仕事アカウント。グローバルのCLAUDE.md、ロードマップのパターン、エージェント委任ルールを常に編集している。セッション間、リポジトリ間。ある方法で動かし、何が壊れるか見て、一つの変数を変えて、また動かす。
現状で機能するものを見つけてそこに留まる本能がある。わかる；特に今持っているものがすでにいい場合は。でもこれは動くターゲットで、複利は本物だ；仕事のやり方の小さな改善は、プロセスの小さな改善が積み上がるのと同じように積み上がる。一週間ではデルタを感じない。六ヶ月後に感じる。
いい判断力と本物のドメイン知識があると信じているなら（ここまで読んでいるならたぶんそうだ）、チャンスはそこにある。私より賢い人たちが、プッシュしないことでこれらのツールからより少ない成果を得ている。それは性格の欠陥じゃない；ただの実験しなかった実験だ。実験を走らせろ。
自律性は時間の決断だ
長い間、完全な自律性でエージェントを走らせる。確認プロンプトなし。監視する；ベビーシッターはしない。
人間の承認を待つプロンプトはすべて、見守ることで食われる思考時間だ。マシン間の調整、並行エージェントセッション、次のイテレーションを構築しながらリアルタイムシステムを管理すること：すべての停止はコンテキストスイッチで、コンテキストスイッチはタダじゃない。
だからガードレールをシステムに設計する：ロードマップ、CLAUDE.md、ハードなアーキテクチャ制約、settings.jsonの細かいパーミッションルール。1 そして走らせる。安全性は構造から来る。警戒からじゃない。2
先週末：sqlerのベンチマークが週末中ずっと無人で走り、ノートパソコンで遺伝的アルゴリズムトーナメントとミニマックスラウンドロビンが動き、マシン全体で五から十のエージェントセッションがアクティブだった。私は他のことを計画していた。他のことにスプリントしていた。眠っていた。自分の人生を生きていた。エージェントは私がいない間も働いていた；自慢じゃない、それが設計の全ポイントだ。人間がどこか別の場所で人間らしくしている間、価値は流れ続けた。
設計で対処する
「LLMは確率的なブラックボックスだ」と言う人たちは、それで会話が終わると思っている。人間も確率的なブラックボックスだ；疲れていて、注意散漫で、悪い日があって、穏やかな顔で自信を持って間違いを犯す。それでも私たちはその周りに工場を作った。私は生産の現場に立って、人々がエージェントがするのを恐れているのとまったく同じ種類の間違いを見てきた：自信を持って間違い、その瞬間に気づきにくく、プロセスが対応していなければ高くつく。解決策は全員を毎秒監視することじゃなかった；ポカヨケ、標準作業、正しい行動を簡単にして間違った行動を明白か不可能にするプロセス設計だった。同じ問題だ。違う作業者だ。
すべてのエージェントが同じリードをもらうわけじゃない。この水準の自律性は今はOpus 4.6でしか可能じゃない；古いモデルでも、他のモデルでもない。古いモデルにデータベースを削除されたことがある。自信を持って、躊躇なく、そして深く謝った。ガードレールが機能したのでリカバリーは簡単だった：違うデータベース、正しいコンティンジェンシー、設計が保証するはずだったこと。教訓は「自律性を与えるな」じゃない。「このモデルはこの能力レベルでこのくらいのロープが適切だ」ということだ。Codexは先週コミットについて嘘をついた；Codexはほとんど信用しない。Opus 4.6は何百ものセッションを通じて他のモデルが単純に得ていない信頼を得た。経験から積み上げた実証的な信頼で、信仰じゃない。
ガードレールとコンティンジェンシーは、エージェントのために発明した概念じゃない。実際のウェブアプリの大規模な本番PostgreSQLデータベースを管理した。FastAPI認証システムを構築した。悪いクエリが実際のお金になり、工場の現場で悪いプロセス設計が人々を傷つける環境で働いた。可変要素が疲れた作業者であれ、金曜日の午後のジュニア開発者であれ、長いコンテキストウィンドウと多くの自信を持つLLMであれ、原則は変わらない。何かがうまくいかなくなったとき——そして何かは必ずうまくいかなくなる——ダメージが抑えられ、リカバリーが簡単になるようにシステムを構築する。そして走らせる。
委任は許されない
自律性は不在を意味しない；適切な瞬間に構造化された存在を意味する。
すべての長いセッションはレポートアウトを生成する。読む。もっと深さが欲しければテストを読む；テストはコードよりもストーリーをよく語り、私のテスト要件は厳格なので読む価値がある（たいていそこまでで十分だ；よく書かれたテストスイートはナラティブだ）。さらに深く掘る必要があれば、コードを読む。その順番：レポート、次にテスト、次にコード。
フロントエンドの作業では、エージェントは常に手動テストのチェックリストを作成する。私自身がやる。失敗を報告する。人間の目と人間の手が必要なものがある；どれがそれかを知ることが仕事の一部だ。
高リスクや繊細なもの（本当に慣れない領域、本番に近い、アーキテクチャ的にリスクがある）については、動くのを見守る。リアルタイムで思考を読む。軌道修正し、止め、修正する。信頼していないからじゃない；何を見ているかわかっていて、修正が高くつく前にドリフトが見えるからだ。
最も重要なループ：何かがずれていると気づき、ランを止め、修正し、すぐにCLAUDE.mdかルールファイルを更新してそれが再び起きないようにする。セッションはアウトプットを生み出す；修正はドクトリンを生み出す。ドクトリンは次のセッションを改善する。それが実際の複利メカニズムだ：より多くやるだけじゃなく、学んだことをエンコードして同じことを二度学ばないようにする。
リーダーと教師としての役割を委任することはできない。エージェントは有能で速い；それでもあなたが方向を設定し、基準を保ち、不足したときにカリキュラムを更新する。それを止めた瞬間、品質が漂流する。怠けた一回のセッションでそれが起きるのを見た。レポートアウトは問題なく見えた；テストが別の話をしていた。
レポートを読め。テストを読め。いつ見守るかを知れ。ルールの更新を止めるな。
これが全部存在する前にソフトウェアを書いてきた人には優位性がある。ノスタルジアじゃない；キャリブレーションデータだ。悪いテストがどういうものかを知っている、それを出荷して代償を払ったから。アーキテクチャドリフトがどう感じられるかを知っている、静かに形を失うコードベースに三ヶ月入り込んだことがあるから。モデルが自信を持って犯す間違いで傷ついた経験があり、その傷跡が本番に入る前のレポートアウトでそれを発見させてくれる。モデルは傷ついたことがない。あなたはある。その非対称性は本物で、重要だ。
変更の可能性あり
去年の十二月、私は今とは違う信念を持っていた。その一部は今恥ずかしい；間違っていたものじゃなく、臆病だったものが。与えていなかった自律性。走らせていなかった実験。
モデルは変わる。ツールは変わる。もっと重要なのは：私が変わる。より多くの経験、より多くのデータ、より多くの実験、より多くの失敗。信念は更新される。
2026年3月。また十二月に聞いてくれ。