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
760
AI によるインシデント初動調査の自動化を行う AI インシデントコマンダーを作った話
azukiazusa1
2
1.2k
習慣とAIと環境 — 技術探求を続ける3つの鍵
azukiazusa1
4
1.3k
持続可能なアクセシビリティ開発
azukiazusa1
6
1.1k
探求の技術
azukiazusa1
7
7.5k
MCP サーバーの基礎から実践レベルの知識まで
azukiazusa1
40
23k
AIと私たちの学習の変化を考える - Claude Codeの学習モードを例に
azukiazusa1
16
7.5k
2025 年のコーディングエージェントの現在地とエンジニアの仕事の変化について
azukiazusa1
29
17k
Other Decks in Technology
See All in Technology
「とりあえず動く」の先へ。 AI時代のチーム開発と内部設計/2026-slsdays
slsops
0
140
ファミコンでPHPを動かす / PHP on the Famicom side b
tomzoh
0
130
データ品質を壊しながらSnowflakeのAIに分析させてみた
kawanago
0
500
AIアプリを使い分けるための共通ツール基盤を考えてみる#devio2026
osawa
0
250
あなたの知らないAmazon VPC Route Server/Amazon VPC Route Server you don't know about
masakiokuda
2
220
大阪オフィスに Unitree Go2 がやってきたので Physical AI やってみた
dafujii
0
300
並行性の問題を防げ!実践トランザクション入門
occhi
0
260
使いこなすために知っておきたい Azure SRE Agent アンチパターン
torumakabe
2
340
おそらく日本で唯一のDevRelインターン生として
husengs7
0
170
Google Cloud Next Tokyo 26登壇時のスクリプト
recruitengineers
PRO
0
190
メルペイ 会計システム概要と歴史
mewuto
0
150
AgentCoreで実践するハーネスエンジニアリング
yakumo
1
280
Featured
See All Featured
How GitHub (no longer) Works
holman
316
150k
Agile that works and the tools we love
rasmusluckow
331
22k
The Spectacular Lies of Maps
axbom
PRO
1
1.1k
Tell your own story through comics
letsgokoyo
1
1.1k
Principles of Awesome APIs and How to Build Them.
keavy
128
18k
Faster Mobile Websites
deanohume
310
32k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
17k
SEOcharity - Dark patterns in SEO and UX: How to avoid them and build a more ethical web
sarafernandez
0
300
Chasing Engaging Ingredients in Design
codingconduct
0
340
Pawsitive SEO: Lessons from My Dog (and Many Mistakes) on Thriving as a Consultant in the Age of AI
davidcarrasco
0
250
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.8k
Paper Plane (Part 1)
katiecoart
PRO
2
11k
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