この記事について
この記事は完全に人の手によって書かれています。
人間の脳からの産地直送となっておりますので、安心してお読みください。
はじめに
現在、大生成AI時代となっており、大企業がこぞって生成AIを打ち出し、日進月歩で成長を続けています。
最近で言うと、Googleが出したAntigravityから始まり、Gemini 3 Pro、GPT-5.1、Claude Opus 4.5など11月だけでも飛躍的な進化を遂げています。かく言う筆者もAntigravityやGeminiを日頃から愛用しており、その凄まじさを実感しているところです。
まさに世は大生成AI時代であり、これから先人間がシステム開発を行うことなんてないんじゃないか？と思わせてきています。
...しかし、本当にそうでしょうか？
AIの得意・不得意
AIは何でもかんでも簡単にこなしているように見えるかもしれません。実際、どんなに難しいタスクだとしても数分から数時間程度待てば結果が返ってきます。これは凄まじいことです。
しかし、その品質はどうでしょうか？
いまだ人間のレビューが必要である以上、中身が完全に保証されているとは言いづらく、また全てを自動で行ってくれているわけではありません。
その結果SDD（Spec Driven Development：スペック駆動開発）のように、AIに指示する「仕様」を人間が厳密に定義する開発手法が重要視されつつあるわけです。
これは複雑なタスクに限った話ではありません。
先日私が個人的に学習を進めているときにも、つい最近アップデートによって破壊的な変更が入ったライブラリの情報をGeminiが収集できておらず、何度プロンプトを投げても間違った結果しか返ってこなかったことがありました。
これについては、破壊的な変更を加えたライブラリもどうかと思うのですが、AI側としても、常に最新の情報を参照しながら会話をしているわけではなく、ある時点での世界のスナップショットをもとに会話をしているわけですから、こういったことが起こるのも必然です。
AIは、すごく手を動かすのが早くてめちゃくちゃ博識だけどどこか抜けています。
つまり、AIというのは完璧ではないのです。
アウトプットってなんのためにするの？
AIを使ってなんでもこなせるようになりました。
簡単にアプリの実装も行えます。
AIを使って技術系のブログも書けます。
ではそれはなんのためにやってるアウトプットなのでしょうか？
私はアウトプットをすること自体は非常に良いことだと思っています。
筆者自身もこうして記事を書くことでアウトプットをしていますし、自分でAIを使ってアプリを作ることもあります。
大事なのはそこに目的意識があるかどうかです。
『AIを使ってアプリを作りました』というのは結果であって、重要なのはそこから何を得たのかということです。
もちろん、『お金を稼ぐためにアプリを作った』というのは非常に素晴らしいことです。
しっかりとした「お金を稼ぐ」という目的があります。
『AIを使った開発フローを体験する』こと自体を目的とするのも良いでしょう。
しかし、単に『AIに作らせて終わり』になってはいけないと思います。
特に学習段階においては強くそう思います。
成功体験を積むことは重要ですが、AIを使って作ったアプリについて、何も知識がない状態では本当に『ただ作っただけ』になってしまいます。
いろんな人がSNSで『AI使って〇日でアプリ作りました』『一日AIぽちぽちしてるだけで1ヶ月〇〇万円の売り上げ』という投稿をしているのを見て焦る気持ちは非常にわかります。
しかし、『ただ作っただけのアプリ』では、商用化したとしても成長させることはできないでしょう。
なぜならそのアプリの強みや弱みを理解していないからです。
最近、こうした『ただ作っただけ』『ただ書いてもらっただけ』といった、中身のないアウトプットが散見されるようになった気がします。
最初はそれでもいいかもしれませんが、徐々に『中身を理解して自分の言葉にする』習慣をつけるべきです。
じゃあ、どんなことを勉強すればいいのか？
ということで本題です。
AI時代に私たちエンジニアは一体何を勉強したらいいのでしょうか？
Geminiのプロンプトの書き方でしょうか？Claude CodeのTool Useの使い方でしょうか？OpenAIのFunction Callingの呼び出し方でしょうか？
これらは正解でもあり、不正解でもあると思います。
生成AIの分野は未だ発展途上であり、現在の知識が1ヶ月後に通用するかは未知数です。
もちろん、最新の情報をキャッチアップし、最新技術を理解することは非常に重要です。しかし、これらを使いこなせたからといって5年後にも同じように使える保証はありません。
今の段階で生成AIの技術に全リソースを割くのは個人的には間違っていると思います。（特に私のようなジュニアエンジニアにとっては）
では、何を学ぶのか？
私の答えは「いろんなこと」です。
なんじゃそりゃ、と思う人が多いかと思いますが、至って真面目です。
もっとわかりやすくいうと、『広く浅く、多種多様な分野のことを知る』ことが重要だと思っています。
この考えの元となったのは、ソフトウェアアーキテクチャの基礎-エンジニアリングに基づく体系的アプローチという本（めちゃくちゃ面白くておすすめです）の中の、技術的な幅という概念です。
この本の中ではこの世の技術知識の全てを集約したピラミッドが描かれており、その中には、「わかっていること」「わかっていないとわかっていること」「わかっていないとわかっていないこと」の3種類があります。
この本の中でアーキテクトは技術の深さよりも広さの方が大事だということが書かれていましたが、現代においてこれは一般の技術者においても言えることだと思います。
なぜなら、自分の知らないことに関するAIの出力に対して、自分では何も保証することができないからです。
簡単な例を挙げましょう。
私は韓国語が全くわかりません。適当なハングルが並んでいて、適当な間隔で空白があったらそれが正しい韓国語だと認識してしまうでしょう。
しかし、英語に関してはネイティブとは言わないまでもある程度の知識があります。適当にアルファベットを並べただけではそれが英文でないことは即座に判断できるでしょう。
これと同じことがプログラムやシステムにも言えます。
少しでも知っていれば間違っている、おかしいと気づけることも、全く知らない状態では気づけないのです。
こちらも例を挙げてみましょう。
AIが「パスワードは簡単にするために平文で保存しよう」といってきたらあなたはどうしますか？
ほとんどの人は「そんなのあり得ないから暗号化しろ！」と怒鳴り散らすでしょう。
しかし、「パスワードを平文で保存してはいけない」ということを知らない人がいたらどうでしょうか？
「そっちの方が簡単だし、それでいいや」「AIが言ってるから間違えないよね」と言ってそのコードが何かの間違いで本番環境に乗ってしまったらどうでしょうか？
考えただけでも恐ろしいですね。
これは非常に極端な例で、本番環境にデプロイされるまでにコードレビューやCIによる自動テストなど様々なチェックを経るため実際には起こりづらいことではありますが、もっと小規模なことだと十分起こりうることです。
ここで重要なのは、今回のインシデントの原因を取り除くために必要な知識は、「パスワードは平文で保存してはいけない」ということのみである、という点です。
「どうやって暗号化するのか」や「暗号化するための具体的なコード」などは必要ありませんでした。
もちろん、実際に暗号化する際にはこれらの知識も必要ですが、これらの知識がなくても「パスワードは平文で保存してはいけない」という知識があれば、今回のことは起こりませんでした。
こういった小さな知識の種を持っているだけで、AIが提示したコードの危険性に気づくことができます。だからこそ、詳細な実装方法はAIに任せるとしても、私たちは「わかっていないとわかっていること」の範囲を広げていく必要があるのです。
まとめ
アウトプットはどんどんした方が良いです。
しかし、アウトプットをなぜするのかという目的意識を持ちましょう。
そして生成AI時代だからこそインプットをどんどんしていきましょう。
何も分厚い技術書を1から読破しろ！と言っているのではありません。まずは『こういう技術があるんだ』という名前や概念を知ることが重要です。
その『知っている』という感覚が、AI時代における強力な武器になるはずです。
ここまで読んでいただきありがとうございました。
共感してくださった方はいいねを、お前の言ってることはデタラメだ、と思う方はコメントをぜひ残していってください。
それでは今後も良いエンジニアライフを👋