AI時代のエンジニアに必要なパラダイムシフト－自己否定の先にあるもの

小西秀和です。
私はこれまで、設計に多くの時間をかけて熟考し、コードの品質にこだわり、それらを支える技術的な知識を深く積み上げることに情熱を燃やしてきました。そして、AWSの全認定資格を取得し、Japan AWS Top Engineerにも選出していただきました。知識と技術の蓄積こそが自分の価値だと信じていました。しかし、つい最近、その価値観を自己否定することにしました。

この記事では、AI時代にエンジニアが何に価値を置くべきか、何を手放し何を磨くべきかについて、私自身の経験と考察をまとめています。これは特定の誰かに向けた教訓めいた話ではなく、私自身が直面したパラダイムシフトの記録です。同じような葛藤を抱えているエンジニアの方にとって、何かしらの参考になれば幸いです。

1. 価値を失いつつあるもの－「知っている」ことの意味が変わる

「知っている」こと自体の価値が、急速に薄れてきていると感じています。

フレームワークの使い方を知っている
設計パターンを知っている
特定言語に精通している
ベストプラクティスをドキュメント化できる

これらはすべて、AIが即座に再現できるようになりました。知識の蓄積量で勝負する時代は、終わりに近づいているのではないでしょうか。

なぜそう考えるようになったのか

10年前頃、Stack Overflowの回答を暗記している人が重宝された時代がありました。その後、ChatGPTが登場する数年前までは「ググれば分かることを覚える意味はない」という感覚が一般的になっていきました。そして今、AIはググるどころか、質問の意図を理解し、コンテキストに合った回答をコードごと生成してくれます。

具体的に振り返ってみます。

設計・アーキテクチャの知識：「このAPIはRESTよりGraphQLで設計すべきです」「この処理はサーバーサイドに寄せるべきです」と判断できることに、かつては大きな価値がありました。しかし今では、AIに要件を伝えれば、適切なアーキテクチャを選択した上で実装まで完了してくれます。設計の引き出しを多く持っていること自体の価値は、以前とは比べものにならないほど小さくなっています。

言語・フレームワークへの精通 ：「Pythonのasyncioの挙動を深く理解している」「Reactのレンダリングサイクルを完全に把握している」。こうした知識はAIが広範に持っています。しかも、人間が一つずつドキュメントを読んで覚えるより遥かに速く、関連情報を横断的に引き出せます。

ビッグテックのCEOたちの発言

これは私個人の感想だけではありません。ビッグテックのCEOたちが次々と「AIがコードの大部分を書く時代が来ている」と公言しています。Google CEOのSundar Pichaiは2024年10月の決算報告で、Googleの新規コードの25%以上がAI生成であると発言しました(※1)。MetaのMark Zuckerbergは2025年1月、「2025年中にミッドレベルエンジニアの仕事をAIが代替し始める」と予測しました(※2)。Anthropic CEOのDario Amodeiは2025年3月に「3〜6ヶ月以内にAIがコードの90%を書くようになる」と予測し(※3)、同年10月にはAnthropic社内でそれが実現していると述べました(※4)。

これは未来の話ではなく、ここ数年の動きを踏まえれば、すでに現実として進んできたことだと受け止めています。

［出典］

私自身が陥った思考パターン

私自身が陥った思考パターンを正直に書きます。それは 「自分の方がうまく書ける、だから自分で書くべきだ」 という思考です。

AWSの全認定資格を取得し、6年連続でTop Engineerに選出されてきた自分にとって、「知識の蓄積量が自分の価値だ」という信念は非常に強固なものでした。「AIが書くコードは平凡だ。自分ならもっと洗練されたコードを書ける」。AIの登場初期に感じていたこの感覚は、おそらく間違っていなかったと思います。しかし、「自分の方がうまく書ける」という事実があっても、そのことがそのまま「だから自分で書くべきだ」という結論にはつながりません。

丁寧に磨き上げたコードを1時間かけて書く代わりに、AIに30秒で書かせてレビューと改善に集中する。浮いた時間で次の課題にも取り組める。結果として、同じ時間でのアウトプットの質も量も格段に高くなると実感しています。この気づきが、私にとっては大きな転換点でした。

2. 価値が残る、あるいは増していくもの

では、価値が薄れていくものがある中で、何が残るのか。私はこれを、単なるスキルの入れ替えではなく、エンジニアの価値の定義そのものが変わるパラダイムシフトだと考えています。

	従来のパラダイム	新しいパラダイム
価値の源泉	技術力（書く・知る・解く）	課題設定力・判断力・実行力（定義する・見抜く・届ける）
エンジニアの役割	手を動かす職人	AIを指揮して実現する人
評価の尺度	どれだけ良いコードを書けるか	どれだけ大きな課題を解決できるか

従来の延長線上にはこの転換はありません。だからこそ「自己否定」が必要になるのだと、私は感じています。

では、新しいパラダイムにおいて価値が増していくものは何か。私なりに整理すると、大きく3つの力に集約されます。

課題設定力 ：何を作るべきかを定義する力
判断力 ：AIの出力の良し悪しを見抜く力
実行力 ：実現してユーザーに届けきる力

それぞれ詳しく書いていきます。

2-1. 課題設定力－問いを立てる力

AIは「これを作って」と言えば作ってくれます。しかし 「何を作るべきか」は、AIには決められません。

この事業の本当の課題は何か
ユーザーが本当に困っていることは何か
技術的に可能なことのうち、今やる意味があるのはどれか

これは現場を知り、人と話し、判断する人間にしかできないことです。そしてこの問いの質が、AIの出力の質を決定します。

なぜ「問い」がこれほど重要なのか

AIの出力品質は、入力の品質に完全に依存します。同じ機能を作るにしても、以下の二つの指示では結果が全く異なります。

指示A ：「ユーザー管理画面を作って」

指示B ：「月間アクティブユーザー5000人規模のSaaSで、カスタマーサクセスチームが解約リスクの高いユーザーを素早く特定するためのダッシュボードを作って。直近30日のログイン頻度、主要機能の利用率、サポート問い合わせ回数をもとにヘルススコアを算出し、スコアが低い順にソートして表示する」

指示Bを出せる人は、事業を理解し、ユーザーの課題を把握し、何が本質的に必要かを判断しています。この「課題設定力」は、技術知識とは全く別の能力であり、AIには代替できないものだと感じています。

課題設定力を高めるために

私自身が意識していることを挙げてみます。

ドメイン知識の深さ ：事業領域を深く理解していなければ、本質的な問いは立てられません
ユーザーとの接点 ：実際のユーザーの声、行動、不満を知っていること
技術的な実現可能性の感覚 ：何ができて何ができないかを大まかに把握していること（詳細はAIが埋めてくれます）
課題の構造化能力 ：漠然とした問題を、解決可能な単位に分解する力

2-2. 判断力－ AIの出力の良し悪しを見抜く目

AIは100点の出力も出せば、一見もっともらしいが致命的に間違った出力も出します。これは性能の問題というより、AIモデルの本質に由来する性質だと考えています。AIモデルは突き詰めれば「データから確率分布を推定する統計的機械」であり、確率的にもっともらしい出力を返すよう設計されています。「正しさ」を保証する仕組みがAI自身の内部にあるわけではないため、もっともらしい誤りは構造的に避けられないものだと捉えています。

だからこそ、その差を見抜く目が必要になります。そしてこの目は、むしろ従来のエンジニア経験があるからこそ持てるものだと思います。

人間が観察し、AIに問う

スケーラビリティやセキュリティの検証、エッジケースの洗い出し、パフォーマンス分析。これらはAIに聞けば高い精度で答えてくれます。しかし、何を確認すべきかに気づくのは人間の役割です。

本番環境で過去に起きた障害のパターンを知っているからこそ、「この設計で同じ問題が起きないか？」とAIに問える
ユーザーの実際の使い方を観察してきたからこそ、「この画面遷移は本当に自然か？」という違和感に気づける
ステークホルダーとの会話から感じた温度感があるからこそ、「この仕様で本当に合意が取れるか？」と立ち止まれる

過去のプロジェクトで痛い目に遭った経験、ユーザーの行動を観察してきた知見。こうした蓄積があるからこそ、AIに対して正しい問いを立てられるのではないでしょうか。

判断力の活かし方

ここで大切なのは、判断力の使いどころです。判断力はレビューと方向修正に使うものであって、自分の手を動かす理由にしてしまうと、かえって生産性が下がってしまいます。

映画監督は自ら演技をしません。しかしその判断力がなければ、映画は成り立ちません。エンジニアの判断力も同じだと思うのです。AIの出力に不満を感じたとき、自分で書き直すのではなく、方向修正のフィードバックとしてAIに返す。その繰り返しの中でこそ、判断力は最大限に活きるのではないでしょうか。

ただし、これは絶対的なルールというわけではありません。実務上、自分で手を動かした方が合理的な場面もあります。例えば、リスクが小さく確実に直せる軽微な修正、AI利用量の上限に達してコストを抑制したい状況、AI側で障害が発生してどうしても自分で実装しなければならないとき、などです。原則として「判断力はレビューと方向修正に使う」を置きつつも、状況に応じて柔軟に判断するのが現実的だと感じています。

2-3. 実行力－実現してユーザーに届けきる力

コードが書けること自体の価値は変わりつつありますが、実際にサービスとして動かし、ユーザーの手に届けるところは依然として泥臭く、人間の仕事です。

インフラを構成し、運用する
ステークホルダーと合意を形成する
障害時に判断して対応する
ユーザーのフィードバックを受けて方向転換する

ここには人間の意思と感情が伴います。AIを最大限に活用する前提であっても、人間にしか担えない実行力があります。

実行力の具体的な中身

粘り強くやり抜く力

うまくいかない状況でも諦めず、AIを活用しながら試行錯誤を繰り返し、成果が出るまで挑戦し続ける
想定外の障害や仕様変更に直面しても、柔軟に方向転換しながら前に進み続ける
「もう少しで届く」という最後の一歩を、泥臭くやりきる

人の感情を汲み取る力

ステークホルダーの曖昧な不満や言語化されていない期待を読み取り、本当に求めているものを引き出す
ステークホルダー間の利害や温度差を察知し、合意形成を導く
チームメンバーのモチベーションや不安を感じ取り、適切に関わる

責任を引き受ける力

不確実な状況でも「これでいく」と決断し、その結果に責任を持つ
誰かが決めなければ進まない局面で、最終判断を引き受ける覚悟

AIはあらゆる技術的な作業を支援できますが、ステークホルダーの隠れた要求を察し、チームの士気を高めながら、成果が出るまで粘り強く走り続ける。こうしたことは人間にしかできません。

3. 自己否定について－なぜ私にはこれが必要だったのか

「自己否定」という言葉に込めた意味－ Self-Disruptionとして

ここで一度、タイトルにも使った「自己否定」という言葉について、私がどのような意味で使っているのかを整理しておきたいと思います。

「自己否定」はやや過激に響く言葉かもしれません。しかし、私が本当に伝えたいのは、英語で言うところの "Self-Disruption" です。Self-Disruptionは、ビジネス戦略の文脈で使われる概念で、競合や市場に破壊される前に、自らの既存の成功モデルを能動的に壊しにいくことを指します。代表例として、NetflixがDVD郵送事業を自ら捨ててストリーミングに全振りした事例や、Appleが絶好調のiPodを自ら潰してiPhoneを生み出した事例が知られています。

では、なぜ「自己破壊」や「自己変革」ではなく「自己否定」という言葉を選んだのか。「自己破壊」は物理的・全否定的すぎて再生を含意しにくく、「自己変革」は柔らかすぎて「少し変える」程度にも聞こえてしまいます。私がこの言葉に込めたかったのは、これまで信じてきた価値観をはっきり否定するほどの強さです。だからこそ、あえて「自己否定」という強い言葉を選びました。

ここで言う自己否定は、立ち止まることではなく、能動的に自らを更新することを意味しています。この前提のもとで、以降を読み進めていただけたらと思います。

なぜ私にはこれが必要だったのか

ここまで読んで、違和感や抵抗感を覚えた方もいらっしゃるかもしれません。私自身がまさにそうでした。第1章で書いた「自分の方がうまく書ける、だから自分で書くべきだ」という思考パターンは、まさに私が長年かけて積み上げてきたスキルへの執着から生まれたものです。そのため、「自分が何年もかけて積み上げてきたスキルの価値が変わる」ということを、素直に受け入れるのは簡単ではありませんでした。

だからこそ、私は自分に対して「自己否定」という強い言葉を使う必要がありました。

私が否定したもの

「自分の手で書いたコードに価値がある」という信念 ：コードの価値は、誰が書いたかではなく、何を解決するかで決まります。AIが書いても人間が書いても、ユーザーの課題を解決するなら同じ価値があるはずです。
「深い技術知識を持っていることが優秀さの証明」という評価軸 ：知識はAIが持っています。優秀さの新しい尺度は、AIを活用して成果を出せるかどうかに移りつつあるのではないでしょうか。
「AIより自分の方がうまく書ける」という判断で手を動かしてしまう習慣 ：これが最も手放しにくいものでした。判断力があるからこそAIの出力に不満を感じ、自分で書き直してしまう。しかしそれは、方向修正のフィードバックとしてAIに返すべきものを自分の手で処理していたのだと、今は思っています。

否定しなくてよかったもの

一方で、手放す必要がなかったものもあります。前章で述べた課題設定力・判断力・実行力は、むしろ価値が高まっています。

ただし、使い方は変わりました。AWSの全認定資格を取得する過程で培った幅広い技術知識は、自分でコードを書くためではなく、複数の領域を横断してAIの出力を統合的にレビューし方向修正するために使うものへと変化しています。知識そのものを否定したのではなく、知識の活かし方を再定義したということかもしれません。

判断力を育てる道は、AWS認定だけではない

これに関連して、もう一つ書いておきたいことがあります。AIの出力を判断する力は、AWS認定以外の道でも十分に身につけられるということです。

実務経験、特に過去のプロジェクトでの障害対応
他社事例や設計レビューの蓄積
公式ドキュメントの精読、コミュニティでの議論への参加
OSSのコードリーディングやアーキテクチャ解説の読み込み

これらはどれも、判断力の土台を作る道です。大切なのは資格の有無ではなく、自分に合ったパスで判断力を鍛えることではないでしょうか。

私自身がAWS認定をどう位置づけているか

AWSの全認定資格を取得し、Top Engineerに6年連続で選出されてきた私として、AWS認定について自分の中での位置づけが大きく変わったことも記しておきます。

今の私にとってAWS認定は、「AIが出してくるAWS関連の出力を判断する力を養うための、有料で効率的な学習パス」です。スコープが体系化されており、合格ラインが明確で、短期集中で学べるよう設計されている。判断力を鍛える一つの手段として、いまでも有用だと思います。

しかし、それは目的ではなく手段です。だから、かつての私のように「エンジニアたるもの資格は取るべき」という立場を、私はもう取りません。自分に合ったパスを選べばそれでよい、という立場に変わりました。資格を積み上げてきた自分自身の経験を否定するのではなく、その経験を踏まえてなお、こう言い切れるようになったことが、私にとってのもう一つの自己否定の到達点でもあります。

自己否定は一度では終わらない

私が実感しているのは、自己否定は一回きりのイベントではないということです。AIの能力は日々進化しています。今日「これはまだ人間がやるべきだ」と思っていることが、半年後にはAIが完璧にこなせるようになっているかもしれません。

だからこそ、「自分にしかできない仕事は何か」を問い続けることが大切なのだと思います。自己否定とは、一度古い価値観を捨てることではなく、常に自分の価値を問い直し続ける姿勢そのものなのかもしれません。

4. ローカルAIエージェントとの出会い－私の自己否定を引き起こした触媒

ここまで、自己否定について抽象度の高い書き方をしてきました。しかし、実はこれには非常に具体的な触媒がありました。ローカルAIエージェント、なかでもClaude Codeの登場です。ローカルAIエージェントが何をできるのかを目の当たりにしなければ、前章で書いたレベルでの自己否定にはおそらく至らなかったと思います。そこで本章では、抽象的な物語からいったん離れ、その技術そのものに正面から向き合ってみます。

Claude Codeは2025年2月24日にClaude 3.7 Sonnetと同時にResearch Previewとして登場し、2025年5月22日にClaude 4の発表とともにGA（一般提供）が開始されました。コードベースを読み解き、設計・実装・検証までを自律的に行うその振る舞いは、私が握りしめていた「自分の方がうまく書ける」という前提を根本から崩しました。本章で本当にお伝えしたいのはこのことです。

4-1. オンラインAIエージェントとローカルAIエージェント

生成AIサービスの分類軸はさまざまありますが、動作する場所で大別すると大きく二つに分かれます。

オンラインAIエージェント ：ブラウザやチャット画面越しに使用するタイプです。Anthropic Claude（Web版）、OpenAI ChatGPT、Microsoft 365 Copilotなどが代表例です。手軽に使える一方で、手元のデータを直接扱うには制約があります。
ローカルAIエージェント ：ローカル端末（PC）上で動作し、ファイルシステムに直接アクセスできるタイプです。Anthropic Claude Code（コーディング中心）、OpenAI Codex（コーディング中心）、Anthropic Claude Cowork（一般事務中心）などが該当し、新しいプロダクトも続々と登場しています。

ローカルAIエージェントの最大の特徴は、PC内のファイルシステムに直接アクセスできることです。この一点の違いが、AIに任せられる仕事の幅を劇的に広げます。

4-2. ローカルAIエージェントが私に自己否定を迫った理由

ローカルAIエージェントの本質的な強みは、実行環境ごと巻き込める自律性にあると私は考えています。

ファイルシステム＋コマンド実行環境への直接アクセス ：ファイルの読み書き、コマンド実行、テスト実行などを、エージェント自身が自律的に行います。
コードベース全体・プロジェクト固有の文脈を取り込める ：リポジトリ構造、設定ファイル、CLAUDE.mdのようなプロジェクト固有指示までまるごとコンテキストに取り込みます。
自分の出力を実行して検証し、反復・自己修正できる ：「書く → 動かす → 失敗を見て直す」というループを、人間が介さずに回せます。

つまり、ローカルAIエージェントは「それらしいコードを書く」ところで止まらず、自分でその結果を検証して磨き上げるのです。これを目の当たりにした瞬間、「自分の方がうまく書けるから自分でやる」という論理は成り立たなくなりました。AIは単にコードを生成するだけでなく、自分の出力を自分で反復改善し、プロジェクト全体の文脈を踏まえて、動くものを届けてくる。ここで、私は自己否定と正面から向き合わざるを得なくなったのです。

4-3. 「AIで差がつく技術」の進化 — プロンプト → コンテキスト → ハーネス／エンバイロメント

AI活用において差がつく技術は、この1〜2年で進化してきました。〜2024年は「プロンプト」、2024〜2025年は「コンテキスト」と直線的に進んできましたが、ローカルAIエージェント時代に入った最新ステージでは、ハーネスエンジニアリングとエンバイロメントエンジニアリングという二つの並列なサブ領域に分岐しています。

時期	注目された技術	何が問われるか
〜2024年頃	プロンプト・エンジニアリング	どう指示を書くか
2024〜2025年頃	コンテキスト・エンジニアリング	RAG等で背景情報をどう教え込むか
今〜これから（並列の対）	ハーネスエンジニアリング	AIエージェントのランタイムをどう構成するか — permissions / hooks / MCP / ツール表面（プロセスの内側）
今〜これから（並列の対）	エンバイロメントエンジニアリング	AIエージェントが動く世界をどう囲うか — OSユーザー / サンドボックス / ネットワーク（プロセスの外側）

この最終ステージで注目される二つの技術は、いずれもAIエージェント時代に新しく必要になった概念で、同じスタックの異なる層に位置します。ハーネスエンジニアリングはエージェントランタイム自身のプロセス内の構成 — どの権限を評価し、どのフックを発火させ、どのMCPサーバを読み込み、CLAUDE.mdにどんな方針を載せるか。エンバイロメントエンジニアリングはそのランタイムが触れる世界のプロセス外の境界 — OSユーザー、ファイルシステムACL、コンテナ、ネットワークegress、バックアップ、監査基盤。エンバイロメント側については、例えばAymen Furter氏のEnvironment Engineering as Platform Engineering for AI Agentsに関する記事が参考になります。

なぜハーネス／エンバイロメントエンジニアリングなのか

AIエージェント時代には、AIエージェント自身が必要な情報を取りに行くようになります。問われるのは「何を与えるか」ではなく、「何を見に行かせ、何をさせ、何を許すか」、すなわちガードレール設計になります。そしてこのガードレールは、一層ではなく二層に分かれます。

具体的な構成要素として、ハーネス側（プロセス内）:

ツール呼び出しに対するパーミッション（allow / deny / ask）
ライフサイクル・フック（ブロック・改変・監査）
MCPサーバのスコープと個別ツールのゲーティング
プロジェクトに同梱される CLAUDE.md のアドバイザリ
承認ワークフローとプロンプトインジェクション対策

エンバイロメント側（プロセス外）:

OSユーザー分離とファイルシステムACL
コンテナ・devcontainer・VMによるサンドボックス
ネットワークegressの制御（ファイアウォール、許可ドメイン）
バックアップとディスクスナップショット
ツール呼び出し・ファイル変更を捕捉する監査パイプライン

ハーネス／エンバイロメントエンジニアリングは、ローカルAI活用の主戦場

このステージの構図を二種類のAIエージェントに重ねてみると、はっきりします。

	プロンプト	コンテキスト	ハーネス	エンバイロメント
オンラインAI	高	高（RAG）	限定的	限定的
ローカルAI	高	高	高（主戦場）	高（主戦場）

オンラインAIは与えられた画面の中で仕事をします — ハーネスもエンバイロメントも提供側に固定されており、利用者が動かせるのはプロンプトとコンテキストだけです。一方ローカルAIはユーザーの環境そのものを触ります。ハーネスもエンバイロメントもユーザー自身の設計対象になり、その両方の設計の良し悪しがローカルAI活用の上限を決めることになります。「安全性」と「利便性」を二層の両方で整えた者が、AIのメリットを最大限に享受できると感じています。

4-4. ローカルAIエージェントをまだ使ったことがない方へ

ローカルAIエージェントをまだ使ったことがない方には、ぜひ一度、自分の手で動かしてみていただきたいと思います。記事を読んだりデモを見たりするだけでは足りません。実際に自分のファイルの上で動かして初めて、視点の転換は実感に変わります。会社で使用許可がまだ下りていないなら、個人の責任のもと、自身のプロジェクトで主体的に使ってみる価値はあると個人的には考えています。

そして、何から始めればよいか分からないなら、それ自体をAIに尋ねてみるのが最初の一歩としてぴったりです。こうした小さな場面でも、第2章で述べた課題設定力・判断力・実行力が、静かに試されているのではないでしょうか。

5. どう働いていくか－私自身の行動変容

「手を動かす職人」から「AIを指揮して実現する人」へ。

抽象的な話で終わらせたくないので、私自身が実践している（あるいは実践しようとしている）ことを、具体的に書いてみます。

5-1. コードはAIに書かせて、自分は「定義」と「判断」に集中する

従来の私の働き方では、1日の大半を要件の理解や設計、コーディング、チームコミュニケーションに費やしていました。

今ではその時間の使い方が大きく変わっています。課題の定義や要件の構造化、AIへの指示と出力のレビュー、AI活用に関するチームでのコミュニケーションが中心になり、自分の手でコードを書く機会はほとんど無くなりました。かつてコーディングに充てていた時間の多くが課題の定義とAIの出力の判断に移ったことで、同じ時間でカバーできる範囲が大きく広がったと感じています。

5-2. T型ではなく面で動く

ここで言う「T型」とは、縦軸に1つの専門領域の深さを、横軸に周辺領域の広い理解を持つ人材像のことです。例えば「バックエンドに深い専門性を持ち、フロントエンドも少し分かる」というような形が典型的です。従来は、このT型のスキルセットが理想とされてきました。しかし、AIが各領域の実装を担えるようになった今、一人のエンジニアがカバーできる範囲は面的に広がるのではないかと考えています。

フロントエンド、バックエンド、インフラ、データベース設計、セキュリティ。これらすべてを自分の手で実装する必要はありませんが、すべてに対して指示を出せるだけの理解と出力を判断できるだけの経験は必要になってきます。

私自身、AWSを軸としつつもマルチクラウド、オンプレミス環境を横断して設計・構築してきた経験がありますが、AIの登場によってこの「面で動く」ことのハードルが大きく下がったと感じています。以前は各プラットフォームの仕様を自分の頭に入れておく必要がありましたが、今はAIがその知識を補完してくれます。自分が持つべきなのは、全領域の詳細な仕様知識ではなく、本質を押さえた上でAIを適切に使いこなせるだけの経験値ではないでしょうか。

これは「浅く広く」とは少し違います。各領域の本質的なポイントを押さえた上で、AIに適切な指示を出し、出力の品質を判断できる深さが求められます。言わば「判断力の幅を広げる」ということではないでしょうか。

5-3. 考え込む前に作って検証する

私はキャリアの初期にシリコンバレーでR&Dに携わりましたが、そこでの経験から得た最も大きな学びは、素早い試行錯誤（rapid iteration）に主体性、創造的思考、粘り強さ、適応力を組み合わせることで、意味ある成果を生み出すスタイルでした。この考え方は、今まで一貫して重要だと体感してきた行動指針の根幹です。

この行動指針が活きる場面は、今回が初めてではありません。IT業界では、オンプレミスからクラウドへ、モノリスからマイクロサービスへと、「従来のやり方が通用しなくなる」局面が繰り返し訪れてきました。クラウド黎明期には「クラウドに本番環境は任せられない」という抵抗感がありました。私自身、生成AIが登場した当初は「自分の手で書いた方が品質が高い」と感じましたが、これもあの時と同じ構造の抵抗感ではないかと気づき、はっとしたことがあります。しかし私は、そのたびに素早く試して、失敗から学び、柔軟に方向転換することで、変化の波に乗り続けてきました。

そして今、生成AIの進化によって、この「素早く作って検証する」サイクルが劇的に加速しています。

従来: 2週間かけて設計を固め、2週間かけて実装し、合わなければ手戻り。

今後: 1時間で仮説を立て、AIに実装させ、動くものを見て検証し、方向転換する。これを1日に何度も回す。

「完璧な設計を最初に作る」という思考から、「素早く作って素早く学ぶ」という思考への転換です。失敗のコストが下がった以上、失敗を恐れて考え込む時間の方がもったいないのかもしれません。

今回のパラダイムシフトの規模はこれまで以上に大きいかもしれません。しかし、主体性を持って素早く動き、創造的に考え、困難に折れず、変化に適応するという姿勢そのものは、どの時代のシフトにおいても変わらず重要であり続ける普遍的なものだと考えています。

5-4. 「自分にしかできない仕事」を問い続ける

これが個人的には最も大切にしている行動指針です。日々の仕事の中で、常にこう自問するようにしています。

「今やっているこの作業は、AIにできないことだろうか？」

もしAIにできることを自分がやっているなら、その時間の使い方は見直した方がよいかもしれません。AIにできることを人間がやっている時間は、今後ますます「もったいない時間」になっていくように思います。

定型的なCRUDの実装 → AIに任せる
テストコードの作成 → AIに任せる
ドキュメントの作成 → AIに任せる
バグの調査と修正 → AIに第一報を任せ、自分は判断に集中する

では、自分は何に時間を使うべきか。

ユーザーと話して本質的な課題を見つける
事業戦略と技術戦略を接続する
チームの技術的な意思決定をリードする
AIの出力を統合し、プロダクトとして成立させる
障害時に最終判断を下す

6. チームとマネジメントに起きる変化－他者との関わり方も変わる

ここまでは主に「個人としてのエンジニア」の話をしてきましたが、エンジニアは一人で仕事をしているわけではありません。チーム、マネジメント、組織。他者との関わり方もまた、このパラダイムシフトによって大きく変わると考えています。

6-1. チーム構造の変化－少人数で大きな成果を出す時代へ

AIが実装を担えるようになることで、一人のエンジニアがカバーできる範囲が劇的に広がります。これは必然的にチーム構造に影響を与えます。

従来であれば、フロントエンド、バックエンド、インフラ、QA、PMとそれぞれ専門の担当者を揃えて10人のチームで開発していたプロダクトを、2〜3人のエンジニアがAIと協働してカバーできるようになりつつあります。

これは「人を減らす」という話ではなく、同じ人数でより大きなインパクトを出せるということです。ただし、そのためにはチームの一人ひとりが課題設定力・判断力・実行力を高いレベルで持っている必要があります。少数精鋭のチームでは、一人ひとりがより主体的に動くことが求められるようになるのではないでしょうか。

6-2. マネジメントの焦点が移る－「労働量」から「判断の質」へ

マネジメントの対象も変わります。

従来のマネジメント	今後のマネジメント
工数の見積もりと配分	課題の優先順位づけと方向性の判断
タスクの割り振り	「何をAIに任せ、何を人間がやるか」の設計
進捗の管理	アウトプットの品質レビュー
スキルセットに基づくアサイン	判断力・課題設定力に基づくアサイン

AIが実装速度のボトルネックを取り除く以上、マネージャーの仕事は「誰に何をやらせるか」ではなく、「チームとして何に取り組むべきか」「AIの出力の品質をチーム全体でどう担保するか」に移っていくのではないでしょうか。

6-3. 評価基準の再定義

これは組織にとって最も難しい変化かもしれません。

従来はコード量、コミット数、特定技術への専門性、資格の数といった「目に見える成果」で評価できました。しかしAIがコードを書く時代に、これらの指標だけでは十分な評価が難しくなっていくように感じています。これは資格を積み上げてきた私自身にとっても例外ではありません。

新しい評価基準として考えられるのは、以下のようなものです。

どれだけインパクトのある課題を定義できたか
AIの出力をどれだけ正確に判断し、品質を担保できたか
どれだけ素早く仮説検証を回して成果に繋げたか
チーム全体のAI活用レベルを引き上げる貢献をしたか

「何を知っているか」ではなく「何を実現したか」で評価する。言葉にすれば当たり前のことですが、実際に評価制度として設計するのは容易ではありません。しかし、ここに向き合わなければ、優秀な人材から離れていくのではないかと感じています。

6-4. ジュニアエンジニアの育成という課題

個人的に最も悩ましいと感じているのが、ジュニアエンジニアの育成です。

従来、ジュニアは比較的簡単なタスク（バグ修正、小さな機能追加など）を通じてコードベースを理解し、徐々に判断力を養ってきました。この「修行」の過程で失敗し、レビューを受け、少しずつ経験を積むことで、シニアエンジニアに成長していきます。

しかし、AIがジュニアレベルのタスクを高い品質でこなせるようになると、ジュニアが経験を積む機会そのものが減ってしまう可能性があります。かといって判断力は経験からしか育たない。ここに大きなジレンマがあります。

一つの可能性として、「AIが書いたコードをレビューすること自体を学習の場にする」というアプローチが考えられます。AIの出力に対して「なぜこの設計なのか」「他にどんな選択肢があるのか」「この実装のリスクは何か」を考える訓練は、従来の「自分で書いて覚える」とは異なりますが、判断力を鍛えるには有効かもしれません。

いずれにせよ、ジュニアからシニアへの成長パスは、各組織が意識的に再設計する必要がある課題だと思います。

また、一人ひとりがAIと組んで高速に動けるようになると、チーム内の情報共有が薄れるリスクもあります。「誰が何をどう判断してこの設計にしたのか」が見えにくくなるのです。ジュニアの育成に限らず、チーム全体として、コードそのものよりも判断の根拠を共有する文化が今まで以上に重要になるのではないでしょうか。

7. AIは「何を実現すべきか」を自分では決められない

最後に、私が最も大切だと考えていることを書きます。

AIは強力です。コードを書く速度も品質も、多くの場面で人間を上回ります。しかしAIには決定的にできないことがあります。「何を実現すべきか」を自分では決められないということです。

AIにとって、指示の質がすべてです。良い問いを立てられる人間がいなければ、AIはその力を発揮できません。逆に言えば、課題設定力で良い問いを立て、判断力で出力を正しく見極め、実行力で最後まで届けきる人間こそが、AI時代に最も価値を持つのではないでしょうか。

これは脅威ではなく、機会だと捉えています。AIが実装を担ってくれるからこそ、エンジニアは「何を作るべきか」「なぜ作るのか」「本当にユーザーの課題を解決できているか」という、より本質的な仕事に集中できるようになります。

手を動かす職人としてのプライドを手放すのは、正直に言って痛みを伴うものでした。しかし、自己否定の先には、課題設定力・判断力・実行力を軸に、より大きなインパクトを生み出せるエンジニアとしての新しい姿があると信じています。

この記事に書いたことは、あくまで私自身の経験と考察に基づくものです。異なる考えをお持ちの方もいらっしゃると思います。

この記事を読んで、「エンジニアの敗北宣言だ」と受け取る方もいるかもしれません。しかし、自己否定とは立ち止まることではありません。自分が積み上げてきたものを正面から見つめ直し、変化すべき部分を見極めて次に進む。むしろ、それはエンジニアが最も得意としてきたことではないでしょうか。私たちは昨日の自分のコードを今日リファクタリングしてきた人間です。今回は、その対象がコードではなく自分自身の価値観だったというだけのことです。

ただ、もしこの記事を読んで少しでも何かを感じていただけたなら、一つだけ自問自答してみてください。

自分が今日取り組んだ仕事のうち、AIには決してできないものはどれだけあったか？

その答えを考えることが、きっと次の一歩に繋がるのではないかと思っています。

参考：