ブログ運営 on 或る阿呆の記

サイト大改造

Wed, 04 Nov 2026 23:26:03 +0000

2012年10月にLivedoorブログから始まった当サイトは、2016年7月にWordPressに移行しました。そしてそれから10年、おおよそ二回目のサイト大改造となる、Hugoへの移行を実施しました。

きっかけはサイバー攻撃の激化です。WordPressだとメンテナンスがたいへんだなぁと思いました。それだけだと大仰なことをしたなという感じですが、まぁ元々、うちのサイトでWordPressの機能は大して使っていなかったので、やめたいなぁという気持ちもありましたので。ちょうどよかったかなと思います。何よりせっかくのAIがWordPressだと手足を縛られている感じになりますし。

逆に言うと、機能をあまり使っていなかったので比較的すんなり移行できた、とも言えます。まぁ意識はしていて、少しずつプラグイン依存を減らしていたんですよね。カスタムフィールドの利用もやめましたし。その積み重ねがあったから出来た、のはあったな。

サブブログの邪悪なAI記事サイトを先行で試すことができたのも良かったです。なんでも作っておくものだな。ただあのサイトはメディアファイルの扱いがなかったので、それについては新たに改修が必要で、アーキテクチャはまた少し複雑になってしまいましたが…。ま、仕方ないですね。AIの力を借りつつWordPressサイトをHugoに移行見ると無駄な複雑さがわかるかと思います。

まーまだ予約投稿機能作ってないとか、コメント機能がないとか（過去コメントの閲覧はできます）、色々ありますけどね。一応一通りは動いている、はずです。動いてないところは随時改修していく所存です。

今後とも、当サイトをよろしくお願いいたします。

個人でAIやるならHuman in the Loopが最強？

Wed, 04 Nov 2026 00:00:00 +0900

最近ブログの移行を進めています。で、先行して移行したサブブログで色々試しているのですが、以前からやりたかったタグ整理について、ちょっといい感じにできています。

ブログのタグ整理って非常に大変で挫折率99.9% と言われているのですが、僕が勝手に言っているのですが、でも多分そうです。課題は色々あるんですけど、列挙するなら以下でしょうか。

粒度や切り口がブレがち
既にどんなタグがあったか忘れる
似たようなタグを表記揺れでつけて気づかない
そもそもタグをつけることを忘れる
サイトの成長に合わせてタグの統廃合が必要になるが、つらい
とにかくつらい
面白くない

結果非常に中途半端なものになりがち。そんなもん使えないので誰も使わない。使わないのでますますやる気が失せる悪循環。タグは人類には早かった。

なのでAIの協力を頼む。といっても、AIに完全に任せると「違うんだよなぁ」となるんです。やったことあるんですがマジで全然頼りにならない。無秩序にどんどん膨らんでカオスになります。列挙した課題にもあるけど、タグは継続的なメンテナンスが必要なので、やっておしまい！じゃなくて、継続的なタグ管理ワークフローまで考える必要があるんですね。いかにしてAIの力を借りつつエントロピーの増大を抑え込むか。

ということで、タグ管理の機能をつくることになります。具体的には、各記事を読み込ませたうえで、既存のタグから候補を選ばせつつ、他にも良いタグがあるかも、と思ったら候補として出す。で、人間がその選択を見ながら、承認していく。いわゆるHuman in the loopの形です。

機能の画面としてはこんな感じになりました。

人間も参加するのでGUI必須だと思います。めんどくさいですが、ある程度タグが出来上がり始めると、ポチポチと連続して承認できるようになるので、人間の時間は案外そんなに必要ないです。少なくとも1記事書くほうがよほどたいへんです。

そんで終わったら、100以上タグが出来ているので、これの統廃合を進めます。これもAIの力を借ります。

まぁまぁそれなりかなっていう提案をしてくれます。ここはだいぶチューニングの余地があるかな🤔

それが終わったら、出来上がったタグの中から必ず選ぶことという条件付きで、すべての記事に対してAIに最初からタグを振り直させます。これで、無秩序にならないかつそれなりのものが出来る……はずです。

今後は新しい記事ができるたびに同様にAIにタグ選定をさせ、新しいタグが出来たら、他の記事に適用……をどうさせるかはこれも運用次第かなぁ。毎回全記事やるとお金かかるんでね(^_^;)

タグの関連性から候補となる記事は多くなさそうなので人間がやってもいいかもしれないし、あるいは半年に一回くらいなら全記事大掃除、とかしてもいいかもしれません。

まぁそんなわけで、結局自己満足かもしれないのですが、今までやりたかったけど出来なかったタグ管理はできそうな感じです。Human in the loopはAI活用の仕方として非常に良いと思いました。

しかし個人だから出来ますけれど、組織だとどうかな。運用の現場と開発が密接に繋がっていることが条件で、この条件が最も難しく、ノーコードが流行らないのもDXがクソになりがちなのもだいたいこれのせいなので、組織の仕事で現場に適用できるかと言えば、難しいのではないかな、とも思いました。

AIの力を借りつつWordPressサイトをHugoに移行

Sun, 01 Nov 2026 00:00:00 +0900

久しぶりのセルフホストな記事。

このブログはまだWordPressなんですが、サブブログをWordPressからHugoに移行しました。理由は主に昨今のサイバー攻撃の激化のためです。WordPressが悪いというわけではないのですが、アタックサーフェスの大きさやPHPの特性を考えると、正直これからの時代厳しいように思われました。毎日のように「プラグインの更新してないぞ」「このIPアドレスから阿呆みたいなブルートフォースアタックきてるぞ」という通知がくるのも疲れましたし。

なので、昔に戻ってスタティックなコンテンツ配信に徹しよう、というような感じです。

WordPressからHugoへ

今回手始めに移行したのは、AIに記事を書かせている邪悪なサイトです。こんな感じに変わりました。

before

after

なんだかんだで移行まで3日くらいかな。正直AIなかったらしんどすぎて無理ってなったと思います。でも移行を決めたのはAIによるサイバー攻撃の激化のためなので、AIのおかげで言っていいのかどうかは微妙なところです。

ここからまた色々と手を加えつつ運用をして、課題を洗い出しながら、本ブログであるこのサイトの移行の準備を進めます。このサイトは14年続いているだけあって色々な歴史が不思議なHTMLタグとなって残っているため、すんなりとはいかないでしょう。AIにめっちゃ調査させながら進めていくことになるでしょうね。かなり時間がかかると思います。仕方無い。来月中にできるといいな。

全体の構成

さて、構成ですが、元々の構成は極めてシンプルでした。

graph TD
cf(Cloudflare)
wp(WordPressコンテナ)
cf --->|トンネル| wp

これが今回、ちょっと複雑になりました。というのも、私は自作の管理アプリケーションがあり、そこで記事の執筆などもしたいためです。こんな感じのアプリでやってます。

記事執筆と管理系のがずらずらと。ちなみにサイトトップの古のアクセスカウンタもこのアプリケーション上でウィジェットを作っています（アクセス解析自体はOSSのUmamiを使わせていただいております）。ウィジェットのみグローバルに公開して、内部のアプリケーションはLAN内限定です。

執筆機能は重要です。そもそもWordPressを使っていたのも、ぶっちゃけWYSIWYGで編集してその場で公開できなきゃいやだいという運用上の理由が大きかったです。デザインはどうでもよい。なので、Hugoに移行するとしてもエディタを用意できることはマストでした。このへんはAIのおかげでやれるようになったと言っていいでしょう。

ただこういうややこしいことをする以上、Hugo側の管理と衝突するために、アーキテクチャはどうしても考えるところが生じます。今回は以下の構成に行き着きました。

flowchart TD
subgraph Internet["インターネット"]
User["閲覧者ブラウザ"]
end
subgraph Cloudflare["Cloudflare Edge"]
CDN["Cloudflare DNS / CDN"]
CFTunnel["Cloudflare Tunnel Edge"]
end
subgraph Server["自宅・ホストサーバー（完全閉域）"]
subgraph Delivery["配信基盤 (Docker)"]
TunnelApp["cloudflared コンテナ"]
Caddy["Caddy Webサーバー (ポート開放なし)"]
StaticFiles["静的ファイル (HTML / CSS / 画像)"]
end
subgraph Management["執筆・ビルド基盤"]
Dashboard["Web管理画面 (Blog Dashboard)"]
Hugo["Hugo (静的サイト生成)"]
Source["Markdown記事"]
end
end
%% 閲覧フロー
User -->|HTTPS| CDN
CDN --> CFTunnel
CFTunnel -.->|アウトバウンド常時接続| TunnelApp
TunnelApp --> Caddy
Caddy -->|読み取り専用| StaticFiles
%% 執筆フロー
Dashboard -->|記事保存| Source
Dashboard -->|ビルド実行| Hugo
Source -.-> Hugo
Hugo -->|HTML出力| StaticFiles

Hugo環境はコンテナに隔離して、cloudflaredよりトンネル経由で外からアクセスする感じです。Cloudflare依存になってるやんと見えますが、まぁそうなんですが、別に使えなくなったらVPSからfrpなりなんなり使った構成に切り替えればいいだけなので、まぁいいかなと。さらに言えばサイト公開するマシンはそれ専用にする予定です（まだ徹底はできていない）。

そんで、記事の生成とかビルドの実行とかは、全部管理アプリケーション上でやる構成ですね。一言で言えば管理アプリケーションが正本となる構成です。Hugoリポジトリは中継地点ないしバックアップの役割になります。なのでCI/CDによるホスティングではないです。これによる制約はいくつかあります。主に運用上の制約は以下になるでしょうか。

管理アプリケーションとHugoのホスティング環境が同一のマシン上にあること（変えてもいいんだがややこしくなり思想から外れる）
普段は管理アプリケーションからHugoリポジトリのpush/pullを実行するが、Hugo側のデザイン変更時（特に記事データに特殊な記法を挿入する時）はローカルのHugoリポジトリでpushする、2つのワークフローが存在すること
CI/CDでブランチごとにホスティングしてステージング環境作るとかはできない（できないことはないが構成と運用がややこしくなり、設計思想から外れる）

この制約は受け入れることになります。

別の考え方としてリポジトリを正本とする考え方もあり、まぁそちらのほうがアーキテクチャは綺麗になると思うんですが、なんか無駄に複雑な運用になりそうだったのでやめました。どうせ運用者も僕だし。

再び個人サイト激動の時代に…

とまぁこんな感じでやっていて思ったんですが、AIで楽になったと言っていいんですかねぇ…。25年前は専門じゃなくてもやる気があれば頑張ってサイトを持つことができたと思うんですけれど、今はこれちょっとどうなんでしょう…。

トンネル技術とコンテナが揃った時には、個人サイトやセルフホストがまたやりやすい時代になった！と思ったのですけれど、サイバー攻撃がヤバいから守備を固めよう、WordPressはよくない、でも運用が不便になって更新しなくなったら元も子もないから利便性も高めよう、みたいなことを考え始めると、AIによる効率化以上に、トータルの難易度自体は上がり続けているような気がします…。

いやまぁ、僕がややこしくしているだけか。

これはまぁ結局、何をどこまで信じるか、という話です。少し前までだとVPSやクラウド基盤そのものを疑うのはキチガイ扱いだったかもしれないのですが、最近お名前.comデスクトップクラウドが基盤ごとやられて顧客の資産がハッカーの攻撃により消失し、さらにGMOが顧客の端末を回収するため物理的に全国を駆けずり回ったという事件は、クラウドは絶対安全ではないという当たり前の技術的な真実を曝け出しました。ま…それでAWSをはじめメガクラウドが陥落するかと言えば別にそういうわけではないですけれど、でもメガクラウドだから安全だ、は技術ではなく信仰でしょう。

結局個人サイトって自分の城です。城をどこにたてますか、どうなったらその城はぶち壊れますか、あなたはそれに納得できますかと、そういう話なんだと思います。絶対防御は無理なので、そのうえで何を賭けるのか。それを考え始めると、やりたいことに対して、本気でぶち壊そうとする勢力、さらにその被害が大きくなりすぎて、それが多分根本的な問題なのだと思います。

僕の構成がややこしくなっているのは、それだけ僕が納得するのに必要になってしまったということはあります。別にもっとシンプルな構成は可能です。元々のようにCloudflareトンネルでWordPressコンテナ直通でも良いといえばそうなので。ちゃんと更新し続けて、今回のPHP事件みたいなのがあったらキャッチアップして…ってやっても、基本は大丈夫でしょう。心配なら物理的にサイト専用のマシン作って切り離すくらいで、ほぼほぼ問題ないと言って思います（まぁそれも普通からするとややこしいわけですが…）。

まぁ結局どうしたいかは人それぞれということになるんですが、その構成に至る道筋や、またその構成における必要な運用はなにか、普通の人がそれを理解して辿り着くのが難しくなっているのかなぁと、そんな風に思いました。

<関連記事>

あわせて読みたい

AIによるサイバー攻撃時代の個人サイト・個人ブログのセキュリティ

/ai-cyber-attack/

あわせて読みたい

AIでソフトウェアの作成は楽になったが、結局最後は泥臭い

/aisoftware/

ブログを14年続けてわかったこと：あらゆるリンクは消える

Fri, 09 Oct 2026 00:00:00 +0900

まぁもう表題で終わってるんですけど、今月で当サイトは14周年を迎えるのですが、振り返ってわかったことは、あらゆるリンクは消えるということです。もう本当に全部消えます。行きつけのサイトはもちろん、当時絶対に潰れないと思われた大手サービスも消えます。全部消えます。今あるリンクは全部全部全部消えます。

消える消えるよサイトは消える

このサイトも、多くのリンクを貼ってきましたが、消えているサイトが多いことにふと気づいて驚きます。たとえば本サイトの最初の記事は、Ubuntu Serverを構築するぞ！という2012年…そう、まだ私が二十代半ばだった頃の記事…なのですが、これは実のところ当時あったUbuntu Magazineを自分なりになぞった（そして無駄にアレンジして爆死した）ものです。

あわせて読みたい

小型のメディアサーバー兼NASをたてるその2 〜RAID編〜

/19182815-2/

本サイト最古の記事です。当時、雑誌以上のことは書いてないよなぁ…(^_^;)という引け目があったことをなんとなく覚えています。実際には、記事を読むと情報というよりも試行錯誤のほうがコンテンツになっているので、結果的には今も好事家なら生暖かく面白く読める記事に思います。自分で言うのもなんですが。ただ純粋に機能として見たとき情報量と言いづらく、それがコンテンツであるとは当時の自分にとって確信が持てなかったのでしょう。

単に情報としては、Ubuntu Magazineで完成されていました。なので、ネットでも公開されているそれを読めばいいじゃないか…という気持ちはありつつ記事を公開したような思い出です。記事からもリンクが貼られています。それは金のない若者だった僕にとって、とても有り難いものでした。

しかし、その後Ubuntu Magazineは消えました。

https://ubuntu.asciimw.jp

なんで消えたのかは知りません。KADOKAWA CORPORATIONにとっていくつかのPDFを置くだけのサーバ代がたいへんだとは到底思えませんし。となると大人の事情があったのか、どうなのか。

わかりませんが、とにかく消えました。そして私のサイトだけが残った。

まぁこんな感じで、上記の記事は連載記事としていくつか書くのですが（続けて連載記事を書く体力はもはやありません）、参考とした個人サイトやらなんやらも、今見ると大部分消えていたりするんですよね。当時「これは結局ただ他所様の情報を集めただけなのではないか…？」という気持ちもあったのですが、結果的にそれら大元が消えたことで、私のサイトの中にある記述だけが残った形です。

個人サイトの場合は大人の事情というより、単に個人的な事情でしょうね。個人サイト、もうほんと報われないですから。世間の流れも、ライフステージも変わりますしね。ちなみにこのサイトも、実はいくつかの記事が非公開になっています。その中には非公開にする直前までそこそこアクセスのあった記事もあります。個人的な事情です。しゃーないのです。時代も私も変わっているので。

私がリンクで終わらせずにスクショを貼ったりするのは、こういう原体験のために、あらゆるネット上の情報について、きっと消えるんだろうなぁという気持ちがあるからだったりします。インターネットは一期一会。その傾向は昔よりも強まっています。お気に入りのサイトも、胴元もろとも消えることがあります。ジオシティーズは何処に消えた…。

あの日見たゲーム画面が本当にそうだったのか僕たちは全部忘れた

この消える現象はWebサイトにとどまりません。むしろマシなほうかも。消える媒体の最たるものは、オンラインゲームやソーシャルゲームをはじめとするネット主体のゲームじゃないですかね。40年前のファミコンは今でもプレイできる方法があるのに、5年前に流行っていたあのソーシャルゲームはもうプレイできません。もはやあったのかどうかも疑わしい気分だ。

僕の青春はSFCことスーパーファミコンであり、FFことファイナルファンタジーの4から6くらいでしたが、まぁ前後の1-3、7-10,12くらいまではやりましたが、あの時代で良かったと時々思います。今でも媒体は残っており、オリジナルをプレイすることは可能です。そして当時の記憶は皆が共通であり、確かなものです。媒体は修正されません。

しかしもし今のオンラインゲームであったならば…日々のアップデートは僕の思い出を塗り替えた可能性があります。それならまだマシで、アクセスすらできない状態になったとき、いったいそれは本当に存在したのかも、疑わしいものになる。ストアにあるタイトル画面の残骸だけが、かつて存在した証になるのだろうか。そのストアすらも、いつかは消えるのだろう。

このように考えたとき、恐らく2000年代後半くらいから現在、そしてもうしばらく後まで、後世においてデジタル暗黒時代として記録されるのではないかな、と思います。あらゆることがネットに集約されはじめたにも関わらず、あらゆることがネットから消えている。結果、いったい当時何があったのか、誰にもわからない。かろうじて当時の人の話にこぎつけても、人によって言うことがバラバラ。そりゃそうですね、なにしろバージョンが違いますから。

そして誰もいなくなった

僕は現状を危惧する考えです。今起きていることを有り体に言えば、文化の死、あるいは断絶と言えるかもしれません。この原因について考えたときに、いくつかのキーワードが浮かんできます。列挙するなら、とりあえず以下の3つがあります。

資本主義
中央集権、あるいはプラットフォーム
クラウド

資本主義というのは、たとえば資本の論理においては文化の死も肯定されるということです。代表的なのがどこぞのネズミのために著作権がどんどんと長引いていくあの現象です。あれは多くの古典を人々から遠ざけています。身近においても、終わったソーシャルゲームを蘇らせるような行為は、これは大罪とされます。企業はいつか使うかもしれないIPの独占を手放したくはありません。

根本的に、資本の論理と文化とは水と油です。金で愛は買えないといえば誰もが頷くと思いますが、まぁもしかしたら頷かない人はいるかもしれないですがそういう可哀想な人は置いといて、文化とは金より愛に近いものですから、資本の論理を優先すれば、どうしても文化の在り方は難しくなります。

ですが資本主義だけならば、あまり大きな問題にならなかったかもしれないと思います。が、デジタルにおける中央集権化およびクラウド化と資本主義のシナジーによって、話は深刻になっていきます。

寄らば大樹の陰といいますか、多くの人が少数のプラットフォームに集まった結果、そのいっときの利便性と引き換えに、一つのプラットフォームの決定によりあまりにも多くの巻き添えが発生するようになりました。そしてこの決定に資本主義が強く絡みます。資本の論理において生存の理由がないものは、生きられない、少なくとも生きづらいのです。

プラットフォームは資本の論理に根づきます。そしてクラウドはすべてをプラットフォームの側に寄せます。資本の論理は、それに反するものを、たとえ文化的価値があっても容赦なく滅します。

そして誰もいなくなった。

まぁ実際にはまだ、ビッグテックを代表とするいくつかのプラットフォームが残っており、皆そこに集まっているわけですけれども、栄枯盛衰、諸行無常を思えば、何がどうなってもおかしくありませんね。Xなんかも例外じゃありませんよ。ってかあれこそ、いつ消えても（あるいは閲覧できなくなっても）おかしくないんだわ。

あなたはデータを信じますか？

まぁそんなわけで、せめてもの抵抗というか、僕は細々とこうして場末で独り世情のあれやこれやを書き散らしている、というのは大げさで単に書くのが好きだから書いているのですが、しかしこういう個人が必要なんじゃないのか、という気持ちもあったりなんだりするんです。最後に残るのは結局、こういう資本の論理と完全に切り離された、存在理由が不合理な私文なんじゃないでしょうか。

こういう気持ちもあって、今は個人でHTMLを含む様々なデジタル媒体を含むメディアを、アーカイブ・閲覧・編集・管理できるセルフホストのアプリケーションをシコシコつくっていたりします。このサイトでたまにD-Shelf（仮）と言っているのがそれです。しかし自分で使う分にはまだしも（基本的にはわたしの普段遣いのために作っているものです）、人様に見せられる状態には、AIの力を借りても中々難しいもので、公開はだいぶ先になりそうですが。

ま、難しいことを言わずとも、とりあえずは個々人がこうやってその時々を記録・保存していくだけでも十分じゃないでしょうか。それも立派なアーカイブです。

そんなことしたところで、所詮個人のアーカイブに信用などないじゃないか、と思われるかもしれません。しかし、信用ってなんでしょうか。政府機関のことでしょうか。大学のことでしょうか。どっかのなんかエラいって言われている人のお墨付きでしょうか。あるいはブロックチェーンのことなんでしょうか。それともまさかまさか、バズツイのことなんでしょうか。

全部、違うと思います。それらは単に権威ないし技術、あるいはトレンドなのであって、それ以上でもそれ以下でもありません。

では信用とはなにか。信用とはとどのつまり、自分の心の内側から湧き上がる内発的なものであると私は思います。これは極めて主観的です。しかし本質がそうであると思います。虚心坦懐になって、信じるに足ると思われたのならば、それが信用です。それはとてもしんどいことです。だってこの考えだと、信用とはつまり、自分の責任にもとづくものだということだからです。

だからみんな、客観に逃げました。主観のしんどさに耐えきれなくて、客観に逃げました。信用の根本をすっ飛ばして外形で判断できる体裁に頼ったところに、現代の歪みがあります。結果、世間的に信用とされるものを、私たちは本当のところ、何にも信じていないのではないでしょうか。そりゃそうという話で、別に客観は客観で便利なので、適当に使えばいいんですけれど、事実は単に事実なのであって、信じるものではないでしょう。

こういう考えなので、私は外形的な証明を作る気はまったくありません。信用とは生身の人と人が繋ぐトラストチェーンであると考えます。信用してくれなんていいません。信用するのもしないのも人の勝手だと思います。

ただこの信用というのは、客観的な判断と異なりけっこう気合いのいるものです。気合いというのは、これは有限です。それは精神であり、時間です。その有限なリソースを、我々死に向かっている生物がコミットするのであれば、そこにはそれなりの信用があるでしょう。そういう個々の信用の連なりは、社会的にも信用といっていいものなんではないでしょうか。その信用の軌跡が文化なのだと、私は思います。

<関連記事>

みんなが個人ブログ・サイトをつくる世界線はあるか

/jitakuserverselfhost/

AIでブログのスクショ定点観測機能をつくった

Sun, 20 Sep 2026 00:00:00 +0900

AIで制作しているブログ管理補助ツールに、定点観測機能を入れました。こんなのです。

ちなみにこの動画自体は、管理アプリを開いた状態でMacのスクリーンレコードで撮影したのを、ffmpegで変換して作りました。

ffmpeg -i input.mov -vf "fps=10,scale=800:-2" -c:v libx264 -crf 26 -preset slow -an output.mp4

こういうツール周り、本当に便利になりましたよね。PCのスペックも高くなりました。

ブログ始める14年前（遠い目）に欲しい機能でした。本ブログはもうすぐ開設から14年なのですが、14年分のトップページタイムラプスがあれば、しがない個人ブログとはいえ、圧巻だったでしょうねぇ。無料のLivedoorブログから始めて、独自ドメインを取得し、WordPressに移行し、いろいろなテーマを試し…など、まぁ個人としてできることはやってきていますから。記事の内容もの、その時々で変わっていますしね。

アクセスカウントも最初から置いていればなぁ。本当に、昨日できたことを明日もやるという継続こそ、本当に必要なもので、時間という平等な資源を結実させ、個人が大手と戦えるはずのかけがえのない武器でしたが、なんだか無自覚に刀狩りされて、しかもそれをモダンだと思い込まされてきましたね(^_^;)

ま、いまはAIという武器が手に入ったことで、再び個人の力が拡張されました。またこの20年のなんだかなぁというインターネットの歴史を経て、大いなるビッグテックへの愛想も付きました。

そんな流れのもと、いまさらながら定点観測をしていきます。年末くらいにタイムラプスをざっと流そうかな。

みんなが個人ブログ・サイトをつくる世界線はあるか

Tue, 08 Sep 2026 00:00:00 +0900

初心者、とはなんの初心者だろうと思いつつ、誰でも個人ブログ・個人サイトを持つ、あるいはそれに類する状況になる未来はないかと、ずっと考えています。一時期はそれは無理だと諦めたのですが、技術的には、2010年代、非常に難易度が高くなった時期から少しマシになっており、インターネット黎明期に個人サイトをつくっていたガッツがあれば出来るのではないかな、と思われます。

巨大プラットフォームからの逃げ場

とはいえ簡単ではないのですけれど、それでもやりたい人は実はいるだろう、と思います。だってXもFacebookもnoteもpixivも窮屈だし、しかも煩いでしょう。ブルスカだのMastodonだのなんだのありますが、まぁちょっとやってみると、結局全部SNSやないかい、と思うわけです。まぁSNSなんでそりゃそうなんですけど。

SNSであるからというより、恐らく本質的な問題は巨大プラットフォームが寡占していることに端を発している、と思います。巨大過ぎて影響力が無視できないので睨まれるけれど、巨大過ぎてまともな管理なんかできません。つまり、自重で沈んでいるんですよ、もう。

そうすると、選ばれなかった世界線ではあるのですが、今一度一人ひとりの自由な場ができないものかなぁ、と考えております。いま２つのシナリオを考えていて、数人から数百人、多くて数千人程度の小規模プラットフォームをたくさんつくる方向と、もう一つは、かつてのように個人サイトよもう一度、というシナリオです。

個人サイトリバイバルの現実性

どちらかというと小規模プラットフォームが僕の本命なのですが、ここではいったん置いといて、まずは個人サイトリバイバルはありえるのか、ということを考えます。

技術的には、先に述べたとおりよい環境になりました。

具体的には、安価なVPS・または自宅回線とグローバルをつなぐトンネル技術、多くのFOSSや配布されたサーバ用アプリケーション、そして知識の架け橋を繋いでくれるAI、の3つが大きいです。これらによって、個人の頑張りで、非ITエンジニアでも個人ブログ・サイトは再び射程内に入ったもの、と見ています。技術的にはね。DNS周りは引き続き鬼門ではあるのですが、これは昔からですし、まぁ複雑性はあがってますけれど、AIという頼れる道具ができたので、やる気さえあれば、多分いまのほうが楽だと思います。

ただ問題は別のところにあるでしょう。まず不自由とはいえ巨大プラットフォームが既にある程度の機能を無料で提供しているのはモチベを大きく削ぎます。まぁ個人的には見せかけの無料だと思いますが…無料のランチはない、とはいまさら言う事でもないんですけどね。昔は自分で発信しようと思えば、頑張るしかありませんでしたが…頑張らなくてもいい手段があるとなるとどうしても踏ん張りきれない。これは馬鹿にできません。

それ以上に問題なのは、集客でしょうか。これが非常に悩ましいのですが、既にGoogleをはじめ検索エンジンは個人ブログ・サイトを現実的に見限っています。いまから新しいサイト、検索エンジンからの流入を見込むのはかなりしんどいです。うちのブログだって、10年以上やっていますが、いまは良かった時の2割くらいですしねぇ…。それでも多分、マシなほうなんですよ。

かといって、もはやジャンル別サーチエンジンも、また別サイトからのリンクも、ほとんど見込めません。全部Googleが焼き払いました。焼き払った後に撤退しました。田舎のイオンかよ。そして誰もいなくなった。

まぁ僕らユーザも便利だと検索エンジンに飛びついてしまったので、共犯といえばそうかもしれないんですが…。Googleは違うという気持ちが20年前にはありましたが、まったく同じでしたねぇ…。

活路はあるか

集客問題に解決はいったいあるんだろうか、というと、今のところは正直ないです。現在は、見捨てられたとはいえ少しは検索にも引っかかるので、それに期待するしかありません。また、うちのサイトは少し（？）前からnoteに転載を始めましたが、noteの記事内にブログ記事のリンクを関連として貼ると、興味を持ってくれた方の流入はちょこちょことあります。現状それくらいしかないかなぁ。

ちょっと触れた小規模プラットフォームの話とも絡むんですが、個人的にはやる気のある人が再び独自の観点でサーチエンジンやリンク集をなるべく負荷を減らして作れるようなものができないか、とは思っています。

これはMastodonのようなものとはまったく違うものです。あれは分散型だといいますが、技術的にそのように呼ばれるものであるとして、社会的な概念としての分散とは違うように思われるんですよねぇ…。僕にはあれはプロトコルを中心にした一つの巨大システムに見えるんですよね。

そうではなくて、独立した個々の島と、それを勝手に繋いだり外したりするような、自由気ままなかつてあったインターネット的な世界線を考えているわけです。多分似たようなこと考えて動いている人はけっこういるような気もするんですが…。

まぁちょっとまだまだなので、とりあえずいまは、個人ブログ・サイトをつくるための技術的な案内をつくるところから始めますかねぇ…。

【脱Google？】Google抜きで古のアクセスカウンタを設置できる、そうAIならね

Fri, 28 Aug 2026 00:00:00 +0900

アクセス解析といえばみんな大好き過ぎて涙目で泡吹いているGA4ことGoogle Analyticsなんですが、当サイトはマイブームだった脱Googleの流れで利用をやめました。まぁこれに関しては脱Googleというより、純粋に使いづらかったからやめた面もあります。GA4は個人サイトのアクセス解析としてはあまりにも重すぎて意味不明、最初からGA4だったら誰も使わなかったんじゃないのこれ、と思います。

Umamiの導入

それから当サイトではWordPressのプラグインのお世話になっていたんですけれど、最近、セルフホストできるUmamiを導入しました。

あわせて読みたい

セルフホストしたUmamiでWordPressサイトのアクセス解析

/umami-wordpress/

これでWordPressプラグインに頼らず、またWordPress以外のあらゆるサイトについて一括してアクセス解析ができるようになりました。有り難いことです。

UmamiはAPIを利用できるので、サイト内の記事のアクセスランキングなどもつくれます。ま、WordPressで実現しようと思ったらカスタムフィールドとかいじる必要あると思いますが…当サイトはもともと別に独自実装で入れていたものがあるので、それを流用することでランキング生成のバックエンドもサクッとUmamiベースに置換できました。

アクセスカウンタをもう一度

作業中、もしかして古のアクセスカウンタを設置できるのかなぁ、とふと思いました。アクセスカウンタって古代文明の名残みたいな感じかもしれませんが、というか若い人はもしかすると存在を知らないかもしれませんが、昔の個人サイトはたいていあったものです。

アクセスカウンタが消えたのは、需要が消えたから、ではないと思います。実際、PVランキング自体はけっこう色々なサイトで今でもありますよね。というかWordPressでもアクセス解析プラグインはたくさんあります。

だったらアクセスカウンタもあっていいじゃない、と思うわけですが、アクセス解析で覇権を取ったGoogle AnalyticsのAPIを追従しながら頑張って設置するにはちょっと情熱が必要になります。API権限の管理問題で、どうしても煩雑になりますよね。まぁ少なくとも、私は今までやる気にはならなかったですねぇ。

AIが一晩でやってくれました

しかし今は、今までとは違う。セルフホストの環境が完全に整っており、さらにAIがある。このセットによって、今までならば「できるだろうけどめんどくさいなー」ということで半年の放置不可避だったものが、爆速でそれらしいものが出来上がる。

ということで、GeminiにUmamiのAPIをつかったアクセスカウンタのジェネレータを作ってもらいました。

若干の調整は発生しましたが、ジェバンニも真っ青の凄まじいスピードでつくってくれました。これは嬉しい。HTMLの埋め込みタグ一つでアクセスカウンタが設置できます。

そして当サイトに古のアクセスカウンタがのっかりました。

ふふふ。00年代感。

これは既に作っていたサイト管理用Webアプリを土台にして作ったのですが、機能的には独立しているので、切り離せば誰でも使える形になります。なので気が向いたら分離しようかな…と思ったりもしますが、これの場合、通常一番の障壁はどっちかっていうとUmamiをセルフホストすることでしょうね(^_^;)

まぁUmamiも結構な頻度で更新しているようなのですが、バージョン固定できますし、Googleの気分に振り回されず、自分のやりたい解析ができて、解析結果もAI使えば存分に利用可能、というのは、これはかなり魅力的ではないでしょうか。

AI使ってなんだかんだと喧しい世の中ですが、そんな派手なことしなくても、確かに自分にとって役立つものができるので、そういうことを人にも勧めていきたいですねぇ。

<関連記事>

セルフホストしたUmamiでWordPressサイトのアクセス解析

Fri, 21 Aug 2026 00:00:00 +0900

Google Analytics代替として候補にあがる、セルフホストのアクセス解析ソフトUmamiを使っていく。

GitHub - umami-software/umami: Umami is a privacy-first analytics platform. Traffic, campaigns, behavior, conversions, and revenue in one place — no cookies, no tracking, self-hosted or in the cloud. · GitHub

なお公式サイトはisドメインなんだけれど、なぜか弾かれる。Cloudflare経由で接続するといけるのでおまかんっぽいんだがアイスランドに嫌われるようなことしたっけ？

まぁそれはいいとして、今回インストールでは「How to Install Umami Analytics on Docker (2026 Guide)」の記事を参考にさせていただきました、っていうか正直うちの記事よりこの記事のほうが詳しいからこっち見たほうがいいよｗ

じゃあなんで書くのかというと、記事は消えるから……。10年以上もブログやっていると「この記事が詳しいです！」で雑に案内だけ貼ったリンクが消える消える。まぁ微妙に情報補足と雑なWordPress案内も追加したので…。

環境

Umami@3.2.0
自宅サーバ
- ThinkPad L390, Core i5-8265U, 32GB RAM
Linux Mint Xfce 22.3
- docker 29.7.2
Cloudflare Tunnel

インストールと最初の設定

`docker-compose.yml`

以下でランダムな文字列を作る

openssl rand -hex 32

文字列はコピーしておく。

.envを作成する。以下のAPP_SECRETにさっきのランダム文字列を入れる。パスワードは適当に入れる。

POSTGRES_USER=umami
POSTGRES_PASSWORD=your-secure-password
POSTGRES_DB=umami
APP_SECRET=run-openssl-rand-hex-32-to-generate
DISABLE_TELEMETRY=1

docker-compose.ymlを編集。元記事からimageのURLだけ差し替えた（エラー出たので）。ポート番号は変えたかったら変える。バージョン固定したかったらする。ちなみにvつかないらしい（v3.2.0ではなく3.2.0）。

services:
 umami:
 image: umamisoftware/umami:postgresql-latest
 ports:
 - "3000:3000"
 environment:
 DATABASE_URL: postgresql://${POSTGRES_USER}:${POSTGRES_PASSWORD}@umami-db:5432/${POSTGRES_DB}
 APP_SECRET: ${APP_SECRET}
 DISABLE_TELEMETRY: ${DISABLE_TELEMETRY:-1}
 depends_on:
 umami-db:
 condition: service_healthy
 init: true
 restart: always
 healthcheck:
 test: ["CMD-SHELL", "curl http://localhost:3000/api/heartbeat"]
 interval: 5s
 timeout: 5s
 retries: 5

 umami-db:
 image: postgres:15-alpine
 environment:
 POSTGRES_DB: ${POSTGRES_DB}
 POSTGRES_USER: ${POSTGRES_USER}
 POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
 TZ: UTC
 volumes:
 - ./umami-db-data:/var/lib/postgresql/data
 restart: always
 healthcheck:
 test: ["CMD-SHELL", "pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}"]
 interval: 5s
 timeout: 5s
 retries: 5

ここで、参考記事によると、Cloudflare Tunnelを使っている場合、Umamiから見ると全部CloudflareのIPを取ってしまうので、docker-compose.ymlのenvironmentに以下を追記せよとのことであった。

CLIENT_IP_HEADER: cf-connecting-ip

VPSとかで直接公開してCaddyをリバースプロキシにしている場合はヘッダの付与よしなにしているから不要なはず。

準備が出来たら、docker compose upでエラーが出ないことを確認する。いけたらdocker compose up -dでバックグラウンド起動。

最初の設定

http://<IPアドレス>:<ポート>にアクセスして、ユーザ名adminとパスワードumamiでログイン。

当然危ないので、管理者設定からパスワードを変更する。ユーザ名も変更できる。

言語設定も日本語あり。

ネットワーク設定

トラッキングデータの送信はクライアントマシンから行うため、グローバルに公開する必要あり。

全体の流れは以下 by AI。

sequenceDiagram
autonumber
actor Client as クライアント
participant WP as WPサーバー(ブログサイト)
participant Umami as Umamiサーバー(セルフホスト)
Note over Client, Umami: 1. ブログページの読み込み
Client->>WP: ① ページリクエスト (アクセス)
WP-->>Client: ② HTML返却 (Umamiのscriptタグを含む)
Note over Client, Umami: 2. アクセス解析データの送信 (クライアント直接)
Client->>Umami: ③ script.jsの読み込みリクエスト
Umami-->>Client: ④ script.jsの返却
Client->>Umami: ⑤ 閲覧データ(PV等)を直接送信 [要グローバル公開]

うちの場合は例によってCloudflare Tunnelで開通している。

ここでサブドメインだが、参考記事によるとanalyticsとか使うと広告ブロッカーに遮断される率が上がるらしい。参考記事ではstatsやmetricsやtrackなどにせよと言われている。

WordPressサイトの解析

別にWordPressサイトじゃなくてもやることは同じ。

トラッキングコードの取得

サイドバーの「Webサイト」より、管理したいドメインを追加する。

追加したら、Editを開くと以下のようなトラッキングコードが取得できる。

<script 
 defer 
 src="https://your-umami-domain.com/script.js" 
 data-website-id="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx">
</script>

基本はこれを<head>タグに貼り付けること。

タグの貼り付け

プラグイン「Integrate Umami」があるが、<head>タグに貼り付けるだけなのでプラグイン使う必要はないかなと思う。

うちはテーマとしてSwellを使っているので、「外観」「カスタマイズ」「高度な設定」から「headタグ終了直前に出力するコード」にコードを貼り付け。

自分だけ除外とかするなら functions.phpでログインユーザにはトラッキングコードを出さないとかしないといけないかなと思う。

実測で確認

しばらくダッシュボードを見てきちんと動いているか確認する。

まぁなんか動いてそう。使い方についてはおいおい見ていこうと思う。

以上。ちなみに最初AIに聞いて作業していたんだが、古いバージョンの情報に惑わされて完全に無能だった。

ブログのアイキャッチ画像はAIで作れる。どうでもいいから

Tue, 12 May 2026 00:00:00 +0900

ブログにはアイキャッチ画像というものがある。記事を開くととトップにあったり、記事一覧のサムネイルになっていたりするあれだ。

ブログはアイキャッチ画像ありき

うちにサイトにもある。本ブログの記事には表示していないが、記事一覧では見られる。また、noteに転載する記事では、設定している。

トップページ

うちのサムネイルはご覧のとおりだが、基本的にはタイトルや本文の内容に即した短い文字列を、そのまま画像にしただけのものだ。なんか色々やってこれに落ち着いた。

アイキャッチ画像というのは本質的に馬鹿らしく、あってもなくてもどうでもいいものだと思うので、あまり労力をかける気になれない。だったら作らなければいいのにと思うだろうが、現在のブログではアイキャッチ画像を設定することが半ば強制されている。先のとおりnoteでも設定は実質必須であるし、本サイトを構築するWordPressの有名なテーマ「SWELL」においても、基本的に設定されていることが前提の設計だ。

まぁもちろんないからといって記事を投稿できないというわけではないのだけれど、アイキャッチありきのデザインにアイキャッチなしで投稿すると、シャッター街のような居心地の悪い見栄えになる。僕はWebサイトなんてpタグとaタグだけでいいんだという粗忽者だけれど、その僕をしてみすぼらしい印象を抱かせる。これは許容できない。

ブルシット・ジョブ

ということで、渋々ながらアイキャッチ画像を制作していた。まぁどうせやるなら真面目にやったほうがよかろうかと重い、Affinityシリーズまで購入した（Affinityは3で無料化されているが2はそこそこした）。しかしどうあっても本質的な価値を生まない無駄にしか思えず、最終的には「いかにラクしてそれらしくするか」に腐心することになった。

そういうわけだから、ChatGPTの画像生成機能ができたときは喜んで利用したのだけれど、今振り返ると当時の画像生成で出来上がるものはかなり不出来だった。けばけばしい色合いでこれでもかと空間を埋め尽くすようなものが多く、気持ち悪いものが多かった。しかもどこまでもイメージ画像で、何がなんだかわからん。

しばらくするとその不格好さに気づき、自分のサイトにこんな気持ち悪い絵は置けないなぁとなった。で、結局、背景画像のみ落ち着いたものをAIに作らせて、それを使いまわしながら文字入れだけ自分でやる、というスタイルになった。以下のような感じだ。

一応それなりの手間はかけているだけあり、正直今の完全AI生成のものより見栄えがするかもしれない。

しかしやり始めると文字間の調整（カーニングというらしい）など地味に面倒くさくて、サムネイルを作るのが面倒で記事をあげなくなるなどという本末転倒なこともあった。めんどい。

また、その頃、今まで自分がやってきたことと向き合う中で、かなり旧来のWebに対して遠慮なく批判的に考えるようになっていたこともあり、「そもそもサムネイルなんているかよ！！」という嘆きが明確になっていた。こんなものはブルシット・ジョブだ。明確にそう思った。時間をかけてはいけない。

自動化の試み

僕は本格的にAIのみで生成することを試みはじめた。

重要なことは、ボタン一つでサムネイルを生成し、さらにそれをWordPressの記事として設定できることだ。ここで壁となるのは、「許せるサムネイルであること」「記事に設定するところまでやること」の2つだ。

「許せるサムネイル」というのは、案外難しい。実際に記事のサムネイル画像をAIに作らせたことがある人ならわかると思うが、生成一発で自分が納得できる画像は稀である。だいたいいくつか候補を作って、ああでもないこうでもないと注文をつけないといけない。

なぜそうなるかと言えば、AIが変に作り込もうとするからだ。なので、AIが記事内容からそれっぽく想起した画像はしばしば「それは俺の意図ではない」と思うし、また細部をよく見ると破綻している。最近はかなりそれらしいものができるようになってきたようだけれども、少なくとも2025年くらいまでは一発ぽんで使い物になるという感じではなかった。そもそも画像の生成は使用するトークン量が多いため、AI料金の高騰化を考えると持続性に疑問符もつく。矛盾しているようだが、AIサービスに依存するのは嫌だった。

それで、制約をかけることにした。そもそも画像を作ろうとするからよくないのだ。文字だけにすればよい。そしてその文字のデザインは、テンプレートHTMLを与えてある程度統一すればよい。出力もHTMLにすればよい。そしてHTMLをヘッドレスブラウザで開き、スクリーンショットを撮影することで画像とすればよいのだ。ブラウザで表示するものをそのまま使うため、微妙な文字の調整もされていると期待できる。また、これならばトークンの量も少なく、ローカルLLMでも対応できる可能性がある。

この試みはやってみるといくつか引っかかるところがあったが、最終的にはそれなりに安定して動くようになった。これを最終的にwebpでWordPressの記事に登録するインタフェース部分を作り込んで、完了。最初はCLIで動かしていたが、その後GUI化するなど、地味な改良もAIプログラミングによって比較的容易にできた。

ローカルLLMによる出力は正直まだ若干安定しないところがあるのだけれど、ここはテンプレートHTMLとプロンプトを泥臭く調整すればなんとかなるような気もしたし、またOSSモデルの発展で解決するかもしれないので、本当に必要になってから作り込むでもいいかなと思った。今はとりあえず、月20ドルのサブスクを契約しているので、それを使えばいい。

やらなくていいことの最大効率を達成

そんなわけで、今は特に大きなストレスになることもなく、アイキャッチ画像を作れるようになった。しかし、これを「AIによる効率化を達成した」と言っていいのかはわからない。前述のようにそもそもアイキャッチ画像は不要だ。しかし、現代のプラットフォームがそれを求めるので、仕方なく作っているに過ぎない。本質的に価値を生まないブルシット・ジョブだ。少なくともうちのブログではそうだ。

本来やらなくてよいことを実質的に強制され、それをAIで自動化したからといって、それを効率化と呼んでいいのかはわからないと思った。

そもそもAIで自動化できたのは、それがどうでもいいことだからだ。僕は記事内容についてはAIを利用しない。僕にとって記事とはどうでもよくないものだからだ。AIに自動化できることのすべてがどうでもいいとは言わないが、しかしどうでもいいことの自動化はAIでできる、とは言えるだろう。そして実際今AIで自動化できた！されているもののうち、実際のところ「どうでもよかったからできた」ものは、かなり多いのではないか。誰も読まない議事録、定型メール、大して興味のないニュースのまとめ…。

たまにネットで喧伝される「AIで業務効率化を達成した」とする企業の勇ましい報告も、その実態がどうであったかは怪しいものだと思う。最近はAIを活用して効率化を喧伝する政党まであるが、世の中に蔓延っているものがどうでもいいことばかりなのだとすれば、確かにそれは実効的に見えるだろうか。しかしやっていることは、やらなくてよかったことを高速でやっているだけかもしれない。それも膨大なエネルギーを使って。

まぁ、そんなことが続くとは思えないが、当面はそうなりそうに思える。みんな成果を求めているし、成果とは数字だ。数字は単に数字であり、必要性を保証しない。これがAI絵ならばパッと見よくできてるけど何がいいたいのかわからない、必要以上に隙間を埋めたケバくて気持ち悪い絵として認識できるかもしれないが、実際のワークフローとなると難しい。

AIは確かに素晴らしいのだけれど、その素晴らしいものを使ってやらなくていいことばかりしているとすれば、虚しいことだと思うし、破綻すると思うけれど、であればこそ、僕のような凡夫にも人間として多少なりとも存在意義を感じられる、かもしれない。

<関連記事>

あわせて読みたい

AIプログラムは市民プログラマの福音になるか？

2026年1月サイトの現況：アイキャッチは無駄、上位記事の謎、セルフホストやりたい、自宅サーバは死なず

Sun, 01 Feb 2026 00:00:00 +0900

ブログ始めて早13年、思い返して思うことは、定期的にスクショ撮っておけばよかった、ということでした。なのでスクショ撮りつつ近況について。

スクショ

PCから見るとトップはこんな感じになっております。。

うーん無駄に長い。絶対下までスクロールしてる人いないと思う。短くしたほうがよい。なにかこう、せっかくアイキャッチ画像作ったんだからと思って、なんとなく作ってしまったのかなと思います。思いますって、もう自分で自分のことがわからないよ。なんでこんな風にしたんだ？

アイキャッチ画像は結局意味ないよなと思うに至り、ほとんどの記事ページでは非表示になっています。しかし利用しているWordPressのテーマSwellではほぼ必須なのと、まぁ一応対外的にはアイキャッチ画像がOGPになったりするので、設定自体はしています。画像は記事内容からAIに作らせるスクリプトを作成しています。こういうそもそもやらなくていいことが楽になったと騒いでいる2026年。なんだかなぁ。

あとサイトコンテンツが無駄に増えていますが、基本的には内部リンク集になります。これはなんかまぁ、在りし日のテキストサイト的なインデックスを再現しようとしている感がありますね。メンテナンスめんどくさい。しかし意図としては、めんどくさいことをやろう、というのもあったりします。

AIにできないこと、それはめんどくさいこと。なんでだよめんどくさいことやってくれよ。めんどくさいことは全部人間にやらせよう。めんどくさいの本質について考えさせられる今日この頃。

セルフホストをやっていきたい

サイトコンテンツとして、セルフホスト系を一つ目立たせていこうかなぁと最近は思っています。地味に当サイトの最初の記事は大昔に見よう見まねでUbuntu Serverを構築したというもので、原点回帰かもしれません。

あわせて読みたい

小型のメディアサーバー(兼NAS)をたてるその1 〜準備編〜

/19182815-2/

なんだかんだで僕はサーバが好きなのかもしれないですね。サーバというか、コンピュータが人間のために一生懸命働いて、人間がそれで楽しく過ごせる、というのがいいんです。コンピュータはそのためにある。

また、一時期自宅サーバはおしまいですみたいなことを言っていましたが、2026年、セルフホストにて復活の兆しが見えます。

あわせて読みたい

自宅サーバーは浪漫枠

/45948138-2/

自宅サーバは浪漫にしてはいけなかったんだと今にして思います。

アクセスはやや戻り。上位記事の謎

Google先生から嫌われ尽くしていた当サイトですが、今はやや戻って、一時期AI記事別館にも負ける勢いだったのですが、少しだけ復活しつつあります。一時期は最盛期の2-3%くらいまで落ち込んでましたが、今は15%以上にはなっているようです。もうちょっと頑張ったら20%いくかも。

今月というか過去30日で、以下のTimeTaggerの記事が圧倒的PV（というほどでもないが）だったんですが何故。2,3日だけめっちゃ増えてました。Googleのなんかに引っかかっていたんでしょうか？

/timetagger/

ちなみに2位はマネーフォワードMEやめたってよ、の記事。これはまぁなんかわかる。地味にずっとアクセスありました。

あわせて読みたい

マネーフォワードMEの有料会員をやめた理由

/moneyforwardme/

3位は当サイトで累計だと多分一番PVが多い、ブラック研究室の記事。一時期アクセス減ってたんだけどなんかまた増えたんか。ちなみに後年になって母校では微妙に出回っていたらしいです。元同期に「これあいつの記事じゃね？」と思って探し当てられました笑

あわせて読みたい

ブラック研究室の見分け方

/24084902-2/

4位はATOK改悪にランボー怒りの解約の記事。x.comにも貼ったところ、X経由でもけっこうアクセスがあった。実際、ATOKはかけがえのない顧客とブランドを目先の利益で削ってしまったんじゃないのかなー。

あわせて読みたい

ランボー怒りの解約：ATOK値上げ強制移行

/atok-premium/

2026年2月は？

ここしばらく経済系の記事やAI愚痴記事、それだけならまだしも何か思想めいたことを吐き出す記事などあり、たまにみている人は少し大丈夫かといった感じだったかもしれませんが、2月はインフラ系の技術的なちょっとした実証記事が増えるのではないかと思います。

邪悪と自嘲しつつAI記事別館を続けている理由

Wed, 28 Jan 2026 00:00:00 +0900

うちはAI記事の別館があります。

AIによる技術記事備忘録 | AIに同じことを聞かない

当初はAI記事いかなるものぞという実験的な試みで始めましたが、今はもうだいたい感触はわかったので、当初の目的は達せられたと思います。

しかしそうすると、この別館は維持すべきかどうか、というのは悩ましくなります。というのも、検索エンジンやnoteにAI記事のゴミが溢れている昨今、自分もその悪行に加担してよいのか？という倫理上の問題があるからです。

これについて、僕はいくつかの理由で維持の選択をとっています。

まず、AI記事別館の内容については、特に技術系記事において、僕が実際にAIに相談して実行した結果をまとめさせたものなので、内容的には大間違いということはあるまい、と思っているからです。まぁ間違いがないとは言えないのですけれど、自分で書いたほうが品質が高いというわけでもないでしょう。

また、自分で実際に調べる必要が発生したことですから、僕自身、あとで記事を見返すことはけっこうあるんですね。一度やった手順は二度やるものです。なので、僕にとっても実用上の価値があるのですよ。

今後いつまでもAIが使えるか？というのも疑問があります。あるいは、AIが今の品質を持ち続けるか？AIのコストは非常に高く、これはいつどうなってもおかしくないと疑っておりますので、現在のAIの出力を保存するのは価値があると思います。

次に、Google広告の維持という俗な理由があります。本館たる当サイトではGoogle広告を廃絶していますが、Google広告はしばらく出さないと、資格を失効してしまい、再審査が必要になってしまうんですねぇ。で、まぁ今後何があるかもわからないので、せっかくあるGoogle AdSenseの資格は、保持しておきたい、という俗な気持ちがあるのです。ただ本館にはおきたくないなぁと思われ、それで、別館ならいいか！という感じで使っています。

最後に、AI記事別館が検索に引っかかったとして、それは検索エンジン側の問題であり、サイト側の問題ではない、ということです。これは今までもずっとそうでした。今までだって、個人ブログは冷遇され、クソみたいなまとめサイトやコンテンツファーム、通り一遍の情報が貼ってあるだけの公式サイトに追いやられていました。

そしてそれは、SEOできてないのが悪い、あるいはコンテンツの品質が低いからだ、と言われてきました。であるならば、AI別館の記事が検索に引っかかるのは、記事がそれだけ素晴らしいからなんでしょう？ そうでないと、理屈がとおらないですよね。じゃ、なんの問題もないですね。それこそ、GoogleとGoogleを使うみんなで選んだ世界線です。さんざっぱら無視しておいて、いまさらサイト側に何かを求められてもね。

……まぁちょっと恨みつらみも混ぜましたが、基本的には最低限私が確認したコンテンツではありますし、なにより私自身が使っているものですから、それを公開するのは、まぁそんなにおかしなことでもないだろう、という感じでやっております。

<関連>

あわせて読みたい

AIによるまとめや議事録はどこまで使えるのか

/aigijiroku/

レンタルサーバー・カラフルボックスの解約

Fri, 28 Nov 2025 00:00:00 +0900

レンタルサーバーである、カラフルボックスの解約手続きをしている。3年契約していたが、結局あまり使わないまま、もうすぐ期限を迎えるため。

カラフルボックスといえばR18もOKプランがあるので有名だ。別にR18をやろうと思っていたわけじゃないんだけれど、あまりそういうの気にしないようなサイト構築しようと思ったんやね。でも結局なんもしなかったね。

ま、このサイトもしばらく相乗りしていた時期もあったので、まったくの無駄、ということもないか。カラフルボックスは一つの契約で、複数のサイトを展開することができたんよね。

/blog-colorfulbox/

ただこれはだいぶややこしいので、技術的なことよくわからんしなぁ、という理由でレンタルサーバーを選んだ人にはお勧めしない。しかしわかる人がレンタルサーバーを選ぶことはあまりない気もするので、もはやいったい誰向けの記事なんだこれは、という感じである。その後結局自由度を求めてVPSに戻っちゃったしなぁ。

ドメインと解約申請

さて、長々と前置きしてようやく解約の手順だが、解約自体はコントロールパネルから「解約申請」を選ぶだけなので、特に言うことがない。

ただ手続きは置いといて、気になるのは「永久無料ドメイン」はどうなるのか、ということだろう。

「ColorfulBox 永久無料ドメインの取得方法、解約後はどうなるかも解説 - とくしよネット」の方によると、ドメインとの管理は別々とのことだった。なので、カラフルボックスをレジストラとしてそのまま続けてもいいし（永久無料ではなくなる）、移管してもいい、ということのようだ。まぁカラフルボックスを使い続ける理由はまったくないので、移管予定だけど。またCloudflareなの？🥺

そんなわけで、ドメインの有効期限とサービスの期限はそれぞれ異なるので気をつける。

解約申請においては、ドメインの自動更新の無効化にチェックを入れつつ、解約タイミングとして「請求期間の終了」と「即時」のどちらかを選ぶ。普通は即時にする理由は特にない気がする。

申請するとメールが届く。最初にやった時、画面をしばらく開きっぱなしにしていたためか、ちゃんと申請がとおっていなかったわ。

引っ越ししないと

ということで、解約申請をしたので、これから引っ越し作業を気が向いた時に進めていく。正直ほぼ休止しているサイトなので、なくなったらなくなったでいーよ別に、みたいな感じでいる。サイトばかり作ってどうするんだか。どうせほぼアクセスないし、引っ越し先は自宅サーバにしようかな。

あわせて読んで

Cloudflareの違和感：サイバー攻撃じゃないからなんなのか

Sat, 22 Nov 2025 00:00:00 +0900

先日はCloudflare大爆発でインターネットが壊れ、CloudflareのCDN使っている当サイトも落ちたんですわ。ちょうどいいタイミングで来てくれた方すみません。まぁ、察し……だったかもしれませんが。

Cloudflare使っているのは端的に言うとTLS終端が面倒くさいからなんだけど、そういう人けっこう多いんじゃないかな。つくづくhttpsは無駄どころか害悪というか、ボディブローのようにWeb全体にダメージを与えている……実質強制しよったGoogleさんェ……。

しかしこうして障害が起きたときに無力なの見ると、やっぱりめんどくさがらずにちゃんとやるべきか……。ぐぬー。Cloudflare使う方が可用性は高いとかじゃないんだ、俺のサイトが落ちて、俺がそれに気づいているのに、俺が何もできない、それは俺のサイトと言えるのかって、そういう話なんだ。うむー……ちょっと考えます。

で、この件についてCloudflareから全然詫びメールこねぇなと思いつつ、Gigazineで記事になっているのを読んだ。

Cloudflareが大規模障害の原因を発表、XやChatGPTなどインターネット全体に影響を及ぼした障害はサイバー攻撃ではなくシステムの問題 - GIGAZINE

Cloudflareによると、障害の原因はシステムの不備であってサイバー攻撃ではないとのこと。Cloudflareは「今回の障害は直接的にも間接的にもサイバー攻撃や悪意ある活動によって引き起こされたものではありません」と述べ、他者からのシステム侵入を強く否定しています。

読んだ時、だからなんだと思ったよ。サイバー攻撃だろうとシステムの問題だろうと、起きたことが変わるわけじゃない。もちろん原因追及自体は重要なことだけれど、殊更にシステム侵入ではないと強調されても、知らんがなと思う。

この「銀行強盗を撃退できない銀行は許されないが、銀行員のミスで大規模やらかしはしゃーなし」のような奇妙な空気感は、IT業界全体としてあるように思われる。しゃーなしは言い過ぎにしても、「サイバー攻撃ではない」と強く否定するのは、実際的な影響の問題というより、そちらのほうが沽券に関わる、と考えているからじゃないか。

しかしユーザからすれば、サイバー攻撃なのかシステムのやらかしなのかは関係がない。システムダウンさせるのが悪意のある攻撃者なのか、悪意はないけど内部の無邪気な阿呆なのか、前者ではないと強調する意義はよくわからない。これからも無邪気な阿呆がダウンさせ続けたり情報漏洩させるなら、何も安心できないと思う。

システムのやらかしなら情報流出が起きないわけではなく、実際「違うユーザの情報が表示される」というマークシートがズレたみたいなやらかしは稀によくある。最近だとChatGPTのやらかしとかあった（「ChatGPTで個人情報漏えい OpenAIが原因と対策を説明 - ITmedia NEWS」）。

システムは机上の論理的存在ではなく、現実に動くモノだ。価値が生まれるのは設計された時ではなく運用された時で、設計と運用は一体となっている。しかしながら、技術屋というのは設計に寄りがちな人種が多いらしい。確かにまぁ、設計のほうがより技術らしいというか、頭のいい感じにはなるんだがね。

外部からの攻撃ではないんだと言いたがるのは、設計の問題ではないんだとつまり言いたいのかもしれない。技術力の敗北ではないのだと。

だが原因がどこにあろうと、起きたことは大規模障害。結局、運用の敗北もまた技術の敗北だ。

別にそれ自体が悪いってんじゃない。実際、100%防ぐことは不可能だ。それはそうだ。ただ、なんで僕は僕のサイトが落ちてるのに何もできないんだとか、全然詫びメールこねぇなぁとか、普段は「はやくアップデートしろ！攻撃されても知らんぞー！！」とアップデートを脅迫的にせっつくのに、現実には何をしたところで勝手にやらかすやんとか、そういうことは思うよ。

なんというか、対等じゃないし、こっちに目が向いてないな、ということはひしひし感じる。ブログにポストポーテム「2025年11月18日のCloudflareの障害」あがってるから読んだんだけどさ。

Cloudflareチーム全体を代表し、本日インターネットに多大なるご迷惑をおかけしましたことを深くお詫び申し上げます。

君らが迷惑かけたのはインターネットじゃなくて俺だよ。君らにとってはインターネットなんだろうけれど、俺にとってはたった一つのサイトなんさ。知ったこっちゃなかろうが。いや、一応ちゃんと前段で「お客様」にも詫びてるんだけどさ。まぁ、それだけの責任を感じているというレトリックなのはわかるよ。そうなんだろう。実は俺もたった一つのサイトってのは嘘だからな。けっこうサイトやってんのさ。CF使ってないサイトは落ちなかった。レトリックだよ。しかしそれにしても、メールこねぇな。

理念を見て人を見ない時代。そういう違和感がずっとある。

<関連記事>

あわせて読みたい

Google様の言いつけに従って、https化の準備をしなくてはならない

/https63/

あわせて読みたい

やらなくていいことばかりしている

/yaranakuteiikotobakarishiteiru/

2025年でも独自ドメインを取得してホームページを作ろう

Tue, 28 Oct 2025 00:00:00 +0900

独自ドメインを持っておくとインターネット上における活動の自由が大幅に上がる。もはやプラットフォームのサービスに乗っかるのが当たり前という感じかもしれないのだが、独自ドメインさえあれば、その流れに抗って、自分を中心にして活動することができる。

そこには不透明な検閲によるシャドウバンもアカウント凍結もない。 自分だけのネットワークでセキュアかつ便利にデータをやりとりしたり、ストリーミングしたりすることも可能だ。AI学習と本気で抗うこともできる。自分のサイトを公開して、永続的なWebの居場所を構築することもできる。それはつまりホームページである。

実際、僕は独自ドメインで自サイトを持っているが、ここがWebにおける僕のホームだ、という感じがする。この感覚はnoteのアカウントでは絶対に得られない。。ホームページとは和製英語だが、本質的で良い言葉だと思う。和製英語はしばしばダサい扱いされることもあるけれど、日本人が海外から概念を輸入し、咀嚼した結果だ。英語だと完全に同一といえそうな単語はないようで、強いて言えばpersonal websiteになるのかもしれないが、ホームページのほうが本質を捉えている。是非ともhomepageを逆輸出したいところだ。

ホームページの形態は、実はなんでも良い。Webサイトの構築以外にも、SNSのインスタンスをたててもいい。メールでもいい。けれども、基本的には自分のサイトを持つのが第一だろう。そのサイトは全世界に公開してもいいし、鍵をかけて自分や知り合いにしか見られないようにしてもいい。家族用にしてもいい。

なんでもいい。なんでもできる。する自由がある。

それはなんでもしないといけない、とも言える。実際、ここ20年ほどでWebは何かと複雑化されてしまい、妙にハードルがあがってしまったことは事実だ。それはプラットフォームが選ばれた一因でもある。もっとも、複雑化の立役者がGAFAMであることを思うと、マッチポンプじゃないの、とも思うわけだが……。

けれども、大事なところさえ押さえておけば、既存のサービスもうまく使える。自由を守りながら便利さも確保できる。その具体的なものについては、別途記事にしたい。

それでも、できないことはある。

たとえば、関係そのものを持ち出すことはできない。自分のブログを作ることは可能だが、noteと同じように読まれるわけではない。同様に、機能的にXの代替を作ることは可能だが、作ってもそれはXと同じように見られるわけではない。これはあらゆるプラットフォームの代替で言えることだ。また、特にビジネスでも利用している人は、決済機能を抑えられていることが一番のネックになってしまうかもしれない。ここは非常に根深く、解決が難しいことは認めざるを得ない。

それでも、コンテンツは持ち出せる。自分が作ったものをWebに公開し続けることは、少なくともできる。もしかしたら、プラットフォームのフォローではなく、自分のサイトを訪れてくれる人もいるかもしれない。

SNSの10000人のフォロワーよりも、自分のサイトに直接来る1人の常連のほうが、僕は価値があると思う。このあたりは価値観だけれど、大して珍しい価値観でもないだろう。全員に聞いてほしいとは元より思っていない。

理由はなんでもいいんだけれど、僕としては、多少頑張っても自分で自分の居場所をWeb上に作る人たちが増えてほしいし、またそういう人たちの作ったものを見せてもらいたいと思っている。その一助となる記事を書いていきたい。

見せたいものを作るのではなく、残したいものを作る

Sun, 19 Oct 2025 00:00:00 +0900

何故ホームページを作るのか、ということを考えた時、その目的は発信よりもむしろ保存にあると思う。これはホームページだけではなく、写真、文章、絵、音楽、動画、あらゆる創作の根源ではないだろうか。創作の最終的な終着点は保存にあり、発信や公開はその途中駅に過ぎない。

だから、ホームページは公開しなくてもいい。公開しなくてもいいが、多分公開したほうがいい。公開して誰かに届いたという実感は、続けるうえで大きなモチベーションになるからだ。けれども、相手に届けること自体が目的ではないのだと思う。

では保存の目的は何か、それはよくわからない。実用的には、後で見返すため、かもしれない。しかし現実的に、僕らが旅行で写真を撮影するとき、その写真が本当に見返されるかといえば、必ずしもそうではないだろう。結果として、一度も見返されないままの写真のほうが、世の中には多いのではなかろうか。

それでも僕らは写真を撮る。この瞬間を残したいと、なんだかそんな感じがしたからだ。たとえ二度と見返さなかったとしても。

それは自分という存在の確認行為というべきものかもしれない。

そうして残された、他人の生きた痕跡を見ると、少し愉快な気持ちになる。土についた足跡を見て、その足の持ち主に想いを馳せるようなものだろうか。知らない道を歩くときに足跡を見ると、なんとなしに心強さというか、安心感のようなものを感じる。こんなところを歩いた人がいるのかと、驚くこともある。

でもそれは結果だ。足跡はこの道を通る人がいるかもと考えて残すものではない。誰にも見られなかったとしても、自分さえ見なかったとしても、その瞬間を残すという行為そのものに、価値があるのだろう。

そのようにして、この記事もまた、僕のホームページに残される。

Google検索からいよいよ本格的に切られている：noteに逃げてもGoogleの地獄の中で

Sat, 18 Oct 2025 00:00:00 +0900

うちのブログのアクセス解析を見ると、Google検索からいよいよ切られていることがわかる。去年の時点でもっとも多かった時から98%減にまでなり、これ以上落ちたら本当にゼロになりそうだなと思ったが、そこからさらに減り、本当にゼロになりそうな雰囲気がある。すでにBing流入の1/4にまで落ち込んでいる。これは依然としてGoogleが支配的な検索エンジンのシェア率を考えると異様な数字だ。

緑色が合計、青色がGoogleである。なお紫はBing。最近逆転した。

僕はこのブログを、検索エンジンにおける個人サイトの扱いとして一つのメトリクスにしている。Googleの悪口ばっかり書いてるから嫌気されるとかあるのか、とも思ったりもしたけれど、彼らにそんな能力があるとは思えないので、当サイトは一般的な場末の個人サイトと見てまぁいいだろう。なので、この状況は、程度の差こそあれど、どこもかしこも似たり寄ったりじゃないか。

こういう状況なので、noteなどのプラットフォームに転載せざるを得ないような状況になってしまっている。そしてnoteに記事を投稿すると、公明正大にAI学習に同意したことにされる。その金はGoogleが出している（「note、Googleと資本業務提携。生成AIを活用し、創作活動をより一層サポート｜note株式会社」）。なにこの地獄。「それはこんな顔ではありませんでしたか」のホラーかよ。

一応、学習に同意しないオプションはあるので、そうしているけれど、それを守っているのかどうかはプラットフォームを信じる以外何もなく、彼らの倫理など信じられるものではない。そもそも、Webで公開したが最後、基本的には学習されるものだと考えるほかないだろう。だってできてしまうんだから。それを否定しても仕方が無いと思う。そうでなくても、テキストはコピペされてきた。こんな場末のブログでさえも、丸コピペされた時はあったくらいだからねぇ。

そう思いつつ同意していないのは、同意したという体裁を端金で取らされたくないからだ。多分しばらくは「お小遣い入りました😚」みたいな投稿するやつが出てくるんじゃないかと思うが、それが支配と衰退の始まりであることは、歴史とも言えない、ほんの10年、15年の、現在進行形の物語だ。

というかもう既にnoteはAI記事だらけになっているね（noteはあれに金払うの？）。AI記事の中には比較的よく出来ているものがあることは確かだ。正直フォローしているアカウントすらある。ただそれは、ポテチのように軽口だということだ。人間ジャンクフードを食べたい時もあるだろう。そういう時にいいんだ。でもジャンクフードまみれの生活は嫌だっていうだけだ。

しかし振り返って、僕自身が、自らをジャンクにしていなかっただろうかと、最近思う。つまりGoogleが求めているのはジャンクであり、そうであることを自身に課していなかったか。

情報の切れ端。断片。干物。それは構造化され、見出しがあり、わかりやすい。1+1とは？足し算とは？どんな時に使うの？1+1の例は？結論：1+1=2。これはまだマシで1+1=11が結論だったり、調べて見たけどわかりませんでしただったりする。それでもわかりやすい。構造が。

構造的であれ。10年以上積み上げられた僕の記事は、9割以上に見出しがつけられ、それなりにセマンティックを考慮している。また、1記事完結も意識されている。タイトルなどで多少は検索との親和性も考慮している。それは、学部生の時に文章とはそのように書くものだと思い込まされたのもあるし、そうすることに合理性があると一定信じられたからなのもある。実際一定程度合理的である。

これからも見出しはどんどんつけていく。見出しは理解を助ける。見出しは有用である。強調も有用である。それは意味理解を助ける。しかし、必須ではない。ブログは論文ではないしレポートでもない。

僕は本当に考えていただろうか。ただ誰かから、そうであることを求められて、適当に流されたのではなかろうか。それは理解を助けるものというより、形式的な呪縛ではなかったか。

一応まだBingからの流入はあるが、これもそのうちになくなるのだろうと思う。そうして考えた時、自分が本当に何を書きたかったか、あるいは読みたかったか、考えないわけにはいかない。少なくとも、検索エンジンやAIのために文章を書いているわけではない。

この文章は、見だしをつけられる。つけたほうがわかりやすいかもしれない。ただ、つけたくない気がした。そういう文章を、増やしてきたい。

サイト公開13年にしてメールアドレスの公開

Thu, 02 Oct 2025 00:00:00 +0900

このサイトもついに今月で13年を迎える。だからというわけではないのだが、管理人に直接連絡をしたい人向けの連絡先として、メールアドレスを公開することにした。フォーム設置ではない。これはなんというか一周回ったというか、気持ち的には十周回って結局それか、みたいな気もする。でも逆にもうこれでいいんじゃないか、という気もする。とりあえず、いわゆるフォーム設置はしなかった。

どうしていまさら

そもそも今さら僕に直接連絡を取りたい人がいるのかはよくわからない。今までも問い合わせフォームなど、直接連絡手段をおいたことはあった。

あわせて読みたい

ブログのダイレクトメッセージはGoogleID公開でいいんじゃなかろうか

/blog-direct-message/

この時は、メールアドレスはスパマーの餌食になるからと、どうやらGoogleアカウントをそのまんま乗っけるという形にしていたようだ。その後フォーム設置した記憶があるようなないような。どうしたかな。

いずれにせよ、その後少ししんどくなってやめたような記憶がある。だいたい僕という人間は会ったことのない人と文字列のやりとりだけで心通わせられるほど器用ではないのだし。というかメールでくるのは、ブログを見て、というよりは、何かよくわからない感じのものが多かった。

とはいえもうすぐサイト13年目になる今、昔書いた技術メモを検索エンジンでやってきた一見さんが見るばかりのサイト、というのもなんだかとてもつまらない気がした。まぁつまらなくても続けられるというのが、ブロガーの特性として必須なのではないかと思うし、別につまらなくても良いと言えば良い。

それでも、今さらまた設置する気になったのは、少し寂しくなったのかもしれない。まぁポジティブなことを言えば、これから少し動く予定があるので、連絡先も用意しようとは思っていた。

なぜメールアドレスの公開なのか、あるいはなぜ問い合わせフォームではないのか

さて、公開方法はメールアドレスをまんま公開である。

tama@hack-le.com

ここに送れば僕のところに届くかもしれないし届かないかもしれない。というのも、メールサーバは今のところConoHaのアプリケーションサーバを活用しているので、恐らく安定していると思うのだが、今後メールサーバをセルフホストする可能性があるため、そうするとたまたまサーバが落ちていて届かなかった、ということがあるかもしれないからだ。

そんないい加減なことでいいのかと思われるかもだが、届かなければ世界一有名なインフルエンサであるところのメーラーデーモンさんが返信をしてくれるのだから、また後でもう一回送ってくれという感じだ。そういうこともある。役所だってすべての通知を配達証明で送るわけではなく、普通郵便で送ってくるじゃないか。

また、先の記事を読む限り、どうやら10年前の僕はスパマーに暗殺される心配をしていたようなのだが、今はスパムメールにより精神破壊爆弾が自動的に炸裂することはないらしいことも知ったので、おきもしない過度な心配はやめることにした。スパムメール曰く永久に凍結しているらしい僕のAmazonアカウントはもはや絶対零度だが、もちろん普通に買い物している。そもそも普段からくる正規のメールマガジンからして十分スパムみたいなもんだし、今さらAmazon絶対零度のお知らせが増えたところでどうということはない。

あとこの時代だが、問い合わせフォームのほうがスパムの餌食になりやすい側面がある。というのも、フォームは身分を偽って送信することができるからだ。これにより、「フォーム問い合わせ代行」なる商売が爆誕している。

メールの場合も代行業は可能だが、代行業者に自鯖ドメインを使わせる、大量メール送信を自ドメインとIPアドレスの責任でやる、など、送信者の責任がけっこう大きい。ブラックリスト入りしたときのインパクトは、個別のサイトによるフォーム送信のIP Banどころの騒ぎではない。

考えて見ると、メールというのはよく出来た仕組みだと思うし、なんだかんだでそれなりにちゃんと我々は運用してきたらしい。

まぁフォームにも確かに良いところがある。既定のフォーマットに合わせてバリデートをかけられる。なので、登録申請などは確かにフォームが向くだろう。つまりワークフローの中に位置づけるなら、入出力が明確なフォームのほうが都合がよい。

しかし逆に言うと、単独の個別の連絡については、必ずしもフォームが向くわけではない。個別の連絡というのはだいたいフリーフォーマットが必要になるし、身元確認のために必要もなく個人情報を入力させるくらいなら、自分のメールアドレスを使わせるほうが余程有効だ。捨てアドもあるが、そんなもんすぐわかるし返信しないよ。

送信者と受信者にはそれぞれ等分の責任があって然るべきで、メールは割と、それがちょうどよい。

また、メールアドレスはどこでも公開できる。最近はGoogle検索で個人サイトが除外されているため、noteに記事を転載しているわけだが、メールアドレスならばさらっと書ける。メールアドレスは取り回しが良い。

13年目の結論

ということで、サイト13年記念というわけではないが、メールアドレスを設置した。返信するかはわからないけれど、少なくとも読むとは思う。

AIはおま環がわからない：WordPressで毎日全記事の更新をしたら記事IDが爆増した事件簿と迷探偵AI

Sun, 28 Sep 2025 00:00:00 +0900

とてもニッチな話。うちのサイトはWordPress製でテーマとしてはSWELLという有名なテーマを使っている。SWELLは簡易的なPVカウント機能があるのだけれど、dailyやweeklyの差分は自分で計算する必要がある。

で、せっかくカウンタがあるんだから活用しようかなと思って、最近全記事のPVのスナップショットをとるようにしたのさ。で、そこからdaily, weekly, monthlyの差分を計算するバッチ処理を書いた。計算しただけでは甲斐がないので、計算した結果を全記事のカスタムフィールド（自分で定義できる変数欄みたいなの）にセットするようにした……ところ、毎日記事IDが3000ずつ増えるようになった🥺

原因はActivityPubプラグインをよく知らずに適当に入れていたことだった。これによりデータベースに10万件以上のゴミIDが出来ていた。おま環故に、これがわかるまでけっこう苦労した。また完全なるおま環であったためか、AIに相談したらパニックの極みであり、ジャイアントスイングをされた。

事の顛末

毎日差分をセットするようになってから3000ずつ増えるようになったため、これは明らかにそれが原因だ、というのはわかっていた。記事数は1000で、daily, weekly, monthlyで界王拳三倍。計算も合う。

原因はわかるが、どうしてそうなるのかは理解できない。カスタムフィールドの更新をするだけで記事IDが増えるのは明らかに奇妙な挙動だ。LLMに相談したが、LLMも混乱しているのか、PUTではなくPOSTをつかってましたとか（確かにPUTのほうがいいので修正したがそこではない）、カスタムフィールドの更新で register_rest_fieldを使っているのは行儀が悪いので register_metaを使いましょうとか（これもその通りではあるので修正したがやはり関係ない）毎日記事を取得しているのが原因ですなど、何も問題がないところを「問題を発見しました！」と嬉々として報告してきて無能。

最終的に、初心にかえってコンテナにアクセスし、データベースの状況を調べたところ、以下のような大量のUPDATEログがIDを使っていたことが判明した。

| 44700 | [Update] 2021年… | 2025-09-26 00:21:17 | publish | ap_outbox |
| 44699 | [Update] macOS… | 2025-09-26 00:21:17 | publish | ap_outbox |
...

oh……。

ap_outboxってなんぞ……と思ったら、ActivityPubプラグインだった。これがわかると、無能だったLLMが突如として活き活きして「完全にそれです。更新がトリガとなって通知でIDを消費しているのでしょう。Q.E.D.」と。

ActivityPubプラグインというのは、WordPressのFediverseに接続するためのプラグインなのだが、性質上デフォルト設定では更新を検知するとこういう挙動になるらしい。カスタムフィールドの更新はWordPress的には更新なので、こういうことになってしまったわけだ。

元よりノリで入れていただけのプラグインだったので、設定をちゃんとすれば問題なくなる可能性はあったが、面倒臭くなってプラグインを停止した。停止すると、記事ID爆増はおさまったので、やはりこれが原因であったらしい。ちなみにメタIDはさらに酷いことになっていた。データベースから削除した時のログがこれ。

MariaDB [hackle_db]> DELETE pm
 -> FROM wp_postmeta pm
 -> LEFT JOIN wp_posts p ON p.ID = pm.post_id
 -> WHERE p.post_type = 'ap_outbox';
Query OK, 77470 rows affected (2.394 sec)

MariaDB [hackle_db]> DELETE FROM wp_posts
 -> WHERE post_type = 'ap_outbox';
Query OK, 25799 rows affected (57.199 sec)

77470件……。そんなに……。

AIは問題は解けるが問題文は作れない

反省点としては、まずよくわからないことをするもんじゃあないよという当たり前の話である。また、LLMの得意不得意の境界線がハッキリ出たシーンでもあった。

WordPress + ActivityPubプラグイン導入
全記事のカスタムフィールドを毎日更新

これら特殊な状況が組み合わさった結果、AIは完全なる無能と化した。

しかしap_outboxなるものが大量にIDを消費している、というデータベースの状況を提出したところ、一気に覚醒してたちまち適切な判断を下せるようになった。

これはつまり、AIは与えられた解けるが、現実世界において問題と思われるものはしばしば問題文の体裁にいたっていないことが多く、その状態では無力だ、ということを示している。

今回の事例で言えば、AIにとって問題設定は「WordPress REST APIでカスタムフィールドを更新すると、カスタムフィールドのIDが変に増加する」だったが、実際には「WordPress REST APIで投稿を更新すると、ActivityPubプラグインがフックし、 ap_outboxという投稿タイプを大量に新規作成したため、 wp_postsのIDが異常に増加する」である。

まぁわかってみればそりゃそうだ、ではあるのだけれど、現実に起きる問題とは、今回のように固有の環境が起因していたり、大きな影響を与えていることは少なくない。AIのベンチマークが必ずしもアテにならない原因の一端ではあろう。

これについて、AIがローカルの知識をすべてもっていれば解決できる！と思う向きもあるかもしれないが、一体誰がどうやって「すべてのローカル知識」とやらを用意し、そしてそれをAIが適切に利用できる形にするというのか。そもそも僕らはすべてのローカル知識があるから問題がわかるのだろうか？少なくとも僕はデータベースを見るまでActivityPubプラグインが原因とは思いもしなかった。

恐らく必要なことは、「問題文がそもそも大きく間違えているのではないか？」という疑いをもち、問題文自体を作成するための支援ができることだと思うが、恐らくそのような挙動を許すと、今度は「合っているのに間違っている」と他責に走る偽陰性のようなものが許し難いほど高まるように思える。

問題を設定することの困難さはいわゆるフレーム問題の枠組みなんだろうが、なぜこれを人間が出来るのかと考えたとき、それは責任のように思える。問題をこのように設定する、というのは、論理的判断というより、責任なのではなかろうか。死なないAIは原理的に責任が持てない。

となると、この問題は原理的に人間の領域、ということになるのかもしれないなぁ、などということを、最近はAI記事に負けている我がブログのPVを見つつ思うのであった。

レンサバからVPSに帰ってきた

Sat, 24 May 2025 16:35:02 +0900

このブログは12年……今年で13年の歴史があり、当初のLivedoorの無料ブログからインフラレベルで幾重の変遷を経て今に至るのだが、先日レンサバからVPSに帰ってきた。おおう、懐かしのConoHa VPSよ。このはちゃんのイラストはいらんから安くしてくれんかね……。とりあえずサービス維持調整費とかいう欺瞞は本当に早くやめてください。これ始まって2年以上たつけど、真面目な話なにかの法律に引っかからないんだろうか。

まぁそれでも3年分の契約で7割引きは十分お安い。VRAMは2GB。4GB欲しい。2GBの金で4GBほしい！！！！

当サイトのインフラの歴史

当サイトのインフラは以下のように変遷している。

2012年：Livedoor無料ブログ
2016年
- 独自ドメインの取得
- ConoHaのVPSに移行、WordPress構築
- https対応
2017年
- PHP 5.4 -> 7.1
2020年
- PHP 7.1 -> 7.4
2022年
- PHP 7.4 -> 8.1
2023年
- ConoHaのVPSからレンタルサーバーのカラフルボックスに移行
2025年
- ConoHaのVPSに帰ってきた

インフラの移行は面倒臭いしリスキーなのでそうあることではないのだが、こうしてみると2016年が大きな転機だったようだ。その後は基本的にせいぜいPHPのバージョンをあげる程度のことしかしていない。DBのバージョンはあげてなかった気がする。

httpsは本当にいらなかった

まぁやっぱり面倒臭かったのはhttps対応かなと思う。当時も「本当に必要かこれ」と思っていたけれど、今にして思うと本当に必要なかった。うちのサイトに暗号化しないといけない情報は特にないです。

とはいえ、やらないとブラウザの覇権を握ったGoogleから抹殺されてしまうために渋々従わざるを得なかったのだが、当時はGoogleが個人サイトそのものを抹殺するとはまだ思っていなかった。僕がGoogle嫌いなのは、Webサイトを運営していてGoogleの態度が変わっていくのを目の当たりにし、またジャイアントスイングされ続けてきたからだろう

Google検索しているだけだったら、「最近の検索クソだな」とは思っても、嫌いにまではならなかったと思う。実際プロダクトはウンコでもプロダクトの基礎となる部分では今なお大きな存在感を放っているし、エンジニア仲間の友人は今でもGoogle信者を自称している。実際色々な仕事をしているのはそうだ。しかし今の僕には、Googleがいなければ他の誰かが似たようなことをしていただろう、という風に感じられてしまう。少なくとも、僕がWebサイトを構築し運用することに関しては特に問題がなかっただろうし、もしかすると今よりも良い世界線だったかもしれない。

Googleの影響力よ

意図したわけではないのだが、何故かまたGoogleの愚痴になってしまった。色々な切り口がある中で、いつも最初にくるのはこれなんだが、逆説的にそれだけGoogleの影響力が大きかったということなんだろうなぁ。個人的にはGoogleはGAFAで最初に陥落するとすら思っているけれど、昨今のAI事情の中でどうなるか次第だ。

ちなみに僕は散々愚痴っといてなんだが、今はAIチャットボットとしてはGeminiに課金している。これについてはGeminiがいいというよりOpenAIが自滅し続けているだけという感覚だ。

/chatgpt-yoisho/

GeminiはChatGPTほどごますりしてこないので、Geminiを使っている。あと馴れ馴れしくないからさ……。

いつかローカルLLMがまともに使えるようになったら、なんとかそうしたい。現状はまだちょっと厳しい……。

https楽になったし、検索ももう気にならない

さて、Googleの愚痴が本題ではなく、VPSに戻したことが本題なんだが、愚痴っていたらそれなりの文字数になってしまった。

しかしここまでの話でも言えることはあって、少なくとも以下の点はレンサバからVPSへの移行という面倒くさい作業をする背中を押した。

Cloudflareのおかげでhttps対応が楽になった
どうせもう検索ヒットは死んでるので、ダウンタイムの発生や移行ミスで検索順位が落ちるとかまったく気にしなくなった
botウザい

https対応が楽になったというのは、まぁCloudflare Tunnelだなぁ。まぁLet’s Encryptのおかげで個人でも対応はできるんだけど、面倒くさいし定期的に証明書再発行ミスってサイトがマルウェア扱いされるみたいなことはよく起きる。っていうかあの作業がまず面倒臭いんだが、そういう無意味な構築・運用をしなくてよいっていうのは実際的にも精神的に楽だね。

そしてまぁ、移行はなんかミスると長時間のダウンタイムとかに繋がりかねず、そうすると検索順位が大きく落ちるなどのペナルティも発生しうるだけれど、既にジェノサイドされている個人サイトとしてはもはやどうでもいい。まぁと言いつつも当サイトのアクセスにおいて検索エンジン経由が多いのはそうなんだが、多いといったところでしれているし、そもそも検索で情報が見つからなくて困るのは検索している人であって僕ではない。

まぁこれを言うとサイト運営の意義とは何かという話なんだけれど、実際なんなんだろうと思いながらサイトを続けている。なんなんだろうね。ただ現状に納得いっていないことは確かだ。検索からすべて弾かれてももはや知ったことではないと思う。

そんなことより今はbotがウザい。たまにアクセス伸びてんなと思ったらだいたいフィルタリングしきれていないbotだよ。昔はまぁそれも大して気にならなかった、というのも検索エンジンなどに機械的に評価されようというならある程度のbotも仕方ない、という気持ちがあった。

しかし今となってはもうそんな気持ちもない。僕は何のためにブログを書いているのか、サイト運営を続けているのか、もはや僕自身にもわからない。昔は利他と自己満足のないまぜのようなものと解釈していた。その気持ちは今もある。

あわせて読みたい

ブログを続ける理由

/cross/

一方で、もはや自己も利他も薄っぺらく思えることも確かだ。しかしでは何かと言われるとわからない。だが少なくともGoogleの検索エンジンのためではないし、ましてbotのためではない。

レンサバだと対応が限られるが、VPS上なら対応の幅が広がるし、そもそもCloudflareの対応が有能である。やはりサイトは自由でなくては。

サイトは続くよ多分どこまでも

そんなわけでまぁ、とりあえず2年ぶりのConoHaのVPSに帰ってきた。どういう形態になってもサイト自体は続けられることはありがたいと思う。本当はWordPressやDockerの話をしようかと考えていたんだがまったくしていない。まぁこれはまた別の機会に。

ConoHaはまぁGMOなんでGMOだけれど、とりあえず国内で安く使えるし、なんだかんだでいいと思うよ。

お友達紹介

お友達紹介コードを貼っておしまい。こっから飛んで使い始めてもらったら1000円分のクーポンがもらえるはず（このとも～友達紹介～｜レンタルサーバーならConoHa）。そして定常的に使ったら僕に2000円分のクーポンが入る。クーポンのためにブログを続ける人生だった。

しかし今まで数百回クリックされているはずだが実際に使うとこまでいったのは1人だけである。もはやVPS流行らないのか。

あわせて読みたい

やらなくていいことばかりしている

/yaranakuteiikotobakarishiteiru/

サーバーも会社も学校も、いつでも逃げ出せることが大事

/escape/

WordPressがゴタゴタしているので移行も考えたが、当面は維持

Sat, 02 Nov 2024 18:07:58 +0900

このサイトはWordPressでできている。で、WordPressといえば最近ゴタついており、何かと極端なTwitterなんかではもうオシマイだみたいな言説も流れていた。自分はそこまでは思っていないし、なんとか軟着陸してほしいと思ってはいるけれど、そうは言ってもリスクは感じていて、ブログも今のうちから移行を検討すべきだろうか、などと思っていた。

まだまだ続きそうだが、対応はいったん保留

経緯については「WordPressとWP Engineの戦い #WPDrama」がとても詳しく、また更新してくれている。今のところ緊迫した状況が続いているようだ。まぁ裁判沙汰にまでなってしまったし、長期戦になってしまうのだろうと思う。

色々と思うところはあるのだけれど、いったんそれは置いといて、WordPressにあまり寄りかかってしまうのもリスクはあるよなと、わかっていたことではあるのだけれど、認識を新たにした。それで、WordPressから他に移行することもちょっと考えた。3か月前に契約したVPSがほとんど遊んでいる状態なのもあり、そっちに移行しようかな、とか。

考えたが、結論としてはいったん保留。確かに緊迫した状況ではあるけれど、長年に渡って巨大なエコシステムを築き上げてきたWordPressの世界が今日明日で崩壊するはずもなく、また少なくとも今あるソフトウェアは使い続けることができるのだから、大慌てで引っ越すのはしんどいだけで割に合わないだろう。今後状況がよくなる可能性だってあるのだし。また、現在のWordPressホスティングサービスも契約は1年以上残っているため、大急ぎでVPSに移行するメリットは特にない。

いざとなれば移行できるような見通しはたてたい

ただそれはそれとして、いつでも引っ越せるようにはしておきたいとも思った。テーマやプラグインを使っているところ……具体的には、このサイトはテーマとして有料のSwellを使っているのだが、Swellの機能で実現しているブロックや、またプラグインでコードのシンタックスハイライトをしている部分などは、調整が必要そうだ。12年も続けているので影響範囲を調査するだけでも労苦である。今さらだけれど、あまり使い過ぎないようにしておいたほうが良さそうだ。

また、WordPress以外のCMSを実際に運用したことがないので、何か小規模なサイトを立ち上げて試していきたい。移行の準備とまではいかなくても、本当にいざとなれば「これこれをすれば移行できるかな」くらいの見通しはたてたい。今はそれすらもないので。

以下は現在検討中のもの。CMSもあればいっちょヘッドレスCMSやってみるかな。

Statamic: LaravelベースのCMS。いったん使ってみるつもり
Ghost: node.jsベースのCMS。ヘッドレスとして有名だがヘッドもあるっぽい。消費メモリが多そう
microCMS: ヘッドレスCMS。国産。セルフホスティングできないが個人サイトなら無料の範囲で収まりそう。フロントエンドの勉強はいる。
Strapi: 有名なヘッドレスCMSだがXでは悪評を聞く。外人がshit shitと言っていたので逆に気になる
Netlify CMS + SSG: だいぶ勉強がいりそう。SSGはNext.jsかHugoか。VPSは馬鹿らしいのでホスティングサービスの選定も出てくる

こうして書いてみて思ったが、エンジニアとしてはヘッドレスCMSやNetlify CMS + SSGみたいな仕組みを使いたいなぁという気持ちになる一方で、コンテンツを運用・管理するブロガー目線だといやちょっとそれは……という気分になる。更新のしやすさは更新頻度に直結する。

あとブログには向いてなさそうだが、調べている間にDirectusなるCMSもあって、これはコンテンツ管理というよりデータ管理っぽいのだが、既存のRDBなデータベースをマネジメントできるヘッドレスCMSという感じで、ダッシュボードをつくったり管理画面を作ったりするのに良さそうで興味がわいた。このブログとは別のブログで使いたい感じがした。

個人ブログを12年続けて思うことなど

Wed, 30 Oct 2024 08:00:00 +0900

先日2024年10月17日に、ブログを開設して12年を迎えた。ただ、実を言うと本当にこのブログを開設した日付がいつなのかはわからない。というのも、このブログはLivedoorブログのサービスを利用するところから始まったのだが、その日付がいつだったか覚えていないためだ。その後自分でVPSでサーバを借りてやるようになったため、今となってはわからない（今はさらにレンタルサーバのホスティングサービスを利用しており、また最近はVPSに出戻りを検討中）。

ブログの開設日とはなにか

しかしそもそも考えて見ると、何をもってブログを開設したと言えるかは定義があるわけでもない。ブログサービスでアカウントを作成した日は一つのわかりやすい基準だが、人によっては初投稿を公開した日がそうかもしれない。あるいはそれらは準備段階で、一通り諸々定まった日こそが開設日だという人もいるかもしれない。

つまるところ、開設日の決まり方に法的な決まりがあるわけでもないので、結局はその人が「今、自分はブログを開設したぞ」となんらかのことをきっかけに思った日が開設日である。であるならば、どこかの時点で自分は10月17日を開設日と決めたので、まぁそれでよいのだろう。

サイトの記録をつけておけばよかったと思う

このように自サイトの開設日すら定かではないといった具合だから、このサイトがいつ何をしてきたのかはもはやわからない。まぁ過去記事を漁れば、当時のサイトをスクショした画像なども時々あるので、なんとなく想像することは可能だけれど、当然ながらそんなことをするモチベーションはない。

したがってこのサイトの動向についてはなんとなくの記憶だけが頼りなのだけれど、12年も続くともはや何がなんだかわからない。思うのは、少しでも記録をとっておけばよかったなぁ、ということであった。サイトのトップページのスクショ程度でも構わない。実際、12年分のサイトトップページの記録程があれば、非常に面白かったのにと思う。それは他人にとってもけっこう興味深いコンテンツではないだろうか。特に当サイトはLivedoobブログからWordPressにうつったり、またWordPressのテーマを何度か変えているため、サイトの概観が劇的に変わる瞬間が何度もあったから、それなりに見応えもあったかもしれない。

まぁ過ぎてしまったことは仕方ないので、今さらながらサイトの記録もつけていこうかなと思う。ちょうど、ダイエット日記なんていう自分の記録めいたことも始めたことだし。

12年で変わったこと

この12年の変遷について、いくつかの切り口で想いを馳せたい。

自分: 仕事が変わった

この12年で変わったことはたくさんあるが、一番大きいのは、仕事が変わった。まぁこれは変わったというより変えられるように動いたというべきだろう。大学院を中退し、キャリアの最初で躓いた僕は、新卒一括採用が普通の日本社会において、かなり厳しいスタートを切ったことになる。それは自覚していた。不安定な身分にいた。

このブログを立ち上げたのは、そういう不安定な身分だったことと無関係ではない。なんでもいいから世の中に何かを発信しなくてはという切迫した感じがあった。

その後非常に特殊なキャリアを歩んだものの、どんな仕事をしていても、気持ちだけは常に技術者のつもりでいた。紆余曲折経て、上京し大手と言えるIT系の企業にも雇ってもらえたことで、社会的にも明確にエンジニアと言える立場になったのではなかろうか。また、生活も安定した。とはいえ安定するのに10年かかったのは、やはり人生設計においては非常に厳しいものがあったことも確かだ。未だ独身でいることをそのせいにする気は無いけれど、影響はあったと思う。そろそろ生涯独身も見えてきたなぁ。

しかしその分身軽で自由だ。今年、個人事業主として開業届を出た。また、それとは別に友人と法人設立の予定もしており、この週末にも登記の申請書類を整える予定だ。これは独り身でないとできなかったなと思う。一度手にした社会的立場とそれなりの安定収入をまた捨てることになったが、独身の自分には大きすぎるものだったし、せめて己だけは自由でありたいと強く願った結果だった。この先どうなるかはわからない。

ブロガーとしての心理的変化

自分の人生が変わるに連れて、ブログに書かれる記事の内容も、また根幹となる思想も変わっていった。振り返って、転機となった記事はこれかな。

あわせて読みたい

ブログ作って4年半、ですます調からであるだ調を基本に変更する

/desumasu/

ですます調からであるだ調に変更したという記事で、今となってはこんなことを真剣に考えていたのかと過去の自分に驚く。まぁ自分で言うのも何だけれど、僕は真面目なんだと思う。

記事内では、「人のために書く」から「自分のために書く」というスタンスのシフトだと主張している。そういわれると確かに、ですます調のほうが、人に見せる、解説する、という気分はあるように思われる。実際昔の記事を読むと、若輩者ですが、書かせていただきます！という態度がなんとなく見て取れて、我ながら面はゆい。

それに引き換え、今は「好きで勝手にやってます。よければどうぞ」くらいのものだ。コレは確かに、心理的な変化があったかもしれないな。少しばかり不貞不貞しさを感じる。笑。

しかし、今も読者の存在を意識していないわけではない。Web上に公開している以上、それは当然のことだ。人の目は常に意識している。ただ昔は「私があなたに伝えたい」だったのが、今は「何を感じるかはあなたが決めること」そういう気分が強くなっているように思う。実際のところ、前者のほうが読者を意識した態度だとは、必ずしも言えないのではないか。後者のほうが、読者の自意識をより強く認めているとも考えられる。その観点では、前者の態度は無自覚ながらやや傲慢とさえ言えるかもしれない。

もちろん僕は良いものを書きたいと思っている。こんな徒然とした文でも、時間の制約の中で、少しでも良くしたいと願っている。だがそれは、専ら自分のためだ。自分がいいと思うものを、自分のために書きたい。でもそこに他者の目が入ることは意識しているし、それは嬉しく思っている。まぁこれくらいが今の私の精一杯ですが、貴方はどう思われますか。ああ、言わなくていいですよ、それにしても、もう10月も終わるというのに、なかなか涼しくならないですね。え、涼しいですか？そうですかー。

個人ブログ全体の危機とインターネット

ただまぁ、最近はその人の目につきづらくなってしまったようだ。これは個人ブログ全体の問題で、数年前からだいぶ言われていたと思うが、特にここ1,2年が決定的だった。このブログなど、良いときに比べて一時はユーザが98%ほど減った。今は多少マシになったが、それでも以前より90-95%ほど減っている状態だ。

やはり検索流入の激減が大きい。しかもそれはほとんど検索エンジン側の問題だ。今となっては、彼らにコンテンツのクオリティを測る能力などまるでなかったことが白日の下にさらされているため、かつては「品質を向上させることだ」とGoogleの言うことを真に受けて念仏のように唱えていた者たちもほとんど見られなくなった

まぁ、今となっては検索エンジンにそこまで依存していたこと自体が誤っていたんだろうと思う。かつての個人サイトは相互リンクやジャンル別サーチエンジンへの登録、一般掲示板への宣伝などちゃんとしていた。そういうあれこれを全部ぶっ飛ばしたのが、管理人目線からのGoogle検索の衝撃だった。人間誰しも楽に流れる。しかもそのほうがうまく機能するとなればなおさらだ。

そうして従来のやり方が失われたところで、突然梯子を外されたというのが個人的な感覚である。

あわせて読みたい

Google先生に見捨てられた個人ブログがこの先生きのこるには

/blog/

問題がどうであれ、多くの個人ブログ（サイト）が危機的状況に陥っていることは変わりない。このSNSの時代に、わざわざ自サイトを開設するという多大な労を厭わない者たちのコンテンツが、ネットの海の藻屑と消え、企業が文字単価0.1円で令和の奴隷たちから買い上げた文字列や生成AIの出力ばかりが蔓延るようになった。これは今後も続くだろう。

こんな状態だから、検索自体が既に信用を落としているし、これはWeb自体にとっての危機でもある。しかし、みんな次がわからない。僕もわからない。まさか相互リンクよ再び、ではないだろう。個人ブログはWebの実際的な運用の中で育まれた。Web自体が大きく変わり続けている以上、この広告に塗れた濁流の中で、活路を見出さないといけない。

大切な場所

最後に少し暗い話をしてしまったが、別に未来を憂えているわけではない。期待しているわけでもないが。ただ種々の事情があったにせよ、なんだかんだ12年続けたこのブログは、僕にとっては大切な場所の一つだ。続けてきたので、これからも続けていきたいと思う。とてもささやかだけれど、それが僕にできることだし、できたことだからだ。

今さらサイトのトップページを作った

Sat, 21 Sep 2024 01:54:55 +0900

このブログを始めたのが2012年の10月なので、もう丸12年たとうという時期になって、ついにトップページが作られた。

https://hack-le.com

といっても、いくつかのカテゴリ別ページを作っただけなんだけどさ。どうせ検索エンジンからの一見さんばかりだし、TOPページ見られることも、あまりないんだろうけどさ。まぁでも少しは見に来てくれる人もいるかもしれないし……。

どうしていまさら

まぁ厳密にはトップページがなかったは言い過ぎで、「ブログ」がトップページだったとは言える。そういうことではなく、サイトの水先案内的なルートのページという役割をもったページというものはなかった。これまで何度か作ろうとしていたが、ついぞできることはなかった。

理由は色々あって、まず面倒だったというのがあるんだけれど、それ以上にブログというのはそういうものと思っていた。実際最新記事一覧ページしかないブログは今なお多いし。

それというのもブログというのはGoogle検索と共に成長してきたので、ユーザの流入は基本的に検索エンジンであり、それはつまりサイトの窓口が実質としてGoogleだったことを意味している。なので、わざわざエントランスページを作って「Sorry, this site is Japanese only!!」と警告する必要もなかったわけだ。すべてのページが入り口だった。

しかし時代は変わり、いつ頃からかGoogleは、商売っ気のない個人サイトを嫌気し、企業が1記事500円（税込み・システム利用料引き前）で令和の奴隷たちに書かせた量産コピペ記事を有り難がるようになった。その結果、当たり前のことを2000文字に薄めた情報とも言えないナニカが検索上位を独占した。

最近は「検索結果はクソだからなぁ」と言えば「ああね」と言った具合でたいていの人に通じるようになったよ。数年前までは、まだ多くの人がGoogle神を信仰していて、Googleの検索結果にもの申せば「お前の検索の仕方が悪い！」と悪し様に言われたものだが、もはやそういう人もついぞ見なくなった。

それでもみんなGoogle検索を使い続けているのは、今まで使ってきたし、またiPhoneにもAndroidにも標準で搭載されているからであって、品質がよいからというわけではないだろう。しかし他に乗り換えても大して結果がよくなるわけでもないこともあって、Google検索以外をデフォルト検索エンジンにしているのは僕のような変わり者くらいだ。

この状況ではGoogleが変わることは望めない。しがない個人ブロガーの僕は、もはや検索流入に頼れる時代でもないことはわかりつつも、さりとて今さら何をどうしてよいかもわからず、やれることも思い浮かばないので、とりあえずトップページを作ったのだった。

まぁ要は「検索を前提にしたサイト作りの崩壊」を肌で感じており、なんとか対応しないとなぁと思う中で、とりあえずやるべきと思えることの一つが、サイト案内的なトップページを作ることだったので、重い腰をあげて作った、という流れだ。

サイトについて考えるきっかけになった

なので、これからちょっとずつ見やすくしていきたいと思っている。見てくれる人がどれだけいるかは別にしても、少なくとも自分にとってもこれは良いことだと作ってみて思った。というのも、「このサイトは何するものぞ」ということを考えないわけにはいかないからだ。

……何するものなんだろうね？特に決まっていないから、12年も続けてこれたんじゃないかという気はする。あれしなきゃこれしなきゃとか思ったら、しんどくて続けられなくなるし。まぁでも、ちょっとくらいは考えてもいいのかなとも思ったな。

実際、「そういえば最近あれの記事書いてないなー」とか、最新記事が数ヶ月前になってるカテゴリ見て思ったよね。

時代がどうあれ

最近は使えるAIなんかも出てきて、検索エンジン自体がその存在意義に揺さぶりを賭けられているためか、またちょっと変わってきたかなぁとか思ったりなんだりもする。

あわせて読みたい

Googleの個人サイト冷遇の流れに歯止めがかかった説（あるいは希望的観測）

/google-kojin-site/

まぁ希望的観測かなとは思うし、何よりGoogle検索に過度に依存していたこと自体はどうあろうと反省すべきなんだよな。

これからもインターネットの世界では色々あると思うけれど、僕自身はせめて泰然として、自分のためにサイトを続けていきたい。

Googleの個人サイト冷遇の流れに歯止めがかかった説（あるいは希望的観測）

Fri, 13 Sep 2024 01:21:26 +0900

ひたすら個人サイトや個人ブログを排斥し続け、特にここ一年はトドメをさしたかのように思われたGoogle検索だが、驚くべき事に8月以降、少しマシになってきているという話で、実際このサイトも少しアクセスが回復している。

正しくないと知っていたんだろう？

アクセス回復したのなんて数年ぶりくらいじゃないかな。7月くらいはもうよかったときの2%くらいまで落ち込んでいた（2%落ち込んだんじゃないよ、2%まで、つまり98%落ち込んだんだよ）んだけれど、ここ1か月でなんか知らんけど数倍になってるね。といっても、2%まで落ち込んでからの数倍だから、昔と比べたらやっぱり酷いもんではあるんだけれど。

Googleも、検索結果がゴミまみれだったのはまぁ認めずとも本当は認識していたんだろうなと思う。そして個人サイト冷遇も本当はright thingじゃないことを知っていて、それでもあえてやっていたんだろう、と僕は邪推している。そのほうが商売になるし、どうせみんなGoogleを使うに決まっているからだ。

これについて、興味深い分析記事がある。

ラガバンの戦術は、検索の質を下げることで検索クエリの数（つまり、同社が検索者に表示できる広告の数）を増やすこと（訳注：「エンゲージメント・ハッキング」）だった。そうすれば、ユーザは目的のものを見つけるまでにGoogleでより長く時間を過ごさなければならなくなる。

（中略）iPhoneやSamsung、Mozillaまで、あらゆる検索ボックス提供者とGoogleとの独占的な取引により、品質を落としてもビジネスへの影響はないだろうという（正確な）考えのもと、プロダクトを劣化させて利益を上げようとするメタクソ化の勝利だった。

— Google検索を殺した男――Googleはいつ、どこでメタクソ化に舵を切ったのか | p2ptk[.]org

これはゴミみたいな記事に上位を独占させることが、Googleの利益になることを示している。極端な話、ユーザが情報が見つけられずGoogle検索を永遠に彷徨い続ける事が、Googleの商業上の勝利となる。

まぁ普通に考えて誰が好き好んでそんなことするのかという話だが、これまで築きあげてきた信用が、そして失われたその他の選択肢が、ユーザにGoogle検索を使わせ続けた。

求めているものを出せ

しかし今、それが揺らぎつつある。まぁそうだね、ChatGPTだね。Googleも慌ててGeminiを出したけれど、悪化した検索結果がGeminiの品質を落とすという冗談みたいなことにもなっていたからねもう。

/google3-google-ai/

上のケースは検索に出てきたスマホの大嘘記事をGeminiが信じてしまったというものだが、ジャンルによっては本当に酷いんだよねぇ……。家電とかで検索してもさ、どこぞの企業ブログが書いた「オススメ掃除機34選」とかしか出てこないんだよ。34選ってそれもうオススメじゃないから。知ってる名前34個並べただけだから。

オススメっていうのは、プライドをかけて選び抜く、独断と偏見に満ちた、反発も覚悟の性癖開示であって、そんな「本当の」お勧めを教えてくれるのが個人サイトだったのに、もはやそれが検索には出てこない。

この状況じゃ、検索エンジンを使う機会なんてど忘れした言葉の意味を調べる時くらいだ……が、最近はそれさえも、2000文字で薄めた無意味な文字の羅列みたいなのが出てくる始末。

そんな状況だから、実際、Google検索で調べ物している人、急激に減ってるんじゃないかな。ChatGPTのほうがマシだもん実際。なんならTwitterのほうがマシ……なんだけど、今のTwitterはインプレゾンビに支配されているのでもうだいぶ無理。本当に金ってやつはインターネットを狂わせるようだ。

そういうわけで、今まで冷遇し続けてきた個人サイトの再評価は、可能性としてはあるのかなと思う。実際、上にも書いた邪推なんだけど、Googleは多分何をどうすべきか知ってるんだよ。今までしてきたことをやめればよくて、そうすると、自ずと個人サイトは再評価されるはずだ。そしてそれこそ、AI時代の中で検索エンジンが生き残る道だと思う。この記事に書かれているような独断と偏見に満ちたこと、ChatGPTは絶対に言わないからね。でもそれが、ユーザが本当に見たいものだし、そういう数十億の個性の発露こそ、インターネットの中で輝くべきものだと思う。AIが書いた当たり障りのない一般論じゃなくてね。

……ま、今後どうなるかはわからないし、どうなってもいいんだけどさ。別に再評価されなくても、Googleがどうあろうと、世の中がどうあろうと、僕は僕の思うことをやるだけだ。

Google AdSenseを撤廃、個人ブロガーにとって広告収入とはなんだったのか

Mon, 12 Aug 2024 19:42:46 +0900

このサイトから撤廃したのはもうだいぶ前になるけれど、他のサイトからも撤廃した。ただAI記事別館にはまだつけている。完全に撤退してしまうと、また流れが変わった時に苦労しそうなので……。まぁ別館のほうは遊びだから（本館であるこのサイトも趣味だけど）。

Amazon広告は貼り続けるけどね。もう全然金になんかなってないよ。それでも貼るのは、額面以上に嬉しいからだね。まぁ個人ブロガーの広告収入に対する微妙な気持ちを、この記事ではちょっと書いていこうと思う。

もうだいぶevilだったので

まぁ撤廃するまでもなく、個人サイト冷遇の流れを受けてPVが既にピーク時の2-3%にまで落ち込んでいるので、既に収入は途絶えており、ただ無駄にスペースを食うだけのウザいバナー状態になっていた。最後に広告収入が払い込まれたのはいつだったろうか。

まぁそれはページ全体広告など、どう見てもevilでしかない広告を嫌気していたのもある。Googleにすべてまかせて、あらゆるところに広告を貼り付け、ページ遷移の際に画面すべてを詐欺まがいの広告で覆い尽くす例のアレをやっていれば、まぁもうちょっと収入は入ったのかもしれない。

とはいえ、もはやサーバー代にもならないような小銭のために、Googleと一緒にevilになる気にはなれない。勝手に悪堕ちしてくれ。

金は出さないが口は出す

また、何かとポリシー違反だなんだとやかましかったのもある。技術系の記事が多めのこのサイトでは、あまりそういうことはなかったが、エンタメ主体のサイトではPTAのごとくなんだかんだと文句をつけてきた。正直その基準は理解に苦しむものであり、機械的な文字列マッチングで判定しているとしか思えないものだった。実際、何も手を加えずに再審査に出すと、ほとんどの場合そのままPASSした。

潔癖症なのかと思いきや、肝心のGoogle広告自体は下品なものが多い。ビビッドな広告（隠語）を平気で垂れ流しておきながら、人様のコンテンツ内容に口だししてくるのは純粋にイラつかされる。確かに上品な記事とは言えんかもしれんがね、お前んとこの広告よりはまだ品があるぞと言いたかった。

それでも金を出すなら、まぁ再審査を出すくらいの手間はしてやろうかとも思えるが、前述のように金さえ出さなくなくなったので……とまぁ、これは検索流入がなくなってPVが落ちたので、と同義だが、まぁいずれにせよ金は出さない癖に口やかましさだけは増すばかりで、さすがにやってられないと思った。

広告掲載をやめる

Googleが変質したのはだいぶ前からだが、ここ一年はとどめの一撃を刺された感じで、多くの個人ブロガーたちの断末魔が聞こえる。Google広告を撤廃したのは僕だけでもないようだ。

元々、このブログでお金を稼ぐことは全く考えておらず「はてなブログ Pro 代が出ればいいなー」ぐらいの考えだったので、広告をすべて外すことにしました。

— Google AdSense の広告掲載を全て止めることにしました - しばやん雑記

この感覚は非常に僕と近くて、まさに僕も「サーバー代くらいになればいいなー」という考えだった。もう一つ付け加えるなら、サーバー代なんてはした金なんだけれど、その金が出るということに、金銭の額面以上の喜びを感じられたんだよ。多分、そういう人が多かったんじゃないかな。

広告は感謝の表現だった（と思えた）

このサイトも一時とはいえお小遣いくらいは広告収入でもらってきたので、あまり悪し様にだけ言うのもフェアじゃないかなとも思うから、広告モデルの良かったところについても言うと、 「対価を払ってくれ」という言いづらいことを言わずにいさせてくれたことだな。そしてまた、ユーザ側も自然体で対価を払うことができたことだ。

昔、「なんでエンジニアの人ってタダで情報共有するの？」みたいなことを営業の人に聞かれたことがある。その時僕は「返したいからですよ」というようなことを言ったんだけれど、それはあまり納得してもらえなかった。「まぁセルフブランディングの一環ですかね」と言うと僅かに頷かれた。まぁこれはどちらも本音なんだよ。別にブランディングはしてないけど。本質的にね、まぁ自己満足のためなんだ。

何故満足できるかと言えば、誰かの役に立っているという実感と、そして感謝があるからだね。まずPVは実感になる。見られているってことは、それだけ役に立っていると思える。でもそれだけじゃ、やっぱりちょっと足りなくてね。できれば、ありがとうとか言ってもらいたいと思うんだよ。でもブログにコメントつけるのってけっこう勇気いるやん。実際このブログのコメント数なんてほとんどないよ。まぁしゃーない。

そんな中で、広告収入って、感謝の気持ちの表れのように感じられたんだな。ボランティアでお昼ご飯代が出たような気持ちに近いかもしれない。労働の対価と考えると全然割に合わないけれど、ほんの気持ちと考えると嬉しい。

なので、広告がユーザと運営者を繋ぐ架け橋だったことは、確かにあったと思う。

脱Googleしたというより

まぁでも、そんな時代はもう終わりということなんだね。企業サイトが広告を貼るのは純粋にビジネスだし、またGoogleももうそういうサイトしか相手にしなくなってしまったようだ。そこにあるのは公式PRと、紙より薄くて当たり障りのない情報とも言えないナニカだが、まぁそういう未来が選ばれたらしい。

そんなわけで検索エンジンはもはや公式サイトを探す場所でしかなくなったわけだが、一応このサイトは曲がりなりにも10年以上やっていることもあるためか、僅かながらのPVが残っている。しかし、それももうすぐなくなるのかもしれない。

ということで、「脱Google」カテゴリに入れているが、これに関しては脱Googleしたというよりさせられたというほうが感覚として近い。なにしろ次が見つかっていないからね。

まぁでも、あまりにもGoogleに頼り過ぎてしまったという反省はあるんだよな。ブログ自体は続けていきたいし、たとえ読者が僕一人になってもやっていこうという気持ちもあるけれど、さすがにそれは寂しいからね。ブロガー自身、変わっていかないといけないんだろうな。

WPFormsでGmailのフリーアドレス経由で独自ドメインをfromにしてメール送信する

Fri, 02 Aug 2024 14:31:05 +0900

なんかすごい長ったらしいけど、要は受信専用で使っていた独自ドメインのメールアドレスについて、WPFormsのSMTP機能でメール送信したくなり、Gmailのエイリアス機能を使って、Gmailアカウント経由でぶっ飛ばす、ということ。昨今の事情を考えるといつまで使えるのかわからないんだけれど、少なくとも今は使えるみたいなのでメモ。

前提

独自ドメインで、メール受信としてCloudflareのEメールルーティング→Gmailに飛ばしている。受信専用ならこれでいいやと思っていたが、WordPressの投稿フォームプラグイン、WPFormsを使って、Fromを独自ドメインのメールアドレスとなるように、メールを送信したい。フツーなら、投稿フォーム用のメールアドレスでSMTP認証で送信したらいいわけだが、受信専用なのでそうもいかない。

ということで、Gmailのフリーアドレスのアカウントを経由して飛ばす。以下のような感じ。

graph LR
sender(WPForms)
gmail(gmail.com)
receiver(フォーム投稿者)
sender --> gmail
gmail -->|hoge.comとして内容確認メール送る| receiver

やり方

基本的には、gmail.comのアドレスを使って、独自ドメインのメールアドレスで送信するやり方を、WPFormsに適用する、という方法になる。そのやり方については下記の記事が非常に参考になりました。

Cloudflare とGmail で独自ドメインのメールを無料で送受信する方法【Cloudflare Email Routing】 #cloudflare - Qiita

詳細は記事に参照として、送信側の設定としては、下記の操作をする。

Gmailのアカウントでアプリパスワードを設定する(既に非推奨だがキニシナイ)
Gmailにアドレスを追加する

設定の「すべての設定を表示」
「アカウントとインポート」タブ
「他のメールアドレスを追加」
独自ドメインのメールアドレス + エイリアスとして扱いますにチェック
SMTPサーバの設定
- SMTPサーバ: smtp.gmail.com
- ユーザ名: ログインアカウントのメールアドレス
- パスワード: アプリパスワード

この設定後、同じようにSMTPを使ったメール送信をすると、追加した独自ドメインのメールアドレスで送信できることが確認できる。

WPFormsにおいても、SMTP認証を使って、上記のSMTPサーバの設定をすることで、送信することが確認できた。しかしながら、設定画面でSPF/DMARCの設定できてないよとWarningがでる。でるが今は送れるので、いったんよしとする。

注意

メーラのSMTP設定でも同様にすることで、メールクライアントからメール飛ばすことも可能。しかし昨今の情勢を考えると、永続的に使えるとは思わないほうがよさそう。

アプリパスワードがdeprecated扱いでいつなくなってもおかしくない
DKIM/SPF/DMARC周りが厳しくなっている昨今、いつまでもちゃんと届くか不安

なのでまぁ、一時的な措置としては本記事の内容でも良いと思うが、今後もずっと安定してSMTP使ってメール送りたいなら、やっぱりまぁちゃんとしておいたほうが安全かなぁと思う。さすがに自分でメールサーバたてる気合いは普通ないことを考えると、ConoHaのメールサーバを借りたり、あるいはZoho Mailあたり使うほうが良いかな。

あわせて読みたい

格安メールを求めて、Zohomailを使い始めてみる

/zohomail/

テキストで図を書けるWordPressのMermaidプラグインは最高だぜ

Wed, 08 May 2024 17:53:21 +0900

ブログ記事を書いていると、ちょっとした図を書きたくなることがある。だがブログ書きにとって、図は一つの鬼門である。というかめんどくさい。ただただめんどくさい。いくつかのコンポーネントを矢印で繋ぐ程度のしょっぱいシステム図を書くために、編集ソフトを起動し、エクスポートし、アップロードして貼り付けるのは苦行である。そんなことはやりたくない。

できるぞ、Mermaid記法なら。

救いのMermaidプラグイン

Mermaid記法とは図をテキストで記述するもので、図の種類によっては手で頑張って書くより余程楽に書ける。テキストであるため、最近ならばAIに下書きさせることも可能だ。Notionなんかも対応している。というかNotionで図を書く方法は標準的にはこれしかない（Draw.ioがブラウザで使えるエクステンション出していたりするが）。WordPressでもプラグインを導入してMermaid記法に対応することにより、手をキーボードから離すことなくブログで図を書くことができるというわけだ。

graph LR
hoge(Hoge)
fuga(Fuga)
db[(謎のデータベース)]
hoge -->|hogehoge| fuga
hoge -.- db

こんな感じでさらっと図が書ける。描けるじゃなくて書ける。正直これくらいの絵でも、あるのとないのとではわかりやすさが全然違うことはよくあるのだが、そうは言ってもこの程度の絵でも描くのは非常に面倒なので、ブログ記事だとついつい端折ってしまいがちである。でもテキストなら書ける。

Gutenbergとの相性よし

実際これは非常に便利で、手放せないプラグインの一つになった。また、このプラグインはブロックエディターであるGutenbergと非常に相性が良い。

Screenshot

このように/mermaidと記述するだけで、ブロックを呼び出してコードを書くことができる。これがクラシックエディタだとそうはいかない。

Gutenbergは出始めは全文コピペすらままならず阿鼻叫喚で、その時の印象が悪すぎたためにクラシックエディタをずっと使い続けていたのだが、ひたすら改良されていったようで、今はだいぶ使いやすくなった。箇条書きをシフトでインデントできない（スペースでできるけど……）のはなんとかしてもらいたいし、htmlコードのタグも複雑になってしまっている（REST APIで頑張ろうと思った時に壁になりそうなんだよなぁ）が、エディタとして使う分には良いと思う。

記法は覚える価値あり

Mermaid記法はテキストベースであるので、ChatGPTをはじめとする昨今の生成AIとは非常に相性が良い。言えばスニペットを書いてくれる。書いてくれるが、そもそも「編集ソフト起動するのめんどくせぇ」が根幹にあるわけで、当然「AIに聞くのもめんどくせぇ」のである。

したがって、いちいち調べながら書かずに、書きたい図が書ける程度には覚える必要はある。必要はあるが、これは気合いを入れて2,3時間ほどチュートリアルを頑張ればほぼほぼやりたいことはできるようになると思われる。

この知識はずっと使えるうえに実践的なので、学習コストという観点で見たとき、非常にコスパ・タイパに優れる。Mermaid記法はWordPressだけではなく、Notionで使えるし、拡張機能入れればVSCodeでも使える。テキストで書けるということはコード管理することも可能である。まぁあまり複雑な図を書くのには向いていないので、本格的にやるならそれ用のツールを使うべきだけれど、そんな図を書くことばかりじゃない、というか書きたい図の9割はドラフトだと思う。そんな9割の需要をMermaid記法は汲んでくれるのです。

ということで、WordPressでMermaidは最高だぜという記事でした。Mermaid記法は食わず嫌いの人が多いように思うのですが（というか自分がそうだった）、学習する価値はあるので是非やると良いと思います。使う人を増やしたい。自分はプラグインでWP Mermaid Plugin — WordPress.comを使っているのですが、もう一年ほどメンテされてないのですよね。良いプラグインだけれど、インストール数も1000+程度。使う人が増えればお金にもできるだろうしメンテナンス意欲も沸くはず……。

みんなで使おうMermaid。

2024年謹賀新年笑える自分であるように

Wed, 03 Jan 2024 13:04:55 +0900

新年あけましておめでとうございます。技術系の記事が多めで、一見さんが多いブログではありますが、時々見に来てくれている人もいらっしゃるようなので、年始くらいはご挨拶したいと思います。一見さんももちろん嬉しいお客さんですが、やはり一番嬉しいと思うのは、何度も来ていただけることですね。

このブログを始めたのは2012年の10月なので、今年で12年目となります。これだけ続けていると、良くも悪くも私という個人の変遷がなんらかの形で表現されるわけですが、まぁ当然のことながらブログから垣間見える表層は個人の一側面でしかありません。とは言うものの、一側面であるには違いなく、また表層に見えて案外深層だったのかもしれないと、昔の記事を読み返して思うこともあります。

個人サイトは個の発露

ブログ記事に含まれる情報はその記事だけで完結している（させている）ものですが、個人というフィルタを通して端々に滲み出る感性は連続的なものであり、その記事だけ読んで掴めるものではありません。まぁそういった感覚的なことを良しとしない向きもあるのですけれど、それは大きなニュースメディアのようなものに求められるもので、一方個人ブログというのはしがない個人の発信の場ですから、情報そのものではなく個の感性こそが基本となります。ですので、個人ブログは一見さんよりも常連さんのほうがより記事の内容を把握できるので、書き手としても常連さんのほうが嬉しいわけですね。

まぁ、実際にはメディアが取り扱わないようなニッチな情報というのも個人ブログの大きな役割の一つですから、そういった情報そのものを求めているという向きもあるやもしれません。特に技術系の記事にはその傾向があることは事実でしょう。いや、一見さんが多いという統計データを素直に解釈するならば、そちらが主たるユーザであると認めるべきなのかも。そうなのかな。

わかりませんけれど、少なくとも管理者がブログを続けるモチベーションは、ビジネスではない場合、情報ではなく個の発信が基本であることは間違いないことです。たとえそれが限りなく情報の形を取っていたとしても、それは個の発露です。そうでない場合、そのブログは続かないでしょう。人間はAIではないのです。

技術記事はAIに……できる？

AIといえば、最近は純粋に技術的な記事はAIに書かせて別館を作っております。これは2023年の大きな変化と言えましょう。

AIによる技術記事備忘録 | AIに同じことを聞かない

最初の間はちんけな記事しか書けんなぁなどと思っていましたが、コツを掴むと自分で書くよりよほど丁寧な記事を圧倒的な短時間で書き上げることができるようになりました。具体的には、自分でかけば数時間かかるだろう記事が、20分程度で書けるほどです。これは素晴らしい。

と書くと簡単そうですが、それがそうでもありません。これならみんなブログを書けるのでは？と一瞬は思ったりもしましたが、個人ブログの再流行はやはりないでしょう。前述のとおり技術革新のみならず個人の試行錯誤も必要であり、またいくら短くなったとはいえ0秒で書けるわけでもなく、そもそも 「何故書くのか？」という本質に、多くの人は躓きます。なので、たとえAIを使ってもブログ記事を書けない人の方が多いと確信を持って言えます。

まぁ実際AIに聞けばなんでも答えてくれる中で何故AIにブログを書かせるのか？とはそれ自体が大きなテーマであり記事をいくつも書けてしまうわけですが、その記事はAIに書けない類の感性の塊であり、時間もかかるのでここでは割愛致します。なんでもAIというわけにはいきませぬ。

とはいえ情報が主体となる技術記事はかなりAIが得意とするところなので、AIによる記事執筆もどんどんやっていきたいところです。新しいことをやっていれば必ず新しい技術的な知見を得られるはずなので、AI記事ブログが盛り上がることは、新しいことに挑戦している自分の証明にもなるはず。

と言いつつ、最近ボチボチとやっているAWSのStep Functionsなどは、まだ熟れていないためか、ChatGPTがまるで役に立っていないという事実もあります。で、結局いつもの試行錯誤トライアンドエラーでなんとかかんとかやっており、そのような比較的新しい技術については結局私が書く羽目になるかもしれませんねぇ。まぁそういう人がいないと、AIも学習元がなくて困りますか。結局最後は人間なのか。めんどくさー。

2024年は転機の年にする

新しいことと申し上げましたが、2024年は私にとって後年振り返った時に「あの時が転機だった」と言える年にしたいと思っております。これは新年の抱負です。何をするかはある程度決まっていますが、そのために必要なことはまだわからないことが多いですし、何よりその先に何が待ち受けているのか、まったくわかりません。もしかしたら、後悔することになるのかも。

ただ、それでもやるべきだと強く感じています。特にここ2,3年、私はずっと難しい顔をしていたと自覚しています。自分はこんな顔でこんな声を出すのかと、薄ら寒くなることがありました。慢性的な不眠のために、睡眠薬をもらうようになりました。俺は薬に頼らないと満足に寝ることもできないのかと情けなくなります。いったい俺は何をしているのか。

曲がりなりにも生きてきました。失ったものもあります。積み上げられたものもあります。それは結果です。私は取捨選択したつもりですが、実際のところ大きな流れの前に小さな個たる私の徒手など空しく大した意味はありません。意味があるとすれば、その手を動かしたことそのものにあるのでしょう。だからこそ掴めたものもあります。流れには逆らえませんが、その中で何を得て何を失うのかは、ある程度個にも制御出来る部分があります。

特に重要なものは金です。金はいります。すべてを失えません。失わないように動きます。機会があれば得ようとします。最善を尽くします。それは多分、納得できます。納得できれば、僕は多分、笑えるんじゃないかな。大笑いというわけにはいかないかもしれませんが。まぁ、それもいいでしょう。何もうまくいかず、ここまで積み上げてきたものを放り出す結果になったとしても、馬鹿なことをしたもんだなぁと、笑える自分でありたいのです。

今年もよろしくお願い致します。

技術記事はAIに書かせたほうが楽になったよ

Thu, 23 Nov 2023 15:45:26 +0900

このブログの記事はだいたい人間99%なのだけれど、だいたいAI99%のAI別館もある。

AIによる技術記事備忘録 | AIに同じことを聞かない

わざわざ手間暇かけて別サイトにしたのは、AI生成であることを明確にするためというより、こだわりのためだ。曲がりなりにも10年以上ブログをやっているだけあって、僕も文章には多少こだわりがあったらしい。Stable Diffusionの出力する6本指の絵は気にならないが、ChatGPTの出力する漂白された文字の羅列には反吐が出た。良いとか悪いとか以前に何も感じない。乾いている。この干物みたいな文字列を僕の文章と思われたくねぇ。僕の反吐を塗りたくる必要がある。

技術記事との相性が抜群

しかし、色々試していると、いくつかのジャンルにおいてはChatGPTの書く記事は中々のものであることがわかってきた。その一つが技術系の記事だ。最近書かせた記事を羅列すると、以下のようなものがある。

自分としては、出来にけっこう満足している。必要な情報が書かれているし、むしろ自分では面倒臭がって書かないようなイントロダクション（上記の例ではなぜDynamoDBはDecimalなのか？Decimalだと良いことはあるのか？など）も書いてくれて、記事を読むレベルの人にとっては役立つものなんじゃないだろうか。

最初の頃はシェルスクリプトのスニペットのメモ記事くらいしか書けないなと思っていたが、アウトラインを書かせてそれを膨らませていく手法を取り入れてから、「お、これならまぁいいかな」と思えるレベルになったと思う。具体的なノウハウは下記の記事にまとめた。

ChatGPTを駆使した技術ブログライティングのアプローチ

この記事は技術記事というよりハウツーに入ると思うが、ハウツーも中々AIと相性の良いジャンルだと思う。

つまり、 「情報」を対象とした記事は書きやすい。今までめんどくさくて書かなかった記事を書けるようになり、非常にハッピーだ。

お気持ちは人間

一方で、「それって僕の感想ですが何か？」系のお気持ち情感たっぷりの記事は、まだまだ人間には及ばない。以前よりはだいぶ書かせられるようになってきたものの、薄めたカルピスのような味気なさは否めない。たとえば以下の記事は、このサイトでもよく取り上げるテーマ「これからの個人サイト」なのだが、それなりにボリューミーではあるものの今ひとつ。

デジタルの流れの中で生き残る個人サイト

このサイトではたとえば以下の記事が近いかなと思うが、自分で言うのもなんだけれど僕の記事のほうが1000倍くらい読めると思う。

あわせて読みたい

Google先生に見捨てられた個人ブログがこの先生きのこるには

/blog/

少なくともお気持ち記事については、今後もしばらく人間の独壇場であろう。

他には、最近始めた脱Googleの記事なんかも、AIには書けない記事だろうな。技術とお気持ちの境目みたいな記事、こういう体験ベースの記事はAIには書けない（捏造することはできる）。また、何か特定のものに対してネガティブな記事を商用AIは苦手としている（というより苦手にさせられている）。そんなわけで、レビュー系もAIには厳しい。

まぁつまり、答えのない「思想」や「感情」を対象にした記事をAIに書かせるかなり難度が高い。多分、自分で書いた方が千倍早くて良いものが書ける。ただし、特定の情報源に基づいた論理展開であれば、そこに思想があったとしても、かなりやれるんじゃないか、とも思う。情報と思想の境目は、今一番AIライティングでやりがいのある領域かもしれない。

AIへの期待は大きい

AI記事の技術が発達しても、本質的なところで人間のお気持ちが同じ人間にとって重要である以上、このブログもネタには困らなさそうである。

とはいえ、今後ローカルAIなどで、ポリがコレなアレとかを気にしない、自分の感性を忠実に学ばせたAIなんかを使えるようになれば、状況は変わるかもしれないが、これは技術的な問題以上に政治的、社会的な問題があるので、あまり一般には広まらなさそうである。個人的にはチャレンジしたい領域でもあるので、生成AIの動向には引き続き目を離さず、市井の一市民として自分なりのチャレンジをしていきたい。

噂のステマ規制法はうちの場末ブログにも影響あるのかな

Fri, 03 Nov 2023 15:33:13 +0900

そういえば先月から、ステマ規制法なるものが施行されたと話題になっていた。また阿呆な規制作ったんだなぁ……と思って他人事みたいでいたが、よくよく考えてみるとうちのサイトのAmazonアフィリエイトにも影響があるんじゃないか？🤔と思って調べている。正直よくわからんのだ。

ステマ規制法について

ステマ規制法とかいうのが10月から実施されたらしい。無駄な仕事を作るのに余念がない俺たちの日本政府が、また余計なことをしたという感想である。さすが一人あたり労働生産性最低クラスでバンバン過労死してる我が国だぜ。

ざっと調べている感じ、要は広告主との関係性を明示せよというもので、言ってること自体は正しいからもしかすると良い法律だと思う人も多いのかもしれないんだが、こんなもんコストがかかるだけで何一つ問題を解決しないクソだよ。こういう無駄をひたすら積み重ねて、我が国の今があるんじゃない。

インフルエンサのステマについて

多分これを聞いて最初に思い浮かぶのはインフルエンサーによるステマじゃないかなと思うんだけど、インフルエンサーと広告元に関係があるとか、言われなくてもだいたいわかるだろ。言わないとわからないやつには言ってもわからんよ。私の信じるインフルエンサーと広告元に関係があるなんて思いもしませんでした、青天の霹靂です！なんてやついる？いたとして、この阿呆は関係性の明示に気づくか？気づいたとして、それで行動が変わるのか？何も変わらんよ。なので無意味。

ブログのアフィリエイトについて

これが僕の関係するところであり面倒くさいポイントだ。このサイトにはAmazonアフィリエイトがあって、それはブログの中で「Amazon広告あるからね」的なお約束文言をフッタに仕込んで対応している。で、これはこれでいいよっていうんならいいんだが、「もっとちゃんと一つ一つ明記しないとステマだ😡」とか言われたら面倒くさいよな。ただ常識的に考えてほしいんだが。

たとえば上の記述を見て、「コイツはAmazonやHIKSEMIとの関係を隠して広告を貼っている！読者を騙そうとしているに違いない！！ステマだああああ！！！」ってなる面白人類いるかって話よ。いたとしてそれはもうそいつ側の問題やで。

実際、この法律の意図するところとだいぶ異なると思うんだが、対応しないといけないのかはよくわからんのよな。もうちょっとちゃんと調べないといけないとなぁ。っていうか聞くところねぇのか？いつもいつも、知らん間に規制ができて、窓口もようわからん、あっても本当に使えるのかわからん、異議申し立ても何もできねぇ。そんなんばっかりや……。

まぁどんなにバカバカしくても、もし本当にそうしないといけないっていうなら、それはもうやるしかないんだけれど、これAmazonのツールで作ってるやつだし、必要ならAmazon側で画像にPR表記つけるとかして対応してほしいなぁ。機械的にiframeタグの中になんか埋め込めばいいとかくらいなら、こっちで対応してもいいけどさ。

サクラレビュー問題

今回の法律でAmazonやらなんやらに蔓延るサクラレビューは明確に黒になったはずだ。しかし、今までだって「☆5をつけたら商品もう一個プレゼント！」なんてまともな企業のやることじゃあなかったよ。つまりサクラレビューなんてのはまともじゃない企業がやることで、だからこそブランドの価値が見直されるということにまでなってしまった。「おお、サンワだ安心」みたいな。Amazonを荒らし尽くしている彼らは、日本の法律なんか遵守しないんじゃないかね……。下手したら日本にいないでしょ。

まぁ連中を放置していたAmazonの罪は重いよな。以前☆5依頼を告発するレビューしたらAmazonに却下されたわ。本来的にはプラットフォーマーであるAmazonが責任を持って対応すべきことなんだが。まぁそんな感じだから、正直、何も変わらないんじゃないかね……。この状態がいいとは僕も思ってないよ。以前こういう記事を書いた。

あわせて読みたい

Amazonのレビューは報酬目当てのサクラ系だらけで全然参考にならない

/amazon-review/

ただまぁ、こんなんは法律で規制しようとしたって効果がない割に副作用のほうが大きいだろっていう（今まさに僕がこうやって無駄に調べ物をしている）話。いや、何も変わらないならまだ良くて、業者がもっと巧妙になり、サクラチェッカーでも追えないくらいに進化してしまったらどうしてくれようか、という心配まである。

調べる無駄

まぁもうちょっと調べるけど、それにしても何してんだろうという徒労感がすごい。これやって何がどう生産されるんだ。このブログは趣味でやってる個人ブログだからどうなろうとどうってことないけど、Webメディアやってるところはてんやわんやだったろうな。なんなら今でも対応に追われてるんじゃない。

何も産まない仕事ごっこで勝手に疲弊するのは自分たちだけにしてほしいもんだよ。民間にまで強要するのいい加減にやめさせられないもんかね……。

ChatGPT + DALL-E 3 でアイキャッチ画像を作成する

Mon, 30 Oct 2023 12:44:21 +0900

（追記: いきなりナーフされている。毎日単位で品質が下がっている。一応まだプロンプトの工夫でなんとかなるが、できるうちにやっておけという感じ）

このサイトはイマドキ流行らない文字ばかりの殺風景なテキストサイトです。いや……でした。最近、ついにこのサイトでもアイキャッチ画像が作られるようになり、だいぶ賑やかになった。過去記事も含めて、順次更新していっている。まぁね、僕もブログ歴10年以上ですから、アイキャッチ画像くらい軽く作ってしまうんだなぁ。はい、全部AIです。

なぜアイキャッチ画像を作ってこなかったか

まぁそもそも、僕はアイキャッチ画像というやつについて、非常に懐疑的だ。英語だとfeatured imageというらしいが、日本語のアイキャッチ画像のほうが実態に即しているだろう。最近、XことTwitterでは、「外部リンクからタイトルを表示せずアイキャッチ画像のみ表示する」というイーロンマスク主導の嫌がらせ政策が実施されたが、これによって、意味不明な画像を添付したツイートみたいなのが激増することになった。これはアイキャッチ画像が、マジでアイをキャッチする以外何もしていなかったことの証左だろう。それに何の意味があるのか。

もちろんYouTubeなんかではサムネイルは非常に重要なので、ちゃんと作れば機能するのはわかる。わかるが、ブログの記事レベルでいちいちちゃんと作ってられるか、という話だ。そもそもブログはYouTubeのようなプラットフォームに展開しているわけでもないため、アイキャッチ画像によって人目を引く意味も限定的だ。

その結果、どこぞの素材サイトから適当に拝借してきたものをそのまま使ったり、頑張るなら文字入れしたりといった程度でお茶を濁すことになる。

素材サイトから適当なものを探すのはけっこう面倒臭い。慣れればそれなりに効率よくなるのかもしれないが、効率よくやったところで本質的に無意味と思うとやる気が出ない。そのうえ、コピーライトの問題もある。素材をどう使っていいのかを把握して適用するのはそこそこの難度だ。というかそこまでして使いたいとも思わない。

noteはこの問題について、プラットフォーム内でアイキャッチ画像、noteで言うところの見出し画像として使える画像を共有するという機能をつけていた。これはけっこう便利だったのだが、いつのまにか勝手に見出し画像が消されている、みたいなこともあった。で、定期的に消えてないかチェックしましょう、みたいなことも言われていて、こうなると非常に億劫だ（参考: 自分の記事の見出し画像がいつの間にか消えていないかチェックしましょう！｜やらぽん☆のほほんゼミナール）。そんなこなんで、僕はnoteでも見出し画像を使わなくなった。

なんでこんなことが起きるかと言えば、自分のものではないからだ。これは本質で、素材サイトも同様だが、 「他人の作った画像を借りている」という問題が本質としてあるわけだ。これは「すべて自分でコントロールできる」感覚が重要な個人サイトにとっては、根本的なところでけっこう痛い。まぁ有料素材サイトから買えばその限りではなかろうが、いちいち買えんわい。

というわけで、どうせ作るなら内容に即したものを自作しないといけないな、とか思うわけだが、まぁこれは当然のことながらめんどくさい。このサイトにはガジェット系の記事も多いから、適当に写真とって文字入れするだけという雑なアイキャッチ画像も最近は作っていたけれど、あれでさえめんどくさい。まぁそのめんどくさいことを頑張ってやっている個人ブロガーも世の中にはたくさんいるので頭が下がるが、僕には無理ぽ。

AI画像が解決した「適当なアイキャッチ画像」

そんなわけでこのブログはいつまでも文字だけの世界だった。それを変えたのが最近流行の生成AIだ。

しかし、最初からうまくいったわけではない。生成AIでアイキャッチ画像を作れるんじゃないか？ということはだいぶ前から着目していて、Stable Diffusionを使って何枚かのアイキャッチ画像を作ったことはある。しかし、これも実はけっこう難易度が高かった。

記事のキーワードを拾う
プロンプトを考える
試行錯誤する

という一連の作業が必要なのだ。また、Stable Diffusion自体の学習コストもけっこう大きい。それで、 「どうせ手間かけるなら自分で素材作って適当に文字入れするほうがええわ」という結論になった。

しかし、最近ChatGPTがDALL-E3と連携するようになって、生成AIによるブログのアイキャッチ画像生成はついに実用レベルに達した。

記事内容をコピペするだけで、キーワードを拾ってプロンプト考えていい感じの画像を作ってくれる
コピーライトの問題を解決している

これは、ChatGPTが長い文章を入力できるようになったこと、DALL-E自体の品質が上がったことの相乗効果による。だいたい2-4枚つくれば、1枚くらいは「まぁいいか」と思える程度のものがある。まぁ、このラインは人によるだろう。僕なんかはアイキャッチ画像にはまるでこだわりがないため、「それなりに記事内容に沿っていればいい」程度だから、絵が破綻していなければよい。まぁ、時々難航する記事もある（商標が絡んだり、OpenAIの超厳しいコンテンツポリシーに引っかかったり）。

実際どんな感じのものができるの？ということこんな感じだ。

けっこう悪くないと思うが、どうだろうか。iPhoneでSuicaができるかもという記事の、スマホの中に電車があるアイキャッチ画像とか地味に名作だと思う。こんなん素材サイトに絶対ないし。一方で雑なイメージ画像もあるけれど、まぁこれはこれで。

などと書きながら、 「この記事のアイキャッチ画像はAI製じゃなくてスクショやん」という話なんだが、それはそのほうがわかりやすいと思ったからね。当然ながら、AIで作らないといけないわけじゃないのでな。なんだかんだでAIに作らせるのもそこそこの手間はあるので、スクショのほうが楽だから、スクショで十分ならスクショでやるわな。

他にどんな画像ができるのか知りたい人は、是非うちのトップページを見に行ってね。適当にリロードしたらランダムで出てくるよ。灰色のやつはまだこれからのやつだよ。

https://hack-le.com

記事内でサイトURL貼るの変な感じ。

ChatGPTへの頼み方

最後に、別にいらん気もするが、僕がアイキャッチ画像を作ってもらう時の頼み方を書いておこう。

以下のブログ記事のアイキャッチ画像を作成してください。商標を使わないようにしてください。アスペクト比はワイドで、高さが1024pixel、幅が1792pixelです。

以下ブログ記事
----

この下にブログ記事の本文をそのまま載せればOK。あと4つ作れと言ってるのに2つしか作ってくれないことが多い（最初の頃は4つ作ってくれていたのに……）。

ついでに、できあがる画像はpngでそこそこ容量でかいから、webpに変換するのがオススメ。ChatGPTにやらせてもいいけど、僕はここは自分でやってる。Macだったら右クリック拡張できるよ。やり方は以下のChatGPTに書かせた記事を参照。

【Macユーザー必見】右クリックから画像をwebpに瞬時に変換しよう！

いい時代になったよね。

追記: 日々ナーフされている

この記事を書いたのはたった2日前なのに、もうナーフされている。実はこの記事を書いた時点で、既にナーフされていたんだが、今はもっと酷い。1日単位で品質が下がっている。

具体的には、読み込みアイキャッチ画像を作らず翻訳する、プロンプトしか作らない、作り直しを要求すると一から指示を求める（前は「作り直して」と言えば文脈から的確に判断していた）、作り直しで横長などの要件を忘れやすい（以前もちょくちょくはあった）など、なかなか酷い。ってか一度に読み込みできるトークンの量また減ってない？🤔

ChatGPTに限らずだが、どうもAI系は昨日できたいたことが今日できないということが多発する。できるうちにやるほうがいい。

WordPressでGutenbergを使うようになった

Sun, 22 Oct 2023 14:50:47 +0900

僕はずっとクラシックエディタを愛用していた。普通に文章を書くだけならそのほうが使いやすかったからだ。クラシックエディタが使いやすいというより、Gutenbergが使いづらかったというほうが正確だろう。特に最初の頃、全文コピペすら手間がかかったのには閉口した。箇条書きのインデントの挙動もタブやShift + Tabで思ったように動いてくれず、あまりよくない（これは今もそう）。

Gutenbergを使い始めた

しかし、そんな僕も今はGutenbergをメインで使うようになっている。クラシックエディタは過去記事を編集する時くらいにしか使わない。その時には、クラシックエディタを不便に思うこともある。

いくつかのプラグインが、従来のクラシックエディタよりも使いやすいことがGutenbergを使うようになった大きな理由だ。特にMermaid記法を使えるようになるプラグインは有り難かった。また、このブログは比較的プログラミングのネタもちょくちょくあるから、コードのシンタックスハイライトがやりやすいことも助かっている。Gutenbergのプラグインを使えばビジュアルエディタのままシームレスに作業することができるのは楽だ。クラシックエディタの時はコード部分だけhtmlで記述するなど涙ぐましいことをしていた。ギャラリー機能なんかも、ちょっと画像をリッチに貼りたい時には便利なものだと思った。

ということで、僕程度のブログ書きでも、Gutenbergの機能はちゃんと使ってみるとけっこう便利なものが多い。確かにまぁ、単なるテキストだけで完結しないことも多くなったこの時代、ブロックエディタは必要な進化だったのかなと、ようやく僕も感じるようになった。

クラシックエディタのほうが今なお使いやすい面もある

しかしそうは言っても、ただテキストを書いて、いくつかの画像を添えるだけならば、今なおクラシックエディタのほうが使いやすいこともまた事実だ。だからこそ僕は長いことクラシックエディタを使い続けてきたのだし、今でもクラシックエディタを愛好している人がいることはとても理解できる。

Gutenberg、箇条書きの挙動はそろそろなんとかならんものだろうか。やはりShiftを押したときにはインデントをしてほしい。ネストが深くなった時にあれこれ編集していると、意図しない挙動になることもままある。箇条書きはテキストにおいてはもっともよく使う機能の一つなので、これはけっこうストレスフルだ。

あとあまり使っている人はいないかもしれないのだが、REST APIなんか使って編集しようとした時、Gutenbergは独自のタグが多すぎてとてもついていけない。まぁREST APIユーザはどちらかというとWordPressをバックエンドとして使う人のためのものかもしれないが……。

WordPressの開発はたいへんだろうが、クラシックエディタのほうが明確に良いと言えるユースケースが存在する以上、サポートはまだまだ続けざるを得ないのではないだろうか。

WordPressいいよね……

とは言うものの、基本的にはGutenbergで良いんじゃないの、と思う程度には、Gutenbergも熟れたように思う。あとはもうちょっとMarkdownっぽいコマンドがきくといいんだけどな。Notion並の操作感にならんかな。などと勝手なことを言っているが、WordPressにまったく金を出していない身なので、正直使えるだけでも有り難い。

WordPressの素晴らしいところは、多くのホスティングサービスが存在するところだ。昔は自分でサーバたててブログ運営するのも楽しかったが、今となってはひたすらめんどくさいだけなので、ホスティングサービスが多数存在し、切磋琢磨しているのはただただ有り難い。インストールも楽だ。

僕はカラフルボックスというサービスを使っているのだが、一つの契約に複数のWordPressをのっけることもできるので、だいぶお得だと思う。GUIでサクッと作ったり壊したりできるから、サイトのスクラップ&ビルドも手軽にできる。実際、運用するサイトの数を増やすことができたのはホスティングサービスのおかげだ。まぁ可用性については微妙なところもあるが、99.5-99.9%くらいは出せているようだ。ちょいちょい落ちるけど。とはいえ、自分でPHPとかDBのアップグレードする作業を思えば楽すぎてもう。証明書の更新失敗とかもないし。

これだけ使いやすい体系を世界的に構築したWordPressには、ただただ頭が下がる。WordPressは良いものだ。

広告を入れた

Sun, 16 Jul 2023 13:32:07 +0900

先月WordPressのテーマを変更してから、広告コードを入れていなかったために広告が一切表示されていない状態だった。快適であった。が、今日再び広告を挿入した。ひとまず配置を自動にしているため、ウザったいかもしれないが、というか既にうざったさを僕自身が感じているが、まぁ様子を見よう。

サイトの運営はサーバー代やソフトウェアの費用など物理的にコストのかかるのもので（このテーマも有料のものである）、趣味とはいえ、何かと不安定な昨今、少しでも足しになるなら入れたいなぁという気持ちがある。まぁでもそれ以上に、僕自身の心境の変化、みたいなことのほうが大きいかな。どうせ足しにならんし。

広告減らしていたが……

まぁ、本当に少額なので。このサイトは既にピークを超えていて、一番よかった時でも月に1万程度にしかならず、時給換算なんかしようものならブラックバイトも泡を吹いて卒倒するような数値だった。

今はさらに厳しく、Googleの個人サイト嫌気の流れからアクセスが落ち込み、また広告単価も下がったために、当時の1/10程度になり、「これだけユーザビリティを下げてこれかぁ」とゲンナリして、いつだったか、このサイトでは広告をかなり減らした。どうせ金にもならないんだったら、ユーザビリティをあげようと思ったわけだ。それによって収入はさらに減り、1/20程度になった。

あと他にも、何かと小うるさいGoogleのアドセンスポリシーに嫌気がさしたという面もある。大した金も出さない癖に、他人様が一生懸命作ったコンテンツに対してグチャグチャ言うんじゃあないよ……という気持ちにさせられた。これが月1万円でまだ伸びるかもしれないと思えた時代の時は、もうちょっと話を聞こうかなという気もしていたので、なるほど金払いというのは大事なものである。

そういう流れだから、テーマを刷新して広告コードが外れたのを機会に、広告そのものをなくしてもよさそうなものではあった。実際そうしようかとも少し思った。が、入れたのは、今までついでみたいにやってきた広告だが、もうちょっとちゃんと見てもいいかなと、そんな風にも思ったからだ。

対価について

僕自身の対価に対する考え方は、昔とだいぶ変わった。

最近つくづく思うのは、適切な金の流れを作ることがいかに難しいかということだ。その結果、本当に対価を払うべき人に払わず、むしろ払うべきではない人にばかり払っているような、そういう実感がある。たとえば、政治的な話となってしまうが、昨今話題の公金チューチューなどはまさしくその例だろう。我々納税者は、払うべきではない人たちに、まったく求めていないことへの謎の対価を強制的に払わされている。

その一方で、僕が普段愛用しているソフトウェアで、きちんと対価を支払えているものはどれくらいあるだろうかと思う。まぁ確かに寄付の受け口があったりはするのだが、ハードルが高いし、また貢献者全員に思ってしまうとけっこう膨大な数になり、さすがに……となってしまいがちだ。あと昔寄付したらずっとせびられるようになったWikipediaの件とかが個人的に枷になっていたりする。それだったら、最初から値札をつけてくれるほうがいいんじゃないかと、最近は思う。

また、対価の払い方は金だけではないとも思え、特に文化的な振興については、むしろ金以外のやりとりをいかにできるかにかかっているといえるだろう。承認欲求だなんだと色々と言われているSNS的ないいねも、感想やレビューも、立派な貢献行為だと思う。そういう対価の払い方もある。文化ではそれが重要だ。ブログもまた文化である。この無形の貢献は非常に尊いもので、在りし日の僕がそれを重視し過ぎてしまっていたことは、若気の至りというやつである。

有形の対価

しかし我々が現実にやりとりするのは金と呼ばれるもので、それは交換と貯蓄という両方の性質を兼ね備えている。それが重要で、交換もできなければ貯蓄もできない無形の貢献は確かに尊いものの、それだけでやっていけないこともまた現実だ。

だが、有形の対価の求め方は難しい。Webサイトの場合は、ビットコインだのドージコインだの、暗号通貨の投げ銭QRコードを置いてもいいが、置物にしかならないだろう。coinhive的なものは今にして思うと非常に大きな希望であったが、裁判で大きな味噌がついてしまった。最後まで戦われて逆転無罪を勝ち取られたデザイナーの方は本当に素晴らしいと思う一方、現実的には今なお怖さを感じる。

そう考えていくと、現実的に、Web広告はよくできた仕組みだなと思うし、Googleの真の革新性は、この広告をWebに馴染ませたことにあるのだろうとも思う。まぁ、色々思うところも確かにあるし、その歪みでWebは劣化したとすら思ってもいる。もっと他の何かも探すべきだし、Coinhiveは本当に可能性だったのにと思う。まぁ何を言ったところで、今日明日の現実世界においては、今なおWeb広告がWebサイトにとってもっとも有効な対価の獲得手段であるという事実を、認めないわけにはいかない。

そんなわけで、このサイトの記事に価値があるどうかは最終的に読み手の判断ということになるものの、自分としては一定程度の価値を信じて作っているので、Web広告の設置という形で、ひとまず僕なりの値札としたい。

AIによる記事専用の別館を作りました

Sat, 08 Jul 2023 13:28:25 +0900

こちらでございます。

https://ai.hack-le.com/

自分とChatGPT-4との対話を記事としてまとめさせたものです。それについて、自分の意図や、どういった質問をしたかについても掲載しています。

サイトの目的

このサイトの目的は3つあります。

備忘録と共有

まずは自分にとっての備忘録とその共有。ChatGPTに何度も同じことを聞いている自分を発見した今日このごろ、聞いた内容についてまとめておく必要があるように思われました。Notionでやってもいいのですが、せっかくなのでブログとして公開すれば、参考になる人もいるかな？と思いました。一応ChatGPT課金勢だしね。ChatGPT-4がどれくらいの仕事をするのかもよくわかろう。プラグインの威力も強力。

AIはどこまでブログを書けるのかの実験

次に、生成AIでどこまでブログ記事を書けるものなのか、という実験。既に生成AIによってゴミ記事が大量に生産されているとされる昨今、AIに適当に記事を書かせても、たしかにそれらしいものはできるのですが、基本的にそれらしいだけのゴミです。過去安金で雇われた人間が推定1文字0.1円で書いてきたいかがでしたかブログの記事を量産してきたわけですが、生成AIがもたらすのは結局ゴミ量産のコストダウンに過ぎないのだろうか。

いや、そんなことはないはずだ、と思うのです。むしろ、圧倒的な量とSEOだけで駆け上がってきたそういったクラウドソーシング系ゴミサイトに対して、知識と意欲をもった私人が対抗するための武器として使えるものだと思います。

ブログ記事というのは書くのに異常に時間がかかるし、テクニックも必要です。なので、できる人、やってくれる人は相当限られてしまいます。苦労の割に拡散もなく、Googleからは個人の仕事は軽視されるし（Googleは本当に反省してくれ）、報われづらい。だったらTwitterでいいよね、とできる人までSNSに行ってしまったなぁと思います。そういう人でも、AIが骨格を書いてくれるなら、またブログやろうかって人もいるんじゃないかと。

ただまぁ、いくつかやってみたところ、「内容的には悪くないのだが、根本的になにか足りない」という感じです。なんといいますか、見た目も味も悪くないのだけれど、まっっったく印象に残らない料理といいますか、食べたという実感すらわかないような、そういう感じなんですねぇ。

これは生成AIそのもののさらなる進化と、また私自身のAIを使役する力の向上が必要と思いますが、ただ、どうも、それ以前の根本的な問題を抱えているようにも思えます。これは一番の課題です。

テクニックの共有

まぁ今のところテクニックというほどのテクニックはないのですが、記事生成のために質問を重ねていくに連れて、ノウハウ・ハウツーといった知見が積まれていくものと思います。どういう質問をすればいいのか、どうまとめさせればいいのか。

私はすべての質問を掲載しますので、それなりに参考になるのではないかと思います。

このサイト（本館）の今後

ということで、わざわざAI記事専用の別館をつくったわけですが、本館にあたるこのブログは、今後も相変わらずな感じでやっていきます。人間100%の記事とAI記事の違いを味わってもらえればと思ったり思わなんだり。

まぁでも自分で言うのもなんですが、やっぱり人間が書いた記事のほうが面白いと思います。今のところ、AI記事にはまっっっっっったく負ける気がしません。時間さえくれたら、同じテーマでAIより12000%面白い記事書けると思います。

まぁその時間がかからないところが、AIのすごいところですし、ジャンルによっては今でもかなり活かせるんじゃないかとも思うんですね。そういうジャンルを探るのもまた、一つの目的です。こういうの、あれこれ考えるよりやったほうがいいですから。

そんなわけで、今後はAI別館もよろしくお願いします。いつか私のブログを全部読み込ませて、私が死んでも永遠にブログ記事書かせる狂気のサイトにします。

久しぶりのGutenberg

Wed, 05 Jul 2023 17:54:58 +0900

いくつかの機能を試すために、久しぶりにGutenbergを起動している。中途半端ではあるがMarkdownも使えるし。

コード

コードの入力がどれだけ楽にできるか。クラシックエディタだと直接htmlを書かざるを得ず苦痛ではあった。

import boto3

def main():
 pass

if __name__ == '__main__':
 main()

テーマ変えたからシンタックスハイライトはされない。確かCDNでなんか入れたんだよな……。もはやそれも面倒くさい……プラグインをそのうちなんか入れよう……。

Mermaid記法

今回Gutenbergを使い始めようと思った理由の一つで、プラグインを入れたらいい感じでMermaid記法のブロックが使えるからだ。

graph LR
test(hoge)
test2(hoge2)
test --> test2

なるほど🤔

まぁ書きやすいといえば書きやすいか。tabキーでフォーカス外れるのはつらいけど……。

数式

まぁ今となってはあまり使うことはないのだが……。MathJaxを使っていたのだが、コードをいじってヘッダに直接つっこんでいたため、テーマを切り替えたタイミングで見事に死んだ。

あわせて読みたい

WordPressの数式表現はMathJaxが一等便利

/wordpress-mathjax/

まぁもう一回コード差し込んでもいいんだけど、、、僕は気づいたんだ。コードの修正は忘れるけど、プラグインを入れたことは忘れないことに……。運用を考えた時、プラグインに頼るほうが楽。

ということでMathJax-LaTeXプラグインを入れさせていただきました。。。既存のコードについて、無事きれいに表示されたのを確認。

そんでショートコードのlatexで囲んだら、インラインで表示される。

[latex]ax^2 + bx + c = 0[/latex]

表示されている。またちゃんと数式使うような仕事をしたいもんだね……。

使えそう

いくつか気になる機能について試してみたが、特に問題なさそう。個人的にはMermaidをブロックで書けるのがけっこうキラーアプリだった。このサイトはテキストがメインだから、クラシックエディタのほうが使いやすかったんだけれど、図示したいことは多いからね。Gutenberg使っていくか……。

独自ドメインのWordPressを、カラフルボックスに移行して複数サイトを展開する

Sun, 25 Jun 2023 17:33:26 +0900

僕はもう疲れたんだよ。。。VPSでWordPressの運用なんて、もう面倒くさいだけなんだ。そこに喜びはもはやない。postfixで喜んでメールを送っていた僕はもういないんだ。

ということで、VPSから脱却すべく、もう数年ばかり続けていたブログを有名レンサバの一つであるカラフルボックスに移行する。カラフルボックスには既に別サイトを展開しているが、同じ契約に同居させる。

なお、今回のターゲットはこのブログではない。が、うまくいったらこのブログも移行するつもりだ。そしてVPSは解約する。。。

環境・前提

以下の環境が前提である。

既にカラフルボックスでサーバーを契約してサイトを構築している。このサイトがプライマリドメインであり、ドメインAとする
VPS上で別のサイトを構築している。VPSのサイトのドメインをドメインBとする
- ドメインBは外部で管理（今回はムームードメイン）
VPS上のドメインBサイトを、カラフルボックスのドメインAと同じ契約のサーバーに同居させる
移行ツールはUpdraftPlusのプラグインを利用する
ホストマシンはMac
- 動作確認するときに /etc/hosts をいじる。MacかLinuxだと話が早い。Windowsのやり方は公式ドキュメントでフォローされていたのでそれで

一つの契約を存分に使わせてもらう。僕は市井の小市民……。

ちなみにこの手順はある程度の時間、サイトの接続が不安定になるかもしれない。だいたい証明書のせい。おのれSSL。

プライマリドメインのゾーンからワイルドカードを削除する

プライマリドメインはここではドメインAにあたる。恐らくカラフルボックスのデフォルト設定だと思うのだが、その場合ワイルドカードですべてのサブドメインにAレコードが割り当てられている可能性がある。

通常はこれでも困らないのだが、別のドメインBも登録する時、困ることがある。これはサービスの制約のために、ドメインBがドメインAのサブドメインになってしまう。まぁ普通はサブドメインになにがあるかなんて気にされないしわからないものではあるが、やはり気持ち悪いので、ワイルドカードのレコードがあるかを確認して、削除しておく。

もしサブドメインで使っているものがある場合は、そのドメインだけは通してのを忘れずに。。。

カラフルボックスでゾーンを作成する

サーバを確認する
サーバはcPanelの「サーバー情報」から確認可能
DNSの管理
サービスから「新しいゾーンを追加」
ゾーン名は追加したいドメイン名
ここでレコードセットを選択するときに上で確認したサーバを選択する
一応中身を確認する。基本的に全サブドメインが当該ドメインに向かっているで問題ないはず

cPanelでドメインの追加とアプリのインストール

cPanelにログイン
ドメインの追加
追加したいドメイン名を入れる
ドキュメントルート共有しますかみたいなチェックボックスにチェックがデフォで入っているので外す
プライマリドメインにサブドメインが強制的に作られる（なので最初にワイルドカードのレコードを削除した）
当該ドメインでWordPressをインストール
ドキュメントルートのオプションだけ外す
管理者名とかパスワードは引き継ぐ

動作確認する

ここからがポイントだが、/etc/hostsでいったんローカルで名前解決して、移行と動作確認をしておく。

移行する

移行手順は方法による。今回移行先がレンサバなのでシェルスクリプトでDBダンプして……とかはできない。プラグインで頑張る。今回はUpdraftPlusを使う。

UpdaraftPlusの使い方は「WordPressをプラグイン「UpdraftPlus」で移行する方法 | 4thsight.xyz」を参照する（丸投げ）。

まぁでもだいたいわかるじゃない。。。一つ付け加えるなら、プラグインから順番に一つずつ復元したほうが安全かなと思う。

元々のサイトが画像多めとかだと移行たいへんかも。200MB超えるとちょっと警告出てたな。

もしドメイン名が変更されている場合、データベースの復元でちゃんとReplaceまでしてくれる。有能。

動作確認してOKだったら次。

NSを変える（ここで一時SSLエラーが出る）

このセクションを実行すると、恐らくサイトに一時接続できない、というよりSSLエラーが出るはず。というのも、SSL証明書が新サーバーで適用されてないからやね。これについては、後述するSSL証明書の発行をあらかじめしておいて、cPanelから手動で適用することにより、回避できるかなと思う。

ただ今回はカラフルボックスで使える無料の証明書を使いたかった。なので、先にNSの向け先を変えて、証明書を発行できるようにしたい（そうしないとエラー出るはず、、、）。

NSの向け先を変えるやり方はレジストラに則る。まぁでも有名所は公式にあるよ。

他社管理ドメインのネームサーバー変更方法 – ColorfulBox（カラフルボックス）サポートサイト

SSL証明書の発行

これができたら無事引っ越し完了となるはず。

cPanelからSSL/TLS Statusにアクセス
当該ドメインについて、エラー起きてるか自己証明になっているはず
チェックを入れてAutoSSLを実行する
うまくいったらAutoSSL Domain Validatedになります。うまくいかなかったらしばらく待ってもう一回実行する
ドメインの操作は変更が適用されるまでじっくり待とう。。。多分カラフルボックスの管理画面から見て、ゾーンが「保留中」になっている間はだめじゃないかな
自己署名を削除してから実行すると成功したりする

一通りのトラブルシューティングは公式ドキュメント参照「無料独自SSLにおいてSSL証明書が発行されない – ColorfulBox（カラフルボックス）サポートサイト」。

うまくいったらとりあえず引っ越し完了。元サイトはしばらく残しておいたほうが安全。お疲れ様でした。

参考リンク

カラフルボックスでサブドメイン追加して2つめのWordPressサイトを構築する

Sat, 24 Jun 2023 19:29:08 +0900

このブログはConoHaでVPSを借りてやっているのだが、別にレンサバのカラフルボックス（ColorfulBox）で運営しているものもある。昔はサーバ運営も趣味みたいなものだったが、今となっては面倒臭さが勝っており、PHPだのDBだのEOLが迫ってアップグレードせざるを得なくなるたびに憂鬱になる。昔は「ブログのネタが出来たぜ」くらいに思っていたけれど、もはやただただ面倒だ。正直このブログもレンサバに移設したい。これが歳か……。

だからというわけでもないが、カラフルボックスで複数のサイトを構築する練習。今回はドメインも含めてカラフルボックスで管理しているものとする。

環境

以下の環境を前提とする。

ドメインはカラフルボックスで管理している
カラフルボックスで管理しているドメインを使って、既にWordPressのサイトを構築している（ここではネイキッドドメインに割り当てている）
同じドメインにサブドメインを追加して、別のWordPressサイトを構築する

まぁ開発環境を構築したりサンドボックスを構築したり、色々用途はあるかなと思う。

サブドメインのレコードを確認

まず使いたいサブドメインでカラフルボックスのサーバに向くようにDNSの設定をする。カラフルボックス管理の初期設定だと、ワイルドカードでサブドメインは全部いけるようになっている。なのでこのままでもいいかもしれないのだが、後述のSSL証明書のために恐らく明示的にサブドメイン用のレコードを指定する必要があると思われる（少なくともプライマリドメインじゃないとそうだった。プライマリドメインではワイルドカードでも証明書ができるかもしれないのだが、僕の環境ではもはや確認できない…）。

カラフルボックスにログイン
タブのドメイン→DNSの管理
レコードを編集したい当該ドメインの書き込みアイコン（ゾーンの編集）をクリック
追加したいドメインが向くべきところに向いていることを確認する
具体的には、ネームが @ でタイプAでカラフルボックスの指定するIPアドレスに向いていること
サブドメイン部分を追加
Aレコードで追加するならネイキッドドメインと同じIPアドレス。CNAMEでも多分大丈夫

cPanelでドメインの設定

ドメインの設定ができていれば、次はサーバー側の設定なのでcPanelの設定をする。いつも「どこからログインするんだっけ？」と悩む。

タブのサービス→購入済みサーバー
当該のサーバーを選択
左側にある「cPanelにログイン」ボタンから遷移
機能リスト→真ん中らへんにある「ドメイン」
「新しいドメインを作成する」
サブドメインも含めて作成したいドメインを記入する、ドキュメントルートのところのチェックを外す
送信→ドメイン画面に戻る
Force HTTPS Redirectがオフの状態になっているがいったん放置（すぐはオンにできなかった）

WordPressのサイトを構築する

機能リスト→一番下のWordPressを選択する
「このアプリケーションをインストール」
ドメインの設定をさっき作ったサブドメインにする
ディレクトリは空白。なんもしていなければ、ドキュメントルートがサブドメイン作成したときのやつと同じになっているはず
管理者ユーザー名とかパスワードとか諸々適当に決めてインストール
ドメインのSSL/TLS Statusで証明書が発行されているか確認する。されていなかったらAutoSSLを手動で実行する
ドメインに戻って、Force HTTPS Redirectがオフになっているのでオンにする
なぜかネイキッドドメインのほうもオフになっているかもしれないがオンにする
サブドメインにアクセスして動作確認する

以上。

次は他所で管理しているドメインで同様にできるか試したい。ゾーンの追加と証明書周りがめんどくさそう。

ChatGPTに記事を書かせられるかやってみる

Mon, 17 Apr 2023 04:32:55 +0900

ChatGPTでブログの記事を書けるものなのかなぁと思って、一度やってみる。どういう元ネタからこの記事が出力されたかを踏まえて、これから先どうするかを考える。

ということでGo。

タイトル：ローカルAI時代への備え、グラボ選びの悩みとSSDの誘惑

こんにちは、皆さん！今回は、ローカルAIの時代に備えてグラフィックボード（グラボ）を新調しようと思った私の悩みと、その過程で気になったSSDの価格についてお話ししようと思います。

まず、ローカルAIの時代が近づいていることを考えると、どれくらいのスペックのグラボが必要になるのか悩みますよね。私もその一人です。高性能なRTX4090を手に入れたい気持ちはあるものの、そんなにお金持ちではないし、適当に高額なものを買うのも考え物です。

そこで、現状に合わせてRTX4070TiやRTX4080を検討してみたものの、将来的にはRAM20GB以上が必要になるような凄いグラボが出てきたら、それを買い換えるのも辛いですよね。そんなことを考えると、VRAMが24GBのRTX3090も選択肢に入ってくるわけです。

しかし、悩んでいるうちに、なぜかSSDが目に留まりました。最近のSSDは非常に安く、PCパーツが安くなっているのを見ると、なんだか心が癒やされます。例えば、Crucialの2TB NVMe SSDが15,800円とかになっているんです。安すぎて、つい買いたくなってしまいますよね。

しかし、冷静に考えると、Windowsのシステムドライブ換装はかなり面倒くさいです。それに、現状ストレージ不足でもないし、実際には必要ないという結論に至りました。そんなわけで、結局はSSDも買わず、何もしないままでいる私です。

皆さんも、ローカルAIの時代に備えたパーツ選びに悩むことがあるかもしれませんが、焦らず、じっくり考えて自分に合った選択をしていきましょう。それではまた次回！

面白くないｗ

まぁ仕方ないかもしれないんだが、全然面白くなくて草。最初のこんにちは！の謎のテンションよ。ちなみに元ネタは以下の文です。

以下の内容のブログの記事を書きたい。ドラフトを書いてほしい。

ローカルAIの時代に備えてグラボを新調しようと思ってみていた。でも現状だとどれくらいのスペックが必要になるかわからないので悩ましい。何も考えずにRTX4090を買えるほど金持ちではないし、そもそもそんな適当な金の使い方はしたくない。さりとて現状にあわせてRTX4070TiやRTX4080にして、その後にRAM20GB以上必要になるようなすごいやつが出てきてもつらい。そんなことを考えるとVRAMが24GBのRTX3090も選択肢に入ってくる。うーん、うーん、と悩んでいる間に、なぜかSSDが目に止まった。めちゃくちゃ高いグラボと違って今SSDは非常に安い。PCパーツが安くなっているのを見ると心が癒やされる。なんかもうCrucialの2TB NVMe SSDが15,800円とかになってる。安すぎ。こんなのもう買うしかない。と思ったのだけれど、Windowsのシステムドライブ換装は冷静に考えたらめっちゃ面倒くさい。別に今ストレージ不足でもなし。冷静に考えていらない。ということで断腸の思いで買わなかった。結局、何もしていない。満たされない。

まぁ僕も無茶振りだなぁ。全然整ってない、心情の吐露。まぁAIにはキツイな。

この元ネタの文章は僕が何も考えずにキーボードを打鍵した結果出てきた文字の羅列なんだが、もし僕がこれをブログ記事にするとしたら、太字にした部分をポイントとみなすだろう。

グラボを買うのに、適当な金の使い方をしたくない
PCパーツが安くなっているのを見ると癒やされる

ここに僕という人間の性根が現れている。AIは、適当に高額なものを買うのは考えもの、としているが、高額だからとかそういうことではない。僕はPCについてはそれなりにこだわりがあるので、こだわりがある以上、正しく価値を評価して金を使いたいのだ。金を使うとは評価すること。そして評価ほど難しいことはない。世の中の不幸はだいたい、金だけある阿呆が下手くそな金の使い方をするところに端がある（溜め込むよりマシ説はある）。だから僕は、拘りがあるPCの領域で、下手くそな金の使い方をしたくないんだ。

また、「PCパーツが安くなっているのを見ると癒やされる」をAIは「PCパーツが安くなっているのを見ると、なんだか心が癒やされます」とさらっと書いたが、ここはさらっと書かないでほしい。そんなことで心癒やされるのはおかしいのだから、ちゃんとその意図を汲んでくれ。

で、そこらへんと昨今のグラボ事情、SSD他PCパーツの価格事情を背景に、金の使い方と評価の話と無理やり繋げて適当にまとめてくれたら、だいたい僕が普段書くようなとりとめのない系雑文になる。

……というのをAIにやれというのは、非常によろしくないね。

情報と合理的な解釈

まぁ今回は完全に僕のテーマの与え方が悪かったなぁ。こういうエッセイチックなやつは、けっこう工夫しないとAIにさせるのは難しそうだ。

やはり、一般的な情報の集約と、そこから導き出される合理的な解釈のほうが向くだろう。LPWAとか、記事を書くほどには好きではない、でも情報量少ないから書いたら誰かの役に立つやろかくらいの、ニッチなテーマを選んでやるといいかもしれない。

ちょっと色々試してみよう。

2022年改正個人情報保護法でGoogle Analytics使うのに結局同意ポップアップはいるのかいらないのか

Thu, 21 Apr 2022 07:22:39 +0900

という長ったらしい記事タイトルになってしまったわけだけれど、2022年4月1日から施行された改正個人情報保護法でCookieの扱いが厳しくなったぞという話で、それに付随してCookie使っているGoogle Analyticsも厳しくなったんじゃないの、具体的にはあのウザったらしい同意ポップアップいるんじゃないの、という話。

結論を書くと、恐らく不要。ただ世界各国の流れや技術的な潮流を考えると、時間の問題かもしれないが、そもそもCookie自体使わない方向に行くかもしれない。

改正個人情報保護法で変わったこととその影響

そもそもこの改正個人情報保護法で何が変わったのかだが、平たくいうとCookieの情報を使うサービスでユーザの同意が義務付けられるパターンが明確化された、という感じ。

で、多くの個人ブログが影響受けるであろうところは、Cookieの情報をGoogle社に送りまくるGoogle Analyticsの利用で、これのために人類の生産性を落とすだけのあのウザったらしいポップアップの同意を導入しないといけないのかという問題が生じる。

本記事はその疑問についてあれこれ調べたものである。というか内容的には「改正個人情報保護法＞WebサイトにGoogleやFacebookのタグを埋め込んだだけでは個人関連情報の提供にはならないようです : プライバシーマーク・ISMSナビ」の記事のとおりで（この記事本当にありがとうありがとうという感じ）、もう少し自分なりに整理したものです。

個人情報保護法におけるCookieの扱い

まずそもそも個人情報保護法でCookieの扱いはどうなっているのか。

法令･ガイドライン等｜個人情報保護委員会

これの「個人情報の保護に関する法律についてのガイドライン」に関するQ&A とかいう長ったらしいPDF（HTML版が準備中だった）によると、以下である。

(個人関連情報) Q8-1 Cookie 等の端末識別子は個人関連情報に該当しますか。家族等で情報端末を共用している場合はどうですか。

A8-1 個別の事案ごとに判断することとなりますが、Cookie 等の端末識別子について、個人情報に該当しない場合には、通常、当該端末識別子に係る情報端末の利用者に関する情報として、「個人に関する情報」に該当し、個人関連情報に該当することとなると考えられます。また、家族等の特定少数の人が情報端末を共用している場合であっても、通常、情報端末の共用者各人との関係で、「個人に関する情報」に該当し、個人関連情報に該当することとなると考えられます。

なお、Cookie 等の端末識別子は、他の情報と容易に照合することにより特定の個人を識別することができる場合には、当該情報とあわせて全体として個人情報に該当することとなります。

要は個人を特定できる個人情報そのものズバリではないが、「個人関連情報」に該当する。個人関連情報ってなんぞというと、個人情報の保護に関する法律 | e-Gov法令検索の第2条7によると以下。

７　この法律において「個人関連情報」とは、生存する個人に関する情報であって、個人情報、仮名加工情報及び匿名加工情報のいずれにも該当しないものをいう。

まぁ特定に至らずとも、個人の情報には違いないよねって感じ。

個人関連情報の第三者提供について

さて、Cookieは個人関連情報だとして、それを第三者提供することについて、個人情報保護法ではどうなっているのか。これは第31条1項とその1号によると以下。

（個人関連情報の第三者提供の制限等）第三十一条　個人関連情報取扱事業者は、第三者が個人関連情報（個人関連情報データベース等を構成するものに限る。以下この章及び第六章において同じ。）を個人データとして取得することが想定されるときは、第二十七条第一項各号に掲げる場合を除くほか、次に掲げる事項について、あらかじめ個人情報保護委員会規則で定めるところにより確認することをしないで、当該個人関連情報を当該第三者に提供してはならない。一　当該第三者が個人関連情報取扱事業者から個人関連情報の提供を受けて本人が識別される個人データとして取得することを認める旨の当該本人の同意が得られていること。

重要部分を太字にしました。この「本人の同意が得られていること」が今回の改正の影響があったところで、これを素直に読むと「本人の同意必須やん、え、同意ってどうやんの、やっぱりあのブルシットポップアップなの」とか思うわけだが、これについて、ガイドラインによると以下のような記述がある。

(法第 31 条の適用の有無について) Q8-10 A 社が自社のウェブサイトに B 社のタグを設置し、B 社が当該タグを通じて A 社ウェブサイトを閲覧したユーザーの閲覧履歴を取得している場合、A 社は B 社にユーザーの閲覧履歴を提供したことになりますか。

A8-10 個別の事案ごとに判断することとなりますが、A 社が B 社のタグにより収集される閲覧履歴を取り扱っていないのであれば、A 社が B 社に閲覧履歴を「提供」したことにはならず、B 社が直接にユーザーから閲覧履歴を取得したこととなると考えられます。このため、B 社がそのタグを通じて閲覧履歴を取得することについて、法第 31 条第1項は適用されないと考えられます。なお、個人情報取扱事業者である B 社は、閲覧履歴を個人情報として取得する場合には、偽りその他不正の手段によりこれを取得してはならず(法第 20 条第1項)、また、個人情報の利用目的を通知又は公表する必要があります(法第 21 条第1項)。

重要部分は太字にしました。

これはまさにGoogle Analyticsのユースケースがズバリなのだが、そもそも「第三者への提供にあたらない」という解釈である。もっとも、「閲覧履歴を取り扱っていないのであれば」という但し書きのところが微妙なのだが、これは閲覧履歴を使ってサイトの広告に反映するぞとかそういうことを言っているのだと思われる。パーソナライズ的なことしてないよね、って感じ。

あの長江より長いQ&Aからこの情報を見つけてきて記事にしてくれたブログ「改正個人情報保護法＞WebサイトにGoogleやFacebookのタグを埋め込んだだけでは個人関連情報の提供にはならないようです : プライバシーマーク・ISMSナビ」には感謝しかない。保護法があってガイドラインがあってガイドラインのQ&Aがあるってもう嫌がらせだよ😭

まとめ

2022年4月1日の改正個人情報保護法により、Cookieは個人関連情報とされ、個人関連情報を第三者に提供するには「本人の同意」が必要とされた（第31条1項1号）
Google AnalyticsはCookieを使うが、そもそも「提供」とみなされない（ガイドラインQ&A 8-10）
よって、改正個人情報保護法ではGAの利用でポップアップのあれは不要

とはいえ、世界的にもCookieを排する流れであることは変わらないし、そのうちになんか対応しないといけないのかなぁとかは思っている。

正直そんな悪者にするようなもんじゃないと思うんだけどなぁ、Cookie。

趣味の継続は困難かつ必要なもの

Sun, 06 Feb 2022 17:30:52 +0900

僕にしてはよく続いたと思うが、やはり継続的なブログ更新ほど難しいものはない、ということを再確認した。例によって、早速更新が滞っているからだ。

やめたらいいじゃないか、なんの役に立つんだという気持ちが芽生えてくる一方、僕が一番続いてる趣味らしい趣味だということを鑑みて、もうちょっと粘ろうかな、という気もしている。多分もうちょっと粘る。

趣味の継続は難しい

ブログの継続的な……ここでいう継続的とは毎日を表す……更新が難しいのは、書くことがないから……ではなく、その逆で、日々色々なことが起きるからである。

色々なことと言うのは、何もビッグイベントに限らない。「今日は少し頭が痛い」「寝不足だ」「昨日飲みすぎた」「残業時間が長かった」「どうも気分がのらない」「新しいゲームをやり始めたらついやり続けてしまった」そんなレベルの話である。

そういうなんてことのない何かを掬い上げて記事にするのがブログというものだから、常に書くべき色々なことは存在する。そしてそれは、書く理由になると同時に、書かない理由にもなる。

理由は簡単である。疲れるからだ。これが仕事ならばもちろんその程度の障害でできなくなるなんてことはまずないが、しかしブログの執筆というのは趣味である。おおよそ人類の何にも貢献しなければ、当の自分にとっても必ずしも役に立つこともない。ま、趣味というのはそういうものだ。

そういうわけだから、日々生きるため、仕事や家事に忙殺されている身の上では、趣味というのは真っ先にリストラの対象となり、結果、趣味の継続とは非常に難しい。

しかし、僕にとって生きる糧になるのがこの趣味であることもまた事実である。仕事や家事ばかりでは、心が疲弊する。なにより、世界が狭くなる。これは、絶対にそうなる。

仕事と趣味は必ずずれる

世の中には仕事が趣味だと豪語する人が多くいることは承知している。実際、経営者にプライベートなどあってないようなものかもしれないし、そうでなくても、技術者など専門職では、趣味と仕事の境目が曖昧になることは事実だ。

しかしそれは結果論であって、そもそも趣味とは仕事に活かそうとしてすることではない。結果的に仕事に役立つことがあっても、それを目的にはしていない。

仕事と趣味は、本来的に別ベクトルのものである。したがって、たとえ重なることがあったとしても、進めていけば自ずとずれ始める。つまり、仕事が趣味という状態は起こり得ないことではないが、それはいっときの偶然に過ぎない。なので、「仕事が趣味みたいなもんでね」と10年言い続けたなら、それは無趣味を言い換えただけである。

アクセルとブレーキ

これはつまり、仕事とはなにか、趣味とはなにか、という話なのであろう。色々な定義の仕方があり、その定義の仕方に当人の人生観が如実に現れる。しかし一つ言えることは、両者は違う、ということだ。そして恐らく、その向きは反対である。

アクセルとブレーキがあって始めて車は車足り得る。仕事と趣味のどちらがアクセルだとかそんな話をする気はない。ただ、逆の性質をもった2つの機能をあわせて、始めて長く安全な運転はできるのだと思う。

だから僕は今、こうして意味もなく、なんの役にも立たない記事を書いている。そして多分、必要なことだと、感じている。

Google先生に見捨てられた個人ブログがこの先生きのこるには

Tue, 18 May 2021 06:25:32 +0900

今どきブログをやっている人もすっかり珍しくなってしまった。まぁそれはそうで、かつてと違って今からブログを始めるのは非常に厳しい。このブログを始めたのは2012年。今にして思うと、個人がブログをしてそこそこの集客をできる最後の時期だったのかもしれない、と最近思う。

今は違う。個人ブログは、もはや検索で引っかからない。まったく引っかからないわけではないんだが、あらゆる企業やアフィリエイターの作った、しょうもないサイト（失礼！）に押しのけられている。

（もし今からブログを始めようという人がいるなら、技術系ならQiita、それ以外ならnoteに投稿するのが実質的。悪くないプラットフォームだと思う。この記事の趣旨ではないので、これ以上は言及しない）

時代は変わった。ブログ文化は検索エンジンと共に成長したが、今や検索エンジンは個人ブログを必要としてない。であれば、個人ブログも変わらないといけない。

ブログは検索エンジンを前提にした文化

これは僕が勝手に言っていることなので、一般的に言われていることではない、と前置きしたうえで言うと、ブログは検索エンジンからの流入を第一にしている。というより、Google検索と一緒に成長した、というほうが良いだろうか。ブログ自体は、90年代からあったようだし。

ただ、今のブログの形は、やはりGoogle検索とセットで出来上がったものだと思う。もちろん、TwitterやFacebook、Instagramなど他のSNSからの流入を見込んだブログも多いんだけれど、それはいわゆるインフルエンサー、あるいはそこまで言わずともそれに近い人たちができることで、無名の多くの一般ピーポーにとっては、やはり検索エンジンが第一の玄関口となる。

実際、00年代のブログはめちゃくちゃSEOに強くて、そのために中身のある個人サイトを押しのけてしょうもない記事が引っかかるようになった、なんてこともあったから（歴史は繰り返す？）、けっこうヘイトも買っていたように思う。

あれ、もしかして個人サイトといっても、今となっては通じない人のほうが多いのか？シュタインズ・ゲートのサイトが当時の雰囲気を再現してくれているので、参考に貼っておこう。

未来ガジェット研究所

これ作ったのオカリンの設定なんだろうか。タイトルが「無題ドキュメント」と当時を知る人ならふふっとなるユーモアを利かせてくれているが、もしダルが作っていたらここはちゃんとする気がする。役割的には広報と考えて、オカリンが作ったのかなぁ。少なくとも文章はオカリンのテイストだね。

閑話休題。

まぁとにかく、00年代の中頃か、あるいは後半くらいからかな、ブログはインターネットを席巻したと言ってもいい。で、ブログは個人でも始めやすい……というかむしろ、個人がやるものだった。企業が表立ってやるには、まだちょっと胡散臭さがあった。

Googleが神だった時代

僕がブログを始めたのは2012年で、ブームには乗り遅れたものの、まだまだ個人ブログもいけた。いわゆる２ちゃんまとめブログみたいなのがまだまだ強かった頃だね。記事をちゃんと書いて半年も経てば、そのうちにきっとGoogle先生が評価してくれて、人が増えるはずだと、そう信じられていたし、実際、そうだった。

そうなんだよねぇ。まぁ評価がどれだけ適切だったかは難しいけれど、まぁそれなりに納得できるというか、こんなもんかなぁ、と思わせるものがあった。この感覚は、だいたい10年代半ばくらいまであったな。ま、これは記憶だけれど。

僕がブログを始めた10年代前半にはもう、最近のGoogle検索おかしくない？っていう意見はあったけれど、基本的にはPVが少ないのはお前の記事が悪いからだ説のほうが幅を利かせていたと思う。

少なくとも、良い記事さえ書けばきっとGoogleに評価してもらえると信じられていた時期は、たしかにあった。それがいつまでなのかは、わからないけれど。

それはつまりどういうことかっていうと、ブログの記事ってのは、Google検索に合わせて進化していった、とも言えるんだな。なにしろGoogleこそ信じられる神なんだから。神の意向に添うのが正義だ。

たとえばだ。よく言われるように、ブログには一覧性がない。どんなコンテンツがあるのかよくわかりづらい。これは特に、従来の個人サイトに慣れていた人間からすると、ブログの明確な欠点に見える。

でも、それがどうした？あんたが探しているものは、Googleの検索窓に打ち込めば出てくるはずだ。もしうちのブログで用意できていれば、Google先生が出してくれる。もし出してくれないなら、きっとうちよりいいやつを、別の誰かが用意してくれているんだ。うちとしては残念だが、あんたにとっては、そのほうがいいだろう？

だからブロガーは、ただ良い記事を書けばいい。そうすれば、Googleが拾ってくれる。良い記事とは、情報のまとまった記事だ。構造的に書け。読者の求めるものを書け。コンテンツファーストだ。サイドバーはノイズだ。読者を記事に集中させろ。

その結果、資金にものを言わせて薄っぺらく情報をまとめただけの無意味なサイトが、個人の深い考察を押しやった。また、情報の真贋まではGoogleにはわからないので、嘘・大袈裟・紛らわしいだけのPV狙いサイトで溢れた。

個人はGoogleに見限られた

誰がどう見ても、おかしな状態だった。日本ではWELQ問題も起きた。

Googleは対策を重ねた。その中で、個人というものを信用しないようになったのだと思う。なんでやねん、と個人的に思うが、仕方ない。

検索結果を見てくれ、今や企業が作った無数のいかがでしたかブログと、どこぞのメディアの記事、企業の公式PRページで埋め尽くされているだろう。そうなってしまったんだ。

昔からあるサイトならともかく、今から一個人がブログをやるには、たいへん厳しい時代となった。Google検索と共にあった個人ブログは、梯子を外されたんだ。もう、Googleは頼れない。

これからの個人ブログ、いや、個人サイト

それでも僕はブログが好きだし、続けていきたいと思っている。ただ、20年代に個人がやる以上、今のままではいられないよなぁ、とは思う。

最近なんとなく思い出しているのが、かつてブログが駆逐した、個人サイトである。さすがに今更ホームページ・ビルダーもサイドフレームもないものだが、ツールはともかく、思想的なところで、個人サイトには今の個人ブログに必要なものがあったように思えてならない。

それが何なのか。抽象的なところでは表現する言葉をまだ持たないのだが、具体的なところで言うと、 「コンテンツを自分の手で並べること」ではないだろうか。

それはもはやブログの形式ではないが、思うに、ブログ自体が本来は一コンテンツに過ぎないはずだったのではないか。ただ、Google検索が優秀だった時代は、Googleが代わりにコンテンツを並べてくれた。それが個人にとっても信じられた。だから、「コンテンツを並べる」という面倒な作業は忌避された。

それはもうかなわない。でも、考えてみれば、個人がただ記事を書くだけで皆に読まれるなんて、00-10年代が奇跡の時代だったのだと思う。まぁでも、プラットフォームはGoogleだけじゃない。SNSもある。友達に教えるのだって、立派な広報だ。

すべてをコンテンツとして内包し、並べられたもの。それは個人サイトなのかどうか。よくわからない。ただ、そういう風に、やってみてもいいのかもしれない。そんなことを思っている。

ブログを続ける理由

Sat, 12 Dec 2020 17:07:30 +0900

知らなかった。このブログを始めたのが2012年の10月なので、実に8年以上ブログを続けているのだが、クロス投稿という概念を初めて知った。仮にも技術ネタ多めで、恐らく傍からは技術系のブログと目されているのではないかと思うのだが、そんなことも知らなかったのである。やはり僕は阿呆。

クロス投稿なるもの

クロス投稿というのは、オリジナル記事は別にあることを明示したうえで、他所様のプラットフォームに投稿する行為らしい。つまり、これを使えば自ブログの記事を別所に掲載することができる。

そんなことができるとは知らなかった。僕がQiitaに記事を投稿しないのは、「いや、この記事は俺のだから」という意識があるからなんだが、クロス投稿が許可されているプラットフォームであれば、投稿してもいいなと思える。

というか、投稿させてほしい。

個人サイト冬の時代

ブログに限らず、個人サイトに冬の時代が来て久しい。サイト制作に時間がかかるというのはもちろんそうなのだが、それ以上に、検索流入が見込めなくなった。Google先生は謎の個人の与太話には耳を貸さず、「調べてみました！わかりませんでした！いかがでしたでしょうか？」というまとめサイトを客観的で信頼性があると考えてしまった。

本当に知りたいことはいつだって言葉の外にあるんだが、機械はどこまでいっても字面を解析することしかできないので、そうなるのも仕方ないのかもしれない。というより、そんなGoogleの好みに合わせて爆誕したのが、いかがでしたかブログである。阿呆らしい。

そんな阿呆な記事に追いやられて、多くの有益な個人サイトが、ただでさえ目立たなかったのに、今やネットの片隅にすら置かれなくなってしまった印象だ。もちろん僕のサイトも例外ではなく、もうずっとサイト来訪者は減るばかりだ。

人に見られるためではないが

別に人に見られるために記事を書いているわけではない。だからこそ、このブログも8年以上続いている。これは個人サイトをやったことがある人ならわかってもらえると思うが、誰かのためにとか、誰かに見せるためにサイトをやっていると、なかなかどうして続かない。

ブログ指南みたいな記事ではよく「他人に見られることを意識して」と書かれているが、実際のところ「他人の目なんか気にせずに」書くほうが長く続く。僕は僕のためにブログを書いているので、続けることができているのだ。

しかしそうすると、検索流入の話など出てくるのはおかしいことにも思える。誰かに見られることを気にしないなら、どうでもいい話じゃないか。

それはまったくもってそのとおりなのだが、ここがサイト運営の微妙なところで、そもそも本当に他人に見られなくていいのであれば、わざわざインターネットに公開する必要なぞないわけだ。なぜ公開するのかといえば、それはやはり誰かに見てもらいたいという気持ちがあるからだ。

利他的で自己的な欲求

その気持ちの源泉はなんだろうか。斜に構えた人は「自己顕示欲」「承認欲求」と切り捨てるかもしれない。

もちろんそれは違う。ブログなんかやっても、自己顕示欲も承認欲求も満たされない。むしろいかに自分がちっぽけな一個人に過ぎないのかを痛感させられるばかりだ。まだしもTwitterのほうがマシだろう（Twitterでもある程度大御所にでもならない限り満たされることはないと思うし、なったところでクソリプで絡まれる面倒臭さのほうが大きいと思うが…）。

じゃあなぜ公開するのかと言うと、この知識を、この知見を、役立ててほしいという利他的な精神と、あるいはこの感情を共有したい、たとえ理解されないとしても、という自己的な欲求がないまぜになって、延々と見られるかどうかもわからない長文を公開し続けているのだと思う。

人の感性が情報を意味に変える

個人的に重要だと思うのは、客観的な情報の中に込められた、主観的な感情・感性の発露である。書き手の想いが、無味無臭で色もない情報に、彩りと強い印象をもたせ、情報が単なる知識を超えた「意味」になると思う。それは、受け取り手の人生観・世界観によっても大きく変わる。実に面白い。

が、少なくとも現状、それは人間だからできることらしいと、Googleの検索結果を見ると考えざるを得ない。今や検索結果は、感性を排除した、そのようにしか受け取ることしかできない単なる情報の羅列、しかも同じ情報や無意味な伝聞で溢れている。そしてチェーン店しかない大通りのようになってしまい、だだっ広い割にどこまでいっても同じ場所のような、一様な印象しか残らなくなってしまったわけだ。

クロス投稿してみた

現実には、今この瞬間もどこかに本物の人の声は発せられているのだが、それを捉える手段として検索エンジンがポンコツになってしまっている以上、発信者も受信者も、なにかしら手段を考えないといけない。

今世にある各種プラットフォームは、そうした需要の一部を汲んでいる面があると思う。Googleに切り捨てられた個人の感性はTwitterに拾い上げられ、信頼性のない個と切り捨てられた名もなき技術者の足跡はQiitaに拾われた。もっとも、いつだって本当に面白いものは、誰にも掬われていない隙間にあると思うと僕は思うが、まぁそれはいい。自分にとって面白いものは、だいたい他者にとってゴミである。

そんなわけで、僕としてもいい加減独自ドメインに展開する孤島に引きこもるのではなく、なにかしら余所の場にも情報を出さないとなぁ、と数年ばかり思っていたものの、やはり自分のブログというのは可愛くて、なぜ俺の記事を余所に提供しなきゃいけないんだ、というみみっちい気持ちが邪魔していた。

が、クロス投稿という形ならば、まぁやってみてもいいなぁ、という風に思える。クロス投稿ならば、あくまで主権は僕にあると考えられるからだ。

ということで、早速「Crieit - プログラマー、クリエイターが何でも気軽に書けるコミュニティ」に実験投稿してみたりなんだりしている。Mediumじゃないのが自分で言うのもなんだけど僕っぽい。

続けるかどうかはわからないけれど、まぁしばらくやってみようと思う。

WordPressのためにPHPのバージョンを 7.1 -> 7.4 に上げる(CentOS 7, nginx)

Sun, 14 Jun 2020 17:43:36 +0900

当サイトはCentOS 7系のサーバー上のWordPressで動いている。で、「PHPのバージョンが古い」と怒られた。最後にPHPのバージョンを更新したのは「WordPress高速化のためCentOS 7でPHPを5.4->7.1にアップデート(on ConoHaのVPS) – 或る阿呆の記」で3年ほど前のことだ。

ああ、そろそろ更新しないといけないか……と、重い腰を上げて更新することにした。

環境

ConoHaのVPS
CentOS Linux release 7.8.2003 (Core)
nginx version: nginx/1.16.1
PHP 7.1.4 (cli) (built: Apr 11 2017 19:36:58) ( NTS )
MariaDB 5.5.65
WordPress 5.4.2-ja

なんていうか、そろそろ色々バージョンアップしたい。

やること

基本的には前回のアップグレード時の記事「WordPress高速化のためCentOS 7でPHPを5.4->7.1にアップデート(on ConoHaのVPS) – 或る阿呆の記」と同じ流れ。なんでも記事は残しておくものだ。既にRemiを導入している点が異なる。

（既に導入済みなので本記事では省略）Remiの導入
WordPress関連サービスの停止
現行のPHPの削除
PHP7のインストール
WordPress関連サービスの起動

# 関連サービスの停止
sudo systemctl stop mariadb.service
sudo systemctl stop php-fpm.service
sudo systemctl stop nginx.service

# 現在のPHPを削除
sudo yum remove php*

# PHP7をインストール
sudo yum install --enablerepo=remi,remi-php74 php php-mbstring php-gd php-mysql php-pspell php-xml php-xmlrpc php-fpm

# PHPのバージョン確認
php --version

# PHP-FPMの再設定(nginx)
sudo sed -i "s/user = apache/user = nginx/" /etc/php-fpm.d/www.conf
sudo sed -i "s/group = apache/group = nginx/" /etc/php-fpm.d/www.conf

# 関連サービスの起動と有効化
sudo systemctl start nginx.service
sudo systemctl start php-fpm.service
sudo systemctl start mariadb.service
sudo systemctl enable php-fpm.service

やった

実行した。

$ php --version
PHP 7.4.7 (cli) (built: Jun 9 2020 10:57:17) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies

WordPressも問題なく動いている。人が少ない時を見計らったし、時間にして1分もかからなかったので、影響を受けた人はいないと思うが、どうかな。

そろそろブログをコンテナ化しようかなと思う今日この頃。

アイキャッチ画像(featured image)を観念して作ることにした

Wed, 30 Oct 2019 00:13:08 +0900

ブログでは普通アイキャッチ画像というものが用意されている。何かと言えば、よく見かけるものだと記事冒頭にある画像で、その場合は読者のファーストビューとなる。

僕はこれがあまり好きではなく、また面倒でもあったので、アイキャッチ画像は導入してこないでいたのだけれど、まぁ機能的にあったほうがよい場面もちょくちょく出てきたし、実は別にアイキャッチさせる必要もなかった、ということで、観念して作ることにした。

アイキャッチ画像は必要か

アイキャッチ画像というのは、ブログやらなんやらで記事内に最初に表示される画像で、ユーザーにとってはファーストビューになる。よいアイキャッチ画像を入れるのはブログにおいてはアクセスアップのための必須のテクニック、なんて言われることもあるが、元々文字情報に重きを置く僕にとって、アイキャッチ画像なんてのはスクロールの手間を増やすだけの無用の長物でしかなかった。今でも必須のものではないと思っている。

まぁいわゆるアフィブログなんて呼ばれるところで量産されるコピペ記事やいかかでしたかブログなんて揶揄されるネット上のアレな記事たちが、無意味としか思えない適当感溢れるアイキャッチ画像を用いていたことも、僕にアイキャッチ画像に対する悪印象を与えていたかもしれない。昔こんな記事「適当なアイキャッチ画像なら無いほうが良い – 或る阿呆の記」を書いていました。

とはいえ、記事のイメージ画像というのがあったほうが、人目につきやすいことは事実である。特にSNSになんかでは画像の有無で拡散するしないは大いに影響するところだろう（まーこのサイトではそんな心配こそ無用の長物というべきものだが）。

で、OGP(Open Graph Protocl) なんて規格もあるわけで、となると、このサイトは一応技術系の話題が多いブログであるし、いまだにOGPの設定をしていないのもなぁと思うにつけ、アイキャッチ画像がないのもなぁ……とか、Googleさんからも少なくとも一つの画像を推奨されているとか、Googleさんが作ってくれる関連記事にも画像が使われるしとか、機能的な面でもアイキャッチ画像はあったほうがよいのかなぁ、なんて最近思うようになってきた。

まぁそれでもやっぱり記事冒頭にいちいち画像があるのはウザいと思えば、非表示にしたらよいのである。それだとアイキャッチじゃないやんという話だが、どうやらアイキャッチ画像というのは日本での呼び名であるらしく、WordPressではfeatured imageと呼ばれており、別に必ずしも記事冒頭でアイキャッチする必要はないわけだ。

ということで、もう2020年も近づいてるしな……なんて思いつつ、重い腰を上げて今更ながらアイキャッチ画像ことfuatured imageを作るようにするかなー、なんて思った次第である。とはいえ適当にやっても仕方ないので、あれこれ調べて、自分なりに納得のいくようにやることにする。

画像のサイズはどうするか

まず画像の解像度をどうすればよいのかだが、メディアによって推奨するサイズがバラバラで困る。とりあえずいくつかまとめると下記のような感じ。

メディア	解像度	アスペクト比
Facebook	1200x630	1.91 : 1
Twitter		1.91 : 1
AMP	1200x675	16 : 9 (1.78 : 1)
Googleの関連項目	画面サイズによる	1.91 : 1

Googleの関連項目は実際にChromeのデバッグツールでPC版とスマホ版の時の画像サイズを直接調べた。解像度自体は画面サイズによって異なるようだが、アスペクト比は概ね1.91:1くらいになる模様。もっとも、ここで確実にアイキャッチ画像が使われるのかどうかは知らない。

Facebookが推奨する1200x630と近いアスペクト比ということで、やはりこの比率がデファクトスタンダードなのだろうか。

だが、AMPはいわゆるフルHDのサイズを推奨しているようで厄介だ。Google検索にも関わってくるだろうし、WordPressからも警告されるし。

前述のようにWPではeye catch imageではなくfeatured imageとよばれる

まぁでも、フルHDに合わせておけば、1.91:1で表示される時には上下が少しクロップされるだけだろう。Twitter Summary Cardとか、なんだかんだで正方形にクロップされることもあるしなぁ。

以上を踏まえると、1200x675など16:9で作っておいて、真ん中らへんに見切れたら困る部分をおいて、上下には気持ち余裕をもたせれば、いい感じになるのかな、と思う。別に1920x1080でもいいと思う。テレホタイム時代じゃあるまいし、画像サイズがネックになることもいまさらそんなに……まぁ都内の昼間にスマホでアクセスしたらあれかもだけど、このサイトは昼間にPCで来る人が多いしなぁ（まぁそれを言い始めたらそもそもSNSで共有されているわけでもないんだが）。

作ってみる

作ることに決めたなら、後は習うより慣れよというやつで、とにかく作っていくしかない。僕の美術センスのなさを炸裂させる日がついにきたわけだ。

というわけで、超有名なフリー素材サイトのいらすとやから適当なイラストを拝借しつつ、適当に文字入れするという、極めて適当な制作をしているが、まぁやっているうちに少しずつレベルアップするんじゃないだろうか。しないかな。しないかもしれん。

参考サイト

WordPressでナビゲーションメニューからランダムな記事に飛ばす固定ページを作る

Fri, 27 Sep 2019 20:50:11 +0900

なんか変なタイトルになったけれど、やりたいことは、WordPressのナビゲーションバーから「ランダム」みたいな項目を作って、それをクリックするとランダムな投稿記事に遷移させたい、ということです。

方法として、開いた瞬間にランダムなページにリダイレクトする固定ページを作って、その固定ページをナビゲーションメニューに表示させる感じ。ちなみにこのサイトでは実装していない（そんな需要ないと思うし）。

環境

WordPress 5.2.3
nginx 1.12.2
php 7.1.4

やりたいこと

WordPressのナビゲーションメニューに「ランダム」みたいなメニュー項目を作って、そいつをクリックしたら何かのランダムな投稿記事に飛ばしたい。

やり方

いろいろなやり方があると思うのだけれど、多分楽なのは強制的にリダイレクトする固定ページを作って、それをメニューに表示させることかな、と思う。ので、その方向で実装を考える。

リダイレクトにはhtmlやJavaScriptを使ったクライアント側の方法と、phpを使うやり方、あるいはWordPressで用意された関数を使うサーバーサイド側やり方がある。DBにアクセスして、その情報を使うことを考えると、サーバーサイド側で対応したほうが楽だろう。で、WordPressに用意された関数があるのであれば、生のphpを使ってリダイレクトするよりもよいと思われる。わざわざそれ用の関数を作っているということは、裏でいろいろな処理が必要かもしれないので。

で、調べてみるとwp_redirect() なる関数があるので、まぁこれを使うのがよいだろうな、と。関数リファレンス/wp redirect - WordPress Codex 日本語版によれば、リダイレクト先の絶対パスがわかればよいらしい。

ということで、次の問題はランダムな記事のURLをいかにして引っ張ってくるか、である。ランダムな記事、みたいなワードで調べると、やたらWP_Query()を使った記事が出るのだが、コードを見るとどうも嫌な感じがする。影響大きくない？リファレンス（関数リファレンス/WP Query - WordPress Codex 日本語版）を見ても

ほとんどの場合、クラスの内部やグローバル変数を使わなくても欲しい情報は手に入れられるでしょう。どこからでも欲しい情報を手に入れるために、とてもたくさんの関数があるのですから。

— 関数リファレンス/WP Query - WordPress Codex 日本語版

とあり、どうも基本的には推奨されない関数に思える。少なくとも、適当な記事のURLがほしいだけの目的にはそぐわなさそうだ。

色々調べた結果、get_posts()でランダムな1記事をゲットして、その情報を取得するのが簡便に思えた。まぁ正直もっとよい解法があるような気もする。get_post()でランダム指定できれば楽だがそういうわけにもいかないようだ。

とにかく、これでリダイレクトはできるとして、どのファイルにコードを記述したらよいか、だが、固定ページなのでpage.phpに記述すればよい。その中で、is_page(slug)で条件分岐してやれば、任意のslugの固定ページでのみリダイレクトさせることができる。注意点として、page.phpの最初に記述してやることだ。でないと、表示がうまくいかない。内部の動きはよくわからないが、wp_redirect()は単にページ遷移しているだけではないらしい。

ソースコード

これまでのことをまとめて、コードを書いていく。

まず空の固定ページを作る。ここで、固定ページのスラッグを’random’とするが、別になんでもよい。is_page()で指定できればなんでもよい。で、作ったらpage.phpの頭に以下のようなコードを書く。

<?php
	if (is_page('random')) {
		$args = array(
			'posts_per_page' => 1,
			'orderby' => 'rand',
			'post_type' => 'post',
			'post_status' => 'publish',
			'suppress_filters' => true 
		);		
		$rand_post = get_posts($args)[0];
		$location = get_permalink($rand_post);
		wp_redirect($location);
		exit;
	}
?>

短いコードで、難しいこともしていないので、特に解説の必要はないと思うが、軽くメモ書きしておく。

if (is_page(‘random’)) {…} により、スラッグが’random’の固定ページでのみの処理としている。

get_posts()のパラメータを$argsで指定している。orderbyを’rand’にするのが唯一と言っていいポイントだ。ここでカテゴリーなどを指定することで、特定の範囲に絞ったランダム記事に飛ばすこともできる。

で、1記事で十分なので、$rand_postにリストの1番目を入れて、その記事のパーマリンクの文字列をget_permalink()で取得する。ループ内で使うthe_permalink()じゃないよ。

で、取得したリンクにwp_redirect()で飛ばす。第二引数にステータスコードを入れることもできるのだが、省略すると302になる。302は一時的な遷移の時に使われるもので、まぁ今回のケースに合致するかは微妙な気もするんだが、少なくともドメインの引っ越しとか恒久的なリダイレクトで使われる301よりは意味が近いだろうから、まぁそのままでよいかな、と。

おわり

以上で、ナビゲーションメニューにランダム遷移な項目を追加できた。まぁエンタメ系のサイトだと、こういうのも意味あるかな、と思って作ってみた。このサイトだとあんまり意味ないと思うので、このサイトには実装せず。

それにしても、WordPressでしかPHPを使わないので、時々手を入れようとするととても疲れる。セミコロンうち忘れて技術的な問題を発生させまくる私。Cだと忘れないのにPHPだと忘れるのは何故だろう。

参考リンク

サイドバー復活。ブログを1カラムから2カラムに戻した

Tue, 05 Jun 2018 12:38:14 +0900

このブログは元々平均的な、メインカラムとサイドバーの2カラム構造だったのだが、2016年11月、コンテンツファーストの考えの元、サイドバーを取っ払って、1カラムに変えた。

ただまぁ、実際のところPCで閲覧する限り、サイドバーというのはやはり便利だと思うことが多い。そして当サイトのユーザーは7割がPCであり、コンテンツの内容から、それは変わることがないように思えた。で、自分的に考えが変わったこともあり、一年半ぶりに、サイドバーを復活させてみることにしたのだ。

1カラムにした経緯

このサイトは元々は標準的な2カラム構成だった。メインがあって、右にサイドバーがある。サイドバーには、サイト内でアクセスの多い記事や、最近投稿した記事、カテゴリなんかが並んでいる。広告を載せていたこともあった。

が、サイドバーの意義について疑問に思うところがあって、やめた。つらつらと考えた記事が以下。

まぁごちゃごちゃと書いているけれど、だいたい以下のようにまとめられる。

記事を見るのにサイドバーが邪魔
モバイルだとどうせ下に追いやられて見えない
PCでもあまりクリックされない

サイドバーは確かに機能的で、そのサイトのことがひと目である程度わかる。けれど、いろいろと調べていると、コンテンツファーストという考え方があることを知り、それによれば、閲覧者が見たいのは記事の内容であって、サイト構造ではない、という至極もっともな指摘。なるほどそうだなぁと思い、サイドバーをやめたのだ。

サイドバーを復活させることにした理由

それから一年半。シングルカラムのブログも少しずつ増える中、自分はサイドバーを戻すことにした。

理由はだいたい以下のとおり。

管理者目線だとサイドバーがあると便利
モバイルよりPCのアクセスが多い
クリックされない=見られていない、ではない
そのサイトはどんなサイトか、という背景は重要な情報

サイドバーは、そのサイトを散策するのにはやはり便利なもので、まぁ確かにこのサイトの読者のほとんどは1記事だけ見て去っていく一見さんなのであるけれど、何度も来てくれる人も少しはいるようであるし、そしてなんと言っても、少なくとも自分は使う。自分だって読者だ。というか一番の読者だ。一番の読者は大事にしないとね。

そしてモバイルのアクセス比率が、当サイトの場合一向に増えない。いまだに7割くらいはPCだ。まぁそれは、当サイトの記事内容の偏りのためであろう。考えてみれば、自分もこのサイトをスマホで見ようと思わない。そしてそれは、今後も続いていくものだと思われる。なので、モバイルファースト云々、はあまり考えなくてよいのかなー、と。

そして、次が一番の理由なのだけれど、サイドバーは、その記事の内容を考えるうえでも重要な情報だ、と考えるようになったことだ。

1記事で完結できる、立派なコンテンツばかりではなく

言うまでもなく、インターネット上の情報は玉石混交である。書いてあることをまるっと鵜呑みにしてはいけない。だから、そこに書かれていることがどれだけ信頼できるのか、使われている言葉のニュアンスはどうなのか、そういうことが知りたいわけだ。そのためには、その記事を書いた人は誰なのか、あるいはどんな人なのか、ということがわかると、非常に有り難い。

それには、サイドバーが便利だと思う。考えてみれば、自分は他所様のサイトでもサイドバーをよく見る。それによって、そのサイトがどういう情報をメインに扱っているのか、なんとなしにわかる。また、継続的に更新されているサイトなのか、最近はどんなことに関心を抱いているのか、他記事のタイトルの付け方はどんなか、そういったことも伺い知れる。

それは、その記事の内容を判断する上でも重要な指標だ。サイトのメインジャンルはやはり記事を書いた人の得意分野であろうから、記事の内容にどれだけ詳しいか、姿勢はどうか、予想がつけやすいし、また扇情的なタイトルをつけた記事ばかりが並んでいたら、その記事の信頼性も落ちるし。MS系を邪険にする記事のサイトにApple系の記事多かったら、ああねって感じだろうし（いや、うちのサイトのことでは…）。

サイドバーを必ずしもクリックするわけではないけれど、だからといって見ていないわけではないのだ。

そりゃもちろん、1記事の内容で完結できるように、しっかりとした記事を書くことは可能だろう。でも個人サイトの1記事で、それはない。むしろ逆で、多くの知識、理解を共有していることを前提としている。もちろん、人様に見られるものである以上、ある程度は一見さんの目も気にしているが、基本的には、ま、これくらいのことは知っているよね、とか、こういう流れの記事だよね、とか、私ってこういう人やん、という態度で記事を書くのが実際のところだ。

なので、ほとんどの場合、サイトの記事には多くの書かれるべき前提が抜け落ちている。その前提を補完する作業は中々にしんどいので、今なお、ネットで調べればわかるでしょうということでも、本というパッケージが売れ続けているのだろう。

サイドバーは、記事の前提を補完する一助となる有用なツールじゃなかろうか。そう思うに至り、当サイトではサイドバーを復活させることにしたのだ。

まぁ、シングルカラムのほうが見た目はカッコいいような気がするけれど、ブログとしては、やっぱりサイドバーはあったほうがいいかな。

Google Analyticsを使うための基礎を学ぶ

Mon, 09 Apr 2018 17:35:21 +0900

最近Google Analyticsを使ってアクセス解析をしている（このサイトではもうずっと前からしてはいる…まぁ何か月かに一回PVを見るだけなんだけれど）。しかし周りに詳しい人もいないので、例によって自分で色々と調べながら試行錯誤の日々。

ひとまず、基本的なところで、学習したことを覚え書き。

サイトの目的は何か

アクセス解析をする上では、まず「このサイトの目的は何か」を考えなくてはならない。アクセス解析はサイトの目的を達成するために行うものだからだ。

ECサイトであれば、サイトの目的はわかりやすく「売上を伸ばす」なのだが、当サイトのような雑記ブログだと、特に目的なんてものはなく、どうしたものかと思う。まぁ基本は自分の覚書で、そのうち誰かの役に立ったらいいな、とか、常連さんができたら嬉しいな、くらいのものなので、どこまでいってもPVだ……などというのはどうでもよいこと。

目的を決めたら、その目的を達成するための、具体的に数値化できる「目標」を設定する。アクセス解析では、この「目標」に向けて、施策と解析を繰り返すことになる。たとえばゴールページを設定し、そのページに到達されることを目標とするとか、広告のクリックを目標とする（クリック計測）、など。

この目的と目標を決めるのが一番むずかしいのではなかろうか。目標は数値化された成果でなければならず、この成果を評価する指標としてKGI(Key Goal Indicator, 重要目標達成指標)があり、KGIに至る経過としてKPI(Key Performance Indicator, 重要業績達成指標)がある。たとえば、ゴールページがあったとして、そのゴールページへの到達がKGI、そこに至るまでのページ遷移がKPI、など。

参考

【テンプレートあり】KPI・KGIの違いとは〜目標達成に欠かせない2大項目について徹底解説｜ferret [フェレット]

アクセス解析の手法

成果を測るためにアクセス解析を行うわけだが、その元ネタとなるデータを集める手法について、ざっくりと理解したい。これは大別して3種類ある。

サーバーログ方式
パケットキャプチャ方式
ビーコン方式

サーバーログ方式は、たとえばapacheやnginxの残すログであったり、または自前のアプリケーションが残すログから解析する。トラブルがあった時にはもちろん見ることになるが、アクセス解析目的としても、作り込みさえすれば恐らく最も詳細な情報が得られるだろう…が、その分手間もかかる。データ量も膨大であり、アクセス解析の目的にはやや重すぎる気がする。

パケットキャプチャ方式は、ネットワークを流れるパケットそのものを直接解析する方式。最初はWiresharkのようなものを想像して、アクセス解析というより組み込み機器やネットワーク機器の試験に使われるものではないんだろうか、なんて思ったのだが、どうやらそれ用の製品が、ハードウェアからあるらしい（ログ型、タグ型にも対応可能なアクセス解析ツール「RTmetrics」製品紹介 | オーリック・システムズ株式会社）。で、利点としてはリアルタイムに解析ができる、専用のハードウェアを用いるのでWebサーバーに負荷をかけない、などがあるようだ。しかし、ハードウェアを用いるので、当然導入コストは高く、また保守・運用コストも馬鹿にできないだろう。普通はあまり選択肢にのぼらないのではなかろうか。

最後のビーコン方式は、html内に所定のタグを埋め込むことで、都度サーバーに情報を送る方式である。Google Analyticsで採用されている方式はこれ。解析対象の全ページにタグを埋め込まなくてはならないが、それさえしてしまえば、Google Analyticsというリッチなサービスを使えるのだから、大助かりである。

逆に言うと、ビーコンを送らなければ計測されない。それを利用して、たとえばWordPressなどでは、ログインユーザーに対してはビーコンを送らないようにする、などして任意のユーザーのアクセスを除外できる。Chromeのアドオンでは、自分のビーコンを送らないようにするものもある。

参考

何をどのように計測できるのか

以降、アクセス解析はGoogle Analyticsを前提とする。

Google Analyticsでは、何をどのように計測できるのか。それは前節のビーコン方式、ということがすべてなのだけれど、もう少し具体的に言うと、ユーザーがアクセスしたページのカウント、バナーのクリック率、資料のダウンロード回数、サイトの滞在時間といったものを、html内のタグを通じて計測することができる。

そして、クリック計測などのためには、それ用にタグを改変しなければならない（aタグにonclick属性をつけるとか）。やりたいことを思うがままにしていくと、だいぶ煩雑になってしまうので、タグの管理が重要になる。

そのためのツールとして、Google Tag Managerというものがある。ここでは詳しくは触れないが（というか自分も勉強中なので、書きたくても書けない）、ある程度本格的にアクセス解析を行うつもりなのであれば、Google Tag Managerの利用が推奨されている。Google Tag Managerを使うと、コードをいじらずに計測するものを管理できるので、特にエンジニアとデザイナーで分業している（コードをいじる人とデザインする人が異なる）ケースで役立つ。

また、アクセスしたユーザーについての情報も得られる。それは使用しているデバイスやブラウザといった、基本的なものから、サイトにアクセスした回数、検索エンジンから来た場合の検索ワード（これは最近は専らSearch Consoleによる）とか、いったいどうやっているのか知らないが、ユーザーの年齢や性別、嗜好まで様々。

データをどのように見て、活用すればよいのか

種々のデータが得られるのはよいのだが、あまりにも膨大な情報が得られるので、正直どうしてよいのかわからない。サイトの全体的な傾向を見るだけならば、ユーザー数、セッション数、PVを見ればよいが、これを見ても「ふーん」と思うだけで、何か行動が変わるわけでもない。まぁPVが増えていけば励みにはなる（このサイトはもう2,3年くらい横ばいである…）。

ということで、最初の話に戻るのだが、サイトの目的と、目的達成のための目標が重要である。逆に言うと、このサイトのように目的がないと、特に解析するものもない。最近、このサイトにも何か目的が合ったら良いだろうかと考えているのだが、何も思いつかない。

閑話休題。

たとえば会員サイトで登録者数を増やすことを目的として、目標を会員登録の完了ページに到達してもらうことと考える。そのためには、まず会員申請のページに到達してもらう必要があり、かつ実際に会員申請をしてもらう必要がある。その経過について、それぞれのアクセスをコンバージョンとして、どれだけのコンバージョンがあったかを解析していくと、会員登録に至るまで、ユーザーがどの段階で振り落とされていくかを可視化することができる。

これをファネル分析と言う。ファネルとは漏斗のことで、ユーザーが段々と絞られていく様を表現したものらしい。

ファネル分析で、ユーザーの離脱率が高いページがわかれば、そのページを改善し、変更前と変更後のアクセスの変化を解析することで（可能であれば、変更前と変更後をランダムに表示するA/Bテストで）、変更の成果を定量的に測ることができる。

その他、PVアップが目的であれば、ユーザーが最初に到達するページ（Google Analyticsにおいてはランディングページ(LP)と呼ばれるが、一般的には別の意味もあることに注意「ランディングページ（LP）とは何か？-メリットをわかりやすく解説！」）を調べて、そのページ関連するコンテンツを増強する、等の対応が考えられる。

また、直接コンバージョンに寄与しておらずとも、リピーターや滞在ページの多いユーザーに焦点を絞って解析し、よく見られているコンテンツを調べるなど、そのサイトで求められているものを調査することもできる。

ひとまずこれくらいで

他、各種ユーザー情報を利用すれば、より高度に仮説の検証やらが出来るはずなのだが、今のところ自分にはこの程度で精一杯である。少しずつ知識を積み上げていきたいが、あまりこれを頑張るのもなんだかなぁという微妙な感じ。

とりあえず、ダイレクトにトップページに来てくれているリピーターさんは常連さんだと考えてよいのだろうか。いや、このサイトで別にそんな解析をする気はないが……。

まぁでも、アクセス解析について勉強するにつれ、このサイトももう少し何か考えたほうがよいのだろうか、なんて思う今日この頃である。

今回の参考にさせていただいた書籍。ただし、自分が読んだのは随分前に入手した第一版のほうで、情報の古いところが散見された。移り変わりの早いジャンルなので、二版を手に入れるべき。

WordPressでGoogle Tag Managerを利用する

Thu, 05 Apr 2018 11:53:14 +0900

WordPressでGoogle Tag Manager（以下GTM）を利用するためのメモ。GTMについてのごく基本的な知識はあるものとする。つまり、アカウント作成から書くわけではなく、何をしなければいけないのかわかったうえで、WordPress特有の操作部分について触れる。

タグをつくってスニペットをget

GTMの管理画面より、適当にタグを作っておく。で、管理タブの「Goolge タグマネージャをインストール」よりスニペットをコピーしておく。

このスニペットを、すべてのページの<head>内と<body>内に貼る必要がある。また、管理者のヒットまで測定してしまうのは嬉しくないので、ログイン時にはカウントしないようにしたい。

WordPressのphpに貼り付け

探せばGTM用のプラグインも多くあるのだが、勝手がよくわからないので、直接コードを書き換えて対応する。

WordPress管理画面より、「外観」→「テーマの編集」→「テーマヘッダー(header.php)」を選択。

<head>内の、<?php wp_head(); ?>より下のどこかに、指定のスニペットをペタッとペースト。また、<body>直下あたりにも、指定のスニペットをペタッとペースト。

さて、これだけだと管理者の足跡も残ってしまうので、ログイン時にはスニペットを外しておきたい。以下のようにする。

<?php if ( !is_user_logged_in() ) : ?>

ここにGTMのスニペット

<?php endif; ?>

!is_user_logged_in()で、ログインユーザーの時はGTMを使わないようにしている。これを<head>内と<body>内でそれぞれ適用。

確認

終わったら、一旦WordPressからログアウトして、GTMがきちんと動作しているか確認する。

GTMの管理画面に戻り、ワークスペースのプレビューでテストを実行。その状態でサイトにアクセス。

[caption id=“attachment_6488” align=“aligncenter” width=“1888”]

下になにか出ている[/caption]

Tags Fired On This Pageでタグがちゃんと発火（って言っていいのだろうか）していることを確認。

終わったらプレビューモードを終了して公開。公開するのを忘れない。

以上。

WordPressでGoogle Analyticsを利用する

Tue, 03 Apr 2018 15:51:37 +0900

WordPressでアクセス解析サービスのGoogle Analyticsを利用するメモ。

プラグインを使ったやり方と、自分でソースコードをいじるやり方がある。自分のアクセスを弾くのがポイントか。ただ、直接利用するのではなく、Google Tag Managerを利用するのが良いのかな、と思う。

Google Analytics

Google謹製のアクセス解析サービス。費用がかからないのが信じられない高機能。高機能過ぎて使いこなせない。

利用するのは、htmlの<head>内にコードを記述するだけ。それについてのやり方はこの記事の本旨ではないので省略。

WordPressの場合、コードをいじるか、プラグインを利用するか。コードをいじるほうが小回りがきくものの、簡単なのはプラグインだろう。ただプラグインを使うほどのものでもないとも思う。プラグインだと、更新されているかを気にしないといけないし。

管理者としてログインした時に、アクセスを弾くのがポイントか。Chromeなら、Google Analyticsでカウントされないようにするプラグインを利用するのも良い。

ただ、Google Analyticsを直接利用するのではなく、Google Tag Managerを使うほうが良いのかな、と思う。

プラグイン

お手軽。

Google AnalyticsのWordPressプラグインは色々あると思うが、自分はSuper Simple Google Analyticsを利用していた。有効化したら、Google Analytics NumbersにUA-hogehogeを入力するだけ。管理者のヒットを記録しないため、Track Administrator Hitsのチェックを外しておく（ヒットしてもよいならチェックする）。

コードをいじる

外観→テーマの編集→テーマヘッダー(header.php)をいじる。<head>以下、<?php wp_head(); ?>の後あたりに、指定のスニペットをコピペ。

[caption id=“attachment_6483” align=“aligncenter” width=“1390”]

コピペ[/caption]

わざわざ貼るほどのものでもないと思いつつ。

まぁこれだけなので、特にプラグインを使うこともないのではなかろうか。

Google Tag Manager

この記事の本旨ではないので詳細は記述しないが、真面目にアクセス解析するならクリック解析など色々なことをする必要があろう。そうするとタグ管理が複雑になってくるので、今後のことを考えると、Google Tag Manager経由で管理するのがよいのかな、と思う。

Weebly で Google Tag Managerを利用する

Thu, 29 Mar 2018 10:57:18 +0900

Weeblyはサイト作成の支援ツールである。ここでは、WeeblyでGoogle Tag Managerを利用する方法について書く。Google Tag Managerの基本的なところについてはわかっているものとして、Weeblyの操作方法に焦点を当てる。bodyの編集をどこでやればよいのかが見つけづらかった。

GTMの利用

Google Tag Manager（以下GTM）を利用するためには、<head>内と<body>内にそれぞれGoogleより発行されたタグを記述すればよい。ここでは、GTMの仕組むやタグがどこにあるのかについては触れない。

Weeblyで利用

さて、Weeblyで<head>内と<body>内をいじるにはどうすればよいか。

<head>は「設定」→「SEO」→「ヘッダーコード」に記述すれば良い。

[caption id=“attachment_6467” align=“aligncenter” width=“1126”]

ヘッダーコード[/caption]

で、次に<body>をいじる。「テーマ」→「HTML/CSSの編集」。下の方にしれっとあって、探しづらい。

[caption id=“attachment_6468” align=“aligncenter” width=“306”]

見つけづらい[/caption]

めっちゃ縦長。しかも短くすると「HTML/CSSの編集」部分の下半分が消える。

次に、「ヘッダーの種類」→「header.html」を開いて、<body>以下にタグを貼り付ける。

[caption id=“attachment_6469” align=“aligncenter” width=“1316”]

タグを貼り付け[/caption]

あとはGTMの設定の問題。

以下の記事を参考にさせていただきました。ありがとうございました。

Install Google Tag Manager in Weebly - Dmitri Ilin’s blog

Google様の言いつけに従って、https化の準備をしなくてはならない

Sun, 18 Feb 2018 21:44:47 +0900

2018年7月にリリース予定となっているChrome68より、http接続のサイトは警告が発せられるらしい（「Chrome、HTTP接続の全サイトで警告を表示、今夏から - CIOニュース：CIO Magazine」）。このサイトについては既に対応済みであるが、趣味で運用している別サイトはしていない。面倒だがそろそろやらないといけないか……Google様には逆らいませんとも。

そろそろか

http接続というだけで危険サイト扱い。いつかこうなる時は来ると思っていたが、いよいよらしい。恐らく、Apple率いるSafariでも似たようなことはなされるだろうし、これも時代の趨勢か。

まぁ、ごもっともな話ではある。別に個人がなんら情報を送信するわけでもない場末の個人サイトで、https化を強制することもないと思うが、まぁセキュリティの向上に繋がることには違いないし、やらなくていい理由とは言えまいな。このサイトでも利用しているLet’s Encryptなど無料のドメイン証明書発行サービスなどもあるので、経済的な事由も理由にはなるまい。

面倒臭い

ただまぁ、やはり、面倒臭い。一度やったことではあるので、手順自体はだいたい把握しているのだが、やってみると何かとトラブルが起きるものだ。このサイトをhttps化した時も、色々と面倒なことがあった（「結局サイトをhttps対応させました – 或る阿呆の記」）。特に機械的には別サイト扱いとなるので、Googleアナリティクスなど各種統計が取り直しなのが地味に鬱陶しい。

一番面倒だったのは、Amazonアソシエイト・プログラム絡みのトラブルであった。httpとhttpsは別サイトだからと、丁寧に申請し直したのだが、その際どういうわけか、Amazon側の人から「サイトが見られない」と言われ、しかしこちらは普通に見ることができていたから、色々なOSとブラウザの組み合わせで試行し、Amazonのサポートの人と何度も連絡を取り合う羽目になってしまった。最終的に、Amazon側で閲覧するブラウザを変更したら見ることができたそうな。

この時のことが半ばトラウマとなって、https化には及び腰であった。が、最近調べてみると、どうもhttps化させただけであれば、Amazonアソシエイト・プログラムの再申請は必要ないらしい（参考「ブログを常時SSL化したらAmazonアソシエイトに再登録が必要か問い合わせてみた｜イエノナカノヒト」…聞いてくれて有難うである）。

昔調べた時は、申請が必要、と言われていたように思うのだが……あれから状況が変わったのだろうか。まぁ、普通に考えて、同じドメインで、httpとhttpsで別サイトにした、なんて変わり者はそうおらんだろうし、必要ないよなぁ。だいたい同じドメインでも、サイトの内容をガラッと変更させることだってあるわけだし。

というわけで、以前一番面倒だったAmazon絡みの問題はクリアできて、またいい加減Googleさんもシビレを切らしているような感じなので、どこかで折を見て、サイトのhttps化に乗り出そうかなぁと思う。

大昔、若気の至りで作ったサイトまではさすがに対応する気がないが。そういうサイトは多いのだろうな。検索順位にも影響があるんだろうか。でも、あの時代に作られて、そのまま放置されているサイトって、けっこう有用だったり、面白かったりするサイトが多いと思う。アマチュアリズムを発揮して作られたからだろう。今時の、在宅ライターに安金払って、体裁だけ整えて通り一遍のことを無難に書き連ねたまサイトなんぞより、よほど良いサイトだと思うのだが。何か寂しい感じもする。

ブログのダイレクトメッセージはGoogleID公開でいいんじゃなかろうか

Sat, 07 Oct 2017 17:09:51 +0900

ブログでは記事へのコメント欄とは別に、管理人に直接メッセージを送る需要がある。メールアドレスを公開すれば済む話だが、そうするとスパムの餌食になる可能性があるため、"@“を"あっと"と書いたり、画像化したり、メールアドレス公開ではなく送信フォームを作ったりと、皆色々な工夫をしている。

色々と考えた結果、サイト用にGoogleでIDを取得し、それを公開する、という極めて原始的な方法に落ち着いた。公開してから10ヶ月近く経過したが、時折メールは届くし、スパムはきたことがない。もうコレでいいんじゃないだろうか。

ダイレクトメッセージの需要

ブログの記事を読んで、何か言いたいことがあれば、たいていコメント欄がついているので、そこに書き込めばよい。が、過去に一悶着あったサイトだと、コメント欄が閉鎖されていることもままある。

このサイトは五年続いているにも関わらず、幸いこれまでややこしいことにもなっておらず（感謝）、今のところ特に制限も設けずコメント欄を開放しているが、今後どうなるかはわからない。少しでも何かあれば先ず承認制に移行するだろうし、それでも面倒臭くなれば廃止するだろう。どうしても何か一言言いたいというだけならば、今時は記事のリンクを貼ってTwitterで呟けばよい話なので、ブログとしては寂しいが、いざとなればコメント欄閉鎖も問題ないと考えている。

したがって、記事に対するコメントは何も問題ないとして、それとは別に「管理人に対して」伝えたいことがある場合もある。その需要に応える形で、たいていのサイトやブログでは、メールアドレスを公開していたり、コメントフォームを設置していたりする。

種々の苦労

一番簡便なのはやはり、メールアドレスの公開である。しかし、メールアドレスを公開すると、スパム業者の餌食になりやすい。ということで、”@“を"あっと"に変更したり、全体を画像化したり、文字列の一部を全角化したり、別の文字に置き換えて注釈を加えたりなど、種々の涙ぐましい対応がなされている。

一番良いのはコメントフォームを設置することと言われており、まぁそれはたしかにそうだろう。利用者もメールアドレスを必ずしも公開しなくてよいし、負担が少ない。

しかし、当サイトはWordPressで構築しているのだが、その場合コメントフォームを設置するとなると、ちょっと苦労する。まぁ使いやすいプラグインが公開されているので、それを利用すればよいのだけれど、管理の手間が一つ増える。それがあまり好ましくない。

たいした手間ではないと言われればそうかもしれないが、私は嫌なのだ。だいたいこのサイトだって、WordPressでもっとも標準的、というか最初についてくるテンプレート、TwentySeventeenをほぼそのまま使っている（見出しの節番号入れなど、機能に関わる最低限のことのみ手を入れている）。以前はTwentySixteenを使っていた。導入しているプラグインも10前後と少ない。ブログは記事が読みやすいことが一番重要なわけで、メンテナンスコストは最小限に抑えたいのだ。

で、コメントフォームを使わないとなれば、結局メールアドレスの公開に落ち着くのだが、メールアドレスの公開には先に挙げたような対応が必要で、なんだかこれもスマートではないなぁと思えて、微妙ではある。

色々考えた末、このサイト用に取得したGoogleのID名を公開し、Googleなんだから@の後ろは自ずとわかるよね、という形に落ち着いた（「CONTACT – 或る阿呆の記」）。

[caption id=“attachment_6004” align=“aligncenter” width=“783”]

画面[/caption]

スマートかと言われると微妙だが、余計な置き換えなどがなくシンプルであると思う。かれこれ10ヶ月これで運用して、現在まで問題は起きていない。送り主のIPアドレスがわからないが、その代わりメールアドレスがわかるので良いだろう。悪戯メールは御免だが、悪戯コメントさえほとんど来ない当サイトにおいては杞憂か（本当に感謝）。スパムメールもない（Gmailが優秀なのでスパムが来ないというだけなのかもしれないが）。

個人サイトだったら、わざわざコメントフォームなんて設置しなくても、もうコレでいいんじゃないのかなと思う今日この頃である。

ところでどうでもいいが、ニックネームが気恥ずかしくなってきたので変えたいと思っているが、踏ん切りがつかない。ドメインの変更は手間がかかるので、多分そのままだろう。

サイトの背景色を一瞬だけダークにしてみてやめた

Wed, 20 Sep 2017 03:36:55 +0900

サイトの背景色をダークにしてみた。しばらくニヤニヤした後、我に返ってやめた。

眩しっ！と思って

もうずっと、軽度の不眠が続いている。今も眠れていない。最近は在宅での仕事が多く、時間には融通がきくのでなんとかなっているものの、このままだと生活に支障もきたす。なんとかしたいところだが、中々難しい。

眠ろうとするとかえって目が冴える。よくないと思いつつも、ついついスマートフォンなどいじってしまう。「不眠」などで検索し、「寝る前に電子機器をいじらないようにしましょう」などと書いてあるのをベッドの上で見ているのだから世話ない。しかしスマホを閉じたところで眠れないものは眠れないのだ。

どうせ眠れないのであればと、更新が滞りがちな自サイトを覗く。そうすると、真っ白な背景が真っ暗な部屋の中で眩しく輝く。目が痛い。

以前「ナイトシフトは使ってみると確かに目に優しい感じがする – 或る阿呆の記」の記事で、ブルーライトカットの効用について書いた（この記事でも不眠について書いている…慢性的な不眠がもうずっと続いているようだ…）。また、ダークテーマを用意しているアプリケーションは、単なるデザインの問題ではなく、実利的な意味があることにも気づき、それ以来、対応しているアプリについては積極的にダークテーマを活用している。

その流れからいくと、本サイトもダークテーマを採用してよいのではないかと思えた。背景色をホワイトにしているのは、デフォルトがそうなっているからで、別に拘りがあるわけではない。見づらくなければよいのだ。背景色をブラックにして、文字をホワイトにしても、さほどみづらくはならないだろう。

お昼は明るいほうがいい

ということで、なんとなく背景色をブラックにして、サイトをダークにしてみた。

[caption id=“attachment_5935” align=“aligncenter” width=“784”]

ダーク[/caption]

ほう……なんだか新鮮である。こじらせた中学生が作った裏サイト（笑）感がないでもないが。まぁそういう内容のサイトではないし。特にスマートフォンで見た時には、普段よりも確かに目に優しい感じがしたので、それなりに効果があるように思えた。

…で、しばらくそのままにしていたのだが、よくよく考えてみるとこのサイトは平日の昼間にもっともアクセスが多いサイトである。恐らくは何かしら調べ物の際に辿り着いているのだと思う。そんな平日の昼下がり、訪れたサイトが真っ黒だとギョッとしてしまうのではなかろうか。

昼間っから眼精疲労に気を遣う必要はないわなぁ……また、スマートフォンで見るとそれなりに良い感じに見えたものの、パソコンだとやけに仰々しくも感じる。大画面一杯真っ黒なのは、それはそれで強烈だろうか。

うーん……ではもうちょっとグレーな感じにするとよいかもしれない。しかしそうすると文字色が悩ましい。うーん……なんだかどうでもよくなってきた。戻そう。戻した。

つまり、夜は早く寝なさいということである。

TwentySeventeenで1カラム（シングルカラム）にする

Mon, 08 May 2017 10:30:48 +0900

先日、当サイトのテーマをTwentySixteenからTwentySeventeenに変更した。当サイトは1カラム（シングルカラム）である。一手間必要だったのでメモ。

謎のオフセット

サイドバーにウィジェットを設置しない1カラムレイアウトにすると、フロントページやアーカイブページ、固定ページに謎のオフセットが発生する（下図）。

[caption id=“attachment_5367” align=“aligncenter” width=“948”]

謎のオフセット[/caption]

何故こうなるのか、よくわからない。

対応

「Topic: Single column posts page in Twenty Seventeen? « WordPress.org Forums」を参考に対応した。

まず、固定ページの「カスタマイズ」→「テーマオプション」より、「1カラム」を選択する。

[caption id=“attachment_5369” align=“aligncenter” width=“549”]

1カラムを選択[/caption]

変更したら保存する。

これでなおればよいのだが、自分の場合、フロントページやアーカイブページは謎のオフセットが発生したままであった。で、参考ページにあったコードを、style.cssに追記する必要があった。

`@media screen and (min-width: 48em) { .blog:not(.has-sidebar) #primary article, .archive:not(.page-one-column):not(.has-sidebar) #primary article, .search:not(.has-sidebar) #primary article, .error404:not(.has-sidebar) #primary .page-content { width: 100%; } }`

これを適用すると、オフセットは発生しなくなるが、余白の設定が本来と異なるようだ。

なお、style.cssを変更しても、ブラウザでページを閲覧すると、変更前のキャッシュが残っているためリロード（更新）しても変更が反映されないことがある。そのような時、即時変更を反映させるには、通常のリロードではなくスーパーリロードする（Mac版ChromeではCmd+Shift+R…参考記事「君は3つのリロードを知っているか？ - os0x.blog」）。

後日、上記コードをコメントアウトしてみたところ、一時的にオフセットが発生せず、適切な余白のある1カラムとなり、「アレ？やっぱりいらないのか？」と思ったのだけれど、その翌日にサイトを確認すると、やはりまたオフセットが発生していた。どうにもよくわからない。

ブログ作って4年半、ですます調からであるだ調を基本に変更する

Fri, 05 May 2017 22:09:56 +0900

ブログとしてサイトを開設して4年半。いつのまにか記事数も400を超えて、思う。ですます調ってのは妙だなぁと。それなりに納得してですます調で続けてきたのだけれど、いちいち改まっている感じで、どうにもよろしくない。サイトの記事の性質が変わってきたことも影響しているだろうか。それは自分の変化でもある。

端的に言うと、人のためというより、自分のために記事を書くようになった、のではないかと思う。もはや独り言に近いかもしれない。独り言が敬語の人は、相当珍しいだろうな。

で、実にいまさらではあるのだけれど、であるだ調を基本に変えようと思う。解説を主眼においた技術系の記事は、しれっとですますで書くかもしれないけれど。

変更します

実にいまさら。2012年の10月に開設して、オリンピックもやって、今は2017年。そういえば愛機Mac mini 2012が発売された頃か（いまだに使えているのが嬉しいような残念なような）。しっかり4年半経過している。

ブログをやっている人ならわかると思うけれど、文体の基本形がですます調かであるだ調かは大事なことで、それを変えるのは、そのサイトにとってはけっこうな大事件。ある日一人称が"僕"だった人が、突然"俺"と言い出したら、小学生の男の子ならともかく、大人なら「何があった？」と心配になるだろう。口調、語調はキャラ付けの基本で、軽々に変えられないものだ。

でも変える。変えてしまう。続けて4年半というけれど、あと5年続けたら最初の4年半がマイノリティ。いや、違和感の払拭だけならすぐだろう。身内や友達や恋人が髪型変えたら正直慣れないし、たいていの場合は前のほうがよかったと思うけれど、2週間もすれば前の髪型のほうが思い出せなくなる。そんなものなんだ。

このサイトは検索エンジンからの流入を基本としているので、あまり定期的に見に来てくれている人はいないと思うから（見に来ているよという人には有難く思う。来たいわけじゃないけど特定のキーワードで検索するとやたら出てきてまたおまえか状態だよという人、すまん。その気持ちわかる。でも文句はGoogleに頼む。そしてそれなのにこの記事に辿り着いたなら、やっぱりありがとうだ）、わざわざこんなこと記事を書く必要性はないかもしれない。でも、どちらかと言うと自分のために、ここに変更を宣言している。そう、自分のため。自分のためなんだ。

誰のための記事か

自分のため、これが今回の変更の一番の理由じゃなかろうか。

前述のとおり、ですます調かであるだ調かというのは、キャラ付けの基本で、ブログを始める際にはたいていの人がどちらにするか悩むところだ。自分も悩んだ記憶がある。結果としてですます調を選んだけれど、考えてのことだから、納得してそうしたということだし、また今でも間違えてはいなかったと思っている。あの時はそうするのが自然だった。

つまり、あの頃と今で、記事の性質が変化している。それは畢竟自分の心境の変化である。ですます調が自然だったあの頃と、今は違うんだと思う。

「全記事一覧」には時系列で当サイトのタイトルが並んでいる（使っている人はいないだろうが）。それを見ると、このサイトでもっとも古い記事5件のタイトルは以下だ。

Windows 8ではシャットダウンしても電源が完全に落ちない (2012年11月4日)
Ace PlayerでDLNAサーバー(MiniDLNA)上のフォルダが更新されないときのメモ (2012年10月31日)
小型のメディアサーバー兼NASをたてるその3 〜初期設定、SSH編〜 (2012年10月30日)
小型のメディアサーバー兼NASをたてるその2 〜RAID編〜 (2012年10月24日)
小型のメディアサーバー(兼NAS)をたてるその1 〜準備編〜 (2012年10月21日)

懐かしい（Windows 8！）。タイトルからわかるように、いわゆるハウツーもの。メディアサーバーをたてる記事は、本サイトで最初で最後の連載記事だった（今後も連載記事を書く気はない。面倒だから）。ほとんど当時の雑誌Ubuntu Magazineにあった内容をなぞっただけで、今見ると気恥ずかしい。その後も、技術系のメモやガジェットのレビューが多い…これは今も多いのだけれど、そればかりではない。最近5件の記事が以下だ。

macOS Sierraでもクリーンインストールすればメモリ4GBで足るらしい (2017年4月28日)
運用することの難しさ (2017年4月26日)
macOS Sierraをクリーンインストール後にやったこと (2017年4月24日)
ようやくmacOS Sierraをインストール (2017年4月23日)
PiVPNでエラーが出たのでインストールしなおした (2017年4月20日)

5件中4件がインストールの話でどうかと思うが、それはそれとして、表面的にはやはりコンピュータ関係の記事が多いので、あまり変わっていないと思うかもしれない。

そうでもない。

古い5件が、明確に「解説」を主眼においているのに対し、この新5件は解説する気なんてサラサラなくて、いうなれば"経験"や"考え"をつらつらと書き連ねているだけ。これは大きな差だ。昔だったら、「Sierraでメモリ4GBは足りるのか」とか「運用が難しい理由」（さすがに「運用が難しい4つの理由」にはしないだろう）とか「macOS Sierraクリーンインストールの手順」（何番煎じか）なんて記事にしていたんじゃないかな。

つまり、昔は他人のためになるような記事を書こうという意識が強かったんだと思う。大学を中退して、その後も零細でやってきた自分は、同期もおらず、頼れる人もほとんどいなかった。何か困った時、いつもいつでも、力になってくれたのはインターネットだ。大学時代からそう。ずっとそう。だから、Web上に知識を展開してくれる人に対する感謝もあった（ある）し、自分もその一員であろうという気持ちが強かった（今も）。

まぁ5年も前のことなんて実際のところあまり覚えていないし、ブログを作った理由そのものもなんだったかなぁという感じではあるけれど（紙で別につけている日記を見ても書いていない…）、当時そういう気分があったことは確かで、それはブログの内容に大いに影響していると、今にして思う（5年後の自分にこんな風に分析されるなんて、当時の自分にすれば嫌だろうな）。

とは言うものの、Webに公開している以上、今だって他人に読まれることをもちろん意識している。本当に他人に読まれなくていいならLAN内でほそぼそとやればいいし、実際そうやって作ったものもある。でもこのサイトは違う。今この時も世界中に向けて公開している。それはサーバーの勉強のためだけじゃない。他人のためになるようにという想いは、今もちゃんとある。

けれど、それはもうメインではないのかもしれない。極端な話、結果として誰のためにならなくてもいいと思っている。自分が読めれば、それでいい。結果、誰かのためになることがあれば、それは嬉しいことだと思う。

ということで変えます

他人に「解説」しようではなく、「まぁよかったらちょっと聞いてくれる？」とか「今日やったことだけどさ、参考になりそうだったら聞いてってよ」くらいのトーンに落ち着いた、という感じかな。

それには、ですます調っていうのはどうにもいちいち固くてよくない。改まりすぎている。特にぼやきに近い記事なんてのは、丁寧語だと妙にしゃちほこばっているみたいで、ケッタイだなぁと思う。話題によっては、ちょっと偉そうに感じることもある。もちろん書き方を工夫すれば、ですます調でも問題なく書けるのだけれど、いやに面倒臭いし、自分の今にうってつけではないなと思う。

だから、であるだ調。これからは。また心境に変化があれば、ですます調に戻すこともあるかもしれない。また、解説を主眼においた記事は、しれっとですます調で書くなんてのはありそう。ですます調、落ち着いていていいんだけれどね。個人的に購読しているサイトにはですます調が多いし。けれど、今しばらくはであるだ調がしっくりくるな。

ところで、ひょっとすると「元々そんなですます調でもなかったのでは」という問題もあるだろうか。実際、自分は100%ですますで統一してきたわけではない。が、やはりですますが基調ではあったと言えるだろう。

学校の作文では統一せよと教わるし、フォーマルな文章ではそうすべきだ。けれど、ブログ記事など比較的フランクな文章では、であるだかですますかなんてのは表現技法の一つで、両方を織り交ぜて使っても問題ない。口調の突然の変化は、ニュアンスを表現する有効な手法だ。特にですます調は改まりすぎるきらいあるから、自分は好んでその手法をよく使う。

一方、であるだ調はキツくなりすぎるきらいがある。注意しないといけないだろうな。特にネガティブなことを書くとき、思っている以上に攻撃的なニュアンスにならないか、それは気をつけたい。反対の意見を持つ人に気を使って自分の意見を曲げる気はないけれど、それにしたって、必要以上に気分を害させたくはないものな。

無駄にグタグタと長々しくなってしまったが（私の直す気のない悪癖である）、そういう次第なので、今後はであるだ調で記事を書くが、まぁ生暖かく見守ってもらえればと思う。

WordPress高速化のためCentOS 7でPHPを5.4->7.1にアップデート(on ConoHaのVPS)

Thu, 04 May 2017 22:52:57 +0900

当サイトはConoHaのVPSで、用意されているCentOS 7のイメージをベースに、WordPressで構築している。CentOS 7では、標準のphpが5.4だが、今回高速と噂のphp7にバージョンアップさせた。GoogleのPageSpeed Insightsでサーバーの応答速度を見ると、確かに改善されたようだ。体感でも実感できる。作業のためにサーバーを止めた時間は1分程度じゃなかろうか。

環境

当サイトは以下の環境である。

ConoHaのVPS
CentOS 7.3
nginx 1.10.2
php 5.4.16
MariaDB 5.5

何故かCentOS 7はphp 5.4.16でずっとメンテナンスされているらしい。MariaDBのバージョンも低い（WordPress 4.7の推奨はバージョン10以上）のが気になるが、今回は手を付けないことにする。

前準備

あまり自分でソースをダウンロードしてコンパイルして…などと頑張りたくないので、できればyumコマンドでインストールしたい。Remiリポジトリを用いると、yumで簡便にインストールすることが可能であるようなので、それを利用する。そのためにはEPELリポジトリを使う必要があるが、ConoHaのCentOSイメージは最初からEPEL有効化されている仕様なので、ここでは触れない。Remi、EPELについては「yum が便利になる RPMforge、Remi、EPEL とは一体何なのか – oki2a24」の解説が詳しい。

以下のコマンドを実行。

`sudo rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-release-7.rpm yum --enablerepo=remi,remi-php71 info php `

一応yum infoでバージョン7.1がインストールできることを確認。

あとは、使用しているプラグインや自分の書き加えたコードが、PHP7でも問題ないかであるが、これはもう環境によるとしか言えないのがつらいところだ。自分はあまりややこしいことはしていない（できない）し、使用しているプラグインもせいぜい10程度で、またサポートが続いているものを選んでいるので、まず問題なかろうと判断した。

前準備はこれだけ。

PHPのアップデート作業

ここからアップデート作業に入る。やることは以下。

WordPress関連サービスの停止
現行のPHPの削除
PHP7のインストール
WordPress関連サービスの起動

サーバーを止めて作業をすることになるので、できれば人の少ない時間を見計らって行いたい。トラブルが起きなければ停止時間は1分程度で済むが、トラブルが起きれば……。

`# 関連サービスの停止 sudo systemctl stop mariadb.service sudo systemctl stop php-fpm.service sudo systemctl stop nginx.service  # 現在のPHPを削除 sudo yum remove php*  # PHP7をインストール sudo yum install --enablerepo=remi,remi-php71 php php-mbstring php-gd php-mysql php-pspell php-xml php-xmlrpc php-fpm  # PHPのバージョン確認 php --version  # PHP-FPMの再設定(nginx) sudo sed -i "s/user = apache/user = nginx/" /etc/php-fpm.d/www.conf sudo sed -i "s/group = apache/group = nginx/" /etc/php-fpm.d/www.conf  # 関連サービスの起動と有効化 sudo systemctl start nginx.service sudo systemctl start php-fpm.service sudo systemctl start mariadb.service sudo systemctl enable php-fpm.service  `

PHP-FPMは設定し直しなことに注意。

サイトにアクセスして、問題なければOK。問題あったら……頑張ろう。自分の場合はPHP-FPMの設定を忘れていて、WordPressの操作をするユーザー名がapacheのままになっており、その関係でメディアのアップロードやプラグインのアップデートでエラーが出るようになった（WordPressを使っている人なら一度は見るだろう、FTP接続せよと促すアレである）。ただし、サーバーを停止した時間自体は恐らく1分ほど。サーバーが停止していたことに気づいた人はいなかったかもしれない。

高速化されたか

さて、PHP7にして当初の目的であった高速化は果たされたかであるが、これは驚くべきことに本当に速くなった。そういう触れ込みで、またそのような個人によるレポートも多くあり、だからこそ今回の作業を行ったのであるけれど、本当に快適になると驚いてしまう。

まず体感としてページの表示がキビキビとなされるようになったことがわかる。といっても体感でわかるのは平生からサイトにアクセスしている自分くらいであるから、参考程度に数値を出す。

「PageSpeed Insights」にて測ったところ、サーバーの応答速度が約0.5秒から約0.25秒にまで短縮された。

[caption id=“attachment_5328” align=“aligncenter” width=“488”]

約0.24秒[/caption]

この「サーバーの応答時間」は、サーバーの負荷の具合などによって左右されるので、指標としてはあまり当てになるものではないかもしれない。しかし、日付や時間を変えて何度か計測したところ、いずれも0.25秒前後であった。この数値はこれまで見られないものだったので、高速化が言えるように思う。

こんなにスムーズにいくなら、もっと早くやっておけばよかったかな。それは結果論か。満足のいく結果だった。

TwentySeventeenに変更。さらば黒枠。よりモノクロームに

Wed, 03 May 2017 13:27:23 +0900

当サイトはWordPressで構築している。テーマとして標準のTwentySixteenを使っていたが、TwentySeventeenに変更した。ただでさえ白黒だったのが、さらにモノクロームな感じになってしまった。

TwentySixteen

WordPressのテーマをTwentySixteenからTwentySeventeenに変更した。標準テーマを使い、これといってカスタマイズもあまりしていない以上、特にテーマに思い入れがあるわけでもなし、なるだけ最新のものを使うのが、機能的にもセキュリティ的にもなんとなく良いだろうと思っている。

TwentySixteenに対する不満もないではなかった。TwentySixteenはシンプルでスッキリした見た目をしており、その点はよい。だが、ある程度広い画面で見た時、フッターが本文の左側に回り込むという仕様はやはりケッタイであったと思う。フッターは最後にあるからフッターなのではなかろうか。

この仕様によるバランスの悪さは、特にシングルカラムにした時顕著であった（下図）。

[caption id=“attachment_4340” align=“aligncenter” width=“901”]

左右非対称[/caption]

サイドバーがある時はまだよかったが、シングルカラムでは本文があからさまに左右非対称で、左側の空白が気になって仕方がない。自分はUIに明るいわけではないけれど、やはりこれはおかしいと思う。

対応するにはどうしたらよいのかアレコレ調べた挙句、Web上の先人の例に習い、985px以上の時のレイアウトを無効化させるという荒っぽい手段を取った（「Twenty Sixteen で記事本文の左側に回り込むフッターを回り込ませない」）。

テーマのレイアウトの大きな特徴を殺すことは、そのテーマを使う必然性を大きく揺るがせる。実際、自分にとってTwentySixteenを使う必然性は無かったといえる。単に良いテーマを探すのが面倒だったので、公式のものならば間違いはあるまいという程度の理由で使っていた。

大きな特徴といえば、サイト全体を囲う黒枠もTwentySixteenの特徴だっただろう。しかしこれも自分は気に入ってはいなかった。この黒枠のインパクトは強烈で、先のケッタイなフッターの位置と合わせて、TwentySixteenはシンプルでありながら非常に強い自己主張を持っていたと思う。

黒枠からの解放

それが気に入ればよかったのだが、残念ながら私にとってあまり良いものではなかった。だから、機会があればテーマの変更をしようと思っていたのである。だがあまり手を入れていないとはいえ、まったくカスタマイズしていないわけでもないので、テーマの変更は億劫な作業であり、ズルズルと先伸ばしにしていた。

が、最近サイトの編集中やけに404エラーが頻発するという謎の不具合があって、これの原因追求も兼ね、えいやと変更作業を行うことにした。この不具合は、どちらかというとWebサーバーのnginxないしPHP-FPMに起因することのような気もする（後でわかったが、php-fpm.serviceを再起動させると症状がなおった）が、いずれにせよテーマの変更は一つ原因の切り分けになるだろう、などとグダグダ考えてみたものの、結局のところテーマ変更する後押しの理由付けが欲しかっただけだろう。

そしていざやりだしてみると、思ったほどには時間がかからないものである。多少手間取ったところもあるが、大きなトラブルもなく変更できた。

元々スッキリしたサイトなのだが、変更後はさらにスッキリした。どうやらこのテーマはリンクさえ色付けしないのが標準らしく、見出し文字の微妙な灰色とあわさり、以前よりさらにモノクロな印象が強まった気がする。灰色一色といういい加減極まりないFavicon（実は変えたい）が妙にサイトにマッチしているなと思った。Google AdSenseの広告だけが、このサイトをかろうじて彩っている。

そして、なんといっても黒枠がない。あの黒枠がないことで、全体的によりぼやけたといえるかもしれない。いや、あの黒枠がサイト全体をかっしりと引き締めていたのかも。異様な存在感というだけではなかったのだなと、なくなったらなくなったで寂しさも感じる。

TwentySeventeenの感触

ただぼやけたと感じるのは、TwentySeventeenの大きな特色であるどでかいヘッダーを有効に使っていないからというのもあるだろう。本当は、一発で人目を引く画像を用意してサイトを華々しく飾るべきなのだ。けれど、このサイトにうってつけなそんな画像を少なくとも今は思い当たらないし、また自分はあまりヘッダーにうるさく自己主張をしてもらいたくもないとも思っているので（昔流行ったまとめサイトの悪印象が残っているからだろうか）、当面は今までどおり画像なしで運用することにした。テーマのレイアウトを有効活用しないのは相変わらず。

まぁ実際のところ、このサイトはテーマの力を少ししか使えていないのだろうと思う。アイキャッチはおろか画像すらほとんど使われない、飾り気のないシングルカラム構造には、幾分重すぎるくらいだろう。むしろ、標準の種々の設定が余計ですらある。

たとえば、TwentySixteenもそうであったように、TwentySeventeenも1カラムデザインとして使おうとすると、ちょっと手をいれる必要があった。シングルカラムでの利用も考えられているようではあるのだが、すんなりとはいかない。やはりブログデザインとしてのメインではないからだろうか。

（追記）1カラムについて。固定ページで、「カスタマイズ」→「固定レイアウト」→「1カラム」を選択する。そうすると、自分の場合はフロントページなどで、左側に妙なオフセットが発生した。対応として「Topic: Single column posts page in Twenty Seventeen? « WordPress.org Forums」のコードをstyle.cssに書き加え、そのときはそれでうまくいった。

その後、広告の挿入、MathJaxやコードのシンタックスハイライトの導入、関連記事の表示、見出しも番号付けなど、一通り手を入れ、最低限の形は整えたつもりだ。ディレクトリ構造やコードの記述の仕方がTwentySixteenと若干変わっていることもあり、まったく同じようにはいかなかったけれど、概ね同じようにはできた。この作業に面白みを感じられない自分は、やはりWebデザインにはとんと縁がないらしい。

全体的にはあまり代わり映えしていないというのが第三者的評価かもしれないが、グローバルメニューが常に表示されていることや、フロントページでもフッターが表示されていること、投稿日が記事タイトルの上に表示されることなど、細かな機能的改善が見られ、それなりに満足している。

TwentySixteenよりもTwentySeventeenのほうが好印象だ。ただあまりにもまんま過ぎるので、もう少し手を入れたい気持ちもある。どうしたものかな。

WordPressの数式表現はMathJaxが一等便利

Sun, 02 Apr 2017 14:58:00 +0900

当サイトはWordPressで構築しています。数式表現はMathJaxを利用させてもらっており、これがたいへん簡単かつ便利でした。

Webでの数式表現

Webの数式表現は長いこと鬼門で、一番よくあるタイプは別アプリケーションで作成した数式を画像化して埋め込む方式でしょうか。MathMLのように、言語として記述できる規格もあるのですが、結局メジャーにはなっていない印象です。表記が異常に冗長で、とてもではないが手打ちは実用でないし、サポートしているブラウザも限られています。特にChromeが標準対応していないのはつらいところです。このあたりの比較は「Webの数式表現」の記事がたいへん参考になります。

MathJax

しかし最近はやはり相当進んでいるようで、MathJaxなるものがあって、それを利用するとWeb上で簡単に数式を表現できるようになります。たとえば以下のように。

[ \begin{align} \lambda & = \frac{-c + c(1 + \frac{1}{2} (\frac{\Delta f \lambda_{0}} {c})^{2})} {\Delta f} \ & = \frac{\Delta f \lambda_{0}^{2}} {2c} \end{align} ]

これの記法ですが、TeXの記法がそのまま使えて、上式では以下のようなコードを記述しています。

[caption id=“attachment_5158” align=“aligncenter” width=“595”]

数式[/caption]

TeXの記法もわかりやすいかと言われるとアレなんですが、なんだかんだ言ってコードベースとなるとTeXしかないなぁと思う今日この頃です。

内部的にはJavaScriptを利用しており、それ故にあらゆるモダンなブラウザで表現することができます。また、数式を使うような記事はなかなか陳腐化せず、それこそ10年以上読まれ続けたりすることもありますので、サポートが続くのかも気になるところですがMathJaxの公式ページを見ると錚々たる組織が支援しているので、まぁ大丈夫だろうと思います。

WordPressで利用するには

さてMathJaxをWordPressで利用する方法ですが、「Getting Started — MathJax 2.7 documentation」を参考に、header.phpの</head>直前に、以下のコードを差し込みます。

`<script type="text/javascript" async src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.0/MathJax.js?config=TeX-MML-AM_CHTML"> script>`

これだけなので、WordPress用のプラグインもあるようですが、まぁ必要ないでしょう。

あとは、ページを作成する時にスラッシュ[からTeX記法を始めてスラッシュ]で閉じると、Web上は綺麗な数式に変換されます。文中に埋め込みたいときはスラッシュ(とスラッシュ)を使います。文中だと(\sin x)のようになります。

便利ですねー。

無料ブログでもいいけど独自ドメインは取得しといたほうがいいよというぼやき…ドメインの引越しはたいへんだ

Fri, 10 Mar 2017 14:29:52 +0900

ドメインの引越しはたいへんです。当サイトは去年の今頃に独自ドメインを取得し、その数ヶ月後、4年お世話になったLivedoorブログをやめて、VPS+WordPressに移行しました。が、実は旧アドレスからリダイレクトするため、いまだにLivedoorブログのIDはもっていて、完全に脱してはいません。いや、気持ちの問題だとはわかっているのですが。独自ドメインだけでも、さっさと取得しておけばよかったなぁ。

引っ越して9ヶ月でもLivedoorブログのIDを消せない

このブログは、5年前にLivedoorブログから始まりました。そして去年の今頃、独自ドメインを取得し、その数ヶ月後に4年もお世話になったLivedoorブログを後にし、その三ヶ月後の7月、VPS+WordPressに移行しました。

さて、問題となるのはURLです。独自ドメインを取得してからの記事であれば問題なくリダイレクトできますが、それ以前のURLについては、Livedoor側で転送してもらわなくてはいけません。このサイトは4年もの間、LivedoorのURLでやってきましたから、つまり非常に多くの記事でその必要があるということです。

ということで、引越してから9ヶ月近くたつのですけれど、いまだにリダイレクトのためだけにLivedoorブログのIDを持ち続けている、という状態です。別にそれで害があるわけではないのですけれど、なんだか気持ちが悪いし、Livedoor側にもちょっと申し訳がない。

[caption id=“attachment_4942” align=“aligncenter” width=“374”]

アクセス0のLivedoorブログ管理画面[/caption]

とはいえ独自ドメインを取得したのは一年前なので、ここ1年の記事については問題がありませんし、また当サイトのアクセスのほとんどは検索エンジン経由なので、消してしまっても問題がないとは思うのです。しかし旧アドレスの被リンク経由がまったくないわけでもなく、どうにも踏ん切りがつかない。強いて言えばRSSフィードがありますけれど、これは変えてもらえないということは結局そういうことなのでしょうから（苦笑）、影響は恐らく小さい。

つまり気持ちの問題なのですけれど、持っていても害がないだけに、なかなかねぇ……さっさと独自ドメインだけでも取得しておけば、こんな悩みもなかったのですが。これからブログを始めようという人は、できるだけ早く独自ドメインだけでも取得して適用したほうが良いですよ、という話でした。

リダイレクトできるだけ幸せ

まぁでも、これは幸せな悩みです。世の中には、否応なくドメインを変えざるを得ない時があって、そういう時は前のドメインからリダイレクトすることすらかないません。たとえば、DDoS食らってドメインを変えろとサーバー会社に迫られたという話もあるそうです（それで解決するとも思えませんが）。また、私は個人的にドメイン凍結を食らったという苦い思い出もあります（参考「使っていないドメインに利用制限…XYZとムームードメイン」…この時の経験から私はXYZはもうサイトには使いません）。

そういう訳ありな事情で引越しを余儀なくされた場合、旧ドメインは使えませんから、リダイレクトすらできない。せめて一時的にでも使えて、Googleアナリティクスなどで引き継げればまだ良いのですけれど、それもできない場合、完全に一から出直しということになり、とても悲しいことになります。

大手ブログサービスのドメインであれば、ドメイン凍結などはなくとも、なんらかの事由によりサービスを追い出されたり、あるいはサービスに嫌気がさして別所でやりたくなったりなどはありうることで、そうすると結局裸一貫で再出発となりますから、なにをどうしても、常になにかしらのリスクがあるものです。

実際に一から再出発する羽目になった他サイトのことなどを思うと、ドメイン変更というやつは、現実の住所変更よりもたいへんで、影響が大きく、時間も労力もかかることだなと思います。せめてサイトの証明手段が、ドメインの所有権以外にもあるとよいのですが。

滞りなくWordPress 4.7 にアップデート

Sat, 07 Jan 2017 22:33:40 +0900

当サイトのWordPressのバージョンを、4.6.1から4.7にアップデートしました。といっても、本当に何事もなくアップデート出来てしまったので、問題なかったという報告程度です。

2017/02/07追記：割と大騒ぎなのでだいたい皆知っていそうですが、4.7および4.7.1はREST API関連で深刻な脆弱性が見つかったので、至急4.7.2にアップデートしなければなりません（「WordPress の脆弱性対策について：IPA 独立行政法人情報処理推進機構」）。

環境だけ

環境を列挙。

ConoHaのVPS
CentOS 7.2
WordPress 4.6.1 -> 4.7
PHP 5.4
MariaDB 5.5

少しはネタになるようなことがあるかと思ったんですが、まったく何もありませんでした。少なくとも今のところは問題が見つかりません。もちろんいいことなのですが。ふむ。

なお、うちで使用しているプラグインは以下です。

Akimset
AMP
Category Order and Taxonomy Terms Order
Easy Table of Contents
Google Sitemap by BestWebSoft
List all posts by Author, nested Categories and Titles
Simple GA Ranking
Super Simple Google Analytics
WP Multibyte Patch

多分少ない方でしょう。なるべく増やさないようにしています。

yumからそのままインストールしているので、phpとMariaDBのバージョンが古いのですが、次はこれを新しいバージョンにしてみようかな。

謹賀新年、2017年もよろしくお願いします

Mon, 02 Jan 2017 03:29:12 +0900

2016年が終わり、2017年が始まりました。根拠もなく2017年は来ないと思っていました。でも来ました。私もとうとう30歳。Don’t trust under thirty。今年もよろしくお願いします。

謹賀新年

せっかくなので新年の抱負でも語ればよいだろうか、そういえば去年は何を書いたかなと見てみると（「謹賀新年、30代になるにあたって」）、39歳と一緒にされるのは嫌だからアンケートは25-34区切りにすべきだとかしょうもないことを書いていました。成長しませんね私。

このサイトについては、ようやく独自ドメインをとったりLivedoorブログをやめてサーバー移転したりhttps対応したりと、2016年は割と盛りだくさんだったのですが、びっくりするくらいセッション数が変わりません。当サイトのセッション数の推移は、やけに変動が激しい某記事がどれだけGoogle先生に好かれるかの推移となっているようです。Google先生が見た目ではなく中身で人を判断しているという証左でしょうか（昨今の騒動を見る限り、騙されやすい一面は今なおあるようですが）。

サイトの内容が変わらないということは、私が変わっていないということでしょう。悲しいことです。それともいいことでしょうか。少なくとも不満足なことです。嫌気がさして転職サイトに登録したけれど、実際にアクションは起こしませんでした。環境は変わりません。でも、周囲の関係は少し変わりました。結婚を考えていた彼女と別れたりとか。そんなこともありました。もう随分前の話です。

何もしなかった割に色々なことがあり、少し疲れました。少なくとも冗談記事を書く気分ではないかな。疲れは未だ癒えないけれど、休むのではなく動くことが必要なのかなと思う今日この頃です。

この歳になってなお迷走していますが、今年もよろしくお願いします。楽しく生きたいですね。

Twenty Sixteen で記事本文の左側に回り込むフッターを回り込ませない

Wed, 30 Nov 2016 00:20:26 +0900

WordPressの標準テーマの一つであるTwenty Sixteenでは、表示領域が大きくなったとき…具体的には、985pxを超えたとき、singleページにおいて、記事本文の左側にフッターが回り込み、日付などのメタ情報を表示します。Twenty Sixteenの大きな特徴といえるデザインですが、これをなくします。

1カラムではバランスが悪い

Twenty Sixteenの左側フッターは、大きなデザイン上の特徴といえるので、これを消すのは制作者の本意ではないのかもしれません。しかし、この独特のデザインは、特にサイドバーを排除した1カラムにおいて、記事本文と余白が左右非対称になってしまい、たいへんバランスが悪いという印象です（下図）。

[caption id=“attachment_4340” align=“aligncenter” width=“583”]

左右非対称[/caption]

これはやはり、サイドバーがない場合についてはあまり考慮されていないのではないかと考えざるを得ません。元々、この左側にフッターが回り込むこと自体、正直けったいな印象があったので、これは改めようと思いました。

親テーマで、985px以上のcssデザインを無視する

しかし、この修正はたいへん難儀しました。WordPressにおいて、テーマのカスタマイズには子テーマを用いるのが定石ですから、当サイトでもそうしているのですが、子テーマでそれらしいところをどういじっても、この回り込みが解除されません。

親テーマのstyle.cssで言えば、14.4節、すなわちだいたい3400行目以降の、@media screen and (min-width: 61.5625em) { } 内の記述が、この回り込みの実装にあたるはずであり、ここの該当箇所らしきところを上書きすればよいはずなのはわかるのですが、どうにもうまくいかない。

まぁ何か間違えていたのでしょうけれど、結局、面倒くさくなって、この61.5625em以降、すなわち985px以降の変更をすべてまるっと無視するというやり方を採用することにしました。「Twentysixteen カスタマイズ 4 〜最小限度の改変を見極め実施する – Digital Boo」の記事を参考にさせていただき、親テーマのstyle.cssにおいて、以下のような変更を施しました。

`/*14.4 ->= 985px*/ @media screen and (min-width: 99961.5625em) { }  /*14.5 - >= 1200px*/ @media screen and (min-width: 99975em) { } `

参考記事の案をそのまま採用させていただきました。min-widthをありえない値に……つまり、985px以上でなされる変更を、すべて実質的に無視します。したがって、このサイトはPCだろうがタブレットだろうがスマートフォンだろうが、ほとんど変わらないデザインです。

しかし、特にこれで問題がありません。回り込みをただ解除するだけだと、メタ情報が改行されて表示されるなど、また対応すべきことがありますが（参考「WordPressのTwentySixteenを濃い目にカスタマイズした | 男が満足するときＢｌｏｇ」）、これならばそもそも回り込み仕様にならないので、そういった修正も必要ありません。

ただ、やはり親テーマのcssをいじるのは気になるところです。今後Twenty Sixteenのアップデートがあった場合、忘れずに再修正せねばなりません。うーむ。

それはさておき、修正結果は以下です。

[caption id=“attachment_4342” align=“aligncenter” width=“865”]

等間隔[/caption]

左右の余白が等しくなり、等間隔になりました。これで問題ありません。

記事冒頭に記事を投稿した日付の表示

さて、この変更によって、左側に回り込むフッターに表示されていたメタ情報が、記事冒頭で確認できなくなりました。その中でも特に日付は、記事の質を判断するためのもっとも重要な指標の一つです。まぁ、元よりスマートフォンなど表示領域の狭い媒体においては、記事下でしか確認できなかった情報ではあるし（それはそれで問題か）、記事下までスクロールすれば確認できるので、このままでも良いかもしれませんが、私としてはやはり記事冒頭で日付を確認したい。

ということで、template-parts/content-single.phpの、the_content();の前に、以下のような変更を加えました。

`// 追記 echo '[投稿日] '.get_the_date(); if ( get_the_date() != get_the_modified_date() ) { 	echo '
[最終更新] '.get_the_modified_date(); } echo '
';  the_content(); `

ついでに更新した日付も表示されるようにしました。最終更新がいらない場合、if{ }の行を削除すればOKです。

サイドバーをなくしました

Tue, 29 Nov 2016 00:34:34 +0900

以前「サイドバーはないものとして考える」という記事で、今後サイドバーをなくす方針であることを示唆しましたが、今回それを実行しました。ブログを開設して早4年、ずっと2カラムデザインでやってきましたが、これも時流です。しかしこうなると、標準テーマであるTwentysixteenにも色々思うところが。

情報量のバランス

このブログを開設したのが4年前の10月ですから、まるまる4年続けていることになります。我ながらよく続けているものです。

このブログは当初より2カラムデザインを採用していました。それはサイドバーがあるほうが一画面に表示できる情報量が多いからです。いっときは3カラムデザインにすることさえも考えました。しかし、Wikiでもあるまいに、多すぎる情報量は益が少ないばかりかむしろ煩雑な印象を与えると考え直し、やめました。

現在の私は、よくある2カラムデザインでさえ少し煩雑に思っています。サイドバーには一見してそのサイトの傾向をなんとなく把握できるというメリットがあるのですが、それは記事を読む時に必ずしも必要なことではない。しかも、レスポンシブデザインにおいてスマートフォンでサイドバーは下に追いやられるのが普通です。となると、スマートフォンからサイドバーの情報はあまり見られていないのだろうと考えたほうがよい。

スマートフォンからのアクセスは増える一方で、もはや無視するわけにはいきません。このサイトでは、その内容から今でもPCからのアクセスが主流ですが、それでも全体の3割以上が既にスマートフォン経由です。

となると、閲覧者のデバイス毎に見られる情報量に差があるということを意識してデザインしなければならないのですが、それは面倒なことです。また、面倒な割に、得られるメリットといえば、前述したようにサイトのおおまかな傾向を一瞥に把握させられる程度のことです。サイトそのものに興味を抱いてくれた人でいれば、そのようなことをせずとも、グローバルメニューなどを用意することで、十分対応できるように思えます。

1カラムにしました

などと考えた結果、1カラムデザインに変更することにしました。

今後は、メニューの内容を少しずつ見やすく充実させていくことが課題となるでしょう。ひとまず、カテゴリ別の記事一覧ページを作成しました。これの目次を利用することで、今までのカテゴリー欄が果たしていたことはできるはず。まぁ、このページにアクセスするという一手間はあるのですが、このサイトはそんなに重いサイトではないので、よしとします。

WordPressで、投稿記事と同じカテゴリー内の前後数件の記事を一覧出力する

Fri, 18 Nov 2016 00:15:04 +0900

ブログでは、記事下に投稿記事と同じカテゴリーの記事を並べる、ということをよくします。今回は、投稿した記事と同じカテゴリーの前後数件の記事を一覧出力します。要は、投稿した記事と同じカテゴリーでかつ、投稿した日付が近い日のものを一覧出力しよう、ということです。

動機

ブログにおいては、投稿した記事と同じカテゴリーの記事を記事下に一覧出力するのが一般的です。その時、同一カテゴリーの最新記事であるか、あるいはランダムに並べたものであることがたいていのようです。

それはそれでよいのですが、投稿した記事の前後の記事を一覧出力したい、というケースもあるものと思います。たとえば連載記事です。全20回の連載記事を一つのカテゴリでまとめて、記事下に最新記事を10件表示するようにした場合、たとえ第5回の記事のページでも、記事下に一覧出力されるのは第11回〜第20回となってしまいます。しかし、この場合読者に優しいのは、第5回の前後、すなわち第1回〜第4回および第6回〜第10回が一覧出力されることではないでしょうか。

このサイトは、連載記事は多くありませんが、ひとつながりのテーマについて、ある時期に集中して記述することが多いです。したがって、記事下に出力するのは、最新記事よりも、投稿記事の前後の記事であるほうが、より関連性が高くなる可能性が高いと考え、今回の実装に至りました。

完成形

前後合わせて10件の記事を出力します。基本は前5件、後5件ですが、記事数が5件に満たない場合は前2件後8件などとします。合計が10件に満たない場合は、すべて表示されます。また、投稿記事は一覧内に出力しません。カテゴリーが複数ある場合は、すべてのカテゴリーについて一覧出力します。その際、一度出力した記事は他カテゴリー内で出力しません。

2016年11月現在、この記事の下の出力がまさにそうです。一応画像を貼ります（日付出力部分はソースコードに含んでいません。念のため）。

記事一覧出力の例

だいたい上のような感じを目指します。

ソースコード

ソースコードを以下に記述します。使用されている関数の意味や、どのファイルに適用すべきかなどは、より簡単な実装である「WordPress で同一カテゴリの記事タイトルを記事下に表示（複数カテゴリ）」の記事を参照してください。この記事に書いてあることがわかれば大丈夫です。逆にわからないと厳しいと思います。

<?php
// 投稿記事のカテゴリーを取得する
$post_cat_ary = get_the_category();
$post_cat_id = array();
foreach( $post_cat_ary as $post_cat ):
	$post_cat_id[] = $post_cat->cat_ID;
endforeach;
$args = array( 'include' => $post_cat_id );
$categories = get_categories( $args );

// 投稿記事のIDと、除外するIDリストの配列
$post_id = get_the_ID();
$post_id_array = array();

// カテゴリー毎にループ処理
foreach( $categories as $category ):
	// 投稿記事のカテゴリ内で新着から何番目かを確認
	$args = array( 'posts_per_page' => 999, 'category' => $category->cat_ID, 'exclude' => $post_id_array );
	$posts = get_posts( $args );
	$posts_ids = array();
	foreach ( $posts as $post ) {
		$posts_ids[] += $post->ID;
	}
	$post_pos = array_search( $post_id, $posts_ids );

	// post_id_array に投稿記事のIDを追加
	$exclude_ids = array();
	$exclude_ids[] = $post_id_array;
	$exclude_ids[] += $post_id;

	// 投稿記事がカテゴリー内で新着5件内だった時の処理
	$post_offset = $post_pos - 5;
	if ( $post_offset < 0 ) {
		$post_offset = 0;
	}

	// 投稿記事の順番 - 5件 をオフセットして記事一覧を取得
	$args = array( 'posts_per_page' => 10, 'offset' => $post_offset, 'category' => $category->cat_ID, 'exclude' => $exclude_ids );
	$posts = get_posts( $args );

	if ( sizeof($posts) > 0 ):			
		echo '<h2><a href="'.get_category_link( $category->term_id ).'">'.$category->cat_name.'</a> の記事</h2>';
	 	echo '<ul>';
		$count = 0;
 	foreach( $posts as $post ):
			// 投稿記事がカテゴリー内で最新だった時
			if ( $post_pos == 0 ) {
				if ( $count == 0 ) {
					echo '<li>---本記事（カテゴリー内最新）---</li>';
				}						
			} 

			// 記事の表示
 			echo '<li><a href="'.get_permalink().'">'.get_the_title().'</a></li>';
			// 一度出た記事を二度表示しない
			$post_id_array[] = get_the_ID();

			if ( ($post > 0) && ($post_pos < 5) ) {
				if ( $count == $post_pos -1 ) {
					echo '<li>---本記事---</li>';
				}
			} else {
				if ( $count == 4 ) {
					echo '<li>---本記事---</li>';
				}
			}
			$count += 1;
 	endforeach;
	 echo '</ul>';
	endif;
endforeach;
$post = get_post($post_id);
?>

大まかには以下のことをしています。

投稿記事のカテゴリーを取得する($categories)
取得した各カテゴリーについて、次のループ処理を行う
投稿記事が、そのカテゴリーで新着から何番目かを確認する($post_pos)
$post_posから前後5件表示したいので、$post_pos-5 をオフセットしてget_posts()
get_posts()の結果を$postにして出力する
3-5を投稿記事のカテゴリーの数だけ出力
$postを元に戻す

最後はメタデータに影響するのでなにげに重要です。$postをいじるのは行儀が悪いのかしら……。そろそろWordPressちゃんと勉強しようか……。

一度出た記事を表示しないなどの処理もしているので、コードがちょっと複雑になっています。詳細については、コメントでわかるように書いているつもり…です。

いまさら旧ドメインのRSSフィードをリダイレクト設定しました

Wed, 16 Nov 2016 13:45:04 +0900

いまさらですが、旧ドメインのRSSフィードをリダイレクトするように設定しました。ドメインを変更したのが3月の終わりなので、もう8ヶ月ほど経過していることになります。時がたつのは早いですね。

もし前のフィードを残したまま、現在のフィードを追加された方がいたら、フィードが重複するかもしれません。すみませんがご対応お願いします（実際どうなるんでしょう）。忘れていたわけではないのですが、何故かRSSフィードをリダイレクトするという発想がなく、対応が遅れました。

TwitterなどSNSを利用した情報収集ツールが隆盛する昨今、RSSは死んだと言われて久しいですが、私はRSSが好きなのです。だって便利でしょう。ついでなので、それに関わる話を少し。

元々ブログは好きではなかった

かつて、インターネットであらゆる個人が好き勝手なサイトを開いていた時代がありました。トップページがあって、コンテンツがって、閲覧者がぐるぐると見て回るような、そういうサイトです。各種便利なプラットフォームへと移り、いまやめっきり見なくなってしまいましたが、これも時代の趨勢と思うと、寂しい限り。

個人サイト自体がなくなったわけではなく、ブログ形式のサイトはまだまだ生き残っています。このサイトもそうです。しかしブログは一つ一つの記事の独立性が高く、また雑多であるため、従来の個人サイトのように見て回るような感じではありません。どうにも簡素に思え、私は元々ブログがあまり好きではありませんでした。

しかし、技術的なことを調べていると、個人のブログ記事にお世話になることもしばしばです。そのうちに、自分が調べたことも残すようにすれば、自分だけでなく少しは他人のためにもなろうと思い、このブログを作成……したのかどうかはよく覚えていません。なぜこのブログを作ったんでしょうね？私は日記をつけているのですが、当時の日記を見返すと、一言「ブログをつくってみた」とだけ書かれていました。仲の良い友だちとの初めての会話が思い出せないように、このブログのきっかけもまた遠い記憶の彼方です。多分、大したことじゃないんでしょう。あれからもう4年か……。

ブログに便利なRSS、思い出す人

自分でも作るくらいですから、当時より私は多くのブログを巡回していました（巡回という言葉はもはや死語でしょうか）。その際便利だったのが、RSSフィードです。これを使うと、購読しているブログの新着記事を欠かさずに見ることができる。有難いものです。

RSSと聞くと、その開発者の一人であるアーロン・シュワルツ（Aaron Swartz） という人を思い起こします。私と同年代の人ですが、私などとは比較するのもおこがましいほど才気とエネルギーに溢れた人であったようです。しかし、MITの論文ダウンロード事件に関わる裁判の最中、自殺してしまいました。私がブログを始めて3ヶ月後、2013年1月のことです。

彼は26年の短い人生の間で、驚くべき仕事を成しています。彼の残したもの、残そうとしたものについて考える時、変な話ですが、私はブログをできるだけ長く続けようと思うのです。

閑話でした。

サイドバーはないものとして考える

Wed, 09 Nov 2016 23:49:04 +0900

2023-10-28追記：どうせこのブログほとんどはPCのアクセスですし、サイドバーは有用な情報源だというのが今の考えですね。

当サイトは2カラムのレスポンシブデザインで、PCなどで見るとサイドバーが表示されます。モバイルファーストだのスマホシフトだのと喧しい昨今ではありますが、当サイトは記事の性質故か、今でもPCからのアクセスのほうが多いです（6割弱）。しかし、今後モバイル比率は上がるだろうということや、検索でたどり着くパターンが多いことなどを勘案すると、サイドバーはないものとしてサイトを構築していったほうがよいのかなと思う今日この頃です。

スマホだとサイドバーは追いやられる

当サイトはWordPressの標準テーマであるTwenty Sixteenを採用しておりますので、基本は2カラムのレスポンシブデザインです。スマートフォンで閲覧すると、サイドバーの情報は記事下に追いやられます。一応情報量は減っていないということになりますが、果たして記事下にある記事一覧などにどれだけの意味があるのだろうとかと思います。実際、ほとんど見られていないのだろうな。

モバイルファーストとかスマホシフトなんて言われて久しく、Webの利用の7割がスマホである、なんてまことしやかに言われていたのがもう去年のこと（参考：「ネット利用の70％はスマホ／ECはサービスによってPC利用が多いものも【ニールセン調査】：MarkeZine（マーケジン）」）。当サイトは記事の性質故か、今でもPCからのアクセスのほうが多いですが（6割弱といったところ）、モバイルからの比率は確かに上がっているようです。

つまりと、サイドバーの情報はサイト閲覧者の多くに見られていない可能性が高い。したがって、サイドバーありきの設計には問題がある。

サイドバーの必要性

また、そもそもサイドバーは必要なのかという疑問もあります。当サイトの訪問者はほとんどが検索エンジン経由ですが、直帰率は8割超えですので、ほとんどの人は1ページだけ見てさっと立ち去っています（ちょっと悲しい）。サイドバーはサイトの構造を端的にナビゲートしてくれるものですが、あまり機能していないようです。

まぁそれでも、サイトを回ってくれる人もいるようですし、また私自身がサイト内をよくうろついているので、ナビゲートバー的なものはあると良いとは思います。しかし、それであれば何もサイドバーに拘る必要はありません。たとえばトップにメニューバーをつけても同様の役割が期待できる、というかそちらのほうが適しているでしょう。

というわけで、私の中でサイドバーの存在意義自体が、だいぶ揺らいでいます。

ただ一点、私が明確にサイドバーのメリットだと思うことは、一瞥してそのサイトのことがある程度把握できることです。カテゴリの一覧や人気記事を見ればサイトの傾向が掴めるし、新着記事を見れば更新頻度がわかるし（まだ「生きている」サイトなのかどうかは大事ですね）、交流の盛んなサイトであれば、最新コメントも意味があるでしょう。

つまり、そのサイトの今を手っ取り早く知る、知らせるのに、サイドバーは適しているのではないでしょうか。私も興味を持ったサイトはサイドバーをざっと眺めます。管理人の立場からしても、状況をざっと把握できるサイドバーは便利です。

とはいえ、ポータルサイトや情報サイトでもない個人の雑記ブログに必要かどうかと言われれば、まぁ不必要かなぁと思います。全員に確実に見られるならともかく、それなりの画面を持った媒体にしか見せられないようでは、ちょっとねぇ。

まぁ、メリットがゼロではないので、シンプルなつくりの当サイトは比較的レスポンスも良い部類に入ると思いますし、邪魔にはなっていないと思いますから、当面サイドバーを置いておくつもりです。でも、折を見て1カラムにするかもしれません。

サイドバーはないものとして

つらつら書いてきましたが、少なくとも、2016年現在、サイドバーありきの設計はよろしくない、とはハッキリ言えそうです。サイドバーはないものとして、サイト作りをすすめていったほうがよいのだろうな、などと思う今日この頃です。

具体的には、メニューバーを拡充させていくつもりです。とりあえず、新着記事一覧を作ってみました。あとは閲覧数の多い記事とか、話題別の案内があればよい感じですかね。

そもそも、今時は一つのサイトを回るということ自体があまりないんんだろうなとも思いますが……それを言っては身も蓋もない。いや、個人サイトが難しい時代になりましたね。

ところで当サイト含め、Web上のサイトのほとんどはタブレットが一番見やすいと思います。でも、タブレットからのアクセスが一番少ないんですよね。数の問題なのでしょうけれど。

参考記事

個人的に参考になった記事です。

いい加減、ブログにサイドバーはいらないのでは？というご提案 | やわなべ.net…うちと同じような感じで参考になる
左サイドバーと右サイドバーの歴史的背景 | xxxx7…サイドバーはトップページ文化の名残という指摘になるほど
これからのWebサイトは極力サイドバーやヘッダーは無くす方向で - ポジティブ心理学研究所…ヘッダーさえ要らないという主張

結局サイトをhttps対応させました

Fri, 04 Nov 2016 00:30:19 +0900

「なかなかhttps対応のモチベーションが上がらない」では面倒でいまいちやる気にならないと書いていましたが、結局https対応させました。どうせいずれやるつもりではあるのだし、それだったら早いほうがよいか…と。アドレスバーのプロトコル部分が緑色になり、かっこよくなりました。

https対応することに意義がある

https対応とはつまりサイトの暗号化です。これにより、盗聴や改竄を防ぐ意味合いがあります。最近はメールアドレスやクッキーなども個人情報と考えられているようなので、別にクレジットカードの登録をしたりするわけでもない当サイトでも、https対応の意味はあります。ついでにhttp/2に対応させることで、速度も上がるかもしれないしね。

まぁ個人サイトの場合、安全性よりは、https対応しているということそのものが訪問者に対するメッセージになる、という意味合いが大きいかもしれません。私自身、他のサイトを覗いた時、https対応されていれば「おっ」と思います。アドレスバーの緑色もカッコイイですし。

https対応そのものは楽

個人サイトですから、たいした設定をしているわけではありません。そういう場合、対応は楽です。

証明書の発行
Webサーバーの設定
WordPressの設定

証明書の発行は、有難いことに無料でやってくれる「Let’s Encrypt - Free SSL/TLS Certificates」を利用しました。スクリプトを用意してくれているので手順も非常に簡単です。

証明書を自動で発行するスクリプトcertbotのインストール手順は「Let’s Encrypt の使い方 - Let’s Encrypt 総合ポータル」によります。certbotの使い方は「Certbot」を参照。

SSLの設定方法については、Apacheかnginxで項目が異なりますが、どちらも色々なブログで解説されております。当サイトはnginxを使用しており、私が参考にさせてもらった記事は「自社WordPressサイトを完全HTTPS化しました。 – 稲葉サーバーデザイン」です。WordPressでサイト構築をしていることは、https化についてはほとんど影響がないように思います。

せっかくなので、http/2にも対応させました。しかし、iPadからアクセスするとhttp/2で通信されるのですが、Mac + Chromeでアクセスするとhttp/1.1のまま……何故……まぁとりあえずこれは置いておこう。

https対応後の対応は割と面倒

面倒なのは、その先です。httpとhttpsでは、Web上においては別のサイトということになります。したがって、アクセス解析やらアフィリエイトやら、登録し直しです。それが面倒臭い。ソーシャル・ブックマークのようなものを重視している人は、それがリセットされるのもつらいでしょう（回避手段はあるようですが）。Amazonアソシエイトなどは再審査です。当サイトはドメイン移転などもしているので、初めてではありませんが、何度やっても緊張します。慣れません。

これらの対応が面倒で及び腰になっている人、けっこう多いんじゃないかと思います。

Amazonアソシエイトでひっかかる

（2018/11/04追記：いまどきはAmazonアソシエイトの再審査は必要ないそうです。当時ももしかしたらいらんかったのかしら…）

そして、Amazonアソシエイトの再審査で引っかかりました。といっても、サイトの内容に問題があったとかではなく、サイトが閲覧できないため、審査できない、というものでした。

最初はたまたま作業中ドンピシャにアクセスがあったのかと思ったのですが、再度依頼したところ、画面が真っ白になり閲覧できない状態である、と。さすがにおかしい。SSL化の影響だろうか？

しかし、手持ちのデバイス（Mac,Windows,iOS,Android…）を総動員して、インストールしているブラウザ、さらにケータイ回線なども使って片っ端から試してみたのですけれど、どうにも異常が見当たらない。考えづらいが、ひょっとして暗号化のプロトコルが厳しくて復号化できない？などとも思い、設定を変更し、Webサーバーを再起動し、祈るような気持ちで再度依頼。

すると、別のブラウザ（IE）では閲覧できたようで、無事承認をいただけました。しかし、どうも旧環境ではやはり閲覧できていないことが言外に伺え、サイトに何か問題があるのか多少不安を残した結果です。どうなんでしょうね。アクセスは特に変わらずあるようですが……。

ついでにAMP

せっかくだからと、WordPressのAMPプラグインを導入して、AMPに対応させました。AMPとは、Accelerate Mobile Pageでその名の通り、高速なモバイルページの表示を実現する規格で、Googleが推し進めています。これに対応させると、AMP対応ということで、検索で特別枠で表示されることがあり、サイト運営者から関心を集めています。

自分で勉強して実装するとなると手間ですが、WordPressでは簡単にAMP対応させられるAMPプラグインを開発してくれている人がいます。ただ、そのAMPプラグインはだいぶ前に一度試したのですけれど、実際に使って見るとエラーが頻発するので、現状使い物にならないと判断しやめました。あれからしばらく、今はどんな感じかなと再度導入してみたところ、今度はまったくエラーが出ない。これならば使えそうだということで、適用しました。有難い。

実際にどれだけ効果が出るのかは未知数ですが。

追記：アイキャッチ画像が設定されていないと、Search Consoleで怒られます。image必須なんだそうです。indexはされましたが。アイキャッチって好きじゃないんですよね。。。そのうちサイトのイメージ画像を頑張って作り、一括設定することはあるかもしれませんが、当面放置です。

趣味じゃないとつらいよね

というわけで、https（およびAMP）対応したわけですが、やはりこういう作業はなかなかたいへんです。今後のメンテナンスも煩雑になります。証明書関係でサーバーの引越しの一手間が増えました。サイト運営は趣味でないとやれませんね。

まぁでも、なかなか楽しいものです。趣味としては金がかからない、むしろ金銭だけ見れば多少なりとも広告収入があるのでプラスだから上等じゃないでしょうか。かかるのは時間ばかりですが、そこはそれ、趣味なので。

ページ速度改善のためnginxで圧縮を有効にする（WordPressでも有効）

Sun, 30 Oct 2016 13:21:34 +0900

PageSpeed Insights

Googleのページ速度測定ツールとしてPageSpeed Insightsがあります。これを実行すると、特に速度対策してないサイトではたいてい「圧縮を有効にする」ようにと注意されます。他にも複数注意されますが、圧縮は簡単な割にスコアが大幅に上がりやすい項目です。また、WordPressなど使っていると、ソースコードをいじるのも一苦労ですが、この項目については簡単に実行することができます。

本記事では、nginxで圧縮を有効にするやり方についてメモします（Apacheにあらず）。

ページ速度の測定と改善

ページ速度の測定にはいくつかのスタンダードがありますが、そのうちの一つがGoogleのPageSpeed Insightsです。これを使ってみた所、当サイトのスコアはPC版が69点、モバイル版が57点でした。これはよくないスコアで、いわゆる赤点でしょうか。まぁ特に速度改善の対策らしい対策はしていないので、そのことを思えばこんなものなのかもしれませんが。

色々とGoogleから注意されましたが、その中の「圧縮を有効にする」を実行したところ、PC版が83点(+14点)、モバイル版が66点(+9点)となりました。及第点とはいきませんが、赤点は脱することができたようです。

追記：どうやらこの調整をしていたときはサーバーがたまたま重かったのか、応答速度が遅く、その後再測定すると86点/69点に。まぁ大して変わりませんが。

WordPressは大きなソフトウェアなので、自分でさっといじれるところが少なく、Googleからの有難い助言も、すぐ実行できるものばかりではありません。その中でこの圧縮は、nginxの設定だけで済み、かつ大幅なスコア改善が期待できる項目です。是非ともやっておきたいですね。

圧縮を有効にするとは

圧縮を有効にするとは、コンテンツを圧縮して転送するデータ量を減らそうというものです。基本的に、Webサーバーのソフトの設定で対応することになります。Apacheであったり、nginxであったりです。いずれも、設定ファイルにちょっと付け加えるだけで、gzipで圧縮する設定にすることができます。

使用するうえで、注意しなくてはいけないこともあります。圧縮処理を行うため、CPUの負荷は上がるという点です。また、処理する時間がかかります。したがって、なんでもかんでも圧縮すればよいというものではないといえます。たとえば小さすぎるファイルや、jpeg画像のように既に十分圧縮されているものは、圧縮の効果が薄いどころか逆効果になるかもしれません。また、もしアクセスが多すぎてCPUに余裕がない場合も、この設定は藪蛇かもしれません（そんな心配してみたいですね）。

とはいえ、それが定量的にどれくらいなのかは難しい問題です。その難しい問題を泥臭く頑張るのことをチューニングというわけですが、今回はあまり頑張らず、まぁこんなものだろうという設定にします。

nginxでのやり方

nginxでのやり方をメモします。nginxの設定ファイルをいじりますが、設定ファイルの基本は「nginxの設定ファイル nginx.conf の読み方超入門」という記事に書きましたので、設定ファイルの場所や、コンテキストやディレクティブ、MIMEタイプといった用語がわからない場合はご参照ください。

gzip圧縮転送として、gzipディレクティブを使います。これはhttp,server,locationコンテキスト内で使えます。locationコンテキスト内での使用例を以下に示します。

` location / { try_files $uri $uri/ @wordpress; # gzip圧縮 gzip on; gzip_min_length 1k; gzip_types text/css text/javascript application/x-javascript application/javascript application/json image/svg+xml; gzip_disable "msie6";  } `

gzip圧縮以下が適用例です。一つずつ見ていきます。

gzip on;により、gzip圧縮転送を有効にします。

gzip_min_length 1k;で、圧縮対象の最小のファイルサイズを指定します。この場合1kB。なお、デフォルト値は20です。

gzip_typesは、圧縮を有効にするファイルの種類を指定します。text/htmlについては指定せずとも圧縮が有効化されます（入れるとダブってるよと警告されます）。なお、text/htmlやtext/cssはMIMEタイプと呼ばれます。MIMEタイプとは、簡単に言うとWeb上における拡張子みたいなものです。たとえば、.cssはMIMEタイプにおいてtext/cssと表現されます。この対応は、/etc/nginx/mime.typesで定義されています。

gzip_disableは、圧縮を無効にするユーザーエージェントを指定します。特定のブラウザについては圧縮しないとか、そういうことです。“msie6"は特別な符号で、ME IE 6 SV1未満について最適化されています（これらのブラウザは圧縮の実装に不具合があるそうです）。もっとも、MS IE6を使ってこのサイトを覗く人はほとんどいません。今月は全体の0.015%ほどあったようですが、果たしてちゃんとこのサイト表示はされているのでしょうか。

以上の設定を、適切なところに配置します。WordPressを使っている場合、locationコンテキストがphpとそれ以外で分散しているかもしれませんが、その場合両方に配置します。serverコンテキスト内に配置してしまうのが手っ取り早い？

設定が完了したら、設定ファイルを再読込です。CentOS 7の場合（つまりsystemdの場合）は以下。

`$ sudo nginx -t -> 設定ファイルの文法が正しいことを確認 $ sudo systemctl reload nginx.service `

以上。

gzip圧縮したファイルを用意して転送するgzip_staticについて

さて、gzipをonにした場合、毎回圧縮処理が行われますが、これは前述したとおり負荷の増加と処理時間というデメリットがあります。それで、この処理を減らすために、圧縮したファイルを用意しておいて、それを使うという方法があり、nginxにおいてはgzip_staticというディレクティブでその機能を有効化できます。しかし、これは標準的な機能ではなく、使用するには、自前でnginxをビルドしなくてはなりません（コンパイルオプションは–with-http_gzip_static_module）。

したがって、ここではこの機能は利用しないものとします。興味がある人は各自調べてください。

効果

ところで、この効果ですが……確かにスコアは上昇したものの、体感としてはあまり変わらないですね。ただ、見やすいページとしてGoogleには多少なりとも好印象を与えられるようになった……のではないかな？多分。

他にも修正せよとされる項目がいくつもあるのですが、WordPressに依存するところも多く、おいそれとは手が出しづらい。WordPressは便利なのですけれど、個人のブログサイトにはちょっと複雑過ぎるかもしれません。

今回の設定には、「nginx実践入門」を大いに参考にさせていただきました。この本、一通りまとまっていて便利です。技術評論社のサイトでも電子データが直販されています。

nginx実践入門 | Gihyo Digital Publishing

DRMフリー（厳密にはソーシャルDRM）なので、好きなデバイスとソフトで読めてオススメです。

LivedoorブログからWordPressに移行してサイトの回遊率が落ちた

Mon, 24 Oct 2016 01:09:48 +0900

このブログは長らくLivedoorブログでやってきましたが、今年7月下旬に晴れてVPSのWordPressで構築した自前のブログに移行することができました。概ね満足しているのですが、移行してからのここ三ヶ月ほどのデータを見るとサイトの回遊率は落ちてしまったようです。この場合WordPressというより、標準テーマのTwentySixteenをだいたいそのまま使っていることがポイントでしょうか。コンテンツの見えやすさの問題か、それとも広告の問題か、などと考えていますが、正直なぜかはよくわかりません。

ページ/セッションとセッションあたりの平均時間が共に下落

当ブログは、検索エンジンからの流入を基本にしたブログです。Livedoorブログ時代、Googleアナリティクスによると新規セッション率は3割くらいになっていて、そんなにリピーターばかりなのかと不思議でしたが、独自ドメインに移行してからのデータを見ると、8割強が新規さんで、こちらのほうが実情に近いものと思います。

恐らくユーザー層はあまり変わっていないでしょう。記事が変わったわけではありませんし。セッション数は移行してしばらくは微減していましたが、最近は微増の傾向にあります。それがサイトの改装と関係があるのかはわかりません。

明らかに変わったのが、ページ/セッションです。Livedoorブログ時代は、だいたい1.35-1.45くらいだったのが、WordPress移行からは1.25-1.35になりました。これはセッション数に関わらずそんな感じです。ちょうど移行した日から、わかりやすくその傾向が続いています。セッションの平均時間も、1分20-30秒くらいだったのが、ここ一ヶ月は1分を切っています。1分切りはちょっと寂しいなぁ。

ということで、サイトの回遊率が下がったのは確かなようです。

原因はよくわからないが…

ただその原因がよくわかりません。記事の内容そのものは変わらないので、レイアウトによる影響ということになるとは思うのですが…。

現在のレイアウトは、WordPressの標準テーマであるTwenty Sixteenを元に、少しだけ手を入れた状態です。前のブログでも見やすさには気を使っていたので、特別見やすくなってはいないでしょうが、別に見づらくもなっていないと思うのです。記事下には前と同じく同カテゴリの最新記事を並べていますし、少なくとも情報量という点では変わらないはずなのですが。

が、現に下がっているので、見づらくなったのかもしれない、と考えるのが一つ。そしてもう一つ考えられるのは、広告です。

モバイルのおかげで広告収入は上昇したが

実は、回遊率は下がったものの、広告収入は多少上がりました。といっても、当サイトの広告収入は月あたり数千円もないので、たいして変わらんだろうと言われてしまうとそうなのですが…（時給に換算してはいけない）。それでも、少ないなりにハッキリと上がったのです。

上昇した主な原因は、モバイルのGoogle AdSenseです。LivedoorブログはPC版は比較的自由にやらせてもらえるのですけれど、モバイル版についてはほとんどレイアウトをいじらせてもらえないうえに、記事上と記事下の一番良いところにLivedoorの広告が強制的に入れられます（Livedoorはそこで稼いでいるのでしょう）。これ以上広告をつけるのも嫌だったので、モバイル版では記事中以外に広告をつけませんでした。

しかし、時代はモバイルです。当サイトは技術系の記事も多いためか、今でも比較的PCからのアクセスが多いブログですけれど、それでも全体の3-4割がモバイルです。モバイルからのアクセスは今は、記事下にGoogle AdSenseを入れています。単純に、ここに入れた分の収入分上がった、というところでしょうか。

さて、この広告収入というのは皮肉なもので、サイトからの離脱とセットなのですね。広告収入はサイト運営者にとって、モチベーションの一つなのですけれど、回遊率と広告収入は必ずしも比例しないというジレンマがあります。特に記事中の広告は、記事を見て、最後まで読まれることなく離脱されたということを意味するので、微妙なものです。

そんなわけで、回遊率が下がった分は実は広告による離脱になっていた、という可能性もあります。

何か対応するつもりはないが、興味深い

とはいえ、私自身は前述したとおりサイトの移行には概ね満足しており、回遊率が下がったことを多少残念に思うところもありますけれど、それをもってサイトを大きく変えようとは思っておりません（飽きたら変えるかもしれませんが、基本的にWebデザインにはあまり興味がないので面倒臭い）。

当サイトは、あくまで私にとって必要な情報をメモ、共有したり、私見を述べたりすることを目的としたブログです。サイトのアクセスは、増えれば嬉しいですけれど、そこに熱意を傾けることはないです。ただ、レイアウトの変更が目に見えて回遊率に繋がったという事実が興味深い。本当に変わるものなのですねぇ。

なかなかhttps対応のモチベーションが上がらない

Mon, 17 Oct 2016 22:36:16 +0900

最近、会社のサイトをhttpsに対応させました。もちろん私の本職ではありませんが、零細企業なので一人で色々やらねばなりません。思っていたよりも簡単にできたので、当サイトもhttps対応しようかとも思うのですが、どうにも面倒で、なかなかモチベーションがあがりません。

個人サイトレベルならばhttps対応そのものは楽

当サイトはWebサーバーでnginx、サイト構築にWordPressを利用しています。どちらもhttpsの利用はちょっと設定ファイルをいじるだけで適用できます。既に十分な情報がWebに流れているので、あまりひっかからずにできました。

SSL証明書の取得も、Let’s Encryptのおかげでコストをかけずにできました。費用がかからないというだけでなく、導入用のソフトウェアcertbotがたいへんよくできいるために導入も非常に楽で、あまりにも楽なので逆に心配になったほどです。よくできていますね。

アドレス変更にまつわる対応が面倒

面倒なのはhttps対応の後です。httpsとhttpでは別サイトとして扱われますから、たとえばAmazonアソシエイトなどでは別途承認手続きが必要になりますし、GoogleのSearch Consoleなども新たにサイト登録しなければなりません。

いや、それだけといえばそれだけなのですが、それが面倒臭いです。特にAmazonの再審査は心的負担が大きい。当サイトなどは割合硬派な部類だと思いますし、落とされたりなどはないと思いますが、それでも審査というのは気が重いものです。

httpsの重要性を説くページがhttp

https対応にあたって様々なページを参考にさせていただきました。それで一つ気になったことがあります。httpsは重要であるとか、今後必須というような記事はよく見受けられたのですが、それらのページがhttpであることもさほど珍しくなかったことです。

それはhttps対応の面倒さという現実が如実に表れていると思います。当サイトのようなひねた要素のまるでない個人サイトでさえ、ちょっとばかり気が重いですし。まして大きなサイトとなればなおさら、導入の障壁は大きいことでしょう。

その割に、https対応で目に見えて受けられる恩恵というのはちょっと思いつきません。速度が早くなるでもないし、セキュアになると言われても、通販サイトでもないしねぇ。当サイトにもコメント欄はあるので、まぁしたほうがよいのかもしれませんが……。

そのうち対応しようとは思うが

とはいえ面倒臭いということは安全性を高めない言い訳にはならないですし、そのうち対応しようとは思っています。どうせ対応するのであれば早いほうがよい……のですが、うーん、なかなかねぇ。

記事のメンテナンスもなかなかたいへん

Sun, 11 Sep 2016 01:56:04 +0900

けっこう、過去の記事を修正することがあります。内容が古くなっていたり、間違えていたりしていることに気づいた時は、その都度修正します。これがなかなか、たいへんです。

Raspberry Pi周りの内容が古い

当サイトで比較的多くアクセスをいただいているのは、Raspberry Pi関係の記事なのですが、ちょうどいじり始めたばかりの去年の記事が多く、今見ると内容が古かったり、不正確だったりするところが見受けられます。

ちょこちょこと直してはいるのですが、特にRaspbian Jessieに変更してから、systemd採用の影響でUART周りの設定方法が大幅に変わったことや、Raspberry Pi 3になってハードウェア的にも変更があったことから、今や記事内容が古いものがけっこうあります。

まぁこれは技術系の記事ではどうしても避けられないところで、実際Webで情報を集めて混乱するのは、新旧のバージョンでのやり方が混在して集まるところです。特にIT関係は情報の陳腐化するスピードが早く、なかなか追いつけません。

気づいたところはなおしているが

当サイトの一番の読者は私自身ですので、記事内容の間違いに気づいた時点でなおすよう心がけてはいますが、やはりすべての記事をチェックできているわけではありませんし、時間も限られていますから、なかなか厳しいのが現状です。

また、勉強したこと、知ったことをそのまま書いているので、情報が古くなったとかではなく、そもそも間違えている、ということもよくあります。まぁ、ハッキリと間違えているのであればなおすのですが、間違えているとは言い切れないが正しいとも言えない、なんとも微妙だなぁという記述ついては（当サイトのほとんどの記述はそうかもしれない！？）、あえて放っていることも多いです。

初学者の理解に基づく記述は、不正確でも同じ初学者にとって正しく厳密な記述よりわかりよいことが往々にしてあります。少なくとも書いた時はそれが正しいと思って書いたわけですし、まぁ明確に間違いでなければ、そのままでも不誠実ではなかろう……などと考えているものの、気になるところはちょこちょこと修正してもいます。わかりやすく正確なのが一番に決まっていますが、それはなかなか、難しい。

もし、読んでいておかしいなと思う所があれば、優しく指摘していただけると幸いです。

Amazonアソシエイトで生成されるURLがいつの間にかhttpsな感じに

Wed, 31 Aug 2016 04:04:35 +0900

ここ一ヶ月くらいのことですが、Amazonアソシエイト・プログラムの公式ツールで生成される広告用のURLが、突然様変わりしました。最初不具合もあって、どういうことだと生成されるURLをよくよく見てみると、httpsになっていたり、プロトコルを指定しない形式になっていたり。へぇ。公式では長らくhttpsに対応していなかったAmazon広告、しれっと対応しました。Web全体が少しずつhttpsに移行していますね。そろそろ、このサイトもhttps化の時期かなぁ。

突然のhttps対応

ある日いつものようにAmazonのツールバーでアフィリエイト用リンクを生成しようとすると、ツールバーがえらい様変わりしていました。以前は、ツールバーでリンクを生成することを選択してから、どのような形式にするか（テキストのみか、テキスト+画像か、画像のみか）選択する2ステップが必要だったのですけれど、今回の改訂で、リンクの生成を選ぶステップがなくなり、最初から形式のみを選ぶようになっていました。文字も大きく見やすくなっており、おお、改善されたな、と。

が、残念なことに画像のみのURLが最初不具合で使えませんでした（当サイトではあまり使いませんが）。どうも、URLに日本語がそのまま使われていたことが問題だったのかな。こんなとこでも、マルチバイト文字の壁です。天下のAmazonでも、グローバル対応はたいへんなのですね。とはいえ、一発でわかりそうなのに、テストはけっこういい加減なんでしょうか…。

というわけで、しばらくは使わなかったのですが、数日するとちゃんとなおっていました。現在は日本語がなく、また長ったらしいアルファベットの文字列になっています。他にどこが変わったのだろうとURLをしげしげ眺めていると、画像のみの場合のURLが、httpsから始まっている。ほう。そして、画像+テキストのURLは、httpもhttpsもつかず、つまりプロトコルを指定せず、いきなり//から始まっている。この場合、httpsが使えればそれが優先されるはず。つまり、https対応にした、のかな。

公式のセントラルページを見ると、以下の様な文言がお知らせにありました。

Amazonアソシエイトプログラムからのお知らせ

【2016/08/19:リンクURLに関するお知らせ】現在、Amazon.co.jp へのリンクURLを生成いただく際は、http:// から始まるURLではなく、https:// から始まるURLを推奨しております。変更する際は http:// を https:// に置き換えるだけで機能いたします。なお、http から始まるリンクURLは今後も有効に機能いたしますので、過去に生成したリンクを変更する必要はございません。

対応したようです。

アフィリエイトはSSL化の壁だった

アフィリエイトのリンクは、SSL化を目論むサイトにとって一つの壁でした。調べてみると、ここ一年くらいでも以下のような記事があります。

AmazonアソシエイトのリンクはSSL対応にできるのか調べてみた。サポートからの回答も紹介。｜あしたもまたひがのぼる！
ブログをhttps化にしたけれど導入できる広告がアドセンスだけだった - SAKULIFESAKULIFE」（記事の補足によるとA8.netも7月末に対応したとのこと）

しかし、Webの潮流はSSL化。各所で少しずつ対応が進んでいますが、今回のAmazonの対応は大きいのではないでしょうか。

そろそろ変えどき？

今回の変更を受けて、当サイトでもAmazonアソシエイト・プログラム関係のURLは一通り変更しました。画像のみについては（ほとんどないけど）httpsから始まるように、画像とテキストのあのちょっとダサ目な縦長インラインフレームのやつはhttpなどのプロトコルを指定せずいきなり//から始まるように。

以前のLivedoorブログ時代は、全記事の文字列を変更するには、記事のインポート・エクスポートが必要でけっこう大仰だったのですけれど、WordPressではプラグインでさくっとできるし、プラグインを使いたくなければデータベースを直接叩けばよいので楽ですね（この程度であればプラグインの利便性を享受してよいと思いますが）。Livedoorブログはモバイル用サイトが酷かったし、WordPressでサイト構築してよかったと思います。

まぁ、変更せずとも以前のhttpなアドレスでも機能するのですが、このサイトもいずれはhttpsに対応しようと目論んでいまして（無料の証明書発行サービスもあ機能しているようですし）、その時はAmazon関係のリンクもhttps対応させる必要がありますから、気づいた時にやっておいてしまうほうが、後々楽でしょう。

別に、こんな泡沫サイトでWebの最適化なんて大仰なことを考えているわけではありませんけれど、httpだとChromeブラウザでアドレスの頭に丸で囲んだiがつくのが、ちょっと嫌でして。informationのiなんでしょうか。あとhttpsの文字色の緑がカッコイイですよね。ま、個人サイトはこんなものです。あはは。

使っていないドメインに利用制限…XYZとムームードメイン

Tue, 09 Aug 2016 17:30:58 +0900

以前ムームードメインで取得したXYZドメインが、また利用制限にかかりました。しかし……このドメイン、もう使っていないのです。だから、問題の起きようもないと思います。となると、やはりレジストリ側の問題ではないのかな、と思います。

元々問題があったとは思えない

一度利用制限にかかったことのあるドメインなので、曰くつきということになるのでしょうけれど、それにしたって、元から問題があったとは考えづらいのです。フツーの個人サイトを運用していただけですから。

私の窓口は、取得元のリセラーであるムームードメインです。しかし何が問題なのか聞いても、ムームードメインは教えてくれません。レジストリの判断というだけです。確かにそうなのでしょう。しかしそれではわかりません。私の目から見て何も問題はなかったので、結局何も直さなかったのですが、それで再び制限がかかることはひとまずありませんでした。

サーバーごと削除した後に何故かまた制限

ただ、嫌な思い出のあるドメインなので、できればもう使いたくなくて、復帰後も新アドレスへのリダイレクトしかしていなかったものを、それももうよかろうと、最近、サーバー毎削除しました。つまり、今は何にもない跡地です。にも関わらず、先ほどなんとなく今どうなってるのかなとwhoisしてみたら、またserverHoldにかかっていました。なぜ……。使っていないのに、どうしたら問題が起きるのか。。。

よくわからないのが、リダイレクト中、つまり稼働中は普通に使えていたのに、何故にサーバーを消してから、つまり何もなくなってから利用制限がかかるのだろう、ということです。これは偶然なのか、そうでないのか、なんとも判断がつきません。逆ならわかるのですが。

私としては、恐らくサーバーの稼働状況との因果関係はないのだろうと、つまり、レジストリ側の判断に問題があるのではないか、考えています。そして、第一義的にはレジストリの問題とは思うものの、ムームードメイン経由で取得したドメイン、ということも考慮しないわけにもいきません。ムームードメイン経由で取得したドメインが巻き添えで制限された、という話も調べていたらでてきましたし、また特定のレジストラ経由でXYZドメインが何故か制限された、という話も海外のスレッドではちょくちょく見られました。推測ですが、巻き添えなのかなぁと思います。

せめて、何かしら説明してくれたらいいのですけれど、きっとムームードメインは今回もレジストリの判断、としか言わないでしょうし、どうせ使っていないドメインですから、いまさら嫌な思いをしながらやりとりする気力もありません。

こういうことがあると、ムームードメインからの移管も考えてしまいますが、こういったことはどこのレジストラやリセラーでもありそうにも思えます。移管の手間も考え、当面は様子見です。ただ、こういう次第なので、このXYZ + ムームードメインの組み合わせはもう人には到底オススメできません。XYZのドメインをムームードメインで取得することをお考えの方には、参考にしてもらえればと思います。

WHOISに個人情報を開示すれば、こういうこともないのかもしれません。でもこのご時世に、個人サイトでそれは色々厳しいものです。さすがに本名・住所は、ちょっとね。最初の頃はそれでもよかったのでしょうけれど、これだけインターネットが一般的になってしまうと、悪意というのはどこに潜んでいるのかわかりませんから、なかなか。要は連絡が取れたらいいので、メールアドレスくらいでいいと思うのですけれど。

適当なアイキャッチ画像なら無いほうが良い

Mon, 25 Jul 2016 22:59:12 +0900

（2023-10-28追記）時代は変わって適当ながらAIでアイキャッチ画像を作れる時代になりもうした。ということでこれからはどんどん適当なアイキャッチ画像を入れてまいる所存。

ブログではよくアイキャッチ画像というものが使われます。ページを開くと、大きな画面でおにーさんやおねーさんが喜んでいたり困った顔をしていたりする、しかし記事内容とは特に関係がなかったりするアレです。ブログの運営において、多くのサイトで推奨されているものですが、アレの使い方はなかなか難しいところがあると思います。

記事の理解を助けない画像

文章だけで表現できることは限られていますから、色々なメディアを活用して閲覧者の理解を助けるのは良いことです。HTMLの面目躍如といったところでしょうか。まぁ、用意するほうにしてみれば、かなり労のかかることなので、私は必要最低限の画像を貼る程度です。

しかしながら、それが記事の理解を助けるどころか、なんら記事との関連性のない画像が、昨今よく見受けられます。先ほども、調べ物をしていたら、頬に手をあてて「しまった！」という顔をした女性の画像がデカデカと貼られており、びっくりしました。ある作業について「やってしまいがちな失敗」をまとめられた記事だったので、まぁそういうイメージを伝えようとしたのでしょうが。

待たされるし、スクロールが面倒臭いし

逆に言うと、その程度の意味しかありませんから、特に必要のない画像だと思うのです。昨今、クライアント側のコンピュータのスペックはだいぶ良くなりましたが（安PCで大量のタブを同時に開くと厳しいですけど）、サーバーの処理能力、そしてネットワークの帯域はいまだ十分とは言えません。画像の表示で待たされて、なんだなんだと思っていたら、そんな意味のないでっかい画像がポンと出てきた、となると、その画像は不必要であるどころか、邪魔とすら感じます。また、そんな画像をしげしげと眺める趣味もありませんから、瞬時にしてスクロールをするのですが、これも何度も続くとイラつきを感じることがあります。

サムネイルである種のカテゴリのイメージを伝えるにはよいか？

私にはリソースの無駄に思えてならないのですが、聞くところによると意味はあるらしい。まぁ、意味のないことを手間暇かけてやりたがる人がそんなに多いとは思えませんし、そうなのでしょう。実際に数字を上げている人はいないものかと思って探してみたら、「アイキャッチ効果人は人の顔に自然と目がいく | ブログ集客法ブログなら集客できる」の人はPVが2から3.2の1.5倍になったと言っています。つまり、サイトの回遊率が上がったということでしょう。

それは、あるかもしれません。アイキャッチ画像は記事の中でも特別な位置づけにあり、スクリプトで利用しやすいという特徴があります。したがって、記事に込められた感情の一端を表現しているだけのものであったとしても、サムネイルで一覧表示したとき、その記事の感情的なカテゴライズを容易にし、また人目を惹き付けやすい、考えられることですし、理解できます。年収が低くて息が臭いおねーさんとか、有名ですよねぇ…あれは確かバナー広告でしたっけ。

つまり、アイキャッチ画像は、本でいうところの表紙で、広告の役割を担っている、と考えればわかりよいか。本屋で、その本を手に取ってもらうためのもの。だから、その記事のためというよりは、他の記事にアクセスしてもらうための呼び水……まぁ、わかります。であるならば、もう少し画像が小さくても良いのに、とは思いますが。記事を開いたということは、もう手に取ったということですから、ことさらに表紙・アイキャッチを強調することもないでしょう。記事に直接関係のある画像なら良いのですが、多くの場合、そうではないのですし。

どうせ作るなら適当でないものを

まぁ、アイキャッチの役割が広告であるとして、良い広告は広告として認識されないジレンマがありますから、私のアイキャッチに対する悪感情は、悪いアイキャッチばかりが記憶に残る傾向があるから、なのかもしれません。本の表紙は皆よく考えて作られているものですし、その表紙に相当するものを、よくあるフリー素材のおねーさんをペッと貼るだけみたいなのでは、ちょっと不足でしょうねぇ。それであれば、新書の表紙よろしく、文字だけのほうが潔いというものです。

ついでですが、記事の途中で意味もなくフリー素材のおねーさんを配置するような記事もありますけれど、これは本を読んでいたら突然何の意味もなく女の人の写真が挿絵にでてくる感じに近いと思いますが、雑誌のグラビアじゃあるまいし、あまり品が良いとは言えんです。ちと、よろしくない。おねーさんに限らず、頭を抱えたおにーさんなどもですけどね。イメージ画像とやらを文章の途中に挟んでも、仕方ないと思うのですが。

WordPress系のことを調べていると、そういうサイトがちょくちょく目について、辟易とします。何故この界隈はこういうのが多いのでしょうね…。どんな画像であれ、労はかかっているでしょうし、適当にやるくらいなら、無いほうが良いと思います。

Livedoorブログから引っ越しました

Wed, 20 Jul 2016 20:19:28 +0900

数ヶ月前から引っ越す引っ越すと言っていましたが、本当に引越しました。といっても、ドメインはそのままですし、ディレクトリ構造は変わっているものの、ちゃんとリダイレクトしているので、元の記事が見られないということはないはずです。ただし、RSSフィードのURLは変更されますので、ご注意ください。これもリダイレクトで飛ばせるんだろうか？

もしかして前のほうが見やすい？とか色々思うところはありますが、まぁ歩きながら考えます。

自前でやりたかったので

Livedoorブログも悪くはなかったのですが。何も考えなくていいし、その割にレスポンスも良好でしたし。しかし、色々と制限が多かったのも事実。特に辟易としたのは、モバイルの制限のきつさでしょうか。レイアウトの自由が一切きかないのは、ちょっとねぇ。特に広告がなぁ。お金払うから消したかったくらいです。

というわけで、遅ればせながら当サイトもVPS + WordPressのよくある構成になりました。標準のテーマであるTwentySixteen感満載でお届けします。本当はもうちょっと、ちゃんといじりたいのですが、まぁぼちぼち勉強しながら、ということで。

記事によっては、見え方がおかしいところもけっこうあると思いますが、ちょいちょいとなおしていきます。

いつまでLivedoorブログをもっておくか…

若干気持ちが悪いのは、独自ドメインを取得していなかった頃のアドレスから飛べるようにするため、Livedoorブログも当面は残しておかなくてはいけないということです。独自ドメインの運用を開始してからまだ4ヶ月ほどではありますが、それにしても、以前のアドレスをいつまで持っておくべきか…別にお金がかかるわけではないのですが…。

WordPress の Twenty Sixteen でリンクの下線を消す

Sat, 09 Jul 2016 00:30:25 +0900

text-decorationじゃなかった

WordPressの標準テーマの一つであるTwenty Sixteenにおいて、リンクの下線を消すやり方です。通常、リンクの下線を消すには以下を用いるとされます。

`a { text-decoration: none; }`

正解はbox-shadow

しかし、Twenty Sixteenにおいては、リンクの下線はtext-decorationではなく、box-shadowでやられているようです。したがって、以下のようにするとリンクの下線が消えます。

`a:link { box-shadow: none; } a:visited { box-shadow: none; } a:hover { box-shadow: none; } `

ハマりました……。

参考記事「get rid of underlined links css twenty sixteen « WordPress.com Forums」

見出しに番号を付けた(LivedoorブログでもOK)

Fri, 08 Jul 2016 15:34:17 +0900

Livedoorブログでシンプルエディタを使うと簡便にタグ打ちできることを知り、hタグをちゃんと使うようになりました。そうすると、今度は見出しに番号を付けたくなります。一記事あたりに付く見出しなんてそう多くはないのですが、性分ですね。CSSで使えるものはないかと調べたところ、counter-incrementおよびcounter-resetを使用することで簡単にできました。

2016/07/08 追記・修正：CSS3対応として:beforeを::beforeに変更、counter-reset のタイミングを変更と経緯の追記
2015/07/22 追記：個別記事下のカテゴリの最新記事には番号を振らない
2014/09/15 記事作成

見出しの深さが1の場合

LivedoorブログにおいてCSSをいじるときは、編集画面より「ブログ設定」→「カスタマイズ」→「CSS」タブを選択し、CSSを記述します。

Livedoorブログのプレビューでは、ブログ記事では記事内で使われることが多いhタグはh3とh4ですとありましたが、このブログではh2タグから使っています。したがって、h2タグに番号を付ける場合を想定します。以下のようになります。

`body { counter-reset: section2; } h2::before { counter-increment: section2; content: counter(section2) ". "; } `

section2という変数に番号が入ります。bodyのcounter-resetでsection2=0とし、h2が出るたびにsection2に1ずつ加えます。そんで、h2タグの要素の前にsection2を表示する、という具合です。たいへんシンプルですね。

(2016/07/08 追記) ::beforeについてですが、これはCSS2までは:beforeでしたが、CSS3においては、擬似要素と擬似クラスをハッキリ区別するために、::beforeになりました（参考：「::before (:before) - CSS | MDN」）。:beforeでも実際的には問題ないと思いますが、ここではCSS3準拠とします。

(2016/07/08 修正) Livedoorブログ対応で注意。Livedoorブログにおいては、ブログのキャッチフレーズというか、詳細（本ブログで言うと「見栄を張らない…（略）」の部分）も、h2タグが使われています。このままだと、この部分にも番号が割り振られてしまいます。回避する方法としては、h2::beforeをh2:not(#blog-description)::beforeとするとか、あるいは .article-body-inner h2 というように、div class=“artcile-body-inner” 内のh2であることを明記する、などが考えられます。私は後者を採用しています。

また、body でcounter-resetをかけた場合、トップページで複数記事がある時、section2のcounter-resetが最初の一度しかされません。対応として、body ではなく article タグで counter-reset をかけるなどがあります。

見出しの深さが2の場合(2.1とか)

このブログではh2タグの他h3タグを使うことが多いので、その場合についても記述します。

`body { counter-reset: section2; } h2 { counter-reset: section3; } h2::before { counter-increment: section2; content: counter(section2) ". "; } h3::before { counter-increment: section3; content: counter(section2) "." counter(section3) ". "; } `

先ほどとやっていることは一緒です。ただh3の番号にsection3を使うのですが、h2が出たらsection3をリセットするというところがポイントでしょうか。それくらいですね。同じ要領で階層を増やせます。

追記：カテゴリの最新記事には番号を振らない

Livedoorブログにおいて、このままだと、記事の個別ページで、下に表示されるカテゴリの最新記事に0.1の番号が振られてしまいます。

面倒なので放っていたのですが、やはり気になるので雑ですが消しました。以下を追記すると、カテゴリの最新記事には番号を振りません。

`div.related-articles h3::before { content: ""; } `

div要素のrelated-articlesクラス下にあるh3においては、何も書きませんよということです。もっとスマートな書き方があるように思いますが、ひとまずこれで目的は達せられます。

追記：counter-resetのタイミング

2016/07/08にしれっとコードを修正しています。深さ2以上の見出し時のコードで、元々は、bodyにてsection2とsection3のcounter-resetをしていました。また、counter-incrementはh2::beforeではなくh2内で記述していました。それを、bodyでcounter-resetするのはsection2のみ、section3のcounter-resetはh2内で行い、counter-icrementは各見出しタグの::beforeにて行うようにしました。

元々のコードでも問題なかったのですが、Googleアドセンスのタグを挿入すると、どういうわけかcounter-resetが正常にされなくなったためです。たとえば 2.1 - 2.4 と番号を割り振った場合、次に3.1と割り振られるべきところで、3.5となってしまう。試行錯誤の末、counter-resetのタイミングが重要であるということがわかりました。現在の形にすると、正常に番号が振られます。このコードは「CSS counter-reset property」を参考にさせていただきました。

Googleアドセンス用コードのあるなしや、h2::before と h2 内のどちらに記述するかや、body内でsection3をリセットするかで挙動が変わる理由が、イマイチわかっておりません。ただまぁ、必要のない変数の初期化がないなど、今のほうがコードとしても綺麗に見えますし、ひとまずまずこれで。

参考

以下の記事を参考にしました。ありがとうございます。

(K)CSSとHTMLだけで番号付きの見出しを作成する（CSS覚え書き） | web(K)campus

ブログを始めるなら半年は続けたい

Sat, 02 Jul 2016 13:51:39 +0900

ブログを始めてから、かれこれ三年半。もうすぐ4年です。どんなことでも、続けるということはよいものですし、色々と見えてくること、気づくことがあります。それで、これは気づいたことの一つなのですが、どうも、ある記事がGoogleに評価されるには、だいたい半年くらいかかるようだなぁ、と。

記事の評価に半年かかる

日々のアクセス数は、個人サイトの管理人にとっては楽しみの一つです。別にアクセスを稼ぐためにやっているわけではありませんが、それでも記事を読まれるのは掛け値無しに嬉しいものです。どういう記事が求められているかを知るための貴重なデータでもあります。ですから、はぁ、この記事が読まれているんだなぁ、というのは、楽しみ半分、勉強半分といったところです。

月日が経つにつれて、アクセスを集める記事も少しずつ入れ替わってきますが、その頻度というのが、だいたい半年くらいの目安であるように思えます。実際、PCでアクセスすると、当サイトのサイドバーから人気記事を見ることができますが、どれもそれなりにアクセスいただくまでに半年くらいかかっているんですよ。私としては、半年前と言えばもう昔のことですから、書いたことも忘れていることもあります。ですので、正直な感想としては、はぁ、今になってこの記事がアクセスされるのか、という感じです。

もちろん、記事、ブログの性質にもよるのでしょうのでしょう。速報性の高いニュースブログであれば、また別でしょうが、まぁ個人が書く記事といえば、自分の考えや経験談といったものが主ですから、速報性はあまりないのがたいていでしょう。まぁ、新商品のレビューとなれば、その限りではないでしょうけれど。

しかしまぁ、そんなものなのでしょう。仮にも3年以上続いている当ブログでもそのような感じですから、これから何かしらのブログを始めようという人は、まぁ、半年は続けることが肝要なのだろうと思います。半年とは、随分と長い時間ですが…。経験上、技術系の記事は、多くのアクセスを集めることはありませんけれど、一定数には必ず読まれる、しかもそれなりに長くアクセスされることになる、非常に手堅い記事だと思うので、始めるなら、何か、技術系の連載記事ができると、続けやすいかなと思います。

でも、なにがきっかけでアクセスが増えるんでしょうね。当サイトは昔ながらの検索エンジンからの流入がほとんどを占めますから、何かしらのキーワードで上位になるよう評価されたのでしょうが。単純に時間という話だけでもないと思うのですが、さて…。

ムームードメイン + .xyzドメインで利用制限（serverHold）にかかる。この組み合わせはオススメしない

Fri, 01 Jul 2016 09:14:26 +0900

本記事は、ムームードメイン + XYZ で、利用制限がかかり、またそれが解除されるまでのことを綴った記事です。まぁ一人の経験談ですから、そういうものとして参考にしてもらえればと思いますが、少なくとも私はオススメしないですよ、この組み合わせ。

（2016/08/07追記：久々に見ると、またserverHoldにかかっていました。しかし、今回のことで嫌気がさしていた私は、既に当該ドメインを使っていません。したがって、問題の起きようがありません。ムームードメイン+XYZに問題があるのだと私は判断します）

これまでの記事。

serverHoldから解除までの流れ

サイトを運営していた独自の.xyzドメインで、ある日突然serverHoldの制限がかかり、解除されるまで。

1日目：突然ドメインが使えなくなる. whois 見るとserverHold. ムームードメインに連絡
2日目：ムームードメインからレジストリに連絡するわって返事
7日目：ムームードメインからレジストリ判断で制限された. 解除のためサイト情報提出、WHOISの代理情報を一時的に個人情報に切り替え
14日目：突然ドメインが開通. ムームードメインに結局原因は何？と聞いてみる
15日目：ムームードメインから「あくまでレジストリ判断だから」と返事
今に至る。

やったことは、WHOIS情報をムームードメインの代理情報から、自分の個人情報に一時的に書き換えただけです。今は代理情報に戻しています。というか、解除待ってられないので、別ドメインを取得して、サイトは移転させました。Search Consoleでアドレス変更をGoogleに伝えたかっただけなので、それも果たしましたし、また制限くらおうがどうなろうが、もはやどうでもいいことです。.xyzはもう買いません。

二週間というのは、弱小サイトだとGoogle検索に引っかからなくなるには十分な期間らしいですね。

原因はなんだったのか

当サイトのドメイン、hack-le.comでも同じことがあると、私的にはかなりダメージがあります。今後のためにも、原因を知りたいところです。ダメ元でムームードメインにも原因について問い合わせてみて、一応は返答もきたのですけれど、「あくまでレジストリの判断。不正な利用がないかコンテンツを再確認するための一時的な解除らしいから注意して」という内容で、まぁ予想していたことではありましたが、つまり「わからん」ということです。再確認しろと言われても、判断基準はわからない、では確認のしようもないものです。個人とは一サーバー管理者として、ログを追跡したり、監視ソフトで不正ログインやネットワーク・CPU負荷に怪しい動きがないかも調べましたが、見当たらず。まぁ、実際のところ何の問題もなかったのでしょう。でも、そうは言えないんでしょうねぇ。不運な事故に巻き込まれたと考えるよりほかないですね。

ムームードメインの対応について

今回の件について、ムームードメインの対応そのものは、特に遅いということもなく、また非常に事務的でした。ただ一点、開通後に問い合わせた時、「なお、現在の状況と致しましては、レジストリより一時的に当該ドメインのServerHoldステータスを外した状況であるとのことでございます。」という文言があったのですが、これは伝聞ですから、つまりなんらかの説明がレジストリからあったということだと思うのですが、こちらから問い合わせるまでムームードメインから私に何の連絡もなかったことが気にかかります。とはいえ、開通の翌日に問い合わせたので、もうしばらく待っていたらムームーから連絡があったのかもしれませんし、私から連絡をしたことで、ムームー側がレジストリにわざわざ問い合わせたくれたのかもしれませんし（だとすれば有難いことですが…だとすればね）、なんとも言えないです。もし、一言でも同情の言葉があれば、印象はだいぶ変わるんですけどね。

ムームーからは本件については、レジストリの判断だから何も言えないの一点張りで、まぁそう言うしかないのだろうとは思います。レジストリからは、具体的なことは何も教えてもらえないのでしょう。仕方ないですね。。ただ、「.infoドメイン取得で結構手間取った話 - のっぴきならない昨今です」の記事の人は、ムームードメイン経由で取得したことが一因となってserverHoldの憂き目にあったようなので、ひょっとしたら、リセラーの影響もあった可能性はあります。しかし、こういう話はどこのレジストラやリセラーでもありそうなことではあるので、私としては今回の件でムームードメインから他所に移管する気は今のところありません。面倒臭いですし。まぁ、日本語の情報量の少ない制限なので、一つ参考情報としてあげておきます。

レジストリの対応について

今回の発端はレジストリによる利用制限だったのですが、結局原因についてはわからずじまいです。「My Domain / nameservers are serverHold | Web Hosting Talk」にもいきなり制限され、問い合わせたら何の説明もなく解除されて、もうxyzは買わねぇとぼやいてる外人さんがいますし、私としても、今回もっとも不信感を抱いたのは、xyzのレジストリです。何の具体的説明もありませんでしたが、何もしないで解除されてますから、まぁそういうことでしょう。今後、私がxyzドメインを使うことはありませんし、人にも薦めません。前述の記事の人は.infoドメインですが、やはり一番安定したgTLDは.comなのでしょうか？ .comならば大丈夫という保証はありませんが、少なくとも私が所持している.comドメインで、こういったことは今のところ起きていないので。

WHOIS情報で、リセラーの代理情報ではなく、自分の個人情報を出せれば、また違うかもしれません。しかし、メールアドレスくらいならともかく、このご時世に本名、住所まではなかなか出せるものでもありません…。当サイトでさえも、いくつかはデリケートな話題を取り扱っている記事もあり、実名出しは憚られます。要は、連絡がつけば問題ないわけでしょう。

gTLDなんてなんでもいいと思っていた

今回のことは、色々、勉強になりました。レジストリやレジストラといった存在をこれだけ意識したのは初めてのことです。gTLDなんて値段以外なにも変わらないと思っていましたが、管理団体が違うのだから、自ずと違いもでますよねぇ。

考えてみると、インターネットの世界は広いようですが、そこには大元があって、ちょっとしたことで、たちまちインターネットの世界から弾かれてしまいます。今回のレジストリもそうですし、別方面ではGoogle八分というものもあります。他、「金と力のインターネット:Geekなぺーじ」の記事はタイムリーにインターネットの背後にある力を考えさせてくれました。ドメインだって、結局借り物なんですよね。一つのドメインに拘泥せず、いざとなればいくらでも乗り換えるよ、というスタンスが大事なのかも。たとえそれで評価がリセットされたとしても、記事が残ってさえいればやり直せる。長い目で見れば、大したことじゃない。

矮小な一市民にできることは限られています。矮小な一市民だからこそ、たいていのことは見過ごされる、という面もあるので、良し悪しではあるのですが。インターネットの自由は、案外脆いものなのかな、と、そんなことを考えました。その中で、自由な自分であるためには、あらゆることに複数の選択肢を用意できることが重要なのだと思います。

しかし、Googleの代わりって、なんでしょうね。

ドメイン変更後、二ヶ月半ほどでアクセスが以前と同じくらいに

Sat, 18 Jun 2016 22:07:44 +0900

3月末頃に、ようやく独自ドメインを取得しました。ドメインの移行は、本来であればGoogleのツールであるSearch Console（旧ウェブマスターツール）より、Googleにお知らせすることができるのですが、それはドメインの持ち主である場合に限られます。つまり、livedoor.comの持ち主であることが求められるのですが、当然私にはそんな権限はありません。したがって、Googleにドメインの変更を通知することができず、まぁ流れに任せるしかありませんでした。

セッション数の推移

元のURLからでも、リダイレクトで飛ばせるので、旧URLを踏んだ人を404の憂き目にあわせることはなかったと思うのですが、しかし元のURLにはページがありませんので、Googleがそのことを察知すれば、アクセスは減るだろうなと思ってはいました。それが現れたのは、ドメインを変更してから一週間ほどしてからのことで、まず半分程度にまで落ち込み、それからしばらくすると、2/3程度にまで回復し、その後はまたそれで安定していました。

結局アクセスは減ったのだなと思っていたのですが、ここ二週間ほどで、またアクセスが以前と同水準程度に戻っています。変化は割と急で、恐らくそれは、ある日を境に本ブログでもっともアクセスを集めている記事（ブラック研究室の記事です）が、以前と同程度の検索順位に戻り、その影響が特に大きいものと思います。まぁ、他の記事にもセッション数を上げているのがあるので、その影響もありますが。

というわけで、Livedoorブログのドメインから、独自ドメインに変更してからのセッション数の推移としては、一週間ほどで約半分、その後しばらくして2/3、そして二ヶ月半ほどして元通り、というのが本ブログにおける実例でした。ここから、さらに増えると嬉しいのですが。

今度はサーバーを引っ越そうかな

あまり一辺にあれこれやるのはよくなかろうと、まずはドメインの引越しを済ませましたが、本丸はサーバーの引っ越しにあります。

Livedoorブログは決して悪いものではなくて、インフラ周りのことを一切考えなくて良いし、表示も早いし、一般的にはよいものだと思います。Livedoorブログは家族や友人にも進められるブログです。

しかし、やはり自由がない。特に、スマホ版は融通がきかない。現在、Livedoorブログは有料プランを廃止し、さらにPC版においては広告の非表示すらできるのですが、スマホ版はほとんど融通のきかないレイアウトで、一番いい位置に広告を載せているので、まぁそこで稼いでいるのですね。モバイルファーストが叫ばれて久しい昨今、それは正しいやり方なのでしょう。

当ブログは、その内容から今でもPCからのアクセスが一番多いのですけれど、当ブログの一番の読者である私自身が、時折スマホで閲覧します。その時、どうにもこのLivedoorデフォルトのレイアウトが、色々気に入らないところがあるのです。

そんなこんなで、将来的なことも考え、近々、本ブログをLivedoorブログから、どこぞのVPS上でWordPressにより作成したものに引っ越すつもりです。

serverHoldは珍しいのか。中華サイトばかりでる。とりあえず.xyzは使わないことにする

Sun, 12 Jun 2016 12:04:24 +0900

続報「ムームードメイン + .xyzドメインで利用制限にかかる。この組み合わせはオススメしない」.xyzはもう買いません。

ある日突然、ドメインが使えなくなりました。whoisで見ると、Domain StatusがserverHoldです。これはレジストリのオペレータによりセットされもので、これをされるとドメインそのものが使えなくなります。対応としては、レジストラに問い合わせるしかありません。

ドメイン凍結続行中

現在ムームードメインに問い合わせていますが、レジストリのやったことですし、ムームーが直接何かできるわけではないので、返答待ちです。

しがない個人サイトとはいえ、いえだからこそ、こういうことはけっこうショックで、原因を調べたりもしているのですが、 「serverHold 原因」で調べると中華サイトのオンパレードです。なんだかそれがヒントのような気もしつつ、まぁ、まず誤爆でしょう。.infoドメインですが、「.infoドメイン取得で結構手間取った話 - のっぴきならない昨今です」という迷惑メール業者に巻き込まれた人の話もあります。色々なことがあるものです。Whois情報で個人情報を公開すればよいのかもしれませんが、このネットの世界にあるのは必ずしも善意ばかりでないことはよく知られたことですし、それもちょっとねぇ。

待っていれば、解除されるかもしれないし、されないかもしれません。解除されることを望みますが、こういうことがあった以上、私としては、もう.xyzドメインは利用しないつもりです。既に新たなドメインを取得し、サイトは引越しました。解除されないと、元ドメインからのリダイレクトすら出来ないので、解除してほしいところですが…。

色々なTLDのある昨今ですが

そもそも、TLD（Top Level Domain；.comなどのこと）増やしすぎです。最近、.sexなるTLDが新設されて、しかも「ブランド保護のために取得しておくことをオススメします」のようなことを言っていましたが（「新ドメイン「.sex」、非アダルト事業者を対象に早い者順で登録受付 -INTERNET Watch」）、これはとてもまっとうな商売の仕方ではないと思います。お名前.comでも、やたらブランドイメージを毀損しないためにアダルトなTLDのドメインを取得しましょうという広告が流れますが、一体どこの誰が、会社名.adultなんてアドレスを直打ちするというのでしょう。直打ちしたとして、それでアダルトサイトに繋がったところで、どうしてそれがブランドイメージの毀損になるのでしょう。阿呆がいるなぁ、と考えて終わりだと思います。

話が逸れました。まぁ、昔ながらの.comや.netを使っておけば、よいのだろうと思います。

「DNSアドレスが見つかりませんでした」独自ドメインのサイトがserverHold….xyzのせいなんだろうか

Fri, 10 Jun 2016 01:46:29 +0900

謎です。独自ドメインを取得して運用している個人サイトに、突然アクセスできなくなりました。「このサイトにアクセスできません。○○のサーバーのDNSアドレスが見つかりませんでした」とにべもなく言われてしましました。

突然アクセスできなくなった

VPSのサービスでDNSも借りているのですが、最初はそこがおかしいのかな？と思ったものの、pingは返るし、障害情報も上がっていないし、どうも違うらしい。調べてみると、「「サーバーDNS addressが見つかりませんでした」ブログのトラブルを解決！ | 落ちこぼれサラリーマンのブログ」な記事もあり、そうなるとレジストラないしレジストリの問題っぽい。しかし、認証についてはちゃんとしているはず。実際、ムームードメインでドメインを取得しましたが、コントロールパネルから見ると、私が取得しているドメインはすべて認証済みです。うーん……。

ムームードメインのサポートを参照していると、「【clientHoldとは？】ドメインが急に利用できなくなりました。 | よくある質問 | ムームードメイン」という記事がありました。ドメインの管理は階層構造でされていますが、これによるとレジストラより上位の機関で利用制限がされているかもしれない、とのこと。「Whois検索 - お名前.com」で調べてドメインを調べてね、とのことなので調べます。お名前.comのページですが、ムームードメインで取得したドメインは、.jp以外は結局お名前.comの管理下にあるためでしょう（正確にはムームードメインはレジストラではなくリセラー）。

利用制限されていた

調べてみると、果たして、Domain StatusがserverHoldです。ふむ…ムームードメインのページに有る、clientHold、ではないようですが、ダメそうなスータスです。「Resources - ICANN」によれば、serverHoldとは以下です。

This status code is set by your domain’s Registry Operator. Your domain is not activated in the DNS.

このステータスコードはレジストリのオペレータによってセットされる…ううむ。やはり、レジストラより上位の機関によって制限されている模様。「.infoドメイン取得で結構手間取った話 - のっぴきならない昨今です」の記事の人は、どうやら迷惑メール業者に巻き込まれて制限を食らってしまったらしい。私も、何かに巻き込まれたんだろうか。先のICANNのページでは、serverHoldの対応として、「レジストラに問い合わせようね」としか書かれていない。まぁそうするしかないのでしょう。

仕方ないので、一応、clientHold時の対応としてムームードメインのページにある、Whois情報の再認証を行い、それでも制限が解除されないのを確認のうえ、ムームードメインにServerHoldかかってます、と問い合わせしました。どうなるやら…。

余談ですが、お名前.comのWhois検索ページ、非常に重いんですが……何故だろうか。というか、お名前.comのページ、全般的に重すぎる。それが嫌で私はムームードメインを使っているのですが…それにしても重い、重すぎる。何か私の環境に問題があるのだろうか…それともこんなものなのか…。

.xyzのレジストリってどうなんだろね？

ところで、今回の件が起きたのは.xyzドメインです。で、調べていると「My Domain / nameservers are serverHold | Web Hosting Talk」という記事がありました。同じような状況の人がいて、どうも最終的に制限は解除されたようなのですが、その際レジストラには何の説明もなかったらしく、スレ主はxyzのレジストリに不信感を抱いたようで、「もうxyzは買わん」と言って終わります。

ううん…どうなんだろうなぁ。やっぱり、.comのほうがいいのかなあ。作ったばかりのサイトで、あまり人に知られていないサイトあるし、ドメイン変えようかなぁ…。でも、Amazonアソシエイトとかまた申請しないといけないし、面倒臭い…ううぅ…色々なことがうまくいきません……。

WordPressでカテゴリと記事一覧を作成するプラグインでサイトマップのページを作成

Fri, 20 May 2016 09:00:54 +0900

本記事は、WordPressのサイトマップページをプラグインを用いて作成する記事です。サイトマップと言うと、Googleさんの見回り用に提出するsitemap.xmlが思い浮かぶのですが、昨今のサイトを見ていると、全記事一覧を表示するhtmlのサイトマップページがよくあるようです。これは確かに便利で、サイト全体を俯瞰したいという気持ちのある自分としては、是非実装したいと思いました。

プラグインを探す旅

しかし、私はphpは不勉強ですし、WordPressも初めて間もないですから、勝手がよくわかりません。手っ取り早く実装するには、プラグインに頼るのがよかろうと思ったのですが、有名ドコロらしいPS Auto SitemapはWordPressの最新に対応しておらず、また最新バージョンに対応しかつ使いやすそうであったSimple Sitemapは、実際にやってみると思ったような結果がでない。

カテゴリを並べればサイトマップだ

どうしたものかな、と思っていたところ、「WordPressのサイトマップ(目次)のプラグイン3選。でもおすすめはない！ » eBook Brain」の記事にある、「カテゴリを全部並べればサイトマップです」という文言にはっとしました。なるほどそのとおりです。

参考記事では、List category postsというプラグインを紹介されていました。このプラグインはWordPress最新版(4.5.2)にこそまだ対応していないものの、4.4.3には対応していて更新が止まっているわけではなさそうですし、また実績もあるので、これを利用しようかと思ったのですが、ざっとプラグインを眺めていると、「List all posts by Author, nested Categories and Titles」という長ったらしい名前のプラグインが目に入りました。

これは4.5.2に対応しています。更新もそれなりにしているようです。インストールが600件というのが心もとないですが、カテゴリを並べるだけのプラグイン、そう複雑なことをしているわけでもないでしょうから、変なことにもなるまいと、これを利用してみることにしました。

List all posts by Author, nested Categories and Titlesの利用

結論から言えば、これはたいへんうまく働いてくれました。一行のシンプルなショートコードを固定ページに書くだけで、カテゴリと記事の一覧を作成することができました。任意のカテゴリを除外したり、記事の順番を日付順にしたりといったことも簡単です。ショートコードの例は「List all posts by Authors, nested Categories and Titles — WordPress Plugins」にありますが、WordPressの管理画面にある「ツール」より、条件に合わせたショートコードを生成することができます。

たとえば、カテゴリと記事の両方を並べ、シングルユーザーで（記事を書く人が一人だけ）、記事は日付順にソートし、カテゴリ未分類(スラッグはunknown)を除外するには、以下の様なショートコードを、固定ページに書けばOKでした。

[caption id=“attachment_5710” align=“aligncenter” width=“751”]

ショートコードの例[/caption]

サイドバーなどでもうまく使えば、かなり柔軟性の高いサイト設計ができそうです。あまり実績のないプラグインのようですが、まぁカテゴリを出力するだけですからややこしいこともしていないでしょうし、なかなか良いのではないでしょうか。

Twenty Sixteen で、キャッチフレーズをタイトルから消す

Thu, 19 May 2016 09:00:35 +0900

現在のWordPressでデフォルトとなっているTwenty Sixteenでは、フロントページのタイトルが「サイト名 - キャッチフレーズ」となっています。キャッチフレーズが長いと、titleが無駄に長くなり、不都合がある場合もあります。他テーマだと、header.phpやらfunction.phpやらをいじればよいことが多いようですが、Twenty Sixteenではwp-includesにある関数をいじる必要があるようです。

やり方

具体的には、wp-includes/general-template.phpにあるwp_get_document_title関数内にある、1008行目あたりの、以下の部分をコメントアウトします。

` // Append the description or site title to give context. if ( is_front_page() ) { // ここの部分をコメントアウト // $title['tagline'] = get_bloginfo( 'description', 'display' ); } else { $title['site'] = get_bloginfo( 'name', 'display' ); } `

名前が一般的なテンプレートですので、このテンプレートを利用する他のテーマにも影響があるだろうと思います。それがどれだけあるのかは、わかりませんが。

また、WordPressをアップデートした場合も初期化されますので、ご注意を。

ここに至るまでの軌跡

ここに至るまでの軌跡について書きます。というのは、WordPressはけっこう更新が激しいせいか、ディレクトリ構成などの変化も激しく、検索した情報がどれも古くて直接は使えなかったからです。ですが、探し方自体はそう変わるものでもありませんので、苦労の軌跡を書いておくことは、無駄ではなかろうと思います。以下、興味ある方だけどうぞ。

header.phpを調べる

まずは、Twenty Sixteenのheader.phpを調べました。これのheadタグを記述する部分に、それらしいものはないかと思ったのです。ソースコードと照らしあわせながら見ると、微妙ですが、可能性があるとすれば、wp_head()でしょうか。wp_head()は何するものぞ、とgrepコマンドで調べてみると、functions.php内でtwentysixtten_javascript_detection関数にフックしていました。名前からしてダメそうな感じがしつつ、同phpファイルで定義されているその関数の中身を見ると、やはりscriptタグを書き出しているだけみたい。wp_head()ではなさそう。

他にそれっぽい関数を探す

header.phpじゃなければなんだろう、と思い、今度はfgrepコマンドでheaderタグの中を記述してそうなphpファイルを検索しました。すると、index.phpがヒット。ああ、これは可能性あるな、と思ってみてみたら、get_header()関数なるものが。get_header()ってなんぞ、と思って探してみても、テーマディレクトリ内に定義したファイルがない。が、WordPressではWebの管理画面から、関数を調べることができます。普通にググってもよいですが。調べると「get_header() | Function | WordPress Developer Resources」より、wp-includes/general-template.phpがソースファイルであることがわかりました。どおりでテーマディレクトリ内にないわけです。

それで、今度は当該ファイルのget_header()の中身を見ました。なんだかよくわかりません。とりあえず、ここをいじってもダメな気がする。

wp-includes内を調べる

ではどうしようかと思いましたが、wp-includesディレクトリ内のファイルをいじればよい、というのは間違えていない気がします。ということで、headerに関係ありそうなファイルを、findコマンドで探しました。すると、theme-compat/header.phpなるものが見つかりました。それらしいです。ヒントがあるかもしれません。

中身を見ると、果たして、titleタグ内を記述しているところがありました。そこで使われているのが、wp_get_document_tile()関数です。おお、なんだかとてもそれらしい名前だ。これはなんだろうとググってみると、「wp_get_document_title() | Function | WordPress Developer Resources」より、get_header()と同じgeneral-template.phpで定義されていることがわかりました。

wp_get_document_title関数を調べる

再び当該phpファイルより、wp_get_document_title関数を見ていきます。ざっと眺めた感じ、なんだか有望そうです。特に臭いのが、キャッチフレーズを示すdescriptionを付加していると思われるところ、すなわち前節で示した部分です。ここをコメントアウトしてみると、どうか？何かあっても嫌なので、仮想環境下で試してみると、なるほど、タイトルからキャッチフレーズの部分が消えました。どうやら、これであっていたようです。

以上より、目的を達成することができました。titleからキャッチフレーズを外すなんて簡単だと思っていたのですが、手こずりました。

WordPress で同一カテゴリの記事タイトルを記事下に表示（複数カテゴリ）

Wed, 27 Apr 2016 17:30:47 +0900

2016年11月17日修正：ソースコード中、閉じる必要のないphpは閉じないようにした

本記事では、WordPressにおいて、記事下に同一カテゴリの記事を表示する方法について記述します。カテゴリが複数あればすべて表示し、また投稿記事のリンクはリストに含まれないようにします。最初のコードはバグがあったので、後でしれっと修正しました。

やりたいこと

WordPressを初めてしばらく、そろそろテンプレートをいじりたいなと思うようになりました。手始めに、個別記事ページの記事下に、投稿記事と同じカテゴリの記事のタイトルを表示しようと思いました。Livedoorブログだと何も考えずともあるやつです。それを実装します。記事のカテゴリが複数ある場合にも対応します。phpについては不勉強ですが、自分が全然わからないコードを書いてしまうと、後々何か起きた時に右往左往してしまうことになるので、まぁなんとか説明できる範囲で書きました。

コード

編集すべき個別記事ページの php ファイルは、/var/www/html/wp-content/themes/ほげほげ/single.php です。私は初心者なので、デフォルトのTwentySixteenを使っていますが、このテーマでは、single.php に get_template_part( ’template_part( ’template-parts/content’, ‘single’ ); という記述があります。つまり、個別記事のphpの実体は、template-parts ディレクトリ下にあるということです。template-parts ディレクトリを見ると、content-single.php というそれらしいファイルがあります。このファイルを編集します。

以下のコードを末尾に追記すると、記事下に記事と同一カテゴリのうち新規10件のタイトルが表示されるようになります。おおまかな流れとして「[WordPress] 見ている記事と同じカテゴリーの最新記事一覧を表示する方法 (参照中の記事は除外) | TechMemo」を参考にさせていただきました。

` 10, 'category' => $category->cat_ID, 'exclude' => $post_id ); $posts = get_posts( $args );  // 記事が1つ以上存在する時のみhtmlを出力 if ( sizeof($posts) > 0 ): echo ''.$category->cat_name.' と同一カテゴリの記事
'; echo ''; foreach( $posts as $post ): echo ''.get_the_title().'
'; endforeach; echo '
'; endif; endforeach; $post = get_post($post_id); ?> `

echo文の.(ドット)は、結合を意味します。echoの度にいったんphpを閉じるサンプルをよく見ますが、ソースコードが非常に見づらくなるので、一度phpが始まったら、出来る限りphpで書き続けるほうが良いのではないかと思っています。WordPressの元のphpを見ると、毎回閉じたり開いたりしているので、どうあるべきかはわかりませんが…。

解説

一行一行、見ていきます。

$post_id = get_the_ID(); で、投稿記事のIDを代入します。これは、後で当該記事を記事一覧から省くのに使います。また、$categories にテンプレートタグ get_the_category() より、投稿記事の属するカテゴリーを代入します。get_the_category() については「テンプレートタグ/get the category - WordPress Codex 日本語版」を参照。

カテゴリーは複数あるかもしれません。ので、foreach( $categories as $category ): より、１つずつ$category として処理します。

次がポイントで、 get_posts() を利用して同一カテゴリの記事の情報を取得します。get_posts() のパラメータが重要です。ここではパラメータを $args に配列でまとめています。それぞれ説明すると、posts_per_page は件数で、表示したい記事数を入れます。category は、取得したいカテゴリのカテゴリIDを入れます（この場合 $category->cat_ID）。exclude は、除外したい記事のIDを入れます。その他どんなパラメータがあるのかなど、詳細については「テンプレートタグ/get posts - WordPress Codex 日本語版」および「get_posts:WordPress私的マニュアル」を参照してください。

さて、取得した記事群 $posts のサイズが0以下であれば、つまり表示すべき記事がないということなので、ここまでです。次の if 文内の処理は行われず、すなわち最後のほうの endif; 後、つまりループの終わりまで飛びます。$posts のサイズが0より大きければ、つまり表示すべき記事がある場合は、カテゴリ名を $category->cat_name() より取得し、その後 $posts 内の各記事情報を $post として処理していきます。各記事のURLを get_permalink() で取得し、記事タイトルを get_the_title() で取得します。

以上を繰り返し、$categories 内のすべてのカテゴリーについて処理したら、ループを抜けます。

ループを抜けたら、変わってしまった$postを元に戻します。$post = get_post($post_id);です。これをしないと、$postが一番最後に表示した記事の情報になってしまうため、メタ情報の日付がおかしなことになったりします。

リストで一度登場した記事を、別カテゴリのリストで表示させない

さて、以上のやり方でも問題ないと思いますが、たとえばAの記事がカテゴリ1とカテゴリ2の両方に属している場合、カテゴリ1とカテゴリ2のリストの両方にAの記事が載ります。それはそれでよいという場合もあるでしょうし、それはちょっと格好がつかないという場合もあるでしょう。以下に、一度リストにのった記事は、他カテゴリのリストから外れるようにするやり方を書きます。

上記コードでは、get_posts()のパラメータである$argsのexcludeで、記事のIDを指定することで、現在の記事をリストから除外しています。したがって、このexcludeに、現在の記事だけでなく、一度表示した記事のIDも指定すればよい。このexcludeは、数値、文字列のほか配列を指定することができるので、’exclude’ => post_id のpost_idを除外したい記事すべてのIDを格納した配列にすればOKです。具体的には、コードを以下のように書き換えます。

`// $post_id = get_the_ID(); $post_id_array = array(); $post_id_array[] = get_the_ID(); ...中略... // $args = array( 'posts_per_page' => 10, 'category' => $category->cat_ID, 'exclude' => $post_id ); $args = array( 'posts_per_page' => 10, 'category' => $category->cat_ID, 'exclude' => $post_id_array ); ...中略... '.get_the_title().''; // ここを追記 $post_id_array[] = get_the_ID(); endforeach; $post = get_post($post_id_array[0]); ?> `

これで、たとえばカテゴリ1とカテゴリ2に含まれる記事Aは、カテゴリ1のリスト内でしか表示されなくなりました。

独自ドメインに移行してからのアクセス数経過二週間で半分

Sat, 09 Apr 2016 11:14:51 +0900

独自ドメインに移行してから二週間が経過しました。通常、サイトアドレスが変更となった場合は、旧ウェブマスターツールであるGoogleのSearch Consoleより移転ツールを使用するのが常道です。しかし、Livedoorブログで通常利用している人間がそれを使用すると、「ルートレベルのドメインとサブドメインのみに制限」とにべもなく言われて、使えません。

アクセス数が半分

blog.livedoor.comの所有者でなくては引越しツールが使えないわけです。もちろん私にそのような権利はありません。それで、Googleにサイトアドレスの変更を伝えることができませんでした。同じアカウントで管理しているのだから、察知してくれてもよさそうですが。それとも、察知はしてくれているのかな。

さて、それでしばらく様子を見ていました。最初の一週間は、アクセス数に変動らしい変動も見受けられませんでしたが、変化は突然現れました。端的に言うと、ある日セッション数が1/3程度に落ち込み、その翌日は1/4程度にまで落ち込みました。その後セッション数はやや回復し、現在は半分程度で推移しているようです。

このブログは、ソーシャルサービスからの流入はほとんどなく、検索エンジン頼みの、ネット上の孤島のようなところですので、Googleの匙加減一つでアクセス数が大きく変動します。サイトアドレスの変更を正しく伝えることができれば、このような減少もなかったのでしょうが、まぁ仕方ありません。続けていれば、そのうち以前と同じくらいには戻るでしょうか。

それとも、これはいわゆるドメインそのものの評価の現れなのかな。Googleの評価においては、コンテンツの内容そのものはもちろんですが、ドメインも重要であると聞きます。今まではblog.livedoor.blogとしてGoogleに評価されていましたが、これからはhack-le.comとして評価されます。現在hack-le.comの評価はないに等しいはず。であるとすれば、アクセス数は戻らないのかもしれないし、戻るのかもしれないし、あるいはもっと増えるようになるのかもしれない。こういう影響があるのだとすれば、今後のアクセス推移が楽しみです。増えなかったら悲しいですね。

新規セッション率が久しぶりに高い

当ブログは偏った記事が多いせいか、新規セッション率が低く30%程度でした。なにかしらの関心あるキーワードのうち、いくつかのキーワードにおいて、検索エンジン上で当ブログの記事が繰り返し表示されているのだと思います。あるいは、サイト自体を訪問してくれている人も、少ないながらいてくれているのでしょう（嬉しいことです）。それが、アクセス数の激減に合わせて、90%近くまで上昇しました。

まぁ、これは新規セッションの数え方で、本当に新規の人が増えたというわけではないと思います。どのように新規をカウントしているのか、その詳細についてはわかりませんが、現象から考えると、ユーザーが過去に訪問したサイトアドレスとの照合でしょうか。検索エンジン上で旧アドレスがだいたい消え、新たなアドレスがGoogleに認知されたということです。

とすれば、この新規セッション率も徐々に下がっていき、最終的に以前と同程度になるのではないかと思うのですが、さて、それにどれくらいの時間がかかるかな。これにかかる期間がどれくらいかで、当ブログの実質的なリピーター率というのが、朧げながら見えてくるように思います（新規セッション率そのものは、二年以内の再訪でリピーターとみなされるようです。これは感覚的にはかなり長いように思えます）。

ところで、新規セッション率30%はちょっと低すぎるのではないかと常々感じていました。それはつまり、私が同じようなテーマの記事ばかりを書いているということで、畢竟私自身の変化の無さを象徴しているように思えてならないのです。それは必ずしも悪いことではなかもしれませんが、今の私の心境からいくと、ちょっと残念なことなのです。だから、恐らくまやかしとはいえ、新規セッション率の上昇はちょっと嬉しかったですよ。

まぁ色々とゴタゴタしていますが、何かをして何かが起きる、というのは、なんであれ楽しいものです。

Livedoorブログで独自ドメインに移行する際にやったこと、起きたこと（アクセス変動など）

Fri, 01 Apr 2016 14:07:39 +0900

先日、独自ドメインに移行しました。DNSサーバーの設定ミスで、しばらく自サイトに自宅からアクセスできないという憂き目にもあいましたが、問題なく移行できました。本記事は、その際行ったこと、起きたこと（アクセス変動など）をまとめた記事です。

記事の目的

作業は一通り終わりです。記事内のURLの変換も終わりましたし、AmazonアフィリエイトやGoogleアナリティクスの変更手続きも済みました。あとは、Googleさんが引っ越しに気づいてくれるのを待つばかりです。

もっと早くやっておけばよかったと思いますが、私はどうにもWeb周りに苦手意識があって（関心は強いのですが）、なんとなく厄介そうに思え、ずるずるとここまで延ばしてしまったのです。それというのも、使用されている言葉の意味や、仕組みがよく把握できていないせいです。

まぁでも、やってみれば存外簡単なものです。過去の自分に見せるつもりでまとめます。

ドメインの取得

ドメインの取得にかかる手順について。

ドメインとは

まず、ドメインの意味を確認します。ドメインとは、当ブログでいえば hack-le.com の部分です。よくある名前はだいたいそれ系の業者がおさえていて、プレミアがついていたりします。hackleは英単語であるせいか、取れませんでした。また、どこにでもコレクターはいるもので、ドメインを集めて管理する奇異な趣味の人も少なからずいるようです。ドメインは、取得はもちろん維持費もかかるのに。まぁでも、趣味というのは金がかかるものですし、関心のない他者からすると理解し難いものです。それでこそ趣味というべきものです。

費用

費用はTLD(Top Level Doamin)によって異なります。いわゆる.comの部分です。特に.comのように、誰でも使える汎用的なTLDを、gTLD(Generic TLD)と呼びます。.comや.netは有名ですね。目新しく安いドメインは、その手の胡散臭い人たち御用達で、巻き添え規制などのトラブル率も上がるかもしれません。また、他に誰でも使えないものもあるのかというと、たとえばco.jpや.jpなどがそれにあたります。

で、費用ですが、.comが年間1,280円といったところです。 .xyzや.asiaなどは、取得費用は安くても維持費が高かったりするので、注意が必要です。取得費用のキャンペーンやっているやつは、だいたい維持費が高い。そういう商売ということです。

取得できるところ

取得できるところで代表的なのは、お名前.comとムームードメイン、バリュードメインなどでしょうか。コントロールパネルのUIが軽かったように思ったので、ムームードメインにしました。名前が可愛いですし。サイトは「ドメイン取得は【ムームードメイン】最安値99円！」。

ドメインの管理は ICANN -> レジストリ -> レジストラ -> リセラーという階層構造になっていて、.jp以外は、ムームードメインはリセラーで、レジストラであるお名前.comと契約しているという形らしいので、結局管理自体はお名前.comの範疇になるようです。なお、ICANNはThe Internet Corporation for Assigned Namesand Numbers の略です。

DNSの設定

DNSの設定について。大事な設定です。私はこのDNSサーバーの設定でミスをしました。何をミスしたのかというと、ムームードメインで、hack-le.comについて、DNSサーバーをまだ使わない設定になっていました。これでは、いくら設定をしたところで意味が無い。阿呆なミスでした。その結果、しばらく誤ったキャッシュがプロバイダのDNSサーバーに残ってしまったのか、しばらく自分だけ自分の家に入れない、みたいな阿呆な状況になりました(自分だけであれば、MacやLinuxならば、/etc/hostsを編集して、一時的に当該ドメインとIPアドレスを直接的に結びつけるとよいでしょう）。

DNSとは

DNSとは Domain Name System の略で、ドメイン名とIPアドレスを変換する仕組みです。郵便番号と住所を紐付けるようなものですね。郵便番号だけだと、正確な住所にはなりませんが。自分の管理するドメインについて、どのDNSで管理するか、設定する必要があります。これをしないと、ドメインがネットの世界で知れ渡らず、ドメイン名でアクセスできなくなってしまいます。

設定

したがって、DNSの設定は大事です。「独自ドメインを設定する (ムームードメインの場合) - ライブドアブログのヘルプ（PC向け）」にのっとっておこないます。

Aレコードの設定を、と言われますが、DNSにおいてAとはAddress、つまりIPアドレスのことです。LivedoorのIPアドレスに飛ばすように設定するわけです。CNAMEとはCanonical Name、つまり別名で、wwwのように、サブドメインを使った運用をするときに使います。昨今はサブドメインも流行らなくなりました。www、あまり見なくなりましたね。

Livedoorブログの変更

Livedoorブログ内のことについては、公式のヘルプがあてになります。Livedoorブログは、なかなかどうして公式ヘルプが充実していると思います。

URLの変更

URLの変更は簡単です。「URL・ドメインの設定をする - ライブドアブログのヘルプ（PC向け）」にのっとって、管理ページより、「ブログ設定」→「ブログURL」→「独自ドメインを使用する」。このタイミングで、すべての記事のURLが書き換わります。旧URLからはリダイレクトで転送されるので、問題ありません。

このとき、DNSの設定がうまくいっていないと、適切なところに飛べず、レジストラの使用されていないIPアドレスのページにいったりします。前述したように、私の場合そうなってしまい、さらに悪いことに、その後DNSの設定をなおしても、どうもキャッシュがプロバイダのDNSサーバーに残ってしまったのか、宅内から自サイトにアクセスできない状況が2,3日ほど続いてしまいました。

記事内にあるURLの変更

記事を一括変換します。「過去の記事内容を一括で編集する - ライブドアブログのヘルプ（PC向け）」にあるとおり、インポート、エクスポート機能を利用します。これは問題なくすぐに終わりました。有料プランのみで利用できる、と書いていますが、現在Livedoorブログに有料プランはありません（お金払うからスマホサイトの広告消したいのですが…）。

アフィリエイト、アナリティクスの手続き

忘れがちなのが、各種サービスの設定です。特にお金の絡むやつはちゃんとしておかないと、後々問題になると面倒ですからねぇ…。

Amazonアフィリエイト

Amazonのアフィリエイト規約は、調べているとけっこう色々と規約違反で憂き目を見た人の話を聞きます。Amazonは、Googleと同じくらい、あまり嫌われたくない企業です。しかしまぁ、時折DRMについてこぼす以外は、Amazonにとって不都合なことも書いていませんし（Fire TV Stickは素晴らしいと書いていますし！）、一般的に世間様に顔向けできないようなことも書いておりませんので、手続きさえちゃんとすれば、まず問題はないはずです。Amazonのおかげで、クロネコと佐川と郵便局の人に顔を覚えられた上客でもあります。手順を踏めば、無下にはされなかろう。

しかし、その手順というのがたいへんにわかりづらいのです。恐らく、先進的でグローバルなイメージとは裏腹に、社内はけっこう縦割りで区分けされているのではないかと思います。サイトの変更手続きは、なかなか妙です。

アソシエイト管理ページのトップから、右上の「アソシエイトアカウントの管理」→「Webサイト情報の確認」そして「※登録Webサイトの追加・変更の場合は、事前にこちらからご連絡ください。」のこちらから、に貼られているリンクを踏みます。で、そこでサイトを引っ越した旨をまず報告するのです。

この「事前に」というのがどれくらい事前なのかわからず、最初に、まず引っ越し前に、「ドメインを変更する予定です」という報告をしたところ、「引越し先のURLでサイトが確認できず申請を却下しました」的なメールをもらいました。どうやら、引っ越した後に申請しないといけないらしい。

それで、引っ越した後に再度申請。この時点で、改めて審査されます。人によっては、ここで落とされた、という人もけっこういるようです。私も、落とされたりアフィリエイトリンクを削除してから報告せよとか言われたりしたら面倒だなぁと思ったのですが（それでなんとかならないことはありませんが…）、無事審査を通り承認されました。まともに記事があって、かつアカウントがAmazonのお得意さまであれば、喧嘩腰でない限りそうそう落ちないように思います。

で、審査が終わってよかったよかったで終わりではなくて、この後に、自分で、「アソシエイトアカウントの管理」→「Webサイト情報の確認」よりURLの変更をしないといけません。まぁ、これを忘れたからといって、ただちに制裁を受ける、なんてことはまずないと思いますが、問題が起きると面倒臭い。

なお、当ブログに時々あるAmazonの商品リンクは、アフィリエイトです。どうせリンクを張るのであれば、ちょっとでも小銭になると嬉しいな、くらいのもので、実際、明日はちょっといいお昼ごはんが食べられるぞ、くらいの収入にしかなっていません。お金よりはモチベーションの意味で励みになります。ただ、セッション比で考えるとかなり少ない額ではあるようです。そういうサイトではないとはいえ、サイトの価値を測る一つのバロメーターと言えますし、良い記事を書くことが第一にしても、ちょっと考えるべきことはあるのかなぁとも思います。

Googleアナリティクス

Google アナリティクスのサイト変更については、「アナリティクス設定」→「プロパティ設定」→「デフォルトのURL」を変更をしました。また、もう一つ忘れてはいけないのが、「管理」→「ビュー」→「ビュー設定」より「ウェブサイトのURL」を変更することです。これをしておかないと、過アナリティクスで表示される相対URLを踏むと、旧アドレスに飛んでしまいます。まぁ、解析結果そのものには影響しないのですが。

問題はSearch Console（旧ウェブマスター）のほうです。Search Consoleでは、通常アドレス変更時には「アドレス変更ツール」を利用するのですけれど、以下のように言われてしまいます。

ルートレベルのドメインとサブドメインのみに制限

独自ドメインでないと、こういう制限もあるわけです。

まぁ、リダイレクト設定もちゃんとしていますし、新アドレスについては新たに登録することにして、あとはGoogleさんにサイト移転のことを気づいてもらうより他ありません。

アクセスの変動

本節は2016年8月10日に追記しました。

こればかりはケース・バイ・ケースだと思いますが、当サイトの場合について記録しておきます。まず、引越してからしばらくはアクセスに変動はありませんでした。しかし、一週間ほどすると、一気に半分に激減し、その後1日、2日ほどえ3/4程度まで回復しました。その後は比較的安定し、時折緩やかな上昇傾向が見られ、二ヶ月半ばかりした頃には、引越し以前と同水準のアクセスに戻りました。

サイトにある記事の性質によるところが大きいので、必ずこうなるとは思いません。他の人の話を聞くと、短期的にはアクセスが落ちたという人をよく見ましたが、実態はどうやら。とはいえ、真っ当に運用されているサイトであれば、基本的に時間が解決してくれる問題だと思います。

参考記事

参考にしました。ありがとうございます。

ドメインを変更して、自サイトにアクセスできない憂き目を見る

Tue, 29 Mar 2016 01:07:03 +0900

当ブログもようやく独自ドメインに移行しました。まだリンクの張替えなど済んでいませんが、アクセス解析の設定変更や、Amazonアフィリエイトの変更手続きなども済み、まぁたいへんなところはだいたい終わったかなという感じです。

自分のブログにアクセスできない阿呆

それで、情けないことに、しばらく自分のブログにアクセスできないでいました。正確には、自宅の契約しているプロバイダ経由では、といったところでしょうか。自サイトにアクセスすると、使用されていないドメインにアクセスしたときなどに表示されるページに飛ばされるのです。最初はまぁ、ああDNSの設定を誤っていたからなぁと思ったのですが、治してもそれが続く。誤ったキャッシュが残ってしまっているのだろうか、と思い、ルータやらPCやらブラウザやらで色々クリアしてもダメ。では、とWi-fiを経由せずにスマホでアクセスすると、正常。ふむ。プロバイダのDNSサーバーかな、と思い、外部のDNSサーバー経由でやってみたところ、正常に表示されました。

ああ、やっぱりか…と思ったものの、これはもう私にどうこうできることではありませんから、時がたつのを待つしかありません。で、今になって、ようやく安定して繋がるようになりました。独自ドメインとはいえ、Livedoorブログの敷地を借りてる身、専用の固定IPアドレスがあるわけではありませんから、/etc/hostsで無理矢理というわけにもいかず、短期間とはいえ、自分のブログに自宅から自由にアクセスできないという、なんとも情けない事態でした。ドメインの変更をするだけでもこれだけ面倒臭いのだから、いざ実際にサーバーを引っ越したら、また色々起きるんでしょうねぇ…まぁ、これも経験でしょうか。

サイトアドレスを変更しました

Sat, 26 Mar 2016 20:20:54 +0900

独自ドメインを取得し、設定しました。これに伴い、サイトアドレスが変更となりました。サイト内のアドレス表記の変更や、アクセス解析の登録情報変更など、まだ完全には引っ越しは終わっていませんが、アドレスについては旧URLからリダイレクトされるので、閲覧側が意識することは当面ありません（追記：RSSフィードに登録してくださっている方は、変更が必要です。お手数おかけします）。

独自ドメインを取得

最初DNSの設定を誤っていて、ナイスタイミングで訪れた方は正常にページが表示されなかったと思われます。たいへん申し訳ないのですが、謝っても声は届かないのが辛いところです。ちなみに私は、なかなか自サイトに繋がってくれず、DNSキャッシュをクリアしました（参考：「OS X で DNS キャッシュをリセットする - Apple サポート」）。追記：うーん、うまくページに辿りつけないことが多いです。DNSの設定を間違えていたせいかな。それならば時間が解決してくれるでしょうけれど、うーん、不手際ですね…。

将来的には、Livedoorブログから独立してどこかVPSでも借りて、自由にやりたいものです。まぁ、まだ先の話ですが。当ブログとは他に、適当に運用している趣味趣味ブログがあるので、そちらで運用のノウハウを学んでからにしたいと考えています。まぁ、URLが現在のアドレスとしてGoogleなどに認知されるまで待たねばなりませんし。

やはり自分のドメインを持ちたい

アドレス変更は、サイトを運営する者にとってはなかなかたいへんなものです。作業そのものが面倒であることはもちろんですが、地道に積み上げてきた検索エンジンからのサイト評価もリセットされますし、せっかく自分の記事を気に入ってくれてリンクをしてくれた人に、リンク切れの憂き目をあわせてしまうのも気が引けます。それでも、借り物ではない自分のドメインというのは、やはり欲しいのです。

思えば、ブログを始めてもう三年半。途中死にブログ状態になったりしながらも、もっと肩の力を抜いて、自分の読みたいものを書けばよいのではないか、と気楽に更新するようになってからは、記事数も増え、それに比例してアクセスもそれなりにいただけるようになり、日々の励みになりました。元々日記を書いていた私にとって、このブログというのは性に合っているらしく、ずっと続けたいと思っています。

時々は少しでも人の役にたつことがあればよいなと思いながら、できる限りの良い記事を書いていく所存です。今後ともよろしくお願い致します。

独自ドメインへの移行を検討中

Sat, 05 Mar 2016 12:58:20 +0900

ブログを始めてからもうすぐ三年半になります。記事数は300を超え、800セッション/日程度のアクセスがあるので、まぁこの手の個人ブログとしては中堅どころと言ってよいのではないでしょうか。それなりに人様の役に立つのことのできた記事もいくつかはあるのではないかと思います。

ブログを自分のものにしたい

さて、本ブログはLivedoorブログでスペースを借りてやらせていただいているものです。この無料ブログというシステムは実に気軽に始めることができるたいへんよいもので、なんでもよいから「始める」ということがもっとも肝要なことですから、極限まで敷居を下げてくれたLivedoorブログについて、私は基本的に感謝の念があります。しかしながら、こうして長いこと続けていると、人様の敷地で続けていることになんとなく違和感を感じるようになってきました。また、自分の好き勝手なデザインにしようと思うと、無料ブログはWordPressよりも却って手間がかかることがあるという実用上の問題もあります。

当サイトは、その性質上PCからのアクセスが多く、私自身もPCで閲覧することが多いのですが、最近はスマートフォンでアクセスすることが多くなってきました。スマートフォン版は別のデザイン設定となっていて、昨今の流れを考えるとやや不格好です。また、スマホ版は広告も表示されます。Livedoorブログは広告の非表示設定ができて、いったいどうやって収入を？と不思議だったのですが、最近はスマートフォンでの閲覧が主流ですから、PC版の広告というのは大した問題ではないのでしょうね。最近他にもブログ（それも趣味全開であまり人の役に立たないブログ）を始めてみましたが、そちらはモバイルからのアクセスが主流です。時代は変わっています。

まぁ当サイトはAmazonのアフィリエイト・リンクを貼らせてもらっているくらいなので、広告自体に拒絶反応はないのですが、どうせなら広告も自分で選びたいものです。また、PCとスマホでデザイン設定を同一にしたいとか、ソースコードを綺麗に表示したいとか、そういった欲求もあり、そうするとやはり好き勝手にできるVPS上でWordPressによりブログ構築、というのがもっとも良い選択ということになります。

引っ越しの憂鬱

しかしブログの引っ越しは、考えようによっては現実の住居の引っ越しよりも面倒かもしれません。戸籍などがあるわけではありませんから、ブログのアドレスが変更されれば、それまでに培われてきた被リンクや検索エンジンからの評価などはすべてリセットされます。長期的にはそれでも大した問題にはなるまいとも思いつつ、やはりその心理的抵抗感は大きい。少なくとも、短期的な来客数は激減するものと思いますし、良いと思って当ブログの記事を紹介してくれた人にリンク切れの憂き目を合わせてしまうというのも、なんだか。まぁそのあたりは無理やりリダイレクトさせるなど、まぁ対応のしようもあるでしょうが、それにしても手間です。

とはいえ、どうやら私はブログを続けるということに関しては向いている人間のようなので、できれば一生涯ブログを続けたいと考えています。そうすると、やはり独自ドメインで、どこかのVPSを利用してWordPressでブログを構築するのが一番良いはずです。時間はかかりそうですが、移行の準備を進めようと思います。

まぁ、まずは独自ドメインの取得でしょうか。ひとまず、Livedoorブログのままで、独自ドメインを数ヶ月ほど利用しようかと思っています。というのも、Livedoorブログを利用する限りにおいては、独自ドメインに変更してもLivedoor側でリダイレクトを行ってくれるからです。独自ドメインに移行するだけでも、今後の引っ越しが随分楽になります。まぁ、リダイレクトするとはいえドメインが変わって検索エンジンからの評価がどうなるのかなど、気にはなりますが、まぁブログは趣味ですし、アクセスの変化を身をもって経験できるよい機会だと考えることにしましょう。

そういえば、当ブログの記事をそのまま写したと思われるコピーサイトを見たことがありますが（本当にやる人いるんですね）、記事が重複した場合、記事生成された日付から、検索エンジンからはあちらが本物という認定をされたりしてしまうのでしょうか。そうなったらなんだか面白いですね。

一からやり直すという手は？

ところで、このブログはそのままにしておいて、別のブログを始める、という手段もあります。実際これについては考えているところもあるのですが、やはり過去の記事が別所にあるというのはなんだか妙な気持ちがしますし、メンテナンスの行き届かないブログを放置するのも気が引けますので、やはり引っ越しというのが筋でしょう。

ただ一点、気になっている記事があります。それは当ブログでもっともアクセスをいただいている「ブラック研究室の見分け方」という記事です。この記事は当ブログの中で浮島のごとく浮いているのですが、ダントツで人気の記事です。この記事はちょっと特別な立ち位置で、記事自体がもはや一つのサイトのような様相を呈していまして、これのURLが変更されるのは、できれば避けたい。しかしこの記事だけを切り離して引っ越しというわけにもいきませんし、まぁ仕方ないとは思うのですが、心残りになりそうです。

2015年雑感…デジモノばっかり

Thu, 31 Dec 2015 22:56:15 +0900

更新すればアクセスは上がる

もうついに2015年が終わろうとしています。本ブログ的には、今年はこれまでになく頑張った年で、7月くらいから更新頻度を一気に高めました。それまではほとんど死にブログ状態だったので、こういうパターンはけっこう珍しいのではないかなと思います。今ちょっとGoogleアナリティクスを見てみたら、6月と12月を比較すると、アクセスは2.5倍(8400->22000)、PVは3倍(10,0000->31,000)になっていて驚きました……更新頻度はバカにできないですね。ただいつ頃からかトラッキングコードの挿入に若干の不備があったようで、一番変化の大きかった7月から8月のデータがまるっと抜けていたりと、昔のデータの信憑性はちょっと怪しいのですが。まぁでもかなり増えたのは間違いありません。

検索エンジンからの流入がメインのブログなので、元々新規率の非常に高いブログだったのですが、それが89%から30%になりました。これがよいのかどうかはよくわかりません。ただそんなに同じ人がきているのか？というのはちょっと意外でした。一見さんばかりだと思っていたので。まぁ有難いことですが。

というわけで、2016年もできるだけ更新頻度を下げずに頑張りたいと思います。

ちなみにここ一週間は全然更新していないのですが、年末でかなりドタバタしていたので仕方ありません。いくつか書き上がりそうな記事もありつつ、どれも完了しないまま今日に至りました。今日は異常に眠かった。

2015年あれこれ

記事一覧をざっと見ながら、心にひっかかったことをいくつか。

きっと盛り上がらない電子書籍

2015年になりましたが、電子書籍は結局今年も盛り上がりませんでした。来年もきっと盛り上がらないのだろうなと思います。どこか大手が読み放題とか定額レンタルとか開始したら大盛り上がりでしょうけれど、動きがあるとすればAmazonですが、ないでしょうねぇ…。後は、もっとありえないでしょうけれど、DRM禁止とかね。素敵な夢です。夢ですが。

電子書籍は、今変に安定してしまっているのが問題だと思います。

そろそろスマートなんとかはもういいかと

Apple Watchが販売されて久しいですが、もうほとんど話題に上らなくなりました。まぁでも、スマートウォッチ市場は元々がそんなものですし、これがiPhoneのように爆発的なヒットになると本気で信じていた人はあまりいないのでないかと思います。バッテリーの問題が大きいですよねぇ……。

私はWithingsの見た目アナログ時計なActivitéを購入しました。歩数計、睡眠計などがついた腕時計です。元々アクティビティトラッカーが欲しかったし、腕時計も必要だなと考えるようになっていたので、そんな私にはうってつけのアイテムでした。これはけっこう身の回りの人からの評判も良いです。Apple Watchもそうですが、汎用機として使うにはバッテリーがなぁ……腕にまいたところで、メールやSNSに気づけなかった言い訳が減るだけですし……。まだちょっと、汎用機としては早いかなと思います。

ところで、そろそろなんでもかんでも頭にスマートつけるのはもうよいのではないかとも思う今日この頃です。もうスマートとついているだけで、自分などはかなり眉唾だなと思いながら見るようになりました。

大手参入でストリーミングが一段メジャーに

Apple MusicとAmazon プライムビデオ（プライムミュージック）はかなりインパクトがありました。元々SpotifyやらHuluやらありましたけれど、やはり大手がやると各種メディアも取り上げるので、一気にオカンも知っているサービスにのし上がりました。なんだかんだいいながら、テレビで大々的に取り上げられない限り、結局オタクの趣味で一蹴されてしまうのは、いまだに変わらないんですよねぇ…。

まぁそう言いながらも、私もAppleとAmazonの参入でようやくストリーミングサービスに手を出したのですから、まぁミーハーなものです。どちらもなかなか楽しい。Apple Musicは本当はもっと新しい音楽を追わないとと思って加入したんですけれど、結局昔聴けなかったアルバムばかり聴いていてダメです。来年はもっと広げたい。しかしむしろ古きをより掘り下げるほうが私向きか。意外とけっこうマイナーなところがそろっていて嬉しい。Amazon プライムビデオは、孤独のグルメのドラマが見れているだけでよかったなと。Fire TV Stickと合わせると、家族で楽しめて非常に素晴らしい。こういう連携はやはり大手が強いですね。業界を牽引してきたスタートアップにも負けないでほしいですが。

急激に見るようになったIoT

言葉自体はそこそこ前からあったと思うのですが、IoTは今年になってやたらと見かけるようになった印象です。なんだろう？2016年も引き続き騒がれそうです。何か契機があったような感じもしないのですが、トレンドですね。私は眉唾だと思っているのですが（「IoT の期待感と現実 : 或る阿呆の記」）。

これを受けてか、Raspberry Pi特集があちこちの雑誌でされて、最初は嬉しかったもののだんだん食傷気味に。その中でもCQ出版のトランジスタ技術とInterfaceはマニアックなところまで踏み込んでいましたね。Raspberry Piはもっと使いこなしたい。

Mac mini は音沙汰無し

今年はMac miniは特に動きがありませんでした。当ブログのコメントでも指摘があったのですが、まぁもうMacは全体的に二年周期に入ってしまったということなんでしょう。PCのスペックも停滞して久しいですから、それはよいのですが、それにしても2014年の仕様がいまだに最新とはなぁ。

結局、手持ちのMac mini 2012にSSD480GBとハードディスク1TBを追加してFusion Driveとして、お茶を濁しました。そうすると、PCへの物欲がすっと消えて、ああやはり拡張できるということは大事だなぁと。それとも、だからこそ拡張性をなくそうとしているのか？寂しい動きです。次のPC購入はいつになることやら……。本当に壊れるまで使えそうですMac mini 2012。

AndroidよりChromebookに期待

先日Chromebookを購入しました。今のところ宅内でブログ記事を更新したりする程度にしか使っていませんが、なかなか面白い。ChromeのエクステンションにあるWriteboxなどは、テキストエディタとして想像以上に勝手が良くて、Simplenoteに置き換わりそうです。

正直Android端末についてはもう大方出尽くしたと思っていて、実際2015年特に面白いこともありませんでしたし、2016年もそう変わらないと思うのですが、Chromebookはまだまだこれからかと思います。OSはもう十分良いものですから、これに加えて各種便利なエクステンションや、Emacsキーバインドの実現（Macを真似してもいいんですよ！） 、タッチパッドのジェスチャーをユーザー定義、Androidアプリの変換（現状でも試験的に出来るものはあるのですが）などがあると嬉しいですね。ハードウェアは、とにかく重さが課題でしょうか。軽くて薄くて値段が熟れた一品が国内で出ると、最高だなぁ。ASUSが出したFlip C100PAなんて、かなり面白いと思います。タッチパネルがあって、軽くて、小さくて、コンバーチブルで、バッテリーもそこそこ、ちょっと早すぎた感はありますが、良いんじゃないでしょうか。Androidアプリが使えるようになれば、化けるのでしょうけれど……。

来年はもっと深い記事がかけるように

記事を見なおしてみると、デジモノガジェットのレビューと場当たり的なトラブルシューティングがたいていでした。あとは、まだ日本語の情報が多いとは言えないRaspberry Pi関連で、センサ関連のことなど。まぁ今の自分はこんな程度ということがよく表れているように思います。来年は、もっと技術的にも深い記事が書けるよう精進したい。

現実世界の話をするなら、仕事ももうそろそろ転機を迎えなくては……来年30歳になると思うと、恐ろしい。友人の第二次結婚式ラッシュも一段落し、自分もそろそろ考えにゃならんなとかいつまで自由にいられるんだろうとか憂鬱なことを考えつつ、さよならバイバイ20代。

カテゴリアーカイブを見出しのみに

Fri, 06 Nov 2015 20:17:18 +0900

このブログを一番閲覧しているのは間違いなく私自身で、考えたことや調べたこと、やってみたことの備忘録として活用しているのですが、ブログというのはサイト全体を鳥瞰するのが難しいものですから（そのためあまり好きではなかった）、整理の仕方が肝心です。

ブログの整理

まぁ、Wordpressを使ってしっかりと見やすいようなブログを作成している人もよくいますが、ここはLivedoorの提供するデザインテンプレートに則ったお仕着せの無料ブログですし、あまり贅沢は言えません。どうにも、Web周りは不勉強です。

さて、やはりカテゴリの整理が見やすさには重要だと思い、ちょくちょく見なおしているのですが、思ったことを雑多に書き散らしているせいもあり、いつのまにやら随分長くなってしまいました。しかし、分けようとするとこうなってしまう…もう少し整理できればよいのですが。そして、カテゴリを開くと記事が本文つきでダラダラと続くので、どうにも一覧性が悪い。せめてこれだけでもまずはどうにかしたい。というわけで、カテゴリ別に閲覧するときは、本文抜きで見出しのみ表示するようにしてみました。下の画像のような感じです。

やったこと

Livedoor公式ヘルプ記事「アーカイブページで本文を省略してタイトルだけにする - ライブドアブログのヘルプ（PC向け）」を参考にしました。「ブログ設定」→「ブログパーツ設定」→「カスタマイズ」→「カテゴリアーカイブ」より、<div class=“article-body”> … </div> および <div class=“article-footer”> … </div> をまるっとコメントアウトすると、本文およびコメントなどのフッター部分が非表示となります。が、このままでは見出し部分がやけに大きく取られてしまっていたので、雑ですが、「CSS」タブに以下を追記しました。

`.page-category .article{ padding-top: 1px; height: 44px; } `

heightをピクセルで固定するのは非常に雑だと、CSSに疎い自分にもわかります。他に良いやり方があるのは想像がつきますが、今の私の知識ではこれが一番楽でした。タイトルが3行以上になるような、長いものだとはみ出ます。したがって、ライトノベルのレビューには考えものです（いつくらいからか、妙なタイトルをよく見るようになりました）。しかしまぁ、当ブログとしてはひとまずこんなものでしょうか。

他に、日付の装飾を取っ払いました。

それにしても、一覧にすると広告の位置がなかなか邪魔でした。そのため、お世話になっているLivedoorさんには申し訳ないのですが、記事下広告を非表示としました。とはいえ、モバイル版の広告はいじれません。このサイトは記事の性質故かPCからのアクセスが多いのですが、世間の潮流としてはモバイルが主流です。PCの広告は、もはやあってもなくても変わらないのかもしれません。

iOS9 で Crystal を導入し、SafariでAmazonの広告がブロックされるのを確認

Sun, 27 Sep 2015 02:32:10 +0900

ようやく、というべきかもしれません。iOS 9で、限定的にではありますが、広告ブロックが実装されました。といっても、今のところ新たに有料アプリ（Crystalは120円）を購入する必要があります。また、Safari内だけです。が、利用する人にとっては大きなメリットがあるでしょう。

当ブログの広告がブロックされるのを確認

当ブログは、三ヶ月ほど前よりAmazonアソシエイトに参加しています。アフィリエイトは実際どんなものなのかな、と気になったので、やってみることにしました。収入は、平均すると月に一回お昼ごはんを食べられるかどうかといったところ。それでもまぁ、自分のサイトを経由した買い物があるのを見ると嬉しくなるものです。

それはともかくとして、当ブログのAmazonの広告はブロックされるかな？と確認しました。以下です。こんな感じです。見事にブロックされています。ぽっかりと不自然な隙間があれば、そこには広告があったということになりましょう。ここは、詰めたほうがよいように思えますので、いずれ改善されるかもしれません。タブレットやスマートフォンでの広告ブロックが悲願だった人は多いのではないでしょうか。

当ブログの広告スタンス

前述した通り、当ブログはAmazonアソシエイトに参加しております。収入自体は雀の涙ではありますが、参加している以上、私は広告を否定する者ではありません。しかしながら、Webには最低な広告が看過できないほどに溢れている、ということも事実だと思います。特にアダルトな要素のある広告については辟易としますし、そういうのに限って追尾型という悪夢。いったい金をかけて人に悪印象を与えて何の意味があるんだろう？と疑問に思うのですが、実際にある以上それなりに効果があるということかもしれません。けれども、それならば何をしてもよい、ということにはならず、「規制されていないじゃないか」とやりたい放題にしていれば、必要以上の締め付けが待っています（だからこそ性表現にはどのメディアも気を使っているわけで）。

広告は、本来忌むべきものではありません。「広告ブロックについての私見 | 辺境社会研究室」の記事はたいへん示唆的であり、特に以下の記述はなるほどと思いました。

中には良い広告があって、ユーザもその便益を受けていたはずだ。しかし残念ながら、ユーザはそれを信じない。広告が良いコンテンツを提供しているとき、人はそれを広告と感じない。

真の広告は広告と気づかない、というのは逆説的ですが事実でしょう。それはいわゆるステルス・マーケティングとはまったく違うものです。良い広告ほど印象に残らないとなれば、個人の経験から広告全体の質を把握することは不可能に近く、実は思われているよりも広告というのは有用に機能しているのかもしれません。しかし、だからといってタチの悪い広告があって良いということにはなりませんから、やはり広告ブロックの需要というのはなくならないでしょうし、それもまた理解されるべきことです。

当ブログは、広告についても、広告ブロックについても否定しません。私自身、他の人の紹介記事を参考にしてものを購入するということは日常茶飯事ですから、アフィリエイトの仕組みは良い物だと思っています。そう思えばこそ私もプログラムに参加しているのです。そもそも、現在のインターネットにおいて広告の否定はネットの否定に繋がります。良かれ悪しかれ、それくらい今の広告はネットに根付いている。ネットをしていて、Googleのお世話になっていない人はいません。苦い薬かもしれませんが。

しかしながら、タチの悪い広告が溢れているのも事実なので、とにかく広告をブロックしたい、という要求は理解できるものであり、そのために当ブログの広告がブロックされることを私は厭いません。まぁ、それはこのブログが趣味で書かれたもので、収入自体があってないようなものだから、広告を生業にしている人であればそうも言ってられないだろうとは思います。

といいますか、私自身がPCではAdblockのような広告ブロックの拡張機能を使っていますので、人様のやることについてアレコレ言えるわけがありません！

Web全体から見れば自浄作用

Appleの動向はなんでもかんでも針小棒大に騒ぎ立てるまとめサイトも、本件については実に静かなものです。しかし、今のところ影響はわずかだろうという見方が強そうで（参考：「iOS9の広告ブロック機能が与える損失額は「わずか」10億ドル - iPhone Mania」）、私もそう思います。デフォルトで機能すれば別でしょうが、現在の有料アプリを購入し、設定する、というやり方では、まぁ今までPCでもAdblockの拡張機能を導入していた層のさらにまた一部しか使わないでしょう。また、こういうのは薬と病気の関係みたいなもので、いくら規制を強めたところで、イタチごっこになるものです。

それでも、Apple直々の措置ということで、特に広告業界やアフィリエイト業界へのインパクトはかなり大きい模様。しっぺ返しがきた、という見方もあるようですが、私としては全体の中で自浄作用が働いている、と思えます。Web全体から見れば、一部の企業によりタチの悪い広告が蔓延し、それに対応する形でIT企業の大手が対策をとった、というだけです。別に政府が法律を定めたわけでも、独裁国家が広告を攻撃したわけでも、テロリストが広告やめろとGoogleを爆撃したわけでもありません。Webという大きな枠組で見れば、庭の中で起きたことです。これはつまり自浄だと思います。これを受けて、Webの広告のあり方も変化していくのでしょう。良い方向に変わるとよいのですが。

細々とアフィリエイトの真似事を始めてから、そのうち当ブログの広告についても一つ書かないといけないな、と考えていたので、今回は良い機会でした。ところで、当ブログで唯一サイドバーに陣取って広告リンクが貼られている「UNIXという考え方」という本ですが、一冊も売れていません。本当に良い本なので興味のある方は是非。私は現在読みなおし4週目です。広告以上！

記事を闇雲に書いても仕方ないといっても、記事が受けるかは上げてみるまでわからない

Sat, 12 Sep 2015 11:56:20 +0900

ブログをしている人間なら、必ず一度は目にすることになる助言が「なんでもいいからとにかく毎日記事を書け」というアドバイスです。やってみればわかることですが、これはなかなかたいへんです。どんな文章でも、ちゃんと書けばそれなりに時間がかかります。

量より質というものの

そうして頑張って書いたところで、果たしていったいこの記事を誰が読むのだろう？という疑問が脳裏をよぎります。そしてアクセス解析というのをしてみると、たいていの記事はやはりあまり読まれていない。ブログを始める人は多いが、続けられる人は多くない。

そんな中で「毎日書け」というのは、なかなかどうしてたいへんなアドバイスといえます。そこへ目につくのが「アクセスは記事数に比例するわけではない」という主張。曰く、量より質。アクセスの大半は少数の記事が占める。毎日書くことに拘泥せず、人を集める質の高い記事を書け。

その記事が求められているかは上げてみるまでわからない

量より質とはまったく正論だと思うのです。問題はその記事が人を集めるかは上げてみるまでわからないことです。「ちゃんと書いた記事はそれなりにアクセスを集められる」という主張もありますし、それについては頷けるところもあるのですが、しかしブログ全体のアクセスに寄与している記事を見てみると、私としては、必ずしも時間をかけて丁寧に書いた、質について自信のある記事ばかりではない…というより、むしろそういった記事は正直なところ少数で、「この記事がアクセスされるものなのか」と驚くことのほうが多いです。

まぁ考えて見れば、温度センサLM75Bや大昔のROMライターPECKER11の使用方法について書かれた記事よりも、Mac miniの新型で素敵なのが出たらいいなぁというつぶやきのほうがまだしも面白く感じられるという人は多いでしょう。それはそうだろうなと思いつつ、あの記事ただのぼやきなんだよな、と思ったり、なんだり。

不思議なもので、マスというのは平均的であるはずなのですが、一人ひとりを見てみると、誰も彼も平均とは外れた趣味嗜好を持っているものです。平均的嗜好とは、あらゆる人がもつ嗜好の否定論理和ではないかと疑いたくなるほどです。これはいけると思ったものが、だいたい外れるのも道理といえましょう。そうして考えると、打てる玉は多いほうが良い。10回打てば9回外れるかもしれないが、1回が当たればそれで十分なのだから、よーく狙って一回だけ打つよりも、だいたいで10回打つほうが良いというものです。

毎日書けばチャンスは増える

そういうわけですから、やる気があるなら毎日書け、というにべもないアドバイスは、結果的にまぁそこそこ的を射ていると思うのです。別に決心したわけではないのですが、当ブログもここ二ヶ月ほどはできるだけ毎日記事を更新しております。結果、日によるものの、概ねとしてアクセスは以前より30%程度増えているようです。まぁ、いつまで続くのかはわかりませんし、果たしてどれだけ人様の役に立てているのかな、とも思うのですが…。まぁ、役に立つかというのもありますが、書いていて楽しいか、というのもあるので、プレッシャーにならない程度にマイペースにやっていきたいものです。

Livedoorブログで子カテゴリにインデントと – (ハイフン) をつけた

Tue, 07 Jul 2015 00:04:05 +0900

あまりちゃんと使ってこなかったカテゴリ機能を、いい加減少しはまともにしようと思い、整理しています。とりあえずせっかくカテゴリに親子を作れるのだからと、子カテゴリを作りました。しかし、恐らくこれはブログデザインに何を採用しているかによると思うのですが、当ブログが使っているデザインでは、そのままだと子カテゴリと親カテゴリがそのまま並んでしまい、たいへんわかりづらい（下図）。

子カテゴリにインデントをつけ、更に行頭に - (ハイフン) をつけることで、親子関係をハッキリさせようと思います。ライブドアのヘルプに参考記事があったので（「カテゴリの親子関係を作る - livedoor Blog ヘルプセンター」）それを参考にし、ブログ設定→カスタムJS→カスタマイズ→CSS タブレットの末尾に、以下のコードを追記しました。

`.sidebody.category-child { padding-left: 12px; } .sidebody.category-child:before { content: "- "; } `

.sidewrapper .side .sidebody.category-child …とするのが記事通りなのですが、.sidewrapperと.sideがよくわからなかったので.sidebory.category-childのみとしました。最初の命令で左に12pxの余白を取るように指示し、次の命令で行頭に - (ハイフン) をつけるように指示しています。結果は以下の様になります。

わかりやすくなったのではないでしょうか。まぁ一番大事なのは、どのようにカテゴリを作るかなのですが。

自分のブログを振り返り、また他人の目のつもりで当ブログを見返すと、ハードウェア単位で区分けするのがよいように思えました。また、こうしてカテゴリを分けることで、ああこのブログはこれらの話題が多いんだな、じゃあ次もこのへんで記事を書こうかな、なんていう考えも浮かんだので、カテゴリを考えるのは読者よりむしろブログ管理人にとって有益なことかもしれません。自分のブログがなんたるかを考えるよい機会と言えます。

Livedoorブログの編集にシンプルエディタを使ってタグ打ちで書くことにする

Fri, 08 Aug 2014 05:23:23 +0900

いつの間にかこの雑多なブログをはじめて二年近くたちました。通してみると、いったい何のブログなんだかよくわからない感じですが、なんだかんだで一日何百人かに継続して閲覧されているようで、少しは世の中にたっていたらいいなぁと思う今日この頃です。

ブログの編集にタグ打ち

そもそもブログサービスの良い所というのは、HTMLの知識がない人でも簡単にそれなりの見栄えのページが作れてしまうところなのでしょう。情報関係のことがめっぽう苦手な私の母でさえ、趣味仲間とアメブロで交流をしているようです(ところでアメブロにありがちな改行連発や装飾過多な文字列を見ていると、昔のテキストサイトを思い出します。やはり皆が通る道なのでしょうか？)。だからタグ打ちが標準ではないのも道理です。ところが、htmlタグを使ってある程度構造を意識した文章を書こうとすると、いろいろ不便なところがあるのですね。端的に言えば、Livedoorブログの標準エディタには「見出し」がないのです。そういったことを意識しない人向けということなのでしょうが…。自分でHTMLソースをある程度いじることもできるのですが、標準のエディタといったり来たりするとたいへん面倒くさい。まぁブログというのはそんなものなのだろうと思っていたのですが、ヘルプページをなんともなしに眺めていると、Livedoorではブログ設定でシンプルエディタに設定することでタグ打ちができるということを、いまさらながら知りました。

早速いくつかのページを編集してみると、なるほどこれは便利。pタグやhタグを入れて見出しや段落の設定がちゃんとできる。もちろんこれが私の母にとって最適なエディタでないことは自明ですが、少なくとも私にとってはこちらのほうが分かり良い。これからはこのシンプルエディタで編集をすることに決めました。

h1タグって複数あっても良いらしい

ところでhタグを使うにあたり、気になったのはテンプレートでどのレベルまでのhタグが使われているのかということでした。そこで自分のブログのソースコードを見てみると(Safariではソースコードを見るのに設定が必要で、最初わかりませんでした)、まずブログタイトルがh1タグで指定され、次にブログの説明文がh2タグ、そして記事タイトルがh1タグとなっていました。はて、大昔HTMLの勉強をしたとき、h1タグやh2タグは1ページに一つだと習ったような気がしたが、テンプレートの段階でh1タグが複数使われている。Livedoorブログのテンプレでそうなっているくらいだから、悪いことではないのだろうけれども、実際のところどうなのだろう？と調べてみると、やはりh1タグが複数あるのは悪いことではないとのこと。

参考 h1タグを複数入れるのは良くないことか？ | ラビットSEOブログ

上記サイトによれば「常識的に考えていい範囲なら大丈夫」とのことで、言われてみるとなるほどその通りです。というわけで、編集ではh2タグから使うことにしました。

ブログというのも面白い

私はいつも流行に周回遅れでして、今もっとも流行っているのはLINEやTwitter、FacebookのようなSNSだとわかっているのですが、そのあたりには近寄らず、いまさらながらブログを書いて喜んでいます。かつてブログ全盛の頃は、あまり好きになれなかったのですけれど、最近はむしろ好んで読むようになりました。もっとも、それは個人のHPページが廃れ、検索で引っかかるのがどこもかしこも判で押したように一緒のまとめブログばかりになってしまい(ChromeではGoogle謹製の拡張機能で、ほとんどのまとめブログを検索結果からブロックしていましたが、最近乗り換えを試みているSafariでは同様のことが簡単にできるものを今のところ見つけられておらず、ちょっとばかり不便です)、なんとかひっかかる個人のどうでもいいジョーク交じりなブログが相対的に良く見えるようになったということかもしれません。しかし自分でいざやってみるとブログは簡便で面白い。10年前からやっていればよかったかなと思う今日この頃です。