はじめに

小さな仕様変更のつもりが、大きな追加費用の話に発展してしまった。思い描いていたイメージと違う画面ができあがってきた。そんなすれ違いに、もどかしさを感じたことはありませんか？ 私たちも、「もっと柔軟に、一緒に考えられる開発のかたち」を模索してきました。
本記事では、変化に寄り添う開発パートナーでありたいという私たちの想いと、準委任契約に込めた想いをご紹介します。

一緒に考えるパートナーであるためには？

請負契約の現場でよく交わされる言葉

例1）機能追加の要望が出たとき
発注側（お客様）：「そういえば、検索結果にフィルターを追加できますよね？あれ、たしか最初の打ち合わせで話してたと思うんですが...」
開発側：「申し訳ありません。それはスコープ外ですね。要件定義書には含まれておりません。」
発注側：「えっ？最初から話してたと思うんですけど...。なんで反映されてないんですか？」
開発側：「正式な仕様としては合意されておらず、実装対象になっていないため、対応には追加費用が発生します。」

例2）軽微な修正のつもりで依頼したとき
発注側：「あと、ここの文言を少し変更して、ボタンの色も変えてもらえますか？デザインにちょっとこだわりたくて。」
開発側：「それは大幅な仕様変更です。デザインガイドラインからの逸脱になりますので、影響範囲を精査し、別途お見積りとなります。」
発注側：「えっ？ボタンの色を変えるだけですよ？そんなに大ごとですか？」
開発側：「スタイルガイドや他画面との整合性にも関わるため、慎重な対応が必要になります。」

例3）思っていたものと違う画面が出てきたとき
発注側：「あれ？この画面、ここのフローはもっと簡単になるはずじゃなかったでしたっけ？」
開発側：「そんな話、聞いてません、、、いただいた仕様に基づいて、その通りに作っています。」
発注側：「えぇ...たしかに言葉にはしてなかったかもしれないけど、流れ的に当然そうなると思ってました。」
開発側：「明文化されていない内容は基本的に対象外となります。」

システム開発の現場で、こんなやりとりに疲れた経験はありませんか？
こうした"すれ違い"とも言える冷たいコミュニケーションをせずに、開発することはできないのか？
そんな想いが私たちにはありました。

請負契約がもたらす"壁"

システム開発は、進めるうちに新たな課題や気づきが次々に生まれるものです。
しかし請負契約のもとでは、要件・納期・金額を最初に確定させるため、途中で仕様を変えるたびに、調整や費用の再検討が必要になります。

「最初に決めた通りに作る」ことと、「本当に必要なものを届ける」こと。
この間に生まれるズレに、私たちは違和感を抱くようになりました。
もっと自然な変化に柔軟に応え、最適なシステムをお客様と一緒に育てていきたい。
そんな想いが、大きくなっていきました。

お客様とチームでいたいから、準委任契約という選択を

システム開発を進める上で、「まずは請負契約で進めたい」というご要望をいただくことは少なくありません。ゴールや成果物を明確に決めてからスタートするスタイルは、安心感があり、プロジェクトの管理もしやすいと感じられるからだと思います。私たちも、請負契約ならではの安心感やメリットを十分に理解しています。

ただ、近年のシステム開発は、市場環境の変化が速くなり、ビジネスニーズやユーザー要求も常に変化しているため、プロジェクト開始後に要件やニーズが変わるケースがますます増えてきました。
最初に決めた仕様を守ること自体が目的になってしまい、「本当に今、必要なもの」とずれてしまう──そんなジレンマが起きる場面も、現場で見てきました。

そうした背景から、私たちが選んだのが 「準委任契約」 でした。

この契約形態では、あらかじめ決まった成果物に縛られることなく、必要な作業・工程そのものに対して対価が発生します。 つまり、変化に柔軟に対応できます。 請負契約のように、最初にすべてを決めてから始めるのではなく、都度、話し合いながら進めていくスタイルが特徴です。

とはいえ、ゴールへの責任感が揺らぐわけではありません。 私たちは、仕様変更や要件追加があった場合でも、プロジェクトの目的やお客様の本来のゴールを常に意識しながら対応を進めます。 単に作業をこなすのではなく、お客様と同じ目線で課題を解決することを目指して伴走します。

また、準委任契約では柔軟な対応が可能な一方で、プロジェクトの方向性がぶれないよう、定期的なチェックポイントや中間ゴールの設定を必ず行っています。
これにより、お客様と認識を合わせながら一歩ずつ進めることができ、進行中でも「今、正しい方向に向かっているか」を常に確認しながら開発を進められます。

準委任契約を導入することで、現場は大きく変わりました。 例えば、あるプロジェクトでは、当初要件が曖昧だったにもかかわらず、「まずは一緒に考えていきましょう」とスタートできました。
結果として、お客様自身も気づいていなかった課題やニーズを掘り起こすことができ、本当に必要とされるシステムにたどり着くことができました。 「仕様に含まれていないから...」ではなく、「まず相談する」ことができるようになり、 信頼を積み重ねながら、「共にゴールを創っていく」感覚が生まれました。

最近では、当初は「絶対に請負契約でないと進められない」というお声をいただいた企業様からも、最終的には「準委任契約でお願いします」と言われることが増えてきました。

準委任契約が生む、柔軟な開発と信頼の関係

準委任契約には、私たちが大切にする価値観と相性の良いポイントがたくさんあります。

柔軟に変化に対応できる

準委任契約の最大の強みは、「途中での変更」に柔軟に対応できることです。 要件の追加や修正も、都度話し合いながら、スピード感を持って反映できます。 「まず作ってみて、使ってみて、調整していく」という現代的な開発スタイルと相性が良く、お客様の"ひらめき"を最大限活かすことができます。

一緒にプロジェクトを育てる

請負契約だと、どうしても「発注者 vs 受注者」という関係になりがちです。 でも準委任契約では、同じチームの一員として、共通のゴールに向かって並走している感覚が生まれます。
実際に、あるお客様からは「仕様にないけど、相談したらすぐ一緒に考えてくれて先回りした提案ももらえた」という声もいただきました。

進捗が「見える化」されることで、同じ目線で前に進める

請負契約でも、進捗管理表や中間報告などを通じて、プロジェクトの状況を把握することは可能です。ただ、その多くは「成果物の完成に向けた節目ごとの報告」であり、日々の作業の流れや現場で起きている細かな変化までは伝わりづらいこともあります。

一方、準委任契約では、稼働状況や進捗を日報や定例ミーティングなどを通じてリアルタイムで共有する文化が根付きやすく、「どこに時間がかかっているか」「何に悩んでいるか」といった細かな情報まで、お互いが同じ目線で把握できる関係性が築かれます。

また、契約構造の違いも、プロジェクトへの関わり方に影響します。 請負契約では「成果物に対する対価」という性質上、ある程度お任せするスタンスになりやすい傾向があります。

準委任契約では「稼働時間に対する対価」であるため、お客様も「何に時間が使われているのか」「この進め方でよいか」など、日々の状況に対して自然と目を向けるようになります。 その結果、もしスケジュールが遅れそうな場合でも、「なぜそうなっているのか」「何を優先すべきか」といったことを事実に基づいてフラットに議論できるようになり、対立ではなく建設的な対話につながります。 進捗の"見える化"は、単なる報告のための手段ではなく、お互いの理解を深め、信頼関係を育てるプロセスそのものだと考えています。

信頼関係が深まる

何かを"お願い"するたびに費用の話になってしまうと、どうしても心理的な距離ができます。
でも準委任契約なら、「まず相談してみよう」と思っていただける関係を築くことができます。
お互いがフラットに意見を出し合えることで、自然と信頼関係が深まる。
それは、プロジェクト成功の大きな鍵になります。

エンジニアにとっても、作ることだけがゴールではなく、"お客様の課題を解決する"という本質的な価値に集中できるようになりました。

本当に寄り添える開発パートナーでありたい

私たちが準委任契約に込めているのは、「契約形態を変えること」そのものではありません。 大切なのは、"お客様の力になりたい"という想いを、どうやって実現するか。 そのためのひとつの手段として、私たちは準委任契約を選んでいます。

お客様のビジネスや現場に深く入り込み、ともに課題を見つけ、解決し、改善を重ねていく──。 そんな関係性こそが、私たちの理想です。 変化の多い時代だからこそ、契約にも柔軟性と信頼が求められると、私たちは感じています。

とはいえ、準委任契約がすべての案件に適しているわけではありません。

• 短期間・低コストで成果物を納品することが明確な案件
• スコープが完全に決まっていて、変更が発生しないことが前提の案件

こうしたケースでは、請負契約のほうが適していることもあります。 大事なのは、プロジェクトの性質に応じて、最適な契約形態を選ぶこと。 私たちは準委任契約を"万能の正解"とは捉えていません。 お客様にとっての最善策をご提案しております。

同じ方向を向き、変化を楽しみながら一緒にものづくりをしていく──
そんな出会いが生まれることを、心から願っています。

もし今、

• もっと柔軟に動いてくれる開発パートナーがほしい
• 仕様が固まっていなくても相談に乗ってほしい

そんな思いをお持ちでしたら、ぜひ一度お話ししてみませんか？契約形態は、あくまで関係づくりの"土台"です。 お客様とともに、信頼でつながるチームをつくっていけることを、私たちは何より大切にしています。

X（旧Twitter）・Facebookで定期的に情報発信しています！
Follow @acceluniverse

はじめに：受託開発はつらい？

「いつかは自社サービスで自由に開発がしたい」
「受託開発って納期に追われてしんどそう」
「裁量もやりがいもなさそう...」

そんなふうに思っていませんか？
最近は、SNSやイベントでも"自社サービス開発の魅力"が語られる場面が多く、「エンジニアとしてカッコいいキャリア＝自社サービスに関わること」といったイメージが強まっているように感じます。

でも、実は受託開発にもさまざまなスタイルがあり、その中には"やりたいこと"を実現できる環境もあります。
今回は、私たちが行っている受託開発のスタイルを通じて、「受託開発ってこういう形もあるんだ」という視点をお届けしたいと思います。

自社サービスの魅力とその現実

自社サービスの魅力は多くの方が語っているとおりだと思います。

• 自分のアイデアで新しい機能を提案できる
• 社会の課題解決に直結したサービスを提供できる
• 長期的に同じプロダクトを育てることができる
• 開発だけでなく、ユーザー視点やマーケティングにも関わることができる

確かに、こうした環境はエンジニアにとってやりがいがあり、非常に魅力的です。 ですが、実際にそうした仕事を担えるのは一部のメンバーだけということも、忘れてはならない現実です。 大規模なサービスになるほど組織が細分化され、担当できるのはほんの一部の機能や領域。 企画や技術選定に関わるポジションに就くには、長い時間とチャンスを待つ必要があります。
つまり、自社サービスであっても「やりたいこと」にすぐに関わることができるとは限らないのです。

受託開発の一般的なイメージ

一方で、「受託開発」と聞くと、どんなイメージを持たれるでしょうか？
おそらく、多くの方が次のようなイメージを思い浮かべるかもしれません。

• 下請けのような立場で、決められた仕様をただ作るだけ
• 常に納期に追われて、気持ちの余裕がない
• 技術選定の余地がなく、最新技術も取り入れにくい

確かに、そういった開発現場も存在します。
しかし、それは受託開発の「一部」でしかありません。
実は、受託開発にも多様な形があり、企業ごとにスタイルが全く違うのです。

AUCの受託開発のスタイル

私たちアクセルユニバース（以下、AUC）は、一般的な分類では"受託開発会社"に入りますが、実態は少し違います。
お客様一社一社の課題に合わせたオーダーメイドのシステム開発を行っており、仕様書通りに作るだけの受託開発ではありません。 それぞれのプロジェクトごとに「何をどう作るべきか」を共に考え、ゼロから設計し、育てていくスタイルを大切にしています。

私たちが手がけているのは「受託開発」ではなく、お客様とともに創り上げる「プロジェクト」だと考えています。

(1)一次請け90％以上の体制

お客様と直接契約しており、「何をどう作るか？」という段階から相談されることがほとんどです。
要件がすでに固まったものを受け取って作るのではなく、企画段階からエンジニアが関わる。これが私たちのスタイルです。

また、要件定義から設計・開発・テスト・運用までを一貫して担当する体制の中では、技術力に加えて、業務理解やお客様とのコミュニケーション力も求められます。 お客様と直接やり取りしながら課題を解決していくため、開発だけでなくビジネス視点も問われる環境です。「部分的に関わるだけ」ではなく、プロジェクトの最初から最後まで、自分の手で価値をつくりあげていけるのが特長です。

(2)準委任契約が中心＝納期に追われない

受託開発というと「納期地獄」のイメージがあるかもしれませんが、弊社の案件の多くは準委任契約です。
「月○時間稼働」という形でお客様と伴走するスタイルのため、無理なスケジュールで開発を詰め込むようなことは、基本的にありません。

(3)常駐なし、フルリモートも可能

すべて自社内で開発を行っており、お客様先で常駐して業務をすることはありません。プロジェクトはリモートで進行できる体制を整えており、働き方の自由度も高いのが特徴です。

さらに、フルリモート・フルフレックス制度を導入しており、ライフスタイルに合わせた柔軟な働き方が可能です。 2024年の実績では、一人あたりの平均残業時間はわずか月3.6時間です。
また、社内では約50％のメンバーが首都圏外に在住しフルリモートで勤務しています。全国どこからでも活躍できる環境を実現しています。

首都圏に在住するメンバーは、出社・在宅の働き方を自身のスタイルに合わせて選択できる体制を整えています。 働きやすさを保ちつつも、プロジェクトを通じて成長していけるような環境づくりを心がけています。

(4)多種多様な業種・技術に関わることができる

お客様の業界は、小売業、総合商社、製造など多岐にわたります。
その分、要件も開発環境も異なるため、常に新しい技術やアーキテクチャに触れられるチャンスがあります。

• Next.js / Nuxt3
• AWS / Azure / GCP
• Python / TypeScript / Go / Kotlin など

「いろんな言語・フレームワークに挑戦したい」「インフラも設計してみたい」そんな方には、むしろ最適な環境です。

"やりたいこと"ができる理由

弊社の受託開発では、「仕様通りに作る」だけでは終わりません。
「そもそもどんなシステムが必要なのか」から一緒に考えるフェーズに関わることができるため、技術的な提案や意思決定の余地がたくさんあります。

一次請けかつ要件定義から一気通貫で関わるスタイルだからこそ、お客様と対話しながら本質的な課題を見極め、技術の選定やアプローチの設計に関わることができます。

• お客様の業務を理解し、課題を言語化する
• システム構成や技術選定を提案する
• 開発・運用フローそのものを再設計する

こうした工程に関わることで、単なる"つくる人"ではなく、"共に考えるパートナー"として仕事を進めることができます。

幅広い業種や技術領域のプロジェクトに関わる中で、自ら学び、吸収する姿勢を大切にすることで、スキルの幅を広げるチャンスが豊富にあります。

• 「将来はテックリードを目指したい」
• 「幅広い技術を習得して、選ばれるエンジニアになりたい」
• 「現場を理解し、技術を武器に、お客様とチームをリードできるプロジェクトマネージャーになりたい」

そう思っている方には、まさに"やりたいこと"に出会えるフィールドです。

まとめ：選択肢を広げてみませんか？

自社サービスが魅力的なのは間違いありません。
ですが、自社サービスだけがやりがいのある開発ではないということも、少し感じていただけたでしょうか？

受託開発の中にも、「企画から関わる」「提案できる」「技術に挑戦できる」環境は確かに存在します。
私たちAUCは、そんな開発スタイルを実現している会社のひとつです。

転職やキャリアの選択肢を考えるとき、「受託開発＝つらい」という思い込みを、ほんの少し疑ってみてください。
そうすることで、自分にとって本当にフィットする働き方が見えてくるかもしれません。

▶ 気になる方はぜひこちらもチェックしてみてください！

• 社員インタビュー
  「自分らしく成長する」を叶えてくれる場所　大迫 拓馬 / ソフトウェアエンジニア

  未知への一歩から始まったAUCで描く 成長ストーリー　長森 礼音 / SREエンジニア

• 採用ページ
  新卒採用/ 中途採用/ 長期有給インターンシップ

X（旧Twitter）・Facebookで定期的に情報発信しています！
Follow @acceluniverse

1. 企業のシステム選びにおける選択肢
2. パッケージとオーダーメイド開発の比較
3. オーダーメイド開発で競争力を強化する最新アプローチ
4. オーダーメイド開発が向いている企業とは？
5. まとめ

1.企業のシステム選びにおける選択肢

近年、企業のデジタル変革が加速する中で、自社に最適なシステムを選定することが、競争力を左右する重要な要素となっています。企業がシステムを導入する際の選択肢として、大きく分けて「パッケージ※1」と「オーダーメイド開発」の2つがあります。

パッケージは、短期間で導入できる手軽さや初期コストの低さが魅力ですが、業務に完全にフィットしない場合もあります。

一方、オーダーメイド開発は、企業の独自性や成長戦略に応じた柔軟なシステムを構築できるメリットがありますが、その分コストや開発期間が課題となることもあります。

企業の成長フェーズやビジネス要件によって、どちらの選択肢が適しているのかは変わってきます。本記事では、それぞれの特徴やメリット・デメリットを比較し、オーダーメイド開発を活用して競争力を強化するアプローチについて解説します。

2.パッケージとオーダーメイド開発の比較

2-1. パッケージのメリット・デメリット

パッケージは、一般的にクラウドサービスや既存のソフトウェアとして提供されることが多く、迅速な導入と低コストが大きな利点です。しかし、業務プロセスとの適合度やカスタマイズの自由度に課題がある場合もあります。

メリット

• 導入スピードが速い：すでに完成されたシステムのため、短期間で利用を開始できる。
• 初期コストが低い：開発費用が不要であり、月額課金などの形でコストを抑えられる。
• 運用・保守の負担が少ない：ベンダーが管理・保守を行うため、自社のITリソースを節約できる。
• 最新技術の適用が容易：自動アップデートが提供されるため、常に最新の機能を利用可能。

デメリット

• カスタマイズ性の制限：業務に完全に適合しない可能性があり、要件を満たせない場合もある。
• データ管理の課題：機密データを外部のクラウドに保存するため、セキュリティやデータガバナンスの面でリスクが生じる。
• ランニングコストの増大：月額課金制のため、長期的に利用すると総コストが高くなることがある。
• 他システムとの連携が難しい：既存のシステムとの統合に制限があり、運用フローに制約が出る可能性がある。
• バージョンアップの度に追加コストが発生：バージョンアップ時にカスタマイズ部分の修正や、新機能利用・プラン変更・外部連携に伴う追加ライセンス費用が発生し、想定外のコストにつながることがある。

2-2. オーダーメイド開発のメリット・デメリット

オーダーメイド開発は、企業の業務プロセスに完全に適合するシステムを構築できるため、競争力の強化に貢献します。しかし、開発には時間とコストがかかり、運用・保守の負担も考慮する必要があります。

メリット

• 業務に最適化したシステム構築：企業独自の業務フローや要件に完全に適合したシステムを開発可能。
• 高い拡張性と柔軟性：将来的なビジネス拡大や業務変更に応じたシステムの拡張が容易。
• セキュリティの強化：自社環境でのデータ管理が可能なため、情報漏えいリスクを軽減できる。
• 他システムとのスムーズな連携：既存システムや外部ツールと柔軟に統合し、業務プロセスを最適化できる。

デメリット

• 開発コストが高い：ゼロから開発するため、初期投資が大きくなる。
• 導入までの期間が長い：要件定義、設計、開発、テストなどの工程を経るため、導入に時間がかかる。
• 運用・保守の負担が大きい：システムの管理・保守を自社で行う必要があり、ITリソースの確保が必要。
• 開発リスクがある：要件変更や開発遅延が発生する可能性があり、適切なプロジェクト管理が求められる。

3. オーダーメイド開発で競争力を強化する最新アプローチ

3-1. データ連携で業務を効率化

近年、多くの企業がデータドリブン経営を重視し、業務プロセスの最適化を進めています。
また、複数のSaaSを導入したものの、データが連携できずに手間が増えるという問題が発生しやすいという状況もよく耳にします。オーダーメイド開発では、社内外のデータを統合し、シームレスな連携を実現することで業務の効率化が可能です。

データ連携のポイント

異なるシステム間のデータ統合：ERP(Enterprise Resource Planning)、CRM(Customer Relationship Management）、BI(ビジネス・インテリジェンス)ツールなど複数のシステムを連携し、一元管理を可能にします。

• リアルタイムデータ処理：APIやETLツールを活用し、リアルタイムでデータを取得・分析する。
• データの可視化：ダッシュボードを活用して、業務のKPIをリアルタイムで確認できる環境を整備する。

データ連携を強化することで、意思決定のスピードを向上させ、業務の最適化が可能になります。

3-2. 連携したデータを活用し、生成AIで高度なデータ分析を実現

データ連携を活用することで、企業は生成AIを駆使した高度なデータ分析を実現できます。
生成AIは、膨大なデータセットから有益なパターンやトレンドを抽出し、意思決定の質を向上させる強力なツールとなります。

生成AIを活用したデータ分析のメリット

• 予測分析の高度化：市場動向や顧客行動を予測し、ビジネス戦略を最適化できる。
• 異常検知の強化：システム障害や不正行為の兆候を自動検出し、リスクを低減。
• 業務プロセスの自動化：データ入力やレポート作成などの作業を自動化し、効率を向上。
• パーソナライズされたサービス提供：顧客データを分析し、個別最適化されたマーケティング施策を実施。

これにより、企業は競争力を強化し、データドリブンな経営判断を行うことができます。

4. オーダーメイド開発が向いている企業とは？

向いている企業の特徴

• 独自の業務プロセスを持つ企業：標準的なパッケージでは対応できない業務を持つ企業。
• 競争優位性を高めたい企業：ITシステムを差別化要因として活用したい企業。
• 長期的な視点でIT投資を行う企業：初期コストは高いが、中長期的な運用コストを抑えたい企業。
• データを活用した意思決定を行いたい企業：業務データの分析やAI活用を積極的に推進したい企業。

導入に適したタイミング

• 事業拡大・新規事業立ち上げ時：ビジネスの拡張に合わせた最適なシステム構築が可能。
• 既存システムの老朽化・限界時：パッケージの制約が業務のボトルネックになっている場合。
• 業務効率化の必要性が高まった時：手作業の削減やデータ活用を強化したいタイミング。
• 競争優位性を確立したい時：市場での差別化戦略としてITを活用する必要がある場合。

実際の成功事例

事例1：製造業の生産管理システム刷新

ある製造業の企業では、パッケージのERPシステムを利用していましたが、工場ごとに異なる生産管理フローに対応できず、業務の効率が低下していました。そこでオーダーメイド開発による生産管理システムを導入。

結果

• 工場ごとの業務フローに最適化されたシステムで作業時間を20%削減。
• 在庫管理の精度向上により、材料の無駄を30%削減。
• 各工場のデータを統合し、経営層がリアルタイムで状況を把握可能に。

事例2：EC企業のデータドリブンマーケティング基盤を構築

急成長中のEC企業では、複数のパッケージツールを組み合わせたマーケティング分析を行っていましたが、データの分断が課題でした。そこでオーダーメイド開発によるデータドリブンマーケティング基盤を構築。

結果

• 顧客データを統合した分析基盤を構築。
• AIを活用した購買予測アルゴリズムを開発し、リピート率を15%向上。
• キャンペーン施策の効果測定を自動化し、マーケティング施策の最適化を実現。

5.まとめ

一品物だからこそ生まれる価値、オーダーメイド開発で競争力を最大化

企業のITシステム選定において、パッケージとオーダーメイド開発にはそれぞれのメリット・デメリットがあります。短期間で導入しやすいパッケージは、コストを抑えつつ標準化された機能を活用したい企業に適しています。一方で、オーダーメイド開発は、独自の業務プロセスに最適化したシステムを構築し、競争優位性を確立したい企業にとって有効な選択肢です。

特に、事業の成長に伴い標準的なシステムでは対応しきれなくなった場合や、より高度なデータ活用を推進する必要がある場合には、オーダーメイド開発の価値が高まります。実際に、製造業やEC業界では、オーダーメイドシステムの導入によって業務効率化や売上向上につながった成功事例が多数存在します。 自社の現状や将来のビジョンを見据えた上で、最適なITシステムを選定し、競争力の強化につなげていきましょう。

アクセルユニバースでは、こうした企業の課題に対し、「フルスクラッチによるオーダーメイド開発」はもちろんのこと、「既存パッケージ（SaaS）導入後の活用最大化」にも対応しています。 例えば、複数のSaaSを導入している企業では、各ツール間の連携不足により、同じデータを何度も入力する手間が発生したり、重複した業務プロセスがボトルネックになることがあります。

当社は、これらの課題に対して、SaaS間のスムーズなデータ連携や自動化の仕組みを提供し、反復作業を最小化しながら全体最適を実現するIT基盤の構築を支援しています。業務の現場レベルから経営判断に至るまで、企業全体の効率化と意思決定の迅速化を実現するために、最適なシステムアーキテクチャを一緒に考えていきましょう。 オーダーメイド開発か、パッケージの最適活用か----貴社の課題や状況に応じて、最良の答えをご提案します。

※1　本記事では、SaaSなどのクラウド型サービスを含めた既製システムを「パッケージ」としています。

X（旧Twitter）・Facebookで定期的に情報発信しています！
Follow @acceluniverse

1. はじめに
2. 「ゼロトラスト」の考え方を取り入れる
3. 設定ミスを防ぐ！インフラのコード化（IaC）を活用
4. 「監視」と「インシデント対応」の自動化を強化
5. セキュリティパッチの適用を自動化する
6. 社員のセキュリティ意識を高める
7. まとめ

1.はじめに

最近、「クラウドを導入したものの、セキュリティ運用が複雑になって管理が大変...」といったお悩みを耳にすることが増えました。クラウドの柔軟性や拡張性を活かしつつ、どうすればセキュリティリスクを最小限に抑えられるのでしょうか？

そこで今回は SRE（Site Reliability Engineering）の考え方を活用したセキュリティ運用の最適化 について、5つのポイントにまとめました。情報システム部やシステムを管理されている総務部の皆さまに役立つ内容になっていますので、ぜひチェックしてみてください。

2.「ゼロトラスト」の考え方を取り入れる

これまでの企業ネットワークでは、「社内ネットワーク＝安全」「外部＝危険」という境界型セキュリティの考え方が主流でした。

しかし、VPN で社内ネットワークに接続するだけで自由にシステムへアクセスできる環境では、攻撃者が VPN 認証さえ突破すれば、内部のデータや重要なシステムに簡単に侵入できてしまいます。

そこで注目されているのが、ゼロトラスト（Zero Trust）の考え方です。ゼロトラストでは、「何も信用しない（Never Trust、 Always Verify）」を前提に、社内外のすべてのアクセスを検証し、必要最低限​​の権限のみを付与することで、セキュリティリスクを極力抑えます。

ゼロトラストを実現する3つのポイント

ゼロトラストの考え方を企業のセキュリティ運用に取り入れるためには、認証・アクセス制御・権限管理の3つの要素を徹底することが重要です。

check①最小権限の原則（PoLP：Principle of Least Privilege）を徹底
➡ 必要最低限のアクセス権しか与えないことで、万が一の不正アクセス被害を抑えます。

check②多要素認証（MFA）の導入
➡ パスワード＋ワンタイムパスワードなど、複数の認証要素を組み合わせることでセキュリティ強化ができます。

check③端末や場所に応じたアクセス制御
➡ たとえば「日本国内の社用PCからのみアクセス可能」など、細かくルールを設定すると安心です。

ゼロトラストを意識することで、「誰でもどこからでもアクセスできる」リスクを最小限にできます。

※関連記事：VPNリスクの終焉とゼロトラスト時代のセキュリティ運用とは？

3. 設定ミスを防ぐ！インフラのコード化（IaC）を活用

クラウド環境では、設定のわずかなミスが大きなセキュリティリスクにつながることがあります。特に「うっかりパブリックに公開されていた...」といった事態は絶対に避けたいですよね。

そこでおすすめなのが Infrastructure as Code（IaC） を活用した運用です。

Infrastructure as Code（IaC）とは？

Infrastructure as Code（IaC）とは、クラウドのインフラ設定をコードとして管理し、自動的に構築・変更できる仕組みのことです。 クラウド環境では、サーバー・ネットワーク・ストレージなどのインフラを手動で設定するのではなく、プログラムコードとして行わなくても、環境構築の自動化と継続性を確保できます。

check①設定をコード化し、変更履歴を管理
➡ TerraformやAWS CloudFormationを使えば、「誰が」「いつ」「どんな変更をしたか」がすぐにわかるようになります。

check② 自動チェックを組み込み、設定ミスを防ぐ
➡ OPA（Open Policy Agent）やCheckovなどのツールを活用すると、セキュリティポリシーに違反する設定を事前に検出できます。

人手によるミスを減らし、セキュリティを一貫して守れる仕組みを作ることが大切です。

4. 「監視」と「インシデント対応」の自動化を強化

「セキュリティインシデントは起こらないのが理想」ですが、 現実的にはどんなに対策をしても100％防ぐことはできません。 だからこそ、「早く気づいて、すぐに対応する」仕組みが必要です。

check①SEIM（Security Information and Event Management）の活用
➡ AWS GuardDuty、Google Chronicle、Splunkなどを使ってログを集約し、異常を検知できます。

check②ログを一元管理し、自動分析を導入
➡ ELK StackやCloudWatch Logsを活用すると、異常な動きをすぐにキャッチできます。

check③SOAR（Security Orchestration, Automation and Response）の導入
➡ セキュリティインシデントが発生したら、事前に設定したルールに基づいて自動で対処します。（たとえば特定のIPアドレスを即ブロックするなど）

SREの視点では 「インシデントは発生するもの」と捉え、素早く検知し対応できる仕組み を整えることがポイントです。

5. セキュリティパッチの適用を自動化する

クラウド環境では、OSやミドルウェアの脆弱性が次々と発見されます。セキュリティパッチを適用しないと、 攻撃の標的になりやすくなる ので要注意です。

check①自動パッチ適用の仕組みを構築
➡ AWS Systems Manager Patch ManagerやGoogle OS Patch Managementを活用すると、自動でパッチ適用が可能です。

check②脆弱性スキャンツールを活用
➡ Amazon InspectorやAqua Securityを使えば、脆弱性のあるコンポーネントを事前にチェックできます。

「忙しくて対応できなかった...」を防ぐためにも、自動化を取り入れることが重要です！

6. 社員のセキュリティ意識を高める

どんなに技術的な対策を講じても、 人的ミスやフィッシング詐欺による情報漏洩が原因でセキュリティ事故が発生するケースは少なくありません。

check①定期的なセキュリティ研修を実施
➡ フィッシング詐欺の実例を紹介しながら、「自分ごと」として学べる場を作るのが効果的です。

check②セキュリティSLO（Service Level Objective）を設定
➡ たとえば「全社のパスワード変更率90%以上」など、具体的な目標を掲げることで意識向上につながります。

check③インシデント対応の訓練を実施
➡ 「もしも社内で情報漏洩が起きたら？」といったシナリオを想定し、実際に対応できるかシミュレーションを行うとよいでしょう。

結局のところ、 セキュリティは「仕組み」だけでなく「人の意識」も大きく関わるもの。全員で意識を高めていくことが大切です。

7.まとめ

クラウド環境でのセキュリティ運用を最適化するために、SREの視点から 5つのポイント をご紹介しました。

■ ゼロトラストの導入で、不正アクセスを防ぐ
■ 設定ミスを防ぐために、IaCを活用する
■ セキュリティ監視を自動化し、迅速に対応する
■ セキュリティパッチ適用を自動化し、リスクを最小限に
■ 社員のセキュリティ意識を高め、人的ミスを防ぐ

「自社のセキュリティ運用、もっと最適化したい！」という方は、ぜひSREのアプローチを取り入れてみてください。不安な点や、「自社の環境でも導入・運用が可能なのか？」といった疑問があれば、どうぞお気軽にアクセルユニバースまでご相談ください。SREの導入や最適な運用体制づくりを、専門のチームが丁寧にサポートいたします。

X（旧Twitter）・Facebookで定期的に情報発信しています！
Follow @acceluniverse

1. はじめに
2. VPNに潜む"突破される前提"のリスク
3. ゼロトラストとは？ 「信用せず、常に検証する」
4. ゼロトラスト実現の3つの技術要素
5. 専用製品がなくても始められるゼロトラスト
6. ゼロトラストがもたらす運用の最適化
7. まとめ：ゼロトラストは「思想」であり、今すぐ始められる改革

1.はじめに

近年、リモートワークやクラウド活用が急速に進んだことで、企業のセキュリティモデルも大きな転換期を迎えています。従来の「社内ネットワーク＝安全」という前提のもと構築された境界型セキュリティは、もはや万能ではありません。
特に注目されているのが「ゼロトラスト」という新たなセキュリティモデルです。本記事では、VPNのリスクを再認識しつつ、ゼロトラストをいかに実践的かつ段階的に導入できるかについて、日々の運用に直結する視点で掘り下げていきます。

2.VPNに潜む"突破される前提"のリスク

VPNは、長らくテレワーク環境でのセキュリティ手段として広く使われてきました。しかし、VPN装置の脆弱性を突いた不正アクセスは、企業や公的機関でも後を絶ちません。
たとえば2020年、ある官公庁ではVPN経由で1年以上にわたり不正アクセスが行われ、内部システムが侵害されました。また、某大手ゲーム会社では、古いVPN機器が踏み台にされ社内ネットワークへの侵入を許してしまい、顧客情報流出という深刻なインシデントに発展しています。
VPNが破られると、まるで「社内に鍵のない裏口ができた」状態になり、攻撃者は内部のどこまでも自由に移動できてしまいます。この「一度突破されたら終わり」という構造こそが、VPN最大の弱点なのです。

3.ゼロトラストとは？ 「信用せず、常に検証する」

ゼロトラストは、「ネットワークの内側にいるから安全」という発想を根本から覆すモデルです。
その基本原則は非常にシンプルで、"Never Trust, Always Verify（決して信頼せず、常に検証する）" です。
ネットワークの内外を問わず、すべてのアクセスに対して認証・監視・制御を行うことで、内部での不正アクセスや"ラテラルムーブメント（横方向の攻撃の横展開）"を防ぐことができます。
重要なのは、「検証された結果としてのみアクセスが許可される」ことです。
これにより、「VPNで入ることができれば、すべての社内リソースに触れられる」といったリスクを根本から排除できます。

4.ゼロトラスト実現の3つの技術要素

ゼロトラストを実現するには、以下の3つの技術を柱として導入することが効果的です。

4-1. 多要素認証（MFA）

パスワードに加え、スマホ認証・生体認証・ワンタイムパスワード（OTP）などを組み合わせた認証方式です。
たとえパスワードが漏洩しても、他の要素がなければ突破できません。
特にVPNやクラウドアプリケーションへのアクセスには、最低限MFAを必須化すべきです。

4-2. マイクロセグメンテーション

ネットワークをアプリケーション単位・業務単位で細かく分割し、セグメント間の通信を厳格に制御します。万が一侵入されても攻撃の横展開を防げるため、ダメージを局所化できます。

4-3. 最小権限の原則（Least Privilege）

ユーザーやデバイスに業務上本当に必要なアクセス権のみを与える設計思想です。過剰な権限は脆弱性を生みます。これを徹底することで、万一の内部不正や誤操作にも強くなります。

5.専用製品がなくても始められるゼロトラスト

「ゼロトラスト＝高額なソリューション導入が必要」と思われがちですが、実際には既存環境で工夫しながら段階的に取り組むことが可能です。

• VPN＋MFAの導入から
  既存VPNや社内アプリケーションに、スマホ認証アプリ（Google Authenticator等）によるOTP認証を組み合わせることで、MFAをすぐに実装できます。

• ACL(Access Control List)やVLAN(Virtual Local Area Network)による論理分離
  ファイアウォールやスイッチの設定を見直し、部署・業務単位で通信を分離しましょう。マイクロセグメンテーションの簡易版として有効です。

• 権限棚卸しとIAMの活用
  特権アカウントの整理、不要な共有アカウントの廃止を徹底し、IAMを活用した最小権限の実現を図りましょう。あわせて、SSO基盤を整備することで、アクセス管理の一元化とユーザー利便性の両立も可能になります。

6.ゼロトラストがもたらす運用の最適化

ゼロトラストの導入は、単にセキュリティを強化するだけではありません。
セキュリティ運用そのものを「効率化」するという側面も持ち合わせています。

• アクセス制御の一元管理により、ポリシーの散在や重複を排除

• 統合ログ監視による可視性の向上と、インシデント対応の迅速化

• 同一ポリシー適用により、社内外でのルールのばらつきが解消

• 管理対象の削減により、IT部門の負担が軽減

これにより、人的ミスの削減、コスト圧縮、そしてIT担当者の工数確保につながります。

7.まとめ：ゼロトラストは「思想」であり、今すぐ始められる改革

ゼロトラストは、単なるセキュリティ製品ではなく「思想」と「戦略」です。まずは、VPN＋ID/パスワードの限界を正しく認識するところから始めましょう。
そしてMFAやネットワーク分離、権限整理といった今あるリソースでできることから一歩ずつ取り入れることで、リスクを大幅に減らし、運用も効率化できます。
「社内だから信頼する」という思い込みを捨て、「誰であっても、常に検証する」という新しい常識をチーム全体に浸透させていくことが、次世代のセキュリティ体制構築への第一歩となります。

X（旧Twitter）・Facebookで定期的に情報発信しています！
Follow @acceluniverse

1. はじめに
2. SREが向いているシステムの具体例
3. SREの効果を引き出すための技術的な要件
4. SREが効果を発揮する環境の整備
5. 導入事例：ある企業システムへのSRE適用例
6. まとめ

1.はじめに

クラウド環境の最適化を検討されている方が、SRE（Site Reliability Engineering）について情報収集をされる際、どのようなシステムが向いており、どんな条件下で最大の効果を発揮するのかを理解することは効果的です。本記事では、システムよりの具体例や技術的観点を交えて、「SREが適したシステム」と「効果を引き出すポイント」を詳しく解説します。

2.SREが向いているシステムの具体例

2-1.高可用性が必須な業務基幹システム

企業の中核を担う基幹システムは、業務の停止が直接的な損失や信頼の低下につながるため、SREの手法を取り入れることで信頼性を向上させられます。

・ERPシステム

販売管理、在庫管理、財務会計などを一元管理するERPシステムは、停止すると事業運営全体に影響を及ぼします。SREでは、システムダウンを未然に防ぐためのモニタリングや予測分析を導入し、ダウンタイムを最小化します。

・顧客管理システム（CRM）

クラウド型CRMシステムやオンプレミスCRMは、営業やカスタマーサポートの効率化に重要です。ここでのSLO設定（例: サーバ応答時間95%以内に100ms）やエラーバジェットの活用は、ユーザー満足度を高める鍵となります。

2-2. ミッションクリティカルなシステム

特に外部ユーザーや顧客が直接利用するシステムでは、障害がブランドや収益に影響を与えるため、SREの価値が大きく発揮されます。

・オンライン決済システム

決済処理では、1秒の遅延やエラーが信用損失につながります。SREでは、冗長構成や継続的な負荷テストを通じて高い可用性を確保します。

・物流システム

配送トラッキングや倉庫管理システムでは、リアルタイム性が重要です。分散システムの監視や障害発生時の迅速な切り替えをSREのアプローチで実現できます。

2-3. クラウドネイティブなシステム

クラウド技術を採用している場合、SREの手法は特に効果的です。

・コンテナオーケストレーション

Kubernetesなどのオーケストレーションツールを使用している場合、SREによる自動化が効果を発揮します。Podのスケールアウト/スケールインやフェイルオーバーの最適化がその一例です。

・サーバレスアーキテクチャ

サーバレス環境（例: AWS Lambda、Google Cloud Functions）では、オンデマンドでスケールする仕組みがあるため、SREによるモニタリングやパフォーマンス最適化が重要です。

3.SREの効果を引き出すための技術的な要件

3-1.明確なSLO/SLIの設定

SREの導入は、信頼性目標（SLO: Service Level Objective）が明確であるほど効果を発揮します。

SLO/SLI設定の具体例

・応答時間

Webアプリの応答時間を「95%のリクエストが200ms以下」と設定し、これをSLIで定量的にモニタリング。

・エラー率

APIリクエストの成功率を99.95%以上に保つ目標を設定し、これを監視ツールで追跡。

・ダウンタイム

月間許容ダウンタイムを「43.2分以内」（99.9%稼働）と設定し、エラーバジェットに基づいて適切な運用を実現。

3-2.モニタリングとアラートの強化

システムの信頼性を向上させるには、リアルタイムのモニタリングと自動アラートの整備が必要です。

使用可能なツール例

・インフラ監視

Prometheus、Zabbix、Datadogなどを活用し、CPU使用率やディスクI/Oを監視。

・アプリケーション監視

New RelicやAppDynamicsでトランザクション応答時間を可視化。

・ログ管理

ElasticsearchやSplunkでエラーログの集中管理と迅速な検索。

3-3. 自動化の推進

SREの効果を引き出すには、運用タスクを極力自動化することが重要です。

・自動デプロイ

CI/CDツール（例: Jenkins、GitLab CI）を使い、デプロイメントの迅速化とエラー削減を実現。

・リソース管理

Infrastructure as Code（例: Terraform、Ansible）でクラウドリソースの一元管理を行い、変更のトレーサビリティを確保。

・異常検知の自動化

AI/MLを活用した異常検知（例: DatadogのAnomaly Detection）で、潜在的な問題を早期に特定。

4. SREが効果を発揮する環境の整備

4-1.文化とプロセスの改革

SREは単なる技術ではなく、文化改革でもあります。システム企画部門が率先して以下を推進することが重要です。

・開発と運用の連携（DevOps）

システムダウンは顧客の信頼を損ない、ブランドイメージに悪影響を与えます。SREがシステムの安定稼働を支えることで、顧客離れのリスクを最小限に抑えられます。

・障害を許容する文化

「障害ゼロ」ではなく、エラーバジェットを活用し、許容範囲内での失敗を容認する仕組みを導入します。

4-2.段階的導入のすすめ

SREを全社的に導入する前に、次のような段階的なアプローチを取ることを推奨します。

・パイロットプロジェクトを設定

特に影響度の高いシステムや新規プロジェクトに限定してSREの実験的導入を行います。

・成功事例の展開

成果をもとに他のシステムへ展開し、組織全体での運用改善を目指します。

4-3.コストとROIの評価

SREの導入には初期投資が必要です。システム企画担当者としては、コストと効果のバランスを見極めることが大切です。

主なコスト要因:

・ツールライセンス

・エンジニアのトレーニング

・文化改革に必要な時間とリソース

投資効果の測定例

・障害発生時の復旧時間（MTTR: Mean Time to Recovery）の短縮。

・予定外のダウンタイムの減少による業務への影響削減。

・顧客満足度や信頼性向上による利益拡大。

5. 導入事例：ある企業システムへのSRE適用例

背景

ある製造業の企業では、クラウド上に顧客注文管理システムを構築していました。しかし、頻繁に発生するサーバ負荷問題とダウンタイムにより、顧客クレームが急増していました。

対応内容

1.SLOの定義

「95%のリクエストを1秒以内に処理する」という目標を設定。

2.監視とアラートの導入

Datadogでシステム全体をリアルタイムで監視し、CPUスパイク時にアラートを発生。

3.スケーリングの自動化

Kubernetesを利用して、トラフィック増加時にコンテナを自動スケール。

結果

・ダウンタイムが月間2時間から10分以下に減少。

・顧客満足度が15%向上。

・システム運用コストが10%削減。

6. まとめ

SREは特定の条件下で大きな効果を発揮するアプローチですが、すべてのシステムに適用すべきとは限りません。自社システムの特徴を分析し、SREの導入が適切かどうかを慎重に判断する必要があります。 リスクの少ないはじめ方として、パイロットプロジェクトを設定し、段階的にSREの導入を進めることで、リスクを抑えながら効果を最大化できます。

X（旧Twitter）・Facebookで定期的に情報発信しています！
Follow @acceluniverse

1. はじめに
2. エラーバジェット（Error Budget）：開発スピードと信頼性のバランス
3. ポストモーテム（Postmortem）：障害から学ぶ文化
4. トイル（Toil）：非効率な運用作業を削減する
5. まとめ

1.はじめに

日々進化するデジタルサービスの世界では、システムの安定性と開発スピードのバランスを取ることが求められます。しかし、現場のエンジニアの皆さまは、「システムの信頼性を確保しながら、どうやってスピーディに新機能をリリースできるのか？」というジレンマを抱えているのではないでしょうか。

そんな課題を解決するために生まれたのが「SRE（Site Reliability Engineering）」というアプローチです。本記事では、SREの実践に欠かせない3つのキーワード「エラーバジェット」「ポストモーテム」「トイル」を取り上げ、それぞれの意味と活用法をわかりやすく解説します。

開発チームと運用チームが円滑に連携し、より良いサービスを提供するためのヒントとして、ぜひご一読ください。

2.エラーバジェット(Error Budget)：開発スピードと信頼性のバランス

エラーバジェットとは？

エラーバジェットとは、GoogleのSREチームが導入した概念で、SLO（Service Level Objective）を基に「どの程度の障害が許容されるか」を数値化したものです（出典: O'Reilly『Site Reliability Engineering』）。この考え方により、開発チームは安全な範囲で新機能をリリースでき、信頼性とイノベーションのバランスを取ることが可能になります。

事例：エラーバジェットの活用によるデプロイ最適化

あるクラウドサービス企業では、「99.95%の可用性」をSLOとして設定し、それを超えない範囲で開発を進める仕組みを導入しました。この仕組み（エラーバジェット）を活用することで以下のような運用が可能になります。

• SLOが安全な範囲内では積極的に新機能をリリース
• 障害が発生し、エラーバジェットが枯渇するとデプロイを制限し品質向上に注力

このアプローチにより、開発チームと運用チームは共通の指標を持ち、デプロイのリスクを定量化しながらバランスの取れた開発サイクルを実現できます。

注意すべき点

エラーバジェットをうまく活用しないと、

• 障害が発生しているのに開発を優先してしまう
• 逆に慎重になりすぎて、開発スピードが落ちる

GoogleのSREチームは、「エラーバジェットは計画的に活用することが重要であり、完全になくすことを目標にするのではない」と述べています（出典: 『Site Reliability Engineering』）。つまり、信頼性を確保しつつ、エラーバジェットを最大限活用することで、開発のスピードと安定性の最適なバランスを維持することが求められます。

3.ポストモーテム(Postmortem) : 障害から学ぶ文化

ポストモーテムとは？

ポストモーテムは、システム障害発生後に実施する詳細な分析プロセスであり、GoogleのSREチームによって確立されました。このプロセスの目的は、「誰がミスをしたか」ではなく、「なぜミスが起こったのか」を理解し、再発防止のための対策を講じることです（出典: O'Reilly『Site Reliability Engineering』）。

事例：ポストモーテムの導入による障害対応の改善

あるeコマース企業では、過去に大規模なシステム障害を経験しました。この障害は、データベースの負荷増大と適切なスケーリング対策の不足が原因で発生しました。復旧には数時間を要し、多くのユーザーがアクセスできない状況となり、顧客満足度にも悪影響を及ぼしました。

この経験を踏まえ、同社ではポストモーテムの文化を導入し、以下の取り組みを実施しました。

• すべての重大な障害について詳細なレポートを作成
• 障害の根本原因を特定し、システム改善につなげる
• 関係者全員で共有し、今後の運用改善に活かす

この取り組みにより、同社の障害対応プロセスは大幅に向上し、類似の問題が発生する頻度が減少しました。また、ポストモーテムの実施を通じて、技術的な改善だけでなく、チーム全体の障害対応スキルの向上にもつながりました。

Googleは、ポストモーテムを「技術的な進化を加速させるための手段」と位置づけており、単なる問題報告ではなく、組織全体での学習と改善を目的とすることが重要だと強調しています。組織的にポストモーテムを実施し、継続的に改善を積み重ねることが、より信頼性の高いシステム運用につながるのです。

注意すべき点

ポストモーテムを有効に機能させるには、

• 「責任追及」ではなく「学びの場」として運用する
• 根本原因を明確にし、対策を具体的に定める

4.トイル(Toil) : 非効率な運用作業を削減する

トイルとは？

Googleの定義によると、トイルとは「手作業が多く、反復的で、自動化可能な運用作業」を指します。SREの基本理念のひとつに「トイルの削減」があり、エンジニアがより価値のある作業に集中できるようにすることが求められます（出典: O'Reilly『The Site Reliability Workbook』）。

事例：トイル削減による運用の効率化

あるWebサービス企業では、システム監視のアラート対応がエンジニアにとって大きな負担となっていました。頻繁に発生するアラートへの対応に多くの時間を取られ、本来注力すべき開発業務に影響が出ていたのです。

そこで、同社は以下の取り組みを実施しました。

• 繰り返し発生するアラートの自動対応スクリプトを作成
• ログ分析の自動化を導入し、手作業を削減
• 定期的なメンテナンス作業を自動化

これらの取り組みにより、エンジニアの手作業が大幅に削減され、より価値のある業務に集中できるようになりました。

この手法はGoogleのSREチームでも採用されており、Googleは「SREは運用作業の50%以上をトイルの削減に使うべき」と推奨しています。つまり、SREの役割は単なるシステム管理ではなく、運用の自動化と効率化を進めることで、信頼性の高いサービスを維持しながら開発のスピードを向上させることにあります。

注意すべき点

トイル削減を効果的に進めるには、

• 「単なる自動化」ではなく、本質的な業務改善を目指す
• 過剰な自動化によるシステムの複雑化を避ける
• SLO（サービスレベル目標）とのバランスを取る
• チーム全体での合意を形成する

5.まとめ

SREの現場では、「エラーバジェット」「ポストモーテム」「トイル」といった概念が、システムの安定性と開発の柔軟性を支える重要な要素として機能しています。

• エラーバジェットを活用することで、開発スピードと安定性のバランスを最適化
• ポストモーテムを実施することで、障害対応の質を向上させ、継続的な改善を促進
• トイルを削減することで、エンジニアの生産性を向上させ、より価値のある作業に集中可能に

これらの概念をうまく組み合わせることで、信頼性の高いシステム運用を実現し、開発スピードを維持することができます。アクセルユニバースでは、これらの手法を活用し、システムの安定性を最大化するソリューションを提供しています。ぜひ、貴社のSRE戦略にもご活用ください。

X（旧Twitter）・Facebookで定期的に情報発信しています！
Follow @acceluniverse

1. はじめに
2. 信頼できるSRE業者の特徴
3. SRE業者選定時の注意点
4. まとめ

1.はじめに

近年、システムの安定性と運用効率を向上させるためにSRE（Site Reliability Engineering）を導入する企業が増えています。しかし、SREの導入には専門知識と経験が必要であり、適切な業者を選定することが成功の鍵を握ります。本記事では、SRE導入において信頼できる業者の選び方と注意すべきポイントを解説します。

2.信頼できるSRE業者の特徴

2-1. 豊富な実績と専門知識

SREはシステムの可用性や信頼性を高めるためのエンジニアリング手法であり、経験豊富な業者を選ぶことが重要です。過去の導入実績や成功事例を確認し、特定の業界やシステムにおけるノウハウを持っているかを見極めましょう。

2-2. 自社の課題に合わせた提案ができる

単にSREの原則を適用するのではなく、企業ごとの運用課題に応じたカスタマイズができる業者が望ましいです。初期のコンサルティングで具体的な課題を共有し、どのような施策を提案してくれるか確認しましょう。

2-3. 生成AIなど最新技術の活用

SREでは自動化が重要な要素の一つです。最新の技術を活用し、モニタリングや障害対応の自動化を推進できる業者を選ぶことで、運用負荷を軽減できます。

2-4. SLA（サービスレベルアグリーメント）の明確化

業者の信頼性を判断する上で、提供されるSLAが明確かどうかを確認することが重要です。どの程度の可用性や復旧時間が保証されているのかを事前にチェックし、自社の求める水準と合致しているか検討しましょう。

2-5. セキュリティとコンプライアンス対応

SREの導入においては、セキュリティ対策も不可欠です。業者が適切なセキュリティポリシーを持っているか、また、ISO27001などの認証を取得しているかを確認することで、安全な運用を実現できます。

3.SRE業者選定時の注意点

3-1. 価格だけで判断しない

SREは単なるアウトソーシングではなく、長期的なパートナーシップが求められます。安価な業者を選ぶと、必要なスキルやサポートが不足する可能性があるため、コストだけでなくサービス内容を総合的に評価しましょう。

3-2. 内製化支援の有無

将来的にSREを自社内で運用したい場合、業者が内製化を支援してくれるかも重要なポイントです。ドキュメントの提供や社内エンジニアへのトレーニングを実施してくれる業者を選ぶと、よりスムーズな移行が可能になります。

3-3. 既存システムとの親和性

業者が提案するツールやプロセスが、自社の既存システムと適合するかを確認しましょう。例えば、既存の監視ツールと連携可能か、導入に伴うシステム変更の影響はどの程度かなどを事前に検討することが大切です。

3-4. 継続的な改善提案ができるか

SREは一度導入して終わりではなく、継続的な改善が求められます。業者が定期的なレビューやパフォーマンス分析を行い、改善策を提案してくれるかを確認することで、長期的な運用の質を向上させることができます。

4.まとめ

SRE導入において信頼できる業者を選ぶには、実績や提案力、最新技術の活用、セキュリティ対応などを総合的に判断することが重要です。単なる外注ではなく、長期的なパートナーとして共に成長できる業者を選ぶことで、より効果的なSRE運用が実現できます。

アクセルユニバースではお客様ごとの当初は見えていなかった課題も含め、それぞれのニーズに合致したSREを実現しています。また、生成AIを活用したSRE運用を提供し、障害予測や自動復旧、業界ごとの最適なSRE戦略を提案しています。SRE導入を検討している企業は、ぜひアクセルユニバースのサービスも参考にしてみてください。

SREの導入を成功させるためには、適切な業者選びが欠かせません。慎重に業者を選定し、自社に最適なSRE運用を実現しましょう。

X（旧Twitter）・Facebookで定期的に情報発信しています！
Follow @acceluniverse

1. はじめに
2. SLA、SLO、SLIの定義と相互関係
3. SLA、SLO、SLIが連携して品質管理を実現する流れ
4. これらの連携がSREにおいて重要な理由
5. SLA、SLO、SLIの考え方を練習しよう
6. まとめ

1.はじめに

SRE（Site Reliability Engineering）は、Googleが提唱した運用手法で、システムやサービスの安定性と信頼性を高め、サービス停止や障害を防ぐことで顧客にとって高品質な体験を提供することを目的としています。その中で、SLA（Service Level Agreement）、SLO（Service Level Objective）、SLI（Service Level Indicator） の3つは、品質管理を支える重要な柱となっています。それぞれが異なる役割を持ちながら密接に関連し合い、SREの実践において欠かせない要素です。これらについて、ピザ配達サービスと電車運行サービスを例に、一緒に理解を深めていきましょう。

2.SLA、SLO、SLIの定義と相互関係

SLA、SLO、SLI の定義を押さえ、ピザ配達サービスの事例で具体的に考えてみましょう。

2-1.SLA（Service Level Agreement: サービスレベル契約）

SLAは、サービス提供者と利用者（顧客）との間で交わされる契約です。具体的には、サービスがどのように提供されるかを明示し、顧客に対して「どの程度信頼できるのか」を示します。

目的

サービス提供者は提供すべきサービスレベルを明確にし、利用者は受け取るサービスの品質を理解することができるため。

ピザ配達サービスの例

ピザチェーン店が「90%以上の注文を30分以内にお届けします」と顧客に約束する。

この「30分以内に90%以上の注文を届ける」という約束がSLAです。これにより、顧客は「自分の注文が確実に時間内に届く可能性が高い」という具体的な期待を持つことができます。同時に、ピザチェーン店にとっては、サービスの信頼性を顧客に示すことで、競合他社との差別化を図り、リピーターの獲得につなげる重要な要素となります。例えば、配達が30分を超えるケースが10%を超えると、SLAの達成が困難になります。その場合、運用を見直す必要があると判断できます。このように、SLAは顧客との約束であると同時に、サービス提供者自身が信頼性を維持・向上させるための目安ともなるのです。

2-2.SLO（Service Level Objective: サービスレベル目標）

SLOは、サービス提供者がSLAを守るために内部で設定する目標値です。これは具体的な基準であり、達成することでSLAを実現します。

目的

内部で達成すべき品質目標を設定し、運用方針を明確化する。

ピザ配達サービスの例

配達スタッフが「95%以上の注文を25分以内に届ける」という目標を設定する。

SLAを守るには、少し厳しめの内部目標（SLO）を設ける必要があります。これは、予期せぬトラブルや運用上のばらつきに備えるためです。例えばピザ配達サービスでは、悪天候や交通渋滞、注文の集中など、配達時間が遅れてしまう要因が発生することがあります。これらの影響を考慮し、SLOを「95%以上の注文を25分以内に届ける」といった厳しめの基準に設定することで、運用に余裕を持たせ、万が一の事態にもSLAが守られる確率を高めることができるようにしています。

また、SLOは単なる目標ではなく、運用チーム全体の努力の指針となるものです。SLOを明確にすることで、調理や配達のプロセスの見直し、配達員の配置の最適化、ルート計画の改善など、チーム全体が具体的な改善策に取り組みやすくなります。このように、SLOはSLAを達成するための「現実的かつ挑戦的な基準」として、サービス運用の質を向上させる重要な役割を果たしています。

2-3.SLI（Service Level Indicator: サービスレベル指標）

SLIは、サービスの状態を測定するための具体的なデータや数値です。このデータをもとに、SLAやSLOの達成状況を確認します。

目的

サービスの品質を数値で把握し、問題点を明確にする。

ピザ配達サービスの例

実際に注文が配達されるまでの時間を件数で割った平均配達時間や25分以内の配達成功率、25分超えの遅延率を算出する。

このデータは、SLOが達成されているかを判断するための根拠として重要です。もしSLI（例えば25分以内の配達率）が「95%」を下回った場合、配達が遅れた注文の具体的な原因を分析することで、運用上の問題点を明確にできます。例えば特定の時間帯やエリア、配達手段によって遅延が多い場合、それに対応した改善策を講じることが可能です。

また、SLIは単なる記録ではなく、サービスの改善に直接つながるデータです。例えば、配達成功率のデータを継続的にモニタリングすることで、運用の改善が進んでいるかを確認できます。さらに、SLIを複数の指標で測定する（例: 配達成功率、平均配達時間、配達温度の適正率など）ことで、サービスの品質を多面的に把握でき、顧客体験をより向上させるためのヒントを得ることができます。SLIはサービスの現状を「見える化」し、継続的に品質向上を支える重要な役割を担っています。

3.SLA、SLO、SLIが連携して品質管理を実現する流れ

結果をもとに継続的改善を実施

SLIのデータがSLO（目標）を下回っている場合、原因を特定し改善施策を実行します。これにより、SLA（顧客との約束）を守り続ける仕組みが実現します。

例

・配達エリアが広範囲にわたり、一部の遠距離配達が25分以内に間に合わない。

　→配達エリアを再定義し、範囲を縮小。遠距離の注文は別店舗に割り振る。

・配達ルートの最適化不足

　→地域ごとの渋滞情報をリアルタイムで共有し、配達ルートを柔軟に変更できる仕組みを整備。

このようにSLAを達成できるように継続的改善を行います。

4.これらの連携がSREにおいて重要な理由

4-1.信頼性の向上

SLAを守ることで、顧客にとってサービスの信頼性が高まります。また、SLOを目標に運用を管理し、SLIを測定し続けることで、サービスの品質を継続的に向上させることができます。

4-2. トラブルの早期発見と対応

SLIを定期的にモニタリングすることで、SLOの目標を下回る兆候をいち早く察知できます。これにより、SLAを破る可能性のあるトラブルを未然に防ぐことが可能です。

4-3. 顧客満足度とビジネス成長の両立

SLA、SLO、SLIを活用することで、顧客が求める品質を維持しながら、サービス提供者にとっても効率的な運用が実現します。このバランスが取れることで、顧客満足度が向上し、ビジネスの成長にもつながります。

5.SLA、SLO、SLIの考え方を練習しよう

ピザ配達サービスの事例を通じて基本概念を学びました。それではこの知識を応用して、電車運行サービスにおけるSLA、SLO、SLIを一緒に考えてみましょう。ピザ配達サービスと電車運行サービスの違いに注目しながらどのように適用されるのかを整理していきます。

5-1. 電車運行サービスにおけるSLA

電車の場合、「時間通りに運行されること」 や 「大きな遅延が発生しないこと」 が乗客の期待になると考えられます。この点をふまえ、電車運行サービスにおけるSLAを考えてみましょう。

さて、以下のSLAを考えてみましたが、皆さんはどのようなSLAを考えたでしょうか？

例:電車運行サービスのSLA

(1)平日の通勤ラッシュ時（朝7時～9時）、運行遅延率を5%未満に抑えます。

(2)30分以上の遅延発生率を1%未満に抑えます。

(3)運行中止時、15分以内に代替交通手段を提供し、適用対象の乗客へ電子クーポンを発行する。

考えてみよう①

SLAを設定する際、ピザ配達サービスと電車運行サービスでは、それぞれ何に気をつける必要があるでしょうか？

この2つのサービスでは、顧客の期待や求められる品質保証の内容が異なります。

ピザ配達は個々の顧客に迅速なサービスを提供することが最優先されるのに対し、電車運行は多くの乗客に対する安定した輸送の維持が目的となるため、SLAの性質や補償の内容が大きく異なります。

5-2.電車運行サービスにおけるSLO

SLOは、SLAで約束した基準を守るために、鉄道会社が内部で設定する具体的な目標値です。SLOは、運行管理チームや運転士、システム運営チームが共有する「実現可能で挑戦的な基準」として機能します。皆さんは上記のSLAに対して、どんなSLOを考えますか？

さて、以下のSLOを考えましたが、皆さんはどのようなSLOを考えたでしょうか？

例:電車運行サービスのSLO

(1)平日の通勤ラッシュ時（朝7時～9時）、運行遅延率を3%以下に維持する。

(2)30分以上の遅延発生率を0.5%以下に抑える。

(3)運行中止時、15分以内に振替輸送を提供し、適用対象の乗客へ電子クーポンを発行する。

考えてみよう②

電車運行サービスのSLOでは何を重視して目標を設定することが考えられるでしょうか？候補は様々ありますが、上記の3つのSLOでは何を重視しているのか考えてみましょう。

上から順番に、平日通勤ラッシュ時の定時運行の維持、大規模遅延の抑制、サービス継続性と緊急時対応と考えられます。

5-3. 電車運行サービスにおけるSLI

SLIは、SLOの達成状況を確認するための測定データです。鉄道会社は、運行状況を数値で記録し、どの程度SLOを守れているかを継続的にモニタリングします。これにより、SLAが達成されているかどうかを判断できます。上記のSLOに対しては、以下のSLIが考えられます。

例:電車運行サービスのSLI

(1)通勤ラッシュ時の運行遅延率

例）朝のラッシュ時に200本の電車が運行され、そのうち6本が5分以上遅延

→ 遅延率 = (6 ÷ 200) × 100 = 3.0%（SLO達成）

(2)30分以上の遅延発生率

例）1日1000本の電車のうち、4本が30分以上遅延

→ 遅延発生率 = (4 ÷ 1000) × 100 = 0.4%（SLO達成）

(3)振替輸送手配完了時間

例） 1か月間で3回の運行中止が発生し、対応完了時間が9分・8分・10分

→ 平均 = 9分（SLO達成）

例えば、運行管理システムでは、全電車の出発時刻と到着時刻を記録して、運行遅延率や運行遅延発生率を計測します。このSLIデータを基にどの程度SLOが達成され、結果としてSLAが守られているかを把握できます。

5-4.SLA、SLO、SLIが連携して電車運行を支える仕組み

これらの3つは、それぞれ異なる役割を持ちながらも、緊密に連携して機能します。

・SLA : 乗客に対する明確な約束

・SLO : その約束を守るための内部目標

・SLI : 目標達成状況を確認するための指標

電車運行サービスでは、多くの乗客が予定どおりに移動できるよう、定時運行・大規模遅延の防止・運行中止時の対応 といった要素が求められます。そのために、SLA、SLO、SLIが連携し、運行の品質を維持・向上させる役割を果たします。

ただし、電車の運行においては「安全性」「コスト最適化」など、様々な要素を考慮しながらバランスを取る必要があります。どの指標を重視するかは、サービス内容や提供者の方針によって異なります。

例） 安全性を最優先する場合

→ 遅延よりも、保守・点検の頻度を増やし、安全基準を強化する。

例）コストを最適化する場合

→ 遅延が多少発生しても、運行本数を削減し、効率的な運行を重視する。

このように、SLA、SLO、SLIの設定はサービスの特性によって異なり、それぞれの目的に応じた最適な指標を選ぶことが重要です。

6.まとめ

SLA、SLO、SLIは、サービスの品質を維持し、信頼性を高めるために欠かせない基本概念です。それぞれの役割を正しく理解し活用することで、トラブルを未然に防ぎ顧客の期待を超えるサービスを提供できるようになります。これまで、ピザ配達サービスや電車運行サービスの例を通じて、SLA、SLO、SLIがどのように品質管理に活用されるかを考えてきました。

SREはこれらの概念を土台に、システムやサービスの安定性を高めるアプローチを提供します。ピザ配達サービスや電車運行サービスの事例で考えてきたように、「顧客への信頼」を「数値と目標」に落とし込み、それを「データで実現」する仕組みを作ります。

システム運用に対しSREを導入することで、次のようなメリットを実現できます。

・サービスのトラブル発生率を低下させ、信頼性向上。

・明確な目標とデータ測定に基づく運用の効率化。

・顧客や社内ユーザーからの信頼を得られるシステムの提供。

SLA、SLO、SLIを活用する第一歩として、現在運用しているシステムの「目標（SLO）」と「測定指標（SLI）」を明確にしてみてください。それに基づいて「どんな約束（SLA）を実現するべきか」を考えることで、SREの考え方を実践的に取り入れることができます。

X（旧Twitter）・Facebookで定期的に情報発信しています！
Follow @acceluniverse

1. はじめに
2. AWS Compute Optimizerとは？
3. 対象リソースについて
4. AWS Compute Optimizerの採用メリット
5. AWS Compute Optimizerの採用デメリット
6. 実装ステップ：AWS Compute Optimizerを有効化する方法
7. AWS Compute Optimizerの導入で次の一歩を踏み出そう

1.はじめに

AWSのリソースコストを削減したいと考えていても、「会社のアカウント情報を第三者に見せるのはちょっと...」と不安に感じる方は多いと思われます。そこで安心して始められるコスト最適化の第一歩として、AWS Compute Optimizerをご紹介します。このツールは、専門知識がなくてもAWSのリソース利用状況を可視化し、最適化案を提案してくれる頼れる存在です。今回の記事では、このCompute Optimizerの仕組みや具体的なメリット、注意点を分かりやすくお伝えします。さらに、記事の最後ではコスト削減施策を次のステージに進めるための実践的なステップもご紹介しますので、ぜひ最後までご覧ください。

2.AWS Compute Optimizerとは？

AWS Compute Optimizerは、AWSリソースの設定と使用率メトリクスを分析し、最適なリソースサイズを提案するサービスです。このツールを使えば、現在使用中のリソースが過剰なスペックを持つ、または逆にスペック不足でパフォーマンスに影響を与えているかを簡単に判断できます。

主な特徴は以下の通りです。

AWS Compute Optimizerは無料プランと有料プランがあり、それぞれ異なるデータ分析期間をサポートします。

・無料プラン : 過去14日間のデータ分析

・有料プラン : 過去90日間の詳細データ分析（料金はリソース1時間あたり0.0003360215USD）

3.対象リソースについて

AWS Compute Optimizerでは、最適化の推奨事項を提供する対象が決まっています。対象となるのは、以下8個の主要リソースです。（2025年1月時点）

1. Amazon EC2 インスタンス

2. Amazon EC2 Auto Scaling グループ

3. Amazon EBS ボリューム

4. AWS Lambda 関数

5. Amazon ECS on Fargate サービス

6. 商用ソフトウェアライセンス

7. Amazon RDS インスタンス

8. Amazon RDS ストレージ

ただし、推奨事項を得るためには、2つ注意点があります。それについては、後の5. AWS Compute Optimizerの採用デメリットで詳しく触れたいと思います。

4.AWS Compute Optimizerの採用メリット

AWS Compute Optimizerを活用すると、単なるコスト削減にとどまらず、パフォーマンスの向上や運用の効率化といった幅広いメリットが得られます。「効率よくAWSリソースを使いたいけれど、何から始めればいいか分からない...」そんなお悩みを抱えている方にとって、最適なツールとなっています。それでは、Compute Optimizerを導入することで得られる主なメリットをご紹介します。

4-1.大幅なコスト削減

AWS Compute Optimizerは、リソースの使用状況を徹底的に分析し、過剰なスペックでコストがかさんでいる場合や、リソースを使いすぎている具体的な状況を教えてくれます。その結果、リソースの最適化を行うことで、AWSコストを最大25%削減することが可能です。例えば、普段気づきにくいオーバープロビジョンされたEC2インスタンスや、実はもっと低コストなストレージオプションで十分なEBSボリュームなど、目からウロコの気づきが得られるかもしれません。

4-2.パフォーマンスの最適化

「スペックが足りなくて処理が遅い」「逆にオーバースペックで無駄が多い」など、運用現場でよくある課題を正確に分析し、最適なスペックやサイズを提案してくれます。

4-3.迅速な導入

AWS Compute Optimizerの魅力の一つは、なんといってもすぐに使えるという手軽さです。AWS Management Consoleで有効化するだけで、レコメンデーションが自動生成され、すぐに最適化案を確認することができます。特別なセットアップやトレーニングも必要なく、まさに「今すぐ始められる」ツールです。AWSの利用経験が豊富な方はもちろん、初めて最適化に取り組む方でも直感的に使える設計になっています。

4-4.エンジニアの工数削減

これまでリソース最適化といえば、エンジニアが膨大な使用率データを分析し、最適なリソースサイズを手作業で見つけ出す必要がありました。Compute Optimizerは、こうした煩雑な作業を自動化します。エンジニアは最適化のためのデータ解析に時間を割く必要がなくなり、本来注力すべきプロジェクトや改善活動に集中することが可能です。結果的に、チーム全体の生産性を向上させることができるだけでなく、運用コストも削減できるという、一石二鳥のメリットを提供してくれます。

5.AWS Compute Optimizerの採用デメリット

どんなに便利なツールにも、効果的に活用するためには理解しておくべき制約があります。AWS Compute Optimizerも例外ではありません。このツールを導入する際に注意したい点を以下にまとめました。

5-1.対象サービスが限定的

AWS Compute Optimizerは、Amazon EC2やEBS、RDSなどの主要なリソースには対応していますが、すべてのAWSサービスを対象にしているわけではありません。たとえば、Amazon S3やDynamoDBなど、重要ながらも対象外となるリソースがあります。そのため、Compute Optimizerだけでは網羅的な最適化が難しい場合があり、場合によっては他のツール（AWS Trusted AdvisorやCost Explorer、Compute Savings Plans）との組み合わせや追加の手動作業が必要になります。

5-2.使用条件がある

Compute Optimizerのレコメンデーションを得るには、リソースが一定の条件を満たしている必要があります。例えば、最低でも過去14日間のメトリクスデータが収集されていることが前提となります。そのため、新しく作成したばかりのリソースや、使用頻度の低いリソースでは、具体的な提案が得られない場合があります。より詳細な分析を行う場合は、最大90日間のメトリクスデータを収集して実施する有料プランとなります。 こうした条件を理解しておくことで、Compute Optimizerの利用効果を最大化できるでしょう。

6.実装ステップ：AWS Compute Optimizerを有効化する方法

AWS Compute Optimizerは、手軽に有効化でき、導入後すぐにリソース最適化の提案を受け取ることが可能です。「具体的な手順が分からなくて不安...」という方のために、実際の画面を使った動画もご用意しましたので、ぜひそちらも参考にしてみてください。

以下では、Compute Optimizerを有効化し、実際にレコメンデーションを適用するまでのステップを簡単に解説します！

1.Compute Optimizerを有効化

AWS Management Consoleで「AWS Compute Optimizer」を検索し、有効化ボタンをクリック。

2.対象リソースを確認

自身の環境で分析対象となるリソース（EC2、EBSなど）を確認し、使用状況メトリクスが十分に収集されているかチェック。

3.ダッシュボードで結果を確認

推奨事項をダッシュボード上で確認し、最適化されたリソースに変更。

4.レコメンデーションの適用

提案された設定をもとに、リソースサイズや設定を調整。

7.AWS Compute Optimizerの導入で次の一歩を踏み出そう

AWS Compute Optimizerを利用することで、リソースのパフォーマンスを向上させながらコスト削減が実現できます。特に、自動化された分析と推奨事項は、運用コストを削減しつつ効率的なリソース利用をサポートしてくれる強力な味方です。

しかし、Compute Optimizerがカバーする範囲は限定的であり、一部のAWSリソースや環境における最適化はサポート外となる場合があります。

そのような網羅できない部分や、より高度な最適化の余地がある場合は、専門家のアドバイスを受けることが理想的です。アクセルユニバースでは、AWSアカウント全体を見渡して包括的なコスト削減を支援するAWSコスト削減チェックリストを提供しています。このチェックリストでは、Compute Optimizerでは対応できない領域もカバーし、さらに具体的で効果的な施策を実現できる内容が含まれています。

AWSのリソース利用をもっと最適化したい方や、現状のコスト削減施策を次の段階に進めたい方は、ぜひ以下のリンクをご覧ください。

AWSコスト削減を叶える18個のチェック項目

コスト最適化を効率的に進めたい方は、お気軽にアクセルユニバースにご相談ください！

X（旧Twitter）・Facebookで定期的に情報発信しています！
Follow @acceluniverse

1. 背景
2. 原因調査
3. 解決策
4. 結果

1.背景

AWSを使用する多くの企業にとって、Amazon S3（Simple Storage Service）は最も利用されるストレージサービスの一つです。S3は、スケーラブルで信頼性が高く、データを安全に保存できるため非常に人気があります。しかし、使い方によってはストレージコストが膨らみ、毎月の予算を圧迫する原因にもなります。私たちAUCでは、SRE活動の一環としてAWSのコスト適正化を進めており、特にAmazon S3のコスト削減に焦点を当てました。

私たちがAmazon S3のコストを削減する上で直面した課題は、以下の点に集約されました。

• データストレージが急激に増加し、不要なデータが放置されている。
• データのライフサイクルポリシーが適切に設定されていないため、古いデータが自動削除されていない。
• ストレージクラスを見直していないため、アクセス頻度の低いデータが高コストのストレージクラスに残っている。
• データ転送の方法が最適化されていないため、予想外の転送料金が発生している。

これらの課題に対処するため、S3のコスト削減を図るための原因調査と最適化を実施しました。

この記事では、Amazon S3のコスト削減に向けた原因調査から解決策までのプロセスを具体的に記録します。

2.原因調査

まず、S3コストの内訳を確認するために、AWS Cost Explorerを活用してコスト分析を行いました。Amazon S3のコストは主に以下の2つの要素に分かれます。

• データストレージ料金：保存されているデータ量に応じて発生するコスト。
• データ転送料金：データをインターネットまたは他のAWSサービスへ転送する際に発生するコスト。

私たちの調査結果では、コストが急激に増加している主な原因は、ストレージクラスの選択ミスとデータライフサイクルの適切な管理が行われていなかったことにありました。また、転送コストが予想以上に高くなっていることも確認されました。以下、詳細な分析を進めました。

2-1.不要なデータの放置

長期間アクセスされていないデータが大量にS3バケットに保存されており、これがストレージコストを大幅に押し上げていました。具体的には、あるプロジェクトで使用されていたログデータやバックアップファイルが自動削除されることなく数年間にわたって保存され続けていたのです。

2-2.ストレージクラスの最適化不足

Amazon S3には、アクセス頻度に応じた複数のストレージクラスがあります。アクセス頻度が高いデータは「S3標準（Standard）」に保存されるべきですが、長期間アクセスされないアーカイブデータやバックアップデータに関しては「S3 Infrequent Access」や「S3 Glacier」などの低コストのクラスに移行すべきです。しかし、これが実施されていないために、全データがS3標準クラスに保存され、高いコストが発生していました。

2-3.データ転送の最適化不足

私たちの分析によると、EC2インスタンスからS3へのデータ転送が、VPCエンドポイントを使用せずに行われており、結果としてインターネット経由でデータが転送されていました。この設定ミスにより、不要なデータ転送料金が発生していました。

3.解決策

私たちは、以下のアプローチでS3のコスト削減を実現しました。

3-1.データライフサイクルポリシーの設定

まず、Amazon S3のデータライフサイクルポリシーを設定しました。これにより、特定期間が過ぎたデータを自動的にアーカイブする、あるいは削除することで、不要なデータが永続的に保存されないようにしました。例えば、アクセスされなくなってから90日を経過したデータは「S3 Glacier」に移動し、1年間アクセスがなかったデータは自動削除するように設定しました。

• S3 Lifecycle Rules：特定のオブジェクトを指定期間後に低コストのストレージクラスに移行する、または削除するポリシーを適用。

これにより、アーカイブデータや古いバックアップデータが適切に管理され、ストレージコストを削減することができました。

3-2.ストレージクラスの見直し

次に、すべてのS3バケットに保存されているデータのアクセス頻度を分析し、ストレージクラスの見直しを行いました。アクセス頻度の低いデータは、「S3 Infrequent Access」または「S3 Glacier」に移行することで、ストレージ料金を大幅に削減しました。

• S3 Standard：頻繁にアクセスされるデータ。
• S3 Infrequent Access：アクセス頻度が低いが必要なデータ。
• S3 Glacier：アーカイブデータ。

また、今後は新しいデータが自動的に適切なストレージクラスに保存されるように設定を行い、運用管理の負担を軽減しました。

3-3.VPCエンドポイントの導入

私たちは、EC2インスタンスとS3間のデータ転送を最適化するために、VPCエンドポイントを導入しました。VPCエンドポイントを利用することで、インターネットを介さずにVPC内部で直接データ転送を行うことができ、データ転送料金を大幅に削減することができました。

• VPCエンドポイント（Gatewayタイプ）：S3との通信をインターネットを介さずに行うことで、データ転送料金を削減。

VPCエンドポイントの利用により、データ転送料金を最大で80％削減することに成功しました。

3-4.S3インテリジェントティアリングの利用

さらに、S3インテリジェントティアリングという機能を活用しました。これにより、アクセスパターンに基づいて自動的にストレージクラスを最適化し、手動での移行作業を減らしました。インテリジェントティアリングは、データのアクセス頻度が減少した際に自動的に低コストのストレージクラスに移行してくれるため、長期間にわたってストレージコストの削減に寄与します。

4.結果

これらの最適化施策により下記の成果を得られました。

4-1.データライフサイクルポリシーの設定によるコスト削減

前提条件

• 東京リージョン
• 保存されているデータ量：10TB（10,240GB）
• データのアクセス頻度は低く、90日後にほとんどアクセスされなくなる

アプローチ

• 90日後に「S3 Standard」から「S3 Glacier」にデータを移行
• 年間データを保持後、削除。

コスト計算

• S3 Standard: 0.023USD/GB/月

→10,240GB × 0.023USD × 3か月 = 706.56USD

• S3 Glacier Flexible Retrieval: 0.0045USD/GB/月

→10,240GB × 0.0045USD × 9か月 = 414.72USD

合計: 706.56USD + 414.72USD = 1,121.28USD/年

削減前のコスト

もし全データが「S3 Standard」に保存されていた場合 : 10,240GB × 0.023USD × 12か月 = 2,826.24USD/年

削減効果

1,121.28USD/年 vs 2,826.24USD/年 → 約1,705USDの削減（約60%の削減）

4-2.ストレージクラスの見直しによるコスト削減

前提条件

• 東京リージョン
• 10TBのデータのうち、頻繁にアクセスされるデータは40％（4TB）、残り60％（6TB）は低頻度

アプローチ

• 頻繁にアクセスされるデータ（4TB）を「S3 Standard」に保持
• 低頻度のデータ（6TB）を「S3 Infrequent Access」に移行

コスト計算

• S3 Standard: 0.023USD/GB/月

→4,096GB × 0.023USD × 12か月 = 1,130.496USD/年

• S3 Standard Infrequent Access: 0.0138USD/GB/月

→6,144GB × 0.0138USD × 12か月 = 1,017.4464USD/年

合計: 1,130.496USD + 1,017.4464USD = 2,147.9424USD/年

削減前のコスト

すべて「S3 Standard」に保存されていた場合 : 10,240GB × 0.023USD × 12か月 = 2,826.24USD/年

削減効果

2,147.9424USD/年 vs 2,826.24USD/年 → 約678USDの削減（約24％の削減）

4-3.VPCエンドポイントの導入によるデータ転送料金の削減

前提条件

• 東京リージョン
• 毎月、10TBのデータをEC2からS3に転送
• 現在は、インターネット (NAT Gateway) 経由で転送しているため、データ転送料金、およびNAT Gateway配置料金が発生している

アプローチ

• VPCエンドポイント（Gatewayタイプ）を導入し、インターネット (NAT Gateway) 経由の転送を排除

コスト計算

VPCエンドポイントデータ転送料金 : 0USD

VPCエンドポイント利用料金 : 0USD

削減前のコスト

• NAT Gatewayデータ転送料金:0.062USD/GB/月

→ 10,240GB × 0.062USD × 12か月 = 7,618.56USD/年

• NAT Gateway配置料金:0.062USD/時

→ 0.062USD × 8760h = 543.12USD/年

合計: 7,618.56USD + 543.12USD = 8161.68USD/年

削減効果

0USD/年 vs 8161.68USD/年 → 8,162USDの削減（100％の削減）

4-4.S3インテリジェントティアリングの利用によるコスト削減

前提条件

• 東京リージョン
• 保存データ：10TB（10,240GB）
• オブジェクト : 1,000件
• データアクセスパターン：最初の3か月は頻繁にアクセスされるが、それ以降はほとんどアクセスされない

アプローチ

• 「S3 Standard」ではなく「S3 Intelligent Tiering」を使用
• アクセスパターンに基づいて自動的に低コストのストレージクラスに移行

コスト計算

• S3 Intelligent Tiering：最初の3か月は「S3 Standard」相当、以降は低頻度アクセスストレージに移行

• 最初の3か月

Frequent Access Tier : 0.025USD/GB/月 → 10,240GB × 0.025USD × 3か月 = 768USD

• 残りの9か月

Infrequent Access Tier : 0.0138USD/GB/月 → 10,240GB × 0.0138USD × 9か月 = 1,271.808USD

• オブジェクト1,000件あたりのモニタリング・オートメーション料金 : 0.0025USD/月

0.0025USD × 12か月 = 0.03USD/年

合計: 768USD + 1,271.808USD + 0.03USD = 2,039.838USD/年

削減前のコスト

もし全データが「S3 Standard」に保存されていた場合 : 10,240GB × 0.023USD × 12か月 = 2,826.24USD/年

削減効果

2,039.838USD/年 vs 2,826.24USD/年 → 約786USDの削減（約28％の削減）

4-5.総合的なコスト削減効果

これらのアプローチを総合的に適用することで、S3のコストを大幅に削減することが可能です。

• データライフサイクルポリシーによる削減: 約1,705USD/年
• ストレージクラスの見直しによる削減: 約678USD/年
• VPCエンドポイントの導入による削減: 約8,162USD/年
• S3インテリジェントティアリングによる削減: 約786USD/年

これにより、合計で年間 約11,331USD の削減が見込めます。特に、データ転送コストの削減が大きなインパクトを与えていますが、データストレージの最適化も重要なポイントです。

今後の課題としては、さらなるデータの最適化と、各部門でのコスト意識の向上が挙げられます。AWSのベストプラクティスに従ったコスト管理を継続し、今後も新たなコスト削減の方法を模索していきます。

X（旧Twitter）・Facebookで定期的に情報発信しています！
Follow @acceluniverse

1. はじめに
2. SREとは？
3. SREと従来のIT運用との違い
4. なぜSREが重要なのか？
5. SREの導入事例：Googleの成功事例
6. SREの課題と克服
7. 最後に

1.はじめに

「SRE」（Site Reliability Engineering) という言葉を聞いたことがあるでしょうか？ IT業界に携わっている方なら、特に耳にする機会が増えたかもしれません。 SRE（サイト信頼性エンジニアリング）は、今注目すべきトピックのひとつです。

SREはGoogleが提唱した概念で、ITインフラやシステム運用の信頼性向上と効率化を目指した革新的なアプローチです。本記事では、SREの基本的な考え方から、その導入が企業にどのようなメリットをもたらすのか、また、導入にあたってのポイントについてわかりやすく解説します。

2.SREとは？

SRE とは「Site Reliability Engineering」の略で、簡単に言うと、ソフトウェアエンジニアリングの手法を使って、システム運用の効率や信頼性を向上させるアプローチです。 SRE の概念は、Google で働くエンジニアのベン・トレイナー・スロス氏によって考案され、彼は「SREは本質的に、エンジニアが担当する運用である」と述べています。

従来の運用と比較すると、SREはエンジニアリング的なアプローチに強く依存しており、問題が発生した後に対応するのではなく、予防的な対策を行うことに重点を置いています。他の大規模なIT企業の実践によれば、SREはシステム全体の信頼性を向上させるだけでなく、同時に運用コストの削減や開発速度の向上にも最適とされています【1】。

3.SREと従来のIT運用の違い

SREと従来のIT運用の違いは、アプローチそのものにあります。従来のIT運用はシステムの安定稼働を重視し、システム障害が発生した際には迅速に対応する「反応型」の手法をとってきました。これに対して、SRE は、プロアクティブなアプローチを採用します。つまり、システム障害が発生する前に対策し、それを事前に防ぐことが重要視されます。

主な違い

①エラーバジェットの導入:SREでは、完璧な稼働率を目指すのではなく、許容可能な障害時間である「エラーバジェット」を設定し、信頼性と新機能の迅速なリリースのバランスを取ります。過度な可用性の追求は、開発効率や競争力の低下を招くリスクがあるとされています【2】。

②自動化の徹底: 人の手による運用はミスのリスクを増大させます。SRE では、自動化を徹底することで運用の効率性と安定性を向上させます。これにより、チームはより付加価値の高い業務に時間を割けるようになります。

4. なぜSREが重要なのか？

現在のビジネス環境では、ITシステムの安定性が企業の競争力に直結しています。特にクラウドベースのサービスやオンラインビジネスでは、わずかなダウンタイムが顧客離れや収益損失に直結する可能性があります。

SREを導入することで、システムの可用性やパフォーマンスを向上させ、同時にコスト削減を実現することが可能です。また、運用業務の自動化によりエンジニアの負担を軽減することで革新や新規開発に、より多くのリソースを割くことができるようになります。SREは、現代のビジネスにおいて不可欠な運用手法であり、企業の成長と競争力を支える重要な役割を果たします。以下に、SREの代表的な4つの手法を具体例と共に紹介します。

①サービスレベル目標（SLO）の設定

SREは、システムのパフォーマンスや可用性を測定するために、サービスレベル目標（SLO）を明確に定義することを重視します。SLOは「どの程度のサービスの可用性が必要か」 を定量的に示す指標であり、具体的な目標を設定することで、開発チームと運用チームの間の期待値を統一する役割を果たします【3】。

②モニタリングとアラート設定

SREでは、システム全体を継続的にモニタリングし、異常が発生した際には即座にアラートを発生する仕組みを構築します。これにより、障害が深刻化する前に予防的な対応が可能になります。また、適切に設計されたモニタリングシステムは、システム全体の普及性を大幅に向上させます。

③ポストモーテム分析

インシデントが発生した場合、SREは「ポストモーテム」と呼ばれる詳細な分析を行います。この分析は、問題の修正だけでなく、再発防止策の設計とチーム全体への共有を目的としています。この成長プロセスでは、ナレッジベースを構築し、フィードバックループを活用することで、継続的な改善につながっていきます。【4】。

④自動化の推進

SREの基本理念には、「人が行う繰り返し作業を可能な限り自動化する」という考えがあります。これにより、システム管理やメンテナンスにおける手動操作を極力抑え、エラーのリスクを軽減します。 自動化を推進することで、人的介入が減少し、運用コストの削減や運用効率の改善につながります。

5.SRE導入の例：Googleの成功事例

SREを導入したGoogleは、世界で最も大規模にSREを活用している企業の一つです。GmailやYouTube、Google検索といった主要なサービスを利用性が高い状態で提供するために、SREの手法に効果的にエラーバジェットを活用することで、新機能を迅速にリリースしながらも、信頼性を維持し続ける仕組みを実現しています。

このような取り組みは、概念的理論に留まらず、大規模で慎重な運用が求められる企業においても効果があることが証明されています。 さらに、Googleは他の企業がSREを導入する際のサポートも行っており、その成功例は多岐にわたります【5】。

6.SRE の課題とその克服

SREは多くの利点をもたらしますが、その導入にはいくつかの課題が伴います。特に、自動化の推進には初期投資や高度な技術力が必要です。システム管理の自動化ツールやモニタリングの仕組みを構築する為には、専門知識を持つ人材が不可欠であり、それに伴うトレーニングやスキルアップも企業全体で取り組む必要があります。また、これらの投資は短期的に目に見える成果が得られにくいため、長期的な視点を持つことが求められます。

さらに、SREの実装には企業文化の変革が必要不可欠です。SREの理念は、システムの信頼性向上を最優先にしつつも、新しいサービスや機能の迅速なリリースを目指すものです。しかし、これを達成するには、従来の「開発チーム vs 運用チーム」という対立構造を解消し、両者が密接に協力する体制を築かなければなりません。この文化的な変革は、リーダーシップやチーム全体の意識改革を伴うため、スムーズに進めることが難しい場合があります。

また、SREの導入では「信頼性」と「開発スピード」という相反する目標のバランスを取ることも課題の一つです。たとえば、開発チームが新機能の迅速なリリースを優先したい場合、運用チームは信頼性確保の観点から慎重なリリースを求めることがあります。このような状況を解決するために、Googleが提唱した「エラーバジェット」の概念が非常に有効です。エラーバジェットは、システムの許容範囲内での失敗を明確に定義することで、チーム間の合意形成を促し、両者の目標を両立させる仕組みとして機能します。

SREを成功させるためには、これらの課題に対して段階的かつ戦略的に取り組むことが重要です。たとえば、まずは小規模なプロジェクトでSREの手法を試し、その成果を全社的に展開することで、スムーズに導入を進めることができます。また、SREを導入する際には、経営層の理解と支援が欠かせません。必要なリソースを確保し、文化改革をスムーズに進めるためのサポートが求められます。

7.最後に

SREは、現代の複雑なITシステムを効率的に管理し、安定して稼働させるための革新的なアプローチです。Googleのような大規模な企業だけでなく、すべての企業にとってSREは信頼性向上や運用効率の改善に大きく貢献します。また、学術的な観点からも、SREの原則や実践は、システムの洞察性や可視性を向上させることが実証されています。

SREの導入は、システムの安定性を確保しながら、新しい機能やサービスをより迅速に提供できる体制を築くことが可能となり、顧客満足度や市場競争力の向上も期待できます。これからのビジネス競争において、SREを導入することは競争力を高めるための重要なステップとなるでしょう。皆様の組織でも、ぜひSREの導入を検討してみてはいかがでしょうか？

X（旧Twitter）・Facebookで定期的に情報発信しています！
Follow @acceluniverse

1. はじめに
2. SREとSEOの重要な関連性
3. 技術的アプローチ：SREによるSEO改善の戦略
4. まとめ

1.はじめに

最近、Googleが「Core Web Vitals」を検索アルゴリズムの重要な指標として組み込んだことで、サイトのパフォーマンスや信頼性などSEOに与える影響が一層注目されるようになりました。これまで、マーケティング部としてSEO対策といえばキーワードやコンテンツの最適化が主な取り組みでしたが、それだけでは十分ではない時代に突入しています。

弊社のSRE担当のエンジニアと話している際、サイトのパフォーマンスや安定性を改善することが検索エンジンからの評価に直結するため、SRE（Site Reliability Engineering）の考え方がSEOにも有効であるという事実を知りました。SREが目指す可用性やスケーラビリティの向上といった取り組みが、単にシステムの信頼性を高めるだけでなく、検索結果における順位向上やユーザー体験の改善にもつながるというものです。

この気づきは、私たちマーケティング部にとっても新鮮なものでした。技術的な施策とマーケティング施策を連携させることで、ビジネスの成果をさらに押し上げる可能性が広がります。

この記事では、SREのプラクティスをSEOにどう活用できるのかをテーマに、エンジニア視点を取り入れながら掘り下げていきます。技術チームがいかに関わってSEOやサイト運用の効率化を進められるのか、新たな発見が得られる内容をお届けします。ぜひ最後までご覧ください。

2.SREとSEOの重要な関連性

2-1. SREがSEOに与える影響

SREは、システムの「信頼性」と「パフォーマンスの最適化」を追求する役割を持ちますが、これらはSEOにおいても重要な要素と深く関係しています。非常に安定していることは、ユーザーエクスペリエンスだけでなく、検索エンジンからの評価にも直結するのです。 以下のポイントが特に注目すべき要素です：

1.稼働率の維持

Webサイトがダウンしている時間は、検索エンジンがそのサイトをクロールできません。これが頻繁に起こると、検索エンジンはそのサイトを信頼できなくなるとみなし、ランキングを低下させる可能性があります。障害の早期検知や復旧を迅速化することで、稼働率が高い段階で維持することができます。

2.エラーレートの削減

404エラーや5xxエラーが増加すると、Googleはそのサイトを「ユーザー体験を損なうサイト」と判断します。これにより検索エンジンの評価が低下し、SEOランキングに悪影響を及ぼします。 SREでは、ログの監視やエラー率の自動アラートを活用し、エラーの発生を迅速に把握する仕組みが完了しています。これにより、問題を回避し、検索エンジンやユーザーに信頼されるサイト運営が可能になります。

3. ページ速度の最適化

ページ速度は、現代のSEOにおける最重要指標の一つです。 ページの読み込みが遅いと、ユーザーが逃げるだけでなく、Googleのランキングでも不利になります。 ちなみにGoogleが重視するCore Web Vitals（ LCP、FID、CLS）では、速度や応答性が評価の中心となっています。SREのパフォーマンス監視や最適化手法を活用すれば、キャッシュの効率化やCDN（コンテンツ配信ネットワーク）の導入によって、ページ速度を大幅に向上させることが可能です。

2-2. SEO目標に合ったSLO（Service Level Objective:サービスレベル目標）の設定

SREの観点から、SEOに合わせたSLOを設計することは、技術チームとマーケティングチームの連携を深める重要なステップです。具体的には以下のような目標を設定します。

・稼働率目標: 99.95%以上の稼働率を維持します。

・ページ速度目標: 95%のリクエストで2秒以下の応答を実現します。

・エラー率目標: HTTP 404や500系エラーを0.1%未満に抑えます。

これらのSLOを基に、SEOパフォーマンスに直結するKPI（Key Performance Indicator）を設定することで、定量的な改善計画を立てる事が可能になります。

3.技術的アプローチ: SREによるSEO改善の戦略

以下は、技術チームが日々の業務に取り入れられる具体的な取り組み内容です。SREの視点を活かしてSEOパフォーマンスを向上させるための実践例を挙げます。

3-1. Webパフォーマンスの強化

キャッシュの活用と最適化

・長期キャッシュの実装: JavaScriptやCSSファイルを適切にキャッシュすることで、再ダウンロードを減少させます。

・動的コンテンツのキャッシュ戦略: ユーザーセッションに依存するページも、キャッシュ可能な構造に最適化します。

CDNの導入とエッジ最適化

・グローバルユーザーに対する応答速度を向上させるため、CDN（Content Delivery Network）を活用します。

・エッジキャッシュを設定し、ユーザーに最も近い場所からリソースを提供することで応答時間を短縮します。

3-2. 安定したデプロイメントの確立

継続的デリバリー（CI/CD）のベストプラクティス

・ロールバックプロセスの自動化: リリース後の問題に迅速に対応できるよう、即時ロールバックが可能な仕組みを構築します。

・カナリアリリースの実施: 小規模なトラフィックに対して新しい変更をテストすることで、トラブル発生時の影響を最小限に抑えます。

モニタリングの自動化

・アラートポリシーの設計: パフォーマンスやエラーレートの急激な変化を検知するアラートを設定し、問題を迅速に把握できる仕組みを整えます。

・リアルユーザー監視（RUM）: 実際のユーザーのアクセスデータを収集分析し、潜在的な課題やボトルネックを特定します。

3-3. Core Web Vitalsの完全最適化

・LCP（Largest Contentful Paint）: サーバーの応答時間を短縮し、主要コンテンツを迅速にレンダリングします。

・FID（First Input Delay）: JavaScriptの実行を細分化し、インタラクティブ性を向上させます。

・CLS（Cumulative Layout Shift）: 画像や広告などに定義済みのコンテナサイズを設定することで、レイアウトのズレを防ぎ、視覚的な安定性を確保します。

4.まとめ

SREを活用することで、Webサイトの品質とパフォーマンスを技術的に高めるだけでなく、SEOにも大きな効果を生み出すことができます。 ページ速度の最適化といったところは、技術チームが注力すべき重要なポイントです。特に、Googleが重視するCore Web Vitalsへの対応を進めるには、CI/CDの導入、キャッシュの最適化、CDNの活用といった具体的なアプローチが効果的です。これらの取り組みは、システムの安定性を向上させるだけでなく、検索エンジンの評価向上にもつながります。マーケティング部としても、技術チームと連携してSREのプラクティスを日常業務に取り入れることで、ユーザー体験を向上させながら、サイトのビジネス価値を最大化することが重要だと感じています。Webサイトは単なる技術的な基盤ではなく、ビジネス成長の基礎です。技術とマーケティングの両方の視点を融合させれば、さらに競争力の高いWebサイト運営によるビジネス成長が実現できると考えます。

「SEOに強い技術基盤を構築したい」「サイトのパフォーマンスを向上させたい」という企業様がございましたら、アクセルユニバースにぜひお気軽にご相談ください！

X（旧Twitter）・Facebookで定期的に情報発信しています！
Follow @acceluniverse

1. はじめに
2. SREとは？
3. SREのメリット
4. SREのデメリットと対策
5. まとめ

1.はじめに

現代のITシステムにおいて、システムの信頼性は企業にとって最も重要な要素の一つです。サービスの停止や障害は、顧客満足度の低下や収益損失に直結するため、システムを安定して稼働させることが求められています。しかし、システムの複雑化や運用業務の負担増加により、信頼性を確保するのは容易ではありません。 この課題を解決するために注目されているのが、SRE（Site Reliability Engineering） です。SREはGoogleが提唱した運用手法で、システムの信頼性を高め、サービス停止や障害を防ぐことを基本的な目的としています。 本記事では、SREの具体的なメリットと導入の重要性について解説します。

2.SREとは？

SRE（Site Reliability Engineering）は、システム運用にソフトウェアエンジニアリングの手法を取り入れ、信頼性と効率性を向上させるアプローチです。特に、サービスの停止や障害を防ぎながら、安定したシステム運用を実現することに重点を置いています。

SREの基本的な目的

・システムの可用性と信頼性を確保

・サービスの停止や障害の未然防止

・運用タスクの自動化による効率化

・継続的な運用改善

SREの主な要素

・SLI（Service Level Indicator）：サービスの状態を数値で示す指標（例：稼働率や応答時間）。

・SLO（Service Level Objective）：SLIに基づく目標値（例：稼働率99.9%以上）。

・エラーバジェット：サービスの停止許容範囲を定め、デプロイや改善のバランスを取る仕組み。

3.SREのメリット

SREを導入することで、企業はシステム運用をより信頼性が高く効率的なものへと進化させることができます。以下に、SREの主なメリットを解説します。

3-1.システムの信頼性向上

SREの最大の目的は、システムの信頼性を高めることです。SLIやSLOを設定し、システムの状態を定量的に管理することで、障害発生を未然に防ぎます。

効果

サービス停止のリスクを大幅に低減し、ユーザー体験を向上させます。

3-2. 障害対応の迅速化

障害が発生した場合、SREでは標準化された対応プロセスや自動復旧スクリプトを用いて、迅速な復旧を実現します。また、障害後には「ポストモーテム（事後検証）」を実施し、再発防止策を徹底します。

効果

ダウンタイムを最小限に抑え、システム安定性を維持します。

3-3. 運用自動化による効率化

SREでは、繰り返し発生する運用タスク（例：ログ監視や障害対応）を自動化します。これにより、エンジニアは戦略的な業務に集中できるようになります。

効果

人的ミスの削減と運用効率が向上します。

3-4.継続的な運用改善

障害の原因分析や運用データのフィードバックを基に、運用プロセスを継続的に改善します。これにより、システムの信頼性がさらに向上します。

効果

長期的な安定稼働と効率的な運用体制が確立できます。

4. SREのデメリットと対策

SREには多くのメリットがありますが、導入に際しては以下のような課題もあります。

4-1.導入に時間とコストがかかる

SREの導入には、SLI/SLOの設定や運用体制の見直し、自動化ツールの構築などが必要で、初期段階でコストや時間がかかります。

対策

・小規模な試験運用（PoC）から始め、段階的に導入を進める。

・外部の専門家やパートナー企業のサポートを活用する。

4-2.高度なスキルが求められる

SREを実践するには、運用自動化やデータ解析の知識が必要です。チームメンバーのスキルアップが求められる場面もあります。

対策

・専門トレーニングや教育プログラムを実施する。

・SREの専門家を採用または育成する。

4-3.運用形骸化のリスク

SREの導入後、運用が形骸化し、改善サイクルが停滞するリスクがあります。特に、ポストモーテム（事後検証）が適切に行われないと、運用効果が低下する可能性があります。

対策

・定期的な運用レビューと改善サイクルをプロジェクト化する。

・SREの責任者を明確にし、継続的な改善を推進する体制を構築する。

5. まとめ

SRE（Site Reliability Engineering）は、システムの信頼性向上を軸に、運用効率化とサービス停止の未然防止を実現する強力なアプローチです。

SRE導入の主なメリットは、①システムの信頼性向上、②障害対応の迅速化、③運用自動化による効率化、④継続的な運用改善の4点でした。

一方で、導入時には時間やコスト、スキル不足の課題が伴う場合があります。しかし、適切な計画と体制構築、外部の専門家のサポートを活用することで、これらのデメリットを解決できます。弊社にはこれらの課題を解決しながらSREの導入を成功に導いた多くの実績があります。

<お客様からいただいたお言葉>

・依頼していなかったら、AWSセキュリティ改善活動は、後回し・先送りになりスタートすらできていなかった

・技術力の高さから得られる安心感を感じる、無い知見と技術力でを補っていただける

・漠然とした課題がプロジェクト化でき、柔軟な体制で進めることができるようになった

SRE導入は確かに初期段階で工夫が必要ですが、適切なパートナーがいることでスムーズに進めることができます。弊社は、お客様のシステム環境や課題に合わせた柔軟な体制を構築し、SRE導入を支援いたします。

SRE導入に興味をお持ちでしたら、ぜひお気軽にご相談ください。私たちと一緒に、信頼性の高いシステム運用を実現しましょう。

無料ご相談会はこちらから

X（旧Twitter）・Facebookで定期的に情報発信しています！
Follow @acceluniverse

1. はじめに
2. システムの健康診断を超えて：SREの価値とは？
3. SREがもたらす「攻め」の価値：エラーバジェットの考え方
4. 顧客体験向上に直結するSREの役割
5. 総合診療としてのSRE：ビジネスとシステムの架け橋
6. SREの未来：システム運用を超えた価値創造
7. まとめ

1.はじめに

SRE（Site Reliability Engineering）は、単なるシステム運用の効率化や信頼性向上に留まりません。ビジネスの要求に応えつつ、顧客体験を向上させるためには何が必要かを常に考え、実践する多面的なアプローチが求められます。その役割は、まるでシステムの「総合診療医」ともいえる存在です。

2.システムの健康診断を超えて：SREの価値とは？

一般的に、SREの取り組みはシステムの安定稼働や障害対応、自動化、セキュリティ強化など、技術的な課題にフォーカスされがちです。しかし、それだけでは十分ではありません。システムが正常に稼働することはもちろん重要ですが、その先にある「ビジネスへの貢献」や「顧客体験の向上」を視野に入れることで、真の価値を発揮します。

たとえば、大規模なシステム障害が発生すれば、単に復旧作業を行うだけでなく、その障害がどのように顧客体験やビジネス成果に影響を与えたかを分析し、再発防止策に反映させる必要があります。SREは、技術のスペシャリストであると同時に、ビジネス価値を創出する「戦略的パートナー」としての役割を果たすべき存在です。

3.SREがもたらす「攻め」の価値：エラーバジェットの考え方

SREの中心的な考え方のひとつに「エラーバジェット」があります。エラーバジェットは、許容できるシステム停止時間を数値化したもので、信頼性と新機能開発のバランスを取る指標として機能します。

エラーバジェットの仕組み

1.定義

例えば、月間稼働率を99.9%に設定した場合、43.2分の停止が許容されます。この範囲内であれば、新機能開発や改善作業を積極的に進められます。

2.活用例

エラーバジェットが十分に残っている場合、リスクを取って新しい機能をリリースし、顧客価値を高めることが可能です。 逆に、エラーバジェットを超えた場合は、安定性を最優先し、リリースを一時停止するなど、システムの改善に専念します。

この仕組みにより、SREは「攻め」と「守り」の両立を図りながら、システムの成長と安定性をバランス良く保つことができます。

4. 顧客体験向上に直結するSREの役割

SREの最終的な目標は、エンドユーザーの体験を向上させることにあります。単にシステムを止めないだけでなく、次のような形で顧客満足度や企業の成長に貢献します。

4-1.コスト削減と再投資

SREの取り組みによって運用コストを削減できれば、その余剰資金を新しいサービスや機能開発に再投資できます。例えば、効率化したインフラ運用費用を新商品の開発や顧客サポート体制の強化に回すことで、顧客体験を向上させることが可能です。

4-2.ブランドイメージの保護

システムダウンは顧客の信頼を損ない、ブランドイメージに悪影響を与えます。SREがシステムの安定稼働を支えることで、顧客離れのリスクを最小限に抑えられます。

4-3.障害の影響を最小化

障害が発生した場合、迅速な復旧や影響範囲の限定化を実現することで、顧客が感じる不便を最小限に抑えます。これにより、障害発生時でも顧客満足度を一定に保つことが可能です。

5. 総合診療としてのSRE：ビジネスとシステムの架け橋

SREは、「システム」と「ビジネス」の両方を理解し、両者を結びつける役割を担っています。この視点で見たとき、SREには次のような特徴があります。

5-1.システムとビジネスを包括的に見る能力

SREは、技術的な側面だけでなく、ビジネス目標や顧客ニーズを深く理解し、それに即した運用改善や新機能の提案を行います。たとえば、売上に直結する重要なシステムの稼働を優先的に保証する一方、リスクが低い部分では柔軟性を持たせるといった判断が求められます。

5-2.分断された組織の架け橋

多くの企業では、システム部門とビジネス部門が分断され、協力がスムーズに進まないことがあります。SREは、その間に立ち、技術的視点とビジネス視点をつなぐことで、組織全体の効率を高めます。

6.SREの未来：システム運用を超えた価値創造

SREは、システム運用の専門家から、ビジネス成長を支えるパートナーへと進化しつつあります。今後のSREには、次のような期待が寄せられています。

1.予測可能な運用

AIや機械学習を活用し、障害を未然に防ぐ運用体制の構築。

2.顧客中心の戦略

顧客満足度を重視した新しいKPI（Key Performance Indicator）の設定と管理。

3.ビジネス貢献の明確化

運用改善がビジネス成果に与える影響を定量化し、企業全体の価値を可視化。

7. まとめ：SREは「攻め」と「守り」の要

SREは、単なるシステム運用の枠を超えた多面的な取り組みを通じて、企業全体の成長を支えるエンジンとなります。顧客体験の向上、コスト削減、ブランド保護といった効果を最大化するには、SREを「総合診療」として捉え、ビジネスと技術のバランスを常に意識する必要があります。

今後もSREは進化を続け、企業にとって欠かせない存在となっていくでしょう。技術とビジネスを結びつけるこの新しい役割を積極的に取り入れることが、未来の成功を左右する鍵となるはずです。

X（旧Twitter）・Facebookで定期的に情報発信しています！
Follow @acceluniverse

目次

• 結局、何が違うのか？
• Redshiftの運用性
  • 1. AWS上の対向システムとの統合容易性
  • 2. 機械学習ベースの管理タスク自動化
  • 3. Glue/Lake Formation による一元的なメタデータ・アクセス権限管理
• まとめと次回予告
• 出典（いずれも記事公開時点閲覧）

結局、何が違うのか？

こんにちは、アクセルユニバース株式会社、データサイエンティストの世古大樹です。

クラウド環境にデータウェアハウス（DWH）を構築しようとする場合、まず候補に上がるのはAWSの Redshift と、Google Cloud（旧GCP）の BigQuery でしょう。Redshiftが選ばれるのは、主に組織がすでにAWS上にシステムを構築しており、DWHも同じAWS上に作りたいからだと思います。AWSのシェアは国内トップであり（出典1）、「クラウドサービスならAWS」と考える企業も多いです。

一方、データ分析基盤に詳しい人は、Google Cloud のBigQueryを好みがちかもしれません。AWSがクラウドサービス全体をリードしているのに対し、Google Cloud はデータ分析や機械学習の領域に特別な強みがあると知られています。2019年に「DWHにBigQueryを採用しないことは大罪である」と主張するブログ記事（出典2）が公開され、このような意見は今も根強く残っています。

とはいえ、この記事の時からは月日が流れ、データウェアハウスを取り巻く環境は大きく変わりました。上のブログでRedshiftがBigQueryより劣っているとされた理由は「自前のクラスタ管理が必要など、フルマネージドでない」「スケールしない」という運用性の面でしたが、2022年に Redshift Serverless がリリースされ、BigQuery同様のフルマネージド・サーバーレスサービスとして使えるようになりました（今でもBigQueryの長所に「サーバーレス」を挙げる記事は多いですが、Redshiftもとっくにサーバーレスなのです）。

今は、単純に「RedshiftよりBigQueryの方が良い」と言えない状況です。両者の差は縮まっており、ほとんど同じ物のように見えます。RedshiftとBigQueryで共通している主な機能を、筆者が調査できた限りで表にしてみます。1つ1つ読む必要はありませんが、「これほど多くの機能が共通しているならどちらでもいいのでは？」と感じられるのではないでしょうか。

実際のところ、「どちらを使ってもあまり変わらない」というのも一つの見識だと思います。自社や担当者が詳しい方のクラウドを選択するのも手、です。

しかし、より詳しく見ていくと、両者には明確な違いもあることがわかります。このブログでは、それを 「運用性ならRedshift、コスパならBigQuery」 という視点に整理し、2回に分けて説明します。1回目の今回はRedshiftの運用性を解説します。読者の方が適切なクラウドサービスを選べる助けになれば幸いです。

Redshiftの運用性

Redshiftの運用性が高いと言える根拠は、「1. AWS上の対向システムとの統合容易性」「2. 機械学習ベースの管理タスク自動化」「3. Glue/Lake Formation による一元的なメタデータ・アクセス権限管理」の3つです。

1. AWS上の対向システムとの統合容易性

前述した通り、AWSは国内シェアが高く、クラウドサービス業界を牽引する存在です。そのため多くの組織のITシステムはすでにAWS上に構築されており、オンプレミスでホストされていても、AWSへの移行が検討される場合が多いです。DWHには、これらのITシステムからデータを受け取るための連携が必要なので、DWHも同じAWS上に立てると簡単になります。構成としては、データソース・データレイク・データウェアハウス・データマートをはっきり分けて構築する、以下のようなものが考えられます（あくまで一例です）。

（筆者作成）

Glueが複数種類のデータソースを横断して、簡単にデータ収集・データレイク構築をしてくれるのが見て取れると思います。一方、AWSから Google Cloud へのデータ連携は複雑です。一般的なマルチクラウド構成の複雑さ（クラウド相互の認証認可、学習コスト、運用体制等）はもちろんのこと、RDSから Google Cloud へのデータ転送など、構築自体が大きく複雑になります。

AWS上のシステムと容易に統合できるRedshiftには、 運用簡素性・開発工数・自由度 の面でメリットがあるのです。

2. 機械学習ベースの管理タスク自動化

先ほどRedshiftとBigQueryで共通している機能の表を載せましたが、どちらかにしかない機能もあります。それらの機能の一つ一つは細々としたものですが、「機械学習ベースの管理タスク自動化」とまとめると、塵も積もれば山となる、Redshiftの強みと言って差し支えないものになります。

このことをより具体的に言うと、Redshiftは、 利用しているだけでデータやクエリの状況を自動的に判定し、DWHを最適化してくれる のです。他方のBigQueryは自動最適化の機能が限定的で、BIツールによるクエリを最適化する BI Engine がある程度です。基本的には、モニタリングを行って、その結果を判定し、手動でメンテナンスを行わなければなりません（出典3参照）。Redshiftであれば、機械学習などによって監視・判定・メンテナンスを自動化し、放っておくだけで処理を効率的にしてくれる様々な機能が提供されています。詳しく見ていきましょう。

バラしてしまうと、この節の元ネタは Black Belt（出典4） の、主に pp.20-33 です。この Black Belt 資料自体、Redshiftを理解するうえで必読のものなのでぜひ読んでいただきたいのですが、それはそれとして、この記事では Black Belt をもとにRedshift独自の（＝BigQueryにはない）管理機能をまとめ、筆者の観点から補足を行います。

Redshift独自の自動管理機能のまとめ

• カラム（列データ）の最適化
  • ゾーンマップとソートキー：カラムをあらかじめソートし、ディスクの物理ブロックごとに最小値と最大値を記憶しておくことで、不要なブロックを読み飛ばして処理する。
  • 圧縮エンコードの自動管理：カラムごとに最適なエンコード方式を自動で判定し、圧縮する。（手動選択も可能）
    
• テーブルの最適化
  • 自動テーブル最適化：利用状況を判定し、ソートキーや分散キーを必要に応じて自動設定する。（手動設定も可能）
  • Vacuum Delete 自動化：Delete・Update 後の削除領域の開放を、適切なタイミングで自動実行する。（手動実行も可能）
  • ソート自動化：テーブル全体のソートは負荷が高くなるが、機械学習によってソートが必要な部分だけをピンポイントに、適切なタイミングでソートすることで、パフォーマンスやアクセスに影響なくソートできる。（手動ソートも可能）
    
• ネットワークの最適化
  • データを均等分散して並列処理に最適化するだけでなく、JOINするレコード同士を同じ場所に置くことで、I/Oを削減できる。
    
• クエリ実行の最適化
  • Analyze 自動化：テーブルの統計情報を適切なタイミングで自動更新することで、最適な実行計画のもとにクエリを行える。
  • Auto WLM：ワークロードごとに、物理リソース（メモリ・CPU等）の割当を自動で最適化する。
  • ショートクエリアクセラレーション：クエリの実行時間を予測し、短時間と判断されたクエリは、特別な領域でスムーズに処理される。（オフにもできる）

「ゾーンマップとソートキー」「自動テーブル最適化」について

たとえばテーブルの列 date: DATE がちゃんと日付順に並んでいないと、普通は WHERE date >= '2024-01-01' のようなWHERE句を含むクエリに対してフルスキャンを行う必要があり、応答時間や課金額が無駄に大きくなってしまいます。そこで列をいくつかの塊（1MBのブロックごと）にまとめ、塊の中の最大値と最小値をメモリに保存しておけば、最大値が 2024-01-01 未満である部分を読み飛ばして処理することができ、効率が上がります。これがゾーンマップです。

しかし、これだけではまだ無駄があります。読み込むブロックに含まれる全てのデータが 2024-01-01 以上とは限らないからです。例えば100件中1件のみが 2024-01-01 以上で、99件のスキャンは無駄だった、ということもありえます。そのため、さらに列のデータを降順にソートしておけば、少なくとも最大値が 2024-01-01 以上である最後のブロックの1つ前のブロックまでは全て 2024-01-01 以上ということになるので、効率的な処理が可能です。このようにソートする列を指定するものがソートキーで、適切なソートキーを自動設定してくれるのが自動テーブル最適化です。

（筆者作成）

これらの機能は検索の効率を上げるという点で、インデックスに似ています。BigQueryにはインデックスがあり、一度作成したインデックスを自動管理してくれる機能もあります。しかし、最初にインデックスを作るには手動のDDLコマンドが必要であり、適切なインデックスを作るためにクエリパターンの監視・解析も必要です。管理の簡素さという点で、Redshiftに軍配が上がるところです。

3. Glue/Lake Formation による一元的なメタデータ・アクセス権限管理

これは厳密にはDWHの機能ではありませんが、AWSで多くの場合Redshiftと併用されるサービスのメリットとして挙げます。

「メタデータ」とは何かというと、データレイクやDWHに保存されているデータ（実データ）を説明する情報です。具体的には、テーブル・列・データ型・データソース・データ作成日などの説明です。そしてメタデータは「データカタログ」というデータベースに保管されます。データカタログを調べてメタデータを見れば、どのデータが「使える」データなのか、どの列が何を意味しているのかなどがわかります。DWHに蓄積される膨大なデータを活用するためには、「どこにどんなデータがあるのか」がわかることが重要です（わからないと使えるデータも埋もれてしまいます）。

データに対するアクセス権限管理についても、メタデータが重要な役割を果たします。たとえば、メタデータに「センシティブデータであるかどうか」という列を加え、それを利用してセンシティブデータを閲覧できるユーザーを制限する、というような運用が可能になります。また、（あまり無いことですが）機密情報に関わるメタデータ自体へのアクセスを制限することも考えられます。

AWSではETLとメタデータ・アクセス権限管理が一体化している ため、このあたりの管理が大きく省力化されます。先ほどの構成例をもう一度見てみましょう。

まず、下の Glue Crawler がデータソースを探索し、メタデータを作って Glue Data Catalog に保管します。保管されたメタデータの使い道は2つあります。1つはGlueのJob（ETLタスク）において、取得対象のデータを特定するために使われます。もう1つは Lake Formation で、テーブルの列単位などのきめ細かい粒度でのアクセス権限を設定するために使われます。Lake Formation のアクセス権限管理はデータレイクだけでなく、データマートにも及びます。Redshiftデータ共有と統合することで、コンシューマーRedshiftのアクセス権限を Lake Formation で管理することができるのです。

要するに、AWSではETLとメタデータがGlueという1つのサービスに合体しており、さらにGlueが統合的なアクセス権限管理を行う Lake Formation と高度に接続されていることで、データの管理負担が抑えられる、ということです。これは大きな特長です。

Google Cloud ではこうは行きません。ETLサービスであるDataflowにはメタデータ管理などの機能がなく、Data Catalog というサービスで別途データカタログを作成する必要があります。また、アクセス権限管理も Data Catalog、Cloud Storage（データレイク）、BigQuery（DWH）で個別に行わなければなりません（かなり大変そうじゃありませんか？）。特に Cloud Storage できめ細かいアクセス権限管理を行うことは、煩雑なため公式に非推奨とされています。Cloud Storage のきめ細かいアクセス権限管理はACL（Amazon S3 のACLと同様のものであり、現在はAWSでも Google Cloud でも非推奨とされている方式）で行う必要があるためです。

きめ細かいアクセスでは、2 つの異なるアクセス制御システム間で調整が必要になります。このため、意図しないデータ漏洩が発生する可能性が高くなり、リソースにアクセスできるユーザーの監査は複雑になります。特に、個人を特定できる情報などの機密データを含むオブジェクトが存在する場合は、均一なバケットレベルのアクセスを有効にしてバケットにデータを保存することをおすすめします。
（出典5）

......と言われても、一部のユーザーから隠さなければならない機密データを含むバケットで均一なアクセスを有効にするとなると、

1. 機密データを見てはいけないユーザーがそのバケット（＝データレイク）全体を見られなくなるか、
2. 機密データを保管するバケットをデータレイクから分割し、そのバケットにアクセス制限をかけるか

しかありません。1だとそのユーザーのデータ利用が制約されてしまいますし、2だと「すべての生データを1箇所に集約する」というデータレイクのコンセプトそのものに反してしまいます。Google Cloud ではデータレイクのアクセス権限管理に課題があると言わざるを得ないでしょう。

まとめと次回予告

今回の記事では、BigQueryと比較したときのRedshiftの運用性について解説しました。ポイントをまとめておきます。

1. RedshiftもBigQueryも、多くの機能が共通しているが、詳しく見ると「運用性ならRedshift、コスパならBigQuery」という違いがある。
2. Redshift中心の構成では、AWS上の対向システムからデータ収集を行うのが簡単。
3. Redshiftは、自動管理機能によって設定・監視・メンテナンスの負担が小さくなる。
4. AWSでは、ETL・メタデータ・きめ細かいアクセス権限管理が Glue/Lake Formation に一元化されており、効率的な運用が可能。

次回は、実際にクエリを投げてかかった費用と応答時間を比較しながら、「BigQueryのコスパ」について解説します。「BigQueryはコストパフォーマンスに優れている」とはよく言われますが、必ずしもRedshiftより安くて速い訳ではありません。それでもBigQueryにあるコスパ上の利点とは何でしょうか？（次回記事はこちら）

出典（いずれも記事公開時点閲覧）

1. 総務省『情報通信白書令和6年度版 データ集』「第4章第8節 7. PaaS/IaaS利用者のAWS、Azure、GCP利用率」 https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r06/html/datashu.html#f00281
2. データエンジニアの酩酊日記『近年のデータ分析基盤構築における失敗はBigQueryを採用しなかったことに全て起因している』 https://uma66.hateblo.jp/entry/2019/10/17/012049
3. Google Cloud『BigQuery 管理の概要』 https://cloud.google.com/bigquery/docs/admin-intro?hl=ja
4. Amazon Web Services『Amazon Redshift 運用管理 AWS Black Belt Online Seminar』 https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt2023Amazon-Redshift-Management0331v1.pdf
5. Google Cloud『アクセス制御の概要』 https://cloud.google.com/storage/docs/access-control?hl=ja

X（旧Twitter）・Facebookで定期的に情報発信しています！
Follow @acceluniverse

目次

• 「費用対効果」で選ぶには？
• 結果：BigQueryは「安定」している
• 実験条件
  • データセット
  • データウェアハウス設定・計測条件
  • クエリ
• コード集
  • 前処理
  • データロード等
  • 計測記録の取得（BigQuery）
  • リザルトキャッシュの無効化（Redshift Serverless）
  • クエリ1-1：小規模構造化データ、単純集計
  • クエリ1-2：小規模構造化データ、集計+ウィンドウ関数
  • クエリ1-3：小規模構造化データ、ウィンドウ関数+CTE+集計
  • クエリ2-1：中規模半構造化データ、CTE+集計
  • クエリ2-2：中規模半構造化データ、JOIN+集計
  • クエリ2-3：中規模半構造化データ、ウィンドウ関数集計+CTE+JOIN

「費用対効果」で選ぶには？

こんにちは。アクセルユニバース株式会社、データサイエンティストの世古大樹です。

今回は、以前のデータウェアハウス比較記事の続編で、BigQuery と Redshift Serverless のコストパフォーマンスを比較する実験を行いました。

詳しくは後述しますが、同じデータセットに対して同じクエリを実行し、かかった料金（コスト）と応答時間（パフォーマンス）を計測しています。

データセットは、80GiB程度の構造化データと360GiB程度の半構造化データの2種類を利用します。それぞれのデータセットに対し、性質の異なる3つのクエリ（合計6つのクエリ）を書きました。クエリ1つにつき5回実行して、特有のオーバーヘッドがある1回目を除外し、2〜5回目の計測結果の平均値を取っています。

「BigQueryの方が安価で性能が良い」とよく言われているようですが、実際に比較した結果を公開しているものは見当たりません。本記事を読めば、コストとパフォーマンスに根拠を持ってデータウェアハウスの選定ができるようになります。

結果：BigQueryは「安定」している

実験の詳細は後回しにして、いきなり結果から発表したいと思います。詳細は .xlsx ファイル（こちらからダウンロード）でご確認いただけますが、ここでは概要の解説を行います。

まず、「コスト」にあたる平均課金額は以下のようになりました。（データセットやクエリの内容は後述します）

「差」「比」はともに「BigQuery 容量コンピューティング」と「Redshift Serverless」を比較したもので、BigQueryが有利な場合は青色、Redshiftが有利な場合は赤色で表現しています（以降の表も同様）。

「比」を見ると、思いのほか傾向が一定していないのが驚きです。BigQueryの方が安いクエリも、Redshiftの方が安いクエリもあります。クエリ1-1はBigQueryの方が約13倍高い一方、2-2はRedshiftの方が15倍高くなり、ばらつきが大きいようです。

次に、「パフォーマンス」にあたる平均応答時間は以下のようになりました。

BigQueryの応答時間は比較的安定している（425〜27,212ms、約64倍）のに対し、Redshiftはかなり開きがある（68〜158,411ms、約2300倍）のが目を惹きます。RedshiftのRPU（仮想的な演算リソース）は、BigQueryと近い応答時間になるように設定したのですが、実際に比を1付近にできたのは1-2と2-3だけです。1-1と2-2ではRPUを最低にしてもBigQueryより大幅に速くなり、逆に1-3と2-1ではRPUを非常に大きくしてもあまり速度が上がらず、BigQueryには遠く及びませんでした。

「BigQueryの方がパフォーマンスが高い」とよく言われていますが、むしろ正確には、「BigQueryの方がパフォーマンスが安定している（Redshift Serverless ほど極端に長い応答時間を必要としない）」傾向にありそうだ、ということが読み取れます。

また、平均課金額の表で垣間見えていた、各DWHにとって「どのクエリが得意／不得意か」の傾向は、応答時間にも共通しており、課金額の比が大きい順に平均応答時間の比も大きくなりました。つまり、どちらのDWHにも、「得意なクエリは安いし速い」「苦手なクエリは高いし遅い」という相対的な傾向があるようです。

そこで、各クエリがそれぞれのDWHにとってどの程度「得意」かを表す指標を作ります。平均応答時間の逆数を、クエリに対するDWHの「パフォーマンス」、平均課金額を「コスト」と捉え、パフォーマンスをコストで割ります。この「コストパフォーマンス指数」が高いほど、そのDWHがそのクエリを「得意」としていることを示します。

まず行ごとに「比」を見ると、BigQueryがRedshiftの何倍のコストパフォーマンスを示したかがわかります。全体的にはBigQueryが上回っており、特に2-1では210倍もの差になっていますが、6個中2つのクエリではRedshiftが優勢で、1-1では83倍の差です。必ずBigQueryの方が優れているとは言い切れず、「どちらが良いかは場合による」ことになります。

実験した限りでは、Redshiftが上回った場合の共通点は、「RPUが最低の8でも非常に速いこと（数秒以内）」でした。「CTE（サブクエリ）があるとRedshiftが不利になる傾向にある」ということも言えそうですが、サブクエリはメモリサイズをボトルネックとする処理なので、「メモリサイズと比例するRPUの数を増やしても、サブクエリを含むクエリがあまり速くならないこと」の説明がつきません。事前には、BigQueryではインデックスを張れるのに対しRedshiftではソートキーの指定しか行えないため、JOINが含まれるとBigQueryが大幅に速くなると予想していたのですが、そういった傾向もありませんでした。

困ったことに、BigQueryの測定から得られる情報（スロット数・応答時間・処理データ容量）からは、Redshiftの方が良いのかどうか予想できません。言えるのは、「Redshift Serverless を使っている場合、RPU数が小さくなければBigQueryに移行した方が良くなる見込みが大きい」ということです。

次に列ごとに（縦に）表を見ると、こちらははっきりした傾向が読み取れます。値が大きいほどそのDWHにとって簡単な処理で、逆に小さいほど難しい処理だということになり、最大値と最小値の幅が狭いほど、常に安定したコストパフォーマンスを発揮できることになります。BigQueryの方が、平均課金額・平均応答時間ともに幅の開きが小さかったため、コストパフォーマンス指数も安定しました。BigQueryは 0.00012〜2.4 の20,000倍、Redshiftは 0.0000023〜200 の約90,000,000倍です。「BigQueryのコストパフォーマンスは、Redshift Serverless に比べて、（優れているというより）安定している」というのが、この実験における最も重要な結論です。

平均前の測定値、RPU数、課金額の計算方法などの詳細、および注意事項などは、 .xlsx ファイル（こちらからダウンロード）をご覧ください。

実験条件

以下では、どのような条件の下に実験を行ったのかを、「データセット」「データウェアハウス設定・計測条件」「クエリ」に分けて述べます。ただし、実際に利用したクエリ文等は非常に長いので、末尾の「コード集」にまとめて掲載しました。ここでは日本語ベースで、概要や意図だけを説明します。

データセット

利用したデータセットの1つ目は、Chicago Data Portal の Taxi Trips (2013-2023) です。シカゴ市が公開している、市内のタクシーの賃走についてのデータセットです。11年分の運行について、タクシーID、開始・終了時刻、走行距離、運賃などが記録されています。CSV形式で23列×約2億行、解凍時サイズは約80GiBの、単一テーブルのデータです。表では「小規模構造化データ」と呼んでいます。

2つ目は、Hugging Face にある McAuley-Lab の Amazon-Reviews-2023 です。1996年から2023年までに amazon.com へ投稿された商品レビューが収集されています。レビューデータの集まりである User Reviews、レビューされる商品の情報である Item Metadata の2種類のデータがあり、さらにそれぞれ商品カテゴリでデータセットを分割されています。実験では、商品カテゴリによって分割されたデータを1つにまとめ、種類に応じて2つのテーブルとしました。いずれもJSON形式で、User Reviews は約260GiB、Item Metadata は約90GiB、計360GiBほどです。表では「中規模半構造化データ」と呼んでいます。

いずれも GCS/S3 バケットに保存し、そこから BigQuery/Redshift へロードしました。

データウェアハウス設定・計測条件

今回の実験では、「実際にDWHの利用を開始した時のパフォーマンスを再現すること」を目指し、現実の利用開始時に近い設定としました。

パフォーマンス最適化の基本としては、BigQueryではインデックスの作成、Redshiftではソートキーの指定ができます。DWHの利用が進んでいけば、メトリクスに基づいて最適なインデックスを構築したり、ソートキーが自動的に最適化されたりするところですが、普通、利用開始時にはそこまで行わないと思います。とはいえ、最適化を何も行わないのもリアリティがありません。そこで今回は、「インデックスは主キーにのみ張り、ソートキーにはタイムスタンプ列を指定する」というシンプルな設定にしました。また、RedshiftのVACUUMは、各データベースでデータロード完了後の1度のみ実施しました。

計測に際しては、信頼度の高いデータとするため、リザルトキャッシュの取得を無効化した上で5回連続で同じクエリを行い、2〜5回目の計測結果の平均値を取りました。1回目の結果を除くのは、Redshiftで初回のみコードコンパイルが行われるなど、例外的なオーバーヘッドが発生しうるからです。

リージョン（ロケーション）については、AWS・Google Cloud ともに全て東京単一リージョンで実行し、料金も東京の金額で計算しました。

BigQueryの課金モデルは、予約したスロット（仮想的な演算リソース）の利用量に基づく「容量コンピューティング」と、スキャンしたデータ量に基づく「オンデマンド」の2種類があり、さらに「容量コンピューティング」には3つのエディションがあります。BigQueryの利用を開始する場合、まず「オンデマンド」で自社の利用量等を把握し、「容量コンピューティング」の予約に移行することが想定されていますが、初めから「容量コンピューティング」を使うことも十分あり得ます。そこで今回は、「オンデマンド」を利用してその課金額と処理データ量を記載しつつ、「容量コンピューティング・Standardエディション」の場合のスロット数と課金額も計算し、記録しました（こちらの数値を元に、他のエディションの金額も計算可能です）。

Redshift Serverless の課金額は、RPU（仮想的な演算リソース）の利用量に基づきます。このRPUのベース値は8〜512の間で指定することができ、大きくすると応答時間は短くなりますが、ある程度を超えると短縮効果がコストの増加に見合わなくなります。今回は、原則的にBigQueryの応答時間と近くなるように設定しつつも、コストに見合わないほど大きな値にはしないようにしました。例えばクエリ1-3の応答時間は、RPUが128のとき約160秒でしたが、最大の512に設定しても約100秒と、40％の時短に対して2.5倍のコストになります（コストパフォーマンス指数は0.64倍）。BigQueryは約20秒でしたが、それにできるだけ近づけるのではなく、現実的なラインと考えられた128RPUに設定しました。

なお、最適なRPU数を探索するためのクエリは、測定に影響を及ぼさないように、別のデータベースで行いました。また、Redshift Serverless には1分間の最低課金時間があり、1分未満のクエリであっても1分間分の料金が発生します。しかし実際の利用においては、1分未満のクエリも、他のクエリと同時に実行することで合計1分以上にできると考えられるため、測定されたままのミリ秒数に基づいて料金を計算しました。

以上の料金は、演算（クエリ）に対する費用であり、実際にはストレージ（データ保存）に対する費用も発生しますが、そちらは（通常の利用では）演算に対する費用に比べてかなり安価になることと、デモを行わなくても簡単に見積が取れることから、計測を行いませんでした。また、本記事に掲載されている料金についての情報は公開時点のものであることにご注意ください。料金の詳細について、BigQueryはこちら、Redshiftはこちらをご覧ください。

計測結果の取得には、BigQueryでは後に掲載するクエリを用いました。Redshiftでは、クエリエディタv2のリザルトに表示される Elapsed time で応答時間を計測し、応答時間にRPU数とRPU時間あたりの料金を乗じて課金額を計算しました。RPU数が指定したベースRPU数の通りであることはコンソール上で確認しました。

クエリ

DWHパフォーマンスのボトルネックとして代表的な処理は、ディスクI/OとCPUに負荷のかかるソート（結合・ORDER BY句・ウィンドウ関数）と、メインメモリを消費するサブクエリです。そのため、DWHの主なワークロードである集計（集約関数）を全クエリに含めながら、これらの句や関数の様々な組み合わせを試しました。

できるだけ標準SQLに準拠するようにしました。方言の違いにより、BigQueryとRedshiftで全く同じクエリ文にはなりませんでしたが、同じ処理を実現するものになっています。

また、クエリは集計・分析として意味を持つように作成し、コード集にはその説明も付けておきました。

コード集

前処理

Amazon-Reviews-2023 の Item Metadata は、そのままだと BigQuery の仕様でエラーが出るので、以下のPythonスクリプトで前処理しました。Redshiftの場合は前処理なしで読み込めますが、同一条件で比較するために、同じく前処理したデータをロードしています。

import json
import re

def clean_columns(obj):
    if isinstance(obj, dict):
        keys = list(obj.keys())
        for key in keys:

            # テーブル定義に合わないデータ型を修正する。
            if key == 'rating_number' and not isinstance(obj[key], int):
                del obj[key]
            elif key in ('average_rating', 'price') and not isinstance(obj[key], float):
                del obj[key]
            elif key == 'details' and not isinstance(obj[key], dict):
                del obj[key]
            elif key in ('videos', 'images', 'features', 'description', 'categories', 'bought_together') and not isinstance(obj[key], list):
                obj[key] = []
            elif key == 'images':
                images = obj[key]
                for image in images:
                    for image_size in list(image):
                        if not image_size in ('thumb', 'large', 'variant', 'hi_res'):
                            del image[image_size]
                            print(str(image_size) + 'を削除しました。')

            # BigQueryの仕様に合わせたキーの前処理：使用できない特殊文字を消去し、大文字・小文字の違いを無視する。衝突が発生するか空文字列になる場合は削除する。
            cleaned_key = re.sub(r'[!"$()*,./;?@[\]^`{}~]', '', key.lower())
            if key != cleaned_key or cleaned_key == '':
                if cleaned_key in obj or cleaned_key == '':
                    del obj[key]
                else:
                    obj[cleaned_key] = obj.pop(key)

        for value in obj.values():  # ネストされたオブジェクトに対して再帰的に処理を行う。
            clean_columns(value)
    return obj

def main():
    with open('item_metadata_before_cleaned.jsonl', 'r') as input, open('item_metadata.jsonl', 'w') as output:
        for line in input:
            obj = json.loads(line)
            obj = clean_columns(obj)
            cleaned_line = json.dumps(obj)
            output.write(cleaned_line + '\n')

if __name__ == '__main__':
    main()

データロード等

Taxi Trips (2013-2023), BigQuery

このデータセットのタイムスタンプ形式はBigQueryにサポートされていないので、一度文字列型で読み込んでから変換しています。 また、各データセット共通ですが、BigQueryでは4GB以上のファイルを圧縮形式でロードできないので、解凍したデータを読み込んでいます（Redshiftでは圧縮したまま利用しています）。

CREATE SCHEMA taxi_dataset 
  OPTIONS(
      location='asia-northeast1',
      storage_billing_model='LOGICAL'
  );

CREATE TABLE taxi_dataset.TaxiTrip (
    trip_id STRING,
    taxi_id STRING,
    trip_start_timestamp STRING,
    trip_end_timestamp STRING,
    trip_seconds INT,
    trip_miles FLOAT64,
    pickup_census_tract STRING,
    dropoff_census_tract STRING,
    pickup_community_area INT,
    dropoff_community_area INT,
    fare FLOAT64,
    tips FLOAT64,
    tolls FLOAT64,
    extras FLOAT64,
    trip_total FLOAT64,
    payment_type STRING,
    company STRING,
    pickup_centroid_latitude FLOAT64,
    pickup_centroid_longitude FLOAT64,
    pickup_centroid_location GEOGRAPHY,
    dropoff_centroid_latitude FLOAT64,
    dropoff_centroid_longitude FLOAT64,
    dropoff_centroid_location GEOGRAPHY,
    PRIMARY KEY(trip_id) NOT ENFORCED
);

LOAD DATA INTO taxi_dataset.TaxiTrip
FROM FILES (
    allow_jagged_rows=true,
    field_delimiter=',',
    format='CSV',
    null_marker='',
    skip_leading_rows=1,
    uris=['gs://my-bucket-name/TaxiTrip.csv']
);

ALTER TABLE taxi_dataset.TaxiTrip
    ADD COLUMN new_trip_start_timestamp TIMESTAMP,
    ADD COLUMN new_trip_end_timestamp TIMESTAMP;

UPDATE taxi_dataset.TaxiTrip
    SET
        new_trip_start_timestamp = PARSE_TIMESTAMP('%m/%d/%Y %I:%M:%S %p', trip_start_timestamp),
        new_trip_end_timestamp = PARSE_TIMESTAMP('%m/%d/%Y %I:%M:%S %p', trip_end_timestamp)
    WHERE true;

ALTER TABLE taxi_dataset.TaxiTrip
    DROP COLUMN trip_start_timestamp,
    DROP COLUMN trip_end_timestamp;

ALTER TABLE taxi_dataset.TaxiTrip
    RENAME COLUMN new_trip_start_timestamp TO trip_start_timestamp,
    RENAME COLUMN new_trip_end_timestamp TO trip_end_timestamp;

CREATE SEARCH INDEX tt_pk_index    -- 主キーにインデックスを張る。
    ON taxi_dataset.TaxiTrip(trip_id);

Taxi Trips (2013-2023), Redshift Serverless

CREATE DATABASE taxi_database;

CREATE TABLE IF NOT EXISTS
    taxi_database.public.TaxiTrip (
        trip_id CHAR(40),
        taxi_id CHAR(128),
        trip_start_timestamp TIMESTAMP,
        trip_end_timestamp TIMESTAMP,
        trip_seconds INT,
        trip_miles FLOAT,
        pickup_census_tract VARCHAR(255),
        dropoff_census_tract VARCHAR(255),
        pickup_community_area INT,
        dropoff_community_area INT,
        fare FLOAT,
        tips FLOAT,
        tolls FLOAT,
        extras FLOAT,
        trip_total FLOAT,
        payment_type VARCHAR(64),
        company VARCHAR(255),
        pickup_centroid_latitude FLOAT,
        pickup_centroid_longitude FLOAT,
        pickup_centroid_location GEOMETRY,
        dropoff_centroid_latitude FLOAT,
        dropoff_centroid_longitude FLOAT,
        dropoff_centroid_location GEOMETRY,
        PRIMARY KEY(trip_id)
    )
    BACKUP NO
    COMPOUND SORTKEY(trip_start_timestamp, trip_end_timestamp);    -- タイムスタンプ列をソートキーにする。

COPY taxi_database.public.TaxiTrip (
        trip_id, taxi_id, trip_start_timestamp, trip_end_timestamp, trip_seconds, trip_miles, 
        pickup_census_tract, dropoff_census_tract, pickup_community_area, dropoff_community_area, 
        fare, tips, tolls, extras, trip_total, payment_type, company, 
        pickup_centroid_latitude, pickup_centroid_longitude, pickup_centroid_location, 
        dropoff_centroid_latitude, dropoff_centroid_longitude, dropoff_centroid_location
    )
FROM 's3://my-bucket-name/TaxiTrip.csv.gz'
IAM_ROLE 'my-role-arn'
REGION 'ap-northeast-1'
CSV
DELIMITER ','
NULL AS ''
IGNOREHEADER 1
TIMEFORMAT 'MM/DD/YYYY HH:MI:SS AM'
GZIP;

VACUUM;

Amazon-Reviews-2023, BigQuery

CREATE SCHEMA amazon_reviews_dataset 
    OPTIONS(
        location='asia-northeast1',
        storage_billing_model='LOGICAL'
    );

CREATE TABLE amazon_reviews_dataset.ItemMetadata (
    main_category STRING
    , title STRING
    , average_rating FLOAT64
    , rating_number INT
    , features ARRAY
    , description ARRAY
    , price FLOAT64
    , images ARRAY>
    , videos ARRAY> 
    , store STRING
    , categories ARRAY
    , details JSON
    , parent_asin STRING 
    , bought_together ARRAY
    , PRIMARY KEY(parent_asin) NOT ENFORCED
);

/*
ItemMetadataのみ、スキーマ自動検出でエラーが出るので、スキーマ自動検出をオフにするため、SQLではなく以下のbqコマンドでロードする。

$ bq --location=asia-northeast1 load \
--noautodetect --source_format=NEWLINE_DELIMITED_JSON \
amazon_reviews_dataset.ItemMetadata \
gs://my-bucket-name/item_metadata.jsonl
*/

CREATE SEARCH INDEX im_pk_index    -- 主キーにインデックスを張る。
    ON amazon_reviews_dataset.ItemMetadata(parent_asin);

CREATE TABLE amazon_reviews_dataset.UserReviews (
    rating FLOAT64
    , title STRING
    , text STRING 
    , images ARRAY>
    , asin STRING
    , parent_asin STRING 
    , user_id STRING
    , timestamp INT -- UNIX時刻。
    , verified_purchase BOOLEAN
    , helpful_vote INT
    , PRIMARY KEY(parent_asin, user_id) NOT ENFORCED
    , FOREIGN KEY(parent_asin) REFERENCES amazon_reviews_dataset.ItemMetadata(parent_asin) NOT ENFORCED
);

LOAD DATA INTO amazon_reviews_dataset.UserReviews
FROM FILES (
    format='NEWLINE_DELIMITED_JSON',
    ignore_unknown_values=true,
    uris=['gs://my-bucket-name/user_reviews.jsonl']
);

CREATE SEARCH INDEX ur_pk_index    -- 主キーにインデックスを張る。
    ON amazon_reviews_dataset.UserReviews(parent_asin, user_id);

Amazon-Reviews-2023, Redshift Serverless

Item Metadata の description は本来SUPER型ですが、サイズが大き過ぎてCOPY時にエラーが出るデータがいくつもあります。サイズの限度で打ち切るため、COPY時に TRUNCATECOLUMNS オプションを付け、SUPER型は TRUNCATECOLUMNS の対象にならないため VARCHAR(65535) 型で定義しました。この処理を施してもデータサイズはほぼ変化せず、クエリに description を使うこともないため、測定に問題はありません。

CREATE DATABASE amazon_reviews_database;

CREATE TABLE IF NOT EXISTS
    amazon_reviews_database.public.ItemMetadata (
        main_category VARCHAR(64)
        , title VARCHAR(4096)
        , average_rating FLOAT
        , rating_number INT
        , features SUPER
        , description VARCHAR(65535)
        , price VARCHAR(64)
        , images SUPER
        , videos SUPER
        , store VARCHAR(4096)
        , categories SUPER
        , details SUPER
        , parent_asin VARCHAR(16)
        , bought_together SUPER
        , PRIMARY KEY(parent_asin)
    )
    BACKUP NO;

COPY amazon_reviews_database.public.ItemMetadata (
        main_category, title, average_rating, rating_number, features, description, price,
        images, videos, store, categories, details, parent_asin, bought_together    
    )
FROM 's3://my-bucket-name/item_metadata.jsonl.gz'
IAM_ROLE 'my-role-arn'
REGION 'ap-northeast-1'
JSON 'auto'
NULL AS ''
TRUNCATECOLUMNS
GZIP;

CREATE TABLE IF NOT EXISTS 
    amazon_reviews_database.public.UserReviews (
        rating FLOAT
        , title VARCHAR(4096)
        , text VARCHAR(65535)
        , images SUPER
        , asin VARCHAR(16)
        , parent_asin VARCHAR(16)
        , user_id VARCHAR(128)
        , timestamp BIGINT
        , verified_purchase BOOLEAN
        , helpful_vote INT
        , FOREIGN KEY(parent_asin) REFERENCES ItemMetadata(parent_asin)
    )
    BACKUP NO
    COMPOUND SORTKEY(timestamp);

COPY amazon_reviews_database.public.UserReviews (
        rating, title, text, images, asin,
        parent_asin, user_id, timestamp, verified_purchase, helpful_vote 
    )
FROM 's3://my-bucket-name/user_reviews.jsonl.gz'
IAM_ROLE 'my-role-arn'
REGION 'ap-northeast-1'
JSON 'auto'
NULL AS ''
TRUNCATECOLUMNS
GZIP;

VACUUM;

計測記録の取得（BigQuery）

Redshiftではコンソール上で記録を閲覧するため、コードがありません。

SELECT
    job_id  -- クエリの一意ID。
    , TIMESTAMP_DIFF(end_time, start_time, MILLISECOND) AS elapsed_time_milliseconds  -- 応答時間（ミリ秒）。
    , total_slot_ms / TIMESTAMP_DIFF(end_time, start_time, MILLISECOND) AS num_slot  -- 「容量コンピューティング」の場合のスロット数。
    , 0.051 * total_slot_ms / (1000 * 60 * 60) AS cost_capacity  -- 「容量コンピューティング」の場合の課金額（USD）。
    , total_bytes_billed * POW(2, -40) AS total_terabytes_billed  -- スキャンされたデータ容量（TiB）。
    , 7.5 * total_bytes_billed * POW(2, -40) AS cost_on_demand  -- 「オンデマンド」の場合の課金額（USD）。
    , start_time  -- クエリの開始時刻。
    , state  -- クエリの状態（実行中でないか確認するために出力させる）
    , LEFT(query, 50)  -- クエリ文の冒頭50文字。
FROM `my-project-name`.`region-asia-northeast1`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
ORDER BY start_time DESC;

リザルトキャッシュの無効化（Redshift Serverless）

BigQueryではコンソール上で設定を行うため、コードがありません。

SET enable_result_cache_for_session TO off;  -- 無効化。

SHOW enable_result_cache_for_session;  -- 無効化されていることの確認。

クエリ1-1：小規模構造化データ、単純集計

データセットに含まれる運行の総数と、運賃の平均値を求めます。

BigQuery

SELECT 
    COUNT(*) AS num_trips, 
    AVG(fare) AS avg_fare
FROM taxi_dataset.TaxiTrip;

Redshift

SELECT 
    COUNT(*) AS num_trips, 
    AVG(fare) AS avg_fare
FROM TaxiTrip;

クエリ1-2：小規模構造化データ、集計+ウィンドウ関数

1台のタクシーが1日に乗車された回数のTOP10と、その日付を調べます。

BigQuery

SELECT
    RANK() OVER (ORDER BY COUNT(trip_id) DESC) AS ranking,
    LEFT(taxi_id, 10) AS short_taxi_id,
    CAST(trip_start_timestamp AS DATE) AS date,
    COUNT(trip_id) AS trip_count
FROM taxi_dataset.TaxiTrip
GROUP BY
    CAST(trip_start_timestamp AS DATE), 
    taxi_id
ORDER BY ranking ASC
LIMIT 10;

Redshift

SELECT
    RANK() OVER (ORDER BY COUNT(trip_id) DESC) AS ranking,
    LEFT(taxi_id, 10) AS short_taxi_id,
    CAST(trip_start_timestamp AS DATE) AS date,
    COUNT(trip_id) AS trip_count
FROM TaxiTrip
GROUP BY
    CAST(trip_start_timestamp AS DATE), 
    taxi_id
ORDER BY ranking ASC
LIMIT 10;

クエリ1-3：小規模構造化データ、ウィンドウ関数+CTE+集計

「タクシーは、どの程度スムーズに乗客を見つけられるのか？」を知りたいとします。一つの指標として、「前の乗客を降ろした場所の近くで、すぐに次の乗客を拾うという事象」について調べます。1人目の客を降ろした直後にその近くで2人目の客を拾い、2人目の客を降ろした直後にその近くで3人目の客を拾い......と、この事象は連続することがあります。n回連続した事象を series n trip、n回以上連続した事象を series n or more trip と呼び、n = 1, 2, 3 について相対度数を算出します。

BigQuery

-- タクシーごとに、各運行とその直前の運行の、運行ID、開始／終了座標、開始／終了時刻を取得するCTE。
WITH CurrAndPrevTrips AS (
    SELECT
        trip_id AS curr_trip_id,
        LAG(trip_id, 1) OVER W AS prev_trip_id,
        pickup_centroid_location AS curr_start_point,
        ST_GeogFromText(
            LAG(ST_AsText(dropoff_centroid_location), 1) OVER W    -- 地理データに直接ウィンドウ関数を適用できないRedshiftに合わせた処理（本来BigQueryでは不要）。
        ) AS prev_end_point,
        trip_start_timestamp AS curr_start_time, 
        LAG(trip_end_timestamp, 1) OVER W AS prev_end_time
    FROM taxi_dataset.TaxiTrip
    WHERE
        ST_Distance(pickup_centroid_location, dropoff_centroid_location) 
            < trip_miles * 1609 -- 誤った位置情報を持っている可能性が高いレコードが15％程度あるので、除外する。
    WINDOW W AS (
        PARTITION BY taxi_id
        ORDER BY trip_start_timestamp, trip_end_timestamp, trip_id
    )
),
-- 客を降ろしてから、一定の時間・距離内で、新しい客を拾った運行（series 1 trip）の組を取得するCTE。
Series1Trips AS (
    SELECT
        curr_trip_id,
        prev_trip_id
    FROM CurrAndPrevTrips
    WHERE
        TIMESTAMP_DIFF(curr_start_time, prev_end_time, MINUTE) <= 15
        AND ST_Distance(curr_start_point, prev_end_point) < 500
),
Series2Trips AS (
    SELECT
        Tbl1.curr_trip_id AS curr_trip_id,
        Tbl1.prev_trip_id AS prev1_trip_id,
        Tbl2.prev_trip_id AS prev2_trip_id
    FROM 
        Series1Trips AS Tbl1
        INNER JOIN Series1Trips AS Tbl2
            ON Tbl1.prev_trip_id = Tbl2.curr_trip_id -- 連続している2つのうち前者が、別の連続の後者として存在している場合を捉えて結合する。以下同様。
),
Series3Trips AS (
    SELECT
        S2.curr_trip_id AS curr_trip_id,
        S2.prev1_trip_id AS prev1_trip_id,
        S2.prev2_trip_id AS prev2_trip_id,
        S1.prev_trip_id AS prev3_trip_id
    FROM 
        Series2Trips AS S2
        INNER JOIN Series1Trips AS S1
            ON S2.prev2_trip_id = S1.curr_trip_id
),
Series4Trips AS (
    SELECT S3.curr_trip_id
    FROM 
        Series3Trips AS S3
        INNER JOIN Series1Trips AS S1
            ON S3.prev3_trip_id = S1.curr_trip_id
),
-- 総運行数とn連続運行数を集計するCTE。
DuplicatedCounts AS (
    SELECT 
        (SELECT COUNT(*) FROM CurrAndPrevTrips) AS num_all_trips,
        (SELECT COUNT(*) FROM Series1Trips) AS s1, -- この数は、series 2 trip を重複して2回数えている（一般に series n trip を重複してn回数えている）。
        (SELECT COUNT(*) FROM Series2Trips) AS s2, -- この数は、series 3 trip を重複して2回数えている（一般に series n trip を重複してn-1回数えている）。以下同様。
        (SELECT COUNT(*) FROM Series3Trips) AS s3,
        (SELECT COUNT(*) FROM Series4Trips) AS s4
)
SELECT
    num_all_trips,
    s1 - s2 AS num_series_1_or_more_trips, -- この数は、series n trip を重複なく1回として数えている。以下同様。
    s2 - s3 AS num_series_2_or_more_trips,
    s3 - s4 AS num_series_3_or_more_trips,
    FORMAT('%.2f %%', (s1 - s2) / (num_all_trips * 1.0) * 100) AS rate_series_1_or_more_trips, -- 1.0 を掛けるのは、実数除算を行うための措置。以下同様。
    FORMAT('%.2f %%', (s2 - s3) / (num_all_trips * 1.0) * 100) AS rate_series_2_or_more_trips,
    FORMAT('%.2f %%', (s3 - s4) / (num_all_trips * 1.0) * 100) AS rate_series_3_or_more_trips
FROM DuplicatedCounts;

Redshift

-- タクシーごとに、各運行とその直前の運行の、運行ID、開始／終了座標、開始／終了時刻を取得するCTE。
WITH CurrAndPrevTrips AS (
    SELECT
        trip_id AS curr_trip_id,
        LAG(trip_id, 1) OVER (
            PARTITION BY taxi_id
            ORDER BY trip_start_timestamp, trip_end_timestamp, trip_id
        ) AS prev_trip_id,
        pickup_centroid_location AS curr_start_point,
        ST_GeomFromText(LAG(ST_AsText(dropoff_centroid_location), 1) OVER (  -- Redshift では、地理データに直接ウィンドウ関数を適用できない。
            PARTITION BY taxi_id
            ORDER BY trip_start_timestamp, trip_end_timestamp, trip_id
        )) AS prev_end_point,
        trip_start_timestamp AS curr_start_time, 
        LAG(trip_end_timestamp, 1) OVER (
            PARTITION BY taxi_id
            ORDER BY trip_start_timestamp, trip_end_timestamp, trip_id
        ) AS prev_end_time
    FROM TaxiTrip
    WHERE
        ST_Distance(pickup_centroid_location, dropoff_centroid_location) 
            < trip_miles * 1609 -- 誤った位置情報を持っている可能性が高いレコードが15％程度あるので、除外する。
),
-- 客を降ろしてから、一定の時間・距離内で、新しい客を拾った運行（series 1 trip）の組を取得するCTE。
Series1Trips AS (
    SELECT
        curr_trip_id,
        prev_trip_id
    FROM CurrAndPrevTrips
    WHERE
        (EXTRACT(EPOCH FROM curr_start_time) - EXTRACT(EPOCH FROM prev_end_time)) / 60 <= 15
        AND ST_Distance(curr_start_point, prev_end_point) < 500
),
Series2Trips AS (
    SELECT
        Tbl1.curr_trip_id AS curr_trip_id,
        Tbl1.prev_trip_id AS prev1_trip_id,
        Tbl2.prev_trip_id AS prev2_trip_id
    FROM 
        Series1Trips AS Tbl1
        INNER JOIN Series1Trips AS Tbl2
            ON Tbl1.prev_trip_id = Tbl2.curr_trip_id -- 連続している2つのうち前者が、別の連続の後者として存在している場合を捉えて結合する。以下同様。
),
Series3Trips AS (
    SELECT
        S2.curr_trip_id AS curr_trip_id,
        S2.prev1_trip_id AS prev1_trip_id,
        S2.prev2_trip_id AS prev2_trip_id,
        S1.prev_trip_id AS prev3_trip_id
    FROM 
        Series2Trips AS S2
        INNER JOIN Series1Trips AS S1
            ON S2.prev2_trip_id = S1.curr_trip_id
),
Series4Trips AS (
    SELECT S3.curr_trip_id
    FROM 
        Series3Trips AS S3
        INNER JOIN Series1Trips AS S1
            ON S3.prev3_trip_id = S1.curr_trip_id
),
-- 総運行数とn連続運行数を集計するCTE。
DuplicatedCounts AS (
    SELECT 
        (SELECT COUNT(*) FROM CurrAndPrevTrips) AS num_all_trips,
        (SELECT COUNT(*) FROM Series1Trips) AS s1, -- この数は、series 2 trip を重複して2回数えている（一般に series n trip を重複してn回数えている）。
        (SELECT COUNT(*) FROM Series2Trips) AS s2, -- この数は、series 3 trip を重複して2回数えている（一般に series n trip を重複してn-1回数えている）。以下同様。
        (SELECT COUNT(*) FROM Series3Trips) AS s3,
        (SELECT COUNT(*) FROM Series4Trips) AS s4
)
SELECT
    num_all_trips,
    s1 - s2 AS num_series_1_or_more_trips, -- この数は、series n trip を重複なく1回として数えている。以下同様。
    s2 - s3 AS num_series_2_or_more_trips,
    s3 - s4 AS num_series_3_or_more_trips,
    TO_CHAR((s1 - s2) / (num_all_trips * 1.0) * 100, 'FM999.000') || ' %' AS rate_series_1_or_more_trips, -- 1.0 を掛けるのは、実数除算を行うための措置。以下同様。
    TO_CHAR((s2 - s3) / (num_all_trips * 1.0) * 100, 'FM999.000') || ' %' AS rate_series_2_or_more_trips,
    TO_CHAR((s3 - s4) / (num_all_trips * 1.0) * 100, 'FM999.000') || ' %' AS rate_series_3_or_more_trips
FROM DuplicatedCounts;

クエリ2-1：中規模半構造化データ、CTE+集計

Amazonレビューが「参考になった」を獲得する数に関して分析したいとします。一般に、投稿された直後のレビューは「参考になった」を獲得しておらず、時間の経過とともに獲得数を増やし、十分時間が経過することでそのレビューに相応しい獲得数に漸近すると考えられます。そこで分析の際、「十分時間」が経過していないレビューをWHERE句で排除することで、獲得数が安定したデータのみを対象にできます。そのためにここでは、「十分時間」が何年であるか特定するため、レビューを経過年数の階級に分類し、階級ごとに獲得数の平均値を求めます。そして階級の平均値と全体の平均値の比を取り、その比が一定の閾値に達しているかどうかのフラグを出力させます。

このデータセットのタイムスタンプはミリ秒単位のUNIX時刻です。このデータが収集されたのは2023年9月23日で、UNIX時刻にすると1695427200000になります。

BigQuery

WITH VoteNumWithClass AS (
    SELECT
        helpful_vote
        , CASE
            WHEN timestamp > 1679529600000 THEN '0.0-0.5y'  -- 投稿から経過した時間が0年以上半年未満である階級。以下同様。
            WHEN timestamp > 1663891200000 THEN '0.5-1.0y'
            WHEN timestamp > 1647993600000 THEN '1.0-1.5y'
            WHEN timestamp > 1632355200000 THEN '1.5-2.0y'
            WHEN timestamp > 1616457600000 THEN '2.0-2.5y'
            WHEN timestamp > 1600819200000 THEN '2.5-3.0y'
            WHEN timestamp > 1584921600000 THEN '3.0-3.5y'
            WHEN timestamp > 1569196800000 THEN '3.5-4.0y'
            WHEN timestamp > 1553299200000 THEN '4.0-4.5y'
            WHEN timestamp > 1537660800000 THEN '4.5-5.0y'
            WHEN timestamp <= 1537660800000 THEN '5.0y-'
            ELSE NULL
        END AS class
        , AVG(helpful_vote) OVER () AS overall_avg
    FROM amazon_reviews_dataset.UserReviews
)
SELECT
    class
    , AVG(helpful_vote) / MAX(overall_avg) AS votes_ratio_to_overall
    , CASE
        WHEN AVG(helpful_vote) / MAX(overall_avg) < 0.7
        THEN 'Too recent to rely on.'
        ELSE 'Old enough.'
    END AS eval_usable_or_not
FROM VoteNumWithClass
GROUP BY class
ORDER BY class;

Redshift

WITH VoteNumWithClass AS (
    SELECT
        helpful_vote
        , CASE
            WHEN timestamp > 1679529600000 THEN '0.0-0.5y'  -- 投稿から経過した時間が0年以上半年未満である階級。以下同様。
            WHEN timestamp > 1663891200000 THEN '0.5-1.0y'
            WHEN timestamp > 1647993600000 THEN '1.0-1.5y'
            WHEN timestamp > 1632355200000 THEN '1.5-2.0y'
            WHEN timestamp > 1616457600000 THEN '2.0-2.5y'
            WHEN timestamp > 1600819200000 THEN '2.5-3.0y'
            WHEN timestamp > 1584921600000 THEN '3.0-3.5y'
            WHEN timestamp > 1569196800000 THEN '3.5-4.0y'
            WHEN timestamp > 1553299200000 THEN '4.0-4.5y'
            WHEN timestamp > 1537660800000 THEN '4.5-5.0y'
            WHEN timestamp <= 1537660800000 THEN '5.0y-'
            ELSE NULL
        END AS class
        , AVG(helpful_vote) OVER () AS overall_avg
    FROM UserReviews
)
SELECT
    class
    , AVG(helpful_vote) / MAX(overall_avg) AS votes_ratio_to_overall
    , CASE
        WHEN AVG(helpful_vote) / MAX(overall_avg) < 0.7
        THEN 'Too recent to rely on.'
        ELSE 'Old enough.'
    END AS eval_usable_or_not
FROM VoteNumWithClass
GROUP BY class
ORDER BY class;

クエリ2-2：中規模半構造化データ、JOIN+集計

商品のレビュー数が多くなると、「自分がレビューを書く意味がない」と感じる人が増えて、レビュー数の増加が鈍化する傾向がある、という推測を立てました。これについて調査したいと思います。しかし、単にレビュー数の時間変化率だけを見ると、その商品が人気を失ってレビューされなくなった場合と区別できません。また、サクラを利用していたり、クーポンなどの報酬を用意して購入者にレビューを書くよう促したりしている商品であれば、通常のレビュー数の鈍化パターンに当てはまらないだろうと思われます。

そこでこのクエリでは、「商品ID、商品のレビュー数、商品のレビューについた『参考になった』の総数」の組を取得します。十分なレビュー数がある商品のうち、レビュー数に対して「参考になった」総数が多いものは、鈍化傾向にある可能性が高く、逆に少ないものはサクラなどを利用している可能性が高いと考えられます。

結果セットのサイズが大きいので、Redshiftでは一時テーブルに出力して表示させることができません。UNLOADコマンドによってS3バケットに結果を出力します。

BigQuery

SELECT
    UR.parent_asin
    , MAX(IM.rating_number) AS rating_number -- 1つの parent_asin に対応する rating_number は一意。このMAX関数は形式的なもので、実際は唯一の rating_number が返される。
    , SUM(UR.helpful_vote) AS sum_vote
FROM
    amazon_reviews_dataset.UserReviews UR 
    INNER JOIN amazon_reviews_dataset.ItemMetadata IM
        ON UR.parent_asin = IM.parent_asin
GROUP BY UR.parent_asin;

Redshift

UNLOAD('
    SELECT
        UR.parent_asin
        , MAX(IM.rating_number) AS rating_number -- 1つの parent_asin に対応する rating_number は一意。このMAX関数は形式的なもので、実際は唯一の rating_number が返される。
        , SUM(UR.helpful_vote) AS sum_vote
    FROM
        UserReviews UR 
        INNER JOIN ItemMetadata IM
            ON UR.parent_asin = IM.parent_asin
    GROUP BY UR.parent_asin;
')
TO 's3://my-bucket-name/unload2-2/'
IAM_ROLE 'my-role-arn'

クエリ2-3：中規模半構造化データ、ウィンドウ関数集計+CTE+JOIN

「参考になった」を獲得しやすい、優れたレビューの特徴を分析したいとします。そのためのデータを、2-1で求めた期間の条件でフィルタリングし、適切に加工して取り出す必要があります。しかし、単純に「参考になった」の獲得数を基準とするのは不適切だと考えられます。100件以上の「参考になった」を獲得しているレビューが複数ある商品で10件の「参考になった」を獲得しているレビューと、他に「参考になった」を獲得しているレビューが存在しない商品で10件獲得しているレビューでは、後者をより「優れている」と判定すべきだからです。

そこでこの分析では、パレート分析のような方法を用いることにしました。具体的には、商品ごとに、「参考になった」獲得数の順にレビューを並べ、累積相対度数に応じてグループA、B、Cに分けます（総度数が0の場合のグループはNULLとします）。そしてレビューごとに、そのレビューがどのグループに属するかと、以下の情報をセットにして出力します（後工程で、レビューがどのグループになるかを説明できる変数の組み合わせを探るという想定）：「商品ID」、「評価値（星の数）」、「商品全体の平均評価値と評価値の差」、「添付画像の有無」、「レビュータイトルの原文」、「レビュータイトルの単語数」、「レビュー本文の原文」、「レビュー本文の単語数」。

結果セットのサイズが大きいので、一時テーブルに出力して表示させることができません。BigQueryでは別のテーブルを作成した上でそこに結果を保存する設定を行い、RedshiftではUNLOADコマンドによってS3バケットに結果を出力します。

BigQuery

WITH UserReviewWithWindow AS (
    SELECT
        *
        , 1.0 * SUM(UR.helpful_vote) OVER (
            PARTITION BY UR.parent_asin
            ORDER BY UR.helpful_vote DESC
        ) -- 商品ごとに、「参考になった」数の多い順にレビューを並べたときの、「参考になった」の累積度数。1.0を掛けるのは商を浮動小数点値にするため。
            / NULLIF(SUM(UR.helpful_vote) OVER (PARTITION BY UR.parent_asin), 0) -- 商品ごとの「参考になった」合計数。これで割ることで、「参考になった」の累積相対度数になる。
            AS crf
        , RANK() OVER (
            PARTITION BY UR.parent_asin
            ORDER BY UR.helpful_vote DESC
        ) AS rank -- 商品ごとに、「参考になった」数の多い順にレビューを並べたときの順位。
    FROM amazon_reviews_dataset.UserReviews UR
    WHERE UR.timestamp < 1584921600000 -- 2−1で決まったUNIX時刻（3年以上経過）。
)
SELECT
    UR.parent_asin -- 商品ID。
    , CASE -- パレート分析のグループを割り当てる。70%までをAグループ、90%までをBグループ、以降をCグループとする。
        WHEN UR.rank = 1 AND UR.crf IS NOT NULL THEN 'A' -- 相対度数が0.7以上のレビューをAグループに割り振るための処理。
        WHEN UR.crf < 0.7 THEN 'A'
        WHEN UR.crf < 0.9 THEN 'B'
        WHEN UR.crf <= 1.0 THEN 'C'
        ELSE NULL
    END AS pareto_group
    , UR.rating
    , IM.average_rating - UR.rating AS diff_avg_rating
    , CASE
        WHEN ARRAY_LENGTH(UR.images) = 0
        THEN false
        ELSE true
    END AS has_images
    , UR.title AS raw_title
    , LENGTH(UR.title) - LENGTH(REPLACE(UR.title, ' ', '')) + 1 AS num_words_title
    , UR.text AS raw_text
    , LENGTH(UR.text) - LENGTH(REPLACE(UR.text, ' ', '')) + 1 AS num_words_text
FROM
    UserReviewWithWindow UR 
    INNER JOIN amazon_reviews_dataset.ItemMetadata IM 
        ON UR.parent_asin = IM.parent_asin;

Redshift

UNLOAD('
    WITH UserReviewWithWindow AS (
        SELECT
            *
            , 1.0 * SUM(UR.helpful_vote) OVER (
                PARTITION BY UR.parent_asin
                ORDER BY UR.helpful_vote DESC
                ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING  -- Redshift では集約ウィンドウ関数に ORDER BY 句を含める場合、フレーム句が必須。
            ) -- 商品ごとに、「参考になった」数の多い順にレビューを並べたときの、「参考になった」の累積度数。1.0を掛けるのは商を浮動小数点値にするため。
                / NULLIF(SUM(UR.helpful_vote) OVER (PARTITION BY UR.parent_asin), 0) -- 商品ごとの「参考になった」合計数。これで割ることで、「参考になった」の累積相対度数になる。
                AS crf
            , RANK() OVER (
                PARTITION BY UR.parent_asin
                ORDER BY UR.helpful_vote desc
            ) AS rank -- 商品ごとに、「参考になった」数の多い順にレビューを並べたときの順位。
        FROM UserReviews UR
        WHERE timestamp < 1584921600000 -- 2-1で決まったUNIX時刻（3年以上経過）。
    )
    SELECT
        UR.parent_asin -- 商品ID。
        , CASE -- パレート分析のグループを割り当てる。70%までをAグループ、90%までをBグループ、以降をCグループとする。
            WHEN UR.rank = 1 AND UR.crf IS NOT NULL THEN ''A'' -- 相対度数が0.7以上のレビューをAグループに割り振るための処理。
            WHEN UR.crf < 0.7 THEN ''A''
            WHEN UR.crf < 0.9 THEN ''B''
            ELSE ''C''
        END AS pareto_group
        , UR.rating
        , IM.average_rating - UR.rating AS diff_avg_rating
        , CASE
            WHEN GET_ARRAY_LENGTH(UR.images) = 0
            THEN false
            ELSE true
        END AS has_images
        , UR.title AS raw_title
        , LENGTH(UR.title) - LENGTH(REPLACE(UR.title, '' '', '''')) + 1 AS num_words_title
        , UR.text AS raw_text
        , LENGTH(UR.text) - LENGTH(REPLACE(UR.text, '' '', '''')) + 1 AS num_words_text
    FROM
        UserReviewWithWindow UR
        INNER JOIN ItemMetadata IM 
            ON UR.parent_asin = IM.parent_asin;
')
TO 's3://my-bucket-name/unload2-3/'
IAM_ROLE 'my-role-arn'

X（旧Twitter）・Facebookで定期的に情報発信しています！
Follow @acceluniverse

1. 導入
2. SREにおける視点の違い
3. SREを外部に委託する利点
4. SRE外部委託の課題とコストの問題
5. 自社の一員として動いてくれるSREパートナーを選ぶ
6. SREを社内で運用するか外部に委託するかの選択
7. まとめ

SRE（Site Reliability Engineering）の外部委託における利点と課題について、システム運用の効率化とコスト管理の観点で適切な委託先の選び方を解説します。

1. 導入

SREは、システムの安定運用と信頼性向上を実現するために不可欠な役割を果たします。特に、システムの障害発生リスクを最小限に抑え、サービスの継続的な提供を保証することが重要です。しかし、企業がこのSREの役割をどのように担うかという選択は、システムの規模や企業のリソース状況に大きく左右されます。SREを社内で構築し運用するか、それとも外部に委託するかは、企業がシステム運用において直面する大きな課題の一つです。本記事では、SREを外部に委託することの利点と課題、そして成功に導くための適切な委託先の選び方について詳しく説明します。

2. SREにおける視点の違い

SREの基本的な目的は、システムの信頼性を高め、サービスの停止や障害を防ぐことです。これには、システムの自動化、継続的なモニタリング、障害対応体制の強化などが含まれます。技術的には、インフラの冗長化や障害時のフェイルオーバー、負荷分散の最適化などを実施することがSREの重要な業務です。

しかし、ビジネス視点でのSREの役割は、単にシステムを安定的に動作させるだけでは不十分です。企業が成長し、ビジネスの要求が高度になるにつれて、SREの目的は、システムの安定運用をベースに、エンドユーザー体験の向上や業務効率の改善を目指すものに変わります。つまり、技術的なパフォーマンスの最適化だけでなく、最終的にビジネス全体にどう貢献できるかがSREの評価指標となります。SREは、システム運用にとどまらず、企業の戦略的なビジネス目標に向けて、顧客体験を改善し、コスト削減や運用効率化を通じて、企業全体の成長を支える役割も担っているのです。

3. SREを外部に委託する利点

企業がSREを外部に委託する理由はさまざまですが、その主な利点は以下の通りです。

3-1. 専門的な知識と経験の活用

外部のSREチームは、さまざまな業界やプロジェクトで培った専門的な知識と経験を持っています。彼らは、特に大規模で複雑なシステムや、マイクロサービスアーキテクチャを採用している企業において、その知識を活かして迅速かつ効果的に問題解決を図ります。たとえば、オンプレミスからクラウドへの移行や、クラウドネイティブな環境での運用効率化など、社内チームでは得難い専門的なスキルを提供することができます。

3-2. 柔軟な人的リソースの活用

外部委託によって、企業はリソースを柔軟に活用することが可能です。社内でSREチームを固定費として維持するよりも、外部のSREリソースを必要に応じて変動費として活用できるため、コスト管理がしやすくなります。たとえば、繁忙期や新しいプロジェクトの立ち上げ時に追加リソースが必要になった場合、外部のSREチームを一時的に増強することで、短期間での対応が可能となります。

3-3. 高い対応力とスピード

外部のSREチームは、複数のプロジェクトを経験しているため、問題解決や障害対応のスピードに優れています。例えば、突発的なシステム障害が発生した場合、経験豊富な外部のSREチームは迅速に原因を特定し、最適な解決策を実行します。また、24時間365日の対応が求められるような運用環境において、外部委託はスピーディな対応と高い信頼性を提供します。

4. SRE外部委託の課題とコストの問題

しかし、SREの外部委託にはいくつかの課題があります。最も大きな課題はコストの問題です。外部のSREチームを活用する場合、特に長期間にわたるプロジェクトでは、社内でSREを運用する場合と比較してコストが高くなることがあります。契約形態やサービス内容によっては、予算を超過するリスクもあります。そのため、企業はコスト対効果を十分に考慮し、運用効率を維持しつつ、費用を適切に管理する必要があります。

また、外部のSREチームが企業のビジネス戦略や目標を理解しているかどうかも重要なポイントです。単なる技術的な問題解決だけでなく、企業全体の目標にどのように貢献できるかを考える外部チームと連携することが不可欠です。これを実現するには、定期的なコミュニケーションと、目標に対する明確な期待値の設定が必要です。

5. 自社の一員として動いてくれるSREパートナーを選ぶ

SREを外部に委託する際には、単に技術力や価格だけで選ぶのではなく、「自社の一員として動いてくれる」パートナーを選ぶことが重要です。従来のシステム開発においては、顧客からの依頼に基づいて開発会社が対応するという形が一般的でしたが、SREはそれとは異なるアプローチが求められます。

SREの外部委託においては、外部のSREチームが単に顧客の要求に応じるだけでなく、プロアクティブに課題を発掘し、解決策を提案することが重要です。外部チームが率先してシステムの潜在的な問題を見つけ、顧客が気づいていないリスクや改善点を提案することで、システムの安定性やパフォーマンスを向上させることができます。これが、SREを外部に委託する際の真の価値です。

企業は、単なる技術的なサポートを超えて、ビジネス全体に貢献できる外部パートナーを選ぶことが、長期的な成功への鍵となります。このようなパートナーを見つけることで、企業はシステム運用の安定性を確保しつつ、エンドユーザー体験の向上やビジネス価値の最大化を実現できます。

6. SREを社内で運用するか外部に委託するかの選択

SREを社内で運用するか、外部に委託するかの判断は、企業の規模や戦略によって異なります。社内に専任のSREチームを構築することで、特定のプロジェクトや業務に深く関与し、企業のビジネス目標に沿った運用が可能となります。しかし、社内リソースの制約や、システムの複雑化による負荷増加を考慮すると、外部に委託する選択肢も検討する価値があります。

特に、新規サービスの導入や、大規模なシステム更新を控えている場合、外部のSREチームを活用することで、短期間での立ち上げや運用を成功させることができます。企業は、自社の現状と将来的なニーズを踏まえ、最適なSRE戦略を選択することが重要です。

当社では、上記の間をとって、お客様社内へのSREチームの立ち上げを実施することもできます。具体的には、数名のお客様SREチームに経験豊富な当社メンバーも数名参画し、チームの習熟度を高めながら、お客様SREチームがひとり立ちすることを支援しています。

7. まとめ

SREを外部に委託することは、システムの信頼性向上や運用効率化において多くのメリットをもたらします。外部委託による柔軟なリソース活用や、豊富な経験を持つチームによる迅速な対応は、特に大規模なシステム運用において有効です。しかし、外部委託にはコストや適切なパートナー選びといった課題も伴います。

SREの外部委託を成功させるためには、単なる技術的なサポートに留まらず、企業のビジネス目標やエンドユーザー体験にまで貢献できる外部パートナーを選ぶことが不可欠です。SREを自社の成長戦略にどのように組み込むかを明確にし、信頼できるパートナーと連携することで、システム運用の最適化と企業の成長を両立させることが可能です。

SREの外部委託に関するご相談や詳細については、ぜひお問い合わせください。貴社のニーズに合わせた最適なソリューションを提供し、システム運用の成功を支援します。

X（旧Twitter）・Facebookで定期的に情報発信しています！
Follow @acceluniverse

1. Gartner社による生成AIのレポート
2. 生成AI導入の進め方
3. まとめ

Gartner社による生成AIのレポート

Gartner社は、データ品質の低さ、リスク管理の不十分さ、コストの増大、ビジネス価値の不明確さなどの理由で、2025年末までに生成AIプロジェクトの30％がPoC以降に中止されるだろうと発表しました。

2024/07/29に発表されたGartner社によるレポート

2024/7/29にシドニーで開催されたGartner Data & Analytics Summit

Gartner Data & Analytics Summitで講演した、Gartner社のRita Sallam氏は、「今までされてきた誇大宣伝の後、各社の経営者は生成AIに実施した投資回収を待ちきれず、生成AIの価値を表明することに苦労しています。生成AIプロジェクトの範囲が広がるにつれて、システム開発・利用に必要な金銭的負担がますます大きくなっています。」と話しました。

Gartner社によると、生成AIは生産性向上・業務効率化のために使用されることが多いですが、会社の利益に結びつけることが難しく、投資判断をしにくい背景があると述べられています。

生成AI導入にかかる費用例

下記はGartner社が発表した生成AI導入にかかる費用例です。プロジェクトの規模に応じてかかる費用は大幅に変動するため、参考値としてお受け取りいただきたいですが、投資に見合うためのシステム導入をするためには、新たなビジネスチャンス（コスト削減ではなく、売上増加）を目指して生成AIを導入する必要がありそうです。

「残念ながら、生成AIには万能なソリューションはなく、コストは今までのシステム開発や導入に比べて不確実性が大きいです。」とRita Sallam氏は言います。「コストは、支出額、投資するユースケース、採用する導入アプローチによって決まります。市場を大きく変えるために生成AIをあらゆるところに導入したいと考えている場合や、生産性向上や既存プロセスの拡張に重点を置く堅実な場合など、費用、リスク、変動性、戦略的影響のレベルはそれぞれ異なります。」

生成AI導入に後ろ向きなことを書いてしまいましたが、導入の効果・成功例は多分にあります。Gartner社のレポートWhat Mature Organizations Do Differently for AI Successでは、ユース ケース、職種、従業員のスキル レベルに応じて異なるさまざまなビジネス改善を報告しています。最近の822名を対象とした調査では、回答者の平均では15.8%の収益増加、15.2%のコスト削減、22.6%の生産性向上が報告されており、使い所を適切に見極めることで、効果を得られることが分かっています。

次の章から生成AIプロジェクトの進め方を紹介します。

生成AI導入の進め方

1. 生成AIの得意不得意を知る

まず生成AIがどのようにビジネスに貢献できるかを理解することが大切です。生成AIとは、テキスト、画像、音声など、様々な形式のコンテンツを自動的に生成する技術です。下記に代表的な得意分野を記載します。

代表的な活用分野

• カスタマーサポートの自動化
• 商品説明やコンテンツの自動生成
• デザインや広告素材の生成
• 自動テキスト要約やレポート作成

2. プロジェクトの目的と目標を決める

まずビジネス課題を明確にするところから始まります。どのような問題を解決したいのか、あるいはどのプロセスを効率化したいのかを具体的に定義します。

• 目的の設定: 生成AIを導入することで達成したいゴールは何か？
• KPIの設定: 生成AIの効果を測るための指標（例：生成されたコンテンツの量、品質、時間の短縮など）を設定します。

3. データの収集と準備

自社のナレッジを学習させるためには、大量のデータが必要です。データの品質が精度に大きく影響します。以下のステップを踏んで、データの質を確保します。

• データの収集: 自社のデータや公開されているデータセットを活用します。
• データの前処理: データのクリーニングや正規化を行い、ノイズを除去します。
• データのアノテーション: 必要に応じて、データにラベル付けを行い、モデルが効果的に学習できるようにします。

4. モデル選定とカスタマイズ

生成AIモデルには、既存のオープンソースモデルやクラウドサービスで提供されているモデルを利用する方法があります。たとえば、OpenAIのGPTシリーズやDALL-Eなどの大規模言語モデルが有名です。

• 既存モデルの活用: 既存の生成AIモデルを使用すれば、導入がスムーズで費用対効果が高いです。
• カスタムモデルの構築: 自社のビジネスニーズに合わせてモデルをカスタマイズする場合、ファインチューニングが必要です。

5. インフラの選定と構築

生成AIは計算リソースを大量に使用するため、適切なインフラが必要です。クラウドサービス（AWS、GCP、Azureなど）を活用すると、スケーラビリティやコスト面で柔軟に対応できます。

• クラウドインフラの構築: 生成AIモデルのトレーニングや推論に最適化されたインフラを用意します。
• コストの最適化: 必要に応じてオンデマンドリソースを活用し、コストを管理します。

6. テストとパイロット運用

AIモデルの導入前には、十分なテストとパイロット運用を行う必要があります。生成AIの出力品質を確認し、ビジネス要件に合致しているかどうかを評価します。

• 生成結果の検証: 出力されたコンテンツが期待通りか、ユーザーが満足できる品質かを確認します。
• パイロット運用: 小規模なプロジェクトでまず運用を開始し、実際の運用に耐えられるかテストします。

7. 生成AIの運用と改善

生成AIは、導入した後も継続的な改善が可能です。運用中に得られたフィードバックをもとに、微調整を行います。

• パフォーマンスモニタリング: モデルの出力やパフォーマンスを監視し、問題があれば対応します。
• 継続的な改善: 新しいデータや技術を取り入れて、AIモデルを進化させ続けます。




まとめ

生成AIが「既存のデータを活用し、新たなコンテンツ（文章・画像・音声など）などまだ得られていないものを作る技術」であるため、その技術を作ることも正解のないプロジェクトです。

正解のない、つまり生成AIプロジェクトは場当たり的になってしまうのか？とご質問いただくことが多いのですが、それは違います。ここは他のシステム開発プロジェクトと同じで、適切な準備と計画が成功の鍵を握ります。目標を明確にし、データを整備し、生成AIを段階的に導入することで、途中で頓挫してしまう・システム構築したけれど使えない・想定より費用がかかる、などの失敗へのリスクを低減します。

当社では、生成AIの活用にむけて無料相談会を実施しています。みなさんが考えていることを具体化させる、次のタスク・ステップを明確にする、生成AIでできるか回答する、などのようなご相談も大歓迎です。ぜひお気軽にお問い合わせください。






X（旧Twitter）・Facebookで定期的に情報発信しています！
Follow @acceluniverse

目次

1. はじめに
2. SaaS活用に至る変遷
3. 連携基盤構築のアプローチ
4. 事例

はじめに

デジタル化が進んだことでSaaSの活用が増えています。

SaaSはクラウドサービスの一部で、総務省の「令和4年通信利用動向調査」によると、クラウドサービスを一部でも利用している企業の割合は、2022年には72.2％に達しています※ 総務省 令和4年通信利用動向調査。
そのうち、クラウドサービスの効果について、「非常に効果があった」または「ある程度効果があった」と回答した企業の割合は87.1％と、多くの企業が導入効果を感じており、今後もSaaS利用は加速していくでしょう。

SaaSは便利ですが、その急速な普及に伴い、システム企画部門にとって新たな課題が生じています。
各部署で独自に導入されたSaaSのデータ連携や、異なるSaaS間での業務効率の低下などが代表的な課題です。

本ブログでは、複数のSaaSの組み合わせ・データ連携に頭を悩ませている方向けに、当社がおすすめしている解決策を紹介いたします。

SaaS活用に至る変遷

以前は、スクラッチ開発で自社業務にマッチしたシステムや、SaaS追加開発し、ひとつのシステムで関連業務をすべてまかなうシステムが多く構築されていました。
その方法では、導入までに時間がかかること、SaaSのバージョンアップで追加開発箇所に不具合が生じることなど、導入前後に大きな課題を引き起こしました。

これを解消するために、近年ではSaaSは追加開発せず、複数SaaSを組み合わせて利用することが増えました。

そのため、「どの組み合わせが最適か」「複数のSaaSが業務に合わせてデータが繋がらず、データを2重管理している」など、新たな課題が出現しています。

SaaSを連携させるためのデータ連携基盤を構築し、APIで連携させるアーキテクチャを提案しています。
SaaS同士のデータ連携はもちろん、連携すべきシステムを追加する際も、連携基盤へ連携するため将来的なメンテナンス性も高まります。

複数のSaaSシステムがそれぞれ連携するイメージと、今回提案している、SaaSを連携させるためのデータ連携基盤を構築するイメージを図で表現します。

複数のSaaSシステムがそれぞれ連携する

それぞれのSaaSシステム同士が直接繋がっており、連携の数が増えるに従って接続の複雑さが増していくことがわかります。 このような接続方法では、各システムごとに個別の連携開発が必要となり、効率が悪くなる傾向があります。

提案：データ連携基盤を介して複数システムが連携する

各SaaSシステムはデータ連携基盤に接続されており、システム同士が直接繋がるのではなく、連携基盤を通じてデータがやり取りされます。
これにより、各システム同士の個別の接続開発が不要となり、連携の複雑さが大幅に削減されます。 このようなアーキテクチャは、拡張性とメンテナンスのしやすさを向上させる効果があります。

連携基盤構築のアプローチ

(1) 現状分析と要件定義
- 連携する各SaaSシステムの現状を把握し、どのデータがどのシステムで必要かを明確にする。
- 各システム間のデータの流れや連携頻度、形式を定義する。

(2) アーキテクチャ設計
- 連携基盤の基本アーキテクチャを設計。APIゲートウェイ、メッセージキュー、ETL（Extract/Transform/Load）ツール、データ変換機能などの必要なコンポーネントを検討する。
- セキュリティやデータの可視性・統制を含め、どのようにデータを管理するか設計する。

(3) APIおよびデータフォーマットの標準化
- すべてのシステムが統一されたAPIを介して接続できるようにする。
- 連携データのフォーマット（JSON、XML、CSVなど）やバージョニングの標準化を行う。

(4) データ変換・マッピング
- 各SaaSシステムが異なるデータ形式やフィールドを使用している場合、データのマッピング・変換処理を設計する。ETLツールを活用してデータの抽出、変換、ロードを実行する。

(5) リアルタイム連携とバッチ処理の設計
- リアルタイムでデータ連携が必要なケースと、バッチ処理で定期的に連携するケースを分け、システムに負荷がかからないよう設計する。
- それぞれに適したメッセージングツールやスケジューリングツールを導入する。

(6) セキュリティとアクセス管理
- APIアクセスの認証・認可を設置し、データの暗号化やログ管理を実施する。
- 連携するシステムごとにアクセス権を細かく設定し、データの安全性を確保する。

(7) モニタリングとエラーハンドリング
- 連携基盤に対する監視を導入し、リアルタイムでエラーやパフォーマンス問題を検知できるようにする（例：ログ管理ツールやアラートシステム）。
- エラーが発生した場合のリトライやエラーハンドリングの設計も重要。

(8) テストと検証
- 各SaaSシステム間のデータのやり取りを詳細にテストし、データが正しく連携されることを確認する。
- スケーラビリティやパフォーマンスのテストも実施し、将来的な負荷に耐えられるか検証する。

(9) 運用と保守
- データ連携基盤を運用に移行し、定期的なメンテナンスやシステム更新、データフォーマットの変更に対応できる体制を整備する。
- 新しいSaaSシステムが追加された際に、スムーズに統合できるように柔軟性を持たせる。

これらのアプローチを順次実行することで、安定したデータ連携基盤を構築できます。構築後は、継続的な監視と改善が重要です。

事例

ここでは2つの事例を紹介します。

Salesforceをデータ連携基盤に使用した事例

複数店舗を持たれている to C向けの事業を実施している会社様です。
店舗やコールセンターで得られたお客様からの声を、適切に本社に連携し、分析用にデータを蓄積する必要があります。
もともとはSalesforceが導入されていましたが、店舗やコールセンターでは機能が過剰であること、データ分析はもっと高性能な機能が必要であることから当社に相談いただきました。

アプローチ

• 店舗・コールセンターのデータ入力用の画面を構築し、データはSalesforceにAPI連携。
  
• データ分析は、BI専用ツール（Amazon QuickSight）を導入し、Salesforceと簡単に連携。
  
  

システム構成イメージ

メリット：既存システムを活かし、業務の効率化とデータ分析の強化

• 既存のSalesforceおよび蓄積されたデータを活かすことができたこと
  
• 店舗・コールセンター業務に特化したシステム導入により、現場のキャッチアップ期間を最低限にできたこと
  
• BIツールは、AWSマネージドサービスを活用し、構築費用・期間を最低限にできたこと
  

SaaSとスクラッチ開発を組み合わせた事例

百貨店などに出店されている to C向けの商品の販売・製造を実施している会社様です。
百貨店内の店舗から注文され、在庫を確認し、出荷する一連の流れを、電話やExcel管理・目視チェックなど、ややアナログな環境で運用されていました。
今後の事業拡大（=注文数・生産数増加）を見越して、業務効率を上げるためにシステム化を検討され、当社に相談いただきました。

アプローチ

• 標準化しやすいい業務はSaaSに置き換え
  
• 標準化しにくく、お客様独自の業務がスクラッチで開発
  
• 各システムを連携するハブを構築し、APIでデータ連携
  
  

システム構成イメージ

メリット：システムの柔軟性は維持したまま、業務の標準化

• SaaSとスクラッチ開発を組み合わせることで、構築費用・期間を最低限にできたこと
  
• 各システムを疎結合にし、システムリプレイス・システム追加構築をしやすい構成にしていること
  

業務と密接に関わっているSaaSの連携は「これだけやればいい」といった正解がありません。
お客様ごとの業務をヒアリングし、適切な構成を提案いたします。ぜひお気軽にご相談ください。

X（旧Twitter）・Facebookで定期的に情報発信しています！
Follow @acceluniverse

データ分析基盤構築とは、大量のデータを蓄積・変換・分析するためのインフラを開発することです。主軸となるデータレイク・データウェアハウス・BIツールの他、NoSQLデータベース、データパイプラインツール、ETLツールなど様々な要素があり、それぞれ様々なベンダーから多種多様な製品が出ています。

比較項目は膨大で、複雑です。性能・機能・セキュリティ・コスト......一体何を基準に選べばよいのでしょうか。当社には一つの戦略があります。それは、

" 分析ツールはコスト最適性で、データ基盤は運用性で選ぶ。 "

これがデータ利活用を成功させるための鍵です。以下のように、2つのポイントに分けられます。

詳しく解説していきます。

秘訣①BIツールの二極化と、「コスト最適」な配分

まずは実際に、分析ツールの費用をご紹介しましょう。データ利活用の最初に導入するデータ分析ツールとしては、BIツールが一般的です。TableauとQuickSightという2つのBIツールを比較します。1,000人の従業員が利用する場合、支払額は次のようになります。

［ケース1］

• Tableau：約3,000万円／年
• QuickSight：約800万円／年

3〜4倍の差です。

極端な例ではありません。BIツールの価格は二極化しており、このくらい高いか、安いか、どちらかです。最初に適切な製品を導入できないと、その後毎年不必要なコストがかかり続けてしまいます。

とはいえ高価なツールには、独自の機能や、高度な利用をする際の使いやすさがあります。例えばTableauはドラッグ＆ドロップのような直感的な操作によって、簡単・迅速にデータ分析ができ、分析を主務とするユーザーに向いています。ただ一律に安価なものを導入すると、結局機能が不足してデータ利活用が進まないという本末転倒の事態になるでしょう。

「安ければいい」でも「高機能であればいい」でもなく、「必要な利用者にだけ必要な機能を」。それが「コスト最適化」の観点です。具体的には、

• 自社のニーズを洗い出し、
• 「誰が・どんなタスクを・どの程度」できる必要があるかを見極め、
• それぞれに必要十分なツールを用意すること。

これによってコスト最適な利活用推進を図ることが重要なのです。

ツール配分の例を考えましょう。先ほどの従業員1,000人のうち、データからインサイトを得るための分析業務を行うのは経営戦略部と店舗開発部の計100人で、その他の900人はあらかじめ作成された可視化ダッシュボードを日々の業務で参照するだけだとします。分析を行う100人（とツールを管理するエンジニアチーム）がTableauを利用し、残りの900人はQuickSightを利用するのが適切です。費用は以下の通りです。

［ケース2］

• Tableau：約700万円／年
• QuickSight：約800万円／年
• 合計：約1,500万円／年

さらに、従業員に対する細かいアクセス権限の設定などが不必要である場合、QuickSightの代わりに無料の Looker Studio を利用できます。この場合、費用はさらに安くなります。

［ケース3］

• Tableau：約700万円／年
• Looker Studio：0円／年
• 合計：約700万円／年

これはあくまで簡単な例ですが、「分析か／可視化か」「細かいアクセス権限管理が必要か／不要か」という観点は一般的なものです。自社のニーズをこのような形で整理し、それに合った適切なツールを選んでいくというイメージをつけましょう。

では具体的に、どのようなツールがあるのでしょうか。高価・高機能なものでは、Board、Domo、Qlikといった有名製品にそれぞれ特長がありますが、AIによる自然言語処理で直感的に使えるThoughtSpotのような製品も生産性を向上し、使い始めのハードルを下げるでしょう。安価なものはGoogleの Looker Studio が代表的ですが、OSSのMetabaseも、自動でダッシュボードを生成してくれるX-rayという機能に魅力があります。

秘訣②利活用に必要な「運用性の高いデータ基盤」

「データ基盤」とは、データを利用可能な形で蓄積するためのインフラストラクチャのことです。と一口に言っても、実際にはデータパイプライン・データレイク・ETL・データウェアハウスと、多くの構成要素があります。それぞれの構成要素を動かすのに必要なプログラムや設定の項目は非常に多く、開発や運用の工数が大きくなります。分析ツールが費用の勘所であるのに対して、データ基盤はいわば工数の勘所です。

しかし本当に工数を割くべきなのは、開発や運用ではありません。要件定義とそれに基づく継続的デリバリーに力を入れてこそ、将来の成功があります。データ基盤の構築はDXやクラウド移行と似ており、現行のシステムや業務自体の変化を伴うものです。様々なステークホルダーへの説明・ヒアリング・調整が不足していれば、プロジェクトは失敗へ向かいます。一方で、プロジェクトのエンジニアチームが主体となって調整を行い、使う人たちにとって使いやすいデータ基盤を構築することができれば、利活用は順調な滑り出しを迎えられます。データ基盤は一度出来上がった後でも現場から様々な要望が舞い込んできますが、それに応じられるコミュニケーション体制も確立できるはずです。

そのため、エンジニアチームがコミュニケーションに時間を割けるように、データ基盤では保守運用性の高い構成を選択し、開発工数も抑えることが重要になります。

その視点で一般的に優れているのは、基盤をAWSサービスだけで構築することです。AWSでは、データウェアハウスのメンテナンス自動化、アクセス権限やメタデータの管理一本化などの恩恵を得られます。また、AWS上に構築されることの多い対向業務システムとの連携もスムーズです。

もちろん、どのような場合でもAWSがベストな訳ではありません。Google Cloudは先進的な性能によって、データ基盤市場に確固たる地位を築いています。データウェアハウスについては、独自の機能と料金システムで支持を伸ばしているSnowflakeも検討の余地があります。

データ利活用のスタートダッシュ

"分析ツールはコスト最適性で、データ基盤は運用性で選ぶ。"というテーマについて解説してきました。それでは、なぜこれが望ましい戦略なのでしょうか。それは、「データ利活用／データドリブン経営を、最低限のコストで、スムーズに始められる」からです。このうち「最低限のコスト」については、分析ツールを適切に選ぶことで高すぎる負担を避けられるということが、まずあります。運用性の高いデータ基盤も、保守・改修を含めたTCOを抑えることで、コストカットに繋がります。

では、「スムーズに始められる」とはどういうことでしょうか。データ利活用／データドリブン経営の「スムーズな開始」を阻む要因は、主に2つ考えられます。1つ目は「利用者のリテラシー不足」で、「ツールの操作がわからない」「データが何に使えるのかわからない」といったものです。2つ目は「エンジニアの設計ミス」で、「ツールのスペックが足りない」「使い物にならないデータを生成している」などです。この2種類の失敗は、「基盤を使う人たちとエンジニアチームのコミュニケーション不足」という1つの失敗から出てくる結果に過ぎません。

基盤構築の段階から、エンジニアチームが積極的に利用者に関わっていくことが重要なのです。コミュニケーションを重ねることで、利用者がデータを理解していくことができます。エンジニアチームの側も、フィードバックから要件定義、製品選定やスキーマ設計のヒントを与えられます。

「コスト最適に・スムーズに始める」ことにゴールを置いて基盤構築をすれば、その後のデータカルチャーの浸透、データによる収益拡大といった経営目標へと繋がっていくでしょう。そのためには、分析ツールはコスト最適性で、データ基盤は運用性で選ぶことになります。

最適な製品選定と要件調整のご提供

アクセルユニバース株式会社では、当社の掲げる「顧客中心主義」に基づいて、お客様に合わせた最適な分析ツール・データ基盤を立案・開発いたします。お客様の状況をヒアリングし、適切なプランをご提案することを得意とする企業です。

また、必要に応じて、お客様部署間のファシリテーションなどの総合的なITコンサルティングを提供しております。

まずは追加でお聞きになりたい情報から、お気軽にご相談ください。

（お問い合わせはこちら）

BIツールの費用計算

いずれも記事公開時点での情報です。1ドル＝150円、有効数字1桁としました。 Tableau公式の価格情報 、AWS公式の料金情報 をもとに計算しています。

［ケース1］ Tableau：「Tableau Creator」10人、「Tableau Explorer」100人、「Tableau Viewer」890人。 QuickSight：「管理者」10人、「作成者」100人、「閲覧者」890人。

［ケース2］ Tableau：「Tableau Creator」10人、「Tableau Explorer」100人。 QuickSight：「管理者」10人、「作成者」100人、「閲覧者」790人。

［ケース3］ Tableau：「Tableau Creator」10人、「Tableau Explorer」100人。 Looker Studio：無料ユーザーのみ。

貴社のDX（デジタルトランスフォーメーション）は、もうお済みでしょうか..？

経産省が警鐘をならす「2025年の崖」。

既にご存知の方も多いと思います。

昨今、企業活動とITが密接に関連する状況において、当該レポートは全ての企業様にとって他人事ではない内容であるように思えました。

あらためて経産省の発表内容を振り返るとともに、本記事が企業様の次の意思決定・行動のリマインドとなれば幸いでございます。

経済産業省からの警鐘

2018年9月に経済産業省から「DXレポート～ITシステム「2025年の崖」の克服とDXの本格的な展開～」というレポートが発表されています。

※「経済産業省Webサイト」へのリンクは こちら

このレポートを読むと、大きく２つの内容が語られていると解釈しました。

１）レガシーシステムに起因し、各企業のシステム障害リスクが増加。
　　2025年以降、国内のシステム障害による経済損失が 最大12兆円／年の発生する可能性がある。

2）レガシーシステムは、システム障害リスクの要因となるだけではなく、各企業の将来の成長・競争力強化のためのDX
　（デジタルトランスフォーメーション）を実現する妨げにもなっている。

着目すべきは、クラウドやAI、IoTといったデジタル技術の積極採用だけではなく、既存のシステムがレガシー化していないか？また、レガシー化している場合はそれらの対処は大丈夫か？といった、足元に対して警鐘を鳴らしているという点だと感じました。既存システムがレガシー化している場合、既存の環境を維持するだけでも企業にとって大きな損失を招く可能性があるということを示唆しています。

貴社のシステムは、大丈夫でしょうか？？

レガシーシステムとは..？

レガシーシステムという言葉の定義を整理すると、
「技術面の老朽化、システムの肥大化・複雑化、ブラックボックス化等の問題があり、その結果として経営・事業戦略上の足かせ、高コスト構造の原因となっているシステム」のことと記されています。

・技術の老朽化 とは..
システムの仕様や使用している技術を把握している人材がリタイアし、メンテナンスのスキルを持つ人材の枯渇が危惧される状態

・システムの肥大化・複雑化 とは..
過剰なカスタマイズが積み重なることで、システム全体の規模が膨らんだり内部のロジックが複雑になっているといった状態

・ブラックボックス化 とは..
技術の老朽化とシステムの肥大化・複雑化が重なり、システムの全貌と機能の意義が分からなくなっている状態

今回の警鐘をうけとめ、まずは企業様内で上記のような事象が発生していないかどうか、発生している場合それはどの程度の規模なのか、早期に確認を行うことが必要と感じます。

ある日突然、いつも使用しているシステムがダウンしたら..、そのダウンしたシステムがレガシーシステムであったら..
復旧にどれほどの時間と労力が必要となるのか..（そもそも、復旧が可能なのか..）復旧までの期間事業に与える業務のインパクトと損失はどの程度になるのか..この記事を読まれた企業様では、このような状況にないことを祈るばかりです。

DX（デジタルトランスフォーメーション）とは..？

DX（デジタルトランスフォーメーション）という言葉の定義についても整理してみたいと思います。

・DXという言葉の発祥
2004年にスウェーデンのウメオ大学のエリック・ストルターマン教授が提唱されたと言われています。
DXとは「ITの浸透が、人々の生活をあらゆる面でより良い方向に変化させる」という概念を示すようです。

概念であるためか、この段階で具体的なアクションへ落とし込むのはかなり難しいように感じます。

・経産省による定義
経産省は、DXという概念を日本向けにもう少し具体化しており、「 DX 推進ガイドライン 」 の中で以下のように定義付けています。

「企業がビジネス環境の激しい変化に対応し、データとデジタル技術を活用して、顧客や社会のニーズを基に、製品やサービス、ビジネスモデルを変革するとともに、業務そのものや、組織、プロセス、企業文化・風土を変革し、競争上の優位性を確立すること」

※経産省の「DX 推進ガイドライン」は こちら

どのような状態になることをDXというのか、それが定義されたことで言葉の意味が具体的になったと感じます。 新時代（新しいルール）へアジャストしていくため、更には新時代でも競争上の優位性を確立していくために、既存の破壊と再構築を視野に入れた変化の取り組みこそがDXだと。そして、レガシーシステムに対する対策だけではなく、このDXを積極的に進めていくべきであると、記載されています。

レガシーシステムの問題点を解消し、企業でDXを推進するための方法とは..？

レガシーシステムの問題とDXに関して、重要であることのイメージをなんとなく持っていただけたかと思います。
一方で、DXの実現は非常に困難であると感じられた企業様も少なくないのではないでしょうか？

経産省のレポートでは、どのようにDXを進めていけばよいか、ガイドラインを示しています。（後述の図１、２）
しかし、各社状況やスタートラインが異なっているため、現実的には安易ではない取り組みになるかと思います。

ただ、困難を困難のままにしてしまうと、それ以上前に進みません。
困難な事をどうやったら実現できるか、問題を解ける状態に分解しながら進めていくことが重要であると考えます。

そのファーストステップは、やはり「現状の可視化と将来に起こり得る事象への定量的なシミュレーション」ではないかと考えます。
今が把握できて、将来の危惧or飛躍を定量的に語れるのであれば、経営陣／現場ともにそれを回避・改善or推進・支援する方向に動こうとなるのではないでしょうか？また、そのような協力を促す説得力のある材料になるのではないでしょうか？ （進行方向に崖があるにもかかわらず、昨日までと同じルートと歩き方にしがみついく人がいたのであれば、それは違った意味で危機ですが..）

現在地がわかり、目的地が決まる、その差を埋める行動をNext Actionとする。Next Actionも重要度や影響度から優先度をしっかりと持ち、濃淡を付けて計画的に進めていく..そんな動き出しが必要と考えます。

図1

出典：「DXレポート～ITシステム「2025年の崖」の克服とDXの本格的な展開～」（経済産業省）

図2

出典：「DXレポート～ITシステム「2025年の崖」の克服とDXの本格的な展開～」（経済産業省）

AUCがお手伝いできること

（最後は露骨な宣伝となってしまいますが..）

通常業務と平行してレガシーシステムの対応やDXの推進を行っていくのは至難の業である思います。
また、専任の採用もすぐには難しい対応であると思います。

現状の可視化や今後の展望の検討支援、具体的なシステム開発やインフラ開発とその保守運用。機械学習の企画〜PoC〜システム実装など..弊社がお手伝いできる色々なシチュエーションがあると考えております。

DXがまだお済みでなく、これから本格的に進めていこうとしている企業様、弊社サービス概要ページのリンクを添えておきますので、興味をもっていただけましたら、お気軽にお問合せください。

※「ITコンサルティングサービス」ページは こちら

※「新規Webサービスの構築」ページは こちら

※「クラウド構築・運用保守」ページは こちら

※「お問い合わせ」ページは こちら