メインコンテンツへスキップ
Context Grammar文脈を読むAIをデザインする

Context Grammar · Stage 4

Rule Engine:状況を、役に立つ行動へ

役立つ提案は、その場の状況すべてに合い、人と交わした約束を守るものです。Rule Engine は、そうした約束と、決して越えない線を、モデルの手の届かないところに置いておく場所です。

AIの気配りを、確かな判断に変える。

音声:英語

文字起こしを読む

The quick-meal judgment

「20分後には出たいので、すぐ食べられるものを」と客が伝えます。気の利く店員は調理が早い料理を探すだけでなく、熱くて食べるのに時間がかかる料理も避けます。必要なのは、早く出せて、無理なく食べ終えられる一皿。Rule Engineは、AIの応答を考えるときに同じように状況を読み解きます。

01 · Read

学校へ行く朝。お弁当を詰めて出発するまで15分。AIは食材、食事制限、作る時間を確かめます。昨日卵を買ったことは知っていますが、ご飯が炊いてあるかは分かりません。だから、そこだけ尋ねます。これがRead。伝えられたことと記録を集め、まだ分からないことを残します。

02 · Match

ご飯はあります。調理できるのは約8分で、子どもの食事制限も守る必要があります。AIはおにぎりと卵焼きを一案として出します。時間がない朝に長いレシピ比較は要りません。これがMatch。「時間内に作れるものを選ぶ」などのルールを当てはめます。

When rules meet

料理中で手がふさがっていれば音声案内は便利です。でも家族がまだ眠っていて、静かにしてほしい朝なら、声を出さない方がよい。近くの画面に手順を静かに出します。ルールがぶつかったときは、守るべき境界と家の約束を優先し、その場に合う伝え方を選びます。

03 · Emit

方針が決まりました。おにぎりと卵焼きを提案し、手順は短く、選ぶのは親。Emitはその判断を画面へ渡します。スマートフォンではチェックリストと操作ボタン。離れたキッチン画面では遠くから読める大きな文字。同じ判断でも、端末に合わせて見せ方は変わります。

Requirements before preferences

「今日は違う味にできる?」味付けや付け合わせは変えられます。でも食物アレルギーは譲れません。まず必ず守る条件を満たし、その上で好みや変化を選びます。希望には柔軟に、安全には厳密に応えます。

The same rules, a new place

お弁当を詰め、車に乗ります。調理の詳しい手順はもう不要。買い物リストは到着まで待てます。運転中に知らせるのは本当に急ぐ必要があることだけ。場所が変わるたびに設定をやり直さず、同じ約束を新しい状況へ当てはめます。

A guess is not an agreement

「忙しそう」はAIの推測で、外れることもあります。「買う前に聞いて」は人が決めた約束です。気分への推測が明確な境界を上書きしてはいけません。同じ情報と同じルールなら、ルールによる判断は同じ。その一貫性が信頼につながります。

Propose · Check · Present

今夜の買い物をAIが準備するとき、三つの仕組みが連携します。Rule Engineが提案をルールに照らして整え、Negotiation Gateが許可を確かめ、AX Patternsが直せる確認画面を作ります。使う人には、注文案を見て、必要なら直し、買うかどうか決める一つの流れとして届きます。

One source, different views

仕事では同じ調査資料でも、近いチームには詳しい数字が必要で、別の関係者には共有を許された要約だけで十分なことがあります。一つの資料をもとに、相手に合う画面を組み立てます。情報を集め、ルールを当てはめ、何を見せるか画面へ伝える。基本の順序は同じです。

Read · Match · Emit

「なぜ今日のお弁当はこれ?」理由は、出発まで15分で、材料が家にあったから。もし提案が合わなければ判断の根拠を確かめ、ルールを直せます。Readで状況を知り、Matchで約束を当てはめ、Emitでその場に合う形で届ける。理解して、直せるAIの助け方です。

A parent packs rice balls and an omelet into a lunchbox while a child waits at the door.
出発まで15分。分かっていることを読み、足りないことは聞き、合うものを選びます。

01 / 急いでいる日の注文

すぐ作れても、すぐ食べられるとは限らない

レストランで「20分後には出たいんです」と伝えたとします。スープは3分で作れても、熱すぎて食べ終えるまでに時間がかかるなら、今のあなたには合っていません。気の利く店員は、調理時間だけでなく、食べて店を出るまでを考えます。

AIも同じです。答えを一瞬で出せても、読む・確かめる・行動に移す時間が足りなければ助けになりません。Rule Engineは、目的、今の状況、守るべき約束を合わせて、次に何を示すかを決める仕組みです。「理解」と「実際に役立つ表示」の間をつなぎます。本人との約束や譲れない線もここに置かれ、モデルの外にあるので、モデルには書き換えられません。

急ぎの食事を頼む一人客と、時間を考える店員のイラスト

02 / Read:まず確かめる

分かっていることと、まだ分からないことを分ける

次は登校前の朝です。出発まで15分。子どものお弁当が必要です。家族のBrainはアレルギーを覚え、昨日卵を買った記録もあります。でも、買った記録だけで、今も卵が残っているとは言えません。炊飯器にご飯があるかも分かりません。

Readでは、Intent、Situation Signals、Relationship Dials、Brainの情報を集めます。その情報がどこから来たか、今も正しそうかも一緒に扱います。答えを左右する情報が一つ足りなければ、「ご飯は残っていますか?」とだけ尋ねる。知っていることを何度も聞かず、古い情報を今の事実として扱わないためです。

出発前、子どものお弁当を考える家族のイラスト
01 / 分かっている

出発まで15分。子どものアレルギーは登録されている。

02 / まだ不確か

昨日卵を買った。でも今も残っているとは限らない。

03 / 必要な一問

炊飯器にご飯は残っていますか?

03 / Match:条件を合わせる

今できる、一つの提案に絞る

ご飯と卵があると確認できました。身支度を考えると、調理に使えるのは8分ほど。ここでレシピを12案並べられても困ります。Matchは実際に作れるものを残し、絶対に守る条件に反するものを外して、おにぎりと手早い卵焼きという一案を選びます。

速さだけで選ぶわけではありません。アレルギー、手元の食材、調理と詰める時間、考える余裕まで見ます。人なら自然にしている判断を明確なルールにすることで、似た朝に毎回違う基準で迷わないようにします。

おにぎりと卵焼きの具体的な一案を描いたイラスト

04 / 条件がぶつかったら

一つの手がかりだけで決めない

調理中で手が油まみれなら、音声が便利そうです。でも家族はまだ寝ています。「手がふさがっているから音声で話す」と「静かにする」という条件がぶつかります。

Rule Engineは表示する前に、その優先順位を考えます。近くの画面に短い手順を静かに出して、ちらっと見れば分かるようにできるでしょう。使える機能があるからといって、プライバシーや安全の約束を破ってよいわけではありません。安全な伝え方がなければ、待つか後で尋ねます。

家族が寝ている朝、キッチン画面で静かに確認するイラスト

05 / Emit:伝え方を指定する

判断は一つ、画面ごとに見せ方を変える

Emitは、決めた内容をui.commandという共通の指示にまとめます。たとえば「お弁当を一案だけ提案」「手順は最小限」「声は出さない」「最後に選ぶのは親」。これは完成した画面の画像ではなく、どの端末でも守るべき意味の指定です。

携帯なら、指で確認できる短いチェックリスト。キッチンの画面なら、離れていても読める大きな二手順。同じ判断を保ちながら、その場所の端末に合った形で見せられます。

共通の判断

おにぎり+卵焼き・8分・音声なし・親が決める

携帯・タッチで確認

① おにぎりを作る ② 卵焼きを焼く

キッチン画面・ひと目で確認

おにぎり → 卵焼き

06 / Rule Engine が持つもの

約束、頼まれたこと、ゆとり、越えない線

Rule Engine が持つものは四つです。約束:本人が言ったこと。本人の言葉のまま、日付と理由とともに残します。頼まれたこと:何を頼まれ、どこで終わりか。ゆとり:頼まれた範囲の中で調整できる幅。頼まれた分の境目やその先のことは、本人に差し出すだけで、頼まれずにやることはありません。線:決して越えないこと。

アレルギーは越えない線です。明示したプライバシーの境界や予算の上限も同じです。手軽で人気のある候補でも、その線を越えるならRule Engineは候補から外します。

味付け、おかずの組み合わせ、見せ方は柔軟に変えられます。食材が足りなければ、別の味付けを提案してもいい。でも2分早くなるからといって、アレルギーの条件を緩めてはいけません。確かな情報が足りなければ、確認するか安全な案に戻します。

AI と一緒に作るときも、この四つは同じです。頼まれた19件の作業は終わりました。途中で見つけた3件の問題は頼まれた分の先にあるので、一覧にして差し出すだけで、直しません。直すかどうかは、本人の新しい判断です。

約束

「買う前に確認して」・言葉、日付、理由

頼まれたこと

今朝のお弁当一つ・詰め終えたら完了

ゆとり

味付け・副菜・見せ方・それ以上は提案だけ

越えない線

アレルギー・プライバシー・予算上限

07 / キッチンから車へ

同じ人でも、次の瞬間には状況が変わる

数分後、あなたは車を運転しています。お弁当のことは覚えていても、キッチンの手順を車の画面に出すべきではありません。手も目も運転に使うからです。急がない買い物情報は控え、どうしても必要な経路変更だけを短く安全な方法で知らせる。それさえ邪魔になるなら待ちます。

部屋を出るたびに設定を変える必要はありません。身体の状態、考える余裕、今の優先事項、使える端末が変わると、同じルールから別の応答が生まれます。

運転中、画面を見続けず道路に集中する人のイラスト

08 / 推測と約束

「急いでいそう」は、購入の許可にはならない

「急いでいそう」はAIの推測です。「買う前に必ず確認して」は本人との約束です。推測を使って説明を短くしても、購入確認を飛ばしてはいけません。情報が古かったり欠けたりしているときほど、AIに任せる範囲が勝手に広がることはありません。

同じ状態、つまり同じ情報、同じ約束、同じルールなら、Rule Engineが出す許可の結果(進める・聞く・止まる)は同じになります。伝え方の言葉はモデルが書くので変わることがありますし、刻々と変わる在庫も別の話です。ただ「どの情報を見て、どのルールが優先され、なぜ実行・停止したか」は確かめられ、テストできます。

体験から、仕組みへ

Read → Match → Emit → 次の段階

ここまでの話には、明確な仕組みがあります。次の図は、各段階が何を担当するかを振り返るためのものです。使う人がこの専門用語を覚える必要はありません。

01 / 04

Read

Intent、Signals、Dials、Brainの情報を集め、出典・鮮度・不明点を残す。

02 / 04

Match

越えない線、約束、頼まれたこととそのゆとり、優先順位を照合し、矛盾を解く。頼まれた分の先は提案にとどめる。

03 / 04

Emit

内容・情報量・伝え方・誰が決めるかを、端末に依存しないui.commandにまとめる。

04 / 04

次へ

Negotiation Gateが実行・確認・停止を判断し、AX Patternsが体験を形にする。

作り手へ:結果だけでなく、使われたルールを見られるように

context.ymlのような定義でSignalsとDialsの値を揃え、rules.ymlのようなルールで条件・結果・優先順位を定め、ui.commandを各端末が共通に読みます。どの情報とルールで判断したかを記録し、安全や信頼に関わる強い条件を便利さのための弱いルールが上書きしないようにします。仕様にあるルール番号や件数、優先度の数値は「現行版」の参考値で、定義ではありません。

intent + signals + dials + brain
  → read(source, freshness, unknowns)
  → match(requirements, preferences, authority)
  → ui.command(content, density, channel, decision_by)
  → negotiation_gate → AX patterns

同じルールで、朝の二つの場面を比べる

キッチンと車を切り替えてください。ルールは同じまま、今のSignalsと出す指示だけが変わります。

Signals in

手がふさがる・家族は就寝中・残り8分

ui.command out

キッチン画面に、お弁当の一案を静かに表示。決めるのは親。

09 / 一つの情報、相手ごとの見せ方

誰に見せるかで、必要な詳しさが違う

仕事でも同じ判断を別の形で見せることがあります。技術チームには細かな測定値や未解決の懸念が必要かもしれません。経営層には結論と確かさ。社外の顧客には合意した提案と日程だけが適切かもしれません。

Rule Engineは相手に合った表示を指示できますが、実際に何を見せてよいかはDisclosure Dialとアクセス権が決めます。見た目を整えるだけで秘密情報が安全になるわけではありません。必要な権限や事実がなければ、その情報は出さず、確認を求めます。

同じ仕事の情報を相手ごとに見せ分けるイラスト

10 / 分かる・直せる

なぜそうしたかが分かり、間違いを直せる

役に立つ提案には、普通の言葉で理由を添えられるはずです。「調理できるのが8分で、ご飯と卵があると確認でき、アレルギーを避ける必要があるので、おにぎりと卵焼きを提案しました」。そう聞けば、思い違いにもすぐ気づけます。

予定が違ったり、ご飯がなかったりしたら、情報を直して提案も変えられます。使ったルールも記録されるので、同じ失敗が続くなら設計を改善できます。Rule Engineが応答を提案した後は、Negotiation Gateが、進めてよいか、確認が必要か、止めるべきかを判断します。

次の章

次は、いつ人に確認するか

Rule Engineが応答を提案した後、Negotiation Gateがリスク、確かさ、あなたとの約束を確認します。