AIと共に生きる技術選定 2026

@Go Connect #12

Transcript

1. © YAMASHITA, LTD. All rights reserved. AIと共に生きる技術選定 2026 Go Connect #12 2026年4月22日
2. © YAMASHITA, LTD. All rights reserved. 自己紹介 • 2025年7月 ヤマシタ入社 • 在宅介護領域の基幹システム内製化 o フルサイクルエンジニア o 採用 • Go / Serverless • 植物 o アガベ o ビカクシダ • 猫 o Lambda (♀4歳) Sugar Sato (@satoIsSugar) 2
3. © YAMASHITA, LTD. All rights reserved. 会社概要と現状　　事業領域 • 業界最大規模 • 30年の歴史・全国 78拠点以上 • 大手で唯一の年中無休対応 【福祉用具レンタル・販売】 • 全国6拠点8工場体制で　 　　　　　　　　　 トラブルや災害時にも、安定供給を実現 • 契約継続率 　 99.9％ 【リネンサプライ】 3
4. © YAMASHITA, LTD. All rights reserved. HCシステム構成概要図 4 内勤アプリ 外勤アプリ 営業向け 配送向け 事務向け SC向け 内勤アプリ用BFF 外勤アプリ用BFF 顧客基盤（CRM） 社員情報基盤 請求・受注基盤 SCM基盤 MDM （マスターデータ管理） 顧客基盤（CRM） DB 社員情報基盤DB （EntraID） 請求・受注基盤 DB SCM基盤DB DWH/データレイ ク (Fabric, notion) MCP ダッシュボード (Fabric/PowerBI) 外部システムI/F (API・サービス） ケアプラン連携 介護保険請求 利用者アプリ 利用者アプリBFF MCP/API 外部AIエージェ ント フロント層 BFF層 基幹Sys 層（API 層） DB層 エンドユーザー Copilot（テキスト・音声・ AI Agent） 凡例）点線 ... 直接参照もある が、補完的な利用 Copilot（テキスト・ 音声・AI Agent） (個別アプ リ) Power Platform / Dify MCP/API MCP/API MCP/API
5. © YAMASHITA, LTD. All rights reserved. 最近、AI 時代に合わせて技術選定の 判断軸が変わってきてませんか ?
6. © YAMASHITA, LTD. All rights reserved. 今日話すこと 6 • AI 時代に加わった「新しい判断軸」 • その軸で動かした技術選定 (複数) • 気づきとしての共有
7. © YAMASHITA, LTD. All rights reserved. 今日話さないこと 7 • 特定ツールの優劣比較 • 全チームに当てはめる推奨論 • "AI を使うかどうか " の議論
8. © YAMASHITA, LTD. All rights reserved. ということで、 AI 時代に合わせて 技術選定を見つめ直してみた話をします
9. © YAMASHITA, LTD. All rights reserved. 9 目次 Index 01 技術選定 02 見直した動機 03 深掘り事例 : ent → sqlc 04 同じ軸で動かした他の判断 05 課題感 06 まとめ
10. © YAMASHITA, LTD. All rights reserved. 01 技術選定
11. © YAMASHITA, LTD. All rights reserved. 2026年1月時点の選定 (全体像) • 言語: Go • API: REST • DB: PostgreSQL • Infra: AWS ECS • Web Framework: Echo • ORM: ent • Migration: Atlas • API 仕様: OpenAPI • 自動生成: oapi-codegen (types のみ) • 監視: Datadog + dd-trace • チームは DDD 寄り / 理解しやすさ最優先
12. © YAMASHITA, LTD. All rights reserved. なぜこれを選んだか • Echo ◦ OpenAPI と相性良 ◦ oapi-codegen の事例豊富 • ent ◦ 静的型付け ◦ enttest で軽量テスト ◦ Atlas と一体で schema → migration • Atlas ◦ ent schema から直接マイグレーション生成 ◦ コードとスキーマの単一真実源 • oapi-codegen (types のみ) ◦ フル自動生成だとデバッグ/レビュー理解コストが高い • 共通方針: 過度な抽象化・フル自動生成は避ける
13. © YAMASHITA, LTD. All rights reserved. • ogen (routing / handler 自動生成) ◦ OpenAPI-first を徹底できる強さはある ◦ ただし思想が強い ◦ 手書き routing・DDD 寄り設計と相性が悪い ◦ デバッグ時に「どこで何が起きているか」追いづらい 代替案① 自動生成系
14. © YAMASHITA, LTD. All rights reserved. 代替案① FW • Gin ◦ 利用者は多く実績も十分 ◦ handler が error を返さない ◦ domain error を return err で伝播して中央の ErrorHandler で型判定する Echo のようなパターンが取りづらい ◦ middleware で後追いする設計にはできる ▪ がしかし、c.Errors は any 相当で型の恩恵が薄れる • Chi ◦ net/http 寄りで良い選択肢 ◦ Echo の方がチーム運用に合致
15. © YAMASHITA, LTD. All rights reserved. 代替案② ORM 系 • sqlc / sqlx ◦ SQL 主導で強力 ◦ 当時はスキーマ駆動 (ent + Atlas)と方向性が違うと判断 → 不採用 • GORM ◦ 学習コスト低いが、ORM がドメイン層に侵食しやすい ◦ interface が多くブラックボックス化 • ent — 採用 ◦ 静的型付け ◦ enttest ◦ Atlas 連携で綺麗にはまる選択肢だった
16. © YAMASHITA, LTD. All rights reserved. 02 見直した動機
17. © YAMASHITA, LTD. All rights reserved. 見直した動機は 2 つ • ① 人が書く時間の価値が変わってきた • ② 生成物の量が AI のコンテキストを圧迫していくため
18. © YAMASHITA, LTD. All rights reserved. 動機① 人が書く時間の価値が 変わってきた
19. © YAMASHITA, LTD. All rights reserved. 動機① — 従来の最適化ポイント • IDE 補完で型を頼りにサクサク書ける ◦ (NeoVimなんで自分はあんまり関係ないが...) • 関連テーブルもオートナビで辿れる • "人が快適に書くこと" を最優先していた
20. © YAMASHITA, LTD. All rights reserved. 動機① — 崩れた前提 • コードを書く主体が AI に移りつつある ◦ 作業工数の削減 ◦ 大きな変更もどんとこい • 人のキータイプ速度はボトルネックではない • "人の書きやすさ" の価値は相対化
21. © YAMASHITA, LTD. All rights reserved. "IDE で書きやすい " より "AI に説明しやすい "
22. © YAMASHITA, LTD. All rights reserved. 動機② 生成物の量が AI のコンテキスト を圧迫していく
23. © YAMASHITA, LTD. All rights reserved. 動機② — 生成物の量を再評価する • 自動生成物は "書かなくて済むコード " • だが AI にとっては "読まされるコード " • 関係のない生成物ほど、AI のコンテキストを圧迫する
24. © YAMASHITA, LTD. All rights reserved. 動機② — 実測: ent 撤去時の削除量 • ent 関連 -4,489 行 が消えた ◦ stock_query.go 528 行 ◦ mutation.go 667 行 ◦ ent.go 608 行 ◦ etc… • 今後もっとテーブルが増えてくると AI に渡すコンテキストを圧迫しそう。。。
25. © YAMASHITA, LTD. All rights reserved. 動機② — コンテキスト圧迫が効いてくる場面 • schema 変更時の差分 PR レビュー負担 • AI に読ませる時の token 消費 • "関係ない自動生成コード" がコンテキストを食う
26. © YAMASHITA, LTD. All rights reserved. "たくさん生成してくれる " の意味が変わった 🙌
27. © YAMASHITA, LTD. All rights reserved. 03 深掘り事例 : ent → sqlc
28. © YAMASHITA, LTD. All rights reserved. 判断軸を当ててみた • ent ◦ 生成物が多く、AI コンテキスト圧迫が高い • sqlc ◦ 生成物は必要分、SQL は人が書く • "人は仕様を書く / AI は実装を書く " に噛み合う
29. © YAMASHITA, LTD. All rights reserved. tree 比較: ent vs sqlc
30. © YAMASHITA, LTD. All rights reserved. ent の強みと弱みの再評価 • 従来軸での強み ◦ enttest (sqlite) で軽量な repository テスト ◦ 静的型付けが効く ◦ IDE 補完でサクサク ◦ Atlas と一体でスキーマ管理が綺麗 • 新軸での致命傷 ◦ 生成物が大きすぎる ▪ AI のコンテキストを圧迫 → 結論: 従来では有利でも、未来で不採用になりうる
31. © YAMASHITA, LTD. All rights reserved. ORM を変えるだけで、こんなに減る • ent → sqlc の移行で ◦ ent 関連 ≒4,500 行 ◦ sqlc 関連 ≒400 行 • 差分はそのまま AI が読む量の削減 • schema は 1 つしかないのに、この規模 ◦ 試しに43 schema 追加したブランチ ▪ ent 生成物が +334,106 行 に膨らんだ
32. © YAMASHITA, LTD. All rights reserved. コード比較: ent vs sqlc
33. © YAMASHITA, LTD. All rights reserved. 今: 人が書くのは SQL そのもの
34. © YAMASHITA, LTD. All rights reserved. 全てのコードに意味がある 状態を目指す 自動生成の "ついで" を排除
35. © YAMASHITA, LTD. All rights reserved. • 手放したもの ◦ 軽量な enttest（sqlite） ◦ クエリビルダーの IDE 補完 ◦ Edge() での暗黙リレーション辿り • 得たもの ◦ Raw SQL による透明性（AI が読める仕様） ◦ testcontainers-go で本番相当の検証 ◦ コンテキスト圧迫の解消（≒▲4,500 行） • 変わらず残ったもの ◦ Atlas によるスキーマ 判断のバランス — 移行の等価交換
36. © YAMASHITA, LTD. All rights reserved. 04 同じ軸で動かした他の判断
37. © YAMASHITA, LTD. All rights reserved. ORM だけじゃない • 同じ「AI が扱いやすいか」軸で見直したもの • 共通項: "人が仕様 / AI が実装" を徹底する • 共通項: AI が必要な情報を取りやすくする
38. © YAMASHITA, LTD. All rights reserved. 判断例① ドキュメントの分割配置 • OpenAPI を paths.yaml と components.yaml に細分化 • CLAUDE.md / .agents/docs/ を階層別に分散 (45 ファイル規模) • 目的: AI が必要な部分だけ読み込む
39. © YAMASHITA, LTD. All rights reserved. 判断例② MCP を積極的に導入 • context7 / serena / postgres などの MCP • AI が自律的にドキュメント・コードを探せる • "人が AI のために情報を集める" を減らす
40. © YAMASHITA, LTD. All rights reserved. 判断例③ AI の癖を剥がす運用 • スキルで AI 生成の冗長を削る • depguard でレイヤー違反を機械的にブロック • AI と一緒に書くための "ガードレール"
41. © YAMASHITA, LTD. All rights reserved. 05 課題感
42. © YAMASHITA, LTD. All rights reserved. 課題感(軸を動かしたあと) • SQL を "書ける人" の価値が戻ってきた(教育コスト) ◦ とはいっても基本的には AI がコーディングするので小さい問題 • sqlc でも限界はある ◦ 動的クエリ ◦ Null 型変換 ◦ JOIN 命名 • AI 時代向けのドキュメント運用コストが発生
43. © YAMASHITA, LTD. All rights reserved. 今の正解は暫定解 AI の進化で判断軸はまた動く
44. © YAMASHITA, LTD. All rights reserved. 06 まとめ
45. © YAMASHITA, LTD. All rights reserved. 変わった判断軸の整理 観点 従来 (人中心) 追加すべき軸 (AI 中心) 書く体験 書きやすさ 説明しやすさ 生成物の評価 多いほど楽ができる 必要最小限がいい 読まれる対象 IDEでの補完・ナビ コンテキスト効率
46. © YAMASHITA, LTD. All rights reserved. まとめ • "AI が扱いやすいか" を判断軸に 1 つ加えて考えた • 既存の軸を捨てる話ではなく、軸が 1 つ増える話 • 軸を入れると、ORM 以外も一緒に動く
47. © YAMASHITA, LTD. All rights reserved. 判断軸が変われば "当たり前の選択 " も入れ替わる
48. © YAMASHITA, LTD. All rights reserved. Thank You
49. © YAMASHITA, LTD. All rights reserved. 引用・参考リンク • https://echo.labstack.com • https://entgo.io • https://sqlc.dev • https://atlasgo.io • https://github.com/oapi-codegen/oapi-codegen • https://golang.testcontainers.org • https://github.com/jackc/pgx • https://github.com/OpenPeeDeeP/depguard 49