LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

FreshRSSとは？セルフホスト型RSSアグリゲーターの概要

FreshRSSとは、複数のウェブサイト・ブログ・ポッドキャストが配信するRSS/Atomフィードを自社サーバーへ集約し、閲覧・整理できる無料のセルフホスト型ニュースアグリゲーターです。公式サイトは「A free, self-hosted RSS and Atom feed aggregator」と説明しており^*1、軽量で拡張性が高く、カスタマイズしやすいソフトウェアと紹介されています^*1。GitHub公式リポジトリはAGPL-3.0ライセンスで公開されており、2026年7月時点で15,000件を超えるスターを獲得しています^*2。

競合企業のプレスリリース、技術ブログ、業界ニュースといった情報源は数が増えるほど確認の手間も膨らみます。個別にサイトを巡回する運用では、担当者が変わった際に確認先が引き継がれない、更新の見落としが生じるといった課題も起きやすいでしょう。FreshRSSは、こうした複数の情報源をひとつの画面へ集約し、社内の情シス・マーケティング・企画部門で共有するための基盤として使えます。データが外部のクラウドサービスへ送信されない自社サーバー完結の設計であるため^*1、外部フィードサービスの仕様変更やサービス終了に運用が左右されにくい点も特徴です。

タグ・保存検索で複数フィードを一元管理する仕組み

OPMLインポートと保存検索で情報を整理する

FreshRSSは、既存のRSSリーダーからフィード一覧をOPML形式でインポート・エクスポートできます^*1。乗り換え時に登録済みフィードを一から登録し直す必要がないため、既にRSSリーダーを使っている部署でも移行の負担を抑えやすいでしょう。また、検索条件を保存できる機能も備えており^*1、「特定企業名を含む記事」「特定カテゴリーの新着」といった条件を毎回入力し直さずに呼び出せます。

公式サイトは、100万件以上の記事と5万件以上のフィードを扱える性能を持つと説明しています^*1。競合・技術・業界動向という複数分野の情報源を同時に登録しても、記事数の増加によって動作が破綻しにくい設計と言えるでしょう。

複数ユーザー対応と匿名読み取りモードで部署共有もしやすい

GitHub公式リポジトリは、マルチユーザー対応と匿名読み取りモードをサポートすると明記しています^*2。部署ごとにアカウントを分けて権限を管理しつつ、社内向けには匿名でも一覧を閲覧できるモードを組み合わせられる設計です。ログイン方式もWebフォーム・HTTP認証・OpenID Connectの複数から選べるため^*2、既存の社内認証基盤と連携させる余地もあります。

テーマや拡張機能（Extensions）にも対応しており^*2、表示や機能を自社の運用に合わせて調整できます。ただし拡張機能の追加やユーザー権限の設計は、導入前に方針を固めておかないと、部署ごとの利用ルールがばらついてしまう恐れがあります。

WebSubとXPathスクレイピングで更新の見落としを防ぐ

FreshRSSはWebSub（旧PubSubHubbub）というプッシュ型通知の標準規格に対応しています^*2。対応フィード側がWebSubをサポートしていれば、定期的な巡回を待たずに更新をリアルタイムに近い形で受け取れる仕組みです。競合他社のプレスリリースや採用情報のように、公開タイミングが重要な情報を追う場合には有用な機能でしょう。

加えて、XPathを使ったウェブスクレイピング機能も備えています^*2。RSS/Atomフィードを配信していないウェブページであっても、XPathで指定した要素を抽出し疑似的なフィードとして取り込める仕組みです。フィード非対応のニュースサイトや官公庁の告知ページを情報収集の対象に加えたい場合、この機能が選択肢になります。JSON文書のサポートも明記されており^*2、フィード形式が限られる情報源への対応幅は比較的広いと言えます。

Google Reader API・Fever APIでモバイル・外部クライアントと連携する

2つのAPI方式の違い

FreshRSSはブラウザ経由のアクセスに加え、ネイティブアプリ経由でもモバイル端末から利用できます^*5。外部クライアントとの連携には2種類のAPIが用意されており、Google Reader互換APIが最も機能が充実した方式として案内されています^*5。もう一方のFever APIは、公式ドキュメントで「機能が限定的で効率も劣る」と位置づけられています^*5。特別な事情がない限り、Google Reader互換APIを優先する判断が妥当でしょう。

Google Reader互換APIは「/api/greader.php」、Fever APIは「/api/fever.php」のエンドポイントにモバイルアプリからアクセスする仕組みです^*5。対応クライアントの例としてEasyRSSが公式ドキュメントで挙げられています^*5。

有効化の手順と社内展開時の注意点

APIを使うには、管理画面の認証設定で「Allow API access（モバイルアプリに必要なAPIアクセスを許可）」を有効にしたうえで、プロフィール画面から利用者ごとにAPIパスワードを設定する必要があります^*5。この設定はユーザー単位で個別に必要となるため^*5、複数部署へ展開する際は初期設定の手順を案内する運用ルールをあらかじめ用意しておくと混乱を避けやすくなります。

Docker Composeで構築する標準的な導入手順

公式のDocker READMEでは、次のようなdocker runコマンドが構築例として示されています^*4。

docker run -d --restart unless-stopped --log-opt max-size=10m \
  -p 8080:80 \
  -e TZ=Asia/Tokyo \
  -e CRON_MIN=1,31 \
  -v freshrss_data:/var/www/FreshRSS/data \
  -v freshrss_extensions:/var/www/FreshRSS/extensions \
  --name freshrss \
  freshrss/freshrss

環境変数TZでタイムゾーンを指定し、CRON_MINでコンテナ内蔵のcronによるフィード自動更新の実行分を定義します^*4。データはfreshrss_dataボリューム、拡張機能はfreshrss_extensionsボリュームへ永続化される構成です^*4。公式イメージはlinux/amd64・linux/arm64・linux/arm/v7の各アーキテクチャに対応しています^*4。

リバースプロキシ配下で運用する場合は、X-Forwarded-ProtoやX-Forwarded-Prefixといったヘッダーの転送設定が必要になる点も公式READMEで案内されています^*4。OpenID Connectによる認証もOIDC_ENABLED等の環境変数を追加することで有効化できます^*4。社内の既存認証基盤と連携させたい場合は、この設定を事前に確認しておくとよいでしょう。

サーバー要件とデータベース選定の注意点

公式ドキュメントの前提条件ページによると、PHP 8.1以上が推奨されており^*3、必須のPHP拡張としてlibxml・cURL・JSON・PDO_MySQL・PCRE・ctypeが挙げられています^*3。32ビット環境ではGMP拡張も必要です^*3。推奨される拡張にはZlib・mbstring・iconv・ZipArchiveがあり^*3、これらを揃えておくと処理が安定しやすくなります。

データベースはPostgreSQL 10以上が推奨されている一方^*3、SQLite・MariaDB 10.6以上・MySQL 8.0以上にも対応しています^*3。少人数運用であればSQLiteで始め、利用部署が増えてから外部データベースへ移行する進め方も選べるでしょう。ウェブサーバーはApache 2.4が推奨で、nginxとlighttpdも利用可能とされています^*3。ファイル権限については、Webサーバーの実行ユーザー（例：www-data）へ所有権を与え、dataフォルダに書き込み権限を付与する必要があると案内されています^*6。この権限設定を誤ると、フィードの取込や設定保存でエラーが発生する原因になりやすい部分です。

セルフホスト内製と外注委託のコスト構造比較

FreshRSSをセルフホストで自社構築する場合と、外部パートナーへ委託する場合では、費用構造・必要スキル・リスク対応の重心が異なります。以下の表に主な違いを整理しました。

内製構築に必要なスキルと外注との違い

Docker運用・認証設計・分類ルール整備に求められる専門知識

FreshRSSを内製で構築・運用する場合、求められる知識は複数の分野にまたがります。Dockerコンテナの運用とサーバー管理、PHP・データベースの要件確認、リバースプロキシ経由でのヘッダー設定、認証方式（Webフォーム・HTTP認証・OpenID Connect）の選定、タグやワークフローによる分類ルールの整備がその内容です。自社の情報システム部門だけでこれらを完結させるには、複数の担当者が連携する体制を整える必要があるでしょう。

判断を先送りにしたまま自己流で構築を進めると、consumeフォルダに相当する取込設定の不整合や、APIパスワード運用の周知不足といった問題に後から気づくケースが生じます。特にリバースプロキシ配下でのヘッダー転送設定を見落とすと^*4、ログインや API連携が正しく動作しない事態にもつながりかねません。

専門パートナーに委託した場合の違い

専門パートナーに依頼すると、Docker環境の構築から認証設定、複数部署へのアカウント展開、バージョンアップ時の動作確認まで一連の工程を任せられます。自社では構成検討や動作検証だけで時間がかかる場面でも、複数の情報基盤を扱ってきた知見を活用すれば、稼働までの期間を圧縮しやすくなるでしょう。内製と外注のどちらを選ぶ場合でも、まずは自社で追いたい情報源の整理と、共有したい部署の範囲を明確にすることが出発点になります。

まとめ：FreshRSSセルフホスト活用の3つの判断軸

本稿ではFreshRSSの機能とセルフホスト構築の要点を、公式サイト・GitHubリポジトリ・公式ドキュメントの情報に基づいて整理しました。要点は次の3つに集約されるでしょう。第一に、複数のRSS/Atomフィードを自社サーバーへ集約し、タグ・保存検索・マルチユーザー対応で情報収集を一元管理できる点です^*1*2。第二に、WebSub・XPathスクレイピング・Google Reader API等の機能により、更新の取りこぼしを防ぎながらモバイル端末や外部クライアントとも連携できます^*2*5。第三に、Docker構築や認証設計、部署展開には専門知識が求められるため、内製と外注のどちらで進めるかを費用構造とリスクの両面から見極める必要があります^*3*4。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：FreshRSS公式サイト（https://freshrss.org/）
2. *2　出典：FreshRSS公式GitHubリポジトリ「README」（https://github.com/FreshRSS/FreshRSS）
3. *3　出典：FreshRSS公式ドキュメント「Prerequisites」（https://freshrss.github.io/FreshRSS/en/admins/02_Prerequisites.html）
4. *4　出典：FreshRSS公式GitHubリポジトリ「Docker README」（https://github.com/FreshRSS/FreshRSS/blob/edge/Docker/README.md）
5. *5　出典：FreshRSS公式ドキュメント「Mobile access」（https://freshrss.github.io/FreshRSS/en/users/06_Mobile_access.html）
6. *6　出典：FreshRSS公式ドキュメント「General installation instructions」（https://freshrss.github.io/FreshRSS/en/admins/03_Installation.html）

Tweet