SCSKクラウドソリューション の技術ブログ
全1226件
こんにちは！SCSKサイトーです🐧 Snowflakeに Cortex Code がリリースされました。 これが、もう、とても便利です。 「あ、これSQL初心者のSnowflakeライフが、かなり改善されるやつだ」 と素直に思いました。 どう改善されたのかをぜひお伝えしたい！ ──そう思い、戦い形式でお届けします。 ※利用しているデータはすべてサンプルデータです Snowflake Cortex Codeとは Snowflake Cortex Codeを端的に言えば、 SnowflakeにてSQL/Pythonコードを考えるだけでなく、作ってくれるAI機能 今回紹介するのは Snowsight（Web UI）版 の Cortex Codeです！ なお使う為には以下設定が必要です👇 利用アカウントが クロスリージョン推論 を有効 利用ユーザーが SNOWFLAKE.COPILOT_USER & “SNOWFLAKE.CORTEX_USER または SNOWFLAKE.CORTEX_AGENT_USER” ロールを保持 第1回戦：しょうもない誤字 まずは初心者やりがちの事故から（お分かりいただけただろうか…） テーブル名がスペルミス ついでにSQL句も間違ってる ということがありました。 エラー文の下部「修正」をクリックすると、Cortex Codeが正しい回答を教えてくれます。 しかもなんと「保持」をクリックすると、正しいSQL文に書き換えてくれます。 これで「上司に勇気出してエラー相談したら、ただの誤字だった」問題とサヨナラ！ 第2回戦：既存SQLの解説 「毎月のデータを抽出して。よしなにこのSQLを使い回せばいいから」と言われたとき 過去の賢人が作った長いSQLを見て どこを直せばいいのか、そもそも何しているのかすら分からん…。 そんなときもCortex Code！ 雑なプロンプトを投げるだけで、SQL文の解説をしてくれます！ 第3回戦：そもそも0から作る そして最大の山場 SQLが作れない ORDER BY？ DESC？ASC？ 正直、その場その場で検索していました。 そんな状態でも Cortex Codeは助けてくれます！ プロンプトで指示するだけで 対象テーブルの中身に沿ったSQL を生成してくれます！ 「SQLを知らないからSnowflake触れない。。」 という前提が、少しずつ崩れています！ まだまだ戦いは続く ここで重要なポイント！ Cortex Codeがすごいのは、 ✅ 実際のテーブル名・カラム名を含めて考えてくれること 普通の生成AIだと、 テンプレSQLは出る でも「どこを置き換えるか」が分からない ということがよくあります。 Cortex Codeは、 Snowflake内の実データを用いて、そのまま使える代案を出してくれます！ 唯一の欠点は、「元に戻す」「保持」という選択肢が分かりづらいです。（個人の感想） 代案を書いてもらった後に、「保持って代案が残るの？私が書いたのが残るの？」と時々迷います…（正解は前者です） 我々の戦いはまだまだ続いていきます！ まとめ ここまで読んでいただいて、 「Cortex Code、便利そうだな」 と少しでも思ってもらえたら嬉しいです！ 今回はSQLの話でしたが、Pythonコードにも使えます。 Cortex Codeを使ってPythonでStreamlitアプリ作成するといった上級者向けの使い方も ゆくゆくは試していきたいです！
TechHarmonyエンジニアブログでは、 AWS・Oracle Cloud・Azure・Google Cloud 各分野の受賞者 にフォーカスし、インタビューを通してこれまでの経歴や他の受賞者に聞いてみたいことをつないでいく「 リレーインタビュー 」をお届けしています。 第5弾は、「2025 Japan AWS Top Engineers」 を受賞された福地 孝哉（ふくち たかや）さん。 Japan AWS Top Engineers は、特定の AWS 認定資格を持ち、AWS ビジネス拡大につながる技術力を発揮した活動を行っている方、または技術力を発揮した重要な活動や成果がある方が選出されるプログラムです。 日々どのようにAWSと向き合い、どんな経験を積み重ねてきたのか。 そして、受賞に至るまでの背景には、どのようなキャリアストーリーがあったのでしょうか。 本インタビューでは、畑さんのこれまでの経歴やAWSへの向き合い方、さらに「次の受賞者へ聞いてみたいこと」まで、じっくりとお話を伺いました。 プロフィール 2025 Japan AWS Top Engineers 所属： エンジニアリング革新本部エンジニアリング革新推進部 氏名： 福地 孝哉 【自己紹介】 現在“技術戦略本部デジタル推進部“に所属し、AIを活用したシステム開発を全社に定着させるための取り組みを行っています。先端技術の調査・研究や技術支援を通じて、 AI駆動開発の推進を担当 しています。あわせて、AWS上で稼働する自社サービスの開発品質および生産性の向上に取り組んでいます。 本編 AWSエンジニアになった背景を教えてください。 学生時代はIT技術未経験でしたが、就職活動時のOB訪問がAWSに興味を持つ最初のきっかけでした。当時は社会全体でリモートワークが急速に広がり、オンプレミスからクラウドへの移行が加速した時期でもあり、OBの方から仮想化技術を基盤として提供されているAWSが、今後のI T基盤において重要な役割 を担っていくことを教えていただきました。社会やビジネスの変化に即応できる点に大きな可能性を感じました。入社後は、AWS社講師による新人研修を通じて、Amazonのイノベーション文化から生まれた AWSのパワフルさ とスピーディーさを学びました。 AIを活用した判定システムを短時間で構築するデモを体験し、 アイデアを素早く形に できるAWSならではのものづくりの 楽しさ も実感しました。加えて、活発な AWS コミュニティ （JAWS-UG）や初心者向けの 教材が充実 している点も、AWSの世界に踏み出す後押しとなりました。 エンジニアとして大切にしている価値観や信条はありますか？ 変化の激しい時代においても、技術を追い続けながらその本質を正しく理解することを大切にしています。AI時代に入り、技術進化のスピードは加速しています。その中で価値を提供し続けるため、日々の 学習と情報収集 を欠かさず、AWSの「 What’s New 」などを通じて最新のサービス動向を把握し、社内で週次の 情報発信 を行っています。また、Amazonのリーダーシップ・プリンシパルの一つである「 Dive Deep 」の精神も大切にしています。AWSは高い抽象化によって利便性を実現している一方、 内部挙動の理解 が重要になる場面も少なくありません。私は表面的な理解にとどまらず、 実際に検証を重ねて本質を理解すること を重視しています。ECSの挙動を深く調査し、 公式ドキュメントの改善 に貢献した経験もその一例です。今後も技術に真摯に向き合い、仲間やお客様から 信頼 されるエンジニアであり続けたいと考えています。 https://www.aboutamazon.jp/about-us/leadership-principles この度は受賞おめでとうございます！ 受賞に至るまで特に重点を置いて取り組んできたこと・乗り越えたチャレンジを教えてください。 AWSを使った 成功 / 失敗 の体験を個人の経験に留めず、再現可能な形で広く 共有 することに取り組んでいます。特に案件を通じて得たサーバレス設計の知見を整理し、ガイドライン化や登壇を通じて展開することで、社内外で活用できる状態を整えてきました。若手エンジニアの技術力の底上げを目的とした 育成施策 に加え、AWSへの理解を深めるため GameDay を開催し、実践を通じて学べる環境づくりを進めてきました。これらの活動を通じて、 「組織内外でAWSを使いこなせる人を増やす」 ことを目指し、継続的にチャレンジしています。 受賞がご自身のキャリアやチームに与えた影響はありますか？ これまで関わってくださった お客様 や プロジェクトメンバー の 皆様と共に 積み重ねてきた取り組みが評価された結果であり、深く感謝しています。個人としての受賞ではありますが、多くの方々との協働なくして成し得なかった 成果 であり、自身のキャリアにおいても 自信 となりました。現在はクラウドを取り扱う部署から異動していますが、引き続きAWSで培った知見を活かし、チーム内外問わずアーキテクチャ改善等の相談を受ける機会が増えています。受賞をきっかけに、技術面に加えて、より幅広い役割を期待されるようになったと感じています。また、社外への発信活動が目に留まり、出身大学での講義において講演の機会をいただくなど、次世代に 働く価値観 ・ キャリア 、 技術の面白さ を伝える 場にも関わるようになりました。今後はこうした経験で得た知見や繋がりを組織に還元し、 社会全体のさらなる価値向上に貢献していきたい と考えています。 今後、個人として、挑戦してみたい新しい技術・分野や、目指している目標について教えてください。 チームとして「 AI駆動開発 」の 実践 と 現場への定着 を進めていきます。弊社の技術ビジョン2030に掲げられている「 AI駆動型開発適用100％適用 」は、単なるツール導入にとどまらず、設計・実装・テスト・運用までを含めた 開発プロセス全体（SDLC）の変革 だと捉えています。AIエージェントを活用しながら、プロジェクトでの適用結果や成功事例を共有し、情報発信を通じた啓蒙活動にも取り組み、 AIを前提 とした 開発文化 を組織全体に根付かせていきたいと考えています。 https://www.scsk.jp/sp/technology_strategy/scsk_techstrategy.html 前回のリレーインタビューでの畑 健治さんから 福地さんへのご質問です。ご回答をお願いいたします 福地さんはいわゆる現場部隊からコーポレート部隊へ異動されたとお伺いしていますが、 異動に伴い 自身の意識や取り組みとして 特に変化したこと があれば教えてください。 以前は目の前のお客様への貢献が中心でしたが、現在はハブとして様々なプロジェクトに関与しながら、その取り組みをいかに横展開できるか、組織として持続可能な形にできるかをより意識するようになりました。AIをはじめとした技術をいち早く試せる環境を活かし、実際に手を動かしたり、多くの部署を通じて得られた知見を整備することで、現場で実践的に活用できる形に落とし込むことを大切にしています。 次のインタビューは AWS Top Engineers の「安彦 洋樹」さんです！安彦さんにお聞きしたいことはありますか？ 安彦さんはプレイングマネージャーとして技術の最前線に立ちながら、メンバーを育てていくことにも力を注がれていると思います！ 日頃メンバーと接するうえで工夫されていることや、大事にしていることがあればぜひお聞かせください！ 福地 孝哉さん、ありがとうございました！ 最後に、読者の方へメッセージをお願いいたします！ 私たちは、クラウドをはじめとした技術を強みに、 お客様やパートナーの皆さまと価値創出に取り組んでいます。 技術を楽しみながら、 ぜひ一緒に未来を創っていきましょう。 次回インタビューは、2025 Japan AWS Top Engineers を受賞された 安彦 洋樹（あびこ ひろき）さんです。 次回の記事もお楽しみにお待ちください！
Genspark で人気の高い Deep Research について紹介します。Gensparkとは？については以下をご覧ください。 エージェント型AI Gensparkとは？ 次世代型AIオールインワンワークスペース Genspark（ジェンスパーク）AI ワークスペース 3.0 について紹介します。 blog.usize-tech.com 2026.03.24 Deep Researchとは？ Genspark の Deep Research（ディープリサーチ、深層研究） とは、 複数のAIモデルが協調して インターネット上の大量の情報を自動収集・分析し、詳細なレポートを生成してくれる高度なリサーチ機能 です。単なる検索を超え、数百の情報源を読み込んで整合性の取れた回答を提供します。 Deep Research（またはDeep Search）は、Genspark だけでなく、ChatGPT、Gemini、Claude、Perplexityなどにも実装されている機能となりますが、Gensparkの特徴としては、Deep Research V2 では「o3-mini-high」「DeepSeek R1」「Claude」「Gemini」「GPT」など複数のAIが連携して分析を行うところにあります。 サービス 機能名 無料利用可否 特徴 Genspark Deep Research 一部可 複数AIモデル協調 ・マインドマップ ChatGPT Deep Research 不可 最高精度・長文レポート生成 Gemini Deep Research 一部可 Google検索、Workspace連携 Claude Advanced Research 不可 長文PDF読解・安全志向 Perplexity Deep Search 一部可 高速・出典リンク表示 Microsoft Copilot Deep Research 一部可 Office（doc/xls/ppt）連携 Deep Researchの利用方法 まずは、単純なプロンプトで入力してみましょう。 以前と同じく”オンラインストレージ市場”を前提とし、プロンプトは「 オンラインストレージ市場の今後の5年間の展望について 」としてDeep Researchをまず実行してみました。 Deep Researchで完成したレポートについては、Genspark の Sparkpage（スパークページ） 機能を利用して、Web公開することが可能ですので、実際に完成したレポートを公開します（加筆/修正なし） オンラインストレージ市場の今後5年間の展望（2025-2030年） https://qdaiyuza.gensparkspace.com/ プロンプトが簡易すぎたため、いわゆるオンラインストレージ（ Dropbox 、 OneDrive 、 Google Drive 、 Box ）だけでなく、クラウドストレージ（AWS、Azure、Google Cloud）など他のストレージの情報も含まれています。 さすがに、Deep Researchを利用する場合には、もう少し詳細なプロンプト指示が必要そうです。 効果的な Deep Research プロンプトは、目的 + 範囲 + 出力形式の3点を入れると安定するとされています。 目的 : 何を決めたいのか 範囲 : 期間、地域、業界、対象企業 出力形式 : 表、箇条書き、比較、結論、未確定点（疑問点） そのまま使えるプロンプトの例としては、 ・市場調査 「2025年の日本国内〇〇〇市場について、主要ベンダー、成長要因、課題、今後12か月の見通しを、根拠付きで整理してください。」 ・競合比較 「A社、B社、C社の〇〇〇製品を比較してください。機能、運用負荷、導入難易度、使い勝手、価格感、強みと弱みを表でまとめてください。」 ・提案準備 「社内向けに『〇〇〇製品を採用すべきか』を判断したいです。導入メリット、懸念点、想定される反論、代替案まで整理してください。」 ・規制調査 「EUと日本のデータ保護関連の最新動向を比較し、企業のIT運用に与える影響を要点だけまとめてください。」 ・技術トレンド 「2025年以降の〇〇〇の技術トレンドを、実運用で重要な観点に絞って整理してください。」 オンラインストレージ市場調査のより効果的なプロンプトとして「 Dropbox、BOX、One Drive、Google Driveのオンラインストレージ製品を比較してください。市場シェア、機能、運用負荷、導入難易度、使い勝手、価格感、強みと弱みを表でまとめてください。 」としました。 先ほどと同じく完成したレポートは、Genspark の Sparkpage の機能を利用して、Web公開しました（加筆/修正なし） Dropbox、Box、OneDrive、Google Drive 比較分析 https://uhbbflrd.gensparkspace.com/ 次は、プロンプトで意図した内容のレポートが作成されました。さらにプロンプトを調整することも可能です。 また、作成されたWebサイトを元にして、Genspark の AIスライドでPPT資料を作成したり、AIドキュメントでWord資料を作成することも可能です。 まとめ 簡単ですが、Genspark の Deep Research（ディープリサーチ、深層研究）について紹介しました。 1つの事実を知りたいなら、通常Google検索やAIチャットボットにて「〇〇〇を教えて」「〇〇〇とは？」で十分 です。 用語の意味、事実の確認、今日のニュース、単発の疑問は、今まで通りの通常検索やAIチャットボット。 Deep Researchを利用するのは、複数の情報を比べて判断したい場合、説明資料や資料の材料を作る場合 になります。 今回のような「オンラインストレージ製品を3社比較して、機能と導入難易度と運用負荷を整理して」を始めとする、市場調査、技術動向調査、製品選定、競合比較、規制影響の整理、提案書の下調べなどは、Deep Researchとなります。 通常検索 Deep Research 概要 1つの事実を知りたい 例.用語の意味、事実の確認、今日のニュース、単発の疑問 複数の情報を比べて判断したい 例.市場調査、技術動向調査、製品選定、競合比較、規制影響整理、提案書の下調べ 深さ 比較的少ない情報を素早く返す 多数の情報源を読み込んで統合 手順 質問に対してそのまま答す 調査計画を立てて段階的に掘り下げる 時間 数秒 数分かけてレポート作成 出力 簡潔な回答 比較表や論点整理を含むレポート 企業の実際の業務を実施されている方は、Deep Research で非常に効率化が見込めると思います。
LifeKeeperの『困った』を『できた！』に変える！サポート事例から学ぶトラブルシューティング＆再発防止策 こんにちは、SCSKの前田です。 いつも TechHarmony をご覧いただきありがとうございます。 システム基盤の主戦場がオンプレミスからパブリッククラウドへと移り変わり、AWSやAzure上でHAクラスタを構築する機会がぐっと増えました。クラウドでのインフラ設計において、「いかにクラウドリソースを最適化し、コストや構築の手間を抑えるか」は常に重要なテーマです。 そのため、サーバーのNICを最小限に抑えたり、オンプレミスと同じ感覚で同一サブネット内にネットワークをまとめようとしたり、監視用のサーバー（Witness）の台数を節約しようと考えるケースがよく見られます。 しかし、HAクラスターソフトウェアであるLifeKeeperをクラウド（特にAzure環境）で構築する場合、この「オンプレミス感覚のネットワーク設計」や「コストを意識した構成」が、思わぬ構築の壁となって立ちはだかることがあります。仮想IP（VIP）が正常に機能しなかったり、スプリットブレイン対策の構成要件を満たせず、設計の手戻りが発生してしまうのです。 本連載企画「LifeKeeper の『困った』を『できた！』に変える！サポート事例から学ぶトラブルシューティング＆再発防止策」では、サポートセンターに蓄積された「生のトラブル事例」を元に、安定運用のための実践的な知恵を共有していきます。 1. はじめに 前回の「カテゴリ3 第1弾」では、AWS環境における自動復旧機能との競合や回避策について解説しました。 第2弾となる今回は、 Microsoft Azure（以下、Azure）環境 にフォーカスします。 Azure環境での構築・運用において、サポート窓口には「オンプレミスの感覚でIPアドレスやサブネットを設定したら通信ができない！」といったネットワーク周りのご相談や、「スプリットブレイン対策（Quorum）の最適な構成・ディスクの選び方が分からない」というお問い合わせを数多くいただきます。 今回は、Azure環境においてハマりやすい「ネットワーク設計（IP割り当て・内部ロードバランサー連携）」 の罠と、スプリットブレインを防ぎつつリソースを最適化するための 「Quorum/Witness設計」の正解について、実際のサポート事例を交えて紐解いていきましょう！ 💡 前回の記事（カテゴリ3 第1弾）はこちら！ ▶ 【クラウド環境特有の落とし穴 #1】良かれと思った自動復旧が仇に！？AWS環境（EC2/Route53/S3）でハマる構成と回避策 – TechHarmony 2. 今回の「困った！」事例①：IP・ネットワーク設計の落とし穴 ❓ 事象の概要（困った！） 「Azure上のWindowsサーバー2台でLifeKeeperを構築予定です。コストや構築の手間を省くため、仮想IPリソースとDataKeeperのミラーリングで利用するNICを『同一サブネット』に配置したいと考えています。ただ、仮想IP自体は別セグメントにする予定ですが、動作やサポート要件に影響はありますか？」 🔍 原因究明のプロセスと判明した根本原因 オンプレミスであれば、柔軟にルーティングやVLANを設定して対応できるケースもありますが、Azure環境ではネットワークの仕組みが異なります。サポートで仕様と要件を確認したところ、Azure環境特有の厳しいルールが判明しました。 Azure上で仮想IP（VIP）を機能させるためには、ロードバランサー（ILB：内部ロードバランサー等）を用いたネットワーク切り替えが前提となります。この仕組みを正常に動作させるため、LifeKeeperの要件として「保護するNICごとに異なるサブネットを割り当てること」が必須（同一サブネットでの構成は未サポート）となっているのです。 💡 具体的な解決策（できた！） Azure環境でネットワークを構成する際は、以下の対応を行うことで正常に構築・運用が可能です。 異なるサブネットの割り当て 仮想IPリソースで使用するNICと、DataKeeperのミラーリング等で使用するNICには、必ず 別々のサブネット を用意して割り当てます。 サブネットマスクは「/32」に設定 IPリソースを作成する際、クラウド特有のルーティング競合を避けるため、サブネットマスクは必ず 255.255.255.255 (/32) に設定します（これはクラウド環境共通の必須設定です）。 ロードバランサーの活用 VIPを機能させるためのILBを適切に構成し、LifeKeeperの可用性をさらに高めるために「LB Health Check リソース」の導入も検討しましょう。 ▼【図解】Azure環境におけるネットワーク構成のNG/OK例 3. 今回の「困った！」事例②：スプリットブレイン対策とQuorumの迷い ❓ 事象の概要（困った！） 「Azure環境でスプリットブレイン対策を行いたいのですが、StorageモードやMajorityモードなど選択肢が多く、どれを選べばいいか迷っています。Azureの共有ディスクは使えるのでしょうか？ また、複数クラスタがある場合、Witnessサーバーはクラスタごとに必要ですか？」 🔍 原因究明のプロセスと判明した根本原因 スプリットブレイン（ネットワーク分断により両ノードがアクティブになってしまう現象）の対策はクラスター運用の要ですが、クラウドでは共有ストレージの扱いやネットワーク構成がオンプレミスと異なるため、構成の選択に迷うお客様が多数いらっしゃいます。 サポートからの回答により、Azure環境における最適なアプローチが整理されました。 💡 具体的な解決策（できた！） お客様の要件や環境に合わせて、以下のいずれかの手法を選択するのがベストプラクティスです。 パターンA：共有ディスクを利用する場合 v9.6.2以降（Linux版の場合）、Azure共有ディスクを用いた「SCSI-3 Persistent Reservations」によるI/Oフェンシングがサポートされています。共有ストレージを利用できる構成であれば、これが推奨の対策の1つとなります。 パターンB：サーバー構成（Majorityモード）を採用する場合 クラスターノードとは別のサーバーを「Witness（監視）サーバー」として立てて多数決をとる手法です。Witnessサーバーは、クラスターノードと異なる可用性ゾーン（AZ）に配置することが推奨されます。 ★嬉しいポイント：複数のLifeKeeperクラスターが存在する場合、 1台のWitnessサーバーを複数クラスタで「共用（相乗り）」することが可能 です。これにより、構築コストと運用負荷を大幅に削減できます！ ▼【図解】複数クラスタでのWitnessサーバー共用（相乗り）イメージ クラスタごとに Witness サーバーを立てる必要なく、 1 台のWitnessサーバーで複数のシステムを監視してコストが削減出来るわね！ 4. 補足事例：DataKeeperのパフォーマンス設計（同期 vs 非同期）と潜むリスク Azureのようなクラウド環境（あるいは遠隔地へのDR構成）でDataKeeperを利用する際、避けて通れないのが「同期モード」と「非同期モード」の選択です。 ここでは、設計時に必ず議論になる「リージョン間の距離（ネットワーク遅延）」 と、 「障害発生時のリスク」の2つの観点から解説します。 1. 物理的な距離（レイテンシ）が性能に与える影響 DataKeeperの同期モードは、稼働系で書き込みが発生するたびに、ターゲット側へデータを送り、その「書き込み完了通知（ACK）」が戻ってくるまでアプリケーションの処理を一時待機させます。 同一リージョン内（可用性ゾーン：AZ間など）： 遅延が極めて小さいため、同期モードでも実用的なパフォーマンスが得られることが多いです。 リージョン間（東日本－西日本間など）： ネットワークの「物理的な距離」に応じて通信遅延（レイテンシ）が大きくなります。同期モードを選択した場合、この遅延がそのまま「アプリの書き込みレスポンス低下」として現れます。 設計のポイント： 東日本と西日本を跨ぐようなDR（災害対策）構成で同期モードを採用する場合は、「性能低下を許容してでもデータ保全を優先する」 という明確な合意が必要です。パフォーマンスを最優先とするなら、距離の影響を受けにくい 「非同期モード」が第一の選択肢となります。 2. 障害発生時のデータロスと自動フェイルオーバー 非同期モードを選択する際、もう一つ理解しておくべきなのが「障害時の挙動」と「計画的な切り替え時の挙動」の違いです。 同期モード： 常に両ノードのデータが一致しているため、障害時もデータロスが発生せず、 最高レベルのデータ品質 を保てます。 非同期モード： 稼働系の書き込みを優先し、同期はバックグラウンドで行います。 ⚠️ 【重要】非同期モードの落とし穴： 稼働系が突然ダウンした場合、待機系への 自動フェイルオーバー自体は正常に実行 されますが、まだ転送されていなかった「未同期のデータ（キュー）」は、フェイルオーバー時に すべて破棄（データロス）されます。これにより、復旧後にデータ不整合が生じるリスクがある点に注意が必要です。 💡 【補足】計画的な切り替えは安全： メンテナンス等で「手動でのスイッチオーバー」を行う場合は、LifeKeeperが未同期のデータをすべて送り終えてから切り替える 動作をします。そのため、非同期モードであっても手動切り替えであればデータロスや不整合は発生しません。 【結論：どう選ぶべきか？】 Azure環境における判断基準は以下のようになります。 項目 同期モード（推奨：同一リージョン/AZ間） 非同期モード（推奨：リージョン間/DR構成） 重視する点 データ品質・完全一致（ロスなし） アプリケーションの処理速度（レスポンス） 距離の影響 距離（東日本-西日本など）があると遅延する 距離に関わらず書き込み速度に影響しない 障害時の自動切り換え (フェイルオーバー) ロスなし・不整合なし 直前のデータ破棄・不整合のリスクあり 計画時の手動切り替え (スイッチオーバー) ロスなし・不整合なし ロスなし・不整合なし（同期完了を待つため） 💡 さらに深掘り！：非同期モードで「データ不整合」はどこまで起きる？ 「非同期モードでデータが破棄されると、ファイルが壊れてOSやDB（Oracle等）が起動しなくなるのでは？」と不安に思う方もいるかもしれません。しかし、DataKeeperにはそのリスクを最小限に抑える**「書き込み順序の整合性（Write Order Fidelity）」**という重要な仕組みがあります。 書き込み順序の保証： DataKeeperはブロック単位で同期を行いますが、ソース側で書き込まれた順序を厳密に守ってターゲット側へ転送します。そのため、「新しいブロックだけが先に届き、古いブロックが欠落する」といった不自然な状態は発生しません。 「停電直後」と同じ状態（クラッシュ一貫性）： 障害発生時のターゲット側のディスクは、理論上**「ソース側のサーバーがある一瞬の時点で突然停電した際のディスク状態」**と等価です。 復旧のメカニズム： 最新の数ブロックが失われたとしても、ディスク全体としては「過去のある時点」の整合性が保たれています。そのため、フェイルオーバー後のOS（NTFS/ReFS等）やデータベース（Oracle等）は、自身の標準的なリカバリ機能（ログのロールバック等）を使って、不整合を解消し正常に起動することが可能な設計となっています。 【結論】 非同期モードは「直前のデータ（数秒分など）」を失う可能性はありますが、 「システムが二度と立ち上がらなくなるようなファイル破損」を防ぐための高度な転送制御 が行われています。パフォーマンスを優先しつつ、実用的な可用性を確保できるのが、DataKeeperが選ばれる理由の一つです。 5. 「再発させない！」ためのチェックリスト＆ベストプラクティス これまでの事例を踏まえ、Azure環境での構築前・設定時に確認していただきたいチェックリストを作成しました。ぜひ日々の運用や新規構築時にお役立てください！ ✅ 再発防止策（Azure構築前・設定時のチェックリスト） 【ネットワーク・IP設計】 仮想IPリソースに割り当てるサブネットマスクは 255.255.255.255 (/32) に設定しているか？ 各サーバーのNIC（IPリソース用とミラーリング用など）には、それぞれ 異なるサブネット を割り当てているか？（※同一サブネットは未サポート） 仮想IPを機能させるためのロードバランサー（ILB等）は適切に設計されているか？ LB Health Checkリソースの導入を検討し、フェイルオーバーの確実性を高めているか？ 【Quorum・データ保護設計】 スプリットブレイン対策として、自社環境に合ったフェンシング手法（SCSI-3 PR、Majorityモード等）を正しく選定できているか？ Majorityモードの場合、Witnessサーバーはクラスタノードと異なる可用性ゾーン（AZ）に配置するよう設計しているか？ DataKeeperの同期モードは要件に合っているか？（LAN環境/データ品質重視＝「同期」、WAN環境/レスポンス重視＝「非同期」） 💡 ベストプラクティス Azure特有の設定マニュアルを必ず参照する Azure環境はオンプレミスや他のクラウドと動作原理が異なる部分があります。構築時は公式マニュアルの「Azure 特有の設定について」を必ずご一読いただき、OS（Windows/Linux）ごとの差異も確認してください。 Witnessサーバーの効率的な活用 複数クラスタを運用する場合、MajorityモードのWitnessサーバーは1台で共用可能です。無駄なリソースを省き、コストの最適化を図りましょう。 ログの監視ポイントを把握する フェイルオーバーの成否やスプリットブレイン対策の挙動は、Linuxであれば /var/log/lifekeeper.log に記録されます。運用監視ツール等と連携し、このログを適切に監視する仕組みを整えることが安定稼働への近道です。 6. まとめ いかがでしたでしょうか。Azure環境でLifeKeeperを安定稼働させるためには、クラウド特有のネットワーク仕様（ILB連携やサブネット要件）と、ストレージ仕様（スプリットブレイン対策）を正しく理解することが成功の鍵となります。 「オンプレと同じで大丈夫だろう」と思い込まず、事前に公式ドキュメントや本記事のチェックリストを活用して、落とし穴を回避してくださいね！日々の運用でここを意識すれば、不要なトラブルは確実に防げます。 7. 次回予告 次回の連載テーマは「カテゴリ4：DataKeeperの落とし穴：データ保護とパフォーマンスのバランス」です。 DataKeeperのミラー同期トラブルや、性能ボトルネックと障害時動作の確認ポイントについて、実際のサポート事例からディープに解説します。お楽しみに！ 📚 本連載のバックナンバー 過去のトラブル事例と解決策もぜひあわせてご覧ください！ カテゴリ1：リソース起動・フェイルオーバー失敗の深層 ▶ 【リソース起動・フェイルオーバー失敗の深層 #1】EC2リソースが起動しない！クラウド連携の盲点とデバッグ術 – TechHarmony ▶ 【リソース起動・フェイルオーバー失敗の深層 #2】ファイルシステムの思わぬ落とし穴：エラーコードから原因を読み解く – TechHarmony ▶ 【リソース起動・フェイルオーバー失敗の深層 #3】設定ミス・通信障害・バージョン違いの深層と再発防止策 – TechHarmony カテゴリ2：OS・LKバージョンアップで泣かないために ▶ 【OS・LKバージョンアップで泣かないために #1】OSバージョンは変えていないのに！？カーネル更新の「落とし穴」と互換性の真実 – TechHarmony ▶ 【OS・LKバージョンアップで泣かないために #2】「設定が消えた！？」「亡霊IPが警告！？」を防ぐロードマップ：単純な上書き更新に潜む落とし穴と回避策 – TechHarmony カテゴリ3：クラウド環境特有の落とし穴 ▶ 【クラウド環境特有の落とし穴 #1】良かれと思った自動復旧が仇に！？AWS環境（EC2/Route53/S3）でハマる構成と回避策 – TechHarmony ▶ 【クラウド環境特有の落とし穴 #2】オンプレ感覚の「同一サブネット」はNG!?Azure環境のネットワーク要件とQuorum設計の最適解 詳しい内容をお知りになりたいかたは、以下のバナーからSCSK LifeKeeper公式サイトまで
こんにちは！SCSKの木下です。 今年も、 4月24日 に Zabbix Japan 主催「Zabbix 全国セミナー in 東京 2026」 が開催されます！ 本イベントは、 「ZabbixプロフェッショナルによるZabbixの可能性を広げる最新活用術」をテーマに Zabbixをこれから使ってみたい方 すでにZabbixを使っているが、運用に課題を感じている方 バージョンアップや設計の見直しを検討中の方 など、Zabbixに関わるすべての方に向けたオンサイト限定セミナーです。 Zabbix JapanおよびZabbixパートナー各社が一堂に会し、 講演 および 展示 を通じて 最新情報から実用的なノウハウまで ご紹介します！ 開催概要 開催日： 2026年4月24日（金）13:00〜18:00 会場： ビジョンセンター新宿マインズタワー （新宿駅南口より徒歩5分） オンサイト開催のため、各社ブースで直接質問・相談も可能です。 SCSK の講演内容について SCSKからは、 「SCSKのZabbix技術ブログとZabbix構築パッケージのご紹介」 と題し、 多くのエンジニアに読まれている SCSK 技術ブログ（TechHarmony） の中から、 特に反響の大きかったZabbix関連記事 初期構築から運用までを支援する 「Quick Start Package for Zabbix」 を活用した効率的な導入・運用手法 について、わかりやすくご紹介します。 「これからZabbixを始める方」 「 Zabbixをより使いこなしたいと考えている方 」 どちらの方にも参考になる内容です！ 展示ブースも充実 セミナー中、 展示ブースを設置しています。 自社の環境について具体的に相談したい！ 講演内容についてもっと詳しく知りたい！ といった方は、 ぜひお気軽にお立ち寄りください！ お申し込みについて 参加には 事前申込が必要 です。 ご興味のある方はぜひお早めにお申し込みください！ 👉 Zabbix セミナー in 東京 2026 参加申込はこちら！ 最後に Zabbixを「これから使う方」にも、「すでに活用している方」にも、 新しい気づきを持ち帰っていただけるセミナー です。 みなさまと会場でお会いできることを、SCSK一同楽しみにしております！
こんにちは。SCSK株式会社の上田です。 Zabbixに関する、 深刻な脆弱性（CVE-2026-23921） が発表されました。 この脆弱性は、 Zabbixのバージョン7.0.21、7.2.14、7.4.5までのバージョン に影響します。 Zabbixをご利用の方は一度ご覧いただき、対象の場合はアップデート等のご検討お願い致します。 脆弱性情報 概要 ZabbixのAPI機能（include/classes/api/CApiService.php）において、ブラインドSQLインジェクションが可能となる脆弱性（CVSS v4.0 スコア：8.7 / High）が存在します。 APIアクセス権限を持つ低権限ユーザーから悪意のある文字列が入力されることにより、データベース情報を抜き出され、最終的に セッション識別子の漏えいや管理者アカウントの乗っ取りにつながる恐れ があります。 対象コンポーネント API 対象バージョン 以下の Zabbix バージョンが影響を受けます。 Zabbix 7.0.0 – 7.0.21 Zabbix 7.2.0 – 7.2.14 Zabbix 7.4.0 – 7.4.5 影響 APIアクセスが可能な低権限ユーザーが、データベース内の任意のデータを抽出できる可能性があります。 セッション識別子の漏えいや管理者アカウントの乗っ取りにつながる恐れ があります。 回避方法 この脆弱性を回避するためには、Zabbixの最新バージョン（修正済みバージョン）にアップデートすることが推奨されます。 Zabbix 7.0.22以降 Zabbix 7.2.15以降 Zabbix 7.4.6以降 最後に 弊社では Zabbixのバージョンアップの支援 も行っております。 ご興味のある方は、是非弊社までお問合せください。 その他ご相談事項がございましたら、以下ページよりお問い合わせいただければと思います。 お問い合わせ 製品・サービスについて 入力 ｜ SCSK株式会社 SCSK株式会社 製品・サービスについてご意見・ご質問をお受けしております。 www.scsk.jp 最後まで読んでいただき、ありがとうございました。 弊社では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
SCSKの伊吹です。 以前ServiceNowの変更管理の違いについて触れました。 ServiceNowの変更管理の違い – TechHarmony 今回は変更管理のレコードの作成をどこから行うかについて触れたいと思います。 基本的な作成方法 一番基本的な手順はアプリケーションメニューからの作成になります。 1.アプリケーションメニューの「変更管理」＞「新規作成」を選択します。 2.作成したい変更管理のレコードに合わせて、ステータスモデルを選択します。 他プロセスからの作成方法 前段では基本的な作成方法を記載しましたが、必ず変更管理のメニューから起票しないといけないのでしょうか？ いいえ、そんなことはありません。 例えばヘルプデスクの担当者がお客様からのインシデント対応中に変更管理レコードを起票する場面があります。 または問題管理の担当者が問題解決の手段として変更管理を利用する場面があります。 そういった場合を想定して、ServiceNowはOOTBの状態でインシデント管理や問題管理から変更管理レコードを起票するための仕組みを持たせています。 インシデントレコード/問題レコードの三本線をクリックして表示されるメニューの中には、下図のような変更管理レコードの作成メニューが用意されています。 次はインシデントレコードの関連レコードタブの中に「変更要求」欄から起票するパターンです。 虫眼鏡マークをクリックして表示される画面の上部に「新規」ボタンがあり、ここをクリックすることでも変更管理レコードを作成できます。 他にも問題レコードの関連リストにある「変更要求」タブ内に「新規」ボタンがあり、ここをクリックすることでも変更管理レコードを作成できます。 これらの機能を利用することでインシデントレコードや問題レコードから直接変更管理レコードを起票することができます。 更に変更管理のメニューから作成した場合とは異なり、変更管理レコードを作成した時点で、作成元になったインシデントレコードや問題レコードとの紐づける完了しております。（下図は問題レコードから作成した場合の例です。） まとめ 今回は基本的な変更管理のメニューからの作成方法に加えて、インシデント/問題のレコードから変更管理レコードを起票する方法をご紹介しました。 今回はご紹介できませんでしたが他の管理プロセスから起票したり、フローに変更管理レコードを作成するアクションを組み込んだりすることもできます。 これらを利用することで、プロセスを跨いで変更管理レコードをより簡単に作成することができます。
昨今、業務で利用するクラウドサービス（SaaS）が増加するにつれて、「過去類を見ないほど業務ファイルが分断され、ファイルを見つけることがますます困難になっている」といった課題を感じていませんか？ 「ファイルはDropboxにあるはずだけど、メールやチャットでやり取りしたかも…」「どのツールで届いたか覚えていない」と、1つ1つのツールを開いて探すのは非常に非効率です。 そんな課題を解決するのが、AIを活用した新しいユニバーサル検索＆ガバナンスツール「Dropbox Dash for Business」です。本日は、このツールの魅力と主な機能をご紹介します。 Dropbox Dash for Business とは？ Dropbox Dashは、単なる検索ツールではありません。AIを活用した「検索」「整理」「コンテンツコントロール」を組み合わせることで、企業データを一元管理し、時間の節約と効率の向上を実現するソリューションです。 大きく分けて「探す（ユニバーサル検索）」「要約・回答（AIチャット）」「保護とコントロール」の3つの強力な機能を提供します。 1. すべてを探せる「ユニバーサル検索」 Dropbox Dashの最大の特徴は、サービスを横断した検索機能です。 Dropboxだけでなく、Google Drive、Microsoft OneDrive / SharePoint / Teamsなど、複数のクラウドサービスに散らばった情報から、探しているものをすばやく見つけ出します。 それぞれのサービスで個別に検索する手間が省け、本当に必要な仕事に集中できるようになります。 2. コンテンツの理解を深める「AIチャット・要約」 AIチャット機能を使えば、ファイルの検索だけでなく、その内容の理解も一瞬です。 以下のような業務ニーズに対応可能です。 仕様書の検索: 数百ページに及ぶような複雑な工事共通仕様書などを読み込ませ、チャット形式で質問して必要な情報を引き出す。 要約と回答生成: 検索した複数ファイルの要点をすぐに要約し、質問に対する回答や関連コンテンツへのリンクを自動生成する。 提案書やVE案の作成: 既存の提案書や工事ノウハウをAIに学習させ、効率よく新たな提案を作成する。 3. 情報システム部門必見！「保護とコントロール」 複数のアプリを利用していると、「組織外への共有やゲスト招待が簡単にできる分、機密情報が漏洩しないか心配」「共有状況を包括的に確認するのが煩雑」といったセキュリティ上の悩みがつきものです。 Dropbox Dashはビジネス利用に耐えうる高度な管理機能（コンテンツ・ガバナンス・ツール）を備えています。 権限の見える化: 複数のクラウドファイルに対するアクセス権限を、1つのUIで表示・フィルタリングできます。 迅速な修正アクション: 不必要な共有を見つけた場合、その画面からすぐに「公開リンクの削除」「共同編集者の削除」「共有の停止」といったアクションを実行可能です。 【想定される活用ユースケース】 退職者によるデータ持ち出し防止: 不審な共有を即時発見し、アカウント停止後もアクセスを強制的に無効化。 JV（共同企業体）プロジェクト終了後の対応: プロジェクト終了後も残存しがちな外部ユーザーのアクセスを一括表示し、まとめて削除することで機密データアクセスを遮断。 年次の共有状況監査: 長期間放置された不要な共有設定を特定し、効率的に解除。 まとめ Dropbox Dashは、「必要な情報への迅速なアクセス（AI検索）」と「共有リンクのセキュリティホール防止（ガバナンス）」を両立させる次世代のプラットフォームです。 情報のサイロ化やセキュリティ管理にお悩みのIT推進担当者様は、ぜひ検討してみてはいかがでしょうか。 Katsuyuki Fujinaka SCSK DropboxTeam Manager ご説明やデモのご依頼は下記のお問合せ先まで。 お問合せ： Dropbox-sale@scsk.jp SCSKのDropbox紹介サイト： https://www.scsk.jp/product/common/dropbox/index.html
「もし朝一番、PCを開くと身代金を要求する英文の壁紙に変わっていたら ……。」 想像してみてください。個人のPCだけでなく、全社員が共有しているファイルサーバーのデータまで一斉に暗号化され、業務が完全にストップしてしまう事態を。今、多くの企業が直面しているランサムウェアの脅威は、もはや「他人事」ではありません。 どれだけ強固なセキュリティソフトを導入しても、100%の防御は不可能です。だからこそ、今求められているBCP（事業継続計画）の肝は、「感染を防ぐこと」ではなく「感染した後に、いかに早く、確実に復旧するか」にあります。 本記事では、万が一の事態でも組織のデータを速やかに「感染前の状態」へ一括復旧できる、Dropboxの強力なバックアップ・リカバリ機能（巻き戻し機能）について解説します。 100%の防御は存在しない。今、必要なのは「出口戦略」としてのBCP 従来のセキュリティ対策は、ウイルスソフトやファイアウォールによる「入口対策」が中心でした。しかし、巧妙化するランサムウェア（身代金要求型ウイルス）の前では、どんなに高い壁を築いても突破されるリスクをゼロにはできません。 もし、自社のファイルサーバーが暗号化され、全業務がストップしたら？ バックアップからの復旧に数日、あるいは数週間を要する場合、その間の損失は計り知れません。 今、真のBCPに求められているのは、「感染を前提とした出口戦略」です。つまり、攻撃を受けたとしても、いかに迅速に、何事もなかったかのように業務を再開できるか。その答えが、Dropboxの「巻き戻し（Rewind）」機能にあります。 ランサムウェアの被害を自動検知 Dropboxのアラート機能 巻き戻しの前に、ランサムウェアの被害を最小限に抑えるためには素早く疑わしい動きを検知し、通報する仕組みが必要となります。 Dropboxにはアラート機能が用意されており、ランサムウェアの被害が疑われるケースや機密情報が含まれるコンテンツを外部と共有したり、データを一括移動、一括削除すると検知し、通報する仕組みが提供されています。 Dropboxのセキュリティアラート： https://help.dropbox.com/ja-jp/security/security-alerts セキュリティアラート機能により、素早く次のアクションを起こすことが可能です。 ※本機能はDropbox Advanced, Enterprise およびセキュリティアドオンを購入されたDropbox Standardのチームでご利用いただけます。 数クリックで「時計の針を戻す」。Dropbox Rewindの圧倒的復旧力 ランサムウェアの被害に遭った際、最も困難なのは「どのファイルが汚染され、どこまで遡れば安全か」を特定し、膨大なデータを書き戻す作業です。 Dropboxの「巻き戻し」機能は、この絶望的な作業を劇的にシンプルにします。 タイムライン形式の直感操作： ファイル変更の履歴をグラフで可視化。ランサムウェアによって大量のファイルが書き換えられた「被害を受け始めた時点」を一目で特定し、その直前の時刻を指定するだけです。 一括リカバリのスピード： フォルダ単位、あるいはアカウント全体を数クリックで一括復旧。従来のテープバックアップや外付けHDDのような物理的な差し替えや、専門業者によるリストア作業を待つ必要はありません。 「同期」ではなく「履歴」の保護： Dropboxの履歴データは、PC上のファイルとは別に、Dropbox上の安全な領域に保存されています。PC本体がロックされても、クラウド上の「過去の自分」は無傷のまま守られているのです。 日常の「うっかり」も大丈夫。バージョン履歴がもたらす現場の安心感 BCPはランサムウェア再作だけのものではありません。実は、企業が失うデータの多くは、ランサムウェアのような外敵よりも、日常の「人的ミス」によるものです。 「上書き保存」の悲劇をゼロに： 重要な資料を誤って編集し、そのまま保存してしまった。Dropboxなら、ファイルの右クリックメニューから過去のバージョンを即座に呼び出し、数秒で元に戻せます。 「間違えて削除」も恐くない： 共有フォルダで誰かがファイルを消してしまった場合も、ゴミ箱を探す手間なく履歴から復元可能。 情シス部門の負担軽減： これら全ての復旧作業を、現場の社員が自分で行えます。「ファイルを戻してほしい」という社内依頼が激減し、IT担当者はより付加価値の高い業務に集中できるようになります。 日常の小さなミスを救う機能が、そのまま「会社を救う最強の盾」になる。これがDropboxを導入する最大の経営的メリットです。 守ることは、攻めること。 ビジネスを止めない。それは、攻めの経営を支える最低限かつ最強の基盤です。 Dropboxを単なる「データの置き場所」から、「24時間365日、会社をランサムウェアの恐怖から解放するインフラ」へとアップデートしませんか？ より詳細な技術観点での説明を別ブログで紹介します。 ご説明やデモのご依頼は下記のお問合せ先まで。 お問合せ： Dropbox-sale@scsk.jp SCSKのDropbox紹介サイト： https://www.scsk.jp/product/common/dropbox/index.html
こんにちは。SCSK渡辺(大)です。 シティーハンターの実写映画が続編制作決定したらしく、来年の配信が楽しみです。 今回はPower Automate（以下、PA）に業務で触る機会があったので、その時にAIに色々と相談して知った小技について書いてみました。 長くなったフローを「スコープ」でスッキリまとめる 概要 複雑なフローを作ると、アクションの数が数十個になり、スクロールするだけで一苦労……という状態になりがちです。 そんな時に大活躍するのが「スコープ（Scope）」アクションです。 スコープを使えば、関連する複数のアクションを1つの箱（グループ）にまとめることができます。処理の塊ごとにスコープで囲んで名前を付けておけば、フロー全体の見通しが劇的に良くなり、後からのメンテナンス性も格段に向上します。 展開するとまとめられたアクションを確認することができます。 設定方法 「スコープ」というアクションを追加し、名前を変更します。 ドラッグ＆ドロップでまとめたいアクションを移動します。 非常に便利なスコープですが、1つだけ絶対に覚えておくべきルールがあります。 それは、 「変数の初期化（Initialize variable）」アクションはスコープの中に入れられない ということです。 変数の初期化は、必ずフローのトップレベル（一番外側）の階層で行う必要があります。変数の定義だけは最初にまとめて行い、その後の具体的な処理（変数の設定や追加など）をスコープ内で整理するようにしましょう。 土日・祝日を除外して「営業日」をカウントする 概要 「申請日から3営業日後を期限にしたい」といった要件は実務フローにおいて頻出しますが、標準の addDays 関数では土日や祝日もそのままカウントされてしまいます。 これをPAで正確に計算するための小技が「Outlookのイベント取得」と「ループ処理」の組み合わせです。 設定方法 計算中の日付を今日で初期化 varTargetDateは後述の「今の日付に＋1日するための前処理」の中で使用する変数です。 本題とズレるため式の説明は書略しますが、このアクションより前で取得したMicrosoft Formsの回答日付を”今日”として変数を初期化している、というだけです。 日付カウントを0で初期化 varCountは後述の「ループ処理（1日進めて平日か判定する処理）」の中で使用する変数です。 祝日含めたカレンダーを取得 まずはOffice 365 Outlookコネクタの「イベントの取得」アクションを使い、祝日や会社の休日が登録された「予定表」から休日予定を配列として取得します。 ここで言う「予定表」とはPAと接続しているユーザーのOutlook予定表の事です。 この時、詳細パラメーターの「フィルタークエリ」に以下を入力します。 この式は、一言でいうと「予定の開始日が、今日以降のものだけを取得してください」という命令文です。 Start/DateTime ge 'formatDateTime(utcNow(), 'yyyy-MM-dd')' 式を分解してみましょう。 Start/DateTime ⇒これは、Outlookカレンダーの「予定の開始日時」という項目（列）を指しています。 ge ⇒これは算数でいうところの 「≧（以上）」 を意味する記号です。 英語の「greater than or equal to」の頭文字を取っています。 ‘formatDateTime(utcNow(), ‘yyyy-MM-dd’)’ ⇒ここはPAの関数（数式）です。 utcNow() ⇒今の現在時刻を取得する formatDateTime( ～ , ‘yyyy-MM-dd’) ⇒その時刻を「年-月-日」という文字の形に整えます。つまり、「今日の日付」を作り出しています。 全て繋げると、 「予定の開始日時（Start/DateTime）」が、「今日の日付」と「同じか、それより未来（ge）」のデータを取得する ための式になります。 なぜこのフィルター式が重要なのか？ もし式を空欄にすると、PAは「過去数年分の終わった予定」まで全て読み込もうとします。その結果、 フローの処理遅延や、データ取得上限によるエラー（計算の狂い）の原因 になります。 この1行を追加するだけで、 「今日以降の必要な予定だけ」をピンポイントで取得 できます。 アウトプットのイメージは以下です。 [ { "Subject": "部内定例会議", "Start": "2024-05-01T10:00:00.0000000", "Location": "第1会議室", "IsAllDay": false }, { "Subject": "憲法記念日", "Start": "2024-05-03T00:00:00.0000000", "Location": "日本", "IsAllDay": true }, { "Subject": "みどりの日", "Start": "2024-05-04T00:00:00.0000000", "Location": "日本", "IsAllDay": true } ] 日本の祝日を取得 先ほどOutlookから取得した予定表の中には、自分で入れた別の予定や、他の国の祝日などが混ざっている可能性があります。 そこで、「アレイのフィルター処理」アクションを使って、純粋な「日本の祝日」だけを抽出（絞り込み）します。 Outlookの標準の祝日カレンダーは、予定の「場所（location）」という項目に「日本」という文字がセットされています。 このルールを利用して、「場所が『日本』となっている予定だけを残してください」というフィルターをかけています。 このひと手間を挟むことで、自分独自の予定や海外の祝日を誤って営業日カウントから除外してしまう事故を防ぎ、正確な「日本の営業日カレンダー」を作ることができます。 アウトプットのイメージは以下です。 [ { "Subject": "憲法記念日", "Start": "2024-05-03T00:00:00.0000000", "Location": "日本", "IsAllDay": true }, { "Subject": "みどりの日", "Start": "2024-05-04T00:00:00.0000000", "Location": "日本", "IsAllDay": true } ] 祝日リストの作成 前のステップで抽出した「日本の祝日」データには、件名や場所、時間など、さまざまな情報が混在しています。 このままだと、後の処理で「明日が祝日かどうか？」を判定（比較）するのが非常に難しくなります。 そこで、「選択」アクションを使って、複雑なデータから「日付の文字列（yyyy-MM-dd）」だけを抜き出した、シンプルなリストに変換します。 formatDateTime(item()?['Start'], 'yyyy-MM-dd') 式を分解してみましょう。 item()?[‘Start’] ⇒ループ処理で取り出している一つ一つの祝日データの中から、「開始日時（Start）」だけを抜き取ります。 formatDateTime( ～ , ‘yyyy-MM-dd’) ⇒抜き取った日時から「時間（00:00など）」を切り捨てて、「年-月-日」だけのスッキリした文字に整えます。 アウトプットのイメージは以下です。 [ "2024-05-03", "2024-05-04" ] ループ処理（1日進めて平日か判定する処理） 「Do until」は、指定した条件を満たすまで、中のアクション（1日進めて平日か判定する処理）をぐるぐると繰り返し実行するアクションです。 この「ループ停止条件」を正しく設定しないと、無限ループに陥ってしまいます。 int(variables(‘varCount’)) ⇒カウントを貯めている変数 variables(‘varCount’) は、平日と判定された時だけ「+1」されていく変数です。 int(30) ⇒目標とする営業日数 今回は例として「30（営業日）」を設定しています。（3営業日なら int(3) とします） つまり、真ん中を「以上」にしているので、「平日カウントが目標の日数（30）に到達するか、それを超えたら、このループを終了してください」という命令になります。 件数は「最大○○回ループしたら、条件を満たしていなくても強制的にループを終了する」という設定です。 30営業日先を探すために、念のためカレンダーを最大60日分（約2ヶ月分）まで調べる、という安全なリミッター（無限ループ防止策）になっています。 タイムアウトのPT1H 「処理が1時間（1 Hour）経っても終わらなければ強制終了する」という設定です。 今の日付に＋1日するための前処理 ループの中に入ったら、まずは「今チェックしている日付」を1日未来へ進める必要があります。 そこで、「作成」アクション（アクション名：今の日付に+1日するための前処理）を使って、日付を+1する計算を行います。 addDays(variables('varTargetDate'), 1) 式を分解してみましょう。 variables(‘varTargetDate’) ⇒「現在計算の対象となっている日付」が入っている変数です。（ループが始まる前は「今日」の日付が入っています） addDays( 対象の日付 , 追加する日数 ) ⇒PAで日付を足し算・引き算するための専用関数です。今回は 1 を指定しているので、「対象の日付に1日足してください」という計算になります。 つまり、この式を実行することで「対象の日付の『明日』の日付」が作り出されます。 アウトプットのイメージは以下です。 ループ1回目 ⇒計算前の変数（varTargetDate）： “2026-03-01” このアクションの出力結果： “2026-03-02T00:00:00.0000000Z” （←3月2日に進む） ループ2回目 ⇒計算前の変数（varTargetDate）： “2026-03-02” このアクションの出力結果： “2026-03-03T00:00:00.0000000Z” （←3月3日に進む） ループ3回目 ⇒計算前の変数（varTargetDate）： “2026-03-03” このアクションの出力結果： “2026-03-04T00:00:00.0000000Z” （←3月4日に進む） 今の日付に＋1日する 前のステップ（前処理の作成アクション）で「現在の日付に+1日した日付（明日の日付）」を一時的に計算しました。 しかし、計算しただけでは変数のデータは古いままなので、ここで「変数の設定」アクションを使って、新しい日付に上書き（アップデート）します。 アウトプットのイメージは以下です。 【ループ開始前】 （初期値）： “2026-03-01” 【ループ1回目】通過後： “2026-03-02T00:00:00.0000000Z” （←3月2日に上書きされた） 【ループ2回目】通過後： “2026-03-03T00:00:00.0000000Z” （←3月3日に上書きされた） 【ループ3回目】通過後： “2026-03-04T00:00:00.0000000Z” （←3月4日に上書きされた） 「平日ならカウントを進める（True）」、「休みなら何もしない（False）」 カレンダーを1日進めたら、次はその日が「カウントすべき平日」なのか、「スキップすべき休み（土日・祝日）」なのかを判定しなければなりません。 ここで使うのが「条件（Condition）」アクションです。 画像の設定を見ると、左側の入力欄に長い数式が入り、それが true（真）と等しいかどうかを判定しています。 この長い数式は、一言でいうと「この日は『休み』ではないですよね？」とシステムに問いかけるための数式です。 not(or(equals(dayOfWeek(variables('varTargetDate')), 0), equals(dayOfWeek(variables('varTargetDate')), 6), contains(body('祝日リストの作成'), formatDateTime(variables('varTargetDate'), 'yyyy-MM-dd')))) 式を分解してみましょう。 dayOfWeek(variables(‘varTargetDate’)) ⇒先ほど1日進めた対象の日付（varTargetDate）から、曜日を「数字」で出してくれる関数です（0＝日曜、1＝月曜… 6＝土曜）。 equals(…, 0) / equals(…, 6) ⇒先ほどの曜日の数字が「0（日曜日）」と等しいか？、「6（土曜日）」と等しいか？という判定です。 contains(body(‘祝日リストの作成’), formatDateTime(variables(‘varTargetDate’), ‘yyyy-MM-dd’)) ⇒これは、「祝日リストの作成」で作っておいたシンプルな祝日リスト（body(‘祝日リストの作成’)）の中に、今チェックしている日付（varTargetDate を yyyy-MM-dd に整形したもの）が「含まれていますか（＝祝日ですか）？」という判定です。 or(式1, 式2, 式3) ⇒ or 関数は、カッコの中の条件のうち「どれか1つでも当てはまればTrue」を返します。つまり、上の3つの条件をまとめて「日曜日・土曜日・祝日のいずれか（＝休みである）」という判定のカタマリを作っています。 not(…) ⇒ not 関数は、結果を「逆」にする関数です。先ほどの or で作った「休みである」という判定結果を逆転させ、最終的に「休みではない（＝平日である）」という判定にひっくり返しています。 判定のイメージは以下です。 対象日が「2026年3月3日（火）」の場合 ⇒日曜・土曜か？： 火曜日（2）なので「違う」 ⇒祝日か？： リストに無いので「違う」 ⇒数式の最終結果： 「休み」ではない ＝ true（真） ⇒アウトプット（進む道）： 同様に条件を満たすため、緑色の「True（はい）」ルートに進みます。 ⇒営業日カウント（varCount）がさらに「+1」され、順調に日数が加算されていきます。 対象日が「2026年3月20日（金・春分の日）」の場合 ⇒日曜・土曜か？： 金曜日（5）なので「違う」 ⇒祝日か？： リストに含まれているので「合っている（祝日だ）」 ⇒数式の最終結果： 祝日なので「休み」である ＝ false（偽） ⇒アウトプット（進む道）： 条件が true と等しくないため、赤色の「False（いいえ）」ルートに弾かれます。 ⇒この中にはアクションが0件なので、カウントは増やさずにスルーして次の日へループが回ります。 まとめ GUIでフローを作成できるため初心者にも優しいですね。 その一方で、複雑な処理を実装するのは時間が掛かると感じました。 AIの更なる発展によってPAが今後どのように変わっていくのか気になります。 https://blog.usize-tech.com/power-automate-freeplan/
こんにちは、SCSKの松岡です🚩 SCSKが提供しているクラウドデータ活用サービスでは、データドリブン経営実現のためのステップを、「活用基盤」「可視化・分析」「連携・蓄積」「マネジメント」「高度活用」の5つに定義しています。 各ステップを実現するためのポイントと、さらにそれらを支えるモダンデータスタックの設計についてご紹介します！ データドリブン経営のための5つのステップ AWS データ活用｜サービス｜企業のDX戦略を加速するハイブリッドクラウドソリューション SCSKで提供しているクラウドデータ活用サービスでは、お客様のデータ活用状況に応じて段階的にご支援しています。 STEP01 データ活用基盤 データドリブン経営を実現するためには、まずデータを蓄積・活用するための基盤が必要です。 特に近年では、AI活用の文脈においてもデータ基盤の重要性が増しています。企業独自のデータをどのように収集・蓄積し、どのように活用していくかという観点において、データ活用基盤はすべての出発点となります。 前提として整理しておきたいのが、「データレイク」と「データマート」の役割分担です。 生のデータをそのままの形で保管する「データレイク」と、特定の分析目的に合わせて加工・最適化された「データマート」を適切に切り分けることで、データの鮮度と分析のスピードを両立させることができます。 最初の基盤は「完璧に作る」のではなく、「素早く使える状態にする」ことが重要です。 初期段階で時間をかけすぎると、データ活用の本来の目的である「価値創出」までたどり着けないケースが多く見られます。そのため、テンプレートや既存の構成を活用し、スモールスタートで基盤を構築することが有効です。 また、基盤構築においてはコストと運用負荷も重要な観点です。 基盤の利用コストと運用負荷は初期段階から考慮し、長期的に持続可能な構成を選択することが重要です。 Snowflakeは、データレイクからデータマートまでを一元管理できる高い柔軟性を備えています。 コスト最適化に優れており、運用負荷も少ないことから、管理の負担を抑えたい方に特に利用を推奨しています。 さらに、近年はデータレイク自体の進化も進んでいます。 従来のファイルベースのデータレイクではなく、Icebergのようなテーブルフォーマットを採用することで、検索性能や運用性を大きく向上させることが可能です。 Amazon S3 Tables を利用することで、データレイク(Iceberg)の構築・運用をマネージドに実現することができます。 【ここを気にした!】Amazon S3 Tablesで構築するデータ基盤 データ基盤の構築でIceberg (S3 Tables)を導入した際の試行錯誤を整理しました。 従来のS3によるファイル格納型のデータレイクと比較し、Icebergを採用することで得られたメリットや、それをマネージドで扱えるS3 Tablesの利便性について紹介します。 blog.usize-tech.com 2026.03.24 STEP02 データ可視化・分析 基盤が整った後、次に重要になるのがデータの可視化・分析です。 ここでよくある課題が、「何を見ればよいか分からない」という点です。 単にBIツールを導入するだけでは、データ活用は進みません。業務でどのような意思決定をしたいのか、そのためにどのデータが必要なのかを明確にする必要があります。 可視化・分析は「見たいもの」ではなく「意思決定のアクション」から逆算して設計することが重要です。 また、導入初期段階ではテンプレートの活用が非常に有効です。あらかじめ分析の「型」を用意することで、ユーザーが迷わずデータ活用を開始でき、早期に成功体験を積めるようになります。 さらに近年では、BIのあり方自体も変化しています。 Snowflake Intelligence のようなエンタープライズAIエージェントの登場により、ユーザーは複雑な操作をせずとも、自然言語でデータに問いかけ、必要なインサイトを得ることが可能になりつつあります。 Snowflake Intelligence あらゆる知識を集約 信頼のエンタープライズAIエージェントが応える Agentic AI-powered digital workspace – Amazon Quick – AWS Snowflake IntelligenceやAmazon Quickのように、ダッシュボードを自動生成したり、AIがデータの傾向を要約したりする仕組みが登場しており、可視化のハードルは劇的に下がりつつあります。 Snowflake Intelligence を始めるためのアカウント設定 Snowflake Intelligenceは、生成AIを利用して自然言語によるデータ検索や要約を可能にしてくれる機能です。利用開始するために必要なアカウント設定の手順を紹介します。 blog.usize-tech.com 2025.10.02 STEP03 データ連携 データ活用を拡張していく上で不可欠なのがデータ連携です。企業内には複数のシステムが存在し、それぞれにデータが分散しています。これらを統合し、分析可能な形に整える必要があります。 データドリブン経営を推進する上でも、社内の多種多様なデータ源とスムーズに連携できているかどうかが、意思決定の判断材料を増やすことにつながります。 また、AI活用を見据えた場合、社内の多様なデータ源と連携できているかどうかが、AIが回答できる領域の広さや精度に直結します。 内製化の難易度、開発者のスキルセット、および連携対象システムにコネクタが対応しているかを確認し、最適なサービスを選定することが重要です。 開発スキルや運用体制に応じて、GUIベースのノーコードツールと、柔軟性の高いコードベースの処理（AWS Glue Python Shellなど）を適切に使い分けることが求められます。 【ここを気にした!】AWS Glue Python Shellジョブによるデータ連携 データ連携の実装でAWS Glue (Python Shell Job)を導入した際の試行錯誤を整理しました。 RDSからデータレイクであるS3 Tablesに連携する際に、横展開可能な軽量なデータ連携ジョブを実現するために気にしたポイントについて紹介します。 blog.usize-tech.com 2026.03.30 システム間連携が発生する場合は、各システムの「データオーナー」との協力関係が不可欠です。 データの仕様理解や権限調整、さらには上流工程での変更が下流の分析基盤に与える影響（データ壊れ）を防ぐためにも、部門を越えた連携体制を構築しておく必要があります。 また、AI活用を見据えた場合、画像や音声、PDFといった「非構造化データ」の重要性も増しています。 Snowflakeでは非構造化データの取り扱いが強化されており、画像・テキストなどのデータもカタログ化し、分析・AI活用の対象として安全に取り込むことが可能です。 Cortex AISQLの紹介：SQLをマルチモーダルデータのためのAIクエリ言語に再構築 データ連携のハードルを下げる存在として、 Snowflake Cortex AI の活用が挙げられます。Cortex AIを利用することで、取り込んだ生のテキストや非構造化データに対して、複雑なパイプラインを組むことなくSQLのみで要約や分類、分析などを実行できます。 STEP04 データマネジメント データ活用が進むにつれて、データの管理（ガバナンス）が極めて重要になります。「データの所在が分からない」「権限管理が煩雑」といった課題は、活用が活発な現場ほど顕在化しやすいためです。 複数のソースシステムからデータが集約される中で、各データの定義や意味を管理する「データカタログ」の重要性は、組織の成熟とともに増していきます。 データカタログを導入し、組織全体でデータを可視化することで、データの内容について共通認識を持たせることが重要です。 【ここを気にした!】Amazon Redshiftで構築するBI向けデータマート 今回は、データの可視化・分析において、Amazon Redshiftを用いて事前集計アーキテクチャの見直しを行った際の試行錯誤を整理しました。 また、データマネジメントの観点で、Amazon Sagemaker (Amazon Datazone) を用いて改善できるポイントについてもご紹介します。 blog.usize-tech.com 2026.03.30 また、AWS環境においては、マルチアカウント構成での運用が一般的です。そのため、アカウントを跨いだデータ共有や統制も避けては通れないポイントとなります。 全社的なデータ活用の文脈においては、アカウント横断でデータカタログを一元管理できるか、そして組織間でのデータ共有をいかにセキュアかつ容易に行えるかが、データ活用をさらに加速させるための重要な要素になります。 SageMaker Catalogを活用すれば、アカウントを跨いでデータやAI資産を統合管理できます。 Amazon SageMaker Catalog ：データと AI を安全に発見、管理、共同作業 SageMaker Catalogであれば、中央のデータ基盤管理者に過度な負担をかけることなく、各部署間で直接「利用申請・承認」のワークフローを回すことが可能です。部署ごとの判断で迅速にデータを共有できる仕組みを整えることで、ガバナンスを効かせながらも、データの直接的な広まりを加速させることができます。 STEP05 高度データ活用 STEP 04までの「基盤・可視化・連携・管理」が整うことで、いよいよデータ活用の真髄である高度な分析・予測のフェーズへと進むことができます。 高度なデータ活用は、テクニック以上に「データの品質とアクセスのしやすさ」に依存します。 STEP 01〜04を確実に踏むことで、AIやMLのポテンシャルを100%引き出せる組織へと進化できます！ 【ここを気にした!】Amazon Bedrockを活用したWebクローリング＆名寄せ構想 Webクローリングおよび名寄せの検証において、AWS lambdaとAmazon Bedrockを活用したデータ収集アーキテクチャを検討した際の試行錯誤を整理しました。 従来のルールベースのクローリングと比較し、生成AIを用いた柔軟な情報抽出を取り入れることで、サイト構造の差異に耐えるデータ収集方式をどのように実現したか、また収集データと既存マスタを突合する名寄せの課題についても紹介します。 blog.usize-tech.com 2026.03.30 データ活用基盤の核となるモダンデータスタック 各STEPを乗り越え、データ活用基盤が完成した場合の例はこのようになります。 各構成要素でどのサービスを採用すべきかは、ビジネス要件や技術の進化に応じて変化していきます。 データ活用基盤を構成するサービスは、近年めまぐるしく進化しています。 先ほど記載したように、データレイクにおいては従来のS3に加え、S3 Tablesのようなパフォーマンスに特化した新しいサービスが登場しています。また、データ連携においても、ノーコードのETLツールからコードベースの統合サービスまで選択肢は増え続けており、組織のスキルセットに応じた柔軟な選択が可能になっています。 このように、状況の変化に合わせてサービスを変更したり、場合によっては使い分けたりすることを想定しておく方が良いです。 そこで重要になるのが、 モダンデータスタック の考え方です。 モダンデータスタックとは、単一の製品やサービスに依存するのではなく、各領域でベストなクラウドサービスやSaaSを組み合わせて、柔軟なデータ活用基盤を構成する設計思想です。 例えば、 データ蓄積：S3 / Snowflake データ連携：Glue / TROCCO 可視化：Quick / 各種BIツール データ管理：DataZone といったように、それぞれの役割に応じて最適なサービスを選択し、疎結合に組み合わせていきます。 モダンデータスタックで特定のサービスに依存しない「疎結合」な基盤にすることで、将来的な技術変化や新サービスにも柔軟に対応できる基盤を構築することが可能になります。 この考え方は、AI活用を前提とした AI-Readyなデータ基盤 においても非常に重要です。 AIは単体で価値を生むものではなく、その根拠となるデータの品質や量、そしてアクセスのしやすさに大きく依存します。AI活用を成功させるためには、前段となるデータ基盤・データ連携・データマネジメントといった各STEPが適切に設計されていることが不可欠です。 まとめ 本記事では、データドリブン経営を実現するための5つのステップと、それを支えるモダンデータスタックの設計思想について紹介しました。 データ活用基盤は最初から巨大なシステムを目指すのではなく、段階的に、かつ柔軟なアーキテクチャで構築することがポイントであると考えています。 変化の激しいAI時代にも迅速に対応できる、データ基盤の実現をこれからも目指していきたいです！
SCSKの畑です。 小ネタというか、Kiro そのものの話とは少し外れた話題なのですが、放っておくと大事になりかねない内容だったので備忘として残しておこうと思った次第です。 本エントリの前提 とある案件の PoC において、kiro-cli を使用して大量のファイルをバッチ処理するためのツールを Python で作成していました。内容の詳細は今回の内容に直接関連しないため触れませんが、対象のファイルから特定の情報を抽出する目的で使用しています。 他、ツールの作りは大まかに以下のようになっています。 コンテキストサイズの制約を考慮し、処理対象となるファイル単位でツールから kiro-cli を実行 大量のファイルを処理する場合は相応の時間がかかるため、ツールから kiro-cli をマルチスレッドで実行可能に 後述するようにサイズの大きいファイルを処理する場合は処理時間が想定以上に長くなってしまうことも起こり得るため、一定時間が経過した kiro-cli のプロセスはタイムアウト扱いとしてツール側から終了する 発生した事象 このツールを使用して PoC を進めていたのですが、ワンサイクルの処理で概ね 200-300 前後のクレジットを消費する重い処理（プロンプト）について、コンテキスト/クレジットの消費量を抑えるためにプロンプトやツール自体の見直しを実施していました。良く知られている通り、コンテキストサイズが上限近くに達してしまうと要約が走ってしまい目的の処理が無限ループしてしまったり、kiro-cli からの出力が途中で切れてしまうなどの弊害がある上、コンテキストの消費量を抑えることは消費クレジットの低減に直結するためです。 その試行錯誤をしている最中、現在のクレジット消費量がどれくらいかどうかを確認したくなったため、kiro-cli で /usage を叩いてみました。ツール側で kiro-cli の処理完了時に表示される消費クレジットを集計できるようにしており、概ね 2000 程度まで消費されていることは分かっていましたが、実際のクレジット消費量との突合せがしたいなと。 ところが、/usage に表示されたクレジットの消費量は、想定の 1.5 倍である約 3000 まで増加していました。しかも、継続的にクレジットの消費量を観察していたところ、少しずつゆっくりと値が増え続けているような状況でした。 さすがに血の気が引きつつも、これはマズいということで至急原因を調査する羽目になりました。 原因 そもそも何故消費量が 3000 に達したのかという点も疑問でしたが、まずクレジットの値が増え続けている状況を改善する必要がありました。クレジットの消費量は完全にリアルタイムで反映される訳ではなく、特にマルチスレッドで並列実行するようなケースだと反映が遅れるケースがあったので当初はその可能性を疑っていました。しかし数分程度経っても状況が変わらなかったため、この線はなさそうと判断しました。 次に Kiro のダッシュボードから手がかりとなる情報がないかを探したのですが、サブスクリプション利用状況の概観は確認できるものの、リアルタイムで利用状況を詳細に掘り下げる用途では使用できなさそうでした。機能的には S3 に出力するアクティビティレポートが唯一使えそうだったのですがその時点では有効化しておらず、このタイミングで有効化しても意味があるのかが分からなかったので一旦見送ることに。 この時点で最悪 AWS サポートに問い合わせるしかないかなとも考え始めていたのですが、ひょっとするとタイムアウトした kiro-cli のプロセスが残存しているのではないか？という可能性がふと頭に浮かびました。一連の試行錯誤において数回タイムアウトが発生していたのですが、そのプロセスが残存している可能性があるのではないかと考えたためです。そこで慌てて ps コマンドで kiro-cli プロセスの存在を確認したところ・・ 何と 2 つのプロセスが残存していました。いずれのプロセスも入力（プロンプト）の内容がタイムアウトした処理に合致していた上、しかもその内の 1 個は数時間前から稼働していることに気づきました！ ということで速攻でそれらのプロセスを kill したところ、ようやくクレジットの増加を止めることができました。 また、この時点で消費量が 3000 に達した原因は、残存していた kiro-cli プロセスが単純に少しずつクレジットを消費していたためではないかという推測もつきました。タイムアウトの回数と残存していたプロセスの個数は一致しませんでしたが、プロセスによってはある程度の時間稼働した結果正常に終了した可能性も考えられるため、それも考えると十分に辻褄の合う程度の消費量だったためです。 解決策 ツール側でタイムアウトとして検知したプロセスが正常に kill されていないという事象はツール側の責任であるため、ツール側を改修することで解決しました。 厳密に言うとタイムアウトしたプロセスを kill する仕組みは実装されていたのですが、その対象となっていたのは kiro-cli プロセスのみでした。 実際には、kiro-cli におけるチャットセッションは以下のように kiro-cli-chat という子プロセスとして起動されるようで、親プロセスの kiro-cli を kill するだけでは Linux(WSL) の仕様として子プロセスは kill されません。 今回残存していたのはいずれもこの子プロセスであり、それが断続的なクレジット消費に繋がっていたと考えられるため、タイムアウト時に親プロセスと合わせて確実に kill する必要があります。 ★kiro-cli-chatがkiro-cliの子プロセスとして稼働している $ ps -ef | grep kiro-cli | grep -v grep user 2322 644 0 17:52 pts/0 00:00:00 kiro-cli user 2330 2322 0 17:52 pts/0 00:00:00 /home/user/.local/bin/kiro-cli-chat chat ★親プロセスのkiro-cliをkill $ kill -9 2322 ★子プロセスのkiro-cli-chatは親プロセスをkillしても残存している $ ps -ef | grep kiro-cli| grep -v grep user 2330 643 0 17:52 pts/0 00:00:00 /home/user/.local/bin/kiro-cli-chat chat よって、以下のようにツール（Python）から kiro-cli を subprocess として起動する際、「preexec_fn=os.setsid」を指定することでプロセスグループを作成するように変更しました。この変更により、親プロセス（kiro-cli）とその子プロセス（kiro-cli-chat）の両方に対して SIGTERM や SIGKILL などのシグナルを送れるようになります。 process = subprocess.Popen( command, text=True, encoding='utf-8', preexec_fn=os.setsid, ) その上で、対象プロセスグループに対して kill 用のシグナルを送信するように、対象メソッドのロジックを修正しました。具体的な実装例は以下の通りです。 def kill_pt(process: subprocess.Popen) -> None: # プロセスグループにSIGTERMを送信 pid = process.pid pgid = os.getpgid(pid) try: os.killpg(pgid, signal.SIGTERM) except ProcessLookupError: return # SIGTERM送信後、プロセスグループのgraceful shutdownを待機 deadline = time.time() + 5 while time.time() < deadline: try: os.killpg(pgid, 0) # Null Signalを使用した生存確認 except ProcessLookupError: process.wait() return time.sleep(1) # SIGTERMで停止しなかった場合、プロセスグループにSIGKILLを送信して強制終了 try: os.killpg(pgid, signal.SIGKILL) except ProcessLookupError: process.wait() また、試行錯誤の最中に場合によっては該当処理がタイムアウトしそうと判断できた時点で Ctrl+C でツールを強制終了するようなこともしていたのですが、このタイミングでツール経由で起動していた kiro-cli を終了するような仕組みも不十分であったため、KeyboardInterrupt を kiro-cli プロセスの起動メソッドで catch して上記メソッドで kill するようにしています。（ひょっとすると主原因はこちらだったかもしれませんが・・） それとは別の話として、先述したような「コンテキスト逼迫による無限ループ」については Kiro 側で検知して欲しさもあります。。IDE での実行だと一定回数以上のイテレーションがあった場合は続けるかどうかの選択肢が最近出るようになりましたが、検知の仕組みがインタラクティブである場合バッチ実行すると結局そこでスタックしてしまうので、他の仕組みがないものでしょうかね。ひょっとするともう何かありそうな気もしますが・・ まとめ 実はトータルのクレジット消費量が 3000 に達する前に 1 回確認しており、その時にも同じようにクレジット消費量がゆっくりと増加するような事象は確認できていたのですが、原因のセクションに書いた通り一過性の事象だとスルーしてしまっていました・・ 思い込みは危険なので気になった時点でちゃんと原因を探りましょう。本当に。 Kiro の仕組みを活用するという観点だと、S3 に出力するアクティビティレポートを有効化する以外の方策はなさそうなので、こちらも別の機会に試したいです。このへん、他の生成 AI エージェントだとどのように監視できるのかとかも気になりますね・・ 本記事がどなたかの役に立てば幸いです。
こんにちは。SCSKの大原悠利です。現在、クラウド研修を終え、AWSを用いた基盤更改のプロジェクトに参画しております。 本記事では、プロジェクト中に理解に苦しんだ「 S3バージョニングとライフサイクルルールの削除 」についてご紹介します。 S3のバージョニング機能は、クロスリージョンレプリケーション（CRR）や MFA削除、オブジェクトロックを有効化する目的で利用している方も多いのではないでしょうか。 一方で、「S3 バージョニングが有効な状態でオブジェクトを削除すると、実際には何が起きているのか」については、意外と理解しづらい部分があります。 本記事では、 S3 バージョニング有効環境におけるオブジェクト削除の挙動 について解説します。 S3のバージョニングとは AWS 公式ドキュメントでは、S3 バージョニングについて以下のように説明されています。 「S3 バージョニングを使用すると、オブジェクトの複数のバージョンを 1 つのバケットに保持し、誤って削除または上書きされたオブジェクトを復元できます。」 https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/versioning-workflows.html つまり、S3バージョニングとは S3バケット内のオブジェクトに対して変更履歴を保持する機能 です。 この機能により、オブジェクトを誤って削除したり上書きしてしまった場合でも、過去の状態に戻すことが可能になります。 ここでは、バージョニングの有無によって、オブジェクトを上書きした際にどのような違いがあるのかを見ていきます。 バージョニング無効時の挙動 バージョニングが「 無効」 の場合、オブジェクトを上書きすると、上書き前のデータは完全に削除されます。 そのため、元のオブジェクトを復元することはできません。 バージョニング有効時の挙動 一方、バージョニングが「 有効」 な場合は挙動が異なります。 上書き前の現行バージョンは削除されるのではなく、 非現行バージョン として保持される 上書き後のオブジェクトが新たな現行バージョンになる このように、上書き操作を行っても過去のバージョンが保持されます。 上書き後のオブジェクトのIDを指定して削除することで(ID:102)、必要に応じて以前の状態に戻すことも可能です。 実際に、コンソールでは以下のように表示されます。 バージョニング無効 バージョニングが無効の場合、バージョンIDが「null」で表示され、一つのオブジェクトしか維持されません。 バージョニング有効 バージョニングが有効の場合、バージョンIDがランダムに表示されます。また、新しく上書きされても、現行バージョンが非現行バージョンとして維持されたため、複数のオブジェクトを保持することができます。 このように、S3 バージョニングを有効化することで、 誤操作による上書きからオブジェクトを保護 できます。 削除マーカーとバージョニング時の削除挙動 次に、本記事のメインテーマである、 S3バージョニング有効時のオブジェクトの「削除」 について詳しく解説します。 ここでの重要なポイントは、バージョニング有効時の削除は、通常の削除とは挙動が異なるという点です。この挙動を理解するうえで欠かせない、S3特有の概念が「 削除マーカー（Delete Marker） 」 です。 削除マーカーとは AWS公式ドキュメントでは、削除マーカーについて以下のように説明されています。 「Amazon S3 の削除マーカーは、単純な DELETEリクエストで指定された、バージョニングされたオブジェクトのプレースホルダー (またはマーカー) です。」 削除マーカーの使用 – Amazon Simple Storage Service ここでいう単純な DELETE リクエストとは、バージョン ID を指定しないリクエストです。 つまり、削除マーカーとは 「オブジェクトが削除されたことを示すための、実体を持たないバージョン」 という位置づけになります。 削除マーカーの特徴と注意点 削除マーカーには、以下のような特徴があります。 フラグ用のオブジェクト であり、GETリクエストで取得しようとしても中身は返ってこない 実体データは持たないが、 オブジェクト名分のメタデータ容量 が発生するため、最小オブジェクトコスト分の料金がかかる（STANDARD の場合：USD 0.025$） 明示的な削除やライフサイクルルールを設定しない限り、 自動では削除されない そのため、削除マーカーに気づかないまま放置すると、 少額ながら継続的にコストを支払い続けてしまう可能性 があります。 さらに、削除マーカーに気づかず、非現行バージョンのオブジェクトが残っている場合、その分のストレージコストも引き続き発生します。 このような理由から、AWS公式では 不要になった削除マーカーは自動で削除する運用 が推奨されています。 実際の削除挙動について それでは、バージョニングを有効化したオブジェクトを削除した場合の具体的な挙動についてコンソール上で確認しながら、説明します。 1. オブジェクトのバージョンを表示しない画面にする。 2. オブジェクトを選択し、削除を行う。 3. バージョンを表示していない場合はオブジェクトが完全に削除したように見える。 4. バージョンを表示させることで、現行バージョンが削除マーカーになり、元の現行バージョンが非現行バージョンに移行したことが確認できる。 このように削除マーカーはオブジェクトが削除されたことを示すための、実体を持たないバージョンであり、削除マーカーは0KBのオブジェクトであることを確認できました。 補足：削除マーカーを削除した場合 削除マーカーの バージョン ID を指定して削除 すると、 直前の非現行バージョンが 現行バージョンに繰り上がる 結果として、 オブジェクトが「復活」したように見える という挙動になります。 S3ライフサイクルルールとは S3の ライフサイクルルール では、オブジェクトに対して大きく分けて 2種類のアクション を定義できます。 ストレージクラスの移行（Transition） 有効期限による削除（Expiration） 前者は、一定期間が経過したデータをStandard-IAやGlacierなどの 安価なストレージクラスへ自動的に移行 する設定です。 後者は、 データを削除する設定 になります。 本記事では主に削除に関するライフサイクルルールにフォーカスしますが、全体像を把握するため、代表的な設定を以下に整理します。 ライフサイクルルールの主な種類 ライフサイクルルールの種類 説明 現行バージョンを他ストレージクラスへ移行 オブジェクトの 現行バージョン を、指定日数経過後にStandard-IAやGlacierなど別のストレージクラスへ変更する。 非現行バージョンを他ストレージクラスへ移行 非現行バージョン を、指定日数経過後に別のストレージクラスへ移行する。 現行バージョンを有効期限切れにする 現行バージョンを指定日数経過後に 削除マーカー付きにする（＝論理削除） 。 ※ バージョニング無効バケットでは、この設定で完全削除される。 非現行バージョンを完全に削除 非現行バージョンを、指定日数経過後に 物理削除 する。 期限切れオブジェクト削除マーカーの削除 期限切れの削除マーカー を自動で削除する。 つまり「削除マーカーしか残っていないオブジェクト」を定期的に掃除する設定。 未完了のマルチパートアップロードの削除 途中で中断されたマルチパートアップロードのパーツデータを削除する。 移行ルールと削除ルールの位置づけ 上記のうち、最初の2つ（ストレージクラスへの移行）は主にコスト最適化を目的としたルールです。 AWS 認定試験でも頻出で、実際に設定したことがなくても知識として知っている方は多いのではないでしょうか。 一方で、 現行バージョンの有効期限切れ 非現行バージョンの削除 削除マーカーの削除 といった 削除関連のルール は、 データの寿命管理 や バージョニング有効時の削除運用 に直結します。特に本記事のテーマである 「バージョニングの削除」 を正しく理解するためには、これらの削除ルールの挙動を押さえておくことが重要です。 次節では、これらのルールが 削除マーカーや非現行バージョンに対してどのように作用するのか を、具体的な例を交えて詳しく解説していきます。 ライフサイクルルールの実行タイミング ライフサイクルルールは、 1 日に 1 回のみ 実行されます。 そのため、「指定日数に達した瞬間に削除・移行される」わけではありません。 AWS 公式の説明によると、ライフサイクルルールの適用は おおよそUTC0:00（日本時間 9:00 頃） に行われます。 したがって、「1日後に削除」と設定した場合、実際にはその日数を経過した 次の午前9時（日本時間） に 削除や移行が実行されると考えるとよいでしょう。 参考: 【S3】ライフサイクルルール 削除マーカーをご存知？ バージョニング有効時の削除 × ライフサイクルルール ここまで、バージョニングによる削除の仕組み（削除マーカー）と、ライフサイクルルールの種類について説明してきました。 ここからはいよいよ核心である、 「バージョニング有効バケットの削除を、ライフサイクルルールでどう管理するか」 について解説します。 バージョニングが有効なバケットでは、前述のとおり、オブジェクトを削除しても データ自体は残る ため、 何も考えずに運用すると ストレージが際限なく蓄積 していきます。 一方で、古いバージョンを無計画に手動削除してしまうと、せっかくの 「誤削除から復元できる」というメリットを失ってしまいます。 そこで重要になるのが、 ライフサイクルルールを 使った計画的な削除運用です。 現行バージョンを有効期限切れにする このルールを設定すると、対象オブジェクトは指定日数経過後に 削除マーカーが自動で付与 されます。 つまり、 ユーザーが削除操作をしなくても、自動的に「削除された状態」になる という挙動です。 下図では、現行バージョンを有効切れにすることで、現行バージョンが非現行バージョンに移行しています。（下図 ①） そして、削除マーカーが現行バージョンとして生成されます。（下図 ②） 非現行バージョンを完全に削除 こちらは、 すでに履歴となった古いバージョンを物理削除 するルールです。 この設定は バージョニング有効時のみ意味を持つ もので、 「非現行になってから 30 日後に削除」 「最新の 5 バージョンは残す」 といった指定が可能です。 ユーザーによる手動削除や、新しいバージョンのアップロードによって非現行化したファイルが、一定期間後に自動でクリーンアップされます。 下図では、非現行バージョンを完全に削除し、 test.txt が物理削除されています。（下図 ③） 期限切れオブジェクト削除マーカーの削除 このルールを設定すると、削除マーカーしか残っていないオブジェクトの削除マーカーを物理削除するルールです。 つまり、 ユーザーが削除操作をしなくても、自動的に「削除された状態」になる という挙動です。 下図では、有効期限切れの削除マーカー削除により、削除マーカーも物理削除され、オブジェクトが完全に削除されます。（下図 ④） この3つのライフサイクルルールを組み合わせることで、バージョニングを設定したオブジェクトを自動で削除することができます。 ライフサイクルルール「 現行バージョンを有効期限切れにする 」と「 期限切れオブジェクト削除マーカーの削除 」は 併用不可 なので、2つのライフサイクルルールの設定が必要になります。 以下のライフサイクルルールを設定した場合の挙動を例に説明します。 現行バージョン： 1 日後 に有効期限切れ 非現行バージョン： 1 日後 に削除 期限切れ削除マーカー： 有効 ライフサイクルルールの設定時の時系列 1 日目 test.txt を作成（現行バージョン） 2 日目 現行バージョンが有効期限切れとなり、非現行バージョンに移行 → 削除マーカーが現行バージョンとして作成される 3 日目 非現行バージョンが削除され、データ本体が消える 同日または次回実行時 期限切れ削除マーカーが削除され、バケット内からオブジェクトが完全に消える このように、 設定してから完全削除までには数日かかる 点が重要です。 ライフサイクルルールによる自動削除の検証 上記の設定で実際にコンソールで設定してデモを行ってみます。 今回の検証では、以下の2つの S3 バケットを用意しました。 基本的なライフサイクル設定は同一とし、 「期限切れ削除マーカーの削除」 設定だけを変えています。 設定項目 test-1-oy test-2-oy 対象オブジェクト test.txt test.txt 現行バージョンの有効期限 1日 1日 非現行バージョンの削除 1日 1日 期限切れ削除マーカーの削除 有効 無効 検証前の想定 検証前は、以下のように予想していました。 test-1-oy 削除マーカー削除を有効にしているため、最終的にはオブジェクトが完全に削除される。 test-2-oy 削除マーカー削除を無効にしているため、削除マーカーだけはバケットに残り続ける。 この予想が正しいかどうかを、実際に確認していきます。 検証ログ 1. 2/16 20:30：オブジェクトをアップロード まず、両バケットに test.txt をアップロードしました。 この時点では、どちらのバケットにも 現行バージョンのオブジェクトが1つ存在する状態 です。 2. 2/18 朝：何も起きない？ 「現行バージョンの有効期限」を1日に設定していたため、そろそろ削除マーカーが付くはず、と思って確認しましたが、 特に変化はありませんでした。 ここで分かったのは、以下の点です。 ライフサイクルルールは、設定した日数どおりにきっちり動くわけではない 評価や実行は非同期で行われるため、多少のズレが発生するようです。 3. 2/18 夜：削除マーカーが登場 夜に確認したところ、ようやく変化がありました。 test-2-oy バケットのみで 削除マーカーが生成 （test-1-oyバケットは2/19 朝に削除マーカー生成を確認） 元の test.txt は 非現行バージョン へ移行 このタイミングで、現行バージョンの有効期限切れが実行されたと考えられます。 また、2つのバケットで削除マーカーが生成されるタイミングが異なるということは、 ライフサイクルルールが必ずしも設定日数きっちりに動作するわけではないことを裏付ける結果となっております。 4. 2/20 夕方：なかなか消えない非現行バージョン 次は「非現行バージョンを1日で削除」の設定です。 こちらもすぐに消えるかと思いきや、 2/20 夕方時点でも、非現行バージョンは残ったまま という状態でした。 設定上は「1日」ですが、 実際の削除までには2日以上かかることもある ようです。 5. 2/20 夜：非現行バージョンが削除される 夜になってようやく、非現行バージョンが削除され、バケット内には 削除マーカーのみ が残る状態になりました。 6. 2/24：最終確認で想定外の結果に 最終的な状態を確認したところ、結果は以下の通りでした。 test-1-oy ：オブジェクトなし（想定どおり） test-2-oy ：オブジェクトなし（想定外） 削除マーカー削除を 無効 にしていた test-2-oy でも、 削除マーカーが消えていました。 検証して分かったこと ライフサイクルは「条件成立」と「実行」が別物 今回の検証を時系列で整理すると、以下のような流れで処理が進んだと考えられます。 現行バージョンの有効期限切れが実行される 非現行になってから一定時間経過と判定される 削除処理がキューに入り、後から実行される つまり、 設定した日数＋AWS 側の処理タイミング という考え方をしておかないと、「まだ消えないの？」と不安になりがちです。 削除マーカーはのみになると消えることがある test-2-oy の結果から分かったのは、削除マーカーが 期限切れ かつ、バケット内で唯一のバージョン という状態になると、個別に削除マーカー削除を有効にしていなくても、 S3 側のクリーンアップ処理で削除される場合がある という点です。 まとめ 本記事では、S3 バージョニング有効時におけるオブジェクト削除の挙動と、ライフサイクルルールによる削除管理について整理しました。 S3 バージョニングが有効なバケットでは、オブジェクトを削除しても即座にデータが消えるわけではなく、 削除マーカーが付与されることで論理削除される という点が重要なポイントです。 その結果、非現行バージョンや削除マーカーが意図せず残り続け、ストレージコストが発生し続けるケースも起こり得ます。 このような特性を踏まえると、バージョニング有効バケットでは ライフサイクルルールを前提とした削除運用設計が必須 だといえます。 特に以下の3点は、検証から得た実運用において押さえておくべきポイントです。 ライフサイクルルールは「指定日数どおりに即時実行されるものではない」 → 条件成立と実行にはタイムラグがあり、削除まで数日かかることがある 非現行バージョンを削除しない限り、実データは残り続ける → 「削除＝完全削除」ではない点に注意が必要 削除マーカーのみが残った状態では、設定によらず S3 側で自動削除される場合がある → 挙動は非同期かつブラックボックス的であり、過度な即時性は期待しない バージョニングは非常に強力な保護機能ですが、正しく理解せずに使うと「消したつもりなのに消えていない」「いつ消えるのか分からない」といった不安を招きます。 本記事が、S3 バージョニング有効環境における削除挙動の理解や、ライフサイクルルール設計の一助になれば幸いです。
こんにちは！ 佐藤です。 本記事では、Microsoft Azure環境をCatoクラウドへ接続するための、 vSocket構築手順を解説します。 Azureの操作に慣れていない方でもスムーズに構築が進められるよう、図を多めに用いて手順をまとめましたので、 ぜひご活用いただければ幸いです。 はじめに vSocket（virtual Socket）とは、 組織のクラウド環境をCatoクラウドに接続するための仮想アプライアンス です。 本社や工場などの拠点をCatoへ接続する際には、通常「Socket」と呼ばれる物理アプライアンスを設置しますが、 クラウド環境ではその代わりとしてvSocketを利用します。 現在vSocketは以下の主要なクラウドサービスで利用可能です。 AWS (Amazon Web Services ） Google Cloud Microsoft Azure VMware ESXi 上記の中でも、本記事では Azure vSocketの構築手順を紹介していきます。 本記事は、2026年3月11日時点でのAzure vSocketの設定手順となります。 内容については今後変更の可能性がありますこと、ご了承ください。 図例については、一例としてご参考にいただけますと幸いです。 Cato社が提供する最新版の構築手順は下記となりますので、本記事と併せてご参照ください。 Deploying-Azure-vSockets-from-the-Marketplace ※本書と上記ナレッジベースの内容に差異がある場合、ナレッジベースの内容を正とします。 構成イメージ 本記事では、 vSocketを1台のみ構築する 「シングル構成」 でのデプロイを想定して構築手順を解説します。 手順内で使用している画像は、筆者が実際に検証を行った際の画面キャプチャとなります。 設定内容によって表示が一部異なる場合がありますので、あくまで参考情報としてご参照ください。 構成イメージは以下のようになります。各リソースの役割などは後ほど説明していきます。 その他の構成 HA構成 Azure vSocketをHA構成とする場合、基本的にはシングル構成と同様の手順ですが、各種パラメーターの指定に注意が必要です。 再掲にはなりますが、以下KnowledgeBaseの 「Adding a Secondary vSocket for High Availability」 の箇所をご参照ください。 Just a moment... support.catonetworks.com また、以下のトラブルシューティングページもご活用ください。 Just a moment... support.catonetworks.com 複数VNetとの接続 複数VNetとvSocketを接続したいといった場合には、 VNet Peering によって実現可能です。 詳細は、以下の記事をご参照ください。 【Catoクラウド】vSocketで複数VPC/VNetを接続したい CatoクラウドにAWS/Azure環境を接続する際の、パブリッククラウド側の構成例や設定のポイントをご紹介します。 blog.usize-tech.com 2024.08.08 事前準備 既に作成済みのセキュリティグループなどを使用する場合は、 前提条件として、以下の項目をクリアしていることをご確認ください。 Azure vSocket は、パブリック DNS サーバにアクセスできる必要があります。 VNet(仮想ネットワーク) がプライベート DNS サーバのみを使用するように構成されていないことを確認してください。 確認方法としては、構築に用いるVNetの画面で 「Azure提供のDNSサービス」 が指定されていれば問題ありません。 vSocket インスタンスは、次のリソースへのアウトバウンド接続が必要です。 WANインターフェイスからインターネットへの下記ポートの通信許可 UDP 53 UDP 443 TCP 443 LANインターフェイスからVNet内への DNS および HTTP、Azure Resource Manager への HTTPS MGMTインターフェイスから、インターネットへのUDP 53、management.azure.com へのTCP 443 ※セキュリティグループの設定例は後の手順「2-5オプションの指定」に記載しています。 2026年3月現在、中国国内リージョンではAzure マーケットプレイスからのvSocketデプロイはサポートされていません。 中国でvSocketをデプロイするには、手動でのデプロイをお願いいたします。 詳細手順は以下、Cato社KBをご参照ください。 Azure vSocketサイトを手動でデプロイする Azure vSocketの構築手順 vSocketの構築手順を説明していきます。 以下の流れで構築を進めます。 1. Cato Site 設定 2. Azure 設定 2-1. サブスクリプションとリージョンの指定 2-2. vSocketタイプの指定 2-3. ネットワーク指定 2-4. 各種パラメータの指定 2-5. オプションの指定 2-6. タグの指定 2-7. vSocketのデプロイ 3.疎通確認 1. Cato Site設定 Cato側でのSite（拠点）作成を行います。 1. CMAのナビゲーション・メニューから、「Network」 > 「Sites」をクリックします。 2. 「New」をクリックします。 3. Add Siteウィンドウから、サイトの設定を行い、「Apply」をクリックしてください。 • Site Name : ユニークなサイト名 • Site Type : 適切なものを選択 • Connection Type : vSocket Azureを選択 • Country : 使用する国を選択 • State : 使用する地域を選択(日本の場合選択不要) • Time Zone : 使用するタイムゾーンを選択 • License Type/License ：使用するライセンス • Downstream ： ライセンスの帯域幅に従って設定 • Upstream ： ライセンスの帯域幅に従って設定 • Native Range : 使用するLAN側のIPレンジを設定 • Local IP : 使用するLAN側のLocal IPを設定 ・ネットワークセグメントは、Azure仮想ネットワークのネットワーク範囲に含まれている必要があります。 ・ vSocketのローカルIPは、 VM上LANインターフェイスのIPアドレス と同じである必要があります。 ・ サブネットの最初の4つ、最後の1つのIPアドレスは、Azure側で予約されています。 4. 「Network」>「Sites」からAzure vSocket Siteの設定で作成したサイトをクリックします。 5. 「Site Configuration」>「Socket」をクリックし、 シリアル番号(S/N) をコピーして控えてください。 ※ このシリアル番号は、この後vSocketを構築する際に使用します 2. Azure 設定 Azure側での設定を行います。 2-1. サブスクリプションとリージョンの設定 1. Azure Marketplace から “Cato” を検索し、任意の「サブスクリプション」と「プラン」の ”Cato Socket Template” を選択します。 2.「作成」 をクリックします。 3. vSocketを作成する サブスクリプション 、 リソースグループ を選択します。 4. vSocketを作成する リージョン を選択します。 2-2. vSocketタイプの指定 作成しようとしているvSocketのタイプを選択します。 Primary : シングル構成の場合に選択。またはHA構成のPrimaryを構築する際に選択 Secondary : HA構成で、Primary側の構築はすでに完了していて、Secondaryを構築する場合に選択 Secondaryを先に構築することや、Secondaryのみで動作させることはできません。 2-3. ネットワーク設定 1. ネットワークインターフェースの数を指定します。 インタフェースは、WAN、LAN、MGMTの3つが使用されます。 シングル構成の場合はWAN、LANインタフェースのみの2NIC構成も可能です。 ※シングル構成の場合はMGMTインタフェースでのトラフィックを必要としないため、2NIC、3NICで機能差異はありません。 WANインタフェース：Catoクラウドへの接続 LANインタフェース：Azure内部リソースへのトラフィックを処理 MGMTインタフェース：HA構成時vSocketとAzureAPI間の連携を管理 ２NICと3NICの違いや、3NIC→2NICへ移行する際のポイントについて、以下のブログにて詳細が記載されております。 【Catoクラウド】AzureのvSocketが2ポート対応した件 AzureのvSocketが2NICのマシンタイプをサポートしたので、作成方法と移行方法を紹介してます。 blog.usize-tech.com 2024.11.29 2. vSocketを作成するVNetを指定します。 3. 各インターフェイスのサブネットを指定します。 VNet・サブネットは既存のものを選択することも、新規に作成することも可能です。 新規作成の場合は、(New)とついているリソースが自動で作成されます。 なお、 「Edit virtual network」 または 「Edit subnet」 から新規作成されるリソースの詳細設定が可能です。 リソース名など、管理上分かりやすいように変更することをお勧めします。 4. 「Edit virtual network」 から、VNetの任意の名前とアドレスレンジを設定します。 🖋 マークからは、サブネットの設定を行うことが可能です。 5. サブネットについても 「名前」 と 「サブネットレンジ」 の設定を入力し、「保存」をクリック 既存のセキュリティグループやルートテーブルを使用したい場合は、指定のリソースを選択してください。 2-4. 各種パラメータの指定 Socketのパラメータを指定します。 • vSocket Serial Number : 手順1で控えたシリアルナンバーを入力します。 ※ Cato管理画面のシリアルと一致しない場合、vSocketがデプロイ後に認識されません。 • vSocket LAN IP : 手順1で設定したLocal IPを入力します。 ※Cato管理画面のLocal IPと一致しないと、トラフィックがルーティングされません。 • VM Size ： vSocketのVMサイズを指定します。 ・D8ls_v5：2NIC、3NIC対応 ・D2s_v5：2NICのみ対応 • vSocket interface IP allocation type / WAN・MGMT interface IP allocation： WAN・MGMTのプライベートIPアドレスを、自動で割り振るか(Dynamic)、手動で指定するか(Static)の選択です。 Staticを選択すると、IPアドレスの入力欄が表示されます。お好みの方で設定ください。 2-5. オプションの指定 その他のオプション設定です。 それぞれの概要を説明します。 Public IP Addresses パブリックIPの新規作成の有無を選択します。 Microsoftより 2026年3月31日以降、デフォルトのインターネットへのアウトバウンドアクセス機能が含まれなくなると発表がありました。 それに伴い、これまでは、パブリックIPを「None」に設定することが可能でしたが、 新たにデプロイされるvSockeはパブリックIPが必須の設定 となります。 なお、Noneを選択して作成した既存のvSocketについては、Microsoftによるサポートが継続されるため変更は不要ですが、 Cato社としてもパブリックIPやNATゲートウェイなどを明示的に設定することを推奨しています。 参考元のCato社公式KBは以下になります。 Just a moment... support.catonetworks.com Security Groups セキュリティグループを新規作成するか、既存のものを使うかの選択です。 こちらもこれまでは、Noneの選択が可能でしたが、 上記の通りデフォルトでパブリックIPが設定されるため、必須設定になると予想しています。 具体的な設定内容ですが、Cato社推奨は以下の通りとなっています。 WANセキュリティルール ：すべてのインバウンドトラフィックを拒否し、すべてのアウトバウンドトラフィックを許可 ⇒すべてvSocket起点のアウトバウンド通信とその戻り通信であり、インバウンドトラフィックは不要なため LANセキュリティルール ：両方向全てのトラフィックを許可 ⇒インバウンドLANトラフィックはCatoのFWルールなどで制御可能なため 上記を踏まえた設定例は以下のようになります。 ※WAN_OUTBOUND_ALLOWについてはデフォルトのルールですでに許可されているので設定しなくても問題ありません。 ※LANセキュリティグループはデフォルトからの変更はありません。 セキュリティグループを作成すると優先度650000番台のデフォルトルールが作成されます。 ルールとしてはロードバランサーからの通信を許可したり、インターネットへの通信を許可したりなどがありますが、 その中でも65000番に VirtualNetworkからVirtualNetworkへの通信を許可するルール があります。 当初は「VNet内の通信を許可するものなのかな」ぐらいに思っていましたが、 疎通確認時にICMPを許可せずとも外部のモバイルクライアントからのpingが成功したため、 ここでいう「Virtual Network」とは VNet内だけでなくCatoクラウドの環境も含まれているようです。 つまり、Catoクラウド内の通信であれば、デフォルトですべての通信が許可されているということになります。 Availability HA構成時のAzureの可用性セット・可用性ゾーンを利用するかどうかです。 シングル構成時は「None」で問題ありません。 Availability Set ：単一データセンター内での障害から保護する。 Availability Zone ：リージョン内の複数データセンターで冗長化。データセンター単位の障害から保護する。 ・異なる可用性ゾーンを使用しているVMに可用性セットを割り当てることはできません。 ・AzureではVM作成後に可用性セットに割り当てることはできません。 2-6. タグの指定 vSocketに関連するリソースにタグを付けたい場合は、ここでご指定ください。 2-7. vSocketのデプロイ 最後に、設定内容の確認画面が表示されます。 内容に誤りが無いことを確認の上、「作成」をクリックします。 デプロイには数分かかります。 CMA上のSite一覧で以下のように 「Connected」 と表示されていれば作成完了です。 Azureの環境や設定状況によっては、vSocketのデプロイが失敗する場合が考えられます。 デプロイエラーの内容や、 Azure アクティビティ ログから失敗理由をご確認ください。 改めてvSocketを作成する際は、 エラー時に作成されてしまったリソースを削除してから再試行 するようご注意ください。 3. 疎通確認 実際に作成したvSocketを通して、VNet内のリソースにアクセスできるかを確認してみました。 以下のイメージ図のように、外部のCatoクライアントをインストールしたPCからTest VMへログインできるかを試します。 新たに内部セグメントを追加する際には、以下の2点注意をしてください。 LANサブネットに割り当てられているルートテーブルと同じものを割り当てる 「宛先：0.0.0.0/0 ネクストホップ：LAN NICのアドレス」ルールが設定されているルートテーブルが LANサブネットにデフォルトで割り当てられています。 Catoと通信させたい内部のサブネットにはすべてこのLANルートテーブルを割り当ててください。 CMA上でルーティングを登録する こちらも忘れがちですのご注意ください。 Azure上でセグメントを追加した際は、Catoにも、そこへのルーティングを知らせる必要があります。 「Network」> 「対象のSite」> 「Site Configuration」>「Networks」から設定が可能です。 Type 「Routed」 を選択し、 宛先 と ネクストホップとなるゲートウェイ を登録してください。 ゲートウェイは LANサブネットの先頭アドレス を指定してください。 上記画像の例ですと、LANサブネット：192.168.34.0/24 なので、ゲートウェイ：192.168.34.1 となります。 テスト用のVMを作成したので、実際に疎通確認を行ってみました。 SSHコマンドを打った後、VM作成時に事前設定したログイン用パスワードを入力し、接続することができました。 おわりに 本記事では、Azure環境をCatoクラウドへ接続させるためのvSocket構築手順を解説しました。 マーケットプレイスからのデプロイは、非常に手軽で便利な一方、 自動生成されたリソース（セキュリティグループや、ルートテーブルなど）を 既存のネットワーク構成に適用できるように調整するという手順も必須です。 Azureに限らずですが、問題なく通信できていたとしても「何をどこで管理しているか」はしっかりと把握しておくべきだと感じました。 以上です。ご覧いただきありがとうございました！
こんにちは、SCSKでAWSの内製化支援『 テクニカルエスコートサービス 』を担当している貝塚です。 前回・前々回の記事では、AWS Systems Manager Session Managerのセッションログ記録とRDP録画の設定方法を解説しました。SSM-SessionManagerRunShellドキュメントでCloudWatch Logsへのログ記録を有効化し、Just-in-timeノードアクセスでRDP接続の画面録画を設定することで、EC2インスタンスへのすべての操作を証跡として残す仕組みを構築しました。 しかし、ここでひとつ疑問が浮かびます。Session Managerには対話型シェル以外にも、ポートフォワーディングやSSH over SSMなど、複数の接続方法があります。これらの接続方法を使われた場合でも、ログや録画はきちんと記録されるのでしょうか。もし記録されない接続方法が存在するなら、それを使われてしまうとせっかくの設定が無意味になってしまいます。 本記事では、Session ManagerとFleet Managerの接続バリエーションを網羅的に洗い出し、それぞれでセッションログやRDP録画が記録されるか調査結果をまとめています。その上で、記録が回避されるシナリオを特定し、ネットワーク面と設定面の両方から対策を整理します。 Session Managerの通信メカニズム 接続バリエーションごとのログ記録状況を理解するために、まずSession Managerの通信の仕組みを押さえておきましょう。 通信の全体像 Session Managerでは、EC2インスタンス上で動作するSSM Agentが、AWSのサービスエンドポイントに対してアウトバウンドのHTTPS（ポート443）接続を確立します。クライアントPC側も同様に、AWSのエンドポイントに対してHTTPS接続を行います。つまり、クライアントPCとEC2インスタンスが直接通信するのではなく、AWSのサービスを介してデータをやり取りする構成です。 この仕組みにより、EC2インスタンス側でインバウンドポート（SSH 22番やRDP 3389番）を開放する必要がありません。SSM Agentが自らAWSサービスに接続しに行くため、ファイアウォールでインバウンドトラフィックを許可する必要がないのです。 Session Managerが使用する主なエンドポイントは以下の3つです。 ssm.region.amazonaws.com: コントロールプレーン。セッション開始時の認証・認可や、SSM Agentの定期的なハートビート（5分間隔）に使用されます ssmmessages.region.amazonaws.com: データプレーン。セッションの実データ（シェル入出力やポートフォワーディングのストリーム）を中継します。WebSocket over HTTPS/443で双方向通信を行います ec2messages.region.amazonaws.com: メッセージ配信。SSM Agent 3.3.40.0以降ではssmmessagesが優先されます インターネットゲートウェイやNATゲートウェイを持たない閉じたVPC環境では、これらのエンドポイント用にInterface型のVPCエンドポイント（AWS PrivateLink）を作成することで、インターネットを経由せずにAWSサービスと通信できます。 セッションタイプによる通信の違い Session Managerの通信は、いずれのセッションタイプ(次項「セッションドキュメントの4つのタイプ」参照)でもクライアントPCおよびEC2インスタンスからssmmessagesエンドポイントへのWebSocket over HTTPS/443接続で行われます。この接続はTLS 1.2以上で暗号化されています。ただし、この接続の中を流れるデータの扱いがセッションタイプによって異なり、それがログ記録の可否に直結します。 対話型シェルセッション（Standard_Stream。後述）の場合、SSM Agentがインスタンス上のシェルの入出力を読み取り、WebSocket接続を通じてクライアントPCに中継します。シェルの入出力はプレーンテキストとしてSSM Agentが扱えるため、CloudWatch LogsやS3にセッションログを記録できます。 一方、SSH over SSMやポートフォワーディング（Port。後述）の場合、Session ManagerはSSH/RDPの通信を中継するトンネルとして機能します。SSM Agentはトンネルの終端として、受け取ったデータをインスタンス内部のlocalhost上で動作するSSH/RDPサービス（Linuxではsshd、WindowsではRemote Desktop Services）に転送します。ネットワーク経由のインバウンド通信ではないため、セキュリティグループでSSH（22番）やRDP（3389番）を開放する必要はありませんが、インスタンス上でこれらのサービスが起動している必要があります。 Portタイプの通信図解 セッションドキュメントの4つのタイプ Session Managerでは、セッションの種類を「セッションドキュメント」で定義します。ドキュメントには以下の4つのタイプ（sessionType）があります。 タイプ 用途 ログ記録可否 Standard_Stream 対話型シェルセッション 可能 Port ポートフォワーディング、SSH over SSM 不可 InteractiveCommands 対話型コマンド実行 可能 NonInteractiveCommands 非対話型コマンド実行 可能 参考: Session document schema – セッションドキュメントの4つのタイプ（sessionType）の定義 Start a session – 対話型シェル、SSH、ポートフォワーディング等の接続方法 なお、InteractiveCommandsとNonInteractiveCommandsは、カスタムドキュメントであらかじめ定義した特定のコマンドだけを実行させるためのタイプです。InteractiveCommandsはセッションが維持される用途（例: tail -f でログをリアルタイム閲覧）、NonInteractiveCommandsはコマンドを実行して結果を返したら終了する用途（例: ディスク使用率の取得）で使われます。いずれも自由なシェル操作はできないため、一般的なOSログインの手段ではありません。本記事では詳細な説明は割愛します。 ここでのポイントは、Portタイプのセッションではログ記録ができないという点です。AWS公式ドキュメントにも以下のように明記されています。 Logging isn’t available for Session Manager sessions that connect through port forwarding or SSH. This is because SSH encrypts all session data within the secure TLS connection established between the AWS CLI and Session Manager endpoints, and Session Manager only serves as a tunnel for SSH connections. 出典: Enabling and disabling session logging – AWS Systems Manager つまり、Portタイプのセッションでは、トンネル内部がSSH/RDPプロトコルで暗号化されているため、Session Managerはトンネルとしてのみ機能し、中身を記録することができません。 接続バリエーション別のログ・録画記録設定 それでは、Session ManagerとFleet Managerで利用可能な接続方法を洗い出し、それぞれのログ・録画記録設定を確認しましょう。 接続方法の一覧 以下の表は、各接続方法とそのログ・録画記録状況をまとめたものです。 接続方法 ドキュメントタイプ セッションログ(CloudWatch Logs/S3) RDP録画(S3) 使用ドキュメント 対話型シェル（コンソール/CLI） Standard_Stream 記録される – SSM-SessionManagerRunShell SSH over SSM（ProxyCommand） Port 記録されない – AWS-StartSSHSession ポートフォワーディング Port 記録されない – AWS-StartPortForwardingSession リモートホストへのポートフォワーディング Port 記録されない – AWS-StartPortForwardingSessionToRemoteHost Fleet Manager Remote Desktop Port（内部使用） 記録されない 記録される（JIT有効時） AWS-StartPortForwardingSession（内部使用） 各接続方法の詳細 対話型シェルセッション（Standard_Stream） マネジメントコンソールやAWS CLIからドキュメントを指定せずにSession Manager接続を開始すると、SSM-SessionManagerRunShellドキュメントが使用されます。このドキュメントのタイプはStandard_Streamで、シェルの入出力がプレーンテキストとしてSSM Agentに渡されるため、CloudWatch LogsやS3にセッションログを記録できます。 前々回の記事で設定したデフォルトログ記録は、このStandard_Streamタイプのセッションに対して有効です。 SSH over SSM（Port） SSH over SSMは、クライアントPCのSSH設定ファイル（~/.ssh/config）にProxyCommandを記述し、SSHの通信経路としてSession Managerを利用する方法です。SSHクライアントが生成したSSHパケットをSession Manager Pluginがトンネル内にカプセル化して送信します。 この接続ではAWS-StartSSHSessionドキュメント（Portタイプ）が使用されます。トンネル内部がSSHプロトコルで暗号化されているため、Session Managerはトンネルとしてのみ機能し、セッションログは記録されません。ただし、CloudTrailにはssm:StartSession APIの呼び出しが記録されるため、「誰が、いつ、どのインスタンスに接続したか」は追跡可能です。 ポートフォワーディング（Port） AWS CLIで –document-name AWS-StartPortForwardingSession を指定すると、クライアントPCのローカルポートとEC2インスタンスの指定ポートをSession Managerトンネル経由で接続できます。例えば、ローカルの56789番ポートをインスタンスの3389番ポート（RDP）に転送するように指定して、ローカルのRDPクライアントから localhost:56789 に接続するといった使い方です。 このPortタイプのセッションでも、トンネル内部がRDPプロトコルで暗号化されるため、セッションログは記録されません。 リモートホストへのポートフォワーディング（Port） AWS-StartPortForwardingSessionToRemoteHostドキュメントを使用すると、SSM Agentが動作しているEC2インスタンスを踏み台として、そこからネットワーク的に到達可能な別のホスト（例: RDSデータベース）のポートをフォワードできます。こちらもPortタイプのため、セッションログは記録されません。 Fleet Manager Remote Desktop（Port + RDP録画） Fleet Manager Remote Desktopは、マネジメントコンソールからWindows ServerインスタンスにRDP接続できる機能です。内部的にはAWS-StartPortForwardingSessionドキュメントを使用しており、セッションのタイプはPortです。そのため、Session Managerのセッションログ（CloudWatch Logs/S3）は記録されません。 ただし、Fleet Manager Remote Desktopには独自のRDP録画メカニズムがあります。Just-in-timeノードアクセスを有効化し、RDP接続記録を設定すると、 ssm-guiconnect サービスがRDP接続の画面録画をS3バケットに保存します。この録画機能はSession Managerのログ記録とは別のメカニズムで動作するため、Portタイプのセッションであっても画面録画が可能です。 ログ記録の死角 上記の調査結果から、以下のことがわかります。 Standard_Streamタイプ（対話型シェル）のセッションは、SSM-SessionManagerRunShellドキュメントのログ設定が適用され、セッションログが記録される Portタイプ（SSH over SSM、ポートフォワーディング）のセッションは、セッションログが記録されない Fleet Manager Remote Desktopは、セッションログは記録されないが、RDP録画は別メカニズムで記録可能 つまり、ユーザーがAWS CLIでPortタイプのドキュメントを指定してセッションを開始すれば、セッションログの記録を回避できてしまいます。また、当然ですがSession Managerを経由せずにネットワーク経由で直接SSH/RDP接続できてしまう環境では、そもそもSession Managerのログ記録の仕組み自体が機能しません。 回避シナリオと対策 ログ記録の死角を踏まえ、具体的な回避シナリオとその対策を整理します。対策は「ネットワーク面」と「設定面（IAMポリシー）」の2つの観点から考えます。 回避シナリオ シナリオ1: Portタイプのドキュメントを指定してセッションを開始 ユーザーがAWS CLIで以下のようなコマンドを実行すると、ポートフォワーディングセッションが開始され、セッションログは記録されません。 aws ssm start-session \ --target i-1234567890abcdef0 \ --document-name AWS-StartPortForwardingSession \ --parameters '{"portNumber":["3389"],"localPortNumber":["56789"]}' この場合、ローカルのRDPクライアントから localhost:56789 に接続すれば、Session Managerトンネル経由でインスタンスにRDP接続できますが、セッションログには何も記録されません。 シナリオ2: ネットワーク経由でSSH/RDPに直接接続 EC2インスタンスのセキュリティグループでSSH（22番）やRDP（3389番）のインバウンドが許可されている場合、Session Managerを経由せずに直接接続できてしまいます。この場合、Session Managerのログ記録の仕組み自体が関与しないため、操作記録は一切残りません。 ネットワーク面の対策 ネットワーク面の対策は、シナリオ2（Session Managerを経由しない直接接続）を防ぐことが目的です。 プライベートVPC環境の構築 インターネットゲートウェイやNATゲートウェイを持たないプライベートVPC環境を構築することで、インターネット経由での直接接続を遮断できます。EC2インスタンスがAWSサービスと通信するためには、VPCエンドポイント（AWS PrivateLink）を使用します。 セキュリティグループの設計 EC2インスタンスのセキュリティグループでは、インバウンドルールにSSH（22番）やRDP（3389番）を追加しないことが重要です。Session Managerの通信はすべてHTTPS（443番）のアウトバウンドで行われるため、インバウンドポートの開放は不要です。 具体的には、以下のような設計が推奨されます。 EC2インスタンスのセキュリティグループ インバウンド: ルールなし。システムの通信要件上ポート開放が必要な場合でも、SSH（22番）やRDP（3389番）は許可しない。 VPCエンドポイントのセキュリティグループ インバウンド: VPC CIDRからのTCP 443のみ この設計により、EC2インスタンスへの直接SSH/RDP接続は物理的に不可能になります。 ネットワーク制御の限界 ただし、ネットワーク制御だけではシナリオ1（Portタイプのドキュメント指定）を防ぐことはできません。ポートフォワーディングやSSH over SSMは、Session Managerのトンネル（HTTPS/443）を経由して動作するため、セキュリティグループやVPCエンドポイントの設定では区別できないのです。 IAMポリシー設定面の対策 IAMポリシー設定面の対策は、シナリオ1（Portタイプのドキュメント指定）を防ぐことが目的です。 IAMポリシーでドキュメントを制限 Portタイプのセッションドキュメントに対するssm:StartSessionを明示的に拒否（Deny）することで、ユーザーがCLIからポートフォワーディングやSSH over SSMのセッションを開始できないようにします。 ただし、Fleet Manager Remote Desktopは内部的にAWS-StartPortForwardingSessionドキュメントを使用するため、単純にDenyするとFleet Manager Remote Desktopも使えなくなってしまいます。aws:CalledVia 条件を使い、ssm-guiconnect（Fleet Manager）経由の呼び出しは例外とすることで、Fleet Manager Remote DesktopによるRDP接続（RDP録画付き）は許可しつつ、CLIからの直接的なポートフォワーディングは拒否できます。 { "Version": "2012-10-17", "Statement": [ { "Sid": "DenyPortSessionsExceptFleetManager", "Effect": "Deny", "Action": "ssm:StartSession", "Resource": [ "arn:aws:ssm:*:*:document/AWS-StartPortForwardingSession", "arn:aws:ssm:*:*:document/AWS-StartSSHSession", "arn:aws:ssm:*:*:document/AWS-StartPortForwardingSessionToRemoteHost" ], "Condition": { "ForAllValues:StringNotEquals": { "aws:CalledVia": ["ssm-guiconnect.amazonaws.com"] } } } ] } このポリシーにより、ユーザーがCLIからAWS-StartPortForwardingSessionやAWS-StartSSHSessionを指定しようとするとAccessDeniedエラーが発生します。一方、Fleet Manager Remote Desktop（ssm-guiconnect経由）からの接続は aws:CalledVia 条件により拒否されないため、RDP録画付きのRDP接続は引き続き利用可能です。 参考: Configuring IAM permissions for Remote Desktop – Fleet Manager Remote DesktopのIAMポリシー例（aws:CalledVia 条件の使用例） ドキュメントの作成・変更権限の制限 さらに、ユーザーにssm:CreateDocumentやssm:UpdateDocumentの権限を付与しないことで、ログ記録設定のないカスタムドキュメントの作成を防止できます。(設定例は省略します) まとめ 本記事では、Session ManagerとFleet Managerの接続バリエーションを洗い出し、それぞれのログ・録画記録状況を検証しました。 Session Managerの通信メカニズムを調査した結果、セッションドキュメントのタイプによってログ記録の可否が決まることがわかりました。Standard_Streamタイプ（対話型シェル）ではセッションログが記録されますが、Portタイプ（ポートフォワーディング、SSH over SSM）ではトンネル内部がSSH/RDPプロトコルで暗号化されるため、セッションログは記録されません。Fleet Manager Remote Desktopは内部的にPortタイプですが、RDP録画は別メカニズム（ssm-guiconnect）で記録可能です。 この「ログ記録の死角」に対処するには、ネットワーク設定面とIAM設定面の両方から対策を講じる必要があります。 ネットワーク設定面: プライベートVPC環境でインバウンドポートを開放せず、Session Managerを経由しない直接接続を遮断する IAM設定面: IAMポリシーでPortタイプのセッションドキュメントを拒否し、CLIからのポートフォワーディングやSSH over SSMを防止する。Fleet Manager Remote Desktopは aws:CalledVia 条件で例外とし、RDP録画付きの接続は許可する 前回、前々回の記事で設定したセッションログ記録とRDP録画に加え、本記事で整理したネットワークとIAMの対策を組み合わせることで、すべての操作記録を取る環境を実現できます。
こんにちは、SCSKの嶋谷です。 弊社が提供している監視サービスではSQL Serverを監視したいというお客様が一定数います。 Mackerelでは、SQL Serverのキャッシュヒット率や接続ユーザ数といった基本的な情報を監視することができます。 ただし、これらの情報だけでは把握しきれないポイントもあります。（後述） そのため、Mackerelを利用してSQL Serverの監視サービスを提供する場合、取得できるデータが限られた形での提供となってしまいます。 これまでにMackerelでのOracle Databaseの監視について紹介しましたが、今回はSQL Serverを対象に同様の方法を試してみました。SQL Serverからデータを取得し、それをMackerelに連携することで監視できるのか、実装を通して検証しています。 MackerelでOracle Databaseを監視してみた – TechHarmony MackerelでのSQL Server監視 Oracle Database監視に関する記事を投稿した際に、MackerelではSQL Serverの状態を監視する機能がないと記載しておりましたが誤りでした。メトリックプラグインを利用してSQL Serverの状態を監視することができます。 ただし、プラグインは オンプレミスサーバ や EC2上のサーバ に自前でSQL Serverを構築している場合に有効です。 メトリックプラグイン – mackerel-plugin-mssql – Mackerel ヘルプ AWS RDSで構築したSQL Serverを監視する場合は、AWSインテグレーションの機能を利用して監視することができます。 AWSインテグレーション – Mackerel ヘルプ プラグインで取得できるデータには限りがあり、 DBインデックス断片化率などのデータは取得不可です。 また、プラグインがサポートするSQL Serverのバージョンは下記となっており、古いバージョンではプラグインも利用不可です。 ・Microsoft SQL Server 2017以降 ・Microsoft SQL Express 2017以降 今回は、「プラグインでのデータ取得」と「プラグインで取得できないデータや古いバージョンでのデータ取得」の2つの方法を検証してみました。 プラグイン利用を利用したSQL Server監視 今回はSQL Serverのライセンス込みのAMIを利用して、AWS EC2上にSQL Serverを構築して検証を実施しました。 これにより、SQL Serverがインストールされた状態でサーバが起動するため、即時利用が可能となります。 取得可能データ まずは、プラグインで取得可能なデータの一覧を下記に記載します。 グラフ名 メトリック 説明 MSSQL Buffer Cache Hit Ratio ディスクから読み出すことなくバッファーキャッシュで見つかったページの割合 Page Life Expectancy ページが参照されないままバッファープールに留まった秒数 Checkpoint Pages チェックポイントや、すべてのダーティページをフラッシュする必要がある他のオペレーションによって、1秒間にディスクにフラッシュされたページ数 MSSQL Stats Batch Requests 1 秒間に受信した Transact-SQL コマンドバッチの数 SQL Compilations 1 秒あたりの SQL コンパイル数 SQL Re-Compilations 1秒あたりのステートメント再コンパイル数 Connections SQL Server に現在接続しているユーザー数 Lock Waits 1 秒あたりの File IO Provider のロックの待機数 Procs Blocked 現在ブロックされているプロセスの数 MSSQL Access Page Splits インデックスページがオーバーフローした結果、1 秒間に発生したページ分割の数 設定方法 mackerel-agent.confに下記を記載し、mackerel-agentのサービスを再起動するのみです。 ( 前提として、mackerel-agentがインストールされている必要があります。 ) [plugin.metrics.プラグイン名] command = [ "mackerel-plugin-mssql" , "-instance" , "SQLEXPRESS" ] ※インスタンス名(-instance)はデフォルトのインスタンス名として設定される SQLSERVER と SQLEXPRESS の 2つのみに対応しているため、ユーザ固有のインスタンス名の場合はデータが取得できません。 メトリックプラグイン – mackerel-plugin-mssql – Mackerel ヘルプ データの一例 Mackerelコンソール上に表示されたデータの一例を示します。 今回はMSSQL Bufferのグラフを示します。3つのデータを個別・複合的に分析することでDBの傾向を読み取ることができます。 スクリプトを利用したSQL Server監視 プラグインで取得不可のデータに対しては、下記の流れをPowerShellスクリプトで実装し、データ取得・連携をしています。 ①SQL Serverに接続 接続にはSQL認証を利用しているため、SQL認証を許可する必要があります。(設定の詳細は割愛いたします。) ②SQL文を実行してデータ(数値)を取得 ③取得データをエージェントを利用してMackerelに投稿 スクリプト概要 今回はスクリプトに修正を加えることを減らすために、接続情報やSQL文を別のファイルとして用意しました。 修正が必要な場合には、スクリプトではなくsqlファイルやiniファイルを修正することを想定しています。 ファイル名 説明 mackerel_sqlserver_connect.ps1 SQL Serverに接続してデータを取得後、Mackerelに連携するスクリプト mackerel_sqlserver_connect.sql 実行するSQL文を記述したファイル mackerel_sqlserver_connect.ini SQL Serverへの接続情報などを記載したファイル 以下が作成したスクリプトです。 # PowerShell スクリプト例: SQL Server 接続とクエリ実行 param( [string]$sql_file, # 実行するSQLを記述したファイル [int]$item_number, [string]$figure_name, [string]$metric_name, [string]$failure_status, [string]$alert_monitorname ) function Create_Json($HOSTID, $alert_monitorname, $failure_status, $mackerel_output_error, $unixtime, $maxCheckAttempts) { # JSONにしたいデータを「オブジェクト」で作る $bodyObject = @{ reports = @( @{ source = @{ type = "host" hostId = [string]$HOSTID } name = [string]$alert_monitorname status = [string]$failure_status message = [string]$mackerel_output_error occurredAt = [long]$unixtime maxCheckAttempts = [int]$maxCheckAttempts } ) } # JSON文字列へ $POSTJSON = $bodyObject | ConvertTo-Json -Depth 10 return $POSTJSON } #APIキーの取得 function Get-MackerelApiKey { param ( [string]$filePath ) $configContent = Get-Content -Path $filePath foreach ($line in $configContent) { if ($line -match "apikey\s*=\s*`"(.+)`"") { return $matches[1] } } return $null } #TLS1.2を強制 [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 # APIキーを取得 $MACKEREL_APIKEY = Get-MackerelApiKey -filePath ".\mackerel-agent.conf" # hostIDの取得 $HOSTID = Get-Content -Path ".\id" # ヘッダーの設定 $headers = @{ "X-Api-Key" = $MACKEREL_APIKEY "Content-Type" = "application/json; charset=UTF-8" } # 現在時刻をエポック秒で取得 $currentUtcTime = [DateTime]::UtcNow $unixtime = [int][double]((Get-Date $currentUtcTime -UFormat %s)) # ユーザ自身で接続情報(ユーザ名やパスワード)とSQL文を別のファイルに準備していただき、そのファイルを読み込み $filePath = "mackerel_sqlserver_connect.ini" $PARAM = @{} try { Get-Content $filePath -ErrorAction Stop | % { $PARAM += ConvertFrom-StringData $_ -ErrorAction Stop } } catch { Write-Error "File not exists: $filePath" exit 0 } # 取得した接続情報を各変数に代入 $Server = $PARAM.Server $UserName = $PARAM.UserName $Pass = $PARAM.Pass $maxCheckAttempts = $PARAM.maxCheckAttempts try { # 接続文字列（SQL認証） $connectionString = "Server=$Server; User Id=$UserName; Password=$Pass; " # 接続とコマンド実行 $connection = New-Object System.Data.SqlClient.SqlConnection $connection.ConnectionString = $connectionString $connection.Open() $command = $connection.CreateCommand() $Query = Get-Content -Path $sql_file -Raw -Encoding UTF8 $command.CommandText = $query $adapter = New-Object System.Data.SqlClient.SqlDataAdapter $command $dataset = New-Object System.Data.DataSet $adapter.Fill($dataset) | Out-Null #数値結果が取得できている場合、エラーが解消されていると判断してSQLServer関連のエラーがあればクローズ $alert_response = Invoke-RestMethod -Uri "https://api.mackerelio.com/api/v0/alerts" -Method Get -Headers $headers # 取得したアラート($alert_response)にはMackerel発生しているアラートすべてが含まれている # アラートからSQLServerに関するアラートだけを取得し、ホストIDとアラート内容でクローズを判定 $response_removes = @() $response_removes += $alert_response.alerts | Where-object { # メッセージが存在し、指定のエラーパターンに一致 ($_.message -ne $null) -and ($_.message -match "SQLServer Error") -and # 同一ホストIDのみを対象 ($_.hostId -eq $HOSTID) } if ($response_removes.Length -ne 0) { #Write-Host "not null" $body = @" { "reason": "solve" } "@ #アラートをクローズ $utf8Bytes = [System.Text.Encoding]::UTF8.GetBytes($body) for ($i = 0; $i -lt $response_removes.Length; $i++) { $return = Invoke-RestMethod -Uri "https://api.mackerelio.com/api/v0/alerts/$($response_removes[$i].id)/close" -Method POST -Headers $headers -Body $utf8Bytes #Write-Output $return } } else { #Write-Output "null" } # 結果表示 $dataset.Tables[0] | Format-Table -AutoSize $connection.Close() #返り値を配列に格納(レコードごとではなく、1データずつ) $table = $dataset.Tables[0] $resultRow = $table.Rows | ForEach-Object { ,$_.ItemArray} $sql_result = @($resultRow | ForEach-Object { $_ } | ForEach-Object { $_ }) Write-Host $$resultRow[0] Write-Host $sql_result[$item_number-1] #Mackerelにデータ投稿される形式で出力 Write-Host "sqlserver.$($figure_name).$metric_name`t$($sql_result[$item_number-1])`t$unixtime" exit 0 } catch { #エラー発生時にチェック監視としてアラートを投稿 $exception_error = "SQLServer Error_net : " + $_.Exception.Message Write-Host $exception_error $POSTJSON = Create_Json $HOSTID $alert_monitorname $failure_status $exception_error $unixtime $maxCheckAttempts $utf8Bytes = [System.Text.Encoding]::UTF8.GetBytes($POSTJSON) Write-Host $POSTJSON $response = Invoke-RestMethod -Uri "https://api.mackerelio.com/api/v0/monitoring/checks/report" -Method Post -Headers $headers -Body $utf8Bytes Write-Host $response exit 1 } 以下にスクリプトの簡単な仕様を記載します。 (1)必要情報の取得 スクリプト実行における必要な情報を取得します。 ・MackerelAPIKey ・ホストID ・DB接続情報(サーバ名・ユーザ名・パスワード) ・Mackerelに表示されるグラフ名、メトリック名 ・SQL文 (2)SQL Serverに接続してデータを取得 DB接続情報、SQL文をもとにSQL Serverに接続してデータを取得。 データが取得できない場合は、エラー内容を文字列で取得し、アラートとしてMackerelに連携します。 エラーの原因は下記が考えられます。 ・DB接続情報の設定ミス ・SQL文の記述ミス ・ネットワークエラー など Mackerelの仕様上、一度投稿されたアラートはMackerel上に表示され続けます。 そのため数値データを取得できた場合は、アラートが解決されたと判断してSQL Serverに関する投稿済みのアラートを自動でクローズします。 (3)データの連携 取得したデータをMackerelに連携します。連携したデータはグラフとして可視化されるので、(1)の処理で取得したグラフ名やメトリック名も同時に連携します。 利用手順 (1)以下のファイルをmackerel-agent.confが格納されているフォルダに配置 ・mackerel_sqlserver_connect.ps1 ・mackerel_sqlserver_connect.sql ・mackerel_sqlserver_connect.ini (2)mackerel_sqlserver_connect.iniにDB接続情報を記述 ・接続するサーバ ・ユーザ名 ・パスワード (3)mackerel_sqlserver_connect.sqlにSQL文を記述 (4)mackerel-agent.confに以下を追記 [plugin.metrics.プラグイン名] command = [“powershell”, “-File”, “mackerel_sqlserver_connect.ps1”, “-sql_file”, “mackerel_sqlserver_connect.sql”, “-item_number”, “連携するクエリ結果の列番号”, “-figure_name”, “グラフ名”, “-metric_name”, “メトリック名”, “-failure_status”, “WARNINGもしくはCRITICAL”, “-alert_monitorname”, “アラート名”] ※プラグイン名・グラフ名・メトリック名・アラート名は任意で設定可能です。 (5)mackerel-agentの再起動 データを取得できた場合 データを取得できた場合、Mackerelに連携されて下記のグラフのように可視化されることを確認しました。 このグラフはセッション総数を可視化しています。 今回はセッション総数のグラフを可視化してみましたが、SQLを実行して取得できる数値データはすべて連携できます。 データを取得できない場合 データを取得できない場合、以下のようなアラートがMackerel上に表示されることを確認しました。 DB接続情報の設定ミス時のエラー SQL文の記述ミス時のエラー 上記のエラー内容は一例ですが、エラー内容を連携することでアラートの原因を一目で理解できます。 まとめ 今回はSQL ServerからSQL文を用いてデータを取得して、Mackerelに連携するスクリプトを作成しました。 Oracle Databaseを対象とした開発を経験していたこともあり、比較的簡単に実装することができました。 現在のスクリプトには課題が多くあり、機能として提供するには程遠い状態です。 自分一人の力では限界があるので、部署の方と協力して提供レベルにまで高度化していきたいです。 最後までご覧いただきありがとうございました！
こんにちは。SCSKの井上です。 この記事では、New Relic APM エージェントを導入した後に、アプリケーション監視画面をどのように読み解けばよいかを解説します。インフラとアプリケーション双方の状態を理解することで、ボトルネックを特定し、問題の早期発見や性能改善につなげられるようになります。 はじめに アプリケーションを安定して動かすには、どの処理に時間がかかっているのか、どこで性能低下が起きているのかを把握することが重要です。New Relic APM を使うことで、アプリケーション内の動きを可視化し、ボトルネックの発見や改善ポイントの特定が迅速に行えます。APMエージェントの導入方法については、過去の記事からご確認いただけます。 【New Relic】分散トレーシングの仕組みとPHPへのAPM導入 複雑なマイクロサービス環境で、障害の原因を素早く特定するには分散トレーシングが欠かせません。本記事では、分散トレーシングの仕組みとAPMをPHPアプリに導入する手順もあわせて解説します。 blog.usize-tech.com 2026.02.05 APMのUI構成 この画面ではAPMの見方を解説します。 主要部分UI New Relic APM の Summary 画面は、サービスの状態を一目で把握できるように、役割の異なる4つのエリアで構成されています。上部のフィルタ、ヘルス指標、時間範囲、右側のアクティビティなど、各エリアが いま何が起きているか”を素早く理解する手がかりになります。まずは、この4つのエリアがそれぞれどんな役割を持っているのかを簡単に説明します。 エリア 内容 1.画面上部のフィルタ & 表示切替エリア どの条件でデータを見るか（比較・フィルタ） 昨日・先週の同時間帯との比較、web全体像やAPI単位での絞り込み等 2.ヘルス指標パネル サービスの健康状態の概要（異常の早期発見） 3.期間選択 データの時間範囲を選択（変化点の確認） 4.アクティビティ履歴 & 関連エンティティ デプロイ・関連サービスなどのヒント（依存関係調査） APM 概要ページを使用したトラブルシューティング | New Relic Documentation With the New Relic APM summary page, run diagnostics with application monitoring tools to quickly resolve incidents. docs.newrelic.com 実際にSummary画面に表示されている情報を解説していきます。 【Web transactions timeの推移グラフ】 アプリの遅延要因が「どこで発生しているか」「いつ発生しているか」 を読み取ることができます。 【Throughputの推移グラフ】 アプリがどれくらいの数のリクエストを処理しているかを示します。急激な増加や低下もなく、負荷が一定している場合はリクエストが安定していると読むことができます。 【エラー発生率の推移グラフ】 アプリ側のロジックや特定の処理で断続的にエラーが出ているかを確認できます。Throughputの上下と連動している場合は、負荷が原因でエラーが増えている可能性があると読むことができます。 【Transactions】 最も遅い5件のトランザクションが表示されています。 平均応答時間は速いが最悪時は非常に遅いトランザクションがあります。処理が遅い原因はSlowest traceの時間をクリックすることで深堀することができます。 【Logs】 実際のエラー内容や例外スタック” を直接確認できます。エラー率は上がっているのに原因が分からない時は、最後にLogs を開いて実際にアプリがどんな状態なのかを確認します。 【Infrastructure】 アプリ側に問題がない場合、インフラ側のCPUスパイク・メモリ不足などが原因のケースも多く、その兆候をまとめて確認できます。Infrastructureエージェントが導入されている場合に表示されます。 Distributed tracing 分散トレーシングとは、ネットで商品を注文するような1つの操作が、裏側でいくつものサービス（ログイン確認、在庫チェック、支払い処理など）を通って処理されるときに、それぞれのサービスで”いつ始まって、いつ終わったか”を記録して、全体の流れを見えるようにするしくみです。 ディストリビューティッド（分散）トレーシング：マイクロサービス全体でリクエストを追跡 | New Relic Documentation What is distributed tracing? An intro to New Relic's distributed tracing feature. docs.newrelic.com Servicemap (Maps) サービスマップでは、システム全体の構成要素（ユーザー体験、サービス、インフラ、アプリ）とそれらの依存関係を可視化しています。この画面は主に 障害発生時の影響範囲分析や、依存関係を把握してトラブルシューティングを行うときに使います。 システム全体の構成要素を役割ごとに分類して依存関係をわかりやすくするため、4つに分類されています。この分類により、どの層で問題が発生しているかを迅速に特定し、影響範囲を把握することができます。 マップ上の階層 説明 User experience ユーザーに直接影響するフロントエンドやUI関連のエンティティ Services アプリケーションのビジネスロジックやAPIなど、サービス層のコンポーネント Infrastructure サーバー、ホスト、ネットワークなど、サービスを支える基盤 Engineering operations デプロイ、CI/CD、アラートなど、運用や管理に関する要素 赤枠のRelationship depthは、サービスマップで表示する依存関係の階層の深さを設定します。どこまで依存関係を掘り下げて表示するかを制御する設定で、障害調査時に影響範囲を広く見るか、直接関連だけ見るか、を切り替えるために使います。 サービス マップ: エンティティを視覚化する | New Relic Documentation New Relic's service maps are visual, customizable representations of your application architecture. docs.newrelic.com Dependencies システム内のエンティティ(アプリケーション、サービス、DB、ホストなど)が他のエンティティにどのように依存しているかを示します。Service Mapはシステム全体のアーキテクチャを視覚化に対して、Dependenciesは特定のエンティティが依存しているリソースやサービスに焦点を当てています。Relationship列にて選択したEntityとの接続関係を示します。対象のエンティティから見て上流（called from)や下流（called to）の依存関係があり、どのサービスがどれに依存しているかを確認できます。 Dependencies UI。エンティティのアップストリームおよびダウンストリームの依存関係の表示 | New Relic Documentation An entity's dependencies page shows the selected entity's upstream and downstream dependencies for apps, services, datab... docs.newrelic.com Transactions アプリケーションのリクエスト処理状況を可視化し、どのトランザクションが遅いのか、どの時間帯に負荷が高いのか、リソース使用率がどうなっているかを把握するために使います。主に、レスポンス遅延やサーバー負荷の原因を特定する際に役立ちます。 Sort by 意味 利用シーン 活用例 Most time consuming 合計処理時間が最も長いトランザクション アプリ全体のパフォーマンス改善 サービス全体の遅延要因を特定し、最適化対象を絞る Slowest average response time 平均応答時間が最も遅いトランザクション ユーザー体験の改善 UXに悪影響を与えている処理を特定し、応答時間を短縮 Highest error rate エラーが最も多く発生しているトランザクション 障害対応・品質改善 エラーの多い処理を調査し、例外処理や再試行ロジックを見直す Throughput (calls per minute) 最もリクエスト数が多いトランザクション 負荷対策・スケーリング 高頻度の処理に対してキャッシュ導入やスケールアウトを検討 Apdex by most dissatisfying ユーザー満足度が最も低いトランザクション 顧客満足度の向上 Apdexスコアが低い処理を改善し、ユーザー離脱を防ぐ 上記画面のトランザクションをクリック後、パフォーマンス状況を詳細に把握することができます。トランザクションに絞った平均応答時間、スループット、エラー率、レスポンス時間の内訳などを分析できます。主にボトルネックの特定や遅延原因の詳細調査に使います。 Histrical Performance 過去のパフォーマンスデータ(yesterday,lastweek)を時系列で可視化・比較分析ができます。 利用シーン 説明 目的・メリット 傾向分析 過去のレスポンス時間やエラー率の推移を確認 パフォーマンスの悪化や改善の兆候を把握 障害調査 特定の時間帯に発生したスパイクやエラーを分析 インシデント対応・根本原因分析 リリース影響確認 デプロイ後のパフォーマンス変化を比較 新機能や修正の影響を定量的に評価 キャパシティプランニング 時期や時間帯ごとの負荷傾向を把握 サーバー増強やスケーリングの判断材料 改善施策の効果測定 チューニング前後のパフォーマンスを比較 最適化の成果を確認し、次の施策に活かす ユーザー体験の推移確認 Apdexスコアの変化を時系列で確認 UX改善の効果を測定し、満足度向上へ Databases アプリケーションのデータベースの状態やパフォーマンスを示します。どのデータベース操作に時間がかかっているのか、どの時間帯に負荷が高まっているのか、接続試行の状況などを確認できます。アプリケーションのレスポンスが遅くなったときや、ピーク時の負荷を監視したいとき、頻繁に時間がかかるクエリを特定して、インデックスの追加やSQLの改善を検討する際にも役立ちます。 ソート方法は以下3パターンが利用できます。 Sort by 意味 利用シーン 具体例 Most time consuming 合計実行時間が最も長いクエリ。頻度と実行時間の両方を考慮。 パフォーマンスに最も影響を与えているクエリを特定し、最適化対象を絞る。 頻繁に呼び出される SELECT * FROM が全体のDB時間の50%を占めている。 Slowest query time 単一実行で最も時間がかかったクエリ。 異常に遅いクエリや、インデックスが適切に使われていないクエリ、非効率な結合処理を含むクエリを特定する。 一度だけ実行された JOIN クエリが5秒以上かかっていた。 Throughput (calls per minute) 単位時間あたりのクエリ実行回数（通常は1分あたり）。 負荷の高い時間帯や、スケーリングの必要性を判断する。 毎分1000回以上 INSERT INTO logs が実行されており、DB接続が逼迫している。 External services External services(外部サービス機能)は、サービス間の依存とボトルネックを可視化し、応答時間が急に長くなった場合や、外部API呼び出しがボトルネックになっているか、サービス間の依存関係や遅延の原因を調べたいときに使います。 外部サービス | New Relic Documentation The external services page captures metric details about out-of-process services such as web services, cloud resources, ... docs.newrelic.com JVMs Javaアプリの内部状態（メモリ・CPU・スレッドなど）をリアルタイムで可視化し、パフォーマンスや障害の兆候を早期に発見できる機能です。 JVMページ（Java）：JMXからアプリサーバーのメトリクスを表示 | New Relic Documentation APM's JVM page for Java: Thread pools, HTTP sessions, and transactions; WebSphere PMI and WebLogic JMX metrics. docs.newrelic.com Threads Threads機能は、スレッドが何をしているのかを観察するツールです。アプリケーションの中では、いろんな処理が同時に動いていることが多く、これらの処理はスレッドと呼ばれます。 Threadsの特徴 ：関数やメソッド単位で時間を特定、CPU消費の可視化、スレッド動作分析、全体のコード実行状況把握 使用シーンと具体例 ：アプリ遅延、CPU高負荷、並列処理の詰まり、トランザクショントレースでは見えない問題 スレッド状態 意味 次のアクション RUNNABLE 実行可能状態。CPUを使って処理中またはすぐに処理できる状態 多すぎる場合は、CPU負荷が高い可能性 → 処理の最適化やスレッド数の調整を検討 WAITING 他のスレッドの通知を待っている状態（例：Object.wait()） 長時間待機している場合は、同期処理の見直しやロックの解消を検討 TIMED_WAITING 一定時間待機している状態（例：Thread.sleep()） 不要な待機がないか確認。待機時間の短縮や非同期処理への変更を検討 BLOCKED 他のスレッドがロックを保持していて、処理できない状態 ロック競合が発生している可能性 。ロックの粒度を下げる、非同期化などの改善策を検討 NEW スレッドが作成されたが、まだ開始されていない状態 多すぎる場合はスレッド管理の見直しを検討 TERMINATED スレッドが終了した状態 終了済みなので問題なし。ただし異常終了がないかログ確認は有効 Identity Security for the Digital Enterprise | Ping Identity support.pingidentity.com Vulnerability APMエージェントを活用してアプリ全体の脆弱性状況を可視化・依存関係の脆弱性を自動検出し、CVSSやランサムウェア情報に基づいて修復の優先度を決定します。AWS Security Hub の調査結果やAWS GuardDuty と Inspector の結果をインポートし、ダッシュボードまたはNRQLで表示することもできます。 AWS セキュリティ統合 | New Relic Documentation Send your security data from AWS Security Hub, GuardDuty, and inspector directly to New Relic. docs.newrelic.com All Vulnerabilities 脆弱性が CVSS（重要度）、EPSS（悪用可能性）、ランサムウェア使用状況のデータに基づいて優先度順にランク付けされています。 優先順位付けにより、アプリの公開範囲や影響に応じた対応計画が立てやすくなります。 アラート設定も可能なため、継続的な脆弱性管理を提供できます。 Security RXを使い始める | New Relic Documentation Use Security RX to identify blindspots and remediate vulnerabilities docs.newrelic.com アプリケーションの脆弱性の優先順位を理解する | New Relic Documentation Learn how Security RX prioritizes application vulnerabilities based on CVSS, EPSS, and active ransomware data. docs.newrelic.com Apps Overview APMエージェントを使ってアプリ依存ライブラリの脆弱性を自動検出し、CVSSやEPSSなどで優先順位を付けて修復を支援します。組織全体／個別アプリの視点で脆弱性状況を可視化することができます。 画面 内容 確認観点 ①Total vulnerabilities 検出された脆弱性の総数と重大度別件数 全体のリスク規模を把握 ②Vulnerability exposure window 脆弱性が放置されている期間を重大度別に表示（ヒートマップ） 長期間放置されているCritical脆弱性は最優先で対応 ③Library status 脆弱性を含むライブラリの件数（Critical、High、その他） ライブラリ単位でアップグレード対象を確認 ④Service・APM status APM監視サービスの脆弱性状況（CriticalやHighを含むサービス数） 影響範囲をサービス単位で把握 ⑤High priority vulnerabilities 優先度の高い脆弱性一覧（CVE番号、重大度、優先度スコア） 修正すべき脆弱性を特定 ⑥Top library upgrades 脆弱性解消のためにアップグレードすべきライブラリ一覧（現行バージョンと推奨バージョン） アップグレード計画に活用 ⑦Top vulnerable entities 脆弱性が最も多いエンティティと重大度分布（赤＝Critical、オレンジ＝High）を表示 Criticalを含むエンティティは最優先で対応 DevSecOps、プラットフォーム、セキュリティチームとしてアプリケーションの脆弱性を管理する | New Relic Documentation Monitor and remediate application vulnerabilities across your entire organization with Security RX. docs.newrelic.com アプリケーションの脆弱性を管理 | New Relic Documentation Monitor and remediate vulnerabilities in a specific application with Security RX entity-scoped views. docs.newrelic.com 障害対応の流れ(一例) 障害対応は最初の一手で混乱しがちですが、まずは全体をざっくり見るところから始まります。もちろん、アラートで原因がほぼ特定できているケースや、過去の経験からこのサービスが落ちると大体ここが怪しいと目星がつく場合もあります。その場合は、最初からSummary画面を見ることも多いです。状況によって入り口は変わりますが、どこが赤くなっている？どのサービスが遅れている？と俯瞰しておくと、全体像が掴みやすく、原因の方向性も自然と見えてきます。この記事では、私が New Relic を使って実際に辿っている障害調査のステップをまとめました。 1.全体像の把握（どこで起きているか？） 今どこで何が起きているのかをざっくり掴むところからスタートします。個人的には、障害対応の時はアタフタしがちなので、まずService Mapで全体の流れを眺めます。赤くなっているサービスや、突然応答が遅くなっている部分がないか？この時点で、障害が特定のサービス単体なのか、依存関係（上流・下流）によるものかを確認します。 2. サービス概要の確認（何が起きているか？） 対象のサービスを特定したら、APMのSummaryページでGolden Signals（応答時間・リクエスト数・エラー率）を確認します。普段と比べてどうなのかを確認したいときは、「Compare with yesterday/last week」 を使うと異常が出始めたタイミングが一目でわかります。エラーのスパイクや、普段ない遅延が出ていれば、ここで気づくことができます。 3. 原因の深掘り(どんな処理の流れか？) 次は Transactions を確認します。ここを見ると「/api/v1/data が妙に遅いな…」みたいに 遅延の正体がスッと腑に落ちる瞬間があります。さらに掘るときは Transaction Trace が便利で、どのメソッドが重いのか、どの SQL が詰まっているのか、ここで原因の目星がつきます。 4. エラーの詳細確認（なぜ起きたか？） エラーが増えているときは Errors Inbox が頼りになります。似たようなエラーをまとめてくれるので、「エラーが多すぎて追えない」という状況でも、原因パターンが整理されます。 5. 外部要因の調査（データベース・外部API） アプリ側が正常でも、依存先が遅れているだけ、というのはよくあります。Databases で遅いクエリを確認したり、External Services で外部 API（決済・認証など）の応答遅延を調べるのも重要です。インフラ側の CPU・メモリ・ネットワーク I/O も見ておくと、原因を取りこぼしにくいと言えると考えています。 さいごに この記事では、New Relic APM が提供する主要な可視化機能や、日々の運用で役立つ画面の見方について解説しました。APM を活用することで、アプリケーション内部の処理を詳細に把握でき、ボトルネック調査や性能改善に役立てることができます。また、トランザクションの流れや外部サービスとの連携状況、データベース処理の負荷といった運用上重要なポイントを多角的に分析できる点も大きな特徴です。APM のデータを Infrastructure やログ、分散トレースと組み合わせることで、アプリケーションとインフラ全体を通した統合的な可視化が可能になります。これにより、個別のコンポーネントだけでなく、システム全体を俯瞰した観点での最適化や改善にもつながります。 SCSKはNew Relicのライセンス販売だけではなく、導入から導入後のサポートまで伴走的に導入支援を実施しています。くわしくは以下をご参照のほどよろしくお願いいたします。
前回 Gensparkとは？をご紹介しましたが、今回は Genspark の音声入力ツール Speakly を紹介します。 エージェント型AI Gensparkとは？ 次世代型AIオールインワンワークスペース Genspark（ジェンスパーク）AI ワークスペース 3.0 について紹介します。 blog.usize-tech.com 2026.03.24 Speakly とは？ Speakly（スピークリー） とは、エージェント型AI（AIエージェント）Genspark が開発・提供する、 次世代AI音声入力ツール で、2026年1月にリリースされ「タイピングをやめて、話すだけ」というコンセプトで現在非常に注目を集めています。 従来の音声入力ツール（iOS音声入力、Google音声入力など）は「声を文字にするだけ」でしたが、Speaklyは異なります。 タイピングの4倍速で入力 話した言葉をリアルタイムでテキスト化。一般的なタイピングと比べて約4倍のスピードでアイデアをアウトプットできます。 AI自動編集機能（フィラー除去・整形） 話した内容をそのまま文字にするのではなく、AIが文脈を理解して自然な文章に整えてくれます。 「えーっと、今日やることが、3つあって、えー、まずメール返して、あと、レポート仕上げて、あと会議の資料作る」と音声発音をした場合、「えーっと」「あのー」などのフィラーを自動除去し、言い直しを検出、最終的な意図を保持、箇条書きや句読点を自動フォーマットをすることで「今日のToDoリスト：① メール返信 ② レポート完成 ③ 会議資料作成」と出力されます。 リアルタイム翻訳（100言語以上対応） 日本語で話した言葉を、そのまま英語・中国語・韓国語などに翻訳してテキスト入力することが可能です。 エージェントモード（AIがPCを操作） これが最大の差別化ポイントとなりますが、ファンクションキー（デフォルトでは右[Alt]キー）を押下し Speaklyを起動し、声だけでGensparkへ指示を送れるなど、声で様々な操作を行うことができます。 2026年3月時点で、Windows、Mac、iOS（iPhone/iPad）、Androidへ対応し、Outlook、Gmail、Slackなど様々なアプリケーションに対応しており、入力フィールドがある場所ならどこでもSpeaklyでの音声入力が使えます。 Gensparkの有料プランのユーザーは無料で利用が可能となっており、有料プランユーザー以外は、7日間の無料トライアルがあり、友達を招待する毎に30日間トライアルが延長されます。 Speakly インストールと利用方法について Speaklyのインストールすると上記ログイン画面が表示されます（画面はWindows 版） Speaklyにテキストを任意のテキストボックスに貼り付けること、マイクを使用することを許可します。 マイクのテストを行います。 Speaklyの音声入力を行うためのショートカットキーのテストを行います。 Windows版のSpeaklyの場合のデフォルトのショートカットは、右の[Alt]キー（Right Alt）ですが、後で変更可能です。 ここから実際にショートカットキーを押して音声入力のテストを行います。Notion→Outlook→Slackとテストを行います。 次からSpeaklyの本領とも言えますが、テキストの書き換えを行います。 テキストを選択（ハイライト）し、 ショートカットキーを押したまま「プロフェッショナルなメールに書き換えて」とプロンプトを音声入力 します。 すると先ほどの選択したテキストが”プロフェッショナルなメールへ”書き換えられました。 つまり、 Gensparkを立ち上げて、プロンプトへ文書を入力（コピー＆ペースト）し、指示を出して、出来上がった文書を元のアプリへコピー＆ペーストする手間が省ける と言う訳です。 次は、日本語で入力されているテキストを選択し、 ショートカットキーを押したまま「英語に翻訳して」と音声入力 します。 すると先ほどの選択したテキストが英語に書き換えられます（このチュートリアルでは、Speaklyの別ウィンドウが立ち上がりました） 要するに、プロンプトへコピー＆ペーストしたい文書を選択し、Speaklyの音声入力指示を行うことで、Gensparkを利用することができるのが、Speaklyのメリットとなります。 ショートカットキーを2回押すとGensparkの入力ウィンドウが起動します ので、ショートカットキーを押したまま音声入力するとブラウザでGensparkが立ち上がります。 こちらはブラウザを起動し、Gensparkのサイトを開くのを省けると言う訳です。 言語は100以上サポートしています。 基本的には入力フィールドがあれば、どのようなアプリケーションでも利用することが可能です。 iOS（iPhone）の場合は、キーボードの上に「タップして話す」のボタンが出てきます。ショートカットキーはありませんが基本的には同じ動作となります。 実際の業務利用について 実際に業務で利用するケースとして、メール作成する際、メール本文にて、Speaklyの ショートカットキーを押したまま「来週以降でオンライン打ち合わせの候補日を2、3ください」と音声入力した後で、そのテキストを選択し、ショートカットキーを押したまま「ビジネスメールに変換してください」と音声入力するだけでビジネスメールへ変換されます。 ショートカットキーを押したまま以下を音声入力（文字の入力） 来週以降でオンライン打ち合わせの候補日を2、3ください 上記テキストを選択し、ショートカットキーを押したまま「ビジネスメールに変換してください」と音声入力 お世話になっております。 来週以降の日程につきまして、オンラインにてお打ち合わせをさせて頂ければと存じます。 つきましては、ご都合のよろしい候補日を2、3ほどいただけますでしょうか。 お忙しいところ恐縮ですが、ご確認のほど何卒よろしくお願い申し上げます。 さらに、上記テキストを選択し、 ショートカットキーを押したまま「英語に変換してください」と音声入力 Thank you for your continued support. Regarding the schedule for next week onwards, I would like to request an online meeting with you. Could you please provide two or three candidate dates and times that would be convenient for you? I apologize for taking up your time, and I appreciate your kind cooperation. 長文のテキストを選択し、Speaklyで「要点をまとめて」「要約して」「箇条書きにして」、英文テキストを「日本語で要点をまとめて」も可能です。 Speakly 以外の音声入力ツールを使っていなかったので、Speaklyの音声認識精度の良し悪しは分かりかねますが、誤認識は許容できる少なさなのだとは思いますが比較的発生します。 また、Speaklyの操作を覚える（意識する）のに慣れが必要なのと、ショートカットがうまく起動しないこと、動作が不安定であったり、正直なところ話題になっているが、一般の特に企業での利用は進まないのではないかと思います。特に、在宅勤務なら音声入力（ひとりで話をしていても）問題はないですが、企業で周りに人が居る状況で音声入力をするのは抵抗感があると思います。 タイピングより音声入力が早いのは実感がありますが、4倍の業務効率が図れると言われると違和感があります。正直なところ、このSpeaklyの記事を Speakly の音声入力ですべて作成しようとしましたが、効率が悪いので途中で諦めました。 さらなる利用方法について Speaklyの設定画面で、ショートカットキーの変更が可能です。 また、おすすめのショートカットや、自分でプロンプトを設定してショートカットを作成することもできます。 事前にセットされている「 英語に翻訳 」には編集で実際のプロンプトを確認することもでき、プロンプトには以下（英語）がセットされており、「英語に翻訳」をショートカットキーで起動すると、音声入力した内容が、英語に翻訳されて出力されます。 Translate the text into natural, fluent English. If it’s already in English, just clean it up and improve clarity. Keep proper nouns, brand names, and technical terms unchanged. Output only the translated text without any explanations. （テキストを自然で流暢な英語に翻訳してください。すでに英語の場合は、文章を整理して読みやすくしてください。固有名詞、ブランド名、専門用語は変更しないでください。説明文は含めず、翻訳されたテキストのみを出力してください。） 「 プロフェッショナル校正 」のプロンプトには以下（英語）がセットされており、「プロフェッショナル校正」をショートカットキーで起動すると、音声入力した内容が、プロフェッショナル校正が行われて出力されます。 Rewrite the following content into polished, professional workplace communication. Rewriting Requirements: – Show empathy and perspective-taking – Use a warm, collaborative, and mature tone – Emphasize win-win outcomes; prefer starting with “we” or “together” – Offer value before making requests – Actively listen and affirm the other party – Create shared goals – Use positive feedback – Replace “but” with “and” or “at the same time” – Preserve the original meaning while making it more professional, respectful, and collaborative – Output only the rewritten content, no explanations or prefixes. （以下の内容を、洗練されたプロフェッショナルな職場コミュニケーションのスタイルに書き直してください。 書き換えの要件： – 共感を示し、相手の立場に立って考える姿勢を示す – 温かみがあり、協力的で、成熟した口調を用いる – 双方にメリットのある結果を重視し、「私たち」や「一緒に」という言葉から始めることを推奨する – 依頼をする前に、相手への価値を提供する – 相手の話を積極的に聞き、肯定する – 共通の目標を設定する – 肯定的なフィードバックを用いる – 「しかし」を「そして」または「同時に」に置き換える – 元の意味を保ちつつ、より専門的で、敬意があり、協力的になるよう書き換える – 書き換えた内容のみを出力し、説明や前置きは含めない。） 自分でショートカットを作成できるので、プロンプトも自由に作成することが可能です。 まとめ Genspark の Speakly を紹介しました。 Speaklyの基本的な動きとしては以下となります。 Speaklyを使った音声入力 テキスト選択し、Speaklyの音声入力によるプロンプト指示 カスタムショートカットを作成し、Speaklyの音声入力内容の独自AI処理 今後、一般企業での利用が進むのかどうかは分かりませんが、音声入力は通常のタイピングに比べて4倍速いことを含め、音声入力によるプロンプト指示、独自AI処理による業務効率化が可能なので、一度 Speakly を試されてみてはどうでしょうか？ ちなみに、Genspark に人気のある Genspark 機能順位（Top10）を教えて、と尋ねると以下の回答になりました。 スーパーエージェント（Super Agent） 「なんでもできるAI司令塔」 AI チャット（Mixture of Agents） 「複数AIが協力し最高の答えを出す」 ディープリサーチ（Deep Research） 「AIが徹底的に調査・分析するリサーチエンジン」 AI スライド（AI Slides） 「プロ品質のプレゼンを瞬時に作成」 電話代行エージェント（Call for Me） 「AIが代わりに電話をかけてくれる」 AI 画像/動画（AI Image/AI Video Generation） 「テキストから画像・動画を生成」 AI シート（AI Sheet） 「データ分析・可視化を自動化」 AI デベロッパー（AI Debeloper） 「自律型コーディングエージェント」 AI ドキュメント（AI Docs） 「プロ品質の文書を即時生成」 AI セクレタリー（AI Secretary） 「メール・カレンダー・タスクを丸ごと管理」 また、次の記事では、Genspark の人気のある機能を紹介しようと思います。
こんにちは、SCSKの松岡です🕸️ Webクローリングおよび名寄せの検証において、AWS lambdaと Amazon Bedrock を活用したデータ収集アーキテクチャを検討した際の試行錯誤を整理しました。 従来のルールベースのクローリングと比較し、生成AIを用いた柔軟な情報抽出を取り入れることで、サイト構造の差異に耐えるデータ収集方式をどのように実現したか、また収集データと既存マスタを突合する名寄せの課題についても紹介します。 背景 データ活用基盤において、外部サイトからの商品情報を収集し、分析や業務活用に利用したいというニーズがありました。特に、複数サイトに分散した商品情報を横断的に収集し、一覧化・比較可能な形で整理することが求められています。 一方で、Webクローリングはサイトごとに構造が異なり、HTMLの変更や表記ゆれの影響を受けやすく、安定したデータ取得が難しいという課題があります。従来のルールベースの実装では、サイトごとに個別対応が必要となり、対象サイトの増加に伴って運用負荷が増大し、継続的な運用が困難になります。 また、収集処理の実行環境についても、特定端末に依存した構成では運用が属人化しやすく、安定したデータ収集基盤としては適さない状況でした。そのため、クラウド上で完結し、既存のワークフロー（例： AWS Step Functions ）に組み込める形で実装することが求められました。 さらに、収集した商品情報をそのまま利用するだけでなく、既存のマスタデータと突合し、サイトごとに同一商品の整理（名寄せ）を行う必要がありました。しかし、商品名や型番の表記ゆれ、情報粒度の違いなどにより、単純な一致条件では対応できず、曖昧一致を前提とした設計が必要となります。 このような前提のもと、Webクローリングと生成AIを組み合わせたデータ収集方式および、名寄せの実現方法について検証を行いました。 構成と選定理由 背景の内容を踏まえ、このような構成でAWS環境でのWebクローリングを実現しました。 サイトごとに構造が異なるWebページから商品情報を収集するため、仮想ブラウザによるクローリング方式を採用しました。これにより、単純なHTTP取得では対応できない動的コンテンツやJavaScriptレンダリングにも対応可能としています。実行環境には、コンテナイメージを利用可能な AWS Lambda を採用し、特定端末に依存しないクラウド上での実行基盤を構築しました。 次に、サイトごとのHTML構造の差異に対応するため、ルールベースではなく、 Amazon Bedrock を用いた生成AIによる情報抽出を採用しました。これにより、ページ構造や表現の違いを吸収しながら、商品名や型番といった必要な情報を柔軟に取得できる構成としています。 また、収集処理をクラウド環境にて実行する運用を見据え、AWS CodeBuildを用いてDockerイメージをビルドし、Amazon ECRへ登録（プッシュ）してLambdaへデプロイを行う構成としました。これにより、環境差異のない再現性の高い運用を実現しています。 コンテナイメージを使用して Lambda 関数をデプロイする さらに、収集したデータはCSV形式で Amazon S3 に出力し、後続の名寄せ処理やデータ活用基盤での利用を前提とした中間データとして蓄積します。本検証では名寄せ処理そのものは後段としつつ、曖昧一致を前提としたデータ構造で保持することを重視しました。 このように、「構造差異への対応」「運用の非属人化」という課題に対して、それぞれ適したサービスを組み合わせることで、柔軟かつ実運用を見据えたWebクローリングの基盤を構成しました。 ※なお、Webクローリングの実施にあたっては、対象サイトの利用規約や過度なアクセスによる負荷の回避、取得データの利用範囲（著作権・利用条件）の確認など、法的および倫理的な観点に十分配慮する必要があります。 気にしたポイント 実際に実装したWebクローリングの、処理順序ごとに気にしたポイントを整理します。 ①収集対象サイトの指定(パラメータ化) Lambda実行時に、対象URLをパラメータとして受け取る構成としました。これにより、単一の関数を使い回し、ジョブネットやワークフローから複数サイトの収集処理を横展開できるようにしています。 固定URLをコードに埋め込むのではなく、実行時に切り替えることで、対象サイト追加時の改修を不要とし、運用の柔軟性を高めています。 { "url": "https://example.com" , "prompt": "商品名と価格を抽出してください。\n列は name, price。\nCSV形式で出力してください。" } また、urlと同様に、後述する生成AIでの解析処理時のpromptについてもパラメータ化しています。これにより、プロンプトの調整のみで対応可能なケースであれば、改修不要で対応可能な設計としています。 ②WebサイトからHTMLの取得 HTML取得にはPlaywrightを採用しました。 Playwright Playwrightは、Microsoftが開発したオープンソースのブラウザ自動操作ライブラリです。Chromium・Firefox・WebKitといった複数ブラウザをプログラムから制御できます。 単純なHTTPリクエストではなく、実際のブラウザを起動してページを描画するため、JavaScriptによる動的コンテンツにも対応可能です。 ブラウザ設定は、動作確認をしながら、以下のような設定に調整しています。 # playwright ブラウザ設定 browser = p.chromium.launch( headless=False, args=[ "--no-sandbox", "--disable-setuid-sandbox", "--disable-dev-shm-usage", "--disable-gpu", "--single-process", "--ignore-certificate-errors" ], env={"DISPLAY": os.environ["DISPLAY"]} ) context = browser.new_context( ignore_https_errors=True, locale="ja-JP", timezone_id="Asia/Tokyo", user_agent=( "Mozilla/5.0 (Windows NT 10.0; Win64; x64) " "AppleWebKit/537.36 (KHTML, like Gecko) " "Chrome/124.0.0.0 Safari/537.36" ), viewport={"width": 1920, "height": 1080} ) context.set_default_navigation_timeout(90_000) context.set_default_timeout(30_000) page = context.new_page() page.set_extra_http_headers({"Accept-Language": "ja,en-US;q=0.9,en;q=0.8"}) LambdaはGUIを持たないため、ブラウザ描画のためにXvfbによる仮想ディスプレイを用意しています。本実装では、ヘッドレスブラウザではなく、仮想ディスプレイ上でブラウザを起動（疑似ヘッドフル）する構成としています。これにより、サイト側の描画差異や要素の非表示問題を回避し、安定したHTML取得を実現しています。 動作を安定させるために、不要なリソース消費をおさえるための無効設定を入れています。 サイト側に、人間が操作している通常のブラウザだと思わせるためのコンテキスト設定をしています。 レスポンシブサイトでは解像度によりメニューや要素が折りたたまれるため、画面解像度を1920×1080に固定しています。 Accept-Languageの指定で日本語表示を優先し、取得データの言語揺れを防止しています。 タイムアウト設定を明示的に指定し、操作のハング防止や、海外サイトアクセス時のネットワーク遅延を許容しています。 ③取得したHTMLの解析 取得したHTMLは、従来のようなルールベースで解析するのではなく、 Amazon Bedrock を用いて解析させています。 本実装では、モデルにAnthropic Claude 3.5 Sonnetを採用しました（2025年検証当時の最新バージョン）。検証の結果、HTMLが適切に取得できている前提であれば、生成AIの知能由来による商品情報の抽出漏れはほとんど発生せず、実用レベルの精度で抽出可能であることを確認しました。※実際の精度は、対象サイトの構造や収集対象に依存するかと思います。 Amazon Bedrock ユーザーガイド Anthropic Claude Messages API 解析の設定にあたり、以下の点を考慮しています。 temperature=0.0とすることで、出力の揺らぎを抑え、同一入力に対して安定した結果を得られるようにしています。 HTML本文はそのまま投入するとトークン上限に達する可能性があるため、文字数を制限しています。これにより、不要なコスト増加や処理遅延を防止しています。 Bedrockの推論プロファイルを利用することで、モデル呼び出し時のリソース管理を柔軟に制御できる構成としています。 推論プロファイルを使用してモデル呼び出しリソースを設定する プロンプトは「ユーザープロンプト」と「システムプロンプト」に分けて設計しています。 ユーザープロンプトは、Lambdaのパラメータとして外部から指定可能とし、対象サイトや抽出内容に応じて柔軟に変更できる構成としています。一方で、システムプロンプトでは出力形式を厳密に制御し、後続処理で扱いやすいデータ形式を担保しています。 # システムプロンプト sys = SystemMessage( content=( "あなたはWebページ本文から情報を抽出するツールです。" "出力は必ずCSVのみ（ヘッダなし、カンマ区切り、LF改行）。" "説明文や前置きは禁止。価格が無い場合は「記載なし」と明記してください。" ) ) このように制約を明示することで、生成AIの自由度を抑えつつ、構造化データとして利用可能な形式で出力させています。 改善ポイント ブラウザ操作が必要なサイトへの対応 本実装では、Playwrightによるブラウザ操作と生成AIによる情報抽出を組み合わせることで、一定の汎用性を持ったWebクローリングを実現しています。 しかし一部のサイトでは、単純なページ遷移やテキストベースのクリックでは対応できず、明示的なブラウザ操作が前提となるケースが存在します。 具体的には以下のようなケースです。 初回アクセス時にポップアップ広告や同意画面が表示され、操作しないとページが閲覧できない JavaScriptによる動的表示の後、ボタン操作によるメニュー切り替えが必要 タブ切り替えやアコーディオン展開など、ユーザー操作を前提としたUI構造 これらのケースでは、仮想ブラウザ起動後にサイト特性に応じた操作が必要となります。Playwrightを用いて個別に実装することは可能ですが、サイトごとに処理を作り込む必要があり、これまでの「汎用的なクローリング」という思想とトレードオフになります。 この課題に対するアプローチとして、 browser-use のようなライブラリを利用することで、ブラウザ操作自体を自然言語で制御する仕組みの導入が考えられます。 browser-use browser-useは、生成AIがブラウザを直接操作するためのオープンソースライブラリです。自然言語による指示を解釈して、クリックなどのアクションを自律的に実行してくれます。 これを導入することで、ポップアップの回避や複雑なメニュー遷移といった動的なUI操作をAIがその場で判断して完結できるようになり、サイトごとに個別コードを追加する手間を解消してくれる可能性があります。 収集した商品情報とマスタ情報の名寄せ 本記事でここまで触れていませんでしたが、収集した商品情報は、既存のマスタデータと紐付ける名寄せ処理を行うことで、実際の業務活用につなげることを想定しています。 しかし、複数のWebサイトから収集した商品情報は、サイトごとに表記ゆれ（例：「iPhone 15」と「アイフォン15」）や型番の記述粒度が異なるため、単純なID一致では突合できないケースが多く存在します。 この、曖昧な条件での名寄せを実現するためには、様々なアプローチが考えられます。 Pythonによるカスタムロジックの実装：Levenshtein距離などを用いた文字列類似度の算出 Pythonによるカスタムロジックの実装：ベクトル化による文脈ベースの類似度検索（Embedding） AWSマネージドサービスの活用：AWS Entity Resolutionを利用したルールベース／MLベースのマッチング AWS Entity Resolution は、AWS上のデータに対して、ルールベースおよび機械学習ベースのマッチングをスケーラブルに提供するサービスです。 AWS Entity Resolution 本検証では、業務ロジックに応じた柔軟なカスタマイズ性を重視し、Pythonベースでの名寄せロジックの検証を実施しています。 一方で、Entity Resolutionについても2025年初旬に検証を行っていました。当時は機能面で発展途上と判断し採用を見送りましたが、現在は高度なルールベースのファジーマッチング機能が強化されており、改めて適用可能性を検討したい領域です。 AWS Entity Resolution の高度なルールベースファジーマッチングを使用して不完全なデータを解決する まとめ 本記事では、Webクローリングと生成AIを組み合わせたデータ収集基盤について、設計から実装、改善検討までの試行錯誤を整理しました。従来の構造依存のクローリングから、生成AIによる柔軟な情報抽出へ転換することで、サイト構造差異に対する耐性を向上させることができました。一方で、ブラウザ操作の高度化や名寄せの精度向上といった課題も残っており、今後はAIによる操作制御やマネージドサービスの活用も含め、さらなる実用化に向けた検証を進めていきたいと考えています！ (宣伝) クラウドデータ活用サービス 今回ご紹介した内容は、SCSKで提供しているクラウドデータ活用サービスの中で扱っているテーマの一部になります。 お客様のデータ活用状況に応じて、基盤構築から可視化、データ連携、データマネジメント、高度データ活用までを段階的にご支援しています！ ご関心あれば、以下のサービスページもご参照ください。 クラウドデータ活用サービス｜サービス｜企業のDX戦略を加速するハイブリッドクラウドソリューション クラウドデータ活用サービスは、お客様のデータ活用状況に合わせ、適切なご支援が可能です。 www.scsk.jp
こんにちは、SCSKの松岡です📊 今回は、データの可視化・分析において、Amazon Redshiftを用いて事前集計アーキテクチャの見直しを行った際の試行錯誤を整理しました。 また、データマネジメントの観点で、Amazon Sagemaker (Amazon Datazone) を用いて改善できるポイントについてもご紹介します。 背景 データ活用基盤を構築するにあたり、データの可視化・分析のために、「データマートとして、どこでデータを加工・集約するか」は重要な設計ポイントの1つです。 BIツールは可視化や分析に優れる一方で、データ量の増加や分析要求の高度化に伴い、複雑な結合や集計処理を担わせた場合、 処理時間やレスポンスに影響が出る 可能性があります。そのため、データの加工・集約処理をどのレイヤーで実施するかは、性能と運用性の両面から慎重に設計する必要があります。 Qlik Cloudを用いたデータ可視化を実現したい 複数システムから収集したデータを統合した分析がしたい データ量が大きく、結合・集計処理が複雑 レスポンス性能が重要 ソースシステムのデータ品質にばらつきがある このような前提のもと、PoCにてデータマートの実現方法と構成の妥当性を検証しました。 構成と選定理由 Why Amazon Redshift ? データマートの構築および事前集計の実行基盤としてAmazon Redshiftを採用しました。 BIツールに集計処理を寄せる構成はシンプルである一方、データ量の増加や複雑な結合処理を伴う場合、レスポンスや安定性に影響が出る可能性があります。そのため、本構成では データマート側で集計処理を実施し、BIツールは可視化に特化させる方針 としました。 具体的には、Redshift上でデータマートテーブルを構築し、事前集計を行うことで、Qlik Cloud側の処理負荷を軽減しています。 また、複数AWSアカウントにデータが分散していたため、Redshiftのデータ共有（Data Sharing）機能を活用し、各アカウントのDWHデータを横断的に参照しています。 この機能により、データをコピーすることなく他アカウントのデータを参照可能であり、参照元クラスターのコンピューティングリソースに影響を与えない形でデータ統合を実現できます。 参考：Amazon Redshift でのデータ共有 さらに、Redshift上で構築したマートテーブルは、日次バッチ処理により洗い替えで再生成し、Amazon S3へ出力しています。マート構築時には、ソースデータのばらつきを考慮したクレンジング処理も併せて実施しています。 出力されたS3上のデータは、Qlik Cloudから参照・取り込みを行うことで、BIツール側では軽量なデータセットとして扱うことが可能となります。 AWS内部ネットワークを通じてAmazon S3に接続する |Qlik Cloud ヘルプ 気にしたポイント 本PoCにおいては、データマートテーブルを設計・実装するにあたり、特に以下の観点を重視して構築を行いました。 前提として、本設計はデータオーナーやデータアナリストとは異なる立場から、データマートの構造および処理方法を定義する役割として実施しています。 データ品質の観点 複数のソースシステムからデータを取得し結合処理を行う場合、同一名称のカラムであってもコード体系や採番ルールが異なるケースが存在します。そのため、キー結合を実装する前に、結合率の検証やコード分布の確認を実施し、不整合の有無を定量的に把握しました。 また、システム仕様だけでは判断できない部分については、データオーナーへのヒアリングを通じて業務上の意味を確認し、結合条件の妥当性を担保しています。 加えて、個々のデータ値レベルでのクレンジングも重要なポイントです。実データには、日付フォーマットの不整合や、「00000000」のようなテストデータ・異常値が混在しているケースが確認されました。これらをそのままマートに取り込むと分析結果に影響を与えるため、検知・除外・補正のいずれかの対応が必要となります。 これらのクレンジングについては、ソースシステム側で修正するのか、データマート作成時に補正するのか、あるいはフィルタリングにより分析対象から除外するのかといった複数の選択肢が存在します。そのため、一律のルールとはせず、データの特性や業務影響を踏まえて個別に方針を整理し、データオーナーおよびデータアナリストと合意の上でクレンジングルールを設計しました。 データモデルの観点 データモデルおよびテーブル間のリレーションについて、テーブル構造はER図として整理し、結合対象のテーブル間の関係性（カーディナリティ）が1対1または1対多で成立しているかを事前に確認しました。 特に注意が必要なのが、多対多の関係を持つテーブル同士の結合です。結合キーに対して双方のテーブルに複数レコードが存在する場合、結合処理ではそれらの組み合わせがすべて生成されます。例えば、片方に200件、もう片方に400件のレコードが存在すると、結果は単純な加算ではなく200×400＝80,000件となり、元データ以上にレコード数が増加します。このように、結合はカーディナリティに応じてレコード数が掛け算的に増加する性質を持つため、多対多のまま結合するとデータ量の爆発的増加や集計値の歪み、処理性能の劣化を引き起こす懸念があります。 そのため、設計時には各テーブルのデータ粒度を明確に定義しました。また、多対多の関係を避けられない場合には、中間テーブルを別途設計して関係性を分解することで、データの整合性と可読性を担保することも検討しています。 改善ポイント 今回のように複数システムのデータを統合してデータマートを設計する場合、事前に各テーブルのコード体系やデータ品質上の注意点を把握することが重要となります。こうした課題に対する改善策として有効なのが、データカタログの活用です。 近年では、 Amazon Web Services が提供する Amazon DataZone をベースとしたカタログ機能が、 Amazon SageMaker 上の「SageMaker Catalog」として統合的に利用可能となっています。この仕組みを用いることで、複数AWSアカウントに分散したデータ資産（例：Redshiftのテーブル）を横断的にカタログ化し、一元的に可視化することができます。 データオーナーやデータ基盤管理者は、自身が管理するテーブルに対して、コード体系やカラム定義、利用上の注意点といったメタデータをカタログ上に登録します。これにより、利用者は事前にデータの意味や制約を把握した上で利用することが可能となり、結合条件の誤りやデータ解釈のズレを未然に防ぐことができます。 このように、データカタログを活用することで、今回のように個別に確認していたデータ品質や仕様の把握を仕組みとして標準化することができ、データマート設計の効率化と品質向上の両立が期待できます。 Amazon SageMaker Catalog 「SageMaker Catalog」では、生成AIを活用したメタデータの自動補完やセマンティック検索により、データの発見性が大幅に向上します。また、ビジネス用語集やメタデータ管理機能により、データの意味や利用上の注意点を業務文脈で整理することが可能です。さらに、データのリネージ（データの流れ）を可視化することで、どのような加工を経て生成されたデータかを追跡でき、分析結果の信頼性向上につながります。加えて、データ品質のモニタリング機能により、欠損率や異常値などの品質指標を継続的に把握することも可能です。 まとめ 本記事では、データマートをどのレイヤーで構築するかという設計判断に対し、Amazon Redshiftを用いた事前集計アーキテクチャを採用することで、BIツールの負荷軽減と安定した分析基盤の実現を目指しました。集計処理をデータマート側に寄せることで、レスポンス性能を確保しつつ、可視化ツールの役割を明確に分離することができました。 一方で、データマート設計においては、単なるデータ加工ではなく、データ品質やカーディナリティ、データ粒度といった観点を踏まえた設計が不可欠でした。特に、多対多の関係によるデータ増幅や、コード体系の不整合といった問題は、事前の検証と関係者間での調整が重要でした。 さらに、こうした設計・確認のプロセスは、データカタログを活用することで効率化・高度化が可能です。メタデータや業務知識をカタログとして蓄積・共有することで、データの理解と活用を組織的に支援でき、データマート設計の品質向上にもつながります！ (宣伝) クラウドデータ活用サービス 今回ご紹介した内容は、SCSKで提供しているクラウドデータ活用サービスの中で扱っているテーマの一部になります。 お客様のデータ活用状況に応じて、基盤構築から可視化、データ連携、データマネジメント、高度データ活用までを段階的にご支援しています！ ご関心あれば、以下のサービスページもご参照ください。 クラウドデータ活用サービス｜サービス｜企業のDX戦略を加速するハイブリッドクラウドソリューション クラウドデータ活用サービスは、お客様のデータ活用状況に合わせ、適切なご支援が可能です。 www.scsk.jp
管理者
