1. はじめに：なぜ「カレンダー登録」の自動化が必要だったのか

私たちのチームでは、 Google カレンダーに予定を登録する際に「運用ルール」を設けています。

  • 予定タイトルの先頭に 【勤怠】【MTG(社外)】【作業枠】 などの種別プレフィックスを付ける
  • 種別ごとに 予定の色 を統一する（例：勤怠＝トマト、社外MTG＝グレープ）

一覧表示したときに「誰が何をしているか」が一目でわかる、シンプルで効果的なルールです。チームメンバーはこのルールをしっかり守っていますが、だからこそ問題がありました。

  • 毎回ルールを確認する手間：予定を登録するたびに「この種別のプレフィックスは何だっけ？色は何色だっけ？」とルール表を確認する必要がある
  • 表記ゆれのリスク：全角・半角の違いなど、手入力ゆえの微妙な揺れが起きやすい
  • 地味に時間がかかる：プレフィックスを手入力して、カラーピッカーを開いて色を選んで…という作業を1日に何度も繰り返す

この手間と時間を削減するため、 Google カレンダーの予定作成画面に「種別ボタン」を追加し、ワンクリックでタイトルと色を一括設定する Chrome 拡張機能を開発することにしました。

なぜ AI-DLC で開発しようと思ったのか

ちょうどこの拡張機能を作ろうと思っていたタイミングで、社内の Slack で AI-DLC（AI-Driven Development Life Cycle） について紹介している人がいました。AWS が提唱する AI ネイティブな開発手法で、要件定義から設計・実装まで AI と対話しながら進めるというものです。「これは今後一般的になっていくかもしれない、使ってみたい」と思ったのがきっかけで、今回の開発手法として採用することにしました。

開発には Kiro IDE を使いました。本記事では、完成した拡張機能の紹介と、 AI-DLC で開発を進めた実体験をお伝えします。

2. 【完成版】 GCal Team Helperの全貌

Before / After

例えば、 Google カレンダーに社外 MTG の予定を追加するとします。
チーム内のルールではプレフィックスは「【MTG(社外)】」、予定の色は「グレープ」と決まっています。

Before（手動）：
1. 予定作成ダイアログを開く
2. タイトルに「【MTG(社外)】」と手入力する
3. カラーピッカーを開いて「グレープ」を選ぶ
4. 残りの情報を入力して保存

→ 毎回このステップの手作業が必要です。急いでいると色を忘れたり、プレフィックスを間違えることがあります。

After（GCal Team Helper導入後）：
1. 予定作成ダイアログを開く
2. 表示された「MTG(社外)」ボタンをクリック
3. → タイトルに「【MTG(社外)】」が自動入力され、色も「グレープ」に自動変更される

→ 手間が大幅に削減されています。 表記ゆれも色の付け忘れも発生しません。

主な機能

  • プリセット選択 UI：予定作成ダイアログに種別ボタンが表示され、クリックでプレフィックス＋色を一括設定
  • リアルタイムチェック：タイトルを手入力しても、プレフィックスに応じて色が自動で切り替わる
  • 警告表示：未定義のプレフィックス（例：【未定義】）を入力すると警告バナーが表示される
  • プリセット管理：オプション画面からプリセットの追加・編集・削除・デフォルトリセットが可能
  • デバイス間同期：chrome.storage.sync により、同じ Google アカウントの Chrome 間で設定が自動同期

デフォルトプリセット

初回インストール時に「勤怠」「時間指定作業」「作業枠」「MTG(社外)」「MTG(社内)」「研修/試験」「その他」の7種類の種別がプリセットとして登録されます。それぞれにGoogleカレンダーの色（トマト、フラミンゴ、グレープなど）が紐づいています。また、これらの種別は新規追加や削除など、カスタマイズが可能です。

3. AI-DLC とは何か、Kiro でどう使うのか

AI-DLCとは

AI-DLC（AI-Driven Development Life Cycle） は、 AWS が提唱する AI 中心のソフトウェア開発手法です。従来の SDLC （ソフトウェア開発ライフサイクル）を AI 時代に合わせて再構築したもので、核となる考え方は 「AI が実行し、人間が監視する」 というパターンです。

（参考：AI 駆動開発ライフサイクル:ソフトウェアエンジニアリングの再構築 | AWS Blog）

AI が体系的に作業計画を作成し、意図のすり合わせとガイダンスを求め、重要な決定は人間に委ねます。つまり「AI が勝手にコードを書き始める」のではなく、各フェーズで人間が内容を確認・承認してから次に進む 対話型ワークフロー です。

AI-DLC は3つのフェーズで構成されています：

  • 🔵 Inception（開始）：何を作るか、なぜ作るかを決める（要件定義・設計）
  • 🟢 Construction（構築）：どう作るかを決めて実装する（詳細設計・コード生成・テスト）
  • 🟡 Operations（運用）：デプロイと監視（現時点ではまだ開発中）

Kiro IDE でのセットアップ手順

AI-DLC のワークフローはオープンソースで公開されており、 Kiro IDE の「ステアリングファイル」として配置するだけで使えます。

（参考：awslabs/aidlc-workflows | GitHub）

手順は以下の通りです：

1. AI-DLC のリポジトリをクローン

git clone https://github.com/awslabs/aidlc-workflows.git

2. プロジェクトにファイルを配置

クローンしたリポジトリの中から、必要なフォルダをプロジェクトにコピーします。

mkdir -p .kiro/steering
cp -R aidlc-workflows/aidlc-rules/aws-aidlc-rules .kiro/steering/
cp -R aidlc-workflows/aidlc-rules/aws-aidlc-rule-details .kiro/

配置後のディレクトリ構成：

<プロジェクトルート>/
├── .kiro/
│   ├── steering/
│   │   └── aws-aidlc-rules/    ← コアワークフロールール
│   └── aws-aidlc-rule-details/ ← 各フェーズの詳細ルール

3. Kiro IDE で確認

Kiro IDE の AGENT STEERING & SKILLS パネルを開き、 core-workflow が表示されていれば OK です。筆者の環境では、ファイル配置直後には表示されず、 Kiro IDE を再起動したら認識された ので、表示されない場合は一度再起動を試してみてください。

4. 開発を開始

開発を開始するには、チャットで「 AI-DLC を使って、〇〇を開発したい」と伝えるだけです。AI-DLC ワークフローが自動的に起動し、要件定義から順番にガイドしてくれます。

4. ステップ別： AI-DLC ワークフローの裏側を公開

要件定義（Inception）フェーズ： Kiro からの逆ヒアリングに驚いた

チャットで「 Google カレンダーのチーム運用ルールを自動化する Chrome 拡張機能を作りたい」と伝えたところ、 Kiro チャットはいきなりコードを書き始めるのではなく、逆ヒアリング を始めました。
ヒアリング用のドキュメント requirement-verification-questions.md が作成され、ドキュメント内に書かれた質問に回答を記入するよう求められました。

  • 「プリセットの色は自動設定ですか？それとも警告のみですか？」
  • 「対象は新規予定の作成のみですか？編集も含みますか？」
  • 「ストレージは chrome.storage.sync（デバイス間同期あり）と chrome.storage.local（ローカルのみ）のどちらですか？」

最終的に出来上がった requirements.md には、機能要件7項目、非機能要件5項目、ユーザーシナリオ3パターン、スコープ外などについて記載されていました。

アプリ開発のために重要な要件ヒアリングフェーズを AI がやってくれる便利さに驚きました。言わずもがなですが、ドキュメントの日本語もとても自然でわかりやすいものでした。

設計（Design）フェーズ：細かすぎて正直わからなかった

要件が固まると、 Kiro チャットはコンポーネント設計に進みました。 7つのコンポーネント（Content Script, PresetUI, CalendarDOMAdapter, PresetMatcher, StorageService, OptionsPage, ServiceWorker）の責務分離、技術スタックの選定理由（「 React を入れるとバンドルサイズが +40KB 増大するから不採用」など）が詳細にドキュメント化されました。

正直に言うと、普段インフラ担当でアプリ開発は行っていない自分には、設計ドキュメントを読んでもほとんど理解できませんでした。 AI-DLC ではドキュメントのカテゴリごとに逐一確認が求められ、 OK であれば Apply （適用）するという作業を繰り返すのですが、内容を深く理解できないまま承認していた部分もあります。

逆に言えば、普段からアプリ開発をしていて、設計やコードを細かく確認しながら進めたい人には最高のワークフロー だと思います。「アプリ内部のブラックボックス部分はよしなにやってくれ」というスタンスの利用者にはやや合わないかもしれません。

構築（Construction）フェーズ：チェックリストで段階的に進む安心感

実装は Kiro が生成した コード生成計画（チェックリスト） に基づいて段階的に進みました。

□ 型定義（types.ts）
□ 定数・デフォルトプリセット（constants.ts）
□ DOMセレクタ定数（selectors.ts）
□ ストレージサービス（storage-service.ts）
□ カラーマッピングサービス（color-mapping-service.ts）
□ ...（以下、全13ファイル）

コーディングのフェーズでも設計と同様に「コードが OK なら Apply して」と言われるのですが、コードを見てもあまりわからないので確認しようがない、という場面は正直ありました。

5. 【技術深掘り】 Google カレンダーの壁

Chrome 拡張機能の開発で最も苦労したのは、 Google カレンダーの DOM 操作 でした。

ここで言う「DOM」とは、ブラウザが Web ページを表示するために内部で持っている ページの構造データ のことです。 HTML の各要素（ボタン、入力欄、ダイアログなど）がツリー状に管理されており、 Chrome 拡張機能はこの DOM を読み書きすることでページの見た目や動作を変更します。 Google カレンダーの DOM は非常に複雑で、しかも Google が予告なく構造を変更することがあるため、ここが最大の難所でした。

人間が DOM を調べ、 AI がロジックを組む

AI-DLC で開発を進める中で、Kiro チャットから「 Google カレンダーの DOM 構造は実際のページでしか確認できないため、開発者自身で Chrome の開発者ツールを使って確認してください」と指示されました。

AI が自分にはわからない情報をしっかり整理して、「ここは人間が確認すべき」と明確に指示してくれる というのは、考えてみればすごいことです。ただ、普段インフラ担当の自分にとって、 DOM の調査は未知の領域でした。開発者ツールでどこをどのように確認すれば良いのかわからず、別の AI （Gemini）にやり方を聞いてなんとか探し当てた、という状況です。ここはもう少しうまいことやってくれればいいのに、と思った部分でもあります。

具体的にぶつかった壁

調査の結果わかった DOM の情報をコードに入力し、開発が完了しました。しかし、実際に動かしてみると次々と問題が発覚しました。

壁1：属性値が変わる

Google カレンダーの内部要素には jsname という属性が付いています。最初はこれをセレクタ（要素を特定するための目印）として使っていましたが、カラーピッカーで一度色を選択すると、同じボタンの属性値が変わってしまうという現象が発生。2回目以降の色変更が動かなくなりました。解決策は、変化しない aria-label（アクセシビリティ用の属性）を使うことでした。

壁2：要素が DOM から消える

色を選択した後、 Google カレンダーがダイアログの一部をDOMごと再構築する挙動があり、カラーボタンが一瞬消えて再出現します。連続で色を変更しようとすると「ボタンが見つかりません」というエラーに。これに対しては、 50ms ごとに DOM を確認して要素の出現を待つ「ポーリング」という手法で対処しました。

壁3：処理の二重発火

ボタンクリックでタイトルを変更すると、その変更がリアルタイムチェック機能にも拾われて、色の設定処理が2回走ってしまうという問題がありました。これについてはフラグ制御で抑制しました。

これらの問題はすべて、人間が実際の情報（開発者ツールのログや DOM 構造）を Kiro に渡し、 Kiro が精密なロジックを組むという分業で解決しました。 Kiro は Google カレンダーの実際の DOM を見ることができません。一方、人間は DOM の調査はできても、複雑な非同期制御のコードを素早く書くことはできません。この補完関係がうまく機能しました。

6. Kiro と AI-DLC で開発して分かったメリットと注意点

メリット

1. 思考の整理と要件の明確化

AI-DLC の最大の価値は「コードが書ける」ことではなく、要件定義の段階で思考が整理されることでした。 Kiro チャットからの逆ヒアリングに答えるうちに「あ、ここは考えてなかった」と気づく場面が何度もありました。

2. ドキュメントが勝手に揃う

開発が終わった時点で、要件定義書、コンポーネント設計書、ビジネスルール定義、技術スタック決定書が aidlc-docs/ フォルダに整理されます。これは従来の開発では「後で書こう」と思って結局書かないこともあるドキュメントです。後からチームメンバーが参加したときに「なぜこの技術を選んだのか」が残っているのは結構大きいのではないでしょうか。

3. 手戻りの少なさ

要件→設計→実装と段階的に承認しながら進めるため、「実装してから要件の認識違いに気づく」という手戻りがほぼ発生しませんでした。

注意点・正直な感想

1. 「サクッと作る」には向かない

AI-DLC は要件を細かく確認してくれるからこそ、AI でのアプリ開発でよくある「とりあえず簡単なモックアップを作ってもらって、それを元に改修していく」という進め方はできません。 AI-DLC は 「きちんとした」アプリ開発 であり、実際にお客様に納品するようなしっかりとしたアプリには向いていますが、個人でサクッと作りたい場合には合わないこともありそうです。

2. 設計・コードの確認は開発者スキルが必要

前述の通り、設計ドキュメントやコードの確認を求められますが、アプリ開発の経験がないと内容を判断しづらい場面があります。「アプリ内部はよしなにやってくれ」というスタンスの人にはやや不向きかもしれません。一方で、設計やコードを細かく確認しながら進めたいアプリ開発者には超おすすめです。

3. Operations Phase はまだ未完成

AI-DLC の3つ目のフェーズ（Operations）は現時点ではまだ開発中です。そのため、要件定義から実装まで自動でどんどん進んでいたアプリ開発が、テストやデプロイのフェーズに入ったところで止まってしまいました。とはいえ、そこからは元々の Kiro のチャット機能でテスト実行やビルド、 Git 操作などを普通にやってくれたので、実用上は全然問題ありませんでした。 Operations Phase が完成すれば、さらにシームレスな体験になりそうです。

4. DOM 調査は AI にはできない（でも指示はしてくれる）

Google カレンダーの DOM 構造の調査は、 AI にはできない人間の仕事です。 DOM 構造の調査は苦労しましたが、AI が「ここは開発者自身で確認してください」と明確に指示してくれたこと自体はすごいと思いました。AI-DLC の「AI が実行し、人間が監視する」という思想の表れだと感じます。

5. AI の出力は必ず検証する

Kiro が「ビルドでアイコンがコピーされました」と報告しても、実際には以前のビルドの残骸だった、というケースがありました。AI の出力は必ず自分の目で検証する習慣が大切です。

7. おわりに：AI-DLC を使って丁寧なアプリ開発を

今回の開発を通じて、 AI-DLC を活用することで、単にコードを書くだけではない、プロセスそのものが極めて「丁寧な」アプリ開発を実現できることがよくわかりました。もはや AI は、一部の作業を補助するだけの単なるサポート役ではなく、設計から実装までを共に歩む、アプリ開発にはなくてはならない存在へと進化しています。

AI ネイティブ時代のアプリ開発手法は、今後もさらに多様な形が登場してくるでしょう。しかし、その有力な選択肢の一つとして、 AI-DLC は十分にお勧めできる手法だと思います。

AI でのアプリ開発を進めようとしている方に、この記事が少しでも参考になれば幸いです。