© LayerX Inc. サービス開発で LLMをどうやって履きこ なすか Fintech事業部 (三井物産デジタル・アセットマネジメント） CPO / CTO 三津澤 サルバドール 将司 Masashi SALVADOR Mitsuzawa DAY01 topic ツールの選択 Speaker 

© LayerX Inc. Speaker Fintech事業部(三井物産デジタル‧アセットマネジメント） CPO / CTO ⽇本SF作家クラブ 会員 2018年8⽉ - 株式会社LayerX 2021年4⽉ - 三井物産デジタル‧アセットマネジメント株式会社へ出向 個⼈向けの投資サービスALTERNAのサービス⽴ち上げと 全社のプロダクト開発の統括をしています 三津澤 サルバドール 将司 Masashi SALVADOR Mitsuzawa @MasashiSalvador 

© LayerX Inc. サービス開発の体制と⽬下の課題 サービス開発の体制 / ⽬下の課題 ● 証券/資産運⽤サービスの開発は専⾨性の重ね合わせで加速する ● Designer, Engineer, PdM, QA, Operation, CS, Marketing, Analyst ● ファンド組成担当, 商品開発担当,ファンド運⽤担当 ● コンプライアンス担当 ● それぞれIT / AI技術への習熟度は異なる ● 商品(証券）も仕様（ソフトウェア）がサービスの成⻑と共に多様化 ● 商品/仕様変更の影響範囲の考慮漏れによるインシデント増加 ● メンバー増加に伴い、知識にグラデーションが発⽣ 

© LayerX Inc. ⼈間は複雑さに気を使い続けることはできない ⼈間は複雑さに気を使い続けることはできない 証券としての商品性 販売時 / 運⽤中 販売ページ 運⽤パフォーマンスページ 各種キャンペーン × × 法定帳簿/法定書⾯ 証券オペレーション ソースコード/システム 影響範囲の把握や正しい仕様（もしくは実装）の把握が品質に直結する 

© LayerX Inc. とはいえ、複雑さに対して感度を⾼めることで防げる問題はある ⼈間は複雑さに気を使い続けることはできない：例 例：⾦融商品の⼿数料の考慮 とある商品から⼿数料の取り扱い⽅が変更された 画⾯上だけではなく、最終的に法定交付書⾯まで影響があった 販売側は対応していたが、買い取り側の対応が漏れていてインシデントに →売買の種別問わずソースコードが共通であることを知っている⼈が、漏らさず⾒れて いれば防げるといえば防げる →知っていること & （常に集中して）漏らさないことはLLMの得意分野では？ →誰でもLLMの助けを借りられるようにしたい使えるようにしたい 

© LayerX Inc. 仕様 / 影響範囲の把握: 使われやすさの条件はUIとアカウント 仕様や影響範囲の把握にLLMを利⽤する Notion AI + Slack, GitHub, Google Drive連携 ◯◯を⾏った際に△△がどうなるか教えて？ などの使い⽅ （例：⼀般⼝座への影響範囲） 実際に動作しているソースコード 商品の契約書等 企画書/仕様書/議事録/専⾨家レビュー 法令の条⽂ / 監督指針 

© LayerX Inc. ● Notionは全社員アカウントを保有し、UIにも慣れているので利⽤ハードル が低い ● レファレンスを⾒やすいUIなので、情報の整理の助けになる More コンテクストのコントロールが微妙に難しいので、範囲を限定するのが困難 

© LayerX Inc. 仕様 / 影響範囲の把握: Devin, Claude, Cursorも場合によって活⽤ 仕様や影響範囲の把握にLLMを利⽤する Devin / Cursor or Claude + MCP 変更に対する影響差分の把握やテスト観点の洗い出し ● DevinはGitHubアカウントがなくとも動く Wikiの図解も有⽤ ● Cursorはインデックスが優れているのとコンテキストのコントロールがしや すいので、より役に⽴つ回答を得やすい More ● Devinはシステム外のことを聞いても（情報がないので）回答ができない ● CursorはMCPサーバを設定すると本領発揮できるが、連携先(Notion等）の 権限制御が細かくできないと、利⽤を推進しづらい。UIもあくまでエディタ 

© LayerX Inc. 法定要件の調査:ドメイン知識の階段を上がるためにAIの靴を履く 法定要件の調査にLLMを利⽤：あくまで下調べ ChatGPT(o1-pro, o3-pro) Deep Research) / Notion AI 法務/税務の専⾨家に質問する前処理としてDeep Research等を利⽤する ● 過去の専⾨家レビューのログ ● 3年分の議論の議事録 ● ある程度整理された論点 ● 根拠となっている法令や監督指針などを網羅的に調べてレファレンス化 ● 監査の観点など、⽴場が違う者の視点から論点を洗い出し ● 80点ぐらいの回答は返ってくる ● 論点が洗い出されることにより、的ハズレな議論を避けやすくなる More ● 問い合わせを複数回に分けたりなど、能動的な利⽤は必須 

© LayerX Inc. お悩み お悩み ● 課題の⾃⼰解決が増えるのは嬉しいのだが、LLM ↔ 個々⼈の間で解決してしまうと、コミュ ニケーションとして顕在化しないので知⾒がたまらないといえばたまらない ● 活⽤開始 → 組織としての運⽤のギャップはそこそこにある ○ 活⽤開始フェーズで成果が出ないと機運はしぼむ ■ 切り込み隊⻑的な個⼈がガツガツ進める ■ UIやアカウントや設定の⾯でよりとっつきやすいものを選ぶ ○ 運⽤⾯では、リソースの置き場やツールの使い⽅、プロンプトなどを組織的に決めてい かないといけない？（まだ試⾏錯誤中） ■ 全社ではGPTsなどでツールが共有されている ● ⾃然⾔語で問い合わせできることは、考えやすさに直結しない ○ 分析など（もしかしたら問い合わせも） ○ そもそも分析⼿順を⾃然⾔語で書き下すことそれ⾃体が分析になっている ○ ⼿軽さを実現するか、深さを実現するかでやるべきことは違う 

© LayerX Inc. 気軽に試し、テキストに意志を込めるのは⼈の役割 最後に ● LLMもLLMを利⽤したアプリケーションも⽇々進化しているので、（誰でも）気軽に試せるよ うにすることが⼤事 ● 出⼒結果はあくまでも出⼒結果であり、そこに意志はない（当然）、意志を込めるのは⼈間 の役割。 ○ 例えば、AIが書き起こした/要約した議事録は有⽤だが、そのままコミュニケーションに 利⽤しても意志は乗らない ■ テキストにこもった意志をどうドキュメントに残すかが、今後のLLMの履きこなし の鍵だと（個⼈的には）感じている