こんにちは！
映像・フィジカルAI開発部の大山です。
日々の開発にAIツールを取り入れるのが当たり前になってきました。コードの補完やリファクタリング、仕様の壁打ちなど、便利な道具として使い倒しているエンジニアも多いと思います。
しかし最近、開発を進める中でふとこんな感覚を覚えることがありました。
「なんだか最近、AIに向き合うだけで妙に疲れるな……」
最初は「プロンプトを練ったり、出力されたコードの粗探しを続けたりする作業疲れかな」と思っていました。ですが、少し立ち止まって頭の中を整理してみると、疲労の本当の原因はツールそのものではなく、AIを取り巻く自分自身の思考パターンにあったことに気づきました。
今回は、エンジニアが直面しがちなこの「AI疲れ」の正体について、どう思考を整理し、どう捉え直したかをお話しします。
1. 最初の罠：「利用枠を使い切らないと損」という損失回避
最初のきっかけは、極めて些細な「もったいない精神」でした。
多くのAIサービスには、「5時間で〇〇回まで」といった利用枠の制限が設定されています。作業に迷ったり設計を考えたりしてその枠を余らせてしまうと、どこからか「枠を使い切らないと損なのでは……」という謎の貧乏性が湧き上がってきます。
でも、これは「残っている利用権を使わずに捨てるのはもったいない」という、ただの損失回避の心理でした。そう気づいてからは、「枠なんて余らせておくのが一番の贅沢だ」と割り切って肩の力を抜けるようになりました。
2. 次の葛藤：AI時代だからこそ起きる「技術選定とインプット疲れ」
次に直面したのが、システム設計やアーキテクチャを選定する際のプレッシャーでした。
現場で方針を出すとき、どうしても頭をよぎる不安があります。「いま自分が持っている狭い技術スタックのまま指示を出して、本当に最適なんだろうか。もっと良い構成があるんじゃないか」と。
もちろん、自分やチームが慣れ親しんだ「枯れた技術」を採用すれば、メンバーも迷わず実装しやすいという安心感はあります。一方で、慣れた技術に留まり続けることへの懸念もあり、もっと新しい技術を取り入れたいという思いも湧いてきます。
実際、あるプロジェクトでは、これまで使い慣れたAWSのままいくか、よりメンテナンスフリーに近いCloudflareに乗り換えるかで悩みました。運用実績のあるAWSなら安心して任せられますが、Cloudflareに寄せられれば、サーバー管理そのものから解放されるメリットも捨てがたい。どちらも一長一短で、なかなか踏ん切りがつきませんでした。
こうした悩みに輪をかけているのが、今はAIがコードや実装を強力にアシストしてくれる時代だということです。これまでは学習コストが高くて敬遠していたような新しいスタックであっても、AIのサポートがあればメンバーも挑戦しやすく、エンジニアとしてのやりがいにもつながるはずです。
だからこそ、「より最適な選択肢」を求めて、最新のアーキテクチャやサービス仕様を学ぶ時間がどんどん増えていきました。これまでなら見送っていたような選択肢まで、一通り勉強してから比較・判断しようとする。
これは「AI疲れ」というよりも、AIによって最新技術の敷居が下がった結果、キャッチアップすべきインプット量が跳ね上がって起きた「勉強疲れ」だったのだと気づきました。
3. 本質的な原因：実装の負荷が減った分、設計・仕様検討の負荷が増した
今回の振り返りで一番腑に落ちたのは、手を動かして実装する負荷よりも、設計や仕様を詰める負荷のほうが、以前よりずっと重くなっているという事実でした。
これは工程そのものの変化として説明がつきます。以前は「調査→設計→実装→テスト」という流れの中で、調査と実装それぞれに一定の時間がかかっていました。ところが今は、調査の直後にAIが大量の選択肢を提示してくれるようになり、「調査→AIによる選択肢提示→比較・評価→設計→実装」という一段多い工程を踏むようになっています。
実装そのものはAIの助けで速く終わるようになった一方で（実際、今ゼロベースで企画を進めているある検査系アプリでは、要件定義からプロトタイプが動くまで1.5日でした。比較できる「AIなしの場合」の実績がないので速い遅いは断言できませんが、実装フェーズの体感速度としてはそのくらいです）、その手前の比較・評価から設計に至る部分の負荷は、むしろ増えている感覚があります。実装工数が減った分、意思決定にかかるコストがそのまま重くなった、というイメージです。
しかも、実装とテストが半自動で素早く回るようになったからこそ、「決めてから作る」より「作ってから直す」方が早くなりました。ただ、それは設計や仕様を詰める負荷が減ったという意味ではありません。むしろ気軽に試せる分だけ試行の回数そのものが増え、「この結果で合っているか」「別の作り方の方が良かったのではないか」を都度判断する場面が増えました。実装が軽くなった分、判断の総量はむしろ膨らんでいる、という感覚です。
このループをうまく回すために、実際にいくつか工夫もしています。例えばgitのworktreeを使い、ひとつの案を実装・検証している間に、別のworktreeで次の候補の下調べや別ブランチの修正を並行して進めるようにしています。1つの案の結果を待つだけの時間を作らないようにする、という発想です。
また、ループを何度も回していると、そもそも何を目的に、どんな仕様で、どう設計したのかが記憶からこぼれ落ちていきます。なので、システムの目的や仕様、設計の要点をmarkdownでその都度ドキュメント化しておくことも欠かせません。実装してみて気づいた変更を、仕様や設計のどこまで反映すべきかを判断する土台になるからです。
道筋が決まったタスクを実装するのは、エンジニアにとって集中できて楽しい時間です。しかし、
- どのアーキテクチャを採用するのがチームにとって最も価値があるか
- この設計で本当に手戻りが発生しないか
- 仕様として詰めきれていない部分はどこか
といった検討には、一度で正解が出せるような答えはありません。試しては評価し、また試すというサイクルを回しながら、そのつど頭を使って判断し続けることになります。
「AIを使っているのに疲れる」と感じていた正体は、操作そのものの疲れではなく、実装がAIに支えられるようになった分だけ、設計や仕様を考える負荷の比重が相対的に増えたことによる思考のオーバーヒートでした。
まとめ（これからのスタンス）
今回、自分の思考を整理してみて、3つの疲れの正体をこう捉え直しました。
- 利用枠を余らせることへの焦りは、ただの損失回避（未消費の権利を捨てたくない気持ち）だと分かれば、それだけで気にならなくなる
- 最近の「勉強疲れ」は、AIによって調べるべき選択肢自体が増えたことが原因だと分かれば、無理に全部キャッチアップしようとしなくて済む
- 「AIを使っているのに疲れる」というモヤモヤは、実装ではなく設計・仕様検討に頭を使う時間が増えたからだと分かれば、正体不明な焦りが消える
AIという相棒ができたことで、新しい技術に挑むハードルは格段に下がりました。しかしその分、「どこへ進むべきか」を選ぶ人間の判断コストは以前よりも増していると感じます。
今回の3つの疲れは、根をたどると全部「AIによって選択肢や可能性が増えたこと」に行き着きます。損失回避も、勉強疲れも、設計負荷も、選べるものが増えたからこそ生まれた疲れでした。
実装がAIに支えられるようになった分だけ、エンジニアの価値は「速く実装できること」から「何を選ぶかを見極める力」へ、少しずつ重心が移ってきているように感じます。
ここまではあくまでエンジニア視点での話です。PMやスペシャリスト、管理職といった立場でもそれぞれのAI疲れがあるはずですが、そのあたりはまだ自分自身がAIとの向き合い方を見つけられていない領域なので、今回は触れていません。機会があれば、いずれ別の記事で書いてみたいと思います。
日々の業務で「なんだか頭が重いな……」と感じている方がいれば、一度作業の手を止めて、自分がどれだけのインプットや判断を一人で抱え込んでいるか、紙に書き出してみてはいかがでしょうか。
この記事が、同じように技術選定や開発の進め方に悩む方の参考になれば幸いです！
