AI 時代、エンジニアは何で価値を出す?【Script Jam vol.5 登壇レポート】


こんにちは、フロントエンドエンジニアの下條です。

2026年7月24日に「Script Jam vol.5 – フロントエンドを中心としたエンジニアの交流イベント –」が開催されました。そこで「AI時代、エンジニアは何で価値を出す?〜 技術だけじゃない強みを考える 〜」というテーマで、 LT 枠で登壇させていただきました。その様子を登壇レポートとして残しておこうと思います。

登壇内容

「AIにRailsの仕様を洗い出させて品質向上を目指す」というタイトルで、10分の LT をさせていただきました。

前半では、モノリシックな Rails アプリケーションを Rails API と React Router v7 のフロントエンドに分離する、リアーキテクチャのプロジェクトを題材にしました。既存画面の機能を変えずに移行するため、移行対象画面の仕様を洗い出して Issue に落とし込み、OpenAPI でスキーマを定義してから、UI・ロジック・API の実装と受け入れテストを進めています。

仕様がコードの中にしか存在しない

このプロジェクトでは、移行した画面で実際にバグを起こしてしまいました。退会済みユーザーかどうかを退会日時の有無で判定していたため、一度退会してから復帰したユーザーまで退会扱いにしてしまったのです。

実装時もレビュー時も見落としてしまったのは、退会をどう判定するかというロジックが Rails のコードの中にしか存在しなかったからでした。OpenAPI のスキーマや現行画面を確認するだけでは、コードに埋もれた状態遷移や条件分岐まで拾いきれません。

Rails のコードから仕様を掘り起こす

そこで、Claude Code のスキルとして rails-explorer を作成しました。関連する Rails コードを横断的に調査し、状態遷移・条件分岐・ビジネスロジックを構造化した仕様書として出力するスキルです。

仕様書を作ること自体が目的ではなく、コードの中にしかないロジックを、新しい実装と比較できる形にすることが目的です。生成した仕様書を共通言語として、設計時の意思決定や実装時のインプットに使えるようにしました。

さらに、この仕様書を開発フローの複数の工程で活用しています。

  1. 設計時: Rails コードから仕様を洗い出し、状態遷移や条件分岐を可視化する
  2. レビュー時: 仕様書・現行 Rails・新実装を突き合わせ、ロジックの差分を AI に確認させる
  3. 受け入れテスト時: 仕様書からテスト観点を洗い出し、エッジケースを含めて確認する

この仕組みによって、冒頭の退会判定のようなロジック差分や、API エラーがユーザーに通知されていない箇所などを、レビューやテストの段階で検知できるようになりました。

AI に任せる範囲を広げるために

後半では、AI に任せる範囲を広げた結果、「これで問題ない」と判断するために大切だと感じたことを、次の3つに整理してお話ししました。

  1. レールを敷く: どの工程で、何を渡して、何を出力させるかを決め、AI をワークフローに組み込む。出力結果を見ながら、そのレール自体も継続的に改善する
  2. コンテキストの外側で決める: 「変えるもの・変えないもの・落とすもの」のように、プロダクトやユーザーにとって何がよいかを考える判断は、人間が担う
  3. 最後は責任を持つ: AI が実装したものをそのまま通すのではなく、自分の PR を説明できる状態にし、自分の手でも画面を確かめてリリースまで進める

AI によって作業の一部を任せられるようになっても、仕様をどう捉えるか、プロダクトとして何を選ぶか、出力にどう責任を持つかは人間の仕事として残ります。今回の発表では、実際の開発フローに AI を組み込みながら、その境界をどのように考えているかを紹介しました。

スライド

当日のスライドはこちらで公開しています。

感想

「AI時代、エンジニアは何で価値を出す?」というテーマへの参加者の皆さんの関心はとても高く、他の登壇者の発表もそれぞれの現場の実感がこもったもので、聞いているだけでも多くの気づきがありました。

参加者同士の情報交換・ディスカッションの時間には、参加者がランダムにテーブルを囲み、発表への感想やそれぞれの現場での AI 活用について意見を交わしました。「仕様がドキュメントに残っていない」「AI の出力をどこまで信じるか」といった共通の課題を持つ方とも、共感し合うことができました。

AI によってエンジニア未経験者でもある程度のものをつくれるようになり、フロントエンドとバックエンドの境界も曖昧になってきました。さらに、実装の速度が上がった一方で、実装そのものよりも、生成されたものが仕様やプロダクトの意図に沿っているかを確認するレビューのコストが大きくなっているという実感も共有されました。実装する領域が広がり、速度も上がるからこそ、何をつくるかを考え、出力を見極める上流・プロダクト視点が、これからのエンジニアにはこれまで以上に求められるのだと、参加者の方々との会話を通じて実感しました。

また、AI の実務への取り入れ方や、個人の活用度には二極化が進んでいるという話も挙がりました。ハーネスやワークフローを組み込んで日常的に活用しているプロジェクトがある一方で、組織として取り組んでいても、プロジェクトへの浸透度にはまだ差があるのが現実なようです。

発表をきっかけに、異なる現場の方々と会話し、自分の考えを更新できたことが、今回登壇して一番良かったことでした。これからも登壇という形で考えを整理し、外に出していきたいです。

交流イベントとしての空気感もとても温かく、初参加でも話しかけやすい雰囲気でした。運営の皆さん、参加者の皆さん、ありがとうございました!

Gaji-Labo は フロントエンドのAI開発の実績と知見があります

急速に進化するAI技術、進まないUIとの統合…。 ユーザー体験を損なわずにAIを導入したいと考えながら、実装や設計に悩み、開発が停滞している。 そんな課題を抱えるプロダクトや開発チームを、私たちは数多く支援してきました。

フロントエンド開発の専門企業である Gaji-Labo は、AIチャットや自然言語処理UIなどの設計・実装において、AIの特性を踏まえた体験設計・UI開発・運用まで、フェーズに応じたサポートが可能です。

フロントエンドでのAI導入を相談する!


投稿者 Takumi Shimojo

フロントエンドエンジニア。 通信会社でデザインシステムの構築や React / TypeScript の開発経験を経て、Gaji-Labo に参加。 Next.js / TailwindCSS / Chrome Extension / Figma が好きです。 デザイナーとエンジニアの両者の目線でプロダクトを作れる人材を目指しています。