デザイン思考から発明のポイントを見つける方法 ――現場の課題を、技術的な工夫へ変える

執筆・文責：弁理士　中村幸雄

AIによって、アプリケーションの作成コストは大きく下がりました。以前であれば専門的な知識や多くの時間が必要だったものも、今では小さなチームでもかなりの速さで形にできるようになりました。

しかし、AIシステムをリリースした後の壁——導入はしてもらったが数週間後には誰も使っていない、AIが提案を出しているのに、担当者が結局ゼロから自分で判断し直している、自動化したはずのフローを、現場が毎朝手作業で確認している——こうした現場の課題は、何も変わっていません。

実はこのような現場の課題の先には、技術的な工夫の種が隠れています。今回は、デザイン思考の視点でその整理の仕方を考えてみます。

論理的思考・デザイン思考・アート思考

問題を解くアプローチには、いくつかの異なる起点があります。

論理的思考は、前提を整理し、筋道を立てて答えに近づく考え方です。すでに見えている問題を、矛盾なく効率よく解くことに向いています。ただし、「前提が正しい」という枠の中で動きます。たとえばログを見て離脱ポイントを特定し、UIを直す——これは論理的思考の典型ですが、「離脱率を下げる」という前提を置いた瞬間、解はUIの最適化に閉じてしまいます。「使われない」本当の理由が前提の外にあると、論理だけでは届きません。

デザイン思考は、前提を疑い、現場で観察された行動そのものを出発点にする考え方です。「なぜ使いにくいのか」ではなく「なぜここで人間が手作業に戻るのか」を、行動から読みます。問題の手がかりは、すでに現場にあります。ただ、それがまだ十分に言語化されていない。そこに切り込む思考です。

アート思考は、市場の要望や既存の課題からではなく、作り手自身の関心や違和感を起点に、まだ形になっていないコンセプトを生み出そうとする考え方です。解くべき問題は最初から与えられていません。問い自体を、自分でつくります。

→ アート思考から、発明のポイントを見つける方法（コラム）

本記事で扱うのは、このうちデザイン思考から発明のポイントを見つける方法です。

デザイン思考は、発明の入口を現場に見つける

デザイン思考では、現場の行動を観察するところから始まります。観察された行動は、設計の欠落を指し示す矢印です。そこに、発明の入口があります。

現場での問題は、たいていは、日常業務の中の小さな引っかかりとして現れます。

これらの課題をよく見ると、それぞれに「なぜ」があります。

要約を信用できないのは、根拠がどこにあるのか分からないからかもしれません。ログを目視確認するのは、自動処理が何をしたのかを誰も把握していないからかもしれません。AIの提案が採用されないのは、提案の前提条件が現場の実態とずれているからかもしれません。

デザイン思考の視点では、こうした現場の行動そのものが手がかりになります。人がなぜ使わないのか。どこで不安を感じているのか。どの確認作業を手放せないのか。どの場面で判断が止まるのか。そこを観察すると、システム側でまだ設計できていない処理が見えてきます。

デザイン思考の5ステップを、発明探索に重ねる

デザイン思考には、よく知られた5つのモードがあります。観察（Empathize）→ 定義（Define）→ 発想（Ideate）→ 試作（Prototype）→ 検証（Test）。このプロセスは、発明の探し方にそのまま重なります。法務・労務向けの書類チェックAIを例に、順番に見ていきます。

①観察（Empathize）――現場の行動を評価せずにそのまま見ます。「担当者がAIによる指摘を見た後で、結局ゼロから自分で確認し直す」といった行動です。

②定義（Define）――観察した行動を技術的な問いに翻訳します。AIが指摘事項のみを出力し、どのルールの、どの箇所を、どれくらいの自信で指摘しているのかを検証できないからではないか。検証できる形にするには、システムは何を持てはいいのか？といった具合です。「信用できない」という感情を、設計の言葉に置き換えるのです。ここが一番大事な工程です。

③発想（Ideate）――技術的な解決手段を出します。

④試作（Prototype）――その解決手段で最小構成を組みます。

⑤検証（Test）――「担当者がAIの結果を見た後で、自分で確認し直さなくなったか」を検証します。

デザイン思考では、①の入口（観察）と⑤の出口（検証）が同じ「行動」で閉じられており、途中の③の解決手段が効果的であるかを検証できるという特徴があります。

「根拠を見せる」はUI、「根拠をどう持つか」はアーキテクチャ

今回の書類チェックAIの例で、発明の種となるのは、AIがデータをどう持ち、どう処理するかというアーキテクチャ（構造）です。以下のような3つの工夫が互いにつながって、一つのアーキテクチャを構成する、そのあたりがポイントになりそうです。

第一に、AIの指摘を「正しい／怪しい」という結果だけで保存するのではなく、〈AIの指摘・該当箇所・参照元・確信度〉という4つをセットにして保存するのはどうでしょうか。これにより、以下の効果が期待できます。

• AIによる指摘の「確信度」を表示することができるため、担当者は、確信度が高い指摘はそのまま採用し、低いものだけ見直すという運用を行うことができる。
• 担当者が見直しを行う場合にも、「参照元」に基づいて根拠となるルールへ即座に移動することができ、確認が手軽になる。

第二に、担当者がAIの指摘を信用できず、結局手作業で修正したという行動を、そのままAIを育てる素材にしてもよいかもしれません。すなわち、AIの指摘が「そのまま採用されたか／人間が修正したか」という結果を記録し、それを以下のように活用するアイデアもあります。

• 短期的には、人間が修正することの多いパターンについては「確信度」を自動で引き下げる。
• 長期的には、蓄積されたデータを使って学習し、判断の精度そのものを向上させていく。

第三に、法律の改正や、社内の契約ひな型の更新で前提が変わったときに、「参照元」に基づいて選択的に書類を再チェックしてもよいかもしれません。ここでも〈AIの指摘・該当箇所・参照元・確信度〉という4つのセットを保存する第一の工夫が効いてきます。

このように、これら3つの工夫は独立したものではなく、デザイン思考の観察から出発した解決策が、一貫したシステムの骨格となっていることが分かるでしょう。

問題は、そのままでは発明にならない

現場での問題の発見は重要ですが、それだけでは「要望」にとどまります。発明として問われるのは、その要望を、どのような技術的な仕組みで実現しているのかです。

先ほどの〈AIの指摘・該当箇所・参照元・確信度〉というデータの持ち方や使い方、人間によるやり直しをAIの改善に役立てるフロー、参照元による選択的な再チェック——このように、「システムがどうデータを受け取り、どう処理し、どう判断するか」という具体的な設計にまで落とし込んで、初めて発明として土俵に上がります。

特許の勝負どころには「２つの顔」がある

技術的な工夫には、外から見えにくい「裏側のシステム構造」と、見えやすい「表側の製品機能」があります。先ほどの例では以下のように分類できます。

裏側のシステム構造

• 〈AIの指摘・該当箇所・参照元・確信度〉という4つのセットを保存する。
• フィードバックに基づく確信度の自動更新。
• 蓄積データによるモデルの再学習。

表側の製品機能

• AIが指摘事項とともに「確信度」を表示する機能。
• 担当者が見直す場合に「参照元」を使って根拠にアクセスできる機能。
• 前提が変わった時、影響がある部分だけをシステムが再チェックする機能。

特許出願を行うとその内容は公開されますが、「裏側のシステム構造」の場合、競合他社が模倣していても、その侵害行為の把握が難しい場面があります。よって、このような場合には営業秘密として管理する選択肢もあります。

一方、「表側の製品機能」は、サービスを提供すれば公知となり、特許権を取得していなければ堂々と模倣されてしまいます。特に、「表側の製品機能」は、セールスポイントとなるケースも多く、競合他社の模倣の発見も比較的容易です。よって、このような表に見える機能を特許で抑える価値が高いと言えます。

発明の入口を探すために

デザイン思考によって現場の課題を観察し、解決策を探る一連のステップは、発明の入口を見つけるためのステップでもあります。そして、見つけた工夫を見える工夫と見えにくい工夫に切り分けて考えると、守り方も見えてきます。

発明の余白では、そうした現場の課題や業務フローを整理しながら、どこに発明のポイントがあるのか、特許と営業秘密をどう使い分けるのかを、一緒に確認します。