バックエンド開発者

英国の国家サイバーセキュリティ機関による指針で、同機関の主席セキュリティアーキテクトの一人が書いたもの。AIの支援を受けた開発を、完全な生成から手作業までの連続した幅のうえに置いている。認証や認可のロジックを組むとき、機微な個人データを処理するとき、秘密情報・トークン・認証情報を扱うとき、あるいはセキュリティ上の欠陥の帰結が重大になりうるときには、手作業の側へ寄せるよう助言している。これは助言であって拘束力のある規則ではなく、セキュリティのコードにAIを使うことを禁じてもいない。開発者が実際にどう働いているかについての数字は示していない。

失敗、撤回、規制、あるいは費用が導入を抑えている。判断を下げる、あるいはその不確かさを広げることがある。

同じ悉皆調査である:20の固定質問を、法定の義務のもとで報告する全機関に投げ、それぞれYかNで答え、製品名とライセンス数の区分を書かせる。「AIでコードを生成する」は45機関中31機関がY、20問中の7位。この行が数字以上の価値を持つのは製品の列のせいだ。挙がっている道具は三年前には存在しなかったものばかりである:農務省、退役軍人省、証券取引委員会ほか十数機関がGitHub Copilot、内務省がClaude Code、国土安全保障省と労働省がPoolside、人事管理局がCodex、保健福祉省がAmazon Q Developer。同じファイルの出張予約の行と比べてみるとよい。あちらでYと答えた機関の大半はSAP Concurを挙げている —— あの質問では機関はおおむね元から持っていたプラットフォームを指さしており、この質問ではそうしていない。限界は三つ。エネルギー省や環境保護庁の「10,000-50,000」という区分は企業ライセンスであり、このファイルの他の行の答えでもあるので、それでコードを書いている人数ではない。Yは雇用主が道具を持っていると報告しているのであって、その道具がどれだけのコードを書き、そのうちどれだけが残るかの測定ではない。そして質問は「コード」としか言っておらず、バックエンドかフロントエンドかも、書いている人が十年目か十か月目かも区別しない。この記録がここに付くのは、定型的なサービスコードを書くことがこの業務そのものだからであって、目録がそう言っているからではない。

雇用主がそれを本番に置いた。基準線を動かしうる——規模と、その場がどれだけ似ているかで重みづけされる。

392のバックエンド課題からなる査読済みのベンチマークで、各課題は仕様から実装すべきエンドポイントの組であり、機能テストと、不適切なアクセス制御や誤った認可を含むエンドツーエンドのセキュリティ攻撃(エクスプロイト)が付いている。正しさで最良のモデルは62%に達した。平均すると、各モデルが生成した正しいプログラムのおよそ半分が攻撃可能だった。正しくかつ安全なコードで最良のモデルは35%に達した。これは2025年のモデルが仕様からバックエンドをまるごと書いたものであって、既存のコードベースのなかの変更ではない。また著者の一部は、AIのコーディングエージェントをつくる会社に勤めている。

失敗、撤回、規制、あるいは費用が導入を抑えている。判断を下げる、あるいはその不確かさを広げることがある。

Uberのエンジニアによる査読済みの論文で、Uber自身の開発の流れのなかで動いている道具を扱う。18か月のあいだに、その道具はUberのGoのコードベースで再現可能なデータ競合を404件特定し、224件(55%)について修正を生成し、開発者はそのうち193件(86%)をコードレビューで承認した。退けられた修正には、最初のテストを通ったにもかかわらず誤っていると判断されたものが含まれていた。Uberはこの道具を売っていない。扱っているのは一つの言語、一つのコードベースにおける低レベルのデータ競合であって、サービスをまたぐトランザクション、冪等性、再試行、順序ではない。そして修正はすべて人のレビューを経た。

雇用主がそれを本番に置いた。基準線を動かしうる——規模と、その場がどれだけ似ているかで重みづけされる。

Googleのエンジニアが、社内の大規模なコード移行に言語モデルを使ったことを自ら説明したもの。ある事例研究では、Adsのコードベース(5億行超)のIDを、障害を引き起こしかねない、値が負に回り込む事態を避けるために32ビットから64ビットへ移す必要があった。取り込まれた変更に含まれるコードの修正の80%は完全にAIによって書かれたが、ほとんどの場合、人がモデルの変更の少なくとも一部を差し戻さなければならず、エンジニアは全体の時間が50%短縮されたと見積もった。論文は、コードレビューと変更の展開にはなお人の操作者が必要だと述べている。Googleは使ったモデルを売っている。これはコードベース全体にわたるコード上の型の変更であって、稼働中のデータベースのスキーマ移行ではない。

雇用主がそれを本番に置いた。基準線を動かしうる——規模と、その場がどれだけ似ているかで重みづけされる。

大手テクノロジー企業一社の自己申告で、「生成」をどう数えるか(補完か関数まるごとか)の定義はない。この数字はGoogleの新しいコード全体についてのもので、どの種類のコードかは言っていない。この記録がこのタスクに付くのは、定型的なサービスのコード——ハンドラ、検証、サービス間の呼び出しとそれらのテスト——を書くことがまさにこのタスクだからであり、この発言がバックエンドの仕事を名指ししているからではない。採用については何も述べておらず、レビューの工程はエンジニアに残った。

雇用主がそれを本番に置いた。基準線を動かしうる——規模と、その場がどれだけ似ているかで重みづけされる。

Amazon 自身の技術について Amazon 自身が出した見積りであり、しかもその道具を売っている会社が公表している——作業をした当事者、それを測った当事者、それを売っている当事者が同一である。外から確かめられないので、ここに明記しておく。会社は方法も公表している。節約された時間は、移行された Java の依存関係の数から、手作業なら依存関係一つにつき開発者の一日以上がかかると仮定して見積もられた。この移行が何であるかに注意すること——言語の版の更新には、コンパイラと既存のテスト一式という審判がついているので、各段で成否が機械的に確かめられる。この種の自動化にとって考えうる最も有利な形であり、バックエンドの仕事一般についての結果ではない。そして何が主張され、何が主張されていないかにも注意すること——4,500年はやらずに済んだ作業であり、千人を超える開発者が関わっており、そのうち誰かが去ったとも、職が一つ消えたとも、どこにも書かれていない。

雇用主がそれを本番に置いた。基準線を動かしうる——規模と、その場がどれだけ似ているかで重みづけされる。

著者の大半がMicrosoftに属する査読済みの論文で、クラウドの障害に対応するオンコールのエンジニアのための道具を扱う。その診断情報収集の構成要素は、四年を超えてMicrosoft社内の30を超えるチームに導入されている。言語モデルを使う根本原因予測の構成要素は、予備段階での成功を経て、一つの障害管理チームで数か月にわたり実際に運用されている。これは診断を助けるものであり、何を切り戻すか、何を受け入れるかを決めるものではない。またMicrosoftは、関わっているモデルを売っている。

雇用主がそれを本番に置いた。基準線を動かしうる——規模と、その場がどれだけ似ているかで重みづけされる。

この職の目に見える半分——エンドポイントと配管——が晒された半分であり、そして、あなたが任されていたであろう仕事である。持ちこたえるのは「決して起きてはならないこと」についての部分であり、それは、実際に何かが起きたときにその場にいることで学ぶ。落ち着かないと感じるより早く、当番の輪に近づくこと。

最も晒されている業務については、あなたの位置はフロントエンドのページより強い。そして理由は仕事が難しいからではない——間違いが高くつき、しかも目に見えないので、責任が一点に集まるからである。それが生む失敗の形に気をつけること。誤りが何か月も静かなままである系に対して、生成された変更をレビューすることである。

留まって強くする

間違いが高くつく場所へ行く

決済、元帳、本人確認、規制当局が関わるもの——監督のない変更が許されていない領域であり、だからレビューと責任は、当然のものとして期待されるのではなく、費用がついている。

職の形を組み替える

自律的な仕組みが越えてよい境界を引き受ける

誤りが静かなままになるサービスのなかで、自動の変更が何に触れてよいかを誰かが決めなければならない。大半のチームでそれは誰にも与えられておらず、だからこそ職務記述書ではなく事故の振り返りのなかに現れる。

隣へ移る

データや基盤の仕事へ移る

一貫性、故障、費用についての筋道の立て方はそのまま移るし、どちらも、同じ判断をより広い面に当てる場所である。

部分ごとに速さが違うので、一つの数字は、あなたに必要なものを隠してしまう。エンドポイントを書くことはすでに大半が機械の仕事である。二つの要求が同時に届いたとき何が決して起きてはならないかを決めることや、エラーの文面が何を明かしてよいかを決めることは動いていない。どちらも打鍵ではなく、答える立場だからである。確かめられる信号——前四半期に何かが壊れたとき、難しかったのは見つけることだったか、それとも何をするかを決めることだったか。

最も目に見える業務については晒され具合が低い。そしてその理由は、安心として受け取るより理解する価値がある——バックエンドの正しさはしばしば目に見えず、間違うと高くつくので、仕事に占める責任の割合が大きい。それは難しさの順位ではなく構造の違いであり、変わりうる——この職のエンドポイントの半分は、フロントエンドの半分とまったく同じ条件で晒されている。

面接についてはまだ変わっていない。仕事についての正直な切り分けはこうである——アルゴリズムを思い出せることの重みは以前より下がり、故障について筋道を立てられることの重みは上がった。すでに苦しんでいる系に再試行が何をするかを知っていることは、システム設計の設問が試そうとしているのと同じ技能を、本物に当てたものである。一覧からではなく、自分たちの事故から学ぶこと。

すでに草稿は書けるし、そこは制約ではない。制約は、それが決して何をしてはならないかを誰かが保証し、何年も後にデータを失わずに移行し、そして壊れたときに起きていなければならないことである。それらは責任の位置であり、責任は安くなっていない——規制のかかった領域では、むしろより明確に求められるようになった。