2026-09-18 サイボウズラボ勉強会

2026年社会情報学会のプレゼン資料がどのようなプロセスで作られたか解説する

まずプレゼン自体をやる

この勉強会の資料自体をAIがやる

やらせようと分析させた最初のリアクション:

一次ソースを読みました。/Users/nishio/shakaijoho2026 に制作過程がほぼ全部残っています（wiki/log.md、成果物台帳、candidates/、mobile-review/、final-20260911/*-evidence、transcript/）。

まず一番おいしい切り口だと思うものを1つだけ。

この制作過程の特異点は「AIにスライドを作らせた」ことではなく、人間（西尾）の判断帯域がボトルネックだと認めて、そこに専用の装置を作ったことだと思います。証拠は candidates/ と mobile-review/：

AIが15案を「選ぶために」作る（C01〜C15、比較軸つき。通し講演ではなく候補集合）

人間はスマホの4択で裁く（「本編に欲しい/別の講演で使う/作り直す/不要」）。Tailscale配信＋SQLite、音声入力可、版ごとにPDFのSHA256と画像ハッシュを紐付け、旧版コメントを新版へ自動転記しない

外出中に回答できる。9/12時点で最終稿5版に対しコメント23件・入力イベント255件

「AIが大量に作る」の対価は「人間が大量に選ぶ」で、そのコストをスマホに逃がした、という話。ラボの聴衆にはこれが一番刺さるはずで、かつ他プロジェクトに転用できる形になっています。

進行

題材は2026-09-13の2026年社会情報学会での話題提供「大勢の声を聞く技術は人の自由を増やすのか」(長崎、西尾はオンライン登壇、15-20分枠)

前半: 当日のプレゼンをそのままやる(当日の所要16分38秒)

後半: そのスライドがどう作られたのかの解説

スライドのPDFは2026年社会情報学会からリンクしてある

一言でいうと

「AIに資料を作らせた」話ではなく「人間が判断する帯域をどう安く何度も使うか」の話

AIが候補をいくらでも作れるようになると、ボトルネックは人間が見て決めるところに移る

人間の判断を、机の前のまとまった時間から切り離す。実際にレビューが入力されたのは病院の待合室だった

なので今回作ったものの半分は、スライドそのものではなくスライドをレビューするための道具だった

9日間の時系列

9/8 準備一式をAIに渡す: 原稿検討のハブ、スライド案30枚、図解収集39点、主催者の進行資料 ← 実はここが一番厚い。次の「0.」で戻る

9/9 通しのストーリードラフト(知的生産性の向上→自由の拡大)

9/10 (1)Keynoteドラフト25枚 (2)スマホでレビューする仕組み(→2.) (3)多様な候補15枚と4択レビュー(→1.)

9/11 レビューを受けて「公開データと、確かめたい問い」を軸に全体を組み替え

9/12 12回目の生成版で確定(25枚・20分想定)

9/13 当日は24枚・16分38秒。その日のうちに録音を文字起こししてAIに読ませた

9/14 実際の発話と準備稿の差分を分析

9/15 質疑を踏まえた加筆版35枚。テキストとバイナリで分かれていたrepoを1つに統合

9/16 35枚のまま4枚(p26・p27・p29・p32)の本文を加筆して配布

0. その前に: この9日間でできたわけではない

時系列は9/8の「準備一式をAIに渡す」から始まったが、渡せる状態のものが既にあった、というのがこの節

渡した一式自体、8/31にCosenseのページ1枚から始めて、複数のsessionで9/7まで育てたもの

蓄積層

Cosense /nishio 26,095ページ(2026-09-07の実数。ほかにprivate 409ページ)

ページの作成年は2007年から分布していて、2018年以降は毎年2,000〜3,900ページ増えている

図はGyazoに貼られ、ページの文脈の中にある。「過去の画像フォルダ」ではないのが効く

wiki森(目的ごとに作った独立のLLM Wikiの集まり) 45 wiki・3,926ページ(2026-09-06の一括import時点)

dd2030-wiki、broad-listening-book-wiki、考察の連載19本など、過去に調べて考えた結果の到達点

接続層

自作ツールgraspが、Cosenseのexportと各wikiをLLMから引ける形にしている。本文だけでなく行レベルの逆リンクと2-hop related

講演準備の直前(9/4-9/8)にgrasp側を直している

bulk importが15,000ページで約34時間かかっていたのを分オーダーに、 read --refresh を追加、1.14.2として公開

wiki森45/45を ~/.grasp/grasp.sqlite へ一括import。ここまでやって「渡せる」状態になる

発表準備のために道具の方を直す。道具が自分のものだとこれができる

結果として何が起きたか: 図解収集が9/5に39枚

grasp local store(当時25,898ページ)から講演関連の図解・スクショを集め、 figures/ にGyazo ID名で保存(27MB)、スライド番号へ割当

各図に「どのページの唯一の図か」「他のどの資料で再利用されたか」が付く。これは画像からは出てこない、リンクグラフからしか出てこない情報

例: COPY/情報洪水/DIGESTの3コマ図はブロードリスニングページの唯一の図で、他の3つの資料でも再利用されている → だから「定番図」だと分かる

上が2023年『情報処理』に載せた原図、下が2024年のマニフェストでの使用例(下部にCC0表記)。この2枚を並べる価値があると判断できるのは、再利用の履歴がページ側に残っているから

✔=目視確認済み、無印=ページ文脈からの推定キャプション、と確信度を分けてある

これを作っているのは、会話で分かったことをwikiに書き戻すfile backの習慣

会話は使い捨てだが、file backすると次の会話の入力になる

原稿検討.mdは§4.1から§4.9へ、複数のsessionにまたがって育った1本のハブ(最終的に42KB)

素材があるのではなく素材が意味づけされてリンクされているのが効く

ここでの失敗も記録しておく: 要約が役割を落とし、次の段がそこを埋めた

自己紹介のスライドに「Plurality Tokyo主催」と書かれていた。主催したことはない(2023年の参加者＋Audrey Tang基調講演の翻訳者。主催は別の方)

3段階で劣化していた

①ソース(ChatGPTとのねりねりログ): 「2023年のPlurality Tokyo、Audrey Tangの講演翻訳、『PLURALITY』翻訳を通じて、この問題に「ブロードリスニング」という名前を得た」 ← 役割語はどこにもない

②AIの要約: 実績の箇条書きとして「・Plurality Tokyo」と並置 ← 「を通じて名前を得た」という関係が消えて、項目だけが残る

③スライド化: 自己紹介の箇条書きには役割が要るので「主催」を補完 ← ここで創作が確定し、出荷物に載る

犯人は最終段ではなく中間段。要約で関係が削ぎ落とされると、後段がその隙間を埋める

同じことが2日後にもう一度起きた

「ブロードリスニングなどの可視化手段」→「BL推進」。例示をカテゴリと同一視する圧縮

→ 規律にした: 「AなどのB」をAに縮めない、load-bearingな引用は原文ママで使う

対策として検討ハブの「注意点」に書いたこと

経歴・役割語(主催/創設/代表/リーダー/翻訳/寄稿/参加)は正典=Cosenseの自己紹介の表現をそのまま使う。確認できないなら役割語を書かず「関わった」に留めるか、項目ごと落とす

GPTが出した数値(818人、58トピック、1,200時間、21,348件…)は一次ソースで裏取りしてから原稿に載せる → これが3.のevidenceファイルにつながる

期間表現(「20年近く追ってきた」)は、年を確認するか、期間表現の方を落とす

蓄積があるほど、AIは「それらしい隙間」を埋めたくなる。役割語を補完で創作しない

1. 候補は、選ぶためではなく捨てるために作る

9/10にAIが15枚の候補スライドを作った。通し講演の一部ではなく、比較して捨てるための候補集合

過去の原稿検討・図解収集・構成案・読み直しメモから、主題と見せ方の軸をつけて15通り

例: 「1%の意見を1%読む」「声のトレーサビリティ」「細則と一律禁止」「制約の探索」「アカデミアにも、バイアスがある」

番号はC01〜C15。AI側では「C02-04、C07-08、C09-10、C11-13は同じ枠に置ける別の入口」という比較の構造を作っていた

判定は4択「本編に欲しい/別の講演で使う/作り直す/不要」+自由コメント

結果: 本編に欲しい5枚、不要2枚、未判定8枚

これを書いておかないと、次のターンのAIが「残りは却下されたもの」として扱ってしまう

採用された5枚は一本の論にならない。そこからAIが構成案を出し、実際に通して話して決めた

そして、この比較の構造はレビューする側に届いていなかった

構造があったのはAI向けのREADMEと、カードのtheme欄(「少数意見」など)。レビュー画面は1枚ずつのページ送りで、出るのはタイトル・画像・原稿・その1枚への問いだけ。themeは描画していない

つまり人間からは「これ欲しい？」を15回聞かれたのと同じ。比較のために作ったのに、比較のUIになっていない

7件で止まったのはこれが理由かもしれない。「AとBのどちらか」なら判断は速く、迷いも残らない

向きが0.と逆なのが面白い。0.は人間の記録の隙間をAIが埋めて創作した。こちらはAIが作った構造が人間に届かなかった

境界を越えるのは、相手が見る面に書かれたものだけ。AI向けの文書に構造を書いても、レビュー画面に出なければ存在しないのと同じ

2. レビューの入力は、スマホで受けて、版に固定する

入力されたのは机の前ではなく、病院の待合室だった。外出先の待ち時間が判断の時間になる

1と同じ仕組みを、完成稿のレビューにも使った。スライド画像をタップ拡大→原稿を読む→OK/NG/コメント

音声入力もできるようにしたが、一度も使わなかった。作った機能と、使われた機能は違う

病院の待合室で使う時に音声入力はしないわな

初回の25枚では22枚に入力があり、うち17枚は文章コメント付き

9/12時点で、完成稿の5つの版に対しコメント23件・入力イベント255件

仕掛けとして効いたこと

入力と一緒に、そのときのPDFのSHA256とページ画像のハッシュを保存する

旧版へのコメントを新版へ自動転記しない。どの版に対する「ここ直して」なのかが消えない

保存イベントと、refごとの最新値を別テーブルにする。書き直し途中の保存が混ざるのでイベント数をコメント数と数えない

単独レビュアー前提。端末に未送信が残ることがあるので、DBの件数=入力した件数ではない

コメントを入れただけではAIは動かない。「保存コメントを読んで差し替え案を作って」と別途頼む

レビューと修正を切り離したのは正解だった。入力中に資料が変わるのが一番困る

3. 数字には根拠ファイルを貼る

スライドの数値ごとに evidence.md / evidence.json を作り、計算条件と一次資料を保存する

AIに資料を作らせるときの最大のリスクは、嘘の文章ではなくもっともらしい数字

台帳に「間違えやすいもの」を書いておく

21,348(2025年参院選の公開PRから抽出した論点)は論点数であって人数ではない

母子手帳の群は173論点・全体の0.81%。173人が言ったという意味ではない

1万人の声を1人10分で聞くと208日(1日8時間換算)

モデルと実測を混ぜない。Zipf分布の図は模式モデルであって実測ではないと明記する → zipf-broadlistening

同じ「上位100群のカバー率」(前半で出したZipfの図)でも、モデルの前提が違えば67.0%にも88.3%にもなる。前提を書かない数字は比較できない

AIが便宜的な分母のまま「種類の50%」と答えてしまった例も、撤回の経緯ごと残してある

4. 生成と手編集の境界を決める

PPTXはコード生成。assemble.py → build.mjs → PPTX。グラフはネイティブチャート7個、表2個

文章を画像にしない。PowerPointでそのまま編集できる形で出す

→ 数値の差し替えやレイアウト変更を何度でもやり直せるのが、この方式の利点

ただし人が手で編集した版は、もう再生成しない

各段のsha256と編集方針を引き継ぎファイル(handoff.json)に残し、それを正典にする

例: 「意見を、聞き逃す」の読点を人が削った。意図は読めるが、だからといって他ページまで直さない

「より良くしました」と言って全体を再生成するのが一番やってはいけないこと

変更したページと内容を明示して返す。人間がどこを再レビューすればいいか分かる形にする

9/16の加筆では9枚に差分が出たが、XMLを整形して比較すると内容が変わったのは4枚だけ

残りはPowerPointの保存による改行位置の違い。サイズ差・mtime差は変更の証拠にならない

5. 話し終わってからが後半

準備稿(25枚版)6,868字/20分想定(343字/分)に対し、実際は8,416字を16分38秒(506字/分)

録音の文字起こしと、準備稿を突き合わせる

その場で加わった話が8件。これは今日しか記録されていないので、拾わないと消える

数値の言い間違いが3つ(208日→「280日」など)、主張が逆になった箇所が1つ(散布図を「一粒が一人の意見」と言った。論点数を人数と言ってしまった)

ところが、この突き合わせ自体が比較対象を間違えていた ← 実演も兼ねた教訓

準備稿(25枚)には、当日話されなかったスライドが2枚あった。AIはそれを「16分38秒に押し込む圧力で落ちた」と解釈して分析を書いた

実際は当日の手編集で事前に削除されていた。完成版は24枚。話さない予定だったのだから、落ちたのではない

handoff.jsonの変更記録は「p13の修正」「ページ番号: 19を追加、20と24を修正」だけで、削除そのものが記録されていない

人間がGUIで削った操作が台帳に残らず、後段のAIがその空白を因果で埋めた。0.の3段階劣化と同じ型

観察として残るのはここまで: 事前に削ると決めた論点が、質疑では複数の質問で問われた

→ 質疑を踏まえた加筆10枚を作り、35枚版にした。当日の回答／AIの草案／後から自分で書いた加筆、を区別して記録する

会場マイクが1本なので、会場側の話者は録音からは復元できない

✅確定/❓推定/⬜不明 の凡例をつけて確信度を落とさない

推定のまま「誰々が言った」に昇格させない。外に出す文章では逐語引用も断定的な帰属もしない

6. ハマったところ(実務)

フッターのページ番号は <a:fld> ではなく静的テキストだった。後からスライドを挿入しても振り直されず、7枚ずれていた

PowerPointのAppleScript書き出しは、成功を返すのにファイルを作らないことがある

Keynote経由でPDFにすると版面が変わる(グラフの軸ラベルが潰れ、吹き出しが消えた)

headless LibreOfficeは日本語フォントとグラフ表示がだめだった

プレビューツールの表示崩れを原稿の問題と取り違えて本文を削らない

7. 持ち帰れる形

候補は捨てるために作る。1案を磨かせるより、15案を作らせて人間が捨てる方が速い

レビューの入力は版に固定する。どの版へのコメントかを失うと、後で全部やり直しになる

数字には根拠ファイルを貼る。特に「人数」と「件数」

人が触ったファイルは再生成しない。境界をファイルに書いて、次のセッションのAIに渡す

話した記録を次の入力にする。落ちたものと、その場で足したものの両方を拾う

書かれていることと、起きたことは別。今回3件出た: 音声入力(実装したが一度も使われず)、準備稿の2枚(話す予定として書かれていたが発表前に削除済み)、比較の構造(AI向け文書にはあったがレビュー画面には無かった)

READMEの「〜できる」は実装の記述であって、人間に届いた記録ではない。使われたかどうかは別に確かめる

この方式のコスト

スライドそのものより、レビュー機構と台帳の方に手間がかかっている

台帳を書かないと、次のセッションのAIが同じ間違いをする。台帳は人間のためというよりAIのための資料

15候補のうち判定が返ってきたのは7件。人間の判断帯域は、道具を作ってもやはり足りない

この解説ページの下書きはClaude Codeが制作repoの一次ソース(作業ログ・台帳・レビューJSON・文字起こし差分)から作った