# バックエンド開発者

> 間違いが高くつき、しかも目に見えない部分を引き受ける——一貫していなければならないデータ、二度動いてはならない金、そして午前三時にも上がっていなければならないサービス。

ページ: https://flyvolo.ai/ja/careers/backend-developer
影響指数: 54/100 · 確信度 確度が低い · 評価日 2026-09-12
これは失業の確率ではありません。

## 適用範囲

サービス、API、データの層をつくるエンジニアに向けて書いている。ここでは職位ではなくレイヤーで切っている——若手と経験者のページは逆の切り方であり、上級のバックエンドエンジニアは両方に載る。基盤やサイト信頼性の仕事は重なるが、答える対象が違う。データの取り込みには独立したページがある。

## 業務

### エンドポイントと、そのあいだの配管

- 方向: 自動化されつつある
- 根拠: 根拠あり(検証済みの記録を添付)
- 理由: 仕様がはっきりしていて、学習の素材に大量に含まれていて、走らせれば確かめられる——どの業務であれ生成に向いた強い筋書きにする、同じ三つの性質である。しかもこれは、外から見たときのバックエンドの仕事のかなりの部分でもある。
- これでは言えないこと: エンドポイントを生成することは、それが存在すべきかを決めることでも、何を保証しなければならないかを決めることでも、二度呼ばれたときに何が起きるかを決めることでもない。この仕事で高くついていたのは、打鍵ではなかった。
- 記録:
  - 2026-04-13 · 実際の導入 · 米連邦政府の45機関のうち31機関が、2025年の連邦AI用例目録で商用のAIコーディングツールを報告し、GitHub Copilot、Claude Code、Codex、Poolsideの名を挙げた — https://flyvolo.ai/ja/changes/ev-20260413-backend-developer-2 (出典: https://github.com/ombegov/2025-Federal-Agency-AI-Use-Case-Inventory/blob/3c225ba8438e48306ace7698c8c7feb9486cbc69/Data/2025_consolidated_COTS_AI_use_cases.csv)
  - 2024-10-29 · 実際の導入 · Alphabet の最高経営責任者が2024年第3四半期の決算説明会で、Google の新規コードの四分の一以上が AI によって生成され、その後エンジニアがレビューして受け入れていると述べた — https://flyvolo.ai/ja/changes/ev-20241029-backend-developer-3 (出典: https://blog.google/company-news/inside-google/message-ceo/alphabet-earnings-q3-2024/)
  - 2024-08-01 · 実際の導入 · Amazon は、自社の本番の Java アプリケーション数万件を Java 8 または 11 から Java 17 へ自律的な仕組みで移したと述べ、手作業なら4,500年を超える開発作業と見積もった — https://flyvolo.ai/ja/changes/ev-20240801-backend-developer-1 (出典: https://aws.amazon.com/blogs/devops/amazon-q-developer-just-reached-a-260-million-dollar-milestone/)

### 同時に物事が起きても正しさを保つ

- 方向: いまも人が主導
- 根拠: 根拠あり(検証済みの記録を添付)
- 理由: この種の不具合はテストに現れず、何か月も現れないことも多い。それを考えるには、ほかに何が走っているのか、途中で落ちたとき何が残るのかについての模型を頭に保つことが要る。そして正しい答えは、目の前のコードではなく、事業が交わした保証に依る。
- これでは言えないこと: Uberは、道具がいまや自社のGoのコードにある低レベルのデータ競合の修正を起草しており、コードオーナーがその大半を受け入れ、テストは通ったが誤っていたものをいくつか退けていると報告している。それは一つのコードベースにおける競合であって、サービスをまたぐトランザクションや順序ではない。障害が生成された並行処理のコードに起因すると公に言われることはまずないが、その沈黙は、それが起きていないことの証拠にはならない。
- 記録:
  - 2025-04-22 · 実際の導入 · Uberは、LLMを使った自社の道具が18か月のあいだに、自社のGoのコードベースにある404件のデータ競合のうち224件について修正を生成し、開発者がそのうち193件をコードレビューで受け入れたと述べている — https://flyvolo.ai/ja/changes/ev-20250422-backend-developer-4 (出典: https://arxiv.org/abs/2504.15637)

### データの模型と、使われながらのその変更

- 方向: いまも人が主導
- 根拠: 根拠あり(検証済みの記録を添付)
- 理由: 初期のスキーマの判断は、何年も経ってから、いまのコードからはどの道具にも見えない形で高くつく。費用はすでにデータのなかに書き込まれてしまったものに宿っているからである。移行はまた実務上取り返しがつかず、それは、助けられるのではなく誰かが責任を負わなければならない部類に入る。
- これでは言えないこと: Googleは、IDの大規模な移行の一つで、コードの大半をAIが書き、変更はすべて人がレビューして展開したと報告している。それは一社におけるコードの変更であって、稼働中のスキーマの移行ではない。ここでの主張は、誰が打つかではなく、誰が決め、誰が答えるかについてである。
- 記録:
  - 2025-01-12 · 実際の導入 · Googleは、AdsのIDを32ビットから64ビットへ移す移行で取り込まれたコードの変更の80%が完全にAIによって書かれた一方、コードレビューと展開にはなお人が必要だったと述べている — https://flyvolo.ai/ja/changes/ev-20250112-backend-developer-5 (出典: https://arxiv.org/abs/2501.06972)

### 誰が何を見てよいか

- 方向: いまも人が主導
- 根拠: 根拠あり(検証済みの記録を添付)
- 理由: 生成は、述べられた要求に向けて最適化する。そして認可の不具合とは、まさに誰も述べなかった場合のことである。ここはまた、自信たっぷりでもっともらしい誤答が最も危険な領域でもある。誰かがそれを突くまで、正しい答えとまったく同じに見えるからである。
- これでは言えないこと: 英国のサイバーセキュリティ機関は認可のロジックを手書きに近い形で書くよう助言しており、あるベンチマークでは、モデルがつくった動くバックエンドのおよそ半分が攻撃可能だった。どちらも、決着をつけるもの——同じコードベースのなかで生成されたコードと手で書かれたコードを分けて欠陥を数えた研究——ではない。規制のかかった環境では、ここに人の署名がもともと要求されている——効いているのは難しさそのものより、その要求のほうかもしれない。
- 記録:
  - 2026-06-18 · 制限または撤回 · 英国の国家サイバーセキュリティセンターは、AIの支援を受けて認証や認可のロジックを組むときには、手でコードを書くほうへ寄せるよう開発者に助言している — https://flyvolo.ai/ja/changes/ev-20260618-backend-developer-6 (出典: https://www.ncsc.gov.uk/blogs/the-vibe-coding-spectrum-approach-to-ai-assisted-software-development)
  - 2025-05-30 · 制限または撤回 · 392のバックエンド課題で、最良のモデルのコードが正しくかつ安全だったのは35%にとどまり、モデルが書いた動くプログラムのおよそ半分は攻撃可能だった — https://flyvolo.ai/ja/changes/ev-20250530-backend-developer-7 (出典: https://arxiv.org/abs/2502.11844v3)

### いくらかかり、どれだけ速いか

- 方向: 増強されつつある
- 根拠: 根拠あり(検証済みの記録を添付)
- 理由: 病んだ問い合わせを見つけ、索引を提案することについて、道具は本当に強い。弱いのは取捨のほうである——速さのために金を使うことは事業上の判断であり、どの要求が大事かを知るには、その製品が何のためにあるかを知っていることが要る。
- これでは言えないこと: これが実務でどれだけ道具主導になっているかは、ここでは何も測っていない。そして答えは、観測に予算のあるチームとないチームとで、まったく違う。
- 記録:
  - 2024-08-01 · 実際の導入 · Amazon は、自社の本番の Java アプリケーション数万件を Java 8 または 11 から Java 17 へ自律的な仕組みで移したと述べ、手作業なら4,500年を超える開発作業と見積もった — https://flyvolo.ai/ja/changes/ev-20240801-backend-developer-1 (出典: https://aws.amazon.com/blogs/devops/amazon-q-developer-just-reached-a-260-million-dollar-milestone/)

### 呼び出しに起こされる人であること

- 方向: いまも人が主導
- 根拠: 根拠あり(検証済みの記録を添付)
- 理由: 見立ての段はますます助けられており、それは本当に効く。判断のほうはそうではない。サービスを戻すために既知の損失を受け入れると選ぶことは、誰かが引き受けなければならない結果を伴う判断であり、しかも設計からして情報が欠けたまま下される。
- これでは言えないこと: これは、オンコールの負担が重くなっているのか軽くなっているのかについては何も言っていない——それこそ大半のエンジニアが本当に気にしている問いであり、そして誰も公表しない数字である。
- 記録:
  - 2023-11-13 · 実際の導入 · Microsoftは、LLMを使った障害対応の道具のうちデータ収集の部分が四年にわたり社内の30を超えるチームで使われ、根本原因の予測の部分は一つの障害対応チームで使われていると述べている — https://flyvolo.ai/ja/changes/ev-20231113-backend-developer-8 (出典: https://arxiv.org/abs/2305.15778v4)

## 引用のしかた

- 単位は職名ではなく業務です。どの業務が変わり、どれが変わらないのかを述べてください。
- 各業務の根拠と限界を一緒に伝えてください。推論は結論ではありません。
- このページは年数を示しません。ここから年数を導き出さないでください。
- 詳しくは: https://flyvolo.ai/llms.txt