本記事は 2026 年 3 月 9 日 に公開された「 Kinesis On-demand Advantage saves 60%+ on streaming costs 」を翻訳したものです。 Amazon Kinesis Data Streams は、あらゆる規模のストリーミングデータをキャプチャ、処理、保存できるサーバーレスのストリーミングデータサービスです。2025 年 11 月 4 日、 Amazon Kinesis Data Streams に On-demand Advantage モードが導入されました。オンデマンドストリームで瞬時にスループットを増加させ、安定したストリーミングワークロードのコストを最適化できる機能です。従来はキャパシティを手動管理するプロビジョンドモードか、自動スケーリングするオンデマンドモードのどちらかを選ぶ必要がありましたが、On-demand Advantage の導入によりストリームタイプを意識する必要がなくなりました。 本記事では、使用パターンが異なる 3 つのシナリオを比較し、On-demand Advantage モードでパフォーマンスと柔軟性を維持しながらストリーミングコストを最適化する方法を紹介します。正確に比較するため、2 つの AWS アカウントでシミュレーションを実施しました。1 つは On-demand Standard モード、もう 1 つはアカウントレベルで On-demand Advantage モードを有効にしたアカウントです。両方のデプロイで同一のストリーム構成、シャード割り当て、取り込みパターンを維持し、以下のシナリオで課金への影響を比較しました。 本記事に記載されている料金はすべて us-east-1 リージョンのものです。 On-demand Advantage の節約効果の内訳 前回の記事 では、ウォームスループット機能と、On-demand Advantage モードでストリームをウォームアップしてギガバイト単位や毎秒数百万レコードを処理する方法を紹介しました。次に、On-demand Advantage モードでパフォーマンスと柔軟性を維持しながら、さまざまなストリーミングユースケースがどのようにコスト効率よく運用できるかを説明します。 アカウントレベルで On-demand Advantage モードを有効にすると、On-demand Standard と比較して多くの面でコスト削減が得られます。主なポイントは以下のとおりです。 AWS リージョンで最低 25 MiBps の使用量をコミットすることで、60% 以上の節約が得られます。最低コミットメントは、AWS バージニア北部リージョンの 公開料金 に基づき 1 日あたり約 100 ドルです。 Enhanced Fan Out コンシューマーの料金が 68% 低くなり、ストリームあたり最大 50 まで利用可能です (On-demand Advantage なしでは 20)。 24 時間を超えるデータ保持の料金が 77% 低くなります。 ストリームごとの最低固定料金がないため、コスト増加なしに必要な数のストリームを利用できます。 Kinesis On-demand Advantage を選ぶ理由: 60% 以上の節約 Amazon Kinesis Data Streams の On-demand Standard モードと Advantage モードの両方を評価するため、10 個のストリームをデプロイし、全ストリームで合計 100 MiBps の持続的な取り込みスループットを生成しました。EC サイトがユーザーのクリックストリームデータをストリーミングしてリアルタイムインサイトを生成するケースをモデル化しています。シミュレーションは異なるモードの 2 つの AWS アカウントで 2 日間実施しました。1 日目は 100 MiBps の安定した取り込みレートを維持しました。2 日目は、ホリデーセールイベントに備えて 10 個すべてのストリームのウォームスループットキャパシティを 10 倍に増加させ、実際の取り込みレートは 100 MiBps のまま維持しました。各ストリームは 10 MiBps を取り込み、全オンデマンドストリームで合計 100 MiBps です。 2 日目に、On-demand Advantage モードを設定したアカウントで 100 MiBps のウォームスループットを有効にしました。ウォームスループットを使えば、トラフィック急増に備えてストリームを事前にスケールアップできます。 On-demand Standard の Cost Explorer: On-demand Advantage モードの Cost Explorer: シナリオ 1 で On-demand Advantage のコスト効率が高い理由は、安定したデータスループットと複数ストリームの利用にあります。Advantage モードではストリーム時間料金がゼロですが、On-demand Standard モードではストリーム時間あたり $0.04 の料金が発生します。さらに、Advantage モードの受信バイト料金は GB あたり $0.032 で、On-demand Standard は GB あたり $0.08 です。On-demand Standard 構成では 48 時間で合計 $2,071.75 のコストが発生し、1 日あたり $1,037、年間 $378,505 になります。同じワークロードを On-demand Advantage モードで実行すると、同じ 48 時間で $823.44、1 日あたり約 $412、年間コスト $150,380 です。On-demand Advantage ではウォームスループットの追加料金もかかりません。60% のコスト削減に相当し、このワークロードだけで年間 $228,125 の節約になります。 シナリオ 2: 1 アカウントで 10 ストリーム、15 MiBps スループットと延長保持 ある医療企業では、データの再処理に備えて 2 日間のデータ保持期間が必要であり、規制要件により異なる種類のデータを別々のストリームに保存する必要があります。シナリオ 2 の再現として、On-demand Standard モードと Advantage モードの両方で、48 時間の延長保持期間を設定した 10 個の Amazon Kinesis Data Streams をデプロイしました。延長保持により、ダウンストリームシステムはデータを再処理し、一時的な障害から復旧できます。複数ストリームと保持期間を利用するため、On-demand Advantage モードでコスト効率が高いと予想されます。コスト内訳を見ていきましょう。 コストを評価するため、10 ストリームに分散した 15 MiBps の安定した取り込みトラフィックを 48 時間生成しました。On-demand Standard モード: On-demand Advantage モード有効時: Cost Explorer のスクリーンショットで、On-demand Standard モードと Advantage モードの料金を並べて比較できます。On-demand Standard の 1 日あたりのコストは $176 で、年間 $64,240 です。On-demand Advantage の 1 日あたりのコストは $104 で、年間コストは $37,960 です。15 MiBps のスループットと延長保持を利用しても、Advantage モードで 41% の節約を達成しました。Standard モードでは 24 時間を超え 7 日間までのデータ保存に GB あたり $0.10 の追加料金がかかります。Advantage モードでは 24 時間を超え 365 日間までのデータ保存に GB 月あたり $0.023 の追加料金となり、データストレージのコストが最適化されます。シナリオ 2 の結果は、Advantage モードがより幅広いワークロードでコストメリットをもたらすことを示しています。Advantage モードを有効にすると、最低 25 MiBps の使用量にコミットすることになります。しかし、15 MiBps スループットのシミュレーションでも大幅なコスト削減を達成しました。Advantage モードでは、10 MiBps 以上を取り込んでいれば、25 MiBps のしきい値にコミットしていても Standard モードより低コストになります。 シナリオ 3: 1 つの Kinesis Data Stream と 10 個の Enhanced Fan-Out コンシューマー マイクロサービスアーキテクチャでは、複数のサービスが同じデータストリームから同時に低レイテンシーで読み取る必要がある場合があります。システムの進化に伴い、新しい分析ユースケースをサポートし、ストリーミングデータパイプラインからより深いインサイトを得るために、Enhanced Fan-Out (EFO) コンシューマーが追加されることがあります。 次に、マイクロサービスアーキテクチャで On-demand Advantage モードを使用した EFO コンシューマーのコスト比較を評価します。24 時間にわたり、標準の 24 時間保持を設定した 1 つの Amazon Kinesis Data Stream に、EFO コンシューマーとして設定した 10 個の AWS Lambda 関数を接続してテストしました。 複数の EFO コンシューマーが同じストリームに同時にアクセスした場合のコスト影響を評価するため、評価期間を通じて 25 MiBps の安定した取り込みレートを生成しました。以下のチャートは、25 MiBps ペイロードの Enhanced Fan-Out コンシューマーを持つ Kinesis Data Stream を示しています。 以下のチャートは、On-demand Standard モードと On-demand Advantage モード有効時のコスト差を示しています。 Cost Explorer の分析から、複数の EFO コンシューマーを使用しても、On-demand Advantage モードの方が On-demand Standard モードより全体コストが低いことがわかります。On-demand Standard のコストは $1,266 で、Advantage モードのコストは $419 でした。同じワークロード特性で約 67% の節約を達成し、年間 $309,155 の節約になります。イベント駆動型アーキテクチャで複数のサービスがストリーミングデータへの独立したリアルタイムアクセスを必要とする組織にとって、EFO のコスト削減効果は特に大きいといえます。Enhanced Fan-Out のデータ取得料金は、Advantage モードではコンシューマーあたり GB あたり $0.016 で、Standard モードの $0.05 と比較して大幅に低くなっています。一方、持続スループットが低い (10 MiBps 未満) スパイクが大きく予測不可能なワークロードは、On-demand Standard の候補として推奨されます。スループット使用量をコミットせずに、ストリームのスループットキャパシティを自動スケーリングさせられます。 On-demand Advantage とプロビジョンドモードの比較: On-demand Standard モードと On-demand Advantage モードの両方が利用可能になったことで、プロビジョンドモードに頼る必要がなくなりました。キャパシティを手動管理する必要がなく、オンデマンドストリームならシンプルな料金モデルで運用できます。さらに、多数のストリームを運用したり、延長保持や Enhanced Fan-Out などの機能を使用しているプロビジョンドワークロードのお客様は、On-demand Advantage への移行を強く検討すべきです。データストリームはどのモードを選択しても同じ基盤インフラストラクチャを使用するため、On-demand Advantage とプロビジョンドの間で可用性や信頼性に違いはありません。 ウォームスループットに追加料金がかからないため、瞬時スケーリングが必要な場合は On-demand Advantage がプロビジョンドモードより適しています。 Gbps 規模でも、On-demand Advantage は実際のデータ使用量に基づく課金で競争力のある料金です。 On-demand Advantage は、EFO (マイクロサービスのような高ファンアウトニーズ向け) と延長保持の利用コストが大幅に低くなっています。 比較の参考として、Kinesis コンソールを使用して、アカウントの上位 200 のプロビジョンドストリームが On-demand Advantage に適しているかどうかを確認できます。 まとめ 本記事では、Amazon Kinesis Data Streams の On-demand Advantage モードがパフォーマンスと柔軟性を維持しながら大幅なコスト削減を実現する 3 つの実際のシナリオを紹介しました。On-demand Advantage は大規模ワークロードで優れたパフォーマンスを発揮し、On-demand Standard と合わせて、Kinesis Data Streams はさまざまなストリーミングユースケースにシンプルかつコスト効率の高いソリューションを提供します。ワークロードが安定して 10 MiBps 以上をストリーミングする場合、2 つ以上のコンシューマーにファンアウトする場合、24 時間を超えてデータを保持する場合、または数百のストリームを運用する場合は、On-demand Advantage が最もコスト効率の高いモードです。それ以外のワークロードには、On-demand Standard モードが適しています。多様なプロデューサーからコンシューマーへ毎秒数百万レコードやギガバイト単位のデータをストリーミングする場合でも、Kinesis Data Streams で対応できます。ぜひ Kinesis Data Streams On-demand Advantage を活用して、リアルタイムインサイトを組織やプロセスに取り入れてみてください。 著者について Sandhya Khanderia Sandhya は、AWS のシニアテクニカルアカウントマネージャー兼データ分析スペシャリストです。分析およびデータサービスの深い専門知識を持ち、パフォーマンス、スケーラビリティ、コスト効率に優れたクラウドアーキテクチャの最適化を支援しています。 Pratik Patel Pratik は、AWS のシニアテクニカルアカウントマネージャー兼ストリーミング分析スペシャリストです。AWS のお客様と連携し、ベストプラクティスに基づくソリューションの計画と構築を支援するとともに、お客様の AWS 環境の運用状態を健全に保つための継続的なサポートと技術ガイダンスを提供しています。 Varsha Palepu Varsha は、AWS のソリューションアーキテクトとして、中小企業のイノベーションと AWS 上での構築を支援しています。ストリーミングチームに所属し、技術コンテンツの作成やお客様のクラウド上での目標達成を支援しています。 Kalyan Janaki Kalyan は、Amazon Web Services のシニアビッグデータ＆分析スペシャリストです。高いスケーラビリティ、パフォーマンス、セキュリティを備えたクラウドベースソリューションの設計と構築を支援しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Takayuki Enomoto がレビューしました。

本記事は、CADDi プロダクトチーム Advent Calendar 2024 10日目の記事です。 CADDi プロダクトチーム Advent Calendar 2024 - Adventar はじめに CTO室の西名( @mikesorae )です。最近はもっぱら予算策定や生産性改善の施策を担当しています。 ソフトウェア開発とビジネス、インフラ構成と予算管理、生産性と投資対効果等、事業組織でソフトウェアを開発する上ではどうしてもお金の話がついて回ります。 本記事では、ソフトウェア開発者がステークホルダーと建設的に議論し、より大きなインパクトを生み出すために抑えておくべき会計の用語やポイントをご紹介します。 Why 会計知識 ゲームのルールを理解する 「今このチームにこれ以上の人員は追加できない」「なぜこのツールが必要なのかを説明してほしい」「その技術導入による事業インパクトを説明してほしい」 皆さんも経営者や事業責任者(あるいは中間のマネージャ)との議論の中で上記のようなことを言われ、やきもきした経験が少なからずあると思います。 ソフトウェア開発者と経営者、事業責任者とのコミュニケーション摩擦の原因の一つは、それぞれがプレイしているゲームのルールが異なることだと考えています。 営利企業で働く以上、我々は市場や法制度のルールに従う必要があり、会計はその中でも特に重要なものの一つです。 経営者や投資家、金融機関は会計を共通言語として会話し、その基盤の上に経営戦略や事業戦略のレイヤーが存在しています。 経営者や事業責任者も漏れなくこのルールや力学に従っているので、彼らがどういうルールの上でゲームをプレイしているのかを理解することで、より建設的で有意義な議論ができるようになると考えています。 本記事のゴール 今回は特に損益計算書(Profit and Loss statement: PL)にフォーカスし、以下を目指したいと思います。 PLレベルでの事業構造の解像度を上げる ソフトウェア開発の施策の事業的価値をPL上の言葉で理解する 財務会計と管理会計の話は長くなりそうなので、今回は触れずに進みます。 財務三表と損益計算書(PL) 財務三表とは「貸借対照表(Balance Sheet: BS)」、「損益計算書(Profit and Loss statement: PL)」、「キャッシュフロー計算書(Cash Flow statement: CF)」の3つで、それぞれ会社の資産状況、収益状況、お金の流れを表す資料です。 特に上場企業であれば有価証券報告書として上記を含んだ財務諸表を提出する必要がありますし、会社法ではすべての会社が事業年度ごとの貸借対照表や損益計算書を作成することを義務付けられています。 経営者や投資家はこれらの資料を使って会社の資産や事業、財務状況の健全性を把握し、今後の方針を判断します。 今回は特に「事業の健全性を把握するためのツールとしてのPL」と「ソフトウェア開発」の関係について説明してみたいと思います。 PLの基本構造 下記の図は、一般的なPLの内訳をわかりやすく表現したものです。 PLの内訳 具体的にイメージしやすくするために、簡単なPLのサンプルを用意しました。 サンプルPL 一番上に売上高があり、そこから売上原価や一般管理費等を引いたり営業外収益を足したりしていって、最終的に残ったものが純利益となります。 PL上の売上高や原価率、営業利益率等を見ることによって、事業の収益性の健全さを知ることができます。 (余談ですが、売上目標文脈でよく出てくる「トップライン」という言葉は、PLの一番上の行が売上高であることに由来するそうです) ここからはPL上の各項目について、事業上の意味やソフトウェア開発における関係を掘り下げていきたいと思います。 売上高 (Revenue) 売上高はその名の通り、その会社や事業が製品やサービスの販売によって得た売上の合計です。 売上高が大きいということは、単純に良い製品やサービスを提供していることや、優れたブランド認知、マーケティングチャネル、セールス部門等、売上に影響するなんらかの強い要素を持っていることの間接的な証明になります。 一般的に、売上高はその事業が成長し続けているかどうかを測るための最重要指標として利用されます。 売上原価 (Cost of goods sold: COGS) 売上原価は、製品やサービスを提供するために必要なコストです。 例えばパン屋さんであれば以下のようなものが含まれます。 パンを作る材料費 (直接材料費) パンを作る職人さんの賃金 (直接労務費) パンを焼く設備費 (直接経費) パンを作る上で必要な、オイルやクッキングシート等の消耗品 (間接材料費) パンを販売する人の賃金 (間接労務費) パンを焼く設備の修繕費 (間接経費) (厳密には売上原価には当期に販売された製品の製造原価が含まれます) 何を原価として計上するかは会社のポリシーにもよりますが、ソフトウェア開発では以下のようなものが売上原価として考えられます。 AWS/Google Cloud/Cloudflare等のインフラ費用 サービス提供に必要なソフトウェアやライセンス費用 (地図APIや決済API等) 運用・監視・保守に必要なソフトウェアやライセンス費用 オンコール対応や待機における人件費の一部 サポートやカスタマーサクセスの人件費の一部 サービス維持に必要なセキュリティパッチや不具合修正対応の人件費 売上総利益 (粗利益、Gross profit) 売上高から売上原価を引いたものが売上総利益(一般的に粗利と呼ばれる)ものになります。 粗利には事業維持のための一般管理費や営業活動費が含まれておらず、サービスそのものの純粋な収益性を判断する重要指標として利用されます。 例えば全体の利益が赤字になっていても、粗利が黒字かつ売上高が成長していればサービス自体の収益力としては健全と判断され、投資家や金融機関からの融資を受けやすくなります。 特にスタートアップでは、Jカーブと呼ばれるように短期的には赤字を出しながらも最終的には急角度で成長していく売上モデルを目指すことが一般的です。 www.freee.co.jp 販売費および一般管理費 (販管費、Selling, General and Administrative expenses: SG&A) 販売費および一般管理費(一般的に販管費と呼ばれる)は、事業活動の維持に必要な費用や製品の営業・販促に必要な費用をまとめたものです。 日本で一般的に使われるJ-GAAPやアメリカのUS-GAAPなどの会計基準では、これらの費用は販売費および一般管理費として一つのカテゴリにまとめられることが多いですが、国際財務報告基準(International Financial Reporting Standards: IFRS)ではこれらを性質別(人件費、減価償却費、原材料費等)または機能別(販売費、一般管理費等)で分類することが義務付けられるようになりました。 昨今ではIFRS対応のため、販売費および一般管理費を更に販売・マーケティング費(Sales & Markething: S&M)や一般管理費 General and Administrative: G&A)、研究開発費(Research & Development: R&D)のように分類する企業も増えています。 販売・マーケティング費 (Sales & Marketing expenses: S&M) COGSが現在のサービスを提供・維持する目的なのに対して、S&MやR&Dコストは未来の売上高成長や利益率改善に対する投資です。 そのため、経営層や投資家に合理的な説明ができる限り(かつ財務状況が許す限り)赤字であっても投資するという判断が有りえます。 例えばSales&Marketingコストには営業の人件費や出張費、会食費、広告宣伝費等が含まれますが、これらは未来の売上獲得のための投資と考えることができます。 ソフトウェア開発者が直接的に営業やマーケティングの活動に関わることはあまり多くないかもしれませんが、MA(Marketing Automation)ツールの導入による人件費の抑制やEFO(Entry Form Optimization)によるコンバージョンレートの改善等、間接的にこれらのコスト効率に関わる機会は多くありえます。 研究開発費 (Research & Development expenses: R&D) R&Dには短期の売上向上や利益率向上のための投資や、中長期の基礎研究開発的な投資が含まれます。 例えば、向こう半年から1年程度の機能提供ロードマップに含まれる開発は短期のR&D、顧客への提供価値があるかわからないものや技術的な実現方法自体がわからないものに対する開発は中長期のR&Dと考えることができます。 COGSやS&Mに含まれない開発はほぼR&Dコストなので具体例は枚挙にいとまがありませんが、例えば以下のようなものが挙げられます。 新機能の開発 UIの大規模なアップデート メンテナンス性向上のためのリファクタリング テスト自動化 各種機械学習のPoC IaC導入 S&MやR&D費用の基本的な考え方は、売上総利益(粗利)から一般管理費(G&A)を引いた残りの利益を事業に再投資し、未来の売上や利益を伸ばすことです。 中長期のR&Dを行う前提としては、ある程度の財務健全性が担保されていることや、事業計画とアラインしていることが求められます。 一般管理費 (General and Administrative expenses: G&A) COGSにもS&MにもR&Dにも含まれない、会社運営に必要な業務はG&Aに分類されます。 例えば人事評価、全社会議への出席、各種トレーニングの受講、月次の経費精算等にかかる人件費や有給休暇、看護・介護休暇等はG&Aに含まれるのが一般的です。 G&Aコストは多すぎないことが望ましいですが、例えばチームビルディングやリーダー・マネージャーのトレーニング等が今後のチームの生産性に大きく影響すると判断した場合は、短期的にG&Aコストを投資するという戦略が考えられます。 営業利益 (Operating profit) 売上総利益からSG&A(販管費)を引いたものが営業利益です。 ここから営業外損益や特別損益、法人税を抜いたものが当期純利益となり、その会計期の会社全体の利益になります。 営業外損益には為替差損/差益や有価証券売却益、利息の支払いなどが含まれますが、一旦は営業利益まで意識しておいてもらえればOKです。 Jカーブで一定の成長期に入ったスタートアップや一般的な企業は、売上高や営業利益率を如何に高めるかが基本的なゲームになります。 ソフトウェア開発とPL PLの構造について理解を深めたところで、改めてソフトウェア開発者が意識するべきポイントを考えてみたいと思います。 事業インパクト よく聞く言葉ではありますが、事業インパクトとは何でしょう。定性的なもの、定量的なもの様々が考えられますが、わかりやすい表現の一つとしてPLの項目が利用できます。 例えばプロダクトや機能の開発によってどのくらいの売上が増加したかは、収益性分析によってある程度定量化することが可能です。 CSやOpsの作業効率の改善はCOGSや粗利率として表現することができます。 もちろんPL以外にもKPIを使った定量表現や、セキュリティの強度や採用優位性等の定性的な表現もありえますが、経営者・事業責任者と会話するうえで一番シンプルで説得力が高いのは会計の用語を使うことだと僕は考えています。 *1 もしも採用強化や離職率の低減といったインパクトを盛り込みたい場合は、採用にかかる成功報酬や人件費、オンボーディングコスト、関係構築コストといったものをG&Aコスト観点で織り込むといった方法も一つのアイデアだと思います。 また、事業インパクトとしては、これらのPL上の項目に対してどの程度の割合で影響があるかも重要なポイントです。 例えば「インフラ構成の改善によって500万円/月の改善が見込める」は効果の大きな改善だと思いますが、これがCOGSの1%なのか10%なのかでもインパクトは変わりますし、事業として人件費COGSが課題なのか、システムCOGSが課題なのかによっても大きく優先度判断が変わり得ます。 経営者や事業責任者と事業課題の認識を揃えることで、より大きな事業インパクトのある施策を生み出しやすくなるのではないかと思います。 (それはそれとしてコスト改善はやれるならやった方が良いですが) 投資対効果 (Return on Investment: ROI) 他にも、施策のインパクトを語る上で重要なキーワードとしてROIがあります。 ROIはその名の通り、「投資」に対してどれだけの「リターン(利益)」があったかを表す用語です。最終的な結果指標は利益ですが、利益が出るロジックとしては「COGSが減る」「R&Dコストが減る」等が考えられます。 例えば最近であればChatGPTやCopilotによって設計やコーディング、テストにかかる工数が削減され、同じものを作った場合でもAIツールを利用した方が開発工数が短くなることが期待できます。 これはつまり、ChatGPTやCopilotへの投資によってR&Dコストが低く抑えられるようになったと表現できます。 *2 具体的にどのくらいの効果が得られるかはPoCやベンチマーク、リサーチ会社のレポート活用等で工夫する必要がありますが、このように「いくらの投資で」「どういった見返りが得られるのか」をPLベースで説明できると、より説得力のある提案ができるようになるのではないかと思います。 インフラコスト 突然ですが、Development環境やStaging環境のインフラコストはCOGSとR&Dどちらに計上するのが正しいでしょうか？ また、A事業部とB事業部と横断プラットフォーム部がある場合のインフラコストはそれぞれどの事業部のコストとして計上するのが正しいでしょうか？ これらに決まった答えはなく、ビジネスモデルや会社の方針によって変わります。 恐らくインフラ寄りの方であれば、「今月の予算実績を集計するために、各事業(または各サービス)ごとのインフラコストを出してほしい」というお願いをされたことがあると思います。 会社や事業のフェイズによっては、それぞれの事業単位で収益の健全性を見たいという要求があります。そのため、インフラ構成の要件として環境やサービス単位でコスト集計ができることが重要です。 同一k8sクラスタで動いているサービスや、プラットフォームサービスのコスト等、どうしてもルールベースで按分するしかないものもありますが、GCPプロジェクトやAWSアカウントの分離、タグやラベルを活用することで、サービスや環境に基づいた柔軟なコスト集計を実現することができます。 会計要求に合わせてインフラ構成を後から変更するのは基本的に現実的ではないので、インフラの初期構築時にはぜひこういった会計処理のことを意識していただけると、会計エンジニアが泣いて喜びます。 単純にROIが説明しづらい施策はどうすればいいの？ 施策の効果説明としてPLを用いたアプローチをいくつかご紹介しましたが、依然としてソフトウェア開発にはPLだけでは効果が表現しづらい技術的チャレンジが存在します。 例えば「新しいプログラミング言語の導入」や「レガシーシステムのリアーキテクチャ」といったものが最たる例ではないでしょうか。 特に大きな改修を必要とするものは開発期間も長く、投資と回収が複数の会計期をまたがることになる上、成功の不確実性も高いです。 このような施策をうまく進めるためには、ROIの説明ももちろんですが、コミットメントや信頼といったものが大切です。本当にその施策が事業価値に繋がると信じるのであれば、丁寧にステークホルダーと会話を続けながら課題の言語化や実現方法の模索を進めることが、結果として近道になるのではないかと思います。 まとめ 少し長くなりましたが、PL上の項目の意味合いとソフトウェア開発の関係について、少しでも理解を深めていただけたら幸いです。 実際の現場で、KPIベースで話すべきか、PLベースで話すべきか、ミッションやバリューベースで話すべきかは組織のフェイズ、財務状況、ステークホルダーの好み、会社の文化によってそれぞれ異なりますが、PLをベースに会話できることはソフトウェア開発者としても一つの重要な武器になるのではないかと思います。 もし上長やステークホルダーとの議論が噛み合わないと思ったときは、まず事業上の課題の認識のすり合わせや問題提起から始めてみることをおすすめします。 We are Hiring CADDiは製造業全体を前進させ、世の中を変えていくためにもグローバルな企業を目指しています。 そのため、グローバルで共に戦える仲間を随時募集しています。 ご興味がある方はぜひ下記リンクからご応募ください。 caddi.com *1 : もちろん経営者や事業責任者の性格や好みにも依存します *2 : 開発工数だけではなく、テストコードの拡充による品質の向上、インシデント数の低下によるCOGSの低下、顧客満足度の向上等様々な効果が期待できますが、複合的な提案にするかシンプルなコスト訴求にするかは組織のフェイズやステークホルダーの専門性によって都度考える必要があります

はじめに 対象読者 主なキーワード 共通ID基盤プロジェクトについて なぜプロジェクトを開始したのか？ 共通ID基盤構築の要件 共通ID基盤の技術選定 認証基盤に関連する技術群 どの技術を使うべきか？ アーキテクチャの検討 隠れたサービス要件の発覚 サービスに求められる要件について OIDCで必須のOPへのリダイレクト OIDCとサービス要件の不一致 別の方法を探る 1. 主力プロダクトをOPとする案 2. サービスのドメインを統合する 3. サービスをコードレベルで統合する 終わりに はじめに スマートキャンプ株式会社京都開発拠点では、自社開発プロダクトであるSaaSマッチングプラットフォーム「 BOXIL SaaS 」とオンラインイベントサービス「 BOXIL EVENT CLOUD 」の間でアカウントを共有する共通ID基盤の開発を進めています。 この記事では、その開発過程でOpenID Connect（OIDC）の採用を検討した結果と得られた知見について解説します。 具体的には、共通ID基盤の開発過程を時系列で紹介し、OIDC採用の検討過程、ビジネス要件との折り合いをつけることが難しかったこと、およびOIDCを使わないケースも含めたシングルサインオンの代替案についても触れます。 対象読者 ID基盤を作る際に、OIDCを導入しようか迷っている人 かつOIDCの基本的なことは理解している人 主なキーワード BOXIL SaaS : SaaSマッチングサービス。主力プロダクト。 BOXIL EVENT CLOUD : ビジネスのための情報共有の場としてのオンラインイベントプラットフォーム。 OpenID Connect（OIDC） : 認証基盤としての最有力候補技術。 シングルサインオン（SSO）: 一つのID（アカウント情報）を入力するだけで、連携する他のサービスにもログインできる仕組み。 OpenID Provider（OP）：OIDCにおけるユーザー認証のサービスを提供するサーバーまたはプラットフォーム Relying Party（RP）：OIDCにおけるユーザーの認証情報を利用するサービスやアプリケーション 共通ID基盤プロジェクトについて なぜプロジェクトを開始したのか？ プロジェクトの対象サービスがBOXIL SaaSというサービスと、BOXIL EVENT CLOUDというサービスであることは冒頭にお伝えしました。 BOXIL SaaSとBOXIL EVENT CLOUDとは、別々のサービスではありますが、片方はSaaSを導入したい／提供したい企業向けのマッチング、もう片方はイベント開催を通してビジネス上の知見・つながりを提供しています。 ですのでターゲットとする顧客としてはある程度重なる部分もあります。 現状ではそれぞれ独自の認証システムを持っているので、ユーザーは各サービスで別々に登録する必要があり、サービス間のデータ連携もありません。一方のサービスに登録しているユーザーに対して、そのデータを活用したもう一方のサービスで便利な機能を提供するなどの施策を簡単に提案できない状況でした。 このような課題を解消するため、共通ID基盤の導入により、一度登録すれば複数のサービスでアカウントを共有できるようにするプロジェクトがスタートしました。 ここで現状におけるサービスの簡単な構成図をお見せしておきます。 それぞれのサービスがユーザー情報を独立して持ち、認証も別々に行なっていることがわかります。 認証の仕組み(Before) では現状を踏まえたうえで、要件をまとめていく次のステップに移ります。 共通ID基盤構築の要件 チームでは、ビジネスサイドのメンバーとも話を進め、共通基盤に求められる具体的な要件をまとめていきました。 要件をかいつまんで説明すると下記のような内容になります。 ドメインの異なる2サービス（BOXIL SaaS、BOXIL EVENT CLOUD）でIDを統合して利用できるようにする もともとユーザー属性の近いサービスであるため、IDの一元化によりサービス間での相互送客を狙いたい 会員情報の二重入力や更新の手間を省き、サービスのUXを向上したい 各サービスのデータを紐づけたうえで、データ分析やマーケティング活動に活用したい 属性の近い別のサービスを将来的に連携する際のID連携の基盤を作る 新規サービスにおいても、既存サービスのユーザーを低コストで連携できるようにしたい 本プロジェクトでは上記の要件を満たすべく、まずは関連する技術選定から始めていきました。 共通ID基盤の技術選定 認証基盤に関連する技術群 今回のように異なるドメインのサービス間でのSSOを実現する際に、関連技術をいくつかピックアップし検討していきました。 以下に主要な検討技術をピックアップして簡単に特徴を説明します。 OIDC OAuth2.0を拡張し、認証にも利用できるようにしたプロトコル IDトークンを用いて認証をして、UserInfoエンドポイントからユーザーのプロフィール情報を取得する 異なるドメインのサービス間でのSSOが実現できる データのやり取りはJSON形式で行なう OAuth2.0 認可のためのプロトコル（認証ではない） この仕様で認証を賄うには独自に拡張を行なう必要があるが、リソースサーバーから提供されるプロフィールAPIを用いての認証の方法には脆弱性があり、拡張の際にはセキュリティなどのリスクに特に気をつける必要がある データのやり取りはJSON形式で行なう SAML 異なるドメインのサービス間でSSOを実現できるプロトコル SAMLは独自に定義された認証規格であり、OIDCがOAuth 2.0に基づいているのとは対照的 SAMLはXML形式でデータをやり取りする 独自構築 規格には属さないものの、完全に独自で認証システムを設計する選択肢も存在します。この方法は、特定の要件に対してもっとも柔軟に対応できる点が強みです。しかし、OIDCなどセキュリティも考慮された規格とは異なり、セキュリティリスクも自分たちで考慮の上仕様を決める必要があるため、その点で難易度が高いと言えます。 さらに、この手法は既存のライブラリや参考資料が少ないため、構築と運用のコストが他の方法よりも高くなる可能性があります。 どの技術を使うべきか？ チームでは、先にまとめた既存規格の技術、独自認証などの特徴と、求められる要件を考慮したうえで検討した結果、今回の共通ID基盤プロジェクトにおいては第一候補としてOIDCを採用することになりました。 選定の際に考慮した点については下記の通りです。 社内のスキルセットとのマッチング OIDCはOAuth2.0の拡張であり、基本的なフローはOAuth2.0とほぼ同じであること 既存プロダクトではOAuth2.0の導入実績があり、社内で知見がある程度蓄積されていること 低い複雑性 SAMLよりもプロトコルがシンプルで、仕様自体の見通しが良いこと 走り出しから継続して検討をしながら進めていくような今回のプロジェクトには、シンプルであることがプラスで働くこと 将来的に新しいサービス連携することを考慮したときに、スピーディに連携できそうなこと セキュリティの考慮 IDトークンの署名・暗号化や、 PKCE （Proof Key for Code Exchange）など、多くのセキュリティ機能とベストプラクティスが組み込まれており、必要十分であること ライブラリの充実 標準化され多く利用されている規格であるため、既存のライブラリやツールのサポートが豊富で、設定例やドキュメントも充実していること 基盤のベースの技術としてOIDCを採用したので、それを前提としてシステム構成を考えていきます。 アーキテクチャの検討 次にOIDCを前提として、共通ID基盤を入れたときのサービス全体のアーキテクチャを検討しました。下記に簡略化した構成図を掲載します。 現状のシステム構成図は「 なぜプロジェクトを開始したのか？ 」の章を参照してください。大きく変わったところは下記です。 認証を担う機能を共通ID基盤として新たに構築する BOXIL SaaS、BOXIL EVENT CLOUDでそれぞれ持っていた認証の実装を、共通ID基盤のOIDC経由で行なう実装に置き換える。 各サービス上にあるユーザー情報のうち、認証に使う情報を中心に共通ID基盤に移す。（それ以外の多くのサービス固有のユーザー情報は据え置き） 認証の仕組み(After) OIDCの観点だと、BOXIL SaaS、BOXIL EVENT CLOUDの各サービスはそれぞれRPとなり、新しく作る共通ID基盤はOPとして振る舞う形になります。 隠れたサービス要件の発覚 チームでは、作ったアーキテクチャの想定を元に、実際にOIDCを使ったときに具体的にどのような画面遷移になるだろう？実際のUXはどうなるだろう？といったユーザー観点での調査を重ねて、ビジネスサイドとも話を進めていきました。 サービスに求められる要件について ところで、BOXIL SaaSでは、さまざまな施策を通じて会員の獲得効率（CVR）を最大限に高める戦略を採っています。たとえば、資料請求フォームの入力後に会員登録処理と並行してログインができるよう実装したり、EFO（Entry Form Optimization）によるUXの最適化に重点を置いています。 今回のプロジェクトでも、会員登録の手間を減らしてUXを向上したり、サービス間での相互送客を実現するなどの目的がありますが、実際問題としてはCVRを損なわないという前提条件下で考慮される必要があります。 ただ、この要件は事前に明文化できていたわけではなく、チーム間で明確に認識の形成ができずにプロジェクトが進行して、徐々に懸念が強く浮き彫りになってきたという感じでした。 OIDCで必須のOPへのリダイレクト OIDCの仕様の中にはいくつかの認証フローが定義されていますが、特に今回採用を予定していた認可コードフローにおいては、"OPへのリダイレクト"という仕様があります。 下記のシーケンス図をご覧ください。 シーケンス図 認証の開始時にRPであるBOXIL SaaSから、OPである共通ID基盤にリダイレクトされ、認証が完了した後にOPからRPに認可コード付きでリダイレクトされて戻ってくる流れがあることがわかります。 このリダイレクトはOIDCの仕様上重要で、RPとOP間の疎結合性を保つことで、安全に認可コードをRPに渡すことを実現しています。 OIDCとサービス要件の不一致 さて、前述したように、BOXIL SaaSとしては会員獲得におけるCVRに影響を与える変更は極力避けたい事情がありました。プロジェクトチームでは、OIDCのリダイレクト仕様がBOXIL SaaSのCVRにどのような影響を与えるかを慎重に考察しました。 結果、リダイレクトを入れることで会員登録やリード獲得のプロセスに影響が生じ、ユーザーが外部の認可エンドポイントへ移動することで、会員獲得の動線が分断されて、CVRやEFOによるユーザー動線の最適化にも悪影響を及ぼす懸念が出てきました。 それを避けるために、なんとかリダイレクトしつつも極力CVRに影響を与えない次善策を含め、調査と検討を重ねたのですが、決定的な策が提案できず、最終的には独立した共通ID基盤経由でOIDC認証をする構成を採用しない決断をしました。 高い自由度のUXを確保するために、OIDCのリダイレクト要件は今回のプロジェクトには合わないと判断したのです。 別の方法を探る では、前述した「リダイレクトしたくない」というビジネス要件と、「リダイレクトが必要」というOIDCの仕様を受けて、どういった意思決定をすべきでしょうか。 私たちが現状調査・検討してきた案をいくつかご紹介します。 BOXIL SaaSをOPとする案 サービスのドメインを統合する サービスをコードレベルで統合する なお、この記事を執筆時点では、目下、案の検討を進めている途中のため、どれを採用したのかは言及しません。どの案もUI/UXへの影響や、開発・保守運用工数への影響などなどトレードオフがあり影響度も大きいため、慎重に検討を進めていく必要があります。 また考えるうえでは、短期的なメリット、中長期的なメリットなど時系列も含めて議論が必要と考えています。 以下にそれぞれを簡単に紹介します。 1. 主力プロダクトをOPとする案 認証の仕組み(BOXIL SaaSをOPとする案) この案はOIDCの認証を管理するサーバー（マイクロサービス）を新規で開発・運用するのではなく、考慮すべきビジネス要件が多いBOXIL SaaSをOPとして振る舞わせ、BOXIL EVENT CLOUDはRPとしてそのエンドポイントを利用する形です。 そうすることでBOXIL SaaSでは従来の会員登録のフローを変更する必要がなくなるため、ネックだったリダイレクトの影響に対する懸念は考えなくて良くなります。 デメリットとしては、認証機能自体のBOXIL SaaSへの依存が強くなってしまうため、連携するサービスの負荷でBOXIL SaaSも影響を受けてしまったり、例えばBOXIL SaaSがクローズする際に連携サービスが影響を受ける可能性などがでてきてしまいます。 また、この案は一度しか使えず、今後連携するサービスでは通常のOIDCによるリダイレクトが強制される形になります。 以降の案はOIDCを使わない案です。 2. サービスのドメインを統合する 一方のサービスのコードベースを、もう片方のドメインに丸ごと移すやり方です。 認証の仕組み(サービスのドメインを統合する案) 例えば、BOXIL SaaSは現在 boxil.jp 、BOXIL EVENT CLOUDは boxil-event-cloud.jp でホスティングしていますが、これを boxil.jp 、 event.boxil.jp に変更すれば、サードパーティクッキーの制限がなくなります。 片方でログインして、もう片方のサービスとログインセッションを共有することも技術的に可能になります。 3. サービスをコードレベルで統合する これはできるケースが限られると思いますが、もし連携するサービスのビジネスドメインや会員属性が近く、数が多くない場合は、サービス自体を一つのコードベースに統合する案も考えられそうです。 認証の仕組み(アプリケーションをコードレベルで統合する) 当然ながら自由度は非常に高いですが、引越しする側のサービスについてゼロベースに近い開発が必要になるため、完了までにかかるコストや、統合にあたっての双方のデータスキーマの見直しなど、多岐にわたる検討が必要になります。 終わりに 本プロジェクトの開発過程では、技術選定だけでなく、ビジネス要件との整合性も重要であることが明らかになりました。OIDCは多くの場合に有効な技術ですが、それありきで進めるのではなくUXとビジネス要件をしっかりと両立させ、最適な技術選定と実装を広い視野で追求していく必要があることを今回学ぶことができました。 この記事が皆さまの参考になれば幸いです。