エンジニアの思考録

AIをどう活用するか──手放す作業と残す判断、作業者に戻らない使い方

AI を使えば仕事が楽になるのか、それとも自分の仕事がなくなるのか。同じ読者の中に、この二つの感覚が同居していることが珍しくありません。手を動かす時間は確かに短くなったのに、半年後の自分が安泰になった気はしない。むしろ「速く安くこなせる人」にカテゴライズされそうで、不安が先に立つ方も多いはずです。

シリーズ 1〜4 で、AI 時代の危機感、3 種類の AI 利用形態、API 課金の現実までを順に確認してきました。「AI に何ができるか」「AI を使うとどれくらいのコストがかかるか」までは見えてきたところで、次に必要になるのは「自分は AI をどう使うのか」という、目的側の整理です。ここがあいまいなままツールを増やしても、忙しさだけが増えていきます。

本記事は、AI ツールの使い方や具体的なプロンプト術ではなく、「自立するために AI をどう使うか」という活用目的の整理に的を絞ります。AI に手放してよい作業と、自分に残すべき判断を分け、AI を使っていても作業者ポジションに戻ってしまう構造を避ける、その第一歩を一本の地図にします。

論点の中心は、自分の時間の使い先を「作業」から「判断」へ寄せることです。空いた時間で何を増やすかが決まっていなければ、AI で空けた時間は別の作業で埋まってしまいます。ここを設計できる人だけが、AI を「自立のための道具」として使い続けられます。

本記事を読み終えると、自分の業務を「手放してよい作業」「残すべき判断」「価値の上がる業務整理スキル」の 3 層で見直す視点が手に入ります。続編「個人で作れる仕事の現実」へ進む前の、判断分離の地図として読んでください。なお、シリーズ既読読者は、入口記事 AIで速くなるエンジニア・遅くなるエンジニア|作業種別ごとの効率差 から戻って前提を確認できます。

はじめに

AI で仕事がなくなる不安と、AI で楽をしたい願望を同時に持っている読者は少なくありません。本記事は、その同居を「自立するために AI をどう使うか」という一本の問いに整理し直します。

シリーズ 1〜4 までで、AI を「使うか使わないか」の段階は通過しました。次に問われるのは「どう使えば自分が自立側に立てるか」です。AI を入れたのに作業者の位置から動けない人と、AI を入れて判断側に寄せていく人の差は、能力差ではなく目的設定の差として現れます。本記事は、この目的設定を言語化することに専念します。

シリーズ全体の前提が抜けていると感じた読者は、関連する解説として AIは誰でも使えるが成果を出せるのはエンジニアだけという現実AIは人類を救わない──問いを持たない者から知性は剥奪されていく を併読することで、本記事の判断分離の議論がより明確になります。

自立するためにAIをどう活用するか

AI を使う第一の目的は、楽をすることではなく、自分が判断に時間を使える状態を作ることです。自立を目指す読者が AI を「作業代行」ではなく「仕組み化の手段」として扱う理由を、本セクションで提示します。

図 1: AI を作業代行に使う構造と、仕組み化に使う構造の対比。判断時間を増やす設計が自立の前提になる

AIを使う目的は楽をすることではありません

短期的な楽さを目的に AI を使うと、安く速くできる作業を抱え続けるだけのポジションに固定されます。自立を目指すなら目的は『楽』ではなく『時間の使い方を変える』ことに置きます。

楽をすること自体が悪いわけではありません。問題は、楽になった分の時間を、また別の作業で埋め戻してしまう構造です。AI で 1 時間短くなった作業の枠に、新しい作業案件を詰める働き方では、自分の市場価値の輪郭は変わりません。むしろ「速く安くこなせる人」というラベルだけが強化されていきます。

楽をするための AI 活用は、雇われる側の発想で完結します。自立側に立つ AI 活用は、空いた時間に何を入れるかをセットで設計する発想です。後者を選ぶには、まず「楽になった先に増やすもの」を先に決めておく必要があります。

作業を減らして判断に時間を使うことが重要です

AI で空けるべきは『自分しか判断できない領域』に投じる時間です。減らすべき作業と、減らした時間で増やすべき判断業務をセットで設計します。

判断業務とは、仕様を決める、責任分界を決める、業務をどこまで自動化するかを選ぶ、といった「正解が外にない」仕事です。これらは AI が叩き台を出してくれても、最終的な決定とその責任は人間に残ります。だからこそ、ここに使える時間が長い人ほど、自分の判断で動ける範囲が広がります。

設計のコツは、減らした時間の使い先を先に決めておくことです。空いた時間がそのまま別作業で埋まるのは、判断業務が「いつかやるもの」のままになっているからです。週次・日次のスケジュール上に、判断業務の枠を先取りで置いてしまうと、AI で空けた時間が判断時間に流れ込みやすくなります。

自立する人はAIを作業代行ではなく仕組み化に使います

『人がやっていた作業を AI に置き換える』発想ではなく、『業務全体の入出力を見直して仕組みを作り替える』発想で AI を使う人が、自立側に残ります。

作業代行型の AI 活用は、既存の作業手順をそのままにして、一部の手作業を AI に置き換えるアプローチです。短期では速くなりますが、業務構造そのものは変わりません。一方、仕組み化型は、業務全体の入出力を分解し直し、人がやるところと AI がやるところを再配置するアプローチです。後者には、業務を分解できるスキルが前提として必要になります。

この「業務を分解する力」は、シリーズ最終記事で扱う「仕事化」(商品化・受注メニュー設計) の前段に位置します。本記事ではここを「自立に必要な土台スキル」として位置づけ、具体的な棚卸し手順や商品化の話には踏み込みません。土台が固まっていない段階で商品化を急ぐと、結局は作業案件をかき集めるだけで終わるためです。

AIに手放していい作業を見極める

手放してよい作業の共通点は『入出力が決まっていて検証が容易、取り消し可能』であることです。本セクションでは AI に渡しやすい作業の典型を示し、それを抱え続けるリスクを言語化します。

図 2: 入出力が決まり検証容易な作業は AI に渡し、文脈・責任・主観が絡む判断は自分に残す

要約・分類・初稿・変換はAIに渡しやすい作業です

形式が決まり、検証が形式チェックで済み、結果を取り消せる作業は AI に渡せます。要約・分類・初稿・変換は典型例で、自分の時間を投じる価値が低い領域です。

要約は「元の文章の主要点が抜けていないか」、分類は「カテゴリ定義に沿っているか」、初稿は「構成と必要要素が揃っているか」、変換は「フォーマットが正しいか」で検証できます。いずれも判定基準が外側にあり、間違っていてもやり直しが効きます。これらは AI が苦手としていた領域でもなくなりつつあり、人間が時間をかけて手作業でこなす理由が薄くなっています。

ここで重要なのは「速くこなせるから渡す」ではなく「自分の時間の使い先として優先度が低いから渡す」と捉え直すことです。前者の発想に留まると、後述するように、速くこなせる作業を抱え続けるだけの位置に戻ってしまいます。

入出力が決まっている作業は自分の価値にしない

入出力が固定された作業はそのまま AI で代替可能になります。『速くこなせる』を価値の中心にすると、AI の進化に合わせて自分の市場価値が削られていきます。

入力フォーマットと出力フォーマットが決まっている作業は、AI モデルが進化するたびに代替コストが下がっていきます。今は人間がやるほうが安定している作業も、半年後には AI 単体で十分なクオリティが出るようになる可能性があります。この領域に自分の価値を置いていると、AI の性能向上が、そのまま自分の単価下落として跳ね返ります。

業務委託・外注削減のシグナルは、すでにクラウドソーシング市場の縮小として現れています。発注側は「速く安くできる人を集める」のではなく、「AI に直接やらせる」方向へ動きはじめています。入出力が決まっている作業を価値の中心に置く戦略は、この潮流の逆を進む選択になります。

速くなる作業を抱え続けると作業者に戻ります

AI で速くなった作業を案件として大量に抱える働き方は、AI 代行屋・低単価作業者の位置に戻る入口です。速くなった分の時間を、判断業務に振り向ける設計が必要です。

「AI で速くできるようになったから、これまでの 3 倍の案件を受けられる」という考え方は、ロジックとしては成り立ちます。しかしこのルートは、案件数の増加が AI 化された競合との価格競争に重なる構造を持っており、長期的には単価が下がり続けます。同じ働き方を続ける限り、AI が進化するほど自分の収益が圧縮されていきます。

抜け出す方向は、案件数を増やすのではなく、案件 1 件あたりに自分が判断として関わる範囲を広げることです。仕様調整・要件分解・運用設計など、人間が責任を持つ領域に時間を寄せていくと、AI の進化はそのまま自分の生産性向上として効きます。

自分に残すべき判断を見極める

残すべきは、文脈・責任・主観が絡み、AI に任せると致命的になる判断です。本セクションでは『仕様』『責任分界』『業務整理と自動化対象選定』の 3 つを、自立の土台として位置づけます。

仕様を決める判断は手放してはいけません

仕様の前提誤りは、後工程の作業すべてに伝播します。AI には叩き台までは作れても、最終的に何を作るかを決める判断は、顧客と自分の間に残し続ける必要があります。

仕様判断の難しさは、「正しい仕様が外側に存在しない」ことです。顧客の要望、業務の制約、運用の現実、関係者の合意点、これらをすり合わせながら定義していく作業は、文脈の総合判断であり、AI が叩き台として出した仕様をそのまま採用するのは危険です。叩き台を起点に、人間がもう一段意思決定を入れる工程を必ず挟む必要があります。

ここを「面倒だから AI に任せる」方向に倒すと、後工程の実装・テスト・運用すべてが歪んだ前提の上に乗ります。仕様の歪みは後で気づくほど修正コストが高く、最終的に責任を取るのは人間側です。AI を関与させるのは構いませんが、決めるのは自分という線は手放してはいけません。

責任分界を決める判断は自立の土台になります

誰がどこまで責任を持つかの設計は、契約・検収・運用すべての前提です。責任分界を握れる人だけが、自分の判断で AI を業務に組み込めるようになります。

責任分界とは、「ここまでは自分が責任を負う」「ここから先は顧客側の意思決定」「この範囲は AI 出力を採用したことの責任を自分が引き受ける」といった線引きです。これが曖昧なまま AI を業務に組み込むと、出力の不具合や誤判定が発生したときに、責任が漂流します。SES 現場や受託案件で AI 利用に強い制約がかかるのも、この責任分界が定まらないことが大きな理由です。

責任分界を自分で設計できる人は、契約や検収の局面で自分の言葉を持てます。逆に、誰かが決めた線の中でだけ AI を使う立場では、AI を入れた効果も誰かが決めた範囲に閉じ込められます。自立とは、この線引きを自分で引ける状態のことです。

業務整理と自動化対象選定は次の仕事につながります

業務を入出力単位に分解し、どこを AI に渡すかを選ぶスキルは、そのまま次の仕事の入り口になります。本記事ではスキル定義までを扱い、商品化の詳細はシリーズ最終記事へ譲ります。

業務整理スキルとは、ある業務を「入力 → 処理 → 出力」の単位で分解し、それぞれの工程に対して「人がやるべき理由があるか」「AI に渡せるか」「渡すならどんな前提条件と検証が必要か」を判定できる力です。これは AI 活用の前段スキルでありながら、それ自体が顧客に提供できる価値でもあります。

自動化対象の選定とは、業務全体のうちどこに AI を入れると最もレバレッジが効くかを見極める判断です。多くの現場で「AI を入れたが効果が出ない」と言われる原因は、選定が現場の都合 (やりやすい工程から入れる) で決まっていて、効果の出る工程に入っていないことです。この選定眼を持てるかどうかが、AI 時代に判断側へ立てるかの分岐になります。本記事ではここまでを土台として位置づけ、商品化や受注メニュー化の話はシリーズ最終記事に譲ります。

AIを使っても作業者に戻る人の特徴

AI を使っているのに自立から遠ざかる人には、共通の構造があります。AI 代行屋化・何でも屋化・判断を持たない使い方の 3 つを、本セクションで言語化します。

図 3: AI 代行屋・何でも屋・判断を持たない AI 活用の 3 パターンが、自立から遠ざかる構造を作る

AI代行屋になると低単価競争に巻き込まれます

『AI で安く速く作ります』を売りにすると、同じ売りを持つ人と価格で競い続けることになります。クラウドワークスやランサーズの市場縮小は、この位置の縮小を裏付けるシグナルです。

AI 代行屋とは、「AI を使って従来作業を安く速く提供する」ポジションです。これは AI を導入しているという意味では先進的に見えますが、競合も同じ AI を使えるため、差別化軸が「価格」と「納期」だけに収束していきます。AI モデルが共通である以上、出力品質での差別化も限定的です。

クラウドソーシング市場でこの位置のプレイヤーが減ってきている事実は、市場側がこの位置の必要性を下げていることを示しています。発注者は、安く速くやってくれる人を探すよりも、AI に直接出させて自分で検収する方向に移っています。AI 代行屋を売りに据える戦略は、市場の流れに逆行します。

何でも屋になると自分の軸が消えます

AI で何でもできるようになるほど、何を引き受けるかの判断が重くなります。何でも屋に振れると差別化軸が消え、結果として価格でしか選ばれなくなります。

AI を使うと、これまで自分の専門外だった領域も「やればできる」状態になります。ここで「全部受ける」と決めてしまうと、何を強みにしている人なのかが顧客から見えなくなります。顧客側は「この人にしか頼めない理由」を見つけられず、最終的には価格で意思決定します。

差別化を保つには、「やらない領域」を決める必要があります。AI で広がった守備範囲のうち、自分が判断責任を持って引き受ける領域はどこか、AI に渡せる作業として副次的に提供する領域はどこか、そして引き受けない領域はどこか、この線引きを持っている人が、軸を失わずに済みます。何でも屋への漂流は、引き受け基準を持たないことから始まります。

断を持たないAI活用は自立につながりません

AI 出力の検証や、自動化対象の選定を『お任せ』にしている限り、判断責任は外側に残り、自分の市場価値は積み上がりません。

AI 出力を検証せずにそのまま納品する働き方は、検収の責任を顧客側に押し戻している状態です。これは短期では速く回りますが、不具合が発生したときの責任の所在があいまいになり、再発注の機会を失います。検証工程を自分が担保していることが、AI 時代の信頼の中身になっていきます。

自動化対象の選定を顧客や上司に任せている場合も同じ構造です。「どこに AI を入れるか」を決めない人は、決まった範囲で AI を回す作業者の位置から動けません。判断を持たない AI 活用は、AI を使っているように見えて、実際には作業者ポジションを補強し続けます。自立を目指すなら、検証と選定の判断責任は自分側に置く必要があります。

次に考えるべきこと

作業と判断を分けたあとに必要なのは、それを『個人で作れる仕事』として成立させる視点です。本記事は分け方までを扱い、次の記事で個人開発・個人サービスの現実を確認する導線を引きます。

分けた作業と判断を個人で作れる仕事につなげる

残した判断業務は、そのまま受注メニューや個人サービスの軸に転用できます。本記事ではその転用を『次の記事で扱う』と位置づけ、ここでは方向だけ示します。

仕様策定の判断、責任分界の設計、業務整理と自動化対象の選定、これらは個人で提供できる業務です。重要なのは、これらを「作業の付帯サービス」ではなく「主業務」として位置づけることです。主業務として置けば、AI で速くなった作業はあくまで自分の生産性を支える裏方になり、提供価値の中心は判断側に固定されます。

転用の具体的な進め方、商品化の候補、受注導線の作り方は、シリーズ最終記事の領域です。本記事の段階では、「残した判断は次の仕事の素材になる」という方向感を持って次の記事に進めれば十分です。業務分解や自動化対象の選定について実務上の相談が必要な場合は、Be エンジニアのお問い合わせフォームよりご相談いただけます。

次の記事で個人開発・個人サービスの現実を確認する

次記事『個人で作れる仕事の現実』では、個人開発と個人サービスをどう成立させるかを扱います。本記事の判断分離を前提に、現実の成立条件を読み解いてください。

個人で作れる仕事と一口に言っても、個人開発 (プロダクト販売)、個人サービス (受注業務)、コンテンツ販売、コミュニティ運営など、収益経路は分かれます。それぞれに成立条件が異なり、本記事で整理した「残した判断」をどの経路に乗せるかで難易度も変わります。次の記事では、この経路ごとの現実を確認します。

シリーズ既読読者向けに、入口記事 AIで速くなるエンジニア・遅くなるエンジニア|作業種別ごとの効率差 からの戻りや、関連解説の AIは誰でも使えるが成果を出せるのはエンジニアだけという現実AIは人類を救わない──問いを持たない者から知性は剥奪されていく を並べて読むと、本記事の位置づけがより明確になります。

まとめ

本記事の論点は『自立するために AI をどう活用するか』の 1 点です。AI に手放してよい作業と、自分に残すべき判断を分け、AI を使っても作業者ポジションに戻らない使い方を整える、ここまでが第一歩です。

AI を「作業代行」として使う限り、楽になった時間は別の作業で埋まり、自分の位置は変わりません。自立側に立つには、AI を「仕組み化の手段」として扱い、空いた時間を仕様判断・責任分界・業務整理に振り向ける設計が必要です。手放してよい作業の典型は要約・分類・初稿・変換、残すべき判断は仕様・責任分界・業務整理と自動化対象選定でした。AI 代行屋・何でも屋・判断を持たない使い方の 3 パターンは、AI を使っていても作業者に戻る入口です。

次の記事では、この判断分離を前提に、個人開発と個人サービスの現実をどう成立させるかを扱います。本記事で整理した「残した判断」をどの経路に乗せるかが、自立の具体的な形を決めます。

よく読まれている記事

1

「私たちが日々利用しているスマートフォンやインターネット、そしてスーパーコンピュータやクラウドサービス――これらの多くがLinuxの力で動いていることをご存じですか? 無料で使えるだけでなく、高い柔軟 ...

2

Linux環境でよく目にする「Vim」という名前。サーバーにログインしたら突然Vimが開いてしまい、「どうやって入力するの?」「保存や終了ができない!」と困った経験をした人も多いのではないでしょうか。 ...

3

ネットワーク技術は現代のITインフラにおいて不可欠な要素となっています。しかし、ネットワークを深く理解するためには、その基本となる「プロトコル」と「レイヤ」の概念をしっかり把握することが重要です。 こ ...

4

この記事は、Linuxについて勉強している初心者の方向けに「Shellスクリプト」について解説します。最後まで読んで頂けましたら、Shellスクリプトはどのような役割を担っているのか?を理解出来るよう ...

5

Javaは世界中で広く使われているプログラミング言語であり、特に業務システムやWebアプリケーションの開発において欠かせない存在です。本記事では、初心者向けにJavaの基礎知識を網羅し、環境構築から基 ...

-エンジニアの思考録