LASSIC Media らしくメディア
Squidの導入で押さえる5つのポイント｜社内の通信管理の基本
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- Squidは社内のPCのWebアクセスを1か所に集め、記録と制限をまとめて行えるオープンソースのプロキシです。
- 制限のルールは許可するものから書き、最後にすべてを拒否する形にすると、意図しない通信を通しにくくなります。
- 導入前に、ログの保存期間、利用者の見分け方、HTTPSの扱い、更新の担当を決めておくことが大切です。
※ 本記事は2026年10月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
社員がどのWebサイトを見ているのか、あとから調べようとしても記録が無い。業務に関係のないサイトや危ないサイトを止めたいが、PCごとに設定するのは手間がかかる——。社員のPCが直接インターネットにつながっている会社では、こうした困りごとが起こりがちです。Squid（スクイッド）は、社内のWebアクセスをいったん受け取ってから外へ取り次ぎ、その途中で記録と制限ができるオープンソースのプロキシソフトウェアです。
通信の出口を1か所にそろえられるので、記録と制限のルールをまとめて管理できます。ただし万能ではなく、テレワーク先のPCまで同じルールで管理したい場合は別の方法が合うこともあります。本記事では、社内の通信管理を任された情報システムの担当者に向けて、Squidでできること、UTMやクラウド型との違い、導入で押さえる5つのポイント、そして外部に頼むときに確認したい点を整理します。
目次
Squidとは
社内のPCがインターネットのWebサイトを見るとき、その通信を途中でいったん受け取り、代わりに相手のサーバーへ取り次ぐ仕組みをプロキシ（代理で通信を中継するサーバー）と呼びます。Squidは、このプロキシとして長く使われてきたオープンソースのソフトウェアです。公式サイトは、HTTP・HTTPS・FTPなどに対応したWeb向けのキャッシュ付きプロキシで、充実したアクセス制御を備えると説明しています。*2
- よく見られるページを手元に保存して再利用し、通信量を減らして表示を速くする（キャッシュ）
- アクセス制御・利用者の認証・ログの記録を組み合わせて使える
- ライセンスはGPLv2以降（ソースコードを公開する条件つきで自由に使えるライセンス）*8
- 多くのOSでパッケージとして配布されていて、Windowsでも動く*3
社内では、キャッシュよりも「社員のWebアクセスを1か所に通して、記録し、制限する」役割で使います。外部からの通信を受けてWebサーバーの手前に立つ使い方はリバースプロキシの役割で扱っています。
UTMやクラウド型との違い
社員のWebアクセスの制限は、Squidのように自社でサーバーを用意するやり方に限りません。IPA（情報処理推進機構）の中小企業向けガイドラインは、URLフィルタリングを「ウェブサイトへのアクセスや閲覧について、そのアドレスや内容が所定の条件に合致もしくは違反する場合に停止や警告などを行う技術」と説明し、この機能を含む機器としてUTM（統合脅威管理）も挙げています。*1
| 方法 | 置く場所 | 向いている場面 |
|---|---|---|
| Squid（自社で構築） | 自社のサーバーやクラウドの仮想マシン | 制限のルールやログの残し方を細かく自社で決めたいとき |
| UTMの機能 | 社内ネットワークの出入口に置く専用機器 | ファイアウォールなど複数の対策を1台にまとめたいとき |
| クラウド型のサービス | サービス事業者の設備 | 社外やテレワーク先のPCも同じルールで管理したいとき |
Squidはソフトウェアの利用料がかからない代わりに、サーバーの用意、ルールの設計、更新の作業を自社で受け持ちます。テレワーク先のPCまで含めて管理したい場合の考え方はSASE導入の進め方にまとめています。
Squidでできる3つのこと
社内でのSquidの役割は、通信の「経路」「記録」「制限」の3つに整理できます。社員のPCのWebアクセスをSquidに集め、記録と判定をしてからインターネットへ取り次ぎます。
- 経路：社内のPCのWebアクセスを1か所に集め、出口をそろえる
- 記録：リクエストごとに1行ずつアクセスログを残す。ファイルに書くほか、syslog（ログを集めて送る仕組み）などで別のサーバーへ送ることもできます*5
- 制限：接続元のIPアドレス、行き先のドメイン、曜日と時間帯、ログインした利用者の名前などを条件にして、許可と拒否を決める
ルールが1つも無ければ拒否するのが既定で、公式の設定例も、Squidを動かすサーバー自身（localhost）からの通信だけを許可し、最後の行ですべてを拒否する形です。*4 社内のどの範囲からの通信を許可するかは、導入する側が書き足します。
記録と制限を同じ場所で行うので、誰がいつどのサイトを見たかを1つのログで追えます。IPAのガイドラインも、不正なアクセスを検知・遮断するための監視の場所として、侵入検知システムやファイアウォールと並んでプロキシサーバーを挙げています。*1
導入で押さえる5つのポイント
Squidの導入では、ソフトを入れる作業より、何を記録して何を止めるかを決める作業に時間がかかります。次の5つを導入前に決めておきます。
- ポイント1：記録の目的と保存期間を決める。誰がいつログを見るのか、何か月残すのかを先に決めます
- ポイント2：制限は「許可するもの」から書き、最後にすべてを拒否する。公式の説明も、混乱を避けるために最後の行にすべての拒否を置くよう勧めています
- ポイント3：利用者を何で見分けるかを決める。IPアドレスで見分けるか、ユーザー名で認証するかです。PCの設定を変えずに通信を横取りする透過型の構成では、認証は使えません*6
- ポイント4：HTTPSの中身を見るかを決める。Squidは既定では暗号化された通信を復号せず、そのまま中継します*7
- ポイント5：更新の担当を決める。開発者がサポートするのは最新の安定版だけです*3
つまずきやすいのはポイント4です。HTTPSの中身まで検査するには、SquidがWebサイトの証明書をまねた証明書を使い、社員のPCとの間の通信をいったん復号する設定が要ります。中身まで見るサイトと見ないサイトを分け、範囲を決めてから検討すると進めやすくなります。ポイント5については、執筆時点の最新の安定版は2026年8月24日公開のv7.7です。*3
外部に頼むときに確認しておきたい点
Squidは社員全員のWebアクセスが通る場所になるため、止まると業務全体に響きます。構築や運用を外部に頼むときは、次の点を見積もりの前に確かめておきます。
- どこまで頼むか：サーバーの用意、ルールの設計、PC側の設定の配布、操作の説明のうち、どれを任せるか
- 止まったときの備え：Squidのサーバーを2台にするか。止まったときにWebアクセスをどう扱うか
- ルールの見直し：止めるサイトの追加や例外の申請を、誰が受け付けてどう反映するか
- ログの保管：ログをどのサーバーへ送り、何か月残し、誰が見られるようにするか
- 更新：新しい版や脆弱性の情報を誰が確かめ、いつ更新するか
公式サイトのサポートのページは、有償でサポートを提供する事業者がいることを案内しています。*2 自社にSquidを扱える人がいない場合は、構築だけでなく、ルールの見直しと更新まで含めて頼めるかを確かめておきます。
まとめ：Squidで確かめておきたい3つの点
Squidで社内のWebアクセスを管理するうえで、確かめておきたい点は3つに整理できます。第一に、ログを何のために残し、誰がどのくらいの期間見られるようにするかを決めること。第二に、制限のルールは許可するものから書き、最後にすべてを拒否する形にすること。第三に、HTTPSの中身を見るかどうかと、更新の担当を導入の前に決めることです。この3点を踏まえておけば、「入れてはみたが、ログを誰も見ず、ルールも古いまま」という事態を避けやすくなります。構築や運用の進め方に迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
Squidは無料で使えますか
ソフトウェアそのものはGPLv2以降のライセンスで公開されていて、利用料はかかりません。*8 ただし、動かすサーバーの費用や、ルールの設計・更新の手間は自社で持つことになります。
Squidを入れると通信は遅くなりますか
社員の通信がすべてSquidを通るため、サーバーの大きさは社員の人数と通信量に合わせて決めておきます。Squidには、よく見られるページを手元に保存して再利用し、表示を速くするキャッシュの機能もあります。導入後しばらくは混み具合を確かめ、必要ならサーバーを増強します。
テレワーク中の社員のPCも管理できますか
社外のPCの通信をSquidに通すには、VPN（社外から社内のネットワークにつなぐ仕組み）などで社内を経由させる構成が必要になります。社外のPCが多い場合は、クラウド型のサービスと比べて、通信の経路と費用の両面から選ぶとよいでしょう。
社内の通信管理の仕組みづくりのご相談
Squidによるプロキシの構築から、アクセス制限のルール設計、ログの保管と更新の運用まで、元請（プライムベンダー）としてご提案します。
2006年の創業以来、一次請けのシステムインテグレーターとして、企業のシステム開発と保守・運用を受託してきました。
出典
- *1 参考：独立行政法人情報処理推進機構（IPA）「中小企業の情報セキュリティ対策ガイドライン 第4.0版」（https://www.ipa.go.jp/security/guide/sme/about.html）。出典：本編の「攻撃等の検知」（プロキシサーバー等での監視）と用語集の「URLフィルタリング」「UTM」の記述を参照（2026年10月確認）
- *2 参考：Squid公式サイト「Squid: Optimising Web Delivery」「Why Squid?」「Squid support」（https://www.squid-cache.org/）。出典：対応する通信（HTTP・HTTPS・FTP）、キャッシュ、アクセス制御・認証・ログの機能、有償サポートの案内を参照（2026年10月確認）
- *3 参考：Squid公式サイト「Getting Squid」（https://www.squid-cache.org/Versions/）。出典：最新の安定版（v7.7・2026年8月24日公開）、開発者は最新の安定版のみをサポートすること、各OSのパッケージとWindowsでの利用を参照（2026年10月確認）
- *4 参考：Squid configuration directive「acl」「http_access」（https://www.squid-cache.org/Doc/config/http_access/）。出典：接続元IP・行き先ドメイン・曜日と時間帯・利用者名による条件、既定で拒否すること、最後にすべてを拒否する行を置く推奨を参照（2026年10月確認）
- *5 参考：Squid configuration directive「access_log」（https://www.squid-cache.org/Doc/config/access_log/）。出典：リクエストごとに1行記録すること、ファイル・syslog・UDP・TCPへの出力を参照（2026年10月確認）
- *6 参考：Squid configuration directive「auth_param」（https://www.squid-cache.org/Doc/config/auth_param/）。出典：認証方式と、透過型（intercept）の構成では認証が使えないことの記述を参照（2026年10月確認）
- *7 参考：Squid configuration directive「ssl_bump」（https://www.squid-cache.org/Doc/config/ssl_bump/）。出典：既定では復号せずに中継すること、サーバー証明書をまねた証明書で復号する動作を参照（2026年10月確認）
- *8 参考：squid-cache/squid（GitHub）（https://github.com/squid-cache/squid）。出典：README と COPYING（GPLv2以降のライセンス）を参照（2026年10月確認）
