ASP.NET Web FormsでWinFormsのTagプロパティを再現する方法｜ViewStateとdata属性で移植を成功させる

WinForms の TextBox.Tag にメタ情報を詰めて処理していたアプリを ASP.NET Web Forms に移植すると、同じ発想がそのまま通らず悩みがちです。本記事では Tag 相当の実装方法と、検索・条件分岐ロジックの移植手順を具体例つきで解説します。

WinForms の Tag が便利だった理由

Windows デスクトップアプリ（WinForms）では、各コントロールが常にメモリ上に存在し、イベント駆動で状態を持ち続けます。そのため Control.Tag に「その入力欄の役割」を表すメタ情報を入れておくと、実装が一気に楽になります。

• 入力チェックの種類（必須・数値・日付など）
• 表示や桁数、フォーマット（右寄せ、固定小数点など）
• DB の列名・テーブル名、検索条件、集計対象
• 似た TextBox をまとめて処理するためのグルーピング

例として、次のような “セミコロン区切りのキー=値” 形式を Tag に入れて、処理側で Split して分岐するのはよくあるパターンです。

TF=3;VF=3;TPCrg=5;TPExp=5;TPPay=4;PPmntNm=[prid];PPmntTbl=IncomeT;PCrgNm=[prid];PCrgTbl=IncomeT

結論：ASP.NET Web Forms の asp:TextBox には Tag プロパティがない

ここが移植で最初に詰まりやすいポイントです。WinForms の Control.Tag は Windows フォーム用のプロパティで、ASP.NET Web Forms の TextBox（System.Web.UI.WebControls.TextBox） には同名のプロパティが存在しません。

そのため、コードビハインドで次のように書くとコンパイルエラーになります。

' NG（Web Forms の TextBox には Tag がない）
Me.Txt1_0.Tag = "TF=3;VF=3;..."

一方で、.aspx 側に Tag="..." のような「未知の属性」を書くこと自体は、Web Forms のコントロールでは “追加属性（パススルー属性）” として扱われるケースがあります。ただしそれは “Tag プロパティ” が生えるわけではなく、Attributes コレクションに入って HTML へ出力される、という別物です。

移植の前に整理：そのメタ情報はどこで使う？

WinForms の Tag は万能に見えますが、Web では「その情報をどこで使うか」で最適解が変わります。まずは用途を分類すると、設計がぶれにくくなります。

用途	おすすめの置き場	HTMLに出る？	主なメリット	注意点
サーバー側だけで参照	ViewState / Session / サーバー側辞書	出ない（選び方による）	改ざんの影響を受けにくい	状態管理の設計が必要
サーバー・JavaScript 両方で参照	data-属性 / HiddenField	出る	フロント側でも同じ情報が使える	ユーザーが改ざん可能（信頼しない）
“グループ”としてまとめて検索	data-属性 / CssClass / 命名規約	出る（方法による）	一括処理が簡単、保守しやすい	運用ルール（命名/キー）を決める

サーバー側だけで追加データを持たせる：ViewState の正しい使い方

「ViewState is not a string」というエラーは、ViewState を “1 つの文字列変数” のように使おうとして起きるのが典型です。Web Forms の ViewState は StateBag（キーと値のコレクション） であり、次のようにキーを指定して保存・取得します。

' 文字列を保存（キーを決める）
ViewState("Txt1_0_Tag") = "TF=3;VF=3;TPCrg=5;TPExp=5;..."

' 文字列として取り出す（Nothing 対策をするのが安全）
Dim tag As String = Convert.ToString(ViewState("Txt1_0_Tag"))

コントロールごとにキーを作る場合は、ID を使うと衝突しにくくなります。

Dim key As String = Me.Txt1_0.ID & "_Tag"
ViewState(key) = "TF=3;VF=3;..."

Dim tag As String = Convert.ToString(ViewState(key))

ViewState を使うメリットは、ページ内の状態をポストバック間で保持できることです。逆にデメリットは、値が増えるほど ページサイズ（送受信量）が増える ことです。Tag 文字列が大きい、対象コントロールが多い場合は、次の工夫が効きます。

• Tag 文字列を短くする（キー名の統一、冗長な情報を削る）
• 必要なページだけ EnableViewState を使う（不要なら切る）
• 「毎回同じ定義」は ViewState ではなくサーバー側の定義表（Dictionary）へ寄せる

「Tag プロパティの書き味」を残したい：カスタムサーバーコントロールで独自プロパティを作る

WinForms と似た書き方（MyTextBox.Tag = "..."）をどうしても残したい場合は、TextBox を継承して独自プロパティを生やすのが王道です。値は ViewState に格納すれば、ポストバックでも復元されます。

Imports System
Imports System.Web.UI.WebControls

Public Class MyTextBox
    Inherits TextBox

    Public Property Tag As String
        Get
            Return Convert.ToString(ViewState("Tag"))
        End Get
        Set(value As String)
            ViewState("Tag") = value
        End Set
    End Property
End Class

.aspx で使う場合は、プロジェクト構成により Register が必要になります。

<%@ Register TagPrefix="local" Namespace="YourNamespace" Assembly="YourAssembly" %>

この方法の利点は、コードビハインドで .Tag と書けることです。さらに「HTML に属性として出したくない」場合も、実装次第で避けられます（ただし ViewState を有効にしている場合、値は ViewState に含まれ得ます）。

WinForms の Tag に最も近い実装：Attributes（カスタム属性）に保持する

WinForms の Tag に近い感覚で “各 TextBox が持つメタ情報” を扱うなら、Attributes コレクションを使うのが実用的です。これはサーバーコントロールが出力する HTML 属性を追加・参照できる仕組みで、未知の属性でも保持できます。

aspx マークアップで data-属性として持たせる（おすすめ）

HTML5 的に独自データを持たせる場合は data-xxxx 形式が推奨です。例えば data-tag に Tag 文字列を入れておくと、サーバー側でも JavaScript 側でも同じ情報を使えます。

<asp:TextBox
    ID="Txt1_0"
    runat="server"
    data-tag="TF=3;VF=3;TPCrg=5;TPExp=5;TPPay=4;PPmntNm=[prid];PPmntTbl=IncomeT" />

コードビハインド（VB.NET）からの取得は次の通りです。

Dim tag As String = Me.Txt1_0.Attributes("data-tag")
tag = If(tag, String.Empty)

この方式のポイントは、.aspx で管理しやすく、またブラウザ側で要素を見たときにも “何の入力欄か” が追跡しやすいことです。移植期は特にデバッグ効率が上がります。

Tag=”…” のように書いた場合はどうなる？

Tag="..." と書いた場合、環境や設定によっては、そのまま HTML に tag="..." として出力され、サーバー側からも Attributes("tag") で読めます。ですが、HTML として意味のある属性ではないため、将来の保守性やチーム開発を考えると data-tag のほうが無難です。

コードビハインドから Attributes を追加する

移植段階で “まず動かす” ために、Tag 情報をコード側で生成して付与することもあります。例えば次のように追加できます。

Me.Txt1_13.Attributes("data-tag") =
    "TFdd=3;PF=3;TPrp=RnTxt;PrpNm=UnitRent.[Note];BlncNm=IncomeT.[Note];"

注意点として、ポストバックや動的生成の都合で属性が消えたように見える場合があります。安全策としては、

• 動的に作るコントロールは Page_Init（または OnInit） で再生成する
• 属性付与は 毎回行う（または ViewState を前提にする）
• データバインド系（Repeater / GridView 等）は ItemDataBound など適切なイベントで付与する

という “Web Forms の流儀” を押さえておくと安定します。

重要：data-属性は改ざんされる前提で扱う

data-属性（または tag 属性）は HTML に出るため、ブラウザの開発者ツールで簡単に書き換えられます。つまり、data-tag を元に「金額計算の根拠」や「権限の分岐」などをしてはいけません。安全な設計としては、

• data-tag は UI のふるまい（表示・入力補助・軽い条件分岐） のみに使う
• 重要な判定は サーバー側の定義（DB/設定ファイル/Dictionary） を正にする
• 送信された値は必ずサーバーで再検証する

を徹底すると、移植後にセキュリティ事故を起こしにくくなります。

Tag 文字列を “使える形” にする：キー=値を辞書化する

WinForms の頃と同じように Split(";"c) しても動きますが、移植後に仕様追加が続くと “文字列操作だらけ” になって読みづらくなります。実務では、最初にパースして Dictionary(Of String, String) にしてしまうと、後工程がかなり楽です。

Private Function ParseMeta(meta As String) As Dictionary(Of String, String)
    Dim dict As New Dictionary(Of String, String)(StringComparer.OrdinalIgnoreCase)

    If String.IsNullOrWhiteSpace(meta) Then
        Return dict
    End If

    Dim parts = meta.Split(";"c)
    For Each part In parts
        Dim p = part.Trim()
        If p.Length = 0 Then Continue For

        Dim idx = p.IndexOf("="c)
        If idx <= 0 Then Continue For

        Dim key = p.Substring(0, idx).Trim()
        Dim value = p.Substring(idx + 1).Trim()

        If key.Length = 0 Then Continue For
        dict(key) = value
    Next

    Return dict
End Function

使う側は次のように書けます。

Dim metaRaw As String = If(Txt1_0.Attributes("data-tag"), String.Empty)
Dim meta = ParseMeta(metaRaw)

Dim tf As String = Nothing
If meta.TryGetValue("TF", tf) AndAlso tf = "3" Then
' 例：入力チェックの種類を TF=3 として扱う
End If

この形にしておくと、後から TF や VF の意味が増えても条件式が読みやすくなり、また Null（Nothing）対策も一箇所に集約できます。

「Tagで多数のコントロールを探す」を Web Forms で再現する

WinForms ではフォーム直下の Controls を回せばすぐに探せましたが、Web Forms はコントロールツリーが入れ子になりやすく、Repeater や MasterPage など “NamingContainer” も絡みます。基本は、

• 対象の TextBox を Panel など 1 つの親コンテナにまとめる
• 親から 再帰的に子孫コントロールをたどる
• data-tag（または ViewState / 独自プロパティ）で絞り込む

の流れで移植します。

親コンテナ配下の TextBox をまとめて処理する例

Private Iterator Function Descendants(root As Control) As IEnumerable(Of Control)
    For Each c As Control In root.Controls
        Yield c
        If c.HasControls() Then
            For Each cc In Descendants(c)
                Yield cc
            Next
        End If
    Next
End Function

Private Sub ApplyRules(container As Control)
For Each c As Control In Descendants(container)
Dim tb = TryCast(c, TextBox)
If tb Is Nothing Then Continue For


    Dim metaRaw = If(tb.Attributes("data-tag"), String.Empty)
    If metaRaw.Length = 0 Then Continue For

    Dim meta = ParseMeta(metaRaw)

    ' 例：TF=3 の TextBox だけ右寄せにする
    Dim tf As String = Nothing
    If meta.TryGetValue("TF", tf) AndAlso tf = "3" Then
        tb.Style("text-align") = "right"
    End If

    ' 例：VF=3 の TextBox だけ必須扱いにする（見た目のマーキング例）
    Dim vf As String = Nothing
    If meta.TryGetValue("VF", vf) AndAlso vf = "3" Then
        tb.CssClass = (tb.CssClass & " required").Trim()
    End If
Next


End Sub

ポイントは、Web Forms では “画面に見えているもの” だけではなく、サーバー側のコントロールツリーを正しく走査することです。対象を Panel で囲っておけば探索範囲を限定でき、ページ全体をなめるより高速で安全です。

入れ子が深い画面で FindControl が効かないとき

FindControl は “直下の子コントロール” を見つけるのが基本で、深い階層を一発で探してくれません。Tag 相当で一括処理をしたい場合は、上のような再帰探索が最も堅実です。

Repeater / GridView などデータバインド系の注意

Repeater や GridView の中に TextBox がある場合、コントロールは “行ごと（Item/Row ごと）” に生成されます。Tag 相当の値を入れるなら、

• テンプレート内に data-tag="..." を書く
• または ItemDataBound / RowDataBound で Attributes を付与する

という流れになります。行単位で異なる Tag を持たせる必要があるなら、後者（バインド時に付与）が向いています。

手段別のメリット・デメリット比較

「WinForms の Tag を Web Forms に移植する」と言っても、実装の選択肢はいくつかあります。用途に応じて使い分けられるよう、代表的な方法を整理しておきます。

方法	格納場所	HTMLに出る？	向いているケース	避けたいケース
ViewState(“Key”)	ページの ViewState	原則出ない（ただし ViewState 自体は送受信される）	ポストバックで状態を保持しつつ、画面上の属性は汚したくない	大量のメタ情報でページが重くなる
カスタム TextBox の Tag プロパティ	ViewState（または内部フィールド）	出ない（実装次第）	WinForms の書き味を残したい、共通部品化したい	短期移植で工数が限られる（導入コストがある）
Attributes(“data-tag”)	HTML 属性	出る	サーバー/JavaScript 両方で使う、デバッグしやすくしたい	機密情報、権限など改ざんに弱い用途
HiddenField	HTML input hidden	出る	大きめのデータをクライアントと共有したい（JSON 等）	“見えないから安全” と誤解して使う
Session	サーバー側セッション	出ない	ユーザーごとに確実に保持したい、改ざんを避けたい	セッション肥大化、Web ファーム構成での管理

実務でおすすめの移植手順

移植を短期間で成功させたい場合は、最初から完璧を狙うより “段階的に改善できる形” を選ぶのが現実的です。おすすめは次の順番です。

• まずは data-tag を採用し、WinForms の Tag 文字列をそのまま移植する
• 処理側は ParseMeta で辞書化し、条件分岐を読みやすくする
• Tag が増え続けて辛くなったら、キーを整理し、必要なら TagInfo クラス など型で表現する
• 「HTMLに出したくない」「改ざんが怖い」領域は、サーバー側定義（Dictionary/DB）へ寄せる

たとえば “メタ定義はサーバー側に集約し、画面側は ID だけ持つ” という設計も可能です。data-tag には識別子だけを入れて、実データはサーバー側で引く形にすると、改ざん耐性も上がります。

' 画面側には data-meta-id だけ
Dim metaId As String = If(tb.Attributes("data-meta-id"), "")

' サーバー側の定義表から取得（例：Dictionary や設定ファイル、DB）
Dim meta As TagInfo = TagRepository.Get(metaId)

このやり方は、将来的に MVC や別 UI へ移行するときも “メタ定義の資産” が残りやすい、という副次効果があります。

移植時に一緒に見直したいポイント

質問文にある position:absolute; top:...; left:... のようなピクセル固定レイアウトは、Web ではフォントや表示倍率、ブラウザ差で崩れやすいのが難点です。移植直後は仕方ないとしても、運用フェーズでは次の観点で少しずつ改善すると、保守コストが下がります。

• 入力欄をテーブルレイアウトや CSS Grid/Flex に寄せて、相対配置にする
• 必須やエラー表示は CSS クラス（例：required / invalid）で統一する
• クライアント側の補助は JavaScript（または jQuery）で data-属性を参照して共通化する
• JavaScript で要素を探す場合は、必要に応じて ClientIDMode="Static" を検討する

また、ASP.NET Web Forms 自体は新規開発の主流ではないため、大規模改修のタイミングが来たら Razor Pages / Blazor など別方式も検討余地があります。ただし移植の目的が “現行資産の延命” なら、まずは Web Forms 内で保守性を高めるのが最短です。

まとめ：Web Forms で Tag 相当を実現する現実的な選択肢

• Web Forms の TextBox には WinForms のような Tag プロパティは存在しないため、同じ書き方はできない
• サーバー側だけで保持したいなら、ViewState(“キー”) に格納して Convert.ToString で取り出す
• WinForms の Tag に近い運用をしたいなら、Attributes(“data-tag”) で保持し、必要に応じて辞書化して扱う
• Tag の “書き味” を残したい場合は、TextBox を継承して 独自 Tag プロパティ を作ると移植がスムーズ
• data-属性は改ざん前提。重要な判定はサーバー側の定義を正にし、入力値は必ず再検証する