Androidアプリを作れません。JavaもKotlinも書けません。Android Studioも使いません。PCもUSBケーブルも使いません。それでも、AndroidスマホだけでAndroidアプリを作れるところまで持っていきました。
やることは簡単です。Google PlayからTermuxを入れます。そして、一行貼ります。私のPixelでは、その一行を貼ってから電卓アプリをインストールして動かすまで、約1分20秒でした。
まず試したい人は、ここから先を全部読まなくて大丈夫です。むしろ読まなくていいです。Android 11以降のスマホを用意して、下の通りやってみてください。
まず5秒で始める
Google PlayからTermuxをインストールします。現在使っているのはGoogle Play版です。今回の構成では、Android 11以降を動作要件にしています。
Termuxを起動したら、下の一行をコピーします。Termuxの黒い画面を長押ししてペーストし、Enterを押します。初回なので、いろいろなものをダウンロードします。
curl -fsSL https://github.com/everyoneknows/android-ai-appmaker/raw/2c38f5655ccc27f3eb6f35c5be9a8d825a98f917/setup.sh | bash
黒い画面に大量の文字が流れます。apt-get や openjdk など、いろいろ出てきます。大きなファイルでは 34%、35% のように進捗も表示されます。止まっていなければ、そのまま待ちます。
しばらくするとChromeが開きます。「Androidアプリメーカー」という画面が表示されるので、**「電卓をダウンロード」**を押します。calculator.apk がダウンロードされるので、Chromeのダウンロード一覧から開いてインストールします。
初回だけ、ChromeからAPKをインストールする許可を求められる場合があります。また、Google Playから配布されたアプリではなく、その場で自分のスマホが作ったAPKなので、Play Protectから確認やスキャンを求められることがあります。明確に「有害なアプリ」と判定された場合は進めないでください。
インストールできたら電卓を開きます。123 × 456 = と押して、56088 と出れば成功です。これでAndroidスマホ自身がAndroidアプリをビルドし、そのスマホ自身にインストールして動かしたことになります。
ここまでで十分です。
以下は、なぜこんなことをしているのか、内部で何をしているのか、そしてこの一行を完成させるまでにどれだけ転んだのかを書きます。
ソースコードはGitHubにあります
リポジトリはこちらです。
everyoneknows/android-ai-appmaker
curl | bash を見て嫌な顔をする人は正常です。ネットから取ってきたシェルスクリプトをそのまま実行するので、中身を確認したい人はGitHubを先に見てください。今回のbootstrapは、動作確認した内容を40桁のcommit SHAで固定しています。
このプロジェクトはMIT Licenseで公開しています。セットアップ、APKビルド、localhostのWeb UI、サンプル電卓なども全部リポジトリに入っています。今後Codex CLIを載せる第2幕も、このリポジトリをそのまま育てていく予定です。
ちなみに、このGitHubリポジトリを作ってrc19まで開発しましたが、私はGitHubのWeb画面を一度も直接開いていません。コードもGitHub UIも、私はほぼ見ていません。どうやって開発したのかという話は、それだけで長くなるので別の記事にします。
この記事では、まず「スマホ自身にAndroidアプリを作らせる」という部分に絞ります。
何をしたかったのか
私はプログラマではありません。JavaもKotlinも書けませんし、プログラマになりたいという強い希望もありません。以前Android Studioをインストールしたことはありますが、わりと早い段階で嫌になりました。
でも、Androidアプリそのものは作ってみたかった。プログラマにしかできないと思っていたことは、やってみたかったのです。ここ数年でAIがコードを書けるようになり、その境界線がかなり変わってきました。
AIに「こういうアプリが欲しい」と言えば、コードそのものは書いてもらえます。ただし、Androidアプリの場合、そのコードをAPKにする場所が必要です。普通ならPCにAndroid StudioやSDKを入れます。
そこで考えました。コードを作るAIも、コードをAPKにする環境も、全部スマホの中に入れてしまえばいいのではないか。
最終的にやりたいことは単純です。スマホに向かって「買い物メモを作って」と日本語で言います。すると、そのスマホ自身がコードを書き、そのスマホ自身がAPKをビルドし、そのスマホ自身へインストールする。
今回はその第一段階です。まだCodex CLIは入れていません。まず、Androidスマホ自身がAndroidアプリをビルドできる場所を完成させることにしました。
普通のAndroid開発とは逆向き
普通のAndroidアプリ開発は、だいたいこんな構成だと思います。
PC
↓
Android Studio
↓
JDK / Gradle / Android SDK / build-tools
↓
APK
↓
USB / adb / Google Playなど
↓
Androidスマホ
開発する場所と、アプリを動かす場所が分かれています。PCで作って、スマホへ持っていく。非常に普通です。
今回やっていることは違います。
Androidスマホ
├─ Termux
│ ├─ JDK
│ ├─ Android SDKの必要部分
│ ├─ aapt2
│ ├─ D8
│ ├─ apksigner
│ └─ zipalign
│
├─ APKをビルド
│
├─ localhost Web UI
│
├─ Chrome
│
└─ Android Package Installer
工場と製品の使用場所が同じスマホにあります。Androidスマホの中でJavaをコンパイルし、DEXへ変換し、APKを組み立て、署名までします。そのAPKをChrome経由で同じスマホへ戻してインストールします。
少し変な構成です。でも、これができればPCはいりません。Android Studioもいりません。USBケーブルもいりません。
そして第2幕でCodex CLIをTermuxに入れれば、同じ工場へAIで作ったコードを流せます。
実際のビルドパイプライン
今回のサンプル電卓はJavaで書かれています。Javaのソースコードから、かなり素朴な手順でAPKまで持っていきます。
ざっくりするとこうです。
MainActivity.java
↓
javac
↓
.class
↓
D8
↓
classes.dex
一方で、AndroidManifest.xmlなどのAndroid側の情報をaapt2でまとめます。
AndroidManifest.xml
↓
aapt2
↓
resources.apk
そして両方を合わせます。
resources.apk + classes.dex
↓
zip
↓
unsigned.apk
↓
zipalign
↓
aligned.apk
↓
apksigner
↓
calculator.apk
Gradleは使っていません。今回の目的は大規模なAndroidアプリ開発環境を再現することではなく、まずAndroid端末の中だけで最小限のAPKビルドを成立させることだからです。
現在の主要な設定は次の通りです。
JDK OpenJDK 25
Java source 8
Java target 8
compile platform android-34
targetSdk 34
minSdk 23
build-tools archive 35.0.0
ここで少しややこしいのがAPI 34です。android-34でビルドしているからといって、Android 14以上のスマホでしか動かないわけではありません。APK側の実行下限はminSdk 23です。
ただし、このプロジェクトでは開発環境としてGoogle Play版Termuxを使っています。こちらがAndroid 11以降を前提としているため、今回の「スマホ自身でビルドする」体験全体としてはAndroid 11以上を要件にしています。
最初の敵はJavaだった
最初はもっと簡単に考えていました。TermuxへJavaを入れて、Android SDKを持ってくれば、そのままビルドできるだろうと思っていました。
ところが、実機のGoogle Play版TermuxとAndroid 17の組み合わせでは、JDK 21のjavacが途中でabortしました。Javaソースが間違っているというより、javacそのものが落ちます。
私はJavaを書けないので、当然ここで自力解析はできません。AIにログを調べさせ、環境を切り替えながら検証しました。
最終的にはOpenJDK 25を明示的に使う形にしました。すると、同じ実機でJavaのコンパイルが安定して通るようになりました。
この原因について、現時点で完全な説明はできていません。今回確認できたのは、少なくとも私のPixel、Google Play版Termux、Android 17という環境ではJDK 21で問題が出て、JDK 25では回避できたということです。
ここは技術的にはまだ宿題です。
Android公式のbuild-toolsがAndroidで動かない
Javaを越えると、次はAndroid SDKです。
GoogleがLinux向けに配布しているAndroid build-toolsを取ってくればいいだろうと思いました。ところが、そこに入っているnative binaryはPC向けのx86_64です。
今回使っているPixelはaarch64です。つまり、Androidアプリを作るためのAndroid公式ツールをAndroidスマホへ持ってきても、そのままでは動きません。
なんだそれ、という感じです。
そこで、全部をGoogle配布物で揃えるのをやめました。nativeで動かなければ、Termux側にあるARM64ネイティブ版を使います。
現在はこうなっています。
| ツール | 使用元 |
|---|---|
java |
Termux OpenJDK 25 |
javac |
Termux OpenJDK 25 |
keytool |
Termux OpenJDK 25 |
aapt2 |
Termux package |
zipalign |
Termux package |
android.jar |
Google Android SDK archive |
d8.jar |
Google build-tools archive |
apksigner.jar |
Google build-tools archive |
Google配布物とTermuxネイティブツールの混成です。
d8.jarとapksigner.jarはJavaで動くので、ARM64でもそのまま使えます。一方、aapt2やzipalignはnative binaryなので、Termux側のARM64版を使います。
最初からこの構成を思いついたわけではありません。動かないものを一つずつ分解していった結果、こうなりました。
API 35でも引っかかった
Androidのplatformについても、一番新しいものを使えばいいと思っていました。
ところがAPI 35とTermux側のaapt2の組み合わせでは、今回の環境でうまく処理できない部分がありました。そこでplatformをAPI 34へ下げました。
API 34では同じビルドパイプラインが安定して通りました。今回の電卓にAPI 35固有の機能は何も必要ありません。
そのため、「最新であること」より「この組み合わせなら再現すること」を優先しました。
このプロジェクトではセットアップ時にplatform archiveも固定しています。最新版を毎回自動取得するのではなく、動作確認したURLとSHA-256を指定しています。
新しいものへ追従すること自体は今後できます。でも、まずは「昨日動いた一行が今日も動く」ことを優先しました。
なぜGradleを使わないのか
Android開発に詳しい人ほど、ここまで読んで「なぜGradleを使わない」と思うかもしれません。
理由は、第一幕の目的に必要ないからです。今回は電卓一つを作ることが目的ではなく、Androidスマホの中だけでAPK製造ラインが成立するかを確認しています。
Gradleを入れると、依存関係の解決やAndroid Gradle Plugin、SDK構成など、かなり大きな仕組みが追加されます。それ自体は便利ですが、今回欲しかった最小構成よりずっと大きい。
まずはJavaソースをjavacでコンパイルする。D8でDEXへ変換する。aapt2でmanifestとresourcesをまとめる。署名する。
この一本道がAndroid上で再現できれば十分でした。
今後、作りたいアプリが複雑になればGradleや別のビルド手段を検討するかもしれません。でも最初から全部載せるより、必要になったら増やす方針です。
これは「簡単な方法を選んだ」というより、最初の成功条件に必要なものだけ残したという感じです。
APKができたのにインストールできない
APKを作れるようになった時点で、私はかなり終わった気になっていました。
でも、APKができても、ユーザーがそれを簡単にインストールできなければ第一幕は完成しません。
最初はTermuxから直接Package InstallerへAPKを渡せばいいと思っていました。ところがGoogle Play版Termuxでは、その導線に必要なREQUEST_INSTALL_PACKAGESを使えません。
APKは目の前にある。でも、そのAPKを同じスマホへ簡単に入れる経路がない。
ここでかなり考えました。
最終的に、スマホの中にWebサーバを立ててChromeへ渡すことにしました。
スマホの中からスマホへHTTPで渡す
Termux内でPythonのHTTPサーバを起動します。
待ち受けるのは127.0.0.1:8765だけです。LANへ公開する必要はありません。
構成はこうです。
Termux
↓
Python ThreadingHTTPServer
↓
127.0.0.1:8765
↓
Chrome
↓
/apk
↓
calculator.apk
↓
Android Package Installer
TermuxでAPKを生成します。セットアップが終わるとChromeを開きます。Chromeは同じ端末の127.0.0.1:8765へアクセスします。
Web画面で「電卓をダウンロード」を押すと、/apkからAPKを取得します。それをChromeのダウンロードとしてAndroid側へ渡し、Package Installerからインストールします。
一度スマホの中で作ったAPKを、同じスマホのlocalhost経由でChromeへ受け渡しています。
端末の外へ出ていません。
遠回りですが、ユーザーから見れば「電卓をダウンロード」を押すだけです。
Web UIは一本道にした
技術的にできるようになってからは、ほとんどUXの話になりました。
最初のユーザーはAndroid SDKを知りません。aapt2もD8も知りません。APKがどのディレクトリにできたかも知る必要はありません。
画面には、次にやることだけ出すようにしました。
最初の画面は、
STEP 1 電卓をダウンロード
です。
ダウンロードすると、「Chromeのダウンロードを開いてcalculator.apkをタップしてください」と表示します。
インストールできたら、
インストールできました → 次へ
を押します。
次は、
STEP 2 電卓を起動
です。
123 × 456 = 56088になれば成功だと書いてあります。
最後に、
電卓が動きました → 次へ
を押します。
Chromeへ戻ると、
🎉 はじめてのAndroidアプリが完成しました
と表示します。
そして、
次はCodexです！
ここまでが第一幕です。
電卓も少しだけちゃんと作った
サンプルなので、動けば何でもいいという考え方もあります。
でも、最初に自分のスマホが作ったAndroidアプリが、ボタンが数個だけの実験画面では少し寂しい。
そこで普通の電卓らしくしました。
数字、四則演算、小数点、クリア、イコールがあります。
最後まで気になったのが0の幅でした。
通常の電卓は下段が、
0 . =
のように0が少し広くなっています。
そこまで直しました。
この辺になると、もはやビルドシステムとは関係ありません。でも、プログラムを書かない私が見ているのは、むしろこういう部分です。
ちゃんと電卓に見えるか。押した時に分かるか。次に何をすればいいか迷わないか。
コードを書かないから、私はずっと外側を見ています。
セットアップログはあえて隠さなかった
初心者向けUXを考えると、セットアップ画面をもっと綺麗にしたくなります。
たとえば黒い画面の大量ログを全部消して、
Androidアプリ開発環境を準備しています……
というスピナーだけ見せることもできます。
でも、実際に何度も試しているうちに、私は今のログが結構好きになりました。
apt-getがどんどん流れる。openjdkが見える。大きなファイルを取っている時は34%、35%と数字が増えていく。
プログラムが分からなくても、
おおおおっ、なんか作ってる。
ということは分かります。
進捗率が動けば、処理が止まっていないことも分かります。
全部を隠すことが良いUXとは限らない。
今回は、見せた方が安心する複雑さは残しました。
curl | bash なので少し真面目にセキュリティ
この記事の冒頭では、かなり景気よく一行貼ってくださいと書きました。
curl ... | bash
です。
知らないWebサイトからスクリプトを取ってきて、そのまま実行します。普通に考えると警戒した方がいいです。
そのため、今回は少なくとも「毎回mainブランチの最新版を実行する」という形にはしていません。
Qiitaに載せているURLは、固定したbootstrap commitを指しています。
2c38f5655ccc27f3eb6f35c5be9a8d825a98f917
さらに、このbootstrap自身が実際のappmaker content commitを40桁SHAで固定しています。
セットアップ中にGoogleから取得するplatform archiveやbuild-tools archiveも、期待するSHA-256を持っています。ダウンロード後に検証し、一致しなければ停止します。
Webサーバも127.0.0.1だけで待ち受けます。
Hostチェック、Originチェック、CSRF token、リクエストサイズ上限、ビルドロックなども入れています。
今回の第一幕ではAI自体を使わなくても動きます。
もちろん、だから絶対安全ですと言うつもりはありません。
curl | bashを実行する以上、気になる人はGitHubのコードを先に確認してください。
むしろ、そうしてもらうために冒頭近くへリポジトリを置いています。
そしてrc17で404になった
ここまで読むと、わりと順調に完成したように見えるかもしれません。
実際には最後の方でかなり転びました。
rc17の時点で、ほぼ全部できていました。
Google Play版Termuxを入れる。一行貼る。JDKが入る。Android SDKが入る。APKができる。Chromeが開く。電卓をダウンロードできる。インストールできる。123 × 456 = 56088も動く。
最後に電卓画面から「次の開発に進む」を押します。
Chromeへ戻って、
次はCodexです！
と表示されるはずでした。
押しました。
404。
最後の最後です。
原因はPython側のURL処理でした。
Webサーバは/ならトップページを返します。しかし完了画面へ戻る時は、
/?completed=1
になります。
サーバ側でリクエスト文字列全体を/と比較していたため、query parameter付きのURLをトップページとして認識できませんでした。
urlsplit(self.path).pathを使ってpath部分だけを見るように修正しました。
rc18です。
今度こそ終わったと思いました。
rc18ではダウンロードボタンが動かなかった
rc18をまっさらな状態から試します。
Web UIが開きます。
「電卓をダウンロード」
を押します。
何も起きません。
直接Chromeのアドレス欄へ、
http://127.0.0.1:8765/apk
と入れるとAPKは落ちます。
Termuxからcurlしても正常です。
サーバ側の/apkは200 OKです。
APKのSHA-256も一致します。
つまり、APK生成もWebサーバも正常。
ボタンだけが動かない。
原因はこれでした。
document.querySelector('#download').onclick=
()=>document.querySelector('#download-help').hidden=false;
ボタンを押すと、APKをダウンロードしつつ、その下に「ダウンロードが終わったらChromeのダウンロードを開いてください」と案内を表示するつもりでした。
ところがこのarrow functionは式の結果をreturnします。
hidden=falseの代入結果はfalseです。
DOM0のonclick handlerでfalseを返すと、ブラウザのdefault actionがキャンセルされます。
つまり、
ダウンロード方法を説明するためのJavaScriptが、ダウンロードそのものを止めていました。
修正は単純です。
document.querySelector('#download').onclick=()=>{
document.querySelector('#download-help').hidden=false;
};
これなら戻り値はundefinedになります。
rc19になりました。
しかも古いAPKに騙された
rc18の調査中、さらに嫌なことに気づきました。
私は一度、「ちゃんと電卓をダウンロードしてインストールできた」と思っていました。
でも、Pixelのダウンロードフォルダには前日のテストで落としたcalculator.apkが残っていました。
つまり、今回ダウンロードしたと思ってインストールしたAPKが、実は古いAPKだった可能性があります。
人間側の偽陽性です。
これはかなり怖かった。
自動テストがPASSしていても、HTTPでAPKが正常配信されていても、実機に古いファイルが一本残っているだけで、人間が「動いた」と誤認します。
そこで全部消しました。
Termuxをアンインストールしました。
電卓アプリもアンインストールしました。
ダウンロード済みAPKも削除しました。
そこから完全freshで最初の一行を貼り直しました。
rc19の最終受入試験です。
徒然草第109段
rc17で404。
rc18でダウンロードボタン停止。
さらに古いAPKで偽陽性。
全部、山頂目前です。
ここで思い出したのが『徒然草』第109段の「高名の木登り」でした。
木登りの名人は、弟子が高い場所にいる間は何も言いません。かなり下まで降りてきて、もう危なくなさそうなところで初めて「気をつけろ」と声をかけます。
理由を聞かれて答えます。
「あやまちは、やすき所になりて、必ず仕る事に候ふ」
事故は簡単なところまで来て安心した時に起きる。
700年前から言われています。
rc17からrc19まで、本当にそれでした。
rc19、完全freshで1分20秒
Google Play版TermuxだけをインストールしたPixelから始めました。
電卓アプリはありません。
古いAPKもありません。
一行貼ります。
セットアップが始まります。
大量のログが流れます。
openjdkが入ります。
Android build toolsの必要な部分を取得します。
サンプル電卓をビルドします。
Webサーバが立ち上がります。
Chromeが開きます。
「電卓をダウンロード」
を押します。
今度は本当に新しいAPKが落ちます。
インストールします。
電卓を起動します。
123 × 456 = 56088
動きました。
「次の開発に進む」を押します。
Chromeへ戻ります。
🎉 はじめてのAndroidアプリが完成しました
そして、
次はCodexです！
が表示されます。
時計を見ると、コマンドを貼ってから約1分20秒でした。
第一幕、終了です。
ユーザーに1分20秒しか苦労させないために
今回、一番面白かったのはここです。
完成したものだけ見ると、ほとんど何もしていません。
Google PlayからTermuxを入れる。
一行貼る。
少し待つ。
Chromeで電卓をダウンロードする。
インストールする。
終わりです。
でも、その一行の後ろにはJDKがあります。CPUアーキテクチャがあります。Android SDKがあります。aapt2があります。D8があります。APK署名があります。Androidのインストール権限があります。localhostのWebサーバがあります。Chromeがあります。
ユーザーに1分20秒しか苦労させないために、作る側が全部苦労する。
今回やっていたことを一言でまとめるなら、たぶんこれです。
難しい仕組みを難しいまま渡して、「手順書を読んでください」と言うこともできます。
でも今回は、それをやりたくありませんでした。
知らなくても使えるところまで、面倒を裏側へ押し込みたかった。
私はコードを書いていない
ここまで技術的なことを長々書きました。
でも私は、このコードを書いていません。
Javaを書いていません。
Pythonも書いていません。
JavaScriptも書いていません。
aapt2のコマンドラインを考えたわけでもありません。
JDK21の問題をコードレベルで解析したわけでもありません。
私がやっていたのは別のことです。
「一行にしたい」
「Android Studioはいらない」
「Google Play版Termuxだけにしたい」
「ここでユーザーは迷う」
「電卓が電卓っぽくない」
「0は2列幅にしたい」
「最後に次はCodexですと出したい」
「404になった」
「ダウンロードできない」
「昨日のAPKが残っていた」
「全部消して最初から試す」
そんなことを言っています。
実装はAIがやります。
テストもかなりAIがやります。
でも、どこまで行けば完成なのかを決めるのは人間側です。
AIでも最後は実機だった
今回、自動テストはかなり入れました。
Web UIのテスト。
setupのテスト。
セキュリティ周りのテスト。
ダウンロードのテスト。
回帰テスト。
それでもrc17で404が出ました。
rc18ではリンクが動きませんでした。
さらに、人間が古いAPKに騙されました。
最後に問題を見つけたのはPixelです。
これは、AIが役に立たないという話ではありません。
むしろAIがいなければ、私はここまで来られませんでした。
ただ、今回の成功条件は「コードが正しい」ではありません。
プログラムを書けない人がAndroidスマホを触って、最初から最後まで迷わず行ける。
これが成功条件です。
そこは実機を触るしかありませんでした。
現実は強い。
AIはまだ電卓の中にいない
少し紛らわしいのですが、今回作った電卓の中にAIはいません。
この第一幕はAIなしでも動きます。
セットアップ時にOpenAIへログインもしません。
Codex CLIもまだ入りません。
では、なぜこのプロジェクト名がandroid-ai-appmakerなのか。
この第一幕で作ったのは、AIそのものではなく、AIがあとから使えるAndroidアプリ製造ラインだからです。
今はこうです。
Javaソース
↓
Androidスマホ
↓
APK
次はこうします。
日本語
↓
Codex CLI
↓
Javaソース
↓
同じAndroidビルド環境
↓
APK
たとえば、
「買い物メモを作って」
と入力します。
Codexがコードを書きます。
今できたビルドパイプラインへ流します。
APKができます。
同じスマホへインストールします。
ここまで行ければ、かなり面白くなります。
最終的にやりたいこと
プログラマになりたいわけではありません。
でも、アプリは作りたい。
以前は、その二つはかなり矛盾しているように感じていました。
Androidアプリを作りたければ、JavaやKotlinを勉強して、Android Studioを覚えて、Gradleを覚えて、SDKのことを知る。
それが普通でした。
今も、ちゃんとしたAndroid開発者になるなら当然必要だと思います。
でも、私が欲しいのは資格でも職業でもありません。
自分が欲しいものを、自分で作れることです。
コードを書くところをAIへ渡せるなら、そこは渡せばいい。
今回やってみて、人間の仕事から「コードを書く」という部分だけが、ぽろっと抜け落ちたような感覚がありました。
代わりに、何を作るか、どう使うか、どこが分かりにくいか、本当に成功したのかを見る仕事が残りました。
むしろ、そちらは以前よりはっきり見えるようになりました。
今回の構成まとめ
今回の第一幕を技術的にまとめると、こうなります。
Android 11+
↓
Google Play Termux
↓
OpenJDK 25
↓
Termux native:
- aapt2
- zipalign
Google archive:
- android.jar (API 34)
- d8.jar
- apksigner.jar
↓
javac
↓
D8
↓
aapt2
↓
zipalign
↓
apksigner
↓
calculator.apk
↓
localhost Python Web Server
↓
Chrome
↓
Android Package Installer
↓
電卓起動
サンプルアプリはJava。
minSdk 23。
targetSdk 34。
ビルド環境としての実用要件はGoogle Play版Termuxに合わせてAndroid 11以上。
PC不要。
Android Studio不要。
USB不要。
root不要。
第一幕ではOpenAIアカウントも不要。
一行貼って約1分20秒。
ここまでできました。
GitHubはこちら
もう一度置いておきます。
everyoneknows/android-ai-appmaker
まだ作りかけです。
第一幕がやっと完成したところです。
次はTermuxへCodex CLIを入れます。
最終的には、
「こういうAndroidアプリが欲しい」
と日本語で言うだけで、そのスマホ自身が自分用APKを作るところまで持っていきたいと思っています。
ちなみに、このリポジトリをここまで育てておきながら、私はGitHubの画面を一度も直接見ていません。
ChatGPTと会話し、別のAIが実装し、GitHubへcommitし、私はPixelで実機テストをする。
どういう開発なんだ、それ。
その話は次の記事にします。
まずは第一峰。
Androidアプリを作れないので、スマホに作らせました。
次はCodexです。