背景

以前、以下の記事でGemini CLIを触りました。
このときは簡単にしか触れていなかったので、Gemini CLIを使ってなにかアプリを作りたいとずっと考えていました。

そこで、社内で使用されている勤怠管理システムの操作を楽にするChrome拡張機能を作ることにしました。

どんなものを作ったか

勤怠管理システムには、休暇申請とスケジュール申請（テレワークをするときに申請が必要）の機能があります。
申請時に入力ルールがあるのですが、現状バリデーションチェックがありません。

そのため、申請を出したあとに総務部から「ここ間違ってますよ」とチャットが来て、申請取り消し→再申請する流れを何度も経験しました。

そのため、入力必須の欄を自動で設定してくれるChrome拡張機能を作りました。

実際の画面

休暇申請自動入力機能

（システム全体の画面を映せないのはご了承ください...）

Chrome拡張機能をインストール後、休暇申請のページを開くとページ内に休暇区分毎のボタンが表示されます。

全日休暇
AM半休
PM半休

各ボタンを押下すると、それぞれ入力必須の項目を自動で設定してくれます。

例：全日休暇ボタンを押下すると休暇区分を自動で設定

他にも、記入必須である申請メッセージや、出勤/退勤予定時間（半日休暇の場合）を設定してくれます。

特に半日休暇申請時には、入力必須の項目が分かりづらいため、この機能で入力ミスをなくすことができました。

テレワーク一括申請機能

テレワークメインの社員は、各月ごとにテレワーク予定日をあらかじめ申請する必要があります。
この機能は、各月の平日にテレワーク申請で入力必須の項目を自動で設定してくれます。

スケジュール申請ページを開くと、ページ内にテレワーク一括設定ボタンが表示されます。

テレワーク一括設定ボタンを押下すると、ポップアップが表示され、
スケジュールと申請メッセージの入力が求められます。

入力後、実行ボタンを押下すると、テレワーク申請で入力必須の項目が自動で設定されます。

これにより、20日分近く毎回手動で入力していた作業を一瞬で終わらせることができるようになりました。

各種機能のON/OFF 可能

今後の機能追加も踏まえて、各種機能はON/OFF切り替えられると良いと思い、こちらも対応しました。
Chrome拡張機能をインストール後、アイコンをクリックすると各種機能のON/OFF ができます。

開発で使用したAIツール

コーディング・テスト作成：Gemini CLI
仕様書作成：Kiro
アウトプットの第三者レビュー：ChatGPT

なぜ、Gemini CLIを採用したのか？

とにかく、無料で最大限使えるのが決め手でした。

Claude CodeやCodex等、優秀なAIエージェントは他にもあります。
しかし、どうしてもお金がかかってしまうのがネックでした。

当方、個人開発で稼ぐつもりもなく、なんとなく今流行りのバイブコーディングを試してみたい・・・
くらいの感覚だったので、上記のツールは選択肢から外しました。

Gemini CLIは、無料枠でも大量のトークンを使えるのがありがたいです。
（さすがGoogleさん）

Gemini CLI を無料で利用するには、個人の Google アカウントでログインし、無償版の Gemini Code Assist ライセンスを取得するだけです。この無料ライセンスにより、Gemini 2.5 Pro と 100 万トークンという広大なコンテキストウィンドウにアクセスできます。プレビュー期間中に利用制限することがほとんどないように、業界最大級の利用枠を提供します。毎分 60 回モデルリクエスト、1日あたり1,000 回のリクエストを無料で提供します。

なぜ、Kiroを採用したのか？

AIエージェントによるバイブコーディングで一番不安だったのが、AIの出力の安定性です。
プロンプトベースでいきなり「〇〇を作りたい」と指示しても、期待したアウトプットが出てこず、何度もプロンプトでやり取りを繰り返すような体験の記事をいくつも見てきました。

そんなときに、Kiroが発表され、仕様書駆動開発というキーワードに惹かれました。

こんな経験はありませんか。何度もプロンプトを入力すると、動作するアプリケーションができあがる。楽しくて魔法のように感じます。しかし、プロダクション環境に移行するには、それだけでは不十分です。アプリケーションを構築する際、AI モデルはどのような前提を置いたのでしょうか？あなたはずっとエージェントをガイドしてきましたが、それらの決定は文書化されていません。要件は曖昧で、アプリケーションがそれらを満たしているかどうかわかりません。システムがどのように設計され、その設計があなたの環境とパフォーマンスにどう影響するかをすぐに理解できません。時には一歩下がって決定事項を整理することで、より良くて保守しやすいアプリケーションにたどり着くことがあります。それが Kiro が仕様駆動開発で支援することです。

コンセプトからプロダクションまで、AI エージェントとの作業を簡素化した開発者体験を通じて開発を支援する AI IDE（統合開発環境）、Kiro の発表を嬉しく思います。Kiro は Vibe Coding “も” 得意ですが、それをはるかに超えています。Kiro の強みは、スペック (spec) やフック (hook) などの機能を使って、これらのプロトタイプをプロダクションシステムに移行することです。

Kiroの提唱する仕様書駆動開発を使えば、AIの出力を制御できると思い、早速ウォッチリストに追加。
約3週間ほどで認証コードがメールで届き、Kiroを使えるようになりました。
(2,3日で使えると思っていたので、結構待ちました・・・)

開発の流れ

以下の流れで進めました。

Kiroを使って、仕様書、設計書、開発タスク一覧まで作成
Gemini CLI を使ってコーディング

Kiroを使って、仕様書、設計書、開発タスク一覧まで作成

Kiroでは、Spec（仕様書）モードを使い、以下のドキュメントを作成します。

仕様書：requirements.md
設計書：design.md
開発タスク一覧：tasks.md

仕様書：requirements.md

AIと一緒にChrome拡張機能の仕様を決めます。
ここでは、技術的記述はせず、どんな物を作りたいのか、どんな課題を解決したいのかに注力して作成していきます。

以下は、Kiroを使って作成した仕様書の一部抜粋です。

現在開発中の打刻ミス防止機能に関する仕様書です。
あくまで、こんなドキュメントができるんだなぁ程度で。

requirements.md


# Requirements Document

## Introduction

勤怠管理システムにおいて、出勤・退勤ボタンの誤操作による打刻ミスを防止するChrome拡張機能の要件を定義します。
現在のシステムでは1日に何度でもボタンを押下できるため、意図しない打刻が発生しています。
本機能により、勤怠ステータスに基づいてボタンの押下を制御し、打刻ミスを防止します。

## Requirements

### Requirement 1

**User Story:** ユーザーとして、打刻ミス防止機能を有効化できるようにしたい。これにより、誤った打刻操作を防ぐことができる。

#### Acceptance Criteria

1. WHEN ユーザーが拡張機能の設定画面を開く THEN システムは打刻ミス防止機能の有効/無効を切り替えるオプションを表示する SHALL
2. WHEN ユーザーが打刻ミス防止機能を有効にする THEN システムは現在の勤怠ステータスの入力を求める SHALL
3. IF 打刻ミス防止機能が無効の場合 THEN システムは既存の動作（制限なし）を維持する SHALL

### Requirement 2

**User Story:** ユーザーとして、現在の勤怠ステータスを設定できるようにしたい。これにより、適切なボタン制御が行われる。

#### Acceptance Criteria

1. WHEN 打刻ミス防止機能を初回有効化する THEN システムは勤怠ステータス選択画面を表示する SHALL
2. WHEN ユーザーが勤怠ステータスを選択する THEN システムは以下の3つの選択肢を提供する SHALL：「勤務前」「勤務中」「退勤」
3. WHEN ユーザーが勤怠ステータスを設定する THEN システムはその状態を保存し、打刻ミス防止機能を有効化する SHALL
4. IF ユーザーが勤怠ステータスを設定しない場合 THEN システムは打刻ミス防止機能を有効化しない SHALL

～以下省略～

設計書：design.md

ここから、仕様を実現するための技術手段を作っていきます。
Kiroが先程の仕様書（requirements.md）をベースに、作成してくれます。

あとは、Kiroが作った設計書を読みながら少しずつ詰めていきます。

以下は、Kiroを使って作成した設計書の一部抜粋です。

現在開発中の打刻ミス防止機能に関する設計書です。

design.md


# Design Document

## Overview

打刻ミス防止機能は、既存の勤怠管理サポートChrome拡張機能に新しい機能として追加されます。この機能は、ユーザーの勤怠ステータスに基づいて出勤・退勤ボタンの押下を制御し、誤った打刻操作を防止します。

既存のアーキテクチャに従い、機能ベースの設計を採用し、コアモジュールを活用して実装します。

## Architecture

### High-Level Architecture

本機能は既存の勤怠管理入力サポート拡張機能のモジュラーアーキテクチャに従い、パッケージベース設計とイベント駆動アーキテクチャを採用します。

```mermaid
graph TB
    A[Popup UI] --> B[FeatureRegistry]
    B --> C[AttendanceErrorPrevention Feature Package]
    C --> D[AttendanceStatusManager]
    C --> E[ButtonController]
    C --> F[DateTimeManager]
    
    D --> G[SettingsManager]
    E --> H[DOMUtils]
    F --> I[Background Service Worker]
    
    G --> J[Chrome Storage API]
    H --> K[TargetPage.html DOM]
    I --> L[EventBus]
    
    M[PageDetector] --> N[TargetPage.html Detection]
    N --> C

### Build and Execution Model

- **開発時**: ESM形式でモジュール分割されたソースコード
- **ビルド時**: esbuildによる単一JavaScriptファイルへのバンドル
- **実行時**: dist/main.jsがページに注入され、機能が動作

### Component Interaction Flow

1. **初期化フロー**: PageDetector → TargetPage.html検出 → FeatureRegistry → AttendanceErrorPrevention有効化
2. **ステータス設定フロー**: Popup UI → SettingsManager → EventBus → ButtonController更新
3. **ボタン制御フロー**: ページ読み込み → ステータス取得 → ボタン状態更新
4. **日付変更フロー**: Background Service Worker → EventBus → ステータスリセット → UI更新

## Components and Interfaces

### 1. AttendanceErrorPrevention (Main Feature Package)

```javascript
class AttendanceErrorPrevention extends FeaturePackage {
  constructor() {
    super('attendance-error-prevention');
    this.supportedPageTypes = ['TargetPage.html'];
  }
  
  async activate() { 
    // 機能有効化時の処理
    // - ButtonControllerの初期化
    // - イベントリスナーの設定
    // - 現在のステータスに基づくボタン制御
  }
  
  async deactivate() { 
    // 機能無効化時のクリーンアップ
    // - イベントリスナーの削除
    // - ボタン状態のリセット
  }
}

**責任**: 
- 機能全体の統合管理
- 既存のFeatureRegistryとの連携
- ページタイプに基づく機能の有効化/無効化
- EventBusを通じた他コンポーネントとの通信

～以下省略～

開発タスク一覧：tasks.md

ここまで作成してきた、仕様書（requirements.md）、設計書（design.md）をベースに開発タスクを作成していきます。

このタスク一覧に沿って、Gemini CLIが開発を進めていくためのドキュメントです

チェックリスト形式かつ、各タスクにはどの要望と紐づいているのかもわかります。
これにより、途中で作業中断してもタスクの再開が容易になります。

タスクには、テストコードの作成・テスト実施を任せることもできます。

以下は、Kiroを使って作成した設計書の一部抜粋です。

現在開発中の打刻ミス防止機能に関するタスク一覧です。

tasks.md


# Implementation Plan

## 実装中の注意事項
タスクが完了するたびに、このファイルを更新して進捗を保存するようにしてください。

## 実装タスク

- [ ] 1. プロジェクト構造とコア機能の準備
  - manifest.jsonのバージョンを1.1.0に更新
  - Chrome拡張機能のバージョンを1.1.0に更新
  - 打刻ミス防止機能のディレクトリ構造を作成
  - 既存のコアモジュール（Logger、SettingsManager、EventBus）との連携を確認
  - _Requirements: 1.1, 1.2, 1.3_

- [ ] 2. 勤怠ステータス管理機能の実装
  - [ ] 2.1 AttendanceStatusManagerクラスの実装
    - 勤怠ステータス（勤務前/勤務中/退勤）の管理ロジックを実装
    - Chrome Storage APIを使用したステータスの永続化機能を実装
    - ステータス変更時のEventBus通知機能を実装
    - _Requirements: 2.1, 2.2, 2.3, 4.1, 4.3, 5.1, 5.3_

  - [ ] 2.2 AttendanceStatusManagerの単体テスト作成
    - ステータス管理ロジックのテストケースを作成
    - SettingsManagerとEventBusのモック化テストを実装
    - エラーハンドリングのテストケースを作成
    - _Requirements: 2.1, 2.2, 2.3_

～以下省略～

ここまでドキュメントが作成できたら、ようやくGemini CLIを使って実装に入ります。

Gemini CLI を使ってコーディング

いよいよ実装フェーズですが、基本的にKiroで作成したmdファイルをGemini CLIに参照させてタスクを進めるだけです。

gemini
@requirements.md @design.md @tasks.md を確認してタスクを進めてください

事前にKiroでドキュメントを作っていたので、Gemini CLIが意図しない実装を進めるようなことも少ない印象でした。

1日で使えるGemini 2.5 Proのリクエスト数を使い切ると、
自動的にGemini-2.5-flash に切り替わります。

Gemini 2.5 Proが優秀な回答をしてくれるのも相まって、
Gemini-2.5-flashに切り替わると途端にアウトプットの質が不安定になります。
（途中で固まったり、日本語で出力していたのに急に英語になったり...etc）

そのため、1日のGemini 2.5 Proリクエスト数を使い切ったら、その日の開発は終了。
次の日に持ち越しのような開発で進めていきました。

所感

2,3時間で作れてしまった

開発当初は、いきなり2機能分開発したのではなく、
1機能、1Chrome拡張機能として開発していました。
（このChrome拡張機能は2機能搭載しているので、もともと2つにChrome拡張機能が別れていました）

そのため、1つのChrome拡張機能を作るのに2,3時間で完了しました。
想像以上に早く、完成度が高かったので感動しました。

動作確認で発生したエラーも、コンソールログをGemini CLIに渡して解析してもらったので、
デバッグ作業も非常に楽でした。

仕様書駆動開発の体験が予想以上に楽しかった

ドキュメントもKiroを使ってAIに書かせていたので、
自分でやるならかなり面倒だったであろう、以下の作業も楽しく仕様書を作ることができました。

ドキュメント作成途中での仕様変更
文言の統一
mermaid記法による設計図の作成

また、事前にドキュメントをガッツリ作り込むことで、
実装フェーズでのGemini CLIの挙動も舵取りをできたので、自分でAIをコントロールしている感覚があったのは良かったです。

単体テストフェーズでは、1日のリクエスト数をあっという間に使い切ってしまう

単体テストも、基本的にGemini CLIに投げっぱなしで作れました。
しかし、テストフェーズでは以下のサイクルを高速で回すため、Gemini 2.5 Proの1日のリクエスト数をあっという間に使い切ってしまいました。

テスト実行
テスト失敗
ログ確認
原因調査
コード書き直し
再テスト

そのため、使用リクエスト数がリセットされる翌日まで待つ必要がありました。
テストフェーズが一番時間の掛かった印象があります。

対策

単体テスト対象のファイルをビジネスロジック部分と依存関係の少ないファイルに限定しました。

いきなりGemini CLI にテストを書かせると、全ファイルに対してテストを書こうとしていました。
特にDOM操作を行うファイルの単体テストは、テスト失敗が頻発し、テストも複雑化してしまいました。

そのため、一度作ってもらったテストコードを精査して、
ビジネスロジック部分にテストを限定し、DOM操作を行うファイルのテストコードは削除してもらいました

拡張機能 API を使用せずに記述されたコードは、Jest などのフレームワークを使用して通常どおりテストできます。このようにコードを簡単にテストできるようにするには、依存関係の注入などの手法の使用を検討してください。これにより、下位レベルの実装で Chrome 名前空間への依存関係を削除できます。

また、最初に作ってもらったChrome拡張機能のコードベースでは、機能がシンプルだったゆえにmain.js で全ての処理を担う設計になってしまいました。

そのため、単一責任の原則のに沿うようにリファクタリングを計画しました。

手順としては、
2つのChrome拡張機能のリファクタリングをKiroで計画 → Gemini CLI でリファクタリング実施
その後、2つのChrome拡張機能を1つに統合しました。

この統合作業もKiroを使ってあらかじめ統合方針をドキュメント化しました

意識したこと

まずは1機能・1拡張機能で作成

先程の対策でリファクタリングの話をしましたが、

もともと実現したかった機能は2つありました。
しかし、開発初期段階でKiroの使用感やGemini CLIがどこまで精度の高い実装ができるか把握はしていませんでした。

その中でいきなり2機能を1つのChrome拡張機能にまとめて作るのはリスクだと判断し、
1機能・1拡張機能で作ることにしました。

最終的に、2つのChrome拡張機能を1つに統合し、
今後の機能追加も考慮した設計で作ることができました。（作ったのは全部AIですが...汗）

設計ドキュメントは、AIのために充実させる

ドキュメントを事前に整備しておくことで、AIの出力をコントロールできる仕様書駆動開発に感動したので、
ドキュメント整備は必須だと考えました。

そのため、
開発時に作成したkiroのドキュメントをベースに、以下のドキュメントも作りました。

README.md
GEMINI.md
architecture.md（拡張機能で採用されているアーキテクチャや設計思想、テストコードのルール等を明記したファイル）

コードに変更が入ると、上記のドキュメントはAIにメンテナンスさせました。

合わせて、 Serena をMCPサーバーとして登録しました。
Serena の導入には、以下の記事を参考にさせていただきました。

今後の課題

脱 Kiro

あんなにお世話になった、Kiro をどうして手放す計画を立てているんだって話ですが、
実は、フリープランでのKiroのSpec（仕様書）モードは、ウェルカムボーナスで使えるだけです。
引き続き、Spec（仕様書）モードを使うには、課金が必要でした...orz

本日（8/15）以降、Amazon Q Developer サブスクリプションを持たない Google、GitHub、または AWS Builder ID アカウントでログインしたユーザーは、新しい料金モデルに移行しました。これらのアカウントは現在「無料（Free）」ティアとなっており、月 50 件の Vibe リクエストと 0 件の Spec リクエストが含まれています。

さらに、すべてのユーザーに対して 100 件の Spec リクエストと 100 件の Vibe リクエストのウェルカムボーナスを提供します。このボーナスは、新しい料金プランで最初のリクエストを行った時点から 14 日間有効です（どのティアであっても適用）。これにより、Kiro のすべての機能を体験し、自分の利用ニーズを把握するための時間を確保できます。

Kiro の代替先

今のところ、spec-workflow-mcp を候補に考えています。

以下の記事を拝見したところ、ダッシュボード付きで作成できるドキュメントもKiroとほぼ同じ感じなので、今のうちに触っておこうかなと考えています。

ただし、Kiroは、エディタ上に搭載されているAIモデルでドキュメントを作っていました。
対して、spec-workflow-mcpでは、Gemini CLIを使ってドキュメントを作成するので、
Gemini Pro 2.5 のリクエストを消費してしまうんですね....

ただ、無料で使えるのでKiroの移行先としては筆頭候補だと考えています。

バイブコーディングについて思ったこと

締めになりますが、
今回の開発を通じて感じたことは、身近な課題を認識→ソフトウェアで解決する楽しさを再認識できた の一言だと思います。

これまでは、日常のちょっとした課題をソフトウェアで解決しようとした時、作ろうと思えば作れるけど、労力がかかる がボトルネックに感じる部分は多々ありました。
（Chrome拡張機能なり、windowsバッチなり、）

そのボトルネックがAIで解決されつつあると感じています。
実際、日常業務でちょっと役立つモノを作る程度なら、今回のようにすぐ作れます。

ソフトウェア開発の本質は、課題の解決にあると思っています。
自分が作ったソフトウェアで、身近な課題を解決した達成感と気持ちよさ、他の人に使ってもらう喜びを、AIを通じてより簡単に感じられるようになるのは非常に大事だと感じます。

ここまで読んでいただきありがとうございました！