第1回で書いたように、idash（アイダッシュ）を作るときに最初に決めたのは「AIに判断させない」ということでした。何が重要かを選ばせない。百件のうち重要な五件を拾わせる、という機能は、設計の段階ではっきり不採用にしています。
一方で、秘書には記憶を持っていてほしいのです。毎回こちらがゼロから説明し直すのなら、自分専用にする意味がありません。ここで正面からぶつかります。記憶を持たせるというのは、要するに「何を覚えるか」を誰かが決めるということです。それをAIにやらせた瞬間、最初の原則が崩れます。
今回は、その両立をどうやったかという話です。
役割を三つに割った
やったことを先に書くと、記憶が確定するまでの工程を三つに割りました。
AIがやるのは、会話の中から「この人はこう言っている」という主張を取り出し、それが既にある記憶の項目と同じことを言っているのか、それとも新しい項目なのかを判定するところまでです。言葉の意味を読む仕事なので、ここはAIにしかできません。
次に、決まりきったプログラム（毎回同じ手順しか踏まないコード）がやるのは、数えることと、閾値と比べることと、候補の一覧に上げることです。ここには解釈が入りません。同じ入力を与えれば必ず同じ結果が出ます。
最後に、人間がやるのは承認だけです。
この工程を通して、AIは一度も「これは確定記憶だ」と判定しません。 抽出はします。同じか違うかの判定もします。けれど、それが記憶として残るかどうかには触らせません。ここが、この仕組みでいちばん守りたかった線でした。
証拠の種類で、必要な回数を変える
候補に上がるまでに何回の観測が要るかは、その情報がどこから来たかで変えてあります。
本人がはっきり述べたこと、あるいは訂正したこと——「覚えておいて」「違う、そうじゃない」——は、1回で候補になります。本人の発言から直接分かる事実、たとえば役割や人との関係、いま進行中の案件は2回。観測から推論した傾向や癖は3回です。
分けた理由は単純で、こちらが「覚えておいて」と言ったことと、AIが会話を見て勝手にそう思ったことを、同じ重みで扱いたくなかったからです。同じ一つの項目に複数の種類の証拠が集まったときは、いちばん緩い基準を採ります。明示的な申告が一度でもあれば、推論の回数がゼロでも候補に上がります。
癖のほうは一律で3回にしてあります。
数え方に、思想が入っている
回数の数え方のところに、この仕組みの考え方がいちばん出ていると思っています。
まず、同じ会話の中で何度繰り返されても1回として数えます。一度の長い語りの中で同じ話を三回したからといって、それは三回観測されたことにはしません。1回の熱のこもった語りが「何度も言っていた」に化けるのを防ぐための決まりです。
そのうえで、日付が異なることを条件にしています。数えているのは観測の件数ではなく、その主張が現れた日の数です。別の日に、別の文脈で、また同じことを言った、というケースです。時間をまたいで再現したものだけを「癖」と呼ぶ、という判断です。
その日たまたま言っただけのことは、癖ではありません。自分の実感としてもそうで、一日の中の気分で言ったことが自分の傾向として記録に残るのは、正直なところ気味が悪いです。
「違う」と言われても、カウンタは減らさない
反対の観測が来たときの扱いも、少し変わっています。
ある主張に対して「いや、それは違う」という観測が入ったとき、カウンタを減算しません。代わりに「矛盾あり」という印を立てるだけにしてあります。減らしてしまうと、支持と反証が打ち消し合って、どちらも起きなかったことになってしまいます。実際には両方起きているので、両方残したいわけです。
癖のほうだけは、反証が2回に達したら「保留」に格下げします。ただし、行そのものは削除しません。かつてそう見えていたという事実ごと、消さずに残しておきます。
記憶は、人間が読める場所に置く
記憶をデータベースの中に隠さない、というのも最初に決めた方針のひとつです。中身を覗くのに専用の道具が要る場所に置くと、自分でも何が入っているのか分からなくなります。
なので、確定した記憶はMarkdownのファイルとして保存しています。1行はこういう形をしています。
- [確定 2026-09-06] （内容がここに入る） ^mem-58840114
<!-- key: 主語/述語 -->
<!-- src: どこから来たか -->key は重複判定のための見出しで、同じことを二重に覚えないための唯一の根拠です。src はその情報がどこから来たかを書く欄で、こちらは必須にしてあります。どこから来たかを書けない情報は、そもそも書き込まないという決まりです。
ふつうのテキストファイルなので、人間が開いて読めますし、変更があれば差分として見えます。記憶が勝手に変わっていたときに、どこがどう変わったか分かる状態を保っておきたかったのです。
カウンタは、承認の代わりではない
最後にもう一つ。閾値を超えても、自動では確定しません。
超えたものは承認待ちの一覧に並びます。人間がその行のチェックを付けて、反映のコマンドを実行して、初めて記憶のファイルに書き込まれます。カウンタの役割は、人間の目に触れる候補の数を減らすフィルタであって、人間の代わりに判断するものではありません。
ここを曖昧にすると、「三回言ったんだから確定でいいだろう」という方向に自然と流れます。実際、作っている最中に何度かそう思いました。そのたびに、第1回で決めた一行に戻って踏みとどまっています。
—
ここまで、我ながら丁寧に作りました。証拠の種類を三つに分け、数え方に条件を付け、反証の扱いを決め、承認の経路まで用意しました。設計としては、いま読み返しても間違っていないと思います。
ただ、この仕組みは実際にはほとんど動きませんでした。二週間動かして、観測の台帳に溜まった行は全部で3行です。承認待ちの一覧に至っては、一度も作られたことがありません。ディレクトリごと存在していません。
原因は、抽出の精度でも、閾値の設定でもありませんでした。もっと手前の、単純な場所に問題がありました。次回は、いちばん複雑に作ったこの仕組みが、なぜ空回りし続けたのかを書きます。
コメント