AIで報告書の文章は早く書けた。でも、その材料を探し、表へ転記し、数字の間違いを直す仕事は、翌週も残っている。 僕が開発・運営するVibelyは、ShiftBの社内ツールから始まり、教材管理や受講生の進捗管理を形にしてから外部向けのサービスへ広げました。身近な仕事を仕組みにすることは、営業・企画・事務の現場でも出発点になります。
「AIに仕事を奪われる側と使う側」を、才能や職種で決まる二分法にはしたくありません。この記事では、非エンジニアが今の仕事を続けながら、AIに答えをもらった先で何を作り、どう確かめ、次の仕事へ残すかを扱います。実在する事例と説明用の架空例を分け、行動の違いを具体化します。
AIに仕事を奪われるかを、職種だけで決めない
作業の自動化と、仕事がなくなることは別に考える
営業の仕事には、商談メモの整理、提案資料の作成、条件の調整、顧客への説明が含まれます。文章を生成できるだけでは、相手に何を約束してよいかは決まりません。「営業は残る」「事務はなくなる」と職種名だけで判断すると、自分が変えられる作業が見えなくなります。
国際労働機関(ILO)の生成AIと仕事に関する研究も、職業を構成する個々の作業から影響を評価しています。多くの職業には人の関与を要する作業が含まれ、生成AIの影響として仕事の変容が有力だとしています。これは個人の雇用を保証する話でも、誰が失業するかを言い当てる研究でもありません。
自分の仕事について考えるなら、まず「入力された内容を整える部分」「条件を決める部分」「結果を確認して相手へ渡す部分」に分けます。AIに任せる候補を探しつつ、任せた後に自分が何を判断するかまで書く。職種の将来予測を読むだけでは決まらなかった、次の行動がここで決まります。
「作れるか」は、仕事を変えるための行動の指標
この記事でいう「作れる」は、ゼロからコードを暗記して書けることに限りません。自分の仕事で使う入力、処理の条件、出力を決め、動く形にして、結果を確かめ、必要に応じて直せることです。既存の機能を設定するだけで済むなら、その方法で構いません。アプリを増やすこと自体が目的ではないからです。
ただし、作れる人でも、会社の事業や人員配置の影響を受けます。「AIを使えば仕事は絶対に奪われない」という結論にはできません。ここで扱うのは雇用の安全度ではなく、自分の担当業務の改善に関われる範囲を広げるやり方です。AIの導入を決める権限がない人は、試作の相談や完成条件の整理から参加できます。
校長として見る「作れる」の中身
実在するのは、身近な課題を形にした事例
Vibelyは、社内で使う教材管理や進捗管理などの機能から始まったサービスです。最初から一般向けの大きな製品を想定するより、自分たちが使う対象を具体化したことが出発点でした。非エンジニアの業務でも、「部署全体をAI化する」より「毎回の転記を減らす」の方が、完成品の姿と答え合わせの方法を決めやすくなります。
公開済みの受講生事例には、元営業職のAさんが議事録自動化ツールを開発した例があります。ここから言えるのは、営業の経験に近い題材をツールにしたという事実です。削減時間や社内評価、雇用への効果までは、この事例から断定しません。僕が校長として重視するのは、知っている仕事を題材に、使えるものを作るところまで進めることです。
行動の差は「翌回に何が残ったか」で見る
例えば、会議のたびにAIへ要約を頼み、毎回手で見出しを直す使い方を考えます。次の会議にも同じ直しが必要なら、残っている作業は見出しをそろえる部分です。別の進め方では、決定事項、担当者、期限の欄を決め、材料がない欄を勝手に埋めないルールと、確認する手順を残します。翌回は、新しいメモで同じ手順を試せます。
この対比は説明用の架空例で、受講生を比較した調査ではありません。見る対象はAIへの質問回数やツール名ではなく、次回も使う処理と確認方法が残ったかどうかです。毎回説明し直しているなら依頼文を保存し、同じ修正が続くなら条件へ加え、他人が使えないなら手順を短く書く。残った手作業が、次に作る対象を教えてくれます。
「何を残せば改善になるか」が言葉にできない段階では、ツールを増やしても題材は決まりません。AIシフトコースの無料相談会は、今の仕事から学習の題材を選び、どこまで作ることを目指すかを整理する入口にできます。
AI時代のアプリ開発コース
ShiftBのAIシフトコースは、Claude Codeで本格的なWebアプリケーションを作りながらAI駆動開発を身につけるコースです。ただ作って終わりではなく、コードを読め、セキュリティに責任を持って提案でき、要件定義などの上流工程まで担えるところまで現役エンジニアがサポートします。
AIシフトコースを見る →行動1・2:繰り返す作業を選び、完成条件を書く
行動1:自分で正解を確かめられる作業を選ぶ
日常業務を「週報作成」のような名前で書いたら、その下に実際の操作を並べます。案件一覧を開く、期限を過ぎた案件を探す、担当者別に並べる、共有用の文章にする。そのうち、自分で正しい結果を説明でき、失敗しても原本へ影響しない部分を最初に選びます。この例なら、架空の一覧から期限超過の案件を抽出するところまでです。
選ぶときにつまずきやすいのは、「簡単そう」と「正解が決まっている」を混同することです。催促文は短くても、送る相手や言い方の判断を伴います。対して一覧の抽出は、期限と状態の条件を決めれば照合できます。最初は顧客への送信、請求、元データの更新を含めず、結果を人が見て確かめる範囲に絞ります。
AIへ情報を渡す前には、会社で認められたアカウント、入力できる情報、相談先を確認します。Claude Codeのデータ利用の説明では、個人向けと商用契約でモデル改善への利用条件が異なります。有料契約かどうかだけで判断せず、契約・設定・社内規程を確認してください。練習には、実際の顧客情報を書き換えたものではなく、最初から作った架空データを使います。
行動2:依頼する前に、完成条件を自分で書く
悪い依頼例は「案件管理をAIで便利にして」です。便利の中身がないため、画面や通知が増えても、減らしたかった作業に届くか判断できません。良い依頼例では、入力、選ぶ条件、出力、やらない操作を具体化します。次は、後の表にある架空データを使う練習用の依頼文です。
架空の案件一覧を使い、期限超過の確認表を作りたいです。
入力はID、期限、状態。基準日は2026年9月23日です。
期限が基準日より前で、状態が「未対応」の行だけを選びます。
期限が空欄なら推測せず、別の「要確認」一覧へ出してください。
最初に、この条件で出るはずのIDと理由を説明してください。
その後、同じ形式の一覧で繰り返し使える小さなツールを作ります。
元データの変更、メール送信、実在の社内システムとの連携はしません。
Claude Codeは、会話に沿ってファイルを読み、編集し、コマンドを実行できる開発ツールです(公式の概要)。この依頼文は実行結果を保証するものではなく、何を作るかを合意するための例です。画面の見た目を先に作ると、肝心の抽出条件が曖昧なまま進むため、まず出るはずの結果を言葉で合わせます。
自分で決めるのは、期限当日を含めるか、完了した案件を除くか、空欄をどう扱うかです。ここに現場の知識を使います。AIが提案した条件を採用する場合も、普段の業務ルールと一致しているかを担当者が判断します。会社の承認がまだなければ、この条件メモを相談材料にするところまでで進められます。

行動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のベストプラクティスでも、出力を検証できる条件を渡すことが重視されています。AI自身の「できました」だけで終えず、期待する結果と照合してください。今回の例でも、空の一覧や列名の変更を試したときに、誤った結果を黙って出さず、修正すべき入力を説明できるかまで確認します。
行動4:翌回の入力と、直すための記録を残す
試作が動いたら、作成に使った会話だけでなく、使うファイル、入力の形式、起動する手順、正解の例を一緒に保存します。次の仕事で一覧を差し替えた際にも、同じ条件で処理できるか試します。今週だけ動いた状態と、翌回も使える状態を分けて考えることが、使う側から作る側へ進む練習になります。
この練習では基準日を固定しています。翌回に流用する際は、基準日を毎回入力するのか、その日の日時を使うのかを決め直します。試した日付が残ったままでは、画面は動いていても対象がずれます。会社の締め日のルールなど、変えてよい条件と固定する条件も、手順に添えておきます。
また、依頼文に「送信しない」と書くことと、ツールが送信できないように設定することは別です。公式の権限設定を確認し、許可する操作を絞ります。分からない操作の承認をまとめて省略せず、変更先と実行内容を確認する習慣をつけます。作る過程でAIへ渡す情報と、完成したツールが実行時に送る情報も、それぞれ確認が必要です。
途中で止まりやすいのは、自分だけが使える試作品から、別の入力でも直せる状態へ進む場面です。エラーが出た入力と期待した結果を残せれば、学ぶべき基礎や相談したい内容も具体化します。AIシフトコースで学ぶことを検討するなら、動いた画面だけでなく「ここを変えたら動かなくなった」という記録を、次の学習課題として持っていけます。
AI時代のアプリ開発コース
ShiftBのAIシフトコースは、Claude Codeで本格的なWebアプリケーションを作りながらAI駆動開発を身につけるコースです。ただ作って終わりではなく、コードを読め、セキュリティに責任を持って提案でき、要件定義などの上流工程まで担えるところまで現役エンジニアがサポートします。
AIシフトコースを見る →AIを使う側になるために、今日残すもの
成果は、減った作業と残る判断をセットで説明する
上司や同僚に見せるときは「AIで作りました」に加え、何を入力すると何が出るのか、どこを人が確認するのか、失敗したらどう戻すのかを実演します。使う前後の作業時間を比べるなら、準備、確認、修正まで含め、同じ件数と条件で測ります。試作にかかった時間も別に残し、繰り返して使う価値があるかを判断します。
作った結果、手作業の方が早いと分かることもあります。その場合は導入を見送って構いません。何を試し、どの条件で使えなかったかを説明できれば、次の題材選びに使えます。AI利用そのものを成果にせず、現場で役立つかを確かめるところまでが、今回の「作れる」に含まれます。
試作を業務へ持ち込めない場合は、条件メモを相談に使う
会社で外部AIの利用やツールの導入が認められていない場合、独断で業務データを渡す必要はありません。「毎回ここを確認している」「この条件で一覧を出したい」「結果は自分が照合する」と書いたメモを、上司や情報システム担当への相談に使えます。承認された既存機能で解決できることもあります。新しい開発の前に、利用できる仕組みを確かめてください。
相談では、単に「AIを使いたい」と伝えるより、取り除きたい操作と残す確認を示します。例えば「期限超過の候補を並べるところまで。催促するかどうかは担当者が判断する」という範囲です。作業時間を確保できないなら、その調整も依頼します。導入が進まない理由を、本人の意欲や学習不足だけに結びつけないことも大切です。
最初の成果物は、完成条件をまとめたメモでいい
今日の仕事から、繰り返した操作を1つ選んでください。入力、選ぶ条件、欲しい出力、確認方法を書いたメモが最初の成果物です。作り始める手順は非エンジニアが業務アプリを作る手順へ進めます。実際のExcel集計を題材にするなら、Excel作業をAIで自動化する手順が実践編です。
基礎を学ぶ意味が気になる場合はAIでプログラミングは不要になるのかを、すでに開発を仕事にしている場合はAI時代のエンジニアに求められるスキルを参照してください。非エンジニアの最初の一歩は、自分が知っている仕事の条件を書き、動いた結果を自分で確かめることです。次の仕事にも使えるものを残しながら、作れる範囲を広げていけます。