SuggestArr: 視聴履歴からSeerへの自動リクエストをつなぐセルフホスト型ツール
Effortlessly request recommended movies, TV shows and anime to Jellyseer/Overseer based on your recently watched content on Jellyfin, Plex or Emby—let SuggestArr handle it all automatically, keeping your library fresh with new and exciting content!
ひと目でわかる
- これは何？
- Jellyfin・Plex・Embyの視聴履歴をTMDbで類似検索し、Jellyseerr/Seerrへ自動でダウンロード要求を送るPython製アプリケーション。便利さの代わりに、外部APIとSeerの権限設定に依存する構造を確認しておきたい。
- 誰に向いている？
- 既にJellyseerr/Seerを運用し、TMDb APIキーを用意でき、Docker Composeで常時稼働させられる環境なら、SuggestArrは「誰が何を見たか」から候補を機械的に積み上げる手間を減らせる。逆に、Seerへのリクエストをすべて人手で承認したい場合や、外部APIへの送信を避けたい場合は、自動送信が既定で無効とはいえ候補生成そのものがTMDbとTraktに依存するため不向きである。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
誰の何を減らすツールなのか
SuggestArrが対象にするのは、Jellyfin、Plex、Embyのいずれかを自宅や小規模組織で運用し、その上にJellyseerrまたはSeerを立てている人である。Seerはリクエストを受け取ってからダウンロードを手配するが、リクエストを出す側の作業は人間がやる。視聴履歴を見て、似た作品を探して、タイトルを検索して、送信する。この繰り返しがSuggestArrの削減対象になる。READMEの説明では、メディアサーバーから最近視聴したコンテンツを取得し、TMDb APIで類似タイトルを検索し、Seerへ自動でダウンロード要求を送る、という流れになっている。利用者は自分だけでなく、サーバーにアカウントを持つ家族や同居人を選べる。User Selectionで対象ユーザーを絞り、Per-User Request Visibilityでメディアサーバーアカウント単位にリクエストを表示できる。管理者が全員分の候補を承認する運用と、各ユーザーに自分の分だけ見せる運用の両方が想定されている。
候補生成のデータフローとLLMの位置づけ
処理の骨格は、メディアサーバーの視聴履歴を種にしてTMDbへ問い合わせ、返ってきた類似タイトルをSeerへのリクエスト候補にする、という一本道である。ここにTrakt連携が任意で乗る。各ユーザーが自分のTraktアカウントをProfileからリンクすると、Traktの最近の視聴を推薦の種として使え、Trakt側で視聴済みの作品をスキップ対象に加えられる。管理者が設定するのはTrakt OAuthアプリのClient IDとClient Secretだけで、ユーザーごとの認可は各自が行う。この分担は、管理者が他人のTrakt資格情報を預からずに済む設計だと言える。LLMによる推薦はbeta扱いで、OpenAI互換のAPI（OpenAI、Ollama、Gemini、LiteLLMなど）を指定し、視聴履歴に基づく候補と、その選定理由を生成させる。AI Searchもbetaで、自然言語で見たいものを記述すると、視聴履歴に合わせたタイトルを探し、ワンクリックでSeerへ要求できる。いずれもTMDb検索を置き換えるものではなく、候補の選び方に別の層を足す機能と読める。
Docker Composeで起動しWeb UIで設定する
実行方法はREADMEではDocker Composeが前面に出ている。イメージはDocker Hubのciuse99/suggestarr:latest、またはGitHub Container Registryのghcr.io/giuseppe99barchetta/suggestarr:latestが使える。Compose例ではサービス名suggestarr、container_nameはSuggestArr、restart: always、ポートは${SUGGESTARR_PORT:-5000}を公開し、ボリュームとして./config_filesを/app/config/config_filesにマウントする。環境変数はLOG_LEVEL（既定info）とSUGGESTARR_PORT（既定5000）の2つが例示されている。起動はdocker-compose up。Web UIはhttp://localhost:5000、SUGGESTARR_PORTを変えた場合はそのポートになる。ここでメディアサービスの選択、APIキーとURLの検証（Configuration Pre-testing）、cronスケジュールの編集を行う。前提としてPython 3.xまたはDocker、TMDb API Key、設定済みのJellyfin/Plex/Emby、設定済みのSeerが必要で、PostgreSQL/MySQLは任意、Trakt OAuthアプリも任意である。特定のSeerユーザーとして要求を出したい場合は、Web UIでユーザー選択を有効にし、ドロップダウンでユーザーを選び、そのユーザーのパスワードを入力する。READMEはこの機能についてローカルSeerユーザーのみ対応と明記している。
承認ワークフローは既定で止まる
自動化ツールとして見落とされやすいのが、新規ジョブがグローバル設定Approve requests before sending them to Seerに従う点である。この設定はAdvancedにあり、既定では無効、つまり承認なしで送信される側に倒れている。ジョブごとにこの設定を継承させるか、常に承認する側・常に自動送信する側へ上書きできる。保留された候補はRequestsページに並び、ジョブの所有者か管理者がSeerへ送る、拒否する、グローバルにブラックリスト登録する、のいずれかを選ぶ。Request Workflowには、SuggestArrの候補がレビュー待ちの間そのジョブを一時停止させる設定と、保留のまま一定日数経過した候補を自動で拒否する設定がある。一時停止の挙動はジョブ単位で上書きできる。ここから読み取れるのは、作者が完全自動運転を推奨しているわけではないという姿勢である。既定が自動送信である以上、導入時にまずこのチェックボックスを確認しないと、意図しないリクエストがSeerに流れる。
止まる条件と、向かない使い方
SuggestArrには「送らない」ための仕組みが複数ある。Pending-Request Job Pauseは、Seer側に承認待ちか拒否待ちのリクエストが残っている間、スケジュール実行と手動実行の両方をスキップする。Unwatched-Suggestion Pauseは、ユーザーがSuggestArr経由のリクエストを一定日数内に視聴しなかった場合にスケジュール実行を止める。手動実行はこの場合も使える。Cleanup Automationは、Plex・Jellyfin・Embyでお気に入りに登録されなかったSuggestArr発のリクエストとファイルを削除する任意機能である。つまり、リクエストを積むだけでなく回収もする。ここで注意したいのは、これらの停止条件がすべて「Seerやメディアサーバーの状態」に依存している点だ。SeerのAPIが落ちていれば保留判定もできない。視聴履歴の取得元が一時的に不調なら種が空になる。また、外部のストリーミング配信で視聴可能なコンテンツを国単位で除外するContent Filteringは、あくまでTMDbの配信情報に依存する。配信状況が誤っていれば、見られる作品を要求してしまうか、見られない作品を除外してしまう。リクエストの重複排除や、既にライブラリにある作品の判定がどこまで効くのかは、READMEからは読み取れない。導入前に自分のライブラリで試すべき領域である。
Seer側の既存ツールとの違い
比較対象として素直なのは、Jellyseerr/Seer自身が持つ「似た作品」表示や、メディアサーバー側の推薦機能である。これらはユーザーが画面を開いて選ぶことを前提にしており、履歴の収集も候補の提示も閲覧時の一回性が強い。SuggestArrはそこをcronで回す。Web UIからスケジュールを編集し、決まった時刻に履歴を取りに行き、TMDbへ問い合わせ、結果をSeerのリクエストキューに積む。違いは操作の有無ではなく、実行がユーザーの閲覧行動から切り離されている点にある。だからこそ、承認を挟むかどうか、保留を何日で自動拒否するか、視聴されない候補をいつ掃除するか、という運用パラメータが本体に組み込まれている。逆に言えば、単発で「今日はこれを追加したい」と考える使い方には向かない。AI Searchの自然言語入力はその隙間を埋める機能だが、beta表記のとおり安定性の保証はない。
MITライセンスと更新頻度から見る維持コスト
ライセンスはMITで、リポジトリはアーカイブされていない。直近のリリースはv2.14.0（2026-09-08）、v2.13.0（2026-08-24）、v2.12.0（2026-08-05）で、おおよそ2週間から3週間の間隔で版が上がっている。この頻度は、機能追加が続いている一方で、追従する側にもそれなりの更新作業が発生することを意味する。Dockerイメージのタグはlatestが例示されており、固定タグの運用についてはREADMEに記述がない。構成ファイルはホストの./config_filesにマウントされるため、イメージを差し替えても設定は残る。外部DBを使う場合、SQLiteからの移行がどこまで自動化されているかはREADMEの範囲では確認できない。MITライセンスなので改変や再配布は可能だが、TMDb、Trakt、OpenAI互換API、Seerといった外部サービスの利用規約は別途それぞれに従う必要がある。ここは法的助言ではなく、導入時に自組織の規約と照合すべき項目の指摘である。
編集部の結論
既にJellyseerr/Seerを運用し、TMDb APIキーを用意でき、Docker Composeで常時稼働させられる環境なら、SuggestArrは「誰が何を見たか」から候補を機械的に積み上げる手間を減らせる。逆に、Seerへのリクエストをすべて人手で承認したい場合や、外部APIへの送信を避けたい場合は、自動送信が既定で無効とはいえ候補生成そのものがTMDbとTraktに依存するため不向きである。導入前に確認すべきは、AdvancedにあるApprove requests before sending them to Seerの現在値と、各ジョブのオーバーライド設定、そして外部DBを使う場合はSQLiteからPostgreSQL/MySQLへの移行手順がREADMEにどこまで書かれているかである。
コミュニティノート