――AIと共に働く現場で、いま何が起きているのか
生成AIの進化により、ソフトウェア開発のあり方は大きく変わりつつあります。
「AIに仕事を奪われる」のか、それとも「AIと共に働く」のか。
KiZUKAIでは、少数精鋭の開発体制の中でAIを前提とした“AI駆動開発”にいち早く挑戦してきました。

今回のインタビューでは、その実践を担ってきたメンバーたちに、

• AI駆動開発で実際に得られた価値
• 開発フローやエンジニアの役割がどう変わったのか
• そして、AI時代にエンジニアとして何を磨き、何を手放すべきなのか

について、率直に語ってもらいました。

AI駆動開発で得られた価値

インタビュイー（以下、I）: 本日はよろしくお願いします！まずは、今回のAI駆動開発で得られた価値について伺います。開発スピードやコスト、品質の面で、どのような変化がありましたか？

宇代（以下、U）: やはり、0から1の開発が劇的に早くなった点が一番の成果ですね。ただ、システムとして作り込む段階になると、AIに全てを任せるととんでもないことになるため、作り込みの部分のスピードや品質の成果はあまり感じませんでした。

蜂須賀（以下、H）: 他にも応用に移るまでの基礎知識のキャッチアップが、AIのおかげで圧倒的に楽になりました。たとえ未経験の分野でも、AIを使えば縦にも横にも理解を広げられるので、スピード感が増しましたね。

U: そして特に大きかったのは、バグの原因調査や修復作業がめちゃくちゃ早くなったことです。

I: 開発の初動やトラブル対応のスピードの変化が大きそうですね。コスト削減の面ではどうでしょうか？

U: 会社全体で見れば、オフショア開発を削減してAIを活用して内部でカバーした結果、ざっくりですが5割程度の削減にはつながりました。

I: それは大きいですね。この削減はどうして実現できたのか最大の要因を挙げるとしたら何ですか？

U: AIを活用することで、一人のエンジニア（蜂須賀さん）が、インフラ、バックエンド、フロント全てをカバーできるようになったことです。人間同士のコミュニケーションが最も時間がかかるため、システム全体を理解したフルスタック寄りのエンジニアがAIを使いこなす体制が、一番早く確実なやり方だと考えています。これにより開発人員の大幅な削減にもつながりました。

開発フローはどう変わったのか

I: 開発フローの変化はありますか？

H: 実のところ、要件定義からデリバリーまでのプロセス自体はほとんど変わっていません。変わったのは、「どうやって情報を得て、何を使って作るのか」という点のみです。これまでは自分で一つ一つ検索して調べていた部分が、ほぼすべてAIに置き換わりました。

I: 自分で調べてコードを書くのではなく、AIへの指示に置き換わったということですね。開発には様々な工程がありますが、工程ごとの“比重”は変わりましたか？

H: ここは少し整理して話すと「重要度としての比重」と「実際にかけている工数」が一致せず、逆転現象が起きています。まず重要度の観点で言うと、AIを使うようになってからは、要件定義や設計といった上流工程の重要度はむしろ上がっています。 体感としては、

（重要度の比重）
・Before：上流50〜60％／下流40〜50％
・After：上流60〜70％／下流30〜40％

というイメージです。

I: 上流の重要度がより増しているんですね。

H: そうですね。一方で、実際に使っている時間（工数）は逆です。 AIを使うことで、要件定義や設計、技術調査にかかる時間は以前より短縮されています。
その結果、

（実際にかけている工数）
・Before：上流50〜60％／下流40〜50％
・After：上流30〜40％／下流60〜70％

といった形で、下流（実装・テスト）にかける時間の割合が増えています。

I: それは少し意外ですね。

H: 理由はシンプルで、スクラップ＆ビルドを高速で回せるようになったからです。LLMを使えば試作はすぐに作れるので、「一度作って、壊して、直す」というサイクルを何度も回せます。 結果として、

• 一発で完成すれば、以前より圧倒的に速い
• ただし、何度も作り直す場合は、以前より時間がかかることもある

という状態になります。

I: なるほど。AIを活用することで「常に速くなる」というより、「試作→壊す→直す、を何度も回す前提で設計できるようになった」という変化なんですね。

H: まさにその通りです。だからこそ、設計の質や判断軸はより重要になっています。AIで下流は回せるけれど、どこで止めるか、どの方向に進めるかは人が決めないと、永遠にスクラップ＆ビルドを続けることになるんです。

I: 人がしっかりコントロールすることが大切なんですね。

H: 動くものを作るまでであれば、基本的にもうAIに任せられます。しかし、サービス品質、ユーザーが使って満足できるか、使いやすいかといった、人間が何を受け取るかの判断基準は、人間がやるしかありません。また、機能を実装する際、実現方法は複数あるので、どれが一番プロダクトの方向性にマッチしているかは人間が方向性を示す必要があります。拡張性を考慮した設計や、サポートも人間の役割ですね。

U: もう一つ大事なのは、意思決定と、その結果に責任を持つこと。例えAIがアウトプットしたものでも、ここは完全に人が担う領域だと思っています。

I: AIで一定の成果物は出せるけど、ユーザーが納得するクオリティへの精度向上、またAIを活用したアウトプットの責任に対しても人が担うべきということですね。日に日にAIの精度が上がることで、つい過信してしまうことがありますが、大切にすべき視点ですね。

エンジニアの役割・スキルはどう変わったか

I: AI導入後、日常の業務で最も変わったことは何でしょうか？

H: 一番「やらなくなった」のは、コードを書く作業ですね。体感で8割くらい削減されました。一方で増えたのは、レビューと動作確認です。自分で書いていないAIがアウトプットしたコードの振る舞いを理解するため、コードレビューや単体レベルのテスト検証数が圧倒的に増えました。

U: AIの回答待ちの時間（5〜30分）に別の作業をするので、仕事がマルチタスク化しましたね。以前はシングルタスクで一つの仕事を確実に終わらせていましたが、今は同時に複数のタスクを回すのが当たり前になっています。

I: 黒い画面に高速にコードを書くザ・エンジニアのイメージから大きく変わりましたね。コーディング業務が減ったことで重視するようになった業務やスキルはありますか？

永吉（以下、N）: 「何を作るべきか」を問い続ける姿勢と、コミュニケーション能力です。AIにやらせるには、自分の考えを正しく言語化する力が不可欠になりました。AIを活用して開発する今の環境では、自分の考えを言葉にして共有できることが、これまで以上にエンジニアの価値として求められるようになってきました。

I: エンジニア問わず、スペシャリストとして一部の範囲のみを任せるという業務スタイルが廃れていきそうですよね。そうなると、境界を超えるためのコミュニケーションの重要性が必然的に高まるのも頷けます。

AI活用の工夫と限界点

I: 実際にAI活用でうまくいかなかった事例はありますか？

H: 私の専任はバックエンドなので、フロントエンドには詳しくないんです。詳しくないまま開発をAIに任せたら失敗しました。指示の出し方や考慮すべき箇所が異なるため、それらの理解度が低いまま指示を出した結果、過剰設計やベストプラクティスを逸脱している箇所が多くなってしまいました。詳しくないからとレビューを最低限しか実施しなかった点も失敗の原因として大きいですね。詳しくない自覚があったので、AIと壁打ちして理解を深める努力をするべきでした。

U: 私は、本来自分で理解すべき実装の詳細なキャッチアップをAIに任せすぎた結果、AIが書いたコードの仕組みを理解できず、同じ問題に直面するたびにAIに聞き直すという非効率的な状況に陥りました。

I: やはりAIに任せすぎないというのが大切なんですね。他にもAIの限界を感じた場面はありますか？

H: AIに任せきれないのは、大きく分けて二つの領域です。一つは基盤回り（データベース設計や連携）。サービスの「土台」なので、ここでの設計ミスは取り返しがつかないからです。もう一つは、お客さんが直接見るUI/UX（フロントエンド）ですね。ここはサービスのクオリティにも直結します。現状のAIのアウトプットだと求める精度の4割程度しか出せない印象です。

U: 現状、AIが出したコードは、コンテキスト情報が不足しているために大切な観点が抜けがちなんです。

I: その4割を引き上げるために必要な力は何ですか？

H: 4割程度のクオリティを9割、10割まで引き上げるには、探究心や言語化力、そして責任感が欠かせません。人間が不足している情報や将来を見越した条件を丁寧に言語化し、AIを継続的にブラッシュアップしていく必要があります。ここを疎かにすると、サービスとしての品質は担保できません。

I: やはりどこまで人によるコントロールが重要になってくるんですね。「AIと共に働く」うえで他に意識していることはありますか？

U: AIを一人の人間のように扱うのではなく、すごい忘れん坊なアドバイザー程度に捉えることです。AIはセッションが変わるとすぐに前の内容を忘れてしまう（暴却の概念がある）ため、都度教えてあげる必要があります。

N: 私は、AIにタスクを任せる際、意図しない方向に進まないように制御することをとても意識しました。AIは指示を伝えた途端に修正を始めてしまうことがあるため、まずはいくつか案を出させて、こちらがOKを出してから修正を始めるというように、アウトプットの方針を握り続ける工夫をしました。とにかくAIを過信しすぎないというのが大切ですね。

AI時代の開発職に求められる資質と“手放すべきもの”

I: 改めて、AI駆動開発を通じて、今後のエンジニアに必要だと感じたスキルや思考力は何ですか？

N: AIの限界を理解した上で正しく活用する力、そして「何を作るべきか」を問い続ける姿勢です。また、AIに適切に指示を出すための言語化能力も重要になります。 AIは作業を高速化できますが、方向性の設計や判断を誤ると、期待とは異なるアウトプットになりやすいです。シンプルに行動量と、進むべき方向性が合っているかを深掘りできる「なぜなぜ分析」が重要です。

I: 逆に、「AI時代にはもう執着しなくていい」と感じるスキルや仕事のやり方はありますか？

N: 完璧であることへのこだわり、100点を目指すことは執着しなくていいと思います。AIによって0→1ですぐにたたき台を作れるようになったからこそ、完成度よりもアウトプットを重ねてとにかく物事を前に進めることのほうが大事だと思います。

H: 付随しますが、一人でモヤモヤ悩むことです。AIを壁打ちに使えば、次へ進むスピードが圧倒的に違います。完成度という面でも自分のエゴではなく、AIに判断を委ねて客観的に70点といった合格基準を決め、悩まない状態を作ることを大切にしています。

I: この挑戦を通じて、“人にしかできない価値”はどこにあると感じましたか？

N: とにかくゴールを決める力です。正しい方向性を設定し、AIが出したアウトプットを完成まで導く力は、人にしかできません。

U: AIとは少し離れますが、最終的に人の価値として残るのは、コミュニケーションや、仕事をしていて楽しいと思えるモチベーションの源泉的な部分なんじゃないかと思います。誰かにエネルギーを与え、その人のために頑張れると思わせる「人にバフをかけられる」ような存在であることこそ、人にしかできない価値だと感じます。

I: 確かに”この人と”、”このチームでこそ”共に何かを成し遂げたい、仲間に対してそんな風に思えるのはまさに人の価値ですね。

U: 正直なところ15年先か30年先か間違いなくAIがほとんどの人間の仕事を担える時代は来ると思います。今の僕たちは、もしかすると「仕事を楽しめる最後の世代」かもしれません。AIを悲観するのではなく、この波を面白がりたいですね。

H: ですね。「エンジニアよ、怠惰であれ」という格言がありますが、まさにAIを使って「いかにサボるか」を真剣に考えられるエンジニアほど、間違いなく成長できるし、今のAI時代も活躍できると思います。AIを恐れるのではなく、いかに活用して生産性をあげられるか。まだまだやれることはあるので、KiZUKAIではこれからも積極的にAI活用していきたいです。

最後に

AI駆動開発は、単なる効率化の話ではありません。
「人は何を考え、何に責任を持つのか」を問い直す挑戦でもあります。

KiZUKAIでは、AIを恐れるのではなく、共に働く仲間として迎え入れながら、エンジニア自身も進化し続けることを大切にしています。

この挑戦にワクワクできる方と、次の開発を一緒に進めていけたらうれしいです。
開発エンジニアも積極採用中です！ぜひカジュアルにお話ししましょう。