こんにちは、株式会社アシュアード プロダクトマネージャーの鈴木です。 Assured事業本部のプロダクトチームでは、プロダクト開発の生産性向上のため、積極的に生成AIを活用しています。 今回は、プロダクトチーム内で実際に行われた生成AI活用の事例を5つご紹介します。
Cursorによる文言チェック（デザイナー長尾）
デザイナーとして、新機能開発における文言作成にCursorを活用した事例をご紹介します。
当時開発していたのは、既存プロダクトに追加する新機能でした。初見のユーザーからすると少し理解しづらい機能であることに加え、既存で使っている文言を踏襲する必要があり、文章としての一貫性を保ちながら、新規機能の説明をする難度が高く時間がかかっていました。
そこでCursorに、文章の提案と既存の文章を参考に文言レビューをしてもらいました。伝えたいことを箇条書きでずらっと書き出し、別ページで使われている文言を集めたファイルを参照させてプロンプトに渡すと、Cursorが既存のトーンを踏まえた提案をしてくれます。
普段コードを触らないのでセットアップのハードルは正直ありましたが、セットアップのフォローにもAIを活用することで「意外と大変じゃない」と気付けました。それ以来、Cursorを積極的に活用するようにしています。
この活用でありがたいのは、トーンの整合性まで見てくれることです。「文末に句点をつけるのか」「ここは言い切る形でいいのか」など、細かい表現で悩むことも多いのですが、Cursorは全体を見ながらレビューしてくれるので助かっています。
プロダクトデザインでは一貫性を大切にしています。各画面で文言が統一されていることはユーザーを混乱させないためにも重要だと考えています。
今後は表現の一貫性をさらに高めるために、コンポーネント単位でのルール作成を考えています。「ボタンだったら体言止めにする」など、各コンポーネントで異なる表現やトーンのルールを学習させることで、画面全体の文章を包括的に考えてもらえるようにできないかと期待しています。
Claude Codeが支援するライブラリリーディング会を実施（エンジニア鈴木）
エンジニアチームで新規に利用し始めたライブラリの実装理解を深めるため、Claude Codeを活用したソースコードのリーディング会を実施しました。
このときはReact上でFormに関する状態を管理するための edmundhung/conform を対象に実施し、実際のコードの処理の流れを理解するためにClaude Codeを活用しました。
リポジトリをクローンしてClaude Codeを起動し、「エントリーポイントとなっているメソッドからの処理の流れを追ってください」と具体的に質問します。エントリーポイントから処理がどう流れていくかを追わせることで、ライブラリ全体の構造が見えてきます。実際にFormのバリデーションが行われるタイミングや、メソッドに渡せるパラメータにどのようなものがあるか、処理を追いながら深ぼりして理解することができました。
ライブラリの核となっている用語を説明させるのも非常に有用でした。例えばこのライブラリでは"Intent"という概念が頻繁に使われていましたが、最初は何を指しているのかわかりませんでした。「Intentがどういう概念で、どの処理で使われているのか」をClaude Codeに解説させることで、それがFormの状態を更新するためのアクション（ReduxなどでいうAction）を指すことがわかり、そこからさらに全体の理解が進みました。
全く知らないコードベースを読み解こうと思うとなかなか労力を要するものですが、Claude Codeの助けがあれば馴染みのないライブラリのコードも読み解けるようになるので、気軽にコードを読んでみることができておすすめです。
Claude Code GitHub Actionsによる自動レビュー（SRE 大橋）
Claude Code GitHub Actions を活用して AI Bot による自動レビューを行うようにしました。
もともとの発端は、最近起こった障害のポストモーテムでの振り返りにおいて、原因となったコードの処理の間違いが「GitHub Copilotが指摘していた内容だった」ことでした。それなら、AIレビューを必ず通すようにすればいいのでは──と思い、ちょうど Claude Code GitHub Actions がv1にアップデートされたこともあって、使ってみることにしました。
それ以前にもAIによるレビューをGitHub Actionsで行なっていましたが、単純にPull Requestを読み込ませてレビューさせるだけでは、変更コード量によってトークン超過で動かなくなる問題や、差分以外のコードが読めずに良い指摘がもらえない問題がありました。さらに、レビューが1つの長大なコメントにまとめられてしまい、「内容は正確だが読みづらい」問題もありました。
Claude Code GitHub Actions v1で導入されたエージェントモードを使うことで、これらの課題を解決できました。エージェントモードでは、コンテキストに収まるようにソースコードを少しずつ読ませながら関連するコードも含めて理解させたり、過去のインラインコメントがまだ対応が必要なのかどうか判断させたりした上でレビューするようにしました。
レビュー用のプロンプト自体もAIに書かせました。「汎用的に使えるもので、こういう指摘が欲しい」「細かいチェックではなく、標準化されたプログラミング原則に沿って考えてほしい」などと伝え、DRYやSOLIDといったデザインパターン、セキュリティやパフォーマンスに関する指摘を行うプロンプトを生成しました。
チームへ展開する際には、使っている人のPull Requestを見に行って、「レビュー内容がおかしい」という反応をしている人のものを見て、共通点を探して細かく改善していきました。
他のチームメンバーからは「LLMの出力は安定しない面もあるので、運用で回避しないといけない部分もある。原因について会話しつつ改善のコミュニケーションが取りやすいのはありがたかった」と嬉しいコメントももらっています。
Claude Skillsを使った動作観点の洗い出し（エンジニア田所）
LLMの特性を考慮して、動作確認のための観点の洗い出しにClaude Skillsを活用した事例をご紹介します。
人間の物事の考え方を、目の前の事象を捉える「認知」、それを使って筋道立てて考える「思考」、そして外の世界に作用させる「行動」の3フェーズと捉えています。
LLMに当てはめると、彼らは最初の「認知」と最後の「行動」が特に得意ですよね。 コードの把握や既存仕様の理解といった認知面、そして実際のコードの記述という行動面では、AIは圧倒的なスピードを発揮します。
自身の活用の仕方を振り返ると、コードを書くような「行動」ばかりであるという気づきがありました。目の前の事象を捉える「認知」には、まだ活用の余地がありそうでした。
そこでやってみたのは、Figmaのモックから動作確認項目を洗い出すこと。最終的な動作確認にも使えるし、実装時にも「そういえばこの機能がここにあった」と二度手間が少なくなります。リソースとして画像を読み込ませたかったこともあり、ちょうど登場したClaude Skillsを活用することにしました。
具体的な活用方法としては、動作確認項目の洗い出しを行うSkillを定義した上で、そのSkillを利用するよう明示的にプロンプトで指示しながら、Figmaのスクリーンショットを添付して動作確認項目を出力させています。画面名称や画面から読み取れない仕様などはプロンプトに追記しつつ、出力はスプレッドシートに落とすためTSV形式で「画面、事前条件、操作、期待する結果」といったカラムを含めたファイルとして出力させています。
実際に使ってみると、自分が考慮できていなかった仕様も出力される安心感があります。例えばメールアドレス入力画面の動作確認項目を作成した際に、「メールアドレスとして受け付ける文字列の最大長の制限」が自分の考慮から抜けていたところを見つけることができました。自分の中ではメールアドレスと言ったらこういうものでしょ、という先入観があり、その時は長大な文字列を想像できていませんでした。先入観に左右されないのは、LLMの大きな強みだと改めて実感しています。
チームへの展開の際には、スキルのパッケージ自体をそのまま共有するのではなく、考え方と事例だけを共有しました。スキルを作るのは一瞬でしたし、作ったものがベストではないことも分かっているので、考え方を共有するほうが、チームで効果的な作り方や使い方の探索が促されると考えたためです。実際、同僚が「不明確な点はそのまま流さず、質問してください」という指示を組み込むことで、Claudeの理解度をより高める工夫を見出してくれました。
Geminiによる社内LT資料の作成（QA日下）
社内勉強会でのLT資料作成にGemini in Google スライドを活用した事例を紹介します。
アシュアード社各事業部のプロダクトチームでの交流を目的とした社内勉強会でのLTで、新しくyamory事業部に入社したQAエンジニアのメンバー向けにAssured事業部でのQAの取り組みを紹介する予定でした。話す内容は決まっていましたが、LT開始まで残り1時間を切ったタイミングでスライドを作り始めました。
Googleスライドの新規作成画面を開き、右側に表示されるGeminiのサイドパネルから「スライド作成」を利用しました。話す内容をスライドのページ単位に区切って要約したものを用意し、1枚ずつGeminiに渡して作成していきました。画像もGeminiが自動で生成してくれるため、特に指示しなくても各スライドにビジュアルが入った状態で完成しました。
結果として30分程度で資料が完成し、LTに間に合いました。今回は「作ったものを事前に確認しないでみんなで一緒に見る」という即興性も楽しむ実験的な試みだったため、あえて細かい調整はせずにそのまま使用しました。
Visionalグループ全体でGoogle Workspaceを利用しており、Gemini の機能が利用できるプランとなっています。今回はGoogleスライドでプレゼンテーションを作りたかったため、統合されている機能を使うのが最も相性が良いと思い利用してみました。
まとめ
今回紹介した事例では、新しく登場した機能を積極的に試しているのも印象的でした。生成AIの進化は目覚ましく、数ヶ月前にはできなかったことが今はできるようになっています。新機能をキャッチアップし、自分たちの課題に適用できるかを検証するサイクルを回すことが、活用の幅を広げることに繋がっていると感じました。
また、生成AIを活用するためのプロンプトやコードの生成もAIに作らせる事例も多くありました。AIを使うためにAIを使いながら、まずは試すことを重視してみることで、検証のサイクルを早められているように思います。
プロダクトチームでは、引き続き新しい機能やツールを試しながら、開発プロセスの改善に取り組んでいきたいと思います。
