- StrongDM AIチームは、コードを見ずに高品質なソフトウェアを作る Software Factory という概念を提唱
- 仕様/シナリオベースでエージェントがコードを書き、テストハーネスを実行し、人間のレビューなしで収束する非対話型開発方式
- コードは人間が書いたりレビューしたりしてはならず、エンジニア1人あたり1日最低1,000ドル以上のトークンコストを使ってこそソフトウェア・ファクトリーは正しく機能する
- Claude 3.5 第2改訂版（2024年10月）以降、長期エージェント型コーディングワークフローがエラー蓄積ではなく正確さを複利的に蓄積し始め、非対話型開発の可能性が確認された
- 従来のテスト概念を拡張して**シナリオ（scenario）と満足度（satisfaction）**を導入し、LLMがユーザー満足度を確率的に評価する仕組みを構築
- Digital Twin Universe（DTU） を通じて Okta、Jira、Slack など主要SaaSを複製し、大規模検証を実施。プロダクションの限界を超えるボリュームと速度でシナリオ検証が可能
- エージェント時代はソフトウェア経済学を根本から変え、以前は経済的に不可能だった高忠実度SaaSクローンの構築が今や日常的作業になっている
Software Factory 概念
- 仕様（specs） と シナリオ（scenarios） がエージェントを駆動し、コードを書いて検証する非対話型開発体系
- 人間によるコード記述とレビューを禁止し、開発プロセスのすべてをエージェントが担う
- エンジニア1人あたり1日1,000ドル超のトークン使用量を基準に効率性を測る
- このアプローチは、人間の介入なしにコードが自動生成・検証・収束する自律的ソフトウェア生産環境の構築を目指す
StrongDM AIチームの発足
- 2025年7月14日、StrongDM AIチームが結成され、非対話型開発の実験を開始
- 参加者: Jay Taylor、Navan Chauhan、Justin McCarthy（共同創業者兼CTO）
- 2024年末の**Claude 3.5（10月改訂版）以降、長期的なコード生成の正確性が向上し、反復的なエラー蓄積ではなく正確性の複利蓄積（compounding correctness）**が可能になった
- Cursor の YOLO モードによって、モデルの長期コード生成能力が明確に示された
- 以前のモデルでは、LLMをコーディング作業に反復適用すると、誤解、幻覚、構文エラー、バージョン面での DRY 違反、ライブラリ非互換などあらゆる種類のエラーが蓄積し、アプリは「崩壊」していた
- Anthropic の更新モデルと YOLO モードの組み合わせにより、非対話型開発または成長するソフトウェアの最初の可能性が確認された
中核原則: 手を出さない
- AIチームは初日の最初の1時間で憲章を定め、最も重要な原則として**「コードは人間が直接書いてはならない」**を掲げた
- 当初は単純な直感と実験だった。手で一切コードを書かずにどこまで行けるか、という問いから始まった
- 最初は限界に突き当たったが、テストを追加してから前進し始めた
- エージェントは目先のタスクに固執して近道を選びがちで、return true のような狭く書かれたテストは通過できても、実際に望むソフトウェアへ一般化できない
- 単純なテストだけでは不十分で、統合テスト、回帰テスト、エンドツーエンドテスト、振る舞いテストへ拡張する必要がある
テストからシナリオと満足度へ
- エージェント時代の反復テーマは新しい言語が必要ということ。「テスト」という言葉は不十分で曖昧
- コードベース内に保存されたテストは、コードに合わせて安易に書き換えられたり、コードがテストを些末に通過するように書き換えられたりする
- シナリオという用語を再定義。これはエンドツーエンドのユーザーストーリーを表し、コードベースの外部に保存され（モデル学習における「ホールドアウト」セットに近い）、LLMが直感的に理解して柔軟に検証できる
- 成長するソフトウェア自体がエージェントコンポーネントを含むため、成功判定は単純なブール値ではなく、**確率的・経験的な満足度（satisfaction）**へ移行する
- 満足度: すべてのシナリオを通過した観測軌跡のうち、ユーザーを満足させる可能性がある割合を定量化するもの
Digital Twin Universe によるシナリオ検証
- 以前の体制では、統合テスト、回帰テスト、UI自動化によって**「動くか？」**を判断していた
- 既存の信頼できた手法には2つの限界が見つかった:
- テストが硬直的すぎる: エージェントでコーディングし、LLMとエージェントループを設計プリミティブとして構築するため、成功評価にはしばしば LLM-as-judge が必要になる
- テストは報酬ハッキングに弱い: モデルの不正行為に対してより耐性のある検証が必要
- Digital Twin Universe（DTU） がその答え。ソフトウェアが依存するサードパーティサービスの振る舞いを再現したクローン
- Okta、Jira、Slack、Google Docs、Google Drive、Google Sheets のツインを構築し、API、エッジケース、観測可能な振る舞いを複製
- DTU によって、プロダクションの限界をはるかに超えるボリュームと速度で検証できる
- 実運用サービスに対しては危険または不可能な障害モードのテストも実施可能
- レート制限到達、悪用検知のトリガー、APIコストの累積なしに、1時間あたり数千件のシナリオを実行できる
非伝統的な経済学
- DTU を通じた成功は、エージェント時代（Agentic Moment）がソフトウェア経済学を根本的に変えた多くの例の1つを示している
- 主要SaaSアプリケーションの高忠実度クローン作成は以前から可能だったが、経済的に実現不可能だった
- 何世代ものエンジニアが、テスト用CRMの完全なインメモリ複製を望んでいたが、却下されるのを見越して管理職に提案すらしなかった
- ソフトウェア・ファクトリーの構築者は、**意図的なナイーブさ（deliberate naivete）**を実践する必要がある。Software 1.0 の習慣、慣例、制約を見つけ出して取り除くことだ
- DTU によって、6か月前には想像もできなかったことが今では日常作業としてルーチン化されている
次に読むもの
- Principles : エージェントを使ったソフトウェア開発に関する私たちの信念
- シード → 検証ハーネス → フィードバックループ構造でソフトウェアを成長させ、トークンが燃料として機能する
- すべてのソフトウェアには初期シードが必要で、以前なら PRD や仕様書だったものが、今では数文、スクリーンショット、既存コードベースでもよい
- 検証ハーネスはエンドツーエンドであるべきで、実環境（顧客、統合、経済性）にできる限り近くなければならない
- 出力サンプルを入力にフィードバックする閉ループが、システムの自己修正と正確性の複利蓄積を可能にする
- 検証とフィードバックの理論は理解しやすいが、実務では創造的かつ最先端のエンジニアリングが必要であり、あらゆる障害をモデルが理解できる表現へ変換する方法を探ることになる
- Techniques : これらの原則を適用するための反復的パターン
- Digital Twin Universe（DTU）
- 重要なサードパーティ依存関係の外部から観測可能な振る舞いを複製
- プロダクションの限界を大きく超えるボリュームと速度で検証
- 決定的で再現可能なテスト条件を提供
- Gene Transfusion
- エージェントを具体例に結び付け、コードベース間で動作パターンを移植
- 良い参照と対になったソリューションを新しい文脈で再現できる
- Filesystem
- モデルがリポジトリを素早く探索し、ファイルの読み書きによって自らのコンテキストを調整
- ディレクトリ、インデックス、オンディスク状態が実用的なメモリ基盤として機能する
- Shift Work
- 対話的作業と完全に仕様化された作業を分離
- 意図が完全なとき（仕様、テスト、既存アプリ）、エージェントは往復なしでエンドツーエンド実行できる
- Semport
- 意味を理解した自動ポーティングを単発または継続的に実行
- 意図を保ったまま言語やフレームワーク間でコードを移行
- Pyramid Summaries
- 複数のズームレベルでの可逆的要約
- 全詳細へ再展開する能力を失わずにコンテキストを圧縮
- Products : 私たちが日々使っていて、他の人にも役立つと考えているツール
- CXDB は AI エージェント向けのセルフホスト型コンテキストストアで、Turn DAG、blob 重複排除、動的型付け、視覚的デバッグを提供
- StrongDM ID は人間、ワークロード、AIエージェント向けのアイデンティティシステムで、フェデレーション認証とパススコープ共有をサポート
- Attractor はフェーズグラフで構造化された非対話型コーディングエージェントで、タスクが完全に仕様化されているときにエンドツーエンドで実行する
3件のコメント
仕様主導開発を、マルチエージェントを使って試してみました。作業を大きく減らしてくれるのは確かですが、LLMの性能的な限界のため、顧客が満足できる製品は作れません。100%の代替は不可能で、人間の作業がある程度必要です。
かなり刺激的ではあるのですが、ある程度は理解できる気もして……。なんだか複雑な気持ちになる文章ですね。
この記事を見たあとに下の文章を読むと、より共感できます。
私たちの職人精神を悼む
Hacker Newsの意見
私は Digital Twin Universe という概念に共感する。
私のコードベースも外部サービス連携が多く、テスト時に外部呼び出しを止めるとほとんど何も検証できなかった。
そのため、Okta、Jira、Slack、Google Docs など各APIの 偽物の実装 を作ってテストしていた。
ただしUIまでは複製せず、APIの挙動だけを模倣していた。
「エンジニア1人あたり1日 $1,000 のトークンを使っていないなら改善の余地がある」という話は、あまりにも 非現実的 に聞こえる。
これが本気の主張なのか疑わしい。
計算すると年間およそ $250k 規模になる。
もしAIがそれだけの 生産性 を出せるなら合理的かもしれない。
現実的にはジュニアエンジニア2人分くらいの効率だろう。
結局、人間は リード役 として計画と検証だけを担当することになりそうだ。
誇張された楽観論ではあるが、完全に狂った話というわけでもない。
私は月額 $20 の Claude と OpenAI のサブスクしか使っていない。
トークンを使い切ったら散歩したり本を読んだりしている。
加速主義者 ではないが、それでも仕事は十分できている。
私は StrongDM チームの一員だ。
1日 $1,000 分のトークンを使うのは簡単だが、生産的に使うのは難しい というのが核心だ。
これは単なる ハッタリ に見える。
「うちは君たちよりAIで先に進んでいる」というシグナルを送っているように思える。
読んでいて 気まずさ を覚えた。
既存の mocks やシミュレーションテストを「革新」のように見せている感じだ。
それでも、彼らがコスト構造を率直に明かしている点は評価する。
私は彼らのサイトで実際の コードや製品 を探していた。
唯一見つけたのは strongdm/attractor だった。
「カナダ人の彼女コーディング」が今やビジネスモデルになったわけだ。
追加で strongdm/cxdb も見つけたが、コミット履歴は整理されていた。
cxdb リポジトリ には実際のコードがある。
これが狂気なのか未来の一断面なのかは分からない。
Products ページ にはデータベースとIDシステムもある。
複数のエージェントが協調するには、共有コンテキスト と権限システムが不可欠だ。
BoundaryML の BAML に関するウェビナーを聞いた。
Spec-driven development は、人間がループ内にいる構造化ワークフローを作るアプローチだ。
/research → /plan → /implementというループを明確に定義し、各段階で 人間による検証 を通す。StrongDM の「人間はコードを書いたり読んだりしない」という主張とは正反対の哲学だ。
また一つの 中身のないブログ記事 のように感じる。
実質的な成果物はなく、$1,000/日 のトークンの話は投資家向けアピールに見える。
検証の問題 を解決できなければ、これはすべてハッタリにすぎない。
自動レビューやガードレールを用意しても、結局 仕様と結果の一致 を確認するのは人間だ。
私たちは Speedscale で トラフィックのキャプチャと再生 によって検証を自動化している。
実際のところ、人間の開発も完璧ではない。
コードレビュー、テスト、QA など、さまざまな 体系的な検証手順 がすでに存在している。
重要なのはAIが完璧かどうかではなく、システム全体の品質が収束するか だ。
私の経験では、Opus 4.5 基準だと多少の 純利益効果 はある。
私もほぼ同意する。
核心は 生成より検証 だ。
複数の独立したエージェントが互いに 異論を示しながら合意する 構造を作っている。
要するに、検証とセキュリティテストを エンドユーザーに押し付けている わけだ。
仕様ベースの言語と 形式的検証 をもっと積極的に使うべきだ。
結局、プログラミングとは「仕様を具体化する行為」として再定義されるだろう。
1日 $1,000 のトークンなら、人間よりAIに多くの金を使っていることになる。
これは AIビジョンの崩壊点 のように見える。
Simon Willison が 記事を更新 したそうだ。
年間 $240k なら新卒 FANG エンジニア級だ。
正直、Claude よりできないジュニア も多い。
結局、少数の人間が頂点にいる ピラミッド構造 へ再編されそうだ。
もし同じ仕事を5日で終えられるなら、速度に対するコスト としては合理的かもしれない。
成果物が比例して拡大するなら、費用対効果 は成り立つ可能性がある。
しかもトークン単価が下がる可能性もある。
法律・保険業界 はこの変化に最も苦しむだろう。
人間のミスはモデリング可能でも、自律ループの連鎖的エラー はまったく別の問題だ。
AIの判断は結局 人間の責任 に帰着するだろう。
これが agentic shift 全体のブレーキ になる気がする。
1日 $1,000 のトークンは 話にならない指標 だ。
コード品質が悪ければトークン消費は爆発的に増える。
結局、整理されていないコードベース がコストを押し上げる。
1日千ドルを燃やすチームなら、効率はほとんどないだろう。
（参考: この画像）
これは短期最適化 vs 長期最適化の問題だ。
今の効率を上げるか、システム全体を改善するかの選択だ。
もしかすると、ようやく経営陣が リファクタリングの重要性 に気づくかもしれない。
以前私が言及していた Dark Factory パターン のチームがまさに彼らだった。
関連記事 を書いたが、このチームは 最も野心的な実験者 たちだ。
しかし実際には、成果物がほとんどない。
大学生数人に $10k 渡したほうがもっと良いものを作れそうだ。
1日 $1,000 のトークンなんて、私のチームの予算では 夢のまた夢 だ。
個人的にも生活費のせいで無理だ。
結局、「やっても詰み、やらなくても詰み」という気分になる。
検証可能な成果がなければ ただの言葉 にすぎない。
そして今や、その言葉ですら LLM のおかげではるかに安くなった。
倫理的な開示が必要だ。
サイト上の用語は既存概念を言い換えただけのレベルだ。
「Digital Twin Universe」は mocks、「Gene Transfusion」は参考コードを読むこと、「Semport」はトランスパイルのことだ。
実際の データやベンチマーク は皆無だ。
AIマーケティングがエンジニアリング洞察に見せかけられた例だ。
実際、大半のコアコードはすでに GitHub にある。
本当の差別化要因は メカニズム設計と価値観 だ。
未来は formal methods と AI の結合へ向かうだろう。
「シナリオを holdout set として残してテストする方式」が興味深い。
QAチームの攻撃的テスト を模倣する概念だ。
ビルドチームとバグ検出チームを分けて 相互競争の構造 にするのが印象的だ。
ただ、1日 $1,000 のトークンはオープンソース開発者にとっては 絶望的 だ。
ローカルモデルを使えばコストを下げられる。
このスレッド のように、ローカルエージェント自動化 も十分可能だ。
いつかエージェント同士が 賄賂を渡し合う 状況が来るかもしれない。
私は今でも 人間がループ内にいる方式 を好む。
むやみにトークンを燃やすのは無駄だ。
私は 「LLMs aren’t tools」記事 で、LLM活用の 精神的フレームワーク を探っていた。
「ソフトウェア工場」は現在の到達点だが、その次の段階は LLMを一つのアプリケーション として捉えることだ。
つまり、単なるワークフロー自動化ではなく、カスタムハーネス を作る段階だ。