>100 Views
August 31, 26
スライド概要
こちらのイベントで登壇した際のスライドです: https://findy-aiplus.connpass.com/event/401925/
Japanese codewriting ninja
PRESENTATION SLIDES における 決定論的 整備の実践と 「見ない範囲」の広げ方 MOSH Linter/Skills MOSH develops and operates a platform that supports independent creators in selling their services online. © MOSH, Inc.
Yuki Okushi Software Engineer at MOSH (productivity team) Focus on platform engineering (infra/SRE) Rust maintainer (compiler, std library) : LoL (video game) @timeE4ter GitHub: @JohnTitor © MOSH, Inc.
今日の話 における課題 2. 決定論的LinterとSkillsによる解決策 3. MOSHでの成果と課題 1. MOSH © MOSH, Inc.
における開発速度 MOSH デプロイ数43倍 プレビュー環境100↑ 一週間のPRs 280↑ うち半数以上がmerged (エンジニアの人数は業務委託の方含め30人弱) この数のPRsを日常的にレビューしていかなければならない © MOSH, Inc.
レビューの何がしんどいか (共通)見なければいけない観点が多い ドメインや仕様部分 仕様に準拠しているか? コード品質 (経済的コスト含め)パフォーマンスに問題ないか? 危険なマイグレーションをしようとしていないか? コード規約・お作法(a.k.a. 方言) レビューの個人差 (AI特有)人間が書くコードの巧拙とは違う観点でのレビューも必要 今までの文脈を汲んでいるか? 以前指摘したことと同じ罠を踏んでいないか? © MOSH, Inc.
© MOSH, Inc.
での "on the loop" 的解決策 MOSH 1. Lint 2. Skills © MOSH, Inc.
1. 決定論的に指摘できる部分はlintとして持つ 対象 対応策 UI デザインシステムの整備、それに準拠したカスタムBiomeルール作成 OpenAPI Redoclyにカスタムプラグインを追加して運用 DB schema(Prisma) 自作Linter(prisma-strong-migrations)で危険なmigrationを抑制 機械的に判別できる部分はガンガンlintにしてレビュー負荷と揺らぎを減らす © MOSH, Inc.
example: prisma-strong-migrations カラムやindex削除、ユニーク制約の追加などしていないか?(既存データに障る部分) SELECT queryでのテーブル作成など、重いマイグレーションを実行しようとしていないか? © MOSH, Inc.
に落とし込めないものはSkillsでカバーする 2. Lint とはいえ全部をlintとして表現できるわけではない → 自然言語で表現したい部分はSkillsとして定義 → よく指摘するな〜と思った部分などもSkillsに落とし込む 状況に合わせたSkillsを複数定義 e.g. ADR書く用、AGENTS.md(i.e. コード規約)への準拠を確認する用 reviewにseverityを定義して個々人のレビュー差・意図の曖昧さを減らす 重大な違反は [MUST] そうでないものは [IMO] / [ASK] など 結局これってレスポンスいるやつだっけ…?みたいな曖昧さとかをなくす CodeRabbitにもinstructionsとして渡す 人間以外のレビュー品質も担保できる © MOSH, Inc.
example: CodeRabbit 人間/AI問わず指摘事項を標準化 © MOSH, Inc.
成果 整備したルールなど Biome custom rules: 14 OpenAPI rules: 18 Skills: 11 率 月 4-6月: 0.59% 7-8月: 0.078% revert 1-3 : 0.83% © MOSH, Inc.
課題 ルールやSkillsを改善させていくフローが未整備 参考: 修正PRを食べてレビュースキルが賢くなる:Claude Codeによる自己改善サイクル | メル カリエンジニアリング 既存の違反部分をどう楽に修正していくか 現在は導入時の違反箇所はignoreしている 担当チームへの通知やアシストなど ドメインや仕様部分のレビューは人間が介入すべき部分として残している が、この辺りももしかしたら何かしらのアシストはできるのかも? Skillsの強制も完全にやりきれているわけではなく、試験的運用な部分も多い ある程度見えてきたら全員が自然と乗っかっている仕組みにしたい © MOSH, Inc.
まとめ でもPRsめちゃ増えてる それに対してlintとSkillsで対処 → 人が介入する前に(見ない範囲として)ガードレールとして一定以上の品質を担保 結果PRs増えている中revertを要する変更(i.e. 障害)は増えていない or 減少傾向 副産物としてレビューの個人差を埋めるのにも役立っている(いい時代) MOSH © MOSH, Inc.
こちらもどうぞ! 時代における開発生産性と進化可能性を高める技術戦略 / AI DevEX Conference 2026 - Speaker AI Deck コーディングエージェントが実装するUIの品質を上げるためにやったこと ※ 後ほどリンク付きでツイートします! © MOSH, Inc.