古いファイルにコンポーネントがあっても、元のサイトにその機能があったとは限りません

古いサイトをリファクタリングするとき、ファイルの一覧を機能の一覧と取り違えがちです。SideFunctionBar.vue というファイルが実際に存在し、その中に React、Vue、Vanilla JS のフィルターボタンが書かれていたとしても、それで分かるのは、そのコードがプロジェクトに追加されたことだけです。元のサイトの利用者がその UI を見たり、操作したりした証拠にはなりません。

機能として確認するには、少なくとも公開された入口から実際のマウント先までたどり、さらに利用者の操作と目に見える結果まで確認する必要があります。ファイルの存在は証拠を集める出発点であって、機能が存在したという結論ではありません。

以下で「現在」の実装として説明する内容は、2026年10月2日付の原稿に記録された時点の状態を指します。

「存在する」を証拠の種類に分けます

証拠	確認できること	まだ確認できないこと
ファイルが存在する	プロジェクトにそのコードが保存されていたこと	ページが読み込んだり表示したりしていたこと
コンポーネント内に一通りのロジックがある	作者が想定される動作経路を書いていたこと	その経路が入口につながっていること
store、データ、スタイルがある	状態や表示の準備があった可能性	利用者がその動作を起こせること
ルートや親コンポーネントが import している	実行時にそのコンポーネントへ到達する経路があること	すべての操作と状態変化が実際に機能すること
HTML やブラウザーで結果が見える	確認した環境では機能が出力または実行されたこと	過去のすべてのバージョンやデプロイ環境でも同じだったこと

これらの証拠は互いの代わりにはなりません。コンポーネントのファイルを見つけた段階では、「調査が必要な実装候補」として扱うのが限界です。元のサイトの機能と記述するには、入口と動作の証拠をさらに探す必要があります。

作品フィルターのコンポーネントを実際にたどります

今回の古い Vue プロジェクトには、SideFunctionBar.vue がありました。React、Vue、Vanilla JS を切り替える3つのボタンがあり、filterKeywords を通じて作品の絞り込み条件を変更していました。ファイルの内容だけを読むと、「元のサイトには技術別のフィルターバーがあった」と受け取りやすい構成です。

ところが、アプリケーションの入口からたどると、次の関係が見つかりました。

App.vue → AppShell.vue → router-view → WorkViews.vue

AppShell.vue は共通の外枠とルートの内容を担当していましたが、外枠に SideFunctionBar.vue を組み込んでいませんでした。WorkViews.vue も、このコンポーネントを import していません。作品ページ自体は filterKeywords を読み取り、作品の tag を照合する関数も持っていました。ただし、テンプレートに実際に表示されていたのは「サイト／システム」と「コンテンツ／ビジュアル」の2種類の作品カテゴリを切り替える操作であり、3つの技術別ボタンではありませんでした。

ここでは、次の2点を分ける必要があります。

• 絞り込みの状態と照合ロジックが存在することから、プロジェクトにその設計方針の痕跡が残っていたと分かります。
• SideFunctionBar.vue はアプリケーションのマウント経路につながっていませんでした。そのため、追跡できたこの入口からは、利用者が操作できたという証拠は見つかりませんでした。

より正確には、調査対象の入口では利用を確認できなかった残存実装であり、元のサイトが提供していた公開機能とは扱えません。

リファクタリングでは実在した動作を残します

そこで、リファクタリングで残したのは、明確な入口があった作品カテゴリの切り替えです。技術別フィルターは、もっともらしく見えるという理由だけでは移植しませんでした。

原稿に記録された Astro の作品ページでは、#development と #design を指す2つのネイティブリンクを引き続き出力していました。ブラウザーのスクリプトが [data-work-type] を読み取り、hash に応じて該当する領域を表示し、aria-current も同期します。作品データの技術 tags はカードに表示できますが、これは作品の情報であり、利用を確認できていない別の絞り込み操作ではありません。

小さな違いですが、リファクタリングの結果は変わります。古いファイルだけを見ていれば、新しいページに技術別ボタンを追加してしまうかもしれません。入口と実際のテンプレートを照合すると、復元する必要があったのは作品カテゴリの切り替えであり、マウントされていないサイドバー機能の拡張ではないと分かります。正式な出力の検査でも、生成された HTML に未使用のサイドバーの data-filter コントロールが戻っていないことを個別に確認しました。

古いコンポーネントをどう判断するか

ファイル名から結論を推測するのではなく、次の順序で確認します。

1. まず公開された入口を探します。 ルート、ページの入口、アプリケーションの外枠から始め、読者がその機能のあるページへどう到達するかを確認します。
2. import とテンプレートへのマウントをたどります。 調査対象の入口や親コンポーネントがそのファイルを参照しているか確認します。フォルダー内の別のファイルが参照しているだけでは、正式なページに表示されているとは限りません。
3. イベントと状態の書き込み箇所をたどります。 コンポーネントに click、store、絞り込み関数があっても、それを起動できる操作が実際にあるとは限りません。目に見える操作から状態変化までの経路全体を探します。
4. ソースコードだけでなく、出力を見ます。 初期 HTML、ビルド成果物、実際のブラウザー画面を確認し、その操作が表示され、結果も本当に変わるかを確かめます。
5. 結論を状態ごとに分けます。 「マウント済みで操作できる」「マウント済みだが動作が不完全」「ロジックだけが残っている」「現時点では証拠不足」と分類できます。これら4つをすべて「既存機能」と記述してはいけません。

この順序は、アニメーションのコンポーネント、旧版のナビゲーション、一見完成しているフォーム、データ項目だけが残った機能にも使えます。コンポーネント名がどれほど説得力を持っていても、入口とのつながりを示す証拠の代わりにはなりません。

この調査でどこまで証明できるか

repository で確認できるのは、保存されたコード、追跡できる import 関係、そして確認した環境が生成した出力です。過去のすべてのデプロイが同じコードを使っていたことを自動的に証明するものではなく、repository にコミットされなかった実験版の存在も否定できません。

そのため、この記事の判断は、追跡できたアプリケーションの入口と出力に限ります。その範囲では、SideFunctionBar.vue が元のサイトで操作可能な公開機能だったとは確認できませんでした。過去のすべてのバージョンについて断定するものではなく、マウントされていないコンポーネントを、新しいサイトで復元すべき要件として扱うものでもありません。

リファクタリングは、古いファイルをすべて新しいフレームワークへ移す作業ではありません。どの内容と動作に証拠があるかを、改めて確認する作業です。まず入口と目に見える結果を調べ、そのうえで残す価値のあるコードを選びます。ファイル名だけで、コードが機能になるわけではありません。