本記事は、Claude Codeと関連する公式資料を2026年7月26日に再確認して増補しています。
Claude Codeを開く。昨日の続きを頼もうとして、昨日どこまで進んだかを自分で説明し直す。返ってきた答えはよくできている。でも、結果を確かめるのは自分、次の依頼を考えるのも自分。夜に再開すると、また同じ説明から始まる——便利なはずなのに、気づけば「質問文を作る仕事」が増えている。
この一日に心当たりがあるなら、足りないのは高度なプロンプト(=指示文)ではありません。Claude Codeが仕事を受け取り、実行し、確かめ、次回に残すための「小さな運用設計」です。この記事では、その設計の考え方と、5分で試せる小さな実験を紹介します。
結論: 変わる人は「良い質問」より先に仕事の型を渡している
Claude Codeを質問相手から仕事を進める道具へ変えるために、最初から複数のAIや複雑な設定を用意する必要はありません。まず一つの小さな仕事に、次の5点をそろえます。
- 対象——どのファイルや画面を扱うか
- 変更——何をどう変えるか
- 合格条件——何を満たしたら終わりか
- 停止条件——何が起きたら変更せず止まるか
- 証拠——差分、検索結果、テスト出力など何を残すか
Anthropicの公式ガイドも、Claude Codeを質問へ答えて待つチャットボットではなく、ファイルを読み、コマンドを実行し、変更と確認を進められるエージェント型の環境と説明しています。ただし、明確な成功条件がなければ、見た目は正しそうでも動かない結果になり、人が唯一の確認役になり得るとも注意しています。つまり、製品の機能があることと、こちらの仕事が最後まで進むことは別です。(Best Practices for Claude Code)
急いで試したい人は「5分で試せる小さな実験」まで進んでも構いません。毎回の説明を減らしたい人は記憶の節、確認待ちや変更しすぎを直したい人はhooksと権限の節が直接役立ちます。
なぜ「質問箱」で終わるのか
Claude Codeは質問に具体的に答えてくれます。だから「指示を詳しくすれば、いずれ自動で進む」と考えがちですが、質問の精度と運用の安定は別物です。公式ガイドが勧めているのも、長文そのものではなく、対象ファイル、制約、期待結果、テストなどを具体的に渡すことです。曖昧で複数ファイルにまたがる仕事は探索、計画、実装へ分ける一方、誤字修正のように範囲が明確な小作業では重い計画を省く判断も示されています。(Best Practices for Claude Code)
多くの人の使い方はこうです。「このエラーを直して」「この画面を作って」「この文章を要約して」。一つひとつは正しい依頼ですが、依頼同士がつながっていません。前回どの基準で直したか、どこまで確認したか、次回も守るべきことは何か——それが残っていないので、Claude Codeは毎回「初対面の優秀な助っ人」に戻ります。
正確には、Claude Codeには会話を再開する機能や、後述するCLAUDE.md、auto memoryがあります。それでも、決定事項を会話の流れにだけ置いたままでは、新しい文脈や別の仕事へ移ったときに重要な基準が埋もれやすくなります。
原因は主に5つあります。
- 仕事の入口が毎回違う——「いい感じに直して」では、範囲も終わりの基準も毎回変わる
- 実行と検品が混ざっている——作った本人が「できました」と自己判定して見落とす
- 会話を記憶だと思っている——履歴が長くなるほど大事なルールが埋もれる
- 失敗がその場の修正で終わる——ルールに変えなければ似た場面でまた起きる
- 人とAIの責任境界が曖昧——何でも確認して遅くなるか、重要操作まで進んでしまうか
抜け出す鍵は「もっと長い指示文」ではなく、「何を任せるか」「誰が確かめるか」「何を覚えるか」「どこで止まるか」を再利用できる形にすることです。
いま質問箱か、運用かを見分ける3問
- 前回の説明をほぼ繰り返さずに再開できますか。
- 人が途中で次の指示を考えなくても、検品まで進みますか。
- 失敗した理由が、次回の手順へ反映されますか。
1つでも「いいえ」があれば、まだ質問箱の段階です。「いいえ」は失敗ではなく、設計を始める場所が見つかったということです。
単発利用と「運用」の4つの違い
| 観点 | 単発利用 | 運用 |
|---|---|---|
| 入力 | 毎回、人が状況を作文する | 決まった依頼票へ今回の分だけ記入する |
| 完了 | 出力が返れば一区切り | 先に決めた完成条件を証拠つきで満たしたら完了 |
| 記憶 | 会話履歴と人の記憶に頼る | 決定・結果・次回の注意を所定の場所へ残す |
| 例外 | その場で人が考える | 止まる条件と復旧手順を先に決めておく |
一文にまとめると、運用とは「同じ入口から始め、先に決めた終点まで進み、証拠を残し、次回の手間を減らす仕組み」です。自動化とは成功時だけ無人にすることではなく、失敗した時にも安全な場所で止まれることでもあります。
質問を「完了までのループ」に変える5項目
質問箱から抜ける最小単位は、壮大な自動化ではなく、一枚の依頼票です。次の表を埋めるだけでも、Claude Codeが途中で推測しなければならない箇所を減らせます。
| 項目 | 書く内容 | 悪い例 | 改善例 |
|---|---|---|---|
| 対象 | ファイル、画面、範囲 | このページ | src/pages/contact.astroだけ |
| 変更 | 現在と変更後 | いい感じに直す | 見出しの「送信」を「お問い合わせを送る」へ変更 |
| 合格条件 | 終了を判定できる状態 | 問題なければ完了 | 指定文字が1件、旧文字が0件、既存テストが成功 |
| 停止条件 | 勝手に広げない分岐 | 必要なら何でもする | 対象が複数件なら変更せず件数を報告 |
| 証拠 | 人が確認する材料 | 終わったと報告 | 変更ファイル、差分、実行コマンド、終了コード |
コピペ用の最小形は次の通りです。
対象:
この仕事で触ってよいファイルを指定する。
変更:
変更前と変更後を具体的に書く。
合格条件:
検索、テスト、表示など、終わりを判定する方法を書く。
停止条件:
対象が見つからない、複数見つかる、範囲外の変更が要る場合は変更せず止まる。
報告:
変更ファイル、差分の要点、実行した確認、結果を示す。範囲が広い仕事では、最初に読み取りだけで対象を調べ、計画を確認してから変更へ進みます。反対に、対象と差分を一文で説明できる小修正なら、計画書を作ること自体が新しい手間になります。大切なのは工程数を増やすことではなく、間違った対象へ進む前に分岐を置くことです。
完了の証拠を「感想」から「機械が読める信号」に変える
「対応しました」「問題ありませんでした」は報告ですが、それだけでは検証結果ではありません。Claude Code自身が合否を読み取れる信号を渡すと、作業、確認、修正のループを同じ依頼の中で回しやすくなります。公式ガイドは、テスト、リンター(=書き方や誤りを機械で調べる道具)、期待する出力、画面のスクリーンショットなどを例に挙げています。(Best Practices for Claude Code)
| 仕事 | 弱い完了報告 | 読み取れる証拠 |
|---|---|---|
| 文言変更 | 直しました | 対象の差分、旧文字0件、新文字1件 |
| 不具合修正 | 動くと思います | 再現テストが修正前に失敗し、修正後に成功した出力 |
| 画面調整 | 見やすくしました | 変更前後の同じ幅の画面、はみ出し0件 |
| 設定変更 | 設定しました | 読み込まれた設定値と、対象コマンドの終了コード |
| 調査 | おそらく原因はこれです | 対象ファイル、該当行、再現条件、反例 |
Gitを使うプロジェクトなら、git diff -- 対象ファイルで作業前後の差を対象ファイルに限定して確認できます。Git公式は、git diffを作業中のファイルと記録済み状態などの差を表示するコマンドとして説明し、パスを指定すれば表示対象を絞れるとしています。(git-diff Documentation)
複数人のプロジェクトでは、証拠を会話だけに残さず、継続的インテグレーション(CI=変更のたびに検査を動かす仕組み)へ移す方法もあります。GitHubのstatus checksは、ビルド、テスト、コード検査などの結果を表示し、保護されたブランチで必須にすると、成功するまでマージを止められます。AIが「成功した」と言ったかではなく、外側の検査結果を門にできます。(Status checks)
ビフォーアフター(架空の一般化事例)
小さなWebサイトを一人で管理する担当者の例です。
ビフォー: 「お知らせの文章を変えてください。見た目はそのままで」と頼む。だいたいうまくいくが、ときどき似た名前の別ページが変わる。スマホ表示で文がはみ出すことがある。毎回、変更箇所を探してブラウザで確かめる不安と手間が残る。
アフター: 任せる仕事を「既存ページの文言変更」に限定し、入力を「対象ページ・変更前の文・変更後の文」の3つに固定。完了条件も先に決める(指定ページだけ変更/文字が一字一句一致/構造を変えない/変更箇所と確認結果を報告)。
AIの能力が急に上がるわけではありません。しかし仕事の形が安定し、人が見るべきものが「変更内容」と「確認の証拠」の2つに絞られます。自動化の効果は、派手な成果より先に「判断しなくてよい小さな手数が減る」形で現れます。
毎回の説明はCLAUDE.mdとauto memoryへ移す
Anthropicの現行資料では、各Claude Codeセッションは新しいコンテキストウィンドウ(=その会話で参照できる情報の枠)で始まり、セッションをまたぐ知識には2つの仕組みがあります。人が書くCLAUDE.mdと、Claude自身が作業から残すauto memoryです。どちらも毎回読み込まれる文脈であり、操作を技術的に強制する設定ではありません。(How Claude remembers your project)
| 置き場所 | 書く人 | 向く内容 | 向かない内容 |
|---|---|---|---|
| 会話 | 人とClaude | 今回だけの目的、対象、変更内容 | 次回も守る規則 |
| CLAUDE.md | 人 | テストコマンド、命名、構成、共通手順 | 長い解説、頻繁に変わる資料 |
| auto memory | Claude | デバッグの知見、発見した癖、作業上の学び | 破ってはいけない安全境界 |
| hooks | 人が設定 | 編集後の検査、保護ファイルの拒否 | 状況ごとの柔軟な判断 |
プロジェクト共通の指示は、作業フォルダの./CLAUDE.mdまたは./.claude/CLAUDE.mdへ置けます。最初は次の3種類に絞ると管理しやすくなります。
- Claudeがコードだけでは推測できないコマンド——例:
npm run checkを変更後に実行する - このプロジェクト固有の決まり——例: 記事リンクは末尾を
/にする - 繰り返した失敗の防止——例: 指定外ファイルを変更しない
公式資料はCLAUDE.mdを具体的かつ簡潔にし、1ファイル200行未満を目安にするよう案内しています。長いほど強くなるわけではなく、文脈を消費し、指示が守られにくくなる可能性があります。auto memoryも最初に読み込まれるMEMORY.mdは先頭200行までです。数値は2026年7月26日に確認した現行仕様であり、利用時点の公式ページも確認してください。(How Claude remembers your project)
設定後は、Claude Codeで/memoryを開き、目的のCLAUDE.mdが一覧に出るかを確認します。一覧に出なければClaudeから見えていません。表示されているのに守られない場合は、曖昧な表現、別ファイルとの矛盾、長すぎる説明を順に疑います。公式のトラブルシューティングも同じ分岐を示しています。
ここでの境界は重要です。CLAUDE.mdへ「削除しない」と書くことは行動の案内ですが、削除を技術的に不可能にはしません。破ったときの影響が大きい条件は、次の節で扱うhooks、permission(=道具ごとの許可)、sandbox(=到達できる範囲の隔離)へ分けます。
作る役と確かめる役は、必要な時だけ分ける
この記事の「動くチーム」は、複数のAIを起動することだけを指しません。対象、実行、検品、記録、停止点がつながった運用全体の比喩です。一つのClaude Codeセッションでも、この5つがあれば最小の運用は作れます。
役割を分ける価値があるのは、調査結果が大量で主会話を圧迫する、作った本人とは別の観点で反例を探したい、担当ごとに道具や権限を限定したい場合です。Claude Codeのsubagents(=主会話から特定の仕事を任される専門役)は、それぞれ独立した文脈、専用指示、利用できる道具、権限を持ち、結果を主会話へ返します。(Create custom subagents)
| 形 | 向く仕事 | 費用と弱点 | 最初の選択 |
|---|---|---|---|
| 主会話だけ | 小修正、前後の工程が同じ文脈を共有する仕事 | 作成と自己検品が近くなる | 初心者はここから |
| サブエージェント | 大量調査、独立レビュー、道具を絞る専門作業 | 起動時に背景を渡す必要がある | 結果だけ戻ればよい時 |
| Agent Teams | 担当同士が相談する独立並列、競合する仮説の検証 | 調整とトークン消費が増える | 分割利益が明確な上級用途 |
別の役に検品させても、正しさが保証されるわけではありません。検品役にも同じ思い込みや情報不足があり得ます。役を分けたうえで、テスト、差分、公式出典、期待結果など、AIの外側にある基準を併用します。
実在するAgent Teamsは、複数のClaude Codeセッションが共有タスクとメッセージで連携する機能です。2026年7月26日時点の公式資料では実験的で、初期状態では無効、Claude Code v2.1.32以降が必要です。単一セッションより調整負担とトークン使用量が増え、同じファイルを触る仕事、一本道の仕事、依存の多い仕事には主会話やsubagentsの方が向くとされています。(Orchestrate teams of Claude Code sessions)
「チームらしく見えるから」という理由だけで増やすと、引き継ぎと統合が新しい仕事になります。まず一人分の工程を安定させ、独立して同時に進められる担当が2つ以上見つかったときに分ける方が、失敗の原因を追いやすくなります。
毎回守る検査はhooks、止まり方は権限で固定する
指示、記憶、hooks、権限は似て見えますが、働く層が違います。
| 層 | 役割 | 例 | 失敗時の見方 |
|---|---|---|---|
| 今回の依頼 | 目的と範囲を伝える | この1ファイルだけ変更 | 曖昧なら確認や対象違いが起きる |
| CLAUDE.md | 毎回の文脈を渡す | 変更後にnpm test | 文脈であり強制ではない |
| hook | 決まった時点で処理を起動 | 編集後に検査、保護先を拒否 | スクリプトの不具合や設定漏れがあり得る |
| permission | 道具を許可、確認、拒否へ分ける | 読取は許可、外部送信は確認 | 広すぎる許可は影響範囲を広げる |
| sandbox | ファイルと通信の到達範囲を狭める | 作業フォルダだけ書き込み | 許可済み範囲内の誤操作は別対策が要る |
| 外部チェック | AIの外で反映を止める | テスト失敗ならマージ不可 | 検査自体が不足すると見逃す |
Claude Codeのhooksは、編集前後、処理終了時など決まった時点で利用者のコマンドを実行する仕組みです。公式は、LLMが実行を選ぶかどうかに頼らず、反復作業やプロジェクト規則を動かす用途を説明しています。(Automate workflows with hooks)
ただし、最初から何でもhookにすると設定の保守が増えます。導入順は次の程度で十分です。
- まず依頼文に検査を書き、同じ仕事を数回試す
- 検査コマンドと成功条件が安定したらCLAUDE.mdへ置く
- 実行忘れが繰り返し起き、失敗を機械で判定できる場合だけhookへ移す
- ファイル削除や外部送信など影響の大きい操作はpermissionやsandboxでも止める
PreToolUse hook(=道具を使う直前のhook)は、終了コード2で操作を止め、標準エラーへ書いた理由をClaudeへ返せます。たとえば保護ファイルへの編集を止め、「このファイルは対象外」と返せば、別の方法を選ぶ材料になります。一方、PostToolUseは操作後なので、すでに起きた変更を取り消す用途には使えません。(Automate workflows with hooks)
permission modeは「何を無確認で進めるか」の基準です。2026年7月26日時点の公式表では、defaultは読み取り、acceptEditsは読み取りと編集、planは探索、autoは安全確認を背景で行う長い仕事、dontAskは事前許可した道具だけを無人処理する用途に整理されています。bypassPermissionsは許可確認と安全確認を大きく外すため、インターネットへ出られずホストへ影響できない隔離コンテナやVMだけが対象です。日常の作業PCで確認を減らす近道にはしません。(Choose a permission mode)
権限は、必要な仕事を終える最小範囲に絞ります。NISTは最小権限を、利用者やその代わりに動くプロセスへ、割り当てた仕事に必要な最小限の権限だけを与える原則と定義しています。(NIST CSRC「least privilege」)
外部のWebページやリポジトリ内の文書には、AIの行動を変えようとする文章が混ざる可能性もあります。OWASPは、外部コンテンツを信頼済みの指示と分け、AIの権限を最小化し、影響の大きい操作には人の承認を置く対策を挙げています。(LLM01:2025 Prompt Injection)
失敗例から直す場所を切り分ける
うまく動かないとき、プロンプトだけを長くすると原因が見えにくくなります。症状ごとに直す層を変えます。
「完了しました」と出たが、本当に直ったか分からない
原因候補は、合格条件と検査方法が依頼にないことです。「テストしてください」だけでなく、実行するコマンド、期待する終了コード、確認する文字列、対象ファイルを指定します。結果にはコマンドと出力を残し、失敗時は成功と呼ばず、原因を直して同じ検査を再実行させます。
CLAUDE.mdの指示が使われない
Claude Codeで/memoryを開き、該当ファイルが表示されるかを確認します。表示されなければ配置場所を確認します。表示される場合は、200行を大きく超えていないか、指示が「きれいに」「適切に」のように検証できない表現になっていないか、別のCLAUDE.mdと矛盾していないかを調べます。(How Claude remembers your project)
「PreToolUse hook error: …」と表示される
この表示は、hookのスクリプトが想定外の終了コードで終わった場合などに出ます。公式ガイドは、サンプルのJSONを標準入力へ渡してスクリプトを単独実行し、終了コードを確認する手順を示しています。まずhook単体を直し、動かないhookを避けるために権限を広げることはしません。(Automate workflows with hooks)
確認が多く、無人処理が止まる
最初に止まった操作を、読み取り、編集、コマンド、外部通信、削除、公開へ分類します。作業フォルダ内の既知のテストなら、その正確なコマンドだけを許可する余地があります。外部通信や削除まで一括で許可しません。無人実行では、事前許可にない操作を質問せず拒否するdontAskも選択肢ですが、拒否された操作を記録して次の依頼へ戻せる設計が必要です。(Choose a permission mode)
WebページやREADMEの指示どおりに範囲を広げようとする
外部の文章は調査資料として読み、現在の依頼を変更する命令として扱いません。必要なコマンドは、出所、目的、変更範囲をこちらの合格条件へ照らしてから採用します。パスワード、秘密、課金、公開、削除を求める文面があっても、それだけで許可しません。外部コンテンツによる間接的なprompt injectionへの基本対策は、権限の最小化と高リスク操作の別承認です。(LLM01:2025 Prompt Injection)
5分で試せる小さな実験
手元に「元に戻せる練習用テキストファイル」を1つ用意して、Claude Codeへこう頼んでみてください。作業フォルダを開き、claude-code-practice.txtを作って、本文へ「準備中」と1回だけ書きます。Claude Codeもそのフォルダから起動します。
対象ファイルを1つ指定します。
そのファイル内にある「準備中」という文字を「受付中」に変更してください。
完了条件:
1. 指定ファイル以外を変更しない
2. 変更前後の文字列を報告する
3. 同じ「準備中」が残っていないか検索する
4. 実行した確認と結果をそのまま示す
対象文字が見つからない場合は、変更せずに止まり、
見つからなかったと報告してください。見るポイントは2つ。1回目は、報告に「変更前後の文字列・残りがないかの検索結果・指定外を変えていない確認」が含まれるか。そして同じ依頼をもう一度実行し、対象がもうないため変更せず止まれるか。
1回目は実行できる力、2回目は「条件が合わない時に勝手に進めない力」の確認です。運用では、正しく動けることと同じくらい、止まれることが重要です。「対象・完成条件・止まる条件・証拠」の4点をそろえると、同じ小さな仕事でも安心して任せられる——それを5分で体験できます。
成功の見た目は次の通りです。
| 実行 | ファイル | 報告 |
|---|---|---|
| 1回目 | 「準備中」が「受付中」へ変わる | 変更前後、旧文字0件、対象外変更なし |
| 2回目 | 何も変わらない | 対象が見つからないため変更せず停止 |
2回目に別の「準備中」を探して勝手に編集した場合は、対象ファイルの固定が弱い可能性があります。見つからないのに成功扱いした場合は、停止条件と報告条件を見直します。1回目の成功だけでなく、2回目の無変更も合格に含めることで、「何かを変えるAI」ではなく「条件に応じて仕事を終える運用」を試せます。
7日間で一つの仕事を運用へ育てる
5分実験が通ったら、同じ仕組みを一つの実務へ移します。対象は、元へ戻しやすく、合否を機械で確かめられ、外部公開や支払いを含まない仕事から選びます。記事の表記修正、定型レポートの整形、既存テストの実行などが候補です。
| 日 | すること | 残す数字 |
|---|---|---|
| 1日目 | 人が普段どの手順で行うかを一度記録する | 手作業の回数、所要時間 |
| 2日目 | 対象、変更、合格、停止、証拠の依頼票で実行する | 人が追加した指示の回数 |
| 3日目 | 同じ依頼を別の対象1件で再実行する | 対象違い、確認漏れの件数 |
| 4日目 | 毎回必要だった短い規則だけCLAUDE.mdへ移す | 繰り返し説明した行数 |
| 5日目 | 作成者と検品者を分ける価値があるか判定する | 検品で見つかった重大な抜け |
| 6日目 | 戻せない操作、外部通信、秘密の停止点を確認する | 自動、確認、禁止の操作数 |
| 7日目 | 導入前後を比べ、残す仕組みだけ選ぶ | 減った手作業、増えた時間や費用 |
比較するのは回答の豪華さではありません。人が途中で判断した回数、説明し直した回数、検査をやり直した回数が減ったかを見ます。サブエージェントやhooksを増やしても、引き継ぎや設定保守の手間がそれ以上に増えたなら、小さい構成へ戻す判断ができます。
Claude Codeへ任せない方がよい場面
すべての仕事を運用化する必要はありません。次の場面では、別の方法を選ぶ方が分かりやすいことがあります。
| 場面 | 任せにくい理由 | 代わりの進め方 |
|---|---|---|
| 一度きりの短い相談 | 型を作る時間の方が長い | 通常の質問として使う |
| 正解を機械で判定できない企画 | テストが見た目だけになりやすい | 人が目的と採否を持ち、AIは案と反対意見を出す |
| 秘密や個人情報が必要 | 読取やログへの混入が影響を広げる | ダミー値と伏せた資料で直し、実値確認は専用環境へ分ける |
| 削除、公開、支払い、本番反映 | 間違いを元へ戻しにくい | 準備と検査まで任せ、最終操作を人へ戻す |
| 同じファイルを複数担当が編集 | 競合と統合が増える | 一担当に固定する |
| 依存の強い一本道の仕事 | 並列化しても待ち時間が減らない | 主会話で順番に進める |
自動化しない判断も運用設計の一部です。特に、合否が人の価値観に依存する企画と、外部へ影響する操作を同じ無人ループへ入れると、速さは上がっても判断責任が見えにくくなります。
この先にあるもの
ここまでが入口です。この先は、次の順番で作っていきます。
- 任せる仕事を1つだけ固定する(選び方の5条件)
- 計画・実行・検品の最小3役を設計する
- 記憶(CLAUDE.md)とルールを分ける
- 依頼→実行→検品→記録を1本の流れにする
- 失敗を「二度と起きないルール」に焼き込む
- 人とAIの責任境界を決める
コピペで使える設計シート・チェックリスト・7日間の実践手順・症状別の修正表まで含めた実装編は、noteの有料記事にまとめています。
note「Claude Codeを『質問相手』から『動くチーム』に変える最初の設計」
無料のこの記事だけでも、5分実験と5項目の依頼票は実行できます。より大きな運用へ広げる必要がある人だけ、次の設計へ進んでください。
検証日: 2026-07-26。実例はすべて架空または一般化したものです。
よくある質問
長いプロンプトを書けば、質問箱から抜け出せますか
長さより、対象、制約、合格条件、停止条件、証拠が具体的かを見ます。短くても「指定ファイルだけ」「旧文字0件」「対象が複数なら停止」と書かれていれば、長い背景説明より合否を判断しやすくなります。複数ファイルにまたがり、方法が未確定な仕事だけ、探索と計画を厚くします。(Best Practices for Claude Code)
CLAUDE.mdには何でも書いてよいですか
毎回必要で、コードから推測できない指示へ絞ります。テストコマンド、独自の命名、共通ワークフローは向いています。長い製品説明、ファイルごとの解説、頻繁に変わる情報は別資料へ置きます。具体的で短い方が守られやすく、現行公式の目安は1ファイル200行未満です。(How Claude remembers your project)
CLAUDE.mdとauto memoryはどう違いますか
CLAUDE.mdは人が書く継続的な指示、auto memoryはClaudeが訂正や作業経験から残す学びです。どちらも次の会話で文脈として使われますが、技術的な強制設定ではありません。破られると困る操作境界はpermission、sandbox、PreToolUse hookなどへ分けます。(How Claude remembers your project)
サブエージェントやAgent Teamsを使わないと「チーム」になりませんか
使わなくても構いません。まず一つの主会話に、対象、実行、検品、記録、停止点を持たせれば運用になります。サブエージェントは大量調査や独立レビュー、Agent Teamsは担当同士の連携が必要な独立並列に向きます。同じファイルを触る仕事や一本道の仕事では、分けない方が調整を減らせます。(Create custom subagents)(Orchestrate teams of Claude Code sessions)
確認を減らすため、最初から広い権限を渡してよいですか
読み取り、戻せる編集、既知のテストは条件を絞って自動化しやすい操作です。外部通信、秘密、削除、公開、支払いは別の停止点にします。bypassPermissionsは隔離環境向けであり、通常の作業PCで確認を消す近道ではありません。permissionとsandboxを組み合わせ、仕事に必要な最小範囲から始めます。(Configure permissions)(Choose a permission mode)
まとめ
Claude Codeが「質問箱」で終わる人と変わる人の差は、特別な呪文を知っているかではありません。質問を一回の回答で終わらせず、対象、変更、合格条件、停止条件、証拠を持つ仕事へ変えているかです。
最初にすることは一つです。元へ戻せる小さなファイルで、1回目に正しく変更し、2回目に変更せず止まれる依頼を試します。通った条件だけを再利用し、毎回必要な説明をCLAUDE.mdへ、機械で判定できる反復検査を必要に応じてhooksへ、影響の大きい操作の停止をpermissionとsandboxへ移します。
役割を増やすのは、その後です。主会話だけで進む仕事、サブエージェントへ分ける仕事、Agent Teamsで並列化する仕事を分け、調整負担とトークン消費も費用として数えます。最終的に目指すのは、何でも無人で変える仕組みではありません。同じ基準で進み、結果を証拠で確かめ、条件が違えば安全に止まり、次回の人手を減らす運用です。
Sources
確認日：2026年7月26日。以下はすべて実際にページを開き、本文で使った主張を確認した一次情報です。運営者の体験にもとづく一般化事例は、製品全体の効果を示す実測ではありません。
Anthropic公式
- Best Practices for Claude Code：エージェント型の作業、検証可能な成功条件、探索から実装までの分け方、短いCLAUDE.mdを確認。
- How Claude remembers your project：新しい文脈、CLAUDE.mdとauto memory、200行の目安、文脈と強制設定の違いを確認。
- Create custom subagents：独立した文脈、専用の道具と権限、主会話と分ける条件を確認。
- Automate workflows with hooks：ライフサイクルごとの実行、終了コード2による停止、エラー時の確認方法を確認。
- Configure permissions：allow、ask、deny、permissionとsandboxの補完関係を確認。
- Choose a permission mode：各モードの用途、
dontAsk、bypassPermissionsの条件を確認。 - Orchestrate teams of Claude Code sessions：実験的で初期状態では無効、必要バージョン、向く仕事、調整とトークン消費を確認。
Git・GitHub公式
- git-diff Documentation：作業中の差分と、パス指定による対象限定を確認。
- GitHub Docs「Status checks」：ビルドやテストの結果表示と、保護ブランチで必須にした場合のマージ条件を確認。
セキュリティ標準・公的機関
- OWASP「LLM01:2025 Prompt Injection」：外部コンテンツの分離、最小権限、高リスク操作の人による承認を確認。
- NIST CSRC「least privilege」：仕事に必要な最小限の権限だけを与える原則を確認。