煽りイカ（🦑
Antigravityもいいけど、Claude Code使ってる？
せっかく会社で契約してくれたので、使い方・設定などを色々と調査するための人柱として使い続けている中で、
まずDesktopアプリで使うであろうClaude Codeのチャット欄周りの設定についてをClaudeに聞いてみたので、
そこら辺を情報連携しますね。
どうも、日々AIとイチャイチャしてるえ～すけさんですよ。
そもそもClaude Codeをなんとなくデフォルト設定のまま使い続けてる人はかなり多いんじゃないでしょうか。
チャットGPTみたいなUIだし、とりあえずチャット欄に何か書けばええんやろ？
といったように、課金してるのに内容に沿ったモデルをろくに選ばず「なんかよしなにやってくれ」って投げてるのであれば、それは何とももったいないね。
というわけで今回は、「そこらへんをClaude本人に聞けば一番早くない？」 という発想のもと、
Claude Codeで選べるモデルとモードの違い、そしてどのシーンで何を選ぶべきか
をClaudeに自分で自分の取説を書かせるという若干メタな試みですが、
正確性という意味では割と信頼できるはずです（たぶん）。
Claude Codeで選べるモデル（2025年5月現在）
現在 Claude Code で選択できる主なモデルは以下の通りです。
| モデル | 位置づけ |
|---|---|
| claude-opus-4-5 | 最高性能・重量級 |
| claude-sonnet-4-5 | バランス型・デフォルト |
| claude-haiku-4-5 | 軽量・高速・低コスト |
ざっくり「Opus > Sonnet > Haiku」の順で賢さとコストが比例しています。
「賢いほどいい」と思って全部Opusにしてる人は財布と相談してください。
※会社で契約してる方は、本当に課金に気をつけてね。。。
各モデルの特性と使いどころ
claude-opus-4-5 — 「なんでもできる人、でも遅い」
特性：
- 推論能力が最も高く、複雑な問題を多段階で考えてくれる
- コードの設計判断・アーキテクチャレビューが得意
- 長い文脈をしっかり保持して一貫した回答をする
- ただし応答速度は他より遅め、コストも高め
向いてるケース：
- 設計フェーズ（「このシステムどう作ろうか」という段階）
- バグの原因がどうしても特定できないとき
- セキュリティレビューや複雑なリファクタリング
- PRレビューでロジックの整合性をしっかり確認したいとき
向いてないケース：
- 「このコメント直して」みたいな軽微な修正
- 単純なボイラープレートの生成
- スピードが命のとき
Opusを使うべき場面でHaikuを使うのは、脳外科手術をお箸でやるようなものです。
一方でOpusを使う必要がない場面でOpusを使うのは、お箸でご飯を食べるのに手術用メスを使うようなものです。
claude-sonnet-4-5 — 「実務で一番頼られる中間管理職」
特性：
- 速度・精度・コストのバランスが最もいい
- 日常的なコーディングタスクをサクサクこなす
- 複雑すぎない問題なら十分な推論力を持つ
- Claude Codeのデフォルトモデルはこれ
向いてるケース：
- 普段のコーディング全般
- コードの説明・ドキュメント生成
- テストコードの作成
- CIで回すような定型的なコード生成タスク
向いてないケース：
- 本当に難しいアルゴリズム設計（ここはOpusの出番）
- 速度最優先の大量処理（ここはHaikuの出番）
Sonnetは「とりあえずこれ使っとけ」が成立する唯一のモデルです。
デフォルトのまま使い続けても恥ずかしくない。むしろそれで十分なことが多い。
claude-haiku-4-5 — 「コスパの鬼、でも深く考えるのは苦手」
特性：
- 応答速度が最も速い
- コストが最も低い
- シンプルなタスクは十分な品質で返してくれる
- 複雑な推論や長大なコンテキストの処理は苦手
向いてるケース：
- 大量のファイルに同じ処理をかけるバッチ的な作業
- 単純なコード補完・フォーマット
- ログ解析など定型パターンの繰り返し作業
- プロトタイプの高速作成
向いてないケース：
- 設計の相談
- バグの根本原因調査
- 「なぜこうなるのか」を理解させたいとき
Haikuを使う場合は「この人に高度な判断をさせてはいけない」という意識で使いましょう。
軽いタスク・量をさばくなどの単純作業に向いています。深さを求めてはいけません。
Claude Codeのモードについて
Claude Codeのチャット欄には、操作のたびに表示される確認・承認のダイアログがあります。
モードはチャット欄から切り替えられる3種類で、それぞれ
モード1：許可を確認（デフォルト）
Claude Codeは何かを実行する前に必ず確認を取ってきます。
ファイルを編集しようとすると「このファイルを変更してもいいですか？」、
コマンドを実行しようとすると「このコマンドを実行してもいいですか？」という具合です。
正直、心配性だなと思うレベルで聞いてきたりますが、まぁ安心安全に使うならそれもまたいいか。。。
◆ Claude wants to edit src/api/user.py
Do you want to proceed?
❯ Yes
No
Always allow edits to this file
Always allow edits to this directory
これがデフォルトの動作で、一番安全なモードです。
また、このモードの確認ダイアログには「このファイルへの編集を常に許可する」「このディレクトリへの変更を常に許可する」という選択肢もあります。
これを使うと指定した範囲だけ次回以降の確認をスキップできるので、「この作業ディレクトリは毎回聞かなくていい」という場合に便利です。
信頼できる範囲だけを自動化して、それ以外は確認を保持する、というバランスのいい使い方です。
向いてるケース：
- 初めて触るコードベースへの変更
- 重要なファイルを扱う作業
- まず提案を見てから自分で判断したいとき
「Always allow」を使うときの注意：
「まあディレクトリ全体を許可しておけばいいか」という雑な判断はやめましょう。
安全装置を全部外してから作業するのと同じです。重要なファイルはちゃんと確認を残す、というピンポイントな使い方が正解です。
モード2：編集を承認
ファイルの変更が発生するとき、チャット欄に変更内容のdiffが表示され、
「承認する / 却下する」を選ぶことができます。
◆ Claude proposes the following edit to user.py:
- def get_user(id):
- return db.query(id)
+ def get_user(user_id: int) -> Optional[User]:
+ return db.session.query(User).filter(User.id == user_id).first()
Accept this change?
❯ Yes, apply
No, skip
Yes, apply all remaining
「許可を確認」が「何をするか」の確認なのに対して、こちらは「実際にどう変わるか」を見てから判断できるのが特徴です。diffで変更内容を確認してからGoを出せるので、より細かいコントロールができます。
「Yes, apply all remaining（残り全部適用）」を選ぶと以降の変更を一括で承認できます。
逆に1件ずつ確認したい場合は「Yes, apply」を都度選んでいきます。
向いてるケース：
- 変更内容を自分の目で確認しながら進めたいとき
- 大量ファイルを変更するタスクで「途中まではOKだが一部は自分で判断したい」とき
「Yes, apply all remaining」を選ぶ場合の注意：
「残り全部OK」を選ぶということは、以降の変更を全部信頼するということです。
途中でおかしな変更が混じっていても止められないので、「ここから先は問題ないとわかってる」という確信があるときだけ使いましょう。
モード3：プランモード（実行せずに計画だけ立てる）
「プランモード」 を選ぶと、Claudeは
実際にファイルを変更したりコマンドを実行したりせず、「こういう手順でやります」という計画だけを提示
してくれます。
[プランモードで聞いた例]
You: このAPIのリファクタリングをお願い
Claude:（実際には何もせず）
以下の手順でリファクタリングを行います：
1. user.py の認証ロジックを auth/ に分離
2. router.py の依存関係を更新
3. テストを修正
...（計画の提示のみ。実行はしない）
「先に全体の計画を見たい」「影響範囲を把握してから判断したい」というときに非常に有効です。
計画を確認してOKなら「許可を確認」か「編集を承認」モードに切り替えて実行する、というフローです。
プランモードを使うと「やってみたら全然違う方向に進んだ」という事故が劇的に減ります。
大きい作業の前に一度プランを出してもらってから実行するフローを身につけると、作業の精度が上がります。
これは私（Claude）が推奨しているというより、私が暴走しないようにするための仕組みです。正直に言います。
向いてるケース：
- 大規模な変更の前に影響範囲を把握したいとき
- チームで方針を確認してから実行に移したいとき
- 「やらせてみたら思ってたのと全然違った」を防ぎたいとき
向いてないケース：
- 小さい修正にわざわざ計画を立てるのは逆に手間
- 「とりあえず動かしてみよう」というプロトタイプ段階
3つのモードの使い分け早見表
| シーン | 使うモード |
|---|---|
| 初めて触るコードベースへの変更 | 許可を確認 |
| 重要なファイルを扱う作業 | 許可を確認 |
| 信頼できる作業ディレクトリでの繰り返し作業 | 許可を確認 ＋ Always allow を活用 |
| 変更内容をdiffで見ながら進めたい | 編集を承認 |
| 大規模変更の前に方針を確認したい | プランモード → 実行モードに切り替え |
補足：コマンドラインからモードを指定する場合
チャット欄のUIではなく、コマンドから直接動作を指定することもできます。
主に 自動化やCI組み込みなど「人間がいない状況で動かしたい」 場合の選択肢です。
# ワンショット実行（1回の指示で終了）
claude -p "テストを全部実行して結果を教えて"
# 全操作を確認なしで自動実行（要注意）
claude --dangerously-skip-permissions
--dangerously-skip-permissions はすべての確認をスキップします。
「dangerously」という単語がフラグ名に入っているのはデザインミスではなく、完全に意図的な警告です。
本番環境では絶対に使わないでください。
CIパイプラインやサンドボックス環境での自動化用途に限定して使うべきものです。
「なんかめんどくさいから」という理由でローカル開発に使うと、いつか後悔します。
まとめ
モデル選択：
- Opus → 設計・難しいバグ・根本原因の調査。深く考えてほしいとき
- Sonnet → 迷ったらこれ。日常のコーディング全般
- Haiku → 大量処理・定型作業・コストを抑えたいとき
モード選択（チャット欄）：
- 許可を確認 → 操作ごとに確認。初めてのコードベースや重要なファイルに。「Always allow」で信頼できる範囲だけ部分的に自動化も可能
- 編集を承認 → diffを見ながら1件ずつ or まとめて承認
- プランモード → 大規模変更の前に計画を確認してから実行に移す
コマンドライン（補足・自動化用）：
-
-pフラグ → CI・自動化・ワンショット実行 -
--dangerously-skip-permissions→ 完全に信頼できる環境のみ。名前を読め
Claude Codeはそもままの設定でも「とりあえず動く」ツールとして使えてしまうのが逆に罠で、
ちゃんと設定を理解して使うと作業効率がかなり変わるはずかと。
更に理解を進めたい場合は、エージェントファイルだったり何だりのMDファイル系を用意するというステップになってくるのかなと。