私はシステムを作っている。少なくとも、自分ではそう思っている。しかし、別の視点から見れば、私がやっていることはシステムを壊す行為かもしれない。新しい仕組みを導入するとき、既存のワークフローは変わり、今まで機能していたプロセスが無効化される。創造と破壊は、同じ行為の表裏です。
AIによってプログラミングの敷居が下がり、エンジニア以外の人もコードを書けるようになりつつあります。Claude CodeのようなAgentic Codingツールの発展によって、自然言語で指示するだけでシステムの一部を作り変えることができる。全員が創造者であり、同時に破壊者になれる時代が来ています。
この変化は、バックエンドエンジニアの仕事を大きく変えつつあります。
暗黙の均衡
ソフトウェア開発において、「人がレビューしてOKならOK」というプラクティスは長く機能してきました。しかし、これが機能していたのは、変更の速度と量が人間の認知能力の範囲内に収まっていたからです。コードを書く速度、プルリクエストの頻度、デプロイの間隔——これらが人間のレビュー能力と偶然一致していた。品質保証というよりも、暗黙の均衡だったのかもしれません。
Agentic Codingは、この均衡を崩します。機械がコードを生成する速度は人間のレビュー速度をはるかに超え、非エンジニアもシステムに変更を加えられるようになる。変更の総量が爆発的に増えたとき、「人が全部見る」という前提は成立しなくなります。
ここで問われるのは、「では人は何をすべきか」です。
バックエンドから見える景色の変化
バックエンドエンジニアとして、APIやデータベースを設計するとき、「誰がこのシステムを使うか」を考えます。以前は、利用者は自分たちが作ったプロダクトや、連携する他のシステムでした。呼び出し元はある程度予測可能で、仕様書通りにリクエストが来ることを前提に設計できた。
今、その前提が変わりつつあります。AIエージェントがAPIを直接叩きに来る。そのエージェントは確率的に振る舞い、想定外のパラメータを送ってくることもある。さらに、非エンジニアがAIを使ってそのAPIの上にツールやワークフローを構築する。利用者の多様性と予測不可能性が、一段階上がりました。
これはバックエンドにとって脅威でしょうか。私はむしろ、面白い設計問題だと感じています。
壊れることを前提とした設計
予測不可能な利用者を前提にするなら、「壊されないように守る」だけでは不十分です。壊れることを受け入れた上で、システムの本質的な価値を失わない設計が求められます。
具体的には、いくつかの設計判断が重要になります。
壊していい層と壊してはいけない層を分ける。 マスタデータのような、システムの根幹をなすデータは厳密に守る。読み取り専用にする、バックアップを取る、AIエージェントからの直接書き込みを禁止する。一方で、ユーザーが試行錯誤する層——ワークフローの設定やツールの構成——は壊れても復元できるように設計する。全てを同じ強度で守ろうとすると、硬直化して何も変えられないシステムになります。
誰に何を許可するか設計する。 人間、AIエージェント、AIを使った非エンジニア——それぞれに適切な権限を設計する必要があります。これは従来のロールベースアクセス制御の延長にありますが、「確率的に振る舞う利用者」を権限設計の対象に含めるのは新しい問題です。
「良さ」をより抽象的なレイヤーで定義する。 従来のテストは、期待する結果と実際の結果が一致するかどうかで正しさを判定できました。しかし、AIが関わるシステムでは出力が確率的になります。「このレスポンスは正しいか」ではなく、「このシステムの振る舞いは目的に沿っているか」という、より抽象的な問いに答える必要がある。LLM-as-a-Judgeのような技術は、この文脈で生まれています。
人の役割の移動
これらの設計判断を見ると、エンジニアの役割が具体から抽象へ移動していることに気づきます。
コードを書くこと自体は機械に任せられるようになる。エンジニアの思考としても、機械に任せられることは機械に任せたい。その延長で考えると、エンジニアが担うべきは「何を守り、何を壊していいのか」を定義し、その定義をシステムとして実装することです。
ガードレール[1]、ハーネスエンジニアリング[2][3]、コンテクストエンジニアリング[4]、LLM-as-a-Judge[5]——最近生まれているこれらのテクニックは、まさにこの需要から来ています。人間のレビューというボトルネックを、より構造的な仕組みに置き換える試みです。
何を目的とするのか、何を良いとするのか——その定義は人間が行い、機械に伝わる形にする。抽象的なレイヤーでの判断が、むしろ重要性を増しています。
この変化は、個人の役割だけでなく、プロダクトや業界の構造にも及んでいます。
SaaSの変容と基盤の価値
「SaaS is Dead」という議論があります[6]。Satya Nadellaの発言をきっかけに広まったこの議論の本質は、SaaSが消滅するということではなく、その利用のされ方が根本的に変わるということです。AIエージェントがUIを介さずシステムを直接操作し、シートベースの課金は成果ベースに移行し、複数のSaaSに分散していたワークフローが統合されていく。
この変化の中で、むしろ重要性を増すのが基盤です。UI層の差別化が薄れるなら、プロダクト開発において最も設計判断が問われる領域はバックエンド——データ設計、権限設計、評価基準の設計——に移りつつあります。人間が操作する前提で設計されたインターフェース層が変容する一方で、データをどう守り、誰に何を許可し、何を「良い」とするか——その設計はなくならない。利用者が人間からエージェントに広がるほど、基盤の設計はより慎重に、より意図的に行う必要があります。
良いルールは良い破壊を生む
以前、「プロダクトを作ることはシステムに加担すること」という記事で、技術力を「システムを変える力」として捉え直せるのではないかと書きました。今回はソフトウェアシステムの設計に焦点を当てましたが、壊していい層と壊してはいけない層を分けるという問いは、チームや組織、業界のルール設計にも同じことが言えると思います。
この問題は、今までより難しく、面白くなっていると思います。私たちはシステムを作りながら壊している。その両方が安全にできる基盤を作ることが、今の自分のテーマであると思っています。
参考
[1] CIO, "The Agent Control Plane: Architecting Guardrails for a New Digital Workforce" (2026)
[2] Martin Fowler, "Harness Engineering"
[3] LangChain Blog, "Improving Deep Agents with Harness Engineering" (2026)
[4] Tobi Lütke on Context Engineering — "the art of providing all the context for the task to be plausibly solvable by the LLM"
[5] Evidently AI, "LLM-as-a-Judge: A Complete Guide to Using LLMs for Evaluations"
[6] IDC, "Is SaaS Dead? Rethinking the Future of Software in the Age of AI" (2025) — Satya Nadellaの発言(BG2 Podcast, 2024)を受けた分析