【前編】デザイン思考から発明のポイントを見つける
AIが浸透し、アプリケーションの作成コストは大きく下がりました。以前なら数ヶ月かかっていたものが、今では小さなチームでもかなりの速さで形にできます。
でも、リリースした後に壁がある。「導入してもらったのに、数週間後には誰も使っていない」「AIが提案を出しているのに、担当者が結局ゼロから自分で判断し直している」「自動化したはずのフローを、現場が毎朝手作業で確認している」
「使われる」ための壁は、何も変わっていません。実は、この壁は、発明の入口になることがあります。
今回は、デザイン思考の視点でその整理の仕方を考えてみます。
今回のポイント
リリースしたサービスの「使われない」「手が止まる」「信用できない」は、発明の入口になる。
デザイン思考の5ステップ(観察→定義→発想→試作→検証)は、発明探索のプロセスに重なる。
問題そのものは特許にならない。「どういう技術的な手段で解決するか」まで落とせて初めて検討できる。
「表の機能は特許で牽制、裏の構造は営業秘密で守る」という切り分けこそが、ビジネス価値を生む。
発明のポイントはどこに現れるか——思考の3類型
はると:なあ、りょう、うちで法務・労務向けの書類チェックAIをリリースしたんだけどさ。似たようなサービスが世の中にいっぱいあって、正直どう差別化すればいいか悩んでて。特許って取れるものなのかな。
りょう:その悩み、すごくよくわかる。でも切り口の問題だと思う。「何を作るか」で考えるより、「なぜ使われないのか」から考えると、発明のポイントが見えやすくなるんだよ。
はると:なぜ使われないのか、か。
りょう:問題を解くアプローチって大きく3つあって。まず論理的思考、これは与えらえた前提と条件を整理して最適解を出す考え方。
はると:それはやってる気がするな。ログ見て離脱ポイント特定して、そこのUIを直したり。でも、それで頭打ちなんだよな。
りょう:そうなんだ。論理的思考は強力だけど、「前提が正しい」という枠の中で動くからね。本当の理由が前提の外にあると、論理だけでは解決できない。
はると:じゃあ2つ目は?
りょう:デザイン思考。これは前提を疑って、現場で観察された行動そのものを出発点にする。「なぜ使いにくいのか」じゃなく「なぜここで人間が手作業に戻るのか」を、行動から読む。3つ目はアート思考——作り手自身の違和感から出発するやつ——はまた今度話すとして、今日はデザイン思考の話にしよう。
はると:現場観察が、特許とどうつながるの?
りょう:そこが面白いところで。現場で使われない理由の奥には、まだ設計されていない処理や判断条件が隠れてることが多い。そこに発明の入口があるんだ。

デザイン思考の5ステップを、発明探索に重ねる
りょう:デザイン思考って、よく知られた5つのモードがあるんだ。観察 → 定義 → 発想 → 試作 → 検証。これ、発明の探し方とも重なるんだよ。
はると:重なる?
りょう:順番に行こう。書類チェックAIで言うね。
① 観察(Empathize)——現場での行動を評価せずに観察する。担当者がAIによる指摘を見た後で、結局ゼロから自分で確認し直している。
② 定義(Define)——観察した行動を技術的な問いに翻訳する。AIが指摘事項のみを出力し、どのルールの、どの箇所を、どれくらいの自信で指摘しているのかを検証できないからではないか。検証できる形にするには、システムは何を持てはいいのか?
はると:あ、「信用できない」って感情を、設計の言葉に置き換えるのか。
りょう:そう。これが一番大事な工程。その後の工程が以下。
③ 発想(Ideate)——これに基づいて技術的な解決手段を出す。
④ 試作(Prototype)——その解決手段で最小構成を組む。
⑤ 検証(Test)——「担当者がAIの結果を見た後で、自分で確認し直さなくなったか」を検証する。
りょう:③の解決手段が発明、⑤の検証結果が発明の手応え(効果)になる。
はると:観察した行動が、最後の検証指標にまで戻ってくるんだ。
りょう:そこがデザイン思考の筋。入口(観察)と出口(検証)が同じ「行動」で閉じてる。だから途中で出した技術的手段が、ちゃんと現場の問題に効いてるか確かめられる。
「根拠を見せる」はUI、「根拠をどう持つか」はアーキテクチャ
はると:で、③の発想。具体的にはどんな技術的手段になるの?
りょう:この例で、解像度を一段上げようか。差別化できるのは、「AIがデータをどう構造化し、その構造を使って何ができるか」なんだ。
はると:構造を使って、何ができるか……
りょう:3つ、具体的につなげて見せるね。
(1)AIの回答を「証明書付きのセット」で保存する
りょう:AIのチェック結果を、ただ「正しい/怪しい」という文字だけで保存しない。AIの答えを〈AIの指摘・該当箇所・参照元・確信度〉という4つをセットにして保存するんだ。 「どのルールの、どの文章を読み取って、どれくらいの自信でその指摘を出したのか」。これをパッケージ化して保存しておく。
はると:なるほど。でもさ、保存だけで、なんで担当者が確認し直さなくなるの?
りょう:この例で大切なのは、AIによる指摘を4つの単位に分解したこと。これで現場で2つのことが起きる。
はると:分解か..…
りょう:ひとつは選別。AIの指摘に「確信度」が保存されているから、それを指摘とともに表示することができる。担当者は「確信度が高い指摘はそのまま採用、低いものだけ見直す」とできる。全件を疑う必要がなくなるわけだね。
はると:それは確かに効果ありそうだな。
りょう:もうひとつは確認の手軽さ。担当者が見直す場合にも、AIの指摘の「参照元」が保存されているから、根拠となルールや文へ即座に飛んで確かめられる。
はると:これなら、使ってみようと思うな。
りょう:そうそう、そして、この4つの単位をセットで持っていることが、次の仕掛けの土台になる。
(2)人間の「やり直し」を、AIの改善にフィードバックする。
りょう:ここがデザイン思考と技術がつながる山場だよ。さっき観察した「担当者がAIを信じられず、結局手作業で直す」という行動。あれをそのまま、AIを育てる素材にする。
はると: 行動でAIを育てる?
りょう: (1)で保存した〈AIの指摘〉に対して、「そのまま採用されたか/人間が直したか」という結果を記録する。これが活きる。
はると:というと?
りょう:短期的には、人間の直しが多いパターンについては確信度を自動で引き下げる。長期的には、蓄積されたデータを使って再学習し、判断の精度そのものを上げていく。つまり、(2)のフィードバックによってシステムが賢くなり続ける。
はると:(1)でデータを4つの単位のセットで保存し、AIの回答に使用し、(2)で人間から学ぶ。じゃあ3つ目は?
りょう: 前提が変わった時の再チェック。例えば法律の改正や、社内の契約ひな型が更新されたとする。この時、過去の書類を全部AIで再チェックするのは現実的じゃないよね。
はると: 現場がパンクするね。
りょう: ここで再び(1)の出番。データの中に「参照元」が記録されているから、システムは「変更があったルールに依存して判断した過去のチェック」だけをピンポイントで探し出せる。
(3)前提が変わったときに、「参照元」に基づいて選択的に再チェック。
はると: あ!(1)のデータ構造があるから、(3)の「そこだけ再チェック」ができるのか。
りょう:気づいた? 3つはバラバラの機能じゃなくて、ひとつの繋がったアーキテクチャなんだよ。デザイン思考の「観察」から出発した解決策が、一貫したシステムの骨格になってるでしょ。
→AIの指摘を4つの単位に分解してセットで持つ。
→単位に分解しているから担当者はメリハリをつけて確認でき、確認時の手間も削減できる。
→そのデータと人間の修正行動を掛け合わせてAIがさらに賢くなる。
→ ルールの変更にもピンポイントで対応できる。
問題は、そのままでは発明にならない
はると:じゃあ「信用できる出力を作りたい」って思ったら、もう発明ってこと?
りょう:いや、それはまだ「要望(アイデア)」なんだ。特許の世界で問われるのは、その要望を「どういう技術的な仕組みで解決したか」なんだよ。
はると: 仕組みまで落とし込まないとダメなんだ。
りょう: そう。さっきの〈AIの指摘・該当箇所・参照元・確信度〉というデータの持ち方や使い方、人間の「やり直し」をAIの改善に役立てるフローがあったよね。 フワッとした要望を「システムがどうデータを受け取り、どう処理して、どう判断するか」という具体的な設計図にまで落とし込んで、初めて「発明の構成」として土俵に上がるんだ。
はると: なるほど。で、結局うちのサービスの場合、どこが特許になりそうなの?
りょう: いい詰め方だね。実は、経営や事業の視点から見ると、特許の勝負どころには「2つの顔」があるんだ。
はると: 2つの顔?
りょう: ひとつは、さっき話したAIのデータ構造や改善ループのような「裏側のシステム構造」。もうひとつは、その構造があるからこそ実現できる「表側の製品機能」。 この2つは、知財としての守り方がまったく違うんだよ。
はると: 守り方が違う?
りょう: うん。まず「裏側の構造」だけど、これは特許を出願せずに「営業秘密(ノウハウ)」として隠しておくべきかもしれない。
はると: え、特許とらないの? 苦労して考えた仕組みなのに。
りょう:特許を出願すると、その技術の仕組みは世の中に公開される。もし競合が公開された特許を見て、自社のサーバーでこっそりそのデータ構造や改善ループを真似したとする。はると、それ見抜ける?
はると: あ……他社のサーバーの中のコードまでは見られないから、真似されたことを証明できないか。
りょう: その通り。せっかくの発明も、「他社が真似したこと(特許侵害)」を証明できなければ武器にならない。タダで競合に賢いシステムの作り方を教えるだけになってしまう。だから、外から見えない裏側の仕組みはブラックボックス化して、営業秘密にするのも一つの手なんだ。
はると: なるほど! じゃあ、特許を狙うべきなのは……
りょう:もうひとつの顔、「表側の製品機能」だよ。 今回の例で言えば、(1)のAIが指摘事項とともに「確信度」を表示する機能とか、担当者が見直す場合に「参照元」を使って根拠にアクセスできる機能、参照元による選択的な再チェック機能とか、(3)の前提が変わった時、影響がある部分だけをシステムがピンポイントで炙り出して再チェックする機能とか。これはユーザーの画面上で動くから、競合が真似したも外から分かりやすい。
はると: 確かに! しかもこれ、うちのサービスのセールスポイントになるな。
りょう: そう! だから知財戦略としては、この「表の売れる機能」を特許のメインに据えて他社を牽制する。一方で、それを実現するための「裏の賢い仕組み」は営業秘密として隠し、誰も追いつけない性能差を維持するんだ。
はると: そうか……! 最初から機能を「表」と「裏」に分解してあるから、「これは特許で牽制しよう」「こっちは秘密にしよう」っていう戦略が立てられるのか。
りょう: そういうこと。実際に特許として権利化できるかは先行技術との関係などにもよるけど、この「表と裏の切り分け」が絶対に必要になる。 「なぜ現場で使われないのか」を観察し、そこから生まれた「表の売れる機能」と「裏の隠れた技術」を戦略的に使い分けることで、競合が真似できないビジネス価値が生まれるんだ。
今回のまとめ
「使われない」「手作業に戻る」「信用できない」の裏側には、まだ設計されていない処理や判断条件が隠れている。それは観察された行動からしか見えないので、前提を固定する論理的思考ではなく、デザイン思考が効く。
デザイン思考の5ステップ(観察→定義→発想→試作→検証)は、発明探索のプロセスにそのまま重なる。入口(観察された行動)と出口(その行動が変わったか=技術的効果)が同じ「行動」で閉じるから、出した手段が現場に効いているか確かめられる。
知財には「表の機能」と「裏の構造」という2つの顔がある。外から動きが見える「表の機能」は、真似されればすぐにバレるので特許で牽制する。外から見えない「裏の構造」は、特許にすると仕組みを公開するだけで侵害を立証しにくいので、営業秘密として隠すという使い分けが要る。
観察から生まれた工夫を「守り方」まで設計したとき、競合が簡単には追いつけないビジネス価値が生まれる。
今回も最後までお読みいただき、ありがとうございました。
後編では、アート思考の視点から考えます。
弁理士 中村幸雄
