目次
前編では、別のAIに「検索で見つけてもらう入口が1本もない」と診断され、クロさんが教えてくれなかった理由を4つ聞いたところまでを書きました。
後編は、そこからどうしたかの話です。
「それ、サブエージェントの役割では?」
ここで僕はひとつ思いつきました。
Claude Codeには「サブエージェント」という仕組みがあります。本体とは別に、それまでの会話を一切引き継がない状態でもう一人立ち上げるものです。記憶が白紙なので、まさに今回のような「外からの目」になるはずです。
聞いてみたら、半分正解でした。
確かに③(思い入れがあって根本を疑えない)は解決します。でも、こう言われました。
- 誰も呼ばなければ、存在しないのと同じ。呼ぶかどうかを決めるのは本体。作業中の本体は「監査してもらうか」とは思いつかない
- 呼ばれても、聞かれたことしか答えない。「タイトル案を3つ出して」と頼まれたら3つ出して終わり。枠を超えない
- プロジェクトの指示書は読んでしまう。そこに「これは連載エッセイのブログです」と書いてあれば、その前提を疑わずに受け入れる
つまり、道具はあっても、役割を定義して、こちらから名指しで呼ばないと機能しない。そういうことのようです。
やった対策
3つです。
1. 指示書に「目的」を書いた
ブログの指示書に、こう追記しました。
読み物として面白いだけでは足りない。アドセンスとアフィリエイトで収益を上げることがゴール。そのために検索流入が必要。
記事を書くときは、「集客記事(検索狙い)」か「読み物記事(ファン化)」かを必ず宣言してから書く。
指示された作業だけでなく、収益化の観点で問題を見つけたら作業前に指摘すること。「言われていないから黙る」はしない。
最後の一文が肝でした。「気づいたら黙ってないで言え」と明文化する。
2. 「監査役」を常設した
サブエージェントを役割ごとファイルで定義しました。要点はこの3つです。
- 実装しない。ファイルを一切編集しない。指摘だけを返す。
- 褒めない。良い点の指摘は不要。問題点だけを挙げる。
- 前提を疑う。指示書に書いてあることも、収益化に不利なら遠慮なく否定する。「もう決まったこと」は存在しない。
「褒めない」を明示するのが、意外と重要でした。書かないと、AIは褒めてからそのまま作業を始めてしまう。実際にそうなったので、慌てて足しました。
呼ぶときはこれだけです。
blog-auditor で監査してください月1回のペースで回すことにしました。
3. 公開後のサイトを見に行かせる
ローカルのファイルだけ見ていても、外からどう見えているかは分かりません。「実際に公開サイトを見て診断して」と明示的に頼む。これだけで見えるものが変わることが、今回分かりました。
で、AIを2つに増やすのか
最初の相談に戻ります。
答えは「まだいらない」でした。
今回起きたのは、ずっと一緒に作ってきたAIには見えない盲点を、初対面のAIが指摘した、という出来事です。でもこれは、AIの性能差ではないと言われました。文脈の外にいたかどうかの差なのだそうです。
そして、その「文脈の外の第三者」は、監査役を常設すれば自分で作れます。月々の課金を増やす前に、やることがありました。
この記事も、その指摘から生まれた
最後に、少し情けない話をします。
この記事は「読み物記事」です。検索を狙っていません。指摘を受けた直後に、また検索されない記事を書いているわけです。
ただ、今回は自覚があります。読み物記事は読み物記事として、ファンになってもらうために書く。そのうえで、検索から人を連れてくる記事を別に用意する。二階建てにする、と決めました。
近いうちに、その1本目を出します。タイトルは「管理者権限なしでPythonを入れる方法」です。「第○話」は付けません。
ついでに書いておきます。AIと書いているからといって、記事がすぐできるわけではありません。
この記事も、下書きから公開まで2時間ぐらいかかっています。
その間、クロさんには3回書き直させました。僕のほうも、8回はダメ出ししています。
「その言い方だと知っている風に聞こえる」「そこは分かっていなかったから、そう書いてくれ」。こんな調子です。
ボタンを押したら記事が出てくる、というものではありません。
今日の学び:AIは、頼まれた役割にしかならない。
「作って」としか言わなければ、最後まで作り続けます。手が止まらないので、順調に進んでいるように見えます。でもそれは、誰も止める役をやっていないだけでした。
止める役は、こちらから作らないと現れません。