0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AIコーディング時代に揺れる3年目エンジニアの話 〜レビュー不要論、自分の成長、責任の所在

0
Last updated at Posted at 2026-05-25

この記事の要点(TL;DR)

  • IT未経験で就職して社会人3年目、エンジニア人生のすべてをAIと一緒に過ごしてきた立場から、AIコーディングに対して感じている「揺れ」を書きました
  • 個人の成長の話と、プロダクトの責任の話、2つの視点で考えています
  • 結論:現時点で正解はない。ただ「考えた上で選ぶ」状態を保つことが大事なのではないか、という話です
  • 同じく揺れている人と意見交換できたら嬉しいので、感想ぜひください

巷で話題のレビュー不要論

最近Xで「AIが書いたコードはレビュー不要」「もう一行もコード読んでない」みたいな話をちょいちょい見かけて、自分なりに色々考える時間がありました。

「いや、それでよくない?」って思う自分と、「いやいや待って、それエンジニアとしてどうなん?」って思う自分が同時に存在していました。

この状態をちゃんと言語化したいなと思って書いてます。先に言っておくと、僕は大学でプログラミング触ったことなかった3年目エンジニアで、偉そうなこと言える立場じゃないですし、結論を出す判断材料は少ないと思います。なので、揺れてる最中の人間がリアルタイムで書いてる記事だと思って読んでもらえると嬉しいです。

ちょっとだけ、僕の立ち位置の話をさせてください

先程も触れましたが、僕は今年の春で社会人3年目に入りました。IT未経験で就職して、今ちょうど丸2年経ったところです。

僕が入社した年、ちょうど社内でAIチャットボットが解禁されました。つまり、僕のエンジニア人生って最初からAIと一緒なんですよね。「AIなしの時代」を業務でほぼ経験してない、わりと珍しい世代だと思ってます。

たぶん今回の話を考える上で結構大事なので、最初に置いておきます。

徐々に仕事にAIが浸透し始めている話

1年目の頃の社内AI、今思うと正直しょぼかったなと思います。品質もイマイチ、セキュリティ的な縛りも厳しくて、「使ってもいいけど信用するな」みたいな空気。だから当時は技術調査も不具合調査も10割自分でやってました。

それが2年目あたりからガラッと変わりました。社内のガバナンスが整って、AIの品質が爆上がりして、気がついたら技術調査の8割はAIに聞くようになっていました。怪しいところだけ追加で自分で検索する、みたいな運用。

そして今、会社のAI推進部署ではClaude CodeやCodexを実際の開発に組み込み始めてます。もちろん「完全に任せる」じゃなくて「人が理解してる前提」での部分導入。それでも確実に「人間がAIにコードを書かせる」フェーズに入ってきてます。

そんな感じで仕事を続けていて、最近すごく感じてることがあります。

視点①:自分の中で起きていること(成長の話)

自分の中で何が起きてるか

ハッキリ言えるのは、調べる力が落ちました

1年目の頃って、エラーメッセージをブラウザに貼って、Stack Overflowの似た質問を5個くらい開いたり、ZennやQiitaの記事を探したりして、コメント欄まで読んで、ああこれ違うなって戻って、検索ワード変えて、また開いて……みたいなこと延々やっていました。めちゃくちゃ時間かかるし、しんどかったです。

でもあのプロセスで、自然と「こういうケースではフレームワークのこの機能を使える」「このエラーは大体この辺が原因」みたいな勘所が体に染み込んでた気がするんです。記憶への定着がぜんぜん違いました。

今はAIに疑問を貼るとすぐに答えが出てくる。怪しかったら追加で検索すればいい。速い。マジで速い。でも、あまり覚えてない。

「こういう技術があるんだ」という知識のタグは増えました。「あ、それ○○でいけますね」みたいなラベリングは確実に増えた。でも、いざ「AIなしで○○を使って実装して」って言われたら、僕、たぶんめっちゃググります。引き出しの「ラベル」は増えたけど、「中身」は薄くなってる感覚。

自分でゴリゴリ書いてた頃は、コード書くたびに「自分のスキル」が一段ずつ積み上がってる手応えがあったんですけど、今は手応えが薄いです。アウトプットは確実に増えてるのに、自分の中の何かが育ってる感じがとても薄い。

でも、本当にそれって「失った」のか?

ここからが自分でも答え出てない部分になります。

そもそも前提がもう変わってきてるんじゃないか、っていう疑問もあります。

「AIあり」の世界が標準になりつつあって、これから入ってくる新人はもっとAIネイティブです。だとしたら、これからのエンジニアに求められるスキルって、「自分で全部書ける力」じゃなくて、「AIに上手く書かせる力」「AIの出力を見抜く力」なのかもしれない。

実際、自分の技術力や調査力は伸びてない実感があるんですけど、仕事のアウトプットの生産性と品質は、間違いなく上がってるんですよね。これってどう解釈すべきなんだろうと思います。

コンパイラ最適化の話

これもこういう議論の時によく出るコンパイラ最適化の歴史なんですが。

昔は、レジスタをどう使うかとかループをどう展開するかを、人間が手でアセンブリレベルでチューニングしてた時代があったらしいんです。そういうことができる人が「本物のエンジニア」と呼ばれていました。

でも今、商用開発でその技術が必須かというとほぼないですよね(もちろんそういうのが求められる場面があることも理解しています)。コンパイラの方が圧倒的に上手いから。じゃあ今のエンジニアの価値が下がったかというと、そんなことなくて、「コンパイラに何を任せて、人間は何を考えるか」っていうレイヤーに価値が移っただけ

僕らが今立ち会ってるのも、これと似た移行のどこかなんじゃないかな、と思ってます。

100%同じとは言いません。コンパイラは決定論的だけど、AIは確率的でハルシネーションも吐くし、完全な類比じゃない。でも、「機械に任せる範囲がじわじわ広がっていく」流れの中に、AIコーディングも位置づけられるとは思ってます。

じゃあ調査力とか自分で書く力って、もういらないのか?って言われると、僕は今のところ 「両方できる方がいい」 と思ってます。どっちかに振り切るのは、今は早すぎる賭けな気がして。だってまだ、AIに全振りした世代がどうなるか、誰も知らないんですよ。答えが出るのは10年後とか20年後の話。

なので僕は、仕事ではAIをガッツリ使うけど、家ではあえてAIなしで書いてみる日も意識的に作ってます。これが正解かは分からないですけど、両方の感覚を持っておくのが今は安全な気がしてます。

視点②:AIが書いたコードの責任、誰が取るのか(プロダクトの話)

ここまでは「自分が成長できるかどうか」の話でした。

でも、たぶん「いや、お前の成長の話なんかどうでもよくて、AIが書いたコードの品質と責任の話をしろよ」って思ってる人いると思います。そうですよね。冒頭のレビュー不要論の話に戻りますよね。

ここからが視点その2、責任と品質の話です。

「AIが書いたコードの責任、誰が取るの」問題

「AIが書いたコード、本番投入していいの?」「責任誰が取るの?」「セキュリティどうすんの?」これ、めちゃくちゃ議論されてますよね。

僕の今の結論、シンプルです。

個人で使うなら全部自己責任。仕事ならステークホルダーが決めること。

自分の趣味アプリなら、自分が満足するなら何でもいい。バグってても自分が困るだけ。

問題は、お客さんがいる場合とか、社内の業務システムを作る場合とか、要するに「自分以外の利害関係者がいる場合」。議論されてるケースのほぼ全部、これだと思います。

ここで僕がやるべきは何かと言うと、ステークホルダーにメリットとデメリットを正確に伝えること。これに尽きると思ってます。

AIを使うメリットは大きい

AIを使うメリットはもう、めちゃくちゃ大きいです。これは僕の体感でも、世間の動きを見ても、明らかにそう。コストは下がる。スピードは上がる。大手IT企業がAIを理由に人員削減してる事実が、何より雄弁だと思います。

品質面についても、これ言ったら怒られそうなんですけど、使い手が上手ければ、平均的なエンジニアの手書きより品質が上がることがあると感じてます。テストを書かせる、エッジケースを洗わせる、セキュリティ観点でレビューさせる、これを丁寧にやれば、人間が忘れがちなことをAIが拾ってくれることが結構あると思います。

「いや自分にはこの視点なかったわ」「このクオリティ、自分じゃ出せないわ」って思うこと、僕は普通にめっちゃあります。

もちろん「Googleのトップエンジニア」みたいな上澄みには敵わないとは思います。でも、僕が業務で触れる範囲のコードの平均値と比べたら、AIに丁寧に書かせたコードの方がきれいなことは普通にある。これは僕が3年目だから言える話で、ベテランの方が読んだら「お前の見てる範囲が狭いだけ」って思うかもしれない。それは否定しません。あくまで僕の体感だと思ってください。

でも、リスクはゼロにならない

ただ、リスクはどう設計してもゼロにはならない。ここが難しい所だと思っています。

最近もAI関連の事故を結構な頻度で見かけます。情報漏洩、脆弱性の混入、ライセンス問題。AIを使ったから起きた事故もあれば、運用ミスで起きた事故もある。要するに**「気をつけても起きるときは起きる」**ってことです。

セキュリティをどれだけ設計で固めても、一回事故が起きたらそこに責任は発生する。「AIが書きました」は言い訳になりません。

そもそも、ブラックボックスを信頼するのはAIだけの話じゃない

「中身を完全に理解してないものを信頼して使う」って、別にAIに限った話じゃないと思います。

これもよくある話ですが、例えばライブラリ。僕らが使ってるOSSの中身、ほとんどの人が中身のすべてを理解していないと思います。npmでinstallして、ドキュメント見て、入力と出力さえ合ってれば使う。中の実装は基本ブラックボックスです。で、たまにそのライブラリ自体にバグがあったり、悪意のあるコードが混入してて事故ったりする(log4jとか、最近もnpmパッケージへのマルウェア混入とか、ちょいちょい起きてます)。

AWSとかのクラウドもそう。サービスの内部実装を理解して使ってる人なんてほぼいないし、AWS側で大規模障害が起きてサービスが止まることも、過去に何度もありました。それでも僕らはAWSを使うし、お客さんも使うことに同意してます。

なんでこれが許容されてるかというと、「そういうリスクもあります」とステークホルダーに事前に伝えて、合意の上で使ってるからなんですよね。「AWSが落ちたら自社サービスも落ちる可能性があります」「ライブラリに脆弱性が見つかったら緊急対応します」っていうリスクを、契約や運用ルールの中で織り込んでる。

AIコーディングも、構造としては同じ話だと思うんです。「AIが書いたコードにバグや脆弱性が混入するリスクがあります、ただこういう体制で品質を担保します」っていうのをちゃんとステークホルダーに伝えて、合意の上で使う。それなら、ライブラリやクラウドと同じレイヤーで扱える。

逆に言うと、ステークホルダーに何の説明もせずに勝手にAIで書いて納品、これがマズいと思います。これはAIに限らず、勝手に怪しいライブラリ入れて納品したら同じくマズい。問題はAIかどうかじゃなくて、合意のプロセスがあるかどうか。

責任を誰が取るか

ここで重要なのが「責任を誰が取るか」。

これは現場のエンジニア一人が決められることじゃないと感じます。「AIをどこまで使うか」は技術問題に見えて、本質的には経営判断の問題だと僕は思ってます。

エンジニアの仕事は、メリット・デメリット・想定リスクを正確に経営に伝えること。決めるのは経営。事故ったときに最終的にユーザーに対して責任を負うのも経営。

これって冷たい言い方に聞こえるかもしれないんですけど、別に「自分は知らんぷりします」って意味じゃなくて、「責任の所在を明確にした上で、現場がちゃんと情報を上げる」っていう構造が大事なのではないかと思っているということです。

で、業界はどっちに転ぶのか

僕の予想を一個だけ書いておきます。当たるかは知りません。

積極的にAIを取り入れる経営者が増える
 ↓
AIコーディング前提の企業が増える
 ↓
工数単価の相場が下がる
 ↓
価格競争で他社も追随せざるを得なくなる
 ↓
気がついたら業界全体がAIコーディング前提になっている

たぶんこうなる気がしてます。

一個一個の会社が「使うか使わないか」を悩んでるうちに、市場がそれを決めちゃう未来。「AIを使わない選択肢」が、経済的に許されなくなる未来。

これがいいか悪いかは別の議論なんですけど、エンジニア個人の好みとか倫理観の話を超えたところで、業界全体がそっちに引っ張られていくのは、たぶん止められないと個人的には思っています。

結局何が言いたいか

長くなりました。ほんとすみません。

僕が今のところ思ってるのは、「AIに全任せ」と「AIを信じない」のどちらが正しいかには結論がないということです。

「AIが書いたから安全」も嘘だし、「AIだからダメ」も嘘。それぞれにメリットとデメリットがあって、状況によって最適解が変わる。

大事なのは、自分自身も、ステークホルダーも、そのメリットとデメリットを正確に認識した上で選んでる状態を保つこと。

「考えずに任せる」と「考えた上で任せる」は、見た目は同じでも、中身が全然違います。

僕はまだ3年目で、5年後の僕は今と違うこと言ってると思います。それでいいと思ってます。今は答えを急ぐタイミングじゃなくて、ちゃんと揺れる時期なんだと思います。

この記事を読んで思ったままの感想を自由に書いていただけるとありがたいです。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?