これを見たことがあるはずです。Reactで「クイック・プロトタイプ」を作るチーム——直書きの認証、SQLite、CIなし、手動デプロイ。デモはうまくいく。マネジメントは「出荷しよう。」と言う。すると始まるのが本当の仕事です。すでに動いていたものを、しかし“本物のスタック”上で作り直す——という作業。
何十年もの間、ソフトウェア開発の受け入れられたリズムはこれでした。素早く試作し、アイデアを検証してから、きちんと作り直す。合理的なトレードオフ——代替案が、単一の機能を書き始める前に何週間もインフラに費やすことだったとき。
しかし2026年には、AIコーディング・エージェントが数時間で本番向けインフラを足場（スキャフォールド）として用意できるとしたら？ この作り直しサイクルは、問い直すべき“税”ではないでしょうか。
古い合意
試作（プロトタイピング）が存在したのは、本番環境のセットアップが本当に高コストだったからです。認証、CI/CDパイプライン、データベース移行、監視、コンテナ化——これらはそれぞれ、大きな時間投資でした。ビジネス仮説を検証する前に、小さなプラットフォームを作らないといけなかった。
だから私たちは、戦略的に手抜きをすることを学びました。本物のデータベースの代わりにフラットファイルを使う。管理者ユーザーをハードコードする。SSHでファイルをコピーしてデプロイする。ステークホルダーの前にアイデアを出して、そして本物に投資する。
これは合理的なトレードオフでした。本番インフラのコストは高く、間違ったものを作るリスクも現実にありました。最初のユーザーテストを通らないかもしれない概念のために、何週間もCI/CDパイプラインに投資する理由は何でしょう？
合意はシンプルでした。今の時間を節約し、あとでツケを払う。
合意は崩れた
このコスト方程式は、根本的に変わりました。
2026年2月、アンドレイ・カラパティ（Andrej Karpathy）は、vibe codingの先に来るものを説明するために、「エージェント主体の開発（agentic engineering）」という用語を導入しました。
"新しいデフォルトは、99%の時間あなたが直接コードを書いているわけではなく、やることを行うエージェントをオーケストレーションし、監督として振る舞う——つまり、その「エンジニアリング」には、それが芸術であり、そして&科学であり、そこに専門性があることを強調する意味がある"
この変化はアーキテクチャの意思決定にとって重要です。AIエージェントが、人間の監督のもとで実装を担うとき、本番品質の足場（スキャフォールド）が自然なアウトプットになります。それは後回しにできる“贅沢”ではありません。適切な認証、本物のデータベース、自動化されたデプロイ、構造化されたテストを整えることは、もはやプロジェクトの高コスト部分ではなくなります。
ThoughtworksのCTOであるレイチェル・レイコック（Rachel Laycock）は、端的にこう言っています。「コードを書くことがボトルネックだったことは一度もありません。」 もし従来型のソフトウェア提供のベストプラクティスがすでに整っていなければ、「この速度の倍率は、負債を加速する装置になります」と彼女は警告しています。(The New Stack, 2026年2月)
ただし、ここにはニュアンスも必要です。以前は動けなくなるほど致命的だったある種の技術的負債は、今ではAIエージェントによって素早く解消できるようになりました。ごちゃごちゃしたユーティリティ関数や、一貫性のない命名規則？ エージェントなら数分で直せます。真に危険が残るのは、概念（コンセプト）の負債——間違ったものを作ること、間違った問題を解くことです。AIは、ダメなプロダクトのコンセプトを救えません。
Kent Beckはこれを「プログラミングのデフレーション（programming deflation）」と表現しています。コードの生成が安くなると、コードを書く価値から、何を作るべきか、そしてシステムがどう噛み合うのかを理解する価値へと、価値の移動が起こる。経済が変わります。コードを書くことはもはや希少な資源ではありません。必要なのは判断です。(Tidy First, Substack)
プロトタイプ税
本番向けのアーキテクチャから始めない場合、何が起きるでしょうか？
このパターンは業界全体で見えています。本番インフラから始めるチームは、プロトタイプをそのまま出荷できます。 「本番へ昇格（promote to production）」は“イベント”ではなくなる。そうでない場合は、書き直しが始まります。そしてAIがより速くより多くのコードを生成するほど、書き直しが必要になるコード量も比例して増えます。
2025 DORA Reportのデータによると、AIの導入はソフトウェア開発者の間で90%まで急増しており、AIは一貫してPRサイズを154%増やしています。より多くのコードを、より速く。もしそのコードが“捨てるための土台”の上にあるなら、将来の書き直しがこれまでより痛いものになる速度で負債を積み上げてしまうことになります。
この課題に直接向き合う新しい実践が、「ハーネス開発（harness engineering）」です。AIエージェントは、良いアウトプットを生み出すために、アーキテクチャ上の制約、コンテキスト、そしてコードの衛生状態（コードの手入れ）を必要とします。Fowlerのチームが説明しているように、開発者はますます「ループの中」で働くようになっています。つまり、生成された1行ずつをレビューするのではなく、AIエージェントがどのように動作するかを形作る仕様、テスト、ガードレールを設計するのです。(InfoQ, 2026年3月) 本番向けのアーキテクチャはそのハーネスです。捨てる前提のプロトタイプでは、そのようなガードレールは提供されません——その結果、AIのアウトプットはそれなりに品質が落ちます。
本当のボトルネックは、コードではなかった
より深い主張はこうです。成功したあらゆるアプリケーションの中心にあるのは、UXとビジネスロジックです——つまり、そのアプリがどんな課題を解決するのか、あるいはどんな機会を切り開くのか、というコンセプト。ここが弱ければ、実装がどれほど完璧でも、アプリは弱くなります。
AIエージェントはインフラを足場化し、コンポーネントを生成し、テストを書けます。しかしできないのは、何を作る価値があるかを決めることです。「プロトタイプの負債」の中で最も危険な形は、技術的なものではありません。概念的なものです——間違った土台の上で、間違ったものを作り込むのに費やした数週間。
本番優先のアーキテクチャは、過剰な設計（オーバーエンジニアリング）を目的としているわけではありません。逆です。本当に重要なことに注意を解放するためのものです。インフラが扱われているなら——認証が動く、デプロイが自動化されている、データベースが本物なら——難しい問いに集中できます。これは本当の課題を解決するのか？ 体験（インタラクション）は直感的か？ データモデルは、ユーザーが実際に考える方法と一致しているか？
配慮、品質への意識、そして経験は、迅速で高品質な成果を届けるための最善の保証のままです。AIは実行を加速しますが、判断とセンスは人間の強みのままです。問題は、その判断をインフラの配管に使うのか、それともプロダクトを完璧にすることに使うのか、ということです。これが、私が自分自身のコンサルティング案件を構成する際に依拠している原則です。インフラは初日から解決されるので、毎時間がプロダクトに向かいます。
プロトタイピングがまだ意味を持つとき
これはドグマ的な議論ではありません。探索（検証）がコミットの前にあるべき、正当なケースも存在します：
- 何を作るべきか分からないとき。 コアとなるプロダクト仮説が検証されていないなら、軽量な探索は価値があります。ただし、探索すべきはコンセプトであって、インフラではありません。
- 規制のある環境。 医療、金融、航空には、プロダクションのセットアップに現実の制約を追加するコンプライアンス要件があります。
- ハードウェアに依存するシステム。 統合レイヤーがリスクになる場合は、まずそれをシミュレーションするのが理にかなっています。
しかし、ここでも問いは変わります。使い捨ての基盤ではなく、プロダクションの土台の上で探索できるのでしょうか？ ケント・ベックの「拡張コーディング（augmented coding）」のアプローチ—AIの支援でプロダクション対応のB+木ライブラリを作る—は、プロダクション品質と探索スピードはもはや対立しないことを示唆しています。(Tidy First, Substack)
より良いモデル：進化する垂直スライス
プロトタイピングの代替はウォーターフォールではありません。進化的アーキテクチャです。フォウラーとThoughtWorksが長年提唱してきた考え方で、いまAIによってさらに強化されています。原則は「完璧のためにではなく、変化のために設計する」。明確な境界、テストの自動化、そして頻繁で低リスクな調整を可能にするデプロイ運用によって、安全に進化できるアーキテクチャを作ります。(martinfowler.com)
アイデアはこうです。早い段階から実データベース、実認証、実デプロイを用意します—必ずしも完璧でなくてよいが、決して「使い捨て」でもない状態にする。そして、薄い垂直スライスとして、インクリメンタルに提供します。各スライスはリリース可能であり、各スライスは実在するものです。
VercelのCEOであるGuillermo Rauchは、個々の開発者が、以前は小さなチームでないと成しえなかったことを今では達成できるようになったと述べています。役割は「エージェントマネージャー（agent manager）」へと移っていき、あらゆる行を手で書くのではなく、AIエージェントをオーケストレーションすることになる。たった一人が数時間でプロダクション向けのインフラを足場（スキャフォールド）できるのであれば、使い捨てプロトタイプを正当化する根拠はかなり弱まります。
各垂直スライスは使い捨てではなく、リリース可能です。AIは、各スライスを正しく作るためのコストを下げます。ますます、プロトタイプそれ自体がプロダクトになります—少なくともそうできるのです。このアプローチで、プロダクションに近いシステムを素早く出荷しました。詳細はこちらをご覧ください。
結論
AIは探索の必要性をなくしませんでした。なくしたのは、使い捨ての土台の上に作る言い訳でした。
しかし、より深い教訓はこれです。プロダクションを最優先するアーキテクチャは、実はテックスタックの話ではありません。あなたが本当に重要なことに集中できるように道を切り開くこと—人々が実際に必要としているものを、彼らが受けるに値する配慮と品質で作ること—に他なりません。
プロトタイプ税（プロトタイプのコスト）は、常にトレードオフでした。2026年には、それを正当化するのがますます難しくなっています。
Matthias Huber — AI & ソフトウェアアーキテクト。数か月ではなく数日で実現する！ mhuber.ru
