「AIにコードを書かせる時代になった」という話を聞くたびに、正直、複雑な気持ちになっていました。SIerとして設計・構築の仕事をしながら、「自分の仕事は今後どうなるのか」という問いが、じわじわと大きくなっている。
私は30歳、SIer勤務で、妻と1歳の子供との3人暮らしです。2026年に入ってから、Claude CodeとOpenAIのCodexという2つのAIツールが急速に進化し、「設計・構築エンジニアの仕事に何かが変わり始めている」という感覚を、以前より強く持つようになりました。
この記事では、2026年5月時点の両ツールの状況を整理した上で、SIerの設計・構築業務がどう変わりつつあるかを、自分なりに考えたことをまとめています。
- Claude CodeとCodexの2026年時点での主な違い
- SIerの設計・構築エンジニアに起きている変化
- 価値が下がりそうな仕事・上がりそうな仕事
- AIを「脅威」でなく「武器」にするための考え方
- 今から自分が取り組もうとしていること
「AIに詳しい人」が書いた記事ではなく、「同じように不安と可能性を感じているエンジニアの一人」として書いています。
Claude CodeとCodexを2026年5月時点で整理する
まず両ツールを簡単に整理しておきます。混同されがちですが、出自も設計思想も異なります。
Claude Code（Anthropic）
Claude CodeはAnthropicが提供するAIコーディングアシスタントで、CLIベースでローカル環境のコードと対話しながら作業を進めます。2026年3〜4月の5週間でv2.1.69からv2.1.101まで30本以上のアップデートが連続リリースされており、進化のペースは週6本という異例の速さです。
2026年4月に追加された注目機能の一つが、「Subagent @mention」です。メインセッションから特定タスクをサブエージェントに委任し、複数ファイルの同時編集やリサーチとコーディングの並行実行が可能になりました。また4月30日にはClaude Securityがpublic betaとして公開され、コードベースのスキャン・脆弱性検出・パッチ自動生成を一気通貫で行えるセキュリティ機能も加わっています。
Codex（OpenAI）
OpenAIのCodexは2025年5月に再リリースされた自律型のソフトウェアエンジニアリングエージェントで、2026年4月に「Codex for (almost) everything」と題した大型アップデートが行われました。
最大の変化はComputer Useの搭載で、Macのスクリーンを見て自律的にクリック・入力ができるようになりました。JIRA・CircleCI・GitLabなど90以上のプラグインと連携し、メモリ機能も追加されました。コアモデルもGPT-5.5に更新されています。
両者の性格の違い
一言で言うと、Claude Codeは「ローカル環境でエンジニアと並走するツール」、Codexは「タスクを渡すと自律的に完遂するエージェント」という方向性の違いがあります。どちらが優れているかではなく、用途に応じて使い分けることが現実的です。インフラやIaCを扱う場面ではClaude Codeのローカルでの対話型が使いやすく、開発プロジェクト全体のタスク管理的な使い方ではCodexが向いている場面もあるという印象を持っています。
SIerの「設計・構築エンジニア」に何が起きているか
AIツールの進化が業界全体に影響を与え始めています。SIerという立場から見ると、いくつかの変化が重なって起きていると感じます。
コーディング・テストの工程が急速に変わっている
従来のSIerの収益モデルは、「人月」でエンジニアの工数を積み上げるものでした。なかでもコーディング・テストの工程は、多くの人員を必要とする工程として機能してきました。
しかし2026年現在、AIがコードを生成しテストを実行する速度と品質が上がり続けています。業務仕様を入力すればコードの叩き台が出る、テストケースを記述すれば自動で実行される——これが現実になりつつある中で、「人が1行ずつ書く」工程の比重は、以前より確実に下がっています。
顧客側の「内製化」が加速している
もうひとつの変化が、ユーザー企業側の内製化加速です。AIコーディングツールの普及により、業務に精通したユーザー企業の担当者が「何をしたいか」を入力するだけで、SIerを通さずにシステムの草案を作れる環境が整いつつあります。
「SIerへの発注理由そのものが問い直されている」という指摘も出てきており、「人月ビジネスの前提が崩れ始めている」という感覚は、業界内でも広まってきています。
設計・要件定義工程も変わり始めている
「AIはコーディングの話で、上流工程（要件定義・設計）は人間の仕事だから大丈夫」という見方がありました。確かに今のところ、要件定義や業務設計には人間の判断が不可欠です。でも同時に、「ヒアリング内容からユーザーストーリーの草案を生成する」「データモデルの設計案を提示する」といったAI支援も始まっています。
上流工程がなくなるとは思いませんが、「今まで5人でやっていた仕事が3人でできるようになる」という変化は、すでに起きていると感じています。
価値が下がりそうな仕事・上がりそうな仕事
変化の中で、正直に考えてみました。どんな仕事が影響を受け、どんな仕事の価値が上がるのか。まだ答えは出ていませんが、今の自分の見立てを書いておきます。
価値が下がりやすいと感じる仕事
- 仕様書が決まっていれば誰でも書けるコーディング作業
- パターン化された単体テスト・結合テストの実施
- 既存システムの設定ファイル変更など、定型的な構築作業
- 過去案件の流用で対応できる設計ドキュメントの作成
これらは「AIに代替されやすい」というより、「同じアウトプットをAIの補助で以前の半分の工数で出せるようになる」という方向で変化が起きていると感じています。
価値が上がりそうな仕事
- システム全体のアーキテクチャを戦略的に設計する能力
- 顧客のビジネスと技術をつなぐドメイン知識
- AIが生成したコードや設計を正確にレビューできる目
- 複数のAIツールを組み合わせて業務フローを設計する「AIオーケストレーション」スキル
- 顧客の変革を推進するリーダーシップとコミュニケーション
要するに「AIに任せられる部分を任せながら、AIが判断できない部分で価値を出す」というポジションへの移行が求められている気がします。それは「AIを使いこなせる上流エンジニア」への変化とも言い換えられます。
セキュリティ・監査は人間の責任が残る
Claude SecurityのようなAIセキュリティツールが出てきても、「最終的にこのシステムをリリースする判断」「コンプライアンス上の責任」は人間に残ります。AIが脆弱性を検出し修正案を出しても、その修正を本番に入れてよいかの判断は、エンジニアやPMが行う必要があります。セキュリティや監査の領域では、むしろ「AIの出力を適切に評価できる人材」の重要性が高まると思っています。
AIを「脅威」ではなく「武器」にするための考え方
「AIに仕事を奪われる」という見方と、「AIで自分の仕事を拡張できる」という見方があります。どちらが現実に近いかは、個人の行動次第で変わると思っています。
「AIが何を得意とするか」を理解することが前提
Claude CodeもCodexも、万能ではありません。「渡された仕様の範囲内で、高速かつ網羅的に実装する」ことは得意ですが、「そもそもこの仕様で顧客の課題が解決するか」「アーキテクチャとして5年後も通用するか」といった判断は、まだ人間に委ねられています。
AIツールの得意・不得意を理解した上で使うことが、「使いこなす」ための出発点です。「すごそうだけど何ができるか分からない」という状態のまま放置しているのが、一番もったいないと思っています。
「AIが書いたコードをレビューできる」ことは依然として重要
AIが生成したコードが常に正しいわけではありません。動くように見えて、セキュリティホールがある。テストは通っているが、本番の負荷に耐えられない設計になっている。そういった問題を見抜くためには、「コードを読んで理解できる」基礎力が必要です。
「AIが書くからコードは書かなくていい」という方向に振り切るのは、今の時点では危険だと思っています。自分でも書けるが、AIに書かせてレビューする——この両方ができる状態が、今のエンジニアとしての現実的なポジションだと感じています。
「副業・個人プロジェクトで使い倒す」ことが最速の学習
会社の業務でAIツールを使う機会は、セキュリティポリシーや承認フローの問題で制限されることが多い。でも個人のブログ運営や副業プロジェクトなら、自分の判断で使い始められます。
「業務に活かすためにまず個人で試す」という順番は、新しい技術を身につける際の現実的なルートです。Claude CodeをCLI版でローカルに入れて、ブログのカスタマイズや学習用スクリプトで試してみることから始めると、「業務でどう活かせるか」のイメージが具体的になります。
今から私が取り組もうとしていること
「AIで仕事が変わる」という漠然とした不安を、「では自分は何をするか」という具体的な行動に変えるために、今考えていることを書いておきます。まだ計画段階のものも含めて、正直に。
Claude Code CLIをまず個人環境に入れる
まずは使ってみないことには何も分かりません。Claude Code CLIは個人でも導入できます。このブログの記事執筆補助や、Terraformコードの学習、Ansibleのplaybook作成など、業務とは独立した個人プロジェクトで試してみることを最初の一歩にしようとしています。
「AIの出力をレビューする練習」を意識的にする
AIが書いたコードを「なんとなく使う」のではなく、「なぜこう書いているか理解した上で使う」練習をしたい。そのためには、AIに書かせながらも自分で同じものを書いてみて、差分を確認する、という地道な学習が有効だと思っています。
アーキテクチャ・上流設計のスキルを意識的に積む
「AIが代替しにくい仕事」の代表格がアーキテクチャ設計と上流の業務分析です。これはすぐに身につくものではなく、日々の業務の中で「なぜこの設計を選んだか」「別の選択肢のトレードオフは何か」を考え続けることで積み上がっていくものだと思っています。
業務の中でそういった問いを意識的に立てる習慣を持つことと、並行してAIツールの使い方を覚えていく。その両方が今の自分には必要だと感じています。
変化の過程をこのブログで記録する
「AIを使い始めた結果、何が変わって、何が変わらなかったか」をこのブログで記録していくことが、自分にとってもブログ読者にとっても価値になると思っています。成功談だけでなく、「うまくいかなかった」「こういう使い方は向いていなかった」という記録も含めて残すつもりです。
まとめ：変化の中で「自分のポジション」を作る
この記事では、2026年5月時点のClaude CodeとCodexの状況を整理した上で、SIerの設計・構築エンジニアとして感じている変化と、それに対する自分の考えをまとめました。
要点を整理すると、以下の通りです。
- Claude Codeは2026年4月にSubagent機能・Claude Securityを追加。Codexは「Computer Use」を搭載し、PCを自律操作するエージェントに進化
- SIerのコーディング・テスト工程はAIによる効率化と内製化加速の「ダブルインパクト」を受けている
- アーキテクチャ設計・ドメイン知識・AIオーケストレーション・セキュリティレビューは価値が上がりやすい領域
- 「AIが書いたコードをレビューできる」基礎力は依然として重要
- 会社の業務での制約を超えるために、個人環境でAIツールを試す経験が早期学習につながる
「今日から取れる小さな一歩」として、まずClaude Code CLIをインストールして手元の何か一つのプロジェクトで試してみることをすすめます。完璧に使いこなそうとしなくていい。「このツールが何を得意としているか」を体感することが、今の時点では一番価値のある投資だと思っています。
「AIが怖い」から「AIを武器にできる」へ。その変化は、知識よりも実際に手を動かした経験から生まれると、今は思っています。
コメント