【Loop Engineeringの次に来る？】 人間中心デザインをもとにした Inquiry Engineeringを提唱したい

KAG AI Week 2026 Summer DAY 5 - Offline Meetup! での登壇内容です。

Transcript

1. 2026.7.17 KAG AI Week Day 5 - Offline Meetup! 【Loop Engineeringの次に来る︖】 ⼈間中⼼デザインをもとにした Inquiry Engineeringを提唱したい KDDIアジャイル開発センター 久古幸汰
2. ⾃⼰紹介 久古 幸汰 Kota Hisafuru 2024年度⼊社 | グループイノベーション3部 | エンジニア 技術記事の投稿と個⼈開発が好きです。 業務では企業に対する⽣成AIの効果的な導⼊の⽀援をしています。 CAREER 2024.04 ⼀期⽣ NOW KAG⼊社 新⼊社員として配属 AIサービス開発等 ハッカソン出場も趣味。 KDDI Agile Development Center Corporation 012
3. HCD基礎検定を受けてきました︕ HCD基礎検定とは︖ ⼈間中⼼設計を実践するための基礎知識を、 体系的に確認する検定。 そもそも HCD (⼈間中⼼設計)とは︖ 「利⽤者視点」と「共創」により 新しい価値を⽣み出すこと 平たく⾔うと︓利⽤者(ユーザー)が本質的に何を要求 しているかに注⽬し、ユーザーとのやり取りの中でプ 出典︓NPO法⼈⼈間中⼼設計推進機構（HCD-Net）「HCDとは」より引⽤ https://www.hcdnet.org/hcd ロダクトの価値を⾼める⼿法やマインドセットのこと。 今回のテーマ 🤔 ⽣成AIの活⽤を、HCDのメソッド・プロセスでさらにブースト出来ないだろうか︖ KDDI Agile Development Center Corporation 023
4. 設計対象は、プロンプトからループへ広がってきた NOW! ⼈間が設計する対象 Whatʼs next︖ 01 02 03 04 04 Prompt Engineering Context Engineering Harness Engineering Loop Engineering 〇〇 Engineering AIへの指⽰ AIに渡す情報 AIが動く環境 実装と検証の反復 ︖︖︖ AIに与えるプロンプト を作成・調整すること で、望む結果を得る ⽣成AIに与えるあらゆ る情報（コンテキス ト）を改善・取捨選択 することで応答を最適 化する ⽣成AIを安全かつ効率 的に稼働させるための 環境（＝ハーネス）を 設計する ⽣成AIが⽬標達成まで ⾃律的に実装・検証を 回せるためのループを 設計する 次に設計するのは︖ ⽬の前の指⽰ ⾃律して動く仕組み全体 AI関連のエンジニアリングは、段々と⼈間が扱う領域をAIに明け渡してきた “設計すら”、AIにほとんど任せられるようになってきたよね Q. では、最後まで残る⼈間の役割とは何なのだろうか︖ A. プロダクトが存在する意義、つまり”意図”を伝えることでは無いだろうか︖ (Intent Engineering) ⇒ でも”意図”ってそんな簡単に抽出できるんだっけ︖ KDDI Agile Development Center Corporation 034
5. Inquiry Engineering︓意図を⾒つけるために、問いを設計する ”意図”抽出の問題 ・⾃分の”意図”を、バイアスや思い込みを排除した上で⾔語化することは難しい ・ユーザーの”意図”は、直接的には抽出できない (インタビューやアンケートで間接的にしか出てこない) この問題を解決するために… HCDの考え⽅を踏襲した 定義 Inquiry(問い) Engineeringを提唱したい︕︕ AIが問いを通じて、 ⾔語化されていない意図・制約・課題を引き出す。 そして仮説を⽴て、現実で検証できる形にするための⽅法論。 01 HCDを⼟台にする 誰に何を問い、どの証拠から要求を理解するか 02 AIが⽀援する 問い・記録の整理・仮説の更新 つまり ⇒ 意図を⼈間からAI⾃⾝に抽出させようぜ︕ という考え⽅ ⼈間中⼼かつ意図に注⽬するのはHCDの得意分野 ⇒ AIにHCDの考え⽅を取り込ませよう︕ KDDI Agile Development Center Corporation 045
6. 問う相⼿は2⼈、問うものは3つ 開発者 ユーザー 意図 プロダクトを通じて 実現したい状態 本⼈も⾔語化できていない 本質的な要求 制約 守るべき前提と、 本当に動かせない条件 利⽤状況から⾒える、 解決で守るべき条件 課題 意図を達成するために 解くべきこと 困りごとの奥にある 本質的な問題 開発者には、対話を通じて直接問う ユーザーには、⾏動・発話・利⽤状況から仮説を⽴てる KDDI Agile Development Center Corporation 056
7. 開発者の意図・制約・課題 本質的な課題 例）「ChatGPTと独⽴して存在する 価値のあるAIエージェントアプリを作る」 本当にAIエージェント を使う必要があるの︖︖ げ 約 制 を上 上 売 で 意図を本質的な課題に変換するために 制約が存在する 外 社 例) 意図 と こ AI る エー ジェ制約 ント を ） 例 使う こと 売上を出す必要は︖ 社内の業務改善じゃダメ︖ 例）「AIエージェントを活⽤したプロダクトで売上を出したい」 『Playing to Win』（A.G. Lafley & Roger L. Martin）が⽰す戦略フレームワークと同じ構造で捉えられる KDDI Agile Development Center Corporation 067
8. 開発者の意図・制約・課題 本質的な課題 例）「ChatGPTと独⽴して存在する 価値のあるAIエージェントアプリを作る」 本当にAIエージェント を使う必要があるの︖︖ ） 例 使う こと 売上を出す必要は︖ 社内の業務改善じゃダメ︖ げ 約 制 を上 上 売 で エー ジェ制約 ント を 外 社 この 意図 ⇒意図を本質的な課題に変換するために 制約の確定 ⇒ 本質的な課題設定 制約が存在する をAIにやらせたい︕︕ 例) と こ AI る 意図 例）「AIエージェントを活⽤したプロダクトで売上を出したい」 『Playing to Win』（A.G. Lafley & Roger L. Martin）が⽰す戦略フレームワークと同じ構造で捉えられる KDDI Agile Development Center Corporation 068
9. ユーザーの意図・制約・課題 「あなたの意図は︖」と直接聞いても、ユーザー⾃⾝が本質的な要求を認識しているとは限らない（HCDの知⾒） ユーザーの場合︓⾏動・経験から先に「制約」を導き出す インタビュー・アンケートで 利⽤状況・⾏動・経験を把握 本当にズラせない 「制約」を導き出す 制約の範囲で 「課題」を定義する 例︓エレベーターの待ち時間が⻑いことが問題になっている場合… 直接”意図“を聞くと ⾏動を観察すると… 「待ち時間を 短くして欲しい」 遅いことによる実害は無い =エレベーターを早くして欲しい ＝「早くすること」は制約ではな い 再設定した「課題」 「待ち時間を退屈にさせない ためにはどうすれば良い か︖」 ユーザーから直接出てきた「意図」が、問題の本質を捉えているとは限らない KDDI Agile Development Center Corporation 079
10. ユーザーの意図・制約・課題 「あなたの意図は︖」と直接聞いても、ユーザー⾃⾝が本質的な要求を認識しているとは限らない（HCDの知⾒） ユーザーの場合︓⾏動・経験から先に「制約」を導き出す インタビュー・アンケートで 利⽤状況・⾏動・経験を把握 本当にズラせない 「制約」を導き出す 制約の範囲で 「課題」を定義する 例︓エレベーターの待ち時間が⻑いことが問題になっている この 意図 ⇒ 意図を疑って制約を探る ⇒ 本質的な課題設定 直接聞いた「意図」 ⾏動を観察すると… 再設定した「課題」 をAIにやらせたい︕︕ 「待ち時間を 遅いことによる実害はほぼ無い 「待ち時間を退屈にさせない 短くして欲しい」 ＝「早くすること」は制約ではない ためにはどうすれば良いか︖」 ユーザーから直接出てきた「意図」が、問題の本質を捉えているとは限らない KDDI Agile Development Center Corporation 07 10
11. Inquiry Engineeringで設計するもの じゃあ、どのようなAIを設計したら⼈間から意図・制約・課題を引き出せるようになるの︖ AIが主導して整理を⾏い、⼈間が必要な判断に集中できるように ― 「問えるAI」を設計する A. 前提を問う能⼒ B. ユーザーに問う能⼒ AIが「動かせない」と思い込んだものを疑い直す 現実のユーザーに直接問いかける ① 制約を問う ― ⼊⼒情報の誤分類を正す ② 課題の⼊⼝を問う ― 解き⽅の前提を疑う（⽔平思考） 従来はコストが⾼くて できなかった深い問いをAIが担う → インタビュアーエージェント の「配布」へ ③ 実現可能性を問う ― 「無理だ」の前提を揺さぶる 「前提を問う」×「ユーザーに問う」 ― 2つの問いの能⼒をAIに持たせる KDDI Agile Development Center Corporation 08 11
12. A. 前提を問う能⼒︓AIの思い込みを疑い直す AIが「これは動かせない／これは無理だ」と思い込む3つの場⾯ ― 出来ないことの例と解決策 ①制約を問う ②課題の⼊⼝を問う（⽔平思考） ③実現可能性を問う 今までの AIが 出来ない例 例）ハッカソンで「DevOps」がテーマ だ と伝える ⇒“DevOps効率化”を勝⼿に制約として扱 い始める (実はDevOpsは実践していればOK で、”DevOps効率化”アプリである必要は 無い) 「⽔平思考して」と頼むと、それっ ぽいが⾶躍しすぎた思いつきが出て くる (制約を破る) ⇒ “論理的な⽔平思考”が必要 「⼀般的にこの規模の実装には数週 間かかります」と、 前例・標準⼯数だけで“無理”と結論 付ける 解決策 所与・仮定・未指定に分類 させ、所与には具体的な反例を提⽰ させて思い込みを可視化する（最終 決定は⼈間） 3ステップで⽔平思考 1. 解決策を書き出す 2. SCAMPER等で課題を⾔い換える 3. 元の制約・意図につながるか確認 させる 「難しい」を出発点に 依拠する前提を列挙させ、「エー ジェントが使える前提なら崩れない か︖」と1つずつ揺さぶらせる 開発者⾃⾝すら前提だと思い込んでいるものを1つずつ疑うことで、本質的な課題を導き出す KDDI Agile Development Center Corporation 09 12
13. B. ユーザーに問う能⼒︓インタビュアーエージェントを「配布」する ユーザーの要求を正しく把握するためには構造化された定量的なアンケートでは不⼗分 従来は「量」と「質」の強いトレードオフ ― 検証は常に開発のボトルネック 構造化された定量アンケート 半構造化インタビュー／⽂脈による質問法 量を稼げて集計しやすいが、浅い 動的に深掘りできるが、少⼈数にしか届かない 気づいていない意図や⾔葉にならない不満は掘れない ⼈間のリサーチャーの介在が必要で、コストが⾼く遅い ⇒ 提案︓⼤まかな質問項⽬だけを教えたインタビュアーエージェントを「配布」するのは︖ 動的な掘り下げ 相⼿の答えに応じて質問を変えながら深掘りできる 並⾏対話 アンケート配布に近い規模で、多数のユーザーと同時に対話できる 量 × 質の両⽴ 静的なアンケートより深い⼀次情報を、⼤量に得られる インタビュー AI 開発者（⼈） トレードオフを緩め、多くの⼀次情報で⾼速な検証ループをすことが狙い KDDI Agile Development Center Corporation 10 13
14. HCDとの対応 ここまでのAIの能⼒は、HCDの進め⽅に対応する Inquiry Engineeringでやること 計画 開発者の意図・制約・課題を定義する 使うAI ・制約を問う能⼒ 要求定義 ユーザーの意図・制約・課題を仮説として定義する ・制約を問う能⼒ ・ユーザーに問う能⼒ 具現化 課題から解決策の仮説を⽴て、その仮説が反証可能になるように検 証⽅法まで設計したうえでプロトタイプを作る ・課題の⼊⼝を問う能⼒ ・実現可能性を問う能⼒ 評価 具現化で設計した検証⽅法を誘導・確証バイアスの観点から点検し、 インタビューや⾏動観察として実⾏する ・ユーザーに問う能⼒ 評価⇒要求定義 観測結果を解釈し、仮説（＝意図の理解）を更新して次の周回へつなぐ ・前提を問う能⼒ Inquiry Engineeringは従来のHCDに⾃然に溶け込む⼿法 KDDI Agile Development Center Corporation 11 14
15. おわりに︓次に⼈間が設計するもの Inquiry Engineering⾃体、まだ仮説にすぎない ― それでも本質的な課題設定と意図の抽出は避けて通れない いくら開発が⾼速化しても、良いプロダクトは作れない ⇒ 今後は⼈間中⼼デザインを中核に、AIで効率化する⽅法論が語られてゆくはず 「問い」の設計すらAIに任せるようになったとき、最後に⼈間へ残るものは何か︖ ↓詳細はこちらで↓ 「意図の発⽣源であること」そのもの ⼈間中⼼設計 x AIで、”意図”の抽出を⾼速化し 本質的な課題設定と検証を次のステップへ︕ ご静聴、ありがとうございました︕ KDDI Agile Development Center Corporation 12 15