開発現場のエンジニアが語る、AI活用のリアルとこれからのエンジニア像

AIツールの進化が加速するなか、エンジニアの仕事はどう変わっているのか。日々の開発でAIを使い続けるエンジニア3名に、活用の実態から失敗談、半年後の開発スタイルの展望まで、本音で語ってもらいました。

登場人物

名前	役割
あさしん(@asashin227)（写真右下）	名古屋プロダクト部のエンジニアリングマネージャー。仕事でもプライベートでもAIをうまく使う方法を常に模索中。エンジニア以外でもAIを使えるようにスタメン内でのハンズオンやAIもくもく会を運営しています
おしん(@38Punkd)（写真左下）	iOS開発を得意とするエンジニア。AIを使って積極的にAndroidやWeb技術にチャレンジ中。プライベートではAIでインフラ中心のエンジニアをしている
いが(@cochumo)（写真真ん中）	フロントエンドを専門領域としているエンジニア。AIを使ってバックエンド開発にも軸足を伸ばしています。今回のインタビュアーも兼任。

1日の業務の50〜80%がAIと対話。コードの外にも使い道は広がる

── 1日の業務のうち、何%くらいAIと対話したり、作業を任せたりしていますか？

あさしん： ミーティングが結構多いので、思ったよりは使えていないんですよね。それでも50〜60%くらいにはなっていると思います。ミーティングの前に依頼しておいて、ミーティング後に確認みたいな使い方をしています。

おしん： 自分はあまりミーティングが多くないので、70〜80%は使っていますね。

いが： 60%ぐらいでしょうか。作るものの方向性についてメンバーとディスカッションする部分は人間がやらないといけないので、100%にはならないですね。

── どんな場面でAIを活用していますか？

おしん： 仕様の方向性をまずAIと話して、提案の形に整えてから人間とのディスカッションに持ち込む流れが増えてきました。ステークホルダーへの合意形成の前段階だったり、CS（Customer Success）へのお知らせ文や顧客との調整の頭出しにも使っています。まるっと投げるというよりは、自分なりの仮説がある状態でブラッシュアップしていく、という使い方が多いですね。

あさしん： 最近はClaude Cowork（以下Coworkと表記）をコーディング以外の場面でも使えるようにしていきたいなと思っていて、少しずつ試しています。割合はこれからも増えていきそうだという感覚はありますね。

いが： Coworkいいですよね。社内のチャットのステータス変更の処理を自動化してスケジューリングさせるような使い方は、本当に助かっています。

スピードは上がった。でも、楽しさの「質」が変わった

── AI導入から、開発のスピード感や楽しさはどう変わりましたか？

あさしん： スピード感は確実に上がりましたね。やりたいことを自然言語で書けばとりあえず動く状態になるので、試行錯誤の回数が格段に増えています。ただ、仕事においては「プログラミングは自分がやらなくていい」という目標をもともと持っていたので、AIがコードを書くことへの心理的な変化はそれほどないというか。メンバーが書いてくれるのとAIが書いてくれるのとで、感覚的にはさほど変わらないんです。変わったと思うのは、人との解釈合わせにかかるコミュニケーションコストが減ったことです。AIへの指示は自分の責任で完結するから、より言語化の精度を上げないといけないという意識が強まりましたね。

おしん： 楽しさという意味では、むしろ大きくなりました。これまでネット上の記事を探し回ることに費やしていた時間をAIが肩代わりしてくれるので、「プロダクトの仕様をどう改善すれば売上に貢献できるか」という、本来考えるべきことに頭を使える時間が増えています。

いが： AIの進化にはワクワクするんですけど、AIに実装をやらせているとき自体はそんなにワクワクしなくなってきました。自分が書いていないからのめり込めなくて、複数のことを並行して浅く広く動かす形になってしまっている。コードを書いているときの楽しさは、正直なくなってきましたね。

おしん： ただ、その代わりに。職人的な充実感よりも、事業を前に進めている手応えに重きが移ってきた感覚がありますね。

── 具体的に「これはAIにやらせて正解だった」という事例はありますか？

あさしん： テストケースを大量に作らせるのはAIが得意な領域で、活用しています。あとは先ほど触れたCoworkですね。カンファレンスのグッズを企画するときに、会話の中で出てきたアイデアをそのままデータ化したり、作ったデータをNano Bnanaで画像に合成して、それっぽいイメージを可視化できるのが便利でした。コーディング以外のプロトタイプも、以前より格段に作りやすくなっています。

いが： Coworkは自然言語で指示してワークフローを組むと、ブラウザ操作まで実行してくれます。そこが本当に大きい。こういった活用はこれからさらに広がっていくんだろうなと感じています。

ガードレールを引かないと、リポジトリもドキュメントも静かに汚れていく

── 逆に、失敗したことや、気をつけていることはありますか？

あさしん： 個々のミスというより、チーム全体として気になっているのはリポジトリに入っているドキュメントが少しずつ汚れていくことです。うちもそこまでドキュメントの文化が強いわけじゃないので、誰も深く見ていない箇所でAIが誤った内容を書き込んでいても気づけない。ガードレールをきちんと設計しておかないと、気づかないうちに的外れな方向へ進んでしまう。意識して向き合わなければならない課題だと思っています。

おしん： 嘘とまでは言えないけれど、根拠があいまいなままでも断言してしまうのがAIの特性だと思っていて。わずかでも事実と違う内容が混ざると、ドキュメント全体の信頼性が揺らいでしまいますよね。

いが： 仕様書をAIに書かせた場合でもユーザーインタビューに基づいた内容なのか、推測で書いたものなのか、根拠がまったくない記述なのか、読んだだけでは区別がつかない。その3パターンをちゃんと分類する仕組みを作って曖昧なところを明示的に固めていく、そういう工夫をこれからも続けていきたいですね。

── プロンプトや指示の出し方で、自分なりにこだわっていることはありますか？

あさしん： まず一度考えさせる、というのは意識しています。「プランニングしてください」と明示的に書いてから進めるようにしていて。あとは、プロンプトで都度指示することより、ドキュメントを整えて自動的によい動きをしてくれる環境をつくることを優先していますね。スキルの整備やエージェントの動きを定期的に見直すのも続けています。週に一度くらいは、同じ作業を繰り返していたらスキルとして切り出す習慣もつけています。

セッションの履歴を見て、繰り返しやっていることをスキル化するのは効果的です。全セッションを遡る必要はなく、そのセッション内のやり取りから切り出すだけで十分なことが多い。CLI（Command Line Interface）やLSP（Language Server Protocol）をちゃんと使い込むと、その辺りがうまく機能すると思いますね。

これからのエンジニアに求められるのは、ドメイン分解力・抽象力・言語化力だ

── 半年後、自分たちの開発スタイルはどうなっていると思いますか？

あさしん： コーディング作業そのものは今より少なくなると思っています。その代わり、課題を持っているステークホルダーとのコミュニケーションがより重要になってくる。FDE（Forward Deployed Engineer）と呼ばれる役割、つまりお客さんの現場に立ってエンジニアとして提案していくような動き方も、これから注目されていくはずです。

いが： すでに別の会社では、CxO（Chief x Officer）にAI活用が得意な人を一人つけて、その人がやりたいことをPoC（Proof of Concept: 概念実証）化していくという動き方をしているところも出てきていますよね。

おしん： Figmaじゃなくてプロダクトレベルでのモックを素早く作る、という段階は確実に進んでいくと思います。エンジニアの強みは、やりたいことに対してどのアプローチが現実的かを具体的に示せる点にあります。自分のタスクや技術領域だけを見ていればいいという姿勢は通用しなくなって、事業全体を見渡して課題を見つけ動かしていけるエンジニアが、これからの開発を牽引していくと思っています。

── AIが進化し続ける中で、エンジニアが磨くべき「コアスキル」とは何でしょうか？

あさしん： ITバブルの頃、エンジニアの工数が一番レバレッジが効くと言われていたのは、一人分の工数をかけることで、かけた工数をソフトウェアとして何万人というユーザーに展開できる、かけ算的な成長ができるからでした。今後はAIによってプログラミングが民主化されて誰もが主体的に開発できるようになってくる。そういった中で自分たちが発揮できる価値を捉えていく必要があります。アウトプットがソフトウェアである以上、ソフトウェアがわかる人向けの言語化の仕方はエンジニアならではの強みになると思う。

あとはロジックの破綻を整理してあげるとか、ドメイン駆動開発をエンジニアが担ってAIにドメインごとの指示を出していくとか、そういうやり方が主流になっていくでしょう。ドメイン分解能力、抽象能力、言語化能力、そして事業全体を俯瞰できる広い視野。自分のタスクだけ見ていればいいというエンジニアはどんどん淘汰されていって、事業全体から課題を見つけて推進できるエンジニアが成長して牽引できると思っています。

おしん： エンジニアの専門性はPMやデザイナーとも融合してきているし、モバイル・バックエンド・フロントエンドといった境界もなくなりつつある。そこをコアスキルにするのはもったいない。エンジニアが磨くべきは事業理解であり、事業ドメインをソフトウェア設計に落とし込んで、リリース後も安定的に運用できる力こそが本質なんじゃないかと思っています。