組織の承認は下りた。個人の環境も整えた。第2部から先で待っているのは、実は一番地味で、一番長く付き合う時間です。毎日Claude Codeと一緒に働く、その中身そのものです。
ところが、多くの人がここで拍子抜けします。何を頼めばいいのか、頼んだあとに何をすればいいのか、出てきたものをどう扱えばいいのか。最初の数週間は、この3つで迷い続けます。
この迷いの正体は、難しい技術課題ではありません。基本ループが体に入っていないだけです。ステップ1、つまり1体のClaude Codeと伴走する段階は、実はたった4つの動作の繰り返しでできています。
第2部のこの4回で、その型を体に入れます。今日は型そのもの、次回は「頼む」の質、その次は学びの持ち越し方、最後にこの段最大の山である「見る」の変え方に取り組みます。全部つながった一本の技術です。
4つの動作に分解する
Claude Codeと働くときの一連の流れは、頼む→働く→見る→直させるの4つに分解できます。
職場に、よく似た構造があります。上司が新人に案件を任せるときの動きです。方針を伝え(頼む)、新人が業務に当たり(働く)、報告を受けて確認し(見る)、修正すべき点は自分で資料を書き直すのではなく指摘して直させる(直させる)。任せることと、丸投げすることは違います。この4動作は、その違いを型にしたものです。
“Delegate, don't dictate. Think of delegating to a capable colleague. Give context and direction, then trust Claude to figure out the details.”
筆者訳指示するのではなく、委任する。有能な同僚に仕事を任せるように考える。文脈と方向性を与え、あとはClaudeが細部を詰めるのを信じる。
ここでいう「文脈と方向性」が頼むの中身、「信じる」が働くの間の態度です。手順を逐一指定するのは、委任ではなく指示です。
この4動作には、もう少し細かい公式版があります。
Anthropicは、まとまった作業を任せるときの手順として、Explore(まず読ませるだけで、変更はさせない)、Plan(詳細な実装計画を立てさせる)、Implement(計画通りに進んでいるか確かめながら手を動かさせる)、Commit(変更を説明つきでコミットし、PRを作らせる)の4段階を示しています。頼む→働くの間に、探らせて計画させるという一段が挟まっている、と見るとわかりやすくなります。
Planの段には、覚えておくと得をする操作が1つあります。Ctrl+Gを押すと、Claudeが立てた計画をエディタで直接開いて、自分の手で書き換えてから先に進められます。計画を承認するかどうかの二択でなく、計画そのものに手を入れる選択肢があるということです。
とはいえ、毎回この4段階を律儀に踏む必要はありません。
“If you could describe the diff in one sentence, skip the plan.”
筆者訳差分を一文で言い表せるなら、計画は飛ばしていい。
やることが一文で言い表せる小さな作業なら、Planを飛ばしてそのまま働くに進んで構いません。逆に、影響範囲が広い作業ほど、Planを挟む価値が上がります。
「働く」の間、何が起きているか
頼んだあと、Claudeは沈黙しているわけではありません。ファイルを読み、コマンドを実行し、必要なら書き換え、また確認する。これを目的が達成されるまで繰り返しています。
“An LLM agent runs tools in a loop to achieve a goal.”
筆者訳LLMエージェントとは、目標を達成するためにツールをループの中で使い続けるものである。
この定義を知っておくと、待っている間の不安が減ります。止まっているように見える時間も、たいていは何かを試している時間です。慣れないうちは経過を眺めているだけで構いません。慣れてきたら、その時間で別の作業に移ってもいい。並列に動かす話は第8回で扱います。
実際の一場面を見てみます。
$この新人向けマニュアルの下書きを、誰でも読める言葉遣いに直して。専門用語は初出のときだけ()で元の言葉を残して。
7箇所の専門用語を平易な言葉に置き換えました。 「リードタイム」は「発注から納品までにかかる日数」に、「エスカレーション」は「上位者への報告」にしています。 修正後の全文を onboarding-manual-v2.md に保存しました。
「見る」で何を見るか
いまの段では、全部読んで構いません。それがこの段の正しい姿です。まだ信頼を積み上げている途中だからです。
ただし、漫然と読むのと、見るべきものを決めて読むのは違います。この段で優先して探すべきは3つです。
1つ目は、事実関係の誤りです。文章が滑らかでも、数字や固有名詞が違っていれば意味がありません。働く人にとって最も譲れないのは、やはりここです。読む目的をこの1点に絞るだけでも、確認の質は上がります。
2つ目は、指示から外れた解釈です。頼んだ内容と違う方向に進んでいないかを確かめます。
3つ目は、次に繋がる気づきです。これは伏線になります。同じ間違いに気づくたびにそれをどこかへ持ち越す方法は、第6回で扱います。
「直させる」で自分の手を止める
見て誤りを見つけても、自分では直さないでください。多くの人がやってしまうのが、自分でそこだけ直してしまうことです。その場は速い。しかし、これを続けると、Claudeは何が間違いだったのかを一度も知らないまま、あなたが永遠に同じ修正を繰り返すことになります。
“When Claude makes mistakes, debug your workflow, not the model.”
筆者訳Claudeが間違えたら、直すべきはモデルではなく、あなたのワークフローの方だ。
その場は速い。ただし、次も同じ誤りが起きます。知識はあなたの頭の中だけに残り、Claudeには何も伝わりません。
その場は少し遅い。ただし、次の依頼にはその指摘が反映されます。積み重なるのはこちらだけです。
遅く見える方が、実は近道です。この積み重ねが、第6回で扱うCLAUDE.mdの育て方につながります。
よくある罠
注意
この段でよく起きる3つの罠
一度に頼みすぎる。目的を1つに絞らず複数の作業を同時に依頼すると、働くの間に何が起きているか把握しづらくなります。
沈黙を怖がって割り込む。働いている途中で不安になって別の指示を挟むと、それまでの文脈が壊れることがあります。
見るを飛ばして直させる。実際に確認せず「たぶん合っているだろう」で次に進むと、この段をやっている意味がなくなります。
今日のまとめ
- 基本ループは「頼む→働く→見る→直させる」の4動作でできている
- 見つけた誤りは自分で直さず、Claudeに直させる。積み重なるのはその選択だけ
- いまは全部見てよい段。見る中身を変えるのは次の山、第7回で扱う
明日のアクション
今日実際に使うタスクを1つ選び、「頼む→働く→見る→直させる」を最後まで意識して通してください。
「見る」で見つけた誤りは、自分で直さず、具体的な指摘の言葉にして書き出してください。
それがそのまま、次回学ぶ「意図の渡し方」の練習になります。