エンジニアの AI 活用と聞いて、多くの人が最初に思い浮かべるのはコード生成でしょう。実際、AI にコードを書かせる体験は衝撃的で、そこから活用を始めた方も多いはずです。ただ、開発の現場で一日の仕事を振り返ってみると、コードを書いている時間は仕事全体の一部にすぎません。仕様やエラーの原因を調べる時間、設計を考える時間、動作を確かめる時間、ドキュメントを残す時間──エンジニアの仕事はこうした工程の集合であり、AI が効くのは「書く」工程だけではなく、そのすべてです。コーディング支援だけを見ていると、活用の大半を取りこぼします。この記事では、エンジニアの仕事を 5 つの工程に分けて任せどころを整理し、どの職種にも共通する任せ方の型、アプリ開発・インフラ・QA・非エンジニアそれぞれの主戦場、そして導入後に必ず直面する「速くなったのに品質が落ちた」を防ぐ確認の設計まで、実務の順番で解説します。
- エンジニアの仕事は調べる・設計する・書く・確かめる・残すの 5 工程で捉える ── AI が効くのは「書く」だけではない
- どの職種にも共通する任せ方の型は 3 つ ──渡せる形に分ける・合格条件を先に決める・渡し方を文書にする
- 主戦場は職種で違う ──アプリ開発・インフラ・QA・非エンジニアそれぞれに効きどころがある
- 出力が速くなった分だけ確認を設計する ── ここを省くと、速くなったのに品質が落ちる
エンジニアの仕事を 5 工程で捉える ── AI の任せどころの地図
最初にやるべきことは、ツールの選定ではなく、自分(またはチーム)の仕事の分解です。エンジニアの仕事は、おおまかに次の 5 つの工程に分けられます。
- ①調べる ── エラーの原因を切り分ける、ライブラリや API の仕様を確認する、既存コードの構造を読み解く。開発の中で意外なほど大きな時間を占める工程です。
- ②設計する ── 実現方法の選択肢を並べ、構成やデータの持ち方を決める。ここでの判断が、後続のすべての工程の品質を左右します。
- ③書く ── 実装・修正・リファクタリング。AI 活用の話題で最初に語られる工程ですが、仕事全体から見れば一部です。
- ④確かめる ── コードレビュー、テスト、実機での動作確認。出したものが意図どおりかを保証する工程です。
- ⑤残す ── 仕様書・手順書・コメント・引き継ぎ資料。後回しにされやすく、そのくせ後で一番効いてくる工程です。
この分解をすると、各工程で「AI に渡せる作業」と「人が握るべき判断」が見えてきます。ポイントは、どの工程にも渡せる作業がある一方で、どの工程にも人が手放してはいけない判断があることです。次の表が、この記事全体の地図になります。
| 工程 | AI に渡せる作業の例 | 人が握ること |
|---|---|---|
| ① 調べる | エラーの切り分けの相談、ライブラリ比較の下調べ、既存コードの読解と要約 | 情報の採否 ── 古い情報・誤った前提の見極め |
| ② 設計する | 選択肢の洗い出し、トレードオフの整理、設計案への壁打ち | 決定 ── 何を作り、何を作らないか |
| ③ 書く | 実装、定型コード、テストコードの生成、リファクタリング | 変更の単位と順序、コードの合格条件 |
| ④ 確かめる | 観点に沿った一次レビュー、テスト観点の洗い出し | 設計意図との一致の判断、実機での最終確認 |
| ⑤ 残す | コードからの仕様書起こし、手順書・コメントの下書き | 何を残すかの取捨、内容の最終確認 |
この地図を持つと、AI 活用の進め方が「ツールで何ができるか」から「自分の仕事のどこを渡すか」に変わります。たとえば「今週は①調べる工程の既存コード読解を渡してみる」というように、小さく区切って試せる単位が手に入るからです。私たち自身がコーディング支援ツールをどの作業に使っているかの具体は「Claude Code でできること【自社実例つき】」で公開しているので、①〜⑤の実例として合わせてご覧ください。
どの職種にも共通する、任せ方の 3 つの型
工程の地図ができたら、次は任せ方です。使うツールや職種が違っても、AI に仕事を渡すときにうまくいく型は共通しています。私たちが自社の開発と研修の両方で繰り返し確かめてきた型は、次の 3 つです。
型 1 ── 仕事を「渡せる形」に分ける
AI への依頼がうまくいかない典型は、大きな塊のまま渡すことです。「この機能を作って」と一言で渡すと、AI は足りない前提を自分で補って進めるため、出てきたものが意図とずれます。うまく渡している人は、依頼を目的が 1 つに絞られたサイズまで分けています。「この画面に入力チェックを足す」「この関数のエラー処理を統一する」──このサイズなら、前提の説明も短くて済み、出力の確認も短時間で終わります。分けること自体が設計の訓練になるという副産物もあります。渡せる形に分けられない仕事は、実は人に引き継ぐこともできない仕事です。
型 2 ── 合格条件を先に決める
2 つ目の型は、依頼を出す前に「何ができていたら合格か」を決めておくことです。出力を見てから良し悪しを考えると、もっともらしい出力に判断が引っ張られます。逆に、「この入力のときこう動けば合格」「この規約に沿っていれば合格」を先に言葉にしておくと、確認は照合作業になり、速く、ぶれなくなります。合格条件を書く場所は、依頼文の中でかまいません。「完了の条件は次の 3 つ」と箇条書きで添えるだけで、AI の出力の的中率と、人の確認の速度が同時に上がります。
型 3 ── 渡し方を文書にする
3 つ目は、うまくいった渡し方を口頭や個人のメモで終わらせず、文書にすることです。前提・やってほしいこと・判断に迷ったときの基準・やってはいけないこと──この構造で書いておくと、同じ依頼を繰り返すときに毎回説明し直す必要がなくなり、チームの誰が渡しても同じ品質が出るようになります。書き方の具体的な型は「AIに渡す手順書の書き方 ── 判断基準・禁止事項・出力形式をどう文章にするか」で詳しく解説しています。この文書化は後半の「チームに広げる」の土台にもなる、地味ですが効きの大きい型です。
職種別の主戦場 ── どの工程から任せるか
5 工程の地図と任せ方の型は共通ですが、どの工程が主戦場になるかは職種で違います。「エンジニアの AI 活用」を一枚岩で語ると、コードをあまり書かない職種が「自分には関係ない」と感じてしまう──これが活用が広がらない一因です。職種ごとの効きどころを整理します。
コード生成の恩恵を最も受けやすい職種ですが、実は伸びしろは「書く」の前後にあります。手前では、既存コードの読解と要約──入ったばかりのプロジェクトのコードベースを AI に説明させると、把握までの時間が大きく変わります。後ろでは、テストコードの生成と一次レビュー──自分の書いたコードを別の目で確かめる相手として使えます。「書かせて終わり」から「調べる・確かめるまで含めて分担する」へ移ると、活用の景色が変わります。
書くコードの量は多くない職種ですが、AI の効きどころはむしろ豊富です。設定ファイルの意味の読み解き、構成変更の影響範囲の整理、障害時のログからの切り分けの壁打ち、そして手順書の下書き──いずれも「構成を言葉にする」仕事であり、AI が得意とする領域です。一方で、本番環境に触る操作の実行判断は必ず人が握ります。「調べる」と「残す」を渡し、「実行する」を渡さない──この線引きがそのまま、この職種の活用の型になります。
QA の仕事の価値は「どこにリスクが潜んでいるか」を見抜く観点にあります。AI は、仕様からのテスト観点の洗い出し、テストケースの下書き、バグ報告の再現手順の整理といった網羅と下書きで力を発揮します。人の見落としがちな境界条件を AI が挙げ、AI が知らない業務文脈のリスクを人が足す──両者の観点は重なりが小さいため、組み合わせの効果が出やすい職種です。品質の合否判定そのものは、これまでどおり人の仕事です。
検索でも「非エンジニアの AI 活用」が調べられているとおり、この変化は開発職の外にも及んでいます。要望を仕様の形に言語化する、システムの挙動について一次調査をする、日々の集計を小さなスクリプトで自動化する──従来はエンジニアに依頼していた仕事の一部を、AI の助けを借りて自分で進められるようになりました。ただし、作ったものを業務で使い続けるには、エンジニア側が確認とレビューの受け皿を用意することが条件です。丸投げでも丸抱えでもない、新しい分担の形がここにあります。
この 4 つの職種は、検索の隣接語(インフラ・QA・非エンジニアなど)が示すとおり、それぞれ独立した深掘りに値するテーマです。本記事は全体の地図として、職種ごとの具体的な進め方は今後の記事で個別に掘り下げていく予定です。
「速くなったのに品質が落ちた」を防ぐ ── 確認の設計
ここまで前向きな話を書いてきましたが、導入後に多くのチームが直面する問題を正面から扱っておきます。それは、出力の速さに確認が追いつかなくなることです。AI はコードも文書も、人が書くよりはるかに速く出します。確認のやり方を変えないままだと、確認が積み残り、「よく見ずに通す」が始まります。結果として、書く速度は上がったのに、品質はむしろ下がる──これは AI の性能の問題ではなく、確認の設計を出力の速さに合わせて作り直していないことによる問題です。だからこそ、設計で避けられます。処方は 3 つです。
- ①変更を小さく刻む ── 一度に大きな変更をさせない。型 1 の「渡せる形に分ける」は、実は確認のための処方でもあります。差分が小さければ、確認は速く、確実になります。大きな差分の確認は、どれほど熟練したエンジニアでも精度が落ちます。
- ②確認を 2 段に分ける ── コードの差分を読む確認と、実際に動かして挙動を見る確認は、役割が違います。差分では設計意図とのずれを、実動作では想定外の挙動を見る──型 2 で決めた合格条件をこの 2 段に割り当てておくと、「全部を読み込まないと不安」から抜け出せます。
- ③直しすぎない ── 出力が意図とずれたとき、細かい修正指示を何往復も重ねるより、前提を整えて最初からやり直させるほうが速く、きれいに仕上がることが多くあります。往復が 3 回を超えたら、依頼の出し方(分け方・合格条件)に戻る──この引き際をチームで決めておきます。
もう 1 つ、AI の出力には事実と異なる内容がもっともらしく混ざることがある、という性質も確認の設計に織り込む必要があります。調べる工程で AI が返した情報をそのまま採用しない、根拠を出典で確かめる──この「誤りが混ざる前提の業務設計」は「生成AIのハルシネーション対策 ── 誤りを「事故」にしない業務側の設計」で体系的に整理しています。速さの恩恵を受け取りながら品質を守る鍵は、ツールの選定ではなく、この確認の設計にあります。
個人の活用で終わらせない ── チームの型にする
最後のステップは、活用を個人の腕前で終わらせないことです。多くの開発組織で起きているのは、「一部のメンバーはものすごく使いこなしているが、チーム全体では広がっていない」という状態です。この差は本人の才能の差に見えますが、実際には渡し方の工夫が個人の中に溜まっているか、チームの型として共有されているかの差であることがほとんどです。共有するものは 3 つあります。第一に、型 3 で作った渡し方の文書──依頼の前提・判断基準・禁止事項をチームの共有物にします。第二に、うまくいった依頼の実例──成功した依頼文はそのままチームの教材になります。第三に、確認の基準──前章の「どこまで確認したら通すか」を個人の裁量からチームの決めごとに変えます。
この 3 つが揃うと、新しいメンバーが入ったときにも同じ品質で AI との分担が回るようになり、活用が属人技から組織の力に変わります。私たち Livune も、自社の開発でこの型──仕事を分け、合格条件を先に決め、渡し方を文書にし、確認を 2 段で回す──を毎日実践しており、その実践知をもとに企業のエンジニア組織向けの AI 駆動開発研修を提供しています。研修で一貫して大切にしているのは、ツールの操作を教えることではなく、受講したエンジニアが自分の業務で使い続けられる「型」を持ち帰ってもらうことです。
Livune は、この記事の型──仕事を 5 工程で分け、合格条件を決め、確認を設計する──を自社の開発で毎日実践し、企業のエンジニア組織向けに AI 駆動開発研修を提供している会社です。ツールの紹介で終わらない、業務に定着する活用をご一緒します。
Livune の AI 導入支援・研修を見る →よくある質問
仕事がなくなるのではなく、工程の配分が変わると私たちは考えています。「書く」工程の比重が下がる一方で、何を作るかを決める「設計する」、出力が意図どおりかを保証する「確かめる」の重要度は上がります。本文の表のとおり、どの工程にも人が握るべき判断が残っており、その判断の質こそがエンジニアの価値になっていきます。
関われる範囲は確実に広がっています。要望の言語化・一次調査・小さな自動化などは、非エンジニアでも AI の助けを借りて進められるようになりました。ただし、作ったものを業務で使い続けるには、動作の確認やコードのレビューといった受け皿をエンジニア側に用意することが条件です。個人の試行と業務利用の間に、確認という橋を架けることをおすすめします。
「一番人気のツール」から入るより、本文の 5 工程のどこを渡したいかを先に決めることをおすすめします。渡したい工程が決まれば、必要な機能(コード生成・コードベースの読解・対話での壁打ちなど)が絞られ、候補は自然に狭まります。そのうえで、小さな実務で試して自分たちの業務での使い勝手を確かめてから広げる──この順番なら、選定を間違えても傷が浅く済みます。
確認すべき点が 2 つあります。1 つは契約条件──業務利用では、入力したコードやデータが AI の学習に使われない設定・プランになっているかをツールごとに確認してください。もう 1 つは社内の線引き──入力してよいコード・情報の範囲をルールとして明文化しておくことです。リスクを理由に全面禁止にするのではなく、安心して使える範囲を決めることが、安全と活用を両立させる現実的な方法です。