こんにちは，株式会社ALBERTの太田です。今回はGoogle ChromeのUser ScriptsとContent Scriptsについて，その仕様とGreasemonkeyとの違いを中心に，実際のスクリプトの書き方を交えて解説します。

ユーザースクリプトとは

User Scriptsとは，Google Chrome版のGreasemonkey（ただし，後述の通り互換性はあまり高くありません）です。そもそもGreasemonkeyとは任意のページで任意のJavaScriptを実行し，そのページに機能を追加したり，（自分にとって）不要なものを取り除いたり，異なるサービスとの連携をしたり，といったことをJavaScriptファイルひとつで実現できるようにするFirefoxのAdd-onです。その手軽さと，それに見合わぬ強力なカスタマイズ性能から高い人気を得ています。

しかし，Greasemonkeyはその手軽さと引き換えに安全性を犠牲にしている面があります。AMO（addons.mozilla.org）に公開されているMozillaアプリケーション用のAdd-onはAMO（のレビュアー）による品質管理が行われていますが，userscripts.orgに公開されているGreasemonkey用Scriptはそういったチェックを受けていません。このため使用には十分に注意する必要があります（当然ながら，Add-onについてもAMO以外で公開されているのであれば，より注意が必要です）。これはChromeのUser Scriptsについても同様です（と，少々脅し気味に書きましたが，実際のところ私自身は悪意あるユーザースクリプトというものを見たことはない，ということを申し添えておきます）。

ChromeのUser ScriptsとGreasemonkeyのほかにも，SafariのプラグインのGreaseKitやOperaの標準機能のUserJavaScript，Internet Explorerのコンポーネントブラウザの一部にも同様の機能が実装されています。これらを総称して，ユーザーサイドスクリプトと呼ぶこともあります。

導入

まずは，ChromeのUser Scriptsの動作環境について説明します。ChromeのUser ScriptsはGoogle Chrome 2以降のバージョンで動作します。なお，Chrome 2以前はGreasemetalというプラグインが利用できましたが，Chrome側がネイティブサポートしたためGreasemetalの開発は終了しています。

ChromeのUser Scriptsは起動オプションで --enable-user-scripts というオプションを付けることで使用可能になります。Windows XP, Windows Vistaでのパスは以下の通りです。[username] の部分にはログインしているユーザー名が入ります。

"C:\Documents and Settings\[username]\Local Settings\Application Data\Google\Chrome\Application\chrome.exe" --enable-user-scripts

"C:\Users\[username]\AppData\Local\Google\Chrome\Application\chrome.exe" --enable-user-scripts

オプションを付けて起動すると，ユーザーデータフォルダにUser Scriptsという名前のフォルダが作られます（あらかじめ自分で作成しても問題ありません）。

Windowsの場合，ユーザーデータフォルダは下記の場所になります。一部が隠しフォルダになっているため，探しにくい点に注意してください。

C:\Documents and Settings\[username]\Local Settings\Application Data\Google\Chrome\User Data\Default\

C:\Users\[username]\AppData\Local\Google\Chrome\User Data\Default\

このUser Scriptsフォルダにファイル名が .user.js で終わるスクリプトを置けば，自動でファイルを認識して，@include（もしくは@match）で指定されたページを開いた際にそのスクリプトが実行されます。再起動などは必要なく，ファイルを更新した際も次の読み込み時に即座に反映されます。

User Scriptsの仕様

Greasemonkeyを意識して実装されていますので，動作面ではGreasemonkeyとの互換性があります。

• スクリプトの実行タイミングはGreasemonkeyと同じく，DOMContentLoaded（DOMの構築後，画像などの読み込み完了前）で起動します。

• スクリプトの実行コンテキストがサイト側のスクリプトと分かれています。このため意図せずにグローバル変数を使用してしまったり，サイト側のスクリプトの処理を上書きしてしまうようなことはありません。

ただし，機能面ではGreasemonkeyと異なる部分が多くあります。

• @exclude, @require, @resourceなどのメタデータを使用できません。

• unsafeWindowに相当するサイト側のグローバルオブジェクトがありません（Chrome 2ではcontentWindowという名前でサイト側のグローバルオブジェクトにアクセスできましたが，Chrome 3以降では廃止されています）。

• サイト側のコンテキストでJavaScriptを実行したい場合，ブックマークレット（location.hrefにjavascriptスキームを代入するなどの方法で実現できます）として実行するか，script要素を作ってコードをテキストノードとして挿入する必要があります。

• GM_setValue, GM_getValueなどのGM APIもほとんど使用できません。Chrome 2では名前だけ定義だけされていて，実際には使用できない状態で非常に厄介なことになっていましたが，Chrome 3, 4では定義されていない状態に修正されました。

• GM APIで使用可能なのはGM_addStyle，GM_xmlhttpRequest（ただし，ドメインを超えることはできません），GM_openInTab（実装はwindow.openのラッパー），GM_log（やはりconsole.logのラッパー）の4つです。

また，Chrome UserScript独自の機能もあります。

@matchメタデータ

@matchは@includeの改良版という位置づけで，@includeよりも正確なパターン指定が可能です。@matchはhttpなどのschemeパート，google.comなどのhostパート，/search?などのpathパートに分けてマッチングが行われます。@includeでは http://*.google.com/* というパターンが，http://another.site.com/?.google.com/ にもマッチしてしまうという問題がありますが，こういった問題は@matchでは起こりません。

@includeとは書式が異なる部分が多いので，詳細はMatch patternsを参照してください。特に，Bad patternはやってしまいがちなパターンがまとめられています。

@run-atメタデータ

@run-atはdocument-startと指定することで，ページのDOM構築を待たずに，読み込みを開始したタイミングでスクリプトを実行します。実行タイミングが速いので，例えばショートカットキーなどをこのタイミングで登録すればユーザーの待ちを軽減することができます。ただし，当然ながらDOM要素にアクセスできないため，出来ることは大幅に制限されます。

Content Scriptでも同様のことが可能ですが，run_atとdocument_startという組み合わせであり，ハイフンではなくアンダースコアという違いがあるので注意が必要です。

これらの点に注意すれば，Greasemonkey用のスクリプトをUser Scriptsで動かすことはそれほど難しくありませんが，残念ながらChromeとの互換性を意識して書いていないGreasemonkey ScriptがChromeで動くことは滅多にありません。ただ，OperaやSafariをサポートするスクリプトはChromeでも動作する可能性が高くなります。実際，Greased LightboxはChromeでも動作します。