より良いAIツールの構築

291日前原文(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を手作りするプロセスは楽しんでるんだ。

└

同じようなことだけど、実際にはそれ以上のことだと思う。ソフトウェア開発に関しては、実行やデザインの各イテレーションは、これまで自分でやったことや注意深く観察したことに基づいて、速くなったり良くなったりするはずなんだ。

└

まだまだ手動でリファクタリングをたくさんやってるよ。Vimのバインディングを使うと、ぎこちないLLMにやり方を説明するよりも早いことが多い。私にとってリファクタリングはコーディングの本質そのものなんだ。ほとんど動かない初期バージョンの解決策を作るのは必要だけど、私にとってはあまり面白くない。面白いのは、そのv1をエレガントで既存のアーキテクチャにフィットするものに形作るプロセスなんだ。粗い部分を削り、ミスマッチを減らすとかね。LLMにはそれを正確にやるのは、しばしば細かすぎるんだよね。

これが私が深い研究が好きな理由の一つだね。いつも最初に質問を投げかけて、学びたいことを洗練させて明確にすることを強制される。シンプルなUXの変更が、教育とユーザーをバカにすることの違いを生むんだ。

└

その質問にちゃんと注目したことある？深いリサーチは確かに面白いけど、質問が「カッコいい要素」のためだけにある気がするんだよね。ちゃんと考えてるように見せるために。そう思う理由は、すでに自分が丁寧に書いたことについてよく聞いてくるから。正直、あの余計な質問が実際の検索にあんまり役立ってないと思うんだよね。

└

テクニカルライターとして、Deep Researchは使わないよ。仕事が下手になるからね。リサーチ、メモ取り、要約が、トピックを理解するための方法なんだ。それで知識を持って書けるようになる。結果的にできたメモはほとんど偶然の産物。AIにその作業をやらせると、メモはできるけど理解が得られない。AIが作った文書を読むことは、実際に作業をするのとは代わりにならないんだ。

この投稿は、画期的なイノベーションが外部から生まれることが多い理由の良い例だね。著者のアイデアは、エンジニアリングマネージャーやプリンシパルエンジニアとしての特定の経験に影響されていて、あんまり共感できないな。もしこれがエンジニアリングマネージャーがAIツールをどう作るべきだと考えている代表的な意見なら、AIツールは人間のワークフローにどう適用できるかという特定の仮定に基づいて、局所的な最大値に達しちゃうだろうね。私は15年間、（プログラマーじゃない）ドメインエキスパートを補強するMLアプリケーションのR&Dをやってきたけど、著者が述べている原則に従ったアプリケーションを一度も提供したことがない。私が全然違う視点を持っているってことは、デザインスペースはかなり広いってことだと思うし、特定の方法論が「逆行している」と言うにはまだ早すぎると思う。現実は、今のところAIツールの未来がどうなるかはわからないってことだね。

└

もちろん、一つの解釈としては、あなたが作るMLシステムが15年間にわたって人間のスキルを低下させている（あるいは置き換えている）と言えるけど、立ち位置によって異なる解釈が生まれるのは同意する。ただ、できるだけ人間（とその知識や情報取得）をループに入れておくのは良い練習だと思う。

コーディングのときにAIを使うベストな方法は次の通りだよ： * 洗練された検索と置換。つまり、構造体の初期化をハイライトして「これをYに変換して」と言うこと。（正規表現はいつも面倒だけど、もう少し決定的ではある。） * エージェント的なワークフローのときは、普通のコードよりも高いレベルで扱って、シミュレートされた人間としてではなく。つまり、一度にたくさん頼むと、うまくできなくなるみたい。だから「機能を実装して」と言う代わりに、「新しいファイルを作ってスタブ関数を作ろう」、「スタブ関数1を完成させてxを実行しよう」、「スタブ関数1を呼び出してYを実行することでスタブ関数2を完成させよう」とかね。 * 不慣れなコードベースで何かを見つけたり、何かがどうやって行われたかを尋ねたり。「ねえ、コパイロット、アプリのルートはどこで定義されてる？」プロジェクトの動作についてたくさん質問できるのが一番の利点で、IRCのベテランを煩わせることなくできるから。

これはちょっと混乱する内容だね。Weaklyがコーディングエージェントについて話しているなら、多くのことが理解できるけど、そうじゃない。彼女はオペレーションのインシデントを調査し解決するのを手助けするエージェントについて話してる。Weaklyの主張の要点は、エージェントは自分の役割に留まり、役立つクリッピーのような提案をし、人間が運転するべきだということ。でも、人間がログを掘り下げて異常を特定し、インシデントの仮説を作ることにどんな価値があるの？AIツールはこのタスクにおいて人間よりも根本的に優れている。コンピュータがチェスをプレイするのが得意な理由と同じだね。Weaklyがやってることは、エンジニアにアドバイスをすることと実際に行動を起こすことの間に明確な線を引いているように見えるけど、その線は正しくない。AIツールが自律的に行うべきでないアクションもあるけど（Terraform applyを自動で実行させるのは絶対に嫌だ）、止めるべきでないアクションもたくさんある。インシデント解決の目的は、インシデントを解決することだから。

└

最初の部分を飛ばさなければ、混乱する内容じゃないよ。彼女の一例を使って、人間がどう学ぶか、AIがそのプロセスをどう取り除いているかの部分を省いてるんだ。インシデント解決は、彼女の一般的なポイントの一例だよ。

└

今のところ、誰も満足させるインシデント解決ができるAIツールはないよ。人々は責任を持つだけじゃなく、正しい行動が取られるようにするためにも、ループの中にいる必要があるんだ。

└

異常検知やインシデント管理に関する議論の中で、すべての問題が同じではないということが見落とされがちだね。多くの問題は、ある程度自動化できるんだと思う。重要なのは、何が十分にオフロードできるか、そして本当に人間のエンジニアが必要な時がいつかを理解することだよ。君の言う通り、彼らはスケールでパターンを検出するのが得意だけど…そうじゃない時もある。パターンが意味のあるものかどうかを知ることもね。もちろん、すべての人間がそのギャップを埋められるわけじゃないけど。

私たちは累積的な反復が得意なんだ。人間は基本的にコミュニティに最適化されてる。だからブレインストーミングが効果的なんだよね…でも、通常はグループの中でだけど。認知心理学には、累積文化についての理論があって、これが人間がグループでどう働くかを実証的に示してるんだ。 > 人間は集団で学び、模倣や反復を通じて革新を起こすんだ。巨人の肩に立つっていう名言、知ってる？あれはただの面白い言葉じゃなくて、人間の働き方の根本なんだ。創造性は探索なんだよ。社会的な探索。脳そのものから出てくるわけじゃなくて、脳と環境の出会いから生まれて、時間をかけて社会的・文化的な層で積み重なっていく。だから、LLMが本当に理解してるかどうかなんて考えないんだ。彼らがアイデアを探し、世界でそれを検証している限り、関係ないんだよ。それに、基盤が重要だとは思わない。重要なのは探索だけだと思ってる。でも基盤は、私たちが探索できる検索空間に関係してるかもしれないね。

この投稿は、AIの導入の目的が人間を賢くするための教育じゃなくて、創造性に対して報われない仕事を排除することでプロセスレベルでの生産性を達成することだという大事なポイントを混乱させてるよ。

記事の根本的な前提は、人間がスキルを学び維持するためにはタスクが必要だということだよね。学びは独立して行われるべきで、エージェントがもっとできるから人間が学ばないっていうのは、ちょっと循環論法的な考え方だと思う。これは広範で複雑なテーマだけど（まだ完全には書き終えてない長めのブログをシェアするつもり）、人々は高いレベルのパターンに行くための認知負荷を過小評価してると思う。だから、学びはタスクの前に行われるべきなんだよね。今はピアとペアのような抽象化の真っ只中にいる感じ。ピアはタスクを委任するのに十分信頼できるのかな？もしそうでなければ、ペアデザインパターンは人間のスキルセットを補完するものであるべきだと思う。AIエージェントに対するフラストレーションは、完全に信頼できないことから来てると感じた。それは、人間が関与する必要が絶対にあるってことだよね。人間がいるなら、AIは人間ができることを上手にやるのではなく、人間が必要とすることを手伝う良いアシスタントであるべきだと思う。その部分には同意するけど、もし信頼性が改善されれば、私のタスクのほとんどはAIに全部やってもらってもいいかな。他のフラストレーションは、メモリの問題や（研究において）欠如、幻覚や過信、状況認識の欠如から来てる（状況認識はエージェントが自分を売り込むポイントでもある）。これらが解決されれば、エージェントをペアとして扱うのとピアとして扱うのは、もっとピア側に傾くかもしれないね。

OPに心から同意するよ。この記事はとてもタイムリーで、AIツールの誤った方向性を明確に示してる。私も子供たちもよくLLMに「答えを教えないで、一緒に解決しよう」って聞いてるけど、それは私の質問に対する完全な回答を見るよりもずっと豊かな体験だと思う。OPのEDGEフレームワークがAIとのインタラクションでもっと広まることを願ってるよ。

ハクソク