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

4.1K Views

February 21, 26

スライド概要

Ryo Mimura

@r4mimu

スライド一覧

エンジニャ

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

ダウンロード

関連スライド

組織横断支援チームによるFour Keys計測基盤構築と活用に向けた取り組み

Ryo Mimura 35.5K

E2Eテストワークフローを高速化・安定化させる取り組み

Ryo Mimura 27.7K

sansan_vs_cybozu オープニング

Ryo Mimura 484

猫でも分かるUnreal Engineの学び方 - 超初心者向け編 - 2023 v1.0

ue4 ue5 ue-beginner

エピックゲームズジャパン 1.7M

Unreal Engine5 Lumenの仕組みと肝心なところ

ue5 ue-rendering ue-lumen

エピックゲームズジャパン 1.4M

UE5レンダリングフロー総おさらい(2024) 基礎編！[CEDEC+KYUSHU 2024]

ue5 unreal engine ue-rendering

エピックゲームズジャパン 1.2M

各ページのテキスト

Presenter Profile 三村遼 Ryo Mimura) @r4mimu 株式会社UPSIDER ● ● これまで ○ 社内CI/CD基盤・開発生産性 ○ BtoB SaaS プロダクトエンジニア 2025 ○ UPSIDER カード事業部 Backend Engineer ● ランニング🏃 サウナ🧖 飲酒🍻 ● 好きなパッケージ： context © 2026 UPSIDER.inc 2

UPSIDERについてビジョン / ミッション挑戦者を支える世界的な金融プラットフォームを創る UPSIDERはカード会社から、総合金融機関へ © UPSIDER Inc 3

提供サービス一覧 UPSIDERはAI化された総合金融機関へ当社はこれまで決済事業に特化し、お客様の成長をサポートしてきました。しかし今後は総合金融機関として進化していきます。挑戦者を応援する法人カード請求書カード払いサービスグロースデットファンド経営者の挑戦を支える法人カード https://up-sider.com/ https://shi-harai.com/ https://www.upsidercap.com/ https://president-card.com/ Adboost BUSINESS 与信枠の増枠＆広告媒体仕入れの後払いを実現ビジネスリーダー向けコミュニティ経営者のための経理丸投げサービス https://breakthrough-grid.com/ https://ai-keiri.up-sider.com/ 4

実績ユーザー数 100,000社以上 1 売上規模約 100億円 2 年間成長 50%以上を継続 2 *1 当社が提供する全サービスのリリースからの登録企業数の合計、 2025年11月時点。 *2 2025年4月末時点。株式会社UPSIDER ファクトブック 5

Section AIコーディングは当たり前 ● Cursor, Claude Code, Codex, GitHub Copilot,... ● 「仕様を満たす実装」は当たり前に実現してくれる ● 徐々にモデルの間の実装能力の差は縮まっている（気がする）。どのモデルも賢い ● 関心はツール・モデル比較よりも「どうやってチームで安定して良いコードを出し続けるか」に移ってきた © 2026 UPSIDER.inc 8

10.

Section 我々の文脈での「良いコード」新規社内サービスの立ち上げ = 不確実性が高い ● 要件が変わる、増える、なくなる、決まっていない ● この文脈で最も重要なのは要件の変化に対応できること ○ もちろん正しく動き、読みやすく、パフォーマンスも良いほど嬉しいのは前提で ➡ そのためには適切なモジュール化とアーキテクチャルールの遵守が必要 ➡ ここではコードが「正しく動く状態で、ルールが守られ、秩序が保たれている状態」を「治安が良い」と呼びます © 2026 UPSIDER.inc 10

11.

12.

Section 治安を悪くする実装 🤖 AIで速く作れるようになった一方で、治安が悪化しやすくもなった例えばこんな経験… ● 古い書き方を提案される ● コードベースの悪癖を増幅する ● 既存アーキテクチャの構成を無視する実装 go fixのblogが公開されたよ！ https://go.dev/blog/gofix ➡ 実害は少ないがノイズになる、秩序が保たれない interface{} tt := tt for i := 0; i < 5; i++ © 2026 UPSIDER.inc 12

https://go.dev/blog/gofix

13.

Section 治安を悪くする実装 🤖 AIで速く作れるようになった一方で、治安が悪化しやすくもなった例えばこんな経験… ● 古い書き方を提案される ● コードベースの悪癖を増幅する ● 既存アーキテクチャの構成を無視する実装 ➡ return err のラップ忘れを「プロジェクトのスタイル」として量産 TODOコメントを付けている実装やワークアラウンドをそのまま模倣など... © 2026 UPSIDER.inc 13

14.

15.

Section Rules / Skills で防げるのでは？お察しの通り、Rules / Skills を整えれば一定の治安維持は可能だが...？ ● コンテキスト量や指示の仕方等で、Rulesが無視される。非決定的 ● 人の手による実装では、ソフトな制約はすり抜けられる ● 全パターンを自然言語で網羅するのは難しい ➡ Rules / Skills だけでは治安は保ちきれないことを想定しておくガードレールとしてのハード制約が必要 © 2026 UPSIDER.inc 15

16.

Section ソフトとハードで治安を守る堅牢に治安を守るには、制約の種類を分けて考える ● ● ソフト制約（破ろうと思えば破れる、非決定的） ○ Rules / Skills（AIへの指示） ○ Review（人間 + AI）ハード制約（物理的・機械的に破れない、決定的） ○ コンパイル時に遮断 ○ CI （違反したらマージ不可） ■ Test, Lint © 2026 UPSIDER.inc 16

17.

Section ソフトとハードで治安を守る堅牢に治安を守るには、制約の種類を分けて考える ● ● ソフト制約（破ろうと思えば破れる）ハード制約の話をします ○ Rules / Skills（AIへの指示） ○ Review（人間 + AI）ハード制約（物理的・機械的に破れない、決定的） ○ コンパイル時に遮断 ○ CI （違反したらマージ不可） ■ Test, Lint © 2026 UPSIDER.inc 17

18.

19.

20.

Section AIは知りすぎるとブレる ● コンテキストウィンドウ内のトークン数が増えるにつれモデルの能力が低下する ● ソフト制約 (お気持ち) の限界 ○ 「HandlerからRepositoryを呼ばない」というルールは、自然言語で指示しても守られないことがある ○ レビューで人間が気づいて指摘するのはコストが高い参考：Effective context engineering for AI agents © 2026 UPSIDER.inc 20

https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

21.

Section 依存のコントロール ● 「守る」のではなく「物理的に通れなくする」 ○ ● 人間のお気持ちやルールに頼らず、ツールで強制ハード制約： ○ internal による外部参照からの守り ■ ○ pkg/internal/** は pkg/ 配下からしか import できない Lint で依存ルール違反を落とす ■ 許可されていないパッケージ間の依存 ■ 依存の向きが正しくない © 2026 UPSIDER.inc 21

22.

23.

24.

Section Lint で治安を守る ● depguard はgolangci-lint に入ってるため始めやすい ○ arch-go, go-arch-lint などあるがなんでもいい ○ ルールを Config as Code で管理できるのが大事 ■ ● 依存関係に限らず Lint は重要 ○ ● 落ちたときにAIが自己分析できる例： errcheck, wrapcheck 人間はロジックの正しさだけに集中できるようになる © 2026 UPSIDER.inc 24

25.

26.

Section コンテキスト制御のための Package by Feature ● ✅ Pros ○ 凝集度が高く、ドメイン特化したRules / Skillsを管理しやすい ■ ○ ● 機能単位では並行開発しやすい ❓ Cons ○ ○ ● Rules globs: feature_hoge/** マイクロサービス的な設計の難しさが増える共通パッケージが肥大化しがち AI文脈ではないが、実用 Go言語第2版でも Package by Feature が推されている組織とフェーズと要件の好みに依る © 2026 UPSIDER.inc 26

https://www.oreilly.co.jp/books/9784814401369/

27.

28.

29.

https://go.dev/doc/security/fuzz/

30.

Section 対策：Mutation test で信頼性を担保 ● 意図的にコードに変更を加え、テストがちゃんと失敗するかを検証する ○ if a < b ➡ if a >= b に改変 ○ 値を改変 const HOGE  1 ➡ const HOGE = 555 ○ 処理を一部削除 ➡ 落ちるべき時にちゃんと落ちるかを検証し、テストの品質確認・実装ハックを防ぐ (発表者は Go でやったことないので、良いライブラリや知見があれば教えて下さい...！) 参考： https://stryker-mutator.io/docs/ © 2026 UPSIDER.inc 30

https://stryker-mutator.io/docs/

31.

Section 対策：モックではなく DBを使う ● 実 DB を使ってテストを実行 ○ testcontainers-go, dockertest ● クエリとデータから正しさを担保する ● Package by Feature なら TestMain でパッケージ単位のセットアップが完結する ○ Go のテストはパッケージ単位のプロセス ○ 結合テストが書きやすい © 2026 UPSIDER.inc 31

32.

Section さらなる課題：トレードオフ ● ● DBを使ったテスト、Fuzzing test, Mutation test はどちらも実行時間がかかる ○ コンテナ起動 + マイグレーション ○ ランダム値・コード変更生成テスト間で干渉するので、DBの起動単位は考える必要がある ○ 単一：事前に起動しておく ○ 複数：テスト内で起動（シングルトン、テストスイートごと） ○ トランザクションを commit しない、 defer rollback の仕組み化 ➡ テスト起動・実行時間と複雑性増 © 2026 UPSIDER.inc 32

33.

Section テスト戦略・高速化が大事 ● テスト戦略 ○ ● ユニットテストではモック、コアロジック・結合テストではDB 開発者体験：テストCI を速くしよう ○ 並列実行 t.Parallel() ○ cache の活用 ○ DBを SQLite の in memory に差し替えて妥協 ○ テストファイル分割 gotesplit ○ テスト用 seed データをイメージに入れておく ○ などなど... The Practical Test Pyramid より引用親の顔より見たテストピラミッド © 2026 UPSIDER.inc 33

34.

35.

36.

37.

38.

Section ただの当たり前の話では？ ● ● そのとおり、ここ数年（数十年？）言われてきたプラクティス ○ 適切なモジュール化と依存制御 ○ テストを速く、フィードバックループを短く ○ 開発者体験CI/CD, Observability への投資目的が変わった ○ 人間へのルール・エラーログ ➡ AIへの修正プロンプト ○ 人間の待ち時間 ➡ AIの試行回数 © 2026 UPSIDER.inc 38

39.

40.

Section 開発者体験 = エージェント体験 “The Venn Diagram of Developer Experience and Agent Experience is a circleˮ “「開発者体験とエージェント体験のベン図は円である」ˮ — Laura Tacho martinfowler.com Fragments: February 13 より © 2026 UPSIDER.inc 40

http://martinfowler.com

41.

42.

Section Goと開発者体験 ● 標準機能が豊富ですぐ実行可能 ○ run, test, build, mod, vet, generate ○ ⭐fix: Go チームもAIの古いコード生成を課題視 (ref: https://go.dev/blog/gofix ● 高速なビルド、シングルバイナリ ● 標準パッケージが厚い ● ○ net/http, log/slog, context ○ 標準で Observability 向上させやすい書き方が統一されやすい ➡ これらは全て人間のための設計だが、そのままAI にも効く © 2026 UPSIDER.inc 42

https://go.dev/blog/gofix

43.

Section まとめ ● AI開発では治安維持のガードレールとしてのアーキテクチャ・テスト・CI が大事 ○ 開発者体験を上げよう ● 開発プロセスは変わっていない、ボトルネックが実装の前後にシフト ● 特別な新技術ではない、これまでのプラクティスがAI 時代になお一層効く ○ 開発者体験の向上 ≒ エージェント体験の向上 ● 開発者体験の重要さを考えると Go は最高ってコト!? ● AI時代の開発に一緒に取り組んでくれる仲間を募集中です！We are hiring!! © 2026 UPSIDER.inc 43

44.