【ITニュース解説】Two conditions, one product, and the rule we deliberately apply to only one of them

Munchableというアプリは、複数の健康状態を持つ人々が、特定の食品が自分に合っているかどうかを判断する手助けをする。例えば、逆流性食道炎と過敏性腸症候群（IBS）の両方を抱えている人が、同時に食品の適合性を知りたい場合を考えてみよう。この状況では、一つの食品に対して「これは逆流性食道炎には大丈夫だが、IBSには良くない」といったように、複数の条件間で異なる判断が出る可能性がある。この複雑な状況で、アプリがどのように「正しい」答えを導き出し、ユーザーに伝えるかについて、その裏側のシステムロジックを見ていく。

まず、最も重要な原則の一つが「最悪を優先する」という考え方だ。もしある食品が、ユーザーが持つ複数の健康状態のうち、一つには「良い」と判断され、もう一つには「注意」や「避ける」と判断された場合、アプリは最も厳しい判断、つまり「注意」や「避ける」を最終的な結果としてユーザーに提示する。これは、健康アプリでよく見られる、各条件の評価を数値化して平均点を出すようなアプローチとは異なる。例えば、ある食品が逆流性食道炎には「良い」が、IBSには「避けるべき」とされた場合、アプリは決して「まあまあ」のような中間の評価を出さない。なぜなら、IBSにとって危険な食品は、逆流性食道炎にいくら良くても、最終的にはユーザーの健康を害する可能性があるからだ。玉ねぎが良い例で、逆流性食道炎には問題なくても、IBSには危険である場合、アプリは「避ける」と明確に伝える。これは、ユーザーをトラブルから遠ざけるための、安全第一の設計思想と言える。

しかし、アプリは単に「避ける」という最終判断だけを伝えるわけではない。各健康状態ごとの具体的な判断結果も、捨てられることなく保持されている。ユーザーは、最終的な「どうすべきか」だけでなく、「なぜその判断になったのか」という詳細を、タップ一つで確認できる。これにより、ユーザーはアプリの判断の根拠を理解し、自身の体調や状況に合わせて最終的な判断を下すための、より多くの情報を得られる。

次に、データの信頼性に関する重要なロジックがある。アプリは、データの品質や網羅性が不十分な場合、安易に「良い」という判断を下さない。「良い」という緑色の表示は、データが信頼できる場合にのみ許可される。もし、評価に必要なデータが不足している、あるいは選択された条件の一部が評価できない場合、最終的な判断が「良い」であっても、安全のために「注意」に格下げされることがある。この「データが不十分な場合は良いと表示しない」というルールは、アプリ全体で一貫して適用される。もし異なる画面でこのルールがバラバラに適用されたら、アプリは矛盾した情報を提示し、ユーザーを混乱させてしまうからだ。

ただし、このデータの信頼性に関するルールにも、例外というか、より細かな配慮がある。もしユーザーが複数の条件を選択し、そのうちの一つが、対象の食品について評価できない（データがない、など）場合、全体としての最終判断は「良い」から「注意」に格下げされる。これは、最終判断が「すべての条件」について保証するものであり、その一部に不明な点があれば、安全のため控えめな判断にする、という考え方に基づいている。しかし、評価できた他の条件については、その評価結果（例えば「良い」）はそのまま維持される。評価できなかった条件が「良い」と判断された条件に影響を与えるのは、不必要な不正確さにつながるからだ。

さらに、複数の条件間で判断が「良い」と「注意/避ける」のように食い違った場合、アプリはその「不一致」自体をユーザーに明示する。例えば、アーモンドは胃不全麻痺の症状がある人には「注意」が必要な場合があるが、低FODMAP食の人にとっては特に問題ないとされる。このようなケースで、アプリは単に「注意」とだけ伝えるのではなく、「一つには合うが、もう一つには注意が必要である」という形で、両方の情報を伝える。この「不一致」を示すメッセージは、具体的な理由を一つだけ提示するように設計されている。複数の理由をすべて並べると、情報過多で読みにくくなってしまうため、最も重要と思われる理由（特に「避ける」につながる理由）を優先して表示する。そして、この理由のメッセージは、文中に自然に組み込めるように、自動的に小文字に変換されるなどの工夫もされている。これは、ユーザーがスーパーマーケットで素早く情報を確認する際の使いやすさを考慮したものだ。

このアプリのロジックには、ユーザーが設定する他の要素も関わってくる。一つは「アレルギー」だ。もしユーザーが特定のアレルギーを持っていると宣言し、そのアレルゲンが製品に含まれている場合、他の健康条件がどう判断しようと、その製品は問答無用で「避ける」と判断される。これは、健康条件よりもアレルギーのほうが、生命に関わるリスクが大きいため、すべてのルールに優先して適用される。

もう一つは「健康的な買い物フィルター」と呼ばれるものだ。これは「人工着色料を避けたい」といった、より個人的な好みや健康への配慮に関する設定だ。このフィルターは、アレルギーほど厳しくなく、最終的な判断を「注意」までにしか引き下げない。「避ける」とまではいかない。これは、アレルギーによる危険と、個人的な好みを満たせないこととでは、その重みが全く異なるため、システムもそれに応じて異なる扱いをする必要があることを示している。これらの上位レイヤーのルールは、一度最終判断を押し下げることがあっても、決して判断を「持ち上げる」ことはない。つまり、アレルギーがないからといって、その食品が健康に良いと保証するわけではないのだ。

最後に、システム設計における「条件」と「ダイヤル」の区別についても触れておこう。例えば「乳糖不耐症」は「条件」ではなく、その「乳糖への感度」が「ダイヤル」だと考えられている。もし「乳糖不耐症」を一つの条件と見なしてしまうと、その感度設定によって常に同じ判断が下されることになり、アプリの「複数の条件が矛盾した場合の表示」というロジックにノイズを生じさせる。また、感度設定を「診断」と混同させてしまう可能性もある。この区別を判断する簡単なテストは、「二つのものが互いに矛盾する可能性があるか？」というものだ。もし矛盾する可能性があれば「条件」、そうでなく、一方の値がもう一方の判断基準を調整するだけであれば「ダイヤル」と見なす。これは、システムの構成要素を適切に定義し、ロジックをシンプルかつ正確に保つための重要な考え方だ。

Munchableアプリのこれらの複雑なロジックは、ユーザーの安全と利便性を両立させるために、綿密に設計されている。複数の情報源からのデータ、多層的なルール、そして人間らしいコミュニケーションの側面まで考慮されており、システム開発において単に機能を実現するだけでなく、ユーザーが実際にどのように情報を受け取り、行動するかまで深く考えることの重要性を示している。