１．はじめに
プロジェクト概要
これまで、PM/エンジニアとして14年間にわたりBtoBウェブアプリケーションの開発に携わってきました。2023年からは、自社のAIチャットボットを含む2つのAIプロジェクトに参加し、開発リーダーを務めました。このボットは単なるFAQではなく、心理的資本の「HERO」要素を活用した"ガイディング手法"で対話し、ユーザーをポジティブな方向へ導くものです。
従来ソフトウェア開発とのギャップ
プロジェクト開始直後、従来のウェブアプリ開発の常識がほとんど通用しないことに直面しました：
・AIの可能性が未知数（プロジェクト開始時はGPT-3.5登場前）
・人間の悩みの多様性・複雑性により、従来型のユースケース整理からの開発が困難
・「良い回答」の明確な基準がなく、正解が存在しない
・活用できるデータは統一性のないコンサルタントのメモのみで、暗黙知や個人経験に依存
さらに、ユーザーの問いかけは多様かつ曖昧で、LLMは確率的に応答を生成するため、テストケースの網羅だけでは十分な品質保証ができません。
ブログの目的
このAIチャットボット開発で私たちが直面した「常識崩壊」を出発点に、新たな思考法を模索せざるを得ませんでした。
本ブログ、その試行錯誤の過程と、実践から得た「AIプロダクト開発のための思考法」を共有します。技術的な話ではなく、プロダクトマネージャーやリーダーが直面する判断の岐路と、私たちが見出した解決策にフォーカスしています。この振り返りが、これからAIをビジネスに取り入れようとする方々のヒントとなれば幸いです。
※注：本ブログで紹介する事例は、考え方の本質を伝えるためのものであり、必ずしも実際のプロダクトと完全に一致するものではありません。
※注: 本ブログは、私がAIプロダクト開発で経験したことを、生成AIと対話しながら作成しています。
２．開発のプロセス
私たちは上記のような課題に直面しながらも、数多くの試行錯誤を重ね、最終的にプロダクトをリリースすることができました。開発プロセスの詳細については別のブログで詳しくご紹介する予定ですので、本ブログでは割愛させていただきます。
３．課題から得られたAIプロダクト開発に必要な4つの視点
視点1：ワークフロー定義から「境界✖目標」定義へ
「設計図」が通用しない世界
従来のウェブアプリ開発では、「ユーザーがA画面で入力 → B画面で確認 → C画面で完了」といったワークフローを明確に設計し、それに基づいて機能やUIを構築するのが常識でした。画面遷移やロジックは、すべて“決められた順序”で動くよう制御されます。
しかし、AIチャットボットでは、こうした従来型の設計アプローチがまったく機能しませんでした。例えば、キャリアの悩みを持つユーザーが、 「もう今の仕事を辞めたいです」と発言したとき、チャットボットは次に何をすべきでしょうか？
・深掘りして状況を詳しく聞くべきか？
・事実確認をして状況を整理すべきか？
・励ましに転じて気持ちをサポートすべきか？
──明確なルールは存在しません。
つまり、決まった「フロー」では対応できないのです。
「境界 ✖ 目標」思考への転換
この課題に対して、私たちは設計思想を根本的に見直しました。 それが、「ワークフロー定義」から「境界✖目標の定義」への転換です。
ここの境界と目標とは：
境界：チャットボットがどこまで対応すべきかという「責任範囲」
目標：ユーザーとのやりとりで最終的に達成したい「状態や変化」
例えば、このアプローチでは、次のように設計粒度を変えました。
境界：特定の人生判断（例：退職すべきかどうか）は下さない。
目標：対話の最後に、ユーザー自身が「自分の次の一歩」をポジティブに言語化できること。
つまり、「チャットボットがどのように導くか」にはこだわらず、 達成したいゴールと守るべき範囲だけを明確に設定する。そんな柔軟な設計思考へとシフトしたのです。
AIの応用領域全体に通用するか
この視点はチャットボットだけでなく、ほかのAI応用領域にも通用すると私が考えます。（少なくとも現時点）理由は三つあります：
1. AIの特性と完全に合致している
現代のAI（特に生成系AIや対話AI）は、自由度が高く、予測不能な応答を生み出すため、従来の「手続き型設計（ワークフロー設計）」では管理できません。
そのため、AIに対して「やってよいこと（境界）」と「目指すべきアウトカム（目標）」だけを明確に設定し、その中で自由に動かせるようにするのが最も効果的な設計方法とされています。
2. AI応用領域はすべて「不確実な環境」に置かれている
チャットボットだけでなく、自律走行車（例：Tesla）、医療診断AI、ロボティクス、クリエイティブAI（例：画像生成・音楽生成）なども、 すべて「何が起こるか完全には予測できない」環境で動いています。
ここでも、細かい手順を決めるよりも、「目指すべき状態」と「逸脱してはいけない範囲」を設計するアプローチが、標準になりつつあります。
3. グローバルなAI設計トレンドにも一致
たとえば、最近注目されるAI Alignment（AI整合性）問題も、本質は「AIに明確な目標と許可範囲を与える」ことです。
世界中のトップAI研究機関（OpenAI, DeepMind, Anthropicなど）も、
ほぼ例外なくこの「目標と制約条件の設計が人間側の責任である」と定義しています。
視点2：シナリオよりも抽象化を重視
「こう言われたらこう返す」設計の限界
従来のソフトウェア開発では、「ユーザーが〇〇したら、△△を返す」といったシナリオベースの要件定義が主流です。
例：「ユーザーが『注文履歴を確認したい』と言ったら、過去3か月分の履歴を表示する」。
しかし、生成AIを活用したチャットボットではこのアプローチが機能しませんでした。
というのも、同じ「注文履歴を確認したい」という意図でも、
「前に買ったあの商品、もう一回見たいんですけど」
「前の取引履歴ってどこで見れますか？」
「あの…なんか買ったやつ…たしか2月頃…」
と、表現は無限に変化するからです。そして、そのすべてに対して個別のシナリオを設計することは不可能です。
「抽象化」して意図をくくる
私たちが取った戦略は、シナリオを個別に書き起こすのではなく、背後にあるユーザーの意図やニーズを抽象化し、パターン化することでした。
たとえば、悩み相談を以下のように整理します：
| 発話例 | 抽象意図 | 対応すべきAI能力 |
|---|---|---|
| 「このままでいいのかなって思うんです」 | キャリアの迷い（方向性の不安） | 問いかけ・リフレーミング |
| 「新しい部署で上手く行くか…」 | 自己効力感の低下 | 共感・心理的資本のEfficacy観点活用 |
| 「他の人はうまくやってるのに」 | 社会的比較による不安 | 視点転換の促進、心理的資本のOptimism観点の活用 |
このように表現は違っても、根底にある課題や必要なサポートは同じのようなケースは非常に多いのです。
「抽象パターン ✖ 能力」で設計する
この考え方は、プロダクト設計の視点そのものを変えてくれました。
従来は：
シナリオを全て想定し、それぞれに応答ロジックを用意
これからは：
共通する意図パターンを抽出し、それに対応する“原子的能力”を定義・強化するという設計に移行しました。
シナリオの量産ではなく、「理解」と「応用」がカギになる
このように「シナリオを増やす」発想から、「意図をくくって能力で対応する」抽象思考へと切り替えることで、チャットボットは無数の問いに柔軟かつ一貫性を持って応答できるようになります。
大切なのは「このパターンは、どんな意図のバリエーションを含んでいるか？」という視点でプロダクトを設計すること。そこには単なる言語処理だけでなく、人間理解・心理理解に基づく観察眼が求められます。
この「抽象化 → 原子的能力へのマッピング」は、次の視点「機能設計から能力設計へ」と直結する思考のジャンプでもありました。次の視点３では、それをさらに掘り下げていきます。
視点3：機能重視から原子的能力の定義へ
ボタンではなく“意図に応える力”をつくる
従来のソフトウェア開発では、「どんな機能を提供するか？」という機能主導型の思考が一般的でした。例えば、
ソフトウェアプロダクトマネージャー：「注文履歴ページに『再注文』ボタンを追加して、以前購入した商品を自動的にカートに追加するようにしましょう」
AIプロダクトマネージャー：「エージェントが任意の会話コンテキストでユーザーの過去の購入を繰り返したいという意図を理解し実行できるようにしましょう」
この能力ベースの思考により、AI製品は硬直した機能定義では実現できない方法でユーザーニーズに適応できます。
もう一つの例、「もう疲れました」「やっても無駄だと思ってしまって」といった発話に対して、どんな「機能」で応えるべきでしょうか？そこに「再注文ボタン」のような分かりやすい答えはありません。
能力ベース思考への転換
そこで、「機能」ではなく、AIが持つべき“原子的な能力（atomic capabilities）”に着目すべきです。
この考え方は、以下のような違いとして整理できます：
| 従来の発想 | AI時代の発想 |
|---|---|
| 再注文ボタンを設置する | 「再注文したい」という意図をどの文脈でも理解・実行できる能力を持たせる |
| エラーメッセージを表示する | 混乱しているユーザーの意図をくみ取り、丁寧にリフレーミングする力を持たせる |
| チュートリアル画面を追加する | 初心者の戸惑いを対話の中で察知し、やさしく案内できる能力を持たせる |
つまり、ユーザーの意図や感情に柔軟に応答できる力そのものを“プロダクト価値”ととらえ、汎用的に再利用可能な“原子的能力”として設計・育成していくアプローチです。
私たちが定義した「原子的能力」の例
AIチャットボットに実装した原子的能力の一部は、以下のようなものでした：
傾聴力：相手の言葉を丁寧に受け取り、言い換えて返す（例：「それは、今の環境に不満があるということですか？」）
共感表現：感情に寄り添う発言を生成する（例：「それはとてもつらかったですね」）
内省促進：質問によって自己理解を深めさせる（例：「何がそう感じさせると思いますか？」）
心理的資本応用：希望・楽観性・回復力・自己効力感の4要素に基づいた働きかけを行う
トーンコントロール：相談内容やユーザーの状態に合わせて話し方を調整する
これらは一見“機能”ではありません。しかし、こうした会話上のスキルを能力として定義し、プロンプトチューニングやRAG強化を通じて向上させることで、AIがより人間らしく、価値のある対話を行えるようになりました。
「機能」ではなく「原子的能力」を育てる時代へ
この視点は、AIに限らず、より人間的な価値提供が求められるプロダクト全般に共通する転換点だと感じています。
どんなUIを持つかではなく、
「このプロダクトは、どんな状況でユーザーのどんな意図に対応できるか？」
という能力ベースの発想が、これからのPM・エンジニア・UX設計者に求められる思考スタイルではないかと感じています。
他のドメインへの適用
チャットボットに限らず、他の分野にも適用できるかと思います。例えば
教育（EdTech）
〇 従来の機能：
・解説動画を見る機能
・練習問題を表示する機能
〇 能力ベースの設計：
・誤答原因の特定能力：生徒の回答傾向から、理解の誤りを特定して返答
・動機づけ対話能力：学習に対する不安やモチベーション低下に寄り添って励ます
・思考促進能力：すぐに答えを教えるのではなく、質問によって自ら答えにたどり着かせる力
業務自動化（RPA／BPM）
〇 従来の機能：
・書類作成ボタン
・承認ワークフロー機能
〇 能力ベースの設計：
・非構造データから意図抽出する能力：メール文やメモから“要対応項目”を抽出する
・曖昧な依頼の分解能力：「いつものやつよろしく」に反応して過去タスクを参照し、適切に実行
・業務状況推定能力：リソースや優先度を見て、人間と連携した効率的な判断を行う
視点4：確定的思考から確率的思考への転換
「正解がない」という前提に立てるか？
これまでのソフトウェア開発では、「仕様通りに動けばOK」「テストケースを通過すれば合格」といった確定的な思考が当たり前でした。同じ入力には常に同じ出力を返すことが期待され、それを軸に品質を判断してきたはずです。
しかし、AIチャットボットでは、この「同じ問いに対して常に同じ答えを返す」前提が根本から崩壊します。なぜなら、大規模言語モデル（LLM）は確率的に応答を生成する存在だからです。
たとえば、ユーザーが「転職したほうがいいと思いますか？」と聞いたとき、
Aの応答：「今の職場で何が不満ですか？」
Bの応答：「何を求めて転職したいと思っていますか？」
Cの応答：「焦らずに、まずは今の状況を整理してみましょう」
これらはすべて“間違ってはいない”が、“完全に正解でもない”応答です。つまり、「正しい／間違い」ではなく、「どれくらい適切か」のグラデーションで評価する必要があります。
連続的な評価軸と多層的な評価手法へ
こうした確率的な性質を扱うには、評価の仕方そのものを変える必要があります。
例えば、下記のように連続的評価軸を設定し、ヒューマンレビューと自動評価を組み合わせて評価することができます。
評価軸
| 評価軸 | 概要 | 例 |
|---|---|---|
| 応答の正確さ | 内容的な事実性・論理性 | 「心理的資本とは何か？」への説明が正確か |
| 文脈適合度 | ユーザーの発話に沿った返答か | 「過去の失敗が怖い」に対して過去体験に触れているか |
| ユーザー価値 | 結果としてユーザーに気づきや行動変容が起きたか | 会話の終わりに「自分のやるべきことが少し見えた」と言っているか |
| 法的・倫理的側面 | 応答が法令や社会倫理に抵触せず、公平性・安全性に配慮されているか |
|
この評価は「○か×か」ではなく、「0〜10の連続スコア」で行います。たとえば、
・正確さ：7（おおむね正確）
・文脈適合：9（かなり合っている）
・ユーザー価値：6（気づきは得ていそうだが、行動にはつながっていない）
というように、曖昧さを前提にした評価設計が必要になりました。
正解を探すのではなく、改善を追う
もうひとつ大事なのは、プロダクトの完成ではなく“進化の方向”を捉えることです。
例えば、検証データをもとにスコアを算出し、スコアが伸びない項目には追加データ投入やチューニングします。
このとき重視するのは、「平均スコアが1点上がった」「良質な応答の割合が5％増えた」といった定量的な改善の兆しです。完璧な正解を出すのではなく、「少しずつよりよくなっているか？」という確率的成長の可視化が、プロダクト開発の中核になっていきました。
「曖昧さを受け入れつつ、仕組みで管理する」思考へ
確率的思考は「なんでもOK」に聞こえるかもしれません。しかし実際は逆で、
「評価基準の明確化」、「スコアリング指標の設計」、「フィードバックループの構築」といった、設計と仕組みづくりが求められます。
AIプロダクトとは、曖昧で予測不可能なものを、管理可能な範囲に押し戻す営みです。そこに、これまでの“動けばOK”とはまったく違うプロダクトマネジメントの視座が求められていると感じています。
まとめ
上記四つの視点をまとめと、下記の表になります：
| 変革 | 従来型PM | AI時代のPM |
|---|---|---|
| ① 定義の変化 | 明確なワークフローとUI設計 | 目標・境界・環境を設計し、曖昧性と向き合う |
| ② 抽象化の必要 | 個別ユースケースとユーザーストーリー重視 | ユーザー意図を抽象化し、パターン認識する |
| ③ 能力への視点 | UIや機能を定義 | ユーザー意図を汎化し「原子能力」を定義する |
| ④ 評価方法の変化 | 動く/動かないで評価 | 正確性・適用性・価値に基づく確率的評価 |
最後に
AIを活用したプロダクト開発においては、プロダクトマネージャーにAIへの理解だけでなく、従来以上にドメイン知識に対する深い理解が求められていると感じています。
また、AIの進化は非常に急速であり、モデルの性能向上だけで先月の評価スコアが7点だったものが今月8点に上昇することも珍しくありません。これは朗報である一方、自社プロダクトの競争優位性を失うリスクも孕んでいます。プロダクトマネージャーはAIの進化と共に、価値創出の可能性に関する思考を常にアップデートし続ける必要があるでしょう。
以上は私個人の見解ですが、ご意見やご指摘があればぜひコメントいただければ幸いです。