0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Claude Codeを導入して開発速度が5倍になったのに、なぜ私の疲労度は10倍になったのか

0
Posted at

はじめに:爆速開発の果てに待っていた「前例のない脳疲労」

ここ数週間、日々の開発に Claude Code や Cursor を徹底的に組み込み、いわゆる「AIネイティブ開発」を本気で回してきました。

表面的な数字だけを見れば、大成功と言っていいはずでした。
これまで設計から実装、テストまで丸3日かかっていた新機能が、半日もあればプルリクエスト(PR)まで持っていける。1日に生成されるコード行数も、マージできるブランチの数も、体感で4〜5倍に跳ね上がりました。

「これで残業も減って、定時退勤して技術書を読む余裕ができるはずだ」

そう思っていました。
しかし、現実はまるで逆でした。

終業時にMacBookを閉じた瞬間、これまでのエンジニア人生で経験したことのないレベルの頭痛と、全身の虚脱感に襲われるのです。
**「キーボードはほとんど叩いていないのに、脳のCPU使用率は1日中100%に張り付いていた」**ような感覚です。

なぜ生産性が上がったはずなのに、ここまで心身が削られるのか?
その理由を掘り下げていくと、現在のAIコーディングが抱える**「構造的な罠」**が見えてきました。


1. ジェボンズのパラドックス:開発コストの低下が「ゾンビ要件」を量産する

1865年、イギリスの経済学者ジェボンズはある奇妙な現象を指摘しました。
蒸気機関の効率が上がり、1単位の動力を生み出すのに必要な石炭が減ったにもかかわらず、国全体の石炭消費量は激増したのです。
動力が安くなったことで、あらゆる産業が蒸気機関を導入し、需要そのものが何十倍にも膨れ上がったためです。これが有名な**「ジェボンズのパラドックス」**です。

今、ソフトウェア開発の現場で起きているのは、まさにこのパラドックスの再来です。

AI以前の時代において、「コードを一行ずつ書く物理的なコスト」は、仕様の肥大化を防ぐ**天然の防波堤(ファイアウォール)**でした。
複雑な機能を足そうとすれば、DBスキーマを練り直し、例外処理を泥臭く書き、結合テストを通す必要があります。「これをやると2人月吹き飛びます」という物理的な制約があったからこそ、PMやビジネスサイドも「本当にそこまでして作る価値があるか?」と踏みとどまっていました。

しかし、AIはその防波堤を一瞬で粉砕しました。

「これ、AIに投げたら1時間くらいでサクッと作れません?」

この空気がチームに広がった瞬間、過去に「費用対効果が合わない」としてボツになった仕様や、思いつきレベルのアイデアが**「ゾンビ要件」**として墓場から無限に蘇ってきます。
AIはエンジニアの仕事を減らしたのではなく、開発コストをゼロに近づけたことで、それ以上のスピードで新しい要求を呼び覚ましてしまったのです。


2. スピードの非対称性:人間が「高負荷な人肉Linter」に成り下がる地獄

従来の開発には、人間にとって心地よい「思考の呼吸リズム」がありました。

  1. どう設計するか考える
  2. コードを書く
  3. ビルドを待つ・ログを見る
  4. ドキュメントを調べて直す

タイピングしている時間やコンパイルを待つ数分間は、脳にとって適度な「アイドリング(小休止)」でした。

しかし、Claude Code を導入した途端、その呼吸は完全に奪われます。

ターミナルに1行プロンプトを投げる。10分もしないうちに、数十ファイル・数百行に及ぶ差分(diff)がドカンと降ってきます。
その瞬間から、私たちのロールは「コードを書く人」から**「超人的な新人インターンの暴走を監視する専任レビュアー」**へと強制的にシフトします。

  • git diff を凝視し、AIがなぜこのロジックを変更したのか意図を逆算する
  • 局所的には動いているが、システム全体の設計思想を破壊している箇所を特定する
  • 指摘すると、さらに別の20ファイルが書き換わり、新たな差分の波が押し寄せる
  • エッジケースの考慮漏れを突っ込む
  • よく見ると、今回まったく触る必要のない共通モジュールを「親切心」で勝手にリファクタリングしていて絶望する
  • 泣く泣く git checkout で巻き戻す

相手は24時間寝ずに、1日何万行でもコードを吐き出せる無尽蔵の体力を持っています。
しかし、**「たまに自信満々で大嘘(ハルシネーション)をつく」**のです。

コードの生成速度はマシンタイム(数秒)になったが、人間の理解速度と認知限界は生物のまま据え置かれている。

手作業の負担が減った代わりに、脳のコンテキストスイッチは限界を超えてフル回転を強いられます。手は休まっているのに脳が焼き切れるのは、これが原因です。


3. 「80%の罠」と「残された20%の泥沼」

AIエージェントは、どんなタスクでも「最初の80%」までは驚異的なスピードで運んでくれます。
モックを作り、それっぽいUIを並べ、ハッピーパス(正常系)のAPIを繋ぐところまでは一瞬です。

着手コストが実質ゼロになったことで、私たちは気軽にコードベースをいじれるようになりました。
「この画面、アーキテクチャが古いから最新の設計パターンでリファクタリングして」と投げれば、数分で数十ファイルが書き換わります。

しかし、ソフトウェア工学の本当の地獄は、**「残りの20%」**にあります。

  • ドメイン特有の命名規約やコンテキストの統一
  • ネットワーク瞬断やタイムアウト時の厳密なエラーハンドリング
  • レガシー機能や既存データとの後方互換性
  • 複雑な非同期処理における競合状態(Race Condition)の検証
  • メモリリークの防止とパフォーマンスチューニング

AIが生成するリポジトリには、「あとちょっとで動くはずのコード」が大量に転がることになります。
そして、その「あとちょっと」を埋めるには、プロジェクト全体の文脈を深く理解し、システムの品質に最終責任を持つ人間が泥臭く手を入れるしかありません。

結局のところ、**「AIが猛スピードで散らかした80%の山を、人間が汗を流して100%まで引き上げる」**という構造になり、この最後の20%こそが最もエンジニアの精神エネルギーをすり減らしていきます。


おわりに:AIが削減した時間は、最終的に誰のものか?

誤解のないように言うと、私はAIツールの進化を悲観しているわけではありません。
Claude Code も Cursor も、もはや私の開発環境には欠かせない相棒です。

ただ、一度立ち止まって問い直す必要があると感じています。

「AIが削ってくれたはずの時間は、最終的にどこへ消えたのか?」

浮いた時間が新たなゾンビ要件の消化に消え、エンジニアが「AIの尻拭いをする監視員」として消耗し続けるのだとしたら、AIが進化すればするほど、現場はますます忙しく、不健康になっていきます。

この「AIバブルな疲労」から自衛するために、私は最近以下のルールを意識しています。

  1. AIの作業スコープを厳格に制限する
    リポジトリ全体を無防備に渡さず、単一責任のモジュールや関数単位でコンテキストを絞って作業させる。
  2. 「AIならすぐできるでしょ」に毅然とブレーキをかける
    コード生成が0秒になっても、設計・レビュー・QA・運用責任のコストは依然として人間側にあることをチーム全体で再認識する。
  3. 人間側の「呼吸のペース」を取り戻す
    AIが3秒でdiffを返してきても、即座に飛びつかない。一呼吸置き、自分の思考リズムを崩さない。

道具は凄まじいスピードで進化していきます。
しかし、私たちの脳のスペックも、1日が24時間であるという物理法則も、200年前の産業革命から何一つ変わっていません。

AIの圧倒的なスピードに呑まれてバーンアウトする前に、まずは「人間側のリズム」を取り戻す設計から始めてみる価値はあるはずです。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?