AI時代の「馬なし馬車」

 (koomen.dev)
21 ポイント 投稿者 GN⁺ 2025-04-24 | 2件のコメント | WhatsAppで共有
  • AIでソフトウェアを作ることは楽しく生産的である一方、ほとんどのAIアプリは**従来のやり方をまねた「馬なし馬車(horseless carriage)」**のように非効率的
  • GmailのAIメールアシスタントは過度に形式的な結果を生み、ユーザーごとの体験を提供できていない
  • 本当に役立つAIアプリは、ユーザーがSystem Promptを修正できるようにして、パーソナライズされたエージェントを作れるようにすべき
  • AI時代の理想的なアプリは既存のプログラムを模倣するものではなく、ユーザーの反復作業を減らし、自動化によって真の生産性を高めるAIネイティブなソフトウェアであるべき
  • AIの真の潜在力は、日常業務の自動化を通じて、ユーザーが重要で創造的な仕事に集中できるよう支援することにある

AIで作られたアプリより、AIを活用したソフトウェア制作のほうが楽しい理由

  • 最近、興味深い事実に気づいた。多くのAIベースのアプリを使うことよりも、AIを使ってソフトウェアを自分で作ることのほうが、より楽しく生産的だ
  • AIを開発ツールとして使うと、ほとんど想像できるものなら何でも素早く作れる感覚がある
  • 一方で多くのAIアプリは、AI機能が載っているだけで、実際の有用性が低かったり、むしろ不便だったりする

AI時代の「馬なし馬車」

  • 現在の多くのAIアプリは、本質的に昔ながらのソフトウェア設計をそのまま踏襲している
  • その結果、LLMのような強力なモデルが不必要に制約される構造になってしまっている
  • これを「AI時代の馬なし馬車(horseless carriages)」と表現している
    • 自動車初期のデザインが馬車の形式をそのまま引き継ぎ、非効率だった歴史に似ている

設計を誤ったAIアプリの例: GmailのAIアシスタント

  • Gmailは最近、Geminiモデルを使ってメール下書きを生成する機能を公開した
  • 例では、ユーザー（筆者）が上司に送るメールの下書きを依頼している

> Prompt: 上司へのメール下書きを依頼

  • Geminiが生成した下書きは文法的には完璧だが、筆者が実際に書く文体とはまったく異なる
    • 筆者の実際のスタイル: "hey garry, my daughter woke up with the flu so I won't make it in today"
    • Geminiの出力は過度にフォーマルで不自然
  • 結果的に、自分でメールを書くよりも時間がかかる
  • 筆者はこの機能を「成果の出ない社員を管理している感じ」と表現している
  • 何百万人ものGmailユーザーも似たような経験をしている可能性が高く、そのせいでAIはまだメールを書くのが下手だと誤解しているかもしれない
  • しかし問題はGeminiモデル自体ではなく、Gmailチームのアプリ設計のやり方にある

より良いメールアシスタントの例

  • もしGmailが以下のような方式でメールアシスタントを作っていたなら、はるかに実用的だったはずだ

メール読解エージェントの例

  • このデモはメールを書くのではなく、読んで処理する方式で動作する

  • 使用するツール:

    • labelEmail(label, color, priority) : メールにラベルを付ける
    • archiveEmail() : メールをアーカイブする
    • draftReply(body) : 返信下書きを作成する

  • 受信トレイ内のメールは次のように並んでいる:

    • TechCrunch Weekly
    • Gustaf Alströmer - founder intro?
    • HackerNews Digest
    • The Verge Updates
    • Garry Tan - reschedule
    • など合計12件

  • 各メールは自動で分類と優先順位付けが行われ、一部は自動で返信下書きを生成したり、自動でアーカイブされたりする

  • ユーザーが定義したSystem Promptに従って、各メールが個別に処理される

  • ユーザーはSystem Promptを直接修正し、自分のラベリングロジックを反映できる

> この方式のほうがはるかに強力で直感的で生産的なのに、なぜGmailチームはこう設計しなかったのだろうか?

  • 問題の核心: 「典型的で画一的なトーン」
    • Gmailの設計に由来する最大の問題の一つは、典型的で個性のない文体であること

AI Slop: 形式的でぎこちない出力

  • GmailのGeminiが生成したメール下書きは、過度に冗長で形式的であり、筆者のスタイルとはまったく異なる
  • こうした出力はむしろフィッシングメールのように見えることすらある
  • ほとんどのLLMユーザーはこうした経験をしており、それを避けるためにプロンプトハッキング(prompt hacking) という戦略を自然に使うようになる
    • 例のプロンプト:
      > "let my boss garry know that my daughter woke up with the flu and that I won't be able to come in to the office today. Use no more than one line for the entire email body. Make it friendly but really concise. Don't worry about punctuation or capitalization. Sign off with “Pete” or “pete” and not “Best Regards, Pete” and certainly not “Love, Pete”"
  • 出力の品質は良くなるが、プロンプトが長くなりすぎ、毎回この過程を繰り返さなければならないという点で非効率だ
  • この問題の単純な解決策: ユーザーにSystem Promptの修正権限を与えること

System PromptとUser Promptの区別

  • LLMは本質的に入力された単語（プロンプト）をもとに次の単語を予測するシステムだ
  • すべての入出力はテキストで構成される
    • 本文では単純化のためテキスト中心のインターフェースのみを扱っているが、実際には音声や映像も入出力にできる
  • OpenAIやAnthropicなどは、これを単純化するためにプロンプトをSystem PromptとUser Promptに分離する構造を採用している
    • System Prompt: エージェントの性格と行動様式を定義する（関数に相当）
    • User Prompt: ユーザーからの具体的な要求や質問（入力値に相当）
    • モデルの応答: 出力値

> 例:
> - User Prompt: "Let my boss Garry know that my daughter woke up with the flu this morning and that I won't be able to come in to the office today."
> - Gmailの推定System Prompt:
> - "You are a helpful email-writing assistant responsible for writing emails on behalf of a Gmail user. Follow the user’s instructions and use a formal, businessy tone and correct punctuation so that it’s obvious the user is smart and serious."

  • 問題は、GmailがこのSystem Promptを公開せず、ユーザーに修正権限も与えていないことだ

Peteのユーザー定義System Prompt

  • Gmailが画一的なSystem Promptの代わりに、ユーザーに直接作成権限を与えていたなら、次のように書けただろう

    > You're Pete, a 43 year old husband, father, programmer, and YC Partner.
    > You're very busy and so is everyone you correspond with, so you do your best to keep your emails as short as possible and to the point. You avoid all unnecessary words and you often omit punctuation or leave misspellings unaddressed because it's not a big deal and you'd rather save the time. You prefer one-line emails.
    > Do your best to be kind, and don't be so informal that it comes across as rude.

  • このようなSystem PromptをもとにGPTにメールを生成させると、次のような出力が得られる

    > Garry, my daughter has the flu. I can't come in today.

  • この結果は短く、個人的で、実際のユーザースタイルに合っている

  • 最大の利点は、このSystem Promptを再利用できることで、その後に書くすべてのメールにも同じスタイルを適用できることだ

ユーザープロンプトを書く楽しさと可能性

  • LLMに自分のように考えるよう教え、その結果をすぐ確認できる体験は、非常に直感的で楽しい
  • ユーザーには、自分の文体を定義する「自分専用のSystem Prompt」を書いてみることを勧めている
    • 例のUser Prompt:
      > "Let my wife know I'll be home from work late and will miss dinner"
      > "Write an email to comcast customer service explaining that they accidentally double billed you last month."
  • 良い結果が出れば説明が十分だったという意味であり、そうでなければ内容を補って繰り返せばよい
  • これは人間を教えるよりも、むしろ速くて正直なフィードバックループによって簡単な場合すらある

なぜほとんどのAIアプリはSystem Promptを公開しないのか?

  • 2025年4月現在、ほとんどのAIアプリはSystem Promptを意図的に隠している
  • 筆者はこれをユーザーの権限と個性の剥奪と見ており、より良い結果と利用体験のためにSystem Promptは必ずユーザーに開放されるべきだと主張している

Horseless Carriages: 新しい技術への旧時代的な適用

  • 新しい技術が登場すると、初期のツールはしばしば既存のやり方の枠組みをそのまま模倣して失敗する
  • 「馬なし馬車(Horseless Carriage)」とは、初期の自動車が馬の引く馬車のデザインをそのまま踏襲した事例を指す
    • 例: 1803年のTrevithickの蒸気馬車設計
    • このデザインは当時は革新的に見えたが、今見ると基本構造が自動車に不向きだ
  • 当時の人々はこうした馬車に乗って「エンジンより馬のほうが良い」と考えたかもしれない → 自動車が登場するまでは妥当な判断だった
  • 筆者は現在のAIアプリがこれと似た状況にあると主張する
    • 例: GmailのGemini機能のように、旧時代的なUX設計にAIを付け足しただけのケース
  • 従来の発想は「馬をエンジンに置き換えよう」という水準にとどまっていた
    • 今のAIアプリも同じように「既存アプリにAI機能を追加するだけ」になっている

Old World Thinking: 伝統的ソフトウェア設計の限界

  • これまでは、コンピュータを活用する方法は二つしかなかった
    1. 自分でプログラミングする
    2. 他人が作ったプログラムを使う
  • プログラミングは難しいため、大半は後者を選ぶ
  • その結果、ソフトウェア業界は開発者とユーザーの役割を明確に分ける形で成長してきた
    • 開発者: ソフトウェアの一般的な動作を決める
    • ユーザー: 具体的な入力を与える
  • LLMのSystem/User Promptの区別は、この構造をそのまま反映している
    • System Prompt = 開発者の役割
    • User Prompt = ユーザーの役割
  • しかしメールは非常に個人的な領域であり、AIがユーザーの代わりにメールを書くなら、個人の文体を反映すべきだ
  • 旧来の構造では、ユーザーがプログラム自体を書かない限りパーソナライズは難しい
  • しかしLLM時代にはユーザー自身がSystem Promptを書ける
    • つまり、プログラミングなしでAIの振る舞いを設計できる時代なのだ

ユーザーにユーザーのものを取り戻そう

  • 筆者の主張: LLMが自分の代わりに行動するなら、そのやり方(System Prompt)は自分で教えるべきだ
  • もちろん、すべてのユーザーが最初から自分でPromptを書きたいわけではない
    • Gmailはユーザーのメール履歴を参考にして基本のSystem Promptを生成できる
    • 重要なのは、そのPromptをユーザーに見せ、修正できるようにすることだ
  • 「プロンプトを書けない人はどうするのか?」→ 最初はそうでも、多くはすぐに学ぶ
    • ChatGPTの成功例がそれを証明している
  • 個人的エージェントではなく、会計や法律などのドメインではどうか?
    • System Promptはその分野の専門家が書くのが妥当だが、専門家自身も自分の文脈に合わせて修正したいと思う
  • 例: YCの会計チームはYCに特化したやり方、ルール、ソフトウェアの組み合わせを使っている
    • 汎用的な会計AIエージェントはYCではまったく役に立たない
  • ほぼすべての会計チームが独自のやり方を持っており、そのためExcelのような汎用ツールを好む
  • 結論: ほとんどのAIアプリでSystem Promptはユーザー自身が作成・維持すべきだ

> AIアプリは完成済みのエージェント(agent) ではなく、ユーザーが自分のエージェントを作れるツール(agent builder) であるべきだ

開発者に開発者のものを取り戻そう

  • では開発者は何をすべきか?
    • 特定ドメイン（例: メール、会計台帳など）に特化したエージェントビルダーUIを設計する
    • ユーザーが最初からプロンプトを書かなくても済むように、テンプレートとプロンプト生成支援を提供する
    • ユーザーがエージェントの結果を確認し修正できるフィードバックループのインターフェースを提供する
  • 開発者はまたエージェントツール(agent tools) も提供する
    • メール下書きの送信、 自動送信、メール検索、外部API連携など
  • これらのツールはエージェントの行動範囲と安全性を制御する手段になる
    • コードで書かれたツールによって行動を制限するほうが、テキストプロンプトで制約するよりもはるかに安全で明確だ

> 今後は「プロンプトインジェクション(prompt injection)」を懸念する発想が笑い話になるかもしれない
> → テキスト構造で境界を作るのは脆弱な抽象化の兆候だ
> → システム全体をユーザー空間として捉え、強力なツールとUIで制御すべきだ

メールを「読む」エージェントの本当の価値

  • 先ほど述べたように、より良いSystem Promptがあっても、メール下書きをゼロから書く時間は大きくは節約できない
  • その理由は、筆者の書くメールがもともと非常に短く簡潔だからだ
    • つまり、ユーザープロンプトの長さ ≒ メール本文の長さ
  • 筆者は何度も実験した結果、生成AIはテキスト生成よりもテキスト変換のほうがずっと得意だと実感している
  • だからLLMを活用する本当の目的は、メールを**「書く」ことではなく「読んで処理する」こと**にある

メール読解エージェントのデモ (gpt-4o-mini ベース)

  • 利用可能なツール:
    • labelEmail(label, color, priority) : メールにラベルを付ける
    • archiveEmail() : メールを自動アーカイブする
    • draftReply(body) : 返信下書きを自動生成する
  • このエージェントは各メールを読んで:
    • スパムをうまく振り分け
    • 重要度に応じてラベリングし
    • 要約や返信下書きを作成し
    • 不要なメールは自動でアーカイブする
  • さらにいくつかツールを追加すれば:
    • 購読解除
    • 予定登録
    • 請求書の自動支払いまで可能になる
  • これこそがAIネイティブなメールクライアントのやるべきことだ:
    → 退屈な反復作業を自動化してユーザーの時間を節約すること
    • すでにSuperhuman、Zeroなど一部のメールクライアントはこの方向で開発を進めている

AIネイティブソフトウェアの意味

  • AIの真のキラーアプリは、「自分がやりたくないこと」をコンピュータに代わりにやらせることだ
  • 筆者がこの記事にデモを含めた理由も、LLMが実際にすでにこうした作業を十分うまくこなせることを示すためだ
  • 問題はAIの性能ではなく、アプリ設計にある

> Gmailチームが作ったのは「AIを載せたメールアプリ」
> → ユーザーのための自動化ツールではなく、人間中心のインターフェースにAIを無理やり押し込んだ形

  • 逆に、AIネイティブアプリは次のようであるべきだ
    • 特定ドメインにおけるユーザーのレバレッジを最大化する
    • 例: AIメールクライアントはメール作成時間を最小化する
    • 例: AI会計ソフトウェアは会計処理時間を最小化する

AI時代への期待

  • 反復的で退屈な仕事はすべてエージェントが代わりに処理する
  • ユーザーは重要な仕事に集中できる
  • 自分が得意なこと、好きなことをもっと多くできるようになる

> これこそが筆者がAIの未来に興奮する理由だ
> より良いツール、より良い時間の使い方、より高い生産性

関連記事

2件のコメント

 
crawler 2025-04-24

本当に有用なAIアプリは、ユーザーがSystem Promptを修正できるようにして、パーソナライズされたエージェントを作れるようにすべきです。

もちろん機能を作る開発者たちも分かっているはずですが、脱獄がある限り簡単ではないでしょう。
システムプロンプトの変更をできないように固定していても脱獄されるのに、システムプロンプトの変更を開放するのは不可能に近いことです。
本来の機能とは別の用途で安く使われるかもしれませんしね。
 
GN⁺ 2025-04-24
Hacker Newsの意見

  • 言語モデルを使ってメッセージを個人的に作成することには慎重であるべきだと考える。これは個人の経験や知識の具体性を欠いている

    • Geminiのようなモデルが個人の過去の技術的説明や作業の具体性を理解できるなら、受け入れやすくなるはず
    • しかし多くの場合、1970年代の秘書が書けたメールと大差ない
    • 個人的なメッセージ作成では要約は不要であり、短いメッセージを膨らませることは無意味なノイズを生む
    • AIを使ってメッセージを書くことは、情報伝達の境界を曖昧にする

  • AI機能の90%は役に立たず、高価だと感じる

    • コーディングAI機能以外で有用なAI機能を見つけるのは難しい
    • GmailやiMessageの自動補完機能はLLM以前から存在していた
    • メールをよりプロフェッショナルに聞こえるようにするためにGmailの機能を使ったことはない

  • Geminiは個人秘書のように振る舞い、ユーザーの代わりにメールを送る

    • 個人的なメッセージをAIで作成することは、相手を不快にさせる可能性がある

  • 文法やスペルを気にしない人とのコミュニケーションは不快だ

    • スペルを間違える人を非難しているわけではないが、能力があるのに気にしないのは相手への無関心を示している

  • LLMと接続されたインタラクティブなウィジェットは面白かった

    • Gmailの「メール要約」ボタンは不要に感じる

  • AIが予測可能なスタイルで文章を書くと思っている人は多いが、実際にはそうではない

    • テキストだけでなく画像生成にも当てはまる
    • AIが実際の人のように話せると分かると、人々は不快に感じるかもしれない

  • インタラクティブなデモがリアルタイムで進行するのが良かった

    • メールのスタイルを分析して下書きを作成できる
    • AIが自動でメールを書き、ユーザーが承認する方式へ発展する可能性がある

  • AIはユーザーが望むものを知ることはできず、目標を明確に表現するのも難しい

    • AIがすべてを処理すると、ユーザーは深く考えなくなり、専門性や問題解決能力が制限される

  • 最も有用なAI機能は目立たない

    • メールのラベリングアシスタントが良い例である
    • 「日程再調整」メールを自動で解釈し、予定変更を提案する機能は有用だ

  • AIがメッセージを代筆することを理解できない

    • 重要なメッセージは自分で書くことに意味があり、それは生きた相互作用の表現である