AIが処理するタスクにある“Intelligenceの要・不要”を把握する

（5）情報の構造とフローだけでなく中身にまで踏み込む

　3人目の登壇者は、大企業と法律事務所向けに契約などに関する事業を展開するリーガルテック・カンパニーMNTSQ（モンテスキュー）の共同創業者であり、PM兼デザイナーの生谷侑太郎氏。同社では契約書などのドキュメントの解析にAI技術を用いている。

　生谷氏はAIをIntelligenceまたはIntelligent softwareと呼ぶ。AIと従来のソフトウエアはどちらも「ユーザーが困っていることを技術で解決する」ものである点で基本的に変わらない。Intelligenceが必要となるかどうかは、解決すべきタスクによる。

　記録／更新（ある情報を入れたらそれが記録される）、取得（ある条件を入れたらその条件に合ったDBに記録済みの情報が返ってくる）、集計／可視化（ある条件を入れたらその条件に合ったDBに記載済みの情報が構造化された形で返ってくる）などはIntelligenceが要らないタスク。分類（書類をアップロードすると、それが秘密保持契約なのか定款なのか契約書ではない謎の書類なのかを分類）、抽出（書類をアップロードすると締結日や取引先、危険な条項などを見つけてデータ化）、推薦（商品Aを買うと「こちらもどうですか？」と商品Bを提案）などはIntelligenceが必要なタスクの例になる。

　両者を比較すると、「常に正解を返せる仕様（手続き）を定義できない時」と「入力情報が抽象的な（構造化されていない）時」の2つがIntelligenceの出番であると整理できる。

　Intelligenceを必要とするタスクでは、プロセスの最後に不確実性を持った新情報が発生するのが大きな違いだと生谷氏は言う。「書類をアップロードすると必要な情報が抽出される」というプロセスだけ聞けば非常に便利そうだが、プロセスが良くても結果が良いとは限らない。締結日が検出できなかった、締結日の0がOになっていた、取引先として「以下、乙と呼ぶ」まで抽出してしまった、などさまざまな残念な体験も起こり得る。

　ここで難しいのは、プロトタイプではこうしたさまざまな結果を見ることができないこと。本物に近いデータセットと開発済みのアルゴリズムによる検証が必ず必要になる。言い換えれば、デザイナーは情報の構造とフローの設計だけでなく、中身にまで踏み込んでいく必要がある。そこまでやらないとデザインの骨格が決まらないのがIntelligenceを必要とするタスクのデザインの難しさだと生谷氏は言う。