考察記事のサムネイルを統一し、SEOタイトルを見直した

実機作業はなし。サイトの整備に集中した一日。考察記事のサムネイルを全本統一し、GA4の分析をきっかけにLOG1〜LOG128の全記事タイトルを見直した。改善対象52本、変更不要76本。

やったこと

サムネイルデザインの統一

考察記事のサムネイル画像を全本入れ替えた。

以前は記事ごとにサムネイルのスタイルがバラバラだった。4コマ構成のものもあれば、シンプルなテキスト配置のものもあった。アーカイブページで並べると、明らかに統一感がなかった。

デザインの仕様は今日あらためて決めたわけではなく、すでに固まっていたものだ。BLACK + warm orange（#D4724A）の2色のみ。4コマパネル構成。グリッド背景・版ズレ・紙の質感あり。オレンジはメインアイコン1点のベタ塗りとアクセント細線のみで使い、他はすべてアウトライン。テキストはすべて英語表記。

この仕様をGeminiにプロンプトとして渡し、記事ごとにパネル内容（テーマ・キーワード・構成）だけを変えて生成する。プロンプトをプロジェクト化したことで、何本生成しても同じ文法のビジュアルが出てくる状態になっている。生成→確認→微調整のループが1本あたり5〜10分で回せる。

考察記事を対象に全本を入れ替えた。並べてみると、ようやくアーカイブページがアーカイブらしく見えてきた。

GA4で見えた構造

サムネイルの作業と並行して、GA4のデータを確認していた。期間は4月1日〜13日の13日間。

まず全体の数字から。

絶対数はまだ小さい。ただ、来た人は読んでいる。エンゲージメント時間1分11秒は、流し読みで終わっていない数字だ。

次にページ別の表示回数を見た。ここで気になる数字が出た。

LOG126「Generalist AI GEN-0を解剖する：シミュレーション×実世界データの戦い」が41ユニークユーザーを集めていた。

全体のアクティブユーザー253人のうち16%が、この1ページに来ている計算になる。他の考察記事は10〜15PV台が多い中で、一桁違う数字だった。

なぜLOG126だけが突出したのか。

理由はシンプルだった。タイトルに固有名詞が入っていた。「GEN-0」という、検索意図に直結するワードが記事と検索ユーザーを繋いでいた。GEN-0はFigureが発表したAIモデルで、リリース直後から検索ボリュームが上がっていた。LOG126はその内容を技術的に解説した記事だ。

考察記事はもともと「自分の思考のまとめ」として書いてきたもので、SEOや流入を意識したものではない。LOG126も同じ意図で書いた。ただタイトルの構造だけが違った。他の考察記事のタイトルを見ると、「デザインが利益率を決定するフィジカルAI時代の設計思想」「物理空間を解釈する『振る舞い』の設計」など、概念語で完結しているものが多い。本文には固有名詞が登場しているのに、タイトルに出てこない。

これは機会損失だ。内容は変えなくていい。タイトルだけ直せばいい。

まず5本を修正した

最初にGA4で気になった考察記事から手をつけた。本文を確認しながら、登場している固有名詞をタイトルに反映する作業だ。

修正した5本：

• LOG109「Boston Dynamicsが示した『身体で考える』ロボットと、問いの本質」 → 本文にBoston DynamicsとAtlasが具体的に登場しているのにタイトルに出ていなかった。

• LOG118「GoogleのRT-2とFigureが証明した：良い動きはデータ量で決まる」 → RT-2・Figure・Googleという3つの固有名詞が本文の核心にある。

• LOG128「Claude Codeのマルチエージェント設計がSim-to-Realループと同じ問いを解いていた」 → Claude Codeという固有名詞がタイトルに入っていなかった。

• LOG143「TeslaのEnd-to-Endニューラルネットから学ぶ：デモとデータを同時に生む設計」 → Tesla・End-to-Endという検索意図に直結するワードが本文に登場している。

• LOG145「大阪市の自動運転タクシーが示した：技術は完成する。でも社会は動かない」 → 大阪市・自動運転タクシーという具体的な固有名詞をタイトルに。

この5本を修正したところで、同じ問題が他にもあるはずだと気づいた。範囲を広げることにした。

LOG1〜LOG128を全件見直した

作業の流れを整理しておく。

Step 1：タイトル一覧の取得 サイトのスクリーンショットをPDFで撮影してClaudeに渡し、全記事のタイトルを読み取った。LOG1〜LOG147まで並んでいるスクリーンショットから、番号とタイトルをすべて抽出する。

Step 2：改善候補のリストアップ タイトルを見て「固有名詞が入っていない」と判断できる記事を優先度別に分類した。

• 🔴 最優先（検索価値がほぼゼロ）：「データを取る日」「カップが、動いた。」「ループが、回った。」など、内容が全く伝わらないもの

• 🟠 優先度高：内容はわかるが技術名・ツール名が抜けているもの

• 🟡 優先度中：概念は伝わるが固有名詞を追加できるもの

Step 3：改善案の作成 各記事の文脈から、本文に登場しているであろう固有名詞を推測して改善案を作成した。

Step 4：本文照合（これが最重要） 各記事のPDFをClaudeに送って、改善案と本文内容を照合した。

この照合のステップを省かなかったことが重要だった。Step 3で推測した固有名詞が、実際には本文に登場しないケースが複数あったからだ。

照合で見つかった誤り

照合の過程で発覚した問題を記録しておく。

存在しない企業名を入れたケース

LOG34の改善案として「FANUC・Boston Dynamics・DJI事例から学ぶ産業用AIの『信頼UI』設計」を提案していた。しかし本文を確認すると、FANUC・Boston Dynamics・DJIの記載はなかった。記事の実際の内容はROS 2 × Unity × mechArm 270を使った検証だった。

LOG53・LOG107・LOG119でも同様に、Boston Dynamics・FANUC・NVIDIA・Figureといった企業名を改善案に入れていたが、いずれも本文に記載がなかった。

存在しないツール名を入れたケース

「FigmaデザインをKPIへ変換」→ LOG43の本文にFigmaは登場しない。実際はUnity × ROS 2 × Dockerの話だった。

「GeminiとPhotoshopで作る」→ LOG7・LOG8・LOG9について提案したが、Photoshopは使っていない。正しくはFigmaだった。

存在しない技術を入れたケース

「Unity × NavMesh」→ LOG35・LOG37・LOG49について提案したが、それぞれNavMeshを使っていなかった。LOG35はPrefab × Namespace設計、LOG49はNurseWander.cs × Raycastの実装だった。

存在しないAIツールを入れたケース

「Claude・ChatGPT・Geminiの使い分け」→ LOG56の本文を確認するとGeminiだけで行った自己評価記事だった。ClaudeとChatGPTは登場しない。

LOG94の改善案に「INIT→GRASP→LIFT」と書いたが、実際のステートは「REACH_CUP→GRASP→LIFT→REACH_PLACE→LOWER→PLACE」の6ステートだった。INITというステートは存在しない。

タイトルに存在しない固有名詞を入れることは、SEO改善ではなく逆効果だ。検索でヒットしても本文と内容が食い違えば離脱率が上がる。それ以上に、読んだ人の信頼を失う。照合を経てから反映するという手順は省けない。

最終結果と方針

全128記事の判定結果：

• 改善対象：52記事

• 変更不要：76記事

変更不要と判断した76記事は、すでにタイトルに技術名・ツール名・固有名詞が入っているもの。たとえばLOG74「Gemini-Human-Cline 三位一体による自律ロボット開発フレームワーク」、LOG78「Claude×ChatGPT×Geminiで実現するLP制作ワークフロー」、LOG126「Generalist AI GEN-0を解剖する」などは最初から問題ない。

改善の主な方針：

LOG1〜LOG20はハコブくんHRIシリーズが中心。ハコブくん・HRI・Figma・Unityを本文に登場するなら積極的に入れる。たとえば「愛されるだけじゃない。『信頼』を生むロボットの表情デザイン」は「ハコブくんの表情デザイン。愛着だけでなく『信頼』を生むHRIデザインの実践」に変更する。

LOG20〜LOG80はUnity × ROS 2 × Docker × ハコブくんのデジタルツイン構築期。ハコブくん・Unity・ROS 2・Docker・NavMeshを本文に登場するなら入れる。

LOG80〜LOG128はmechArm 270の購入・実機展開期。mechArm 270・Unity・Python・ArticulationBody・PickAndPlaceなど、実装に直結する技術名を入れる。「データを取る日」は「mechArm 270のPickAndPlaceデータ収集を始めた日｜Unity × Python記録設計」に、「カップが、動いた。」は「Unityシミュレーションでコーヒーカップが初めて動いた｜mechArm 270 PickAndPlace検証」に変える。

考察記事（Deep Diveカテゴリ）は技術実装記事と異なり、特定のツールを使った作業ログではない。この場合は記事内で論及している企業名・研究名・製品名をタイトルに反映する。LOG143「Teslaのエンドツーエンド」、LOG126「GEN-0」、LOG118「RT-2・Figure・Google」のように、考察の対象が何かを明示する。

今の判断

考察記事のタイトルは「思考のまとめ」として書いてきたもので、流入を狙ったものではなかった。それはそれで正しかった。ただLOG126の結果を見ると、内容が同じでもタイトルの構造だけで届く人数が変わることがはっきりした。

変えたのは戦略ではなく習慣だ。

書き終わったあとに30秒、「この記事に登場する固有名詞はなんだっけ」と確認してタイトルに足す。内容は変えない。それだけでLOG126の偶然が再現可能になる。

サムネイルの統一も同じ考え方だ。記事の質は変えない。でも入口を整えておく。どれだけ良いものを書いても、外から見つけられなければ読まれない。LOG126が証明したのはそれだ。

今日の作業でもうひとつ気づいたことがある。改善案を出してから本文を照合する手順は、AIに任せきりにしてはいけないということだ。AIは「それらしい固有名詞」を補完しようとする。特に企業名・ツール名は、コンテキストから推測して存在しないものを入れてしまいやすい。一本ずつPDFで確認する手間は省けない。

サムネイルを並べたら、ようやくアーカイブページがアーカイブらしく見えてきた。タイトルも並べてみると、前半（LOG1〜20）はハコブくんで埋まり、後半（LOG80〜）はmechArm 270で埋まっている。プロジェクトの変遷がそのまま見える。これはこれで、記録の構造が出ていていい。

参照：タイトル改善一覧

変更不要（固有名詞あり）76記事

LOG5, LOG9, LOG16, LOG17, LOG18, LOG19, LOG20, LOG21, LOG23, LOG24, LOG25, LOG27, LOG28, LOG31, LOG32, LOG38, LOG39, LOG40, LOG41, LOG45, LOG46, LOG47, LOG48, LOG51, LOG54, LOG57, LOG58, LOG59, LOG60, LOG61, LOG62, LOG66, LOG68, LOG69, LOG70, LOG71, LOG72, LOG74, LOG75, LOG77, LOG78, LOG79, LOG81, LOG82, LOG83, LOG85, LOG86, LOG89, LOG90, LOG91, LOG92, LOG97, LOG104, LOG106, LOG109, LOG112, LOG113, LOG114, LOG116, LOG118, LOG125, LOG126, LOG128

🔴 最優先（検索価値がほぼゼロ）

🟠 優先度高

🟡 優先度中