連載「YOKOSO PAY の舞台裏」第 2 回

YOKOSO PAY の開発体制AI ネイティブな DevOps で、速く、確かに出す

合同会社Techno Vision AO ・ 公開 2026 年 10 月 25 日

はじめに

合同会社Techno Vision AO は、町おこしのプラットフォーム「YOKOSO PAY」を作り、運営しています。第 1 回ではシステムの構成を紹介しました。

第 2 回は開発体制です。受託開発や技術の提携を考えている IT 事業者・エンジニアの方に向けて、どんな考え方で、どんな仕組みを使い、その結果どうなっているかを紹介します。

YOKOSO PAY は、少人数で開発から運用・営業までを回しています。開発は、ほぼ 1 人のエンジニアと AI のエージェントです。それでも速く、雑にならずに作れるのは、やり方を人の頭の中に置いていないからです。コードと同じ場所 (Git のリポジトリ) に、開発の決まり・開発環境の作り方・設計の判断・インフラの設定・テストまで書いて残しています。受け取った人は、やり方まで丸ごと引き継げます。だから、人が増えれば、そのまま同じ品質で広がります。

開発体制の全体像

AI ネイティブ開発: エージェントを並列で動かす

ねらい開発の手を AI のエージェントで増やし、人は「何を作るか」と「それが正しいか」の判断に集中する。少人数でも、何本もの作業を同時に進める。

仕組み

• コーディングエージェント開発の手は Claude Code です。実装、テストを書くこと、画面を確かめて撮ることまでを受け持ちます
• 並列開発 (git worktree)1 つの作業に 1 つの worktree を割り当て、エージェントを同時に何本も動かします。worktree ごとに Docker Compose のスタック (画面・API・データベースのエミュレータ) を立て、ポートと開発用のデータベースを分けているので、互いにぶつかりません
• 開発環境のコード化worktree を作るスクリプト、エージェントへの指示書、Claude Code の設定、ブラウザを操作する MCP の登録まで、リポジトリに入れています。秘密 (API の鍵など) だけは置かず、起動するときに Secret Manager から渡します
• 指示書 (CLAUDE.md)約 500 行の指示書に、決まりとその理由を書いています。AI はコードから「なぜそうしたか」を読めないからです。起きた失敗も書き足します。例えば、このリポジトリでは tsc --noEmit が 0 ファイルを検査して必ず通るので、型の検査は npm run build で行う、という決まりです。設計の判断は ADR (設計の判断の記録) に残します

効果何本もの作業を同時に進め、main への取り込みは直近 3 か月で 540 件あまり (1 日あたり 6 件ほど) になっています。新しく加わった人も、リポジトリを取ってスクリプトを流せば、同じ環境・同じ決まりで、その日から作業を始められます。

CI/CD: いつでも安全に出せる状態を保つ

ねらい変更を小さく分けて毎日取り込み、いつでも本番に出せる状態を保つ (継続的インテグレーション・継続的デリバリー)。まとめて大きく出すより、壊れたときに原因を絞りやすく、戻すのも速い。

仕組み

• PR ごとの CIGitHub Actions が、型・テスト・データのルールなどを検査します (中身は次の「シフトレフト」で)
• PR ごとのプレビュー環境PR ごとに Cloud Run に確認用の環境を作り、変更を実際の画面で試します
• demo への自動デプロイmain に入ると、インフラの設定と一緒に、確認用の環境 (demo) へ自動でデプロイします
• リリースゲート本番に出すのは、リリースする版で結合テストの全件が通っているときだけです

出し方は、変更の大きさで分けています。 少人数なので、開発に集中する期間と、お客様のところへ導入・営業に出る期間を分けて回しています。

• 新しい機能demo で検証会を通し、確かめ終わってからまとめて本番に出します。決済やお店の運営に関わるので、すぐ出すことより、確かめてから出すことを優先します。9 月 12 日のリリースには、それまでに作って検証した 300 件あまりの変更が入りました
• 改善と修正小さく分けて、すぐに出します

効果開発の速さと安定を測る 4 つの指標 (DORA の指標) で見ると、次のとおりです。

今は、速さの 2 つ (デプロイの頻度・変更のリードタイム) を測っています。安定の 2 つは、利用がまだ少なく、障害の件数が少なすぎて割合や時間に意味が出ないので、利用が増えてから測ります。

シフトレフト: 不具合を、早い段階で止める

ねらい不具合は、見つかるのが後になるほど、直すのに手間がかかる。だから、なるべく早い段階で機械が止める (シフトレフト)。止める場所 (品質ゲート) を決めておけば、人の注意に頼らずに済む。

仕組み: 品質ゲートを 3 か所に置いています。

1. コミットの前 (Claude Code の hooks)

エージェントがコミットするときは、その前に 6 本の検査が走ります。1 本でも外れると、コミットそのものができません。

• ESLint
• 11 言語の翻訳のキーの抜け
• 鍵やパスワードの混入
• Firestore の複合インデックスの抜け (クエリのコードから必要なインデックスを抜き出し、定義とずれていないか)
• 売上の画面どうしで、手数料の数字が食い違わないこと
• 体験版の入口が、サーバの決めた行き先をすべて受け取れること

最後の 2 本は、実際に起きた失敗から作りました。手数料の数字は画面ごとに計算していたため、1 つの画面で書き忘れると、そこだけ数字が食い違いました。目で見比べても気づきにくいので、機械で止めています。一度起きた失敗は、検査にして二度と起こさないようにしています。

2. PR (GitHub Actions)

• 型・ESLint・ビルド画面のアプリ 3 つ (React + Vite)
• Firestore のセキュリティルールのテスト画面から直接読めてはいけないデータが、読めないこと
• 結合テスト (pytest)エミュレータではなく、CI 専用の本物の Firestore を相手に通します。CI 用のデータベースはプールにしてあり、実行ごとに 1 本を借りるので、同時に走る CI どうしがデータを踏み合いません
• 変えた機能だけを、分けて並べて回す変えたドメインに関わる結合テストだけを選び、ジョブに分けて同時に走らせます。PR の待ち時間は 15 分を予算にし、超えたら CI が自分で記録に残します
• 機能の区切りドメインどうしの直接の import は、ESLint と pytest で止めます (モジュラーモノリス)
• インデックスの定義クエリのコードを AST で読んで定義を生成し、手で書いた定義とずれたら止めます
• 依存の固定Python はハッシュ付きのロック (pip-compile)、Docker イメージは digest まで固定します。更新は Dependabot が出し、公開から 7 日経った版だけを取ります

3. 本番の前

• リリースゲートリリースする版で、結合テストの全件が通っていること
• 鍵の取り違え決済 (Stripe) の本番用の鍵を、反映する前に 3 段階で確かめること

止まったら、エージェントが自分で直す

hooks は、止めるときに理由と検査の出力をエージェントに返します。CI で落ちたときも、エージェントがログを読みます。エージェントは理由を読んで直し、もう一度通します。このフィードバックループは仕組みとして組んであるので、AI のモデルが新しくなるほど、同じ仕組みのまま、見つけて直せる範囲が広がっていきます。

効果不具合は、本番に届く前に、コミット・PR・リリースのどこかで止まります。止まった理由を人がいちいち伝えなくても、エージェントが通るまで直します。

Infrastructure as Code: インフラも、コードと同じ流れで

ねらいインフラの設定を画面で手作業で変えると、誰が何を変えたかが残らず、同じ環境を作り直せない。インフラもコードにして、変更をレビューし、いつでも同じものを作れるようにする。

仕組み

• TerraformGoogle Cloud の構成 (Cloud Run・権限・秘密の置き場・定期処理・監視など) を Terraform で書いています
• PR に planインフラを変える PR では、何が変わるか (plan) を PR にコメントで書き出します
• apply してからデプロイdemo は main に入るたびに Terraform を apply し、そのあとでデプロイします。apply に失敗したら、デプロイも止めます
• drift の検出Terraform の定義と、実際の構成とのずれを、demo と本番の両方で毎晩検査します

効果設定の入らないままコードが動く、ということが起きません。実際に、新しい仕組みの権限の設定が足りないまま main に入ったとき、apply が止まり、デプロイも止まりました。権限を足して流し直すまで、設定の無い新しいコードは動きませんでした。

テスト戦略: 変更で、今まで動いていたものを壊さない

ねらい速く作るほど、ある変更が、今まで動いていた別の機能や、前に直した不具合を、知らないうちに壊しやすくなる。テストを層に分けて置き、変更のたびに自動で確かめる。直した不具合は必ずテストにして、同じ不具合を二度と起こさない。

仕組み

• テストピラミッド計算や判定は単体テストで細かく確かめ、決済や返金の流れは結合テストで通します。細かいテストを多く、流れのテストを要所に置きます
• 回帰テスト不具合を直すときは、その不具合を再現するテストを足します
• トレーサビリティAPI のテストのファイルは約 400 あり、そのうち約 100 は、直した課題の番号をファイル名に付けています。後から「なぜこのテストがあるのか」を辿れます
• 否定系のテスト権限の無い操作や不正な入力が、確実に止まることも確かめます

効果一度直した不具合が、別の変更で静かに戻ってくることを、テストが止めます。テストが落ちたとき、何を守るためのテストだったかを、課題まで辿れます。

証跡 (エビデンス): 「確かめた」を残す

ねらいテストが通っても、画面が正しく見えるとは限らない。画面に関わる変更は、実際に動かして確かめ、その証拠を、レビューする人も後から振り返る人も見られる形で残す。

仕組み

• MCP で撮るエージェントが MCP や Playwright でブラウザを操作し、変えた範囲の画面を実際に動かして撮ります。うまくいくところだけでなく、権限の無い操作や入力の誤りが止まる画面も撮ります
• コミットを指定して貼る撮った画像はリポジトリに入れ、PR の本文に、コミットを指定した URL で貼ります。ブランチを消したあとも、同じ画像を見られます
• コンソールも見る見た目が正しくても、裏でエラーが出ていることがあります。console.error・画面の例外・サーバの 5xx を数え、0 件であることも確かめます

コンソールを見る決まりは、実際の失敗から作りました。以前、ある一覧の画面では、データの取得に失敗したときに空の一覧を出していたため、サーバで失敗が起きても画面には「0 件」と出るだけで、誰も気づけませんでした。今は、確認用の環境ではサーバの失敗を画面の下に赤い帯で出し、確かめる側からも塞いでいます (本番では出しません)。

効果これまでに残した画面の証跡は約 2,300 枚です。レビューのときも、半年後に振り返るときも、同じ画面を見て判断できます。

ヒューマン・イン・ザ・ループ: AI の誤りを、人が止める

ねらいAI は、コードとしては正しくても、商売としては間違っている変更を、自信を持って出すことがある。AI に任せる範囲と、人が責任を持つ範囲を分け、最後は人が判断する。

仕組み

• 急所を決める間違えると、気づかないうちにお金・信頼・法的な立場を傷つける場所 (料金や手数料の計算・決済の状態の移り変わり・権限・返金・法律や規約に関わる決まり) を「急所」と決め、人が必ず見ます。急所は純粋な関数や状態の遷移表として 1 か所にまとめ、人が見る範囲を小さくしています
• AI のレビューは、危険度で使い分けるPR の前の AI のコードレビューは、すべての PR にはかけません。お金が動くコードや認証・権限には深くかけ、画面の調整や文書にはかけません
• 指摘が集中したら、直すのをやめるレビューの指摘が同じ場所に集中したら、2 周目は直しません。同じ値の周りで毎回新しい指摘が出るのは、「その値の定義が決まっていない」という合図です。先に定義を書き、定義からテストを書き、最後にコードを合わせます
• プロダクト検証会最後は、開発とは別のメンバーが、テーマごとに実機で確かめます (次の「アジャイル」で)

効果AI の速さを使いながら、お金や権限に関わる判断は人が持ちます。AI の変更で急所のテストが破れたら、それが人に判断を回す合図になります。

アジャイル: 使う人の声で、短い周期で直す

ねらい作ったものを、使う人の目で早く確かめ、見つかったことを短い周期で直していく。

仕組み: テーマごとに「プロダクト検証会」を開き、開発とは別のメンバーが、機能が仕様どおりに動くか、お客様やお店にとって操作しやすいかを、実機で確かめます。見つかった不具合や要望は記録し、次の流れで最後まで追いかけます。

• いま誰が持っているかを決めるどの件にも「次に動く人」を 1 人決め、宙に浮く件を作りません
• 優先度の食い違いを話し合う見つけた人の希望と、決まった優先度が違う件は一覧に出し、理由を伝えます
• 数を毎月見る月ごとに、記録した数と閉じた数を数えています

効果2026 年 8 月から 10 月までの約 10 週間で、検証会を 29 回開きました。見つかった改善や修正は、小さく分けてすぐに本番に出します (上の「CI/CD」の変更のリードタイム)。

あえて採らなかった判断

すべての変更を、取り込んだらすぐ本番に出す

継続的デプロイ (取り込んだら自動で本番に出す) は採っていません。決済やお店の運営に関わるので、新しい機能は demo で検証会を通してから出します。改善と修正は小さく分けてすぐ出し、新しい機能は確かめてから出す、という使い分けです。

PR ごとに、全件のテストを回す

テストが増えるにつれて、PR のたびに全件を回すと、待ち時間が延びていきました。待ち時間が長いと、確かめる回数が減り、かえって雑になります。そこで、PR では変えた機能に関わる結合テストだけを回し、全件は main で定期的に回し、さらにリリースする版で全件が通っていることを本番の前に確かめます。速さと確かさを、回す場所で分けています。

画面の E2E を、CI で回す

Playwright の E2E は 165 本ありますが、CI では回していません。見た目の比較 (VRT) の差分のノイズが多く、毎回の実行の量に見合わなかったためです。代わりに、変えた範囲の E2E を手元で回し、証跡とコンソールの検査で確かめています。再開するときの条件と手順は、決めて残してあります。

数字で見る

2026 年 10 月 24 日の時点の数です。「直近 3 か月」は 7 月 24 日からです。

今の体制と、人が増えたときに伸びるところ

今の体制: 開発は、ほぼ 1 人のエンジニアと AI のエージェントです。検証と全体の取りまとめは、副業で関わる 3 人のメンバーが、リモートで、空いている時間に受け持っています。全体を取りまとめる PM が 1 人、実際に手を動かして検証するメンバーが 2 人です。関わる時間は 1 人あたり月 30 時間ほど、3 人を合わせて月 90 時間ほどです。この体制で、約 10 週間に検証会を 29 回開き、main への取り込みは 1 日 6 件ほどのペースで回しています。

伸びるところ: 1 人あたり月 30 時間ほどでは、その時間は検証でいっぱいで、今は開発に回す余裕がありません。ただ、検証のメンバーは、検証会を通して仕様と画面をいちばんよく知っています。開発環境とやり方はリポジトリに残してあり、品質は AI のエージェントと品質ゲートが支えます。そのため、関わる時間が増えれば、検証のメンバーを、そのまま開発のメンバーに引き上げられます。

• 作り手が増える仕様を知っている人が、同じ環境・同じ決まりで、すぐに作り始められます
• 検証が深くなる検証に使える時間が増えれば、確かめられるテーマも、1 つのテーマを確かめる深さも広がります
• 出すまでが短くなる新しい機能は検証を通してから出すので、検証の手が増えるほど、本番に出すまでの時間が縮みます

人が増えたときに、やり方を一から教え直す必要はありません。増えた分が、そのまま速さと品質になります。もっと深く関わってくれる仲間が加われば、今の仕組みのまま、開発の速さも品質も、もう一段上に行けます。

この仕組みで、開発をお手伝いします

ここで紹介した仕組みは、YOKOSO PAY だけのものではありません。同じ進め方で、次のようなご相談をお受けしています。

• 受託開発AI のエージェントと品質ゲートを使った、Web アプリや業務システムの開発
• 開発体制づくり指示書・hooks・CI・証跡の決まりを、お持ちのリポジトリに合わせて組む
• 既存の仕組みの見直しCI の待ち時間、テストの組み方、インフラの構成の見直し

まとめ

• ほぼ 1 人のエンジニアと AI のエージェントで、開発から運用までを回しています。やり方はリポジトリに残してあるので、人が増えれば、そのまま同じ品質で広がります
• CI/CD・シフトレフト・Infrastructure as Code で、速く出しても壊さない仕組みにしています。不具合は 3 か所の品質ゲートで止まり、止まったら AI が直します
• テストは課題ごとに足し、画面は証跡を残します。お金や権限に関わるところは人が見て、最後は開発とは別のメンバーが検証会で確かめます
• 開発の速さは DORA の指標で測っています。安定の指標は、利用が増えてから測ります

次回は、本番で動いているシステムを、どう守り、どう異常に気づき、どう直しているかを紹介します。

ご意見・ご相談

開発の進め方へのご意見や、受託開発・開発体制づくりのご相談をお待ちしています。

お問い合わせのフォーム

旅行者・お店・町をつなぐ観光アプリ

YOKOSO PAY のご紹介を見る