micomia

Blog

技術記事

アート特化SNSアプリ「Artl」開発記録|作品ファースト設計・「鑑賞しました」・トリミングしない展示の裏側

アート特化SNSアプリ「Artl」開発記録|作品ファースト設計・「鑑賞しました」・トリミングしない展示の裏側

開発の背景——なぜ既存SNSではアートが評価されないのか

SNSがクリエイターの発信拠点になって久しい。InstagramやX(旧Twitter)、Pinterestなど、多くのプラットフォームで毎日無数の作品が投稿されている。それにもかかわらず、絵画や彫刻、版画、立体造形といった芸術作品を真剣に作る人たちの多くは、「既存のSNSで自分の作品が正しく伝わっている気がしない」という感覚を持っていた。

この違和感の正体は何か。Artl の開発は、この問いへの答えを探すところから始まった。

問題は機能の不足ではなかった。既存のSNSには投稿機能も検索機能もコメント機能もある。問題は、情報の流れ方そのものが、作品を鑑賞する体験と根本的に噛み合っていないことにあった。

一般的なSNSのタイムラインには、アート作品と、食事の写真と、日常のつぶやきと、広告が同列で並ぶ。ユーザーの視線と意識は次々に別のコンテンツへ引っ張られる。アート鑑賞のように「一つの対象に没入する」体験には、そもそもの前提が違いすぎる環境だった。

作者側にも別の歪みが生じていた。既存SNSでは注目を集めやすい見せ方が自然と強化される。その結果、「本当に表現したいこと」より「反応されやすいもの」へ作風が引っ張られていく。これはアルゴリズムの問題というより、プラットフォームの設計思想そのものが持つ引力だった。

もう一つ、具体的な問題があった。多くのSNSでは、投稿した画像がプラットフォームの表示都合に合わせてトリミングされる。しかし芸術作品において、構図・余白・縦横比は表現の一部だ。アプリの都合で切り取られた瞬間、作品の意図は損なわれる。

芸術作品そのものにフォーカスした場がない。その一点が、Artl を開発する出発点になった。

「作品ファースト」を設計原則にした理由

課題が明確になったところで、次に問われたのは「ではどんな設計にするか」という点だった。Artl が辿り着いた中心原則は、「作品ファースト」という考え方だ。

作品ファーストとは、作品に演出を加えることではない。むしろ逆だ。アプリ側の存在感を限りなく薄め、作品がそのまま前に出てくる状態を作ることを指す。

なぜこの原則を置くことにしたか。それは、アートSNSが陥りやすい罠を避けるためだった。アート専用と銘打っても、UI設計をしっかり作り込みすぎると、アプリ自体のデザインが主張しすぎてしまう。独自の世界観が強すぎると、作品はそのデザインの中に取り込まれ、作品固有の印象が薄れる。

アプリは空気のように存在し、作品が自然に立ち上がる」——これがArtl の設計思想の核心だ。

この原則は、あらゆる細かな判断の基準になった。タイムラインの情報量はどこまで絞るか、UIの色はどうするか、どこに何のボタンを置くか。一つひとつの判断において「これは作品の前に出すぎていないか」が問われた。

また、作品ファーストの設計は、作家側だけでなく鑑賞者にとっても重要だった。鑑賞者が求めているのも、作品に集中できる空間だ。アプリ内の余計なノイズが少ないほど、作品への没入は深くなる。発信する人と受け取る人の両方にとって自然な場所を作ることが、この原則の目的だった。

トリミングしない・いいねしない——既存SNSとの根本的な違い

作品ファーストという原則を実装に落とし込む過程で、最も大きな判断になったのが二つある。「トリミングをしない」と「いいねボタンを置かない」だ。どちらも、既存SNSの当たり前を外す決断だった。

なぜトリミングしないのか

Artl では、投稿された作品を一切トリミングしない。アプリの表示枠に合わせて切り抜くこともなく、角を丸くする加工も行わない。作品はそのままの形で展示される。

この判断の理由はシンプルだ。芸術作品において、構図・余白・縦横比は表現の一部だからだ。絵画であれば画面の端まで意図がある。写真であれば余白にこそ呼吸がある。それをアプリの表示都合で切り取ることは、表現そのものへの介入になりうる。

一般的なSNSでは、フィード上でカード形式に統一するために画像側を調整させることがある。しかしそれは「アプリに合わせるための作業」であって、「作品のための作業」ではない。Artl はそのズレをなくすために、アプリ側が作品に合わせる設計を選んだ。

鑑賞者の側からも、この判断には意味がある。絵柄や被写体だけを切り取って見るのと、作品全体の比率・余白ごと受け取るのでは、作品の印象はまったく異なる。「生の作品に出会える」という感覚は、この設計から生まれている。

なぜいいねをなくしたのか

Artl には「いいね」ボタンがない。代わりに設置されているのが「鑑賞しました」という機能だ。

なぜいいねを外したか。いいねの数が可視化されると、人はどうしても反応を集めやすい方向を意識し始める。それは芸術においても例外ではない。いいねを意識すれば、表現したいことより反応されやすい見せ方が前に出てしまう。この歪みが、アート作品の制作活動にとって本質的でないと判断した。

「鑑賞しました」という言葉を選んだのは、作品との関わり方そのものを変えるためだ。作品は軽く評価されるものではなく、まず鑑賞されるものだという前提を、ボタンの名前によって示している。

この判断は作家にとっての安心感になるだけでなく、鑑賞者にとっても意外な利点があった。「いいね」を押す行為は「これが好き・良い」という評価を意味するため、軽く押すことへの心理的なハードルがある。一方で「鑑賞しました」は評価ではなく事実の表明だ。「見た」「向き合った」という行為を示すだけなので、反応のハードルが自然と下がる。作家はより多くの鑑賞者から応答をもらいやすくなる。

投稿体験・リアクション設計の具体的な判断

作品ファーストの原則は、投稿フローの細部にまで及んだ。作家が実際に作品をアップロードして公開するまでの体験が快適でなければ、どれだけUIが洗練されていても意味がない。

投稿フローをできる限り軽くする

Artl の投稿画面は、作品画像とキャプション(作品説明)の入力が中心だ。キャプションは任意入力にした。必ず何か書かなければ投稿できない設計では、作家に余計なプレッシャーがかかる。作品だけで出すことも、一言添えることも、どちらも自然にできる状態が望ましかった。

また、タグ付けやカテゴリ選択など、アプリ側の都合による入力項目は排除した。投稿のたびにアプリ都合の作業を求めることは、発信へのハードルを上げる。作品そのものと、必要なら言葉だけで発信できる——この軽さが、投稿体験の核だ。

サブ情報の扱い方にも工夫がある。作品に直接関係しない情報(プロフィール設定、フォロワー管理、作品の編集・削除)はマイページ側に集約した。タイムライン上では作品が主役であり続けるよう、情報の住み分けを徹底している。

タイムラインは作品のみが流れる

タイムラインの設計でも、情報量を意図的に絞った。一般的なSNSでは、投稿者の名前・フォロワー数・コメント数・広告などが作品の周囲を取り囲む。Artl ではこれらの情報を最小化し、作品が流れてきたとき、まず作品が見える状態を優先した。

情報量が多いと、ユーザーの注意は分散する。余計な情報を削ることで、視線が自然と作品へ集まる。鑑賞体験の質は、この設計の積み重ねによって決まる。

言葉の選び方にこだわった

開発で特に難しかったのが、用語の選び方だった。一般的なSNS由来の言葉をそのまま使うと、アプリ全体が「普通のSNS」に寄ってしまう。フォロー・フィード・リポスト——これらの言葉はすでにある種の行動様式と結びついている。アート専用の空間に相応しい言葉を選び直すことが、世界観を守るうえで重要な作業だった。

「鑑賞しました」はその最も象徴的な例だが、アプリ全体を通じて「芸術に合わせてSNSの形を考える」という視点で言葉を選んでいる。

クリエイターが安心して発信できるための設計

アートSNSとして本当に機能するためには、技術的な設計だけでなく、作家が心理的に安心して使える環境が必要だ。どれだけ洗練されたUIでも、作家が「本当に自分の作品を出していい場所だ」と思えなければ意味がない。

評価軸を変えることで生まれる安心感

「いいね」から「鑑賞しました」への変更は、単なる機能の差し替えではない。作品の評価軸そのものを変えることで、作家が発信しやすくなる環境を作っている。

いいねの数を争うプラットフォームでは、反応が少ない作品は「評価が低い」と見なされがちだ。その空気が作家を萎縮させる。「鑑賞しました」という仕組みでは、数の多寡より「誰かが向き合ってくれた」という事実が前に立つ。一人の鑑賞者が真剣に向き合ってくれたことの重さが、数字の多寡より意味を持つ設計だ。

作品をトリミングしないことが信頼につながる

作品が加工されずそのまま表示されることは、作家への信頼の表明でもある。「このプラットフォームに出せば、作品の意図は守られる」という確信がなければ、大切な作品を出す気にはなれない。

特に繊細な表現を大切にする作家ほど、トリミングや加工への抵抗感は強い。Artl がこの点を徹底しているのは、そうした作家に安心して使ってもらうためだ。

アルゴリズムではなく新着順で並べる

現バージョンのArtl では、作品は新着順に並ぶ。レコメンドアルゴリズムで「バズりやすい作品」が優先されることはない。

この設計には理由がある。アルゴリズムによる優先表示は、どうしても「反応を集めやすいもの」を増幅させる傾向がある。それは既存SNSで起きていた「反応されやすい見せ方への誘導」と同じ力学だ。新着順にすることで、投稿した順番に等しく目に触れる機会が与えられる。知名度や過去の実績ではなく、作品そのものが直接届くことを優先した結果だ。

ただし、この設計は将来的な課題も孕んでいる。投稿数が増えれば、新着順だけでは作品の回遊性が下がる可能性がある。アルゴリズムを使わずに多くの作品に出会える仕組みをどう作るか——これが次のアップデートで向き合うべきテーマだと認識している。

作品以外の情報はタイムラインに出さない

作家のフォロワー数や、過去の投稿への反応数、外部リンクなど——これらの情報はタイムライン上に表示しない。こうした数字が見えると、鑑賞者は作品そのものより「この人は有名なのか」「この投稿は人気があるのか」という文脈で判断しがちになる。

作品を作品として受け取ってもらうためには、そうした外部の評価軸をタイムラインから取り除くことが必要だった。

開発を通じて学んだこと・まとめ

Artl の開発を振り返ると、最も難しかったのは技術的な実装ではなく、「芸術専用のSNSが普通のSNSになってしまう」という引力に抗い続けることだったと感じている。

「普通のSNSに寄ってしまう」という開発上の罠

開発を進める中で、何度も「ここは一般的なSNSと同じ設計でいいのでは」という誘惑があった。いいねボタンを置けばユーザーになじみやすい。タグ機能を充実させれば検索性が上がる。レコメンドアルゴリズムを入れれば回遊性が高まる。

どれも正しい観点だが、そのまま採用するとArtl が目指す体験から離れていく。目的を明確に持ち続けながら、一つひとつの機能を「これは作品ファーストに適しているか」で判別する——このプロセスが開発の中心にあり続けた。

用語の選び方でも同じ難しさがあった。「フォロー」「フィード」「いいね」などSNSで広く使われる言葉は便利だが、そのまま使うとアプリ全体のトーンが一般SNSに近づいてしまう。言葉の選択にまで設計思想を貫くのは、地味だが重要な作業だった。

SNSの文脈に合わせるのではなく、芸術に合わせてSNSを考える

Artl の開発から得た最も大きな学びは、特化型SNSを作る際には「既存SNSをベースに特化機能を足す」という発想では不十分だということだ。

アートに特化させるということは、アート体験に最適な情報の流れ方を設計することであり、アート作家が安心して出せる評価軸を設計することだ。それは既存SNSのパーツを取捨選択することではなく、何のための場を作るかという問いから設計を始めることを意味する。

今回の開発では、トリミングしないこと・いいねを置かないこと・タイムラインの情報量を絞ることの三点が、その問いへの答えとして形になった。

現バージョンの課題と次のステップ

現時点のArtl で手応えがあったのは、投稿フローと「鑑賞しました」機能だ。作品を出す体験と、受け取る体験のどちらにおいても、作品中心であることが崩れていないと感じている。

一方で、課題も明確になっている。作品の回遊性・露出の設計だ。新着順の表示は公平だが、投稿数が増えたときに「まだ見ぬ良い作品」との出会いを作りにくくなる。作品中心であることを守りながら、より多くの作品に自然に出会える仕組みをどう作るか——次のアップデートではここに向き合う。

Artl が目指す先

Artl が最終的に目指しているのは、芸術がもっと光を浴びる世界だ。SNSという形式に芸術を合わせるのではなく、芸術のためにSNSという形式を考え直す。その姿勢は、小さな機能の一つひとつに宿っている。

SNS上でのバズとは無縁でも、作品として深く誰かに届く体験がある。数百のいいねより、一人の鑑賞者が「これは本当に良かった」と感じる体験がある。Artl はそういう出会いを作るための場として、引き続き設計を磨いていく。

コミュニティアプリやSNSの開発を検討している事業者にとって、Artl の設計が示す最も重要な問いは「誰のための場を作るか」だ。ターゲットが決まれば、何を足すかより何を引くかが見えてくる。その削ぎ落としの積み重ねが、特化型サービスの価値を作る。

畑井駿佑

畑井駿佑

micomia株式会社の代表取締役です。 エンジニア、プロジェクトマネージャーを経験し、2024年にUI/UXにこだわった使いやすいシステム/アプリを開発するmicomia株式会社を設立しました。

関連記事

植物専門SNS「でぃぐりーん」開発記録|初心者が最初の一鉢を買えない課題をアプリで解決した方法
開発ストーリー

植物専門SNS「でぃぐりーん」開発記録|初心者が最初の一鉢を買えない課題をアプリで解決した方法

植物初心者が「どれを買えばいいか分からない」という課題を解決するために開発した植物専門SNS「でぃぐりーん」。専門SNSを作る前の現場体験、MVPでのスピード開発、位置情報UX、AI機能まで開発全体をまとめます。

建材特化フリマアプリ「Mate-Re:」開発記録|業界特化設計・決済・UI/UXの裏側
開発ストーリー

建材特化フリマアプリ「Mate-Re:」開発記録|業界特化設計・決済・UI/UXの裏側

建設現場で廃材が捨てられる課題を解決するために生まれた「Mate-Re:」。業界特化フリマアプリの設計思想・現場目線のUI/UX・Stripe Connect決済実装・循環経済の設計まで、開発の全体像をまとめました。

医療従事者向けSNS「メディカルサークル」開発記録|信頼感のUI設計・RevenueCat課金・コミュニティ安全設計の裏側
開発ストーリー

医療従事者向けSNS「メディカルサークル」開発記録|信頼感のUI設計・RevenueCat課金・コミュニティ安全設計の裏側

医療従事者専用SNS「メディカルサークル」の開発記録を公開しています。医療情報の安全な共有設計・RevenueCatによる課金実装・コミュニティ安全設計・専門家認証機能など、開発の裏側を詳しく解説します。ぜひこの記事を確認してみてください。

建設現場向け日本語学習アプリ「ゲンゴー」開発記録|外国人技能実習生・多言語対応・4択クイズ設計の裏側
開発ストーリー

建設現場向け日本語学習アプリ「ゲンゴー」開発記録|外国人技能実習生・多言語対応・4択クイズ設計の裏側

建設現場で働く外国人技能実習生向けの日本語学習アプリ「ゲンゴー」の開発記録を公開しています。多言語対応・4択クイズ設計・建設業界特化コンテンツの設計思想など、ニッチ特化アプリ開発の裏側を詳しく解説します。ぜひこの記事を確認してみてください。

園芸サポートアプリ「グリラボ」開発記録|初心者向けUI・育成ガイド・楽しさ設計の裏側
開発ストーリー

園芸サポートアプリ「グリラボ」開発記録|初心者向けUI・育成ガイド・楽しさ設計の裏側

植物初心者が「続けられない」課題を解決するために開発した園芸サポートアプリ「グリラボ」。文字を詰め込まないUI設計、育成ガイド、ゲーミフィケーション、AI機能の役割分担まで、開発の全体像をまとめます。

AI野球コーチアプリ「NEOLAB AI」開発記録|スポーツ×AI・チャットUI・個別最適化の設計思想
開発ストーリー

AI野球コーチアプリ「NEOLAB AI」開発記録|スポーツ×AI・チャットUI・個別最適化の設計思想

AI野球コーチアプリ「NEOLAB AI」の開発記録を詳しく公開しています。スポーツ×AIの組み合わせ・チャットUIで個別指導を届ける仕組み・個別最適化の設計思想など、開発の背景と技術的工夫を開発者が解説します。今すぐ確認してみてください。

FlutterFlowでできないこと|開発会社が実例で解説する限界と回避策
発注ガイド

FlutterFlowでできないこと|開発会社が実例で解説する限界と回避策

FlutterFlowでできないこと・苦手なことを開発会社が正直に解説。Stripeのサブスク非対応、消費型の単発課金不可、PDF/Excel帳票生成、APIキーのハードコード、セキュリティ対策の重さ、デザインの自由度の低さに加え、ツール特有のバグや大規模開発の難しさまで、実例と回避策・使い分けの判断基準をまとめます。

AI駆動開発の注意点|開発会社が実践してわかった「速いけど危うい」落とし穴と対策
発注ガイド

AI駆動開発の注意点|開発会社が実践してわかった「速いけど危うい」落とし穴と対策

AI駆動開発は速い一方で注意点が多い領域です。開発会社が実践してわかった「曖昧な指示で逆に遅くなる」「セキュリティ・依存関係の見落とし」「コードベースの一貫性の崩れ」に加え、非エンジニアが生成AIで作るときに陥る権限設定・データ保存場所の落とし穴まで、対策とセットで解説します。

ノーコードでアプリ開発はどこまでできる?Adalo→FlutterFlow移行の実例で限界と本番化を解説
ノーコード・FlutterFlow

ノーコードでアプリ開発はどこまでできる?Adalo→FlutterFlow移行の実例で限界と本番化を解説

ノーコードアプリ開発の本音を開発会社が解説。Adalo・Glideなど無料ツールの特徴と限界から、FlutterFlowへの移行実例まで詳しく紹介。「どこまでできるのか」「どこで限界を感じるのか」を実際の本番開発経験をもとに率直にお伝えします。

ECサイトをシステム会社に発注するなら「要件リスト」を先に揃えるべき!|10領域の全項目チェックリスト
発注ガイド

ECサイトをシステム会社に発注するなら「要件リスト」を先に揃えるべき!|10領域の全項目チェックリスト

ECサイトをシステム会社に発注する前に要件を整理しないと見積もりズレや追加費用が発生します。決済・配送・会員管理・管理画面・外部連携など10領域の全項目チェックリストを公開します。発注前に必ずご確認ください。ぜひ今すぐ確認してみてください。

アプリ開発を依頼するには?費用・流れ・依頼先の選び方を開発会社が解説|micomia
発注ガイド

アプリ開発を依頼するには?費用・流れ・依頼先の選び方を開発会社が解説|micomia

アプリ開発を依頼する際の流れは要件整理→開発会社選定→見積もり比較→契約→開発→リリースの6ステップです。費用の目安・フリーランスと開発会社の違い・具体的な選び方を開発会社がわかりやすく解説します。詳しくは記事でわかりやすく解説しています。

アプリ開発費用の相場と内訳|種類別の目安・予算を抑えるコツ・依頼前の整理ポイントを開発会社が解説
発注ガイド

アプリ開発費用の相場と内訳|種類別の目安・予算を抑えるコツ・依頼前の整理ポイントを開発会社が解説

アプリ開発費用の相場はSNS・マッチング・業務系など種類によって大きく異なります。ノーコード・MVP・フルスクラッチの費用目安と内訳、予算を抑えるコツと依頼前の整理ポイントを開発会社がわかりやすく解説します。ぜひ今すぐ確認してみてください。

恋愛系マッチングアプリを作りたいと思ったら読む記事|開発会社が教える、作る前に詰めるべきこと
発注ガイド

恋愛系マッチングアプリを作りたいと思ったら読む記事|開発会社が教える、作る前に詰めるべきこと

恋愛系マッチングアプリを開発する前に失敗しないために詰めるべき重要ポイントが6つあります。ターゲット設定・マネタイズ方法・不正ユーザー対策・年齢確認の実装・プロフィール設計・アルゴリズムについて解説します。ぜひ今すぐこちらをご確認ください。

省人化とは?意味・読み方と中小企業のバックオフィス業務で進める具体的な方法
DX

省人化とは?意味・読み方と中小企業のバックオフィス業務で進める具体的な方法

省人化とは業務プロセスを自動化・効率化することで少ない人員で業務を遂行することです。RPA・AI・クラウドを活用した中小企業のバックオフィス省人化の具体的な4パターンと実践手順をわかりやすく詳しく解説します。ぜひ今すぐ確認してみてください。

SNSアプリの作り方完全ガイド|開発費用・作成手順・必要機能・成功事例まとめ
開発Tips

SNSアプリの作り方完全ガイド|開発費用・作成手順・必要機能・成功事例まとめ

SNSアプリを作る方法としてパッケージ開発とオーダーメイド開発を費用・機能・開発期間・ターゲット設定の4観点で徹底比較します。依頼前に整理すべき内容と費用相場を、SNS開発実績のある開発会社が詳しく解説します。ぜひ今すぐ確認してみてください。

【これ一本で丸わかり】FlutterFlowとは?できること・料金・日本語対応・iOS/Android開発までわかりやすく解説
ノーコード・FlutterFlow

【これ一本で丸わかり】FlutterFlowとは?できること・料金・日本語対応・iOS/Android開発までわかりやすく解説

FlutterFlowとは何か、できること・料金プラン・日本語対応・iOS/Android対応状況を開発会社が本音で解説。複数のアプリをApp Store・Google Playにリリースした実体験をもとに、メリット・デメリットまで包み隠さず紹介します。

システム受託開発とは?依頼前に知るべき流れ・契約形態・費用相場
発注ガイド

システム受託開発とは?依頼前に知るべき流れ・契約形態・費用相場

システム受託開発の流れは要件定義→設計→開発→テスト→納品の5工程です。請負契約・準委任契約の違い・費用相場(50〜1000万円以上)・信頼できる開発会社の選び方をわかりやすく詳しく解説します。詳しくはmicomiaブログをご確認ください。

要件定義が曖昧でも相談してよいのか|アプリ開発の進め方をわかりやすく解説
発注ガイド

要件定義が曖昧でも相談してよいのか|アプリ開発の進め方をわかりやすく解説

アプリ開発を検討中で要件定義が固まっていない方向けに、曖昧な状態でも開発会社に相談してよい理由と要件定義を一緒に進めるサポート体制についてわかりやすく詳しく解説します。micomiaにお気軽にご相談ください。ぜひ今すぐ確認してみてください。

FlutterFlowとFlutterの違いとは?特徴・開発スピード・使い分けを徹底比較
ノーコード・FlutterFlow

FlutterFlowとFlutterの違いとは?特徴・開発スピード・使い分けを徹底比較

FlutterFlowとFlutterは何が違うのか?開発スピード・カスタマイズ性・必要スキルの3軸で徹底比較。MVPや社内ツールにはFlutterFlow、高度な処理や独自UIにはFlutterなど、プロジェクト別の使い分け判断基準を解説します。