2019年の春先、吉祥寺駅の上空に光の輪が見えた瞬間がありました。物理的に何が起きていたかは今も分かりませんが、その日から私の中で「視覚表現は意味を運ぶ媒体だ」という確信が静かに固まっていきました。それ以降、アート作品の構図・余白・色彩のどれもが、ただの装飾ではなく一つの言葉になりました。
その感覚を持ち続けたまま、ここ数週間、Rorkにアート系アプリの試作を任せてきました。アーティスト・クリエイターの廣川政樹です。国際芸術賞を17冠と、2014年から続けている個人アプリ開発(累計5,000万ダウンロード超)の両方を行き来している立場から、今回の試作で見えたRorkの強みと弱みを率直にお伝えします。「アート系のアプリにRorkは耐えられるのか」という問いを、自分の実作業で検証した記録として読んでいただければ嬉しいです。
何を試作したか — 「祈りの作品集」アプリ
試作の題材は、私のアート作品テーマである「日本特有の祈りを背景に、集団心理と認知世界の構造、根源意識を探る」をそのままアプリ化したものです。具体的には次の3つの体験を1本のアプリにまとめる構想にしました。
- 作品ギャラリー(縦スクロール・ピンチズーム・余白を活かしたレイアウト)
- 作品ごとの音声朗読(私自身の声で制作背景を語る・stand.fmからの音声を組み込む想定)
- 「祈りのモード」(時刻と気象に応じて画面の色温度と余白量が静かに変化する)
このうち、特に3つ目の「祈りのモード」は、UIフレームワークの設計が浅いと表現しきれません。アート系アプリでもっとも譲れないのは、ピクセル単位の余白と、色温度の微妙な転調です。Rorkがこの領域にどこまで応えるかが、今回の検証の核心でした。
最初の30分で出てきたものの率直な評価
プロンプトに上記の3つの体験を箇条書きで渡し、生成を待ちました。30分ほどで出てきた最初のアプリは、構造としては想像以上に整っていました。
- React Native(Expo)ベースのプロジェクトとして一式そろっていた
- 作品ギャラリーがFlatListで実装され、ピンチズームのライブラリ(react-native-image-zoom-viewer相当)が組み込まれていた
- 朗読音声のスタブ画面があり、再生・一時停止・シークが動く状態だった
- 「祈りのモード」用のテーマ切替ロジックがContext API経由で組まれていた
これは正直、個人開発を12年続けてきた感覚から言って、初期構造としてかなり良い水準です。ただし、ここからが本題でした。Rorkの生成物は「アプリの骨格」としては及第点でしたが、「アート作品としての細部」に踏み込むと、人間が手を入れる余白がはっきり残っていました。
// Rorkが最初に生成したThemeProviderの抜粋(素のままだとアート用途には浅い)
const ThemeContext = createContext({ mode: "day", setMode: (_: string) => {} });
export function ThemeProvider({ children }: { children: ReactNode }) {
const [mode, setMode] = useState<"day" | "dusk" | "night">("day");
// ❌ 色温度の変化が3段階のスナップでしかない
const palette = {
day: { bg: "#FFFFFF", fg: "#111111" },
dusk: { bg: "#F2E8D5", fg: "#3A2B1B" },
night:{ bg: "#0E0F14", fg: "#E8E4D8" },
}[mode];
return (
<ThemeContext.Provider value={{ mode, setMode }}>
<View style={{ flex: 1, backgroundColor: palette.bg }}>{children}</View>
</ThemeContext.Provider>
);
}私が望んでいたのは、時刻に応じて色温度が連続的に滑らかに転調していく挙動です。3段階のスナップ切替では、そもそもアートとしての所作になりません。ここを書き換えていく作業が、Rorkとの対話で最も時間を要した部分でした。
アート文脈をプロンプトでどこまで届けられるか
最初のプロンプトでは「祈りのモード」とだけ書いていたため、Rorkは安全な解釈として3段階の切替を選んだのだと思います。そこで2回目のプロンプトでは、自分の中の言語をできるだけ翻訳して伝え直しました。
「祈りのモード」は、時刻と気象データから連続的に色温度・彩度・余白量を補間します。スナップ切替ではなく、4分ごとに静かに変化します。日没前後の30分は彩度を意図的に高め、深夜0時から3時は余白を画面の20%まで広げる。
この具体性で投げ直すと、Rorkは補間ロジックを書いてくれました。色温度はrequestAnimationFrameでHSLを補間するコードに、余白はuseEffectで時刻に応じてpaddingを更新するコードに、それぞれ落ちました。
// 改善後: 時刻に応じて連続的に色温度を補間
import { useEffect, useState } from "react";
function interpolateHSL(t: number) {
// 0時=深い藍 / 6時=朝霞色 / 12時=純白寄り / 18時=琥珀 / 24時=深い藍へ戻る
const phases = [
{ h: 220, s: 30, l: 8 },
{ h: 30, s: 25, l: 92 },
{ h: 0, s: 0, l: 98 },
{ h: 28, s: 60, l: 70 },
{ h: 220, s: 30, l: 8 },
];
const idx = Math.floor(t / 6);
const local = (t % 6) / 6;
const a = phases[idx], b = phases[idx + 1];
const h = a.h + (b.h - a.h) * local;
const s = a.s + (b.s - a.s) * local;
const l = a.l + (b.l - a.l) * local;
return `hsl(${h}, ${s}%, ${l}%)`;
}
export function usePrayerPalette() {
const [bg, setBg] = useState(interpolateHSL(new Date().getHours()));
useEffect(() => {
const id = setInterval(() => {
const now = new Date();
const t = now.getHours() + now.getMinutes() / 60;
setBg(interpolateHSL(t));
}, 4 * 60 * 1000); // 4分ごとに静かに更新
return () => clearInterval(id);
}, []);
return bg;
}ここで気づいたことが、今回の検証で最大の発見でした。Rorkは「アート文脈を持つ言葉」を曖昧にしか受け取らない代わりに、数値や時間を含む具体的な指示には驚くほど忠実に応えるのです。アーティスト側で自分の感覚を「数式・時間軸・割合」に翻訳して渡せば、Rorkは想像以上に細部まで応えてくれます。逆に「もっと余白を活かして」「もっと祈りらしく」のような形容詞だけのプロンプトでは、無難な解釈で止まる傾向がありました。
累計5,000万DLの感覚から見た「実用に耐えるか」
ここからは個人アプリ開発12年・累計5,000万ダウンロード超の運用視点で見ます。アート系アプリは、見栄えだけで判断してはいけません。日々動かして、ストアに出して、ユーザーの手元で問題なく動き続けるかを問う必要があります。
- 起動時間: Rork生成のままでは初回起動が約2.6秒。FlatListの初期レンダリング件数を絞り、画像をexpo-imageに置き換えて1.4秒まで短縮
- メモリ使用量: 高解像度作品を100点表示する設計なので、初期実装ではiPhone SE(第2世代)でクラッシュ。
recyclerlistview系への置き換えで安定 - アクセシビリティ: ピンチズーム時のVoiceOver読み上げが最初は機能していなかったため、
accessibilityLabelとaccessibilityHintを作品ごとに付与 - ストア審査: アプリ内に音声朗読を含めるため、プライバシーマニフェストと録音目的の記述が必要だった
これらは、Rorkが一発で解決してくれる類の問題ではありません。私が壁紙アプリや癒し系アプリで何度もやってきた手作業が、依然として必要でした。AdMobの収益が月150万円を超えていた時期に何度も学んだことですが、ストアで生き残るアプリは「最初の構造」だけでは作れず、「日々の小さな手当て」の積み重ねでしか作れません。Rorkはその出発点を3週間ぶん早めてくれましたが、ゴールまで運んでくれるわけではありませんでした。
関連する観点については、Rorkを軸にしたアプリ収益化の現実的比較 と アーティスト・クリエイター向けRorkアプリ開発ガイド でも整理しています。あわせて読むと、今回のレビューの背景がより掴みやすいかもしれません。
アート系アプリの試作にRorkを使うべき5つの場面
3週間の試作を経て、自分なりに「Rorkに任せたほうがよい場面」と「人間が握ったほうがよい場面」が見えてきました。アート系アプリに限定して、判断基準を共有します。
- ✅ 構造を立ち上げる初期24時間: ナビゲーション、画面遷移、状態管理の素地はRorkに任せて構わない
- ✅ 標準的なUI部品の実装: ボタン、フォーム、シート、リストなどの土台はRorkで十分
- ✅ アクセシビリティの素地づくり: ラベル付けやコントラスト比は最初の網としてRorkに掛けてもらうとよい
- ❌ 余白・色温度・タイポグラフィの最終調整: ここは作家本人が握る領域。プロンプトで「数値」に翻訳して渡しても、最終確認は手作業
- ❌ 静的アセットの選定: 写真・音声・フォントの選定は作家の感性領域。AIに任せてはいけない
私は1997年、16歳でインターネットに出会ったとき、技術と表現の境界が溶けていく感覚を持ちました。Rorkも、その延長にある道具だと感じています。便利だが、便利さに任せきると、その人の作品は「誰にでも作れるもの」に近づいてしまいます。便利な部分は遠慮なく任せ、作家の輪郭を決める部分だけは自分の手で磨く。この切り分けを意識するだけで、Rorkとの付き合い方は確実に変わります。
まずはあなたの作品の中の「数値で語れる部分」を1つ書き出してみる
もしあなたが作家として、あるいは個人開発者としてアート系アプリを作りたい場合、最初の一歩としておすすめしたいのは「自分の作品の中で、数値や時間で語れる部分を1つだけ書き出す」ことです。色温度なら何度から何度まで、余白なら画面比率の何%、リズムなら何秒間隔。たった1行でいいので、自分の感覚を数値に翻訳してみてください。それが揃った瞬間、Rorkは想像以上の応答を返してくれます。
最後までお読みいただき、ありがとうございました。今回の試作で見えたものは、私自身もまだ整理の途中です。共に学んでいけたら嬉しいです。