- 現在のAIツールの大半は、人間中心の学習プロセス（想起・実行・集団的反復）を反映できていない。これは最終的に人間・AIの双方の成長ループを損なう逆向きの設計である
- 人間は知識ではなく「プロセス」を学び、集団的・累積的な反復を通じて革新する。しかし大半のAIツールは「ボタンをクリック→AIが自動で処理」というパターンで、人間の主体的な想起・学習ループを取り除いている
- 望ましいAIツールは、「説明→実演→ガイド→強化（Explain, Demonstrate, Guide, Enhance）」の段階で人間の能動的な参加と想起を促すべきであり、自動化ではなく増幅を目標にすべきである
- 例: 観測/復旧ツールでは、AIがすぐに対処するのではなく、プロセスの説明・行動の案内・問題解決ガイド・事後改善提案など、各段階で人間の思考と学習を促進する役割が必要
- このような人間中心のパターンが定着すれば、集団的な知識成長とAIの品質も同時に強化されるポジティブフィードバックループが可能になり、システムツール全般に革新をもたらせる
序論: 人間の学習とAIツーリングの本質的な問題
- AIツールは、人間の協業と学習を支援する方向ではなく、非効率で逆向きに作られている
- 人間の能力を強化するのではなく、批判的思考と問題解決を妨げる方向でツールが設計されている
- この状況はすでに目に見える逆効果を生んでおり、より効果的な方向への転換が必要である
現行AIツールの限界: 逆向きの開発
- 現在、AIツールの大多数は以下のパターンに従っている
- AIボタンをクリック → 魔法のように即座に結果を提示
- データ表示とAI提案
- シンプルなプロンプトと自動実行
- この方式は、人間の問題定義・記憶・想起・プロセス学習・知識伝達・反復的改善という中核的な学習ループを省略している
- AIが人間の中核的な強みを代替しようとしているが、AI自体もその部分に弱い
- 結果として、人間の問題解決・思考能力の退化 → 高品質なデータを生成できない（その結果、AIの発展も阻害）→ 悪循環ループが形成される
人間はどのように学習するのか?
- Retrieval Practice理論によれば、人間は情報を入力されることで学ぶのではなく、能動的な想起を通じて学習する
- 単なる暗記ではなく、自ら情報を脳から「取り出す」過程で本当の学習効果が生まれる
- 学習で最も重要なのは、知識そのものよりもプロセスの習得である
- たとえば製菓を学ぶとき、材料を覚えるよりも**ケーキを作る手順（プロセス）**を学ぶ方が効果的である
- このように実践的なプロセス中心の設計は、協業ツールにより適している
革新と集団的成長の原理
- 革新の本質は、新技術を開発する個人から生まれるのではなく、小さな反復的改善の集団的蓄積から生まれる
— 少数の天才的創造ではなく、既存知識の上に複数の人が「積み重ねて改善する」過程こそが本質
- 人間は独自の革新よりも、模倣と反復、既存事例の変形に最適化された存在である
- 脳ベースの集団学習理論は、このような集団的革新が人間に本質的に適していることを示している
- 問題解決と革新を別々に見るのではなく、問題解決力・知識伝達・集団学習こそが革新の原動力である
- 核心は、プロセス中心の学習、適切な難易度の努力、集団的な反復・強化、人間を補助するAIである
- AIツールは人間の「思考の補助者」であるべきであり、自ら判断して代替する存在になってはならない
正しいAIインタラクション設計
- AIは同僚やインターンというより、「物忘れの激しい講師」にたとえられる
- AIの目的は、ユーザーが自分で学び、どう学ぶべきかを学べるよう導くことである
- 効果的な教育プロセス（EDGE: Explain, Demonstrate, Guide, Enhance）を増強する方向で設計する
- 説明(Explain): プロセス案内、抜けている段階の提示など（単に「ボタンをクリックしてください」ではない）
- 抜けている手順の提案
- プロセスガイドの提供と解説
- 人間が自らプロセスを思い出し実行する過程を重視
- 悪い例: 即座に「実行」ボタンを出す、エラーツールチップなど想起プロセスを軽視する設計
- 実演(Demonstrate): クエリ変換、UI実演、インタラクティブデモなど、直接の「自動実行」ではなく、参加を促すことが中心
- 自然言語クエリをシステムのクエリ構文に変換
- UI探索の支援（要求時に関連画面へすぐ案内）
- 短い15秒デモ・インタラクション型チュートリアルの提供
- 「自動実行」は避ける: 信頼性低下、微調整不能、人間の能力低下
- データ追加や人間の想起記録（ペアリング、メンタリングなど）もAIが学習材料にすべきである
- ガイド(Guide): 質問の誘導、問題区間の討論、行動計画の策定など、ソクラテス式の問いかけ/検証
- ユーザーが計画を提示した場合、次のアクションやガイドを提案
- 必要な文書、コード担当者、関連資料を案内
- 観測/学習モデル、記録化の促進
- 応答の検証、情報のクロスチェック、明確性の確認
- 悪い例: 答えを導く支援なしにサポートすること、頼まれていない情報を過剰に提供すること、権威的な態度、ユーザーによる「続行」ボタンの乱用を許すこと
- 人間の合理的推論の反復を妨げない範囲で補助すべきである
- 強化(Enhance): 行動後の改善提案、反復パターンの学習、実務記録のポストモーテム化など、細かな学習のきっかけを提供
- アクション直後/途中で、段階的改善を提案
- 反復作業に対するショートカット/追加機能を動的に表示
- プロセス自体の改善提案: インフラパイプライン改善、アラート修正、勘に頼る場面では計測改善を勧めるなど
- 事後記録（ノート→学習資料化）、観察によるマイクロラーニングの促進など
- 人間の推論ハブを維持し、自動最適化よりも想起を強化するプロンプトを自然に導入
- とりわけ、各段階で人間が想起・選択・実行する構造を堅牢にし、AIはそれを増幅する役割に集中すべきである
- 実際の事例（インシデント管理・観測ツール）の提示に基づき、各段階ごとに良質なAIインタラクションの例とアンチパターンを説明
総括原則
- 人間の学習を継続的に強化する
- チームワークを促進する: 集団的協業と情報共有
- 「空欄→正解」の自動化ではなく、プロセスへの参加・実行を中心とした加速（ただし自動化で直接代替しない）
- 「努力不要の使いやすさ」ではなく、適切な努力と参加を求めるツール
- チームの学習・経験が成果物に反映されるよう支援する
コード作成に適用できる良い例: 「逆向き」ではない「順方向」設計
- AIで即座にコード生成するのではなく、
- 下書き文書作成 → アーキテクチャ図 → テスト計画 → テストコード → スタブコード → コード生成
- コード検証後、プロセス全体を逆向きにたどってテスト・文書・アーキテクチャを再整備する
- 各段階で**質問・検証（想起強化）**を重視し、検証不能な状態でイエス/ノーだけを問うべきではない
- 想起ベースの開発方式は高品質な学習/テストデータを生成し、AI学習も補完する
クロスファンクショナル（非開発、例: カスタマーサポート）への拡張可能性
- 例: インシデント発生による運用停止時に、カスタマーサポートチームがAIを通じて開発チームと連携
- AIが一次草案を提示し、開発チームの検証によって精度を高める
- サポートチーム、開発チームなど複数組織間のリアルタイムな情報の流れと、コンテキストスイッチの負担を最小化
- 中核専門家が過度に割り込みを受けず、必要時には相互コミュニケーションを円滑に行える
- 開発チームの文脈的な技術回答を、AIが一般向けの説明文に分かりやすく変換
- この構造が実現すれば、組織内外の集団学習と協業効率を最大化できる
- 多層支援/統合ツールへと発展可能
結論
- 現行のAIツールは、人間の集団的反復学習・問題解決能力を弱める形（逆向き）で開発されている
- 協業強化、人間主導のプロセス支援を重視する転換が必要
- そうしてこそ、人間とAIが相互に増幅し合う成長を実現する好循環が可能になる
- ツール設計では、人間を単に「ループの中」に置くのではなく、人間そのものがループであることを忘れてはならない
- 今こそシステムツールに人間中心の革新が求められている
- 協業的で、プロセス中心で、増幅型のAIツールが革新の鍵
1件のコメント
Hacker Newsの意見
この記事には混乱を招く部分がある。Weaklyは、2025年時点でantirezが好むと述べた方式のように、もう少し受動的で助言中心に動くコーディングエージェントを指しているように見えるが、実際には運用上の問題を調査して解決する役割のエージェントを扱っている。Weaklyの主張は、エージェントはClippyのように助言だけを行い、ハンドルは人間に渡すべきだというものだ。しかし、人がわざわざログを掘って異常値を見つけ、仮説を立てることにどんな価値があるのか分からない。コンピュータがチェスをよりうまく指せるのと同じように、AIはこうした作業を本質的に人よりうまくこなすツールだ。Weaklyは助言と実際の行動の間に明確な線を引いているようだが、私はその線が正しいとは思わない。もちろん、AIに自律実行を全面的に任せられない領域もあるが（例: Terraform applyの実行）、逆にわざわざ止める理由のない領域も多い。インシデント対応の目的は、結局のところ障害を解決することだ
まだ誰も、満足にインシデントを解決してくれるAIツールを作れていない。責任の問題もあるし、正しい実行を担保するためにも人の介入は不可欠だ
本質的な問題は、実運用環境へのアクセス権をAIに与えるかどうかにある。最近、AIが「するな」という命令にもかかわらずデータベースを削除した事例を見ると（
notのような否定命令をAIが常に正しく認識できるわけではないため）、現実の安全性の面で大きな懸念がある状況だエージェントにどこまで自律性を与えられるのか気になる。DevOpsのベストプラクティスに従うなら、ほとんどの変更はコードコミットや複数環境へのプロモーションを経て初めて本番に反映される構造になっているはずだ。アプリケーションコードだけでなく、インフラ自体も含めてだ。そうした状況で、インシデント対応作業の中でエージェントに自律実行を許せる部分がどこまであるのか気になる
自分でデバッグしてみることにも一定の価値はあると思う。とりわけ目標がプログラミング能力そのものを高めることにあるなら、なおさらそう感じる。チェスで言えば、LeelaやStockfishのようなAIははるかに速く深く分析できるが、本当の実力向上は自分で局面を分析してみる経験から生まれると思う。チェスのプロ選手たちも繰り返し戦術練習をして、常に頭脳を鍛えている。AIと人が一緒に学ぶほうが速く学べるのか、それとも独立して学ぶほうがよいのか、私にも答えはよく分からない。そして、こうした能力自体が今後も意味を持つのかについても意見が分かれる
異常検知やインシデント管理に関する議論で重要な点の一つは、すべての問題が同じではなく、多くの問題はある程度自動化できるということだ。いつどの問題をAIのような認知プロセッサに渡し、いつ人間のエンジニアが直接介入すべきか、その境界が重要だ。AIは大規模なパターン検出は得意だが、それが意味のあるパターンかどうかまで常にうまく見抜けるわけではない。もちろん、こうした隙間を人が常に埋められるわけでもない
AIツール/製品の観点では、今後は「Intelligent Workspaces」に進むべきだと思う。単なるチャットボットから脱却しなければならない
関連リンク
基本的には、すべての設定、レバー、制御権を人間に与えつつ、AI機能が緊密に統合された環境/プラットフォームが重要だ。これは単なるVSCodeフォーク以上に難しいことだ
チャットボットは、Intelligent Workspacesより実装がはるかに簡単だ。そしてAIは人間とのインタラクションなしでもうまく動く。私は、チャット以外のインターフェースでAIを活用する方法がもっと多様になってほしい
最近Claude Codeでプロジェクトを進めているのだが、自分のインスタンスが他の開発者のインスタンスと会話しながら協業できたらいいのにと思う。
CLAUDE.mdを修正してドキュメントを維持することはできるが、CC自体にチームコラボレーション機能が内蔵されていたら本当にありがたい。いい提案があれば共有してほしいこの記事は、なぜイノベーションがしばしば外部者から生まれるのかをよく示していると思う。筆者には大規模組織のエンジニアリングマネージャーやシニアエンジニアとしての経歴が色濃く表れていて、私の経験とはあまり共鳴しない。もしこのスタイルがAIツーリングの定石として固定化されるなら、人間のワークフローに対する特定の前提に基づいてAIが停滞する現象が起きるのではないかと懸念している。私は15年間、（非プログラマの）ドメイン専門家を補助するMLアプリケーションのR&Dをしてきたが、筆者の原則とはやや異なる。視野がこれほど違うということは、デザイン空間が非常に大きく、特定のやり方が正解だと結論づけるにはまだ早すぎるということだ。今後AIツーリングがどこへ向かうのか、まだ誰にも分からない
AIコーディングでいつも心配しているのは、実力維持が難しくなることだ。自分でコード（ボイラープレートを含む）をタイピングする過程そのものが、まさにMr. Miyagiのペンキ塗りのような訓練なのだ。こうした反復訓練のおかげで、頭の中にパターンが深く刻み込まれ、より高いレベルの設計判断を下すときに大きな力になる
以前の技術（文章を書くこと、印刷など）も、ある意味では筆跡やレトリックの力を低下させたのかもしれないが、むしろ考える力は増幅させた。Steve Jobsの「Bicycle-for-the-mind」のようなアイデアがその代表だ。ただ、この論理をAIに適用する際には、過去の技術は流通のボトルネックを解消したのに対し、AIは創造プロセスそのものを直接狙っているという違いがある。創造的な作業におけるAI活用は、それが自分自身の創造力の発達を妨げない限りにおいてのみ望ましいと思う。人間の自己制御力や自己認識には限界がある
私は夜やシャワー中に、よく問題を頭の中で反芻しながら「コード」を思い浮かべる。言語構造が頭の中に深く刻まれていなければ、こうした想像上のコーディングも難しかったはずだ
日常でも似たような例は見つかる:
トランジスタを手作業ではんだ付けしていた時代もあった。しかし今では技術があまりに進歩していて、昔のように自分でやろうとすると負担が大きい。こうして思考の焦点を広げたり縮めたりし続けながら、私は今でもコーディングが恋しくなることがある。今でもかなりコードは書いている
「Every augmentation is an amputation（すべての拡張は、何かの切断である）」 - Marshall McLuhan
だから私はDeep Researchが本当に好きだ。常にまず質問を投げかけてきて、自分が学びたいことを自分でより明確に定義するよう促してくれる。単なるUXの変化でも、サービス利用者の学習を促すこともあれば、逆に批判的思考なしにツールへ依存させる結果にもなりうると感じる
でも、その質問自体を本当に注意深く見たことがあるだろうか。Deep Researchが役に立つこともあるが、ときにはその「質問」が、ただそれらしく見せるために追加されているだけのように感じる。こちらがすでに気を配って明確に書いている部分まで、わざわざ聞き直してくることが多い。実際の検索プロセスにはあまり役立っていない気がする
私はテクニカルライターとしてはDeep Researchを使わないほうだ。むしろ仕事の妨げになる。調査し、メモし、要約するプロセスそのものが、私が主題を深く理解するのを助ける核心だからだ。記録物そのものは、その結果にすぎない。AIがその作業を代わりにやってくれると、メモは手に入るが、それに相当する理解は得られない。AIが書いた文書を読むだけで、直接の経験を置き換えることはできない
この記事は、AI導入の核心を取り違えていると思う。AI導入の目的は人をより賢くすることではなく、人間の創造性に意味のある報酬が与えられない反復作業をなくし、プロセス全体の生産性を高めることにある
私の経験では、コーディングでAIを最もうまく活用する方法は次のとおりだ:
copilot, アプリルートはどこに定義されてる？のように、以前ならIRCの詳しい人に何度も聞いていたようなことをすばやく確認できるので非常に便利だ最近、父のプレゼン資料作りを手伝った。父は情報自体は十分に持っていたが、デザイナーではないのでスライドをきれいに整えるのに苦労していた。いくつかのAIスライド生成アプリを使ってみたが、見た目は格好よくても、実際にユーザーが望む「デザイン改善」には役立たなかった。結局、手作業でもっときれいに整えるほうがずっとよいという結論になった
特に「アーキテクチャとテスト設計から始めて、それを実際のコードに適用する」という流れが100%より効果的だった、という点には全面的に同意する。ワークフローの習慣さえ変えれば、特別なツールがなくても可能だ（もちろん、専用ツールや標準プロンプトがあればなおよい）
docker-composeのような長時間実行プロセスのログを読むのがまだ苦手だ。そして実際にやるべきことは次のとおりだ:importなどでよくミスをするし、長時間動くプロセスにも弱い人間は累積的な反復（継続的改善）に本当に特化した種だ。だからこそブレインストーミングはグループで特に効果を発揮する。認知心理学には、こうした集団学習とイノベーションの累積的な「文化」理論まである。私たちはよく「巨人の肩の上に立つ」と言うが、それは単なる格好いい言い回しではなく、実際に人間の作動原理なのだ。創造性とは結局、探索であり、それも社会的探索だ。脳の内部ではなく、脳と環境の相互作用、そして社会・文化的層位の中で発展していく。だから私は、LLMが本当に「理解」しているのかは気にしない。ただ探索し、アイデアを生み出し、実際に検証できるならそれで十分だ。また、基盤（Substrate）が何であれ、探索そのもののほうが重要だとも思う。ただし、基盤によってアクセスできる探索空間は変わりうる