第IV部 ケーススタディ ・ 第17章
本章は架空企業 Theoretical Ride Sharing（従業員2,000名、うちソフトウェアエンジニア300名、Uber や Lyft に似たライドシェア事業）を題材に、4つのドキュメントを掲載する。17-1は LLM 導入が会社の開発者体験に与える影響を検討する戦略ドキュメント、17-2はその影響をシステムモデルで定量化したもの、17-3は LLM エコシステム（OpenAI、Anthropic、Google などのモデルプロバイダーや、エージェント・RAG フレームワーク）の Wardley マップ、17-4は LLM をドライバーオンボーディング（事業側のユースケース）に適用したときの効果をモデル化したものである。
読み方は前章と同様で、戦略を適用したいなら方針から順に、思考プロセスを理解したいなら探究から逆順に読むとよい。とくに2つのモデル章（17-2, 17-4）は、結論だけでなくモデルをどう組み立て、設定値を変えながら検証して学びを得ていく過程そのものが学習対象になる。
方針セクションの中心は「成果を出せるドライバー（社内のエンジニアやリーダー）が LLM を活用しやすくする」ことと、その活用をリスクとリターンのバランスを取りながら慎重に進めることにある。具体的な方針として、(1) サービスプロビジョニング調整を担う内部ツールを作る、(2) Phabricator のドキュメントレビューに LLM を組み込む、(3) すべてのチームに LLM プロトタイピングを許可するが本番投入は慎重に判断する、といった行動が挙げられる。重要なのは、利用許可と本番運用とを段階的に分け、リスクを管理しながら学習機会を確保する姿勢である。
診断セクションでは、(1) 共通の解決策あるいは共通の無効化により、社内のニーズが少なくとも3つの異なるグループ（非エンジニアの生産性向上ツール、エンジニアの生産性向上ツール、プロダクトの拡張）に分かれる、(2) これらのほとんどはまだ実験段階で本番運用の知見は少ない、(3) 意思決定は急ぐ必要があるが、現場が情報不足のまま個別に判断するとリスクとローリターンになりやすい、(4) 社内には LLM の知識やスキルが偏在しており、それを底上げするにはハンズオンの機会が要る、といった現状が率直に把握される。
探究セクションでは、基盤モデルを自前でトレーニングする選択肢が現実的でないことを確認する。Meta は LLaMA 2 を約2,000万ドル、推定で数千万GPU時間かけてトレーニングしており、OpenAI の GPT-4 のトレーニングコストは1億ドルを超えると報じられる。GitHub Copilot などの外部サービスを使うほうが現実的であり、自社にとっては「基盤モデルを自前で持つかどうか」よりも「既存のモデルやサービスをいかに賢く使うか」が論点だと結論づける。
このモデルから得られる学びは3つに要約される。第一に、本番環境で発生するエラー率を下げても、それだけでは開発のスループット（クローズされたチケット数）は頭打ちになり、根本的な改善には至らない。第二に、チケットの着手やテストを速くしても、ノイズ（仕掛かりのばらつき）が増えるだけで進捗は生まれない。第三に、これら2つを組み合わせて初めて、本番のエラー率を下げつつスループットも改善するという有意な前進が見える。要するに、開発速度を上げてもエラー率を下げる手当てがなければ、差し引きでマイナスになりうることを浮き彫りにする。
モデリングは、開発者のワークフローを5つのストック（Open Tickets＝未着手、Started Coding＝作業中、Tested Code＝テスト済み、Deployed Code＝デプロイ済み、Closed Tickets＝クローズ済み）として表現する。これらは左から右へとパイプライン状に進むが、各段階にはエラーによる右から左への手戻りが3つ存在する。本番環境で発見されたバグ（Closed→Open）、デプロイ中に発見されたバグ（Deployed→Started）、テスト中に発見されたバグ（Tested→Started）である。著者はまず Excalidraw でスケッチし、続いて Google スプレッドシートでフローを数式として実装する（着手率・テスト率・デプロイ率や各段階のエラー発生率を Config シートに置き、絶対参照で各ステップに反映させる）。
モデルの検証では、設定値を変えて挙動を比較する。ベースモデルではクローズ済みチケットの数が頭打ちになり、遅れが拡大し続ける。本番エラー率（ErrorsInProd）を0.25から0.1に下げると完了処理は進むが、ある時点で「完了チケット数」と「本番エラー率」が均衡し進捗が止まる。テスト率（TicketTestRate）や着手率（StartCodingRate）を1から3に上げても、制約がチケットの着手段階にあるため挙動は変わらない（ノイズが増えるだけ）。これらの実験から、開発速度の改善とエラー削減の両方を同時に手当てしなければ意味がないという、直感に反する結論が導かれる。
このマップは、2024年時点の LLM パターン（プロダクトエンジニア、機械学習インフラ、セキュリティとコンプライアンス、エージェントのサポート、RAG を支える検索インデックス、評価、API プロキシ、モデルへ送信する内容の可視性、最新モデルへのアクセス、LLM ベンダー契約など）を可視性と進化段階の上に配置し、この領域がどう進化するかを検討するためのものである。
将来の状態への移行では、この領域の進化を決める2つの問いが浮かび上がる。(1) エージェントや RAG 向けの LLM フレームワークプラットフォームは、OpenAI や Anthropic のようなモデルプロバイダーとバンドルされたまま提供されるのか、それともモデルとプラットフォームが分離して別々に提供されるようになるのか。(2) LLM フレームワークのどの部分がプロダクトとして成立するのか（例えば評価の実行機能はバンドル提供に向かいそうだが、RAG はリアルタイム更新を要するため大規模な検索クラスター運用という難題を抱える）。
描かれたマップは「LLM プラットフォームはモデルプロバイダーから分離する」「各モデルプロバイダーと個別交渉せず、プラットフォームとライセンス契約を結べばモデルにアクセスできる」「RAG 以外の機能のほとんどがバンドル型プラットフォームへ移行する」という想定で描かれている。現在この領域には潤沢な投資が行われており、エコシステムが淘汰されて1つの形に収まるまでは、考え得るあらゆる組み合わせがある程度は存在することになるだろう、と著者は見る。
このモデルは、LLM を事業側のユースケース（ドライバーのオンボーディングとリテンション）に適用した場合の効果を検証する。スケッチでは、ある都市のドライバーのライフサイクルを7つのストック（City Population＝都市の総人口、Applied Drivers＝応募者、Eligible Drivers＝資格基準を満たした応募者、Onboarded Drivers＝オンボーディング完了者、Active Drivers＝実際に運行中、Departed Drivers＝自ら運行を停止した離脱者、Suspended Drivers＝強制的に運行を停止された者）で表現する。応募→資格化→オンボーディング→アクティブという左から右への流れに加え、不足情報の請求（資格化できず差し戻し）、再エンゲージメント（離脱者の復帰）、利用停止解除（停止者の復帰）という例外フローを含む。
著者は lethain/systems で具体的にモデルを実装する。都市人口10,000人を初期値に、各ラウンドで都市内の100人がドライバーに応募し、応募者の25%が有資格に、有資格者の25%がオンボーディング完了に、その50%がアクティブになるといった流れを Leak（変換されなかった残りは消滅する）で記述する。離脱率・停止率や、離脱者・停止者からの復帰率も設定する。著者はここで、各ラウンドで残りが消滅する Leak と、残りがストックに残る Conversion の挙動の違いにも注意を促す。
モデルの検証から得られる発見は明快だ。応募者を有資格にする速度を2倍にしても（オンボーディングを迅速化しても）、長期的なアクティブドライバー数にはほとんど影響しない。不足情報の請求エラーを完全に排除しても同様に効果は小さい。一方、離脱ドライバーの再活性化率を5%から20%に、停止ドライバーの再活性化率を1%から2.5%に上げると、初めて大きな変化が現れる。とくに「離脱と停止の両方」の復帰率を同時に上げると、片方だけより遥かに効果が大きい。つまり、新規獲得の高速化ではなく、既存ドライバー（離脱者・停止者）の再活性化に注力すべきだという、見かけよりも重要な結論が導かれる。
これらの戦略が書かれた2024年当時、LLM 導入への期待は至る所にあふれていたが、LLM が今後どう進化するかは誰にも分からず、十分な経験を持つチームやリーダーもごくわずかしかいなかった。それでも業界からは可能な限り迅速かつ広範に導入せよという猛烈な圧力がかかっていた。
本章のドキュメントが示すのは、緊急性と不確実性という両立しがたい困難な状況にあっても、戦略、とりわけそれを洗練するプロセスが、リーダーを支え前に進むための確かな道筋を見いだす助けになるということだ。とくにシステムモデルは、「LLM を使えば速くなる/増える」といった直感的な期待が本当に成り立つのかを検証で突き崩し、努力を最も効く一点（開発ではエラー削減と速度改善の両立、事業では既存ドライバーの再活性化）へ向け直す役割を果たす。