テーマ、知りたいこと
AIがコードを生成する時代、業務や自己研鑽において手を動かしてコーディングした方がいいと思いますか?
背景、状況
今私の開発チームではClaude Code使ってコードはほぼ自動生成です。
自分の頭の中で考えたことをコーディングし、実際に動かすことで理解し、経験値として積めていた部分がありますが、まだエンジニアになって日が浅いメンバーがClaude Codeに指示を投げ、そのステップをショートカットしていることが長い目でみていいことなのかわかりません。もちろん、コーディングスピードはAIが速いので、いずれはAIで書くようになってほしいのですが。
気になる質問をクリップする
クリップした質問は、後からいつでもMYページで確認できます。
またクリップした質問に回答があった際、通知やメールを受け取ることができます。
回答10件
#1
個人的には書いた方がいいだろう、と思っているのですが、例えばAIが出力したコードをAIに設計・実装の意図を説明させるとか、今の時代に則した学習方法もあると思っており、もう書くことはコスパのいい経験値の積み方でもないのかなと感じています。
#2
総合スコア751
投稿2026/02/15 02:59
編集2026/02/15 04:24基礎の段階で、プログラミング学習の場合は、書いた方がいいと思います。個人的には(経験が浅くても学習の観点がないのであれば)仕事ではAIで書いて、修正が必要な個所を(自身で)書いた方が良いように思います。
会社側が、コスト面を重視するのか、教育面を重視するのかで回答が変わる気もします。ただ、以下の回答でClaudeも言っているのですが「この問いを持っている時点でチームにとって良いリーダー」だと私も思いました。
以下はClaude Opus 4.6の回答です。(ChatGPT、Gemini、Grok、Claudeは、現時点では全てのAIが「手を動かした方がいい」と回答しました)
なぜ手を動かす経験が必要か
プログラミングの理解には、大きく分けて「宣言的知識(何を知っているか)」と「手続き的知識(どうやるか体で分かっているか)」があります。AIが出したコードを読んで「なるほど」と思うのは前者で、自分でエラーにぶつかり、デバッグし、動かす中で身につくのが後者です。
後者が弱いと何が起きるかというと、AIが生成したコードの良し悪しを判断できない、エッジケースやパフォーマンスの勘所がわからない、AIが間違えたときに自力で直せない、といった問題が出てきます。つまり、AIを「使いこなす」ための土台が育たないんです。
とはいえ、昔と同じやり方である必要はない
手を動かす学習とAI活用は共存できます。たとえば、こんなアプローチが考えられます。
段階的に移行する。 新しい概念や言語機能に初めて触れるときは自分で書く。理解した領域ではAIに任せる。この境界線をメンバーごとに意識的に管理するのがリーダーの役割になります。
AIの出力をレビューする訓練をする。 Claude Codeが書いたコードを「なぜこう書いたか」を説明させる(メンバーに、です)。説明できないコードを本番に入れない、というルールは学習にも品質にもプラスです。
小さなスコープで「素手」の時間を作る。 週に数時間でも、アルゴリズムの実装やバグ修正をAIなしでやる時間を設けると、筋トレのように基礎力が維持されます。
長期的な視点
AIツールは今後さらに進化しますが、「何を作るべきか」「この設計で本当にいいか」「ここのトレードオフをどう判断するか」という上流の判断力は、手を動かした経験の蓄積から来るものが大きいです。若手がその土台なしにAIに依存すると、シニアになったときに「AIの指示は出せるが、AIの判断を検証できない」エンジニアになるリスクがあります。
チームとしては、短期の生産性(AI全面活用)と長期の人材育成(基礎力の構築)のバランスを意図的にデザインすることが大事で、あなたがこの問いを持っている時点で、チームにとって良いリーダーだと思います。
#3
#2 ありがとうございます。良いリーダーだなんて恐縮です。
- リスト結局、人間がAIのアウトプットの責任をとる構図が崩れない限りは、それを判断できる力を養わなければいけない
- いつまでも経験豊富なエンジニアがいるわけではない
そう考えると、外から優秀なエンジニアを獲得するか、社内で育てるかになると思いますが、前者はそう簡単ではなく、少なくともエンジニアにはアンコントローラブルな要素だと思うので、後者に力を入れなければいけないなと考えています。
前置きが長くなってしまったのですが、
短期の生産性(AI全面活用)と長期の人材育成(基礎力の構築)のバランスを意図的にデザインすることが大事
自分としてもこれが落とし所なのかなと思っています。
今の時代にAIでコードを書かないのは競争力を損なう、かといって教育をおろそかにすれば開発チームの成長速度は鈍化する。
仕事ではAIで書いて、修正が必要な個所を(自身で)書いた方が良いように思います。
#2さんの意見には同意です。以下の理由で本当は仕事でもAIエージェント使わないで自分で書いてほしいですが、上述の通り競争力の面で使わない手はないので・・
- AIエージェント(Claude Code、CodeX等)のアウトプットのスピードが早すぎて、特に若手エンジニアでは理解が追いつかない
- スピードを求められる現場では性悪説が割とあるなと感じていて(怠慢とかそういうことではなく)、AIエージェントのアウトプットを理解できないままそのままプルリクエストをあげてくる場合がある
- AIのアウトプットは正しく・それっぽく見えるため、「多分大丈夫そう」と理解した気になっている
なので、これに対する対策として以下のような対策を打てると良さそうです。
- きちんとレビュワーがプルリクエストのレビューをする(ちゃんと理解できるかを確かめるため、モブでやって説明させてもいいかも)
- そうするとレビューコストがあがるので、簡単なレビューはGitHub Copilotなどを駆使してコストを下げる
#4
総合スコア171
投稿2026/02/17 03:42
検索機能が発展した現代で文章を手書きすることに価値がないわけでないのと同様に、生成AIの時代にも手書きのプログラムには価値が残り続けます
例えば手書き検索という機能があります
漢字の形が分からなければ、検索候補から地道に対象を絞り込んでいくしかありませんが、目的の漢字を覚えていればそれを書き込んだが効率よく結果を見つけ出せます
AIがプログラムを生成することは、極論はこの延長なので、目的のコードは予め頭の中で描ける状態であることが望ましいです
そのためにはコードを書く経験が必要です
幸い、今はリファレンスとしてAiは非常に有用です
新しい言語を学ぶ時、下手な記事よりは簡単なプログラムをAIに生成して貰った方が理解に繋がります
そこで分からないことの補足として更にテキスト教材を参照してもらうことで理解はいっそう深まるでしょう
あと学習時に必要なのはまずひたすら足し算など本当に単純なプログラムを多様なパターンで設計してもらうことだと思います
言語仕様に慣れて貰った方がその後の理解も早いでしょう
一番の目標は言語リファレンスを読めるようになることです
#6
総合スコア82
投稿2026/02/19 01:08
質問者さんの懸念(若手がAI丸投げで理解追いつかない、レビューで「それっぽいけどヤバい」を見逃す)めっちゃ現場あるあるだと思います。
僕もAI(Claude Codeなど)フル活用してる立場から、現実的な落とし所を。
• 書く経験は完全に否定しない
新しい概念に初めて触れるときは自分で書いてみるのは有効(#4さんの漢字手書き比喩みたいに、目的のコードを頭に描けるようになる)。
でも、理解した領域でまで毎日ガッツリ素手で書くのは非効率。爆速で価値を出さないと競争に負ける時代に、生産性を殺す「おもり」になるリスクが高いです。
• AIのコードを読む(レビュー・ブラッシュアップ)のが最重要スキル
業務のほとんどが「AI出力の読解 → 修正指示 → マージ」。
読む量が増えれば、自然にパターン(良い書き方、怪しいところ)が体得できる。
だから優先順位は 読む >> 書く でいいと思います。
• セキュリティ周りは例外的に勉強する価値が高い
最新レポート(Veracode 2025など)でAI生成コードの脆弱性が多い数字が出てるけど、これは**「AIだから」じゃなくて、「過度に依存してるエンジニアが多い現実」**を表してるだけ。
安易に丸投げしてレビューサボったり、浅いプロンプトしか投げない人が多いから。
プロンプトの投げ方が大事。
例:
• 「どんな潜在的な脆弱性がありそう?」
• 「それどう対応した? 根拠は?」
• 「セキュアな代替案出して」
こういう連鎖で深掘りすれば、AIはかなり良い指摘を返してくれる。
でもこれを打てるかは脆弱性の基本知識(OWASP Top 10とかSQLi、XSS、JWT検証抜け、秘密漏洩など)があるかどうか。
だからセキュリティだけはピンポイントで勉強しておくと、壁打ちの質が劇的に上がる。
まとめると
• 書くは適度に(やりすぎ注意)。
• 読む + プロンプト工夫 + セキュリティ例外勉強
これでAIを相棒に使いこなせて、爆速開発と安全の両立ができるはず。
質問者さんがこのバランスを気にしてる時点で、チームの良いリーダーだと思います。
みんなはどう思いますか?
#7
総合スコア3
投稿2026/02/20 06:58
「コードを書くべきかどうか」という話ではなく、
AI 時代のプログラミングは“手を動かすことそのもの”よりも
“どう考えるか”の比重が大きくなった、という感覚に近いと思います。
バックエンドは依然として手動+AI 補助のハイブリッドで進める場面が多いですが、
フロントエンドはすでに AI 主導で完結するケースが増えてきました。
この流れを見ると、バックエンドや DevOps も
AI が自動生成する時代になるのは時間の問題だと感じています。
#8
総合スコア241
投稿2026/02/20 08:55
難しいテーマですね!
個人的な見解書きます。
学習においては手を動かして開発するのは大事だと思います!
ただこれは、あくまで効率の話しで、手を動かしたほうが理解が速いからです。
例えばコンポーネント化の大切さは、同じものを何個も作って、修正のときに「なんでこんな無駄なこと何個もやってんだろ」って思わないと気づきにくいかと思います。
AIがきれいなコンポーネント設計をしても、「これがコンポーネントってやつか!」ぐらいにしか思わないかなと。
一方業務においては、手を動かさない(AI駆動、SDDなど)で早くアウトプットを出すことが大事や"べき"ではなく求められると思います。
それは、「AIで開発させて」という依頼ではなく、「最速で作って」「1ヶ月で作って」など、「あー手で書いてたら無理やな」という依頼が増えていくと思うからです笑
これが正しい流れなのかどうかはわかりません。
ただ、世の中のスタンダードがこうなりつつあるので、その希望にそう手段を選択するとymmrさんのいうような手を動かさない開発になっていってしまうかなと...
(AIで作ったプロダクトで個人情報漏れるみたいな事件が大きいところで何件もおきたりしたら、少しは変わるかもなーこの流れって思ってます笑)
#9
総合スコア207
投稿2026/02/21 04:56
この記事が秀逸だと思いました。
飲み会で新人に同じ質問をされたので後日この記事を紹介しました。
https://qiita.com/WdknWdkn/items/9b7dea889fec59194df5
リアクションはかなり微妙でしたが、今気づいたこととしてはそもそも新人と自分では見ている世界が全く違うのがひとつあるんじゃないかと思います。
もう1つは学習っていうのはその学習者が自分からどう学習すればいいのかを身につけるもので、他人がその方法を評価することは無理だろうし、この原則はきっと学生時代からそうなんだろうと思います。
あなたの回答
tips
太字
斜体
打ち消し線
見出し
引用テキストの挿入
コードの挿入
リンクの挿入
リストの挿入
番号リストの挿入
表の挿入
水平線の挿入
プレビュー
質問の解決につながる回答をしましょう。 サンプルコードなど、より具体的な説明があると質問者の理解の助けになります。 また、読む側のことを考えた、分かりやすい文章を心がけましょう。