生成AIを実務に組み込み始めたとき、
私が直面したのは「使い方」ではなく、
思考が拡散し続けること
でした。
このブログはノウハウ集ではありません。
私自身の実務ログです。
ただし、
という状態に陥っている人がいるなら、
参考になるかもしれないと思い公開しています。
ここでいう迷走とは、
生成AIとの対話が増えすぎて、
目的・現在地・論点が見えなくなる現象です。
これは特定の業務に限りません。
マーケティング設計でも、業務フロー整理でも、
同じことが起きます。
今回は一例として、
SEO記事設計に取り組んだときのケースを扱います。
人間との対話で微調整していた記事制作を、
条件入力型で再現可能にする
設計に挑戦しました。
しかし条件が増えるほど、
という問題が発生。
これは生成AIの性質上、自然に起きます。
生成AIは
からです。
そこで大量の壁打ちを繰り返しました。
結果、
が発生。
本当に困っていたのは、
会話が拡散し制御不能になること
でした。
ここが核心です。
人間の会議でも、
なら議論は拡散します。
生成AIも同じです。
対話は放っておけば拡張します。
拡張は自然に起きます。
しかし、
収束は自然には起きません。
収束は設計しなければ生まれません。
アーキテクト視点で見ると、
収束には最低限3つが必要です。
今回はこのうち、
停止設計に焦点を当てます。
スレッド冒頭で、次のルールを宣言しました。
以降、私が「#整理」と打ったら、
以下の7項目で現在の状況を出力してください。
#整理
1. 現在地
2. ゴール
3. 採用仮説
4. 捨てた仮説
5. 未確定論点
6. 次の一手
7. 停止判断
LLMは自律タイマーを持ちません。
だからこそ、
ユーザー起点で止める設計
が必要でした。
#整理 により、
まず
現在地とゴールが常に可視化された。
だから、
会話のボリュームが適正化された。
結果として、
さらに、
迷走の兆候を検知できるようになった。
だから、
本来あるべきゴールに戻せるようになった。
単に整理できたのではなく、
制御可能な状態になった
のです。
生成AIの迷走は能力不足ではありません。
設計不足です。
拡張は自然に起きる。
収束は設計しなければ起きない。
#整理 は、
収束を人工的に作るための最小単位でした。
私は、生成AIを実務に組み込む際の
構造設計と運用設計を扱っています。
このブログはその検証ログです。
次回は、
を整理します。