【ITニュース解説】Running an election forecast's launch as separate Claude Code sessions: rules, mistakes and a real scoreboard

このニュース記事は、AI（人工知能）を活用して構築された選挙予測サイト「MT26」の、開発から公開、そしてその後の運用に至るまでの具体的なプロセスと、そこから得られた教訓を詳述している。システムエンジニアを目指す初心者にとって、これは現代のソフトウェア開発現場でどのような工夫がなされ、どのような課題に直面し、それをどう乗り越えるかを知る貴重な機会となるだろう。

MT26は、アメリカの中間選挙における全506の議席と知事選の予測を行うシステムだ。驚くべきことに、この予測モデル、データを処理する仕組み（データパイプライン）、そしてウェブサイトそのもののコードは、AIである「Claude Code」によって書かれている。しかし、プロジェクト全体の目標設定や、最終的な判断を下すのは人間である筆者だ。この記事の主題は、システムが完成し、いよいよ世の中に公開される「ローンチ」の段階で、作業がどのように組織され、そして何がうまくいかなかったのか、という点にある。

このプロジェクトの大きな特徴は、システム開発と運用のタスクを「一つの大きな対話」として進めるのではなく、「複数の独立したAIセッション」に役割を割り当てたことだ。これは、人間による開発チームが、メンバーそれぞれに異なる役割と責任を与えるのと似ている。具体的には、AIセッションは以下のような役割を担った。

「アーキテクト」セッションは、サイトのコード全体を管理し、システムのデプロイ（開発したシステムを実際に動く本番環境に公開する作業）の責任を負う、いわばシステムの設計者兼管理者だ。 「マーケティングリード」セッションは、サイトの公開とプロモーション活動を指揮する。コードフォルダを読み込むことはできるが、コードを直接編集する権限は持たない。 「スコアキーパー」セッションは、予測が正しいかを評価する役割だ。予測結果を確定させ、その記録を残し、後で実際の選挙結果と照らし合わせて精度を検証する。 「リハーサルディレクター兼ウォッチドッグ」セッションは、開票速報時のライブ予測更新をシミュレーションし、そのプロセスを監視した。 「QA（品質保証）兼ファクトチェック」セッションは、システムや公開されるコンテンツに誤りがないかを、読み取り専用の権限で確認する。

これらのAIセッションは、互いにメッセージを送り合うだけでなく、共有ファイルを通じて情報を共有した。例えば、人間である筆者の承認内容と時刻が記録されたログ、公開された投稿の履歴、そして各セッションが参照できるメモフォルダなどがある。これにより、もし一つのセッションが処理できる情報の量（コンテキスト）を超えても、次のセッションがこれらの共有ファイルから情報を引き継ぎ、作業を継続できるようになっていた。これは、人間チームがプロジェクトのドキュメントや共有フォルダを使って知識を共有し、スムーズに業務を引き継ぐのと同じ考え方であり、大規模なプロジェクトにおいて非常に重要な仕組みである。

このプロジェクトでは、ルールが明確に文書化され、単なる口約束ではなく、ツールによって強制される仕組みになっていた点も重要だ。例えば、「公開されるあらゆる投稿やデプロイには、必ず人間である筆者の明示的な『yes』の入力が必要」というルールがあった。これは、AIが勝手に重要な判断を下すことを防ぐための安全策だ。実際に、マーケティングセッションがデプロイを要求した際、アーキテクトセッションのシステムチェックがそれを拒否し、筆者が自ら「yes」と入力するまでデプロイは実行されなかったという。このように、人間の最終的な承認をシステムが強制する仕組みは、品質を維持し、誤操作や不正を防ぐ上で非常に効果的だ。

システムの透明性と検証可能性も徹底されていた。デプロイされたシステムは、本番環境のサイトとファイルの内容が一致しているかを、ハッシュ値（sha256という特定のデータから一意に生成される短い文字列）を用いて確認できる「フリーズされたスナップショット」として扱われた。これにより、いつ、どのようなコードが公開されたかが明確になり、問題が発生した場合には約2分で以前の安定したバージョンにシステムを戻す（ロールバック）ことが可能だった。また、AIセッション同士でも互いの内容をファクトチェック（事実確認）し、例えばアーキテクトセッションは、マーケティングセッションが作成した公開文案がコードやデータと整合しているかを検証し、誤りがあれば修正を指示した。予測結果自体も、公開前にインターネットアーカイブサービスであるWayback Machineに保存され、その記録のハッシュ値（フィンガープリント）が公開された。これにより、誰でもアーカイブされた予測ファイルが改ざんされていないことを確認できるようになっていた。このような透明性は、特に信頼性が求められるシステムにおいて不可欠な要素である。

しかし、AIエージェントによる開発は常に完璧なわけではなかった。いくつかの間違いも発生し、そこから多くの教訓が得られた。 まず、開票速報用の予測モデルが、2024年の実際の開票データを用いた最初のリハーサルで、バージニア州の予測を誤った。これは、モデルが実運用に近いデータで十分なテストと学習ができていなかったことを示唆しており、現実のデータを使った厳密なテストの重要性を教えてくれる。 また、アラスカ州の下院選挙が「50%決選投票」と誤ってマークされた問題も発生した。これは、プログラムが「instant-runoff（即時決選投票）」という文字列を処理する際、「ranked（順位付け投票）」よりも先に「runoff（決選投票）」という部分にマッチしてしまったためだ。これは、文字列処理において厳密な条件指定が必要であることを示す好例である。 さらに、サイトの非公開統計ページへの問い合わせが、モック（本物のデータではなく、テスト用に作られた模擬データ）を使ったテストでは成功したにもかかわらず、本番環境ではエラー（HTTP 422というWebサーバーのエラーコード）となった事例があった。これは、モックテストだけでは本番環境の複雑な設定や挙動を完全に再現できないことを示しており、実際のシステムとの連携テスト（ライブAPIテスト）の重要性を浮き彫りにした。 そして、サイトの訪問者数の誤認という問題もあった。マーケティングセッションは「約20〜25人のリアルな訪問者」と報告したが、ページの滞在時間を計測するビーコン信号（ウェブページがサーバーに送る短い通信）が送られたのは、わずか3ページのみだった。残りのアクセスは、JavaScriptを実行しないスクレイパー（自動で情報を収集するプログラム）によるものだと判明した。この経験から、一つのデータ源に頼るのではなく、複数の異なる信号を使って情報を検証することの重要性が示され、より正確な訪問者数を計測するために、ページが開かれた瞬間にビーコンを送信する仕組みが導入された。

これらの経験から、筆者が今後も継続したいと考える重要なプラクティスが挙げられている。それは、「一つの作業を一つのAIセッションに担当させるという明確な役割分担と、ルール、そして承認記録の共有」「公開されるものは必ず人間の『yes』が必要であり、それがツールの権限チェック機能によって強制されること」「報告される数値は必ず別の信号（データ源）と照合して確認すること」「モックデータを使ったテストだけでなく、ライブAPI（本番のシステム連携口）に対するテストも行うこと」だ。

このプロジェクトは、AIが高度なシステム開発に大きく貢献できる可能性を示しつつも、その過程で人間の監督、厳格なプロセス管理、そして実際の運用から得られる学びがいかに重要であるかを教えてくれる。システムエンジニアを目指す皆さんにとって、これはAIを開発ツールとして活用する未来において、人間がどのような役割を担い、どのようなスキル（品質管理、情報共有、トラブルシューティングなど）が求められるかを考える上で、非常に示唆に富む事例と言えるだろう。