はじめに
「AIを活用して生産性を高め、効率よく業務を回そう！」
「加速するAI時代、AIに仕事を奪われないスキルや情報を身につけよう！」
最近こういう言葉をよく目にしませんか？
もう気づけば、エンジニアでAIを使っていない人の方が珍しくなりましたね。
業務に使えそうなAI情報をインプットする毎日ですが、正直追いきれていないです。
というよりも、「 情報を追うことに疲れた 」 というのが正直なところでしょうか？
それは裏を返せば、それほど膨大なAIが生み出され、成長を続けているという事実を示していると言えます。
特に2025年は加速度的にAIが革新的な進化を遂げた年だと実感しています。
パブリックな面だけでも様々な機能やツールが公開されました。
-
Claude codeやGemini、Codexが、プロジェクト全体を解析して、適切なコード生成をしてくれるようになった
-
MCPでアプリとのツール連携が一気に進んだ
-
Genspark / Dia / Atlas のような「AIブラウザ」「AI IDE」が検索の補助をしてくれるようになった
-
Webサイト構築・アプリ制作・業務効率化ツールが、プロンプトだけでできるようになった
これは一部だけですが、すべて今年に起きた出来事です。
なので今年はエンジニアにとって、AI情報をインプットして実践・選択するだけでもとんでもないインプット量だったのじゃないでしょうか？そりゃ疲れますよね。
ただ、それによって生産性・効率性は確実に上がりました。
特にコーディングに特化したAIは、その影響がわかりやすいかと思います。
少し前までは、エラーログを確認し原因箇所を特定し、似たような Issue を検索して読み漁り、ライブラリやサンプルコードで試しながら理解し、動くまで何度も修正と再実行を繰り返していました。
それが今では、
- 関数のたたき台やクラス設計をAIが提案してくれる
- テストコードまで一緒に生成してくれる
- リファクタ案やパフォーマンス改善のアイデアも教えてくれる
ということが日常になりつつあります。
気づけば、「自分でコードを書いている」という実感よりも、「AIにコードを書いてもらっている自分」という感覚の方が強くなってきたんですよね。
便利さと引き換えに、コーディングそのものに感じていた楽しさや誇りが少しずつ薄まっていくような感覚がありました。そうすると自然とこんな気持ちが湧いてきます。
「 “コードを書くこと”自体の価値が、ガラッと変わってしまったように感じる 」
このモヤモヤをどう整理して、どうアップデートしていけばいいのか。
この記事では、そのあたりを「エンジニア2.0時代のコーディングの楽しみ方」として、言語化してみようと思います。
この記事はこんな方にオススメ
- AIを使い始めた駆け出しエンジニア
- コーディングにAIを多用しているエンジニア
- 「AIは便利だけど、なんか寂しい」と感じているすべてのエンジニア
コーディングがアイデンティティの一つだった
たとえば、AIが人間より上手にイラストを描けるようになったとき、
「 イラストレーターのアイデンティティはどこに残るんだろう？ 」
感じているのは、エンジニアもそれと同じような不安です。
ポートフォリオ制作をしていた頃は、「エディタを開いて、自分の手でコードを書いて、それが動く瞬間」が楽しかったんです。
今はAIがシュッとコードを出してくれる。便利なんだけど、なぜかテンションが上がらない瞬間もある。なんだかモヤモヤする。それは何故か。
自分にとってのコーディングとは、
「手を動かして作ること」がアイデンティティの中心だった ということです。
それをAIが担うようになって感じた “半減感” がモヤモヤの正体でした。
ではそれをどう解消するのか。どのようにしてアイデンティティを保つのか。
それを考えてみることにしました。
ひとまず結論
アイデンティティを“エンジニア2.0”へ引っ越す
つまり自分が楽しいと思える領域を拡張し、上位のレイヤーに移してしまうことで、
この喪失感が解決できるのではないかと考えました。
これを言い換えると、
「 AIに仕事を奪われた 」 のではなく 「 アイデンティティの場所を引っ越す 」 という考え方です。
「アイデンティティを引っ越す？」「エンジニア2.0って何？」
こう思っている方も多いのではないでしょうか？
AIが台頭する前は、コードを書くという行為にアイデンティティを持っても問題ありませんでした。しかしこれからはそのアイデンティティを、
「どんな問題を発見しているか」「どんな設計で解こうとしているか」「AIを含むチームをどう動かしているか」
という部分に居場所を感じることで、新たな価値を作り出せるのです。
これがエンジニア2.0時代の考え方ということです。
- 顧客価値への解像度
- 要件定義・設計に落とし込む力
- AIと対話しながらアウトプットを最大化する力
一見普遍的とも思えるこの力を身に付けることで、AI以上の技術革新が生まれたとしてもアイデンティティを見失わずに対応できます。
普遍的というのは、いつの時代も変わらない価値を生み出せるのです。
エンジニア2.0時代の価値観
この記事では、
AIの技術革新が起きる前の状態を、エンジニア1.0と定義します。
そして以降の状態をエンジニア2.0とするわけですが、詳しく説明します。
先にエンジニア1.0と2.0の違いをまとめると下の表のようになりますが、
ここから言えることはとてもシンプルです。
| エンジニア1.0 | エンジニア2.0 | |
|---|---|---|
| 主な仕事 | 仕様通りにコードを書く | 問題・顧客価値を定義し、AIを含めてシステム全体をデザインする |
| アイデンティティ | 「コードを書いている自分」 | 「何をなぜ作るかを決めている自分」「AIを使って価値を生み出す自分」 |
| 強み | 手を動かすスピード、既存パターンの実装 | 要件定義、設計、レビュー、リファクタリング、チームとのコミュニケーション |
| AIとの関係 | 競合相手：「自分の仕事を奪うかもしれない存在」 | チームメンバー：「雑務を任せつつ、より面白い領域に集中させてくれる存在」 |
| 価値の出し方 | 行数・工数で測られがち | 「この問題をこう解く」というストーリー、全体のアウトプット |
AI時代に求められるのは、
「 顧客価値を理解し、それを設計に落とし込めるエンジニア 」 です。
ユーザーが何に困っていてそれをどんな仕組みで解決できるのか、
どんな制約があり、何を優先したらいいのか。
問題の設定 ＝ イシューの領域に深く入れるエンジニアが普遍的な価値を生み出せるのです。
そうしたエンジニアがこれからの時代に残っていくのだと考えます。
では逆に代替されやすいエンジニアとはどんな特徴があるのでしょう？
それは、
-
「言われた通りに作るだけ」
-
「仕様の背景や目的に興味を持たない」
-
「どう書くか」だけで「なぜそうするのか」には関心がない
といった 手段にしか目が向いていないエンジニア です。
こういった作業は、今どんどんAIが得意な領域に近づいています。
ただ、AIが登場する前でも考えずに作るだけのエンジニアはよくないと言われていました。
AIの存在によって、それがより顕著になったのです。
これからどう楽しむか
では実務のレベルでどう楽しみを見出すのか。
ここからは業務に取り入れられる内容を3つお伝えします。
具体的には3つのモードを使い分けすることで、楽しみの捉え方をリフレーミングできます。
-
コーディングモード
ここではAIと一緒にコーディングするのが前提とします。
実装の大部分はAIに任せて、
「要件の明確化」「設計」「プロンプト」「レビュー・リファクタリング」などを楽しみます。
AIが出したコードをどう崩して良くするかをゲーム感覚でやる、という具合です。 -
素振りモード
このモードでは、あえてAIを使わずに書く時間を確保します。
小さな機能の実装や新しい言語の学習など、あえてAIなしで「手触り」感を味わいます。
コードを書くことの楽しみ自体を完全に手放す必要はなく、 素振りモードとして残しておけばいいのだ ということです。 -
課題解決モード
実際にここがエンジニア2.0の主戦場になります。
「どのような人がどのような場面でこのシステムを使うのか」
「どういった体験を提供できるのか」
「そのために必要な機能は何か」
この辺をPMだけの仕事にせず、エンジニア自身が楽しんで取り組むためにこのモードを使います。
これらのモードを使い分けすることで、業務に対する形骸化を防ぐことができます。
ハイコンテキスト言語をうまく活用する
ここで注意したいのは、AIと共同する際にプロンプトを伝えるかです。
もう最近はAIにプロンプトで指示するのは古いという流れになっていますが、
AIを使い始めたばかりの方には、いいスタートダッシュが切れて便利かと思います。
その理由は、AIはニュアンスや文脈を汲み取ることが苦手だからです。
個人的に、AIがローコンテキスト文化の発祥のものであるからだと考えています。
言語は文脈で考えると２種類に分けることができます。
ハイコンテキストとローコンテキストです。
日本語はハイコンテキストに属し、英語やドイツ語などはローコンテキストに分類されます。
| 言語の特徴 | |
|---|---|
| ハイコンテキスト | 文脈や状況、相手との関係性に依存し、非言語な要素（表情、身振り、空気感）がコミュニケーションで重要な役割を果たす |
| ローコンテキスト | 直接的で言葉自体に明確な意味が込められており、文脈や状況を参照する必要がなくそのままの意味で理解される |
例えば、「なんかいい感じに改善してください」と伝えたとして、人間だと理解することでもAIではその意味を理解できないなんてことがザラにあります。
これは日本語が言葉以外の要素でも伝わってしまうことに問題があります。
ここを改めて認識した上で、プロンプトを言葉そのものに意味を持たせるように改善すれば適切なコード生成が行え、トークン量も抑えられて一石二鳥です。
ではその型とは何か？
以下の5つの要素が含まれていると良いです。
「指示」「役割」「目的」「出力形式」「参照情報」
これらが「いいプロンプトを書く力」になり、「高解像度に文脈を言語化する力」となります。これはまさに、エンジニア2.0の必須スキルであり、アイデンティティにもなり得えます。
サム・アルトマンも使っている
今後も新たな機能やツール、AIなどが登場することでしょう。
そこに加えて業務の仕様やシステムの構築するための情報も収集するとなれば、ますます情報疲れに陥ります。
最近では 情報洪水 と言われるようにもなりました。
それを防ぐには、今でも使用されているローテクを使います。
それはノートです。「そんなこと？」思うかもしれませんが、こういった普遍的なものにこそ価値があります。
実はあのAIの権威であるサム・アルトマン（OpenAI：現CEO）でさえ、いまだに手書きのノートに考えをまとめています。ポケットサイズのメモを愛用していると話しています。
ノートに書くことには、情報の渦に飲み込まれることなく思考を整理する力が備わっています。
ここで最近活用しはじめたノートの取り方をご紹介します。
それはコーネルメソッド式ノートという手法です。
この手法は、米マイクロソフトでエンジニアとして活躍されている牛尾剛さんの著書、
「世界一流エンジニアの思考法」の本書でも取り上げられているノートの活用法です。
元は米のコーネル大学の学生に向けて開発されました。
特徴として、ノートの1ページを3つの領域に分け、それぞれの情報を整理しながらノートを取っていくというものです。3つに分けることによって情報の整理が簡単になり、ノートの中身が一目見て分かりやすいものになります。
-
キュー（きっかけ）
ノートの左側に、自分が学んだことにつながる質問を書いておく。 -
ノート(本文)
一番領域の大きい部分。ここではノートを取りながら学ぶのではなく、自分が学んだことを後から思い出しながら要点を書く。 -
サマリー（要約）
ノートの下側に、後日振り返ったときの要約を書く。
実際にやっていますが、自分が一週間前に何をやったかが一目瞭然になります。
なにより思い出すのに時間をかけなくて済みますし、もう一度調べ直すということが減り、かえって効率が良くなりました。
情報が滝のように流れる現代で、こうしたローテクはストックするのにうってつけのアイテムだと言えます。
おわりに
ここまで書いてみて、そしてAI関連の本や記事を読んでみて分かったことは、
やることは意外と変わらないということです。
今は緩やかに、ただ確実にAI格差が生まれている転換期だと思います。
ですがここでAIに過剰に反応してしまうと、活用目的とズレてしまいます。
AI時代にエンジニアがやるべきことは、
「コーディングをやめること」ではなく、
「 コーディングのどの部分が好きだったのかを言語化して、
その “芯” をAI時代の役割に引っ越すこと 」
なんじゃないかと考えています。
「コーディングのどんな瞬間が一番好きなのか？」
「その楽しさは、３つのモードのどこで再現できそうか？」
「明日からどこの部分を変えられるか？」
ぜひ自分に問いかけてみてください。
この記事が、同じようにモヤモヤしているエンジニアの思慮のヒントになれば嬉しいです。「こんな楽しみ方もあるよ！」というアイデアがあれば、ぜひコメントで教えてください。お待ちしています。
最後まで読んで頂きありがとうございました。
参考記事