Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
続・成果物は「作品」、PMは「キュレーター」
Search
shinya
July 14, 2026
78
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
続・成果物は「作品」、PMは「キュレーター」
https://kddi-agile.connpass.com/event/398191/
shinya
July 14, 2026
More Decks by shinya
See All by shinya
Deliverables Are "Works of Art", PMs Are "Curators"
es0612
0
28
成果物は「作品」 、PMは「キュレーター」〜プロジェクトのフェーズに合わせてコン テキ スト管理しよう〜
es0612
1
300
Featured
See All Featured
How Software Deployment tools have changed in the past 20 years
geshan
0
34k
Large-scale JavaScript Application Architecture
addyosmani
515
110k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
133
19k
Reflections from 52 weeks, 52 projects
jeffersonlam
356
21k
From π to Pie charts
rasagy
0
230
Ruling the World: When Life Gets Gamed
codingconduct
0
280
Done Done
chrislema
186
16k
WCS-LA-2024
lcolladotor
0
680
Facilitating Awesome Meetings
lara
57
7k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.8k
Lightning Talk: Beautiful Slides for Beginners
inesmontani
PRO
2
600
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.8k
Transcript
続・成果物は「作品」 、 PMは「キュレーター」 〜AIが「学芸員」になった美術館の、半年間の運営術〜 2026.7 | KAG AI Week 第2回
| KDDI Agile Development Center 江間 新也
自己紹介 江間 新也 プロダクトデザイン部 POリード 大手製造業でのエンジニア / PdM 経験を経て、現在はアジャイル開発の現場で PO支援・戦略設計を担当。AI活用によるプロ ダクト開発プロセスの効率化に取り組んでいる。
今日は、この作品の「続編」を展示します SHINYA EMA 前回登壇(2026.2 KAG AI WEEK 第1回) 成果物は「作品」 、PMは「キュレーター」 〜プロジェクトのフェーズに合わせてコンテキスト管理しよう〜 p.2
前回のあらすじと、積み残した課題 主張 1 主張 2 主張 3 キュレーションの方針はプロジェクトのフェーズで変わる ── だから
とことん、きれいにしよう。という話でした。 課題① キュレーションが属人的 構造化・投入のやり方が、私の頭の中にしかない 課題② 手動の出し入れはスケールしない 情報の収集・整理・投入が、全部手作業 あれから半年 ── 結論、課題はほぼ解決しました。 議事録・設計書・チケット… あらゆる成果物は 「作品」 作品を選別・配置して 価値を最大化する、PM/POは 「キュレーター」 きれいにするほど 応えてくれる AI は 「最良の鑑賞者」 ただし今度は、 「任せたからこそ」の新しい問題が出てきました。今日はその話です。 p.3
今日持ち帰ってほしいこと AI の役割 鑑賞者 → 学芸員 観るだけでなく、収集・整理・展示までやる 私たちの役割 キュレーター →
館長 任せた仕事を観測し、要所で裁定(ジャッジ)する ── 任せた仕事は、放っておくと少しずつ劣化していきます。だから 「観測と裁定の仕組み」もセットで渡すのがポイントです。 1 キュレーションを、AIに渡す 属人的だった整理・投入を「スキル」として形式知化した話 2 任せたからこそ起きた問題 ──「鮮度」と「品質」 4つの問題のうち今日はこの2つを深掘り(安全・確度は Appendix で持ち帰り) 3 キュレーターから、館長へ 人間の仕事は「書く」から「裁定する」へ変わる p.4
1. キュレーションを、AIに渡す 属人的キュレーションの形式知化
収蔵庫を引っ越し、学芸員に鍵を渡した BEFORE(2月)── 人が運ぶ美術館 AFTER(現在)── 学芸員が動く美術館 収蔵 集める 人 各ツールから手動エクスポートし、Google Drive
の収蔵庫へ運搬 AI Confluence / Jira がそのまま収蔵庫(SSoT)── 「運搬」という工程が消 えた 整理 構造化する 人 フォルダ構成・命名を考え、人間の手で構造化 AI 台帳(ページID・定数・ルール)に沿って、Claude が構造化・投稿 取り出し 文脈を渡す 人 人間が選んで NotebookLM / Gemini に投入(都度、手作業) AI Claude が MCP 経由で収蔵庫と双方向に読み書き ── 自分で取りに行く 利活用 鑑賞する 人 運搬と整理で消耗し、残った時間で活用 人 人間はここに集中 ── 内容の確認・壁打ち・意思決定 人間の持ち場が、 「運搬と整理」から「確認と利活用」へ移りました。 これが引っ越しの一番の成果だと思っています。 p.5
手順を「スキル」に書き、繋いで使う 議事録作成・週次サマリー・会議準備・壁打ち… 約 30 本 の定型ワークフローを Markdown の手順書(スキル)として記述。全スキルが同じ型に従う: 0 文脈を読む
プロジェクト台帳と 鮮度ルールを必ず最初に読込 → 1 収集 関連する議事録・チケットを 収蔵庫から取得 → 2 生成 表記統一・用語補正込みで 成果物を作成 → 3 展示 重複チェックの上で 収蔵庫へ投稿 → 4 振り返り AI自身がセルフレビューを 記録(第3章で詳述) 効いたのは単発より「接続」 ──「取り出し系」×「展示系」のスキルを繋ぐと、一連の業務がまるごと流れる: 例: 会議準備 直近 2 週間の文脈だけ抽出 鮮度フィルタで古い情報を遮断 → 論点を整理 前回アクションと突合 → 会議用の資料に展示 相手に合わせた見せ方で出力 属人化していた「私のやり方」が誰でも読める・直せるチームの資産に。 人間の作業はほぼ「完成品のレビューと承認」だけになりました。 p.6
2. AI学芸員と起きた、4つの問題 鮮度・品質・安全・確度 ── 今日は「鮮度」と「品質」を深掘り
任せた途端に出てきた、4つの問題 キュレーションを任せると、 「任せたからこそ」の問題が出てくる。美術館の運営に例えると: 1 鮮度 会期ルールのない展示 今日 深掘り 展示(コンテキスト)は放っておくと古びる。古い作品で AI
が間違える。 2 品質 学芸員の眼は確かか 今日 深掘り AI がプロジェクトをどれだけ正しく理解しているか、誰も測っていない。 3 安全 収蔵庫の鍵の管理 → Appendix 鑑賞者だった AI が「展示する側」になった。書き込み事故は仕組みで防ぐ。 4 確度 贋作の鑑定 → Appendix AI が生む「洞察」には、それっぽいが根拠の弱いものが混ざる。 どれも「AIの賢さ」だけでは防げず、仕組み(運営ルール)で防ぐ必要がありました。 p.7
「鮮度」── コンテキスト汚染に、会期ルールを作る 1 鮮度 2 品質 3 安全 4 確度 起きたこと 2週間前に完了したタスクを、AIが「進行中のタスク」として議事録に記載。 古い情 報と新しい情報が
区別なく混在し、判断を誤らせる。 対策:3層鮮度モデル すべての情報を「いつ時点か」で 3 層に分類し、扱い方をルール化。 全スキル共通で この尺度を使う。 層 期間 扱い 直近 2週間以内 主要コンテキストとして無条件で利用 中期 2〜6週間 テーマに関連する場合のみ。 [中期: MM/DD更新] ラベル付与 過去 6週間超 明示的に必要な場合のみ。矛盾したら 常に新しい方を優先 「迷ったら新しい方」という単純明快な矛盾ルールがよく効いて、AIの判断のブレが目に見えて減りました。 p.8
「鮮度」── AIの「更新」と、人間の「確認」を区別する 1 鮮度 2 品質 3 安全 4 確度 台帳は AI が自動で最新化してくれる。でも、それをそのまま信じ続けると 間違った自動更新まで信じてしまう。そこで、日付を
2 種類に分けた: 更新日 AI が書き換えた日 =「学芸員の申告」 ≠ 鮮度が回復するのは「確認日」が進んだとき だけ。 AIがどれだけ更新しても、館長の検印 がなければ「新鮮」とは認めない設計にして います。 $ 毎朝の自動チェック [鮮度警告] 継続課題セクション 7.2 確認日: 05/22 → 明日2週間超過 推奨: 中身を確認して検印を とくに確認日が古いところは「1回ヘルスチェックしよう」のサインとして使っています。自動化しても、鮮度管理のところで人間がループに残る仕組みです。 確認日 人間が中身を 確かめた日 =「館長の検印」 p.9
「品質」── 理解度テストで定点観測する 1 鮮度 2 品質 3 安全 4 確度 AIの理解の間違いに気づくのは、たいてい誰かが成果物を読んで指摘した後。 そこで発想は「健康診断」── 症状が出る前に、同じ問診を隔週で行う: 5問の標準化質問
組織体制 / 意思決定 / タスク進捗 / 仕様変更 / 予定 → 手元の台帳だけで回答 最新データは見せない → 実データと突合 正答率をスコア化 → 時系列で記録 劣化を検知 4月上旬 4月中旬 4月下旬 体制変更の直後 5月上旬 5月中旬 5月下旬 6月上旬 計画週次化の直後 発見:劣化は「組織が動いた直後」に起きる 落ちた 2 回は、いずれも体制変更・計画サイクル変化の直後。現実の変化速度に台帳が追 いつけていなかった。 対応:変化が速い期間は、鮮度ルールも速くする 週次化した期間は鮮度の閾値も 2 週間 → 1 週間に短縮。観測がなければ気づけないまま 誤答を信じていた。 80% p.10 91% 87% 64% 78% 78% 76% 64%
3. キュレーターから、館長へ AI時代の PM/PO の役割
館長の仕事 ── 観測し、3つの「裁定」をする 観測のために、全スキルの実行後に AI自身に「セルフレビュー(日報) 」を書かせて蓄積。 溜まったら棚卸しして、人間が承認した改善だけを手順書に反映しています: セルフレビュー うまくいった点 /
つらかった点 / 改善案 → 蓄積 摩擦のあった実行だけ記録 → 棚卸し 3回繰り返したら構造問題 → 人間が承認 → ルール改訂 ここが「裁定」 実はここまでの話に、人間の仕事はすでに登場しています。名前をつけて整理すると、3つの「裁定」 : 1 鮮度の裁定 ◀ 鮮度②で話した「確認日」のこと AIが更新した台帳を人間が確認して、初めて「確認日」が進 む。鮮度の回復は人間の承認とセット。 2 書き込みの裁定 ◀ スキルの「展示」前の承認ゲート 外部への投稿・更新・削除は承認ゲートを通す。読み取りは 自律に任せ、ゲートはここに集中。 3 洞察の裁定 ◀ 壁打ちの結論の確からしさ(詳細 Appendix) AIの洞察・改善提案は「確定 / 棄却 / 追加調査」を人間が 判定。採用したものだけが資産になる。 PM/POの仕事は「書く」から 「裁定する」 へ。 AIの守備範囲が広がるほど、人間は判断の量と質に時間を使えるようになります。 p.11
きれいにする仕事ごと、AIに渡そう。ただし ── 「観測」と「裁定」の仕組みを添えて。 次の課題①:館長が属人化 「裁定」が私一人に集中している。チームで分担できる運営へ 次の課題②:仕組みの複雑化 凝るほどトークン消費・保守コストが膨張。 「軽く作って、育てる」へ 次回作、共同制作者募集中 まだ試行錯誤中。一緒に考えてくれる人、ぜひ話しましょう!
手順書・テンプレートはそのまま共有できます。まとめ早見表と「安全」 「確度」の話は Appendix にあります。 p.12
None
Appendix まとめ早見表/「安全」と「確度」の詳細 ── 質疑・持ち帰り用
まとめ:前回 → 今回の早見表 前回(考え方) 今回(運用) AI 最良の「鑑賞者」 (全部読む) 「学芸員」 (収集・整理・展示までやる)
人間 「キュレーター」 (選別・配置) 「館長」 (観測し、3つの裁定をする) 鮮度 概念の提示(展示物をしまう) 3層鮮度モデル+確認日(館長の検印)で仕組み化 品質 (出力を見て判断) 5問テストの定点観測で劣化を先に検知 安全 (読むだけなので事故なし) 読み取りは自律・書き込みは承認ゲート(詳細 A-1, A-2) 確度 (洞察は人間が書く側) AIの洞察は独立ソースの数で信頼度を判定(詳細 A-3, A-4) 合言葉 とことん、きれいにしよう きれいにする仕事ごと、AIに渡そう 仕組みはすべて Markdown の手順書+既存ツール(Confluence / Jira / Claude Code)の範囲で実現。特別なインフラは不要です。 A-0
「安全」── 鑑賞者が「展示する側」になった日 1 鮮度 2 品質 3 安全 4 確度 書き込みを任せると工数は劇的に下がる。一方で最大の心理的障壁は 「AIが勝手に、取り返しのつかない書き込みをするのが怖い」という不安です。 実際に、こんな 事故がありました:
a 中断したのに、作成されていた ── 投稿を中断・拒否しても、サーバー側ではページが作成済み。 気づかず再実行して二重投稿に。 b 同名タイトルの重複作成 ── タイトルの完全一致だけ確認していたが、日付違い・表記揺れの重複をすり抜けた。 c 確認なしの破壊的操作 ── フォルダ削除や台帳への誤った ID 記入が、確認なしで実行されかけた。 これらは「AIの賢さ」だけでは防げないので、仕組み(ガードレール)で構造的に防ぎます。 A-1
「安全」── ガードレール4点セット 1 鮮度 2 品質 3 安全 4 確度 1 自律度の宣言 スキルごとに「即投稿してよい /
承認後のみ / 投稿しない」を冒頭で宣言。 リスクが高い 操作ほど「明示的なGOがないと進まない」側に倒す。 2 dry-run の必須化 外部に書き込む全スキルに「投稿せず完成形だけ作る」モードを実装。 本番前に完成形の ままレビューできる。 3 投稿直前の2段階重複チェック タイトル完全一致 + 同じ親ページ配下の日付クロスチェック。 ヒットしたら更新 / スキ ップ / 別名を人間に確認。 4 プレビュー承認ゲート 書き込み前に完成本文をビルド → 全文プレビュー → 承認。 差分だけの承認では不十分、 が運用で得た教訓。 原則は一行: 「読み取りは自律でよい。書き込みは承認ゲートを通す」 。過度なゲートは生産性を削るので、このメリハリが大事でした。 A-2
「確度」── AIの洞察には「贋作」が混ざる 1 鮮度 2 品質 3 安全 4 確度 議事録やアンケートから「ユーザー理解(インサイト) 」をAIに抽出させると、量は出る。 ただ「それっぽいけど根拠が弱い・思い込み」が混ざります。意思決定に使 う情報なので、これが一番危ないところです。
特に危険: 「件数主義」の罠 同一会議で同じ人が 3 回言っただけでも、素朴に数えると「3 件の根拠」に見えてしま う。 多く言及された = 確からしい → 独立した別ソースが収束した = 確からしい 鑑定の原則 美術館でいうと 贋作鑑定 見た目(もっともらしさ)ではなく、 来歴(ソースの独立性)で判定する A-3
「確度」── 鑑定のための 3 つの精度レバー 1 鮮度 2 品質 3 安全 4 確度 1 一次データ接地
── 戻って、数える 議事録の主張は「二次情報」にすぎない。アンケート自由記述などの生データに戻って実際に数え、 出現率と分布で裏取りする。接地できない回は「議事録のみ」と正直 に明示する。 2 反証ハント ── 「偽なら何が見えるか」を必ず問う 各インサイトに「これが偽なら何が観測されるか」を立てて能動的に探す。 見つかれば信頼度を下げる。反証を探していない洞察は、高信頼を名乗れないルール。 3 独立ソース三角測量 ── 独立した情報源の数で信頼度を決める 独立 3 ソース収束で「高」 、1 ソースなら「低」+確度を上げる追加質問を必ず生成。 同一会議・同一話者の重複言及は 1 ソースと数える。 意思決定者が「この洞察をどこまで信じてよいか」を一目で判断できるようになりました。 洞察は作って終わりではなく、期限付きの見直し(確定 / 棄却 / 追加調査)を回 しています。 A-4