結論: 「使う」は単発の作業依頼、「任せる」は事業が回る構造。この2つは別物
生成AIを実務に入れ始めて、最初につまずいたのがここでした。「AIに仕事を任せている」と言うとき、実際にやっていたのは単発の作業依頼だったのです。「議事録をまとめて」「メールを書いて」——1回ごとに指示を出し、1回ごとに結果を受け取り、次に何をするかはまた自分で考える。これは電卓を叩いているのと構造的に変わりません。作業は速くなりますが、事業は回りません。
AIを入れても楽にならない、という感覚の正体はここにあります。原因はAIの賢さ不足ではなく、「使う」の延長で止まっているという設計の問題です。事業が回るかどうかは、賢さとは別の軸——「誰が、何を、どこまで、どの安全ラインで引き受けるか」という構造で決まります。この記事は、その「使う」と「任せる」の境目を、自社で複数事業をAIに回してみて分かった範囲で開いていきます。
なぜ「AIを使う」だけでは事業が回らないのか？
理由は1つで、"つなぎ"を全部人間が握ったままだからです。依頼を思いつき、指示を組み立て、結果を確認し、次工程へ渡す——この一連のつなぎが人の手に残っている限り、AIがどれだけ速く答えを出しても、事業を回す仕事は減りません。
私自身、最初は「この作業をやって」と個別に頼むことを繰り返していました。1回1回は確かに速い。けれど、頼む判断・受け取る判断・次に渡す判断が全部自分に残っているので、忙しさの総量はほとんど変わりませんでした。速くなったのは作業で、増えなかったのは自由な時間だった、という感覚です。「使う」と「任せる」の差はここに出ます。
「事業が回る」とは、具体的にどういう状態か？
到達点をひとことで言うと、人間が起点と終点の"判断"にしか触れていない状態です。途中の手作業・つなぎ・記録が全部消えていて、人は「やるかどうかを決める」入口と「これでいいと承認する」出口だけに関わっている。この状態は、AIに1回いい返事をさせることの延長線上にはありません。設計で作るしかない状態です。
たとえば自社では、撮影が終わると素材が命名ルールどおりに整理され、案件管理に新しい行が立ち、編集の準備までつながっていきます。私がやっているのは「この案件を進めていい」と決めることと、仕上がりを確認することだけです。途中のつなぎを人が握らない——この一点が「使う」と「任せる」を分ける決定的な違いでした。
なぜ非エンジニアの自分に、これが作れたのか？
コードが書けないことは不利に見えて、実際には次の3点でむしろ有利に働きました。「任せる」設計は、技術力ではなくこの姿勢から始まっています。
1つ目は、完璧主義を持てなかったことです。自分で実装できないので「全部を一気に作る」という発想がそもそも湧きません。手作業で2回やった1工程だけを切り出して任せる、という現実的な粒度からしか始められませんでした。この小ささが、かえって挫折を防ぎました。何から任せるかの考え方はAIは何から入れるべきかにも書いています。
2つ目は、"壊れる恐怖"を先に設計したことです。中身が読めない人間は、暴走・誤爆・取り返しのつかない操作を心底怖がります。だから機能より先に「送信・公開・お金・削除は人が最後に確認する」という安全ラインを引きました。
3つ目は、言葉で設計できたことです。今のAIは設定を自然言語で書けます。プログラミング言語ではなく、経営者の言葉で「誰が何をどこまでやるか」を文章として定義しました。
明日から試せる、「使う」から「任せる」への最初の一歩
読んで終わりにならないよう、1つだけ具体的な行動に落とします。
今日から1週間、「手作業で2回以上やった作業」を毎日1つだけ書き留めてください。 そして週末に、その中から「途中のつなぎまで含めて丸ごと渡せそうなもの」を1つ選ぶ。いきなり全部を自動化しようとせず、この1工程を"つなぎごと"任せてみる——それが「使う」から「任せる」に踏み出す最小の一歩です。AIをチームの一員のように業務へ組み込んだ実例はチャットでAIに仕事を頼めるようにした話で紹介しています。
まとめ: 賢さではなく、構造で差がつく
AIを入れても楽にならないのは、多くの場合「使う」で止まっているからです。単発の作業依頼を速くこなしても、つなぎを人が握っている限り事業は回りません。途中のつなぎごと渡し、人は起点と終点の判断だけに立つ——この構造に作り替えたとき、初めて「任せた」と言える状態になります。
差がつくのはAIの賢さではなく、この構造をどう設計するかです。そして設計の第一歩は、大きな仕組みではなく「2回やった1工程を、つなぎごと1つ渡してみる」という小ささから始まります。まずは今日の繰り返し作業を1つ、書き留めるところからどうぞ。何を人に残すかという逆側の視点は人に残す仕事の設計も参考になります。