Gemini Code Assist は開発を加速させる。では、エンジニアの専門性はどこへ向かうのか

Gemini Code Assist をはじめとするコード生成AIの導入を進める企業が増えていますが、ツールを入れただけで劇的な生産性向上に直結するわけではありません。実際の現場ではどのような変化が起きているのでしょうか。

Webシステム開発やDX推進を中心に、要件定義から保守・運用までを一気通貫で手がけるシステム開発会社、ラテラル・シンキング株式会社を取材しました。

開発環境（IDE）へ深く組み込める「Gemini Code Assist」の活用を始めましたが、AIの導入により、開発現場では何が起き、どのような壁に直面したのでしょうか。

そして、AI時代におけるエンジニアの専門性はどう変化していくのでしょうか。同社エンジニアの西原 宗詩郎 氏、福井 正寿 氏、松尾 裕太 氏に現場のリアルを伺いました。

西原 氏：AI活用の第一歩は、日常的に使用していた Google Workspace に Gemini がバンドルされた頃から始まりました。

最初の段階では、Google Workspace with Gemini のアプリ画面でコードの相談をし、その出力結果をコードエディターに貼り付けるという使い方が中心でした。便利ではあるものの、AI側には「どのプロジェクトの、どのファイルに関するコードなのか」という背景（文脈）が伝わらないため、プロンプトで毎回手動補正する必要がありました。

この状況を一変させたのが、2025年4月頃の「Gemini Code Assist」の導入です。

Gemini Code Assist は、VS Code などに対応した開発者向けのAIアシスタントです。コード補完やテスト生成に加え、自律的に周辺ファイルを網羅する「Agent Mode」を備えています。

IDE上で動く同ツールの導入により、AIがプロジェクト全体の文脈を理解した上で提案を出してくれるようになりました。「コピペ作業が激減し、開発のリズムが目に見えて変わり始めた」と振り返ります。

すでに Google Workspace を利用している組織にとって、この移行は「外部サービスを新たに導入する」という心理的ハードルがなく、極めてスムーズでした。

西原 氏：システム開発会社にとって、顧客情報や未公開システムの仕様は、最も慎重に扱うべき情報資産です。AI活用を進める上で、内部で議論したのが「顧客データをAIに渡してよいのか」というセキュリティの壁でした。

しかし、仕様を確認していると Gemini Code Assist や Google Workspace with Gemini では、入力したデータがモデルの学習に使用されない設計になっていることを知って安心できました。

西原 氏：次なる問いは、お客様への説明です。今回はすでに始まっていたプロジェクトで、途中からAIを活用する話になったので、AIを使うことに対してどういう反応を示されるのか少し不安でした。

入力データが学習に使用されないこと、セキュリティ体制、データ管理の方針を丁寧に説明した結果、「全く問題ない」との快諾を得られたことは印象に残っています。

西原 氏：はい。「仕様確認はもちろんですが、契約内容や設定項目など、こちらで確認できることは最初にやっておく。そしてお客様には丁寧に説明をすることでご理解いただく。この点がそろって初めて、現場は安心してアクセルを踏める」という教訓がここにあります。

福井 氏：AIを導入することで、開発スピードが速くなることを疑う人はいないと思いますが、それに対してレビューが同じペースでついていけるかというと話は別でした。他社もそうだとは思いますが、レビューする人は限られており、レビュー体制そのものが変わっていないため、ボトルネックの箇所が次工程へ移動した感覚があります。

西原 氏：多くの組織において、シニアエンジニアのリソースは潤沢ではないと推測しておりますが、当社ではレビュー体制の見直しを実施しました。「コードレビュー」、「テスト仕様書レビュー」などの業務について、AIを活用することで効率化をはかりました。

チーム内で共有しているレビューの観点をプロンプトとしてAIに渡し、開発したコードや作成されたテスト仕様書の抜け漏れや不足している観点を事前にチェックさせます。最終的な品質判断は人間（シニアエンジニア）が行いますが、明らかな手戻りやイージーミスを前段で弾けるようになりました。

レビューそのものを全てAIに丸投げするのではなく、その前段階のスクリーニングを任せる形です。

福井 氏：私がいちばん感じることは「Agent Mode」による作業効率化と、それに伴う「文脈設計」の重要性です。Agent Modeは、指示を受けると関連する周辺ファイルを自律的に読みに行く機能ですが、使用しているライブラリ、関数の定義場所、エラーログなどをAI自らが集めて分析します。

Google Workspace with Gemini では、毎回こちらが前提となる文脈を長文で説明していたので、AIが自動的に関連ファイルを参照してくれることで、手間が大きく減ったのはもちろんですが、回答の精度が格段に上がりました。

松尾 氏：あとは、一歩進んだアプローチとして「GEMINI.md」のようなMarkdownファイルにプロジェクトの前提（使用言語、依存ライブラリ、振る舞いの指定など）を記述してプロジェクト内に配置する運用をしています。また、MCP（Model Context Protocol）を活用して、ファイル構成や外部情報源をAIにダイレクトに接続する取り組みも試みつつあります。

AIに何を、どう渡すか。「文脈の設計（コンテキスト・エンジニアリング）」というスキルが、実務における新たな重要技能として浮かび上がっている気がします。

西原 氏：プロジェクトの途中から導入したこともあり、『工数を何%削減できた』と明確な数値で断言するのはまだ難しいです。ただ、体感としては数%レベルの短縮であっても、開発のボトルネックがコーディングからレビューに移ったという事実そのものが、工程の構造変化を証明しています。

現在はコーディング補助とテスト仕様書レビューが中心ですが、今後はさらに「上流（要件定義での業務語彙の整理）」と「下流（既存コードの保守・デバッグ時の理解支援）」へと適用範囲を広げていく構想があります。

古いソースコードを読み解く時間をAIで短縮できれば、保守運用の工数は大きく変わります。コーディングという『点』ではなく、開発プロセスの『線（前後工程）』へAIを広げていきたいと考えています。

AIによってコーディングが高速化しても、顧客に価値のあるシステムを「安定して届ける責任」は人間のエンジニアにあります。商用レベルのシステムに求められるセキュリティ設計、パフォーマンス要件への対応、インフラとの連携、障害耐性といった領域において、最終的な判断をAIに委ねることはできません。

AIが出したコードは、あくまで「動く」という最低限のラインです。それが本番環境に耐えうるか、顧客に安心して提供できるかという「見極めの力」こそが、これからのエンジニアに問われる専門性になると考えているといいます。

もう一つ、AIが代替できない領域として語られたのが「要件定義における専門性」です。

業務システムの開発において、顧客自身が自らの業務プロセスを正確に言語化できているケースは極めてまれです。「慣習的にやっているがルール化されていない」ドメイン知識を紐解くのは、AIではなく人間の役割です。

顧客の業務語彙を理解し、真の課題を言語化して要件へと昇華させる力。今後はこの上流工程のスキルが、システムエンジニアの最大の武器になっていくと考えられます。

AIが生成したコードを評価するには、そのコードが何を意味しているかを緻密に読み解く基礎知識が前提となると松尾 氏は言います。

ゼロからコードを書くスピードよりも、「AIが書いたコードの意図を正確に読み、不具合やリスクを予見できる力」の重要度が高まっているのです。

AI時代のエンジニア育成は、従来の「書く教育」から「育てる教育」へと軸足が移りつつあります。

ラテラル・シンキング社の取材から見えてきたのは、AI導入の本質が「便利なツールを1本入れること」にとどまらない、開発プロセスの変化であるという事実です。

コーディングが速くなった分だけ、次工程へのプレッシャーは強まります。文脈を渡す工夫（設計力）が回答品質を左右し、顧客の想いを言語化する力がこれまで以上に問われます。

AIが進化し、開発が加速すればするほど、人間が担う「判断」の重みは減るわけではなく、より本質的で、よりクリエイティブな領域へと、その重心が移り変わっていくのです。

今回の取材を通して、AIに任せる業務は任せて、人間がすべき重要な確認・判断は行うといった、AI活用のお手本を見たような気がしました。

あくまでも人間が主であることを忘れずに、AIを活用していただければと思います。