Claude Code を毎日使っているのに業務の進み方が変わらない理由
「/initをやった記憶はある。でも最後に更新したのがいつか分からない。」
そういう状態になっていませんか。Claude Codeをインストールして、最初の数日は設定もして、毎日チャットでやり取りもしている。でも、3ヶ月前と比べて業務の構造はほとんど変わっていない。
これは使い方の問題というより、立ち位置の問題です。
Claude Codeを「話しかけたら答えてくれるツール」として使い続けると、毎朝同じような指示を打ち込んで、同じような返答をもらって、それをコピーして作業する、という繰り返しになります。効率化はしているかもしれない。でも業務の進み方そのものは変わっていない。
変化が起きるのは、Claude Codeを「設計対象」として扱い始めたときです。誰がどの文脈で何を知っているか、どのタスクを誰に委任するか、人がいなくても何が動くか。これを設計として考え始めると、Claude Codeはまったく別の動きをするようになります。
@sairahul1 が公開した27個の機能（https://x.com/sairahul1/status/2070428662080618607）には、こうした設計の観点から使うべき機能が体系的に並んでいます。Swarmはこれをエージェント設計の視点から読み解き、実際の業務文脈に落とし込む形で整理しました。
27個は多く見えますが、貫いている考え方は3つだけです。次章からその構造を順に解説します。
27個の機能を貫く3つの規律
27個の機能を並べてみると、バラバラに見えます。ショートカットがあれば、ファイル設定もある。音声入力もあれば、テスト実行の話もある。でも読み解くと、3つの問いに答えるための機能群に整理できます。
規律1: コンテキスト設計（機能①〜⑤）
Claudeが「誰のプロジェクトで、何を目的として、今どこまで把握しているか」を知れる状態を作る。これが崩れると、毎回ゼロから説明することになります。
規律2: 委任設計（機能⑥〜⑭）
タスクと権限を構造的にClaudeへ渡す。「バグを直して」ではなく、「何が壊れているか、制約は何か」を整理して渡すことで、一発で解決する確率が変わります。
規律3: 自律化設計（機能⑮〜㉗）
人が逐一指示しなくても、Claudeが動き続けられる仕組みを設計する。
この3段階は、実は使う順番でもあります。コンテキストが整わなければ委任が雑になる。委任が設計されなければ自律化は暴走する。
ここで意識しておきたいのは、「毎朝、自分がClaudeに指示する」という構造そのものをどう変えるかです。毎朝同じタスクをチャットで投げているなら、それはまだ人が主語になっている状態です。設計がClaudeを動かす構造に切り替わると、朝に自分がやることは変わります。
まず最初の規律、コンテキスト設計の5つの機能から見ていきます。
コンテキスト設計の基礎
Claudeに「このプロジェクトの文脈」を持たせることが、コンテキスト設計の目的です。文脈がなければ、毎回の会話は白紙から始まります。
まず実行するのが `/init` です。
プロジェクトを初めて開いたら、最初にこれを動かします。コードベースの構造・依存関係・ビルドコマンドをClaudeが走査し、\CLAUDE.md\を自動生成します。このファイルがプロジェクトの「設計書」になります。
ここで多くの人が止まります。/initをやった記憶はあるけれど、最後に更新したのがいつか分からない。生成したまま放置すると、プロジェクトが変化するたびにCLAUDE.mdの内容と実態がズレていきます。毎週更新することを前提に運用することで、Claudeは常に最新の文脈で動けます。
次に設定しておくと便利なのが `/statusline` です。
画面下部にステータスラインが表示されるようになります。何が走っているか、どのプロセスが動いているか、視覚的に把握できます。VimやNeovimのカスタムステータスラインとも統合できるため、既存のエディタ環境に合わせて設定することができます。
3つ目が音声入力です。
Macは \⌃⌘スペース\、iOSとAndroidはネイティブの音声入力で、複雑な要件を話す形で渡せます。「このコンポーネント、こういう理由でこう動いてほしい、ただし既存のスタイルは変えたくない」という長い指示文を、タイプせずに渡せます。思考の流れのまま渡せるので、整理しながら打ち込む時間が省けます。
コンテキストの状態確認に使うのが `/context` です。
今の会話に何が入っているか、コンテキストウィンドウの使用状況をリアルタイムで見られます。長いセッションになると、初期に渡した設計書の内容が薄まっていきます。それを把握できるのがこのコマンドです。
そのためのリセット操作が `/compact` と `/clear` です。
\/compact\はコンテキスト全体をサマリーに圧縮します。\/clear\は完全リセットです。長いセッションを続けていると、Claudeの回答が曖昧になっていくことがあります。これはコンテキストが詰まっているサインです。定期的に\/compact\を挟むことで、出力の品質を保てます。
Before: 長いセッションの後半、Claudeが「先ほど話した設計方針に従って」と書いてもズレた回答が返ってくる。
After: \/compact\で圧縮してから続けると、方針を正確に保ったまま出力が戻る。
5つの機能でやっていることは一つです。Claudeが「分かっている状態」を設計として維持する。それが次の委任設計の土台になります。
問題を渡す技術
コンテキストが整ったら、次は問題をどう渡すかです。「バグを直して」で渡すか、構造化して渡すかで、返ってくる精度がまったく変わります。
まず使いたいのが plan mode（`Shift+Tab`）です。
大きな変更の前に、実行ではなく「計画だけ出力してください」というモードです。Claudeが何をどの順番で変えようとしているか、事前に確認できます。
エラーが出てから直すのではなく、計画の段階で「それは違う」と指摘できる。この一手を設計に組み込んでおくかどうかで、予期しない変更が発生する頻度は大きく変わります。変更後に「なぜこのファイルが書き換わっているのか」と確認する手間が減るのも、実際に使い続けると分かってきます。
2つ目が、問題・制約・文脈の構造化です。
「バグを直して」という渡し方では、Claudeは自分で前提を補完しようとします。その補完がズレると、解決策もズレます。
公式で推奨されているフォーマットは、1行目に「何が壊れているか」を書き、2行目以降に「試したこと、制約、期待する出力形式」を書く構造です。この形式で渡すだけで、一発で解決する割合が変わります。問題の渡し方そのものがスキルになります。
3つ目が `AskUserQuestion` です。
Claudeが曖昧な要件に当たったとき、作業を進める前に確認を取る機能です。要件が曖昧なまま実装が進み、「違う、そういう意味じゃない」という手戻りが起きるのは、この機能を使っていない場合に多く発生します。確認のコストを実装の前に払う設計です。
4つ目が自己検証ステップです。
タスクの最後に「テストを実行して、ビルドが通るか確認してから終わって」と渡しておきます。これを毎回手動で追加するのではなく、\CLAUDE.md\に書いておくと、すべてのタスクの末尾で自動的に走るようになります。変更してみたら動かなかった、という状態でClaudeが止まるのではなく、検証まで含めたループが一つのタスクとして完結します。
plan modeで前手を打ち、自己検証で後手を自動化する。この2つを設計に組み込んだ時点で、開発フローの構造が変わります。
次の章では、これをさらに進めて、継続的なタスクをClaudeに委任する設計を見ていきます。
委任の設計
ここまでの章で、Claudeへの伝え方と記憶の持たせ方を整えました。次は「誰が主語になるか」を変える話です。
⑩ サブエージェント
長い作業を人が手順管理しながら進めていると、どこかで必ず詰まります。「次はこれをやって、終わったらあれをやって」と逐一渡すのは、Claudeではなく人が段取りを担っている状態です。
TodoWriteやTaskツールを使うと、Claudeは自分で作業をサブタスクに分解して並列実行します。公式の言葉を借りれば「concurrent subagent execution」、つまり複数の子Claudeが同時に動く構造です。調査・実装・テストを別々のClaudeが同時に走らせる。人が手順を持たなくていい。
⑪ カスタムスキル（業務の型ファイル）
\.claude/commands/\ ディレクトリにMarkdownファイルを置くと、\/コマンド名\ で呼び出せる指示セットになります。Swarmの文脈では「SKILL.md（業務の型ファイル）」と捉えると分かりやすいです。
Before: 毎回「競合調査をしてください。手順は①②③で…」と書く。
After: \/competitive-research\ と1行打つだけ。
同じ指示を毎回書く時間が消えます。チームで共有すれば、誰が呼んでも同じ品質の出力が返ってくる型になります。
⑫ モデル使い分け
セッション内でAlt+Pを押すとモデルを切り替えられます。設計や構想フェーズでは思考力の高いモデル、単純な実装は軽量モデル、デバッグは中間モデル、という3段階の使い分けが現実的です。
処理の重さに対してモデルの力を合わせる。コスト効率と応答速度が同時に改善します。
⑬ CLAUDE.mdの自動更新
「このプロジェクトで学んだことをCLAUDE.mdに追記して」と渡すと、ClaudeがCLAUDE.md自体を更新します。設計書が自分で育つ構造です。
毎週この命令を1行加えるだけで、CLAUDE.mdは「生きたドキュメント」になっていきます。人が振り返りを書かなくても、Claudeが学んだことを蓄積していく。
⑭ 外部ファイルリンク
\@{ファイルパス}\ でファイルやURL、Issueをコンテキストとして渡せます。「このファイルを読んでから作業して」を1行で完結させる仕組みです。
Before: ファイルの中身をコピペしてプロンプトに貼る。
After: \[@src/config](https://x.com/@src/config).yaml を参照して設定を確認して\ と書くだけ。
委任の設計とは、主語をClaudeに渡す仕組みを作ることです。手順・型・参照・記憶、この4つが揃うと、人は「何を作るか」だけを考えればよくなります。
ただし、委任を増やすほど「Claudeが意図と違う方向に動く」リスクも増えます。次の章では、そのドリフトをどう早期に止めるかを見ていきます。
ドリフトを早期に止める
Claudeへの委任が増えると、ある問題が起きやすくなります。気づいたら意図と全然違う方向に進んでいた、という状態です。これをドリフトと呼びます。
ドリフトは後から直すものではなく、設計で前手を打って防げます。
⑮ 即停止
出力が明らかにおかしい方向に向かっていると感じたら、Escapeキーで即停止できます。「完成してから直せばいい」は誤りです。生成が進むほど修正コストは上がる。途中で止めてプロンプトを直し直す方が、時間もトークンも節約できます。
感覚でおかしいと思ったら、迷わず止める。この判断の速さが精度に直結します。
⑯ 第一出力を証拠として要求
作業に入る前に「まず最初の出力だけ見せて、判断してから続けて」と渡すのが、前手の設計です。
見当違いな方向に10分かけさせるより、最初の1出力で確認してから走らせる。ドリフトの芽を最初の一手で摘む考え方です。特に長時間タスクや、方向性が曖昧なまま始める作業では必ず使います。
「あとは任せた」と渡す前に、「最初だけ確認させて」を挟む。たった1ステップですが、この前手があるかどうかで結果が変わります。
⑰ 通知フック
長時間タスクが終わるまで画面を張り付いて待つのは時間の無駄です。\~/.claude/hooks/\ にスクリプトを置くだけで、タスク完了時にデスクトップ通知を受け取れるようになります。
設定は1度きり。以降は別の作業をしていても、Claudeが終わったタイミングで知らせてくれます。待つという行為自体をなくす設計です。
⑱ スクリーンショット渡し
UIのバグを言葉で説明するのは意外と難しいです。「左上に赤いエラーが出て、ボタンが押せない状態で…」と口頭で伝えるより、スクリーンショットを渡した方が速い。
Claudeは画像を受け取って、エラーの内容・原因・修正案をそのまま返してくれます。「この画面を見て」で完結します。
ここまでで紹介した18個の機能は、全て1人が動かす前提の話です。次の章では、複数のClaudeを並列で走らせて統合する「チームとして使う」構造に入ります。
並列稼働と統合
Claude Codeをチャットツールとして使っている間は、1つのタスクが終わるまで次が始められません。でも設計を変えると、複数のClaudeが同時に動く構造が作れます。
Chrome DevToolsとの統合から始めましょう。ブラウザのエラーログやネットワークログをClaude Codeに直接渡せるため、「コンソールに赤いエラーが出てるけど何が起きてるか分からない」という状況を口頭で説明する必要がなくなります。公式ドキュメントには専用ページが設けられており、デバッグの入口として位置づけられています。
セッション管理も変わります。\claude --continue\で最新セッションをそのまま再開でき、\claude --resume\でセッション一覧から選んで戻れます。さらに\/rename\でセッションに名前をつけると、Gitのブランチと同じ感覚で複数のタスクを並行管理できます。「認証系」「決済系」「ダッシュボード」と名前をつけたセッションを使い分けていけば、コンテキストの切り替えコストがほぼゼロになります。
そして並列稼働の本丸がgit worktreesとの組み合わせです。\claude --worktree feature-auth\と打つと、worktreeによってブランチが完全に隔離された状態のセッションが立ち上がります。認証・決済・ダッシュボードをそれぞれ別のworktreeで動かせば、3つのClaudeが同時並行で開発を進めます。それぞれが独立した作業空間にいるためコンフリクトが起きません。1日で1週間分の開発を終わらせる構造が、ここで初めて設計として成立します。
MCPについても整理しておく必要があります。MCPサーバーが常に最適解とは限りません。公式は「CLI tools are the most context-efficient way to interact with external services」と明記していて、\gh\や\aws\のCLIツールはコンテキスト効率が高く、レート制限も受けにくいとされています。\gh\コマンドさえあれば、GitHub IssueをClaude Codeが自律的に作成・更新・クローズできます。MCPを追加する前に、まずCLIツールが使えるかを確認する判断軸を持っておくと設計がシンプルになります。
並列設計ができると、人が順番を管理する必要がなくなります。複数の主語をClaudeに同時に渡す設計に切り替わるからです。次は、設計した並列処理を席を離れていても動かし続けるシステムに発展させます。
自律稼働
並列設計の次の問いは、「その間、自分はどこにいなければいけないか」です。自律稼働の設計ができると、人がいなくても仕事が進む状態が作れます。
\/loop\は、セッション内で自動ポーリングを走らせる機能です。公式の説明は「Quick polling while a session is open」とあり、セッションが開いている間、指定した操作を繰り返します。\--resume\や\--continue\を使えば期限切れでないセッションを再開でき、元記事の体験談によると最大3日間の無人稼働が可能だったケースも報告されています。公式でその日数を直接確認しているわけではありませんが、長時間の自律稼働の入口として機能することは確かです。
2026年Q1に加わったRemote Controlは、ローカルで動くClaude CodeセッションをスマホやPCブラウザから操作できる機能です。コードはローカルに置いたまま、メッセージだけが暗号化されたチャンネルを通じてやり取りされます。2026年2月にresearch previewとして公開されました。外出先のスマホから「テストが通ったか確認して」と送るだけで、ローカルのClaude Codeが動き続ける構図が成立します。
データベースへの自然言語クエリも設計に組み込めます。MCP経由でSQLite・PostgreSQL・MySQLに接続すると、「先週登録したユーザーを教えて」という日本語でデータを取得できます。公式は「run claude mcp add to connect external tools...your database」と案内しており、SQLを書かずにデータ確認のルーティンをClaudeに委任できます。
思考の深さを制御する4個の機能もあります。\ultrathink\はプロンプトにそのキーワードを含めるだけで最大31,999トークンの拡張思考が発動します。\think\が4,000トークン、\megathink\が10,000トークン、\ultrathink\が31,999トークンという階層があります。複雑なアーキテクチャ決定・セキュリティ実装・パフォーマンス最適化・大規模リファクタリング、つまり本当に難しい10%の問題にだけ使うのが正しい使い方です。全ての問いに使うとコストが無意味に膨らみます。
\/effort ultracode\はセッション全体にxhigh推論と動的ワークフローを有効化する設定です。\ultrathink\が1ターン限定のキーワードなのに対し、\ultracode\はセッションを通じて有効であり続けます。コードベース全体の監査・数百ファイルのマイグレーション・高リスク作業のような「セッション全体が重い仕事」に向きます。ただしトークンコストは大幅に増えるため、場面の見極めが効果を左右します。
チャットに入力して動かすところから始まったClaude Codeが、イベントを検知して自律的に動くシステムの入口まで来ました。人が動かすのではなく、設計がClaudeを動かす状態に変わります。次は、ここまでの機能全体を通じて生産性の差が本質的にどこで生まれるかを確認します。
同じ Claude Code で差がつく理由
速く開発している人は、特別な能力を持っているわけではありません。より系統的に設計しているだけです。
たとえば \/init\ を実行する場面を考えてみてください。同じコマンドを打っても、毎週更新されているCLAUDE.mdと、セットアップ時から放置されたCLAUDE.mdとでは、数ヶ月後の出力品質がまったく異なります。Claudeが読むコンテキストの鮮度と精度が、そのまま出力の質に直結するからです。
調理場で例えるなら、どの食材を使うかより、調理場そのものをどう整えるかが料理の水準を決めます。Claudeのモデル性能はどのユーザーにも等しく提供されています。差がつくのは、コンテキストをどう整えたか、指示をどう仕組み化したか、自律稼働をどう設計したか、この3点の精度です。
「どのモデルを使うか」を議論する前に、今あるCLAUDE.mdがいつ更新されたか確認してみてください。それが設計の現在地を教えてくれます。
では実際に、どこから手をつければよいのか。次の章で段階的な導入順序を整理します。
どこから始めるか 段階的な導入ガイド
27個を一度に覚えようとしなくて大丈夫です。
1週目は4個だけに絞ります。
- \
/init\でプロジェクトの地図を作る - \
/compact\で定期的にコンテキストを圧縮する - plan mode（Shift+Tab）で探索と実行を分離する
- 自己検証ステップ（テスト・ビルド）をClaudeに渡す
この4個だけで、セッションの質が根本から変わります。Claudeが「何をすべきか」を正確に把握した状態で動き始めるので、手戻りの量が目に見えて減ります。
2週目以降は、この土台の上に委任設計を加えます。カスタムスキルで指示を再利用できる形にまとめ、モデル使い分け（Alt+P）で処理の重さと速さを調整し、CLAUDE.mdを週次で更新する習慣をつける。指示を「毎回書くもの」から「蓄積されていくもの」に変える段階です。
1ヶ月後には、サブエージェントとgit worktrees、並列セッションへと進めます。複数の機能を同時に開発しながら、自分は設計と確認に集中できる体制が整います。
\ultrathink\ と \ultracode\ は、この流れの中で「本当に難しい問題に遭遇したとき」に初めて使うものです。すべての問題に持ち出すツールではありません。
段階を踏めば、それぞれの機能が「なぜ必要なのか」が体感でわかるようになります。まずは1週目の4個から始めてみてください。
設計対象として扱い始めた瞬間に変わる
Claude Codeを設計対象として扱い始めた瞬間に、セッションの質が根本から変わります。
この記事で紹介した内容を、保存して見返せる形で整理しておきます。
- \
/init\+ \/compact\+ plan mode + 自己検証の4個が最も土台になる基礎設計です - カスタムスキルで指示の再利用を仕組み化し、CLAUDE.mdは毎週更新する「生きた設計書」として育てます
- サブエージェントを使い始めると、生産性は足し算から掛け算に変わります
- ドリフトは早期に検知して即停止するのが鉄則です。第一出力では必ず証拠を要求してください
- git worktrees + 並列セッションで、複数の機能を同時に開発できます
- \
/loop\で自律稼働を設定し、Remote Controlでスマートフォンから確認・指示できます - \
ultrathink\は「本当に難しい10%」のための専用ツールです。全ての問題に使うものではありません
この記事に出てきた機能のうち、1つでも試してみると、Claude Codeとの付き合い方が少しずつ変わっていきます。
AIエージェントに興味を持っていただいた方へ
Swarm（@swarm_japan）はエージェントの本質的な設計思想とビジネス活用事例を発信しています。
フォローするとAIエージェント時代に必要なビジネス知識が身に付きます👇
★ AIエージェントの最新情報を独自視点で解説
★ エージェントのビジネス活用事例の紹介
★ 独自ノウハウの公開
ご興味を持っていただけた方は、ぜひフォローしてチェックしてみてください👀
