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
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
ボーイスカウトルールでメモリやスキルを改善しよう
Search
azukiazusa
July 14, 2026
Technology
2.9k
6
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
13k
学生時代に熱中したことが、社会人の今も生きている話
azukiazusa1
2
740
AI によるインシデント初動調査の自動化を行う AI インシデントコマンダーを作った話
azukiazusa1
2
1.1k
習慣とAIと環境 — 技術探求を続ける3つの鍵
azukiazusa1
4
1.3k
持続可能なアクセシビリティ開発
azukiazusa1
6
1k
探求の技術
azukiazusa1
7
7.3k
MCP サーバーの基礎から実践レベルの知識まで
azukiazusa1
40
23k
AIと私たちの学習の変化を考える - Claude Codeの学習モードを例に
azukiazusa1
16
7.4k
2025 年のコーディングエージェントの現在地とエンジニアの仕事の変化について
azukiazusa1
29
17k
Other Decks in Technology
See All in Technology
AIに丸投げしないトイル削減 / Eliminating Toil Without Leaving It All to AI
kohbis
4
1k
GoにおけるFFIのこれまでとこれから
goccy
4
1.4k
Code4Lib JAPANカンファレンス2026 開会挨拶 / Code4Lib JAPAN Conference 2026: Opening Remarks
ykiyota
0
250
Azure Cost Management の FOCUS コストデータを迷わず読むための“3つの軸”
tetsuyaooooo
0
160
少人数データチームのDevin活用実践事例
runandy16
3
460
The Agent Builder Loop from Daily Work to OSS
minorun365
PRO
3
110
なぜSRE・セキュリティは評価されないのか?守りの組織を事業成長エンジンに変えた実践
cscengineer
PRO
3
2.4k
ASTを使って影響範囲を特定する
nealle
0
120
こんなアーキテクチャ図は嫌だ BEYOND THE TIME: 半年後の自分へ贈る15のメッセージ / 15 of Anti-pattern in AWS Architecture Diagrams
naospon
3
280
推論の観測、できていますか? 〜 Google Cloud Gemini Enterprise Agent Platformで 3つの Gemini モデルを実測して踏んだ、評価の罠 〜
shukob
PRO
0
180
Reactの設計論
uhyo
11
3.4k
コーディングエージェントでM5Stack系の開発を少し試した時の話 / M5 Japan Tour 2026 Autumn 東京
you
PRO
0
100
Featured
See All Featured
HTML-Aware ERB: The Path to Reactive Rendering @ RubyCon 2026, Rimini, Italy
marcoroth
4
600
Being A Developer After 40
akosma
91
590k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.8k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
25
2.1k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.9k
sira's awesome portfolio website redesign presentation
elsirapls
0
410
Mind Mapping
helmedeiros
1
350
Building Flexible Design Systems
yeseniaperezcruz
330
41k
Agile Actions for Facilitating Distributed Teams - ADO2019
mkilby
0
280
Understanding Cognitive Biases in Performance Measurement
bluesmoon
32
3k
Bootstrapping a Software Product
garrettdimon
PRO
306
120k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
254
22k
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