SESのコーディング案件が1年でほぼ半減した。エンジニアファクトリーが公開した6,813件の案件分析データによると、「コーディング中心」に分類される案件の割合は2025年前半（1〜6月）の24.8%から2025年後半〜2026年前半（10月〜翌3月）には13.5%まで低下した。約11ポイントの下落、率にして45%の縮小だ。
この変化の背景にあるのがClaude CodeとOpenAI Codexの普及だ。「AIがコードを書く」が現実になりつつある今、SESエンジニアの仕事は何が変わり、何が変わらないのか。データと現場の両面から整理する。
エンジニアファクトリーが発表した分析（2025年1月〜2026年3月の15ヶ月間、対象6,813件）は、SES市場の案件構造がこの1年で大きく変化したことを示している。なお、比較は「前半6ヶ月（2025年1〜6月）」と「後半6ヶ月（2025年10月〜2026年3月）」の二期間で行われている。
出典: エンジニアファクトリー「2026年SES案件動向レポート」
| 案件種別 | 2025年1〜6月 | 2025年10月〜2026年3月 | 増減 |
|---|
| コーディング中心 | 24.8% | 13.5% | ▼11.2pp |
| インフラ | 37.5% | 50.9% | +13.4pp |
| テスト・QA | 33.8% | 42.8% | +9.0pp |
| AI関連 | 6.5% | 13.5% | +7.0pp |
コーディング中心案件が減る一方で、インフラ・テスト・AI関連がそれぞれ拡大している。「コードを書く仕事」から「インフラを設計・運用する仕事」「AIを組み込む仕事」「品質を保証する仕事」へのシフトが、数字に表れている。
AI関連案件の件数ベースの変化も大きい。2025年Q1（1〜3月）の88件から2026年Q1（1〜3月）には184件へと2倍超に増加した。単価面でも差が出ている。AI案件の平均単価は77.9万円で、非AI案件の71.6万円より6.3万円高い。さらに100万円超の高単価案件の比率は8.8%から12.7%に上昇している。
案件構造が変化した理由は複数ある。
一つは開発ツールの変化だ。GitHub CopilotやCursor、Claude Codeといったコーディング支援AIが広まり、以前は複数人で1週間かかっていたコーディング作業が、少人数で短期間に完了するようになった。結果として、「コーディング専門の人員を何人も常駐させる」という発注形態が減っている。
もう一つは上流へのシフトだ。デジタル化・クラウド化が進むにつれ、「要件定義・設計・インフラ構築」段階での外部エンジニア活用が増えている。コーディング以前の工程に、より多くの専門人材が求められるようになっている。
Claude CodeはAnthropicが開発した自律型コーディングエージェントだ。その開発者であるBoris Chernyは2026年初頭、Business Insider Japanのインタビューでこう述べている。
「現時点で、私にとってコーディングは実質的に解決された課題だ」
——Boris Cherny（Claude Code開発者）
出典: Business Insider Japan
Chernyが次の主戦場として挙げたのは「仕様書の作成」と「ユーザーとの対話」だ。コードを生成するAIは成熟しつつある。次に問われるのは、何を作るかを決め、誰のために作るかを理解する能力だということだ。
著者コメント（小川将司）
この発言を読んだとき、SESの現場で感じていた変化と一致した。コーディング自体を依頼されることは減り、「このシステムをどう改善するか」「どのインフラ構成が要件に合うか」を考えるフェーズでの相談が増えている。「書ける」から「考えられる」への移行は、確実に起きている。
OpenAIが提供するCodexは2026年4月時点で週間アクティブユーザー300万人に達した（2026年4月7日、OpenAI CEO Sam Altman発表）。同発表によれば、OpenAI社内でのCodex導入後、PRマージ数は70%増加したとされる。毎分150億トークンを処理するインフラが、開発現場のコード生産量を根本的に変えている。
「AIが書くコード」が本番環境に入る量は、人間単独の時代と比べ急増している。これは何を意味するか。コードを書く作業の希少性は下がり、「そのコードが正しいかを判断する能力」「本番に入れる前にレビューする能力」「そもそも何を作るべきかを決める能力」の価値が相対的に上がるということだ。
現状のAIコーディングツールが得意な領域と苦手な領域を整理する。
AIが得意な領域
- 仕様が明確なロジック実装（CRUD処理・計算ロジック・API連携）
- テストコードの生成
- リファクタリング・コードレビュー支援
- ドキュメント自動生成
AIが苦手な・人間が必要な領域
- 曖昧な要件から仕様を引き出す（顧客ヒアリング・要件定義）
- 組織固有のドメイン知識・業務ルールの理解
- 非機能要件の設計判断（パフォーマンス・セキュリティ・可用性の優先度付け）
- 複数ステークホルダー間の調整・合意形成
- 既存システムの複雑な文脈の読み解き
SESの案件でいえば、「コードを書く」部分はAIが代替しやすい。一方で「客先の業務を理解し、何を作るべきかを決め、関係者を調整する」部分は、現場にいる人間が担う必要がある。
コーディングAIの普及で恩恵を受けやすいのは、ツールを自由に選べる環境にいるエンジニアだ。しかしSESエンジニアには、客先のセキュリティポリシーによってAIツールの利用が制限されるケースが少なくない。
金融機関・官公庁・大手製造業の社内SEに常駐するエンジニアからよく聞く話がある。「GitHub Copilotは申請が通らない」「Claude Codeは情報漏えいリスクを理由に禁止されている」「ChatGPTへの入力は社外秘データを含むため使用不可」といったケースだ。
Heydayに相談に来るエンジニアでも、2026年Q1時点で相談者の約3割が「現場でAIツールをほぼ使えない」と答えている。
著者コメント（小川将司）
これはSES特有の二重構造の問題だ。所属会社のAI活用方針と客先のセキュリティポリシーの両方をクリアしないと、ツールを使えない。正社員エンジニアより制約が多い状況で、それでもスキルを磨き続ける必要がある。この現実を書いているメディアがほとんどないため、ここで明示する。
現場でAIツールが使えなくても、市場はAI活用スキルを評価する方向に動いている。Findyが2025年9月に実施した採用調査（対象220社）では、AI活用経験を採用評価する企業の割合が3ヶ月で18.1%から57.0%（3.2倍）に急増した。
案件更新やキャリアアップの場面でAI活用経験を問われるケースは増えている。「現場で使えないから」という理由でスキル開発を後回しにすると、次の案件選びに影響が出る。現場外での自己研鑽・副業・個人プロジェクトでのAI活用経験が、SESエンジニアの差別化要素になっている。
エンジニアファクトリーのデータと現場の変化を踏まえ、需要の方向性を整理する。
1. インフラ設計・クラウドアーキテクチャ
エンジニアファクトリーデータでインフラ案件は37.5%→50.9%に拡大した。AWSやGCP・Azureのアーキテクチャ設計、IaC（Terraform・Ansible）の実務経験が特に求められている。AI活用の文脈でも、LLMを本番で動かすためのインフラ設計（GPU/TPU最適化・レイテンシ管理・コスト設計）は人間が担う必要がある領域だ。
Heydayが2026年Q1に扱ったインフラ系AI案件では、平均単価が83〜95万円帯に集中していた。AI案件平均（77.9万円）より高い水準だ。
2. 上流工程（要件定義・基本設計・PM補佐）
コーディングが自動化されるほど、「何を作るか」を決める工程の価値が上がる。要件定義・基本設計・プロトタイプ検証・ステークホルダー調整のスキルは、AIが代替しにくい。SESでも「設計フェーズから入れるエンジニア」の需要は堅調だ。
Gartnerの国内調査（2025年7月、n=400、有料レポート）では、コード生成・補完でのAI利用率が前年比約3倍（49.0%）に達している。コーディング自動化が進む現場では、設計工程に人員を厚く配置する傾向が出始めている。
3. AI活用スキル（プロンプト設計・LLM統合・AI評価）
エンジニアファクトリーのAI案件は88件→184件（2倍超）に増加し、平均単価も非AI案件より6.3万円高い。具体的に需要があるのは「LLM APIを使ったアプリケーション開発」「RAG（検索拡張生成）システムの構築」「AIの出力品質評価・ファインチューニング」だ。
Findy採用調査（2025年9月、220社）でAI活用経験を採用評価する企業が3ヶ月で3.2倍になった事実は、採用市場の変化を端的に示している。
1. 単純なコーディング専門（仕様書どおりに実装するだけ）
エンジニアファクトリーデータが示す通り、コーディング中心案件は24.8%→13.5%に縮小した。「仕様をもらってコードを書く」という作業は、AIコーディングツールが部分的に代替できるようになっている。コーディング力それ自体は必要だが、それだけで差別化する時代は終わりに近づいている。
2. テスト専門（手動テスト・テストケース作成のみ）
テスト・QA案件の割合は33.8%→42.8%に増えているが、内容が変化している。増えているのは「自動テスト設計・テスト基盤構築・品質保証プロセス設計」だ。一方、「テスト仕様書を受け取って手動でテストする」という作業はAIによる自動化が進んでいる。テスト専門でも「何をどうテストするか設計できる」スキルがなければ、案件の選択肢が狭まる。
現場でAIツールが使えない場合でも、業務時間外での経験を積むことは可能だ。具体的な方法として以下が有効だ。
- 個人プロジェクトでClaude CodeまたはCursorを使う: GitHubにリポジトリを作り、実際のプロダクトをAI活用で構築する経験を積む。副業案件に使っても良い
- OpenAI Codex APIをラップしたツールを作る: LLM API連携の実装経験は、AI案件の入口になる
- プロンプトエンジニアリングの実験を記録する: 業務と近いユースケースでプロンプト設計の試行錯誤をNotionやZennにまとめ、「経験の言語化」につなげる
案件データが示す通り、インフラ需要は拡大している。今から着手するなら以下が費用対効果が高い。
- AWS Solutions Architect Associate: インフラ設計の基礎として最も案件への直結性が高い
- Terraform実装経験（IaC）: AI時代のインフラ自動化の文脈で需要が伸びている
- Kubernetes基礎（CKA）: コンテナオーケストレーションはAI推論基盤でも必須になっている
これらのスキルは、Heydayが扱うインフラ系AI案件（平均単価83〜95万円帯）への入口にもなる。
案件を変えなくても、今の現場で上流工程への関与を増やすことはできる。
- 設計レビューに積極的に参加する: 設計書が回ってきたときに意見を出す機会を作る
- 要件の背景を顧客に確認する: 「なぜこの機能が必要か」を聞く習慣が、上流工程スキルの基礎になる
- 自分の担当領域の設計書を自分で書く: コーディング前に設計書を書く経験が、次の案件での役割拡大につながる
現場でのこうした動きは、次の案件交渉や案件選びのときに「上流工程経験あり」として説明できる実績になる。
コーディングが自動化される時代において、「コードを書けるだけ」のエンジニアへの需要が縮小していることはデータが示している。エンジニアファクトリー6,813件の分析では、コーディング中心案件が1年で24.8%→13.5%にほぼ半減した。
ただし、これは「SESエンジニアが終わる」という話ではない。同じデータで、インフラ案件は37.5%→50.9%に拡大し、AI案件は88件→184件（2倍超）に増えている。変化の方向性は「コーディングから設計・AI活用へ」であり、その方向に動けるエンジニアへの需要は拡大している。
Claude Code開発者のBoris Chernyが述べた通り、コーディングは「実質的に解決された課題」になりつつある。次の主戦場は「何を作るかを決める仕様書作成」と「誰のために作るかを理解するユーザー対話」にある。これはSESエンジニアが顧客との接点を持ち、現場のドメイン知識を蓄積してきた強みと重なる。
上流設計・AI活用・ドメイン知識の3軸を持つエンジニアへの需要は今後も拡大する。まず自分が今どのポジションにいるかを正確に把握することが、次の一手を決める出発点になる。
詳しくはあわせて読みたい記事も参照してほしい。
