Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
ボーイスカウトルールでメモリやスキルを改善しよう
Search
azukiazusa
July 14, 2026
Technology
3k
7
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
ボーイスカウトルールでメモリやスキルを改善しよう
エージェントがより効率よくタスクを達成できるように、日常のタスクの中で徐々にメモリやスキルを改善していこうという話です。
azukiazusa
July 14, 2026
More Decks by azukiazusa
See All by azukiazusa
フロントエンドの相手が変わった - AIが加わったWebの新しいインターフェース設計
azukiazusa1
35
14k
学生時代に熱中したことが、社会人の今も生きている話
azukiazusa1
2
750
AI によるインシデント初動調査の自動化を行う AI インシデントコマンダーを作った話
azukiazusa1
2
1.2k
習慣とAIと環境 — 技術探求を続ける3つの鍵
azukiazusa1
4
1.3k
持続可能なアクセシビリティ開発
azukiazusa1
6
1.1k
探求の技術
azukiazusa1
7
7.4k
MCP サーバーの基礎から実践レベルの知識まで
azukiazusa1
40
23k
AIと私たちの学習の変化を考える - Claude Codeの学習モードを例に
azukiazusa1
16
7.5k
2025 年のコーディングエージェントの現在地とエンジニアの仕事の変化について
azukiazusa1
29
17k
Other Decks in Technology
See All in Technology
ログラスのマルチプロダクトを 支える認証基盤 〜テナントごとに異なる統制とどう向き合うか〜
dada4386
3
290
ビジネスを止めない技術的負債の返済のための戦略とその手法 - 技術的負債と向き合う / Complexity and Simplicity
soudai
PRO
1
260
AI臭い文章とは何なのか
nasuvitz
36
76k
大阪オフィスに Unitree Go2 がやってきたので Physical AI やってみた
dafujii
0
190
雪かき部 #7 もう怖くない!SELECT文!
foursue
0
270
人にやさしく、AIにやさしく、書き手を選ばないIaCのガードレール再考 / Rethinking IaC Guardrails for Humans and AI Alike
kohbis
5
1.9k
Argo CDとAtlantisで実現するインフラ管理のセルフサービス化──小規模SREチームで支えるプラットフォーム
cassius7
0
260
1人アドミンな私はAWSアカウント申請をSlackで完結したい!
ysuzuki
0
110
20260929_AmazonGuardDutyの検出通知メールにAWS DevOpsAgentの調査結果を追加する
yhana
1
390
ボードゲームの遊び相手をFoundation Modelsで作る / iOSDC Japan 2026
genda
0
240
Claude起点の仕様駆動開発
tanakaseiya
0
250
高負荷プロダクション環境におけるAWS Lambdaのリアル 〜スケールとコストを左右する実行ライフサイクルの技術仕様〜
maimyyym
2
840
Featured
See All Featured
SERP Conf. Vienna - Web Accessibility: Optimizing for Inclusivity and SEO
sarafernandez
2
1.6k
Un-Boring Meetings
codingconduct
0
430
Become a Pro
speakerdeck
PRO
31
6.3k
Test your architecture with Archunit
thirion
2
2.4k
The SEO Collaboration Effect
kristinabergwall1
1
580
Speed Design
sergeychernyshev
33
2.1k
A Soul's Torment
seathinner
8
3.7k
How to Build an AI Search Optimization Roadmap - Criteria and Steps to Take #SEOIRL
aleyda
1
2.2k
Hiding What from Whom? A Critical Review of the History of Programming languages for Music
tomoyanonymous
3
1.3k
The Limits of Empathy - UXLibs8
cassininazir
1
690
Measuring Dark Social's Impact On Conversion and Attribution
stephenakadiri
2
290
Leading Effective Engineering Teams in the AI Era
addyosmani
9
2.7k
Transcript
リ フ ァ ク タ リ ン グ の た
め の ト ー ク ン 節 約 術 ボーイスカウトルールで メモリやスキルを改善しよう エージェントの迷いを減らしてトークン節約 azukiazusa · 2026.07.16
自己紹介 azukiazusa ▸ Frontend Engineer ▸ https://azukiazusa.dev ▸ 週に 1
回、Web 開発と AI の記事 を書いています ▸ FE(フロントエンド | ファイアー エムブレム)が好き ▸
エージェントの迷いは、トークンの浪費 「迷い」を減らすことが、そのままトークン節約になる タスクの遂行がスムーズに進められないと、余計なトークンを消費する ▸ 探索・試行錯誤・失敗からのリトライ ▸ 同じパターンのコードを実装するのに、毎回同じ調査をさせている ▸ 間違ったコードへの手直し指示 ▸
迷いの多くの原因はプロジェクトの暗黙知や典型作業の 手順不足 わかっているが、なかなか言語化されなかったり、整理の時間 が取れない プロジェクト特有のルールや暗黙知が CLAUDE.md / AGENTS.md に書かれていな い
▸ 典型的に繰り返す作業の手順がスキルとして明文化されていない ▸
ボーイスカウトルール 来たときよりも美しく 自分が通った場所を、来たときよりも少しでも良くして帰る Robert C. Martin「ボーイスカウト・ルール」 『プログラマが知るべき97のこと』 機能追加やバグ修正をした際、ついでに少しだけリファクタリングする ▸ エージェント時代は
CLAUDE.md / AGENTS.md やスキルも同じルールの対象に なる ▸ タスクのついでに、メモリやスキルを少しだけ良くして帰る ▸
手を入れるポイントはエージェントが迷った箇所 タスクの様子を観察して、迷っていた箇所・失敗した箇所を見つける ▸ ハーネスが未整備の初期ほど細かく観察し、整備が進んだら任せていく ▸ マネジメントと同じ ▸ 新人が入ったときはマイクロマネジメントで細かく見て、徐々に任せてマク ロマネジメントに移行する ▸
事例 1: 暗黙知を CLAUDE.md に書いたら一発で正しいコ ードに 課題: トラッキング用のデータ属性はプロジェクト特有のルール。何も伝えないと付 けてくれず、毎回後から手直しを指示していた ##
トラッキング属性のルール ユーザー操作を計測するため、ボタンやリンクなどの インタラクティブ要素には必ず以下の属性を付与する - `data-tracking-id="<画面名>-<操作名>"` 結果: CLAUDE.md にルールを明文化 → 最初から属性付きのコードが生成される
事例 2: API 追加のたびに、同じ調査を繰り返していた apiClient → service → hooks プロジェクトのフロントエンドから
API を呼び出すとき、apiClient → service → hooks というレイヤー構造になっている ▸ API 追加のたびに、このレイヤー構造の調査から作業が始まっていた ▸ 各レイヤーでテストを書くルールが守られないことがあった ▸ service 追加時に必要な作業が漏れて失敗することが何度かあった ▸
手順をスキル化する --- name: add-api description: フロントエンドに API 呼び出しを追加する手順 --- 1.
apiClient にエンドポイントの型と定義を追加 2. service に変換ロジックを実装し、テストを書く 3. hooks から service を呼び出し、テストを書く 4. `npm run typecheck && npm run test` で検証する 事前調査なしですぐに作業へ着手できるようになった ▸ 手順と検証方法が明文化され、作業漏れによる失敗が減った ▸
スキルはエージェント自身に書かせる 今行った作業と私からのフィードバックを元に、 次回から実行できるスキルとして保存して タスク完了直後ならコンテキストが残っている ▸ タスクの帰り際にスキルを 1 つ残す = ボーイスカウトルールを片手間にできる
▸
改善はタスクと同じコミット / PR に含める ついでのリファクタリングと同じようにメモリ・スキルの差分もそのまま PR へ ▸ 「改善のための専用タスク」を作ると優先度が下がり、結局やらなくなる ▸
日常の開発の中で少しずつコード品質を向上させられる ▸
削るのもボーイスカウトルール メモリやスキルは読み込まれるだけでトークンを消費する ▸ 使われないものは定期的に掃除することが大事 ▸ 言語規約や一般論は書かず、プロジェクト特有の暗黙知を中心に書く ▸ 汎用スキルは個人インストールと重複しやすい — 例:
PR 作成スキル ▸
まとめ エージェントの「迷い」はトークンの浪費 — 迷った箇所がメモリ・スキルの改善 ポイント ▸ 暗黙知は CLAUDE.md へ、繰り返し作業はスキルへ —
ボーイスカウトルールで少 しずつ改善 ▸ ただ追加するだけでなく、一般論や重複は削るなど継続的な改善を ▸
T H A N K Y O U ご清聴ありがとうございました azukiazusa.dev