--- title: "AIに仕事を奪われる側から使う側へ【非エンジニアの行動差】" description: "AIに仕事を奪われる側と使う側の違いを、非エンジニアの行動から考えます。確認済みの開発事例と架空の業務例を分け、題材選び、完成条件、答え合わせ、翌回も使える仕組みの残し方を解説。" url: "https://shiftb.dev/articles/ai-work-builders-non-engineer" publishedAt: "2026-09-23" updatedAt: "2026-09-23" author: "立川修平（ぶべ）" category: "career" tags: ["AI活用", "非エンジニア", "業務改善", "キャリア"] --- # AIに仕事を奪われる側から使う側へ【非エンジニアの行動差】 AIで報告書の文章は早く書けた。でも、その材料を探し、表へ転記し、数字の間違いを直す仕事は、翌週も残っている。僕が開発・運営するVibelyは、ShiftBの社内ツールから始まり、教材管理や受講生の進捗管理を形にしてから外部向けのサービスへ広げました。身近な仕事を仕組みにすることは、営業・企画・事務の現場でも出発点になります。 「AIに仕事を奪われる側と使う側」を、才能や職種で決まる二分法にはしたくありません。この記事では、非エンジニアが今の仕事を続けながら、AIに答えをもらった先で何を作り、どう確かめ、次の仕事へ残すかを扱います。実在する事例と説明用の架空例を分け、行動の違いを具体化します。 ## AIに仕事を奪われるかを、職種だけで決めない ### 作業の自動化と、仕事がなくなることは別に考える 営業の仕事には、商談メモの整理、提案資料の作成、条件の調整、顧客への説明が含まれます。文章を生成できるだけでは、相手に何を約束してよいかは決まりません。「営業は残る」「事務はなくなる」と職種名だけで判断すると、自分が変えられる作業が見えなくなります。 国際労働機関（ILO）の[生成AIと仕事に関する研究](https://www.ilo.org/publications/generative-ai-and-jobs-refined-global-index-occupational-exposure)も、職業を構成する個々の作業から影響を評価しています。多くの職業には人の関与を要する作業が含まれ、生成AIの影響として仕事の変容が有力だとしています。これは個人の雇用を保証する話でも、誰が失業するかを言い当てる研究でもありません。 自分の仕事について考えるなら、まず「入力された内容を整える部分」「条件を決める部分」「結果を確認して相手へ渡す部分」に分けます。AIに任せる候補を探しつつ、任せた後に自分が何を判断するかまで書く。職種の将来予測を読むだけでは決まらなかった、次の行動がここで決まります。 ### 「作れるか」は、仕事を変えるための行動の指標 この記事でいう「作れる」は、ゼロからコードを暗記して書けることに限りません。自分の仕事で使う入力、処理の条件、出力を決め、動く形にして、結果を確かめ、必要に応じて直せることです。既存の機能を設定するだけで済むなら、その方法で構いません。アプリを増やすこと自体が目的ではないからです。 ただし、作れる人でも、会社の事業や人員配置の影響を受けます。「AIを使えば仕事は絶対に奪われない」という結論にはできません。ここで扱うのは雇用の安全度ではなく、自分の担当業務の改善に関われる範囲を広げるやり方です。AIの導入を決める権限がない人は、試作の相談や完成条件の整理から参加できます。 ## 校長として見る「作れる」の中身 ### 実在するのは、身近な課題を形にした事例 Vibelyは、社内で使う教材管理や進捗管理などの機能から始まったサービスです。最初から一般向けの大きな製品を想定するより、自分たちが使う対象を具体化したことが出発点でした。非エンジニアの業務でも、「部署全体をAI化する」より「毎回の転記を減らす」の方が、完成品の姿と答え合わせの方法を決めやすくなります。 公開済みの受講生事例には、元営業職のAさんが議事録自動化ツールを開発した例があります。ここから言えるのは、営業の経験に近い題材をツールにしたという事実です。削減時間や社内評価、雇用への効果までは、この事例から断定しません。僕が校長として重視するのは、知っている仕事を題材に、使えるものを作るところまで進めることです。 ### 行動の差は「翌回に何が残ったか」で見る 例えば、会議のたびにAIへ要約を頼み、毎回手で見出しを直す使い方を考えます。次の会議にも同じ直しが必要なら、残っている作業は見出しをそろえる部分です。別の進め方では、決定事項、担当者、期限の欄を決め、材料がない欄を勝手に埋めないルールと、確認する手順を残します。翌回は、新しいメモで同じ手順を試せます。 この対比は説明用の架空例で、受講生を比較した調査ではありません。見る対象はAIへの質問回数やツール名ではなく、次回も使う処理と確認方法が残ったかどうかです。毎回説明し直しているなら依頼文を保存し、同じ修正が続くなら条件へ加え、他人が使えないなら手順を短く書く。残った手作業が、次に作る対象を教えてくれます。 「何を残せば改善になるか」が言葉にできない段階では、ツールを増やしても題材は決まりません。AIシフトコースの無料相談会は、今の仕事から学習の題材を選び、どこまで作ることを目指すかを整理する入口にできます。 ## 行動1・2：繰り返す作業を選び、完成条件を書く ### 行動1：自分で正解を確かめられる作業を選ぶ 日常業務を「週報作成」のような名前で書いたら、その下に実際の操作を並べます。案件一覧を開く、期限を過ぎた案件を探す、担当者別に並べる、共有用の文章にする。そのうち、自分で正しい結果を説明でき、失敗しても原本へ影響しない部分を最初に選びます。この例なら、架空の一覧から期限超過の案件を抽出するところまでです。 選ぶときにつまずきやすいのは、「簡単そう」と「正解が決まっている」を混同することです。催促文は短くても、送る相手や言い方の判断を伴います。対して一覧の抽出は、期限と状態の条件を決めれば照合できます。最初は顧客への送信、請求、元データの更新を含めず、結果を人が見て確かめる範囲に絞ります。 AIへ情報を渡す前には、会社で認められたアカウント、入力できる情報、相談先を確認します。Claude Codeの[データ利用の説明](https://code.claude.com/docs/en/data-usage)では、個人向けと商用契約でモデル改善への利用条件が異なります。有料契約かどうかだけで判断せず、契約・設定・社内規程を確認してください。練習には、実際の顧客情報を書き換えたものではなく、最初から作った架空データを使います。 ### 行動2：依頼する前に、完成条件を自分で書く 悪い依頼例は「案件管理をAIで便利にして」です。便利の中身がないため、画面や通知が増えても、減らしたかった作業に届くか判断できません。良い依頼例では、入力、選ぶ条件、出力、やらない操作を具体化します。次は、後の表にある架空データを使う練習用の依頼文です。 ``` 架空の案件一覧を使い、期限超過の確認表を作りたいです。 入力はID、期限、状態。基準日は2026年9月23日です。 期限が基準日より前で、状態が「未対応」の行だけを選びます。 期限が空欄なら推測せず、別の「要確認」一覧へ出してください。 最初に、この条件で出るはずのIDと理由を説明してください。 その後、同じ形式の一覧で繰り返し使える小さなツールを作ります。 元データの変更、メール送信、実在の社内システムとの連携はしません。 ``` Claude Codeは、会話に沿ってファイルを読み、編集し、コマンドを実行できる開発ツールです（[公式の概要](https://code.claude.com/docs/en/overview)）。この依頼文は実行結果を保証するものではなく、何を作るかを合意するための例です。画面の見た目を先に作ると、肝心の抽出条件が曖昧なまま進むため、まず出るはずの結果を言葉で合わせます。 自分で決めるのは、期限当日を含めるか、完了した案件を除くか、空欄をどう扱うかです。ここに現場の知識を使います。AIが提案した条件を採用する場合も、普段の業務ルールと一致しているかを担当者が判断します。会社の承認がまだなければ、この条件メモを相談材料にするところまでで進められます。 ![AIで作る側になる行動。困る作業を選び、完成条件を書き、架空データで確かめ、翌回も使って直す。承認された範囲で試し、人が結果を確認する](https://shiftb.dev/images/articles/ai-work-builders-non-engineer-flow.png) ## 行動3・4：正解と比べ、次の仕事でも使う ### 行動3：見た目ではなく、正解と例外で確かめる 次の表は説明用に作った5件の架空データです。基準日は2026年9月23日、期限超過は「その日より前」とします。件数は効果や実績を示す数値ではありません。正常な入力だけでなく、当日、完了済み、空欄も用意し、条件の境目で結果が変わるかを確認します。 | ID | 期限 | 状態 | 期待する出力先 | | --- | --- | --- | --- | | A01 | 9月21日 | 未対応 | 期限超過 | | A02 | 9月23日 | 未対応 | 対象外 | | A03 | 9月20日 | 完了 | 対象外 | | A04 | 空欄 | 未対応 | 要確認 | | A05 | 9月22日 | 未対応 | 期限超過 | 期限超過はA01とA05の2件、要確認はA04の1件です。合計だけ合っていても安心せず、IDまで比べます。A02が混じったなら「当日も対象にしている」、A04が消えたなら「空欄の扱いが抜けている」と、違いを指定して直します。「なんとなく違う」と依頼し直すより、どの入力で何が違ったかが明確になります。 公式の[Claude Codeのベストプラクティス](https://code.claude.com/docs/en/best-practices)でも、出力を検証できる条件を渡すことが重視されています。AI自身の「できました」だけで終えず、期待する結果と照合してください。今回の例でも、空の一覧や列名の変更を試したときに、誤った結果を黙って出さず、修正すべき入力を説明できるかまで確認します。 ### 行動4：翌回の入力と、直すための記録を残す 試作が動いたら、作成に使った会話だけでなく、使うファイル、入力の形式、起動する手順、正解の例を一緒に保存します。次の仕事で一覧を差し替えた際にも、同じ条件で処理できるか試します。今週だけ動いた状態と、翌回も使える状態を分けて考えることが、使う側から作る側へ進む練習になります。 この練習では基準日を固定しています。翌回に流用する際は、基準日を毎回入力するのか、その日の日時を使うのかを決め直します。試した日付が残ったままでは、画面は動いていても対象がずれます。会社の締め日のルールなど、変えてよい条件と固定する条件も、手順に添えておきます。 また、依頼文に「送信しない」と書くことと、ツールが送信できないように設定することは別です。[公式の権限設定](https://code.claude.com/docs/en/permissions)を確認し、許可する操作を絞ります。分からない操作の承認をまとめて省略せず、変更先と実行内容を確認する習慣をつけます。作る過程でAIへ渡す情報と、完成したツールが実行時に送る情報も、それぞれ確認が必要です。 途中で止まりやすいのは、自分だけが使える試作品から、別の入力でも直せる状態へ進む場面です。エラーが出た入力と期待した結果を残せれば、学ぶべき基礎や相談したい内容も具体化します。AIシフトコースで学ぶことを検討するなら、動いた画面だけでなく「ここを変えたら動かなくなった」という記録を、次の学習課題として持っていけます。 ## AIを使う側になるために、今日残すもの ### 成果は、減った作業と残る判断をセットで説明する 上司や同僚に見せるときは「AIで作りました」に加え、何を入力すると何が出るのか、どこを人が確認するのか、失敗したらどう戻すのかを実演します。使う前後の作業時間を比べるなら、準備、確認、修正まで含め、同じ件数と条件で測ります。試作にかかった時間も別に残し、繰り返して使う価値があるかを判断します。 作った結果、手作業の方が早いと分かることもあります。その場合は導入を見送って構いません。何を試し、どの条件で使えなかったかを説明できれば、次の題材選びに使えます。AI利用そのものを成果にせず、現場で役立つかを確かめるところまでが、今回の「作れる」に含まれます。 ### 試作を業務へ持ち込めない場合は、条件メモを相談に使う 会社で外部AIの利用やツールの導入が認められていない場合、独断で業務データを渡す必要はありません。「毎回ここを確認している」「この条件で一覧を出したい」「結果は自分が照合する」と書いたメモを、上司や情報システム担当への相談に使えます。承認された既存機能で解決できることもあります。新しい開発の前に、利用できる仕組みを確かめてください。 相談では、単に「AIを使いたい」と伝えるより、取り除きたい操作と残す確認を示します。例えば「期限超過の候補を並べるところまで。催促するかどうかは担当者が判断する」という範囲です。作業時間を確保できないなら、その調整も依頼します。導入が進まない理由を、本人の意欲や学習不足だけに結びつけないことも大切です。 ### 最初の成果物は、完成条件をまとめたメモでいい 今日の仕事から、繰り返した操作を1つ選んでください。入力、選ぶ条件、欲しい出力、確認方法を書いたメモが最初の成果物です。作り始める手順は[非エンジニアが業務アプリを作る手順](https://shiftb.dev/articles/claude-code-business-app-non-engineer)へ進めます。実際のExcel集計を題材にするなら、[Excel作業をAIで自動化する手順](https://shiftb.dev/articles/excel-automation-claude-code)が実践編です。 基礎を学ぶ意味が気になる場合は[AIでプログラミングは不要になるのか](https://shiftb.dev/articles/ai-programming-unnecessary)を、すでに開発を仕事にしている場合は[AI時代のエンジニアに求められるスキル](https://shiftb.dev/articles/ai-era-engineer-skills)を参照してください。非エンジニアの最初の一歩は、自分が知っている仕事の条件を書き、動いた結果を自分で確かめることです。次の仕事にも使えるものを残しながら、作れる範囲を広げていけます。