対象読者：
- 生成AIをシステムに組み込んだが、精度向上に悩みを感じているエンジニア
- 業務フローへのAI適用を検討しているPdM・アーキテクト
- プロンプト芸の運用コストに限界を感じている方
生成AIは、近年の技術の中でも突出したスピードで進化し、そのインパクトは驚異的です。
それでも、 「結局、大事な判断は自分でやっている」「AI の答えを毎回整理し直している」 という感覚が残っていないでしょうか？
文脈を「3 つの軸」で設計する
この記事では、生成 AI への「任せきれなさ」を、プロンプトや RAG のチューニングの問題だけでなく、 AI に渡す文脈に対する設計が不足している状態 として捉え直してみます。
本稿でいう コンテキストモデリング とは、ひと言でいうと、
焦点・境界・粒度の3軸で『AIに渡す世界』を設計すること
です。
もう少し分解すると、次の3 つを決めることになります：
- 焦点（Focus） - どんな問いに答えさせたいのか
- 境界（Boundary） - どこまでを同じ世界として扱うか
- 粒度（Granularity） - 世界をどの大きさのかたまりで切るか
Before / After で見る効果イメージ
Before（文脈を設計しない場合）：
ユーザー：「ログインできません」
→ 全マニュアルを検索
→ AI：「パスワードリセット、SSOエラー、ネットワーク問題の
可能性があります...（長文）」
After（文脈を設計した場合）：
【文脈（このAIが担当する仕事のイメージ）】
- 焦点: トラブルシュート（エラーコードの原因切り分け）
- 境界: Enterpriseプランかつ SSO 利用が前提（ローカルログインは対象外）
- 粒度: 「ログインできない」という問い合わせ 1 件（チケット単位）
→ AI：「SSO設定を以下3点で確認してください：
1. IDプロバイダーの証明書期限
2. リダイレクトURLの設定
3. ユーザー属性のマッピング」
文脈が適切に設計されている場合、 AI の出力がシャープになり、判断の責任範囲も明確になります。
なぜシャープになるのか：
- 焦点で「トラブルシュート」と指定したから、「契約変更のご相談は...」といった余計な提案が出ない
- 境界で「SSO利用が前提」と絞ったから、ローカルログイン関連の情報がノイズとして混入しない
- 粒度で「チケット単位」と決めたから、過去の類似ケースを適切な単位で参照できる
以降、この3 つの設計軸を、なぜ必要で、どう使うのかを順に見ていきます。
1． なぜ任せきれないのか
多くの現場で、こんな状態になっていないでしょうか：
- 社内の資料を全部ベクトルDBに入れる
- 関連しそうなテキストを引っ張ってくる
- AI に「いい感じにまとめて」とお願いする
これでも意味はありますが、
「渡し方（How）」の工夫に偏っていて、「渡すもの（What）」の設計が不十分
という状態です。
なぜこれが問題なのか。
従来の業務システムの多くは、「同じ入力なら同じ出力になる」ことを前提にした 決定論的（deterministic） なモデルで設計されてきました。
一方で、LLM や強化学習エージェントは、ある入力に対して「どの出力をどれくらいの確率で選ぶか」という 確率モデル として実装されており、その分布からサンプリングして応答や行動を選びます（Russell & Norvig, 2010; Sutton & Barto, 2018）。
その結果、同じ入力でも毎回わずかに結果が揺らぐ、non-deterministic（非決定的）な振る舞い を示します。
このゆらぐ層の「前後」に、設計されていない空白があることが問題の本質です：
この空白を埋めるのが「コンテキストモデリング」です。
これは、単発のチャットボットだけでなく、外部 API を呼んだりワークフローを実行したりする「AI エージェント」を設計するときにもまったく同じで、ゆらぐ行動の「前後の世界」をどう切り取るかが成否を分けます。
2． 「コンテキストモデリング」とは何か──プロンプト/コンテキストエンジニアリングとの違い
ここまででざっくり、「コンテキストモデリング＝焦点・境界・粒度の 3 軸で AI に渡す世界を設計すること」というイメージを置きました。ここからは、よく語られる「プロンプトエンジニアリング」や「コンテキストエンジニアリング」とどう違うのかを整理します。
プロンプトエンジニアリングは How to ask（どう聞くか） の話です。「AI に渡す情報の山」は既にあるものとして、その上で聞き方を調整する。
それに対して、コンテキストモデリングは What to Structure（何をどう束ねるか） の話です。AI に投げる前の段階で、そもそも何を入力候補とみなし、どのくらいのまとまりをひとかたまりのケースとして扱い、どこまでの世界を前提として AI に渡すのかを決める仕事です。
イメージとしては、こんな感じです。
床いっぱいに書類が散らばっているオフィスを想像してください。
書類はたしかに全部そこにあります。
でも、どれが最新版なのか、どれがどの案件に属しているのか、どこまでがこのユーザーに関係する話なのかが、ぱっと見では分かりません。
この状態で、いくら丁寧な敬語で話しかけても、相手は苦労します。
AI も同じで、「関連しそうな書類は一応全部見えるところに出しておいたから、あとはうまくまとめて」と頼んでいる限り、どこかで限界がきます。
コンテキストモデリングがやりたいのは、まずこのオフィスを片付けることです。
案件ごとに書類を束ねて箱に入れ、箱には「◯◯社 A プラン／障害対応」のようなラベルを付ける。
同じ箱の中には、「問い合わせの履歴」「対応ログ」「関係するマニュアルの抜粋」といった、ひとまとまりの「ケース」に必要なものだけを入れておく。
そのうえで、「今回はこの箱を AI に渡そう」と決める。
要するに：
- プロンプトエンジニアリングは、散らかった部屋で「丁寧に話しかける」こと
- コンテキストエンジニアリングは、その部屋の「収納用具や検索システムを揃える」こと
- コンテキストモデリングは、そもそも部屋を片付けて「書類を整理し、箱にラベルを貼る」こと
| 層 | 役割（Role） | 対象（Target） | 担当者 |
|---|---|---|---|
| プロンプトエンジニアリング | How to Ask （どう聞くか） |
自然言語の指示 （役割・制約） |
全ユーザー |
| コンテキストエンジニアリング | How to Implement （どう実装するか） |
技術パラメータ （ベクトル・チャンク・検索精度） |
データ／MLエンジニア |
| コンテキストモデリング | What to Structure （何を構造化するか） |
意味の境界 （焦点・境界・粒度） |
アーキテクト／PdM |
一般的にこれらはまとめて「コンテキストエンジニアリング」と呼ばれることもありますが、本稿では技術的な実装論（How to Implement）と、その手前にある意味の設計（What to Structure）を区別するために、あえて 「コンテキストモデリング」 と定義します。
3． コンテキストモデリングの3 つの設計軸
3-1． なぜ設計軸が必要なのか
ここまで見てきたように、AI に任せられるかどうかは、
「どんなコンテキストで、どこまでを AI に渡すか」でかなり決まります。
そのコンテキストを考えるときに、毎回一から考えるのは大変です。
もう少し、 思考のための軸 を用意しておきたいところです。
本稿では、そのための軸として、
- 焦点（Focus）
- 境界（Boundary）
- 粒度（Granularity）
の3 つを置いています。
どれも、AI だから特別に出てきた概念ではありません。
もともと、データ設計やドメインモデリングで使われてきた古典的な考え方です。
コンテキストをもう少し形式的に見ると、次の3 つに分解できます：
- どんな問いに対して（＝焦点）
- どこまでの世界を前提に扱うか（＝境界）
- どの単位の状況を（＝粒度）
ただ、AI によって「ゆらぐ層」を持ち込まれたことによって、
どんな問いに対して、
どこまでの世界を前提にして、
どの粒度で
AI にバトンを渡すのかを、
意識的に決めないといけなくなった、というだけです。
補足: 理論的背景
この 3 軸は、情報システムや言語学、ソフトウェアアーキテクチャの分野でも、「文脈の最小構成要素」として扱われてきました。
-
焦点（Focus）：談話理論（Theories of Discourse）では、会話の中で「いま答えようとしている問い（QUD: Question Under Discussion）」が文脈を規定するという理論が知られています（Roberts, 2012）。
-
境界（Boundary）：DDD（ドメイン駆動設計）における境界づけられたコンテキスト（Bounded Context）が有名です。「どの範囲の用語やルールを一貫性のある"意味のかたまり"として扱うか」を明示する設計パターンです（Evans, 2003）。
-
粒度（Granularity）：DWH/OLAP 設計では、最初に決めるべきパラメータとして知られています。Kimball のモデリングでも、最初の一手は「どの粒度で事実を記録するか」を明確にすることです（Kimball & Ross, 2013）。
軸の依存関係：焦点 → 境界 → 粒度
3 つの軸は並列ではなく、決める順序があります。
なぜこの順序なのか：
| 順序 | 理由 |
|---|---|
| 焦点が最初 | 「何を答えたいか」が決まらないと、境界も粒度も「何のために？」が宙に浮く。焦点は目的を定義する。 |
| 境界が次 | 焦点が決まれば、「その問いに答えるのに必要な世界の範囲」が見えてくる。不要な情報を落とせる。 |
| 粒度が最後 | 境界の中で「何を 1 単位とみなすか」は、境界が決まってから初めて意味を持つ。 |
もちろん、一方向ではなくフィードバックループもあります。粒度を決める段階で「境界を見直す」「焦点を絞り直す」ことはありえます。ただし、起点は常に焦点です。「何を答えたいか」がブレると全部崩れます。
以降、この順序に沿って3 つの軸を説明していきます。
3-2． 焦点（Focus）： このやり取りは、どんな問いに答えようとしているのか
焦点は、「この文脈で答えたい問いの種類」を決める軸です。
同じデータを見ていても、問いが違えば、欲しい答えも違います。
- 同じ売上データでも、「原因を特定したい」のか、「今後のシナリオを比べたい」のか
- 同じサポート問い合わせでも、「今すぐの対処方法」を知りたいのか、「根本原因と再発防止策」を知りたいのか
問いが混ざると、AI は全部に"そこそこ"答えようとします。
結果として、長くて器用だけれど、「結局何の話だったっけ？」となる。
焦点を設計する、というのは、
「いまは何について答えるターンなのか」を明示する
ことです。
-
この呼び出しはトラブルシュートのため
-
この呼び出しは契約条件の説明のため
-
この呼び出しは意思決定のための論点整理のため
といった「問いの型」がはっきりしていれば、
AI に渡す文脈も、それに合わせて絞り込めます。
技術的には「インテント分類※」と似ていますが、
コンテキストモデリングではそれをもう少し広く、「問いごとにコンテキストをスイッチする仕組み」として扱います。
また、実際の対話では「トラブルシュート」から「返品相談」へと話が変わることもあります。その場合は、システム側（Routerやエージェント）が焦点を再評価し、動的にコンテキストをスイッチさせる設計が必要になります。
※インテント分類とは、ユーザー発話を有限個の意図クラスに分類するタスクであり、
音声対話システムにおける Spoken Language Understanding（SLU; 音声言語理解）の中核タスクの 1 つとされる（Tur & Deng, 2011）
3-3． 境界（Boundary）： どこまでを同じ世界として扱うか
境界は、「どの範囲を、この文脈の"有効な世界"と見なすか」の軸です。
プロダクト全体を思い浮かべるとき、頭の中には、
全プラン・全機能・全オプション・全リージョンがそろった理論上の世界が広がっています。
でも、現実には、ひとりのユーザーやひとつの案件にとっての「世界」は、そのごく一部です。
-
いま契約しているプラン
-
実際に有効化されている機能
-
合意しているサポート範囲やリードタイム
これらが、そのユーザーにとっての実在する世界の境界線になります。
境界が曖昧なまま AI に情報を渡すと、
-
そのユーザーには関係ない機能の話
-
契約上はサポート外の前提
-
将来の可能性としてしか存在しないオプション
まで、一律に同じ文脈として扱ってしまいます。
境界を設計する、というのは、
「この文脈では、どこまでを同じ世界として良しとするか」を決める
ことです。
それはそのまま、
-
どの情報を候補として見せるか／見せないか
-
どこまでの仮定を「この場の前提」とみなすか
の線引きになります。
3-4． 粒度（Granularity）： 何を 1 単位の状況とみなすか
粒度は、「世界をどの大きさのかたまりで切るか」の軸です。
- 売上を「1 取引」単位で見るのか、「1 顧客」単位で見るのか、「1 四半期」単位で見るのか
- インシデントを「1 回の障害」なのか、「根本原因ごとのまとまり」なのか
- 会話を「1 メッセージ」なのか、「1 往復」なのか、「解決までのスレッド」なのか
粒度の取り方がバラバラだと、AI に渡す情報もバラバラになります。
1 回の問いに対して、過剰に大きいかたまり（全部入りのログ）を渡してしまったり、逆に細切れすぎて本質が見えなかったりします。
コンテキストモデリングの観点では、
「このユースケースでは、何を 1 まとまりの状況とみなすか」
を先に決めることが、粒度設計です。
この「1 まとまり」が決まっていると、
-
どの単位の履歴を AI に渡すべきか
-
どの単位で類似ケースを探すべきか
-
「この回答は何に基づいているか」をあとから説明するときの単位
がそろってきます。
3-5． （例） CS（カスタマーサポート）自動回答に 3 つの設計軸を当てはめると
カスタマーサポート自動回答の例で、3 つの軸を当てはめるとこうなります。
-
焦点： 問い合わせを「トラブルシュート」「機能の使い方」「契約相談」などに分類し、カテゴリごとに参照するケースやテンプレートを切り替える
-
境界： ユーザーの契約プランや有効なオプションをもとに、「このユーザーにとっての世界」を決め、その境界の内側の情報だけを AI に渡す
-
粒度： 「1 件の問い合わせ〜クローズまで」を 1 ケースとみなし、ケース単位で類似事例を検索し、要約を AI に渡す
同じ「サポート用 RAG＋LLM」でも、違いは歴然でしょう：
コンテキストの設計があるかどうかで、「任せられる感じ」がまったく変わります。
この3 つの設計軸は、サポート以外の場面にもそのまま持ち込めます。
レポート自動生成でも、調達条件の検討でも、経営会議向けのアジェンダ整理でも、「焦点・境界・粒度」が決まっていれば、AI に任せられる範囲を意識的にコントロールできます。
ここまで見てきたように、「焦点・境界・粒度」をユースケースごとに決め直すことこそがコンテキストモデリングです。AI の中身を変えなくても、「AI に渡す世界」をこの 3 軸で整理するだけで、任せやすさと説明しやすさが大きく変わります。
3-6． コンテキスト設計の品質特性
3 つの軸を決めたとして、その設計が「良い」かどうかをどう判断すればよいでしょうか。
ソフトウェア設計における「凝集度」や「結合度」のように、コンテキスト設計にも品質を測る観点があります。
各軸の品質特性
| 軸 | 品質特性 | 問い | 悪い状態 |
|---|---|---|---|
| 焦点 | 純度（Purity） | 1 つのコンテキストが 1 つの問いの種類に対応しているか？ | 複数の問いが混在（トラブルシュート＋契約相談） |
| 境界 | 密封性（Hermeticity） | 境界外の情報が漏れ込んでいないか？ | 他テナント、他プラン、無関係な機能の情報が混入 |
| 粒度 | 一貫性（Consistency） | 同じユースケース内で粒度がブレていないか？ | ケース単位とメッセージ単位が混在 |
焦点の品質：純度（Purity）
1 つのコンテキストが、1 つの問いの種類（Intent）に対応している度合いです。
純度が低いとき：
焦点が混在したコンテキスト：
「トラブルシュートと契約相談の両方に対応」
→ AIの出力：
「エラーの原因はSSO設定かもしれません。
また、プランのアップグレードもご検討ください。
返金ポリシーについては...」
→ 長くて散漫、ユーザーは「結局何？」となる
チェックポイント：
- このコンテキストで答える「問いの種類」を 1 文で言えるか？
- 「〇〇かつ△△」になっていないか？（複合していたら分割を検討）
境界の品質：密封性（Hermeticity）
境界の外の情報が、コンテキスト内に漏れ込まない度合いです。
密封性が低いとき：
境界が漏れているコンテキスト：
「Enterpriseプラン向けだが、Freeプランのマニュアルも混入」
→ AIの出力：
「この機能はFreeプランでは利用できませんが...
Enterpriseプランでは...」
→ ユーザーは混乱、または誤情報
チェックポイント：
- このコンテキストで参照すべきでない情報が混入していないか？
- テナント分離、プラン分離、権限分離が実装レベルで担保されているか？
- 念のため入れておいただけの余計な情報がないか？（ノイズの温床）
粒度の品質：一貫性（Consistency）
同じユースケース内で、状況の切り出し単位がブレていない度合いです。
一貫性が低いとき：
粒度がブレているコンテキスト：
「ケース単位で類似検索、でも AI には直近 5 メッセージだけ渡す」
→ AIの出力：
「過去の類似ケースでは〇〇で解決しましたが、
今回のやり取りを見る限り状況が違うようです」
→ 参照した情報と、判断の根拠がズレる
チェックポイント：
- 「1 単位」の定義を 1 文で言えるか？
- 類似ケースの検索、履歴の参照、要約の単位が揃っているか？
- AI に渡す情報と、AI の出力を検証する単位が一致しているか？
軸横断の品質特性：整合性（Alignment）
3 軸が互いに整合しているかどうかも重要です。
チェックポイント：
- 焦点に対して、境界は過不足ないか？（広すぎ＝ノイズ、狭すぎ＝情報不足）
- 境界に対して、粒度は適切か？（粒度が細かすぎると境界内の情報量が爆発）
- 粒度で切った 1 単位が、焦点に答えるのに十分な情報を含むか？
整合している状態：
- 焦点：トラブルシュート
- 境界：Enterprise + SSO + 該当ユーザー
- 粒度：ケース単位
→ 1 ケースの情報で、トラブルシュートに答えられる
→ 境界内の情報だけで、ケースを構成できる
整合していない状態：
- 焦点：トラブルシュート
- 境界：全プラン、全機能
- 粒度：メッセージ単位
→ 1 メッセージではトラブルシュートに答えられない
→ 全プランの情報が 1 メッセージに対して多すぎる
これらの品質特性は、コンテキスト設計のレビュー観点としても、改善のヒントとしても使えます。「なんとなくうまくいかない」と感じたら、まず純度・密封性・一貫性・整合性のどこに問題があるかを疑ってみてください。
4． コンテキストモデリングで「かなりマシになるところ」と「どうしても残るところ」
コンテキストモデリングは「AI に全部任せる魔法」ではありません。けれど、「どこまでを AI に任せてよくて、どこからは人が決めるべきか」を線引きするには、かなり強い武器になります。
実際のところ、コンテキストモデリングによって、1 章で出てきたあのモヤモヤはどこまで減らせるのでしょうか。
「毎回の整理し直し」や「根拠の見えなさ」は、かなりマシにできます。一方で「最後の一歩を踏み切る怖さ」や「価値判断そのもの」は、どうしても人間側に残ります。
4-1． コンテキストモデリングでかなりマシになるところ
3 章で見たサポート自動回答の例を思い出してください。焦点・境界・粒度が決まっている状態で AI に回答案を出させると、「AI の振る舞い」そのものは相変わらずゆらぐとしても、
-
どのケースの何を参考にしたか
-
どんな種類の問いに対する答えなのか
-
どの前提世界での答えなのか
が、人間から見てだいぶ読みやすくなります。
結果として、
-
ログを上から下まで読んで「結局どういう話だっけ？」と再整理する時間
-
「これ、そもそもこのプランには関係ない話じゃない？」とツッコミを入れる時間
が目に見えて減っていきます。
AI の出力を「正しいかどうか」で一発合格させる、というよりは、
その出力がどの文脈に沿っているかを、構造として揃える
ことで、「扱いやすさ」と「説明しやすさ」が上がるイメージです。
実務的には、たとえばこんな変化が起きます。
-
これまで担当者の頭の中にだけあった「整理の仕方」が、コンテキストモデリングとして外に出てくる
-
「なぜこの情報を候補にしたのか」がログとして残る
-
「この問いには、この文脈セットで AI を呼ぶ」という形で、仕組みとして共有できる
-
「焦点・境界・粒度」の定義がはっきりするため、RAGの検索精度や回答品質をその単位で定量的にテスト（評価）できるようになる
-
境界が明確になることで、範囲外の質問に対して「担当範囲外です」と自信を持って回答を拒否できるようになり、無理に答えようとするハルシネーション（事実に基づかない回答）が減る
ここまで来ると、「毎回自分で一から組み直している感じ」はかなり薄れていきます。
4-2． それでも残るもの：価値判断とリスクテイク
とはいえ、どれだけ文脈を整えても、AI が「最後の責任」まで取ってくれるわけではありません。
たとえば、
-
サポートの現場で、「このラインなら無償対応にしよう」と判断するかどうか
-
調達条件の検討で、「コストを取るか、リードタイムを取るか」を決める瞬間
-
経営会議で、「どこまでリスクを取って新規事業に振るか」を決める場面
こうした局面では、AI は材料を揃えるところまでは手伝ってくれますが、
「どっちを選ぶか」「どのラインで責任を取るか」は、やっぱり人間の仕事です。
モデルの内部で何が起きているかを、きれいに説明できるわけでもありません。
重みの一つひとつを辿って、「だからこの文を返しました」と証明できるようなものでもありません。
なので、コンテキストモデリングをどれだけ頑張っても、
- 最終的な価値判断
- リスクの取り方
- モデル内部のブラックボックス性
といった領域は、原則としてそのまま残ります。
ここを無理に AI に押し付けようとすると、「AI が決めたから」「モデルがそう言っているから」という、誰も責任を取りたくない状態に近づいてしまいます。
それはコンテキストモデリングが目指したい世界ではありません。
4-3． 説明責任の線引きとしてのコンテキストモデリング
では、コンテキストモデリングにはどんな意味があるのか。
ここに説明責任（Accountability）の線引きとしての価値があります。
AI は説明責任を負えません。
「なぜその結論にしたのか」を、自分の言葉で語ることはできません。
けれど、人間側はこう言うことはできます。
この問いに対して、
このユーザー（この案件、この期間）を前提にし、
このケース群と、この条件のもとで、
AI に案を出させた。
つまり、
-
なぜこの問いを AI に投げたのか
-
なぜこの焦点・境界・粒度で文脈を切ったのか
-
なぜこの文脈を「前提としてよし」とみなしたのか
についてなら、人間が説明責任を負えるようになります。
コンテキストモデリングは、「AI の中身を完全に説明する」ためのものではありません。
コンテキストモデリングは、「AI の中身」ではなく「AI に渡した世界」のほうを、人間が説明できるようにするための設計です
この線が引けていれば、
- 「この範囲までは、仕組みとしてこういう前提で AI に任せています」
- 「それを踏まえたうえで、最終判断はこうしました」
と、筋の通った説明がしやすくなります。
逆に、この線が曖昧なまま AI を突っ込むと、
- うまくいったときは「AI すごい」で終わり
- うまくいかなかったときは「AI が間違えた」で終わり
という、誰も責任を持たない状態に陥りがちです。
言い換えると、コンテキストモデリングは「AI の出力そのもの」ではなく、「その出力がどんな焦点・境界・粒度の世界から生まれているのか」を明示する設計だと言えます。
5． AI時代のアーキテクトは「意味のインフラ」を設計する
ここまでの話を振り返ると、コンテキストモデリングが扱っているのは、
「焦点・境界・粒度をどう決めるか」という、その決め方のルールそのものでした。
これは、もともと現場の担当者が頭の中で暗黙にやっていたことです。
ただ、AI が間に入るようになったことで、この暗黙の作業を外に出さないと、いろいろなところが噛み合わなくなってきた。
これまでのアーキテクトは「技術の番人」として語られることが多かったはずです。
AI が入った世界では、それにもう一段、「意味のインフラ」を設計する仕事が乗ってきます。
誰が、どんな文脈で AI に問いを渡し、どこまでの世界を前提に話をしているのか。
その「意味の流れ」を設計できていれば、AI の振る舞いが多少ゆらいでも、システム全体としてどう受け止めるかを説明しやすくなります。
「AI がこう言いました」ではなく、「この文脈を前提に、この問いについて、AI にこういう役割を任せています」と言えるようにする。
そのための"意味のインフラ"を引くのは、やはりアーキテクトの仕事です。
おわりに：あなたの組織では、誰がコンテキストを設計しているか
AI を入れるプロジェクトでは、「どのモデルを使うか」「どのツールをつなぐか」といった話が目立ちがちです。
それ自体は重要ですが、その前後にあるコンテキストは、まだ誰のものでもないまま放置されていることが多いのではないでしょうか。
もし「焦点・境界・粒度」が暗黙のままなら、今は、個人のセンスとプロンプトに依存している状態だと言えます。
最後に、本稿を一言でまとめるなら、
AI 時代のアーキテクトは、「AI の中身」ではなく「AI に渡す世界」と、人間がどこまで責任を持つかという線引きを設計する役割を引き受けることになる
そして、その世界を設計するための実務的なハンドルが、「焦点・境界・粒度」という 3 つの軸だ、というのが本稿のメッセージです。
本稿が皆様の設計のヒントになれば幸いです。
参考文献
非決定性・エージェント / 確率モデル
-
Russell, S., & Norvig, P. (2010). Artificial Intelligence: A Modern Approach (3rd ed.). Prentice Hall.
-
Sutton, R. S., & Barto, A. G. (2018). Reinforcement Learning: An Introduction (2nd ed.). MIT Press.
焦点（Focus / Question under discussion）
- Roberts, C. (2012). Information structure in discourse: Towards an integrated formal theory of pragmatics. Semantics and Pragmatics, 5, 1–69. doi:10.3765/sp.5.6
境界（Boundary / Bounded context）
- Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley.
粒度（Granularity）
- Kimball, R., & Ross, M. (2013). The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (3rd ed.). Wiley.
- Maier, J. F., Eckert, C. M., & John Clarkson, P. (2017). Model granularity in engineering design – concepts and framework. Design Science, 3, e1. doi:10.1017/dsj.2016.16
インテント分類
- Tur, G. and Deng, L. (2011). Intent Determination and Spoken Utterance Classification. In Spoken Language Understanding (eds G. Tur and R. De Mori). doi:10.1002/9781119992691.ch4
Discussion