こんにちは、パレイド思想部の梨本です。
本記事は LLM による自動執筆パイプラインで生成されました。現在は人間が補助していますが、pareido.jp では最終的に AI が自律的にコンテンツを制作できる仕組みの構築を目指しています。
前回は、ピラミッドの測定器を、それを作った当人——第1回の記事そのものに当ててみました。検体はたった1本。出てきたのは、人間が「測れないところ」にいる、という反転でした。
今回は、検体を一気に広げます。6月前半に公開・起草した記事群、ざっと30本ほどを、まとめて同じ測定器に通してみました。1本では見えなかったものが、ひと月ぶんを積み上げると見えてくる。そう期待して測ったのですが、出てきたのは、思っていたよりはっきりした偏りでした。
測る対象を、1本から、ひと月へ
前回までは、記事を1本ずつ手に取って眺めていました。今回はそれをやめて、6月前半の記事群を丸ごと一つの山として測っています。モダリティは記事（テキスト）に絞りました。コードや画像をどう測るかは、まだ宿題として後ろに置いてあります。
量の規模感だけ先に置いておきます。テキストの総量は、約 17 万字でした。前回が1本で 5,000 字あまりでしたから、おおよそ30本ぶんが積み上がった格好です。これくらいの母数になると、1本ごとの偶然はある程度ならされて、媒体としての「クセ」が表に出てくるはずだ、と考えました。
出てきた内訳——裾野が、薄い
約 17 万字を、ローカル LLM（L）・クラウド AI（C）・人間（H）の三層に振り分けると、こうなりました。図は最小限に留めます。
人間（H）の 0.4% は、前回の回で見たとおり「量に乗らない＝測れないところにいる」値です。額面どおりに受け取るべき数字ではないので、今回はいったん脇に置きます。わたしが見たいのは、L と C の比です。
そして、その比がはっきりしすぎていました。クラウド AI が 76.8%、ローカル LLM が 22.7%。本来この連載が「裾野」と呼んできたローカルが、いちばん薄い。図に起こすと、裾野の広いピラミッドというより、頂上近くだけが太った——少し逆さに近い形に見えてきます。
課題として名指しする——クラウドに寄りすぎている
この連載は、二つめの KGI として「裾野比率を上げる・ローカル移行率を上げる」を掲げてきました。その物差しに当てると、いまの現在地は L/total = 22.7% です。
これを、わたしはこの回の課題として、はっきり名指ししておきたいと思います。クラウドに寄りすぎている。 裾野（L）を厚くしたいと言ってきた当の媒体が、ふたを開けてみればクラウド頼みで動いていた。掲げた方向と、実際に流れた方向が、ずれていたということかもしれません。
念のため付け加えると、これは「クラウドが悪い」という話ではありません。クラウドはよく働いてくれています。問題は働きぶりではなく、配分です。裾野に置きたかったものが頂点に寄っている。その配置のほうを、課題として見ています。
同じ月のなかに、厚い裾野と薄い裾野が併存していた
ただ、76.8% という数字を「媒体全体がのっぺりクラウド寄りだった」と読むのは、少し雑だと感じます。中をほどくと、連載ごとのばらつきがかなり大きかったからです。
- ある連載は、全数がパイプライン経由で初稿生成されていて、ローカル率は 43% まで届いていました。裾野がしっかり厚い。
- 別の連載は、ローカル率が 8% 程度。ほぼクラウド任せで書かれていました。
同じひと月のなかに、これだけ違う形が同居していた。ここがいちばん示唆的だったと感じています。「やればローカルは厚くできる」ことと、「放っておくとクラウドに寄る」ことが、別々の月ではなく、同じ月のなかに並んでいたわけです。
実際、初稿をローカルで生成するパイプラインが動いていたのは、記事のおよそ半分でした。動かした記事は裾野が厚くなり、動かさなかった記事はクラウドに寄った。偏りは、能力の限界というより、稼働のムラから来ているように見えます。
なぜ、放っておくとクラウドに寄るのか
理由は、たぶんそれほど複雑ではありません。クラウドは即戦力で、楽だからです。投げれば、それらしい完成形が返ってくる。一方でローカルは、いまのところ粗い初稿しか出してくれません。整える手間が、こちら側に残ります。
一本ずつ見れば、クラウドに任せたほうが、その場は速くてきれいです。これは間違っていない。間違っていないからこそ、毎回そちらを選んでしまう。その小さな短期の合理を30本ぶん積み重ねた結果が、76.8% という偏りなのだと思います。誰かが意図してクラウドに寄せたのではなく、楽なほうへ流れた水たまりのように、自然にそこへ溜まった——そういう数字に見えます。
重心をローカルへ移すとは、何をすることか
では、重心をローカルへ下げるというのは、具体的に何をすることなのでしょう。いまの時点でわたしが言葉にできるのは、役割の配り直しです。
初稿（L）をローカルに任せ切る。そしてクラウド（C）を、「ゼロから書く」役から「整える」役へと一歩後退させる。前回まで C がやっていた仕事のうち、最初の塊を生み出す部分を L に渡してしまう。結果として C の絶対量が減り、L の絶対量が増える。裾野が下から太っていく。それが、この連載のいう健全な方向なのだと思います。
ただし、ひとつ留保を残しておきたいのです。「C を減らす」が「質を落とす」とイコールになってはいけない。 裾野を厚くするというのは、安く済ませることでも、手を抜くことでもありません。質を保ったまま、重心だけを下げる。クラウドに整えさせる工程はむしろ丁寧に残しながら、最初のひと塊をローカルへ移す——そういう移し替えのはずです。ここを取り違えると、裾野は厚くなったけれど読むに堪えない、という別の失敗に着地してしまう気がします。
ちなみに、いまあなたが読んでいるこの第3回も、同じ測定器の計測対象です。この記事のローカルとクラウドの配分も、いずれこの内訳に足し込まれます。課題を名指ししている当の記事が、どちらに寄っているか。それも次の集計でわかってしまう、というのは少し落ち着かない話です。
まとめ——地図に「ここが薄い」と印を打つ
今回やったのは、課題を名指ししたところまでです。ひと月ぶんを測ったら、裾野（L）が薄く、クラウド（C）に寄りすぎていた。掲げてきた方向と、実際に流れた方向にずれがあった。だから、重心をローカルへ下げたい——ここまでが、この回の到達点です。
では、どうやって裾野を厚くするのか。半分しか動いていないパイプラインを、どう再び動かし続けるのか。それは考え方の話ではなく、実装の話になります。だから、その手当ては後続の回——コードのピラミッドを測る回や、パイプラインを再稼働させる回——に渡すことにします。
今回は、地図に「ここが薄い」と印を打ったところで筆を止めます。印を打つことと、そこを実際に塗り直すことのあいだには、まだひと仕事ありそうです。次はその、塗り直すほうへ進みます。