AIに仕事の仕組みを作らせる

AIに仕事を任せたいのに、頼むたびに結果がぶれる。プロンプトに「必ず」「毎回こうして」と書き足しても、話が長くなれば抜ける。一度うまくいった手順を次も同じように頼んだのに、返ってくるものが違う。任せた作業が途中で壊れて、どこから直せばいいのかもわからない。ここでつまずく人は多く、たいていは「先に完璧な仕様書を書けば動くはずだ」と考えて、その仕様書づくりで力尽きます。

止まっているのは、AIの賢さとは別のところです。仕事の仕組みそのもの、つまり同じ指示から同じ結果が返る型を、まだ作れていない。対話でアイデアを膨らませる使い方も、できあがった実務をそのまま任せる使い方も、だいぶ知られてきました。その間にある「仕組みを自分で作って育てる」段階だけが、あまり語られていない。

このページは、その段階のやり方です。仕様書を先に固める発想を捨て、記録を貯めるところから始め、対話と試行錯誤で少しずつ育てる。この順序で通して読めるようにしました。

プロンプトを強くするのをやめる

同じ失敗が続くと、指示の言葉を強めたくなります。「必ず」「絶対に」を書き足す。けれどこれは、守れなかった責任を実行するAIの側へ押しつける書き方です。話が長くなればまた抜ける。強い言葉で再現性は上がらない。

やることは逆でした。

守らせたい行動を、プロンプトの外の仕組みに埋め込む。実行の流れそのものに行動を組み込んでおけば、語気を強めなくても、その行動は毎回守られる。プロンプトの役目は、行動を引き出す命令から、自動化された行動の輪郭を描く設計図へ移ります。

一度うまくいった作業を、そのまま繰り返せると思わないことも大事です。AIに一回だけ何かをさせるのは誰にでもできる。難しいのは、同じ指示から同じ結果が出る状態を作ることのほう。ここに届かないと品質がぶれて、作った意味がなくなります。単発の成果には偶然が混じるので、繰り返しても信頼できる資産にはならない。毎回プロンプトを書き直す運用は、いつまでも安定しません。

その到達点がスキル化です。意図と手順を自分の外に出し、呼び出せば同じ動きが返る形にする。ここまで持っていって初めて、AIは業務に組み込めます。

ルールの置き場所しだいで、AIがそれを自分で直せるかどうかが変わります。Webの設定画面ではなく、手元のテキストファイルにルールを置く。するとAIがそれを自分で読んで、食い違いを見つけ、もっと通じる書き方に直す提案まで返してくる。一方的に命令を送るのをやめて、決まりを一緒に直していく形になります。

計画からは作れない。記録を先に貯める

仕組みを作ろうとして、多くの人がまず計画書や仕様書に向かいます。ところがAIに業務を任せる最初の1〜2週間は、指示を出すこと自体が難しい。何をどう頼めばいいかが見えていないので、計画から作ろうとすると必ず行き詰まる。

記録のほうが先です。

1週間ほど、ふだんの仕事をこなしながら結果を残しておく。そこからルーチンにできそうな部分を拾って、AIに任せる。AIをこちらのやり方に合わせる材料は、自分の記録からしか出てきません。事実がたまる前に設計を決めれば、AIは一般論の平均値へ引っ張られ、当たり障りのないものを返してくる。

仕様書を書いて渡せば自動化が仕上がる、という期待も外れます。「次はこの手順でやって」と文書を渡しても、AIはその通りには動かない。処理の段取りを自分で組んでくれないし、リンクを避けたがるといった癖は、実際に動かしている中でしか見えてこない。対話しながら試し、癖を見つけ、スキルの形にする。この行き来を経て、ようやく自動が近づく。仕様書を書くだけの段階と、動くスキルの段階のあいだには、作る勘を鍛える時間が挟まっています。

だから、仕様を固めてから作る順番をひっくり返す。AIは結果を一瞬で返すので、まず作って、出てきたものを見て仕様を直すほうが速い。最初の出力がつまらなくても、方向を変えてやり直す手間はとても小さい。完璧な仕様を待つより、不完全な出力から学ぶほうが早く進みます。

書いた言葉の量が、任せられる範囲を決める

任せることと書くことの順番は、多くの人の想像と入れ替わっています。任せてから書くのではなく、書いた分だけ任せられる。判断の基準も、前提も、その場の状況も、先に文章にして渡さなければ、AIはこちらの代わりに動けません。

境目はモデルの性能ではありません。

仕事が曖昧なままでは、AIに頼める指示になりません。仕事を細かい言葉に分けて、手順と判断に切り分ける。手順はAIに任せる部分、判断は人が受け持つ部分だと、切り分けた分だけはっきりする。言葉にした密度が、そのまま任せられる範囲になる。言葉にできていないところは、どれだけ賢いモデルでも任せられないまま。任せられるかどうかは、書いた言葉の量で決まります。

書く負担そのものも、AIに任せられます。複雑な作業で人が疲れるのは、手を動かしながら次の手順を頭の片隅で覚え続けるから。そこをAIに実装計画として書き出させ、Markdownのファイルにして手元に置く。次の手順を覚えておく負担が消えて、方針が正しいかどうかの判断だけに頭を使える。計画のファイルが残っていれば、作業を中断してもすぐ続きに戻れます。

育つまでの時間を、あらかじめ知っておく

AIで仕事を自動化しようとすると、最初の数ヶ月は整備に使う時間のほうが、得られる成果を大きく上回る。試行錯誤してルーチンを組み、動かしながら壊れ、また直す。この往復が9〜10ヶ月ほど続いて、やっと投下した時間と減った時間がトントンになる。そこを越えてから、効果が伸び始めます。

多くの人はこの手前で離れていきます。

「AIに任せても楽にならない」と判断して、整備の途中でやめてしまう。最初はマイナス、やがてトントン、そこから先でようやくプラス。この上がり下がりを知っていれば、手前で投げ出さずに済みます。

同じ試行錯誤でも、土台があるかどうかで消える時間が変わる。土台とは、設計の型、仕様書の書き方、うまく動いているスキルの実例のこと。1本目のスキルで得たものが、2本目を作るときの下敷きになる。この初期投資が、あとの調整の重さを決めます。AIがどれだけ賢くなっても、自分の仕事に合わせた微調整は本人にしかできない。それでも、よい土台があれば、その調整でつまずく回数が大きく減ります。

仕組みは作って終わり、とはいかない。手順書もテンプレートも、最初の版はまだ実際の抜け漏れを知らない。仕組みの値打ちは、完成度よりも、失敗を次の改良点へ変えられるところにあります。一回で完璧な予防線を引こうとするより、再発のたびに更新される形を持つほうが、長い目では強い。

全部を任せられたら、手順書は確認だけになる

AIがプロジェクトの全工程をこなせるようになると、手順書の中身が変わる。昔の手順書は「誰がやるか」で書かれていました。人の工程とAIの工程を分けるマーカーを付け、工程ごとに担当を書き分ける。全部がAIの担当になれば、この区別は消えて、残るのは「どこで人が確認を挟むか」だけ。何ステップもあった手順が、確認どころで区切られた2〜3本のリンクに収まります。

ここまで来れば、日々の実務をAIに任せて手を空ける段階に入れます。何を任せ、何を手元に残すか。失敗に気づいて戻す道をどう作るかは、AIに日常のオペレーションを任せるにまとめました。作って育てるこのページと、実務を任せるそのページはひと続きです。作って育てた先に、任せて報告を見る段階があります。