はじめに こんにちは。Re:Career採用で26新卒としてABEMAに入社し、広告配信システムの開 ...

はじめに 株式会社 mediba でフロントエンドエンジニアをしている中畑です。 弊社では Nuxt.js から Next.js への技術リプレイスプロジェクトが進行中です。この記事では、 Claude Code を活用した技術リプレイスの現状と課題をお伝えします。 ! 要約 ハーネス(ルール・コンテキスト・フィードバック・スキル)を整備し、開発フローをスキル化して Claude Code による技術リプレイスを進めている 移植精度の向上や高速化、属人化の防止というメリットがある一方、技術負債の移植や開発者の「理解負債」というデメリットが生じている 現行システムに実際に触れる、モッ

こんにちは。ファインディ株式会社でプリンシパルエンジニアをしている戸田です。 2026年8月5日(水)に、Findy AI Meetup in Fukuoka #7を福岡で開催しました。当日参加くださったみなさま、ありがとうございました！ findy-inc.connpass.com 今回のテーマは「AI開発の"今まで"と"これから"を語り尽くそう」です。 皆さまの熱いご支援のお陰で、Findy AI Meetup in Fukuokaは今回で1周年を迎えました。節目となる今回は、AI開発のこれまでを振り返りつつ、これからを見据える内容の登壇が揃いました。 この記事では、ファインディメンバーによる2つの登壇を振り返ります。 Findy AI Meetup in Fukuokaについて え？フロントエンドエンジニアのワイがインフラも！？ 「開発は一人です」から始まった新規サービス 武器は社内に揃っていた 2つの誤算 変わったこと、変わらなかったこと VibeCodingからAgenticWorkflowへ 速くなったのは開発工程ではなくコード生成 レベル1「速く作る」— VibeCodingと現場の課題 レベル2「正しく作る」— 協働から委任へ ターミナルへの回帰 — 開発環境そのものが変わった 順番を間違えない — 基本が先、AI活用は後 まとめ Findy AI Meetup in Fukuokaについて Findy AI Meetupは、ファインディのエンジニアが主催する技術系オフラインイベントです。 生成AIやAIエージェントの活用を通じた開発生産性の向上をテーマに、社内での実践事例の紹介やエンジニア同士の交流を目的としています。 福岡での開催は今回で7回目、そして1周年となりました。この1年でAI開発の景色は大きく変わりましたが、回を重ねるごとに参加者同士の交流も深まり、福岡のエンジニアコミュニティとして根付いてきたことを実感しています。 え？フロントエンドエンジニアのワイがインフラも！？ まずは、フロントエンドテックリードの新福による登壇です。フロントエンドエンジニアが生成AIとともに専門外の領域へ越境した実体験をお話ししました。 speakerdeck.com 「開発は一人です」から始まった新規サービス きっかけは、新しいサービスの立ち上げでした。ファインディでは生成AI時代のプロダクトが次々に生まれており、立ち上げ期のプロダクトは少数精鋭・スピード重視で職種の枠に囚われないフルサイクル志向となることが多いです。 そんな中で、新規サービス開発を任されることになりました。ただし、人員の確保が難しいため開発は一人です。これまでなら、良いアイデアがあっても専任のメンバーが足りなければ諦めるしかありませんでした。 しかし、生成AI時代ならそれも可能かもしれません。そう考えて、フロントエンドはもちろん、バックエンド、そして完全に初見のインフラ（AWS/Terraform）まで、全部を一人で担当することにしました。 領域 内容 フロントエンド 本来の専門領域 バックエンド Honoを採用、テーブル設計などは専門メンバーによるレビュー インフラ（AWS/Terraform） IAM、VPC、ECS、RDSなど、SREチームによるレビュー 武器は社内に揃っていた 挑戦を支えたのは、弊社SREチームが整備していた社内資産でした。Terraformやバックエンド側APIのスターターキット、社内標準の構成を再利用可能な形にまとめたAWS汎用モジュール、そして環境構築を手助けするエージェントスキルです。 これらの社内資産を活用し、社内の作法に沿ったやり方でAIが書き、人間がレビューして判断するという流れで開発を進めました。 結果、アプリケーション（フロントエンド+バックエンド）に約1ヶ月、完全に専門外のインフラに約1ヶ月、合計約2ヶ月で一人で作り上げることができました。 2つの誤算 一方で、やってみて見えてきた誤算もありました。 1つ目の誤算は「時間」です。 当初は生成AIによる開発期間の短縮を見込んでいましたが、実際は専門メンバーやSREチームによるレビュー待ち、そして試行錯誤のたびに発生するTerraformの反映待ちが作業時間の相当部分を占めました。フィードバックを待つ必要があるものはAIでの高速化が難しく、AIが圧縮したのはあくまで「人間が考える時間」だったのです。 2つ目の誤算は「理解」です。 自分で書いていたときは、仕組みや依存関係を把握しなければそもそも書けないため、両者は常にセットで、疑う機会すらありませんでした。ところが生成AIに書かせると、内容を把握せずとも書けてしまいます。そのまま進めると、なぜ動くか、あるいは動かないかがわからず、インフラでこれは致命的となり得ます。だからこそ、浮いたはずの時間の一部を使って、生成AIの出力を読んで理解する時間を確保する必要がありました。まさに「思考は外注できるが、理解は外注できない」を実感した経験となりました。 変わったこと、変わらなかったこと 生成AI時代では、着手するまでの意思決定コストが下がりました。これまで人員確保がネックになっていた部分も、生成AIが実装や意思決定のコストを下げたことで、諦めなくても良くなったのです。 逆に変わらなかったのは、最終的な責任を持つのは人間だということです。生成AIの出力を判断するためには、結局のところ実装者自身が仕組みを理解し、専門知識を身につけなくてはいけません。 生成AIの発展により、越境しやすい環境になりましたが、専門知識の価値は変わりません。「理解は外注できない」という事実をしっかりと頭に留め、基礎を大事にするというのがこの挑戦から得られたものでした。 VibeCodingからAgenticWorkflowへ 続いて戸田からは、ファインディがこの1年で歩んできたAI活用の変遷を「VibeCodingからAgenticWorkflowへ」と題してお話ししました。 speakerdeck.com 速くなったのは開発工程ではなくコード生成 出発点は、AIを導入して見えてきた現実です。AIが高速化したのは「コードを書く」工程だけで、レビューや検証といった「正しいか」の確認に時間がかかり、開発フロー全体のスループットは横ばいのままでした。これは体感ではなく、可視化した数値が示した事実です。 速くコードを書けても、理解せずに生成されたコードは質が落ち、レビューでの指摘が増え、結局速さの恩恵が消えてしまう。この連鎖を断ち切るために、ファインディでは「正しい作り方と手順」をハーネス化する開発フロー改革に取り組み、AI活用レベルを3段階に分けて段階的に進めてきました。 レベル テーマ 内容 レベル1 速く作る コード生成の自動化 レベル2 正しく作る モノ作り全体の再設計 レベル3 必要なものを作る 他領域への越境 先ほどの新福の登壇は、まさにこのレベル3「他領域への越境」を体現した実例です。ここからは、そこへ至るまでのレベル1とレベル2の道のりを紹介します。 レベル1「速く作る」— VibeCodingと現場の課題 レベル1は、VibeCodingでコードを生成し、Pull requestを作成してレビュー依頼を投げるところまでをAIで自動化するフェーズです。 ただしこのフェーズでは、現場で次のような課題が起きていました。活用レベルの個人差が大きい、AI出力の合否判断ができないまま理解せずにレビュー依頼を出してしまう、Pull requestの質が低下してリードクラスのレビュー負担が増える、そしてAI主導になり人間側の理解が追いつかない「AIに使われている」状態です。 この課題に対して、まずAIが参照するドキュメントやルールを整えるガードレール整備を行いました。READMEやプロジェクトドキュメントで前提や運用ルールを記述し、AGENT.mdやrulesでコード規約・命名規則・テスト方針をAIに参照させ、よくある作業はカスタムコマンドとして規格化する。ガードレールがあって初めて、AIは「使い物になるコード」を出してくれます。 レベル2「正しく作る」— 協働から委任へ レベル2では、正しい方法と手順を用意して、AgenticWorkflowに委任します。 このフェーズの課題は、要件を実現する手順がAIフレンドリーではないことでした。タスクの粒度や手順を誰も決めておらず、生成AIへ何を渡せば精度よく動くかが属人化している。つまり、明確で簡潔なステップ構造、AIに渡す「設計図」が必要だったのです。 そこで、AIが処理しやすい単位へのタスク分解、構造化された設計図を親子Issueで表現するIssue作成、そしてAIと人間でレビュー領域を分割するコードレビューの再定義に取り組みました。人間はレビューで「作り方と実現方法が合っているか」を検証し、設計図にフィードバックする。タスク分解の品質が、そのままアウトプットの品質を決めます。 このレベル1からレベル2への移行は、AIとの関係性の変化でもあります。登壇では「協働」して書くVibeCodingと、「委任」して任せるAgenticWorkflowの違いを次のように整理しました。 観点 AIとの協働（レベル1 VibeCoding） AIへの委任（レベル2 AgenticWorkflow） 関係性 隣で並走するパートナー タスクを任せる実行者 人間の役割 ハンドルを握る運転手 行き先を決める指揮者 AIの役割 助手席のナビゲーター 自走する実行エージェント 任せる粒度 1行〜1関数 タスク/PR/フロー全体 AgenticWorkflowとは、人間がゴールと制約を与え、AIエージェントが計画・実行・自己検証までを自律的に進める開発スタイルです。ゴール指向、計画と分解、ツール使用、自己検証ループという4つの自律性を備えており、人間の仕事は成果物に対するレビューへと移っていきます。 ターミナルへの回帰 — 開発環境そのものが変わった AI委任の並列性は、開発環境そのものも変えました。2026年からファインディではメインツールがIDEからターミナルへ移行しています。 1ウインドウで1タスクずつ進めるスタイルから、複数ウインドウ・ペインで同時にAIへ委任するスタイルへ。IDEの役割は「すべての開発作業を行う場所」から「広域に渡るコードリーディングで理解を深めるとき」に使うものへと変化しました。AIに並列で任せる前提に合わせて、開発環境が「並列委任しやすいもの」へ変わってきているのです。 順番を間違えない — 基本が先、AI活用は後 最後に強調したのは、順番を間違えないことです。土台が弱いと、ガードレールもAIも成果を出せません。 統一規約・型定義・テストコードといったコード品質をまず充実させ、Pull requestの粒度やレビュー文化といった開発文化を育てる。その上でガードレール・ハーネスを整備し、最後にAI SkillやPluginを横展開して組織全体でAI活用を加速させる。基本が固まってからAI活用を載せる、この順番が重要です。 AI時代の本丸は「速く作る」ではなく、「正しく作る」「必要なものを作る」への段階的な越境です。人間の役割はコードの読み書きから、何をどう作るかの判断へと上流に移っていきます。それでも、やるべきことはAI以前から変わりません。基本の徹底こそがAI活用の大前提なのです。 まとめ 今回のテーマは「AI × これまでと、これから」でした。 2つの登壇に共通していたのは、AIによって変わったことと変わらないことの整理です。変わったのは、AIに任せられる範囲です。職種の壁を越えることが現実的な選択肢になり、協働から委任へと関係性も進化しました。変わらないのは、理解と責任が人間に残ることです。AIにどれだけ委任しても、出力を判断する専門知識と基本の土台がなければ、AIは成果を出せません。 この1年でVibeCodingという言葉が当たり前になり、いまはAgenticWorkflowへの移行が始まっています。これからも変化は続きますが、基本を固め、理解を手放さず、段階的に任せる範囲を広げていく。この姿勢は変わらないと考えています。 なお、登壇でも紹介したファインディの開発知見は、ドキュメントサイト「Findy Library」で公開しています。開発の基本からVibeCodingやAgenticWorkflowの実践まで、今回の登壇のベースになっている知見をまとめていますので、ぜひ活用してみてください。 lib.findy.co.jp そして早くも次回開催が決定しました！2026年11月12日(木)に開催予定です。次回は「AI × 並列開発 AIに委任して変わりゆく開発手法」と題しまして、AIへの委任で変わっていく開発手法について語り合う会にしたいと思っています。今回の登壇でも触れた「並列委任」をさらに深掘りするテーマです。ぜひご参加ください。 findy-inc.connpass.com ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers