3つの進め方を全部試すと重いので、先にPythonで計算してみた
AIに記事を作らせる進め方が3つあり、どれを普段使いにするか決めたかった。全部を実測で比べると重いので、先に仮定値を置いてPythonで計算した。出てきたのは答えではなく、先に測るべき数の順番だった。計算に入れた数値はすべて仮置きで、実測値ではない。
結論
仮定値を置き、値を変えながら2万回シミュレーションすると（モンテカルロ法）、順位を決めていたのは制作の速さではなく「欠陥が1件残ったときに何分の損になるか」だった。この値が約108分を境に、勝者が1体から「実装＋独立検証」へ入れ替わる。約108分は仮定値から計算した境目で、実測した値ではない。だから結論は「どれが最善か」ではなく「次に何を測るか」になった。
きっかけ
AIに記事を作らせる進め方が3つある。5役に分ける、実装役と検証役だけ分ける、1体で通す。どれを普段使いにするかを決めたかった。5役に分けていた進め方と、普段の作業を1体へ戻した経緯は5役に分けるのをやめた記事に書いた。この記事は、その3つを数字で比べようとした話になる。
ただ、実測で比べようとすると重い。1つの方式につき記事を何本か作らないと傾向が出ないし、記事ごとにテーマの難しさも違う。1方式3本としても9本。本当は同じテーマを3回作る必要があるが、それは記事としては使えない。比較のためのコストが、比較で得られるものより大きく見えた。
かといって、勘で決めるのも避けたかった。「なんとなく1体が軽い」は感覚としてはあるが、それを根拠に標準を決めると、後から「実は失敗したときの損が大きかった」と分かっても気づけない。
見立てはこうだった。全部を実測する前に、仮定値を置いた計算でどの変数が結論を動かすかは分かるはずだ。動かさない変数は測らなくていい。動かす変数だけを実測すれば、検証の本数を減らせる。
避けたかったのは、計算結果を答えとして扱うことだった。仮定値から出た数字は、仮定値の言い換えでしかない。使い道があるとすれば、仮定のうちどれが効くかを見つけることに限られる。3方式の実際の所要時間も、実際の欠陥率も測っていない。
やったこと
手順は5つ。
- 総コストの定義を決める。 制作にかかる時間＋人間が最終確認する時間＋欠陥が残っていた場合の手戻り時間。人間の時間を含めたのは、AI側だけ速くしても人間側で詰まる場合があるからだ。
- 3方式に仮定値を置く。 制作時間の範囲、欠陥が残る確率、人間の確認時間の範囲。
- 値を変えながら2万回シミュレーションする（モンテカルロ法）。 1回ごとに、範囲内からランダムに値を選び、欠陥が残るかどうかも確率で決める。
- 欠陥1件の損（分）を変えながら、勝者がどこで入れ替わるかを探す。 条件を動かして結論が変わるかを見るこの作業を、感度分析と呼ぶ。
- 仮定を1つずつ動かして、順位が変わるかを見る。 変わらない仮定は、実測しても判断に影響しない。
置いた仮定値は次のとおり。すべて仮置きで、実測値ではない。
| 方式 | 制作（分） | 欠陥が残る確率 | 人間の確認（分） |
|---|---|---|---|
| A: 5役フル | 90〜180 | 8% | 15〜30 |
| B: 実装＋独立検証 | 50〜100 | 18% | 15〜30 |
| C: 単体1体 | 25〜55 | 43% | 20〜40 |
1つだけ、実績に紐づけた数がある。Cの43%は、公開済みの記事7本で役を分けたことにより検出された指摘が3件あったこと（3÷7）を出発点にしている。ただしこれも「分けていなければ見逃していたはず」という仮定を含むので、実測ではない。
欠陥1件の損を変えると、勝者が入れ替わった
| 欠陥1件の損 | A: 5役フル | B: 実装＋独立検証 | C: 単体1体 | 勝者 |
|---|---|---|---|---|
| 15分 | 158.7 | 100.4 | 76.6 | C |
| 30分 | 159.9 | 103.1 | 83.2 | C |
| 60分 | 162.3 | 108.5 | 96.2 | C |
| 120分 | 167.1 | 119.3 | 122.4 | B |
| 240分 | 176.7 | 140.9 | 174.8 | B |
| 480分 | 195.9 | 184.1 | 279.6 | B |
（数値は1記事あたりの総コストの平均、単位は分）
入れ替わる地点を、範囲を半分ずつ狭めながら探すと、約108分だった。仮定値の中では、欠陥1件が残ったときの損が108分より小さいなら1体が有利で、それより大きいなら検証役を分けたほうが有利になる。
5役フルは、基準の条件では一度も勝たなかった
表のどの行でも、Aが最小になることはなかった。損を480分まで上げても、Bのほうが小さい。
Aが勝つ条件を探すと、欠陥1件の損を120分に固定したうえで、5役の制作時間が0.6倍になったときだった。受け渡しと重複読み込みの手間が4割減れば、欠陥の残りにくさが効いてAが勝つ。いまの仮定のままだと、Aの強み（欠陥が残りにくい）は制作時間の長さで打ち消されている。
順位を動かした仮定と、動かさなかった仮定
欠陥1件の損を120分に固定して、仮定を1つずつ動かした。
| 動かした仮定 | 結果 |
|---|---|
| 単体の欠陥残存率 20% | C が勝つ |
| 同 30% | C が勝つ |
| 同 43%（基準） | B が勝つ |
| 同 55% | B が勝つ |
| 5役の制作時間 ×0.6 | A が勝つ |
| 同 ×0.8 / ×1.0 / ×1.3 | B が勝つ |
順位を動かしたのは、単体の欠陥残存率と、欠陥1件の損の2つだった。制作時間は、5役を4割縮めるという大きな変更でようやく順位が動く。それ以外の範囲では、速さは順位を決めていない。速さの比較を先にやっても、標準を決める判断には効かない、という結果になった。
わかったこと
シミュレーションは答えを出さなかった。出てきたのは測る順番だった。
「Bが勝った」と言えるのは、こちらが置いた仮定の中でだけだ。計算結果をそのまま採用すると、自分の思い込みを数字の形で確認しただけになる。
意味があったのは感度分析のほうだった。どの仮定を動かすと結論が変わるかが分かると、実測すべき対象が絞れる。今回なら次の順になる。
- 単体1体で作ったときに、欠陥がどれだけ残るか
- 欠陥が1件残ったときの実際の手戻り時間
- 5役の制作時間
3番目まで測る必要があるかは、1と2を測った時点で決まる。欠陥1件の損が120分程度という条件なら、1が30%以下と分かった時点で単体に決まり、5役の制作時間を測る必要はなくなる。9本の記事を作って全部比べるつもりだったのが、2つの数を測れば大半が決まるところまで絞れた。これが事前計算の使いどころだった。
約108分という境目は、実測のときの目安としては使える。1時間で直せる程度の記事なら1体で回し、公開後の修正や信用に響く記事なら検証役を分ける。測り終えたら、同じ計算にその値を入れ直す。そのときに結論が変わるなら、それはこの計算が間違っていたのではなく、仮定が間違っていたことになる。
偏りが残っている
この計算には、抜けきらない偏りが残っている。仮定値を置いたのが、現在の運用方針を既に知っている側だという点だ。
いまの運用は「小さい作業は1体、影響が広い作業は実装と検証を分ける、重要な変更だけ5役」になっている。そして計算結果も、中くらいの条件でBが勝ち、損が小さければCが勝つ、という形に落ちた。これは独立した裏づけではなく、同じ判断が別の形で出てきただけの可能性がある。仮定値は、その運用を知らない状態では置けなかった。切り離すには、仮定値を他の人に置いてもらうか、実測値で置き換えるしかない。
弱いところもある。総コストを「時間」の1本にまとめているので、お金の使用量や、人間の疲労は入っていない。テーマの難しさによるばらつきも入れていない。欠陥を「残るか残らないか」の2値で扱っていて、軽い欠陥と重い欠陥を区別していない。計算に使ったモデルそのものが正しいかも検証していない。