WPF を Visual Studio（.NET 8 以降）でビルドするたびに、obj\x64\Debug\net8.0-windows*やobj\x64\Release\net8.0-windows*配下に _wpftmp を含む名前の一時ファイルが多数残る――この現象は、いまの開発現場で非常に多く報告されています。例えばプロジェクト名が ABC であれば、次のような 5 種類のファイルが毎回（または高頻度で）現れ、積もり積もってディスク容量を消費していきます。
ABC_<ランダム8桁>_wpftmp.AssemblyInfo.vb
ABC_<ランダム8桁>_wpftmp.AssemblyInfoInputs.cache
ABC_<ランダム8桁>_wpftmp.assets.cache
ABC_<ランダム8桁>_wpftmp.GeneratedMSBuildEditorConfig.editorconfig
ABC_<ランダム8桁>_wpftmp.vbproj.BuildWithSkipAnalyzers
本記事では、これが正常動作である理由、ランダムなサフィックスが付く背景、そして現実的なクリーン運用のベストプラクティスを、WPF／MSBuild の視点から丁寧に解説します。最後に、安全に自動削除するスクリプト例や、CI・チーム開発での運用Tipsもまとめています。
結論（最初に押さえておくべきポイント）
- 正常動作です。これらは MSBuild／WPF ビルド（XAML マークアップコンパイル）およびデザイナーが生成する一時コンパイル成果物（キャッシュ）です。
- Visual Studio や MSBuild に自動削除の設定はありません。積極的に消したい場合は「クリーン」やスクリプト運用で対処します。
- ランダムなサフィックスは衝突回避と整合性のため。並列ビルドやデザイン時ビルドが同時進行しても安全に分離できるよう、セッション毎に一意の名前を採ります。
- 消しても問題ありません。ただし消せばキャッシュが失われるため、次回のみビルド時間がわずかに増えることがあります。
- 大量に残っても動作に支障はありません。最終成果物（
bin配下）には含まれませんが、容量は圧迫します。
現象の正体：WPF ビルドが作る「セッション分離された一時キャッシュ」
WPF のビルドは、C#／VB のコンパイルに加えて、XAML を中間コードへと変換するマークアップコンパイル（Markup Compile）や、BAML／リソースのアセンブリ組み込みといった追加の変換パイプラインを伴います。Visual Studio はさらに、デザイン時（Design-time）ビルドや増分（インクリメンタル）ビルドを駆動し、エディタ上の IntelliSense／デザイナーのための情報も生成します。
この過程で作られるのが、_wpftmp の名を冠した一時ファイル群です。基本的に obj 配下は「中間生成物とキャッシュの置き場」であり、次のビルドで再利用される前提のファイルと、そのセッションにだけ意味を持つ使い捨てのスクラッチファイルが混在します。残っていても害はないため、MSBuild は積極的には削除しません。
ファイルごとの役割（目安）
名称の意味から読み解ける、各ファイルのおおよその役割と扱いを以下に整理します。
| ファイル | 主な役割／中身の目安 | 再利用性 | 削除可否 |
|---|---|---|---|
..._wpftmp.AssemblyInfo.vb | 設計時ビルドや一時プロジェクトで使うアセンブリ属性情報の断片。VB の場合に現れやすい。 | セッション限定の場合が多い | 安全に削除可 |
..._wpftmp.AssemblyInfoInputs.cache | アセンブリ情報入力のハッシュ・タイムスタンプ等、インクリメンタル判断の材料。 | 再利用されることがある | 削除可（次回ビルドで再生成） |
..._wpftmp.assets.cache | リソース（画像、XAML、BAML 等）資産の依存関係やタイムスタンプのキャッシュ。 | 高 | 削除可（再生成） |
..._wpftmp.GeneratedMSBuildEditorConfig.editorconfig | ビルド時に MSBuild がエディタ／コンパイラへ伝える設定のスナップショット。 | セッションまたは構成依存 | 削除可 |
..._wpftmp.vbproj.BuildWithSkipAnalyzers | アナライザーを省略した設計時ビルドの最適化フラグ・マーカー。 | セッション限定 | 削除可 |
いずれも bin の最終成果物に取り込まれることはなく、削除は安全です。消せば必要に応じて自動で再生成されます。
なぜ毎回ランダムなサフィックス（<ランダム8桁>）を付けるのか
- 衝突回避：Visual Studio は「並列ビルド」「デザイン時ビルド」「複数構成（Debug/Release）」「複数ターゲット（例：
net8.0-windowsとnet8.0）」を同時に扱います。同名ファイルになり得る要素が多いため、セッション固有のランダム名で衝突を根本的に排除します。 - 整合性確保：キャッシュをハッシュキーのように扱う設計により、「誤った古いキャッシュを拾う」事故を避けます。セッションが変わればファイル名も変わるため、キャッシュの汚染や取り違えのリスクが下がります。
- 並列・短寿命最適化：プロセス間やビルドノード間でファイルを取り合わない構造は、高速化と安定化に寄与します。清掃は後段の「クリーン」に任せる——というのが MSBuild の基本思想です。
「古いファイルを再利用しないのか？」という疑問への答えは、「種類による」です。assets.cache のように再利用されるキャッシュもあれば、設計時のスクラッチとしてあえて使い捨てにしているものもあります。設計上のトレードオフとして、生成コスト < 衝突回避・安全性 と判断されている、と捉えてください。
これはバグや不具合ではないの？
原則として正常動作です。特に Visual Studio 2022 以降は、並列化・設計時支援の強化により、obj 内の一時ファイルが「増えがち」になりました。プロジェクト規模や XAML の数が多いほど、一時ファイルの生成頻度は高まります。
例外的に、ビルドが強制終了・クラッシュ・中断した場合などに、清掃フェーズが走らず余計に残骸が積み上がることがあります。しかし、次回ビルドで故障の原因になることは稀で、ほとんどは容量の問題にとどまります。
クリーン方法（手動・IDE・CLI）
| 方法 | 手順 | 効果／補足 |
|---|---|---|
| Visual Studio | [ビルド] → [クリーン ソリューション] | obj と bin を削除。ソリューション／プロジェクト単位で実行可能。 |
| CLI（.NET SDK） | dotnet clean（必要に応じて -c Release） | CI/CD 含む自動化に最適。マルチターゲットなら -f net8.0-windows も指定可。 |
| CLI（MSBuild） | msbuild /t:Clean | 古いソリューションや MSBuild 直叩き環境で有効。 |
| 手動削除 | エクスプローラや PowerShell で obj フォルダを削除 | 最も直感的。次回ビルドで必要なものは再生成される。 |
Rebuild（リビルド）は「クリーン＋ビルド」に近い動作ですが、obj の残骸清掃を完全に担保するものではありません。容量を取り戻したいときは明示的なクリーンを推奨します。
安全に自動削除する：PowerShell スクリプト例
ローカル環境での定期清掃には、更新から N 日以上経った _wpftmp 由来のファイルだけを狙い撃ちで削除するのが安心です。例えば以下は「7 日より古いもの」を消す例です。
# 例：開発用リポジトリのルート
$Root = "C:\Repos"
# 何日より古いファイルを削除するか
$Days = 7
$Threshold = (Get-Date).AddDays(-$Days)
$patterns = @(
"*_wpftmp.AssemblyInfo.vb",
"*_wpftmp.AssemblyInfoInputs.cache",
"*_wpftmp.assets.cache",
"*_wpftmp.GeneratedMSBuildEditorConfig.editorconfig",
"*_wpftmp.vbproj.BuildWithSkipAnalyzers"
)
Get-ChildItem -Path $Root -Recurse -File -Include $patterns |
Where-Object {
$*.FullName -match "\obj\" -and $*.LastWriteTime -lt $Threshold
} |
ForEach-Object {
try {
Remove-Item -LiteralPath $*.FullName -Force -ErrorAction Stop
Write-Host "Removed $($*.FullName)"
} catch {
Write-Warning "Failed to remove $($*.FullName): $($*.Exception.Message)"
}
} スケジューラ運用する場合は、タスク スケジューラで「PowerShell を1週間に1度」「ユーザーのログオン有無にかかわらず実行」などと設定しておくと、勝手に掃除が回ります。複数のリポジトリがある場合は $Root を配列にしてループするだけです。
チーム／CI 環境における運用のヒント
- ソース管理から除外：
objとbinは必ず.gitignore等で除外します（標準テンプレートにも含まれます）。 - エージェントは「使い捨て」に：CI ではビルドごとにクリーンなワークスペースを用意するのが王道です。残骸を持ち回さないため、ディスク肥大・キャッシュ汚染の双方を防げます。
- パイプラインの明示クリーン：各ジョブの最初か最後に
dotnet cleanやgit clean -xdfを入れると、余計な中間物を持ち越しません（ローカル開発ではgit clean -xdfは強力すぎるので要注意）。 - キャッシュ戦略は「依存パッケージだけ」：ビルド高速化でキャッシュするなら、
~/.nuget/packages等の復元キャッシュにとどめ、中間生成物（obj）は極力キャッシュしないのが安定です。
容量が厳しいときの現実解：置き場を変える／短寿命化する
大規模ソリューションやモノレポでは、obj の総計が数 GB に達することも珍しくありません。下記のような「置き場所・寿命管理」の工夫が効きます。
中間出力を別ドライブへ逃がす
SSD の空きが少ない場合、プロジェクトの .csproj／.vbproj で BaseIntermediateOutputPath を設定し、obj を大容量ドライブへ退避させます（プロジェクト名でディレクトリ分けして衝突を防ぐ）。
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net8.0-windows</TargetFramework>
<BaseIntermediateOutputPath>D:\VS-OBJ\$(MSBuildProjectName)\</BaseIntermediateOutputPath>
</PropertyGroup>
</Project>
この設定はチーム合意のもとで行いましょう。個人差がある場合は、Directory.Build.props で環境変数を参照し、各自のマシンで上書きできるようにしておくのがスマートです。
<h3>RAM ドライブで短寿命化（上級）</h3>
<p>小～中規模プロジェクトなら、<code>obj</code> を RAM ドライブに置くとビルドが軽快になります。電源断で消える＝<strong>自動的にクリーン</strong>になるため、ディスク肥大の心配も減ります（ただしメモリ消費と再起動時のフルビルドには注意）。</p>「なぜ Visual Studio は自動削除しないのか？」の背景
MSBuild の思想は「ビルドは純粋関数に近づけ、生成物のライフサイクルはツールが支配する」です。obj の一時ファイルは、その多くが「次のビルドで効くかもしれない」性質を持ちます。勝手に消すと、
- 並列ビルド・別プロセスがまだ参照中だった場合に危険
- 必要なタイミングで再生成コストが一度に跳ね上がる
といったデメリットが生じ得るため、自動削除は採用されていません。このため「積極的に消したいときはユーザーが明示的にクリーンする」という設計になっています。
開発体験を悪化させない「クリーン運用」の実践レシピ
- 日常：通常は放置で OK。容量が気になってきたら ソリューションを閉じる→
dotnet clean。 - 週次／隔週：上掲の PowerShell をスケジュール。「7～14 日以上の
_wpftmpだけ削除」で安定。 - 大掃除：四半期に 1 度、プロジェクト全体の
obj／binを削除。NuGet キャッシュの整理（必要なときだけ）も検討。 - CI：エージェントは極力使い捨て。どうしても固定なら、ジョブ冒頭で
dotnet cleanとストレージの上限監視を入れる。
このサイクルで運用すれば、「ビルドが極端に遅くなる」「キャッシュ破損で不安定」といった副作用を避けつつ、ディスク肥大を堅実に抑制できます。
よくある質問（FAQ）
Q. obj にあるこれらのファイルを削除すると、アプリの動作に影響しますか？ A. 影響しません。次回ビルドで必要なものは再生成されます。削除直後の最初のビルドは少し時間がかかることがあります。
<dt>Q. ランダムなファイル名を固定化して、再利用を促すことはできますか？</dt>
<dd>A. <strong>推奨されません。</strong>並列・設計時ビルドの衝突回避や整合性維持に反し、むしろ不安定化の原因になります。</dd>
<dt>Q. <code>_wpftmp</code> 以外にも大量のファイルが増えています。</dt>
<dd>A. <code>.g.cs</code>／<code>.g.vb</code>（XAML の生成コード）や各種 <code>.cache</code> など、WPF は中間生成物が多いプラットフォームです。<code>obj</code> と <code>bin</code> は<strong>バージョン管理から除外</strong>し、定期的なクリーン運用を。</dd>
<dt>Q. ディスク容量をできるだけ食わせたくありません。</dt>
<dd>A. <strong>置き場を別ドライブへ移す／RAM ドライブ活用／週次の自動清掃</strong>のいずれか（または組み合わせ）が効果的です。</dd>
<dt>Q. クリーン後にビルドが遅いです。</dt>
<dd>A. キャッシュが失われた直後は<strong>一度だけ</strong>重くなります。継続的に遅い場合は、ウイルス対策ソフトの除外設定（<code>obj</code> と <code>bin</code>）や、同時ビルド数の調整、ディスクの空き容量を確認してください。</dd>
</dl>運用チェックリスト（最終確認）
obj／binは Git から除外しているか。- 容量が逼迫したらまずは
dotnet clean。 - 定期掃除のスケジュールタスクを用意したか。
- 必要に応じて中間出力の置き場（
BaseIntermediateOutputPath）を見直したか。 - CI はクリーンなワークスペースで走っているか。
まとめ
WPF のビルドが obj 配下に残す _wpftmp ファイル群は、設計時／並列ビルドを成立させるための一時的な中間生成物であり、正常動作です。自動削除の設定はありませんが、クリーン操作やスクリプトで安全に片付けられます。ランダムなサフィックスは衝突回避と整合性のためで、再利用よりも安全性とビルドの安定性を優先した設計だと理解すると腹落ちします。
運用面では、ソース管理からの除外・定期清掃・置き場の工夫を押さえておけば、容量問題をスマートに解決できます。安心して開発に集中しましょう。
付録：関連コマンド早見表
| 目的 | コマンド | 補足 |
|---|---|---|
| ソリューションをクリーン | dotnet clean | -c Release や -f net8.0-windows を必要に応じて追加 |
| MSBuild でクリーン | msbuild /t:Clean | レガシー環境や細かな制御用 |
| クリーン＋ビルド（概念） | Rebuild | IDE から実行。容量回復は Clean の方が確実 |
| ローカルの徹底掃除（要注意） | git clean -xdf | CI では有効、ローカル常用は非推奨 |
付録：削除しても良いもの／残すべきもの
| 対象 | 削除可否 | 理由 |
|---|---|---|
obj フォルダ全体 | 削除可 | 中間生成物・キャッシュのみ。再生成される |
bin フォルダ全体 | 削除可 | 成果物だが、ビルドで再生成される |
packages（ローカル復元先） | 基本は削除しない | 復元に時間がかかるため。どうしても必要な時のみ |
.nuget キャッシュ | 状況に応じて | 破損疑い時や容量逼迫時のみ。通常は維持 |
この記事の要点（ショートメモ）
_wpftmpは 正常な一時ファイル。MSBuild／WPF デザイナー由来。- 自動削除の設定はないので、クリーン操作かスクリプトで運用。
- ランダム名は衝突回避と整合性のため。再利用より安全性優先。
- 容量対策は、定期清掃＋置き場移動＋CI のクリーン運用で解決。
以上を押さえておけば、obj の増殖に悩まされず、安定した WPF 開発環境を維持できます。
コメント