はてなブックマーク

はじめに Cursorが巻き起こしたAI搭載エディタブーム。ああ、課金しているJetBrains製エディタを使いたいのに、、、(この物語はフィクションです)そんな時に現れたのはエディタもターミナルも強制されないCLIベースのAI agent Claude Code様。ああ、あなたはこんなにも私の実装したいことをわかってくれる上にエディタの自由まで取り戻してくださるのですか!おぉ、ジー◯ス!! というわけで、VSCodeやCursorといったエディタが主流の中、最近個人的にZedエディタをメインにして快適に開発できているので、チームの中で布教する教祖になっています。あなたもZed教に入信しませんか?入会料は無料です。(ツッコミどころをふんだんに散りばめたので心の中で拾っていただけると幸いです) Zedとは Zed は、Rust製の高速かつモダンなコードエディタです。AtomやTree-sit

はじめに はじめまして、株式会社グロービスの池邊と申します。QAエンジニアとして6年ほど、グロービスのGLOBIS学び放題やグロービス経営大学院 ナノ単科といったプロダクトのQAを担当しています。 「AIがテスト設計を変えるかもしれない」 そんな期待と不安が入り混じった中で、私は一つの実験を始めました。AIコーディングアシスタントの「Cursor」と、私たちの仕様書が眠る「Notion」をMCPで連携させ、テストプロセス全体を効率化できるかどうかを試してみました。 グロービスのQAチームは、開発プロセスに深く関わっており、各プロダクトチームと連携しながら品質向上に取り組んでいます。日々の業務の中で、私はテスト設計における「属人化」や「考慮漏れへの不安」、そして「ドキュメントと実装の間の断絶」といった課題に、より効果的なアプローチがないかと模索していました。 本記事では、その具体的なプロセス

1 年以上前から、チームメンバーの提案で Container/Presentational パターンを現代的にアレンジした設計を導入し、徐々に改良を重ねてきました。 Hooks が普及して、関数コンポーネント内で状態管理や API 呼び出しができるようになって便利になった一方で、いくつかの困りごとがありました。 「見た目だけテストしたいのに、なんで API モックの準備が必要なんだろう...?」 「このコンポーネント、何の責務を持ってるんだっけ...?」 「新しいメンバーが入ったとき、どこを変更すればいいか分からない...」 確かにファイル数は Hooks だけの時より増えてしまいますが、責務分離により各ファイルが単純になり、特にチーム開発では「単純明快なルール」の方がうまく機能することが分かってきました。 そこで、一時期「もう古い」と言われがちだった Container/Presenta

このデータ重複は、開発現場で地味ながらも厄介な問題を頻発させていました。 データ不整合のリスク: ユーザー情報更新時に片方のテーブルしか更新されず、データが食い違う危険性。 開発効率の低下: 「どちらのnameを参照するのが正だっけ?」という確認が毎回発生し、開発やレビューの効率を阻害。 これらの課題を根本から解決するため、usersテーブルから重複しているnameとemailを削除し、auth_usersにデータを集約することを決断しました。 統合戦略:段階的なアプローチが鍵 データ統合のような影響の大きい変更は、一度に行うとリスクが非常に高まります。そこで、私たちは安全性を最優先し、段階的に進めるアプローチを取りました。 ステップ1:delegateでシンプルな参照を片付ける まず、最もシンプルな参照箇所を修正するため、Railsのdelegateメソッドを活用しました。 # app/

前回の記事では、レビュアーとして利用していたDevinをRoo Codeで置き換えた結果や設計、今後の展望などをご紹介しました。 今回の記事では、その具体的なプロンプトやエージェント、ワークフローの実装方法をチュートリアル形式で解説していきます。 Roo Codeのようなツールをフレームワーク的に活用することで、コードを一行も書かずに、自然言語で実装することができます。今後これらの実装はさらに簡単になっていくことが予想されますが、この記事では、その未来を少し先取りする形で、Roo Codeを用いた具体的なAIエージェントとワークフローを「誰でも実装できる」ことを目指し、チュートリアル形式でご紹介します。 事前準備 ※(注記)既にVSCode & Roo Codeを利用している方は、事前準備を全てスキップ可能です OpenAI(またはAnthropic, Google, etc)のAPIキーを取得

レビュー精度:対象PRへの指摘のうち、正しかった指摘割合の平均 再現率:Devinの良い指摘を再現した割合 レビュー内容の精度やコストから、予想以上にDevinのレビュー精度を上回っていることがわかります。 また、レビューの速度についても、Devinと同等 / ほとんどの場合、Devinよりも高速でした。(ローカル環境がそのまま使えるため、環境セットアップの時間が省略されているのもポイントですね) 定量その2 サイクルタイム レビュー精度という数値のみを追いかけてしまうと、「指摘は鋭いがレスポンスが遅い」といった数値ハック・局所最適に陥るリスクがあります。 開発フロー全体の健全性 を測るために、2 つ目の軸としてサイクルタイム という健康指標を導入しています。これから組織で展開する際に、精度にのみ注目し他を見落とすことがないよう、合わせて指標を追っていきます。 計測には technuma

この記事はCursor (with Gemini 2.5 Pro) に「読んでいて楽しくドキドキするように書いてください」とお願いして書いてもらった文章に、少しだけ手を加えたものです。そのためやや誇張された表現になっていますが、技術的な内容は事実に基づいています。 突然鳴り響いた警報 「おかしい。これはどう見てもおかしい」 ある朝、AWS BillingのCost Anomaly Detection機能から届いた通知を見て、私の顔から血の気が引きました。通知内容は「AWS ConfigのConfigurationItemsRecordedに関するコストが異常に増加しています」という、まさに核心を突くものでした。dev環境のコストグラフを見ると、AWS Config料金が突如として跳ね上がっていたのです。 before: Config料金は多くて15ドル/day、基本は10ドル未満/day af

チューニング チューニングにあたっては、大きく以下の3点を重視しました。また、これらを管理するための「プロンプト」と「Knowledge」の使い分けも工夫しています(後述します)。 レビュー時のお作法を守らせる(AIは細かい作業に分解することが苦手な場合が多いため、ファイル単位でのチェックや処理の追い方といった手順をインプットしています) Railsアプリケーションにおける理想的な設計パターンをレビュー時に定着させる グロービス特有のドメイン知識・運用ルールを活用させる これらの観点で情報整理を行うことにより、「一般的に望ましい設計や実装方法」だけでなく、「自社特有の事情を反映した指摘」を自然に提示できるようになります。 また、知識の初期構築に多くの時間を割くことなく、実際に使いながらDevinにフィードバックを行い徐々に精度を高めていけるため、最初は小さく始めることを意識しました。 Kn

はじめに 前回は Cursor の Project Rules 活用と改善 という記事を書かせていただきました。 今回は、私自身が普段実施している、より具体に迫った Cursor の活用方法をお伝えしようと思います。 私と私のチームのメンバーの一部が活用し始めた手法であり、すべてのPJでワークする確証はないため、ネタ枠の気持ちでお読みいただけると嬉しいです。 また、私が一から考案したものというよりは、X や Cursor の Forum で議論されていた内容を、抽象化し、実践に落としたものです。(※(注記)参考文献を参照) 私の関わっている中規模程度のプロジェクトにおいても、とりわけバックエンド開発(Rails + GraphQL)においては、今回の手法を使い、8~9割ほどのコードは Cursor で生成されたものを使うことができています。 手法の一つとして、参考になる部分があれば幸いです。 Cu

ちなみに来月は利用量がかなり増えそうな見込みがすでに立っており、Devinの上限を超えそうな状況に頭を抱えています。 定性面について(AIサマリー) おすすめの使い方 おすすめの使い方についてアンケート結果をAIサマリー丸っとかけた結果について以下に共有したいと思います。最初はSlackから呼び出す使い方が多かったですが、レビューに組み込むであったりPOやQAのみなさんが使い始めてから活用事例としては多く出てきた印象があります。 1. コードレビュー・PR関連の活用 DevinはコードレビューやPR作成で特に役立つとの意見が多く見られました。 「コードレビューでは特に効果を発揮している印象です。小規模なリファクタはスムーズに行えるため、かなりありがたいですね...!」 「PRレビューでは非常に有用だと感じています。確認すべき観点を knowledge に蓄積することで、確認漏れや同じミスを防げ

この記事はなに? この記事では、現時点でのAIツールで確実に恩恵を受けるためには、 スコープを小さくすることで確実性を上げることが重要であるという考え方を紹介します。 扱わないもの ツールの機能説明、チャレンジングなハック的アプローチのAIに自由に編集・参照させている memories.md ファイルや大きなタスクの context を自然言語でまとめておく issues.md ファイルや.cursor/rulesをAIに自動で修正してもらうなど AI要約 丸投げせず、小さく刻むのがカギ! 💡 3つのポイント 1️⃣ プロンプトを工夫 - 明確に指示するが、手間をかけすぎない! 2️⃣ .cursor/rules でルールを設定 - 一貫性を保つ✨ 3️⃣ タスクを小さく分割 - 実装計画 → テスト → 実装 の3ステップ! ツールの進化を見つつ、最適な使い方を模索しよう💡 自己紹介

1. Project Rules とは Cursor の Project Rules(v0.45~) は、Cursor Chat/Composer での対話において、必要なコンテキストを与えるための機能です Cursor > General > Project Rules から設定できます。 これまで、Cursor では Rules for AI, .cursorrules といったカスタムルールを用いて、プロンプトのコンテキストを与えていました。 Project Rules は、これらのカスタムルールに加え、より具体的かつ個別にコンテキストを与えることができる機能です。 もちろん、Rules for AI や .cursorrules を併用することも可能です。 各ルールの特徴 Rules for AI Cursor のアプリケーション自体に設定するカスタムルールです。 Cursor で

3行で できるだけ「文字列指定」ではなく「キー指定」を使いましょう where句にてテーブル名を指定するのは極力避けましょう activerecord-pretty-comparator gem を使うことで、文字列指定を使わざるを得なかった > もキー指定で書けます はじめに この記事では where('ends_at > ?', Time.current) のような書き方を「文字列指定」、 where(starts_at: ...Time.current) のような書き方を「キー指定」と呼びます 株式会社グロービスのslackにかみぽさんにJOINいただいており、不定期にRailsの困りごとを 壁打ち/相談 させていただいています この記事に出てくるコードは、実際のプロダクトコードをベースにしつつ問題を再現する最小のケースとして書いてみました Kaigi on RailsにCFP出した