テーマ、知りたいこと
実務に携わり始めたばかりの若手エンジニアです。
現在は業務において Claude Code 等のAIエージェントを使用しています。
AIがプロジェクトの構成を把握し、精度の高い実装やリファクタリングを行ってくれる今、「あえてAIに頼り切らず、自力で動かせるレベルまで基礎を習得しておくべき領域」 はどこだとお考えでしょうか。
特に、AIを使うとブラックボックスになりがちな裏側の仕組み(インフラやミドルウェアなど)や、実装の前段にある「設計・要件定義」のスキルについて、エンジニアの先輩方の視点をご教示いただきたいです。
背景、状況
現在は、単なるAIのコピペ人間にならないよう、以下を自分なりに行なっています。
- 対話によるロジックの理解：AIが提示したコードに対し、計算量や保守性、採用されたアルゴリズムの意図を逐一質問し、自分の言葉で説明できるまで納得してから反映させる
- 体系的な学習：業務で触れる断片的な知識を補完するため、並行して技術書を読み知識を整理
しかし、AIの能力が向上するのを目の当たりにするたび、本来実装の試行錯誤を通じて得られるはずの肌感覚(?)が欠如し、実力が空洞化しているのではないかという強い焦りを感じています。
今の仮説
実装の大部分をAIが支援してくれる今だからこそ、人間が時間を割いて習得すべきは以下のような領域ではないかと考えています。
- ドメイン設計と論理モデルの構築: 曖昧なビジネス要求を整理し、一貫性のあるデータモデルやアーキテクチャに落とし込む力。
- 実行環境（インフラ・ランタイム）への解像度: 生成されたコードが実際に動作している環境の挙動。不具合に直面した際、AIの推論に頼らず、ログなどに基づいて問題を切り分ける力。
「実装の効率化が進むからこそ、その前後にある判断や裏側の仕組みの理解に学習リソースを寄せるべきだ」というのが今の所の仮説です。
回答2件
#1
総合スコア21575
投稿2026/02/27 12:38
私はそろそろITエンジニア暦20年になるそこそこの人です。
遅らせながら今年の1月にAntigravityに出会い、そこから1ヶ月と経たない家にClaude Code Max 5xプランに加入し
趣味プログラマーとしてGitHubの草が連日真緑になるレベルでぶん回してます。
そのOpus 4.5や4.6に頼る上で「ワシより上かもしれん……」から
「もうワシより上なのは確実じゃ……」に評価が変わるのもあまり時間はかかりませんでした。
その上であえて尖った回答をしますが、
対話によるロジックの理解：AIが提示したコードに対し、計算量や保守性、採用されたアルゴリズムの意図を逐一質問し、自分の言葉で説明できるまで納得してから反映させる
生成AIが出せるものや、生成AIが説明する御高説をメモを片手に覚えてもしょうがないです。
それ生成AIの得意なことなんで、張り合っても勝てる訳が無いし任せたほうが良い。
昨今では経営者層やITエンジニアではないちょっとPCに明るい程度の人まで
次々とスクリプトやプロダクトを作っては公開出来るようになりました。
その後の世界はどうなる？
私はこう思います。
多数のプロダクトやサービスがセキュリティホールを突かれて大炎上
個人情報や機密情報をばら撒いて損害賠償、多数の経営者や個人事業主が首を吊る
その結果、ITエンジニアは必要だよねってなる
じゃあ人間としての我々ITエンジニアは何処を伸ばすべきか？
生成AI「うっかり忘れてましたｗｗｗ」
↑これを指摘したり、未然に防げる能力を有しているか否かが、
これからのエンジニアが会社のその位置に座っている意味となるでしょう。
その源泉は本を読む事です。
おいおいいきなり古臭いジジイみたいな意見やな。
- セキュリティの知識
- こういうファイルを生成AIに読ませるのは危険という勘所
- フロントエンドならXSSが無いか等の気の利いたチェックポイントをSkillsに格納して遵守させる
- 神ファイルの作成
- Opus 4.6でもすぐに400行を超えるようなファイルをせっせと作り込んでしまう
- 「お前やる気ないだろ、この程度の処理なら半分の行数で書けるだろ」とツッコミ入れただけで150行に減った経験あり
- Opus 4.6でもすぐに400行を超えるようなファイルをせっせと作り込んでしまう
- 大量の一時ファイル・デバッグファイルの生成
- Gemini 3.1 Proはこの辺はまだまだおバカだなーと思う
- これもスキルやルールで良い感じにルールを決める
- 回避策
- 実装しようとしたものに矛盾が生じていたり、技術的に困難である場合、生成AIに投げたままだと迷走
- 「ちょっと相談タイム」と前置きし、この部分はこういう理由で難しいけど、こっちの手段を使えば楽じゃない？
- 思いつかない場合でも生成AIに相談していくことで活路が開けることもある
- テストをサボる
- テストコードをつくれと言うと
3.is 1 + 2みたいなテストを作ってサボり始める - 私は
/revスキルを作って「トートロジーなテストが無いか全部漁って指摘しろ」というチェックリストを作っている - 後は「お前そのテストでt_wadaの前で同じこと言えんの？」とチャットするのも結構効果的だったりする
- テストコードをつくれと言うと
こういった知識は生成AIと100個プロダクトを作れば少しずつでは伸びますが、
名著は思いもよらぬところから「これ知ってる？」と殴りかかってくるので、
斜め読みでも良いから技術書を買ってきて読むとかなりショートカット出来て良いんじゃないかと思います。
具体的にはリーダブルコードとか、MySQLとかセキュリティーとかの分厚い本を買ってきて
ざーっと斜め読みにしていくと良いでしょう。
英語が読めるならドキュメントを読みまくるのもオススメです。
フレームワークやプログラミング言語等のドキュメントもざーっと読んでいきましょう。
ベストプラクティスなんかも読むと良いです。
私はOpusにRustのTauriでWindowsのアプリケーション作れと命令した時に
src-tauriなるディレクトリを作り始めて「おいおい、src-tauriってなんだよ、srcにつくれよ」とチャットしました。
後からTauriのドキュメントに目を通して、「本当にsrc-tauriがベストプラクティスなんだ……」と驚きましたね。
これは私の無知による笑い話ですが、
それなりにベストプラクティスの在り方を知っているからこそのツッコミが出てくると思っていて
「ちょっと引っかかる、その処理は待て」と言えるポイントが作れないエンジニアは不要だとすら思います。
昔だったらMySQLの書籍とか買ってきて、ちゃんと手を動かして全てのコマンドをタイプして覚えろなんて言ったと思いますけどね。
様々な用語にインデックスを貼っていき、いざというところで「お前ちょっと待て！」が言えるのが新時代の優れたIT技術者と呼べるのではないでしょうか？
#2
総合スコア4328
投稿2026/02/27 13:56
AIは0→1にする力はすごいけども、その1が最適なのかは人間が判断して決定する必要があります。
その判断も基本的に一般化できず、自身の組織にとって最適化どうかを判断する必要、責任がありそれがAIに代替できない部分です。
そのため、若手とか関係なく何が正しいのかを判断するためも軸を持つ必要があり、それが経験＋知識になります。
AIが存在する前提でもやはり先人の知恵は必要ですので、前段の回答者様と同じく書籍での学習が必要と考えます。
正確には書籍に限らず体系立てて学ぶことのできる媒体で学び、手を動かして学ぶ事という感じなんですけど。
ただ、書籍はたいてい体系立てて学べる媒体なので例として出しやすいのでついつい書籍と言っちゃいますが、Udemyでもオンラインの資料でも構いません。
比重がこれまでより実装（コーディング）よりも、アーキテクチャ（設計）に移っているのは事実ですが、設計と実装の知識はどうしても独立しているものではなく地続きなので、実装側の経験、知識も必要です。
AIがいくら発展しようが、やはりAIが生成したコードの内容は理解できて、欠点も理解し手動で修正できる程度の力は身に着ける必要があると考えます。
そのため、若手はAI任せにしない心構えは必要でしょう。
あなたの回答
tips
プレビュー