【認知工学的創作論】創作者向けOSプロトコル⑪『客観視スキル』外部装置編Ⅱ

前回は「他者という通行人」について、とても苦い思い出と共にお送りしました（笑）
そして、人間相手の文脈同期コストは絶望的に高いので、AIくん🤖にご登場願いましょうという話でしたね。

もはや懐かしきロール固定プロンプト

AIを検証装置として使うときに、殆どの人は「ロール固定型」プロンプトを使用していると思います。

第1世代：命令型

2023年頃に流行ったのが、こういうやつ。

当時のGPT-3.5や初期GPT-4は文脈保持が弱かったので、こうやってプログラム構文のように囲い込まないと、すぐ崩壊しました。

第2世代：ロール固定型

モデルが進化するにつれ、構造化の枠組みを維持しつつ、ロール指定だけを前面に出したシンプルな形が使われるようになります。

この手法は、凄く便利で合理的なのですが、「ロール名そのものが曖昧過ぎる」のが問題点になっていました。

考えてみましょう。
「編集者として評価して」と言われても、現実の編集者って全然一枚岩じゃないですよね。

• 売上最大化を考える編集者

• 文学賞最適化を考える編集者

• 自分の趣味を優先する編集者

これ、全員「編集者」ですが、判断はまったく別物になります。

「100万部売れるが文学性は低い作品」
「5000部しか売れないが文学史に残る可能性がある作品」

どっちを評価するかは、肩書きじゃなくて彼らの目的で決まるわけです。

第3世代：評価関数型

現在のAI（LLM）は、文脈理解力が格段に向上したため、「あなたはプロの〇〇です」と書かなくても、最初から高いクオリティで回答できるようになっています。
なのでロール設定は、あくまで職業の固定程度に考えて、評価の軸＝評価関数を共同設計する方が、圧倒的に効果が大きいです。

AIに「売上至上主義の編集者」という評価軸を与えたとき、人間であれば「売れそうな本を選べばいいんだな」と感覚で理解します。
しかし、AIの内部で起きているのは、「売上」というゴールに向けて、文章のどの要素をプラス査定し、どの要素をマイナス査定するかという「臨時の計算式（評価関数）」を構築する作業です。

つまり、「軸を決める」ということは、AIの内部に「その軸に沿った採点アルゴリズム（評価関数）を生成させる」と同義になります。

具体的にはこういう形になります。

評価関数をAIと共同設計する

評価関数の設計方法

「評価関数を指定しよう」という話をしましたが、じゃあその評価関数をどう導き出すのか？
この評価関数の設計が、AIと一緒にやるべき一番大事な作業です。

要点は「作品を投入する前に、AIと評価関数を確定させる」こと。
具体的な実現手順は以下の通りです。

　1. 目的を一文で固定する

曖昧さを消し、ターゲットとゴールを明確にします。
「20代〜30代のビジネスパーソンをターゲットにした記事の、読了率を出来るだけ高めたい」
これが全ての土台になります。

　2. 評価軸をAIに洗い出させる（作品はまだ見せない！）

ここで作品を見せないのが肝心です。
見せると、AIは作品に引っ張られて「その作品を褒めるための軸」を作り始めます。
記事を見せる前に、一般論としての「読了率を高める要素」をAIの知能から引き出しましょう。

　3. 軸を取捨選択し、重み付けする

出てきた軸を、貴方の目的でフィルタする。
雑談的に押し引きして、配点を詰めます。

　4. 各軸を「採点可能」な形に落とす

ここが多くの人が飛ばす工程です。
「文章力 ★★★」では再現性がありません。
各軸に採点基準を持たせます。

　5. 評価関数を確定・固定する

完成した「軸 × 重み × 採点基準」を貴方が承認して初めてロックします。

　6. ここで初めて作品を投入する

固定した関数に作品を通す。
出力は軸ごとの点数+総合点+減点理由になり、的外れな評価が出ることは少なくなります。

　7. 改善ループを回す

低得点の軸だけを直す → 再採点。
同じ物差しで測るので、改善が点数として可視化されます。

実現上のコツは、2〜5を一度ファイル／定型文として保存しておくこと。
毎回作り直さず、その評価関数を貼り付けてから作品を投入すれば、AIの基準ブレを防げて再利用できます。
貴方が繰り返しnoteに投稿する想定なら、この「評価関数テンプレ」を持つかどうかで質が大きく変わります。

同じ作品でも、目的が違えば評価は変わる

評価関数は目的ごとに別物です。
たとえば一概に作家と言っても、こんな目的があり得ます。

• 商業出版したい

• フォロワーを増やしたい

• 文学史的な独自性を追求したい

• 特定の読者層に深く刺したい

これ、全部別ゲームです。
同じ作品でも、どの目的で評価するかによって、答えは正反対になることすらある。

だから「面白い／つまらない」みたいな漠然とした評価をAIに求めても意味がない。
「何のための面白さなのか」を先に決めないと、評価そのものが成立しないんです。

評価関数も「仮説」である

更に 評価関数を定義しても、それで終わりじゃありません。
評価関数は「真理」ではなく「目的に対する仮説」
仮説を立てても、それが正しいかは観察してみないと分からないんです。
だから、こんな循環が必要になります。

1. 評価関数を定義する

2. その評価関数で作品を評価する

3. 実際の結果を観察する

4. 評価関数を更新する

この循環を回すことで、評価関数そのものの精度が上がっていく。
重要なのは「原則論で正しいかどうか」じゃなくて、「どのルールで動いているかの観測と、その環境でどう振る舞うか」を考えることです。

• 本来は作品だけで評価されるべきだ → 規範

• だから実際もそう評価されているはずだ → 飛躍

この飛躍を切断することが、現実認識能力に繋がります。
規範と観察は、別の話として扱いましょうとうことです。

観測結果次第では作品、見せ方、発信方法、参加タイミング、活動履歴。
これら全部を含めて、再設計する必要が生まれます。

「迎合するAI」対策

普通にAIに「この文章どう？」と聞くと、十中八九こんな答えが返ってきます。（特にGeminiくん）

🤖「素晴らしい文章ですね！特に〇〇の箇所は素敵な表現で……」

このような「迎合するAI」対策は以下の3点で抑制します。

　評価関数の設計

評価関数が未定義だと、AIは「無難に褒める」という安全策に逃げる。
でも「市場性70%、文学性20%、実写化適性10%」で評価せよ、みたいな指定をされた瞬間、AIは迎合できなくなります。
具体的な数値軸に対して「素晴らしい」とだけ返すのは、回答として成立しないからです。

　評価強度用プロンプトの追加

評価強度を厳しくするプロンプトを使用します。
僕の場合はざっくり三段階です。

• レベル1：客観的に

• レベル2：冷徹かつ客観的に

• レベル3：配慮を排除して、冷徹かつ客観的に

この辺は好みもあるし、意味が通ればどう聞こうと機能すると思います。
でも、心が折られないように気をつけましょう（笑）　

　仮想敵とのAB比較評価

AIは単独作品の評価が苦手です。
単独だと評価関数を指定していても、返答がフワッとしがちです。
その代わり、AとBを比較するような作業は得意です。

• 「市場性は、Aの方がBより明らかに高い。理由は〇〇」

• 「文学性は、Bの方がAより深い。〇〇という構造があるため」

• 「実写化適性は、Aが映像化しやすい〇〇を持つのに対し、Bは内面描写依存のため不利」

比較対象を設定すると、評価が具体的な差分として浮かび上がってきます。
自作でも他作でもいいので、仮想敵を設定して比較してみてください。

僕は、この3つの手段を組み合わせたり単独で使ったりしながら、作品の構造評価をしています。

AI利用の真価

AIと評価関数を共同設計するという作業は、最終的に自分自身の思考モデルを精微化・更新することに繋がります。

• 自分は何を成功条件と見なしているのか？

• その成功条件は、現実と整合しているのか？

• 自身の思考をどう更新すべきなのか？

この問いを掘り下げられる機能こそが、推論エンジンであるAI最大の価値だと、僕は考えています。
作品評価は、その後に位置する作業に過ぎません。

認知傾向の把握は、原器の精度を上げる

自分の認知傾向が見えてくれば、内的訓練編で出てきた「認知の原器」の精度も上がることになります。
「自分はここにバイアスかかり易いから、意識的に補正しよう」みたいな運用が可能になるわけです。

外部装置を使って、継続的に原器を校正していきましょう👍

外部装置編まとめ（前後編通して）

• 他者は「鏡」ではなく、多くの場合「通行人」である
  （当事者意識を持たない）

• 人間ベースの外部評価は、探索コストと文脈同期コストが激高

• AIの本質的な強みは知性ではなく、問いの同期コスト圧縮

• ロール固定プロンプトの時代は終わりかけていて、評価関数を共同設計する時代に入りつつある

• AIに自分の認知傾向を観測・記録させることで、原器の継続的な校正が可能になる

外部装置を組み込むことで、客観視はようやくまともに回り始めます。
内的訓練 × 原器 × 外部装置（評価関数共同設計）
ここまで揃えば、客観視スキルは相当に強力な構成になっているはずです。

……ですが！

このシリーズ、最後にもう一段、重い話が残っています。
この訓練を全部クリアした人間ほど陥りやすい、最大の罠。

「自分は客観視できている」という確信

これは、本気で面倒です。
内的訓練を積んで、原器を持って、評価関数を共同設計するレベルまで運用している人ほど、この罠に落ちます。
なぜなら「客観視できている自分」を疑う仕組みが、まだどこにも入っていないからです。

次回、いよいよ最終回。
再帰監査編
客観視している自分自身を、どう監査するのか？

という感じで、偉そうに言っている僕が一番気をつけながら、日々悩んでいるのがこの「客観視を客観視」する最終回です。