本記事は、下記イベントに対するセッションレポートとなります。 イベント名：Regional Scrum Gathering Tokyo 2026 日時：2026/01/07 登壇者：Kei Ogane 氏 セッション名：複雑さを受け入れるか、拒むか？事業成長とともに育ったモノリスを前に私が考えたこと 本記事の筆者は、モバイルアプリ開発エンジニア、アジャイル開発のスクラムマスター、という立場で案件支援業務に主に携わっています。最近は、生成AIを活用した開発プロセスの整備・導入の支援業務も担当しています。このような立場で感じたセッションレポートを、下記に共有いたします。 セッション内

はじめに：AIに 取って代わられる 恐怖よりも、エンジニアとして学ぶべきことの多さに恐怖している 4月で、エンジニアとして4年目に突入しました。まだまだ、エンジニアとして未熟だと痛感する毎日でございます。私は、プロダクト開発に関わる傍ら、AIを組織に導入したりその後の活用を推進するプロジェクトにも属していました。 プロジェクトの進行で必要な知識をつけるために、AIモデルプロバイダーが発信する知識や、LT会・カンファレンス・社外の事例の記事を調べています。その中で感じているのは、エンジニアとして学ぶべきことの多さです。AIについて調査すればするほど、取って代わられる恐怖よりも、「これからエンジニアとしてこんなに学ばないといけないのか…？」と学ぶべきことの多さに戦慄しています。 2026年4月22日（水）に Sansan株式会社Eight主催のテックリードカンファレンス に参加しました。本記事では、そこで感じたことを、それを増強するための書籍・動画で発信されている知識と組み合わせてお伝えしようと思います。 左: 和田 卓人氏(タワーズ・クエスト株式会社　取締役社長)　右: 佐藤 治夫氏(株式会社ビープラウド　代表取締役社長) なお、本記事は 4ヶ月前に書いた記事(AI時代も変わらない、ソフトウェア開発の基礎) の続きという位置付けでもあります。基礎の重要性を改めて確認し、より具体的な「ではどうするか」に踏み込んでいく内容です。 TL;DR（この記事のまとめ） 「AIに取って代わられる恐怖」や「AI爆速開発の焦り」への対応は、分からないことを放置せず基礎をコツコツ学び続けること。 AIは「簡単さ（Easy）」を極限まで高めたが、システムを「シンプル（Simple）」にしてはくれない。複雑性を切り分け制御できるのは、ドメインや技術を深く理解している人間の役割である。 「1人でAIと爆速開発」というリソース効率の罠から抜け出し、モブプログラミングや Agent Skills による「チームでの意思決定と暗黙知の言語化」へ向かう。 AIエージェントとの関わり方：物的生産性から離れ、対象物を深く理解する カンファレンスでハッとさせられたのは、和田卓人氏の「 AIによる物的生産性に血眼になっているのではないか？ 」という問いかけでした。 AIによってコードの記述スピードは劇的に上がりましたが、だからこそ「誰もいらないものを高速に作っても意味がない」状態になっています。和田氏は講演の中で、AIの登場によってプロトタイプを用いた価値の検証が容易になり、「 価値探索とプログラミングがかなり紐づいてきた 」と語っていました。コードを速く書くことではなく、対象物を深く理解し「何を作るか」を探索することに、エンジニアの主眼は移りつつあります。 この「 スピード（簡単さ）に溺れず、理解を優先する 」という姿勢の重要性は、世界的なソフトウェアエンジニアリングの潮流とも完全に一致しています。Netflix のエンジニア Jake Nations 氏による講演「 The Infinite Software Crisis 」では、次のように指摘されていました。 簡単（Easy）はシンプル（Simple）を意味しない。簡単とはシステムに素早く追加できることであり、シンプルとは自分のやった仕事を理解できることだ。簡単を選ぶたびに、私たちは「今のスピード」と引き換えに「後々の複雑さ」を選んでいる。AIは簡単さを極限まで高めたが、シンプルさを生み出すわけではない。 何を作るかを理解し設計することの難しさは、どのツールも排除できません。 また、「 Software Fundamentals Matter More Than Ever 」という講演でも、次のように語られていました。 「コードは安い」という言説は誤りである。悪いコードは今まで以上にコストが高い。変更しにくいコードベースは AI の恩恵を受けられない。 これは私が4ヶ月前に書いた記事でも触れた DORA レポートの「AI は増幅機」という主張と重なります。良いコードベースであるほど恩恵を受けやすく、悪いコードベースであるほど機能不全が拡大する。基礎の重要性は、AI 登場後にむしろ高まっています。 この点について、『ソフトウェアエンジニアガイドブック』（Gergely Orosz 著）の日本語版特別付録インタビュー（p.557）でも、次のように語られていました。 「問題は、経験の少ないエンジニアがAIに『主導権を握らせ』、AIが何をしているのか理解しないまま仕事を全部任せてみたくなるように誘惑されることです。したがって、『AIと共に学び続け、思考をAIに外注しないエンジニア』への需要は増加するものの、その供給はおそらく減少します！奇妙な時代が訪れることでしょう」 理解を放棄してAIに主導権を渡さない姿勢こそが、これからのエンジニアの価値を左右しそうです。 では、AIに主導権を渡さず、自分たちの理解を保ちながら開発するにはどうすればいいのか？  その具体的な対策として和田氏が推奨していたのが、 Test First でやる場所と、Red-Green-Refactor のように小さなサイクルで回す場所を分ける  ことでした。 エージェントに任せても良いと判断した領域では、ざっくりとした Test First で問題ない。一方で、人間がリアルタイムにレビューして品質を担保したい領域では、Diff（差分）の小さい TDD のステップを強制する方がよい。これは、人間が何千行ものファイルを一気にレビューして理解するのは現実的ではないからです。 AIの爆速な出力に流されず、人間の認知負荷を意図的に下げるために、理解できる範囲に留める仕組みとして、非常に納得感がありました。 開発速度の見直し：モブプログラミングの再評価とリソース効率の罠 AIの登場により、コーディング工程は劇的に短縮されたように感じる場面が多くなったのではないでしょうか。しかし、Tech Lead Conference 2026 でのSansan株式会社（笹川裕人氏）のセッションでも指摘されていたように、開発プロセス全体のボトルネックは「コーディング」から「レビューやテスト」へと移動しています。 かつてGitHubが普及した頃、「1人1ブランチで開発できる＝リソース効率100%」という発想が、プルリクのレビュー待ちというボトルネックを生みました。今、「コーディングエージェントをN列並列で動かす」という発想も、全く同じパターンにはまる危険性があります。 真のボトルネックは、コードを書くことではなく、人間側の判断・レビュー能力です 。 この点について、和田卓人氏は別の対談動画（ AI疲れとジュニアエンジニア育成、モブプログラミングの役割 ）で、次のように語っています。 コーディングエージェントによって、実行責任はエージェントへ、説明責任・品質保証は人間へ、という役割分担になっていく。テックリードが担っていた判断の負荷が全員に降りてきた。 AIが多様な要求に対して提案を返してくる中で、その判断を一人で全部こなすのは現実的ではありません。そこで和田氏が推奨していたのが、 モブプロの実施 です。 AI によってコード生成は十分に速くなっていたとしたら、人間はペアやモブを組む余裕があるはずです。複数人でエージェントと関わり、即時に判断していく。この判断を複数人ですることで、知識移転（教育）も行える可能性について言及していました。 そして、この「リソース効率からフロー効率への転換」と「教育」の重要性は、別の動画（ シニアのゲームに巻き込まれるな ）でも触れられています。 「AIで1日のプルリク量が何倍に」「数日で個人開発アプリを完成」という SNS 投稿に踊らされてはいけない。シニアには元々の積み上げがあるため同じ土俵では勝てない、という主張は、私としては耳が痛い話でした。 圧倒的な積み上げがあるシニアエンジニアと同じ土俵で戦おうとすれば、経験の少ないエンジニアは疲弊し、学びの機会を失います。私も、特に言われたわけではないですが、物的生産性にとらわれて、AIにコード生成させたりレビューさせて、そのまま使うみたいなことがありました。これを、意図的にやっているというより、誰からも要求されていないのに、無理して成果を出そうとしていたなと反省しています。物的生産性を多少下げてでもモブプログラミングの場にジュニアを巻き込み、「チームとしての判断力」と「教育」を両立する構造を作ることが、AI時代には不可欠ではないかと考えています。 開発プロセス：変わらないものと、Agent Skills による専門知識の言語化 AI時代になっても、チーム開発のプロセス全てがひっくり返るわけではありません。Sansan株式会社（笹川裕人氏）のセッションでも、「スクラム等のプロセスの本質（経験的に起きる課題への対処法）は変わらない」とはっきり言語化されていました。 一方で大きく変わるのは、AIという新しいメンバーへの指示の出し方です。合同会社Have Fun Tech代表の曽根武友氏は、「 AI時代における具体と抽象の往復 - 日常にチャンスがある 」というセッションの中で次のように語っていました。 AIへの指示も、結局は人間同士のコミュニケーションと同じ原理。「いい感じにして」が伝わらないのは、プロンプトの抽象度と相手（AI）の抽象度が一致していないから。 具体化には知識が必要であり、相手のドメインで話すにはそのドメインの知識が要る。 この「『いい感じに』という抽象的な指示を具体的な手順に変換するための知識」の重要性は、Anthropicの講演「 Don't Build Agents, Build Skills Instead 」でも強く主張されています。エージェントという曖昧な存在にすべてを丸投げするのではなく、特定のタスクを遂行するための「Skills（専門知識のパッケージ）」を構築すべきだというのです。 AIに的確な指示を出すための「Agent Skills」の整備は、単なるツールの設定ではありません。 チーム内の暗黙知を言語化し、共有知にしていくプロセスそのもの なのです。 国内の企業では、すでにこの「個人の暗黙知から組織の共有知へ」という取り組みが始まっています。 株式会社タイミーでは、「 Agent Harness Group 」という組織を立ち上げ、「個のAI活用」から「組織のAI駆動開発（AI-DLC）実践」へと協業を推進しています。また株式会社LayerXでは、モバイルチームで「 Claude Code Subagents祭 」と題した社内イベントを開催し、属人化しがちなAIへの指示やプロンプトをチームの共有知へと昇華させています。 私自身が推進しているAIエージェント活用においても、ここが最大のポイントになると感じました。単にAIツールを導入するだけで終わらせるのではなく、 Agent Skillsという機能を、AIというメンバーに暗黙知を伝える手段や、組織のベストプラクティスを誰もが簡単に再現できる方法として利用するための仕組みを作っていきたい と考えています。それこそが、AI時代における組織の長期的な競争力の源泉になるはずです。 学習：焦らず、理解を放置しない AIエージェントがコードを爆速で生成してくれる時代において、私たちが個人として取り組むべき最も重要なアクションは、「分からないところを放っておかない」という基本的な学習姿勢です。 Tech Lead Conference 2026でのセッションを通じて、登壇者三者の主張が見事に一致していたのが、この「継続的な学習の重要性」でした。和田卓人氏は、学習について次のように語っていました。 新人は、焦らずに学んでいく必要がある。自分がわからないところを放っておかずにやっていく必要がある。質を下げればスピードが上がるわけではない。トレードオフなのは教育である。質とスピードを担保させるために、教育することが必要になる。 曽根武友氏も、AI が発展しても変わらないこととして「 抽象と具体の往復スキル、ドメイン知識、継続的な学習 」を挙げていました。仕事の形は変われど、この往復の精度を上げることが本質である、と。 さらに、Sansan株式会社 のセッションでも、エンジニアのキャリアパスについて語られていたところで、「 仕事の総量は変わらない——AI で効率化されても別の仕事が生まれる。継続的な学習の必要性は変わらない 」という言葉がありました。この三者の主張は完全に一致しています。 『良いコード／悪いコードで学ぶ設計入門』の著者であるミノ駆動氏も、AI時代に漠然とした不安を抱えるエンジニアに対して、動画（ AI時代に“伸びる人・終わる人”の決定的な差 ）で次のように指摘しています。 漠然と不安に思っている人は、技術を学んでスキルアップすることが不安の解消に繋がっていると思えていないのではないか。不安を覚えるのなら勉強しましょう。 ミノ駆動氏は、AIは「ネット上の学習内容の平均」に収束する傾向があるため、設計的に問題のある構造でも技術知識がなければ素通りしてしまうと語っています。 AIが60〜70点のものしか出せないのは、指示する人間の基礎力（問題を見抜く力）が足りていないから でもあるのです。 また、ファインディ株式会社の高橋氏の動画（ ジュニア育成と組織学習 ）では、AI時代のエンジニア評価について、次のような組織側の変化が語られていました。 機能を何個作ったかっていうよりも、何を学んだかをアピールする時代になってきている。 これは個人の姿勢だけでなく、組織側にも問われることです。アウトプットの量だけを評価指標にすると、生成AIでいくらでも量産できてしまい、本当の力が見えなくなります。「何を学んだか」を評価し、基礎力を高め続ける仕組みを持っているかが、これからの人材育成の分かれ目になります。 最後に、和田卓人氏が別の対談動画の結びで語った、若手エンジニアに向けた言葉を引用します。 自分の能力をコツコツ上げていくことが、自分の競争力を上げていくことにそのままより大きく繋がる時代になってきたと思ってください。…（中略）… 焦らずにコツコツやっていけばいい。希望を持つ上でのコツは、人と比べないことです。比べるのは過去の自分です。 SNSを見れば、AIを使って爆速で開発している人がいくらでも目に入ります。しかし、そこで焦って理解を放棄するのではなく、自分の分からないところを放置せずにコツコツと基礎を積み上げていく。それこそが、AI時代を生き抜くための最強の生存戦略なのだと、改めて心に刻みたいと思います。 まとめ：教育とフロー効率を両立する3つの方向性 4つの観点を通じて感じたのは、ひとつの共通したメッセージでした。 AI は「理解の代替」ではなく「理解の加速器」として使う。 そのために、私たちが明日から取れる具体的なアクションは、以下の3つに整理できると考えています。 1. 物的生産性に流されず、対象への「理解」を深める姿勢と仕組み化 AIによる爆速なコード生成に流されず、「自分が理解できないもの」を放置しないことが第一歩です。分からない概念があればAIに説明させて基礎をコツコツ積み上げる「個人の学習姿勢」を持つと同時に、Test First でざっくり任せる領域と、Diffの小さいTDDのサイクルで回す領域を分け、人間の認知負荷を意図的に下げる「開発の仕組み」を取り入れること。アウトプットの量ではなく、「何を学び、どう理解したか」を重視する姿勢が問われます。 2. モブプログラミングによる判断とレビューの分散 一人がエージェントと対話して爆速で開発するリソース効率の罠から抜け出し、複数人のチームで専門性を持ち寄りながら判断するモデルへ。チームにジュニアが参加することで意思決定の OJT にもなる——教育とフロー効率の両立策として、今後試していきたい方法論です。 3. Agent Skills による組織のベストプラクティスの再現 「いい感じに」という抽象的な指示を具体的な手順に変換する Agent Skills は、単なるツールの設定ではありません。 チームのベストプラクティスを「AIという新しいメンバー」に伝える手段 として捉え直す必要があります。 実際に、株式会社タイミー では「 Agent Harness Group 」を立ち上げて AI との協業を組織的に推進していますし、株式会社LayerX では「 SubAgent 勉強会 」という知識共有の場を作っています。誰もが組織のベストプラクティスを簡単に再現できる仕組みを、社内でも作っていきたいと考えています。 おわりに AI にとってかわられる恐怖よりも、学ぶべきことの多さに恐怖している——というのは、裏返せば「学べば学ぶほど武器になる」ということでもあります。Tech Lead Conference 2026 で登壇者たちが口を揃えて言っていたのは、「 基礎知識を持つ人間がこれまで以上に価値を持つ 」ということでした。 特に4年目という、中途半端な立ち位置にいる自分にとって、和田卓人氏の「焦らずコツコツ自分の能力を上げていけば、それがそのまま競争力につながる時代になってきた」という言葉は、強い励みになりました。 焦らず、分からないところを放っておかず、基礎をコツコツ積み上げていく。その上で、AI を理解の加速器として使う。それがAI時代にエンジニアとして今後も活躍するための必要な考えかもしれません。 最後まで読んでいただきありがとうございました。

本ブログは 2026 年 5 月 19 日に公開された AWS Blog、” CIRT insights: How to help prevent unauthorized account removals from AWS Organizations ” を翻訳したものです。 AWS Customer Incident Response Team (CIRT) は、お客様がアクティブなセキュリティインシデントから復旧するためのご支援を行っています。この活動の中で、特定の お客様の構成や設計 を悪用する、新しいまたは流行している攻撃手口を発見することがしばしばあります。 これらの手口を理解することは、アーキテクチャ上の意思決定への反映、対応計画の改善、そして実際にこのような状況が発生した場合の検出に役立ちます。 本投稿では、攻撃者がお客様アカウントの制御を奪取した後に取る新しいアプローチを取り上げます。具体的には、お客様の AWS Organizations 実装から該当アカウントを離脱させ、その構造が提供するポリシーや保護を回避する手口です。 本記事で説明する手口は、AWS サービスの脆弱性を利用するものではありません。代わりに、特定の構成や設計によって生じた予期しない機会を悪用し、AWS アカウント内のリソースを不正に使用するものです。 何が起きているのか このアプローチは、攻撃者が organizations:LeaveOrganization 権限の付与を持つクレデンシャルを使用するところから始まります。この権限は LeaveOrganization API コール へのアクセスを提供し、メンバーアカウントから呼び出されると、そのアカウントを Organization から離脱させようとします。 重要な点として、このアプローチでは侵害されたルートクレデンシャルが使われる場合もありますが、攻撃者は他の手段でアクセス権を昇格させ、必要な権限を取得したり、その権限を持つロールを引き受ける能力を獲得したり、現在のクレデンシャルにこの権限を付与する能力を獲得したりすることもできます。これが、認可に対して 最小権限のアプローチ を取ることが、お客様の環境を保護する上で極めて重要である理由です。詳細については、 AWS Identity and Access Management (IAM) ドキュメント と、 組織単位 (OU) 設計および サービスコントロールポリシー (SCP) 実装に関する AWS Organizations のガイダンスをご覧ください。 お客様の環境への影響 アカウントが Organization から離脱させられると、その Organization の一部として継承されていた制限 (破壊的なアクションを防止していた SCP、利用可能な AWS リージョンを制限していたもの、特定の API コールをブロックしていたもの等) が適用されなくなります。また、当該アカウントは一括請求 (Consolidated Billing) の対象外となるため、Organization の請求アラートやコスト異常検知も該当アカウントの活動をカバーしなくなります。 AWS CloudTrail の組織トレイルは離脱したアカウントからのイベント取得を停止し、委任管理者を介して管理されていた Amazon GuardDuty の検出結果も中央のセキュリティアカウントへ流れなくなります。 その結果しばしば発生するのは、Organization が当該アカウントへの可視性を失う一方で、そのアカウント内には引き続き Organization のリソースが残るという状況です。関連する Threat Technique Catalog のエントリを以下に示します。 T1078.A002: Account Root User : 侵害されたルートクレデンシャルを利用した初期アクセス T1078.004: Cloud Accounts : 侵害された IAM クレデンシャルを利用した初期アクセス T1098: Account Manipulation : 制御を維持するための権限昇格とアカウント設定の変更 T1666.A002: Leave AWS Organization : SCP やガバナンスコントロールを回避するため、メンバーアカウントを Organization から離脱させる T1562.008: Disable Cloud Logs : Organization からの離脱後、中央集約型ロギングの可視性が失われる この手口の検知 アカウントが Organization からの離脱を試みると、CloudTrail には少なくとも 2 つの API コールが記録されます。 organizations:AcceptHandshake と organizations:LeaveOrganization です。中央集約型のロギングを構成している場合、これらのイベントが侵害アカウントから観測される最後のイベントとなる可能性があります。Organization からの離脱後、デフォルトではアカウント内のイベントは自身の CloudTrail ログに記録されることになります。アカウントが Organization に参加または離脱する際に関連する CloudTrail イベントを以下に示します。これらのイベントは、AWS Organizations を管理するためにチームが利用する承認済みの運用ワークフローの一部でない限り、調査が必要です。 CloudTrail イベント 意味 LeaveOrganization メンバーアカウントが Organization から離脱しようとしている AcceptHandshake アカウントが別の Organization への参加招待を承諾している InviteAccountToOrganization Organization がアカウントを招待している RemoveAccountFromOrganization 管理アカウントがメンバーアカウントを削除している (メンバー自らが離脱する場合とは異なる) この手口を防ぐための推奨ステップ organizations:LeaveOrganization アクションを拒否する SCP を実装してください。AWS Organizations は この制御の実装に関する詳細なガイダンス を提供しており、具体的な SCP ポリシー JSON や、本番環境および開発環境のアカウントには保護を維持しつつ正当なアカウント移行を許容できる OU 構造の設計に関するアドバイスが含まれています。 SCP は、メンバーアカウント内で IAM ポリシーが許可できる範囲を制限するガードレールとして機能します。AWS Organizations をご利用のすべてのお客様には、この SCP が現在配置されているかを確認し、配置されていない場合には実装に向けた手順を踏むことを強く推奨いたします。この SCP は迅速にデプロイでき、運用上の影響も最小限です。メンバーアカウントを Organization から分離することを慎重に管理・検討するためのプロセスを提供します。 このアクションは、ルートだけでなく organizations:LeaveOrganization 権限を持つあらゆる侵害された IAM プリンシパルから発生し得るため、IAM 権限の最小権限原則は重要な補完的な制御となります。ユーザーやロールがポリシーの追加・削除・変更を行ったり、別のロールを引き受けたり、自身の権限を変更したりできる範囲を制限することで、不正な権限変更が行われる経路を減らすことができます。IAM ポリシーを定期的にレビューし、過度に広範な権限 (特に iam:AttachRolePolicy 、 iam:AttachUserPolicy 、 iam:PutRolePolicy 、および広範な信頼ポリシーを伴う sts:AssumeRole ) を確認することは、侵害されたプリンシパルが実行できる範囲を制限するのに役立ちます。 ルートアカウントのセキュリティは引き続き重要です。ルートの侵害がこのパターンの一般的な侵入経路となるためです。すべてのルートユーザーに対して多要素認証 (MFA) を有効化し、ルートアクセスキーを削除し、メンバーアカウントからルートクレデンシャルを完全に取り除く ルートアクセスの一元管理 を採用することで、リスクの軽減につながります。 今後について 本手口は、私たちが様々なエンゲージメントを通じて目にしている、より広範なテーマを浮き彫りにしています。攻撃者は AWS のガバナンスコントロールがどのように機能するかをますます認識しており、Organization が提供する制御からアカウントを切り離すための意図的な手段を取っています。AWS CloudTrail を無効化する、Amazon GuardDuty ディテクターを削除する、Organization からアカウントを離脱させるといった行為は、いずれも同じ戦略の派生形にあたります。すなわち、本来であれば攻撃者の活動を制約し、お客様による対応を支援するはずのガードレールと可視性から、お客様のアカウントを切り離すというものです。 これを防ぐための制御は本日時点で利用可能であり、実装も簡単です。 AWS Organizations サービスチームのガイダンス から始め、 DenyLeaveOrganizationSCP を実装することをお勧めします。本手口に対して、最も効果が大きく、かつ最も労力の少ない制御です。それ以外にも、OU 構造全体での SCP のカバレッジを見直すこと、すべてのメンバーアカウントでルートクレデンシャルと IAM 権限が適切に保護されていることを確認すること、検知・対応プロセスが本手口を考慮に入れていることを確かめることが、より強固なセキュリティ態勢に貢献します。 Threat Technique Catalog for AWS には、根底にある手口の検知ガイダンスが含まれています。 関連リソース Threat Technique Catalog for AWS – Matrix T1078.A002: Account Root User T1078.004: Cloud Accounts T1098: Account Manipulation T1666.A002: Leave AWS Organization AWS Organizations における不正なアカウント離脱を防止するための重要なセキュリティコントロール メンバーアカウントのルートアクセスを一元管理する AWS Organizations サービスコントロールポリシー Amazon GuardDuty AWS CloudTrail ユーザーガイド 本投稿に関するフィードバックがありましたら、下のコメントセクションにご投稿ください。 著者について Shannon Brazil Shannon は AWS Customer Incident Response Team (CIRT) のセキュリティエンジニアであり、デジタルフォレンジックとクラウドセキュリティ調査を専門としています。コミュニティでは 4n6lady として知られ、セキュリティ教育と次世代の防御者の育成に情熱を注いでいます。 Derek Ramirez Derek は AWS Customer Incident Response Team (CIRT) のセキュリティエンジニアです。サイバーセキュリティと、困難なインシデントレスポンスの課題への対処を支援する AI ツールの構築という、自身が情熱を注ぐ 2 つのことを組み合わせて取り組んでいます。オースティンのダウンタウンを走ったり、ゴルフのショートゲームに取り組んだり、Dallas Cowboys を熱心に応援したりしています。 Richard Billington Richard は AWS Customer Incident Response Team (アクティブなセキュリティイベント中に AWS のお客様をサポートするチーム) のアジア太平洋地域における Sr. Security Engineer です。 翻訳は Security Solutions Architect の 松崎 博昭 が担当しました。