ども！ジムにClaudeを連れて行ってトレーナーをやらせている龍ちゃんです。といっても筋トレの話はできません。だって初心者だもの！マシンの名前も重さも回数も、ほとんど出てこないので安心してください。書きたいのは、Claudeをジムのトレーナーにしている、というちょっと変わった運用の話です。 きっかけは、Claude Code に リモート操作の機能 が入ったとき（2026年2月）に、プロダクトマネージャーの人が X で言っていたこれでした。 Take a walk, see the sun, walk your dog without losing your flow. 散歩して、日を浴びて、犬の散歩をしてこい。要は、繋がるようになったんだから席を離れていいぞという話です。言われたので行ってきました。ジムに。 生まれてからというものやせようと決心したことはないのですけど（口だけでは何度もありますけどね！）。 せっかくの機会なので、ジムを契約してClaude Codeとともに運動習慣作りを行っています。 ジムに着いて「今日何やる?」と投げるとこうなる ジムに着いたら、スマホでClaude Codeを開いて「今日何やる?」と投げます。返ってくるのがこれです。 今日は Day B 下半身。前回から中3日空いてる。 - トレッドミル 15分 - スクワット 50kg × 10 × 3セット（前回 50×10,10 で「ちょうど」だったので3セット目を追加） - アダクション 30kg × 12 × 2 - 締め: 股関節ストレッチ 4:37（動画リンク） 何をやるか、どのくらいの強さでやるかを決めているのは全部Claudeです。前回からの差分と、なんで3セット目が増えたのかまで付いてきます。しかも1種目ずつ小出しに降ってきます。全部まとめて渡されると、セット間の休憩で読み切れないんですよね。締めのストレッチはYouTubeの動画を尺つきで指定してきて、この日は 股関節まわりのストレッチ（自宅で5分） でした。 こっちがやるのは、1種目終わるごとに結果を報告するだけ。実際に投げている入力を、ある日のぶんそのまま並べます。 始めます。 3セット終わり ラストセットはきつめだったけど15回できた いや〜きつかった〜 けどまぁ3セット終わった 終わった〜 今回は繋がって一回で15回いけた 2セットとも繋がったよ ストレッチも終わり これで全部です。項目も単位もありません。「終わった〜」しか書いていない行もあります。息が上がった状態で片手にスマホを持って打つので、これ以上ちゃんと書くのは無理なんですよ。それでも通ります。 で、これ、 人間のトレーナーには言えないですよね 。目の前に立っている人に「いや〜きつかった〜」だけ言って次に進むのは、さすがに気まずいです。たぶん「あと2回いけますよ」とか言われます。言われたらやります。やりますけど、こっちはもう限界だと思っているわけです。というか怖くないですか？世の中のトレーナーの方々！ 相手がAIだと、その遠慮が丸ごと要りません。「終わった〜」だけ投げて次に進めるし、愚痴っても気を使わなくていい。抗ってみたら軽めのメニューに変えてくれるし、ジムで先にマシンが埋まっているとメニューの代替も送ってくれます。人と喋るのがそんなに得意じゃない側からすると、この気楽さはかなり効きます。 帰り際、これが1ファイルになって落ちてくる そして帰り際に、その日のぶんがまとまって出てきます。 # 2026-08-05（水）フル / Day C プル - 時間: 13:08 - 13:52（44分） - モード: リアルタイム（種目ごとに申告 → 次の指示） ## セット | 種目 | セット | 主観 | 設定値 | |---|---|---|---| | 膝立ちラットプルダウン | 40kg × 15 / 15 / 15 | ラストセット「ちょうど」 | プーリー最上段、ラットバー、膝立ち | | インバーテッドロウ | 自重 × 10 / 10 / 10 | 「限界」寄り | バー高さ = 胸のちょい上 | ## 気づき - 開始時刻を「会話が始まった時刻」で書いていた（後述） さっきの殴り書きが、この形になって落ちてきます。「プーリー最上段」とか「バー高さ = 胸のちょい上」みたいな設定値は、僕がその場で言った言葉が拾われて入っているだけです。表に整える作業を僕はしていません。 要するに、ごりっごりの管理ですね。メニューを組むのも、記録をつけるのも、重さを決めるのも向こう。こっちがやっているのはマシンの前でスマホに一言投げることだけ。「活用している」というより「管理を受けている」に近い温度で、この運用は回っています。 ちなみにマシンの名前もわかんなかったんで、ジムの初日は写真を撮って「何のマシンか？」・「これはどこを鍛えるものか？」みたいなのを書き起こしから始まりました。 コーチは自分で直せる。直した規約に自分が従う ここが個人的に一番おもしろいところなんですが、 このコーチの振る舞いは自分で書き換えられます 。だって CLAUDE.md に記載されているんだもの。それを読んだうえでコーチをやっているだけなので、気に入らない振る舞いがあったら書き足せば直ります。 たとえば僕のCLAUDE.mdには「怠惰だから毎日行けとこれだけは守らせろ」って記述が入っています。だからサボりたい日も、返ってくるのは「今日は休め」ではなく「軽め」とか「最低ラインでいい」というメニューです。行かない、という選択肢が出てきません。（それもこれもドア to ドア 45秒でジムがあるせいだ！） 実際に足したものを、いくつかそのまま抜き出します。 「今日は休め」ではなく「今日は最低ラインで」を返す 体重を聞くのは週の最初のセッションの1回だけ。聞かない日は話題にしない ストップウォッチを持たせない（記録の手間が増え、それ自体が枠を食う） 専門用語（RPE・1RM等）は使わない。必要なら日常語に置き換える 体重を毎回聞かせないのは、毎日聞かれても毎日乗るわけないからですね。毎日乗ろうなんて続くわけがありません。ただ、文章で今測ってくださいって言われるとなんだか乗れちゃうんですよね。時計を持たせないのも同じで、インターバルを測り始めたら記録が仕事になります。市販のトレーニングアプリでこのへんを変えるのは、まあ無理ですよね。作った人が決めた振る舞いが降ってくるので。 完全に自作自演が許されるわけです 。「毎日行け」と守らせているのは自分が書いた規約だし、「休め」と言わないコーチにしたのも自分。自分で書いた理想に自分が従わされて、しかもちゃんと効いている。とんだマッチポンプなんですけど、そこが面白いポイントだと思っています。 言わせたいことを言わせられて、こっちも言いたいことを言える。 どっちも相手がAIだから成立している部分ですね。 ただ、いいことばかりではないです。 チューニングが必須です。 全部、事故ってから足しています。 起きたこと そこから足した規約 午前に行ったのに夜だと思われて、最後に「おやすみなさい」と返された 開始時にその日の日時を確認する トレッドミルの時間がいつのまにか伸びていた 時間は据え置き。強くするのは別の軸でやる 下の行がとくにひどくて、ある日「最近ジムの時間長くなってね?」と自分で気づいて言うまで、変わっていることにすら気づいていませんでした。しかも調べたら犯人は数日前にコーチ自身が出した方針で、それが1回40分という枠と正面からぶつかっていたんです。自分で雇ったコーチに、自分の枠を壊されていたわけですね。 つまり、 寄せる作業はこっちの仕事 です。放っておいて理想のコーチになることはないし、こっちが違和感に気づかなければ、変な方針のままずっと走ります。（これは開発の現場でもあんまり変わんないですね）自分で書けるということは、自分で書かないと直らないということなんですよね。 AIの登場によって個人開発のアプリを作る順番が逆転した！ ここまでの話を並べてみると、けっこう妙なことになっています。フォームは作っていません。データベースも作っていません。入力はスマホに殴り書きを投げるだけ。それで記録が溜まって、コーチが自分好みに寄っていって、毎日ジムに行けています。 ここから先は個人開発の話に限ります。 自分が使うために自分で作るアプリ のことですね。仕事で人に使わせるものは、要件を先に決めないと成立しない場面が普通にあるので、そこは別の話です。 最近よく「AIが来たからアプリ開発が楽になる」という話を聞きます。個人開発に関しては実感が逆で、 作るハードルはむしろ上がった と思っています。作らなくても済む水準がここまで来てしまったので、「で、それをわざわざ作る理由は?」に答えないといけなくなった。 だとすると、作る順番が逆になるのかもしれません。要件を先に決めて作るんじゃなくて、 まずAIに運用させて、不満が出たところだけ作る 。しかもさっき見たとおり、不満の大半は規約に1行足せば消えます。消えないものだけが残る。 僕の場合、消えなかったものは1個だけでした。 「開始」です。 会話が始まった時刻を開始として記録していたんですが、ドア to ドア 45秒なので家にいるうちに会話が始まってしまう。実際のトレーニング開始と十数分ずれていて、過去のぶんも遡って直しました。これは書き方の問題ではなくて、 僕が言わなかった事実は取れない という話です。「きつかった」は言葉になるけど、「いま始めた」は言わなければ存在しない。だから作るとしても、重さや回数を打ち込むフォームではなくて、 始めたことを伝えるボタン1個 になる気がしています。 この「まず手で回して、何を作るべきかを学ぶ」やり方、実は昔から名前がついていて、 コンシェルジュMVP と呼ばれるそうです。裏で人間が動いているのを隠す Wizard of Oz と違って、手でやっているのを隠さないほうがこれです。ただ定石だと 人手だから捨てる前提 なんですよね。今回それが崩れているのが面白いところで、 コンシェルジュをやっているのがAIなので捨てなくていい 。要件が集まったら畳む仮の仕組みではなく、そのまま本番として回り続けます。 そしてこの形で回せているのは、条件が2つハマっているからだと思っています。 記録がリポジトリに落ちること。 Claude Code に繋いでいるので、書き出し先がそのままGit管理下のファイルです。生データがテキストで残るし、履歴も差分も残るので、さっきの「開始時刻を遡って直した」みたいな訂正も、いつ何を直したかが残ります。データベースに入れていたら、たぶんここまで気楽に直せていません。 もうひとつは お金が増えないこと 。DBも立てていないし、サーバーも借りていません。AIの利用料はもともと払っているサブスクの中なので、この運用のために増えた固定費はゼロです。個人の趣味みたいなものに月額が増えると、それだけで畳む理由になりますよね。 このデータで何ができるか考えると楽しい そして、テキストで溜まっているので、そこから先はなんでもできます。 自分用のダッシュボードを作ってもいいし、そもそもこのデータ自体がネタになります。実際、こんな仮説が出てきました。締めのストレッチには飛ばす日と飛ばさない日があるんですが、 分かれ目は意志ではなく動画の尺なんじゃないか という話です。 動画の尺 やったか 4:37 6:58 7:32 7:32 正直、記録がまだこれだけしかないので決まりとは言えません。7分と7分半のあいだに本当に線があるのかも分かっていません。ただ、先に立てた別の仮説は潰れています。「動画を選ぶのが面倒だからでは」「終わりの宣言との前後関係では」のどっちも外れて、残っているのが尺なんですよね。なので今は尺の仮説を採って、動画のカタログを短いものだけに絞り替えました。外れていたら、また記録の方から分かるはずです。 根性の問題だと思っていたものが、実は尺の問題かもしれない。こういうのは記録が溜まっていないと仮説にすらならないですし、こうやって記事のネタにもなります。こんなデータから自分の傾向がわかったりしたら面白いですよね。 この順番なら、 作る前に何が要るか分かっている状態から開発を始められる 。自分用のツールを想像で設計して、作って、使わなくなる。このやつを何回かやってきたので、それが避けられるだけでも十分嬉しいんですよね。個人開発はこういう始め方が普通になっていくのかもしれません。 とはいえ、結局続けるかどうかは自分次第です。規約を書き足すのも自分だし、ジムに行くのも自分。せっかくなら、一人でジムに行くあの絶妙な孤独感をAIで紛らわせて、行ってみるのはどうでしょう。 ではまた！ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 1人がこの投稿は役に立ったと言っています。 The post Claude Codeをジムに連れ出したらトレーナーになっていた first appeared on SIOS Tech Lab .

はじめに # 私が4年間取り組んできた ETロボコンの活動の軌跡 を紹介します。 昨年度はベーシッククラス（当時の名称：プライマリークラス）に挑戦し、AI活用を取り入れた新しい開発スタイルにも踏み込みました。 これまでの経験がどのように積み重なり、昨年度の成果につながったのかをまとめています。 最後までお付き合いいただければ幸いです。 4年間の活動をひとことで紹介すると # 「設計（UML）→ 実装 → 実機制御 → チーム運営 → AI活用」 と、毎年新しい挑戦を積み重ねてきました。 1年目 ：エントリークラスで基礎を学ぶ 2年目 ：モデル評価がB→Aへ成長 3年目 ：後輩サポートで理解が深化 4年目 ：ベーシッククラス挑戦＋AI活用という新フェーズへ ETロボコン 4年間の歩み この4年間で、技術面もチーム面も大きく成長できたと感じています。 1. 参加のきっかけ：ロボットが動く"あの瞬間"をもう一度 # 私がETロボコンに参加し始めた理由は、高専時代のロボコン経験にあります。 試行錯誤して作ったロボットが初めて思い通りに動いた瞬間の高揚感。 「技術で仲間と何かを成し遂げる楽しさ」を、社会人になっても味わいたいと思い、参加しました。 2. ETロボコンとは：ソフトウェア重視の"教育型ロボコン" # ETロボコンは、 組込みソフトウェア技術の教育を目的としたロボットコンテスト です。 一般的なロボコンがハードウェアの工夫や機構設計を競うのに対し、ETロボコンは 「ソフトウェア設計（UML）と走行結果の両方を評価する」 という点が大きな特徴です。 詳しくはETロボコン公式サイトをご覧ください。 https://www.etrobo.jp/ --> Information ETロボコンは2002年から開催されており、2026年で25年目を迎える長寿コンテストです。組込み技術者育成への貢献が評価され、 経済産業大臣賞を受賞 した実績もあります。 ETロボコンの目的 # 組込みソフトウェア技術者の育成 分析・設計・制御モデリングを含む PBL（Project-Based Learning） の実践 初心者からベテランまでが学び合える教育の場の提供 全国規模の大会構成 # ETロボコンは全国12地区で地区大会が開催され、 上位チームは全国大会（チャンピオンシップ大会）へ進出します。 レベルに合わせて選べる3つのクラス # エントリークラス（シミュレータ部門） 初心者向け。シミュレーターで参加でき、設計と実装のつながりを学べる。 ベーシッククラス（フィジカル部門） 旧プライマリークラス 初級〜中級者向け。モデル表現力やチーム開発を学ぶ。 アプライドクラス（フィジカル部門） 旧アドバンスドクラス 実務経験者・上級者向け。制御技術やAIなど高度な要素を取り入れ、システム全体を可視化しながら開発を学ぶ。 ソフトウェアで勝負するロボコン # ハードウェアは共通の市販キットを使用し、 「設計（モデルシート）＋走行結果」 の総合成績で評価されます。 モデルシートの信頼性・一貫性・表現力が重要で、 走行タイムや難所クリアによるボーナスタイムと合わせて順位が決まります。 技術教育イベントが充実 # 技術教育（オンライン／オフライン） モデリングワークショップ 試走会 地区大会での交流会 チャンピオンシップ大会での成果発表 企業・学生・教育者が同じテーマで議論できる貴重な場となっています。 参加者数と実績 # 全国12地区で大会を開催 累計 4,095チーム / 22,700名が参加 （公式発表） 教育効果の高さから、企業研修や大学の授業にも広く活用されています。 大会との関わり # 豆蔵は大会に参加するだけでなく、地区ゴールドスポンサーとして大会を支援しており、 技術教育への取り組みを企業として積極的に行っています。 3. これまでの参加年ごとの振り返り # 1年目：エントリークラス挑戦（＋アドバンスドクラスサポート） # 初参加で手探り状態ながら、モデル作成と走行調整に取り組みました。 アドバンスドクラスのサポートも経験し、上位クラスのレベルの高さを実感しました。 2年目：モデル評価がB → Aへ成長 # モデリングに重点を置いて取り組んだ結果、評価がBからAへ向上。 設計の重要性を強く感じた年でした。 3年目：後輩サポートで理解がさらに深まる # 自分がA評価を受けたモデルをベースに、後輩へ「どうすればモデルが良くなるか」を伝える立場に。 教えることで自分の理解も深まり、チーム全体の底上げにつながりました。 4. 昨年度（4年目）の取り組み：ベーシッククラス挑戦と"AI活用"という新しい武器 # 昨年度は大きな転換点でした。 エントリークラスから一歩進み、 ベーシッククラスに挑戦 。 さらに今年度は、 AIを積極的に活用した開発スタイル にも踏み込みました。 モデルのレベルアップ # 複雑な制御に対応するため、状態遷移やクラス構造の精度を高め、設計段階での思考が大幅に深化しました。 AIを活用したモデルのブラッシュアップ # AIを"設計レビューの相棒"として活用し、 モデル改善案の生成 抜け漏れチェック UML表現の最適化 など、設計品質の向上に役立てました。 実機を使ったロボット制御の習得 # センサー値の取得、PID制御、ライン追従など、実機ならではの学びが多く、組込み制御の理解が深まりました。 AIを用いたコーディング # コード生成やリファクタリングの提案など、AIを活用した開発スタイルにも挑戦しました。 結果 # モデルは シルバーモデル(2位) を獲得。 走行は課題が残ったものの、技術的な挑戦の幅は過去最大で、次年度につながる大きな経験となりました。 5. 今後の展望：UML × 実機 × 制御 × AI の4本柱をさらに深化 # 今年度は昨年度の経験を踏まえ、 UMLによる設計力、実機制御、制御技術、そしてAI活用 という4本柱をさらに強化していく予定です。 その取り組みの一環として、さらなるモデル作成のレベルアップを目標に アプライドクラスへ挑戦 しています。 昨年度は走行に課題が残りましたが、今年度はコース環境を整備し、 制御技術の底上げにも本格的に取り組んでいます。 AI活用については、 モデル改善 コード生成 設計レビュー など、開発プロセス全体を支える重要な技術として位置づけています。 最後に # ETロボコンは、モデリング、コーディング、実機調整、AI活用など、幅広い技術を実践的に学べる場です。 ロボットが動く瞬間のワクワクと、技術が積み重なっていく手応えを、これからも大切にしていきたいと思います。

2026 年 6 月 25 日、26 日に AWS Summit Japan が開催され、多数のセッションとブース展示が行われました。AWS セッションや AWS Village のブース展示においては、レジリエンスに関するトピックを多数お届けしていました。本ブログでは、AWS Summit Japan 2026 よりレジリエンスに関するセッション、ブースの内容をサマリーでご紹介します。 AWS セッションより 大規模障害から考える、AWS 上で備えるべきレジリエンスの実践 AWS エンタープライズサポート シニアテクニカルアカウントマネージャー 猪又 赳彦より、実際の障害発生時に AWS が何をしているのかを解説するセッションをお届けしました。AWS の障害対応は「検出と軽減策の実施」「振り返り」「学習とスケーリング」の 3 フェーズで進められ、振り返りでは COE（Correction of Error）の中核として Five Whys による根本原因分析が行われることを紹介。「5 回で止める」「直線的な分析に限定する」といった典型的な誤解に触れつつ、1 つの事象から複数の根本原因へ問いを分岐させていく実例が解説されました。 また、障害から生まれた「Availability Axioms（可用性の基本原則）」として、リージョンの分離（AWS STS のリージョナル化の歴史）、AZ 障害への自動対応（Fleet Health Service や Zonal Event Detector による検知と Amazon Application Recovery Controller の Zonal Shift / Autoshift）、厳密なテスト（専用のテストリージョンでのゲームデー）、過負荷からの保護（Metastable Failure という準安定障害の概念）という 4 つの原則が紹介されました。事例では、2025 年 10 月 20 日の US East 1（バージニア北部）リージョンでの Amazon DynamoDB DNS 障害を踏まえ、Fidelity Investments 社が日常的なレジリエンステストにより、当日 2,000 個のアプリケーションのフェイルオーバーを検知から 9 分で完了させた実践が紹介されました。 Operation Phase of AI-DLC － AI 駆動カオスエンジニアリングのすすめ－ AWS Developer スペシャリストソリューションアーキテクト 金森 政雄より、AI-Driven Development Lifecycle（AI-DLC）の Operation フェーズに焦点を当てたセッションをお届けしました。AI-DLC のホワイトペーパーでは、AI がテレメトリを能動的に分析して問題を予測し、ランブックと連携して推奨アクションを提案・実行し、開発者が検証・承認するというサイクルが定義されていますが、実運用に導入するには「既存の運用に乗せる」→「AI で改善する」→「AI を活用した運用（AIOps）へ」という段階的なアプローチが有効であると解説されました。具体例として、アーキテクチャ図上でリスクを可視化する「リスクストーミング」と、カオスエンジニアリングを組み合わせ、AI-DLC で開発されたデモアプリ「Unicorn Market」を用いて、リスク抽出から障害注入実験までを AI が加速するデモが実演されました。 AWS DevOps Agent による自律的インシデント対応 －その能力を引き出す設計のベストプラクティス－ AWS シニアスペシャリストソリューションアーキテクト 加藤 正樹より、障害対応と運用改善に特化した AI エージェント「AWS DevOps Agent」の能力を引き出す設計を解説するセッションをお届けしました。障害対応における AI 活用の課題として、暴走と停止の制御、多様なデータソースの横断、チーム全員でのコンテキスト維持の 3 点を整理し、「調査は AI、判断は人」という設計思想のもと、複数オブザーバビリティツールを横断したテレメトリ調査やコードリポジトリと連携した変更特定、Skills によるナレッジ共有といった機能が紹介されました。デモでは CloudWatch Alarm をトリガーに自律的に調査を開始し、複数テレメトリを相関づけて根本原因に到達、緩和計画を Kiro 等のコーディングエージェントに引き渡すまでの一連の流れが実演されています。 能力を引き出すベストプラクティスとして、調査スコープを定義する Agent Space の設計原則、Insights ファミリーや OpenTelemetry によるテレメトリの充実、Skills と Agent Instructions によるナレッジ共有の 3 点が解説されました。ナレッジ整備前後では根本原因到達時間が 6 分 32 秒から 3 分 38 秒へ短縮された結果も共有されています。事例として KDDI 様では調査リードタイムが数週間から数日へ短縮され、CyberAgent 様では MCP サーバーを活用して本番データベースを安全に調査する独自拡張を構築した事例が紹介されました。 ランサムウェアに対して最優先で取るべき AWS の復旧対策 ソリューションアーキテクト 向井 稔より、ランサムウェア被害からの「復旧」にフォーカスし、状況に応じた 3 段階の対策を解説するセッションをお届けしました。IPA「情報セキュリティ 10 大脅威 2026」でランサム攻撃が 11 年連続 1 位となる中、防御・検知・対応だけでなく、暗号化されたデータを確実に復元し業務を再開する「復旧」フェーズの重要性を強調しました。 まず「すぐに始められる対策」として、Write Once Read Many（WORM）によるイミュータブルなデータ保護を紹介しました。AWS では Amazon S3 Object Lock、Amazon EBS Snapshot Lock、Amazon FSx for NetApp ONTAP SnapLock、AWS Backup Vault Lock の 4 つのサービスで WORM を実現でき、いずれも追加料金なしで利用可能です。Compliance モードを選択すれば、保持期間中は管理者であってもデータを削除できない強固な保護が適用されます。 次に「包括的な対策」として、AWS アカウント自体が侵害されるリスクに備え 3-2-1-1-0 ルールに基づく戦略を解説しました。具体的には、AWS Backup の論理エアギャップボールト（Logically Air-gapped Vault）により AWS 管理の専用アカウント内にバックアップを隔離し、デフォルトで Vault Lock による WORM 保護を適用する構成を紹介しました。さらに Amazon GuardDuty Malware Protection for AWS Backup によりバックアップのマルウェアスキャンを復旧前に実施できること、自動復元テストにより復旧プロセスの正常性を継続的に確認できることを説明しました。最後に「オンプレミス環境の対策」として、バックアップソフトウェアと S3 Object Lock を連携させ、オンプレミスのデータを AWS に WORM 保護付きでバックアップし、DR 対策とランサムウェア対策を同時に実現する構成を紹介しました。 AWS ブース展示より レジリエンス強化と障害対応につかえる AI 体験 本ブースでは「EC サイトが障害で停止し、復旧まで 1 時間を要した」というシナリオを起点に、レジリエンスライフサイクルの各ステップを AI で加速する 4 つのデモを体験いただきました。 起点となる AWS DevOps Agent のデモでは、DB 接続プール枯渇と Redis キャッシュ障害が同時発生する複合障害に対し、CloudWatch Alarm をトリガーに AI が自律的に調査を開始。約 10 分で 2 件の根本原因を特定し、緩和計画まで日本語でレポートする一連の流れをお見せしました（運用・対応と学習）。続いて BIA（Business Impact Analysis）のデモでは、Kiro 上で動く AI ファシリテーターが対話形式でビジネスインパクトの分析を支援。ダウンタイムコストと最大許容ダウンタイムを算出し、DR の目標値を導き出す過程をご紹介しました（目標を設定）。 3 つ目の次世代 AWS Resilience Hub × Kiro のデモでは、GenAI による障害モードアセスメントが現行アーキテクチャの課題を評価し、その結果を Kiro に渡すとマルチリージョン化の提案レポートから CloudFormation テンプレートの改修まで AI が一気通貫で生成。評価・計画・実装を AI が担い、人間は判断とデプロイ承認に集中できるワークフローを提案しました（設計と実装）。最後の Chaos Agent（Kiro × AWS FIS）のデモでは、再設計後の環境に対し AI がカオステストのシナリオ生成から障害注入、RTO/RPO の合否判定までを自律実行。実測 RTO 約 99 秒で目標を大幅にクリアする結果を示し、設計後も AI が継続的に検証する重要性をお伝えしました（評価とテスト）。 4 つのデモは「運用・対応と学習 → 目標を設定 → 設計と実装 → 評価とテスト」というライフサイクルを一気通貫で体験できる構成とし、ご来場いただいた方のご興味のポイントに合わせてご説明させていただきました。 大阪リージョンを使用したマルチリージョン構成のデモ（たこ焼き AI 大将） 大阪リージョンをメインとしたディザスタリカバリ（DR）構成を、たこ焼き注文アプリ「たこ焼き AI 大将」として体験できるデモをご案内しました。レジリエンス／DR は重要でありながら難解と捉えられやすいテーマなので、技術的な堅牢性を保ちつつ誰もが直感的に楽しめる構成を目指してデモを設計・実装しました。注文操作に連動して、たこ焼きを焼く・盛り付けるロボットアームを配置し、来場者の関心を自然に技術デモへ引き込む導線を目指しました。 ブースではリージョン障害を疑似的に発生させても注文を継続できる様子を実演し、Amazon Aurora DSQL のマルチリージョン アクティブ‐アクティブクラスターによる高可用性、Amazon Bedrock のクロスリージョン推論、Amazon CloudWatch Application Signals による SLO モニタリングを組み合わせた構成を紹介しました。障害対応には Amazon CloudFront のオリジンフェイルオーバーと Amazon Application Recovery Controller の Region Switch を採用し、AWS Fault Injection Service で Lambda レイテンシーや DSQL 接続障害時の動作を検証するアーキテクチャを体感いただきました。 AWS レジリエンス体験ゲーム 〜 選ぶだけで学べる、障害対応の意思決定 手を動かしながらレジリエンスを学べるよう、ブースにクイズ形式のゲームを用意しました。AWS のレジリエンス設計を体験できる展示です。来場者は架空のグローバル企業で「最高レジリエンス責任者（Chief Resilience Officer）」となり、次々と発生する障害シナリオに対して復旧の選択肢を選んでいきます。専門知識がなくても選択肢を選ぶだけで進められるので、クラウド初心者からアーキテクトまで、立ち止まって手を動かしていただけました。 用意したのは、業種の異なる 4 つのシナリオです。 FinancePay（決済 / マルチリージョン災害復旧） — リージョン障害に直面し、RTO / RPO を意識しながら、バックアップ＆リストア、パイロットライト、ウォームスタンバイ、マルチサイトアクティブ/アクティブという 4 つの DR 戦略を選択。Amazon Application Recovery Controller（ARC）のルーティングコントロールによるリージョン間のトラフィック切り替えも体験します。 StreamMax（動画配信 / 高可用性とゾーン分離） — ライブ配信中のアベイラビリティゾーン（AZ）障害に対応。マルチ AZ 配置と、ARC の Zonal Shift・Zonal Autoshift による健全な AZ へのトラフィック退避を通じて、障害の影響を AZ 単位に封じ込める考え方を学びます。 ShopFast（EC / セルベースアーキテクチャ） — フラッシュセール中のカスケード障害が題材。セルベースアーキテクチャとシャッフルシャーディング、バルクヘッドパターンで爆発半径（Blast Radius）を最小化し、一部が壊れてもサービス全体を止めないグレースフルデグラデーションを体感します。 DoWellAI（生成 AI / AI ワークロードのレジリエンス） — 生成 AI アプリの安定運用がテーマ。Amazon Bedrock Guardrails による入出力フィルタリング、クロスリージョン推論、プロンプトキャッシング、共有障害の防止といった、生成 AI 時代のレジリエンスパターンを扱います。 「アベイラビリティゾーンとは何か」といった基礎から、セルベースアーキテクチャや生成 AI ワークロードの可用性設計まで、体験しながら段階的に学べる展示を行いました。 進化する金融 × レジリエンス 〜 金融システムを支えるセキュリティ＆レジリエンス 金融ブースでは、ミッションクリティカルなワークロードのレジリエンス強化とサイバーセキュリティ対策について、具体的な実装をデモでご紹介しました。取り上げたのは、次のようなユースケースです。 リアルタイムカード決済のマルチリージョン構成 — 東京・大阪の両拠点で止まらない決済基盤をライブ実演。カードをかざした瞬間から処理完了までの流れを体感いただけます。 認証情報侵害の検知と AI による自律調査 — 多段階攻撃の個別アラートを AI が「攻撃チェーン」として自動判定し、調査レポートまで生成。検知から調査完了までを一気通貫でお見せしました。 AWS Security Agent による設計書レビュー — 設計書を読み込ませ、コンプライアンス確認作業を効率化する取り組みをご紹介しました。 AI との対話によるランサムウェア対策アーキテクチャ提案 — ランサムウェア対策を生成 AI が活用できる Agent Skill として体系化。金融グレードの AWS 推奨構成を対話で具体化し、設計提案・現状評価・改善ロードマップをレポート出力します。 障害訓練シナリオの AI 自動生成 — 構成情報を入力するだけで障害訓練のシナリオと実施計画を AI が自動生成し、訓練準備の負担を大幅に削減します。 止まらない決済基盤から、AI を活用した脅威検知・設計レビュー・障害訓練まで。守りを固めるだけでなく、生成 AI で運用そのものを進化させていく。そんな金融システムのこれからを、実装を通して感じていただける展示となりました。 人間 vs AI 障害対応バトル – Chaos Kitty Challenge AWS のアーキテクチャを物理的に表現し、インシデント対応を体験学習できる Chaos Kitty。4 回目の登場となる今年は、新たに「対戦モード」を追加して AWS Builders’ Fair に展示しました。同じ障害が発生した 2 つの環境で参加者と AI エージェントが同時に対応を開始し、どちらが早く正確に Web 3 層アプリケーションの障害を解決できるかを競います。 AI エージェントには AWS DevOps Agent を採用。メトリクス・ログ・トレースやデプロイ履歴を横断分析して根本原因を特定していく調査プロセスが対戦画面上にリアルタイムで可視化され、AI 時代のインシデント対応の未来を体感できる展示となりました。 Chaos Kitty は AWS Samples として公開しており、ご自身の AWS 環境にデプロイしてお試しいただけます。詳しくは紹介ブログ記事もあわせてご覧ください。 AWS Summit Japan 2026 に Chaos Kitty が対戦モードを引っさげて 4 回目の登場！   大阪リージョンデータセンター 最新の災害対策 大阪リージョンデータセンターブースでは、AWS インフラストラクチャの耐災害性を直感的に体験いただける展示を行いました。今回のサミットでは、大阪リージョンで採用されている日鉄エンジニアリングの免震装置「NS-SSB（球面滑り構造）」を模型と VR 体験装置でご紹介。VR を通じて免震構造の効果を体感いただくことで、大阪リージョンのインフラストラクチャが持つ高い耐災害性をより実感いただける内容としました。特に DR 戦略として大阪リージョンの利用を検討されているお客様から高い関心をいただきました。 まとめ 障害へのアプローチとしては、障害が起こる事を前提とし、素早く復旧する事（レジリエンス、回復力）が重要です。今回の AWS Summit では、このプラクティスを AI エージェントによって加速するという新しい潮流が多く確認できる内容となっておりました。特に、Business Impact Analysis から Resilience Hub によるアーキテクチャ評価、Fault Injection Service を用いたカオステスト、そして障害発生時の DevOps Agent による一次対応まで、レジリエンスライフサイクルの各フェーズに AI を組み込む具体的な実装例が確認できる内容になっておりました。加えて、ランサムウェアからの復旧対策や大阪リージョンを活用したマルチリージョン構成など、ミッションクリティカルなワークロードを守るための実践的な選択肢も幅広くご紹介しました。これからミッションクリティカルなシステムや高い可用性要件が求められるシステムのクラウド活用を検討頂いている皆様に少しでも参考になれば幸いです。 現在は、セッションの動画や資料を以下で公開中です。ぜひあわせてご覧ください。 – 動画（視聴には登録が必要です）： https://aws.amazon.com/jp/events/summits/japan/ – セッション資料： https://pages.awscloud.com/AWS-Summit-Japan-2026-Session-Materials-Download.html – ブース展示資料： https://pages.awscloud.com/AWS-Summit-Japan-2026-AWS-Expo.html 著者について 猪又 赳彦 技術支援本部 エンタープライズサポート シニアテクニカルアカウントマネージャー 鈴木 真史 技術統括本部 交通・物流ソリューション部 シニアソリューションアーキテクト 三好 史隆 技術統括本部 自動車・製造 ソリューションアーキテクト 安藤 麻衣 技術統括本部 通信・メディア技術本部 通信第二ソリューション部 ソリューションアーキテクト