「ユーザがサーバ上の指定フォルダに画像を配置し、
業務データと紐づけて Web 画面で表示する」
――この構成は、社内システムや BtoB 向け Web アプリでは非常によく見られます。
一方で、実装段階になると次のような疑問に必ず直面します。
- 画像は どこに配置すべきか
- DB には 何を持たせるべきか
<img>で直接参照してよいのか- Controller 経由にすべきか
本記事では ASP.NET MVC 5 を前提に、
サーバ内に存在する画像ファイルを、安全かつ運用しやすく表示するための設計パターンを、
実務目線で体系的に整理します。
サーバ内画像表示の全体像を整理する
まずは、画像表示をどのような責務分担で実現するのか、
全体構造を把握するところから始めます。
想定する運用フロー
- ユーザが サーバ上の指定ディレクトリ に画像を配置
- 管理画面や C/S アプリで 業務データと画像を DB で紐づけ
- MVC アプリでは DB 情報をもとに画像を表示
ここで重要なのは、次の考え方です。
Web 画面は「画像の実体」を直接知らない
Web 側が扱うのは「画像 ID」や「画像レコード ID」のみであり、
画像の実体は Controller を通じて安全に取得します。
役割分担の整理（設計の軸）
| 役割 | 責務 |
|---|---|
| DB | 業務データと画像の関係を管理 |
| ファイルシステム | 画像の実体（バイナリ）を管理 |
| MVC | 取得ルール・認可・表示制御 |
👉 この 責務分離 を守ることが、
セキュリティ・拡張性・長期運用の安定性に直結します。
想定プロジェクト構成（ディレクトリツリー）
設計を議論する前に、「どこに何があるのか」を明確にします。
MyMvcApp
├─ Controllers
│ └─ ImageController.cs ← 画像返却用 Controller
├─ Models
│ └─ ImageFile.cs ← 画像情報モデル
├─ Views
│ └─ Sample
│ └─Index.cshtml ← 画像表示View
├─ App_Data
│ └─ Images ← ★ Webルート外の画像保存先
│ ├─2026
│ │ └─01
│ │ └─8f3a9c2d-xxxx.jpg
├─ Content
│ └─ site.css
├─ Web.config
App_Data 配下は Web から直接アクセスできない
これが 業務画像を扱う際の基本構成 です。
画像の配置場所設計が最重要ポイント
画像をどこに置くかは、
セキュリティ・運用・将来の保守性を左右する最重要判断です。
配置場所と用途の対応表
| 配置場所 | 例 | 用途 | 直接URL |
|---|---|---|---|
| Webルート配下 | /Content/images/logo.png |
ロゴ・装飾 | 可能 |
| Webルート外 | App_Data/Images |
業務画像 | 不可 |
| 共有 / NAS | C:\\BusinessData\\Images |
既存資産 | 不可 |
Webルート配下に置く場合（公開画像）
<imgsrc="/Content/images/logo.png"alt="ロゴ">
📌 メリット
- 実装が非常に簡単
- IIS による静的配信で高速
⚠ 注意点
- URL を知っていれば誰でも閲覧可能
- 業務画像・個人情報には不向き
Webルート外に置く場合（業務システム向け）
- IIS から直接アクセス不可
- Controller 経由でのみ返却
- 認可・存在チェックが可能
👉 業務システムではこちらが基本設計です。
DB と画像ファイルの紐づけ方（3パターン）
DB に何を持たせるかで、
設計の自由度・安全性・移行コストが大きく変わります。
🔹 パターンA：画像IDのみ保持【推奨・新規設計】
CREATE TABLE ImageFiles (
ImageId UNIQUEIDENTIFIERPRIMARY KEY,
BusinessIdINT,
Extension NVARCHAR(10)
);
App_Data/Images/
└─ 8f3a9c2d-xxxx.jpg
📝 特徴
- パス変更に強い
- セキュリティが高い
- 新規開発に最適
👉 新規設計で自由に決められるなら最優先です。
🔹 パターンB：相対パス保持【限定用途】
ImagePath='/Content/images/sample.jpg'
⚠ 注意点
- Web 公開画像専用
- 業務用途では非推奨
🔹 パターンC：フルパス保持【既存業務で非常に多い】
📂 ディレクトリ例
C:\\BusinessData\\Images
├─ Customer
│ └─ 2026
│ └─ 00012345.jpg
🗄 DB 定義例
CREATE TABLE ImageFiles (
ImageIdINTIDENTITYPRIMARY KEY,
BusinessIdINT,
FileFullPath NVARCHAR(500),
ContentType NVARCHAR(50)
);
📝 特徴
- 既存資産を活かせる
- NAS・共有フォルダと相性が良い
- 移行案件で現実的
👉 「今すぐ作り替えられない」現場の現実解です。
MVCで画像を返す基本パターン（業務向け）
ここからは、実装の基本形を確認します。
Controller 経由で画像を返す
publicclassImageController: Controller {
public ActionResultShow(int imageId) {
if(!User.Identity.IsAuthenticated) {
returnnew HttpUnauthorizedResult();
}
var image = _db.ImageFiles.FirstOrDefault(x => x.ImageId == imageId);
if(image == null) {
return HttpNotFound();
}
if(!System.IO.File.Exists(image.FileFullPath)) {
return HttpNotFound();
}
return File(image.FileFullPath, image.ContentType);
}
}
View 側（表示）
< imgsrc = "@Url.Action( "
Show ", "
Image ", new {imageId =Model.ImageId } )"
class = "img-thumbnail"
alt = "業務画像" / >
👉 MVC設計上の重要ポイント
- View は 画像の場所を一切知らない
- 取得ルールは Controller に集約する
URLの流れを図で理解する
URL と実体の関係を整理しておくと、
設計意図がブレなくなります。
🔁 処理の流れ（文章で整理）
<img src="/Image/Show?imageId=123">- MVC ルーティングで
ImageController.Show - 認証・認可チェック
- DB から画像情報取得
- ファイル存在チェック
File()でレスポンス返却
👉 URL は入口、実体は Controller の中です。
既存フルパス案件の「移行時の地雷」
フルパス設計は、移行時に事故が起きやすいポイントでもあります。
❌ よくある事故ポイント
- DB に
C:\\...がベタ書き - 本番 / 検証 / 開発でドライブ構成が違う
- UNC パスの環境依存
- 全角・文字コード混在
✅ 現実的な対策
① ルートパスを設定化する
<appSettings>
<addkey="ImageRootPath"value="C:\\BusinessData\\Images" />
</appSettings>
DB には 相対パスのみ を保持します。
② 段階的移行を許容する
- 既存：フルパス
- 新規：ID 管理
👉 一気に直そうとしない
③ パス検証を必ず挟む
- ルート配下チェック
- 拡張子制限
- Content-Type 固定
セキュリティで必ず避けるべきNG例
var path = Request["path"];
return File(path,"image/jpeg");
🚫 なぜ危険なのか
- パストラバーサル攻撃
- 任意ファイル読み取りのリスク
👉 ユーザ入力をパスに使わないのが鉄則です。
設計選択の最終まとめ
公開画像のみ
→ Webルート配下（静的）
業務画像（新規設計）
→ Webルート外＋画像ID管理
既存業務資産・NAS前提
→ フルパス保持＋Controller配信
まとめ
C# MVC でサーバ内画像を表示する設計では、
最初に次の 2 点を決めることが重要です。
- 画像をどこに置くか
- DB に何を持たせるか
業務システムでは、
- Web ルート外に画像を配置
- DB で論理的に紐づけ
- Controller を通じて制御
この構成を採ることで、
安全性・拡張性・運用性の高い画像管理が実現できます。
コメント