こんにちは。SCSKの星です。 今回はServiceNowのバージョンアップ期限に間に合わない場合の対応方法について書いていきます。 はじめに(注意) バージョンアップには期限があります。基本的には期限内に終わらせることが好ましいです。 ※期限内のスケジュール変更や期限の確認方法についてはこちらをご覧ください。 → 【ServiceNow】バージョンアップのスケジュール変更方法 – TechHarmony ただどうしても期限に間に合わない場合もあると思います。その場合はServiceNowにお願いして延長してもらうことも可能です。 ただ、毎回この方法が有効なのかもわかりませんし、場合によっては拒否されてしまうこともあるようです。 そもそもServiceNowの担当者にご迷惑をおかけするのも、あまり望ましくありません。ですので、 「この方法でServiceNow社に延長お願いすればいいや」と思うのではなく、業務上の都合や対応日程など、どうしてもバージョンアップが間に合わなかった場合の手段 としてご認識ください。 延長申請手順 延長申請フォームを要求する 延長をするには、NowSupportで延長申請フォームのリンクをもらう必要があります。 そのためまずはNowSupportにログインします。 https://support.servicenow.com/now ※誰でも作成可能なServiceNowIDではなく、NowSupport専用のアカウントが必要です。わからない場合はライセンス管理者にお問い合わせいただくとよいかと思います。 ログイン後、上部にあるタブから インスタンス > インスタンスダッシュボード を開きます。 インスタンスダッシュボードからバージョンアップを延長したいインスタンスを選択します。 予定されている変更一覧から、メジャーバージョンアップに関するものの変更番号をクリックすることで開きます。 「Family EOL Upgrade…」と書いてあるのが該当します。 開いた変更スケジュールページのアクティビティタブにバージョンアップが間に合わない旨のメッセージを送ります。 こちらにメッセージを送ることでServiceNow担当者が内容を確認し、延長申請フォームのリンクを送ってくれます。 下の図はVancouverバージョン時に延長をお願いした時の例です。 延長願いを出すと、バージョンの期限切れに関する変更チケットに延長申請用のフォームURLが共有されます。 Xanadu→Zurichバージョンアップの際のチケットの名前は「2025 Xanadu End of Life Upgrade」でした。 延長申請用URLが記載されたメッセージは以下の通りです。 ※もしかしたら「Family EOL Upgrade…」のチケットではなく、既にチケットが作成されていれば「2025 Xanadu End of Life Upgrade」チケットに直接延長願いをした方が良いかもしれません。試したことがないのでわかりませんが… 延長申請フォームを記入する ServiceNowから延長申請フォームリンクを共有いただいたら、そちらを記入していきます。 全項目必須回答となっており、不完全な回答を送信すると延長申請は却下されるそうですので慎重に回答ください。 質問は選択肢式の設問が多く、希望延長日時や期限内にバージョンアップできない理由、バージョンアップ計画などについて計22項目聞かれます。また英語での質問・回答になりますのでご注意ください。 またこの際に CISOまたは情報セキュリティ担当者の氏名と連絡先情報を記入する必要 があります。 事前にどなたが該当するか等の確認・調整が必要な場合がありますのでご注意ください。 フォーム送信後、審査にかけられパスすれば自動的に希望した日時でバージョンアップがスケジュール設定されます。 以上となります。この記事が役に立つ場面がないことが理想ですがどなたかの役に立てば幸いです。
こんにちは、ひるたんぬです。 この度「 AWS re:Invent 2025 」に参加できることになりましたので、現地での出来事や参加したセッションについてのレポートをお送りしたいと思います! 今回は、帰国の路と振り返りをしていきます! あっという間の帰国… 帰国時は午前4時前の集合でした。 私は寝てしまうと起きられないリスクがあったので、集合時刻までは寝ずに過ごしました。 ▼ 帰国前の預け荷物。半分空けたところ(& 現地で消費して空いた部分)が全て埋まるくらいの荷物です! ※ 空港で計量したところ、アメリカ国内線の手荷物重量制限ギリギリでした…(49.5 / 50 ポンド) ▼ 行きと同様、空港まではバスで移動します。 ▼ チェックイン後、外を眺めると朝焼けが綺麗でした。 ▼ 国内線でサンフランシスコ国際空港へ移動。 到着後は、トラムで国際線ターミナルへ移動します。 ▼ 国際線のチェックイン。 見慣れた日系企業のロゴを見て少し安心しました。 ▼ 成田空港到着! 約11時間のフライトでしたが、機内食以外は寝ていたためあっという間に着いてしまいました。 荷物受取時に、スーツケースの持ち手が手前に揃えられている姿は、やはり日本のおもてなしの心なのだなと改めて実感しました。 振り返り 最後に、今回のAWS re:Invent 2025に参加した振り返りをしていきます。 参加したセッション 今回は以下のセッションに参加しました。 それぞれのレポートについては、リンク先をご参照ください。 KeyNote Opening Keynote with Matt Garman A Special Closing Keynote with Dr. Werner Vogels WorkShop Optimize mission critical workloads with CloudWatch MCP & Amazon Q CLI Build trustworthy AI applications with Amazon Bedrock Guardrails GameDay・Jam The Frugal Architect GameDay: Building cost-aware architectures AWS Jam: DevOps & Modernization AWS Jam: Generative AI その他イベント AWS re:Invent 5k Race Japan Night re:Play 初参加ということに加え、過去に参加されていた方から「現地でしか体験できないことを優先するべき」というアドバイスをいただいていたため、WorkShopやGameDay・Jamなどのセッションを中心とし、空き時間もExpo見学やHouse of Kiroなど、現地でしかできない体験をするようにしていました。 その結果、re:Inventのスケールの大きさを実感しつつ、国を超えた多くの交流をすることができました。 この経験は、今後の私のAWSに対する学習意欲を間違いなく高めてくれました。 改めて、今回このイベントに参加できたことを嬉しく思います。 持ち物について この連載の初回に、私の持ち物についてご紹介しましたが、帰国した今、改めて持ち物について振り返りをしていきます。 あくまで、私個人の振り返りとなりますので、要・不要は個人によって大きく異なる点ご了承ください。 https://blog.usize-tech.com/reinvent2025-report-1/#toc1 持って行って良かったもの・持っていけばよかったもの 泊数分の着替え → 洗濯する時間はほとんどなかったので、服装に関しては日数分持って行って正解でした。 保湿グッズ → 砂漠地帯ということは油断ならなかったです。顔については保湿グッズを持っていったので良かったですが、手については持っていっていなかったため、最終日付近はささくれが大量発生しました。 リップクリーム → 保湿グッズと類似するところもありますが、普段唇のケアをあまりしない私にとって、初めてリップクリームの重要さを知るきっかけとなりました。それくらい必携なものです。 ボディバッグ → 手荷物検査が厳しいところでは特に役立ちました。現地では中身をすべてチェックされることもあるので、小さいに越したことはないです。 日本のお菓子 → GameDayや食事会場で会話した外国の方にお渡ししました。これをきっかけに会話が弾むことが多かったので、持って行って大正解でした。(「お菓子外交」と名付けていました。) 水 → 会場内では水の補給ができますが、ホテル内などでは必須でした。帰りはなくなっているので、持って行って損はないと思います。 ※ 現地調達もできますが、値段や水との相性のリスクを考えると、持って行ったほうが良いと思います。 サンダル → 機内やホテルはこれで快適に過ごせました。サンダルでもそこそこ歩くため、履き慣れたサンダルだとより良いかと思います。 ヘッドホン・アイマスク → 特に機内で睡眠する際に重宝します。アイマスクは近くの席の方が読書灯を使用されると、そこそこ眩しいので必須でした。 歯ブラシセット → 機内で快適に過ごせるという点で、私は持って行って正解だと思いました。 なくても良かったもの 折りたたみ傘 → 今回は雨が降ることもなかったですし、会場内はほとんどが屋内移動になるので不要かなと思いました。事前に天気予報などをみて、降りそうだったら持って行く、などでも良かった気がしています。 ポータブル給湯器・粉末のお茶 → 今回は三日目くらいに温かいお茶が飲みたくなったので使いましたが、必須というものではありませんでした。 保湿マスク → 私は普通のマスクで問題ありませんでした。ホテル室内でも、就寝前に多めに水分を摂ることで問題なく過ごすことができました。 のど飴 → 会場内で頻繁に水分補給を意識すれば、特段不要かと思います。 終わりに 出発から到着まで計8日間の出来事でしたが、最初から最後まで大変充実した日々を過ごすことができました。 私自身は周りの経験者の方の多くの助言によって、今回のイベントを楽しく、そして有意義に過ごすことができたので、今度は私もこれからre:Inventに参加される方向けにアドバイスをしていけたら良いなと思っております。 本記事が、来年以降re:Inventに参加される方の参考に少しでもなれば幸いです。 最後までご覧いただき、ありがとうございました!
本記事は TechHarmony Advent Calendar 2025 12/9付の記事です 。 Catoクラウドの管理機能「Advanced Groups」について紹介します。 はじめに:GroupsとAdvanced Groups Catoクラウドの設定、運用管理を行う上で、「『工場』に該当する拠点からのアクセスのみを許可/拒否するようにしたい」「いくつかの特定IPレンジに対するルールを設定したい」など、複数の対象をひとまとめに扱いたいという状況に直面することが考えられます。 こういった需要に応える機能が、2025年に入ってから実装された「Advanced Groups」です。 ……しかし、Catoには以前から同じような用途の「Groups」機能が存在していました。 「Advanced Groups」は「Groups」の名前を変えたものではなく、別機能として従来の「Groups」と共存しています。 では、何が違うのか? この記事では、「Advanced Groups」がどうAdvancedなのか、これまでの「Groups」との違いを解説していきます。 Advanced Groupsのメリット 「Advanced Groups」には、既存の「Groups」よりも優れた点が複数存在します。 メンバーにできる属性が多い 「Groups」と「Advanced Groups」は、メンバーとして入れられる項目の属性が異なります。 2025/12現在、「Advanced Groups」でしか指定できない属性が存在する一方で、逆はありません。この点においては、「Advanced Groups」は既存の「Groups」を上回っています。 なお、「Advanced Groups」にて指定できる属性は今後も追加予定とアナウンスされています。 「Groups」での属性名 「Advanced Groups」 での 属性名 備考 Site Site Network Interface Network Interface Interface Subnet Site Network Subnet Advanced Groupsでは、 「Interface Subnet」と「Grobal Range」が 「Site Network Subnet」に統合されています。 Grobal Range Floating Subnet Floating Subnet CMAの[Resources] > [Floating Ranges]にて定義したFloating Rangeを選択できます。 Hosts Hosts 各Siteの[Site Configuration > Static Host Reservations]にて、Static Hostとして登録したHostsを選択できます。 – Global IP Range CMAの[Resources] > [IP Ranges]にて定義したIP Rangeを選択できます。 「Advanced Groups」でしかメンバーにできない属性 です。 メンバー属性の識別機能 「Groups」「Advanced Groups」は共に様々な属性のオブジェクトをまとめて登録することができますが、それぞれの属性は使用する目的が微妙に異なります。 例えば、「Link Health Rule」はSiteの状態を監視して条件を満たした場合にメールで自動連絡をさせることが可能な機能です。この機能が「Source」として指定する対象は当然Siteであり、IPレンジでの指定には対応していません。 しかし、上記の状況で「Source」としてGroupsを使用すると、IPレンジがメンバーとして登録されているGroupを 対象に指定できてしまいます 。 幸い、この例であればCato側で無視されるため問題は生じませんが、誤設定に気が付かない、思わぬ不具合の引き金になるといったリスクが存在します。 「Advanced Groups」はこの問題を解決します。 Catoが自動的に「メンバーと設定しようとしている項目に互換性があるか」をチェックし、 互換性のないAdvanced Groupは選択肢に表示されない ようになっています。 さらに、何らかのポリシーに利用されているAdvanced Groupは、 互換性が無くなるようなメンバーの追加がブロックされる ように制御されます。 不具合の危険を排除できるほか、使えない属性のGroupが大量表示されて本命を探すのが大変……といった悩みも解決できるうれしい機能です。 充実した管理機能 「Advanced Groups」は、既存の「Groups」と比べてUIや管理機能が大幅に向上しています。 簡単に判別できる一覧UI 従来の「Groups」の一覧は、名前とDescriptionだけが表示される仕様です。 このため、似たような名前のGroupが多数存在する場合、「どれがどれだかわからない」問題が発生する恐れがありました。 もちろんDescriptionに詳しく書けば対策にはなりますが、更新されているかどうかまでは中を見なければわかりません。 一方、「Advanced Groups」は、入っているメンバーの属性と数、最終変更日、変更者まで一覧で確認できるようになりました。 これにより、各Advanced Groupがどのような目的のものなのか、大幅に判別しやすくなっています。また、最終変更日が確認できるため、「許可していない対象を勝手に追加する」といった行為が万一発生した場合でもすぐに特定可能であり、変更者表示から誰の作業で変更されたのかも確認可能です。 セキュリティ面も大きく向上している と言えます。 RBAC機能に完全対応 「Advanced Groups」は、RBAC(Role-Based Access Control)機能に対応しています。 CMAの[Account] > [Administrators]から、管理者ユーザ毎に、Advanced Group個別で編集権限 / 閲覧権限を付与可能です。大きな組織で、各拠点の管理者には対応するAdvanced Groupだけの編集を許可する……といった運用が可能です。 この項目は従来の「Groups」も対象として追加はできるのですが、 メンバーが「Site」のGroup以外を指定した場合は機能しないという仕様がありました。 「Advanced Groups」ではそのようなことは無く、どのような属性のメンバーが入ったAdvanced Groupであっても個別の権限設定が可能です。 APIでの編集にも対応 「Groups」はCMAでの手動更新にのみ対応していますが、「Advanced Groups」はAPIでの設定に対応しています。大規模な設定変更や、メンバーが大量に存在する場合の管理に力を発揮することが期待されます。 Advanced Groupsのデメリット 「Advanced Groups」は比較的最近になって実装された機能であるため、制約も少なからず存在します。 DNSやDHCPの設定には未対応 既存の「Groups」は、各Groupに紐づける形でDNS、DHCPの設定を行うことが可能です。 一方、「Advanced Groups」は2025/12現在、これに対応していません。 グループ個別でのDNS設定を行いたい、といった場合は既存のGroupを使用する必要があります。 (機能追加予定とされていますが、時期は未定です。) 設定先に使える場所が少ない 2025/12月現在、「Advanced Group」を対象として 利用できるのはInternet FirewallとWAN Firewallだけ となっています。 せっかくのメンバー属性識別機能も、現状では使える場所が少なすぎてまともに機能しないというのが現実です。 こちらも対象は順次追加予定であるようなので、今後に期待しておきましょう。 おわりに 「Advanced Groups」機能は、既存の「Groups」では手の届かない細かなアップデートが光る一方、実用性はまだ発展途上といえる機能です。 Catoは今後「Advanced Groups」を主流としていく方針を発表しており、いずれは利用可能箇所も大きく増加することが見込まれます。 既存の「Groups」も併存していますが、今のうちに少しずつ触れてみても良いかもしれません。
前にEligible user(有資格者)側としてPIMを利用していました。 【Azure】Microsoft Entra PIM で権限管理(有資格者編) Microsoft Entra Privileged Identity Management(PIM)を利用して権限の申請しました。通常の運用よりも安全に権限管理できる頼もしい技術でした。 blog.usize-tech.com 2025.07.29 今回は Administrator(管理者)側の操作 を検証してみます。 やりたいこと PIMグループを作成して、 アクティブ化の承認 を実施する。 承認依頼のメールとか、承認完了までの操作をブログに記載したい。 PIMの設定 ユーザー情報 ユーザーは2人設定。 Administrator:ad_tomioka Eligible user:kottomioka kottomiokaがPIMのアクティブ化を依頼し、 ad_tomiokaが承認 します。 現時点でkottomiokaは何も権限を有していません。 権限 リソースグループrg-tomiokaをターゲットに、kottomiokaに対して 共同作成者をPIMで割り当てます 。 グループ作成 まずはグループを作成します Azure Portal > Entra IDで検索 > グループ > 新しいグループ から「PIM-tomioka-共同作成者」のグループを作ります。 所有者にad_tomioka、メンバーにkottomiokaを指定しています。 グループ作成後、アクティビティ>Privileged Identity Management から「このグループのPIMを有効にする」をクリックします。 これでグループ作成完了です。 PIMの設定 Azure Portal > PIMで検索 >管理 > Azureリソース からリソースグループrg-tomiokaを指定し、リソースの管理を押します。 管理>割り当て から割り当ての追加を押します。 ロールの選択: 共同作成者 、選択されたメンバー: PIM-tomioka-共同作成者 を指定します。 これからアクティブ化に承認が必要な設定をします。 PIM-tomioka-共同作成者の画面より、割り当て>設定 から ロールのMemberをクリック します。 余談ですがこの画面にいくまで少し苦労しました。 編集画面が出てきて、「アクティブにするには承認が必要です」にチェックを付けて、承認者を設定します。 これでPIMグループ作成完了です。 アクティブ化の承認やってみた kottomiokaでポータルにログインし、PIMでアクティブ化の申請をします。 そしたら メール が来ました。 ad_tomioka側で承認ボタン押すと、 承認者にも理由が求められました 。 承認後 す ぐにkottomiokaに対してアクティブ化 されました。 さいごに ずっとやってみたかったPIMの承認を体験しました。 承認する際にも理由を記載しないといけないことが判明しました。 手作業で承認するので実際の運用では、要求が来るたびに承認するのか、時間を指定して一斉に承認するかの考慮が必要そう。
こんにちは、SCSK斉藤です🐧 2025年11月にSnowflake Intelligenceがついに一般提供(GA)になりました。こちらは生成AIを利用して自然言語によるデータ検索や要約を可能にしてくれるインテリジェンスエージェントサービスです。 前回のブログでは、Snowflake Intelligenceの概要とセットアップ方法について弊社松岡より紹介しました。今回はその続きとして、実際にSnowflake Intelligenceを利用する為の過程・SCSKならではの支援について案内します! Snowflake Intelligence を始めるためのアカウント設定 Snowflake Intelligenceは、生成AIを利用して自然言語によるデータ検索や要約を可能にしてくれる機能です。利用開始するために必要なアカウント設定の手順を紹介します。 blog.usize-tech.com 2025.10.02 はじめに 企業が生成AIを活用するためには、データ活用が必要不可欠です。 Snowflake Intelligenceを活用することで「データが散在している」「非構造化データが活用できない」「誰が使えるのか不明」などの課題を解決することが可能です。 具体的には データの一元管理:構造化・非構造化データを統合 権限設計:部門や役割に応じたアクセス制御を設定 Snowflake Intelligenceにより、現場の意思決定スピードが飛躍的に向上します。 つまり、データ活用は生成AI活用のスタートラインであり、Snowflake Intelligenceはその上で最大の効果を発揮するツールです。 利用シーン 例えばsnowflake Intelligenceは、こんな利用シーンがあります。 営業部門: SQLやデータ分析に不慣れな営業担当者でも、「今月の地域別売上を教えて」と入力するだけで即座に分析結果を取得可能です。営業戦略の意思決定が迅速化。 製造部門: 設備稼働率や不良率などのデータが散在しがちな現場で、「今週のライン別稼働率を比較したい」といった質問を簡単に実行できます。改善活動に直結。 各機能の概要 それではSnowflake Intelligenceを利用するための準備をしていきましょう。 以下の4つの主要機能で構成されており、それぞれが異なる役割を担っています。ここでは、機能の概要をご紹介します。 また4つの機能は全て、Snowflakeの[AIとML]からアクセスできます。 1.Cortex Analyst 自然言語で問い合わせた内容を SQL に変換する Text-to-SQL サービスです。 会話型の質問をSQLクエリに変換することで、SQLの専門知識を持たないユーザーでも容易にデータへアクセスすることを実現します。 例)住んでいる国、ユーザー名、購入した商品のデータの場合 本機能により、「国ごとの購入数を教えてください」といった自然言語を解釈してSQLを組み立てることが可能 Cortex Analyst | Snowflake Documentation 2.Cortex Search Snowflake内の非構造化データに対する高品質・低レイテンシの検索サービスです。 ベクトル検索とキーワード検索のハイブリッドアプローチを活用し、検索やAIチャットボット向けのRAG(Retrieval Augmented Generation)などのユースケースをサポートします。 例)住んでいる国、ユーザー名、購入した商品のデータの場合 本機能により、SQLを使わず日本のユーザーの検索が可能 Cortex Search | Snowflake Documentation 3.Cortex Agents 構造化・非構造化データの両方を横断してインサイトを提供するオーケストレーションサービスです。上述のCortex Analyst(構造化データ用)・Cortex Search(非構造化データ用)をツールとして活用し、LLMと組み合わせてデータ分析を実行します。 例)住んでいる国、ユーザー名、購入した商品のデータの場合 本機能により、AIボットが検索と分析を交えた回答を可能 また関西弁で回答する設定もできるんやで Cortex Agents | Snowflake Documentation 4.Snowflake Intelligence 自然言語を使用してグラフなどのチャート作成や、テキストでの分析結果の返答を行います。 Cortex Analyst・Cortex Search を活用することにより、構造化データと非構造化データを含む様々なデータソースにアクセスし、統合的なデータ分析を行うことが可能です。 ガバナンス、セキュリティの観点としてはすべての回答については、その元となるソース(SQLクエリまたはドキュメント)まで追跡が可能です。また、Snowflake の既存のロールベースアクセス制御を活用することが可能です。 例)住んでいる国、ユーザー名、購入した商品のデータの場合 本機能により、一般ユーザーがチャット形式でデータ分析が可能 Snowflake Intelligence の概要 | Snowflake Documentation SCSKならこんなサポートができます みなさんSnowflake Intelligenceについて興味を持ってもらえたでしょうか? Snowflake Intelligenceローンチパートナーの弊社ならではのサービスの一環として、以下が提供できます。 1.Snowflake Intelligence作成の伴走型支援 Snowflake Intelligenceの導入にあたり、業務に合わせたAIボットの設計から、実装・運用までを弊社がサポートしながら進める「伴走型支援」を提供します。 具体的には以下のような支援内容を想定しております。 SCSKならではの支援例) ・ユースケースに沿った生成AIモデルを選べるようサポート ・回答精度を上げる「整備→QA作成→検証→誤り修正」サイクルをサポート ・お客様のデータの特性や業務に合わせてCortex Agents、Cortex Analyst、Cortex Searchそれぞれの最適な分割方針を提案 ・Snowflake Intelligence活用にあたり事前考慮すべきチャットやデータへの最適な閲覧/利用権限設計を提案 2.Snowflake導入から支援可能 Snowflake Intelligenceだけではなく、DWH/ETL基盤としてのSnowflakeの導入支援も可能です。PoC(概念実証)から始めて、段階的に本番導入まで進めることが可能です。 データ活用上流から運用/データ活用高度化まで一気通貫でサポートします。 サービスに関する最新URLは以下をご参照ください! Snowflakeソリューション│SCSK株式会社|サービス|企業のDX戦略を加速するハイブリッドクラウドソリューション 最後に 一般的なデータ活用のファーストステップとして、BIの固定帳票/ダッシュボードの開発・リリースを目標として掲げられるお客様が多いかと思います。 ただ、実際にはプロジェクトの中で現場関係者を巻き込み切れず、各利用部門のニーズを正確に把握しきれないまま進めた結果、導入したものの「使われないBI」になってしまうという事態に陥ってしまうことも多いのではないでしょうか。 Snowflake Intelligenceを活用することで、会話型のやり取りを通じて構造化・非構造化データの分析が可能になります。これにより、事業部門側でのデータ利活用が促進され、現場から多様なニーズが顕在化することが期待できます。 さらに、Snowflake Intelligenceでは、ユーザーが入力するプロンプトや利用状況のログを分析できます。これにより、よくある問い合わせや分析軸を抽出し、固定帳票/ダッシュボードに反映することが可能です。 このように、Snowflake Intelligenceの活用とその利用状況をもとにしたBIのブラッシュアップを組み合わせることで、現場にとって「本当に使える BI」を提供し、社内全体のデータ利活用をさらに加速できると考えています。 引き続き、Snowflake Intelligenceの可能性を一緒に探っていきましょう!
SCSK いわいです。 前回からだいぶ間が空いてしまいましたが、今回はRaspberry Pi 5で気温/気圧/湿度センサーを使って測定し、 Webで表示するシステムを構築したいと思います。 DBに取得データを格納し、あとから検索できるといろいろ便利です。 今回は前回セットアップした環境をそのまま流用します。(Rapspberry Pi5のみ) Raspberry PiでWebサーバ(冗長構成)を構築② 今度はセンサー 前回はRaspberry Pi 2台でWebサーバを冗長化し、LED点灯を行いました。今回は気温/気圧/湿度センサーを使って情報取得部分を冗長化します。 blog.usize-tech.com 2025.02.17 下準備 使用するRaspberry Piは前回同様に以下のものです。 【Raspberry Pi 5】 CPU: Broadcom BCM2712 quad-core Arm Cortex A76 processor @ 2.4GHz Memory: 8GB OS: Bookworm 前回同様にflaskを利用してWeb画面に測定結果を表示、DBから過去の測定結果を表示できるシステムを組んでみます。 【追加で用意するもの】 温湿度・気圧センサーモジュールキット(BME280使用) ジャンパーケーブル×5 ブレッドボード×1 Webサーバアクセス用PC システムのイメージ PythonでFlaskアプリケーションを作成します。今回はWeb画面に測定結果をグラフ表示するようにしてみます。 さらにDB(sqlite3)を使用して、センサーでの測定結果をローカルDB(bme280_data.db)に格納し、 過去のデータを検索できるようにします。 イメージはこんなカンジで。 今回のシステムで導入する機能と各ライブラリの説明は以下のとおりです。 機能 ライブラリ 説明 Webサーバ Flask 軽量なWebフレームワーク。センサー値や予測結果をWebアプリとしてブラウザに表示。 センサー通信 Smbus2 ラズパイとI2C通信する。BME280と通信するために利用。 bme280 Bosch製の温湿度・気圧センサー BME280用のPythonライブラリ。データ取得する。 データ保存 sqlite3 軽量な組み込み型データベースSQLiteを操作するためのライブラリ。計測データをローカルDBに保存・検索するために利用。 時刻処理 datetime 計測時刻の記録に利用。ローカルDBに保存するtimestampを生成。 Flaskとsmbus2とbme280は前回導入済み、sqlite3とdatetimeはデフォルトでインストールされているライブラリです。 温湿度・気圧センサーモジュールキットとRaspberry Piを接続する 前回同様にブレッドボードに温湿度・気圧センサーモジュールキットを接続します。 ※BME280のSDOもRaspberry Piの6ピンに接続します。 次に回路とRaspberry Pi 5を接続します。 センサ側 Raspberry Pi 5 BME280 VDD 3.3V:1ピン BME280 GND GND:9ピン BME280 SDI GPIO2(SDA):3ピン BME280 SDO GND:6ピン BME280 SCK GPIO3(SDL):5ピン 【Raspberry Pi 5のピン配置】 Raspberry Pi 5 Pinouts including GPIO for the 40 Pin Header – element14 Community 接続が終わったら、以下のコマンドを実行します。 sudo i2cdetect -y 1 実行結果に「76」という表記があれば、正常に接続できています。 Pythonスクリプトの作成 ファイル名はtemp_DB.pyにしてみました。 ChatGPTを利用してPythonスクリプトを作りました。 Pythonスクリプトで実行していることは以下です。 センサーからデータを読む BME280から温度・湿度・気圧の最新値を取得します。 データを保存する 取得した値を毎回データベース(SQLite)に記録していきます。 Webページで表示する FlaskでWebページを作り、以下を表示します。 最新の値(温度・湿度・気圧) データをグラフ化したもの 期間や間隔を指定した検索グラフ 2秒ごとに自動更新 ブラウザは2秒ごとに新しい測定値を取りに行き、自動でグラフや数値を更新します。 データ検索 期間と間隔を指定して、過去データをまとめてグラフ表示します。 Pythonスクリプトの実行 次に各Raspberry PiでWebサーバを起動します。 python3 temp_DB.py Webブラウザからアクセス Webサイトアクセス用PCでブラウザを起動し、以下のURLにアクセスします。 http://Raspberry Pi 5のIPアドレス:5000 センサーが稼働し、2秒ごとに現在の「温度」「気圧」「湿度」が表示されます。 画面右側では2秒ごとに「温度」「気圧」「湿度」のグラフが表示されます。 画面下側では過去データの検索結果を表示します。 これで乾燥対策もばっちりです。 次はDBに格納したデータを使っていろいろ試してみたいと思います。
こんにちは、SCSK株式会社の中野です。 Zabbixは、システム監視・運用に欠かせないオープンソースの監視ツールです。しかし企業や各種プロジェクトでは、外部インターネットに直接アクセスできない、「オフライン環境」でZabbixを導入しなければならないケースも多くあります。 通常の導入手順では、公式リポジトリやインターネット経由でのパッケージ取得が前提となっていますが、オフラインではこの方法は使えません。 本記事では、AWS環境に構築したRed Hat Enterprise Linux 9.6上に、Zabbix 7.0を「オフライン環境」で導入する手順についてご紹介します。 導入手順 今回の構成は以下とさせていただきます。 ZABBIX VERSION: 7.0 LTS OS DISTRIBUTION: Red Hat Enterprise Linux OS VERSION: 9 DATABASE: MySQL WEB SERVER: Apache SELinux: 無効 Firewalld: 無効 オフライン環境として、インターネットにアクセスできない状態を想定しています。そのため、Zabbixインストールに必要なファイルや依存パッケージは、事前に外部環境からダウンロードして持ち込む必要があります。 この記事では、Zabbix本体や必要なライブラリ・依存パッケージの準備からインストールまで、実際に試した手順をベースに解説します。 Zabbix関連パッケージのダウンロード オフライン環境でZabbixを導入するためには、事前に必要なパッケージ類をすべてダウンロードしておく必要があります。 今回は、yumコマンドの–downloadonlyオプションを利用して、Zabbix関連パッケージをまとめて取得します。 # 関連パッケージのダウンロード sudo yum install --downloadonly --downloaddir=/tmp/zabbix <パッケージ名> ※ <パッケージ名> はzabbix-server、zabbix-webなど必要なパッケージ名に置き換えてください この作業には、インターネットに接続されたオンライン環境のRHEL9サーバーが1台必要です。オンライン環境はあくまでダウンロード用に利用するだけなので、検証機や既存のRHEL9環境を流用しても構いません。 取得したパッケージはファイル転送コマンドや、USBメモリなどのメディアでオフライン環境へ持ち込んでください # 関連パッケージのダウンロード(mysql, httpd) sudo yum install --downloadonly --downloaddir=/tmp/mysql mysql-server sudo yum install --downloadonly --downloaddir=/tmp/httpd httpd # 関連パッケージのダウンロード(zabbix) rpm -Uvh https://repo.zabbix.com/zabbix/7.0/rhel/9/x86_64/zabbix-release-7.0-5.el9.noarch.rpm sudo yum install --downloadonly --downloaddir=/tmp/zabbix zabbix-server-mysql sudo yum install --downloadonly --downloaddir=/tmp/zabbix zabbix-web-mysql sudo yum install --downloadonly --downloaddir=/tmp/zabbix zabbix-web-japanese sudo yum install --downloadonly --downloaddir=/tmp/zabbix zabbix-apache-conf sudo yum install --downloadonly --downloaddir=/tmp/zabbix zabbix-sql-scripts sudo yum install --downloadonly --downloaddir=/tmp/zabbix zabbix-agent2 関連パッケージのインストール、DB初期設定 関連パッケージをダウンロードしましたので、オフライン環境でZabbixをインストールします。まずはMySQLとApacheをインストールします。 # MySQLのインストール dnf localinstall /tmp/mysql/* # MySQLのインストール dnf localinstall /tmp/httpd/* # データベースを起動 systemctl start mysqld systemctl enable mysqld 続いて、Zabbix用データベースを作成します。 DB名、アカウント名やパスワード環境に応じて設定いただければと思います。 # DBへの接続 mysql -uroot -p Enter password: (MySQLのrootアカウントのパスワードを入力) # DB、アカウントを作成 > CREATE DATABASE zabbix CHARACTER SET utf8mb4 COLLATE utf8mb4_bin; > CREATE USER zabbix@localhost IDENTIFIED BY 'zabbix'; > GRANT all privileges ON zabbix.* TO zabbix@localhost; > SET global log_bin_trust_function_creators = 1; > exit Zabbixサーバのインストール 続いてZabbixをインストールします。 # Zabbixサーバのインストール dnf localinstall /tmp/zabbix/* 続いて、Zabbix用データベースへ初期データをインポートします。 # DBへ初期データをインポート zcat /usr/share/zabbix-sql-scripts/mysql/server.sql.gz | mysql --default-character-set=utf8mb4 -uzabbix -p zabbix Enter password: (MySQLのzabbixアカウントのパスワードを入力) 初期データのインポート後、log_bin_trust_function_creatorsを無効にします。 # DBへの接続 mysql -uroot -p Enter password: (MySQLのrootアカウントのパスワードを入力) > SET global log_bin_trust_function_creators = 0; > exit その後、Zabbixサーバーの設定と起動を行います。 # 各パラメータ設定 /etc/zabbix/zabbix_server.conf DBHost=localhost DBName=zabbix DBUser=zabbix DBPassword=zabbix # サービスの起動 systemctl start zabbix-server zabbix-agent2 httpd php-fpm systemctl enable zabbix-server zabbix-agent2 zabbix-agent httpd php-fpm Zabbix WEBコンソールへのアクセス Zabbixのインストールは完了しましたので、Webコンソール上でセットアップしていきます。 ブラウザを立ち上げて、以下にアクセスします。 http://xxx.xxx.xxx.xxx/zabbix xxxには、今回構築したIPアドレスを入れてください。例えば、もしZabbixサーバーのIPアドレスが192.168.0.1なら、アドレスバーには”http://192.168.0.1/zabbix”と入力します。 言語を【日本語(ja_JP)】に変更して、【次のステップ】をクリックします。 すべての項目が「OK」になっていることを確認し、【次のステップ】をクリックします。 パスワード欄に先ほど設定したZabbixDBのパスワードを入力し、【次のステップ】をクリックします。 タイムゾーン欄で【(UTC+9:00) Asia/Tokyo】を選択、Zabbixサーバ名を記入し、【次のステップ】をクリックします。 設定内容に問題がなければ、【次のステップ】をクリックします。 【終了】をクリックすると、以下のようなログイン画面が表示されます。 初期状態でユーザーが登録されているので、以下のユーザー名・パスワードでログインします。 ユーザ名:Admin パスワード:zabbix ログインすると、WEBコンソール画面が表示されます。 以上でZabbixのインストールは完了です。 最後に 今回は、オフライン環境でのZabbix導入手順についてご紹介しました。ネットワークに接続できない制約がある場合でも、事前に必要なパッケージをダウンロードし、オフライン環境に持ち込むことでZabbixを導入することが可能です。 監視システムの導入は、障害の早期発見や安定稼働のために大変重要な作業です。Zabbixはオープンソースでありながら高機能な監視を実現できますので、ぜひ今回の記事を参考に、オフライン環境でもZabbixの導入・活用にチャレンジしてみてください。 オフライン環境ならではのハードルもありますが、事前準備をしっかり行うことで、その壁を乗り越えることができます。 本記事がみなさまの環境構築のお役に立てば幸いです。最後まで読んでいただき、ありがとうございました。
本記事は TechHarmony Advent Calendar 2025 12/7付の記事です 。 こんにちは!SCSKの安藤です。 毎年恒例、 TechHarmonyのアドベントカレンダー企画 です!🎉🎉🎉 今年は、前半の約3分の1日程で Zabbix枠 を頂くことになり、投稿のお誘いをいただきましたので参加させていただくことになりました。 はじめに Zabbixは、オープンソースの監視ソリューションとして世界中で利用されています。 その進化の方向性を示す「 Zabbix Roadmap 」と、Zabbix Conference Japan 2025での発表内容から、次期バージョン Zabbix 8.0 LTSの、注目すべきポイントを整理しました。 1. Zabbix 8.0 LTSのリリース時期 2026年Q2にリリース予定 以下のページには2026年Q1と記載ありますが、大方の予想はQ2とのことです。 Zabbix Life Cycle and Release Policy 2. Zabbix8.0LTSの注目機能 Conferenceのテーマと公式ロードマップの情報より、以下の注目機能があげられます。 オブザーバビリティの強化 OpenTelemetry対応、ログベース監視、クラウドネイティブ環境でのトレーシング モバイルアプリ刷新 iOS/Android対応で外出先から問題管理 イベント処理自動化 タグ変更、重複排除、カスタムJavaScript対応 ネットワーク監視強化 NetFlowデータ収集、リアルタイムストリーミング セキュリティ強化 SSO証明書UIアップロード、権限管理改善 オブザーバビリティの強化 監視からオブザーバビリティへ Zabbix8.0LTSの注目機能の1つとして、オブザーバビリティがあります。 「監視(Monitoring)」と「オブザーバビリティ(Observability)」は似ているようで、目的とアプローチが異なります。 監視(Monitoring) オブザーバビリティ(Observability) アプローチ システムや構成要素の状態を定常的に観察 閾値を設定してアラートを発報 システム内部の状態を把握するため、メトリクス・ログ・トレースなど多様なデータを収集・分析 問題発生時に「なぜ起きたか」を探ることが可能 目的 障害検出や稼働状態の把握 障害調査や原因分析 イメージ 症状の確認 診断と治療 監視では、なぜ問題が起きたかまでは分かりません。 環境やサービスが分散・分割され、変化し続けていくクラウドネイティブや分散システムでは、障害調査や原因分析に強いオブザーバビリティが不可欠です。 オブザーバビリティの構成要素 メトリクス :CPU使用率、メモリ、ネットワークなど定量データ ログ :アプリケーションやシステムのイベント記録 トレース :複数サービス間のリクエストやトランザクションの流れ(※Zabbixは今後対応予定) OpenTelemetry対応とテレメトリーの活用 Conferenceでは、 OpenTelemetry がオブザーバビリティ実現の鍵として紹介されました。 OpenTelemetryとは? APM(アプリケーション性能管理)を実現するための標準規格 テレメトリーデータ送受信のプロトコル標準を定義し、APIやSDKを提供 テレメトリーとは? OSやアプリケーションから送信される内部稼働状況のデータ Zabbix + OpenTelemetryの可能性 アプリ側でテレメトリーデータ送信処理を実装 高価なフル機能Observabilityツールを導入せず、既存Zabbix環境に部分的なテレメトリ監視を追加 将来的には、 アプリケーションのトランザクションをZabbixで監視できる世界 が実現 モバイルアプリ刷新 Zabbixのモバイルアプリが登場します。 新しいiOS/Android対応アプリでは、問題通知、履歴データ参照、問題管理が可能になり、外出先でも迅速な対応が実現します。 SREや運用担当者にとって、スマートフォンからの監視・管理は大きな利便性向上です。 実は随分前にはリリースされていたとの話もありますが、私は見かけたことはなく、公開されたら自分のスマホにインストールしてみたいと思っています! イベント処理自動化 複雑なイベント管理を効率化するため、エンタープライズアラームコンソールが導入されます。 タグや重大度の変更、フィルタリング、重複排除、さらにカスタムJavaScriptによる高度なパターンマッチングが可能。 セキュリティ監視や不正検知にも活用でき、運用負荷を大幅に削減します。 ネットワーク監視強化 ネットワークの可視化と分析機能が強化されます。 NetFlowデータ収集・可視化により、帯域使用状況や通信経路を詳細に把握可能。 さらに、ネットワーク機器からのリアルタイムストリーミング対応で、異常検知のスピードが向上します。 セキュリティ強化 Zabbixのセキュリティ機能も進化します。 SSO証明書のUIアップロード により、認証設定がより簡単に。 また、プロキシやプロキシグループに対する 権限ベースの可視化モデル が導入され、アクセス管理がより安全で柔軟になります。 まとめ Zabbixは「監視」から「オブザーバビリティ」へ進化し、クラウドネイティブやSREのニーズに応える機能を拡充していきます。 Zabbix 8.0 LTS は、企業の監視基盤を次のレベルへ引き上げる重要なアップデートになるでしょう。 最後まで読んでいただき、ありがとうございました。明日のアドベントカレンダーもお楽しみに! 弊社ではZabbix関連サービスを展開しています。以下ページもご参照ください。 ★Zabbixの基礎をまとめたeBookを公開しております!★ Zabbix資料ダウンロード|SCSK Plus サポート for Zabbix Zabbix監視構築に必要な知識と最新機能についての資料をダウンロードできるページです。世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします。 www.scsk.jp ★SCSK Plus サポート for Zabbix★ SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします。 www.scsk.jp ★YouTubeに、SCSK Zabbixチャンネルを開設しました!★ SCSK Zabbixチャンネル SCSK Zabbixチャンネルでは、Zabbixのトレンドや実際の導入事例を動画で解説。明日から使える実践的な操作ナレッジも提供しており、監視業務の効率化に役立つヒントが満載です。 最新のトピックについては、リンクの弊社HPもしくはXアカ... www.youtube.com ★X(旧Twitter)に、SCSK Zabbixアカウントを開設しました!★ https://x.com/SCSK_Zabbix x.com
本記事は TechHarmony Advent Calendar 2025 12/6付の記事です 。 皆さん、師走のZabbixライフを満喫していますか?こんにちは、SCSK株式会社 片井です。 今回はZabbixLTS Ver7.0で新しく実装されたZabbix APIメソッド「history.push」について紹介します。 Zabbix APIの基本的な使い方は、当ブログの記事「Zabbix APIの使用方法」にて解説していますので、まだ触ったことがない方は、 ぜひそちらからご覧ください。 Zabbix APIの使用方法 ZabbixはAPIが豊富に用意されており、データの抽出や外部システムとの連携が容易になっております。今回はcurlコマンドを使ってAPIを実行する方法を紹介いたします。 blog.usize-tech.com 2023.07.27 これは何? シンプルに言うと「 Zabbixの各アイテムに監視データを送信できるAPI 」です。 history.push www.zabbix.com さらに言うと「APIで指定したアイテムに任意の監視データを投入し、その値がZabbixのヒストリデータとして検知・モニタリングできるようにする」機能です。 Zabbixは様々なアイテムのタイプが用意されており、幅広い監視に対応しています。 しかし中には以下のような要件で、 監視対象のホスト から Zabbixサーバ に対して、監視データを送りつけたいケースが存在 します。 NW制約の関係でZabbixサーバから監視対象のホストにポーリング(監視データを取りに行くこと)ができない Zabbixサーバから 定期的に データを取りに行くのではなく、 問題が起きた時にリアルタイムで データを送信→検知させたい 上記は一例ですがこういったケースの場合、おなじみの「Zabbix Agent」や、後述する「Zabbix sender」、 そして今回紹介するhistory.pushメソッドを活用することによって、 監視対象ホスト→Zabbixサーバという方向でのデータ送信 によるリアルタイム監視を行うことができます。 具体的な処理の流れは以下のようになります。 監視機器など監視される側のホストから、curlなどHTTPクライアントを使用して、監視データをZabbix WebUIのAPIエンドポイントにPOSTする POSTされたリクエストは、まずZabbix WebUIが受け取る APIキーを元に認証されたデータは、その後ZabbixサーバによってDBに書き込まれる 既存方式の紹介 – Zabbix sender ここまでの話を聞くと、Zabbix経験者の方は「 あれ?それって”Zabbix sender”と同じじゃない? 」と思われるかもしれません。 「Zabbix sender」とは、一言でいうと監視データをZabbixサーバに送信するためのコマンドラインユーティリティです。 6 zabbix_senderコマンド www.zabbix.com APIとコマンドラインユーティリティということで方式は異なりますが、実現される機能としてはほぼ同一です。 Zabbix senderも同様に各アイテムに監視データを投入、ヒストリデータとして検知/モニタリングすることができます。 上記の方式の違いについては後述します。 使ってみよう 実際に使ってみましょう。 事前準備 今回はAPI実行が内容に含まれます。API実行が実践できていない方は、先に下記URLの[データの単純取得]が出来るところまで進めてみてください。 Zabbix APIの使用方法 ZabbixはAPIが豊富に用意されており、データの抽出や外部システムとの連携が容易になっております。今回はcurlコマンドを使ってAPIを実行する方法を紹介いたします。 blog.usize-tech.com 2023.07.27 APIパラメータ 今回の手順で必要なパラメータは以下になります。 パラメータ 入力内容 アイテムID 監視データを投入したいアイテムのID ヒストリデータ 監視データの内容(ステータスの場合:FAILED,SUCCESSなど任意の数値/テキスト) UNIX時刻 Zabbixで監視データ取得時刻として扱われる時刻 ※ZabbixはUNIXタイムで監視データを時刻管理するため形式を合わせる ナノ秒 監視データ取得時刻の重複回避のために参照される時刻、ナノ秒単位で入力 実施手順 Zabbix WebUIのURLに対して、http/httpsで疎通可能なサーバにログインしてください。 以下のcurlコマンドを実行してください。(LinuxOS,curlコマンドインストール環境を想定しています) curl -s -k -d ' { "auth": "<APIキー>", "method": "history.push", "id": 1, "params": [ { "itemid": <アイテムID>, "value": <ヒストリデータ>, "clock": <UNIX時刻>, "ns": <ナノ秒> } ], "jsonrpc": "2.0" } ' -H "Content-Type: application/json-rpc" http://<ZabbixURL>/zabbix/api_jsonrpc.php | jq '.result' curlコマンド実行後、以下のように応答結果が返ってきます。 今回は”6″という監視データの値を、ID:48474のアイテムに投入しています。 ※失敗した場合は、errorのカラムとerror内容が出力されます。 ZabbixのWebUIで投入先のアイテム最新データを見ると、入力したパラメータに従って、”6″の監視データが アイテムのヒストリデータとして投入されていることが分かります。 注意点 アイテムタイプは 「Zabbixトラッパー」 もしくは 「HTTPエージェント」タイプで[トラッピングの有効化]のオプションを指定 することが必須になります。 そのため例えば、 「Zabbixエージェント」のアイテムタイプを指定して、普段は監視データをエージェントから取得、問題が起きた際にhistory.pushで直接監視データを投入する 、といった使い方は不可になります。 後述のZabbix senderとの比較で記載していますが、 データ送信先はZabbixサーバではなく、Zabbix WebUIのURL になります。 そのため、上記WebUIがZabbixサーバから独立している構成の場合は、WebUIサーバとの疎通が確保されている必要があります。 Zabbix senderとの比較 冒頭でZabbix Senderと機能が似ていると触れましたが、実際には以下のような比較ポイントがあります。 比較項目 History Push API Zabbix sender ソフトインストール HTTP,JSON関連ライブラリがインストール済みであれば不要 Zabbix Senderのインストール必須 監視データ送信先 Zabbix WebUI Zabbixサーバまたは Zabbixプロキシ データ形式 JSON形式 Zabbix Senderコマンド/Senderプロトコル (内部的にはJSON形式で処理) 使用ポート Zabbix WebUI のHTTP,HTTPSポート(80, 443) Zabbixサーバまたは Zabbixプロキシ の Trapperポート(デフォルト: 10051) セキュリティ認証 APIトークンベースでの認証 なし(Zabbixサーバ側設定で監視データを受け入れるIPを指定) インストールさえできれば、データ形式の観点からAPI実行文とコマンド文を書く労力の差でZabbix Senderの方が手軽な印象です。 より対応幅が広いのはhistory.push方式になります。エージェントレスの監視をせざるを得ない、アプライアンス機器やアプリ製品では、Zabbix Senderはインストールできないが、HTTP関連ライブラリとJSONは扱える、というケースが多いです。 セキュリティ観点では、API認証で認証情報を管理できるhistory.push方式の方がよりセキュアです。 まとめと今後の展望 今回は、監視データ送信方法として、history.push APIの紹介をさせていただきました。 監視データ送信については、既存の方式としてZabbix senderがありますが、上記比較のように使い分けができるポイントが何点かあるため、 これまでZabbix senderでは実現できなかったと諦めていた監視についても、この実装を機に再考してみてはいかがでしょうか? 所感ですが、生成AIの活用によりZabbix APIの学習・作成コストが非常に低減されており、Zabbix sender方式とのコスト差がより縮まっていくと感じています。 上記比較のように、history.pushはsender方式と比較して、よりセキュア・モダンな方法での監視方式となり、 今後Zabbixのセキュリティ要件がより厳格に求められる方向性で発展していった際は、こういった方式でのデータ投入が必須になっていくのではないでしょうか。 SCSK Plus サポート for Zabbix SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします。 www.scsk.jp ★YouTubeに、SCSK Zabbixチャンネルを開設しました!★ SCSK Zabbixチャンネル SCSK Zabbixチャンネルでは、Zabbixのトレンドや実際の導入事例を動画で解説。明日から使える実践的な操作ナレッジも提供しており、監視業務の効率化に役立つヒントが満載です。 最新のトピックについては、リンクの弊社HPもしくはXアカ... www.youtube.com ★X(旧Twitter)に、SCSK Zabbixアカウントを開設しました!★ https://x.com/SCSK_Zabbix x.com
こんにちは、ひるたんぬです。 この度「 AWS re:Invent 2025 」に参加できることになりましたので、現地での出来事や参加したセッションについてのレポートをお送りしたいと思います! 今回は、最終日の出来事を振り返ります! 半日しか開催がないため内容が少なくなっている点、ご了承ください。 Day 5 最終日は午前中のみの開催です。 ▼ 朝6時半頃に撮影した光景。朝焼けと月のコラボが美しかったです。 Build trustworthy AI applications with Amazon Bedrock Guardrails 最後はWorkShopに参加しました。 このWorkShopではAmazon Bedrock Guardrailsを用いて信頼できるAIアプリケーションを構築することが目的です。 Amazon Bedrock Guardrailsについては、下記記事をご参照ください。 Bedrock ガードレール 生成 AI のユースケースと責任ある AI ポリシーに合わせてカスタマイズされたガードレールを使用して LLM を保護します。 aws.amazon.com 企業がAIアプリケーションを導入する上の課題は主に「規則・規制」と「監査」の二点です。 前者は例えばEUの法令や各企業のガバナンスルールを指し、後者は、例えば医療分野や金融分野においてAIを利活用して判断した根拠を提示できるか、という点です。 特に後者では「ハルシネーション」のリスクがあり、これにおける対策としては人間によるチェックが行われている現状があります。この現状により思うように生成AIを活用することによる生産性向上に繋がっていないということが課題です。 ある報告書によると、労働者は週4.3時間(週の労働時間の約10%)を上記のチェック作業に費やしているようです。 The Reality of AI Hallucinations in 2025 - Drainpipe.io By: Dominick Romano and Chris Gaskins Introduction AI hallucinations are a consistent and unwanted behavior exhibited by... drainpipe.io この問題に対処するために「Amazon Bedrock Guardrails」があります。 今回のWorkShopでは、航空会社のラウンジアクセスというユースケースを対象として、Amazon Bedrock Guardrailsの機能・効果を体験しました。 ▼ 自動推論ポリシーの定義。ポリシーのテストもコンソール上から実行できます。 ▼ ガードレールの作成。自動推論ポリシーもここからアタッチします。 ▼ ガードレールのテスト。ポリシーに準拠しているかのテストが実施されています。 ※ 画面右下Automated Reasoning内に、ポリシーのテスト結果が表示されます。 終わりに AWS re:Invent 2025はこれにて終了です。 参加前は「一週間なんて長いな…」という思いもあったのですが、いざ始まってみると一瞬で過ぎ去ってしまいました。 それだけ充実した日々を過ごすことができたのだと思います。 一方、日本には「家に帰るまでが遠足」という言葉があります。 私も「家に帰るまでがre:Invent」と肝に銘じ、帰国・帰宅するまで安全を最優先に過ごしたいと思います。 初日から最終日まで5日間にわたり連続投稿をしておりましたが、本投稿にて連続投稿は終了となります。 次回は帰国・振り返り編を投稿予定ですので、お楽しみに!
こんにちは、ひるたんぬです。 この度「 AWS re:Invent 2025 」に参加できることになりましたので、現地での出来事や参加したセッションについてのレポートをお送りしたいと思います! 今回は、四日目の出来事を振り返ります! 今回の記事も比較的写真が多めの記事となります。ご了承くださいませ。 Day 4 re:Inventもいよいよ終盤に差し掛かってきました! 今日も目玉イベントが目白押しです! BuilderCards受け取り まずは、BuilderCardsを受け取りに行きました。 最近、弊社内でもBuilderCardsの普及に取り組まれている方がおり、少しずつではありますが、社内の認知度も高まっているのではないかと思っております。 Day 4に来た理由としては、この日に日本語版が配布される、ということだったのですが、配布時間は夕方頃とのこと… 残念ではありましたが、英語版のBuilderCardsはいただけたので、ひとまず目標は達成です。 ▼ BuilderCards受け取り。私の前後にも多くの日本人の方がいらっしゃっていました。 ▼ 実際にBuilderCardsで遊べるブースも。 Sports Forum見学 ここではAWSの技術を利活用している様々なスポーツ分野を知る・体験することができます。 詳細は、下記記事をご参照ください。 AWS re:Invent 2025 Sports Forum | Amazon Web Services See how AWS helps professional sports organizations come to life. Don’t miss the chance to watch, play, and experience s... reinvent.awsevents.com ▼ やはり、アメリカンスポーツと言ったらアメフト、なんですかね。 ▼ AIでシュミレーションするゴルフ いくつかの戦略(パラメータ)を設定し、カップインを狙います。 ラスベガスでF1が開催されたこともあってか、F1に関する展示が数多くありました。 ▼ AWSが活用されている場面 @F1 映像配信やラップタイムの分析にAWS基盤が用いられているようです。 F1におけるラップタイム分析(Track Pulse)の詳細は、下記記事をご参照ください。 Real-time storytelling: The AWS architecture behind Formula 1® Track Pulse | Amazon Web Services On a FORMULA 1® (F1) race day, broadcasts face a significant challenge: identifying the most impactful stories for fans ... aws.amazon.com ▼ F1のタイヤ交換体験 実際に参加しましたが、ホイールガンがとても重かったです。逆にタイヤは軽かったです。 ▼ ここで偶然S3くん?に遭遇。ハグかと思いきや…抱っこされました。 ※ 顔が驚きすぎていたので、モザイクをさせていただきました… Optimize mission critical workloads with CloudWatch MCP & Amazon Q CLI Amazon Q CLIはKiro CLIに改名されましたが、本WorkShopでは旧名称だったので、本記事では旧名称に統一します。 続いて、WorkShopに参加しました。 WorkShopは個人作業で手を動かしながらサービスについて学ぶことができるセッションです。 このセッションでは、MCPサーバを構成し、様々な人間の立場からAmazon Q CLIでトラブルシューティングする流れを体験しました。 ▼ 使用したMCPサーバーの一つ。 この他にもAWSから提供されているMCPサーバーは数多く存在します。 AWSが提供するMCPサーバーについては、下記記事をご参照ください。 Welcome to AWS MCP Servers | AWS MCP Servers Get started with AWS MCP Servers and learn core features. awslabs.github.io また、人間の持つ役割に応じた権限設定を実現するためのガードレールについても紹介されていました。 エージェントの作成方法は、下記記事をご参照ください。 Creating custom agents - CLI - Docs - Kiro Learn how to create and configure custom agents for specialized workflows kiro.dev ▼ エージェントを業務の役職ごと複数定義し、役職外の操作を行おうとした場合 今回のWorkShopでは、hookに特定の条件下でエラーを発生させる(操作を拒否する)コマンドを入力していました。 hooksなどのConfigurationの設定方法は、下記記事をご参照ください。 Agent configuration reference - CLI - Docs - Kiro Complete reference for agent configuration file format kiro.dev A Special Closing Keynote with Dr. Werner Vogels Werner氏によるクロージングのKeyNoteです。 初日にサイン本をいただいたこともあり、必ず参加したかったものです。 Werner氏は今年のre:InventにてKeyNoteでの登壇を引退されるとのことだったので、今回が最後となるようです。 ▼ KeyNote開始前は弦楽器の生演奏でした。Werner氏のKeyNoteでは定番の演出のようです。 雰囲気がガラッと変わっていて、これも良かったです。 ▼ 過去の登壇映像とともに登場するWerner氏 ▼ 今回のテーマは「The Renaissance Developer」です。 Werner氏が実際に紹介していた「The Renaissance Developer」に関する参考記事は下記に記載しております。 The Kernel A one of a kind re:Invent newspaper. thekernel.news ▼ 「The Renaissance Developer」に求められる事項をまとめています。 また、KeyNote内でWerner氏が読むべき宿題として与えていた文献は下記の記事です。 私もこの宿題に取り組もうと思います。 Leverage Points: Places to Intervene in a System - The Donella Meadows Project By Donella Meadows~ Folks who do systems analysis have a great belief in “leverage points.” These are places within a co... donellameadows.org Werner氏のKeyNoteでは、以下の点が個人的には印象的でした。 仕事は「あなた(人間)」のもの。ツール(AIなど)のものではない → 仕事に対しては人間が責任を持ち続ける必要がある 人間同士の会話は曖昧性があるが、人間とコンピュータとの会話は厳密なものだった。 しかし、AIを含む自然言語処理技術の登場により、人間とコンピュータとの会話も曖昧になった。 → 人間とコンピュータの会話に齟齬が生じるリスクが出てくる → これを自然言語で厳密に会話していく仕組みが仕様駆動開発である Werner氏から贈られたメッセージは、日本に帰国してからももう一度ゆっくり噛み締めたいと思いました。 気になる方は、是非下記リンクより動画をご覧ください。 - YouTube YouTube でお気に入りの動画や音楽を楽しみ、オリジナルのコンテンツをアップロードして友だちや家族、世界中の人たちと共有しましょう。 www.youtube.com re:Play re:Inventの締めくくりと言ったら、おそらくこのイベント。 今までセッションが開催されていた会場とは異なる屋外でのイベントです。 re:Playについての詳細は、下記記事をご参照ください。 AWS re:Invent 2025 re:Play | Amazon Web Services You’ve earned it. Celebrate the end of another successful AWS re:Invent with the greatest party in tech. reinvent.awsevents.com ▼ 会場の様子。このイベントのためだけに広大な敷地に様々なアトラクションがあります。 ▼ バドミントンのコートも!皆さんre:inventでの思い出を残すべく楽しまれていました。 ▼ 弊社re:Invent参加メンバーで一枚。 初参加のメンバーが多かったですが、それぞれが充実した日々を過ごすことができました。 終わりに Werner氏のKeyNoteを初めて現地で見ましたが、エンジニアの一員として働く身に刺さる内容ばかりで、改めて現地で講演を見ることができて光栄だなと思った次第です。 いよいよre:Inventも明日(の午前中)で終了となります…! 驚くほどあっという間に時間が過ぎていきました。。 次回の投稿も引き続きお楽しみに!
こんにちは、ひるたんぬです。 この度「 AWS re:Invent 2025 」に参加できることになりましたので、現地での出来事や参加したセッションについてのレポートをお送りしたいと思います! 今回は、四日目の出来事を振り返ります! 今回の記事も比較的写真が多めの記事となります。ご了承くださいませ。 Day 4 re:Inventもいよいよ終盤に差し掛かってきました! 今日も目玉イベントが目白押しです! BuilderCards受け取り まずは、BuilderCardsを受け取りに行きました。 最近、弊社内でもBuilderCardsの普及に取り組まれている方がおり、少しずつではありますが、社内の認知度も高まっているのではないかと思っております。 Day 4に来た理由としては、この日に日本語版が配布される、ということだったのですが、配布時間は夕方頃とのこと… 残念ではありましたが、英語版のBuilderCardsはいただけたので、ひとまず目標は達成です。 ▼ BuilderCards受け取り。私の前後にも多くの日本人の方がいらっしゃっていました。 ▼ 実際にBuilderCardsで遊べるブースも。 Sports Forum見学 ここではAWSの技術を利活用している様々なスポーツ分野を知る・体験することができます。 詳細は、下記記事をご参照ください。 AWS re:Invent 2025 Sports Forum | Amazon Web Services See how AWS helps professional sports organizations come to life. Don’t miss the chance to watch, play, and experience s... reinvent.awsevents.com ▼ やはり、アメリカンスポーツと言ったらアメフト、なんですかね。 ▼ AIでシュミレーションするゴルフ いくつかの戦略(パラメータ)を設定し、カップインを狙います。 ラスベガスでF1が開催されたこともあってか、F1に関する展示が数多くありました。 ▼ AWSが活用されている場面 @F1 映像配信やラップタイムの分析にAWS基盤が用いられているようです。 F1におけるラップタイム分析(Track Pulse)の詳細は、下記記事をご参照ください。 Real-time storytelling: The AWS architecture behind Formula 1® Track Pulse | Amazon Web Services On a FORMULA 1® (F1) race day, broadcasts face a significant challenge: identifying the most impactful stories for fans ... aws.amazon.com ▼ F1のタイヤ交換体験 実際に参加しましたが、ホイールガンがとても重かったです。逆にタイヤは軽かったです。 ▼ ここで偶然S3くん?に遭遇。ハグかと思いきや…抱っこされました。 ※ 顔が驚きすぎていたので、モザイクをさせていただきました… Optimize mission critical workloads with CloudWatch MCP & Amazon Q CLI Amazon Q CLIはKiro CLIに改名されましたが、本WorkShopでは旧名称だったので、本記事では旧名称に統一します。 続いて、WorkShopに参加しました。 WorkShopは個人作業で手を動かしながらサービスについて学ぶことができるセッションです。 このセッションでは、MCPサーバを構成し、様々な人間の立場からAmazon Q CLIでトラブルシューティングする流れを体験しました。 ▼ 使用したMCPサーバーの一つ。 この他にもAWSから提供されているMCPサーバーは数多く存在します。 AWSが提供するMCPサーバーについては、下記記事をご参照ください。 Welcome to AWS MCP Servers | AWS MCP Servers Get started with AWS MCP Servers and learn core features. awslabs.github.io また、人間の持つ役割に応じた権限設定を実現するためのガードレールについても紹介されていました。 エージェントの作成方法は、下記記事をご参照ください。 Creating custom agents - CLI - Docs - Kiro Learn how to create and configure custom agents for specialized workflows kiro.dev ▼ エージェントを業務の役職ごと複数定義し、役職外の操作を行おうとした場合 今回のWorkShopでは、hookに特定の条件下でエラーを発生させる(操作を拒否する)コマンドを入力していました。 hooksなどのConfigurationの設定方法は、下記記事をご参照ください。 Agent configuration reference - CLI - Docs - Kiro Complete reference for agent configuration file format kiro.dev A Special Closing Keynote with Dr. Werner Vogels Werner氏によるクロージングのKeyNoteです。 初日にサイン本をいただいたこともあり、必ず参加したかったものです。 Werner氏は今年のre:InventにてKeyNoteでの登壇を引退されるとのことだったので、今回が最後となるようです。 ▼ KeyNote開始前は弦楽器の生演奏でした。Werner氏のKeyNoteでは定番の演出のようです。 雰囲気がガラッと変わっていて、これも良かったです。 ▼ 過去の登壇映像とともに登場するWerner氏 ▼ 今回のテーマは「The Renaissance Developer」です。 Werner氏が実際に紹介していた「The Renaissance Developer」に関する参考記事は下記に記載しております。 The Kernel A one of a kind re:Invent newspaper. thekernel.news ▼ 「The Renaissance Developer」に求められる事項をまとめています。 また、KeyNote内でWerner氏が読むべき宿題として与えていた文献は下記の記事です。 私もこの宿題に取り組もうと思います。 Leverage Points: Places to Intervene in a System - The Donella Meadows Project By Donella Meadows~ Folks who do systems analysis have a great belief in “leverage points.” These are places within a co... donellameadows.org Werner氏のKeyNoteでは、以下の点が個人的には印象的でした。 仕事は「あなた(人間)」のもの。ツール(AIなど)のものではない → 仕事に対しては人間が責任を持ち続ける必要がある 人間同士の会話は曖昧性があるが、人間とコンピュータとの会話は厳密なものだった。 しかし、AIを含む自然言語処理技術の登場により、人間とコンピュータとの会話も曖昧になった。 → 人間とコンピュータの会話に齟齬が生じるリスクが出てくる → これを自然言語で厳密に会話していく仕組みが仕様駆動開発である Werner氏から贈られたメッセージは、日本に帰国してからももう一度ゆっくり噛み締めたいと思いました。 気になる方は、是非下記リンクより動画をご覧ください。 - YouTube YouTube でお気に入りの動画や音楽を楽しみ、オリジナルのコンテンツをアップロードして友だちや家族、世界中の人たちと共有しましょう。 www.youtube.com re:Play re:Inventの締めくくりと言ったら、おそらくこのイベント。 今までセッションが開催されていた会場とは異なる屋外でのイベントです。 re:Playについての詳細は、下記記事をご参照ください。 AWS re:Invent 2025 re:Play | Amazon Web Services You’ve earned it. Celebrate the end of another successful AWS re:Invent with the greatest party in tech. reinvent.awsevents.com ▼ 会場の様子。このイベントのためだけに広大な敷地に様々なアトラクションがあります。 ▼ バドミントンのコートも!皆さんre:inventでの思い出を残すべく楽しまれていました。 ▼ 弊社re:Invent参加メンバーで一枚。 初参加のメンバーが多かったですが、それぞれが充実した日々を過ごすことができました。 終わりに Werner氏のKeyNoteを初めて現地で見ましたが、エンジニアの一員として働く身に刺さる内容ばかりで、改めて現地で講演を見ることができて光栄だなと思った次第です。 いよいよre:Inventも明日(の午前中)で終了となります…! 驚くほどあっという間に時間が過ぎていきました。。 次回の投稿も引き続きお楽しみに!
本記事は TechHarmony Advent Calendar 2025 12/5付の記事です 。 メリークリスマス、SCSK株式会社の小寺崇仁です。 (今回はAIを使ってブログ記事を作成しています) 近年、監視ツールの分野では「 APM(Application Performance Monitoring) 」と「 オブザーバビリティ(Observability) 」というキーワードが急速に注目されています。APMはアプリケーションの応答時間・エラー率・リソース使用率といった性能指標を監視して問題を発見します。一方オブザーバビリティは、複数のメトリックス、ログ、トレースを相関的に分析し、より深い原因究明を可能にする考え方です。 監視の世界は数値監視から文字列監視、そして今――画像を解析対象とする「 画像監視 」へと進化しつつあります。各製品がオブザーバビリティ機能を強化する中、 ZabbixもVersion 8.0から本格的に対応 を進めています。 以下では、「Zabbix × AI によるサンタクロース検知」を題材に、画像監視の新たな可能性を実験的に紹介します。 なぜ今「画像監視」なのか 従来の監視はCPU負荷やメモリ、サービス応答時間といった定量的なメトリックス中心でした。しかし、数値では表せない現場の状態――防犯カメラ、天候、道路状況、作業手順の逸脱など――にも重要な監視情報が存在します。 画像を監視対象とすることで、人間の「目」が担っていた判断を自動化し、監視の範囲を飛躍的に拡張できます。これが「オブザーバビリティの次の段階」と考えられます。 検証概要:Zabbix×AIによるサンタクロース検知 本実験の目的は、Zabbixを中心にAI画像解析を連携し、視覚的なイベントを監視対象にできるかを検証することです。 実際には作業PCのカメラが撮影した画像をZabbixに送信し、AIがその画像内に「サンタクロースらしいもの」が写っているか判定します。 今回はAI環境に ローカルLLM(Large Language Model) を採用しました。クラウドAIを利用する場合、API利用料や画像送信の通信コストが発生しますが、ローカル運用であれば コストを抑制し、内部データを安全に処理 できます。GPUを搭載したPC上で動作することで、 クラウドコストゼロ・低遅延・オフライン分析 を同時に実現できました。 検証環境構成 作業PC環境 機種:弊社標準ノートPC(Let’sNote) カメラ操作:PowerShell+FFmpegをユーザーパラメータ経由で実行 データ送信:撮影画像をBase64変換しZabbixへ送信 Zabbix環境 仮想アプライアンス:ZV-700 構成:CPU 2コア / メモリ 4GB AI解析環境 CPU:Ryzen 5 7600 メモリ:32GB GPU:RTX 4060 AI実行環境:WSL2+Docker+Ollama AIモデル:llama3.2-vision(ローカルLLM) 実装手順 1. カメラ撮影設定(作業PC側) FFmpegのインストール winget install ffmpeg 撮影スクリプト(photo.ps1) $CamName="USB HD Webcam" $FfmpegPath="C:\Users\scsk-kodera\AppData\Local\Microsoft\WinGet\Packages\Gyan.FFmpeg_Microsoft.Winget.Source_8wekyb3d8bbwe\ffmpeg-8.0.1-full_build\bin\ffmpeg.exe" $FilePath="C:\zabbix\photo.jpg" & $FfmpegPath -y -f dshow -i "video=$CamName" -frames:v 1 $FilePath -loglevel quiet 2>&1 | Out-Null $Bytes = Get-Content -Path $FilePath -Encoding Byte -Raw $Base64String = [System.Convert]::ToBase64String($Bytes) Write-Output $Base64String Zabbix Agent設定 UserParameter=get.file.photo[*],"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -NoProfile -ExecutionPolicy Bypass -File "C:\zabbix\photo.ps1" 2. 画像監視設定(Zabbix側) (1) 撮影アイテム 名前 撮影アイテム アイテムキー get.file.photo 監視間隔 1m (2) 画像保存アイテム 名前 画像アイテム タイプ 依存アイテム データ型 バイナリ マスターアイテム 撮影アイテム (3) AI画像判定アイテム 名前 サンタクロース判定アイテム タイプ 依存アイテム データ型 文字列 マスターアイテム 撮影アイテム 保存前処理(Javascript) AI_URL = 'http://192.168.0.244:11434/api/generate' ai_req = new HttpRequest(); ai_data = { "model": 'llama3.2-vision', "prompt": 'Does the person in the image look like Santa Claus? Answer only with "yes" or "no".', "images": [value], "stream": false, "options": { "num_predict": 5, "temperature": 0.0 } }; ai_resp = ai_req.post(AI_URL, JSON.stringify(ai_data)); ai_resp = JSON.parse(ai_resp); return ai_resp.response; ※ここでプロンプトを指定しています (4) トリガー設定 名前 サンタクロース検知 条件式 find(/pc/san,,,”Yes”)=1 3. AI環境構築 # Ubuntu導入 wsl --install -d Ubuntu-22.04 wsl -d Ubuntu-22.04 # Dockerセットアップ sudo mkdir -m 0755 -p /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin -y # Nvidiaのドライバ設定 curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg distribution=$(. /etc/os-release;echo $ID$VERSION_ID) curl -s -L https://nvidia.github.io/libnvidia-container/$distribution/libnvidia-container.list | \ sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \ sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list apt install -y nvidia-container-toolkit # Ollama起動(ローカルLLM) docker run -d --gpus all -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama docker exec -it ollama ollama pull llama3.2-vision # Windows側からアクセス設定 netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=11434 connectaddress=172.23.36.218 connectport=11434 検証結果 定期監視で撮影された画像がZabbix上に表示され、AI判定結果(Yes/No)が確認できます。サンタの風船を写したタイミングではAIが「YES」と回答し、トリガーが検知しました GPUリソースが正しく利用されており、ローカルLLMによる推論が安定して実行されています。クラウドに画像を送信しない設計のため、セキュリティ面でも保護された構成となりました。 注意点 Zabbixの保存前処理のタイムアウトは10秒です(変更不可)。 AI処理にはGPU性能が大きく影響します。 クラウド利用料やAPIトークンコストを避けるため、ローカルLLMを活用しています。 レスポンスを安定させるため、「num_predict=5」「temperature=0.0」でYes/No回答に限定しています。 まとめと今後の展望 今回のアドベントカレンダー記事では「サンタクロース検知」を通して、Zabbix×AI連携の新しい監視アプローチを検証しました。AI解析にはローカルLLM(llama3.2-vision)を活用し、クラウド依存のない低コスト・セキュアな画像監視基盤を構築しています。 今後の展開としては、AIを使った画像監視の高度化 が期待されます。 AIが物体や動きのパターンを学習することで、単純な「Yes/No判定」から「異常検知」「状態分類」「傾向分析」へとステップアップし、よりインテリジェントな監視が可能になります。 製造ラインでの品質検査や異常検知 天候・災害監視の自動化 道路交通や防犯映像のリアルタイム分析 オフライン環境でのローカルAI監視 OSSとAIによるオブザーバビリティ拡張の未来―― Zabbix × ローカルLLMによる AIを使った画像監視 が、監視の新しい形を切り開こうとしています。 SCSK Plus サポート for Zabbix SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします。 www.scsk.jp ★YouTubeに、SCSK Zabbixチャンネルを開設しました!★ SCSK Zabbixチャンネル SCSK Zabbixチャンネルでは、Zabbixのトレンドや実際の導入事例を動画で解説。明日から使える実践的な操作ナレッジも提供しており、監視業務の効率化に役立つヒントが満載です。 最新のトピックについては、リンクの弊社HPもしくはXアカ... www.youtube.com ★X(旧Twitter)に、SCSK Zabbixアカウントを開設しました!★ https://x.com/SCSK_Zabbix x.com
こんにちは、ひるたんぬです。 この度「 AWS re:Invent 2025 」に参加できることになりましたので、現地での出来事や参加したセッションについてのレポートをお送りしたいと思います! 今回は、三日目の出来事を振り返ります! 今回の記事も比較的写真が多めの記事となります。ご了承くださいませ。 Day 3 5K Race Day 3では、re:Invent定番のイベントの一つと言っても過言ではない「5K Race」が開催されます! 一言で言うと、日の出時刻辺りからラスベガス市街を5km走る、というイベントです。 イベント概要は、以下をご覧ください。 AWS Builder Center Connect with builders who understand your journey. Share solutions, influence AWS product development, and access useful... builder.aws.com 私は初日に参加受付をしていたので、朝5時に起床して会場に向かいました。 ▼ 事前受付後にもらえるゼッケン。ゼッケン(左側の白い帯)にはタイムを記録するためのタグが埋まっているようでした。 ホテルからスタート地点の会場まではバスによる送迎があります。あらゆるイベントにおいて、送迎があるのはとても助かります。 ▼ ウォーミングアップ会場。飲み物や軽食が提供されます。 ▼ レース中。朝の気温は約7℃でしたが、走るにはちょうどよい気候でした。 ▼ やっとの思いでゴール!記念にチェキも撮ってもらえます。 ゴール後は、専用のサイトから自分の順位やタイムを確認することができます。 私は30分程度でゴールできたのですが、半分くらいの順位でした。 上位の方は20分かからずゴールしているので…こちらの攻略は難儀を極めそうです。 ▼ 私の結果。専用のサイトより記録をエクスポートすることができます。 なお、余談ですが当日のレースの様子がFOX Newsに取り上げられているようですね。 ※ あくまで道路封鎖のお知らせですが… Amazon conference 5K shuts down I-15 off-ramp near Las Vegas Strip Amazon’s Web Service conference is in town this week, and every year, attendees participate in a 5K. www.fox5vegas.com AWS Jam: Generative AI 次はAWS Jamへの参加です。 こちらは「NVIDIA」がスポンサーのセッションなので、内容も生成AIに関するものでした。 ▼ 事前説明での一節。生成AIやエージェンティックAIを使いこなし、2026, 2027年以降に備えよう!と説明がありました。 今回は日本人4人でのチームで参加し、前回(Day 1)の参加経験を踏まえて挑みました。 意識したことは、 取り組む問題テーマをチームメンバーと話し合って決める (それぞれの経験有無等によって、取り組む問題の難易度や分野を分けたい) 二問目以降に取り組むときは取り組むテーマを宣言する (同じテーマに取り組んで時間ロスが起きることを防ぐ) ヒントは臆せず使う (30分悩んだ30点よりも、15分で解いた20点を意識する) → 時間が余るということは無さそうだったので、ひたすら解くことを優先するようにしました いざ、ゲーム開始です! ▼ 途中経過。上位3チームには順位を示す風船が置かれました。 私たちのチームは3位、2位…と調子が良いです!! 問題と格闘すること約3時間。あっという間に終了しました。 さて、気になる私たちの順位は…? 4位…惜しい!入賞まで70ポイント弱の差でした。 前回が真ん中(30位前後)であったことを考えると、内容やチームメンバーが変わっているのでなんとも言えないところではありますが、戦略の方向的には間違っていなかったのかなと感じました。 次回こそは、入賞…いや優勝したいですね。。 チーム名「EDLEN」の由来は、テーブルに置いてあったコンセントタップに書かれていた単語です。 記事執筆時に調べたところ、ラスベガスにあるイベントでの用品レンタル会社のようでした… 問題に取り組む中でKiroのSpec駆動開発やVibeコーディングをしたり、MCPサーバの利用設定をしたり…生成AIならではの作業やプロセスが一部でも体験できたことは非常に有意義でした。 ただしJamの形式上、入賞を目指し時間を意識して取り組んだので、改めてゆっくり時間をかけて触れたいなと思いました。 終わりに 三日目は名物のマラソンからAWS Jam参加…と、頭も体もフル活用した一日となりました。 re:Inventも残すところ後二日…最後まで満喫したいと思います! 次回以降の投稿も引き続きお楽しみに!
こんにちは!2年目の秋葉です! 入社2年目でまだまだ勉強中ですが、最近業務で「 Amazon FSx for Windows File Server(以下FSx) 」を触る機会がありました。 その中で、“PowerShellからシャドーコピーを設定してみる” という作業を経験したので、 同じようにFSxを扱う方や、これからPowerShell操作にチャレンジする方へ向けて、私の学びを共有したいと思います。 FSx、ボリュームシャドーコピーとは ここで、本記事の要となるFSx・シャドーコピーについて簡単に説明します。 FSx :WindowsファイルサーバーをAWS上にまるごと構築してくれるマネージドサービスです。 ボリュームシャドーコピー :ファイルやフォルダの過去バージョンを自動的に保存しておく仕組み 似た言葉で「スナップショット」といわれるものがありますが、シャドーコピーはあくまで「 仕組み 」です。 スナップショットはシャドーコピーで作成される成果物だと考えましょう。 今回使用する構成図 今回はWorkSpacesを使用してFSxのボリュームシャドーコピーを設定していきます。 AWS WorkSpacesとは、AWSが提供するマネージド型の仮想デスクトップサービスです。 クラウド上にWindowsまたはLinuxデスクトップ環境を構築でき、利用ユーザーは自宅や社内、出張先など、 どこからでも安全にアクセスできるようになります。 PowerShellからFSxに接続してみる 早速、WorkSpacesに接続してPowerShellを起動します。 ここでひとつ注意点があります。 ボリュームシャドーコピーの設定は、誰でもできるわけではありません。 FSx構築時に「 委任された管理者グループ 」として登録されたグループに所属しているユーザーのみが設定操作を行えるため、 自分のアカウントにその権限がない場合は、対象の管理者ユーザーとして実行する必要があります。 別ユーザーとしてPowerShellを起動出来たら、以下コマンドを使用してFSxに接続します。 “Windows Remote PowerShell EndPoint”は、FSxのマネコン上で確認可能です。 Enter-PSSession -ComputerName "Windows Remote PowerShell EndPoint" -ConfigurationName fsxremoteadmin 赤枠部分が適切なWindows Remote PowerShell エンドポイントであれば成功です。 シャドーコピーの設定 シャドーコピーの容量設定 今回は以下コマンドを使用して設定しました。 「-Default」 オプションを使用すると、シャドウストレージの量をボリュームの 10% に、シャドウコピーの最大数を 20 に設定します。 Set-FsxShadowStorage -Default スケジュール設定 スケジュールを設定する前に、[exit]コマンドを使用して、一度FSxから切断します。 以下コマンドを使用して、Windows スケジュールタスクトリガーを作成します。 JST時刻 で毎日00:00にシャドウコピーを取得するように取得しています。 $trigger1 = new-scheduledTaskTrigger -weekly -DaysOfWeek Sunday,Monday,Tuesday,Wednesday,Thursday,Friday,Saturday -at 00:00 次に、FSxにもう一度接続し、以下コマンドを使用してシャドーコピーのスケジュールを設定します。 Set-fsxshadowcopyschedule -scheduledtasktriggers $Using:trigger1 -Confirm:$false 設定時刻は UTC時刻 で表記されるので、間違えないように注意してください。 その他コマンド コマンド 説明 Get-FsxShadowStorage シャドウコピーストレージを表示 Get-FsxShadowCopySchedule シャドウコピースケジュールの表示 Remove-FsxShadowCopySchedule シャドウコピースケジュールの削除 New-FsxShadowCopy シャドウコピーの作成(手動) Get-FsxShadowCopies 既存のシャドウコピーの表示 Remove-FsxShadowCopies -Oldest 最も古いシャドウコピーの削除 Remove-FsxShadowStorage シャドウコピーのストレージ、スケジュール、およびすべてのシャドウコピーを削除する まとめ 今回は、FSxのボリュームシャドーコピーをPowerShellから有効化・スケジュール設定する流れをまとめました。 実際にやってみて感じたことをいくつか挙げます。 GUIよりも仕組みを理解しながら設定できる FSx構築時に「 委任された管理者グループ 」として指定したグループがかなり重要!(最初、ここでハマりました) スケジュール設定時は、一度FSxから 切断 する!(次に、ここでもハマりました) スケジュール設定時刻は JST表記 だが、表示時刻は UTC表記 に注意!(最後に、ここでハマりました) まだまだ学ぶことは多いですが、実際に構築してみると仕組みがぐっと分かりやすくなります。 これからFSxを運用していく方や、PowerShellを活用したい方の参考になれば幸いです。
当記事は、前回の記事「Ansibleを使用してNW機器設定を自動化する(PaloAlto-サービスグループ編①)」からの改善となります。 設定情報がベタ書きで使い勝手が悪い点 を 設定情報をまとめてINPUT(JSON)できる使い勝手の良い仕組みとしました!! これにより、Anibleとの連携ができるようになりますので、ご参考になれば幸いです。 ※前回記事: https://blog.usize-tech.com/ansible-automation-paloalto-servicegroup-1/ 当記事は、 日常の運用業務(NW機器設定)の自動化 により、 運用コストの削減 および 運用品質の向上 を目標に 「Ansible」 を使用し、様々なNW機器設定を自動化してみようと 試みた記事です。 Ansibleは、OSS版(AWX)+OSS版(Ansible)を使用しております。 PaloAltoの「Objects-サービスグループ」の登録/変更/削除を実施してみた 事前設定 Templateを作成し、インベントリーと認証情報を設定する。 インベントリー:対象機器(ホスト)の接続先を設定。 ※ホストには以下変数で接続先IPを指定 ansible_host: xxx.xxx.xxx.xxx 認証情報:対象機器へのログイン情報(ユーザ名/パスワード)を設定。 ユーザ名は 変数:ansible_user に保持される パスワードは 変数:ansible_password に保持される 事前設定2:設定情報をまとめてINPUT(JSON)できるように、「Survey」を活用 テンプレートが読み込むことができる変数(Survey)を設定する。※今回は、各設定のデフォルト値に値を設定する。 実際の値(JSON) ・input_servicegroup1:{"name":"test_servicegroup001","value":"test_service001"} ・input_servicegroup2:{"name":"test_servicegroup001","value":"test_service002"} ・input_servicegroup3:{"name":"test_servicegroup001","value":['test_service001','test_service003']} ・input_servicegroup4:{"name":"test_servicegroup001","value":"test_service003"} Playbook作成(YAML) 使用モジュール paloaltonetworks.panos.panos_service_group を使用。 ※参考ページ: Ansible Galaxy galaxy.ansible.com 接続情報(provider)の設定 providerには、ip_address/username/password の指定が必要。 vars: provider: ip_address: '{{ ansible_host }}' ← インベントリーのホストで設定 username: '{{ ansible_user }}' ← 認証情報で設定 password: '{{ ansible_password }}' ← 認証情報で設定 変数(Survey)の値取得 vars で 各変数(Survey)の値取得。 ※各変数(Survey)の値は、構造化データのように見えて「文字列」なので、ディクショナリ(構造化データ)として正しく扱えるように、from_json フィルターを使用すること!! vars: wk_input1: '{{ input_servicegroup1 | from_json}}' wk_input2: '{{ input_servicegroup2 | from_json}}' wk_input3: '{{ input_servicegroup3 | from_json}}' wk_input4: '{{ input_servicegroup4 | from_json}}' Objects-サービスグループの登録 ★ 変数(Survey)の値をそのまま使用した場合…エラーとなる 接続情報と サービスグループとサービスの関連付け( Survey:input_servicegroup1 ) を指定して登録( state: ‘present’ )を行う。 - name: Present ServiceGroup1 paloaltonetworks.panos.panos_service_group: provider: '{{ provider }}' name: '{{ input_servicegroup1.name }}' value: '{{ input_servicegroup1.value }}' state: 'present' register: wk_result 実行結果:構造化データではないので、オブジェクトに項目が無いという エラー となる。 ※Ansibleの実行結果を抜粋 "msg": "The task includes an option with an undefined variable. The error was: 'ansible.utils.unsafe_proxy.AnsibleUnsafeText object' has no attribute 'name'. ... Objects-サービスグループの登録 ※サービスグループの新規作成の場合 接続情報と サービスグループとサービスの関連付け( Survey:input_servicegroup1 ) を指定して登録( state: ‘present’ )を行う。 - name: Present ServiceGroup1 paloaltonetworks.panos.panos_service_group: provider: '{{ provider }}' name: '{{ wk_input1.name }}' value: '{{ wk_input1.value }}' state: 'present' register: wk_result 実行結果:対象のサービスグループが登録された。 ※Ansibleの実行結果(diff)を抜粋 "before": "", "after" : "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_servicegroup001\">\n\t<members>\n\t\t<member>test_service001</member>\n\t</members>\n</entry>\n" Objects-サービスグループの登録 ※サービスグループが既に存在する場合 接続情報と サービスグループとサービスの関連付け を指定して登録( state: ‘present’ )を行う。 ※サービスグループが既に存在する場合は、既存設定の置き換えとなる(state: ‘replaced’と同様) - name: Present AddressGroup1 paloaltonetworks.panos.panos_service_group: provider: '{{ provider }}' name: '{{ wk_input2.name }}' value: '{{ wk_input2.value }}' state: 'present' register: wk_result 実行結果:既存のサービスグループが 上書き更新 された。 ※Ansibleの実行結果(diff)を抜粋 "before": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_servicegroup001\">\n\t<members>\n\t\t<member>test_service001</member>\n\t</members>\n</entry>\n", "after" : "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_servicegroup001\">\n\t<members>\n\t\t<member>test_service002</member>\n\t</members>\n</entry>\n" Objects-サービスグループの変更 ※登録のつづき(新たなサービスを関連付けする) 接続情報と サービスグループとサービスの関連付け を指定して、サービスグループの変更( state: ‘replaced’ )を行う。 ※replacedの場合は、既存設定の置き換えとなる (注意:関連付け後の状態を指定すること!!) - name: Replaced AddressGroup1 paloaltonetworks.panos.panos_service_group: provider: '{{ provider }}' name: '{{ wk_input3.name }}' value: '{{ wk_input3.value }}' state: 'replaced' register: wk_result 実行結果:既存のサービスグループが 上書き更新 された。 ※Ansibleの実行結果(diff)を抜粋 "before": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_servicegroup001\">\n\t<members>\n\t\t<member>test_service002</member>\n\t</members>\n</entry>\n", "after" : "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_servicegroup001\">\n\t<members>\n\t\t<member>test_service001</member>\n\t\t<member>test_service003</member>\n\t</members>\n</entry>\n" 接続情報と サービスグループとサービスの関連付け を指定して、サービスグループの変更( state: ‘merged’ )を行う。 ※mergedの場合は、既存設定を維持した更新(Append)となる。 その為、特定サービスの関連付け解除はできない (注意:サービス の関連付け解除をしたい場合は state: ‘replaced’ を使用する必要がある!!) - name: Merged AddressGroup1 paloaltonetworks.panos.panos_service_group: provider: '{{ provider }}' name: '{{ wk_input4.name }}' value: '{{ wk_input4.value }}' state: 'merged' register: wk_result 実行結果:既存のサービスグループが 更新(Append) された。 既存設定が維持されていることを確認 。 ※Ansibleの実行結果(diff)を抜粋 "before": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_servicegroup001\">\n\t<members>\n\t\t<member>test_service002</member>\n\t</members>\n</entry>\n", "after" : "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_servicegroup001\">\n\t<members>\n\t\t<member>test_service002</member>\n\t\t<member>test_service003</member>\n\t</members>\n</entry>\n" Objects-サービスグループの情報収集 ※変更のつづき 接続情報と サービスグループ を指定して情報収集( state: ‘gathered’ )を行う。 - name: gathered AddressGroup1 paloaltonetworks.panos.panos_service_group: provider: '{{ provider }}' name: '{{ wk_input4.name }}' state: 'gathered' register: wk_result 実行結果:対象サービスグループの 情報が取得 できた。 ※Ansibleの実行結果(gathered_xml)を抜粋 "gathered_xml": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_servicegroup001\">\n\t<members>\n\t\t<member>test_service001</member>\n\t\t<member>test_service003</member>\n\t</members>\n</entry>\n" Objects-サービスグループの削除 ※変更のつづき 接続情報と サービスグループと関連付いているサービス を指定して、削除(state: ‘absent’)を行う。 ( 注意:関連付いているサービスが削除されるのではなく、サービスグループが削除される!!) - name: Absent AddressGroup1 paloaltonetworks.panos.panos_service_group: provider: '{{ provider }}' name: '{{ wk_input4.name }}' state: 'absent' register: wk_result 実行結果:対象のサービスグループが 削除 された。 ※Ansibleの実行結果(diff)を抜粋 "before": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_servicegroup001\">\n\t<members>\n\t\t<member>test_service001</member>\n\t\t<member>test_service003</member>\n\t</members>\n</entry>\n", "after" : "" 最後に 今回、変数(Survey)を活用したことで、Ansibleに INPUT(JSON)を設定 できるようになりました。 設定情報がYAMLにベタ書きではなくなったので、使い勝手は増しましたが、 都度 変数(Survey)のデフォルト値に値を設定しての実行の為、まだまだ 使い勝手が悪い。。。 今後 外部からAnsibleの INPUT(JSON)に値を連携し実行させる仕組みを試みたいと思います。
こんにちは。SCSKの松渕です。 2025年11月19日、 Gemini 3がリリース されましたね!それと同時にIDEである Antigravity の発表もされました! 今回は、AntigravityとGemini 3を利用して、簡易WEBサイトを Google Cloud環境上 に実装しました。 以前、Google社提供のコーディングエージェントの Julesを使ったこと があります。が、正直 全く別次元のレベルである と感じました。 はじめに Antigravityとは AWSのKiroと同様に、 AIエージェント型統合開発環境(Agentic IDE) と呼ばれるものです。 Antigravityのポイントとしては、特に以下の点になるかと思っております。 ・ AIによる ブラウザ操作も可能 ・ AIによる 自律的な実装 ・ アウトプット品質の高さ (これはGemini 3のポイントではありますが) ・ Google Cloud環境とのシームレスな連携 類似サービスとの比較は以下の通りです IDE/プラットフォーム 開発元 主な設計思想と特徴 類似サービスとの差別化ポイント Antigravity Google エージェント・ファースト 。AIが自律的にタスクを計画・実行・検証する。 マルチエージェント によるタスクのオーケストレーション。 自律性のレベル と End-to-End (ブラウザ操作を含む)実行能力。開発の 監督 に特化。 Kiro AWS 仕様駆動開発(Spec-Driven Development) 。要件→設計→タスク分解をAIと共同で体系的に進める。 Specモード と Vibeモード 。 開発プロセスの構造化 。ドキュメント(仕様書)を起点とし、 検証可能なコード品質 を重視。エンタープライズ親和性が高い。 Cursor Cursor, Inc. AIアシスタント型IDE 。コードの生成、編集、質問応答を強力にサポートする。AIチャットが非常に軽快で対話的。 AIはあくまで アシスタント であり、線形的なチャットベースの対話が中心。 即応性と軽快さ に優れる。 VS Code Microsoft 広く普及した 高機能なコードエディタ/IDE 。AI機能は 拡張機能 (例: Copilot)として追加される。 AI機能は拡張機能 であり、IDEのコア機能ではない。 私のスキルとブログ記載内容 私自身、普段はインフラが専門 で、アプリケーション開発の経験は多くありません。IDEもほぼ初めての利用になります。この記事では、そんな私と同じような視点を持つ方でも分かるように、初期インストールから詳しく解説しています。 「そんなところいいから、どんなもの作れるの?」って人は後半だけ読んで下さい! Antigravityのインストール まずは最初に、ローカル環境(PC)へAntigravityをインストールするところからになります。 ダウンロード Antigravityのサイト へアクセス。OSに合わせたモジュールをダウンロードします。 私の場合は、「Download for Windows」を押下し、Windows用の「Download for x64」を押下します。 → セットアップ画面が出てきます。必要に応じて設定内容変更しつつインストールしていきます。 → → → → 初期設定画面 Antigravityが起動し、初期設定画面が起動します。「Next」を押下します VS codeを利用している場合、設定をインポートすることも可能です。私は使っていないので「Start fresh」を選択します。 画面のトーンも選べます。ここは好みでよさそうです。私は「Tokyo Night」を選択しました。 次の画面は大事ですね。Antigravityにおいて AI エージェントにどこまで自律的な実装権限を与えるか です。 左カラムの「Agent-driven development」や「Agent assisted development」等の選択をすると、 右カラムの「Terminal execution policy」等が変わりますので、ポイントは右カラムになります。 Terminal execution policyについて エージェントが ターミナルでコマンドを実行する際の許可レベル を設定します。 Turbo: エージェントの判断でコマンドを即時実行し、開発速度を最大化します。(上級者向け) Auto: エージェントが安全性を判断し、リスクがない場合のみ自動でコマンドを実行します。(標準設定) Off: ターミナルでのコマンド実行を完全に禁止し、必ずユーザーの承認を求めます。(安全重視) 私は今回、完全お任せにしたかったので Turbo にしてます。 Review policyについて Always Proceed: ユーザーのレビューなしに、エージェントが生成したコードを即座にコミットします。 Agent Decides: エージェントが自信度などに基づいて、コミットを続行するかユーザーにレビューを求めるかを判断します。 Request Review: 生成されたコードをコミットする前に、必ずユーザーにコードの確認と承認を求めます。(推奨) 私は今回、完全お任せにしたかったので Always Proceed にしてます。 JavaScript execution policyについて Turbo: ユーザーの確認なしに、Web関連のスクリプトを即時実行します。 Auto: エージェントが安全性を判断し、リスクがない場合のみJavaScriptを自動で実行します。(標準設定) Always Ask: JavaScriptの実行前に、必ずユーザーに承認を求めます。 Disabled: WebビューなどでのJavaScriptの実行を完全に禁止します。 私は今回、完全お任せ(以下略) もう一つの要素に「 Use the default allowlist for the browser 」という項目があります。 allowlist とは、エージェントがWebサイトにアクセスしたり、Web上のリソースを使用したりする際の 安全性を担保するためのものです。 チェックを入れる(推奨): Google Cloudの公式ドキュメント、APIリファレンス、一般的な開発者向けサービスなど、エージェントがコード生成のために参照することが想定される 安全なドメインへのアクセスを許可 し、開発フローを円滑にします。 チェックを外す: あらゆる外部ドメインへのアクセスが厳しく制限されるため、セキュリティは向上しますが、エージェントが情報収集やAPIテストを行う際に ユーザーの承認を頻繁に求める ことになり、作業が滞りやすくなります。 今回はチェック入れております。 キーボードショートカット設定と、言語拡張機能をインストール設定画面が出ます。 こだわりなければ、 Normalを選択 して、 Install 7 Extensions にチェック入れた状態で Next を押下。 ここからGoogle アカウントとの連携設定に入ります。画面に従って、Googleアカウントとの連携設定を行います。 → → 認証完了したら以下の画面が出てきます。 Antigravityの画面に戻り、「セキュリティ上の注意喚起」と「データ収集への同意」の画面が出てきます。 以下のような内容が記載されております。 ユーザーは、 データ流出 や 意図しないコード実行 を含む潜在的なリスクに注意すべきです。 Googleがユーザーの Antigravity上での操作データ (エージェントへの指示、コードの修正、対話履歴など)を収集し、GoogleおよびAlphabetの研究、製品、サービスの開発・改善(特に機械学習技術の向上)のために使用することに同意します。 Antigravityの起動しました! 日本語化 Antigravityの画面から、左下の拡張機能(□4つあるようなアイコン)を選択。 検索画面で「Japanese」を検索し、 Japanese Language Pack for Visual Studio Code を選択し、 Install を押下。 信頼できる発行元かの確認が出ます。 Trust Publisher & Install を押下。 インストール後、再起動の確認画面が表示されます。 Change Language and Restrat を押下。 再起動後、日本語になりました! ※ただし、英語の部分もかなり残っています。いずれ日本語になることを期待します・・・! Hello Worldと表示されるサイト作ってみる エージェントモードで依頼 最初にOpenfileから作業フォルダを指定します。 次に、Antigravityのトップ画面から「Open Agent Manager」ボタンを押下する。 ※ Ctrl + Eボタン押下でも可 AIエージェントの動作を管理・監視する画面 として、「 Agent Manager 」が存在します。 従来のIDEに近い使い方としてコードエディタ画面でもAIを使うことは可能です。が、今回は エージェント・ファースト を体験したかったのでAgent Manager画面を利用します! Agent Manager画面が表示されます。なおGemini 3以外にもClaude Sonnet 4.5や、GPTも選べました。 今回はGemini 3 pro (High)を選択します。 → 「 hello worldと表示するサイト作って 」と雑な依頼を投げました。 計画を立てて自律的にアプリ開発をしてもらえました。 ブラウザ表示許可設定 Antigravityの特徴の一つである、ブラウザ操作を行うための初期設定に入ります。 Antigravity側から設定依頼が来ましたので、「Setup」を押下します。 画面遷移するので、「Install extention」を押下します。 Chromeが立ち上がります。Chromeの拡張機能としてAntigravityを追加することを確認されます。 「Chromeに追加」を押下して、追加します。 → 計画に沿ってAIが自動で進めてくれます。 見にくいですが、 ブラウザ表示のテストまでエージェントが実施 してくれます。 IDEの画面上に組み込まれてそのまま見れるのも使い勝手としていいですね。 PC上のフォルダを見ると、実際ファイルが作成されています。 PC上のindex.htmlをクリックすると、Hello Worldが出てきました!! Cloud Run上にデプロイする ここからがAntigravityの本領発揮です。Antigravityの特徴として、 Google Cloudとのシームレスな連携 が挙げられます!! 主な特徴は以下だと考えてます。 Cloud Run への デプロイ: gcloud CLI の初期設定だけしてあげれば、 「Cloud Runにデプロイして」の一言でデプロイ してくれます。 Cloud Logging の 参照およびアプリの自律的な修正 : Cloud Runのログを確認し、エラーを見てアプリケーションを改善、修正を自律的に行えます。 早速Cloud Runへのデプロイの手順に入っていきます。 gcloud CLIの設定 前提としてgcloud CLIの設定が必要になります。私の環境では、gcloud CLIの初期設定は実施済でした。 未実施の場合は、 gcloud CLIのインストール および 初期設定 を最初に実施する必要があります。 Antigravityで依頼する 雑に 「Cloud Run上にデプロイしてほしいな」と依頼 しました。まさかの、 これだけで一発デプロイ成功 しました!!! 何かしら失敗、もしくは聞かれるのではないかと思ってたので、 正直びっくり しました。 また、今回も ブラウザ表示のテストまでエージェントが実施 してくれました。 実機確認 Google Cloudの画面に移動します。Cloud Runサービスが新しく作成されていることを確認できました。 各種設定は、基本デフォルト値でデプロイされているように見えます。 最初のプロンプトの通り、Cloud Runの名前、サービスアカウント、Serverless VPC Access connector利用要否等の設定は一切指示しておりません。 すべてGemini 3で自動で設計/実装 されております。基本的にはデフォルト設定のようです。 リージョンについては、gcloud CLIのデフォルトリージョン設定で実装されたと思われます。 Artifact Registryを確認すると、 イメージも自動でアップロード されておりました。 このほか、Cloud Build使ってビルドしているのも履歴に残っておりました。 CloudRunのURLにアクセスしたところ、しっかりとHello Worldが表示されました! 非常に簡単ですね! Antigravityを使ってみた感想 素晴らしい点 高品質で自律的に実施してくれる 自然言語で依頼したら、 自身で考えて計画を立て、プログラム作成/修正 まで実施してくれます。 それだけなら今まで通りですが、 品質のレベルが今までと段違い だと感じました。 Hello Worldと表示するだけの機能ではありますが、こんな 雑なプロンプトで一発成功 は正直驚きでした。 Gemini以外の選択肢がある Gemini派、Claude派どちらも使えます!得意分野に応じて使い分け また、 Gemini 3のクォータに引っ掛かったときにClaude使う ということもできます! ブラウザの自律操作 テスト等で ブラウザ操作を自律的に実施 してくれます。 そして、それがIDEの画面内で完結するというのも、作業継続性が失われないという意味でもうれしいところです。 もったいない点 無料枠のクォータが少ない。 Gemini 3が人気すぎて、すぐ利用クォータの上限に引っ掛かります。これは仕方ないのですが。。 まとめ 今回は、GoogleのAIエージェント型IDE「 Antigravity 」を使って、シンプルなWebサイトを構築し、Cloud Runへデプロイする一連の過程をご紹介しました。AntigravityのようなAIエージェントをうまく活用すれば、 私のようなインフラエンジニアでも、プログラミングの世界に飛び込んでいける時代になったのだ と実感しました。 しかし、これは同時に新たな責任も伴います。これからは、 AIエージェントが 出力する計画やコードを評価し、指揮する という、 AIエージェントのプロジェクトマネージャー としての役割が求められていくでしょう。 セキュリティ上の問題はないか? 意図しないクラウドコストが発生しないか? エージェントの作成したデプロイ計画が、本番環境の要件を満たしているか? これらを判断するには、AIエージェントの出力内容を理解し、 「なぜ、そうなるのか」 という本質的な部分を理解し続け なければなりません。 ぜひ一度 Antigravity を試してみて、新しい開発の波に乗ってみてはいかがでしょうか。
こんにちは。SCSKの井上です。 この記事では、New Relicにおけるユーザー作成の手順や注意点について解説していきます。この記事で、New Relicの運用をより安全かつ効率的に行えるようになることを目指します。 はじめに この記事では、すでにアカウントをお持ちの方を対象に、ユーザー作成過程において有償ユーザーと無償ユーザーの違い、そしてカスタムロールの作成方法についても触れています。New Relic をチームで活用する際、ユーザーごとに適切な権限を設定することは、セキュリティと運用効率の両面で大切になります。この記事が、ユーザー管理の理解を深める一助となれば幸いです。以下の流れで解説していきます。 アカウントとユーザー アクセスの管理に関するチュートリアル | New Relic Documentation A tutorial that will walk you through creating and managing New Relic accounts and users. docs.newrelic.com 組織の作成(自動で作成) New Relicのサインアップが完了していない場合、以下の手順をご参考ください。この記事では割愛します。 【New Relic】使い始めるためのサインアップガイド この記事では実際にNew Relicを使う導入ステップとして、New Relicのサインアップ方法について解説していきます。初めてNew Relicを利用される方でもスムーズに始められるよう、必要な情報を順を追ってご紹介します。 blog.usize-tech.com 2025.11.19 アカウントの追加(任意) New Relicのサインアップが完了後、New Relicのアカウントを環境ごとに分けたい、プロジェクトごとに分けたい場合などは、この手順を参照してください。アカウントの追加は必須ではないため、1つのアカウントで運用する場合は、本手順はスキップしてください。なお、無料プランをご利用されている場合は、アカウントの追加はできません。 1.自身のユーザー名をクリック後、[Administration]を選択します。 2.「Access Management」をクリック後、「Accounts」タブを開き、 「Create account」をクリックします。 3.アカウント名を入力し、「Create account」をクリックします。 4.作成されたアカウントが表示されます。表示されない場合は、ブラウザの更新ボタンを押した後にご確認ください。 認証ドメインの設定(任意) New Relicでは、ユーザーがどうやってログインするか、どうやって追加・管理されるかを認証ドメインという単位で一元管理します。デフォルトではログイン方法はメール+パスワード、ユーザー追加方法はNew Relicコンソールから手動追加になっています。1つのメールアドレスで複数の認証ドメイン(手動追加とSCIM連携の両方)に参加はできません。また 認証方式はドメイン作成時に決定され、後から変更不可 になります。この記事ではデフォルトのログイン方法にて進めるため、SSO設定手順については割愛します。 項目 説明 ログイン方法(Method of authentication) – メール+パスワード – SAML SSO(シングルサインオン) ユーザー追加方法(Source) – 手動追加(UIから直接) – SCIM連携(IDプロバイダーから自動追加) 設定されている認証ドメインの確認方法は、左下の自身のアイコン>Administration>Authentication Domains の順にクリック後、以下の画面が表示されます。Sourceはユーザー追加方法、Method of authentificationはログイン方法を指します。無料プランでは設定をデフォルトから変更することはできません。ログイン方法はメール+パスワード、ユーザー追加方法はNew Relicコンソールからの手動追加のみとなります。認証ドメインを作成する場合は、「Create authentication domain」をクリックして設定します。 認証ドメイン: ユーザーのログイン方法と管理方法 | New Relic Documentation New Relic user authentication: how users are added, SAML SSO, SCIM, automated user management, and more. docs.newrelic.com カスタムロールの作成(任意) デフォルトで利用可能なロールがいくつかあり、これをStandard roleと呼びます。 デフォルトで使用可能なAdminグループとUserグループが作成されており、それぞれに割り当てられます。権限の細分化が不要で、AdminとUserのみで役割分担ができる場合は、Standard roleを利用します。なお、無料プランをご利用されている場合は、カスタムロールを作成することができません。 Standard roleの確認 Standard roleがどのようなものがあるのかを確認します。左下の自身のアイコン > Administration >Access Management > Rolesタブの順にクリック後、以下の画面が表示されます。Standard rolesは、以下4つが用意されています。 ロール名 説明 All Product Admin 組織全体の設定、ユーザー管理、請求情報など、すべての管理機能にアクセス可能※。 Standard User データの閲覧・ダッシュボードの作成・アラート設定などが可能※。ただし、ユーザー管理や請求情報にはアクセス不可。 Read Only データの閲覧のみ可能。設定変更やアラート作成などは不可。 Billing Manager 請求情報の閲覧・管理が可能。その他の機能にはアクセス不可。 ※アクセスにはロールとユーザータイプの2つが揃って実現できます。All Product AdminやStandard Userロールが付与されていても、ユーザータイプがBasicであれば、ユーザー設定やアラート設定などはできません。 【New Relic】New Relicアカウントの基本構造 この記事では実際にNew Relicを使う前の導入ステップとして、New Relicアカウントの基本構造について解説していきます。アカウントを管理していく上で、必要となる前提知識のため、ユーザ作成する前に知識を深める一助になれば幸いです。 blog.usize-tech.com 2025.11.12 該当のRole名をクリック後、どこの画面(機能)で何ができるのかが表示されています。細かく制御したい場合は、カスタムロールを作成することで可能です。 ユーザー許可 | New Relic Documentation An explanation of New Relic user permissions and what they govern. docs.newrelic.com カスタムロールの作成 Standard roleでは対応できない細かな権限設定や、アクセスを最小限に制御したい場合は、カスタムロールを作成します。 1.Administrationをクリック>Access Management > Rolesの順にクリック後、以下の画面が表示されます。無料プラン以外のアカウントは「Add new custom role」のボタンが表示されていますので、クリックします。 2.ロール名を入力し、チェックボックスをクリックして、ロールの付与を選択後、「Save」をクリックします。 3.Custom roles一覧に先ほど作成したロールが表示されます。名前の変更を行いたい場合や、ロールの変更を行いたい場合は、対象のロール名横の「・・・」より「Manage role」をクリックすることで編集が行えます。 グループの作成(任意) グループとは、特定のユーザーに対して、アカウントとロール(権限)をまとめて割り当てるための管理単位です。同じ組織内であれば、複数アカウントにまたがってグループを活用できます。デフォルトでは「Admin」と「User」グループが用意されています。役割毎に作成したい、プロジェクトやサービス毎で分けたいなど、用途に応じてグループを分けたい場合に、グループを作成します。この手順ではグループの作成に加え、グループとロールの紐づけについても説明します。 1.自身のユーザー名をクリック後、[Administration]を選択します。 2.「Access Management」>「Create new group」をクリックします 3.Group nameを記載後、「Create group」をクリックします。 4.作成したグループの設定画面が表示されますので、設定を行います。 5.グループに所属させたいメンバをプルダウンメニューから選択し、「Add user to group」をクリックします。 6.作成したグループはアカウントをまたいで利用できます。作成したグループをどこのアカウントのどのロールに紐づけるかを選択し、「Add role」をクリックします。ロールを追加しない場合、ユーザーをグループ追加しても、権限がない状態になります。 7.【ブランクでも可】このグループが他のグループのユーザー管理できるようにする場合 、管理するグループをプルダウンメニューから選択し、「Add role」をクリックします。※1 8.【ブランクでも可】この設定はグループ単位でまとめて付与したい場合に設定します。下記表※2を参考の上、「Close」をクリックします。 ※1 Group access group_admin権限を付与することで、他のグループのユーザー管理(追加/削除/変更)が可能になります。上記の手順では、Infra Groupに所属するFull platform権限を持つユーザーがUserというグループに属しているユーザーを管理できることになります。 ※2 Administrative settings New Relicの管理権限を個人単位ではなく、グループ単位でまとめて付与したい場合に設定します。例えば管理者グループを作成し、グループ内すべて同じ権限を付与する場合に使います。管理者や参照のみのユーザーが混在するグループに対して、この設定を行なった場合は、意図しないアクセスができてしまう可能性があります。 ロール名 説明 Organization Settings:組織名の変更、アカウントの追加・削除、エンティティの管理 Organization Manager 組織名の変更、アカウントの追加・削除、エンティティの削除など、組織全体の設定管理 Organization Read Only 上記設定の閲覧 Authentication Domain Settings:SSO設定、ユーザー追加・削除、グループ・ロール管理 Authentication Domain Manager 認証ドメインの設定、ユーザー追加・削除、グループ・ロールの管理 Authentication Domain Read Only 認証ドメイン設定の閲覧 Authentication Domain Add Users 認証ドメインへユーザーの追加 Authentication Domain Read Users 認証ドメインに属するユーザー情報の閲覧 Observability Settings:組織内のすべてのアカウントやエンティティに対して、オブザーバビリティ機能の設定・管理 Organization Product Admin APM、ダッシュボード、アラートなどの機能の設定・管理 Billing:組織のプランや請求情報を変更する機能 Billing User 請求情報の閲覧・管理 重要なユーザー管理の概念 | New Relic Documentation For New Relic user management: how permissions work, including how groups, roles, and permissions work. docs.newrelic.com ユーザーの作成 New Relicコンソールへアクセスするためのユーザーを作成します。気を付けたいポイントとしては、手順3のTypeは Basicユーザー以外は有償になります。契約数に関わらず、作成できてしまうので注意が必要 です。 1.自身のユーザー名をクリック後、[Administration]を選択します。 2.[User Management]をクリック後、[Add user]をクリックします。 3.赤枠の情報を入力して、[Create user]をクリックします。Type欄については、Basic以外は有償ライセンスになります。 4.「Create user」をクリック後、Accessの設定画面が表示されます。Add user to groupのプルダウンメニューより、どのグループに属するかを選択します(複数選択可)。選択後、「Add user to group」をクリックし、「Close」をクリックして完了します。 5.アカウント発行後、アカウントをアクティベーションしていない場合は、Emailの横にPendingが表示されます。 Pendingの表示がなくなっている場合は、ログイン済となります。 【補足】メールの再送希望や有効期限内に手続きができなかった場合は、Pendingにカーソルを合わせた後、ポップアップの「Resend email」をクリックして、再度メールを送信します。 ユーザーを作成後、初回サインインやプロフィール設定、権限変更の仕方は、以下の記事をご参照ください。 【New Relic】New Relicのログイン方法とユーザー設定 この記事ではNew Relicへのログイン方法と作成したユーザの権限変更やプロフィール情報変更について解説していきます。 blog.usize-tech.com 2025.11.26 さいごに New Relicのユーザー作成方法について、有償ユーザーと無償ユーザーとの機能の違いに加え、ユーザーごとの権限を柔軟に管理できるカスタムロールの作成方法の解説をしました。New Relicのユーザー管理は、チームの運用効率やセキュリティにも直結する重要なポイントですので、少しでもご理解いただければ幸いです。 SCSKはNew Relicのライセンス販売だけではなく、導入から導入後のサポートまで伴走的に導入支援を実施しています。くわしくは以下をご参照のほどよろしくお願いいたします。
本記事は TechHarmony Advent Calendar 2025 12/4付の記事です 。 こんにちは、アドベントカレンダー第4走者の坂木です。 本記事では、 保存前処理 の中でもテキストデータの加工処理に焦点を当て、以下の5つの機能について、具体的な設定例を交えながら解説します。 正規表現 置換 前後文字列削除 末尾文字列削除 先頭文字列削除 保存前処理について 保存前処理とは、Zabbixが監視対象から取得したデータを データベースに保存する直前に、その値を加工・変換するための機能 です。例えば、取得した値の単位を変換したり、JSONデータから特定の値だけを抽出したり、正規表現で不要な文字を削除したりできます。 これにより、不要なデータを保存せずに済むためデータベースの負荷を軽減できるほか、データを整形することで、より柔軟で高度な監視や分かりやすいグラフ描画を実現できます。 2 アイテムの値の保存前処理 www.zabbix.com 正規表現 正規表現は、取得したテキストデータから 特定のパターンに一致する部分を抽出・加工 できます。 パラメータとして「パターン」と「出力」を指定し、パターンに一致した部分をどのように出力するかを定義します。これにより、複雑なテキストデータも柔軟に扱うことができ、監視の精度を大幅に向上させることが可能です。 ユースケース コマンドの実行結果から、特定の数値だけを抜き出す ログメッセージからステータスコードやエラーメッセージを抜き出す ログからIPアドレスを抽出して接続元を監視する 実例 以下の/var/log/httpd/error_logから、エラーログの内容のみ抽出する保存前処理を設定します。 # cat /var/log/httpd/error_log [Tue Nov 25 04:42:11.673140 2025] [suexec:notice] [pid 2043:tid 2043] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Tue Nov 25 04:42:11.728157 2025] [lbmethod_heartbeat:notice] [pid 2043:tid 2043] AH02282: No slotmem from mod_heartmonitor [Tue Nov 25 04:42:11.729082 2025] [systemd:notice] [pid 2043:tid 2043] AH10497: SELinux is enabled; httpd running as context system_u:system_r:httpd_t:s0 [Tue Nov 25 04:42:11.747259 2025] [mpm_event:notice] [pid 2043:tid 2043] AH00489: Apache/2.4.64 (Amazon Linux) configured -- resuming normal operations [Tue Nov 25 04:42:11.747282 2025] [core:notice] [pid 2043:tid 2043] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND' アイテムおよび保存前処理の設定は以下のとおりです。 設定した正規表現は、行の先頭から見て、最後の” ] “とスペースに続く部分をすべて取得する、という設定となっています。 正規表現のパラメータ 設定値 説明 パターン ^.*\] (.*) 行頭からすべての文字を読み取り、最後の部分をキャプチャ 出力 \1 キャプチャした部分(.*)を返す こちらのように取得されます。 置換 置換は、収集したデータに含まれる 特定の値や文字列を、データベースに保存する前に別の値や文字列に置き換える 機能です。 これにより、特定のコードを意味の分かりやすいテキストに変換したり、不要な文字を取り除いたりすることが可能となります。 ユースケース MB, GB などの単位や不要な記号を空欄に置換して、必要な文字列だけに整形する UP, DOWN のようなステータス文字列を 1, 0 のような数値に変換して、グラフ化やトリガー条件に使いやすくする 実例 以下のようにメモリの利用量を取得するスクリプトに対し、単位を削除して数値だけに整形する保存前処理を設定します。 ▼監視対象スクリプト # /etc/zabbix/work/mem.sh 1.01 GB アイテムおよび保存前処理の設定は以下のとおりです。今回利用しているアイテム(system.run)の利用方法は こちら をご参照ください。 置換のパラメータ 設定値 説明 検索文字列 <単位> 削除する(空欄に置換する)単位を記載 置換文字列 <空欄> 単位を削除するため空欄のまま こちらのように取得されます。 文字列削除 文字列削除は、保存前処理の パラメータに含まれる文字を、アイテムが取得した値の先頭や末尾から削除する 機能です。 文字列削除機能には、以下の3種類があります。 保存前処理名 説明 前後文字列削除 データの先頭と末尾にある特定の文字を削除 末尾文字列削除 データの末尾にある特定の文字を削除 先頭文字列削除 データの先頭にある特定の文字を削除 ユースケース ログ収集の過程で付加される可能性のある、先頭や末尾の余分なスペースを整形する 実例 以下の文字列に対して、指定した文字(今回は「#」)を削除する保存前処理を設定します。 (本来は末尾のスペースを削除したかったのですが、Zabbixのインターフェース上ではスペースの有無が分かりにくいため、見えやすい「#」を削除する例で説明します。) ▼書き込んだ文字列 te##st test### ###test ###test### アイテムおよび保存前処理の設定は以下のとおりです。 保存前処理名 文字列削除のパラメータ 設定値 説明 前後文字列削除 文字列のリスト # 先頭と末尾の#を削除 末尾文字列削除 文字列のリスト # 末尾の#を削除 先頭文字列削除 文字列のリスト # 先頭の#を削除 こちらのように取得されます。 まとめ Zabbixの保存前処理は、未加工のデータを「使える情報」に変えるための重要な機能です。 正規表現や置換で柔軟な抽出・変換が可能で、前後・先頭・末尾の文字列削除により不要な情報を除去できます。 本記事を参考にぜひ保存前処理を利用してみてください。 弊社ではZabbix関連サービスを展開しています。以下ページもご参照ください。 ★Zabbixの基礎をまとめたeBookを公開しております!★ Zabbix資料ダウンロード|SCSK Plus サポート for Zabbix Zabbix監視構築に必要な知識と最新機能についての資料をダウンロードできるページです。世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします。 www.scsk.jp ★SCSK Plus サポート for Zabbix★ SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします。 www.scsk.jp ★SCSK Zabbixチャンネル★ SCSK Zabbixチャンネル SCSK Zabbixチャンネルでは、最新のZabbixトレンドや実際の導入事例を動画で解説。明日から使える実践的なノウハウを提供します。 今すぐチャンネル登録して、最新情報を受け取ろう! www.youtube.com
こんにちは、ひるたんぬです。 この度「 AWS re:Invent 2025 」に参加できることになりましたので、現地での出来事や参加したセッションについてのレポートをお送りしたいと思います! 今回は、二日目の出来事を振り返ります! 今回の記事も比較的写真が多めの記事となります。ご了承くださいませ。 Day 2 Day 2からは毎日KeyNoteというセッションが開催されます。 そのため、二日目はKeyNoteの聴講からスタートです。 Opening Keynote with Matt Garman KeyNoteでは、AWSにおける新サービスやアップデートなどが数多く紹介されます。 初回のKeyNoteはAWSのCEOであるMatt Garman氏によるKeyNoteです。 本記事では、KeyNoteの具体的な内容には触れません。 ▼ 講演会場オープン時。非常に多くの方で賑わっています。 ▼ DJが会場を盛り上げています。こちらはAWS Summitでも見られる光景ですね。 ▼ Matt Garman氏登場。 上の画像は、Ambassadorの木澤さんよりいただきました。 (前方に座れるのは羨ましいですね…!) ▼ 様々な発表がありました。 コンテンツの内容に応じて、会場が一体となり盛り上がる様子は写真や映像では表現しがたいものがあります。 KeyNoteを聞いてみて、個人的には 今回は「Why not – ?」、日本語で表現すると「〜しませんか?」というテーマがあると思った。 AWSはすべてのステークホルダー(AWS利用者・サービス提供者・パートナーなど)と共創していく、という姿勢を強く感じた。 生成AIを利活用するベネフィットとして「睡眠時間の確保」を挙げていた点が特徴的に感じた。 という感想を持ちました。特に3つ目については、(私が想像する)一般的なベネフィットである「人間が人間にしかできない創造的なことをする時間に充てられる」という視点と異なるものだったので、新鮮な印象を受けました。(ステークホルダーの一員である開発者を大切にする姿勢、といったところでしょうか。。) SWAG回収・Expo巡り AWS re:Inventの特徴の一つといえばSWAGの豪華さ・多さもあるのではないでしょうか。(経験者の多くはスーツケースを半分空けるようおっしゃっているので…) そのため、Day 2の残りはSWAGの回収とAWSやパートナーなどが出展しているExpoを巡りました。 ▼ SWAGの受け取り。日を改めると新しいSWAGに出会えるかも…? こちらはAWSが開催する「/dev/quest」による景品受け取り時です。 「/dev/quest」の詳細は、以下記事をご覧ください。 AWS Builder Center Connect with builders who understand your journey. Share solutions, influence AWS product development, and access useful... builder.aws.com ▼ 受け取ったSWAGの一例。 「Quack the Code」の帽子は、海外の方に頻繁に話しかけられる・イジられるなど好評でした。 ▼ 実際に言われたセリフ例 Like the hat! ※ 5人くらいに全く同じことを言われました。 Quack! Quack! ※ メガホンを持ったAWSスタッフに… Expoでは、日本では一度も見たことがない企業による出展や、各社の提供するサービスの強みを熱心に説明している姿が印象的でした。 また、一部のブースでは日本語にて説明を受けることができ、英語ができないから何も分からない・楽しめない、という心配は無さそうでした。 日本語対応可能な方の服には、日本国旗が貼り付けられていました。 ※ 実際に「日本語対応可能な方=日本国旗が貼り付けられている」というルールがあるかは確認をしていません。 ▼ Expo入口。入る前からワクワクが止まりません。 ▼ 展示の一部。こちらの方々は、AWSのデータセンターをVRでツアーされています。 ▼ ラスベガスでは直近でF1レースが開催されていたこともあり、それにちなんだ展示も。 コースはラスベガス市街でした。本物のF1レースのコースと同じなのでしょうか…? House of Kiro体験 今年のre:Inventに突如現れ話題となっている「House of Kiro」にもお邪魔してきました。 こちらは何かサービスの紹介があるというものではなく、コンセプトを楽しむアトラクションの一つでした。 ▼ 今にも「何か」が出そうな外観。出て欲しくないけど出て欲しい…? ▼ 無事に生還できました!楽しかった!! Golden Jacket受け取り 今回のre:Inventでは、会期前にAWS認定資格をすべて取得した方向けにGolden Jacket(通称「金ジャケ」)が渡される「AWS re:Invent 2025 Golden Jacket Program」がありました。 私は、今回上記参加資格をなんとか満たすことができたので、受け取りをしました。 ▼ いただいたGolden Jacketが入っている箱。重厚感がありますね。 ▼ 認定者ラウンジにて。受け取った方はここで写真を撮られていることが多かったです! Japan Night 最後はre:Invent Japan Tour参加者(及びJapan Night申込者)が参加できる、Japan Nightというイベントに参加してきました。 こちらは主に日本から参加している方の交流が目的とされたイベントとなっており、用意されていたイベントを通じて多くの方と会話することができました。 ▼ 今回はボウリング場を貸し切って行われました。 ▼ 用意されたイベントの一つはラスベガスらしく?コミュニケーションポーカーというオリジナルゲームでした。 ▼ 会場の方と積極的にコミュニケーションを取り、気がついたら「ロイヤルストレートフラッシュ(一等)」に。 豪華な景品をいただきました! 終わりに 二日目からはKeyNoteが始まり、SWAGやExpo巡りなど、re:Inventならではのイベントを満喫することができました! また、帽子を通じて外国人の方とさりげないコミュニケーションを取れたのは良い思い出です。 次回以降の投稿も引き続きお楽しみに!