選挙でGitHubを使うことに意味はあったのか？――GitHubを用いた政策リポジトリの公開について振り返る
安野チームの今泉（GitHub担当）です。
選挙活動が終わって一週間ほど経ちましたが、現在でもテレビ・雑誌等さまざまなメディアにおいて、東京都知事選挙を総括する記事が出ている今日この頃です。感想についてもSNSでたくさん投稿されており、肯定する意見も批判的な意見も、いずれもじっくり拝見させていただいています。
この記事は、「双方向の政策ディスカッション」を実現するための方策として行われた「GitHubを用いた政策リポジトリの公開」プロジェクトについての振り返り記事です。
選挙期間中に投稿した過去の解説記事はこちらをご覧ください。
結果
感想戦を始める前に、まずファクトベースで結果を見ていきます。今回募集したのは「課題提起」であるissueと、「変更提案」であるPull Request（PR）ですが、それぞれどれだけ投稿されたのでしょうか。数字を見ていきましょう。
課題提起（Issue）
政策は複数のラベルが付与されているものもあるため、合計するとissueの数より多い点に注意。
issueは合計で232（open + closed）、うち26は課題は提起されたもののissueとしては閉じられています。閉じられたものの中には、最終的にPRになって統合されたものもありますが、重複するため閉じられたものやissueを立てた方がご自身で閉じられたものが含まれています。
232という数字をどう評価するかは比較対象がないので難しいですが、もともと無名な候補によるものであったこと、GitHubというハードルの高いツールであったことなどを考えると、意外とたくさんの人に見に来ていただけたのかなと思います。
立てられたissueはほとんど政策・マニフェストの内容そのものについてのもので、のちに見るPRではシステム改善系のPRや誤字・表現修正系のPRより少なくなったことと対照的でした。
政策ごとのラベルも集計しましたが、どの分野もまんべんなく意見を集めていました。比較的多いのは「経済」「教育・子育て」「行政」で、有権者からの関心の高さがうかがえます。
なお、立てられたissueの中に荒らしや嫌がらせのようなものは含まれておらず、受付期間全体を通じてモラルの高いフォーラムになっていたといえます。
変更提案（Pull Request, PR）
PRは全体で104本、うち72本はマニフェストに統合（merge）され、反映済みとなっています。まだ未対応のPRが19本、重複削除や明示的に取り込まない判断を行いcloseしたものが13本となります。
この中には、システムサイドや掲示の修正のために技術チームが出したものや、政策立案メンバーが他のルートで得た意見やチーム内での意見を踏まえて提出したものが含まれます。したがって、すべてが有権者によるものではありません。
PRの数え方は難しいですが、PRの目的に応じて以下の三つを分類し、それぞれ集計を行いました。
政策改善：マニフェストの内容に対する変更提案
誤字・表現修正：マニフェスト中の誤記や表現の変更など、形式的な提案
システム改善：オートモデレーションなどのシステム部分や運用改善に対する提案
issueと比較して事務局が対応できた割合が多いのが特徴的であり、このこと自体の当否は後で検討します。内訳を見ると、政策提案42本、誤字・表現修正24本、システム改善38本と、政策そのものより形式面での改善提案のほうが多かったことが特徴的でした。上記の集計には表れていませんが、時系列的に見ると、誤字・表現修正系のPRは最初は多かったものの、多くが修正された最終週ではほとんどが政策提案系のPRになっていました。
小括
まず、最大の問題は、issueとPRで、事務局が対応できた数に大きな差ができてしまったことです。政策に対するissueはかなりの数来た一方で、それらをPRにすることができませんでした。他方、PRは多くを取り込むことができましたが、そのことでかえってissueとPRの取り扱いに落差を生んでしまいました。
また、「システム改善提案が多く、政策についてはほとんど取り込めていなかった」ような感覚を私も持っていましたが、全体としてみれば政策系のPRの方が多かったです。このような感覚には時間的な問題もあり、ブロードリスニング等を踏まえて行った検討はほとんど選挙戦の最終盤、7月4日から6日にかけてPRになったという事情もあるように思われます。
もっとも、政策提案系のPRは、一行追加する提案から骨太のものまで千差万別であるため、PRの数だけで捉えられるものでもないことは注意すべきだと思われます。
よかったところ
1. 新しい試みとしての結果は出せた
まず、候補者と有権者との間で政策に関する双方向のコミュニケーションがちゃんと成立したという点で、政策リポジトリの公開という施策の試みとしては最低限の結果を出すことができたと考えています。
実際、財源問題や所得制限など、マニフェストで批判を受けた部分が、選挙期間中に目の前で撤回されるという体験は都知事選史上類を見なかったものと思われ、テクノロジーの可能性を示すことができたのではないかと思います。
さらに、この取り組みは選挙終了後、さまざまなメディアで取り上げられ、評論家やインフルエンサーのみならず、既存の政治家の中にも取り組みに賛意を示してくれた方がおりました。こうした取り組みが選挙運動における選択肢の一つとなり、実際に真似する政党や候補者が出てきてくれることも期待できる状況だと思います。「政局ではなく政策で人を選ぶ」マニフェスト選挙の実現に貢献できたのではないかと考えています。
2. ハイモラルな議論・機能した自動モデレーション
リポジトリの公開にあたっては、選挙期間中に有権者から意見を募るという取り組み自体が（そもそもGitHubを使う以前の問題として）ほぼ存在しなかったため、何が起こるか予想がつかないという問題がありました。GitHubのハードルが高くて誰も見に来てくれない可能性や、逆に特定の政策が炎上して大挙して人が押し寄せる可能性など、いろいろな可能性を想定していましたが、最終的には①悪質な投稿に対処して非表示にするbotと、②issueの重複をサーチするbotをそれぞれLLMを利用する形で入れ、アドホックに人間が補佐するという形で実施することにしました。
ところが、蓋を開けてみれば、そうしたトラブルはほとんど起きず、ハイレベルな議論が展開されていました。issueの多くは我々が持っていなかった視点や問題点を指摘してくれるものであり、充実した議論になったものと思います。また、参加者の意見に対し、他の参加者が意見をぶつけるといった状況もみられ、東京都の政策についてみんながどう考えているのかを知り、自ら発信する機会にもなったように思います。
また、とりわけissueについて言えることですが、「はじめてGitHubを使いました」という方が一定数書き込んでくれたことが嬉しかったです。利用方法についてはマニュアルを用意していましたが、そもそもUIが英語しかなかったり厳しい面があることは承知していたので、投稿してくれたことに感謝したいです（だからこそ拾えなかったことが申し訳ないのですが…）。
幸いなことに、悪質な投稿を非表示にするbotはほとんど機能しなかったのに対し、issueの重複検知の方はかなり正しく「似た別の議論」があることを指摘できており、議論の整流化に貢献していました。
見つかった課題
1. issue拾えなかった問題
issueのモデレーションが十分に行えなかったことについては、政策立案メンバーがTTTC（ブロードリスニング）の取り込みや財源についての議論等、それ自体2週間でやるには難しかった問題があるなかで、寄せられる議論を十分に捌くことができなかったという問題はあると思います。
わたし自身も技術系のPRや運営に対する要望等への対応や街頭演説の手伝いなどで、政策それ自体に対するコメントはできなかったという自覚があります。議論それ自体をリードすることはできなくても、「この点が明らかになればPRを作れると思います」とか「PR作成しますので、文言についてご検討ください」とか、具体のPRにつながるファシリテーションはもっとやりようがあったと反省しています。
また、issueをPRにするところまで自動化させるのは難しいと思いますが、AIの使いどころとして、今回は取り締まりが主でしたが、議論を促進する方向でも利用できるとよかったのではないかと思います。
issueを取り込めなかったことにより、「やっぱりGitHubが使えるような経験者の声しか届かないんだ」と投稿してくれた方々に思わせる余地を生んでしまったことも反省すべきであり、次回があれば、より適切な運用マニュアルや体制を構築していきたいと考えています。
2. GitHubハードル高すぎ問題
GitHubは非エンジニアには難しすぎる、という指摘もたくさん受けていました。もっとも、このこと自体は当初からわかっていたことではあります。使い慣れている人は少ないものの、実際にはアカウントを作成してからissueを立て、ドキュメントを編集しPRを作成するまでの手順はそれほど多くないので、イメージ先行による言及が多かったのかなとも思っています。
この点については、不特定多数が同時に編集可能なドキュメントの管理方法として、（Google DriveやMicrosoft 365のドキュメント同時編集を想像していただければわかるとおり）政策リポジトリの管理をもっとも簡単かつ人間に親和的なUIで実現できる手段は、いまでもGitHub（に代表されるGitシステム）だと思っています。
法律の仕事をしていて、ドキュメントの共同管理・共同編集については、ビジネスの領域においても現在スマートな解がない（ぐちゃぐちゃになるか、取扱いの技術的なハードルが高いかのどちらか）と思っているので、まさにテクノロジーの力によって超えられるべきハードルであるように感じています。
3. 「取り込み」の恣意性の問題
上記の振り返りとは少し別の文脈ではありますが、「GitHub上で政策に関する議論が行われることそのものへの是非」についても、民主主義そのものとの関係や、政策リポジトリの取り扱い方で非常に重要な論点なので触れておきます。
これは、「GitHubというツールは第三者が客観的に検証可能な論点については有効に機能するけれども、政治・政策という価値判断を含む意思決定には向いておらず、ありもしない『客観的な正しさ』を仮装する面がある」という指摘で、重要な指摘であるように思われます。
都知事選候補の @takahiroanno の取組で、GitHubでの政策討論の話が話題だけれど、国内で初期（自称）にこの手の取組を国で企画・推進した身としては、一家言ある。…
— ADACHI Masatoshi ../.. 足立昌聰 (@MasatoshiAdachi) June 28, 2024
たしかに、GitHubは「より適切な手段」の議論はしやすいですが、大上段の価値の議論を行うには不向きなツールであることは否めません。今回の政策リポジトリをみても、増分的に修正しやすい修正提案が取り込まれていた感は否定できないように思われます。「YAMLファイルにPythonを直書きしないほうがいい」ことは合意できても、「誰も取り残さない行政とはどのようなものか」「教育と医療、どちらにどれだけリソースを割くべきか」についてGitHub上で客観的な合意に至るのは難しく、今回様々なPRを統合できたのは、安野が最終的な意思決定権限を一元的に持っていたからです。
しかし、直接民主制のツールとしてこれを使用することは難しいものの、政策立案者と有権者が双方向的に具体的な政策についてコミュニケーションする手段としての有用性はあったように思われます。さらに、価値判断の客観的正しさは保証できないとしても、政策がmergeされる過程はすべてオープンになっているので、重要な考慮要素が抜けているなどの判断過程は検証可能となっています。
また、熟議民主主義の手段としても有用であったように思われます。今回の政策リポジトリでは、「災害に強い東京の実現」というやや抽象的で重いテーマであったとしても、政策立案メンバーのモデレーションを経て、28コメントの議論の末に無事PRとなってmergeされた例もありました。
今後、本リポジトリを使ってマニフェストに意見を募る方におかれては、上記のような指摘に留意しつつ、これ自体は政治的な価値の対立を根本から解消するようなものではなく、あくまで政策形成過程の一手段なのだという点に注意していただくのがよいのかなと思っています。
おわりに
オペレーションの面においても、ツールの利活用の面においても100点というわけにはいかなかったという反省はありつつも、皆さまの参加によって有意義なフォーラムとなったのではないかと考えています。今回の選挙は残念な結果に終わってしまいましたが、安野の挑戦もまだ始まったばかりですし、チーム安野の活動もしばらくは続きますので、応援いただけますと幸いです。ここまで読んでいただき、ありがとうございました。