技術的負債という言葉を、エンジニアなら誰でも知っている。 「後で直そう」と思って書いたコードが、何年も直されないまま積み重なり、 気づけば誰も全体を理解できなくなっている状態のことだ。

社会の制度も、実はこれと同じ構造をしている。 昔、何かしらの理由で作られたルールが、その理由が消えたあとも 「昔からそうだから」という理由だけで生き残っている。 これは、バージョン管理もテストもないまま何十年と動き続けているレガシーシステムに、かなり近い。

- // 理由: 当時の事情により制定（詳細不明） + // TODO: 現在の前提を検証する function shouldWeStillDoThis() { return "昔からそうだから"; // ← これは仕様ではない }

「昔からそうだから」は、コードレビューでは通らない。 なぜなら、それは理由ではなく、理由がないことの言い換えだからだ。 同じ厳しさを、私たちは循環複雑度が高まった社会のルールにも向ける必要がある。

アンチパターンを共有することから、次の挑戦は始まる。

失敗したプロジェクトのふりかえり(ポストモーテム)を書いたことがある人は多いはずだ。 失敗そのものは恥ずかしいことではない。恥ずかしいのは、それを共有せずに、 次の人がまったく同じ失敗を繰り返すことだ。

政策の歴史や業界の歴史も、実は膨大なポストモーテムの蓄積である。 ただし、多くの場合それはきちんとドキュメント化されていない。 「なぜあの規制はうまくいかなかったのか」を、感情ではなくアンチパターンとして 淡々と計測していく作業。これはエンジニアが一番得意なことのひとつだと思う。

バグを放置しないエンジニアが、社会のバグを放置する必要はない。

本番環境でバグに気づいたら、私たちは見なかったことにはしない。 チケットを切り、原因を調べ、再発防止まで考える。それが仕事の誠実さだと思っているからだ。

同じ誠実さを、社会に対しても持っていていいはずだ。 「なにか怪しい」と感じたルールを、ただの愚痴で終わらせず、 イシューを切るように、静かに手順化してみる。バグの検証は地味なものだ。

ISSUE

良い規制と悪い規制の違いを、感覚ではなく定量的に評価し、ユーザーである国民が生きる現実をドメインとして理解し制度を設計できる人は少ない。
→ まずドメインを理解し、モデル化し、誰でも検証できる再現手順を用意する必要がある。

制度はコードではない。だが、デバッグはできる。

制度は、実行できるプログラム空間としては大きくすぎる。だから「動かして確かめる」ことは簡単ではないし、 シュミレーション環境も存在しない。それでも、デバッグという思考の型自体は応用できる。

何が起きているかを観察する。仮説を立てる。範囲を絞り込む。証拠を集める。 直したつもりで終わらせず、本当に直ったかテストコードで確認する。 この地味な手順の積み重ねこそが、私たちが日々鍛えている筋肉であり、 マクロな政策分析にも応用ができる。

科学が始め、オープンソースが加速した。
公開した知識は強くなる。

オープンソースの世界では、コードを隠すより公開したほうが、結果的に品質が上がることを 何十年もかけて証明してきた。誰でも読める、誰でもIssueを立てられる、 誰でもPull Requestを送れる。この透明性と自由度が、巨大なソフトウェアを支えている。

Pull Requestのない社会を、どうアップデートするか。

一方で現実の社会の制度には、Pull Requestの仕組みがない。変更を提案する場所も、 レビューする文化も、あまり整っていない。だからといって「Forkできないから諦める」のではなく、 Forkできない前提のうえで、それでも少しずつ分析していくためのブレイクポイントを探すしかない。 これは地味で知的な作業を嫌がらないエンジニアにこそ向いている。

社会制度にもIssueを立てよう。

Issueを立てるという行為は、とても謙虚な行為だ。 「私が正しい」と主張するのではなく、「ここに検討すべき点がある」と場に置くだけ。 判断は、それを読んだ人たちに委ねられる。この姿勢は、和を大切にする文化とも、 相性がいいと思っている。

Fact First. 感情より先に、データを見る。

私たちは日頃、感覚で判断してはいけない場面をよく知っている。 「なんとなく速い気がする」ではリリースできない。 計測して、数字を見て、それから判断する。

0か1かを判断する仕事をしてきた人たちへ。

とはいえ、社会の問題は、0か1かの二値では表現できないことがほとんどだ。 重要なのは、「確認済みの事実」「確率の高い推定」「データ不足の未知」を、エビデンスの強さと信頼度に応じて段階的に真偽分類することだ。

政策議論に足りないのは、意見ではなく解析能力かもしれない。

政策の議論を見ていると、意見はたくさんあるのに、 一次資料をきちんと読んで解析している人は驚くほど少ない、と感じることがある。 これは誰かを責めるための話ではなく、単純に「時間が足りない」という、 とても現実的な理由が大きいのだと思う。

法律、論文、議事録、統計。
LLMは、民主主義の新しい開発環境になれるか。

情報が多すぎる時代に、人間だけで政策を読み切るのは、そもそも無理がある。 数千ページにおよぶ資料をすべて読める市民は、ほとんどいない。 これは怠慢ではなく、単純に一人の人間に与えられた時間の限界の話だ。

ただ、AI、とくにLLMの登場によって、この前提が少しずつ変わり始めている。 検索する市民から、解析する市民へ。 大量の一次資料を要約し、矛盾点を洗い出し、根拠を突き合わせる作業を、 機械に手伝ってもらえる時代になった。

これは、専門家の仕事を奪うという話ではない。

行政にもObservabilityが必要だ。

ログのない、テストコードがない、冪等性が保証されないシステムを、私たちは信用しない。 何が起きたのか、あとから追えないシステムは、どれだけ動いていても不安が残る。

政策も同じではないか、と思う。測定できない政策を、私たちはどう評価すればいいのだろう。 政治を、ブラックボックスにしないためには、オープンソースの世界で当たり前になっている「見える化」の発想が、案外役に立つ。

CASE STUDY

「昔はそうだったから」で裁かれる

抽象的な話はここまでにして、実際に起きた三つの事件を見てほしい。 いずれも、技術のことを十分に理解できない捜査・司法の側が、 ごく普通のエンジニアリング行為を「犯罪」として扱ってしまった事件だ。 最終的にはすべて無罪、あるいは名誉回復に至っている。 問題は、そこに至るまでにかかった歳月と、その間に社会が失ったものだ。

岡崎市立中央図書館事件（Librahack事件・2010年）

愛知県の男性が、図書館の蔵書検索サイトの使い勝手に満足できず、 自作のクローラで新着図書情報を取得しようとした。ごく一般的な技術であり、 悪意はなかった。ところが図書館のサイトに接続障害が起き、 図書館は偽計業務妨害容疑で被害届を提出。男性は逮捕され、20日間勾留された。 のちに、障害の真因は図書館側のシステム自体の不具合にあったことが判明する。 男性は起訴猶予となり、その後、図書館側との共同声明で 「クローリングは技術的に一定の配慮が施されたものだった」ことと、 名誉回復が確認された。

Winny事件（2004年〜2011年）

東京大学大学院の研究員だった金子勇氏が開発したファイル共有ソフト「Winny」。 一部の利用者が著作権侵害に使ったことを理由に、金子氏自身が2004年、 著作権法違反幇助の容疑で逮捕された。2006年、京都地裁は有罪判決（罰金150万円）。 2009年、大阪高裁で逆転無罪。そして2011年、最高裁で無罪が確定した。 ソフトウェアを作った本人に、著作権侵害を助長する意図があったとは 認められない、という判断だった。

しかし金子氏は、無罪確定からおよそ1年半後の2013年、42歳の若さで急逝している。 技術者としてもっとも脂が乗っていたはずの7年間を、彼はこの裁判に費やした。

Coinhive事件（2017年〜2022年）

ウェブサイト運営者が、広告の代わりに閲覧者のPCの余剰計算力を借りて 暗号資産をマイニングする「Coinhive」というスクリプトを自分のサイトに設置した。 これが「不正指令電磁的記録保管」、いわゆるウイルス罪の容疑で摘発される。 横浜地裁は無罪、東京高裁は逆転有罪（罰金10万円）。 そして2022年、最高裁は「マイニングスクリプトは不正な指令にあたらない」として、 無罪を確定させた。

逮捕と勾留は一瞬で行われる。名誉の回復には、何年もかかる。

三つの事件に共通するのは、行為そのものの技術的な意味を、 裁く側が十分に理解できていなかったという点だ。 悪意のない、ごく普通のエンジニアリングが、 「よくわからないから、とりあえず罪に問う」という扱いを受けてしまう。 これは特定の誰かの過失というより、専門知識と法制度のあいだに空いた、 構造的なギャップの問題だと思う。

補足：当時、捜査機関の側にも、実際に発生していたサービス障害や 利用者からの苦情に対応しなければならない事情があったことは、公正のために付け加えておきたい。 それでも、専門知識の不足が結果として人を長期間拘束し、苦しめた事実は変わらない。 だからこそ私たちは、技術を理解しない人だけに、技術についての判断を委ねてはいけないのだと思う。

CASE STUDY

薬物をめぐる議論を、善悪ではなくシステムとして読む。

ここまでの話を、ひとつ具体的な題材で試してみたい。薬物政策だ。 この話題は、日本ではとくに感情とデータが激しく衝突しやすい。 だからこそ、エンジニア的な読み方の練習として向いている。

そして、この数十年で大きく変わったのが「観測技術」だ。MRI、fMRI、PET、EEGに加え、画像処理、統計解析、ネットワーク解析などのIT技術が進歩したことで、薬物投与前後の脳活動や血流、機能的な接続、受容体への作用などを、以前より細かく計測できるようになった。

もちろん、脳画像を見れば「安全」「危険」が自動的に判定できるわけではない。ただ、観測できる変数が増えたことで、投与量、脳活動、認知機能、依存リスクなどを分解して検証できる範囲は広がっている。

ソフトウェアなら、observabilityが改善されたのに30年前の障害報告だけを根拠にシステム設計を続けるのは不自然だ。社会制度も同じで、新しい観測結果が得られたなら、モデルを継続的に更新する必要がある。

• 賛成/反対ではなく、構造として見る。 誰の利益で、誰のリスクで、 どの制度がどう機能してきたのかを、まず切り分ける。

• 偏見は、最も修正しにくいレガシーコードである。 一度広まったイメージは、 新しいデータが出てきても、なかなか上書きされない。これはコードよりも厄介かもしれない。

• 規制は必要だ。だからこそ、良い規制を設計する。 無規制を主張しているわけではない。 むしろ「規制がない方がいい」という極端な立場からは意図的に距離を置く。 問いは「規制するかどうか」ではなく、「どういう規制なら機能するのか」だ。

• 合法か違法か。その二値だけでは、社会問題は解けない。 医療用途、 産業用途、嗜好品としての扱い、未成年へのアクセス防止。分解すれば、 それぞれ別の設計課題であることがわかる。

ログを取り、観測し、仮説と実測値の差を見る。社会制度についても、本来やるべきことはそれほど違わない。

補足：脳画像や統計的な関連だけから、因果関係や安全性を断定することはできません。ここでの狙いは特定の結論ではなく、「まず観測し、問題を分解し、データからモデルを更新する」という読み方を共有することです。

規制というプロダクトを、UXから考えてみる。

プロダクトを作るとき、私たちはユーザーを知らずに仕様を決めたりしない。 使う人を観察し、インタビューし、仮説を検証してから初めて設計に入る。

政策も、実は同じ構造をしているのではないだろうか。 現場を知らずに決められたルールは、ユーザーリサーチなしで作られたプロダクトと同じように、 どこかで使いにくさや歪みを生む。 本番環境でしか起きない問題を、机上の議論だけで判断しないこと。 それが、良い規制を設計するための、いちばん地味で、いちばん大事な一歩だと思う。

市民運動を、精神論からエンジニアリングへ。

「アドボカシー」と聞くと、どこか熱量や情熱が必要な世界に思えるかもしれない。 でも、私たちが提案したいのは、もう少し地味なアプローチだ。 運動ではなく、改善プロセスとしてのアドボカシー。 声の大きさではなく、再現可能性で、少しずつ社会を変えていく。

• Issue 気になることを、まず言語化する再現手順を書くように、何が問題かを整理する。

• Evidence 一次資料にあたる統計、論文、議事録。感情より先に、証拠を集める。

• Proposal 代案を出す批判だけで終わらせず、実行可能な代替案まで書く。

• Review 他者の目を通す異なる立場からのレビューを歓迎し、更新し続ける。

優秀な分析者が政治を避けると、誰が複雑な制度をレビューするのだろう。 政治が好きだから参加するのではない。複雑なものを分解できる、それだけで、 すでに社会に提供できる価値があると、私たちは思っている。

AIがコードを書く時代、人間のエンジニアは何を設計するのか。

コードだけを書いていればいい時代は、静かに終わろうとしている。 AIが実装を肩代わりする範囲は、これからも広がっていくだろう。 その先に残る仕事は、おそらく「何を作るか」ではなく「何を変えるべきか」を決めることだ。

生産性が上がった社会で、なぜ私たちはまだこんなに忙しいのか。 コードの生産コストがゼロに近づく世界で、価値はどこへ移っていくのか。 AIが労働を減らすなら、その利益は誰のものになるのか。 これらは、まだ誰も答えを持っていない、とても大きな問いだ。 だからこそ、答えを待つのではなく、一緒に考える側に回りたいと思っている。

テクノロジーは中立ではない。使う側が、どういう思想を持つかで、 その意味は変わってしまう。「作れる人」から「未来を選べる人」へ。 便利な未来をつくることは、もう十分できるようになった。 次に必要なのは、選べる未来をつくることだと思う。