冴えカノのキャラクターをメタファーとした一連の記事は紅坂朱音編を持って完結ですが、最後にこの一連の記事を書こうと思った動機やAIに記事を書いてもらった舞台裏について書いて終わりにしたいと思います。いわば蛇足のあとがきです。
自分は冴えカノを見たのがこの記事を書くちょうど1ヶ月前が初めてで、LLMの特性を色々と調べている段階でした。元々が人の名前や特徴を覚えるのも苦手で頭の中で記号化することで問題解決をしていることもあり、アニメのキャラクターも記号化して見るという習慣が付いていました。そして学習中だったLLMと冴えカノのキャラクターたちの特性がどんどんリンクしていきました。
協力してゲームを作っていくというストーリーは LLMはその特性からくる欠点ゆえに複数エージェント構成こそが最適解ではないか? という当時の疑問と一致していきました。また、ギャルゲーを作るという部分もLLMはハイパーパラメータ調整を管理するフラグ管理ゲームであるという認識とも重なりました。
この発想を少しずつ記事にして、自分が考えるマルチエージェントとはどういうものかを書き残す手段について思い描いた時にAIに久々にQiitaで記事を書いてもらおうとなったわけです。
ですが、その道のりは決して平坦ではなくAIとの協業方法も変遷を重ねました。最終的に技術記事を書く際のコツは欧米式の論文形式で主張や結論を先に提供し、途中のセクションではそれを補強する根拠やアイデアを出す。最後に結論を更に強調するという発想をAIに落とし込んでいくことであるという結論に至りました。
今回は加藤恵編から安芸倫也編、氷堂美智流編、波島兄妹編、紅坂朱音編とAIとの協業方法の変遷を振り返っていこうと思います。
加藤恵編から安芸倫也編
この4記事はGeminiが自発的に調べてくれたおかげで、最後の安芸倫也編以外はスムーズに進みました。一方で安芸倫也編ではコンダクターという独自の発想をベースにしているためにAIの自発的な調査も難航したためかかなりの苦戦を強いられました。Deep Researchが書いた記事を読ませた別エージェントに対して、構成の変更や推敲をお願いすることでようやく出来上がったという意味では前半で最も苦労したのが安芸倫也編、一方で全く構想と違っていたものの出来上がってきた記事をほぼそのまま投稿したのが霞ヶ丘詩羽編でした。
これは記述的な根拠や一般論が多ければ多いほど、AIにとっては書きやすいという典型例と言えるでしょう。
-
プロセス
- LLMに対して理解していることをGeminiと確認作業の様にチャットを積み重ねる
- 掘り下げたいキャラクターとLLMの特性をAIに対して結び付ける様に誘導する
- ある程度、対話を重ねてイメージが固まった段階でDeep Research機能を用いて記事にしてもらう
-
メリット
- LLMや冴えカノ本編について自発的に調査をしてくれるおかげで根拠のある文章が出来てくる
- アウトラインを提供することなく、それなりの文章が上がってくるので修正作業だけで済むことが多い
-
デメリット
- Deep Researchを開始するとそのエージェントは使い捨てになってしまう
- 思っていた通りの記事が出来てこなかった場合の修正作業は構成からやり直しになってしまい、修正作業が大きくなりがち
- 自発的な調査を経て自分が詳しくない知識も混入することがあり、事実確認をしないといけないケースもしばしば
氷堂美智流編
教師データが揃っただろうという見込み発進をしたのが氷堂美智流編。
ここではGeminiがストーリーを把握していないという事実と情報量の少なさに悩まされました。触れたいエピソード自体が少ないにも関わらず、Geminiがそのエピソードについて全く知らない、もしくは一部だけなら知っている程度であり、虚偽の情報を散りばめてくるために出来上がった記事を何度も読んでおかしい点を指摘していく作業に追われました。
-
プロセス
- これまでの4記事が出来たことで教師データは揃ったと判断
- 以前の記事を読ませる
- コンテキストの寿命を氷堂美智流という主人公と生まれた時からの幼馴染という属性を結び付けて会話を重ねる
-
メリット
- 以前の4記事の書き方を踏襲させるのが容易だった
- エージェント内で完結できるので、Deep Researchの回数制限を気にしなくて良くなった
-
デメリット
- 前半の主要キャラたちと比べて情報量が少ない
- Deep Reserchでは気付かなかったがGeminiは細かなエピソードには詳しくない
- キャラクターの特徴や記事で触れておきたいエピソードを自分で用意する必要がある
羽島兄妹編
教師データとして投稿済みの記事を読ませるところから始めたのは同じですが、氷堂美智流編で苦労した点である、キャラクター・エピソードを把握していないという点を先回りして情報を集めてGeminiに食わせてから出海編ではGeminiと一緒にアウトラインを考え、伊織編では自らアウトラインを出して、これで記事を書いてという指示を出す形を取りました。
それぞれ、アウトラインにはある程度忠実で修正量自体は少ないものの導き出される結論に違和感があり重点的に結論を中心に修正を重ねたのが特徴的でした。特にAIにアウトラインを任せた出海編は顕著で自分の書きたい内容でなく、Geminiが書きたいものに改変されているという印象がありました。
ここからの3記事は同じエージェントで書かせたものである点がこれまでの記事とは大きく異なる点として挙げられます。
-
プロセス
- 以前の記事を読ませる
- キャラクターの特徴や盛り込みたいエピソードを把握させる
- アウトラインを固めて技術記事にしてもらう
-
メリット
- メタファーとして取り入れたい内容を先に把握させることで冴えカノ部分に関しては手戻りが少なかった
- アウトラインを明確に伝えることで8割程度満足いく状態からのスタートを切れた
-
デメリット
- アウトラインを一緒に考えると創造的な方向に傾くせいか、Geminiの独自の考えが発揮されやすくなる
- 結論が自分の思っていたものからキャラクターの特性から導き出したものに改変されてしまう
紅坂朱音編
ここまでの失敗を踏まえて、紅坂朱音編では羽島兄妹編でのプロセスに加えて全体の結論、各セクションでの主張を伝えたい内容としてアウトラインとして渡した上で記事にしてもらいました。結果としては結論に至るまでほぼ満足のいく形が出来上がってきましたが、波島兄妹編と比べると触れておきたいエピソードが多かった点から出来上がってくる内容に微妙に盛り込まれる嘘を少しずつ情報を追加することで対応する必要がありました。
-
プロセス
- キャラクターの特徴や盛り込みたいエピソードを把握させる
- 書きたい結論を共有する
- 結論と各セクションで主張したい内容までをアウトラインとして技術記事にしてもらう
-
メリット
- 結論がブレることがないので、細かな点に集中しやすかった
- 各セクションでも前半にメタファー、後半にオーケストレーターという構成にしたおかげでそれぞれのチェックの切り替えが楽になった
- 安芸倫也編で苦労した独自発想部分のオーケストレーターの役割についても2,3度の修正依頼で済んだ
-
デメリット
- 特にないが、紅坂朱音というキャラクターの情報提供については最初に与える情報が足りなかったという反省点が残る
まとめと結論
Geminiに記事を書いてもらう中で最終的に最も効率的だったのは、欧米式の論文の書き方を意識し、結論からAIに情報を共有することでした。 なぜこのアプローチが有効だったのかというと、AIの学習データが、結論を最初に提示する形式に慣れ親しんでいるからです。この形式は、AIが膨大な情報から最も重要な要素を抽出し、論理を再構築するという、最も得意なプロセスと非常に相性が良いのです。
この協業方法が特に事実確認や根拠が重要な技術記事に有効なのは、AIが一貫した認知的な思考を効率的に行えるからです。これは、ゼロから新しいアイデアを生み出す創造的なプロセスとは根本的に異なります。創造的な文章では、発想の飛躍や比喩といった論理的思考を超えた要素が不可欠となりますが、それはAIが今まだ得意とする分野ではありません。しかし、既に結論が決まっている技術記事では、AIは結論に向けて情報を収束させるという、単一で一貫した認知的なプロセスに集中できるため、より効率的に高品質な文章を生み出せるのです。
一連の記事は技術記事でありながらも冴えカノというアニメのキャラクターたちをメタファーとする一方で論理的な思考をさせつつももう一方では比喩表現という創造的な思考をさせなければならないというジレンマを抱えさせていました。この点がGeminiにとっては虚構を作り出しやすい状況を与えることもあり、最後の最後になったものの最初から結論やアウトラインを提供することで補強という一点に集中させたことは成功だったと感じています。
あとがきのあとがき
あとがきのあとがき、つまりは蛇足の蛇足です。
冴えカノ、名前だけは知っていたんですが本当に面白い作品でした。推しのキャラクターは霞詩子の担当編集でもある町田苑子です。
なので、この記事は幻の エンジニアのための「冴えない」編集術ー町田苑子に学ぶAIに記事を書いてもらう 編ということで全国82億の町田苑子ファンの皆様にはご査収頂きたく。
Fine
エンジニアのための「冴えない」xxxx術リンク
- エンジニアのための「冴えない」プロンプト術 ― 加藤恵から学ぶ、再現性という名の"正義"
- エンジニアのための「冴えない」プロンプト術 ― 澤村・スペンサー・英梨々から学ぶ、"高体温"モデルの不確実性の乗り越え方
- エンジニアのための「冴えない」プロンプト術 ― 霞ヶ丘詩羽から学ぶハルシネーションの構造と制御
- エンジニアのための「冴えない」コンテキスト術 ― 安芸倫也の失敗から学ぶLLMとの協業
- エンジニアのための「冴えない」コンテキスト術 ― 氷堂美智留から学ぶ、長寿命なコンテキストの非力さ
- エンジニアのための「冴えない」プロンプト術 ― 波島伊織から学ぶ、同人ゴロの冷徹なプロンプト術
- エンジニアのための「冴えない」コンテキスト術 ― 波島出海から学ぶ、モデルの違い
- エンジニアのための「冴えない」コンテキスト術 ― 紅坂朱音から学ぶ、マルチエージェントシステムの支配者