🧑‍🏫

Chrome拡張機能をAIと作ったら、結局コードを手書きした話

に公開
AI
Chrome拡張
ノーコード
開発体験
tech

TL;DR

ZoomやGoogle Meetのチャットがアーカイブに残らない問題を解決するChrome拡張機能を、「AIとノーコードだけで」作ろうとしました。

結論：自分でコードを書いた方が楽でした。

この記事は、エンジニアなら誰もが体験する「理想と現実のギャップ」について、赤裸々に語ります。

元記事との違い

こちらはQiitaの元記事のエンジニア向け版です。元記事は非エンジニア向けの擬似教材として書きましたが、今回は開発の裏側と技術的な苦労話を中心にお話しします。

なぜこの拡張機能が必要だったのか

オンライン会議あるある：

  • 🎯 チャットで重要な情報が流れる
  • 📹 録画にはチャットが含まれない
  • 📝 議事録作成時にチャット内容を思い出せない

「これはITの力で解決できるはず！」と思い立ったのが始まりでした。

ノーコード開発の甘い罠

最初の目論見

「AIが発達した今なら、コードなんて書かなくても大丈夫でしょ？」

こんな軽い気持ちでスタート。ノーコードツールとAIアシスタントがあれば、サクッと完成するはずでした。

現実は厳しかった

Phase 1: 楽観期

私「AIくん、Chrome拡張機能作って」
AI「はい！manifest.jsonから始めましょう」
私「おお、すごい！」

Phase 2: 困惑期

私「あれ、この機能どうやって実装するの？」
AI「こんな感じで...（微妙に違う提案）」
私「う〜ん、なんか違うな...」

Phase 3: 絶望期

私「もう自分で書く！！！」

エンジニアとして学んだこと

ノーコードの限界

  1. 細かい仕様への対応が困難

    • ブラウザ固有の挙動への対応
    • リアルタイム処理の最適化
    • エラーハンドリングの細分化

  2. デバッグの難しさ

    • 生成されたコードの内部動作が見えない
    • 問題の特定に時間がかかる
    • カスタマイズの自由度が低い

  3. 技術的負債のリスク

    • 将来の拡張が困難
    • パフォーマンスの最適化ができない
    • セキュリティ面での不安

AIとの正しい付き合い方

最終的に、AIは「開発パートナー」として活用しました：

  • 🤝 コードレビューのお手伝い
  • 💡 アイデアの壁打ち相手
  • 📚 技術文書の叩き台作成
  • 🐛 デバッグのヒント提供

開発で実際に使ったルール

AIに対するプロンプトとして、以下のコーディング規約を共有しました：

実際に使ったコーディングルール
# コーディングルール

## 1. クラス設計
- 単一責任の原則に従う
- publicメソッドは明確なインターフェースを提供
- privateメソッドは先頭に_を付与
- コンストラクタでは初期化のみを行う

## 2. 状態管理
- クラス内の状態は全てprivate（#プレフィックス）
- 状態変更は専用のメソッドを通じて行う
- 状態変更後は必要に応じてUIを更新
- 永続化が必要な状態は自動的に保存

## 3. エラー処理
- 非同期処理は全てasync/awaitで統一
- エラーは適切にキャッチして処理
- ユーザーへの通知が必要なエラーは専用メソッドで処理

## 4. イベント処理
- イベントリスナーは集約して管理
- イベントハンドラはバインドして使用
- 複雑なイベント処理は分割して実装

## 5. DOM操作
- 要素参照はキャッシュして再利用
- 更新は必要最小限に抑える
- テンプレート文字列を使用してHTML生成

## 6. 命名規則
- クラス名: PascalCase
- メソッド名: camelCase
- プライベートメソッド: _camelCase
- 定数: UPPER_SNAKE_CASE
- 一時変数: camelCase

## 7. コメント
- クラスとpublicメソッドは必ずJSDoc
- 複雑なロジックには説明コメント
- TODO/FIXMEは課題管理と連携

## 8. テスト容易性
- 依存性は注入可能に設計
- 副作用は分離して管理
- モック化可能なインターフェース

これらのルールを共有することで、AIとの協働がスムーズになりました。

結果として作れたもの

最終的に完成した拡張機能の特徴：

  • ✅ リアルタイムチャット保存
  • ✅ 会議タイトルでの自動分類
  • ✅ 検索可能なアーカイブ
  • ✅ エクスポート機能

エンジニアへのメッセージ

ノーコードは敵ではない

誤解しないでください。ノーコードツールを否定しているわけではありません。

  • プロトタイピングには最適
  • シンプルな業務改善なら十分
  • 非エンジニアとのコミュニケーションに有効

でも、エンジニアの価値は変わらない

複雑な要求に対しては、やはり手書きのコードが必要でした。特に：

  1. パフォーマンスが要求される場面
  2. 細かい仕様への対応
  3. 長期的な保守性

これらは、まだまだエンジニアの領域です。

最後に：開発者として思うこと

今回の経験を通じて実感したのは、技術は手段であって目的ではないということ。

AIもノーコードも、結局は「課題を解決するための道具」の一つです。大切なのは：

  • 🎯 何を解決したいのかを明確にすること
  • 🛠️ 適切な道具を選ぶこと
  • 🚀 結果を出すこと

この拡張機能が、同じ課題を抱える方のお役に立てれば幸いです。

そして、「AI時代だからコードは不要」なんて思っている方がいたら...まあ、一度体験してみることをお勧めします😅

参考リンク

Discussion