非エンジニアのためのAIの頼み方｜技術より効いた6つのこと

効いたのは技術ではなく、頼み方だった

このブログではここまで、業務をどう自動化したかを事例として書いてきた。書類の仕分け、記入漏れの通知、46万件のファイル整理——どれも、こちらはプログラミングができないまま作ったものだ。

一通り書き終えて振り返ってみると、うまくいったかどうかを分けていたのは技術の知識ではなかった。何かを覚えたから作れるようになったわけではない。変わったのは頼み方のほうだ。

そして面白いのは、身についたコツのほとんどがAI特有のテクニックではないことだった。人に仕事を頼むときとほぼ同じだったのだ。

この記事では、実際に失敗したり助かったりしながら身につけた6つを書いておきたい。

① 言葉で説明できないなら、画面を見せる

これがいちばん即効性があった。

初めて触るツールは、画面の各部分に何という名前が付いているのかが分からない。だから言葉で説明できない。

「右上の……なんか歯車みたいなやつの下に出てくる、青い文字の部分」

こんな説明で伝わるはずがない。だから画面を撮って貼り付けて、「これのどこを押せばいい？」と聞く。

用語を知らなくても質問できるようになると、調べる時間がまるごと消える。「この機能の正式名称は何だろう」と検索する手間がなくなるからだ。

（この点は使うAIによってかなり差が出た。詳しくはClaudeとCopilotを使い比べた話に書いている）

② 「何が起きているか分からない」まま聞いていい

非エンジニアがいちばん躊躇するのは、たぶんここだと思う。きちんと整理してから聞かないと失礼な気がする、という感覚だ。

でも実際には、こんな聞き方で十分だった。

「フィルターが効かない。空の行があるはずなのに0件になる。なんで？」

症状しか言えていない。原因の見当もついていない。それでも会話は成立するし、むしろこちらが思いつかない仮説を出してもらえる。

このときの答えは「列の名前に、目に見えない文字が混ざっている可能性がある」だった。自力では一生たどり着けなかったと思う。

分からないことを分からないまま渡していい。 ただし、次の点だけは押さえておく必要がある。

③ 道筋は分からなくていいが、ゴールだけは自分で決める

②と矛盾するようだが、「何がどうなってほしいか」だけは自分で決めておく必要がある。

• ❌ 「この作業を効率化したい」 → 何をもって効率化かが分からない
• ⭕ 「毎朝この表を開いて未入力を探している。これを自動で知らせてほしい」

道筋（どうやるか）は知らなくていい。むしろそこを一緒に考えるのがAIの得意分野だ。でもゴール（どうなったら成功か）を決められるのは自分だけだ。ここを預けてしまうと、それらしいけれど的外れなものが出てくる。

自分の場合、AIに相談するときの型はだいたいこの4つを揃える形に落ち着いた。

この4つが揃っていると、たいてい一発で話が進む。逆に足りないと「これはどうしますか？」の往復が増えて、時間も費用もかかる。

④ 迷ったときにどちらへ倒すかを、先に決めて渡す

これは失敗しかけて学んだことだ。

46万件のファイルを「消していいもの／残すもの」に仕分けてもらったとき、最初に決めたルールがこれだった。

迷ったら全部「要確認」に入れる。

AIに「たぶん消していいと思います」と判断させない、ということだ。確信が持てないものはすべて人間が見る側に回す。

判断を任せるときは、正解の基準よりも「迷ったときの倒し方」を決めておくほうが大事だと感じている。人に仕事を頼むときも同じで、「困ったら止めて相談して」と言っておくかどうかで結果が変わる。

（この話は46万件の整理の記事に詳しく書いた）

⑤ 毎回言うことは、書いて置いておく

AIとの会話は、次に新しく始めたときには引き継がれない。前回どれだけ丁寧に説明していても、翌日にはゼロからになる。

だから毎回同じ説明をするはめになる。これが地味に効いてくる。時間もかかるし、従量課金の環境なら費用にも直結する。

解決策は単純で、決まりごとを文書にして置いておくこと。しかもこれは、2段階に分けられる。

全体に効くもの（グローバル指示）

設定画面に書いておくと、どの作業をするときにも効く。ここに書くのは「どの仕事でも変わらないこと」だけにしている。

• 呼び名や口調
• 確認のやり取りを最小限にする方針
• 費用を意識してほしいという方針

その業務だけに効くもの（作業フォルダの指示書）

業務ごとのフォルダに CLAUDE.md という名前の文書を置くと、そのフォルダで作業するときだけルールが効く。自分が書いているのはこういうことだ。

• ファイル名やフォルダの付け方のルール
• 処理が終わったら完了の合図を残すこと
• この業務で使う言葉の定義

迷ったら業務フォルダ側に書くのがいいと思う。全体に書いたことは全部の作業に付いて回るので、増やしすぎると毎回それを読ませることになるし、他の業務では邪魔になる。

一度書いておけば、毎回口頭で頼まなくてよくなる。**「同じことを二度説明したら、それは文書にすべきサイン」**だと思っている。

（書類の仕分けの記事で作った仕組みも、この文書があって初めて一言で動くようになった）

⑥ 考える場所と、動かす場所を分ける

最後は使い分けの話。

社内のAIは使った分だけ費用がかかる。だから迷いながら試行錯誤する作業を、そこでやらないようにしている。

• 個人の環境＝設計室。どう作るか迷う段階、原因の切り分け、失敗しながらの試行錯誤
• 社内の環境＝実行エンジン。やることが固まったタスクだけを、完成した指示として渡す

これを分けてから、無駄なやり取りがかなり減った。ぼんやりした状態のまま本番環境に持ち込むと、確認の往復が積み上がってしまうからだ。

（この考え方は最初の記事に書いた通り、いちばん最初に決めたルールでもある）

結局、人に仕事を頼むのと同じだった

6つ並べてみて改めて思うのは、そのほとんどが人に仕事を頼むときの作法と変わらないということだ。

• ゴールを伝える
• 迷ったときの方針を決めておく
• 毎回言うことはマニュアルにする
• 試作と本番を分ける

どれも、後輩に仕事を引き継ぐときにやっていることだと思う。AI特有の特別なテクニックはほとんど要らなかった。

逆に、明確にAIならではだと感じたのは2つ。画面を撮って見せられることと、前回のことを覚えていない前提で毎回渡す必要があること。この2つだけ意識しておけば、あとは普段の仕事の感覚がそのまま使える。

「プロンプトの書き方」を勉強しないと使えないのでは、と身構えている人がいたら、そんなに構えなくて大丈夫だと伝えたい。少なくとも自分は、特別な書き方を覚える前に、ここまで作れるようになった。