【本ページはアフィリエイトプログラムによる収益を得ています】
AIを仕事で使っていると、何度も同じ言葉が頭に浮かぶことがあります。
「そうじゃないんだけどなぁ……」
特に多いのが、画像を生成してもらったときです。
出来上がった画像そのものが悪いわけではありません。
むしろ、こちらが渡した情報をもとにAIなりに解釈して
よく作っていると思うこともあります。
それでも、私の頭の中にあったものとは違う。
「もう少し、この画像の雰囲気に寄せてほしかった」
「構図はそのままで、人物だけ変えてほしかった」
「ポーズを参考にしてほしかっただけなのに」
そんなことが起こります。
そこで改めて自分が出した指示を見てみると
そもそも私は
「何を参考にしてほしいのか」
を十分に伝えていなかったりします。
私の頭の中には完成形があります。
でもAIからすれば
その完成形を見ることはできません。
一方で、こちらが明確に指示しているのに
AIがその条件を守らないこともあります。
文章を書くときに
「一人称は『私』で統一してください」
と指定したのに、途中から「俺」が混ざる。
文字数を指定しても、想定した範囲から外れる。
語尾や文章のルールを決めても
長い文章になるとどこかが崩れる。
こちらが伝えていないからズレる場合と
伝えたのに守られない場合。
同じ「そうじゃないんだけどなぁ」でも
原因は同じではありません。
私はこれまで、ChatGPTやCodex、Claude Codeなどを
実際の仕事で使ってきました。
その中で、AIへの指示について考えるとき
ある考え方が自分には一番しっくりくるようになりました。
「何も知らない新卒社員に、この仕事を任せるなら、私はどう説明するだろう？」
これはAIを使い始めて
突然思いついた考え方ではありません。
私はこれまで役職者や管理職として
後輩や部下へ仕事を頼む立場を経験してきました。
その経験を振り返ってみると
人へ仕事を任せることと
AIへ仕事を任せることには
意外と共通する部分があります。
この記事では
いわゆる「最強のプロンプト」や
コピーして使える魔法の命令文を
紹介するつもりはありません。
私自身が何度も「そうじゃない」を経験する中で
AIへ仕事を渡すときに何を意識するようになったのか。
そして、その指示を残していくことが
結果として自分の仕事そのものを
整理することにもつながってきた話を書いてみます。
AIとの「そうじゃない」には、少なくとも2種類ある
AIから期待と違う結果が返ってきたとき
以前の私は単純に
「うまくいかなかった」と考えていました。
でも仕事で使う回数が増えるにつれて
同じ失敗に見えても原因が違うことに気づきました。
大きく分けると、少なくとも二つあります。
私が必要なことを伝えていないケース。
もう一つは
伝えた条件をAIが守っていないケースです。
この二つを分けて考えるだけでも
その後の修正がかなりしやすくなります。
私が伝えていないから、AIなりに解釈した
分かりやすいのが画像生成です。
たとえば参考になる画像を一枚渡して、
「この画像のイメージで作ってください」
と頼んだとします。
人間である私は、その時点ですでに頭の中に
「どこを参考にしてほしいか」があります。
色味なのかもしれません。
構図なのかもしれません。
人物のポーズなのかもしれません。
全体の空気感なのかもしれません。
あるいは構図も背景もそのままに近い状態で
人物の顔だけを別のものへ変えてほしいのかもしれません。
ところが、それを言葉にせず「このイメージで」とだけ
伝えれば、AIは自分で解釈するしかありません。
そしてAIは、与えられた情報の中から
「おそらくこういうことだろう」
と判断して画像を作ります。
その結果がAIにとって最善と思える答えだったとしても
私にとっての最善とは限りません。
ここで起きているのは
AIが私の指示に反抗したわけではありません。
私の脳内にしか存在していない情報を
AIが知らなかっただけです。
参考画像を渡しても「何を参考にするか」までは伝わらない
これは画像生成を繰り返す中で
かなり実感するようになりました。
参考画像を渡すこと自体は有効です。
実際、画像を見せて「このイメージで」と頼めば
文章だけで説明するよりも
近い色味や構成になることがあります。
ただし、それでも十分とは限りません。
「この画像の色味を参考にしてください」
「人物のポーズだけを参考にしてください」
「構図は参考にして、人物そのものは別にしてください」
「全体の柔らかい雰囲気を寄せてください」
このように、参考資料のどこを参考にしてほしいのか
まで伝えた方が、自分の意図には近づきやすくなります。
考えてみれば、人間に頼む場合でも同じです。
デザイナーへ一枚の画像を見せて
「こんな感じで」とだけ言えば
相手はどの要素を重要視しているのか
判断しなければなりません。
AIだから特別なのではなく
そもそも私自身が完成形を十分に
言語化できていなかったとも言えます。
伝えたのに、AIが守らないこともある
ただし、ここは間違えたくありません。
AIから期待と違う結果が返ってきたとき
何でも「人間の指示が悪かった」で
済ませるつもりはありません。
明確に指定したことが守られない場合もあります。
文章作成であれば
一人称を「私」と指定したのに
「俺」が混ざることがあります。
文章量を指定しても誤差が出ることがありますし
文体や語尾のルールを決めていても
長くなるにつれて一部が崩れることもあります。
これは先ほどの画像生成とは事情が違います。
こちらが伝えていなかったのではなく
伝えた条件が出力に反映されなかった
わけです。
人間側の指示不足
↓
必要な条件を追加する
↓
再実行する
明確に指示済み
↓
AIが条件を守っていない
↓
出力を確認して修正させる
この二つを分けて考えるようになってから
私はAIとのズレが起きたときに
まず「どちらだろう」と見るようになりました。
「よしなに」では、人間にだって伝わらない
AIへの指示について考えていると
以前から自分が人に仕事を頼むときに
意識してきたことと
よく似ていることに気づきます。
私はこれまで役職者や管理職として
後輩や部下へ仕事を頼む立場を経験してきました。
そこで何度も感じてきたのが、
「よしなに」では伝わらない
ということです。
私は後輩や部下へ仕事を頼む立場を経験してきた
長く同じ仕事をしていると
自分にとっては当たり前になっていることが
増えていきます。
どの順番で進めるか。
どこを確認するか。
何が起きたら一度止めるか。
誰に報告するか。
どこまでできたら
「完了」と判断するか。
経験を積んだ人間は
こうしたことを意識せず
処理している場合があります。
ところが、新しく入ってきた人には
その「当たり前」がありません。
そこで、
「これ、やっておいて」
とだけ言っても、こちらが想像した通りに
仕事が進むとは限りません。
こちらは
「当然ここまでやるだろう」と思っている。
相手は
「頼まれたのはここまでだ」と思っている。
結果を見てから、
「いや、そこまでやってほしかったんだけど……」
となる。
AIを使っているときの
「そうじゃないんだけどなぁ」
と、かなり似ています。
細かく言えばいい、というものでもなかった
では、何もかも細かく説明すればいいのか。
人への指示では
それもうまくいかないことがあります。
あれをやって、次にこれをやって
そのときここを確認して
もしこうだったらこちらへ行って
その後はこれを……。
一度に大量の指示を出せば
覚えられなかったり、途中で抜けたりします。
説明する側は「全部言った」
と思っています。
でも、仕事をする側からすれば
情報が整理されていません。
だから私は、人へ何かを頼むとき、
できるだけ端的に
しかし必要なことは明確に伝えること
を意識してきました。
必要であれば
後から見返せる指示書や資料を用意する。
口頭ですべて覚えてもらうのではなく
分からなくなったら戻れる場所を作っておく。
この考え方は
AIへ仕事を任せるようになってからも
そのまま使えると感じています。
「これやって」ではなく「どうしてほしいのか」を伝える
たとえば、人に、
「これやって」
と頼んだとします。
言われた側からすれば、
「どうやって？」
となります。
「ここへ行って」
と言えば、
「いつまでに？」
「何で行けばいい？」
「どこへ着けば完了？」
という情報が必要になるかもしれません。
「これに合う物を買ってきて」
と頼んだ場合も同じです。
何をもって
「合う」と判断するのか。
予算はいくらなのか。
どこで買うのか。
そもそも買う物をこちらで決めているのか
それとも候補から相談して決めるのか。
「買ってきて」という一言の裏には
いくつもの判断があります。
私なら、
「まず、これには何が合うと思うか話し合おう」
「候補をいくつか出そう」
「それがどこで買えるか調べよう」
というように、必要に応じて仕事を分けます。
「これやって」
↓
何を？
↓
何のために？
↓
どうやって？
↓
いつまでに？
↓
どこまでやれば完了？
こう考えると
「指示を出した」ことと、「相手が仕事を実行できる状態にした」ことは同じではない
と分かります。
これは人間だけではなく、AIに対しても同じだと思っています。
そこで私は「新卒社員ならどう説明するか」と考える
AIへの指示を考えるとき
私がよく頭に置いているのが
「何も知らない新卒社員」です。
ここでいう新人とは
「能力が低い人」
という意味ではありません。
むしろ能力そのものは十分にある。
ただし、こちらの会社や仕事について
まだ何も知らない人という意味です。
「新人」は能力が低いという意味ではない
入社したばかりの人は
会社独自のルールを知りません。
これまで何があったのかも知りません。
顧客ごとの事情も知りません。
「いつもの方法」も知りません。
上司の頭の中にある完成形も知りません。
でも、それは本人の能力とは別の話です。
必要な情報を渡して仕事を教えれば
できるようになることはたくさんあります。
AIも、私はそれに近い感覚で見ています。
調査ができる。
文章が書ける。
画像が作れる。
コードが書ける。
PC上の作業まで
任せられる場合がある。
能力だけを見ると
驚くほど多くのことができます。
でも、
「私の仕事ではどうするのか」までは
最初から知っているとは限りません。
頭の中の「当たり前」は、相手には見えない
人に仕事を教えるときも
AIへ仕事を渡すときも
難しいのはここです。
自分にとって当たり前に
なりすぎていることほど
説明から抜けます。
そして抜けていることに
自分自身が気づいていません。
AIから想定外の答えが返ってきて初めて
「ああ、そこを言ってなかったか」
と気づきます。
ある意味では、AIがこちらの仕事の曖昧な部分を
見つけてくれているとも言えます。
AIへの指示は、呪文を書くことではなく、新しく入った人に仕事を教えることに近い。
私は今のところ、この考え方が一番しっくりきています。
私がAIへ仕事を渡すときに確認する6つのこと
では実際に、AIへ仕事を頼むときに何を伝えるのか。
私は大きく分けて、次の6つを意識しています。
目的
↓
前提
↓
材料
↓
手順
↓
禁止事項
↓
完成条件
これは
「毎回この順番で長いプロンプトを書かなければならない」
という意味ではありません。
必要な情報が抜けていないか確認するための項目
くらいに考えています。
1．何のためにやるのか――目的
最初は、その仕事を何のためにするのかです。
単に、
「この文章を書いて」
ではなく、
「誰に、何を伝えるための文章なのか」
まで分かれば、判断基準が増えます。
目的を伝えることは
細かな指示を減らすことにもつながります。
途中で判断が必要になったとき
「何のための仕事なのか」が分かっていれば
その目的に合う方向をAIが考えられるからです。
逆に目的がなければ
個別の作業を一つずつ指定する必要が出てきます。
2．何を知っておく必要があるのか――前提
次は前提です。
誰が対象なのか。
これまでどういう経緯があったのか。
どんな環境で作業するのか。
すでに決まっていることは何か。
変更してよいことと
変更してはいけないことは何か。
人間同士なら「当然知っているだろう」
と思う情報ほど、ここへ入ります。
特に長く続いている仕事では
「いつものやり方」が大量に存在します。
その「いつもの」を知らない相手へ仕事を渡すなら
必要な部分は言葉にしなければなりません。
3．何を使って仕事をするのか――材料
仕事に使う材料も明確にします。
Excelなのか。
CSVなのか。
画像なのか。
テキストファイルなのか。
参考資料なのか。
複数の資料があるなら
どれを正として扱うのかも重要です。
人間でも、古い資料と新しい資料を
同時に渡されて
「よろしく」と言われたら困ります。
AIも同じです。
「このファイルを基準にしてください」
「こちらは参考資料です」
と役割を分けるだけでも
判断の迷いを減らせます。
4．どういう順番で進めるのか――手順
仕事によっては
順番そのものに意味があります。
Aを確認してからBを行う。
Bが終わったことを確認して
Cへ進む。
一件終わるたびに確認する。
全部の登録が終わってから削除する。
こうしたルールがあるなら
それを明示します。
特に同じ処理を大量に繰り返す仕事では
途中で独自の方法へ変えられると困ります。
逆に、順番に意味がない仕事なら
そこまで細かく指定する必要はありません。
5．何をしてはいけないのか――禁止事項
私は「やってほしいこと」だけでなく
「やってほしくないこと」も重要だと思っています。
このファイルは変更しない。
元データは削除しない。
この項目は勝手に補完しない。
分からない場合は推測して進めない。
人間に仕事を頼む場合でも
触ってはいけないものがあるなら
先に伝えます。
AIについても同じです。
特にPC上の作業を任せる場合
やってほしいこと以上に
「ここから先は触らない」
という境界線が重要になることがあります。
6．どこまでできれば終わりなのか――完成条件
最後が完成条件です。
これは意外と大切です。
「終わりました」
とAIが言ったとき、
人間側が考える
「終わった」
と同じ状態なのか。
成果物は何か。
どこへ保存するのか。
何件処理すれば完了なのか。
最後に何を確認するのか。
完成条件が曖昧だと
AIと人間で
「仕事が終わった」
の意味が違ってしまいます。
目的 → 前提 → 材料 → 手順 → 禁止事項 → 完成条件
私が意識しているのは、この6つです。
ただし、毎回6項目を長々と
書いているわけではありません。
必要なのは長文ではなく
その仕事を実行するために必要な情報が揃っていることです。
「このExcelを整理して」を仕事の指示に変えてみる
少し分かりやすくするために
簡単な例を考えてみます。
これは私の実体験ではなく
説明用の架空例です。
AIへExcelファイルを渡して、
「このExcelを整理してください」
と頼んだとします。
一見すると普通の指示です。
でも、よく考えると「整理」が
何を意味するのか分かりません。
「整理して」では、完成形が人によって違う
不要な行を削除することなのか。
空白を埋めることなのか。
列を並べ替えることなのか。
表記を統一することなのか。
重複データを削除することなのか。
見た目を整えることなのか。
依頼した人の頭の中には
「整理された状態」があるかもしれません。
でも、それをAIは知りません。
人間の部下へ「このExcel、整理しておいて」と
頼んだ場合でも、おそらく同じ問題が起きます。
6項目で考えると、足りない情報が見えてくる
そこで先ほどの6項目を使います。
たとえば目的は、
「顧客一覧を営業担当者が確認しやすい状態にする」
かもしれません。
前提として、
「1行目は見出しで、2行目以降が顧客データ」
と伝える。
材料は、
「今回渡したExcelファイルだけを使用する」
と決める。
手順は、
- 重複データを確認する
- 電話番号の表記を統一する
- 都道府県順に並べる
といった形にできます。
禁止事項として、
- 顧客そのものを勝手に削除しない
- 不明な電話番号を推測して補完しない
- 元ファイルを上書きしない
と指定する。
完成条件は、
「整理後のファイルを別名で保存し、
変更した内容を最後に報告する」
とする。
ここまで分かれば、「Excelを整理して」よりも
仕事の完成形がかなり明確になります。
「Excelを整理して」
↓
何のために？
↓
何を整理する？
↓
何を変更してよい？
↓
何を変更してはいけない？
↓
どうなれば完成？
長いプロンプトを作ることが目的ではない
ここで誤解したくないのは
「AIには長文で指示しましょう」という話ではないことです。
一行で十分な仕事なら、一行でいいと思います。
「この画像をPNGからJPEGへ変換して
同じフォルダへ保存してください」
これで必要な情報が揃っているなら
それ以上説明を増やす必要はありません。
逆に複雑な仕事なのに、
「いい感じにやって」
だけで済ませれば
AIが判断しなければならない部分が増えます。
端的であることと、曖昧であることは違います。
私はここを意識するようになりました。
AIにどこまで考えさせるかも、仕事によって変わる
もう一つ難しいのが
どこまで細かく指定するかです。
人間への指示でも
何から何まで指示すれば
いいわけではありませんでした。
AIでも同じだと思っています。
画像生成では、曖昧さが結果を大きく変える
先ほどの画像生成なら、
「この画像の雰囲気で」
とだけ頼めば
AIが判断する範囲はかなり広くなります。
それが悪いわけではありません。
自分でも完成形が決まっておらず
「AIならどう作るだろう」と見てみたいときには
むしろ自由度を残した方が
面白い結果が出ることがあります。
でも、
「構図は変えたくない」
「色味だけ寄せたい」
「人物のポーズは参考画像に近づけたい」
という絶対条件があるなら、そこは明確にします。
AIへ自由に考えてほしいところと
勝手に変えてほしくないところを分けるわけです。
アプリ制作では「良くも悪くも解釈して作ってくる」
Claude Codeなどに
小さなアプリを作ってもらうときにも
似たことを感じます。
こちらが漠然と
「こういうことができるものが欲しい」
と伝える。
するとAIは、その要求を解釈して
形にしてくれます。
これは非常に便利です。
私が細かな技術仕様を知らなくても
「こういうことをしたい」
から出発できます。
一方で、AIが補完した仕様が
私の意図と違えば、
「そこはそうじゃない」
となります。
良くも悪くも、AIが
空白を埋めてくれるわけです。
だから最初からすべてを決めるのではなく
出来上がったものを見ながら、
「ここはそのままでいい」
「ここは違う」
「ここはこうしてほしい」
と仕様を固めていく方法も使っています。
「守ってほしい部分」と「考えてほしい部分」を分ける
私が現在意識しているのは
この二つを分けることです。
絶対に守ってほしい部分は
できるだけ明確にする。
一方で、AIの提案や判断を使いたい部分には
ある程度の余白を残す。
全部を固定してしまえば
AIは単なる作業装置に近づきます。
全部を任せれば、こちらの意図とは
違う方向へ進む可能性が高くなります。
仕事によって、その中間を探す。
これはAIを使う上で
かなり重要な感覚だと思っています。
PC作業では「そうじゃない」が比較的少ない理由を考えてみた
こうして振り返ってみると
私の場合、PC上の作業をAIへ任せるときには
「そうじゃない」
が比較的少ないように感じます。
なぜだろうと考えると、AIが特別に正確だからというより
私自身が最初から慎重に指示している
ことも関係している気がします。
私自身が慎重に指示を作っている
PC上のファイル操作や大量処理は
失敗したときの影響が大きくなります。
間違ったファイルを変更する。
必要なデータを削除する。
別の場所へ保存する。
大量の処理を間違ったルールで進める。
こうしたことが起きると困るので
私は自然と慎重になります。
作業内容を箇条書きにしたり
順番を決めたり
触ってほしくない部分を指定したりします。
つまり、画像生成などと比べると
人間側が最初から仕事を細かく整理して渡している
わけです。
必要な条件を具体的に渡すから、差異が小さくなる
もちろん、これだけで
「指示を細かくすればAIは間違えない」
と断定することはできません。
ただ、私自身の経験では
仕事の目的やルールを明確にしている作業ほど
大きな認識違いは起きにくいように感じています。
逆に、こちらが漠然としたイメージだけを渡した仕事では
AIの解釈する範囲が広くなります。
結果の振れ幅も大きくなる。
そう考えると、「AIがどれだけ賢いか」だけではなく
人間がどれだけ仕事を説明できているか
も結果に影響しているのだと思います。
それでも最後の確認は人間がする
ただし、具体的に指示したからといって
すべて任せきりにはしません。
先ほど書いたように、「私」と指定したのに
「俺」が混ざるようなことはあります。
人間でも指示を聞き間違えたり
作業を間違えたりします。
AIにも確認は必要です。
私は「細かく指示したから大丈夫」ではなく
指示することと確認することを
セットで考えるようにしています。
CodexでもClaude Codeでも、基本は同じだった
以前の記事では、CodexとClaude Codeを
実際の仕事で使って感じた違いを書きました。
得意な仕事や仕事の進め方には違いがあります。
それでも、今回のテーマである
「仕事をどう渡すか」という部分では
基本的な考え方は同じでした。
Codexでは、決めたルールを明確に渡す
私はGoogleビジネスプロフィール関連の作業で
38店舗を対象に商品登録380件
商品削除152件という処理を
AIへ任せたことがあります。
こうした大量処理では
途中で作業ルールが変わってしまうと
困ります。
どのデータを見るのか。
既存の項目とどう照合するのか。
どの順番で登録するのか。
登録と削除のどちらを先にするのか。
一店舗ずつ確認するのか。
ルールが決まっている仕事だからこそ
それをAIへ伝える必要があります。
私の感覚では、Codexはこうした
「決めた仕事を実行してもらう」
用途で、指示がしっかりしているほど
使いやすく感じています。
Claude Codeでは、複雑な作業ほど仕様を残す
Claude Codeでは、画像ファイルの変換や
複雑なルールに従った大量のテキストファイル生成などを
任せています。
さらに、自分用のローカル画像検索アプリを
作ってもらったこともあります。
参考画像やキーワードを入れると
指定したローカルフォルダの中から
条件に合う画像や類似画像を探し出すものです。
こうした仕事では
最初から私自身が技術的な実装方法を
すべて決めているわけではありません。
「こういうことをしたい」
という目的から始まり
AIとやり取りしながら形にしていきます。
だからこそ、途中で決まった仕様を残すことが重要になります。
AIが変わっても「何をしてほしいか」を決めるのは私だった
CodexとClaude Codeでは、私の使い方も違います。
でも、
「何のためにやるのか」
「どこまでやってほしいのか」
「何を勝手に変えてはいけないのか」
を決めるのは、どちらを使う場合でも私です。
AIが変われば操作方法や得意なことは変わります。
それでも
仕事の目的を決めて相手へ伝えるという部分は、人間側に残ります。
AIが失敗したら、まず「どこでズレた？」を見る
AIから想定と違う結果が返ってきたとき
私は以前より原因を見るようになりました。
単に、
「違う。やり直して」
だけで終わらせると
また同じことが起きるからです。
そもそも私は指示していたか
まず確認するのは
自分が本当にその条件を伝えていたかです。
「当然こうすると思っていた」
「前もそうだったから今回も同じだと思っていた」
「この参考画像を見れば分かると思っていた」
それは、AIへ実際に伝えた指示とは別です。
自分の頭の中にしかなかったなら
次は言葉にする必要があります。
指示したのにAIが守らなかったのか
逆に、明確に書いてあるのに
守られていない場合もあります。
一人称。
文字数。
保存場所。
変更禁止の項目。
こうしたものを明示していたにもかかわらず
違う結果になったなら
こちらの説明不足とは別の問題です。
この場合は、AIへ条件を再確認させたり
出力を修正させたりします。
AIは何を「正解」だと解釈したのか
もう一つ見るのが、
「なぜAIはこうしたのだろう？」
という部分です。
画像生成なら
参考画像の構図まで寄せた。
文章なら、読みやすさを優先して
こちらの指定した構成を変えた。
アプリなら、こちらが指定していない機能を
「便利だろう」と考えて追加した。
AIなりの理由が見えることがあります。
それを確認すると、
「なるほど、私の指示だとそう読めるのか」
と気づくことがあります。
同じ失敗を、次回の指示へ戻す
そして大切なのが
同じ失敗をその場の修正だけで
終わらせないことです。
一度
「ここは変更しないでほしかった」
という問題が起きたなら
次回は「変更禁止」と書く。
「この順番でやってほしかった」
なら、手順へ追加する。
「分からない場合に勝手に補完された」
なら、「判断できない場合は確認する」
と追加する。
実行する
↓
結果を確認する
↓
どこでズレたかを見る
↓
指示・仕様を修正する
↓
次回また使う
同じ説明を何度もするなら、その説明自体を仕事の仕様にしてしまえばいい。
私はだんだん、そう考えるようになりました。
私はプロンプトを「仕様書」として残すようになった
AIを使い始めた頃は
その場のチャットで仕事が終わることも
多くありました。
でも、仕事で何度も使うようになると
それではもったいないと感じるようになります。
うまくいった指示。
失敗して追加した条件。
作業の順番。
保存場所。
注意事項。
これらは次の仕事でも使えます。
そこで私は、重要な仕事では
仕様書として残すようにしています。
大事な仕事は、箇条書きで条件を整理する
私はAIへの指示を
できるだけ端的に伝えるようにしています。
ただし重要な部分は細かくします。
そのとき便利なのが箇条書きです。
文章で長々と説明するより、
- このファイルを使う
- この順番で処理する
- この項目は変更しない
- 完了後はここへ保存する
- 分からない場合は勝手に進めない
と整理した方が、私自身も確認しやすくなります。
AIのためだけではありません。
自分が何を頼んだのかを
自分で確認するためにも、仕様書は役立ちます。
作業フォルダに仕様書を残す
繰り返し使う仕事では
作業フォルダの中に仕様書を残すようにしています。
そうしておけば、数週間後や数か月後に
同じ仕事をするときにも使えます。
人間は忘れます。
「あのとき、どういうルールでやったっけ？」
となることがあります。
そのとき、チャット履歴を延々と探すより
作業フォルダに仕様が残っている方が分かりやすい。
これはAIを使うようになってから
より意識するようになったことです。
「仕様書として残して」とAI自身に頼む
そして便利なのが
仕様書を自分だけで作らなくてもいいことです。
AIとやり取りしながら仕事が完成したら、
「今回決まった内容を
次回使える仕様書として残してください」
と頼むことができます。
最初の指示。
途中で変更したこと。
最終的に決まったルール。
注意事項。
こうした内容をAI自身に整理してもらう。
もちろん、出来上がった仕様書は人間が確認します。
でも、ゼロから自分でまとめ直すよりずっと楽です。
AIへ仕事をさせるだけでなく
AIに「次回AIへ仕事を頼むための資料」まで作らせる。
これも、私が実務でAIを使う中で便利だと感じている方法です。
別のAIへ仕事を渡すときにも使える
仕様書を残すもう一つの利点は
別のAIへ仕事を引き継げることです。
実際、あるAIで進めていた仕事を
事情があって別のAIへ移すことがあります。
そのとき、作業内容が私の頭の中にしかなければ
最初から全部説明し直さなければなりません。
でも仕様書が残っていれば、
「この仕事は、こういう目的で
こういうルールで進めています」
と渡せます。
もちろんAIが変われば
そのまま完全に同じように動くとは限りません。
それでも、ゼロから説明するよりは
引き継ぎやすくなります。
良いプロンプトは、一度きりの命令文ではなく、次の仕事にも使える仕様書になっていく。
私は今、プロンプトをそんなふうに考えることが増えました。
AIへの指示を考えていたら、自分の仕事まで整理されてきた
ここまで来ると、少し面白いことが起きます。
最初は「AIへうまく指示するため」に始めたはずなのに
だんだん自分自身の仕事が整理されていくのです。
「私は普段、どうやってこの仕事をしている？」と考える
AIへ仕事を任せるには、自分がやっていることを
説明しなければなりません。
すると、
「そもそも私は、何を基準に
判断しているんだろう？」
と考えるようになります。
長年やっている仕事ほど
感覚で処理していることがあります。
Aならこうする。
Bなら止める。
Cなら確認する。
自分では無意識にやっていたことを
AIへ説明するために言葉へ変えていく。
これは、思っていた以上に自分の仕事を見直す作業になります。
頭の中にしかなかった判断基準が言葉になる
仕事には、マニュアルに書かれていない判断が
たくさんあります。
「この場合は念のため確認する」
「このパターンだけは別処理にする」
「ここまでは担当者が判断してよい」
「ここから先は責任者へ確認する」
経験者にとっては当たり前でも
新人には分からない。
AIにも分からない。
だから説明する。
説明するためには、まず自分自身がその判断基準を
認識しなければなりません。
AIを使うことで、頭の中にあった暗黙のルールが
外へ出てくるわけです。
言葉になれば、再現できるようになる
判断基準が言葉になれば、次回も使えます。
AIを変えても使える。
別の担当者へ渡すこともできる。
自分自身が数か月後に
同じ仕事をするときにも使えます。
つまり、AIへの指示を考えていたはずが
結果として仕事の再現性を高めることにつながります。
AI用の仕様書が、人間への引き継ぎにも使える
ここは、管理職として仕事をしてきた
経験ともつながります。
後輩や部下へ仕事を渡すとき
口頭だけでは抜けが出る。
だから指示書があると助かる。
AIへ仕事を渡すときも同じです。
そしてAI用に作った仕様書が十分に整理されていれば
それは人間への引き継ぎ資料にもなります。
AIへ説明する
↓
仕事を言語化する
↓
仕様書として残す
↓
次回再利用する
↓
別のAIへ渡す
↓
必要なら人間へも引き継ぐ
ここまで来ると、AI活用は単なる
「作業を速くする道具」だけではありません。
自分の仕事を整理し、誰かへ渡せる形にするきっかけにもなります。
AIは「優秀だけれど、今日入ってきた新人」くらいで考える
私はAIを人間と同じだと言いたいわけではありません。
AIと人間では当然違います。
ただ、「仕事をどう渡すか」を考えるとき
私は「優秀だけれど今日入ってきた新人」
くらいに考えると分かりやすいと思っています。
できることは多い。でも「うちのやり方」は知らない
能力は高い。
調べられる。
文章を書ける。
画像を作れる。
プログラムも作れる。
大量のファイルを
処理することもできる。
でも、
「うちではこうする」
「この仕事ではこれを優先する」
「この顧客の場合だけは違う」
という事情までは
こちらが伝えなければ分かりません。
だから仕事を教える。
そのために必要な前提を渡す。
そして結果を確認する。
私はこのくらいの距離感が
ちょうどいいと感じています。
やり取りを重ねれば「右腕」になっていく
もちろん、いつまでも
「今日入ってきた新人」
のままというわけではありません。
やり取りを重ねていけば
こちらが何を大切にしているのか
どんな形で仕事を進めたいのか
どういう結果を求めているのかが
少しずつ共有されていきます。
私自身、ChatGPTを「馬麟（ばりん）」と呼び
今では仕事の整理や分解
次に何をするかを考える場面で
右腕のような存在として使っています。
私が目的を決める。
馬麟と一緒に仕事を整理する。
必要に応じてCodexやClaude Codeなどへ
実行する仕事を割り振る。
最後に私が確認して判断する。
こうしたやり取りを繰り返していると
毎回すべてをゼロから説明する必要は
少なくなっていきます。
ただし、新しいプロジェクトや新しい作業を始めるときは
私はあえてもう一度「今日入ってきた新人」
として接するようにしています。
以前の仕事で使った前提が
今回も正しいとは限りません。
過去のやり方や別のプロジェクトの条件が混ざれば
かえって邪魔になることもあります。
だから新しい仕事では、
「今回は何のための仕事なのか」
「今回の前提は何か」
「今回守ってほしいルールは何か」
を改めて伝える。
その仕事に必要な情報を
いったん整理し直して渡します。
新人として仕事を教え
やり取りを重ねながら右腕になっていく。
そして新しい仕事では
また新人として必要なことから教える。
私は、このくらいの考え方でAIと付き合う方が
余計なものを混ぜずに仕事を始めやすいと感じています。
今日入ってきた新人
↓
目的・前提・ルールを教える
↓
仕事を任せる
↓
結果を確認する
↓
ズレを修正する
↓
仕様書へ残す
↓
やり取りを重ねる
↓
仕事を分かっている「右腕」へ
新しいプロジェクト
↓
もう一度「新人」として前提から共有する
教えすぎても、教えなさすぎても仕事は回りにくい
人間の新人に、一挙手一投足まで
すべて指示し続けたら
自分で考える余地がありません。
逆に、
「全部よしなに」
では困ります。
AIも似ています。
絶対に守ってほしい条件は伝える。
自由に考えてほしいところは任せる。
途中でズレたら修正する。
そして、うまくいったやり方は残す。
この繰り返しです。
任せるところまでが人間の仕事、とは限らない
「AIへ任せる」という言葉だけを見ると
指示を出した瞬間に人間の仕事が
終わるようにも聞こえます。
でも、少なくとも私の使い方では
そうではありません。
仕事を渡す。
結果を見る。
問題があれば原因を考える。
指示を直す。
必要なら仕様書を更新する。
そこまで含めて「任せる」だと思っています。
最後の目的と判断は人間が持っておく
AIへ作業を任せることと
仕事そのものを丸投げすることは
別です。
何のためにその仕事をするのか。
何を良しとするのか。
最終的に採用するのか。
そこは人間が持っておく。
私の場合は、自分が目的を決め
必要に応じてChatGPTに整理や分解を手伝ってもらい
CodexやClaude Codeなどへ仕事を割り振り
最後に自分で確認するという使い方が増えています。
AIを一人の万能な存在として見るのではなく
それぞれに役割を持たせる。
そして、その役割を機能させるために
必要なのが
「仕事をどう伝えるか」
なのだと思います。
「プロンプトを書く」より「仕事を教える」と考えてみる
AIへの指示がうまくいかないと、
「もっと高度なプロンプトを書かなければ」
と思うことがあります。
もちろん
プロンプトの書き方を学ぶことに
意味がないとは思いません。
目的によっては、細かな技術や
定型的な書き方が役立つこともあるでしょう。
ただ、私自身が実際の仕事でAIを使う中で
役に立ったのは、もっと基本的な考え方でした。
「これを入社初日の新人に渡して、本当に仕事ができるだろうか？」
次にAIへ何かを頼むとき
私はこれを考えます。
何のためにやるのか。
必要な前提を渡しているか。
何を使えばいいのか。
順番に意味はあるのか。
やってはいけないことはあるか。
どこまでできれば完成なのか。
そして、全部を細かく決めるのではなく
AIに考えてほしいところには裁量を残す。
それでも期待と違う結果になったら
「私はその条件を本当に伝えていたか？」
を確認する。
伝えていなければ、次は指示へ追加する。
伝えたのに守られていなければ
AI側のミスとして修正する。
どこで解釈が分かれたのかを見て
必要なら仕様書へ戻す。
そうやって指示を改善していくと
一度きりだったプロンプトが
少しずつ変わっていきます。
次回も使える。
別のAIにも渡せる。
作業フォルダへ残せる。
必要なら人間にも渡せる。
プロンプトが「仕事の仕様書」に
変わっていくのです。
そして、その仕様書を作るためには
自分自身が仕事を
理解していなければなりません。
「なぜこの作業をしているのか」
「私は何を見て判断しているのか」
「何が起きたら止めるのか」
「どこまでできれば終わりなのか」
AIへ説明しようとすることで
自分の仕事について考える。
自分の仕事を言葉にする。
言葉になった仕事を
もう一度AIへ渡す。
私はAIを使い始めたことで
作業そのものが速くなっただけではなく
こうした
「仕事の渡し方」について
改めて考える機会が増えました。
AIを使いこなすというと
何か特別な技術が必要なように聞こえます。
でも私がやっていることの根っこは
管理職として後輩や部下へ仕事を頼んできたときと
それほど変わらないのかもしれません。
「よしなに」で済ませない。
だからといって
何から何まで細かく指示しない。
目的を伝える。
必要な条件を伝える。
守ってほしいところを明確にする。
考えてほしいところは任せる。
分からなくなったときに
戻れる指示書を残す。
そして、結果を確認する。
AIへの指示で
「そうじゃないんだけどなぁ」
と感じたとき。
すぐに新しいプロンプトの
テクニックを探す前に
一度だけ、
「この指示を何も知らない新人に渡したとして
本当に私が望む仕事ができるだろうか？」
と考えてみる。
私は、それだけでもAIへの仕事の頼み方が
少し変わると思っています。
そして、その問いを繰り返しているうちに
整理されるのは
AIへの指示だけではありません。
自分自身の仕事も、少しずつ整理されていきます。