コードを一行も読まずに、本番のセキュリティソフトをリリースしたチームが実在する。しかも「コードは人間が書いてはいけない、コードは人間がレビューしてはいけない」を憲章に明記したうえで、だ。
「コードを見ない」をルールにした組織
StrongDMは、企業のITインフラへのアクセスを管理するセキュリティ系SaaSだ。2025年7月14日、同社は3名による独立チームを立ち上げた。Justin McCarthy（共同創業者兼CTO）、Jay Taylor、Navan Chauhan——この3人が掲げた憲章は2つだけだ。
- コードは人間が書いてはいけない
- コードは人間がレビューしてはいけない
普通のエンジニアリングチームなら、コードレビューはむしろ品質の要だ。それをルールで禁じた。なぜそんなことが成立するのか。
彼らは自分たちのことを「ソフトウェアファクトリー」と呼んでいる。製造業の「ダークファクトリー」になぞらえた概念だ。ダークファクトリーとは、ロボットだけで稼働する完全自動化工場のこと——ロボットに照明は不要なので工場は暗い。ソフトウェアファクトリーも同じ発想で、「コードを読む人間」がいないなら「コードを読む環境」すら必要ない。
「コードを書かない」はバイブコーディングでも同じだ。ソフトウェアファクトリーとの違いは、「AIが出したコードを人間が確認・修正する」のか、「コードの検証もAIと自動システムが担う」のかにある。
何を作っているのか
このチームが構築しているのは、Okta、Jira、Slack、Google Docs/Drive/Sheetsと連携するエンタープライズ向けアクセス管理・セキュリティソフトだ。セキュリティ企業のプロダクトを、コードを見ずに作っている。
チームの指標の一つが興味深い。「エンジニア1人あたり1日1,000ドル以上のトークンを消費していなければ、改善の余地がある」というものだ（Simon Willison's Blog）。AIモデルへの支出を生産性の尺度にする——人件費ではなく、LLMへの出費が開発コストの主役になるという前提だ。
この取り組みを実現させた転機は、Claude 3.5 Sonnet（2024年10月改訂版）だった。それ以前のモデルでは、長期にわたるエージェント作業でエラーが蓄積していた。改訂版では「エラーの蓄積」ではなく「正確性の複利」——作業を続けるほど精度が上がる——という性質に変わったという。
品質をどうやって担保するか
人間がコードを見ない以上、品質の担保はすべてAIと自動検証に委ねられる。StrongDMが取った方法は2つだ。
デジタルツイン・ユニバース
連携先のAPIを丸ごと複製した、仮想の本番環境だ。Okta、Jira、Slack、Google WorkspaceのAPIを行動レベルで複製したGo製バイナリ群で構成されており、factory.strongdm.aiによれば1時間に数千のシナリオを実行できる。本番APIのレート制限もAPIコストもない。さらに、本番環境では再現できない「危険な障害モード」——Okta APIが突然503を返し続けるケースなど——も安全にテストできる。
自動車工場に例えれば、溶接された車体を全数検査する「検査ライン」だ。人間の目ではなく、センサーと基準値で判定する。
シナリオ検証（ホールドアウトセット）
ここが特に重要な発想だ。通常のテストコードはコードベースの中に存在する。AIエージェントはコードを書くときにテストコードも読める——つまり「テストを通すためのコード」を最適化できてしまう。これを「報酬ハッキング問題」と呼ぶ。答えが見えた状態でテストを受けているようなものだ（Simon Willison）。
StrongDMの解決策は、テストシナリオをコードベースの外に隔離することだ。機械学習の「ホールドアウトセット（検証データを訓練から分離する手法）」と同じ原理だ。
❌ テストがコードベース内にある（エージェントが"カンニング"できる）
codebase/
├── src/ ← エージェントが書く
├── tests/ ← エージェントが読んで最適化できる
└── ...
✅ シナリオをコードベース外に隔離（エージェントからアクセス不可）
codebase/
├── src/ ← エージェントが書く
└── ...
holdout-scenarios/ ← エージェントからアクセス不可
├── scenario-001.yaml
├── scenario-002.yaml
└── ...
判定も「テスト合否（○か✕か）」ではない。「AIエージェントの行動軌跡が、要件を満たす割合」——満足度指標と呼ばれる連続値——で評価する。正解か不正解かの2択ではなく、「どのくらい正しく動いたか」を測る。
Level 0からLevel 5まで
この概念を体系化したのが、Dan Shapiroによる5段階のタクソノミーだ。NHTSA（米国道路交通安全局）の自動運転レベル分類に倣った枠組みで、ソフトウェア開発へのAI関与度を0から5で定義している。
Level 2は、AIをジュニアの同僚として扱い、人間がレビューしながら進める状態だ。Pragmatic CTOの分析では「ほとんどの組織はLevel 2かLevel 3のあたりにいる」とされており、StrongDMはその終点まで一気に飛んだ、という位置づけだ。Level 5のダークファクトリーは、コードを書く人間も、レビューする人間も、コードを読む人間もいない状態だ。
StrongDMはLevel 5の実証実験として注目を集めた。Ethan Mollick（Wharton大学の生成AIラボ共同ディレクター）やGarry Tan（YCombinator社長・CEO）、Simon WillisonなどがこのアプローチをSNSで取り上げ、広く知られることになった。MITテクノロジーレビューも「2026年の10大ブレークスルー技術」にGenerative Codingを選出している（2026年1月12日）。
発注者・非エンジニアが知っておくべきこと
この話を「エンジニアのもの」として聞き流してはいけない。ITシステムを外注してきた立場の人間にこそ、関係がある。
YCombinator Winter 2025コホートのスタートアップの25%が「コードベースの95%以上をAI生成」と回答している。委託先のエンジニアが手で書いているコードは、すでに少数派になりつつある。外注先が「何をどう作っているか」という前提が変わっている。
そしてStrongDMの方法論が示す最大の示唆は、仕様の精度が成果を決めるという点だ。
❌ 曖昧な仕様（エージェントが迷う）
「Okta連携機能を追加して」
✅ 機械が動ける仕様（StrongDM流）
「以下のシナリオをすべて満たすOkta連携を実装すること:
- シナリオ001: 有効なOktaユーザーがアクセス要求 → 承認される
- シナリオ002: 無効なOktaトークン → 401返却
- シナリオ003: Okta APIが503を返した場合 → 3回リトライ後フォールバック
- シナリオ004: 複数ロールが競合する場合 → 最小権限ルールを適用」
レシピ作家と料理人の関係だ。どんなに優秀な調理AIがいても、レシピが「おいしいものを作って」では料理が決まらない。成分・分量・手順が書かれたレシピが精度を決める。AIを使う開発では、仕様を書く人間の能力が、これまで以上に成果に直結する。
誰が責任を取るか
ソフトウェアファクトリーには明確な問いが残る。
Stanford Law Schoolは2026年2月、「AIによって構築され、AIによってテストされたコード——信頼するのは誰か？」という問いを立てた。コードを誰も読んでいないなら、そのコードが何をするかの責任は誰が取るのか。現在の法律は「人間が出荷判断をした」という前提で設計されている。
AIが生成したコードは、人間が共同作成したコードに比べて「重大な問題」が1.7倍多く、セキュリティ脆弱性は2.74倍多いというCodeRabbitの分析（2025年12月）がある。コードを見ないで出荷するためには、シナリオ検証の設計が成否を分ける。
「コードを誰も見ていない」という事実が、バグだけの話では済まなくなる可能性がある。法的責任、契約責任、保険。外注先が「AIが作りました」で免責されるのか——これは発注者がこれから直面する問いだ。
なお、StrongDMは2026年3月5日にDelineaへの買収が完了した。ソフトウェアファクトリーの取り組みが、買収後にどう継続されるかは注目点の一つだ。
仕様を書ける人間が、これからの開発を動かす
コードを書く行為の意味が変わりつつある。StrongDMが示しているのは、一つの極端なモデルとしての「Level 5」だ。すべての組織がここを目指すべきだとは限らない。だが、「AIがコードを書き、人間は仕様と検証基準を決める」という方向性は、規模の差はあれど多くの開発現場に広がりつつある。
建築家は鉄骨を溶接しない。設計図を書く。プロジェクトの良し悪しは、設計図の精度で決まる。ソフトウェア開発でも、「設計図を書く」人間の重要性が上がっている。コードを書けるかどうかより、「何を作るか」と「どう検証するか」を言語化できるかどうかが、これからの開発を動かす。
