Goビルドを理解し、CI/CDの処理時間を25分から10分に短縮した話

Go Conference mini で登壇してきました！

miiveの @sato-shin です。 2026年2月21日に仙台で開催されたGo Conference miniで登壇してきました！

参加から1ヶ月経ってしまいましたが、今さらながら登壇した内容を紹介いたします！

発表スライドはこちらです。 speakerdeck.com

1. はじめに

miiveではバックエンド開発にGoを採用しています。サービスリリースから3年が経つ中で、CI/CDの処理時間は徐々に増加し、1回あたり約25分を要する状態になっていました。

「CI/CDが遅い」というのは、開発者の生産性に直結する問題です。PRを出してからマージまでの待ち時間が長くなり、開発のリズムが崩れてしまいます。

本記事では、この25分を10分にまで短縮した改善の過程をご紹介します。

2. miiveのCI/CDの構成

改善前のCI/CDパイプラインは以下のような構成でした。

Unit Test / E2E Test / Lint は並列で実行され、その後にBuild、Deployと直列で続きます。特に Buildの14分 が大きなボトルネックでした。

3. Goのビルドの特徴をおさらい

改善に取り組む前に、まずGoのビルドの仕組みを整理しました。Goのビルドには以下の特徴があります。

3.1. 単一バイナリで動作する

Goはビルド後に単一の実行ファイルを生成します。Javaのようにランタイム（JVM）を必要とせず、バイナリをそのまま実行できます。これにより、依存するものが少なく、管理が楽でセキュアであり、サーバーの立ち上がりも高速です。

3.2. クロスコンパイルが可能

GOOS と GOARCH を環境変数で指定するだけで、異なるOS・アーキテクチャ向けのバイナリをビルドできます。CI環境がUbuntuでも、Linux/amd64向けのバイナリを簡単に生成できるため、CI/CDの設定がシンプルになります。

$ GOOS=linux GOARCH=amd64 go build -o app

3.3. ビルドキャッシュが組み込まれている

Goのビルドは以下の3ステップで行われます。

1. 依存関係の解決
2. コンパイル (go tool compile) - パッケージごとにオブジェクトファイルを生成
3. リンク (go tool link) - オブジェクトファイルを統合して実行ファイルを生成

ここで重要なのが、パッケージごとのオブジェクトファイルがキャッシュされるという点です。ソースコードに変更がないパッケージは、キャッシュから読み込まれるためコンパイルがスキップされます。

4. 改善への取り組み

4.1. 一般的な高速化手法の検討

まず、Goビルドの一般的な高速化手法を調査しました。

手法	結果
CIでビルドキャッシュを利用する	2回目以降は速くなる
CIでモジュールキャッシュを利用する	2回目以降は速くなる
利用していないコードを削除する	調査したが、全体の1%にも満たない
パッケージの分割を最適化する	時間がかかりすぎるため見送り

キャッシュの利用は有効ですが、それだけでは根本的な解決になりません。キャッシュがない初回ビルドでも14分かかるのは、直感的におかしいと感じました。

普段の開発で go run を実行したとき、そこまで遅いとは感じないからです。

4.2. 計測してみる

「推測するな、計測せよ」の精神で、ローカル環境でビルド時間を計測しました。

まず、最も大きいWeb API serverのみをビルドしてみます。

$ go clean -cache
$ time go build
go build 65.29s

約65秒。妥当な結果です。

次に、CI/CDと同様に全てのコマンド（Web API server + 複数のバッチ処理）をビルドするスクリプトを実行します。

$ go clean -cache
$ time ./build_all.sh
./build_all.sh 265.91s

約266秒（4分半）。 Web API server単体が65秒なのに、全体ビルドでは200秒も増えています。

4.3. リポジトリ構成と疑問

miiveのリポジトリは、Web API server、複数のバッチコマンドが共通の domain / model パッケージに依存する構成です。バッチ系のコードは全体の10%未満であり、しかも共通パッケージはキャッシュによりビルドがスキップされるはずです。

であれば、全体ビルドの時間は Web API server + α 程度に収まるはず。+200秒は明らかに異常です。

4.4. 原因の特定

go build -v オプションを使うと、コンパイル中のパッケージ名が表示されます。これを全コマンドのビルドで実行したところ、同じパッケージが何度もコンパイルされていることが判明しました。

$ go clean -cache
$ ./build_all_verbose.sh
...
math
math
math
...

原因はビルドスクリプトにありました。

ビルドスクリプト内の xargs で go build を並列実行（-P 0）していたのです。複数の go build プロセスが同時に走ると、最初のビルドがキャッシュを書き終わる前に次のビルドが始まるため、ビルドキャッシュが効かず、同じパッケージを何度もコンパイルしていました。

4.5. 修正

修正は非常にシンプルです。xargs の -P 0（無制限並列）オプションを外して直列実行にするだけでした。

直列でビルドすることで、最初の go build（Web API server）で生成されたキャッシュが後続のバッチコマンドのビルドで活用されるようになります。

$ go clean -cache
$ time ./build_all.sh
./build_all.sh 77.50s

266秒から78秒へ、約70%の短縮です。

5. Unit Testの改善

ビルドに加えて、Unit Testの改善にも取り組みました。

最も時間がかかっていたのはDB接続を伴うテストです。テストごとにDBのセットアップ・クリーンアップが走っており、これがボトルネックになっていました。

DATA-DOG/go-txdb を導入することで、各テストをトランザクション内で実行し、テスト終了時にロールバックする方式に変更しました。これにより、Unit Testは10分から4分30秒に短縮できました。

6. 改善結果

7. まとめ

今回のCI/CD改善で得られた教訓をまとめます。

• 原因はシンプルな初期設定時のミスだった - go build を並列実行していたことでビルドキャッシュが無効化されていました。高度な最適化の前に、まず基本的な設定を見直すことが大切です。
• 推測するな、計測せよ - 「遅い気がする」で終わらせず、実際に計測し、go build -v で挙動を確認することで原因を特定できました。
• Goのビルドシステムは優秀 - パッケージ単位のビルドキャッシュが組み込まれており、正しく使えば非常に高速にビルドできます。

CI/CDの速度は、開発者の生産性とプロダクトの品質に直結します。「少し遅いけど、まあいいか」と放置していると、気づかないうちに25分になっていることもあります。

皆さんのCI/CDも、一度見直してみませんか？

We are hiring!

miiveではバックエンドでGoを使っている他にも、フロントではReact、モバイルではReact Nativeを採用しています。 この辺が好き！得意！という方で、決済に興味あるという方は、カジュアル面談のお申し込みをお願いします！

また、軽食を食べたりボードゲームをしながらmiiveについて知ってもらうmiive barを定期的に開催しています！ ご参加お待ちしております 🥂 miive.notion.site

hrmos.co

https://careers.miive.jp

Githubからの通知を探すのがたいへんで...

こんにちは。せーじと申します。現在は株式会社miiveで、Webやバックエンド、アプリの開発をしております。私は業務や私生活で日常的にRaycastを使っています。

私ごとですがDevRelもしており、入社してから推進していたブログ投稿が、この記事でちょうど17週連続投稿となります。キリが悪いですね。30週目でもう一回同じことを言いたい。

17週のうちに毎週1本のペースで記事が投稿されており、そのうち7本を自分で執筆していました。うち6本は Raycastについての記事でした。

www.raycast.com

例えば以下のような記事を執筆しています。

blog.miive.jp

毎回 Raycast の記事を執筆しており、「Raycastはやめた方がいいな〜」と思いつつ、今回もRaycastの記事になります。

拡張機能 GitHub の紹介

今回は以下の拡張機能についてご紹介します。

www.raycast.com

この機能は extensions というOSSで開発&管理されています。今回紹介する拡張機能の大元を開発したのはRaycast社です。また、OSSといってもマージにはRaycast社や同社が指定したレビュワーのapproveが必要になっています。

github.com

install 方法

1. RaycastのStoreを開き

1. github と検索 ※類似の名前の拡張機能が多いため、入れ間違いにご注意ください。

1. Enterで install & 認証情報を設定

詳細はREADME.mdをご覧ください。

https://www.raycast.com/raycast/github#readme

Notificationを探すのがたいへんで...

弊社は GitHub でバージョン管理を行っています。そのため、issueやPR上でのやりとりも盛んに行われます。

様々なissueやPR上で @ メンションで連絡をもらっても見逃すこと・能動的にGitHubを開いて探すことが多かったです。

あれ、さっき通知が来た issue どれだっけ、、、？ PRになにかコメントついてたかな？ 通知多すぎてどれがどれかわからない！

もちろん、ブラウザ上でGitHubを開き、右上からNotificationにアクセスするなどの方法もあると思いますが、個人的には納得できませんでした。

NotificationをRaycastから

そこで使うのが 拡張機能 Github の Notifications Commandです。私は ⌘+N で呼び出せるようにしています。

実際にCommandを実行すると以下のような画面になります。

マスクしている部分にはリポジトリ名や通知内容がプレビューとして表示されています。

PRやworkflowの場合

issueの場合

対象の Notification にフォーカスがあたった状態で ⌘+K を押すと以下のように対象に対するアクションの選択肢が出てきます。UnsubscribeやMark as Readも全てRaycastから実行できます。

終わりに

元々はかなり見落としが多かった私ですが、この機能のおかげで、「あのときのアレ」を探す時間も「通知の見落とし」もなくなりました（たぶん）。

拡張機能 GitHubは他にも

• 自分の PR の一覧
• レビュワーとして追加されているPRの一覧
• 自分が関連するPRの総数と詳細が Macのメニューバーからアクセス
• 自分が担当 or 作成したissueの一覧

など、気になる情報をパッと表示できるCommandが他にもたくさんあります。

| 機能名 | 説明 |
|---|---|
| My Pull Requests | 自分が作成・参加・言及されたプルリクエストを一覧表示 |
| Search Pull Requests | すべてのリポジトリで最近のプルリクエストを検索 |
| Create Pull Request | 自分のGitHubリポジトリでプルリクエストを作成 |
| My Issues | 自分が作成・担当・言及されたIssueを一覧表示 |
| Search Issues | すべてのリポジトリで最近のIssueを検索 |
| Create Issue | 自分のGitHubリポジトリでIssueを作成 |
| Create Branch | ブランチを作成（デフォルトでは無効） |
| Search Repositories | 自分の公開/非公開リポジトリを名前で検索 |
| My Latest Repositories | 最近更新された自分のリポジトリを一覧表示 |
| My Starred Repositories | 自分がスターしたリポジトリを一覧表示 |
| Workflow Runs | 選択したリポジトリのワークフロー実行を管理 |
| Notifications | すべてまたは選択したリポジトリの通知を一覧表示 |
| Unread Notifications | 未読通知をmacOSメニューバーに表示 |
| Search Discussions | 最近のDiscussionsを全リポジトリで検索（デフォルトでは無効） |
| My Discussions | 自分のDiscussionsを表示（デフォルトでは無効） |
| My Projects | 自分のProjectsを表示 |
| My Issues Menu Bar | 自分のIssueをメニューバーに表示 |
| My Pull Requests Menu Bar | 自分のプルリクエストをメニューバーに表示 |

実は上記の表もRaycastに作ってもらいました...　その話はまた別の機会に。

いつもの

弊社にご興味を持っていただけましたら、カジュアル面談や、miive bar（ゆるく雑談とボードゲームをする会）なども実施しています。

ぜひご参加ください！お待ちしております！

hrmos.co

miive.notion.site

XでDMでも大歓迎です！

採用情報については以下をご確認ください！

https://careers.miive.jp

AI Pdmの第一歩 ~『これ、考慮できてる？』をAIに任せる~

こんにちは、miiveでプロダクトマネージャーをしているKengoです。

今回は、PRD（プロダクト要求仕様書）のレビュープロセスをAIで自動化した取り組みについてご紹介します。

---

背景と発生していた課題：プロダクトマネジメントの「広がり」と「複雑さ」

miiveは創業当初から2025年後半まで、プロダクトマネジメントを一人のPdM（プロダクトマネージャー）が担う体制でした。しかし事業の拡大に伴い、複数のPdMメンバーが並走し、エンジニアもプロダクトマネジメントの一部を担うようになってきました。

チームの規模が広がることはとても良いことですが、規模拡大に伴い、新たな課題も見えてきました。 プロダクトマネジメントに関わる人数が増えるほど、「ドメイン知識の濃淡」が生まれ、考慮漏れのリスクが高まるという問題です。

PRDを書く全員がmiiveのドメイン知識を深く持った上で作業する必要があります。しかしmiiveのプロダクトドメインは複雑です。

例えば、以下のようなドメインが複雑に絡み合っています。

• 福利厚生サービスに関わる、税務・労務の法令
• 決済・ポイント・カード発行に関わる、フィンテックの専門知識と法令
• BtoBtoE（企業間取引を通じて最終的に従業員に届けるビジネスモデル）という構造が生む、機能変更による管理者・従業員それぞれへの影響

一人のPdMがすべてを把握していた頃は、経験と勘でカバーできていた部分もありました。しかし複数人でプロダクトマネジメントを行うようになると、「その観点、知らなかった」「そこまで考慮できていなかった」というリスクが高まります。「考慮漏れ」が起きた場合、顧客への影響や事業リスクに直結するケースもあり、許容できません。

一方で、すべての観点を毎回インプットしてPRDを書くのも大変で、すべての観点を網羅してレビューするのも大変になります。 特にPRDのレビューは、書いた本人以外がキャッチアップしながらレビューする必要があり、レビュアーの負荷も高くなりがちです。

---

解決アプローチ：「一次レビュー」をAIに任せる

この課題に対して、PRDレビューエージェントを構築しました。

考え方としてはシンプルで、

プロダクトとして考慮すべき観点、考慮が漏れやすい領域をAIに学習させ、PRDの一次レビューを自動化する

というものです。

人間によるレビューをなくすのではなく、「AIが一次チェックを行い、本当に議論が必要な論点に人間のレビューを集中させる」という方針です。

---

どうやって作ったか

Notionのカスタムエージェントを活用

今回はNotionのカスタムエージェント機能を利用してPRDレビューエージェントを構築しました。

miiveではPRDをNotionで管理しているため、ドキュメントとエージェントを同じ場所で完結させることができます。これにより、「レビューのためにどこかへコピーする」という余分な手順が不要になっています。

SlackからメンションするだけでOK

エージェントへのアクセスはSlackのメンションで行えるようにしています。

@prd-review-agent [Notion PRDのURL]

これだけでレビューが始まります。

Slackを選んだ理由はシンプルで、チームが日常的に使っているインターフェースだからです。

新しいツールを覚える必要もなく、特別な操作も不要で、いつも通りSlackを開いてメンションするだけで使えます。 「ちゃんと使われるエージェント」を作るためには、日常の延長線上に置くことが重要という思想からSlackで完結するようにしています。

エージェントが確認する観点

レビューエージェントは、以下のような観点を中心にPRDを評価します。

• 税務・労務の法規制との整合性（非課税枠、給与課税、関連法令の準拠 など）
• フィンテック領域の考慮事項（残高整合性、関連法令の準拠 など）
• 管理者・従業員それぞれへの影響の網羅性
• エッジケースや例外フローの記述有無
• 非機能要件（セキュリティ・権限）の記載有無

これらはmiiveのプロダクトとして「考慮すべき観点」として蓄積されたナレッジをもとにしています。

実際にエージェントがレビューしている様子。スレッド内でエージェントとやり取りしてPRDの精度を上げていくこともできます。

---

導入効果

PRDの一次レビューが約30秒で完了

従来の人間が実施するレビューでは、PRDを読み込んでレビューコメントを付けるまでに、少なくとも数十分はかかっていました。 それが、エージェントによる一次レビューではおよそ30秒 で完了します。

考慮漏れが実際に見つかった

最も重要な効果として、実際にAIレビューを使ってみると、考慮が漏れていた観点や追加で検討が必要な項目が次々と洗い出されました。 私自身もPRDをレビューしてもらった際に「書いたときには気づかなかったが、言われてみれば確かに」という指摘が多く、PRD全体のクオリティが底上げされていると感じます。

---

まとめ

今回の取り組みは、「ドメイン知識をエージェントに載せてレビューを自動化し、暗黙知を民主化する」試みでした。

PRDのレビューはどうしても経験や専門知識に依存しがちです。その「暗黙知」をエージェントに学習させることで、チームの誰でもハイクオリティなフィードバックが受けられる仕組みになっています。 PRDレビューエージェントはその第一歩に過ぎません。「ドメイン知識をチーム全員の武器にする」ために、AIの活用をプロダクト開発のあらゆる場面に広げていきます💪

---

We're Hiring!!!

miiveは、事業と組織の両面で本格的な成長フェーズに入りました。
まだ少数精鋭だからこそ、一人ひとりの意思決定がプロダクトの未来を左右します。
ユーザー目線のプロダクトづくりに挑み、難しい課題に粘り強く向き合い、社会にポジティブなインパクトを残したい。
そんな思いを持つ方と、一緒に働けることを楽しみにしています。

少しでも興味のある方は、ぜひお話ししましょう！

採用情報はこちら

また、miiveメンバーと気軽に仕事や働き方を語れる「miive bar🍷」も定期的に開催中です。「いきなりカジュアル面談はちょっとハードルが高い…」 という方も大歓迎です。

仮売上と売上の実際にあったゾゾっとする決済パターン 〜重複返金のお話（イシュア側）〜

あいさつ

こんにちは。miiveのmineです。カード決済のお金にかかわるところを開発しています。

今回はイシュア（カード発行会社）側で実際に起きた、少しゾゾっとする決済パターンについてお話しします。

仮売上（オーソリ）と売上確定（請求）。その裏側で起きていた「重複返金」と「返品取消」の話です。

---

今回のタイムライン

一見すると「よくある処理ミス」に見えるかもしれません。

しかしイシュア側では、まったく違う景色になります。

---

① 仮売上（オーソリ）

売上 50,000円

② 売上確定（確定処理）

売上 50,000円

③ 返金（オーソリ）

返金 50,000円

ここまでは問題ありません。

差引ゼロ。きれいに相殺されます。

---

④ 重複返金（確定処理）

さらに50,000円の返金データが到着します。

状況を確認すると以下のようになります。

区分	金額
売上	50,000円
返金①	-50,000円
返金②	-50,000円

差引：-50,000円（返しすぎ）

高額であればあるほど、血の気が引きます。

---

しかし、イシュアはすぐに確定させない

ここが一番ゾゾっとするポイントです。

イシュアはこの重複返金を、即座に確定させません。

なぜか？

返品取消が後日到着する可能性を想定するからです。

加盟店側で

• バッチ二重送信
• 手動処理ミス
• 再送データ

が発生している可能性があります。

だから「一旦止める」。

ここで即確定すると、意図しない残高増加が発生するからです。

---

約1ヶ月後

⑤ 返品取消（確定処理）

⑤ 返品取消（50,000円）

ようやく整合が取れました。

結果的には想定どおり。

しかしこの1ヶ月間、内部ではずっと緊張状態でした。

---

この1ヶ月間に起きていたこと

• 返金超過状態として監視対象

本当に取消が来る保証はありません。

ここが一番怖いところです。

---

もしこれが高額だったら？

今回が5万円だったとしても、

もしこれが500万円だったら？

• 一時的な資金流出
• 不正利用疑い

「処理ミス」では済まないレベルになります。

---

決済は時間差で怖い

オーソリ
売上確定
返金
返品取消

すべてが非同期です。

決済はその瞬間に完結しません。

時間差で整合していく世界です。

そして、その整合を信じて「止める」という判断をする。

ここに決済の怖さがあります。

---

おわりに

仮売上と売上確定。

その先にあるのは信用とリスク管理の世界です。

決済は「通った」で終わらない。

裏側では、誰かが
「本当に取消が来るのか？」と考え続けています。

数字は冷たいですが、
その裏では人間の緊張が動いています。

この記事が、決済設計に関わる誰かのヒントになれば幸いです。

---

we are hiring!

miiveはWeWork 新宿を拠点にしており、気軽に仕事や働き方を語れる「miive bar」を定期的に開催中です。

miiveについて気になった方はぜひご連絡ください！

miive.notion.site

hrmos.co

カードをタッチした数秒の裏側で、何が起きているのか

こんにちは。 miiveで開発責任者をしているdaichiです。

みなさんコンビニで買い物をする時に、カードでタッチ決済をしたことはありますか？

数秒で終わるカード決済ですが、実はその数秒の間に複数のプレイヤーが連携して「この支払いを成立させる」ための処理が走っています。 そしてもうひとつ、普段あまり意識されないのが「決済の確定は数日後に行われる」という点です。

miiveは、Visaの加盟店で使えるプリペイドカードを提供しています。 そのため支払いの瞬間に残高が反映されますが、最終的な確定はもう少し後で行われます。

今回はこの「数秒の裏側」と「数日後の確定」をつなぐ流れを、miiveの視点で図解していきます。

1. カード決済の登場人物

カード決済は「利用者」と「お店」だけで完結しているように見えますが、裏側ではいくつかの役割が登場します。

miiveの場合、ざっくり次の4者で捉えると理解しやすいです。

• miiveカード利用者（従業員）

• Visa加盟店（お店・ECサイト）

• Visaネットワーク

• miive（カード発行体：利用可否の判定／残高の管理）

※実際のカード決済は、ここで挙げた以外にも複数の役割が関わります。本記事では全体像をつかむことを優先し、説明に必要な登場人物だけに絞っています。

---

2. 決済は「数秒で成立」して「数日後に確定」する

カード決済は大きく分けると オーソリ／クリアリング／セトルメント の3段階で進みます。 ポイントは、店頭で「決済完了」に見えるタイミングと、金額が「確定」するタイミングが違うことです。

• オーソリ（Authorization）： その場で「このカードで、この金額の支払いを通していいか？」を確認する処理です。 OKが返ってくると、レジでは「決済完了」になります（体感はここで終わります）。

• クリアリング（Clearing）： 数日後に加盟店から「この取引が最終的にこういう金額でした」という売上データが届き、ここで金額が確定します。

• セトルメント（Settlement）： 確定した売上にもとづいて、加盟店側への支払いが行われます。

全体像を時系列で見ると、こうなります。

sequenceDiagram
  participant U as miiveカード利用者（従業員）
  participant M as Visa加盟店（お店・ECサイト）
  participant V as Visaネットワーク
  participant I as miive

  U->>M: 支払い（タッチ/差し込み/オンライン）
  M->>V: オーソリ要求（この支払いOK？）
  V->>I: オーソリ要求
  I-->>V: 承認/拒否
  V-->>M: 承認/拒否
  M-->>U: 支払い完了（体感はここで終わる）

  Note over M,I: 数日後（タイムラグあり）
  M->>V: クリアリング（売上データ）
  V->>I: クリアリング（売上データ）
  Note over M,I: 精算（加盟店への支払い）

---

3. クレジットカードとプリペイドカードの違い

クレジットカードとプリペイドカードは、見た目はどちらも「カードで支払う」体験ですが、根本の考え方が少し違います。

• クレジットカード：後払い。いま使えるか（与信枠）を確認し、利用分は後日まとめて請求される
• プリペイドカード：前払い。事前に用意された残高の範囲で使い、使った分がその場で残高に反映される

ただし、ここで誤解されがちなのが「プリペイドはその場で残高が減る＝その瞬間にすべてが確定している」という点です。

実際には、カード決済としての処理の流れ自体は共通で、どちらも

1. 支払いの瞬間に オーソリ（承認） が走り（支払いを成立させる）
2. 数日後に クリアリング（売上確定） が届いて（最終的な金額が確定する）
3. その結果にもとづいて精算が進む

という順番で動きます。

違いが出るのは、この共通の流れの中で、利用者に「お金（残高/請求）がどう見えるか」です。

• クレジットカード：オーソリは枠の確認（確保）。請求は後日まとめて
• プリペイドカード：オーソリの時点で残高に反映。ただし最終確定は後日のクリアリング

クレジットカード（請求は後日まとめて）

sequenceDiagram
  autonumber
  participant U as 利用者
  participant M as Visa加盟店（お店・ECサイト）
  participant V as Visaネットワーク
  participant I as 発行側（承認・売上確定）

  Note over U,I: クレジットカード（請求は後日まとめて）
  U->>M: 支払い
  M->>V: オーソリ
  V->>I: オーソリ
  I-->>V: 承認
  V-->>M: 承認
  Note over U: この時点では「請求」は未確定

  Note over M,I: 数日後
  M->>V: クリアリング（売上データ）
  V->>I: クリアリング（売上確定）
  Note over U: 締め日にまとめて請求

プリペイドカード（オーソリで残高に反映）

sequenceDiagram
  autonumber
  participant U as miiveカード利用者（従業員）
  participant M as Visa加盟店（お店・ECサイト）
  participant V as Visaネットワーク
  participant I as miive

  Note over U,I: プリペイド（miive）（オーソリで残高に反映）
  U->>M: 支払い
  M->>V: オーソリ
  V->>I: オーソリ
  I-->>V: 承認（残高を反映）
  V-->>M: 承認
  Note over U: 使った分がすぐに残高へ反映

  Note over M,I: 数日後
  M->>V: クリアリング（売上データ）
  V->>I: クリアリング（売上確定）
  Note over U: 差があれば最終確定に合わせて調整

そして miiveはプリペイドカードなので、支払いの瞬間（オーソリの承認）に残高へ反映されます。

一方で、金額の最終確定は後日のクリアリングで行われるため、オーソリの時点と最終確定の間でズレが生じるケースもあります。

次のセクションでは、このズレも含めて「決済後に起こりうること」を簡単に整理します。

---

4. プリペイドならではの特徴（残高はすぐ動くが、確定は後から）

miiveはプリペイドカードなので、オーソリ（承認）が通った瞬間に 残高がすぐに反映されます。
これは体験として分かりやすく便利な一方で、カード決済の仕組み上 「確定は数日後」 という前提は変わりません。

この “リアルタイムに見える残高” と “後から確定する売上” の間に、利用者が「あれ？」と思いやすいポイントが生まれます。

---

4-1. 取り消し（確定前のキャンセル）

支払い直後にキャンセルになった場合など、売上確定（クリアリング）に進む前に取引が取り消されることがあります。
プリペイドの場合は、オーソリでいったん減った分が 残高に戻る 形になります。

※これはあくまで代表例です。加盟店側の処理タイミングなどによって、反映のされ方やタイミングが前後することがあります。

---

4-2. 返金（確定後の返金）

返品などで代金を戻す必要がある場合、いったん売上が確定したあとに 返金として処理されることがあります。
このため、決済直後ではなく 少し時間が経ってから残高に反映されるケースがあります。

※返金にもいくつかパターンがあり、加盟店側の処理（返品の確定や返金データの送信）によって反映タイミングが変わります。ここでは典型例として説明しています。

---

4-3. オーソリとクリアリングのズレ（差額調整）

決済の最終確定はクリアリングなので、ケースによっては オーソリ時点の金額と確定金額が一致しない ことがあります。

オーソリは「この支払いを通してよいか」を即時に判定するための処理で、ここでは 仮の金額 でいったん成立させます。
一方、クリアリングは数日後に届く「売上の最終結果」なので、ここで 最終的な金額が確定 します。

たとえば外貨決済では、オーソリからクリアリングまでの間に為替レートが動き、最終的な確定額が変わることがあります。
この場合は、確定した金額に合わせて差額が調整されます。

利用者の見え方としては、「いったん減った残高に、後日差額だけ追加で反映される（または戻る）」 イメージです。

たとえば、こんな流れです。

sequenceDiagram
  participant U as miiveカード利用者（残高）
  participant I as miive

  rect rgb(230, 245, 255)
  Note over U,I: オーソリ：1,000円（支払い成立）
  I->>U: 残高に反映（-1,000円）
  end

  rect rgb(255, 245, 230)
  Note over U,I: 数日後
  Note over U,I: クリアリング：1,050円（売上確定）
  I->>U: 差額を調整（-50円）
  end

---

4-4. （補足）加盟店からデータが届かないケースもある（一定期間後に解消）

カード決済は本来、オーソリのあとにクリアリング（売上確定）が届いて完了します。 ただし加盟店側の事情などで、クリアリング（確定データ）や、取り消し／返金に相当するデータが送られてこないケースもまれにあります。

このままだと、オーソリでいったん減った残高が「宙に浮いたまま」になってしまうため、miiveでは 購入日から一定期間（例：45日） を待っても確定や取り消しのデータが届かない場合、システム的に取引を解消（残高を戻す） といった対応を行うことがあります。

sequenceDiagram
  participant U as miiveカード利用者（残高）
  participant M as Visa加盟店（お店・ECサイト）
  participant I as miive

  rect rgb(230, 245, 255)
  Note over U,I: 決済時（オーソリ）
  U->>M: 支払い
  M->>I: オーソリ要求
  I-->>M: 承認
  I->>U: 残高に反映（いったん減算）
  end

  rect rgb(255, 245, 230)
  Note over M,I: 通常は数日後にクリアリングが届く
  Note over M,I: まれにデータ未着
  Note over M,I: （確定も取り消しも来ない）
  end

  rect rgb(230, 255, 230)
  Note over U,I: 一定期間（例：45日）経過
  I->>U: 取引を解消（残高を戻す）
  Note over U,I: セーフティネット（未確定が残り続けないように）
  end

---

まとめ：決済は一日にしてならず

カードをタッチした瞬間、私たちは「決済が終わった」と感じます。 でも実際には、裏側では次のようなリレーが動いています。

• 数秒の間に オーソリ（承認）が走り、支払いが成立する
• 数日後に クリアリング（売上確定）が届き、金額が確定する
• その結果にもとづいて セトルメント（Settlement） が進む（加盟店への支払い）

sequenceDiagram
  participant U as miiveカード利用者（従業員）
  participant M as Visa加盟店（お店・ECサイト）
  participant V as Visaネットワーク
  participant I as miive

  rect rgb(230, 245, 255)
  Note over U,I: 🕐 数秒：支払いの成立
  U->>M: 支払い（タッチ決済）
  M->>V: オーソリ要求
  V->>I: オーソリ要求
  I-->>V: 承認（残高に反映）
  V-->>M: 承認
  M-->>U: 支払い完了
  end

  rect rgb(255, 245, 230)
  Note over U,I: 📅 数日後：金額の確定
  M->>V: クリアリング（売上データ）
  V->>I: クリアリング（売上確定）
  Note over I: 差額があれば調整
  end

  rect rgb(230, 255, 230)
  Note over M,I: 💰 セトルメント（加盟店への支払い）
  end

miiveはプリペイドカードなので、支払いの瞬間に残高へ反映されます。 それでも「最終確定は後日」というカード決済の前提は変わらず、取り消し・返金・金額のズレといった挙動が起こり得ます。

普段は見えない世界ですが、この構造を知っておくと「なぜこう見えるのか」が少しクリアになるはずです。 今後もmiiveのプロダクトを支える仕組みを、できるだけわかりやすく紹介していきます。

---

We're Hiring!!!

miiveでは、一緒に 福利厚生の未来 を作ってくれる仲間を募集しています。

「決済を扱う」「お金が動く」「体験を作る」——こういう領域に少しでもワクワクする方は、ぜひ一度お話しましょう！

hrmos.co

また、定期的にお酒と軽食を楽しみつつ、カードゲームやボードゲームで遊びながら、miiveメンバーと気軽に仕事や働き方の話ができる 「miive bar🍷」 も開催しています。

「いきなりカジュアル面談はちょっとハードルが高い…」という方は、ぜひ miive bar に遊びに来てください！

miive.notion.site

XのDMでもお待ちしております！

GitHubのProjectsが素晴らしかった...

こんにちは。せーじと申します。現在は株式会社miiveで、Webやバックエンド、アプリの開発をしております。私は業務や私生活で日常的にRaycastを使っています。

現職に入社後5本ぐらいRaycastについての記事を書いてきましたが、今日はGitHubのProjectsについて書こうと思います。

きっかけ

弊社には「よもやま会」という文化があります。

週次で開催され「なんだかな〜」と思ったことを記載しておき、それについて話す会です。

ある日

タスク管理ツールを解約したい

- 背景
    - コストが高い。1アカウント1000円/月以上する
    - フル活用できていない。ただのKanbanとしての運用しかできていない。
    - ベロシティを図るとかも今はできていない
    - (GitHubとの)ワークフローもっと組みたい

のような意見が寄せられました。

要約すると「開発メンバーのタスク管理には専用のサービスを利用しているが、うまく使いこなせてないし他のツールでいいのでは？」

という意見でした。たしかに。

賛同が多かったため、有志を集って活動することになりました。

移行先はGitHubのProjectsに

移行先として色々と検討しましたが、「GitHubとの連携が強い（というかGitHubそもそも）」という理由から最終的にはProjectsを採用しました。

Projectsはこんなやつです。

出典：ビューのレイアウトを変更する

1つのProjectsに複数リポジトリのissueを紐付けられ、Kanbanなどでタスク管理ができます。

Projectsってこんなに色々できるのか！

個人で過去にProjectsを利用してはいましたが、7年も前です。「Kanbanが出せるツール」ぐらいの認識で移行を試しましたが、想像以上に多くのことができました。

今回は個人的に「いいな〜」と思った機能をざっくり紹介していきたいと思います。

CLIで完結できる

まず「いいな〜」と思ったのはtokenなどの面倒な設定をしなくてもCLIでしたい操作のほとんどができることでした。

多くのタスク管理サービスの場合、APIを提供していますが、利用するのにAPI Token等の発行が必要になります。 また、CLIから利用しようとするともう一手間かかります。

Projectsの場合、ghコマンドを利用することでissueの作成からprojectsの紐付け、カスタムフィールドの設定、issueの情報の取得までできます。

# issue の作成例
gh issue create --title "My new issue" --body "Here are more details."

# Projects へ追加例
gh issue edit 42 --add-project "Sprint Board"

人間が見ると若干とっつきにくいですが、AIに聞けば使い方を知っておりサクッと簡単に利用できます。

GitHubには公式のMCPもあるのでそちらを使うとより効率的です。

データの移行時も元のデータをAPIで引っこ抜き、ghコマンドでissueを作るshell scriptを作成しました。

この際、適切なsleepを入れないとRate Limitに引っかかるので注意です！

Table / List / Roadmap などViewが豊富

Projectsには3つのViewが用意されています。弊社のユースケースとしては必要十分なViewが用意されていました。

以下の画像は公式サイトから拝借しました。

Table

いわゆるKanbanです。それぞれのissue上に表示する情報もカスタムできて（後述）大変使い勝手がいいと感じています。

List

この表示で「すごい！」と思った点はスプレッドシートやExcelみたいに値をコピー&ペーストできることです。一括で情報を更新したい際などとても便利です。若干スタイルは崩れますが、一覧をコピーし、別のツールにペーストすることもできます。

Roadmap

カスタムフィールド（後述）に設定した値のうち、日付のフィールドを使ってロードマップ表示ができます。

KanbanでPRの状態まで一覧できる

こんな感じで表示されます。画像はPRがOpenな状態です。Merged、ClosedやDraftなどによって表示が変わります。

PRのように一覧に表示する情報は View > Fields > Visible fieldsを設定することでカスタマイズできます。

LabelsをVisible fieldsに追加すると以下のような見た目になります。

リリース物の管理もできる

ProjectsではProjectごとにカスタムフィールドを設定できます。以下の画像はProduct KANBANというProjectのカスタムフィールドです。

ここにリリース日を追加します。

次にListで リリース日ごとにリストを分割する 設定を入れるとどのissueがリリースに含まれるか？が一目でわかるようになります。

GitHub Copilotにissueをお願いする

GitHub Copilotは「GitHub Copilot は、コードをより迅速かつ少ない労力で記述するのに役立つ AI コーディング アシスタント」です。

いわゆるAIエージェントです。人間の代わりにコーディングや調べ物をしてくれます。

github.com

GitHub CopilotもProjects(というかissue)もGitHubが提供しているため、今では簡単にタスクを依頼することができます。

issue > Assigners > Assign to Copilot から簡単にissueをタスクとして渡せます。

Assign to Copilotをクリックすると以下のようなモーダルが出てきます。リポジトリを選択し、Assignを押すとそのまま作業を始め、PRの作成までしてくれます。

「やり方はわかるけど作業するのが面倒」なタスクを任せるには最高です。

GitHub連携

もちろんGitHubとの連携もバッチりでした。ProjectsにはWorkflowという機能があります。 デフォルトで様々な設定が入っており、ポチポチGUI上で設定するだけで動作をカスタムできます。

弊社も今後もっと活用していきたい。

ベロシティを計測する

現状はあまり活用できていませんが、ProjectsにはInsightsという機能も提供されています。

これはissueのステータスやopen / closed、カスタムフィールドの値などを集計しグラフにできるものです。

今後ベロシティの計測などに利用できそうだなと感じています。

最後に

以上「GitHubのProjectsってこんなに色々できるのか...！」という驚きの共有でした！

今回ご紹介したようにフットワーク軽く新しいことを試せる環境です！

弊社にご興味を持っていただけましたら、カジュアル面談や、miive bar（ゆるく雑談とボードゲームをする会）なども実施しています。

ぜひご参加ください！お待ちしております！

hrmos.co

miive.notion.site

XでDMでも大歓迎です！

AIで「答えられる範囲」を広げる。社内の問い合わせ自動化の進化

こんにちは、miiveでプロダクトマネージャーをしている hayashi です。

以前の記事では、社内のプロダクト仕様に関する問い合わせを AI アシスタントで自動化し、問い合わせ対応の負荷を大きく下げた取り組みをご紹介しました。

今回はその第二弾として、プロダクトの仕様以外にもサービスの事業ドメイン（税務・労務・フィンテック）に関連する回答や、ユーザーの実利用データを踏まえた問い合わせへの一次対応についてAIアシスタントで自動化した取り組みについてご紹介します。

---

背景：問い合わせは「仕様」だけでは解決しない

miiveのプロダクトでは、次のような問い合わせが日常的に発生します。

　・「決済のこの挙動は仕様通りですか？」

　・「税務・労務的にこの使い方は問題ありませんか？」

　・「このユーザーのケースでは、実際どうなっていますか？」

このような利用状況に紐づく問い合わせは、

　・プロダクト仕様

　・事業ドメインとしての前提（税務・労務等）

　・実際の利用データ

の 3 つを同時に理解しないと正確な回答が出せないケースが多く、結果として問い合わせが特定メンバーに集中してしまっていました。
特に決済関連問い合わせは回答遅延がユーザー不信につながることもあり、迅速な回答が求められています。

解決アプローチ：仕様 × 実データ をAIで突き合わせる

今回の解決アプローチとして、ユーザーからの利用に関する問い合わせに対して、

プロダクト仕様ベースの知識と税務労務などの事業ドメイン知識、実際の利用データ（BigQuery） を突き合わせて、AI が一次回答を行う

という仕組みを構築しました。

連携のフロー図

これにより、人がBigQueryを開いてクエリを書いて調査する前に、

　・プロダクト仕様上どうあるべきか

　・税務・労務などの事業ドメインを考慮してどうあるべきか

　・実データ上どうなっているか

を整理した回答が即時に返るようになっています。

Devin × BigQuery を安全に使うための Playbook 設計

この仕組みの中核となるのは、Devin（Data Analytics Agent） と BigQuery を安全に連携させる Playbook です。
単に「AI にデータを見せる」のではなく、以下の要素を同時に満たす構成にしています

・再現性 — いつでも同じ結果が出る
・コスト効率 — BigQuery スキャン量を抑制
・品質管理 — 分析誤差の抑止
・プライバシー保護 — PII を扱わない明確な制約

上記の要素を満たすために、Playbook は以下のパートに分かれています

1. 高速・再現性のある基本フロー

2. 分析の深さを制御する段階的ルール

3. BigQuery コスト制御

4. 品質ガードレール

5. プライバシー制御

このように明確な構造を設けることで、AI を安全かつ信頼性高く実データと接続しています。

各Playbookの中身

---

1. data-analytics-agent-main

再現性のある分析を高速に回すための基本フロー

Data Analytics AgentがBigQueryを使って分析を行う際の基本フローを下記の通り定義し、Devinがいつでも同じ振る舞いを行うことを担保しています。

• 調査目的の明確化

• 使用テーブルの前提確認

• 実行・結果整理・ログ化

2. data-analytics-agent-path

分析の「深さ」を3段階に分けて制御

問い合わせ内容に応じて、分析の深さを下記の3段階的に切り替えます。

• 既存のmart（集計済み・整備済みデータ）だけで回答するパス

• 新たなJOIN や重い整形を極力避けるパス

• 本当に必要な場合のみ深掘りするパス

これにより、「速度」「BigQueryのスキャン量」「コスト」をコントロールしながら、必要十分な精度で回答できるようにしています。

3. data-analytics-agent-cost

BigQueryコストを意識した実行ガイド

BigQueryは便利な反面、無制限に使うとコストが膨らみがちです。

そのためこのPlaybookでは、下記のルールを設け、「気づいたら高コスト」になることを防いでいます。

• 本実行前に推定スキャン量（bytes）を必ず取得

• ドライラン結果を分析ログとして保存

  • 推定TB

  • 主要テーブル

  • 注意点

4. data-analytics-agent-quality

「正しいつもりの数字」を防ぐ品質ゲート

分析結果は、間違っていてもそれっぽく見えてしまうのが一番怖いポイントです。

そこで、下記のルールをPlaybook に組み込み、誤った一次回答を出さないためのガードレールを設けています。

• 分析の各段階で必ず通す品質チェック

• やってはいけない分析パターンの明文化

5. data-analytics-privacy

個人情報を扱わないための明確な制限

利用データを扱う以上個人情報（PII）を取得できない設計は必須です。

このPlaybookでは、下記のようなルールを明確に定義し誤った情報を取得しないようにしています。

• Devin（Data Analytics Agent）が取得して「良い情報」と「いけない情報」
• プライバシー制限と取り扱いルール

を明確に定義しています。

その結果、「業務に必要な分析は可能だが、個人情報は閲覧できない」という安全な境界線を保ったまま、実際のデータを活かすようにしたAI活用を進められています。

動作イメージ

Slackで @miive-ai をメンションして、質問事項を入力するだけで実際のデータや事業ドメイン知識をベースとした回答がものの数分で得られるようになりました。

例えば、「特定の決済でポイントが利用されなかった理由は？」という問い合わせに対して、仕様・税務・実データの情報を組み合わせて下記のような正確な回答が返るようになっています。

ユーザーの決済に関する問い合わせの回答（※ 取引は筆者のものです）

導入効果

この仕組みによって、複雑な事業ドメイン知識が関わる問い合わせや、実データを確認する必要がある問い合わせのほとんどをAIが一次回答できるようになりました。

その結果として、一部の社内の有識者に集中していた問い合わせが削減され、組織全体の生産性が向上しています。

まとめ

AIにただデータに接続するだけではなく、プロダクト設計の理解・事業前提・データの安全性を担保することで、はじめて信頼できる AI アシスタントが実現します。

今後はこの仕組みをさらに発展させ、プロダクトだけでなくセールスやバックオフィス領域へもAI 活用を広げていきます💪

We're Hiring!!!

miiveは、事業と組織の両面で本格的な成長フェーズに入りました。
まだ少数精鋭だからこそ、一人ひとりの意思決定がプロダクトの未来を左右します。
ユーザー目線のプロダクトづくりに挑み、難しい課題に粘り強く向き合い、社会にポジティブなインパクトを残したい。
そんな思いを持つ方と、一緒に働けることを楽しみにしています。

少しでも興味のある方は、ぜひお話ししましょう！

hrmos.co

また、miiveメンバーと気軽に仕事や働き方を語れる「miive bar🍷」も定期的に開催中です。「いきなりカジュアル面談はちょっとハードルが高い…」という方も大歓迎です。