re:Invent 2023: AWSが語るクラウドアプリケーションのロックインと切り替えコスト
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2023 - Do modern cloud applications lock you in? (ARC307)
この動画では、クラウドアプリケーションのロックインと切り替えコストについて深く掘り下げます。AWSのGregor Hohpeが、オプション理論や財務管理の概念を用いて、この複雑な問題を多次元的に分析します。managed open sourceの活用、開発速度の向上、そして心理的ロックインを避けるための設計意図の維持など、具体的な戦略を紹介。エンジニアの皆さんの思考を刺激する、ニュアンスに富んだディスカッションをお楽しみください。 ※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
本編
モダンなクラウドアプリケーションの定義と利点
ARC307へようこそ。ここでは、モダンなクラウドアプリケーションがなぜ素晴らしいのか、そして、モダンなクラウドアプリケーションを使用することで、もし必要になった場合に、アプリケーションを別の場所に移行することがより難しくなるかどうかについて話します。昨年、この講演をしたとき、私は実はエンタープライズストラテジストで、サーバーレスを少し触っていました。そして、自分の言葉に責任を持つように、今は実際にサーバーレスチームの一員となりました。エレベーターで随分下まで降りましたが、まだ少しは戦略的な考え方を持ち続けており、戦略家らしい服装も維持しています。
二つのことが起こりました。セッションを300レベルにアップグレードし、そして明らかに部屋もアップグレードしました。ですので、ショーをお楽しみください。まず、モダンなクラウドアプリケーションから始めましょう。これは単純な言葉ですが、よくあることですが、クラウドアプリケーションを「モダン」にする要素について、多くの人がそれぞれ異なるビジョンや意見を持っています。そこで、私たちが何について話しているのかを明確にするために、少しだけ前置きと定義から始めましょう。
クラウドアプリケーションのモダン化：ランタイムだけでない多面的な要素
アプリケーションのモダン化について話すとき、通常見られるグラフはこのようなものです。残念ながら、このグラフは二つの理由で間違っています。まず、コンテナとサーバーレスは二つの異なるものではありません。Lambdaにコンテナイメージをデプロイすることができますし、Fargate ECSをコンテナのサーバーレスランタイムとして持つこともできます。そのため、これはすでに正確ではありません。次に、モダンなアプリケーションについて話すとき、それはランタイムだけの問題ではありません。
もし、完全に手動でこれらを組み立てているとしたら？それはそれほどモダンとは言えないでしょう。観測可能性がなく、マネージドサービスを使用せず、巨大なモノリスで、APIがなく、何とも統合されておらず、COBOLで書かれているとしたら？それは私たちがモダンなクラウドアプリケーションと呼ぶものではありません。そのため、この図を少し修正する必要があります。そして、モダンなアプリケーションとは、クラウドを最も有効に活用するものだと言えます。私個人の意見では、それこそが実際にクラウドネイティブと呼ぶものです - クラウドが設計された目的のために使用し、その機能を完全に活用するものです。
それがとても素晴らしいことである理由は、これらの素晴らしい利点が得られるからです。より回復力があり、可用性が高く、スケーラブルなアプリケーションが得られ、コストの透明性を含むより高い透明性が得られます。サーバーに対して支払いをしているものの、それが今実際に何をしているのかよくわからない状況ではなく、代わりに関数の呼び出しに対して支払いをします。つまり、Lambdaにビジネス機能がある場合、それに対して支払いをすることで、ビジネスで何が起こっているのか、そしてコードが生成している価値を知ることができ、それに対してコストを対応付けることができます。
このアプローチにより、変更をより迅速に行うことができ、アジリティが向上します。また、細分化されているため、可観測性も向上します。パフォーマンスのホットスポットがどこにあるかを特定できるのです。望むように動作しない巨大なブラックボックスではなく、分離して調整できる細かい粒度のコンポーネントがあるため、多くの利点が得られます。
ロックインと切り替えコストの多次元的な考察
そこで、この定義を修正し、先ほどのグラフは忘れましょう。私たちが本当に話しているのは、細かい粒度のアプリケーションについてです。 これにより、何か問題が発生した場合の障害分離など、いくつかの優れた機能が得られます。独立したスケーラビリティが可能になり、これらは疎結合なので、システム全体に変更を波及させることなく変更を加えることができます。また、多くの場合、イベント駆動型でもあります。これは素晴らしい非同期スタイルです。これにより、運用面で望ましい側面が得られるだけでなく、このような種類のアプリケーションを簡単に拡張し、強化することができます。
誰もが熱心に「素晴らしい、ぜひ参加したい」と言います。ここにいる皆さんは既に納得済みかもしれませんね。しかし、次に「これを採用した場合、デメリットはありますか？代償を払うことになりますか？そしてその代償はロックインされることですか？」という質問が出てきます。 アーキテクトとして、私はこのような質問が好きです。「今は心配しないで、そんなことはない」と言う人もいるでしょう。しかし、心配すべきです。これはあなたの設計の一部なのです。すべてのシナリオを考慮すべきで、これは非常に正当な質問です。
しかし、アーキテクトとして、私はこのような質問を分解しようとしています。「これは常に良い」「これは常に悪い」というような恐怖を煽るようなことはしません。アーキテクチャの世界はトレードオフの世界です。常に正しいものと常に間違っているものがあるわけではありません。私はよく「アーキテクチャはハリウッド映画ではない、善と悪の戦いではない、決定を下し、理解することだ」と言います。
トレードオフです。最も強力な手段は2つあります。1つは問題をより多くの次元に分解することです。もう1つは、利用可能なソリューション空間の範囲を広げることです。これは少し抽象的に聞こえるかもしれませんが、これこそが私が皆さんにお伝えしたいことです。そして、それをロックインとスイッチングコストに関する私たちのお気に入りの（あるいは嫌いな）質問にマッピングしていきます。
「サーバーレスで全てを実現したいけれど、できないのでは？」という質問をする人々の考え方は、世界を一次元的に見ています。彼らは右側に欲しいものがすべてあることをはっきりと理解しています。私がすでに説明したように、それは最新で、きめ細かく、回復力があり、スケーラブルです。マネージドサービスを使用し、toil（単調な作業）を減らせます。右側には多くの良いことがあるのは明らかです。しかし、「その側にもリスクがあるのでは？」という別の領域もあります。残念ながら、この一次元的な見方はやや悲しいものです。なぜなら、このスペクトル上に幸せな場所はないからです。右側にいれば、これらの素晴らしい利点を得られますが、他の面で損失を被ります。左側にいれば、実際には得られない素晴らしいものがすべてあるかもしれません。つまり、ここに幸せな場所はなく、これはやや憂鬱な状況です。
切り替えコストの次元：ベンダー、製品、スキルセット
そこから素早く離れて、より多くの次元を見てみましょう。これを分解してみましょう。これは左か右かではなく、2つの独立した次元です。小学5年生の幾何学を思い出してください。これは以前の一次元のグラフを二次元空間にプロットしたものです。単純に直線が得られます。これは前のスライドで見たものとまったく同じですが、今はより広い宇宙で考えています。2つの次元があるので、全く異なる議論ができます。これは本当に上がっていくのか、それともこの曲線は平坦になるのか？この曲線を押し上げることはできるのか？これがどれほど融通が利くかを本当に議論でき、他にも魔法のようなことができます。
世界は2次元だけではありません。3次元目はあるでしょうか？本当に望むなら4次元目もあるかもしれませんが、そこまでは行きません。3次元にとどめておきましょう。しかし、その曲線を平坦にするために押せる3次元目はあるでしょうか？これは典型的なアーキテクトの手法で、一次元的な白黒、善悪の考え方から抜け出し、より多くの次元、ニュアンス、トレードオフを見ることです。では、これを私たちのお気に入りの（あるいは嫌いな）トピックであるlock-inに当てはめてみましょう。
次元の話を続けると、lock-inにも多くの次元があります。多くの人が、lock-inと言えば、vendor lock-inを思い浮かべます。ベンダーが私をロックインしているのか？しかし、それは多くの次元のうちの1つに過ぎません。製品にも切り替えコストがあります。なぜなら、それが本当に問題になっているからです。誰も刑務所に入るわけではなく、誰もロックされるわけではありません。これは切り替えコストの話であり、財務的な考慮事項です。AからBに移行する必要がある場合、労力、時間、お金がどれくらいかかるでしょうか？
これは多くの次元に分解されます。製品がある場合、たとえそれを自社で内製したとしても、そこから移行しようとすれば、無料ではありません。切り替えコストがかかります。バージョンアップグレードにもコストがかかります。多くの方がご存知かもしれませんが、例えばKubernetesという人気のオープンソースプロジェクトを取り上げてみましょう。バージョンアップグレード - 最近、プレビューでサービスを公開しました。それはAmazon EKSの拡張サポートです。これはKubernetes 1、2、3を使用していてアップグレードしていない人々のためのものです。なぜアップグレードしないのでしょうか？怠慢だからでも、やりたくないからでもありません。努力が必要だからです。再テストが必要で、他にもやるべきことがあり、機会コストが高いかもしれません。そのため、今はそのバージョンアップグレードを行っていないのです。
そのため、顧客の要望に応えて、サポート期間を延長しました。これは、あるサービスから別のサービスへ、あるバージョンから別のバージョンへの切り替えコストです。スキルセットについては、既知のものが常に最も扱いやすいものです。新しいことを学ぶと、切り替えコストが発生します。これは二元論ではありません。コンピューターサイエンティストとして、私たちは常に1と0で考えがちですが、アーキテクチャは1と0ではありません。それは灰色の濃淡、スペクトル、トレードオフ、そしてこれらの異なる次元を全て見ることに関するものです。最後のコメントとして、一番下に予想外の面白いものがあります。それは「mental lock-in（心理的ロックイン）」です。これは実際にとても興味深いものなので、後で詳しく説明します。mental lock-inについては心に留めておいてください。
効用と切り替えコストの2x2マトリックス：「受け入れられたロックイン」
では、mental lock-inについて話しましょう。次元の話を続けていきますが、ここでは意思決定によく使用する非常に便利なモデルを使います。2x2マトリックスです。単純すぎるとジョークを言うこともありますが、実際には非常に効果的です。問題を2つの次元に分解し、これらの次元がどのように関連しているかを賢明に考えることができます。
切り替えコストについて話すとき、それが1つの次元です。2つ目の次元は、現在持っているものから得られる効用または価値です。これにより、トピックについてより微妙な見方ができます。この2x2マトリックスでは、4つの象限に分けました。左下は比較的単純です：固有の効用が低く、切り替えコストも低い。これはUSB充電器のようなものです - 1つ失っても、別のを手に入れます。標準化されており、コモディティで、すべて同じなので、議論の余地はあまりありません。
そして、さらに興味深い2つの象限があります。1つは効用はあまり得られないが切り替えが制限されているもの - 古い携帯電話プランや長期契約などを考えてください。これらのモデルは長期的には生き残りにくいことがわかります。誰かが破壊するか、規制当局が介入する可能性があります。顧客にとっても提供者にとってもうまくいきません。右下は興味深いです：固有の効用はあるが切り替えが容易。例は多くありませんが、ソーシャルネットワークがここに当てはまります。異なるネットワークを使用でき、1つを他より好むかもしれませんが、切り替えは簡単です。
最も興味深い象限は右上で、これを「accepted lock-in（受け入れられたロックイン）」と呼びます。ここでは、ある程度の切り替えコストがありますが、固有の効用のために適切なトレードオフを得ていると感じます。これにより異なる視点が得られます：切り替えコストを下げるか、効用を上げるかのどちらかです。これにより、はるかに賢明な会話につながります。
私の良き友人であるAdrian Cocroftは、右上の象限を説明するのに面白い方法を使っています。 彼の講演では、こう尋ねます。「ロックインを心配している人は？」すると全員が手を挙げます。次に「結婚している人は？」と聞くと、みんな自分の手を見て、受け入れられるロックインもあることに気づきます。つまり、潜在的な乗り換えコストよりもメリットの方が大きい場合があるのです。今日は人生の教訓も学べましたね。
ソリューションの範囲を広げる：Platform EngineeringとInternal Developer Platforms
まとめると、多次元的なアプローチは抽象的に聞こえるかもしれませんが、非常に強力な戦略です。単純な「これかあれか」の議論ではなく、乗り換えコストについての知的な会話ができるようになります。コストは素晴らしい指標です。なぜなら問題を財務的な観点から捉え、さまざまな側面を見ることができるからです。これがアーキテクトの戦略その1です。
アーキテクトの戦略その2は、ソリューションの範囲を見て、小さな枠の中だけでなく、スペクトル全体にわたってソリューションを探すことです。ソフトウェア開発、クラウド運用、あるいは従来の運用に携わる人なら誰でもこのモデルを知っています。 よく、機能を構築してデプロイするアプリケーション開発者がいて、その後インフラストラクチャと運用チームがそれを管理する、と考えられています。矢印の専門用語は通常「投げ渡し」で、何か問題が起きたときには「責任転嫁」という逆向きの矢印もあります。
しかし、ワークロードをある場所から別の場所に移す「切り替え」について話すとき、それは「-ility（性質）」の一つです。可用性、保守性、スケーラビリティ、ポータビリティなどのこれらの「-ility」は、しばしば「-ility担当」の責任だと考えられています。これには2つの問題があります。まず、このモデルはもはやうまく機能しません。Serverlessの場合、インフラストラクチャはどこにあるのでしょうか？それはすでに私たちです。次に、ポータビリティはインフラストラクチャの問題だけではありません。アプリケーション開発者が作り出す問題をインフラストラクチャレベルで解決できるという誤った考えがあります。つまり、スケールさせたり、信頼性を高めたりできるという考えです。
しかし、このアプローチは理にかなっていません。問題は発生源で解決すべきで、別のレイヤーで解決すべきではありません。多くの顧客が、Platform EngineeringやInternal Developer Platformsと呼ばれる異なるアプローチを採用しています。このアプローチでも2つのチームを設けることができます。1つは共通要素を扱い、もう1つは個別の機能を扱います。
これらのチームの間のインターフェースは非常に異なります。インフラストラクチャチームに特定のリソースを要求する代わりに、下位レベルのチーム（青いボックスで表現）は上位レベルのチーム（オレンジのボックスで表現）の生産性を向上させるツールを作成します。 この考え方の変化は、ポータビリティとスイッチングコストへのアプローチにも影響を与えます。ここでの2つ目の重要な教訓は、問題を別のレイヤーで解決しようとするのではなく、問題が発生した場所で解決することです。そうすることで、その問題に対処するための最も効果的なツールを活用することができます。
サービスマッピングの限界：クラウドサービスの複雑性
このトピックに関する5つの異なるアプローチについて議論しましょう。そのうち2つはあまりうまく機能しませんが、3つは非常に効果的です。このトピックは、調達や従来のITベンダー選定から生じることが多く、そこでよく使われるツールがサービスマッピングです。人々は、異なるクラウドプロバイダーが仮想マシン、データベース、メッセージキュー、サーバーレス関数などの類似したサービスを提供していると想定します。これは高レベルの視点からは正しいように見えるかもしれませんが、実際には単純化しすぎています。
当社のデータ関連サービスを見てみると、Neptune、時系列データベース、ドキュメントデータベース、リレーショナルデータベース、NoSQLデータベースなど、幅広いサービスがあります。 他のクラウドプロバイダーが全く同じポートフォリオを持っている可能性は低いでしょう。私の意見では、クラウドプロバイダーが互いのカーボンコピーでないことは、選択肢を提供するという点で顧客にとって有益です。しかし、それはまた単純なサービスマッピングが不十分であることも意味しています。
具体的なサービスの例として、Amazon EventBridgeを見てみましょう。EventBridgeはサーバーレスのイベントバスサービスで、簡単に説明すると、イベントを受け取り、フィルタリングして変換し、他の場所にルーティングします。 しかし、ドキュメントからその特性を見ると、長いリストの機能があることがわかります。他のサービスがこれらのプロパティを全て正確に一致させる可能性は非常に低いです。さらに、EventBridgeは単独で存在するわけではなく、他のAWSサービス、IAM、CloudWatch、CloudTrailと統合されています。
一部のベンダーはこのようなサービスマップを使用するかもしれませんが、AWSでは使用していないと思います。なぜなら、それは有用な取り組みではないからです。魅力的に聞こえるかもしれませんが、現実ははるかに複雑です。 したがって、サービスマッピングはクラウドサービスを比較したり、ポータビリティの問題に対処したりする効果的なアプローチではありません。
抽象化レイヤーの課題：物理的特性とコストの問題
このような非効率性を考えると、代替案を検討する必要があります。しかし、簡単に言えば、それほど容易ではありません。そこで、2番目のアプローチに移ります。これはもう少し微妙なアプローチですが、何が機能し、何が機能しないかを理解したいと考えています。このアプローチは、ソフトウェアエンジニアリングの基本的な考え方に基づいています。Andrew Kearneyが「ソフトウェアエンジニアリングの基本理論」と名付けたほど基本的なものです。つまり、間接層をもう1つ追加するだけで、ほぼすべての問題を解決できるということです。この考え方には補足があり、それは「間接層が多すぎることによる問題を受け入れる」ということです。
この概念を適用してみましょう。実際、かなりうまく機能します。間接層を追加することで、技術を組み合わせることができるという生きた証拠があります。私が言うところの「選択肢を与える」ということです。そして、私たちはみなこの例を知っています。例えば、異なるプログラミング言語を使用する選択肢が欲しいとします。これはごく自然な欲求ですが、ここで好みの違いによる争いを引き起こさないよう注意が必要です。強い意見があるのは確かですが、1つのアプリケーションがあり、これらの言語のいずれかを使用する柔軟性が欲しいとしましょう。
アーキテクトとして、私たちはこの仕組みをよく知っています。これらの上に共通の統合層を置くのです。Microservices、Service Mesh、その他良い名前で呼ばれているもの、共通の認証スキーム、共通のデータフォーマットなどです。そうすれば、この問題は解決します。ここで私たちは非常に賢明な操作を行いました。つまり、1つの層を調和させ、いくつかのものを固定したのです。私はこれを「いくつかの選択肢を手放す」と呼んでいます。異なるデータフォーマットや認証スキーム、トランスポートを持つ選択肢を手放すのです。そうすることで、その下の多様性を獲得します。
これが機能するという生きた証拠があります。金融サービス業界から生まれたものです。時々、これをオプション取引と呼びます - いくつかのオプションを売って他のオプションを獲得するのです。そして繰り返しますが、これが機能することを私たちは知っています。これは典型的な抽象化層であり、これは良いことです。同じ概念と同じボックスを使って、ラベルを少し変えるだけで、クラウドに対してもこれができるのではないかと考えるのは非常に自然なことです。この層を置いてこのレベルで調和させれば、すべてうまくいくのではないでしょうか？紙の上では良さそうですが、現実にはそれほど良くありません。
私がこれを説明する方法は次のとおりです。ここは非常に大規模な国際会議で、おそらく100カ国以上からの参加者がいるでしょう。だから、エスペラントのような共通言語を話すべきではないでしょうか？なぜなら、それが私たちが互いに話すことができる共通の層になるからです。はい、それは素晴らしいでしょう。しかし、私たちは皆、ある程度英語を話すことができ、それでなんとかなっています。私はネイティブスピーカーではありませんが、十分に近いです。すべてが十分に良いので、この追加の層は必要ありません。アイデアは健全ですが、広く使用されるようにするのは難しいです。なぜなら、私たちはさらに別のものを学ぶ必要があるからです。
もう少し詳しく見ていきましょう。先ほど、サービス間のニュアンスの違いについて話しました。サービスが互いのカーボンコピーではない理由と、それが実際には良いことである理由についてです。例えば、サービス機能AとBがあり、それらの間に小さなギャップがあるとします。では、どうすべきでしょうか？基本的に2つの選択肢があります。ギャップを埋めるか、ですが、これは難しい作業です。正直に言うと、私自身の経験から言えることです。初期の頃、私はAWSでサーバーレスアプリケーションを構築し、その後別のクラウドに移植しました。私の勤務先を考えると、逆の順序でやるべきだったかもしれませんが、AWSから始めて移植しました。
実際に何が必要かを調べてみました。違いは小さく見えますが、根本的なものです。例えば、Amazon SQSのようなキューには可視性タイムアウトとTTL（Time to Live）がありますが、他のキューにはありませんでした。そのため、私のコードにそれを組み込む必要がありました。サービスに追加することはできません。DynamoDBには原子性操作がありますが、他のデータベースにはありませんでした。そのため、他のデータベースに原子性操作を持たせることはできません。これは簡単にできることではありません。既存のサービスに機能を簡単に追加することはできないのです。
Velocityの重要性：スイッチングコストを削減する第3の次元
さらに問題を複雑にしているのが、AWS re:Inventです。皆さんご存知の通り、昨年は3,300以上の重要な機能とサービスをリリースしました。これは動く標的なので、常にこの作業を続けなければなりません。もちろん、もう一つの選択肢も良いものではありません。最小限に抑えるということですが、そうすると有用性を失ってしまいます。マトリックスを覚えていますか？これでは有用性の軸で妥協することになり、このトレードオフが本当に価値があるかどうかを慎重に考える必要があります。
私はこれを「grim wrapper」と呼んでいます。これらのものをラップすれば全てうまくいくように聞こえますが、実際にはそうではありません。これがうまくいかないもう一つの理由は、論理的な抽象化レイヤーは物理的な特性を抽象化できないということです。
友人の一人と話をしました。彼らはスタートアップ企業で、逆のアプローチを取りました。つまり、最初からサーバーレスネイティブで構築し、その後AWSに移行したのです。彼の言葉はとても興味深いものでした。「2週間かかりました」と言っていました。つまり、実際にはかなり早かったのです。そして彼は「私たちが直面した問題、つまり私たちがしなければならなかったことは、どんな抽象化レイヤーでも助けにならなかったでしょう」と言いました。なぜなら、彼らがする必要があったことは、まさにこういったことだったからです。
価格モデルについてですが、あるサービスは呼び出し回数で課金し、別のサービスは実行時間で課金する、またあるサービスはプロビジョンド容量を持つなど、様々です。抽象化レイヤーを使ってもこの違いはなくなりません。クォータや拡張性についても同様です。Lambdaのより高速なスケールアップや、Amazon SQS FIFO グループのより高いスループットなど、多くの発表がありました。しかし、拡張性の制限や目標値があり、他のサービスがそれに対応していない場合、抽象化レイヤーでは解決できません。リフトアップにかかる時間や、リトライのロジック、エラー処理なども、サービスごとに異なる傾向があります。
そして、各ベンダーが好むと同時に嫌う話題として、サービスの可用性があります。あるサービスを別のサービスにマッピングしても、そのリージョンで利用できない場合、できることはほとんどありません。ここでは、もう少し賢明になる必要があります。論理的なレイヤーは論理的なものを抽象化するのには適していますが、物理的なものは抽象化できません。私たちは細粒度の分散アプリケーションを構築しており、それらには多くの物理的な特性があります。
先ほど選択肢について触れましたが、ワークロードを移動する選択肢があれば素晴らしいと思いませんか？ その選択肢に価値があることは数学的に証明されています。だからこそ、私は誰にも心配しないでと言いません。選択肢は常に価値があります。必要な時が来たら、その選択肢を持っていることは正味の価値があります。しかし、世の中のほとんどのものと同様に、コストもかかります。先ほど見たように、自分で何かを構築する必要があり、それには労力がかかります。そして、私はいつも機会費用を支払っていることを思い出させます。
開発者に何かを構築させたり、マネージドサービスを使わずに自分でサービスを維持させたりする場合、その開発者の日給を支払っていると考えがちです。しかし、開発者のコストは日給ではなく、その時間に他に何ができたかということです。うまく機能しているビジネスであれば、それは実際のコストの何倍もの価値があるはずです。なぜなら、そうでなければビジネスは成り立ちません。何年も前、私がSilicon Valleyで働いていた時、エンジニア1時間あたりの機会費用、つまり価値は1000ドル以上でした。確かに良いビジネスでしたが、私たちは非常に生産性が高く、プラットフォームチームを持っていたので、この価値を生み出すことができました。
ですから、開発者がこれを1日半で行うと言っても、実際には2日かかるでしょう。それは2000ドルではなく、おそらく2万ドルの価値があります。ここでの計算には十分注意してください。機会費用を支払っているのです。もう一つ悩まされるのは複雑さです。お金については、簡単とは言えませんが、銀行があります。お金を借りたり、稼いだり、ローンを組んだりできます。つまり、最終的にはお金を手に入れることができます。しかし、複雑さはもっと厄介です。複雑さが高すぎると、それを低減するのは本当に難しいのです。
財務的視点からのスイッチングコスト：オプション理論と割引率
私たちITの人間は、一般的に物事を追加するビジネスに携わっています。常に新しいものを追加し、何かを取り除くのは本当に難しいのです。だから、そこは十分注意が必要です。最後のポイントはすでに言いましたね。基準を下げるということは、有用性が下がるということです。つまり、あのマトリックスの中で間違った方向に移動してしまうのです。スピーカーやIT関係者として、私たちは少し自慢大会をしています。その自慢大会の一部として、自分の法則を持つことがあります。Conway's lawのようなものですね。これが私たちの地位であり、自分自身を測る方法なのです。良いニュースは、自分で法則を作り出せることです。
私もその助言に従って、Gregor's lawを作りました。しかし、これは実は全くの作り話ではありません。多くの顧客と仕事をする中で得た結論なのです。もし決断を下したくない、地に足をつけたくない、あらゆるプラットフォーム、あらゆる言語、あらゆるデバイス、あらゆる柔軟性、あらゆる規模で、あらゆるコストでオプションを全て持ちたいと思うなら、複雑性の中で溺れてしまうでしょう。そして先ほど言ったように、これが最も抜け出すのが難しい落とし穴なのです。一度複雑性の落とし穴に陥ってしまうと、それを元に戻すのは非常に困難です。
これらのオプションと金融の話、そしてなぜ物事をお金に結びつけるのが良いのかについて少しコメントします。お金は誰もが理解でき、多くの理論が背景にあります。経済学でノーベル賞を受賞する人もいるほどです。
技術的な問題を金融の領域に置き換えることは、この軸上でより良いトレードオフを行うのに役立つ強力な手法です。
ここで私たちは何をしようとしているのでしょうか？私たちは負債を抱えています。そして先ほど言ったように、それはゼロではありません。切り替えが必要になる可能性は、ゼロではないのです。0.1%か0.01%かもしれませんが、人生において100%確実なことは何もありません。それにはコストがかかるので、明らかな負債を抱えることになります。この負債を減らそうとすることはできますが、多くの人が切り替えコストをゼロにしようとしているのを見かけます。それはあまり意味がありません。なぜなら、この負債に対して、それを減らすコストがあるからです。それが機会費用、人件費、そしてそれにかかる時間だと言いました。競合他社が素晴らしい製品を作っている間に、6ヶ月かけてこれを構築していたら、移行すべきものが何もなくなってしまいます。
これにはコストがかかります。答えは、これを最小限に抑えることではありません。答えは、現在の投資と抱える負債の合計を見ることです。これにより、より均衡のとれた議論ができるようになります。簡単に理解できる一般的なモデルが2つあります。1つはオプション理論です。金融オプションを取引する人々は、これを行使価格とオプション価格と呼びます。これらの人々は、移動が必要になったときなど、オプションを利用するときに支払う価格である行使価格を下げようとしていることをよく知っています。
行使価格をゼロにすることは有益な取り組みではありません。なぜなら、行使価格がゼロのオプションは実際には購入になってしまうからです。もはやオプションではなく、すでに全額を支払っているのです。何も得られません。確率は低いのに、100%と仮定しているのです - すでに支払済みです。これはスマートな投資とは言えません。これらの比喩を使って私たちの世界に置き換えると、非常に明確な洞察が得られます。金融の専門家に「行使価格がゼロのオプションが欲しい」と言えば、「それは意味がない」と言われるでしょう。私たちはそこから学ぶことができます。
ここでもう1つ学べるのは、これが保険に似ているということです。保険も私たちが負う負債の一種で、健康保険などがそうです。私がステージから落ちて怪我をした場合、いくらかのお金がかかるという負債を負っています。その負債を負っているので、それに対する保険があるのです。しかし、多くの方が自動車保険で経験されたように、免責額ゼロを要求し、「何も関わりたくない、全部払ってほしい」と言えば、「できますが、こちらが保険料です」と言われるでしょう。そうすると、「やっぱりいいです」と言うことになります。なぜなら、非常に高額になるからです。前払いのコストが跳ね上がってしまうのです。
これも同じことです。保険を買うようなものです。「心配しないで、ラッキーだから大丈夫」などと言って甘く見てはいけません。絶対にダメです。でも、過剰に保険をかけすぎるのもよくありません。中間的な価格や範囲を見てください。ここにはもう1つ重要な側面があります。少し深く掘り下げていますが、これは財務管理の講義ではないので、すぐに話を戻します。ただ、もう1つ重要な点があります。今日のドルは将来のドルよりも高価です。今では再びインフレと金利があるので、これはよくわかります。後で支払えば割引率があるので、そのためにさまざまな支払いオプションがあるのです。
将来のお金は今のお金よりも安いのです。これも意思決定モデルに影響します。この前払いの投資、黄色がかったオレンジの線は、今日のお金です。今すぐそれを使っているのに対し、紫がかった線は負債を表しています。それは1年後かもしれませんし、もっと可能性が高いのは2年、3年、4年、あるいは5年後かもしれません。つまり、そのスイッチングコストは、今日のドルで見れば実際にはより少ないのです。財務管理を行っている組織はこれをよく知っています。彼らは年間収益率、つまり将来のお金が今日のお金よりどれだけ安いかを示す一種の架空の金利を持っています。
その数字が最も高い組織は、最も速く動く組織です。彼らは今この瞬間に生きており、今100万ドルを使うことは彼らにとって本当に、本当に高額です。5年後に100万ドルを取り戻すことは、おそらくあまり価値がありません。 これが、そういった組織が大規模なクロスマルチクラウドプラットフォームのイニシアチブを持つことがほとんどない理由を説明しています。なぜなら、今すぐにそれを行うコストは彼らにとって非常に高くなるからです。それは事業全体のコストになる可能性があります。先ほど言ったように、これを構築するのに6ヶ月かかり、その間に競合他社が製品を発表したら、移行するものが何も残っていないことになります。財務とオプションについて深く掘り下げて申し訳ありませんが、これはアーキテクトとしての思考を鋭くするのに本当に役立ちます。
マネージドオープンソース：効用と切り替えコストのバランス
適切なバランスを見つける方法と、なぜ速く動く組織がこれをほとんど行わないかを理解することは、私の経験と一致します。ほとんどの場合、要求は大規模な組織から来ます。彼らはより動きが遅いので、割引率、つまり金利は arguably 低くなります。彼らにとっては、バランスが少し異なる可能性があります。
しかし、ここに落とし穴があります：彼らは皆、このクラウドのことやクラウドネイティブ、モダンアプリを行っているのは、他の組織のようになりたいからだと言います。速く動き、アジャイルでデジタルになりたいと。しかし、彼らは古い組織のような決定を下しています。それは賢明なことではありません。他の企業のようになりたいなら、他の企業のように考えてください。自社の内部割引率が高いと仮定し、今日のドルは非常に高価だと仮定し、機会費用が本当に高いと仮定してください。なぜなら、そういった組織はそのように機能しているからです。ですから、そういった組織のようになりたいなら、そういった組織のような決定を下してください。
これがうまくいったように見える一般的な反例があります。それはSQLです。ほとんどすべてのデータベースがSQLをサポートしていませんか？そして、大部分でそれはうまく機能しています。 しかし、ここにも微妙な点があります。歴史を少し読み解くと役立ちます。SQLは移植性のためのツールではなく、生産性のためのツールでした。 それは1つの企業によって、リレーショナルデータベースをより簡単に、より速く、より生産的に扱うための特別な目的で構築されました。そして、別のベンダーが「これは実際にかなり素晴らしいな」と言って、それを採用しました。
しかし、それがきっかけではありませんでした。それは開発者がこれらのまだ非常に新しいリレーショナルシステム、リレーショナル代数を扱いやすくするための生産性ツールでした。それには非常に強力な理論的基盤があります。これは単に誰かが言語を作り上げたわけではありません。その下にあるリレーショナル代数は非常に厳密です。それでもSQLは最も複雑な言語には見えません。彼らは単一の文書での公開さえ止めました。なぜなら、それが大きくなりすぎたからです。比較的シンプルなモデルに対してさえ、これを行うことは非常に複雑であることが判明しています。
皆さんご存知の通り、異なるデータベース製品のチューニングは異なります。SQLが抽象化するのは物理的な部分です。論理的な部分は、物理的なことをまだ行う必要があります。そう、SQLは素晴らしいですが、これはポータビリティを実現する例ではないことを覚えておいてください。実際には生産性を向上させる良い例でした。なぜなら、SQLなしで作業したいとは思わないでしょうから。 これが私の主張の核心です。生産性はポータビリティよりも優先されるべきだということです。もし生産性が低く、他の人が高い生産性を持っているなら、ポータビリティの問題は実際には問われることはありません。そしてそれは恐らく良いことではありません。なぜなら、それはあなたのビジネスが良好な状態ではないことを意味するからです。
これが、多くのオープンソースプロジェクトに対する私の小さな不満点です。 私はオープンソースの大ファンです。私のオープンソースプロジェクトはそれほど壮大ではありませんが、常に持っているものを共有しようとしています。しかし、オープンソースプロジェクトが自身をアピールする際に、常にポータビリティの議論を前面に出すことで、少し価値を低く見積もっているように感じます。もっと多くのことを言えるはずです。コミュニティがあり、オープンで、拡張可能で、レビューできます。より生産的になれます。オープンソースプロジェクトが提供する素晴らしいことはたくさんあるのに、この一つの側面だけに焦点を当てると、自分の価値を低く見積もっているように感じます。
だから私は人々にストレートに言います。なぜ「開発者はこれを使うとより生産的になれる」と言わないのか？そして、おそらくポータビリティも得られるかもしれない。これの方が実際にはより良いアピールになると思います。あるいは、協力できる、拡張できるといったことも。これらがオープンソースの本質的な要素であり、そしてポータビリティは付随的な利点になるかもしれません。それで全く問題ありません。さて、ここで5つのアプローチを紹介すると約束しました。悪いニュースは終わりました。ここからは良いニュースです。 実際に何が効果的なのでしょうか？まず明らかなのは、先ほど話したオープンソースです。私はオープンソースの大ファンではありませんが、実際にマネージドオープンソースは非常にうまく機能します。
これらは生産性を大幅に向上させ、素晴らしいサービスで、必要なスキルセットを見つけやすくなります。私たちがすべての運用を代行します。そして、他の場所で同じことをする必要がある場合も、物理的な詳細は別として、大まかには非常に似たものが得られます。私たちが実際にかなり広範なマネージドオープンソースのリストを持っているのは驚くべきことではありません。 これでさえ完全ではなく、スライドに収まりきりません。純粋なオープンソースもあれば、私はイベントストリーミングの分野にいますが、ストリーミングKafkaストリーミングサービス、MQ、RabbitMQ、ActiveMQがあり、データベースもあります。Cassandra互換のデータベースもあります。ほぼすべての分野から選べます。Kubernetesのサービスは言うまでもありません。
つまり、ほぼすべての分野でマネージドオープンソースサービスを提供しており、これらは素晴らしいものです。ぜひ使ってみてください。私たちは常に新しいサービスを作っています。 これは、ユーティリティを得つつ、切り替えコストを抑えるための素晴らしい方法です。
心理的ロックインの回避：設計意図の維持
この緑の象限で表されるシナリオは、実装すべき理想的な戦略です。 これは明白ですが重要なアプローチです。ここでの利点は、特定の機能に優れたサービスがあり、重労働を私たちが代わりに処理するので、あなたはそれを気にする必要がないということです。同時に、スイッチングコストのコントロールを維持できるので、可能な限りこのアプローチを取るのが良いでしょう。
ただし、すべてのサービスにオープンソースの代替品があるわけではありません。私はLambda、EventBridge、Step Functionsなどのサーバーレス技術を担当していますが、これらはオープンソースサービスではありません。そういった場合、どうすればいいのでしょうか？先ほど言及した次元を覚えていますか？私は第3の次元があることを示唆しました。それを見てみましょう。 以前は2次元の曲線を見ましたが、これを3次元に拡張して、スイッチングコストを大幅に削減できないでしょうか？答えはイエスです。その次元とは、velocity（速度）、つまりあなた自身の速度です。
これは考慮すべきもう一つの戦術です。多くの人は、スイッチングコストの問題をサービス選択とベンダー管理の問題としてのみ捉えています。しかし、それは方程式の半分に過ぎません。もう半分は、あなたの働き方に関するものであり、これは責任を一方から他方に移すこととは無関係です。問題を全体的に見ることが重要です。関係する当事者は2つあり、両者ともスイッチングコストを管理するためのレバーを持っています。あなたが持つ最も強力なレバーが、velocityなのです。
良い例が、古いバージョンのJava Development Kit (JDK)からの移行です。何年か前、あるJDKバージョンが脆弱性のためにサポート終了となった時、誰もがアップグレードを望みました。私が以前働いていた組織では、これが大規模な計画を伴う数百万ドル規模のプロジェクトとなり、非常に苦痛を伴うものでした。一方で、高度に自動化されたテストとCI/CDパイプラインを持つスタートアップを想像してみてください。彼らはおそらく週末で移行を完了し、大した問題もなかったでしょう。同じ製品を使用していても、スイッチングコストは桁違いに異なりました。その違いは彼らの働き方、つまりvelocityにあったのです。
では、どうすればvelocityを上げられるでしょうか？これは他の多くの講演でも取り上げられている、よく知られたトピックです。鍵となるのは、より高度な自動化によってフリクションを減らすことです。ビルド、テスト、デプロイメントを自動化します。1年半も存在し続ける長寿命のフィーチャーブランチは避けましょう。代わりに、変更を頻繁にメインブランチにプッシュし、保留中の作業の在庫を減らすのです。
もう一つのアドバイスは、価値を生み出さないものを作らないことです。難しいのは、何が価値を生み出すかを事前に知ることです。解決策は、小さな反復を行うことです。小さな部分を作り、その効果を確認し、それに応じて調整します。うまくいくものはより多く行い、うまくいかないものは減らします。これらは確立されたアプローチです。 摩擦を減らすことは、DevOpsの本質です。在庫を減らすことは、リーン生産方式とフロー最適化から来ています。最大の価値を生み出すものを作ることは、アジリティの核心原則です。何かが価値を提供しないと分かれば、それを止めて他のことに集中します。
ここで重要なメッセージは、解決策の範囲がサービス選択だけにとどまらないということです。自分たちの開発速度が、スイッチングコストに桁違いの影響を与える可能性があります。2週間で移行を完了した開発者の例を挙げましたが、彼らがそれを実現できたのは、非常にリーンな運用と洗練されたソフトウェア開発プラクティス、そして自動化を行っていたからです。彼らは高い開発速度を持っており、それによってスイッチングコストを大幅に削減できたのです。
さて、先ほど触れた心理的ロックインの概念について話しましょう。 設計意図を保持する必要があります。 EventBridgeを例に考えてみましょう。アーキテクチャ図にEventBridgeを入れるのは素晴らしいことです。私が携わり、大好きな素晴らしいサービスです。しかし、あなたが本当に達成しようとしていたのは何でしょうか？この図は、あなたが選んだソリューション、何かを行うために選択したサービスを表現していますが、あなたが実際に何を達成しようとしていたのかを逆エンジニアリングするのは難しいです。おそらく、意図を理解するためには全てのコードを見る必要があり、そのため設計意図が失われてしまいます。
これは非常によく定義された自己完結型のサービスですが、多くの異なることを行うことができます。 メッセージをフィルタリングしたり、内容に基づいて異なる場所にルーティングしたりできます。式とターゲット、フィルターとターゲットがあります。つまり、異なるメッセージを異なる場所に送ることができます。 メッセージを変換し、データ形式やフィールド名を変更することができ、複数の場所にメッセージを送信することもできます。
ここで私は20年前のパターン言語を使用していますが、これがまだ適用できることをいつも嬉しく思います。右側が意図を表現しています。それはあなたが達成しようとしていることです。左側が最終的な決定、つまりあなたが行うサービス選択です。これがスイッチングコストとどう関係するのか疑問に思うかもしれません。実は、かなり関係があります。なぜなら、アイコンだけで考えると - そして私はAWSで働いていますが、私たちはアイコンが大好きで、サービスも大好きで、全て素晴らしいものです - しかし、ここでのメッセージは次のとおりです： もしあなたがそれらのアイコンだけで考えるなら、心理的にロックインされ、私たちのように考えるようになります。そしてそれは、他のプラットフォームのように考えることを難しくします。
完全に透明ですね。つまり、サービスが得意とすることにはサービスを使うということです。サービスには多くの優れた点がありますが、自分の考えをサービスの選択で置き換えてはいけません。意図、決定、トレードオフ、達成しようとしていたことを維持してください。それらをサービスの選択で置き換えないでください。これは、人々が陥りがちな最大のアーキテクトの誤りの一つだと思います。アーキテクチャがサービスの選択であると信じてしまうのです。時には私たちも少し罪があるかもしれません。「アーキテクチャを見せてください」と言うと、サービスアイコンの図が出てきます。それは実装の一種ですが、このアプリケーションを設計し、アーキテクトする際には、もっと多くのことが頭の中で起こっていたはずです。
Scatter Gatherパターンに見るアーキテクチャ思考の重要性
だからそれを失わないでください。なぜなら、それを維持することでスイッチングコストも減らせるからです。サービスからこれを逆エンジニアリングする必要はありません。例えば、別のサービスではフィルタリングと受信者リストに異なるサービスがあるかもしれません。別のイベントルーターはフィルタリングと変換を行うかもしれませんが、受信者リストは行わないかもしれません。その知識を失ってしまうと、どこに行けばいいかさえわからなくなってしまいます。だから、その知識を失わないでください。この中間ステップ、つまりソリューションについて考え、意図を理解し、意図を表現することがいかに重要かを示すために、もう一つ例を挙げます。ここでも、20年前の古いものを使います。
シンプルなパターン、scatter gatherですね。複数の関係者が関与する何かをする必要があり、単一の結果が欲しい場合です。先ほど保険の例がありましたが、保険ブローカーのようなものです。車の保険が必要で、みんなに見積もりを出してもらい、最後にはすべての異なる回答の集計ビューが欲しいのです。これはEnterprise Integration Patternsの古典的なパターンです。アーキテクトとして、アーキテクチャは意味のある決定の連続だと確信しています。ランダムな絵ではなく、あなたが下す決定なのです。では、決定について話しましょう。
ここに決定があります。最初の設計上の決定は、受信者の数を知っているかどうかです。これは常に変化しますか？知っているのか、知らないのか？これは大きな違いを生みます。もし常に出入りがあるなら、異なるシステムを構築することになります。これをサービスにマッピングすると、Amazon EventBridgeは適切なアプローチではないかもしれません。おそらくAmazon Simple Notification Service (SNS)の領域になるでしょう。しかし、その要因は、受信者がより頻繁に出入りし、その数がわからないということでした。これは大きな違いを生むので、その決定を維持してください。
彼らは応答する必要がありますか？棄権できますか？なぜなら、数はわかっていても棄権できるなら、戻ってくるメッセージの数はまだわかりません。集約は、見た目以上に非常に興味深く、はるかに複雑なタスクです。完了したことをどうやって知るのでしょうか？すべてのメッセージを受け取ったでしょうか？それは、数がわかっていて棄権できない場合にのみ機能します。メッセージの数がわからない場合、タイムアウトしますか？特定の数のメッセージを待ちますか？3つあれば十分、というような感じで？段階的なタイムアウトか絶対的なタイムアウトを設けますか？メッセージを良いものとして評価しますか？好みの数字が得られたら、聞くのをやめますか？多くの異なる戦略がありますね。これがアーキテクチャ思考なのです。
結果を出力する段階になったら、どうすればいいでしょうか。保険の比較サイトのように全ての見積もりを集めるのでしょうか。それとも、最良の数字や合計、平均、最大値だけが欲しいのでしょうか。様々な選択肢があります。 この段階を飛ばさないでください。非常に重要な教訓が2つあるからです。これは、私たちがよく話題にする generative AI や artificial intelligence ではありません。これはあなたの人間としての知性です。つまり、あなたがアーキテктとしてこれらの決定を下すのです。
これらのどれも、アイコンの中には見つかりません。ビジネスユーザーとこの議論をすることができます。「Amazon EventBridge の JSON パスの設定をする必要があるんだけど、どれがいい？」と聞いても、ビジネスユーザーは混乱するでしょう。しかし、この議論なら、もっと幅広い聴衆と行うことができます。彼らはこれを理解できるでしょう。応答が必要かどうか、彼らは「はい」か「いいえ」で答えられます。このように、より洞察に満ちた議論ができ、この意図を維持できるのです。これが終わったら、サービスにマッピングします。そうすることで、頭の中で固定されることなく、意図を維持できます。そして、もし他の場所でこれを行う必要が出てきた場合、これを出発点として使えます。単なるカラフルなアイコンではなく。
ここで注意が必要です。 サービスの選択にすぐに飛びついてしまうと、アーキテクチャを単なるサービス選択の作業だと考えてしまうと、最も重要な部分を見逃してしまう可能性があります。この部分を認識し、尊重することで、スイッチングコストを削減することもできます。なぜなら、より良い出発点があり、頭の中で固定されていないからです。アーキテクチャ、設計、パターンの観点から、あなたがやっていることを表現できます。単にサービスの観点からではありません。なぜなら、他の側面では非常に異なるものになるからです。
まとめ：効率的なソフトウェア開発がスイッチングコストを最小化する
では、これらの話はどこに行き着いたのでしょうか。多次元の次元性、ロックインと結婚、オプション理論、ストライク価格、SQLなど、多くのことについて話しました。現実に戻りましょう。私たちはどこにいるのでしょうか。私たちが行った強力な操作は、 この話題から逃げなかったことです。「心配しないで」と言うのは簡単です。いいえ、心配すべきです。しかし、ロックインの恐怖という観点で心配すべきではありません。このような問題について考え、問題を再構築すべきなのです。誰も閉じ込められないということを理解することで、この問題を再構築します。これはコストの問題であり、お金の問題であり、負債の問題であり、何かが起こる可能性の問題なのです。そうすることで、私たちはこの問題についての考えを鋭くしたのです。
そして、これらの次元が本当に役立ちました。効用対コストの次元。スイッチングコストの異なる次元。これは非常に強力な操作でした。そして、このオプション理論は、ストライク価格をゼロにすることが目的ではなく、総コストを最小化し、今日の投資は将来の支払いよりも高価であることを理解するのに役立ちました。これが、恐怖を煽るような極端な考えや、逆に無知という極端な考えから、私たちを救い出し、分別のある会話へと導いた強力なアーキテクトの操作だったのです。
では、何を学んだでしょうか？明らかなアプローチはあまりうまくいかないということを学びました。 一方から他方へマッピングして、移動が必要な場合は同じようなものがあるというのが明らかな方法かもしれません。しかし、それがうまくいかないことを理解し、そのようなマッピングを公開しないのはそのためです。また、この抽象化レイヤーが一部のケースではうまく機能しますが、物理的な側面とコスト面を多く持つ分散システムにはあまり適していないことも分かりました。今朝、Vannaはコストが非機能的側面の一つであると多く語りました。これは抽象化レイヤーでは対応できません。
そして良いニュースが来ました。私たちが取り組むべきことについてです。最初はmanaged open sourceです。 これは非常に明白なものです。二つ目は開発速度です。この問題と解決策の空間のあらゆる側面を考慮し、開発速度を上げることで、スイッチングコストを劇的に削減できます。最後は、精神的なロックインに陥らないことです。設計意図を維持し、決定事項を明確にしてください。それが明確になれば、アイコンが現れます。
ここで「ちょっと待ってください。結局50分近くかけて、良いソフトウェア開発をすべきだと言っているだけではないですか？高い開発速度を持ち、パターンを使い、良いアーキテクチャを作るべきだと」と思うかもしれません。簡単に言えば、その通りです。開発の規律があり、設計意図とパターンを表現し、高い開発速度があり、自動化のレベルが高ければ、スイッチングコストは大きな問題にはなりません。つまり、オプション理論などの本質は、効率的で優れたソフトウェア開発を行うことです。そうすれば、いつか必要になったときに既に十分な準備ができています。managed open sourceをボーナスとして使用しますが、結局のところ、スイッチングコストは最大の問題にはなりません。市場での機会を捉え、適切な開発速度を持つことこそが、本当に注力すべき問題なのです。
ほとんどのベンダーが話したがらないトピックに取り組むことで、少しでも皆さんに刺激を与えられたことを願っています。タイトルに「lock-in」という言葉が入った唯一の講演ができることを、いつも少し誇りに思っています。しかし、これが非常にニュアンスの多いトピックであり、私たちのアーキテクチャの知識を使って実際に知的な議論ができることがわかったと思います。私は時々、自分の考えを整理するために本を書いていますし、ブログも持っています。このような考え方が好きな方は、 ぜひそちらもご覧いただければと思います。以上で終わります。ありがとうございました。
※ こちらの記事は Amazon Bedrock を様々なタスクで利用することで全て自動で作成しています。
※ どこかの機会で記事作成の試行錯誤についても記事化する予定ですが、直近技術的な部分でご興味がある場合はTwitterの方にDMください。
Discussion