Moonmile Solutions Blog

ここ１か月ほど、「アメブロのアレ」と称してツイッター上で呟いていたのですが、それのおまとめ。

発端は、「アメブロのランキングを上げたいなぁ」なところで、アフリエイトとか、集客とか（あるい程度はありますが）、ではないので、あしからず。単純に、アクセス数を上げて、ランキングを（ある程度まで）上げる方法を模索しております。

さて、結論から言うと、１年程前の記事が正しいです。

【アメブロのPV水増し】アクセス解析ツールごとのアクセス数の違い【パシのSEOブログ】
http://www.jweb-seo.com/blog/wordpress/2009/04/30/629

アメブロのPVが界王拳並みな件 – カイ士伝
http://blogging.from.tv/wp/2009/04/29/2046

Google Analytics とアメブロのアクセス解析を比較しています。

Goolge のほうは、アメブロより非常に低くPV（Page View）が出ます。

というのも、Google のほうは、Google などのクローラのアクセス数はカウントしませんが、アメブロのほうはクローラのアクセス数もカウントするんですね。

「アクセス解析」自体が、何を以てPVとするか？の問題はさておき、Google とアメブロの「アクセス解析」では、根底のPVの勘定の仕方が異なる、ということです。

これを踏まえた上で、いくつか実験をすると、

■アメブロでは、１回アクセスすれば１つカウントされる

これは、Google からでも百度（パイドウ）からでも同じ。誰かがちょっと間違ってクリックしても、じっくり読んでも、ロボットがやってきても１回と勘定されます。

これは、RSSにアクセスしても、ブラウザでアクセスしても同じです。

更に云えば、

• wgetやcUrlというツールを使って、アクセスするだけでも１つ増えます。

試しに、wgetで、5秒置きに100回アクセスすると、100アクセス分上乗せされました。

■アメブロのランキングは、PVが多ければ上位になれる

アメブロにもランキングがありますが、ランキングの表示の仕方として、

• １位から３位
• １位から１０位
• １位から５０位
• ５１位から１００位

という見え方の違いがあります。

私が狙うのは、「１位から５０位」のところ、５０位以内というページですね。

方法によっては、１位から３位、１位から１０位も十分狙えるのですが、ちょっとフェアでない「方法」なので、５０位位にしておきます（苦笑）。

エンジニアランキング（2,500人程度）の場合は、4000PVで１０位前後、700PVで５０位以内、を目安に考えてください。

そのほかの母数が多いランキングは、もうちょっと別な手段を取らないと上位に食い込めません。

５０位以内を狙うというのは、一言で云えば「弱者は弱者にやさしいかも」の作戦です。アメブロには「ぺた」という機能がありますが、トップ３の著者に対して見返りを期待するよりも、５０位以内のほうが期待値が高いということです。「見返り」というのは、こちらのＰＶをアップさせてくれるかも、ということです。

５０位以下の場合は、ランキングのページから見づらい（トップ１０からアクセスしづらい）という点で、アクセスアップは望めません。なので、一気に、５０位以内を狙って、徐々に安定化させるのがよいでしょう。

■wgetを廻すだけで、PVが増えて、ランクアップする

という訳で、wget で廻すだけでランキングのアップが期待できます。

方法は簡単です。５０位以内が狙える、700PV分だけ廻してしまえばよいのです。

$url = ‘http://ameblo.jp/アメブロID/’;
for ( $i=0; $i<10; $i++ ) {
 `wget $url`;
 sleep(30);
}

こんな風に簡単な perl スクリプトを使って、ぐるぐる廻してしまうだけでPVがアップ、かつ、ランキングがアップできます。

■もう一工夫して、iframeを使う

wget の方法ですが、ちょっと難点があります。

１つだけのマシンからアクセスをするので、IPアドレスが同じなんですよね。なので、「アクセス者数」が少なくて、いっぺんにばれてしまいます。

# 運営サイドにばれるというか、自分以外は見れないので、どうでもいいんですが。

また、毎日 wget のスクリプトを廻さないといけないので、ちょっとむなしいですね。いえ、PVだけを自分で廻すという行為自体が「むなしい」のは、さておき（苦笑）。

アメブロ以外に、そこそこアクセスのあるブログを持っていれば、iframeを使うという方法があります。

ここのブログのソースを見ると、

<iframe src=”http://ameblo.jp/アメブロID/” width=”1″ height=”1″ scrolling=”no”>
</iframe>

な記述がありますね。

こうすることで、このブログのアクセス数を、そのままアメブロのアクセス数に加算することができます。

試してみると、都合よく、Google のクローラのアクセスもアメブロに加算してくれるので、結構簡単にアクセスアップができます。更に云えば、Google クローラの IP が使われるため、「アクセス者数」もアップするんですね。

ちなみに、自分のカウント用に、特定ページを設けておくと、二重帳簿の元ネタが分かるようになります。

■アメブロのペタはランキングに関係ない

さて、一般的にアメブロのランキングを上げるためには、

• 読者を増やす
• アメブロのペタをたくさん貰う

という話がありますが（運営サイドからも）、実験をすると関係ないことが分かります。

というのも、ペタのお返しをする自動ペタツールというのが結構ありまして、これはペタを直接打つんです。

問題は、アメブロのPVには、ルームの閲覧は加算されていない、ってことです。

これは、どういう事かというと、自動ペタツールを作ってみた分かったことなのですが、

1. 自動ペタツールを使う。
2. ルームから「ペタ」のリンクを辿る。
3. ペタのページから、クリックをエミュレートする。

という方法でツールは成り立っています。

ここで、１や２のページは、PVにはカウントされません。故に、アクセス解析にも出ません。故に、ランキングに無関係なのです（今後の方針で変わるかもしれませんが）。

ということは、実は、

読者はペタを沢山増やしたとしても、ルームなどから直接ペタをしたときには、ランキングに貢献しない。

という結論になります。

きちんと、ブログを読んで、ペタをしている方には効果があるのですが、自動ツールはこのような問題（？）があります。

■更新回数を増やせばランキングがあがる

という訳で、アメブロの更新回数を単純に増やせば、ランキングは単純に上がります。

これは、

1. 更新回数を増やす。
2. Google のクローラがPVを増やす。
3. PVが直接、ランキングに反映される。

という流れで、ランクが上がります。

なので、SEO対策としては、人相手ではなく Google のような機械相手にやればOKってことです。

～～

ちょっと長くなったので、効果的なアクセスアップの方法は後日。

今、私が取っている戦略としては、

1. iframeで下駄を履かせて、５０位以内にする。
2. ５０位以内をキープして、見返りを求める（ペタとか、でもランキングに関係ない）。
3. 更新回数を徐々に増やす。
4. 英単語、コンピュータ用語を交えて、アクセスアップ

なところです。

４ですが、Google のクローラと関係してくるところです。

粘菌コンピュータの続きを20分ほど。

時間に関して決定的な解決ができる場合と、決定的でない解決の場合の２種類があるわけです。

数学的に言うと、

「発散」、「収束」がありますね。よくやる n を無限大にすると、収束する、という計算です。

nを無限大という条件自体は、時間である t を無限大にする、という計算にも置き換えられます。

さて、この数学的に収束する場合ですが、実は３種類あります。

発散と、収束と、振動ですね。

（「振動」だったかどうか、ちょっと覚えていないのですが、この用語は後で調べるとして）、

発散の場合は、t を無限大にしても、値が特定できないパターンです。

一般的な発散の式も当てはまりますが、複雑系のようなバタフライ効果も、これに当てはまります。

収束の場合は、逆に t を無限大にすると、ひとつの値に定まるパターンです。

これは、t が無限大という点で、無限時間ということになりますが、実際に計算するという事実とは離れて、「計算可能」という範囲で、値が定まる、というパターンも含めます。

これが示しているところは、

1/t の t → 無限大 は、容易に 0 と推測できます（あるいは、証明もできます）。

更に、

円周率 π は、一定の値である（発散しない）という計算も、求められます。

ご存じのとおり、π の値は、3.141592… と延々に続くわけですが、πという仮想的な値に定まる、ということは証明がつくわけです。

# 余談を云えば、10進数では、πの値は、3.14… になりますが、π進数では、1 ですね、という話です。

さて、もうひとつは、振動の例です。

この振動の例は、簡単なものがあって、

sin ( t ) の場合、ｔ を無限大にした時は、どうなるかというと、不定 … いや、1から-1間に特定できます。

これは、発散とは違って、予測可能ではあるが、その時の値は特定できない、というパターンです。

予測可能であるが、その時刻には特定できない、ということは、無限大の時間空間の中で、ある時刻の値は特定できるが、ある時刻自体が非決定（あるいは、揺らぎがある）という場合には、値そのものは決定的ではない、ということを示し、かつ、おおざっぱなところでは比較的決定的であるという、少し不思議なパターンになります。

この例は、卑近なところでは、ニュートン力学と量子力学の関係になります。

例えば、

ボールを投げたときの着地点は、ニュートン力学において、決定的です。

ですが、空気抵抗などの揺らぎを考慮すると、量子力学的に、不定になります。

この狭間は、一見非連続に見えますが、実は連続的なものです。

非連続というのは、ニュートン力学から量子力学の分野の計算になった、という点で非連続的に見えるのですが、物体そのものが変化をしない（ボールという物体そのものは、観察者に関わらず、ひとつである … という仮定ではありますがｗ）、ので、物体という軸においては、連続的という訳です。

勿論、量子力学で学ぶ、「観察者」の存在は重々承知しているわけですが。

そんな訳で、

計算をしても発散してしまう問題。

計算をしていけば収束する（あるいは、数学的に収束が証明できる）

という分野とは別に、

計算していくけど、大ざっぱには求められるが、厳密には求められない、という量子力学風な（というのか、複雑系な）話がでてきます。

ああ、粘菌コンピュータの話になかなかつながりませんが、もう少しで辿り着く予定です。

粘菌コンピュータで、少し思考実験。

粘菌コンピュータとは言っても、別に未来な話ではなくて、現実にある話で、

粘菌コンピュータ – Wikipedia
http://ja.wikipedia.org/wiki/%E7%B2%98%E8%8F%8C%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%BC%E3%82%BF

なところで、真面目に研究しています。

生物学の有機的な話と、コンピュータの無機的な話をつながるのは、結構昔からあって、初出であれば「ライフゲーム」です。

ライフゲーム – Wikipedia
http://ja.wikipedia.org/wiki/%E3%83%A9%E3%82%A4%E3%83%95%E3%82%B2%E3%83%BC%E3%83%A0

ライフゲームと、粘菌コンピュータの似ているところは、

• ルールが単純なところ（あるいは、単純なルールがあるところ）
• それぞれの個体が独立して動くところ

にあります。

正確に言えば、ライフゲームは場自体にルールがあって、それ上を点が動くので、点の集まりが生物である（多細胞、あるいは、多分子という意味で）、粘菌とは若干違うのですが、ライフゲームの子孫が、「エージェントシステム」に、伝わっているので、結構関連がある話です。

マルチエージェントシステム – Wikipedia
http://ja.wikipedia.org/wiki/%E3%83%9E%E3%83%AB%E3%83%81%E3%82%A8%E3%83%BC%E3%82%B8%E3%82%A7%E3%83%B3%E3%83%88%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0

このエージェントシステム（マルチエージェントシステム）は、個体にルールを持たせてシミュレーションをしようという考え方で、場全体をモデルに当てはめて多項式なんかで解く方法（パズルの解法や、巡回セールスマン問題なんてのがそう）とは違って、予想できない結果が得られる（あるいは得てしまう）という点で、普通のコンピューティングとは違っています。

このあたりを、ちょっと図にすると、通常のコンピュータ（アルゴリズム）による解法はこんな感じ。

とある、場があって、その中にある個々の相互作用を一度に計算します。

解法上、時間軸に依存しないことが多いので、その時点の解答が得られます。

… って、何のことを言っているか分かりませんね（汗

例えば、２＋３の答えば、常に５ですよね。

これは、１年後でも１００万年後でも同じ。

これが、時間軸に依存しない解答という訳です。絶対的に決まるって奴ですね。

と、

逆に、時間軸に依存する解答というものがあります。

こんな風に、とある注目する物体との相互作用のみを観察します。

場は、注目する個体との相互作用の集合、という概念ですね。

これが先に話した「エージェント」という話です。

さきほどは、場自体が決まっていたわけですが、今回は、場は個体に依存します。

だから、場を無限に広げれば、個体は同じ動作をするって訳（ライフゲームとか）なんですが、まあ、それはさておき。

これが、どうして時間軸に依存するの？というのは、

とある個体（Ａ）と、相互作用のある（Ｂ）という個体の関係は、

• ＡからＢへの作用
• ＢからＡへの作用

という計算による算出できるわけですが、エージェントによるコンピューティングの場合は、この作用の順序は、交換不可能なんですよ。

ええと、数式で表せば、

Ａ・Ｂ　≠　Ｂ・Ａ

ですね。

作用する順序が異なると、結果が異なる。

数学をちょっとやった方ならば「行列」の掛け算を思い出すといいです。

これ、先の「２＋３」のような話で言えば、

Ａ・Ｂ　＝　Ｂ・Ａ

な訳です。交換可能な式。

この違いがなんなのですか？

という話は、つまりは、ＡにＢを掛けるか、ＢにＡを掛けるかという、「順序」の違いなんですね。

後なのか、先なのかという問題。

つまりは、「時間」の問題になるわけです。

そういう訳で、場を中心にしたアルゴリズムは、時間に関係なく計算できるわけですが、エージェントを利用した場合は、時間によって解答が違うわけです。相互作用が時間に依存しているためです。

・・・粘菌コンピュータになかなか繋がりませんが、ひとまず休憩。