Engineering Tomorrow’s Platforms: Staying Relevant in the Age of AI

皆さま方
こんにちは
ようこそお越しくださいました
大変日本に来られて光栄に存じます
そしてプラットフォームエンジニアリングコンフィレンスで
お話してくることを光栄に思います
エンジニアリングトマローズプラットフォームということで
AI時代に生き残る将来の
エンジニアリングプラットフォームということで
お話をさせていただきます
自己紹介です
私ニッキー・ワットと申します
トライフォークという企業のCTOを呼び
ビジネスユニットリーダーとなります
イギリスから参りました
トライフォークというのはグローバルの組織ということになります
そしてその振興の技術
例えばスペシャルコンピューティング
そしてアップルビジョンプロ
そしてグラウドネイティブの技術
そしてプラットフォームエンジニアといった部分を
カバーしております
そしてこちらの左側の部分を
トピックとして取り上げてございます
エンジニアとしての歴史もありますけれども
そしてまたリーダーの
シップスボールになっておりました
さまざまな組織をリードしてまいります
そのプラットフォームのエンジニアリングを
例えば銀行 金融
そして小売りた部分におきまして
採用しております
そしてこちら
今日のお話ですけれども
そうした提携に基づいて
お話をしてまいりたいと思います
ということで
エンジニアリング
その将来に向けてのプラットフォームということになります
そしてそこでまず浮かぶ質問というのは
明日
未来のプラットフォームというのは
実際どのような姿をしているかということです
ということでそれをお話をしてまいりますが
その前にまず理解することがあると思います
つまり今日のプラットフォームは
どういうものかということです
日本の反省という概念がありますけれども
我々といたしましても
それを変える必要があるわけです
我々はどのように過去
物事を構築してきた
山内を認めている
そして何かうまくいかなかったことはないか
そしてまたさらにそこから
どうやって前進を使用していこうということです
ですからうまくいったものに関しましては
そのまま一時として
そうでないものは捨てていくということです
そしてほとんどの組織におきまして
現状と
そしてまた目指す姿というのは
決して同じではありません
当然ながらギャップがあるわけです
差があるわけです
ということで
今日の講演といたしました
そのギャップをどう埋めるかとして
明日のプラットフォームへどう移行するか
という話をしていきたいと思います
そしてまたAIの役割はどういったことかということも
理解していく予想があります
ということで
いろいろな視点からお話をしたいと思います
プラットフォームエンジニアとして
何を知るべきなのか
そしてこれは
その中で関連性を保つために
何をする必要があるかということです
ということで
今日のプラットフォームから見てまいりましょう
現状において
私自身が
そのお客様からの話
そしてまた
ビジネスリーダーの方とお話をして
いわゆる状況としましては
その実装というのは非常に
玉石根拠とあります
ということで
3つの分類されています
生前としたもの
そして不整合のもの
そして混沌というふうに分けております
そしてやはり
改善されました
開発の向上というのがあります
そしてまた
機能提供の加速化
そしてまた
運用の一貫性といった
大きな
共通の特性とあります
しかし
コンサルティングのケアとしまして
いわゆる不整合
または
混沌の状態から
生前とした
状況へ動いていきたい
そしてAIを活用して
生きているわけです
つまり
不整合の
キャテゴリーといたしましては
どういったものがあるかというと
そうしたら
開発者のニーズに対する
理解不足がある
そして画一的なアプローチである
そして再力化されたチームということです
そして混在したチームの
特徴としては
例えば
過度にプラットフォームが複雑である
そしてまた
無駄なコストと労力がある
そして開発者の不満がある
というものがあります
ということで
その部分
どういうふうに
改善をしていくか
プラットフォームの構築を
改善することがいいのか
そしてAIの有無に関わらず
現状をどう把握することか
というところから
スタートしているわけです
そしてどうすれば
それを実現できるか
ということになります
方法はさまざまあります
一つご紹介したのは
プラットフォームエンジニアリング
成熟度モデルというものです
こちらは
2023年に
CNCFが発表しました
ということで
ちょっとお伺いしたいと思います
実際このプラットフォームエンジニアリング成熟モデルを
ご存知の方
どのくらいいらっしゃいますか
手を挙げていただけますか
実際それを使ったことがある方は
どのくらいいらっしゃいますか
それほどはやはりいらっしゃらないですね
ということで
こちらは非常に役立つユールというツールというふうに思います
まさに皆さま方がプラットフォームを改善するというのは
とても役立つものです
そしてケイト
こちらは日本語番号がございます
こちらケイトの方に
また後ほどお話をしていただければいいと思います
そしてリンクもありますので
ご興味がありましたらば
日本語版もございますので
ぜひこちらをご覧いただければと思います
詳細には入りませんけれども
基本的にこの作用の仕方というのは
こういうふうになっています
いわゆるパターン
そしてまた知識
知恵を集積していたということです
そしていわゆる便利な
マトリックスで示そうとしています
それぞれの特徴というのは何なのか
そしてまた実際に
それぞれのステージにおきましての
成熟度を示す実践というのがあります
そしてまた十分な情報というので
通じて自分の位置づけが分かります
そしてどこに制約が今あるのか
そしてまた改善の余地としては
皆さまどこにあるかということが
分かるような形になっています
いわゆる独断的なものではありません
つまり例えば必要なものがあれば
追加することもできます
しかし大まかに言えば
2つ視点があります
つまり縦軸
つまり例えば投資ですとか
採用の部分
そしてまたそれ上から下の
その成熟度レベル
水平レベルのようになります
ということでそれをまとめた図が
こちらとなります
もちろんこれも詳細は省きますけれども
一般的により戦術的
そして成熟度が低いのが
左側となります
そして戦略的で
成熟度が高いほど
右に行くというのが
一般的に生まれます
もちろん右の方に
成熟度を上げながら
行こうとするというのが
一般ということになります
こちらをすることによって
皆さま方の自身の位置というのが
分かります
ということでそれぞれの特徴を
見ていきます
ここが自分の立ち位置だというのを
理解しているわけです
もちろん例えば
全部1とか2とか
いうことはないと思います
その必要もございません
実践的な観点から言いますと
例えばこちらもちろん
やったことがないということで
ございましたら
こちら非常に最新
3週間前に出されたものです
ビーバンクサーという方が
新トッソーの方なんですけれども
この方が
プラットフォームエンジニアリング
成熟度アセスメントツール
評価ツールというのを
発表しました
こちらはまだまだ
初期段階と言えます
ということで
まだフィードバックを
募集中と言いますけれども
簡単な形で
それを見ることができます
そして皆さま方の
組織の疑問に
堅えるような
簡単な方法ということになります
そして
そのクエスチョンに基づいて
そのグラフを使っていきます
例えばこちら
どこの部分を改善するのか
そしてまた
皆さま方の現状というのを
理解するための形に
いきます
それが終わりますと
次の質問としたらば
次は何の
自分の目標は何なのかと
現状は分かったけれども
どこに進むべきなのか
例えば右側に行くべきなのか
それとも
真ん中でもいいのか
ということが
そしてまた
AIはどういうふうに
これらを変えていくのだとか
我々が
マトリックスを見ているもの
これを
AIによって
影響があるのだからろうか
ということがあると思います
ということで
特徴を見ていきて
そしてどこにあるか
ということを見ていきます
そしてもちろんこれは
各組織で違うわけです
例えば
組織の中で
スケールアップを
していきたいと
550のチームを
500チームにしたい
ということですから
スケールアップをする
ということになりますと
目的はもちろん
例えばコスト削減の
組織の目標とは
違ってくるでしょう
セキュリティの
組織とも違いです
ですから最終的な
到達点
到達点というのは
それぞれ違うわけです
ということで
そしてその中で
やはり共通の基盤というか
変わらない原則というのが
あります
つまり成功した
そして成熟したプラットフォームに
いくための共通の
特徴ということです
つまりプラットフォームを
製品として捉える
考え方というのが
それと言えます
つまりプラットフォームを
つまり社内の製品として
考える
つまり一時代のツールとして
インフラで管理する単なる
そうしたインフラ管理のための
ツールを狂うと
ユーザー中心のものである
そして信頼性を
デフォルトとするということです
全体のライフサイクルを
考慮するということです
運用の開始時点から
さらに100日目まで
ちゃんと安定課題をするような
形で信頼性を
デフォルトとするということです
またそれからチームを
セルサービスによって
エンパワーリングしていく
ということも言えます
つまりチームが
それによって
迅速に動けるようになるわけです
そしてまたチームの方も
プラットフォームチームに依存して
ただひたすら待つということが
必要なくなるわけです
ということで問題となるは
現状のAIのトレンド
今見ている状況というのが
そのモデルの中に
反映されているのか
ということで
それを使う上においては
理解をする必要があります
そしてAIというのは
まさに
プラットフォームの成熟度というのを
最低位につつあるというのがあります
これが日々の
開発者の体験
そしてまた運用とか
そして自動化というふうに
つながっていきます
現状のモデルとなってましては
AIのトレンドとなってましては
まず
いわゆる一般的な
ファーストクラス技術としては
扱われていませんけれども
その状況は変わってくるでしょう
しかしメイドウィーとしましては
カスタマイズすることができません
そして格子的なものでは
あるわけです
ということで
進めについて
それは変わっていく
そしてそれはまさにすべきで
そして我々が何を達成したいか
ということを達成していくべきでしょう
プラットフォームエンジニアにつきましては
こうしたモデルを
一つの先に進むための
モデルとして使っていくということが
できると思います
ということで
ここまでのまとめております
プラットフォームと
それからアプローチから
何を学ぶことが
今日はできるでしょうか
非常に多様な
インプレメンテーションの形
実装というのがあります
コントとしたものもありますけれども
しかし一般的に
改善を目指しているわけです
そして多くの人たちは
AIを活用していようとしています
プラットフォーム成熟度モデルというのは
非常に便利なフレームワークです
そして皆さま方の
プラットフォームの評価をしていく
そして先に進む
進むことを示唆してくれます
これはまだ
中心的な役割をまだ
占めておりますけれども
これを我々は先に進むにおいて
採用していくべきでしょう
ではプラットフォーム
将来のプラットフォームはどんなものか
考えていきたいと思います
まずAIは
この物事をどう変えていくんでしょうか
しかし最初に注意事件がありますが
キーノートといたしまして
これからお話しする話ですけれども
今一部
存在しているものもありますけれども
今後将来に出てくるであろう
という予測もあります
しかし
皆さんの目の前に
どういうものが出てきそうか
ご紹介をしていきたいと思います
そして皆さまが
将来に向かって構築をする
プラットフォームのアイデアになれば
と思っております
いくつかの違う分野があるわけですけれども
特定の分野を
深掘りするのではなく
全体像を皆さまに紹介する場だと
思ってください
まず3つの
コアの柱になる部分があります
まずプラットフォーム
アズプロダクトがありますね
そして信頼性
それからセルフサービスです
これは依然として
今後もコアになっていきます
AIはこの
成熟度をどんどん早めて
成熟度が上がるのを早めていくと思います
プラットフォームは
インテリジェントで
そして適合性があるということですね
そして信頼性も重要です
リアクティブからアダプティブに進んでいきます
そしてまた
よりスマートな
スマートなセルフサービス
AIを使って
これを提供していくことができるというものです
プラットフォームアズプロダクトは
よりインテリジェントで
アダプティブなものになっていきます
マインドセットとしては変わらないわけです
ユーザー
開発者をまず前面に出して
そして彼らが中心になっていく
変わるのは
どのように彼らのニーズを理解し
彼らの反応を理解するかということ
そして何か問題が起こった時
どうやってそれを把握するかということです
学習をしていくわけですね
今までフィードバックの書式ですとか
あるいはアンケートなどを通じて
情報を収集したわけです
製品を考えていく上で
非常に有効ですが
でもリアクティブな方法ですね
しかし将来は
ライブなデータ
ユーザーから上がってきたデータから
学んでいくことになります
開発者が何を言っているかではなくて
今やっているのは何なのか
ということを見て
そしてそこから学ぶということです
利用パターンを見て
そしてフリクションパターンが
どこにあるかということを見て
そしてリコメンデーションを上げていきます
パイプラインをセットアップするのに
時間がかかりすぎているなという時
これはAIが判断のために
必要になってきますね
でも何か時間がかかっていると
いうことであれば
それに後追いで反応するのではなくて
アダプティブなものを
作っていくことができるようになります
サポートリクエストを
今見ているわけですけれども
ネームスペースや
あるいは
EKSサービスに
オンボーディングするのに
時間がかかっている
というような話があります
これはシステムの中に
フリクションがあるということです
将来のプラットフォームは
ユーザーがこういった問題を
提示する前に改善をしていくということが
できるようになります
インフラストラクチャーの観測性だけでなく
ビヘイビアについても観測が可能になっていくということです
どこでためらっているか
どこで困っているか
これを見ていくということになります
そしてまたサポートの話もあります
チケットを出して
そして何日も返答を待つという代わりに
コーパイロットのインターフェースができて
リアルタイムで
サポートを提供してくれる
チームはこういった方向で
アダプティブになっていっています
本当にシフトが起こっているわけですね
プラットフォームに対する
フィーリングをつかんでいくことが
できるようになっています
そしてこの奮闘する対象であった
プラットフォームですけれども
今までジラをお使いになっている方多いと思います
そしてジラチケットを出して
それから何日も待たなければいけないということなんですけれども
今は
共に働いてくれるような存在になっていく
アダプションというのは
こういった中で重要な方向性になります
右側に移行していく
成熟度を高める上で必要なわけですね
そしてプラットフォームは
アダプティブにすることができるように
手伝ってくれる
AIからの情報があるということになります
左側では
気に入っていると
そして
新しいチームも
オンボードをすることができる
アダプティブになることによって
これをどんどん進めていくことができるわけです
そしてプラットフォームは
メンテナンスする対象というだけでなく
プロダクト自身が
ユーザーから学んでいくということになります
受動的に
そしてインテリジェントな形で
継続的に学んでいくということなんです
では信頼性ですね
2つ目のポイントになります
でも
これはいつも
基本であることは変わらないんですが
どのように信頼性を確保するかというのが
リアクティブからアダプティブに
変わっていきます
非常に強固な
優れたエンジニアリングプラクティスは
依然として必要ですね
ポリシー
ランブック
ゴールデンパスといったものは必要です
しかしAIの進化によって
リアクティブな執行から
適合型の信頼性確保に
つながっていきます
プラットフォームアズアプロダクトの
進化と同じように
我々の考え方を
変えていかなければいけません
システムの中で
どのように信頼性の問題を
学ぶかということです
そしてフリクションが
失敗につながっていく前に
これを知っていくということが
必要です
ウォーニングシグナルを
つかんでいくということが
必要ですね
プラダクションのシステムだけでは
ありません
ツールやプロセス
開発者が使っているものの
信頼性の問題でもあります
実際に
ディプロイメントに
何かスローダウンが
起こっている
新しいアプリケーションを
展開するのに
時間がかかっている
そして一貫して
遅くなっている
という時には
問題があるということを
示唆していますね
これを検討しなければいけない
ということになります
以上検出は
特定のプラットフォームに
出てきた
データドックの
APMや
GitHubのアクションインサイトの中で
こういったものが
把握できます
も統合していくということが
必要ですね
そしてまた
トラブルシューティングも
説明が可能なものになって
そして実行が
簡単になっていきます
ダッシュボードや
スタッグオーバーフローを見て
何が起こっているか
そこで見ていくことは
できるわけですけれども
しかし将来的には
自然言語で
なぜ機能の
デプロイメントは
失敗したのか
という質問を
投げていくことが
できるようになります
データドックも
こういった
ビルトインが
ありますけれども
データドックを
推奨しているわけでは
ありませんね
例として
ただ名前を
挙げているわけだけです
それからまた
ビットAIもあります
500のエラーが
過去2時間に
起こったものを
示して
というようなことを
言えるわけですね
そして
こういったものを
発見してくれます
こういったツールは
もうすでに
あるわけです
そして
我々のプラットフォームに
こういったものを
もっと広範囲に
適用する必要が
あるかどうか
ということを
考えていくわけです
そしてまた
ポリシーも
リアクティブから
プロアクティブに
移行しています
ユーザーは
AWS
アイアンパリシーの
セットアップが
必要だという場合が
あります
その場合に
いくつかのものを
見て
実際に
アイアンパリシーは
本当に必要な
アクセスよりも
80%以上も
多くのアクセスを
許している
というようなことが
発見できるわけですね
そういたしますと
実際に
開発者は
十分に
信頼性の高いものを
作っていない
ということが
考えられます
そして
コミットをする前に
このビヘイビアを
修正をしていく
ということが
可能になるわけです
信頼性は
執行するだけの
ものではありません
プラットフォームが
そこから学んで
そして適応し
そして皆さんが
簡単に保持できるように
していくということが
可能になるわけです
そして
インパワーメントに関しての
原則というのもあります
よりスマートな
セルフサービスの
オファリングが
AIと一緒に
出てきます
プラットフォームエンジニアリングでは
常にセルフサービスを
進めてきました
チームは
中央のIT部門が
仕事を完了するまで
待たなくてもいい
迅速に動くことが
このセルフサービスによって
できるわけです
YAMLフォームですとか
あるいはテンプレート
もっと成熟度の低いものでは
この特定のテンプレートを
使いなさいということも
できるわけです
そして成熟度が
増してきますと
ポータル
バックステージポータル
といったものを
使っていくことが
できます
この場合には
実際に自分の好きな
素敵なポータルを
選んでいくということになる
わけですけれども
例えば
AWSポータルに関して
どういうものが
必要か
まだ本当には
分かっていない
ということが
あり得るわけです
そしてセルフサービスは
メニュー形式から
対話形式に
進化をしていきます
そして
静的なフォームを
使っていくのではなく
コーパイロットを使って
コーパイロットが
サービスの枠組みを
提供してくれるようになる
そしてまた
インプットの検証を
行ってくれるようにも
なります
そしてオンボーディングも
もう一つ
変化していく分野になります
チーム
それからテクノロジースタックに
適応していきます
私が新しい社員だとします
そして
ガイドのついた
ステップバイステップの
示唆が欲しい
またシニアデベロッパーで
あれば
CLIのショートカットが
知りたいということになります
そして
プロンプトエンジニアリングは
この人は
システムに
まだ慣れていない
ジュニアの
開発者だな
ステップバイステップの
インストラクションを
与えた方がいいな
ドキュメンテーションも
必要だなということを
確認します
そしてシニアの
エンジニアであれば
オンボーディングの
やり方も
変わっていくわけです
そして
経験を積んでいけば
プロンプトエンジニアリングも
もう少し分かっていきますね
ディバッギングも
変わっていきます
セルフサービスで
リアクティブなものでは
なくなります
スラックで
メッセージを書く
というだけでなく
リアルタイムの
AIが助けてくれる
トラブルシューティングが
行えるようになります
ここでの変化ですけれども
ここにポータルがあります
頑張ってね
というのが
今までのアプローチ
それに対して
これが
あなたのアシスタントです
何を探しですか
どう手伝いしますか
と聞いてきます
根本的に
物事の
見つけたが
変わっていきます
サマリーです
コアの原則は
変わりません
しかし実現の仕方が
変わっていきます
プラットフォームアザ・プロダクトが
まず第一原則ですけれども
そこから学んで
そして
継続的に
アダプトしていきます
そしてプロアクティブで
コンテクストの中で
学んでいくことができます
そして
セルフサービスの
改善ですけれども
メニューだけではなく
コーパイロットが登場し
そして
リアルタイムで
ガイドを提供します
そしてAIを通じて
インタラクションを
開発者と起こせます
私がお話ししたこと
エンドユーザーに
フォーカスを当てた
ものが多かったですね
しかし
皆さんおっしゃるでしょう
今エンドユーザーの
問題ではなくて
AIが
私
プラットフォームエンジニアとしての
私の仕事を
簡単にしてほしいわけですよ
とおっしゃるでしょう
プラットフォームエンジニアリングの
スペースについて
お話をしていきたいと思います
この後のセクションでは
3つのAIが
インパクトを提供する分野
プラットフォームエンジニアリングの
異なる分野について
お話をしたいと思います
まずプラットフォームの
利用者を支援する
というのがありますし
そしてまた
我々プラットフォーム開発者を
支援するというのもあります
そして最後の3つ目
これは
確かに学ばなければいけないことですけれども
AIを
ファーストクラスシチズンとして
使って
そして
AIネイティブサービスを
民主化する
AIネイティブな
ツーリングを提供して
そして
コンポーズ
ビルドができるというものを
作っていくということですね
これに何が必要か
見ていきたいと思います
おさらいですけれども
プラットフォーム
利用者を支援する
これはガイディードAIと
私が呼んでいるものですけれども
我々のプラットフォームを
より迅速に
消費することができるようになる
そして
より安全に使うことも
できるようになります
ユーザーは
これをまだ
要求していないわけですけれども
自然言語の
インターフェースを
要求なさってはいないかも
しれませんけれども
今後は
必ず利用者は
チャットGPTのような
オファリングが
必要になっていくと思います
AIの期待値を
チャットGPTが
上げていますね
ドッカーは
コンテナーに関して
これをやりました
チャットGPTは
プラットフォームエンジニアリングの
インターフェースに対する
ユーザーの期待値を
上げていっています
プラットフォームエンジニア
ビルダーは
これを将来
入れていく必要があります
これに何が関連しているかというと
より
ナチュラル
ランゲージ
それから
ガイディッド
セルフサービス
オファリングス
メニュー
カンバーセーション
そしてよりスマートで
アシスティブなものになっていく
ということです
そしてコンスタントに
ユーザーの振る舞いを
学んでいくということになります
特に重要なのは
プラットフォームの
エンパワーリメントということです
そのプラットフォームそのものを
維持するということ
そしてより効果的に
維持していくということが
必要とおります
そしてこちらは
最低レベルということになります
そしてプラットフォームエンジニアリングと
関わらなければいけない
最低ググというふうに
言えると思います
アシストAIとも言うことです
これはどこで起こっていくか
一番明らかくなところでましては
AIのコーディングシステム
ということになります
多くの方々が
そのヘンフラストラクチャー
アザーコードの
作成というのをやっております
例えばテラフォールモデルから
EKSのクラスターの方で
作成していく
そしてボイラブレードの
スカップホールディングもそうです
そして
産有利用可能な
ハンドチャートを作っていく
そしてまたリファクタリング
コードやスクリプトの
リファクタリング
例えばシェルスクリプトの
クリーンアップなどがあります
こちらチャートGPTでも
可能となります
そしてこれがIDになっていく
でも実際に
大変なプラットフォームエンジニアというのは
そのターミナルでやっています
LLMパワーの
CSアライアンスですけれども
こちらが将来といたしました
プラットフォームエンジニアの
将来となっていくと思われます
それぞれの独自なツールと
例えばシェルGPT
これも
シェルコマンドに関しまして
役に立ちます
そしてまたクロードコードという
というのがあります
より多くの人たちが
使っていらっしゃるものと
おそらく傾向としましては
非常に良いもの
有効活用できるものだというふうに
私も思います
そしてやはり
ただ正しがきというのがあります
つまり
常に検証をしようということです
我々の脳みそを
止めてはいけないということです
今日最低限の効力で使っていくことができます
そしてまたオペレーターとしましては
プラットフォームエンジニアにとしましては
まずは最低限のレベルということになります
どういうふうに将来になっていくかということ
そしてうまくいくか
そこは分かりません
でもそうだとしても
少なくともどう動くかということ
そしてまた
どういった制限があるかということ
そして使う上においての制限というのを
知っておくことが必要となります
そしてまた
たくさんの時間を削減をされて
してくれると思っております
私自身もプラットフォームリーダーとして
そして多くの方々に
かけますけれども
やはり上手の方々というのは
なるべく少ない時間で
たくさんのことをやれということにおいて
これはとても便利だと思います
我々にエンジニアとして
特かあるものではありません
しかしながら我々が
そのよりよくできるようにしてくれるものであるということです
コーディングのアシスタント
こうやってよりまたさらに
便利な部分といたしましては
そのドキュメントそのものの側面
そしてそれを維持していくということです
ドキュメントが得意な方もいらっしゃいますし
得意でない方もいらっしゃいます
これをするに行きましては
例えばKubernetesのコントローラーを
作るときにはとても簡単です
そしてAIの方で
提案をさせてみると
リードミーで
そしてから
例のドキュメントの使い方を見せて
そしてそれを作成するというような形です
そしてエディターアシスタントもできますけれども
よりうまくいっている例として
私が見るのは
例えばプロセスを
GitBookなどに入れていくというのがあります
コードがコミットされました
そのエージェントで見せて
そしてそのドキュメントを
自分より作成していくということになります
これはHuman in the Loopですから
AIが何がどれを作成したか
そして人間がどこを作成したかというのが分かります
簡単にそしてやり方なんですけれども
ただまだたくさんの方はやっていらっしゃらないと思います
またそれからアーキテクチャル決定レコード
ADR
アーキテクチャルディシジョンレコードというのがあります
アーキテクチャル決定レコード
ADR
あまりご存知の方いらっしゃいますか
ありがとうございます
これはとても役に立ちます
特に皆さま方にぜひ
一般的な形で使っていただきたいというふうに思います
なぜ意思決定
プラットフォーム構築において
どうしてこの決定ができたのかということが分かります
例えば
フレックスから
オーガCDに移行するという時に
こちらは
AIが自動的に
作ることができません
例えば企業がどうなったかとか
それからコスターの問題とか
そうしたものがあるから
あり得るからです
そしてレコードをそこで把握をするということが
とても重要になります
通常は事前によりますけれども
AIの方で
その事後に作ってもらうということも可能です
ここで重要なのは
例えばファンデーション
つまり基盤を与えてくれるということです
そのAIが
後で実際に
その事後で
決め込むことができる
基盤を
教えてくるということです
フラックスから
アーゴCDに移った理由は
何なのかといったことを
後で考えるを見ても
役に立つということになります
これはトレーニングソース
エンジェンというのを
トレーニングソースとしましても便利です
そしてテキストにおきまして
その意思決定を
より使っていくことができれば
コンシューマーフェイスのAIというのが
より頭が賢くなるということになります
そして次にトラブルシューティングの
コパイロットのトラブルシューティング
AIロックスと呼ぶところに
入っていきましょう
これによって
インシデントのリゾリューション
解決時間というのを
削減してくります
それぞれのシステムにおいて
必ずしも熟知しないと
いくときに
AIでログを解析してもらいます
例えばクラウドウォッチを
見てきて
そしてルート構図を
見ていく
例えば
レートとましては
例えば
メモリー不足が
起こってしまった
そしてまた
これが
原因が
設定ミスのせいだとか
分からないかと
それからアラート
使えるというのがあります
やはり
人間としてましては
さまざまなログを
見ていくというのは
なかなか大変です
しかし
AIにやらせることによって
こちらを
きちんとまとめてくれる
というのがあります
そうしましたら
人前言語においての
トラブルシューティングの
可能性というのが
広がります
こちらの
デブのクラスターは
どうしてスタックしたのだかと
そして
どこにあるんだろうかと
いったような疑問
こうした
データドック
ビットAIが
そうしたことを
提供してくれるようになっています
もう一つ便利な
そのポストモータムの部分というのも
便利です
何かうまくいかなかった
ということにしましたら
さまざまなドキュメント
というのが
スラックとか
ジラのスレッドに出てきます
そしてまた
行動として
何が起こったというのを
見るということです
そしてそれを
まとめて
そして
AIに見せることによって
さまざまな
メトリックス
データ同負荷とか
プレミッシュ
プレミティスとか
スラック
エジラ
そうしたところの
情報というのを
まとめてくれます
少なくとも
ドラフトとしまして
何が起こったかということを
示唆してくれる
ということに言います
これで
皆さま方の
ポストモータムによって
その作業を
かなり削減していきます
ということで
いくつか
具体的な
特化ツールということで
お話をしていきたいと思います
少なくとも
Kubernetesベースでは
お話をしていきたいと思います
KubeコントロールAIですけれども
Googleのほうが
2ヶ月ほどしか
立っていないものですけれども
非常に特化しています
Kubernetesが
特化していたものになります
インテリジェントインターフェースとしての
目的を
第一しています
自然の言語から
特定の
Kubernetesの
オペレーションのほうに
トランスレーションを
するということになります
それによって
Kubernetesのアクセスというのを
効率化することができます
あと
KHSGPTというツールもあります
これは
Kubernetesを
特化した形で
デバッグができるようになっている
ツールになります
そしてまた
特に
これらを
AIのツールというのを
決め合わせることによって
より力が出てきます
よくあることを
もったいといった人は
Kubernetesだけの問題はない
さまざまな
AWSとか
Kubernetesとか
組み合わさって
そしてその他の設定が
どこかで
組み合わさって
というような原因があるわけです
クロードコードのようなものを
使うことによって
皆さま方も
実際にそれぞれのパートと
フッキングをすることに
そして
それぞれの
NCPサービスとか
そうしたさまざまなシステムに
フックをしていて
そしてから
ケージェントという
新しいフレームワークというのがあります
これはオープンソースの
プログラミングフレームワークです
例えば
エージェント AIに
パワーを使って
クラウドネイティブの
エンバローの環境に対しまして
使うことができます
そして
何か
例えば
トラフィックのインシデントが
起こった時に使い
そしたら
なんで
低速になってしまったか
そうしたような時に
使ったりします
いつか例を申し上げました
消費するということでは
ございませんけれども
例として申し上げました
ということで
次
最後
我々としまして
見ていかなければいけないのは
AIネイティブの
オファリングに対しましての
民主化でする
AIをネイブラーとして
見ていくということになります
こちらに行きましては
成功できる
将来におきましての
成功できるプラットフォームとして
我々自身は見ています
エンドユーザー
そしてプラットフォームビルダー
そしてエンドコンシューマー
もこういった形の
エンドユーザーに対しまして
AIのネイティブな機能
というのを
与えてくる
そしてまた
ソリューションに対しまして
独自のソリューションを
構築することが
できるということです
データとプラットフォームが
いわゆるプラットフォームに
つきましての
サブの専門文化になっています
そしてマイクロサービスで
何を構築するか
そしてデータプラットフォーム
というのも
また発生するわけ
そうにおきまして
そこでちょっと専門性が
必要となる
AIのネイティブなプラットフォームというのが
やはり一つの専門分野になっていく
というふうに思っています
そしてより大きな
一般的なものに
含まれていくかもしれませんから
それにしても非常に重要な
分野だと思っております
これによって
プラットフォームビルドが
モジュラー型でなる
必要が出てきます
ここで機能として
可能となるのは
より安全な
セキュリティのアクセスを
認証されて
AIのツーリングに
確保することができます
これはセキュリティ
ガバナンス
ポリシーの部分に
かかっています
さまざまなオプションと
ありますけれども
しかし全てのオプションが
同じとはありません
いわゆるシャドウIDというのは
Dというのは
避けなければいけません
クラウドで何か起こったか
クラウドが
現れた機能や
例えばさまざまな
クレジットカード
さまざまなコードを
そしてAWSとか
Azureとか
そういったところで
使っていったわけです
しかし同じようなことが
まさにAIで
起こっているわけです
ツールをいろいろなところで
使っているというのがあります
ですから業務
ビジネスの視点から考えるに
我々としましては
こうしたオプションというのは
ユーザーをより安全な形で
使ってもらいたい
ですからこれを
もちろん規模の経済も
必要です
そしてこちらの部分を
活用していくというのが
必要でしょう
そしてまた
プロットフォームの
成熟度のモデルというところとも
関わってきます
投資の部分です
つまり投資の分野という意味です
その人
そしてお金と
どこのプラットフォームエンジニアの
ところに成功のために
投資をするか
そして実験的に
そしてAIツーリングというのも
その実験の中に含めるということも
重要となります
ということでまとめております
3つのメインフロントとしまして
我々としまして
注目分というのを申し上げました
AIが大きな影響を与えるものです
まずはプラットフォームエンジニアに
対しましての
エンパワーメントということです
もちろん
まずはオペレーションといって
最低レベルとします
そしてまた
AIツールとか技術というのを使って
よりシステムを改善していく
そしてまたスピードや品質も
改善していく
そしてプラットフォームの
コンシューマーを支援していく
基本的には
より自然言語でしたか
会話のインターフェースを
使うというのがまずあります
そしてまた
AIニティビューの
ソリューションというのを
民主化していく
AIを
ファーストクラスシステムとする
そして
独自のAIシステムというのを
その上に作っていくということです
ということで
その皆さま方も
さまざまなお話をさせていただきました
非常に現状は複雑です
確かにさまざまな課題というのがあります
ということで
こうした中の
よくある2つについて
取り上げていきたいと思います
実際にクライアントさんからの
お話となります
まずは最初の方です
これはLLMに関連したらと思います
実際にAIの幻覚ハルシネーションというのは
まさに本当のことで
決定論的ではありません
ということは
どういうふうに予測できない状況で
制御を維持するかということになります
ということで
まずはやるべきでないことを見ていきます
まず我々としてやりたくないこととしましたが
その盲目に信じてしまうということ
そして検証しない
AIを使ってしまうということです
どういうこと
例えばいわゆるその辺りにあるLLM
そのオープンAIチャットGPとか
そうした
例えばアウトオブターボックスの
エジェントフレームワークなども
含めていきます
こうしたものを
まずは
盲目的に信じてしまって
とにかく最善の結果を求めたとしても
結局は
涙の結果となりということになります
では何をするか
より賢い形で
ガードされた
守られたAIを
捕まえていくわけです
つまりAIの中にラッパー
そしてセッティングをかけることによって
決定論的にしていくということです
そしてまた
AIというのが
その全てのことを解決するというふうに
期待をすることはいけないということです
いわゆる
その全てのプログラムを
全て解決してくれるものではないということです
ではその他の技術としまして
そうしたガーデンでは
守られたAIというための
何があるでしょうか
まず要素としましては
強固なプロンプティングがあります
まずは投資が必要です
プロンプトエンジニアに対しまして
プラットフォームのエンジニアとして
そのAIをちゃんと
正しい結果に
導くような形での理解というのが
必要とおります
我々としましては
バイブコーディングから
よりスペックドリブンの
AIの開発
AIコーディングに
移っていくでしょう
ご聞きのこととは思いますけれども
スペックドリブンの
コーディングというのは
AIに対しましては
非常にクリアな
具体的な
何をするべきかという
インプロットを与えます
入力出力
そしてまた制限も
与えます
そしてまって
そのコントラクトに
従った形で
コードを
生成をさせています
例えばアントソーシング
そうしまして
陽光
サードパーティーとか
若いデベロッパーの
方になりますと
具体的なスクリプト
というふうに書いていきますけれども
これがいわゆる
スペックドリブンになるわけです
ですから
より
曖昧になってはいけない
ということです
そしてまた
これはまた
さまざまなモデルが
やっております
ということで
プロンプトエンジニアルに
関しましての
手押しをすることで
利用するということが
必要と言います
またその他の技術
というのもあります
リトリーバル
オーグメンテッド
ジェネレーション
ラグになります
これは皆さま方が
例えば
ハルシネーション
減額が
モデルに発生しているときに
助けてくれます
プラットフォーエンジニアルと
とましては
まず
そのデータエンジニアリングの
部分というのを
理解も必要です
どういうふうに
採用していくのか
そして
それに対して
ちゃんと
適切なデータを
見ていく必要があります
コンテクストウィンドウにおきまして
そこで
判断ができるように
ということです
コンテクストウィンドウというのは
実は
とても大きな問題があります
つまり
AIのスペースにおいては
大きな問題となります
ここにてはちょっと
触れませんけれども
こちらも
おかえをするという
一つの方法となります
そして
我々の中の
ツールボックスの中に
備えるべきでしょう
最後の
ガードレール
そして
ヒューマンインザルーブ
というのがあります
ですから
チェックをして
きちんとバランスを
とるということです
ここで一つ例を
クーブカトルAI
コントロールAIを
お話をしたい
例をしたいと思います
いわゆる
自然言語で
何をしてほしいか
というのを
言いますと
そこで
それをやってくるわけです
そして
その行く前に
実際実行する場合に
確認をしてくる
ということです
例えば
キャパシティの
エンジンXを
半分にしてくれないか
というふうに
言いますと
そうすると
何ができるか
ということを
伺いして
そして
そのコマンドを
こちらのコマンドを
走らせますけど
いいですか
というふうに
聞いてくるわけです
ですから
これはチェックと
そしてバランス
チェックのバランスが
きちんと取れた上で
先に進むことが
例というふうに
言えると思います
そしてもう一つ
非常にこれは
新しい例となります
スペックキットからの
例となります
こちらはまさに
今月末に出てきた
ものになります
AIコーディング
より決定論的な
形で可能としています
バイブコーディングの
代わりに
関して
スペックを
与えていきます
そして計画を
決めていきます
どういうふうに
するか
そしてまた
それをタスクに
分割して
そしてその
コードというのを
スタート
作成していくわけです
ですから
自動化に
とても便利です
例えば新しいサービスを
オンボーディングを
していくというような
形に
時にとても
便利ということになります
しかし
他のアプローチを
使うことを
恐れてはいけません
ルールベースの
従来の方法というのも
まだ使えるわけですね
これを捨てることは
ありません
これも入っていきます
そしてまた
アクセスに関して
考えていく
エージェントであるか
AIエージェントであるか
あるいは
システムユーザー
かもしれません
ロールを
明確に
定義しておく
ということが
必要です
エージェント
あるいは
システムであっても
アドミンアクセスを
提供してはいけない
ですとか
デバギングの
権限のみを
与えておく
ということですね
以前の会議で
AIエージェントは
AIエージェントは
アングリーインターンの
略ですよと
いった人がいました
AIは
怒っている
インターンだと
意向としては
善意を
持っているんですけれども
リードオンリーアクセス
のみを
提供するというのが
いいアイディアか
と思います
非決定性は
クリエイティビティの
いい根源では
あるかと思いますけれども
しかし
プラットフォームに
安全性が必要です
プラットフォーム
エンジニアとして
闇雲にモデルを
コールしてはいけませんね
AIの安全性を
しっかり
ラップしておく
ということが
必要です
AIは
非常に
迅速に
進化しています
そして
予想がつかない
将来に
どう準備をするか
ということを
考えなければいけません
適合性ということを
考えたいと思います
我々が
将来について
分かっていること
AIが
必ず入ってくる
エージェント
AIが
非常に
大きな部分を
占めるということは
分かっていますね
フォーマットは
違ってくるかもしれません
しかし
エージェント
AI
レディーな
プラットフォームを
構築する必要があります
AIエージェント
プラットフォームというのは
個々の
ワークフローを
コンポーズをして
トリガーして
そして
実施をしていくわけです
AIドリブンな
インターフェースが
必要で
そして
それぞれの部分というのは
小さな
リユーザブルな
ポーションに
分けていく必要があります
まずは
モジュラリティを
考えていく必要があります
コンポジュラリティを
コンポジュラリティを
コンポジュラリティを
コンポジュラリティを
コンポジュラリティを
コンポジュラリティを
コンポジュラリティを
コンポジュラリティを
コンポジュラリティを
コンポジュラリティを
コンポジュラリティを
コンポジュラリティを
コンポジュラリティを
コンポジュラリティを
コンポジュラリティを
コンポジュラリティを
コンポジュラリティを
コンポジュラリティを
コンポジュラリティを
コンポジュラリティを
コンポジュラリティを
コンポジュラリティを
エンドユーザーが
一箇所でボタンを押せば
結果が出てくる
というものではなくて
小さなバッジに分けて
全体としては
答えが出てくる
というものですね
そして将来は
その上にAIが
載っているという形になります
ドキュメンテーションに
投資をするということを
申しました
将来のAIは
テクストが必要なわけです
そしてテクストを
今作っておくことが
必要ですね
たくさん作っておけば
作っておくほど
エージェントベースの
将来に備えるということになります
それからまた
過観測性
ログイングについても
投資をしておく
見えないもの
測定できないもの
というのは
対応していくことが
できないわけです
適用できないということになります
AIがどこに展開していようとも
その関連性の高いものを
作っていくことができます
そしてまた
AIは非常に迅速に
進化をしているので
今のものというのは
古くなっていきます
3つか4つのツールが
過去2ヶ月の間に
出てきましたけれども
しかし
その結果というのを
予測することはできません
将来のために
構築をしていくということは
その一部に
実験が含まれるということになります
どのようにプラットフォーム
将来のプラットフォームを
構築するか
その中に
実験を組み入れる
余裕を作っておく必要があります
エージェントを
使ってみなければいけないわけです
まとめの前に
実際の
私の経験ですね
リアルワールドでの例を
ご紹介したいと思います
2015年のことです
ラグビーワールドカップ
もうほとんど
10年前ですね
明日が
その日付だったと思うんですけれども
皆さんラグビーご存知なくても
心配しないでください
初戦で
南アフリカと
日本チームは
戦ったんですね
そして
そこで非常に
重大な決定をしたんです
ペナルティキックで
3点取って
引き分けに持ち込むか
あるいは
トライを獲得して
そして勝つか
ということで
ペナルティキックではない方を選んだんです
実際にこの試合は
私は見に行っていたんです
そして
もともとは
南アフリカ生まれですので
本当にこのような結果は
予想していなかったんです
またこういうような素晴らしい業績を上げるかどうかは分かりませんけれども
しかしプラットフォームチームは
こういった実験的なトライをしてみる必要があるということなんです
未知の体験を追求することも必要だというお話でした
プラットフォームエンジニアリング成熟度モデルというのは
まだ進化の過程にあります
これを理解して適応させていく必要があります
しかしAI的な思考というのも
含めていく必要があります
そしてファンデーションは依然として必要です
信頼性ですとか
それからAIが物事を変えていくということも
考えなければいけません
よりインテリジェントなプラットフォームで
自身で学んでいくことができるような
プラットフォームを作っていくということで
AIは今後大きなインパクトを持ってきます
プラットフォーム開発者に対しても
それからまたユーザーをサポートするにも
AIが必要になります
そしてこれはただでは達成することができません
いろいろな課題があります
AIを学んで
そして適応性のために
プラットフォームを構築をして
そして実験も受け入れる余地を
作っておく必要があります
プラットフォームはエージェント
コーパイロット
それからまだ発明されていないような
将来発見されるシステムも
ユーザーになっていくということです
プラットフォームユーザーというのは
従来のユーザーがまだ中心になっていくわけですね
そして我々の仕事としては
今までとは考え方を変えて
適応のために設計をし
そして実験できる余地を
作っていくということです
この谷間を眺めて
すごい谷だねというだけでなく
そこに橋を架けていくというのが
我々のミッションです
ご清聴いただきありがとうございました
ニッキーさん素晴らしいご講演ありがとうございました
それではこれよりQ&Aセッションに移ります
早速たくさんのご質問をいただいております
それではまず一番上の質問からまいります
プラットフォームの機能を
社内で標準化して提供するには
数ヶ月の時間がかかりますが
AIの進化が早すぎて
その間に新技術が出てきてしまいます
プラットフォームチームは
どのように新しい技術を取り入れ
機能として提供すべきでしょうか
いかがでしょうか
はい
AIの進化が早いということ
そしてまた
社内において
どのツールを選ぶか
そしてまた
それがどう機能していくか
ということですけれども
やはり選択が重要だと思います
何かその選択をして
そしてそれを使っていく
もちろんたくさんのツールがあります
いくつかすでに
この2ヶ月で出てきた
さまざまなツールというのがあるんですけれども
まずは1つ選んで
そして実験をしていく
そしてそれを深掘りすることによって
学ぶことだということだと思います
あちこちつつくのではなくて
例えば人によっては
例えば6ヶ月待って
上で
そしてどうなるかというふうに
状況を見る方もいらっしゃいますけれども
私は一般的には
まずは選ぶべきだと
そしてそれをちょっと
しばらく使ってみる
そしてその6ヶ月くらいとか
単位をくらい使ってみて
そして評価をしていくというのが
いいんじゃないかと思います
もちろんこれに対しまして
完璧な答えではないわけです
いずれにしましても
実験が必要
何かトライする
いろいろなことをトライするということが
必要と言います
さまざまな1つ2つ技術を
深掘りすることによって
学習することができるわけです
ですからいろいろな
例えば100とか200とか
ツールをいろいろ
飛び回ってしまっては
結局何も学べないと思います
重要なことは何が原則として使われているか
ということを学ぶ
いわゆるスペックドリブンの開発という
方法になりました
まずはそうしたものであれば
そのツールを使って
そしてそのしばらくを使っていくことです
どういうふうにまずは
作用していくかということを理解して
そしてまたまずはその原則を理解をすれば
その後健康するということは可能だと思いますので
それでは続いての質問に参ります
プラットフォーム利用者に対する
インパクトのスライドで書かれていた
明に暗に学習し続けるということが
何を意味するのか
もう少し詳しくお伺いしたいです
ユーザーの振る舞いから学ぶというところですね
もう少し詳細に話してほしいということですが
その意味ですが
アンケートなどを使うだけでなく
どういった機能が欲しいですかといったような
アンケートではなく
チャットスタイルのインターフェースを
使っていけば
質問や
あるいは入ってきたテキストを
分析していきますね
それで分かったと
ユーザーは
一貫して特定のフィーチャーを聞いているなとか
ここで苦労しているなということが
分かってくるわけです
例えば
オンボーディングをどうやったらいいか
というような話
チャットインターフェースで
質問が投げられることによって
どこで苦労をしているか
どこで新しい情報が必要か
ということが分かってきます
そういう会話を通じて
明に暗にユーザーの意向を学んでいくということです
特定のフィーチャーを要求するということではなく
多くの人が同じような質問をしているということは
そこが苦労するポイントだということが分かりますね
そういうアプローチで
今までとは違う方法で
ユーザーについて学んで
そして必要なものを見出していく
それからまた
メトリックスも出てきますね
アプリケーションを展開するとき
どこで何が遅くなっているか
どこでフリクションが生じているか
ここに問題があると
問題が出てくる前に
事前にここに対処しておこうというような形で
プロアクティブに対処することができるわけです
それでは残り時間も少なくなってまいりましたので
あと1,2問ほどお受けできればと思います
続いての質問が
プラットフォームエンジニアリングにおいて
様々なトピックで生成AIが活用できることが分かりました
例えば少人数のプラットフォームチームを立ち上げて
これからAIについても取り組むとする場合に
まずはどのトピックについて取り組むのが
良いでしょうか
組織の課題にもよるとは思いますが
優先度の考え方があれば
伺いたいです
そうですね
優先順位をつけるということ
例えばプラットフォームエンジニアリングチームとしまして
何を見るべきかということの優先順位をつけるときにおきまして
私のお勧めとしては例えばクロードコードとか
そうしたエージェントAIのようなモデルを使うことによって
皆さま方がそれぞれのツーリングというのをどう取り組むか
そしてプラットフォームエンジニアリングについても学ぶことができるというふうに思います
私としてましてはぜひお勧めしたいと思います
例えばプロンプトコンジニアにおきましては
例えばクロードコードを見ることによって
例えばスカッフォルディングをスタートすることができます
枠組み付けのようなスカッフォルディングをスタートすることができます
これをチームとしまして使うようにできると思います
ですからまだやったことがないということでは
まずはバイブコーディングからまずはスタートしていって
そしてAIがどういうふうにできるか
何ができるかできないかということで見ていく
そしてさらにより構造化された小さなものを見ていくのであれば
例えばエージェンティックAIのフレームワークを見ていく
クロードコードはいい例だと思いますけれども
ちょっと効果ですのでそれはちょっとまた別の話になりますけれども
いずれにしましては問題としては
ポイントとしてはこうしたクバニティスとか
AWSとかそうしたものを取り込む
そしてまたテラフォームとか
そうした他の特定のスタートもありますけれども
それによってユーザーに対しましての
開発経験というのを上げていくというのが
お勧めかというふうに思います
ありがとうございます
それでは次の質問を最後の質問とさせていただきます
民主化は良い方向性だと思いますが
専門知識を持たない人がエンジニアリングを始めることによるインシデント
特にセキュリティーインシデントについて懸念を抱いています
ここはプラットフォームでカバーできるのでしょうか
これはガーディーでAIを検討すべき分野だと思います
我々としては民主化もAIのオファリングによって進めたいわけですね
でもその一部にプラットフォームエンジニアリングは
ユーザーが安心して使っていくことができるような
セキュリティ性の高いものを作っていく必要があります
ガードレールを入れておく
AIコンポーネント
利用可能にはなるんですけれども
そこにガードレールが入っているということですね
新しい分野です
したがって正解が分かっているわけではありません
今人々は失敗を犯し
あるいは失敗したら成功を目指すということで
まだ完全に作業が済んでいる分野ではありません
ガードレールを検討すべき分野だということは言えます
そしてかなり問題になる部分ですね
CTOですとかエグゼキティブの方が
情報漏洩がないように
パブリックドーメインに
情報が流れていかないようにしていく
正しいモデルを選んで
どのような情報をそこに入れるか
ということも検討する必要があります
ガードレールをしっかり組み立てて
そして問題の一部はそれによって解決できると思います
それからまた
プラットフォームエンジニアとして
様々な対応方法を入れておかなければいけない分野だと思います
それでは
以上でキーノートセッションを終了いたします
皆さまニッキーさんに
もう一度盛大な拍手をお願いいたします
ありがとうございました
ありがとうございました