UTARMP(UMP)をつくっている話 — 複数メディアを 1 つの管理画面から

2026-06-25 プロダクト

気がつくと、運用するサイトが増えていました。地方紙の web 展開、地域メディア、リサーチハブ、そして下川町の店舗や会社のサイト。それぞれに別々の CMS や入稿の作法があって、サイトが 1 つ増えるたびに、覚えることと手間が積み増しになっていく。

UTARMP — 普段は UMP（UTAR Media Platform）と呼んでいます — は、この積み増しを止めるためのものです。複数のメディアを、1 つの管理画面から入稿・校閲・配信し、サイトごとのビルドからデプロイまでを自動化する。

サイトごとの違いは、裏で吸収する

メディアは、それぞれ事情が違います。記事だけのサイトもあれば、固定ページとお知らせだけの店舗 HP もある。出力先も、Astro のリポジトリだったり、置き場所のパスが違ったり。公開の仕組みも、GitHub にコミットしてからビルドを叩くもの、デプロイフックを撃つもの、とまちまちです。

UMP は、この違いをアダプタという形で裏に吸収しました。メディアごとに「種類（記事 / 固定ページ / お知らせ）」「出力先」「公開のしかた」を定義しておけば、書く人は管理画面で同じ操作をするだけ。あとはプラットフォームが、そのメディアに合った場所へ、合った形で届けます。

実際にいまは、地方紙の web から、地域メディア、リサーチハブ、店舗 HP、会社 HP まで、十数のメディアを横断して動かしています。最初に dohoku.net で土台を固めて、そこで通った形を他のサイトに広げていきました。

UMP は UTAR と ID を共有しています。といっても 1 つの巨大なデータベースを共有しているわけではなく、メールから導いた同じ鍵を使うことで、別々のアプリでも「同じ人」として扱える形にしました。誰がどのメディアを運営できるか、という権限も、この ID の上に乗せています。

入稿のたびに発生する地味な作業 — 校閲、タグ付け、要約 — は、AI に下ごしらえをさせています。人がゼロから書くのではなく、たたき台を出させて、人は判断と仕上げに回る。記事数が増えても運用が重くならないように、ここは早めに手を入れました。

承認のフローも挟んであります。書いてすぐ世に出るのではなく、確認を通してから公開する。メディアごとに、即時公開か承認制かを選べるようにしています。

つくっていていちばん学びがあるのは、実際に回しはじめてから見える無駄のほうです。

たとえば、トップページの編成。編集するたびにサイト全体のビルドが走ってしまうと、記事数の多いサイトでは再ビルドの行列ができて、何分も待たされる。そこで「編成を変える操作」と「サイトに反映する操作」を切り離して、編集中は無駄にビルドを走らせないようにしました。

こういう、使ってみないと気づけない摩擦を 1 つずつ削っていく作業が、CMS をつくるということの実体なんだと思っています。

「メディアを増やすほど、運用が重くなる」を、「増やすほど、運用が軽くなる」に反転させたい。共通化できるところは徹底して共通化し、違いだけを最小限のアダプタで吸収する。発信する人が、書くことそのものに時間を使える状態を、裏側からつくっています。