0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@HikaruYam(Hikaru Yamaguchi)

Codexを使ってアプリをリリースしてみた。

0
Last updated at Posted at 2026-09-06

はじめに

少しまとまった時間ができたので、個人でアプリを作り、ストアで公開するところまでやってみました。

ストア提出の具体的な手順は、詳しい記事がすでに多くあるため、この記事では扱いません。今回は、スマホのCodexアプリから指示を出し、どのように開発を進めたのかを中心に書きます。

作ったのは、技術記事を「あとで読む」と「読んだ」に分けて管理する「ツミテック」です。

alt text

App Store

どんなアプリか

QiitaやZenn、企業の技術ブログなどを見ていると、気になる記事が次々に見つかります。とはいえ、その場ですべてを読むのは難しく、ブラウザのタブ、Xのいいね、ブックマークなど、保存先がばらばらになっていました。

特に不便だったのが、「まだ読んでいない記事」と「すでに読んだ記事」が混ざってしまうことです。

そこで、用途を技術記事の管理に絞り、記事の状態も2つだけにしました。

  • あとで読む記事（未読）
  • 読み終わった記事（既読）

主な機能は次のとおりです。

  • URLの貼り付け、またはSafariなどの共有メニューから保存
  • 未読・既読の切り替え
  • タグとメモ
  • 選択した文章を「記事スクラップ」として保存

「記事スクラップ」は、記事全文ではなく、自分で選んだ文章だけを出典URLと一緒に端末内へ残せる機能です。

alt text

コードはほぼCodexに実装してもらった

ツミテックはFlutter製ですが、具体的なコードはほぼCodexに書いてもらいました。私はFlutterコードの実装にはほとんど関わっていません。

私が主に担当したのは、次のような判断と確認です。

  • どんな課題を解決するアプリにするか決める
  • 必要な機能と、今回は作らない機能を決める
  • 画面を実際に触り、使いにくい部分を見つける
  • 修正内容と完了条件を言葉にしてCodexへ伝える
  • 実機で再確認し、問題があれば追加で指示する

実装に関わる作業は、Codexに任せました。

  • リポジトリ内の仕様書や既存コードを調べる
  • コードとテストを変更する
  • 解析、テスト、ビルドを実行する
  • 変更内容をPull Requestにまとめる
  • 指摘した不具合を調査して修正する

スマホから指示して、手元で確認する

基本的には、次の流れで開発しています。

スマホのCodexアプリから要望を送る
        ↓
Codexが仕様・コードを調査して実装する
        ↓
テストとビルドを行う
        ↓
Androidの開発用APKを作る
        ↓
自分の端末へインストールして触る
        ↓
気になった点を追加で指示する
        ↓
修正版をもう一度インストールして確認する
alt text

開発環境

開発にはMacBook AirとミニPC(Ubuntu)を使っています。Codexは主にミニPC上で動かし、自分で設定や動作を確かめるときはMacBook Airを使いました。

普段使っているスマホがAndroidなので、UIを確認するときは開発用apkを端末にインストールしています。Codexが作業する環境と私が確認する環境を分け、できあがったものを普段使いの端末で触る形です。

Flutterを使っているのでAndroid, iOSの基本的な実装は共通化されています。そのため、ミニPC内で簡単なandroidの挙動の確認はできますが、iOSの共有メニューなど、プラットフォーム固有の機能だけはmacbookでビルドして確認していました。

指示はだんだん具体的になった

最初のころは、「この画面を使いやすくして」「いい感じに直して」といった指示もしていました。ただ、これだけでは、動くものはできても期待どおりの操作になるとは限りません。特にUI周りは求める操作や見た目を具体的に伝えたないと、期待通りになりにくいと感じました。

実機確認を繰り返すうちに、次の内容をまとめて伝えるようになりました。

  • 現在どの画面で何が起きているか
  • どの操作をしたときに困るか
  • 期待する表示や遷移
  • どの状態になれば修正完了か
  • 今回は変更しない範囲

例えば、「ボタンの場所を変えて」とだけ伝える代わりに、次のように書きます。

記事を読んでいる画面で、スクラップ保存の操作が見つけにくい。
AppBarには新しいボタンを増やさず、外部ブラウザで開く操作と同じ場所から使えるようにしたい。

実機で文章を選択したあとに保存できること、保存後に選択状態が残らないことも確認してほしい。

位置に加えて、「どの操作の近くに置きたいか」「操作後にどうなってほしいか」まで書くと、意図に近い形になりやすくなりました。

画面遷移を変更したときは、その画面を開けるかに加えて、戻る操作や保存後の移動先、削除後に戻る場所まで確認します。見た目には問題がなくても、一連の操作を試して初めて違和感に気づくことがよくありました。

仕様をリポジトリへ残す

チャットだけで開発していると、少し前に決めた内容と矛盾した指示を出してしまうことがあります。そこで、アプリのコンセプト、画面のルール、実装しない機能などをMarkdownでリポジトリへ残しています。

新しい作業を頼むときは、まずCodexに関連する仕様書と既存コードを確認してもらいます。大きめの変更はIssue単位に分け、実装に入る前に作業計画を確認します。

特に役立ったのは、「実装しないもの」を決めておくことでした。技術記事を扱うアプリなら、AI要約、RSS、全文保存、クラウド同期なども欲しくなります。ただ、最初から全部を詰め込むと、何のためのアプリなのかがぼやけてしまいます。

そこでツミテックでは、記事を保存し、未読・既読に分け、あとから探せることを中心に据えました。Codexは多くのコードを書いてくれますが、どこまで作るかを決めるのは自分の役割だと考えています。

ストア公開にはアプリ以外の準備も必要だった

今回やってみて実感したのは、アプリが動くだけではストアに公開できないということです。

ツミテックでは、アプリ本体とは別に、紹介ページ、サポートページ、プライバシーポリシーを静的なWebページとして用意しました。ページはGitHub Pages（github.io）で公開し、Cloudflare Registrarで管理している独自ドメインのDNSも設定しました。

ほかにも、ストアへ掲載する説明文やスクリーンショット、プライバシーに関する申告、審査担当者向けの説明などを準備しました。開発中は機能のことばかり考えていましたが、実際に配布するとなると、Webサイトやドメイン、ストア情報、審査対応まで必要になります。

普段の業務でもアプリ開発に関わっていますが、公開に必要なものを一からすべて用意したのは今回が初めてでした。アプリの実装以外にもやることが多いと分かり、ストア公開までの全体像を学べたことは大きな収穫でした。

Codexに任せても、人の確認は必要だった

Codexは実装に加え、テストやビルドもこなします。ただし、テストが通ることと、使いやすいことは別です。

実機で確認すると、次のような問題が見つかりました。

  • 下から出る画面を最後までスクロールできない
  • 端末下部のシステム領域と操作部分が重なる
  • ボタンは表示されているが、利用の流れに合わない場所にある
  • 保存後や削除後の戻り先が不自然

こうした問題は、スクリーンショットやコードレビューだけではなかなか気づけません。私が端末で触って違和感を言葉にし、それをもとにCodexに直してもらうやりとりは欠かせませんでした。

AIにすべてを丸投げするというより、実装担当のCodexと、プロダクト判断・実機確認を行う自分で開発している感覚に近いです。

この開発スタイルで感じたこと

PCの前にいる時間と、開発が進む時間が一致しなくなった

スマホから指示できるので、思いついた改善をその場でCodexに頼めます。自分でコードを書く時間を確保できなくても、移動中などに要件を整理して送れば、Codexに作業を進めてもらえます。

Flutterやアプリ開発の知識はほとんど必要ないと感じた

今回の開発では、Flutterのコードを自分で書く場面はほとんどありませんでした。個人開発くらいの規模なら、実装の大部分をAIに任せられると感じています。

ただし、テストやビルドのCIを組み、その結果を確認できる程度の知識は必要でした。そこまで用意できれば、普段の開発はスマホからの指示だけでもかなり進められます。

UI・UXとアプリの面白さは人が判断する

Codexから「実装とテストが完了した」と報告されても、それだけで完成にはしません。APKを入れて一連の操作を試し、気になる点がなくなるまで修正します。

特にUIはAIだけでは確認しにくいため、まだ人が実機で触る必要があります。また、動くアプリを作ることと、使い心地がよく、面白いアプリを作ることは別だなと強く思いました。最後は人が判断するしかないと感じました。

正直なところ、今のツミテックも、アプリとしての面白さはまだ十分ではありません。これからも自分で使いながら更新を重ね、改善していきたいと思います。

まとめ

普段の業務でもアプリ開発に関わっていますが、ストアへ出すために必要なものを一から用意した経験は、とても勉強になりました。アプリ本体以外にも準備することが多く、普段の開発とは違う知識を得られました。

現在はiOS版を公開しています。Android版も近いうちに公開したいと考えています。Google Playは個人開発者がリリースするには障壁が多く、色々準備中です。

ブラウザのブックマークに「あとで読む」が増えている方は、よければツミテックも使ってみてください。

役立ったツール

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?