RevComm Tech Blog

コミュニケーションを再発明し 人が人を想う社会を創る

フロントエンド開発への AI コーディングエージェントの導入 - MiiTel Phone チームにおける取り組みの紹介

はじめに

MiiTel Phone の開発チームでは Claude Code などの AI コーディングエージェントを活用して、生産性やコード品質の改善などに取り組んでいます。

本記事では実際に取り組んでいる内容や課題などについて紹介します。

実施している取り組み

UI コンポーネントの実装の効率化

Figma MCP などを活用して、デザインデータから React コンポーネントを生成しています。Storybook 向けのストーリーの生成も任せることで、コーディングエージェントが実装してくれた UI コンポーネントをすぐに確認することができて便利です。

help.figma.com

また、React Grab を活用することで、ちょっとした UI の手直しなどが行いやすくなりました。

github.com

コードレビューの効率化

GitHub Copilot code review や Devin Review などをコードレビューに活用しています。工夫している点として、過去に発生したバグや実装上注意すべき点などを Markdown ファイルにチェックリスト形式でまとめておき、それらを .github/copilot-instructions.mdREVIEW.md から参照させることで、実装時の考慮漏れを指摘してもらえるようにしています。

<!-- 例) .github/copilot-instructions.md のイメージ (実際のコードとは異なります) -->
## Code Review

- [チェックリスト](../docs/checklist.md)で指示されたチェックを実施してください。
- 日本語でコメントしてください。
- [`openspec/specs/*/spec.md`](../openspec/specs/)で定義された要求に対する違反がないことをチェックください。

今のところ、GitHub Copilot code review はきちんとチェックリストを参照した上でレビューを実施してくれており、意図せず問題が再発してしまうことの防止に役立っています。

弊社における GitHub Copilot code review の活用例についてはぜひ下記記事も参照ください!

tech.revcomm.co.jp

問い合わせやバグなどの調査

Pup CLI という Datadog と連携するための CLI ツールが公開されています。

github.com

Pup CLI を使うことで、 Datadog のログの検索などをコマンドラインから行うことができます。

様々な用途に活用できそうですが、Pup CLI の大きな特徴として Agent Mode というコーディングエージェントとの連携を想定した機能が提供されています。

github.com

具体的には、Claude Code などのコーディングエージェント経由での Pup CLI の実行が検出された場合、Pup CLI は自動的にコーディングエージェント向けに最適化された出力を返却してくれます。

注意点として、Pup CLI を使用する際は意図せずコーディングエージェントにセンシティブな情報が渡されてしまわぬよう注意すると良いと思います。Datadog に送信するログなどはきちんと精査し、必要に応じてマスキングを実施するなどの対応を行なっておくと、より安心して連携できます。

仕様駆動開発

コーディングエージェントを使うようになってから、実装スピードや問い合わせ・バグなどの調査速度はかなり改善されたと感じるものの、既存コードの背景や意図、仕様などの暗黙的な知識をどうやってコーディングエージェントに伝えるかという点を課題に感じていました。

対策としては信頼性の高いテストコードの割合を増やし、コーディングエージェントが意図せぬ変更を実施した際にきちんと捕捉できるようにする仕組みを整備する方法などが考えられます。しかし、コーディングエージェントが意図せずテストコードの方を修正して強引にテストを通そうとするケースも多々見受けられ、この手法にも限界がありそうです。

これらの課題の解決策として仕様駆動開発が有効なのではないかと思い、試しています。

過去の変更の背景をきちんとリポジトリ内で文書化・蓄積できるようにし、そして変更を実際にコーディングエージェントに依頼する前にあらかじめ要求や背景などの情報を伝えられるようにすることで、意図せぬ変更を防止しつつ、よりスムーズに機能を実装できるようになることを期待しています。

仕様駆動開発を補助する OSS としては、下記のツールが人気であると思います。

MiiTel Phone チームでは OpenSpec を採用しています。理由としては以下です。

  • OpenSpec は TypeScript 製であり、普段使用しているフロントエンド関連のツールのみでの導入および管理が可能で、より手軽に試しやすかったこと
  • openspec/specs/*/spec.md に Source of truth として機能する仕様を蓄積し、openspec/changes/archive/に過去の時点における実装の背景などがスナップショットとして蓄積されてゆく作りであるため、導入の目的により近いこと

また、OpenSpec は既存のプロダクトの開発に後から導入したケースにおいてもうまく機能してくれるのが良い点です。openspec/specs/*/spec.mdに、段階的に既存機能の仕様や要求などを追加していくことができます。

例えば、以下は spec.md の例です。spec.md を記述する際は、所定のフォーマットに準拠していることを検証できるよう、huskylefthook などのツールで openspec validate コマンドの実行を自動化しておくと便利です。

# Example Specification

## Purpose

This app supports a simple, reliable TODO management experience for individuals.

## Requirements

### Requirement: Creating and managing TODO items

The TODO app MUST allow a user to create, view, update, complete, and delete TODO items.

#### Scenario: Creating a new TODO

- **GIVEN** a user is signed in to the TODO app
- **WHEN** the user enters a title and submits the form
- **THEN** a new TODO item is created with status "Incomplete"
- **AND** the new TODO item appears in the TODO list

#### Scenario: Editing an existing TODO

- **GIVEN** a TODO item exists
- **WHEN** the user updates the TODO title and saves
- **THEN** the TODO item shows the updated title
- **AND** the TODO item's completion status remains unchanged

#### Scenario: Completing a TODO

- **GIVEN** a TODO item exists with status "Incomplete"
- **WHEN** the user marks the TODO item as completed
- **THEN** the TODO item's status becomes "Completed"
- **AND** the TODO item is visually distinguished as completed in the list

#### Scenario: Deleting a TODO

- **GIVEN** a TODO item exists
- **WHEN** the user deletes the TODO item
- **THEN** the TODO item is removed from the TODO list
- **AND** the TODO item MUST NOT appear in future list results

### Requirement: Filtering and searching TODOs

The TODO app SHALL allow a user to filter and search TODO items.

#### Scenario: Filtering by completion status

- **GIVEN** the user has both completed and incomplete TODO items
- **WHEN** the user filters the list to "Incomplete"
- **THEN** only incomplete TODO items are displayed

#### Scenario: Searching by keyword

- **GIVEN** the user has multiple TODO items with different titles
- **WHEN** the user searches for a keyword that matches some TODO titles
- **THEN** only TODO items with titles matching the keyword are displayed

まだあまり OpenSpec の導入による効果は実感できていないというのが正直なところではあるのですが、以下の点を期待して、少しずつ使用を進めています。

  • OpenSpec は特定のエージェントに依存せず、Markdown ベースのシンプル かつ 一貫した形式で要求を記載してゆくため、人にとってもコーディングエージェントにとっても内容を理解しやすい
  • 仮にうまく仕様駆動開発がワークしてくれなかったとしても、導入・検証の過程でリポジトリ内に追加したドキュメントはそのまま残るため、全く無駄になってしまうことはないであろうと判断しました

定型的タスクの効率化

RevComm では社内向けの Claude Code プラグインマーケットプレイスが整備されており、定型的タスクを効率化するための様々なコマンドやスキルが蓄積されています。問い合わせの調査に特化したスキルやその他日頃の雑多なタスクを効率化するためのスキルやコマンド群が蓄積されており、日頃の業務の効率化に活用しています。

社内向けプラグインマーケットプレイスがあると、仕組みを手軽に活用・共有できるようになり、とても便利に感じています。

ガードレールの整備

コーディングエージェントが意図せぬ振る舞いをしてしまうことがどうしても出てくるため、ガードレールを整備して、より安心して利用できるようにすることが重要と感じています。具体的には以下のような取り組みが効果的であると思います。

  • 信頼性の高いテストコードの比率を増やす

    tech.revcomm.co.jp

  • ESLint の設定の厳格化やプラグインの追加により、コーディングエージェントのミスを早期タイミングで捕捉できるようにする

  • 意図せぬ振る舞いをした際は適宜、AGENTS.md を見直す

課題

コードレビュー

コーディングエージェントにより開発速度が大幅に向上しても、人によるコードレビューやテストはどうしても時間がかかってしまいがちです。

GitHub Copilot code review や Devin Review などは、コードレビュー時の見落とし防止などに活用できて非常に便利ではあるものの、どうしてもコードレビューやテストには時間がかかってしまいがちです。

対策としては、一つ一つの PR をできる限り小さくすることで、レビューの手間を軽減したり手戻りを減らすことなどが期待できますが、この方法にも限界はあります。

取り急ぎできることとしては信頼性の高いテストコードの割合を徹底的に高め、CI などで迅速にリグレッションの発生を検知できるようにしつつ、レビュープロセスを簡素化できるようにすることが良いのではないかと感じています。

また、レビューにどうしても時間がかかってしまう問題については、レビューに関する方針を見直す必要性が生じてくるのではないかと考えています。逐一、細かなレビューは実施せず、どこかのタイミングで一括してレビューを実施することで効率を改善するなどの方法が必要ではないかと思います。そのためには、コード変更に関するトレーサビリティーを改善することも重要ではないかと思っています。例えば、下記のようなツールがこの点に貢献してくれるのではないかと期待しており、ぜひ今後、試してみたいです。

github.com github.com

意図せぬ UI の生成

Figma MCP などを活用することで、UI コンポーネントの生成は大幅に効率化されますが、時折、コーディングエージェントが意図せぬレイアウトでコンポーネントを出力を生成するケースが見受けられます。

この課題は今後のモデルの進化に伴い改善されてゆく可能性は高いと思いますが、現時点では Storybook の活用などによりスムーズに UI を確認できるようにしておくと、コーディングエージェントに素早く修正依頼ができるため、効率的ではないかと感じています。

おわりに

Claude Code などのコーディングエージェントの活用を始めてから、コードの記述は大幅に効率化されました。しかし、膨大な変更を一度に任せてしまうと、巨大な PR ができてしまいレビューの負担が増したり、精度が低下して却って手戻りが増えてしまうなどの問題も発生してしまいます。できる限り PR のサイズを小さくしつつ、コーディングエージェントに並列で作業を任せるのが現時点では効率的ではないかと感じています。

また、コーディングエージェントはとにかく変化が激しいため、継続的な振り返りなどに基づいて、適宜、使い方や運用を見直したり、チーム内外で情報を共有することが重要と感じました。

本記事の内容が参考になれば幸いです。