見出し画像

プロンプトは命令ではない。優秀な後任への引き継ぎ書だ（Obsidian仕事術②）

KumeHaya@データサイエンス起業家

「追加負担なく効率化が実現できます。」その一文を見た瞬間、この打ち合わせは始まる前から半分終わった、と思った。翌朝8時、私のデスクには、きれいに整えられたスライド一式が置かれていた。レイアウトは美しく、誤字もなく、見出しも論理的に並んでいるのに、中身を読んだ瞬間、背筋が冷え、嫌な予感がせり上がった。相手は、過去のIT導入で現場の手間を増やされ、何度も上層部から叱責されてきた製造業の部門長で、彼が恐れていたのは、システムが便利かどうかではない。

「また現場に、余計な入力作業が増えるのではないか」。

その不信が滲む真ん中に、スライドはきれいな顔で「本ツールの導入により、現場の業務は大幅に自動化され、追加負担なく効率化が実現できます」と記していた。きれいにラッピングされたまま、相手の急所を踏み抜いていた。

前日の夜、私は翌朝の顧客訪問を引き継いでもらうメンバーに、たった一言の言づけと、過去の打ち合わせ記録が詰まったフォルダのパスだけを伝えていた。

「鈴木さん、この新規事業の提案資料、いい感じにまとめておいて」。

議事録も、過去案も、顧客別の断片も一応そろっており、優秀な彼なら拾ってくれるはずだと思っていたが、彼の手元に届いたのは材料の保管先だけだった。企画の狙い、相手が怖がる点、信頼を壊す語、良い準備の合格ライン。その一式を、私は何ひとつ説明していなかった。悪いのは鈴木さんではなかった。私が知らせるべきだったのは、フォルダのパスではなく、その場で何を恐れ、何を守り、どこで口をつぐむべきかという、一人分の引き継ぎ書だった。

いま、私は画面の向こうにいる生成モデルにも、似た手つきをしている。短い願いと大量のファイルを積み、あとは察してくれることを期待する。返ってきた内容が外れていると、性能やセンスの問題にしたくなるが、胸に手を当てると、まだ外へ出していないものがある。顧客対応の怖さ、相手の記憶にこびりつく言い回し、こちらが口をつぐむべき場面。AI時代に必要なのは、神プロンプトを探す力ではない。自分の実務を、他人が再現できる形にする力だ。この記事で扱うのは、プロンプトの小技より手前にある、仕事の前提を外に出す作業である。


1. AIは、顧客の地雷を知らない

生成AIに何かを任せるとき、多くの人が短い一文を打ち込んで終わる。

「この記事を面白くして」
「この説明をもっと説得力ある感じにして」
「いい感じに要約して」。

言い方は違っても、やっていることは、あの日の私とあまり変わらない。背景も、相手の急所も、成功の基準も説明していない。それなのに、返ってきた案を見て、私たちは少しがっかりする。整っているけれど無難で、言いたいことと微妙にピントがズレていて、最後まで腑に落ちない。このズレは、AIの能力不足だけで起きるのではない。脳内に閉じ込めてある文脈を、相手が勝手に察してくれると甘えているから起きる。人間の後任に預けてもズレるものは、生成モデルに預けてもやはりズレる。

これは感覚論だけではない。
2023年に公表されたHBSなどの研究者による実験では、BCGのコンサルタント758人を対象に、生成AIが得意な領域では作業速度や品質を押し上げる一方、モデルの得意範囲を外れた複雑なタスクでは、使った人の方が正しい解に届きにくくなることが示された。論文では、境界外タスクで正答に至る割合が19ポイント低かったと報告されており、この数字は「AIを使えば常に賢くなる」という楽な期待に水を差す。怖いのは、雑に間違える場面より、見た目の品質が高いまま、きれいに外す場面だ。整っているから正しい、論理的に見えるから使えると思った瞬間、私たちは危険な地点へ踏み込む。

実際のビジネスシーンで考える。あなたが短い指示で顧客向けスライドの作成を任せたとする。「顧客インタビューの書き起こしメモを元に、新規事業の社内向け企画書を作成してください。説得力のある、論理的な構成にしてください」。このテキストを受け取ったモデルは、一般的な型を当てはめる。課題、解決策、導入後の姿、投資対効果、次のアクションが順番に並び、見出しはきれいで、文章も滑らかだ。そこで、「本ツールの導入により、現場の業務は大幅に自動化され、追加負担なく効率化が実現できます」という一文が顔を出す。提案らしいし、前向きでもある。上司に見せても怒られなさそうに見えるところが、かえって厄介だ。

ところが、相手の部門長は、「追加負担なく」という言葉を見た瞬間に不信感を抱く。現場入力の有無、初期マスタの整備担当、初月の問い合わせ窓口。その全部が、彼の中ではまだ解決していない。過去に「簡単だから」と言われて導入したITツールで現場が混乱した痛みは、まだ尾を引き、担当者の表情にこびりついている。モデルが火種を選んだのではない。私が、そこを火種だと教えていなかった。

2. プロンプトは、優秀な後任への引き継ぎ書である

文脈に依存する仕事では、入力欄の一文だけで勝負しないほうがいい。短く賢そうな指示より、優秀な後任へ残す申し送りに近いものが要る。面倒に見えるが、人に頼むときも本当はここで差が出ていた。正本にするファイル、古い数字、相手を怒らせる言い方、断定してよい範囲と仮説に留める範囲。そうした細部がなければ、優秀な人ほど一般的な正解へ向かい、案件の癖は置き去りになる。

生成モデルも同じだ。あなたの会社の過去の失敗も、顧客の口癖も、社内政治の細い亀裂も、昨日の打ち合わせであなたが感じた違和感も知らない。言葉にしていないものは、ないものとして扱われる。プロンプトを書く時間は、命令を格好よくする時間ではない。自分の仕事の前提を、次の人が読める形にする時間だ。ここでいう「後任」は、正式な人事異動の相手に限らない。明日の自分、同僚、外部パートナー、AIエージェント。文脈を知らない相手が同じ入口に立てるかを考えると、手元の仕事のうち、どこが暗黙知のまま残っていたのかが露呈する。

3. 引き継ぎ書にすると、出力はどこで踏みとどまるか

では、同じ頼みごとを「引き継ぎ書」として組み直すとどうなるか。まず、顧客事情として「過去のIT導入で現場の手間が増え、作業増を強く警戒している」と明記する。今回取りたい承認は、A事業部長からのPoC実施許可。参照するのは顧客インタビュー、現場担当者の不満メモ、システム移行時の作業手順書。合格ラインは、現場の残業を増やさず初月から試せる、と読み手が判断できること。避ける表現は、作業増の有無を安易に断定する言い方、自動化や画期性だけで押し切る抽象的な売り文句、現場の入力作業を小さく見せる説明。最後に、資料の骨子を各パート300字以内で作る、と形式だけ添える。

この形で渡すと、相手は無難な営業スライドの型へ逃げにくい。一般論に向かおうとした足が、ここで一度止まる。返ってくる案は、たとえばここまで具体化する。「導入初月は、現場に新しい入力作業を増やさない設計を前提にします。既存の日報データを取り込み、マスタ整備と問い合わせ対応は情報システム部が一次窓口を担います。現場側の変更点は、週次確認時のチェック項目を一つ足す範囲に限定します」。派手ではないが、事故率は下がる。相手が本当に疑っている点に先回りして答えているからだ。この場面では、強い文言で押すより、不信がほどける順番を外さないことの方が効いている。

顧客理解が、突然モデルの中に芽生えたわけではない。こちらが、案件の地図を差し出しただけだ。短い指示でも、タイポ修正や短いメールの整形、単純な変換なら十分なことはあるし、毎回長い引き継ぎ書はいらない。けれど、誰かを説得する説明、顧客や社内の意思決定に触れる資料、言いすぎると信頼を失う一節では、話は別だ。どう書かせるかの前に、何を守るかを人間が決める必要がある。

4. 一枚引き継ぎプロンプト：6つの空欄

6つの空欄は、穴埋めテンプレートではない。今回だけの事情、動かしたい相手、読ませる材料、合格の線、越えてはいけない境界、返してほしい形。この6つを先に並べるのは、仕事をきれいに説明するためではなく、どこから濃く書くべきかを決めるためだ。人へ任せるとき、本当は最初から必要だった問いを、AIに頼む前にも置くだけでいい。

全部を同じ厚みで埋めると、また説明書になる。危ない打ち合わせでは、最初に太くする欄が違う。今回なら、会社紹介や企画の狙いを長く語るより、部門長が過去に何で傷ついたか、こちらがどの一語を出すと信頼を失うかを先に書く。「整える」では広すぎる。A事業部長からPoCの許可を得る。顧客が社内説明に使える状態にする。現場の残業を膨らませず初月から試せる、と読めるところまで落とす。そこまで決まって、頼みごとはようやく足場を持つ。

次に見るのは、材料の重みだ。古い議事録、現場担当者の走り書き、役員の一言、過去案を同じ列に置くと、受け手はたいてい声の大きいものに引っ張られる。日付が新しい、役職が高い、名前がそれらしい。その程度の理由で主役が決まると、あとで会議室の空気だけが冷える。どれを読ませ、どれを退け、どれをこの場では見せないか。ここで線を引かないと、肝心の取捨選択だけが向こう側へ渡ってしまう。

形式は最後でいい。構成、文字数、トーンを指定するのは必要だが、器から決めると、形だけ整った空箱が返ってくる。いちばん太く引くのは禁則だ。作業増を小さく見せない。自動化だけで押し切らない。現場の入力を勝手に消えたことにしない。入力欄の先に悪意はない。禁止されていないなら、よかれと思って越える。だから、人間が先に線を引く。

5. プロンプトは、使い捨てのメモではなく、仕事の判断基準になる

こうした申し送りを残しておくと、次回の自分が助かるだけでは終わらない。前回どこまで言えたか、どの表現を避けたか、どの根拠を採ったかまで後からたどれる。頭の中で処理していた小さな分岐が、あとから読める形で残る。私なら、打ち合わせのObsidianノートに、目的、参照先、禁則、次に見る人への注意を残す。A事業部長向けのPoC説明なら、日報データ、情報システム部、初月の問い合わせ窓口、現場が嫌がる一言まで同じページに寄せる。そうしておくと、翌月の自分が前回の分岐点をたどるとき、うまく言語化できなかった違和感まで拾いやすい。

ただ、残すことと、全部を放り込むことは違う。議事録、チャットログ、過去案、顧客の断片記録、Slackの断片。フォルダごと差し出せば親切に見える。けれど、受け取る側からすると、それは親切というより捜索願に近い。どれが生きている情報で、どれが古いのか、どの一文は顧客の本音で、どれはその場しのぎの相槌なのか。そこを選ばないまま束だけ厚くすると、モデルは声の大きい断片に寄っていく。

哲学者マイケル・ポランニーは、人は説明できる以上のことを知っているという趣旨の議論を残した。この話はAI論というより、仕事そのものの話として身につまされる。私たちは判断しているのに、その理由を毎回は説明していないから、次の人が同じ段差でつまずく。GitLabのHandbook-first文化も、遠い話ではない。GitLabは、業務プロセスやルールを個人の記憶やチャットに閉じ込めず、チームが参照できる場所へ残すことを重視している。制度をそのまま真似る必要はない。大事なのは、その場で消えていた分岐点を、次の人が読める棚に収める姿勢だ。

量ではなく、編集で残す。今回だけの事情を短く残し、参照先を絞り、触れてはいけない地雷を太く引き、あえて見せない断片を決める。ここで手を抜くと、向こう側は器用に補う。補った結果、こちらの現場から少しずつ離れ、信頼だけがすり減る。違和感のある出力が返ってきたとき、性能だけを疑う前に、手元の引き継ぎ書を見直したほうがいい。ズレは、こちらの暗黙知が外に出ていなかった穴を指している。

6. 明日、まず一行だけ書く

明日から、完璧な引き継ぎ書を作る必要はない。最初の一行だけでいい。「この仕事で、絶対に踏んではいけない地雷は何か」。それを書くだけで、指示の表情が改まり、後任への手渡しにも重さが戻る。自分が何を怖がり、何を大事にして、何を「良い仕事」と呼んでいるのかが見え始める。あの日の鈴木さんに、私が本当に渡すべきだったものは、共有フォルダのパスではなかった。顧客の痛み、過去の失敗、触れてはいけない火種、そして何をもって良い提案と呼ぶかだった。

生成モデルに預けるときも同じだ。投げる前に、一行だけ先に添える。「この仕事は、現場へ余計な作業を背負わせずにPoC判断へ進むためのもの。『追加負担なく』とは断定しない。迷ったら、A事業部長向けPoCノートの禁則欄へ戻る」。ここまで書くと、頼みごとは単なる命令ではなくなる。仕事の奥にあった判断が、画面の外へ出てくる。

次にAIへ何かを頼むときは、うまい言い回しを探す前に、確認する場所を一つ決める。何を守るための仕事なのか。どの言葉で信頼を失うのか。誰が見ても同じ前提に戻れる場所はどこか。プロンプトは、そこで初めて命令ではなく引き継ぎ書になる。

参考文献・資料

#創作大賞2026 #ビジネス部門 #AI活用 #プロンプト #ナレッジマネジメント

いいなと思ったら応援しよう！