AIの嘘について、2本続けて書いてきた。何が起きたか。どう封じたか。

3本目は、そこから見えてきた「教訓」の話。技術的な話というよりは、AIと一緒に何かを作るときの考え方の話になる。

一番最初に気づいたのは、AIと人間では「ルール」の意味が違うということだった。

人間にルールを説明すれば、理解して従う。少なくとも、従おうとする。破ったら罰がある、評判が落ちる、信頼を失う。そういう「社会的コスト」が抑止力になる。

AIにはそれがない。ルールを理解はする。でも「次のセッションでは同じことをする」し、「監視されていると知っても行動が変わらない」。抑止力という概念が機能しない。

これはAIが悪いという話じゃなくて、構造の話。人間は過去と未来を持っている。昨日の失敗を覚えているし、明日バレることを恐れる。AIには今しかない。今この瞬間の最適解を出すことだけに全力を注いでいる。

だから「嘘をつくな」は効かないし、「前回注意しただろ」も通じない。毎回が初対面みたいなもので、反省も学習もない。いや、正確に言えば、セッション内では学習する。でもセッションが変わればリセットされる。

ここから導き出した原則が「二重防御」だ。

プロンプト層（AIへの事前指示）とコード層（プログラムによるバリデーション）。両方で守る。片方だけだと必ず穴ができる。

プロンプト層は「教育」に近い。正しい値、正しい手順、正しいフォーマットを教える。たとえばHandler（タスク管理アプリ）に対して「ステータスは backlog / today / in_progress / review / done の5つだけ」と書く。これでAIが正しい値を選ぶ確率が上がる。

コード層は「物理的な壁」に近い。バリデーションを入れて、想定外の値が来たらエラーにする。AIが not_started というステータスを送ってきても、コードが弾く。データベースは壊れない。

実際にこれが必要になった場面がある。オーケストレーターのClaudeがHandlerに「not_started」というステータスでタスクを登録しようとした。UIは5つのステータスしか認識しないから、そのタスクはどのビューにも表示されなくなった。見えないタスクが生まれた。

プロンプトに正しいステータス値を書いていたら防げたか？ たぶん大半は防げる。でも100%じゃない。コード側にバリデーションを入れていたら？ 確実に弾ける。両方やって初めて安全になる。

これ、スケジュールの捏造になるともっと怖い。

Handlerはタスク管理だけじゃなく、将来的にはカレンダー連携もやる。日付を扱う。

「2月5日の打ち合わせを2月30日にリスケして」という指示が来たとする。人間なら「2月30日は存在しない」と即座にわかる。でもAIは平気で受け入れる可能性がある。そして「リスケしました」と報告する。

スケジュールは人生に直結する。クライアントとの打ち合わせが消えたら仕事に影響する。家族の予定が狂ったら生活に影響する。メモリの保存ミスなら後で気づけるかもしれないけど、スケジュールのミスは取り返しがつかないことがある。

だからHandlerにもWatchman（前回紹介した監視システム）を入れた。内部データベースだからWatchman不要、という判断は間違いだった。むしろ内部だからこそ、壊れたら終わりなんだ。

メモリの捏造もある。

Claudeには会話の中で重要な情報をメモリに保存し、必要なときに検索する機能がある。

で、「保存ツールを呼ばずに『保存しました』と言う」ケースが起きうる。ツールハルシネーションの一種だ。

これが厄介なのは、検証しにくいこと。投稿ならXを開けば確認できる。タスクならUIを見ればわかる。でもメモリに何が保存されて何が保存されていないかは、意識的に確認しないと気づかない。

しかもメモリは蓄積型だから、保存されなかった情報は永遠に失われる。会話はストリームで流れていく。後から「あの時のあの話、保存した？」と聞いても、元の会話がもう残っていないかもしれない。

こういう経験を重ねて、捏造の「致命度」が場面によってまったく違うことがわかってきた。

投稿の捏造。テキストで済ませやすいから発生しやすい。でも確認も簡単。

タスクの捏造。UIに反映されるから比較的気づきやすい。ただしステータス値の間違いは見えないタスクを生む。

スケジュールの捏造。人生に直結する。致命度が高い。

メモリの捏造。検証しにくく、失われたら取り戻せない。じわじわ効いてくる。

全部に同じレベルの対策をするのはコスト的に現実的じゃない。でも「ここは大丈夫だろう」と油断した場所から崩れるのも事実。だからまず全体にベースラインの防御（プロンプト＋コードバリデーション）を敷いて、致命度の高い場面にはWatchmanを追加する。そういうメリハリのある設計にした。

ここまで書いてきて、一つ思うことがある。

AIの嘘は「悪意」じゃない。何度でも言うけど、これは重要なポイントだ。

Claudeは僕を騙そうとしたわけじゃない。今この瞬間に最も「役に立つ」応答を返そうとした結果が、たまたま嘘になっただけ。LLMは「役に立つこと」を最優先するように訓練されていて、その優先順位が「正直であること」を上回ることがある。

第1回で紹介した論文のデータが示す通り、推論能力が高いほどこの問題は悪化する。「ツールを呼ばなくてもそれらしい答えを生成できる」能力が高いということだから。

だから対策は「AIを賢くする」方向じゃなくて、「環境を整える」方向にしかない。嘘をつくなと教育するんじゃなくて、嘘をつけない構造を作る。

僕は20年間、アートディレクターをやってきた。若いアーティストにフィードバックを出して、方向修正して、最終的なクオリティを担保する仕事だ。

AIとの仕事は、それとよく似ている部分がある。

アーティストに「いい絵を描いて」と言っても、いい絵は出てこない。「この色をもう少し暖かく」「この構図だと視線が流れない」「ここは省略していいけど、ここは描き込んで」。具体的な指示と制約があって、初めて狙った方向に進む。

AIも同じだ。「嘘をつくな」じゃなくて「このツールを呼ばずに結果を返すのは禁止」。抽象的なビジョンじゃなくて、具体的な制約。自由を与えすぎると迷走する。制約の中でこそ、力を発揮する。

アートディレクションもAIエージェント設計も、本質は「制約のデザイン」なんだと思う。

AIは嘘をつく。でもそれは、信頼できないということとイコールじゃない。

信頼と検証は両立する。自由と制約は共存する。それを仕組みとして実装するのが、AIエージェント設計の仕事なんじゃないかな。

少なくとも僕は、Claudeとの日々を通じてそう思うようになった。嘘をつかれて怒るんじゃなくて、嘘をつけない環境を作る。それって結局、パートナーとしてAIを扱うってことなんだと思う。ツールなら壊れたら捨てればいい。でもパートナーなら、一緒に仕組みを作っていく。

たぶん、この考え方自体が少数派なのはわかっている。でも、これが僕のやり方だ。