← 2026-02-08 の一覧へ戻るホーム
ソフトウェアファクトリーとエージェンシーの瞬間

2026/02/08 0:05

ソフトウェアファクトリーとエージェンシーの瞬間

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

（推論は追加しないでください）**

この記事では、ジャスティン・マッカーシー（共同創業者／CTO）、ジェイ・テイラー、およびナヴァン・チャウハンが2025年7月14日に設立したStrongDM AIが、自律型「ソフトウェアファクトリー」を構築した方法を説明しています。ファクトリーは高レベルの仕様とシナリオを使用して、コードを書き、テストを実行し、変更をマージするAIエージェントを駆動しますが、人間によるコード作成やレビューは一切必要ありません。

主要指標：1人あたりのトークンコストが$1,000を超える場合はプロセスに改善が必要です。2024年後半、Claude 3.5（2024年10月）への移行で長期的な推論が可能になり、「千刀で死ぬ」状況を防ぎました。2024年12月にはCursorのYOLOモードがこの改良された長期エージェント型コーディングを実証しました。

チームは「Hands off!（手を離す）」というチャーターを採用し、堅牢なテストが追加されるまでゼロマニュアルコード作成を試行しました。最初に単純なテスト（例：

return true
）に依存した結果失敗したため、統合・回帰・エンドツーエンド・振舞いテストへ移行し、「テスト」を「シナリオ」と再定義しました。また 「満足度」 指標を導入しました。これは観測されたシナリオ軌道がユーザーの意図をどれだけ満たすかを確率的に測るものです。

Okta、Jira、Slack、Google Docs/Drive/Sheets などのサードパーティサービス向けにデジタルツインユニバース（DTU）を構築し、高ボリュームで検証できるようにしました。これにより、本番サービスの制限に達したりコストが発生したりすることなく、検証が可能です。DTU はソフトウェア経済学の変化を示しており、SaaS アプリケーションのフルメモリレプリカを構築することが現在は日常的かつ経済的に実現可能になっています。

この記事では、そのようなエージェント型ソフトウェアファクトリーを構築するための原則、技術、および日々使用されるツールについて概説しています。

本文

ソフトウェアファクトリーを構築した――

非対話型開発で、仕様＋シナリオがエージェントにコードを書かせ、ハーネスを走らせ、レビューなしで収束させる仕組みを作りました。

以下は物語形式です。もし原理から始めたい場合は、反復的に適用すればチームの直感・確信（¹）と最終的には自分だけのファクトリー（²）が加速するいくつかの制約・ガイドラインを提示します。

1. 「禅問答」またはマントラ形式

  • なぜこれをやっているのか？（暗黙的に：モデルが自ら行うべきこと）

2. 「規則」形式

  • コードは人間によって書かれてはいけない。
  • コードは人間によってレビューされてはいけない。

3. 「実務」形式

  • 今日、人間エンジニアあたりでトークンに1,000ドル以上を使っていなければ、あなたのソフトウェアファクトリーには改善余地があります。

StrongDM AI ストーリー

2025年7月14日、Jay Taylor と Navan Chauhan が私（Justin McCarthy、共同創業者・CTO）とともに StrongDM AI チームを設立しました。
発端は 2024 年末の出来事です：Claude 3.5 の第2版（2024年10月）が登場し、長期的なエージェント型コーディングワークフローが「エラー」ではなく「正確さ」を増幅するようになったからです。

正確さの増幅 vs エラーの増幅

2024 年12月までに、モデルの長期的コーディング性能は Cursor の YOLO モードで明らかでした。
それ以前は、LLM を繰り返し適用すると、誤解・幻覚・構文ミス・バージョン DRY 破壊・ライブラリ非互換性など、想像できるあらゆるエラーが蓄積されました。アプリや製品は劣化し、最終的に「千の切り傷で死ぬ」ような崩壊を迎えます。

YOLO モードと Anthropic の更新モデルのおかげで、内部では 非対話型開発 または “grown software” と呼ばれるものが初めて見えてきました。

Knobs を探し、11に設定

それらを 11 に設定します。AI チームの最初の日の最初の 1 時間で、我々は「アンロック」と呼ぶ一連の発見へ向かうチャーターを策定しました。
振り返ると、チャーターで最も重要な行は “Hands off!”（手を離せ！）でした。初めはただの直感―コードを書かずにどこまで進められるか試すだけでした。

結局それほど遠くはいきませんでした—少なくともテストを追加するまでは。
エージェントは即時タスクに固執し、

return true
のようなショートカットを取ってしまいます。これは狭く書かれたテストには通るが、一般化できないでしょう。

テストだけでは不十分でした。統合テスト？回帰テスト？エンドツーエンドテスト？行動テスト？

テストからシナリオへ、そして満足度へ

エージェント時代の共通テーマ：新しい言語が必要です。

  • 「test」という単語は不十分で曖昧。コードベースに保存されたテストは遅延的に書き換えられ、コードを簡単に変更して合格させることができます。
  • 我々は scenario（シナリオ） という言葉を再利用し、エンドツーエンドの「ユーザーストーリー」を表すようにしました。これは通常コードベースの外部に保存されます（モデル学習時の “holdout” セットと同様）。LLM が直感的に理解し、柔軟に検証できるものです。

ソフトウェア自体がエージェント性を持つため、成功の定義を「テストスイートが緑になる」というブール値から、確率的・経験的なものへ移行しました。私たちは satisfaction（満足度） という語を使ってこの検証を量化します：

すべてのシナリオを通過した観測軌跡の中で、どれだけがユーザーに満足している可能性があるか？

デジタルツインユニバースでシナリオを検証

以前は、統合テスト・回帰テスト・UI 自動化で「うまく機能するか？」と答えていました。私たちは既存の手法に二つの制限があることに気付きました：

  1. テストは硬直的 ― エージェントでコードを書き、LLM で構築しているため、成功判定には LLM‑as‑judge が必要でした。
  2. テストは報酬ハッキングされやすい ― モデルが騙し合格するリスクが高かったです。

そこで登場したのが デジタルツインユニバース（DTU） です。これは私たちのソフトウェアが依存する第三者サービスの行動クローンです。Okta、Jira、Slack、Google Docs/Drive/Sheets の API、エッジケース、観測される振る舞いを再現しました。

DTU を使うことで：

  • 本番よりもはるかに大きなボリューム・レートで検証可能
  • ライブサービスでは危険または不可能な失敗モードをテストできる
  • 1 時間あたり数千のシナリオを実行し、レート制限・濫用検知・API コストに悩まされない

非常識的経済学

DTU の成功は、エージェント時代がソフトウェア経済を大きく変えたことを示しています。高忠実度の SaaS アプリケーションクローンを作ることはいつも可能でしたが、経済的に実行不可能でした。何世代ものエンジニアが CRM のメモリ内レプリカをテスト用に欲しがっていたにも関わらず、提案自体を抑制していました。

ソフトウェアファクトリーを構築する人は 意図的な素朴さ を実践しなければなりません：Software 1.0 の習慣・慣例・制約を見つけて取り除く。DTU は、6か月前には不可想像だったことが今では日常であることを証明しています。

今後

  • 原則 – エージェントでソフトウェアを構築する際に真実だと信じること
  • 手法 – それらの原則を適用するための繰り返しパターン
  • 製品 – 私たちが日常的に使い、他者にも役立つと考えるツール

読んでいただきありがとうございます。自分だけのソフトウェアファクトリー構築に幸運を祈ります。

同じ日のほかのニュース

一覧に戻る →

2026/02/08 6:45

小型 C コンパイラ

## Japanese Translation: Tiny C Compiler（TCC）は、非常に小さな（約100 KBのx86実行ファイル）Cコンパイラであり、1回のステップでコンパイル・アセンブル・リンクを行い、バイトコード層なしでネイティブx86マシンコードを生成します。2.4 GHz Pentium IV上では、Links BrowserテストをGCC（20.0 秒）より約10倍速く実行できます（2.27 秒）。これは別のコンパイルステージが不要であるためです。 TCCはISO C99を完全にサポートし、自身をコンパイルでき、任意のC動的ライブラリを直接リンクすることも可能です。完全なプリプロセッサ、GNUスタイルのアセンブラー構文、オプションのメモリと境界チェック機能、さらにはシェバンベースの「Cスクリプト」まで含まれ、コマンドラインから実行できます。libtccライブラリにより、他のプログラムがTCCをランタイムコード生成のバックエンドとして使用できるようになります。 性能テストはPentium IV上で行われました。新しい測定値（参照1–4）では、モダンハードウェアでも速度向上が継続しています。ドキュメント、メールリストサポート、およびSavannah/GitHubリポジトリは最新情報を提供します。 TCCはGNU Lesser General Public License（LGPL）の下で配布されており、商用利用も許可されています。

2026/02/08 8:23

**良質なコードの静かな終焉**

## Japanese Translation: 著者は中学時代から「Good Code™」―読みやすく、保守しやすく、特定の目的を持って存在するコード――を書き続けることに情熱を注いできました。機能提供に重点を置くソフトウェアエンジニアとして、彼は今日の高速開発環境で良いコードがますます希少になっていると感じています。 同僚の経験はこの状況をよく示しています。外部Linuxカーネル統合システムをCからRustへ書き換えた後、最初のバージョンは機能していたものの読みづらく保守が困難でした。原始的なCロジックを学習した上で再度書き直すと、コードはクリーンになり、自明であり、元のCよりも優れていると言えるようになりました。この経験が著者に品質コードへの熱意を再燃させました。 現在、彼はほとんどの場合初期バージョンを書かず、代わりに「Good Code™」ではなく許容できるものを生成するコーディングエージェントに頼っています。このようなツールへの継続的な依存が個々の行レベルでの品質への注意を薄め、業界実務におけるGood Codeの静かな消滅を招くと彼は恐れています。コード品質が低下すると保守コストや技術的負債が増大し、開発者の生産性、製品の信頼性、そして最終的には企業から提供されるソフトウェアへのユーザーの信頼まで損なわれます。

2026/02/08 2:39

**セクターC：512バイトで実装されたCコンパイラ**

## Japanese Translation: SectorCは、x86‑16アセンブリで完全に書かれたCコンパイラで、単一の512バイトのブートセクタに収まります。Ultra‑compactなトークン化スキーム「Barely C」を使用しており、各スペース区切り語を「メガトークン」とみなし、`atoi()`で識別子をハッシュし64Kテーブルに格納します。変数はこのハッシュを通じてセグメント0x3000に保存されます。最初のBarely C実装は468バイトで、シンボルテーブルなしの再帰下降パーサーでした。バイトスレッド化されたForth風の変種も試みられましたが、サイズをさらに削減することはできませんでした。 最終的なコンパイラはわずか **303 バイト** です。サイズは、フォールスルーロジック、テイルコール、コールフュージョン、`lodsw/stosw`の広範な使用、およびすべてのジャンプオフセットを1バイト内に収めるなどの手法で削減されました。残り約200バイトでBarely Cは完全なCサポートへと拡張されました：ネストされたif/whileブロック、包括的な演算子集合（+, −, *, &, |, ^, <<, >>, ==, !=, <, >, <=, >=）、ハッシュテーブルを介した関数定義と再帰、インライン`asm`ステートメント、および単一行(`//`)と複数行(`/* */`)コメントの両方が実装されました。 コンパイラのランタイムは `rt/` ディレクトリ内の2つのCファイルに分かれています：ライブラリルーチン（多くの場合インラインasmを含む）を持つ `lib.c` とエントリポイントとして機能する `_start.c` です。これらはプログラムソースと結合してからコンパイルされます。記事には、全ブートセクタのBase64文字列、VGAモード0x13hで動くサイン波を描画するデモ、および追加例（`hello.c` はビデオメモリ0xB8000に書き込み、`twinkle.c` はPCスピーカーで「Twinkle Twinkle Little Star」を再生）が含まれています。この作業は、512バイトという一見不可能な目標—完全機能のCコンパイラを実現すること—が、創造的なトークン化、ハッシュ化、および積極的なコードサイズ最適化によって達成できることを示しています。