"AIエージェント時代、正直しんどい話" に対する処方箋
最近「AIエージェント時代、正直しんどい」という記事を読んでめちゃ共感しました。
そこで下記のようにXでポストしたところ、思った以上に反響がありました。
このポストは これからは 「認知負荷とどう戦うか」のゲームになるだろう という話なのですが、この戦いに使えるTipsを形に残したいと思いこの記事を書き始めました。
例えば、認知負荷が高いものに対してはDivide and Conquer（分割統治） などが有名ですが...
この手の問題に対して体系的に深く解説している「プログラマー脳」を使い、元記事で挙げられた6つの問題それぞれに対する処方箋として紹介したいと思います。
この本は 「脳の働きをより深く理解することで、プログラマーとしてのスキルや習慣を向上させる」 というアイデアがコンセプトです。
2年くらい前に日本語訳された本ですが、正直、今が一番この本を主体性を持って読める最高のタイミングだと思います。興味がある人は本も読んでみることをおすすめします。
プログラマー脳の基礎
まず、「プログラマー脳」の核心を押さえておきましょう。
3つの記憶システムがあるということ
- 長期記憶（LTM）: パターン、言語知識を保存
- 短期記憶（STM）: ジャンプ先の関数名、変数名、処理の流れなど4-6個の情報を一時保管
- ワーキングメモリ: 2-6個しか同時処理できない
チャンキング
複数の情報を「塊」にまとめる技術。
例: 「S・T・R・A・T・E・G・Y」（7個）→「Strategy」（1個）
パターンを知っていれば、AI生成コードであろうと、自分の辞書にある「パターン」として1つの塊で理解できるだろう？というアイデアです。
混乱の3つの原因
- 知識不足: パターンを知らない
- 情報不足: 変数名が不明瞭
- 処理能力不足: ワーキングメモリがオーバーフロー
私は最近(AIエージェント時代)は主に「3. 処理能力不足」が問題であると考えています。
ワーキングメモリがオーバーフローすることによって10年, 15年選手のベテランエンジニアでも「疲れる」といった意見を何度も観測しています。
オーバーフローしないためにいかにパターンを認識しチャンキングを行うかというところが肝だと思います。
問題1: 全承認が一人に集中
なぜしんどいのか
複数のエージェントの成果物を同時にレビュー → ワーキングメモリが限界を超える。
- エージェント1: ワーキングメモリ3個
- エージェント2: ワーキングメモリ3個
- エージェント3: ワーキングメモリ3個
→ 合計9個 = オーバーフロー
処方箋: レビュー観点を1つに絞る
今回は「バグ」だけ、次回は「セキュリティ」だけ。
レビュー目的を1つに絞る = ワーキングメモリの使用量を削減。
問題2: ドカンと積まれる成果物
なぜしんどいのか
spec.md（200行）、tasks.md（100行）、変更ファイル5個...
ワーキングメモリ2-6個の限界を大幅に超える情報量。
処方箋: AIへの指示を2-6個に分割
BAD: 「PDFページ操作機能（追加、削除、並び替え、分割、結合）を実装して」
GOOD:
- タスク1: addPageメソッドだけ
- タスク2: deletePageメソッドだけ
- タスク3: reorderPagesメソッドだけ
- タスク4: splitPDF、mergePDFメソッド
- タスク5: ドキュメント
1タスク = ワーキングメモリ2-3個で処理できる粒度
問題3: 「完璧です」が信用できない
なぜしんどいのか
AIは「今この瞬間、この仕様で動く」だけ。前提が崩れたら？メンテは？
知識不足 + 情報不足 → コードの「意味」が理解できない → 不安
処方箋: よく使われるパターンを学び、ポイントを抑える
学ぶべきパターンの例:
- GoF（Strategy、Factory、Observer）
- React（HOC、Render Props）
- アーキテクチャ（Clean Architecture、MVVM）
効果:
- AI生成コードを「パターン」として認識し、細かい部分ではなく大枠で問題ないかを捉える
- 「ああ、Strategyパターンね」で理解完了
問題4: レビューしきれん
なぜしんどいのか
知らないライブラリ、知らないパターン。「詳しい人」がいない。全部自分で判断。
情報不足 → 理解できない → 不安
処方箋: コメントでガイドを配置
AIに生成させる前に、コメントで「何をするか」を書く。
class PDFGenerator {
// TODO: プラグインの初期化
// TODO: PDF生成処理
// TODO: 後処理
}
効果:
- AIがガイドに沿って実装
- レビュー時も「ガイド通りか」だけチェック
問題5: 「分からんけど動く」
なぜしんどいのか
「なんで動いてるか分からん。壊れたら直せるか分からん。」
コードの所有感がない → 不安がずっと続く
処方箋: 雛形は人間が作る
人間が事前にやること:
- インターフェース・型定義を作成
- メソッドのシグネチャを定義
AIに丸投げしない = 設計図を握る = 所有感を保つ
問題6: 記憶に残らん
なぜしんどいのか
手を動かせば苦労と紐づいて記憶に残る。AIに書かせると「動いた、終わり」。脳に引っかかってない。
長期記憶への定着プロセスが欠如
処方箋: AIをメンターとして使う
- BAD: 「作って」 → 記憶に残らない
- GOOD: 「ここどうしたらいい？」 → 記憶に残る
選択肢を出させ、自分で選び、自分で書く。
まとめ
元記事をリスペクトしたかったので記事内に挙げられている問題を全て利用させていただきましたが、うまいこと重複しないように分解するのが難しかったです。が、言いたいこと伝わっているといいな...(伝われ)
| 問題 | 処方箋 |
|---|---|
| 1. 全承認が一人に集中 | レビュー観点を1つに絞る |
| 2. ドカンと積まれる成果物 | タスクを2-6個に分割 |
| 3. 「完璧です」が信用できない | よく使われるパターンを学ぶ |
| 4. レビューしきれん | コメントで「ガイド」配置 |
| 5. 「分からんけど動く」 | 雛形は人間が作る |
| 6. 記憶に残らん | AIをメンターとして使う |
核心は「ワーキングメモリは限られた数しか同時処理できない」ということで、
この限界を知り、AIとの協働方法を工夫すれば、認知負荷は管理できるはずです。
これ自体はAI時代に新しく登場した事象やテクニックではないですが、ここ最近このテクニックの重要性を深く感じています。
もちろん実際にデプロイするには細部の確認は欠かせませんが、全てを細かくチェックすることがそもそも疲労の原因なので "適切にサボれる場所を探す" イメージです。
「ワーキングメモリの限界を知り、オーバーフローを避けるために意図的にチャンキングを行うこと」ぜひ日々の開発で意識してみてください。少しでもAI疲れを軽減するきっかけになると嬉しいです。
プログラマー脳ではここで取り上げた問題だけではなく、体系的に説明してあるのでもっと詳しく知りたい！という方はぜひ書籍も読んでみてください。(認知科学とか好きな人は絶対読んだ方がいい)
最後までお読みいただきありがとうございました。
Xでも情報発信しているので、フォローしていただけると励みになります！
Discussion
記事とりあげて下さってありがとうございます。AI使ってて愚痴みたいなことをつらつら書き連ねてたら、みんなもまあまあ思ってはったみたいで、思いの外読んでいただいたみたいで、恐縮しております。
コーディング・システム設計とは別の、マネージャーとしての質の違う負荷も感じてます。エンジニアやったら常識やろってことも、たまに話通じんこともあったり…まあ話が通じん人もいますけど笑
オーケストレーションの時代がくるかもしれないですけど、AIって、ショボいミスで「あっ、これ忘れてました」とか、AI自身の短期メモリの少なさから？「さっき言うたやん、もう忘れたん？」みたいなこともあって、あんまり信用できひんのですよね～。なので、レビューもAIにさせたれ、っていうのも心配なんです。
多分、過渡期なんで、もうちょい記憶が長持ちしたり、AI自身に責任（ペナルティ）与えたりして教育するみたいな機能がついてきたら、ちょっとは信頼したってもええ（横柄）ようになるかもしれないですね。
ただ、必須の協業相手になると思うんで、触れ続けることは大切ですね。処方、ありがとうございます～
コメントありがとうございます。ryoさんが記事にしてくれて、多くの人が共感したのですごい話題になってましたね。
おっしゃる通り、過渡期なのは間違いないと思います。
数年前と仕事がガラッと変わって、たまに自分何してるんだっけ？ってなることがあります。
コーディングの喜びが懐かしいです。少し寂しいですが、これからも臨機応変に対処していくしかないのだと思います。
記事を読ませていただきました。
個人的には「コメントでガイドを配置する」というのが斬新だなと思いました。ある意味LLMのコード生成を活かしつつ設計の部分をしっかり人間が噛む、という意味合いとしても有効ですね！
コメントありがとうございます〜
これ、個人的には自分がOJT期間の時に先輩におおまかな実装の手順を組み立ててもらったりしていたのを思い出しました。これだと初めからどこを作ってもらうのかが明確なのでレビューも効率がいいから良さそうですね