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
3.1k
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
770
AI によるインシデント初動調査の自動化を行う AI インシデントコマンダーを作った話
azukiazusa1
2
1.2k
習慣とAIと環境 — 技術探求を続ける3つの鍵
azukiazusa1
4
1.3k
持続可能なアクセシビリティ開発
azukiazusa1
6
1.1k
探求の技術
azukiazusa1
7
7.6k
MCP サーバーの基礎から実践レベルの知識まで
azukiazusa1
40
23k
AIと私たちの学習の変化を考える - Claude Codeの学習モードを例に
azukiazusa1
16
7.5k
2025 年のコーディングエージェントの現在地とエンジニアの仕事の変化について
azukiazusa1
29
17k
Other Decks in Technology
See All in Technology
Temporal 最高!でも改めて「日付」について調べたら人類の負債すぎる件
riyaamemiya
0
230
AIで選択肢が広がった組織設計の理想と現実
konifar
12
5.1k
背中から、背中へ ー 社外コミュニティで学んだ「雑に背中を押す」という恩送り ー / easygoing encouragement and pay forward to community
naitosatoshi
0
320
小規模OSSモデルは サイバーセキュリティ業務に どこまで使えるか
bbrbbq
0
300
【データ横丁主催】AI エージェント時代のTranslytical Data Platform
shisyu_gaku
0
300
国際カードブランドルール変更に伴うクレジットカード決済取引仕様変更について
k1style
0
240
LLM-as-a-Judgeは本当に信頼できるのか――評価器を評価する話
taka_aki
3
1.1k
スクラム祭り2026福井トラック_閉じたループから価値のスパイラルへ
kc_nakanishi
0
170
AI駆動開発におけるハーネスエンジニアリングの勘所
tsukuboshi
1
780
外国人エンジニアがVueプロトタイプで仕様を合わせている話 / Vue Fes Japan 2026 LT
eluwing
0
170
野良MCPサーバーを排除せよ!MCPサーバーのガバナンス
yukiogawa
1
240
sue445's proposals 2026
sue445
0
150
Featured
See All Featured
WCS-LA-2024
lcolladotor
0
920
Leveraging Curiosity to Care for An Aging Population
cassininazir
1
540
Building Better People: How to give real-time feedback that sticks.
wjessup
371
20k
The browser strikes back
jonoalderson
0
1.9k
Writing Fast Ruby
sferik
630
63k
Prompt Engineering for Job Search
mfonobong
0
540
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
128
56k
Bootstrapping a Software Product
garrettdimon
PRO
306
120k
Tips & Tricks on How to Get Your First Job In Tech
honzajavorek
1
810
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
50
10k
Max Prin - Stacking Signals: How International SEO Comes Together (And Falls Apart)
techseoconnect
PRO
0
500
Conquering PDFs: document understanding beyond plain text
inesmontani
PRO
4
3.2k
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