メインコンテンツにスキップ

スタンフォードCS146Sに見るAIコーディング開発の現在地

AIエージェントと開発
スタンフォード大学のCS146S「The Modern Software Developer」は、開発者の仕事を「コードを書くこと」から「エージェントに正しい文脈を渡し、出力を検証すること」へ定義し直している。講師のMihail Eri…
作者

obelos

公開

2026年11月8日

更新日

2026年11月8日

スタンフォード大学のCS146S「The Modern Software Developer」は、開発者の仕事を「コードを書くこと」から「エージェントに正しい文脈を渡し、出力を検証すること」へ定義し直している。講師のMihail Eric氏がAAIF Liveで行った講演「How Stanford Teaches AI Coding Now」をもとに、講義の中身と、その背景にある技術・実務の潮流を整理する。

要点

  • カリキュラムは1年で8割以上が入れ替わった。 2026年秋学期は前年の教材の約85%を捨て、エージェントスキル、コンテキストエンジニアリング、MCP、エージェントによるコードレビュー、ソフトウェアファクトリーに置き換えている。
  • 中核の作法はRPI（Research → Plan → Implement → Test）である。 いきなり実装させず、調査で文脈を集め、計画を人間が確認し、実装後に自動で検証する。
  • ボトルネックはコード生成から検証と文脈設計に移った。 Playwrightやブラウザ操作用MCPによる動作確認、意図単位で設計したMCPサーバー、永続的な記憶の仕組みが差を生む。

講演者と講演の場

Mihail Eric氏は、スタンフォード大学の非常勤講師としてCS146Sを担当し、同時に営業向けAIプラットフォームを提供するスタートアップMonacoでHead of AIを務めている。Amazon Alexaで初期の大規模言語モデル開発に携わり、複数のAIスタートアップを創業した経歴を持つ。

講演の場であるAAIF（Agentic AI Foundation）は、Linux Foundation傘下で2025年12月に発足した団体である。AnthropicのMCP（Model Context Protocol）、Blockのgoose、OpenAIのAGENTS.mdの3プロジェクトを母体とし、エージェント関連の標準をベンダー中立に管理する。MCPの「本拠地」で、AI時代の開発教育が語られたという位置づけになる。

CS146S「The Modern Software Developer」とは

CS146Sは2025年秋学期に開講した、AIによるソフトウェア開発ライフサイクル全体の変化を扱う講義である。AIツールの使用を禁止するのではなく、全面的に使うことを前提にしている。

2026年秋学期（9月22日開講）は、前年の教材の約85%を刷新した。扱うテーマは次のとおりである。

領域 内容
実行基盤 AIハーネス、エージェントのループ処理、エージェントスキル
文脈設計 コンテキストエンジニアリング、エージェントが扱いやすいコードベースの原則
接続 MCPサーバーの設計と運用
品質 エージェントによる完全自動のコードレビュー、検証の自動化
運用 DevOpsへのエージェント導入、ソフトウェアファクトリー

GitHub Copilotで補完を受ける段階はすでに前提であり、講義の焦点は「複数のエージェントをどう組み合わせ、どう品質を担保するか」にある。

宿題は実在のOSSへのコントリビューション

宿題は人工的な演習問題ではなく、主要なオープンソースプロジェクトへの実際のコントリビューションである。既存の大規模コードベース（ブラウンフィールド）を読み、メンテナーのレビューを通過するPRを出すことが求められる。

AIエージェントは新規の小さなコードではほぼ失敗しないが、既存の大規模コードベースでは文脈不足で破綻しやすい。実務で差がつくのは後者であり、宿題の設計はその現実に合わせている。課題そのものはGitHubリポジトリ（mihail911/modern-software-dev-assignments）として公開されている。

RPIループ：調査・計画・実装・検証

講義で繰り返し教えるのがRPIループである。もとはHumanLayerのDex Horthy氏が、既存の大規模コードベースでコーディングエージェントを機能させるために提唱したワークフローで、講義ではこれに検証（Test）を加えた形で扱う。

フェーズ エージェントがやること 成果物 人間の関与
Research 関連ファイル・既存パターン・依存関係を調べる 圧縮した調査メモ 調査範囲の妥当性を確認
Plan 変更するファイル、手順、各段階のテスト方法を書く 実装計画（仕様書） ここを最も厚くレビューする
Implement 計画どおりに実装する コード差分 原則として計画との差分だけ見る
Test 自動テスト・画面操作で動作を確かめる テスト結果・証跡 証跡で合否を判断

なぜフェーズを分けるのか

LLMは状態を持たない。出力の質を上げる手段は入力（コンテキスト）を最適化することだけである。1つのセッションで調査も実装も行うと、コンテキストウィンドウが調査の途中経過で埋まり、モデルの判断精度が落ちる。

RPIでは各フェーズの成果物をファイルに書き出し、次のフェーズは新しいセッションでその成果物だけを読み込む。これによってコンテキストを常に小さく保つ。人間のレビューを計画段階に集中させるのも同じ理由である。数百行のコード差分を読むより、数十行の計画を読む方が誤りを早く安く見つけられる。

規模による使い分け

すべての作業にRPIを適用する必要はない。

作業の規模 進め方
ボタンの色変更など エージェントに直接指示する
小さな機能追加 簡単な計画を立ててから実装する
中規模の機能追加 調査を1回行い、計画、実装
既存の大規模コードベースでの複雑な改修 RPIを全段階で回し、フェーズごとにコンテキストを圧縮する

検証の自動化が必須になった

エージェントが「完了しました」と報告しても、それは実装が終わったことを意味するだけで、動作が確認されたことを意味しない。講演では、この差を埋める検証の仕組みが今や不可欠だと強調している。

  • Playwrightによるブラウザテスト：エージェント自身がE2Eテストを書き、実行し、失敗したら修正する。
  • MCP経由のブラウザ・デバッグツール：エージェントが実際の画面を開き、コンソールログやネットワークリクエストを読んで不具合を特定する。
  • 動作の記録と証明：画面操作を録画・スクリーンショットとして残し、PRに証跡として添付する。レビュアーはコードを読む前に、意図どおり動いたかを確認できる。

検証をエージェントのループに組み込むと、人間のレビューは「動くかどうか」ではなく「設計として妥当かどうか」に集中できる。

トークンコストを前提にしない使い方

講義にはAnthropicでClaude Codeを開発したBoris Cherny氏らがゲスト講師として登壇している。最前線の開発者は、トークンコストを節約対象ではなく生産性への投資として扱っている。

  • 複数エージェントの並列実行：Cherny氏は複数のターミナルでClaude Codeのインスタンスを同時に動かし、1日に数十のPRを出す。
  • 計画モードから始める：大半のタスクは計画（Plan Mode）から始め、計画が固まってから実装に移る。
  • エージェント同士のレビュー：あるエージェント群が問題点を洗い出し、別のエージェント群がその指摘が誤検知でないかを検証する。
  • メタプロンプティング：エージェントにプロンプト自体を生成・改善させ、自律的に試行を繰り返させる。

さらに規模を上げると、数千のエージェントを同時に走らせる「ソフトウェアファクトリー」の考え方になる。開発者の役割は、コードを書く人から、エージェントの作業を設計・監督する人へ移る。

MCPサーバーは「意図」単位で設計する

MCPサーバーを作るとき、既存のREST APIをそのまま1対1でツール化するのはアンチパターンである。講演では、エージェントが達成したい意図（インテント）に合わせてツールを設計すべきだとしている。

設計方針 ツールの例 エージェント側で起きること
APIの1対1変換 get_customer、list_orders、list_tickets、get_ticket_detail 何度もツールを呼び、結果をつなぎ合わせる。途中の生データでコンテキストが埋まり、組み合わせを誤りやすい
意図単位の設計 summarize_customer_open_issues(customer_id) 1回の呼び出しで、判断に必要な要約済みの情報が返る

意図単位で設計する利点は3つある。ツール呼び出しの回数が減る。返すデータを判断に必要な粒度に絞れるため、コンテキストを節約できる。ツールの説明文が「何のために使うか」を表すため、エージェントがツールを選び間違えにくい。

MCPは人間向けAPIの別名ではなく、エージェント向けのインターフェースである。設計の起点は「エンドポイントの一覧」ではなく「エージェントが解く問い」に置く。

Monacoの事例：営業領域のAIエージェント

講演の後半では、Eric氏が所属するMonacoでの取り組みを紹介している。Monacoはスタートアップ向けのAIネイティブな営業プラットフォームで、2026年2月に3,500万ドル超の調達とともに正式公開し、同年5月にはBenchmark主導で5,000万ドルのシリーズBを調達した。

データを1か所に集めてGTMを自動化する

Monacoは、CRM、メール配信（シーケンサー）、受信箱、商談録画、見込み客データベースなど、従来は別々のツールに分かれていた営業の仕組みを1つのプラットフォームに統合している。商談の文字起こし、メール、Slackのやり取りまで同じ場所に集め、成果を出している営業担当者のやり方をエージェントに学ばせる。ターゲット市場の算出から、アウトバウンド営業、パイプライン管理までをエージェントが実行し、人間の営業担当者は関係構築と最終判断に集中する。

これはコーディングで起きている変化と同じ構造である。エージェントの性能はモデルだけでは決まらず、どれだけ正確な文脈をそろえられるかで決まる。

Monaco Memory：永続的な記憶の層

Monaco Memoryは、組織やユーザーの文体、過去のやり取り、顧客ごとの経緯を永続的に保持する仕組みである。講演では、Andrej Karpathy氏が2026年4月に提唱した「LLM Wiki」に近い仕組みとして説明している。

LLM Wikiは、LLMに構造化されたMarkdownのWikiを継続的に書かせ、保守させるパターンである。従来のRAGとの違いは次のとおり。

観点 従来のRAG LLM Wiki型の記憶
知識の扱い 質問のたびに生データから断片を検索し、組み立て直す 情報源を取り込んだ時点で要約・相互参照・矛盾検出まで済ませ、Wikiとして保存する
蓄積 質問を重ねても何も蓄積されない 情報源や質問が増えるほどWikiが充実する
書き手 人間が文書を用意する LLMがページの作成・更新・リンク整備を担い、人間は情報源の選定と問いの設定を担う

営業に当てはめると、顧客ごとのページに過去の商談、懸念事項、決裁者、使った言い回しが蓄積され、次のメールや提案がその履歴を踏まえて作られる。パーソナライズされたアウトバウンド営業は、この記憶の層があって初めて成立する。

まとめ

CS146Sが示しているのは、AIコーディングの主戦場がコード生成の速度ではなく、次の3点に移ったということである。

  1. 文脈の設計：RPIでフェーズを分け、エージェントに必要十分なコンテキストだけを渡す。
  2. 検証の自動化：PlaywrightやMCPで動作を確かめ、証跡を残す。「実装した」と「動作を確認した」を区別する。
  3. インターフェースと記憶の設計：MCPサーバーを意図単位で作り、LLM Wiki型の永続的な記憶でエージェントに組織の知識を持たせる。

この3点はコーディングに限らず、営業・企画・運用など、エージェントに仕事を任せるすべての領域に共通する。

参考

次に読む