Rui Software怠惰なエンジニアが生成AI時代に正しく怠ける方法
この記事では、「サボる」のではなく、未来の自分が同じ作業をしなくて済む仕組みを作るための、生成AI時代の怠け方を整理します。
🧭 テーマの主役：「正しく怠ける」とは何か
怠惰なエンジニアにとっての理想は、椅子に沈んで何もしないことではありません。理想は、昨日の自分が作った仕組みに今日の仕事を押し付け、今日の自分は次の仕組みを作ることです。
一言で言えば、正しく怠けるとは、作業を減らすために作業を設計する技術です。料理で例えるなら、毎回包丁で千切りするのではなく、スライサーを買い、よく使う野菜を先に切って冷凍し、平日の自分を救う感じに近い。最初だけ少し面倒ですが、未来の夕方に「助かった……」と心から思えます。
生成AI時代の怠け方でできることは、かなり具体的です。
- 調査・要約・比較表作成をAIに下書きさせる
- テスト観点、レビュー観点、リリース手順をテンプレート化する
- コード生成より先に、仕様の穴や曖昧な言葉を見つける
- 自分の作業ログを再利用可能なプロンプト・チェックリストに変える
- 「毎回聞かれる質問」に対して、AIが読めるナレッジを整える
ここで大事なのは、怠ける対象を間違えないことです。考えることまで丸投げすると、あとで不具合・手戻り・説明不能という名の請求書が届きます。生成AIは優秀な後輩というより、超高速なインターン兼検索係兼壁打ち相手です。任せる範囲を設計できる人ほど、気持ちよく怠けられます。
🎯 動機：なぜ今、「怠け方」がスキルになるのか
昔からエンジニアには「面倒なことは自動化しろ」という文化がありました。ただ、生成AIの登場で、その対象がコードだけではなく、文章・調査・設計・レビュー・運用メモまで広がりました。
GitHubのOctoverse 2025では、LLM SDKを使う公開リポジトリが大きく増え、AIを前提にした開発ワークフローが一般化していることが示されています。Stack Overflow Developer Survey 2025でも、開発プロセスでAIツールを使う、または使う予定の回答者が84%に達したと報告されています。一方で、同調査ではAIツールへの好意的な見方が2023年・2024年の70%超から2025年は60%へ下がっています。
つまり現場の空気は「みんな使っている。でも、全員が幸せになっているわけではない」です。ここが面白いところです。AIを触っただけの人と、AIに仕事を渡す設計をした人の差が、じわじわ広がっています。
この差は、洗濯機を買っただけの人と、洗濯物の分別・干し方・収納場所まで設計した人の差に似ています。機械はあるのに床に服が山積みなら、生活はあまり楽になりません。AIも同じで、導入より先に「どの作業を、どの粒度で、どう検査して渡すか」が効きます。
💭 仮説：怠惰な人ほど、AIワークフロー設計に向いている
怠惰な人は、同じ作業を2回やることに強い拒否反応を示します。これは悪癖に見えて、実は自動化の才能です。
仮説はこうです。生成AI時代に強い怠惰なエンジニアは、「作業者」ではなく「作業の型を作る人」になる。コードを1回書くより、コードを書く前の入力情報、期待出力、検査条件、失敗時の戻し方を整える。その型にAIを流し込むと、毎回ゼロから頑張らなくて済みます。
たとえば、バグ修正を考えます。怠け方が下手な人は、AIに「このバグ直して」と丸投げします。怠け方がうまい人は、次のように渡します。
目的: ログイン後にリダイレクトされない不具合を直す
再現手順: ...
期待結果: ...
変更してよい範囲: auth 配下のみ
禁止事項: try/catch で握りつぶさない
検査: 既存テスト + 手動確認手順
出力: 原因、変更点、テスト結果を短く報告
この差は地味ですが、結果は大きく変わります。AIに魔法を期待するのではなく、弁当箱の仕切りを先に作ってからおかずを詰めてもらう。ぐちゃぐちゃにならないので、食べるときの自分が助かります。
🔍 検証：AIは万能薬ではなく、増幅器である
生成AIは、よい設計も悪い設計も増幅します。雑な依頼を速く大量に処理できるため、雑さも高速で増えます。ここを勘違いすると、「AIを入れたのにレビューが地獄」という悲しい景色になります。
McKinseyのState of AI 2025は、AI利用が広がる一方で、パイロットからスケールした成果への移行にはまだ課題が残ると整理しています。DORAのAI-assisted Software Development関連の調査でも、AI導入は単なるツール配布ではなく、測定・信頼・組織能力とセットで扱う必要があるとされています。
エンジニア個人に置き換えると、これは「AIを契約したか」ではなく「AIに渡す仕事の棚卸しができているか」の問題です。タスクを次の4種類に分けるだけでも、怠け方の精度が上がります。
ポイントは、AIに任せるかどうかを「できそう」ではなく「失敗したときの損害」で決めることです。READMEのたたき台なら多少外しても直せます。認証・課金・個人情報・本番DBの変更は、AIが自信満々でも人間がハンドルを握るべきです。自信満々な間違いほど、レビュー時の血圧に悪いものはありません。
🔄 代替アプローチ比較：怠け方にも流派がある
怠け方はひとつではありません。自動化、生成AI、テンプレート、外注、放置。それぞれ向き不向きがあります。
| 怠け方 | 向いている作業 | 弱点 | おすすめ度 |
|---|---|---|---|
| 生成AIに下書きさせる | 調査整理、仕様たたき台、テスト観点、文章化 | 事実確認と責任判断は残る | 高 |
| スクリプトで自動化する | 繰り返し実行する定型作業、変換、集計 | 初期実装と保守が必要 | 高 |
| テンプレート化する | PR本文、設計メモ、レビュー観点、障害報告 | 更新しないと形骸化する | かなり高 |
| 人に丸投げする | 自分より得意な人がいる専門作業 | 背景共有を怠ると手戻りが増える | 条件付き |
| やらない | 価値が低い作業、誰も読まない資料 | 本当に不要か判断が必要 | 最強だが危険 |
一番強いのは、これらを混ぜることです。AIで下書きし、よく使う形をテンプレートにし、3回以上繰り返したらスクリプト化する。逆に、半年に1回しかやらない作業を完璧に自動化するのは、怠惰ではなく趣味です。趣味なら止めません。私もたぶんやります。
💡 活用事例：怠惰な1日をワークフローに変える
ここでは、生成AI時代の怠惰なエンジニアの1日を想像してみます。目的は、楽をすることではなく、判断力を温存することです。
朝、まず昨日の作業ログをAIに渡して、今日のTODO候補に分解させます。この時点ではAIの提案を信用しすぎません。自分で優先順位を決め、「今日はここまでやれば勝ち」という線を引きます。
次に、実装前にAIへ仕様の曖昧さを指摘させます。これはかなり費用対効果が高い怠け方です。コードを書いてから要件漏れに気づくと、せっかく作ったものを壊す必要があります。実装前の質問出しは、旅行前に天気予報を見るようなものです。雨なら傘を持てばいい。現地でずぶ濡れになってから反省するより安い。
昼は、AIにテスト観点を出させます。ただし「全部テストして」ではなく、「境界値」「異常系」「権限」「互換性」のように観点を指定します。夕方、PR本文の下書き、変更点の要約、レビュアー向けの確認ポイントをAIに作らせます。
この流れの価値は、コード量が増えることではありません。人間が判断すべき場所に集中できることです。Stack Overflowの2025年調査でAI利用が広がる一方、信頼や好意的な見方が伸び悩んでいることを踏まえると、AIに判断を委ねるより、判断材料を作らせる使い方のほうが現実的です。
🔥 ハマりポイント：やりがちな3つの過ち
怠ける技術は、雑に使うとすぐ「未来の自分への嫌がらせ」に変わります。ここは少しだけ真面目に見ておきましょう。
その1：「AIが書いたから大丈夫」と思ってしまう
症状は、もっともらしいコードや文章をそのまま通してしまうことです。原因は、生成AIの流暢さを正確さと取り違えること。対処は、AIの出力を「完成品」ではなく「レビュー対象の新人成果物」として扱うことです。テスト、公式ドキュメント確認、差分レビューをセットにします。
その2：プロンプトを毎回その場で書く
症状は、毎回AIに同じ説明をして疲れることです。原因は、怠けるための準備を怠っていること。対処は、よく使う依頼をテンプレート化することです。「バグ調査用」「PRレビュー用」「設計の穴探し用」など、3種類だけでも効果があります。
その3：自動化すべきでないものまで自動化する
症状は、スクリプトやAIエージェントの保守に時間を吸われることです。原因は、発生頻度と失敗コストを見積もらずに作り込むこと。対処は、「3回やったらテンプレ化、5回やったら自動化」くらいの雑な基準を置くことです。雑ですが、何も基準がないよりずっと働きます。
🚀 取り込み方：今日から怠けるための3段階
いきなり完璧なAI開発環境を作ろうとすると、環境構築だけで週末が溶けます。怠けるために疲弊するのは本末転倒なので、段階を分けます。
今日（5分）
まず、今日やった作業を3行だけメモします。形式は雑で構いません。
今日やったこと:
困ったこと:
次に同じことをするとき短縮できそうなこと:
このメモをAIに渡して、「次回のチェックリストにして」と依頼します。これだけで、未来の自分への引き継ぎができます。
今週
よく使うプロンプトを3つ作ります。おすすめは次の3種類です。
1. 仕様の曖昧さを指摘して
2. この差分のレビュー観点を出して
3. この作業を再利用可能な手順書にして
ポイントは、プロンプトを作品にしないことです。凝りすぎると続きません。弁当箱に金箔を貼る前に、まず弁当を詰めましょう。
今月
自分専用の「怠ける資産」を作ります。具体的には、docs/ai-prompts.md や logs/workflow-notes.md のようなファイルに、よく使う指示、失敗例、確認コマンド、レビュー観点を貯めます。
ここまで来ると、AIは単発のチャット相手ではなく、自分の作業スタイルを反映した道具箱になります。大工が道具を手入れするように、エンジニアはプロンプトとチェックリストを手入れする。怠惰なのに職人っぽい、ちょっとお得な状態です。
✅ 要点まとめ
生成AI時代の怠惰は、何もしないことではなく、同じ苦労を繰り返さないための設計です。最後に、この記事の要点を圧縮します。
- AIに任せる前に、目的・制約・検査条件を渡す
- コード生成より、仕様の穴探し・テスト観点・レビュー観点に使うと安定しやすい
- 定型・低リスク作業はAIやスクリプトに寄せる
- 高リスク判断は人間が持ち、AIには判断材料を作らせる
- プロンプト、チェックリスト、作業ログを資産化すると、未来の自分が楽になる
- 「やらない」と決めることも、立派なエンジニアリング判断である
まとめ
怠惰なエンジニアが生成AI時代に目指すべき姿は、「AIに全部やらせる人」ではありません。AIに渡せる形まで仕事を分解し、検査できる形で受け取る人です。
これを読んだあなたは、明日からまず作業ログを3行残し、それをチェックリスト化するところから始められます。小さすぎると思うかもしれません。でも、怠惰の資産はいつも小さいメモから始まります。未来の自分を働かせるために、今日の自分は少しだけ仕組みを作りましょう。