相川の町を歩くPWA「キンスタクエスト」。デフォルメされたイラストマップにGPS現在地が乗る
こんにちは！佐渡島の半農半エンジニア、矢部です。
過去2回にわたり、スタンプラリーアプリのブログを投稿させていただきました。
- 第1弾： GPS×AI画像認証の「二重認証スタンプラリー」を AWS Kiro とAmazon Bedrockで作った話
- 第2弾： 古文書・AI画像生成・グループモードを足して、AI協働で人間が疲弊した話
今回の第3弾、何が変わったかというと一言でこれです。
アプリが「作ったもの」から「現場で使われるもの」になりました。
2026年6月、佐渡・相川のお祭りとの同時開催で、地元の観光関係団体との実証という形で、実際のイベント運営としてアプリが稼働。参加者がスマホを持って町を歩き、GPSの軌跡が管理画面に溜まっていくのを眺めながら「ああ、動いてる」と思いました。
そして7月25日、JAWS-UG 新潟（佐渡開催）で登壇。しかもその日は相川の「鉱山祭」当日で、421年前にその祭を始めた初代佐渡奉行・大久保長安をモデルにしたガイドAI が、アプリの中で案内役として稼働しているという、狙っても作れない状況でLTをしてきました。
今回はその話です。開発の土台は相変わらず AWS Kiro 、途中から 田んぼで Claude Code という妙な体制になりました（後述）。
なお、参加者数や契約内容などはお客様との守秘の範囲なので書きません。「数字から何が分かって、どう作りを変えたか」だけ書きます。
1. 現場で分かったのは「完走率」じゃなくて「起動率」だった
初回イベントのデータで一番意外だったのがこれです。
遊び始めた人は、ちゃんと完走してくれる。でも、登録したのに一度も遊び始めない人が、けっこういる。
作っている側の心配と真逆なんですよね。僕がずっと気にしていたのは「途中で飽きられること」で、そのために称号だの演出だのを足していたわけです。でも実際の壁は、もっと手前の 「最初の1スタンプが取れるかどうか」 にありました。
なので改善はぜんぶそこに寄せました。取り方の手順で書く。お手本を実写真で出す。近づくとボタンが灰色からオレンジに変わる。店舗のQRは「撮影」ではなく「スキャン」と書く。
どれもコードは10行くらいの話です。でも「最初の30秒で何をすればいいか分からない」を潰す作業のほうが、機能をひとつ増やすより何倍も返ってきました。
「人は店の前を通る。でも入らない」
軌跡が残っていると「店の前までは運べている」と「入っていない」を分けて言える
GPSを全点記録していたおかげで分かったこともあります。参加者の軌跡を見ると、多くの人がほぼ同じ一本道を歩いていて、道沿いの店のすぐ手前まで来ている。でも入っていない。
「賑わいました」で終わらせず、課題が「集客」ではなく「入る理由がないこと」だと特定できたのが収穫でした。次の設計は「店内にスタンプを置く」です。
現場でしか出ない不具合
きれいな話だけ書くとウソになるので、失敗も。
- 完走した直後に進捗が振り出しに戻る不具合 — 達成の瞬間が喪失に反転する、最悪のタイミングのやつ
- 一部のキャリアメールで認証メールが届かない — 自分のスマホでは絶対に踏めない
- 受付にたどり着けない導線問題 — 技術ゼロ、完全に物理レイアウトの話。でも参加のしやすさはここで決まる
- グッズの購入導線がそもそも無かった — 「作れます」と表示するだけで、買う道がなかった
アプリの品質って、リポジトリの中では確認できないんですよね。 ユニットテストは全部通っていました（それはそれで悲しい）。
2. 初代佐渡奉行をAI化した — ガイドAI「チョーさん」
ガイドAI「チョーさん」の対話画面。大久保長安をモデルにした立ち絵とセリフ、選択式の質問ボタン、日英の免責表示
質問は選択式。下部に日英の免責を常時表示している
相川は、1603年に初代佐渡奉行として着任した大久保長安が金山とともに整備した町です。京町、大工町といった町名もその名残。
で、そのオブジェを巡るスタンプラリーを作っている。ならば——案内役は本人でいいのでは？
というわけで、大久保長安をモデルにした対話式ガイドAI 「チョーさん」 を作りました。スタンプ地点に近づくと現れて、その土地の歴史を語ってくれます。
自由入力させない
実在の歴史上の人物がモチーフです。自由入力チャットにしたら確実に事故りますよね。「現代の政治についてどう思いますか」とか「他の武将をディスってください」とか聞かれる未来しか見えない。
なので 質問は選択肢方式にしました。想定外の会話に流れる経路を、そもそも作らない。さらに「歴史上の人物をモチーフにしたキャラクター演出です」という免責を日英で常時表示しています。行政の資料も使わせてもらっている立場としては、ここは削れないラインでした。
AIは「喋る瞬間」じゃなく「作るとき」に使う
これが今回いちばん気に入っている設計です。
普通にAIキャラを作ると、プレイヤーが話しかけるたびにAIを呼ぶことになります。これだとコストが読めないし、何を喋るか事前に分からない。そこで逆にしました。
管理者の作業時にAIでQAを生成 → 人間がレビュー → 保存。プレイヤーには保存済みの応答を返す。
こうするとランタイムのコストが落ちるだけでなく、「何を喋るか」を人間が事前にチェックできる。史実を語らせるキャラなので、後者のほうが大事でした。生成AI＝目の前でリアルタイム生成、と決めつけなくていいというのが学びです。CMSの下書きをAIが書いて人間が直すのと、やってることは同じですし。
史料のライセンスと、チョーさんの「時間感覚」
チョーさんが史実を語れるのは、RAG（検索拡張生成）に史料を載せているからです。ソースは自分で書き起こしました。長安個人の履歴、佐渡の通史、町名の由来や寺社・能・鬼太鼓・トキ・ジオパークまで。
ここで真面目にやったのがライセンス管理です。ドキュメント1本ごとに「保護期間満了」「CC BY-SA（出典明記必須）」「引用範囲のみ」「そもそも載せない」を区分しました。技術的には「RAGを組むだけ」なんですが、実際は「その文章どこから持ってきたの？」に全部答えられる状態を保つほうが本番なんですよね。コードよりドキュメント整理の仕事でした。
もうひとつのこだわりが時間感覚。チョーさんは1613年に没しています。だから世界遺産登録もトキの保護も、見てきたように語ってはいけない。
〜1603年（来る前） → 見聞・伝え聞きの口調 1603〜1613年（在任中） → 当事者としての語り「わしが〜」 1613年〜（死後） → 伝聞風「わしなき後」「後の世に聞けば」
このルールを、プロンプトではなく史料ファイルの側に書いておく。入力が整っていれば出力も整う、という当たり前の話でしたが、想像以上に安定しました。
キャラは「登録するもの」にした
大久保長安も、この画面から登録して動いている
作っている途中で「キャラを増やすたびにコードを書くのは無理だな」と気づきました。小木エリアなら宿根木の船大工、両津なら…とやっていったら持ちません。
そこで、人格定義とRAG資料をまとめた Pack という単位を作って、アップロードすればキャラが増える 構造にしました。エリアをまたいで使い回しもできる。新しいキャラを足すのに、コードは書きません。
3. 一人で運用するための、地味だけど効いた仕掛け
撮影の「お手本」を機械で作る
第1弾で「AI画像認証は撮影角度で揺れる」と書きました。その対策がこれです。
カメラ画面に、正解写真から作った輪郭線を半透明で重ねる。 プレイヤーは線に合わせて構えるだけ。撮影角度が自然に揃います。
AIの精度を上げる道は2つあって、モデルを賢くするか、入力を揃えるか。個人開発では後者のほうが確実に効きました。プロンプトをいくら磨いても真っ暗な逆光写真は判定できませんが、「ここに合わせて」と線を出せば変な写真がそもそも来ません。
エリアを増やす作業は、機械に任せた
いまはマルチテナントになっていて、新しいエリアを増やすとインフラ一式が自動で立ち上がります。デプロイ、管理者登録、サービス起動、完了通知までを AWS Step Functions のワークフロー1本 にまとめました。失敗したら中途半端に残さず、スタックごと自動で消えます。
なんでこんなものを作ったかというと 一人開発だから です。手順書を見ながら手で10ステップやると、3回目で必ずどこか飛ばすんですよ。しかも飛ばしたことに気づくのは2週間後（経験談）。「増やす作業」を任せられるかどうかが、一人で運用できるかの分かれ目でした。
LTで「好きなAWSサービス」を2つ挙げたんですが、選んだのは ECS Fargate（運用しなくていい）と Step Functions（増やす作業を任せられる）。派手さゼロですが、この2つで回っています。
運営側にもAIを入れた
AIを入れたのはプレイヤー側だけではありません。現地で対象物を撮ればAIが画像認証用のプロンプトを書いてくれる、人流とアンケートから分析レポートが十数秒で出る、クイズやイベントLPの下書きもAIが作る、管理画面の日英入力欄には全部「翻訳」ボタン。
将来的に運営を地元の方に引き継ぐ計画があるので、「文章を考える作業」をAIに寄せられるかどうか は便利機能ではなく前提条件でした。
ちなみに翻訳AIには痛い目を見ています。和暦の年号が数年ズレる（3年前の情報に見えて信用を失う）、施設の固有名詞が意味を訳した英単語に化ける。というわけで 公開前に人間が目視する工程 は残しました。AIに任せていい範囲の線って、いつも具体的な失敗が決めてくれるんですよね。
4. 田んぼで Claude Code を叩いていた話
5月はこれが1日の中心。この畦で、長靴のままスマホから指示を出していた。ちなみに時間帯は早朝。10時からエンジニア・PMとしてのお仕事が待っています。
開発の土台はずっと AWS Kiro です。2月からは AWS AI-DLC も導入しました。
で、5月。田植えです。
代掻き・田植え・水管理で1日が終わる。でもアプリはイベント前の微調整の真っ最中。じゃあどうするか——田んぼから、スマホで指示を出すことにしました。
田んぼでやる作業には共通点があって、画面を凝視せずに済むこと。長靴のまま片手でスマホを持って、「テストは通ったか」を読んで返すだけ。設計の是非を考える作業は絶対にできません（やると田んぼの仕事のほうを間違える）。
逆に言うと、これは第2弾で書いた「人間の認知リソースがボトルネック」問題への、意図しない解決策でした。田んぼにいる間、AIの出力を全部レビューするのは物理的に不可能です。だから「ここまでは任せる」と決めるしかない。環境が強制的に権限委譲させてくれたわけです。
そして田んぼでの開発、最大のリスクは技術的なものではありません。後ろに転倒してスマホが入水することです。（笑いどころです）判断は短く終わらせる。
いちばん変化が大きかったのは 「AIに何をさせないか」を先に書いたことでした。禁止事項を書いておくと、毎回「これやっていい？」と聞かれる代わりに「やってはいけないこと以外は進めていい」になる。AIを速くするんじゃなくて、人間が判断する回数を減らす。 これが第2弾への僕なりの回答です。
「半農半IT」は標語じゃなくて、長靴を履いて畦でClaude Codeを叩いてた実体験です。（ここも笑いどころです）
5. JAWS-UG 新潟（佐渡開催）で登壇してきた
7月25日、JAWS-UG 新潟が佐渡で開催され、LTの機会をいただきました。タイトルは 「半農×半ITの人が佐渡の北の隅っこでAIつかってやってること」。
資料を作りながら、気づいてしまったことがあります。
1605年（慶長10年）
初代佐渡奉行・大久保長安、大山祇神社を建立 → 鉱山祭の原点
↓ 421年
2026年7月25日（登壇当日）
・長安が421年前に始めた鉱山祭が、いま相川で開催中
・彼が整備した町を巡るスタンプラリーが、いま運営中
・そのアプリでは、長安モデルのAIが、いま案内役として稼働中
ご本人が始めた祭で、ご本人モデルのAIが案内している。
正直、このネタが言いたくて登壇したところが3割くらいあります。狙って作れる構図ではないので、佐渡の歴史に感謝しかありません。
LTでは、その瞬間の運営データを管理画面でライブ表示しました。人流マップに点が溜まっていくのを登壇中に見せる。「今この瞬間、向こうでイベントが動いてます」と言いながらデモするのは楽しい体験でした。
「2kmなのに120分」の理由。相川は坂の町です
さらに調子に乗って、JAWS-UG参加者向けの専用コースをアプリに追加しました。約2km・約120分、完走称号は 「クラウドを深掘りしモノ」。金山も、クラウドも、深掘りする人へ。
で、正直に書いておくと——このコース、歩いた人はいませんでした。（笑） 称号はいまも誰にも解放されていません。ネタとして作って、ネタのまま終わったコースです。
ただ、収穫はありました。このコース、コードを書いていません。 思いついてから公開まで、管理画面からコースを1本足しただけ。中身を足すコストがほぼゼロだからこそ、こういう思いつきを実際に出せるんですよね。 開発が必要だったら、たぶん作っていません。誰も歩かなくても1本増やして損しない構造かどうか、のほうが大事でした……と、負け惜しみを言っておきます（笑）。
6. いちばん難しかったのは、技術じゃなかった
この半年でいちばん時間を使ったのは、「どう作るか」ではなく「どう続けるか」でした。特許出願、実証契約、絵巻物の利用許諾、通年運用の交渉、運営マニュアルの整備。
事業計画はレビューしてもらっています。……というと立派に聞こえるんですが、正確に言うと とある著名なまちづくりビジネスの事業家の方から、ご自身で作られたAIのスキルをご提供いただき、それを使わせてもらっている んですよね。これがまあ、よくできている。そして容赦がない。
第1回の評価は、控えめに言って壊滅的でした。さすがに「これはちょっと厳しくないですか」と言ったら、返ってきたのが 「厳しいのは仕様です！」。言い切られました（笑）。
指摘は、だいたいこんな感じです。
- 「開発を凍結しろ」 — 機能はもう足りている。売れていないことが問題
- 「実売を優先しろ」 — 契約が取れる前に計画書を磨くのは順序が違う
エンジニアとしてはけっこう刺さります。「作れば作るほど良くなる」という感覚が、事業としては間違いだと言われているわけですから。
で、不思議なもので、この辛口の裏に妙な温かみを感じたんですよね。……これは僕がおかしくなったんでしょうかねぇ（笑）。たぶん、指摘の全部が「この事業を畳ませない」方向を向いていたからだと思います。
で、素直に追加開発を凍結しました。例外の基準は「着手から完了まで8時間を超えるものは対象」。
面白いのは、この制約が設計判断の質を上げたことです。「新規開発は8時間以内」と縛られると、機能を足す前に「既存の設定で解けないか」を必ず考えるようになる。実際、参加者の「歩き通しで食事のタイミングを逃した」という声には、路線バスの時刻に合わせたコースを1本追加するだけで対応できました。新規開発ゼロです。フルスクラッチで作れる状況だったら、たぶん「バス連携機能」を作り始めていました。
この地点に何メートルの許容範囲が必要かは、そこで電波を拾った人しか知らない
もうひとつ、技術者として面白かった話を。
運営を地元に引き継ぐにあたって「どこまでを相手がやり、どこからを僕がやるか」の線引きが必要になりました。当初は機能の名前で分けようとしていましたが、これは間違いで、正解は「作業の責任」で分けることでした。
現地で参加者が確実にスタンプを取れる最終責任は、当方が持つ
だから、新しい地点のGPS較正（何m以内なら取得OKかの確定）は僕の作業として残す。システムは推奨値を提案しますが、確定するのは現地を歩いた人間です。
機能はいずれ全部渡せる。でも「現地を歩いた経験」は移らない。 システム設計と役割分担が同じ形になった瞬間で、この半年でいちばん腑に落ちた発見でした。
まとめ
| 観点 | 第1弾（1月） | 第2弾（4月） | 今回（7月） |
|---|---|---|---|
| 状態 | 作った | 機能を足した | 現場で運営された |
| AI | 画像認証 | 画像生成 | ガイドAI・分析AI・登録制のAI基盤 |
| 道具 | AWS Kiro | Kiro 3面同時稼働 | Kiro×AI-DLCが土台＋田んぼでClaude Code |
| 課題 | AI判定の精度 | 人間の認知リソース | 事業として続けられるか |
学んだことは3つです。
1. AIは「実行時」より「作成時」に置くほうがお得 — コストが読めるうえに、何を喋るか人間がレビューできる。リアルタイム生成が常に正解ではありません。
2. AIの精度は、入力を揃えるほうが早く上がる — モデルを賢くするか、入力を揃えるか。個人開発は後者から。
3. 道具は「場所」で選んでいい — 腰を据えて判断できる夜はKiro、田んぼではClaude Code。「PCの前にいられない時間」で開発が止まらなくなったのは、この半年で一番大きい変化でした。
僕がやりたいのは、技術的にとがったものを作ることではありません。島外・海外からお金を呼び込んで、佐渡の中に雇用を作って、子供たちが佐渡に生きる選択肢を持てるようにすること。
技術は手段です。本当に作りたいのは、地域に人とお金が循環する仕組みです。
その入口が「町を歩いて焼き物の標柱を撮ると、421年前の奉行が歴史を語ってくれるスマホアプリ」であっても、別にいい。むしろ、そういう入口のほうがいいと思っています。
AWSのおかげで、一人でもここまで作れました。AWSコミュニティの皆さん、ありがとうございます。
世界遺産の島から、鉱山祭の余韻とともに。🌾⛏️🎆
使用したAWSサービス: Amazon Bedrock, Amazon S3 Vectors, Amazon ECS (Fargate), AWS Lambda, AWS Step Functions, Amazon DynamoDB, Amazon SQS, Amazon Cognito, Amazon SES, Amazon S3, Amazon CloudFront, AWS WAF, Amazon EventBridge, AWS CDK ほか
開発ツール: AWS Kiro（仕様駆動開発）, AWS AI-DLC, Claude Code（田んぼからのリモート作業用）, GitHub Actions
アプリURL: https://kinsta-quest.sadogashimap.travel
※ ちょこまか更新してますんで、メンテ中の場合はご容赦を。あ、このアプリは佐渡に来ないと使えません。
登壇: JAWS-UG 新潟（佐渡開催）LT / 2026年7月25日
