クライアントワークで培った力が、AI時代に生きる理由

「AIが書いたコードを、まだ読んでいますか。それとも、受け入れて祈るだけですか」――。

X上のこんな問いかけに、『Clean Code』などの著書で知られるソフトウェアエンジニアのRobert C. Martin（通称Uncle Bob）氏は、「どちらでもない」と答えました。コーディングエージェントの急速な進化によって、少し前までの開発の常識が変わりつつあります。

本連載では、株式会社本田技術研究所や株式会社ディー・エヌ・エー（DeNA）を経て、現在はフューチャーアーキテクト株式会社でシニアアーキテクトを務める渋川 よしきさん（@shibu_jp）に、SE・ITコンサルタントが直面しやすいキャリアの悩みについて解説いただきます（全6回予定、過去記事はこちら）。

第5回のテーマは「AIに任せる時代の、エンジニアの役割」。第3回では、AI時代にも価値を持ち続ける知識として「ドメイン知識」を取り上げました。今回は、AIと共に開発する中で、エンジニアの働き方がどう変わるのかに目を向けます。

コードを書く時代から、技術を選ぶ時代へ

ChatGPTのような対話型のAIや、Claude CodeやCodexのようなコーディングエージェントが登場し、「もうそれがない時代には戻れない」という人もいると思います。

一方で、長いプロジェクトの途中で従来のやり方を継続しており、まだAIを本格的には使えていない人もいるかもしれません。いずれにしても、まったくAIがなかった時代に戻ることはないでしょう。

AIがコードを書いてくれるようになると、「これまで積み上げてきたスキルの価値が下がってしまうのでは」などと不安に感じる人もいるのではないでしょうか。

しかし、コードを書く作業はAIに任せられても、どんな技術を使い、何をつくるかを決めるのは人間の仕事です。むしろ、そうした判断の重要性は増していくでしょう。エンジニアに求められるスキルは、なくなるのではなく中身が変わっていくといえます。

今回は、AI時代にどんな技術やスキルが求められるようになるのか、そしてSEやITコンサルで積んできた経験がどう生きるのかを考えてみます。

AIエージェントの急速な進化

ChatGPTが広まり始めた2022年頃、AIの業務利用で話題になったのはハルシネーションをいかに抑えるか、ということでした。その対策として、温度（temperature）やtop-p / top-kといった、回答のばらつきを調整するパラメータをどう設定するかが盛んに議論されたものです。しかし、AIの性能自体が向上した今、そうした話題を目にする機会は減りました。

2025年頃からコーディングエージェントを多くの人が触り始めると、「コーディング標準をいかに守らせるか」「テストコードをどのように書かせるか」「生成されたコードをどうレビューするか」といったことが話題になりました。しかし今では、こうした工夫も、議論されることは少なくなりました。

当初のチャットAIは入力されたコンテキスト情報のみから推測し、コードや回答を生成するものでした。しかし、現在のコーディングエージェントはウェブで最新情報を取得し、指示しなくてもテストを書き、動作を確認したうえで、動くものをほぼ確実に仕上げてくるようになりました。わずか数年、場合によっては1年ほど前の常識が、既に過去のものになりつつあるのです。

ボトルネックは「世界観をAIに伝えられるか」へ

「AIが書いたコードをまだ読んでいるか、それとも受け入れて祈るだけか」というX上の投稿に対し、Robert C. Martin氏は「どちらでもない」としたうえで、「私はAIが生成したコードを読まない。そして、祈る必要がないほど徹底的にテストし、制約をかけている」と返信しました。

また、米Thoughtworks CTOのRachel Laycock氏も、自身の連載コラムで「すべてのコードを人間がレビューするのではなく、アーキテクチャの根本的な変更など、経験豊富な人の目が必要な例外的なものに絞るべきではないか」という趣旨を述べています。

さらに、OpenAIでCodexを担当するEric Provencher氏は、新モデルの登場に合わせて「以前は役立った細かすぎる指示が、今はかえって結果を妨げることがある」と、指示の見直しをXへの投稿で呼びかけています。Anthropicも、Claude Codeの公式ドキュメントで「ステップではなく結果を説明する」ことを勧めています。どうつくるか（How）を細かく指示するより、何をつくりたいのか（What）を伝えてAIに任せたほうがいいというわけです。

かつて議論されていた「テストを書かせる」「コードの品質を維持させる」といったHowは、今ではAIが判断して実行してくれます。人間がそこまで細かく指示することは、むしろ「やるべきではないこと」になっているのです。

いまだに新しいモデルが出ると「ちょっとの指示で既存のゲームのクローンができた」と話題になることがありますが、それ自体にはあまり意味がありません。なぜなら、システムを開発する目的は、今までにないものをつくって仕事の仕方を変えることだからです。

既存のものを1行の指示で再現できても、クライアントワークでお客さまのシステムをつくる私たちにとっては大きな価値ではありません。裏を返せば、正しいシステムをつくるうえでの最大のボトルネックは、「システムの世界観を正しくAIに伝えられるか」に変わったということです。

AIが賢くなっても「できないこと」はある

どんなにAIが賢くなっても、コンピュータサイエンスや物理法則の限界を超えるソフトウェアをつくることはできません。例えば、JPEG画像のように圧縮の過程で情報の一部を捨てたlossyなデータから、元の完全なデータを復元することはできません。

また、受け取ったリクエストのパケットだけから送信者を特定するには、プロバイダーなどの協力がないと不可能です。さらに、光ファイバーの中では光の速さが真空中と比べて落ちるため、データが地球を一周するだけで少なくとも約200ms（0.2秒）かかります。

AIに任せるにしても、こうした「どうやってもできないこと」は知っておく必要があります。

AIに間違った前提を渡さないために

ソフトウェアにもいろいろなアーキテクチャの選択肢があり、それぞれメリットやデメリットがあります。例えば、データの保存先であるストレージだけでも、たくさんの種類があります。ブームなどもありますが、用途ごとにどれが適しているかは、おおよそ絞られます。

• データを保存・管理する：RDB、NoSQL、NewSQL
• ファイルや分析用データを蓄積する：オブジェクトストレージ、データウェアハウス
• 速く届ける・探す：キャッシュストレージ、CDN、検索エンジン、ベクトルデータベース
• その他：シークレットマネージャ、メッセージキュー

こうした選択肢から何を選ぶかについても、ある程度「こうなるべき」というセンスは必要です。細かいコードのレビューは不要になっても、アーキテクチャや技術選定の良し悪しの判断まで不要になるのは、だいぶ先でしょう。AIがつくってくれるからといって、コストがかさんだり、性能が落ちたり、無駄なものができたりしても構わない、とはならないからです。

AIは最初の指示が間違っていても、その前提の中でベストを尽くそうとします。例えば、整合性が大切なシステムで「結果整合性（Eventual Consistency）でいい」と指示して、トランザクション機能が弱いストレージを使ってしまうと、AIはそれを補うための大量のコードをつくるはずです。そうしたコードは、RDBを使っていればそもそも不要なものです。

ストレージ以外にも、アプリケーション、その実行基盤、フロントエンドなど、様々な領域で同じことが起こり得ます。

以前と比べ、SQLを正確に手で書けるかといったスキルの必要性は、AIの登場によって減っていると思います。一方で、多くの技術を知り、正しく技術選定を行ってアーキテクチャを考え、AIに間違った指示をしないというスキルは、これからも必要とされ続けるでしょう。

正しい指示をするためには、まずは選択肢を知る必要があります。歴史があって生き残ってきたものは、出発点となります。特に大規模なシステムや高い性能を支えてきたものを学び、その後新しいものを触ってみるとよいでしょう。

そして、選択肢が増えてきたときに、それぞれの何が良くて、どのような欠点があるかをきちんと考えていくことが大切です。現行システムがつくられたときの背景を考えながら、今つくり直すならどのような選択肢がベストなのかを議論する。そういった普段の仕事の中にも、よいセンスを身に付けるチャンスは転がっているでしょう。

一人ひとりに求められる、プロダクトオーナーやスクラムマスターの視点

今までは開発者であれば「コード作成」に多くの時間を割いてきました。しかし、実際のコーディング作業をAIが担うようになると、それを指示するのが仕事になります。言い換えれば、開発者自身にも、何をつくるかを考えるプロダクトオーナーや、チームが円滑に動けるよう整えるスクラムマスターのような視点が求められるようになるのです。

具体的には、「一人ソフトウェア開発チーム」のマネージャーとなり、各エージェントにタスクを割り振り、その結果を確認して統合していくのが開発の仕事になるでしょう。タスクの依存関係を考えて割り振ることも必要になりますし、エージェントのコスト（残りトークン数）を考えてタスクの難易度を調整して渡すことも必要になるかもしれません。

AIに要件を効率よく渡せるかどうかが最終的な開発効率を左右します。そのため、時間がかかりそうな要件定義はステークホルダーと調整して先に進めておいたり、うまくプロトタイプをつくって議論をコントロールしたりといった対人調整も必要になるでしょう。

今までは工数の都合上チームで分担していたような活動を、一人で担うことも増えていくので、こういったスキルを身に付けていく必要があるといえます。

第2回ではマネジメントスキルについて書きましたが、人のマネジメントには苦手意識があっても、AIエージェントのマネジメントは楽しいという人もいるはずです。「マネージャーとエキスパート、どちらの道に進むか」と悩んでいる人にとっては、新しい選択肢の一つになり得ます。自分の知らなかった能力に気づく人も出てくるかもしれません。第3回で紹介したドメイン知識の学習も、こういった活動を効率よく行うための前提条件になっていくでしょう。

現場で積み重ねた経験は、AI時代にこそ生きる

ここまで、AI時代に求められる技術やスキルについて書いてきました。AIがコードを書くようになり、エンジニアの仕事の中心は、技術を正しく選び、何をつくりたいのか（What）となぜ必要なのか（Why）を伝えながら、AIエージェントを率いていくことへ移りつつあります。

プログラマーとして仕事をしている人には大きな変化かもしれませんが、SEやITコンサルタントとして要件を整理し、技術を選定し、関係者と調整してきた人からすると、仕事の内容はそれほど変わらないと感じるかもしれません。むしろ、そうして現場で積み重ねてきた経験こそが、AI時代に生きてくるはずです。

もちろん、個人でできることが大幅に増えるので、今までは予算がなくてできなかったようなことも、いろいろできるようになります。今はとにかく、「変化を楽しむ」のがいいでしょう。

渋川さんが翻訳を担当した『C4モデル ―ソフトウェアアーキテクチャを可視化するジェネリックでシンプルな図解のテクニック』（オライリー・ジャパン）が、12月2日に発売予定です。著者のSimon Brown氏は、11月26～27日開催の「アーキテクチャConference 2026」に登壇予定です。

これまでの経験がどう生きるか、キャリアのプロと話して確かめてみませんか

記事にもあったように、AIと協働する時代には、エンジニアの働き方が大きく変わっていきます。一方で、自分にとっては当たり前に積み上げてきたスキルや経験の中にこそ、これからの時代に企業から求められるものもあるかもしれません。

Findyの「ユーザーサクセス面談」では、転職の具体的な相談だけでなく、年次・職種ごとのキャリア傾向や、エンジニア転職市場のトレンド、現在のスキルでの想定年収といった情報も知ることができます。

転職するかどうかの結論を急ぐ必要はありません。まずは一度、今とこれからのキャリアについて整理してみませんか。