日常的に使えるClaude Codeのヒントとベストプラクティス50選

 (x.com/codevolutionweb)
25 ポイント 投稿者 GN⁺ 2026-03-20 | 1件のコメント | WhatsAppで共有
  • Claude Codeをすでに使っている開発者向けの実践的なヒント50選で、Anthropic公式ドキュメント、開発者Boris Cherny、コミュニティの経験、1年間の日常利用経験をもとに整理
  • cc alias、!プレフィックス、Esc巻き戻しなどのセッション運用ショートカットから、サブエージェント、エージェントチーム、worktree並列作業まで幅広く網羅
  • CLAUDE.mdの書き方、Hooksシステム、コンテキストウィンドウ管理など、品質と一貫性を維持するための構造的な方法論を含む
  • CLIツール活用、MCPサーバーの選定、バッチ処理など、さまざまなワークフローパターンを提示
  • 50個すべてを適用する必要はなく、最も不便だったもの1つから試してみるという段階的導入を推奨

1. cc aliasの設定

  • alias cc='claude --dangerously-skip-permissions'を ~/.zshrc（または ~/.bashrc）に追加すると、ccと入力するだけでClaude Codeセッションを開始可能
  • すべての権限プロンプトをスキップする設定であり、フラグ名も意図的に物騒
  • Claude Codeがコードベースに対して何をできるのかを完全に理解したうえでのみ使うべき

2. !プレフィックスでbashコマンドをインライン実行

  • !git statusや!npm testを入力すると、コマンドが即座に実行され、コマンドと出力がコンテキストに残る
  • Claudeが結果を確認して後続作業を行えるため、Claudeに実行を頼むより速い

3. Escで停止、Esc+Escで巻き戻し

  • EscはClaudeを途中で止めるが、コンテキストは失わない — すぐに方向転換できる
  • Esc+Esc（または /rewind）では、Claudeが作成したすべてのチェックポイントをスクロールメニューで開き、コード・会話・その両方を復元可能
    • 復元オプションは4種類: コードと会話、会話のみ、コードのみ、チェックポイント以降の要約
  • 確信度40%のアプローチでも試せる — 失敗しても巻き戻しでノーダメージ
    • ただし、チェックポイントが追跡するのはファイル編集のみで、bashコマンド（マイグレーション、DB作業）の変更は記録されない
  • claude --continueで直近の会話を再開し、claude --resumeでセッションセレクターを使える

4. Claudeに自己検証の手段を与える

  • プロンプトにテストコマンド、リンタチェック、期待される出力を含めることで、Claudeが自分でミスを見つけるフィードバックループを作る
    • 例: "authミドルウェアをJWTにリファクタリングして。変更後に既存のテストスイートを実行し、失敗をすべて修正してから完了して"
  • Boris Chernyによれば、これだけで品質が2〜3倍向上
  • UI変更ではPlaywright MCPサーバーを設定し、Claudeがブラウザを開き、ページを操作し、UIが期待どおりに動くか検証できる — ユニットテストが見落とす問題を拾える

5. 言語別コードインテリジェンスプラグインを導入

  • LSPプラグインはファイル編集後に自動診断（型エラー、未使用import、欠落した戻り値型など）を提供し、導入できる単一プラグインの中でも最も効果が高い
  • インストールコマンド例:
    • /plugin install typescript-lsp@claude-plugins-official
    • /plugin install pyright-lsp@claude-plugins-official
    • /plugin install rust-analyzer-lsp@claude-plugins-official
    • /plugin install gopls-lsp@claude-plugins-official
  • C#、Java、Kotlin、Swift、PHP、Lua、C/C++プラグインも/pluginのDiscoverタブで利用可能
  • システムに対応する言語サーバーのバイナリがインストールされている必要がある（なければプラグインが通知）

6. gh CLIを使い、あらゆるCLIツールを学ばせる

  • gh CLIを使えば、別途MCPサーバーなしでPR、Issue、コメントを処理できる — CLIツールはMCPサーバーよりコンテキスト効率が高い（ツールスキーマをコンテキストウィンドウに読み込まないため）
  • jq、curlなどの標準CLIツールにも同様に当てはまる
  • Claudeが知らないツールでも、--helpの出力を読んで構文を把握し、自分でコマンドを実行できる — 例: "sentry-cli --helpで学習してから、本番環境の最新エラーを見つけて"
  • ニッチな社内CLIツールでも機能する

7. 複雑な推論には"ultrathink"を追加

  • "ultrathink"キーワードでeffortを高く設定し、Opus 4.6で適応的推論を有効化
  • アーキテクチャ判断、難しいデバッグ、多段階推論など、Claudeが行動前に十分考える必要がある状況に向いている
  • /effortで常時設定することも可能 — 単純な作業では低いeffortにして高速かつ低コストを維持
  • 変数名変更にthinkingトークンを使う必要はない — 問題に応じてeffortを調整する

8. スキルでオンデマンド知識を拡張

  • スキルはClaudeの知識を拡張するMarkdownファイルで、CLAUDE.mdと異なり関連タスクでのみ読み込まれるため、コンテキストを軽く保てる
  • .claude/skills/に作成するか、プラグインにバンドルされた事前構築済みスキルをインストール可能（/pluginで探索）
  • APIルール、デプロイ手順、コーディングパターンなど、Claudeがたまに必要だが常時は不要な特化ドメイン知識に適している

9. 携帯電話からClaude Codeを操作

  • claude remote-controlでセッションを開始し、claude.ai/codeまたはiOS/AndroidのClaudeアプリから接続
  • セッションはローカルマシン上で実行され、スマホやブラウザは単なる接続窓口 — メッセージ送信、ツール呼び出しの承認、進捗監視が可能
  • tip #1のcc aliasを使っていれば追加承認が不要なため、リモート操作がさらにスムーズになる — タスクを開始して席を外し、Claudeが完了した時や想定外の状況になった時だけ確認すればよい

10. コンテキストウィンドウを1Mトークンに拡張

  • Sonnet 4.6とOpus 4.6はいずれも1Mトークンのコンテキストウィンドウをサポート
  • Max、Team、Enterpriseプランでは、Opusは自動で1Mコンテキストにアップグレードされる
  • /model opus[1m]または/model sonnet[1m]で、セッション中にモデルを切り替え可能
  • 大きなコンテキストで品質が気になる場合は、500kから段階的に増やしてテスト
  • CLAUDE_CODE_AUTO_COMPACT_WINDOWとCLAUDE_AUTOCOMPACT_PCT_OVERRIDEでコンパクションの発動タイミングを制御

11. アプローチが不確かなときはPlan Modeを使う

  • Plan Modeは複数ファイルの変更、見慣れないコード、アーキテクチャ判断に向いている — 事前に数分投資することで、Claudeが20分かけて間違った問題を解く事態を防げる
  • 小さくて範囲が明確なタスクではスキップしてよい — diffを一文で説明できるなら、そのまま実行
  • Shift+TabでNormal、Auto-Accept、Planの権限モードを切り替え可能（会話を離れずに）

12. 無関係な作業の間では/clearを実行

  • きれいなセッションに鋭いプロンプトを与えるほうが、散らかった3時間のセッションより優秀 — 別タスクならまず/clear
  • 進捗を捨てるように感じるが、蓄積したコンテキストが現在の指示を埋もれさせ、30分ぶん損した感覚を生む
  • /clearと、集中した開始プロンプトを書くための5秒のほうがはるかに効率的

13. バグを解釈せず、生データを貼り付ける

  • バグを言葉で説明すると、Claudeが推測して修正してまた繰り返す、遅い工程になりがち
  • エラーログ、CI出力、Slackスレッドをそのまま貼り付けて"fix"と言えば、Claudeは分散システムのログを読み、問題箇所を追跡する
  • 人間の解釈は、Claudeが根本原因を正確に見つけるために必要な細部を失わせる余計な抽象化になる
  • CIにも同様に使える — "Go fix the failing CI tests"とCI出力を貼り付ける、またはPRのURL/番号と一緒に失敗チェックの修正を依頼する
  • ターミナル出力を直接パイプすることも可能:
    • cat error.log | claude "explain this error and suggest a fix"
    • npm test 2>&1 | claude "fix the failing tests"

14. /btwで素早いサイド質問

  • /btwは会話履歴に入らないオーバーレイを開き、素早く質問できる
  • 現在のセッションに関する明確化に使う: "なぜこのアプローチを選んだの?" または "他の選択肢とのトレードオフは?"
  • 回答は閉じられるオーバーレイに表示され、メインコンテキストを軽く保てる

15. --worktreeで分離された並列ブランチを実行

  • claude --worktree feature-authで分離された作業コピーと新しいブランチを作成 — git worktreeの設定と後片付けはClaudeが自動処理
  • Claude Codeチームが最大級の生産性向上要因の1つと評価
  • 3〜5個のworktreeを立ち上げ、それぞれ独立したClaudeセッションを並列実行（通常は2〜3個を使用）
  • 各worktreeは独立したセッション、ブランチ、ファイルシステム状態を持つ
  • ローカルworktreeの限界はマシンのリソース — 複数のdevサーバー、ビルド、ClaudeセッションがCPUを奪い合う
    • Builder.ioは各エージェントを別個のクラウドコンテナに配置してマシン負荷を解消

16. Ctrl+Sでプロンプトを一時保存

  • 長いプロンプトを書いている途中で先に短い回答が必要になったら、Ctrl+Sで下書きをstash
  • 先に短い質問を送信すると、stashしたプロンプトが自動で復元される

17. Ctrl+Bで長時間タスクをバックグラウンド化

  • Claudeが時間のかかるbashコマンド（テストスイート、ビルド、マイグレーション）を開始したら、Ctrl+Bでバックグラウンドに回せる
  • Claudeは作業を続け、ユーザーも会話可能 — プロセス完了時に結果を表示

18. ライブステータスラインを追加

  • ステータスラインはClaudeの各ターン後に実行されるシェルスクリプトで、ターミナル下部に現在のディレクトリ、gitブランチ、コンテキスト使用量を色分けして表示
  • /statuslineコマンドで素早く設定可能 — 何を表示するかを尋ね、スクリプトを自動生成

19. サブエージェントでメインコンテキストをきれいに保つ

  • 「サブエージェントを使って、決済フローが失敗したトランザクションをどう処理しているか調べて」と頼むと、別のClaudeインスタンスが独立したコンテキストウィンドウでファイルを読み、分析し、簡潔な要約を返す
  • 深い調査はコンテキストウィンドウの半分を消費しかねないため、サブエージェントでそのコストをメインセッションから切り離す
  • 組み込みタイプ: Explore（Haiku、高速なファイル検索）、Plan（読み取り専用分析）

20. マルチセッション調整のためのエージェントチーム

  • 実験的だが強力な機能 — CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMSを設定または環境変数に追加して有効化
  • 「これらのモジュールを並列にリファクタリングする3人のチームメンバーでエージェントチームを作って」と指示
  • チームリーダーがメンバーに作業を割り振り、各自が独立したコンテキストウィンドウと共有タスクリストを持ち、メンバー同士で直接メッセージ可能
  • 3〜5人のメンバー、各メンバーあたり5〜6個のタスクから始めるのを推奨
  • 同じファイルを編集するタスクの割り当ては上書き問題があるため避ける — まずリサーチとレビューのタスクから始め、並列実装へ広げる

21. コンパクションに保持指示を追加

  • コンテキストのコンパクション時（自動または/compact）に保持したい内容を指定できる: /compact focus on the API changes and the list of modified files
  • CLAUDE.mdに常設の指示を追加することも可能: "コンパクション時は変更したファイルの完全な一覧と現在のテスト状況を保持せよ"

22. /loopで繰り返しチェックを実行

  • /loop 5m check if the deploy succeeded and report backで繰り返しプロンプトをバックグラウンドでスケジューリング
  • 間隔は任意（デフォルトは10分）で、s、m、h、d単位をサポート
  • /loop 20m /review-pr 1234のように他のコマンドもループ可能
  • タスクはセッションスコープで3日後に失効 — 忘れられたループが永久に動き続けることはない
  • デプロイ監視、CIパイプライン監視、外部サービスのポーリングに活用

23. 音声入力で情報量の多いプロンプトを書く

  • /voiceでプッシュ・トゥ・トークを有効化し、Spaceキーを押しながら話すとリアルタイムで文字起こしされてプロンプトに挿入される
  • 音声とタイピングは同じメッセージ内で混在可能
  • 音声プロンプトはタイピングより自然により多くのコンテキストを含められる — 背景、制約条件、望む結果を、キー入力を節約しながら説明できる
  • Claude.aiアカウントが必要（APIキーではない）
  • ~/.claude/keybindings.jsonでプッシュ・トゥ・トークのキーをmeta+kなどに再バインドし、hold-detectionのウォームアップをスキップ可能

24. 同じ問題を2回修正しても解決しなければやり直す

  • 修正のラビットホールにはまり、問題がまだ解決しない場合、コンテキストが失敗したアプローチでいっぱいになり、次の試行に悪影響を与える
  • /clearしたうえで、学んだことを反映したより良い開始プロンプトで再スタートする
  • クリーンなセッションでの鋭いプロンプトは、行き止まりが蓄積した長いセッションにほぼ常に勝る

25. Claudeにどのファイルを見るべきか正確に指定する

  • @src/auth/middleware.ts has the session handlingのように**@プレフィックス**でファイルを直接参照
  • @プレフィックスはファイルパスとして自動解釈され、Claudeが正確な場所をすぐ把握できる
  • Claude自身でもgrep/検索はできるが、候補を絞り込み、正しいファイルを特定する過程でトークンとコンテキストを消費する — 最初からファイルを指定すればその全工程を省ける

26. 曖昧なプロンプトで不慣れなコードを探索する

  • 「このファイルで何を改善する?」は優れた探索用プロンプト — すべてのプロンプトが具体的である必要はない
  • 既存コードに新しい視点が必要なとき、曖昧な質問はClaudeに予想外の発見をする余地を与える
  • 慣れていないリポジトリのオンボーディング時に活用 — Claudeが、最初の読解では見落としがちなパターン、不整合、改善機会まで指摘してくれる

27. Ctrl+Gで計画を編集

  • Claudeが計画を提示したら、Ctrl+Gでテキストエディタに直接開いて編集できる
  • Claudeがコードを1行も書く前に、制約条件の追加、手順の削除、アプローチの変更が可能
  • 計画がだいたい正しいが、いくつかの手順だけ修正したいとき、全体を説明し直す必要がない

28. /init実行後は結果を半分に削る

  • CLAUDE.mdはプロジェクトルートにあるMarkdownファイルで、Claudeにビルドコマンド、コーディング標準、アーキテクチャ上の決定、リポジトリ慣例などの恒久的な指示を与える
  • Claudeは各セッション開始時にこれを読む
  • /initでプロジェクト構造に基づくドラフト版を生成 — ビルドコマンド、テストスクリプト、ディレクトリ構成を自動認識
  • 出力は肥大化しがち — 存在理由を説明できない行は削除し、不足しているものを追加する

29. CLAUDE.mdの全行に対するリトマス試験

  • CLAUDE.mdの各行について「この行がなければClaudeはミスするか?」と問う
  • Claudeがすでに正しくできている指示はノイズ — 不要な行が重要な行を薄める
  • 遵守率が落ちる前の上限はおよそ150〜200個の指示で、システムプロンプトがすでに約50個を使っている

30. Claudeがミスしたら「CLAUDE.mdを更新してこのミスが再発しないようにして」

  • Claudeがミスしたら、"update the CLAUDE.md file so this doesn't happen again"と指示する
  • Claudeが自分用のルールを書き、次のセッションから自動的に従う
  • 時間が経つとCLAUDE.mdは実際のミスによって形作られる生きた文書へと育つ
  • 無限に肥大化するのを防ぐため、@imports（tip #32）で別ファイル（@docs/solutions.mdなど）を参照 — CLAUDE.mdは軽量に保ち、Claudeが必要時に詳細を読む

31. .claude/rules/で条件付きルールを適用

  • .claude/rules/ に Markdown ファイルを配置して、トピック別の指示を整理 — すべてのルールファイルはデフォルトでセッション開始時に読み込まれる
  • paths frontmatter により、特定のファイルパターンでのみ読み込むよう条件付きで有効化できる:
    • 例: paths: ["**/*.ts"] に設定すると、Claude が .ts ファイルを読むときだけ TypeScript のルールを読み込む
  • メインの CLAUDE.md は軽く保つ — Claude は現在作業していない言語のルールを読まない

32. @imports で CLAUDE.md を軽量に保つ

  • @docs/git-instructions.md のようにドキュメントを参照 — @README.md、@package.json、@~/.claude/my-project-instructions.md も指定可能
  • Claude は 必要なときだけファイルを読む — 毎セッション読み込まれる CLAUDE.md を肥大化させず、「必要なら追加コンテキスト」を与える役割

33. /permissions で安全なコマンドの許可リストを設定

  • npm run lint への承認を何百回もクリックするのはやめる — /permissions で 信頼できるコマンドを許可リストに登録
  • リストにないコマンドには引き続きプロンプトが表示される

34. /sandbox で Claude に自由な作業を許可

  • /sandbox で OS レベルの隔離 を有効化 — 書き込みはプロジェクトディレクトリに制限され、ネットワーク要求は承認済みドメインのみに許可
  • macOS では Seatbelt、Linux では bubblewrap を使用し、Claude が生成するすべてのサブプロセスに制限を適用
  • auto-allow モードでは、サンドボックス内のコマンドは 権限プロンプトなしで実行 — ガードレール付きのほぼ完全な自律性
  • 無監督作業（オーバーナイトのマイグレーション、実験的リファクタリング）には、Docker コンテナ 内で Claude を実行すると完全な隔離と簡単なロールバックを提供できる

35. 反復作業用のカスタムサブエージェントを作成

  • tip #19 の即席サブエージェントとは異なり、カスタムサブエージェントは .claude/agents/ に 事前設定して保存
    • 例: Opus + 読み取り専用ツールの セキュリティレビュアー エージェント、Haiku の高速検索エージェント
  • /agents で参照・作成
  • isolation: worktree で独立したファイルシステムを持つエージェントを設定可能

36. スタックに合った MCP サーバーを選ぶ

  • 始めやすい MCP サーバー: Playwright（ブラウザテストと UI 検証）、PostgreSQL/MySQL（スキーマを直接クエリ）、Slack（バグレポートとスレッドのコンテキスト）、Figma（デザイン→コードのワークフロー）
  • Claude Code は 動的ツールローディング をサポート — Claude は必要なときだけサーバー定義を読み込む

37. 出力スタイルを設定

  • /config で好みのスタイルを選択 — 組み込みオプション: Explanatory（詳細、ステップごと）、Concise（簡潔、アクション重視）、Technical（高精度、専門用語に強い）
  • ~/.claude/output-styles/ に カスタム出力スタイル ファイルを作成することも可能

38. CLAUDE.md は提案、Hooks は要件

  • CLAUDE.md は推奨ベース — Claude はおよそ 80% 順守する
  • Hooks は決定的 — 100% 実行される
  • 例外なく毎回必ず実行すべきもの（フォーマット、lint、セキュリティチェック）は Hook に設定
  • Claude に考慮してほしいガイドラインであれば CLAUDE.md で十分

39. PostToolUse Hook で自動フォーマット

  • Claude がファイルを編集するたびに フォーマッターを自動実行 するよう、PostToolUse Hook を .claude/settings.json に追加
    • Edit|Write マッチャーに npx prettier --write "$CLAUDE_FILE_PATH" 2>/dev/null || true を登録
  • || true により、Hook の失敗で Claude がブロックされないよう にする
  • npx eslint --fix を 2 つ目の Hook エントリとしてチェーンすることも可能
  • エディタが同じファイルを開いている場合は format-on-save を無効にするのがよい — エディタ保存が プロンプトキャッシュを無効化する との報告があり、Hook にフォーマットを任せる

40. PreToolUse Hook で破壊的コマンドをブロック

  • rm -rf、drop table、truncate パターンを PreToolUse Hook でブロック — Claude は試すことすらしない
  • Hook は Claude がツールを実行する 前に発火 し、破壊的コマンドを事前に遮断する
  • .claude/settings.json に追加するか、/hooks で対話的に設定するか、Claude に「rm -rf、drop table、truncate コマンドをブロックする PreToolUse Hook を追加して」と指示する

41. Hook でコンパクション時に重要なコンテキストを保持

  • 長いセッションでは、コンテキストのコンパクション時に Claude が 作業中の内容の文脈を失う可能性がある
  • compact マッチャーを持つ Notification Hook は、コンパクションが発動するたびに重要なコンテキストを 自動で再注入 する
  • Claude に「コンパクション後に現在のタスク、変更ファイル、制約条件を思い出させる Notification Hook を設定して」と指示する
  • 再注入の対象として適している項目: 現在のタスク説明、変更ファイル一覧、厳格な制約（「マイグレーションファイルは変更しないで」）
  • 機能実装に深く入り込み、Claude に文脈を失ってほしくない 数時間に及ぶセッションで特に有用

42. 認証、決済、データ変更は必ず手動レビューする

  • 認証フロー、決済ロジック、データ変更、破壊的な DB 操作 — 他のコードがどれだけ良く見えても必ず人間がレビューする
  • 誤った認証スコープ、設定ミスのある決済 Webhook、列をひそかに削除するマイグレーションは、ユーザー、コスト、信頼を失わせる
  • どれほど自動テストを増やしても、こうした問題をすべて捕捉できるとは限らない

43. /branch で現在の流れを失わずに別アプローチを試す

  • /branch（または /fork）で 現在地点から会話のコピーを作成
  • 危険なリファクタリングをブランチ側で試す — 成功したら維持し、失敗しても元の会話は無傷
  • rewind（tip #3）との違い: 両方の経路がそのまま生き続ける

44. 機能仕様が不完全なときは Claude にインタビューさせる

  • 何を作りたいかはわかっているが、Claude がうまく作るための 詳細が足りないとき は、Claude に質問させる
    • 「私は [簡単な説明] を作りたい。AskUserQuestion ツールを使って詳しくインタビューして。技術実装、エッジケース、懸念点、トレードオフについて質問して。ありきたりな質問はしないで。すべてをカバーするまでインタビューしたら、SPEC.md に完全な仕様を書いて」
  • 仕様完成後は、新しいセッションでクリーンなコンテキストと完全な仕様を使って実装 を始める

45. 1 つの Claude が書き、別の Claude がレビューする

  • 1 人目の Claude が機能を実装し、2 人目の Claude が 新しいコンテキストでスタッフエンジニアのようにレビュー する
  • レビュアーは実装時の近道を事前に知らないため、あらゆる部分に疑問を投げかける
  • 同じ発想は TDD にも適用できる: セッション A がテストを書き、セッション B がそれを通すコードを書く

46. PR レビューを対話的に進める

  • ワンショットの PR レビューを依頼するのではなく（もちろんそれも可能だが）、PR をセッションで開いて 対話 を進める
    • 「この PR で最もリスクの高い変更を説明して」
    • 「これが同時実行されたら何が壊れる？」
    • 「エラーハンドリングはコードベースの他の部分と一貫している？」
  • 対話型レビューの方が多くの問題を見つけられる — 重要な領域を 深く掘り下げられるから
  • ワンショットレビューはスタイル上の細かな指摘をしがちで、アーキテクチャ上の問題を見落としやすい

47. セッションに名前と色を付ける

  • /rename auth-refactor で プロンプトバーにラベル を表示
  • /color red または /color blue で プロンプトバーの色 を設定
    • 使用可能な色: red, blue, green, yellow, purple, orange, pink, cyan
  • 2〜3 個の並列セッションを運用するなら、名前と色を付ける 5 秒の投資で 間違ったターミナルに入力するミスを防げる

48. Claudeの完了時にサウンドを再生

  • Stop HookでClaudeの応答完了時にシステムサウンドを再生
  • タスクを開始して別の作業に切り替えたあと、完了時に通知音で知らせる
  • 例: .claude/settings.json にStop Hookとして /usr/bin/afplay /System/Library/Sounds/Glass.aiff を登録

49. claude -p でバッチ処理をファンアウト

  • 非対話モードでファイル一覧をループ処理 — --allowedTools でファイルごとにClaudeが実行できる作業範囲を制限
  • & で 並列実行し、最大スループットを確保:
    • for file in $(cat files-to-migrate.txt); do claude -p "Migrate $file from class components to hooks" --allowedTools "Edit,Bash(git commit *)" & done; wait
  • ファイル形式の変換、コードベース全体のimport更新、各ファイルが独立した反復的マイグレーションに適している

50. スピナー動詞のカスタマイズ（お遊び要素）

  • Claudeが考えている間、ターミナルに "Flibbertigibbeting..."、"Flummoxing..." のような スピナー動詞 を表示
  • 好きな文言に置き換え可能 — Claudeへの指示:
    • "Replace my spinner verbs in user settings with these: Hallucinating responsibly, Pretending to think, Confidently guessing, Blaming the context window"
  • 一覧を自分で用意しなくてもよい — "Replace my spinner verbs with Harry Potter spells" のように 雰囲気だけ伝えれば Claudeが一覧を生成
  • 待ち時間を少し楽しくする小さなカスタマイズ

関連記事

1件のコメント

 
roxie 2026-03-20

1番からとても楽しいですね