はじめに
こんにちは！佐渡島の半農半エンジニア、矢部です。前回のブログでは、GPS×AI画像認証の「二重認証スタンプラリー」をKiroとAmazon Bedrockで作った話を書きました。
ありがたいことにブログが採用されまして、その後も機能追加を続けています。今回はその「その後」の話です。
前回は技術寄りの話が中心でしたが、今回は 「市の古文書をアプリに組み込んだ経緯」「AIでゲームのビジュアルを大量に作った話」「グループ対戦モード」 に加えて、 「AIと協働開発して人間側が疲弊した話」 という、ちょっとリアルな話もします。
市所蔵の古文書がアプリに入るまで — 偶然から始まった公民連携
観光協会での偶然の出会い
この話、完全に偶然から始まりました。
ある日、相川の観光協会に立ち寄ったんです。そしたら、たまたまそこに 佐渡市の古文書や歴史資料を管理している課の方 がいらっしゃった。
「あの……実は相川のスタンプラリーアプリを作ってまして、江戸時代の絵巻とか古文書の画像を使わせていただくことって……できたりしますか？」
ダメ元です。行政が所蔵する歴史資料をいち個人開発者のアプリに貸してくれるなんて、普通に考えたらハードル高いですよね。
ところが、話を聞いてくださった方が興味を持ってくれまして。「面白いですね、正式に利用申請を出していただければ検討しますよ」と。
なんやかんやで利用申請
そこから「なんやかんや」ありました。利用目的の説明、アプリの概要資料の作成、申請書の記入。正直、コードを書くより緊張しました。
でも結果的に、佐渡市が所蔵する江戸時代の絵巻の画像を、アプリ内で利用させていただけることになったんです。
技術的には、絵巻の画像をS3に保存して、管理画面から登録・管理できるようにしています。presigned URLで配信して、アプリ内のギャラリーで閲覧できる仕組みです。
公民連携のハードルは意外と「きっかけ」だけ
振り返ると、技術的なハードルよりも 「最初の一言を言えるかどうか」 のほうがずっと大きかった。
地方のDXって、APIの設計やAIの精度も大事だけど、「たまたま観光協会に寄ったら、たまたまその課の方がいた」 みたいな偶然を逃さないことのほうが大事なのかもしれません。
エンジニアの皆さん、地方で開発するなら、コワーキングスペースじゃなくて観光協会に行きましょう（半分冗談、半分本気）。
NanoBANANAでゲームビジュアルを量産した話 — ボツの山を越えて
なぜ画像生成AIを使ったのか
スタンプラリーアプリには、プレイヤーが選べるアバターキャラクターが必要でした。
- 男性武士、町娘、甲冑武士、金山の坑夫、商人、町人、旅人……
- それぞれスプライトシート（歩行アニメーション用の3コマ画像）が必要
- さらにマップのイラストやUIアイコンも
イラストレーターに発注する予算はありません（個人開発ですから）。かといって自分で描く画力もありません（半農半エンジニアであって、半農半イラストレーターではない）。
そこで NanoBANANA の出番です。kiro以外にオーダーするのは、コンテキストの節約と、餅は餅屋という発想でした。
大量のボツから「これだ！」を掘り当てる
NanoBANANAでの画像生成、率直に言って ボツ率がすごい です。
スプライトシートひとつ取っても、こんな感じでした。
生成した画像: たぶん200枚以上 まあまあ使えそう: 30枚くらい 実際に採用: 8キャラクター分
問題はいくつかあって。
- テイストの統一が難しい — 同じプロンプトでも毎回微妙に画風が変わる
- スプライトシートとして使えるか — 3コマの歩行アニメーションとして自然に動くかは生成後に検証しないと分からない
- 背景の透過処理 — 生成画像の背景を透過にする後処理が毎回必要
結局、「生成 → 選別 → 後処理 → テスト → やり直し」 を何十回も繰り返しました。
それでもAI画像生成を選ぶ理由
大量のボツを出しながらでも、NanoBANANAを使った理由はシンプルです。
ゼロから描くよりは圧倒的に速い。
完璧なイラストが一発で出てくることは期待してません。でも「だいたいこんな感じ」のイメージを大量に生成して、その中から選んで調整するワークフローは、個人開発者にとって現実的な選択肢です。
プロのイラストレーターの仕事を置き換えるものではないけれど、「予算ゼロの個人開発でもビジュアルを諦めなくていい」 のは、画像生成AIの確かな恩恵です。
ちなみにマップのイラストも同様のプロセスで作りました。デフォルメ地図のベースデザインをNanoBANANAで何パターンも生成して、良さそうなものを選んで手動で調整。こちらもボツの山でした。
グループモード — 小規模パーティでスタンプを奪い合え
「一人で歩くのも楽しいけど、みんなで競争したい」
スタンプラリーを何人かに使ってもらったとき、こんなフィードバックをもらいました。
「友達と一緒に回ってるのに、アプリ上では各自バラバラ。お互いの進捗が見えたら盛り上がるのに」
そこで グループモード を実装しました。
仕組み
1. リーダーがグループを作成 → QRコードが表示される 2. メンバーがQRコードを読み取って参加（最大10人） 3. 全員のGPS位置がマップ上にリアルタイム表示 4. スタンプ収集の進捗もリアルタイムで共有 5. 「あいつもう5個集めてる！急がなきゃ！」 6. 24時間経過 or リーダーが離脱 → グループ凍結
技術的なポイントをいくつか。
プログレスのリセット＆リストア
グループに参加すると、スタンプとキャラクターの収集状況がリセットされます。全員同じスタートラインから始める公平性のため。グループを抜けると、元のデータが復元されます。
これ、DynamoDBの設計がちょっと面倒でした。Single Table Designで GROUP#{groupId} をパーティションキー、MEMBER#{userId} をソートキーにして、参加時のスナップショットを保持。離脱時にリストアする仕組みです。
30秒ポーリング
メンバーの位置と進捗は30秒ごとにAPIで同期しています。WebSocketも検討しましたが、ECS Fargate最小構成で動かしてるので、ポーリングのほうがシンプルで安定。佐渡の電波事情を考えると、リアルタイム性よりも確実に動くことのほうが大事です。
色分けされたメンバー表示
10人まで参加可能で、各メンバーには固定のカラーパレットから色が割り当てられます。マップ上でアバターの色が違うので「あ、あの青い人もうあそこまで行ってる！」が一目で分かる。
少人数だから面白い
このグループモード、大規模MMOを目指しているわけじゃないんです。家族4人とか、友達グループ5〜6人とか、小規模パーティで盛り上がるための機能です。
観光地のスタンプラリーって、結局は「一緒に歩いてる人と共有する体験」なんですよね。技術的にはシンプルでも、「お互いの位置が見える」だけでゲーム性が一気に上がりました。
ECSの課金が月200ドルを超えた日 — そしてLambda移行の修羅場
個人開発者のAWS課金事情
ここからはスタンプラリーアプリそのものの話ではなく、個人開発者としてのインフラ運用の話です。
スタンプラリーアプリ以外にも、ECS Fargateで動かしている個人開発アプリが2件ありました。合計3件のECSサービスが常時稼働。
ある月のAWS請求書を見て、血の気が引きました。
月額200ドル超え。
ECS Fargateは「使った分だけ」とはいえ、タスクが常時起動していれば24時間365日課金されます。0.25 vCPU / 0.5GBの最小構成でも、3件動かせばそれなりの金額になる。半農エンジニアのお小遣いには厳しい。
急遽2件をLambdaベースに移行
スタンプラリーアプリはそのままECSに残しましたが、残り2件のアプリを ECSからLambdaベースのAPI に急遽移行することにしました。
この移行作業を Kiroの3セッション同時稼働 でやったんですが、これが想像以上にキツかった。
Kiro 3面同時稼働で学んだこと — 人間がボトルネックになる話
脳のリソースとヒットポイントが削られていく
Lambda移行の2件 + スタンプラリーの機能追加。3つのKiroセッションを並行して走らせました。
各セッションがスペック駆動で設計→タスク→実装を進めてくれるので、AIの生産性は高い。問題は 人間側 です。
セッション1: 「設計レビューお願いします」 セッション2: 「テスト失敗しました、方針を確認させてください」 セッション3: 「タスク3の実装が完了しました。次に進みますか？」 人間（僕）: 「えーっと、セッション1の設計は……あれ、セッション2のコンテキストと混ざった……」
脳のリソースとヒットポイントがどんどん下がっていく感覚をリアルで味わいました。
RPGでいうと、パーティメンバー（AI）は元気いっぱいなのに、プレイヤー（人間）のMPがゼロになって全滅する感じ。技術的な問題じゃないんです。純粋に 人間の認知リソースが足りない。
技術よりも大事だった気づき
この経験で得た気づきは、技術云々よりもずっと本質的なことでした。
「疲弊しないでAIを使って作業をするには、休憩を適切に入れるとか、作業との距離感がすごく重要」
AIが高速に成果物を出してくれるからといって、人間も同じペースで承認・判断・コンテキストスイッチを続けられるわけじゃない。むしろAIが速いぶん、人間の判断待ちが連続して、脳が休まる暇がない。
人によっては、マルチタスクが過ぎて心身の不調をきたすかもしれません。これはAI利用のネガティブな側面として、もっと語られるべきだと思います。
「人に優しい生成AI」があってもいいんじゃないか
ここからは僕の願望みたいな話です。
Kiroのスペック駆動開発は素晴らしいんですが、細かい承認・確認がユーザーに求められる場面が多い。もちろん品質担保のためには必要なんですが、3セッション同時に回していると、確認の嵐で人間が疲弊する。
僕が欲しいのはこういう仕組みです。
「明確なチェックポイントをこちらが指定して、そこまではノーチェックで進めてくれる」
システム開発をAIと協業するなら、生体部品としての人間がボトルネックになるのは当たり前なんです。そこを尊重する仕組みが欲しい。
たとえば「設計フェーズが完了したら声かけて。タスク分解と実装は任せるから、テストが全部通ったらまた声かけて」みたいな粒度で制御できたら、人間の認知負荷はぐっと下がるはず。
セッション引継ぎの精度問題
Kiroでは、セッションのコンテキスト消費が一定量に達すると、次のセッションへの引継ぎが行われます。この仕組み自体はありがたいんですが、引継ぎの精度にはまだ改善の余地がある。
「さっきのセッションで話してた設計方針、引き継がれてなくない？」みたいなことが時々起きる。Steeringがあるので致命的にはならないんですが、微妙なニュアンスや「この方針でいこうと合意した」という経緯が落ちることがある。
ローカルに作業履歴を持てたら
理想を言えば、ローカルでSQLiteなどを動かして、そこに作業履歴を保存し、セッション引継ぎの際にそれを活用するような仕組みが欲しい。
セッションごとに消えるコンテキストではなく、永続化された作業ログ。「前のセッションでこのファイルをこう変更して、この方針で合意した」という情報が、次のセッションにそのまま引き継がれる。
……とはいえ、ここは完全に他力本願です。こういった「おそらく誰しもが感じる不便」は、どこかの有能な方が作成し、デファクトになるまで待つスタンスです。はい、ずるい大人なので。
Gitに生成AIの作業履歴を保存する方式もいくつか出てきていて、「どうすっかな、なに使おっかな」と検討中ではあるんですが。正直、まだ決め手に欠けるというのが本音です。
まとめ — 機能は増えた、でも一番の学びは「人間の限界」だった
ブログ第1弾からの進化
| 追加した機能 | ポイント |
|---|---|
| 古文書の活用 | 市所蔵の絵巻をアプリに組み込み。偶然の出会いから公民連携へ |
| ビジュアルデザイン | NanoBANANAで8種のアバター＋マップデザインを量産（ボツの山） |
| グループモード | 最大10人でリアルタイム対戦。GPS位置と進捗を30秒同期 |
| ECS→Lambda移行 | 月200ドル超えの課金対策で2アプリを移行（他のプロダクトだけど） |
技術を超えた学び
| テーマ | 気づき |
|---|---|
| 公民連携 | ハードルは技術じゃなくて「最初の一言」 |
| AI画像生成 | ボツ前提のワークフローが個人開発を支える |
| AI協働の疲弊 | 人間の認知リソースがボトルネック。休憩と距離感が大事 |
| セッション管理 | 作業履歴の永続化が今後の課題 |
前回のブログでは「地方の観光課題にAI×クラウドは効く」と書きました。それは今も変わりません。
でも今回付け加えたいのは、「AIと協働する人間側のキャパシティを意識すること」 です。AIの生産性が上がれば上がるほど、人間がついていけなくなるリスクがある。技術の進化と同じくらい、「人間がどこまでやるか」のデザインが重要になってくる。
Kiroのスペック駆動開発は、設計→実装のプロセスを構造化してくれます。その構造化の次のステップとして、「人間の介入ポイントを最適化する」仕組みが進化してくれたら——3セッション同時稼働でもMPが枯渇しない未来が来るかもしれません。
世界遺産の島から、疲れた脳を田んぼの風で癒しつつ。3月はまだ寒いから冷え切ってしまいマスが！（wwww）🌾⛏️🧠
