「AIに仕事を渡す力」から鍛える — AI時代に現場で入る新人への思考実験

TL;DR

• AI 時代に現場で入るなら、コードを書くこと自体より先に 「AIに仕事を渡す力」 を意識的に鍛えたい、という思考実験です（未来予測ではありません）。
• 現場で身につけた型（差分設計・レビュー・外注調整・現場導入・可視化）が、そのまま AI 協業の渡し方に効く、という振り返りです。
• 年代で強みは違いますが、「経験を AI に渡せる形へ変換する」 構造は同じ、という整理です。

はじめに

現場系の仕事（ネットワーク検証、設計レビュー、ベンダー調整、拠点立ち上げ、監視、業務フロー整理など）を長くしてきました。コードを書くより、仕様を分解し、前提と制約を揃え、検証して引き継ぐ ことが仕事の中心に近かった、という感覚があります。

仕事の休眠期にルーティンの業務効率化を AI と試す余裕ができたとき、これまで当たり前にやってきたことが、そのまま AI への渡し方 に重なりました。後輩に説明する材料にもなりそうなので、まず自分で使い込みながら、この記事にまとめています。単なるツール作りではなく、経験を AI に渡せる形へ変換する訓練 になっている感覚です。

これらは AI 時代になって初めて重要になったのではなく、仕事を渡すようになると急に表に出る タイプの力だと思います。前回の AI小噺 — 終わらない会話の構造 より重めの整理になります。

「AIに仕事を渡す力」 は、プロンプト術ではなく、次の 7 つ をセットで扱えることです。

• 業務を分解する
• 入力と出力を決める
• 制約を伝える
• 判断基準を決める
• 検証方法を用意する
• 出てきた成果物を受け入れ確認する
• 最後に、人に渡せる形へ整える

実際、この 7 項目に沿って「この順番で一つずつ作業を進めてください」と AI に指示するだけでも、かなり作業が進めやすくなります。第1部では、なぜ私がその結論に至ったのかを、自分の現場経験から振り返ります。

第1部：経歴から見えた「渡し方」の型

通信インフラの知識 → 既存を流用し、差分を明示してAIに渡す

最初のキャリアは、通信インフラ系の現場でした。

ネットワーク機器の検証、手順書作成、サービス接続、設計レビュー。
大きな組織の中で、複数社が関わる下請け構造の現場に入り、既存サービスを流用しながら新しいサービスをどうネットワーク機能として実現するかを考えていました。

ここで鍛えられたのは、単にルータやスイッチの知識ではありません。

一番大きかったのは、「既存の仕組みを見て、差分を考え、今回必要な形に落とし込む」 ことでした。

新サービスだからといって、すべてをゼロから作るわけではありません。
既存のパケット処理、既存の経路、既存の設計思想、既存の運用を見て、何を流用できて、どこだけが違うのかを考える。

これは今、AI に仕事を渡すときにもそのまま使っています。

AI に「全部作って」と頼むより、

• 既存のこの仕組みを流用する
• 今回違うのはここ
• 入力はこれ
• 出力はこう
• 判定基準はこれ
• 検証用サンプルはこれ

と渡した方が、ずっと安定します。

設計レビューの知見 → 情報を削ってAIに渡す

キャリアを通じて行ってきた設計レビューの経験も大きかったです。

ベテランのレビューを受けると、単に「正しいかどうか」だけではなく、「相手に伝わる形になっているか」 を見られます。

また、新人のレビューを行うと、レビューの前提条件を合わせることの重要さに気づかされます。

情報が足りなければ当然だめです。しかし、情報が多すぎてもだめ です。

レビューする側は、すべての背景を追いたいわけではありません。
判断に必要な情報、リスク、差分、前提、確認してほしい点を見たい。

この 「情報を削る力」 は、AI 協業でもかなり重要です。

AI には大量の情報を渡せます。しかし、大量に渡せることと、うまく渡せることは違います。

人間にレビューしてもらうときと同じで、AI にも次のように渡した方がよい。

• 背景
• 目的
• 制約
• 入力
• 出力
• 判断基準
• 触ってよい範囲
• 触ってはいけない範囲
• 検証方法

これはプロンプト術というより、仕事の渡し方 です。

ベンダー調整術 → AIを外注エンジニアとして扱う

現場では、ネットワーク機器やサーバなどの販売会社との調整も多くありました。

勉強会という形で設計内容をすり合わせたり、相手の理解度に合わせて資料を作ったり、こちらの要求が伝わるように前提を整えたりする。

この経験は、AI を使うときにもかなり効いています。

私は AI を、魔法の箱というより 「外注のエンジニア」 に近い感覚で扱っています（別記事 AI を「外注エンジニア」として扱う話 でも整理しています）。

外注のエンジニアに仕事を渡すとき、普通はこうします。

• 何を作りたいか説明する
• 既存資料を渡す
• 制約を伝える
• 成果物の形式を指定する
• 途中でレビューする
• 必要なら手戻りさせる
• 最後に受け入れ確認をする

AI にも同じことをします。違うのは、コストと時間の感覚です。

人間の外注先なら、何度も手戻りさせるとコストが膨らみます。相手の時間も奪います。

AI の場合、その制約はかなり小さく、手戻りを発生させてもほぼコストがかかりません。
だから、自分が扱いやすい速度まで、わざと仕事の速度を落とせます。

一気に作らせるのではなく、

1. まず状況を整理させる
2. 次に設計させる
3. それをレビューする
4. 小さく実装させる
5. 検証させる
6. ドキュメント化させる

という進め方ができます。これは、AI が速いからこそ、人間側が制御しやすい速度に落とす という発想です。

物理工事PMのスケジュール力 → 現場に置ける形までAIに設計させる

企業オフィスの新規立ち上げ、撤退、縮小に関わった時期もありました。

自分たちの機器をどう持ち込むかだけを見て済む仕事ではありません。

ビル設計 PM とのネゴ、LAN ケーブル配線業者の確保、内装・天井・フロア・什器業者とのスケジュール調整。
さらに、管理組合の制約の把握、鍵保管ルール、複数事業者の回線予約まで見なければなりません。

スケジュール調整が出来ても、現場に入れなければ意味がありません。
機器が確保できても、タイミングが合わなければ設置できません。
設定が正しくても、回線が通っていなければ通信はできません。
そもそも電源がなければ、機器は動きません。

ここで身についたのは、「成果物は、それが使われる場所まで含めて設計する」 という感覚です。

コードが動くだけでは足りません。

• 誰が使うのか
• どのフォルダに置くのか
• どの順番で操作するのか
• エラーが出たら誰が見るのか
• 入力ファイル名はどうするのか
• 出力結果をどう判断するのか
• 引き継ぐときに何を読めばよいのか

ここまで考えて、ようやく現場で使えるものになります。

AI にコードを書かせること自体は、かなり簡単になりました。
しかし、現場で使える形にするには、今でも運用設計が必要 です。

監視とデータ可視化の技術 → AIが生成したデータを見る

経歴の後半には、監視ツールの運用や、ネットワーク状況の可視化もやりました。

監視ツールのマニュアルを読み込み、職場の使い方に合わせて設定する。

Excel VBA やバッチファイルを使い、監視ツールの機能や API からデータを取り、グラフ化して事業部に見せる。

AI に何かを作らせるとき、最後に必要なのは 「本当に良くなったのか」 を見ることです。

たとえば業務ツールなら、

• 処理件数
• エラー件数
• 差分件数
• 人間が確認すべき件数
• 作業時間の変化
• 誤判定しやすいパターン

こういったものを見える形にすると、改善の会話ができます。

AI はコードを書けます。しかし、何を成功とみなすかは、人間が定義する 必要があります。

経歴の振り返り — 経験をアナロジーしてAIへ渡す

振り返ると、私がよく使っていたのは アナロジー だったのだと思います。ある現場で覚えた構造を、別の現場に移す力です。

経歴で学んだこと	AI 協業での使い方
既存サービスを流用し、差分を設計する	業務効率化ツールの設計
情報を削って渡す	AI への指示
外注エンジニアに仕事を渡す	AI エージェントの扱い方
現場に置ける形まで考える	ツール配布・運用引き継ぎ
データを取って見せる	AI 成果物の検証

つまり、AI 時代だからまったく新しい能力が必要になった、というより、過去の現場経験を別の対象に移し替えられる人が強くなっている のだと思います。

---

第2部：AI 時代に新人で入るなら

ここまでの経歴を踏まえて、いまの時代に、現場で入る新人 に伝えるなら、具体的には次のように動いてほしいと思います（私自身はすでに別の道を選んでいるので、あくまで思考実験です）。

1. 業務を手順に分解する練習をする

まず、目の前の仕事を手順に分解します。

たとえば、Excel で毎日やっている集計でもいい。
ファイルを受け取り、列を確認し、不要な行を消し、並べ替え、別表と突合し、結果を誰かに送る。

それを日本語で手順化します。

この時点では、コードを書けなくても構いません。

重要なのは、「自分が何を判断しているのか」を言語化すること です。

2. 入力と出力を決める

次に、入力と出力を決めます。

AI に仕事を渡すとき、一番大事なのはここ です。

• 入力ファイルは何か
• 必須列は何か
• 出力ファイルは何か
• どの列を追加するのか
• どの条件なら OK なのか
• どの条件なら人間確認なのか

これを決められるだけで、AI に渡せる仕事の質が上がります。

3. 小さなスクリプトに触れる

次に、VBA、PowerShell、Python、バッチファイルのどれでもよいので、小さなスクリプトに触れます。

最初から大きなアプリを作る必要はありません。

• ファイル名をそろえる
• CSV を読み込む
• Excel を整形する
• API からデータを取る
• フォルダを整理する
• ログを残す

大事なのは、「手作業は、ある程度までは自動化できる」と体感すること です。

4. GitHub や Skills を、作業を資産化する場所として使う

GitHub や Cursor の Skills のような仕組みは、かなりプログラマー寄りです。業歴のある人がいきなり乗ると、文化の違いで疲れるかもしれません。

実際、私は何でも GitHub へ寄せているわけではありません。ファイル共有や作業管理は Google ドライブの Web 版・デスクトップ版を使い、Skills も自分に必要だと感じたものだけをサーベイしてから独自に入れるようにしています。

プログラマーのロジックに無理に合わせるより、現場系のロジックで AI に触れた方が、自分には扱いやすい からです。たとえば、環境に依存させない、設定の正本をコードから分離する、といった考え方です。

一方で、若い人なら早めにプログラマーのロジックに触れてよいと思います。目的は、流行のツールを使うことではありません。作業を一回限りで終わらせず、再利用できる形にする感覚 を身につけることです。

• 手順を README にする
• よく使う処理をスクリプトにする
• 変更履歴を残す
• 他人や AI が読める形にする
• 次回の自分が楽になる形にする

5. AI に丸投げせず、受け入れ確認までやる

AI に仕事を渡す力には、受け入れ確認 も含まれます。AI が出したものを見て、

• 目的に合っているか
• 入力の想定は合っているか
• 出力は確認しやすいか
• 異常系はどうなるか
• 手順書は利用者に読めるか
• 次に改修する人が困らないか

を確認する。これは、外注成果物を受け入れるのと同じ です。

AI が便利になるほど、人間側の責任は 「作ること」から「渡し方と受け取り方」 に移っていきます。

年代別の違いはあっても、やることの型は同じ

20代・30代・40代で持っている経験の量は違います。立場も違います。
ただ、AI に渡す練習の 型 は同じです。以下、年代ごとに少しずつ違う読み方を書きます。

20代に伝えたいこと

正直、いまの 20 代の人の考え方が分かるとは思いません。
なのでここでは、自分の中の 20 代 を取り出して、その頃の自分に伝える形で書きます。

当時の自分に伝えるなら、「プログラマーか、インフラエンジニアか」という迷い を、いまならそんなに早く決めなくてよい、ということです。

インフラの現場に入りながら、コードの世界にも憧れていた頃がありました。どちらか一方だけを選んで深掘りしろ、と言われる雰囲気もありました。AI がある前提なら、両方の型を無理なく吸収する余地はかなり広がっていると思います。

現場で身につける分解・検証・手順化の力を土台に、スクリプトや小さな自動化は AI と一緒に取りに行けばよい。プログラマー寄りの書き方や資産化の習慣も、現場の業務に接続して試せる。肩書きで一回決めるより、仕事を渡せる形に落とす練習を早く始める方が効きます。

営業でも、事務でも、運用でも、企画でも、現場の仕事を分解して、AI やスクリプトに渡せる人は強くなると思います。大事なのは、プログラミング思考を別の業務に持ち込む ことです。

• 業務を分解する
• 入力と出力を決める
• 例外を考える
• 検証する
• 手順を残す
• 他人に渡せる形にする

最初の一歩は、目の前の Excel 作業を日本語で手順化することです。次の具体例は、そのイメージです。

具体例（匿名）：毎朝の Excel 集計を AI に渡す

架空の事務作業です。実在の顧客名・金額は出していません。

やっていること
毎朝、売上 CSV を受け取り、不要行を削除・並べ替え・別表と突合し、閾値未満の行を目視で拾って担当へ連絡する。

AI に渡した定義

• 入力: sales_YYYYMMDD.csv（列: 日付, 店舗ID, 金額, ステータス）
• 出力: summary_YYYYMMDD.xlsx（列: 店舗ID, 合計, 要確認フラグ）
• OK 条件: 要確認フラグは「合計が閾値未満」のときのみ 1
• 人間確認: フラグ=1 の行だけ目視
• 検証: サンプル 3 日分で手作業結果と突合し、差分 0 件

結果
コードを 1 行ずつ読むより、突合結果とログを見る運用にした。
「全部自動化」より「人が見る行を減らす」 設計の方が、現場では受け入れられやすかった。

これが本記事冒頭の 7 項目の縮図 です。

30代におすすめしたいこと

30 代は、これまで積んできた業務知識が一度形になり始める時期だと思います。

現場の流れも分かる。人の動きも分かる。どこが面倒で、どこが属人化していて、どこを直すと効くかも見え始める。

だからこそ、この時期は AI や自動化へかなり寄せてよい と思います。

20 代のように基礎を広く取りに行くというより、自分の業務知識を材料にして、AI へ仕事を渡す練習 をする。今まさに持っている現場知識を、スクリプト、手順書、業務フロー、検証サンプルへ変換していく。

方向転換もまだ効きます。
それでいて、完全な新人ではない分、AI に渡すべき業務のネタも持っている。

この時期に「自分の現場知識を AI に渡せる形へ変える」経験を積めると、その後かなり動きやすくなると思います。

40代の人と分かち合いたいこと

40 代の人とは、過去の経験はかなり使える、という感覚を分かち合いたいです。

ただし、そのままの名前では使いにくい。

過去の肩書きや担当システム名ではなく、その中で 何をやっていたのか を抽象化してみると、AI に渡せる形が見えてきます。

• 障害対応をしていたなら、切り分けの力
• 手順書を書いていたなら、再現可能性を作る力
• ベンダー調整をしていたなら、仕事を渡す力
• 監視をしていたなら、状態を見える化する力
• 現場導入をしていたなら、利用者目線の導線設計

こうやって抽象化すると、昔の経験が、今の AI 協業にも使える形になります。

AI は若い人だけの道具ではありません。
むしろ、現場でいろいろな失敗や調整を経験してきた人ほど、AI に渡す仕事の粒度を作りやすい 面があります。

50 代以上については、私はまだ経験していないので分かりません。
ただ、少なくとも 40 代までの実感としては、過去の現場経験を抽象化できれば、AI 協業にかなり接続できます。

まとめ

私自身は、通信インフラ、設計レビュー、ベンダー調整、物理工事 PM、監視可視化、他業界業務の効率化の中で、かなり遠回りして「渡す型」を身につけました。後から振り返れば、もう少し意識的に取りに行けた部分もあります。

少なくとも今の仕事では、AI に仕事を渡せる人が強い。
そしてその力は、プログラマーだけのものではありません。

現場を知っている人ほど、業務を AI に渡せる形へ変換できる可能性があります。

これから鍛えるべきなのは 「AI を使う力」 というより、「AI に渡せる仕事を設計する力」 だと思います。

関連記事

• AI小噺 — 終わらない会話の構造 — 前回の軽量記事（会話の切り上げ）
• AI を「外注エンジニア」として扱う話 — 本記事の「ベンダー調整」節の詳細版
• AIコーディングに「運用エンジニアの規律」を持ち込む話 — 分解・検証・手順化の規律
• 私のAI協業の1日 — 実況（短時間で業務ツールを作る流れ）
• AI コーディングは「錬金術」だ — 思考を放棄しない前提