「発言601件」と表示する寸前で手が止まった——数え方ひとつで、道具は人を誤解させる

2026年9月14日

愛知の国会議員45人が国会で何を質問したかを引ける道具を作り、公開しました。作りながら一番時間を使ったのは、データの取得でも画面でもなく、「何を1件として数えるか」でした。

デモ: https://xb4g.com/giin/?ref=vwork-giin
買い切り版: https://kappstore.exbridge.jp/app.php?id=dd868beae043026b&ref=vwork-giin

手が止まった画面

国会会議録検索システムから45人分の発言を取り込み、「最近の発言」を並べたところ、こういう文字列が並びました。

御異議ないと認めます。よって、そのように決定いたしました。
次に、○○君。
本日は、これにて散会いたします。

数えると、収録した発言の 約30%が120文字未満。その多くが委員長としての議事進行でした。

議員ごとに内訳を出したら、もっと具合が悪いことが分かりました。

	全発言	議員としての質疑	答弁	議事整理
A議員	601件	5件	0件	596件
B議員	542件	14件	131件	397件
C議員	451件	29件	33件	389件

「発言601件」とだけ出していたら、読んだ人は「よく質問している議員だ」と受け取ったはずです。実際には委員長という役職に就いているから件数が多いだけで、その人は何も悪くありません。悪いのは、分けずに数えた画面のほうです。

集計は、事実の顔をして解釈を混ぜてくる

ここが今回いちばんの学びでした。

生データを出すだけなら、解釈は読む人のものです。ところが集計した瞬間に、集計の設計者の解釈が数字に混ざります。しかも数字は解釈に見えないので、読む人はそれを事実として受け取ります。

「発言601件」は嘘ではありません。会議録に601件あるのは事実です。それでも、読んだ人が受け取る意味は間違っています。嘘をついていないのに誤解させるというのが、集計のいちばん危ないところでした。

業務システムでも同じ構図はあります。

「対応件数」に自動返信を混ぜる
「稼働率」に待機時間を含めるかどうか
「解約率」の分母を契約数にするか稼働アカウント数にするか

どれも嘘ではないのに、混ぜ方ひとつで意思決定が変わります。AIに作らせるとき、この手の判断は勝手に埋められます。 言われていないから考えない、のではなく、もっともらしい定義を自分で決めて進んでしまいます。指示した側が中身を見ないと、気づけません。

どう直したか

発言の冒頭には必ず話者の表記があります。

○○○○○委員          → 議員としての質疑
○副大臣（○○○○君）  → 大臣等としての答弁
○○○○○委員長        → 委員長としての議事整理

ここを見れば機械的に分けられます。LLMは要りません。45人分を分類した結果です。

議員としての質疑 6,886件
議事整理 2,508件
答弁 927件

画面は既定で質疑だけを出し、タブで切り替えられるようにしました。各ページに「数えているのは議員として質問・討論した発言だけです」と理由つきで書いています。

「なぜこの人が入っているのか」に一言で答えられるか

もうひとつ設計で迷ったのが、誰を収録するかでした。

党派で選べば応援サイトになります。住所で選ぼうとすると人によって判断が割れます。結局こうしました。

「愛知の有権者だけが投票用紙に書ける候補」

衆議院愛知1区〜16区（16人）
衆議院比例代表東海ブロック（21人）
参議院愛知県選挙区（8人）

参議院の比例代表は全国共通なので入れません。この線なら恣意的な取捨選択がなく、「なぜこの人が入っていて、あの人が入っていないのか」に一言で答えられます。結果は自民24・国民民主8・中道改革連合4・参政3・立憲2・維新／公明／チームみらい／無所属が各1でした。

収録範囲の定義は、説明できる一文で書けるかどうかで選ぶ——これは他の案件でも使える基準だと思っています。

制約が設計を良くした例

「ことがらの最近のニュースも出したい」と考え、NHKなどのRSSを見にいったところ、提供ページにこう書いてありました。

提供するRSSは個人の方の利用のためのみに使用することができます。ブログやプログラム等によって、商業目的での利用を含め再配信や再提供を許可するものではありません。

当社は商用サイトを運営しているので対象外です。Yahoo!も新聞社も同様でした。

そこで、商用利用が明文で許されているものだけに絞りました。

源	件数	条件
国会の議案	242	MIT
省庁の報道発表（6省庁）	235	公共データ利用規約 PDL1.0

議案データには提出者の議員名が入っていたので、45人と突き合わせられました。議員ページに「提出した議案」が出せるようになり、発言だけでは見えない活動が拾えます。一般ニュースを諦めたことで、かえって道具の筋が通りました。

作りの話

PHP 8 と SQLite だけです。常駐プロセスもポートもDBサーバーも要りません。LLMも使っていません（分類も割り当ても機械的な判定なので）。運用費がかかりません。

Claude Code から引けるように MCP も同梱しました。ただし読み取り専用で、要約はしません。抜粋と会議録URLを返し、まとめるかどうかは呼び出し側に任せています。ここで要約すると、誤りが一次情報から切り離されて独り歩きするからです。

毎日の更新も仕組みにしました。発言の増分を取り、分類し直し、議案と報道発表を取り、サーバーへ配って、最後に公開ページを実際に叩いて件数が一致するか確かめます。公開側で確認できたときだけ成功とします。手元のデータが新しくなっても、見ている人には何も変わっていないからです。

この道具がしないこと

要約しない（機械的な抜粋だけ）
論評しない
賛成・反対を判定しない
議員に順位をつけない
候補者を扱わない（現職のみ）

政治の情報に限らず、人の評価に使われうる道具は、正しさより先に「間違えたときに誰が傷つくか」で設計が決まります。AIに要約させれば見栄えは良くなりますが、要約が間違ったとき傷つくのは本人で、しかも要約文のほうが一次情報より速く広まります。