# スロップコードからソフトウェアファクトリーへ

- 番組: [Agentic Conversations (formally mlops.community)](https://ai-curator.jp/podcasts/shows/cmv3z5c0n000l5o10j1ogyu9h)（Demetrios）
- 元のタイトル: From Slop Code to Software Factories
- 配信日: 2026年10月30日
- 長さ: 47分
- 要約作成日: 2026年10月30日
- トピック: [#コンテキストエンジニアリング](https://ai-curator.jp/topics/%E3%82%B3%E3%83%B3%E3%83%86%E3%82%AD%E3%82%B9%E3%83%88%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%83%AA%E3%83%B3%E3%82%B0) [#MCP](https://ai-curator.jp/topics/MCP) [#Computer Use](https://ai-curator.jp/topics/Computer%20Use) [#コーディングエージェント](https://ai-curator.jp/topics/%E3%82%B3%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%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%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%83%95%E3%82%A1%E3%82%AF%E3%83%88%E3%83%AA%E3%83%BC) [#エージェントUI](https://ai-curator.jp/topics/%E3%82%A8%E3%83%BC%E3%82%B8%E3%82%A7%E3%83%B3%E3%83%88UI)
- URL: https://ai-curator.jp/podcasts/cmvtt1umh00014511bwmgj10e

## 要約

HumanLayer の CEO で「コンテキストエンジニアリング」の名付け親とされる Dexter Horthy が、アムステルダムでタンデム自転車に乗りながら Demetrios Brinkmann と語った回。「コードは雑でも次世代モデルが直してくれる」という期待への疑問、computer use の実用例、MCP ツール設計、チャットUIの限界、そして各社の主任エンジニアが個別に作るソフトウェアファクトリーの共通基盤の話に及ぶ。

## ポイント

- 「雑なコードは次のモデルが直す」という冗談に対し、Dex は新モデルでもバグ診断は上達したが保守しやすい設計や抽象化は上達していないと述べている。
- computer use により、チェックインや搭乗券の取得、役所の予約などフォーム入力を API なしで任せられるようになったという体験が語られた。
- MCP ツールはエージェントに合わせて設計すべきで、Claude Code や Codex が学習で使い込んだツール形状に似せると信頼性が上がるという見方を示した。
- チャットだけでは情報量が低いため、タイムラインへのコメントや編集可能なカードなど、タスクに特化したリッチなUIが必要だと議論された。
- 大企業では主任エンジニアが各自ソフトウェアファクトリーを作っており、同期やストリーミング、承認といった共通部分を GitHub Actions のように部品化することを HumanLayer は目指している。

## 章立て

- [01:02] **「GPT-7が直す」という冗談** — 雑なコードを放置しても将来のモデルが直すという期待と、新モデルでも設計力は上がっていないという指摘。動くなら問題ないのかという問いも提示される。
- [07:25] **computer use の実用例** — メール確認、フライトのチェックイン、搭乗券の取得、ドイツでの免許更新予約などを任せる使い方を紹介する。
- [11:37] **動画編集と MCP の設計** — Palmier MCP を使ったデモ動画制作と、優れた MCP は学習済みツールに似せるという設計論を述べる。
- [16:46] **モデルの使い分けと放置ワークフロー** — 一つのモデルに習熟する重要性と、ランニング中に反復改善させて粗い動画を得た体験を語る。
- [23:43] **ブラウザエージェントは過渡期か** — 将来すべてがヘッドレスになるのか、広告やアップセルを前提にしたサイトの収益はどうなるのかを議論する。
- [29:03] **チャットにはリッチなUIが必要** — 音声入力での返信、編集可能なカード、タイムラインへのコメント、ニュースレター作成の例から、人間の帯域を高めるUIを論じる。
- [40:30] **各社が作るソフトウェアファクトリー** — 主任エンジニアが個別に構築するバックグラウンドエージェント基盤と、同期やストリーミングの負担を HumanLayer が部品化する構想を説明する。
- [44:59] **エージェント版 GitHub Actions** — CI の例えで、所有すべき部分と汚れ仕事の部分を分け、アーティファクト共有などを部品として提供する考えを述べる。

## 解説記事

AI エージェント向けツールを開発する HumanLayer の CEO、Dexter Horthy（Dex）が、ホストの Demetrios Brinkmann とアムステルダムでタンデム自転車に乗りながら語った回である。話題は、AI が書いた雑なコードの行方から、computer use の実用例、MCP の設計、チャットUIの限界、社内のソフトウェアファクトリーまで広がった。なお、収録は自転車の操縦に苦戦しながら行われ、会話は何度も中断している。

#### 「GPT-7 が直してくれる」は通用するか

冒頭の話題は、Claude 3.7 や Opus 4 の頃に交わされていた冗談である。コードが雑でも読まずに進め、あとで十分賢いモデルが現れたら修正してもらえばよい、という考え方だ。ところが GPT-6 が出た今も、期待ほど解決していないと Dex は述べている。

Dex の見立てでは、新しいモデルはバグの診断やゲーム、Blender、computer use といった領域では進歩した。しかし保守しやすいソフトウェアを作ることや、良い抽象化、スパゲッティにならないコードベースの設計はまだ身についていない。そのため問題は引き続き「次のモデル」に持ち越されている。

そのうえで彼が問うのが、動いていれば問題ないのかという点である。今日は動いても、数か月後に数千〜数百万のユーザーを抱えた状態で何かが壊れ、3 か月間コードを読んでいなかった開発者が原因を理解できないまま、モデルにスロットマシンのように修正を引かせ続ける。この状況を彼は半年にわたって警告してきたという。

#### computer use と MCP の設計

ホストの Demetrios は、OpenAI の Jason Louie から聞いた話をきっかけに computer use に傾倒したと語る。Codex に受信トレイを定期巡回させ、航空会社のメールが来たらフォームに入力して搭乗券を取得させている。当日の朝はチェックインを忘れていたが、メールボックスには搭乗券がすでに届いていた。ドイツでの免許更新の予約も任せ、日時と持ち物の連絡、カレンダー招待まで済んだという。API を使えない相手にもブラウザ上で本人になり代わって操作できる点を、彼は高く評価している。

Dex は Palmier（DaVinci Resolve のような編集ツールに MCP が付いたもの）と Opus 4.8 でデモ動画を作った経験を紹介した。2 時間分の素材から数秒おきのコンタクトシートを作らせ、ストーリーボードを作成させ、ランニング中は「プロ品質になるまでヒルクライムせよ」という指示のメッセージを複数キューに積んで放置した。戻ると出来は粗い（slop）ものの、画面録画を溜めておけば後でデモにできると思える水準だったという。

MCP については、非テック企業が最初に出すものは出来が悪くなりがちだと指摘する。コーディングエージェントが大量の計算資源をかけた強化学習で特定のツール群に習熟している点を踏まえ、HumanLayer では自社ハーネスのツールを Claude Code のものと同じ形に揃えている。Codex の編集は一括パッチ形式であり、Claude Code 流の old string/new string 形式を渡すと明らかに使いこなせないという。MCP は人間ではなくエージェントの思考に合わせて設計すべきだというのが彼の主張だ。

#### ブラウザエージェントとウェブの行方

二人は、ブラウザエージェントは MCP や API が普及するまでの応急処置なのかを議論した。ブラウザ操作は API 利用料を避けられる一方で速度が出ない。また、広告やアップセルを前提とするサイトは、エージェントが無視した場合に収益を保てるのかという疑問も出た。ただし Dex は、ショッピング中のエージェント経由でアップセルが本人に届いた例も挙げている。

Demetrios は、小さな自治体など技術チームを持たない組織が MCP を採用する動機は乏しいのではないかと疑う。Dex は、米国の healthcare.gov のようにウェブ普及から約 12 年遅れで行政のオンライン化が進んだ例を挙げ、「GovMCP」のようなものがいずれ現れる可能性を示唆しつつ、時期は読めないと述べた。人間向けサイトが不要になれば、各社は MCP 経由でシステムや物流を提供する形に変わるという見通しも語られた。

#### チャットを超えるインターフェース

後半は、チャットは情報の帯域が低いという話になる。Demetrios は音声入力の Whisper Flow で返信を口述させ、Codex デスクトップアプリで返ってくる編集可能なカードに期待している。Dex は、動画編集のタイムラインに直接コメントを付けてエージェントに伝えたいと言う。Frame.io のような仕組みを経由する回避策も話題に上った。

Dex は、初期の HumanLayer の発想も、承認や分類のたびに目的特化のレビューUIへ誘導することだったと振り返る。UIの出し方もコンテキストの一部だという指摘が出た。Fable が情報を大量に吐き出す問題に対しては、視覚的にまとめるオープンソースのスキル「Showman」を公開したと紹介している。人間にとって「3+6」のように労力のいらない形で情報を提示したいという考え方である。

Demetrios はニュースレター作成の例を挙げた。100 件の記事から 5 件を選び、要約と自分の見解を付けて配信ソフトに流す一連の作業は、チャットが十分に賢くなればミニアプリに置き換わるのかもしれない。いま作るツールの寿命が 1〜2 年かもしれないという緊張関係を、二人は認めている。

#### ソフトウェアファクトリーと GitHub Actions の比喩

Dex によれば、HumanLayer の顧客は主に 100 人以上、多くは 300 人超のエンジニアを抱える企業だ。そこでは主任エンジニアが各自でソフトウェアファクトリーを作り、CTO はバックグラウンドエージェントを求めている。Ramp が公表した事例の影響も大きいという。

自社で持つべきなのは開発環境やコードの実行方法である。一方で、コンテナで動くエージェントとのメッセージのストリーミング、Slack やUIとの接続、承認、差分の共有といった部分は、差別化にならない重荷になる。HumanLayer 自身もローカルのデーモンとクラウドを結ぶ同期エンジンに多くの時間を費やし、Electric SQL や durable streams を使っていると語った。

Dex はこれを GitHub Actions に例える。利用者はランタイムやテストを YAML で定義するだけで、ログ収集やスケジューラ、webhook の処理は他者に任せられる。同様に、エージェントが書いた計画ファイルをチームに共有し、Slack で通知しコメントを戻せるといった部品を提供したいという。

#### まとめ

本回の中心は、モデルが進化しても設計の質や運用の負担は自動では解決しないという現実的な認識だ。日本のエンジニアにとっては、動くだけのコードを溜めるリスク、MCP をモデルの学習傾向に合わせて設計する発想、チャットを超える承認・レビューUIの必要性が参考になる。社内でエージェント基盤を作る際は、自社で持つ部分と共通化できる配管部分を見極めることが課題になりそうだ。

> この要約・解説記事は、元の音声の文字起こしをもとに AI（Claude）が日本語で作成したものです。出典: Agentic Conversations (formally mlops.community)「From Slop Code to Software Factories」