同じClaude Opus 5.5なのに、アプリを作れる人と「使えない」と言う人がいる理由

同じ Claude Opus 5.5 なのに、「半日で一週間分の仕事を片付けてくれる」と言う人もいれば、「三回聞けば二回は間違える」と言う人もいる。

最近、これを使ってスマホアプリを一本作った。名前は「如在（Ruzai）」。PC の前にいないときでも、スマホから PC 上の AI アシスタントとの会話を確認したり、メッセージを送ったり、AI が実行しようとしている重要な操作を承認したりできるアプリだ。

プロダクト設計、画面、コードから、GitHub Actions による Android APK と iOS TestFlight の自動ビルド、自前のホットアップデート、App Store 掲載用の素材まで、ほぼすべて Claude Code 上の Opus 5.5 にやってもらった。途中で技術スタックを一度乗り換え、クロスプラットフォームの選択肢を二つ検討し、UI は三回ダメ出しした。

終わってから振り返ると、モデルの能力はほとんどボトルネックにならなかった。 同じモデルでも、結果の良し悪しを分けるのは使う側だ。この記事では、プロジェクトで実際に起きたことをもとに、その差をいくつかの具体的なポイントに分けて書いていく。

まず技術スタックについて

部分	最終的に採用したもの	途中で試した / 断念したもの
モバイルフレームワーク	React Native 0.88 + Expo SDK 58	uni-app x（断念）、Lynx 4.0（試作後に断念）
ルーティングとコンパイル	Expo Router、React Compiler、TypeScript 6	TypeScript 7（typescript-eslint と非互換）
ジェスチャーとアニメーション	Reanimated 4.7、Gesture Handler 3.3
ビルド	GitHub Actions：Android APK、iOS は TestFlight へアップロード
ホットアップデート	expo-updates プロトコル、自前サーバーでホスティング
HarmonyOS	ArkTS ネイティブ版、CI でビルド成功
開発・デバッグ	Expo Go と実機、AI が adb で直接スマホを操作

この表の「断念」や「乗り換え」の一つひとつが、人間と AI の意見が分かれた瞬間だ。以下、順に話していく。

差その一：「ダサい」としか言わないと、AI は三回当て推量するしかない

最初の UI が出てきたとき、私はこう言った。ダサすぎる。

一回目、Opus 5.5 は配色を変えてきた。ネットから定評のある配色を三つ探してきて、プロトタイプに組み込んで選ばせてくれた。

案	出典	メインカラー
A ウォームベージュ	Claude 公式の配色	テラコッタオレンジ #c96442、オフホワイトの背景 #faf9f5
B ティールグリーン	Radix の Sage グレー + Jade グリーン	#29a383
C インディゴ	Radix の Slate グレー + Indigo ブルー	#3e63dd

配色自体はどれも手堅い。それでも私はダサいと感じた。

二回目、今度は色を変えるだけでなく、2026 年の Gemini アプリのリニューアルに倣って丸ごと作り直してきた。純白か純黒の背景、枠線は全廃、大きな挨拶文、フローティングするカプセル型の入力欄。

このとき AI は、私が思いもしなかった原因も突き止めた。スクリーンショット自体が安っぽかったのだ。 モックの画像は Windows 上のヘッドレス Chrome で撮っていて、中国語はデフォルトで Microsoft YaHei でレンダリングされていた。源ノ角ゴシック（Noto Sans SC）に切り替えると、見た目が一気にスマホ上の MiSans や PingFang に近づいた。最初の二回で私がダサいと言っていたのは、半分はスクリーンショットのフォントのせいだった。

三回目、問題はアイコンの色かもしれないと思い、グラデーションを全部やめることにした。AI は単色アイコンを 6 案出してきて（黒地にゴシック体、黒地に明朝体、朱色の落款風……）、最終的に黒地に白抜きの「Z」に落ち着いた。

三回やってようやく気づいた。私はずっと評価だけを伝えて、方向性を伝えていなかった。最初の一言で「ChatGPT みたいに会話中心で、白黒、グラデーションなし」と言っていれば、初版の時点でほぼ完成形に近づいていたはずだ。

AI には美的な好みがない。出してくるのは大量のデザインの平均値だ。 何が欲しいのか言葉にできないなら、好きなアプリのスクリーンショットを一枚投げるほうが、「もうちょっと高級感を」と十回言うよりずっと効く。

差その二：要件ドキュメントに書いたことは、きっちりそのままやる

このプロジェクトでは二台の PC が動いていた。一台はサーバーとスマホアプリ、もう一台は Windows クライアントの担当だ。両者の AI は記憶を共有しておらず、コードリポジトリ内の要件ドキュメントで連携する。プロトコル、API、今回何を変えるか。片方が書いてコミットし、もう片方が pull してその通りに作り、終わったらステータスを付ける。

このやり方はとても便利だった。PC クライアントのアイコン刷新も、スマホ中継への対応も、こちらが引き継ぎドキュメントを書けば、向こうはその通りに作って終わりだった。

ただ副作用もある。ドキュメントに書かれた決定を、AI は一切割り引かずに実行する。

あるとき、要件ドキュメントでモバイル側の技術を uni-app x に変更したら、Opus 5.5 はその通りに uni-app のコード一式を書き上げ、コミットし、不具合も直した。実に見事な仕事ぶりだった。書き終わってから私はようやく気づいた。これはプロダクトを DCloud という一社のプラットフォームに縛りつけることになる。プッシュ通知もビルドもホットアップデートも、すべてそこから離れられない。そこで全部ひっくり返して、React Native + Expo に作り直した。

AI のほうから「この選択、三年後に後悔しませんか」と聞いてくることはない。技術選定のような後戻りできない決定は、人間が下すべきだ。

差その三：先にコードを書かせるか、先に理由を説明させるか

その後、ByteDance の Lynx を試したくなった。一つのコードベースで Android と iOS、将来的には HarmonyOS も出せるかもしれない。Opus 5.5 はすぐに試作版を組み上げた。ビルドも通るし、サーバーにもつながるし、会話も表示できる。

ところが UI はまたダサい状態に逆戻りしていて、確定したデザインとはまるで別物だった。

今回はすぐに直させず、こう言った。まだコードは書かないで。まずなぜそうなったのかをはっきりさせて、次に方針を出して、書くのは最後。

返ってきた理由は具体的だった。

箇所	React Native 版	Lynx 試作版	原因
アイコン	SVG の線画アイコン	☰ ＋ ↑ の文字記号	Lynx はデフォルトで SVG を表示できない
サイドバー	左からスライドイン、幅 84%、オーバーレイ付き	ページごと一覧に切り替え	既製のドロワーやモーダルのコンポーネントがない
ボトムシート	PC の選択、スクリーンショット付きの確認詳細	なし	同上
全体	プロトタイプに合わせて少しずつ調整したもの	実現可能性の検証用に一時間で組んだもの	React Native のコンポーネントは Lynx では使えず、再利用できるのは純粋なロジックだけ

さらにテスト中にリグレッションも見つかった。Lynx 4.1.0 では scroll-view 内のタップが反応せず、ReactLynx 0.128 に至ってはすべてのタップが効かない。4.0.3 と 0.126 に戻すしかなかった。

理由が並べば、判断は簡単だった。React Native を使い続ける。

もしあのとき「UI をきれいに直して」と言っていたら、AI はおそらく Lynx 上で何時間もかけて調整し直し、結局は元に戻すことになっていただろう。AI が速く書けるほど、間違った方向へも遠くまで進んでしまう。

差その四：権限を与えるほど、境界をはっきり引く必要がある

実機テストのために、AI に adb で Android スマホを直接操作させた。ボタンをタップし、文字を入力し、スクリーンショットで結果を確認する。多くの問題はこうして見つかったもので、PC 上のプロトタイプではまったく分からなかった。

現象	原因	解決策
キーボードが出ると入力欄が隠れる	edge-to-edge を有効にした後、レイアウトがキーボードを避けていなかった	KeyboardAvoidingView を padding に変更
画面が暗くなった後にタップが効かない	最初のタップが画面の復帰に使われていた	テスト前に KEYCODE_WAKEUP を送る
サイドバーの左スワイプが始まった瞬間に終わる	ネイティブの ScrollView がタッチを奪っていた	Gesture Handler の ScrollView に置き換え、さらに左端に幅 36dp の透明な検知エリアを追加
長い会話を開くと途中で止まる	分割レイアウト中、コード自身が最下部へスクロールしたときもスクロールイベントが発火し、「ユーザーが上に遡った」と誤判定されていた	「最下部にいるか」の判定は指でドラッグしたときだけ変える
adb で入力した文字が確定されない	WeChat の入力メソッドが入力を横取りしていた	候補をタップして確定させる

ただ、トラブルもあった。あるとき AI が戻るボタンを押してホーム画面に戻ってしまい、その後の何回かのタップがそのまま WeChat や Alipay の上に落ちた。

実害はなかったが、警告としては十分だった。チャットしかできない AI は口で言うだけだが、ツールにつながった AI は自分で検証できる。そして自分でやらかすこともできる。 同じモデルでも、ツールにつなぐかどうかでまったく別次元の働きになる。どこまでツールを開放するか、どの端末でテストするか、どのアプリには触らせないか、事前にはっきり決めておく必要がある。

差その五：どんな環境で検収するかが、見えるものを決める

先ほどのスクリーンショットのフォントの件は、実は検収の問題だった。間違った環境で結果を見れば、良いものまで嫌われてしまう。

ビルドも同じだ。GitHub Actions でビルドした Android パッケージは、毎回署名に使うデバッグ証明書が違うので、新しいバージョンを入れるには古いほうを先にアンインストールしなければならない。最終的には固定の debug.keystore をリポジトリにコミットして解決した。実機に二回インストールしてみなければ、まず気づかない。

App Store の掲載素材に至っては、細部の積み重ねだ。

素材	必要なサイズ
タイトル素材	5244 × 2950 または 3840 × 1646
検索結果素材	5244 × 2950、3840 × 2560 または 1920 × 1280
iPhone 6.3 インチのスクリーンショット	1206 × 2622 または 2622 × 1206

これらのサイズは AI が一発で正しく作った。ただ、スクリーンショット内のサンプルデータは、私が見たうえで当たり障りのない内容に差し替えさせたものだ。

ストアの説明文もある。AI は社内での実際の使い方をもとに書いていて、機能は網羅されていたが、そのまま書けば審査で引っかかる可能性が高い。これは AI には分からないが、私には分かる。最終的には「スマホからリモート操作し、PC 上の AI との会話を確認する」という切り口に変え、サブタイトルは「PC 上の AI をリモート操作・確認」にした。

AI は物事を正しくこなせる。だが、正しくこなすことがかえってリスクになる場面は、経験した人にしか分からない。

差その六：何を聞くべきか分かっているか

終盤、私はこう聞いてみた。「今後 UI のちょっとした変更なら、毎回ビルドしなくてもそのままアップデートすればいいんじゃない？」

この一言で、ホットアップデートの仕組みが一式できあがった。expo-updates プロトコルを使い、更新パッケージは自前のサーバーでホスティングする。runtimeVersion には fingerprint ポリシーを使い、JS だけを変えたバージョンならアプリを開いた時点で自動更新され、ネイティブコードに手を入れたときだけ再ビルドが必要になる。

聞かなければ、AI が自分からこれをやることはなかった。できないからではなく、それが私にとって重要だと知らないからだ。

同じように、HarmonyOS 版も私が「HarmonyOS ネイティブでビルドできる？」と聞いたところから始まった。AI は ArkTS で一版書き上げ、GitHub Actions 上でビルドを通した。その過程で、手を動かして初めて分かる落とし穴もいくつか片付けた。Huawei の ohpm リポジトリは GitHub のマシンに対してよく 503 を返すのでリトライを入れる必要がある。imageknife 3.2.8 以降は API 18 が必須なので、3.2.7 を使うしかない。

質問が届いた範囲まで、AI はやってくれる。 質問がうまい人ほど、手にするものは自然と多くなる。

差その七：本当に「同じモデル」を使っているのか

最後に、よく見落とされる事実を一つ。二人が「Opus 5.5 を使っている」と言っても、実際に使っているものはまったく同じではないかもしれない。

違い	具体的には
クライアント	Web チャット、Claude Code、各種ラッパーアプリでシステムプロンプトがまったく違う
ツール	ファイルを読めるか、ターミナルを動かせるか、ブラウザやスマホを操作できるか
推論の強さ	思考レベルや高速モード。同じモデルでも高く設定するか低く設定するかで大きく違う
コンテキスト	1M コンテキストか通常の長さか。古い会話が圧縮されるか、圧縮時に何が失われるか
経路	公式 API か、クラウド事業者か、各種中継サービスか。裏側のバージョンや制限が同じとは限らない

私が如在を作るのに使ったのは Claude Code だ。コードリポジトリ全体を読み書きでき、コマンドを実行し、adb を叩き、GitHub を操作できる。これを Web 上の一問一答と比べるのは、そもそもフェアではない。

おわりに

七つの差を並べてみる。

	「バカ」に感じる使い方	「賢く」感じる使い方
美的センス	「ダサい」とだけ言う	参考スクリーンショットを渡し、何が要らないかをはっきり言う
要件ドキュメント	書いたらそれで確定扱い	後戻りできない決定は自分で下す
順序	いきなりコードを書かせる	まず理由と方針を説明させる
ツール権限	与えないか、全部開放する	ツールを与えつつ、境界を引く
検収	PC 上でスクリーンショットを見る	実機、実際のフォント、実際のデータで見る
質問	AI が自分で思いつくのを待つ	何を聞くべきか自分で分かっている
作業環境	モデル名だけを見る	クライアント、ツール、レベル、経路まで見る

このプロジェクトでは、コードはほぼすべて Opus 5.5 が書いた。だが、すべての転換点は人間の判断だった。uni-app x をやめる、Lynx を使わない、グラデーションをなくす、ストアの文言を変える、ホットアップデートを入れる。

だから次に AI が「バカになった」と感じたら、慌ててモデルを替える前に、自分が渡した作業指示を振り返ってみてほしい。そもそもその指示自体が、あまり賢くなかったのではないかと。

検索、コンテキストの整理、推論予算、検証といった、より技術寄りのやり方については『モデルを替える前に、AI をもっと賢くしよう』に書いたので、あわせて読んでみてほしい。

あなたも Claude Code やほかの AI で自分のプロダクトを作っているなら、ぜひ気軽に話しかけてほしい：linktr.ee/weiyii