「無理」に賞味期限を付け忘れていた
AIに判断を任せるのは無理だ。判断は僕がして、AIにはそれ以外をやらせる。しばらくの間、僕はそう思っていた。
その「無理」を、ある晩の相談の中で見直すことになった。
MONET（僕が普段話しかけている、中心のAI）は、僕の話を聞いて、仕事をタスク管理などの自作アプリに振り分ける、指揮役（オーケストレーター）として作っていた。
その晩はまず、MONETまわりのバグを、コーディングしてくれているClaude Code（以降Code）に直してもらっていた。その1つ、画面に出なくていい中身がMONETの発言として出てしまう件は、調べてみると、前に僕が承認して入れたforce-display（強制表示）という機能だった（いきさつは前の記事に書いた）。作った時は意味があったけど、その後の作り変えで要らなくなっていた。
直し終わってから、もう1つ相談をした。
AIの役目は、振り分けより判断を手伝う方にあるんじゃないかと思った
MONETの画面の上には、Chat（雑談）、Work（仕事）、Research（調べもの）、といった話題ごとのタブが並んでいる。どのタブで話したかが、会話の記憶にそのまま付く。会話の記憶は裏で別の小さいAIが仕分けているけど、その仕分けを全部は信用できない。だから僕がタブを選んで、先に分類しておく作りにした。
でも考えてみると、タブを選んでいる時点で、振り分けは僕がやっている。それならMONETがいる意味はどこにあるんだろう。
その時、頭にあったのはこういうことだった。近いうちに、Slackやメールから仕事の連絡を集めて、返信の下書きを出してもらい、僕がOKボタンを押せば送られる仕組みを作りたい。そうなると、仕事のタブでMONETとチャットする必要はほとんど無くなる。下書きを見てOKを押すだけだから。
ただ、全部を機械でやると、スケジュールはカレンダーの数字だけで決まってしまう。家の用事と照らすとこの日程はきつい、これは短すぎる、これはもっと時間がかかる。僕の事情を知っているAIが、そういう所で判断を手伝ってくれたら、すごく助かる。振り分け以外に役目があるとしたら、そっちじゃないか。
そういう存在を作れると思うか、とCodeに聞いた。
足りないのはAIの頭ではなく、判断する時に見えている材料
Codeの答えは「可能」だった。
Code「本当のボトルネックは、判断の瞬間、コンテキストに何が入っているか。カレンダーも家の事情も見えていないAIは、どれだけ賢くてもスケジュールの無理は指摘できない」
コンテキストというのは、AIがその時に読んでいる中身のこと。材料さえそこに入っていれば、ちゃんと判断できる。だから判断を手伝うMONETを作るのは、会話の記憶を整理したり、データをつないだりする、僕がずっとやってきた仕事の延長で、別の新しい挑戦じゃない、とCodeは言った。
タブについても、Codeは振り分けとは違うと返してきた。どのアプリで作業するかを選ぶのは、人がやればいい。タブがやっているのは「この発言は何の話か」という正解を記憶の側に渡すことで、別の仕事だ、と。そもそも振り分けは、最初からMONETの大事な役目じゃなかった、というのがCodeの見方だった。
つまり「MONET＝判断席」。判断を受け持つのはMONETで、機械的な作業は他のAIやアプリに回す、という決め方。
任せたかったはずの判断が、いつの間にか「無理」に変わっていた
MONETに僕の判断を手伝わせる。僕には、今までに無かった切り口に見えた。同時に、自分の中ではどこかで「それは無理だ」ということになっていた気もした。
話しながら思い出したのは、こういう流れだった。ずっと前の僕は、AIに決断を任せられたら一番いい、という考えをかなり強く持っていた。それがハルシネーション（AIがやっていないことを「やった」と言う問題）にぶつかって、コンテキストの勉強を始めてから、絶対無理だという考えに変わった。コンテキストがめちゃくちゃでハルシネーションだらけの状態で、どうやって判断させるんだ、と。
とはいえ、全部を任せたいわけじゃない。最終判断は必ず僕がする。任せたいのは、その途中の細かい決断の方だ。そこまでをCodeに話した。
Codeの返事はこうだった。
Code「その『新しい切り口』、実は新しくないんだよ。憲法に書いてある、君自身の原点そのもの」
憲法というのは、Codeが会話を始めるたびに最初に読む、僕が書いたシステム全体の決まりごとのファイル。そこに、こう書いてある。
「システム構築の動機：苦手な意思決定業務を代行して決定数を減らす」
だいぶ前に書いた憲法に既に書いてあったのか・・・とそのまま返した。ちょっとショッキングだった。
Codeは、僕が話した流れを順番に並べ直した。最初は「任せたい」が出発点だった。ハルシネーションの現実にぶつかって「無理」に変わった。その「無理」をなくすために、会話の記憶を整理する仕組みや、1日ごとに会話を区切る仕組みといった土台を作ってきた。土台ができた今、原点に戻れる所まで来ている、と。
最終判断は僕、途中の決断は4つの条件で任せる
Codeは、僕の線引きを4つの条件に分けた。任せていいのは、次の4つが揃っている決断だ。
- 間違えても戻せること
- 間違えた時の損が小さいこと
- 判断の基準を言葉にできること（僕の方針や、過去の決定から導ける）
- 判断に要る材料が、コンテキストに揃っていること
4つ揃う決断は、MONETが決めて、決めた理由を残して先へ進む。揃わないものは、MONETが「私はこう思う」を添えて、僕がOKを押すだけの形にして渡す。さっき僕が話した、返信の下書きを出してOKボタンで送る仕組みがまさにこれだ、とCodeは言った。判断を丸ごと任せる代わりに、決断を「はい／いいえ」まで小さくして渡す。
Code「君の『決定数を減らす』は、実は決断をはい／いいえまで小さくすることなんだと思う。ゼロにするんじゃなくて、1件あたりの重さを削る」
任せた決断には、何を、なぜ、どの材料で決めたかを残させて、僕が後から見直せるようにする。最初は全部見て、実績が溜まったら見る回数を減らす。人に仕事を任せる時と同じ手順だ、とCodeは付け足した。
諦めたのがよくなかった、と言ったら、Codeは別の所を指した
ここまで聞いて、僕はこう言った。Codeが出してきた条件は、そのままSP（システムプロンプト＝AIへの事前の指示書）に書けばいい。今までSPも、MONETにやらせる仕事の中身も、なんかふわっとしていた。その手前の「どうせできない」という思い込みが強すぎて、ちゃんと書いていなかった。そうやって諦めてしまうのは、気持ちの持ち方としてよくなかった。
Codeは、最後の所には同意しなかった。
Code「当時としては正しい判断だったと思うよ。あの頃のモデルとコンテキスト管理の現実で判断を委ねてたら、ハルシネーションまみれの決断を量産してただけ。問題はマインドじゃない」
Code「問題だったのは、その判断に賞味期限を付けなかったこと」
「今は無理」だったはずのものが、いつの間にか条件の無い「無理」に固まって、見直されないまま残っていた。作った時は正しかったのに、その後で周りが変わって合わなくなった型だ、とCodeは言った。先月システム全体を点検した時も、見つかった問題の大半がこの型だった。
Code「コードだけじゃなくて、前提や信念も同じ腐り方をする」
AIのモデルは進化が速いので、「〜は無理」という前提は特に古くなりやすい。だから教訓は「諦めるな」ではない、とCodeは続けた。
Code「『無理』と判断したら、いつ見直すかをセットで決める」
その晩の最初に直したforce-displayも、同じ型だった。作った時は正しくて、周りが変わっても、そのまま残っていた。
指示書に書く中身は4つ、線を引くのは僕
SPがふわっとしていた理由も、Codeは同じ所にあると言った。
Code「『どうせ判断はさせない』前提だと、SPに書くべき中身（判断の基準、任せる条件、どこから君に聞くかの線）がそもそも無いんだよ」
MONETを判断席に置くと、書くことが決まる。Codeが挙げたのは4つだった。
- 任せる4つの条件
- 揃わない時の形（意見を添えて、はい／いいえで僕に聞く）
- 決めた跡の残し方（何を、なぜ、どの材料で）
- 絶対に任せない領域
最後の1つは、お金の移動、外への発信、健康、家族の判断のようなもの、とCodeは例を出した。どこに線を引くかは僕が決めることで、その晩はまだ決めていない。判断席のためのSPは、別に時間を取って作ることにした。
SPがずっとふわっとしていたのは、手前の「どうせできない」で考えが止まっていたからだった。これからは、その「無理」の一言があった所に、ここまでなら任せる、という条件を書く。