AIには「面倒なとこだけ」渡すのが正解

AIを使い始めた人が最初にはまりがちなのが、「何でもAIにやらせようとする」パターン。結果として出力が微妙で、修正に時間がかかり、「思ったより使えない」となる。

X上で今注目されているのは、もう少し手前の発想だ。「面倒なところだけ切り出して渡す」——これが実務に合うという声が、複数の発信者から相次いでいる。

下書きはAI、最終判断は自分。この距離感が「一番使いやすい」というわけだ。全部任せようとしないからこそ、AIとの協働がスムーズになる。

注目したいのは、この発想が「使い方の慣れ」から自然に出てくる点だ。最初から設計して運用するというより、「面倒なことがあったら、これAIに投げられないかな、と最初に考えるようになった」という感覚。ツールとの距離感が体に染みついてくる段階がある。

面倒を渡す、の一つの好例がVBAマクロの生成事例だ。目的を1〜2行と指示書を渡すだけで、コードの生成と同時に引き継ぎ用の仕様書の叩き台まで出力できる、という使い方が話題になっている。

ここがポイントで、単に「コードを書いてもらう」だけなら以前からできていた。ただ、そのコードを誰かに渡したり、数ヶ月後に自分で読み返すときに「これ何をやってるんだっけ」となるのが実際の問題だ。仕様書を別途書くのが面倒で後回しになり、気づけば属人化している——そういう場面は少なくない。

コードと仕様書を同じプロンプトで出力させることで、「引き継ぎコスト」まで一括で下げられる。しかもそれが「叩き台」として出てくるから、あとは自分で修正・確認するだけ。この「判断は自分が持つ」構造が、先ほどの距離感の話とも一致している。

AIへの指示は「一発正解」を狙わないでも触れているように、一回のプロンプトで完成品を狙うより、叩き台を出してもらって手を入れる方が、実務では安定する。

メール、要約、文章整理、アイデア出し——これらに共通するのは「面倒だが、正解が決まっているわけでもなく、自分が判断している」タスクではないという点だ。逆に言うと、自分の判断が入らなくてもいい部分はAIに渡せる候補になる。

実務で使う量感としては、一つひとつは小さい。メールの下書きが3分浮く、要約に5分かからなくなる、というレベル。ただこれが積み重なると、体感として「時間が浮いてきた」という感覚につながる。

重要なのは「すごいプロンプト」でも「高度な使い方」でもなく、自分の日常業務の中で「面倒だと感じている作業」を一つリストアップして、そのままAIに投げてみること。最初からフローを設計しようとすると止まる。

AI作業は「詰まった場所」ごとにツールを使い分けるでも指摘されているように、使い方は全体設計より「詰まった場所への対処」から始まる方が実態に合っている。