micomia

Blog

技術記事

アート特化SNSアプリ「Artl」開発記録|作品ファースト設計・投稿体験・クリエイター向けUXの裏側

アート特化SNSアプリ「Artl」開発記録|作品ファースト設計・投稿体験・クリエイター向けUXの裏側

作家やクリエイターが既存のSNSで作品を投稿すると、作品そのものより「バズ」や「いいね数」が評価軸になりがちです。アート作品が正当に鑑賞される場がない——そんな課題意識から生まれたのが「Artl」です。
「作品ファースト」を設計原則に掲げ、UI・投稿体験・リアクションの仕組みまで、既存SNSとは全く異なるアプローチで設計されました。


目次


作品ファーストとは何か? Artlが設計した“作品を邪魔しないUI”

はじめに

Artl を一言で表すなら、芸術特化のSNSアプリです。
ただし、その特徴は単にテーマをアートにしたことではありません。
中心にあるのは、作品ファーストという考え方です。

作品ファーストとは、作品を優先すること

このアプリにおける中心価値は、作品を邪魔しない構成であることです。
作品中心の設計とは、トリミングをしないこと、世界観を過度に持たないUIにすること、投稿しやすいことを意味しています。
アプリ側が前に出すぎず、作品そのものがまず見えることを優先しています。

作家と鑑賞者の両方にとって自然であることが重要だった

作家にとって使いやすいだけでは、アートSNSとして十分ではありません。
鑑賞者にとっても、作品が自然と目につき、無理なく向き合える必要があります。
そのためArtl では、作品がそのまま展示されるタイムラインを重視し、UI全体も主張しすぎない方向で整えています。

アプリの世界観に作品を持っていかせない

多くのアプリは、独自のデザインや装飾で印象を作ります。
しかしArtl では、その強い世界観がかえって作品の印象を奪う可能性を避けています。
アプリは空気のように存在し、作品が自然に立ち上がること。
それが、このUI設計の核になっています。

まとめ

作品ファーストとは、作品に特別な演出を加えることではありません。
むしろ、余計な干渉を減らし、作品がそのまま届く状態を作ることです。
Artl は、その思想をUI/UXにまで落とし込んだアプリです。


アート作品を主役にするSNS UI設計とは

はじめに

鑑賞者にとって見やすいアートSNSとは何か。
Artl が出した答えは、シンプルで、作品のみが自然と流れてくるアプリであることです。

ビジュアル中心でも、アプリは前に出すぎない

Artl では、ビジュアル中心のUI/UXを取りながらも、アプリ自体が主張しすぎないことを重視しています。
作品を見るための場であって、アプリのデザインを見るための場ではないからです。
そのため、シンプルさと、存在感を出さないUIが大きなテーマになっています。

情報量を絞ると、自然に作品へ視線が集まる

情報量が多いと、ユーザーの注意は分散します。
逆に、余計な情報を削ると、作品に自然とフォーカスが向かいます。
Artl の鑑賞体験は、まさにその前提で作られています。
作品が流れてきたとき、まず作品が見えること。
それが鑑賞体験の質を決めます。

うまくいったポイントは投稿と閲覧の両方にある

現バージョンで手応えがあったポイントとしては、作品の投稿フローと閲覧画面での「鑑賞しました」機能が挙げられています。
見るときも出すときも、作品中心であることが崩れていない。
それがArtlのUI/UXの完成度を支えています。

まとめ

Artl のUI/UXは、シンプルに見えてかなり意図的です。
主張しすぎないこと、情報を絞ること、作品に自然と視線が集まること。
その積み重ねによって、アート鑑賞に向いた空間が作られています。


アート特化SNSアプリを開発した理由

はじめに

SNSが作品発表の場として使われることは珍しくありません。
一方で、既存のSNSは本当にアート作品に向いているのかという問いは、あまり深く考えられてこなかったように思います。
Artl は、その違和感から生まれたアート専用SNSです。

芸術作品にフォーカスした場所がなかった

このアプリを考えた出発点は、芸術作品そのものにフォーカスしたアプリが見当たらなかったことにあります。
既存のSNSでも作品投稿はできますが、そこで主役になるのは必ずしも作品ではありません。
写真の見栄えや情報の流れ、アルゴリズムの文脈に引っ張られ、本来の表現が別の評価軸に置き換わってしまうことがあります。

問題だったのは“映え”が入り込むこと

Artl が向き合った最初の大きな課題は、映え意識の排除でした。
一般的なSNSでは、どうしても注目を集めやすい見せ方が強くなります。
その結果、作品そのものより、反応を得やすい見せ方が優先されやすくなります。
それは、芸術作品を作る人にとって本質的な評価軸とは言いにくいものです。

目指したのは、作品自体が評価される環境

Artl の想定ユーザーは、芸術作品を作っている人と、本質的な作品を見たい人です。
つまり、発信側と鑑賞側のどちらも、作品そのものに向き合いたい人たちです。
このアプリが目指したのは、投稿された作品が余計な文脈に飲み込まれず、そのまま受け取られる環境でした。

まとめ

Artl は、アートをSNSに載せるためのアプリではなく、アートのためにSNSの形を考え直したアプリです。
映えや拡散の文脈ではなく、作品が作品として届くこと。
その環境を作ることが、このサービスの出発点でした。


作家が安心して発信できるSNSとは何か Artlの投稿体験を支える考え方

はじめに

アートSNSにおいて、作品の見え方と同じくらい重要なのが、投稿する側の体験です。
どれだけ鑑賞しやすくても、作家が使いにくければ、本当に届けたい作品は集まりません。
Artlでは、発信のしやすさもかなり丁寧に考えられています。

大切にしたのは、作家の想いをそのまま伝えられること

投稿体験で特に重視されたのは、作家の想いをそのまま伝えられることでした。
作品とキャプションを入力できる構成にしつつ、余計な操作は増やしていません。
作品そのものと、必要な言葉だけで発信できる状態を作っています。

投稿の負担になる要素を減らした

Artl では、キャプション(作品説明)を任意入力にし、作品に必要のないタグ付けなどのフローも排除しています。
これは、投稿するたびにアプリ都合の入力を求めないためです。
公開ページでも、作品のこだわりをそのまま投稿できるデザインであることが紹介されています。

サブ情報はマイページにまとめる

作品に直接関係しない情報は、マイページ側に集約しています。
作品の編集やプロフィール編集、フォロワー管理などを一元化しつつ、タイムライン上では作品が前に出るようにしています。
これにより、作品体験と管理体験がうまく分離されています。

まとめ

作家が安心して作品を発表できる状態とは、余計な制約なく、作品の意図を保ったまま出せることだと思います。
Artl は、作品の投稿フローそのものを軽くすることで、その安心感を支えています。
アート専用SNSとして、この“投稿のしやすさ”はとても大きな要素です。


なぜArtlはトリミングしないのか 作品をそのまま展示する設計の意味

はじめに

Artl の特徴として分かりやすいのが、作品をそのままの形で展示する設計です。
トリミングもせず、アプリに合わせて角を丸くするような加工もしません。
この判断には、かなりはっきりとした思想があります。

トリミングは、表現そのものへの介入になりうる

作家によっては、作品の構図や余白に強い意図を持っています。
そのため、トリミングされてしまうこと自体が表現の制約になりえます。
Artl では、その懸念を持つ作家も安心して展示できるよう、作品の形をそのまま保つ方針を採っています。
公開情報でも、作品のトリミングや角丸加工を行わず、そのまま投稿できるデザインであることが案内されています。

作品をアプリに合わせる作業を発生させない

一般的なSNSやアプリでは、表示比率やカード形状に合わせるために、画像側を調整する必要が出てくることがあります。
しかし、それはアート作品のための作業ではなく、アプリに合わせるための作業です。
Artl は、そのズレをなくそうとしています。

余白や比率も含めて作品として届ける

作品の余白や比率には意味があります。
そこをそのまま届けられることは、鑑賞者にとっても重要です。
単に絵柄や被写体だけを見るのではなく、作品全体の呼吸を感じられるからです。
Artl ならではの体験として挙げられている「生の作品に出会える」という感覚は、こうした設計から生まれています。

まとめ

Artl がトリミングしないのは、画像処理の都合ではなく、表現を守るためです。
作品をそのまま届けることは、作家にとっての安心感であり、鑑賞者にとっての誠実さでもあります。
アート専用SNSとして、この判断はかなり本質的だと思います。


Artlが目指すのは、芸術がもっと光を浴びる世界

はじめに

Artl は、作品ファーストの思想をかなり明確に形にしたアプリです。
一方で、現バージョンにはまだまだ改善ポイントもあります。
それは、作品の露出や回遊性に関する部分です。

難しかったのは、普通のSNSに寄ってしまうこと

開発で特に難しかったのは、芸術専門のSNSでありながら、中身が普通のSNSになりがちな点でした。
作品重視であり続けるには、用語や導線、反応の仕方まで細かく考え直す必要があります。
「世界観を出すための用語」が難所だったというのも、その象徴です。

次に必要なのは、作品がもっと前に出る仕組み

現バージョンを通して見えた改善ポイントとして、作品がもっと露出できる仕組みが挙げられています。
作品中心であることは守りつつ、より多くの作品に出会いやすくすることが課題です。

今回は作品が新着順に並んでいますが、これでは大量投稿によるタイムラインの独占など将来的に行うべき施作がまだまだ残っていると感じています。

回遊性を上げるUIが次の優先課題

今後アップデートするなら、最も優先したいのは回遊性を高めるUIです。
作品を壊さず、世界観も守りながら、より多くの作品へ自然に触れられるようにする。
そのバランスは簡単ではありませんが、Artl の成長には重要なテーマです。

まとめ

Artl が最終的に目指しているのは、芸術がもっと光を浴びる世界です。
SNSの文脈に合わせるのではなく、芸術に合わせてSNSの形を考える。
その姿勢は現バージョンにもはっきり表れています。
次のアップデートでは、その思想を保ったまま、もっと出会いが広がる場へ進化していくはずです。


「“いいね”ではなく“鑑賞しました” 」Artlが反応の仕方を変えた理由

はじめに

SNSにおいて、いいねはごく当たり前の機能です。
しかしArtl では、その当たり前を外しました。
代わりに採用したのが、「鑑賞しました」という表現です。

いいね集めは、作品制作の本質ではない

Artl が“いいね”を外した最大の理由は、いいね集めが作品制作活動の本質ではないと考えたからです。
いいねの数が可視化されると、人はどうしても反応を集めやすい方向を意識します。
それは芸術作品においても同じで、表現したいことより、反応されやすい見せ方が前に出てしまう危険があります。

“鑑賞したかどうか”に立ち返る

Artl では、作品への反応を「いいね」ではなく、「鑑賞しました」という行動として捉え直しました。
作品は軽く評価されるものではなく、まず鑑賞されるものだという前提です。
この再定義によって、反応の意味そのものが変わっています。
公開ページでも、作品作りの邪魔になるいいね機能を除外し、「鑑賞しました」を簡単に送受信できる機能を搭載したと案内されています。

作家にも鑑賞者にも意味がある

この機能は、作家にとっては「本当の自分の作品を観てもらえる」という体験につながります。
一方で、鑑賞者にとっても、いいねより押しやすい側面があります。
評価するより、鑑賞したことを示す方が、行為として自然だからです。
その押しやすさが、反応のハードルも下げています。

まとめ

Artl は、反応ボタンを変えただけではありません。
作品との向き合い方そのものを変えようとしています。
“いいね”ではなく“鑑賞しました”という小さな違いは、実はアートSNSとしての根本思想をよく表しています。


なぜ既存SNSはアート投稿に向いていないのか

はじめに

一般的なSNSは、多くの情報が流れ込むことを前提に設計されています。
それは便利さでもありますが、アート鑑賞という観点では別の問題を生みます。
Artl は、そのズレをかなり強く意識して設計されたアプリです。

異なるコンテンツが、作品への集中を奪ってしまう

一般的なSNSでは、作品以外の投稿、広告、話題のコンテンツなど、さまざまな情報が同じタイムライン上に並びます。
その中で作品を見ると、視線や意識は自然と他の情報にも引っ張られます。
アート鑑賞のように、一つの対象に没入したい体験とは、そもそもの前提が違っています。

情報量の多さは、鑑賞の空気そのものを壊してしまう

アート作品を見るときに大切なのは、作品に入り込めることです。
ところが情報量が多い空間では、その没入が続きません。
鑑賞中に別のコンテンツが入り込むことで、作品の前に立っている感覚が弱くなってしまいます。
Artl は、このアートに適していない空間を大きな課題として捉えていました。

作者側も本来の方向からずれやすくなる

既存SNSの問題は、鑑賞者側だけにあるわけではありません。
作者側も、見られるために別の観点で作品を作らざるを得ない空気に引っ張られます。
その結果、本当に表現したいことではなく、反応されやすいものへ寄っていく可能性があります。
これは作風の迷走にもつながりかねません。

まとめ

既存SNSがアートと相性が悪いのは、機能が足りないからではありません。
情報の流れ方そのものが、作品に集中する体験と噛み合いにくいからです。
Artl は、その構造自体を見直すことで、アートを見る空間を作ろうとしたアプリです。


まとめ

Artlの開発を通じて見えてきたのは、「専門特化SNS」の本質は「できること」を増やすことではなく、ターゲットユーザーにとって「邪魔なものを排除する」設計だということです。
micomiaでは、特定のコミュニティや業界向けのSNS・コミュニティアプリの開発をサポートしています。ユーザーが本当に必要としている体験を設計段階から一緒に考えます。

畑井駿佑

畑井駿佑

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

関連記事

植物専門SNS「でぃぐりーん(グリラボ)」開発記録|園芸初心者向けUI・AI機能・位置情報UXの設計思想
開発ストーリー

植物専門SNS「でぃぐりーん(グリラボ)」開発記録|園芸初心者向けUI・AI機能・位置情報UXの設計思想

植物初心者が「最初の一鉢」を買えない課題を解決するために開発された植物専門SNS「でぃぐりーん(グリラボ)」。園芸体験のハードルを下げるUI設計、AI機能の役割、位置情報を使った購入支援、MVPでのスピード開発——開発全体をまとめます。

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

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

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

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

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

医療×学術コミュニティアプリ「メディカルサークル」の開発記録。信頼感を作るデザインシステム、RevenueCatでサブスク課金をFirestoreと同期する実装、通報・ブロック機能による安全設計、管理画面を含むUI/UX設計まで全体をまとめます。

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

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

建設現場の外国人技能実習生向けに開発した日本語学習アプリ「ゲンゴー」。一般的な日本語教材では届きにくい建設用語への特化、多言語対応、JLPT対策の追加、毎日続くUI設計——開発背景と設計思想をまとめます。

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

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

野球指導の個別最適化をAIで実現した「NEOLAB AI」。記事や動画では届きにくかったコーチングをAIで変える開発背景、回答の信頼性をどう担保したか、なぜチャットUIを選んだか——スポーツAIアプリ開発の全体像を解説します。

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

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

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

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

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

システム会社にECサイトを発注するとき何を伝えればいいか分からない方へ。決済・配送・会員・管理画面・外部連携まで、開発前に確認すべき要件を10領域・全項目リスト化。AIと一緒に要件定義を進める際の入力テンプレートとしても使えます。

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

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

micomiaのパッケージアプリ開発サービスの注文方法を解説。ベースアプリ選択・追加機能・カラー・リリースオプションの選び方からお支払いまでをわかりやすくご紹介します。

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

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

アプリ開発費用の相場をSNS・マッチング・業務系アプリの種類別に解説。ノーコード開発やMVPアプローチで費用を抑える方法も紹介。

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

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

恋愛系マッチングアプリを作りたい方へ。開発相談を多数受けてきた開発会社の視点で、作る前に知っておくべき「アイデアの詰めが甘い」6つの失敗パターン、それでも作る価値がある条件、事前に詰めるべき3点を解説します。

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

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

省人化の読み方・意味から、業務効率化・自動化との違い、中小企業のバックオフィス業務で実現する具体的な4つのパターンと3ステップの進め方、ツール選定の罠までを一本で解説します。

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

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

SNSアプリの作り方を「パッケージ開発」と「オーダーメイド開発」で徹底比較。依頼前に整理すべき機能・予算・ターゲットのポイントと、micomiaの開発実績を交えてわかりやすく解説します。

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

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

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

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

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

システム受託開発の基本から、契約形態(請負・準委任)の違い、費用相場、依頼の流れ、失敗しないパートナー選びまで体系的に解説。発注を検討中のB2B担当者・経営者向けの実務ガイドです。

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

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

要件定義が曖昧でもアプリ開発会社に相談してOK。早い段階で専門家に相談するメリットやMVPアプローチの活用法を解説。micomiaではアイデア段階からのご相談を歓迎しています。

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

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

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

FlutterFlowとBubbleの違いとは?特徴・料金・選び方を徹底比較
ノーコード・FlutterFlow

FlutterFlowとBubbleの違いとは?特徴・料金・選び方を徹底比較

FlutterFlowとBubbleの違いを徹底比較。対応プラットフォーム・開発アプローチ・料金・パフォーマンスの観点で整理し、モバイルアプリにはFlutterFlow、WebアプリにはBubbleが向く理由など、プロジェクトに合った選び方を解説します。

開発後の保守運用で必要なこととは?コスト・体制・よくある課題を解説
開発用語集

開発後の保守運用で必要なこととは?コスト・体制・よくある課題を解説

開発後の保守運用で必要な業務内容・コスト目安・よくある課題を解説。障害対応やセキュリティ対策、属人化防止のポイントをmicomiaの経験をもとに紹介します。

FlutterFlowでStripe決済を導入する方法|設定手順・注意点をわかりやすく解説
ノーコード・FlutterFlow

FlutterFlowでStripe決済を導入する方法|設定手順・注意点をわかりやすく解説

FlutterFlowにStripe決済を導入する設定手順をわかりやすく解説します。Stripeの基本的な仕組みとFlutterFlowとの連携方法・実装上の注意点まで、決済機能を初めて組み込む開発者でも理解できるよう丁寧に紹介していきます。