20261110 NaITE39 AIとひとりで働く 統合版

206 Views

November 10, 26

スライド概要

2026年11月10日開催のNaITE勉強会 Vol.39のセッション資料です.
https://nagasaki-it-engineers.connpass.com/event/402144/

JaSST'26 Hokkaidoでの特別講演で扱わなかった論点についての資料です.

profile-image

個人事業主「クオリティアーツ(Quality Arts)」代表。ソフトウェアやシステム開発の伴走支援を主とし、スタートアップから大手メーカー、公共まで幅広く活動。組織・チーム・個人を対象に、技術導入、エンジニア教育、プロセス改善、経営層やCxOの支援している。近年はDX/AI文脈の組織整備やリスキリング、品質経営や経営戦略まで、立場や課題に応じて支援。

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

(ダウンロード不可)

関連スライド

各ページのテキスト
1.

AIと ひとりで 働く 〜今後に向けた, わたしの現在地 と みんなの論点〜 池田 暁 クオリティアーツ 代表 NPO法人ASTER 理事,NaITE 代表 JaSSTʼ26 Hokkaido 特別講演+勉強会拡張 NaITE#39 2026/11/10(火) 大阪

2.

アジェンダ 自己紹介 はじめに 第1部 「ひとり」で,AIとどう向き合うか 第2部 広がっていく論点 おわりに 2026/11/10 © Quality Arts,Akira Ikeda 2

3.

アブストラクト 私は個人事業主として,IT企業に対し経営や開発改善,育成など多岐にわたる協創・伴 走支援を行っています.クライアントは大企業からスタートアップ,地方の中小企業まで, 相手も経営者から開発現場までと多様です.この活動をひとりで成立させるうえで,AIは すでに欠かせない道具となっています. 本講演は二部構成です. 前半では,「わたしの実践」の現在地を紹介 します.道具立てに特別なものはありませ ん.伴走者・コンサルタントとして一番大切な“考えること”に集中するために何をAIに任 せ,何を任せないかについて,その線引きを中心に述べます. 後半では,多様なクライアントとの対話から見えてきた「みんなの論点」を紹介 しま す.対話の関心は,AIをどう使うかという技術的な話題から,文化・人間・組織へと移り つつあるように見えます. 本講演は事例発表でも技術解説でもなく,答えを提示するものでもありません.その かわり,本イベントの各セッションで議論を広げるための「観点」をいくつか持ち帰れ るよう構成 しています. あえて抽象的 な話を主としますが,一日の議論の入口として思考を広げることに役立て ば幸いです. 2026/11/10 © Quality Arts,Akira Ikeda 3

4.

ご注意 • 時間と進め方について – 本資料は,事前にお読みいただく前提の参考資料です – 当日は講演の上映はなく,19:10〜20:30のディスカッションが主です – 本編(第1部・第2部)は,JaSSTʼ26 Hokkaidoでの30分の講演がもとです • 内容について – 「ひとり」が前提です(個人主義の話です) – 事例や答えはありません,個人のルールや作法,今後の論点を紹介します – Howの話はしません • ナラティブ的に書いているので,「キーワードだけ印象に残してください」 • 議論について – 後半の「みんなの論点」を出発点に,参加者全員で議論します – 本編で扱わなかった9つの論点も「勉強会拡張」として収録しています 2026/11/10 © Quality Arts,Akira Ikeda 4

5.

自己紹介 経歴・活動・著書のご紹介 2026/11/10 © Quality Arts,Akira Ikeda 5

6.

プロフィール • 名前:池田 暁(いけだ あきら) • やっていること: – ソフトウェアエンジニアリング分野 伴走者 – ときどきもの書き • 主な所属: – クオリティアーツ(個人事業主) 代表 – NPO法人ASTER(ソフトウェアテスト技術振興 協会) 理事 – 長崎IT技術者会(NaITE) 代表 – 公益財団法人長崎県産業振興財団 CO-DEJIMAス タートアップメンター • 出身: – 長崎県長崎市 • 信念: – 「ソフトウェア品質技術の力で世界を幸せに」 – 「利他,自責,有言実行」 – 「なければ作ればいいじゃない」 2026/11/10 © Quality Arts,Akira Ikeda 6

7.

クオリティアーツでの活動 – スタートアップ・ベンチャーを含む中小企業から大企業に対してソフトウェアエンジニアリ ングの強化や改善について伴走支援 – ソフトウェア開発技術や品質技術の導入に関するコンサルティングや技術顧問,新人含む技 術者の教育や育成,全社レベルでの組織作り・プロセス改善など,ご相談内容に応じて幅広 く支援 – そのほか,国内の技術力向上のために,諸学会や技術イベントでの講演,寄稿や書籍執筆, コミュニティ活動にも積極的に取り組んでいる コンサルタント 伴走者 請負でも,派遣でもない. 納品物は「考えた結果」 相手が「見ている先」も「見えていない先」も, あらゆることを想定しておく. 判断の材料と方向を提供する仕事 安全に,気持ちよく走ってもらう支援をする仕事 伴走支援や非常勤CxOなど対応しています.お気軽にお声がけください! 2026/11/10 © Quality Arts,Akira Ikeda 7

8.

主な業務経歴(企業所属) • 株式会社日立情報通信エンジニアリング(情報通信) – 組込みシステムの設計,品質保証業務を経て,技術支援部門にてテス ト技術を中心にアジャイル開発やMBD/SPL等の導入を支援 • 株式会社日立ハイテク(医用) – 自社製品(医用系機器)の開発プロジェクトに品質,テストに関する リードエンジニアとして参画し,テスト管理業務やプロセス活動に従 事 • 日立Astemo株式会社(自動車) – Tier1サプライヤの自社製品開発プロジェクトに参画,テスト管理業 務やプロセス活動に従事するほか,全社を対象としたテストプロセス 改善や研究による新技術導入,教育など品質確保や効率向上,技術高 度化に従事 • 株式会社ビズリーチ(HR系SaaS) – SQE(Software Quality Enabler)として,ソフトウェア品質に関 する改革やソフトウェアエンジニアリングの導入 • 株式会社マネーフォワード(fintech系SaaS) – CQO(Chief Quality Officer)として経営レベルで品質を管掌 • 株式会社NDKCOM(受託開発系) – CTO(Chief Technology Officer)として経営レベルで技術を管掌 • ただいま充電中 (大量インプット期間中) 2026/11/10 © Quality Arts,Akira Ikeda 8

9.

主な学会やコミュニティ委員 • 品質管理学会 代議員,2024年〜 • NaITE(長崎IT技術者会) 代表,2015年〜 • 長崎QDG 実行委員長,2015年〜 • Agile Japan 長崎サテライト 実行委員長,2016年〜 • 公益財団法人長崎県産業振興財団 CO-DEJIMAスタートアップ メンター,2021年〜 • 筑波大学大学院 非常勤講師,2007年度・2008年度 • NPO法人ASTER(ソフトウェアテスト技術振興協会) 理事, 2006年〜 • JaSST 東海 アドバイザ,2009年〜 • 日科技連SQiP 運営委員 • WACATE(ソフトウェアテストワークショップ) 初代実行委員長, 2007年〜2009年 • AFFORDD(派生開発推進協議会) • 日本品質管理学会・ACM 運営委員,2010年〜 正会員,2002年〜 • その他,技術コミュニティ委員やアドバイザ歴任 2026/11/10 © Quality Arts,Akira Ikeda 9

10.

自己紹介:主な著書・訳書,論文(一部) • 著書・訳書 – 共訳:実践ソフトウェアエンジニアリング 第9版,オーム社,2021 – 共著:SQuBOK Guide V3,オーム社,2020 – 共著:[改訂新版]マインドマップから始めるソフトウェアテスト,技術評論社, 2019 – 共著:ソフトウェア品質知識体系ガイド―SQuBOK Guide V2,オーム社, 2014 – 共著:Software Testing “ManiaX” vol.1 〜10,WACATE Books,2009 〜15 – 共訳:ISTQBシラバス準拠 ング,2008 ソフトウェアテストの基礎,センゲージラーニ – 共著:ソフトウェアテスト入門 押さえておきたい《要点・重点》,技術評論 社,2008 – 共著:ソフトウェア品質知識体系ガイド―SQuBOK Guide,オーム社, 2007 – 共著:マインドマップから始めるソフトウェアテスト,技術評論社,2007 – その他,ソフトウェア・テストPRESS等テスト関連の雑誌やWeb媒体の連載 等 • 特許 – 「車載向け統合テストケースのコードクローン解析に基づくテストケース効 率生成技術の開発」 2026/11/10 © Quality Arts,Akira Ikeda 10

11.

宣伝:実践ソフトウェアエンジニアリング(第9版) • 2021年12月1日に「実践ソフトウェアエンジニアリン グ(第9版)」の翻訳書を出版しました • 顧客に提供される最終的な品質はすべての要素の掛け算 で決まります.故に,全エンジニアが一般教養として 持っておくべき体系(のひとつ)です • 世界的にはITエンジニアを志す,大学生の一般教養的教 科書です • AI時代を生き抜く一般教養 ソフトウェアエンジニアリング・スタンダードの第9版 本書は米国においての第1版が発行(1982年)されて以来,世界45万部を超えるベ ストセラーの最新刊である第9版の邦訳書です.ソフトウェア同様,改良が続け られているソフトウェアエンジニアリングの「最良の手法」を解説している書籍 であり,現役のソフトウェアエンジニアならびに学生諸氏におすすめする1冊で す. 原書:Roger S. Pressman, Bruce R. Maxim, Software Engineering,McGraw-Hill, 2020 翻訳:西 康晴,水野 昇幸,池田 暁,井芹 久美子, 井芹 洋輝, 岡澤 裕二, 金子 昌永, 衣笠 駿, 鈴木 一裕, 根本 紀之, 松尾 和昭, 山﨑 崇 2026/11/10 © Quality Arts,Akira Ikeda 11

12.

最近公開したもの・取り組んでいること • 企業の方向け – 地方中小企業向け 新卒ITエンジニア 新卒研修シラバス • https://quality-arts.com/?p=285 • 新卒エンジニアの方向け – 小説(連載中):地方中小IT企業 新卒ITエンジニア向け 小説 • 新卒エンジニア、観察ノートを開く(上巻) 観察を、始める – https://ncode.syosetu.com/n5612mf/ • 新卒エンジニア、観察ノートを開く(中巻) 両輪を、回す – https://ncode.syosetu.com/n5272mg/ • 新卒エンジニア、観察ノートを開く(下巻) 道を、選び取る – https://ncode.syosetu.com/n7647mh/ • 学生の方向け – 記事(連載中):エンジニアの卵に贈る、就活の書 • https://note.com/ikedon0505/n/n364a3374b725 ぜひ活用してください! 2026/11/10 © Quality Arts,Akira Ikeda 12

13.

はじめに 本講演のポジション確認と,進め方・ゴール 2026/11/10 © Quality Arts,Akira Ikeda 13

14.

再度本講演でのポジション確認 • わたしは「コンサルタント」であり「伴走者」である • わたしは,ひとりで活動している,つまり個人主義的な働き方 • 組織の中の人間と違い,特定組織に専従せず,多様な現場を横断して見る – だから今日は,みなさんとは違う角度から観点を紹介できる • その他 – 現在は事業経営層や経営層とのお仕事がほとんど • なので,経営の要素としての品質やテストを考えている 2026/11/10 © Quality Arts,Akira Ikeda 14

15.

この講演についての整理 • どういう講演か – 事例発表でも技術解説でもない – 当日について,AIの議論に幅を持たせるための「観点の提供」 • 3つの確認 – 第一に,あくまでも「 ひとり活動 」としての話です – 第二に, 観点の提供であり,解法や正解は配りません – 第三に,30分の講演がもとなので エッセンスのみ です • つづきは当日のディスカッションで! 2026/11/10 © Quality Arts,Akira Ikeda 15

16.

進め方とゴール 第1部 第2部 ひとりコンサルであり伴走者で あるわたしが,AIをどう使って いるか,その一例の紹介 多様なクライアントとの対話か ら見えてきた,「AIをどう使う か」のその先の論点 【ゴール】 みなさんが当日のディスカッションで, 様々な観点から議論できるように助けること 2026/11/10 © Quality Arts,Akira Ikeda 16

17.

第1部 「ひとり」で, AIとどう向き合うか 量はAIに,質は自分に ― 3つの実践を紹介 2026/11/10 © Quality Arts,Akira Ikeda 17

18.

第1部でお話することの要点 第1部では,「わたしの実践」の現在地を報告します.道具立てに特別なものはありま せん.伴走者・コンサルタントとして一番大切な“考えること”に集中するために何をAIに 任せ,何を任せないかについて,その線引きを中心に述べます. • 伴走者は「量」と「質」でできている • AIに任せるための「運用ルール」と「作法」,そして「複眼」 • 「考えることに時間を使う」ために割り切ったAI環境 2026/11/10 © Quality Arts,Akira Ikeda 18

19.

第1部 実践1 AIで量の問題に立ち向かい, 質と向かい合う AIは量の問題を解決し, 質に取り組むことを強化する 2026/11/10 © Quality Arts,Akira Ikeda 19

20.

伴走者は「量」と「質」できている わたしのこと • 量の問題 – あらゆることを想定しておくには,大量の情報が要る – さらには,経営に近い相手と走るなら,品質やエンジニアリングの知識だけでは足りず,ビジネス や政策の動向といった情報まで必要になってくる – 主なアウトプットとしては調査資料一式,これをまとめるだけでもかなり大変 – コンサルファームなどの組織は数の論理(組織:人数や知識ベース)で立ち向かっているが,わた しは数の論理が使えない • 質の問題 – 情報を集め終わったら,それらをもとにどれだけ考え込めるかが勝負 – 主なアウトプットは提案資料・説明資料一式,やはりまとめるのは大変 – ひとりだと情報を集めるだけで全体の工数が尽きる,考える時間を確保することを優先すると調 査が甘くなるというジレンマ • 量→質の順序は変わらないから,質のために量の手を抜くと,結局質が悪くなる • 量と質は行ったり来たり( 量の追加爆発 ) – 質を行っている最中に,追加の量の問題が起きる.シーケンシャルにはすすまないのが現実 2026/11/10 © Quality Arts,Akira Ikeda 20

21.

ひとり伴走者の不利をAIで解決 わたしのこと • 量の問題をAIの力で劇的に改善 – これまでは,集めるだけで工数が尽きる.裏取りの工数確保も頭が痛かった • 資料を探す,中身を確認する,情報を整理する,エビデンスを確保する,事実確認のための他の情 報も探しに行く,さらには別の追加調査…,量と質の行ったり来たりの工数… – AIを使うことで,調査や裏取り,情報整理といった工数が劇的に下がり,質のために考える 工数を数倍取れるようになった • AIで量の問題を解決することで,質の工数が足りないという問題が解決できる • さらに質には,もう一つの効き方がある,それは複眼の導入 – ひとりにはレビューしてくれる同僚がいない, セルフレビューには認知バイアスの壁がある – ひとり活動は複眼効果を得ないままに結果をクライアントに提示するということ • なので,セルフレビューを帽子の被り直しで無理やり対応するということが起きていて,うまくい かないこともあった • わたしにとってのAIの導入で得られる最大の恩恵は,工数削減より「考える」ことの時 間が増えたことに加え,質の磨きに貢献する複眼効果の獲得 である 2026/11/10 © Quality Arts,Akira Ikeda 21

22.

第1部 実践2 考えることと複眼効果を 得るためのAI運用ルール わたしの「考える」「複眼」を意識した運用ルール 2026/11/10 © Quality Arts,Akira Ikeda 22

23.

AIの運用は徹底して実利主義で • AIの運用は徹底して実利主義 • ただし実利主義は無規律ではない – CLAUDE.mdには「 ソフトウェアエンジニアリングをフル活用しろ 」と書いており,AIとの やり取りは事実ベース・工学ベースで行うことを義務付け – コンテキスト文書として各種BOKをまとめたものを揃えてある • 守秘にも線引きがある – ひとりコンサルは守秘契約を個人で背負う. – NDAの結び方で守りつつ,顧客の状況に合わせる – クライアントの情報を使わない技術情報は,自分のAIで.クライアントの情報を扱うときは, クライアントからアカウントを供与してもらい,そちらで. – 情報の線引きを,アカウントの線引きとして物理的に実装している. • 運用の注意深さではなく,構造で守る(現状は第三者的な技術伴走が多いので後者の出番は少) • AIとの共同作業そのものを,ソフトウェアエンジニアリングの規律の下に置いている 2026/11/10 © Quality Arts,Akira Ikeda 23

24.

わたしの運用ルール(2026年6月時点) # 種別 1 思想 わたしは 「考える」ことを使うことを優先 し,雑多なことは全てAIに任せる. ただし量と質のバランス感覚は手放さない. 2 進め方 タスクは細かく, 高速に回す 3 進め方 環境構築に時間を使うくらいなら,細かくプロンプトを送って仕事を先に進める Cowork程度で十分. 環境構築の楽しさにハマって顧客への価値提供のスピードを落とすのはもったいな い.ターミナルを使って「なんとなくできている」錯覚も,イケてるエンジニア的 な高揚感も要らない 4 規律 AIとのやり取りは 事実ベース・工学ベース で行うことを義務付け. 守らないといけないプロセスは,工学技術を徹底的に使わせる 5 規律 CLAUDE.mdは最低限の7項目だけ:「感想想像不要・事実のみを優先」「 ソフト ウェアエンジニアリングをフル活用しろ 」「Web検索・調査の結果はローカル保存 し次回はそれを見ろ」「忖度不要,率直に」「バージョン管理とレビューは徹底」 「議事録を残せ」「言われなくても定期的にメモリや資料をクレンジング」 6 規律 コンテキスト文書として各種BOK をまとめたものを常備する (ISTQBシラバス・SQuBOK・SWEBOKなど) 2026/11/10 © Quality Arts,Akira Ikeda 24

25.

わたしの運用ルールつづき(2026年6月時点) # 種別 7 規律 守秘とAI利用の線引き:NDAの結び方で守りつつ,顧客の状況に合わせる. クライアント情報を使わない技術情報は自分のAIで. クライアント情報を扱う場合は,クライアントからアカウントを供与してもらい, そちらで. 情報の線引きをアカウントの線引きで物理的に実装する 8 道具 スライドは基本自作 .「魂が入っていない仏は,コンサルでは使い物にならない」 9 道具 入力は基本音声.良いマイクを買いましょう. キー入力はエンター誤爆があるが,音声はそれがないし,長文指示がしやすい. 10 道具 ライセンス料はケチらない. 残りのトークン量に怯えると,作業の大胆さが失われ る(もちろん限度はある) 2026/11/10 © Quality Arts,Akira Ikeda 25

26.

そして,絶対に譲らない作法 • ひとり伴走者(個人事業主)は,自分の名前と思考が商品である. • 考えるべきこと・オリジナルは絶対に自分で考える. – 考えることそのものをAIに丸投げしない.丸投げした成果物は「AIが考えたもの」であって, わたしのものではない. オーサーシップは,手放さない . – ※AI自動生成したスライドで話すのは難しくないですか? • ほとんどの場合,クライアントへの提案・説明スライドは自作する – AIによる自動生成は便利だが,そのままでは相手に響かない – 「魂が入っていない仏は,コンサルでは使い物にならない」 運用ルール&作法のうえで,複眼効果を得る 2026/11/10 © Quality Arts,Akira Ikeda 26

27.

複眼とはすなわちレビューである • 基本, プロンプトは雑でいい – 「いまの作業を鑑みて,様々な立場からレビューア(専門家)を10人招聘し,10ラウンドレ ビューしろ.足りなければさらにやれ」とぶん投げる. • 基本, レビュースキルは作らない – 「よさげなスキルを使え」というだけ – スキルを作り込むのに時間を使うよりは,人数 回数で解決するほうがリーズナブル • ただしレビュー技法だけは明示的に教える&伝える – ほおっておくとアドホックレビューしかやらない – レビュータイプはISTQB(非公式レビュー/ウォークスルー/テクニカルレビュー/インスペク ション)+Wiegers・SQuBOK系(回覧式など). – AIレビューで特に効くのは,リーディング技法の実装,パースペクティブベース・リーディング とロールベース・リーディング,「10人招聘」はPBRの実装 – 技法の解説文書はコンテキストとして与える. • ISTQBシラバス・SQuBOK・SWEBOKを正典とする.ソフトウェアエンジニアリングの正典も • 「運用ルール:工学ベース」と「コンテキスト(正典)」でレビューとしての質を確保 エンジニアリング技術を,AI利用時でも徹底する 2026/11/10 © Quality Arts,Akira Ikeda 27

28.

第1部 実践3 環境について. 入口はSlack, LLMはClaude一本 わたしは「考えたい」のであって, 「AI環境を構築したい」わけではない. 2026/11/10 © Quality Arts,Akira Ikeda 28

29.

「考える」ことを優先した環境についての考え方 AI周りの環境は,「考えるための最小構成」に割り切っている • わたしは「すごく考えたい」のであって,「すごい環境をつくりたい」わけではない • 考えることより相対的に優先度が下がることは,多少の非効率さを割り切る • コンサル・伴走者が出す成果や価値は「クライアントにすごく考えた結果を,最速で わたしていくこと」 – クライアントにとって価値があるのは「考えた結果」であり,AI環境そのものは価値を生ま ない • ひとり活動にすぎないので,チーム活動レベルの環境はいらない – 最近流行っているひとり会社アーキテクチャも,わたしは個人事業主だからいらない – チーム活動だと,共通基盤が必要なので,環境整備の重要さは増す オーバーな環境は,考える時間を減らし, 複眼に使える時間も減る 2026/11/10 © Quality Arts,Akira Ikeda 29

30.

環境の全体像 わ た し の こ と • シンプルに,入口はひとりSlack – わたしの作業はSlackから始まり,その先に各ツールがぶら下がる Claude Claude Code 調査・整形・ドラフト プロトタイプ ひとりSlack (入口・結果の集約) ChatGPT / Gemini Google Workspace 外部レビューア 予定・メール・日報 矢印=「結果」がSlackに集まる向き.各種AIはbot / AgentとしてSlackに登録. • 過程と結果の分離,そして結果の一元化 – 個別のツールやクライアント環境には,結果に至る「過程」と「結果」の両方が保存されている. そのうち「結果」だけを,中央集権的にSlackへコピーする. – だから結果を確認するときは,Slackだけを見ればよい – ひとりで多数の案件とツールを回すための情報アーキテクチャ,これも「考える」に集中するため の仕掛けのひとつ.探す時間は価値を生まない 2026/11/10 © Quality Arts,Akira Ikeda 30

31.

使っているLLM • 使い分けはシンプルで, 基本はClaude一本 – 長文に強いことが選定理由(いまのところ.池田感覚では) • 普段の伴走・コンサルの調査やレビュー – Claudeのデスクトップアプリでプロジェクト+Cowork. • プロトタイプを作るとき – Claude Codeをターミナルで,ただし簡単なものならCoworkで済ませてしまう. • 移動中に仕込み作業などしたいとき – Claude モバイルのチャットやディスパッチを使うなど • レビューの厚みが欲しいとき – ChatGPTとGeminiを「Claudeから見た外部レビューア」として呼ぶ • その他のAI機能,LLM以外のツールに搭載されているAI機能は当然のように積極的に使っている – スケジュールやメールはGoogle Workspaceベースの管理 – SlackのAI機能を使った自動日報はかなり助かっている – ナレッジベースはいまのところはひとりNotion 2026/11/10 © Quality Arts,Akira Ikeda 31

32.

ローカルLLMは使ってない よく聞かれますが,ローカルLLMは使っていません. • 理由 – 環境メンテナンス時間やPC資源を取られるし,モデルも古い – 当面はClaude本体のバージョンアップ・機能アップに乗っかるほうがリーズナブル – それが落ち着いてきたら他のAIやローカルLLMに広げていく.ひとり活動で現時点でそこま で広げるのは工数に見合わない,と割り切っている • なお空きPCで環境は作ってあるが,稼働率は低い.ほぼゼロ. – ローカルLLMは安い? • ローカルLLM用にPCやGPU,周辺機器や電力を考えると,安くないどころか高いのでは – メモリモリモリのPC一式に100万円〜,月の電力数万円消費と考えたら... – ローカルLLMが真に必要なのは,絶対に外部に出せない機密や技術を扱うこと • つまり企業内のセキュリティエリアにあるエッジLLMでしょうね – 今は,単なる趣味になってしまいそうな状況 2026/11/10 © Quality Arts,Akira Ikeda 32

33.

第1部のまとめ 「ひとり」で, AIとどう向き合うか 任せていることと任せていないこと,その線引き 2026/11/10 © Quality Arts,Akira Ikeda 33

34.

任せていることと任せていないこと 第1部では,「わたしの実践」の現在地を報告しました.道具立てに特別なものはあり ません.伴走者・コンサルタントとして一番大切な“考えること”に集中するために何をAI に任せ,何を任せないか について,その線引きを整理したのが下の表です. 任せること 任せないこと • 調査:大量の情報収集と「裏取り」 • 整形:ドラフト・体裁・定型ドキュメント • レビューの実行:レビューアの招聘(10人 10ラウンド) • コンテキストの作成:技法解説文書(正典か ら生成) • 結果の集約:Slackへ一元化 • 雑多なことの一切 • 考えること :オリジナル・思想・魂 • 問いを立てること :何を調べるか,なぜやる か • どう見るか :レビュー技法の指定 • 統合と最終判断 :出てきたものの検収 • 自分の名前で出すもの :オーサーシップ,ス ライド • 守秘の線引き :何をどのアカウントに渡すか AIに任せなかったことは,考えることと,問いを立てることと,最後の判断. こうして整理すると当たり前のように思いますが,最初のプロンプトは自分の考えと言え るようなものになっているでしょうか?考えを任せていないでしょうか? 2026/11/10 © Quality Arts,Akira Ikeda 34

35.

第2部 広がっていく論点 エンジニアリングだけでは解けない5つの論点 2026/11/10 © Quality Arts,Akira Ikeda 35

36.

第2部についての要点 第2部では,多様なクライアントとの対話から見えてきた「みんなの論点」を紹介しま す.対話の関心は,AIをどう使うかという技術的な話題から,文化・人間・組織へと移り つつあるように見えます. • 第2部では,IT企業の管理職以上がいま何に目を向け始めているかを紹介します • ただし,直接的な答えは提示しません.といいますか,できません (現在進行形だから) • 紹介する論点は,当日のディスカッションで使ってください 2026/11/10 © Quality Arts,Akira Ikeda 36

37.

第2部 論点の紹介の前に 工学・エンジニアリングだけでは解けない現実 2026/11/10 © Quality Arts,Akira Ikeda 37

38.

ある出来事 ̶ 2026年5月 社会のこと ネットではこう呼ばれました 「AIに仕事を奪われた野球監督」 わたしは,この表現は間違っていると思います. 起きたのは「AIによる代替」ではない. 文脈を持たないAIの字義通りの助言が,検証されないまま,現実の社 会システムを駆動した. 複眼のひとつであるはずのAIが,統合者のいない「単眼」の判断主体 になった. 2026/11/10 © Quality Arts,Akira Ikeda 38

39.

この問題はエンジニアリングだけでは解けない 社会のこと • ガードレール設計などは工学の分野で対応可能 • だが「何を問題とみなすか」「どこまでの介入が正当か」は工学の外にある. • 事件そのものの是非は司法の領域として脇に置いておくとして, • AIは設計された振る舞いのままに,児相も警察も法と手続きの通りに動いた 各要素がそれぞれのルール通りに動いて,それでも全体は望まぬ結果になった • ソフトウェア開発に置き換えれば,部品が全部正しくても系は壊れるという現象 • 法(外のルール)への準拠だけでは防げない失敗がある. 埋めるのは律(内側から自分に課す規範)である 工学,つまりエンジニアリングだけでは解けない問題に対して, どう考えていくかを議論していかなければならない 解法は“いまは”ない,だから“論点” 2026/11/10 © Quality Arts,Akira Ikeda 39

40.

第2部 論点の紹介 対話から生まれた14個のうち,本編では5つ 論理は考慮せず,放談的に 2026/11/10 © Quality Arts,Akira Ikeda 40

41.

最近の対話から出てきた論点(14個・本編ではうち5つ) # 論点 問 A 認知 AIを,何者として向き合うか B 健康 AI時代の新しい「病気」に,備えているか C 法と律 ルールが追いつかない時代,規範は誰が立てるのか D 技術 自動化の教訓を,繰り返していないか E 役割 旧来の工学はAIに吸収されていく F 人財パイプライン ジュニアの仕事が消えたら,後継者はどこで育つのか G 文化 チーム主義と個人主義,開発文化はどこへ行くか H ガバナンス 組織では「どの人間が」統合と判断を握るのか I 格差 AI活用の格差(組織規模・地域・人)に,品質はどう向き合うか J 地政学 AIスタックの分断,技術選定が政治判断になる K AI投資の経済学 この過熱は,鉄道バブルの再演か L 電力・物理制約 ソフトウェアの話が,物理と地域の話になる M 知財・著作権 創作と模倣の境界という,古典的な問い N セキュリティ 攻撃側も「複眼」を手に入れる 2026/11/10 © Quality Arts,Akira Ikeda 41

42.

論点A【認知】AIを何者として向き合うか 社会のこと • わたしたちは,対話するものを「人」として扱うようにできている – 擬人化はほぼ普遍的な人間の反応.だからそれは正しいことなんだろうと思う – ただし 問題なのは,反応の有無ではなく,その上に判断の主権まで明け渡してしまうこと • AIは機械なのに人間であると思ってしまう,ずれた認知のまま活用を考えるから苦しい – 人だと思うから,忖度や遠慮,過剰な期待と失望という対人コミュニケーションの悪い面が 持ち込まれる – だからわたしは,当たり前ですが,AIはあくまで機械と思い, 絶対に愛称をつけない • 名前をつけた瞬間に愛着がわくから • とはいえ,従来の機械扱いもまた間違いであろう – 「対話する道具」は人類が初めて手にした道具で,わたしたちはまだこれの正しい呼び名 (定義,扱い方,etc)を手に入れていない 2026/11/10 © Quality Arts,Akira Ikeda 42

43.

論 点 B【 健 康 】 AI時 代 の 新 し い 「 病 気 」 に , 備 え て い る か 社会のこと • 論点Aと関連して,健康や病気の話がある. • 認知の歪みは,効率の話にとどまらず健康の問題になる – 人だと思って関わり続ければ,これまで人間対人間で起きてきた心の不調が,AI相手にも生 まれてくるだろう – そしてAI特有の,まだ名前のない新しい不調も生まれてくるはずだ – 「AIを使っていて心の不調に陥る」という話が,珍しくなくなる未来は十分あり得る • これは,エンジニアリングだけでは解けない問題の最たる例だと思います – 内閣府消費者委員会の調査では,10代女性の52.4%が,日常生活での生成AIの使用目的に 「悩み相談」と回答している – また 「人間関係や人付き合いに関するAIのアドバイス」を信頼している割合は,10代女性 で約6割,10代男性で約5割 に上る 2026/11/10 © Quality Arts,Akira Ikeda 43

44.

論点D【技術】自動化の教訓を再現していないか みなさんのこと • いまのAI活用は,かつて自動化ツールを手にしたときのバッドプラクティスを再現して いないか • 何でも自動化する.悪いプロセスを自動化して,悪さを加速する,等 • 自動化の基本に立ち返って適用すべきことを考えても良い あの頃の自動化 いまのAI活用??? 何でも自動化する 何でもAIに投げる 悪いプロセスを自動化して,悪さを加速 悪いプロセスにAIを載せて,悪さを加速 効果を測らずツールを回す 効果を測らずAIを回す 「自動化の基本」という教訓が残った その教訓を,わたしたちは使っているか? 2026/11/10 © Quality Arts,Akira Ikeda 44

45.

論点E【役割】旧来の工学はAIに吸収されていく わたしたちのこと • 開発・テストプロセスで,AIが吸収していくのは,形式化・言語化されている作業 (仕様からのテスト設計,定型ドキュメント,突合など) – 形式化された作業から順に吸収されていくとして,ソフトウェアエンジニアリングに残るの は何だろうか? • 残るのは,文脈の把握,意図と価値の判断,問いを立てること,複数視点の統合 • 短期的な見立てとしては,建築のメタファーがある. – エージェント技術がこのまま向上すると, AIエージェントはビルダー(優秀な左官・職人) になり,人間のソフトウェアエンジニアは建築家(建築士)になっていく のかもしれない. – 設計意図を描く人と,それを高速・高品質に形にする存在.ではQAエンジニアは??? • 建築の世界には,工事監理や建築確認検査という品質の職能がすでにある. • ソフトウェアの世界で,それに相当するものはある? 別の職能を作るべき? 必要ない? 2026/11/10 © Quality Arts,Akira Ikeda 45

46.

論点E【役割】旧来の工学はAIに吸収されていく わたしたちのこと • 「これからのエンジニアは何を学ぶべきか」への,わたしの見立て – 流行のツール知識は,AI自身が吸収するか,モデルの進化が陳腐化させる – だからこそ, ソフトウェアエンジニアリング,コンピュータサイエンス,リベラルアーツと いった「揺るがない基本」の相対価値が,これから上がっていく. • 関連する論点(論点F) – この論点には,経営の現場で動いているもう一つの面「 人材パイプラインの断絶 」がある • ジュニアの仕事をAIが吸収していくと,後継者はどこで育つのか • 海外では若年層の採用減少が実証され始めている(スウェーデンではAI曝露度の高い職業で22〜25 歳の採用が5.5%減). – メタファーで言えば, 左官の見習いは,どこで修行するのか 2026/11/10 © Quality Arts,Akira Ikeda 46

47.

論点G【文化】チーム主義と個人主義 わたしたちのこと • わたしは個人だから,個人主義としてAIを使うしかなかったが,みなさんはチーム主義 • わたしの仮説「 AIは使えば使うほど,人を個人主義に向かわせる 」 – 個人が「AIチーム」を編成し,人間は単一の専門職からマルチタレントになっていくのではない か • ここで言うマルチタレントとは,何でも自分の手でできる人のことではない. • 複数の専門領域にわたって,AIに的確な指示を出し,出てきたものを検収できる人のことだ – 実行の深さをAIが埋めるので,従来のジェネラリストに付きまとった「広く浅く」のペナルティが 消える. • だから広さが,そのまま強みになる(逆に,単一領域の深い実行力は吸収リスクに晒される) – そして領域を跨ぐ土台になるのが,先ほどの「揺るがない基本」で,基礎がある人ほどマルチタレ ントになれると思う • 開発スタイルはどこへ行くのか. – 個人主義化していくチームメンバーを,チームとして再統合するスタイルか.それとも個人主義を 突き詰めるスタイルか. • 個人がAIで複眼を作れるなら,人間の他者の眼は不要になるのか. わたしはAIで複眼を作ったが,それでも人間の眼は要ると思うのか? 2026/11/10 © Quality Arts,Akira Ikeda 47

48.

第2部のまとめ 広がっていく論点 認知・健康・技術・役割・文化 ― 5つの論点を,明日からの対話の種に 2026/11/10 © Quality Arts,Akira Ikeda 48

49.

お渡しした5つの論点 第2部では,多様なクライアントとの対話から見えてきた論点を紹介しました.対話の 関心は,AIをどう使うかという技術的な話題から,文化・人間・組織へと移りつつあるよ うに見えます. # 論点 問 A 認知 AIを,何者として向き合うか B 健康 AI時代の新しい「病気」に,備えているか D 技術 自動化の教訓を,繰り返していないか E 役割 エンジニアリングに残るのは何か.テストエンジニアは何をする人か G 文化 チーム主義と個人主義,開発文化はどこへ行くか 工学,つまりエンジニアリングだけでは解けない問題に対して,どう考えていくかを議論 していかなければならない. 解法は“いまは”ない,だから“論点” みなさんが持っている論点は何でしょう? 2026/11/10 © Quality Arts,Akira Ikeda 49

50.

勉強会拡張 本編で扱わなかった9つの論点 論点C・F・H・I・J・K・L・M・N 2026/11/10 © Quality Arts,Akira Ikeda 50

51.

勉強会拡張:本編で扱わなかった9つの論点 # 論点 問 C 法と律 ルールが追いつかない時代,規範は誰が立てるのか F 人財パイプライン ジュニアの仕事が消えたら,後継者はどこで育つのか H ガバナンス 組織では「どの人間が」統合と判断を握るのか I 格差 AI活用の格差(組織規模・地域・人)に,品質はどう向き合うか J 地政学 AIスタックの分断,技術選定が政治判断になる K AI投資の経済学 この過熱は,鉄道バブルの再演か L 電力・物理制約 ソフトウェアの話が,物理と地域の話になる M 知財・著作権 創作と模倣の境界という,古典的な問い N セキュリティ 攻撃側も「複眼」を手に入れる 2026/11/10 © Quality Arts,Akira Ikeda 51

52.

論点C【法と律】規範は誰が立てるのか 社会のこと • 本編の「ある出来事」で見たのは,各要素が法や手続きの通りに動いても,全体は望ま ぬ結果になりうるということ • 法(外のルール)は事後的で,技術の速度には追いつかない.だから当面は,内側から 自分に課す「律」で埋めるしかない • ルール自体は,いま急速に動き始めている – EU AI Act:2024年発効.禁止行為は2025年2月,汎用AIの義務は2025年8月から段階適 用(出典:欧州委員会) – 日本:AI推進法が2025年5月成立・9月全面施行.ただし基本法・理念法で,企業への罰則は ない(出典:内閣府) • つまり法は「方向」は示すが,「現場の作法」までは決めてくれない.その隙間を律が 埋める – 品質の世界には規格やガイドラインの蓄積がある.それは律の下敷きになるのではないか • 議論:その律は,誰が立て,誰が更新するのか – 個人の作法か,企業の規程か,業界の合意か.どの層で決めるのが妥当か.あなたの組織に 明文化された「律」はあるか 2026/11/10 © Quality Arts,Akira Ikeda 52

53.

論点F【人財】後継者はどこで育つのか わたしたちのこと • 役割論(論点E)の続き.形式化された作業から順にAIが吸収していくと,ジュニアが 担ってきた仕事が先に消える • 若年層の雇用への影響は,すでに実データで見え始めている – Stanfordの研究(2025):AI曝露の高い職種で,22〜25歳の雇用が相対的に約13%減(出 典:Stanford Digital Economy Lab/ADP) – ただし減っているのは「自動化」用途.「補助」用途では減っていない.鍵は自動化か拡張 か • ここにジレンマがある.実務の入口をAIが埋めるほど,「実務で覚える」という育成の 王道が痩せていく – 左官の見習いは,どこで修行するのか – わたしは本編で「揺るがない基本」ほど価値が上がると述べた.ではその基本は,どこで身 につけるのか • 議論:育成の入口が消えるなら,育成の設計をどう作り直すか.「実務で覚える」を何 で置き換え,誰がコストを負うのか 2026/11/10 © Quality Arts,Akira Ikeda 53

54.

論点H【ガバナンス】統合と判断は誰が握るのか みなさんのこと • 第1部で「統合と判断は手放さない」と述べた.これは,ひとりだからできる話でもあ る • 組織では,統合と判断を「どの人間が」握るのかが,途端に難しくなる – 権限と責任が曖昧なままAIを走らせると,誰も統合していない「単眼」になりうる.本編の 「ある出来事」は,統合者が不在だった帰結とも読める • これを仕組み化する標準は,すでに登場している – ISO/IEC 42001(AIマネジメントシステム,2023,認証可能),NIST AI RMF (Govern/Map/Measure/Manage).2025年時点で義務ではないが採用が進む(出典: ISO,NIST) • ただし規格は「枠」を与えるだけ.最後に統合し,責任を負う「人」は,規格の外にい る • 議論:あなたの組織で,AIの出力を最終的に統合し,責任を負うのは誰か.その人に, 判断に必要な情報と時間は与えられているか 2026/11/10 © Quality Arts,Akira Ikeda 54

55.

論点I【格差】品質はどう向き合うか わたしたちのこと • AI活用の力は,組織規模・地域・個人で大きくばらつく.これは能力差というより,前 提(資源・データ・仲間)の差だと思う • 格差は,実データで見え始めている – WTO ICC調査(2025):AI利用は小規模企業41%に対し,大企業は60%超(出典: WTO/ICC) – OECDも地域間の分断(emerging divides)を指摘(出典:OECD) • わたしは地方(長崎)で個人として活動しているので,この格差は肌で感じる • 品質の視点で怖いのは,「AIを使える現場」と「使えない現場」で品質水準が二極化す ること.品質保証は中立の技術に見えて,格差を広げる側にも,埋める側にもなりうる • 議論:品質保証は,格差を広げる側か,埋める側か.地方・中小・個人に届く品質支援 は,どんな形なら成立するか 2026/11/10 © Quality Arts,Akira Ikeda 55

56.

論点J【地政学】技術選定が,政治判断になる 社会のこと • ソフトウェアは「良いものを選べばよい」はずだった.だがAIスタック(半導体・モデ ル・クラウド)は,国家間の分断の対象になっている – 米国は先端半導体の対中輸出規制を継続・変更.2022年以降,規制対象や条件が政治で動く (出典:米商務省BIS,議会調査局CRS) • つまり,技術選定が純粋な技術判断ではなく,政治判断になりうる – 使えると思っていたモデルやチップが,明日も使える保証はない.供給が止まるリスクを設 計に織り込む必要がある • 個人や中小に,国家の力比べはコントロールできない.できるのは「依存の分散」と 「乗り換えやすさ」を用意しておくことくらいではないか • 議論:あなたの技術選定は,地政学リスクを織り込んでいるか.特定のモデル・チッ プ・クラウドに,抜けられないほど依存していないか 2026/11/10 © Quality Arts,Akira Ikeda 56

57.

論点K【経済】鉄道バブルの再演か 社会のこと • いまのAI投資は,どう見ても過熱している.これは19世紀の鉄道バブルの再演ではない か – 鉄道は過剰投資で多くが破綻したが,敷かれたレールは残り,後の経済を支えた • 見落としがちなのは,「過熱」と「実装の難しさ」が同時に起きていること – MIT『The GenAI Divide』(2025):企業の生成AIパイロットの約95%がROIゼロ(300 事例)(出典:MIT) – IMFやイングランド銀行も,AI相場の過熱を警告(出典:IMF) • バブルが弾けても,計算資源やモデルという「レール」は残るのかもしれない.問題は, 弾けたときに自分の事業が生き残れるか • 議論:AI前提の計画は,投資の波が引いても成立するか.過熱した価格や無料枠に,事 業の前提を預けていないか 2026/11/10 © Quality Arts,Akira Ikeda 57

58.

論点L【電力・物理】物理と地域の話になる 社会のこと • ソフトウェアの話だったはずが,いつのまにか電力と土地という物理の話になっている – IEA:データセンターの電力需要が2025年の約485TWhから2030年に約950TWhへ倍増し, 世界電力の約3%に(出典:IEA『Energy and AI』2025) • 電力確保は,もはや経営判断そのものになりつつある – Big Techが原子力に回帰.MicrosoftはThree Mile Island再稼働の長期契約,Google・ Amazon・MetaもSMR等に投資(出典:Fortune,IEEE Spectrum等) • 品質やアーキテクチャの議論は,これまで電力や環境をほとんど「与件」として扱って きた.それが,与件でなくなりつつある • 議論:品質・アーキテクチャの議論に,電力・環境コストの観点は入っているか.「速 い・正しい」だけでなく「効率が良い」も品質特性に入るか 2026/11/10 © Quality Arts,Akira Ikeda 58

59.

論点M【知財】創作と模倣の境界 社会のこと • 生成AIは,創作と模倣の境界という,きわめて古典的な問いを再燃させた • 学習データと著作権をめぐる訴訟・和解が,各国で相次いでいる – New York Times対OpenAI/Microsoft(2023年提訴,2025年時点で審理継続)(出典: 米連邦地裁S.D.N.Y.) – Bartz対Anthropic:2025年9月に著作者と和解,最低15億ドル(1冊約3000ドル).合法 取得の学習は「変容的」,海賊版取得は否定(出典:NPR等) • 現場の実務問題は,抽象的な是非より「来歴を説明できるか」に集約されていく気がす る – 生成物の権利,学習データの出所,再利用の可否.これらを説明できないと,納品物として 使いにくくなる • 議論:あなたの成果物は,学習・生成の来歴を説明できるか.「AIが作った」ことを, どこまで開示すべきか 2026/11/10 © Quality Arts,Akira Ikeda 59

60.

論点N【セキュリティ】攻撃側も複眼を持つ みなさんのこと • 第1部で,複眼(レビュー)はこちらの武器だと述べた.だが同じ複眼を,攻撃側も手 に入れている – 攻撃の自動化・高速化・巧妙化(説得力あるフィッシング,脆弱性探索の効率化など) • すでに実害が出ている – ArupのディープフェイクCFO詐欺(2024):偽の役員ビデオ会議で約2,560万ドルを騙取 (出典:CNN,世界経済フォーラム) • 怖いのは,防御と攻撃が「同じ道具」で軍拡競争になること.守る側の優位は続かない – 「AIで守る」だけでなく「AIで攻められる」前提で,テスト・レビューを設計する必要があ る • 議論:あなたのテスト・レビューは,AIを使う攻撃者を想定しているか.なりすましや 社会工学に,品質保証はどこまで踏み込むべきか 2026/11/10 © Quality Arts,Akira Ikeda 60

61.

参考・出典(勉強会拡張分) 勉強会拡張 • 本セクション(勉強会拡張分)で触れた主な出典 – C 法と律:欧州委員会「EU AI Act」/内閣府「AI推進法」 – F 人財:Stanford Digital Economy Lab(Brynjolfsson ら,2025)/ADP – H ガバナンス:ISO/IEC 42001:2023/NIST AI RMF – I 格差:WTO ICC(2025)/OECD – J 地政学:米商務省BIS/米議会調査局CRS – K 経済:MIT『The GenAI Divide』(2025)/IMF – L 電力:IEA『Energy and AI』(2025)/Fortune・IEEE Spectrum – M 知財:NYT対OpenAI/Microsoft(S.D.N.Y.)/Bartz対Anthropic(2025和解) – N セキュリティ:Arupディープフェイク事件(CNN/世界経済フォーラム,2024) • ※ 詳細URLは別途一覧を提供します. 2026/11/10 © Quality Arts,Akira Ikeda 61

62.

おわりに 2つのまとめと,わたしがいま見ている論点 2026/11/10 © Quality Arts,Akira Ikeda 62

63.

第1部と第2部のまとめ • 第1部のサマリ – AIはわたしを増幅する機械 – 「考える」に集中するために向き合っている – 数の論理の壁が消え,圧倒的な量が質に貢献する – 複眼を得る – ただし,統合と判断は手放さない • 第2部のサマリ – 論点を5つ紹介しました. – 認知:AIは人でも従来のツールでもない,では何者か – 健康:AI時代の新しい「病気」に,わたしたちは備えているか – 技術:自動化の教訓を,わたしたちは繰り返していないか – 役割:エンジニアリングに残るのは何か,テストエンジニアは何をする人か – 文化:再統合か,個人主義の徹底か 2026/11/10 © Quality Arts,Akira Ikeda 63

64.

おわりに,わたし個人の話 ̶ いま見ている論点 わたしのこと • わたしはいま,『人文知』を大きな論点として捉えています • いま起きているのは産業革命を超えるかもしれない変化で,ソフトウェアだけでなく社会と文化 を変えている • 前回の大変動は産業革命とフランス革命という「二重革命」 – 社会を対象とする新しい知,社会学を要請した • 大変動は,新しい学問を生む.今回も同じことが起きるのではないか – 現に,前述の事例のように,エンジニアリングだけでは解けない問題が現れている. – 法が追いつかないなら律を立てるしかない • 律を考えるのは倫理学や法哲学,まさに人文の領域である • AIにより答えのコストが下がった今,残るのは問いの質 – 人文知とは,問いの質を出すためのものごと(広義に人文・社会科学を含む) • 「問う力」を軸にしたリベラルアーツ再評価の動きは,企業の側にも出始めている 2026/11/10 © Quality Arts,Akira Ikeda 64

65.

おわりに,わたし個人の話(続き) わたしのこと • ただし,人文知としての知識を貯めるだけでは足りない. • 正確には,歴史や人文科学から行動モデルを学び,それを活用することが大切で,そ れは開発やテストといった領域でも必要になるはずだと思う. ( ここで言う行動モデルとは,ある状況でどう問い,どう動くかの型 のこと) • とするならば,AI時代のスキル獲得やリスキリングとは,ツールの習得ではなく,行 動モデルの切り替えのことなのかもしれない – 論点D「自動化の教訓に立ち返る」は,「過去から行動モデルを学び転用する」ということ • ただしこれらはわたしの実感からの話で,そこにはまだ解はない • 論点として,議論を進め,わたしとしての結論を見出していきたいと考えている 2026/11/10 © Quality Arts,Akira Ikeda 65

66.

モヤモヤしたと思います 〜わたしもです • みなさんモヤモヤしたと思います.わたしもモヤモヤしています. • 今はAI技術の進化が速すぎて,言語化した瞬間に古いものになる. • だからいまのAIとの付き合い方は,解法を求めるのではなく,論点を求めるのがよい とわたしは感じている. • 論点だけを押さえておいて,無理に言語化しない.今日答えを配らなかったのは,そう いう理由だ. • 質疑の時間を取らなかったのも同じ理由で答えが出にくいセッションだから. • その代わり,このあとトークセッションがあります • ラジオ番組の感覚でモヤモヤを語り合うセッションで,あそこでなら,あれこれ答えに つながっていく議論ができるのではとわたし自身楽しみにしています.興味ある方はぜ ひ. 2026/11/10 © Quality Arts,Akira Ikeda 66

67.

進め方とゴール 第1部 第2部 ひとりコンサルであり伴走者で あるわたしが,AIをどう使って いるか,その一例の紹介 多様なクライアントとの対話か ら見えてきた,「AIをどう使う か」のその先の論点 【ゴール】 みなさんが当日のディスカッションで,様々な観点から議論できるように 助けること 【観点】 ・個人主義の伴走者としての,AIの利用 量,質,運用ルール,作法,複眼(レビュー) ・14の論点(本編5つ+拡張9つ) 認知,健康,技術,役割,文化 2026/11/10 ・主語のラベル わたし,みなさん,社会,わたしたち © Quality Arts,Akira Ikeda 67

68.

Thank you! テストとは, もともとプロダクトへの問いを設計する仕事だ. みなさんは最初から「問いの専門家」である. AIに奪われる側ではなく,拡張される側だ. わたしがAIから複眼をもらったように, このセッションがみなさんの 今日一日の複眼のひとつになれば嬉しいです! 2026/11/10 © Quality Arts,Akira Ikeda 68