バイブコーディングを仕事で使う範囲【任せる業務の決め方】

バイブコーディングを仕事で使うなら、工程を分ける

「営業を自動化」では、判断する単位が大きすぎる

営業の仕事にも、未対応の案件を並べる、返信文を下書きする、値引きを決める、顧客へ送る、といった違う工程があります。未対応一覧の誤りは原本と照合して直せますが、送信済みの文面や約束は、ファイルを戻すだけでは取り消せません。同じ部署の業務でも、任せられる範囲は工程ごとに変わります。

最初の候補は、入力と出力がはっきりしていて、原本を変えずに試せるものです。中小機構の実践記事でも、非エンジニアは比較的軽い業務から試す考え方と、データの集計例が紹介されています。ここではさらに、出力を誰が確かめ、どこで本番の仕事へ戻すかまで決めます。

作るときのAIと、使うときのAIを分ける

範囲を決めた結果、今ある表のフィルターや入力規則だけで済むなら、まずそれを使います。専用の道具を作るのは、同じ操作の繰り返しや複数ファイルの処理など、既存の機能だけでは残る手作業があるときです。動かす道具が増えるほど、更新と引き継ぎの仕事も増えます。

バイブコーディングは、AIと対話しながらプログラムを作る進め方です。完成した道具が、毎回AIへデータを送るとは限りません。たとえば決めた条件で表の行を絞る処理は、生成AIを呼ばないプログラムにもできます。一方、問い合わせの文章を要約する機能は、利用時にもAIサービスへ内容を送る構成になり得ます。

作成時に渡すサンプルと、利用時に処理する本番データの両方について、どこへ送られるかを確認してください。「パソコン上で画面が開く」だけでは、外部通信の有無は分かりません。コードの意味を追う前に、AIへ「入力から出力までの保存先と送信先を説明して」と頼み、会社で利用を認められた範囲と照合します。説明だけで判断できなければ、接続する前に管理担当者へ確認します。

操作をまだ試していない場合は、ピラー記事のバイブコーディングの始め方から練習できます。本記事の線引きは、その道具を仕事へ持ち込む段階で使ってください。

業務別に決める、任せていい範囲と止める場所

社内ツール：表示や候補作りから任せる

備品の在庫一覧、案件の未対応一覧、申請の入力チェックは、最初の候補になります。ただし「社内向けだから安全」とは決めません。閲覧者に見せてよい情報だけを集め、結果を見る機能と原本を書き換える機能を分離します。在庫不足の候補を出すところまでなら試しやすくても、自動発注まで付けると金額や取引先への影響が増えます。

入力チェックも、空欄を知らせることと、申請を承認することは別です。給与の確定、採用の合否、契約の承諾など、本人や相手の扱いを決める仕事は、初心者が作った道具へ最終判断ごと任せる対象から外します。まずは担当者が読むための整理にとどめ、既存の承認手続きを残してください。

データ処理：集計結果を別の場所に出す

表の結合、表記の統一、条件に合う行の抽出は、答え合わせを作りやすい業務です。原本から試用を認められたデータだけを取り出し、結果は別ファイルへ保存します。重複らしい行を見つけても、原本から自動削除する機能は最初から付けません。同姓同名や同額の取引を、同一データと誤って扱う可能性があるためです。

共有表では、書き込み先にも注意が必要です。Google Sheets APIの公式説明によると、連携の権限範囲はスプレッドシートのファイルに適用され、特定のタブだけには限定できません。「このタブにだけ書いて」という指示と、他のタブへ書けない権限設定は同じではありません。入力用と出力用のファイルを分ける構成も検討します。

定型連絡：文案と送信を分離する

当番通知や締め切りのリマインドは、まず宛先・本文・送信予定を一覧にする道具として作ります。実際の送信は担当者が確認してから行います。社内の連絡でも、宛先を間違えれば見せてはいけない情報が届き、再実行で同じ通知が重複すれば受け手の仕事を増やします。

Slackのchat:writeは、アプリとしてメッセージを送信するための権限です。下書きをファイルに保存するだけの段階なら、その送信権限を付ける必要はありません。接続を増やす前に、必要な仕事が下書きで完結するかを考えます。

業務をここまで分けると、作りたい画面より先に決めることが見えてきます。自分の仕事のどこを切り出し、どこを人に残すか。その設計から一緒に整理したい方は、AIシフトコースの無料相談会へ、今使っている手順を言葉にして持ってきてください。

手順1・2：題材を選び、使うデータと権限を決める

手順1：完成条件を、更新しない仕事として書く

題材を「未対応案件の確認」に絞るとします。いきなりアプリを作る前に、対象の表、抽出する条件、出力する項目、担当者へ渡す方法を書きます。詰まりやすいのは「未対応」の意味です。空欄を未対応と扱うのか、確認が必要な不明データと扱うのかで、同じ表から違う一覧ができます。

悪い依頼例は「案件管理を便利にして、遅れている人へ自動で連絡して」です。便利さの基準も、遅れの定義も、連絡の許可も決まっていません。下は、説明用の架空業務について、試作の境界を決めた依頼例です。

案件表のコピーから、状態が「未対応」の行を抽出する道具を作りたい。
表示項目は案件IDと担当だけ。状態が空欄なら「要確認」へ分ける。
原本は変更せず、結果を別の確認用ファイルへ出す。
メール・チャット送信、外部サービスへの接続、定期実行は付けない。
まず入力・出力・保存先と、条件が不明なときの動きを説明して。
実装前に、私が決める必要のある点を挙げて。

この段階では、画面の色やボタンの数は後回しで構いません。「未対応を一覧にする」だけに狭めれば、後で結果が正しいかを自分で判定できます。作り方そのものは非エンジニアが業務アプリを作る手順に沿って進められます。

手順2：指示文と、実際のアクセス権をそろえる

最初は架空の表を作り、会社の情報を含まない作業用フォルダで試します。実データへ進むときは、会社で認められたツール、利用目的、送信先を確かめ、必要な列だけを使います。名前を消しても、案件内容や連絡先が残れば機密情報を含むことがあります。コピーを作ること自体と、そのコピーをAIへ渡してよいことは別に判断します。

Google Driveの共有設定では、閲覧者・閲覧者（コメント可）・編集者を選べます。連携用アカウントを使う場合も、元ファイルは閲覧、出力先は必要に応じて編集、というように権限を分けます。広い権限のまま「原本を触らないで」と頼むだけでは、設定として原本を守ったことにはなりません。

親フォルダから編集権限を受け継いでいる場合は、ファイル単体を閲覧者にしても権限を狭められません。入力用ファイルの置き場所や親フォルダの共有設定も、管理担当者と確認してください。

Claude Codeも、許可する操作を設定できます。公式セキュリティガイドは、提案されたコードやコマンドを利用者が確認する責任を明記しています。見慣れない操作を承認するときは、対象ファイル、外部送信、変更内容を説明させます。分からない操作は止め、判断できる人へ確認してから進めてください。

手順3・4：答え合わせを作り、止め方まで試す

手順3：AIの答えより先に、期待する結果を作る

架空の案件を5件用意します。A01・A03・A05は未対応、A02は対応済み、A04は状態が空欄とします。期待する出力は未対応が3件、要確認が1件です。合計だけでなく、案件IDも照合します。件数が合っていても、別の案件が混じる間違いを見逃さないためです。

次の表は、この架空データに対する答え合わせです。測定結果や成功率ではありません。変更後のケースでは、最初の表からA03を対応済みに変えます。最後は見出しだけの空の表を渡します。

最初はA01・A03・A05、変更後はA01・A05が並び、どちらもA04が要確認に分かれることを確かめます。空の表では、前回の結果が残らないことも見ます。架空データで通ったら、実データのうち利用を認められた範囲で同じ照合をします。ここでの合格は、この条件で試せたという意味です。別の形式や用途まで使える証明にはしません。

手元で照合できないときは、依頼をさらに狭めます。たとえば「取引の異常を見つける」では正解を決めにくくても、「必須欄が空の行を出す」なら確認できます。AIに作らせた道具を、同じAIの「問題ありません」という返答だけで合格にしないことが大切です。

手順4：失敗しても、元の仕事に戻れるか確かめる

同じ入力で再実行し、一覧が重複しないかを見ます。列名を変えたときは処理が止まり、何を直すかが表示されるようにします。ファイルを読めなかったのに「未対応はありません」と出る設計では、失敗を正常な結果と取り違えます。入力エラー、該当なし、正常終了を分けて出すように依頼してください。

試用をやめる操作も確かめます。手動実行なら終了方法、定期実行を追加するならスケジュールを無効にする場所、連携を追加するなら権限を外す場所を記録します。途中で止めたときに出力が半端な状態にならないか、どの結果を採用してよいかも確認します。最初は原本の更新や送信を付けず、手作業の手順へ戻れる状態で試します。

Claude Codeのサンドボックスは、コマンドが触れるファイルや通信先を制限する仕組みです。ただし、AIで作ったアプリを後から別の場所で動かす際の権限まで、そのまま保証するものではありません。開発中の制限と、実際に使う道具の設定を分けて確認します。

正常時だけでなく、空欄や再実行まで確かめられると、次は同僚にも使ってもらう段階です。そこで必要になるのは、結果を説明し、修正し、引き継げる力です。AIシフトコースでは、AIに作ってもらったものを理解して直せるようになる学習へ進めます。

小さく使い始め、担当者を決めてから広げる

「担当者が休んだ日」を想定して引き継ぐ

試用前に、入力を用意する人、結果を確認する人、不具合が出たときに止める人を決めます。同じ人が兼ねても構いませんが、不在時に誰が判断するかは残します。説明書には、入力ファイルの場所、実行方法、正常な出力例、停止方法、元の作業へ戻す方法を書きます。パスワードや接続用の秘密情報を、その説明書へ貼らないようにします。

利用者が変わると、画面以外の条件も変わります。自分には開けたファイルが同僚には開けない、保存先を見つけられない、といった点を、試用する本人のアカウントで確認します。動かすために全員へ編集権限を広げる前に、その人に必要な閲覧範囲と操作を見直してください。

任せる範囲を広げるときは、別の変更として扱う

一覧表示から原本更新へ、社内の下書きから顧客への送信へ進むときは、新しい仕事を追加する判断です。利用者、扱う情報、失敗時の影響が変わるので、確認する条件と責任者も決め直します。コピーでの集計が通ったことを理由に、そのまま送信まで自動化しないでください。

設計・保守の技術的な論点はバイブコーディングの限界、作成中につまずくパターンは失敗と対策の記事で扱っています。ここで決めるのは、その前提となる業務の範囲です。

明日の仕事から選ぶなら、原本を変えず、答え合わせができる集計や一覧作成を候補にしてください。使うデータ、期待する出力、人が確定する場所、止め方を書いてから作り始めます。バイブコーディングを業務へ持ち込む一歩は、自分が責任を持って確かめられる工程を、動く道具にすることです。