AIに現場に合う提案をしてもらうために

Papillonについてブログを書こうとAIに相談したとき、「地味に便利なこと3つ」という案が出てきました。カレンダー、タスク、ハビットトラッカー。どれも実際にある機能ですし、紹介記事としては成立します。

それでも、私にはしっくり来ませんでした。機能は合っているのに、なぜそれを作ったのかが伝わらなかったからです。

AIは、よくある切り口や一般的な答えを出すのが得意です。一方で、こちらが話していない経験や、特定の利用者が置かれた状況を知ることはできません。この違いは、ブログを書くときだけでなく、AIを使って製品を考えるときにも重要だと思います。

Papillonを最初から使えるようにした理由

私はもともとタスク管理が苦手でした。GTDなどを試してもうまくいかず、バレットジャーナルで基礎を学び、システム手帳で管理する喜びを知りました。Obsidianも好きですが、カレンダーを使うにはプラグインを探して入れる必要があります。誰もがカスタマイズから始めたいわけではないと思いました。

だからPapillonでは、カレンダーや日次ノート、タスクなどを最初から使えるようにしています。単に「カレンダーがある」ではなく、準備に時間をかけず、その日のノートを開いて書き始められるようにしたかったのです。

こうした背景は、私が話すまでAIの提案には入りませんでした。伝えた後なら、AIは経験を整理して文章にできます。でも、どの経験が設計に影響したかを、何も聞かずに当てることはできません。

Papillonでは、日々の記録をローカルのMarkdownノートに残します。AIは必要に応じてノートを探し、読んでから応答できます。たとえば、以前のメモを参照しながら今日のタスクを整理する。利用者が書きためた背景を、AIとの会話にも持ち込めるようにしています。

製品開発でも、「カレンダーがほしい」という要望だけなら、AIは機能案をいくつも出せます。でも、その人が予定を確認したいのか、今日の仕事へ迷わず進みたいのかによって、必要な画面や操作は変わります。

業務向けのAIでも同じです。「入力を自動化したい」という一言から、一般的な機能案は作れます。ただ、誰が何を入力していて、どこで時間がかかり、入力後に誰が確認するのか。その仕事の流れを知らなければ、役に立つ提案かどうかは判断できません。

そこで、まずは実際の場面を聞く。仮の案を小さく作って使ってもらい、合わないところを確かめる。分かったことをAIにも渡せば、次の案をより具体的にできます。AIを使うほど、最初に現場の話を聞くことが大切になるのだと思います。

最初の私は、AIにPapillonの名前と「ブログのネタがほしい」という希望だけを伝えていました。それなら、よくある機能紹介が返ってくるのも自然です。

次に相談するなら、「タスク管理が苦手だった経験から、設定せず今日の記録を始められるようにPapillonを作った。この理由が伝わる記事の切り口を考えて」と伝えます。欲しい案だけでなく、そこに至った経験と、誰に何を届けたいかを先に説明するのです。

クライアントと製品を作るときも同じです。要望の言葉だけをAIに渡す前に、使う人がどの場面で困り、今はどう対処しているのかを一緒に確かめる。その具体的な話をAIにも伝えてこそ、現場に合う案を考える助けになります。

使う人が積み重ねてきた記録を、AIが一緒に考えるための手がかりにする。Papillonでも、その体験を大切にしています。