この記事はHTアドベントカレンダー4日目の記事です。
記事サマリ
はじめに：意思決定を「支援」するとは何か？
AIやORの技術は日々進化しています。しかし、その一方で、そもそも「良い意思決定」とは何か？という根本的な問いを改めて考える機会は意外と少ないように感じます。
私たちはこれまで、最適化エンジン、レコメンドシステム、ダッシュボード、生成AI……さまざまな「意思決定支援システム（DSS）」を作り続けてきました。技術の選択肢は増え、できることも広がっています。
それでも、こんな疑問が残ります。
「意思決定とは何か？」
「それを"支援する"とは具体的にどういう行為なのか？」
このごく当たり前のようでいて見落としがちな問いに、いま一度立ち返ってみたいと思います。
1. 意思決定とは何か？── Simonの意思決定過程
1960年に発表された意思決定研究の古典であり、今なお本質的なフレームワークとして、Herbert A. Simon の意思決定過程があります。
Simonは意思決定を次の3段階に分解しました：
① Intelligence（状況の把握）
- 問題を発見する
- データや情報を集める
② Design（代替案をつくる）
- 問題を整理する
- 解決策となる複数の代替案を生成する
③ Choice（選択する）
- 代替案を比較する
- 条件に最も合う案を選択する
意思決定とは「何かを選ぶ行為」ではなく、「複数案を見比べて納得できる判断に至るプロセス」です。
2. 人間の意思決定は「相対評価」である
多くの人が誤解しがちですが、人間は"絶対的な最適解"を求めていません。
心理学・行動経済学・認知科学の研究では、人間の意思決定が以下の構造で成り立っていることがわかっています：
- 「一番良い案」を探すのではなく
- 「比較したときに納得感がある案」を選ぶ
つまり、意思決定とは相対評価のプロセスなのです。
なぜ絶対評価ができないのか？── 限定合理性
Simon自身がこれを「限定合理性（Bounded Rationality）」と名付けました。
理由はシンプルです：
- データは常に不完全
- 情報は常に不足
- 時間は有限
- 人の認知能力には限界がある
この状態では絶対最適など存在しません。だからこそ、Simonは人間が「最適解（Optimizing）」ではなく「満足解（Satisficing）」を選ぶと説明しました。
💡 Satisficing = Satisfy（満足する）+ Suffice（十分である）
「これで十分」と納得できる選択肢を見つけた時点で探索を止める
3. 意思決定支援システム（DSS）とは？
意思決定が"相対評価"だとすると、DSS（Decision Support System）の役割は明確です：
人間が適切な比較と選択ができるようにサポートするシステム
DSSは以下のような技術の集合体であり、形式は問いません：
- 数理計画法
- 統計・機械学習
- ルールベースシステム
- 可視化ダッシュボード
- Agentic AI
重要なのは「どの技術を使うか」ではなく、「比較と選択のプロセスをいかに支援するか」です。
4. 意思決定問題の分類
意思決定問題は、その構造化の度合いによって3つに分類できます：
| 分類 | 特徴 | 例（注※） | アプローチ |
|---|---|---|---|
| 構造的問題 | 完全に定式化できる | 在庫補充（EOQモデル）、クレジットカード不正判定（ルールベース）、広告入札の自動化 | 自動化 |
| 半構造的問題 | 一部は定式化・一部は判断 | 在庫補充の発注量決定、採用候補者のスクリーニング、与信審査 | モデル＋人の判断をハイブリッドで支援 |
| 非構造的問題 | 問題定義が曖昧、判断中心 | 広告クリエイティブ制作、UI/UXデザイン、マーケティング施策立案、新規事業企画、経営判断 | 人間の直感・経験に依存（従来） |
注※ 1970年代はこうだっただろうという私の独断と偏見
Gorry & Scott Morton (1971) は、構造的問題は自動化できる一方で、真に重要で組織に大きな影響を与える決定の多くは、非構造的・半構造的領域にあると指摘しました。半構造的問題は「モデルと人間の対話」によって効率的に支援できる可能性を示しましたが、非構造的問題に対しては、意思決定者への情報提供など限定的な手段に支援が留まっていました。
5. 非構造的問題へのアプローチ —— 生成AIが変えたこと
構造化できない問題をどう扱うか？——これは長年、意思決定研究の難題でした。
Rittel & Webber (1973) は 「Wicked Problems（厄介な問題）」 という概念を提唱し、従来の科学的・工学的アプローチでは解けない問題の特徴を整理しています。明確な定式化ができない、終わりがない、正解が存在しない——こうした問題は「人間の直感・経験・暗黙知に頼るしかない領域」とされてきました。
この状況を大きく変えたのが、生成AIの登場だと私は考えています。
生成AIの本質的な変革は、これまで作れなかった「選択肢」を生成できるようになったことにあります。
非構造的問題の難しさは、そもそも比較対象となる代替案が思いつかないことでした。広告コピー、企画案、デザイン案——従来は人間の創造性に依存していた領域で、生成AIによって代替案を大量に生成できるようになりました。これにより、「比較して選ぶ」というDSSの土俵に乗せることができるようになったのです。
これが「半構造化」の正体です。
| 問題タイプ | 従来のアプローチ | 生成AI以降のアプローチ【私の考え】 |
|---|---|---|
| 構造的問題 | 自動最適化 | 自動最適化（変化なし） |
| 半構造的問題 | DSS支援 + 人間判断 | DSS支援 + 人間判断（変化なし） |
| 非構造的問題 | 人間の直感・経験に依存 | 生成AIで半構造化 → DSS支援 + 人間判断 |
つまり、生成AIは「非構造的問題を半構造化するツール」として機能するというのが私の見立てです。
この「解ける問題クラスの拡大」こそが、現在の生成AIを活用したDSS開発ブームの本質ではないでしょうか。生成AIによる代替案生成が可能になったことで、先に挙げた非構造的問題の例（広告クリエイティブ制作、UI/UXデザイン、マーケティング施策立案など）でも生成AIを活用したDSS開発が急速に進んでいます。生成AIによる半構造化が可能になったことで、「DSSで支援できる」対象になったと考えています。
6. 生成AIの登場でも変わらないDSSの本質
では、変わらないものは何でしょうか？
変わらない原則①：解くべき課題は人が決定する
生成AIによって非構造的問題を半構造化できるようになりましたが、そもそも「何を解くべきか」は人間が決めなければなりません。
開発現場では、与えられた課題をそのまま生成AIで解こうとするケースが多く見られます。しかし、問題設定自体が間違っていれば、どれだけ開発工数をかけても期待した成果は得られません。
「本当に解決したい問題は何か？」を見極めるには、現場のリアルな状況、組織の力学、言語化されていない制約など、システムでは把握できない要素を考慮する必要があります。これは今のところ、人間にしかできない仕事だと考えています。
さらに言えば、与えられた情報から想像される「現実」を疑う力——これこそが人間の価値になってくると感じています。「この課題設定は本当に正しいのか？」「見えていない前提はないか？」と問い、その疑いを検証するために自ら動く。この自律的な行動は、少なくとも現時点の最高性能を持つChatGPTやClaudeといった対話型生成AIを利用するだけでは難しい領域です。
💡 技術で何ができて、何ができないかを適切にモデリングする——これがよいDSS設計の出発点だと考えています。
変わらない原則②：最終判断は人間が行う
いかに生成AIの出力が優れていたとしても、最終的に意思決定を行うのは人間です。
非構造的・半構造的問題では、情報の一部が欠落していたり、評価基準が曖昧だったりします。このような状況では、生成AIによる完全自動の意思決定は難しく、最終的な判断は人間が行わなければなりません。
ここで重要なのは、生成AIから出力される解は「人間が納得すればよい」ということです。システムが出力した唯一解を押し付けるのではなく、人間が「これでいい」と思えることが大切です。
この「納得」を実現するために、DSSはHuman-in-the-Loop（人間参加型）のシステム設計である必要があります。システムだけで完結するのではなく、人間が納得できるまで解を作り込める仕組み——これがDSSの本質だと考えています。
7. DSS設計で大事なこと
ここまでの議論を踏まえて、DSS設計において特に重要だと考えるポイントを整理します。
① 「何を良しとするか」を定義する
生成AIによる代替案生成が容易になった今、差別化の源泉は「何を生成するか」だけでなく「何を良しとするか」にも広がっています。
しかし、「何を良しとするか」は自明ではありません。まず組織として評価基準を定義し、関係者間で合意を形成する必要があります。ブランドの価値観、顧客への約束、品質の基準——こうした暗黙知を言語化し、共有することが出発点です。
この合意があってはじめて、評価基準をシステムに落とし込むことができます。評価の仕組みに「何が良いか」を教え込むことが、企業固有の資産になるでしょう。
② データ基盤がDSSの適用範囲を決める
DSSの適用範囲は、利用可能なデータの範囲によって決まります。
過去の成功事例、顧客フィードバック、パフォーマンス指標——こうしたデータが揃っている業務領域では、DSSは候補を正しく評価・選択でき、意思決定の自動化が進みます。逆に、データが存在しない領域にはDSSを展開できません。
つまり、データ基盤が整っていれば、より大きな業務領域を横断するDSSを構築できます。評価に必要なデータが揃っている領域から順にDSSの適用範囲を広げていくことで、業務横断的な意思決定支援が可能になり、DSSを構築するメリットも大きくなります。
DSS設計においては「どの生成AIを使うか」だけでなく、「どの業務領域にデータがあるか」を見極めることが非常に重要だと考えています。
③ 人のフィードバックを継続的に取り込み、ループとして改善する
DSSは導入して終わりの仕組みではなく、人間のフィードバックを取り入れることで育っていくシステムです。特に非構造的・半構造的領域では、
- 実際の利用者の評価
- 現場の文脈に即した判断
- 運用中に発見された"例外"
などが、評価モジュールやデータ構造を磨き続ける上で極めて重要になります。
DSSは本質的にHuman-in-the-Loopのループ型システムであり、「生成 → 評価 → フィードバック → 改善」という小さなサイクルを地道に回すことで、はじめて現場に馴染む"生きた意思決定支援システム"へと進化します。
例えば、NVIDIAは社内のQ&Aシステムにおいて、ユーザーフィードバックを活用してLLMを再学習することで、正答率を向上させながらモデルサイズの削減にも成功したことを報告しています。「ユーザーがシステムの提案に対してどう判断したか」というフィードバックが、システム改善の最も価値あるデータになるという好例です。
結局、DSSとは何か？
DSSの定義は、Gorry & Scott Morton (1971) 以来、「人間の意思決定を支援するシステム」として位置づけられてきました。
生成AIによって「解ける問題クラス」は広がりました。しかし、DSSの本質は変わっていないと私は考えています：
人間が適切な比較と選択ができるようにサポートするシステム
技術は変わっても、この定義は不変です。だからこそ、技術選択よりもプロセス設計が重要だと考えています。
🚀 明日から意識できる3つのこと
1. 「どう作るか」より「何が良いか」を議論する
プロンプトエンジニアリングで生成品質を上げることも重要ですが、それ以上に「このタスクにおける合格ラインは何か？」「ベテラン社員はどこを見て良し悪しを判断しているか？」をステークホルダーと言語化することに時間を使いましょう。
2. UIを「答え合わせ」ではなく「比較検討」の場にする
ユーザーは絶対的な正解ではなく、納得できる選択肢を求めています。システムが唯一解を提示するのではなく、複数の代替案を並べて表示したり、それぞれの特徴を提示したりして、ユーザーの「比較と選択」をサポートするUI設計を意識してみてください。また、対話を通じてユーザーが納得いく解を作り込めるようなUI設計も重要です。
3. ユーザーの意思決定をログに残す
DSSの精度を上げるための最も貴重なデータは、システムの最終出力ではなく、それに対して人間が下した判断です。最終的な「採用/不採用」だけでなく、比較検討の過程、修正のやり取り、やり直しの理由——こうしたプロセス全体を蓄積し、評価の改善に回せるパイプラインを設計の初期段階から組み込みましょう。
まとめ
人間の意思決定は、絶対的な正解を探すものではなく、複数の案を比較して「これなら納得できる」と感じるプロセスです。生成AIの登場により、これまで経験や直感に頼っていた非構造的な問題でも、問題整理や代替案生成が容易になり、DSSが支援できる領域は大きく広がりました。しかし、どの課題に取り組むべきかを選び、最終判断に責任を持つのは今のところ人間です。DSSはその比較と納得のプロセスを整える技術であり、人間の判断を"置き換える"のではなく"拡張する"存在として機能します。
これからのDSSにおいては、「どんな案をどう生み出すか（生成）」と「何を良しとするか（評価）」の両輪をどう設計し、ループとして回せるようにするかが重要になっていくはずです。その積み重ねによって、最適解ではなく"納得解"に至るプロセスの質が高まっていきます。
もっとも、こうして意思決定の本質を論じていても、遠い未来にはその判断すらAIが肩代わりする時代が来るのかもしれません。とはいえ、人間が「どの案を良しとするか」をあれこれ考える余白まで奪われてしまったら、少し寂しい気もします。せめて当面は、その"悩む権利"くらいは人間の手元に残っていてほしいところです。
参考文献
- Simon, H. A. (1960). The New Science of Management Decision. Harper & Row.
- Gorry, G. A., & Scott Morton, M. S. (1971). "A Framework for Management Information Systems". Sloan Management Review, 13(1), 55-70.
- Rittel, H. W. J., & Webber, M. M. (1973). "Dilemmas in a General Theory of Planning". Policy Sciences, 4(2), 155-169.