第3回です。前回までにVSCodeへのCline導入と各社APIキーの初期設定まで完了しました。 今回はこの環境で各AIプロバイダーに「Chrome拡張機能」を作成させ、どの程度仕上がりに差がつくのか確認してみようと思います。
今回も元ネタを食わせたAIに文章生成してもらっていますので、もしかするとおかしいところがあるかもしれません。ご了承ください。
今回作成するChrome拡張機能の概要
さて、折角なので実用的なものをと思い、Chromeのウィンドウサイズ変更とスクリーンショットができる拡張機能を作ってみようと思います。
これをCline+各モデル(Anthropic Claude / OpenAI / Google Gemini)の組み合わせでそれぞれ作成し、仕上がりにどのような違いがあるかをチェックしてみます。
というわけで、まずは作業用ディレクトリを準備しVSCodeで開きます。
- 作業ディレクトリ名:
cline-sample-ext_claude - 作成対象:Chrome拡張機能(Manifest V3対応)
開発環境のセットアップ(Git / Node.js / Plasmo / GitHub)
作業に入る前に開発環境を整えます。
1. Git for Windows の確認
Cline はコードの生成や変更・差分追跡を行う際に内部的に Git を使用します。Windows 環境で git コマンドが動作するか確認します。
PS C:\> git -v
git version 2.55.0.windows.5
PS C:\>2. Node.js と Plasmo の準備
ビルドやパッケージ管理用に Node.js を使用し、フレームワークには React / TypeScript で拡張機能が作成できる Plasmo を利用します。
PS C:\> node -v
v24.21.0
PS C:\> npm -v
11.19.0
PS C:\>3. GitHub リポジトリの初期化と紐づけ
Clineは内部的に Git のコミット履歴や差分(Diff)を参照しながらタスクを実行します。事前に git init やリモート接続が用意されていないとエラーになるため、GitHub上でリモートリポジトリを作成し、ローカル環境と紐づけて初期化をしておきます。
GitHub上でリモートリポジトリを作成

↑今回はこの設定で作成。
ローカルの初期化とリモート紐づけ
VSCodeのターミナルからコマンドを実行し紐づけする。
# 1. ローカルリポジトリの初期化
git init
# 2. 変更内容を初回コミット
git add .
git commit -m "Initial commit"
# 3. あらかじめ作成しておいたGitHubリモートリポジトリと紐づけ
git branch -M main
git remote add origin https://github.com/uc4696/cline-sample-ext_claude.git
# 4. リモートへプッシュ
git push -u origin mainWindows環境でのPowerShell調整
実際にClineを動かした際、PowerShell絡みでいくつか問題が発生したため、実施した対応を書いておきます。
1. PowerShellのアップデート
winget install --id Microsoft.PowerShell --source winget2. PowerShellの実行許可設定
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser3. デフォルトターミナルの設定
今回はデフォルトターミナルとしてPowerShellを設定します。

↑Ctrl + Shift + P を押す。入力欄に Terminal: Select Default Profile と入力し「ターミナル規定のプロファイルの選択」をクリック。

↑pwsh.exe を選択する。

↑Cline の設定(歯車アイコン)を開き、 Terminal Settings タブの、Terminal Execution Mode は「Background Exec」、Default Terminal Profile は「Power Shell 7」を指定する。
Clineの初期設定(コスト・暴走対策)
事前にClineを使用した際にAPIコストを節約したり暴走を抑止するための設定を入れておきます。(効果に関しては不明です)
1. clinerules の配置
.clinerules は、プロジェクト直下に配置することで Cline(AIアシスタント)の挙動や開発時のルールを制御できる設定ファイルです。事前に設置しておくことで、AIに対してプロジェクト固有のフォルダ構造、コーディング規約、禁止事項などを毎回プロンプトで指示しなくても認識させることができます。
今回はコード生成を指示する前に、トークンの無駄遣いやAPIコストの暴走を抑える設定を入れておきました。(ないよりマシな程度?)

↑プロジェクトのルートディレクトリに .clinerules というファイルを作成し、以下の内容を記載します。
# Chrome拡張機能開発の共通ルール & コスト最適化・暴走防止
## 1. 開発範囲とディレクトリの制限(マルチワークスペース対策)
- 作業開始時に、対象となる拡張機能のルートフォルダー(`manifest.json` や `package.json` が存在するディレクトリ)を必ず特定してください。
- 原則として、特定した対象の拡張機能フォルダー内だけを調査・変更し、対象外のフォルダーや生成物を変更・閲覧することは絶対に禁止します。
- コマンドを実行する際は、必ず対象フォルダーのルートまたはその配下の適切なディレクトリを基準に実行してください。
## 2. 事前調査・書き換えのコスト最適化ルール
- タスクを開始する際、不要なファイルを片っ端から読み込む動き(関係のないファイルへの過剰なgrepやfindなど)を厳禁とします。
- コードの調査や書き換えを行う場合は、必ず該当する最小限のファイルだけをピンポイントで読み込んで処理してください。
- 1回の指示に対して、AI側で勝手にツール(ファイル確認など)を何度もループ実行して迷走しないでください。
- 実装方法に迷ったり、必要なファイルが見つからない場合は、ツールを複数回動かして調べる前に、まずユーザー(人間)にチャットで質問・確認してください。
## 3. バージョン管理と自動リリースへの配慮
- 拡張機能の機能追加・修正(エンハンス)を行った場合は、必ずプロジェクトの管理ファイル(`package.json` や `manifest.json` など)の `version` を更新(インクリメント)してください。
- 理由: CI/CD(GitHub Actionsなど)による自動リリースフローが組まれている場合、バージョンが更新されていないと新しいリリースやタグが正常に生成されない原因になります。
- ただし、ドキュメントの更新やコメント修正など、拡張機能の配布物(ビルド成果物)に直接影響しない変更のみの場合は、バージョン更新は不要です。
2. Plan モードと Act モードの使い分け
あとから気づいた機能で今回の作用では利用しませんでしたが、Clineの動作モード(Plan / Act)を分け、それぞれのモデルを割り当てることで、APIコストを節約できたりもするようです。
- Plan モード:コード変更やコマンド実行を行わず、ファイル調査と計画作成のみを実施
- Act モード:計画に沿って実際にファイル書き換えやターミナルコマンドを実行
3. Auto approve の設定
ターミナル実行などの自動承認(Auto approve)の設定です。設定しておくと勝手に進むので楽なのですが、AIが迷走したり、無限ループに陥ったりと、APIコストを無駄に使ってしまう罠もあるようです。


- Read files(ファイルの読み込み)
- 説明: プロジェクト内のファイルをClineが自動で読み込むことを許可します。
- 設定: オン
- 理由: これをオフにすると、ファイルを1行見るだけでも毎回承認ボタンを押す必要があり、作業が全く進まなくなります。
- Edit files(ファイルの編集・書き込み)
- 説明: Clineがコードを書き換えたり、新しいファイルを作成したりすることを自動で許可します。
- 設定: オン
- 理由: Read files と同じ理由です。
- Execute commands(コマンドの実行)
- 説明:
npm run devやgit statusなどのターミナルコマンドを、Clineが自動で実行することを許可します。 - 設定: オフ
- 理由: テストコードの実行などを自動化できて便利ですが、予期せぬコマンドを実行されるリスクを減らすため、最初は確認を挟む(オフにする)のが無難です。
- 説明:
- Fetch web content(ウェブコンテンツの取得)
- 説明: 最新のドキュメントやエラーの解決策を調べるために、Clineが自動でインターネット上のウェブサイトにアクセスして情報を取得することを許可します。
- 設定: オン
- 理由: 情報収集のみなので、ローカルのコードが破壊されるリスクはありません。
- Use MCP servers(MCPサーバーの使用)
- 説明: MCP(Model Context Protocol)という仕組みを使って、外部のツールやデータベース、GitHubなどとClineを連携させる操作を自動で許可します。
- 推奨: オフ
- 理由: 作業内容によってはコスト跳ね上がります。
Clineによる自動構築
準備が整ったので、拡張機能構築用のプロンプトを投入します。
あなたは優秀なChrome拡張機能エンジニアです。
以下の仕様に基づいて、Chrome拡張機能(Manifest V3)をゼロから開発してください。
VSCodeのワークスペース上で必要なファイル群を生成し、実装を進めてください。複雑な実装になるため、一度に全てを作るのではなく、ステップバイステップで実装と動作確認を行ってください。
【開発環境・技術スタック】
- ターミナル環境: PowerShell (ps) を使用すること
- 実行環境: Node.js
- フレームワーク: Plasmo (Chrome Extension Framework)
- 言語/UI: TypeScript, React (Plasmoの標準構成を利用)
- Chrome Extension Manifest V3 (Plasmoのビルドプロセスに準拠)
【仕様要件】
1. ウィンドウサイズ変更機能
- ウィンドウサイズによるサイズ変更と、ビューポートサイズ(コンテンツ表示領域)によるサイズ変更の両方に対応すること。
- デフォルトテンプレートとして、一般的に使われるサイズを4〜5種類用意すること(例: スマホ縦/横、タブレット、PC標準など)。
- 任意のカスタムサイズを設定・保存できる機能(ウィンドウサイズ基準、ビューポートサイズ基準の両方)を実装すること。
- カスタムサイズ入力時は、カレントディスプレイ(現在の画面解像度)を基準とし、現実的な最大値・最小値でバリデーションを行うこと。
2. ポップアップ(アイコンクリック時のメニュー)
- コンパクトで使いやすいUIにすること。
- システムのダークモード/ライトモードに自動で準拠するCSS(またはTailwind等)を実装すること。
- 現在のウィンドウサイズとビューポートサイズをリアルタイム(ポップアップを開いた時点)で表示すること。
- サイズのテンプレート選択ボタンを配置すること。
- 任意サイズの追加・削除画面をここからシームレスに呼び出せるようにすること。
3. スクリーンショット機能
- 画面の「表示部分(Visible Tab)」のスクショ撮影機能。
- 画面の「ページ全体(Full Page)」のスクショ撮影機能(スクロールして結合する、またはデバッガーAPIを使用するなど適切な手法で実装)。
4. スクリーンショット保存・設定機能
- 保存先:標準のダウンロードディレクトリ配下の「Captures」フォルダとする。
- ダウンロード機能(chrome.downloads API)を使用すること。
- 保存ファイル名デフォルト:「screenshot_YYYYMMDD_HHMISS.jpg」
- 画像形式:JPG
- 拡張機能の設定画面(Optionsページ)を作成すること。
- 設定画面で「Captures」のディレクトリ名を任意の文字列に変更可能とすること。
- 拡張機能の設定データの保存は `@plasmohq/storage` などを活用し、デフォルトで `local` を使用し、設定画面から `sync` を切り替えて選択できるようにすること。
5. アイコン
- ウィンドウのサイズ変更をイメージできるようなSVGアイコンを仮作成し、Plasmoの仕様(assets/icon.png等)に従って配置すること。
6. バージョン管理
- package.json等を利用した標準的なバージョン管理を行うこと。
7. ドキュメント管理(README)
- プロジェクトの概要、ディレクトリ構成、インストール手順、ビルド手順(開発サーバーの起動方法など)、および現在の実装状況をまとめた `README.md` をルートディレクトリに作成すること。
- 以降、機能の追加・修正、またはビルドプロセスが発生する都度、必ずこの `README.md` を最新の状態に更新すること。
【実装の進め方(提案)】
PowerShellを使用して以下の順序で実装を進め、各ステップが終わるごとに報告してください。
※重要1※ ターミナルでの入力待ちによるフリーズを防ぐため、`npm create plasmo` などの対話型CLIコマンドは絶対に使用しないでください。
※重要2※ 各ステップの完了時、またはコードに大きな変更を加えた際は、必ず `README.md` を更新して変更履歴や現状の仕様を追記してください。
1. Plasmoプロジェクトの手動初期化:
- 対話型コマンドは使わず、ファイル出力ツールを用いて手動で `package.json`、`tsconfig.json`、最低限のReactボイラープレート(`popup.tsx`等)を直接作成してください。
- その後、PowerShellで `npm install` のみを実行して依存関係を解決してください。
- 必要な権限(tabs, activeTab, storage, downloads, scripting 等)は `package.json` の `manifest` オプションに設定してください。
- 仮アイコンの配置と、最初の `README.md` を作成してください。
2. ポップアップUI(Reactコンポーネント)の作成(ダークモード対応込み)。
3. ストレージロジックの構築(`@plasmohq/storage` を用いた local/sync の切り替え、設定の保存・読み込み)。
4. ウィンドウ/ビューポートのサイズ変更ロジックとバリデーションの実装。
5. スクリーンショット撮影とダウンロード処理の実装。
6. オプションページ(設定画面)の実装。
それでは、ステップ1のファイル作成と `npm install` から作業を開始してください。修正したプロンプト。Open AI と Google はこちらのプロンプトで作成しました。
あなたは優秀なChrome拡張機能エンジニアです。
以下の仕様に基づいて、Chrome拡張機能(Manifest V3)をゼロから開発してください。
APIコストを最小限に抑えるため、途中でユーザーへの確認や報告を待つことなく、プロジェクトの初期化から全機能の実装、ドキュメント作成までを「一気に、最も効率的な手順で」完了させてください。
【開発環境・技術スタック】
- ターミナル環境: PowerShell (ps)
- 実行環境: Node.js
- フレームワーク: Plasmo (Chrome Extension Framework)
- 言語/UI: TypeScript, React (Plasmoの標準構成を利用)
- Chrome Extension Manifest V3
【仕様要件】
1. ウィンドウサイズ変更機能
- ウィンドウサイズ基準と、ビューポートサイズ(コンテンツ表示領域)基準の両方のサイズ変更に対応。
- デフォルトテンプレート(スマホ縦/横、タブレット、PC標準など4〜5種類)を用意。
- 任意のカスタムサイズの設定・保存機能(ウィンドウ・ビューポート両対応)。
- カスタムサイズ入力時は、カレントディスプレイ(現在の画面解像度)を基準とした現実的な最大値・最小値でバリデーションを実施。
2. ポップアップ(アイコンクリック時のメニュー)
- コンパクトで使いやすいUI。
- システムのダークモード/ライトモードに自動準拠するCSS(またはTailwind等)を適用。
- ポップアップを開いた時点の現在のウィンドウサイズとビューポートサイズを表示。
- サイズのテンプレート選択ボタンを配置。
- 任意サイズの追加・削除画面をシームレスに呼び出せる設計。
3. スクリーンショット機能
- 「表示部分(Visible Tab)」の撮影機能。
- 「ページ全体(Full Page)」の撮影機能(スクロール結合やデバッガーAPI等、適切な手法を選択)。
4. スクリーンショット保存・設定機能
- 保存先:標準のダウンロードディレクトリ配下の「Captures」フォルダ。
- ダウンロード機能(chrome.downloads API)を使用。
- デフォルトファイル名:「screenshot_YYYYMMDD_HHMISS.jpg」(画像形式:JPG)
- 拡張機能の設定画面(Optionsページ: `options.tsx`)を作成。
- 設定画面で「Captures」のディレクトリ名を任意の文字列に変更可能にする。
- 設定データの保存は `@plasmohq/storage` を活用し、デフォルトで `local` を使用、設定画面から `sync` へ切り替え可能にする。
5. アイコン
- ウィンドウのサイズ変更をイメージできるSVGアイコンを仮作成し、Plasmoの仕様(`assets/icon.png`等)に従って配置。
6. バージョン管理
- package.jsonを利用した標準的なバージョン管理を実施。
7. ドキュメント管理(README)
- プロジェクト概要、ディレクトリ構成、ビルド・起動手順、および実装した仕様を網羅した `README.md` をルートディレクトリに作成。ビルドやファイル構成が完了した最終段階で、実際の状態に合わせて正確に記述すること。
【実装の実行プロセス(一括実行用)】
ターミナルでの入力待ちによるフリーズを防ぐため、`npm create plasmo` などの「対話型CLIコマンド」は絶対に使用しないでください。以下のプロセスをシームレスに連続実行してください。
1. プロジェクト基盤の手動作成
- `package.json`(Manifest設定や必要な権限 `tabs, activeTab, storage, downloads, scripting` 等を含む)、`tsconfig.json` をファイル出力ツールで直接作成。
2. 依存関係のインストール
- PowerShellで `npm install plasmo react react-dom @plasmohq/storage` などの必要なパッケージを非対話形式で一括インストール。
3. ソースコードの生成
- `popup.tsx` (メインUI)、`options.tsx` (設定画面)、背景処理・ユーティリティロジック等のファイルをすべて作成。UIからロジックまで完全に動作する状態に仕上げる。
4. アセットの配置
- アイコン用ディレクトリを作成し、仮の画像ファイルを配置。
5. READMEの作成
- 完成した構成を元に `README.md` を出力。
途中で致命的なエラーが発生しない限り、一気通貫で全ファイルを生成し、完成状態にしてから作業完了の報告を行ってください。それでは作業を開始してください。
↑プロンプトをメッセージ欄に入力し送信します。

↑途中 Approve に応じた対応は必要になりますが、それ以外は自動で拡張機能が作成されます。(今回の場合だと、プロンプトに構築段階で停止する指示がはいっていたため都度再開する必要がありました)
各モデルに作らせた拡張機能の比較
Clineと組み合わせるモデルによって、開発の成果物にどのような違いが出るのか興味があったため、3つのモデルそれぞれに、同じ仕様を記載したプロンプトを渡し構築してみました。
先にまとめてしまいますが、次のような結果でした。
| モデル | 仕上がり |
|---|---|
| Claude Sonnet 5 | UIの出来が良い。機能面はあと一歩という印象だが、不具合箇所を追記で指示すればすぐに直りそう。 |
| OpenAI Sol 5.6 | UI・機能ともにやや残念な仕上がり。修正を重ねていけば良くなりそうだが、根気がいりそう。 |
| Google Gemini 3.1 Pro | UIの出来が良く、機能面も惜しい仕上がり。こちらも不具合箇所を指摘すれば素直に直りそうな手応え。 |
以降、詳細を記載します。
Anthropic (Claude Sonnet 5)
UIのデザイン

使用トークン(コスト)
💰 コスト(API費用)
- 発生コスト: $20.3822
※これについてはプロンプトと動作環境に問題があり、7~8割は必要以上のコストがかかってしまっている
📊 コンテキストウィンドウ(Context Window)
- 使用量(Used): 221.4k トークン(全体の 22.1%)
- 最大容量(Total): 1.0m(100万)トークン
- 残容量(Remaining): 778.6k トークン
🔢 累積トークン使用量(Token Usage)
- 総トークン数(Token Usage): 24.9m(約2490万トークン)
- 入力(Prompt Tokens): 7.2m トークン
- 出力(Completion Tokens): 125.9k トークン
- キャッシュ書き込み(Cache Writes): 514.9k トークン
- キャッシュ読み込み(Cache Reads): 17.0m トークン
📂 生成されたファイル構成
E:.
├─.plasmo
├─assets
├─build
├─node_modules
├─scripts
└─src
├─components
└─lib- 最もモダンで保守性の高いアーキテクチャ
- 特徴: Plasmo推奨の
src/ディレクトリ構成(src/components,src/lib)を採用。 - 評価:
- プロジェクトルート直下にファイルを乱立させず、コンポーネント(UI)とロジック(
lib)をsrc/配下に分離するベストプラクティスを遵守している。 scripts/ディレクトリも作成しており、ビルド・デプロイや各種自動化タスクまで見据えた構造を意識している。- スケールしやすく、手動でのリファクタリングが最も不要なクリーンなファイル構造。
- プロジェクトルート直下にファイルを乱立させず、コンポーネント(UI)とロジック(
動作確認結果
| チェック項目 | 結果 |
|---|---|
| ウィンドウ基準でのサイズ変更 | ◯ |
| ビューポート基準でのサイズ変更 | ✕ |
| カスタムサイズの追加 | ◯ |
| 表示部分のスクショ | ◯ |
| ページ全体のスクショ | ✕ |
一発作成直後のリポジトリ

Open AI (Sol 5.6)
UIのデザイン

使用トークン(コスト)
💰 コスト(API費用)
- 発生コスト: $0.3346
📊 コンテキストウィンドウ(Context Window)
- 使用量(Used): 27.8k トークン(全体の 2.6%)
- 最大容量(Total): 1.1m(110万)トークン
- 残容量(Remaining): 1.0m(100万)トークン
🔢 累積トークン使用量(Token Usage)
- 総トークン数(Token Usage): 321.1k トークン
- 入力(Prompt Tokens): 27.9k トークン
- 出力(Completion Tokens): 13.0k トークン
- キャッシュ読み込み(Cache Reads): 280.2k トークン
📂 生成されたファイル構成
E:.
├─.plasmo
├─assets
├─build
├─node_modules
├─contents
└─utils- コンテンツスクリプト重視のフラット構成
- 特徴: ルート直下に
contents/(Chrome拡張機能の Content Script 用フォルダ)とutils/を配置。 - 評価:
- Plasmo特有の
contents/ディレクトリ(Webページへの画面注入スクリプト)をルート直下に展開している。 src/による階層構造は使わず、ルート直下にフォルダを並べるフラットな設計。- 迅速に単一機能の Content Script を動かすのには適しているが、機能が増えるとファイル整理が必要になりそう。
- Plasmo特有の
動作確認結果
| チェック項目 | 結果 |
|---|---|
| ウィンドウ基準でのサイズ変更 | △ 変更されるサイズとされないサイズがある |
| ビューポート基準でのサイズ変更 | △ 変更されるサイズとされないサイズがある |
| カスタムサイズの追加 | ◯ |
| 表示部分のスクショ | ✕ |
| ページ全体のスクショ | ✕ |
一発作成直後のリポジトリ

Google AI (Gemini 3.1 Pro)
UIのデザイン

使用トークン(コスト)
💰 コスト(API費用)
- 発生コスト: $0.7362
📊 コンテキストウィンドウ(Context Window)
- 使用量(Used): 40.2k トークン(全体の 3.8%)
- 最大容量(Total): 1.0m(100万)トークン
- 残容量(Remaining): 1.0m トークン
🔢 累積トークン使用量(Token Usage)
- 総トークン数(Token Usage): 336.2k トークン
- 入力(Prompt Tokens): 172.1k トークン
- 出力(Completion Tokens): 30.4k トークン
- キャッシュ読み込み(Cache Reads): 133.6k トークン
📂 生成されたファイル構成
E:.
├─.plasmo
├─.vscode
├─assets
├─build
├─node_modules
├─scripts
└─utils- 開発環境の気配りと独自構造の混合
- 特徴:
.vscodeフォルダを唯一自動生成、コンポーネントはルート配下のutils/に配置。 - 評価:
- VSCode環境の設定ファイル(
.vscode)を用意して開発効率に気を配る姿勢が見られる。 - 一方で、コード配置については
src/を使わずルート直下にscripts/やutils/を並べるスタイル。 - UIコンポーネントの分離や構成の整理という面では、ややクラシックな構造
- VSCode環境の設定ファイル(
動作確認結果
| チェック項目 | 結果 |
|---|---|
| ウィンドウ基準でのサイズ変更 | △ 変更されるサイズとされないサイズがある |
| ビューポート基準でのサイズ変更 | ✕ |
| カスタムサイズの追加 | ◯ |
| 表示部分のスクショ | ◯ |
| ページ全体のスクショ | ◯ |
一発作成直後のリポジトリ

さいごに
今回Clineを試してみて、一発構築とはいかないまでも、想像以上に動くものが作れると実感しました。API費用を抑える工夫や、優秀なClaude系以外のモデルを使う場合のプロンプト調整など、やり方次第でいくらでも実用的に使えそうです。
そして何より、「Plasmoなどのフレームワークや、拡張機能の基本を学ばずにいきなり作れる」という時短効果は圧倒的です。学習コストをすっ飛ばせるのは、AI開発の一番のメリットだと感じました。
仕事の効率化にも間違いなく活かせるので、今後も色々と試していきたいと思います。
今回の拡張機能、その後・・・
Claudeが作ってくれたもう一歩二歩足りない生成物をベースに、動かない部分の修正や、細かい部分の仕様を詰めて、想定した機能がまともに動くところまで改修しました。
出来上がった拡張機能は折角なのでウェブストアに登録し公開しました。とはいえこの手の機能は多数あるので使ってくれる人がいるかはわかりませんが、何事も経験ということで・・・。






コメント