00:00:00（アップビートな音楽）
00:00:02皆さん、こんにちは。調子はいかがですか？
00:00:23お会いできて嬉しいです、デックスです。
00:00:25素晴らしい紹介をいただいた通り、
00:00:27私はしばらくの間、エージェントの開発に打ち込んできました。
00:00:296月の「AI Engineer」での講演「12-Factor Agents」は、
00:00:32史上最高のトークの一つに選ばれました。
00:00:34確かトップ8くらいに入っていたと思います。
00:00:356月のカンファレンスで最も評価されたセッションの一つです。
00:00:38そこで「コンテキスト・エンジニアリング」について触れたかもしれません。
00:00:41さて、今日私がここへ来た理由、お話ししたいことは何でしょうか？
00:00:446月の「AI Engineer」で私が最も気に入った
00:00:46トークの一つについて話したいと思います。
00:00:47昨日イゴールから最新情報の共有があったことは承知していますが、
00:00:49スライドの変更が間に合わなかったので、
00:00:50今日は彼が6月に話した内容をベースに進めます。
00:00:54要するに、あらゆる規模の企業の
00:00:56開発者10万人を対象に調査を行ったところ、
00:00:58多くの場合において、
00:01:00ソフトウェア開発にAIを利用すると、
00:01:01やり直しやコードベースの激しい入れ替わりが発生することが分かりました。
00:01:04複雑なタスクや、
00:01:07既存の（ブラウンフィールド）コードベースではあまり上手くいきません。
00:01:08チャートを見れば一目瞭然ですが、
00:01:10出荷量は大幅に増えているものの、
00:01:11その多くは、先週出荷した
00:01:14質の低いコード（スロップ）の修正に費やされています。
00:01:15一方で、別の側面もあります。
00:01:18新規（グリーンフィールド）開発や、小さなVercelのダッシュボードのような
00:01:21プロジェクトであれば、非常にうまく機能します。
00:01:25しかし、10年もののJavaコードベースに挑もうとすれば、
00:01:28そう簡単にはいきません。
00:01:29これは私自身の経験とも一致していました。
00:01:30個人的な経験や、多くの創業者や
00:01:32優れたエンジニアと話した結果、「スロップが多すぎる」、
00:01:35「技術的負債の工場だ」、「我々のコードベースには使えない」という声を聞きます。
00:01:37モデルが進化すれば、いつか解決するかもしれません。
00:01:40しかし、それこそが「コンテキスト・エンジニアリング」の核心です。
00:01:42今のモデルから最大限の能力を引き出すには？
00:01:44コンテキスト・ウィンドウをどう管理すべきか？
00:01:46この話を8月にしました。
00:01:48白状しなければならないことがあります。
00:01:49初めてClaudeのコード機能を使った時、それほど感動しませんでした。
00:01:53「まあ、少しは便利かな、UXは好きだけど」という程度でした。
00:01:56しかしその後、私たちのチームはあることに気づき、
00:01:59実際に、
00:02:012倍から3倍のスループット向上を実現できました。
00:02:02あまりに多くを出荷できるようになったため、
00:02:06コラボレーションの方法を変えざるを得なくなりました。
00:02:07ソフトウェア構築のあり方を根本から作り直したのです。
00:02:113人のチームで8週間かかりました。本当に大変な作業でした。
00:02:14しかし解決した今、もう以前のやり方には戻れません。
00:02:16これが「スロップ（質の低いコード）をなくす」ということです。
00:02:18私たちは一つの正解に辿り着いたと考えています。
00:02:209月にはHacker Newsで大きな話題になりました。
00:02:23何千人もの人々がGitHubを訪れ、
00:02:25私たちの「Research-Plan-Implement（調査・計画・実装）」プロンプト・システムを導入しています。
00:02:28私たちが導き出した目標はこうです。
00:02:31既存の（ブラウンフィールド）コードベースで機能するAIが必要です。
00:02:35複雑な問題を解決できるAIです。
00:02:38そして「スロップ」をなくすこと。
00:02:40さらに「メンタル・アライメント（認識の同期）」を維持する必要があります。
00:02:42これについては後ほど詳しく説明します。
00:02:44もちろん、あらゆる場面において
00:02:46できるだけ多くのトークンを有効活用したいと考えています。
00:02:47何をAIに有意義にオフロード（肩代わり）させるかは、
00:02:50非常に重要です。
00:02:52とてつもなく大きなレバレッジになります。
00:02:53これが、コーディング・エージェントのための高度なコンテキスト・エンジニアリングです。
00:02:56まずはその枠組みから説明しましょう。
00:02:58コーディング・エージェントの最も未熟な使い方は、
00:03:01何かを依頼し、間違いを指摘して
00:03:03軌道修正を繰り返し、何度も何度も問い詰めることです。
00:03:05コンテキストが尽きるか、諦めるか、泣き出すまでね。
00:03:09もう少し賢いやり方があります。
00:03:11AIを使い始めて早い段階で、
00:03:13多くの人がこれに気づきます。
00:03:17会話が脱線してしまったら、
00:03:21新しいコンテキスト・ウィンドウを開始した方が良いということです。
00:03:24「よし、あの方向はダメだった。仕切り直そう」と言うのです。
00:03:26プロンプトもタスクも同じです。
00:03:27でも今回はこちらの道を進みます。
00:03:29「あっちの方は上手くいかないから行かないで」と指示します。
00:03:31では、いつやり直すべきだと判断するのでしょうか？
00:03:34もしこのような反応が見られたら……
00:03:37（会場笑）
00:03:39おそらく、最初からやり直すべき時です。
00:03:41Claudeに「失敗しているぞ」と伝えた時の決まり文句ですね。
00:03:45さらに賢い方法があります。
00:03:47私はこれを「意図的な要約（Intentional Compaction）」と呼んでいます。
00:03:50これは、順調に進んでいるかどうかにかかわらず、
00:03:53既存のコンテキスト・ウィンドウの内容を
00:03:56Markdownファイルに圧縮するようエージェントに依頼する手法です。
00:03:59それを確認し、タグを付けることができます。
00:04:00そして新しいエージェントが開始されると、
00:04:02最初から作業に取り掛かれます。
00:04:04検索やコードベースの理解に時間を取られ、
00:04:05混乱に陥ることもありません。
00:04:07要約（コンパクション）には何が含まれるのでしょうか？
00:04:09問題は、何がコンテキスト・ウィンドウの
00:04:11容量を占有しているかです。
00:04:13ファイルの探索、コードフローの把握、
00:04:17ファイルの編集、テストやビルドの出力結果。
00:04:20もしJSONや大量のUUIDをコンテキストに
00:04:22垂れ流すようなMCP（Model Context Protocol）を使っているなら、
00:04:25もう目も当てられません。
00:04:26では、何を要約すべきでしょうか？
00:04:28詳細は後で述べますが、
00:04:30これが非常に優れた要約の例です。
00:04:31今まさに取り組んでいる課題、
00:04:33解決すべき問題に関係する
00:04:34正確なファイル名と行番号です。
00:04:37なぜこれほどまでにコンテキストにこだわるのか？
00:04:39LLMはYouTubeでも指摘されましたが、
00:04:42非決定的であるため「純粋関数」ではありませんが、
00:04:45「ステートレス（状態を持たない）」ではあります。
00:04:46LLMからより良いパフォーマンスを引き出す唯一の方法は、
00:04:49より良いトークンを投入することです。
00:04:51そうすれば、より良いトークンが返ってきます。
00:04:52ループを繰り返すたびに、
00:04:53Claudeや他のコーディング・エージェントは
00:04:55次に使うツールを選択します。
00:04:56正しい次の一手は数百通りあるかもしれませんが、
00:04:58同様に、間違った次の一手も数百通りあります。
00:05:00次に出力される内容に影響を与える唯一の要素は、
00:05:03それまでの会話の内容だけです。
00:05:05ですから、正確性、網羅性、サイズ、
00:05:07そして「軌道（トラジェクトリ）」を考慮して、
00:05:10このコンテキスト・ウィンドウを最適化するのです。
00:05:11「軌道」の話は興味深いものです。
00:05:12多くの人がこう言います。
00:05:13「エージェントに指示したのに、
00:05:16間違ったことをした。」
00:05:17「だから修正して叱りつけたのに、
00:05:18また間違ったことをした。」
00:05:20「だからまた叱ったんだ。」
00:05:21LLMはこの会話の流れを見て、こう考えます。
00:05:23「なるほど、私が間違えると人間は叱る、
00:05:24また私が間違えると人間は叱る……」
00:05:26「ならば、この会話において次に出現すべき確率は、
00:05:29私が間違いを犯し、
00:05:31人間にまた叱ってもらうことだ」となってしまいます。
00:05:33ですから、自分の「軌道」に注意してください。
00:05:35これを整理すると、
00:05:36最悪なのは「誤った情報」、次に「欠落した情報」、
00:05:39そして「過剰なノイズ」です。
00:05:42数式で考えるのが好きなら、
00:05:44このような簡単な式で表せます。
00:05:47ジェフ・ハントリーはコーディング・エージェントについて多くの研究をしました。
00:05:51彼は非常に的確に述べています。
00:05:51「コンテキスト・ウィンドウを使えば使うほど、
00:05:53結果は悪化する」と。
00:05:55ここから、ある概念が導き出されます。
00:05:56非常にアカデミックな呼び名ですが、「ダム・ゾーン（愚かな領域）」です。
00:05:59これがあなたのコンテキスト・ウィンドウだとしましょう。
00:06:01約16万8千トークンの容量があります。
00:06:03その一部は出力や要約のために予約されています。
00:06:05モデルによって異なりますが、
00:06:07ここではClaudeのコード機能を例にします。
00:06:09容量の約40%を超えたあたりから、
00:06:10タスクによっては収穫逓減（効率低下）が始まります。
00:06:14もしエージェントにあまりに多くのMCPを詰め込みすぎると、
00:06:17常に「ダム・ゾーン」で作業することになり、
00:06:18決して良い結果は得られません。
00:06:21他の人もこの話をしています。
00:06:21その詳細はここでは省きます。
00:06:22状況によって異なりますが、
00:06:2340%というのはタスクの複雑さに応じた
00:06:26一つの良い目安になります。
00:06:28さて、要約（コンパクション）の話に戻りましょう。
00:06:31今後は「ダム・ゾーンを巧みに回避する」と呼ぶことにします。
00:06:33「サブエージェント」を活用できます。
00:06:37フロントエンド用、バックエンド用、
00:06:39QA用、データサイエンティスト用のサブエージェント……。やめてください。
00:06:44サブエージェントは役割を擬人化するためのものではありません。
00:06:47「コンテキストを制御するため」のものです。
00:06:49例えば、巨大なコードベースの中で
00:06:51何かがどう機能しているかを探したい場合、
00:06:53それがサブエージェントをサポートしていれば、
00:06:55エージェントをそのように誘導できます。
00:06:56あるいは独自のサブエージェント・システムを構築してもいいでしょう。
00:06:58基本的には「これがどう動くか探してきて」と指示します。
00:07:00すると、そのエージェントは新しいコンテキスト・ウィンドウを切り出し、
00:07:03そこで膨大な読み込みや検索、
00:07:05ファイルの精査、コードベースの理解を
00:07:07すべて行います。
00:07:09そして、親エージェントに対して
00:07:13非常に簡潔なメッセージだけを返します。
00:07:14「探していたファイルはここにあります」というように。
00:07:17親エージェントはその一つのファイルを読み、すぐに本題に入れます。
00:07:20これは非常に強力です。
00:07:22これらを正しく使いこなせば、
00:07:23このような優れたレスポンスが得られ、
00:07:25コンテキストを完璧に管理できるようになります。
00:07:29サブエージェントよりも、あるいはその上位レイヤーとして
00:07:30あるいはサブエージェントのさらに上のレイヤーにあるのが
00:07:32「頻繁かつ意図的な圧縮」と私が呼んでいるワークフローです。
00:07:35「リサーチ・計画・実行」については後ほど詳しく話しますが、
00:07:37要点は、常に
00:07:39コンテキストウィンドウを小さく保つということです。
00:07:41コンテキスト管理を中心にワークフロー全体を構築します。
00:07:45これには「リサーチ、計画、実行」の3つのフェーズがあり、
00:07:48常に「スマートゾーン」に留まるようにします。
00:07:51リサーチとは、システムがどう動くかを理解し、
00:07:53適切なファイルを見つけ、
00:07:55客観性を保つためのものです。
00:07:56リサーチに使えるプロンプトの例がこちらです。
00:07:58これがリサーチプロンプトの出力結果です。
00:08:00これらはすべてオープンソース化されています。
00:08:01皆さんも自分で取得して試してみてください。
00:08:04計画フェーズでは、正確な手順を概説します。
00:08:06ファイル名や行のスニペットも盛り込みます。
00:08:08変更を加えるたびに、どうテストを行うかについて
00:08:10非常に明示的に記述します。
00:08:11これが優れた計画プロンプトです。
00:08:12こちらが作成した計画の一つです。
00:08:13実際のコードスニペットが含まれています。
00:08:16そして実行に移ります。
00:08:17これらの計画を読めば、
00:08:17世界で最も性能の低いモデルであっても
00:08:20おそらく失敗しないことが容易にわかるはずです。
00:08:23このように計画通りに進めることで、
00:08:24コンテキストを低く抑え続けます。
00:08:26計画プロンプトについては先ほど言った通り、
00:08:27プロセスの中で最も地味な部分です。
00:08:30これを実際に試してみたかったのです。
00:08:31私は、Boundary ML社のCEOである
00:08:34友人のVaibhavと一緒にポッドキャストをやっています。
00:08:37そこで私は「君の会社の30万行のRustコードベースの
00:08:39プログラミング言語の修正を、
00:08:41一発でやってのけるよ」と言ったんです。
00:08:42そのエピソードはすべて公開されています。
00:08:451時間半ほどの長さです。
00:08:46今はその詳細は語りませんが、
00:08:47多くのリサーチ結果を作成しましたが、
00:08:48質が悪かったのでそれらは破棄しました。
00:08:49そして「リサーチなし」と「リサーチあり」で計画を立て、
00:08:51すべての結果を比較したんです。
00:08:53とても楽しい時間でした。
00:08:54それが月曜の夜のことです。
00:08:55火曜の朝、私たちが番組に出演していた時、
00:08:57CTOがプルリクエスト（PR）を見ていました。
00:08:59彼は私がポッドキャストのネタでやっているとは知らず、
00:09:03「これ、良さそうだね。
00:09:04次のリリースに入れよう」と言ったんです。
00:09:05彼は少し困惑していました。
00:09:08これがその計画です。
00:09:09とにかく、実証されました。
00:09:12既存のコードベースでも「スロップ」なしで機能します。
00:09:14しかし、より複雑な問題も解決できるか見たかったのです。
00:09:17Vaibhavはまだ少し懐疑的でした。
00:09:19土曜日に7時間ほど一緒に座って、
00:09:21BAMLに3万5千行のコードを納品しました。
00:09:24PRの一つは1週間後にマージされました。
00:09:26もちろん、一部は自動生成されたコードです。
00:09:28挙動を更新すると、
00:09:29すべてのゴールデンファイルが更新されるようなものです。
00:09:31それでも、その日に大量のコードを出荷しました。
00:09:33彼は、1〜2週間分の仕事を7時間で終えたと評価しています。
00:09:36これで複雑な問題も解決できることがわかりました。
00:09:40ただし、これには限界もあります。
00:09:41友人のBlakeと一緒に、
00:09:42Parquet JavaからHadoopの依存関係を削除しようとしました。
00:09:46Parquet Javaが何かをご存知なら、
00:09:47あなたのキャリアに何が起きてそこに行き着いたのか、
00:09:50お気の毒に思います。
00:09:53それは上手くいきませんでした。
00:09:55これがその時の計画とリサーチです。
00:09:57ある時点で、すべてを投げ出して、
00:09:58ホワイトボードに戻りました。
00:10:00どこに落とし穴があるかを学んだ後で、
00:10:01実際に自分たちで
00:10:03考え直す必要がありました。
00:10:05「これは実際にどう組み合わさるべきか？」と。
00:10:06このことは、後でJakeが話す
00:10:09非常に興味深いポイントに繋がります。
00:10:11「思考をアウトソーシングしてはいけない」ということです。
00:10:13AIは思考の代わりにはなりません。
00:10:14AIは、あなたが行った思考（あるいは思考の欠如）を
00:10:17増幅させることしかできないのです。
00:10:19よく「これはスペック（仕様）駆動開発ですよね？」
00:10:21と聞かれますが、
00:10:23いいえ、スペック駆動開発という言葉は壊れています。
00:10:27概念ではなく、その「言葉」がです。
00:10:30定義が曖昧なのです。
00:10:33これはThoughtWorksのBrigettaです。
00:10:35多くの人が「スペック」と言いながら、
00:10:37単に「詳細なプロンプト」を意味しています。
00:10:39この写真を覚えている人はいますか？
00:10:41これが何から引用されたか知っている人は？
00:10:43おっと、かなりマニアックでしたね。
00:10:44「エージェントの年」など永遠に来ません。
00:10:46なぜなら「意味の拡散」が起きているからです。
00:10:47Martin Fowlerは2006年にこう言いました。
00:10:49定義のしっかりした良い用語が生まれても、
00:10:52みんなが盛り上がって、
00:10:53100人が100通りの意味で使い始めると、
00:10:56その言葉は役に立たなくなってしまうのです。
00:10:59人としてのエージェント、マイクロサービスとしてのエージェント、
00:11:02チャットボット、あるいはワークフローとしてのエージェント。
00:11:05Simon、ありがとう。
00:11:06結局、振り出しに戻りました。
00:11:07エージェントとは、単にループ内にあるツールのことです。
00:11:09スペック駆動開発にも同じことが起きています。
00:11:11以前はこのプレゼンの冒頭にSeanのスライドを
00:11:15入れていたのですが、それが原因で
00:11:15多くの人が間違ったことに集中してしまいました。
00:11:17「コードのことは忘れろ、今やそれはアセンブリのようなものだ、
00:11:19マークダウンだけに集中すればいい」という彼の考えは、
00:11:21非常にクールですが、みんな「スペック駆動開発」を
00:11:24「良いプロンプト（PRD）を書くこと」だと言い出しました。
00:11:26検証可能なフィードバックループや
00:11:28バックプレッシャーを使うことだと。
00:11:30あるいはSeanが教えたように、
00:11:32コードをアセンブリのように扱うことかもしれません。
00:11:34しかし、多くの人にとっては、コーディング中に
00:11:36大量のマークダウンファイルを使うだけのことになっています。
00:11:37あるいは、先週見つけた私のお気に入りの例では、
00:11:39「スペックとはOSSライブラリのドキュメントのことだ」と。
00:11:43もう無茶苦茶です。
00:11:44スペック駆動開発は過剰に宣伝され、今や無意味です。
00:11:48意味が拡散してしまったのです。
00:11:49そこで、今日実際に役立つ4つのこと、
00:11:52社内や多くのユーザーとの間で効果があった
00:11:55戦術的かつ実践的なステップについてお話しします。
00:11:59まずリサーチを行い、システムがどう動くかを把握します。
00:12:02映画『メメント』を覚えていますか？
00:12:03Peterが言うように、これは
00:12:05コンテキストエンジニアリングに関する最高の映画です。
00:12:07主人公は目覚めると記憶がなく、
00:12:09自分のタトゥーを読んで、自分が誰で
00:12:11何をしようとしているのかを理解しなければなりません。
00:12:12エージェントにオンボーディングをさせなければ、彼らは嘘をつきます。
00:12:17これは皆さんのチームの図です。多くの方にとっては
00:12:19非常に簡略化されていますが。
00:12:19皆さんの組織はもっと大きいはずです。
00:12:21しかし、例えばここにある作業をしたいとします。
00:12:23一つの方法として、すべてのリポジトリに
00:12:26オンボーディング情報を入れることができます。
00:12:27大量のコンテキストを配置するのです。
00:12:28「これがリポジトリで、こう動く」という具合に。
00:12:29これは、コードベース内のすべてのコンテキストを圧縮し、
00:12:32エージェントが実際に作業を始める前に
00:12:34あらかじめ参照できるようにしたものです。
00:12:36これの難しい点は、内容が長くなりすぎることです。
00:12:39コードベースが巨大になると、
00:12:41ドキュメントをさらに長くするか、
00:12:43情報を削ぎ落とすしかありません。
00:12:45そして、これを読み進めるうちに、
00:12:48500万行の巨大なモノレポの
00:12:49コンテキストを読み取ることになり、
00:12:52仕組みを学ぶだけでスマートゾーンを使い果たしてしまいます。
00:12:53すると、その後のツール呼び出しは
00:12:55性能の低いダムゾーンで行うことになってしまいます。
00:12:57ですから、これをスタックごとに分割（シャード）できます。
00:13:02段階的な情報開示を行うのです。
00:13:04細分化できるはずですよね？
00:13:05各リポジトリのルートにファイルを置き、
00:13:08それぞれの階層レベルにおいて、
00:13:11作業場所に応じた
00:13:13追加のコンテキストを持たせるのです。
00:13:15ファイル自体は信頼できる唯一の情報源（Source of Truth）なので、
00:13:17ファイル自体の説明は書きません。
00:13:18しかし、エージェントが作業する際には、
00:13:19ルートのコンテキストを読み込み、
00:13:21次にサブコンテキストを読み込みます。
00:13:22特定のツールの話はしませんが、
00:13:23CloudMDでもHoaxでも、
00:13:24何を使っても構いません。
00:13:26必要なことだけを読み込むので、
00:13:28スマートゾーンにはまだ十分な余裕があります。
00:13:31この方法の問題は、情報が古くなることです。
00:13:33新機能をリリースするたびに、
00:13:35キャッシュを無効化し、
00:13:38内部ドキュメントの大部分を再構築する必要があります。
00:13:42AIを駆使して、
00:13:43この更新をプロセスの一部に組み込むことも可能です。
00:13:46ここで質問です。
00:13:48実際のコード、関数名、
00:13:50コメント、そしてドキュメントの中で、
00:13:51このチャートのY軸が何を表しているか、わかる人はいますか？
00:13:57――スロップ（無駄）。――スロップ。
00:13:58実はこれは、コードベースの各部分に含まれる
00:14:01「嘘の量」を表しています。
00:14:03更新をプロセスに組み込むことはできますが、
00:14:06おそらくやらないでしょうから、お勧めしません。
00:14:08私たちが好むのは「オンデマンドの圧縮コンテキスト」です。
00:14:11SCMプロバイダーやJIRA、Linearに関連する
00:14:14機能を構築しているなら、
00:14:15少しだけ誘導を与えます。
00:14:17「このコードベースの
00:14:18このあたりの範囲を対象にする」と言えば、
00:14:21優れたリサーチプロンプトやスラッシュコマンドが、
00:14:24皆さんのスキルを活かして、
00:14:27サブエージェントを起動し、コードベースを垂直にスライスして、
00:14:30コードベースを垂直にスライスし、調査ドキュメントを作成します。
00:14:33それは、現時点での正確なスナップショットであり、
00:14:35実際のコードに基づいた、重要な部分だけを抽出したものです。
00:14:39私たちは「真実」を圧縮しているのです。
00:14:41「計画」こそがレバレッジとなります。
00:14:43計画とは、意図を圧縮することに他なりません。
00:14:45そして計画段階で、正確な手順を概説します。
00:14:48調査結果、PRD、バグチケットなど、
00:14:50元となるものが何であれ、それらを取り込みます。
00:14:52そして「プラン・ファイル」を作成するのです。
00:14:54ここでもまた、情報を凝縮しています。
00:14:55ここで一度立ち止まり、メンタル・アライメントについて話しましょう。
00:14:58コードレビューは何のためにあるか、分かりますか？
00:15:00メンタル・アライメント、つまり認識合わせのためです。
00:15:05もちろん、正確性を確認するためでもありますが、
00:15:08最も重要なのは、チーム全員が
00:15:10共通の認識を持てるようにすることです。
00:15:11コードベースが「どう」変わり、「なぜ」変わるのかについてです。
00:15:14私は毎週1,000行のGolangを読むことができます。
00:15:17いや、1,000行も読むのは無理ですね。
00:15:18大変ですが、やろうと思えばできます。
00:15:19ただ、やりたくないだけです。
00:15:20チームが成長すれば、すべてのコードがレビューされます。
00:15:23コードを読まないわけではありません。
00:15:24しかし、チームのテクニカルリーダーとしての私は、
00:15:27「計画」を読むだけで、状況を把握し続けることができます。
00:15:29それで十分なのです。
00:15:30問題を早期に発見し、
00:15:32システムがどのように進化しているかを理解し続けられます。
00:15:35Mitchellが素晴らしい投稿をしていました。
00:15:36彼はプルリクエストに
00:15:38AMP（エージェント）のスレッドを載せているそうです。そうすれば、
00:15:41GitHub上の膨大な差分テキストだけでなく、
00:15:43正確な手順やプロンプトを確認でき、
00:15:44「最後にビルドを実行して成功した」ことも分かります。
00:15:46これにより、レビュアーを開発の過程へと導くことができます。
00:15:49これはGitHubのPRだけでは不可能なことです。
00:15:51以前の2、3倍のペースで
00:15:52コードを出荷するようになる中で、
00:15:54チームの認識を一致させる方法を見つけるのは
00:15:57皆さんの責任です。「これこれの手順で行い、
00:16:00手動テストでこう確認した」と示す必要があるのです。
00:16:01目標はレバレッジであり、モデルが正しく動作するという
00:16:04高い確信を得ることにあります。
00:16:06計画を読んでも、実際に何が起こり、
00:16:08どんなコード変更がなされるか分からないのでは意味がありません。
00:16:11そのため、試行錯誤の結果、私たちの計画には
00:16:14変更箇所の実際のコードスニペットを含めるようにしました。
00:16:17目標はレバレッジです。
00:16:18意図を圧縮し、
00:16:19確実な実行を実現したいのです。
00:16:22私は物理学を専攻していました。
00:16:23私たちはピークや曲線の中心に線を引くのが好きです。
00:16:28計画が長くなるほど信頼性は上がりますが、
00:16:30読みやすさは低下します。
00:16:31チームやコードベースにとっての「スイートスポット」が
00:16:33必ずあるはずなので、それを見つけてください。
00:16:35調査結果や計画をレビューし、
00:16:37それらが優れていれば、認識の同期（メンタル・アライメント）が可能になります。
00:16:40「考えること」を丸投げしてはいけません。
00:16:42以前も言いましたが、これは魔法ではありません。
00:16:44完璧なプロンプトなど存在しないのです。
00:16:46計画を読まなければ、うまくいくはずがありません。
00:16:50だから私たちは、開発者がエージェントと対話し、
00:16:53作成された計画を読み進めるという、
00:16:55人間中心のプロセスを構築しました。
00:16:56そして、ピアレビューが必要なら、
00:16:58誰かに送ってこう聞けばいいのです。
00:16:58「この計画で合ってる？
00:17:00アプローチはこれでいいかな？
00:17:00確認する順番はこれで大丈夫？」と。
00:17:03Jakeもブログで書いていましたが、
00:17:05「調査・計画・実行」のサイクルを価値あるものにするのは、
00:17:07人間が介在し、正しさを担保することなのです。
00:17:11この話から一つだけ持ち帰ってほしいことがあります。
00:17:14それは、「悪いコード1行」は単なる悪いコードですが、
00:17:17「悪い計画の一部」は「100行の悪いコード」になり得るということです。
00:17:22また、システムの仕組みや場所についての
00:17:25「悪い調査（誤解）」があれば、
00:17:27すべてが台無しになります。
00:17:29モデルを間違った方向へ導いてしまうからです。
00:17:31社内やユーザーとの取り組みにおいて、私たちは常に、
00:17:34このパイプラインの中で最もレバレッジの高い部分に
00:17:36人間の努力と集中力を向けようとしています。
00:17:39考えることを丸投げしないでください。
00:17:41気分を良くさせるためだけに
00:17:43大量のMarkdownファイルを吐き出すだけのツールには注意しましょう。
00:17:45具体的な名前は出しませんが。
00:17:47時には、ここまでやるのが過剰な場合もあります。
00:17:49私が考えているのは、
00:17:51常にフルセットの「調査・計画・実行」が必要なわけではないということです。
00:17:54もっと多く必要な時もあれば、少なく済む時もあります。
00:17:56ボタンの色を変えるだけなら、
00:17:57エージェントに直接指示すればいいのです。
00:18:00単純な計画や小さな機能ならそれで十分です。
00:18:04複数のリポジトリにまたがる中規模な機能なら、
00:18:07調査を行ってから計画を立てるべきでしょう。
00:18:09要するに、解決できる問題の難易度の限界（天井）は、
00:18:10コンテキスト・エンジニアリングによる情報の圧縮を
00:18:13どれだけ徹底できるかによって決まります。
00:18:15より困難な課題に取り組むなら、
00:18:18より多くの準備が必要になるでしょう。
00:18:19「どれくらいのコンテキスト・エンジニアリングが必要か」
00:18:21とよく聞かれますが、
00:18:23それは反復練習（レップス）次第です。
00:18:24何度も失敗するでしょう。何度も何度も
00:18:26やりすぎてしまったり、足りなかったりして、
00:18:27失敗を重ねる必要があるのです。
00:18:29まずは一つのツールを選んで、使い込んでみてください。
00:18:32ClaudeやCodexなど、さまざまなツールを
00:18:35あれこれ使い分けて効率を最大化しようとするのはお勧めしません。
00:18:36私は略語が好きではありません。
00:18:40「仕様書駆動開発」は破綻したと言いました。
00:18:42「調査・計画・実行」が最終的なステップになるとは思いません。
00:18:44重要なのは情報の圧縮とコンテキスト・エンジニアリングであり、
00:18:47人間が「スマート・ゾーン」に留まり続けることです。
00:18:48しかし、世間ではこれを「RPI」と呼び始めており、
00:18:50もはや私にはどうすることもできません。
00:18:52注意してください、完璧なプロンプトも
00:18:55特効薬（シルバーバレット）も存在しません。
00:18:56もし流行りの言葉を使いたいなら、
00:18:58これを「ハーネス・エンジニアリング」と呼んでもいいでしょう。
00:19:00それはコンテキスト・エンジニアリングの一部であり、
00:19:01Codex、Claude、Cursorなどの連携ポイントを
00:19:03どう活用し、
00:19:05自分のコードベースをどう適応させるかということです。
00:19:07では、次は何が来るでしょうか？
00:19:11コーディング・エージェントの技術は、
00:19:12いずれコモディティ化すると考えています。
00:19:13誰もがその使い方を学び、上達していくでしょう。
00:19:15本当に難しいのは、チームのあり方や
00:19:17ソフトウェア開発ライフサイクル（SDLC）をどう適応させるかです。
00:19:21コードの99%がAIによって出荷される世界において。
00:19:24これを見出せなければ、おしまいです。
00:19:26ある種の「溝」が広がりつつあります。
00:19:27スタッフエンジニアはAIを採用しません。
00:19:29彼らにとってはそれほどスピードアップに繋がらないからです。
00:19:31一方で、ジュニアやミドル層はAIを多用します。
00:19:33スキルギャップを埋めてくれるからです。
00:19:35しかし、それは同時に「ゴミ（slop）」も生み出します。
00:19:36そしてシニアエンジニアはAIをますます嫌うようになります。
00:19:38先週Cursorで出荷されたばかりのコードの
00:19:40後始末に追われることになるからです。
00:19:42これはAIのせいではありませんし、
00:19:44ミドル層のエンジニアのせいでもありません。
00:19:46文化を変えるのは非常に困難であり、
00:19:48成功させるにはトップダウンでの変革が必要です。
00:19:50もしあなたが企業のテクニカルリーダーなら、
00:19:52一つのツールを選んで、まずは使い込んでみてください。
00:19:54興味があれば、私たちは現在採用活動を行っています。
00:19:56あらゆる規模のチームが「99% AI生成コード」の世界へ
00:19:59最短で到達できるよう、エージェント型IDEを構築しています。
00:20:03一緒に働きたい方は、ぜひお話ししましょう。
00:20:06ウェブサイトを見るか、メールを送ってください。
00:20:08会場で見かけたら声をかけてください。
00:20:09本日はありがとうございました。
00:20:11（観客の拍手）
00:20:13（アップテンポな電子音楽）