第一原理からの AI ファーストのソフトウェア設計：実践者のガイド
ほとんどのチームはその下にある前提を 1 つも見直さずに AI を採用しました。だから出力は速くなり、システムは悪くなったのです。
ほとんどのエンジニアリングチームがまだ声に出して言っていない問いがあります。モデルがコードを書けるなら、私たちは今いったい何が得意であるべきなのか。
私が聞く答えはほとんど防御的です。プロンプトのエンジニアリング。AI の出力のレビュー。どのツールに手を伸ばすかを知ること。すべて本物の技能で、すべて実際の転換の下流にあり、そしてどれも私が実践で見続けているものを説明しません。同じツールを、同じ四半期に、同じモデルで採用したチームが、まったく異なる場所に行き着くのです。一方の集団はより速くリリースしてソフトウェアが保ちます。もう一方はより速くリリースして、次の四半期を何を壊したか見つけることに費やします。
同じツール。逆の結果。その違いはモデルについてではありません。
誰も計算に入れなかった増幅器
DORA の 2025 年の AI 支援ソフトウェア開発の現状の報告がこれに数字を付けました。技術に携わる人の 90 パーセントが今や仕事で AI を使い、80 パーセント以上が生産性が上がったと信じています。どちらも意外ではありません。重要な発見は 3 つ目です。高い AI の利用は、ソフトウェアのデリバリーのスループットの増加とソフトウェアのデリバリーの不安定さの増加と同時に結びついている、というものです。
もう一度読んでください。これが主張の全体です。ツールはチームをリリースにおいて速くし、物事を動かし続けることにおいて悪くしました。一方ではありません。両方です。
DORA の枠組みは AI が増幅器であるというものです。それが降り立つ実践を何であれ拡大します。強いシステムはより強くなります。弱いシステムは弱いことにおいて速くなります。
つまり興味深い問いは「どう AI を採用するか」であったことは一度もありません。「AI は私たちの中の何を増幅するか」でした。そしてそれに答えることは、どのツールの決定より遠くまで戻ることを要求します。
ツールではなく問題から推論する
第一原理から考えることは無意味になるまで繰り返された語句の 1 つなので、私がそれで何を意味し何を意味しないかを具体的にしましょう。
類推による推論は、AI の採用のほとんどが見えた形です。開発の作業の流れがありました。新しい能力が来ました。その能力が作業の流れのどこに収まるかを問い、最小抵抗の地点、通常はコードの執筆に加え、他のすべてを同じままにしました。立ったままの会議、チケット、作業周期、レビューがすべて保たれました。作業の流れは与件として扱われ、ツールがそれに合わせられました。
第一原理からの推論はより難しい問いを立てます。プロセスを、ソフトウェアを構築することについて実際に、物理的に真実であるところまで剥いてください。それからそれらの真実のどれをモデルが変え、どれに触れなかったかを問うてください。生き残ったものから再構築してください。
これを正直にやると、AI が変えたのは正確に 1 つのことだと分かります。そしてそれはこのカテゴリが売ってきたものではありません。
コードを生み出すコストはほぼゼロになりました。コードが何であるべきかを決めるコストは動きませんでした。
有用なすべてはこの 1 つの非対称から出てきます。以下は、どの実践者にも記憶から言えてほしい 4 つの帰結です。
1 つ目：データモデルが製品である
画面はあらゆるアプリの最も揺れやすい部分であり、始めるのに最も誘惑的な場所です。目に見える部分だからです。同時に、捨てるのが最も安いべき部分でもあります。
データモデルは逆です。何を問えるか、何にインデックスを張れるか、全員を怖がらせるマイグレーションなしに後で何を変えられるかを決めます。下流のあらゆる能力は、その層で下された、あるいは即興で作られた選択によって制約されます。
コードが高くついたとき、この順序は自らを強制していました。考えていないスキーマに対して 100 の画面を手で書く人はいませんでした。100 の画面を手で書くのに 1 四半期かかったからです。生成はその自然な門を取り除きました。今、人間が一度もレビューしていないデータモデルに対してインターフェース全体を生み出せ、それは完成して見えます。
だから順序が意識的になる必要があります。まずモデル、次に契約、次にインターフェース。伝統的だからではなく、高くつく決定が変えるのがまだ安いうちに下される唯一の順序だからです。
2 つ目：先送りされた決定もやはり下される
これは実践者が過小評価するものです。
明示的に下さないあらゆる決定はやはり下されます。生成ツールが、生成の時点で、あなたの会社、コンプライアンスの表面、マイグレーションの履歴、次の四半期の計画を含まない文脈から下します。モデルは決めることを拒みません。もっともらしい何かを選んで先へ進みます。
解約された購読を持つユーザーはまだ何を見られるのか。2 人が同じレコードを変えたら何が起きるのか。メールアドレスは一意か、そして何の中で一意か。誰もこれらの問いをプロンプトしなかったので誰も答えず、しかしアプリは今 3 つすべてに答えを持っています。推論で選ばれ、本番でそれに当たることでしか発見できない答えです。
これはつくり手のコミュニティが70 パーセント問題と名付けたものの背後にある仕組みです。前進が止まるのは残りの作業が難しいからではなく、残りの作業が数百世代前に静かに下され、全体を分解せずにはもう変えられない決定によって塞がれているからです。
これを直す実践には今や名前があります。仕様駆動開発です。まず要件、制約、成功の基準を書いてください。その文書を正しさの源として扱ってください。エージェントにそれに基づいて構築させてください。GitHub は Spec Kit をリリースし、AWS は Kiro をリリースし、その収束は偶然ではありません。
3 つ目：生成が無料なら制約は書かれなければならない
何十年も、正しさは部分的にコードを書くコストによって担われていました。規則を実装するエンジニアリング担当者はその規則を頭に保つ必要がありました。人間の頭の中の暗黙の知識は制約を保存する許容できる場所でした。ループの中に常に人間がいたからです。
その保存場所はもう機能しません。制約が機械が読める場所（スキーマの制約、型、検証の規則、テスト、仕様の中の明示的な 1 行）で表現されていないなら、生成ツールに関する限りそれは存在しません。まさに驚こうとしている人の記憶の中にだけ存在します。
これが AI ファーストの設計の実践的な核心であり、華やかさはありません。不変条件をそれを強制できる層へ押し下げてください。「空でない」と「一意」はフォームの処理ではなくデータベースに。型はコードのコメントではなく境界に。認可は誰かがエンドポイントに書くのを覚えていた条件ではなく、システムが評価する方針として。
外に出したあらゆる制約は、モデルがもう間違えられない決定です。
4 つ目：あなたは今 2 種類の利用者のために構築している
最後のものは最も新しく、ほとんどのチームがまったく内面化していないものです。
あなたのアプリには今 2 種類のユーザーがいます。1 つは画面を見る人です。もう 1 つは API を呼ぶエージェントで、あなたのインターフェースを一度も見ず、良いデザインで説得されません。ある能力がユーザーインターフェースにあって API にないなら、エージェントの経済に関する限りそれは存在しません。
これには設計上の帰結があります。同等性は嬉しい追加ではありません。人間がインターフェース経由でできることは何でも、定義され、文書化され、発見可能な表面経由で到達できるべきです。これはまた、GraphQL がエージェントの利用にとって REST よりよく合う理由でもあります。自らを記述するスキーマは、人間が先に統合のメモを書かなくても機械が探索できるものです。
エージェントのために構築すれば、人間のインターフェースは副産物として単純になります。人間のためだけに構築すれば、納期の圧力の下で API を後から加えることになります。インターフェースを設計するのに可能な限り最悪の時間です。
これを飛ばすことがデータでどう見えるか
GitClear は 2023 年から 2026 年の 6 億 2300 万件のコード変更を分析し、保守性の絵は上のすべてと整合しています。
2023 年の基準に対して重複したコードブロックは 81 パーセント増です。1 つの送信の中でのコピー＆ペーストは 2022 年の 9.4 パーセントから 2026 年前半の 15.7 パーセントへ上昇しました。エラーを隠す構造は 47 パーセント増です。同時にファイル間の関数呼び出し、つまりコードの再利用の利用できる最も明確な信号は 35 パーセント減で、コードを整理する活動は 2022 年の変更の 21 パーセントから 2026 年の現時点で 3.8 パーセントへ崩れました。
エンジニアリング担当者は今、コードを整理するよりおよそ 5 倍多くコピー＆ペーストしています。2022 年にはこの比率は逆方向に働いていました。
これのどれもモデルの質の問題ではありません。再利用の代わりの重複、表面に出すのではなく飲み込むエラーの処理、起きなくなったコードの整理。これらは生成が安く構造が明示的に誰の仕事でもないときに得られるものです。出力は局所的にもっともらしく、全体として一貫しません。それはまさに画面から始まる作業の流れが検出できない障害の形です。
今週から始めてこの方法で働く方法
これのどれも組織の再編を要求しません。4 つか 5 つの習慣の順序を変えることを要求します。
- 最初の画面の前にデータモデルを書いてください。 エンティティ、関係、多重度、行を一意にするもの、削除で何が連鎖するか。ここでの 1 時間はプロジェクトで最もてこの効く 1 時間であり、ツールがあなたを積極的に飛ばすよう誘う 1 時間です。
- レビューする成果物を仕様にしてください。コードの差分ではなく。 仕様が正しく生成がそれに忠実なら、数千行の生成されたコードをレビューすることは演劇です。それらを生んだ文書をレビューしてください。議論がまだ安いうちに仕様について議論してください。
- 名前を付けられるあらゆる制約を外に出してください。 生成する前に、決して破られてはならない規則を列挙し、それぞれをシステムがそれを強制する場所に置いてください。会話の中に留まるものは何であれ、最終的に会話に一度も加わらなかった何かによって破られます。
- API を製品の表面として設計してください。 その後で人間のインターフェースをその利用者の 1 つとして扱ってください。これはエンジニアリングより順序の選択であり、それを遅く順序づけることが高くつかせる理由です。
- スループットだけでなく不安定さを計測してください。 DORA の発見は速さと脆さが一緒に上がったことなので、速度だけを測ることは自分の傾向の良い半分だけを見せます。変更の失敗率と復旧までの時間が、増幅器があなたのために働いているかを教える数字です。
これのコストは何か
トレードオフがないふりをするのではなく、それについて率直でありたいと思います。
この方法で働くことはプロジェクトの最初の週には遅く、その後のあらゆる週には明確に速くなります。これは本物のコストで、前もって、まさに勢いが最も価値あるように感じられ競合が目に見える何かをリリースしている瞬間に支払われます。これらすべてを飛ばしたチームが勝っているように見える作業周期があるでしょう。
規律の面でも無料ではありません。制約を書くことはインターフェースが現れるのを見るより楽しくありません。仕様をレビューすることはコードをレビューするより満足感がありません。これらの習慣は納期の圧力の下で腐り、それはそれらを重要にしている同じ圧力です。
そしてその一部は本当に当てはまりません。この週末にアイデアを検証していて結果を捨てるつもりなら、捨ててください。上記のどれも 2 日の寿命のソフトウェアにはやる価値がありません。ここでの主張はデモより長く生きるアプリについてです。
一度も自動化できなかった部分
コードの生産の周りに築かれた一部の役割は縮みます。一部は消えます。そうでないふりをすることは誰の準備も助けず、あらゆるエンジニアリングの仕事が安全だと言う人はあなたに親切をしていません。
しかし非対称が実際に何をしたか見てください。決定の表現を自動化し、決定そのものにはまったく手を付けませんでした。何を構築するか。何を構築しないか。どの不変条件が成り立つか。システムが決してしてはならないこと。境界がどこにあり、誰がそれを越えることを許されるか。
その仕事は常に難しい部分でした。ただ打鍵の労力の下に隠れていただけです。仕事のように見えるほど高くついた打鍵の下に。
打鍵が仕事であったことは一度もありません。
関連する読み物
実践を深く：仕様駆動開発。ツールを選んでいるなら：2026 年の最良の AI アプリビルダー。
よくある質問
「AI ファーストのソフトウェア設計」とは何を意味しますか。 コードのほとんどが手で書かれるのではなく生成され、一部の利用者が人間ではなくエージェントであるという前提を中心にアプリを設計することです。実践的には、データモデル、制約、API の契約が前もって明示的に定義されることを意味します。これらは生成があなたのために下せない決定だからです。
AI ファーストの設計は単に AI のコードのツールを使うこととどう違いますか。 AI のツールを使うことは変わらない作業の流れに能力を加えます。AI ファーストの設計は作業の流れの操作の順序を変えます。インターフェースの前にモデルと契約、レビューされる成果物としての仕様、強制できる層へ押し下げられた制約です。DORA の 2025 年の調査は AI の採用がスループットと不安定さを一緒に上げたことを見出しました。それはツールが変わって実践が変わらないときに起きることです。
AI 時代のソフトウェア設計の第一原理は何ですか。 4 つが成り立ちます。データモデルが製品であり画面はその 1 つのビューである。明示的に下さないあらゆる決定は生成ツールによって暗黙に下される。制約は誰かの頭の中ではなく機械が強制できる場所に住まなければならない。そしてあなたのアプリは今、人間のインターフェースとエージェントに向けた API の両方に仕えていて、それらは同等性を必要とする。
この方法で設計するとチームは遅くなりますか。 作業を追加するのではなく前に積みます。データモデルと仕様に集められる決定は、どうせ誰かが下す決定です。最初に意識的にか、後からモデルが推測することで暗黙にか、です。2 番目の道が修正の来る場所であり、修正は速くありません。
仕様駆動開発は AI ファーストの設計と同じものですか。 仕様駆動開発が実践で、AI ファーストの設計はより広いアーキテクチャの帰結の集合です。仕様駆動開発は仕様を書いてそれに基づいて生成することを覆います。AI ファーストの設計はデータのモデリングの順序、制約がどこで強制されるか、人間の利用者と並んでエージェントの利用者のために設計することも覆います。
これらすべてを飛ばして問題ないのはいつですか。 プロトタイプ、デモ、社内の一度きりのもの、そして破棄する予定のあらゆるものです。この負荷は、実際のユーザー、実際のデータ、そして時間による変化を生き延びなければならないソフトウェアにとってだけ担う価値があります。
