---
title: MOSHにおける決定論的Linter/Skills整備の実践と「見ない範囲」の広げ方
tags: 
author: [Yuki Okushi](https://www.docswell.com/user/jtitor)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/3JK9PG6NJD.jpg?width=480
description: こちらのイベントで登壇した際のスライドです: https://findy-aiplus.connpass.com/event/401925/
published: August 31, 26
canonical: https://www.docswell.com/s/jtitor/KN7Q7W-2026-08-31-183903
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/3JK9PG6NJD.jpg)

PRESENTATION SLIDES
における
決定論的
整備の実践と
「見ない範囲」の広げ方
MOSH
Linter/Skills
MOSH develops and operates a platform that supports independent creators
in selling their services online.
© MOSH, Inc.


# Page. 2

![Page Image](https://bcdn.docswell.com/page/LE3WXN6ZE5.jpg)

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.


# Page. 3

![Page Image](https://bcdn.docswell.com/page/8EDK2WV47G.jpg)

今日の話
における課題
2. 決定論的LinterとSkillsによる解決策
3. MOSHでの成果と課題
1. MOSH
© MOSH, Inc.


# Page. 4

![Page Image](https://bcdn.docswell.com/page/V7PK19VVJ8.jpg)

における開発速度
MOSH
デプロイ数43倍
プレビュー環境100↑
一週間のPRs 280↑
うち半数以上がmerged
（エンジニアの人数は業務委託の方含め30人弱）
この数のPRsを日常的にレビューしていかなければならない
© MOSH, Inc.


# Page. 5

![Page Image](https://bcdn.docswell.com/page/2JVVYMZRJQ.jpg)

レビューの何がしんどいか
（共通）見なければいけない観点が多い
ドメインや仕様部分
仕様に準拠しているか？
コード品質
（経済的コスト含め）パフォーマンスに問題ないか？
危険なマイグレーションをしようとしていないか？
コード規約・お作法（a.k.a. 方言）
レビューの個人差
（AI特有）人間が書くコードの巧拙とは違う観点でのレビューも必要
今までの文脈を汲んでいるか？
以前指摘したことと同じ罠を踏んでいないか？
© MOSH, Inc.


# Page. 6

![Page Image](https://bcdn.docswell.com/page/5EGL9G46JL.jpg)

© MOSH, Inc.


# Page. 7

![Page Image](https://bcdn.docswell.com/page/4JQYWXG27P.jpg)

での "on the loop" 的解決策
MOSH
1. Lint
2. Skills
© MOSH, Inc.


# Page. 8

![Page Image](https://bcdn.docswell.com/page/K74WK65PE1.jpg)

1.
決定論的に指摘できる部分はlintとして持つ
対象
対応策
UI
デザインシステムの整備、それに準拠したカスタムBiomeルール作成
OpenAPI
Redoclyにカスタムプラグインを追加して運用
DB schema(Prisma) 自作Linter(prisma-strong-migrations)で危険なmigrationを抑制
機械的に判別できる部分はガンガンlintにしてレビュー負荷と揺らぎを減らす
© MOSH, Inc.


# Page. 9

![Page Image](https://bcdn.docswell.com/page/LJ1YXVWXEG.jpg)

example: prisma-strong-migrations
カラムやindex削除、ユニーク制約の追加などしていないか？（既存データに障る部分）
SELECT queryでのテーブル作成など、重いマイグレーションを実行しようとしていないか？
© MOSH, Inc.


# Page. 10

![Page Image](https://bcdn.docswell.com/page/GJWGNL6K72.jpg)

に落とし込めないものはSkillsでカバーする
2. Lint
とはいえ全部をlintとして表現できるわけではない
→ 自然言語で表現したい部分はSkillsとして定義
→ よく指摘するな〜と思った部分などもSkillsに落とし込む
状況に合わせたSkillsを複数定義
e.g. ADR書く用、AGENTS.md（i.e. コード規約）への準拠を確認する用
reviewにseverityを定義して個々人のレビュー差・意図の曖昧さを減らす
重大な違反は [MUST] そうでないものは [IMO] / [ASK] など
結局これってレスポンスいるやつだっけ…？みたいな曖昧さとかをなくす
CodeRabbitにもinstructionsとして渡す
人間以外のレビュー品質も担保できる
© MOSH, Inc.


# Page. 11

![Page Image](https://bcdn.docswell.com/page/4EZL3MYN73.jpg)

example: CodeRabbit
人間/AI問わず指摘事項を標準化
© MOSH, Inc.


# Page. 12

![Page Image](https://bcdn.docswell.com/page/Y76WXND97V.jpg)

成果
整備したルールなど
Biome custom rules: 14
OpenAPI rules: 18
Skills: 11
率
月
4-6月: 0.59%
7-8月: 0.078%
revert
1-3 : 0.83%
© MOSH, Inc.


# Page. 13

![Page Image](https://bcdn.docswell.com/page/G75MX53D74.jpg)

課題
ルールやSkillsを改善させていくフローが未整備
参考: 修正PRを食べてレビュースキルが賢くなる：Claude Codeによる自己改善サイクル | メル
カリエンジニアリング
既存の違反部分をどう楽に修正していくか
現在は導入時の違反箇所はignoreしている
担当チームへの通知やアシストなど
ドメインや仕様部分のレビューは人間が介入すべき部分として残している
が、この辺りももしかしたら何かしらのアシストはできるのかも？
Skillsの強制も完全にやりきれているわけではなく、試験的運用な部分も多い
ある程度見えてきたら全員が自然と乗っかっている仕組みにしたい
© MOSH, Inc.


# Page. 14

![Page Image](https://bcdn.docswell.com/page/9J29XNKMER.jpg)

まとめ
でもPRsめちゃ増えてる
それに対してlintとSkillsで対処
→ 人が介入する前に（見ない範囲として）ガードレールとして一定以上の品質を担保
結果PRs増えている中revertを要する変更（i.e. 障害）は増えていない or 減少傾向
副産物としてレビューの個人差を埋めるのにも役立っている（いい時代）
MOSH
© MOSH, Inc.


# Page. 15

![Page Image](https://bcdn.docswell.com/page/DEY48PNPJM.jpg)

こちらもどうぞ！
時代における開発生産性と進化可能性を高める技術戦略 / AI DevEX Conference 2026 - Speaker
AI
Deck
コーディングエージェントが実装するUIの品質を上げるためにやったこと
※ 後ほどリンク付きでツイートします！
© MOSH, Inc.