taupe WebとAIと暮らし

Projects / 実践記録

公式サイトを「歩いてめぐる世界」に作り直した。ishikawa.co全面リニューアルの記録

公式サイトを「歩いてめぐる世界」に作り直した。ishikawa.co全面リニューアルの記録

本ページはアフィリエイトプログラムを利用しています

ishikawa.coは、僕が運営する6つのメディアや、制作・開発の活動をまとめた公式サイトです。
2026年7月20日、そのishikawa.coを全面リニューアルしました。

右へ歩くと、僕が運営している6つのメディアが、それぞれ違う場所として現れます。
森では雨が降り、湖の先で記事を釣る。
暗い回路では信号が走り、旅の街では記憶が点になって残る。
6つの世界を通り抜けると、画面が崩れ、キャラクターと粒子が落下し、読むための「Living Atlas」へ組み替わります。

完成した画面だけを見ると、最初からこの形を目指していたように見えるかもしれません。

実際には、その前に3Dの電脳街をかなり作り込み、丸ごと撤回しています。
白い線画の世界も作り、動画も入れ、歩いた軌跡や再訪者の演出も試しました。
動いたのに捨てたものが、いくつもあります。

この記事では、2018年から続くishikawa.coの変化と、今回の制作で何を作り、どこで違和感を止め、なぜやり直したのかを記録します。
完成報告というより、失敗と判断を含めた制作日誌です。

ishikawa.coは、何度も主役を変えてきた

2026年6月版ishikawa.coのダーク背景とオーロラ色の画面

最初のishikawa.coは、2018年に作ったWordPressのプロフィール兼サービスサイトでした。

Webサイト制作、ブログ、プロフィール、問い合わせ。
個人で仕事をするために必要な入口を、素直に並べたサイトです。
当時の主役は、制作者としての僕と依頼窓口でした。

2021年には独自PHP構成へ移り、旅と食を記録するisLog、釣りや田舎暮らしのフィールドノートを残すmoss、WebやAIの制作記録を扱うtaupeなどの最新記事をAjaxで取得するようになりました。
自分を説明するだけではなく、運営しているブログが今も動いていることを見せる。
現在の公式ハブへつながる発想は、この頃から少しずつ現れています。

2025年8月には、Canvasのscene、warpナビ、ターミナル風表示、Sound切り替えを持つ実験的な構成へ変更しました。
普通のページを並べるだけでなく、画面そのものを体験にしたいという方向が、ここで明確になります。

2026年4月版では、PHPのサーバーサイドレンダリングを土台に、メディア、制作・開発、AI Music、個人開発サービスを普通に読めるHTMLとして整理しました。
RSS取得、JSONキャッシュ、下層ページ、構造化データもこの時期に整えています。

6月には、ダーク背景、オーロラ色、パララックス、カーソル軌跡、足跡パーティクルを使うUIへ刷新しました。
見た目は華やかになりましたが、まだ「格好いい事業サイト」の範囲にいる。
6つのメディアが同じカードの中に並び、それぞれの違いが薄く見える状態でした。

ishikawa.coの主役は、制作実績のカードだけではありません。
釣り、WebとAI、旅と食、Minecraft、贈り物、商品選び。
現在も更新している6つのメディアと、それらを運営する活動全体です。

同じデザインのカードを6枚並べるだけでは、その違いが消えてしまう。
それぞれを「場所」にして、移動そのものを紹介にできないか。
今回のリニューアルは、そこから始まりました。

歩ける3D電脳街を作り、構想ごと捨てた

撤回前のISHIKAWA.WORLDに作り込んだ3D電脳街

2026年7月初め、最初に作ったのはThree.jsによる3D世界でした。
建物、看板、Bloom、霧、反射、当たり判定、巨大な映像スクリーン。
香港の路地を思わせる電脳横丁を作り、操作キャラクターをサイバー猫にした時期もあります。

3Dのサイトとして見れば、試したかった要素はかなり入っていました。
歩ける。
光る。
音が鳴る。
建物の間を抜けられる。

しかし、作り込むほど、モデル、ライティング、カメラ、質感、当たり判定の調整が制作の中心になっていきました。
僕が運営しているメディアより、3D空間そのものが主役になっていたのです。

さらに、世界をひとつのサイバー都市へ統一すると、6つのメディアの違いも消えていきます。
mossの森も、isLogの旅も、贈り物を紹介するモノオモイも、同じネオン街の看板に見えてしまう。

そこで、3Dを改善し続けるのをやめました。
実装を軽くするための調整ではなく、構想そのものを撤回しました。
ただし、全部が無駄だったわけではありません。

公式サイトを「歩く」という操作には残す価値がある。
そして、6つのメディアをひとつの質感へ押し込むべきではない。
この2点は、3D版を作ったからこそ見えた判断でした。

残したのは「歩く」だけです。

白い線画から、歩くことで生まれる点描へ

3D版の後に作り直した初期の白い点描世界
ロゴの粒子が一粒へ集まり点描世界の起点になる起動演出

3D版の後、画面は一気に白くなりました。
真っ白な世界にキャラクターが立ち、歩くと足元から線が伸び、メディアが場所として現れる。
最初はSVGの線画、一筆書き、2.5Dの奥行きを中心に考えていました。

いきなり6世界を作らず、まずmossの森、雨、湖、桟橋、釣りに範囲を絞りました。
ひとつの世界で「歩くと何が起きるか」を固めないまま数を増やすと、6種類の未完成ができるだけだからです。

制作を続ける中で、環境表現の主役は線から点へ変わりました。
キャラクターは線画SVGのまま残し、森、水、回路、宇宙、贈り物、商品棚をCanvas上のドットと粒子で描く構成です。
点は、世界ごとに方言のように変奏できます。

森では葉や雨になる。
湖では波紋と飛沫になる。
taupeでは回路を走る信号になり、おじクラではキューブや花火になる。
モノオモイでは包み紙に、モノえらび編集部では比較する棚や選択の印になる。

これは3D版を単純に軽量化したものではありません。
表現の主語を「作り込まれた空間」から「歩くことで生まれる点」へ変えたのです。

初期の白い画面には別の問題もありました。
余白として見せたいのに、長い白画面はロード停止に見えます。

そこで、ロゴが粒子で組み上がり、一粒へ集まり、その一粒が落下して地面の波紋になる起動演出を作りました。
ロゴと世界を別々に見せず、最初の点がそのまま旅の起点になります。

見栄えが整った後にも、最初の表示と再描画でロゴの縦位置がずれる不具合が残りました。
大きな演出を作っていても、1px単位のずれで「作り物」が見える。
こうした違和感も、公開前に止めた箇所です。

6つのメディアを、6つの場所と動詞にする

雨と森と湖、桟橋で記事を釣る第一幕のmoss世界
暗い回路を信号が流れる第一幕のtaupe世界
棚と比較と選択を点描で表したモノえらび編集部の世界

第一幕の共通操作は単純です。

歩く。
景色が反応する。
世界の入口を読む。
Spaceで記事を発見し、Enterで記事やメディアへ進む。

ただし、発見の仕方は同じにしませんでした。
mossでは雨が森の途中から増え、湖としてたまり、桟橋の先で記事を釣り上げます。
湖の点密度が足りず水に見えなかったり、桟橋より手前から水が始まったり、釣り糸が桟橋を貫通する位置でも釣れたりして、何度も作り直しました。

taupeは暗い回路と信号。
isLogは旅、街、港、記憶。
Minecraftのプレイ記録を残すおじクラは、ジ・エンドを連想する虚空、キューブ、浮遊建築、クリーパーの花火。
モノオモイは贈り物。
家電や日用品を型番・仕様から比べるモノえらび編集部は、棚、比較、選択です。

それぞれの世界には動詞も置きました。

mossはwalk / ripple / fish / live。
taupeはconnect。
isLogはcapture。
おじクラはbuild。
モノオモイはunwrap。
モノえらび編集部はchoose。

違いを色だけで表すのではなく、看板の紋章が組み上がる動き、粒子の形、記事と出会う行為まで変えています。

途中では、mossの画面へ動画素材を入れたこともあります。
しかし、点描世界より映像が主役になり、世界の文法が崩れたため外しました。
素材があるから使うのではなく、その世界のルールに合うかで判断する必要がありました。

キャラクターの後ろへ残る線や波状パーティクルも削除しています。
画面を散らかし、性能にも寄与しませんでした。
前回の星座や前回の旅人を残す再訪演出も、初見では意味が伝わらず「?」になるため見直しました。

足すことより、動いているものを外す判断のほうが難しかったです。

記事発見、星座、音を旅の記憶にする

mossの湖で最新記事を釣り上げて発見した場面
6世界の発見順から生成された旅の星座

世界へ着くだけでは、メディアを紹介したことになりません。
そこで、6メディアの最新記事をPHPがRSSから取得し、世界の中で発見できるようにしました。
mossでは記事を釣り上げるように、媒体の行為と記事発見を一致させています。

発見した順番は、旅の星座になります。
同じ6世界を通っても、順番が違えば形が変わる。
最後には旅のしおり画像として持ち帰れます。

音もBGMループではなく、発見、落下、上昇といった出来事ごとに一音を鳴らすWebAudioの「音の点描」にしました。
音源ファイルを再生し続けるのではなく、画面上の点と同じように、操作の瞬間だけ音が置かれます。

一周目と二周目、逆再生、覚醒演出、訪れた世界の色が残る道も加わりました。
一方で、再訪演出は説明なしでは伝わりにくいものも多く、残すものと外すものを何度も選び直しています。

完成しかけた頃、演出の瞬間だけ本当に重くなった

性能改善後の歩行画面とframeやheapを表示するデバッグHUD

宝や第一幕から第二幕への遷移が遅く見える時期がありました。
演出としてゆっくりしていたのではありません。
実際に処理が重くなっていました。

単一フレームで大量の粒子を生成し、配列の先頭をまとめて削除し、オブジェクトを作り直していたことが原因です。
ヒープは15MBから31MBへ鋸歯状に増え、ガベージコレクションが体感できる引っかかりになっていました。
対策は、粒子を単純に減らすことではありませんでした。

バーストを複数フレームへ分散し、配列先頭の削除をswap-popへ変更。
420スロットの粒子プールを先に確保して再利用し、粒子上限1400は増やさない。
改善後はヒープが約16MBでほぼ平坦になり、再計測では6ms以上のdropスパイクが0件になりました。

歩行中の微妙なカタつきには、別の原因がありました。

Canvasは30fpsで再描画し、その間をCSS transformで補間していました。
しかし補間値は近景にしか合っておらず、遠景が再描画のたびに約5px戻っていたのです。
地面は滑らかなのに、奥の森だけが毎秒30回揺れる構造でした。

dot canvasをfar / nearの2帯へ分け、各帯のparallax値で補間するように変更しました。
さらに、frame、JavaScript、Canvasのp95、heap、再確保、band値を実機で見られる性能HUDを先に作りました。

感覚だけで「重い」と言い続けるのではなく、どこが止まっているかを画面上で測れるようにしてから直す。
これは今回の制作で大きかった工程です。

JavaScriptの計測が速くても、全画面にmultiply、screen、soft-lightを6層重ねていた時期はGPU側の負荷が残りました。
通常の明世界はblend 0層、暗世界だけscreen 2層へ削減。
結果としてtaupeの色はむしろ鮮明になりました。

「最後がつまらない」で、第一幕の先を作り直した

第一幕の世界が崩れキャラクターと6色の粒子が落下する遷移
人物、メディア、OSS、相談領域を縦に読むLiving Atlas

6世界を通った後の終点は、当初、メニューや普通の下層ページへのリンクでした。
しかし、ここまで歩いた後に、最後だけ普通のWebサイトへ戻るのはつまらない。
実画面を見て、そこで止めました。

書斎、扉、同行キャラクターなど、いくつかの案を検討しました。
最終的に選んだのは、SEO fallbackとして用意していたサーバーHTMLそのものを、第二幕の「Living Atlas」へ昇格させる方法です。
第一幕は横に歩いて、6つのメディアを発見する。

第二幕は縦にスクロールして、人物、メディア、公開OSS、相談領域を読む。
スクロール中は左のレールをキャラクターが歩き、止まると座ります。
「読むこと」を、第二幕の歩行にしました。

第一幕の右端まで歩くと、世界が崩れ、6色の粒子とキャラクターが落下します。
崩れた粒子は第二幕の縦軸へ再構成されます。
歩く世界から読む地図へ、同じ点が役割を変える遷移です。

入口も一度作り直しました。
最初はSpaceで第二幕へ進む設計でしたが、右へ歩き続ける第一幕の文法と合いません。
右へ進み切る操作へ変更しました。

第二幕へ入った後も、縦スクロールへ変わったことが伝わらず、左右キーを押し続ける問題がありました。
W / Sと上下キー、停止時の案内、タッチ画面の「スワイプ」を追加しています。

一度到達したブラウザには旅のしおりを出し、次回は第二幕へ短縮できます。
ただし、第一幕へ戻った後に再入場できない不具合や、遷移途中で「世界へ戻る」を押すと入力ロックが残る不具合もありました。

遷移中は両方の幕を一時的に操作不能にし、完了、中断、Escape時の解除処理を一元化しました。
遷移58%の瞬間にクリックとSpaceを入れる回帰テストまで作っています。

見えない状態管理の1行が、最深部の体験全体を止めることがあります。
取り逃した発見を後から集めてもポータルが開かない不具合も、完了状態を最終地点でしか判定していなかったことが原因でした。
発見のたびに再評価する純関数へ切り出し、テストを追加しました。

モバイルは、PC版を縮めるだけでは成立しなかった

390pxのスマートフォンで表示した公開版の第一幕

390pxの画面でdocument幅が1080pxになる。
看板がキャラクターへ重なる。
スクロール案内が見出しを隠す。
再訪時だけ旅のしおりと音ボタンが重なる。
PC用のキーボード案内がタッチ画面にも出る。

モバイル版では、こうした別条件の問題が続きました。
Living Atlasを1列へ組み替え、看板を画面内へ補正し、タッチ用左右ボタンと文言を追加しました。
初回表示だけでなく、一周後の再訪状態も別シナリオとしてQAしています。

キャラクターも背景以上に優先して直しました。
上昇前のしゃがみが小さすぎる。
着地後に一瞬だけ大きな姿が出る。
記事発見後や放置後に歩くと縦に細かく震える。
落下のはずが浮上に見える。

キャラクターは体験全体の基準尺です。
fall、brace、launch、land、sitなど専用姿勢を増やし、状態遷移とサイズを回帰テストへ入れました。

下層ページでは、H1の「プロジェクト」が語中で分断したり、終章の「す。
」だけが次行へ落ちたりしました。
大きな演出が完成していても、公開前にはこうした組版の違和感を優先度の高い問題として修正しています。

ゲームのように見えても、意味のあるHTMLを土台にする

ishikawa.coはPHP 8.4のサーバーサイドレンダリングとVanilla JavaScriptで動いています。
UIフレームワークや本番用ビルド工程は使っていません。

Canvas 2Dは点群、水、雨、飛沫、回路、宇宙を描きます。
キャラクター、リンク、記事、操作、アクセシビリティに必要なUIはDOMとSVGです。
PHPは6メディアのRSS取得、JSONキャッシュ、本文、構造化データを担当します。

重要なのは、検索やAIのために別の隠し本文を持っていないことです。
2026年4月版で作った意味のあるサーバーHTMLを残し、その同じDOMがJavaScript有効時にはLiving Atlasとして見えます。
JavaScriptが失敗しても、人物、メディア、公開OSS、Servicesの見出しとリンクは普通に読めます。

titleとdescriptionには、6メディア、公開OSS、Webサイト・システム開発、SEO / LLMO、AI活用、記事制作を整理しました。
Person、WebSite、Media、SoftwareSourceCode、Serviceの構造化データを接続し、projects、sitemap、robots、llms.txtも用意しています。

reduced motionでは大型演出を止めても、情報や操作を失わない構成にしました。
RSSはPHP側で取得してキャッシュし、閲覧中に6サイトへ大量アクセスしません。
SEO / LLMO対応をゲームの後ろへ付け足したのではなく、普通に読める意味構造の上へ第一幕と第二幕を載せています。

AIと作ったが、違和感を止める判断は自分で行った

今回の制作では、僕が体験の目的、世界の方向、違和感、優先順位、公開判断を決めました。
実際のChromeで歩き、「重い」「浮いて見える」「最後がつまらない」「それは早合点している」と具体的に止めています。

Codexは、既存コードと仕様を読み、実装、回帰テスト、性能計測、公開前QA、デプロイ手順を進めました。
Claudeは独立レビュー、表現の方向整理、性能原因の仮説分解、第二幕案、公開前QAを担当。
プロデューサー役は、公式ハブとしての事業整合、SEO / LLMO、外部視点の問題、公開可否を整理しました。

複数のAIが勝手にサイトを作ったわけではありません。
この役割分担の背景は、以前まとめたひとり事業のAIチーム運用にもつながっています。
長期の制作タスクを後継へ渡す際には、Codexの長期タスクを安全に移行した記録で整理した引き継ぎ方法も使いました。

AIによって大量の試行は可能になりました。
しかし、3D電脳街、動画、強すぎる粒子、普通のメニューを採用しないと決めたのは、実画面で違和感を見つけ、言葉にして止めた後です。

途中では、画面全体に出た斜めの白い帯を、木の粒子だけの問題だと局所化しかけたこともありました。
見えている症状を狭く解釈すると、AIとの制作でも誤診します。
「木だけの話ではない」と現象全体へ戻し、描画を調べ直しました。

実装する役と、画面を見て方向を止める役。
さらに、作った本人とは別にレビューする役。
その分離がなければ、動くものを作ることと、公開してよいものを作ることが混ざっていたと思います。

AIとの制作体制をもう少し基礎から確認したい場合は、書籍「60分でわかる! AIエージェント 超入門」も、役割分担や自律的な処理の入口を整理する補助資料になります。
この記事で扱ったishikawa.coの制作は本の手順を再現したものではありませんが、AIエージェントという言葉の前提を確認したいときの次の一冊です。

76の回帰テストと公開作業までを制作に含める

公開前には、Nodeの回帰テスト76件、PHPテスト6ファイルを再確認しました。
主要QAではconsole error 0、横overflow 0、PCと390pxを確認し、独立QAで公開を止める問題が0件になったことを確認しています。
GitHub ActionsではPHP検証、Nodeテスト、公開用artifact生成、FTPS dry-run、本番同期、release marker照合、HTTPスモークを順に実行します。

公開対象から、不要になった制作素材、sample、movie、legacyも整理しました。
作ったものをサーバーへ全部置くのではなく、現行体験に必要なものだけを公開します。
2026年7月20日17時46分、現行版を本番へデプロイしました。

公開で終わりではありません。
6つのメディアが更新されれば、世界で発見する記事も変わります。
ブラウザ、端末、再訪状態によって、まだ見えていない違和感が出る可能性もあります。

だから、今回作ったのは完成品というより、観測しながら直していける公式サイトです。

まとめ。歩ける世界の裏側には、捨てた画面が残っている

今回のishikawa.coは、3D電脳街を作り込んだ後に撤回し、白い線画を点描へ変え、6つのメディアを6つの場所にしました。
記事を発見し、星座を作り、音を一粒ずつ置く。
最後が普通のメニューではつまらないと止め、第一幕の世界を崩して、第二幕のLiving Atlasへつなぎました。

その途中には、性能劣化、状態管理、入力競合、モバイルの横overflow、キャラクターの揺れ、文章の1文字落ちまで、大小のやり直しがあります。
AIは、その試行回数を増やし、実装と検証を進めてくれました。
一方で、実画面の違和感を止め、何を主役にするかを決める仕事は残りました。

歩けること自体が目的ではありません。
僕が運営している6つのメディアと、その間を行き来しながら続けている活動を、ひとつの公式サイトとしてどう見せるか。
その問いへの、2026年7月時点の答えがこの世界です。

実際の第一幕とLiving Atlasは、ishikawa.coで確認できます。

続けて読む

次に読むなら、これ。

同じテーマの実践記録や、taupeの読み方へ進めます。

同じテーマAI活用近い実践記録をカテゴリから続けて読めます。サイトの読み方FAQ運用方針や、よくある質問を確認できます。taupeについてこのサイトについてどんな視点で作り、使い、運用しているかをまとめています。

Category

Author / Official hub

イシカワヒデカズの実践記録

Web制作、開発、AI活用、メディア運営の相談先は公式サイトにまとめています。