# 経験のあるソフトウェアエンジニア

> 自分が書いていない系に手を入れ、何を世に出してよいかを決め、それがどう壊れるかに答える——ソフトウェアの仕事のうち、打鍵ではなく、特定のコードベースについての判断が大半を占める部分である。

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

## 適用範囲

保守されている本番のコードベースで数年を過ごしたエンジニア——レビューし、設計し、何を出すかを決める人——に向けて書いている。ここでは職位で切っている。フロントエンド、バックエンド、データエンジニアリングはレイヤーで切っており、それぞれ別のページを持つ。だから上級のフロントエンドエンジニアは二つのページに載り、その二つは別の問いに答える。入社直後の仕事は別に評価しており、テスト専門のエンジニアリングも独立したページを持つ。機械学習エンジニアリングとAI研究にもいまはページがある。サイト信頼性エンジニアリングは実在し、本当に別物であり、そしてまだここでは扱っていない——それは空白であって、ここに属するという判断ではない。

## 業務

### 自分が書いていない系に手を入れる

- 方向: いまも人が主導
- 根拠: 根拠あり(検証済みの記録を添付)
- 理由: このページで最も強い証拠が語っているのはこの業務であり、しかもその証拠は思いがけない向きを指している。参加者が自ら保守しているリポジトリの実際の課題を使った無作為化試験で、2025年当時のAIの道具を使った経験のある開発者は19%長くかかり、しかも自分は20%速かったと信じていた。変更に必要な文脈は、その特定の系についてその人の頭のなかにある模型が握っており、それを道具に供給する費用は、節約する分より大きい。
- これでは言えないこと: 試験は一つ、開発者は十六人、しかも彼らがよく知っている成熟したリポジトリである。著者自身、これが大半の開発者や新規の案件を描いたものではないと明言している。同じ道具が一年後にどう振る舞うかについては何も語っていないし、一度測られた減速は、その道具の恒久の性質ではない。
- 記録:
  - 2025-07-10 · 制限または撤回 · 経験のあるオープンソース開発者16人が実際の課題246件に取り組んだ METR の無作為化試験では、2025年初頭のAIの道具を使ったとき19%長くかかり、しかも本人たちは20%速かったと信じていた — https://flyvolo.ai/ja/changes/ev-20250710-junior-software-developer-2 (出典: https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/)

### 機械が書いたものをレビューする

- 方向: 新しい業務
- 根拠: 根拠あり(検証済みの記録を添付)
- 理由: 生成はボトルネックを取り除くのではなく移す。届くコードは増え、それを読む仕事はそのブランチに責任を負う者に降りかかる。GitHubがCopilotの実行基盤を主に自社のエージェントを使ってRustに移行した際、開発者の2,639件のメッセージのうち31.0%がレビュー、テスト、CIに費やされた。AI開発ツールを導入した米国のある機関は、その出力がコードベースに入る前にレビューと承認を受けなければならないと記録している。そしてStack Overflowによる49,009人の開発者の調査では、最も経験豊富な層が、ツールが生み出すものへの不信を最も強く報告している。
- これでは言えないこと: 生成されたコードの割合は、レビューにどれだけ時間がかかるかも、それがきちんと行われているかも、エンジニアの総数が変わったかも語らない。レビューの量が増えることも、自動的に良い仕事ではない——時間に追われたとき、最も雑にやられやすい部分である。
- 記録:
  - 2026-09-16 · 技術的能力 · GitHub は、一人の開発者が自社の Copilot のエージェントとともに Copilot のランタイムを832,378行の Rust へ移し、その開発者の2,639件のメッセージのうち31.0%がレビュー、テスト、CI に向けられたと報告した — https://flyvolo.ai/ja/changes/ev-20260916-experienced-software-engineer-4 (出典: https://github.blog/ai-and-ml/generative-ai/migrating-the-github-copilot-runtime-to-rust-using-copilot/)
  - 2025-06-23 · 使用者による採用 · Stack Overflow による 49,009 人の開発者調査:84% が AI ツールを使っている、あるいは使う予定であり、経験の長い層ほどその出力を信用していない — https://flyvolo.ai/ja/changes/ev-20250623-experienced-software-engineer-2 (出典: https://survey.stackoverflow.co/2025/ai)
  - 2025-04-15 · 実際の導入 · 米国移民関税執行局は、2025年4月15日にAI開発者ツールを本番導入したと報告し、その出力はコードベースに入る前に必ずレビューと承認を経なければならないと記している — https://flyvolo.ai/ja/changes/ev-20250415-experienced-software-engineer-3 (出典: https://github.com/ombegov/2025-Federal-Agency-AI-Use-Case-Inventory)

### どう壊れるかを見据えて設計する

- 方向: いまも人が主導
- 根拠: 根拠あり(検証済みの記録を添付)
- 理由: モデルは構成を提案し、流暢にそれを弁護できる。できないのは、その取捨の結果を背負うことである。そしてここでの取捨は技術上の好みではない——どの失敗ならこの組織が生き延びられるかについての賭けであり、それはコードではなくその組織についての事実に依る。
- これでは言えないこと: これは仕事の中身についての判断であって、測定ではない。設計レビューが外に出されることはまれである。ある政府省庁のエンジニアリング標準はその例外で、設計の責任はチームに残ると明記しているが、それ以外の場所で設計上の判断が機械に渡されているかどうかは、それが起きている会社の外からはほとんど観察できない。
- 記録:
  - 2026-03-20 · 制限または撤回 · 英国のある政府省庁のエンジニアリング標準は、AIは設計についての人の責任を置き換えられないと述べ、AIの支援を受けたあらゆる出力を本番に入る前に人が承認することを求めている — https://flyvolo.ai/ja/changes/ev-20260320-experienced-software-engineer-5 (出典: https://engineering.homeoffice.gov.uk/standards/use-ai)

### 何を世に出すかを決める

- 方向: いまも人が主導
- 根拠: 根拠あり(検証済みの記録を添付)
- 理由: 機械は今や、誰かが目を通す前に変更をはるかに先まで運べる。GitHubのCopilot実行基盤の移行では、エージェントと共に作業した一人の開発者が数か月で832,378行のRustを生み出し、何が受け入れ可能かを決め続けた。判断が明文化されている場合、それは人の判断である。Fedoraの評議会は、AIが貢献に対する唯一の、あるいは最終的な裁定者であってはならず、自動化がそれを実行する場合でも、受け入れに対する最終的な責任はその行為を承認する人間にあるとしている。
- これでは言えないこと: 一企業による自社プロジェクトの説明と、一つのオープンソースプロジェクトの貢献受け入れに関する規則である。いずれも企業一般でリリースの判断がどう下されているか、あるいはあらゆる検査を通ったものがどれほどの頻度でなお失敗するかを示さない。
- 記録:
  - 2026-09-16 · 技術的能力 · GitHub は、一人の開発者が自社の Copilot のエージェントとともに Copilot のランタイムを832,378行の Rust へ移し、その開発者の2,639件のメッセージのうち31.0%がレビュー、テスト、CI に向けられたと報告した — https://flyvolo.ai/ja/changes/ev-20260916-experienced-software-engineer-4 (出典: https://github.blog/ai-and-ml/generative-ai/migrating-the-github-copilot-runtime-to-rust-using-copilot/)
  - 2025-10-24 · 制限または撤回 · Fedora の評議会、貢献の唯一または最終の判定者としてAIを使うことを禁止し、受け入れの最終責任を人に置く — https://flyvolo.ai/ja/changes/ev-20251024-experienced-software-engineer-7 (出典: https://docs.fedoraproject.org/en-US/council/policy/ai-contribution-policy/)

### 他の誰かができるようにする

- 方向: いまも人が主導
- 根拠: 根拠あり(検証済みの記録を添付)
- 理由: この作業は、作業そのものの外にある理由で重みを持つようになる。下から入ってくる人が減るなら、判断力の継承は良い習慣ではなくなり、供給路そのものになる。一部の技術コミュニティはこれを明文化している。LLVMは good first issue のラベルが付いた課題でのAIツールの使用を禁じ、それらを新しい貢献者の学びの機会として残しており、新参者の変更をレビューすることがプロジェクトの次の貢献者を育てる方法だとしている。
- これでは言えないこと: 一つのオープンソースプロジェクトの規則が新参者のための作業を残しているにすぎない。企業内の指導については何も述べておらず、ここには若手の採用が減っているか、より多くの指導の仕事が上級者に降りかかっているかを測定したものはない。
- 記録:
  - 2026-01-16 · 制限または撤回 · LLVM、「good first issue」ラベルの課題でのAIツール使用を禁止し新規貢献者の学習機会として残す — https://flyvolo.ai/ja/changes/ev-20260116-experienced-software-engineer-6 (出典: https://llvm.org/docs/AIToolPolicy.html)

### コードを書き変える自律的な仕組みを引き受ける

- 方向: 新しい業務
- 根拠: 根拠あり(検証済みの記録を添付)
- 理由: この仕事は2022年には存在せず、既定で誰かに割り当てられることもない。生成がリポジトリに触れることを許される場所ならどこにでも現れる。AI開発ツールを導入した米国のある機関は、その出力がコードベースに入る前にレビューと承認を受けなければならないと記録しており、GitHub自身によるCopilot実行基盤の移行では、一人の開発者がエージェントを指揮し、移行先のアーキテクチャを守り、メッセージの大半をレビュー、テスト、設計上の異議に費やした。
- これでは言えないこと: 一機関の一覧への記載と、一企業による自社プロジェクトの説明である。いずれもこうした所有がどれほど一般的かを示さず、ここにはそれがすでに報酬の支払われる役割だと示すものもない。
- 記録:
  - 2026-09-16 · 技術的能力 · GitHub は、一人の開発者が自社の Copilot のエージェントとともに Copilot のランタイムを832,378行の Rust へ移し、その開発者の2,639件のメッセージのうち31.0%がレビュー、テスト、CI に向けられたと報告した — https://flyvolo.ai/ja/changes/ev-20260916-experienced-software-engineer-4 (出典: https://github.blog/ai-and-ml/generative-ai/migrating-the-github-copilot-runtime-to-rust-using-copilot/)
  - 2025-04-15 · 実際の導入 · 米国移民関税執行局は、2025年4月15日にAI開発者ツールを本番導入したと報告し、その出力はコードベースに入る前に必ずレビューと承認を経なければならないと記している — https://flyvolo.ai/ja/changes/ev-20250415-experienced-software-engineer-3 (出典: https://github.com/ombegov/2025-Federal-Agency-AI-Use-Case-Inventory)

## 引用のしかた

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