今から 20 年前の 2006 年 3 月 14 日、 Amazon Simple Storage Service (Amazon S3) は、 「新着」 ページに掲載されたわずか 1 段落のシンプルな発表とともにひっそりとリリースされました: Amazon S3 はインターネットのためのストレージです。デベロッパーがウェブスケールコンピューティングをより簡単に利用できるように設計されています。Amazon S3 は、ウェブ上のどこからでも、いつでも、どのような量のデータでも保存および取得するために使用できるシンプルなウェブサービスインターフェイスを提供します。Amazon が自社のウェブサイトのグローバルなネットワークを運営するために使用している、スケーラビリティ、信頼性、高速性に優れた低コストのデータストレージインフラストラクチャを、すべてのデベロッパーが利用できるようにします。 Jeff Barr 氏のブログ記事 もわずか数段落で、カリフォルニアで開催されるデベロッパー向けイベントに向かう飛行機に乗る前に書かれたものでした。コード例はありませんでした。デモもありませんでした。大々的な宣伝もありませんでした。当時、このリリースが私たちの業界全体を形づくることになろうとは、誰も想像していませんでした。 初期段階: ただ機能するビルディングブロック S3 の中核には、オブジェクトを保存する PUT と、後でそれを取得する GET という、2 つのシンプルなプリミティブがあります。しかし、真のイノベーションは、その背後にある哲学にありました。すなわち、差別化につながらない手間のかかる作業を処理するビルディングブロックを作成することで、デベロッパーがより高度な作業に注力できるようにするということです。 S3 は、サービス開始当初から、今日でも変わっていない 5 つの基本原則をガイドとしてきました。 セキュリティ は、お客様のデータがデフォルトで保護されていることを意味します。 耐久性 は、イレブンナイン (99.999999999%) の可用性を実現するように設計されており、当社はロスレスになるように S3 を運営しています。 可用性 は、障害は常に存在しており、対処される必要があるという前提に基づき、あらゆるレイヤーに組み込まれるように設計されています。 パフォーマンス は、事実上あらゆる量のデータを劣化なく保存するために最適化されています。 伸縮性 とは、データの追加や削除に応じてシステムが自動的に拡張および縮小し、手動での介入が不要であることを意味します。 これらの原則が適切に機能することで、サービスは非常にわかりやすいものとなり、ほとんどのお客様はこれらの概念の複雑さについて考える必要はありません。 今日の S3: 想像を超えた成長 S3 は 20 年間にわたって、想像を絶する規模に成長を遂げながらも、その核となる基本理念を堅持してきました。 S3 が最初にリリースされたとき、3 つのデータセンターにまたがる 15 のラック内の約 400 のストレージノードで、合計約 1 ペタバイトのストレージ容量と合計 15 Gbps の帯域幅を提供していました。当社は、最大オブジェクトサイズを 5 GB として、数百億個のオブジェクトを保存できるようにこのシステムを設計しました。当初の料金は 1 ギガバイトあたり 15 セントでした。 S3 は現在、数百エクサバイト規模のデータを対象として、39 の AWS リージョン内の 123 のアベイラビリティゾーンで、数百万のお客様のために、500 兆個超のオブジェクトを保存し、世界中で毎秒 2 億件超のリクエストを処理しています。 最大オブジェクトサイズは 5 GB から 50 TB へと、1 万倍に増加しました。数千万台すべての S3 ハードドライブを積み重ねると、国際宇宙ステーションまで届き、ほぼ往復できるほどの高さになります。 S3 はこのような驚異的な規模を支えるまでに成長しましたが、お客様が支払う料金は低額になりました。今日、AWS が課金しているのは、 1 ギガバイトあたり 2 セント をわずかに上回る料金です。これは、2006 年のリリースから見ると、約 85% 低い料金です。同時に、ストレージ階層を使用してストレージにかかる支出をさらに最適化する方法も継続的に導入しています。例えば、 Amazon S3 Intelligent-Tiering を利用することで、 Amazon S3 Standard と比較して、お客様全体で合計 60 億 USD 超のストレージコストを削減しています。 過去 20 年間にわたって、 S3 API はストレージ業界全体で採用され、基準点として利用されてきました。現在、複数のベンダーが S3 互換のストレージツールとシステムを提供しており、同じ API パターンと慣例を実装しています。これは、S3 向けに開発されたスキルやツールが他のストレージシステムにも応用できることが多く、より広範なストレージ環境へのアクセスが容易になることを意味します。 このような成長や業界での普及にもかかわらず、おそらく最も注目すべき成果は、2006 年に S3 向けに作成したコードが、現在も変更されることなく機能していることです。お客様のデータは 20 年間のイノベーションと技術的な進歩を経てきました。当社は、複数世代のディスクとストレージシステムにわたって、インフラストラクチャを移行してきました。リクエストを処理するためのコードはすべて書き直されています。しかし、お客様が 20 年前に保存したデータは今日でも利用可能であり、当社は API の完全な後方互換性を維持しています。これは、常に「問題なく機能する」サービスを提供するという当社のコミットメントです。 規模を支えるエンジニアリング S3 をこれほど大規模に実現できるのはなぜでしょうか? その答えは、エンジニアリングにおける継続的なイノベーションです。 以下の内容のほとんどは、AWS の VP of Data and Analytics である Mai-Lan Tomsen Bukovec と、 The Pragmatic Engineer である Gergely Orosz 氏との対談に基づいています。 詳細なインタビュー では、より深く理解したい方のために、技術的な詳細をさらに掘り下げています。以下の段落では、いくつかの例をご紹介します: S3 の耐久性の中心にあるのは、フリート全体ですべてのバイトを継続的に検査するマイクロサービスのシステムです。これらの監査サービスはデータを監視し、劣化の兆候を検出した瞬間に修復システムを自動的にトリガーします。S3 はロスレスになるように設計されています。イレブンナインという設計目標は、レプリケーション係数と再レプリケーションフリートの規模を反映したものですが、システムはオブジェクトが失われないように構築されています。 S3 のエンジニアは、本番において 形式手法と自動推論 を用いて、数学的に正確性を証明しています。エンジニアがインデックスサブシステムにコードをチェックインすると、自動証明によって一貫性が損なわれていないことが検証されます。この同じアプローチは、 リージョン間レプリケーション や アクセスポリシー の正確性を証明します。 AWS は過去 8 年間にわたって、S3 リクエストパスのパフォーマンスクリティカルなコードを Rust で段階的に書き換えてきました。Blob の移動とディスクストレージは書き換えられ、現在は他のコンポーネントで作業が積極的に進められています。生のパフォーマンスだけでなく、Rust の型システムとメモリ安全性の保証により、コンパイル時にバグのクラス全体を排除できます。これは、S3 の規模と高い正確性の要件を満たす必要がある運用において不可欠な特性です。 S3 は「スケールはメリットである」という設計哲学に基づいて構築されています。 エンジニアは、スケールが拡大することで、すべてのユーザーにとって性能が向上するようにシステムを設計します。S3 の規模が大きくなるほど、ワークロード間の相関性が低下し、すべてのユーザーにとって信頼性が高まります。 今後の展望 S3 のビジョンは、単なるストレージサービスを超え、すべてのデータおよび AI ワークロードの普遍的な基盤となることです。当社のビジョンはシンプルです。すなわち、あらゆる種類のデータを S3 に一度保存すれば、専用システム間でデータを移動させることなく、直接そのデータを利用できる、というものです。このアプローチにより、コストが削減され、複雑さが解消され、同じデータの複数のコピーを作成する必要がなくなります。 近年の注目すべきリリースをいくつかご紹介します: S3 Tables – 時間が経過する中で、クエリ効率を最適化し、ストレージコストを削減する、自動メンテナンスを備えたフルマネージド Apache Iceberg テーブル。 S3 Vectors – セマンティック検索と RAG のためのネイティブベクトルストレージ。インデックスあたり最大 20 億のベクトルをサポートし、クエリレイテンシーは 100 ミリ秒未満です。わずか 5 か月間 (2025 年 7 月～12 月) で、25 万を超えるインデックスを作成し、400 億を超えるベクトルを取り込み、10 億件を超えるクエリを実行しました。 S3 Metadata – データの即時検出のための一元化されたメタデータ。カタログ化のために大規模なバケットを再帰的にリストする必要がなくなり、大規模データレイクに関するインサイトの取得までの時間を大幅に短縮します。 これらの各機能は S3 のコスト構造で利用できます。従来は高コストのデータベースや専用システムが必要だった複数のデータタイプを、大規模かつ経済的に処理できます。 1 ペタバイトから数百エクサバイトに。1 ギガバイトあたり 15 セントから 2 セントに。シンプルなオブジェクトストレージから、AI と分析の基盤へ。このような変化の中にあっても、当社の 5 つの基本原則、すなわち、セキュリティ、耐久性、可用性、パフォーマンス、伸縮性は変わっていません。そして、2006 年に書かれたお客様のコードは、今日も機能します。 Amazon S3 における次の 20 年間のイノベーションに祝意を表したいと思います。 – seb 原文は こちら です。

.table-of-contents > li > ul > li > ul { display: none; } はじめに こんにちは、検索基盤部の倉澤です。ZOZOTOWNの検索機能のバックエンドの開発を担当しています。検索基盤部の一部システムではGoを採用しています。 2026年2月21日（土）にGo Conference mini in Sendai 2026が開催されました。本記事では、会場の様子や個人的に印象に残ったセッション・LTについて紹介します。また、私もLT枠で登壇したため当日話しきれなかった内容もあわせて紹介します。 目次 はじめに 目次 Go Conference mini in Sendai 2026とは 会場の様子 セッション AI時代のGo開発2026 爆速開発のためのガードレール 個人的に気になった点 Go パッケージのサプライチェーン攻撃を防ぐ CI を作ってみた 個人的に気になった点 Go 1.26 で生まれ変わった go fix をプロダクト開発の運用に乗せる 個人的に気になった点 encoding/json/v2のUnmarshalはこう変わった ~内部実装で見る設計改善~ このテーマを選んだきっかけ さいごに Go Conference mini in Sendai 2026とは Go Conferenceは、プログラミング言語Goに関するカンファレンスです。今回は「東北から広がるGoコミュニティ」というテーマで仙台にて4年ぶりに開催されました。18セッション（20分）と12のLT（5分）によって構成され、Goに関するさまざまなテーマについて発表されました。参加者は117人と大盛況のうちに終わりました。 sendaigo.jp 会場の様子 会場は仙台市青葉区にあるアーバンネットビル仙台中央 カンファレンスルームでした。ワンフロアにスポンサーブースと2部屋のセッションルームがあり、同時に発表が行われました。 オープニングの様子 スポンサーブースでは、参加者向けのさまざまなコンテンツが用意されていました。 株式会社UPSIDERさんのブース 株式会社UPSIDERさんのブースでは、「Goの挑戦Goっそり教えて！」をテーマに意見が募られていました。「TinyGoを使って何かを作ってみたい」等の声があり、TinyGoへの関心の高さがうかがえました。 株式会社SODAさんのブース 株式会社SODAさんのブースでは、「あなたのやらかしエピソードや懺悔したいことを教えてください」をテーマに意見が募られていました。生成AIが書いたコードによってやらかしたエピソードが昨今の開発事情を表していて面白いなと思いました。また、SODAさんのブースではGopherの16タイプに分ける診断を実施しておりました。 snkrdunk.github.io 私は、「数学的な賢者」でした！ Gopherの16タイプ診断 会場では参加者全員にステッカーなどのノベルティが配布されており、どれもとても可愛らしいデザインでした。 ノベルティのステッカー また、ネームタグの裏側には「すぐに使える仙台弁」が記載されており、参加者同士の会話のきっかけになっていました。仙台開催ならではの遊び心が感じられる演出でした。 ネームタグ さらに登壇者にはTシャツが配布され、登壇の良い記念になりました。運営の皆さまのお心遣いに感謝です。 登壇者用のTシャツ セッション AI時代のGo開発2026 爆速開発のためのガードレール www.docswell.com こちらのセッションでは、生成AIにおける開発の「速さ」と「治安（コード秩序やルール）」をいかに両立させるのかについて紹介されています。 課題 生成AIの発達・普及により実装速度が飛躍的に向上した一方で、アーキテクチャのルール違反などコードの治安が悪化しやすくなっている。 対策 Rules/Skillsのような非決定的な制約（ソフト制約）だけに頼るのではなく、決定的な制約（ハード制約）をガードレールとして整備することが重要。 紹介されているハード制約の例 Goの internal パッケージによるアクセス制御 depguard 等のLintによる依存ルールの強制 Fuzzing testやMutation testによるテスト品質の担保 個人的に気になった点 アーキテクチャの依存ルールを生成AIに守らせるという観点で、Goの internal パッケージを用いるというのは面白い発想だと思いました。一方で、ドメイン単位でパッケージを分割する Package by Feature だからこそ威力を発揮する一面もあるのかなと思いました。私が携わっているプロジェクトでは、アーキテクチャの技術的な役割（レイヤー）毎にパッケージを分割する Package by Layer を採用しています。 internal パッケージの配下に各レイヤーのパッケージを切る構成が一般的です。この場合、 internal が守れるのは外部モジュールからのアクセスであり、 internal 内部のレイヤー間の依存方向までは防げません。 発表後に登壇者の方へ質問したところ、 Package by Layer でも internal パッケージが活きるケースを共有していただきました。各層でしか使わない関数を他の層から使われないように守るという観点です。例えば、 presentation 層でレスポンスに対して処理する関数を internal に配置すれば、他の層からの誤った利用を防げるとのことでした。レイヤー間の依存方向の制御とは別に、各層の内部実装の隠蔽という観点で internal が有効に機能するというのは納得感がありました。 Go パッケージのサプライチェーン攻撃を防ぐ CI を作ってみた speakerdeck.com こちらのセッションでは、Goパッケージのサプライチェーン攻撃をCIで防ぐ取り組みについて紹介されています。 課題 typosquatting （タイプミスを狙った攻撃）や slopsquatting （AIのハルシネーションを狙った攻撃）により、悪意のあるパッケージの混入リスクがある 対策 Googleが公開している capslock を活用し、パッケージがアクセスし得る特権的操作（ファイルシステム操作、ネットワーク通信など）を静的解析で検知 PRで新しいパッケージが追加された際に、 main ブランチとのCapabilityの差分をCIで検出 その結果をClaude Code Actionに読み込ませることで、セキュリティリスクを診断する仕組みを構築 個人的に気になった点 こちらのセッションは、昨年開催されたGo Conference 2025の「 サプライチェーン攻撃に学ぶmoduleの仕組みとセキュリティ対策 」に続く内容だと感じました。昨年の発表では、Goのパッケージ管理システムを利用したサプライチェーン攻撃が3年以上見つからず、その根本的な対策も難しいという話がありました。本発表はLT枠で5分と短かったですが、昨年のGo Conferenceで発表された課題に対して対策を検討し、同じくGo Conferenceで発表するという流れにとても感心しました。 発表内容で気になったのは、新しく追加されたパッケージのCapabilityから悪意の有無をClaude Codeがどう判断しているかという点です。登壇者の方に質問したところ、依存先パッケージのメソッド名や周辺の実装をもとに判断していると考えられるとのことでした。また、サードパーティの公式パッケージを追加した際にも、依存先パッケージでCapabilityの警告が出るケースもあったそうです。ただし公式パッケージである以上、対処は難しく、まだ改善の余地があるとのことでした。 Go 1.26 で生まれ変わった go fix をプロダクト開発の運用に乗せる speakerdeck.com こちらのセッションでは、Go 1.26で大幅に刷新された go fix コマンドをプロダクト開発の現場にどう組み込むかについて紹介されています。 運用フローの設計 「検知」と「適用」を分けて考えるのがポイント 検知（毎PR）： golangci-lint の modernize を有効化し、CIで古い書き方を常時警告する 適用（Goバージョン更新時）： go fix ./... を2回実行して既存コードを一括変換する go fixに関する3つのアプローチと使い分け modernize ：組み込みルールによるコードのモダン化。go fixを実行するだけ SuggestedFix ：自作Analyzerに修正提案を追加し、プロジェクト固有のパターンを自動修正する go:fix inline ：非推奨関数に //go:fix inline を付与し、利用者側でgo fixを実行するだけでAPI移行を自動化する 個人的に気になった点 先日公開された公式ブログ「 Using go fix to modernize Go code 」を読んでおり、最近私も go fix を実行した経験がありました。そのため、運用観点の話はとても興味深い内容でした。特に気になっていたのは、 go fix の「2回実行が必要」という点の仕組み化です。ある modernize ルールの適用が別のルールの適用機会を生むため、公式ブログでも2回の実行が推奨されていますが、これを仕組み化するのは難しいと感じていました。登壇者の方に質問したところ、以下のような回答をいただきました。 まだ完全な仕組み化はできていないが、 pre-commit フックでコミット前に go fix を実行する方法を検討している ただしpre-commitの導入はチームにより意見が分かれるため、Claude CodeのSkillsで実行させるのも有効ではないか 生成AIのSkillsは、こうした「毎回やるべきだが柔軟さも求められるルール」の適用に向いているという点に納得感がありました。また、 golangci-lint の modernize リンターについても質問しました。内部的にはgo fixと同じ modernize アナライザが動いているため、こちらも同様に複数回の実行が必要とのことでした。 encoding/json/v2のUnmarshalはこう変わった ~内部実装で見る設計改善~ speakerdeck.com 私も今回LT枠で登壇いたしました。このセッションでは、Go 1.25で実験的に追加された encoding/json/v2 パッケージの Unmarshal 関数を取り上げました。従来の encoding/json パッケージが抱えているパフォーマンス上の課題と、v2での改善点を内部実装の観点から紹介しました。 v1での課題点 パッケージの構成 ：1つのパッケージに「JSONを解析する処理」と「Goの構造体に変換する処理」がすべて混在しており、変更時の影響範囲も広かった エラーメッセージ ：JSONのパース（解析）に失敗したとき、どの項目でなぜ失敗したのかがエラーメッセージから読み取りにくかった メモリの使い方 ：Unmarshalを呼ぶたびに内部で使うオブジェクト（Decoder）を毎回新しく作成しており、高頻度で呼び出すとメモリ確保やGC（ガベージコレクション）の負担が大きかった データの読み取り方 ：JSONデータを読み取るたびに内部でコピーが発生しており、メモリ効率が悪かった v2での改善点 パッケージの分離 ：「JSONの解析」を担う jsontext パッケージと「Goの型へのマッピング」を担う json パッケージに分離し、それぞれの役割を明確にした 構造化されたエラー ：エラー情報にJSONのどの位置で、どんなJSON型が原因で失敗したかを含めるようにし、原因の特定が容易になった オブジェクトの再利用 ：sync.Poolパッケージを使い、一度作った Decoder を使い回すことで、メモリ確保の回数とGCの負担を大幅に削減した 効率的なバッファ管理 ：1つのバッファ（データを一時的に保管する領域）を論理的に分割して管理することで、データのコピーなしに必要な部分へアクセスできるようになった このテーマを選んだきっかけ 普段の業務ではREST APIを実装する機会が多く、 encoding/json パッケージを利用する場面も多くありました。しかし、 encoding/json には以前から課題が多く、 golang/go#71497 でも長期にわたって議論が続いています。そんな中、Go 1.25で実験的にv2が追加されました。 go-json-experiment/jsonbench のベンチマーク結果を見ると、v2の Unmarshal 関数は以下の点で大きく改善されていることがわかります。 大幅な速度改善 ：具象型で2.7〜10.2倍、RawValue型では最大21.1倍と、v1から劇的に高速化されている 安全性を犠牲にしていない ： unsafe パッケージを使用せず、UTF-8の検証や重複キーの拒否などRFC準拠の正確性も向上している ストリーミング対応 ：v1では非対応だった Unmarshal のストリーミングにも設計当初から対応している 速度・正確性・安全性のいずれも改善されているという結果から、「なぜこれほど改善できたのか？」を内部設計から理解したいと思い、 アドベントカレンダーの記事 で調査しました。その調査がきっかけとなり、今回プロポーザルを提出しました。 さいごに 今回LT枠ではありますが、初めてGo Conferenceにプロポーザルを提出し、採択していただきました。発表後には「あと20分くらい聞きたかった」や「よく5分でまとめましたね」などとても温かいお声をいただきました。登壇を機に、さまざまな方と繋がれたことは非常に貴重な経験でした。アウトプットがきっかけで生まれる繋がりの大切さを改めて実感しました。また、登壇を機に初めて仙台へ行きました。牛タンやずんだ餅など仙台グルメも堪能でき、カンファレンスと合わせて充実した思い出となりました。 最後に、このような素晴らしい場を作ってくださった運営の皆さまに心から感謝いたします。準備から当日の進行まで、細やかな配慮が行き届いており、登壇者・参加者いずれの立場でも安心して楽しむことができました。 ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com

TechHarmonyエンジニアブログでは、 AWS・Oracle Cloud・Azure・Google Cloud 各分野の受賞者 にフォーカスし、インタビューを通してこれまでの経歴や他の受賞者に聞いてみたいことをつないでいく「 リレーインタビュー 」をお届けしています。 第3弾は、「2025 Japan AWS Top Engineers」 を受賞された 寺内 康之（てらうち やすゆき）さん。 Japan AWS Top Engineers は、特定の AWS 認定資格を持ち、AWS ビジネス拡大につながる技術力を発揮した活動を行っている方、または技術力を発揮した重要な活動や成果がある方が選出されるプログラムです。 日々どのようにAWSと向き合い、どんな経験を積み重ねてきたのか。 そして、受賞に至るまでの背景には、どのようなキャリアストーリーがあったのでしょうか。 本インタビューでは、寺内さんのこれまでの経歴やAWSへの向き合い方、さらに「次の受賞者へ聞いてみたいこと」まで、じっくりとお話を伺いました。 プロフィール 2025 Japan AWS Top Engineers   所属： ITインフラサービス事業グループ クラウドサービス事業本部 クラウドサービス第二部 氏名： 寺内　康之   【自己紹介】 2024年、2025年と続けてJapan AWS Top Engineers (Service) に選出されました。今現在は、AWSの内製化を目指すお客様に対し、技術支援サービス「 テクニカルエスコート 」を提供するチームのリーダを担っています。 私は、小学生の頃にパソコン(PC-8001)に出会い、その後パソコン通信にハマり、大学ではUNIXの洗礼を受けました。 ネットワークエンジニアとして就職。その後サーバエンジニアとしても業務を行い、様々なお客様のシステム構築と運用を行いました。また自社で構築したサービス運用も経験するなど、いろいろな部署を渡り歩き、嬉しいこと辛いことの経験を積みました。 そんな中AWSと出会い、衝撃を受けることになります。AWSを中心にビジネスをしている現在の部署に異動し「テクニカルエスコート」を立ち上げました。 本編  AWSエンジニアになった背景を教えてください。 2007年にEC2が発表されAWSを知ったときの衝撃は忘れられません。サーバを作ることがソフトウェアのようにすぐに実現するという即時性と利便性は信じがたいものでした。 その 驚き が 魅力 に変わり、AWSのサービスに魅了されていきました。 その後のAWSのサービス拡充の勢いはすごいもので、新サービスのたびに感嘆したものです。従来の ITの概念を塗り替える 、その センス・オブ・ワンダー を皆さんにも感じてほしく、AWSを使った仕事をしたいと考えました。 基盤エンジニアであった私は、趣味でプログラミングをする程度ではあったものの、AWSが打ち出す開発者向けサービスとその思想に共感し、徐々に上位レイヤーへの進出も測っております。ITやクラウドは遷り変わりの早い世界であり、日々勉強を続けております。 エンジニアとして大切にしている価値観や信条はありますか？ 「使える」「作れる」というシステムの表面的な挙動だけではなく、その 裏にある技術的理論 をしっかり勉強することです。クラウドサービスは、コンピュータおよび通信の原理原則の上に、基礎技術が構築されており、それを組合せ抽象化したものです。その原理原則をしっかり学び理解した上で、システムを作っていきたいと考えています。 学ぶことは試行錯誤の連続であり、多くの エラーの先に成功 があります。それは自分だけでなく、誰でも同じだと思っています。業務の上でも、技術支援サービスは新しい体験が数多くあり、新しい試みは常に失敗と隣り合わせです。そのため 他者の失敗を許容する文化醸成を心がけています この度は受賞おめでとうございます！ 受賞に至るまで特に重点を置いて取り組んできたこと・乗り越えたチャレンジを教えてください。 まずは足場固めとして、AWSをSCSK社内で使ってもらうにはどうしたらいいかを考えました。 クラウドという概念は知っていても、いざお客様に提案しようとすると躊躇してしまう。なぜなら良くわからないから。だから経験をすることができない。こうした負の連鎖を断ち切りたいと考えました。そこで 社内 に対しても 社外 に対しても 実施する技術支援サービスを立ち上げ ました。 長く続いた オンプレシステム と、 クラウドサービス上で作るシステム とでは、システム設計の考え方が大きく 違い ます。このことを多くのエンジニアに 理解してもらう取り組みを続けています。 受賞がご自身のキャリアやチームに与えた影響はありますか？ 個人的には大きな 自信 につながりました。お客様と話す際も堂々と話せるようになったと思います。 チームとしては、メンバーの目標の一つにもなっていると思い、その結果 メンバーのスキル向上の啓蒙 になっていると思います。 またビジネスとしては お客様から の 信頼 される 効果が大きいです。特に技術支援という、技術力が重視され る ビジネス においては アピール として 箔 が付いた ことが何より有り難いです。 今後、個人として、挑戦してみたい新しい技術・分野や、目指している目標について教えてください。 IT技術進歩の歴史の中では、大きなブレイクポイントが度々ありました。インターネットの商業利用開始、スマートフォンの発明、クラウドサービスの開始、 ディープラーニング の 実用化 。こうしたブレイクポイントが起こると、そこには大きなビジネスチャンスが産み出されます。それを逃さず習得し、 新たなビジネス/サービス を創出 していきたいと考えています。LLMの成功から、機械学習・人工知能が大きな潮流となっておりますので、それは確実にキャッチアップしていきます。その 次は 、 量子コンピューティング だと思っています。 我々のチームは、基盤技術者が多いためアプリケーション開発に関する 技術の経 験 を積む ことが目標です。また DevOpsやAI-DLCなどの新たな開発体制・手法についての支援力をより拡充していきます。 前回のリレーインタビュー での佐藤 優音さんから 寺内さんへのご質問です。ご回答をお願いいたします。 寺内さんは、クラウド 黎明期 から 新しいサービスに関する知識 を積極的に 収集 されてきたと思いますが、常に最新技術をキャッチアップするための ポイントを教えて ください！ 一番の情報収集元はSNSです。自分の興味ある話題を発信することで 、SNSプラットフォーム が私の興味領域を学習し、 近しい話題を優先的に表示 してくれます。 発信 の増加が 入力 の増加につながる好循環を生み出すことがSNS活用のコツだと思います。 他にも、AWSやIT技術の アンテナの高い社内の人との対話 が非常に有用ですね。 次のインタビューは AWS Top Engineers の「畑 健治」さんです！畑さんにお聞きしたいことはありますか？ 畑さんはDBからアプリケーションまで 幅広いIT技術 を 習得 されていますが、コンピュータに触れていて 一番楽しいと思う点 はどんなところにありますか。 寺内さん、ありがとうございました！ 最後に、読者の方へメッセージをお願いいたします！ ITの原理原則は科学技術で成り立っています。 物理 や 数学 を疎かにせず勉強していきたいです。そして現実はSFビジョンに近づいてきました。正しく技術を理解し、 次の新たな未来をSF的思考をする こと、それが新たなエネルギーになると信じ、想像の翼を広げていきましょう   次回インタビューは、2025 Japan AWS Top Engineers を受賞された 畑 健治 （はた けんじ）さんです。 次回の記事もお楽しみにお待ちください！