「せっかく3日かけて実装した画像アップロード機能を、私は自らの手で1行残らず全削除した」
令和に自作した2ちゃんねる風掲示板「つゔぁいちゃんねる（2ch.biz）」開発秘話の第18弾。今回は、エンジニアが最も陥りがちな「多機能化の罠」と、個人開発者がWebサービスを健全に生き残らせるために下した「画像保持の完全撤廃とURL展開への大転換」の意思決定プロセスを公開します。
💡 はじめに：「画像も直接アップロードできた方が便利じゃん」という誘惑
Webアプリの開発に少し慣れてくると、誰もがこう思います。
「令和の掲示板なんだから、テキストだけじゃなくてスマホで撮った写真をその場でアップロードできた方が便利に決まっている」
実際、私は開発初期の段階で、誇らしげに「画像アップロード機能」を組み込みました。
- 投稿フォームに「📷 画像を添付」ボタンを設置
- クライアント側でのドラッグ＆ドロップと即時サムネイルプレビュー
- サーバー側でのファイル形式バリデーション（MIMEチェック）
-
uploads/ディレクトリへのWebP自動リサイズ保存
テスト環境でスマホからラーメンの写真をアップロードし、スレッドに綺麗なサムネイルが表示された時、「最高にモダンな掲示板ができた！」と自画自賛していました。
……しかし、そのわずか数日後、私はこの機能を丸ごとゴミ箱に捨てることになります。
😱 個人開発者を破滅させる「画像保持」の3大現実
本番運用を見据えてリスクシミュレーションを行った瞬間、背筋が凍りつくような現実が次々と浮き彫りになったのです。
1. ディスク容量とネットワーク転送量（帯域費用）の爆発
最近のスマートフォンで撮影した写真は、1枚で5MB〜10MBを超えることも珍しくありません。
もし1日に100枚の写真が投稿されたら、それだけで月間数十ギガバイトのストレージが消費されます。格安VPSのSSD容量（数十GB〜100GB）など、数ヶ月でパンクします。
さらに恐ろしいのが 「画像の配信転送量」 です。
人気スレッドに貼られた写真が1万回閲覧されたら、それだけで数十ギガバイトの転送量が発生し、クラウド破産（数万円〜数十万円の請求）を引き起こします。
2. 児童ポルノ・著作権侵害・違法画像の「保持リスク」
これが最大の決定打でした。
匿名掲示板である以上、悪意あるユーザーが違法な画像や他人のプライベート写真をアップロードしてくる可能性を100%防ぐことは不可能です。
もし自分のサーバーのディスク（uploads/）にそれらの違法画像が保存されていた場合、 サーバー管理者自身が「違法コンテンツの保管者」として家宅捜索やサーバー押収、刑事責任を問われるリスク を直接背負うことになります。個人開発者が背負うにはあまりにも重すぎる十字架でした。
3. 画像ファイル偽装スクリプト（Web Shell）の脅威
画像に見せかけてPHPコードを仕込んだポリグロットファイル（Polyglot）がアップロードされ、サーバー上で実行されてしまえば、サーバー全体が乗っ取られてボットネットの踏み台にされます。
🗑️ サンクコストを捨てろ！「機能全廃」という勇気
エンジニアにとって、自分が苦労して書いた数千行のコードを捨てるのは身を切られるような苦痛です。「せっかく作ったんだから、なんとか制限を厳しくして残せないか…」と誰もが葛藤します。
しかし、個人開発において最も大切なのは 「守りきれないリスクは最初から持たないこと（引き算の美学）」 です。
開発初期（2026年8月18日夜）、私は決断を下し、画像アップロード機能に関わるすべての資産を完全消去しました。
2ch_biz/
├── [DELETED] uploads/ ← サーバー上の画像保存ディレクトリを完全消去
├── [CLEANED] api.php ← upload_image APIおよび画像処理コードを全削除
├── [CLEANED] server.js ← Node.js側のマルチパートアップロード処理を全削除
├── [CLEANED] admin.html / js ← 管理コンソールの画像設定タブを完全撤去
└── [CLEANED] index.html / app.js ← 投稿フォームのカメラボタンとプレビューDOMを全削除
すべてのコードを消し去った瞬間、サーバーのディスク使用量は劇的に軽くなり、セキュリティ監視の精神的プレッシャーから完全に解放されました。
💡 本家2ちゃんねるが「画像アップロード」を持たなかった真の理由
この機能を捨てた時、私は20年以上前にひろゆき氏が設計した本家2ちゃんねるのアーキテクチャの凄絶さに、改めて畏敬の念を抱きました。
2ちゃんねるは、全盛期で何百万人ものユーザーを抱えながら、 掲示板本体には一切の画像アップロード機能を持たせませんでした 。
画像を共有したいユーザーは、imgurやlivedoorなどの「外部画像ローダー」に自分でアップロードし、その 「URLだけを本文に貼る」 という文化が徹底されていたのです。
【伝統的な2chのスタイル】
今夜の晩飯できたぞー
https://i.imgur.com/example.jpg
この設計思想により：
- 2chのサーバーにはテキスト（数キロバイト）しか流れないため、超軽量・爆速レスポンスを維持できる
- 画像のストレージ費用と配信転送量は、外部画像ホスティング会社が肩代わりしてくれる
- 違法画像の保管責任は画像ホスティング側にあり、2ch側は「URLテキストの削除」だけで済む
これは単なる手抜きではなく、 Webサービスが長期間生き残るための究極の知恵（アーキテクチャ） だったのです。
🚀 次なる進化：テキスト掲示板のまま「画像を見せる」逆転の発想
画像アップロードを全廃したからといって、画像の共有を諦めたわけではありません。
「画像ファイルを自前で持たず、ユーザーが本文に貼った外部URLを、安全にインライン展開してサムネイル表示すればいい」
自前ホスティングを捨てたことで、逆に「モダンな画像プレビュー体験」をノーリスクで実現する新しい道が開けました。
🎯 まとめと次回予告
第18回となる今回は、エンジニアとして最も苦しく、かつ最も価値のあった決断 「画像アップロード機能の完全撤廃」 について解説しました。
今回の学び・ポイント
- 「作れる」と「運用できる」は全く別 ：ストレージ費用と法的リスクを個人のキャパシティと天秤にかける勇気。
- サンクコストを恐れずに捨てる ：危険な機能は、どれだけ時間をかけて作ったものであっても早期に切り捨てるのがプロの判断。
- 本家2chの偉大な引き算 ：テキストに特化し、重たいメディアは外部URLに任せる設計思想の強靭さ。
そして、画像アップロードを捨てた翌日、私は掲示板に新たな魔法をかけました。
「本文に貼られた画像のURLを検知し、安全にサムネイルを展開するクライアントパーサー」 です。
次回、 【第19回】本文内の画像URLを自動サムネイル展開！安全なプロキシ経由とモーダルプレビュー へと続きます！
🔗 関連リンク
- 本番サービス : https://2ch.biz/