技術職ではないオペレーション担当者がQoderを活用し、1日で自分用のiOS映画アプリを作りました。
ある晩、仕事から帰って映画を見ようと思い、動画アプリを次々と開きました。しかし、大量のおすすめを前にして、結局何を見たいのか分かりません。ソファで20分ほどスクロールした末、何も見ずに寝てしまいました。
私はQoderチームのオペレーション担当で、コードは書けません。それでも一つのアイデアが浮かびました。毎日いくつかの映画だけをおすすめしてくれ、上下にスワイプしながら今夜見る作品を決められるアプリを作れないだろうか。気に入らなければ飛ばし、気に入れば保存する。「あなたへのおすすめ」アルゴリズムもコミュニティもなく、毎日5本、ポスターを見て決めるだけのアプリです。
同僚に刺激され、ある日の昼食後、考えているだけではなく実際に試すことにしました。Qoderを開き、そのまま作業を始めました。
結果は自分でも驚くものでした。「Daily Movie」というiPhoneで動くiOSアプリを本当に完成させ、体験もまずまずのものになりました。ただし、想像していたほど順調ではありません。環境構築に2時間かかり、共有機能ではアプリが完全にクラッシュし、完成したUIは明らかに「AIが作ったような見た目」でした。後にSNSで、Vibe Codingで稼げると思うのは、コーヒーマシンを買えばカフェを開けると思うようなものだ、という比喩を見ました。まさにその通りです。感覚だけでAIに任せれば始めることはできますが、遠くまでは進めません。最後に不足を埋めてくれたのは、要件をより明確に伝えることと、専門的な標準をAgentへ読み込ませることでした。Qoderでも業界でも、これをSkillsと呼びます。詳しくは後ほど説明します。
Qoderを開き、左上からQuestモードを選択しました。
中に入ると、3つのテンプレートがあります。
作りたかったのはアプリのプロトタイプだったため、Prototype Demosを選びました。
この3つの分け方には意味があります。Prototype Demosは、「アイデアがあるので、まず動かして見てみたい」場合に向いています。曖昧な目標を説明し、Agentとすばやく探索する、構造化されたVibe Codingです。Code with Specは逆の道を取ります。作りたいものと受け入れ基準を先に明確に書き、AgentがSpecに従って実行します。一方は曖昧な状態から明確な状態へ、もう一方は明確な状態から完成へ進みます。今回はPrototype Demosから始めましたが、後にプロジェクトが迷走しないよう支えたのは、途中で身につけた「Spec型の考え方」でした。
Agentとの協働には陥りやすい罠があります。手順の一つひとつを細かく制御しようとするほど、かえって方向を外しやすくなります。よりよい方法は、道順ではなく目的地を説明することです。チームの開発者は、「意図を明確にすれば、Specは自然に育つ」と表現していました。そこで、「まずReact Nativeプロジェクトを作り、次にナビゲーションを設定する」とは言わず、「Daily Movie」の構想と必要な機能をまとめて伝えました。毎日5本をおすすめする、上下のスワイプで閲覧する、お気に入りへ保存できる、映画館のような雰囲気にする。意図が具体的なほど、Agentが最初に作るものの完成度は上がります。Qoder Quest 1.0はすぐに、QStudio内で実行する方法と、独立したReact Nativeプロジェクトを生成する方法の2案を示しました。迷わず後者を選びました。
まもなくQuestがアプリのプロトタイプを生成し、プロジェクトの場所を教えてくれました。
次の問題は、実行環境をどう構築するかです。
Questへ次々と質問しました。この作業には約2時間かかり、主に2か所で詰まりました。Node.jsのバージョンが合わず依存関係をインストールできなかったことと、iOSシミュレーターを別途ダウンロードする必要があり、Xcodeの操作がまったく理解できなかったことです。知らないボタンとメニューだらけの巨大なXcode画面を見て、コンピューターを閉じたくなったこともありました。それでも、エラーが起きるたびにスクリーンショットをQoderへ渡すと、原因を特定し、解決策を示してくれました。
皮肉なことに、「コードを書く」作業はQoderが数分で終え、本当に苦労したのはコードの外側でした。iOSシミュレーターのインストール、Xcodeの分かりにくい設定などです。Agentはコードを書けますが、環境やツールの問題についてQuestができるのは提案までで、最終判断は自分で行う必要があります。
最後に、Expo Goを使ってiOSシミュレーター上で「Daily Movie」を起動できました。
初めてアプリが動いた瞬間、数秒間固まった後、スクリーンショットを撮って仕事のグループチャットへ送りました。同僚が「これを作ったの？」と聞くので、「厳密にはQuestが作ったけれど、アイデアは私です」と答えました。まだモックデータでしたが、メイン画面も詳細画面もあり、全体の骨格はすでにアプリらしくなっていました。
仮データはあくまで仮データなので、実際の映画情報へ置き換える必要があります。しかし、データはどこから取得すればよいのでしょうか。
Qoderへ適切なデータソースを尋ねると、無料の映画データAPIを提供するTMDb（The Movie Database）をすすめられました。世界中の数百万本の映画情報を取得でき、登録後すぐに利用できるため、個人プロジェクトに適しています。手順に沿ってアカウントを登録し、開発者アクセスを申請しました。API Keyを取得してQoderへ連携を依頼すると、実データをスムーズに取り込めました。
アプリを開いて本物の映画ポスターが次々と表示された瞬間、一気に「生きた」感じがしました。
データの次はUI設計です。
Qoderへ、暗い映画館のような雰囲気にし、映画カードを大きくしてポスターを主役にしたいと伝えました。このアプリはポスターを見て選ぶため、ポスターがよく見えなければ体験そのものが成り立ちません。カードをタップすると、評価、監督、出演者、あらすじなどの完全な情報を表示し、お気に入りボタンとTMDbページへのリンクも置きます。
UIは3～4回調整しました。
SkillはAIへ具体的なデザイン標準を与えます。指示が正確なほど、出力は安定します。
とはいえ、そのときは深く考えず、「Skillを入れたら結果がずっとよくなった」と感じただけでした。Skillが通常の文書と違うのは、一度書いて放置するものではなく、AIが作業のたびに読む「生きた標準」だという点です。使用するたびに適用され、標準が形骸化しません。
違いは明らかでした。導入前のUIは「使える」もの、導入後は「使いたい」ものです。カードの角丸、フォントの階層、余白のリズムが自然になり、画一的なAIデザインではなくなりました。
こうしてQuestが骨格と実装を担当し、Skillsが品質を管理しました。最終結果は本当に予想以上でした。
要件は単純です。「好きな映画をお気に入りへ保存し、次にアプリを開いたときも見られるようにしたい。お気に入りは独立したページにし、保存した映画をすべて表示する。」
QuestはAsyncStorageという仕組みを使いました。簡単に言えば、スマートフォン内の「小さな倉庫」です。お気に入りの映画データをそこへ保存するため、アプリを閉じて再度開いても残り、オフラインでも見られます。この機能は問題なく完成しました。
ここでは大きな問題に直面しました。最初は、「映画ポスターとQRコードを使ったきれいな共有カードを作り、画像として保存して共有できるようにしたい」と伝えました。Qoderは、react-native-view-shotでスクリーンショットを作り、expo-sharingで共有する方法をすぐに実装しました。
しかし、インストールするとアプリが完全にクラッシュしました。タップした瞬間に画面が真っ暗になり、ホーム画面へ戻される、ためらいのないクラッシュです。
エラーをQoderへ渡すと、これらの機能が依存するネイティブモジュールはExpo Go環境では動作せず、独立版のアプリをビルドする必要があると説明されました。独立版のビルドにはApple Developerアカウントや署名証明書などが必要で、私には複雑すぎました。
諦めず、代替案を2～3種類試しましたが、それぞれに問題がありました。2時間以上試した後、最初から欲しかった共有カードを断念するのは悔しかったものの、要件を簡略化し、プレーンテキストとReact Native標準の共有コンポーネントへ切り替えました。
最終的な共有内容は次のとおりです。
華やかなカードではありませんが、安定して使えます。
ここで得た最大の教訓は、まず動くバージョンを作り、複雑な機能は後から改善することです。
AIは「標準的な道」では確かに効率的ですが、Expo Goのネイティブモジュール制限やApple Developerの証明書体系といったプラットフォーム境界にぶつかると、問題の場所は教えられても、何を選ぶかまでは決められません。最後に私を救ったのは「削る」ことでした。画像の共有カードを削り、プレーンテキストに変え、重要な機能を磨く時間を確保しました。削るときは惜しく感じましたが、振り返ると正しい判断でした。そうしなければ、ずっとそこで止まっていたでしょう。
基本機能の完成後、Questとさらに細部を磨きました。
QuestはSkillのルールに沿って、一連の最適化を行いました。ポスター画像は効率的な読み込み方式へ変わり、まずぼかした色面を表示してから高解像度画像へ滑らかに切り替わるため、白い画面のちらつきがなくなりました。大きな背景画像は見た目の品質を保ちながら数分の一まで圧縮されました。スクロール一覧の内部ロジックも整理され、画面外のコンテンツは自動的にメモリから解放されるため、スクロールを続けても重くなりません。仕組みの詳細は分かりませんが、実機でのスワイプは明らかに滑らかになり、ポスターもほぼ瞬時に表示されました。
SNSでは似た議論を多く見かけます。Vibe Codingはプロジェクトが大きくなると迷走し、Agent自身も何を変更したのか説明できなくなるため、すぐ限界に達するという意見があります。一方、SDD（Spec-Driven Development）こそ最善で、要件とアーキテクチャ文書を明確に書いてからAgentを動かすべきだという意見もあります。振り返ると、まさに私の道のりでした。最初は感覚だけでAIに任せてすばやく進みましたが、環境構築、プラットフォーム制限、デザイン品質で詰まりました。その後、要件を具体的に説明し、SkillsをAgentへ読み込ませることで、ようやく期待する結果が得られました。
おもしろい話もあります。プロダクトマネージャーは、AIがあればデザイナーのモックを待たなくてよいと言い、デザイナーは開発者の実装を待たなくてよいと言い、開発者はPMの要件を待たなくてよいと言います。ではオペレーション担当の私は、3人すべてを飛び越えたのでしょうか。ユーザーにニーズとフィードバックがあることだけは変わりません。
「Agentがコードを書けるなら、計画も更新できる。そのまま任せればよい」という言葉にも共感しました。Skillsはさらに先へ進み、AgentがよいSOPを推測する必要さえなく、標準を読み、そのとおりに実行できます。
今は、Vibe Codingは優れた出発点ですが、それだけで最後までは進めないと考えています。最初からCode with Specを使い、10分かけて要件と受け入れ基準を書いていれば、共有機能の問題には遭遇しなかったかもしれません。一方で、最初の「とにかく試してみよう」という衝動がなければ、今も考えているだけだったでしょう。どちらも必要で、順番と比率の問題です。
Karpathyは、将来のソフトウェアは高度にパーソナライズされ、誰もが必要なときにAIへアプリを生成させ、使い終えたら捨て、App Storeから他人向けの汎用製品をダウンロードしなくなると述べています。これを「bespoke software」と呼び、現在のソフトウェアをレンガで造った城、将来のソフトウェアを必要に応じて煮込み、飲み終えたらなくなるスープに例えています。
それを見た瞬間、「Daily Movie」のことだと思いました。毎日5本、上下にスワイプし、ポスターで決める。このように具体的なニーズに完全に合うアプリをApp Storeで誰かが作ることはありません。しかし私は1日で作り、自分だけが使うものでも、大規模で多機能な映画アプリより自分に合っています。
とはいえ、完成後に振り返ると皮肉な点があります。最も時間を使ったのは「作る」ことではなく、「iOSアプリとして動かす」ことでした。Qoderはすぐにコードを書き、残りの時間はXcode、シミュレーター、Expo Goのネイティブモジュール制限、Apple Developer証明書と格闘しました。2026年になっても、99%のサービスにはAIに適したインターフェースがなく、ユーザーが手作業でWeb画面を操作します。「私はコンピューターなの？」という気持ちは、Xcodeを見つめていた私そのものです。
Karpathyが言うように、将来のソフトウェアがアプリもApp Storeも署名証明書も不要で、必要なときにコードを生成し、使い終えたら消えるものになれば、この記事の失敗の半分は存在しません。しかし今は移行期です。AIがコードを書く能力はすでに到来しましたが、コードを実行する基盤は古いままです。それでも、具体的なニーズがあり、試行錯誤を厭わない人にとって、参入障壁は以前よりはるかに低く、急速に下がっています。
ここで「Daily Movie」の開発は一つの節目を迎えました。実際のiPhoneへExpo Goをインストールし、コードをスキャンして起動すると、スワイプも操作も滑らかで、予想以上の体験でした。
最終版の体験をまとめると、次のとおりです。
Qoderを開いてから、iPhoneで滑らかに動くアプリを作るまで、私は一行もコードを書きませんでした。
作業中、「AIに引きずられている」という不安を感じなかったことには驚きました。Questモードの進め方が関係しているのでしょう。まず作りたいものを確認し、不明な点は質問カードで意図を明確にし、確認後に自律実行します。
Qoder Questがアイデアを動くコードへ変え、Skillsが私の知らないデザインと性能の品質を支えました。Skillsがなければ、アプリは今も一目で「AI製」と分かる水準だったでしょう。
環境構築に2時間かかり、共有機能では要件を削るなど、多くの問題にも直面しました。しかし、振り返ると原因はほぼ同じです。本当に欲しいものを十分に考えていなかったか、現実の制約を過小評価していました。解決策も特別ではありません。いったん止まり、考え直し、それからAgentに作業させるだけです。
「Daily Movie」は完璧ではありませんが、私が作りました（実際にはQuestが作りましたが、アイデアは私です）。完成して得た最大の気づきは、「自分にもできた」ことではなく、Agentとの協働ではコードを書けるかどうかはそれほど重要ではなく、欲しいものを明確に説明できるかが重要だということです。
長い間作りたかったアプリがあるなら、「準備ができる」まで待たないでください。Qoderを開き、Questモードへ切り替え、アイデアを言葉にして、まず動くバージョンから始めます。途中で必ず壁に当たります。そのときは止まり、本当に欲しいものは何か、今は何を諦められるかを考えてください。
技術職ではないオペレーション担当者が、自分の好みにぴったり合うアプリを作りました。考えてみると、とてもおもしろいことです。
アイデアから動くアプリへ
01. Questモードでアプリの骨格を作る
Qoderを開き、左上からQuestモードを選択しました。
- Spec-Driven（Code with Spec）：要件と計画が明確な開発タスク向け
- Prototype Demos：アイデアをすばやくプレビュー可能なプロトタイプにする場合向け
- Create Tools：ツール型アプリケーションの構築向け
02. 実際の映画データを接続する
仮データはあくまで仮データなので、実際の映画情報へ置き換える必要があります。しかし、データはどこから取得すればよいのでしょうか。
Qoderへ適切なデータソースを尋ねると、無料の映画データAPIを提供するTMDb（The Movie Database）をすすめられました。世界中の数百万本の映画情報を取得でき、登録後すぐに利用できるため、個人プロジェクトに適しています。手順に沿ってアカウントを登録し、開発者アクセスを申請しました。API Keyを取得してQoderへ連携を依頼すると、実データをスムーズに取り込めました。
アプリを開いて本物の映画ポスターが次々と表示された瞬間、一気に「生きた」感じがしました。
03. Skillsで「AIっぽさ」をなくす
データの次はUI設計です。
Qoderへ、暗い映画館のような雰囲気にし、映画カードを大きくしてポスターを主役にしたいと伝えました。このアプリはポスターを見て選ぶため、ポスターがよく見えなければ体験そのものが成り立ちません。カードをタップすると、評価、監督、出演者、あらすじなどの完全な情報を表示し、お気に入りボタンとTMDbページへのリンクも置きます。
UIは3～4回調整しました。
- 最初のカードは小さく、ポスターが見づらい → 「カードを高くし、画面の高さの3分の2を使う」
- 評価の数字が小さい → 「評価を一段大きくし、太字にする」
- 下部のテキストとポスターの境目が急すぎる → 「ポスター下部へ透明から黒へのグラデーションを追加する」
frontend-design というSkillをインストールし、その中のデザイン標準に従ってUIを最適化させました。
一つコツがあります。Skillをインストールした後も、指示は具体的に書いてください。
04. お気に入り機能
要件は単純です。「好きな映画をお気に入りへ保存し、次にアプリを開いたときも見られるようにしたい。お気に入りは独立したページにし、保存した映画をすべて表示する。」
QuestはAsyncStorageという仕組みを使いました。簡単に言えば、スマートフォン内の「小さな倉庫」です。お気に入りの映画データをそこへ保存するため、アプリを閉じて再度開いても残り、オフラインでも見られます。この機能は問題なく完成しました。
05. 共有機能での失敗
ここでは大きな問題に直面しました。最初は、「映画ポスターとQRコードを使ったきれいな共有カードを作り、画像として保存して共有できるようにしたい」と伝えました。Qoderは、react-native-view-shotでスクリーンショットを作り、expo-sharingで共有する方法をすぐに実装しました。
しかし、インストールするとアプリが完全にクラッシュしました。タップした瞬間に画面が真っ暗になり、ホーム画面へ戻される、ためらいのないクラッシュです。
エラーをQoderへ渡すと、これらの機能が依存するネイティブモジュールはExpo Go環境では動作せず、独立版のアプリをビルドする必要があると説明されました。独立版のビルドにはApple Developerアカウントや署名証明書などが必要で、私には複雑すぎました。
諦めず、代替案を2～3種類試しましたが、それぞれに問題がありました。2時間以上試した後、最初から欲しかった共有カードを断念するのは悔しかったものの、要件を簡略化し、プレーンテキストとReact Native標準の共有コンポーネントへ切り替えました。
最終的な共有内容は次のとおりです。
06. 細部の改善と性能最適化
基本機能の完成後、Questとさらに細部を磨きました。
- 「興味なし」ボタン：今日の5本に見たい映画がなければ、「興味なし」を押して別の作品へ入れ替えます。ただし1日3回までで、使い切ると「明日また来てください」と表示します。無制限に変えられると、推薦はランダムシャッフルになり、「毎日の厳選」という儀式性が失われます。選択肢を適度に制限すると、かえって決断しやすくなります。選択疲れには、少ない方がよい場合があります。
- 毎日の更新ロジック：5本の映画はUTC+8、つまり北京時間の午前0時に更新します。このバグは自分で使って発見しました。午前1時に開いても前日の一覧が表示され、アルゴリズムが壊れたと思いましたが、調べるとタイムゾーンの問題でした。ここではオペレーション担当としての感覚が役立ちました。
- 触覚フィードバック：スワイプ、ボタン操作、お気に入り登録の際に、スマートフォンが軽く振動します。追加後は体験が明らかによくなり、ネイティブiPhoneアプリに近い操作感になりました。
frontend-design の導入を思い出し、Skillsから vercel-react-native-skills を見つけました。VercelチームによるReact NativeとExpoのベストプラクティス集で、モバイル性能の問題を解決するためのSkillです。
インストール後、Qoderへ「vercel-react-native-skills の標準を参照して、映画カード一覧のスワイプ性能とポスター画像の読み込みを最適化してください」と伝えました。
frontend-design はAIテンプレートらしさをなくし、vercel-react-native-skills はスワイプと読み込みを指の動きへ追従させました。2つのSkillsにより、アプリの品質は本当に一段上がりました。
07. 完成後に考えたこと
SNSでは似た議論を多く見かけます。Vibe Codingはプロジェクトが大きくなると迷走し、Agent自身も何を変更したのか説明できなくなるため、すぐ限界に達するという意見があります。一方、SDD（Spec-Driven Development）こそ最善で、要件とアーキテクチャ文書を明確に書いてからAgentを動かすべきだという意見もあります。振り返ると、まさに私の道のりでした。最初は感覚だけでAIに任せてすばやく進みましたが、環境構築、プラットフォーム制限、デザイン品質で詰まりました。その後、要件を具体的に説明し、SkillsをAgentへ読み込ませることで、ようやく期待する結果が得られました。
おもしろい話もあります。プロダクトマネージャーは、AIがあればデザイナーのモックを待たなくてよいと言い、デザイナーは開発者の実装を待たなくてよいと言い、開発者はPMの要件を待たなくてよいと言います。ではオペレーション担当の私は、3人すべてを飛び越えたのでしょうか。ユーザーにニーズとフィードバックがあることだけは変わりません。
「Agentがコードを書けるなら、計画も更新できる。そのまま任せればよい」という言葉にも共感しました。Skillsはさらに先へ進み、AgentがよいSOPを推測する必要さえなく、標準を読み、そのとおりに実行できます。
今は、Vibe Codingは優れた出発点ですが、それだけで最後までは進めないと考えています。最初からCode with Specを使い、10分かけて要件と受け入れ基準を書いていれば、共有機能の問題には遭遇しなかったかもしれません。一方で、最初の「とにかく試してみよう」という衝動がなければ、今も考えているだけだったでしょう。どちらも必要で、順番と比率の問題です。
Karpathyは、将来のソフトウェアは高度にパーソナライズされ、誰もが必要なときにAIへアプリを生成させ、使い終えたら捨て、App Storeから他人向けの汎用製品をダウンロードしなくなると述べています。これを「bespoke software」と呼び、現在のソフトウェアをレンガで造った城、将来のソフトウェアを必要に応じて煮込み、飲み終えたらなくなるスープに例えています。
08. 最終成果
ここで「Daily Movie」の開発は一つの節目を迎えました。実際のiPhoneへExpo Goをインストールし、コードをスキャンして起動すると、スワイプも操作も滑らかで、予想以上の体験でした。
最終版の体験をまとめると、次のとおりです。
- 登録やログインなしですぐに利用可能
- TMDbで評価6以上の映画を毎日5本厳選し、上下のスワイプで閲覧
- タップして詳細を表示し、お気に入り登録と共有をワンタップで実行
- 触覚フィードバックを追加し、ネイティブに近い操作感を実現
09. AIでアプリを作りたい人への助言
- 最初に適切なテンプレートを選ぶ：アイデアの検証や見せられるデモの作成にはPrototype Demos、明確な機能要件と技術計画がある場合はCode with Specを選びます。
- 道順ではなく目的地を説明する：「映画推薦アプリを作る」より、「毎日5本の映画をおすすめし、上下のスワイプで閲覧し、お気に入り登録できるiOSアプリを作る」と伝えます。「何が欲しいか」を明確にし、「どう作るか」はAIへ任せると、最初の完成度が上がります。
- エラーが出ても慌てない：スクリーンショットを撮るか、エラーメッセージをコピーしてQoderへ渡します。ほとんどの環境構築問題は特定できます。
- Skillsをいくつか導入する：フロントエンド画面なら
frontend-design、コンテンツ系ならseo-contentを使います。導入前後の違いは明らかで、早く入れるほど早く効果を得られます。skills.shで適したものを探してください。 - Vibeで始め、Specで仕上げる：Prototype Demosでアイデアをすばやく検証して構いません。ただしデモ以上のものを作るなら、Code with Specから始めることを検討してください。欲しい機能、不要な機能、受け入れ基準を10分かけて書く方が、後で2時間問題にはまるより有効です。意図が明確なほど、AIが方向を外す可能性は下がります。