20260914 AIエージェント時代のPlatform Engineering LLM基盤とプロダクトの責務境界線

Transcript

1. 2026/09/14 AIエージェント時代のPlatform Engineering LLM基盤とプロダクトの責務境界線 ドメインは任せ、統制を担い、評価を共創する。 株式会社ログラス 神﨑 太貴
2. ⾃⼰紹介 神﨑 太貴 Taiki Kanzaki 株式会社ログラス エンジニア（AI基盤担当） 早稲⽥⼤学を卒業後、新卒で野村総合研究所に⼊社。⼩売‧⾷品‧商社‧不動産など、東証プライム上場企業を 中⼼として、11年間で12件の基幹システム構築プロジェクト担当。性能改善や中規模のチームマネジメント、 ⼤規模開発における⽅式設計‧標準化を経て、アーキテクトとして、組織横断の共通化を推進。 2025年8⽉に株式会社ログラスへ参画。⽣成AIを取り込んだシステム基盤の R&D を担当し、コンテキスト管理 の技術検証を経て、全社共通の LLM基盤をゼロから⽴ち上げ。本番稼働後も、プロダクトの要求に合わせて責務 の線を引き直しながら増改築を続けている。並⾏して経営管理プロダクトの AI エージェント実装にも携わる。 本⽇は、プラットフォームとプロダクトの両側に⽴って⾒えた、8ヶ⽉の責務分解の話をします。 © 2026 Loglass Inc. 2
3. 目次 01 LLMアプリケーションにおけるプラットフォームの現在地 02 境界線の変遷：広げて、ぶつかる 03 守りと攻めのプラットフォームへ 04 プロダクトに、何をもたらしたか 05 まとめ：境界は動く前提で考える © 2026 Loglass Inc. 3
4. 01．LLMアプリケーションにおける プラットフォームの現在地 © 2026 Loglass Inc. 4
5. 01｜前提 LLMアプリにも「共通の部分」はある。従来の横断関⼼事の上に、LLM固有の層がもう⼀枚乗る プロダクト A プロダクト B プロダクト C 本⽇の話 ＝ プロダクト基盤と LLM基盤の責務分解 LLM基盤層 プロバイダキー管理 ∕ メータリングと予算制御 ∕ コンテンツセーフティ ∕ プロンプト‧出⼒‧ツール呼び出しのトレース プロダクト基盤層 認証‧認可 ∕ レート制限 ∕ ロギング‧監査 ∕ 課⾦‧請求 インフラ層 （本⽇のスコープ外） ※ このうち「プロンプト‧出⼒‧ツール呼び出しのトレース」が、このあとの話の中⼼になります。 © 2026 Loglass Inc. 5
6. 01｜不都合な真実 「全部プロダクトで独⾃に作る」は、いま⼀定成り⽴ってしまう プロダクト A プロダクト B プロダクト C 独⾃実装 独⾃実装 独⾃実装 LLM基盤層 ⸺ 本来はプロダクト横断で1つ。それが製品ごとに重複する プロダクト基盤層 認証‧認可 ∕ レート制限 ∕ ロギング‧監査 ∕ 課⾦‧請求 インフラ層 （本⽇のスコープ外） 1週間で書ける。ただし「書ける」と「集約できる」は別問題。 集約は規模の関数で、コード⽣成速度の関数ではない © 2026 Loglass Inc. 6
7. 01｜プラットフォームの出番 差別化に効かないものほど、後回しになる。そこを基盤が持てば、プロダクトを引き上げられる ↑ 差別化に効くか（＝開発の優先度） 効く プロダクトが作る いずれ基盤へ落ちる ‧ドメイン知識をもったプロンプト ‧LLM 特有のメモリー機能 ‧決定論的なロジック ‧Temporal 等の途中再開機構 通ると、 何が⼿に⼊るか • Eval の⼟台（トレース‧評価データ） 効か ない 投資しない 基盤化する ‧モデル開発 ‧ガバナンス：予算‧レート制限‧監査 ‧コンテキストのコンパクション ‧LLM o11y：トレースと評価データ ‧FW が持つチェックポイント機構 ‧製品ごとに持つと N 回払い • テナント別のコスト按分 • 設定ゼロ。baseURL 差し替えだけ Eval が無くても 60点 は作れる。80点 へ⾏くのに要 る。守らせるのではなく、引き上げる。 （点数は体感の⽬安。定量指標ではない） 製品固有 横断的関⼼事か → 横断共通 レート制限なしで本番に出て、請求額が跳ね上がった ⸺ こうして落ちる。 ※ Audit ログ管理‧認証‧共通通知基盤も、同じ象限から基盤化されてきた（横断的関⼼事∕Team Topologies の Platform team）。 ※ ⼀般の o11y は Datadog で解決済み。LLM o11y はプロンプトを扱うため、同じ基盤には相乗りできない。 ただし、従来の領域と違い LLM ではこの線引きがまだ定まっていない。 どこまでがプラットフォームで、どこからがプロダクトか ⸺ それが今⽇の主題 © 2026 Loglass Inc. 7
8. 02．境界線の変遷：広げて、ぶつかる © 2026 Loglass Inc. 8
9. 02｜題材 正しい分解点は、最初から分かるものではない。探りながら、8ヶ⽉で3つの形を通った プロダクト側 ① 2026年1⽉〜 ② 2026年4⽉〜7⽉ ③ 2026年8⽉〜 囲う LLM 呼び出しの統制だけを1サービスに閉じる 広げる 基盤と呼ばれるもの⼀式を、⼀度すべて作る 引き直す 統制点だけを基盤に残し、実⾏系を返す 画⾯‧ドメインロジック 画⾯‧ドメインロジック 画⾯‧ドメインロジック Agent 実⾏機能 Agent 実⾏機能（回帰） 製品固有 MCP サーバ（回帰） 責務分解点 LLM Gateway LLM Gateway LLM Gateway 汎⽤エージェント LLM基盤側 Eval基盤 MCP サーバの共通管理 MCP Gateway（設計中） コンテキストの共通管理 コンテキスト統制（模索中） Langfuse ⸺ 初⼿から、通ったリクエストが蓄積されている ⼊れ替え前提でサービスを分けていたから、作り替えられた。 LLM 固有の発明ではない。 LLM Gateway と Eval基盤は初⼿から不変 ⸺ 次は、この初⼿をどう考えて作ったか © 2026 Loglass Inc. 9
10. 02｜フェーズ1（2026年1⽉〜） 枯れた技術だけで組める統制点を初⼿に選んだ。だから8ヶ⽉、中核であり続けている なぜ初⼿に選んだか 何を持たせたか LLM Gateway 横断共通で、差別化に効かない どの製品も同じものが要る。独⾃に作っても差がつかない プロバイダ APIキー管理 キーを基盤に閉じ、プロダクトへ配らない レート制限‧予算制御 テナント別に上限を決めて制御する コンテンツセーフティ ⼊出⼒の検査を経路で強制する メータリング プロダクト∕テナント∕ユーザ単位でコスト帰属 トレース記録 Langfuse へ。Eval の⼟台になる 枯れた技術だけで組める HTTP プロキシ‧レート制限‧メータリング 必ず通る経路になる 経路に置けば、守られているかを検証できる ※ 現時点の対応プロバイダは Anthropic のみ。増やすときも、変える場所はここ1点に閉じている。 広げても畳んでも、ここだけは作り直していない ⸺ 8ヶ⽉を通じて、LLM基盤の中核であり続けている © 2026 Loglass Inc. 10
11. 02｜フェーズ2（2026年4⽉〜7⽉） LLM基盤として思いつくものを、⼀度そろえにいった。Agent‧Tool‧Context の3軸 Agent Tool Context 汎⽤エージェント MCP サーバの共通管理 コンテキストの共通管理 特化型の Sub Agent 群を基盤が提供し、プロダクト側 プロダクト API を LLM ツールとして公開する MCP どのデータをどう参照するかのカタログを基盤に置く の Main Agent が呼ぶ サーバを基盤が開発‧運⽤ 実利⽤がなければ正しさは検証できない。だから基盤側の⼈間がプロダクト側に⼊って作った ⸺ 3⽅向とも同じ道を辿った。 境界が曖昧なうちは、越境して両側を⾒るしかない ⸺ この⽴ち位置が、次の気づきにつながる © 2026 Loglass Inc. 11
12. 02｜フェーズ2で踏んだ失敗 広げた先で分かったのは、技術がまだ枯れていないことと、所有権が向こうにあること ① 汎⽤エージェント（A2A 構想） ② MCP サーバの共通管理 やろうとしたこと やろうとしたこと 基盤が特化型 Sub Agent を提供し、プロダクトが呼ぶ⼆層構造 プロダクト API を MCP サーバとして基盤が開発‧運⽤ 起きたこと 起きたこと 24⽇で撤回。⾮同期統制（再起動耐性‧承認待ち‧状態同期）の技術が、まだ枯 5週間で15回の追従同期。粒度と形状の判断⾃体が、プロダクトのドメイン知識 れていなかった。 を要した。 分散は、技術が枯れてから プロダクトのケイデンスに従属する成果物は持てない 畳んだのは需要ではなく、技術と所有権の判断。機能は枯れた構成で提供し続けた ⸺ No は剥奪ではなく置換。 3つ⽬の Context は、いまも模索中。 これは我々固有の失敗ではない。どの会社の「共通基盤チーム」も⼀度は通る道 ⸺ ここから、線を引き直す © 2026 Loglass Inc. 12
13. 03．守りと攻めのプラットフォームへ © 2026 Loglass Inc. 13
14. 03｜フェーズ3：責務境界の再定義（2026年8⽉〜） 返すだけでは、負荷は増え続け Eval も散る。だから統制点を残す 広げたものは汎⽤にならず、実装は返す。 ただし、返すだけでは解けないことが2つある。 ※ この章で稼働しているのは LLM Gateway と Eval基盤。MCP Gateway は設計中、コンテキスト統制は模索中。 エージェント実⾏機能（プロダクト側） 呼び出し元 Eval基盤 MCP Gateway ⸺ 認可‧監査‧カタログ統制を、必ず通る1点に LLM基盤側 （Langfuse） Tool の記録が1か所に MCP サーバ 実態のサービス MCP MCP プロダクト A MCP プロダクト B MCP MCP MCP プロダクト C 外部 MCP 外部サービス MCP サーバは連携先の数だけ増える。通す点を残さなければ、追従も Eval の分散も解けない 実装はプロダクトへ返し、経路だけを基盤に残す。 ⸺ 返すのは所有権であって、統制ではない © 2026 Loglass Inc. 14
15. 03｜いまの責務分解 ドメインはプロダクト。基盤は「守り」と「攻め」の2軸で持つ エージェント実⾏機能（プロダクト側） プロダクト LLM基盤 ① 統制（守り） LLM Gateway MCP Gateway Agent の LLM 呼び出しを⼀本化 Tool の MCP 呼び出しを⼀本化 → プロバイダ（現時点は Anthropic のみ） → 各 MCP サーバ（⾃社‧外部） Langfuse ⸺ 2つの経路を traceparent で1本のトレースに繋ぐ LLM基盤 ② Eval（攻め） 何を考え、どのツールを叩き、いくらかかったかが1件で追える ① 統制 ＝ 守り ⸺ 予算‧安全性‧キーを必ず通る経路に寄せる。事故を⽌める ② Eval基盤 ＝ 攻め ⸺ 通れば記録が残る。品質を上げる 統制はライブラリではなく、必ず通る経路に置く。 ⸺ 検証できない強制は、強制ではない ※ ②の⾃動連携は LLM 経路では稼働中、MCP 経路はこれから。MCP Gateway は設計中、コンテキスト統制は模索中で、この図はまだ完成形ではない。 © 2026 Loglass Inc. 15
16. 04．プロダクトに、何をもたらしたか © 2026 Loglass Inc. 16
17. 04｜プロダクトが乗る理由 プロダクトが乗るのは、守りのため。使い続けると、攻めまで⼿に⼊っている 守りのために乗る 予算‧安全性‧キーを⾃前で作らない 安全弁が ⼿に⼊る レート制限‧予算‧コンテンツセーフティ 使うほど実績が溜まる 通るだけでトレースが貯まる 攻めまで ⼿に⼊っている Eval が回り、60点の壁へ挑める ただし素通しでは、この鎖が切れる ⸺ 3つの⼿当てで繋いでいる ① ⽂脈が消える 呼び出し元の span_id を baggage で運ぶ ② 繋ぎすぎて壊れる ライフサイクルが独⽴する処理は Span Link ③ 失敗が黙る 送信前に型を正規化した（開発環境で約1週間、観測が全件⽋けた）。⽋損の検知⾃体は宿題 守りのつもりで乗ると、攻めまで付いてくる。 ⸺ だからプロダクトは、基盤に乗る © 2026 Loglass Inc. 17
18. 04｜Eval基盤への接続 幹はプロダクト、枝葉は基盤。評価だけは Eval基盤の上で共創する プロダクトが持つ LLM基盤が持つ プロダクトと基盤で共創 ①幹 ② 枝葉 ③ 評価 ターンとノードをアプリ層で張る Gateway を通れば無条件で残る 基盤は器と素材を出し、基準は⼀緒に決める 責務分解点 Langfuse で記録‧プロンプト管理‧評価を⽀える 1件のトレースの形 • ターン（ユーザの1往復） Langfuse（Eval基盤） • ノード：計画 ‧トレース＋セッション：1往復を1本に ◆ LLM 呼び出し ‧プロンプト管理：⽣成した版が⾃動で紐づく ‧評価スコア：rubric と judge の結果 • ノード：実⾏ ◆ ツール呼び出し（MCP） ◆ LLM 呼び出し 素材は預かる。判断は預からない。⸺ この線引き⾃体が、責務分解点の実例 © 2026 Loglass Inc. 18
19. 04｜守りの事例：3つのガードレール ⾃前でも作れる。作らずに済むのが価値。経路に置けば、3つとも標準で効く コストリミット プロダクト‧テナント単位で上限を決め、超えたら⽌める。⻘天井にならない 守りの対価 2.3ms 冪等性担保 リトライしても、⼆度払わない‧⼆度実⾏しない 内訳：レート制限 1.3ms∕冪等性 0.8ms∕セーフティ 0.2ms （p50）。 コンテンツセーフティ Gateway を1ホップ挟むこと⾃体は別途 p50 16ms‧平均 ⼊出⼒を経路で検査し、利⽤ポリシー違反を⽌める。不要なアカウント停⽌を避ける 43ms。 ソリューションはどれも従来どおり。 ⸺ LLM基盤の違いが出るのは、この先 ※ 同じ経路から、レイテンシとエラー率も取れる（スコアは⾼いのにユーザ評価が低い1件を、154秒のレイテンシと切り分けられた）。 © 2026 Loglass Inc. 19
20. 04｜攻めの事例：60点の壁を越える 観測できて初めて、60点の壁を越えられる。地道だから、アプリでは優先度が上がらない ① 基準を決める ② 使う rubric と期待仕様。Git 正‧PR 必須 本番トレースが貯まる 実⾏結果から、観測できるようになること プロンプトの評価 版を変えて、出⼒がどう変わったか 実⾏結果は貯まる。 Tool の実⾏回数 基準は⼈が書く 呼びすぎが⾒え、実際にツールを統廃合した ④ 戻す ③ 採点する Tool ごとの精度 スコアを Langfuse へ。版を刻む そのトレースを基準に照らす どのツールが外しているかが分かる ※ 基準（シナリオ‧rubric）は⼈が書き、PR でレビューする。ここまでの成果はツール統廃合の1件で、スコアの継続改善はこれから。 上がらない優先度を、基盤が引き受ける。 ⸺ 統制は事故を⽌め、Eval は品質を上げる © 2026 Loglass Inc. 20
21. 05．まとめ：境界は動く前提で考える © 2026 Loglass Inc. 21
22. 05｜今⽇の線 ドメインは任せ、統制を担い、評価を共創する。ただしこれは、3つ⽬の形にすぎない 今⽇⽰した線 8ヶ⽉で通った3つの形 ① ドメインはプロダクトに残す ① 囲う 差別化に効く判断は渡さない LLM 呼び出しの統制だけを1サービスに閉じる ② 統制を担い、守りで載せる ② 広げる プロダクトが欲しいのは安全弁。従来の統制がそのまま効く 基盤と呼ばれるもの⼀式を、⼀度すべて作る ③ 攻めの⼟壌を出し、評価を共創する ⼀緒に回して、60点の壁を越えていく ③ 引き直す いまここ 統制点だけ残し、実⾏系をプロダクトへ返す いま⽴っているのは、3つ⽬の線。 ⸺ 8ヶ⽉で3回動いた。次も動く © 2026 Loglass Inc. 22
23. 05｜なぜ変化を受け⼊れられたか 変化を受け⼊れられたのは、従来⼿法の延⻑にいたから。LLM基盤は、新しい発明ではない 不確実な領域ほど、枯れた⼿法の上に組む loose coupling gateway pattern control / data plane • ⼊れ替え前提の最⼩粒度で分ける • 横断関⼼事を経路に寄せる • 契約で統制し、実装には踏み込まない • → 今⽇：8ヶ⽉で3回作り替えられた • → 今⽇：LLM Gateway と MCP Gateway • → 今⽇：traceparent の伝搬契約と共有パッケー ジ 変わったのは価値の源泉 ⸺ 攻めの Eval データと、守りの統制点を預かる ※ 「コードを配って構築時間を節約する」価値は AI によって減価した。だから実⾏基盤を⼿放せた。 © 2026 Loglass Inc. 23
24. 05｜クロージング ベストプラクティスは、まだ誰も持っていない。だから、越境して⾒つけにいく 宿題も残る（MCP Gateway‧コンテキスト統制‧契約の検証可能性）⸺ いままさに、再分解の途中です。 まだ過渡期。 不確定要素が多い だから、従来⼿法をフルに使う。 変化に強い形で組む それでも⾒極めきれない。 だから、越境しよう ベストプラクティスは、これから作られる。 ⸺ 同じ問題意識の⽅、ぜひ⼀緒に。 © 2026 Loglass Inc. 24
25. 06｜We are hiring！ ログラスではAI基盤エンジニアを募集中です！ 少しでも興味がある⽅はぜひ懇親会でお話しさせてください！ © 2026 Loglass Inc. 25