第6章: 合格するまで繰り返す

X投稿を8本作って品質チェックにかけたところ、3本が不合格になりました。

記事の要約としてはよくできている。文章は丁寧だし、内容に間違いもない。でも、読んだ人が「ふーん」で終わってしまう。noteのリンクをクリックする理由がないのです。つまり、それっぽいけれど、ゴールに向かっていない

前章で「合格基準を先に決める」大切さをお伝えしました。基準を作ったこと自体は正解でした。基準がなければ、この3本は「よくできた要約」としてそのまま投稿されていたはずです。しかし基準を作っただけでは、品質は上がりません。不合格の成果物を、どうやって合格ラインまで引き上げるか。この章のテーマです。


あなたの品質サイクルはどの段階?

まず、今のあなたの状態を確認してみてください。

全部チェックが付いた方: この章はスキップして第7章へ進んでも構いません。ただし「修正回数の設計」と「上限を超えたときの対処」は一読の価値があります。

1〜3個チェックが付いた方: 品質サイクルの「部品」は揃い始めています。この章で抜けている部分を補いましょう。

チェックがゼロの方: この章があなたのAI活用を変えるターニングポイントになります。焦らず、ひとつずつ取り入れてください。


「一発合格」という幻想を捨てる

料理を思い浮かべてください。味見もせずに料理を出す人はいません。味が薄ければ塩を足し、もう一度味見する。それでも何か足りなければ醤油を少し加えて、また味見する。当たり前のことです。

ところが、AI社員の仕事になると、なぜか「一発で完璧なものが出てくる」と期待してしまいます。「AIなんだから、指示を出せば正しいものが返ってくるはずだ」と。しかし実際には、新入社員に初めて企画書を書かせたのと同じで、最初から完璧なものが出てくることは稀です。

違うのは、修正のコストです。人間に「もう一回やり直して」と頼めば、相手の時間も気持ちも消耗します。AI社員なら、修正依頼は数秒で完了します。SNS投稿文のような短い文章なら数秒、記事1本でも数十秒で修正版が返ってきます。人間に同じことを頼んだら何時間もかかる作業が、その場で終わるのです。

だから発想を変えます。一発で合格させようとするのではなく、合格するまで繰り返す仕組みを作る。これが品質サイクルです。


X投稿3本不合格から始まった品質サイクル

話をX投稿の3本不合格に戻します。

まず、なぜ不合格になったのかを分析しました。不合格の理由は2つ。1つは文字数が長すぎたこと。もう1つは、もっと根本的な問題でした。

不合格の投稿文は、記事の内容をただ要約しているだけだったのです。X投稿のゴールは「記事の要約を見せること」ではなく、「読んだ人がnoteの記事を読みたくなること」です。「この人に仕事を頼みたい」と思わせるのはnote記事の役割で、X投稿はそこへの入り口です。第1章で設定した「ゴール照合」の観点で見ると、目的を達成しない投稿文だったのです。

ここで、最初の修正指示を出しました。「要約ではなく、読者が続きを読みたくなる切り口で書き直して」。AI社員は数秒で書き直してきました。切り口は改善されました。しかし文字数がまだオーバーで、1本が不合格のまま。

2回目の修正指示。「文字数を140字以内に収めつつ、読んだ人がクリックしたくなる一文を冒頭に置いて」。今度は具体的に「何を」「どう直すか」まで伝えました。結果、ようやく8本すべてが合格しました。

この体験を振り返ると、品質サイクルの骨格が見えてきます。

まず、作業を始める前に合格基準を確認する。基準がなければ先に定義する。これは前章の内容です。次に、AI社員に成果物を作らせる。そして合格基準に照らして評価し、結果を記録する。不合格の項目があれば、何が足りないのかを具体的に伝えて修正させる。修正された成果物を再び同じ基準で評価する。合格すれば納品。不合格ならもう一度修正。

基準確認、作成、評価、修正、再評価。この5つで1サイクルです。そして鉄則は一つだけ。合格していないものを納品しない。


「もう一回やって」では品質は上がらない

X投稿の修正で気づいた、もう一つの重要なことがあります。

1回目の修正指示は「要約ではなく、読者が続きを読みたくなる切り口で」でした。方向性は合っていましたが、具体性が足りなかった。だから文字数の問題が残りました。2回目は「140字以内」「クリックしたくなる一文を冒頭に」と具体的に伝えました。すると1回で通った。

「ダメ、やり直し」では品質は上がりません。「この項目がこういう理由で不合格だから、こう直して」と明確に伝えることが重要です。

川島さんにも同じことが起きました。前章でAI社員に問い合わせメール返信のチェックリストを作った川島さん。今度はAI社員に取引先への提案メールを作らせました。品質チェックをかけると、文章は丁寧ですが、相手が質問していた納期の話にまったく触れていません。不合格です。

川島さんは「もう一回やって」と指示しました。返ってきたメールを見ると、言い回しは少し変わっていますが、納期の話は相変わらず入っていません。また不合格。

そこで指示を変えました。「相手の質問に対する直接回答を冒頭に入れて。具体的には、納期について聞かれているので"3月末に納品可能です"のように答えてから本題に入って」。AI社員はこの指示で1回で合格を出しました。

「もう一回やって」は、AI社員にとって情報がゼロの指示です。何が悪かったのかわからないまま、サイコロを振り直しているだけ。「ここがダメだから、こう直して」は、AI社員の判断基準を更新する指示です。この違いが、1回で合格するか3回かかるかを分けます。


修正回数に上限を設ける理由

品質サイクルが回り始めると、次の問題が出てきます。「何回まで修正させるか」です。

CC Company(シーシーカンパニー)では当初、修正回数に上限を設けていませんでした。「合格するまで繰り返す」を文字通り実行していたのです。ほとんどのタスクは2〜3回で合格しました。しかし、ある記事の品質チェックで問題が起きました。修正を繰り返しても、合格ラインの80点にどうしても届かない。4回、5回、6回。修正のたびに少しずつ点数は上がるものの、合格ラインに達しません。

原因を調べてみると、合格基準自体に問題がありました。1つの記事に対して、相反する2つの基準が設定されていたのです。「簡潔に書く」と「詳細な根拠を入れる」が同時に要求されていて、片方を直すともう片方が下がる。どれだけ修正を繰り返しても、両方を同時に満たすことは構造的に不可能でした。

この経験から、CC Companyでは修正回数の上限を5回に設定しました。5回修正しても合格しない場合は、AI社員の問題ではなく、指示や基準の問題である可能性が高い。だから5回で止めて、人間に判断を返すようにしています。

川島さんが「もう何回やっても同じだ」と感じた日

川島さんにも似たことが起きました。議事録をAI社員に作らせていたのですが、「決定事項の書き方が曖昧」と3回指摘しても直りません。同じフィードバックを3回繰り返しても品質が上がらないのです。

原因は、修正指示自体が曖昧だったことでした。「決定事項を明確に書いて」では、AI社員は何をどう明確にすればいいのかわかりません。川島さんが「決定事項は"誰が/何を/いつまでに"の3要素で書いて」と書き換えたら、1回で合格しました。

この話からわかることが2つあります。まず、3回同じ指摘をして直らないなら、修正指示の出し方を変えるべき。AI社員が悪いのではなく、指示が伝わっていない。次に、上限がなければ、同じ失敗を何度でも繰り返してしまう。上限があるから「このやり方では無理かもしれない」と立ち止まって考える機会が生まれるのです。

上限に達したら人間が判断する

CC Companyでは、上限の5回に達すると自動的に「人間判断待ち」の状態に移行します。人間が状況を見て、合格基準が厳しすぎたなら基準を見直して再実行する。このアプローチでは無理だと判断したらタスクを中止する。問題が大きすぎるなら小さく切り分けて再挑戦する。この3つの道から選びます。

「出口のない仕組みは必ず壊れる」。この原則は第10章でさらに詳しく解説します。


コラム: note記事を80点から93点に引き上げた話

CC Companyではnote記事を100点満点の基準で評価しています。80点以上がA(公開OK)、60〜79点がB(修正後に公開)です。

ある記事を品質チェックにかけたところ、80点でした。合格ラインぎりぎりです。他の記事が90点台で揃っている中、80点の記事をそのまま出すのは気になります。基準上は合格ですが、品質にばらつきがあることが数字で見えてしまった。

ここで品質サイクルを回しました。まず不合格項目を確認すると、「読者の痛みに具体的な名前をつけていない」「処方箋(解決策)が抽象的」の2点が低得点でした。1回目の修正指示: 読者の痛みに「ゴースト文体問題」という名前をつけ、処方箋を「文体の設計図を作る3ステップ」に型化するよう伝えました。

修正後、再評価したところ93点。13点上がりました。不合格項目がなくなっただけでなく、記事全体の切れ味が上がりました。痛みに名前がつくと読者が「まさにそれ」と思えるし、処方箋が具体的だと「やってみよう」と思えます。品質サイクルを1回回すだけで、「ぎりぎり合格」が「胸を張って出せる記事」に変わったのです。


なぜ繰り返すと品質が上がるのか

ここで、もっともな疑問が浮かぶかもしれません。「同じAI社員に同じ仕事をやり直させて、本当に結果が変わるのか?」と。

結論から言えば、変わります。しかもこれは偶然ではなく、AIの仕組み上、必然的にそうなります。理由は2つあります。

理由1: AI社員は毎回まったく同じ文章を作るわけではない。 AI社員が文章を書くとき、一語ずつ「次にどの言葉を使うか」を選んでいます。この選び方に、意図的にランダム性が組み込まれています。「最も確率の高い言葉」だけを毎回選ぶのではなく、確率が高い言葉の中から少し幅を持たせてランダムに選ぶ仕組みです。この幅を制御するのがTemperature(テンパレチャー:出力のランダム性を制御する設定値)で、多くのAIサービスではこの幅がある程度大きく設定されています。だから、同じ指示でも実行するたびに異なる結果が返ってきます。サイコロを振り直すようなもので、次はもっと良い目が出るかもしれないのです。

理由2: 修正指示が、AI社員の判断基準を変える。 品質サイクルでは単に「もう一回やって」と言うのではなく、「ここが不合格だったから、こう直して」と具体的な修正指示を出します。この修正指示はAI社員にとって新しい情報です。たとえば、「権威性が足りない」というフィードバックを受ければ、次の生成では「権威性」に関連する表現を優先的に選ぶようになります。1回目とは異なる判断基準で文章を組み立てるため、結果も変わるのです。

これは研究でも裏付けられています。カーネギーメロン大学のマダーン(Madaan)ら(2023)は「Self-Refine」(セルフリファイン:自己改善)という手法を発表し、AIが自分のフィードバックを使って反復改善するとタスク品質が平均約20%向上することを示しました(NeurIPS(ニューリップス:機械学習の国際学会) 2023採択)。CC Companyの品質サイクルはまさにこのアプローチを業務に応用したものです。フィードバックを与えて修正させる行為は、根性論ではなく、AIの仕組みに基づいた合理的なアプローチなのです。

さらに、「基準を作る、チェックする、修正する、再チェックする」というサイクル自体の有効性は、AI以前から製造業や医療の現場で実証されています。これは第5章でも触れたPDCAサイクルと呼ばれる手法で、製造業では製品欠陥が65〜79%減少したという研究報告もあります(Applied Mathematics and Information Technology, 2025)。AI社員の品質管理に使っているのは、何十年も前から効果が証明されている仕組みを、新しい技術に当てはめただけなのです。


LLM(Large Language Model:大規模言語モデル)知識: Temperatureとサンプリングの技術的補足

本文で紹介したTemperatureについて、もう少し技術的な補足をします。

AIが「次の単語」を選ぶとき、内部では候補となる単語それぞれに確率が割り当てられています。たとえば「今日の天気は」の続きとして「晴れ」に40%、「曇り」に30%、「雨」に20%、その他に10%、のような確率分布です。Temperatureが低い(例: 0.1)と、最も確率の高い「晴れ」がほぼ毎回選ばれます。Temperatureが高い(例: 0.8)と、「曇り」や「雨」が選ばれる確率も上がります。さらに、修正指示によって文脈が変わると、確率分布自体が再計算されるため、2回目の方が良い結果になる可能性が構造的に高まります。

つまり「やり直させると偶然良くなることもある」のではなく、「修正指示が文脈を変え、確率分布が変わることで、構造的に改善される」のです。品質サイクルを回す行為は、この仕組みを意図的に利用しているのです。


規模に応じた実践

個人で始める場合: まず1つの業務で品質サイクルを試してください。たとえばAI社員に書かせたメールを、自分で3項目チェックして、不合格なら修正指示を出す。それだけです。チェック項目は3つで十分です。慣れてきたら項目を増やしていけばいいのです。

チームで運用する場合: チーム共通の合格基準を作り、品質チェックの結果を共有フォルダに記録してください。「誰がいつチェックして、結果はどうだったか」が見える状態にすることで、属人化を防げます。修正回数の上限(3〜5回が目安)を決めておくと、「いつまでも修正が終わらない」問題を予防できます。

組織として仕組み化する場合: CC Companyのように、品質サイクルをワークフローに組み込みます。成果物の重要度に応じて審査レベル(第5章)を設定し、チェック記録を残し、上限超過時のエスカレーション先を決めます。さらに、品質チェックの結果を定期的に分析すれば、「どの部門のどの業務で修正回数が多いか」が見えてきます。そのデータが、指示の改善や基準の見直しにつながります。


まとめ

品質サイクルが回り始めました。しかし、1人のAI社員にあれもこれも任せていると、ある問題が起きます。


ここまでの内容(目的の設定、業務の分解、弱点の理解、育成マニュアル、合格基準、品質サイクル)は、AI社員育成の土台です。この土台づくりの段階で詰まりやすいのは、実は「どの業務からAI化すべきか」の優先順位です。業務を洗い出せても、どれが効果が高いかは自社の事情によって異なります。

もし「業務は分解できたが、どこからやるか決められない」「合格基準の粒度が自社に合っているか自信がない」と感じたら、あとがきに外部の視点を活用する方法をまとめています。