AIコーディングを「工場」として設計する。Benedict Bradyの現場ノート
AIコーディングエージェントを本気で使い込んでいくと、単発のチャットとして扱うか、それとも一種の生産ラインとして設計するかで、得られる成果が大きく変わってくる。開発者のBenedict Bradyが公開した「Notes on the software factory」は、後者の立場に立った実践メモだ。もとは投資会社Ellipsis Labsのオフィスで行った「vibe coding(感覚まかせのAIコーディング)」に関する講演を文章化したもので、エージェントに何を与え、どこを速くし、何がまだ弱いのかを、現場の手触りで箇条書きにしている。
「ソフトウェア工場」という比喩がしっくりくるのは、この記事が個々のプロンプト術ではなく、人間とエージェントが一緒に回すワークフロー全体をどう組み立てるかを扱っているからだ。すでにエージェントを日常的に触っているエンジニアやテックリードにとって、次の一手を考えるための見取り図になる。
原文はこちら: https://www.benedict.dev/software-factory
まず、モデルに「道具」を渡す
記事の出発点はシンプルだ。エンジニアが使っているのと同じ道具一式をエージェントに与えよ、というもの。デプロイを叩くCLI、フロントエンドを確認するためのブラウザ、テストやシミュレーションを回す高性能マシン(著者はModalを挙げている)、といった具合だ。長い工程を最後までやり切らせるには、人間の開発者が持っているインフラへのアクセスをエージェントにも与える必要がある、という理屈である。
面白いのは、こうしたセットアップは「チームに一人、正しく組める人がいて、その環境を他のメンバーに配れる」形になりがちだという指摘だ。ボトルネックになっている部分にこそ事業機会がある、という視点にもつながっている。
速くすべきなのは「考える前後」
次のテーマは、遅い工程を見つけて速くすること。ここで著者が強調するのは、思考ステップの周辺、つまり実行やチェックにあたる部分をすべて高速かつ並列化しておくべきだ、という考え方だ。狙いは、ボトルネックを「実行」ではなく「思考」そのものに寄せること。実行が足を引っ張らなくなれば、モデルが考える時間が全体の律速になる。実行状況を監視するループを走らせておく、という具体策も添えられている。
批評役を置き、考える時間を増やす
品質を上げる工夫として、二つの点が印象的だった。一つは「批評役(critic)」を別エージェントとして立てること。作業しているエージェントとは切り離した、まっさらな文脈を持つエージェントに成果物を評価させ、改善案を出させる。ルーブリック(評価基準)をテキストで定義し、そこに到達するまで反復させる/goalのようなパターンが、長い工程の一貫性を保つのに効くという。
もう一つは、品質が思考量に比例するという観測だ。「ベンチマークのスコアは思考時間とともに伸びる」ため、難しい問題ほど思考の度合いを上げよ、という素直な提案になっている。かつては文脈長の制約から明示的なプラン作成の工程を挟んでいたが、制約が緩みつつある今は、形式的なプランモードは省きつつ「先に測ってから切る」原則だけ残せばよい、と方針の変化も率直に書かれている。
弱点は「記憶」と「長時間運用」
ここが個人的にいちばん腑に落ちた部分だ。理想は、背後で静かにユーザーの好みを学習してくれる記憶機能だが、現実はそこまで来ていない。モデルは記憶ファイルへの書き込みや削除はできるものの、多様な人間の好みに合わせて振る舞うようには十分に訓練されていない。将来的には「夢を見て内省する」ような仕組みが信頼性を上げるかもしれない、と展望が述べられている。
現時点で難しいと挙げられているのは、極端に長時間走るワークフローの管理、事業コンテキストの抽出、継続学習とサンプル効率、そして常時稼働するエージェントだ。ここは補足になるが、多くのチームが「エージェントは短距離走は速いが長距離走は苦手」と感じている実感とよく重なる。
スキル、GitHub、そしてスタックの作り替え
記事の後半は、より踏み込んだ将来像に向かう。著者は「スキル」を、ワークフローや環境固有のクセを記した文書として位置づける。モデルは毎セッションで一から学び直すため、先にスキルを読ませれば立ち上がりを短縮できる。ただしモデルが賢くなるにつれ、この種のスキルは要らなくなっていくだろうと見ている。これは、汎用的な計算と学習が特化した工夫を上回るという「苦い教訓(the Bitter Lesson)」への目配せだ。
さらに大胆なのが、GitHubは役割を終えるという予測だ。エージェントがすべてのプルリクをレビューし、統合テスト一式が揃うなら、人間中心のレビュー基盤の意味は薄れる。そもそもコードは高度に圧縮された出力であり、エージェント同士はトレースやスキル、文脈といったもっと帯域の広い情報でやり取りすべきだ、という主張だ。だからこそ、AWSからIDEまでを人間ではなくエージェント向けに縦に作り替えた「エージェントネイティブなスタック」が要る。速いデプロイループ、エージェント向けのトレース、容易なテストとロールバック、段階的な権限管理、エージェントへのアラート通知などが要件として並ぶ。
その文脈で「End-to-Endでテストできないものは、システムにとって巨大な負債だ」という一節は強い。統合テストが充実していればこそ、エージェントに大規模な作り替えを任せられる、という因果である。入力手段としてのタイピングも帯域が狭いと見なし、音声入力を経て、いずれ会話や環境音、映像といった文脈の取り込みへ進むだろうと展望している。ローカルとクラウドの使い分けが今は中途半端だ、という現状認識で締めくくられる。
読みどころ
一つひとつの主張は目新しいものばかりではないが、「工場」という一貫した視点でエージェント活用を並べ直しているのが、この記事の価値だと感じた。道具を渡し、ボトルネックをずらし、批評役で品質を担保し、テスト基盤の上で作り替えを任せる。この順番で自分たちの開発フローを点検してみると、どこが人間頼みのまま止まっているかが見えてくる。まだ弱いと明言されている記憶と長時間運用については、過度な期待をせずに設計する、という現実的な姿勢の参考にもなる 🛠️。
出典: Benedict Brady「Notes on the software factory」(2026年7月8日)。ニュースレター『Leadership in Tech』で紹介。原文: https://www.benedict.dev/software-factory