Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ボーイスカウトルールでメモリやスキルを改善しよう
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
azukiazusa
July 14, 2026
Technology
9
0
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
620
AI によるインシデント初動調査の自動化を行う AI インシデントコマンダーを作った話
azukiazusa1
2
1k
習慣とAIと環境 — 技術探求を続ける3つの鍵
azukiazusa1
4
1.3k
持続可能なアクセシビリティ開発
azukiazusa1
6
990
探求の技術
azukiazusa1
7
7.2k
MCP サーバーの基礎から実践レベルの知識まで
azukiazusa1
40
22k
AIと私たちの学習の変化を考える - Claude Codeの学習モードを例に
azukiazusa1
16
7.2k
2025 年のコーディングエージェントの現在地とエンジニアの仕事の変化について
azukiazusa1
29
17k
Other Decks in Technology
See All in Technology
地域 SRE コミュニティ最前線 / SRE NEXT 2026 Discussion Night Track C
muziyoshiz
0
160
どうして今サーバーサイドKotlinを選択したのか
nealle
0
210
AIで政治は変わるのか? — 中高生と考えたAI時代の民主主義(東海高校サタデープログラム)
eitarosuda
0
400
グローバルチームと挑むプロダクト開発
sansantech
PRO
1
160
AIDLC_ヤフーショッピングの取り組み
lycorptech_jp
PRO
0
560
知見・人・API・DB・予算 ─ ナイナイ尽くしだった人事データ整備 with dbt、5年間の学び
ken6377
1
170
SRE Lounge Hiroshimaへの招待
grimoh
0
410
なぜ人は自分のプロジェクトを 「なんちゃってアジャイル」と 自嘲するのか
kozotaira
0
260
ヘルスケア領域における AI 活用と その安全性担保のための取り組み (Leveraging AI in Healthcare and Our Efforts to Ensure Its Safety) - Google I/O Extended Tokyo 2026, July 11, 2026
zettaittenani
0
180
Compose 新機能総まとめ / What's New in Jetpack Compose
yanzm
0
150
AIと共生する開発者プラットフォーム:バクラクのモノレポ×マイクロサービス基盤
sakajunquality
2
2.6k
Keeping applications secure by evolving OAuth 2.0 and OpenID Connect
ahus1
PRO
1
150
Featured
See All Featured
The Director’s Chair: Orchestrating AI for Truly Effective Learning
tmiket
1
210
Large-scale JavaScript Application Architecture
addyosmani
515
110k
Principles of Awesome APIs and How to Build Them.
keavy
128
18k
Writing Fast Ruby
sferik
630
63k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
52
6k
The Art of Programming - Codeland 2020
erikaheidi
57
14k
SEO for Brand Visibility & Recognition
aleyda
0
4.6k
Kristin Tynski - Automating Marketing Tasks With AI
techseoconnect
PRO
0
280
AI Search: Where Are We & What Can We Do About It?
aleyda
0
7.7k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
38
2.9k
Rebuilding a faster, lazier Slack
samanthasiow
85
9.6k
Neural Spatial Audio Processing for Sound Field Analysis and Control
skoyamalab
0
370
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