始める前に PoC をしてみた

2026.07.02約4分費用: 0円

使ったもの

数分で Zip が返ってきた

生成 AI が流行っている。それは知っている。でも、実際どこまでできるのか。仕事で触れる情報と、世の中の宣伝文句の間には、たいてい距離がある。だから最初に、いちばん安い方法で試すことにした。PoC (Proof of Concept) というやつである。

やったことは単純で、Claude のチャット (claude.ai) にこう頼んだだけだった。

iPhone のアプリで、Swift でゲームを作って。Zip ファイルで出力して。

数分後、Zip ファイルが出力された。ダウンロードして、手元のサポート切れ Intel Mac の Xcode に展開する。USB で iPhone をつないで、アプリをインストールする。

動いた。

雑に頼んだゲームが、雑に動いた。品質の話ではない。「プログラミング言語を書かずに、チャットの依頼文だけで、実機で動く iPhone アプリが手に入った」という事実に、時代が変わった瞬間を見た気がした。

この体験を、記録に残すことにした

PoC が通ったので、本番をやることにした。生成 AI の可能性がどこまであるのか、実際にプロダクトを作って確かめる。それが lycoapp.com のアプリ群で、この Architecture Notes はその 3 か月の記録である。

進め方は OODA ループ (Observe / Orient / Decide / Act — 観察・状況判断・意思決定・行動) に寄せた。計画を固めてから作る PDCA ではなく、まず観察して、その場で判断して、動く。生成 AI との開発は状況が毎週変わるので、この回し方が合っていた。

ひとつ強調しておきたいのは、このプロダクトで使った技術はすべて初見だということ。似た技術を仕事で使った経験はあるが、「自分が使ったことがあるから」という理由では選んでいない。要件に対してフラットに検討して構築した。だから各記事は、しがらみのない選定記録として読めるはずである。

記録の形式

検討結果は ADR (Architecture Decision Record — 意思決定の記録) として残す。記述形式は MADR (Markdown Any Decision Records) に、SCQA フレームワーク (Situation / Complication / Question / Answer) の流れを重ねた。状況から問いを立て、判断基準を並べ、答えと理由、没にした案、やってみた振り返りまでを 1 本の話として書く。ちなみにこの形式も初見である。

手順書は書かない。理由は 2 つある。第一に、ADR の主役は「なぜそう決めたか」であって手順ではない。第二に、手順は AI に聞くのがいちばん早い。ここに書いた構成は実際に動いているので、記事ごと AI に渡して「これを再現して」と頼めば、たいてい上手くやってくれる。

次の 1 開発基盤 から、具体的な意思決定に入る。