「Claude Code の基本16コマンドで AI 社員化」を数え直す — 実在しないコマンドと、本当に効く16個

X のトレンドに「Claude Code の基本16コマンドで AI 社員化が加速」が上がっていた。関連記事をいくつか開いて、手を止めた。数が合わない。

公式のコマンドリファレンスを数えると、組み込みコマンドは執筆時点（2026年8月）で70件前後ある。バンドルスキル（Claude Code に同梱されたスキル）を足せば80件を超える。16ではない。

そして数以上に気になったのは中身のほうだ。「Claude Code の基本コマンド」として /add /drop /ls を挙げる解説が複数あるが、この3つは Claude Code には存在しない。 別のツールのコマンドである。

トレンドの見出しを責めたいのではない。ここで問いたいのは、「基本コマンドを覚えると AI 社員化が進む」という因果が本当に成り立つのか、という点だ。結論を先に書くと、成り立たない。順に見ていく。そのうえで、暗記用リストの代わりに局面で束ねた16個と、コマンドより効く**「常設物」**を最後に置く。

「基本16コマンド」という数字はどこから来たのか

検索上位に並ぶのは、いわゆる「AI 社員」系の記事群だ。Claude Code で秘書・PM・経理といった仮想部署をつくる、という趣旨のものが多い。そのなかに 「Claude Code × AI社員16名の会社システム」 を掲げるものがある。中を見ると確かに16体のエージェントを部署ごとに配置する構成で、付属するスラッシュコマンドは /morning-briefing /weekly-kpi /invoice といったその人が自分で定義したものが57個ある。

整理すると、こうだ。

• 16 = エージェント（AI 社員）の数
• 57 = その人が自作したカスタムコマンドの数
• どちらも Claude Code の「基本コマンド」の数ではない

つまり 16 はコマンドの数ではなく、配置する社員の数 として使われていた数字だ。それがトレンドの見出しで「16コマンド」と結びついた、というのが素直な読みだろう。

ここで見落とされがちな点がある。/morning-briefing のようなコマンドは覚えるものではなく、書くものだ。Claude Code に元から入っているわけではない。自分の業務に合わせてファイルとして定義したから存在している。「AI 社員化」の実体はこちら側にある。

これは細かい揚げ足取りに見えるかもしれないが、実害がある。「16個のコマンドさえ覚えれば AI 社員化できる」という誤った完了条件を読者に渡してしまうからだ。16個覚えても、AI 社員は1人も増えない。増えるのは後述する「常設物」を書いたときだけである。

存在しないコマンドが「基本」として出回っている

もうひとつの実害はこちらだ。解説記事に出てくる次の3つは、Claude Code のコマンドではない。

なぜ移植できないかというと、ファイル選択のモデルが根本から違うからだ。

Aider は、チャットに載せるファイルを人間が明示的に出し入れする設計になっている。/add で対象に入れ、/ls で現在の顔ぶれを確認し、要らなくなったら /drop で外す。文脈に何が入っているかを管理する責任は人間側にあり、だからこそこの3つが中核コマンドとして必要になる。

対して Claude Code は、必要なファイルをエージェント自身が探して読む設計だ。人間はやりたいことを言えばよく、どのファイルを開くかはエージェントが Grep や Glob で決める。人間が事前に対象を宣言する工程そのものが存在しないので、/add に相当するコマンドも要らない。

つまりこれは「名前が違うだけの同じ機能」ではなく、片方には存在しない工程なのだ。だからコマンド表だけを移植しても噛み合わない。/drop は Claude Code のコマンド一覧に無いので、打っても意図した動作はしない。

この批判は、当ブログの過去記事にも当てはまる

ここまで他所の記事を検証しておいて黙っているのはフェアではないので、書いておく。

当ブログには 「Claude Code で使える神コマンド10選」（2026年3月）という記事がある。今回の作業で公式リファレンスと突き合わせたところ、そこで挙げた10個のうち、組み込みコマンドとして実在するのは /diff と /status だけだった。/edit /undo /run /test /fix /refactor /search /commit /doc は公式のコマンド一覧に無い。

つまりこの記事が批判している構図が、そのまま自分に返ってくる。当時、一次情報と照合しないまま書いた。 旧記事の訂正は別途行うが、ここで隠さずに書いておくほうが、この記事の主張と整合する。

教訓として一般化するなら：AI ツールの解説記事は、コマンド名の一致まで確認しないとそのまま信じられない。それは他人の記事に限らない。一次情報は 公式のコマンドリファレンス にある。/help を打てば手元の実物が一覧できる。それが最短の検証だ。

Claude Code のスラッシュコマンド16個【局面別】

「16」という数に意味はない。ただ、覚えるべきコマンドを局面で束ねると、たまたま4×4に収まるというのは実用的な整理ではある。トレンドの見出しに正面から答える形で並べ直した。

暗記用のリストではなく、**「困ったときにどの引き出しを開けるか」**の地図として使ってほしい。

① 立ち上げ — /init /memory /permissions /config

この4つは毎回打つものではない。プロジェクトを開いた最初の1回で効かせて、あとは放置する種類のコマンドだ。

特に /permissions は、後から効いてくる。承認プロンプトが出るたびに手を止めているうちは、エージェントは非同期に働けない。逆にここを緩めすぎると事故につながる。**「読み取り系は許可、破壊系は確認」**の線を最初に引いておく（この線引きは Claude Code のセキュリティ設定で詳しく扱った）。

② 仕事の渡し方 — /plan /goal /subtask /agents

ここが「AI 社員化」に一番近い層だ。

/plan は、実装させる前に計画を出させて突き返すための関門である（plan モードはコスト削減にも効く）。/goal はその裏返しで、人間が停止条件を宣言する。「テストが全部通るまで」と置けば、その条件を満たすまで作業が続く。

/subtask は文脈の防衛でもある。調べ物の途中経過をメインの会話に流し込むと、本題の文脈が押し出される。サブエージェントに投げれば、中間出力は向こうに残り、こちらには結論だけが返る。

③ 文脈の管理 — /context /compact /clear /rewind

長いセッションで応答の質が落ちたとき、原因はモデルではなく文脈であることが多い（context rot とセッション管理）。まず /context で何が食っているかを見る。

/compact と /clear の使い分けは明快だ。話の続きをしたいなら /compact、話を切りたいなら /clear。 同じ問題を延々こねているセッションを /compact で引き延ばすと、間違った前提ごと要約されて残る（要約による圧縮の限界）。そういうときは /clear して、必要な事実だけ改めて渡すほうが速い。

/rewind は会話だけでなくコードも一緒に戻る。「3手前の方針のほうが良かった」を実際にやり直せる。

④ 出す前の検証 — /diff /verify /code-review /security-review

なお下2つは組み込みコマンドではなくバンドルスキルとして提供されるが、使う側から見た呼び出し方は変わらない。

AI 社員化の成否は、実はここで決まる。 人間がレビューのボトルネックである限り、何人 AI を並べても人間の処理速度以上には出ない。

/verify を挟むと「動くと言い張るが動かない」が減る。/code-review と /security-review を挟むと、人間のレビューは「全部見る」から「指摘の妥当性を判断する」に変わる。この2つは差分・PR 番号・ブランチ・パスのいずれも対象に取れるので、PR 単位でまとめて回せる。冒頭の図で検証から文脈管理へ戻る破線は、ここで通らなかったときの経路にあたる。

コマンドより効くのは「常設物」

ここまで16個を並べておいて言うのも何だが、コマンドは AI 社員化の主役ではない。

コマンドは「その場で1回効く」ものだ。打たなければ効かないし、打つのは人間である。つまり 人間が覚えている限りでしか効かない。 これは自動化ではなく、手動操作の別名にすぎない。

対して、書けば全セッションに勝手に効くものがある。

この4つの設定方法そのものはフック・カスタムコマンド・サブエージェントの記事にまとめてある。ここでは「なぜコマンドより効くのか」だけを見る。

「AI 社員」という比喩に一番近い実体は、上の表のサブエージェントだ。.claude/agents/code-reviewer.md のような Markdown 1枚で定義できる。

---
name: code-reviewer
description: Reviews code for quality and best practices
tools: Read, Glob, Grep
model: sonnet
---

You are a code reviewer. When invoked, analyze the code and provide
specific, actionable feedback on quality, security, and best practices.

.claude/agents/ に置けばプロジェクト全体（チームで共有可能）、~/.claude/agents/ に置けば自分の全プロジェクトで効く。description は「いつこの担当者に振るか」の判断材料として使われるので、ここを曖昧に書くと呼ばれない。tools で権限を絞れるのも重要で、レビュー担当に Write を渡さないといった設計がそのまま書ける。

tools は許可リストだが、逆に disallowedTools で継承したツールから引くこともできる。ほかにも次の項目が使える。

• permissionMode — 承認の扱い（plan にすれば読み取り専用の担当者になる）
• maxTurns — 暴走を防ぐターン数の上限
• skills — 事前に読み込ませるスキル
• memory — 永続メモリのスコープ（user / project / local）
• isolation: worktree — 独立した git worktree で作業させる

詳細はサブエージェントの公式ドキュメントにある。関連して、エージェントからスキルへの設計変更も押さえておくと使い分けが決めやすい。

スキルについて押さえておきたいのは、カスタムコマンドとスキルが統合されたという点だ。.claude/commands/deploy.md と .claude/skills/deploy/SKILL.md はどちらも /deploy になる。既存の commands/ はそのまま動くが、スキル形式にすると付随ファイルを置くディレクトリが持てる（公式ドキュメント）。

同じ指示を3回貼ったら、それはスキルにすべき合図だ。 CLAUDE.md に手順を書き足していくと全セッションの文脈を圧迫する（CLAUDE.md は less is more）が、スキルの本文は呼ばれたときだけ読み込まれる。長い手順書ほどスキルに逃がす価値がある。

最初の30分で何をするか

「16コマンドを覚える」より投資対効果が高い順に並べる。

1. /init を打つ。 生成された CLAUDE.md を読み、事実と違う記述を直す。自動生成をそのまま残すのが一番もったいない。
2. 承認プロンプトが出るたびにメモする。 3回以上出たものは /permissions で許可に回す。手が止まる回数がそのまま並列化の上限になる。
3. 同じ指示を貼り直したらスキルにする。 貼った回数がそのまま「まだ自動化していない量」だ。
4. レビュー担当のサブエージェントを1人つくる。 tools を読み取り系だけに絞る。ここが人間のレビュー負荷を最初に削る。
5. 「必ずやる」ことはフックに落とす。 CLAUDE.md に書いたルールは提案であって強制ではない。守られなくて困るものだけフックに昇格させる（この昇格の判断基準は訂正を OS にする話で詳しく書いた）。

この5つは全部、1回やれば以後ずっと効く。コマンドの暗記量とは無関係だ。

まとめ

• Claude Code の組み込みコマンドは執筆時点で70件前後、バンドルスキルを含めれば80件超あり、「基本16コマンド」という区切りは公式には存在しない
• 「16」は 「AI 社員16名」（エージェントの数）が混ざったもの。同じ記事のコマンドは57個で、しかも全部自作のカスタムコマンドだった
• 解説記事にある /add /drop /ls は Aider のコマンドで、Claude Code には存在しない。ファイル選択のモデルが違うので、コマンド表だけ移植しても噛み合わない
• 同じ誤りは当ブログの過去記事にもあった（「神コマンド10選」の10個中、実在は2個）。他人事ではない
• 実用的に束ねるなら 立ち上げ / 仕事の渡し方 / 文脈の管理 / 検証 の4局面。たまたま4×4=16個に収まる
• ただし AI 社員化を進めるのはコマンドではなく常設物（CLAUDE.md・スキル・サブエージェント・フック）。コマンドは打った1回しか効かないが、常設物は全セッションに効く

コマンド表を暗記する前に、/help を打って手元の実物を見たほうが速い。その一覧に /drop は無い。

参考リンク

• Claude Code コマンドリファレンス（公式）
• サブエージェント（公式）
• スキル（公式）
• Aider In-chat commands