ハルだよ〜。Claude Code（アンソロピックが作ってるAIコーディングツール。ターミナルの中でAIが自分で考えてファイルを編集したりコマンドを実行したりしてくれるやつ）関連の記事、これで何本目だろってくらい追いかけてるんだけど、今回はちょっと違う角度から攻めてみたよ。世界中の使い手のTipsを漁ってたら、みんな口をそろえて言ってることがあったの。それが「細かく指示するな」ってこと。え、AIツールなのに指示を減らせって逆じゃない？って最初思ったんだけど、ちゃんと理由があったから深掘りしてみた📝
開発者本人が「マイクロマネジメントはやめて」と言ってる件
これが一番びっくりしたんだけど、Claude Codeの開発者であるボリス・チェルニー氏が、Yコンビネーターのイベントでこんなことを言ってるんだよね。Business Insider Japanによると、ユーザーによくある間違いは「これをやって、次にこうやって、次に3、4と…」みたいに手順を全部書いてしまうことなんだって。
チェルニー氏いわく「現代のモデルに対しては、それは正しいやり方ではありません」とのこと。代わりに、達成すべき成果（ゴール）だけをはっきり伝えて、ガードレール（やっちゃダメなことの線引き）と完了の定義を決めたら、あとは任せてしばらく待つのがコツらしい。「きっと驚かせてくれると思います」とまで言ってるのが印象的だった。私も最初は「1、2、3で細かく指示するのが丁寧」って思い込んでたから、これは目からウロコだったよ👀 考えてみれば人間のマネジメントでも、新人には手順書を渡すけど、ベテランには目的だけ伝えて任せるよね。AIも“経験値”が上がった今、同じ扱い方にシフトすべきタイミングなのかもしれないなって思った。
“任せる前の型作り”が本当のコツだった
じゃあ何も準備せず放り投げればいいのかっていうと、そうじゃなくて。細かい手順書は要らないけど、その代わりに「型」を作っておくのが上手い人たちの共通点みたいなんだよね。よく出てくるのが CLAUDE.md というファイル。プロジェクトの前提知識やルールをここに書いておくと、Claude Codeが毎回それを読んでから動いてくれる仕組み。AWSのブログで紹介されてたイベントでも、CLAUDE.mdの活用やPlanモード（実装前にまず計画だけ立てさせるモード）、`/context`や`/fork`みたいな便利コマンドが実践Tipsとして紹介されてた。
あとgihyo.jpの連載で解説されてたAuto-Acceptモードも面白い。Shift+Tabキーを押すと「毎回確認するManualモード」→「安全なら自動承認するauto mode」→「Planモード」と切り替えられて、危険そうな操作は自動でブロックしてくれるんだって。任せると言っても丸投げじゃなくて、こういう安全弁がちゃんと用意されてるのがポイントだと思う。個人的にはこの“三段階切り替え”が地味に神設計だなと感じてて、初心者はManualで慣れて、慣れたらauto modeに移行、みたいに自分のレベルに合わせて使い分けられるのがいいよね。
実際にYouTubeでベストプラクティスを実践してる動画もあって、CLAUDE.mdの仕様づくりからMCP（AIとツールやデータを繋ぐ標準のやり方）を使ったFigma連携、カスタムコマンドでの「調査→計画→実装→PR作成→レビュー」までの一連の流れを丁寧に見せてくれてる。実際にどう手を動かしてるのか気になる人はこれ見てみて。
新機能「アドバイザー機能」は“相談役”を雇う発想
最近話題になってるのが「アドバイザー機能」。普段の作業は普通のモデルに任せて、方針を決める直前や、同じエラーが繰り返し出た時、タスク完了を宣言する前の最終チェックだけ、より賢いモデルに相談させる仕組みなんだって。中村優太さんの解説動画を見つけたので貼っておくね。
動画の中で面白かったのが「分担にも見えないコストがある」って指摘。指示書を書く側と読む側で二重にコストがかかるし、記憶の使い回し（プロンプトキャッシュ）が効かない構成だとさらに膨らむって。だから小さい仕事は自分（安いモデル）でやった方が早くて安いこともあるし、大きくて判断が何度も必要な探索的な仕事ほど相談役に任せる価値が出てくるらしい。これ、会社の外注と全く同じ理屈だなって思って笑った😊 ちなみにこの機能、アンソロピックに直接つないでる契約でしか使えなくて、AWSなど他社クラウド経由だとまだ使えないという制限もあるみたい。万能の魔法じゃなくて、使いどころを見極める道具ってことだね。こういう「賢いモデルは要所だけ」という設計思想は、コストと精度のバランスを取る上でこれからの標準パターンになっていきそうな予感がしてる。
非エンジニアも巻き込んで広がる活用の場
Claude Codeの面白いところは、もうエンジニア専用ツールじゃなくなってきてること。AWSとクラスメソッドの共同イベントでは、ビジネス職や企画職の人たちも参加して、約3時間でプロダクトを作りきったらしい。参加者の声で「プロダクト開発自体は驚くほど簡単になった。知識が不足していても着手可能な点が大きい」ってコメントがあったのが印象的。
あと『Claude Code実践入門』の発売記念講座でも、対象者別の活用アプローチとして、非エンジニアがデスクトップアプリで気軽に試すバイブコーディング（AIに雰囲気で指示してコードを作らせる開発法）から、若手エンジニアの育成・評価モデルの話まで幅広く扱われてる。「作業スピード」より「設計力・コード精査力」で評価する軸にシフトすべき、って論点は今の現場が抱えてる悩みそのものだなと思った。これまでは「早く書けるかどうか」が評価軸だったけど、AIが書くのが当たり前になると「その設計や仕様が正しいかどうかを見抜けるか」がエンジニアの本当の価値になってくる、って構造の変化だよね。
もちろん未経験者でもある程度は作れる、という日経クロステックの検証記事もあって、「ログイン機能を追加して」と日本語で指示するだけでAIが計画を立てて実装まで一貫してやってくれる、って書いてあった。マイクロマネジメントしないという開発者の哲学と、こういう現場での広がり方は地続きなんだよね。細かい手順を全部書かなくても、型（CLAUDE.mdやPlanモード）さえ整えておけば、経験の浅い人でもちゃんと戦力になれる。
結局、何が変わったのか整理してみた
ここまで追いかけてきて思うのは、Claude Codeの進化って「AIが賢くなった」だけの話じゃなくて「人間側の使い方の常識」が変わってきてるってことなんだよね。細かく指示を書くほど丁寧、というこれまでの感覚から、ゴールとガードレールだけ決めて任せる方が結果的に速くて質も良い、という感覚へ。しかもその“任せ方”自体にCLAUDE.mdやPlanモード、アドバイザー機能みたいな型やツールがちゃんと用意されてるから、属人的な勘に頼らなくても再現できるのがいいところ。
これがエンジニアだけじゃなく企画職やビジネス職にも広がってきてるってことは、これから「AIへの任せ方」がプログラミングスキルと同じくらい大事なスキルになっていく、ってことなんだと思う。私自身、次に何か触るときは手順書を書くんじゃなくて、まずゴールとルールだけ書いてみようかなって本気で思ったよ。これはClaude Codeが「魔法の道具」じゃなくて「任せ方を学べば化ける道具」だと私が思う理由かな🛠️
