背景
deployment と open-decisions A2 で長期未着地だった「Azure デモ環境を docs からどう動線化するか」について、nishio が 2026-06-04 22:29 の dd2030 Slack 投稿で Ohki さん宛の 4 問の具体質問として整理した。前提として kouchou-ai-docs-entry-restructure-2026-06-03 の spine 改訂 (入口は viewer、self-host は最後) と連動している。nishio-slack-azure-demo-visibility-proposal-2026-06-04より
4 問の構造
質問は「どこまでなら公開 OK か」を 4 段階に decompose している。
1. viewer 公開（サンプルレポート閲覧）
ビューワーをそのまま公開してサンプルレポートを見せることへの賛否確認。広聴 AI の出力物 (レポート) を見るだけのアクセスで、admin 操作・API キー・データ投入は伴わない。コストもプロビジョニング負担も極小。
ここはほぼ問題なさそう、という前提で問われている。
2. admin 画面共用 + 秘密情報禁止の明示
admin 画面まで公開し、ユーザが自分の API キーを入力して試せる構成。
実装上の前提:
- Issue #660 (2025-07-30 merge) で admin form からの API key 入力経路が main にある llm-providersより
- PR #868 (2026-05-29 までに merge) で
USER_API_KEYplumbing が main にある meeting-report-2026-05-25より
したがって「ユーザが自分のキーで分析を回す」コード自体は問題ない。コストもユーザのキー側に乗るので dd2030 持ち出しは増えない。残るのは運用方針として「共用環境で全員に共有されるから秘密情報を入れないで」を明示すれば OK か、という判断。
3. ワンクリック 1 ヶ月専用試用環境
「秘密情報を入れたい自治体」向けの代替案として、Github admin (大木さん他) がワンクリックで 1 ヶ月の専用試用環境を provisioning する構成。
open-decisions A2 では「やるならユーザごとに現 Azure デモ環境相当を丸ごと複製する方向」と書かれていたものを次のように具体化:
- on-demand provisioning（恒常運用ではない）
- Github admin (大木さん他) がトリガー（誰がやるかが定義される）
- 1 ヶ月の試用期限つき（永続稼働ではない）
4. 365 日稼働 SaaS の不参加確認
「試用期間を超えて 365 日稼働を保証する SaaS」を大木さんがやる気はない、という前提確認。
deployment と open-decisions A2 で SaaS ホスト kouchou-ai.dd2030.org は「体制不足で先送り」と繰り返されてきた。Q4 はこの状態を「目下の方針として明示する」確認質問として読める。これが confirm されれば、docs 上でも「365 日稼働 SaaS は現状の選択肢にない」と書ける。
2026-06-05 の Resolution
azure-demo-visibility-thread-resolution-2026-06-05 により次のように着地した。
viewer 公開 / admin 共用は進める
Q1 / Q2 とも賛成。ただし実施には次の prerequisite と明示文言が伴う。
- Prerequisite (設計判断): 現状の Azure デモ環境では、WebUI からユーザがキーを指定しなかった時のフォールバックとして container の
OPENAI_API_KEYに dd2030 側のキーが設定されている可能性が高い。viewer 公開 + admin 共用に切り替える際は、まずこのフォールバックキー設定を外し、ユーザがキーを入れなかったら動かない構成にする必要がある（具体的な設定箇所や値は公開 wiki には書かず、Google Drive「広聴 AI-Azure デモ環境」側で扱う） - 公開時の明示文言 (3 点):
- 共用環境であること
- 個人情報・未公開情報・機微情報は入れないこと
- データ保存や継続稼働は保証しないこと
1 ヶ月専用試用環境は優先度低
Q3 はアイデアとしてはあり、ただし実ニーズは現時点で不明。「選択肢としては取り得るが、今は優先度低い」位置付けで保留。代わりに、自治体ユーザ向けには 公開事例 / サンプルレポート / サンプル CSV を見ながら「どんなテーマで使えるか」「どんなデータが必要か」を理解できる導線 の充実が優先となる。
365 日 SaaS は提供主体・責任範囲の整理項目化
Q4 は「継続利用できる環境はあるとよさそう」だが、「誰が、どの責任範囲で、どういう形で提供するか」の整理が必要。個人運用環境に自治体が乗るのは難しく、dd2030 として提供すると 365 日稼働 / データ管理 / 問い合わせ対応 / サポートまでの責任が重い。責任を持って継続運用・サポートできる主体 を立てる方向で、別途整理項目化する。
社会実装の実態としては、ツール / SaaS 環境の有無だけでなく、自治体や団体の「テーマ設定 / 意見収集 / 読み解き / 政策形成・対話への接続」までの支援が必要、という補足あり。
デモ環境の価値の再フレーム
Resolution と一緒に出てきた重要な再フレーム:
- これまで「自治体側がデモ環境に自分のデータを投入してレポート生成する」ことを暗黙の goal にしていた節があったが、大木さんの観察では「自治体側でデータ投入してレポート生成まで至ったケースは、把握範囲ではまだ無い」
- 一方で「動くものを見られる」「admin 画面からサンプル CSV をダウンロードできる」ことが、「どう使うか」「どんなデータを準備すべきか」の理解に役立っているという声はある
- したがって、デモ環境の現時点の価値は 「自分たちのデータを投入して試す場所」よりも「使い方や準備すべきデータを具体的に理解するための参照環境」 として見直す方がよい
この再フレームは kouchou-ai-docs-entry-restructure-2026-06-03 の spine tier 1 「興味がある人」の docs 内コンテンツ設計に直接効いてくる。「demo を入口にする」目的が「データ投入の予行演習」ではなく「使い方と準備データの参照」になる。
docs spine との接続
kouchou-ai-docs-entry-restructure-2026-06-03 の改訂 spine と対応させると次のようになる。
- tier 1「興味がある人」= 4 問の Q1（viewer 公開）
- tier 2 選択肢 1「誰かが建てたサーバ」= Q2 と Q3 を併用（共用デモ + 1 ヶ月専用）
- tier 2 選択肢 2「サーバを建ててくれる人を探す」= docs に連絡先リストを置く形（今回の質問の対象外）
- tier 2 選択肢 3 / tier 3「自分で建てる」= 従来の self-host（今回の質問の対象外、Q4 で確認する SaaS 線とは独立）
Q1〜Q3 が解決すると spine tier 1 と tier 2 前半（managed 線）が docs の動線として埋まる。
Open Questions
- 共用 admin 画面で「秘密情報を入れないで」明示が法的 / 倫理的に十分な protection か。実態として API キー入力は秘密情報入力と区別しづらく、ユーザの誤投入リスクが残る
- container
OPENAI_API_KEYフォールバック除去の具体実装 (Bicep / Container Apps の env 設定変更 / deploy workflow 側の手当てなど) は Google Drive「広聴 AI-Azure デモ環境」側で扱う - 公開時の 3 点明示文言 (共用 / 機微情報禁止 / 保存・継続稼働非保証) を docs / admin 画面のどこにどう出すか
- dd2030 Web サイト上の公開事例ページの更新・充実は誰が継続的にメンテするか（broadlistening-tool-ecosystem-vision / kouchou-ai-scope-line-from-marketing-to-plugin-2026-06-03 との接続点）
- 365 日稼働を担う「責任を持って継続運用・サポートできる主体」をどう立てるか。dd2030 / 個人 / 別法人 / 自治体側コンソーシアム など複数候補が考えられるが、現時点で未着地
Updates
- 2026-06-05: azure-demo-visibility-thread-resolution-2026-06-05 により Resolution 確定。Q1 / Q2 進行 (前提: container の dd2030 フォールバックキーを除去 + 3 点明示文言)、Q3 優先度低 (公開事例の充実が代替方向)、Q4 提供主体・責任範囲の整理項目化。あわせてデモ環境の価値を「データ投入の場所」から「使い方理解の参照環境」へ再フレーム
- 2026-06-04: 初回作成。nishio の Slack 4 問を spine 改訂 / 既存 open-decisions A2 / 実装済み USER_API_KEY plumbing と接続して整理