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?

AI時代の根性論 長時間労働ではなく仮説・検証・改善を続ける仕事術

0
Posted at

AI時代の根性論 長時間労働ではなく仮説・検証・改善を続ける仕事術のアイキャッチ

はじめに

生成AIへ依頼しても、最初から期待どおりのコードや文章が返ってくるとは限りません。

ここで「AIは使えない」と諦める人もいれば、前提、指示、資料、分解方法、検証手段を変えながら、目的に近づける人もいます。

AI時代に必要なのは、長時間働くことや、画面へ張り付き続けることではありません。

この記事では、目的を諦めず、短い試行と検証を繰り返す力を、筆者独自の表現として 知性の根性 と呼びます。これは、研究機関や業界団体が定めた公式用語ではありません。

先に結論

  • AI時代の根性は、同じ方法を我慢して続けることではなく、目的を保ったまま方法を変え続けること
  • AIは仕事の初稿を速く作れる一方で、得意・不得意の境界が分かりにくい
  • 人間には、課題設定、作業分解、検証、統合、最終判断が残る
  • AIの利用時間ではなく、品質、実作業時間、手戻り、再現性で効果を測る
  • 疲れるまでAIを動かすのではなく、停止条件と確認時間を決めて使う

AIにかじりつくのではなく、解くべき課題にかじりつく。

この記事で一番伝えたいのは、この考え方です。

前提

  • 対象読者: 生成AIを開発、調査、資料作成、業務改善に使うエンジニアやマネージャー
  • 想定環境: 所属組織が利用を許可した生成AIサービス
  • 扱う範囲: AIを使った仕事の設計、検証、改善の進め方
  • 扱わない範囲: 特定モデルの性能比較、顧客情報や機密情報の入力方法、医療上の診断
  • 事実確認日: 2026年8月20日

根性を使う場所が変わった

従来の根性論では、長時間働くことや、同じ作業を我慢して続けることが努力として評価されがちでした。

しかし、AIが初稿、調査候補、コード案、テスト案を短時間で作る時代には、人間が同じ作業量で競う意味は小さくなります。

代わりに重要になるのは、次の力です。

  • 解くべき問題を見つける
  • 目的と完了条件を言葉にする
  • 大きな仕事を検証可能な単位へ分ける
  • AIへ必要な背景情報を渡す
  • 出力をテストや一次資料で確かめる
  • 誤りの原因を考え、依頼方法を変える
  • 複数の成果物を一つの仕事へ統合する
  • 最終結果に責任を持つ

つまり、努力が不要になるのではありません。 努力を向ける場所が、作業量から仕事の設計と判断へ移る ということです。

AIは平均点を上げやすい

生成AIには、経験が少ない人でも一定水準の初稿へ到達しやすくする効果があります。

Oxford Academicで公開されている論文「Generative AI at Work」では、5,172人のカスタマーサポート担当者を対象に調査し、AI支援によって1時間当たりの問題解決数が平均15%増えたと報告しています。特に、経験や技能が少ない担当者で効果が大きく見られました。

ただし、これは1社のカスタマーサポート業務を対象にした結果です。すべての職種や開発業務で同じ効果が出ると一般化はできません。論文でも、経験豊富な担当者では効果が小さく、一部の品質指標がわずかに下がったことが示されています。

カップ麺に置き換えて考える

生成AIは、誰でも短時間で一定の味を出しやすいカップ麺に似ています。

お湯を注げば、すぐに食べられる状態になります。しかし、人気店の一杯との差は、最後の仕上げにあります。

  • 目的に合う材料を選ぶ
  • 読者や顧客の好みに合わせる
  • 不要な部分を削る
  • 事実を確認する
  • 全体の流れを整える
  • 最後の品質に責任を持つ

この比喩は研究結果ではなく、筆者がAIによる初稿作成を説明するために整理したものです。

AIには得意・不得意の境界がある

AIの厄介なところは、難しそうな仕事ができるのに、その隣にある簡単そうな仕事で間違えることがある点です。

Harvard Business Schoolの研究紹介では、758人のコンサルタントを対象とした実験で、AIの能力範囲内にある課題では、作業速度が25%超、評価品質が40%超、完了数が12%超向上したと報告しています。一方で、AIが得意な課題と不得意な課題の境界が不規則であることを、 Jagged Technological Frontier と表現しています。

日本語では「ギザギザした技術の境界」と考えると分かりやすいです。

例えば、AIが複雑なコードを生成できたからといって、次の内容まで正しいとは限りません。

  • 現在のプロジェクト固有の命名規則
  • 暗黙の業務要件
  • 利用中のバージョンに合うAPI
  • 本番環境の権限やネットワーク条件
  • 例外時の動作
  • セキュリティと個人情報の扱い

そのため、「前の回答が正しかったから、次も正しいだろう」と考えず、仕事ごとに検証方法を決める必要があります。

人間の役割は監督・編集・統合へ移る

Microsoft ResearchがCHI 2025で発表した研究では、319人の知識労働者から936件の生成AI利用例を集めています。AIへの信頼が高いほど批判的思考が少なくなる傾向があり、自分の業務判断への自信が高いほど批判的思考が多くなる傾向が報告されました。

また、生成AIを使うと、批判的思考の中心が 情報の検証、回答の統合、仕事全体の監督 へ移ると整理されています。

AI時代の人間は、単なる作業者ではありません。少なくとも、次の役割を持ちます。

役割 行うこと
依頼者 目的、制約、優先順位を伝える
設計者 作業を小さく分け、入出力を決める
編集者 複数の回答を比較し、一つの成果物へまとめる
品質管理者 テスト、ログ、一次資料で正しさを確かめる
責任者 利用可否を判断し、最終結果に責任を持つ

プロンプトを書く技術だけでは不十分です。AIを仕事の流れへ組み込み、どこを人間が確認するかまで決める必要があります。

筆者が実務で使う改善ループ

次は、筆者がAIを使う仕事を整理するための流れです。特定団体が定めた公式手順ではありません。

大切なのは、AIへ同じ依頼を何度も投げ直すことではありません。

検証で分かったことを使い、次のどれかを変えます。

  • 前提情報
  • 完了条件
  • 作業の分け方
  • 参考資料
  • 使用するモデルやツール
  • テスト方法
  • 人へ確認するタイミング

具体例: APIの500エラーを調査する

例えば、開発中のAPIで500エラーが発生したとします。

次の依頼だけでは、AIが不足した情報を推測で補いやすくなります。

このAPIのエラーを直してください。

最初に、調査と修正を分けます。

1. 事実を集める

  • 再現手順
  • HTTPメソッドとパス
  • 入力値
  • 期待した結果
  • 実際のレスポンス
  • スタックトレース
  • 直前の変更
  • 使用中のライブラリとバージョン

2. 完了条件を決める

  • 原因を説明できる
  • エラーを再現するテストがある
  • 修正後にテストが通る
  • 正常系を壊していない
  • ログへ秘密情報を出していない

3. AIへ調査を依頼する

次のテンプレートは、筆者が実務用に整理したものです。

# 目的
<!-- AIに何を終わらせてほしいかを書く -->
APIの500エラーについて、原因候補と切り分け手順を整理する。

# 確認済みの事実
<!-- 推測を混ぜず、ログや再現結果だけを書く -->
- POST /users で再現する
- レスポンスは HTTP 500
- PostgreSQLの一意制約違反がログに出ている

# 未確認事項
<!-- まだ調べていないことを明示する -->
- 同じメールアドレスを送ったときの仕様
- 例外処理の実装範囲

# 制約
<!-- 変更してはいけない範囲や安全条件を書く -->
- データベースのスキーマは変更しない
- 秘密情報や本番データは使わない
- 推測は事実と分けて書く

# 完了条件
<!-- 人が合否を判定できる条件を書く -->
- 原因候補を根拠付きで示す
- 確認順を番号付きで示す
- 再現テスト案を示す
- 修正による副作用を示す

# 出力形式
1. 確認済みの事実
2. 原因候補
3. 切り分け手順
4. テスト案
5. 修正時の注意点

4. AIの回答を別の手段で検証する

AIが「一意制約違反が原因」と答えても、それだけで修正を確定しません。

  • 実際のログと一致するか
  • テストで再現できるか
  • API仕様では409を返すべきか
  • 既存の例外処理と整合するか
  • 公式ドキュメントの現在の仕様と合うか
  • 修正後に単体テストと結合テストが通るか

ここまで確認して、初めて成果物へ反映します。

AIを使えば必ず速くなるわけではない

AIの利用時間が長いほど、生産性が上がるとは限りません。

METRが2025年初めに行った熟練オープンソース開発者の実験では、当時のAIツールを使った場合、対象タスクの完了時間が平均19%長くなりました。ただし、対象者とリポジトリが限定された研究であり、開発業務全体へ一般化できる結果ではありません。

さらにMETRは2026年2月、2025年後半のAIツールでは開発者が速くなった可能性が高い一方、AIなしでの作業を避ける参加者が増えたことなどによる選択バイアスがあり、正確な効果量を判断しにくいと報告しています。

つまり、「AIは速い」「AIは遅い」のどちらかで固定せず、 自分の仕事と現在のツールで測る 必要があります。

AI活用の効果を測る

「AIを使ったから効率化できた」という感想だけでは、改善したか判断できません。

筆者は、少なくとも次の項目を残すと比較しやすいと考えています。

項目 記録する内容
作業 何を完成させたか
AIの用途 調査、初稿、実装、テスト、レビューなど
生成時間 AIへの依頼と回答待ちに使った時間
確認時間 出典、コード、テストを確認した時間
修正時間 AI出力を直した時間
手戻り 誤った方向から戻すために使った時間
品質 テスト結果、指摘数、欠陥数、レビュー結果
再利用 テンプレートや手順として残せたか

実作業時間は、次のように考えます。

実作業時間 = 生成時間 + 確認時間 + 修正時間 + 手戻り時間

これは一般的な生産性指標ではなく、筆者がAI利用の見かけの速さに惑わされないために使う簡易的な計算です。

完成までの時間が短くなっても、欠陥やレビュー負担が増えていれば、全体では改善していない可能性があります。

疲れるまでAIを使わない

複数のAIを同時に動かすと、作業が速く進んでいるように感じます。しかし、人間が確認できる量を超えると、未確認の回答だけが積み上がります。

次は、筆者が継続して作業するために置いている実務上の目安です。医学的な基準ではありません。

  • 同時に監督するAI作業を増やしすぎない
  • 依頼前に停止条件と完了条件を決める
  • 生成する時間と、確認する時間を分ける
  • 判断が荒くなったら、新しい生成を止める
  • 重要な判断は時間を置いて見直す
  • 休憩、睡眠、運動を削ってAI作業を続けない

AI活用の目的は仕事を増やすことではなく、価値のある成果を持続的に作ることです。

従来の根性論との違い

以下は、この記事の主張を比較しやすくするために、筆者が独自に整理した表です。

従来の根性論 AI時代の知性の根性
長時間、手を動かし続ける 短い試行と検証を繰り返す
同じ方法を我慢して続ける 目的を保ち、方法を変える
与えられた作業をこなす 課題と完了条件を定義する
自分一人の作業量を増やす AIと人の役割を設計する
ミスを気合で埋め合わせる 原因を分解し、再発防止を仕組みにする
長時間労働を努力の証明にする 品質、時間、手戻りを測る
疲れても作業を続ける 認知負荷と停止条件を管理する

成果を決める要素

この記事の考えを概念的な式にすると、次のようになります。

成果 = AIの性能
     × 課題設定
     × 文脈の質
     × 作業分解
     × 検証
     × 改善の継続

これは研究で検証された数式ではなく、筆者独自の整理です。

AIの性能が高くても、解く問題が間違っていたり、完了条件がなかったり、確認せずに使ったりすれば、成果は不安定になります。

反対に、最初の回答が不十分でも、原因を確かめ、条件を直し、別の方法を試せば、少しずつ目的へ近づけます。

実務で確認するチェックリスト

依頼前

  • 解くべき課題を1文で説明できる
  • 完了条件を人が判定できる
  • AIへ入力してよい情報か確認した
  • 大きすぎる仕事を分割した
  • 事実と推測を分けた

回答後

  • 一次資料や公式ドキュメントを確認した
  • コードはテスト、静的解析、ビルドを通した
  • セキュリティ、個人情報、権限を確認した
  • AIを使っていない人にも説明できる
  • 修正理由と最終判断を記録した

振り返り

  • 実作業時間と手戻りを記録した
  • 次回も使える依頼文や手順を残した
  • AIに任せる範囲を広げるか狭めるか判断した
  • 新しい生成より確認を優先すべき状態になっていないか見直した

参考・確認先

関連記事

まとめ

  • AI時代に必要なのは、長時間労働ではなく、仮説、検証、改善を続ける力
  • AIは初稿の水準を上げやすいが、得意・不得意の境界は不規則
  • 人間は課題設定、作業分解、検証、統合、最終判断を担う
  • AIの効果は利用時間ではなく、品質、実作業時間、手戻り、再利用性で測る
  • 目的にかじりつきながら、方法と道具は柔軟に変える

おわりに

AIを仕事で使うときは、最初の回答の出来だけで判断せず、完了条件と検証方法を決めて、小さな改善を重ねることが大切です。

Wealthy Designでは、AIを使った業務改善やWebシステム開発に取り組んでいます。会社の取り組みは、会社サイトにまとめています。

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?