記事の概要
- 誰が・何をした：Fotógrafo Nobutsugu Sugiyama、2011La aplicación para iPhone “COSPLAY SHOWCASE” ocupó el segundo lugar en la App Store en 2018.、Revivido como una aplicación web usando IA。
- En conclusión,：AIは「丸投げ」では動かない。しかし「要件を構造化して渡す」技術さえあれば、過去の資産は確実に現代へ繋がる。
- この記事で得られるもの：実際のAI共同開発で判明した「AIが失敗するパターン」と「AIを正しく動かす5つのルール」。
Introducción：あなたにも「眠っている資産」はないか
古いアプリ、動かなくなったWebサービス、デジタルデータ化されていない作品群——。
「あの頃作ったもの、今の技術でもう一度やりたい」と思ったことがある人は多いはずだ。しかし現実には、「技術的な壁」と「時間とコスト」の前で、ほとんどのプロジェクトは諦められる。
私は2026年のゴールデンウィーク、その壁にAIと一緒に正面からぶつかった。
15年前にApp Storeで売上第2位を記録した「COSPLAY SHOWCASE」というiPhoneアプリを、WEBアプリとして復活させるプロジェクトだ。完全なエンジニアではなく、「多少コーディングができる写真家」という立場で。
「AIがあれば数時間で完成する」——そう思っていた時期が私にもあった。
現実は違った。
挑戦の背景：IPA/APKを解析した日
まず手元にあったのは「バイナリ」だけだった
今回のプロジェクトで私が用意できたのは、以下のものだけだった。
- iOS版のIPAファイル（ iPad/iPhoneアプリの「中身」が詰まった、インストール用のパッケージ）
- Android版のAPKファイル（Androidアプリの「正体」である、インストール用のファイル一式）
- 当時のJPEG画像群とUIスクリーンショット
- アプリ紹介ページのテキスト
- 自分自身の「制作者の記憶」
最大の問題は、完全なソースコードが残っていなかったことだ。
つまりプロジェクトの出発点は、最初からリバースエンジニアリング前提だった。
Claudeに解析させると何が起きるか
最初の試みは単純だった。
「ClaudeにIPA/APKを読ませれば、ある程度自動でReact化できるのでは？」
現在の生成AIはReact生成、TypeScript生成、Tailwind CSS構築、UIコンポーネント生成、エラー修正修正——この領域でかなり強い。だから「古いアプリをAIでWeb化する」という発想は、現実的に見えた。
Reaccionar:（「部品」を組み合わせて、画面を作る仕組み）CSS de viento de cola:（決められた「単語」を並べるだけで、デザインができる道具）
しかし実際に手を動かすと、状況はまったく違った。
IPA内部では、リソース構造、画像ファイル、一部の設定情報、バンドル構成は確認できた。pero、肝心のObjective-C時代のコンパイル済みコードは、そのままでは読めない。ClaudeはIPAを解析し「構造っぽいもの」は認識する。peroUI遷移、gesture設計（指の動きに対する「反応」の設計）、状態管理、アニメーションの意図es、ほぼ復元できなかった。
Android APK側はXMLレイアウトやdrawable（画像や図形など、画面に表示する「素材データ」の総称）が比較的残っており、多少読みやすかった。しかしここでも本質的な問題が起きる——AIは「存在しているもの」は読める。pero「なぜそう設計したか」は理解できない。
なぜ画像がこの順番なのか。なぜこのタイミングで切り替えるのか。なぜこのスワイプ速度なのか。これらの設計意図は、バイナリには記録されていない。En otras palabrasUI/UXの思想部分は、AIには復元されない。
es、最初の大きな壁だった。
直面した絶望：3つの「地獄」
プロジェクトが進むにつれ、具体的なトラブルが次々と現れた。
地獄1：UI構造崩壊
最初のプロンプトはこんなものだった。
「このIPA/APK構造から、Reaccionar + Tailwind CSSで同等UIを再構築してください」
結果は、かなり壊れていた。
AIは画面を推測で組み始める。しかしhierarchy（階層）、state構造（データの管理ルール）、component分割（部品単位への切り分け）が実アプリと違う。「それっぽいが別物」が生成される。Tailwind CSS化においても、utility過剰化、responsive崩壊、z-index事故、mobile overflowが頻発した。特に多かったのが「PCでは正常、スマホで崩壊」というパターンだった。
utility過剰化：（デザイン命令が多すぎて、コードが「呪文」になること）responsive崩壊：（画面サイズを変えると、見た目が「ぐちゃぐちゃ」になること）z-index事故：（パーツの重なり順が狂い、ボタンが「埋もれて」押せなくなること）mobile overflow：（画面の横幅をはみ出し、左右に「ガタガタ」揺れること）
地獄2：スワイプ挙動の破綻
特に深刻だったのがこれだ。
COSPLAY SHOWCASEは「写真をフリック回転する」ことが核心だった。しかしAIは慣性スクロール（inertial scroll）、ドラッグ状態の管理、touch cancel処理、モバイルgestureの実装をかなり間違える。
touch cancel；（「触っていた指が、画面から外れたり無効になったりした状態」）
como resultado、
- 引っかかる
- 飛ぶ
- 逆方向へ動く
- モバイルだけ壊れる
が頻発した。特にモバイルSafariでは、touch-action、overflow、passive event、image renderingの周辺でかなり詰まった。
touch-action：（画面に触れたときの「スクロールの許可」設定）overflow：（枠からはみ出した部分を「隠すか出すか」のルール）passive event：（スクロールを「滑らかに動かす」ための事前合図）image rendering：（画像を「クッキリ見せるか滑らかに見せるか」の指定）
触り心地はAIにとって最も苦手な領域だった。 見た目は再現できる。しかし「指離れ」「慣性の重さ」「スワイプ速度」「アニメーションのタイミング」——これらは論理だけでは決まらない。最終的に人間側が違和感を検知するしかなかった。
地獄3：state循環地獄
React移植時に特に頻発したのがこれだ。
AIはすぐuseEffect（「勝手に連動」して動く自動処理）を書きたがる。como resultado、無限再レンダリング、state循環、image preload暴走が起きる。
お気に入り表示の折り返しレイアウトというバグ一つを直そうとしたところ、修正のたびに別の箇所が壊れる「デバッグの無限ループ」に突入した。
- 縦並びになる → 直す → タイトル順表示が崩れる
- 直す → 画像サイズが変わる → 直す → 横スクロールが消える
- 元に戻そうとする → 別の箇所が壊れる
同じ禁止事項をAIが何度も無視する。直前のやり取りの文脈を忘れて逆戻りする。
このプロセスを経て、私はAI共同制作の「本質的な構造」をようやく理解し始めた。
そこから導き出した「AI共同制作の5つのルール」
AIは「丸投げ」で動かない。しかし「AIをどう動かすか」を理解すれば、過去の資産は確実に現代へ繋がる。以下が、この体験から抽出した5つのルールだ。
ルール1：「要望」ではなく「設計書」で渡せ
AIへの指示で最も重要なのは、曖昧な要望を構造化された条件に変換することだ。
❌ 失敗する指示の例
「ブラウザ幅に応じて自然に折り返してほしい」
この指示でAIはTailwindのフレキシブルなレイアウトを生成した。しかしそれはCOSPLAY SHOWCASEの横スクロールUIを破壊した。「自然な折り返し」がAIにとって「縦積み」を意味したのだ。
✅ 機能する指示の例
- La disposición vertical no sirve en absoluto.
- 横スクロールは必ず維持
- Mantenga el tamaño de la imagen igual que el orden del título
- 行数のバランスは崩さない
違いは「何をしてほしいか」ではなく、「何をしてはいけないか」を明示していることだ。AIは制約条件が多いほど、正しい方向に収束しやすい。スワイプ挙動の修正においても、「慣性を入れない」「スワイプ速度は一定」「モバイルSafari優先」「画像ロード中にlayout shift禁止」という具体的な禁止事項・条件リストが、最も効果的な指示だった。
ルール2：AIの「忘却」を前提に設計する
AIはコンテキスト（文脈）を保持する能力に限界がある。長いやり取りの中で、前半に決めた仕様を後半で無視することが頻繁に起きる。
実際に私のプロジェクトでは、「横スクロール禁止」と決めたはずのルールを、数十ターン後にAIが何事もなかったように破るという場面が何度も起きた。state循環問題の修正時も、前の対話で禁止したuseEffectを再び使ってくる、ということが繰り返された。
対策は「禁止事項リストを毎回冒頭に貼る」ことだ。
【このセッションの絶対条件】
・横スクロールUIは変更しない
・画像サイズは既存の仕様を維持
・縦並びレイアウトは使用禁止
・useEffectの新規追加は禁止これをプロンプトの冒頭に毎回挿入するだけで、AIの「逆戻り」事故は大幅に減る。過去の対話履歴に頼らず、毎回のプロンプトで状態を定義するのがAI共同開発の基本作法だ。
ルール3：「コードの意味が分かる」だけで圧倒的に有利になる
完全なエンジニアでなくていい。しかし「完全な素人」でもいけない。
Claudeが「687行目のperRow計算が原因です」と言ったとき、その意味を理解できるかどうかで、次の指示の精度が天と地ほど変わる。私の場合、React stateがどう循環しているのかを最低限把握できていたから、「stateを単純化してください」「thumbnail stateを分離してください」という的確な修正指示が出せた。
重要なのはコードを書ける力ではなく、「エラーの意味を掴もうとする姿勢」だ。エラーメッセージをそのままAIにコピペして「これはなぜ起きているか」と聞くだけでも、解決への道は開ける。
プログラミングの基礎的な概念（変数、関数、ループ、条件分岐）を知っている人間は、AI時代において「中間層」という最強ポジションにいる。コードを書く人より、調整できる人の価値が、これからの時代に上がっていく。
perRow計算：（画面幅に合わせて「1行の個数」を自動調整する計算）React state：（ アプリが今この瞬間に覚えている「記憶」）thumbnail state：（どの「縮小画像」を選択中かという記憶）
ルール4：「作り手の記憶」こそ最大の資産だと知れ
今回のプロジェクトで最も重要だったのは、技術でもAIの性能でもなく、私自身がこのアプリの設計者だったという事実だった。
AIは仕様書がなければ動けない。pero、仕様書がなくても「作り手の記憶」があれば、それを言語化してAIに渡せる。
- タップしたときの回転アニメーションの「速度感」
- 横スクロールの「慣性の重さ」
- ショウケース空間の「奥行きの演出」
これらは数値で記録されていなくても、制作者の体で覚えている。その記憶を言語化する力が、AIに設計図を渡す力になる。
逆に言えば——今回、Claudeに最初の単純なプロンプト「このIPA/APK構造から同等UIを再構築してください」を投げたとき、AIが出力したのは「それっぽい別物」だった。15年前アプリ特有の挙動や触り心地は、ソースコードを持たないAIには復元できなかった。
過去の資産を復活させる際、AIの性能より先に問うべきは「あなたはその作品のことをどれだけ言語化できるか」だ。
ルール5：「失敗の記録」を残すことが、一次情報になる
AIが失敗したことを隠してはいけない。
デバッグの無限ループも、同じミスを繰り返したことも、解決できなかった機能があることも（今回のTogether機能はいまも未完成だ）、すべて記録として残す。
なぜか。
「AIに丸投げしたら数時間で完成した」という話は、読んでいて気持ちいい。しかし再現性がない。同じようにやってみても、同じ結果にならないからだ。
por otro lado、「こう指示したら壊れた」「この順番で直したら別の箇所が崩れた」「この機能だけはどうしても動かなかった」という記録は、次に同じ壁にぶつかる人間にとって、具体的な地図になる。
成功談は読み物として面白い。pero失敗談は、情報として使える。
AIと共同制作する人間が増えるほど、「どこで躓くか」「どう立て直すか」という一次情報の価値は上がっていく。それを持っているのは、実際にやった人間だけだ。
実践チェックリスト：過去の資産をAIで復活させる前に確認すること
- 復活させたい作品について、自分は設計者・制作者として関わったか？
- 当時の仕様を言語化できる「記憶」があるか？
- AIへの指示を「要望」ではなく「条件リスト」で書けるか？
- エラーメッセージの意味を最低限読もうとする姿勢があるか？
- 失敗と試行錯誤を記録として残す覚悟があるか？
- 「数時間で完成する」という期待を捨てられるか？
6つすべてにチェックが入るなら、あなたのプロジェクトはAIで動かせる可能性が高い。
resumen：AIは「橋を架ける道具」であり、橋を完成させるのは人間だ
2011年に生まれた「COSPLAY SHOWCASE」は、2026年のゴールデンウィークを経て、WEBアプリとして再び動き始めた。
AIがあったから完成したのは事実だ。pero、AIだけでは絶対に完成しなかったことも事実だ。
IPAとAPKを解析し、Claudeに「自動復元」させようとした最初の試みは失敗した。state循環地獄、スワイプ挙動の破綻、無限デバッグループ——AIは速く生成するが、設計は雑だった。しかしその失敗を通じて、「AIをどう使うか」を学んだ。
AI時代に必要なのは「生成力」ではない。問題切り分け、UI観察力、違和感検知、仕様整理、修正指示——これらの能力だ。
過去の資産をAIで現代に繋ぐ作業は、「楽をする」ことではない。「これまで不可能だったことを、可能にする」ことだ。
その違いを理解した人間だけが、AIを本当の意味で使いこなせる。
🎭COSPLAY SHOWCASE WEB版を体験する https://nsp-jp.com/cosplayshowcase/app/
📖プロジェクト全記録（元記事） https://nsp-jp.com/blog/cosplay-showcase-web-ai-revival/
