Architecture Notes始める前に PoC をしてみた
00要約Overview
Tools
- iPhone実機での動作確認手持ち
- Mac (Intel・サポート切れ)Xcode 展開、PoC のみ手持ち
- Claude生成 AI (Free プラン)0 円
01序Jo
生成 AI が流行っている。それは知っている。でも、実際どこまでできるのか。仕事で触れる情報と、世の中の宣伝文句の間には、たいてい距離がある。
だから何かを始める前に、いちばん安い方法で確かめることにした。PoC (Proof of Concept) というやつである。問いは、これだけ。
生成 AI だけで、iPhone アプリは作れるのか?
02破Ha
Zip
やったことは単純で、Claude のチャット (claude.ai) にこう頼んだだけだった。
iPhone のアプリで、Swift でゲームを作って。
Zip ファイルで出力して。
数分後、Zip ファイルが出力された。ダウンロードして、手元のサポート切れ Intel Mac の Xcode に展開する。USB で iPhone をつないで、アプリをインストールする。
動いた。
雑に頼んだゲームが、雑に動いた。品質の話ではない。「プログラミング言語を書かずに、チャットの依頼文だけで、実機で動く iPhone アプリが手に入った」という事実に、時代が変わった瞬間を見た気がした。
Product
PoC が通ったので、本番をやることにした。生成 AI の可能性がどこまであるのか、実際にプロダクトを作って確かめる。それが lycoapp.com のアプリ群で、この Architecture Notes はその 3 か月の記録である。3 か月で、ここに書いてあることは一通りできた。
- アプリ 10 本リリース
- Web サイト構築
- ドメイン取得
- AdMob / BMC / アフィリエイト
すべてスマホによる構築である。
進め方は OODA ループ (Observe / Orient / Decide / Act — 観察・状況判断・意思決定・行動) に寄せた。計画を固めてから作る PDCA ではなく、まず観察して、その場で判断して、動く。生成 AI との開発は状況が毎週変わるので、この回し方が合っていた。
ひとつ強調しておきたいのは、このプロダクトで使った技術はすべて初見だということ。技術者として、似た技術を仕事で使った経験はあるが、アプリ開発はしたことがない、GitHub も使ったことがない。「自分が使ったことがあるから」という理由では選んでいない。要件に対してフラットに検討して構築した。だから各記事は、しがらみのない選定記録として読めるはずである。
03急Kyu
ADR
検討結果は ADR (Architecture Decision Record — 意思決定の記録) として残す。記述形式は MADR (Markdown Any Decision Records) に、SCQA フレームワーク (Situation / Complication / Question / Answer) の流れを重ねた。状況から問いを立て、判断基準を並べ、答えと理由、没にした案、やってみた振り返りまでを 1 本の話として書く。ちなみにこの形式も初見である。
詳細な手順書は書かない。理由は 2 つある。第一に、ADR の主役は「なぜそう決めたか」であって手順ではない。第二に、手順は AI に聞くのがいちばん早い。ここに書いた構成は実際に動いているので、記事ごと AI に渡して「これを再現して」と頼めば、たいてい上手くやってくれる。そのため、記事の最後に AI への指示文を添えてある。やりたいことさえ伝われば、あとは AI と相談して決めていけばいい。
もう一歩踏み込むと、これは省力化だけの話ではない。AI が作業を代わってくれて、人間の仕事が意思決定へ寄っていくのなら、プロダクト開発で本当に残す価値のあるドキュメントは、何をどう作るかの設計書ではなく、なぜそう決めたかの記録の方ではないか — PoC で時代の変わり目を見て、そう考えるようになった。
設計書ではなく、意思決定の記録 (ADR) が、
開発ドキュメントの中心になっていく。
よって、このサイトは「何をしたか」ではなく「なぜそう決めたか」の記録として読んでほしい。道のりは、まず 1 AI 駆動スマホ開発 で作れるようになり、2 ブランド基盤 で積み重ねの器を整え、3 マーケティング で何を作るかを決め、4 マネタイズ で死なないプロダクトにする — という順で進む。ここから、具体的な意思決定に入っていく。