世界を動かす技術を、日本語で。

より良いAIツールの構築

2025年7月23日原文(hazelweakly.me)

概要

  • 人間の学習方法AIツール設計 の関係性について考察
  • 現状のAIツールが 人間の強みを損なう設計 になっている問題提起
  • Retrieval Practiceプロセス重視 の学習理論を紹介
  • より良いAIツール設計 の具体的な提案
  • 実例 (インシデント管理)を通じた改善案の解説

人間の学びとAIツール設計の逆転現象

  • 人間の学習 は、単なる情報の受け取りではなく、 自分で思い出す努力 (Retrieval Practice)によって強化される性質
  • 最も効果的に学ぶ内容 は「知識」ではなく「プロセス」。例:ケーキ作りは材料暗記ではなく手順習得
  • イノベーションの本質 は「独創的な個人のひらめき」ではなく「累積的な反復と共同作業」
  • 人間社会は模倣・反復・改善 によって発展。個人の天才神話よりも「肩の上に立つ」文化
  • 問題解決とイノベーションは本質的に同じ。学びと知識の集団的伝播がカギ

現状のAIツール設計の問題点

  • 多くのAIツールは「 AIボタンを押す→自動で解決」という流れ
    • 人間のリトリーバル(思い出す努力)やプロセス反復 が排除されている
    • 集団的知識伝達や反復的改善 の機会を奪う設計
  • AIが人間の強みを奪い、結果的に人間もAIも成長しない悪循環
    • 人間のスキル低下→AIの学習データ品質低下→全体の非効率化
  • ツールは人間の思考を助けるべき であり、「人間の代わりに考える」ものではない

より良いAIツール設計のための視点

  • AIを「同僚」や「インターン」ではなく、「忘れっぽいインストラクター」として捉える
    • 本質は「人間が学び、学び方を学ぶ」ことのサポート
  • AIは人間の能力を増幅させる存在。プロセスの一部を肩代わりするだけでは不十分
  • 証拠に基づく教育プロセス (例:Explain, Demonstrate, Guide, Enhance=EDGE法)をAIと組み合わせて設計

インシデント管理を例にしたAIツールの改善案

  • 現状のアンチパターン :「人間へのプロンプト→即AIが自動対応」

    • これでは人間の思考プロセスが鍛えられず、専門性が失われる
  • 理想的なAIツールの流れ (EDGE法に基づく)

    • Explain(説明)

      • 例:「この手順を試しましたか?」「デプロイをロールバックしてみますか?」など、次の行動を自分で思い出すきっかけの提示
      • 悪い例:「このボタンを押せば自動で解決」など、思考の機会を奪う設計
    • Demonstrate(実演)

      • 例:「あなたの質問をツールのクエリに自動変換」「操作手順のアニメーション表示」
      • 悪い例:「クリック一発で自動実行」→応用力や信頼性が損なわれる
    • Guide(ガイド)

      • 例:「次に何を調査しますか?」「詰まっている点はどこですか?」と対話的に思考を深めさせる
      • 悪い例:人間の入力無しに一方的に情報提供、指示口調での訂正
    • Enhance(強化)

      • 例:人間の行動や判断を次の学習サイクルに活かし、より高度な課題へ誘導
      • 累積的な知識・ノウハウの蓄積と活用

まとめと提言

  • AIツール設計の本質 は「人間のプロセス学習と反復力を最大化すること」
  • 人間の強み(思い出す努力・反復的改善・集団的知識伝達)をAIが増幅する設計 が理想
  • 自動化・省力化だけを追求すると、人間もAIも非効率化。本来の価値を見失わない設計思想が重要
  • AIは「人間の学びを促進するインストラクター」 として設計・運用すべき

このアプローチにより、 人間とAIがともに成長し、組織全体の知識や問題解決力が強化される未来 を目指すべき

Hackerたちの意見

AIツールや製品については、「インテリジェントワークスペース」への移行が進むべきだと思う。チャットボットは減らしてね。基本的には、人間にすべてのノブやレバー、スロットルを与えつつ、AI機能としっかり統合された環境やプラットフォームのこと。これはVSCodeのフォークを超えた、かなり大変な作業だよ。

インテリジェントワークスペースを実装するより、チャットボットを作る方がずっと簡単だし、AIは人間のインタラクションが必要ない場合も多い。AIとやり取りするためのチャット以外のインターフェースが見てみたいな。

最近、プロジェクトでClaude Codeを使ってるんだけど、私のインスタンスが他の開発者のインスタンスと連携できたらいいなと思ってる。CLAUDE.mdを修正してドキュメントを維持することはできるけど、チームがもっと効果的にコラボできるような機能がCCにあったら最高だよ。提案があれば大歓迎!

AIによるコーディングでずっと心配してるのは、練習の機会が失われること。手でコードを書くこと(ボイラープレートや何度もやったことを含めて)は、ミヤギさんの「フェンスを塗る」みたいなものだと思う。繰り返すことで、脳に深く刻まれていくし、こうしたパターンが自分の一部になることで、より高レベルなデザイン決定をするのがずっと効果的になるんだ。

これに関してはリアルライフでも似たようなことがあるね。1) 実際のペンや鉛筆で意味のある長文を書くのはいつが最後か思い出せない。私の字は本当にひどい。2) GPSなしで運転する道を見つけることができなくなった。地図を読む?笑

特に、開発者がAIの自分の生産性への影響を過大評価しているというMETRの研究を考えると心配だよね(たとえそれがネガティブでなくても)。

夜やシャワーの中で問題を考えることがよくあるんだけど、その時に頭の中で「コードを書く」感じになる。これが時々すごく役立つんだ。頭の中に言語構造が根付いていなかったら、これは不可能だと思う。

トランジスタを手でハンダ付けするのも昔はあったけど、今はみんな続けたがってるのかな?何兆個ものトランジスタがある今、笑。こうやってズームインしたりズームアウトしたりするのが好きなんだ。いつかもう一段階ズームアウトできるかも。コーディングが恋しいな。まだたくさんコード書いてるけど。

よく聞く反論は、書くことや印刷技術が私たちの書道や修辞スキルを衰えさせたかもしれないけど、思考能力を衰えさせたわけではない、というもの。むしろ、思考能力を拡大させたんだよね!基本的にはスティーブ・ジョブズの「心のための自転車」ってアイデア。AIにこの理論を適用するのに問題があるのは、以前の技術は流通のボトルネックを解決していたのに対し、これは創造的プロセスそのものに直接アタックしているから。Stratecheryの投稿が素晴らしくて、AIがアイデア生成における「実体化」のボトルネックを取り除こうとしていると主張している。創造的なタスクにこれを行うのは、自分の創造的な発展を妨げない限りは大丈夫。人間は自己制御や自己認識に限界があるからね。

「すべての拡張は切断である」 -- マーシャル・マクルーハン

私がLLMで生成したコードにはバグがたくさんあって、結局、デバッグや小さなエラーを見つけるためにもっと時間をかけるから、コードをよく理解することになるんだ。これって逆にいいかもね。正しい答えを練習するだけじゃなくて、間違った答えをどう直すかを知ることで、もっと深く学べるから。

ちょっと脱線するけど、エディタで文字を打つとキャラクターが爆発するようなうざい効果があったよね。コードのために一文字一文字叩きつけるタイプライターを思い出す。人々は、関数やモジュールがUIとしてただのボックスになって、コードが見えないようなものを作り始めるかもしれないし、もう始めてるかもね。CRUD UIを作るように頼まれたとき、やるべき作業の順番を計画するんだけど、繰り返しやることで作業が単調になっていくのを感じる。そこにAIが入ってくる余地があると思う。でも、POShカメラのGUIやOSを手作りするプロセスは楽しんでるんだ。

Hacker Newsで議論の続きを見る