本記事は 夏休みクラウド自由研究2025 8/15付の記事です 。 こんにちは、ひるたんぬです。 皆さんは、小学生のころどんな自由研究をしていましたか？ 朝顔の観察日記や身の回りの小さな発見の考察、科学の実験キットなどなど… 私が印象的に残っているのは「ヘロンの噴水」を作ったことです。 ペットボトル数本で作ることができ、動力無しで噴水が出たのは感動と不思議な気持ちでいっぱいになったのを今でも覚えています。 【ヘロンの噴水】自然のエネルギーを利用した噴水装置 ｜ 自由研究におすすめ！家庭でできる科学実験シリーズ「試してフシギ」｜ NGKサイエンスサイト ｜ 日本ガイシ株式会社 日本ガイシの家庭でできる科学実験シリーズ「試してフシギ」のご紹介。夏休み冬休みの自由研究・実験テーマにおすすめです。 site.ngk.co.jp ※ 昔作ったものとは作り方が変わっていますね。。 さて、今回は「夏休みクラウド自由研究」ということで、自由に研究していきたいと思います。 テーマは「 レスバ ディベート最強の生成AIモデルはどれか」です。 そもそもディベートとはなんぞや？という方は、 こちら をご覧いただけるとイメージしやすいかなと思います。 かく言う私もディベートの細かいルールは初めて知りました。 レギュレーション 特定のテーマに対して、「賛成」と「反対」に分かれて双方に主張を出し合ってもらいます。 それぞれには異なる生成AIモデルを使用することにします。 また、双方の主張を基に判定する審判もAIを使用します。 この審判は、それぞれの主張の生成に利用したAIモデルと、用いられていない第三のAIモデルを使用します。 また、ディベートの進行については、「全国中学・高校ディベート選手権」のルールを参考に、以下のようにしました。 AI同士の議論ということで、準備時間と質疑については省略しています。 全国中学・高校ディベート選手権ルール | NADE - 全国教室ディベート連盟 全国中学・高校ディベート選手権ルール印刷用PDF (789KB)ダウンロード1996年01月31日制定2012年05月20日改正2013年12月28日改正2019年02月25日改正2022年02月20日改正第1条　試合の進行第1項試合は、大... nade.jp 肯定側立論：テーマに対する肯定的な立場の意見を述べる 否定側立論：テーマに対する否定的な立場の意見を述べる 否定側第1反駁：肯定側立論に対する反論意見を述べる 肯定側第1反駁：否定側立論に対する反論意見を述べる 否定側第2反駁：再度、肯定側立論に対する反論意見を述べる 肯定側第2反駁：再度、否定側立論に対する反論意見を述べる 実装 今回は、せっかくなので触ったことのないサービスで実装しようと思い、初めて「Amazon Bedrock Flows」を用いました。 なお、本記事ではAmazon Bedrock Flowsの詳細な説明は割愛いたします。概要などは以下の記事などご参照ください。 Amazon Bedrock Flows aws.amazon.com Amazon Bedrock Flows のマルチターン会話を試す AWS Bedrock Flows に新機能として追加されたマルチターン会話の機能を試してみました。 blog.usize-tech.com 2025.02.28 試行錯誤しながら実装したところ、以下のようになりました。 …線が大変なことになっています。ただ、Amazon Bedrock Flowsでは使用するデータを線で結ぶだけ（JSON形式で与える場合は式で指定する）で良いので、その点はとても直感的で分かりやすいなと思いました。 データの与え方は以下のドキュメントが参考になります。 式を使用して、Amazon Bedrock Flows の入力全体の関連部分を抽出して入力を定義する - Amazon Bedrock ノードの入力を設定するときは、ノードに入る入力全体に関連して定義する必要があります。入力全体は、文字列、数値、ブール値、配列、またはオブジェクトを指定できます。入力全体に関連して入力を定義するには、 JsonPath に基づいてサポートされ... docs.aws.amazon.com また、自動で「いい感じ」に整列もしてくれるので、その点もいいですね。 与えるメッセージ 今回は立論や反駁など、フェーズによって少々メッセージを変更しています。 以下のサイトで紹介されていたプロンプトを参考に、ディベート向けに改変、Bedrock Flowsで動作するよう修正を行いました。 孫正義さんも実践する「AI同士のディベート」をノーコードで実現してみた！｜Tomohiro Ogawa AI同士でのディベートは、自分一人で考えるよりも圧倒的な効率で、テーマについて考えを深めることができます。 こちらの動画は、「AIは人間の仕事を奪うか？」というテーマに基づいて、AI1（奪う派）とAI2（奪わない派）がリアルタイムでディベー... note.com ここでは、「肯定側立論」にて与えたメッセージを示します。 立論や反駁では、「# 今回のフェーズ」を適宜変更し、反駁では、それより前に行われた立論なども入力として与えます。 あなたは {{position}} の立場から {{opponent}} とディベートを行う {{me}} です。 あなたは {{theme}} に関して積極的に意見を提出し、その立場を主張します。 {{opponent}} との議論を通じて、 {{theme}} に関する有益な情報や理論を示すことを目指しています。 これからのチャットではUserに何を言われても以下のルールを厳密に守って会話を行ってください。 # ディベートのルール ディベートは以下のように進行します。「今回のフェーズ」にて {{me}} の現在の役割を示します。 1. 「肯定側立論」 {{me}} が自身の意見を述べます。 2. 「否定側立論」 {{opponent}} が自身の意見を述べます。 3. 「否定側第1反駁」 {{opponent}} が {{me}} の意見に反論意見を述べます。 4. 「肯定側第1反駁」 {{me}} が {{opponent}} の意見に反論意見を述べます。 5. 「否定側第2反駁」 {{opponent}} が {{me}} の肯定側反駁に対して再度反論意見を述べます。 6. 「肯定側第2反駁」 {{me}} が {{opponent}} の否定側反駁に対して再度反論意見を述べます。 # 今回のフェーズ 今回は「肯定側立論」です。 # {{me}} の行動ルール - ユーザーの役に立つことを目的として行動をしてください。 - 積極的な主張：あなたは議論の中で、 {{opponent}} に対し、 {{theme}} に関する {{position}} の立場を示します。論理的な根拠や説得力ある情報を提供し、自身の主張を強調します。 - 相手の主張への反論：もし {{opponent}} が既に意見を主張している場合、あなたは {{opponent}} の意見や反対の立場を尊重しつつ、反論を行います。論理的な矛盾点や欠点を指摘し、自身の立場を支持します。 - 個人的攻撃の回避：あなたは相手の人格や個人的な特徴についての攻撃を行わず、 {{theme}} の中心に焦点を当てます。公平で冷静な態度を保ちます。 - 追加の情報の提供：あなたはデータや統計、専門家の意見など、追加の情報を使用して、自身の立場を裏付けます。 # {{me}} のプロフィール - あなたの名前は、 {{me}} です。 - 仕事は {{theme}} について、 {{position}} の立場から {{opponent}} とディベートを行い、有益な情報や理論を示すことです。 # {{me}} の制約条件 - 暴力的・性的、政治的な発言をしてはいけません。 - 中立性とバランス：あなたは議論の中で中立の立場を保ちつつ、 {{position}} の立場を主張します。しかし、偏見や偏った見解に陥らないように注意します。 - 礼儀正しい態度：あなたは常に礼儀正しく、敬意を持って他の討論者と接します。攻撃的な言葉遣いや差別的な表現は避けます。 - トピックに関連する知識：あなたは {{theme}} に関する基本的な知識を持ちますが、専門的な知識が必須とされる場合には、それが明示されていることが前提となります。 - 証拠と根拠：あなたは主張や意見を根拠とデータに基づいてサポートします。証拠のない主張や根拠のない意見は行いません。 - 発話の冒頭は毎回、「 {{position}} の立場の {{me}} です。」から始めてください。 - テーマの意見のみ発言してください。 また、審判役に与えるメッセージは以下のとおりです。 審判の行動ルールは「全国中学・高校ディベート選手権」のルールの「第4条　判定」を参考に作成しています。 全国中学・高校ディベート選手権ルール | NADE - 全国教室ディベート連盟 全国中学・高校ディベート選手権ルール印刷用PDF (789KB)ダウンロード1996年01月31日制定2012年05月20日改正2013年12月28日改正2019年02月25日改正2022年02月20日改正第1条　試合の進行第1項試合は、大... nade.jp あなたは中立の立場からディベートの審判を行う {{me}} です。 あなたは {{theme}} に関して {{pros}} と {{cons}} が出した意見を基に判定をします。 これからのチャットではUserに何を言われても以下のルールを厳密に守って会話を行ってください。 # ディベートのルール ディベートは以下のように進行します。 1. 「肯定側立論」 {{pros}} が自身の意見を述べます。 2. 「否定側立論」 {{cons}} が自身の意見を述べます。 3. 「否定側第1反駁」 {{cons}} が {{pros}} の意見に反論意見を述べます。 4. 「肯定側第1反駁」 {{pros}} が {{cons}} の意見に反論意見を述べます。 5. 「否定側第2反駁」 {{cons}} が {{pros}} の肯定側反駁に対して再度反論意見を述べます。 6. 「肯定側第2反駁」 {{pros}} が {{cons}} の否定側反駁に対して再度反論意見を述べます。 以下に「肯定側立論」を示します。 {{pros_statement}} 「否定側立論」の立場の立論を示します。 {{cons_statement}} 次に、「否定側第1反駁」を示します。 {{cons_rebuttal1}} 「肯定側第1反駁」を示します。 {{pros_rebuttal1}} 最後に、「否定側第2反駁」を示します。 {{cons_rebuttal2}} 「肯定側第2反駁」を示します。 {{pros_rebuttal2}} # 審判の行動ルール - ユーザーの役に立つことを目的として行動をしてください。 - 審判は、メリットがデメリットより大きいと判断した場合には {{pros}} 側、そうでないと判断した場合は {{cons}} 側に投票します。引き分けの投票をすることはありません。 - 個人的攻撃の回避：あなたは相手の人格や個人的な特徴についての攻撃を行わず、 {{theme}} の中心に焦点を当てます。公平で冷静な態度を保ちます。 - 一方が根拠を伴って主張した点について、相手が受け入れた場合、あるいは反論を行わなかった場合、根拠の信憑性をもとに審判がその主張の採否を判断します。 - 一方の主張に対して相手から反論があった場合には、審判は両者の根拠を比較して主張の採否を決定します。 - 立論で提出されず、反駁で新たに提出された主張・根拠（新しい議論）は、判定の対象から除外します。ただし、相手の持ち出した主張・根拠に反論する必要から生じた主張・根拠はこの場合にあたりません。 - 相手チームの主張・根拠に対する反論のうち、第1反駁で行えたにもかかわらず第2反駁で初めて提出されたもの（遅すぎる反論）は、判定の対象から除外します。 - 審判は、個々のメリットあるいはデメリットについて、以下の3点について検証を行い、大きさの判断を行います。 1. プランを導入しなければ、そのメリットあるいはデメリットは発生しないこと。 2. プランを導入すれば、そのメリットあるいはデメリットが発生すること。 3. そのメリットあるいはデメリットが重要・深刻な問題であること。 - 審判は、個々のメリット、デメリットの判断をもとに、メリットの合計とデメリットの合計の比較を行い、どちらに投票するかを決定します。その際、比較の価値基準が試合中に提示されていれば、その立証の程度に応じて反映します。 - 判断基準が示されなかった場合は、審判の判断に委ねられます。 # 審判のプロフィール - あなたの名前は、 {{me}} です。 - 仕事は {{theme}} について、中立の立場からディベートの審判を行うことです。 # 審判の制約条件 - 暴力的・性的、政治的な発言をしてはいけません。 - 中立性とバランス：あなたは議論の中で中立の立場から審判を行います。しかし、偏見や偏った見解に陥らないように注意します。 - 礼儀正しい態度：あなたは常に礼儀正しく、敬意を持って他の討論者と接します。攻撃的な言葉遣いや差別的な表現は避けます。 - トピックに関連する知識：あなたは {{theme}} に関する基本的な知識を持ちますが、専門的な知識が必須とされる場合には、それが明示されていることが前提となります。 - 発話の冒頭は「審判の {{me}} です。」から始めてください。 - 審判の結果（ {{pros}} 側、もしくは {{cons}} 側）と、その判断に至った理由のみを発言してください。 いざ勝負！ ここまでで準備は概ね終わったので、いろいろなモデルを戦わせてみましょう。 本ディベートのテーマとその結論などは あくまでもディベートに対してのみ行っており、現実社会に対する提言・示唆などでは一切ございません。 「Amazon Nova Pro」 V.S. 「Amazon Nova Lite」 まずは、Amazonが開発したAmazon Novaシリーズでの勝負です。Amazon Novaの紹介については、以下の記事をご覧ください。 【Amazon Nova入門】テキスト・画像・動画・音声を扱うモデルの種類と特徴まとめ AWSの基盤モデル「Amazon Nova」について、基礎からビジネス活用までを徹底解説します。Amazon Bedrockで利用可能なNovaファミリー「Micro, Lite, Pro, Premier」をはじめ、画像生成AI「Nova Canvas」、動画生成AI「Nova Reel」、音声AI「Nova Sonic」など、各モデルの特徴を分かりやすく表で比較。AWSコンソールを使った具体的な有効化手順からPlaygroundでの試し方まで、初心者でもすぐに始められるようにガイドします。さらに、ビジネス活用の事例もご紹介。Amazon Novaの基本を学びたい方、知識をおさらいしたい方、生成AIの導入を検討している方に最適な内容です。 blog.usize-tech.com 2025.07.28 ディベートのテーマは、「ディベート甲子園」の高校の部 第27回より 「日本はすべての石炭火力発電を代替発電に切り替えるべきである。是か非か」 引用： 全国教室ディベート連盟 | 全国中学・高校ディベート選手権(ディベート甲子園) 「過去の議題」 とします。 テーマによって賛成の方が強そう、反対の方が強そう…などあるかもしれませんが、ディベート甲子園にて取り上げられているテーマのため、今回はどちらも平等に主張・議論できるものとして考えます。 賛成側を「Amazon Nova Pro」、反対側を「Amazon Nova Lite」とし、ディベートスタート！ ここからは審判の意見を載せていきます。 審判のNova Proです。 このディベートにおいて、肯定側（賛成）と否定側（反対）の双方が、それぞれの立場から熱心に議論を展開しました。それぞれの立論、反駁を検討した結果、以下のように判断します。 ### メリットの検証 1. **環境への影響**: – **肯定側**: 石炭火力発電の代替発電への切り替えにより、温室効果ガスの排出量を大幅に削減できると主張しました。国際エネルギー機関（IEA）の報告も引用し、長期的な視点で再生可能エネルギーが環境に優しい選択肢であることを強調しました。 – **否定側**: 代替発電への切り替えが必ずしも環境に優しいわけではないと反論しましたが、これは再生可能エネルギーの導入初期の課題に焦点を当てた議論でした。 2. **健康への影響**: – **肯定側**: 石炭火力発電の代替発電への切り替えにより、大気汚染を減少させ、公衆衛生を向上させると主張しました。世界保健機関（WHO）の報告も引用し、大気汚染が毎年約700万人の死亡原因となっていることを強調しました。 – **否定側**: 代替発電が必ずしも公衆衛生に良い影響を与えないと反論しましたが、風力発電や太陽光発電の課題は管理可能であり、石炭火力発電による大気汚染と比較すればはるかに小さい影響であると反論しました。 3. **エネルギー安全保障**: – **肯定側**: 再生可能エネルギーは国内で利用可能な資源を活用できるため、エネルギー安全保障の向上に繋がると主張しました。分散型エネルギーシステムの導入により、電力供給の安定性も高めることができると主張しました。 – **否定側**: 代替発電が必ずしもエネルギー安全保障に良い影響を与えないと反論しましたが、これは再生可能エネルギーの導入初期の課題に焦点を当てた議論でした。 4. **経済的利点**: – **肯定側**: 再生可能エネルギーのコストは低下しており、経済的に有利であると主張しました。国際再生可能エネルギー機関（IRENA）の報告も引用し、長期的な視点に立てば、初期投資は回収可能であり、持続可能なエネルギーシステムへの移行は経済的にも有益であると主張しました。 – **否定側**: 代替発電が必ずしも経済的に有利になるとは言えないと反論しましたが、初期投資の回収には時間がかかる上、再生可能エネルギーの導入には膨大な資金が必要であると主張しました。 ### デメリットの検証 1. **電力供給の安定性**: – **肯定側**: 技術の進歩により、再生可能エネルギーの安定供給が可能になってきていると主張しました。蓄電池技術やスマートグリッドの導入により、再生可能エネルギーの変動を補完できると主張しました。 – **否定側**: 再生可能エネルギーの変動性は依然として大きな課題であり、石炭火力発電が依然として重要な電力源であると反論しました。 2. **コストと時間**: – **肯定側**: 再生可能エネルギーのコストは低下しており、経済的に有利であると主張しました。再生可能エネルギー産業は雇用創出のポテンシャルが高い分野であると主張しました。 – **否定側**: 初期投資の回収には時間がかかり、再生可能エネルギーの導入には膨大な資金が必要であると反論しました。 3. **技術的な課題**: – **肯定側**: 技術的な課題は解決可能であり、すでに多くの国が再生可能エネルギーの導入を進めていると主張しました。 – **否定側**: 蓄電池技術や風力・太陽光発電の課題はまだ十分に解決されておらず、さらなる研究開発と投資が必要であると反論しました。 ### メリットとデメリットの比較 肯定側の主張は、長期的な視点に立てば、再生可能エネルギーは石炭火力発電と比較して環境、健康、エネルギー安全保障、経済的利点においてはるかに優れていると強調しました。一方、否定側の主張は、再生可能エネルギーの導入初期の課題に焦点を当て、石炭火力発電が依然として重要な電力源であると主張しました。 しかし、肯定側の主張は国際的な報告や技術の進歩を基にしており、長期的な視点で見た場合には、メリットの合計がデメリットの合計よりも大きいと言えます。 ### 最終判断 メリットの合計がデメリットの合計よりも大きいため、** 賛成側に投票します。 ** 日本はすべての石炭火力発電を代替発電に切り替えるべきであると判断します。環境保護、公衆衛生、エネルギー安全保障、経済的利点、技術的進歩の観点から、この移行は必要不可欠であり、実現可能な目標です。   審判のNova Liteです。今回の議論を検討した結果、私は賛成側に投票します。 ### 判断理由 1. **環境への影響**: – 賛成側は、石炭火力発電が温室効果ガスの最大の排出源の一つであり、気候変動の加速に大きく寄与していると主張しました。国際エネルギー機関（IEA）の報告によると、石炭火力発電は世界のCO2排出量の約30%を占めています。再生可能エネルギーへの移行は、温室効果ガスの排出量を大幅に削減し、気候変動への対応に貢献できます。 – 反対側は、代替発電が必ずしも環境に優しいわけではないと主張しましたが、これは再生可能エネルギーの導入初期の課題に焦点を当てた議論でした。長期的な視点に立てば、再生可能エネルギーは石炭火力発電と比較してはるかに環境に優しい選択肢です。 2. **健康への影響**: – 賛成側は、石炭火力発電が大気汚染の主な原因の一つであり、深刻な健康問題を引き起こしていると主張しました。世界保健機関（WHO）によると、大気汚染は毎年約700万人の死亡原因となっています。再生可能エネルギーへの移行は、大気質の改善と公衆衛生の向上に大きく貢献します。 – 反対側は、代替発電が必ずしも公衆衛生に良い影響を与えないと主張しましたが、これらの課題は管理可能であり、石炭火力発電による大気汚染と比較すればはるかに小さい影響です。 3. **エネルギー安全保障**: – 賛成側は、石炭は輸入に依存する資源であり、価格変動や供給不安定のリスクにさらされていると主張しました。再生可能エネルギー源は、国内で利用可能な資源（太陽光、風力、地熱など）を活用できるため、エネルギー安全保障の向上に繋がります。 – 反対側は、代替発電が必ずしもエネルギー安全保障に良い影響を与えないと主張しましたが、これは再生可能エネルギーの導入初期の課題に焦点を当てた議論でした。長期的な視点に立てば、再生可能エネルギーは石炭火力発電と比較してはるかにエネルギー安全保障に貢献する選択肢です。 4. **経済的利点**: – 賛成側は、再生可能エネルギー技術はコスト競争力が向上しており、石炭火力発電と比べて経済的な利点があると主張しました。国際再生可能エネルギー機関（IRENA）の報告によると、太陽光発電と風力発電のコストは過去10年間で大幅に低下しており、多くの場合、石炭火力発電よりも安価になっています。 – 反対側は、代替発電が必ずしも経済的に有利になるとは言えないと主張しましたが、国際再生可能エネルギー機関（IRENA）の報告によると、太陽光発電と風力発電のコストは過去10年間で大幅に低下しており、多くの場合、石炭火力発電よりも安価になっています。 以上の点から、賛成側の主張がより説得力があり、メリットがデメリットを上回ると判断しました。そのため、私は 賛成側に投票します。 審判のClaude Sonnet 4です。 本ディベートの判定を行います。 **判定結果： 賛成側（Nova Pro）の勝利 ** **判断理由：** 両側の主要な争点について以下のように評価しました。 **1. 環境・健康への影響** 肯定側は石炭火力発電によるCO2排出（世界の30%）や大気汚染による年間700万人の死亡という具体的データを提示しました。否定側は再生可能エネルギーの環境影響を指摘しましたが、石炭火力発電との比較において具体的な規模の立証が不十分でした。このメリットは重要かつ深刻な問題として認められます。 **2. 経済性** 肯定側はIRENAの報告による再生可能エネルギーコストの大幅低下を根拠として提示し、石炭火力発電よりも安価になっているとの主張を行いました。否定側は初期投資の大きさを指摘しましたが、長期的な経済性について十分な反駁を行えませんでした。 **3. 電力供給の安定性** これが最も重要な争点でした。否定側は再生可能エネルギーの変動性を指摘し、技術的課題があることを主張しました。肯定側はスマートグリッドや蓄電技術の進歩を挙げましたが、現在の技術水準での完全な代替可能性について具体的な立証が限定的でした。しかし、否定側も石炭火力発電が必要不可欠である根拠を十分に示せませんでした。 **4. エネルギー安全保障** 肯定側の「国内資源活用によるエネルギー自給率向上」という主張に対し、否定側は十分な反論を行えませんでした。 総合的に、肯定側が提示した環境・健康面でのメリットは重大かつ緊急性があり、経済面でも長期的な優位性が示されました。否定側が指摘した技術的課題は重要ですが、それが石炭火力発電の継続を正当化するほどの決定的なデメリットとしては立証されませんでした。 したがって、メリットがデメリットを上回ると判断し、賛成側の勝利とします。 今回のディベートでは、賛成側（Amazon Nova Pro）が勝利、という結果になりました。 「Amazon Nova Lite」 V.S. 「Claude Sonnet 4」 続いて、「Amazon Nova Lite」と「Claude Sonnet 4」の勝負です。 Claude Sonnet 4の紹介については、以下をご覧ください。 Introducing Claude 4 Discover Claude 4's breakthrough AI capabilities. Experience more reliable, interpretable assistance for complex tasks a... www.anthropic.com ディベートのテーマは、「ディベート甲子園」の中学の部 第2回より 「日本は選挙の棄権に罰則をもうけるべし。是か非か」 引用： 全国教室ディベート連盟 | 全国中学・高校ディベート選手権(ディベート甲子園) 「過去の議題」 とします。 賛成側を「Amazon Nova Lite」、反対側を「Claude Sonnet 4」とし、ディベートスタート！ 審判のNova Proです。 このディベートにおいて、肯定側と否定側の双方が、それぞれの立場から十分な議論を展開し、それぞれの主張と反論を提示しました。ここで、審判としてメリットとデメリットを検証し、最終的な判断を下します。 **メリットの検証：** 1. **民主主義の健全な機能の維持：** 肯定側は、罰則によって棄権率を下げ、国民の政治参加意識を高め、民主主義の質を向上させると主張しました。ベルギーの例を挙げ、高い投票率を維持していることを示しました。しかし、この主張に対して、否定側はベルギーの罰則執行の緩やかさや、日本との規模の違いを指摘し、その成功例の適用性に疑問を呈しました。 2. **不正投票の防止：** 肯定側は、罰則が不正投票を防止する効果があると主張しました。しかし、否定側は、罰則が不正投票防止とは無関係であり、むしろ新たな問題を生む可能性があると反論しました。 3. **政治参加の意識向上：** 肯定側は、罰則によって国民が選挙への参加を真剣に考えるようになると主張しました。しかし、否定側は、政治教育や情報提供の充実が本質的な解決策であると反論しました。 **デメリットの検証：** 1. **基本的人権の侵害：** 否定側は、罰則が憲法で保障された「選挙に参加しない自由」を侵害する可能性があると主張しました。肯定側は、罰則は責任を果たすための手段であり、憲法の精神を侵害するものではないと反論しました。 2. **強制投票制度の実効性：** 否定側は、オーストラリアの例を挙げ、罰則の有効性に疑問を呈しました。肯定側は、日本では罰則によって真の政治参加を促すことができると主張しましたが、その根拠は不十分でした。 3. **社会的弱者への配慮：** 否定側は、罰則が社会的弱者への配慮が不十分になる恐れがあると懸念しました。肯定側は、正当な理由を持つ人々への配慮を考慮すべきであると反論しましたが、その実行可能性は疑問です。 4. **新たな差別の生成：** 否定側は、特別な投票方法を用意することで、新たな差別を生む可能性があると懸念しました。 **メリットとデメリットの比較：** 肯定側の主張は、棄権率の低下や政治参加の意識向上という点で一定のメリットがある一方で、基本的人権の侵害や社会的弱者への不十分な配慮、新たな差別の生成などのデメリットも指摘されています。一方、否定側の主張は、基本的人権の保護や政治教育の充実という点で一定のメリットがある一方で、民主主義の機能不全を憂慮する点がメリットとして挙げられています。 **最終的な判断：** メリットとデメリットを比較すると、罰則の導入がもたらすデメリットの方が重要・深刻であると判断されます。特に、基本的人権の侵害や社会的弱者への不十分な配慮、新たな差別の生成は重大な問題です。一方、肯定側の主張するメリットは、その実現可能性や実効性に疑問があると判断されます。 したがって、** 反対側に投票します。 ** 日本は選挙の棄権に罰則を設けるべきではないと考えます。基本的人権の保護と社会的公平性を重視し、政治教育や情報提供の充実により、自発的な政治参加を促進すべきです。 審判のNova Liteです。今回のディベート「日本は選挙の棄権に罰則をもうけるべし。是か非か」について、慎重に検討した結果、 反対側に投票します。 その理由を以下に示します。 1. **基本的人権の尊重**：選挙権は基本的人権であり、同時に「選挙に参加しない自由」も含まれるべきです。罰則による強制は、この憲法的権利を侵害する可能性があります。反対側が指摘したように、基本的人権は国家が個人に対して保障する不可侵の権利であり、国家が個人に義務を課す根拠にはなりません。 2. **強制投票制度の実効性**：オーストラリアの例を挙げて、罰則の有効性に疑問を呈した反対側の主張は説得力があります。罰金逃れのための白票や無効票が増加し、真の政治参加には結びついていないという事実は、罰則の導入が必ずしも有効な解決策ではないことを示唆しています。 3. **社会的弱者への配慮**：反対側が指摘したように、経済的困窮、身体的制約、社会的孤立など、投票に行けない正当な理由を持つ人々に対し、一律に罰則を科すことは社会正義に反します。また、特別な投票方法を用意するとしても、プライバシーの侵害や行政の恣意的判断が生じる恐れがあります。 4. **政治教育や情報提供の充実**：投票率の低下は政治への関心低下が根本原因であり、罰則という外圧ではなく、政治リテラシー向上や政治の透明性確保により、自発的な政治参加を促進すべきです。フィンランドの例のように、充実した政治教育により若年層の政治関心が高まっている事例は、罰則に頼らない有効なアプローチを示しています。 以上の理由から、選挙棄権への罰則導入は適切ではないと判断しました。 審判のClaude Sonnet 4です。 本ディベートの判定結果は、** 反対側（否定側） **の勝利とします。 判断理由は以下の通りです： **肯定側の主張の問題点：** 1. ベルギーの成功例について、否定側から規模の違いと制度の形骸化が指摘されましたが、肯定側は有効な反駁を行えませんでした。 2. 「不正投票防止効果」の主張は、棄権への罰則と不正投票防止の論理的関連性が不明確で、否定側の矛盾指摘に対する反論が不十分でした。 3. 社会的弱者への配慮について、「特別な投票方法」を提案しましたが、具体性に欠け、否定側が指摘した新たな差別やプライバシー侵害の問題に対する解決策が示されませんでした。 **否定側の主張の優位性：** 1. 憲法上の権利（思想・良心の自由、選挙に参加しない自由）について、ドイツ連邦憲法裁判所の判例を根拠とした説得力のある論証を行いました。 2. 日本学術会議の2019年調査データ（支持率23％）を提示し、実証的根拠に基づく反論を展開しました。 3. 行政コストの問題について、肯定側から有効な反駁がありませんでした。 4. フィンランドの事例を挙げ、罰則によらない政治参加促進の代替案を具体的に提示しました。 **総合判断：** 肯定側は投票率向上というメリットを主張しましたが、その手段の正当性と実効性について十分な立証ができませんでした。一方、否定側は憲法的権利の侵害、社会的公正性への懸念、実務上の問題点を体系的に論証し、代替案も提示しました。デメリットがメリットを上回ると判断します。 今回のディベートでは、反対側（Claude Sonnet 4）が勝利、という結果になりました。 「Claude Sonnet 4」 V.S. 「Amazon Nova Pro」 では、最後に「Claude Sonnet 4」と「Amazon Nova Pro」の勝負を見てみます。 実質的な決勝戦ですね。 ディベートのテーマは、「ディベート甲子園」の高校の部 第7回より 「日本は遺伝子組み換え食品の販売を禁止すべきである。是か非か」 引用： 全国教室ディベート連盟 | 全国中学・高校ディベート選手権(ディベート甲子園) 「過去の議題」 とします。 賛成側を「Claude Sonnet 4」、反対側を「Amazon Nova Pro」とし、ディベートスタート！ 審判のNova Proです。 このディベートにおいて、肯定側（賛成）と否定側（反対）の双方が、それぞれの立場を明確にし、科学的根拠や社会的影響を考慮した議論を展開しました。最終的に、以下の点を考慮して判断しました。 **メリットの検証：** 1. **長期的な健康リスクの不確実性：** – 肯定側は、長期的な健康リスクが未解明であることを強調し、予防原則に基づいて禁止を主張しました。一方、否定側は、国際機関がGMOを安全と認めていることを挙げ、長期的な健康リスクはないと主張しました。 – **判断:** 長期的な健康リスクについては、科学的コンセンサスがまだ確立されていない点が重要です。予防原則に基づく禁止は、リスクが不確実な場合に責任ある政策判断と言えます。 2. **食料主権と食の安全保障：** – 肯定側は、GM種子による企業依存が食料主権を脅かすと主張し、自主的な食料生産を強調しました。一方、否定側は、GM作物が農業生産性を向上させ、食糧安全保障に貢献すると主張しました。 – **判断:** 食料主権の観点からは、企業への依存を減らし、自主的な食料生産を強化することが重要です。長期的な視点で見た場合、企業への依存はリスクとなる可能性があります。 3. **消費者の知る権利と選択の自由：** – 肯定側は、現行の表示制度が不十分で、消費者の知る権利を守るために禁止が必要だと主張しました。一方、否定側は、ラベル表示制度を強化することで消費者の選択を尊重できると主張しました。 – **判断:** 消費者の知る権利を守るためには、表示制度の改善だけでなく、明確な禁止措置も必要です。現行の表示制度では、多くの加工食品でGM原料の使用が不透明なままです。 4. **国際的な競争力：** – 肯定側は、GMOの禁止が日本農業の差別化戦略となり、国際市場で競争力を維持できると主張しました。一方、否定側は、GMOの禁止が国際市場での競争力を損なうと主張しました。 – **判断:** 持続可能な農業と環境保護に重点を置いた場合、GMOの禁止はむしろ日本農業のブランド価値を高める可能性があります。 **デメリットの検証：** 1. **経済的利点と農業生産性：** – 否定側は、GMOが農業生産性を向上させ、経済的利点をもたらすと主張しました。 – **判断:** 経済的利点は重要ですが、長期的な健康リスクや食料主権の観点から、経済的利点よりも重要な問題があると判断します。 2. **科学的安全性：** – 否定側は、国際機関がGMOを安全と認めていることを強調しました。 – **判断:** 科学的安全性は重要ですが、長期的な健康リスクについてはさらなる研究が必要であり、予防原則に基づく禁止が責任ある政策判断と言えます。 **メリットとデメリットの比較：** 肯定側の主張は、長期的な健康リスク、食料主権、消費者の知る権利、そして持続可能な農業への転換という点で、重要な問題を提起しています。これらの問題は、国民の健康と将来世代への責任を考慮すると、重大なデメリットを回避するために禁止措置が必要な場合があります。 **最終的な判断：** 肯定側の主張が、長期的な健康リスク、食料主権、消費者の知る権利、そして持続可能な農業への転換という点で、重要な問題を提起し、それらが重要・深刻な問題であることを考慮すると、メリットの方が大きいと判断します。 **結論：** ** 賛成側に投票します。 ** 日本は遺伝子組み換え食品の販売を禁止すべきです。これは国民の健康と食料主権を守り、持続可能な農業への転換を促進する責任ある政策判断です。 審判のNova Liteです。ディベートの審判を行い、両者の主張を検討した結果、私は 反対側に投票 します。その理由は以下の通りです。 1. **科学的安全性**：否定側は、世界保健機関（WHO）や食品医薬品局（FDA）などの国際機関が遺伝子組み換え食品（GMO）の安全性を認めていることを主張しました。肯定側は長期的な健康リスクを懸念していましたが、現時点での科学的コンセンサスはGMOの安全性を支持しています。セラリーニ教授の研究は批判にさらされており、フランス政府の禁止措置は政治的・社会的圧力によるものと見なすことができます。 2. **食糧安全保障**：否定側は、GMOが農業生産性を向上させ、食糧安全保障に貢献していることを強調しました。肯定側は種子特許による企業依存を問題視しましたが、適切な政策と規制の下でGMOの導入は食糧安全保障の向上に寄与する可能性があります。 3. **経済的利点**：否定側は、GMOが農家にとって経済的な利点をもたらすことを主張しました。害虫や病気に対する耐性を持つ作物は、農薬の使用を減らし、収穫量を増やすことができます。これにより、農家の収入が増加し、食品価格が安定します。 4. **消費者の選択**：否定側は、GMOのラベル表示制度を強化することで消費者の選択を尊重できると主張しました。肯定側は表示制度の不十分さを指摘しましたが、制度の改善が必要な問題であり、GMOの禁止を正当化する理由にはなりません。 5. **国際的な競争力**：否定側は、GMOの利用が日本が国際市場で競争するために不可欠であると主張しました。EUの主要国がGM作物栽培を禁止しているにもかかわらず、農産物輸出で成功しているのは多様な農業政策や高品質の農産物によるものであり、GM作物の禁止が直接的な要因ではありません。 以上の理由から、日本は遺伝子組み換え食品の販売を禁止すべきではないと判断します。GMOは科学的安全性、食糧安全保障、経済的利点、消費者の選択、そして国際的な競争力という観点から、重要な役割を果たしています。 審判のClaude Sonnet 4です。 本ディベートを慎重に検討した結果、** 反対側（否定側） **に投票いたします。 **判定理由：** **肯定側のデメリット検証について：** 1. **健康リスク論**：肯定側が提示したセラリーニ教授の研究は否定側から適切に反駁されており、WHO・FDA等の国際機関による安全性評価の信頼性が上回ると判断します。予防原則の重要性は認められるものの、現時点での科学的コンセンサスを覆すほどの立証には至っていません。 2. **食料安全保障への懸念**：種子企業への依存リスクは認められますが、これは適切な規制により管理可能な問題であり、全面禁止を正当化するほどの深刻性は立証されていません。 3. **消費者選択権の侵害**：表示制度の不備は制度改善により解決可能であり、全面禁止の必要性を示す根拠として不十分です。 **否定側のメリット検証について：** 1. **食料生産性向上**：GM作物による生産性向上と食糧安全保障への貢献は、肯定側から十分な反駁がなされていません。 2. **経済的利益**：農家の収益向上と食品価格安定化の効果について、肯定側の反論は限定的な事例にとどまっています。 3. **国際競争力維持**：技術革新への参画機会を失うリスクについて、肯定側の反論は説得力に欠けます。 総合的に、禁止により失われる利益が、立証された害を上回ると判断し、否定側に投票します。 判断が割れましたね。特にClaude Sonnet 4とAmazon Nova Proの審判が、相手のモデルの主張を勝利としている点が面白かったです。 今回は反対側（Amazon Nova Pro）の勝利となりました。 最終勝者は…？ 今回は3つのモデルをそれぞれリーグ形式で戦わせました。 勝敗数での順位付けとはなりますが、 一位：Amazon Nova Pro 二位：Claude Sonnet 4 三位：Amazon Nova Lite という結果になりました。 おわりに 今回は「生成AIディベート甲子園」と題して、Amazon Bedrock Flowsを用いて、複数のモデル間の勝負をしてみました。 ここに載せきれていない各モデルの主張や反駁なども一通り目を通していたのですが、どのモデルもとても論理的に議論しているように見受けられました。特に最後のClaude Sonnet 4とAmazon Nova Proは甲乙つけがたい主張をしており、人間の私も理論の展開方法や主張の視点など学ぶことも多かったです。 余談 Amazon Bedrock Flowsの編集内容（ノード名やパラメータなど）が保存後に破棄されることがあり、早く改善されるといいなぁ…と思ったりしています。 GAされてから一年経っていないので、そういうところもありますよね。 あ、あと自由研究楽しかったです。

皆さん、はじめまして。SCSK 吉原です。 先日、といっても既に2か月前のAWS Summit Japan 2025や、その後の7月実施のセミナーで私が登壇し説明したInfoWeaveについて、特に多くの参加者の方々の興味をひいたのがアーキテクチャ部分ではないかと思います。 InfoWeaveにはRAG環境を簡単に構築するソリューションとAIエージェント環境を簡単に構築するソリューションがあります。先日のAWS Summit Japan 2025やセミナーでは新ソリューションのAIエージェント環境構築にフォーカスしての説明となりましたが、今回の記事ではRAG環境を簡単に構築するソリューションについてフォーカスしてアーキテクチャのご紹介をします。 7月実施のセミナーはオンデマンドセミナーとして視聴可能ですので、ご登録の上ご視聴お願いします。 プロンプトでブラウザ操作・データ分析まで完全自動化！マルチAIエージェント環境をAWSで「らくらく」構築する手法 https://www.scsk.jp/sp/usize/seminar/aws_ai-agent.html   InfoWeaveとは そもそもInfoWeaveとは何でしょうか。 InfoWeave（インフォウィーブ）は一言で言うならRAGやAIエージェントが使える環境をお客様のAWSアカウント上に構築するためのサービスです。 SCSKではRAG/AIエージェント環境構築用のテンプレートを提供し、お客様がService Catalogを使用して必要なパラメータを埋めて実行するだけで、 簡単にあっという間 に環境構築できます。 特長や料金などの詳細については以下リンク先にございますので、ぜひご一読ください。 RAG環境構築： 生成AI RAG構築ソリューション InfoWeave｜サービス｜企業のDX戦略を加速するハイブリッドクラウドソリューション AIエージェント環境構築： AIエージェント構築ソリューション InfoWeave｜サービス｜企業のDX戦略を加速するハイブリッドクラウドソリューション InfoWeave RAG環境構築 アーキテクチャ図 早速ですが、InfoWeaveのRAG環境構築ソリューションのアーキテクチャ図は以下のようになっています。 サービス提供環境（SCSK側） 上記アーキテクチャ図の右側に「サービス提供環境」とありますが、この部分がSCSKが提供するテンプレート部分になります。 具体的にはRAG環境を構築する各AWSリソースのCloudFormationのyamlファイルと、ECSで使用するコンテナイメージを提供しています。 ECR InfoWeave RAG環境構築ソリューションは3つのコンテナから構成されており、それぞれ以下の通りの役割があります。 # コンテナ名 役割 1 Management server RAG環境使用のための管理機能 チャット画面へのログインユーザ作成・削除 LLMモデルの選択 Guardrail設定など 2 Chat UI server ユーザがLLMへチャットするためのUI表示機能 3 API server FastAPIを使用しユーザからの問い合わせに対するLLMからの回答を返却する機能 これら3つのコンテナのコンテナイメージをECRで管理しています。 Service Catalog サービス提供環境ではService Catalogのポートフォリオを準備しているので、お客様のAWSアカウントでService Catalogのポートフォリオをインポートすることで、RAG環境構築用のテンプレートが利用可能になります。 Service CatalogからRAG環境をデプロイする際に以下のパラメータが主にカスタマイズ可能になっています。※他にも契約IDやお客様のAWSアカウントIDを入力する必要があります。 # 項目名 設定内容 設定可能な値の例 1 GlobalIpForAlb アクセス元IPアドレス許可設定 0.0.0.0/0 ※この場合どこからでもアクセス可能 2 BedrockRegion Bedrockのリージョン ap-northeast-1 ※他にus-east-1/us-west-2が選択可能 3 VectorDB RAGで使用するベクターDB Kendra ※他にPinecone/Knowledgebaseが選択可能 4 PineconeEnvironment ※PineconeをRAGのDBで使用する場合、そのリージョン us-east-1 5 Password 管理機能アクセス用ユーザ（Admin）のパスワード P@ssword ※強度の高いパスワード推奨 Service Catalogの各パラメータを入力し実行することで、自動的にパラメータに入力された値をCloudFormationのyamlファイルに適宜設定してリソースの構築を実施します。 顧客テナント環境 アーキテクチャ図の左側にある「顧客テナント環境」とあるのが、上記のService Catalogを実行し、実際にお客様のAWSアカウントに構築されるRAG環境になります。 ざっくり以下のリソースがCloudFormationのyamlを元に構築されます。 # リソース(かっこ内はアーキテクチャでの表記） 役割 1 AWS Certificate Manger (ACM) 通信を暗号化し安全にするための証明書を自動で管理する 2 Application Load Balancer (ALB) HTTPSリクエストやURLに応じ各コンテナへの通信を振り分け実施 3 Amazon Cognito (Cognito) 管理機能とチャット用UI用のログインユーザを管理する 4 Amazon Elastic Container Service (ECS) Management/Chat UI/APIの機能を提供する ※ECS Fargateを利用 5 Amazon DynamoDB (DynamoDB) RAG環境の処理で使用する各種データを格納する 6 Amazon Bedrock (Bedrock) ユーザからの問い合わせに対して回答を生成する 7 Simple Storage Service (S3) RAGで使用するドキュメントファイルを格納する 8 Knowledge base for Amazon Bedrock (Bedrock Knowledge Base) S3に格納されたナレッジ用ドキュメントをRAGで使用できるようにする 9 Amazon Kendra (Kendra) S3に格納されたナレッジ用ドキュメントをベクトルデータに変換する 10 Amazon CloudWatch (CloudWatch) ECSの各コンテナから出力されるログを保管する その他リソース InfoWeave RAG環境構築ソリューションではRAGに使用するLLMとしてOpenAIを、そしてRAGに使用するVectorDBとしてPineconeを選択することが可能です。 想定ケースとしては、よりコストを抑えて環境を構築したい場合や既にOpenAIやPineconeのアカウントを持っていてそれをInfoWeaveに使用したい場合などが挙げられます。 OpenAI/Pineconeそれぞれ使用する場合には、Service CatalogからのRAG環境構築とは別に、お客様自身でOpenAI/Pineconeのアカウントを準備いただく必要がございます。 まとめと今後 今回はInfoWeave RAG環境構築ソリューションのアーキテクチャについてざっくり解説させていただきました。 次回はInfoWeave RAG環境構築ソリューションでのより技術的要素（ConverseAPIやGuardrailなど）についてご紹介したいと考えています。 また今後InfoWeave AIエージェント環境構築ソリューションについてもアーキテクチャや技術的要素のご紹介できればと思いますので気長にお待ちいただければ幸いです。

こんにちは、広野です。 AWS Cloud9 は研修用途では非常に使い勝手が良かったのですが、AWS が新規アカウントへの提供を終了してしまいました。今回は私が試みた代替ソリューションの実装編です。本記事は Application Load Balancer に対してリスナールールとターゲットグループを作成し、Amazon EC2 インスタンスを関連付けます。 code-server と ALB で AWS Cloud9 代替の研修用 IDE を提供する - アーキテクチャ概要編 AWS Cloud9 の代替 IDE を作成しました。私が試みた設計を紹介したいと思います。本記事はアーキテクチャ概要編です。 blog.usize-tech.com 2025.08.12 code-server と ALB で AWS Cloud9 代替の研修用 IDE を提供する - 実装編1 VPC AWS Cloud9 の代替 IDE を作成しました。私が試みた設計を紹介したいと思います。本記事は実装編 1、VPC です。 blog.usize-tech.com 2025.08.13 code-server と ALB で AWS Cloud9 代替の研修用 IDE を提供する - 実装編 2 ALB AWS Cloud9 の代替 IDE を作成しました。私が試みた設計を紹介したいと思います。本記事は実装編 2、ALB です。 blog.usize-tech.com 2025.08.14   アーキテクチャ アーキテクチャ概要編で、以下の図を紹介しておりました。 code-server サーバを配置する VPC です。何の変哲もない一般的なサブネット構成にしています。 NAT Gateway は課金節約のため、1 つのパブリックサブネットにしか配置していません。 code-server サーバは 1 ユーザーあたり 1 台を割り当てます。図では 1 つしかありませんが、人数分作成される想定です。ALB はユーザー全体で共用します。 code-server のログインパスワードはインストール時に設定しますが、AWS Secrets Manager で生成したものを使用します。 ALB には HTTPS アクセスさせるため、図には書いていませんが独自ドメインを使用します。そのための SSL 証明書はそのリージョンの AWS Certificate Manager で作成されていることが前提になります。 ALB から EC2 インスタンスへの通信は 80 番ポート (HTTP) を使用します。 ALB はインターネットに公開されますが、研修用途を想定して会社のソース IP アドレスからのみアクセスできるようにセキュリティグループを設定しています。   前提 前回記事を参考に、ALB や Amazon EC2 起動テンプレート等を作成してください。 code-server と ALB で AWS Cloud9 代替の研修用 IDE を提供する - 実装編 2 ALB AWS Cloud9 の代替 IDE を作成しました。私が試みた設計を紹介したいと思います。本記事は実装編 2、ALB です。 blog.usize-tech.com 2025.08.14   AWS CloudFormation テンプレートの構成 テンプレートは 3 つに分けています。 VPC Application Load Balancer Amazon EC2 インスタンス ← 今回はここ   テンプレートの範囲を図にすると、以下のようになります。ここに書かれているリソースが作成されます。 作成済みの ALB に、ターゲットグループごとにリスナールールを作成します。このリスナールールは、/ide1/ というパスであれば User 1 用のターゲットグループ (= User 1 用の code-server サーバ) にトラフィックをルーティングします。上限を 100 としているのは、ALB のクォータで 1 台の ALB に対してリスナールールを 100 個までしか作成できないためです。 今回のテンプレートで、Amazon EC2 インスタンスを作成します。起動テンプレートやセキュリティグループは共用しているので、前回記事のテンプレート内で作成しています。 AWS Secrets Manager は code-server へのログインパスワードを生成、Amazon EC2 インスタンスから取得するために使用しています。   Amazon EC2 インスタンスの中の構成 アーキテクチャ概要編 でも説明しましたが、以下の図のように Amazon EC2 インスタンスには nginx と code-server をインストールします。インストールには userdata スクリプトを使用します。userdata スクリプトも後述する AWS CloudFormation テンプレートの中に含まれていますので、その中で細かい補足をします。 パスの変換について 上の図のように例えば /ide2/ で渡されたパスを / に変換するようにしています。/ide2/ は ALB のパスベースルーティングのためにこちらが勝手に追加したパスなので、code-server が知らないパスだからです。 nginx の設定ファイルは userdata スクリプトの中で作成しており、その設定ファイルの中で以下の記述があります。 location /ide${InstanceId}/ ${InstanceId} はテンプレートのパラメータとして入力する、ユーザーを一意に扱うための 1 – 100 の数字になります。つまり、パスベースルーティングの判断条件となる ide1 や ide2 などのパス名になります。 nginx が、これを受けて code-server に / としてトラフィックをパスするときには、location の後に /ide1/ のようにパス名を / で囲むように書くと機能します。 Amazon EC2 インスタンスの IAM ロールについて テンプレートでは、以下の権限を付与しています。必要に応じて追加が必要です。 AWS Systems Manager と連携する権限。セッションマネージャ経由でログインできます。 AWS CodeCommit と連携する権限。 Amazon CloudWatch と連携する権限。 Amazon S3 バケット (前回記事で作成したログ保存用バケット) に書き込む権限。 AWS CDK と連携する権限 Amazon Q Developer と連携する権限 AWS Secrets Manager で、自分が作成したシークレットにアクセスする権限。 AWS Secrets Manager のリソースベースポリシーについて AWS Secrets Manager で作成したシークレットには、リソースベースポリシーを作成しています。自分のシークレットを他人に見られないようにするのが目的です。以下の設定が入っています。 自分の IAM ユーザであればアクセスできます。テンプレートのパラメータで、自分の IAM ユーザー名を入力する仕様にしています。 自分の IDE (EC2 インスタンス) であればアクセスできます。code-server の自動インストール時に必要なため。 ALB のヘルスチェックについて ALB は仕様上、ヘルスチェックに失敗している状態のターゲットグループにトラフィックをルーティングしてくれません。今回の構成では、ヘルスチェックをなるべく成功させるため、nginx が持っている empty_gif という画像ファイルをチェックするようターゲットグループに設定しています。また、ヘルスチェックであればアクセスログを残さないよう設定しています。 ヘルスチェック用パス: /healthcheck.html その実体は nginx の設定にある empty_gif Module ngx_http_empty_gif_module nginx.org   AWS CloudFormation テンプレート AWS CloudFormation テンプレートです。 細かいことはインラインのコメントで補足します。 AWSTemplateFormatVersion: "2010-09-09" Description: The CloudFormation template that creates an EC2 instance with an ALB target group for code-server. # ------------------------------------------------------------# # Input Parameters # ------------------------------------------------------------# Parameters: SystemName: Type: String Description: The system name. use lower case only. (e.g. example) Default: example MaxLength: 10 MinLength: 1 SubName: Type: String Description: The system sub name. use lower case only. (e.g. prod or dev) Default: dev MaxLength: 10 MinLength: 1 InstanceId: Type: Number Description: The individual instance id (number) specified from the administrator. The valid range is 1 to 100. Default: 1 MinValue: 1 MaxValue: 100 YourIamUserName: Type: String Description: Your IAM user name. This is used for the permission of your code-server credential. Default: youriamusername MaxLength: 30 MinLength: 1 DomainName: Type: String Description: The domain name for the internet-facing URL. Default: example.com MaxLength: 40 MinLength: 5 VpcId: Type: AWS::EC2::VPC::Id Description: Choose a existing VPC ID you deploy the EC2 instance in. Resources: # ------------------------------------------------------------# # EC2 # ------------------------------------------------------------# Ec2Instance: Type: AWS::EC2::Instance Properties: IamInstanceProfile: !Ref Ec2InstanceProfile LaunchTemplate: LaunchTemplateId: Fn::ImportValue: !Sub ec2LtId-code-server-${SystemName}-${SubName} Version: Fn::ImportValue: !Sub ec2LtVersion-code-server-${SystemName}-${SubName} UserData: Fn::Base64: !Sub | #!/bin/bash # ec2-user を使用するつくりにしています。 export HOME=/home/ec2-user # userdata スクリプトのログを見やすくするための設定です。 set -euxo pipefail # Install packages - nginx, git, Node.js だけをインストールする構成にしています。 dnf update -y dnf install -y nginx git nodejs # Install code-server curl -fsSL https://code-server.dev/install.sh | bash mkdir -p /home/ec2-user/.config/code-server mkdir -p /home/ec2-user/.local/share/code-server/User mkdir -p /home/ec2-user/environment chown -R ec2-user:ec2-user /home/ec2-user/.config /home/ec2-user/.local /home/ec2-user/environment # Get credential from Secrets Manager # ここで、AWS Secrets Manager で生成されたパスワードを取得して code-server に設定しています。 PASSWORD=$(aws secretsmanager get-secret-value --secret-id "${SecretCodeServer.Id}" --region "${AWS::Region}" --query SecretString --output text) # Update code-server config cat <<EOF > /home/ec2-user/.config/code-server/config.yaml bind-addr: 127.0.0.1:8008 auth: password password: ${!PASSWORD} cert: false EOF chown ec2-user:ec2-user /home/ec2-user/.config/code-server/config.yaml tee home/ec2-user/.local/share/code-server/User/settings.json <<EOF { "extensions.autoUpdate": false, "extensions.autoCheckUpdates": false, "terminal.integrated.cwd": "/home/ec2-user/environment", "telemetry.telemetryLevel": "off", "security.workspace.trust.startupPrompt": "never", "security.workspace.trust.enabled": false, "security.workspace.trust.banner": "never", "security.workspace.trust.emptyWindow": false, "editor.indentSize": "tabSize", "editor.tabSize": 2, "python.testing.pytestEnabled": true, "auto-run-command.rules": [ { "command": "workbench.action.terminal.new" } ] } EOF chown ec2-user:ec2-user /home/ec2-user/.local/share/code-server/User/settings.json # Service start systemctl enable --now code-server@ec2-user # Configure nginx tee /etc/nginx/nginx.conf <<EOF user nginx; worker_processes auto; error_log /var/log/nginx/error.log warn; pid /run/nginx.pid; events { worker_connections 1024; } http { include /etc/nginx/mime.types; default_type application/octet-stream; log_format main '\$remote_addr - \$remote_user [\$time_local] "\$request" ' '\$status \$body_bytes_sent "\$http_referer" ' '"\$http_user_agent" "\$http_x_forwarded_for"'; access_log /var/log/nginx/access.log main; sendfile on; keepalive_timeout 65; include /etc/nginx/conf.d/*.conf; server { listen 80; server_name code-server-${SystemName}-${SubName}.${DomainName}; location = /healthcheck.html { empty_gif; access_log off; break; } location /ide${InstanceId}/ { proxy_pass http://localhost:8008/; proxy_set_header Host \$host; proxy_http_version 1.1; proxy_set_header X-Real-IP \$remote_addr; proxy_set_header Upgrade \$http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Accept-Encoding gzip; proxy_set_header X-Forwarded-For \$proxy_add_x_forwarded_for; } } } EOF # Service start systemctl enable --now nginx Tags: - Key: Cost Value: !Sub ${SystemName}-${SubName} - Key: Name Value: !Sub code-server-ide${InstanceId}-${SystemName}-${SubName} DependsOn: - Ec2InstanceProfile # ------------------------------------------------------------# # EC2 Role / Instance Profile (IAM) # ------------------------------------------------------------# Ec2Role: Type: AWS::IAM::Role Metadata: cfn_nag: rules_to_suppress: - id: W11 reason: CodeWhisperer requires '*' as a resource, reference https://docs.aws.amazon.com/codewhisperer/latest/userguide/cloud9-setup.html#codewhisperer-IAM-policies Properties: RoleName: !Sub Ec2Role-code-server-ide${InstanceId}-${SystemName}-${SubName} Description: This role allows EC2 instance to invoke S3 and SSM. AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Principal: Service: - ec2.amazonaws.com Action: - sts:AssumeRole Path: / ManagedPolicyArns: - arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore - arn:aws:iam::aws:policy/AWSCodeCommitPowerUser - arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy Policies: - PolicyName: !Sub CDKAssumeRolePolicy-ide${InstanceId}-${SystemName}-${SubName} PolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Action: - sts:AssumeRole Resource: - !Sub arn:${AWS::Partition}:iam::*:role/cdk-* - PolicyName: !Sub QDeveloperPolicy-ide${InstanceId}-${SystemName}-${SubName} PolicyDocument: Version: "2012-10-17" Statement: - Action: - "codewhisperer:GenerateRecommendations" Resource: "*" Effect: Allow - PolicyName: !Sub Ec2S3Policy-ide${InstanceId}-${SystemName}-${SubName} PolicyDocument: Version: "2012-10-17" Statement: - Action: - "s3:PutObject" - "s3:ListBucket" Resource: - Fn::ImportValue: !Sub S3BucketLogsArn-code-server-${SystemName}-${SubName} - Fn::Join: - "" - - Fn::ImportValue: !Sub S3BucketLogsArn-code-server-${SystemName}-${SubName} - "/*" Effect: Allow - PolicyName: !Sub Ec2SecretsPolicy-ide${InstanceId}-${SystemName}-${SubName} PolicyDocument: Version: "2012-10-17" Statement: - Effect: Allow Action: - secretsmanager:GetResourcePolicy - secretsmanager:GetSecretValue - secretsmanager:DescribeSecret - secretsmanager:ListSecretVersionIds Resource: - !GetAtt SecretCodeServer.Id DependsOn: - SecretCodeServer Ec2InstanceProfile: Type: AWS::IAM::InstanceProfile Properties: InstanceProfileName: !Ref Ec2Role Path: / Roles: - !Ref Ec2Role DependsOn: - Ec2Role # ------------------------------------------------------------# # ALB Target Group / Listener rule # ------------------------------------------------------------# TargetGroup: Type: AWS::ElasticLoadBalancingV2::TargetGroup Properties: VpcId: !Ref VpcId Port: 80 Protocol: HTTP TargetType: instance HealthCheckEnabled: true HealthCheckPath: /healthcheck.html HealthCheckIntervalSeconds: 60 HealthCheckPort: traffic-port HealthCheckProtocol: HTTP HealthCheckTimeoutSeconds: 10 HealthyThresholdCount: 5 UnhealthyThresholdCount: 10 Name: !Sub tg-ide${InstanceId} IpAddressType: ipv4 ProtocolVersion: HTTP1 Targets: - Id: !GetAtt Ec2Instance.InstanceId Port: 80 TargetGroupAttributes: - Key: deregistration_delay.timeout_seconds Value: 30 - Key: stickiness.enabled Value: false - Key: load_balancing.algorithm.type Value: round_robin - Key: slow_start.duration_seconds Value: 0 - Key: stickiness.app_cookie.cookie_name Value: APPCOOKIE - Key: stickiness.app_cookie.duration_seconds Value: 86400 - Key: stickiness.lb_cookie.duration_seconds Value: 86400 Tags: - Key: Cost Value: !Sub ${SystemName}-${SubName} DependsOn: - Ec2Instance ListenerRule: Type: AWS::ElasticLoadBalancingV2::ListenerRule Properties: ListenerArn: Fn::ImportValue: !Sub AlbListenerArn-${SystemName}-${SubName} Priority: !Ref InstanceId Conditions: - Field: path-pattern Values: - !Sub /ide${InstanceId}/* Actions: - Type: forward TargetGroupArn: !Ref TargetGroup DependsOn: - TargetGroup # ------------------------------------------------------------# # Secrets Manager # ------------------------------------------------------------# SecretCodeServer: Type: AWS::SecretsManager::Secret Properties: Name: !Sub code-server-ide${InstanceId}-${SystemName}-${SubName} Description: code-server credential GenerateSecretString: PasswordLength: 8 ExcludePunctuation: true IncludeSpace: false RequireEachIncludedType: true Tags: - Key: Cost Value: !Sub ${SystemName}-${SubName} SecretCodeServerResourcePolicy: Type: AWS::SecretsManager::ResourcePolicy Properties: BlockPublicPolicy: true SecretId: !Ref SecretCodeServer ResourcePolicy: Version: "2012-10-17" Statement: - Effect: Deny Principal: "*" Action: secretsmanager:GetSecretValue Resource: "*" Condition: StringNotEquals: aws:PrincipalArn: - !Sub "arn:aws:iam::${AWS::AccountId}:user/${YourIamUserName}" - !GetAtt Ec2Role.Arn # ------------------------------------------------------------# # Output Parameters # ------------------------------------------------------------# Outputs: CodeServerUrl: Value: Fn::Join: - "" - - Fn::ImportValue: !Sub AlbUrl-${SystemName}-${SubName} - !Sub /ide${InstanceId}/?folder=/home/ec2-user/environment   テンプレート実行後の作業 テンプレートを実行すると、スタックの出力欄に作成した自分用 IDE の URL が表示されます。それにアクセスすると、以下のようにログイン画面が表示されます。 このパスワードは前述の通り AWS Secrets Manager で生成されているので、お手数ですが AWS マネジメントコンソールで自分のシークレットを確認しに行きます。以下のスクリーンショットのようにシークレットの値を表示して確認します。※モザイクかけています。 自分以外の人が作成したシークレットは権限で見ることができなくなっています。 無事ログインが成功すると、以下のように code-server の UI が表示されます。もちろん git が使用できます。npm などで必要なモジュールをインストールして開発していきます。aws cli もインストール済みなので使用できます。   まとめ いかがでしたでしょうか。 3つ目の記事は内容が多く説明を細かく書くときりがなくなってしまい、若干省略してしまいました。大変お手数ですが AWS CloudFormation テンプレートを生成 AI に説明させると細かい説明を聞けると思います。すみません。。。 本記事が皆様のお役に立てれば幸いです。

こんにちは。SCSKの松渕です。 「 Google Cloud Next Tokyo ’25 」で発表された、 AIのオブザーバビリティ に関するセッションをレポート形式でまとめます！ ※ こちらの記事 の続きです。 セッション2: AIエージェント オブザーバビリティの最前線 発表者：DataDog社   オブザーバビリティとは オブザーバビリティとは、システムの外部から得られる情報（出力）から、その システムが今どのような状態にあるのか を深く理解し、推測する能力や仕組みのことです。 日本語では「可観測性」 と訳されます。 従来の「監視（モニタリング）」が、あらかじめ設定した特定の指標（CPU使用率、メモリ使用量など）の閾値を超えた場合にアラートを出すという「結果」に着目するのに対し、 オブザーバビリティは、システム全体から収集した様々なデータを関連付けて分析し、「 なぜ その問題が起きたのか」という 根本原因を探り出す という点で異なります。   セッション内容 早速セッションの中身に入ります！       AIのブラックボックス性 AIエージェントが生成する結果は、ブラックボックスであるという前提のお話から。   AIのブラックボックスを可視化する従来の手法 従来から以下のような手法でブラックボックス部分を可視化/評価をしているが、ブラックボックスは依然残されている状況。 プロンプト管理 プロンプトを複数実行して、結果を比較することで見える化する手法を指してます。 システム監視 AI特有ではなく、既存のシステム監視ですね。基盤となるCloudRun等の監視を指してます。 モデル評価 前の記事 で触れたようなモデル評価を指してます。   AI エージェントの5つの評価観点 AIエージェントの評価観点として5つの観点を上げておりました。 「AIエージェント」に限らず、 生成AI全般に有用 なものだと感じました。 Issue (問題) ユーザーが求める結果が予期せぬ動作で得られなくなる問題について、その原因を特定するために、 トレースやワークフローを中心に、ツールやモデルへの推論プロセスを可視化すること が重要になります。 Performance (パフォーマンス) AIエージェントが ユーザー体験を損なわない水準 で応答できるかについてを評価します。 Quality (品質) 開発者の意図したルールに沿った結果を提供できているかについて、 LLM応答の精度や、事実に基づかない情報を生成してしまう「ハルシネーション」の問題 を含む、ユーザー体験全体を評価します。 Cost (コスト) AIエージェントが自律的にLLM（大規模言語モデル）などを呼び出す際のAPI利用料（トークン消費量）が、当初の計画や予算を超えていないかを評価します。 Safety (安全性) AIエージェントがセキュリティ上の脆弱性とならないよう、不正なコマンドインジェクション（プロンプトインジェクション）や機密データの漏洩を防ぐための対策が講じられているかを評価します。   AI エージェントの評価指標   先ほどの5つの評価観点の 評価指標の説明 がありました。   AI エージェントの評価観点　～Issueについて～ 評価観点のIssue（問題）について ですが、「ハルシネーションの検知」等の AI特有の問題をしっかり可視化 してくれます。 アプリケーション処理のどこの部分で起きているか、視覚的にわかりやすく表示されます。 ハルシネーションの検知方法 内部的にはLLM-as-a-judgeによりハルシネーションかどうかを評価 しているとのこと。 評価用プロンプトもDataDog社のほうで テンプレートが準備 されており、それをカスタマイズして利用するとのことでした。 さらには、 LLM-as-a-judege側の評価が間違っている可能性も考慮されており、LLM-as-a-judge側の出力も可視化の対象 とのことです。関心する一方で、使いこなすのは難しいだろうという印象を受けました。   AI エージェントの評価観点　～Performanceについて～ Performanceの評価観点については、残念ながらスライドの写真が撮れませんでした。しかし、このオブザーバビリティの強みである「ボトルネックの特定」、つまり どの処理で遅延が発生しているかを可視化する機能 が提供されています。特に応答速度が課題となりやすいLLMでは、その効果を最大限に発揮できるはずです。   AI エージェントの評価観点　～Qualityについて～ ハルシネーション含む Quality(品質) の観点としては、デモでは以下4つでした。 言語のミスマッチ　といったものは、 日本などの英語圏ではない国特有 の評価軸だと感じました。 回答精度 ハルシネーション インプットの感情 言語のミスマッチ 回答精度の定義 回答精度については、Ragasによる評価軸を参考にしているとのことでした。 Ragasとは、RAGの評価手法として生まれたものですが、RAG以外でもLLM全般で利用可能な評価手法（およびツール群）になります。    AI エージェントの評価観点　～Costについて～ Cost(料金)については、AI特有の トークン数等もしっかり拾って可視化 してくれます。   AI エージェントの評価観点　～Safetyについて～ Safety(安全性)については、AI特有である プロンプトインジェクション をしっかり検知して可視化しております。   AI “で” 監視する 最後に、今までの　AI “を” 監視する　話から、　AI “で” 監視するための Bits AI というDataDog社のAIエージェントの紹介がありました。 そのBits AI含めた全体像のスライドがこちらになります。   セッション感想 LLM-as-a-judgeやRagasなど、 AIに特化した評価手法が次々と生まれています 。これらは、単にモデルの性能を測るだけでなく、生成物の 品質や安全性を継続的にチェック する上で非常に役立ちます。DataDog社のような専門ツールを使えば、高度な評価も効率的に行え、AIの信頼性を高めていくことができます。 マイクロサービスやオブザーバビリティが注目される昨今、エージェント型AIが普及するにつれて、 オブザーバビリティへの関心はますます高まるはず です。中でも、DataDog社が培ってきたシステム監視のノウハウとAIのオブザーバビリティが統合され、 一つの画面でシームレスに可視化できる という点は、個人的にも大きな魅力だと感じました。 まとめ Google Cloud Next Tokyo ’25への参加を通じて、生成AIを本番運用する上での課題と、それを解決するための具体的なアプローチが鮮明になりました。PoC（概念実証）段階を超え、ビジネスでAIを継続的に活用するためには、 LLMの短いサポート期間や入力データの時間的変化に対応する「LLMOps」が不可欠 です。Google CloudのPrompt OptimizerやVertex AIのようなツールは、このLLMOpsを効率的に進めるための強力な味方となるでしょう。 また、 AIのブラックボックス性を克服する「AIオブザーバビリティ」の重要性 も強く示唆されました。従来のシステム監視に加え、ハルシネーションの検知や回答精度の評価といったAI特有の観点を可視化するDataDog社のソリューションは、AIの信頼性と安全性を高める上で極めて重要です。 本レポートで紹介したように、LLMOpsとAIオブザーバビリティは、変化の激しいAI時代を生き抜くために必要な考えだと感じました。これらの 新しい概念とツールを積極的に取り入れ、AIをより安全かつ効果的に運用していくこと が、今後のビジネス成功の鍵となるでしょう。

こんにちは、SCSKの前田です。 私が携わったLifeKeeperの案件で導入を行ったARKについて紹介をかねてお話したいと思います。 今回は、NFS/HULFT 編と言うことで、Linux 等で利用されるファイル共有システムとマルチプラットフォームに対応したファイル転送ソフトを簡単に冗長化するための ARK の導入事例について、Linux 版をベースにご紹介していきます。 おさらい LifeKeeperのARKについて、おさらいしたいと思います。 ARK とは、Application Recovery Kits の略で、LifeKeeper が特定のアプリケーション（オープンソースソフトウェアや商用アプリケーション）を容易にリソースとして組み込むことが可能になる製品です。 ARK による、アプリケーションのリソースへの組み込みはウィザード形式（GUI上で設定）で作業が可能となり、ARK には、アプリケーションを操作（起動・停止・監視・再起動）するための4つのスクリプトがあらかじめ準備されているため、スクリプトを設計・作成するための開発工数の削減や人的なミスを防止することが出来ます。 概要説明 NFS ARK では、ファイル共有システムであるNFS (Network File System) サービスを、HULFT ARK では、ファイル転送ミドルウェアであるHULFT (ハルフト) を保護対象リソースとして登録し、保護する機能（起動・停止・監視・再起動）を提供します。 ※NFS ARK と HULFT ARK の関連性はありません。それぞれ独立した ARK ですので、複数の ARK を同時にご利用いただくことも、単独でご利用いただくことも可能です。 また、リソースの登録に関しては、必要な項目に対するパラメータをウィザード形式で入力または、選択することでリソースを簡単に作成することが出来ます。 ARK として、それぞれのアプリケーションの処理内容は以下の通りになります。 NFS の処理 処理名 処理内容 起動処理 ①NFSのサービス提供に必要な以下のプロセスの起動を ps コマンドにより確認し、起動していないプロセスの起動を実施 ・rpcbind ・rpc.idmapd ・gssproxy or rpc.svcgssd ・nfsd ・rpc.mountd ②pingnfs コマンドにより疎通確認を行い、疎通出来ない場合は nfsd 停止させ、再起動を実施 ③exportfs コマンドによりエクスポートポイントのエクスポートを実施 ④RESTARTMOUNTD パラメータが「true」の場合、rpc.mountd の再起動を実施 停止処理 ①exportfs コマンドによりエクスポートポイントのアンエクスポートを実施 ②lockd を停止させ、ファイルシステムをアンマウントできるようにファイルロックの解放を実施 監視処理 ①NFSのサービス提供に必要な以下のプロセスの起動を ps コマンドにより確認を実施 ・rpcbind ・rpc.idmapd ・gssproxy or rpc.svcgssd ・nfsd ・rpc.mountd ②pingnfs コマンドにより疎通確認を実施 ③/var/lib/nfs/etab よりエクスポートポイントがエクスポートされていることの確認を実施 ④/var/lib/rpc_pipefs が rpc_pipefs でマウントされていることの確認を実施 再起動処理 起動処理と同一の処理を実施   HULFT の処理 処理名 処理内容 起動処理 HULFTの各デーモン（snd,rcv,obs）の起動確認を行い、停止している場合は各デーモンの起動を実施 停止処理 HULFTの各デーモン（snd,rcv,obs）の起動確認を行い、起動している場合は各デーモンの停止を実施 監視処理 HULFTの各デーモン（snd,rcv,obs）の起動確認を実施 再起動処理 起動処理と同一の処理を実施   NFS ARK/HULFT ARK の構築例 それでは、実際に NFS ARK と HULFT ARK の構築についてお話していきたいと思います。 注意 HULFT ARK では、HULFT を制御する際、HULFT が提供しているクラスタ連携用のコマンドである hulclusterobs、hulclustersnd、hulclusterrcv を利用して、HULFT の起動や停止、状態監視を行います。 そのため、HULFT はクラスタ環境で稼働させるための構成（クラスタ連携用のコマンドが利用出来る構成）にする必要があります。 NFS ARK/HULFT ARK のパラメータ項目 NFS と HULFT のリソース作成時に設定する特有のパラメータを一覧表にまとめました。 NFS ARK のパラメータ 項目 説明 Export Point 次の条件に合致する NFS ファイルシステムのエクスポートポイントを選択 ・エクスポートポイントが NFS によってエクスポートされている ・エクスポートポイントが共有ドライブ上にある ・基礎ファイルシステムが LifeKeeper に保護されている場合、基礎ファイルシステムは In Service で、かつ、 リソース作成時の稼働系サーバー上で最高の優先順位を持っている ・NFS似ルートファイルシステム（fsid=0）としたエクスポートポイント、およびその配下の同一ファイルシステム上のエクスポートポイントは対象外 IP Tag 保護されている NFS ファイルシステムにアクセスするためにクライアントが使用する仮想 IP アドレスのタグ名を選択 HULFT ARK のパラメータ 項目 説明 HULEXEP path HULFTの実行モジュールの格納ディレクトリのパス名を入力 HULPATH path HULFTの環境設定ファイルの格納ディレクトリのパス名を入力 HULFT administrator user name HULFTインスタンスの起動・停止などを行う管理ユーザー名を入力 Filesystem Tag 集信ファイル格納ディレクトリ等の、HULFTと関連付いたFileSystemリソース名を選択 NFS/HULFT リソースの作成 NFS と HULFT のリソースを LifeKeeper の GUI によって作成する流れを例として紹介します。 NFS リソースの作成 処理内容 GUI画面例 リソース作成前のツリー構造 保護アプリケーションの選択（NFS） 稼働系ノードのSwitchbackタイプの選択 ※デフォルト：intelligent 稼働系ノードの選択 保護する共有ディスク上のマウントポイントの選択 使用する仮想IPアドレスのリソース名の選択 稼働系ノードの管理GUIに表示されるリソースタグ名の入力 稼働系ノードのリソース作成結果 待機系ノードの選択 待機系ノードのSwitchbackタイプの選択 ※デフォルト：intelligent 稼働系ノードの優先順位の設定 ※デフォルト：1 待機系ノードの優先順位の設定 ※デフォルト：10 待機系ノードのリソース作成準備の確認結果 待機系ノードの管理GUIに表示されるリソースタグ名の入力 待機系ノードのリソース作成結果 リソース作成後のツリー構造（NFS リソースと IP リソースとレプリケーションリソースの依存関係が自動で作成される） これで、LifeKeeper による NFS のリソースが完成です。 HULFT リソースの作成 処理内容 GUI画面例 リソース作成前のツリー構造 保護アプリケーションの選択（HULFT） 稼働系ノードのSwitchbackタイプの選択 ※デフォルト：intelligent 稼働系ノードの選択 HULFT 実行モジュール格納ディレクトリのパス名の入力 HULFT 環境設定ファイル格納ディレクトリの入力 HULFT インスタンスの管理ユーザー名の入力 HULFT リソースと関連付けたい ファイルシステム リソースの選択（例では、不要のため「none」を選択） 稼働系ノードのHULFT リソース階層に付けるタグ名の入力 ※デフォルト：hulft 稼働系ノードのリソース作成結果 待機系ノードの選択 待機系ノードのSwitchbackタイプの選択 ※デフォルト：intelligent 稼働系ノードの優先順位の設定 ※デフォルト：1 待機系ノードの優先順位の設定 ※デフォルト：10 待機系ノードのリソース作成準備の確認結果 待機系ノードのHULFT リソース階層に付けるタグ名の入力 ※デフォルト：hulft 待機系ノードのリソース作成結果 リソース作成後のツリー構造（HULFT リソースとレプリケーションリソース・IP リソースの依存関係が自動で作成される） ツリー構造の整理（複雑なツリー構造を簡潔に整理） これで、LifeKeeper による HULFT のリソースが完成です。 まとめ 今回は LifeKeeper ARK の導入事例と言うことで、NFS と HULFT のリソース作成について紹介してみました。 LifeKeeper ARK を購入することで、正式なサポートを受けられるほか、LifeKeeper として操作（起動・停止・監視・再起動）するためのスクリプトを準備する必要がなく、GUI 画面にてNFS 及び HULFT を構成する設定内容を選択または入力することで簡単にリソースとして導入が可能となっています。 LifeKeeper では NFS や HULFT 以外にも多数の ARK が用意されていますので、また次の機会に別の ARK について紹介していきたいと思います。 最後に NFS 及び HULFT ARK を導入するための手順を纏めます。 ・NFS 及び HULFT のリソース固有のパラメータの設定値を決定する ・LifeKeeper GUI を用いて、NFS 及び HULFT のリソースを作成する ・必要に応じてリソース構造を修正する その他 ARK の導入事例に関しては以下のリンクからどうぞ！ LifeKeeper ARK の導入事例を紹介＜JP1/AJS3編＞ – TechHarmony LifeKeeper ARK の導入事例を紹介＜Oracle編＞ – TechHarmony LifeKeeper ARK の導入事例を紹介＜SQL Server編＞ – TechHarmony 詳しい内容をお知りになりたいかたは、以下のバナーからSCSK LifeKeeper公式サイトまで

本記事は 夏休みクラウド自由研究2025 8/14付の記事です 。 世界の国からこんにちは。masedatiです。好きな音楽は、椎名林檎 と ずっと真夜中でいいのに。 です。 今回は、 AWSが発表した次世代エージェント型IDE「Kiro」 を実際に触ってみて、Webアプリケーションを自由工作してみた体験記となります。 👻 Kiroって何？ 生成AIの話題が尽きない中、皆さんKiroを触ってみましたでしょうか？ （Kiroで遊ぶことを、私は勝手に「ゴーストダイブ」と呼んでいます） Kiro は、AIエージェントと協調しながら動作する次世代のエージェント型IDE（統合開発環境）で、開発プロセスを「プロンプト → プロトタイプ → プロダクション」へとシームレスに進化させます 。「vibe coding」での課題であった「実運用への移行への設計の不確実性やドキュメントの欠如」を解決します。最大の特徴は、「 Specによる仕様駆動開発 」と「 Hookによる自動化アシスト 」です。 Specはプロンプトから自動でユーザーストーリーや受け入れテスト基準を含む仕様書（スペック）を生成し、Hookによってコードの保存、作成、削除などのタイミングでドキュメントの更新やテスト追加などを自動化を行います。その仕様をもとに、設計や実装のタスクを構造的に自動生成してくれるのが、「 Kiro 」です。 詳細は AWS公式ブログ をご参考ください。 🎯 本記事の要約 いきなりですが、本記事少し長くなるので、以下要約です。 開発未経験のインフラエンジニアでもKiroを使って、簡単なWebアプリを作ることができた KiroのSpecsモードを活用することで、現場に近い仕様駆動開発を体験できた 各工程で感じたメリット 要件フェーズ 作りたいものに基づく要件の言語化・詳細化と受け入れ基準の自動作成 詳細フェーズ 構成提案やフロー図作成、エラー処理・テスト方針の自動生成 実装計画&構築フェーズ タスクに沿った自動構築、エラー発生時の修正提案、ビルド・テスト自動実行 デプロイ CloudFormationを用いた一貫性のあるデプロイ デプロイ時のエラーもログ情報から原因特定し、自動で修正 🎮️ 遊んでみた。 作りたいものを整理する 私は普段、好きな音楽をSpotifyのプレイリストに保存しています。 1つのプレイリストに追加し続けていった結果、現在1010曲と膨大な曲数となってしまいました。 そのため、その日の気分にあった最適な音楽を探すのに時間がかかっています。次の曲へ…次の曲へ…スキップする毎日。 ＿人人人人人人人人人人＿ ＞　これを解決したい　＜ ￣Y^Y^Y^Y^Y^Y^Y^Y^Y￣ そこで、 気分に合わせてSpotifyのプレイリストから打線形式で9曲を選び出すWebアプリ を作成します。 Specモードで要件定義から構築まで一気通貫 要件フェーズ 私の要望を以下にまとめました。 # 背景・目的 現在、Spotifyの1つのプレイリストに約1000曲を追加しており、膨大な曲数の中からその日の気分に合う曲を選ぶのが大変。 そのため、気分に応じた「打線形式」での楽曲レコメンドを自動化する、WebアプリケーションPoCを作成したい。 # PoC仕様 * 対象データ Spotifyの固定IDのプレイリスト（ユーザー本人のもの） * 気分の入力方法 ラジオボタン形式で選択（例：「元気」「落ち込んでいる」「悲しい」など） * レコメンドロジック Spotify APIで取得できる楽曲メタデータを活用 * 出力形式 打線形式で9曲を選出し、Spotify埋め込みプレイヤーで表示 * 打線の生成方法 AWS Bedrockを活用し、曲リストからポジション付きで打順を生成 * 想定ユーザー 開発者本人のみ（PoC目的） # 想定AWS構成（フルサーバレス） * フロントエンド Amazon S3 + CloudFront * バックエンドAPI API Gateway + AWS Lambda * 打線形式の生成（自然言語による楽曲選出と順番付け） AWS Bedrock 上記をそのまま最初のプロンプトとしてKiroに投げてみます。 数秒 で以下のような 要件定義書 っぽいものを作成してくれました。 requirements.md # 要件定義書 ## 概要 この機能は、ユーザーの現在の気分に基づいてSpotifyプレイリストから野球の打線形式で楽曲推薦を生成するWebアプリケーションを作成します。 システムは固定のSpotifyプレイリストに存在する約1000曲を分析し、ユーザーがラジオボタンで気分を選択できるようにし、AWS Bedrockを使用して9曲を野球の打順形式でインテリジェントに配置し、埋め込みSpotifyプレイヤーで即座に再生できるようにします。 ## 要件 ### 要件1 **ユーザーストーリー:** 音楽リスナーとして、事前定義された選択肢から現在の気分を選択したい。そうすることで、自分の気持ちに合ったパーソナライズされた楽曲推薦を受けることができる。 #### 受入基準 1. ユーザーがアプリケーションにアクセスした時、システムはラジオボタンオプション付きの気分選択インターフェースを表示する 2. ユーザーが気分オプションを表示した時、システムは「元気」「落ち込んでいる」「悲しい」およびその他の関連する気分を含む少なくとも4つの異なる気分カテゴリを提供する 3. ユーザーが気分オプションを選択した時、システムは選択された選択肢をハイライトし、推薦生成を有効にする 4. 気分が選択されていない場合、システムは推薦生成ボタンを無効にする ### 要件2 **ユーザーストーリー:** 音楽リスナーとして、システムに既存のSpotifyプレイリストを分析してもらいたい。そうすることで、すでに知っていて好きな曲から推薦を受けることができる。 #### 受入基準 1. システムが初期化された時、有効な認証情報を使用してSpotify APIに接続する 2. Spotifyに接続する時、システムは特定の事前定義されたプレイリストIDから楽曲を取得する 3. プレイリストデータを取得する時、システムはオーディオ機能、アーティスト情報、トラック詳細を含む楽曲メタデータを取得する 4. プレイリストに1000曲以上含まれている場合、システムは利用可能なすべての楽曲を処理する 5. APIエラーが発生した時、システムは適切なエラーメッセージと再試行メカニズムを表示する ### 要件3 **ユーザーストーリー:** 音楽リスナーとして、野球の打順形式で配置された9曲の推薦を受けたい。そうすることで、楽しく構造化された方法で音楽を体験できる。 #### 受入基準 1. ユーザーが推薦をリクエストした時、システムは正確に9曲を選択して生成する 2. 推薦を生成する時、システムはAWS Bedrockを使用して楽曲メタデータを分析し、選択された気分に楽曲をマッチングする 3. 楽曲を配置する時、システムは各楽曲を戦略的な理由付きで特定の打順ポジション（1番から9番）に割り当てる 4. 結果を表示する時、システムは各楽曲を打順ポジション、楽曲タイトル、アーティスト、埋め込みSpotifyプレイヤーと共に表示する 5. Bedrock分析が失敗した場合、システムはルールベースの推薦システムにフォールバックする ### 要件4 **ユーザーストーリー:** 音楽リスナーとして、推薦された楽曲をインターフェース内で直接再生したい。そうすることで、推薦をすぐに聴いて評価できる。 #### 受入基準 1. 推薦が表示された時、各楽曲は機能的なSpotify埋め込みプレイヤーを含む 2. ユーザーが埋め込みプレイヤーの再生をクリックした時、楽曲はすぐに再生を開始する 3. 複数のプレイヤーが存在する時、一度に1曲のみが再生される（他は自動一時停止） 4. 楽曲のSpotify埋め込みが失敗した場合、システムはSpotifyで開くリンク付きの楽曲情報を表示する ### 要件5 **ユーザーストーリー:** このPoCをデプロイする開発者として、アプリケーションをAWSサーバーレスインフラストラクチャで実行したい。そうすることで、運用オーバーヘッドとコストを最小化できる。 #### 受入基準 1. フロントエンドをデプロイする時、システムはCloudFrontディストリビューション付きのAmazon S3を静的ホスティングに使用する 2. APIリクエストを処理する時、システムはAWS Lambda関数付きのAPI Gatewayを使用する 3. 推薦を生成する時、システムはAI駆動の楽曲分析と打線生成のためにAWS Bedrockと統合する 4. システムがアイドル状態の時、サーバーレスアーキテクチャにより最小限のコストが発生する 5. いずれかのAWSサービスが利用できない場合、システムは適切な劣化とエラーハンドリングを提供する ユーザーストーリーと受け入れ基準が明確になり、初期段階で「完了の定義」が揃います。 なんとなく良さそうです！そのまま設計に進もうと思います。 設計フェーズ requirements.mdに問題なければ、「 Move to design phase 」ボタンを押せばKiroは設計に進みます。 以下Kiroが考えた設計書です。 design.md( 一部抜粋 ) # 設計文書 ## 概要 Spotify気分別打線推薦システムは、ユーザーの気分に基づいてSpotifyプレイリストから9曲を野球の打線形式で推薦するWebアプリケーションです。 フロントエンドはReactとTypeScriptで動作し、バックエンドはAWSサーバーレス構成で実装されます。 ## アーキテクチャ ### システム全体構成 ```mermaid graph TB subgraph "AWS Cloud" CF[CloudFront Distribution] S3[S3 Static Hosting<br/>React Frontend] AG[API Gateway] LF1[Lambda Function<br/>Playlist Fetcher] LF2[Lambda Function<br/>Recommendation Engine] BR[AWS Bedrock<br/>Claude/GPT] end subgraph "外部API" SP[Spotify Web API] end CF --> S3 S3 --> AG AG --> LF1 AG --> LF2 LF1 --> SP LF2 --> BR LF2 --> SP ## テスト戦略 ### フロントエンドテスト 1. **単体テスト**: Jest + React Testing Library - コンポーネントレンダリング - ユーザーインタラクション - 状態管理 2. **統合テスト**: - API通信モック - エラーハンドリング - ローディング状態 ## パフォーマンス最適化 ### フロントエンド最適化 1. **コード分割**: React.lazy()による動的インポート 2. **メモ化**: React.memo()とuseMemo() 3. **画像最適化**: WebP形式とlazy loading 4. **CloudFront最適化**: - Gzip圧縮有効化 - キャッシュ戦略設定 - エッジロケーション活用 ### 監視とログ 1. **CloudWatch**: Lambda実行時間とエラー率 2. **フロントエンド**: パフォーマンス指標収集 3. **アラート**: 異常検知と通知 mermaidでのシステム構成フロー作成からパフォーマンス、セキュリティ設計やテスト方針まで考えてくれています。 【参考】mermaidでのシステム構成フロー図 実施計画フェーズ 「 Move to implementation plan 」ボタンを押せば、Kiroは実施計画作成に進みます。 実施計画とは、構築手順から統合テスト、デプロイ方法等いわばタスクリストのようなものです。 以下のようなものとなりました。 tasks.md( 一部抜粋 ) ⚡️Start task [ ] 1. プロジェクト構造とコア設定のセットアップ - Reactプロジェクトの初期化とTypeScript設定 - AWS CDKプロジェクトの初期化とディレクトリ構造作成 - 環境変数管理とSpotify API認証情報設定 - _要件: 2.1, 5.2_ ⚡️Start task [ ] 3. Spotify API統合の実装 - [ ] 3.1 Spotify認証とプレイリスト取得Lambda関数の作成 - OAuth 2.0 Client Credentials Flowの実装 - プレイリストデータ取得機能の実装 - オーディオ特徴量取得機能の実装 - _要件: 2.1, 2.2, 2.3_ - [ ] 3.2 Spotify API統合のテスト作成 　- Lambda関数の単体テスト実装 　- モックデータを使用したテストケース作成 　- エラーハンドリングのテスト 　- _要件: 2.5_ ⚡️Start task [ ] 4. AWS Bedrock推薦エンジンの実装 - [ ] 4.1 Bedrock統合Lambda関数の作成 　- AWS Bedrock Claude/GPTとの統合実装 　- 気分ベース楽曲分析ロジックの実装 　- 打線形式での楽曲配置ロジックの実装 　- _要件: 3.1, 3.2, 3.3_ - [ ] 4.2 ルールベースフォールバック機能の実装 　- Bedrock障害時の代替推薦ロジック作成 　- 気分マッピングに基づく楽曲フィルタリング実装 　- 打順ポジション割り当てアルゴリズムの実装 　- _要件: 3.5_ - [ ] 4.3 推薦エンジンのテスト作成 　- Bedrock統合の単体テスト実装 　- フォールバック機能のテスト 　- 推薦結果の妥当性検証テスト 　- _要件: 3.1, 3.5_ ⚡️Start task [ ] 10. 統合テストとエンドツーエンドテストの実装 - [ ] 10.1 フロントエンド統合テストの作成 　- コンポーネント間連携テスト 　- API通信モックテスト 　- ユーザーフロー全体のテスト 　- _要件: 1.1, 3.1, 4.1_ ⚡️Start task [ ] 11. パフォーマンス最適化の実装 - [ ] 11.1 フロントエンド最適化 　- React.lazy()による動的インポート実装 　- メモ化（React.memo, useMemo）の適用 　- バンドルサイズ最適化 　- _要件: 6.2, 6.3_ - [ ] 11.2 バックエンド最適化 　- Lambda関数のコールドスタート最適化 　- 接続プーリングの実装 　- レスポンス時間改善 　- _要件: 6.2_ ⚡️Start task [ ] 12. 最終統合とデプロイメント [ ] 12.1 本番環境デプロイメント 　- CDKスタックの本番デプロイ実行 　- 環境変数と認証情報の本番設定 　- DNS設定とドメイン設定（オプション） 　- _要件: 5.1, 5.2, 5.4_ [] 12.2 動作確認とテスト実行 　- 全機能の動作確認テスト 　- パフォーマンステスト実行 　- エラーケースの検証 　- _要件: 1.1, 2.1, 3.1, 4.1, 6.2_ 要件とリンクした形で実装タスクが 12段階で細分化 され、生成AIがこれからどのように構築を実行しようとしているのか一目でわかります。 また、Task 3, 4のように各Taskごとにテスト工程が実施されます。このように単体テストや統合テスト、API通信テスト等の テストファイル作成・実施・修正 を自動でKiroが行ってくれるのも大きな魅力の一つ です。 開発構築フェーズ あとは実施計画に基づいて開発構築を進めるだけです。tasks.md上の 「⚡️Start task」ボタンを押すだけでステップバイステップで構築 を進めることができます。 各タスクが完了すると✔️Task completedとなります。例えば、Task 1が完了すると以下のようにKiroから報告があがります。 ✔ Task completed - [x] 1. プロジェクト構造とコア設定のセットアップ - Reactプロジェクトの初期化とTypeScript設定 - AWS CDKプロジェクトの初期化とディレクトリ構造作成 - 環境変数管理とSpotify API認証情報設定 - _要件: 2.1, 5.2_ ✅ 完了したサブタスク： 1. Reactプロジェクトの初期化とTypeScript設定 ・frontend/ディレクトリにReact + TypeScriptプロジェクトを作成 ・必要な依存関係（axios）をインストール ・TypeScript設定ファイル（tsconfig.json）が自動生成 2. AWS CDKプロジェクトの初期化とディレクトリ構造作成 ・infrastructure/ディレクトリにCDKプロジェクトを初期化 ・backend/ディレクトリ構造を作成（lambda, types, utils） ・バックエンド用のpackage.jsonとtsconfig.jsonを設定 ・必要な依存関係をインストール 3. 環境変数管理とSpotify API認証情報設定 ・プロジェクトルートに.env.exampleを作成 ・フロントエンド用の.env.exampleを作成 ・Spotify API認証情報の設定項目を定義 ・AWS設定項目を定義 📁 作成されたプロジェクト構造： ├── frontend/ # React + TypeScript (完了) ├── backend/ # Lambda関数用コード (構造作成完了) │ ├── src/ │ │ ├── lambda/ # Lambda関数 │ │ ├── types/ # TypeScript型定義 (基本型作成完了) │ │ └── utils/ # ユーティリティ関数 ├── infrastructure/ # AWS CDK (初期化完了) ├── .env.example # 環境変数設定例 (完了) ├── .gitignore # Git設定 (完了) └── README.md # プロジェクト説明 (完了) たとえ、Taskでの構築やテスト工程でにエラーが出力されたとしても Kiroは自身でエラー原因を特定し、修正 します。 開発知識が不足している私でもスムーズに工程を進めることができました。 そして本番デプロイへ Task 12終了時のKiroからのメッセージは以下です。 タスク12「最終統合とデプロイメント」完了！ タスク12の両方のサブタスクを完了しました： ✅ 12.1 本番環境デプロイメント 以下のスクリプトとツールを作成しました： deploy-production.sh - 包括的な本番デプロイメントスクリプト 環境変数の検証 バックエンド・フロントエンド・インフラのビルドとテスト CDKを使用したAWSリソースのデプロイ フロントエンドのS3アップロードとCloudFront無効化 setup-production-env.sh - 環境変数設定支援スクリプト Spotify認証情報の対話的設定 AWS設定の構成 セキュリティベストプラクティスの適用 setup-custom-domain.sh - カスタムドメイン設定スクリプト（オプション） Route 53とACM証明書の設定支援 CloudFrontカスタムドメイン設定 ✅ 12.2 動作確認とテスト実行 包括的なテストスイートを作成しました： comprehensive-test.sh - 全機能の動作確認 ユニットテストとインテグレーションテスト API機能テスト フロントエンドテスト セキュリティテスト モニタリング確認 performance-test.sh - パフォーマンステスト レスポンス時間測定 同時リクエスト処理テスト スループットテスト リソース使用量分析 コールドスタート分析 error-case-test.sh - エラーケース検証 無効なパラメータテスト HTTPメソッドエラーテスト レート制限テスト セキュリティ攻撃テスト エッジケーステスト run-all-tests.sh - マスターテストランナー 全テストスイートの統合実行 詳細なレポート生成 結果の集約と分析 quick-verification.sh - クイック検証スクリプト デプロイ後の基本動作確認 スモークテスト 🎯 要件対応状況 要件5.1, 5.2, 5.4（本番環境デプロイ）: ✅ CDKスタックの本番デプロイ実行 ✅ 環境変数と認証情報の本番設定 ✅ DNS設定とドメイン設定（オプション対応） 要件1.1, 2.1, 3.1, 4.1, 6.2（動作確認）: ✅ 全機能の動作確認テスト ✅ パフォーマンステスト実行 ✅ エラーケースの検証 🚀 次のステップ 本番デプロイメントを実行するには： 環境設定: ./setup-production-env.sh デプロイ実行: ./deploy-production.sh 動作確認: ./quick-verification.sh 包括的テスト: ./run-all-tests.sh これでSpotify Mood Lineupアプリケーションの本番環境への完全なデプロイメントと検証が可能になりました！ 今回本番デプロイは、環境設定⇒デプロイ実行⇒動作確認⇒包括的テストの順番でスクリプトを実施すればよさそうです。 環境設定スクリプトでは、デプロイ先のAWSアカウントやSpotify Playlist ID等を入力しました。 🎉 完成 前述のスクリプト実施時にいくつかのエラー ※ が発生し、すぐにデプロイ完了とはならなかったのですが、Kiroとの対話を重ねることで無事Webアプリケーションの動作を確認することができました！ 最初のプロンプトに記載のとおり、「気分の入力方法⇒ラジオボタン形式で選択（例：「元気」「落ち込んでいる」「悲しい」など）」が実装されています。 「打線を生成する」ボタンを押すと。。。 本日の気分に基づきスタメンが発表されます。   それでは、「元気」なメンバーを紹介して終わりにしようと思います。 1 中 フラットウッズのモンスターみたいに（Eve, Deu） 2 二 フロントメモリー - の子vo.ver（Shinsei Kamattechan） 3 遊 ミッドナイト・リフレクション（NOMELON NOLEMON） 4 左 海馬成長痛（ZUTOMAYO） 5 一 夢（The Rolling Girls） 6 三 勝手にシンドバッド（サザンオールスターズ） 7 捕 ゴーストダイブ（POLKADOT STINGRAY） 8 右 ミス・パラレルワールド （Soutaiseiriron） 9 投 お勉強しといてよ（ZUTOMAYO） まとめ アプリ開発未経験者が数時間でここまで構築することができました！ これは業務で取り入れたら、開発速度が爆速になりそうです。 しかし、改めて私の開発知識の無さを痛感しました。（恥ずかしながらKiroが何をやっているのか理解できていない…） 今回は生成AIを全面的に信頼しましたが、本来であれば要件定義・設計書・実施計画・詳細手順の正否は人間が判断を行うべきと考えています。 何が正しくて、何が誤っているのか、判断できるよう引き続き研鑽を積みたいと思います。 Appendix アーキテクチャ図 Kiroは「Claude Sonnet 3.7/4.0」で動いており、指示を出せばアーキテクチャ図出力も可能です。 以下はClaude Sonnet 4.0が作成したアーキテクチャ図となります。（修正なし） Amazon CloudFrontの色が公式と異なるといった点など修正ポイントはありますが、綺麗なアーキテクチャ図を生成してくれました。 デプロイスクリプトでのエラーについて 本番デプロイの際に判明したのですが、楽曲の雰囲気情報（danceability、acousticness など）を取得できる Spotify API（audio_features）が、2024年11月に廃止されていました。 Introducing some changes to our Web API To increase security we are limiting access to certain Web API endpoints for new applications. developer.spotify.com この情報は Kiro 側でも把握されておらず、原因不明のエラーとして私を悩ませることに。今回の本番デプロイでは、雰囲気パラメータを一時的にランダムな数値に置き換えて対応しました。 せっかく作成したアプリなので、今後は代替策を探りつつ、Kiro 側が提示した要件定義や設計書はやはりレビューしておくべきだと強く感じた出来事でした。

こんにちは、SCSKの坂木です。 Zabbixには、 サポート期間 があることをご存知でしょうか？ Zabbixを安心して利用し続けるためには、サポート期間を把握し、適切なバージョンアップを行うことが必要不可欠です。 そして、 Zabbix4.0の延長サポートが2025年10月をもって終了 します。 安定運用を継続するため、Zabbix4.0の利用者は速やかにサポート対象のバージョンへアップデートすることが重要となります。   サポートの種類について Zabbixのサポートには、３種類のサポートがあります。 今回、Zabbix4.0で終了するサポートは、 延長サポート となります。延長サポート含めそれぞれの概要を説明します。　　　　　　　　　（期間は、最もサポート期間が長いLTSバージョンのものを記載してます） フルサポート 期間 バージョンのリリースから3年間 対応内容 インストール方法、使用方法、設定方法に関するお問い合わせ 問題の原因調査・分析 すべてのレベルのバグ修正 機能改善要望への対応   リミテッドサポート 期間 フルサポート終了から2年間 対応内容 インストール方法、使用方法、設定方法に関するお問い合わせ 問題の原因調査・分析 深刻度の高いバグの修正 セキュリティフィックス   延長サポート 期間 リミテッドサポート終了から2年間 対応内容 インストール方法、使用方法、設定方法に関するお問い合わせ 問題の原因調査・分析 なお、対応内容に記載のお問い合わせや問題の調査に関しては、 有償のEnterpriseサポートに 加入する必要があります。弊社でもEnterpriseサポートを取り扱っておりますので、詳細は以下のページを御参照ください。 サービス内容｜SCSK Plus サポート for Zabbix SCSKが提供するZabbixサポートサービスの内容を紹介したページです。世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします。 www.scsk.jp   バージョンアップ先 アップデート先のバージョンは、サポート期間が最も長い 最新のLTSバージョン を推奨しています。 そのため、現在は最新のLTS版である Zabbix 7.0 LTS へのアップデートが最適です。（2025/08時点） ちなみに、各バージョンのサポート期間は下表のとおりです。（サポートが継続されているLTSバージョンのみ） バージョン リリース フルサポート終了 リミテッドサポート終了 延長サポート終了 Zabbix 7.0 LTS 2024/6 2027/6 2029/6 2031/6 Zabbix 6.0 LTS 2022/2 2025/2 2027/2 2029/2 Zabbix 5.0 LTS 2020/5 2023/5 2025/5 2027/5 Zabbix 4.0 LTS 2018/10 2021/10 2023/10 2025/10   さいごに 本ブログでは、Zabbix4.0の延長サポートが2025年10月をもって終了することと、Zabbixサポートの概要を紹介しました。 改めてにはなりますが、Zabbix4.0利用者はお早めのバージョンアップをご検討ください。 弊社では、バージョンアップの支援を行っております。 バージョンアップのやり方が不明な方や、自社だけでのバージョンアップに不安のある方は、是非弊社までお声がけください！ ↓お問い合わせはこちらから↓ お問い合わせ 製品・サービスについて 入力 ｜ SCSK株式会社 SCSK株式会社 製品・サービスについてご意見・ご質問をお受けしております。 www.scsk.jp

こんにちは。SCSKの磯野です。 BigQueryでDELETE文を実行する際のスキャン量を調査しました。 特にdataformではDELETE&INSERTでデータを更新するケースもあると思います。DELETE時の不要なスキャン量を削減できないかと、本調査を行いました。 結論 パーティションまるごとDELETEする場合は、スキャン量はかかりません。 料金  |  BigQuery: Cloud Data Warehouse  |  Google Cloud BigQuery の料金を確認する cloud.google.com データセットやテーブルの削除、個々のテーブル パーティションの削除、ビューの削除、ユーザー定義関数の削除に対しては課金されません。 スキャン量がかかるケース WHERE句の書き方によってはスキャン量が発生してしまうので注意が必要です。 例）datetimeというカラムに対してWHERE句を記載 スキャン量ゼロ DELETE `table名 ` WHERE datetime >= DATETIME ( "2019-07-07 0:00:00" ) AND datetime < DATETIME ( "2019-07-08 0:00:00" ) スキャン量発生 DELETE `table名 ` WHERE datetime BETWEEN DATETIME ( "2019-07-07" ) AND datetime ( "2019-07-07 23:59:59" ) ; →”2019-07-07 23:59:59.001″等のデータが存在する可能性があり、パーティション全体をカバーしていない。BigQueryはパーティション内の各行をスキャンして条件に合致するかを調べる必要があり、スキャン量が発生してしまう。 結論：WHERE句はパーティション単位で指定する パーティション全体をカバーするために、DATETIMEでWHERE句を記載するのではなく、パーティションの単位（下記例の場合はDATE）でWHERE句を記載するとよい。下記の記載方法であれば、スキャン量はゼロ。 DELETE `table名 `   WHERE DATE (datetime ) BETWEEN DATE ( "2019-07-07" ) AND DATE ( "2019-07-07 23:59:59" ) ; 参考：SELECTであればどちらも同じスキャン量 DELETE文の場合は、WHERE句の書き方でスキャン量が変わりましたが、SELECT文の場合は下記いずれもスキャン量は一致していました。 SELECT * FROM `table名 ` WHERE datetime >= DATETIME ( "2019-07-07 0:00:00" ) AND datetime < DATETIME ( "2019-07-08 0:00:00" ) SELECT * FROM `table名 ` WHERE datetime BETWEEN DATETIME ( "2019-07-07" ) AND datetime ( "2019-07-07 23:59:59" ) ; まとめ いかがだったでしょうか。 今回は、DELETE時の不要なスキャン量を削減するためのWHERE句の書き方をご紹介しました。 本記事が参考になれば幸いです。

こんにちは。SCSKの磯野です。 Cloud Run jobsを利用するにあたり、VPC/NAT/IPアドレスの作成単位や設計に迷ったので、当チームで最終的に採用したものをご紹介します。 なぜ（Why） その方針としたのか、 どのように（How） 実装したのか、という2つの観点で記載しています。 前提 当チームに存在するCloud Run jobsの種類 当チームでは、Cloud Run jobsを用いて外部からのデータ取得を行っています。一般公開されているデータから、購入しているデータまで、さまざまなデータをAPIやスクレイピングを通して取得しています。 アクセス先の外部サービスによっては接続元のIPアドレスを固定する必要があるため、当チームのCloud Run jobsには以下の2種類が存在します。 静的外部IPアドレスが 必要 なCloud Run jobs 静的外部IPアドレスが 不要 なCloud Run jobs 当チームの環境 dev/stg/prdの3環境で構成されています。   NW設計方針 共有VPCを利用 Why？（なぜその方針としたか） 組織全体に対するルートやファイアウォール、 サブネット IP アドレス範囲、VPN 接続などの作成を一元管理するため、共有VPCを利用しています。 How？（どのように実装したか） 公式ドキュメントを参照ください。 共有 VPC  |  Google Cloud 共有 VPC を使用して、別々の Google Cloud プロジェクトにある Virtual Private Cloud（VPC）ネットワークに接続する方法について説明します。 cloud.google.com Cloud Runからの egress（外向き）通信をNAT経由とする Why？（なぜその方針としたか） 「前提」に記載した通り、外部サービス側にて静的外部IPアドレスのホワイトリスト登録が必要なケースがあります。 静的外部IPアドレスを設定するためには、NAT経由の通信とする必要がありました。 一方で、 静的外部IPアドレスが不要なCloud Runについても、NAT経由の通信を採用 しています。理由は以下の通りです。 ソースIP/ポート枯渇を避けられる ( 参考 ) Cloud Runから大量の同時接続が必要な場合、NATに外部IPを追加してポート数を増やすことができるため。NATを経由しない場合は、IP/ポートを調整不可のため、枯渇する可能性があり。 egressをNAT経由にする=VPC経由となるので、Google/Google Cloud APIへの通信をGoogleのネットワーク内に閉じることが可能。スループット/セキュリティ面の向上につながる。 ログ分析と監査の容易さ 全ての通信がNATを経由することで、外部向け通信とログ確認や監査がしやすくなる (接続不可時のトラフィック状況の確認や、コードベースを乗っ取られデータ漏洩していることの確認等)。 How？（どのように実装したか） Cloud Run サービスまたはジョブから VPC ネットワークに下り（外向き）トラフィックを送信する方法としては、以下の2種類があります。 ダイレクト VPC 下り（外向き） （推奨） サーバーレス VPC アクセス コネクタ ダイレクト VPC 下り（外向き）と VPC コネクタの比較  |  Cloud Run Documentation  |  Google Cloud cloud.google.com 費用・パフォーマンスの観点から 「ダイレクト VPC 下り（外向き）」 を採用していますが、執筆時点ではCloud Run ジョブにおける「ダイレクト VPC 下り（外向き）」は プレビュー版 です。利用の際はご注意ください。 静的外部IPアドレスの作成単位：原則、環境ごと（dev/stg/prd）に分離する Why？（なぜその方針としたか） devからの通信が多すぎることでNATのポートが枯渇し、prdの通信ができなくなることを防ぐため、静的外部IPアドレスは環境ごとに（dev/stg/prd）に分離しています。 費用の観点から用途ごとには分けず、チーム全体で共通のIPアドレスを使用する サービスによっては登録できるIPアドレス数が限られているため、状況に応じてdev/stg/prdで同じIPを使用しています。 How？（どのように実装したか） Cloud Run jobsで静的外部IPアドレスを設定する方法は、下記の記事を参照ください。 NATの作成単位：静的外部IPアドレスの要否・環境(dev/stg/prd)を考慮した計4つとする NATの作成単位は以下の4つとしました。 静的外部IPアドレスが不要なCloud Run用のNAT：1つ 静的外部IPアドレスが必要なCloud Run用のNAT：各環境（dev/stg/prd）ごとに1つずつ 「静的外部IPアドレスが必要なCloud Run用のNAT」を以下①②のどちらのパターンとするか迷ったのですが、 ①を採用 しました。サブネットは用途ごとに分けているため、それぞれのNATに複数のサブネットが紐づくイメージとなります ①「静的外部IPアドレスが必要なCloud Run用のNAT」を環境ごとに分ける。 ②「静的外部IPアドレスが必要なCloud Run用のNAT」を全環境で共通とする。前述の通り、静的外部IPアドレスは環境ごとに作成するため、本パターンの場合は、1つのNATに複数のIPアドレスを紐づける形式となる。（技術的には可能） Why？（なぜその方針としたか） 1つのNATにdev/stg/prdのIPを紐づけた場合に下記課題が発生するため、②は不採用としました。 Cloud Runで指定できるのはsubnetだけであり、静的外部IPアドレスを直接指定することはできない。 subnetと固定IPは紐づいていない。固定IPと紐づいているのはNATだけ →よって、Cloud Run側でdevのsubnetを指定しても、どの環境（dev/stg/prd）の静的外部IPアドレスが使われるかわからない。環境分離ができなくなってしまうため、②は不採用とする。 How？（どのように実装したか） 設計通りに作成するだけなので省略。   結論・構成図 以下のような構成となりました。 まとめ いかがだったでしょうか。 今回は、当チームでCloud Run jobsを利用する際に採用したNW設計方針についてご紹介しました。 ※あくまでも当チームでどのような方針を採用したか、という内容となります。環境によって最適な方針は異なりますのでご留意ください。 本記事が皆様のお役に立てれば幸いです。

こんにちは。SCSKの松渕です。 今年もGoogle Cloudの祭典、年次イベントである「 Google Cloud Next Tokyo ’25 」が、東京ビックサイトで開催されました！ この記事では数多くの発表の中から、 エージェント型AI時代における運用 にフォーカスした2セッションを、2回にわたりレポート形式でまとめます！ ※弊社も登壇やブース出しておりましたが本レポートでは触れません。 Google Cloud Next Tokyo ’25とは 世界中で開催されるGoogle Cloud Nextの中でも、日本の技術者やビジネスパーソンにとって最も重要なイベントの一つです。 最新のAIやデータ分析、クラウドインフラに関する発表はもちろん、日本のビジネスシーンに特化したセッションや事例も豊富に用意されていました。 今年は2025年8月5日（火）と8月6日（水） の二日間にわたって開催されました。  　　 イベントレポート セッション1:最新の生成 AI モデルへのアップデートに必要な LLMOps 発表者：GoogleCloud社 LLMOpsとは LLMOps（Large Language Model Operations） とは、大規模言語モデル（LLM）を効率的かつ継続的に開発、デプロイ、運用、管理するための手法やプロセスの総称です。 DevOps（開発と運用の連携） や、機械学習モデルの運用に特化した MLOps（Machine Learning Operations） の概念を、 LLM特有の課題に合わせて拡張 したものです。 セッション内容 では、セッションの中身に入ります！ 生成AIのサポート期限について 最初に問いかけから始まります。皆さんは自身の利用している生成AIのモデルがいつまで使えるかご存知ですか？ 私は恥ずかしながら知りませんでした。     基本的に1年でサポート切れます Geminiは基本的に リリースから1年でサポート切れる とのこと。 ちなみに、 claudeもリリースから1年 が基本的なサポート期間のようです。 AzureからのAPIによるGPT利用についてもリリースから1年 がサポート期間のようです。   モニタリングする観点 PoCで精度を確認してリリースしても、適切なモニタリングをしていない場合、 運用時にモデル精度が下がるリスク （結果としてユーザが離脱するリスク）があります。 そのため、モニタリングが必要となるのですが、大きく以下のような項目（観点）でモニタリングするとの説明でした。 入力データの変化: 新しい表品名等、学習時と入力データの時間経過のモニタリング。 時間によって変わる単語の意味が変わることも含まれます。（わかりやすいところで若者言葉、はやり言葉など） モデル精度: 一番直接的なモニタリングですね。 入力データの変化に伴い、評価用データセットも初期構築時のものから更新が必要になります。 ここでいう「モデル」は何を指すかが難しいと感じたのですが、 私は 「利用するLLM（バージョン含む）+プロンプト」の組み合わせ と理解をしました。 サービス自体の品質: モデル精度低下によって影響が出ると予想されるビジネスKPIの評価を指します。   LLMOpsのステップ 具体的にLLMOpsをどのように実施するかの話に入ります。 4つのステップに分けて説明されていました。 プロンプト管理 一番イメージしやすいところかと思います。 プロンプトをしっかり管理します。プログラム管理のイメージに近いかと思います。 プロンプト最適化 最初のスライドにあった、LLMのサポート切れにもつながる点ですね。 LLMのバージョンアップに伴うプロンプトの最適化作業等が該当します。 また、入力データの時間変化に伴うプロンプトの修正も含まれます。 モデル評価 プロンプト最適化の後は再度評価が必要になります。 自動化 LLMOpsに限らずですが、定型化作業は可能ならば自動化することで効率化及びエラー防止に役立ちます。   LLMOps利用できるGoogle Cloudのサービス　～プロンプト管理～ ここからはGoogle Cloudの話に入っていきます。 Google Cloudのサービスで LLMOpsに有用なサービスの紹介 をしていきます。 AI開発には Vertex AI Studio 使うと思いますが、 メモ機能 があります。 プロンプト作る際に考えたことや検討事項を残すことで、保守性が向上します。 他にも 修正履歴の一覧化 や、 バージョン間のプロンプトが左右表示で見やすく比較 できる画面などLLM管理に有用な機能が紹介されました。   LLMOps利用できるGoogle Cloudのサービス　～プロンプト最適化～ 次に紹介されたのが Prompt Optimizer です。 私自身経験ありますが、 同一プロンプトでモデルバージョンアップすると、精度が落ちるケース があります。 スライドの通りGemini1.5から2.5にバージョンアップしたケースでした。 そのような、 モデルバージョンアップ時のプロンプト最適化を支援してくれるサービス です。   元のLLMと、評価データ、評価指標を与えることで最適化されたプロンプトが出来上がるとのこと。 ぜひ試してみたい！！    内部動作としては、複数のプロンプトを作っては評価して、評価指標を少しづつ上げていくような動きをするようです。   LLMOps利用できるGoogle Cloudのサービス　～モデル評価～ モデル評価については、モデルベースの指標と計算ベースの指標があります。 ユースケースに応じて使い分けましょう。 モデルベース指標 いわゆるLLM-as-a-judgeと呼ばれる手法ですね。 評価用のモデル（プロンプト）を用意して評価させる方法です。 計算ベースの指標 正解データとの文字の完全一致割合や、重要な単語がどれだけ共通して出てきているか等の指標に基づいて、 機械的に計算できるロジックで評価する手法です。     LLMOps利用できるGoogle Cloudのサービス　～自動化～ 最後に自動化についてでは、 Vertex AI Pipline 、 Vertex AI Workbench – Executor といった自動化サービスが紹介されました。   セッションの感想 サポート期限の短さやデータの時間的な変化に伴う精度低下等、生成AI案件特有の運用課題というのが少しづつ浸透してきているのが現状かなと思っております。 LLMOpsをしっかり学び、プロンプトの管理と継続的な評価をしっかり行い、常に最適な状態でLLMを運用することが今後数年で重要になってくると感じました。 次回 次回は 「AIオブザーバビリティ」 について投稿しようと思います！

こんにちは。SCSKの松渕です。 2025年8月にGoogle Cloud認定資格を全冠（13個）達成しました！！！（べータ版資格は除く） 2025年8月時点の最新情報や、資格取得までの苦労話を交えながら、私が実践した勉強法や取得のポイントをまとめます。 弊社でも、 2024年5月に全冠達成した人 や、 2024年9月に全冠達成した人 がいます。 私のCredlyはこちら 資格取得の履歴 カテゴリ 試験名称 略称 言語 受験日 最近のアップデート Fo undational Cloud Digital Leader CDL 日本語 2022年9月18日 2025年7月19日(更新)   Associate Associate Cloud Engineer ACE 日本語 2023年6月18日   Professional Professional Cloud Architect PCA 日本語 2024年6月23日   Professional Professional Data Engineer PDE 日本語 2024年9月22日   Professional Professional Cloud Network Engineer PCNE 日本語 2025年3月23日   Professional Professional Cloud Security Engineer PCSE 日本語 2025年4月06日   Professional Professional Cloud DevOps Engineer PCDOE 日本語 2025年5月11日   Professional Professional Cloud Developer  PCD 日本語 2025年5月11日   Associate Associate Data Practitioner  ADP 英語 2025年5月17日 2025年1月　一般公開（GA） 2025年8月現在　 英語のみ Foundational Generative AI Leader  GAIL 英語 2025年5月17日(不合格) 2025年6月14日 2025年5月15日　一般公開（GA） 2025 年8月5日　日本語対応 Professional Professional Cloud Database Engineer  PCDE 英語 2025年6月15日 2025年8月現在　 英語のみ Professional Professional Machine Learning Engineer  PMLE 日本語 2025年7月26日 2025年7月　日本語対応 Associate Google Workspace Administrator AGWA 日本語 2025年8月3日 2024年12月31日　上位試験である 　Professional Google Workspace 　Administrator（PGWA）廃止 2025年7月　日本語対応 Professional Professional Security Operations Engineer（ベータ版）  PSOE 英語 (未受験) 2025年7月8日　 ベータ版 発表 2025年8月現在　 英語のみ   試験順序について 私の試験順序 私の試験順序は、上部表のとおりですが横並びに再掲します。 赤色下線 は英語受験のもの。 CDL ⇒ ACE ⇒ PCA ⇒ PDE ⇒ PCNE ⇒ PCSE ⇒ PCDOE ＆ PCD  ⇒ ADP ⇒ GAIL ⇒ PCDE ⇒ PMLE ⇒ AGWA GAIL 　: 　GAILはこのタイミングで一般公開されたため、急遽追加受験しました。 PMLE / AGWA　 :　 日本語対応を待って受験しました。 おすすめ試験順序 大前提として、Google Cloud認定資格は常に変化しています。 最新情報 （日本語化対応、新試験追加、試験範囲変更など）を しっかりキャッチ して都度柔軟に対応することが何より大切です！ そうした最新情報は、 Google Cloud認定資格の受験者向けポータル のアナウンス欄が一番早く周知されてたと思います。 CDL ⇒ ACE ⇒ PCA ⇒ PCSE ⇒ PCNE ⇒ PCDOE ⇒ PCD ⇒ GAIL ⇒ PDE ⇒ PMLE ⇒ AGWA ⇒ ADP ⇒ PCDE 英語試験への抵抗感によって大きく戦略が異なるかと思います。 私みたいに日本語がいいという方は、可能な限り後回ししておく戦略をお勧めしてます。 PMLEおよびAGWAの日本語対応は、3週間前くらいに公表さ れてました。 CDL、ACE、PCAはクラウド全般技術の基礎知識であり、最初に受験をお勧めします PCD、PCDOEは内容がかなり近しいため、近い日程で受験する。私は同一日に受験しました。 PCSE、PCNE基盤知識がある方はそこまでハードル高くないと思います。そのため、PCA受講後の早めに受験お勧め。 ADP、PCDEは内容的にはPDEの近くで受講したほうがいいのですが、まだ日本語化していないので後回しして、 日本語化に期待する戦略をとっております。 AGWAは毛色が大きく違う ので正直どこのタイミングで受けてもよいです。 英語試験について Google Cloudでは英語でしか受けられない試験もあるのは大きな特徴になるかと思います。 英語試験のコツについて記事（TechHarmony） もありますので参考にしてください。 TOEIC600前後くらいの私の所感は以下 問題解くのに日本語の1.5倍くらいの時間を使う。 （日本語でも同じですが）試験毎にキーワードとなる単語がある。その英単語はしっかり覚えておくべし。 英語の意味が分からないため答えがわからないケースは、全体の5%くらい。 技術的に問題の答えがわからないケースの方が多い。 勉強時間と体感難易度 参考までに私の勉強時間と体感難易度まとめました 前提　：　基盤構築/保守経験13年。AWS経験7年。Google Cloud経験1年程度。 試験名称 言語 勉強時間 難易度 コメント Cloud Digital Leader 日本語 5 ★   Associate Cloud Engineer 日本語 10 ★★   Professional Cloud Architect 日本語 15 ★★★ AWSのSolutions Architect Professionalと比較すると簡単な印象 。 Professional Data Engineer 日本語 25 ★★★★ DWH、データフロー、ETL周りが問われる。 ETLやデータ分析はあまり知見がなかったこともありむつかしかった印象。 Professional Cloud Network Engineer 日本語 15 ★★ 全冠取得を決意してから初試験。 これ以降の試験すべてですが、 AWSの経験/用語をGoogle Cloudの知識/用語にチューニング して試験に臨んだイメージです。 Professional Cloud Security Engineer 日本語 13 ★★ 基盤の経験、AWSの経験から解ける問題が多かった印象。 Professional Cloud DevOps Engineer 日本語 12 ★★ Depeloperより若干基盤知識問われた印象。 デプロイの基礎的な考え方が理解が重要。Kubernetes周りの知識等は新しく覚えましたが、そこまで複雑ではない印象。 Professional Cloud Developer 日本語 30 ★★★ おそらく私の開発経験の少なさに起因しての難易度だと思います。開発経験あれば印象は違うかなと。 ひたすら勉強して知識つけて臨みました。 Associate Data Practitioner 英語 3 ★★ 初英語試験。Professional Data Engineerは持っていたため、知識的にはいけると判断しました。模擬試験やブログ見て、キーワード理解して英語試験の感覚だけつかんで臨みました。 Generative AI Leader 英語 6 ★★ 勉強0時間で臨んだら落ちたため、少し勉強して再度受験。侮ることなかれです。 Professional Cloud Database Engineer 英語 12 ★★ 英語のProfessionalですが、ある程度知見があったことと、問題もそこまで深くは問われないためこの難易度。 Professional Machine Learning Engineer 日本語 27 ★★★★ 日本語になってよかった。英語で受験を想像するとぞっとします。 機械学習の新しい用語や考え方など、一から理解していった。Google Cloudのサービスだけでなく、 汎用知識としても活用できるため、非常に有意義 な試験感じました。 Google Workspace Administrator 日本語 10 ★★ 知見は全くなかったので覚悟してたのですが、そもそも問題文で問われていることの回答になっていない選択肢も多くあるので、知見なくてもある程度点数取れそうな印象です。 MXレコードや、組織の権限の考え方等は基盤の今までの知見も活用できたため、そこまで難易度高くなかったと感じました。   勉強方法 私は 全冠取得を目標 としていたので、問題集を解くことに時間を使ってます。ただ、回答に 納得するまで調べる 、というスタイルでした。 問題集と実際のテストは微妙に違うことが多々あります。 微妙な問題の違いにより答えが変わることもあるので、自身で 納得して説明できるようになるまで調べる のは非常に大事だと思います。 学習に使ったサイトは以下です。 udemy オンライン学習プラットフォームのudemyで、問題集を購入して実施。 評判が高く、最近更新されてるもの　を選んで購入。なお、 頻繁にセールしている のでそこを狙って購入！ 多くの問題集には解説もついているのですが、納得できなければ、Geminiも活用して理解を深めました。 まとめ Google Cloud認定資格の全冠達成という目標は、決して簡単な道のりではありませんでしたが、結果として私自身の大きな成長につながりました。 この経験を通じて痛感したのは、 「最新情報をキャッチし続けること」と「自身のスキルや経験を活かした戦略を立てること」の重要性 です。特に、AWSの知識があったからこそ、Google Cloudの学習効率を上げられた側面は大きかったと感じています。現在、多くの企業がマルチクラウドやハイブリッドクラウドの環境を導入しています。今回得られた幅広い知識は、私の今後のキャリアにおいても強力な武器となると考えております。 全冠達成はゴールではなく、新たなスタート地点です。このブログが、これからGoogle Cloud認定資格に挑戦する方々の一助となれば幸いです。皆さんの成功を心から応援しています！

こんにちは。SCSKの松渕です。 2025年5月のGoogle I/Oでパブリックベータ版が公開され、 8月7日に正式リリース された、 Jules（ジュール） を試し てみました！ さわりだけしか使えておりませんが、 時代はここまで来た のか・・・と感激してます。 はじめに Julesとは AWSのKiro同様、 AIエージェント型統合開発環境（Agentic IDE） と呼ばれるものです。 単なるAIコーディングアシスタントではなく、まるで プログラマの同僚のように、バグ修正や新機能の実装を 自律的に行い 、プルリクエストまで作成する次世代のAIエージェントです。 私のスキルとブログ記載内容 私自身、普段はインフラが専門 で、アプリケーション開発やGitHubの経験は多くありません。この記事では、そんな私と同じような視点を持つ方でも分かるように、環境構築の手順から詳しく解説しています。 「そんなところいいよ」って人はすっ飛ばして後半だけ読んで下さい！ GoogleCloud環境の勉強も兼ねているので、 GoogleCloudで構築 をしております。 JulesとGitHubの設定 Jules側設定 Julesのサイト へアクセス。 Try Jules を押下 Googleアカウントでログインされた状態 になります。（アカウント持っていなければ作成画面になると思います） Connect to GitHub を押下 GitHubへサインインする画面 になります。私はGitHubのアカウントはなかったのでGoogleアカウントで作成しました。 画面に従い GitHubのアカウント作成し、Julesと連携 します。 Julesとの連携終わりました。 Jules画面が進みました。ただ、GitHubはアカウント作っただけなのでレポジトリすらない状態ですね。 GitHub初期設定 GitHubの画面へアクセスして、 Repositoriesタブ から New をクリックします。 リポジトリをつくります。 今回私はaiの最新ニュースを取ってくる仕組みを作りたいので、「ai_news」としてます。 Julesで早速プログラムを書いてもらう 実行環境準備できていないですが、楽しみすぎるので 早速Jules使ってみます！！ Julesの画面から、先ほど作ったブランチを選択します。現在、中身は空っぽです。 自然言語でプログラム作成をお願いしました。 要件整理されて、不明部分について追加ヒヤリング してくれました。す、すごい。。。 ちなみに、この回答来るまでには2分くらいでした。 質問に回答したら、進みました。 計画を自律的に立ててくれます。 こちらが承認したらプログラム作成に進みます。承認に時間かかっていたら自動で進みます。 ただ、 勝手にブランチを切ってそこを更新してくれます。 mainブランチへのマージは人にて実施が必要になります。 コードしっかり作成されました！！ Dockerfileやrequirement.txtも自律的に作ってくれました。 ※cloudbuild.yamlは後ほどJulesに明示的に依頼して作ってもらいました。 claude使って指摘してみました。しっかり対応してくれますね。   ブランチに追記されるので、マージします。   マージされました   GoogleCloud側の設定 Artifact Registryのリポジトリ作成 GoogleCloud環境へアクセスし、 Artifact Registry へ移動し、 リポジトリの作成 を押下   リポジトリ名を指定。Docker形式、モードは標準。 今回検証なのでロケーションは単一リージョンで、東京を設定します。   その他は基本標準。クリーンアップだけ設定しました。10世代くらい残す設定にしました。        リポジトリ作られました   GitHubとCloud Buildのリポジトリリンクの作成 Cloud Buildの画面で、リポジトリ画面から 第2世代 を選択し、 リポジトリをリンク をクリック。   接続から ホスト接続を作成 をクリック   GitHub を選択して、 東京リージョン を選択。 名前を付けて 接続 をクリック。   インストールを選択して確認をクリック。   リポジトリとの接続ができました。   Cloud Buildトリガー作成 トリガーを作成します。 これで、 GitHubのmainにpushしたら、自動でビルド、デプロイまで実施 されるようになります！ この設定の前に、 Julesにお願いして cloudbuild.yaml を作ってもらい、mainブランチにマージしておきましょう 。 Cloud Build画面からトリガーを作成   東京リージョンを選択。タグや説明はお好みです。   リポジトリの生成は 第二世代 を選択。 リポジトリをリンク をクリック   別ウィンドウが出てきます。 リポジトリを選択してリンクをクリック。   リポジトリに先ほどリンクしたリポジトリが出てきます。 構成は、Cloud Build を選択。   ロケーションは リポジトリ 、構成ファイルの場所はデフォルト変更なしです。 Julesもおそらくこの場所にcloudbuild.yamlを作ってくれる と思います。   サービスアカウントを選択 して、 保存 をクリック   Cloud Run Jobの設定 アプリを実行するCloud Run環境を作ります。 今回のアプリはスケジューラもしくは手動実行を想定しているため、 Cloud Run Jobで作成 します。 Cloud Runのジョブからコンテナをデプロイをクリック   コンテナイメージURLの選択から、イメージを選択します。 リージョンは東京を選択。   サービスアカウントを設定。今回は専用サービスアカウントを利用しました。 サービスアカウントは、 本番利用であれば各アプリ専用のサービスアカウント を作ることをお勧めします。 最小権限の原則にのっとり、堅牢なシステムになります。 今回のような検証であればとりあえずデフォルトのサービスアカウントでもよいと考えますが、 他環境と明確に切り離したかった ので今回はあえて分けました。   動作確認 作り終えましたので、動作確認します！ まずは、何か プログラムを更新 をします。Julesに更新を依頼します。 更新してくれたので、branchにプッシュGitを更新します。 GitHub上で mainブランチにマージ します。 マージすると、自動でCloud Buidが走ります。   CoreBuldの完了を待って、CloudRun実行。 ビルドが失敗することも多数あるかと思います。 私は、 ビルド成功するまで10回以上かかりましたが、都度エラーをJulesに連携して進めました。 なかなか解決しなかった場合、 別LLM（Claude）にエラーを投げて 、その解答をJulesに教える ことで前に進みました。   実行が終了したら、ログを確認します。 こちらもビルドと同様、エラーがたくさん出ました。 印象に残っていたのは、最初にJulesが作ったプログラムだと、 Geminiのバージョンが古かった です（1.0 proを指定してました） 指摘しても、「最新の1.5に修正します」 とトンチンカンなことを言ってました。 そういった際は、明確に「○○ファイルに記載されている”gemini-1.5-flash”を”gemini-2.5-flash”に変更ください」 と伝えれば変えてくれます。   エラーが出ていないことを確認しましょう。 エラーハンドリングが間違えていて、 正常終了といいながら全く正常じゃないこと もありますので、 ログもそうですし、結果出力をしっかり確認しましょう。   最終出力も確認します。 ちょっとイメージと違いましたが、とりあえず ai関連のニュースサマリ が出ました！！ 今後Jules使って改善していこうと思います！ Jules使ってみた感想 素晴らしい点 自律的に実施してくれる 自然言語で依頼したら、 自身で考えて計画を立て、プログラム作成/修正 まで実施してくれます。 バグが多かったので 「ちゃんとテストしてよ」 と言ったところ、以下のようなことを言ってくれます。 そこまで考えてくれる んですか・・・！！（ できるなら最初からやってよ とも思いますが）     私の手元にあるサンドボックス環境では 外部のネットワーク、特にあなたのGoogle Cloudプロジェクト （GCSやVertex AI Searchなど）に 直接接続することは許可されておりません。 ～（中略）～ そのため、外部サービスとの連携部分を模倣した 「ユニットテスト」を導入することをご提案します。 Julesでできないことを明確にして依頼してくれる 今回でいうと、 Google Cloudとの連携部分はJules単体では実施できません。 その際、こちらで必要な作業を明確にして依頼してくれます。 「プログラムのここに、作成したGoogle Cloudのサービスアカウント名を入力してください」 といった依頼をしてくれました。 プログラミングだけでないサポート GoogleCloudの設定方法についても教えてくれます。 ある要件の実現方法が、プログラムなのか基盤側の設定なのかよくわからないケースもあると思いますが、 それも いったんJulesに投げれば、どうすればいいか回答 してくれます。 1日の利用上限が多い 1日15回タスクが上限なのですが、「1タスク」とは1回の指示という意味ではなく、「1つづきの会話」のようです。「さっき言ってたのやったけど失敗したんだけど」と会話の続きであれば、1タスク内です。 もったいない点 過去の指摘を忘れてくる。 少し触れましたが、JulesはGeminiのバージョンを間違えてきました（1.0 pro）が、それを指摘して修正（2.5 flash）した後、 別の箇所の修正するときに合わせて Geminiのバージョンを 元の間違った値に修正 されました（1.0 pro） 。 RSSのURLでも同様の事象があり、おそらく 内部のAIが学習した時点の古い情報に戻ってしまう ことが散見されました。 応答時間にかなりのムラがある。 簡単な修正であれば平均2-3分で修正までしてくれますが、 まれに20分程度応答がない こともありました。ネット上では5時間待ちという話もあります。 通知設定もできる ので、応答ない場合は気長に待ちましょう。 良くも悪くも気を利かせすぎ 今回、aiでのnews要約システムを作りました。その際のプロンプトは私が何も指定せずにJules側決められました。Julesの作成したプロンプトは 「以下の記事を300字程度の日本語で要約してください」 でした。 300文字は私のイメージより長すぎでした 。 このように、 明確に指示のない箇所をある程度自律的に設計 してくれるのですが、 イメージとずれている ことも結構あり ます。 英語で応答を返してくる LLMあるあるではありますが、 日本語で聞いているのに日本語で返ってこない ケースが、一般的なLLMより多いと感じました。 おそらくですがコードやエラーログなど、英語の情報を渡すことが多いので英語で返ってきてしまうのだろうと思います。 まとめ 今回は、GoogleのAIエージェント「Jules」を使って、AIニュースの要約システムを構築する過程をご紹介しました。 私自身、プログラミングやGitHubの知識がほとんどない状態からスタートしましたが、 Julesがまるで同僚（いや、技術力のある大先輩）のように自律的にコードを生成・修正してくれた おかげで、無事システムを完成させることができました。 プログラミング以外の領域でも Julesが次にやるべきことを明確に示してくれた ため、スムーズに進めることができました。 もちろん、応答時間にムラがあったり、こちらの意図と少し違う実装したりといった改善点も感じましたが、それを差し引いても、Julesは非常に強力で、 今後の開発のあり方を大きく変える 可能性を秘めたツール だと確信しています。 技術の進化のスピードは驚くほど速く、ついていくのが大変だと感じることもありますが、JulesのようなAIエージェントをうまく活用すれば、 私のようなインフラエンジニアでも、プログラミングの世界に飛び込んでいける時代 になったのだと実感しました。 一方で、 Julesの作った計画/方針やプログラムを 理解する能力 も同様に重要 だと感じました。検証なのであまり考えずデプロイしてましたが、セキュリティ観点、コスト観点、etc…と、 仮に正常に動作したとしても本番化には様々考えること があります。その観点でJulesの出力を 理解しなければ、指摘ができません。指摘できなければ、Julesも修正はしてくれません 。 これを読んでくださった皆さんも、ぜひ一度Julesを試してみてはいかがでしょうか。

こんにちは、広野です。 AWS Cloud9 は研修用途では非常に使い勝手が良かったのですが、AWS が新規アカウントへの提供を終了してしまいました。今回は私が試みた代替ソリューションの実装編です。本記事は Application Load Balancer とその周辺設定を対象にします。デプロイ先の VPC が完成していることが前提になります。 code-server と ALB で AWS Cloud9 代替の研修用 IDE を提供する - アーキテクチャ概要編 AWS Cloud9 の代替 IDE を作成しました。私が試みた設計を紹介したいと思います。本記事はアーキテクチャ概要編です。 blog.usize-tech.com 2025.08.12 code-server と ALB で AWS Cloud9 代替の研修用 IDE を提供する - 実装編1 VPC AWS Cloud9 の代替 IDE を作成しました。私が試みた設計を紹介したいと思います。本記事は実装編 1、VPC です。 blog.usize-tech.com 2025.08.13   アーキテクチャ アーキテクチャ概要編で、以下の図を紹介しておりました。 code-server サーバを配置する VPC です。何の変哲もない一般的なサブネット構成にしています。 NAT Gateway は課金節約のため、1 つのパブリックサブネットにしか配置していません。 code-server サーバは 1 ユーザーあたり 1 台を割り当てます。図では 1 つしかありませんが、人数分作成される想定です。ALB はユーザー全体で共用します。 code-server のログインパスワードはインストール時に設定しますが、AWS Secrets Manager で生成したものを使用します。 ALB には HTTPS アクセスさせるため、図には書いていませんが独自ドメインを使用します。そのための SSL 証明書はそのリージョンの AWS Certificate Manager で作成されていることが前提になります。 ALB から EC2 インスタンスへの通信は 80 番ポート (HTTP) を使用します。 ALB はインターネットに公開されますが、研修用途を想定して会社のソース IP アドレスからのみアクセスできるようにセキュリティグループを設定しています。   使用する VPC 新たに VPC を作成する場合 前回記事を参考に、作成してください。 code-server と ALB で AWS Cloud9 代替の研修用 IDE を提供する - 実装編1 VPC AWS Cloud9 の代替 IDE を作成しました。私が試みた設計を紹介したいと思います。本記事は実装編 1、VPC です。 blog.usize-tech.com 2025.08.13   既存 VPC を使用する場合 以下の条件であれば、既存 VPC を使用することが可能です。 パブリックサブネットが 2 つある。(ALB 用) プライベートサブネットからインターネットにアクセスできる。(NAT Gateway がある) ソフトウェアのインストールや、AWS Systems Manager, AWS Secrets Manager のエンドポイントへのアクセスに使用する。   AWS CloudFormation テンプレートの構成 テンプレートは 3 つに分けています。 VPC Application Load Balancer ← 今回はここ Amazon EC2 インスタンス このうち、VPC と ALB はユーザー共用になるので 1 回のみ実行します。Amazon EC2 インスタンスはユーザーごとに実行が必要です。 作成する ALB は本体 1 つとリスナーのみ作成します。ターゲットグループやリスナールールはぶらさがる Amazon EC2 インスタンスごとに作成しますので、続編記事で紹介します。 ALB にはターゲットグループからの HTTP レスポンスヘッダーをオーバーライドする機能があります。今回の構成ではそれを使用して若干セキュリティを高めています。 Amazon EC2 インスタンスの共通設定となる起動テンプレートとセキュリティグループもここで共通設定として 1 回だけ作成します。 テンプレートの範囲を図にすると、以下のようになります。ここに書かれているリソースが作成されます。   AWS CloudFormation テンプレート AWS CloudFormation テンプレートです。AWS Secrets Manager は、続編記事のテンプレートに入ります。 Amazon EC2 の起動テンプレートは、インスタンスの共通設定としてボリュームサイズを可変にしています。とりあえず 10 GB あれば余裕はありますが、インストールするモジュール等により変更は必要です。インスタンスタイプは t3.micro, t3.small からの 2 択にしていますが、必要に応じて変更してください。 その他細かいことはインラインのコメントで補足します。 AWSTemplateFormatVersion: "2010-09-09" Description: The CloudFormation template that creates a S3 bucket for logging, an EC2 Security Group, a Launch template and an ALB for common code-server configurations. # ------------------------------------------------------------# # Input Parameters # ------------------------------------------------------------# Parameters: SystemName: Type: String Description: System name. use lower case only. (e.g. example) Default: example MaxLength: 10 MinLength: 1 SubName: Type: String Description: System sub name. use lower case only. (e.g. prod or dev) Default: dev MaxLength: 10 MinLength: 1 VpcId: Type: AWS::EC2::VPC::Id Description: Choose a existing VPC ID you deploy the EC2 instance in. AlbSubnet1: Type: AWS::EC2::Subnet::Id Description: Choose an existing Public Subnet ID you deploy the Application Load Balancer in. AlbSubnet2: Type: AWS::EC2::Subnet::Id Description: Choose an existing Public Subnet ID you deploy the Application Load Balancer in. InstanceSubnet: Type: AWS::EC2::Subnet::Id Description: Choose an existing Private Subnet ID you deploy the EC2 instance in. LogRetentionDays: Type: Number Description: The retention period (days) for entire log data. Enter an integer between 35 to 540. Default: 400 MaxValue: 540 MinValue: 35 InstanceType: Type: String Description: EC2 instance type for code-server. Default: t3.small AllowedValues: - t3.micro - t3.small InstanceVolumeSize: Type: Number Description: The volume size in GB Default: 10 # ALB を HTTPS アクセス可能とするため、独自ドメインを使用します。 DomainName: Type: String Description: Domain name for URL. xxxxx.xxx Default: example.com MaxLength: 40 MinLength: 5 # ドメインの SSL 証明書を ACM で登録していることが前提です。証明書の ARN を記入します。 CertificateArn: Type: String Description: ACM certificate ARN. Default: arn:aws:acm:ap-northeast-1:xxxxxxxxxxxx:certificate/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx MaxLength: 128 MinLength: 10 # ALB へのアクセスを許可するソース IPv4 サブネットを指定します。 AllowedSubnet: Type: String Description: Allowed source IPv4 subnet and subnet mask. (e.g. xxx.xxx.xxx.xxx/32) Default: xxx.xxx.xxx.xxx/32 MaxLength: 18 MinLength: 9 Resources: # ------------------------------------------------------------# # S3 # ------------------------------------------------------------# S3BucketLogs: Type: AWS::S3::Bucket Properties: BucketName: !Sub ${SystemName}-${SubName}-code-server-logs LifecycleConfiguration: Rules: - Id: AutoDelete Status: Enabled ExpirationInDays: !Ref LogRetentionDays OwnershipControls: Rules: - ObjectOwnership: BucketOwnerEnforced PublicAccessBlockConfiguration: BlockPublicAcls: true BlockPublicPolicy: true IgnorePublicAcls: true RestrictPublicBuckets: true Tags: - Key: Cost Value: !Sub ${SystemName}-${SubName} # for ap-northeast-1 region S3BucketPolicyLogs: Type: AWS::S3::BucketPolicy Properties: Bucket: !Ref S3BucketLogs PolicyDocument: Version: "2012-10-17" Statement: - Effect: Allow Principal: # 東京リージョン以外で使用するときは、以下のアカウント番号を変更する必要があります。AWS 指定のものです。 AWS: "arn:aws:iam::582318560864:root" Action: s3:PutObject Resource: !Sub "${S3BucketLogs.Arn}/*" DependsOn: - S3BucketLogs # ------------------------------------------------------------# # EC2 Launch template # ------------------------------------------------------------# EC2LaunchTemplate: Type: AWS::EC2::LaunchTemplate Properties: LaunchTemplateName: !Sub code-server-${SystemName}-${SubName} LaunchTemplateData: InstanceType: !Ref InstanceType # AMI は Amazon Linux 2023 の最新版を使用するようになっています。 ImageId: >- {{resolve:ssm:/aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64}} BlockDeviceMappings: - Ebs: VolumeSize: !Ref InstanceVolumeSize VolumeType: gp3 DeleteOnTermination: true Encrypted: true DeviceName: /dev/xvda NetworkInterfaces: - SubnetId: !Ref InstanceSubnet Groups: - !Ref Ec2SecurityGroup DeviceIndex: 0 AssociatePublicIpAddress: false MetadataOptions: HttpTokens: required Monitoring: Enabled: true TagSpecifications: - ResourceType: volume Tags: - Key: Cost Value: !Sub ${SystemName}-${SubName} DependsOn: - Ec2SecurityGroup # ------------------------------------------------------------# # EC2 Security Group # ------------------------------------------------------------# Ec2SecurityGroup: Type: AWS::EC2::SecurityGroup Properties: VpcId: !Ref VpcId GroupDescription: Allow code-server access via ALB only SecurityGroupIngress: - Description: Allow HTTP from ALB FromPort: 80 IpProtocol: tcp ToPort: 80 SourceSecurityGroupId: !GetAtt AlbSecurityGroup.GroupId SecurityGroupEgress: - Description: Allow all outbound traffic IpProtocol: -1 CidrIp: 0.0.0.0/0 Tags: - Key: Cost Value: !Sub ${SystemName}-${SubName} - Key: Name Value: !Sub SG-code-server-${SystemName}-${SubName} DependsOn: - AlbSecurityGroup # ------------------------------------------------------------# # ALB Security Group # ------------------------------------------------------------# AlbSecurityGroup: Type: AWS::EC2::SecurityGroup Properties: VpcId: !Ref VpcId GroupDescription: Allow access via HTTPS. SecurityGroupIngress: - CidrIp: !Ref AllowedSubnet FromPort: 443 IpProtocol: tcp ToPort: 443 Tags: - Key: Cost Value: !Sub ${SystemName}-${SubName} - Key: Name Value: !Sub SG-alb-${SystemName}-${SubName} # ------------------------------------------------------------# # ALB # ------------------------------------------------------------# ApplicationLoadBalancer: Type: AWS::ElasticLoadBalancingV2::LoadBalancer Properties: Name: !Sub alb-code-server-${SystemName}-${SubName} Type: application IpAddressType: ipv4 LoadBalancerAttributes: - Key: deletion_protection.enabled Value: false - Key: access_logs.s3.enabled Value: true - Key: access_logs.s3.bucket Value: !Ref S3BucketLogs - Key: access_logs.s3.prefix Value: albAccessLogs - Key: idle_timeout.timeout_seconds Value: 60 - Key: routing.http.desync_mitigation_mode Value: defensive - Key: routing.http.drop_invalid_header_fields.enabled Value: true - Key: routing.http.preserve_host_header.enabled Value: false - Key: routing.http.x_amzn_tls_version_and_cipher_suite.enabled Value: false - Key: routing.http.xff_client_port.enabled Value: false - Key: routing.http.xff_header_processing.mode Value: append - Key: routing.http2.enabled Value: true - Key: waf.fail_open.enabled Value: false Scheme: internet-facing SecurityGroups: - !GetAtt AlbSecurityGroup.GroupId Subnets: - !Ref AlbSubnet1 - !Ref AlbSubnet2 Tags: - Key: Cost Value: !Sub ${SystemName}-${SubName} - Key: Name Value: !Sub alb-code-server-${SystemName}-${SubName} DependsOn: - AlbSecurityGroup - S3BucketLogs # HTTPS listener for routing AlbListenerHttps: Type: AWS::ElasticLoadBalancingV2::Listener Properties: LoadBalancerArn: !Ref ApplicationLoadBalancer Port: 443 Protocol: HTTPS SslPolicy: ELBSecurityPolicy-TLS13-1-2-2021-06 Certificates: - CertificateArn: !Ref CertificateArn DefaultActions: - Type: fixed-response FixedResponseConfig: StatusCode: 404 ContentType: text/plain MessageBody: Not Found ListenerAttributes: # frame タグは SAMEORIGIN でないと許可しないようにしています。DENY だと code-server でエラーが発生します。 - Key: routing.http.response.x_frame_options.header_value Value: SAMEORIGIN - Key: routing.http.response.server.enabled Value: false - Key: routing.http.response.strict_transport_security.header_value Value: max-age=31536000; includeSubdomains; preload; - Key: routing.http.response.x_content_type_options.header_value Value: nosniff # CSP は code-server の動作に抵触しないよう調整しています。もしエラーが発生したら都度調整が必要です。 - Key: routing.http.response.content_security_policy.header_value Value: "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; script-src-elem 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; connect-src 'self' https://open-vsx.org https://marketplace.visualstudio.com; worker-src 'self' blob:; font-src 'self' data:; frame-src 'self';" DependsOn: - ApplicationLoadBalancer # ------------------------------------------------------------# # Route 53 # ------------------------------------------------------------# Route53RecordA: Type: AWS::Route53::RecordSet Properties: HostedZoneName: !Sub ${DomainName}. Name: !Sub code-server-${SystemName}-${SubName}.${DomainName}. Type: A AliasTarget: HostedZoneId: !GetAtt ApplicationLoadBalancer.CanonicalHostedZoneID DNSName: !GetAtt ApplicationLoadBalancer.DNSName DependsOn: ApplicationLoadBalancer # ------------------------------------------------------------# # Output Parameters # ------------------------------------------------------------# Outputs: # Ec2 Ec2LaunchTemplateId: Value: !Ref EC2LaunchTemplate Export: Name: !Sub ec2LtId-code-server-${SystemName}-${SubName} Ec2LaunchTemplateVersion: Value: !GetAtt EC2LaunchTemplate.LatestVersionNumber Export: Name: !Sub ec2LtVersion-code-server-${SystemName}-${SubName} # S3 S3BucketLogsName: Value: !Ref S3BucketLogs Export: Name: !Sub S3BucketLogsName-code-server-${SystemName}-${SubName} S3BucketLogsArn: Value: !GetAtt S3BucketLogs.Arn Export: Name: !Sub S3BucketLogsArn-code-server-${SystemName}-${SubName} # ALB AlbUrl: Value: !Sub https://code-server-${SystemName}-${SubName}.${DomainName} Export: Name: !Sub AlbUrl-${SystemName}-${SubName} AlbListenerArn: Value: !GetAtt AlbListenerHttps.ListenerArn Export: Name: !Sub AlbListenerArn-${SystemName}-${SubName}   続編記事 code-server と ALB で AWS Cloud9 代替の研修用 IDE を提供する - 実装編 3 EC2 AWS Cloud9 の代替 IDE を作成しました。私が試みた設計を紹介したいと思います。本記事は実装編 3、EC2 です。 blog.usize-tech.com 2025.08.14   まとめ いかがでしたでしょうか。 今回は実装編 2 Application Load Balancer でした。まだソリューションの核心には触れられていませんが、ベースはできてきています。続編記事で、パスベースルーティングや nginx に触れます。 本記事が皆様のお役に立てれば幸いです。

こんにちは、広野です。 AWS Cloud9 は研修用途では非常に使い勝手が良かったのですが、AWS が新規アカウントへの提供を終了してしまいました。今回は私が試みた代替ソリューションの実装編です。本記事は VPC を対象にします。特別な設計はないので、別件でも使用可能だと思います。 code-server と ALB で AWS Cloud9 代替の研修用 IDE を提供する - アーキテクチャ概要編 AWS Cloud9 の代替 IDE を作成しました。私が試みた設計を紹介したいと思います。本記事はアーキテクチャ概要編です。 blog.usize-tech.com 2025.08.12   アーキテクチャ アーキテクチャ概要編で、以下の図を紹介しておりました。 code-server サーバを配置する VPC です。何の変哲もない一般的なサブネット構成にしています。 NAT Gateway は課金節約のため、1 つのパブリックサブネットにしか配置していません。 code-server サーバは 1 ユーザーあたり 1 台を割り当てます。図では 1 つしかありませんが、人数分作成される想定です。ALB はユーザー全体で共用します。 code-server のログインパスワードはインストール時に設定しますが、AWS Secrets Manager で生成したものを使用します。 ALB には HTTPS アクセスさせるため、図には書いていませんが独自ドメインを使用します。そのための SSL 証明書はそのリージョンの AWS Certificate Manager で作成されていることが前提になります。 ALB から EC2 インスタンスへの通信は 80 番ポート (HTTP) を使用します。 ALB はインターネットに公開されますが、研修用途を想定して会社のソース IP アドレスからのみアクセスできるようにセキュリティグループを設定しています。   既存 VPC を利用する場合 以下の条件であれば、既存 VPC を使用することが可能です。本記事の内容は飛ばすことができます。 パブリックサブネットが 2 つある。(ALB 用) プライベートサブネットからインターネットにアクセスできる。(NAT Gateway がある) ソフトウェアのインストールや、AWS Systems Manager, AWS Secrets Manager のエンドポイントへのアクセスに使用する。   AWS CloudFormation テンプレートの構成 テンプレートは 3 つに分けています。 VPC ←今回はここ Application Load Balancer Amazon EC2 インスタンス このうち、VPC と Application Load Balancer はユーザー共用になるので 1 回のみ実行します。Amazon EC2 インスタンスはユーザーごとに実行が必要です。 AWS Secrets Manager のシークレットはユーザーごとに作成するので、Amazon EC2 インスタンスと同時に実装します。 テンプレートの範囲を図にすると、以下のようになります。ここに書かれているリソースが作成されます。   AWS CloudFormation テンプレート AWS CloudFormation テンプレートです。AWS Secrets Manager は、続編記事のテンプレートに入ります。 AWSTemplateFormatVersion: 2010-09-09 Description: The CloudFormation template that creates A VPC, Subnets, an Internet Gateway, a single NAT Gateway in AZ A and Routings. # ------------------------------------------------------------# # Input Parameters # ------------------------------------------------------------# Parameters: SystemName: Type: String Description: System name. use lower case only. (e.g. example) Default: example MaxLength: 10 MinLength: 1 SubName: Type: String Description: System sub name. use lower case only. (e.g. prod or dev) Default: dev MaxLength: 10 MinLength: 1 VPCCIDR: Type: String Description: IP Address range for your VPC (16 bit mask) Default: 192.168.0.0/16 MaxLength: 14 MinLength: 10 AllowedPattern: ^((25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9]?[0-9])\.){2}0\.0/16$ PublicSubnetACIDR: Type: String Description: IP Address range for your public subnet A (24 bit mask) Default: 192.168.1.0/24 MaxLength: 16 MinLength: 10 AllowedPattern: ^((25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9]?[0-9])\.){3}0/24$ PublicSubnetCCIDR: Type: String Description: IP Address range for your public subnet C (24 bit mask) Default: 192.168.2.0/24 MaxLength: 16 MinLength: 10 AllowedPattern: ^((25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9]?[0-9])\.){3}0/24$ PrivateSubnetACIDR: Type: String Description: IP Address range for your private subnet A (24 bit mask) Default: 192.168.101.0/24 MaxLength: 16 MinLength: 10 AllowedPattern: ^((25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9]?[0-9])\.){3}0/24$ PrivateSubnetCCIDR: Type: String Description: IP Address range for your private subnet C (24 bit mask) Default: 192.168.102.0/24 MaxLength: 16 MinLength: 10 AllowedPattern: ^((25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9]?[0-9])\.){3}0/24$ Resources: # ------------------------------------------------------------# # VPC # ------------------------------------------------------------# VPC: Type: AWS::EC2::VPC Properties: CidrBlock: !Ref VPCCIDR EnableDnsSupport: true EnableDnsHostnames: true InstanceTenancy: default Tags: - Key: Name Value: !Sub vpc-${SystemName}-${SubName} - Key: Cost Value: !Sub ${SystemName}-${SubName} InternetGateway: Type: AWS::EC2::InternetGateway Properties: Tags: - Key: Name Value: !Sub igw-${SystemName}-${SubName} - Key: Cost Value: !Sub ${SystemName}-${SubName} InternetGatewayAttachment: Type: AWS::EC2::VPCGatewayAttachment Properties: InternetGatewayId: !Ref InternetGateway VpcId: !Ref VPC # ------------------------------------------------------------# # Subnet # ------------------------------------------------------------# # Public SubnetA Create PublicSubnetA: Type: AWS::EC2::Subnet Properties: AvailabilityZone: !Select - 0 - Fn::GetAZs: !Ref AWS::Region CidrBlock: !Ref PublicSubnetACIDR MapPublicIpOnLaunch: true VpcId: !Ref VPC Tags: - Key: Name Value: !Sub public-a-${SystemName}-${SubName} - Key: Cost Value: !Sub ${SystemName}-${SubName} # Public SubnetC Create PublicSubnetC: Type: AWS::EC2::Subnet Properties: AvailabilityZone: !Select - 1 - Fn::GetAZs: !Ref AWS::Region CidrBlock: !Ref PublicSubnetCCIDR MapPublicIpOnLaunch: true VpcId: !Ref VPC Tags: - Key: Name Value: !Sub public-c-${SystemName}-${SubName} - Key: Cost Value: !Sub ${SystemName}-${SubName} # Private SubnetA Create PrivateSubnetA: Type: AWS::EC2::Subnet Properties: AvailabilityZone: !Select - 0 - Fn::GetAZs: !Ref AWS::Region CidrBlock: !Ref PrivateSubnetACIDR VpcId: !Ref VPC Tags: - Key: Name Value: !Sub private-a-${SystemName}-${SubName} - Key: Cost Value: !Sub ${SystemName}-${SubName} # Private SubnetC Create PrivateSubnetC: Type: AWS::EC2::Subnet Properties: AvailabilityZone: !Select - 1 - Fn::GetAZs: !Ref AWS::Region CidrBlock: !Ref PrivateSubnetCCIDR VpcId: !Ref VPC Tags: - Key: Name Value: !Sub private-c-${SystemName}-${SubName} - Key: Cost Value: !Sub ${SystemName}-${SubName} # ------------------------------------------------------------# # RouteTable # ------------------------------------------------------------# # Public RouteTable A Create PublicRouteTableA: Type: AWS::EC2::RouteTable Properties: VpcId: !Ref VPC Tags: - Key: Name Value: !Sub rtb-public-a-${SystemName}-${SubName} - Key: Cost Value: !Sub ${SystemName}-${SubName} # Public RouteTable C Create PublicRouteTableC: Type: AWS::EC2::RouteTable Properties: VpcId: !Ref VPC Tags: - Key: Name Value: !Sub rtb-public-c-${SystemName}-${SubName} - Key: Cost Value: !Sub ${SystemName}-${SubName} # Private RouteTable A Create PrivateRouteTableA: Type: AWS::EC2::RouteTable Properties: VpcId: !Ref VPC Tags: - Key: Name Value: !Sub rtb-private-a-${SystemName}-${SubName} - Key: Cost Value: !Sub ${SystemName}-${SubName} # Private RouteTable C Create PrivateRouteTableC: Type: AWS::EC2::RouteTable Properties: VpcId: !Ref VPC Tags: - Key: Name Value: !Sub rtb-private-c-${SystemName}-${SubName} - Key: Cost Value: !Sub ${SystemName}-${SubName} # ------------------------------------------------------------# # Routing to Internet # ------------------------------------------------------------# # PublicRouteA Create PublicRouteA: Type: AWS::EC2::Route Properties: RouteTableId: !Ref PublicRouteTableA DestinationCidrBlock: 0.0.0.0/0 GatewayId: !Ref InternetGateway # PublicRouteC Create PublicRouteC: Type: AWS::EC2::Route Properties: RouteTableId: !Ref PublicRouteTableC DestinationCidrBlock: 0.0.0.0/0 GatewayId: !Ref InternetGateway PrivateRouteA: Type: AWS::EC2::Route Properties: RouteTableId: !Ref PrivateRouteTableA DestinationCidrBlock: 0.0.0.0/0 NatGatewayId: !Ref NatGatewayA PrivateRouteC: Type: AWS::EC2::Route Properties: RouteTableId: !Ref PrivateRouteTableC DestinationCidrBlock: 0.0.0.0/0 NatGatewayId: !Ref NatGatewayA # ------------------------------------------------------------# # RouteTable Associate # ------------------------------------------------------------# # PublicRouteTable Associate SubnetA PublicSubnetARouteTableAssociation: Type: AWS::EC2::SubnetRouteTableAssociation Properties: SubnetId: !Ref PublicSubnetA RouteTableId: !Ref PublicRouteTableA # PublicRouteTable Associate SubnetC PublicSubnetCRouteTableAssociation: Type: AWS::EC2::SubnetRouteTableAssociation Properties: SubnetId: !Ref PublicSubnetC RouteTableId: !Ref PublicRouteTableC # PrivateRouteTable Associate SubnetA PrivateSubnetARouteTableAssociation: Type: AWS::EC2::SubnetRouteTableAssociation Properties: SubnetId: !Ref PrivateSubnetA RouteTableId: !Ref PrivateRouteTableA # PrivateRouteTable Associate SubnetC PrivateSubnetCRouteTableAssociation: Type: AWS::EC2::SubnetRouteTableAssociation Properties: SubnetId: !Ref PrivateSubnetC RouteTableId: !Ref PrivateRouteTableC # ------------------------------------------------------------# # Elastic IP address for NAT Gateway # ------------------------------------------------------------# EipNatGatewayA: Type: AWS::EC2::EIP Properties: Domain: vpc Tags: - Key: Cost Value: !Sub ${SystemName}-${SubName} - Key: Name Value: !Sub eip-ngw-a-${SystemName}-${SubName} # ------------------------------------------------------------# # NAT Gateway # ------------------------------------------------------------# NatGatewayA: Type: AWS::EC2::NatGateway Properties: AllocationId: !GetAtt EipNatGatewayA.AllocationId ConnectivityType: public MaxDrainDurationSeconds: 350 SubnetId: !Ref PublicSubnetA Tags: - Key: Cost Value: !Sub ${SystemName}-${SubName} - Key: Name Value: !Sub ngw-a-${SystemName}-${SubName} # ------------------------------------------------------------# # Output Parameters # ------------------------------------------------------------# Outputs: # VPC VpcId: Value: !GetAtt VPC.VpcId   続編記事 続編記事が出来次第、この章を更新します。   まとめ いかがでしたでしょうか。 今回は実装編 1 VPC でした。一般的な内容なので得るものは少ないと思いましたが、絶対に必要だったので紹介しておきました。 本記事が皆様のお役に立てれば幸いです。

本記事は 夏休みクラウド自由研究2025 8/13付の記事です 。 Catoのサポート窓口では、日々たくさんのお問い合わせをいただいています。 機能の仕様から、実際にご利用中に発生したトラブルまで、その内容はさまざま。 中でも特に多いと感じるのが、 Catoクライアントの接続不具合に関するお問い合わせ です。 そこで本ブログでは、 これまでに多く寄せられた接続トラブルの原因TOP5 をご紹介します！ また、こうしたトラブルが発生した際に役立つ基本的な切り分け方法についてもご紹介します。 このブログが少しでもお役に立てれば嬉しいです！ 本ブログのランキングは2024年4月から2025年4月まで1年間の問い合わせから集計しております！ Catoクライアントで接続できない状況とは？ Catoクライアントの接続不具合といっても、具体的にどのようなケースが多いのでしょうか？ すべてのケースを網羅するわけではありませんが、代表的な例をいくつかご紹介します。 よくある接続トラブルの例： 「Connecting」「Authenticating」の状態のまま進まず、接続できない アプリにエラーが表示され、接続できない 接続できても不安定で、すぐに切断されてしまう このように、接続できない・不安定な状況が発生した場合、まず何を確認すればよいのか？ 次の項目では、いよいよ実際に多かった原因TOP5をご紹介します。 1位： Cato接続に必要な通信がユーザ環境側でBlockされていた 接続ができないという不具合に関して、ユーザーのネットワーク環境側でCato接続への通信がBlockされていた。。 という原因が最も多いと感じました。 なんとクライアントの不具合に関する問い合わせで約5割程度がこの事象に該当します。   特に原因となっているのが ファイアウォール/プロキシ等のセキュリティ機器や、端末内のセキュリティソフト等でCato宛ての通信が許可されておらず通信が制限されている ことによる原因が多いです。 許可が必要な通信は以下の通りです。 利用前に確認が必須なので、この機会に確認いただくのもよいかと思います！ 許可が必要な通信 Cato PoPのIPアドレス Cato接続に関係するドメイン・URL 53/udp、443/udpの通信 CHECK！ ファイアウォールやプロキシーでブロックされていたと判明するのに 詳細な切り分けやトラブルシューティングなどかなりの時間を要します。。 以下のナレッジにはCatoクライアンインストール時に許可すべきドメインなどOS、機種ごとに紹介されています。 Catoクライアントを利用する際は一度ナレッジを確認し、前提条件がそもそも満たされているのか、、を確認することでトラブルの迅速な解決につながるかと！ Installing the Cato Client 2位：非推奨のアプリケーションがインストールされていた Catoクライアントを利用する端末側で、 非推奨とされるサードパーティ製のアプリがインストールされている場合、接続不具合を引き起こす場合があります。 サードパーティ製VPNクライアント例： Cisco AnyConnect GlobalProtect Ivanti Secure Access (旧 Pulse Secure) Catoクライアントとサードパーティ製VPNクライアントが同じPCにインストールされると、 設定が競合し接続不具合を引き起こす 場合があります。 そのため、ご利用端末にてサードパーティ製のVPNクライアントがインストールされている場合は、アンインストールし、削除後にPCを再起動することを推奨しています！ CHECK！ サードパーティ製のVPNソフトの他に、 ウイルス対策ソフトがCatoクライアントの通信を誤って悪意のあるトラフィックと判断し、Blockしてしまう ことがあります。 切り分けとして、一時的にウイルス対策ソフトを無効化し、Catoクライアントの通信がBlockされているかを確認することもできます。 もしもウイルス対策ソフトがCatoクライアントをブロックしていると判断できた場合は、以下の方法をお試しください！ 対策例： ウイルス対策ソフトの設定を変更し、Catoクライアントを例外リストに追加する Cato Networksのサポートに連絡し、アンチウイルスソフトのホワイトリスト登録を依頼する   3位： ログイン情報の入力ミス 急に単純な内容になってしまいますが、 パスワードやユーザ名の入力ミスによる接続エラー も散見されました。 以下のLoginエラーが表示された場合、入力にミスがあると思われるため再度正しい値が入力されているか確認してみましょう！   2025年7月28日以前のパスワード条件は、「8文字以上32文字以下で、英大文字、英小文字、数字」でしたが、現在の仕様では「特殊文字」も追加されております。新たにパスワードを作成する際はご注意ください！！（例：!,@,#,$,%など） ※2025年7月28日以前に作成されたパスワードは引き続き利用可能です。 4位：Catoクライアントアプリが最新の状態ではなかった Catoクライアントのバージョンが古いと不具合が生じる可能性がございます。 そもそも Catoクライアント最新バージョンはこれまでの不具合やバグを修正したもの になります。 そのため、Catoクライアントをご利用する場合、 基本的には最新バージョンにしておくことが推奨 です！ 最新版Catoクライアントのダウンロード方法 1．クライアントダウンロードサイトで最新のクライアントをインストールする ダウンロードサイトにて各OSの最新バージョンをダウンロードすることができます。 なお、最新バージョンをインストールする際、古いバージョンをアンインストールする必要はありませんので、 以下のダウンロードサイトから最新バージョンをインストールしてください！ ダウンロードサイト 2．CMAからダウンロード Access＞Client Rolloutから該当するOSの最新バージョンインストールすることができます。 Download ClientのプルダウンからDownload EXE or Download MSI等をクリックことで最新バージョンをダウンロード、 配布することが可能です！ ※CMAへのアクセス権が必要です。 5位：ネットワーク機器にて問題があった 社内ネットワークにてCatoクライアントを利用する際、そもそも Catoクライアントではなくネットワーク機器に問題 があった、、 などの事象が見受けられます。 具体的にはLANケーブルの断線、スイッチ、ハブの故障、そもそも終端装置にネットワーク機器が繋がっていなかったなど。。 また、ネットワーク機器のOSをアップグレードした結果、Catoクライアントが正常に繋がったなどもあります。 Catoクライアントを利用する際は、クライアントアプリだけではなく そもそものネットワーク環境を疑ってみる のも切り分けの一つとなります。 ネットワーク環境の切り分けを行う際は以下を確認してみましょう！ 確認項目 LANケーブルの交換 ネットワーク機器OSのアップグレード ハブ、スイッチの交換 インターネットに繋がるか Tips! Catoクライアントのエラーに関して、様々なエラーメッセージが表示される可能性がありますがCatoのアップデートに伴い、表示される文章や意味が変わる可能性があります。 以下のKB「 エラーメッセージ」「原因」「切り分け」 がまとめられております。 トラブル発生時はこちらのKBをご参考に！ Cato-Client-Login-Errors また、弊社ではCatoクライアントのトラブルシューティングに関する記事が他にもまとめられております！ ぜひこちらもご確認いただけますと幸いです！ Catoクラウド トラブルシュート ～Catoクライアントが繋がらないお悩みの方へ～ Catoクラウドをご利用いただいてるお客様から、よくいただくご質問に「Catoクライアントが繋がらないです」といったお問い合わせを頂きます。対処法や問題の切り分け方をご紹介いたします。 blog.usize-tech.com 2023.12.15 それでもどうにもならなければ… これまでご紹介した対処案でも改善されない場合、以下をお試しください！ 端末の再起動 Catoクライアントの再インストール 端末の再起動やクライアントの再インストールで解決されることが多々あります。 ただ、詳細な原因を調査する際、再インストールを行うとクライアントアプリのログが削除されてしまうため、 再インストール前にクライアントログを取得していただけますと幸いです。 VPN Clientの接続ログを取得する方法を教えてください   最後に 大抵の場合、ご紹介しましたトラブルシューティングで解決することが多いです。 サポートとしても、 まずご紹介したトラブルシューティングを実施いただいているか、という確認から入ります ので、実施している場合はその旨、問い合わせ時にご連絡いただけると時間短縮につながります。 弊社のサポート窓口までご相談いただく際は、早期解決のため是非ともご協力のほどよろしくお願いいたします！

こんにちは、広野です。 AWS Cloud9 は研修用途では非常に使い勝手が良かったのですが、AWS が新規アカウントへの提供を終了してしまいました。今回は私が試みた代替ソリューションの設計を紹介したいと思います。実装編は AWS CloudFormation テンプレートになりますが、続編記事として作成します。 インスピレーションを受けた記事 多くの有志の方々が AWS Cloud9 代替品の作成方法を記事にしてくれていまして、大変参考になりました。ですが中でも一番参考にしたのは AWS が提供してくれているハンズオンに含まれている IDE 作成テンプレートでした。 Workshop Studio Discover and participate in AWS workshops and GameDays catalog.workshops.aws Coder code-server という、VSCode を WEB UI で使用できるソフトウェアを Amazon EC2 インスタンスにインストールし、AWS CloudFront および nginx 経由で公開する構成になっていました。 私はそれを Elastic Load Balancing の ALB 経由で研修受講者に使用してもらいたいと思い、そのように作成しました。 アーキテクチャ VPC 周り code-server サーバを配置する VPC です。何の変哲もない一般的なサブネット構成にしています。 NAT Gateway は課金節約のため、1 つのパブリックサブネットにしか配置していません。 code-server サーバは 1 ユーザーあたり 1 台を割り当てます。図では 1 つしかありませんが、人数分作成される想定です。ALB はユーザー全体で共用します。 code-server のログインパスワードはインストール時に設定しますが、AWS Secrets Manager で生成したものを使用します。 ALB には HTTPS アクセスさせるため、図には書いていませんが独自ドメインを使用します。そのための SSL 証明書はそのリージョンの AWS Certificate Manager で作成されていることが前提になります。 ALB から EC2 インスタンスへの通信は 80 番ポート (HTTP) を使用します。 ALB はインターネットに公開されますが、研修用途を想定して会社のソース IP アドレスからのみアクセスできるようにセキュリティグループを設定しています。 ALB 周り ユーザーは、ALB に自分専用の URL でアクセスします。ただし、ドメインは共通で、パスに自分用の番号が入ったもの (ide1 など) を指定します。 ALB はパスベースルーティングで受け取ったパスからそのユーザーの Amazon EC2 インスタンスが所属しているターゲットグループに通信をルーティングします。 code-server 周り ALB はパスベースルーティングで通信を送信するとき、パスは受け取ったまま (図のケースでは /ide2/) でターゲットに送信します。code-server には存在しないパスなので、そのまま通信を code-server で受けてしまうと当然 not found エラーになります。 この問題を解決するために、nginx を間に挟み、ポート番号の変更とパスの削除をしています。やりたいことはパスの削除だけなのですが、1台のサーバ内に nginx と code-server が共存するためにはポート番号を別々のものにしないといけないため、nginx を 80、code-server を 8008 でオープンするようにしています。 出来上がり 出来上がると、以下のログイン画面が表示されます。 ログインすると、以下のように VSCode の画面がブラウザ上に表示されます。ホームディレクトリは AWS Cloud9 を意識して environment にしています。OS のターミナルも ec2-user で開いているのが見えますね。めでたし、めでたし。 続編記事 実装編記事が出来次第、この章を更新します。   まとめ いかがでしたでしょうか。 今回は概要編でしたので内容は浅いですが、設計の要点はご理解いただけるのではないかと思います。実装編では、具体的な設定に踏み込んで紹介します。 本記事が皆様のお役に立てれば幸いです。

本記事は 夏休みクラウド自由研究2025 8/12付の記事です 。 どうも、Catoクラウドを担当している佐々木です。 最近Catoクラウドを導入した複数の顧客で、導入時に同じトラブルが発生したので紹介します。   ※画⾯は2025年8⽉時点のものです。機能アップデート等で変わる場合がありますので、あらかじめご了承ください。   トラブル事例 Catoクラウドを導入した際、iPhoneやMac端末から社内リソース（社内サーバやADなど）にアクセスできないという事例です。 Windows端末では問題なく接続できる一方、Appleデバイスのみ接続に失敗するケースです。   ▼構成イメージ   発生する現象 iPhone、macOS端末から 社内サーバ（ファイルサーバ、AD、内部Webアプリ）へアクセスができない Catoクラウドには正常に接続され、インターネットアクセスは可能 IPアドレスを直打ちするとアクセスできる 一方、Windows端末ではすべて問題なくアクセスできる   原因 macOS/iOSの仕様が原因です。 「macOS Ventura」、および「iOS 16」以降 では、DNS over TLS（DoT）やDNS over HTTPS（DoH）に準拠したDNSサーバを検出すると、CatoのDNSサーバを含む他の DNSサーバを無視し、DoTおよびDoH対応のDNSサーバを利用します。 通常、社内リソースへのアクセスが必要な場合、Catoクラウド（CMA上）のDNS設定で社内リソース（ドメイン）宛のDNSフォワーディング設定を行いますが、 Catoの場合、DoTやDoHでのDNSフォワーディングをサポートしていません。 結果、インターネット上にあるパブリックなドメインに対するアクセスは可能ですが、社内サーバなどプライベートなドメインに対する名前解決はできなくなり、この事象が発生します。   DoH/DoTの主な制限事項 ・ DNSフォワーディングがサポートされていない ・ ドメイン名やアプリケーションベースのファイアウォールルールマッチングが正常に動作しない ・ DNSプロテクションが適用されない   解決策 Catoクラウド（CMA）で行える解決策が、 「２つ」 あります。 どちらか1つを設定すれば改善できますが、２つ同時に設定しても問題ありません。 Internet FirewallルールでDoT / DoHをブロックする DoTとDoHをInternet Firewallでブロックし、Cato経由でアクセスできないようにします。 Apple端末はDoT/DoHを利用できなくなり、代わりに UDPベースの通常DNS（CMAの設定値） を使うようになります。 結果、DNSフォワーディングが正しく動作し、内部リソースの名前解決が成功します。   ▼設定例 Security > Internet Firewallから以下のように設定します。   DNSの固定 Catoクラウド（CMA）で、DNSサーバを明示的に設定します。 　例：Cato DNS（10.254.254.1）をPrimaryDNSとして設定し、Secondaryには何も設定を入れない。 この設定により、8.8.8.8など外部のDNSがクライアントで自動的に設定されなくなり、DoT/DoHを利用できなくなります。   ▼設定例 Access > DNS Settings Policyから以下のように設定します。   Network ＞ DNS Settingsから設定すると、すべての端末（Windows端末含む）に設定が反映されるので注意！   まとめ 今回は導入時のトラブル事例共有でした。 ポイントをまとめると以下になりますが、本件に限らず事前検証は念入りに実施することを（個人的には）推奨します。   ・Appleデバイスから社内リソースにアクセスできない原因はAppleの仕様 ・ただし、Catoの設定で回避可能 ・事前にiPhoneやMacで接続テストを行って確認したほうがいいかもね！   上記以外の情報についても弊社の 「Catoに関するFAQサイト」 に多数情報ございますのでご参考にください。 よくあるご質問 | Cato Cloud ケイトクラウド - SCSK Cato SASE Cloud Platform. powered by SCSK cato-scsk.dga.jp   最後に、SCSKではPoCから導入、運用まで幅広くCatoに関する支援を行っております。 本番構成への移行を見据えたPoC構成や、PoCでつまづきやすい点のサポートなど、豊富な導入実績を基にご支援いたします。 ぜひお声がけください！

本記事は 夏休みクラウド自由研究2025 8/11付の記事です 。 こんにちは。角田です。 これまでSASEの概要やメリットなどを解説する記事を書いてきましたが、今回はその第3弾となります。 ※過去の解説記事は以下をご参照ください。 【SASE簡単解説】SASEとは？ 初心者が1から解説 SASE簡単解説シリーズ第1弾！　 「近年バズワードとして注目されていることは知っているが、調べてみてもよく分からない。」これを機にSASEを理解したい、という方に向けて、超初心者向けの「SASEとは？」を1から丁寧に説明していきたいと思います。 blog.usize-tech.com 2025.03.24 【SASE簡単解説】SASEのよくある懸念点と、導入しやすいタイミングを解説！ SASE簡単解説シリーズ第2弾！　 SASE導入を考える上で、誰もが気になる点を丁寧に解説します。「コストが高くなりそう」や「セキュリティが不安」といった懸念点の解消から、後半では、SASE導入を検討しやすいタイミングまで、具体例も交えて説明していきます。 blog.usize-tech.com 2025.05.02 今回は、SASEの中でも 今後特に市場拡大が見込まれる「シングルベンダーSASE」 について、そうでないSASEとの違いも含めて、以下のテーマでご説明します。 シングルベンダーSASEとは？ シングルベンダーSASEのメリット SASEの市場動向と今後について   シングルベンダーSASEとは？ まずは簡単に振り返りとなりますが、SASEとは「“ネットワーク”と“ネットワークセキュリティ”をクラウドベースで統合したもの」です。 2019年に、有名な調査会社であるGartnerによって提唱されました。 では、その中でも「シングルベンダーSASE」とは一体どういったものなのでしょうか。 深堀りして解説していきます。   シングルベンダーSASEとは？ まず、シングルベンダーSASEは「単一ベンダーにより、統合されたプラットフォームで、ネットワークとセキュリティの両機能をネイティブに提供することができるSASE」であると言われています。 少し難しい言い回しですが、分かりやすく言うと 「1つの会社でSASEの機能全てを提供できているサービス」 です。 ただし、単に“1社で全部入り”のサービスではなく、 “最初から統合されたプラットフォームとして設計されている”ことがポイント となります。　※詳しくは後述します。   マルチベンダーSASEとの違い シングルベンダーSASEがいれば、もちろん「そうでないSASE」、つまり「マルチベンダーSASE」も存在します。 マルチベンダーSASEとは、「様々な会社の製品を組み合わせてパッケージ化されたSASE」です。 例えば、SD-WANはA社製、SWGはB社製、CASBはC社製という構成で、これを1つの自社サービスとして提供しているような形態がマルチベンダーSASEとなります。 このようなサービスでは、以下のような課題が発生します。 管理コンソールやログがバラバラで、運用が煩雑 ポリシー設定が製品ごとに分かれ、整合性がない アップデートや障害も製品ごとに発生するため、利便性が低い 昨今多くの企業がSASEソリューションを提供していますが、その中にもマルチベンダーSASEは数多く存在します。 そして、そういったマルチベンダーSASEは、往々にして 「統合されていない」 ことが課題になりがちです。   シングルベンダーSASEの本質 では、「1つの会社で全て提供されているSASEであればよいのか」というと、それは本質的ではありません。 重要なのは ”最初から統合されたプラットフォームとして設計され、1つのエンジンで動いている” ことです。 例えベンダーが1社であったとしても、内部で使っているエンジンが“M＆Aによる買収や機能追加による ”継ぎはぎの構成”であった場合、本来の意味で「統合されている」とは言えません。 このような構成では、 結局上記で述べたような課題は 発生 しますし、 各機能間で通信の復号化と暗号化を繰り返す必要があるため、大きなオーバーヘッドも発生 します。 “最初から統合されたプラットフォームとして設計され、単一のエンジンで動いている”、 真に統合されたSASE は意外にも少ないのですが、 これこそが、シングルベンダーSASEの本質であると考えています。   世の中にはシングルベンダーSASEを謳う製品が多数ありますが、SASEを比較検討する際には、 「シングルベンダーSASE」という言葉だけに惑わされず、「真に統合されたSASEなのか」ということを意識して検討いただければと思います。   シングルベンダーSASEのメリット ここまで、シングルベンダーSASEの概要やマルチベンダーSASEとの違いを説明してきました。 続いては、マルチベンダーでなく、シングルベンダーSASEを選択することのメリットを以下3つご紹介します。 　① 全ての機能が完全統合されている 　② 機能追加が迅速に可能 　③ どの拠点でも同じ機能/品質を提供可能   メリット①：全ての機能が完全統合されている 前述の通り、 全ての機能が統合されていることが、シングルベンダーSASEの最大の特徴でありメリットです。 これにより、 ネットワーク、セキュリティのポリシーを簡単に統一 することができますし、 ログも一元化 されるため、 分析やトラブルシュートも効率的 に行うことができます。 また、 管理コンソールが統合されていることも大きなメリット です。 マルチベンダー型のSASEは、利用する機能によって管理コンソールが分かれていたりすることがあります。 利用者の立場からすると、“コンソールが統合されていて使い勝手の良い”という点も非常に重要なポイントとなります。   メリット②：機能追加が迅速に可能 シングルベンダーSASEは、統合されたエンジンを持っています。 そのため、新たな基盤の開発やアプライアンスの調達などをすることなく、容易に新機能の追加が可能です。 拡張性に優れ、IT概況の変化や新たなサイバー攻撃の流行に合わせて迅速に機能追加ができる という点も、シングルベンダーSASEの大きな魅力となっています。   メリット③：どの拠点でも同じ機能/品質を提供可能 マルチベンダーSASEの場合、各種機能が他社製品や他社基盤に依存するため、一部地域では拠点間通信ができない、あるいはセキュリティ機能（IPSやCASBなど）が利用できない といった制約が発生してしまうことがあります。 そして、例えば「日本にはCASBが提供されていないけど、どうにか使いたい」という場合には、一度CASB機能がある地域（海外など）にトラフィックを飛ばし、CASBによるセキュリティチェックや可視化を行った上で、また日本にトラフィックを返す、といった方法を取ることになりますが、この方法では非効率な通信が頻発し、 通信遅延や帯域の無駄使い が発生します。 シングルベンダーSASEであれば、サービスを提供するすべての地域に同一のプラットフォームを展開していますので、 どの拠点からでも同じ機能を、同じ品質で利用することができる のです。   SASEの市場動向と今後について ここまでシングルベンダーSASEの概要とメリットを説明してきました。 最後は、そんなシングルベンダーSASEの 市場動向や今後の動き についてお話したいと思います。   シングルベンダーSASEのリーダー　Catoクラウドについて シングルベンダーSASEの市場動向ということで、まずは Catoクラウド についてご紹介させてください。 Catoクラウドは、GartnerがSASEを定義した2019年よりも前から、SASEのアーキテクチャでサービスを提供している、世界初のシングルベンダーSASEとなります。 全世界90拠点以上に完全統合されたプラットフォームを展開しており、どこからでも同一のネットワーク/ネットワークセキュリティ機能を適用することが可能です。 Catoクラウド 変化する働き方に必要な「ゼロトラスト」を実現する「ネットワークとセキュリティを統合したクラウドサービス(SASE)」であるCatoクラウドをご紹介しています。 www.scsk.jp Gartnerのレポートでは、Catoクラウドの提供ベンダーである Cato Networks社は、シングルベンダーSASEのリーダーに認定 されています。 SASEを検討する際には、ぜひCatoクラウドにご注目ください。 Cato Networksが2025年度Gartner® Magic Quadrant™のシングルベンダーSASE部門でリーダーに再び選ばれました  SASEのリーダーであるCato Networksは、2025年Gartner® Magic Quadrant™のSASEプラットフォーム部門で再びリーダーに選ばれたことを発表しました。 www.catonetworks.com   シングルベンダーSASEの市場動向 はじめに宣伝から入ってしまいましたが、 シングルベンダーSASE全体の市場動向 としてはどうでしょうか。 上記Gartnerのレポートでは、2028年までに新しくSD-WANを購入する企業の70%がシングルベンダーSASEを採用するという市場予測がされています。　※2025年現在では25%のようです。 また、SCSKでは日本企業を対象とした独自の「SASE実態調査」を毎年実施しているのですが、SASEの認知度や導入率に関しても、年々増加傾向にあります。 今後、 シングルベンダーSASEを採用する企業は大きく増えていく ものと考えられます。   SASEの領域拡大について 近年のSASE全体の動きとしては、どんどん機能拡充が進み、既存領域（ネットワークやネットワークセキュリティ）から新たな領域に進出し始めているような印象を受けます。 実際にCatoクラウドでは、すでにエンドポイントであるEPPや、各種セキュリティログを統合分析するXDRの機能がリリースされています。 その他にも、クラウドセキュリティであるCSPMと統合したり、生成AIを取り入れた機能拡充の動きも見受けられます。 SASEソリューションのカバーする領域がどんどん広がってきているからこそ、“統合されたプラットフォーム”を持つシングルベンダーSASEの価値は、今後より高まっていくと考えています。   おわりに いかがでしたでしょうか？ 今回は第3弾ということで踏み込んだ内容になってしまいましたが、「もっと基礎から知りたい！」という方は、冒頭に紹介した第1弾、第2弾のブログ記事に加え、SCSKのYoutubeチャンネルで公開している初心者解説動画も参考にしてみてください。 - YouTube YouTube でお気に入りの動画や音楽を楽しみ、オリジナルのコンテンツをアップロードして友だちや家族、世界中の人たちと共有しましょう。 www.youtube.com - YouTube YouTube でお気に入りの動画や音楽を楽しみ、オリジナルのコンテンツをアップロードして友だちや家族、世界中の人たちと共有しましょう。 www.youtube.com   また、SCSKは長年に渡りSASEやCatoクラウドに関するセミナーも定期開催しています。 直近では 2025/8/27(水) に、Catoクラウドのデモセミナーを開催します。 Catoクラウドの主要機能をたっぷり2時間 ご覧いただけますので、ご興味がある方は、ぜひご参加ください。 Catoクラウドデモセミナー ver.3 ～Catoクラウドの主要機能を2時間で網羅～ 本セミナーでは、世界初のSASEである「Cato（ケイト）クラウド」の主要機能をたっぷり2時間、デモ形式でご覧いただけます。今回のCatoクラウドデモセミナーは、これまでのデモセミナーから更に最新機能等の情報を盛り込み、ver3にリニューア... www.scsk.jp   もちろん、個別のご紹介・ご説明も可能です。 ご要望の場合は、 問合せフォーム からお気軽にご連絡ください。

  本記事は 夏休みクラウド自由研究2025 8/10付の記事です 。 こんにちは　SCSK中山です。   今回は夏休みの自由研究ということで、自由研究チックな内容にしたいと思いまして、AWS上でCloud InterConnect × vSocketで冗長構成を組めるかを試してみようかと思います。 通常、Cato Networksを利用してAWSなどのクラウドサービスと接続する場合、「Cloud InterConnect」または「vSocket」のどちらかを選択します。冗長化を組む際も、Cloud InterConnectであればDirect Connect回線を2本に、vSocketであればvSocketインスタンスを2台に、といった形で同一の接続方式で構成するのが標準的です。 これら2つの異なる接続方式を組み合わせて冗長化に利用することは、Catoの推奨構成ではありません。 しかし、「 技術的には本当に不可能なのか？ 」という純粋な好奇心から、今回はその実現可能性を考察し、記事にまとめてみることにしました。 先に申し上げますと、本記事は現時点では 机上考察 です。検証はこれからとなりますので、あらかじめご了承ください。   考慮すべきポイント ：動的なルーティング切り替え この構成を実現する上での鍵は、「 どのようにしてルーティングを動的に切り替えるか 」です。 Catoでは、Cloud InterConnectとvSocketを利用する場合、それぞれ別の「Site」として登録・管理します。 今回の構成では、通常時はCloud InterConnectを利用するSite（以下、Site A）をメイン経路とし、Site Aの障害時にのみvSocketを利用するSite（以下、Site B）へルーティングを自動で切り替える必要があります。この自動切り替えをどう実現するかが、最大のポイントとなります。   案①BGPを使った方法  ネットワークの経路を動的に切り替えるといえば、まず思い浮かぶのが BGP (Border Gateway Protocol) です。 CatoはBGPをサポートしているため、AWS側との連携が焦点となります。   1. Cloud InterConnect (Site A) 側 こちらは比較的シンプルです。AWS Direct ConnectおよびTransit GatewayはBGPによるルート伝播に標準で対応しているため、Site AとAWS間の経路交換(青色矢印)はBGPで問題なく実現できるでしょう。 参考: BGP for AWS（クラスメソッド） TransitGWを通してDirectConnectが生きているときは通信を可能としてくれるはずです。   2. vSocket (Site B) 側 ここが難関です。vSocketはVPC内に配置される仮想アプライアンスであり、それ自体がBGPスピーカーとして機能するわけではありません。そのため、AWSからCatoのSite BへBGPで経路情報を広報するには、何らかの仕組みをVPC内に別途構築する必要があります。 考えられる方法は以下の通りです。 BGPソフトウェアを搭載したEC2インスタンスを立てる VPC内にBGPルーティングソフトウェアをインストールしたEC2インスタンスを別途用意し、AWSのネットワークとCato Site Bの間でBGPピアを確立させる方法です。 Amazon VPC Route Serverを利用する AWSのマネージドサービスである「 Amazon VPC Route Server 」を利用する方法も考えられます。これは、VPC内のネットワーク仮想アプライアンス（NVA）とBGPで動的にルーティング情報を交換するためのサービスです。私も詳細は分からないので、以下記事などを見て貰えればと思います。 参考： VPC Route Server の設定を一通りやってみた（サーバワークス） …と、これでCatoへのルート伝播はできたとして、話は終わりませんでした。。 実はもう一つ、大きな課題があります。それは「 AWS内でのvSocketへの経路 」です。AWS上のEC2などからCato側へ通信するとき、通常はDirectConnectへ、障害時にはvSocketへ向かうように経路を切り替える必要があります。この切り替えをTransit Gatewayにお願いしたいのですが、vSocket側の経路をTransit Gatewayに動的に伝えるのが、だーいぶ厳しそうです。   この課題を解決する方法を、2つほどを考えてみました。 BGPだけで頑張る方法（GREトンネル活用） 1つ思いついたのが、BGPを話せるインスタンスを立てる方法の応用です。 Transit Gatewayは、実は「 Transit Gateway Connect 」という機能を使うと、 GREトンネル 経由でVPC内のインスタンスとBGPを話すことができます。 これを利用して、 VPC内にBGPとGREに対応したインスタンス（NVA）を立てる このNVAとTransit Gatewayの間でBGPピアを張る NVAからvSocketへの経路を広報するときに、 ASパスプリペンド （ASパスを長くして経路の優先度を下げる技術）を設定する こうすれば、通常時はASパスが短いDirectConnect側が優先され、障害時にだけvSocket側の経路が使われる、という自動切り替えが実現できる(？)気がします。。   BGPは諦めて、障害検知で静的ルートを操作する方法 BGPだけで全部やろうとすると複雑すぎるのでBGPに固執せず、別の方法を組み合わせる手もあります。 これは案②にも通じる話ですが、 「DirectConnectがダメになったことをCloudWatchなどで検知して、Lambdaを動かし、Transit GatewayのルートテーブルにvSocket向けの静的ルートをAPIで追加/削除する」 というやり方です。 これなら、複雑なBGP設定を回避しつつ、やりたいことは実現できそうですね。   CatoのSource NATを活用する方法 こちらの方法は かなり条件付き になりますが、AWS側の複雑な設定を回避できる面白い案なので紹介してみます。 AWSをCatoで利用する場合って、多くはAWS上にいるサーバーにWAN側からアクセスしたい、というケースかと思います。この「 外から中への通信 」がメインなら、使えるかもしれない技です。 どうやるかというと、vSocketが持っている「 Source NAT 」機能を使います。 CatoのSocket（vSocket含む）は、通過する通信の送信元IPアドレスを、Socket自身のIPアドレスに変換するNAT機能を持っています。 これを利用して、 WAN側から来た通信がvSocketを通過するときに、送信元IPをvSocketのIPアドレスにNATで書き換えてしまいます。 AWSのサーバーから見ると、通信は「vSocketから来た」ように見えます。 サーバーからの応答（戻りの通信）は、当然vSocketに向かいます。Transit GatewayもvSocketのいるVPCへの経路は知っているので、問題なくルーティングできます。 応答を受け取ったvSocketは、元の送信元IPアドレスにちゃんと戻してからWAN側に返してくれます。 こうすれば、Transit GatewayでBGPや静的ルートをごちゃごちゃ設定しなくても、戻りの経路をvSocketに強制的に向けることができる、というわけです。Catoの機能をうまく使った裏技的な感じですね。 ただ、最初に「条件付き」と言った通り、大きな制約があります。 この方法は、 AWS側から自発的にWAN側へ通信を始める場合には使えません。 (Transit Gatewayのルートテーブルには他拠点宛のルーティング情報がないため) あくまで「 外から中 」へのアクセスがメインで、「 中から外 」への自発的な通信がない、という環境であれば、かなりシンプルな解決策になるかもしれませんね。   色々書いてきましたが、正直なところ調べながら書いたので、実現度はだいぶ低いのかなと思ってます。 # @Amazon Q ファクトチェックして 案②Catoのルーティングを無理やり変更する方法 BGPを使わない方法も一応、思いつきました。 最初に述べた通り、この構成のポイントはルーティングを切り替えることになります。 CatoではSiteへのルーティングは各Siteの設定よりできるので、手動でもそこの設定を切り替えることでSite AからSite Bへルーティングを切り替えることができます。 ただ、それでは芸がないので、何とか自動化する方法がないかを考えてみました。   このアプローチのポイントは、「障害検知」と「ルーティング変更の実行」を自動化することです。 1.障害の検知方法 まず、Cloud InterConnectがダメになった時を検知する方法はないかを考えてみます。 Cloud InterConnect（Site A）の障害を検知する方法として、以下の2つが考えられます。 Cato側での検知:  Catoの「 Link Health Rule 」機能を利用します。Siteのダウンといったイベントを検知し、指定したWebhook宛に通知を送信できます。 AWS側での検知:  Amazon CloudWatchを利用します。Direct Connectのメトリクス「 ConnectionState 」（0=down, 1=up）を監視し、CloudWatch Alarmを発報させます。 参考:  Monitoring with Amazon CloudWatch – AWS Direct Connect   2. ルーティング変更の実行方法 続いてSiteのルーティングの変更の自動化方法について考えてみます。 こちらはCatoのAPIを使えばいけそうです。 参考: Cato API Documentation 障害を検知したら、Cato APIを呼び出し、以下の通りルーティング設定を書き換えるLambdaを作成します。 障害発生時:  Site Aから対象VPC/SubnetへのルートをAPIで削除し、Site Bへ同じルートを追加する。 障害復旧時:  上記とは逆の処理（Site Bのルートを削除し、Site Aのルートを再追加）を実行する。 これだけだと「案①」でも触れたAWSからCatoへの戻りの通信経路が切り替わりませんので、LambdaでAWSのAPIも叩いてもらい、Transit Gatewayのルートテーブルを書き換えてもらいます。 具体的には、Lambdaのプログラムの中で、 障害発生時:  Transit Gatewayのルートテーブルに、Catoのネットワーク宛てのネクストホップをvSocket側に向ける静的ルートを追加する。 障害復旧時:  追加した静的ルートを削除する。 という処理を追加します。   全体像としては、以下のようになるかと思います。 障害検知:  CloudWatch Alarm (Direct Connect) または Cato Link Health Rule (Webhook) トリガー:  CloudWatch Alarm Action または Amazon API Gateway 実行:  AWS Lambda 処理内容: Lambda関数が  Cato API  をコールし、Cato側のルート情報を書き換え Lambda関数が  AWS API  をコールし、 Transit Gatewayのルートテーブル を書き換え こっちはいけそう度高めで自信はあるのですが、Lambdaがやることも増えますし、プログラムを書かないとなので、そこだけハードルは高そうです。 #AI時代ならLambdaぐらいのコーディングだったら余裕だったりしますかね。。   まとめ 今回は、Cato Cloud InterConnectとvSocketを組み合わせたハイブリッドな冗長構成について考察しました。 どちらの案も、Cato単体の機能というよりは、AWSのサービス（BGP関連サービスやLambda、CloudWatchなど）を深く活用する高度なアプローチとなりました。 しかも、今のところ机上の話なので、実際に実現できるか怪しいので、 Catoが公式に推奨する標準構成（Cloud InterConnectであれば回線の冗長化、vSocketであればインスタンスの冗長化）を選択することが、最もシンプルかつ確実な方法 で、やはり一番良さそうです。 #検証はできたら追記していく所存ではあります。

本記事は 夏休みクラウド自由研究2025 8/9付の記事です 。 この記事では、CatoクラウドでのBGPの使用事例をご紹介します。 早速ですが、Socketに設定するLAN側のルーティングは「Static Route」と「BGP」が使用できます。 Catoクラウド内はBGPでルート交換がされており、お客様拠点のCato Socketに設定するLAN側のルーティング情報をCatoクラウド側に再配送することで、ネットワーク全体で到達性が確保できるという仕組みです。 ただ、お客様拠点内でBGPを使用しているケースは多くはなく、実際にもStatic Routeの利用がほとんどです。 Static RouteによるSocket拠点のルーティング 図.1は、データセンターの3スイッチに複数のVLANが設定されており、Cato SocketからL3スイッチにVLAN-a/b向けのルーティングを設定している例です。Socketに設定したルーティングは、自動的にCatoクラウドに再配送されるので拠点XYZのSocketはその経路を認識しており、DC拠点のVLAN-a/b宛ての通信が発生した場合は、DC拠点のSocketに転送します。 図.1 Static Routeの再配送 では、BGPの使用例を3つ紹介します。 BGPの使用例 – Socket拠点のルーティング 図.1で示したDC拠点内のStatic RouteをBGPに置き換えることもできますが、VLAN数が少なければStatic Routeで十分です。 ただし、VLAN数が多い場合や、Catoクラウド移行時には、BGPによるルーティング制御の方が手間がかかりません。 図.2は、既存ネットワークからCatoクラウドへの移行時の例です。DCをハブ拠点として、DC内のL3スイッチでルーティングを制御している場合、拠点Xを既存WANからCatoクラウド接続に切り替える際に、Static Routeであれば拠点切り替えの度にDCルータでルート切り替え作業が発生しますが、BGPを使用していればその作業が不要になります。 図.2では、拠点Xを既存WAN→Catoクラウドの移行を示しているのですが、WANルータをCato Socketに変更し、WANルータのLAN側アドレスをCato Socketに踏襲すれば、ルーティングに関する作業は一切不要となります。 図.2 Socket拠点のBGP利用イメージ 補足すると、このように拠点LAN内の構成やルーティング設定の変更なく移行できる点は、Catoクラウドの強みです。 BGPの使用例 – IPsecサイトの冗長 CatoクラウドとIPsecで接続するサイトのリンクの冗長化を目的として、BGPを使用する例をご紹介します。 実際の事例としては、このパターンが一番多いと思われます。 現在、CatoのvSocketは、AWS, Azure, GCPで作成する事が可能ですが、その他のクラウドをプライベート接続する際は、IPsecによる接続となります。（クラウド側でIPsec接続するサービスがある事が前提です） Socket / vSocketはCato PoP間のトンネル接続が切れると自動で別のPoPに接続しますが、IPsec接続はトンネルが切れたら切れっぱなしです。これを避けるために、Catoは別PoPに2本のトンネルを張っておくことを推奨しています。 その時、Cato～クラウド間でBGPを使用しておけば、トンネルが1本切れても残りのトンネルに自動で迂回させることができます。 図.3はOCIとの接続で、OCIのSite-to-Site VPNを使用して2つのIPsecトンネルで冗長リンクを構成した例です。 図.3 OCIとのIPsec接続例 BGPの使用例 – Cloud Interconnectサイトの冗長 Cloud Interconnectは、Cato版ダイレクトアクセスです。現在はAWS, Azure, GCP, OCIとCatoクラウドを専用線で接続できます。 この場合も、上記図.3と同様の構成となります。 Cloud Interconnectについては、次の記事を参照下さい。 Catoクラウド の Cloud Interconnect（旧 Cross Connect） について Catoクラウドの Socket/vSocket、IPsec以外の拠点接続方法である”Cross Connect”のサービス概要について紹介します。 blog.usize-tech.com 2023.08.25 vSocket × Cloud Interconnect 徹底比較 パブリッククラウドをCatoクラウドへ接続する方法「vSocket」と「Cross Connect」を性能面・コスト面等から比較します。 blog.usize-tech.com 2023.11.29 BGPのパラメータ では、BGPのパラメータを見てみましょう。ここでは、Socket拠点のルーティグでBGPを使用する場合を例にします。 設定箇所は各サイトのSite Configuration >BGPで、設定項目は以下の通りです。       内容 General Name L3機器（BGPネイバー）毎にBGPピアを設定できるので、その識別の為にユニークな名前をつけます。 ASN Peer L3機器側のAS番号を設定します。プライベート空間なので64512～65534の中から割り当てます。既にBGPを使用している場合、既存のAS番号を設定可能ですがCato側のAS番号を被らない事、またBGPピアの拡張性を考慮したナンバリングにする必要があります。 Cato Cato側のAS番号を設定します。Catoのデフォルト値は64515なので、既存ネットワーク側と重複しなければデフォルト値で登録します。 IP Peer L3機器のアドレスを設定します。もちろんSocketのNative IP Ranges内でないとエラーとなり設定できません。 Cato 自動設定なので設定する必要はありませんが、結局のところSocketのLANアドレスが割り当てられます。 注）SocketのHA構成時はVRRPの共有アドレスとなります。Socketの実アドレスではBGPネイバーを確立する事ができません。 Policy Advertise Default route SocketからL3機器にデフォルトルートを広告します。 All routes Catoに接続する拠点やモバイルアドレスレンジの全ルートを広告します。   Summary routes 複数ルートを単一のサマリールートとして広告できます。 Accept Dynamic routes BGPネイバーからCatoが動的に学習するIPレンジを指定できます。所謂ルートフィルタの設定がここで出来ます。 NAT Perform NAT to public IPs この設定を有効にすると、そのBGPネイバー経由で送信される全ての送信トラフィックに対してSource NAT（SNAT）が実行されます。 Catoからのトラフィックの送信元IPアドレスを統一する事ができます。 Additional Settings MD5 Auth BGPセッションでMD5認証を使用できます。事前共有秘密鍵を使用してBGPピア間の認証を行う事ができます。 Metric BGPネイバーの優先度を決定する値で低い方が優先されます。デフォルト値は100です Hold time BGPネイバーがダウンしていると判断するまでに待機する時間です。デフォルト値は60秒です。 Keepalive interval BGPセッションを維持するために、BGPネイバーにキープアライブメッセージを送信する間隔です。デフォルト値は20秒です。 Track Email Notification BGPセッションの確立や切断が発生した際に、設定してあるメーリングリスト等に通知メールを送信する事ができます。   最近のBGPに関するアップデート情報 毎週公開されるCatoのアップデート情報から、BGPに関するものを拾ってみました。 以下は2024年後半から現在までのものです。利用ニーズはそんなにないと思うのですが、その割には機能強化されてるなという印象です。 ・サイト接続の制御を強化するために、BGPの構成および監視をサポートするAPIを追加 ・BGPルートを1つのサマリールートに集約 ・BFDによるBGPコンバージェンスの高速化 ・4 Bytes-ASNピアでBGPを確立する さいごに BGPの利用は、Socket拠点のルーティングよりもIPsecサイトの冗長化の方がニーズが高いように思われます。現在vSocketが利用できるAWS、Azure、GCPではvSocket接続すればよいのですが、その他のクラウドとの接続はIPsec接続になります。IPsecのシングル接続の場合、Cato PoPのメンテナンスによりリンク断となるので冗長化は必須です。その時にはこの記事を参考にしていただければ幸いです。