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で個別指導を届ける仕組み、一人ひとりに最適化する設計思想まで、開発の背景と技術的な工夫を開発者が解説します。

【社長の知識をAIに】園芸の知識を学習したAIを開発しました。
AI

【社長の知識をAIに】園芸の知識を学習したAIを開発しました。

YouTube動画159本の知識をベースに社長AIを構築しました。 利用ケースなども考慮しながらAIモデルの設計・開発を行いましたのでその開発記録をご紹介します。

人工衛星×AIで土地の変化を検出するアプリを開発|実際のシステムの画面も公開
AI

人工衛星×AIで土地の変化を検出するアプリを開発|実際のシステムの画面も公開

衛星データ(Sentinel-2)を活用して、土地の変化や不正利用・無許可造成を広域で検知・監視する方法を、企業・自治体向けにわかりやすく解説します。仕組みや活用場面、導入時の注意点に加え、micomiaが開発する土地利用の異常監視システムの実例もご紹介します。

AI駆動開発とは?プロンプトだけでアプリを作る方法との違いを開発会社が解説
開発用語集

AI駆動開発とは?プロンプトだけでアプリを作る方法との違いを開発会社が解説

AI駆動開発とは、AIにアプリ開発を丸投げする方法ではありません。エンジニアが設計と品質に責任を持ち、AIで実装、テスト、レビューを効率化する開発方法です。プロンプト生成型との違いや、品質と安全性を高める考え方を初心者向けに解説します。

グリラボとは?写真から植物や庭の悩みを相談できるAI園芸サポートアプリ
その他

グリラボとは?写真から植物や庭の悩みを相談できるAI園芸サポートアプリ

グリラボは、植物や庭の写真から、種類・状態・病害虫・剪定・雑草対策などをAIに相談できる園芸アプリです。限定・お値打ちな植物を購入できるアウトレットショップも利用できます。

micomiaのセキュリティ対策 — お客様のアプリを守るために、私たちがすること
発注ガイド

micomiaのセキュリティ対策 — お客様のアプリを守るために、私たちがすること

micomiaが全開発案件に標準で組み込むセキュリティ対策を、スマホアプリ編・Web編に分けて解説します。App Check、二層防御、XSS・CSRF対策、鍵の管理方法など、専門用語も一つずつご説明します。

アプリの調子がおかしい6つの症状|原因の見立てと、自分で直せるか開発会社に頼むかの分かれ目
発注ガイド

アプリの調子がおかしい6つの症状|原因の見立てと、自分で直せるか開発会社に頼むかの分かれ目

アプリの画面が真っ白、ボタンが反応しない、プッシュ通知が届かない、403エラー、退会しても使えるなど、よくある6つの症状について、考えられる原因と、自分で確認・対応できる範囲、開発会社に頼むべき範囲を整理し、解説しています。

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

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

FlutterFlowが苦手とするStripeのサブスク決済や帳票生成、セキュリティ・デザイン自由度の制約を、開発会社が実例つきで整理しました。どこで限界に当たり、どう回避してFlutterと使い分けるかの判断基準まで分かります。

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

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

AI駆動開発は速さの裏で落とし穴も増えます。曖昧な指示でかえって遅くなる、セキュリティや依存関係の見落とし、コードの一貫性の崩れといった注意点と対策を、非エンジニアが陥りやすい権限・データ保存の失敗もあわせて解説します。

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

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

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

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

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

ECサイトをシステム会社へ発注する前に要件を整理しないと、見積もりのズレや追加費用が生じやすくなります。決済・配送・会員管理・管理画面・外部連携など10領域の全項目をチェックリスト形式でまとめ、発注前に押さえるべき要件が分かります。

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

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

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

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

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

アプリ開発費用の相場はSNS・マッチング・業務系など種類で大きく変わります。ノーコード・MVP・フルスクラッチそれぞれの費用目安と内訳、予算を抑えるコツや依頼前に整理しておきたいポイントを開発会社が分かりやすく解説します。

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

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

恋愛系マッチングアプリの開発で失敗しないために、作る前に詰めておきたい6つのポイントを解説します。ターゲット設定やマネタイズ、不正ユーザー対策、年齢確認の実装、プロフィール設計、マッチングアルゴリズムまで押さえるべき要点が分かります。