#claudecode

結論から言うと、どっちでもいい。日本語で書いて全然問題ない。 ネットで「CLAUDE.mdは英語が正義」みたいなの見るけど、あれ半分は雰囲気で言ってるだけだと思う。Claude は普通に日本語の指示を読むし、ちゃんと従う。「英語じゃないと精度ガタ落ち」みたいなことは起きない。 ただ「どっちでもいい」で終わると記事にならないので、ぶっちゃけどこで差が出るのか、正直なところを書く。 CLAUDE.md っていうのはプロジェクト直下に置いとくと Claude Code が自動で読んでくれる指示書ファイル。「このリポジトリではこうしてね」を書いとくやつ。 ここに日本語で「テストは npm test で回して」「コミットメッセージは日本語で」とか書いても、ちゃんと効く。Claude は多言語モデルだから、指示の言語が日本語か英語かで「言うこと聞かなくなる」みたいなことはまず無い。だから読めるか読めないかで悩む必要はゼロ。ここを勘違いして「英語じゃなきゃダメなんだ…」って無理して英語で書くのは、正直いちばんもったいない。 差が出るとしたら、だいたいこの3つ。全部「精度」じゃなくて「

Claude Code を使っていると、同じ種類の確認が何度も出てきて作業が止まることがあります。 たとえば、同じフォルダ内のファイルを何十回も読む、同じ種類の修正を連続で書き込む、毎回「この操作は実行してよいですか」と聞かれる。そういうときは、許可リストをきちんと整えると、必要な確認だけが残り、手が止まりにくくなります。 ここでいう許可リストは、Claude Code に「この種類の操作なら毎回確認しなくてよい」と伝えるための設定です。全部を無制限に許す話ではありません。むしろ逆で、作業に必要なものだけを絞って許可しておくと、うるさすぎる確認ダイアログを減らせます。 まず大事なのは、何を減らしたいのかを分けて考えることです。 ファイルを読むたびの確認なのか、編集や書き込みの確認なのか、外部コマンド実行の確認なのか。ここを混ぜると、許しすぎて危なくなります。Claude Code は人間の代わりに動くので、便利さと安全性の境目を最初に決めておくのがいちばん効きます。 実際には、対話中の確認で「この操作を許可する」「常に許可する」といった選択肢が出たときに、その場の勢いで全部通すのではな

Claude Code で毎回同じお願いを打ち直しているなら、それをスラッシュコマンドにしてしまうと楽です。たとえば「このフォルダの重複ファイル候補を探して」「この文章をやさしい日本語に直して」「変更点を要約して」といった、よく使う頼みごとを短い名前で呼び出せます。長い指示を毎回貼り付ける手間が消え、作業の抜けも減ります。 まず押さえておきたいのは、カスタムコマンドは「Claude Code の中で何度も使う自分用の定型文」を保存しておく仕組みだということです。チャットの履歴を探し直すより、名前で呼べるほうがずっと速い。非エンジニアの人にとっても、これはかなり効きます。案件ごとの書類整理、フォルダの点検、不要ファイルの洗い出し、文章の整形など、毎回ほぼ同じ頼み方をする場面は意外と多いからです。 使い方は難しくありません。Claude Code では、プロジェクト内の `.claude/commands` にコマンド用のファイルを置きます。公式ドキュメントの案内に沿って作るのが確実ですが、基本の考え方は「ファイル名＝コマンド名、本文＝Claude への指示」です。たとえば、文章校正用の定

Claude Code を使うなら、`CLAUDE.md` は「毎回くり返し言うのが面倒な前提」を置く場所です。 うまく書くと、作業のたびに同じ説明を打たなくて済みます。逆に、細かすぎる指示や、その場しのぎのお願いを詰め込みすぎると、あまり効きません。 このファイルに向いているのは、作業の仕方そのものです。たとえば「このリポジトリでは `src/` を編集対象にする」「日本語で返す」「勝手に外部公開用の文面を変えない」「削除前に確認する」といった、毎回の判断基準です。 向いていないのは、一回限りのタスクの手順書です。今日だけ必要な“このフォルダをこの順で処理して”のような内容は、`CLAUDE.md` に恒久的に残すより、その場の指示で渡したほうが自然です。 まずは、効く書き方から見ていきます。 ```md 返答は日本語で、簡潔に書く ファイルの追加・削除・移動は、理由を先に述べる 破壊的な変更は、実行前に確認を取る 既存の表記ゆれは、むやみに直さず周辺に合わせる 変更対象は原則として `docs/` と `src/` に限定する 迷ったら、まず関連ファイルを確認してから提案する ``

Claude Code を同じプロジェクトで何度も使うなら、最初にやっておくと効くのが `CLAUDE.md` です。 これは、そのリポジトリで守ってほしい作法や前提をまとめておくためのメモで、ざっくり言えば「この案件ではこう動いてほしい」というプロジェクトメモリの役目を持たせられます。毎回「このフォルダは何のためのものか」「何を触ってよくて、何を触らないか」を説明し直す手間が減ります。 たとえば、コード修正だけでなく、文書整理、不要ファイルの洗い出し、案件ごとの資料作成のような作業でも、同じ説明を繰り返すのは地味に面倒です。 弁護士の案件フォルダなら「依頼者名の入ったファイル名は変えない」「提出版は `final` ディレクトリにまとめる」。 ディスク整理なら「`Downloads` 直下は消さず、重複候補だけ報告する」「写真の原本は触らない」。 こうした約束を先に置いておくと、Claude Code の返答の質が安定します。 `CLAUDE.md` は、作業するプロジェクトのルートに置くのが基本です。 Claude Code がそのプロジェクトの文脈を読むとき、まずここを見に行く運

古いコードや見慣れない削除を前にしたとき、いちばん欲しいのは「誰が書いたか」より「なぜ残っているか」です。Claude Code には、対象ファイルを読みつつ git の履歴も手がかりにして、変更の背景を文章で整理させる使い方があります。単なる要約ではなく、「この行がいつ入ったか」「直前に何が壊れていたか」「削除してよいかの判断材料は何か」を拾わせるのがコツです。 たとえば、リファクタリング前の分岐が妙に残っている、見えないところで古い設定が生きている、文書フォルダに古いテンプレートが増殖している。そういう場面で、Claude Code に履歴を追わせると、コードの現在形だけでは見えない理由が見えてきます。非エンジニアでも、ファイル整理や文書作成の「これは何のために置いてあるのか」を詰める用途に向いています。 使い方は、先に「いま見えているファイル」と「履歴」を両方見せることです。Claude Code に対して、対象の場所を決めたうえで、こんなふうに頼みます。 ```text このファイルについて、git 履歴を手がかりに「なぜこのコードやこの記述があるのか」を説明してください。 見

Claude Code にコンフリクト解消を手伝ってもらうときは、いきなり「直して」と丸投げするより、ぶつかった場所と、元に戻せる材料を一緒に渡すほうがうまくいきます。 Git のマージ衝突でも、文章ファイルの差分でも、やることは似ています。迷っている箇所を見える形にして、判断材料を少し添える。これだけで、やり直しの手間がかなり減ります。 まず渡すべきなのは、コンフリクトが起きたファイルそのものです。できれば `<<<<<<<` `=======` `>>>>>>>` が残った状態のまま、修正前の内容を含めて見せます。Claude Code は周辺の文脈を読めますが、衝突の境目が消えてしまうと「どこが両者の食い違いか」が分かりません。 実際の依頼は、こんな形が使いやすいです。 ```text このコンフリクトの解消を手伝ってください。 優先したいのは A ブランチ側の意図ですが、B ブランチ側の次の変更も残したいです。 このファイルは最終的に読みやすい文章にしたい 数値や固有名詞は B 側を優先したい 文章のトーンは A 側に寄せたい 衝突マーカーが残っている状態のまま、このフ

プルリクエストの説明文は、あとで見返したときに「何を、なぜ、どう変えたか」が残る大事な記録です。Claude Code を使うと、差分やコミットメッセージ、メモを材料にして、ひとまず読める下書きを短時間で作れます。空白のフォームを前にして止まる時間が減り、説明の抜けもかなり抑えられます。 やり方は難しくありません。Claude Code に「変更内容を要約して、PR 本文の形に整えて」と頼むだけです。ただし、任せきりにすると危ないところもあるので、下書きに入れてほしい材料と、入れてほしくない推測をはっきり伝えるのがコツです。 たとえば、ローカルの作業ディレクトリで次のように頼めます。 ```text このブランチの変更を読んで、プルリクエスト本文の下書きを日本語で作ってください。 次の構成で、Markdown のまま出してください。 変更の要約 背景と目的 主な変更点 動作確認 気になる点・未対応事項 条件: 事実だけを書く 変更内容を勝手に補わない 断定できないことは「要確認」と明記する 読み手はこのリポジトリを知っている社内メンバーを想定する 箇条書きは短く、説明は簡潔に ```

Claude Code で壊れやすいコードを直すとき、いきなり書き換えに入らないのがコツです。先に「今の振る舞い」をテストや確認手順として残してから手を入れると、直したつもりで別の場所を壊す事故がぐっと減ります。コード整理でも、文書の大掃除でも、ディスク削減でも同じです。先に基準を作ってから触る。これだけで作業の怖さがかなり下がります。 リファクタという言葉は少し硬いですが、要するに「見た目や構造を整えるが、動きは変えない」作業です。Claude Code はこのとき、ただ修正案を出すだけでなく、「どこを保護するか」「何を確認してから変えるか」を一緒に考えさせると安定します。 たとえば、Python の関数を分割したい、古い命名を揃えたい、重複ファイルの整理ロジックを見直したい、契約書テンプレートの章立てを整えたい。どれも、先にテストの形を決めておくと安心です。機械的な単体テストでなくても、手順書や比較用のサンプルでもかまいません。 まずは Claude Code に、直す前に「守るべき現状」を拾わせます。依頼文はこんな感じで十分です。 ```text このリポジトリで、今の動きを変え

Claude Code でいちばん役に立つ使い方のひとつが、自分が触った差分をその場でレビューしてもらうことです。 書いた本人は「何をしたか」を知っているので、抜けや危うさに気づきにくいものです。そこで Claude Code に、変更したファイルだけを読ませて「この差分の気になる点を挙げて」と頼む。これだけで、ロジックの穴、説明不足、不要な変更、うっかり混ぜた雑修正がかなり見つかります。 エンジニアならコードレビューの補助に、非エンジニアなら文書や整理作業のセルフチェックに向いています。たとえば、契約書のドラフトで言い回しがぶれていないか、フォルダ整理で同じファイルを二重に残していないか、Markdown の文章で見出し構造が崩れていないか。人間の目だと見落としやすいところを、差分ベースで拾わせる使い方です。 --- まずは、変更したあとにそのままレビューさせます。大げさな設定は要りません。作業対象のディレクトリにいる状態で、普通に「レビューして」と依頼します。 ```text この変更内容をレビューしてください。 特に次を見てください。 仕様や意図から外れていないか 不要な

Claude Code にコミットメッセージを任せると、差分の要点を短く拾って、書きぶりも揃えやすくなります。人が毎回ゼロから考えるより、まず「何を変えたか」を安定した粒度で出させるほうが、履歴が読みやすくなります。特に、作業の切れ目が細かい日や、ひとつの修正に説明が要る日ほど効きます。 ただし、任せ方が雑だとメッセージも雑になります。Claude Code は“それっぽい文”を作るのは得意ですが、コミットの単位まで自動で整えてくれるわけではありません。ここで大事なのは、文章の上手さより先に、差分の見方を揃えることです。 たとえば、1 回のコミットで混ぜるのは「1 つの目的」に寄せます。誤字の修正、文書の言い回しの整理、不要ファイルの削除、設定ファイルの調整。これらをひとまとめにして「いろいろ修正」と書かせると、あとで履歴を追えません。Claude Code には、まず変更点を要約させ、その後でコミットメッセージに落とし込ませるのが扱いやすいです。 実際の使い方はシンプルです。Claude Code に対して、差分を見たうえで「短い要約 → コミットメッセージ」の順で出してもらいます。

Claude Code にフック（hooks）を入れておくと、こちらが保存したタイミングで「整形だけ先にやっておく」流れを作れます。 コードの見た目をそろえたいときはもちろん、文書の改行や余計な空白を整えたいときにも便利です。手で毎回整えるより、作業の最後に自然に片づくのが気持ちいいところです。 ここでのポイントは、Claude Code に「保存のたびに全部やり直せ」と雑に頼むのではなく、ファイルが保存されたときだけ、決まった整形コマンドを走らせるようにすることです。 こうしておくと、本文の編集に集中できて、最後の後始末を機械に任せられます。 まずは、どんな使い方をしたいかをはっきりさせます。たとえば Python なら `ruff format`、JavaScript や TypeScript なら `prettier --write`、Markdown なら `prettier --write` や `mdformat` のように、普段から使っている整形ツールを 1 つ決めます。Claude Code の役目は、そのコマンドを保存後に呼ぶことです。 Claude

Claude Code にまとめて置換を頼むと、たしかに早いです。けれど、ひとたび思った通りでない変更が混ざると、どこから直せばいいか分からなくなります。そこで効くのが、小さく直して、小さく確かめて、問題があればすぐ戻せる形に分けるやり方です。 これは開発だけの話ではありません。大量の文書名を揃える、案件フォルダの中身を整理する、重複した表記を統一する、といった作業でも同じです。 Claude Code は、ファイルを直接書き換える前に「どう分けて進めるか」を人間が決めておくと、とても扱いやすくなります。いきなり全件置換を指示するより、まず対象を絞り、次に一部だけ反映し、最後に確認して広げる。この順番にすると、途中で止めても作業が崩れません。 たとえば、社内文書の表記を「メールアドレス」から「連絡先」に寄せたい、あるいは案件資料のファイル名から日付の表記ゆれをなくしたい。そんなときは、最初から「全ファイルを一斉に置換して」と頼むのではなく、次のように進めます。 ```text 1. まず対象ファイルを一覧にして 2. 変更候補を確認できる差分を出して 3. 1つのフォルダだけ先

Claude Code に長い説明を毎回書くのが面倒なら、先に「こういう仕上がりで」と 1 つだけ見せると、話がかなり速くなります。 このやり方は、英語圏では few-shot と呼ばれることがありますが、要するに「見本を 1 つ渡して、残りを同じ調子でやってもらう」頼み方です。Claude Code では、細かなルールを全部言葉で列挙するより、短い指示と実例を組み合わせたほうが、意図が伝わりやすい場面が多いです。 たとえば、フォルダ整理をしたい人なら、こんな頼み方ができます。 まず、やってほしいことを一言で伝えます。そのあと、理想の出力例を 1 つだけ置きます。 ```text このフォルダの中身を見て、重複しそうなものや不要そうなものを整理したいです。 判断のしかたは、次の例に合わせてください。 例: report_final_v3.docx → 最終版に見えるので残す候補 report_old.docx → 古い版なので確認候補 .DS_Store → macOS の不要ファイルなので削除候補 この例と同じ考え方で、他のファイルも 「残す候補 / 確認候補 / 削除候補」 の 3

Claude Code に「長い仕事をそのまま進めて」と渡すと、途中で迷ったり、どこまでやったか見えにくくなったりします。先に小さな ToDo に分けさせると、作業の見通しが立ち、途中確認もしやすくなります。コード修正だけでなく、フォルダ整理、重複ファイルの洗い出し、長文の下書きにも効きます。 このやり方の肝は、いきなり実行させるのではなく、まず「何を順番にやるか」を書き出させることです。Claude Code は対話しながら進められるので、最初に作戦を出させてから、ひとつずつ潰していく運びに向いています。 たとえば、案件フォルダを整理したいなら、こんなふうに頼みます。 ```text この作業を、実行前に小さな ToDo に分解してください。 目的: 旧案件フォルダの整理と不要ファイルの削減 条件: まず手順だけ提案する 危険な削除は勝手にしない 迷う点があれば確認質問を先に出す 作業は小さく分ける ``` コード修正なら、もう少し具体的にしておくと安定します。 ```text 次の変更作業を、実行前に ToDo に分解してください。 やってほしいこと: 影響範囲の確認 変更対象ファ

Claude Code は、お願いの仕方ひとつで動きがかなり変わります。 「何をしてほしいか」だけでなく、「何をしてほしくないか」を先に置くと、不要な編集、余計な削除、勝手な整形をかなり減らせます。ファイル整理でも、文書作成でも、コード修正でも効きます。 たとえば、重複ファイルの整理を頼むときに「安全第一で、削除はしないで。まず候補を出して」と添えるだけで、作業の進め方が落ち着きます。逆にそこを書かないと、こちらの意図より前に進んでしまうことがあります。 禁止事項は、遠回しに匂わせるより、短く具体的に書くほうが通じます。 よく効く形は、依頼文の最初か最後に「やらないこと」をまとめて置くやり方です。Claude Code に渡す文章に、そのまま入れてしまってかまいません。 ```text この作業では、次のことはしないでください。 ファイルの削除 既存文書の全面書き換え フォルダ構成の変更 こちらの確認なしでの実行 まずは提案だけ出してください。 ``` 言い方のコツは、抽象的な禁止を避けることです。 「適当にやらないで」では伝わりにくいですが、「削除はしない」「移動はしない」「上書き保

Claude Code に既存ファイルを読ませて、「このプロジェクトの書き方に寄せて」と頼むだけで、あとから直す手間をかなり減らせます。 新しく機能を足すときも、文書を整えるときも、ファイル整理をするときも、まずは“その場の流儀”を真似させるのが近道です。 たとえば、何人かで触っているコードベースには、見た目には小さいけれど守られている癖があります。変数名の付け方、コメントの温度感、改行の入り方、エラーメッセージの言い回し。Claude Code はそこを雑に平均化してしまうことがあるので、最初に「このファイル群の作法を読んで、同じ調子で書いて」と明示しておくと安定します。 使い方は難しくありません。手本を渡して、守ってほしい範囲を絞るだけです。 ```text 次の既存ファイルを読み、命名、コメントの量、関数の長さ、改行の癖を このコードベースの作法として把握してください。 そのうえで、新しく追加するコードは、既存の書き方に合わせてください。 見た目だけ真似るのではなく、同じ意図の処理があれば同じ構造を優先してください。 ``` もう少し実務寄りにするなら、何を真似るのかを具体化しま

Claude Code に雑に「直して」とだけ頼むより、「まず調べて、次に直して」と分けて指示したほうが、手戻りが減ります。 とくに、既存コードの修正、フォルダ整理、重複ファイルの洗い出し、文書の整形のように、先に状況把握が必要な作業で効きます。 理由は単純で、いきなり修正に入ると、Claude Code が「何を根拠に直すか」を自分で補ってしまうからです。 先に調べさせると、対象のファイル、命名、依存関係、似た設定、既存の方針を確認したうえで、その情報に沿って直せます。人間がレビューするときも、この順番のほうが判断しやすいはずです。 たとえば、README を整えたいときに、最初から「読みやすくして」とだけ頼むと、書き換えの方向がぶれやすいです。 先に「このリポジトリの README、見出し構成と重複表現を確認して」と頼み、その結果を見てから「では、その指摘に沿って最小限で直して」と続けると、修正の筋が通ります。 同じことは、開発者以外の用途でも起きます。 たとえば、外付けディスクの中身を減らしたいとき、いきなり「不要なものを消して」では危ない。まず「このフォルダ群の中で、重複してい

Claude Code に作業を頼むとき、いちばん効くのは「何を作るか」だけでなく「何をしないか」まで先に渡すことです。 ゴール、制約、成功条件、触ってよい範囲を最初に揃えると、やり直しが減ります。ファイル整理でも、文書作成でも、コード修正でも効きます。 たとえば、ただ「このフォルダを整理して」と頼むと、見た目は整っても、必要なものまで移動されたり、命名が勝手に変わったりします。 逆に、目的と境界を先に書くと、Claude Code は判断しやすくなります。人に仕事を頼むときと同じで、曖昧さを減らすほど返答の精度が上がります。 依頼文の骨格はシンプルです。次の4点を最初に置きます。 1. 目的 2. 制約 3. 成功条件 4. 変更してよい範囲 この順で書くと、相手は「何を達成すればよいか」と「どこまで手を出してよいか」を先に理解できます。 Claude Code はターミナル上でファイルを読んだり編集したりできるので、境界が曖昧だと、意図しない変更が入りやすくなります。 たとえば、文書整理ならこんな依頼です。 ```text 目的: 取引先向け提案書のたたき台を、読みやすく短くしたい

Claude Code に仕事を投げるとき、いちばん効くのは難しい命令ではありません。 「何を直すのか」と「どこまで触ってよいのか」を、先に狭く決めることです。 このひと手間で、生成された差分を読みやすくできるし、意図しないファイルまで触られる事故も減ります。 エンジニアならリファクタリングや機能追加の前さばきに使えます。非エンジニアでも、文書整理、重複ファイルの洗い出し、フォルダ内の資料の整形にそのまま効きます。 曖昧な依頼が弱いのは、Claude Code がサボるからではなく、境界がないからです。 「このフォルダだけ」「このファイル群だけ」「本文だけ直して、見出し構成は変えない」のように、先に線を引くと結果が安定します。 たとえば、README の整備ならこう書けます。 ```text 次の作業をしてください。 対象: docs/README.md やってほしいこと: 導入文を短くする 見出しの順番は変えない 手順の重複を減らす 文章は日本語のまま、意味は変えない やらないこと: コード例は変更しない 他のファイルは触らない 新しい機能説明を勝手に足さない 完了条件: READM

Claude Code に頼むとき、同じ一文に「何がどうなっているか説明して」と「ついでに直して」まで詰め込むと、返ってくる作業の焦点がぼやけます。 この TIPS は、依頼を「説明」「修正」「整理」に分けて投げるだけで、やり取りの手戻りを減らすためのものです。特に、ファイル整理や文書作成のように、コード以外の作業でも効きます。 Claude Code は、たしかに一度にいろいろ頼めます。ですが、全部を同じ粒度で混ぜると、どこまでが現状把握で、どこからが変更作業なのかが曖昧になります。曖昧なまま進むと、意図しない修正をしたり、説明は合っているのに直し方がずれたりします。 人が隣で仕事を受けるときと同じで、「まず現状を見て」「次に直して」と順番を切るほうが、結果が安定します。 まずは、頼み方を分けるところから始めます。たとえば、文章の推敲ならこうです。 ```text この文書の構成を説明して。まだ直さないで。気になる点だけ箇条書きで挙げて。 ``` 次に、説明を受けたあとで修正を頼みます。 ```text さっき挙げた気になる点のうち、語尾の重複だけ直して。内容は変えないで。 ```

Claude Code に作業を任せていると、途中までよさそうに見えても、方針がずれたり、編集範囲が広がりすぎたり、手を入れてほしくないファイルまで触られたりします。そんなときは、無理にその場で修正させるより、いったん作業を捨ててやり直したほうが早いことがあります。 この手の戻し方を知っておくと、試行錯誤の回数が増えても怖くありません。文書作成でも、ディスク整理でも、コード修正でも、「もう一回、最初から」をためらわずに使えるようになります。 まず押さえたいのは、Claude Code の作業は、基本的に自分の手元のファイルを直接変えていく、という点です。だから「戻す」ときは、Claude Code にお願いして巻き戻すより、Git の履歴やファイルの退避を使って人間側で整理したほうが確実です。Git を使っているなら話はかなり簡単ですし、Git を使っていない場合でも、元ファイルを残してから作業する習慣をつければ十分に立て直せます。 一番堅いのは、作業前に小さく区切っておくやり方です。たとえば、ひとつの案件フォルダ、ひとつの書面、ひとつの整理対象だけを Claude Code に渡しま

Claude Code で大きい作業をするときは、いきなり全部を変えないほうがうまくいきます。まず範囲を切り、次に一段ずつ進める。これだけで、途中で壊れても戻しやすくなり、レビューもしやすくなります。非エンジニアの人なら、フォルダ整理や文書の大量編集でも同じです。1回の指示を小さく区切るだけで、結果の確認がぐっと楽になります。 たとえば、壊れやすいのはこういう依頼です。 > 「この案件フォルダ全体を整理して、重複ファイルを消して、名前も統一して、要約書も作って」 やりたいことは分かりますが、変更の種類が多すぎます。Claude Code に任せるときは、まず“何を変えるか”ではなく“どこまで変えるか”を先に決めます。区切り方のコツは、ひとつの作業を「探索」「提案」「実行」「確認」に分けることです。 最初は、作業前の見取り図を作らせます。まだ編集しない段階です。 ```text このディレクトリの内容を見て、変更が必要そうな箇所を3つの観点で整理して。 1. 手を付けるべき場所 2. 触らないほうがよさそうな場所 3. 小さく始めるなら最初の一手 まだファイルは変更しないで。 ``` こ

Claude Code を使うとき、いきなり変更を走らせる前に「まず方針だけ見せて」と挟む使い方があります。これがプランモードです。 ファイル整理でも、文書作成でも、コード修正でも、先に段取りを確認できるので、「思っていたのと違う」をかなり減らせます。特に、削除や移動のように戻しにくい作業では効きます。 たとえば、散らかった作業フォルダを整理したいとします。いきなり消さずに、Claude Code に「どう整理するつもりか」を出させれば、危ない手を打っていないか先に見られます。案件フォルダを月別に分けたい弁護士の人や、重複資料を減らしたい総務担当、古い下書きを整えたい編集者にも向いています。 要するに、実行より先に設計図を確認するための使い方です。 まずは、やりたいことをそのまま頼みます。ポイントは「実行」ではなく「計画を出して」と明示することです。 ```text このフォルダ内の不要ファイルを整理したいです。 いきなり変更せず、まず手順と影響をプランとして示してください。 削除候補、移動候補、注意点を分けて説明してください。 ``` もう少し具体的にするなら、目的をはっきり書いたほ

Claude Code を使い始めると、いちばん先に気になるのが「この操作、どこまで勝手にやってもらって大丈夫か」です。 ファイルの読み取りだけなら安心でも、編集や削除、外部コマンドの実行まで広げると、便利さと事故のリスクが急に近づきます。 権限モードを理解しておくと、Claude Code に任せる範囲を仕事に合わせて切り分けられます。文書作成ならほぼ自動で回し、ディスク整理なら確認を挟み、コード修正では危ない操作だけ止める。そういう使い方ができるようになります。 Claude Code には、ユーザーの許可なしには実行しない操作をどう扱うかを決める仕組みがあります。基本は「毎回確認する」「ある程度は自動で通す」「危険な操作は止める」という考え方です。ここを雑に広げると、便利な代わりに、思っていない場所を書き換えたり、削除してはいけないファイルを触ったりする可能性が上がります。 まずは、権限モードを“安全装置の強さ”として捉えると分かりやすいです。読み取りだけならかなり広く許せます。書き込み、削除、ネットワーク経由の操作、システムに影響するコマンドは、確認を挟む側に置くのが基本です。

Claude Code に長いファイルをそのまま貼る代わりに、「どのファイルを見ればよいか」「どこを読めば十分か」を探させる。 この頼み方を覚えると、巨大な設定ファイル、長いログ、散らかった文書を前にしても、手でコピペする量をかなり減らせます。ディスク整理や案件ごとの資料確認でも効きます。 まず大事なのは、Claude Code に「全部読んで要約して」ではなく、「探して、必要な箇所だけ見て」と頼むことです。 Claude Code は作業ディレクトリ内のファイルを見ながら進められるので、こちらがファイル全文を貼る必要はありません。場所の見当がつかないときは、ファイル名の候補、拡張子、覚えている単語、エラー文の一部だけを渡します。 たとえば、リポジトリのどこに設定があるか知りたいなら、こんな依頼で十分です。 ```text このプロジェクト内で、API の接続先を設定している場所を探して。 候補のファイル名と、該当しそうな行だけ教えて。 全文は貼らなくていい。 ``` もう少し具体的なら、調べ方まで指示します。 ```text このフォルダの中から「timeout」「base_url」

Claude Code を長く使っていると、だんだん「今この会話、前の話を引きずりすぎているな」と感じる瞬間があります。そんなときに効くのが `/clear` です。会話の履歴をいったん空にして、コンテキスト管理をやり直す。たったそれだけですが、これで指示の食い違いが減り、不要な前提を持ち越さず、返答も軽くなります。 特に、ひとつの案件を順番に進める人ほど効きます。コード修正、ファイル整理、文章のたたき台作成、ディスク使用量の洗い出し。どれも「さっきの続き」を覚えていてほしい場面と、逆に「前の話は忘れてまっさらで考えてほしい」場面が混ざります。そこで区切りを入れる感覚が大事になります。 まず覚えておきたいのは、`/clear` は“失敗したときの最後の手段”ではないことです。むしろ、話題が切り替わったタイミングで先に使うのが上手いやり方です。 たとえば、こんなときは区切りどきです。 ひとつ目は、依頼の目的が変わったときです。 「この Python スクリプトを直して」から「同じフォルダの不要ファイルを整理したい」に変わるなら、会話の流れは別物です。前半のソフトウェア修正の前提を後半に引

Claude Code は、ただ「作業を始める道具」ではなく、そのプロジェクトで何をしてよくて、どこまで触ってよいかを最初に整える道具でもあります。 この最初のひと手間を入れるだけで、あとからの指示が通りやすくなり、余計なやり直しも減ります。開発案件でも、文書整理でも、フォルダの掃除でも効きます。 最初にやるべきことは、むずかしくありません。 「作業範囲を決める」「ルールを置く」「確認のしかたを決める」。この3つです。 Claude Code を開いたら、最初にやるべきなのは作業場所の確認です。 これはエンジニア向けの話に見えますが、非エンジニアにも重要です。たとえば、案件ごとにフォルダを分けて書面を作る、写真整理で年ごとのフォルダだけを対象にする、不要キャッシュを消す対象をひとつの作業用フォルダに閉じる。こういうとき、最初の境界が曖昧だと事故が起きやすいです。 Claude Code では、基本的にいま開いているプロジェクトの中で作業する前提を作ります。 だから、まずはターミナルで目的のフォルダに入ってから起動するのが大事です。 ```bash cd /path/to

Claude Code は、ざっくり言うと「端末の中にいる作業係」です。コードを書く人だけの道具に見えますが、実際には、フォルダの整理、不要ファイルの洗い出し、文章の下書き、既存ファイルの読み解きまでかなり広く使えます。 ただし、何でも任せてよいわけではありません。向いている仕事と、任せると危ない仕事の境目を先に知っておくと、かなり使いやすくなります。 まず押さえたいのは、Claude Code が得意なのは「ファイルを読んで、差分を考えて、手を動かすこと」だという点です。逆に、事実確認が必要な判断、最終責任を伴う編集、曖昧な指示しかないままの大規模変更は苦手です。 この線引きさえ分かれば、開発者でなくても普通に役立ちます。たとえば、案件ごとに散らかった資料をまとめる、同じ内容の文書を整える、古いバックアップや重複ファイルを見つける、といった用途です。 Claude Code に向いているのは、内容を壊さずに扱える作業です。人間が目視でやると時間がかかるけれど、ルールが決まっているもの。こういう仕事は相性がいいです。 たとえば、フォルダの中身を見て「どのファイルが古いか」「同じような名

Claude Code を手元で動かせるようになると、コードの修正だけでなく、ファイル整理、不要データの洗い出し、文章の下書きまで、同じ流れで頼めます。Claude Code 入門として最初に押さえるべきなのは、むずかしい設定ではなく「端末を開いて、サインインして、作業フォルダで一度だけ指示してみる」ことです。Claude Code 使い方の入口は、思っているよりずっと狭くて短いです。 まずは前提を軽くそろえます。Claude Code は Anthropic の CLI コーディングエージェントで、ターミナルから使います。難しく聞こえますが、要するに「チャット画面ではなく、黒い画面や端末アプリに話しかける」道具です。エンジニアならソースコードのあるフォルダ、非エンジニアなら案件ごとの文書フォルダや、写真・ダウンロード・共有資料をまとめた作業用フォルダで使うのが自然です。 最初の準備は、公式の案内どおりに Claude Code をインストールすることです。ここは配布形態が変わることがあるため、手順そのものは公式ドキュメントを優先してください。流れとしては、対応する環境にインストールし

Claude Code は、ファイルを見たり、直したり、整理したりする作業を、ターミナルの中でそのまま手伝ってくれる道具です。 ただ、最初の壁はだいたい「何を打てばいいのか分からない」です。そこで、覚える操作を本当に少なくして使うやり方に絞ります。本文を読んだあとは、起動する・指示する・終わる の3つだけで回せるはずです。 ターミナルに慣れていない人ほど、最初は「小さなフォルダで試す」のが大事です。たとえば、請求書のひな形が散らかったフォルダ、毎回似たような文書を置く案件フォルダ、ダウンロード後の不要ファイルが溜まった場所。そういう、壊れても困らない場所で始めると気が楽です。 まずは Claude Code を、作業したいフォルダで開きます。やることは単純で、対象フォルダに移動してから起動するだけです。 ```bash cd /path/to/作業したいフォルダ claude ``` `cd` は「このフォルダの中で作業する」という意味です。`/path/to/作業したいフォルダ` の部分は、自分のフォルダの場所に置き換えます。 起動したら、もう複雑なコマンドは覚えなくてかまい

Claude Code を使うとき、つい「いいプロンプトを書けば何とかなる」と考えがちです。私もその感覚はよくわかります。1回きりの質問なら、それで十分なことも多い。でも、同じような作業を何度も回す、途中の結果を確認する、前回の状態を覚えておく、となると話は変わります。そこで必要になるのが、単発の指示ではなく「loop」という考え方です。 元記事は、Youssef Hosni氏が Medium の Level Up Coding に書いたもので、Claude Code を使った agentic automation、つまり「AI にある程度の自律性を持たせて作業を進める仕組み」をどう設計するかを扱っています。面白いのは、AI をいきなり全自動にするのではなく、まずは安全で नियंत्र可な形で回し、少しずつ賢くしていく発想にあると思います。 この記事の主題は、Claude Code を「1回答えるAI」ではなく「繰り返し動く仕組み」として使うこと loop は、実行のきっかけ、読むべき文脈、できること、検証方法、状態の保存場所、停止条件まで含めて設計する 最初は `TASK.md`、

From a Claude / Claude Code developer’s perspective, this story is interesting less because of any one product update and more because it highlights a real tension in the current AI-dev conversation: the language around coding assistants is getting noisy. Even the people building these tools can get tired of the slogans that spring up around them, especially when those slogans start to flatten the actual work. The source is a Reddit post titled “Please wait for verification.” The referenced disc

ClaudeがClaude Codeに dynamic workflows という新機能を追加しました。ざっくり言うと、1つのAIが順番に考えるのではなく、たくさんの“子エージェント”を同時に動かして、最後に結果をまとめる仕組みです。 これ、かなり面白いです。AIエージェントの話は最近よく聞きますが、ここまで「並列処理」と「検証」を前面に出しているのは印象的だと思います。単に“速い”というより、大きくて面倒な仕事を、壊れにくい形で進める方向に踏み込んでいるのがポイントです。 Claude Codeに dynamic workflows が追加された 1つのAIではなく、10〜100規模の並列 subagents を使って作業する 結果をチェックしてからユーザーに返すため、精度重視の作業に向く バグ調査、セキュリティ監査、大規模移行、長いレビュー作業などで強い research preview として提供され、Max / Team / Enterprise などで利用可能 **通常のClaude Codeより多くのtokensを消費

Claude’s new dynamic workflows feel like Anthropic trying to push Claude Code from “helpful coding assistant” into “orchestrator for serious engineering work.” For developers, the interesting part isn’t the marketing language about speed — it’s the claim that Claude can now plan, fan out, verify, and keep state across large jobs instead of choking on them in a single pass. Anthropic has introduced dynamic workflows in Claude Code as a research preview. The feature is meant for **hard

For Claude Code users and builders, this is the kind of article that makes you realize the product is a lot more programmable than the official docs suggest. André Figueira’s read-through of the source code surfaces a pile of hidden hooks, frontmatter fields, and agent settings that can change how Claude behaves at runtime, sometimes in surprisingly powerful ways. Claude Code’s hook system can do more than the docs admit: hooks can return JSON that rewrites inputs, alters permission decisions, i

Claude Code routines are an interesting step toward making Claude feel less like an interactive assistant and more like an always-on workflow engine. For developers, the big shift is that Claude can now react to schedules, API calls, and GitHub events from Anthropic-managed cloud infrastructure, so the laptop no longer has to be open for the work to happen. Routines are a research preview feature, so behavior, limits, and the API surface may change. A routine is a saved Claude Code configuration