TECH PLAY

SCSKクラウドソリューション

SCSKクラウドソリューション の技術ブログ

1236

こんにちは! AIを業務に活用するようになり、AIセキュリティについて、気になっている方も多いのではないでしょうか。 本記事ではAIセキュリティの概要と、それに対するCato Networks社の新たなソリューションである 「Cato AI セキュリティプラットフォーム」 について紹介していこうと思います。 ぜひ最後までご覧いただけますと幸いです。   はじめに 企業にとって、AIの導入はもはや未来の話ではなく、今、ここにある現実となっています。 ChatGPTなどの生成AIやエージェント型AIの普及により、企業のあらゆる部門でAIツールが活用され始めました。 しかし、このAIの急速な普及には大きな課題が付き纏っています。 それが、 企業のAI利用を“可視化・制御・保護”するためのセキュリティ である 「AIセキュリティ」 についての課題です。 本記事では、AIセキュリティの現状の課題について触れたうえで、それを解決するソリューションである 「Cato AI セキュリティプラットフォーム」 について、解説していきたいと思います。   AIセキュリティが直面する課題 生産性向上の目的で企業にAIツールが次々と導入されていく一方で、いくつかの重要なセキュリティ課題が指摘されており、 その安全性に関する統制が追いついていない現場も多いのではないでしょうか。 以下はAIセキュリティの主な課題です。それぞれについて簡単に解説していきます。 No 課題 例 1 シャドーAI 従業員が会社で許可されていない独自AIツールを無許可で利用 2 情報漏洩 プロンプトに入力した個人情報が他者への出力として表示される 3 ガバナンスとコンプライアンス 企業が社員のAI利用状況について把握できていない 4 自社製AIへの攻撃と脆弱性 LLMを搭載した自社製アプリに対するプロンプトインジェクション   ①シャドーAI 現在、多くの企業が直面している問題が シャドーAI です。 これは、企業が正式に許可していないAIツールを、従業員が個人的に利用してしまう状況を指します。 例えば以下のような例が挙げられます。 ・個人アカウントのAIツールの社内利用 ・用途特化型のマイナーAIサービスの利用 基本的に企業では、 チャット内容を学習に利用しない、オプトアウト設定 を行った商用版のAIツールの利用をルールとしているかと 思いますが、こういったオプトアウト設定やセキュリティ設定の緩いシャドーAIの利用により、意図せず、情報漏洩が発生するリスクが増大します。 以下のサイトでわかるように、 2026/4月時点で約48,000種ものAIサービス が登録されており、その中には先述したようなセキュリティ設定が甘いものも多数あると思われます。 There’s An AI For That® — No. 1 Website For AI Tools このように、昨今の爆発的なAIツールの増加により、出自不明なAIも増加したことから、シャドーAIへの対策はますます重要になっているといえるでしょう。 ②情報漏洩 先述したシャドーAIにも関連しますが、AI利用において特に懸念されるのが データ漏洩リスク です。 具体的には以下のような行為を、セキュリティ設定が不十分なAIツールに対して行うことが挙げられます。 ・プロンプトに機密情報を書いてしまう ・機密ファイルをアップロードする ・顧客情報を入力する 上記の結果 ・入力された情報がAIの学習に使われる ・他ユーザーの出力に機密情報が混入する といった重大なデータ漏洩につながる恐れがあります。 実際、多数のAIに個人情報を入力した結果、個人情報がネット上にばらまかれるといった被害も考えられます。 (事例は「AI 個人情報 流出」あたりで検索するとたくさんヒットしますので、ご自身でご確認ください) 特に 特定用途に特化した新興のAIサービス等 では、データ管理やセキュリティが整備されていないケースもあるため、 十分な注意が必要になります。   ③コンプライアンスとガバナンス AI利用には コンプライアンス・ガバナンスの観点 も重要です。 日本国内ではAIに関する規制はまだ限定的ですが、海外では規制が進み始めています。 代表例が EUのAI Act です。 EUの国々では ・従業員の評価 ・採用判断 ・社会的スコアリング などをAIに任せることは 法令違反になる可能性 があります。 他にも、各国のデータ保護規制、そして業界固有の規制など、企業はこれらに準拠した形でAIを利用しなければなりません。 上記のように企業は様々な規制に準拠したうえでAIを利用する必要があり、 そのためのコンプライアンス・ガバナンス整備が必要となります。   ④ 自社製AIへの攻撃と脆弱性 生成AIツールの利用だけでなく、自社製のAIに対しても攻撃や脆弱性に対する防御が必要となります。 具体的にはAIモデルの制限を迂回して、本来は禁止されているタスク(例えば、ランサムウェアの製作方法の説明)を実行させる ジェイルブレイク や、入力されたプロンプトに悪意のある命令を埋め込み、AIの動作を乗っ取るという プロンプトインジェクション といったAI特有の攻撃手法が次々と開発されています。 これらから自社製AIへの攻撃を防ぐため、  AIシステム自体を保護する仕組み が必要になります。   Cato AIセキュリティプラットフォームとは 上記で挙げたAIセキュリティの課題に対して、Cato Networks社が提供するのが、 「Cato AIセキュリティプラットフォーム」 となります。 Cato Networksは、元来別々に構築されていたネットワークとセキュリティを、クラウド上で統合して提供する SASE(Secure Access Service Edge)プラットフォーム を提供する企業です。 このように、ネットワーク・セキュリティ領域に強みを持つ企業が、 AIセキュリティの専門企業 である Aim Security を買収したうえで、 既存のCatoプラットフォームに組み込む形で提供するのが上記となります。 主に 2つのアプローチ でAIに対するセキュリティを 包括的 に保護します。 ①ユーザー向けAIセキュリティ まず一つ目のアプローチはユーザー向けAI、つまり 「AIを利用する」 ことに対するセキュリティアプローチです。 具体的には、以下のような機能を提供します。 No. 機能 説明 1 シャドーAIの検出 利用中のすべてのAIをツールごとに可視化 2 プロンプト&アクションの可視化 ユーザーの プロンプト・アクションを可視化 し、 許可される操作を制御 3 AIインタラクションDLP(Data Loss Prevention) 機密情報を自動的にマスキングしたり、高リスク情報の送信をブロックしたりすることで、 意図しない情報漏洩を防止 4 エージェント型AIの可視化(未実装・近日公開予定) データやシステムにアクセスするAIエージェントを 発見・監視   上記の通り、 先述したAIセキュリティ課題(シャドーAI、情報漏洩、ガバナンス等) に対して、 ツールの可視化、 セキュリティポリシーを用いたプロンプトの制御、 機密情報のマスキング等 を通じて、 包括的な対処 が可能です。 これらについて、いずれも Catoのダッシュボード上で、設定及び可視化 が実施できます。 なお、これらの機能の利用については、 Catoクラウドを経由して行われる通信 に対して提供可能となります。 そのため利用にあたっては既存の Catoクラウド利用ユーザー は 設定の上即時利用 できることも大きなメリットといえるでしょう。 また、 本機能のみを利用したいというニーズ にも、 専用のブラウザプラグイン導入 により対応可能となっております。 設定内容の詳細は、別記事でまた紹介させていただきます。   ②アプリケーション向けAIセキュリティ 二つ目のアプローチはアプリケーション向けAI、つまり 「独自に構築したAI」 に対するセキュリティアプローチです。 具体的には、以下のような機能を提供します。 No. 機能 説明 1 AIアプリ&エージェント・インベントリ (未実装・近日公開予定) すべてのAIアプリケーションとエージェントAIのワークフローを発見 2 AIファイアウォール(ランタイム保護) プロンプトインジェクション 、 モデルの不正利用 、 不正なエージェントのアクション をLLMに届く前にブロック 3 データ窃取防止 AIのAPIコールや応答を介した機密データの流出を阻止   上記より、企業によっ て独自に構築したAIアプリケーション に対しても、包括的なセキュリティ対応を実施しています 。 特に AIファイアウォール機能の導入で 、不正なユーザーリクエストを以下のように LLMに届く前に検出 、 防御できる点 が嬉しいですね。 これにより自社で構築したAIアプリケーションについて、 プロンプトインジェクション や ジェイルブレイクの防止 が実現できます。 ユーザー ↓ API ↓  AIファイアウォール (ポリシーチェック・プロンプトインジェクション検出等) ↓ LLM(ファイアウォールを通過したもののみ到達)   また検知するポリシーについては、 独自に設定 も可能なようです。 なお、設定については、アプリケーション側と、Cato側でそれぞれ必要なので、別記事でまた紹介させていただきます。   まとめ AIセキュリティは、企業がAI時代を生き残るための必須の課題となっています。シャドーAI、データ漏洩、規制遵守、そして新たな攻撃脅威に対応するためには、 「利用するAI」 と 「構築したAI」 の両方を保護する包括的なアプローチが求められています。 そうした状況において、今回紹介させていただいた Cato AIセキュリティプラットフォーム は有力な選択肢になるのではないでしょうか。 包括的なAIセキュリティ保護 はもちろん、 Catoと統合したダッシュボード で 各種セキュリティポリシーの設定 や、 AIの利用状況を簡単に可視化 できる点も、ユーザーにとっては魅力的ですね。 また今後、具体的な設定内容をまとめた記事も順次公開していく予定ですので、気になった方はぜひそちらもご覧いただければと思います。 最後までご覧いただき、ありがとうございました。
初めまして。入社3年目になります、SCSK竜崎斗磨と申します。 TechHarmony初投稿となります!これから少しずつ、皆様方にAWSのお役立ち情報を発信できれば幸いです。 今回は、実際の案件で直面した課題から得た「シンプルかつ効果的な、IAMユーザーのログイン検知」の知見を共有したいと思います! 今回の話の焦点としては、rootユーザー”以外”のIAMユーザーになります。 概要・構成 案件の中で、「rootユーザー 相当 の強い権限を持つIAMユーザーがログインした際に、確実に検知・通知したい」という要件がありました。 AWS環境におけるログイン検知といえばrootユーザーの監視が基本ですが、本番環境の保守などで強力な権限を持つIAMユーザーが存在する場合、そのユーザーの挙動を監視することもセキュリティ上非常に重要です。 今回は「AWS User Notifications」を使用して、この仕組みをシンプルに構築しました。構成図は以下の通りです。 AWS User Notifications内で通知設定を作成すると、裏側でEventBridgeのルールが自動作成され、イベントをフックして指定のEmailへ通知を飛ばしてくれます。 没にした構成案 ログイン検知の実装にあたり、AWSにおける定番の通知アーキテクチャもいくつか検討しました。しかし、コストや運用面から今回は見送っています。 CloudWatch Logs × メトリクスフィルター × SNS 没理由(コスト懸念): Trail LogをCloudWatch Logsに保管することになるため、ログ保管に対する料金が膨らむ懸念がありました。 CloudTrail × EventBridge × SNS 没理由(設定の非効率さ): rootユーザーのログインイベントは 米国東部(バージニア北部 / us-east-1) に記録される仕様がありますが、 一般のIAMユーザーのログインは「 ログイン操作が行われた各リージョン 」で発生 します。これを拾うために、全リージョンで手動でEventBridgeルールを設定・管理するのは運用上、非常に非効率です。 S3 × Lambda × SNS 没理由(Lambdaの無駄撃ち): Lambdaにイベントが渡ってくる前の段階でユーザーを限定することができず、全管理イベントがLambdaに流れてきてしまいます。Lambda側で都度ユーザーを判別することになり、実行が「垂れ流し状態」になるため却下しました。 設定方法 それでは、AWS User Notificationsを使った設定手順を解説します。 前提として、マルチリージョンのCloudTrailの証跡設定をオンにしている必要があります。 AWSコンソールからCloudTrailの証跡設定を行い、「管理イベント」用の証跡を作成することで、 上記の前提に記載した設定が可能となります。 状態として、①マルチリージョンの証跡が「はい」②管理イベントが収集対象となっていれば問題ありません。 証跡設定が確認できたら、AWS User Notificationsのコンソールから通知ルールを作成します。 イベントルール設定 AWS のサービスの名前:AWS Console Sign-in イベントタイプ:サインインイベント(または、 AWS Console Sign In via CloudTrail ) リージョン:使用しているアカウントで有効になっているリージョン全てを選択(※1) 高度なフィルター(オプション):<対象ユーザーに条件を絞ったJSON>(※2) (※1)有効になっていないリージョンは、選択しなくて問題ありません。 以下、参考までに、AWS社からのメッセージになります。 現在オプトインリージョンにつきましては、 リージョンサインインエンドポイント (<region>.signin.aws.amazon.com) にアクセスした場合は、 グローバルサインインエンドポイント (signin.aws.amazon.com) にリダイレクトされる動作となっておりました。 そのため、ConsoleLogin のイベントを検知するためには、 デフォルトで使用可能なリージョンにのみルールを作成すれば十分であり、 User Notifications の非対応のリージョンにつきましては考慮いただく必要がない状況でございます。 上記メッセージより、仮に新規リージョンが追加された場合でも、別途オプトイン、つまり対象リージョンを手動で有効にする必要があるため、特に懸念することは無いという結論になります。 (※2)以下に、1人の特定ユーザーを指定したJSONの例を記載しております。 複数ユーザー指定も可能です。 { "detail": { "userIdentity": { "arn": [ "arn:aws:iam::000000000000:user/xxxx" ] } } } Email承認 配信チャネルにEmailを設定すると、対象のEmail宛に承認メールが届きます。 以下画像の、 Verify email より、承認してください。 ステータス確認 通知設定、対象リージョン、及び配信チャネルが全てアクティブになっていることを確認します。   動作確認 実際に、監視対象としたIAMユーザーでマネジメントコンソールにログインしてみます。 対象ユーザーでログイン後、指定したEmail宛に以下の通知が届いていれば、成功しています。 まとめ 今回はAWS User Notificationsを活用して、高権限IAMユーザーのログインをシンプルに検知する方法をご紹介しました。 複雑なアーキテクチャを組まなくても、マネージドサービスをうまく組み合わせることで、コストや運用負荷を下げつつセキュアな環境を構築できます。 今後も得た学びや、案件での実践的な知見をこのブログで発信していきたいと思います。 最後まで読んでいただき、ありがとうございました!
以前、運用高度化のためにGoogle CloudでAIチャットボットを作成したのですが、MicrosoftではどのようなAIツールがあるのか…気になったので調べてみました。 本記事では、「Microsoft Copilot Studio」と「Azure AI Foundry」の機能や特徴を徹底比較します。ぜひAI開発ツール選定の参考にしてください。 Microsoft Copilot Studioとは? 企業が独自のAIアシスタント(Copilot)を作成したり、既存の「Microsoft Copilot for Microsoft 365」を自社向けにカスタマイズしたりするための ローコード開発プラットフォーム です。 以前は「Power Virtual Agents」と呼ばれていたサービスが、最新の生成AI(ChatGPTのような大規模言語モデル)を組み込んで大幅に進化・改称したものです。 概要 - Microsoft Copilot Studio Microsoft Copilot Studioを使用してインテリジェントな AI エージェントを簡単に構築できます。 ローコード インターフェイスを使用して、プラットフォーム間でエージェントを作成、カスタマイズ、展開します。 learn.microsoft.com 最大の特徴(なぜローコード・ビジネス向けなのか?) プログラミング知識が不要(ローコード/ノーコード) 画面上のドラッグ&ドロップや、自然言語でAIアシスタントを構築できます。エンジニアだけでなく、業務部門の担当者(人事、総務、営業企画など)が自らAIを作ることが可能です。 自社の独自データとの連携が簡単(RAGの実現) Copilot Studioを使えば、自社のWebサイト、SharePoint内の社内マニュアル、PDF文書などを指定するだけで、「自社の独自情報に基づいて回答するAI」を数分で作れます。 業務の自動化(アクションの実行)   「Power Automate」などのツールと連携し、「社内システムへデータを入力する」「休暇申請を提出する」「メールを送信する」といった実際の業務プロセスをAIに代行させることができます。 Microsoft 365のCopilotを拡張できる すでにTeamsやWordなどで使っている「Copilot」に対して、自社独自のプラグイン(拡張機能)を追加し、より自社の業務にフィットした有能なアシスタントに育てることができます。 ビジネス導入におけるメリット 開発スピードとコストの大幅削減 ローコードであるため、社内の人間が数日〜数週間で構築・改善のサイクルを回せます。 エンタープライズ級のセキュリティとガバナンス Microsoftの堅牢なセキュリティ基盤の上で動くため、入力したデータや社内情報が外部のAI学習に利用されることはありません。IT部門がしっかり管理・統制を効かせることができます。 「会話のシナリオ」と「生成AI」のいいとこ取り 「必ずこの順番で質問して、手続きを進める」といった厳格なルール(シナリオベース)と、「マニュアルから自由に回答を生成する」(生成AIベース)を自由に組み合わせて、柔軟かつ正確なAIを作れます。 Azure AI Foundryとは? Azure AI Foundryは、開発者やデータサイエンティストが、高度なカスタマイズを伴う独自の生成AIアプリケーションやAIエージェントを設計・構築・評価・運用するための、 統合的なプロコード開発プラットフォーム です。 ※以前は「Azure AI Studio」と呼ばれていたサービスを中心に、MicrosoftのAI開発ツール群を統合し、リブランディングしたプラットフォームです。 Microsoft Foundry とは - Microsoft Foundry Microsoft Foundry は、開発者が安全で安全で責任ある方法で AI を使用してイノベーションを推進し、未来を形成できるようにする信頼できるプラットフォームです。 learn.microsoft.com 最大の特徴(なぜプロコード・高度なAI開発向けなのか?) 世界中のあらゆるAIモデルを自由に選べる・育てられる OpenAIの「GPT-4」だけでなく、Metaの「Llama」、Googleのモデル、Microsoftの軽量モデル「Phi」など、数千種類のAIモデル(モデルカタログ)から用途やコストに合わせて最適なものを選択できます。 複雑で大規模なRAG(自社データ連携)の完全制御 Copilot Studioでも自社データ連携(RAG)は可能ですが、AI Foundryでは「数百万件の文書」「複雑な社内データベース(SQLなど)」を対象にした、高度な検索システムを構築できます。 プロンプトフロー(複雑な処理の流れの構築) 「ユーザーの質問を受け取る」→「データベースを検索する」→「Pythonコードで計算処理をする」→「AIに回答を作らせる」といった、複雑な処理のパイプラインを、視覚的なツールとコードを組み合わせて緻密に設計・デバッグできます。 厳格なテストと「責任あるAI」の実装 Azure AI Foundryには、AIの回答精度を定量的に評価したり、不適切な入出力を自動でブロックしたりする、プロフェッショナル向けの強力なテスト・安全管理機能が備わっています。 ビジネス・開発におけるメリット 圧倒的な自由度とカスタマイズ性   プロンプトから検索アルゴリズム、使用するモデルに至るまで、開発者がすべてをコントロールできます。 スケーラビリティ(拡張性)とパフォーマンス Microsoft Azureの強力なクラウドインフラストラクチャ上で動作するため、世界中の何百万人ものユーザーが同時にアクセスするような大規模な商用アプリケーションにも耐えられます。 エンタープライズのセキュリティとコンプライアンス 企業の閉域網(VNet)の内部だけでAIシステムを完結させるなど、金融機関や政府機関でも採用されるレベルの極めて厳格なセキュリティ要件を満たすシステム構築が可能です。 Microsoft Copilot Studio と Azure AI Foundry の比較表 比較項目 Microsoft Copilot Studio Azure AI Foundry 一言で言うと 「手軽にAIアシスタントを作るツール」 「AIシステムを根本から開発するツール」 主な利用者 業務部門、IT管理者、プロメーカー 開発者、データサイエンティスト、AIエンジニア 必要なITスキル プログラミング不要 (ドラッグ&ドロップ、自然言語で指示) プログラミング必須 (Python、C#などを用いたコーディング) プラットフォーム SaaS(Microsoftが管理) PaaS(Azureサブスクリプション内で自己管理) 展開チャネル Teams、Outlook、Webなど API、Functions、Web、コンテナなど 主なビジネス活用シーン(ユースケース) Microsoft Copilot Studio Copilot Studioで作ったAIは、社内外のさまざまな場面で活躍します。 【社内向け】社内ヘルプデスク(情シス・人事・総務) 「交通費の精算方法を教えて」「パスワードを忘れた」といった社員からのよくある質問にAIが自動回答。マニュアルを読み込ませておけば、担当者の負担が激減します。 【社外向け】カスタマーサポート(顧客対応) 自社製品の取扱説明書やFAQサイトを学習させたAIをWebサイトに設置。24時間365日、顧客の問い合わせに高精度な自然言語で対応します。 【営業支援】社内データ検索アシスタント 「〇〇製品の最新の在庫状況と、過去の提案書を出して」とTeamsでAIに頼むと、社内データベースから情報を引っ張ってきて要約してくれます。 Azure AI Foundry Azure AI Foundryは単なる社内向けチャットボットの枠を超えた、自社のコアビジネスや製品に直結するAI開発で使われます。 【自社製品へのAI組み込み】BtoB/BtoC向けの機能拡張 自社が提供している業務システムやスマホアプリのなかに、「独自のAIアシスタント機能」を開発してAPI経由で組み込むことができます。 【高度な業務自動化】自律型AIエージェントの開発 「在庫管理システム」「会計システム」「メールソフト」など複数のシステムをAIが自律的に横断し、状況を判断して業務を遂行する「エージェントAI」を構築できます。 【専門領域の特化型AI】医療・金融・法務などの専用AI 一般的なAIでは理解できない専門用語や社内独自のルールを、ファインチューニングによって深く学習させた、その業界・企業専用のAI開発ができます。 まとめ Microsoft Copilot Studioは、プログラミング知識がなくても自分たちの業務を助ける「AIアシスタント」を自ら作り出せます。一方で、Azure AI Foundryを使えば、高度なAIシステムを構築することも可能です。 これらを組み合わせて使うこともできるので、組織の目的に合わせて最適なAI開発ツールを選択してみてください!
2024年度にAWS認定資格をすべて取得し、 2025 ALL AWS Certifications Engineers として表彰していただきました! 振り返ってみると、当初の予定を大幅に前倒しした 資格取得RTA のような怒涛のスケジュールでした。 今回は、なぜ実務経験が断片的だった私が全冠を目指したのか、そしてどうやって駆け抜けたのか、その記録を公開します。 挑戦前のスペック:AWS経験は「点」でした 「全冠」と聞くと、さぞかしAWSを使いこなしている人を想像されるかもしれませんが、当時の私の状況はこんな感じでした。 仕事:クラウドネイティブな開発基盤構築チームで、いわゆる「何でも屋」をしているエンジニア 主戦場: Azure、GoogleCloud(仕事の比率はこちらが高め) AWS実務経験: 特定サービスのアプリ部品を1つ作成。あとは、炎上プロジェクトでの技術支援(火消し)にスポット参戦 得意なこと: プログラミング、DevOps関連技術、アプリ開発周り 保有資格: 高度情報(システムアーキテクト、データベーススペシャリスト)、Java資格など AWSに関しては「広く浅く」どころか、特定のスポットだけ激しく触ったことがあるという、非常に偏った知識状態からのスタートでした。 取得動機:あふれるAWSへの想いを形にしたかった 理由はシンプルです。AWSが好きだから。 しかし、世の中はAWSエンジニア戦国時代。人気すぎて競争率が高く、インフラ専任ではない私には、なかなかAWSメインの案件が回ってきませんでした。 「好きなのに、触れない……。この熱意をどうにかして証明したい!」 そう思い立った結果が、「資格で可視化すること」でした。当初は「年2個くらいずつ、ゆっくり取ろうかな」と考えていたのですが、いざ始めると火がついてしまいました。 得意なDevOps分野が意外とスルスル取れたことで弾みがつき、1資格2週間(1・2月は月3個ペース)という怒涛の短期集中モードに突入してしまったのです。 (※よい子の皆さんは、無理のないスケジュールを立ててくださいね!) 攻略ルート:得意を固めてから「専門領域」に挑む 一般的にはSAA(Associate)からSAP(Professional)へ進むのが王道ですが、 私は知識のオーバーラップを意識して、得意な領域からグルーピングして攻略しました。 実際に進んだ順番 1. 基礎・開発系(足場固め) CLF → SAA → DVA → DOP → SOA まずは得意なDevOps周りを固め、勢いをつけました。 2. トレンド・データ系(攻めの姿勢) DEA → AIF → MLS → MLA 新設されたデータ・AI系資格を一気に攻略。 3. インフラ・専門系(最難関の壁) ANS → SCS → SAP 最難関のネットワーク(ANS)をあえて後半に。 最後は集大成としてラスボス的存在のSAPで締めました。 実際に駆け抜けたロードマップ コード 正式名称 レベル 初回取得日 コメント CLF-C01 AWS Certified Cloud Practitioner Foundational 2023-01-28 AWSはじめ SAA-C03 AWS Certified Solutions Architect Associate 2024-02-12 穏やかに取得 DVA-C02 AWS Certified Developer Associate 2024-06-26 ウォーミングアップ期間 DOP-C02 AWS Certified DevOps Engineer Professional 2024-12-20 覚醒 SOA-C02 AWS Certified SysOps Administrator Associate 2025-01-10 ここからRTAスタート DEA-C01 AWS Certified Data Engineer Associate 2025-01-25  ↓ AIF-C01 AWS Certified AI Practitioner Foundational 2025-01-29  ↓ MLS-C01 AWS Certified Machine Learning Specialty 2025-02-06  ↓ MLA-C01 AWS Certified Machine Learning Engineer Associate 2025-02-13  ↓ ANS-C01 AWS Certified Advanced Networking  Specialty 2025-02-26  ↓ SCS-C02 AWS Certified Security Specialty 2025-03-05  ↓ SAP-C02 AWS Certified Solutions Architect Professional 2025-03-17 ゴール!! 勉強方法:三種の神器 短期集中を成功させるために、効率を最優先しました。 1. AWS Black Belt (動画/資料) 知らないサービスは、まずこれ。公式の「正解」を脳に叩き込みます。 2. Udemy (動画教材) 特に未知の領域(AI、ネットワーク)は、ハンズオン付きの教材で「触った感触」を擬似体験しました。 3. オンライン問題集 「試験の勘」を養うために、仕上げとして数周。間違えた部分は公式ドキュメントに戻って徹底的に潰しました。 挑戦中に感じた「光と影」 苦しかったこと:最難関ネットワークの壁 一番しんどかったのは、やはりANS(ネットワーク)です。 開発をしていると不具合の原因として立ちはだかることもあるネットワークですが、実務で使ったことのない細かいサービス仕様には本当に苦戦しました。 また、MLA(機械学習エンジニア)も普段の業務と距離があったため、根気強く動画と問題集を往復する日々でした。 楽しかったこと:アーキテクチャの万華鏡 逆に一番楽しかったのは、試験を通じて膨大なアーキテクチャ事例に触れられたことです。 普段は特定の基幹システムを見ることが多いのですが、多種多様な構成を学ぶのは新鮮で、「AWSならこんな解決策があるのか!」と、ただただワクワクしました。余計にAWSが好きになりました。 おまけ 最後にちょっとだけ自慢させてください! 12回もの試験を乗り越えたご褒美に、AWS Summit2025で取得した資格のシールをいただいてきました!(デザイン好きすぎて額縁に入れました。) 某RPGが大好きでたくさんのシリーズをやっているのですが、まさかAWSの資格シールがRPG風なんて…!!ドット絵のキャラクターが並んでいるのを見るだけで、テンションが上がります。こうして物理的な形になると、頑張ってよかったな~と改めて実感します。  総評:全冠を取得して変わったこと 2月から3月のラストスパートは、正直くじけそうになる瞬間もありました。 ですが、1つ合格するたびに「自分でもできるんだ」という自信が積み重なり、最後は 早く次の試験を受けたい! というランナーズハイに近い状態になっていました(笑)。 全冠を達成して得られたのは、単なる称号だけではありません。 AWSという巨大なパズルの全体像 が見えるようになったことで、アーキテクトとして自信を持って提案ができるようになりました。   もし、「実務経験が少ないから」と迷っている方がいたら、ぜひ一歩踏み出してみてください。資格取得の過程で得られる知識は、必ず現場でのあなたの武器になります。 最後まで読んでいただきありがとうございました! 2025 ALL AWS Certifications Engineers の名に恥じぬよう、これからも精進します! P.S.勢いそのままに、実は「AWS Certified Generative AI Developer – Professional」のベータ版も突撃し、Early Adopterバッジをもらってきました。気力が湧いたら、そちらの記事も書く…かもしれません。
S3 Files という新しい機能が発表されましたので、さっそく使ってみました。 また、ざっとドキュメントを読んだ所感もあわせて書いておきます。 Announcing Amazon S3 Files, making S3 buckets accessible as file systems - AWS Discover more about what's new at AWS with Announcing Amazon S3 Files, making S3 buckets accessible as file systems aws.amazon.com 概要 S3 Files は、**汎用 S3 バケットを EC2、Lambda、ECS/EKS などからマウントし、ファイルシステムとして利用できる機能**です。 S3 Vectors のように別種の S3 リソースが増えるわけではなく、利用するのは通常の汎用 S3 バケットです。 以前から Mountpoint for Amazon S3 という仕組みはありました。 こちらも S3 バケットをマウントして使えるという点では似ていますが、あくまでクライアント側のツールであり、共有ファイルシステムそのものではありません。 それに対して S3 Files は、S3 バケットを背後に持ちながら、より本格的なファイルシステムとして扱えるようにした機能、という理解です。 ファイルシステム作成 前提として、リンク先となる汎用 S3 バケットではバージョニングを有効化しておく必要があります。 「ファイルシステムを作成」をクリックします。 事前に作成しておいたバージョニング有効済みのバケットと、マウントターゲットが作成される VPC を選択します。 私の環境では、この後 5 分ほどで作成が完了しました。 作成できました。見た目はかなり EFS を思い出させます。 実際、ドキュメントによれば S3 Files は Amazon EFS を用いて実装されているようです。 マウントターゲット EFS と同様に、マウントターゲットが指定した VPC 配下に作成されます。 セキュリティグループはデフォルトのものがアタッチされていました。 このままでは使えない場合があるため、マウント元の EC2 などから通信できるよう、適切なセキュリティグループに変更または設定を調整しておく必要があります。 EC2 からのマウント 前提:EC2 に付与された IAM ロールに十分な権限が必要です。今回は検証のため、Administrator 権限を付与した状態で実行しています。 上記画面の「EC2 インスタンスへのアタッチ」より、マウント手順を確認できます。 アタッチ先 EC2 やマウントポイントなどを指定すると、下部のコマンド例に内容が反映されます。 この画面の入力はコマンド例に反映されるだけで、実際の変更はそのコマンドを実行して行います。 手順どおりに実行するだけですが、内部的には efs-utils を使うようです。 したがって、efs-utils の前提条件は満たしておく必要があります。 $ sudo mount -t s3files fs-011ca9d3df3f21efd /mnt/s3files $ sudo mount | tail -n 1 127.0.0.1:/ on /mnt/s3files type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,noresvport,proto=tcp,port=20721,timeo=600,retrans=2,sec=sys,clientaddr=127.0.0.1,local_lock=none,addr=127.0.0.1) $ df -T /mnt/s3files Filesystem Type 1K-blocks Used Available Use% Mounted on 127.0.0.1:/ nfs4 9007199254739968 0 9007199254739968 0% /mnt/s3files OS からは NFSv4 のファイルシステムとして見えていることが分かります。 続いて、一般ユーザーが扱えるサブディレクトリを作成し、その中でファイルを作成してみます。 $ sudo mkdir -p /mnt/s3files/work $ sudo chown ec2-user:ec2-user /mnt/s3files/work $ chmod 755 /mnt/s3files/work $ touch /mnt/s3files/work/hello.txt $ ls -l /mnt/s3files/work/hello.txt -rw-r--r--. 1 ec2-user ec2-user 0 Apr 8 10:06 /mnt/s3files/work/hello.txt $ echo "Hello S3 Files" >> /mnt/s3files/work/hello.txt $ cat /mnt/s3files/work/hello.txt Hello S3 Files ファイルの作成と追記ができました。 S3 バケット側を確認すると、ファイルが作成されており、内容も反映されていました。 自動マウントについては、fstab などを使って構成できそうですが、今回は未検証です。 アーキテクチャ おおよそ以下のような構成になっているようです。 ※ あくまでドキュメントを読んだ上での個人の理解です。 S3 とのやり取りを仲介する S3 Files が中間層として動作し、EC2 や Lambda、ECS/EKS などの compute resource は、この S3 Files を共有ファイルシステムとして利用するイメージです。 ファイルの変更はまず S3 Files 側で処理され、その後 S3 バケットへ同期されます。 一方、読み取りについては常に同じ経路を通るわけではなく、データサイズやアクセスパターンに応じて最適化されるようです。 前述の Mountpoint for Amazon S3 は、クライアント側で動くツールとしてファイル操作と S3 API の間を橋渡しするものでした。 それに対して S3 Files は、共有ファイルシステムとしての意味合いが強く、設計思想からかなり異なるように見えます。 また、S3 Files 作成時には S3 Files 用の IAM ロールが作成され、その権限で S3 バケットとの同期処理を行う構成になっています。 ただし、これだけで完結するわけではなく、マウントする側の EC2 などにも別途 IAM 権限が必要です。 権限関連 当然ながら、利用には IAM 権限が必要です。 権限はざっくり分けると、以下の 3 種類があります。 S3 Files を作成・管理するための権限 S3 Files 自身が S3 バケットと同期するための権限 EC2 や ECS/EKS など、実際にマウントして使うクライアント側の権限 単に S3 の権限だけでよいわけではなく、新しい service prefix である s3files: の権限も必要になります。 また、クライアント側には s3files:* 系の権限に加えて、状況によってはリンク先 S3 バケットを直接読むための権限も必要です。 したがって、実運用では権限設計はかなり丁寧にやる必要がありそうです。 How S3 Files works with IAM - Amazon Simple Storage Service Learn how S3 Files works with IAM. docs.aws.amazon.com 最後に 今回は EC2 からマウントして試してみましたが、同時に Lambda や ECS/EKS からも利用できるようです。 そのため、サービス間でファイルを受け渡すような構成はかなりやりやすくなりそうです。 S3 を単なるオブジェクト置き場として使うのではなく、共有ファイルシステムのように扱えるようになる、というのがこの機能の面白いところだと思いました。 今回はハンズオン目的だったため、権限関連はかなり雑に試しています。その点はご了承ください。 お読みいただきありがとうございました。
こんにちは。SCSK渡辺(大)です。 Proプランをサブスクリプションする前にClaude Codeをお試しで触ってみたかったので、世の中的には何番煎じか分かりませんが、Claude CodeをAmazon Bedrock経由で利用するための環境を作りました。 環境構築に必要なリソース群はAWS CloudFormationテンプレート(YAML)1つにまとめたので、デプロイも後片付けもコマンド一発です。 Amazon Bedrock経由の場合は従量課金で青天井になるため、おまけ程度ですがトークン数の監視アラートも仕込んでいます。 リセラー経由のアカウントでは別途Anthropicモデルの承認等が必要な場合があります。   構成図     作るもの YAMLのテンプレート1つで(AWS CloudFormationスタック1つで)以下を全部作ります。 VPC + パブリックサブネット(SSM用) EC2(Amazon Linux 2023、Claude Code・uv・AWS MCP自動インストール) Amazon Bedrock Application Inference Profile(Sonnet/Opus)※1 Claude Code設定(Amazon Bedrock接続、サブエージェントはSonnet、Haiku非推奨) AWS MCPサーバー設定(.mcp.json) ccstatusline設定(Model・Cost・Tokens表示) トークン監視(CloudWatch Metric Filter + Alarm → SNSメール通知)※2 Amazon Bedrockログ用IAMロール※3 ※1 Haikuは除外しています。 理由は、Haiku 4.5はClaude Codeの tool_reference blocks 機能に非対応で、ツール操作(ファイル読み書き、bash実行など)でAPIエラー(400)が出るためです。 参考: #14863 – Haiku agents fail with “tool_reference blocks not supported” error ※2 個人利用向けのおまけ程度の設計です。 アカウント全体の合計トークン数で監視しています。複数人で「誰が何トークン使ったか」を把握したい場合は別の構成が必要です。 ※3 Amazon Bedrockログが既存している場合には作成は任意。   前提条件 構築するためには様々な方法があります。 下記は参考として私が実施した環境を記載します。 ローカル Windows 11 Kiro (ターミナルはpowershell) AWS CLI (v2.32.3) Session Manager Plugin (v1.2.804.0) AWS AWSアカウント 管理者権限が付与されたIAMユーザー   事前準備 AWSアカウント、および管理者権限が付与されたIAMユーザーの準備については触れませんが、それ以外については出来る限り触れます。 Kiroをインストール 以下の公式サイトからダウンロードした後、インストールします。 Downloads – Kiro KiroにGoogle、GitHub、またはAWS Builder IDでサインインします。 必要に応じてPro以上のプランをサブスクライブしてください。 以降の手順の中でKiroとチャットはしないので、Freeプランでも今回の構築には影響はないかと思います。 AWS CLIをインストール 以下の公式ガイドからインストールします。 AWS CLI の最新バージョンのインストールまたは更新 – AWS Command Line Interface Session Manager Pluginをインストール 以下の公式ガイド通りにインストールしていきます。 AWS CLI 用の Session Manager プラグインをインストールする – AWS Systems Manager 拡張機能「Open Remote – SSH」(jeanp413)をインストール Kiroで拡張機能「Open Remote – SSH」を検索すると出てくる「Open Remote – SSH」(jeanp413)をインストールします。 デプロイ準備 Kiroのターミナルで以下のコマンドを入力してエンターを押します。 値をクォーテーションで囲み、任意のスタック名を指定してください。 この名前がAWS CloudFormationのスタック名になり、以降のコマンドでも使用します。 $STACK_NAME = "任意のスタック名"      2. ワークスペースに claude-code-on-aws.yaml というファイルを作成します。      3. claude-code-on-aws.yaml に以下を記載して保存します。 長すぎるので畳んでいます。   保存時の文字コードはBOMなしUTF-8にしてください。 BOM付きUTF-8やShift_JIS(cp932)で保存するとデプロイ時にエラーになります。 Kiroの場合、下部のステータスバーに「UTF-8」と表示されてればOKです。 「UTF-8 with BOM」など他のものになっている場合には、そこをクリックして「UTF-8」に変更してから保存してください。 ▶ claude-code-on-aws.yaml(クリックで展開) AWSTemplateFormatVersion: "2010-09-09" Description: > Claude Code on AWS - Linux EC2 + Bedrock + Token Monitoring. Single stack. SSM tunnel SSH for VSCode Remote SSH. Cost-aware. # ============================================================ # Parameter Groups (for AWS Console display) # ============================================================ Metadata: AWS::CloudFormation::Interface: ParameterGroups: - Label: default: Project Settings Parameters: - ProjectName - CostTag - Label: default: EC2 Configuration Parameters: - InstanceType - VolumeSize - Label: default: Network Configuration Parameters: - VpcCidr - SubnetCidr - Label: default: Bedrock Model Configuration Parameters: - SonnetInferenceProfileId - OpusInferenceProfileId - Label: default: Token Monitoring Parameters: - AlertEmail - TokenThreshold # ============================================================ # Parameters # ============================================================ Parameters: ProjectName: Type: String Default: claude-code Description: "Prefix for all resource names (e.g. claude-code -> claude-code-vpc)" AllowedPattern: "^[a-zA-Z][a-zA-Z0-9-]*$" ConstraintDescription: "Must start with a letter, then alphanumeric and hyphens only" CostTag: Type: String Default: claude-code Description: "Cost allocation tag applied to all resources" InstanceType: Type: String Default: t3.medium Description: "EC2 instance type (e.g. t3.small, t3.medium, t3.large)" VolumeSize: Type: Number Default: 20 MinValue: 8 MaxValue: 100 Description: "EBS disk size in GiB. Amazon Linux uses ~2GB. 20GB is sufficient" VpcCidr: Type: String Default: 10.0.0.0/16 Description: "VPC CIDR block" AllowedPattern: "^\\d{1,3}\\.\\d{1,3}\\.\\d{1,3}\\.\\d{1,3}/\\d{1,2}$" SubnetCidr: Type: String Default: 10.0.1.0/24 Description: "Public subnet CIDR block" AllowedPattern: "^\\d{1,3}\\.\\d{1,3}\\.\\d{1,3}\\.\\d{1,3}/\\d{1,2}$" SonnetInferenceProfileId: Type: String Default: jp.anthropic.claude-sonnet-4-6 Description: "Bedrock Sonnet inference profile ID for ap-northeast-1" OpusInferenceProfileId: Type: String Default: global.anthropic.claude-opus-4-6-v1 Description: "Bedrock Opus inference profile ID (global prefix, cross-region)" AlertEmail: Type: String Description: "Email address for token usage alerts" AllowedPattern: "^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$" ConstraintDescription: "Must be a valid email address" TokenThreshold: Type: Number Default: 150000 Description: "Token alert threshold (input+output+cache total per hour). Alert if exceeded" Resources: # ============================================================ # VPC / Network # ============================================================ VPC: Type: AWS::EC2::VPC Properties: CidrBlock: !Ref VpcCidr EnableDnsSupport: true EnableDnsHostnames: true Tags: - Key: Name Value: !Sub "${ProjectName}-vpc" - Key: Cost Value: !Ref CostTag InternetGateway: Type: AWS::EC2::InternetGateway Properties: Tags: - Key: Name Value: !Sub "${ProjectName}-igw" - Key: Cost Value: !Ref CostTag AttachGateway: Type: AWS::EC2::VPCGatewayAttachment Properties: VpcId: !Ref VPC InternetGatewayId: !Ref InternetGateway PublicSubnet: Type: AWS::EC2::Subnet Properties: VpcId: !Ref VPC CidrBlock: !Ref SubnetCidr AvailabilityZone: !Select [0, !GetAZs ""] MapPublicIpOnLaunch: true Tags: - Key: Name Value: !Sub "${ProjectName}-public-subnet" - Key: Cost Value: !Ref CostTag PublicRouteTable: Type: AWS::EC2::RouteTable Properties: VpcId: !Ref VPC Tags: - Key: Name Value: !Sub "${ProjectName}-public-rt" - Key: Cost Value: !Ref CostTag PublicRoute: Type: AWS::EC2::Route DependsOn: AttachGateway Properties: RouteTableId: !Ref PublicRouteTable DestinationCidrBlock: 0.0.0.0/0 GatewayId: !Ref InternetGateway SubnetRouteTableAssociation: Type: AWS::EC2::SubnetRouteTableAssociation Properties: SubnetId: !Ref PublicSubnet RouteTableId: !Ref PublicRouteTable # ============================================================ # Security Group - HTTPS outbound only, no inbound (SSM access) # ============================================================ SecurityGroup: Type: AWS::EC2::SecurityGroup Properties: GroupDescription: !Sub "${ProjectName} - HTTPS outbound only, SSM access" VpcId: !Ref VPC SecurityGroupIngress: [] SecurityGroupEgress: - IpProtocol: tcp FromPort: 443 ToPort: 443 CidrIp: 0.0.0.0/0 Tags: - Key: Name Value: !Sub "${ProjectName}-sg" - Key: Cost Value: !Ref CostTag # ============================================================ # EC2 Key Pair (for VSCode Remote SSH via SSM tunnel) # Private key is stored in Systems Manager Parameter Store # ============================================================ EC2KeyPair: Type: AWS::EC2::KeyPair Properties: KeyName: !Sub "${ProjectName}-keypair" KeyType: rsa KeyFormat: pem # ============================================================ # Bedrock Application Inference Profiles # Enables per-model cost tracking via Cost Explorer tags # ============================================================ SonnetProfile: Type: AWS::Bedrock::ApplicationInferenceProfile Properties: InferenceProfileName: !Sub "${ProjectName}-sonnet" Description: !Sub "Sonnet profile: ${SonnetInferenceProfileId}" ModelSource: CopyFrom: !Sub "arn:aws:bedrock:${AWS::Region}:${AWS::AccountId}:inference-profile/${SonnetInferenceProfileId}" Tags: - Key: Application Value: !Ref ProjectName - Key: Cost Value: !Ref CostTag OpusProfile: Type: AWS::Bedrock::ApplicationInferenceProfile Properties: InferenceProfileName: !Sub "${ProjectName}-opus" Description: !Sub "Opus profile: ${OpusInferenceProfileId}" ModelSource: CopyFrom: !Sub "arn:aws:bedrock:${AWS::Region}:${AWS::AccountId}:inference-profile/${OpusInferenceProfileId}" Tags: - Key: Application Value: !Ref ProjectName - Key: Cost Value: !Ref CostTag # ============================================================ # IAM Role - SSM + Bedrock + AWS MCP (least privilege) # ============================================================ EC2Role: Type: AWS::IAM::Role Properties: RoleName: !Sub "${ProjectName}-ec2-role" AssumeRolePolicyDocument: Version: "2012-10-17" Statement: - Effect: Allow Principal: Service: ec2.amazonaws.com Action: sts:AssumeRole ManagedPolicyArns: - arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore Policies: - PolicyName: BedrockAccess PolicyDocument: Version: "2012-10-17" Statement: - Sid: InvokeModels Effect: Allow Action: - bedrock:InvokeModel - bedrock:InvokeModelWithResponseStream Resource: - !GetAtt SonnetProfile.InferenceProfileArn - !GetAtt OpusProfile.InferenceProfileArn - "arn:aws:bedrock:*:*:foundation-model/*" - "arn:aws:bedrock:*:*:inference-profile/*" - Sid: ListModels Effect: Allow Action: - bedrock:ListFoundationModels - bedrock:ListInferenceProfiles - bedrock:GetFoundationModel Resource: "*" - PolicyName: AWSMCPAccess PolicyDocument: Version: "2012-10-17" Statement: - Sid: AllowAWSMCP Effect: Allow Action: - aws-mcp:InvokeMcp - aws-mcp:CallReadOnlyTool - aws-mcp:CallReadWriteTool Resource: "*" - PolicyName: MarketplaceAccess PolicyDocument: Version: "2012-10-17" Statement: - Sid: AllowMarketplace Effect: Allow Action: - aws-marketplace:ViewSubscriptions - aws-marketplace:Subscribe Resource: "*" Condition: StringEquals: aws:CalledViaLast: bedrock.amazonaws.com Tags: - Key: Name Value: !Sub "${ProjectName}-ec2-role" - Key: Cost Value: !Ref CostTag InstanceProfile: Type: AWS::IAM::InstanceProfile Properties: InstanceProfileName: !Sub "${ProjectName}-instance-profile" Roles: - !Ref EC2Role # ============================================================ # EC2 Instance - Amazon Linux 2023 # Auto-installs: Git, Node.js, Python, Claude Code, uv, AWS MCP # ============================================================ EC2Instance: Type: AWS::EC2::Instance DependsOn: - SonnetProfile - OpusProfile Properties: ImageId: "{{resolve:ssm:/aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64}}" InstanceType: !Ref InstanceType KeyName: !Ref EC2KeyPair IamInstanceProfile: !Ref InstanceProfile SubnetId: !Ref PublicSubnet SecurityGroupIds: - !Ref SecurityGroup BlockDeviceMappings: - DeviceName: /dev/xvda Ebs: VolumeSize: !Ref VolumeSize VolumeType: gp3 Encrypted: true PropagateTagsToVolumeOnCreation: true UserData: Fn::Base64: !Sub - | #!/bin/bash set -e exec > >(tee /var/log/user-data.log) 2>&1 echo "=== Setup started: $(date) ===" # System update dnf update -y # Install Node.js 22, Git, Python3 curl -fsSL https://rpm.nodesource.com/setup_22.x | bash - dnf install -y nodejs git python3 python3-pip # Setup as ec2-user sudo -u ec2-user bash << 'USEREOF' set -e export HOME=/home/ec2-user cd $HOME # Install Claude Code (native installer) curl -fsSL https://claude.ai/install.sh | bash -s stable export PATH="$HOME/.local/bin:$PATH" # Install uv (required for uvx / AWS MCP proxy) curl -LsSf https://astral.sh/uv/install.sh | sh # Bedrock environment variables cat << EOF >> ~/.bashrc # Claude Code on Bedrock export CLAUDE_CODE_USE_BEDROCK=1 export AWS_REGION=${AWS::Region} export AWS_DEFAULT_REGION=${AWS::Region} export ANTHROPIC_DEFAULT_SONNET_MODEL="${SonnetArn}" export ANTHROPIC_DEFAULT_OPUS_MODEL="${OpusArn}" export CLAUDE_CODE_SUBAGENT_MODEL="${SonnetArn}" export CLAUDE_CODE_MAX_OUTPUT_TOKENS=16384 export MAX_THINKING_TOKENS=10000 export PATH="\$HOME/.local/bin:\$HOME/.cargo/bin:\$PATH" EOF # Claude Code user settings mkdir -p ~/.claude cat << 'SETTINGS' > ~/.claude/settings.json { "provider": "bedrock", "autoUpdates": true, "autoUpdatesChannel": "stable", "language": "japanese", "statusLine": { "type": "command", "command": "npx -y ccstatusline@latest", "padding": 0 }, "permissions": { "deny": [ "Bash(rm -rf:*)", "Bash(sudo:*)", "Read(.env)" ] } } SETTINGS # AWS MCP Server (managed, via mcp-proxy-for-aws) cat << 'MCP' > ~/.mcp.json { "mcpServers": { "aws-mcp": { "command": "uvx", "timeout": 100000, "transport": "stdio", "args": [ "mcp-proxy-for-aws@latest", "https://aws-mcp.us-east-1.api.aws/mcp", "--metadata", "AWS_REGION=us-west-2" ] } } } MCP # ccstatusline config (Model | Session Cost | Tokens Total) mkdir -p ~/.config/ccstatusline cat << 'CCSTATUS' > ~/.config/ccstatusline/config.json { "lines": [ [ {"category": "model", "widget": "model"}, {"category": "separator", "widget": "separator"}, {"category": "cost", "widget": "session_cost"}, {"category": "separator", "widget": "separator"}, {"category": "tokens", "widget": "tokens_total"} ] ] } CCSTATUS # Verify installations source ~/.bashrc claude --version && echo "Claude Code OK" || echo "Claude Code FAILED" USEREOF echo "=== Setup completed: $(date) ===" - SonnetArn: !GetAtt SonnetProfile.InferenceProfileArn OpusArn: !GetAtt OpusProfile.InferenceProfileArn Tags: - Key: Name Value: !Sub "${ProjectName}-ec2" - Key: Cost Value: !Ref CostTag # ============================================================ # Bedrock Model Invocation Logging # Required for token monitoring via Metric Filters. # After deploy, enable logging in Bedrock console and # point to this log group and select the logging role. # ============================================================ BedrockLogGroup: Type: AWS::Logs::LogGroup Properties: LogGroupName: !Sub "/aws/bedrock/${ProjectName}" RetentionInDays: 30 Tags: - Key: Cost Value: !Ref CostTag BedrockLoggingRole: Type: AWS::IAM::Role Properties: RoleName: !Sub "${ProjectName}-bedrock-logging-role" AssumeRolePolicyDocument: Version: "2012-10-17" Statement: - Effect: Allow Principal: Service: bedrock.amazonaws.com Action: sts:AssumeRole Condition: StringEquals: aws:SourceAccount: !Ref AWS::AccountId ArnLike: aws:SourceArn: !Sub "arn:aws:bedrock:${AWS::Region}:${AWS::AccountId}:*" Policies: - PolicyName: BedrockLoggingCloudWatch PolicyDocument: Version: "2012-10-17" Statement: - Effect: Allow Action: - logs:CreateLogStream - logs:PutLogEvents Resource: !Sub "arn:aws:logs:${AWS::Region}:${AWS::AccountId}:log-group:/aws/bedrock/${ProjectName}:*" Tags: - Key: Cost Value: !Ref CostTag # ============================================================ # Token Monitoring - SNS Topic (KMS encrypted) # Alert emails may contain IAM ARN info, so encryption applied. # After deploy, confirm the subscription email! # ============================================================ AlertTopic: Type: AWS::SNS::Topic Properties: TopicName: !Sub "${ProjectName}-token-alert" Tags: - Key: Cost Value: !Ref CostTag AlertSubscription: Type: AWS::SNS::Subscription Properties: TopicArn: !Ref AlertTopic Protocol: email Endpoint: !Ref AlertEmail # ============================================================ # Token Monitoring - CloudWatch Metric Filters # Extracts token counts from Bedrock invocation logs and # publishes as custom CloudWatch metrics. No Lambda needed. # Includes cache tokens (cacheRead/cacheWrite) for accurate totals. # ============================================================ InputTokenMetricFilter: Type: AWS::Logs::MetricFilter Properties: LogGroupName: !Ref BedrockLogGroup FilterPattern: '{ $.input.inputTokenCount = "*" }' MetricTransformations: - MetricNamespace: !Sub "${ProjectName}/BedrockTokens" MetricName: InputTokenCount MetricValue: "$.input.inputTokenCount" DefaultValue: 0 CacheReadTokenMetricFilter: Type: AWS::Logs::MetricFilter Properties: LogGroupName: !Ref BedrockLogGroup FilterPattern: '{ $.input.cacheReadInputTokenCount = "*" }' MetricTransformations: - MetricNamespace: !Sub "${ProjectName}/BedrockTokens" MetricName: CacheReadInputTokenCount MetricValue: "$.input.cacheReadInputTokenCount" DefaultValue: 0 CacheWriteTokenMetricFilter: Type: AWS::Logs::MetricFilter Properties: LogGroupName: !Ref BedrockLogGroup FilterPattern: '{ $.input.cacheWriteInputTokenCount = "*" }' MetricTransformations: - MetricNamespace: !Sub "${ProjectName}/BedrockTokens" MetricName: CacheWriteInputTokenCount MetricValue: "$.input.cacheWriteInputTokenCount" DefaultValue: 0 OutputTokenMetricFilter: Type: AWS::Logs::MetricFilter Properties: LogGroupName: !Ref BedrockLogGroup FilterPattern: '{ $.output.outputTokenCount = "*" }' MetricTransformations: - MetricNamespace: !Sub "${ProjectName}/BedrockTokens" MetricName: OutputTokenCount MetricValue: "$.output.outputTokenCount" DefaultValue: 0 # ============================================================ # Token Monitoring - CloudWatch Alarms # Fires when total tokens (input + output) exceed threshold # within the monitoring window. Uses Metric Math to sum both. # ============================================================ TokenUsageAlarm: Type: AWS::CloudWatch::Alarm Properties: AlarmName: !Sub "${ProjectName}-token-threshold-alarm" AlarmDescription: !Sub "Bedrock token usage exceeded ${TokenThreshold} in monitoring window" ComparisonOperator: GreaterThanThreshold EvaluationPeriods: 1 Threshold: !Ref TokenThreshold TreatMissingData: notBreaching AlarmActions: - !Ref AlertTopic Metrics: - Id: input_tokens ReturnData: false MetricStat: Metric: Namespace: !Sub "${ProjectName}/BedrockTokens" MetricName: InputTokenCount Period: 3600 Stat: Sum - Id: cache_read_tokens ReturnData: false MetricStat: Metric: Namespace: !Sub "${ProjectName}/BedrockTokens" MetricName: CacheReadInputTokenCount Period: 3600 Stat: Sum - Id: cache_write_tokens ReturnData: false MetricStat: Metric: Namespace: !Sub "${ProjectName}/BedrockTokens" MetricName: CacheWriteInputTokenCount Period: 3600 Stat: Sum - Id: output_tokens ReturnData: false MetricStat: Metric: Namespace: !Sub "${ProjectName}/BedrockTokens" MetricName: OutputTokenCount Period: 3600 Stat: Sum - Id: total_tokens Expression: "input_tokens + cache_read_tokens + cache_write_tokens + output_tokens" Label: "Total Tokens (1 hour)" ReturnData: true # ============================================================ # Outputs # ============================================================ Outputs: InstanceId: Description: "EC2 Instance ID" Value: !Ref EC2Instance SSMConnectCommand: Description: "Connect via SSM Session Manager (terminal only)" Value: !Sub "aws ssm start-session --target ${EC2Instance}" SSMPortForwardCommand: Description: "SSM tunnel for VSCode Remote SSH (port 22 -> localhost:10022)" Value: !Sub "aws ssm start-session --target ${EC2Instance} --document-name AWS-StartPortForwardingSession --parameters portNumber=22,localPortNumber=10022" KeyPairName: Description: "EC2 Key Pair name (retrieve private key from Systems Manager Parameter Store)" Value: !Ref EC2KeyPair ConsoleURL: Description: "EC2 Console direct link" Value: !Sub "https://${AWS::Region}.console.aws.amazon.com/ec2/home?region=${AWS::Region}#InstanceDetails:instanceId=${EC2Instance}" SonnetProfileArn: Description: "Bedrock Sonnet Application Inference Profile ARN" Value: !GetAtt SonnetProfile.InferenceProfileArn OpusProfileArn: Description: "Bedrock Opus Application Inference Profile ARN" Value: !GetAtt OpusProfile.InferenceProfileArn BedrockLogGroupName: Description: "Enable Bedrock Model Invocation Logging to this log group" Value: !Ref BedrockLogGroup BedrockLoggingRoleName: Description: "Select this role in Bedrock console when enabling invocation logging" Value: !Ref BedrockLoggingRole AlertTopicArn: Description: "SNS Topic for alerts (confirm email subscription after deploy!)" Value: !Ref AlertTopic StopCommand: Description: "Stop instance (saves cost)" Value: !Sub "aws ec2 stop-instances --instance-ids ${EC2Instance}" StartCommand: Description: "Start instance" Value: !Sub "aws ec2 start-instances --instance-ids ${EC2Instance}" CleanupCommand: Description: "Delete all resources" Value: !Sub "aws cloudformation delete-stack --stack-name ${AWS::StackName}"   AWS CLIの認証設定 credentials ファイル で認証設定済みの場合はスキップしてください。 SSO利用の場合は aws sso login を使ってください。 ブラウザを開き、管理者権限が付与されたIAMユーザーでAWSマネジメントコンソールにログインします。 Kiroでターミナルを開き、aws login と入力してエンターを押します。 ブラウザの別タブで Continue with an active session の画面が出るので、AWSマネジメントコンソールにログインしているIAMユーザーをクリックします。 「Your credentials have been shared successfully and can be used until your session expires.」が表示されたらタブを閉じます。 Kiroのターミナルで、aws sts get-caller-identity と入力してエンターを押します。 出力結果を確認し、AWSIDとIAMユーザー名が想定通りであることを確認する。   推論プロファイルIDを確認 現在のIDを確認します。 Kiroのターミナルで以下のコマンドを入力してエンターを押します。 aws bedrock list-inference-profiles ` --region ap-northeast-1 ` --query "inferenceProfileSummaries[?contains(inferenceProfileName, 'Claude')].{Name:inferenceProfileName, Id:inferenceProfileId}" ` --output table   環境構築 デプロイ AWS CloudFormationスタックをデプロイします。 Kiroのターミナルで以下のコマンドを入力してエンターを押します。 デプロイは約5〜10分で完了します。 AlertEmail だけデフォルト値がないので必ず書き換えが必要です。 SonnetInferenceProfileId と OpusInferenceProfileId は事前準備で確認したIDと異なる場合に書き換えてください。 ProjectName もスタック名と揃えておくとリソース名が統一されて管理しやすいですが、お好みで書き換えてください。 aws cloudformation deploy ` --template-file claude-code-on-aws.yaml ` --stack-name $STACK_NAME ` --parameter-overrides ` ProjectName=$STACK_NAME ` CostTag=claude-code ` InstanceType=t3.medium ` VolumeSize=20 ` VpcCidr=10.0.0.0/16 ` SubnetCidr=10.0.1.0/24 ` SonnetInferenceProfileId=jp.anthropic.claude-sonnet-4-6 ` OpusInferenceProfileId=global.anthropic.claude-opus-4-6-v1 ` AlertEmail=your-email@example.com ` TokenThreshold=150000 ` --capabilities CAPABILITY_NAMED_IAM ` --region ap-northeast-1   各パラメーターの説明は以下の通りです。 パラメータ デフォルト値 説明 ProjectName claude-code リソース名のプレフィックス CostTag claude-code コスト配分タグ InstanceType t3.medium EC2インスタンスタイプ VolumeSize 20 EBSディスクサイズ(GiB) VpcCidr 10.0.0.0/16 VPCのCIDRブロック SubnetCidr 10.0.1.0/24 パブリックサブネットのCIDRブロック SonnetInferenceProfileId jp.anthropic.claude-sonnet-4-6 Sonnetの推論プロファイルID OpusInferenceProfileId global.anthropic.claude-opus-4-6-v1 Opusの推論プロファイルID AlertEmail なし(必ず指定) トークンアラート通知先メールアドレス TokenThreshold 150000 トークンアラート閾値(1時間あたり)   トークン数監視アラート関連の追加設定 Kiroのターミナルで以下のコマンドを入力してエンターを押します。 これでBedrockモデル呼び出しログを有効化します。 $ACCOUNT_ID = aws sts get-caller-identity --query "Account" --output text $json = @" { "cloudWatchConfig": { "logGroupName": "/aws/bedrock/$STACK_NAME", "roleArn": "arn:aws:iam::${ACCOUNT_ID}:role/${STACK_NAME}-bedrock-logging-role" }, "textDataDeliveryEnabled": true, "imageDataDeliveryEnabled": false, "embeddingDataDeliveryEnabled": false, "videoDataDeliveryEnabled": false } "@ [System.IO.File]::WriteAllText("$PWD\logging-config.json", $json) aws bedrock put-model-invocation-logging-configuration ` --region ap-northeast-1 ` --logging-config file://logging-config.json            2. AlertEmailに指定したメールアドレスに以下件名のメールが届きます。            件名:AWS Notification – Subscription Confirmation         そのメールを開き、「Confirm subscription」のリンクをクリックします。         これでトークン数が設定した閾値を超過した場合指定したメールアドレスに通知が飛ぶようになります。   接続確認 EC2インスタンスへの接続確認 EC2インスタンスのIDを取得します。 Kiroのターミナルで以下のコマンドを入力してエンターを押します。 $INSTANCE_ID = aws cloudformation describe-stacks ` --stack-name $STACK_NAME ` --region ap-northeast-1 ` --query "Stacks[0].Outputs[?OutputKey=='InstanceId'].OutputValue" ` --output text Write-Host "Instance ID: $INSTANCE_ID"      2. EC2インスタンスに接続します。          Kiroのターミナルで以下のコマンドを入力してエンターを押します。          「TargetNotConnected」となった場合には10分後くらいに再度試してみてください。 aws ssm start-session --target $INSTANCE_ID --region ap-northeast-1      3. EC2インスタンスへ接続でき、ターミナルにて表示が 「sh-5.2$」のように変わったことを確認します 。   KiroからEC2へのリモート接続設定 SSMで接続すると ssm-user というユーザーでログインします。 Claude Codeは ec2-user にインストールされてるので、ユーザーを切り替える必要があります。 Kiroのターミナルで以下のコマンドを入力してエンターを押します。 sudo su - ec2-user      2. Claude Codeが導入されていることを確認します。          Kiroのターミナルで以下のコマンドを入力してエンターを押します。          バージョンが出ればOKです。 claude --version       3. Kiroのターミナルで「exit」を入力してエンターを押し、ec2-userを抜けます。           もう一度、「exit」を入力してエンターを押し、SSMセッションを抜けます。          4.  EC2キーペアIDを取得します。            Kiroのターミナルで以下のコマンドを入力してエンターを押します。 $keyId = aws ec2 describe-key-pairs ` --key-names "$STACK_NAME-keypair" ` --query "KeyPairs[0].KeyPairId" ` --output text ` --region ap-northeast-1        5. 秘密鍵をダウンロードします。            Kiroのターミナルで以下のコマンドを入力してエンターを押します。 New-Item -ItemType Directory -Path ~\.ssh -Force aws ssm get-parameter ` --name "/ec2/keypair/$keyId" ` --with-decryption ` --query "Parameter.Value" ` --output text ` --region ap-northeast-1 | Out-File -Encoding ascii ~\.ssh\claude-code-key.pem         6. SSH Configを作成します。             <ユーザー名> は自分のWindowsユーザー名に置き換えてください。             Kiroのターミナルで以下のコマンドを入力してエンターを押します。 Set-Content -Path ~\.ssh\config -Value "Host claude-code`n HostName localhost`n Port 10022`n User ec2-user`n IdentityFile C:\Users\<ユーザー名>\.ssh\claude-code-key.pem"          7. SSMトンネルを開始します。             Kiroのターミナルで以下のコマンドを入力してエンターを押します。             「Waiting for connections…」と表示されたら準備完了です。 aws ssm start-session ` --target $INSTANCE_ID ` --document-name AWS-StartPortForwardingSession ` --parameters "portNumber=22,localPortNumber=10022" ` --region ap-northeast-1   KiroからRemote SSH接続 Ctrl+Shift+P → 「Remote-SSH: Connect to Host…」→ claude-code と入力してエンターを押します。 自動でKiroがもうひとつ立ち上がります。 Kiroにサインインします。 下図の赤矢印の先のように、新たに開かれたKiroでは左下に と表示されていることを確認します。   Claude Codeを起動 Remote SSHで接続しているほうのKiroで実施します。 念のためにルートディレクトリから移動した後、Claude Codeを起動します。 mkdir ~/projects && cd ~/projects claude      2. テーマを選択してエンターを押します。              3. セキュリティに関する注意事項が出るので確認したらエンターを押します。            4. ワークスペースの確認で問題なければエンターを押します。            5. AWSのMCPサーバーをテンプレートで入れているので出てくる選択肢です。          お試ししてみたいということであれば2で良いかと思います。不要な場合には3を選択してください。            6. チャット画面が開きます。         テンプレートでccstatuslineも入れています。 下図のようにコストとトークン数などを表示することが出来ます。     同様の情報は /cost でも見れますが、表示させたいという場合には下記を実施してください。 Claudeとの会話ではなくターミナル上で「npx ccstatusline@latest」を入力してエンターを押します。 Main Menu から Edit Lines を選択してエンターを押します。 Line 1 を選択してエンターを押します。 Model以外を選択した状態でdを押して削除します。(Modelのみ残す) aを押した後、All を選択してエンターを押します。 追加したいものを追加します。 Escを数回押して Main Menu まで戻ります。 Save & Exit を選択してエンターを押します。 Claudeを起動して下部に追加されていることを確認します。   お試し後のリソース削除 リソース削除はスタック消すだけです。 aws cloudformation delete-stack --stack-name $STACK_NAME --region ap-northeast-1 Amazon Bedrockコンソールのモデル呼び出しログ設定だけ手動で無効化してください。 aws bedrock delete-model-invocation-logging-configuration --region ap-northeast-1   おまけ程度のトークン数の監視アラートについて テンプレートにはおまけ程度ですが、トークン数の監視アラートを仕込んでいます。 仕組み Amazon Bedrock のモデル呼び出しログを CloudWatch Logs に出力し、Metric Filter でトークン数(Input・Output・Cache Read・Cache Write)を抽出し、CloudWatchメトリクスに変換しています。 1時間あたりの合計トークン数が閾値を超えると CloudWatch Alarm がSNS経由でメール通知します。 Lambda不要で、全てマネージドサービスの組み合わせです。 閾値を超えると件名:ALARM: “claude-code-daisuke-token-threshold-alarm” in Asia Pacific (Tokyo) のようなメールが届きます。 注意点 個人利用向けの設計のため、AWSアカウント全体の合計トークン数で監視しています。 複数人で「誰が何トークン使ったか」を把握したい場合は別の構成が必要です。 トークン数での監視であり、料金そのものの監視ではありませんので、各モデルの料金差異は考慮されていません。 閾値はあくまで目安として捉えてください。 ALARMからOKに戻るまで、CloudWatchの評価範囲の仕様により数十分かかることがあります。 Amazon Bedrockのモデル呼び出しログの有効化はテンプレートとは別にコマンドまたはAWSマネジメントコンソールにて手動で行う必要があります。   まとめ Claude Code on Amazon Bedrockはレートリミットなしで使えるのが魅力ですが、従量課金なのでコスト管理が大事です。 ご利用になる際はお気を付けください。 当記事において不備がございましたらご連絡いただけますと幸いです。 最後に、ここまで協力してくれたKiroから「いいね」を貰うことができて嬉しかったです。
こんにちは。SCSKの池田です。 2025年11月12日にLifeKeeperが10年ぶりのメジャーバージョンアップを果たしました。これまでOS毎に異なっていたライセンス体系やサポート期間の考え方が統一されるなど、「全てをシンプルに、より分かりやすく、より使いやすく」をコンセプトに改変が行われました。 具体的な内容は以前の記事をご確認ください。 LifeKeeper v10リリース記念 これまでと何が変ったか!? 今回は、LifeKeeperの姉妹製品であるSingle Server Protection v10のライセンスについて解説したいと思います。   Single Server Protectionの名前が変わりました まずライセンス体系に入る前に、お伝えしないといけないこととして、Single Server Protectionのライセンス名称がv10に統一されています。   以前のライセンス名 v10のライセンス名 Windows版 Single Server Protection for Windows LifeKeeper v10 for SingleServer Linux版 Single Server Protection for Linux   Windows版のライセンス体系 続いて、Windows版の旧バージョンと新バージョンのライセンス体系の変更点についてみていきたいと思います。 こちらの図をご覧ください。 上の図のように、旧バージョンではSingle Server Protection for WindowsにDB製品やIISが同梱されていましたが、新バージョンでは、DB製品が「Recovery Kit for Database-SS」という独立した製品になっています。その分、LifeKeeper v10 for SingleServerの価格がお安くなっています。「LifeKeeper v10 for SingleServer」は、よりお求めやすい価格で可用性を実現して欲しいというサイオステクノロジー社の想いが垣間見れますね。 また旧バージョンではJP1/AJS Manager、Agent、HULFTとミドルウェアごとにARKが用意されていましたが、v10では「Recovery Kit for Enterprise Apps-SS」に集約されている点も大きな変更点になります。 LifeKeeper v10 for SingleServerの価格が安くなるのはうれしいなぁ   Linux版のライセンス体系 続いて、Linux版の旧バージョンと新バージョンのライセンス体系の変更点についてみていきたいと思います。 こちらの図をご覧ください。 Linux版の場合、旧バージョンでは多くのRecovery Kitが同梱されていましたが、Windows同様に新バージョンでは、DB製品が「Recovery Kit for Database-SS」という独立した製品になっていまして、LifeKeeper v10 for SingleServerの価格がお安くなっています。 また本体に同梱されていたWebSphere MQや、JP1/AJSやHULFT用のRecovey Kitが「Recovery Kit for Enterprise Apps-SS」に集約されている点も大きく変わった点となります。 まとめ LifeKeeperと同様にSingle Server Protectionについても、v10でライセンスが統一されましたが、OSごとに冗長化することができるミドルウェア製品が異なることから、それぞれの利便性を確保しつつ、ライセンス体系の見直しが行われてたようです。 「以前のバージョンでは同梱されていたRecovery Kitが、新バージョンで含まれていない」という事態にならないように、十分注意を払いながら必要なライセンスを購入していただければと思います。 少しでも不安な場合は、サイオステクノロジー社から認定されたSI&サポートパートナーであるSCSKにお問い合わせください。 オステクノロジー認定のSI&Supportパートナー (サイオステクノロジー公式サイト) Lifekeeperの製品体系 (サイオステクノロジー公式サイト) 詳しい内容をお知りになりたいかたは、以下のバナーからSCSK LifeKeeper公式サイトまで
皆様は、「DataKeeper」という製品をご存知でしょうか。 DataKeeperとは、稼働中のサーバのデータを、リアルタイムで待機系に複製(ミラーリング)し、止めないシステム運用を実現するソフトウェアです。 クラスタノード間でボリュームをミラーリングし、あたかも共有ストレージのように扱うことが可能になります。クラスタリングソフトウェアであるLifeKeeperやWindowsのWSFC(Windows Server Failover Clustering)と連携することにより、高可用性を実現しつつ、データの冗長性を確保することが可能となります。   本記事では、DataKeeperの機能や特徴を解説し、どのような状況で活用していくかについて紹介していきます。   DataKeeperの基本機能・主な特長 基本機能 DataKeeperは、稼働系と待機系のローカルディスク上のボリュームをレプリケーションの技術で同期し、 それらのボリュームを論理的な共有ディスクのように扱い、LifeKeeperおよびWSFCとも連携する機能が特徴です。 DataKeeperの構成イメージ   サーバ毎に接続されたローカルディスク上のボリュームをレプリケーションし、 ミラーボリュームを作成することで、共有ディスクとして扱うことが可能となります。 障害発生時には LifeKeeper と連携してLifeKeeperが監視・フェイルオーバーを実行し、 DataKeeperがデータレプリケーションを担い、論理共有ディスク上のデータをそのまま待機系に引き継ぎます。   主な特徴 ■ブロックレベルのリアルタイム・レプリケーション 同期/非同期に対応しており、WAN向け最適化や圧縮も備え、レイテンシー環境でも帯域効率よく複製します。帯域制御とパフォーマンスについては、ファイル単位ではなく「ブロックレベル」となるため、高速での転送が可能となります。 同期に使うネットワーク帯域を調整できるため、業務ネットワークへの影響を最小限に抑えられます。   ■WSFCとネイティブ連携 DataKeeper VolumeをWSFCのリソースとして扱い、クラスタ側の制御に自然統合することができます。 Windows標準のクラスタ機能(WSFC)が、DataKeeperのボリュームを「物理ディスクリソース」として認識し、SQL Serverやファイルサーバの冗長化をする際、使い慣れた WSFC の管理画面で運用できるため、学習コストを増やさずに導入できます。   ■クラウド/仮想/物理を横断 AWS/Azure/GCPやVMware、オンプレ物理で同じ考え方で設計・展開が可能となります。 AWSやAzureでは、オンプレミスのような「共有ストレージ(SAN)」をマウントしてクラスタを組むのが難しい、または高価なマネージドサービスが必要となりますが、 DataKeeperを使えば、ローカルディスク同士を同期させるだけでクラスタを組むことが可能です。   ■コスト最適化 共有ストレージが不要となり、OSからは「共有ディスク」として認識されるため、アプリケーション側の対応が不要、コストを抑えることができます。   では、これらの特徴が実際の現場でどのように役立つのか、シチュエーションごとに DataKeeper の活用イメージを紹介します。   シチュエーション別、DataKeeperの活用事例 1) クラウド移行を検討中の情シス(AWS) 前提 :既存オンプレで SQL Server FCI や ファイルサーバクラスタ を利用中 AWS に移行しても ダウンタイムを極小化した高可用性(HA) 構成 を維持したい 課題 : AWS では、共有ディスク構成が直接使えない/FSx for Windows(共有ファイルサービス)が割高/  マルチAZをまたいだ共有ストレージ提供が制約多い、という背景がある 解決 :DataKeeper を使うことで、各ノードのローカル EBS(ディスク)上のボリュームをブロック単位で同期し、 共有ディスクなしでも WSFC)を構築可能。またマルチAZまで柔軟に拡張可能となります。AWS に「オンプレ同等の可用性構成」を持ち込めます。 構成イメージ(AWS): マルチAZの SQL Server FCI/ファイルサーバ にLifeKeeper + DataKeeper を導入した構成各ノードはローカル EBS を利用 DataKeeper が ブロックレベルで EBS を同期(Sync/Async) LifeKeeper/WSFC によりAZ 障害時は自動フェイルオーバー ➡ 共有ディスクが不要なため、AWS の制約(共有ストレージ/コスト)を解消できます   2) 共有ストレージのコストや仕様で悩むエンジニア 前提 :オンプレ/仮想環境で NAS/SAN などの共有ストレージ を利用している 課題 :共有ストレージは高コスト、専用スキルや運用の複雑性、SPOFが気になる。 解決 :DataKeeperは既存のローカルストレージを活用し、SPOFを排除。 SSD/フラッシュも活かせるため性能面でも優位。 アレイ依存のレプリケーションに比べ、コスト効率の高いHA/DRが構築可能。  構成イメージ :Azure:ASCS/ERSやDBのWSFCを共有ディスク不要で内部LB・クォーラム設計のガイダンスに沿い、DataKeeperで共有相当を実現。 ➡コストを下げつつ、ストレージの複雑性・制約をすべて解消できます     他方式とのDataKeeperの比較 具体的な活用イメージをご紹介しましたが、他方式と比べてどこが優れているのか?も気になるポイントです。 代表的な方式との比較を整理してみます。  比較対象 DataKeeper導入のメリット DataKeeper導入のデメリット vs クラウド共有ストレージ(FSx/Azure Files等) ・コスト最適化(従量課金を排除) ・マルチAZ対応 ・ローカルI/Oで性能が安定 ・局所レイテンシ低減の余地 ・レプリケーション帯域の確保が必要 ・ローカルディスク障害時の運用が発生 ・一般的に2ノード中心 vs S2D (Storage Spaces Direct) ・WSFC+既存ディスクで即構成 ・クラウド横断で利用可能 ・専用NIC/ハード不要 ・学習コストが低い ・スケールアウトストレージ機能なし ・大規模分散用途には不向き ・ソフトウェアライセンス費用が発生 vs SQL Server Always On(AG) ・DB以外も保護可能 ・SEでFCIが作れライセンス最適 ・アプリ改修不要 ・フェイルオーバーが単純 ・読み取り専用レプリカ不可 ・全ボリュームレプリケーション ・AGにあるDBレベル機能を持たない   比較を踏まえて理解が深まったところで、 実際の相談でよくいただく質問もまとめておきます。 よくある質問(FAQ) Q1. レプリケーションは同期/非同期を切り替えられますか? A. はい。ブロックレベルで同期/非同期を選択でき、切り替えも可能です。 Q2. SQL Server Standard EditionでもFCIを構築できますか? A. 可能です。DataKeeper+WSFCで共有ディスク相当を提供できるため、Standard EditionでもFCIを構成できます。 Q3. ネットワーク障害でノード間の通信が切断された場合、再同期はどうなりますか? A. フル同期のやり直しは不要です。通信が途絶えた際、DataKeeperはレプリケーションを一時停止し、変更されたブロック箇所(差分)だけを内部のビットマップメモリに記録し続けます。ネットワーク復旧後は、その差分データのみが自動的に再同期(部分再同期)されるため、システムへの負荷を最小限に抑えて正常な状態に復帰できます。 Q4. DataKeeperでレプリケーションできないデータはありますか? A. はい。Cドライブなどの「OSシステム領域(システムボリューム)」はレプリケーションの対象外となります。また、DataKeeperはドライブ(ボリューム)単位でのブロック同期を行うため、「特定のファイルやフォルダだけ」を指定して同期することも仕様上できません。   まとめ DataKeeperでは、AWSやAzure等のクラウド・オンプレを問わず、同じアーキテクチャ思想で設計・展開・運用できるのが強みであることをお伝えいたしました。 LifeKeeper連携まで含めた“アプリもデータも守る”設計で、止めないシステム運用を支援します。  詳しい内容をお知りになりたいかたは、以下バナーからお問合せください。
Googleの提供する NotebookLM について紹介します。 現在のビジネスパーソンが直面している課題として、 情報の「質」ではない「量」の暴力 だと言われています。日々届く数十、数百のメール・チャットと添付ファイル、業務上確認が必要なドキュメント・Webサイトの数々。それらすべてを精読する時間は、物理的にもはや存在しません。かつては「資料を読む」という行為は美徳だった時代がありましたが、今では非効率作業の代表です。 NotebookLMは、この難問に対する回答となります。2026年になって、単なる「便利なPDF要約ツール」ではなく、情報を構造化し、自律的にリサーチし、瞬時にプレゼン資料や動画へと昇華させる統合的な「Research-to-Content Pipeline(リサーチから制作へのパイプライン)」へと変貌を遂げています。   NotebookLMとは? NotebookLM(ノートブックエルエム) は、 パーソナライズされた AIリサーチアシスタント です。つまりあなた個人の専用AIアシスタントです。 所有する資料(ドキュメント、PDF、テキストファイルなど)、Webサイト(URLなど)の内容を元に、情報整理、要約、質疑応答、アイデア出しをサポートし、理解を深めたり、レポート、マインドマップへのアウトプットをすることができます。 通常のAIチャットボット(ChatGPT、Gemini、Claude)は、インターネット上の広範な情報を元に様々なタスクに対応できる一方で、ハルシネーション(=もっともらしいウソ)が避けられないのですが、NotebookLM はアップロードされたソースの資料を活用することに特化しているため、情報の出所をすぐに確認でき、ハルシネーションを最低限に抑制することはできます。 また、アップロードした資料については、 AI モデルのトレーニングに一切使用されません とされています。   利用法方法(ソース、チャット) さっそくNotebookLMの利用方法について説明します。 NotebookLMログインし「ノートブックブックを作成」を選択すると上記画面が表示されます。 まず、ソースとして、ウェブサイト(URL)、ローカルのファイル、Googleドライブの各種ファイル(ドキュメント、スプレッドシート、スライド)、テキストの入力を行い、資料をアップロードします。 2026年4月時点でサポートされているファイルは、pdf, txt, md , docx, csv, pptx, epub, avif, bmp, gif, ico, jp2, png, webp, tif, tiff, heic, heif, jpeg, jpg, jpe, 3g2, 3gp, aac, aif, aifc, amr, au, avi, cda, m4a, mid, mp3, mp4, mpeg, ogg, opus, ra, ram, snd, wav,wma となっており、 ドキュメント(PDF、テキスト、CSV、 Word文書 、 Powerpoint文書 、マークダウン文書、電子書式形式)と画像、動画、音声ファイル となります。 NotebookLMに関するWebサイト記事(noteに掲載されているGemini公式記事など)、Youtube動画などをソースとして登録 してみました。登録されたソースは、左のウィンドウにリストアップされます。 すると中央のウィンドウに、 NotebookLM: A Guide to Personalized AI Research and Analysis (NotebookLM:パーソナライズされたAI研究と分析のためのガイド)としてソースの要約が記載されました(タイトルは編集可能です) Googleが提供する NotebookLM は、ユーザーがアップロードした特定の資料に基づいて情報の解析や要約を行う、パーソナライズされた AIリサーチアシスタント です。一般的な生成AIとは異なり、指定されたソースのみを情報源とするため、回答の 信頼性 が高く、引用元を即座に確認できるメリットがあります。多様なファイル形式に対応しているほか、 マインドマップ による視覚化や対話形式の 音声概要 など、情報の理解を深めるための独自機能が充実しています。ユーザーのデータが学習に利用されない 安全な環境 で、資料作成や論文読解といった幅広いシーンでの活用が期待されています。簡単なステップで導入でき、情報の整理やアイデア出しを効率化するツールとして紹介されています。 通常のAIチャットボットのようにプロンプトで質問し回答を得ることや、要約、比較、アイディア出しなどができますが、回答を行った情報については出所がすべて表示されており、そのソースも表示されますので、間違った情報ではないかを容易に確認することが可能になっています。   利用方法(Studio) プロンプトを駆使して様々アウトプットを生成することは可能ですが、右ウィンドウのStudioを利用することで、簡単に様々なアウトプットを生成することが可能となっています。現在Studioには以下の9つのアウトプット生成機能が提供されています。 アウトプット機能 機能概要 音声解説 ソースに基づいてAIポッドキャストを生成 スライド資料 ソースに基づいてAIスライドを生成(PDF、PowerPoint出力可) 動画解説 AIが解説動画を生成します マインドマップ ソースに基づいてAIによるマインドマップを生成 レポート ソースに基づいてレポートを生成(概要説明資料、学習ガイド、ブログ投稿など) フラッシュカード ソースに基づいてAIフラッシュカード(単語帳)を生成 クイズ ソースに基づいてAIによるインタラクティブなクイズを生成 インフォグラフィックス ソースに基づいてAIによるインフォグラフィックス(情報を整理して見やすく整えた画像)を生成 Data Table ソースからデータ表を生成(Googleスプレッドシート連携) インフォグラフィックス こちらがワンクリックで生成されたインフォグラフィックス『 2026年版 NotebookLM 完全攻略ガイド:資料を「成果物」に変える究極のAIリサーチツール 』となります。 1枚に情報整理された非常に見やすく理解しやすい画像(インフォグラフィックス)が生成されました。 残念ながら現状は出来上がった画像の追加修正は行えません。ただし、作成する際にスタイルや色、強調するポイントなどをプロンプト指示して作成することは可能です。 スライド資料 こちらがワンクリックで生成されたスライド資料、『 2026年の大進化:NotebookLMが実現する「知識の精製パイプライン」 』となります。15ページのスライド資料が作成されました。 先ほどのインフォグラフィックスとは異なりスライド一枚単位で、プロンプトにて変更の指示を行うことが可能です。 画像の配置やタイトルを短くなどは比較的簡単に行えますが、「文字の〇〇〇を△△△にして」などは画像認識されているためなのか、正直なところかなり手こずります。 また、 スライドは、PDFとPowerPoint形式でエクスポート(ダウンロード)することはできます が、残念ながらPowerPoint形式は、1枚の画像イメージ(画像ベース)として出力されるため、画像や文字修正は行うことはできません。 現時点で画像や文字を修正可能なPowerpoint形式でダウンロードできるのは、 Genspark となります。 エージェント型AI Gensparkとは? 次世代型AIオールインワンワークスペース Genspark(ジェンスパーク)AI ワークスペース 3.0 について紹介します。 blog.usize-tech.com 2026.03.24 マインドマップ マインドマップも作成できますが、修正できません。 その他には、 レポート で概要説明資料・学習ガイド・ブログ投稿記事を作成したり、 音声解説 では、ラジオ番組のような二人の掛け合いの音声ファイルが作成され、 動画解説 は、音声+説明イメージも自動作成されます。 フラッシュカード は単語帳を作成し、 クイズ は複数選択肢のテスト(クイズ)を作成しますので、試験勉強などの学習用に最適です。 Data Table では、Googlesスプレッドシートとの連携も可能です。   実際の利用シーンについて NotebookLMを活用することで、ビジネスパーソンの膨大な資料の読み込みや整理、アウトプット作成の時間を大幅に短縮し、業務効率を劇的に向上させることができます。 主な利用シーン(活用例)を記載します。   会議の準備と議事録の事後処理 効率的な事前把握 : 過去の議事録や関連レポートをアップロードし、音声解説や動画解説で要約を生成すれば、移動中などに音声で重要事項を素早く確認できます。 タスクと決定事項の抽出 : 会議の録音ファイルや議事録から、決定事項や次に取るべきアクション(タスク)を数秒で一覧化できます。 競合調査と市場分析 情報の集約と横断分析 : 競合他社のWebサイトURL、業界レポート、プレスリリースを一つのノートブックにまとめ、「自社との差別化ポイントは?」といった複数資料を跨いだ分析が即座に行えます。 比較表の自動作成 : 2026年の新機能「データテーブル」を使えば、複数の資料から「価格」「機能」「導入実績」などの共通項目を抜き出し、比較表を自動で作成してGoogleスプレッドシートへ書き出すことが可能です。 提案資料やコンテンツの作成支援 構成案(骨子)の作成 : 散らばった社内資料やWeb情報を基に、新規事業提案書の骨子やレポートのアウトラインを短時間で作成できます。 プレゼンスライドの自動生成 : 分析した内容を基に、デザイン性の高いプレゼンテーションスライド(PPTX形式)を自動生成できます。プロンプトで個別スライドの微調整も可能です。 解説動画の作成 : 複雑な社内規定や技術文書を動画解説でアニメーション付きの説明動画に変換し、チームや顧客への分かりやすい説明資料として活用できます。 法務・コンプライアンスチェック リスクの洗い出し : ページ数の多い契約書や利用規約、業界ガイドラインを読み込ませ、「リスクになりそうな条項の特定」や「新旧ガイドラインの差異の整理」を瞬時に行えます。 根拠の即時確認 : 回答には必ず元の資料への引用リンクが付くため、専門用語や複雑な条項のファクトチェックが容易です。 社内ナレッジの共有と人材育成 専用チャットボットの構築 : 業務マニュアルや製品の取説を読み込ませることで、不明点がある際にいつでも質問できる「社内専用FAQチャットボット」として運用できます。 研修の自動化 : 研修資料を音声解説や動画解説でで講義音声に変換したり、自動生成されたクイズやフラッシュカードを用いて新入社員の自己学習を促したりすることで、教育コストを削減できます。 データ分析とスプレッドシート連携 定量・定性データの統合分析 : 売上数値が入ったGoogleスプレッドシートと、顧客アンケートなどの定性データを組み合わせて分析し、その結果を構造化されたレポートとして出力できます。 上記以外にも、 自分が作成した資料のレビュー (誤字脱字や言い回しにおかしいところがないかのチェック)、 改訂版資料が送られてきた際に前回資料との差異の洗い出し などにも活用しています。 これらの機能の活用によって、ビジネスパーソンは「資料を読み込む」というインプット作業から解放され、「意思決定」や「創造的なアウトプット」に集中できるようになります。   まとめ NotebookLMは、2023年に「 Project Tailwind(テイルウィンド) 」としてサービスリリースされ、2024年6月に日本語インターフェースおよび日本語ドキュメント解析に対応し、日本国内でも利用できるようになりました。昨年(2025年5月)にiOS/Androidのモバイルアプリ も登場しましたが、 2026年に入り、以下の大幅な機能向上によりいっきに活用できるレベルになったと言えます。 Gemini 3 Flash を搭載し、劇的にスピードアップ (50ページの技術マニュアルを45秒以内で20分の音声講義へ変換) EPUB形式の電子書籍や、Googleスプレッドシート、Microsoft Wordファイルの直接読み込みが可能になるなど対応ソースが拡大。モバイル版でカメラ撮影した写真をそのままOCR解析して取り込み可能。 最新AIモデル(Nano Banana Pro、Veo3)を活用し、資料の内容を滑らかなアニメーションとナレーションで解説する プレゼンテーション風動画を自動生成 できるように。 アップロードした資料からデザイン性の高いプレゼンスライドを自動作成。 生成されたスライドを Microsoft PowerPoint形式での書き出し が可能で、プロンプト指示による個別スライドの修正に対応。 複雑な情報を、アニメ風、プロフェッショナル、雑誌風など、10種類のスタイルから選択して視覚的な図解(インフォグラフィック)へ変換。 データテーブル機能として、複数のPDFやWebサイトから価格や納期などの共通項目を抜き出し、比較表を自動作成。作成した表をそのままGoogle スプレッドシートへエクスポート可。 自身が作成したNotebookLMの知識ベース(ノートブック)を、Geminiアプリ内の「Gems」などのソースとして直接利用し、高度な画像生成やWeb検索と組み合わせることが可能へ。 スライドは、前述の通りPowerPoint形式でダウンロードは可能ですが、現時点では1枚のイメージとして出力されるため、現状では画像や文字がPowerPointでは編集できないなど使い勝手が悪いところはありますが、 NotebookLMとしては、 対話型AI(AIチャットボット)から進化し続けているので、今後も業務効率化の観点では目を離せません。  
2026年3月、 RFC 9849: TLS Encrypted Client Hello というインターネット標準のプロトコル仕様が発行されました。(正確には “Proposed Standard” ではありますが、標準と呼んで差し支えないでしょう。) この Encrypted Client Hello (以降 ECH と表記します) は、プライバシー保護という観点では望ましい技術ですが、Cato クラウドのようにセキュリティ機能を提供するサービスとは相性が悪い面があります。具体的には、ECH によって Cato が通信先のドメイン名を正しく認識できなくなり、セキュリティポリシーが適切に機能しなくなる可能性があります。 本記事では、ECH が Cato クラウドの動作にどのような影響を与えるのか、そしてどう対応すべきなのかを解説します。 TLS Encrypted Client Hello とは ECH については2年前のブログでも少し触れていましたが、その当時の懸念は少々杞憂でした。 Cato クラウドの FQDN ベースの制御の仕組みと課題 Cato クラウドでは、通信先の FQDN をベースとしたトラフィック制御やアクセス制御を行うことができます。一方で、FQDN の根幹を成す DNS はアプリケーションレイヤの技術であり、ネットワークやトランスポートのレイヤからは直接扱えない技術でもあります。 そうしたレイヤの違いから Cato クラウドが通信先の FQDN をどのように識別しているのか気になりましたので、深掘りして調査検証し、いくつか浮かび上がってきた課題をここで説明します。 blog.usize-tech.com 2024.03.29 ECH とは何かざっくりと言いますと、TLS 通信においてクライアントが接続するサーバのドメイン名を保護するプロトコルです。ドメイン名そのものを機密にするものではなく、クライアントがどのドメイン名と通信するかを機密にするものです。 これまで、通信先のドメイン名を保護する技術として DNS 通信を暗号化する技術 (DNS over TLS / HTTPS / QUIC) や DNS の QNAME minimisation がありました。 それらによって名前解決の段階では通信先のドメイン名を保護できるものの、その後の TLS 通信を開始する際にクライアントが最初に送信する Client Hello メッセージにはサーバのドメイン名が暗号化されずに格納されています。そのため、通信経路上の監視者はクライアントの通信先のドメイン名を覗き見ることができてしまいます。 この課題を解決するために、通信先のドメイン名を暗号化して Client Hello に格納できるようにする標準技術として ECH が生まれました。 ECH の通信の流れ 基本的な通信の流れ ECH の基本的な通信の流れは次のようになります。 まず、クライアントは DNS の HTTPS レコードの名前解決を行い、ECH を作成するための暗号鍵とダミーのドメイン名を取得します。HTTPS レコードというものに馴染みのない方も居るかもしれませんが、2023年11月に標準化された DNS の新しいレコードタイプです。 次に、クライアントは TLS 接続を開始する際、本物のドメイン名を暗号化して Client Hello メッセージに埋め込み、外から見えるドメイン名の部分にはダミーのドメイン名を格納して送信します。これにより、本物のドメイン名を保護しつつ、通信経路上の監視者にはダミーのドメイン名と通信しているように見せることができます。 その後、サーバは Client Hello メッセージ内の暗号化されたデータを復号し、本物のドメイン名を取り出して適切に処理することで、最終的に TLS 接続が確立します。 TLS Inspection が有効な場合の通信の流れ Cato のように経路上で TLS Inspection を行う場合、通信の流れが少し変わってきます。 Cato が TLS Inspection を行う場合、Cato はサーバに成り代わって Client Hello メッセージを処理します。その際、Cato はメッセージ内の暗号化されたデータを復号できないため、本物のドメイン名を取り出すことができず、ECH にも対応していない Server Hello メッセージをクライアントに返すことになります。 クライアントは返ってきた Server Hello メッセージを見て、ECH が機能しないことを検知し、その TLS 接続をエラー終了させます。その後、ECH を使わない通常の TLS 接続にフォールバックし、本物のドメイン名を暗号化せずに Client Hello メッセージに格納して送信します。 それを受信した Cato は TLS を適切に処理できますので、クライアントと Cato との間で TLS 接続が正常に確立します。 ECH が Cato の通信に与える影響 ECH による TLS 接続が確立した場合、Cato はダミーのドメイン名しか認識できないため、本物のドメイン名に基づくセキュリティポリシーを適用できないことになります。さらに、本物のドメイン名を正しく認識できないことから、ドメイン名をもとに Cato が分類しているアプリケーションカテゴリやリスクスコアなどによる制御も適切に機能しなくなります。 そのため、Cato の基本的なセキュリティ機能である Internet Firewall や IPS に影響があり、本来ブロックすべき通信が通過してしまうという問題を引き起こします。 なお、ECH による TLS 接続が確立するということは TLS Inspection が有効ではない状態でもありますので、TLS Inspection が有効であることを前提としたセキュリティ機能 (IPSの一部、Anti-Malware、CASB、DLP など) には影響がありません。また、ECH による TLS 接続の前段階として本物のドメイン名の名前解決が行われますので、DNS Protection にも影響はありません。 ECH による通信の有無の確認方法 お客様の環境で ECH による通信が行われているかどうか、完全ではないものの確認方法はあります。 まずは、 ECH のテストサイト にアクセスしてみてください。 “You are using ECH.” と表示されれば ECH で通信が行われおり、”You are not using ECH.” と表示されれば ECH が使われていないことを示します。   また、テストサイト以外での ECH による通信を確認する方法として、Cato の CMA の Events 画面にて “Domain Name” がダミーのドメイン名であるイベントを確認する方法があります。 上記のテストサイトの場合ですと、ダミーのドメイン名は “public.tls-ech.dev” で、イベントには次のような記録が見つけられます。(TLS Inspection を有効にした環境での例で、本物のドメイン名のイベントも合わせて抽出しています。) 上の画像の中でも “Domain Name”, “Sub-Type”, “Action” の3つのフィールドに注目すると、ECH がどのように処理されているかが分かります。 表に書き起こすと次のようになっています。(古い時刻から順に並べ替えています。) 時刻 Domain Name Sub-Type Action 2026/03/27 09:44:18.078 public.tls-ech.dev Internet Firewall Monitor 2026/03/27 09:44:18.086 public.tls-ech.dev TLS Alert 2026/03/27 09:44:18.255 tls-ech.dev Internet Firewall Monitor まず最初に ECH を用いた TLS 接続が行われたため、Cato ではダミーのドメイン名でイベントが記録されており、Internet Firewall 機能は通過しています。 2つ目のイベントは TLS が Alert となっていますが、これは先ほどの説明の通り、Cato が ECH を処理できないためにクライアント (ブラウザ) が TLS 接続をエラー終了させていることを示しています。 3つ目のイベントは本物のドメイン名で記録されており、ECH を使わない通常の TLS 接続にフォールバックしたことを示しています。   2026年3月現在、ECH が有効な Web サイトは少なく、Cloudflare にホスティングされている Web サイトでしかまだ採用されていないように見受けられます。Cloudflare 上の Web サイトの場合、ダミーのドメイン名は全サイト共通で “cloudflare-ech.com” となっています。 “Domain Name” が “cloudflare-ech.com” であるイベントを確認し、Cato のいずれかのセキュリティ機能でブロックやエラー (Alert) となっていれば、ECH による通信は失敗していると判断できます。 ECH への対策方法 ECH によって Cato のセキュリティ機能が適切に働かない問題への対策方法はいくつか考えられ、現状で取りうる対策を以下に整理します。 1. TLS Inspection を有効にする 先ほどの説明や例の通り、TLS Inspection が有効であれば ECH による通信が失敗しますので、Cato のセキュリティ機能が適切に働きます。 TLS Inspection を有効にしていないお客様ですと、これを有効にすると既存の通信に多大な影響が及ぶため、この方法を採れないかもしれません。しかし、ダミーのドメイン名だけでも TLS Inspection を行うようにすれば ECH の問題を解消できますので、ご検討いただければと思います。 ただし、Cato では一部の OS (Android, Linux, その他不明なOS) の通信では TLS Inspection が行われないようになっていますので、それら OS が行う通信は ECH によってセキュリティ機能が働かないという問題があります。 2. ダミーのドメイン名の通信をブロックする ダミーのドメイン名の通信を Internet Firewall でブロックするというのも有効な対策です。ひとまず、”cloudflare-ech.com” 宛の通信をブロックすれば、現状では ECH に対策できていると言ってよいかと思います。 ただ、今後は Cloudflare 以外の Web サイトのホスティング事業者も ECH をサポートしてくることが予想されます。その場合、ダミーのドメイン名も事業者ごとに用意されるはずですので、ブロックすべきドメイン名を追加する運用も必要となってくる点に注意が必要です。 3. HTTPS レコードのクエリをブロックする もしもお客様が独自の DNS サーバをお使いであれば、その DNS サーバにて HTTPS レコードのクエリをブロックするという対策も考えられます。実際に試したわけではありませんが、Active Directory の DNS サーバをお使いであれば、HTTPS レコード (Type 65) をブロックする設定は可能だろうと思います。 ただ、OS やブラウザによっては意図しない DNS サーバを参照することもあるようですので、この方法も完全ではありません。 あとがき TLS Encrypted Client Hello (ECH) はインターネット標準のセキュリティ技術ではありますが、Cato のようなセキュリティサービスとは相性が悪い困った技術でもあります。 ECH によって引き起こされる問題への対策方法を3つ挙げましたが、1,2 の方法を両方とも採用することが現状での最適な対策と言えるかと思います。 しかし、現在行う対策が将来においても有効であるとは限らないため、Cato にて次のような機能が実装されることを期待しています。 クライアント OS を区別せず、ECH による TLS 接続を拒否する機能 (対策1の但し書きへの対応) ダミーのドメイン名であることを示す Application Category 定義の作成と随時更新 (対策2の但し書きへの対応) HTTPS レコードのクエリをブロックする機能(対策3の実現) ECH は Cato に限らず様々なセキュリティサービスでも同様の問題を引き起こすはずですので、不明点や疑問点などがありましたら何でもご相談いただければと存じます。 参考リンク RFC 9849: TLS Encrypted Client Hello Cato ナレッジベース: Website Hosted on Cloudflare Bypasses the Cato Firewall RFC 9460: Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)
こんにちは!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/