アフィリエイト

Macの検索順位チェックツールはWine+GRCが効率とコスパ抜群!

SERPOSCOPEが正常に動かない状態が続いているので、MacでWineを使ってGRCを動かす方法に移行しました。その判断に至る経緯、設定方法、運用してみた感想をご説明します。

Parallelsに代わるWineを発見!

Macbook Pro(2017)を自宅筋トレ中の事故で壊してしまったので、この度、M2 Macbook Airを購入しました。次の記事で説明したように、丁度Googleの仕様変更の都合でSERPOSCOPEが動かなくなってしまっていて、検索順位チェックツールを移行しようと考えていました。

GRCは即捨てろ!SERPOSCOPEの評判と使い方!使えないなんて嘘!GRCの使いづらさにうんざりしてきたので、SERPOSCOPEに乗り換えました。使い方と使ってみた感想をお伝えします。 202...

SERPOSCOPEの前は、Parallels DesktopでWindowsを走らせてその上にGRCを動かすという方法をとっていました。MacBook Pro(2017)には重い処理だしメモリーも不足気味で、筐体が熱くなってしまいました。それが嫌だったのと、コスパも良くなるので、SERPOSCOPEに移行した経緯があります。

M2 Macbook Airになるとスペックは圧倒的に良くなるので、Parallels×Windows×GRC という方法でも余裕になるかと思いました。当然、SERPOSCOPEと同じように、GRCだってGoogleの仕様変更の影響を受けるはずです。なのでGRCもまともに動かない状態なのではないかと気になって調べてみたところ、全くそのような情報は出ていません。GRCは有料だし、日本では圧倒的にSERPOSCOPEよりもユーザ数が多いので、問題があれば必ず話題になっているはずです。なので現状正常に使えているということです。どのようにGoogleの仕様変更を乗り越えたかは分かりませんが、決して安くはない使用料をとっているだけありますね。

そこで、Parallels×Windows×GRCの設定を開始しようとしたら、なんと以前購入たParallels Desktop 11はM1やM2などのAppleシリコンに対応していないので、執筆時点で最新のParallels Desktop 18を購入する必要があるということがわかりました。そして、以前も使っていた無料で利用できるWindows10もAppleシリコン(正確に言うとARMアーキテクチャ)に対応していないので、ARM に対応しているWindows11を購入する必要があると言うことです。

Parallels Desktop for Mac のシステム要件

以下によると、Parallels Desktop17でも大丈夫そうですね。M1に対応していると書いてあるので。

Parallels Desktop 17 のシステム条件とサポート対象のゲスト オペレーティング システム

また、ARMに対応しているWindows10でもいける気がしますね。

とはいえ、Win10もWin11もARM版の利用は、開発者向けのWindows Insider Programを使うなど、少しトリッキーな気がするので、初心者は苦戦するかもしれません。ちゃんと調べてないのでわからないですが。

困ったなーと思いながらGRCの公式サイトを眺めていると、以下のページを見つけました。

Wineを用いてMacでGRCを利用する方法

こんなページ前からあったっけ?Wineというツールは使ったことがないのですが、名前は知っていました。でも、あまり使い物にならないイメージを勝手に持っていました。

ただ、現在の最新のMac OSにはWineが対応していないので、使えないと書いてあります。何にでも疑ってかかる私は、ほんとかなーと思いながら、M2 MacでWineが使えないか調べてみました。するとあっさり以下が見つかりました。

macOSでWinアプリを実行する第3の方法、しかもWindowsのライセンスは不要です

AppleシリコンのMacで見事に秀丸というWindowsのアプリケーションを動かしています。秀丸が動いてGRCが動かない理屈はありません。

しかも、Wineにもいくつか種類があって、この記事で扱っている「homebrew-wine」はオープンソースなので完全に無料で利用できます。ということは、ParallelsとWindowsのライセンス代が浮きます。素晴らしい!

さっそくやってみた。結論から言うと問題なく動いた。GRCの公式サイトで現在は対応されていないと書いていたが、おそらく最新の状況が反映されていないということだろう。

では、設定方法を説明していく。

スポンサーリンク

コマンドラインでの設定はハードル高いかも

homebrew-wineはコマンドライン(エンジニアが使う黒い画面)を基本的に使うので、慣れていない人は少し抵抗があるだろう。でも、MacはWindowsに比べてコマンドラインを使う機会が多くなるので、この際慣れておいてもいいかもしれない。(コマンドラインがどうしても嫌な人は、先ほどの記事で少し紹介されていたWineskinを使ってみるといいかもしれない。)

今回の手順で使用した環境のバージョンを記載しておく。

端末 M2 MacBook Air(2022)
Mac OS 13.0(22A380)
homebrew 3.6.17
wine-crossover 22.0.1
GRC 5.65.274.1

まずは、homebrewを使っていない人は、以下を参考にしてインストールしよう。

macOS(またはLinux)用パッケージマネージャー

homebrewもエンジニアがよく使うツールで、Macのアプリケーションのインストール、バージョン管理、アンインストールなどをコマンドラインでできるようにするもの。

ここからは先程紹介した秀丸を例にした記事とやり方はほぼ同じだが少しイレギュラーなところもあったので、詳しく手順を説明していく。

まずはGRCの公式サイトから、通常通りGRCsetup.exeというインストールファイルをダウンロード。

ちなみに、GRCは課金していない段階でもある程度は使うことができるので、まだ迷っている方も、課金する前にこの方法を試してみてもいいかもしれない。

ここからはコマンドラインでの作業。Macに最初からインストールされている「ターミナル.app」のコマンドラインを扱うアプリケーションを開く。そして以下を入力。


ここが秀丸の記事と違う部分だが、以下のようなエラーが出た。


10行目によるとMFC42.DLLというライブラリーが足りていないようだ。ネットで調べた結果、以下を見つけた。

Linuxでもハヤえもんを使う方法

これに従い、以下のようにWineの設定を変更できるwinetricksというものをインストール。


そして、これを使って不足していたMFC42.DLLをインストール。


この途中で以下のようなプロンプトが立ち上がって来た。

ドイツ語だが、Yesに相当する「Ja」をクリック。

そしてもう一度以下を実行。


すると以下のようなアラートが出ることがあるのだが、基本的には全部OKで進める。私の  Macは言語を英語に設定してしまっているのでの英語になっているが、日本語にしている場合は日本語で表示される。

すると、Windowsで普通にインストールする時のようなセットアップ画面が表示されます。ちなみに、Macの言語を英語にしていると、文字化けしてしまう。なので、私はこのタイミングでMacの言語を日本語にした。

Macの言語を英語にして文字化けさせない方法としては、以下でいけた。

CJK Fonts in WINE

記憶が曖昧なのだが、もしかしたらフォントの導入は不要で環境変数の指定だけでいけたかもしれない。

標準インストールでもいいし、カスタムにしてインストール先などを変えてもいいです。ショートカットなど作る必要はないので、カスタムで進めてみた。

以下のように、デフォルトだと

C:\Program Files (x86)\Shellware\GRC

にインストールしようとする。

これは、Macで言うと以下に相当する。

/Users/xxxx/.wine/drive_c/Program Files (x86)/Shellware/GRC

つまり、Wineが自動的にMacのホームディレクトリ配下に.wineというディレクトリを作って、仮想的にWindowsのディレクトリ構成を作る。ちなみに、「.wine」という文字列は変数で変えることもできるので、複数の環境を運用することも可能。

そして、「参照」ボタンを押すと、インストール場所を選べるのだが、なんと.wine配下ではない場所も選ぶことができる。以下のようにZドライブがMacの最上位にリンクされているからだ。

インストールが完了したらコマンドラインから以下でGRCを起動できる。引数には先程インストールした場所にあるGRC.exeをフルパスで指定する。


すると見事にGRCが起動できる。

起動するまでにかかる時間が本当に普通のMacアプリと同じくらいです。Parallelsの場合は、Parallelsを起動⇒Windowsの起動⇒GRCの起動と手間と時間がかなりかかっていたことに気がついた。

読みにくい字を綺麗にする

よく見ると、メニューの文字が小さいしギザギザしていて読みづらい。

左下のステータスバーに表示される文字も同じ感じ。

これは設定で見易くすることができる。winecfgというものでフォント周りの設定を変更することで対処することがでる。以下を参考にした。

wine+DominoやJtrimのサブメニューの文字化け解消


をすると、以下のような設定画面が開く。

「デスクトップ統合」から「項目」で「メニューのテキスト」を選び、「フォント」をクリックする。これはGRCのメニューのフォントを変える手順。

次に見やすいフォントを選ぶが、私の場合はMacの標準的なフォントであるヒラギノ角ゴシックにした。なので、「フォント名」は「ヒラギノ角ゴシック W5」、「スタイル」は「標準」、「サイズ」は「10」にした。

ステータスバーの文字については、「項目」で「ヒントのテキスト」を選択して同じようにフォントを設定する。GRCを再起動すると設定が反映される。

ただ、ステータスバーはなぜか9という文字の大きさだけ小さくなってしまう。

スポンサーリンク

普通のMacアプリと同じように起動できるようにする

無事GRCを起動できたものの、毎回いちいちコマンドラインから起動するのが面倒だ。なので、以下の記事を参考にGRCを起動するだけのMacアプリを作る。

Macでシェルスクリプトを .appアイコン化する方法

記事と違う部分は入力するスクリプトとシェルにはzshを選ぶこととアイコンの画像だけ。アプリの名前は何でも良いが「GRC」にしておくと綺麗。

スクリプトは以下。


これで以下のように普通のMacアプリと同じようにアイコンができる。これをクリックするだけで、GRCが起動できる。もちん、Dockにも配置できる。

ところで、先程のスクリプトはコマンドラインで入力したコマンドと違う。このスクリプトのポイントを説明しておこう。wine64をフルパスで指定すること。GRC.exeのパスはあなたの環境に合わせて変えること。

そして、 >/dev/null 2>&1 & の部分は、以下を参考に処理がバックグラウンドで走るようにしたもの。

Automator gets stuck at shell script

これが無くても動くのだが、無い場合、Automatorが処理が実行中だと認識してしまい、Macのメニューバーの右側にGRCを起動している間ずっと「0%完了」と表示されてしまい、気持ち悪い。

アイコンの画像も設定しなくてももちろん使えるが、そうするとAutomatorと同じアイコンということだ。

わかりやすくしたいので私はGRCのアイコンの画像を取得して設定した。どのようにGRCのアイコンの画像を取得するかというと、次のツールを使った。

Icon Explorer

これもWindowsアプリなのでWineで実行する。zipファイルをダウンロードして解凍するとexeファイルが出てくるので、以下で起動できる。


なぜか画面が緑色なのだが、一応使える。インストールしたGRC.exeを選び、表示される GRC_0をクリック。

右側に表示される一番大きいアイコンを右クリックして表示される「Save toPNG」をクリックする。

次に表示される背景色を決める画面で、なぜか透明やWhite以外を選択しないときちんとしたアイコンの画像が出力できない。なので、私は適当に以下のようなMoney Greenを選んだ。透明やWhiteを選んでしまうと、なぜかアイコンの画像が透過したものになってしまう。

適当な場所にアイコン画像を保存し、先程の記事の手順でAutomatorで作ったアプリのアイコンに適用すると、こんな感じでGRCのアイコンになる。

ドックに配置した場合は以下のような感じ。

ほとんど通常のMacアプリと同じ感覚になるのだが、一つ違和感があるのが、起動した後、以下ようにDockにもう一つGRCのアイコンが出現すること。しかも、カーソルを近づけて表示されるアプリ名が「wine64-preloader」となる。

通常のDockにあるMacアプリは起動しているときは、そのアイコンの下に「・」が表示されるだけのはずだ。まぁ、これは些細なことなので、対処するのは諦めた。

チェックも正常にでき、有料ライセンスも正常に使えた!

いくつか適当に検索ワードと対象サイトを登録してチェックしてみたところ、正常に確認できた。また、有料のライセンスを購入して、認証もできた。さらに、以前のParallelsで運用していたGRCから持ってきた大量のデータをインポートして、大量のキーワードをチェックしたところ、全て正常にチェックできた。

スポンサーリンク

Parallelsに比べて圧倒的にマシンリソースを節約できる!

Wineは一説にはWine Is Not an Emulatorの略だと言われている。Parallelsのようにエミュレーションを行っているわけではないのでパフォーマンスのロスが少ないとされる。簡単に言えばWineは、Mac上でWindowsを動作させているのではなく、MacにWindowsと同じ挙動をさせているのである。

なので、速度的にもParallelsより速い。ただ、GRCで時間がかかる順位チェック処理が短くなると言うことはなさそうだ。というのは、この時間は、検索エンジンからのレスポンスを待つ時間や、意図的に何もしない時間が中心だからだ。なので、速さは画面上のもっさり感の無さ、キビキビ感に差が出る。

そして、マシンリソースへの負荷はどのくらい違うのかも気になったので調べてみた。

同じ筐体ではないしMac OSのバージョンも違うので正確な比較ではないかもしれないが、ざっくりした比較は可能と思われる。古いMacbook ProにあるParallelsでGRCを起動した状態で、アクティビティモニターで表示されるCPUとメモリーの使用状況を調べた。

わー、なんとParallels関連のプロセスのCPU使用率を合計すると、240.2%になっていた。100%超えてるのってどういうこと?って思ったが、CPUのコアが複数あるマシンなので一つ以上のコアを使っている場合は、100%を超えることもあるとのこと。

ちなみに、「Windows7」とあるが、実際はWindows10が走っている。仮想マシンの名前をアップグレード時に変え忘れたままだったので。

あと、Windowsの画面を前面に出していない時は、しばらくするとCPU使用率は5%程度に激減する。おそらくスリープしているのだと思われるが、結局Windows側を触るとすぐに100%を越えてしまう。

次に、今回導入したWineのCPU使用状況を見てみる。

wine64-preloaderとwineserverというプロセスが対象のプロセスになるが、合計すると26.2%となる。これはGRCを操作している時も、そうでない時も大きな変動はない。

これだけ違うと電力消費量も大きく違うだろう。Parallelsを使っていた時、筐体が熱くなってファンがブンブン回っていたのを思い出した。

次にメモリの使用状況を見ていく。まずはParallelsの方。

合計すると1.75GB程度とすごい大きさ。しかも、Windowsが前面にない時も、特に減るわけではない。

次にWineの方を見る。

こちらはたったの87MB。これは圧倒的な差。

明らかに、Wineの方がマシンリソースの使用効率が高いことがわかる。Parallelsの時によくあったメモリ不足に陥ってパソコンが遅くなる機会も減らせそうだ。

マシン上のディスク容量がどのくらい使われるかも比べておこう。Parallesではpvmファイルというのがデータとなる。私の「Windows 7.pvm」はなんと41.08GBもあった。GRCしか使っていないのに。

Wineでは基本的に.wineディレクトリ配下にデータが入る。.wineはわずか386.2MBだった。これを見ても圧倒的に効率が良い。

Wine Parallels
CPU使用率 26.2% 240.2%
メモリ使用量 87MB 1.75GB
ディスク使用量 386.2MB 41.08GB

Wine側のバージョンは前述したが、一応、Parallels側の環境のバージョンも記載しておく。

端末 MacBook Pro(2017)
Mac OS 10.13.6
Parallels Desktop 11
Windows Windows10
GRC 5.62.274.1

プロセスが残ってしまって起動できなくなる?

全く不満無く使えそうだったのだが、不可解なことがあった。

アクティビティモニタでCPUのプロセスを見ると、wine64-preloaderがたくさん立ち上がっているのだ。

GRCしか起動していないので一つでいいはずだ。使用率が0なものがほとんどだ。おそらく、20.1のものしか実際には使われてはいないのだろう。しかし、不思議なことにメモリタブの方を見ると、全てある程度の数字が入っていた。20.1のもの以外全て強制終了してみたところ、問題なくGRCは動き続けた。

さらに不可解なことが起きた。前述したwinecfgでフォントを変えてGRCに反映させるのを繰り返し行なっていた時だった。急にGRCが起動しなくなった。winecfgも起動しなくなった。アクティビティモニタを見ると、数え切れないほどのwine64-preloaderが立ち上がっていた。

やはり、winecfgやGRCなどのWindowsアプリを起動するたびに、wine64-preloaderというプロセスが起動するということだ。アプリを停止した段階でプロセスも消えるはずだが、なぜか消えなくて大量のプロセスが残ってしまうということのようだ。

とりあえず、wine64-preloaderを全て強制終了していく。しかし、数百個はありそうで、まとめてできずに、少しずつ選択して終了していくのでかなり時間がかかった。

全部終了できたので、再びGRCを起動しようとした。しかし、起動しない。winecfgも起動しない。不思議だ。色々調査したが原因はわからなかった。.wine配下に何かゴミが残ってしまっているのだろうか。Windowsでいうレジストリ周りにゴミが入ってしまっているのだろうか。

とりあえず、.wineディレクトリをリネームして、新たに.wineを作成したらGRCが起動できた。(普通にwine64で初めてWindowsアプリを起動する時に.wineディレクトリが作成される)

原因追究のため、リネームした.wineと新しい.wineのdiffをとって比べようとしたが、複雑にシムリンクされているのでうまくdiffの結果が出なかった。なので、とりあえず原因追及は次に起きた時にする。とりえず.wineを新規作成すれば動くようになるとわかったのでそれで満足。ただ、古い.wineを削除する場合は、GRCのデータを失わないように退避しておくのを忘れないように。

以下の記事によるとMac再起動でも動くようになるかもとあるので、次は試してみようと思う。

A bunch of wine-preloader processes are throttling my CPU when running Steam

Parallelsの場合は利用者も多いのでネット上に情報が多く、謎が残ることは少なかったが、Wineの場合は少しマニアックで、情報もそんなに多くないし、色んなバージョンがあり、定石的な使い方も確立していないように思える。不安な方は、Wineを使った有償でサポートがある以下の製品がある。とはいえ英語の製品なので、英語がある程度できないとサポートを受けるのも難しいかもしれないが。

CrossOver Mac

スポンサーリンク

カーソルがGRCから出られなくなる

しばらく使っているとカーソルがGRCのアプリの外に出られなくなる事象が発生した。しかたがないので、左上の赤ボタンをクリックして終了したら出られるようになった。再びGRCを起動するとそのような事象は起きなかった。

また、しばらく使っているとまたカーソルがGRCから出られなくなった。これが起きるたびに赤ボタンでアプリを停止するのも気持ち悪いし、処理が走っている場合は中断してしまうので、今度は左上の黄色ボタンをクリックしてみた。これを押すと、停止するわけではなくDockに小さく収まる。これでカーソルは自由に外に動けるようになった。ドック内に入ったGRCをクリックするとカーソルも自由に動ける状態で再び開くことができた。

時々このカーソルの事象が起きるのがちょっと気になるが、致命的な問題ではないのでまだ調査はしていない。

チェック処理中にMacがスリープしたらエラー

GRCのチェック処理は長い時間がかかりがちだ。WineでGRCの処理を流している時に、Macがスリープした。スリープから復帰したら以下のエラーが出た。

これが出ると、GRCを再起動しないと、再び処理を開始できなかった。スリープすると100%起こるわけではないが、時々こういうことがある。なので、GRCのチェック処理を流すときはスリープしないようにMacの設定をする必要がある。Macbook A
irは、持ち歩くノートパソコンなので基本的にはスリープする設定にしておきたいので悩ましい。

Parallelsの時は、Macがスリープしてもスリープ解除したら知らぬ間に処理をよしなに再開してくれていた。先ほどのカーソルのような事象も起きない。さすがParallelsは有料ソフトだけあって、この辺りのユーザビリティは考えられている。

スポンサーリンク

Macアプリからのコピー&ペーストができない?

Evernoteというノートアプリで検索キーワードをまとめていて、それをまとめてコピー&ペーストでGRCに持ってきてペーストしようとしたらできない。何も文字が出てこない。GRC内でのコピー&ペーストは機能している。

試しにGRCを再起動したら、Evernoteからのコピー&ペーストができるようになっていた。何だったのだろう。やはり少し不安定。とはいえ、そんなに致命的な問題ではないので我慢する。おかしな事象が起きたらとりあえずGRCの再起動で対処する。

共有ドライブに.wineを配置したら複数端末から使える?

まだやっていないのだが、.wineディレクトリをDropboxなどのリモートディスクに配置して、使う時は端末にマウントして動かせば、もしかしたら複数端末から利用できるかもしれない。GRCのライセンス認証がどのような仕組みで行われているかわからないが、認証データが.wine内に配置され、物理的に端末に紐づかないなら可能だろう。

ちなみに、こちらもやっていないが、Parallelsで運用する場合でも、理論上はpvmファイルをリモートディスクに配置して複数端末から使えるはずだ。ただ、pvmファイルは前述したように数十GBもあるので、毎回ネットワークを介して端末に転送するのは現実的ではない。

それに対して、.wineディレクトリをマウントするだけなら、せいぜい400MB程度なので可能だろう。とはいえ、GRCの規約的にこのような使い方をして良いのかは精査していない。リモート上のWindowsに1ライセンス分のGRCを入れて複数端末から使うという使い方は普通にされているようなので、それと同じようなものな気がする。やる場合は、ご自身で規約を確認し、自己責任ですること。

.wineディレクトリを端末間で共有できたら、Macを2台持っている人なら、家にあるMacは常時起動し毎日決まった時間にGRCを走らせる設定にしておいて、出先ではノート型のMacでGRCのデータを確認だけする、といった使い方も可能かもしれない。こうすれば、持ち歩くMacのスリープの設定に悩むことはない。ただ、複数端末から同時にマウントして起動した場合、ファイルが壊れたりしないかといった心配はあるが。

スポンサーリンク

まとめ

Macで検索順位をチェックする手段としてのWine+GRCの良い点、悪い点をまとめておく。比較対象としては、私がこれまで使ったことのあるParallels+Windows+GRCやSERPOSCOPEとなる。

  • WindowsやParallelsのライセンス料がかからない
  • 起動する手間と時間がかからない(Macアプリと同レベル)
  • エミュレーターではないので処理が速い
  • マシンリソースの使用効率が圧倒的に良い
  • コマンドラインからの設定が必要で少しハードルが高い
  • ネットの情報が比較的少なく、自力で解決しなければならない状況が多い
  • スリープ復帰時に落ちる等、少し不安定なところがある

正直、ITに疎い方にはハードルが高いのでこの方法はおすすめしない。でも、現在初心者であっても、ITに関心があって学習意欲がある方は挑戦する価値があると思う。ここで得た知見は、パソコンを少しでも使う仕事をしているなら使えるし、サイト運営でも間違いなく役に立ってくるので。