Error Log: なぜ、あなたの「訴え」はシステムに弾かれるのか（Type Mismatch）
FactSort Lab. | System Architect です。
System Status: Analyzing...
「話が噛み合わない」「冷たくあしらわれた」。役所でも、企業でも、弁護士でも、入口でこれが起きることがあります。
ここで言いたいのは、相手が性格的に冷たい、という話ではありません。もちろん、そういう人もいます。でも、あなたが感じた冷たさの相当部分は、もっと機械的な理由で説明できます。
それは、データ型の不一致（Type Mismatch）です。
当事者の側には現実があります。痛みも、怖さも、怒りも、疲れも。
ただ、その現実が「処理できる形式」に変換されないまま投入されると、システムは動けません。動けないとき、システムは決まって同じ顔をします。「要件が足りません」「具体的に」「証拠はありますか」。
つまり、エラーです。
今日は、そのエラーを、ソースコードの思想——「創造性ゼロ（zero creativity）」、「決定論的（strictly from JSON）」——を比喩として借りながら、入口の仕組みとして説明します。第３回で扱う「推論の連鎖」に接続するための、前段の話です。
1. バグの特定：Type Mismatch（なぜ弾かれるのか）
入口で起きていることは単純です。
多くのユーザーは、次の形式でデータを送信（Input）しようとします。
Input: 「あいつが許せない」「すごく辛い」「信じられない」
Data Type: Unstructured String（非構造化テキスト／感情）
これは決して「間違い」ではありません。人間の出力として自然です。
ただ、レガシーシステム（司法・行政・企業窓口）が要求しているスキーマは別です。
Required: Timestamp（日時）, Location（場所）, Action（行為）, Evidence_ID（証拠）
Data Type: Structured Object（構造化データ／事実）
プログラムで、数値を要求するフィールドに文字列を入れてしまうと例外が投げられますが、これと同じです。
「つらい」は真実でも、Timestampの代わりにはなりません。
「許せない」は正当でも、Evidence_IDの代わりにはなりません。
ここで起きる「門前払い」の正体は、人格否定などではなく、入力の型が合っていないことによるRejectです。
もう少し具体的に言うと、入口の担当者が頭の中で（あるいは書面の形式として）やっているのは、だいたいこんな感じです。
いつの話ですか（日時がない）
どこですか（場所がない）
誰が何をしましたか（行為が特定されていない）
それは何で確認できますか（記録がない）
この質問が多いとき、あなたの話が薄いのではありません。データが未整形なのです。
2. 司法や行政のシステムは「決定論的（Deterministic）」であることを求める（創造性を嫌う）
なぜ、彼らは感情を読み取らないのか。
冷たいから、ではありません。制度として、入力に対して一意の出力を返すこと（決定論性）が求められているからです。
決定論的（Deterministic）というのは、ざっくり言えばこうです。
入力A（事実のセット）が同じなら、
出力B（手続上の扱い・判断の方向）が大きくブレないようにする
これは「正しさ」以前に、「公平」と「説明可能性」のための要求です。
担当者が気分で変えたら困るし、前例と整合しないと困るし、後で説明できないと困る。だから、入力はできるだけ固定された形式に寄せたい。
行政が「前例」を大切にし、裁判所が「裁判例」を大切にする理由でもあります。
個別の事例にどれほど感情的で耐え難いものがあったとしても、結果はいつも大体同じ。
ですから、ここに「感情」という揺らぎ（Creativity）が混入すると、システムはバグを起こしてしまいます。
同じ出来事でも、怒りの強さや語り口で印象が変わる。印象で結果が揺れるなんてことになると、制度は壊れてしまいます。
つまり、自己防衛として、感情データはフィルタリング（無視・後回し・参考扱い）されやすい。これは残酷ですが、仕様としては筋が通っています。
この説明のポイントは一つです。
「読んでいない」のではなく、「処理の本流には載せられない」ということです。
3. 「推論の連鎖（Chain of Inferences）」の前提：固定された“足場”の必要性
第３回では、証拠から事実を組み立て、そこから結論に向かう「推論の連鎖」を扱う予定です。
その連鎖が成立するためには、まず“固定された足場”が必要です。
足場とは「ノード」です。
ノード（node）は、ネットワーク図の「点」であり、技術っぽく言うと、推論の連鎖は「点（ノード）」と「線（関係）」でできています。
点（ノード）＝後で参照できる確かな材料
線（関係）＝「この材料から、こう言える」というつながり
法や手続の世界で、点（ノード）になりやすいのは次のようなものです。
記録（メール、チャット、録音、写真、診断書、日報、入退室ログなど）
具体情報（日時、場所、当事者、発言の文言、媒体、同席者）
逆に、点（ノード）になりにくいのが感情や昔話です。
「怖かった」「屈辱だった」「許せない」
「何年か前に、どこだったかな、あいつに殴られたんだよ」（昔々、あるところに…というのと変わりません。）
これらは当事者には重要ですが、第三者が同じ形で観測しづらい。記録にも残りにくい（残ってない）。すると、点（ノード）として固定できない。
推論の連鎖は、まず点が必要です。点がなければ線を張れない。
だから入口は、感情より先に「点になれるもの」を要求する。これが、Type Mismatchが起きる構造です。
4. デバッグの手順：相手の仕様を変えず、入力をリファクタリングする
相手（システム）の仕様を変えようとするのは、ほとんどの場合コストが極めて高いものです（というより不可能）。
ハックする方法は一つ。こちらの入力データを、システム互換の形式にリファクタリング（整形）することです。
「通る入力」は、だいたい次の形です。
Timestamp：いつ（例：2026/01/12 14:30頃、少なくとも日付）
Location：どこで（例：会議室A／Slack／メール／Zoom）
Action：誰が何をしたか（例：上司Xが「無能だ」と発言）
Evidence：何で確認できるか（例：E01=メール、E02=チャットスクショ、E03=同席者メモ）
そして、ここがポイントです。
あなたの脳内にあるカオスな出来事を、そのまま時系列に並べるだけでは、処理しづらいことがあります。そこで、次の段階として「柱（Pillar）」でまとめることを試みています。
Pillar（主張の柱）＝出来事を束ねる“分類ラベル”
例：厳しい業務指導、侮辱発言、隔離、評価の不利益、等
※これは法的評価ではなく、事実を整理するための「検討単位」として束ねるために作り出したラベルです。
Pillarで整理すると、後の推論がやりやすくなります。
なぜなら、推論の連鎖は、「材料が多いほど強い」のではなく、「材料が論点ごとにまとまっているほど強い」からです。
5. あなたの感情は“ノイズ”ではなく、優先度の高いアラート
誤解されたくないのですが、感情を排除しろ、と言っているわけではありません。
感情は、現実の圧力であり活力です。むしろ、感情があるから「何かが起きた」と分かる。
でも、入口の処理系にとって、感情は「アラート（異常検知）」であって、「証拠型データ」ではない。
アラートが鳴ったなら、次にやるべきことはログ採取です。これは冷たい話に聞こえますが、これによって現実が動き出します。
6. 型変換を自動化する
あなたの出来事を、Pillarごとに整理し、構造化データへ変換する。
そのための「パッチ（修正ツール）」は以下の内容を持っています。
創造性は一切入れない（生成AIに創造させず、ハルシネーションを回避）。
入力されたデータ（JSON）から、決定論的に（strictly from JSON）、同じ入力なら同じ出力になる形で文書化します。
これは“作文”ではなく、ログ整形です。入口を通すための互換レイヤなのです。
今回は、推論の連鎖の前提について記載しました。
「点（ノード）」を固定し、論点（Pillar）ごとに束ね、線（関係）を張れる状態にする。
次回は、その点と点をどうつないでいくのか、どこで連鎖が切れやすいのか、切れないために何を残すべきか——その話に入ります。