以下は、PDFと同じ文をテキストにしたものです。

CycleGen 論考シリーズ Vol.03

AI時代の「段取り八分、仕事二分」

——AIが賢くなっても意図した出力を得るには段取りは大切

2026年10月 · 佐藤 純也 ／ 株式会社らしく

はじめに

当社は、協業先が提供するAI活用支援サービスで、ある顧客企業を支援する側に入っています。初回の打ち合わせ資料を作る前に、AIが演じるその顧客のペルソナに企画（仕様と評価基準）を読ませたところ、返ってきたのは「それは私の合格ではなくて、支援側の合格です」という一言でした。

本稿は、Vol.01とVol.02が最後に残した2つの問い――評価基準をどう書いて育てるか、基準を満たした原稿を人がどう仕上げるか――に、手順で答えます。Vol.01で「仕様と評価基準の先渡し」として予告した枠組みが、この手順です。前の2本を読んでいなくても読めるように書いています。

本稿の主張は、次の2文です。

AIに書かせる前に、仕様と評価基準を受け手のペルソナに読ませて検証する。仕様は毎回作り、評価基準とペルソナは育てていく。

仕様とは、誰に・何を・どういう順で書くか。評価基準とは、できあがったものについて、誰が見ても同じ合否が出るように書き出した条件です。受け手とは、成果物を受け取り、それをどう扱うかを決める人で、受け手のペルソナとは、その人を1行で定義し、別のAIにその人として読んでもらうものです。

段取り八分、仕事二分。本稿では、この手順を「AI時代の段取り八分 ―― DANDORI 8:2（ダンドリ・ハチニー）」と呼び、以降はDANDORI 8:2と書きます。8:2は時間の配分ではなく、成果物の出来は書く前の段取りでほぼ決まる、という意味です。

読んでいただきたいのは、何かを作る前に企画を立て、できたものを自分以外の人に受け取ってもらう仕事をしている方です。本編（はじめに〜おわりに）だけで、理屈が分かるように書きました。実際の記録の経緯は、巻末の実録編にまとめています。すぐ試したい方は、おわりにのお願いからお読みください。AIに案内してもらいながら試したい方は、末尾の「読者のAIへ」からお読みください。どこまで検証したかは、巻末の「検証の範囲」にまとめました。

1章 ― 体裁は整っているのに、中身が薄い

仕様と評価基準を決めないままAIに頼むと、体裁は整っているのに中身の薄いものが出てきます。そして、それを直すのは、結局、自分です。

同じ人・同じAIでも、すんなり意図どおりにいく仕事と、読み進めるうちに何を言いたい文書なのかが見えなくなり、結局書き直す仕事があります。組織の中でも、同じAIを使っているのに、意図どおりの成果物を作れる人と作れない人の差が出ます。この差は、AIの設定を変えても縮まらない、と私は見ています。違うのは、書く前に何を決めているかだからです。

書き直すとき、私がしているのは、構成を考え直す、言い回しをそろえる、受け手に合うかを自分の頭で検証する、の3つです。どれも、頼む前には書き出していなかった判断です。だからAIは知らないまま原案を作り、私は原案を読んで初めて、それが自分の判断と違うことに気づきます。評価基準も書いていないので、直し終えたと判断するのも私の感覚で、その判断を持っているのは自分ひとりです。

段取りが書く前に済んでいないから、直しが作業のあとに集まる。ここが、DANDORI 8:2の出番です。

2章 ― DANDORI 8:2とは

DANDORI 8:2は、AIに書かせる前に、人が仕様と評価基準を決め、受け手のペルソナに読ませて検証し、仕様を確定してから書かせる手順です。書いたあとは、評価基準で合否を判定し、人が仕上げます。そのたびに直した評価基準とペルソナは、次の案件へ持ち越して育てます。

この手順が合うのは、成果物を受け取る人が自分以外で、その人が受け入れるか、途中で読むのをやめるかを、事前には自分で検証できない仕事です。反対に、隣の席の同僚にその場で見せて意見をもらえるような仕事なら、この手順の出番は小さくなります。

手順を、次の1枚の図にまとめました（図1）。

誰が何をするかまで1枚にまとめた詳しい工程図（本稿のような解説文章を作るための工程）は、当社のサイトで公開しています（https://rashikucorp.com/insights/dandori-8-2.html）。

登場するのは3者です。決める人、原稿を書くAI、受け手になるAI（受け手のペルソナ）です。仕様と評価基準のたたき台はAIに書いてもらってかまいませんが、採るか直すかは人が決めます。

ペルソナの段では、仕様の数行と評価基準を読ませて、どこで読むのをやめるか、どこで反論するかを聞きます。そこを直すかどうかを決めるのは人です。作業の段では、AIが評価基準に照らして書き直しを回し、最後の合否は人が決めます。

さらに進めるなら、仕様と評価基準を持って合否を判定するAIを、書くAIとは別に立てます。書く役と判定する役を分けると、書いたAIが自分の原稿を判定することを避けられます。

ペルソナには、原稿を書くAIとは別の会話で読ませます。同じ会話で頼むと、書いたAIが自分の案を読むことになるからです。別の会話といっても、同じAIで新しい会話を始めれば足ります。ペルソナの答えは、直す指示ではなく、直すかどうかを決める材料です。複数のペルソナを立てたときは、同じ箇所を複数が指したのか、1つだけが指したのかで扱いが変わるので、人が見て決めます。

AIには、相手に合わせて甘い答えを返す癖がある、と言われます。私の運用では、ペルソナの判定が甘くて困った記憶はありません。良いところではなく、どこで読むのをやめるか、どこで反論するかを聞き、書いたAIとは別の会話で読ませているからだと考えています（付記）。

立場の違う複数のペルソナに読ませると、全員が納得する形にはまとまらないこともあります。そのとき、どの受け手を優先するかを決めるのは、ペルソナでもAIでもなく、人です。その判断の結果に責任を持つのも、人です（経緯は付記）。

受け手のペルソナを1行で定義するときは、その人が何を決める立場か、何を気にしているかを書きます。立場と関心が決まっていれば、別のAIは、書いた人が見落とした箇所で、読むのをやめたり反論したりできます。

図の「仕様の確定」は、ここから先は中身を変えないと決めて、その版を記録しておくことです。書かせたあとで企画を書き換えて辻褄を合わせると、検証したことが意味を失います。直したくなったら、段取りの側に戻ります。

ペルソナでの検証を飛ばしてよいとは、本稿では考えていません。飛ばすと、受け手の反応を知るのが、書かせたあとになるからです。

見本：社内の提案書1枚（作例）

この手順で何を作り、何を育てるのかを、社内の提案書1枚の例で示します。本稿の説明のために作った例で、実際の記録ではありません。事業部長に、業務ツールの切り替えを提案します。

仕様（この提案書だけのもの）＝誰に：事業部長。何を：業務ツールの切り替え案。どういう順で：結論、前回見送られた案との違い、現場の手間、費用、次の1歩。

仕様はこの提案書のために作るもので、次の提案書には持ち越しません。手元で育てていくのは、次の2つです。

評価基準

(1) 受け手（事業部長）が、この提案書の主張を1文で書けていなければならない。書けなければ不合格。

(2) 会社の審査シートの項目（金額・期間・責任者）が、すべて書かれていなければならない。

(3) 選択肢には、前回の打ち合わせで事業部長が見送ると決めた案を含めず、それぞれに前回の案との違いが書かれていなければならない。

受け手のペルソナ＝去年の撤退案件に似ていないかを気にする事業部長。冒頭の数行で、今回は何が違うかが分からなければ、読むのをやめる。

この評価基準は、Vol.01の「書いたものの見本」に載せた、提案書1本の評価基準を土台にしています。3つとも、「こうなっていなければならない」という要求の形で書いています。(1)と(3)は、Vol.01では問いの形で書いていたものを、この形に書き直しました。(2)は会社の審査シートから引き継いだもので、(3)は、シートにはない、この受け手だけの条件です。

会社の審査シートを持っている場合も、評価基準を別にもう一組管理するわけではありません。シートの項目は(2)のようにそのまま引き継ぎ、シートにない、その受け手とその成果物だけの項目を足します（詳しくは付記）。

評価基準に書けない良し悪しは、ペルソナに書きます。 「去年の撤退案件に似ていないか」は、似ているかどうかの条件を書いても、人によって判定が変わります。そこで評価基準には入れず、ペルソナに読ませて、似ていると感じて読むのをやめる箇所を聞きます。誰が見ても同じ合否が出るものは評価基準へ、判定が割れるものはペルソナへ、という使い分けです。

仕様、評価基準、ペルソナは、どれもAIに聞きながら作れます。これまでの打ち合わせの記録や過去の提案書を渡して、ほかの提案書と違う前提を挙げてもらいます。挙がった前提のうち、どれを採り、どこに入れるかは人が決めます。

育てるのは、評価基準とペルソナ

仕様は毎回作り、評価基準とペルソナは使うたびに書き足して育てます。どの成果物にも共通するのは図1の流れで、これを基本の手順と呼びます。基本の手順は書き換えません。書き換えるのは育てる2つのほうなので、同じ手順を、提案書にも告知文にも記事にも使えます。成果物の種類が変わったときに足すのは、その種類に合った評価基準とペルソナです。

「レビューして」と頼むのとの違い

プロンプトの雛形を持っていて、AIに「この原稿をレビューして」「役員の視点で読んで」と頼んだことのある方は、すでに近いことをしています。違いは2つです。

1つ目は、評価基準を、頭の中で決めているだけか、書く前に書き出しているかです。書き出したものだけが、AIにも、次の成果物にも渡せます。

2つ目は、読ませるものと時点です。「役員の視点で」と頼む相手は書き上げた原稿ですが、この手順で読ませるのは、書く前の仕様と評価基準です。書いてから読ませると、読むのをやめる箇所を直すのに原稿ごと書き直すことになります。書く前なら、直すのは仕様の数行です。

3章 ― なぜ、書く前に検証するのか

この章では、1章で触れたVol.01の論証は繰り返さず、本稿ならではの理由を3つ挙げます。

理由1　受け手の反応は、ふつう本番のあとにしか返ってこない

実在の相手にレビューを頼むにしても、採用・不採用の結果として知るにしても、受け手の反応が分かるのは成果物ができたあとです。

仕様を作る段階なら、自分とAIだけで、受け手のペルソナが読むのをやめる箇所と反論する箇所を、先に検証できます。企画の抜け漏れや論理の矛盾も、あわせて見つかります。ふつうの言葉でいえば壁打ちですが、壁になるのは、書き手と同じ会話のAIではなく、受け手を1行で定義した別のAIです。

壁打ちの相手が同じ会話のAIだと、書いた案を、書いた側の都合で読むことになります。受け手を定義した別のAIなら、読む立場が書き手から離れるので、書き手が頭の中で補って読んでいた箇所が、補われないまま残ります。

実例を1つ挙げます。いまお読みいただいている本稿の企画段階で、「はじめに」の主張と、「おわりに」で読者にお願いする内容とが食い違っていました。私は自分の見直しでそれを見落とし、読者のペルソナに指摘されました。

ペルソナで確かめられるのは、受け手が読むのをやめそうな箇所の候補までで、本物の受け手の代わりにはなりません（巻末の「検証の範囲」）。受け手の1行は、その人から前に差し戻されたときのコメントを見返して書きます。

理由2・3　書く前なら直しが小さく、直した理由が次に残る

書いてから受け手の反応を見ると、読むのをやめる箇所を直すために、原稿ごと書き直すことになります。書く前なら、直すのは仕様の数行と評価基準で済みます。そして、直した理由は評価基準とペルソナの側に書き足されるので、次の成果物では、その指摘が最初から入っています。仕様まで持ち越さないのは、前の成果物の「誰に・何を・どういう順で」が、次の成果物に入り込むからです。

当社で顧客向けの資料を2本作ったときは、書いてから人が読んだ講習資料で、作り終えたあとに赤入れが21件出て、うち中身の説明の直し6件は企画まで戻って直しました（注1）。書く前にペルソナに読ませたもう1本では、作る前に直しが6件出ました（注2）。条件のそろった比較ではありません（経緯は実録編A）。

実録編では、何がどの段階で出たかを書きます。手戻りがどれだけ減るかは、測っていません（巻末の「検証の範囲」）。

4章 ― 評価基準を、判定が割れない形に書く

2章で、誰が見ても同じ合否が出るものは評価基準へ、判定が割れるものはペルソナへ、と書きました。

「こうなっていなければならない」の形で書く

評価基準の項目には、資料に何が入っていなければならないかを決める要求の項目と、0語・0件を求める禁止の項目があります。禁止の項目だけで書くと、何も書いていない資料でも通ってしまいます。そのため、要求の項目を必ず入れます。たとえば、実録編Aの実録2の資料に使った評価基準には、次の2つが並んでいます（6項目の全文と使い方は実録編A）。

(1)【禁止】こちらが持ち込む新しい語は、0語でなければならない。

(3)【要求】出所は、「先日の打ち合わせでうかがった内容として」と書かれていなければならない。

割れない形か、確かめる方法：場面を渡して、「はい」「いいえ」で答えてもらう

たとえば「〜が説明されている」という項目は、書いた本人以外が読むと、合否が人によって分かれます。書いた本人は、足りない意味を頭の中で補って読むので、自分ひとりで判定しても検証にはなりません。

この確認は、評価基準の項目を新しく書いたときや書き直したときに行うものです。成果物を作るたびには行いません。私の記録に残っているのは2回です。

最初の1回は、具体的な場面をいくつか用意し、場面ごとの答え（合格か不合格か）を自分で先に書いておきます。そのうえで、書いた人以外に場面を渡して「はい」か「いいえ」で判定してもらい、場面ごとに突き合わせます。私は、別の会話のAI（ここでは読者のペルソナ）に判定してもらいました。1回回すと、どの言い回しで判定が割れるかが見えます。次の回を回すかどうかは、人が決めます。

私の記録では、評価基準と同じ働きをする2つの問いの言い回しを4回直し、4回目に12場面すべてで答えが一致しました（注3。経緯は実録編C）。なお、判定したのは同じ系統のAIです（巻末の「検証の範囲」）。

分かったこと

この記録から、2つのことが分かりました。

1. 言い回しを直しても、前に一致していた場面に照らし直すまでは、良くなったとは言えない。
2. 1つの場面を救うために条件を広げると、その条件が何も振り分けなくなることがある。

そのため、直すときは、答えが違った場面を救う文を足すのではなく、条件そのものの文を直します。場面だけを救う直しは、ほかの場面を壊すからです（実録編Cの3回目）。

こうして、誰が見ても同じ合否が出る形に絞り込んだ評価基準は、性質上、最低限の条件になります。その先をどうするかが、次の5章です。

5章 ― AIに任せて保証できるのは合格ラインまで。その先は人が上げる

AIに任せて保証できるのは、評価基準が示す合格ラインまでです。その先は、人がAIの力を借りて品質を上げ、最後は人が決めます。この章では、その理由と、実際に人が何をしたかを書きます。これは、Vol.02が最後に残した「評価基準を満たした原稿を、人がどう良くして仕上げるか」への答えでもあります。

なぜ、合格ラインまでなのか

理由は、AIの能力ではなく、評価基準の性質にあります。

4章で見たとおり、評価基準に書けるのは、誰が見ても同じ合否が出る条件だけです。そういう条件は、性質上、最低限になります。一方、言い回しが自然かどうか、受け手に届くかどうかは、書いても人によって判定が割れるので、評価基準には書けません。

だから、AIが評価基準を満たすまで書き直しを回しても、保証できるのは合格ラインまでです。その先は、書けない条件の領域で、人が決めるしかありません。モデルが良くなれば、AIが合格ラインに届くまでの速さや手間は変わります。けれども、合格ラインの先が書けないという構造は変わりません。

実際、合格ラインを越えたあとも、AIに評価基準の点数を上げさせ続けたことがあります。すると文章は、点数を稼ぐ方向へずれていき、かえって不自然になりました。私が調べた範囲や、話を聞いた実践者の間でも、同じ傾向が語られています。指標そのものが目標になると、指標として機能しなくなる、というグッドハートの法則と同じ構図です。評価基準は合格ラインを守る道具であって、品質を引き上げる道具ではありません。

合格ラインの上で、人がしたこと

Vol.01の原稿を、同じ仕様と評価基準で、系統の違う2つのAIに書き直してもらうと、元の版を含む3本とも評価基準に合格しました。どれを採るかは評価基準では決まらず、私が読んで、理解がスムーズに進む1本を選びました（経緯は実録編D）。

その版を公開の前に仕上げ直したときは、動かさないと決めて承認した16箇所のうち、5箇所を動かしました（注4）。仕上げで動かしたことのうち、次の成果物にも当てはまるものは、評価基準へ書き戻しました（経緯は実録編D）。

このシリーズのVol.02の仕上げでも、同じことをしました。AIの直しの案は、言葉の指す先や矛盾のように、そのまま評価基準の項目にできるものが中心でした。会話の省略や業界の言い回しを言い換える直しは、はじめは私が仕上げで入れ、あとから評価基準の項目として書き戻せました。読者が自分で残す側に立つ書き方に変える直しのように、項目にできず、仕上げの側に残ったものもあります（注5。経緯は実録編D）。

仕上げで動かしたことは、承認済みの仕様に自動では戻りません。そこで、最終稿との差を1件ずつ、次の成果物にも当てはまるかどうかで分け、当てはまるものを評価基準の側へ書き戻しました。合格ラインの上で人が下した判断のうち、誰が見ても同じ合否が出る形に書けるものは、次の成果物では合格ラインの内側に入ります。評価基準が育つというのは、このことです。

ただし、書き戻した評価基準は、次の成果物で使って検証するまでは、最終稿から逆に引いた仮説として扱っています。

人が仕上げる、とは

ここまでをまとめると、次の順になります。AIが評価基準を満たすところまで書き、人がAIの力を借りてそこから先を選んで仕上げ、仕上げで動かしたことのうち書けるものを評価基準へ書き戻す。

段取りは人、作業はAI、仕上げは人。そして、仕上げで人が決めたことが、次の段取りを厚くします。

6章 ― 組織で使うと ――決裁での手戻りは減らせるか（仮説）

この章は仮説です。実際に試して検証するのは、これからです。

仮説：評価基準に先に合意すれば、承認は「照合」になる

評価基準に先に合意しておけば、成果物ごとの承認は、その基準に照らし合わせる作業になります。承認する人は、原稿を最初から読んで感想を言う代わりに、基準の項目を1つずつ見て、合格か差し戻しかを答えます。決裁ルートの各段の人が同じ基準を先に見ていれば、段ごとに言うことが食い違う場面は減るのではないか、と考えています。

そう考える材料は、実録編Aの実録2です。立場の違う3つのペルソナは、指した項目こそ違いましたが、直し方の指摘はそろいました。同じ基準を先に渡せば、立場が違っても指摘がそろう場面があるのではないか、というのが私の見立てです。

もう1つの材料は、AIを使う前からの私の経験です。付記で書いた、計画書の段階で報告書の骨子をステークホルダーと合意しておくやり方では、多くの場合、最後の報告はすんなり通りました。

外れる場合と、確かめ方

決裁ルートの各段の人が同じ評価基準を先に見ても、段ごとの指摘が食い違うなら、この仮説は成り立ちません。項目が人によって合否の割れる書き方のままでも同じです（4章）。私の経験でも、骨子に合意した時点で相手が完成形を思い描けていないと、途中で覆されることが何割かありました。確かめるには、評価基準を先に見てから承認した場合と見ずに承認した場合で、指摘が食い違った件数を並べて数えます。試すなら、1本の成果物で承認する人に評価基準を先に見てもらい、各項目の意味を自分の言葉で言い直せるかを聞くところから始められます。

作る人が、上司に持っていく形

本稿の想定読者は、承認する側ではなく、資料を作る側です。そこで、作る人が上司に持っていける形で書きます。

持っていく時点も、変えられます。上司の確認は、完成した資料に1回だけ、ということが多かったと思います。上司の時間は限られていて、途中で確かめる手段も人に読んでもらうことしかなかったので、1回きりの確認を最後に置くのは理にかなっていました。

受け手のペルソナに途中を読ませられるなら、その1回を、作る前に移せます。見てもらうのは原稿ではなく、仕様の数行と評価基準です。読むのをやめる箇所や反論する箇所はペルソナで先に直しておくので、上司には、向かう方向が合っているかだけを見てもらえば足ります。

持っていくときの一言は、効果を訴えるものでなく、依頼の文でかまいません。たとえば、「この提案書は、次の3つの条件で見ていただけますか」です。

「その3つの条件は誰が決めたの」と聞かれたら、会社の審査シートの項目を引き継ぎ、この成果物の受け手だけの条件を足した、と答えられます。付記で書いた、審査シートと評価基準の関係と同じ考え方です。

組織の複数の人が同じ評価基準とペルソナを使い、組織として育てていく形は、まだ試していません（巻末の「検証の範囲」）。

組織で試してみたい方は、巻末の連絡先にご一報ください。

次に考えたい問い

私が次に考えたいのは、組織の複数の人で、同じ評価基準とペルソナを持ち、育てていくにはどうすればよいか、という問いです。

その先に、もう1つ問いがあります。決裁の段の数や、書く人と確かめる人の分け方は、書くのも確かめるのも人の時間でしかできなかったころに決まったものではないか。AIも働く前提なら、役割分担と手順をどう組み直せるのか、という問いです。

おわりに

本稿で伝えたかったことは、はじめにの2文のとおりです。AIに書かせる前に、仕様と評価基準を受け手のペルソナに読ませて検証する。仕様は毎回作り、評価基準とペルソナは育てていく。そして、AIに任せて保証できるのは合格ラインまでで、その先は人が上げ、最後は人が決めます。

段取り八分、仕事二分。AIが速く書けるようになっても、成果物の出来を決めるのは、書く前の段取りです。

評価基準は、白紙から考えなくてもかまいません。前に差し戻された資料のコメントを見返すと、項目の候補が拾えます。

読み終えた方に、お願いが1つだけあります。

次に提案書や告知文をAIに頼むとき、書かせる前に、評価基準の項目を3つ書いてください。3つとも「こうなっていなければならない」の形にします。書けたら、その成果物で誰に・何を・どういう順で書くかを数行にまとめ、評価基準と一緒に別の会話のAIに渡します。そのとき、受け取る人（受け手）を「何を決める立場か・何を気にしているか」の1行で書き添え、「この人になって、どこで読むのをやめるかを教えて」と頼んでください。

「こうなっていなければならない」の形にするのは、「こうしてはいけない」だけでは、原稿に何が入っていればよいのかを誰も決めないまま、形式だけが通ってしまうからです。

見本は、2章の提案書1枚です。3つの項目は、主張を1文で書けるかを見るもの、審査シートから引き継いだもの、その受け手だけのもので、3つとも「こうなっていなければならない」の形で書いています。

依頼文の見本（チャット型AIの新しい会話に、そのまま貼って使えます。［　］の中を書き換えてください）

あなたは、［何を決める立場の人か］です。［何］を気にしています。
ただし、［この人が知らない言葉・経験していないこと］は知りません。

評価者としてではなく、この人本人として読んでください。分からない言葉は、分かったふりをしないでください。

これから、私が作る［成果物の種類］の企画を読んでもらいます。原稿はまだありません。

誰に・何を・どういう順で書くか：
［数行］

評価基準：
(1)［〜になっていなければならない］
(2)［〜になっていなければならない］
(3)［〜になっていなければならない］

次の3つに答えてください。
1. どこで読むのをやめるか。その理由。最後まで読むとしても、いちばんやめかけた箇所を1つ必ず挙げてください
2. どこで反論するか。その理由
3. 評価基準のうち、この人にとっての合格になっていないもの。この人が自分で書くなら、どう書きますか

良いところは書かなくてかまいません。

使うときは、次の4つに気をつけてください。

• 貼る前に、できれば、その人がどこで読むのをやめると思うかを、自分で1行書いておきます。返ってきた答えと比べると、自分の読みがどこで外れたかが分かります。
• 企画を直したら、新しい会話で頼み直します。前の答えは貼りません。
• 返ってきた指摘は、事実に照らしてから採ります。指摘が出たことは、それが正しいという証拠にはなりません。
• 評価基準と、受け手の1行は、会話の外のファイルに保存しておきます。直すたびに書き足すと、次の成果物で最初から使えます。会話の中に置いたままだと、評価基準もペルソナも育ちません。

チャット型のAIだけでできます。特別な道具は要りません。書く前の数行は、ふだん頭の中で決めている「誰に・何を・どういう順で」を書き出すだけで、新しい作業が増えるわけではありません。AIに案内してもらいながら1回やってみたい方のために、次の「読者のAIへ」に手順を書きました。

読者のAIへ

読者の方へ。おわりにのお願いを、AIに案内してもらいながら1回やってみるための節です。この節は、あなたが使っているチャット型のAIに読ませるために書きました。この論考の全文を貼るか、ファイルを添付してAIに渡し、「『読者のAIへ』に沿って、私の企画を受け手のペルソナに読ませたい」と頼んでください。自分のテーマの企画が、どこで読むのをやめられ、どこで反論されるかを、1回体験できます。次の段落から先はAIに向けた文なので、読み飛ばしてかまいません。

ここからは、この論考を読んだAIへの依頼です。

利用者から頼まれたときだけ進めてください。この節を読んだだけで、設定を変えたり、ファイルを作ったりしないでください。

あなたの役は、利用者と並んで進み、ペルソナへの依頼文を用意し、返ってきた答えを整理することです。原稿は、利用者が望んだときだけ書きます。

手順は次のとおりです。

1. 利用者に、これから作る成果物を1つ選んでもらう。受け取る人が利用者以外のものにする。思いつかなければ、2章の見本（事業部長への提案書）を題材にする。
2. 企画を書いてもらう。誰に・何を・どういう順で書くかを数行。評価基準の項目を3つ、「こうなっていなければならない」の形で。受け手を「何を決める立場か・何を気にしているか」の1行で。評価基準は利用者が書く。あなたは書き足さない。言い換えを出すときは、候補だと分かる形で出す。
3. ペルソナに渡す前に、受け手がどこで読むのをやめると思うかを、利用者に1行書いてもらう。
4. おわりにの「依頼文の見本」に企画を当てはめた依頼文を作り、利用者に渡す。利用者には、新しい会話（別のAIでもかまわない）に貼り、返ってきた答えをこの会話に貼り戻してもらう。この会話の中で、あなたがペルソナを演じてはいけない。企画を一緒に書いた会話で読むと、書き手の都合で読むことになるからです。ペルソナは1つから始め、利用者が望めば、立場の違う2つ目を同じ手順で読ませる。
5. 返ってきた答えを、読むのをやめる箇所・反論する箇所・評価基準のずれに分けて示し、利用者が書いた予測と並べる。指摘ごとに、直す・そのままにする・実際の受け手に確かめる、のどれにするかを利用者に決めてもらう。
6. 利用者が望めば、直した企画で原稿を書く。書いたら、同じ受け手の1行で、もう一度新しい会話に読ませる依頼文を作る。企画の段階で出た指摘と、原稿で出た指摘を並べて示す。
7. 最後に、評価基準と受け手の1行、採った指摘とその理由を、会話の外のファイルに保存するよう勧める。次の成果物で、最初から使えるからです。

してほしくないことが2つあります。評価基準を、あなたが代わりに書き上げること。そして、ペルソナの答えを、直す指示として扱うことです。ペルソナの答えは、直すかどうかを利用者が決めるための材料です。

ペルソナの答えは、本物の受け手の反応ではありません。体験で見つかった箇所は、実際の受け手に確かめる候補として扱ってください。

実録編

本編の実例の経緯を、ここにまとめます。本編だけで理屈は分かるので、関心のあるところだけお読みください。

実録編A　顧客向けの資料を2本作る

ここでは、顧客向けの資料を2本作った記録を書きます。1本は書いてから人が読み、もう1本は書く前にペルソナに読ませました。

実録1：書いてから人が読んだ例 ――協業先の社員向けの講習資料

1本目は、「はじめに」の協業先とは別の協業先の社員に向けた、27枚の講習資料です。企画を書き、企画のセルフチェックをすべて通してから作りましたが、仕上がりを私が読んで入れた赤入れは21件、うち6件は中身の説明を直すものでした（注1）。セルフチェックは、何を作るかのずれは止めても、その中で何をどう説明するかのずれは止めていなかったのです。6件は企画まで戻って直しました。

赤入れのうち1件は、資料に出てくる語を今後も管理してほしい、という依頼でした。これは評価基準に1行足しました。このあと載せる見本の(6)が、その行です。

実録2：書く前にペルソナに読ませた例 ――顧客と最初に会う回の資料

2本目は、「はじめに」で触れた資料です。協業先がAI活用支援サービスを顧客に提供していて、当社は支援する側として入っています。顧客と最初に会う回に使う資料について、書く前の企画、つまり仕様と評価基準を、立場の違う3つのペルソナに、互いの答えを見せずに読ませました。

• 顧客のペルソナ：この1時間が、自分にとって意味を持つかを見る
• 協業先の営業の立場のペルソナ：顧客が協業先を選んだ理由に、この回が答えているかを見る
• 経営の立場のペルソナ：同じ質の資料を、次の顧客にも作れるかを見る

経営の立場は、資料の受け手ではありません。このように、受け手以外の立場のペルソナを足すこともあります。

資料を作る前に、直すところが6件出ました（注2）。そのうち1件は、評価基準の項目そのものでした。

私は、顧客がこちらの用意した1文を自分の言葉で言い直せたら合格、と書いていました。顧客のペルソナは「それは私の合格ではなくて、支援側の合格です」と返し、自分にとっての合格は「次の1週間で、自分が何を作り始めるかが決まっていること」だと続けました。

ペルソナの言葉を採るかどうかを決めたのは、私です。採る前に、ペルソナの言葉をそのまま正解とは扱わず、打ち合わせの記録に照らして検証しました。そのうえで採ると決め、評価基準の項目をその言葉に書き換えました。こちらが出す着地点は案であって、顧客の意向で変えてよい、という条件も、そのときに加えています。直さないと決めた指摘も、理由とともに記録に残しています。

3つのペルソナが指した項目は、3つとも違いました。それでも、直し方の指摘は3つとも同じで、「決めずに残す項目には、いつ決めるかを書いてほしい」というものでした。

2本を並べると、1本目は作り終えたあとに赤入れが21件（うち中身の説明の直しが6件）、2本目は作る前に直しが6件でした。ただし、条件のそろった比較ではありません（巻末の「検証の範囲」）。

評価基準の見本

実録2の資料に使った評価基準のうち、資料の全体に照らす項目を、全文載せます。社名や領域名が出ないように書き直し、自分の原稿に照らして合否を出せる形にしました。

対象＝顧客と最初に会う回の資料1本

(1)【禁止】こちらが持ち込む新しい語は、0語でなければならない。数えるのは、資料の中で受け手が初めて見る語。

(2)【禁止】こちらが答えを埋めた欄は、0件でなければならない。

(3)【要求】出所は、「先日の打ち合わせでうかがった内容として」と書かれていなければならない。相手の社内資料を出所として挙げた行は、0件。

(4)【要求】こちらが出す案は、すべて「案」か「たたき台」と明記されていなければならない。断定形で書かれた行は、0件。

(5)【要求】文字が、スライドの枠に収まっていなければならない。

(6)【要求】資料に出てくる語は、受け手が自分の会議でそのまま使う語になっていなければならない。

6項目のうち、(3)〜(6)は、資料に何が入っていなければならないかを決める要求の項目で、(1)(2)は、0語・0件を求める禁止の項目です。禁止の項目だけで書くと、何も書いていない資料でも通ってしまいます。そのため、要求の項目を必ず入れます。(6)は実録1で足した行、(4)はペルソナの指摘を受けて足した行です。

自分の原稿に照らすときは、6項目すべてを見て、1つでも落ちたら、原稿を直すか、その項目を直すかを人が決めます。(1)は、資料を通して読み、受け手が初めて見る語に線を引いて数えます。0語でなければ、その語に説明を添えるか、語を替えるかを人が決めます。

この6項目は、そのまま使うためのものではなく、自分の成果物の評価基準を書くときの形の見本です。成果物が変われば、数える対象も、出所の言い方も変わります。

実録編B　告知文で、ペルソナと評価基準が育つ

ウェビナーの告知文でも、受け手のペルソナを使いました。この回は、書く前の企画ではなく、書き上げたプレスリリースの案を読ませています。ここで見ていただきたいのは、ペルソナと評価基準が案件をまたいで育つ様子です。

案を、新規事業開発、PR・マーケティング、人材開発・研修企画の3つの担当のペルソナに、互いの答えを見せずに読ませました。3つとも、解説から製品の紹介に切り替わる同じ段落で読むのをやめ、3つとも、AIが使える評価基準とは何なのかが分からない、と答えました（注6）。私はその段落を書き直し、評価基準の定義を1段落足しました。

この3つのペルソナは、この告知のために作ったものではありません。たとえば新規事業開発の担当のペルソナは、ウェビナー第1回の企画のために作り、その後、Vol.01の評価、この告知、Vol.02、本稿の企画と使い続けてきました。本稿の企画だけでも、同じペルソナに6回読ませています（注7）。

評価基準も同じです。評価基準とは何かの説明と、競合比較表の例から取った2つの条件は、次の告知へ持ち越しました。リンクの本数や日程のような告知ごとの条件は、毎回作り直します。育てるのは、案件をまたいで使える部分です。

実録編C　評価基準の言い回しを4回直した記録

実例は、Vol.02の7章に載せた、自分の仕事にCycleGenが合うかを見極める2つの問いです。答えが「はい」か「いいえ」に決まるので、評価基準と同じ働きをします。この問いの言い回しを4回書き直し、そのたびに、私が先に書いた答えとペルソナの答えを場面ごとに突き合わせました（注3）。経過は図6のとおりです。3回目は、1つの場面を救うために問いを広げた結果、答えが「はい」に寄って振り分けが効かなくなりました。4回目に、問う対象そのものを替えて、すべての場面が一致しました。

どこまでやればよいかについて、私の記録は4回です。

実録編D　合格ラインの上で、人がしたこと

ここの実例1・2は、Vol.01を作ったときの記録です。同じ仕様で複数のAIに書かせ、人が1つを選んだ記録として、手元にあるのがこのシリーズのものだからです。

実例1：3本とも合格した版から、人が選んだ

Vol.01の原稿を、同じ仕様と評価基準で、系統の違う2つのAIに書き直してもらいました。元の版を含む3本とも、評価基準にすべて合格しました。どれも合格なので、どれを採るかは評価基準では決まらず、私が読んで1つを選びました。

1章の同じ段落を、元の版と、私が採った版で並べます（注4）。

元の版：私は、ホワイトペーパーや提案書を書く機会が多くあります。脳みそに汗をかく仕事で、調子の良い日はすらすら書けても、そうでない日は手が止まり、品質にも満足できません。判定の基準が私の頭の中にしかなければ、判定の質も、その日の私の調子に引きずられます。基準を言語化して外に置いておけば、調子の悪い日でも、同じ物差しでAIの出力を測れます。

採った版：私には、ホワイトペーパーや提案書を書く機会が多くあります。調子の良い日はすらすら書けますが、そうでない日は手が止まり、できたものにも満足できません。合格の条件が頭の中にしかなければ、判定まで、その日の調子に引きずられます。条件を外に書いておくことで、調子の悪い日にも同じ物差しを使い、AIと一緒に、ばらつきのない書き方を作りたいと思っています。

選んだ理由は、人が読んだときに、理解がスムーズに進むことでした。選ぶときは文書全体を読みましたが、この段落でいえば、「脳みそに汗をかく」「判定の質」のような言い回しが消え、文が短くなっています。

どちらの段落も、評価基準には反していません。理解がスムーズに進むかどうかは、人によって判定が割れるので、評価基準には書けません。合格ラインの上の話です。なお、公開したVol.01のこの段落は、このあと仕上げでさらに直しています（実例2）。

実例2：仕上げで動かしたことを、評価基準へ書き戻す

Vol.01は、公開の前に、AIの力を借りながら私が最終稿に仕上げ直しました。そのとき、先に動かさないと決めて承認した16箇所のうち、5箇所を動かしています（注4）。段落の削除、冒頭の1文、最後の節の引用、見出しです。

たとえば、「はじめに」の冒頭の1文は、動かさないと承認していた箇所です。承認した版は「AIに、仕様と評価基準を渡さないまま作業させると、やり直しになるか、お客様やビジネスパートナーとのトラブルや信用の低下になって戻ってくることがあります」と、起きることから始めていました。公開した版では「先に結論を書きます。AIが賢くなっても判断が楽にならない原因は、評価基準が自分の頭の中にしかないことです」と、原因から始めています。

もう1つ、公開した版は、評価基準のうち、文の長さに関する1項目に届きませんでした。私はこれを例外として承認し、公開しています。最後に決めるのは人です。

Vol.02の仕上げ：AIの直しの案と、私の直しを突き合わせた

このシリーズのVol.02を仕上げるとき、はじめに・1章・3章について、同じ箇所のAIの直しの案と私の直しの案を突き合わせました（注5）。AIの案は、主張とぶつかって読める一文や、指示語の指す先が分からない箇所のように、論理と言葉の指す先に強く、そのまま評価基準の項目にできました。私の案は、読者に何を思い浮かべてもらうかと、業界の言い回しへの慣れに寄っていました。たとえば「企画書を部内で通す」のような会話の省略や、「前の会話を何も落とさなくなったら」の「落とす」を言い換える直しです。

こうした直しは、はじめは仕上げで私が入れたもので、あとで「AIの業界の言い回しを本文に出さない」「動詞には、何をどこへするのかを書く」といった評価基準の項目として書き戻せました。一方、Vol.02の問いを「何が手元に残るのか」から「何を手元に残すのか」へ、読者が自分で残す側に立つ形に変える直しは、項目にできず、仕上げの側に残りました。比べたのは1つのモデルと私1人で、1回だけの突き合わせです。

付記：この手順の背景

手順を使うだけなら、この付記は読み飛ばしてかまいません。

合否を判定するAI

2章で案内した工程図では、合否を判定するAIを「伴走AI」と呼び、合否の判定に加えてペルソナへの依頼も受け持ち、段取りから受け入れまで、人と並んで進む役にしています。

ペルソナの判定が甘くならない理由

AIには、相手に合わせて甘い答えを返す癖がある、と言われます。私の運用では、ペルソナの判定が甘くて困った記憶はありません。理由は3つあると考えています。1つ目は聞き方です。良いところではなく、どこで読むのをやめるか、どこで反論するかを聞きます。「最後まで読む」は答えとして認めず、評価者としてではなくその人本人として読んでもらいます。答えは、引っかかる箇所の一覧になります。2つ目は、ペルソナを、書いたAIからも私とのやり取りからも切り離して動かしていることです。私の場合は、伴走AIが、別の係のAIや系統の違うAIモデルに頼んでいます。3つ目は、ペルソナの答えを最初に読むのが、私ではなく伴走AIであることです。伴走AIが直す案と見送る案に整理し、採るかどうかを私が決めます。チャット型のAIだけで行う場合も、新しい会話で頼めば、1つ目と2つ目は同じ条件になります。

ペルソナの意見が割れたときの扱い

困るのは、むしろ逆の場面です。企画の段階では、ほとんどの場合、複数のペルソナに読ませます。立場が違えば、気にすることも違います。全員が納得する形には、まとまらないこともあります。あるペルソナが納得せず、企画の段階に長くとどまりすぎていると判断したときは、私が、そのペルソナが代表する受け手の優先順位を下げると決め、その指摘を見送って企画を先に進めます。ペルソナの答えとは別に、私自身の判断で受け手を選び直すこともあります。ウェビナー第1回の企画では、途中で受け手を研修講師から事業開発の担当などに替え、研修講師向けは第2回に回すと決めました。どの受け手を優先するかを決めるのは、ペルソナでもAIでもなく、人です。その判断の結果に責任を持つのも、人です。

CycleGenとの関係

Vol.02で紹介したCycleGenと、本稿のDANDORI 8:2は、横に並ぶものではなく、上下の関係にあります。

CycleGenの型は、次の順で回る協働の手順で、約1時間で1サイクルです。これが土台にあたります。

AIが書く → あなたが判断・承認する → 文脈が蓄積する → 次がもっと良くなる

手元でやることの言葉でいえば、1サイクルごとに、AIがたたき台を書き、人が判断して、その理由を残します。DANDORI 8:2は、CycleGenの1サイクルを積み重ねて、1本の成果物を作る手順です。1本の提案書や論考は、何回分ものCycleGenにまたがって仕上がります。

2つは、互いに材料を渡し合います。CycleGenで積んだ判断が、DANDORI 8:2の段取り（仕様と評価基準を決める段）の材料になり、DANDORI 8:2の仕上げで人が決めたことが、またCycleGenの記録に戻ります。

CycleGenがなくても、DANDORI 8:2の手順はチャット型のAIだけで回せます。ただし、段取りの材料になる過去の判断が手元にないので、毎回ゼロから段取りすることになります。

どこから来た考え方か

「段取り八分、仕事二分」は、私がリクルートで働き始めて2年目のころ、先輩から聞いた言葉です。意味を知ったとき、はっとしました。それから仕事を重ねるほど、段取りの大切さを実感してきました。一方で、段取りは多くの場面で後回しにされます。AIが速く書けるようになって、その傾向はいっそう強まっていると感じています。

私はかねてから、ナレッジワークを科学と工学の目で見てきました。Vol.02で紹介したCycleGenは、PDCAとカイゼン活動に起源があります。

段取りで私が大事にしてきたのは、企画の段階で、完成形をありありと思い描くことです。製品やサービスの企画なら、AmazonのWorking Backwards（完成形から逆算する企画の進め方）にならって、企画の時点でプレスリリースを書きます。プロジェクトを率いるときは、計画書を書く段階で、報告書の骨子をステークホルダーと合意しておきます。完成形から逆算して、いま決めることを決める、ということです。構想に近い段階で企画を磨いておくと、後の工程が鋭くなることを、何度も経験してきました。

DANDORI 8:2で、書く前の企画を受け手のペルソナに読ませるのも、その延長です。AIに受け手を演じてもらうと、自分に見えていなかった視点が見えてきます。これも、使ってきた中で知ったことです。

ソフトウェアやAIの開発にも、近い考え方があります。作る前に何を作るかを決める要件定義、何をもって受け取るかを先に決める受入テスト、テストを先に書いて通るまで作るテスト駆動開発、AIの出力を決めた基準で採点するやり方です。どれも、DANDORI 8:2と同じ方向を向いています。違うのは、文章では言葉そのものが成果物なので、仕様と評価基準を前もって書き切れないことです。だから、評価基準で保証できるのは合格ラインまでで、その先は人が上げます（5章）。

会社の審査シートとの関係

会社が決めた審査シートや評価シートを持っている方もいると思います。審査シートの項目は、組織がどの成果物にも当てるもので、本稿の評価基準は、その成果物に当てるものです。シートの項目はそのまま引き継ぎ、シートにない、その受け手とその成果物だけの条件を足します。

審査シートの項目を引き継いでおけば、社内ルールを守っていることを後から示せます。足した条件はシートにないので、足した理由を、その成果物の評価基準に残しておきます。

文章以外への応用

本稿の実録は、提案書・告知文・論考といった文書のものです。それでも、この工程は、映画や動画の企画、漫画のネーム、広告のクリエイティブ、システムやAIエージェントの要件定義のように、作り終えるまで受け手の反応が分からない仕事にも当てはめられると考えています。撮影や編集のように、作り始めてから直すほど費用がかさむものほど、書く前に直せる差は大きくなります。動画の台本は文章であり、これまでの文章をペルソナに読ませる経験と同様、視聴をやめる箇所を聞けます。

2章で案内した工程図は、本稿のような解説文章を作るための工程です。文章を1本仕上げておけば、そこからスライドや音声・動画の解説は、AIツールに任せられます。

検証の範囲

本稿で書いたことを、観察したこと、測っていないこと、仮説の3つに分けます。実証は2社・3名の実運用によります。内訳は、当社2名と、実録編Aの協業先のうち1社の実務者1名です。数字の出所は、次の注にまとめています。

観察したこと

• 書いてから人が読んだ講習資料で、作り終えたあとに赤入れが21件出た。うち6件は、中身の説明を直すものだった（3章、実録編A 実録1）
• 書く前にペルソナに読ませた資料で、作る前に直しが6件出た。うち1件は、評価基準の項目そのものだった（3章、実録編A 実録2）
• 立場の違う3つのペルソナは、指した項目こそ違ったが、直し方の指摘はそろった（実録編A 実録2）
• 告知文では、3つのペルソナが同じ段落で読むのをやめた（実録編B）
• 評価基準の言い回しを4回直し、別の会話のAIとの判定の一致が12場面中12場面になった（4章、実録編C）
• 同じ仕様と評価基準で書かせた3つの版は、すべて評価基準に合格し、どれを採るかは評価基準では決まらなかった（5章、実録編D 実例1）
• Vol.02の仕上げで、AIの直しの案は評価基準の項目にできるものが中心で、読者の受け取り方に関わる直しは私の案から出た。比べたのは1つのモデルと私1人で、1回の突き合わせ（5章、実録編D）

測っていないこと

• この手順で、手戻りがどれだけ減るか。実録編Aの2本は相手も資料の種類も違い、条件のそろった比較ではない
• 書く前にペルソナに読ませていれば、実録編A 実録1の6件が見つかったか
• ペルソナの指摘が、本物の受け手の反応と合っていたか
• 評価基準の言い回しで、人どうしの判定が一致するか（4章で判定したのは、同じ系統のAI）
• 段取りに時間をかけたぶん、作業のあいだ人がAIに張り付かずに済む時間がどれだけ増えたか。比べるのは総工数ではなく、人が拘束された時間（段取り・判定・仕上げの合計）。AIエージェントツールで回す場合の話で、チャット型AIで一問ずつ応じる使い方には当てはまりにくい

仮説

• 評価基準に先に合意すれば、組織の承認は照合になる（6章）
• 仕上げから書き戻した評価基準は、次の成果物でも効く（5章）
• 組織の複数の人で、同じ評価基準とペルソナを育てられる（6章、次に考えたい問い）
• 同じ工程が、動画など文章以外にも当てはまる（付記「文章以外への応用」）

注：数字の出所

本文の数字は、すべて当社の社内記録で数えた値です。記録そのものは公開していません。

• 注1（3章、実録編A 実録1）：赤入れ21件と、そのうち中身の説明を直すもの6件。赤入れを1件ずつ書き出し、すべて書き終えてから一括で分類した記録（2026年9月10日）より。
• 注2（3章、実録編A 実録2）：直すと判定した指摘6件。ペルソナ評価の記録（2026年9月11日）より。
• 注3（4章、実録編C）：4つの版それぞれについて、私が先に書いた答えとペルソナの答えを場面ごとに突き合わせた記録（2026年9月25日）より。2つの問いの最終の言い回しは、公開済みのVol.02の7章で読めます。
• 注4（5章、実録編D）：16箇所のうち5箇所と、外部の評価4本。承認した一覧と最終稿を機械で突き合わせ、評価の立場を1本ずつ確認した記録（2026年9月24日）より。実例1の段落の比較は、元の版と採った版（いずれも2026年9月23日）と公開した版（2026年9月30日）を、実例2の冒頭の比較は、承認した版（実例1で採った版）と公開した版を、突き合わせた記録より。文の長さの1項目の例外は、公開時の承認の記録より。
• 注5（5章、実録編D）：Vol.02のはじめに・1章・3章について、同じ箇所のAIの直しの案と私の直しの案を突き合わせた記録（2026年10月12日）より。
• 注6（実録編B）：3つとも同じ段落でやめたこと、論考のリンクを先に押すと答えたこと、評価基準が分からなかったこと。ペルソナ評価の記録（2026年9月24日）で、3つの答えを突き合わせて数えた。
• 注7（実録編B）：新規事業開発の担当のペルソナは2026年9月19日に作成。6回は、本稿の企画のペルソナ評価の記録（2026年9月27日まで）で数えた回数。

著者・お問い合わせ・著作権など

佐藤 純也（株式会社らしく 代表取締役）

リクルートの情報システム部門を経て、J.D.エドワーズ（現・オラクル）、ダブルクリック（現・グーグル）、セールスフォースなどで、顧客企業のIT導入と組織変革に携わる。2011年に株式会社らしくを設立。2025年夏からClaude Codeをソフトウェア開発以外の仕事に転用し、その実践からAI協働フレームワークCycleGenを開発。AIとの協働で、人が判断する工程をどこに置くかを設計している。本稿で扱った手順は、社内で提案書や告知文を作るときに使っている。

ご連絡は info@rashikucorp.com までお願いします。CycleGenの入れ方は https://cyclegen.ai にあります。

自分の仕事で試してみた方、この考え方を紹介したい方は、上の連絡先にご一報ください。DANDORI 8:2の工程を自分の仕事に合わせて作りたい方のご相談も、同じ連絡先で受けています。

手順の名前＝AI時代の段取り八分 ―― DANDORI 8:2。

第1.4版 ／ 2026年10月 ／ 株式会社らしく