最近私が Claude Code をどう使っているかまとめました。

以前 [2026-01-16-1] で Claude Code の書籍を紹介しましたが、今回は自分のワークフローについて書きます。

作業環境

MacBook の内蔵ディスプレイで作業しています。私は外部ディスプレイをあまり使わない人です。

macOS 標準の ターミナル.app を画面全体に表示し、tmux を使っています。tmux はウィンドウを分割せずに使い、タブ（ウィンドウ）の切り替えで作業しています。Ghostty や iTerm2 にはまだ（？）乗り換えていません。

エディタは Emacs です。Claude Code 登場前は、何度か VSCode への乗り換えを試して諦めて…を繰り返していましたが、今は考えなくて良くなりました。助かります。

今さらながら Emacs の global-auto-revert-mode が便利です。Emacs で開いているファイルを Claude Code が編集したとき、Emacs のバッファが自動的に更新されます。こんな設定 です。

Claude Code のモデルはプライベートでも会社でも Opus 4.6 (1M context) を使っています。Sonnet は基本的に使いません。プライベートの Claude のプランは Pro にしたり Max にしたりしていて、Max の時は 1M context 付きになります。

ワークフロー

GitHub Issue を起点とした 3 ステップのワークフローで作業しています。

1. 作業計画の作成

起点は /create-plan-for-gh-issue という自作の skill（スラッシュコマンド）です。

GitHub Issue の内容から作業計画を Markdown ファイルとして作成します。Issue は PR 作成でも調査でも、なんでも構いません。

ポイントは Issue に必要な情報を書いておくことです。Description でもコメントでも良くて、内容が雑多でも大丈夫です。添付画像も読み込んでくれます。

作らせたあとに何回かやり取りして、より良い計画にしていきます。

2. 作業計画のレビュー

作成した計画を別セッションの Claude Code にレビューさせます。不安なときは Codex にもレビューさせます。

Codex を直接使うことはあまりなくて、/codex-discuss という自作の skill 経由で使っています。

💡 /codex-discuss は引数に何か渡せばいい感じに議論してくれますし、引数に何も渡さなくても勝手に議論対象を考えてくれます。何を議論したらよいか分からない時は、ユーザーに聞いてきます。第三者視点を得られる気がするので重宝していますが、欠点は遅いことですね…。

計画書は Markdown ファイルなのでレビューがやりやすく、週を跨いだ作業でも問題ありません。

計画がまとまったら、記録のために GitHub Issue のコメントとして貼り付けています。以前はリポジトリの docs/plans/ にコミットしていましたが、削除したファイル名などが grep にヒットしノイズになるのと、ちょっと違うなと思って止めました。

3. 作業の実施とレビュー

計画はたいてい Phase に分割されており、各 Phase ごとにコミットする想定になっています。

git 操作は今のところ人間がやっています。コミットメッセージの提案には /suggest-commit-message という自作の skill が重宝しています。

PR をレビュー依頼する前に、別セッションの Claude Code で /review してレビューし、不安だったら /codex-discuss で議論します。

openai/codex-plugin-cc も試しましたが、あまり合いませんでした。

また、Dependabot からの PR レビューには /review-dependabot-pr が重宝しています。

まとめ

2026/04 時点の Claude Code の使い方をまとめました。

Claude Code をカスタマイズしすぎないようにしています。Twitter を見ているとみんな高度なことをやっているように見えますが、あまり影響を受けすぎず、自分の直感を信じて使っています。

いくつか紹介した Claude Code の設定などは、以下の dotfiles-public リポジトリにまとまっています。

今後もブラッシュアップしていくのと、評判の良い Codex.app も使ってみようと思います。

落穂拾い

Claude Code からの Yes/No の質問には y/n で十分

Claude Code からの Yes/No の質問は y や n で十分です。地味ですがトークン削減になります。

Claude Code からのインタビュー形式のヒアリング

作業内容がぼんやりしているときは、Claude Code から「インタビュー形式で」ヒアリングしてもらうと整理しやすいです。

情報ソースが足りない時に、Claude Code が自律的に質問してきます。

~/.claude/CLAUDE.md に「ユーザーに選択・判断を求める場合は AskUserQuestion ツールを使うこと」の一文を入れています。

Claude Code のセッションは短く保つ

Claude Code のセッションはコンテキストウィンドウに余裕があっても、あまり延命しないようにしています。途中経過のノイズが紛れ込んで、ちょっと変になる体感があるためです。

ちなみに現在のコンテキストウィンドウ (cw) は、Claude Code のステータスラインで把握しています。

Claude Code のステータスライン

上記ステータスラインの設定はこちら:

Claude Code からの通知設定

Claude Code の処理完了を見逃さないよう、以下のような tmux のステータスラインと macOS の通知センターに通知を送る設定をしています。

tmux のステータスライン

macOS の通知センター

前職の同僚の吉田さんの記事が参考になりました。

吉田さんの記事では、スピナー表示や未読マーカーの仕組みが詳しく解説されています。私の設定は、それをベースに以下の調整を加えたものです。

  • 共通:
    • Notification フックを追加し、ツール許可待ちなどのアイドル状態でもtmux の未読マークや通知音で気付けるようにした
  • tmux:
    • SessionEnd フックでスピナーを後片付けし、/exit や C-c C-c で終了した時にスピナーが回り続ける問題を解消した
    • heartbeat ファイルを導入し、mtime を TTL として監視することで、Esc 中断時にもスピナーが自動停止するようにした
    • 未読を表す●の色を赤からシアンに変更。シアンのほうが未読のように見えるため
  • macOS 通知センター:
    • Notification（Funk 音）と Stop（Glass 音）でサウンドを変え、「気付いてほしい」と「完了」を耳で区別できるようにした
    • 通知本文に (tmux:N) でウィンドウ番号を付与し、どのウィンドウに戻ればいいか分かるようにした

実際のコードはこちらです。