AIエージェント時代のPlatform as a Product —— テックリードがPdMとして回す発見・導入・計測 / Platform as a Product in the AI Agent Era

Platform Engineering Kaigi 2026の登壇資料です。

https://www.cnia.io/pek2026/
https://www.cnia.io/pek2026/sessions/0e00df55-55c3-4e95-b995-e2b8e1c77182/

Transcript

1. AIエージェント時代の Platform as a Product テックリードがPdMとして回す発⾒‧導⼊‧計測 杉⽥寿憲（toshi0607） 株式会社LegalOn Technologies Platform Engineering Kaigi 2026 1
2. 知っていたはずのPlatform as a Product 典型的な課題に典型的な解決策を提供した 課題 機能 告知 ✕ 利⽤ • 課題: マージ前に実環境に近い条件で検証したい • 機能: プレビュー環境とmirrordを⽤意した • 告知: リリース時の利⽤チームからの反応もよかった しかし、⽇々の開発での利⽤は増えなかった 2
3. 話し⼿の⽴ち位置 Director of Platform Engineering Platform Tech Lead 2023年4⽉から Akupara（アクパーラ）の ⽴ち上げと開発 PdM テックリードを続けながら 2026年4⽉から明⽰的に担当 WorkOnの開発 にも参画 HR系プロダクト「WorkOn」の開発に⼊り、プラットフォームの利⽤者の開発業務も⾃ら経験している 3
4. 複数プロダクトを⽀えるAkupara 構成と開発体制が異なるプロダクトにゴールデンパスと共通インフラを提供する LegalOn WorkOn Akupara Plan Build DealOn ほかのプロダクト ゴールデンパスと共通インフラ Test Deploy Operate 開発ライフサイクルを認知負荷低く回す 4
5. 事業課題の解決を⽀えるプラットフォーム ⼤きな「プロジェクト」から課題を選び成果を確かめるフェーズへ プロジェクトとして作る 課題を選び、成果を確かめる Phase 1 Phase 2 Phase 3 これから 「LegalOn」⽴ち上げ 2023〜2024年 USリージョン展開 2024〜2025年 開発ライフサイクル改善 2025〜2026年 AIエージェント時代の プラットフォーム 50以上の マイクロサービスの標準化 マルチプロダクト‧マルチ リージョンへの再設計 デプロイとフィードバック ループの⾼速化 課題を選び、 成果の有無を確かめる どの課題に投資し、それによってどんな成果が出たか評価する必要が⾼まった 5
6. AIエージェントで変わった2つのこと このフェーズの変化にAIエージェントが2つの変化を加えた 1．開発者の速いループ 2．Akuparaを使うAIエージェント • インフラを含む調査から実装‧検証まで、 開発者が進められる範囲が広がった • AIエージェント⾃⾝がAkuparaの情報、 ツール、実⾏環境の利⽤者になった • 個々の施策を速く進められる 作業の⽂脈から⾒つけられなければ選ばれない 6
7. PdMを担うと宣⾔した4⽉ 宣⾔の⼀部 ⽅針 Achievement プラットフォームの原則 開発者に加え、 AIエージェントもAkuparaの ユーザーとして扱う 開発ライフサイクルの場⾯ごとに 半期で到達したい状態 • 要望ではなく 困りごとから考える A1 ⽴ち上げ • 使われて初めて完了とする A2 ⽇常の変更 事例3 A3 マージ前の検証 事例2 • アウトカムに つながったかを⾒届ける A4 ガードレール A5 運⽤ 事例1 7
8. 判断を1つのループで回す テックリードの判断に3つを加えて1つのループで回す 3つの判断がそろうとループが回り続ける Release Outcome 以前から: どう作るか∕安全に運⽤できるか∕技術的に完成したか Discovery Measurement Delivery Enablement 1 誰のどの課題を解くか 2 ⽇々の作業で選ばれ、使い切れるか 3 何を計測して次の投資分野を決めるか Discovery Delivery、Enablement Measurement どれかが⽋けるとループは途中で⽌まる 8
9. 施策を組織の⽬標まで接続 個々の施策が最後に全社の何をよくするのかをつなげて示す 全社で測り始めた品質‧コスト‧納期 Akuparaの提供価値 Achievement（半期の⽬標）と 評価指標 個々の施策 品質: ISO/IEC 25010の品質特性 コスト: AIエージェントのトークン費⽤も含む 企画からリリースまでの待ち時間 納期: 得られる品質の⽔準（信頼性‧セキュリティ‧性能などの品質特性）∕到達する速さと 負担（変更のリードタイムや変更品質と、待ち時間や認知負荷） 開発ライフサイクルの場⾯ごとに到達したい状態 例: Akupara MCP、プレビュー環境、mirrord 9
10. 最初の仮説は独⾃オーケストレーター 事例1: A5（運⽤）のDiscovery ─「誰のどの課題を解くか」 運⽤のAchievement: 問題の検知から原因特定‧修正‧再検証までを例外時以外はAIエージェントが完結できる状態 困りごとの仮説 提供すべきものの仮説 • 本番への⾃動デプロイが監査要件を満たせるか • 決めた⼿順どおりに切り戻せる仕組み • 機密性の⾼い情報をAIエージェントに渡せるか • 運⽤のシナリオを実⾏するエンジン • アラートの⼀次仕分けの共通化 想定した流れ（共通のオーケストレーターとして提供） アラートや 問い合わせ AIエージェント が調査 修正PRを 作成 ⼈が判断 10
11. 実際の運⽤を4チームに聞いた 要望ではなく実際の作業、制約、失敗、判断の境界を聞いた 1．起点 3．対応の流れ 4．AIに任せる範囲 5．判断点 調査 対応 判断 2．⼊⼒になるシグナル 検知 6．権限とデータの制約 7．成功指標 運⽤の⾃動化を進めていた4チームに共通の7つの軸で聞く 11
12. 流れは同じでも中⾝は違った 表⾯的には「検知から修正まで」という共通の流れがあった ⽐較項⽬ チームごとの差 起点 週次の定期実⾏、画⾯からのissue report、監視のアラート、エラー通知 実装済みの範囲 起票まで全⾃動、修正PRまで3エージェントで直列、PR提案を検証中、原因候補の投稿まで 実⾏⽅式 個⼈のローカル実⾏、ワークフロー製品とエージェント製品の組み合わせ、複数の⽅式を並⾏ して検証 ⼈が判断する境界 起票後の確認と優先度付け、原因のチェックとPRレビュー、PRを出すかの判断、アラートの ミュートやDBの修正やマージ 共通のオーケストレーターを⽤意しても、制約の違うプロダクトごとの運⽤実態に合わず、最悪の場合は使われない 12
13. 作る‧⽀える‧買う 誰が運⽤し続けるかまで含めて⽐べた 選択肢 メリット コスト 作る ⼀貫した制御と統合 オーケストレーターの開発‧運⽤ ⽀える 各チームの⽅式を残せる 共通部品と境界の設計 買う 早期に試せる機能 製品制約と接続⽅法の評価 結論: 「⽀える」と「買う」を組み合わせる 13
14. オーケストレーターを⾒送る インタビューで⾒つかった共通の制約から共通で⽀える部品を決めた インタビューで⾒つかった共通の制約 共通で⽀える部品 クレデンシャルが各所に散らばり、払い出しの申請も⾯倒 スコープを絞った認証情報と権限 CI上のエージェントにMCPの権限を渡せず、個⼈のローカル実⾏に留まる 安全な実⾏環境と監査 機密性の⾼いデータを含む本番ログをエージェントに渡せない データガバナンス 検知‧仕分け‧調査の結果の形式がチームごとに違い、 ほかのチームの仕組みにつなげない 結果を次の段へ渡すための共通の形式 調査の⼿順が⼈やリポジトリに散らばり、⾃動化の効果も測れていない 調査⼿順（Playbook）の共有と効果の計測 限られた開発⼒を繰り返し現れる制約に振り向ける 14
15. 実装と運⽤に関わってきたから 要望を集めるだけでは評価できない境界 どのデータへアクセスするか どの操作を監査するか どの権限をどこで渡すか 例: CI上のエージェントにトークンを渡せない どこで⼈の承認が必要か 例: 誤った診断による修正が約1週間後に再発 共通化できる処理と各プロダクトに残すべき判断を分ける 15
16. 次の検証条件まで決める 判断は⾒直す条件まで決めて完了する PoC対象: 運⽤の⾃動化を試しているチームのうち、協⼒意思とアラートや問い合わせの量で選んだ Decision Experiment 1つのプロダクトの1つの運⽤シナリオを 共通部品とマネージドサービスで最後まで回す • 共通部品で実際の運⽤を⽀えられるか • ⼈が判断する境界を守れるか • 継続利⽤できるか • ⾜りない部分を内製する条件は何か Revisit Evidence 16
17. マージ前検証の2つの⼿段 事例2: A3（マージ前の検証）のEnablement ─「⽇々の作業で選ばれ、使い切れるか」 ローカル開発 mirrord ローカルの変更を GKE上のサービスと 接続して検証 PR プレビュー環境 PR単位の環境で 変更を検証 マージ デプロイ後 ここで初めて分かる 問題を減らしたい コーディングが速くなるほど実環境に近いフィードバックまでの時間がボトルネックになる 17
18. 反応を利⽤の予兆だと思った 「需要はある」という理解だけでは使われない原因を特定できなかった β版の提供から約6週間後に聞こえてきた声 リリース時の反応 40+ 13 告知へのスタンプ 返信 「⻑年欲しかった機能」という声も 「様⼦⾒」 「mirrordは使っていない」 「セットアップ済みだが、 ユースケースを思いつかない」 18
19. ⾃分も検証⼿段を選べなかった WorkOnの開発に⼀エンジニアとして参加した いつもの流れ AIと ローカル開発 動作確認 レビュー PRレビュー への対応 マージ デプロイ QA mirrordもプレビュー環境も、この流れのどこにも出てこなかった 知っていたし、セットアップ⽤のskillも設置済み。それでも流れを回すだけで⼿⼀杯で選択肢に上がらなかった 明⽰的に「mirrordを使って」と指⽰したとき クエリの変更をmirrordでdevのDBにつないでマージ前に確かめられた 19
20. skillは必要な場⾯で⾒つからない リポジトリに置くだけでは必要な瞬間に参照されるとは限らない ⼈ AIエージェント 過去の説明やチーム内の会話から ツールを思い出せる ≠ 作業中に与えられた指⽰と 参照できる⽂脈から選択肢を決める 1つの作業の中でエージェントが検証⼿段を選ぶまで 存在する ⾒つかる 選ぶ 成功する 標準の開発フローの中で⾃然に⾒つかり、実⾏される設計が必要 20
21. 「使われる」を5つの状態に チームが使い続けるまでを5つの状態に分ける 責任者の賛成 認知を広げる⼒ 認知 開始 初回成功 継続利⽤ 開発成果 • 賛成してくれていても、開発者が知っているとは限らない • 知っている ≠ 試す ≠ 固有のエラーを越えて成功する ≠ 次の変更でも使う • 利⽤回数が増える ≠ ⼿戻りやリードタイムが改善する 脱落率は実測していないため、数値は付けない 21
22. 告知を増やす仕事ではない ⽌まった場所ごとに⽀援を変える 段階 ⽀援 実際にやったこと 認知 具体的な利⽤場⾯を届ける 各チームへの紹介と、チームに合わせた使い⽅の 説明 開始 標準的な作業から起動できる⼊⼝を作る PRにラベルを付けるだけで起動 初回成功 プロダクト固有のエラーを解消する 初回のエラーへの対応 継続利⽤ プロダクトごとの開発⽅針と接続する プロダクトの開発⽅針との接続 開発成果 利⽤前後の作業⼯程やメトリクスを⽐較する 利⽤者数の推移の可視化 それでも利⽤者の増加や最終的な成果にはまだつながっていない 22
23. プロダクトの⽬標から話す 継続利⽤のために会話の始め⽅を変えた 施策を売り込む会話 ⽬指す会話 「Akuparaの⽬標を達成したいので、 この機能を試してください」 「今期⼒を⼊れている施策に ちょうどリリースしたしくみが役⽴ちそうです」 例: WorkOn 6⽉ 8⽉初め 8⽉末 ⽅針に「プレビュー環境をすぐ 使える状態に」 「良さそう止まり」 （実はエラーで使えず） フィードバックをすぐ直し、 利⽤が増えはじめる 23
24. 分かったことと検証中のこと 未確定の成果を成功として語らず次の判断に必要な証拠を集める 分かったこと まだ分からないこと • 認知、初回エラー、使いどころ、継続利⽤は 別々の課題 • 継続利⽤が増えていない原因 • ⼿戻りや開発時間がどれだけ減ったか • 開発に参加すると提供側から⾒えない失敗が 分かる • ⼈とAIエージェントでは発⾒可能性の設計が 異なる 24
25. 問い合わせの裏に残る⼿戻り 事例3: A2（⽇常の変更）のMeasurement ─「何を計測して次の投資分野を決めるか」 ⽇常の変更のAchievement: アプリとインフラをまたぐ変更を、AIエージェントが必要な情報を得て漏れなく進められる状態 問い合わせの件数では⾒えない 変更漏れの⼿戻りが残る ⽉に約15件 appとinfraのリポジトリが分かれていて、必要 な変更が漏れる 2026年8⽉時点、SREへの問い合わせ全体 ほとんどはアプリとインフラをまたぐ変更とは別の内容 A2の指標: 問い合わせの件数 →「変更漏れによる追加のPRなしで完了できた割合」 Akupara MCP（β版） アプリの差分 インフラへの影響を確認 必要な変更と次の⾏動を返す 例: Pub/Sub subscriber、環境変数、Secret参照 25
26. 話を聞く相⼿を変更履歴で探した 具体的な変更を経験した⼈に話を聞く appとinfraの 変更履歴 両⽅にまたがる変更 Pub/Sub、worker、権限など 協⼒を依頼 6⽉ 8⽉ 変更履歴から8⼈を選んで依頼 （LegalOn 3⼈、WorkOn 3⼈、DealOn 2⼈） AIエージェントでappとinfraのPR履歴を分析 し、依頼の候補を広げた 依頼の経路: 直接の依頼、SRE & Platformの定例、WorkOnの全体定例、Slack 26
27. 配布不⾜だと考えた この仮説が正しければ案内とセットアップの改善が優先になる 事実 回答の中⾝ 最初の仮説 アンケートを配っても、回答が 少ない（8⽉上旬の時点で4件） MCPが呼ばれなかった回が多 い。呼ばれた回は「ほぼすべて 正しい」「そのまま作業に移れ る」 ‧存在を知らない ‧セットアップされていない まだ結論ではない（実測していない） 27
28. 段階ごとに計測した 利⽤を1つの数字にしない 段階 どの記録で⾒えるか 1. MCPを利⽤可能だったか セッションの記録（設定やツールの検索が⾒えたか） 2. 対象となる変更をしていたか セッションの記録（会話から変更の候補を推定） 3. 呼び出しを試みたか セッションの記録、サーバーの記録 4. 実⾏が成功したか サーバーの記録（拒否されたか） 5. 結果が次の⾏動に使われたか まだ測れていない 記録から確かめられない状態を未利⽤だとは決めつけない 28
29. 接続はされているが呼ばれていなかった 「セットアップされていない」という推定は外れていた 0.4% 8⽇間のセッション7,199件のうち、ツール の呼び出しは27件 接続はある ある利⽤者の⼿元の記録 0件 8⽉以降の355セッションで対象となる変 更の候補が124件。呼び出しの試⾏は12 件、実⾏を確認できたのは0件 対象の変更もある アンケート 0回 促す前にエージェントが ⾃分から呼んだ回数 サーバーの記録 呼ばれない 接続はされているが、対象の変更もあるのに呼ばれていない 29
30. 計測基盤にも限界があった 計測は判断に必要な問いに合わせて更新するもの 呼び出しの記録（audit log）の例 event tool decision tools/call （ツール名） allow caller 空 • 7⽉1⽇〜9⽉1⽇の306件すべてでcallerが⽋けていた • NATの内側なので、⼈単位に数えられない • HTTPがstatelessで、セッションの開始（initialize）と呼び出し（tools/call）を突き合わせられない ⾜した計測 9⽉3⽇: callerとcaller_source 9⽉4⽇: セッションの開始（クライアントの名前と版） 30
31. 計測で打ち⼿を変えた 接続は⼗分にされていたので、案内は増やさない いま進めていること 1．プラグインの形で配る 計測の前なら 進⾏中 MCPの設定と使う場⾯を書いたskillを社内のプラグイン配布で⼀緒に届ける 認知とセットアップの依頼を 増やしていた 2．ベンチマークで呼び出しの割合を上げる（設計中） 進⾏中 対象の変更の場⾯でエージェントがAkupara MCPを呼ぶかを繰り返し評価して チューニングする 最終的にA2では漏れのない変更完了割合まで追う 31
32. 判断を前へ戻した 3つの事例は別々の成功談ではない 事例 試された判断 得た事実 戻した判断 運⽤⾃律化（A5） 誰のどの課題を解くか チームごとに既存実装と任せたい範囲 が違う 共通で作る範囲 検証環境（A3） ⽇々の作業で選ばれ、使い切れ るか 機能やskillがあっても⽇々の作業で選ば ⼊⼝と利⽤⽀援 れない Akupara MCP（A2） 何を計測して次の投資分野を決 めるか 起動済みでも必要な場⾯での利⽤は別 計測と改善の優先順位 AIエージェントという利⽤者に対し、いま試している答えの⽅向 エージェントが作業の中で読む場所に置き、呼ばれたかを計測しながら直す 32
33. 4⽉の原則を事例で振り返る 4⽉に掲げた原則は事例を通して具体的な中⾝を持った 4⽉に掲げた原則 事例で分かったこと 要望ではなく困りごとから考える 聞いた結果、作ろうとしていたオーケストレーターを⾒送った（事 例1） 使われて初めて完了とする 知ってもらう、初めて成功する、使い続けるは、それぞれ別に起き る（事例2） アウトカムにつながったかを⾒届け る 最初の計測では分からず、問いに合わせて計測を作り直した（事例 3） 33
34. プラットフォームを作る⼈が始められる 今⽇の事例で経験が役⽴った場⾯ 作り、運⽤してきた経験 共通化する技術境界を選ぶ 事例1 権限‧データ‧実⾏環境の制約を評価する 事例1 投資判断 ＋ ユーザー理解 （現場に⼊り、対話する） ⼈とAIエージェントの開発フローを⾃分で検証する 事例2 計測できる事実と、ログから推測できないことを区別する 事例3 ＋ 計測 34
35. 機能を1つ選んで始める 専任PdMがいないチームは1つの機能で発⾒から計測までを1周回す 始め⽅ 1 確かめる3つの問い 次に提供する機能を1つ選ぶ 2 利⽤チームの実際の作業を⾒る 3 実装前に継続投資の判断条件を決める 4 提供後に同じ作業をもう⼀度⾒る 5 判断と計測の時間を開発計画へ⼊れる 1 この施策は誰のどの作業を変えるのか 2 ⼈とAIエージェントは必要な場⾯で選 び、使い切れるか 3 次に何を直すかを決められる 情報があるか 35
36. 速いループを組織の成果へ 判断のループを担うことから プラットフォームのPdMは始められる 作った機能の数ではなく事実をもとに何を変えたかを積み重ねていく 36