シャドーイング練習: Rethinking Claude Code Best Practices — Lydia Hallie, Anthropic - 動画で英語スピーキングを学ぶ

練習モードを選ぶ

各モードは全画面の練習ルームで開きます。

286 文

文が短すぎたり長すぎる場合は、Editをタップして調整してください。

I had some technical difficulties during my talk this morning.

So I ran back home and I'm just going to record it from my computer instead.

So hi everyone.

I'm Lydia.

I work on the clock code team at Anthropic and the models have gotten really good lately.

So we have Opus 5 .5, which is my favorite daily driver.

And earlier this week, we also launched Fable 5 .2.

And these models are extremely good at long running tasks and understanding your code base.

And especially Fable was also really good at verifying its own output.

But as these models get better, the way that we work with them in Cloud Code also changes.

So earlier this year, I don't know if you remember, but sessions kind of used to look like this.

So we'd use a model like Opus 4 .5, which honestly for its time was really good.

I really enjoyed working with Opus 4 .5.

But compared to today, it would just stop a lot earlier.

So it would just run for shorter amounts of time.

And we'd also keep correcting it.

We'd keep reminding it to do things, add things like importance, exclamation mark, all these things to our CloudMD file.

And also features like auto mode didn't exist yet.

So we were either approving everything manually or taking the riskier approach with dangerously skip remission.

So we were still very much in the loop as humans.

But as these models got better at taking on bigger tasks, our sessions also changed.

So nowadays, at least at Anthropic, our sessions look more like this.

So we're running dozens of sessions at the same time, running for hours, verifying their own results along the way,

and we even have sessions orchestrate other sessions.

So whereas we used to be in the loop for almost every step

and running one or just a couple sessions at a time, we've now essentially become managers for dozens of sessions.

We also get a lot more done, though.

Now, you may have seen our blog post in October about

how Enthropic went from about 2 ,500 changes a day in May to more than 30 ,000 a day in September.

But this also means that we as developers just have to rethink on what we're focused on instead.

So if you think about our best practices from earlier this year, it was mainly about steering sessions,

approving commands, saying no to certain things or restricting what

Cloud could do, checking the output and also starting the sessions.

So everywhere that we now step out of that loop, something else has to take over.

And this is either the model, the harness, or the environment that it's running in.

So if we are not in a loop to approve every command and we're running so many sessions at the same time,

how can we make sure that the code it's writing is still high quality?

And most importantly, if these sessions are running for hours without our supervision, how can we make sure that they're running safely?

So let's go through that by taking this old session

and seeing what we have to change to get to that end result that I showed earlier.

Well, first of all, let's use the actual defaults we start sessions in nowadays.

So that's not really something you should think about.

So let's update the model here from Opus 4 .5 to Opus 5 .5 and change the manual permission to auto mode.

And Opus 5 .5 is a lot better at understanding your intent and understanding your code base.

So we really don't have to steer it as much anymore mid -session.

And you also no longer have to approve every command

because we started making auto mode the default permission mode back in August.

Now being better at understanding your intent and your code base also means

that we have to rethink the instructions we have in our code base.

So if you followed our best practices from earlier this year you may still have things like important

or never do this exclamation mark all these things in your cloud MD file

but with today's models you really don't need that

and it can actually make the model go off track

so you end up with more tool calls and overall a worse results

so nowadays your cloud md file should only include the things

that cloud cannot see from your code

so for example maybe you have a service that's still using some legacy source somewhere

but it's not directly referenced in the code that's still good to keep in there

but everything else like what stack you're on

or where to look you really don't need that anymore

and we actually have a command for this called dr prompt audit

which makes it really easy to optimize your environment for a specific model.

So if you're on Opus 5 .5 here and you run this command,

it will automatically check your CloudMD and your skills to see what the new model no longer needs.

Now auto mode is a permission mode

that runs a separate classifier on pretty much everything that isn't just reading or editing files in your project.

So it automatically allows commands that it knows are safe, like running tests or installing dependencies, but still blocks commands where it's unsure whether they're safe

and normally that's pretty good normally that's kind of you know what we want

but for example here

if we ask it to ship something to staging

we would have just you know approved the push to our deploy repo

but by default auto mode only trusts this folder and this repo

so it would block that command

so we're back in the loop now the defaults should be good in most cases

but if you still notice that you have to approve a lot of commands, even in auto mode.

The first thing to look at is settings here because you can configure auto mode in your own settings, just in plain English.

And this is what gets sent to the classifier, which then decides whether to reject or allow certain commands.

So here we can just write which repos, buckets, domains we trust and what it should always allow or never do.

Okay, so honestly, this was pretty easy by just using today's defaults, we've already gotten rid of most of our in the loop stuff

because the model took over the steering

and auto mode took over all the approving so getting out of the loop is easy.

But the harder question now is how do we make sure it's okay that we're not there anymore?

So first is keeping it safe, and then also verification.

So let's start with keeping it safe, because everything so far, so upgrading the model and using auto mode, it's just working with a model.

And in most cases, it does what you tell it to do, but that's not a guarantee.

So in a study we published back in August, we tested auto mode versus real people in the loop,

and only about 14 % of people caught a clearly dangerous command.

AutoMode blocked 89 % of them, so it is a lot better at it than we were.

But about 1 in 10 of those commands still went through.

So if you do want the guarantee, you can only enforce that in the harness.

And this is where some of our older best practices still matters, and that's permission.

So, for example, if you have a deny rule for a specific tool call in your project,

clot code looks at this rule before the automo classifier even looks at it in fact

if a tool call matches a deny rule the classifier never even sees it

so having deny rules is still the best way to make sure clot actually never does something

but then how do you know what needs to be a

rule in your project versus what the model can just know

because they've gotten so good at it i think it kind of just comes down to

if clot gets this wrong once can i take it back so if it writes the wrong code, you can still revert that.

100

So you can still leave that to the model.

101

But if it throws away our uncommitted changes

102

or it reads a key that's now in your transcript and you don't want that, that should still be a rule.

103

So for example, let's say that we just never want Claude reading our .end file.

104

Now by default, Automode is fine with this.

105

So it would have just approved it.

106

So if you want to make sure that Claude can never read this file, you should just add a deny rule

107

and then commands like cat cannot open this file either

108

but it's not always that straightforward because sometimes certain commands can have side effects

109

so for example let's say

110

that npm test here a very normal command it's just a test

111

so automote runs it that's fine but

112

when the script is running it runs code

113

that you didn't write like your dependencies

114

or maybe clod runs a script real quick

115

that it wrote just to quickly check something so

116

if one of those scripts is compromised it could just open

117

that same end file or your ssh keys

118

and send those to a server you've never heard of right

119

and even if we were still there as humans approving everything honestly we would have just clicked allow

120

because there's nothing to say no to it's just part of the script

121

that in this example case npm test runs and permissions only decide

122

if a tool call runs but they cannot limit what it can reach once it's running

123

so we want to make sure that these kinds of scripts can still run

124

because this is just part of you know how cloud can check its own work running tests

125

so we cannot just block npm tests

126

but we want to limit its side effects

127

so really we just want to limit the environment

128

that it's running in so if you're running it locally

129

or on your own machine you can run commands like

130

that in a sandbox so then you have control over

131

which files in a command it can read

132

which folders it can write to which hosts it can reach

133

and the operating system enforces that also this also applies to everything that command then starts so any child processes

134

so on its own that deny rule got checked by claude before the command runs

135

but all it sees there is npm test so it doesn't see

136

which files that scripts ends up opening but with the sandbox on

137

that same rule gets passed on to the operating system

138

so now when when

139

that dependency tries to open our end file the operating system just doesn't let it

140

and by default it can still read most of your machine

141

so you'd want to add another rule for your ssh keys

142

if you care about that um and it also cannot reach a host

143

that wasn't approved but the sandbox only covers the shell commands

144

that cloud runs and whatever those start but claude's own files your mcp servers

145

and all of your hooks still run outside of it

146

so the rest of your session still runs on your own machine

147

and everything that's on there

148

so ideally you want this whole thing to run somewhere where none of

149

that is even there in the first place and

150

that is a cloud session

151

because there it gets its own machine with a fresh copy of a repo

152

and this runs even when we close our laptop

153

which is definitely something you want for these longer running sessions

154

that run for hours so in this case this automatically gets rid of the end file issue

155

because it's not in git and neither are my ssh keys

156

or our github token and if it still needs an api key uh you can add

157

that as a network secret where it will it will tell you like hey

158

i'm missing an api key mid -session um

159

so it can use it without actually ever sending it to the model

160

and by default also in a cloud session network access is limited to things like package registries and github

161

so you have to explicitly add those domains to your environment for claw to to reach other hosts okay

162

so with a cloud session we can run these long running sessions even with our laptop closed

163

and it keeps us safe

164

because it runs in its own environment now it's still good to remember

165

that this machine is disposable but the things that leave it aren't

166

so a commit that pushed or a message it sent through a connector

167

so we still run it in auto mode with our deny rules just commit it into the repo

168

so they come along so it could still catch things like a force push

169

or a secret and a commit all that kind of stuff

170

and beyond just safety we also need to make sure

171

that Claude is actually working on the right thing

172

so next is verification

173

and the nice thing about being in a loop uh like we kind of knew the work was good

174

because we'd already kind of seen every change we'd proved everything

175

but now if claude works for hours in the background we don't have

176

that anymore and we're not really going to read every file at the end either

177

so you know say

178

that we ask it to move our auth to a new

179

api well claude is very good at understanding what we want

180

but there are still a lot of small decisions

181

that it has to make along the way

182

so with the exact same problems you know one run might move it over

183

but leave the old api in there or one might move it

184

but only for new logins and another one might move it

185

but log everyone out and these all look pretty reasonable

186

but it really helps to set up these verification points along the way

187

so claude keeps verifying its own results and those can be anything

188

that comes back as a pass or fail

189

so tests a build a screenshot whatever you have

190

so now we just want to make sure that we review these verification points.

191

They're a lot shorter to review than if we just had to, you know, review the whole change at the end.

192

So that's pretty reasonable.

193

So if one of these runs would still log everyone out, it doesn't get past that first check,

194

and then it just has to find another way.

195

And there's a couple ways to set this up.

196

The easiest one is, of course, just in your prompt.

197

So, you know, you say what done looks like

198

and ask it to split that into tasks so they have their own tests.

199

And I also like to ask it to show the actual output

200

because you weren't there to see it but again prompting is not a guarantee

201

that a model will do it so for the ones

202

that have to run guaranteed run i would use hooks

203

which are just you know scripts that cloud code runs at a specific point

204

and those give you a lot of control because you decide

205

when they run and what they run and what they check

206

so for example every time it edits a file

207

we can run our linter every time

208

it wants to mark a task as complete we can run the tests for what it changed um

209

so you know if it touch our off code or something.

210

It has to pass the off tests.

211

And when it wants to finish the whole session, we can just run the entire test suite.

212

And if one of those fails, it goes, oh, that's still broken.

213

It goes back until it passes.

214

So it fixes it.

215

Now, just one thing, when a test fails, by default, most tools that exit with a one exit code.

216

But with a one, that task by Cloud Code just gets marked as completed anyway.

217

So make sure that your scripts exit with a two exit code

218

because that's what actually sends cloud back to fix it

219

so okay now we have one session that i'm pretty comfortable with leaving alone

220

so now we can start with a few more of those

221

because they've all got their own machine

222

so they're you know not all working in the same folder

223

and we don't really have to think about work trees too much ourselves anymore

224

but then we still start every session ourselves

225

and we review every one of them

226

and honestly this is already a pretty good place to be

227

we are still fully in control over what gets started and

228

when we call a task done

229

but even there um you know we're still the ones kicking off every session

230

and we're still in the loop for all of them

231

so i think the most important thing to have in place here now is your ci

232

because all of these sessions eventually open a pr

233

and your ci runs the same checks on every one of them no matter how

234

that session was set up or you know what claude decided to do along the way.

235

And if you turn on autofix, we have like CI autofix,

236

Cloud can also see when one of those checks fails and then go back to fix it.

237

So you're not the one spending your review on things that, you know, a check could have already caught.

238

And for some of them, you can even turn on merge when ready.

239

So then GitHub merges the PR once all of the checks have passed.

240

So you're not in the loop to review.

241

But again, that's not the default.

242

And that really depends on how risky the changes

243

so for example on our team every pr gets reviewed by cloud first

244

so not by the session that wrote it

245

so it comes with a fresh context

246

and also a separate group of agents to just double check every bug it finds

247

and then how much we review ourselves just depends on the risk

248

so smaller changes like docs or copy they don't need a person so once the automated checks are green

249

we're pretty good to go.

250

Maybe ordinary product changes just need one reviewer, and then risky changes might need two.

251

Now, ultimately, kind of where we see things going, and we're already kind of doing more of that adnthropic,

252

is that you're not really starting all of those sessions yourself either.

253

Because if you're anything like me, I'm terrible at context switching, so having to manage so many sessions at the same time doesn't always go well.

254

So instead, you just have one main session that's your orchestrator

255

and you can already see this in things like cloud code projects

256

which is still in beta but you just tell it what it needs to be done

257

and the orchestrator splits it up and then starts other sessions for each task

258

and it keeps track of what comes back so it automatically starts

259

and verifies these threads which are just new sessions

260

so instead of talking to eight sessions you're just talking to one

261

and the main session doesn't write the code itself

262

so there you want a model that's really good at deciding what to do

263

and judging what comes back a model like fable and

264

if something comes back that isn't actually done it just you know sends it back

265

so until it's actually done and passes everything

266

and the threads need a model that's good at actually doing the work like opus 55

267

and you can set those separately so you know one model for the main session

268

and then another one for the threads and another benefit is

269

that with this setup with cloud code projects specifically we don't manage context anymore that's all done automatically for us

270

so we no longer have to think about you know

271

when to compact or clear all of that stuff okay so

272

if you look back at those old best practices they're all still there but they've just moved

273

so the model sears it now um auto mode approves your deny rules

274

and the environment restrict what's possible your test your hooks

275

and your ci check set and then ultimately cloud can just start them as well

276

so almost everything we used to do ourselves is now either the model the harness

277

or the environments and we're really just here to start

278

that first one and to just review what comes out so

279

if you want to try this in your own setup

280

i would say just take one thing

281

that's way bigger than you normally give claude make sure your ci actually catches the things you care about

282

and then spend a bit of time just configuring your environment like it's network access it's secret

283

and it's you know setup script and then start in the cloud

284

and see where your sessions get stuck and where you're still in the loop

285

because that's the next thing to hand over to claude

286

i also highly recommend checking out our best practices in the docs as well thank you so much

アプリをダウンロード

流暢に話すために必要なすべて

AI発音採点文ごとに採点

IPA練習すべての音をマスター

単語学習自分の単語帳を作る

単語ゲーム遊びながら覚える

QRをスキャン

Download on theApp Store Get it onGoogle Play

同じチャンネル

Your AI Agent Starts Every Session Like a New Hire - Killian Carlsen-Phelan, Sonar

Daily ConversationUniversity StudentsWorking Adults

The Multi-Agent Architecture That Actually Ships — Luke Alvoeiro, Factory

Business EnglishUniversity StudentsWorking Adults

What Does an AI Engineer Do Now? - Aparna Dhinakaran, Arize AI

Daily ConversationUniversity StudentsWorking Adults

Anthropic's CCA Exam as a Field-Guide for Agentic Engineering — Frank Coyle, UC Berkeley

Business EnglishInterview EnglishUniversity Students

Why Software Factories Fail

Daily ConversationUniversity StudentsWorking Adults

How I deleted 95% of my agent skills and got better results — Nick Nisi, WorkOS

Business EnglishUniversity StudentsWorking Adults

Beyond Code Coverage: Functionality Testing with Playwright — Marlene Mhangami, Microsoft

Business EnglishUniversity StudentsWorking Adults

"Software Fundamentals Matter More Than Ever" — Matt Pocock

Business EnglishUniversity StudentsWorking Adults

Don't Build Agents, Build Skills Instead – Barry Zhang & Mahesh Murag, Anthropic

Business EnglishUniversity StudentsWorking Adults

FOR YOU

このレッスンの語彙とスピーキングのポイント

このスピーキングレッスンは、動画「Rethinking Claude Code Best Practices — Lydia Hallie, Anthropic」を教材にしています。繰り返し出てくる語は次のとおりです：session, model, command, code, cloud。この動画には、シャドーイング用の文が286文、単語が3581語あります。音声の長さは17:31です。話す速さは速く、1分あたり約204語です。音のつながりや弱く発音される音が多くなります。単語の86%は英語の頻出3,000語に含まれます。残りは練習の前に確認しておきましょう。

この動画の重要語彙

動画に出てくる覚えておきたい単語15語を、発音と意味つきで紹介します。

単語	発音	意味
cloud 名詞	/ˈklaʊ̯d/	雲, 雲霞
loop 名詞	/luːp/	ループ
approve 動詞	/əˈpɹuːv/	承認する, 賛成する
default 名詞	/dɪˈfɔlt/	デフォルト
script 名詞	/skɹɪpt/	文書, 文章
deny 動詞	/dəˈnaɪ/	否む, 打ち消す
guarantee 名詞	/ˌɡæɹ.ənˈtiː/	保証
exit 名詞	/ˈɛɡzət/	出口
verification 名詞	/ˌvɛ.ɹə.fɪˈkeɪ.ʃən/	確証, 検証
thread 名詞	/ˈθɹɛd/	糸
output 名詞	/ˈaʊtpʊt/	出力
hook 名詞	/hʊk/	鉤, フック
commit 動詞	/kəˈmɪt/	預ける, 任せる
nowadays 副詞	/ˈnaʊ.ə.deɪz/	現在, 現代では
risky 形容詞	/ˈɹɪski/	危険な

動画に出てくる句動詞

単語	発音	意味
come back 動詞		戻る, 帰る
take over 動詞		引き受ける
check out 動詞		試験する, 検査する
come out 動詞	/ˌkʌm ˈaʊt/	出る
go back 動詞		戻る, 帰る
throw away 動詞		棄てる, 捨てる

この動画の文法

話し手がよく使っている文型を、動画の実際の表現とともに紹介します。

文型	動画での表現
「used to」 used to + 動詞 — 今はもう違う過去の習慣や状態	used to look · used to be · used to do
現在完了形 have/has + 過去分詞 — 過去の出来事が今も関係している	have gotten · we've now essentially become · we've already gotten
受動態 be + 過去分詞 — 誰がするかより、何が起きるかに焦点を当てる	is compromised · wasn't approved · was set

注意したい発音

話し手はwe're, don't, you'reなど、短縮形や弱形を63回使っています。聞こえたとおりの短い形で発音しましょう。

「th」の音: thread /ˈθɹɛd/, rethink /ɹiːˈθɪŋk/, auth /ɔːθ/
「sh」と「zh」の音: verification /ˌvɛ.ɹə.fɪˈkeɪ.ʃən/, essentially /ɪˈsɛnʃəli/, shell /ʃɛl/, instruction /ɪnˈstɹʌkʃən/, supervision /ˌs(j)uːpəˈvɪʒən/
長い単語（アクセントの位置に注意）: verification /ˌvɛ.ɹə.fɪˈkeɪ.ʃən/, dependency /dɪˈpɛndənsi/, essentially /ɪˈsɛnʃəli/, ordinary /ˈɔɹdɪnɛɹi/, difficulty /ˈdɪfɪkəlti/

日本語話者が苦手な音：

/r/ と /l/ の区別 — /l/ は舌先を歯茎につけ、/r/ はどこにもつけない: importantly /ɪmˈpɔɹ.tənt.li/, separately /ˈsɛp.ɹət.li/
/v/ — /b/ にならないように、上の歯を下唇に当てる: approve /əˈpɹuːv/, verify /ˈvɛɹɪfaɪ/, verification /ˌvɛ.ɹə.fɪˈkeɪ.ʃən/, server /ˈsɝvɚ/, versus /ˈvɝsəs/
/f/ — 「フ」ではなく、上の歯と下唇で出す: default /dɪˈfɔlt/, verify /ˈvɛɹɪfaɪ/, verification /ˌvɛ.ɹə.fɪˈkeɪ.ʃən/, folder /ˈfoʊldɚ/, enforce /ɪnˈfoɹs/

この動画での練習方法

まず声を出さずに動画を最後まで聞き、知らない単語をメモします。
まず0.75倍速で一文ずつシャドーイングし、慣れてきたら通常の速度に戻します。
自分の声を録音して元の音声と比べます。cloud, loop, approveなどの単語に特に注意しましょう。

シャドーイングとは？英語上達に効果的な理由

シャドーイング（Shadowing）は、もともとプロの通訳者養成プログラムで開発された言語学習法で、多言語習得者として知られるDr. Alexander Arguelles によって広く普及されました。方法はシンプルですが非常に効果的：ネイティブスピーカーの英語を聞きながら、1〜2秒の遅延で声に出してすぐに繰り返す——まるで「影（shadow）」のように話者を追いかけます。文法ドリルや受動的なリスニングと異なり、シャドーイングは脳と口の筋肉が同時にリアルタイムで英語を処理・再現することを強制します。研究により、発音精度、抑揚、リズム、連音、リスニング力、そして会話の流暢さが大幅に向上することが確認されています。IELTSスピーキング対策や自然な英語コミュニケーションを目指す方に特におすすめです。

シャドーイングのやり方: ステップ別の完全ガイドを読む →

シャドーイング練習: Rethinking Claude Code Best Practices — Lydia Hallie, Anthropic - 動画で英語スピーキングを学ぶ

練習モードを選ぶ

アプリをダウンロード

同じチャンネル

Your AI Agent Starts Every Session Like a New Hire - Killian Carlsen-Phelan, Sonar

The Multi-Agent Architecture That Actually Ships — Luke Alvoeiro, Factory

What Does an AI Engineer Do Now? - Aparna Dhinakaran, Arize AI

Anthropic's CCA Exam as a Field-Guide for Agentic Engineering — Frank Coyle, UC Berkeley

Why Software Factories Fail

How I deleted 95% of my agent skills and got better results — Nick Nisi, WorkOS

Beyond Code Coverage: Functionality Testing with Playwright — Marlene Mhangami, Microsoft

"Software Fundamentals Matter More Than Ever" — Matt Pocock

Don't Build Agents, Build Skills Instead – Barry Zhang & Mahesh Murag, Anthropic

おすすめ動画

How Anthropic uses Claude in Product Management

Armchair Architects: Resiliency in the Cloud – Core Patterns

Did Anthropic Kill Git?

We Let $200 GPT-Pro Think for 7 Days on Unsolved Math

Claude Code Is Wasting Tokens... Microsoft Built a Fix

Sec Growth DataScience staff meeting Sep 14 2022

I Looked Into How Devs Are Actually Using AI

What's New in Zephyr 4.5?

9 Insane Claude Mods I Already Can't live Without

We've got separation of concerns wrong

The last real programmers are dying out...

このレッスンの語彙とスピーキングのポイント

この動画の重要語彙

動画に出てくる句動詞

この動画の文法

注意したい発音

この動画での練習方法

シャドーイングとは？英語上達に効果的な理由