■ 1. 発表の背景と目的
- AIによるソフトウェア開発が加速度的に広がり、あらゆる業務のAI化を試みる企業も登場している
- 一方で「プロダクトの価値が上がらない」「AIが混乱して実装が終わらない」「既存環境を破壊する変更をしてしまう」といった課題も生じている
- AI駆動開発が上手くいかない要因の一つとして、「物事の認識や解釈が不正確だったり、歪みが生じている」ことが挙げられる
- 認識の歪みは、顧客要求の誤解釈やドメインモデルの構造的な問題に直結する
- 本セッションでは、認識の歪みを正す手段として哲学と認知科学のノウハウを紹介する
■ 2. 前提: AI時代におけるエンジニアの役割変化
- 一般的なソフトウェア開発プロセスは「要求定義→要件定義→設計→実装」で構成される
- このうち設計・実装はAIに置き換わりつつある
- 人間の仕事は必然的に上流の「要求定義・要件定義」へシフトしていく
- 要求・要件定義もAIに置き換わるという意見もあるが、「ああしたい・こうしたい」と要求するのは人間であり、目的や価値を決められるのは人間だけである
- フェーズによる役割分担:
- 問題定義フェーズ（要求・要件定義）: 人間がpilot（操縦士）、AIがcopilot（副操縦士）
- 問題解決フェーズ（設計・実装）: AIがpilot、人間がcopilot
- AI時代のエンジニアの役割は以下の2つに集約される:
- 問題定義（どのような問題を解くべきか）
- AIが設計実装した成果物の妥当性検証
■ 3. 認識のズレが引き起こす問題: 2つの事例
- 物事の認識や解釈に歪みがあると、問題定義もドメイン設計も上手くいかない
- 事例1「類似するもの」（認識のズレ）:
- ビジネス側が「購入後に類似するものを一覧表示する機能がほしい」と要求した
- 開発者は「類似するもの」を「購入商品と見た目が似た商品（同種の別メーカー品）」と解釈した
- 実際にビジネス側が意図していたのは「購入商品とセットで使う関連商品」だった
- 数ヶ月後、同じスポンジ類似品が表示される機能が完成したが、ビジネス側の期待とは全く異なる成果物となった
- 事例2「ユーザー」（いびつなドメインモデル）:
- ECサイトに「ユーザーに所属会社・会社電話番号・所属部署・ロールを登録できる仕様」が追加された
- 担当者は深く考えずに既存のユーザーモデルに項目を追加した
- 実際には法人顧客向けの仕様だったにもかかわらず、個人・法人を同一モデルに混在させた結果、「学生なのに会社名登録が必要か」「誕生日項目が法人登録画面に表示される」などの問合せや苦情が殺到した
- 両事例の共通原因:
- 事例1「類似するもの」→ 開発者は「同種の商品」と解釈したが、本当の意味は「関連商品」だった
- 事例2「ユーザー」→ 開発者は区別なく解釈したが、本当の意味は「個人顧客と法人顧客」という別概念だった
- いずれも「言葉の意味を正しく解釈できなかった」ことが根本原因
■ 4. 解決に役立つ哲学と認知科学
- こうした問題の解決に役立つのが哲学と認知科学であり、物事をより正しく認識することに役立つ
- 哲学とは:
- 物事の本質を突き詰めるために問いを立て、考えを深めていく学問
- 「なぜそれが正しいか」「前提が間違っていないか」といった追求をする
- 世界の仕組みや真理の理解、ルールや善悪判断の基準となる思考を整理する目的で生まれた
- 分野は形而上学・認識論・意味論・語用論・倫理学など多岐にわたる
- 認知科学とは:
- 知能や心の働きを情報処理の観点から解明する学問
- 知覚・記憶・学習・言語理解・感情など心的機能が関心事
- 哲学・人工知能・心理学・言語学などの分野とも関係が深い
- 本セッションで紹介する2つの概念:
- 哲学: 言語ゲーム
- 認知科学: スキーマ理論
■ 5. 言語ゲーム（哲学）
- 哲学者ウィトゲンシュタインが提唱した概念
- 「言葉の意味は単独では決まらず、用法や文脈によって決まる」とする考え方
- 例: 「水！」という言葉の意味は文脈によって異なる
- カレー店では「飲み水がほしい」
- 火災現場では「鎮火するための水を持ってきてほしい」
- 例: 「殺す」という言葉も文脈によって意味が変わる
- ソフトウェア文脈では「動作中のプロセスを強制停止するkillコマンド」
- 日常文脈では「人を殺める」
- 同じ言葉でも文脈が違えば意味が根本的に異なる
■ 6. スキーマ理論（認知科学）
- 認知科学に登場する理論で、人間の脳は自分の知識や経験に当てはめて物事を解釈しようとする
- この知識の枠組みを「スキーマ」と呼ぶ
- スキーマの利点: 「これは自分の知識に当てはめると○○だ！」と瞬時に認識・判断できる（例: 電車を見て「電車だ」と素早く認識する）
- スキーマの問題点: 知識や経験のないものに対して誤ったスキーマを適用し、誤った解釈をしてしまう
- 例: 電車を知らないジャングルの原住民が電車を「巨大なヘビ」と解釈する
- 例: 「適当にやっといて（要点を押さえてやって）」という指示を「粗くやればいい」と解釈して問題が生じる
■ 7. 言葉の意味を正しく理解するための4つの確認
- 言語ゲームとスキーマ理論の学びから、言葉の意味を理解するには以下4つの確認が必要である
- 確認すべき4項目:
- アクター: システム利用者・利害関係者（誰が関係するのか）
- 目的: アクターの目的（何をしたいのか）
- 文脈: アクターの背景やおかれている状況（どのような状況か）
- ルール: 文脈内で生じるルール・制約・方針（どのような制約があるか）
- 構造的な関係性:
- 人の言葉の裏には目的がある
- 目的は文脈から発生する（例: 寒い→上着が欲しい）
- 各文脈にはルールがある（例: 身体のサイズ、予算上限）
■ 8. 4つの確認を事例に適用した改善例
- 事例1「類似するもの」の改善:
- アクターの確認: 「ここでのユーザーとはどういうユーザーですか？」→「日用品をまとめて買うような層」と判明
- 文脈・目的の確認: 「具体的にどういう状況でどうしてほしいのですか？」→「購入後に追加購入を促したい」と判明
- ルールの確認: 「「類似する」とは具体的にどういう条件ですか？」→「購入した商品とセットで使うような商品」と判明
- 正しい認識: 「台所用スポンジを購入した場合、食器用洗剤や食器拭きなど一緒に使うもの」
- 事例2「ユーザー」の改善:
- アクターの確認: 「学生のユーザーはどうなりますか？」→「学生はありえない」→「ここでのユーザーとは？」と問い直す
- 文脈・目的の確認: 「これは法人顧客です」→「法人でなければならない理由は？」→「法人が仕事で使う物品を一括大量購入しやすくするため」と判明
- ルールの確認: 「個人と法人でルールが違いそうですね」→「割引・見積もり・請求書発行のフロー、担当者が複数人になるケースもある」と判明
- 正しい設計: 個人ユーザーモデルとは別に、会社→組織→法人アカウントという独立したドメインモデルを設計
■ 9. 意味解釈で陥りがちな注意点
- 自分の文脈で意味解釈しないよう注意:
- 誰もが陥りがちなのは、相手の文脈ではなく自分の文脈で言葉の意味を解釈してしまうこと
- スキーマ理論によると、人間はどうしても「自分の知識や経験」というレンズを通して物事を見てしまいがち
- 自分の文脈を捨て去り、相手の視座に立つ姿勢が重要
- 「言葉には厳密な定義があるはずだ」という罠:
- 「言葉には厳密な一意の定義があるはずだ」と思い込むと、文脈による意味の違いを理解できなくなる
- 数学・科学など理系出身者ほどこの罠にハマりやすい
- 重要なのは一般定義への拘泥ではなく、「相手の言葉の背後にある意図や意味は何か」を正確に理解する姿勢
■ 10. ユビキタス言語との接続
- 本セッションで語っていた内容は、ドメイン駆動設計（DDD）に登場する「ユビキタス言語」の話であった
- あえてセッション冒頭でユビキタス言語と明かさなかった理由は、「用語集だ」という先入観（スキーマ）に引きずられて本セッションの意義の理解が歪むことを防ぐためだった
- ユビキタス言語とは:
- 開発の利害関係者同士で認識を揃えるために使う言葉
- 適用可能な範囲は「境界付けられたコンテキスト」まで
- 同じ「ユーザー」という言葉でも、コンテキストが違えば意味も取り巻くルールも異なる（例: 営業コンテキストでは「見込み客」、カスタマーサポートコンテキストでは「問合せ客」）
- ユビキタス言語のドキュメントには「文脈」と「取り巻くルール」の項目が必要であり、ない場合は追加して見直すべき
- ユビキタス言語の策定にはAIを活用できる（プロンプトに言語ゲーム・スキーマ理論の観点、アクター・目的・文脈・ルールを組み込む）
■ 11. AIとの関係と結論
- 言葉の意味解釈が不正確なままAIに開発を指示しても、プロダクトを正しく作ることは困難
- 文脈が不十分だとAIも意味を取り違えて混乱し、ユーザーモデルに対して疑いなくフィールドを追加するなど、人間と同様の誤りを犯す
- 「AIは増幅器」であり、使い手である人間のスキルを増幅するものである
- 地に足のついた基礎力があってはじめてAIで能力を増幅できる
- 結論（基本こそ奥義）:
- 物事を正確に理解するために言葉の意味を整理する
- そのために哲学や認知科学を活用する
- 理解した意味に基づき要件を定義し、設計と実装に落とし込む
- 鍛錬し磨いた基礎力があってはじめてAIで能力を増幅できる