はじめに こんにちは、クラウドエース株式会社 第一開発部の喜村です。 「自分だけのアプリを作ってみたいけど、時間が足りない」——エンジニアなら誰しも一度は感じたことがあるのではないでしょうか。業務で培った技術力はあっても、個人開発となると要件定義からデザイン、実装、デプロイまでをすべて一人でこなす必要があり、なかなかハードルが高いものです。 しかし近年、AI ツールの進化は目覚ましく、個人開発を取り巻く環境は大きく変わりました。本記事では、Gemini・Google AI Studio・Antigravity といった AI ツールを活用し、企画からデプロイまでを効率的に進めた個人開

こんにちは。 ファインディ株式会社でソフトウェアエンジニアをしている西村です。 普段私たちが開発しているファインディのプロダクトの裏側や、開発メンバーが日々どのように働いているのかをお伝えするために、Findy Tech Talkという技術系のオフラインイベントを開催しています。 その第一弾となる 「開発メンバーが語るFindy Conferenceの裏側とこれから」を開催しました！ findy-inc.connpass.com 今回は3名が登壇し、Findy Conferenceを支える技術基盤（受付システム・GraphQL設計・権限管理）、開発前に「適切なツッコミ」を入れて最速で価値を届けるアプローチ、そしてFindy初のモバイルアプリをReact Nativeで立ち上げた経緯について話しました。 この記事では、各登壇の内容をダイジェストでお届けします。 登壇内容 Findy Conferenceを支える技術基盤の裏側 最速で価値を出すためのプロダクトエンジニアのツッコミ術 ゼロから始めた Findy 初のモバイルアプリ開発 まとめ 登壇内容 Findy Conferenceを支える技術基盤の裏側 西村は「Findy Conferenceを支える技術基盤の裏側」と題して、話しました。 Findy Conferenceとは、カンファレンスの準備・開催・運営の管理プラットフォームであり、3つの立場が異なるユーザーが使うシステムです。 主催者 参加者 スポンサー企業 異なる立場のユーザーが使うシステムであるため、各ユーザーに応じた機能を提供しつつ、円滑なカンファレンス運営を支援することが求められます。 カンファレンスを開催するまでにある課題を3つに絞って紹介します。 1つ目は、ネットワークが不安定でも止めない参加者受付機能です。 当日の会場では常にネットワークが安定しているとは限りません。例えば、多数の参加者が一斉にWi-Fiへ接続を試みるため、ネットワークが不安定になりがちです。 参加者の入場処理が失敗してしまい、記録が正しく行えなくなります。また、受付スタッフは通常の受付業務ができなくなり、カンファレンスの運営に影響が出てしまう。 そこで、Findy Conferenceでは、受付した参加者のデータをLocalStorageに保存する設計を採用しました。 navigator.onLine でネットワーク接続を検知し、復旧次第バックエンドへ同期する仕組みです。 ネットワークが不安定な環境でも、受付業務を止めることなくスムーズに入場記録を行えるようになりました。 2つ目は、Findy Conferenceに合うGraphQLスキーマ設計についてです。 冒頭で書いた通り、3つの異なる立場のユーザーが存在します。 Findy Conferenceでは、主催者・参加者・スポンサー企業の画面をサブドメインで分けています。 そのため、GraphQLのスキーマ設計においても、各ユーザーが必要とするデータを効率的に取得・権限管理できるように工夫が必要でした。 そこで、Findy Conferenceでは、次のような設計方針を採用しました。 このスキーマ設計によって、後述する権限管理を容易にし、各ユーザーが必要とするデータを効率的に取得できるようにしています。 3つ目は、GraphQLでどのように権限管理するのかについてです。 Findy Conferenceでは主催者画面にユーザーロールごとに権限管理しています。 GraphQLでは カスタムディレクティブ を使うことで簡単に権限管理をすることができます。 Findy Conferenceでは @auth のディレクティブを使い、次のように権限管理を表現しています。 module Types module Admin class Conference < Types :: Admin :: BaseObject field :id , Int , null : false field :conference_participated_users , Types :: Admin :: ConferenceParticipatedUser .pagination_type, directives : { :: Directives :: Admin :: Auth => { roles : [ FULL_ACCESS , VIEW_ONLY ] } } end end end このRubyコードをGraphQLのスキーマに変換すると次のものになり、 @auth のディレクティブが使われていることを確認できます。 """ カンファレンスID """ id : Int ! """ カンファレンス参加者情報 """ conferenceParticipatedUser ( """ カンファレンス参加者ID """ id : Int ): ConferenceParticipatedUser @ auth ( roles : [ "full_access" , "view_only" ] ) 以上、3つの課題をもとに、Findy Conferenceをどう開発してきたかを少しでも伝われば幸いです。 今後もカンファレンスを裏から支え続けるプロダクトとして成長していきます。 最速で価値を出すためのプロダクトエンジニアのツッコミ術 エンジニアマネージャーの大原が「最速で価値を出すためのプロダクトエンジニアのツッコミ術」と題し、迅速にユーザーに価値を届けるための開発前のアプローチについて紹介しました。 迅速にユーザーへ価値を届けるには、開発前にロードマップや企画に対して「適切なツッコミ」を入れることが重要だと思います。 ツッコミなしで進めると「機能が増えてリリースが遅れる」「使われない機能になる」といった問題が生じてしまいます。 そのツッコミを入れる際の重要な観点として、2つの視点を紹介しました。 1つ目は「 目的達成のための最小工数になっているか 」です。 要望があったときに、実装を想像して、仕様を分解し、どれくらい工数がかかるかを考えます。 その上で、本当に今必要か、使用頻度は高いかなどを検討し、仕様を最小限必要なものにブラッシュアップしていきます。 具体例として、Findy Conferenceでは、参加申込→当日運営→運用・拡大と機能を最小限にして段階的にリリースすることで、短期でのリリースを達成しました。 2つ目は「 三方よしになっているか 」です。 施策や機能を考えるときに、ユーザー、自社、関係者にとって良いものかを確認し、自社都合のみの施策や利害不一致を避けることが大事です。 ユーザー体験が向上し、その結果事業にインパクトが出るような施策が理想だと考えています。 最後に、ツッコミの質を高めるために大事なこととして、次の3つを挙げました。 仕様・実装を把握し、技術的な制約を即座に指摘出来るようにする ユーザーの声を聞くことで、ユーザー課題の解像度を上げる 事業モデルを理解することで、事業インパクトを理解出来るようにする 今後もこういった観点を大事にしながら、最速で価値のあるサービスを提供していきたいと思います。 ゼロから始めた Findy 初のモバイルアプリ開発 モバイルエンジニアの加藤が「ゼロから始めた Findy 初のモバイルアプリ開発」と題し、当社初のモバイルアプリ「 Findy Events 」の立ち上げについて紹介しました。 まず、私達がどのような思想でモバイルアプリ開発を始めるに至ったのか、その背景についてです。 AIの進化が目覚ましい昨今だからこそ、オフラインの場でしか手に入らない生きた情報や、かけがえのないつながりがあると考えました。 そこで、「 オフラインにおけるつながりを最大化し、エンジニア同士の知識・経験の共有を促進する 」ことをモバイルアプリが提供する本質的な価値と位置づけました。 次に、このアプリを0→1で立ち上げるために挑戦した具体的なプロセスについて話をしました。 開発当初、社内にモバイルアプリ開発の実績がなく、現役のモバイルエンジニアも自身一人だけという状況でした。 そのため、要求&要件定義や技術選定だけでなく、社内での開発環境・管理ルールの策定といった土台作りから始める必要がありました。 要求&要件定義では、エンジニアとして、企画のすり合わせから、UI・UXの議論まで深く入り込み、徹底してモバイルアプリならではの体験作りに拘りました。 これは、エンジニア向けのプロダクトを開発しているファインディだからこそ、利用ユーザー目線での解像度の高い意見を出すことができたのだと思います。 また、モバイルアプリ開発のためのメインフレームワークの選定についても紹介しました。 チーム全体のリソースを鑑みて、Cross Platformによる開発を前提としたものの、「Flutter」と「React Native」のどちらを選定すべきなのかは非常に悩んだポイントです。 次のように、国内での採用事例数やモバイルエンジニアとしての習熟のしやすさなど、いくつかの指標を比較することから始めましたが、最終的には「組織のアセット」×「モバイルエンジニアとしての自身のナレッジ」を活かせる「React Native」を採択しました。 この選定により、立ち上がりに苦労した部分もありましたが、次の2点のような大きな収穫があったため、Betterな選択ができたと考えています。 Webフロントエンドの有識者による質の高いレビューを通じて、多くの学びを得ることができた Webフロントエンドと親和性の高い技術の理解が進んだことで、他のWebフロントエンドのコードが読めるようになった また、2025年12月に、Android版をリリースし、「 Findyユーザー感謝祭2025〜今年の"しくじり"を供養しよう〜 」で実際に触って頂きました。 直接、ユーザーの操作を見たり、感想やご意見を頂けたことで、「伸びしろ」を感じることができました。 今後は、「ユーザーが迷わないUI・UXを突き詰めて、その利便性から、自然とアプリを利用してもらえる」そんなアプリへと、成長させていきたいと考えています。 まとめ 今回のFindy Tech Talkでは、Findy Conferenceを支える技術基盤、プロダクトエンジニアとしてのツッコミ術、そしてモバイルアプリ開発の立ち上げについてお話ししました。 当日、イベントに足を運んでくださった参加者のみなさん、本当にありがとうございました。頂いたアンケート結果を、次回開催の参考とさせていただきます。 残念ながら今回のイベントに参加出来なかったみなさんも、次回イベント開催時には是非ご参加ください！ 現在、ファインディでは一緒に働くメンバーを募集中です。 興味がある方はこちらからご覧ください。 herp.careers

エージェントが IDE のエラーを見逃す理由 初期のコーディングエージェントには大きな問題がありました。AI が生成したコードは一見正しく見えても、IDE が検出したエラーがエージェントには見えないのです。エージェントは追加のツールを実行しない限り、これらのエラーを認識できませんでした。その結果、エージェントは自信を持って次のタスクに進む一方で、コードベースには技術的負債が蓄積されていきました。 これは、診断情報を活用していないコーディングエージェントに共通する根本的な課題です。 現代の IDE のほとんどは、リアルタイムでエラーを検出する高度な言語解析ツールを継続的に実行しています。しかし、エージェントがこの豊富な情報に効率的にアクセスできなければ、コード検証のために（コストのかかる）ビルド/テストコマンドを実行せざるを得ません。これは実行速度が遅く、トークンを消費し、開発環境がすでに提供している詳細なフィードバックを見逃してしまいます。結果として、必要以上にリソースを消費するコード検証プロセスになってしまうのです。 診断情報なしでコードを生成するコスト エージェントが IDE の診断情報を参照できない場合、品質向上のための反復改善ができません。代わりに、正しいと思われるコードを生成して次のタスクに進んでしまいます。その結果、開発者がエージェントの品質保証を担うことになります。型エラーの手動修正（例：実際のプロパティは user.name なのに user.getName() を呼び出している）、不足しているインポートの追加（ Button を使用しているのに import { Button } from '@/components/ui/button' を忘れている）、リンティング違反の解決（未使用の変数、一貫性のないインデント）などです。これは開発速度を低下させるだけでなく、エージェントが生成したコードへの信頼を損なう結果にもつながります。 Kiro におけるフィードバックループの完結 現代の IDE は、高度な言語解析インフラストラクチャで動作しています。言語サーバーがコードベースをリアルタイムで解析します。例えば、TypeScript 拡張機能は型チェックを実行し、ESLint はコードスタイルを検証し、Java 拡張機能は即座にコンパイルフィードバックを提供します。また、CloudFormation や Terraform の拡張機能は、デプロイ前にリソースプロパティ、必須引数、リソース参照などのインフラストラクチャ設定を検証します。 この解析はコーディング中に継続的に実行され、エラーを 診断情報 として表示します。エディタで見る赤い波線や問題マーカーがそれです。これらの診断情報は、コードの正確性に関する即座で正確なフィードバックの貴重な情報源となっています。 しかし、初期の AI コーディングアシスタントは、この情報にアクセスできませんでした。代わりに、ビルドコマンド（ npm run build 、 npm test など）を実行してコードを検証していましたが、1 回の実行に数秒から数分かかることもありました。 仕様駆動開発を通じて AI コーディングに構造をもたらすエージェント型 IDE である Kiro では、エージェントに IDE 診断情報への直接アクセスを提供することで、この課題を解決しました。現在、Kiro がコードを書くと、開発者が見るのと同じエラーを即座に確認し、レビュー前に修正できます。コード品質への影響は顕著で、手動修正が減り、プロジェクトの品質基準への準拠が向上しました。Kiro のコーディングエージェントは、これらのクライアント側の診断情報と緊密に統合され、コードの理解と生成の両方を強化します。IDE を動かすのと同じ言語サーバーへの接続を通じて、エージェントはコンパイル時エラー、型警告、リンティング結果をリアルタイムで読み取り、解釈できるようになりました。Kiro がコードを生成または変更すると、この診断情報を参照して正確性を検証します。例えば、Java の不足しているシンボルや Python の構文エラーを検出し、そのフィードバックに基づいて出力を自動的に改善できます。 ワークフローの比較 従来のアプローチは、遅い反復サイクルを繰り返します。エージェントがコードを生成し、時間のかかるビルド（および/またはテスト）コマンドを実行します。ビルドがエラーで失敗すると、エージェントは修正を生成し、再度ビルドコマンドを実行します。この重いプロセスは、ビルドが成功するまで繰り返されます。 診断駆動型アプローチははるかに高速です。コード生成後、エージェントは 35 ミリ秒未満で診断情報をチェックします。行番号と説明を含む具体的なエラーが提供されます。エージェントはターゲットを絞った修正を生成し、さらに 35 ミリ秒で診断を介して検証してから、検証済みのコードで続行します。 時間差は、複数ステップのタスクで複合的に拡大します。仕様駆動開発では、Kiro が数十のタスクを実装する際、診断ツールは vibe-coding モードと比較して約 4 倍の頻度で呼び出されます。これは、各タスクの境界で受け入れ基準が満たされていることを確認する必要があるためです。これにより、実装プロセス全体を通じて継続的な検証が実現されます。 実際の効果 本番環境での使用と制御されたベンチマークを通じて、診断統合の効果を測定しました。結果は、測定可能なコード品質の向上とともに、大幅な効率改善を示しています。効率面では、ビルド/テストコマンドの削減により、コマンド実行が 29% 削減されました。この指標は、診断機能の導入前後の数日間にわたる本番環境でのエージェントのインタラクション統計を比較することで算出されました。エンドツーエンドのレイテンシを削減しながら、コード品質が向上しました。 言語に依存しないアーキテクチャ 診断システムの強みは、その汎用性にあります。各言語用にカスタム解析を構築するのではなく、Kiro は、すでに多数の IDE 機能を支えている Language Server Protocol（LSP）と拡張 API を活用しています。本番環境のデータは、これが多様な技術スタックで機能することを実証しています。例えば、TypeScript、Python、Rust などの汎用言語や、SQL、YAML、GraphQL などのドメイン固有言語の 人気のある拡張機能 は、型チェックとリンティング情報を提供します。さらに、主要なビルドツール（Maven、Make、Cargo など）やプログラマティック設定ファイル（Terraform、Kubernetes YAML、Dockerfile など）の拡張機能により、セットアップとデバッグの体験が向上します。 活用シナリオ 本番環境での使用分析により、診断ツールが既存または新規生成されたコードの品質を向上させる一般的なパターンが明らかになりました。 シナリオ 1 [構文エラー]： 分析用の Python コードベースで、エージェントがウィンドウ集計の新機能を実装します。 診断ツールは、正規表現エラー（ missing ), unterminated subpattern at position 13 ）を発見し、エージェントが修正します。再検証により、エラーが解消されたことが確認されます。診断ツールがない場合、エージェントはコマンドラインでテストを作成・実行して問題をチェックする必要があります。 シナリオ 2 [ハルシネーションの回避]： TypeScript コードベースで、Kiro がコンポーネントに変更を加え、即座に検証します。 診断ツールは、即座に 2 つの 型の不一致 （ Type 'number' is not assignable to type 'string' と Cannot assign to read-only 'executionTime' ）と プロパティのハルシネーション （ Property 'itemAge' does not exist on type 'StackProps' ）を報告します。これらの問題を基に、エージェントは修正を生成し、変更を再検証します。このパターン（生成 → 検証 → 改善）は、型エラーが一般的ですが言語サーバーで簡単に検出できる静的型付け言語で頻繁に見られます。 シナリオ 3 [型検証]： Swift プロジェクトで、Kiro が新しい機能を追加し、編集されたファイルの診断をチェックします。 診断により、ファイルの 1 つに 型エラー があることが判明します。エージェントは問題を修正し、影響を受けたファイルを再検証して、修正が正しいことを確認します。 シナリオ 4 [Infrastructure as Code — IaC]： 診断検証は、アプリケーションコードを超えて機能します。ユーザーが Kiro に Terraform 設定 のチェックを依頼します。 これは、診断システムが従来のプログラミング言語だけでなく、ドメイン固有言語や設定フォーマットでも機能することを示しています。 エージェント開発のメリット コード生成とコード検証を統合することで、診断ツールは次の改善を実現します： 認知負荷の軽減： AI が生成したコードを手動で検証する時間が減ります。Kiro が「診断エラーなし」と報告すると、開発者はより高い信頼性を持って作業を続行できます。 高速な反復： bash コマンドの実行頻度の削減は、具体的な時間の節約につながります。 コード品質の向上： 問題が発生した時点で即座に対処することで、よりクリーンで高品質なコードが実現します。 まとめ IDE 診断情報は、コード検証のための重要な即時フィードバックの源です。診断情報を Kiro のエージェントワークフローに直接統合することで、初期のコーディングエージェントが抱えていたコード生成と検証の間のギャップを解消しました。 結果は明確です。コマンド実行の削減、高速な検証サイクル、多様な技術スタックにわたるコード品質の向上を実現しました。エージェントに遅くてコストのかかるビルド/テストコマンドに依存させるのではなく、Kiro は、すでに現代の IDE を支えている高度な言語解析インフラストラクチャを活用します。TypeScript の型チェックから Terraform の設定検証まで幅広く対応しています。 この診断駆動型アプローチは、エージェントのフィードバックループを高速化します。盲目的にコードを生成して動作を期待するのではなく、Kiro は開発者が見るのと同じエラーを確認し、積極的に修正します。結果として、手動修正が少なく、開発者の信頼を得られるコードが実現します。 この違いを体験する準備はできましたか？ Kiro を無料で始めて 、診断機能を備えたエージェントが開発ワークフローをどのように変革するかを確認してください。 Discord のコミュニティに参加して、フィードバックを共有し、質問をし、AI 支援コーディングで開発している他の開発者とつながりましょう。 謝辞 クレジット（アルファベット順）：Al Harris、Nathan Jones、Nikhil Swaminathan、Siwei Cui、Varun Kumar