先に要点
- Claude Codeでは、まず `/init`、`/context`、`/compact`、`/clear`、`/cost`、`/permissions`、`/diff`、`/rewind` あたりを覚えると作業がかなり安定します。
- `/compact` は会話を要約して続けるためのコマンドで、別タスクへ切り替えるなら `/clear` の方が向いています。
- 翻訳では、文面だけでなく「キーを維持する」「用語集を渡す」「対象ロケールごとに分ける」「レビューしやすい差分にする」ことが重要です。
- 英語を基準文にして各言語へ展開する方法はコスパが良い場面がありますが、日本語のニュアンスが原本なら無理に英語経由にしない方が安全です。
Claude Codeを使い始めると、自然言語で頼むだけでもかなり作業できます。
ただ、長く使うほど差が出るのは、実はプロンプトのうまさだけではありません。セッションをどう整理するか、いつコンテキストを捨てるか、どのコマンドで確認するかがかなり効きます。
この記事では、2026年4月19日時点のClaude Code公式ドキュメントを確認しながら、覚えておきたいスラッシュコマンドと、翻訳・i18n作業をClaude Codeに任せるときのコツを整理します。
Claude Codeそのものの概要から確認したい場合は、Claude Opus 4.7とは？性能・料金・API移行・Claude Codeへの影響を徹底解説 もつながります。
まず覚えたいClaude Codeコマンド
Claude Codeの公式Commandsページでは、セッション内で / を入力すると利用可能なコマンドを確認できると説明されています。
全部を覚える必要はありません。実務でまず効くのは、次のあたりです。
| コマンド | 使いどころ | 注意点 |
|---|---|---|
| /init | プロジェクト用のCLAUDE.mdを作る入口 | 生成された内容をそのまま信じず、実際のコマンドや運用に合わせて直す |
| /context | 今のセッションで何がコンテキストを消費しているか見る | 長いログ、巨大ファイル、不要な会話が膨らんでいないか確認する |
| /compact | 会話履歴を要約して、同じ作業を続ける | 何を残してほしいか指示を付けると失敗しにくい |
| /clear | 関係ない作業へ切り替えるときに新しい会話へする | 前の文脈が消えるので、必要な要点は別途メモしてから使う |
| /cost | API利用時のトークン使用量や推定コストを見る | Pro/Maxのようなサブスク利用では請求額の確認用途とは違う。利用傾向は `/stats` も見る |
| /permissions | 実行してよいツールやコマンドの許可設定を見直す | 便利さだけで緩めすぎると危険。削除、外部送信、本番操作は慎重に扱う |
| /diff | Claudeが変えた差分を見る | 「動いた」だけでなく、関係ない変更が混ざっていないか見る |
| /rewind | 会話やコードを前の地点へ戻す | Gitの代わりではない。重要な作業ではブランチやコミットも使う |
| /model・/effort | モデルや推論の強さを切り替える | 常に最大にすれば良いわけではない。軽い翻訳や単純修正ではコストが重くなる |
この中でも、最初に差が出るのは /context、/compact、/clear です。
Claude Codeは、ファイルを読み、コマンドを実行し、出力を見ながら作業するため、セッションが長くなるほどコンテキストが膨らみます。公式のベストプラクティスでも、コンテキスト管理は重要な制約として扱われています。
/compactとは何か
/compact は、会話履歴を要約してコンテキストウィンドウを空け、同じ作業を続けやすくするためのコマンドです。
Claude Code公式のCommandsページでも、/compact [instructions] は会話を要約してコンテキストを空けるコマンドとして説明されています。
たとえば、長めの修正をしている途中で、次のように使えます。
/compact 変更したファイル、未解決のTODO、実行したテスト、失敗した方針、次にやるべき確認を残してください
こうすると、単に圧縮するだけでなく、残してほしい情報の優先順位を伝えられます。
特に、次のようなタイミングでは /compact が効きます。
- 1つの機能修正が長引いている
- 調査で多くのファイルを読ませた
- エラーログを何度も貼った
- まだ同じタスクを続けたい
- 途中経過を失いたくない
逆に、完全に別の作業へ移るなら /compact より /clear の方が向いています。
前の文脈を要約して残す必要がないなら、きれいに捨てた方がAIの判断がぶれにくいです。
/compactと/clearの違い
| 観点 | /compact | /clear |
|---|---|---|
| 目的 | 同じ作業を続けるために会話を要約する | 新しい会話としてやり直す |
| 向いている場面 | 同じバグ修正、同じ機能追加、同じPR作業を続ける | 翻訳から別機能の実装へ移る、調査から別案件へ移る |
| 残るもの | 要約された重要情報 | 基本的に前の会話文脈は使わない |
| 失敗しやすい使い方 | 残すべき情報を指示せずに雑に圧縮する | 必要な前提をメモせずに消す |
実務では、次のように考えるとかなり分かりやすいです。
- 同じ作業を続ける:
/compact - 作業を切り替える:
/clear - どちらか迷う: まず
/contextを見る - やらかした:
/rewindやEsc + Esc
Claude Code公式のコンテキストウィンドウ解説でも、長いセッションでは /compact が会話履歴を構造化された要約に置き換えること、プロジェクトルートのCLAUDE.mdやauto memoryは再注入されること、パスに紐づくルールやサブディレクトリのCLAUDE.mdは再読込が必要になることが説明されています。
つまり、/compact は「全部を完璧に残す魔法」ではありません。重要な情報は上の方に置く、必要なら要約指示を付ける、圧縮後に前提を確認する、という使い方が安全です。
作業別のおすすめコマンド
新しいプロジェクトを触るとき
まずは /init でCLAUDE.mdのたたき台を作り、不要な説明を削って、実際に使うコマンドだけを残します。
そのうえで、次のように依頼すると入りやすいです。
このリポジトリを調査してください。まずCLAUDE.mdとREADMEを読み、主要なディレクトリ、テストコマンド、危険な変更になりそうな箇所を整理してください。実装はまだしないでください。
大きめの作業なら、先にPlan Modeで調査させる方が安全です。
公式ベストプラクティスでも、複数ファイルに触る変更や不慣れなコードでは、探索、計画、実装を分ける流れが推奨されています。
途中で迷走したとき
Claude Codeが同じ修正を何度も外すと、セッション内に失敗した方針がたまります。
そのまま続けると、前の誤った仮説に引っ張られることがあります。
この場合は、次の順で立て直します。
Escで止める/diffで不要な変更がないか見る/rewindで戻すか判断する- 必要なら
/compactで「失敗した方針」を明示して残す - それでもズレるなら
/clearして、学んだことだけを短く貼り直す
個人的には、同じ論点で2回外したら、粘るより整理した方が早いことが多いです。
コストや利用量が気になるとき
API利用なら /cost で現在セッションのトークン使用量を確認できます。
公式のコスト管理ページでは、/cost はAPI利用者向けの詳細なトークン統計であり、ProやMaxのサブスク利用では請求額確認の用途とは異なると説明されています。
コストを下げたいときに効くのは、モデルを下げることだけではありません。
/clearで無関係な文脈を捨てる/compactに残す情報を指定する- 巨大ログを丸ごと貼らず、エラー周辺だけ渡す
- 何でもOpusにせず、軽い作業はSonnetや低めのeffortで進める
- 翻訳や一括処理はファイル単位・ロケール単位に分ける
トークンは、読ませる情報が増えるほど増えます。
翻訳でも同じで、関係ない履歴を抱えたまま「ついでに翻訳して」と頼むより、翻訳専用のきれいなセッションにした方が安く安定しやすいです。
翻訳でClaude Codeを使うときのコツ
Claude Code公式のOverviewには、CLIで claude -p "translate new strings into French and raise a PR for review" のように翻訳を自動化する例があります。
つまり、Claude Codeはコード修正だけでなく、翻訳ファイルの更新、差分作成、PR化にも使えます。
ただし、翻訳は「日本語を英語にして」だけだと実務では足りません。
多言語サイトやアプリでは、次の制約が重要になります。
- 翻訳キーを変えない
- JSONやYAMLの構造を壊さない
- プレースホルダーを維持する
- 製品名、機能名、固有名詞を勝手に訳さない
- 文字数が長くなりすぎる言語を考慮する
- 敬体、常体、カジュアルさをそろえる
- 差分レビューしやすい単位で出す
たとえば、次のように頼む方が安全です。
@locales/en.json を基準に、@locales/ja.json と @locales/ko.json の不足キーだけ翻訳してください。
条件:
- JSONのキー順と構造を維持する
- {name} や %s のようなプレースホルダーは変更しない
- productName は翻訳しない
- 日本語は自然な敬体にする
- 韓国語はアプリUI向けの短い表現にする
- 変更後にJSONとしてパースできるか確認する
このように、翻訳対象、対象外、出力形式、検証方法を明示します。
Claude Codeに任せるなら、最後にパーサーやテストで機械的に壊れていないことを確認させるのが大事です。
英語を渡して各言語に翻訳した方がコスパは良いのか
結論から言うと、英語を基準文にして各言語へ展開する方がコスパが良い場面はあります。
ただし、常に正解ではありません。
英語をハブにするメリットは、次の通りです。
- 多くのAIモデルが英語の技術文脈を扱いやすい
- 翻訳元を1つに固定できる
en.jsonを基準に不足キーを検出しやすい- 各言語の差分を同じ構造でレビューしやすい
- 翻訳メモリや用語集を作りやすい
特に、UI文言、エラーメッセージ、ヘルプテキスト、技術ドキュメントでは、英語をsource of truthにして、そこから日本語、韓国語、中国語、フランス語などへ展開する流れはかなり現実的です。
一方で、日本語の文面が原本で、ブランドのトーンや文化的なニュアンスが強い場合は、無理に英語を挟むと意味が薄まります。
たとえば、採用コピー、和文の利用規約の説明、国内向けキャンペーン、細かい敬語ニュアンスが重要なFAQでは、日本語原文から直接翻訳した方が安全なことがあります。
| 方式 | 向いている場面 | 注意点 |
|---|---|---|
| 英語を基準に各言語へ翻訳 | UI文言、技術文書、SaaS、グローバル展開 | 日本語独自のニュアンスは薄まりやすい |
| 日本語から各言語へ直接翻訳 | 国内向け原稿、ブランド文、敬語や文脈が重要な文章 | 言語ごとの品質差が出やすく、レビュー負荷が上がる |
| 英語版と日本語版を両方渡す | 精度を上げたい重要ページ、利用規約の説明、ヘルプセンター | 入力トークンは増えるが、意図のズレを減らしやすい |
コスパを見るなら、単純なトークン単価だけではなく、レビュー時間も含めて考えます。
少し多めに文脈を渡して翻訳品質が上がり、レビューが30分減るなら、そちらの方が安いこともあります。
翻訳プロンプトで入れるべき情報
Claude Codeに翻訳を頼むときは、次の情報を入れると安定します。
翻訳対象: @locales/en.json
出力先: locales/ja.json, locales/fr.json, locales/de.json
目的: SaaS管理画面のUI文言
トーン: 短く、自然で、業務向け
維持するもの: JSONキー、プレースホルダー、HTMLタグ、製品名
翻訳しない語: Claude Code, API, workspace, token
検証: JSONとしてパースし、未翻訳キーと余分なキーを一覧にする
レビュー: 不自然な直訳がありそうな文言を最後に表で出す
ここで大事なのは、翻訳そのものより翻訳後の確認手順です。
AIは自然な文章を作れますが、JSONのカンマ、プレースホルダー、HTMLタグ、複数形、文字数制限を壊すことがあります。
実務では、次の確認をセットにします。
- JSON/YAMLとしてパースできるか
- sourceにあるキーが全言語に存在するか
- targetに余分なキーがないか
{count}や%sが消えていないか- UIに収まる長さか
- 法務・料金・セキュリティ文言を勝手に柔らかくしていないか
このあたりを自動チェックできるなら、Claude Codeに「翻訳して終わり」ではなく、「翻訳して検証コマンドを実行して、問題を直して」と頼めます。
翻訳用のカスタムコマンドやSkillを作る
同じ翻訳作業を何度もするなら、毎回プロンプトを書くよりSkill化した方が安定します。
Claude Code公式ドキュメントでは、SKILL.md を作ることでClaudeの能力を拡張でき、直接 /skill-name で呼び出せると説明されています。既存の .claude/commands/ も動作しますが、公式上はSkillsがより広い仕組みとして案内されています。
たとえば、次のようなSkillを作れます。
---
name: translate-locales
description: Translate locale JSON files while preserving keys, placeholders, and product terminology.
disable-model-invocation: true
---
Translate locale files from the source locale to target locales.
Rules:
- Preserve all JSON keys and ordering.
- Do not translate placeholders such as {name}, {count}, %s, or HTML tags.
- Keep product names unchanged.
- Prefer concise UI wording.
- After editing, validate JSON syntax.
- Report missing keys, extra keys, and suspicious literal translations.
こうしておくと、次のように呼べます。
/translate-locales source=locales/en.json targets=ja,ko,fr
翻訳は繰り返し作業になりやすいので、Skill化の効果が出やすい分野です。
ただし、自動実行で本番反映まで進めるのは危険です。翻訳は必ず差分レビューし、重要ページはネイティブチェックや担当者レビューを入れた方が安全です。
翻訳でやりがちな失敗
1. 全言語を一気に頼みすぎる
対象言語が多いほど、出力が長くなり、途中で抜けやすくなります。
最初は ja と ko だけ、または1ファイルだけで試して、問題がなければ広げる方が安全です。
2. 用語集を渡さない
同じ workspace を「ワークスペース」「作業領域」「スペース」と揺らされると、UI全体の品質が落ちます。
翻訳前に「翻訳しない語」「訳語を固定する語」を短い表で渡すと、レビューがかなり楽になります。
3. 日本語を英語にしてから多言語化して意味が薄まる
英語ハブは便利ですが、原文の意図が日本語にある場合は危険です。
この場合は、日本語原文と英語参考訳の両方を渡し、「意味は日本語を優先、用語は英語を参考」と指定するとズレを減らせます。
4. UI確認をしない
翻訳テキストは、文章として自然でもUIに入りきらないことがあります。
ドイツ語やフランス語などで長くなりやすい文言、モバイル画面、ボタン文言、ナビゲーションは実画面で確認した方が安全です。
まとめ
Claude Codeでは、まず /init、/context、/compact、/clear、/cost、/permissions、/diff、/rewind を覚えると作業がかなり安定します。
特に /compact は、長い作業を続けるための重要コマンドです。ただし、別タスクへ移るなら /clear、失敗から戻るなら /rewind と使い分けます。
翻訳では、Claude Codeを単なる翻訳エンジンとして使うより、ファイル構造、キー、プレースホルダー、用語集、検証コマンドまで含めて任せる方が実務向きです。
英語を基準に各言語へ展開する方法は、UI文言や技術文書ではコスパが良い場面があります。一方で、日本語のニュアンスが原本なら、英語経由で意味を薄めないように注意が必要です。
Claude Codeは賢いですが、長い文脈を抱えたまま何でも続けると精度もコストも悪くなります。
コマンドでセッションを整理し、翻訳では入力と検証を型にする。ここを押さえると、Claude Codeはかなり実務の道具らしくなります。
参考リンク
- Claude Code Docs: Commands
- Claude Code Docs: Explore the context window
- Claude Code Docs: Manage costs effectively
- Claude Code Docs: Best Practices for Claude Code
- Claude Code Docs: Overview