マルチドライブアーキテクチャ: 複数の駆動力でプロダクトを前進させる

by Kenichi SUZUKI

Slide 1

Slide 1 text

マルチドライブアーキテクチャ：複数の駆動⼒でプロダクトを前進させる株式会社ログラス鈴⽊健⼀ CTO室⼩林達プロダクト基盤部アーキテクチャ Conference 2025

Slide 2

Slide 2 text

⾃⼰紹介鈴⽊健⼀（Kenichi Suzuki） X: @_knih 新卒でNTTデータに入社。ミッションクリティカルシステム・大規模基幹システムのアーキテクチャ設計や統括業務に従事した後、より堅牢な開発を求めて、プログラム言語理論（型システム、関数型等）を研究。  その後、Visionalにてサイバーセキュリティ事業の立ち上げからプロダクト開発をけん引した。ContractS株式会社にて開発部長、プロダクト部長、技術戦略室長、VP of Developmentを歴任。2023年ログラスへ入社。アーキテクチャConference 2024

Slide 3

Slide 3 text

複数の異なる変化速度を同時に扱うアーキテクチャをどう設計するか？

Slide 4

Slide 4 text

本⽇のお品書き前半 ● 速度差が摩擦を⽣むという問題 ● マルチドライブアーキテクチャ後半 ● 事例1：リアーキテクチャ ● 事例2：共通基盤まとめ前半は概念に徹します後半で事例をお話します

Slide 5

Slide 5 text

板挟みになっていませんか？

Slide 6

Slide 6 text

板挟みになっていませんか？よくある板挟みちゃんと設計しないと！もっと速く、市場の変化に追いつきたい、顧客ニーズを満たしたい！正しいけど同時には満たせない AIに対応して！

Slide 7

Slide 7 text

板挟みになっていませんか？よくある板挟み板挟み状態短期（速く進めたい）中期（整えたい）⻑期（未来へ備えたい）

Slide 8

Slide 8 text

板挟みになっていませんか？事業変化によってアーキテクチャが限界になるリスク異なる要求を同時に扱う必要性に迫られた短期戦略中期戦略⻑期構想共通基盤等の標準化の要求競争優位の核をつくる戦略的昇華既存アーキテクチャが限界になるリスク既存プロダクトの価値強化

Slide 9

Slide 9 text

正体は異なる時間軸

Slide 10

Slide 10 text

異なる時間軸を扱うマルチドライブアーキテクチャ

Slide 11

Slide 11 text

それぞれ異なる時間軸で動いている

Slide 12

Slide 12 text

異なる時間軸を扱うマルチドライブアーキテクチャ異なる時間のスケール関⼼事によって時間のスケールが異なる ⋯ ⋯ 短期中期⻑期（2〜5年）（3ヶ⽉〜2年）（数週〜3カ⽉）

Slide 13

Slide 13 text

異なる時間軸を扱うマルチドライブアーキテクチャ Anthonyの経営管理の3階層異なる時間軸で動く3階層戦略計画（Strategic）管理統制（Management）業務統制（Operation） Anthony, R. N. (1965). Planning and Control Systems: A Framework for Analysis. Harvard Business School Press. Anthonyの3階層⻑期（数年）中期（四半期〜年）短期（⽇〜週〜⽉）時間軸関心事競争優位の構築組織の⽅向性効率的な資源配分戦略の実⾏保証⽇常業務の効率化タスクの遂⾏

Slide 14

Slide 14 text

異なる時間軸を扱うマルチドライブアーキテクチャ経営理論の3階層と、3つの駆動戦略計画（Strategic）管理統制（Management）業務統制（Operation）共通基盤等の標準化の要求競争優位の核をつくる戦略的昇華既存プロダクトの価値強化変化による要求（関心事の違い）アンソニーの 3階層異なる時間軸はどこから来るのか

Slide 15

Slide 15 text

異なる時間軸を扱うマルチドライブアーキテクチャ経営理論の3階層と、3つの駆動ビジョン駆動（V; Vision）イネーブルメント駆動（E; Enablement）オポチュニティ駆動（O; Opportunity）戦略計画（Strategic）管理統制（Management）業務統制（Operation）プロダクトの羅針盤競争優位の源泉開発効率の向上・強化ビジネス最前線の機会対応長期中期短期アンソニーの 3階層対応する駆動力各階層を駆動する力の源泉は？

Slide 16

Slide 16 text

異なる時間軸を扱うマルチドライブアーキテクチャ経営理論の3階層と、3つの駆動ビジョン駆動（V; Vision）イネーブルメント駆動（E; Enablement）オポチュニティ駆動（O; Opportunity）戦略計画（Strategic）管理統制（Management）業務統制（Operation）プロダクトの羅針盤競争優位の源泉開発効率の向上・強化ビジネス最前線の機会対応長期中期短期共通基盤等の標準化の要求競争優位の核をつくる戦略的昇華既存プロダクトの価値強化変化による要求（関心事の違い）アンソニーの 3階層対応する駆動力異なる時間軸と関⼼事を、互いに阻害せず並列に動かすため、駆動⼒で分離する

Slide 17

Slide 17 text

multi-drive ひとつの対象やシステムが、複数の独⽴した駆動源や原動⼒によって同時に動かされている状態。あるいは、複数のドライバーが独⽴して動くしくみ。

Slide 18

Slide 18 text

異なる時間軸を扱うマルチドライブアーキテクチャマルチドライブ、3つの駆動ビジョン駆動（V; Vision）イネーブルメント駆動（E; Enablement）オポチュニティ駆動（O; Opportunity）未来への道筋をつくるつくる力を強くするいまの価値を生む長期中期短期

Slide 19

Slide 19 text

異なる時間軸を扱うマルチドライブアーキテクチャオポチュニティ駆動（顧客‧市場に向き合うアジリティ）顧客や市場からの機会（Opportunity）に直接対応し、新しい価値を素早く創造・検証・提供する駆動力 MVP Growth 新規アプリA 新規アプリB 既存アプリA 既存アプリB ・・・・・・不確実性価値の最大化不確実性の解像度が変化するオポチュニティ駆動に投資すると、不確実性を解像し、ポテンシャルを価値に変換できる

Slide 20

Slide 20 text

異なる時間軸を扱うマルチドライブアーキテクチャイネーブルメント駆動（アジリティを⽀える開発効率）開発効率を担保し、安定性を確保する駆動⼒スピードの持続開発効率の最⼤化基盤の⼀貫性認証基盤権限制御 Agentic RAG ⋯ プロダクト横断でなくてはならないケイパビリティを提供するイネーブルメント駆動に投資すると、オポチュニティ駆動領域の価値創出が速く‧安全になる

Slide 21

Slide 21 text

異なる時間軸を扱うマルチドライブアーキテクチャビジョン駆動（アジリティのベクトルを定める羅針盤）⻑期的な戦略やビジョンを具現化し、プロダクト全体の⽅向性をつくる駆動⼒ビジョン駆動に投資すると、将来的に取れる市場⾯積そのものが広がる成⻑領域の開拓⻑期の⽅向性と筋道の構築持続的な競争優位性の構築どこへ⾏くか（どの領域で勝つか）なぜそこへ⾏くか（勝つ理由）何を前提とするか（勝てる条件）何に投資するか（勝つために必要な武器は何か）何を捨てるか（勝つために戦わない領域はどこか）

Slide 22

Slide 22 text

異なる駆動をつなぐテンションとクラッチ

Slide 23

Slide 23 text

異なる駆動をつなぐ遅い変化と速い変化の衝突二項対立は負債を生み、成長の足かせになるテンション（歪み）市場ニーズ、価値検証遅い変化速い変化遅い変化を優先した場合：（スピードを犠牲にしがち）機会損失という事業的負債が⽣まれる速い変化を優先した場合：（品質を犠牲にしがち）技術的負債が⽣まれる安定性、品質保証

Slide 24

Slide 24 text

異なる駆動をつなぐテンションとは異なる時間軸を持つ関⼼事が、混在あるいは不適切に接続されていることで⽣じる歪みや摩擦のことテンションは⼀種のサイン速度差があり、境界の設計が必要だというアラートテンションは、後述するクラッチで吸収していくテンション（歪み）中期（あるいは⻑期）の時間軸短期の時間軸優先順位は？？技術的負債はいつ解消する？

Slide 25

Slide 25 text

異なる駆動をつなぐ異なる時間軸を調整するクラッチ駆動間のテンションを吸収する境界を設ける速度差はテンションを⽣むならば吸収する仕組み（＝クラッチ）が必要中期（あるいは⻑期）の時間軸短期の時間軸テンションを吸収するクラッチ

Slide 26

Slide 26 text

異なる駆動をつなぐ参考）クラッチのイメージエンジンエンジンクラッチによって速度差を吸収する

Slide 27

Slide 27 text

異なる駆動をつなぐクラッチの具体、２種類のクラッチ技術的クラッチの他に、組織的クラッチも効果的技術的クラッチ組織的クラッチ ● 共有ライブラリ ● API ● ⾮同期化 ● フィーチャーフラグ ● イベント駆動 ● マイクロサービス etc. ● ロードマップ同期 ● 責務の境界付け ● 優先順位のプロセス ● 設計レビュー ● 技術的負債の返済ルール ● フィードバックループの設計 etc.

Slide 28

Slide 28 text

共有ライブラリフィーチャーフラグ API (REST, gRPC) ⾮同期化(キューイング) イベント駆動マイクロサービスコスト（ρ）効果（η）クラッチ（分離）のトレードオフ効果が⾼いほど導⼊‧運⽤コストも⾼くなる

Slide 29

Slide 29 text

異なる駆動をつなぐテンションの変換モデル削減効果分離コスト T: テンション ⋯ 組織の速度差が原因で生じる摩擦を定量化したもの η: 変換効率 ⋯ テンションをどれだけ削減できるか ρ: 内部抵抗 ⋯ クラッチの導入やメンテに掛かるコストや複雑性例：マイクロサービスは変換効率が高いが、内部抵抗も高い改善前テンション純改善後テンションコスト改善前改善後クラッチの削減効果と追加コストを意識する

Slide 30

Slide 30 text

クラッチ導入の損益分岐点テンションが⾼い場合はマイクロサービスのほうが有利テンションが低い場合は軽量な境界のほうが有利テンションが低いのに重厚な境界を設けると逆効果

Slide 31

Slide 31 text

体制とアーキテクチャのイメージ

Slide 32

Slide 32 text

体制とアーキテクチャのイメージマルチドライブとチームトポロジーコンプリケイテッド・サブシステムチームプラットフォームチームストリームアラインドチームイネイブリングチームファシリテーション X -as-a-Service X -as-a-Service ビジョン駆動領域オポチュニティ駆動領域イネーブルメント駆動領域異なる時間軸を扱う概念がチームトポロジーとの⼤きな差？

Slide 33

Slide 33 text

オポチュニティイネーブルメントビジョン共通基盤体制とアーキテクチャのイメージアーキテクチャイメージドメイン基盤データ基盤 App1 App2 … AppN AI エージェント関⼼事と変化速度で駆動領域を分けるコンテキスト基盤エージェント基盤

Slide 34

Slide 34 text

前半のまとめ：マルチドライブアーキテクチャの3原則原則1：分離の原則（Separation）異なる時間軸を混ぜない短期‧中期‧⻑期の関⼼事を不⽤意に混ぜると、速度差による「テンション（歪み）」が⽣まれ、双⽅の良さを殺してしまう。まずは時間軸で切り分ける原則2：駆動の原則（Drive） 3つのエンジンを持つビジョン(V)、イネーブルメント(E)、オポチュニティ(O)。役割の異なる3つの駆動⼒を定義し、それぞれを最適な速度で⾃律的に回す原則3：接続の原則（Connection）クラッチでつなぐ速度差を吸収する「クラッチ（境界）」を設け、コストと効果の損益分岐点を⾒極めて適切に接続する

Slide 35

Slide 35 text

マルチドライブアーキテクチャ事例紹介 x2

Slide 36

Slide 36 text

事例紹介の前に⼩林達（Satoshi Kobayashi）略歴ディーバ (2004 〜 2014) 連結会計製品の導⼊‧開発ビズリーチ (2014 〜 2024) HRMOS採⽤‧評価の⽴ち上げ（開発部⻑）ログラス (2024 〜) リアーキテクチャ、共通基盤（EM）好きなモデル Composer 1 趣味娘とキャンプ、カメラ、⽇本酒

Slide 37

Slide 37 text

事例 1/2: 基幹製品のリアーキテクチャ

Slide 38

Slide 38 text

事例 1/2: 基幹製品のリアーキテクチャ事例 1: 基幹製品のリアーキテクチャログラスは、昨年末よりリアーキテクチャリングに⼤きな投資をしています。リアーキテクチャの結果、データ分析基盤が誕⽣しました（記事参考）。最⼩のリスクで最⼤のインパクトをどう実現しようとしてきたか、マルチドライブアーキテクチャの視点で振り返ってみます。 https://note.com/loglass_post/n/n04d559e729c5

Slide 39

Slide 39 text

事例 1/2: 基幹製品のリアーキテクチャモノリシックなアーキテクチャの限界が⾒え始めた • 創業より6年、モノリスが中⼼ • DDD、クリーンアーキテクチャの徹底により内部品質は保たれていた • それでも（それが故に顕在化が遅くなった可能性もあり）、コードベースが⼤きくなるにつれ認知負荷が限界へ • 短期的な施策の波に押され、⻑期的な施策が打てなくなりつつあったモノリス  

Slide 40

Slide 40 text

事例 1/2: 基幹製品のリアーキテクチャ対処療法にとどまり、製品の進化が減速抜本的な対応の必要性複雑化した業務に対応した処理の再構成複数のケースに対応しやすい柔軟さを持ったモデルの実現疎結合‧⾼凝集のモジュール構造対処療法⾮同期化、処理の分割実⾏データ‧処理が類似した固有の実装テストコード追加、プロセスの⾒直しタイムアウト多発障害の増加傾向新たなユースケース

Slide 41

Slide 41 text

事例 1/2: 基幹製品のリアーキテクチャすべての駆動が未分化の状態だった、と⾔えるオポチュニティ、イネーブリング、ビジョンの駆動が絡まった未分化の状態 • 開発計画は、短期開発‧⻑期開発の速度差「テンション」を意識できていない • モノリスは、速度差を吸収するための「クラッチ」機構を意識できていないなにより、まず「明確な境界」を引くことが必要だった

Slide 42

Slide 42 text

• 専任チームを構成。社歴の⻑いエース級数⼈のPdM、デザイナー、エンジニア。社歴が⻑い ≒ 歴史‧痛みを深く共有（課題感が強い） • 荒いスケジュールはあるが、短期的な売上を追わないのはもちろんこと、⻑期の売上計画にも織り込まない形でスタート • ログラスの企業規模では、⼤きな投資 • 振り返ると、まさにビジョン駆動の萌芽であった事例 1/2: 基幹製品のリアーキテクチャ完全に独⽴したプロジェクト組成という意思決定⻑期的な競争優位性の獲得にフォーカスしたプロジェクトを組成

Slide 43

Slide 43 text

事例 1/2: 基幹製品のリアーキテクチャ既存開発と距離をおき、接続が不明瞭な状態でのテンションの衝突を避けるすぐに開発しないビジョン駆動の分離の徹底 FigJamの絵調査、要件化、モデリングの徹底 • 徹底的な先⾏プロダクトの調査 • 顧客要望の深堀り。たとえば、既存製品がカバーできていない巨⼤なExcelユースケースの分析、要求への昇華（右図） • 並⾏して技術検証とPoCの繰り返し

Slide 44

Slide 44 text

事例 1/2: 基幹製品のリアーキテクチャテンションが⾼まり、ビッグバンの懸念へ半年以上の試⾏錯誤の末、リアーキテクチャの形は明確になった。しかし、「最⾼のものをじっくり作って乗り換えてもらう」時間軸は⻑い。現実との乖離‧世の中においていかれるリスクが、ビジョン駆動における懸念としてあがってきた駆動差を低減し、ビッグバンリリースを避けたい理想の形は⾒えつつあった既存製品との⼤きすぎるテンション

Slide 45

Slide 45 text

事例 1/2: 基幹製品のリアーキテクチャクラッチの「効果」と「コスト」のトレードオフ観点しかし、⼤きく異なる駆動を接続する ≒ クラッチを⾼度にしすぎることは、トレードオフを超え、効果の頭打ち、場合によっては減少の可能性も懸念された

Slide 46

Slide 46 text

事例 1/2: 基幹製品のリアーキテクチャ現実に「適合」できるのか、検証を繰り返した既存製品を置換または接続できるのか。「適合設計」と呼ぶ、クラッチの形成期を経ることになった。同時に理想にフィードバックを得る機会ともなった。理想は現実から乖離していないか？理想が現実に耐えうるのか？適合設計 ≒ クラッチ形成期ビジョン駆動オポチュニティ駆動理想リアーキテクチャ現実既存製品 Feedback Verﬁcation

Slide 47

Slide 47 text

事例 1/2: 基幹製品のリアーキテクチャ部分的なリプレース、という現実解に舵を切った既存の改修性能や品質の改善幅に疑問符部分リプレース現実界なのでは？完全リプレース乗り換えられない懸念旧製品新製品旧製品新製品旧 to 新製品効果★★☆ コスト★★☆ 効果★☆☆ コスト★☆☆ 効果★★☆ コスト★★★ 採⽤

Slide 48

Slide 48 text

事例 1/2: 基幹製品のリアーキテクチャ複数ドライブを並⾛させるアーキテクチャへ性格の異なるシステム間を接続し、単⼀プロダクトを形成。リーアキテクチャは、現在進⾏形でプロダクション環境への段階的デプロイを進めているビジョン駆動オポチュニティ駆動新アーキテクチャ既存プロダクト短期ユースケース RDB データ同期 Outbox トランザクショナル業務DB的（OLTP） Stream Aligned Source of Truth 個別業務重視分析DB的（OLAP）⻑期ロードマップ汎⽤化重視 Complicated SubSystem スケーラブル⾮RDB クラッチ

Slide 49

Slide 49 text

事例 1/2: 基幹製品のリアーキテクチャ • リアーキテクチャにビジョン駆動で取り組んできた。 • 完全に独⽴したチームで『⻑く使う』ために『正しく作る』ことを⽬標 • ビッグバンリリースの懸念、コストに対して成果が頭打ちする懸念 • 早期にクラッチを形成する⽅向に舵を切り、新旧をスムーズにつなげる • 結果的に、オポチュニティ駆動の開発を維持しつつ、ビジョン駆動の成果を編み込んでいく現実解に着地しつつある事例1のまとめ

Slide 50

Slide 50 text

事例 2/2: 全社横断の共通基盤

Slide 51

Slide 51 text

事例 2/2: 全社横断の共通基盤事例 2: 全社横断の共通基盤昨年末から少しずつ動き出し、今秋より本格化した共通基盤構築（記事参照）。マルチドライブアーキテクチャで広いスコープをどう捉え、どうマネージしていこうとしているか、現在地をお伝えします。 https://note.com/loglass_post/n/nba2b49ea7da5

Slide 52

Slide 52 text

事例 2/2: 全社横断の共通基盤複数の⼤きな変化が、同時に起こりつつある既存製品中⼼リアーキテクチャ既存製品 + 新規製品マルチプロダクト製品 + 組織 + 個⼈ AI ⻑期視点で⼼臓部の再構成モノリス分割‧認知負荷低減 Loglass AI Agents構想 AIネイティブカンパニーへ経営管理、⼈員計画、同時多発的に多数の⽴ち上げ⼀貫性のある進化のための「共通基盤」の機運昨今、ログラスの製品を取り巻く状況‧環境が、⼤きく変わってきた。

Slide 53

Slide 53 text

それぞれで向かう⽅向性と「時間軸」が異なり、整合を取ることが極めて難しい既存製品中⼼既存製品 + 新規製品製品 + 組織 + 個⼈⻑期視点で⼼臓部の再構成モノリス分割‧認知負荷低減 Loglass AI Agents構想 AIネイティブカンパニーへ経営管理、⼈員計画、 2027年までに20プロダクトリアーキテクチャマルチプロダクト AI ⼀貫性のある進化のための「共通基盤」の機運事例 2/2: 全社横断の共通基盤複数の⼤きな変化が、同時に起こりつつある⻑期視点での抜本的な変化が⽬的製品ごとに要件‧技術‧進度に「差」刻々、世の状況が変わり⽅向を定めにくい

Slide 54

Slide 54 text

変化を許容しつつ、無秩序にプロダクトが広がることは避けなければいけない既存製品中⼼既存製品 + 新規製品製品 + 組織 + 個⼈⻑期視点で⼼臓部の再構成モノリス分割‧認知負荷低減 Loglass AI Agents構想 AIネイティブカンパニーへ経営管理、⼈員計画、 2027年までに20プロダクトリアーキテクチャマルチプロダクト AI ⼀貫性のある進化のための「共通基盤」の機運事例 2/2: 全社横断の共通基盤複数の⼤きな変化が、同時に起こりつつある素早い要求変化への適応秩序だった製品進化 V S

Slide 55

Slide 55 text

事例 2/2: 全社横断の共通基盤進度の速い部分をまずイネーブルさせる • 共通ユーザー管理に取り組む • データモデル、データの独⽴性、アプリケーションテンプレートを同時に提供 • ⼀部メンバーの兼務でスタート経営管理新製品A 新製品B 新製品C 共通ユーザー管理イネーブルメント駆動で初速をつける

Slide 56

Slide 56 text

事例 2/2: 全社横断の共通基盤イネーブルメント駆動で初速をつけるビジョンを語るではなく、進度の速い部分をまずイネーブルさせることに集中。 • 摩擦を減らして⾃由度を獲得 ‐ 初期は、プロセスの摩擦‧認知負荷が⾼く、ビジョンを語っても実⾏できない ‐ イネーブリングは、摩擦を減らして⾃由度を増やす⾏為 • 全体の最適解への準備 ‐ イネーブリングは、多くの場合「今の状況での個別最適を⾼める」活動 ‐ イネーブリング施策が回ると「これでできそう」という⾃⼰効⼒感が⽣まれる ‐ 「もっと⼤きな⽬的のためにどこを変えるべきか」を考える素地ができた

Slide 57

Slide 57 text

事例 2/2: 全社横断の共通基盤あるべき姿、ビジョン駆動へのギアチェンジ現在は、統合ロードマップの策定が徐々に進み、駆動を切り替えようとしている「この基盤を使って、どんな世界を実現したいか？」という問いに答える、意味‧⽬的の付与。イネーブリングによって「どこへ⾏ってもおかしくない状態」の獲得し、イネーブルメント駆動ビジョン駆動

Slide 58

Slide 58 text

事例 2/2: 全社横断の共通基盤駆動の移⾏ ≒トポロジーの変遷駆動の移⾏をトポロジーの変遷になぞらえて捉えているイネーブルメント駆動ビジョン駆動「偶有的複雑性と戦うためのアーキテクチャとチームトポロジー」(2024)より

Slide 59

Slide 59 text

事例 x2 のまとめ

Slide 60

Slide 60 text

事例まとめ: リアーキテクチャと共通基盤異なる駆動と、境界、遷移をマネージする現実を、マルチドライブアーキテクチャのフレームワークで捉え直し、複数の異なる駆動と、その時間軸での遷移で⽴体的に捉え、マネージしていく意義 • リアーキテクチャは、ビジョン駆動で開始し、オポチュニティ駆動と接続する • 共通基盤は、イネーブルメント駆動で開始し、ビジョン駆動に遷移するマルチドライブアーキテクチャが、複雑で動的な現実に地図を与えるフレームワークになる

Slide 61

Slide 61 text

まとめ

Slide 62

Slide 62 text

まとめまとめ：ご清聴いただきありがとうございます！テンションを恐れず、適切なクラッチを設計しましょう • 速度差（時間軸）を⾒極め、適切に分離する ‐ 時間軸のズレを混ぜるのではなく、駆動⼒を分離 ‐ ただし、分離にはコストが伴うため、速度差に⾒合うだけの効果があるか（損益分岐点）を常に⾒極める • アーキテクチャを動的に捉る ‐ フェーズによって主役となる駆動（V‧E‧O）は変わってくる ‐ 変化に合わせて柔軟に境界を引き直す • テンション（歪み‧摩擦）を進化の合図にする ‐ 現場の摩擦は新たなクラッチが必要になったというアラート。 ‐ テンションを再設計のトリガーに変える

Slide 63

Slide 63 text

よりリアルなお話はぜひログラスのブースで！書籍販売ブースの近くです

Slide 64

Slide 64 text

No content

Slide 65

Slide 65 text

Appendix

Slide 66

Slide 66 text

Appendix テンションは駆動間の速度差に⽐例する安定性優先スピード優先テンションは駆動間の速度差に⽐例する T_i,j : 駆動i、駆動j 間のテンション v_i : 駆動iにおける変化速度(velocity) 速度差が⼤きいほど、クラッチ（緩和する仕組み）が必要テンション