コーディングルールの鮮度を保ちたい 2026-07-10 SRE NEXT 2026 @handlename Nature Inc. 

@handlename Hiroaki Nagata Software Engineer (Backend) & SRE at Nature Inc. 

宣伝 Nature? ホームオートメーションとエネルギーマネジメント やってます 最近 スマートロック を出しました We are hiring! IoT デバイスの開発・製造・販売・運用までひと通 りやってます 👉️ 詳しくはこちら https://nature.global/careers/ 

まえがき このトークについて 今年2月に行われた kamakura.go #8 の再演です https://engineering.nature.global/entry/keep- fresh-go-internal-conventions もともと5分のLT用資料なのでゆっくりしゃべります。 nature kamakura.go で検索すればたぶん出てきます。 

ここから本編 

コンテキスト 

コンテキスト Nature の backend アプリケーション 言語: Go 歴史: 10年くらい 規模: 70万行くらい (vendor/ 除く) Contributor: 100名以上 👉️ 歴史が長くて新旧さまざまなコードが混在してい る! 

コーディングルール 使ってますか？メンテしてますか？ 

コーディングルール なぜ必要？ コード品質担保のため レビューコスト削減のため 最近では AI エージェント に精度高くコードを書かせるため 何をルールとする？ プロダクト固有のルールを定義したい 一般的なルールは公開されているもの を参照すればいい † ‡ Nature では主に Claude Code を使っています。 Google Style Guides や Go Code Review Comments など。 † ‡ 

Nature でのコーディ ングルール運用(過去) Notion の利用 全社共通のナレッジマネジメントツール データベースを作ってそこにルールを登録 機能はしていた 使い慣れたツールによる管理 プロパティでカテゴリ分け・ステータス管理 

Notion 運用時代の課題 1. AI エージェントから参照しづらい Notion MCP を使えば参照は可能だが・・・ 複数ページの取得には複数回の tool 使用が必要 2. メンテナンスコスト 開発メンバーの余力に委ねられていた 開発チームの合意を取る方法が明確ではなかった これらの課題を解決したい。 

課題1: AI エージェントから参照しづらい 

課題1: AI エージェントから参照しづらい ルールを Agent Skill として定義する 「AI エージェントに参照させたいなら、AI エージェントの仕組みに乗っけてしまおう」 Notion のデータベースから Agent Skill (= Markdown) に移行した Skill の説明に従って AI エージェントが適宜参照できるようになった ❯ tree .claude/skills/go-internal-conventions/ .claude/skills/go-internal-conventions/ ├── SKILL.md ├── references │ ├── architecture.md │ ├── comments.md : : │ └── type_design.md └── scripts └── search_conventions.py 

課題2: メンテナンスコスト (誰がメンテナンスするのか？) 

課題2: メンテナンスコスト (誰がメンテナンスするのか？) レビューコメントをもとに コーディングルールを更新する仕組み 「コードレビューでの指摘をルールに反映させよう」 「人がやるのは大変(できたらやってる)なので AI エージェントにやらせよう」 ルールを更新する Agent Skill を定義 直近 N 日間のレビューコメントを拾ってルールに追加 たとえば、直近7日間のレビューコメントからルールを更新するには: いつも通りコードレビューしていればコーディングルールが更新される /update-go-internal-conventions --days 7 

課題2: メンテナンスコスト (どうやって合意を取るのか？) ルールの更新をコードレビューする 「コードレビューを使って合意形成しよう」 1. Agent Skill を GitHub Actions で定期実行 2. 作成された Pull Request を開発メンバーがコードレビュー 3. Approve(=合意)されたらマージ(=採用) いつも通りコードレビューしていればコーディングルールの合意が取れる 

実際に作られる PR 例 レビューしやすいように概要を記載 情報源としたPRのサマリー 

実際に作られる PR 例 追加されたルールの一覧 削除されたルールの一覧 候補には上がったがルール化しなかったもの 

いつも通りコードレビューをしていればコーディングルールが更新されていく！ 

成果 Notion 運用時代と比べて・・・ 未合意のルール: 13 → 0 合意済みのルール: 14 → 47(2月時点) → 69 暗黙知が明文化され、未合意のまま放置されるルールがない状態を保つ仕組みができた 🎉 † だいぶ多くなってきたので、レビューとの矛盾発見とルールの削減を強化したいと考えているところです。 † 

まとめ いつも通りコードレビューしていれば コーディングルールが最新化される仕組みを作った レビューコメントをチームの知識として有効活用できるようになった AIエージェント利用の加速により、レビュー対象の重点を コードそのものからルールに移す 必要性を感じている アプリケーションコードに限らず、 コードレビューを伴う文書全般 に使えるはず