広聴AIは、多くの人から集めた意見をAIで整理し、その広がりを図や文章で読むためのツールだ。その結果を対話や判断に使うには、処理中に声が抜け落ちたら気づけること、表示された件数や要約の意味を読み違えないことが大切になる。
9月8日から9日未明にかけて、西尾とCodexはこの信頼性と使いやすさを中心に開発を進めた。本体には20件の変更提案（PR）を取り込み、別に開発されているブラウザ完結のServerless版にも5件のPRを提出した。同時に、開発の目的を「レポートを作れること」から、その先の「元の声を確かめ、対話・判断・応答へつなげられること」まで広げて考え直した。初期の対応記録 / 実装とマージの記録 / Serverlessとの関係と開発方針より。
まず、分析の失敗が見えるようにする
出発点は、前日に読んだSlackとGitHubの課題（Issue）だった。同じ回答データでも、条件によって意見が一件も抽出されない回答が増えるという報告があった。調べると、正常に「抽出する意見がなかった」場合と、API呼び出しや応答の解釈に失敗した場合が、同じ空の結果として扱われていた。これでは、結果が少ない理由を利用者が判断できない。SlackとIssueからの問題整理 / 初期の対応記録より。
そこで、通信エラー・時間切れ・不正な応答を正常な0件と区別し、失敗時は後続の処理を止めるようにした。意見グループに見出しを付けるラベル生成でも、失敗を正常完了に見せないようにした。調査に必要な回答IDや原文は診断用の出力へ残し、公開レポートには自動で含めない。失敗時に費用や利用量の集計が揃わなければ、「集計不完全」と表示する。初期の対応記録 / 実装とマージの記録より。
モデル選択にも食い違いがあった。Azureでは画面上の選択が実際の呼び出しに使われないため、固定されている設定を正しく表示するようにした。モデル一覧・説明・価格・検証状態も一つのカタログに集約した。西尾の判断で、未検証モデルもその状態を表示して選択可能にし、実際に動くかの確認は別の課題として人間が担当することにした。料金が分からない場合を無料と表示しないことも、この整理に含めた。初期の対応記録より。
元の回答欠落の根本原因まで特定できたわけではない。今回進めたのは、失敗を見逃さず、原因を調べられる状態にすることだ。
分析を始め、結果を読むまでのつまずきを減らす
失敗の検知に続いて、利用者が通る画面の流れを整えた。
分析を始める前には、CSVの形式エラーを原因と修正方法付きで示し、読み込みに失敗したときに以前の入力が残らないようにした。空のタイトルや概要はCSV名から補完する。送信前の確認画面では、入力件数・対象列・モデル・API接続の状態を一緒に確認できるようにした。選択したモデルやローカル接続先を使う接続確認も加えた。ただし、費用と時間の数値見積もりはまだなく、「目安なし」と表示する。実装とマージの記録より。
結果を読む画面では、階層図を掘り下げたときに、その場所に対応する説明・件数・割合が一緒に変わるようにした。図と説明の行き来や、親のグループへ戻る操作も揃えた。また、表示された件数は社会全体の支持率ではないこと、収集対象の偏りや元コメントを確かめる必要があることを、閲覧画面と持ち出すHTMLで案内するようにした。実装とマージの記録より。
日本語の折り返し、全画面表示でのボタンと説明の重なり、静的ファイルの開き方も修正した。狭い画面では一覧を初期表示にしつつ、明示された設定や利用者が選んだ表示を尊重する。開発者向けには、空・通常・エラーなどの画面を切り替えて確認する環境、完成データの参照整合性を調べる任意の検査コマンド、Windows導入とプロンプト調整のガイドを追加した。実装とマージの記録より。
Serverlessとの関係は、利用者の目的から考える
ここまでの改善を既存版だけで進めてよいのか、という問いも扱った。広聴AIには既存のサーバ構成に加えて、ブラウザ上で動くServerless版がある。初めて試す人、継続して組織で運用する人、分析手法を比較する人では、必要な入口や制約が異なる。dd2030-wikiを参照し、「どちらを本流にするか」を、利用入口・開発の重点・所有やリポジトリ移管という三つの判断に分けた。Serverlessとの関係と開発方針より。
途中でCodexが「次はServerlessの抽出失敗を修正する」と提案したところ、西尾から「広い視野で考えて」と指摘された。直せる不具合を選んでも、それが今の利用者にとって最大の障害とは限らない。そこで、具体的な実践の収集→分析→議論→応答をたどり、どこを改善すると価値があるのかを確かめる方向へ考え直した。ブラウザ版を初回利用、既存版を組織運用、分析エンジンを手法比較に使うという役割分担も、利用場面で検証する仮説として扱う。Serverlessとの関係と開発方針より。
その間も、両版で同じ問題が起きる部分の保守は進めた。CSVの入力例、階層図の件数・割合、失敗後の復帰、スマホ表示を同じ条件で比較し、Serverless側にも対応する修正を提出した。元コメントのIDが数値変換で壊れる問題も修正した。一方、両版の結果ファイルには原文を含むかどうかなどの差がある。互換性を高める際にも、公開する情報の範囲を勝手に広げないことを共通の条件とした。両版の構造・データの比較 / 実装とマージの記録より。
古い課題を、今の実装に照らして整理する
自動テストの完了を待つ間に、過去のIssueも読み直した。未解決119件の一覧・本文・コメントを取得し、現行実装と関係するものを重点的に確認した。その結果、実装済みの5件を完了にし、重複する3件は残すIssueへ要件を引き継いで閉じた。さらに18件へ、現在の状態と残作業を追記した。過去Issueの棚卸しより。
確認では、古い「完了」というコメントをそのまま信じないことが重要だった。例えば、乱数のseedが設定済みと書かれた課題は、その後の変更で固定が意図的に外されていた。また、作成前の確認画面があっても費用見積もりは未実装で、抽出意見を読めても元コメントへの参照は別の課題として残る。似た機能があることと、求められた利用ができることを分けて判断した。過去Issueの棚卸しより。
この判断方法はWikiの開発手順にも残した。Issueを閉じる根拠、検証した範囲、両版で共通に確かめる入力や操作を、次回の作業でも使えるようにした。Wikiを使った開発手順より。
テストを確認し、本体20 PRを取り込んだ
実装した変更は、CI（GitHub上の自動テストやビルド）の成功を確認して、本体のmainブランチへ順にマージした。日付をまたいで残った7 PRも最終的にはすべて取り込んだ。文書メニューの追加位置が競合した箇所は、各ページへの導線を残して解消し、変更後のCIを再確認した。取り込んだ20 PRには、以前から提出されていた文書化や依存更新のPRも含む。初期の対応記録 / 実装とマージの記録より。
主な検証結果は次のとおり。
- 本体の統合結果：閲覧画面の109テスト、抽出診断・成果物検査の21テスト、厳密な文書ビルドが成功。最後に取り込んだPRでは、ブラウザ操作を通すE2Eテストと本番ビルドもCIで成功し、最終mainと検証した内容の一致を確認した。
- Serverless側：各PRでローカルのテストや表示を確認し、最後の追加修正では204テストと型検査が成功。階層図の移動、絞り込み、0件からの復帰、スマホ表示、単一HTMLでの操作も確認した。
- 検証の限界：新モデルの実API動作、Windows実機の追加確認、初見利用者による現場評価は行っていない。テスト成功だけで分析品質や現場価値が実証されたとは扱わない。
実装とマージの記録 / 過去Issueの棚卸しより。テスト件数は実行した範囲が重なるため合算していない。AIによる自動レビューが利用制限や実行待ちだったPRもあり、CI成功とレビュー完了は区別した。マージ方法と競合解消の詳細は実装記録に残している。
作業終了時の状態は、次のようになった。
| 対象 | 状態 |
|---|---|
| 本体 | 20 PRをmainへ反映。最終commitは 775e0f5 |
| Serverless | 提出した5 PRは未マージ。GitHub Actionsの実行承認待ちで、作業アカウントにマージ権限もない |
| 過去Issueの棚卸し | 完了5件・重複統合3件を閉じ、18件を更新 |
| 最後の7 PRに対応するIssue | 11件がマージにより完了。これを含め、本体の未解決Issueは100件 |
| 本体に残るPR | 作業中を示すdraftの2件を維持 |
実装とマージの記録 / 過去Issueの棚卸しより。
残した作業と、次に進めること
残る二つのdraftについては、西尾が内容を確認し、そのまま残すと判断した。
- #917：OpenAI Flex対応。tokoroten / Copilotが担当するAPI費用削減の変更。通常テスト・ビルドの成功確認はまだ揃っていない。
- #891：Windowsスタンドアロン版。Python・API・閲覧／管理画面を同梱するtokorotenの試作。現在のmainと競合し、作成フロー全体の検証やインストーラーが残る。Serverlessとの役割も検討事項となる。
実装とマージの記録 / Windows配布試作の確認記録より。新モデルの実動確認も、#912 / 913で人間が担当する課題として残している。
次の開発候補は、利用者の流れに沿って三つに整理した。
- 自分に合う入口を選べるようにする。今回整えたWindows導入ガイドを土台に、閲覧・CSV分析・組織運用・開発・分析実験を分け、制約に合う経路へ案内する（#876 / #496）。
- 分析を始める前に判断材料を持てるようにする。費用・時間について推定・不明・実測を区別し、両版で比較できる条件を残す（#79 / #11）。
- 元の声を確かめ、次の対話へ渡せるようにする。原文の公開範囲を守り、活用事例には問い・収集の偏り・根拠照合・その後の行動・失敗も残す（#56 / #250 / #564 / #130）。
過去Issueの棚卸し / Serverlessとの関係と開発方針より。
実装へのリンク
本文で扱った改善を、個々の変更へたどるための一覧。本体の以下20 PRはすべてマージ済み。
| 改善のまとまり | 本体PR |
|---|---|
| 抽出・ラベルの失敗検知、診断、完成データの検査 | #910、#919、#928、#931 |
| モデル表示・カタログ・接続確認 | #911、#914、#926 |
| 入力補完・タイムアウト・作成前確認・CSV・Windows導入 | #918、#920、#922、#923、#929 |
| 読み方・階層図・日本語とスマホ表示・状態別UI確認 | #924、#927、#933 |
| 開発導線・プロンプト比較・Node依存の棚卸し文書 | #925、#930、#903 |
| 開発起動と依存更新 | #932、#904 |
Serverless側は、[元コメントIDの保持 #22](https://github.com/tokoroten/kouchou-ai-serverless/pull/22)、[CSV入力 #23](https://github.com/tokoroten/kouchou-ai-serverless/pull/23)、[読み方ガイド #24](https://github.com/tokoroten/kouchou-ai-serverless/pull/24)、[階層図と説明の連動 #25](https://github.com/tokoroten/kouchou-ai-serverless/pull/25)、[抽出診断・日本語・スマホ表示 #26](https://github.com/tokoroten/kouchou-ai-serverless/pull/26) の5件。いずれも未マージ。
Open Questions
- 921で扱う利用入口・開発重点・所有や移管を、それぞれどの利用観測を根拠に決めるか。
- 費用・時間見積もりと元コメント参照は、両版のどこまで共通の振る舞いを約束するか。
- 具体的な実践で、収集から対話・判断・応答までの最大の障害はどこか。
記録の範囲
対象は2026年9月8日〜9日未明（JST）。前日のSlack調査を出発点とし、GitHubの最終マージ確認は9日02:21、残るdraftの内容確認は02:31、維持する判断は02:57の記録に基づく。読みやすさのため最終状態を本文へ統合しており、今回の編集で新たなGitHub操作や動作検証はしていない。途中の判断・実装・検証の詳細は 初期の対応記録 / 実装とマージの記録 / 過去Issueの棚卸し を参照。
Updates
- 2026-09-09 02:06: 日報を作成。
- 2026-09-09 02:21: CI待ちだった本体7 PRのマージと統合検証を反映。
- 2026-09-09 02:57: #917 / 891をdraftのまま残すユーザー判断を反映。
- 2026-09-09 03:06: 初見の読者が読みやすいよう、背景・改善・Serverlessとの関係・検証・残課題の流れへ再構成。追記の内容を本文へ統合し、PR一覧を後半へ移した。初稿と途中経過はGit履歴と上記の実装記録に保持。