7月31日、ksred.comが「Claude Code Workflows That Survived 18 Months in Production」と題した記事を公開した。Claude Codeを18ヶ月間本番環境で使い続けた筆者が、実際に生き残ったワークフローと捨てたワークフローを整理した実践知見だ。
AIコーディングツールの記事は「最初の1週間」に書かれることが多い。デモが動いて興奮した状態で書かれ、1年後に誰も戻ってきて検証しない。この記事はその逆だ。
筆者は2025年2月のリサーチプレビュー開始からClaude Codeを使い続け、対象はGreenfield（新規）の玩具プロジェクトではなく、本番稼働しているGoサービス群、複数のVueフロントエンド、スキーマ変更が怖くなるほどのPostgresだ。その環境で「生き残った6つのワークフロー」と「捨てた4つ」が整理されている。
不快な前提：体感速度は信用できない
本題に入る前に、筆者が強調するのがMETRの無作為化試験の結果だ。経験豊富なオープンソース開発者を対象に複数タスクで実施した結果、AIを使った方が19%遅かった。にもかかわらず開発者自身は「20%速くなった」と回答していた。
※元記事でのMETRの試験条件（参加者数・タスク数・リポジトリ規模等）の詳細は元記事本文を直接確認されたい。
この「体感速度と実測速度のギャップ」こそが問題の核心だと筆者は言う。生き残ったワークフローはすべてこのギャップを機械的に埋めるものであり、捨てたワークフローはすべて気持ちよくさせながらギャップを広げるものだった。
生き残ったワークフロー：核心は「証明させること」
プランモードをほぼ全セッションで使う
Shift+Tabを2回押してプランを読み、内容に納得してから実装させる。Claude Codeのビルダーであるボリス・チェルニー氏（製品開発を主導するエンジニア／PM）は自分のセッションの約80%でプランモードを使うと述べており、Anthropicの試算では典型的な機能実装に約20の意思決定があるとされている。仮に各決定で80%の正答率でも、すべて正しく判断できる確率は約1%になる。
プランの価値は「良いプランが出てくること」ではなく、「悪いプランを安く発見できること」だ。プランを読むのは90秒、400行のdiffをまともに読むのは20分かかる。
失敗するテストを仕様として書く
明示的に書いておかないと機能しない、と筆者は強調する。ポイントは「テストを先に書き、実装には一切手をつけないこと」だ。放置すると、Claudeは実装してからその実装に同意するテストを書く。それは「何も保証しない自信」を高コストで生成しているだけだ。
失敗するテストは、Claudeが言い訳できない仕様になる。Goのサービスではテーブル駆動テストが明確な形を与えるため、特に効果が高いという。このワークフローが機能する理由は構造にある。テストが先にあれば、Claudeの「完了」の定義が「自分が納得したとき」から「テストが通ったとき」に変わる。検証の基準が外部化される、というのが筆者の表現だ。
CLAUDE.mdをほぼ空に保つ
CLAUDE.mdはすべてのターン、常に、全文がロードされる。そのため「たまにしか必要ない情報」を書き込むのは、毎回コストを払いながら希薄化させているだけだ。
記述が増えるほどClaudeが従うルールは増えるどころか減る、と筆者は述べる。残しているのは「これがなければ即座にミスになる」最小限の情報のみ。ビルドコマンド、ORMではなく生SQLを使うこと、エラーラッピングの規約、自動生成されるため手動編集禁止のディレクトリ一覧だ。それ以外は筆者が自作したCont3xt（関連するときだけコンテキストを取得するツール）に移した。
サブエージェントは「読み取り専用」で使う
サブエージェントを早期に導入し、2週間で使うのをやめ、その後戻った経緯が述べられている。正しい用途は並列化や専門化ではなく「コンテキスト分離」だ。
40ファイルを読んで1つの質問に答えるサブエージェントは、そのノイズをすべて自分のウィンドウで消化し、親エージェントには結論の段落だけを渡す。親は沈殿物を受け取らずに済む。
一方、実装作業にサブエージェントを使うのは、通常比4〜7倍のトークンコストを払いながら、それでも1行ずつレビューしなければならない構造だ。Agent Teamsでは約15倍になるという。
「絶対にXするな」はフックに書く
プロンプトに書いたルールは、セッションが長くなるか、コンテキストが混雑するか、モデルが完了を急ぐと静かに無効化される。**PreToolUseフックでブロックするルールはリクエストではなく制約**なので、常に効く。
筆者のフック設定は以下のようなものだ。
PostToolUseでgofmtとlinterを自動実行（フォーマット差分がdiffに混入しない）- 自動生成ディレクトリとmigrationsへの書き込みをブロック
- ターン終了をテストスイートのパスに条件付け
最後の設定について筆者は「どのモデルアップグレードよりも、このツールの性質を変えた」と述べる。「完了したと言うもの」から「実際に完了したときだけ止まれるもの」になった。
圧縮より/clearを選ぶ
コンテキストウィンドウのコンパクション（圧縮）は非可逆であり、混乱した状態で圧縮すると「小さなコンテナに保存された混乱」が残るだけだ。
Sonnet 5やOpus 5の100万トークンコンテキストでもこの方針は変えていない。容量の上限が大きくなっても、品質の低下はおよそ2/3を超えたあたりで始まる、というのが筆者の観察だ。
捨てたワークフロー
並列セッションを無制限に増やすこと
4〜5セッション（ccswitchで管理）が限界だと筆者は述べる。それ以上は「1人が1日で正直にレビューできる量」を超える。50エージェントを走らせていたユーザーがモデル更新で全員同時に劣化した事例も紹介されており、スケールアウトの上限はモデルの能力ではなく人間のレビュー帯域にある、という指摘は重い。
全操作の自動承認
廃棄可能なコンテナ内なら問題ないが、それ以外では危険だ。ただし筆者が本当の問題として挙げるのは劇的な事故ではなく、「レビュー習慣が失われること」だ。自動承認に慣れると、差分を読む筋肉が静かに落ちていく。
全タスクにカスタムエージェントを書くこと
スラッシュコマンドやスキルで足りるケースがほとんどだった。エージェントの設計・保守コストを払う価値がある場面は、筆者の経験では限られていたという。
モデル選択をその都度考えること
opusplan（プランをOpusで、実行をSonnetで行う設定）をデフォルトにして考えるのをやめた。2026年4月時点のAnthropicのコスト試算では、開発者1人あたり1アクティブ日に約13ドルとなっており、大部分はSonnetで代替できる作業にOpusを使っていることが多いという。選択をルール化することで認知負荷を排除した、という判断だ。
共通する構造
生き残ったワークフローはすべて「モデルに何かを証明させる」仕組みを持つ。捨てたワークフローはすべて「生産的に見せる」仕組みだった。
筆者はこう締めくくる。
18ヶ月で変わったことをひとつにまとめると、「どうすればもっと多くの作業を引き出せるか」ではなく、「どこで作業を検証するか」を問うようにしたことだ。
詳細はClaude Code Workflows That Survived 18 Months in Productionを参照していただきたい。
