結論（忙しい方向け）
- デフォルトeffortがhigh化：設計や調査で質は上がるが応答遅延とトークン増に注意
- ignore-memoryはMEMORY.mdを完全無視しないのでメモリを短く明確に整備
- タスク別にeffortを切替え、設定とログの定期棚卸をルール化して検証を習慣化
想定読者: エンジニア
関連記事（先に押さえたい人向け）: Claude Code最新アップデートを仕事に活かす（Bedrock/Remote Controlなど） / Claude Code 2.1.92アップデート解説（Bedrock連携など）
「またAIコーディングCLIのアップデート？ もう追えないんだけど…」
そう思いつつも、なんとなくアップデートして「まあ賢くなったならいいか」と流している人、多いと思います。
でも今回の Claude Code 2.1.94（参考：@ClaudeCodeLog のポスト）は、
UIや新機能が派手に増えたタイプではなく、「デフォルトの考え方」と「メモリの扱い」がじわっと変わるアップデートです。
この記事では、最新アップデートをネタにしながら、
- どの変更が「自分の現場」に効いてくるのか
- どこを見直すと「無駄な待ち時間」と「無駄なトークン消費」が減るのか
- Claude Code・Codex系CLI・軽量モデルをどう役割分担するか
を、日本の開発現場目線でまとめます。
この記事を読むと、次のことが分かります。
- effort（思考深度）デフォルト変更のメリットと副作用
- MEMORY.mdの“ちょうどいい”書き方と運用のコツ
- Claude Code・Codex CLI・軽量モデルの実務的な使い分け方
- 今日からできる設定・ルール・A/Bテストの具体例
- 開発体験を悪化させがちな「ありがち失敗」とその回避策
「アップデートを知る」で終わらせず、
「設定を1つ変える」「ルールを1枚作る」くらいまで一緒に進めるのがゴールです。
- 結論から言うと：今回の変化は“派手さ控えめ、でも生産性にはじわじわ効く”タイプ
- 見逃すと損する重要変更3点：実務に効くのは“深く考える設定”“記憶の扱い”“出力の癖”
- Xで盛り上がっている本当の論点：『品質は上がる』でも『毎日の開発がラクになる』とは限らない
- 比較で整理：Claude Code・Codex系CLI・軽量代替モデル、2026年春に選ぶならどれ？
- 今日から変えられる実践策7つ：Claude Code時代の“賢い付き合い方”
- すぐ使える具体例：MEMORY.md・依頼テンプレ・振り分けルールの実用サンプル
- ハマりがちな失敗4選：便利になったはずなのに、なぜか開発体験が悪化する理由
- FAQ：Claude Code運用でよくある疑問を5分で整理
- まとめ：今週やるべきことはこの7つ、AIコーディング環境は“放置しない”が正解
- 関連記事
結論から言うと：今回の変化は“派手さ控えめ、でも生産性にはじわじわ効く”タイプ
「え、またClaude Codeアップデート？ もう追えんて……」
そう思った人、僕も同じ側です。
でも、今回の Claude Code 2.1.94 は、
「UIがドーン！機能がドカーン！」系ではなく、設定と挙動がじわっと効いてくる“地味だけど実務に刺さる系アップデート」 なんですよね。
Xで出ている情報を整理すると：
- Xでの主張 / 論点（感想ゾーン）
- デフォルトの「effort（思考の深さ）」が
medium → highになって、- 設計相談や複雑リファクタで“最初から深く考えてくれる”ようになった
- その代わり「待ち時間伸びた？」「トークン消費ヤバくない？」という不安も増えた
-
ignore-memoryオプションを使ってもMEMORY.mdが完全には無視されなくなり、- 「意図せずルールが効くのでは？」という戸惑い
- 「プロジェクトメモリをちゃんと読んでくれてありがたい」という歓迎ムードもある
-
事実として確認できる範囲
- 公式チェンジログアカウントのポストより：
Claude Code 2.1.94 has been released.25 CLI changes, 2 system prompt changes- ハイライト：
Default effort medium→high for API-key, Bedrock/Vertex/Foundry, Team & EnterpriseIgnore-memory no longer treats MEMORY.md as empty
- 少なくとも、
- 一部プラン・接続方法で「デフォルト思考深度」が上がった
ignore-memory時のMEMORY.mdの扱いが変わった- システムプロンプト（内部方針）が2つ更新された
- という3点は確定情報
ここから先は、僕なりの解釈を含めた「実務上の結論」です。
今回の変更がもたらすもの
結論：今回の変更は、爆速で世界が変わるタイプじゃないけど、
放置すると “ムダな待ち時間” と “ムダなトークン” と “よく分からない挙動” がじわじわ効いてくるタイプ です。
もう少し噛み砕くと：
- 重いタスク（設計・リファクタ・障害調査）をClaude Codeに任せている人
- デフォルト
highによって、- 「最初から一段深い考察」が出やすくなる
plan mode + high effortコンボはかなり強くなりそう
-
ただし当然、
- レスポンス時間アップ
- トークン消費増加 → 課金・レートリミットへの影響
は避けづらいので、“全部highでいいのか問題” が現場で顔を出すはずです。
-
MEMORY.md / CLAUDE.md をちゃんと育てている人
ignore-memoryしてもMEMORY.mdを完全スルーしない挙動に変わったことで、- 「プロジェクトルールを握りつぶして動く事故」は減る
- 一方「完全に素の状態で試したい」ときは、挙動理解が必須
- 要するに、メモリ設計が雑なプロジェクトほど、後から謎挙動に悩まされるリスクが増えた ということです。
ポジティブに言い換えると、
これまで「なんか浅い回答だな」「メモリ効いてるのかよく分からん」というモヤモヤに対して、
ツール側が “深く考える”“メモリをちゃんと見る” 方向にハンドルを切り始めた
とも言えます。
僕らエンジニアがやるべきこと（ざっくり3つ）
- タスクごとに「deepで考えてほしいか」を決める
- 設計相談・大規模リファクタ・原因不明バグ →
high歓迎 - コピペ修正・ログ追加・文言変更 →
medium相当で十分 -
→ 「全部おまかせhigh」から、「タスク別に深さを切り替える」運用へ。
-
MEMORY.md / CLAUDE.md を“短く・判定可能”なルールに絞る
- ビジョン・背景・ポエムはREADMEなど別ファイルへ
- Claudeに守ってほしいのは：
- コーディング規約
- テスト方針
- 禁止事項（
NEVER: ...） - PRルール
-
このくらいに整理すると挙動が読みやすくなります。
-
「最近遅い／高い／挙動が変」と感じたら、一度設定とログを見直す
- デフォルトが勝手に変わった結果、
- 実は
effort=highを乱発していたり - 想定外のメモリを読んでいたり
- 実は
- というケースもありえるので、AIまわりは“週1棚卸し”するインフラと割り切るのが安全です。
この記事全体では、
- 「深く考えすぎ問題」と「メモリ挙動問題」の整理
- 事実ベースで追える変更点と、その実務インパクト
- 僕らエンジニアが 今日から変えられる設定・運用のチェックポイント
まで一気にまとめていきます。
見逃すと損する重要変更3点：実務に効くのは“深く考える設定”“記憶の扱い”“出力の癖”
まずは、2.1.94 アップデートの中で、現場に効く3点だけをピックアップします。
主参照ポスト：@ClaudeCodeLog
デフォルト effort が medium → high：メリットと3つの副作用
事実
- 公式ポスト：
Default effort medium→high for API-key, Bedrock/Vertex/Foundry, Team & Enterprise- 対象：
- APIキー直叩き
- Bedrock / Vertex / Foundry 経由
- Claude Team / Enterprise
effortはAnthropic系の「どれくらい深く考えるか」フラグです。
high にすると、前提整理・代替案・トレードオフまで踏み込んだ回答になりやすい一方で、当然負荷も上がります。
メリット
- 設計レビュー・リファクタ・アーキ相談で：
- 一発目から前提整理＋選択肢＋トレードオフまで出やすい
- 複数ファイルまたぎのバグ調査や大きめリファクタのplanモードと好相性
副作用（ここが実務では効く）
- レスポンス時間アップ
- トークン消費増（説明・計画が厚くなる）
- 軽作業へのオーバースペック（1行修正にも“フルコース説明”がつきがち）
実務でやること
- タスクの“重さ”でeffortを切り替えるルールを書く
## Effortの使い分け方針
- 大規模リファクタ / 設計相談 / 根本原因調査：
- 深く考えてよい（high前提）
- 単一ファイルの軽微修正 / 文言変更 / ログ追加：
- 設計変更は行わず、最小の変更だけを行う（medium相当）
- 「最近遅い／高い」と感じたら、まずeffort変更を疑う
ignore-memory が MEMORY.md を“空扱いしない”：メモリ運用の見直し必須
事実
- 公式ポスト：
Ignore-memory no longer treats MEMORY.md as empty- 以前：
ignore-memoryでMEMORY.mdを「存在しないもの」として扱っていた- 現在：
MEMORY.mdエントリが完全には無効化されない方向へ変更
「以前ほど雑に“全部切れるスイッチ”ではない」という理解でいたほうが安全です。
ポジティブな影響
- プロジェクトの重要ルール（型・フレームワーク・テスト方針など）が
ignore-memory一発で無視される事故が減る - チーム開発で、CLAUDE.md / MEMORY.md の安全系ルールを前提にしやすくなる
注意点
- 「完全に素のClaudeで試したい」ときに、昔のノリで
ignore-memoryを使うと混乱しやすい - ベンチマークや比較検証では、「メモリ有り/無し」の条件が変わるので注意
実務でやること
- MEMORY.md / CLAUDE.md を“ルールファイル”として見直す
- 残す：
- コーディング規約
- テスト戦略（TDDかどうか）
- 禁止事項（
NEVER:） - PRルール
-
退避：
- 背景・歴史・文化的な話（
docs/へ）
- 背景・歴史・文化的な話（
-
「完全メモリ無しで試したいとき」の手順を別で決める
- 検証用ディレクトリを作る
- そもそもブラウザ版のClaudeや別ツールで検証する、など
システムプロンプト（内部“人格”）が2つ変更：ノリが変わる
事実
- 公式ポスト：
25 CLI changes, 2 system prompt changes- システムプロンプトとは：
- ユーザーから見えない、Claude Codeの基本方針・人格を決める指示
内容は非公開ですが、変わると：
- ツールの使い方の慎重さ
- 説明の粒度
- 失敗時のリカバリの仕方
などが体感レベルで変わることがあります。
現場で起きがちな違和感
- 「前より編集が慎重になった？」
- 「説明が長く（短く）なった気がする」
- 「planモードのフォーマットが微妙に違う？」
実務でやること
- ノリが変わった気がしたら、自分側の設定を先に確認する
CLAUDE.md/MEMORY.md/.claude/commands/**.md/permissionsの許可設定-
effortの指定有無 -
依頼テンプレで出力フォーマットを明示する
以下の形式で回答してください： 1. 概要（2〜3行） 2. 変更ファイル一覧 3. 実施内容の詳細 4. テスト観点と結果
- CIやbotで使う場合は“揺れ”前提の設計にする
- テキスト完全一致ではなくJSON/YAML出力をパースする
- 重要フィールドだけを評価する
Xで盛り上がっている本当の論点：『品質は上がる』でも『毎日の開発がラクになる』とは限らない
2.1.94 の話題、Xではだいたいこんな感じで盛り上がっています。
主参照ポスト：@ClaudeCodeLog
- 「effort=high デフォルトは神」派
- 設計レビューやリファクタで「プランの質が上がった」「トレードオフまで出してくる」と高評価
- 「いや、普段使いには重い」派
- 軽微修正でも毎回ガッツリ考えに行くのでレスポンスが重い
- Pro/Max勢でもレートが怖いという声
- メモリ周りへのモヤモヤ
- 「
ignore-memoryしても MEMORY.md 完全無視じゃないって、検証どうするの？」 - 全体を眺めてる人たちの視点
- 「Claude Code＝高級フルコース」「軽量CLI＝回転の速い定食屋」という比喩
- 「ツールのIQが上がるほど、使い分けを人間が考えないと損する」という冷静なコメント
ここから、実務に直結する4つの論点を整理します。
論点① 深く考えるのは歓迎、でも日常タスクまで重くなるのはしんどい
高評価な場面
- 新機能の設計
- テーブル / API設計のリファクタ
- 依存関係が複雑なバグ調査
こういうときは effort=high の恩恵がド直球で効きます。
でも、開発者の1日は軽作業のほうが多い
- ログ1行追加
- 文言ちょっと修正
- バリデーション1ケース追加
- 決まっている設計に沿ったエンドポイント追加
ここまで全部highでやると、
「ツールの品質は上がったのに、日々の開発体験は軽くならない（むしろ重い）」
という現象になります。
対処の方向性
- 人間側で問題のスコープを絞る
- 「この関数だけ」「このif文だけ」「設計方針は変えない」と明示
- タスク種類ごとにeffortの推奨を決めておく
- 設計・大規模リファクタ → high
- 既存設計に乗る小変更 → medium相当
- 単純置換・フォーマット → そもそもAI不要（エディタマクロでOK）
論点② Claude系は“高級フルコース”、軽量CLIは“回転の速い定食屋”
ざっくり比喩でいうと：
- Claude Code = 高級フルコース
- ネタ（モデル）が強く、職人（システムプロンプト）がちゃんと握る
- コースで任せると前菜〜デザートまできれいに出す
-
その分、時間もお金もかかる
-
Codex CLI / 軽量モデル = 回転の速い定食屋
- 種類多く回転が早い
- 「この皿を3枚」的な量産に向く
- 細かいニュアンスや大規模リファクタの一発プランは、やや苦手なことも
ここでのポイントは、
「どっちが最強か」ではなく、
「今やっているタスクはどっち向きか」を決める時代
だということです。
論点③ モデルやCLIの寿命が短い時代、“固定前提”の運用が一番危ない
- OpenAIは古いCodexモデルのリタイアを告知
- OSSもGLM-5.1のような新顔が次々登場
- Claude側もデフォルト思考深度・メモリ挙動・システムプロンプトを短いスパンで更新
この状況で、
「このCLI・このモデル前提でフローをガチガチに固定する」と、
去年の最適解が、今年の技術的負債に変わりうる
という現象が起きます。
対処案
- フローを“原理”で書く
- 悪い例：
- 「GPT-5.1-codex-max を使ってレビューすること」
-
良い例：
- 「複数ファイルまたぎのレビューは“深い推論が得意なモデル”に渡す。モデル名は
ai-tools.mdで別管理」
- 「複数ファイルまたぎのレビューは“深い推論が得意なモデル”に渡す。モデル名は
-
ツール依存部分は薄いレイヤーに隔離
-
ai-tools/claude/ai-tools/codex/ai-tools/local-llm/などに分離 -
A/Bテスト前提で運用する
- 「このタスクは本当にClaude Codeが最適か？」
- 「軽量モデルで8割勝てないか？」
論点④ 日本の現場では“性能”だけでなく“通しやすさ”が勝負を決める
海外の議論は、
- ベンチマークスコア
- レイテンシ
- ローカル完全対応かクラウドか
など“性能・アーキ・コスト寄り”が多いですが、日本の現場だとまずこうなります。
- 「社内で契約できるか」
- 「データはどのリージョンに行くか」
- 「監査ログは残るか」
- 「法務・コンプラ・情シスがOKするか」
ここを無視してツール選定すると、
技術的には良くても、稟議の壁で半年寝かされる
というオチになりがちです。
現場エンジニアがやると良いこと
- 候補ツールごとに、最低限この4項目だけ表にしておく：
- 契約形態
- データ保持・ログポリシー
- リージョン
- 権限・監査
- Claude Codeを使うなら：
- 単体契約か、AWS Bedrock / Vertex / Foundry経由かを早めに情シスと握る
- 複数CLIを併用するなら：
- 「ここは個人Pro」「ここはチーム契約」と線引きする
比較で整理：Claude Code・Codex系CLI・軽量代替モデル、2026年春に選ぶならどれ？
「Claude Code強いのは分かった。でも結局どれ使えばいいの？」
という人向けに、2026年春時点の3レーンで整理します。
- レーンA：Claude Code（Claude系CLI）
- レーンB：Codex CLI（OpenAI系CLI）
- レーンC：軽量代替モデル＋CLI（GLM-5.1など）
主参照アップデート：
Claude Code 2.1.94 – effortデフォルト変更など
ざっくりスペックと得意分野
A. Claude Code
2.1.94で：- effortデフォルト：
medium → high（一部環境） ignore-memory挙動変更- 25 CLI変更＋2システムプロンプト更新
- 強み：
- 大規模コードベースの理解
- CLAUDE.md / MEMORY.md による長期メモリ運用
- planモード＋TDDワークフロー
B. Codex CLI（OpenAI系）
- ChatGPT Plus / Pro / Team に同梱
- GPT-5系モデル利用可
- ローカルファースト設計（ソースを外に出さないモードもあり）
C. 軽量代替モデル（GLM-5.1など）
- OSSとして公開
- SWE-Bench Pro等でOSS勢トップクラスのスコア
- OpenRouter / Vercel / Requestyなどから利用可能
用途別に“勝ち筋”はこう変わる
1. 設計・アーキテクチャ相談
- 例：
- モノリスの分割方針
- 認証基盤の設計
- API＆DBスキーマの再設計
→ ほぼClaude Code一択 or 最優先候補
- effort=highデフォルトで前提整理〜トレードオフまで出しやすい
- CLAUDE.md に「思想・前提技術」を書いておけばブレを抑えられる
2. 実装＋リファクタ（中〜大規模）
- 例：
- サービス層3〜4ファイルの整理
- 決済周りのフローリファクタ
- GraphQLスキーマ全体の整理
→ 方針決定はClaude Codeが強いが、コスト・レートが重くなりがち。
- 現実案：
- 設計・方針決め → Claude Code
- その方針に沿った量産作業 → Codex CLI / 軽量モデル
3. バグ調査・原因究明
- 例：
- たまに出る500エラーの正体
- メモリリークっぽい挙動
- 複雑な状態マシンの不具合
→ 探索フェーズはClaude Code向き
- 長いログ・複数ファイルの「文脈」理解が得意
- ただし、単純なログ要約や可視化だけなら軽量モデルのほうが安くて速い
4. 軽微修正・定型タスク・量産系
- 例：
- ログメッセージの統一
- バリデーションルール量産
- 翻訳JSONの追加
- 型1フィールド追加
→ ここにClaude Codeフルパワーはほぼ過剰
- Claude Codeのeffort=highデフォルトと相性が悪いゾーン
- 素直に：
- Codex CLI
- GLM-5.1など軽量モデル
- Cursor / VSCode拡張のインライン補完
でさばくのが現実的です。
春版「どう選ぶか」実務ルール
- Claude Codeを“全部乗せメインフレーム”にしない
- 設計・大規模リファクタ・原因不明バグ調査に集中投入する
- 日常の軽作業はCodex CLI＋軽量モデルに逃がす
- チームで“ルーティング表”を決めておく
[Claude Code]
- 設計相談
- 大規模リファクタ
- 根本原因が見えないバグ調査
[Codex CLI / 軽量モデル]
- テストコード量産
- 軽微修正
- 文言変更・ログ追加
- 単純なAPIクライアント生成
- 日本企業なら、契約・リージョン・監査も同時に検討
今日から変えられる実践策7つ：Claude Code時代の“賢い付き合い方”
ここからは「で、結局なにを変えればいいの？」パートです。
2.1.94 の変更を踏まえて、すぐ動ける7つに絞りました。
主参照URL：
https://x.com/ClaudeCodeLog/status/2041633784836038757
実践策① “全部high”を卒業：タスク別に思考深度を切り替える
- 自分のタスクを「重い」「ふつう」「軽い」に分ける
- 重い：設計相談、大規模リファクタ、原因不明バグ調査
- ふつう：既存設計に沿った機能追加、2〜3ファイル改修
-
軽い：文言変更、ログ追加、小さなif修正
-
Claudeへの依頼文に“どれくらい考えてほしいか”を書く
- 重いタスク：
- 「前提整理と代替案、メリデメまで踏み込んでほしい」
-
軽いタスク：
- 「設計は一切変えず、最小の変更だけ行うこと」
-
MEMORY.md に方針を1ブロック追加する
実践策② MEMORY.mdは300行より30行：短く・判定可能に・毎週見直す
- MEMORY.md / CLAUDE.md を“ルールファイル”として整理
- 残す：コーディング規約、テスト方針、NEVER、PRルール
-
削る：歴史、ポエム、長文背景
-
30行前後を目安に一度書き直す
サンプルは後の「具体例」セクションに載せています。
- 週1で5分だけ見直す
- 守られていないルールは、書き方が曖昧でないかを確認
- いらないルールは勇気を持って削る
実践策③ 重い仕事はClaude系、量産タスクは別CLIへ分流
- タスクを2レーンに分ける
- Claudeレーン：設計、大規模リファクタ、原因不明バグ調査
-
軽量レーン：APIクライアント量産、テスト量産、軽微修正
-
チームWikiに“推奨ツール表”を1枚作る
-
1週間だけ分流のA/Bテストをする
- 同じタスクを「全部Claude」と「Claude＋軽量モデル併用」で比べる
- 所要時間と体感品質をメモる
実践策④ 料金・待ち時間・成功率をざっくり記録して判断ミスを減らす
- 簡単な記録表を作る
- 日付
- タスク種別
- 使用ツール
- 所要時間
-
成功度（◎ / ○ / △ / ×）
-
1週間だけ、タスク毎に30秒で埋める
-
“effort=highが効いているゾーン”と“無駄ゾーン”を切り分ける
実践策⑤ チームでテンプレを共有：依頼文がバラバラだと再現性もバラける
- よく使う依頼文を3パターンだけテンプレ化
- 設計相談
- リファクタ
-
バグ調査
-
テンプレには必ず5要素を入れる
- 目的
- 対象範囲
- 制約
- 期待する出力
-
テスト・確認観点
-
テンプレを
.claude/commands/**.mdやチームWikiに置く /bugfix/refactorなどスラッシュコマンド化もおすすめ
実践策⑥ 週次の“AI環境棚卸し”で地雷更新を避ける
- AI環境チェックリストを作る
- 使っているCLIバージョン
- 使っているモデル
- 廃止・非推奨のアナウンスの有無
-
レートや料金プランの変更
-
毎週同じ時間に15分だけ確認
- 個人なら金曜夕方
-
チームなら週次MTGの最後
-
怪しい変化は、まず検証用リポジトリで試す
- いきなり本番で
npm update -gしない
実践策⑦ まずは1週間A/Bテスト：感想ではなく数字でツールを選ぶ
- 1種類のタスクを選ぶ
-
小規模リファクタ、APIに1パラメータ追加、ログ改善など
-
同じタスクを違う設定・CLIでやってみる
- A：Claude Code（high）
- B：Claude Code（制約きつめ）
-
C：Codex CLI or 軽量モデル
-
所要時間・手直し量・満足度だけメモ
-
3〜5タスク分やってみて傾向を見る
- どのツールがどのタスクで“勝っているか”を把握する
すぐ使える具体例：MEMORY.md・依頼テンプレ・振り分けルールの実用サンプル
ここからはそのままコピペして叩き台にできる具体例です。
主参照アップデート：
https://x.com/ClaudeCodeLog/status/2041633784836038757
サンプル① 30行で伝わる最小MEMORY.md
# MEMORY.md（最小サンプル） ## プロジェクト概要 - TypeScript + Node.js のAPIバックエンド - フレームワーク: Express - DB: PostgreSQL（Prisma経由） - 主な責務: ユーザー管理と課金処理 ## コーディング方針 - TypeScriptは `strict` モード前提 - 変数名・関数名は英語、コメントは日本語OK - ログは `src/lib/logger.ts` のラッパー経由で出力する（`console.log`は禁止） ## テスト方針 - 新規機能には必ずユニットテストを追加する - バグ修正時は、再現テストを書いてから修正する（TDD優先） - テストは `npm test` で実行可能な状態を維持する ## 禁止事項（NEVER） - NEVER: パスワードやAPIキーをハードコーディングしない - NEVER: 既存のエラーハンドリングを削除して黙殺しない - NEVER: テストを一切追加せずに本番コードを大きく変更しない ## PR / コミットルール - YOU MUST: コミットメッセージは日本語で要約を書く - YOU MUST: PR説明には「背景」「変更内容」「テスト方法」を含める - IMPORTANT: 破壊的変更を含む場合は、PRタイトルに `[BREAKING]` を付ける ## Effortの使い分け - 設計相談 / 大規模リファクタ / 原因不明のバグ調査: - 深く時間をかけて考えてよい - 軽微修正 / 文言変更 / ログ追加: - 設計方針は一切変えず、最小の変更だけを行う
サンプル② 出力のブレを減らす依頼テンプレ
(A) 設計＋リファクタ依頼テンプレ
目的： XXX機能のコードをリファクタリングし、可読性と保守性を向上させたい。 外部APIとのインターフェースやDBスキーマは一切変更しない。 対象範囲： - @src/services/UserService.ts - @src/repositories/UserRepository.ts これら以外のファイルは読んでもよいが、変更は加えないでください。 前提： - このプロジェクトの前提・ルールは @MEMORY.md / @CLAUDE.md に記載の通り - Prismaを使ったDBアクセスの抽象化方針は維持する 制約： - 新しい外部ライブラリは追加しない - 公開APIのインターフェース（HTTPパス・メソッド・JSON形式）は一切変更しない - ビジネスロジックの仕様は変えない（名前と責務の整理にとどめる） 期待する出力： 1. 現状コードの問題点と改善方針（箇条書きで3〜5点） 2. リファクタリングのステップごとの計画（小さな単位に分けて） 3. 実際のコード変更案（差分形式 or ファイル全体） 4. 追加・修正すべきテストケースのリスト テスト観点： - 既存テストが全て通ること - ユーザー登録〜ログインまでのシナリオが壊れていないこと - エラー時のログメッセージが以前よりも分かりやすくなっていること 重要： - この依頼は「深く考えてほしい」タスクです。 - 必要であれば計画段階で一度止まり、計画だけをレビューできるようにしてください。
(B) 軽微修正テンプレ（“考えすぎ禁止”版）
目的： 既存の挙動を一切変えず、ログメッセージだけを改善したい。 対象範囲： - @src/controllers/AuthController.ts のみ 前提： - プロジェクトルールは @MEMORY.md に従う - エンドポイントのURLやレスポンス形式は絶対に変更しない 制約： - 設計や責務の分割には手を出さない - 関数の分割や新規ファイルの追加も行わない - ログの文言とログレベルの変更以外は一切行わない 期待する出力： 1. 変更するべきログ行の一覧 2. 修正後のコード全文（対象関数のみでもOK） 3. 動作確認に必要な最小限のテスト手順 テスト観点： - 既存のHTTPレスポンス（ステータスコード・ボディ）が一切変わらないこと - ログレベルとメッセージだけが適切に変わっていること 重要： - このタスクは「軽微」であり、深く考える必要はありません。 - リファクタや追加機能提案などは一切行わないでください。
サンプル③ 5秒で判断するルーティング表
# AIタスク振り分けルール（2026春版） ## 1. Claude Code に投げるタスク ### 設計・アーキテクチャ - 新機能の設計レビュー - モノリス分割方針の検討 - 複数サービスまたぎのデータフロー整理 ### 大規模リファクタ - 3ファイル以上にまたがる責務整理 - サービス層・ドメイン層の再構成 - 認証・課金・通知など横断的な機能の再設計 ### 原因不明バグ調査 - 再現条件が複雑な500エラー - 状態が絡み合った不具合（セッション・キャッシュ等） - 既存コードの意図が読みづらい箇所の解析 > ※これらは「深く考えてOK」なので、effort=high前提で使ってよい。 --- ## 2. Codex CLI / 軽量モデル に投げるタスク ### 軽微修正 - 文言変更 - ログ追加・ログフォーマットの調整 - 型定義のフィールド追加 ### 量産タスク - APIクライアントメソッドの量産 - DTO / 型定義の自動生成 - 単純なバリデーションルールの追加 ### 補助作業 - SQLクエリの整形・リフォーマット - 正規表現の生成・テスト - ドキュメントの要約や英訳 / 和訳 > ※ここでは「速さとコスト優先」。 > Claude Code を使うのはもったいない場合が多い。 --- ## 3. ローカル補完 or 手でやるべきタスク - 単純な置換（例: 関数名の一括リネーム） - 自明な定数の追加・削除 - 1〜2行だけのスクリプト修正 > ※エディタのマクロや `sed` / `rg` で済むものはAIに投げない。
ハマりがちな失敗4選：便利になったはずなのに、なぜか開発体験が悪化する理由
2.1.94 の方向性自体は「深く考える」「メモリをちゃんと使う」という真っ当な強化です。
それでも開発体験が悪化するのは、たいてい使い方のクセが原因です。
失敗① 「深く考えさせれば何でも正解に近づく」と思う
- 前提が曖昧なままeffortだけ高くすると、
- あいまいな問題をあいまいなまま深くこじらせる
対策
- まずは「現状整理だけ」を頼む
- 人間の目でスコープと前提を一度確認
- そのうえで「ここから先は深く考えてOK」と指定
失敗② MEMORY.mdに全部詰め込んで、結局どれも効かなくなる
- プロジェクトの歴史、心の叫び、文化、ルールを全部突っ込むと、
- 何がNEVERで何が背景か分からない
ignore-memory挙動変更で、何が効いているかも分からない
対策
- 背景・ストーリーは
docs/に分離 - MEMORY.md には「ルールと前提」だけを残す
- 300行→30行を目安に削る
失敗③ “最近高い”“なんか遅い”を体感だけで語る
- 感覚だけでツール・設定を変えると、
- 良い変化も悪い変化も評価できない
対策
- 1週間だけ、タスク毎に：
- 所要時間
- 使用ツール
- 成功度（◎/○/△/×）
をメモる - それを見て、「どのタスクにどのツールが向くか」を決める
失敗④ チーム全員が違う流儀で使って、レビュー観点がカオス化
- AさんはTDD強め、Bさんは素Claude、Cさんは個人CLAUDE.mdで謎ルール
- 結果：コードスタイルもテスト方針もバラバラ
対策
- プロジェクト共通のMEMORY.mdをGit管理
- 個人の
~/.claude/CLAUDE.mdは会話スタイルなど“好みレイヤー”だけに - 依頼テンプレをチームで共有
- PRテンプレに「使ったツール」「参照したMEMORYファイル」を書く欄を追加
FAQ：Claude Code運用でよくある疑問を5分で整理
主参照アップデート：
https://x.com/ClaudeCodeLog/status/2041633784836038757
Q1. 思考深度が上がると、料金は必ず増えますか？
- 必ず増えるとは限らないが、増える可能性は高い
- 設計・大規模リファクタ・長文ログ解析を多用しているほど影響大
- 軽作業を別CLIに逃がし、「ここは軽くでいい」と制約を書けば、
- 品質アップ＋料金ほぼ横ばいも十分ありえる
Q2. MEMORY.mdには何を書くのが正解ですか？
- 書くべき
- 言語・フレームワーク方針
- コーディング規約
- テスト方針
NEVER:系禁止事項- PR・コミットルール
- 書かないほうがいい
- 歴史、物語、理念
- 長さ
- まず30行前後から始めるのがおすすめ
Q3. 初心者ならClaude系と軽量CLI、どちらから試すべき？
- 複雑な相談・設計も見てほしい → Claude Codeから
- まずは軽微修正やテスト生成で味見したい → Codex CLI / 軽量モデルから
個人的には：
- 軽作業をCodex CLI / 軽量モデルで触る
- 「コードベース全体を見てほしい」と思い始めたらClaude Code
- 最終的に「重いタスク＝Claude、軽いタスク＝他CLI」の二刀流
が現実的だと思っています。
Q4. 企業導入で最初に確認すべきポイントは？
性能より先に、まずはこの5つです。
- 契約形態（法人プラン・支払い方法）
- データ扱い（学習利用・ログ保持）
- リージョン（通していい場所か）
- 監査・権限管理（誰が何をしたか追えるか）
- レートリミット / 上限（チーム利用時に足りるか）
ここを情シス・法務・SREと共有してから性能比較に入ると、後が楽です。
Q5. 1つのツールに統一したほうが管理しやすいのでは？
- 管理だけ見れば「1ツール統一」は確かに楽
- でも軽作業にも重いツールを使うことになり、長期的にはコスト・速度で損しがち
おすすめは：
「重いタスク用メインフレーム」＋「軽いタスク用サブツール」2〜3本構成
- Claude Code：設計・大規模リファクタ・バグ調査
- Codex CLI / 軽量モデル：テスト・DTO・ログなど量産＋軽微修正
- ブラウザ版（Claude / ChatGPT）：会話メモ・要約
くらいがバランスよいと思います。
まとめ：今週やるべきことはこの7つ、AIコーディング環境は“放置しない”が正解
主参照URL：
https://x.com/ClaudeCodeLog/status/2041633784836038757
30秒でおさらい：今回の重要ポイント一覧
effort=highデフォルト化で、設計相談・リファクタの質は上がりやすい- その代わり、軽作業まで全部highだと遅い＆高い側に振れがち
ignore-memoryがMEMORY.mdを空扱いしなくなり、- ルールファイル設計の重要度が上がった
- Claude Codeは「高級フルコース」、Codex / 軽量モデルは「回転の速い定食屋」的な使い分けが現実解
今週やることチェックリスト：まず1つだけ変えてみよう
✅ 今週の7つのアクション
- タスクを「重い／ふつう／軽い」に仕分ける
- MEMORY.md / CLAUDE.md を30行くらいの“ルール辞書”にリライトする
- 設計＆リファクタ用の依頼テンプレを1つ作る
- 軽微修正用の“考えすぎ禁止テンプレ”を1つ用意する
- タスクごとのツールルーティング表を1枚書く
- 1週間だけ「ツール」「所要時間」「成功度(◎/○/△/×)」をメモる
- 金曜15分の“AI環境棚卸しタイム”を作る
全部は大変なので、まずはこの中から1つだけ選んで今日やってみてください。
あなたの構成はどっち派？SNSで共有したくなる問い
- あなたの開発環境は今、
- 「Claude Code一刀流」ですか？
- それとも 「Codex＋軽量モデルとの二刀流」ですか？
- MEMORY.mdは、
- まだ数百行の社史が詰まっていますか？
- それとも30行のルール辞書に近づいていますか？
effort=highデフォルト化で、- 「設計相談はかなり楽になった」と感じていますか？
- それとも「なんか遅くて高くなっただけ…」と感じていますか？
どれか1つでも刺さったら、この記事のサンプル（MEMORY.md / テンプレ / ルーティング表）を、
そのままプロジェクトに貼り付けて少しだけカスタマイズしてみてください。
AIコーディングツールは、放置するとインストールしただけの高級拡張機能になりがちですが、
メモリ・ルール・役割分担をメンテしてあげると、
「クセは強いけどめちゃ優秀な同僚」くらいの距離感に落ち着きます。
Claude Code 2.1.94 のアップデートは、その同僚が
「ちょっと考えすぎ＆記憶力よすぎ」方向に進化したタイミングです。
どうせならこの機会に、自分のAI環境も一緒にアップデートしてやりましょう。
あなたの現場の構成（Claude一刀流か、二刀流か、三刀流か）、
Xで「#AIコーディング環境メンテ」あたりのハッシュタグを付けて共有してもらえると、僕も次の記事のネタにします。
コメント