AIがコードも仕様も書く時代、現場は何に困っているのか

AI教育推進ミートアップ AIがコードも仕様も書く時代、 現場は何に困っているのか 2026年 5月 20日 オーティファイ株式会社 林 祥一

自己紹介: 林 祥一(Hayashi Shoichi) ◼ 1989年、(プログラムを書かないソフトウェアハウス)NTTソフトウェア入社 ◼ 1991年、富士ゼロックスのシステム技術研究所に入所 ➢ オブジェクト指向言語拡張によるマルチエージェントシステム, CSCWの研究などに従事 ⚫ ➢ Lispkit Lisp拡張による並列関数型言語Mulasame(SECDR-Scheme)の作者 1998年に試作システム商品化のため開発部門に異動。以降、文書/記録管理・コラボレーション支援・ワークフロー・内部統制・エン タープライズリスク管理等のプラットフォーム開発のアーキテクトおよび商品企画に従事 ◼ 2010年にHAYST法をお客様に伝授する役目を担ったことをきっかけに、コンサルティング活動を開始 ➢ ➢ その後、要求開発・ソフトウェア品質に領域を広げて製造系、金融系、通信・情報サービス系等60社以上にコンサルティング実績がある 2018年、ベリサーブ社を経て ◼ 2025年にアーティファイに入社 ➢ 現在は、これまで積み上げてきたコンサルティングの知見を、AIによってシステム化する取り組みに没頭中 ◼ ネット公開記事: ➢ ➢ ➢ https://qiita.com/sho1884 https://note.com/sho1884 https://www.veriserve.co.jp/helloqualityworld/media/search/?person=%E6%9E%97%E7%A5%A5%E4%B8%80 ◼ ネット公開ソフトウェア: ➢ NeoCEG: 原因結果グラフ法に基づくソフトウェアテスト設計ツール ⚫ ➢ https://neo-ceg.vercel.app/ NeoCombi: ペアワイズ法に基づくソフトウェアテスト設計ツール ⚫ https://neo-combi.vercel.app/ 1

• https://qiita.com/sho1884
• https://note.com/sho1884
• https://www.veriserve.co.jp/helloqualityworld/media/search/?person=林祥一
• https://neo-ceg.vercel.app/
• https://neo-combi.vercel.app/

私のプログラミングのルーツ 2

本日の内容選定で考慮した事 ◼ 過渡期特有の問題は取り上げない 新しい技術を学び、それを使い、 従来と同じことをやってしまう ◼ 現場で解決すればよいことは取り上げない ◼ 現場はあまり困っていないことが困ったこと ➢ AIと関係なく、元々困っていることは変わらず こちら側の手当てにも需要があるはずだが、 必要なリソースを簡単には調達できない ➢ そう簡単に変化しないから こちらに対する手当は既に大きな ビジネスになっている 第１の壁 変化を避ける傾向（行動レベル） 第２の壁 思考が抜け出せない傾向（認知レベル） ⚫ 現状維持バイアス（status quo bias） ⚫ 認知的固定（cognitive fixation） ⚫ 慣性（inertia） ⚫ 心的セット（mental set） ⚫ ルーティン志向（routine-oriented） ⚫ フレーム依存（frame dependence） ⚫ リスク回避的（risk-averse） ⚫ 自動思考（automatic thinking） ⚫ 習慣依存（habit-dependent） ⚫ パラダイムロック（paradigm lock） 3

目次 AI駆動開発の動向と影響 p.05 •実装技術を主戦場として生き残れるか 上方向に役割を移す （その１） p.14 •マネージャーになれってこと？ AIをマイクロマネジメントしてしまう困った人たち p.21 •やり方を任せられない病 仕様は書けないがコードなら書けるプログラマ p.28 •それって、頼む側から見るとヴァイブコーディングにほぼ同じなのでは？ マネジメントスタイルとハーネス p.41 •ダイナミックなプロセスであることは時代の要請 コードからコンテキストへ p.58 •フレーム問題の再来 上方向に役割を移す （その２） p.72 •システム思考・デザイン思考は時代の要請 観測能力向上を活かす p.94 •常時接続データ / VOC：ECサイト,SNS / AIとの会話 自動化とは、強制化である。 p.99 •アーキテクチャによる規制が静かに変えてしまうもの 4

I n q u i r y AI駆動開発の動向と影響 実装技術を主戦場として生き残れるか

Vモデルで見る現状のAIと新人開発者の得意領域 ◼ 現状のAIと新人開発者の得意領域は見事に重なってしまう 企画 「上流(コンサルやBA)へ 逃げろ」は本当か？ 現状の新人開発者が 得意なところ 運用 「検証やQAへ逃げろ」は 本当か？ 現状のAIが得意である（とされ、 注目が集まっている）ところ 6

Vモデルで見るAIの今後の進歩 ◼ 注目されていない領域でもAI活用は進んでおり、人間の作業を代替するのは時間の問題 企画 運用 現状のAIがここが得意な理由は、 最初の研究領域としての条件が一 番揃っているから 7

Vモデルで見る今後の人間の役割 ◼ 「どうやって作るか」が中心課題ではなくなっていく 多くの技術者は上方向に役割を移すことになるだろう （PM、PdM、ビジネスアーキテクトのような？） 企画 運用 「ボクなら、もっと 上手いやり方を考 え出せるけどね」 ここに人間が要らなくなるわけ ではない ただし、少数精鋭で十分なので、 技術スキルが高く、また研鑽を 積み続ける必要がある 理論に強い、あるいは技術に長けた 人材で構成される少数精鋭になる。 8

「才能の無駄遣い」といわれる人は次々に出てくるのできっと大丈夫 Minecraft: Redstone Computer (Interactive PC, Calculator, Day/Night Controller) https://www.youtube.com/watch?v=aQqWorbrAaY 9

• https://www.youtube.com/watch?v=aQqWorbrAaY

従来のソフトウェア工学が扱ってきた範囲 ◼ プロセスモデル: 従来のウォーターフォール型モデルと、近年の主流であるアジャイル型 プロセスの比較・解説 ◼ 要求エンジニアリング: 顧客の要求を分析し、ユースケースやユーザーストーリーとして 定義する工程 ◼ 設計: 外部設計・内部設計（アーキテクチャ設計やコンポーネント設計）について、モデ ル図（UMLなど）を用いて説明 ◼ 製造とテスト: プログラミング、単体テスト、結合・総合テスト、および品質保証の概念。 ◼ プロジェクトマネジメント: スケジュール管理、工数見積もり、リスク管理などの管理技 術 CSはサイエンスなので、基本的にここの領域 の仕組みや原理、理論、情報の性質を扱う。 だからある意味当たり前。 多くの新人は、ここ以外は何も勉強してきていない。 「もしかしたら授業で取り扱ったかもしれないが、憶えていない。」という。 10

従来のITSSやSFIAにも同様の問題 ◼ 従来のITSSやSFIAは「静的なフレームワーク」になっていて、現代的な観点からは、以下 のようなものが事実上こぼれ落ちてしまっている。 ◼ 「スケーリング」の動的な性質 ➢ 従来のフレームワークは「システムを完成させて納品する」という静的なデリバリーモデルが ベース ⚫ 欠落している視点: トラフィックの増大に応じてリソースを弾力的に伸縮させる（Elasticity）能力や、 分散システム特有の「部分故障を許容しながら全体を動かし続ける」といった動的なシステム運用・設 計の視点が極めて弱い ⚫ 実態: GoogleのSRE（Site Reliability Engineering）が重視する「エラーバジェット」や「トイルの 撲滅」といった概念は、既存の「ITサービスマネジメント」という項目の中では単なる「効率化」とし て埋もれてしまい、その本質的な価値が評価されない 11

従来のITSSやSFIAにも同様の問題(続き) ◼ 「不確実性」への対応（Safety-2:レジリエンス的な視点） ➢ GoogleやAWSのインフラは「壊れること」を前提に設計されている。ITSS等の標準は「壊さない こと（Safety-1）」を前提とした品質管理に寄っている。 ⚫ 欠落している視点: カオスエンジニアリングのような「あえて壊して回復力を高める」といったレジリ エンス（回復力）の領域は、標準化されたスキルの外側にある。 ⚫ 実態: クラウドネイティブな環境では「不確実性を制御する」スキルが必須。だが、標準化の枠組みで は「手順通りの確実な実行」が評価の軸になりがち この発想・考え方は、上の 世代にほとんどないので、 引き継ぐものがない 12

なぜ理論化が「停滞」しているように見えるのか ◼ 「再現性」と「定数」の壁 ➢ 学問は通常、境界条件を固定し、再現性を確保することで理論を構築します。しかし、現代の ハイパースケールな分散システムは、「ネットワークの遅延」「ハードウェアの個体差」 「ユーザー行動のゆらぎ」といった、理論化しにくい「動的な変数」が多すぎます。 ◼ 実験場の独占（大規模リソースの不在） ➢ かつてCSの進歩は大学のメインフレームから生まれましたが、現在は「実験場」そのものが巨 大テック企業に独占されています。数万台のノードを協調させ、秒間数百万リクエストを捌く 際に出現する「相転移」のような現象を研究するには、大学の研究室ではリソースが圧倒的に 足りません。結果として、理論が現象を予言するのではなく、「企業が作った動くもの（例： Spanner, Dynamo）」を後から学問が追認するという、逆転現象が起きています。 これって、普通の学問になるということでは？ 物理学など、多くの学問は「現象の記述」から始まる 数学のように、実機が存在する前にアラン・チューリングは「計算機」の概念を 作ったが、その方が特殊なアプローチと言えるかもしれない。 13

I n q u i r y 上方向に役割を移す （その１） マネージャーになれってこと？

（PM、PdM、ビジネスアーキテクトのような？） ◼ System of Systems(SoS), Scrum of Scrums AI時代のScrum of Scrums of Scrums 今後はここから スタート ISO/IEC/IEEE 21840:2019 Guidelines for the utilization of ISO/IEC/IEEE 15288 in the context of system of systems (SoS) Figure 6 — Degree of operational and managerial independence varies 従来はここの一員から スタート 15

新人もいきなり新しい意味でのマネージャー役割に ◼ AIがコードを書くので、新人に作らせる必要はなくなった。教育的効果を無視できないの で、これは継続している現場は多いが、純粋にコストになってしまったので、経営として 余裕がなくなれば切り捨てられるだろう。 ◼ 高度な知識と技術力を持ち、新しい技術開発をする技術者はこれからもずっと必要。優秀 な一人がリードして、チームが必要な作業をして支えるという体制が一般的だった。でも 作業部分はAIで十分。だから少数精鋭の体制が一般的になるだろう。 ◼ 日常的な時間軸の中で周りの諸先輩たちの仕事を観察する機会が激減するだろう。少しず つOJTで全体を理解して追いついていくような時間的余裕もない。 ◼ 作業をしながら学ぶ時間はなく、さっさと自分がリーディングできる ようにならないといけない。 それができなければ不要な人材ということになってしまう。 16

扱う対象領域、マネージャーの役割も大きく変わる ◼ 管理的作業が減少し、本来の判断と責任の役割が大きくなる。 ◼ ソフトウェアという『設計・コード・プロセスから成る体系的な人工物』を扱う技術から、 人間・組織・データ・ビジネス価値が複雑に絡み合う『エコシステム全体』を科学的・合 理的に制御する技術へ ◼ 従来の「箱物設計」のようなモデルでは対応できない、「都市計画」のような持続的かつ 進化的なエンジニアリングの領域 17

「巨大な都市計画」のような持続的かつ進化的な領域 ◼ 規模も複雑さもより大きく Figure 3 — Overview of an SoS Figure 2 Overview of a system NOTE This figure is reproduced from ISO/IEC/IEEE 15288:2015, Figure 2. ISO/IEC/IEEE 21840:2019 • Guidelines for the utilization of ISO/IEC/IEEE 15288 in the context of system of systems (SoS) • SoSは階層構造で記述されるのではなく、図3に示すように、 一般的なネットワークとして記述されることが多い。 クリストファー・アレクザンダー 『都市はツリーではない』 (1965年) 18

AI 時代のモジュール化と組織設計 ── 逆コンウェイのすすめ DSM ─ 設計の依存関係 R M1 M2 M3 TSM ─ タスク／組織の依存関係 M4 R R T1 T2 T3 T4 R コンウェイの法則 M1 M2 T1 （双方向に効く） T2 M3 T3 M4 T4 R: デザイン・ルール（共通の上流仕様） AI 時代＝エージェントへの役割割り当て AI エージェントに任せた瞬間、エージェントへの役割の振り方 が新しい組織構造になる。 ── そこで コンウェイの法則 が、人間相手より速く・無自覚に悪さをする。 暴走させないためのレバーが デザイン・ルール ── 学ぶ価値はここにある。 Baldwin, C. Y. & Clark, K. B. 『Design Rules: The Power of Modularity』 ／ 邦訳『デザイン・ルール ― モジュール化パワー』 19

組織・構造・プロセス AI 時代＝エージェントへの役割割り当て 『奥村 洋, 組込みソフト産業の実態と開発の課題 第4回 日本の組込みシステム 開発の 特徴と今後の展開, 46巻5号 情報処理2005年5月 』より Pixel Agents:クロード・コードのエージェントたちがアニメーション キャラクターとして生き生きと動き出す。 https://marketplace.visualstudio.com/items?itemName=pablodelucca.pixel-agents 20

• https://marketplace.visualstudio.com/items?itemName=pablodelucca.pixel-agents

I n q u i r y AIをマイクロマネジメントしてし まう困った人たち やり方を任せられない病

マイクロマネジメントは代表的なアンチパターン(人間相手の場合) ◼ 人間相手のマネジメントは、「手順（How）」ではなく「コンテクスト（Why）」と「期待 丸投げ（ネグレクト）にならないように、 値（What）」を共有するスタイルに移行している。 適切な委任（デリゲーション）の範囲を 設計することが肝要 1. 心理的安全性の低下と「学習性無力感」 • 人間には「自己決定権（自分の行動を自分で決めたいという欲求）」がある。 • 細かく指示されすぎると、モチベーションの消失、思考停止、責任感の欠如、当事者意識の喪失、 スキルの停滞:成長が止まる、などの問題が起こる。 2. スケーラビリティの限界（上司がボトルネックになる） • 意思決定の遅延: 上司の確認待ちで現場が止まる。リソースの浪費: 組織全体の生産性が下がる。 3. レジリエンス（復元力）の喪失 • VUCA状況では、現場での即興的な判断が不可欠。手順に固執すると、想定外の事態が起きた際に 応用が利かない。 • 「失敗を防ぐ（Safety-1）」ために手順を固めるのではなく、「状況に合わせて柔軟に成功へ導く （Safety-2）」ためには、現場の裁量が不可欠。 22

宣言型定義への移行は難しく、手続き的に考えてしまう ◼ 1980年代後半〜90年代、商用RDBMSとSQLが急速に普及する一方で、「集合を一度に扱う」 発想に馴染めず、従来通り一行ずつ手続き的に処理するプログラマが多かった。 ◼ 典型的な「手続き的SQL」の症状 1 カーソル多用症候群 一発のUPDATE文で済む処理を、わざわざカーソルで一行 ずつ取り出してループで回す。集合演算より「制御して いる感じ」が安心だった。 2 アプリ側でJOIN テーブルAを全件SELECT→ループ内で都度Bを単一SELECT。 今で言うN+1問題を「自然な書き方」として書いてしまう 人が多くいた。 手続き的: DECLARE c CURSOR FOR ... LOOP FETCH → IF → UPDATE 手続き的: for row in SELECT * FROM A: SELECT * FROM B WHERE id=… 宣言的: UPDATE t SET x=y WHERE ... 宣言的: SELECT … FROM A JOIN B ON … 背景: 手続き型言語で訓練された頭には「何が欲しいか」だけ書く抽象度への跳躍は大きかった。 23

小中学校でのプログラミング教育は？ ◼ 当初はループや分岐に関心が集まってしまっていた ➢ 手続き的思考を極端に強化されてしまった世代がいる のではないかと、心配。 24

Scratchはマルチエージェントシステム ◼ Scratchは基本的に「マルチエージェント・システム」そのもの ◼ 「ブロックは子供騙しの入門用」「黒い画面（CUI）でテキスト を打つのが本物のプログラミング」と思っている人は多い ◼ 企業の教育担当や採用担当にもそういう人がたくさんいる ➢ Scratchで興味深い発想をしている人よりも、Pythonでつまらない 練習問題を解いている人の方を高く評価してしまう ➢ 企業の採用条件に「○○言語の使用歴X年以上」とか、今でも普通 によく見る 将来は一流エンジニアだね プログラミング言語、 もう覚えて使えるんだ http://itpro.nikkeibp.co.jp/article/COLUMN/20111019/371083/ 25

• http://itpro.nikkeibp.co.jp/article/COLUMN/20111019/371083/
• https://opensource.com/article/18/4/designing-game-scratch-open-jam
• https://creativecommons.org/licenses/by-sa/3.0/

「何が欲しいか(What) 」 を表現することは実は難しい ◼ AIへの適切なプロンプトの書き方は、当初の頃から既に変わってきている。何が欲しいか、 それが満たすべき達成基準の定義を与えればよい。 ◼ LLMが既に学習済みの方法を教える必要はない。邪魔なノイズになって劣化させているだ け。 ➢ 例えば先のSQLの例では、手続き的記述をすることで、高性能なオプティマイザの働きを台無し にする。 ➢ 指示した本人が気付けないことが最大の問題。 「よし、今日もAIをだいぶ 賢くできたな」 ➢ AIは基本的に指示された通りに動くので、自分がやり方を 教えたのでAIができるようになったと思っている。 ◼ 「どうやって作るか(How)」より「何を作るか(What)」を表現することの方が難しい ◼ 必要十分な「コンテクスト(Why)」を選定することも難しい 「理系なので、国語は 苦手なんですよ」 ◼ 要求仕様定義が苦手な技術者は多い 26

(参考)マーケティング領域におけるニーズとウォンツ 例1） 洗濯に手間 を取りたく ない ウォンツ (Wants) クリーニン グに出した い 目 的 ――― ニーズ (Needs) 例2） 全自動洗濯 機が欲しい 例えば「コーヒーが飲みたい」と いうウォンツが発せられたとして、 その代案を考えてみよう。 ニーズによってだいぶ異なったも のが選択肢に挙がってくることが 右図を見れば分かるだろう。 ニーズ ウォンツ 手 段 家事代行 サービスを 利用したい 喉を潤し たい 眠気を覚 ましたい 目指すべき姿・状態 ソリューション サービス プロダクト 香りでリ ラックス したい コーヒー が飲みた い 27

I n q u i r y 仕様は書けないがコードなら書け るプログラマ それって、頼む側から見るとヴァイブコーディングにほぼ同じなのでは？

要求仕様が定義できないのにコードならなぜ書けるのか？ ◼ 要求仕様定義を境界点として、その前は「What（何を作るか）」であり、その後は「How（どう作る か）」であると分離できる。決まったことを具体化するだけだから比較的簡単だという説。それは 当たり前。 学校で教育されていない What（何を作るか） 「問題をつくる」作業 要求仕様定義 How（どう作るか） 「問題を解く」作業 学校で教育されている ◼ ここで問題にしたいことは少し違う。結局要求仕様書は書けないのだが、コードを書きながら修正 し、納品まで持っていける技術者は結構いる。それはなぜなのか？ これって、ヴァイブコーディングで ➢ 即時のフィードバックループ AIがやってくれることと同じでは？ ⚫ 試行錯誤の反復の中で仕様を“掘り当てる” ことができる ⚫ 速さとともに、実は「フィードバックループに何が乗っているか」が重要 しかも超高速で。 ➢ 要求仕様書は「考えてから書く」ものであるが、コードは「書きながら考える」もの。 ⚫ 村上春樹が「書く前にストーリーは決まっていない」と言うのに似ている。 ➢ 問題は発見されるものであって、定義されるものではない ⚫ 「仕様書を書く→実装する」という順序自体が、フィクション。論文の基本型「問題／目的・方法・結 果・考察」などがフィクションなのと同じ。 ⚫ 現実のソフトウェア開発における問題は、作って見せるまで顧客自身も自分が何を欲しいか分かってい ない。(ハーバート・サイモンの言うill-structured problem) 29

ヴァイブコーディングがそこそこ上手く動く理由 ◼ 相手にやってほしいこと（どう振る舞って欲しいか）を伝える方法は、大きく二つある。 演繹的指定 帰納的指定 指示を伝える方法 振る舞いのルールを示してそれに従うよう に促す 手本をやって見せて、同じように振る舞うこと を促す 例 「期限までに納税してください。」 「対象の文章を要約してください。」 「ここにあるようないい感じで、新しいポップを作って ください」 「この記入例のように書類作成してください」 メリット ルールを十分質良く言語化できていれば、 誤解なく伝わる ルールを明確にできなくても、指示が可能 デメリット ルールを言語化しないと指示できない ルールは実行する側が推測することになるの で、誤解を招きやすい 複雑な指示を要する 場合に発生する問題 ヌケモレなくルールを正しく言語化するのが 大変 ヌケモレなくルールを推測できるような過不足 ない例を揃えるのが大変 ◼ 従来、何らかのタスク処理をコンピューターに指示しようとするならば、 プログラムを書いて与えなければならなかった。演繹的にルールを（し かも多くの場合手続き的に）示す必要があった。 ◼ それに対し、LLMに対しては、抽象度の高いルール指示や、帰納的な 与え方が可能になった。ここに特徴があるので、人はそこに関心を持ち、 手法にOne-shot/Few-shotという名前まで付けた。 30

Zero-shot/One-shot/Few-shot ➢ Zero-shotとは、プロンプト内で例を一切示さない（帰納的な与え方をしない）方法。 この手法は、モデルが事前学習で獲得した汎用的な知識と推論能力を直接利用する ➢ One-shotとは、例を一つ示す方法 ➢ Few-shotとは、例を一つより多く示す方法 ◼ これらの呼び方は、LLMの文脈で特に重要視される「In-context learning」という能力を明確にす るために生まれた。In-context learningとは、プロンプト内で与えられた例からタスクを学習する 能力を指す。この能力を最大限に引き出すための具体的な手法が、One-shotやFew-shotプロンプ ティングということになる。 ◼ Brownらは、In-context learningによってLLMの極めて高いレベルの能力を引き出せることを実証し、 そのインパクトを世界に知らしめた。 ➢ Tom B. Brown and others, 「Language Models are Few-Shot Learners」, ⚫ https://doi.org/10.48550/arXiv.2005.14165 ➢ ここで「学習」という言葉が使われているが、その「学習」は、従来のLLMの重みを更新するような学習で はないことに注意を要する。 ➢ 「ごく少数の例を見せることで、既に学習済みの能力の中から、それに必要な能力を引き出し易くなる。そ れがその文脈であたかも学習したかのように見えるので、学習と表現している」と解釈するのがより正確で ある。 31

• https://doi.org/10.48550/arXiv.2005.14165

AI観点で見るとラング研究は失敗し、パロールの集積が成功した 20世紀の言語学 ─ ラングの記述を目指した ソシュール、チョムスキー以来、有限の規則体系から無限の文を生成する 理想化された言語能力 を解明しようとし てきた。 → 規則を書き尽くせない。例外が無限に出る。実用化は半世紀進まなかった。 LLM ─ パロールから直接学んだ 膨大な発話データだけから、文法書を内蔵せずに ラングが為す仕事を実現した。 → 事例だけで仮説的振る舞いを獲得 ─ 構造主義が不可能と考えたルートを開拓した。 だから LLM は、自分が学んだラングが何かを定義できない。 それはバグではなく、成功した方法そのものの帰結 32

規則・内包 表現 と 領域 観察・外延 表現 規則・内包 観察・外延 言語学 ラング（言語体系） パロール（個別発話） 科学哲学 理論・法則 観察データ ソフトウェア開発 要求仕様書 要求仕様は定義できないがコードなら書ける現場への指示 AI コーディング SDD の仕様書 ヴァイブコーディングの指示 要求分析 Example Mapping のルール（青の付箋） Example Mapping の具体例（緑の付箋） テスト設計 原因結果グラフ デシジョンテーブルの期待値埋め 領域は違っても、構造は同じ。 事例だけからは、規則は決まらない ─ 必ずアブダクションが要る。 33

ヴァイブコーディングが「動いてしまう」理由と、破綻する場所 典型的タスクでは動く 固有領域では破綻する LLM の事前分布は「典型的にはこう」という強い投射可能性を内蔵して いる。だから定型的な要望には、ユーザーが仮説を明示しなくても LLM 側のデフォルト仮説で当たる。 特定業界の業務ルール、組織固有の判断基準、レガシーの暗黙の制約 ─ LLM の事前分布にはない。仮説不一致が起き、しかも事例レベルで一致 して見えるため発覚しない。 ヴァイブコーディングの正体 ユーザーは事例だけを提示し、仮説生成（アブダクション）を LLM に押しつけている 仮説(規則・法則)が外在化されない 合意が成立しない ずれが堆積する LLM の頭の中で何が起きたか、誰にも見えない ユーザー側の理解と LLM の生成根拠は、別物のまま 事例レベルで一致して見えるので、発覚は遅れる 修正を依頼すると、そこは直してくれる。しかし、何を合意できているかを確認して いないので、ちゃんと動いていたところが壊れる。 上手くいっている部分について確認していないので当たり前 34

「過去の正解」は「未来の規則」を保証しない ◼ 例えば、次のように実例が示されているとする。 ➢ 1⊕1=2, 10⊕15=25, 25⊕32=57, 41⊕56=97 ◼ 「なるほど、⊕はアディション（足し算）のことだな」と理解する人がいてもおかしくな い。しかし、68⊕57=125と予想したら、68⊕57=5だという。 ◼ そこで改めてルールを確認すると、⊕は次のようなクワディション(クワス算)と判明 ➢ 「もしxとyがどちらも57以下の場合、通常のアディション(足し算)を適用するが、もしxまたは yのどちらかが57より大きい場合、結果は常に5になる」 ◼ 規則（要求仕様定義）が全ての問題を解決するという意味ではない。それは「設計図」で はなく「合意のプロトコル」として有効だということ。 ◼ ウォーターフォールからアジャイルへ移行しなければならない理由はここにある。 「いかなる行動も、ある規則と一致させることができる」 「規則に従うとは、ある実践のことである」 Ludwig Wittgenstein 35

Validity(意図と仕様の一致)、Correctness(仕様と実装の一致) ★ Validityが低い状態でCorrectnessを高めても無駄な 努力になる BDD: Behaviour Driven Development の場合 ◼ BDDのプラクティスはValidityを重視 • Example Mapping やユビキタス言語的 な「ビジネスの言葉で書く」という方針 発見(Discovery ) 厳 密 さ BDDの Automation Validity （意図と仕様の一致） • Daniel Jackson が "lightweight formal methods" を提唱したときの動機 の一つは、「仕様を書く過程で意図のバグ を見つける」こと • 具体的なインスタンスを自動生成して見せ ることで「こういうケース、想定してまし た？」と問いかける SysML V2 Intent •共同作業と構造化された会 話を通じて、共通の理解を 確立する ◼ UMLの普及した部分やSysML V1 ◼ 形式手法側のAlloy 形式手法 （Formal Methods） 意図 定式化(Formulation) •システムの動作例をシナリ オとして文書化する 自動化(Automation) 仕様 Specification •シナリオは、システムの動 作を検証できるように自動 化される 「うちの文書はちゃんと メンテしてないからあて にならないんですよ。 コードが一番信用でき ますね。」 Validityの観点が 欠落している Correctness （仕様と実装の一致） 実装 Implementation 36

このテクニックは、顧客のために定期的に要求ワークショップを 開催しているMatt Wynneによって発見／発明された。 実例マッピング実施途中の図例 As a 外国人の観光客として So that 慣れていない日本 の硬貨を使用せずに済む バックログに 一旦戻す 仕様 ExamplesからRulesを導くのは アブダクション 商品が選択されて、 購入の意向を確認し たら決済処理に進む 代価の回収が確認 出来てから商品を提 供する 代価の回収(決済処 理)に失敗したら、そ の取引を取り消す 代価の回収(決済処 理)に失敗したら、そ の結果と理由を提 示する 状況: 販売待機中 操作: 缶コーヒーが選択さ れたら 結果: 缶コーヒーを購入す るものと見做す 状況: 缶コーヒーが選択さ れている 操作: 長時間何の操作もな いなら 結果: 顧客が購入を取りや めたと見做し、仕掛の状態 をすべて破棄する 状況: 缶コーヒーが選択さ れている 操作: クレジットカードがタッ チ(支払いの所作)されたら 結果: 決済処理に進む 状況:選択された商品は缶 コーヒーである 操作: 代価の回収が確認 出来たら 結果: 購入された缶コー ヒーを提供する（取り出し可 にする） 状況:選択された商品は缶 コーヒーである 操作: 代価回収に失敗した ことを検知したら 結果: その取引を取り消し、 仕掛の状態をすべて破棄 する 状況:選択された商品は缶 コーヒーである 操作: 代価回収に失敗した ことを検知したら 結果: 決済に失敗したことと その理由を提示する テスト アジャイルにもウォーターフォールにも効果的！ 振る舞い駆動開発(BDD: Behavior Driven Development)のプラクティス（第3回③）より https://www.veriserve.co.jp/helloqualityworld/media/20250704001/ Questions 状況: 缶コーヒーが選択さ れている 操作: ペットボトルのお茶が 選択されたら 結果: 最後に選択された ペットボトルのお茶に選択が 変更されたと見做す Examples 顧客が購入を取りや めたことを検知したら、 仕掛の状態をすべて 破棄する Rules 決済処理の前であ れば、いつでも商品 選択（選択を変更） できる Story 一つのユーザーストーリーについて、 20～30分の議論で作成する。 I want クレジットカードの タッチ決済で飲み物を 購入したい 37

• https://www.veriserve.co.jp/helloqualityworld/media/20250704001/

演繹・帰納・アブダクション 19世紀の哲学者 C.S. パースが整理した、推論の三類型 演繹 帰納 アブダクション Deduction Induction Abduction 規則 + 事例 → 結果 事例 + 結果 → 規則 結果 + 規則仮説 → 説明 確実だが、新しい知識は生ま ない。前提に含まれた情報を 展開するだけ。 観察から一般法則へ。ただし 無数の仮説と整合し、一意に 決まらない。 観察を最もよく説明する仮説 を発明する。新しい観念を導 入できる唯一の操作。 この三類型を補助線にすると、最初の違和感の正体が見えてくる 38

仮説を、その場で、共同体として、外在化する この二段階は、AIも意外と得意である 観察 アブダクション 合意 演繹 ドメインから具体例を収集 仮説候補を生成する 共同体として仮説を引き受ける 実装・検証へと展開 この二段階こそが、人間でなければならない部分 ここをサボりたがる 技術者は多い LLM はアブダクションの候補生成を肩代わりできる。しかし── 「思っていたのと 違う」 「これが我々の仮説だ」と引き受けるのは、責任を負える主体 ─ 人間の共同体 にしかできない。 この大切な２段階をサボると、後でトラブルになる ずっと前から両者は違うものを見ていた。たまたま事例が一致していたから気づかなかっただけ。 39

AI駆動開発の主流は、仕様駆動開発(SDD: Spec-driven development)とBDDが統合された形になっていくだろう AI支援による仕様駆動開発(SDD: Spec-driven development)には振る舞い 駆動開発(BDD: Behavior Driven Development)のプラクティスが効果的 https://qiita.com/sho1884/items/0dc782484f0f01c9d079 生成AIに正確・精緻に要求を伝えるのに相応しい表現： • 質の良い定義でありさえすれば、Gherkin言語によるシナリオ表現である必要はない。簡潔な動詞句に よる自然言語表現、SysMLやUML、原因結果グラフによるモデル、デシジョンテーブルや状態遷移図、 述語論理表現、DSL表現、etc. 表現形式は何でも構わない 40

• https://qiita.com/sho1884/items/0dc782484f0f01c9d079

I n q u i r y マネジメントスタイルとハーネス ダイナミックなプロセスであることは時代の要請

プロンプト・エンジニアリング再考: 思考・推論手順指定は必要？ ◼ 次に示す例のような、思考・推論過程に対する要求 ➢ 例） 「ステップバイステップで考えてください」「まず、解決するための計画を立ててくださ い。それから、その計画を順に実行してください」「まず、SWOT分析を行ってください。その 結果に基づいて提案してください」など ◼ これは「What」で定義された機能要求に付随する「プロセス要求」と捉えればよい。出力 の精度を上げたり、ハルシネーションを防止したりする狙いを持つ ◼ 効果が期待できることが広く知られている次の各手法について、以下でそれぞれ簡単に解 6W2Hで体系化し直した生成AI(LLM)のプロンプトの書き方 説する。 https://qiita.com/sho1884/items/a7c1aee2899c369ef6d6 • • • • • • • • • • 質問精緻化（Question Refinement） 反転インタラクション（Flipped Interaction） 思考の連鎖 ― Chain-of-Thought（CoT） Zero-shot CoT 知識生成（Generated Knowledge） 方向性刺激（Directional Stimulus） ステップバック(Step Back) 自己整合性(自己一貫性) ― Self-Consistency、あるいは CoT-SC（CoT with Self-consistency） 思考の木 ― Tree-of-Thought（ToT） LLM-Blender • • • • • • • • • • • MAGIシステム CAMEL：AI同士を対話させる手法 検証の連鎖（CoVe: Chain-of-Verification） メタ認知的（Metacognitive） 仮想スクリプトエンジン（Virtual Script Engine） PAL（Program-Aided Language Models） ReAct 参考テキストを提供する 計画と解決プロンプト ― Plan-and-Solve Reflexion サブタスクに分割する 42

• https://qiita.com/sho1884/items/a7c1aee2899c369ef6d6

プロンプトエンジニアリングの拡張・分析・整理・分解（途上） プロンプト エンジニアリング プロンプト エンジニアリング コンテキスト エンジニアリング ハーネス エンジニアリング ユーザー ハーネス • フィードフォワード制御と フィードバック制御は、コー ディングエージェントのユー ザーが自身のシステムに合わせ て設定するものです ビルダー ハーネス • コーディングエージェントの開 発者によって構築されたハーネ ス（例：システムプロンプト、 コード検索ツール、オーケスト レーションなど） モデル https://martinfowler.com/articles/harness-engineering.html レイヤー 何を扱うか 旧来は プロンプト 役割・タスク指示・思考様式・出力形式 プロンプトに全部書いていた コンテキスト 何を見せるか、どう組み立てるか プロンプトに全部詰め込んでいた ハーネス いつ呼ぶか、どう繋ぐか、何を保持するか アプリケーションコードに散らばっていた 43

• https://martinfowler.com/articles/harness-engineering.html

適切な委任（デリゲーション）の範囲を設計する ◼ ReActが「Thought-Action-Observation」の単一ループだとすれば、Reflexionは「失敗の 言語化」というメタループを上に重ねた拡張版。 ◼ この２つは「未完成だからハーネスにある」のか、「人間が判断・介入すべきだからハー ネスに置くべき」なのか 分類 思考駆動装置 ツール/実行系 対話・観点設計 例 現在の地位 Zero-shot CoT, Self-Consistency, ほぼ不要（内部化された） ToT, Step Back, Plan-and-Solve, CoVe ReAct, Reflexion, PAL ハーネスに移行（プロンプトでは書か ない） 反転インタラクション, 知識生成, 方向性 依然有効（人間にしか決められな 刺激, CAMEL, MAGI い） 44

AIエージェントの基本動作ReAct(Reason:推論＋Act: 行動) ◼ 基本的に以下の処理の流れを反復することで、複雑なタスクを解決する。 最初の入力 観察(Observation): 思考(Thought): 最初の入力を受け取り、 それを観察し、… 何をすべきかを自然言 語で推論 基本的に外部環境を観察するので、それが可能な行動 (Action)のために、次の3種類のWikipedia Web APIが導 入された。 ① search[entity] 対応するエンティティのWikiページが存在する場合は 最初の5つの文を返し、存在しない場合はWikipedia 検索エンジンから上位5つの類似エンティティを提案 する。 ② lookup[string] ブラウザのCtrl+F機能をシミュレートして、文字列を 含むページの次の文を返す。 ③ finish[answer] 現在のタスクが完了したことを通知し、最終回答する。 観察(Observation): 外部環境からの結果を 受け取り、それを観察 し、… 情報収集の結果観察 に基づいて、LLMが 次に何をする必要が あるかを反復的に思 考する。 行動(Action): ツールやAPIを呼び出 す 45

Reflexionの特徴と構成 ◼ ReflexionというAIの学習サイクルは、まるで人間が試行錯誤しながらスキルを身につけていくよう な手順を繰り返す。その手順は次頁に示すが、「行動する役」「評価する役」「反省する役」とい う3つの異なる役割をLLMが担いながら進んでいく。 この手順のポイント： ◼ 自ら「反省」する: ➢ 失敗したときに、AI自身がその原因を分析し、 言葉で教訓を導き出す。 ◼ 経験が次に活かされる: ➢ この反省文が「長期記憶」として保存され、次 の行動計画に直接影響を与えるため、AIは同じ 失敗を繰り返さずに、徐々に賢くなっていく。 ◼ 継続的な改善: ➢ 成功するまで、または限界まで、この「行動→ 評価→反省→行動」のサイクルを回し続けるこ とで、AIのタスク解決能力が強化される。 46

プラットフォームの選択はマネジメントスタイルの選択 プランニング、状況判断、やり直しなど、意思決定の 脳となる部分をLangGraph、手足となる実行と連 携をn8nに、分業させることができる BPMNのような静的構造のオーケス トレーションしか念頭にないと、い つもこれを選んでしまう ツール Dify n8n LangGraph マネジメントスタイル マイクロマネジメント プロセス管理 デリゲーション 主な関心事 手順の正確性（How） システム間の整合性（データの加 工と運搬を管理） 目標の達成（What） 自由度 低（固定） 中（定型） 高（自律） 47

任せるためにはダイナミックなオーケストレーションが必要 ◼ 探索木は事前に存在しない ➢ AIエージェントの実行は、「あらかじめ用意 従来モデル: 用意された木を辿る された木を辿る」のではなく、実行しながら 枝を生やしていくプロセスである ➢ 次の一手は、その時点の状態(State)から決 まる ➢ 同じ初期入力でも、LLMの確率性と外部状態 AIエージェント: 走りながら枝が生える によって異なる枝が生える ➢ 失敗時には状態を保ったまま再探索するため、 循環(Loop)が本質的に必要となる ◼ だからグラフに描くことが難しい 実行済み 実行時に決まる 48

ダイナミックなプロセスは時代の要請 ◼ 定常的で静的なワークフローは図に描ける ➢ 計画やシステム設計に活用してきた ➢ しかし現在は、価値を生み出すビジネスの中心部分は動的で、ほとんど従来のような図には表 せない。無理にその枠組みに収めるならば、一番大事な部分がこぼれ落ちてしまう ➢ ソフトウェア開発を例とすると、ウォーターフォールは静的なプロセスだから図に描ける ◼ 一方、動的プロセスは図に描くことが難しい ➢ アジャイルのよく知られたプロセス図は1サイクルを示しているだけ。実際の大規模開発プロセ スは動的であり、従来の手法ではモデル化できていない ➢ ビジネスのリーンも同様 ◼ モデル化の方法論が確立していない結果、全体プロセスが見えにくく、フェーズゲートも 設置されず、GRC（Governance, Risk, Compliance）の観点からも問題が生じている ◼ 静的なプロセスモデルを補う、動的意思決定の構造を扱う新しいフレームワークが必要 49

ダイナミックなプロセスのモデル化は探索されている最中 ◼ 現代のシステムやビジネスの価値創造の中心は「判断」「探索」「適応」にあり、静的な 構造としては描けない ◼ LangGraph（判断の動的連鎖の制御）や ADR（Architecture Decision Record: 判断の根 拠の記録・追跡）などに見られるように、動的意思決定をメタモデル化する技法が重要に なってきている ◼ これはAIとは無関係に始まっていた流れだが、マルチエージェント型AIシステムの設計で は特に重要性が増している。人間とAIの役割や責任の境界を明確にする必要があるから ◼ 興味深いのは、この「動的意思決定のメタモデル化」が、AIが関与する開発プロセスその ものを設計・統制するためにも不可欠であること 50

フロー図を書こうとするのではなく、観測と分析の基盤を作る 01 02 設計フェーズの出力物を見直す 「実行フローの完全な事前定義」を成果物に 求めない。状態空間と意思決定の判断基準を 文書化することに注力する。 03 評価は「経路の正しさ」でなく「 結果と適応力」で トレース・チェックポイント・状態スナップ ショットを残す仕組みを最初から組み込む。 これが事後分析の唯一の入口になる。 04 想定経路を辿ったかではなく、最終的に目的 を達成したか・失敗から回復できたかで評価 する基準を整える。 Observabilityへの投資を優先する ハイブリッド構成を意識する 全体のガバナンスは静的に決め、自律性が必 要な部分だけエージェントに任せる。動と静 の使い分けが現実解。 航跡は、未来を縛るためではなく、現在を理解するために残す。 51

ADR(Architecture Decision Record: 判断の根拠の記録・追跡)の例 # ADR Template v1.3 # AIへの指示: # 1. 以下のスキーマに従ってADRを生成すること。 # 2. 'neglected'セクションでは、なぜ不採用としたかのトレードオフ を明確に記述すること。 id: ADR-NNN title: "決定事項の要約" date: "YYYY-MM-DD" status: proposed # proposed | accepted | deprecated | superseded superseded_by: null # statusがsupersededの場合、後継ADR のidを記載 # 責任の所在 participants: author: "起草者名" approver: "承認者名（またはチーム名）" last_updated: "YYYY-MM-DD" context: problem: | 解決しようとしている問題、背景、制約。 価値中立な事実と、技術的・組織的な状況を記述。 drivers: - "意思決定に影響した主要な要因（例：パフォーマンス、品質、納 期）" decision: summary: "決定内容の1行要約" detail: | 「〜することにした」という能動的な表現を用い、 論理的な選定理由（Rationale）を含めて記述する。 neglected: # 採用しなかった選択肢とその理由——反実仮想の記 録 - option: "検討したが採用しなかった案A" because: "採用しなかった決定的な理由（一文）" - option: "検討したが採用しなかった案B" because: "採用しなかった決定的な理由（一文）" consequences: positive: - "決定によって得られる直接的なメリット" negative: - "この決定により受け入れる負債や、制約されること" risks: - "将来的に問題になる可能性がある不確実な懸念事項" references: - "関連ドキュメントのURLや関連ADRのID" 52

Safety-1とSafety-2 ―「うまくいったこと」も学習資源にする Safety-1（従来の安全管理） Safety-2（新しい安全管理） 安全の定義 失敗の数が可能な限り少ないこと 成功の数が可能な限り多いこと 安全管理の原理 受動的で、何か許容できないことが 起こったら対応する プロアクティブで、連続的な発展を 期待する 事故の説明 事故は失敗と機能不全により発生 する 事故調査の目的は原因と寄与して いる要素を明らかにすること 物事は結果にかかわらず基本的に は同じように発生する 事故調査の目的は、時々物事がう まくいかないことを説明する基礎と して、通常どのようにうまくいってい るかを理解すること ヒューマンファクターへの態度 人間は基本的にやっかいで危険要 因 人間はシステムの柔軟性とレジリエ ンスの必要要素 パフォーマンス変動の役割 有害であり、できるだけ防ぐべき 必然的で有用 監視され、管理されるべき AIの「パフォーマンス変動」も、 有害として防ぐべきだけでなく、 想定外への柔軟な対応を可能にす る「必然的で有用」な要素。 Reflexion の長期記憶には、失敗 の反省だけでなく、揺らぎを乗り 越えた成功の秘訣も残すべき。 ここで「人間」を 「AI」に読み換えてみ ると味わい深い Safety-1 と Safety-2 の比較 文献[エリック•ホルナゲル, Safety-1 & Safety-2—安全マネジメントの過去と未来, 北村正晴,小松原明哲監訳. 海文堂出版,2015]に示されている 「悪いことが起きるのを待つのではなく、普通のことしか起きていないように見える状況において、何が 実際に行われているのかを理解しようとすることが重要なのである」 ― エリック・ホルナゲル『Safety-1 & Safety-2』 (2015) 53

人間チームとAIエージェントを含む実践共同体をどう設計するか ◼ ハーネスに人間の介入点を残すということは、反省の社会性を担保するということ ➢ どのタイミングで、誰が参加して、何について反省するかを設計しておく。そして、それが可能なように ハーネスを設計する必要がある ◼ 「言語化することで経験は学習可能になる」というのは、教育学やコーチングの古典的な洞察 ➢ 重み付け更新という不透明な学習を、読める・編集できる・引き継げる自然言語の反省で代替する ◼ Donald Schönの「reflective practitioner（省察的実践家）」やDeweyの経験学習論 ➢ 反省（reflection）は単なる認知プロセスではなく、実践共同体（community of practice）における対話 的・社会的な営みとして描かれていた ➢ 職人が親方に相談する、医者が同僚とカンファレンスする、教師が同僚と授業研究をする——反省は本質的に 他者を含む ◼ 開発やビジネスの場では ➢ レビュー、KPT（Keep / Problem / Try）、KPTA（＋Action）、あるいはアジャイル開発のレトロスペク ティブ、トヨタ生産方式の「振り返り」など 54

境界線は技術的にではなく、社会的・倫理的に決められるべき ① 観測可能性と説明責任の問題 ➢ Reflexionのループがコントロール可能な側のハーネスにあるということは、「何を反省として 残したか」「どの過去経験を参照したか」が読める・監査できる・編集できるということ ➢ モデルの内部に飲み込まれた瞬間、それはブラックボックス化する ② 価値判断の所在：「何を失敗とみなすか」「何を成功とみなすか」「次に何を試すべきか」 ➢ ReflexionのEvaluator役が下す判断は、本質的に目的論的 ➢ 誰の目的に照らして評価するのか？ ⚫ これはモデルが単独で決められる問題ではなく、ユーザーや組織の文脈に依存する ⚫ コントロール可能な側のハーネスに置くべき、というのは技術的制約ではなく設計上の規範 ◼ 本来は「責任を持つべき主体」を設計し、その責任境界に合わせてハーネス構造を決めた い。しかし現実には、強者（企業・プラットフォーマー）が自分に都合のいいようにハー ネス構造を決め、関わりたくない責任を外側に押し付ける形になる。 55

しかし「事後」のグラフ化は可能で、有用 ◼ 実行が終わったあとなら、その実行で実際に辿られた経路をグラフとして書き起こせる ◼ これは「設計図」ではなく「航跡図」 デバッグ・障害分析 振る舞いの傾向分析 ガードレール設計の根拠 予期せぬ結果が出たときに、 エージェントがどの状態でど の判断をしたかを追跡する。 トレースは原因調査の一次資 料となる。 多数の実行を集計することで 、頻出する経路、よく失敗す る分岐、ループに陥りやすい 状態など、系全体の特性が浮 かび上がる。 観測された逸脱パターンをも とに、許容できない経路に対 してのみ事後的に制約をかけ る。事前に全経路を縛るのと は方向が逆。 56

「航跡」を「設計図」と取り違えてしまう技術者は少なからずいる ◼ 例えば、Erik Hollnagel氏が提唱したFRAM(Functional Resonance Analysis Method)は、複雑で生き物のように変化するシステムが 『普段うまくいっている理由』を、業務全体の『機能のつながり UMLやBPMNの静的構造にすっかり 慣れてしまっていて、「ハンマーを持つと、 すべてが釘に見える」あるいはストリー トライト・エフェクトの状態に陥っている のかもしれない と、その変動（ブレ）』から紐解くための道具なのだが、そのグ ラフでフローを描いてシミュレーション解析してしまう。 ◼ グラフに描いた途端に、その構造は静的なものになっている。仮 にそのグラフでシミュレーションして完全に安全なことが立証さ れたとして、次の瞬間にグラフの形が変わったらどうするのか？ ➢ 何を聞かれているのかさえ分からない様子だったりする 症状① サンプルを設計図に昇格させる 症状② 再現性を過大評価する 症状③ 静的な線路に無理やり押し込める うまく動いた一回の実行ログを「正し いフロー」として文書化し、以後それ に従うべきだと考える。 同じ入力なら同じ経路を辿るはずだと 暗黙に仮定する。LLMの確率性と状態 依存性を軽視する。 BPMNやワークフローツールで表現で きる形に「整形」しようとし、本来必 要な循環や再探索を削ぎ落とす。 57

I n q u i r y コードからコンテキストへ フレーム問題の再来

コードからコンテキストへ、重心が移りはじめている ◼ 「何がシステムの振る舞いを決めるか」が変わりはじめた 従来型システム LLMシステム コードが振る舞いを決める コンテキストが振る舞いを決める LLM（固定・交換可能） 処理ロジック （コード） コンテキスト構成 （システムプロンプト・履歴・ RAG・ツール定義） 設定 / 環境変数（補助） → システムの機能・人格・スコープのほぼすべてを規定 従来型システムでは「コードに何を書いたか」が、LLMシステムでは「コンテキストに何を入れて何を入れないか」が、 システムの実体を決める。 59

LLM自体はコンテキストの記憶を持たないことに注意 ◼ LLM(モデルコア)から見れば、プロンプトウィンドウにあるテキストは、特に何か工夫が ない限りは、その出所や取得プロセスに関わらず、すべて同じ「入力データ」として扱わ れ、区別はつかない。 ➢ どこから来た情報であろうと、すべて同じ「入力トークンのシーケンス」に過ぎない。 • それがユーザーが直接タイプした指示であろうと、 • RAGシステムが外部データベースから引っ張ってきてコンテキストに挿入したドキュメントであ ろうと、 • ReActのエージェントがウェブ検索APIを呼び出して得た結果であろうと、 • あるいはLLM自身が以前に生成した「思考」のテキストであろうと、 ➢ 何の工夫もなければ、LLMの内部では、それらはすべて同じ重み付けで扱われる。 ◼ LLM自身が「これはユーザーが打った」「これはRAGの出力だ」「これはReActがウェブか ら取ってきた」といったメタ情報を区別するメカニズムは基本的に持っていないことを、 忘れない方が良い。 60

生成AI初心者に向けたコンテキスト理解のための工夫 以下の疑問、持ちませんでしたか？ ◼ 問１： ➢ ChatGPTやGeminiは、あなたとある程度継続的に会話してくれ ますよね。LLM(large language model)は、何人いるのでしょ うか？ LLM ◼ 問２： ➢ LLMとユーザーの数はどちらが多いと思いますか？ ◼ 問３： ➢ 複数人と同時に話せるなんて、LLMは聖徳太子のようですね。 なぜそんな器用なことができるのか、考えてみたことがあり ますか？ ◼ 問４： ➢ 運用時に学習しないって、長期記憶できないということです よね。ところで短期記憶はどうなってると思っていますか？ 61

短期記憶の在り処 ココをうまく使う方法を よく知ることが大事！ コンテキストウィンドウ （Context Window） システムプロンプト（System Prompt） • あなたは親切で丁寧なAIアシスタントです。質問には簡潔に答えて ください。 これまでのユーザーとLLMの会話履歴 • （ユーザープロンプトとLLMの応答が交互に並ぶ） 最新のユーザープロンプト（User Prompt） 数分前の記憶を忘れてしまう前向 性健忘の男が妻殺しの犯人を追う、 クリストファー・ノーラン監督が 贈る異色サスペンス。 62

求められるのはプロンプトよりもコンテキストエンジニアリング Philipp Schmid『The New Skill in AI is Not Prompting, It's Context Engineering』 https://www.philschmid.de/context-engineering エージェントの台頭に伴い、「限られたワーキングメモリ」に どのような情報を読み込むかがますます重要になっています。 エージェントの成否を決定づける主な要因は、エージェント に与えるコンテキストの質であることが分かってきています。 エージェントの失敗の多くは、もはやモデルの失敗ではなく、 コンテキストの失敗です。 63

• https://www.philschmid.de/context-engineering

コンテキストエンジニアリング ◼ Philipp Schmid『The New Skill in AI is Not Prompting, It‘s Context Engineering』より 構成要素名 説明 指示／シス テムプロンプ ト 会話中のモデルの動作を定義する初期の一 連の指示。例やルールなどを含めることができ る／含めるべき。 ユーザープロ ンプト ユーザーからの直接的なタスクや質問。 状態／履歴 （短期記憶） 現在の会話、この瞬間に至るまでのユーザー とモデルの応答を含む。 長期記憶 過去の多くの会話から集められた持続的な知 識ベース。学習したユーザーの好み、過去の プロジェクトの要約、または将来の使用のため に記憶するように指示された事実を含む。 取得情報 （RAG） 特定の質問に答えるための、外部からの最新 知識、文書、データベース、またはAPIからの 関連情報。 利用可能な ツール 呼び出せるすべての機能や組み込みツールの 定義（例：check_inventory、send_email）。 構造化され た出力 モデルの応答形式の定義（例：JSONオブジェ クト）。 コンテキスト 指示／システムプロンプト 状態／履歴 (短期記憶) 長期記憶 取得情報(RAG) 利用可能なツール ユーザープロンプト 構造化された出力 64

「Less is More（少ない方が豊かである）」の原則 ◼ LLMに与える情報は、単に量が多いだけでなく、「関連性が高く」「正確で」「簡潔に整 理され」「LLMの既存知識と適切に連携する」ものであるべき。 ◼ いずれにしろ、与える情報は多ければ多いほど良いということはない。 ➢ 他の手法の論文でも指摘されていることだが、ノイズになるものを増やせば結果は悪化する。 ➢ 良かれと思ったものがノイズになることも多い。 ➢ 特にモデルが正しくよく知っていることについては、その知識やスキルを引き出す工夫をすれ ばよいのであって、下手な教え方をしない方が良い。 ◼ 正しくても奇妙な例を一つでも含めてしまうと、LLMはそれを深読みして誤解してしまう可能性があ る。それはチェーホフの銃※になってしまうからである。 ※ チェーホフの銃 アントン・チェーホフ本人の言葉「もし、第1幕から壁に拳銃をかけておくのなら、第2幕にはそれが発砲さ れるべきである。そうでないなら、そこに置いてはいけない。」に由来する。 村上春樹の『1Q84 BOOK 2』では「物語の中に、必然性がない小道具は持ち出すなということだよ」と登場 人物の台詞の中で説明させている。 65

Show, don’t tell (説明より実例) ただし落とし穴に注意！ ◼ 特にBDD(Behavior-Driven Development)の実例やTDD(Test-Driven Development)のテスト を定義した人なら経験しているだろう。 ➢ 例えば、自動販売機の振る舞いの実例を「代価の回収が確認出来たら、購入された缶コーヒー を提供する」といったように定義している場面を考えてみる。 ➢ いくつものルールや実例を定義している際に、ある実例では、「缶コーヒー」ではなく、 「ペットボトルのお茶」と記載したとする。 書いた方としては、飲み物の自動販売機なのだから、様々な飲料が出て来るのが当たり前と考 える。そして「ペットボトルのお茶」をたまたま選んでみただけだ。 ところが、その実例を受け取った方は、ルールを推測する際に、「缶コーヒー」と「ペットボ トルのお茶」の違いでルールに何か差があるに違いないと、余計な深読みをすることになる。 この問題は、相手がLLMだろうと人間だろうと関係なく起こり得る問題である。LLM相手の場合 も逃れることはできない。 https://www.veriserve.co.jp/helloqualityworld/media/20250604001/ ◼ 結局、プロンプトやコンテキストの作成者は、提示する例の質と代表性に細心の注意を払 う必要がある。 66

• https://www.veriserve.co.jp/helloqualityworld/media/20250604001/

コンテキスト図再考 従来のスコープ定義 コンテキスト図が答える3つの問い Context Diagram によって境界は事前確定できた ユーザー 外部システム System • 誰がこのシステムの関係者か • ユーザー・他システム・関連組織を列挙 • 何を入出力するか • システムが受け取り、返す情報の種類 • 責任の境界はどこか • = 何を作らなくてよいかの確定 この方式が成立する前提 管理者 他組織 DeMarco / Yourdon (1970s) — 構造化分析の最上位図 実務的な核心 ⚫ 何を扱うかを描くことではなく、何を扱わないかを早い 段階で確定させる点にある。 ⚫ これにより、後工程でのスコープクリープや手戻り、 過剰実装といった問題を構造的に防ぐことができた • 入出力の型が事前定義可能 • 整数・構造化データ・固定スキーマ • 意味論が決定的 • 同じ入力 → 同じ出力 • 関連性が静的に確定 • 扱う情報は設計時に列挙できる 67

LLMを含むシステムでは前提が崩れる ◼ 自然言語が入出力に入った瞬間、境界は静的に引けなくなる 型の崩壊 決定性の崩壊 境界の崩壊 入力空間も出力空間も自然言語。 事前列挙・スキーマ化が原理的に 不可能。 同じ入力に同じ出力を返す保証が ない。確率的な振る舞い。 システムの実質的な機能は、コー ドではなくコンテキスト構成に依 存して決まる。 「注文番号(整数)」のような型契 約が成立しない 従来の「プロセス」概念とは質が 異なる プロンプト・履歴・RAG結果が振 る舞いを規定 帰結 コンテキスト図の「矢印一本」では、もはや何も定義できない。 68

フレーム問題がここに形を変えて再来する ◼ 「フレーム問題」は解かれていない ―コンテキストエンジニアリングの中で形を変えて 再来する ◼ フレーム問題は「AIと人間の差によって発生しているわけではなく、あらかじめモデル化 しようとするから発生する問題」であることがわかる ◼ 最新のAIは静的な因子選別から設計者を解放する。しかし今度は「動的に膨大な文脈のど こを言語化・記号化してAIに与えるか」という、新しい姿のフレーム問題が立ち現れる。 中心的問い ある状況において 何が関連的 (relevant) で 何が無関連 (irrelevant) かを、 どうやって決めるのか？ 69

両者は構造的に同じ問題である McCarthy & Hayes (1969) が状況計算 (situation calculus) の文脈で提起した問題 のDennettによる拡張 — relevance problem LLMのコンテキスト構成は relevance problem の実装版 思考実験「ロボットと爆弾と荷車」 (Cognitive Wheels, 1984) シナリオ ユーザーが「明日の会議の資料を準備して」と 入力したとき — • ロボットR1: 荷車の上に爆弾。荷車を動かしたが、爆弾 も一緒に動くことに気づかず爆発。 • コンテキストに何を入れるか？ • ロボットR1D1: 行為のあらゆる含意を考えるよう改良。 荷車を動かすと壁紙の色は変わるか、車輪は回るか、そ の回転で空気は動くか…無限の派生を前に固まる。 • 何年前までの履歴を見るべきなのか • ロボットR2D1: 「無関連な含意は無視する」よう改良。 だがどれが無関連かを判定するために、結局すべての 含意を検討する必要があり、また固まる。 • どの過去メールが関連するのか • 「会議」と名のつく文書を全部か、参加者で絞るのか • 関連しそうな社内Wikiも引くべきか、どこまで辿るのか • 引かなくていい(=無関連と判断していい)ものは何か • コンテキスト窓に収まらない場合、何を捨てるのか 無限に派生する候補から、有限のコンテキスト窓に何を載せるかを決める。 「載せなかったもの」が後で重要だったと判明する可能性は常にある。 — これはフレーム問題の構造そのものである。 「Less is More（少ない方が豊かで ある）」の原則やコスト削減に取り組 まなくてはならない 70

スコープ定義の構造的変化 ◼ AIシステムにおけるスコープ定義の構造的変化 ➢ 「境界を引く」から「境界を引くための判断基準を設計する」へ B E F O R E A F T E R 境界の事前確定 選別基準の設計 処理ロジックがスコープを決める 設計時に何を扱い何を扱わないかを列挙できた コンテキストの構成がスコープを決める 実行時に動的に何を選び何を捨てるかが境界 relevance は静的に確定 relevance は入力ごとに決まる 新しい時代のスコープ — 設計すべき4つの次元 意図 知識 行為 振る舞い 対象内/外の発話 アクセス可能な情報源 許可されるツール 出力形式・逸脱時挙動 71

I n q u i r y 上方向に役割を移す （その２） システム思考・デザイン思考は時代の要請

コンテキスト図(システム連携視点)は物理的システム階層をZoom Out 例えば、顧客(関係)管理(Customer Relationship Management)に は、左下図に示すような機能要求があるだろう。これに応え るためには、右図に示されるような他システムとの連携が必 要である。 右図はコンテキスト図: 対象システムが動作する環境および周 囲の外部要素を明示するためのダイアグラム 73

機能目的展開(バリューラダー)は認識論的システム階層をZoom Out ◼ 顧客(関係)管理の機能について、目的展開によってシステム階層を上ってみると、右下図のように なるだろう。 ◼ ここに現れるのは認識論的システムなので、コンテキスト図の眺めとは直接的な関係がないことが わかる。 ◼ 物理的および認識論的なシステム階層、その両方を俯瞰する相乗効果により、イノベーションの可 能性が高まることを期待できる。 74

機能（目的）展開はシステム思考の主要な手法の一つ ◼ 機能(目的)展開もしくはバリューラダー(Value Ladder)はZoom Outして関心対象とする「システム」の範 囲を広げることに相当する ◼ 扱う「システム」の範囲(全体)を決めるのはそのシステムの研究に携わる主体の判断による ◼ この手続きによって「システム」の範囲を決める際に重要なのは，全体としての範囲を確定するときに， 一つ外側の同心円(Sn+1)を見た上で戻って全体(Sn)を決める，という思考方法である。 75

機能展開の一例: 〔公園の設計〕 • • • • 機能展開によって設計者は、どのレベルに見合うシステムを設計するかを決定する。 大きい番号のついた機能は、それよりも小さい番号のついた機能を含む。 対応して作られるシステムも大きい番号に対応するシステムが小さい番号に対応し て作られるシステムを包含する。 したがってできるだけ大きい番号の機能を選ぶのがよいとされている。 このF4レベルまでは、機能を満たすシステムは ロジスティックなシステムとして扱える。 普通のシステム設計の手続きによって、イン プットIとアウトプットOをきめて設計を行うこ とができる 。 F0 公園内で 発生したゴ ミを入れる。 F1 公園内の ゴミを局所 的に集める。 〔公園に置くゴミ箱〕を 手がかりとする F2 公園内で 局所的に集 めたゴミを 取り去る。 F3 公園内で 発生したゴ ミを取り去 る。 F4 公園内を 不要物のな い状態に整 える。 このF5レベル以上から、機能に 人間が入ってくる。 F5 公園内を 利用する 人々に清潔 感を与える。 F6 公園を利 用する人々 に憩いを与 える。 F7 市民に憩 いのある生 活をしても らう 。 例えば、「人は何故”憩い”を求めるのか?」 という課題を設定し，その原因を探るべく 因果連鎖図法を適用したりする等の必要が ここから出てくる。 すべての人々が納得する清潔感などというものはあり得ない。 来園する人々それぞれが清潔感について異なった感じ(清潔に 対する欲求)をもっているはずである。 同じ個人でも、状況によっては、それは変化する可能性がある。 • • 結果として、複数の要素が、しかも相反する要素が出てくることがあり得る。 だから万人を満たすシステムはあり得ないということになってしまう。 どのシステムを採用するかは，因果連鎖図等を用いて環境の制約を考慮した うえで、最終的には採択者の決心に委ねられる。 76

例: バリューグラフ紹介の場合 77

アプローチの比較 使い分けできない人が多い どっちをやっているかの自覚がないので迷走しているケースも多い ◼ 不良改善や生産性などの問題を解決するとき、大きく二つのアプローチがある。 （原因） 分析アプローチ 「なぜそうしたの？」と問いかけていく 不良の原因を分析することによる改善法 デザインア プローチ(ワークデザイン) 「何の目的でそうするの？」と問いかけていく 何をすべきかを明確にすることによる改善法 【例】ネジとナットを使っての組み立てで、ピッタリくっついていない不良品が頻発している問題を 解決したい Q: なぜネジの穴を大きくしすぎたのか？ A: 刃物の回転が楕円を描いていたから。 Q: なぜ刃物の回転が楕円を描いていたのか？ A: 刃物の取り付け方が垂直になっていなかったから。 Q: なぜ刃物の取り付け方が垂直になっていなかったのか？ A: 垂直になっていなくとも刃物は固定されて機械に装着でき たから。 【解決策(案) 】 完全に垂直でない限り刃物が装着できないようにして、問題 の原因を取り除く。 Q: 何の目的でネジとナットを使うの？ A: プラスチック板と別なプラスチック板をくっつけるため。 Q: 何の目的でプラスチック板と別なプラスチック板をくっつける の？ A: 両プラスチック板で，A部品を固定するため。 【解決策(案) 】 ネジとナットである必要はない。接着剤で張り合わせたら。 さらに、最初から一体成形してしまえば張り付けなくてもいい。 一体成形可能にするのに最初の手間はかかるが、ネジやナット、 毎回の組立の手間が不要になる。 【特徴】前の作業にさかのぼって分析していく ので、質問に過去形が含まれている 【特徴】これから何をしたいのかを探っていく。意 思を明確にし、計画することになる 78

事業環境/観測能力/収益構造の変化と顧客に届けるべき価値の変化 AIDMAモデル 消費者の購買行動を 5 段階で説明する古典的モデル(1920 年代〜) A I D M A Attention Interest Desire Memory Action 注意 関心 欲求 記憶 行動 商品の存在を 知る 興味を持ち 関心が湧く 「欲しい」と 思うようになる ブランドを 覚えている 実際に 購入する 提唱:Samuel Roland Hall(米国, 1920 年代) / 特徴:購入(Action)で完結する線形モデル — 購入後の口コミ・再購入は射程外 79

事業環境/観測能力/収益構造の変化と顧客に届けるべき価値の変化 ◼ 例えば事業主体として、どこにどんな介入を するとロイヤルカスタマーに留まってくれそ うか、検討するのに活用できる。 ➢ ライフサイクルの重要なステージやイベ ントにおいて、どんなUX(物語)が必要 か？ ➢ 必要な価値は揃っているか、ターゲット に本当に届いているか？ ➢ 失敗しているなら、どこで失敗している か？ ➢ どう改善すれば良いか？何かヒントはな いか？ ◼ 重要なのは、これらの疑問に答えをもたらす 情報が得られる仕組みを戦略的に整えておく こと。 ➢ そうでなければ次に何を開発すべきか、 知る術がない。 80

「フィードバックループに何が乗っているか」が重要 ◼ デザイン思考は“プロセス”ではなく “学習ループ” ◼ デザイン思考は 探索 → 仮説 → 実験 → 学習 のループ 学習 共感 探索 ◼ 5つのステップ（共感・定義・発想・プロ トタイプ・テスト）は アクティビティの テスト 定義 分類 ◼ 実際のプロジェクトでは順番通りに進ま ない ◼ 行き来し、戻り、飛ばし、同時進行する IDEOやd.schoolも「線形ではない」「循 環する」と明言してる プロト タイプ 実験 発想 仮説 81

試行錯誤の反復の中で仕様を“掘り当てる” バックログ リファインメント ステークホルダー デイリースクラム スプリント レビュー プロダクト バックログ プロダクト オーナー 名前が「プロダクトバック ログ」となっているが、プロ ダクト要求だけではなく、 チームに対する要求を入 れることができる。 スプリント レトロスペクティブ スプリントプラニング 速さとともに、フィード バックループに何を 乗せるかが重要 •スプリントゴール(このスプリ ントを行う価値)を定義(Why) •プロダクトバックログアイテム を選択(What) •タスク分解など、作業計画 (How) スプリント バックログ プロダク トインク リメント 82

ウォーターフォールとアジャイルの比較(スコープ、時間、工程) 要求 （スコープ） 要求 （スコープ） 分 析 設 計 実 装 テ ス ト 時間 ウォーターフォール 最後に動くものができる 時間 アジャイル 動くものが徐々にできあがり、成長する 平鍋健児、野中郁次郎『アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント』翔泳社, 2013年より 83

ライフサイクル: 問題は発見されるもの、定義されるものではない ビジネスステーク ホルダーへの可読 性を維持する コンセプト 策定 オポチュニティ (機会) を評価する 前進するか ボツにする か ディスカバリ (発見) MVSを見つけだす 機能毎に優先順位を 付けて上位から選択 するようなやり方を してはならない。 全体を通して 何を作るかだけではなく、 誰のためのなぜを 考え続ける。 ビジネス ステークホルダー リリース コラボレーション 評価を続け、 学び続ける 評価 ステークホルダー、 顧客、ユーザーとと もに評価 MVP / MVS デリバリー 詳細を詰める ストーリー ワークショップ 適正サイズ (1 ～3日間で 開発とテス ト可能)の分 解されたス トーリー 実装構築 毎日の コラボレーション 評価 チームで個々の部品 を評価 作る間も 会話を続 ける 84

即時のフィードバックループの実現例: BDD コンセプト 策定 オポチュニティ (機会) を評価する BDD: Behaviour Driven Development の場合 アウトプットを 最小限に抑える 努力を 忘れないこと。 全体を通して 何を作るかだけではなく、 誰のためのなぜを 考え続ける。 評価 ディスカバリ (発見) ステークホルダー、 顧客、ユーザーとと もに評価 MVSを見つけだす 発見(Discovery ) •共同作業と構造化された会 話を通じて、共通の理解を 確立する リリース 評価を続け、 学び続ける デリバリー 詳細を詰める 定式化(Formulation) •システムの動作例をシナリ オとして文書化する 評価 チームで個々の部品 を評価 ストーリー ワークショップ 実装構築 自動化(Automation) •シナリオは、システムの動 作を検証できるように自動 化される 毎日の コラボレーション 作る間も 会話を続 ける デリバリーでは 個々のストーリーの 細部を詰めていく 85 85

ウォーターフォールとの比較 協議 ビジネスシナリオ ユースケースなど 要求 ビジネス ステークホルダー 確認 受け入れテスト 検証 要求仕様 など 基本設計 システムテスト そして、ある日 検証 「思っていたの と違う」 設計ドキュメン など 詳細設計 統合テスト という瞬間が訪れる 検証 実装 On the basis of コード コンポーネント テスト ずれは今、生まれたのではない ずっと前から両者は違うものを見ていた。 たまたま事例が一致していたから気づか なかっただけ。 86

要求仕様を早期に固定したくなる事情 要求の種類と相互の関係 ◼ 何を(What) ⇒ システム要求 ◼ プロダクト要求(Q) ◼ 機能要求 ◼ 非機能要求 or 品質要求(Q) ◼ 性能やユーザビリティ、保守性等、直接ではないが機能や対象を制約する要求 ◼ いくらで ◼ コスト要求(C) ◼ いつまでに ◼ 納期(D) ◼ リリース範囲を区切って複数回に分ける場合もある ◼ どのように(How) ◼ トレードオフ関係になって しまうことが多い。 ◼ Qの方から見ると、C, Dは制 約条件に見える。 ◼ Qに限らず、C,Dにも交渉の 余地がないか探ることが大 事。 ◼ 交渉して合理的なバランス で合意する。 ◼ 最初だけぬか喜びさせても 何にもならない。合理性の 無い守れない合意は、結局 双方を不幸にする。 ◼ プロセス要求 ◼ ISO/IEC 15504(SPICE: Software Process Improvement and Capability dEtermination), ISO26262, ISO/IEC/IEEE 29119, etc. (セーフティおよびセキュリティ領域のものが増えている) 87 87

正しく運用されたアジャイルの実際 ◼ アジャイル開発が正しく行われているならば、右図のようになるはずである。 ➢ 学習した結果、修正・作り直しが発生するのが普通のことである。 ➢ 何も学習する気がないのであれば、ウォーターフォールを選択した方が良い。 要求 （スコープ） 要求 （スコープ） 時間 時間 88

DevOpsの実情 ◼ 即時のフィードバックループ ⇒ 自動でデプロイできるがリリース判断ができない ◼ フィードバックループに何を乗せるかあまり考えていない Dev Ops 89

DevOpsモデル図が見落としている 顧客(事業主体)の活動をVモデルに配置 企画 (仮説生成) 速さとともに、「フィード バックループに何を乗せ るか」が重要 ユーザ調査 (共感、洞察) 要求分析 要求分析 企画 (仮説生成) 要求分析 企画 (仮説生成) UX調査 具体化 評価・検査 (共感、洞察) 要求分析 (Prototype) (Prototype) (Prototype) 考える(Ideate) 着想(直観) 具体化 具体化 考える(Ideate) 着想(直観) 点線から上が頭 下は手足 考える(Ideate) 着想(直観) 考える(Ideate) 着想(直観) UX調査 評価・検査 (共感、洞察) UX調査 (共感、洞察) 評価・検査 運用テスト 要求定義 受け入れ テスト (次期Prototype を含む) システム 設計 システム テスト ソフトウェア 設計 ソフトウェア 統合テスト 実装／ 単体テスト 運用テスト 要求定義 受け入れ テスト (次期Prototype を含む) システム 設計 システム テスト ソフトウェア 設計 ソフトウェア 統合テスト 実装／ 単体テスト 運用テスト 要求定義 受け入れ テスト (次期Prototype を含む) システム 設計 ソフトウェア 設計 要求定義 (次期Prototype を含む) システム 設計 システム テスト ソフトウェア 設計 ソフトウェア 統合テスト 実装／ 「理系の人や技術者の方って、 単体テスト 視野が狭くてステレオタイプで すよね」と、よく言われました 文系が頭 理系は手足 実装／ 単体テスト 90

点で捉えるUI／UX 役に立つ Useful ◼ 人間中心設計の主な視点 ➢ UI／UXなどと表現されたことも多く、 製品やシステムと対峙している最中の UXに注目が集まってしまった。 ➢ 現在においてもUXはUIの良し悪しに よるユーザー体験のことであると誤認 している技術者は多い リアル ・ワールド 使いやすい Usable 好ましい Desirable 価値がある Valuable アクセス しやすい Accessible 探しやすい Findable 信頼できる Credible ユーザー・エクスペリエンス・ハニカム https://semanticstudios.com/user_experience_design/ デジタル 91

• https://semanticstudios.com/user_experience_design/

線で捉えるUX ◼ 時系列 ◼ プロセス／トランザクション単位 ➢ 製品やシステムと対峙している最中のUIは特殊な顧客接点(タッチポイント)の一つに 過ぎない リアル ・ワールド 時間 デジタル 92 92

面で、さらに立体的に捉えるUX/顧客接点(UI) サービサー(企業) 組織 従業員 リアル ・ワールド 宿泊試用し て効果を確 認したい レンタルで 試用してみ たい 旅先でも利用 できるホテル に泊まりたい アプリ 専用デバイス パートナー(企 業) 訪問 接客 自分用に最 窓口 店舗 適に調整し て欲しい Web デジタル 93 93

I n q u i r y 観測能力向上を活かす 常時接続データ：使い方、使用状況、 VOC：ECサイトなどにおける評判、SNS会話 AIとの会話

認知の社会的構築過程を記述する: Lucy Suchmanの工夫 ◼ 二人一組での対話を通じた認知プロセスの「表出化」 ➢ 被験者を単独ではなくペアにしてタスクをこなしてもらうことで、通常は内面に留まりがちな認知過程や判 断の意図が、言語的に表出される ➢ 一方が操作し、もう一方が状況を確認しながら意見を述べることで、「この操作は何を意図しているのか」 「どうしてその選択をしたのか」が自然に語られる ◼ これはまさに、認知を観察するのではなく、「認知の社会的構築過程を記述する」という発想の転 換を体現する方法論だった。 ルーシー・A・サッチマン 著， 佐伯 胖 監訳， 上野直樹，水川喜文，鈴木栄幸 訳 『プランと状況的行為─人間- 機械コミュニケー ションの可能性─』産業図書（株）（1999） 95

AIとの会話分析は非常に熱い領域として急速に立ち上がっている ◼ エスノメソドロジー的視点の力(Suchmanがこの手法で重視したのは？) ➢ 「個人の思考」を見るのではなく「相互行為の中で思考がどう立ち上がる か」を観察すること ➢ タスク遂行中の言語・ジェスチャー・沈黙などの相互調整から、意味付 け・判断・行為構造がどう形成されるかを捉える ◼ つまり、思考プロセスを“行動の中”で捉えるアプローチである。 ◼ この方法は、メタ認知の外在化にもつながる特徴を持っている。 ➢ ふだんは言葉になりにくい思考の過程が、二人の対話を通じて自然に言語 化され、観察可能なかたちとなる。こうした構造は、自分自身の認知を他 者の視点から捉える「他者的メタ認知」の考え方とも重なる。 ◼ 「お前を消す方法」でお馴染み!? 懐かしのOfficeイルカの復活 ➢ Suchmanの主張（かつてのOffice Assistantの失敗原因そのもの） ⚫ ⚫ 「私たちは一見，あらかじめプランを持っていて，そのプランに従って行為しているように 考えるが，実際のところ，プランは，本来的にアドホックである行為に対して補完的なリ ソースでしかない」 「私たちの行為は避けがたく状況に埋め込まれていて，その状況は常に私たちのまわり で変化を続けており予測不能であることから，そもそも曖昧さを排したプランを立てるこ となどできない」 96

「認知の過程ベースの設計改善」へと進化する可能性 ◼ UIにLLM(特に対話型エージェント)が組み込まれるようになると、インタフェースを介した「自然な 対話」がそのままエスノメソドロジー的観察対象になり得る。 ➢ 「認知の過程のUXを改善する」という設計哲学へと進化する可能性がある ➢ LLMとUIとの対話ログを状況的構成として分析すれば、ユーザーが何に迷い、どんな観点で試行錯誤したか が明らかになる アプローチ 特徴 認知の露出度 伝統的インタ ビュー 事後的、構造化された 問いかけ 中程度（説明としての認知） ⇒ 認知過程が二次的に再構成される（インタビュアーの期待に応えよ うとする加工が入るなど、ノイズが増える） LLMとの対話 （UI内） エスノメソド ロジ―的ログ 分析 状況に応じた逐次的発 話と試行錯誤 言語行為・反応・修 正・相互調整を分析 高い（構成中の認知） ⇒ 質問、迷い、ツッコミ、試行錯誤などの反応を把握できる 非常に高い（活動中の認知） ⇒ その場で思考が進む様子＝状況的構成(situated construction)が 加工されずに表出される ◼ それにより、従来の「結果ベースのユーザビリティ評価」から、 ➢ 「認知の過程ベースの設計改善」へと進化する可能性がある 97

「認知の過程ベースの設計改善」へと進化する可能性(続き) ◼ Suchman の研究スタイルは非常に一貫している ➢ 「ユーザの認知状態を本人から直接聞くのではなく、他者とのや 人文系の研究者が 多数入り込んでく るだろう りとりの中で自然に語られるように構造化する」 ◼ かつてのユーザビリティ評価が「何ができたか」「どこで失敗 したか」という結果の記録に依存しがちであったのに対し、 ◼ LLMとの対話ログを活用することで、ユーザーがどのように考 え、迷い、調整していたかという“認知の流れ”そのものを設 計対象にできる。 ◼ もちろん、Suchmanらによるエスノメソドロジー的手法は、す でに認知過程の観察に踏み込んでいたが、LLMとの対話ログは それをより広範かつ自動化されたかたちで実装可能にするとい う点で、新たな展開の可能性を示している。 98

I n q u i r y 自動化とは、 強制化である。 アーキテクチャによる規制が静かに変えてしまうもの — 自由・責任・主体性をめぐる人文学的考察 —

なぜ、人はそう振舞うのか？(そのやり方で仕事をするのか？) 営業自粛に協力して くれたら報酬(補助 金)を出す ex. シャドウBAN ゾーニング 要請に従わない店の ある道路を封鎖する （卸業者や金融取引 の経路を封鎖する） 市場 market 規制 される 誰か 報酬,罰金 飲食店の営業を法律で 制限する 法 law ex. プログラム コード アーキテク チャ architecture 業務システム, セキュリティ システム ローレンス・レッシグ『CODE』 legal code 法規制, 国際規格 規範 social norms ex. ドレスコード 社内方針, 規定, 慣習, 組織風土 要請に従わない店名 を公表する モラル・ハザード（moral hazard）※は、この領域の問題で はないことに注意！ ※:監視コストや情報の非対称性が非効率性を引き起こす可能性が、 取引主体のモラルに依存してしまうような「制度的欠陥」の状態。 道徳的な意味合いはない 100

強制化の一つの帰結——責任の主体が個人から設計者へ ◼ 責任の所在は、どこへ移動するか 個人 法・規範・市場の下で 行為の主体 強制化 （automation as enforcement） 設計者 アーキテクチャの下で 責任の引受先 具体例: ボーイング 737 MAX 失速防止のための自動制御システムが、特定条件下でパイロットの操縦入力を上書きする設計。 アーキテクチャ が操縦を上書きする以上、墜落の責任をパイロットに帰属させることはできない。 責任は、システムを設計した者・運用した者へと移動する。 2度の墜落事故で346名が死亡。コードがパイロットの状況 判断と暗黙知を封じ、安全のための装置が惨事を生んだ。 一見良いことに見える。だが裏返せば—— 「個人が自分の行動の主体である」という近代的な人格概念を、設計が静かに掘り崩している。 101

4要素の中でのアーキテクチャの特異性 ◼ 法・規範・市場と、アーキテクチャを分かつもの——「逸脱の余地」 法・規範・市場 アーキテクチャ Law / Norms / Market Architecture / Code → 事後的 違反してから罰が来る ✕ 事前的 そもそも行為が起こせない → 確率的 罰は必ずしも下らない ✕ 決定論的 確率ではなく不可能性 → 程度的 重さに応じてグラデーション ✕ 全か無か グラデーションがない 人間の側に「逸脱の余地」を残す 「逸脱の余地」を構造的に消去する 従わない自由と引き換えに、結果を引き受ける 従う／従わないの選択そのものが消える アーキテクチャ規制 議論編 — 強制化と人間の主体性 102

アーキテクチャの暴走による失敗 失敗事例 設計: アーキテクチャの具体 分析: 失敗のメカニズム 帰結: 具体的弊害 スピードリミッター 車両に物理的・電子的な最高速 度制限を組み込み、それ以上の 加速を不可能にする設計。 規範の代替によるリスク補償。「システムが 安全を担保している」という認識が、運転 手の「注意深く運転する」という規範を麻 痺させる。 制限内であれば乱暴な運転をして も良いという誤認が生まれ、事故率 は期待ほど下がらない。安全装置が 逆説的にリスク行動を誘発。 DRM （デジタル著作権管理） コンテンツの複製・再生・移植を コードで物理的に封鎖。デバイス 認証や回数制限などを伴う。 市場原理への干渉。法を守る「正規購入 者」の利便性のみを物理的に奪い、海賊 版（制約なし）の方が価値が高いという市 場の逆転を招く。 デバイス制限等の不便さから、ユー ザーが正規プラットフォームから離 脱する本末転倒な事態。海賊版の 優位性が高まる。 SNSの推薦アルゴリズム ユーザーの嗜好に偏った情報を 優先的に表示する推薦コード。エ ンゲージメント最大化が設計目 的。 民主的プロセスの物理的遮断。多様な意 見との接触という民主的規範を、効率的な 情報提示（コード）が駆逐する。 エコーチェンバーを生み、社会的分 断を加速。対話による合意形成を物 理的に困難にし、公共圏の機能を侵 食。 アルゴリズム量刑 （COMPAS等） 再犯リスクを統計モデルで予測 し、量刑判断や仮釈放決定の参 考とする米国の司法支援システ ム。 ブラックボックス化と異議申し立ての遮断。 裁判官の裁量（規範）をコードに置換し、 過去のバイアスを「客観的数値」として再 生産。 人種的偏向が固定化・再生産。被告 は判定根拠を検証できず、デュープ ロセス（適正手続）の事実上の無効 化。 中国の信用スコア 決済プラットフォーム（Alipay／ WeChat Pay）が、消費行動・ 人間関係・発言を統合してスコ ア化する民間システム。 市場と規範の融合。「何を買うか」「誰と話 すか」「何を発言するか」が市場アクセス （特典・与信）に直結する設計。 コミュニケーションと経済活動が同 一のスコアに収斂し、自己検閲が常 態化。ハーバーマス的な公共圏とシ ステムの境界が溶解。 103

「AIの倫理」と銘打って語られる問題のかなりの部分は古い問題 ◼ 「AIの倫理」と銘打って語られる問題のかなりの部分は、アーキテクチャ:自動化システ ムと人間の境界をどう設計するかという、数十年来の古い問題 ◼ 新しいのは規模と速度であって、構造ではない ◼ またこれは「巨大なシステム」だけの話ではない 日々書いているコードもまた、規模の差こそあれ同じ性質を持つ。 バリデーション一つ、必須項目一つ、デフォルト値一つを増やすことが、 ユーザーから「逸脱の余地」を、 ひいては判断の主体性を、ひと欠片ずつ奪っているかもしれない。 設計のたびに、本来は問うてみた方が良いだろう Q1 ここで「逸脱の余地」を消す必要が、本当にあるか？ Q2 想定外の事態で、人間が判断する経路は残っているか？ Q3 この設計は、ユーザーの主体性をどう変えてしまうか？ 便利にしてやってるのに、 何が不満なんだ？ 104

ルールあるいは仕組みを考える際に前提となる人間観 ◼ ロールズを始めとする現代のリベラルな政治哲学者の多くは、カント主義者を自認する。 結果的に秩序が保てれば 良いので。 •ＳＦの設定のように、ルールに 従うと快感を与える等の意識自 体をコントロールできる技術が 開発されると良い。 最初は無自覚的に従って いるが、次第に言語に よって「ルール」を捉え るようになり、意識的に 従うようになる。 ルールは黙約に基づいて 形成すると考えるヒュー ムの道徳論に、「べき」 の入る余地はない。 「ヒュームの法則」また は「ヒュームの原則」 •「事実から価値は導出されな い」という命題 •この「事実／ 価値」の対立は、 哲学者を悩ませてきた。 ウィトゲンシュタイン ～ ハーバマス・ラインの 「ルール」の起源論は、 事実としての「ルール」 と規範としての「ルー ル」を仲介できていそう に見えるところが魅力。 だが、上手くスルーして いるだけ、とも言える。 •統制ルールと構成ルール ―― サール •H.L.A.ハートの法理論 •ルールは歴史とともに進化する ──ハイエク •ルールは「言語」を介して生成 される──ハーバマス カントによる定言命法の 定式 「汝の意志の格率が普遍 的立法の原理として妥当 するよう行為せよ」 理性がルールを形成する ──カント ベンサム流の功利主義で は、各自が「ルール」を 認識して意識的に従って いるかどうかにはあまり こだわらない。 慣習に従うルーティンの 行動パターンから次第に 「ルール」が生成する。 何があったら「事実」は 「規範」になるのか？ 現代の功利主義者が、人 間が意識しないまま 「ルール」に従うように 誘導する「アーキテク チャ」を推奨するのは当 然かもしれない。 経験の蓄積がルールをつ くる──ヒューム ベンサム流の功利主義、 行為功利主義の系譜 ◼ しかし、カントが『実践理性批判』で示しているような、純粋な定言命法の可能性を追求していた ら、具体的な政策や制度の話はできない。カントの基準を弛めるしかない。 •仮言命法は「～したいのであれ ば、～せよ」と条件つきで自ら に命令する。その条件次第でい ろいろ変化する。 •私たちが道徳的判断だと思って いるもののほとんどは、仮言命 法によっている。一見定言命法 に見えるものでも、「他人から 嫌われたくなかったら」といっ た条件が隠れていることが多い。 人間の理性は（幾何学の 公理を発見するように） 道徳法則を発見すること ができ、それに従う意志 を自発的に形成すること ができる。 ヒューム以来の近代哲学の大問題： 「事実」(現に「～している」という事実としての「ルール」)と「規範」(「～すべき」という規範としての「ルール」)はどういう関係にあるのか、 何があったら「事実」は「規範」になるのか、それとも両者は違う次元にあって、関係づけようがないのか 105

本日はお時間を頂き、誠にありがとうございました。 本日の資料をまとめるにあたり、改めて多くの気づきが得られました。 深く考える学習の機会ともなりました。 貴重な機会をいただきまして、ありがとうございました。