AI時代のGo開発2026 爆速開発のためのガードレール_Mimura

Go Conference mini in Sendai 2026
https://sendaigo.jp/

Transcript

1. © 2026 UPSIDER.inc AI時代のGo開発2026 爆速開発のためのガードレール UPSIDER Ryo Mimura 2026/02/21 Go Conference mini in Sendai 2026 1
2. © 2026 UPSIDER.inc Presenter Profile 三村 遼 Ryo Mimura) @r4mimu 株式会社UPSIDER • これまで ◦ 社内CI/CD基盤・開発生産性 ◦ BtoB SaaS プロダクトエンジニア • 2025 ◦ UPSIDER カード事業部 Backend Engineer • ランニング🏃 サウナ🧖 飲酒🍻 • 好きなパッケージ：context 2
3. 挑戦者を支える世界的な 金融プラットフォームを創る UPSIDERはカード会社から、総合金融機関へ UPSIDERについて ビジョン / ミッション 3 © UPSIDER Inc
4. 提供サービス一覧 UPSIDERはAI化された総合金融機関へ 当社はこれまで決済事業に特化し、お客様の成長をサポートしてきました。しかし今後は総合金融機関として進化していきます。 4 挑戦者を応援する法人カード https://up-sider.com/ https://shi-harai.com/ https://breakthrough-grid.com/ https://ai-keiri.up-sider.com/ https://www.upsidercap.com/ https://president-card.com/ 請求書カード払いサービス ビジネスリーダー向けコミュニティ 経営者のための経理丸投げサービス 経営者の挑戦を支える法人カード グロースデットファンド 与信枠の増枠＆広告媒体 仕入れの後払いを実現 Adboost BUSINESS
5. 売上規模 年間成長 約100億円2 50%以上を継続 2 100,000社以上1 ユーザー数 実績 株式会社UPSIDER ファクトブック *1 当社が提供する全サービスのリリースからの登録企業数の合計、 2025年11月時点。 *2 2025年4月末時点。 5
6. © 2026 UPSIDER.inc Agenda Topic 1 AI 開発の「速さ」と「治安」 Topic 2 Architecture: 依存の制御 Topic 3 Testing: AIのハックを防ぐ Topic 1 Topic 2 Topic 3 6
7. © 2026 UPSIDER.inc Section AI開発の「速さ」と「治安」 7
8. © 2026 UPSIDER.inc Section AIコーディングは当たり前 • Cursor, Claude Code, Codex, GitHub Copilot,... • 「仕様を満たす実装」は当たり前に実現してくれる • 徐々にモデルの間の実装能力の差は縮まっている（気がする）。どのモデルも賢 い • 関心はツール・モデル比較よりも 「どうやってチームで安定して良いコード を出し続けるか」に移ってきた 8
9. © 2026 UPSIDER.inc Section What is 良いコード？ 「良い」にはいくつかの観点がある • 正しく動く：仕様を満たす • 読みやすい：認知負荷が低い • パフォーマンスが良い：速い、省リソース • 柔軟性が高い：要件の変化・拡張に対応できる ※様々な観点があるが主旨と離れるのでざっくり 9
10. © 2026 UPSIDER.inc Section 我々の文脈での「良いコード」 新規社内サービスの立ち上げ = 不確実性が高い • 要件が変わる、増える、なくなる、決まっていない • この文脈で最も重要なのは要件の変化に対応できる こと ◦ もちろん正しく動き、読みやすく、パフォーマンスも良いほど嬉しいのは前提で ➡ そのためには適切なモジュール化とアーキテクチャルールの遵守が必要 ➡ ここでは コードが「正しく動く状態で、ルールが守られ、秩序が保たれている状態」 を「治安が良い」 と呼びます 10
11. © 2026 UPSIDER.inc Section 治安を悪くする実装 🤖 AIで速く作れるようになった一方で、治安が悪化しやすくもなった 例えばこんな経験… • 古い書き方を提案される • コードベースの悪癖を増幅する • 既存アーキテクチャの構成を無視する実装 11
12. © 2026 UPSIDER.inc Section 治安を悪くする実装 🤖 AIで速く作れるようになった一方で、治安が悪化しやすくもなった 例えばこんな経験… • 古い書き方を提案される • コードベースの悪癖を増幅する • 既存アーキテクチャの構成を無視する実装 ➡ 実害は少ないがノイズになる、秩序が保たれない interface{} tt := tt for i := 0; i < 5; i++ 12 go fixのblogが公開されたよ！ https://go.dev/blog/gofix
13. © 2026 UPSIDER.inc Section 治安を悪くする実装 🤖 AIで速く作れるようになった一方で、治安が悪化しやすくもなった 例えばこんな経験… • 古い書き方を提案される • コードベースの悪癖を増幅する • 既存アーキテクチャの構成を無視する実装 ➡ return err のラップ忘れを「プロジェクトのスタイル」として量産 TODOコメントを付けている実装やワークアラウンドをそのまま模倣 など... 13
14. © 2026 UPSIDER.inc Section 治安を悪くする実装 🤖 AIで速く作れるようになった一方で、治安が悪化しやすくもなった 例えばこんな経験… • 古い書き方を提案される • コードベースの悪癖を増幅する • 既存アーキテクチャの構成を無視する実装 ➡ 依存関係の方向を無視した参照 domain の struct に技術要素が入る など... 14
15. © 2026 UPSIDER.inc Section Rules / Skills で防げるのでは？ お察しの通り、Rules / Skills を整えれば一定の治安維持は可能だが...？ • コンテキスト量や指示の仕方等で、Rulesが無視される。非決定的 • 人の手による実装では、ソフトな制約はすり抜けられる • 全パターンを自然言語で網羅するのは難しい ➡ Rules / Skills だけでは治安は保ちきれないことを想定しておく ガードレールとしてのハード制約が必要 15
16. © 2026 UPSIDER.inc Section ソフトとハードで治安を守る 堅牢に治安を守るには、制約の種類を分けて考える • ソフト制約 （破ろうと思えば破れる、非決定的） ◦ Rules / Skills（AIへの指示） ◦ Review（人間 + AI） • ハード制約 （物理的・機械的に破れない、決定的） ◦ コンパイル時に遮断 ◦ CI （違反したらマージ不可） ▪ Test, Lint 16
17. © 2026 UPSIDER.inc Section ソフトとハードで治安を守る 堅牢に治安を守るには、制約の種類を分けて考える • ソフト制約 （破ろうと思えば破れる） ◦ Rules / Skills（AIへの指示） ◦ Review（人間 + AI） • ハード制約 （物理的・機械的に破れない、決定的） ◦ コンパイル時に遮断 ◦ CI （違反したらマージ不可） ▪ Test, Lint 17 ハード制約の話をします
18. © 2026 UPSIDER.inc Section 今回の視点 Go の機能・ライブラリを用いたハード制約で治安を下支えする話 • Goの言語機能・ライブラリ・エコシステム • 依存の制御 • Test,Lint,CIなどの仕組み化 これまでの開発経験や、最近考えているAI開発での速さと治安の良さを 両立させるには？を共有します 18
19. © 2026 UPSIDER.inc Section Architecture: 依存の制御 19
20. © 2026 UPSIDER.inc Section AIは知りすぎるとブレる • コンテキストウィンドウ内のトークン数が増えるにつれモデルの能力が低下する • ソフト制約 (お気持ち) の限界 ◦ 「HandlerからRepositoryを呼ばない」というルールは、自然言語で指示しても守られ ないことがある ◦ レビューで人間が気づいて指摘するのはコストが高い 20 参考：Effective context engineering for AI agents
21. © 2026 UPSIDER.inc Section 依存のコントロール • 「守る」のではなく「物理的に通れなくする」 ◦ 人間のお気持ちやルールに頼らず、ツールで強制 • ハード制約： ◦ internal による外部参照からの守り ▪ pkg/internal/** は pkg/ 配下からしか import できない ◦ Lint で依存ルール違反を落とす ▪ 許可されていないパッケージ間の依存 ▪ 依存の向きが正しくない 21
22. © 2026 UPSIDER.inc Section internal で外部参照から守る 22
23. © 2026 UPSIDER.inc Section Lint で依存ルール違反を落とす 23 ❌ depguard の例
24. © 2026 UPSIDER.inc Section Lint で治安を守る • depguard はgolangci-lint に入ってるため始めやすい ◦ arch-go, go-arch-lint などあるがなんでもいい ◦ ルールを Config as Code で管理できるのが大事 ▪ 落ちたときにAIが自己分析できる • 依存関係に限らず Lint は重要 ◦ 例： errcheck, wrapcheck • 人間はロジックの正しさだけに集中できるようになる 24
25. © 2026 UPSIDER.inc Section コンテキスト制御のための Package by Feature • ドメイン単位 Feature)でパッケージを切る ↔ 技術レイヤーでパッケージを切る 25
26. © 2026 UPSIDER.inc Section コンテキスト制御のための Package by Feature • ✅ Pros ◦ 凝集度が高く、ドメイン特化した Rules / Skillsを管理しやすい ▪ Rules globs: feature_hoge/** ◦ 機能単位では並行開発しやすい • ❓ Cons ◦ マイクロサービス的な設計の難しさが増える ◦ 共通パッケージが肥大化しがち • 組織とフェーズと要件の好みに依る 26 AI文脈ではないが、実用 Go言語 第2版でも Package by Feature が推されている
27. © 2026 UPSIDER.inc Section Testing: AIのハックを防ぐ 27
28. © 2026 UPSIDER.inc Section テストでの課題あるある • 「xxxを実装してテストもして」とするとテストを「通す」ことに最適化しがち ◦ mock.any, mock.anyTimes でのバイパス • 正常系を満たせばOKとしている • エッジケースは考慮漏れ （...人間もやりがち😇） 28
29. © 2026 UPSIDER.inc Section 対策：Fuzzing test でAIに自滅してもらう 🤖💥 • testing.F を活用 • seed corpus の生成は AI が得意 ➡ 「壊す」方向にも AI を使う🔥 29 https://go.dev/doc/security/fuzz/ より引用
30. © 2026 UPSIDER.inc Section 対策：Mutation test で信頼性を担保 • 意図的にコードに変更を加え、テストがちゃんと失敗するかを検証する ◦ if a < b ➡ if a >= b に改変 ◦ 値を改変 const HOGE  1 ➡ const HOGE = 555 ◦ 処理を一部削除 ➡ 落ちるべき時にちゃんと落ちるかを検証し、テストの品質確認・実装ハックを防ぐ (発表者は Go でやったことないので、良いライブラリや知見があれば教えて下さい ...！) 参考： https://stryker-mutator.io/docs/ 30
31. © 2026 UPSIDER.inc Section 対策：モックではなく DBを使う • 実 DB を使ってテストを実行 ◦ testcontainers-go, dockertest • クエリとデータから正しさを担保する • Package by Feature なら TestMain でパッケージ単位のセットアップが完結する ◦ Go のテストはパッケージ単位のプロセス ◦ 結合テストが書きやすい 31
32. © 2026 UPSIDER.inc Section さらなる課題：トレードオフ • DBを使ったテスト、Fuzzing test, Mutation test はどちらも実行時間がかかる ◦ コンテナ起動 + マイグレーション ◦ ランダム値・コード変更生成 • テスト間で干渉するので、DBの起動単位は考える必要がある ◦ 単一：事前に起動しておく ◦ 複数：テスト内で起動（シングルトン、テストスイートごと） ◦ トランザクションを commit しない、 defer rollback の仕組み化 ➡ テスト起動・実行時間 と 複雑性 増 32
33. © 2026 UPSIDER.inc Section テスト戦略・高速化が大事 • テスト戦略 ◦ ユニットテストではモック、コアロジック・結合テストではDB • 開発者体験 ：テストCI を速くしよう ◦ 並列実行 t.Parallel() ◦ cache の活用 ◦ DBを SQLite の in memory に差し替えて妥協 ◦ テストファイル分割 gotesplit ◦ テスト用 seed データをイメージに入れておく ◦ などなど... 33 The Practical Test Pyramid より引用 親の顔より見たテストピラミッド
34. © 2026 UPSIDER.inc Section まとめ • AIによる治安の悪化をいかに防ぐか ◦ ソフト制約とハード制約 • アーキテクチャの構造 ◦ AIがコンテキストを集めやすく理解しやすいパッケージ ◦ internal や Lint での強制 • テスト ◦ ハックを許さない、検出できるようにする • Lint や テストを強制する CI を品質ゲートにしよう 34
35. © 2026 UPSIDER.inc Section … 35
36. © 2026 UPSIDER.inc Section 特に目新しいこと言ってないな 💬 36
37. © 2026 UPSIDER.inc Section …ただの当たり前のプラクティスですよね 💬 37
38. © 2026 UPSIDER.inc Section ただの当たり前の話では？ • そのとおり、ここ数年（数十年？）言われてきたプラクティス ◦ 適切なモジュール化と依存制御 ◦ テストを速く、フィードバックループを短く ◦ 開発者体験CI/CD, Observability への投資 • 目的が変わった ◦ 人間へのルール・エラーログ ➡ AIへの修正プロンプト ◦ 人間の待ち時間 ➡ AIの試行回数 38
39. © 2026 UPSIDER.inc Section なぜ、いま改めて重要なのか • AI によって最も速くなったのは 「実装」フェーズ • ボトルネックが実装の前後にシフト • 実装が爆速になり、元々あった ボトルネックが AI によって露呈し 増幅されている 39
40. © 2026 UPSIDER.inc Section 開発者体験 = エージェント体験 “The Venn Diagram of Developer Experience and Agent Experience is a circleˮ “「開発者体験とエージェント体験のベン図は円である」 ˮ 40 — Laura Tacho martinfowler.com Fragments: February 13 より
41. © 2026 UPSIDER.inc 41 開発者体験 = エージェント体験
42. © 2026 UPSIDER.inc Section Goと開発者体験 • 標準機能が豊富ですぐ実行可能 ◦ run, test, build, mod, vet, generate ◦ ⭐fix: Go チームもAIの古いコード生成を課題視 (ref: https://go.dev/blog/gofix • 高速なビルド、シングルバイナリ • 標準パッケージが厚い ◦ net/http, log/slog, context ◦ 標準で Observability 向上させやすい • 書き方が統一されやすい ➡ これらは全て人間のための設計だが、そのまま AI にも効く 42
43. © 2026 UPSIDER.inc Section まとめ • AI開発では治安維持のガードレールとしてのアーキテクチャ・テスト・ CI が大事 ◦ 開発者体験を上げよう • 開発プロセスは変わっていない、ボトルネックが実装の前後にシフト • 特別な新技術ではない、これまでのプラクティスが AI 時代になお一層効く ◦ 開発者体験の向上 ≒ エージェント体験の向上 • 開発者体験の重要さを考えると Go は最高ってコト!? • AI時代の開発に一緒に取り組んでくれる仲間を募集中です！ We are hiring!! 43
44. © 2026 UPSIDER.inc Section References • https://www.martinfowler.com/articles/exploring-gen-ai/ccmenu-quality.html • https://martinfowler.com/fragments/20260213.html 44