※この記事は レバテック開発部 Advent Calendar 2025 3日目の記事です。
導入
クリスマスも近いので、最近感じたことを少し書いてみる。
（アドベントカレンダーっぽくない記事になりそう、すみません）
ここ最近PRレビューをしていると、「仕様を満たしてない」「コーディング規約に沿ってない」みたいな指摘があって、思った以上に時間を要するケースが増えてきた。
理由が気になってあるメンバーとペアプロをしてみたところ、AIエージェントに対して指示を送り続ける、いわゆる VibeCoding のスタイルで実装している姿を目にした。
AIを活用すること自体は良いことだし、生産性向上にもつながる。ただ一方で、「エンジニアとしてそのコードをどれだけ理解し、説明できているのか」という点が気になり、考えたことを雑に吐き出したい。
コードに込める「魂」
突然だけど、こんな実装があったとする。
const fn = (datetime: Datetime) => {
console.log(datetime);
}
const datetime = new Date();
fn(datetime);
このコードはこのままでは動かない。
AIに「Datetimeにして！」と修正を依頼して以下のようなコードが生成されたとしても、同じく動作しない。
const fn = (datetime: Datetime) => {
console.log(datetime);
}
const datetime = new Date('2025-12-03 00:00:00');
fn(datetime);
なぜ動かないのか、どの型を渡すべきなのか。
その理由を説明できない状態でコードを書き進めてしまうと、レビューでのやりとりが増え、お互いにとって負担になってしまう。
ここで自分が大切だと考えているのが、コードに込める「魂」 だ。
これは大げさな表現に聞こえるかもしれないが、言い換えると 「なぜそのコードがそう書かれているのかを説明できる責任」 のことである。
会社に属してプロダクト開発をすることにおいて大切なのは、書いたコードに「責任」を持つことであり、これは「その実装を自分が説明できる」という姿勢に他ならない。
レビューはその責任を前提にした意見交換の場だが、理解が追いついていないと、意図が伝わらずキャッチボールの回数が増え、結果としてチーム全体の工数が膨らんでしまう。
VibeCodingは「使い方次第」で強力な武器になる
VibeCodingそのものが悪いわけではない。
むしろ、熟練したエンジニアにとっては、AIの提案内容を精査し、必要に応じて修正指示を出すことで、想定するアウトプットへ効率よく誘導できる強力な手法だと思う。これは「コードに責任を持つ」という姿勢を保ったまま、作業を高速化する良い使い方だ。
また、初学者にとって完成形のコードを見ること自体は非常に価値がある。私自身、既存システムの保守を通じて多くを学んだ経験があるので、AI生成コードを題材に学習するというアプローチにも賛成だ。
冒頭の例のようなコードを前にして、動かない理由を理解せずにAIに解決を任せるようなレベルであれば、まずは言語の勉強をするのがいいと思う。
土台を整備する
ここまでは主に「AIを使う側」の姿勢について書いてきたが、そもそも AI のアウトプット自体の質をどう上げるか という観点もある。
いくらエンジニアが「魂」を込めても、AIの出力が毎回ブレていては効率が落ちてしまう。ありきたりだが、自分なりに取り組んで効果を感じた方法をいくつかまとめておきたい。
参照できる「共通の土台」を用意する
やはり基本ではあるが、コード規約やアーキテクチャ定義などをドキュメント化しておくこと は大きな効果があった。
AIに実装を依頼する際、これらのドキュメントを参照させることで、コードの方向性や品質ラインがある程度揃う。
特に良い点は、実装時もレビュー時も同じドキュメントを AI が参照できるため、ベースラインが共有される ところにある。
これにより、チームで共有している設計思想や意図が AI の出力にも反映されやすくなり、コードのばらつきが減る。
リファクタリングでは「テストから書く」指示を徹底する
もう一つ効果があったのは、既存機能のリファクタリング時に必ずテストコードから書かせること だ。
AIに対して「まずテストコードを書き、そのテストを通す実装を行う」という流れを明示すると、意外にもまともなコードが出てきやすい。
メリットとしては、
- テストコードという“観点”ができ、AIが実装の意図を外しにくくなる
- 少なくとも動作面の担保が取りやすい
といった点がある。
もちろん、テストコードそのものが間違っている可能性はあるので、レビューは必須だ。
それでも、最後に必要なのは「魂」
ドキュメントを整備し、テスト駆動を指示したとしても、AIが仕様や実装の細かな意図を完全に汲み取ることは難しい。
だからこそ、AIを使う側のエンジニアに “コードへ魂を込める姿勢” は不可欠だと感じている。
そのためには、多くの学びが必要になるし、むしろ学びの効率を高めるためにAIを活用することが大事だと思う。
短期的なアウトプットの量を増やすためではなく、今後のキャリアの土台を育てる投資としてAIを使うことが、自分としては最も価値があると考えている。
まとめ
結局のところ、自分が伝えたいのはとてもシンプルだ。
- 「AIを使ったら作業時間が1/10になった」
- 「AIのおかげで、これまでできなかったことができるようになった」
こうした成果は、すでに一定の土台を持っているエンジニアだからこそ得られる効果だと思っている。
設計意図を理解し、コードの意味を説明し、AIのアウトプットをきちんと評価できる力があってこそ、AIは本来の力を発揮する。
逆に
- 出力されたコードの意図を説明できない
- なぜ動く（あるいは動かない）のか自分で判断できない
という状態だと、業務の成果物として使うにはまだ難しい場面が出てくる。そしてそれはチームの負担となってしまうことがある。
エンジニアという仕事を楽しむためにも、まずは自分なりに試行錯誤して、コードに「魂」を込める力を身につけることが大事だと感じている。
Discussion