初めまして、今年の4月から25卒で入社したミヤタ(@hm-404 )と申します。今回、せっかくなので記事を書いてみませんか？と打診を受けまして、「私でよければ！」と思い書かせてもらいました。拙い文章かもしれませんが、最後まで読んでいただけると幸いです。
この記事は私が新卒研修でAIを用いた開発に参加した経験をもとに学んだことや感想を共有することを目的としています。
- 出身：関西
- 経歴：工業高校→IT系専門学校→GxP
- プログラム歴：8年弱
- 学生時代：チーム開発と個人開発とフレームワーク研究
- 現在：研修中
- スキル：フロント(React)中心、時々バックをやる程度
- 主言語：基本TypeScript、JavaScriptとHTMLとCSSは再勉強中
新卒は4月の共通研修後に主に4つのコースに分かれます。このコースは事前に新卒向けのアンケートを実施し、その結果をもとにコース分けが行われ、5月からの研修は基本このコースに沿って行われます。私はその中のOJTコースという研修を行っています。
OJT（On-the-Job Training）
職場で実際の業務に携わりながら行う研修のこと。
私のほかに3人がこのOJTコースで実際に案件に入りながら研修を行っています。
OJT配属決定
周りのOJT参加者が既存案件に所属していったので「私もどこかの既存案件に入って研修する形になるのかな…？」と思っていたのですが、私が配属になったのはまさかの新規案件でした。案件が始まったばかりだったこともあり、「新卒の自分が入っても迷惑では？」と不安を感じた一方で、「むしろ貴重な機会では」とやる気も湧きました。
AI駆動開発
案件に配属してバックエンド側から手を付けることになりました。これまでにバックエンドを担当した経験はあったものの、本格的に扱ったことはなく、フレームワークも初めて触るものでした。言語自体には馴染みがあったものの、「果たして自分に何ができるのか…」という不安がありました。そんな中、先輩社員の方が教えてくださり、少しずつ取り組む姿勢が整っていきました。
学生の頃もCursorというエディタで、AIを補助的に活用したコーディングをしていましたが、その頃は分からない部分やエラーの解決はAIに頼りつつも、コードを書くのは基本的に自分自身というスタイルでした。
しかし、この開発はAI駆動と書いているようにAIに指示を与えてコードそのものを生成させる形式で進めます。実際に体験してみると開発スピードの速さとAIの可能性に驚かされる一方で、「エンジニアがまったく不要になるわけではない」と強く感じました。
実際に使用していたツール：VScode＋GitHub Copilot
開発で使用しているフレームワーク：AutoGen,Next.js
今回の研修を通してエンジニアとして成長したと思ったことは大きく5つありました。
その1：自分の知識＝AIの能力
AIに適切な命令を与えるには、AIが生成したコードを読み解く力が必要です。AIは確かに優秀で、開発スピードも大幅に向上します。しかし、人間がミスをするのと同様に、AIも間違えることがあります。そしてその修正は、最終的に人間で担う必要があります。
「なぜそのエラーが出てしまっていたのか」「なぜ動かないのか」
その原因を見極めるには一定の知識が求められます。
これまで自分自身が蓄えた知識やノウハウは決して無駄ではなく、それらを活かすことで開発が更にスムーズに進んでいきます。そのことからAIの能力は使用者の知識量に依存する と感じました。
その2： AgentとAskとEditを用途に合わせて切り替える
AI駆動開発にはGitHubCopilotを使用しており、チャットボット機能にはAgent,Edit,Askの三つがあり、それぞれに特徴があります。
- Agentは自動コーディング
- Askは質問
- Editは現在のコードの編集
最初はAgent機能を中心に使用していました。プロンプトを書くだけで、意図に沿ったコードが自動生成される様子に驚き、「これを人間が書いていたら何日かかるのだろう…」と感じたほどです。
しかし、使っていくうちに「何も考えずにAgent任せで開発を行うのはかなり危険だ」と気づきました。
実際、エラー修正を依頼したのに逆にエラーが増えてしまったり、1つの機能を実装させたつもりが、余計な処理まで追加されていたこともありました。
そこで修正時にはまずAsk機能で該当箇所の原因や対応方針を確認し、それを元にプロンプトを組み立ててからAgentに実装を依頼するようにしました。この流れに関しては修正の流れにて記述しています。
ただ便利と言う理由のみでAgent機能を使うのではなく、使用用途ややりたいことによって機能を分けることがとても重要だと学びました。
その3：プロンプト文の重要性
前述の自分の知識＝AIの能力にも通じますが、どれだけ知識があっても、それをAIに正しく伝えるのは簡単ではありません。AIは文脈こそ理解してくれますがAgentとAskとEditを用途に合わせて切り替えるで述べたように、時に余計な処理を勝手に行ってしまうこともあります。そうした事態を防ぐために重要なのが、プロンプト文です。AIに指示を出す際は、曖昧さを排除し、目的と制約をはっきり伝える必要があります。
具体的なもので言えば、禁止事項を明確化するというものがあります。
事実に基づいて修正してください
余計なことはせず、愚直にエラー修正を行ってください
新しい機能を追加しないでください
私の場合、こういった禁止事項まで丁寧に指定しないと、意図しない変更が加えられ、「結局、自分で修正した方が早かった…」と感じることも少なくありませんでした。おそらく命令の仕方に改善の余地があるのだと思いますが、禁止事項を明確化させるのはかなり効果的だと感じました。
以下は、私がChatGPTなどで調べ物をする際によく使うプロンプトです。
プロンプト文を作成する際に意識していること：
- 推論と仮設を禁止して事実のみを明記してください
- 分からないことは分からないと発言してください
- 出典とURLを明記してください。もし推論ならその根拠となる情報を明記してください
- 事実と推論を明確に区別して回答してください
その4：修正の流れ
私自身が感覚で動くタイプの人間で、基礎知識をもとにしながら、過去の経験や「このコード、ちょっと変かも」という違和感を頼りにコーディングをしてきました。個人開発やチーム制作ではバックエンドとフロントエンドの両方を担当することが多く、そうした経験の中で自然と自分なりのスタイルが形成されていきました。社会人となった今でも、基本的にはそのスタンスを保っています。その反面、イレギュラーなバグが発生すると対応に苦戦し、エラーの修正に半日かかることもありました。
そんなとき、先輩からアドバイスをいただいたことで、「どうすればより効率的にバグ修正できるか」を考え、自分なりの修正フローを確立するに至りました。
1. バグを特定する
そのエラーがどこで起きたのかをエラーコードを読んだりAIに質問して特定します。たいていは読めば大体わかるのですが時々エラーとなってる文章の指定がなかったり、抽象的な内容になっていたりする場合があるので、その時は編集した部分やエラーの内容である程度の目星をつけてからAIに丸投げしたりします。
2. なぜバグが起きたのかの整理
そのバグがなぜ起こってしまっているのかやその該当部分にあたるコードを探して情報の整理を行います。同じ状況で再現を行ったりコンソールログを確認しながらAIに質問をしてそのバグが起こった原因を整理します。
3. 内容についてコードを使わずに言語化する
コードを使わずに言葉で通じるようにします。なぜ起こったのか、原因は何なのか。根本的な問題を解決するためと私自身がそのバグの起こった原因を理解するために工程として入れています。
4. 修正案を考える
バグの原因とそのコード上の問題点が把握できたら、それに対してどのように対応するかの修正案を考えます。
複数の解決方法がある場合は、それぞれのメリット・デメリットを整理します。この段階では、AIに「こういう原因だと思うが、どう直すのが良いか」などと相談したり、類似事例を調べたりもします。
5. バグを修正する
修正案に基づいて、実際にコードを修正します。
6. バグが起きた原因と修正内容を言語化する
修正後、そのバグが「なぜ起こったのか」と「どのように直したのか」を文章で言語化します。PRを作成する際や自分がどのようにこのバグを修正したかを後々見直してもわかりやすくするために行っています。
手間自体はかかりますが、私はこの方法でバグを修正するようになってから劇的に修正の速度が速くなりました。
その5：コンポーネント指向の再認識
もともとReactの勉強をしていたため、コンポーネント指向の基礎的な考え方は理解していました。学生時代の時も基本的にはコンポーネント指向にのっとって作ってました。学生時代の開発でも基本的にはコンポーネント指向に沿って実装していましたが、当時の自分は「画面単位で大きな部品を作る」というスタイルで、小さな部品もその中にまとめてしまっていた結果、コードが冗長になり見づらくなったり、エラーの特定に時間がかかったりすることが多くありました。
そんなとき、先輩から教わったのが「コンポーネントは小さなパーツに分けて構成する」という考え方でした。
この考え方はAtomicDesignの考え方に近いと思い、興味を持って調べたり、先輩からお話を聞いたり、コンポーネントを作る際に意識しながらコーディングをしていました。そして自然と自分の中でコンポーネントに対しての考え方が固まってきました。
特に意識するようになったのは、以下の点です：
- コードの可読性を高めるためにパーツを分ける
- 画面をパーツごとに分けている
- コンポーネント一つに必要な処理しかないため、コードが短くなる
- 可読性とコンポーネントの使いまわしがやりやすくなる
コードを短く保つことで、人間だけでなくAIの理解も早くなり、エラー修正や提案の精度が上がります。その結果、開発全体のスピードが格段に向上しました。
この考え方を頭の片隅に常においておくことでリファクタリング作業やフロントの画面を設計する際に「このパーツは分けすぎかもしれない」「逆に粒度が粗すぎるかも」といった視点が持てるようになり、画面設計全体への理解が格段に深まりました。
今回の研修を通して大きく二つの内面的な変化と課題が生まれました。
その1：言語化能力の重要性
私は、感覚や過去の経験に頼って物事を理解する傾向が強く、つい自己完結してしまいがちです。
そのため、人に説明することが苦手で、「もっと簡潔に伝えられたのでは？」「こんな内容にしては説明が長すぎたかも」と反省する場面が多々あります。
エンジニアといえど、誰とも話さずに黙々と作業する日はほとんどなく、数時間に一度は報連相の機会があります。
また、朝会や夕会などの定例ミーティングでも、口頭で状況を共有する場面が頻繁に発生します。そういった場面で、「なぜその問題が発生したのか」「自分はどう考えているのか」といった内容を他者に伝えることに、今もなお苦戦しています。
このように、業務の中で相手に分かりやすく説明するには、言語化能力が不可欠だと痛感しました。
エンジニアはコードを書く以上に「報告・連絡・相談」や「PR・Issueの記述」が多く発生します。そうした中で、自分の考えや状況を正確に伝える力＝言語化能力の重要性を、これまで以上に強く感じています。
個人開発では、自分が理解できれば問題ありませんでしたが、チーム開発・実務となるとそうはいきません。
これは「業務を通して向き合うことになった課題」であり、現在の自分の中で大きな目標です。
誰かに教える、伝えることができて初めて自分のためになる
最近ではこの言葉を肌で実感しています。
その2：「人に頼ること」への意識変化
これまでの私は、次のような考え方や背景を持っていました：
- 何か行き詰ったりすると自分で解決しないといけないと考えてその結果解決できしまう
- 誰かに任せるよりも自分でやった方がいいという考え方
- 自分で解決しないといけないという責任感が過度に人よりも強い
- 長男だったため周りに頼れる年上があまりいない環境
- 頼ってしまえばその人に迷惑が掛かってしまうから自分で何とかしないといけない思考
こうした経験や環境の影響から、「誰かに頼る」という発想自体が、私の中にほとんど存在していませんでした。今でも苦手意識はありますし、この考え方を根本的に変えるには、まだ時間がかかるかもしれません。
それでも、少しずつ「頼る」という選択肢が、自分の中に生まれてきました。もちろん、頼りすぎるのは良くありませんが、逆に「まったく頼らないこと」が自分だけでなく、チーム全体にも悪影響を与える場合があります。
実際に、研修中に自分だけで抱え込み、うまくいかなかった経験がありました。
そのとき先輩から「徐々に頼れるようになればいいよ」と声をかけてもらい、自分の中の考え方も少しずつ変わっていきました。
今でも完全に慣れたわけではありませんが、以前よりは周囲に頼れるようになってきていると感じています。
いずれは、自分が苦手なことは素直に頼りつつ、誰かに頼られる存在にもなれるよう、これからも努力していきたいと思っています。
研修を通して、知らなかったITの知識を学んだり、知っていたつもりの知識を再確認・再構築したりする貴重な機会を得ました。
しかし、それ以上に印象的だったのは、 「仕事をするうえで必要な考え方・姿勢・習慣」を学べたことです。
- 相手と自分の考えに相違がないかを確かめる
- 本当に分からないことはきちんと聞き、頼る
- 自分の中で完結せず、きちんと誰かに説明できるようにする
私にとってこの三つの考えが自分の中の価値観を大きく変えてくれました。どれも当たり前のように見えますが、その「当たり前」ができていなかったからこそ、これまで苦労してきたのだと実感しました。
知識やスキルももちろん重要です。しかし、それ以上に当たり前なことが最も重要であると研修を通して学びました。
この記事が今後、AI開発を行う新卒の方々や同じように悩みや不安を抱えている方の参考になれば幸いです。
改めまして最後まで読んでいただきありがとうございました！そしてこの場をお借りして色々と教えてくださったり相談に乗ってくれた先輩社員の皆さんにお礼を申し上げます。
本当にありがとうございました！
