IDチームの前田です。
今回は『部下としてのAI 世界一流エンジニアの進化術』の紹介です。
米マイクロソフトの Azure Functions プロダクトチームでシニアソフトウェアエンジニア 牛尾剛さんに執筆された書籍で、前著は『世界一流エンジニアの思考法』で、そちらを読んでいる方も多いのではないでしょうか。
本書はその続編にあたり、生成AI の登場によって著者自身の仕事の進め方がどう変わったかが書かれています。
生成AI の使い方を扱った本は今や山ほどありますが、本書は「AI をどう使うか」よりも「AI を使う側の人間がどう変わるか」に踏み込んでいるのが印象的でした。
さて、今回は、本書を読んでとくに刺さった箇所を紹介します。
3行まとめ
- 『部下としてのAI』は、米マイクロソフトで Azure Functions の開発に従事する牛尾剛さんが、生成AI との協働で得た知見をまとめた本
- AI がコードを書くようになっても、価値が残るのは人間側の「インサイト」と「理解の深さ」
- コンテキスト・マネジメント、Fail Fast の自動化、新しい「Be Lazy」など、明日から試せる話が多い
AI 時代に価値が残るのは「インサイト」
いちばん刺さったのがここでした。
コードを書くこと自体に価値はなくなっていくけれど、インサイトには価値がある
インサイトとは、自分自身のものの見方であり、理解の深さのことだと本書では説明されています。
コードを深く理解して、何にフォーカスし、どんな機能を持たせたいのかを決める。
そうした人間側の判断こそが、創造的な仕事を生み出すために必要だという話です。
周りの優秀なマネージャーやエンジニアは、自分が理解できていない状態を絶対に見過ごさないそうです。
会議でも打ち合わせでも時間をかけて「理解できない」点を解決する。
理解には時間がかかるが、そうすることで以後の生産性が積み上がることを知っているからだ、と書かれていました。
AI が書いてくれるからこそ、読んで理解する力が効いてくる。
著者の観察でも、設計をきちんとできる技術者ほど、バイブコーディングで一気にプロトタイプを作り上げていたそうです。
コンテキスト・マネジメントの極意は「余分な情報を与えない」
実務にすぐ効きそうだったのがこの章です。
コンテキストが膨れ上がりすぎると、AI は情報の矛盾に混乱したり、記憶の限界を超えたりします。
履歴を要約して圧縮する機能はあるものの、その過程で重要な情報が欠落することも少なくありません。
そのうえで、コンテキスト・マネジメントの極意は一言でいえば「余分な情報を与えない」ことに尽きる、と本書は言い切ります。
よくある失敗は、すべての指示を一つの長いプロンプトに詰め込んでしまうこと。
人間の部下だって、一度に大量の指示を出されたらパニックになる、という例えが分かりやすかったです。
原則として、次のような指針が挙げられていました。
- フルヒストリーより、最少のコンテキストを（Minimal Context over Full History）
- 暗黙の推論より、明示的な API 呼び出しを（Explicit Tool Calls over Implicit Reasoning）
- リモートコールより、ローカルファイルを（Local Files over Remote Calls）
細かい指示をあれこれ重ねるよりも、「やってはいけないこと」「最低限守るルール」というハーネスを設定するほうが AI の性能が上がる、という指摘も納得感がありました。
細かく指示すればするほど良いと思って長いプロンプトを書きがちなので、ここは考えを改めたいところです。
早く失敗し、自動化せよ
バイブコーディングの実践にあたって著者が最も強調しているのが「早く失敗せよ」、さらに言えば「失敗を自動化せよ」（Fail Fast, and Automate!）という考え方です。
Fail Fast 自体はアジャイルや DevOps で共通して使われてきた手法ですが、AI が高速にコードを書く前提になると、フィードバックを得る仕組み側を自動化しておかないと追いつかない、というのは言われてみればその通りです。
関連して、こんな一節も好きでした。
「コードを書いたとき、このコードは他人に簡単に説明できるか？って考えるんだ。簡単に説明できなかったら、たぶん君は複雑なことをしている」
新しい「Be Lazy」
前著でも紹介されていた Be Lazy は「より少ない時間で価値を最大化する」という考え方でした。
本書では、これが次のように更新されています。
「より楽をして価値を最大化する」
何かのバリューを出すことを、どうやったら「一番楽に」できるかを考える。
AI という部下が手に入った以上、自分が手を動かす前提を疑うべきだ、ということですね。
センスについての定義も面白かったです。
センス＝問題選択×ユーザー理解×価値の提示速度
多くの人に使ってもらえるソフトウェアを作れる人こそセンスがいい、という定義で、天性のものとして片付けていないのが良いところです。
センスの塊のように見える師匠も、失敗から学んで改良を重ねていた、という話も添えられていました。
ボトルネックは人間側に移る
AI に任せる範囲が広がると、今度は人間の脳が先に音を上げます。
著者自身、調べものもドキュメント作成も面倒な部分もどんどん AI に任せているものの、人間が確認して指示を与えなければならない箇所は残ります。
二つ三つの作業を並行して走らせながらコンテキストスイッチを繰り返していると、脳が相当くたびれてしまう。
バイブコーディングに熱中しすぎて夜中まで起きていることが度々あった、という告白も書かれていました。
対策として挙げられていたのは、生活習慣側を作り替えることです。
- 「AI 前」に戻ろうとせず、「AI 後」のスタイルをつくる
- AI により学習が加速するぶん、脳が早く疲れるのは自然なことだと受け入れる
- 夜は脳が疲れているのでアウトプットや音楽にあて、インプットと学習は朝に持ってくる
そもそも人間が1日に下せる意思決定の数には限りがあり、上限に達すると判断力が鈍る、という話もありました。
AI の使い方の本を読んでいたはずが、最後は睡眠と生活リズムの話になるのが面白いところです。
所感
- AI にコードを書かせるほど、読んで理解する力と、何を作るかを決める力が効いてくる。この一貫した立場が本書のいちばんの主張だと受け取りました
- コンテキスト・マネジメントの話は、Claude Code や各種エージェントを日常的に使っている方ほど刺さると思います
- 未来を予測しようとしないこと、楽観的にリスクをとって挑戦の数を増やすほうがパフォーマンスは上がること。このあたりは、変化の速い領域にいる全員に効く話でした
- 一方で、書かれているのは著者が米マイクロソフトで実践している環境の話です。自分の現場に合う形に翻訳しながら読むのが良さそうです
気になった方は、ぜひ読んで欲しい
