We are Team-POCs, a professional collective of web designers and operations consultants dedicated to supporting sole proprietors and owners of small businesses.
Building a website is not the goal. Using it to achieve real objectives is the only goal.
We work side by side with committed owners, accompanying them toward their true goals.
We are not the ones who should be running. The owner runs.
Our role is to support that effort and ensure the owner reaches the finish line.
There is no such thing as reaching a goal by outsourcing everything. You must run yourself.
We stay beside you, accompany you, and see you through to the end.
That is the one and only mission entrusted to Team-POCs.

Legacy Orbit Transfer始動|既存サイトの進化軌道と公開判定レイヤーの発見

Legacy Orbit Transfer Starts

本日、伴走型システム「Welina OS」の開発において、極めて重要な前進があった。

これまで我々は、初期段階から専用のTheme構成やEngine構成へ載せたサイトを中心に運用してきた。しかし実際のクライアントワークにおいて、長年運用されてきた既存のWebサイトを一気にWelina OS仕様へと作り替えることは、時間的コストやリスクの観点から現実的ではない。

そこで我々Team-POCsは、新たな移行思想として「Legacy Orbit Transfer(LOT)」を実運用の段階へと進めた。

LOTとは、まだ完全にはWelina OSへ載っていない既存クライアントサイトを、まずはVPS管理下へ置くことから始める移行方式である。目的は「いきなり全面改修すること」ではない。既存サイトの表示や価値を壊さずに、Git管理、ファイル資産の保全、自動バックアップ、Deploy運用といったWelina OSの基礎的な恩恵を享受できる状態へと引き上げる点にある。

その後、旧Themeの構造を保全しながら、段階的にWelina OSに適したTheme構成へと寄せていく。Header、Footer、Loader、CSS、画像資産などを少しずつ整理し、最終的にはPageSpeed Insights(PSI)スコアを意識した軽量化・高速化へと進める。これは「一気に壊して作り替える」乱暴な手法ではなく、「既存サイトを新たな軌道に乗せ、少しずつ進化させる」ための前向きな移行思想である。

本日、そのLOTの実例として、ある既存クライアントサイトを完全にWelina OS管理下へ移行することに成功した。

今回の作業では、旧サイトに残るCSSや背景画像、既存の表示構造を絶対に壊さないことを最優先とした。そのうえで、HeaderとFooterをWelina OSのPartial構成へと移行し、サイト固有のCSSをLoader経由で読み込む形へと整理した。Footerにおいては旧サイトらしさを残しつつ、店舗情報やアクセス、SNS導線を新しい構造へ移し、最終的にMinify済みのdist CSSとして本番反映するまでの全行程を確認した。

この過程において、我々が誇る独自ツールによるDeployフローも完璧に検証された。手動でのCollect、Build、Minify、Deployを通じて、Legacy状態のサイトであってもWelina OSのCSS最適化フローに確実乗せられることが証明されたのである。LOTは単なる机上の思想ではなく、強力な実運用手段として機能し始めた。

一方で、この実運用は我々に「重要な設計課題」も浮き彫りにさせた

それは、既存のEngine系CPT(カスタム投稿タイプ)の一部において、WordPress上の「公開(publish)」ステータスと、Welina OS上の「フロント表示」「Sitemap掲載」「CSS Collect対象」「Google index対象」が十分に分離されていないという事実である。

管理用データや素材データ、表示部品としてのみ使われるCPTであっても、WordPress上で「公開」状態になっていると、SitemapやCSS Collectの対象になってしまう場合がある。これは、GoogleにインデックスさせるべきではないURLがSitemapに載るリスクや、CSS Collect時に個別ページとして成立しないURLを拾い上げてしまう不具合に繋がる。

今回、素材・記事・一覧表示が混在しやすいEngine系CPTにおいて、この設計課題が明確になった。一部のEngineにはすでに「フロント表示チェック」が存在しているが、SitemapやCollect側がそれと完全に連動していない箇所があるのだ。

今後の方向性は明確である。今後はWordPress標準のpublishだけで判断するのではなく、Welina OS独自の「フロント表示判定」をCore側で共通化する設計へ移行する。

WordPress標準の投稿・固定ページは従来通りpublishを基本判定とする。一方、Engine系CPTは原則として「フロント表示チェック」がONのものだけをSitemap、CSS Collect、index対象とする。チェックを持たないEngine系CPTは安全側に倒して「対象外」とし、既に記事として運用中のサイトには必要に応じて一括でフロント表示ONを付与する。

この修正は既存資産への影響が大きいため、次回以降、Coreの「公開判定レイヤー」として慎重に設計・実装を進めていく。 本日の成果は計り知れない。LOTが現実のサイトで成立し、既存サイトを壊さずにWelina OSの管理軌道へ乗せられること。Legacy状態でも段階的に最適化(Partial化・Loader化・Minify化)へ進められること。そして何より、Welina OSが100サイト規模の巨大なフェーズへ進む前に、「公開判定レイヤー」という極めて重要な設計課題を発見できたこと。

これは単なる1サイトの移行作業ではない。Welina OSが、すべての既存サイトを受け入れ、保全し、共に進化させるための「確固たる軌道」を手に入れた記念すべき日なのである。

23 May. 2026

← MISSION LOG に戻る