本記事は 春のスキルアップ応援フェア2026 4/24付の記事です 。 こんにちは、ひるたんぬです。 最近料理にハマっており、仕事終わりは可能な限り自分で料理を作ろうと心がけています。 そんな私はWebサイトに数多あるレシピのお世話になっているのですが、材料欄によく「少々」「ひとつまみ」といった記載を見かけます。これら二つを使い分けているレシピもあり、分量に差はあるのか気になったので調べました。 【少々のはかり方】親指と人差し指の2本で軽くつまむ。 【ひとつまみのはかり方】親指、人差し指、中指の3本の指で軽くつまむ。 引用：デリッシュキッチン「 料理の基本！少々・ひとつまみのはかり方 」 明確な違いがあったのですね。。。今まで「どっちも同じだろう」と思い投入していたので改めようと思います。 さて、今回は「春のスキルアップ応援フェア」ということでしたので、普段はAWSを中心に触っておりSnowflakeミリしらな私が、SnowflakeのCortex AIを活用して非構造化データの画像を検索できるようになるまでの道のりを記したものです。 長めの投稿となりますが、飛ばしながらでも最後まで温かく見守っていただけますと幸いです。 きっかけ 先日、社内勉強会にてSnowflakeについて知る機会がありました。 その中ではデータ活用の重要性を起点にSnowflakeの概要から強み、実際の導入事例までを座学で学んだほか、実際にSnowflakeの社員様にご登壇いただきサービスのデモを見せていただきました。 それまでは、「Snowflakeってデータ分析や活用ができる、なんかすごいツールが集まったもの」程度の認識だったのですが、デモの中で、 「画像のような非構造化データまで分析ができる」 ことを聞いたときに、これはすごい…！と思い、試すまでに至りました。 なお、その中でご紹介いただいたブログ記事はこちらです。 Snowflake で画像(非構造化データ)を AI で処理して検索できるようにしてみる zenn.dev また、上記ブログで紹介されている元の記事も参考にさせていただきました。 SQLだけで画像分類！SnowflakeのAI_CLASSIFY関数を試してみた zenn.dev 本記事でも、上記ブログ記事に沿って実際に手を動かしました。 Snowflake Cortex AIとは？ 公式サイトの文章が簡潔で分かりやすかったので、引用させていただきます。 データの存在する場所でAIを活用して、 会話、ドキュメント、画像をインテリジェントなインサイトに変換 できます。業界をリードするLLMにSQLで直接、またはAPIを介して大規模にアクセスし、マルチモーダルデータの分析と エージェントの構築 を、すべて Snowflakeのセキュアな境界内で実行 できます。  引用：Snowflake「 Cortex AI 」 ポイントとしては、以下が挙げられます。 会話、ドキュメント、画像をインテリジェントなインサイトに変換 → 非構造化データの中でも、そもそも文字データですらない画像からも情報抽出が可能 → 構造化データ・非構造化データを一箇所に集約可能 Snowflakeのセキュアな境界内で実行 → 大切なデータも安全に処理ができる 画像データを分類してみよう！ 下準備 今回私は初めてSnowflakeを触るので、アカウント開設から始めました。 Snowflakeでは30日間（もしくは$400到達のどちらか早い方）の無料お試しが利用できるので、今回は学習目的でこちらを使わせていただきました。 アカウント開設は、メールアドレスなどの必要事項を数点入力するのみで完了し、ものの5分程度でアカウントが発行されました。 また、参照元のブログ記事では車載カメラで撮影されたデータセットを用いておりましたが、折角なので違うデータセットで試すこととします。今回は飛行機の画像が含まれているデータセット¹を用意し利用しました。 ¹ Kaggle「 Commercial Aircraft Dataset 」 学習目的で任意のデータセットを利用する場合、権利関係にご注意ください。 今回のデータセットは「CC0」であり、クレジットを表記することなく利用が可能です。 参考：Creative Commons「 CC0 」 データ格納 Snowflakeでは「ステージ」という概念があります。これは、簡単に言えばデータを格納する場所です。 ステージ上にデータを保管し、Snowflakeテーブルとデータのやり取りをする、中継地点という考え方もできます。 ステージは、Snowflake Stageという「内部ステージ」と、パブリッククラウド（Amazon S3・Google Cloud Storage・Azure Blob Storage）上の「外部ステージ」に分けることができます。 更にこの「内部ステージ」は以下の3つに分類することができます。 ユーザーステージ【Snowflake管理ステージ】 → 各ユーザーにデフォルトで割り当てられているステージ。ファイルに対するアクセスが一人（＝そのユーザー自身）である場合に選択。 テーブルステージ【Snowflake管理ステージ】 → 各テーブルごとに自動で作成されるステージ。ファイルに対するアクセスが一つのテーブルである場合に選択。 名前付きステージ → 上記の制約が存在しないステージ。自由に作成が可能。外部ステージはここに位置する。 Snowflake上のドキュメントには、上記内部ステージの選択方針として以下のように述べられていました。 自分だけがロードするデータファイル、または単一のテーブルにのみロードするデータファイルをステージする場合は、ユーザーステージまたはデータをロードするテーブルのステージのいずれかを使用することをお勧めします。 名前付きステージはオプションですが、複数のユーザーやテーブルが関係する可能性のある通常のデータロードを計画する場合は、使用を 推奨 します。 引用：Snowflake Documentation「 ローカルファイルに対する内部ステージの選択 」 ステージの取り扱いについてはなんとなく理解することができました。 今回の処理は、ユーザーステージやテーブルステージで実施することはできません。必ず名前付きステージを作成して作業を行ってください。 参考：Snowflake Documentation「 AI_CLASSIFY – Limitations 」「 AI_FILTER – Limitations 」 ステージの作成 ここからは実際にSnowflake上のリソースを操作していきます。 SnowflakeはコンソールのGUIでも操作はできますが、SQLでもできるため、今回はできる限りSQLを使って作業していきたいと思います。 SQLのコマンド実行環境はSnowflake上のWorkSpaceを使用します。 まず、Snowflake内部に名前付きステージを作成します。 ステージ名は「AIRCRAFT_IMAGE_STAGE」としました。 なお、このタイミングでデータベースも併せて作成します。 CREATE DATABASE AIRCRAFT_DB; CREATE OR REPLACE STAGE AIRCRAFT_DB.PUBLIC.AIRCRAFT_IMAGE_STAGE ENCRYPTION = (TYPE = 'SNOWFLAKE_SSE'); ステージの作成時には、暗号化オプションを忘れずにつけるようにしてください。 デフォルトのクライアントサイドでの暗号化では、後述するAI_CLASSIFY、AI_FILTERなどの処理を行うことができません。 実際に作成できたかも確認します。 SHOW DATABASES STARTS WITH 'AIRCRAFT_DB'; SHOW STAGES STARTS WITH 'AIRCRAFT_IMAGE_STAGE'; それぞれ作成されていることが確認できました。 画像のアップロード 取得した画像を先程作成したステージに格納します。 WorkSpace上にImagesフォルダを作成、フォルダ内に画像ファイルを準備し、ステージにアップロードします。 ファイルのアップロードを一度に行うとフリーズしてしまったので、数回に分けて行いました。 私の環境では1,000枚程度であれば一度に作業できました。 ちょっと動作を確かめたい場合は、全部アップロードしなくても良かったですね…後述しますが、 すべての画像のアップロードは、おすすめしません。 今回はWorkSpaceで作業してみたかったため、画像をWorkSpaceにアップロードする必要がありましたが、Snowflake CLIを利用することで、ローカル環境から直接ステージにファイルを転送することも可能です。 ローカルファイルシステムからのデータファイルのステージング | Snowflake Documentation docs.snowflake.com WorkSpaceへのアップロードには、ブログ記事を参考に以下のコマンドを用いました。 PUT file:///snow://workspace/USER$.PUBLIC.DEFAULT$/versions/head/Images/*.jpg @AIRCRAFT_IMAGE_STAGE; しかし、上記コマンドで試したところ以下のようなエラーが表示されました。 Unsupported feature ‘unsupported_requested_format:snowflake’. ここでコンソール上には「💠Fix」の文字が。。これをクリックすると、Cortex Codeによる問題解決が始まりました。 Cortex Codeによると、 Replaced   PUT   with   COPY FILES INTO .   The   PUT   command   isn’t   supported   in   Snowsight   —   COPY FILES INTO   is   the   workspace-compatible   way   to   upload   files   from   a   workspace   to   a   stage.   Also   changed   versions/head   to   versions/live   (the   correct   workspace   path). とあり、PUTコマンドは SnowSight ²ではサポートされていない、代わりにCOPY FILES INTOコマンドを使うように案内されていました。 今回はこちらに従い修正を受け入れると、問題なく実行できるようになりました。 ² SnowSightとは、PythonやSQLでSnowflake上のデータを操作するWebインターフェースのことです。 修正後のコードはこちらです。 COPY FILES INTO @AIRCRAFT_IMAGE_STAGE FROM 'snow://workspace/USER$.PUBLIC.DEFAULT$/versions/live/Images/' PATTERN = '.*\.jpg'; なお、PUTコマンドが使えないことについては、公式ドキュメントにも記載がありました。 コマンドは、いずれのSnowflakeウェブインターフェイスの  Worksheets ページからも実行できません。 引用：Snowflake Documentation「 PUT – 使用上の注意 」 また、今回はWorkSpaceで作業してみたかったため、画像をWorkSpaceにアップロードする必要がありましたが、Snowflake CLIを利用することで、ローカル環境から直接内部ステージにファイルを転送することも可能です。 ローカルファイルシステムからのデータファイルのステージング | Snowflake Documentation docs.snowflake.com 外部ステージへのファイル転送は、それぞれのサービスで用意されているコマンドやコンソールを使用します。 一通りのアップロードを終えたら、無事にファイルが格納されていることを確認します。 SELECT * FROM DIRECTORY(@AIRCRAFT_DB.PUBLIC.AIRCRAFT_IMAGE_STAGE); しかし、ここでもエラー… DIRECTORY not enabled for the stage AIRCRAFT_IMAGE_STAGE 日本語約すると、作成したステージでは、DIRECTORYが有効化されていないとのことでした。そもそもこの「DIRECTORY」というものがどういうものか分からなかったので、その理解から始めます。 ディレクトリテーブルは、ステージで複数層になった暗黙のオブジェクトで（独立したデータベースオブジェクトではない）、 ステージ内のデータファイルに関するファイルレベルのメタデータを格納する ため、概念的には外部テーブルに似ています。 引用：Snowflake Documentation「 ディレクトリテーブル 」 ステージ内に格納したファイルのメタデータを格納するテーブル、と理解しました。 ディレクトリテーブルはステージの作成時に作ることもできますが、今回は既にステージを作っていたので、ステージのプロパティ変更コマンド（ALTER STAGE）を使用します。 ディレクトリ作成後は、メタデータ更新のため、手動でリフレッシュコマンドを実行します。 ALTER STAGE AIRCRAFT_DB.PUBLIC.AIRCRAFT_IMAGE_STAGE SET DIRECTORY = (ENABLE = TRUE); ALTER STAGE AIRCRAFT_DB.PUBLIC.AIRCRAFT_IMAGE_STAGE REFRESH; 上記が完了したら、改めて確認をします。 SELECT * FROM DIRECTORY(@AIRCRAFT_DB.PUBLIC.AIRCRAFT_IMAGE_STAGE); 無事にアップロードできていることを確認できました！ 上記の解決にもCortex Codeの力をお借りしました。 画像分類項目の検討 いよいよここからはCortex AIを用いた画像分析に入ります。 今回はブログでも紹介されていた関数のうち、AI_FILTER関数とAI_CLASSIFY関数を使います。 AI_FILTER関数   ランディングギアは出ているか ※ 車輪のことです。 四発ジェット機か ※ ジャンボジェットのようにエンジンが4発の航空機のことです。 着陸しているか 日本航空（JAL）、もしくは全日本空輸（ANA）の航空機か AI_CLASSIFY関数 各画像の天候のラベル付け 晴れ 曇り 雨 航空機が所属するアライアンスのラベル付け Oneworld Star Alliance SkyTeam 所属なし 紹介されていたブログの項目を参考に王道からチャレンジングな項目まで設定しました。ブログ記事ではAI_CLASSIFY関数でトヨタ車の検出ができていたようだったので、AI_FILTER関数で同じようなことができるか検証します。また、そこから少し踏み込み、航空会社を判別したうえで、その航空会社が所属するアライアンスを分類できるかを試します。 いよいよ実践！ すべての準備が整ったので、実際に分類をしていきます。 実践①：AI_FILTER AI_FILTER関数は、自然言語によるプロンプト入力の結果をブール値で返す関数です。テキストはもちろんですが、今回実験するような画像に対する処理も対応しています。 AI_CLASSIFY | Snowflake Documentation docs.snowflake.com ランディングギアの判別 SELECT RELATIVE_PATH AS FILE_NAME, AI_FILTER( 'この画像の航空機は、ランディングギアは出ていますか？', TO_FILE('@AIRCRAFT_DB.PUBLIC.AIRCRAFT_IMAGE_STAGE', RELATIVE_PATH) ) AS SHOW_LANDINGGEAR FROM DIRECTORY(@AIRCRAFT_DB.PUBLIC.AIRCRAFT_IMAGE_STAGE); TRUEと判別されたのは6,070枚でした。いくつかピックアップしてみます。 様々な角度の画像がありますが、どれもランディングギアが出ていることが分かります。 逆に、FALSE（ランディングギアが出ていない）と判別された結果も、いくつかピックアップしてみます。 こちらもランディングギアが出ていないものが多かったです。 ただ、一部（上図右下）ではちょうどしまっているところなども、FALSEと検出されていました。判断に迷うところですね。。 四発ジェット機の判別 SQL文は自然言語での指示部分、及び結果を整理するインデックス名以外は変更がありません。 SELECT RELATIVE_PATH AS FILE_NAME, AI_FILTER( 'この画像の航空機は、四発ジェット機ですか？', TO_FILE('@AIRCRAFT_DB.PUBLIC.AIRCRAFT_IMAGE_STAGE', RELATIVE_PATH) ) AS IS_QUADJET FROM DIRECTORY(@AIRCRAFT_DB.PUBLIC.AIRCRAFT_IMAGE_STAGE); TRUEと判別されたのは679枚でした。いくつかピックアップしてみます。 こちらもどれも四発ジェット機ですね。上図右下のANAは画像全体がかなり霞んでいますが、正しく判別できています。 着陸しているかの判別 SELECT RELATIVE_PATH AS FILE_NAME, AI_FILTER( 'この画像の航空機は、着陸していますか？', TO_FILE('@AIRCRAFT_DB.PUBLIC.AIRCRAFT_IMAGE_STAGE', RELATIVE_PATH) ) AS IS_LANDING FROM DIRECTORY(@AIRCRAFT_DB.PUBLIC.AIRCRAFT_IMAGE_STAGE); TRUEと判別されたのは681枚でした。いくつかピックアップしてみます。 どの航空機も着陸した状態です。 JALまたはANAの航空機の判別 SELECT RELATIVE_PATH AS FILE_NAME, AI_FILTER( 'この画像の航空機は、JALもしくはANAの航空機ですか？', TO_FILE('@AIRCRAFT_DB.PUBLIC.AIRCRAFT_IMAGE_STAGE', RELATIVE_PATH) ) AS IS_JAL_ANA FROM DIRECTORY(@AIRCRAFT_DB.PUBLIC.AIRCRAFT_IMAGE_STAGE); TRUEと判別されたのは84枚でした。いくつかピックアップしてみます。 しっかり分類されていましたね！ Oneworld塗装やStar Alliance塗装の機体まで分類できている点、JAL Expressという、かつて存在したJALグループの便まで検出できている点は驚きでした。 JALのロゴ、懐かしいですね。。 実践②：AI_CLASSIFY AI_CLASSIFY関数は、指定されたカテゴリに分類をする関数です。こちらの関数もテキスト・画像両方に対応しています。 AI_CLASSIFY | Snowflake Documentation docs.snowflake.com 天候のラベル付け SELECT RELATIVE_PATH AS FILE_NAME, AI_CLASSIFY( TO_FILE('@AIRCRAFT_DB.PUBLIC.AIRCRAFT_IMAGE_STAGE', RELATIVE_PATH), ['晴れ', '曇り', '雨'] ):labels[0]::STRING AS WEATHER_CATEGORY FROM DIRECTORY(@AIRCRAFT_DB.PUBLIC.AIRCRAFT_IMAGE_STAGE); 晴れが5,013枚、曇りが1,491枚、雨が33枚でした。 ▼ 晴れ ▼ 曇り ▼ 雨 AI_FILTERと異なり、はい・いいえの二択で判断できないので中々評価が難しいところではありますが、明らかに間違えている、と言えるものは無さそうでした。 「曇り」画像の左下は人間だと「晴れ」と答えそうですが、気象庁における天候の定義に基づくと誤りでは無さそうです。すごいなぁ…と感心してしまいました。 雲量が0から1のときは「快晴」、2から8のときは「晴れ」、9から10のときは「くもり」としています。 引用：気象庁 はれるんライブラリー「 雲の量と天気の「快晴」「晴れ」「くもり」の関係は？ 」 アライアンスのラベル付け いよいよ、難関と思われる問題です。 SQL文はラベルカテゴリとインデックス名が変わる程度で、大きな違いはありません。 SELECT RELATIVE_PATH AS FILE_NAME, AI_CLASSIFY( TO_FILE('@AIRCRAFT_DB.PUBLIC.AIRCRAFT_IMAGE_STAGE', RELATIVE_PATH), ['Oneworld', 'Star Alliance', 'SkyTeam', '所属なし'] ):labels[0]::STRING AS ALLIANCE_CATEGORY FROM DIRECTORY(@AIRCRAFT_DB.PUBLIC.AIRCRAFT_IMAGE_STAGE); Oneworldが507枚、Star Allianceが1,218枚、SkyTeamが659枚、所属なしが4,153枚でした。 ▼ Oneworld マレーシア航空：○ イベリア航空：○ （旧）メキシカーナ航空：○ ※ （旧）メキシカーナ航空は運行停止 日本航空：○ フィンエアー：○ アメリカン・イーグル（アメリカン航空グループ）：○ ※ アメリカン・イーグルはアフィリエイトメンバーです。 ▼ Star Alliance ルフトハンザドイツ航空：○ ユナイテッド・エクスプレス（ユナイテッド航空グループ）：○ ※ ユナイテッド・エクスプレスはアフィリエイトメンバーです。 オーストリア航空：○ LOTポーランド航空：○ 全日本空輸：○ TAPポルトガル航空：○ ▼ SkyTeam デルタ航空：○ KLMオランダ航空：○ エールフランス：○ デルタ・コネクション（デルタ航空グループ）：○ ※ デルタ・コネクションはアフィリエイトメンバーです。 中国東方航空：○ アルゼンチン航空：○ …という訳で、なんと抽出したものはすべて合っていました。。びっくりです。単純に航空会社を認識するだけでなく、その先のアライアンスまで認識して分類できる能力はありそうですね。 結果の整理 それぞれのSQL文の実行結果は画面上にテーブル形式で出力されるほか、CSV形式でのダウンロードも可能です。 これでももちろんいいのですが、データ活用という観点からすると、これらの結果をSnowflake上で活用できる形で管理したいと思います。この場合には、テーブルを用意して結果を保存します。 しかし、私はSQL文の中にTABLEの作成を入れ忘れていました… 再実行、、、が頭によぎりましたが、ここで朗報です。 Snowflakeではクエリの実行結果が24時間保存されます。 RESULT_SCAN | Snowflake Documentation docs.snowflake.com まさに、今の私のためだけに作られたような機能…！早速この「RESULT_SCAN」を使ってテーブルを作成していきます。 ここで必要になるのが、クエリ実行結果のIDです。 これもSQLで検索することが可能ですが、今回はWorkSpace上ですぐ特定できたため、そちらの方法を採用しました。 実際のSQL文も併せて表示されるため、迷うことは無さそうです。 これを使ってテーブル作成のSQL文を作成し、実行します。 CREATE OR REPLACE TABLE AIRCRAFT_DB.PUBLIC.RESULT_LANDINGGEAR AS SELECT * FROM TABLE(RESULT_SCAN('00c11e3b-1234-8aba-5678-231a00012345')); これをクエリの数繰り返し、計6つのテーブルを作成することができました。 最終的にこれを一つのテーブルにまとめます。 今回はこの方法をCortex Codeに聞いてお願いしました。 抽象的な表現かつ日本語ですが、うまく動いてくれるのでしょうか… Cortex Codeは、今までのSQLの中身を確認したあと、それぞれの結果のテーブルを確認し、SQL文を生成してくれました。 生成内容を確認するに、きちんと指定名でのテーブルを作成し、その中にすべての結果をLEFT JOIN関数を用いて結合させていることがわかります。 問題はなさそうだったので、この結果を受け入れます。 するとCortex Codeではコードの実行と検証が実施され、問題ない旨回答をもらいました。検証まで一連の流れで行ってくれるのはありがたいですね。 最終的な回答文も日本語でした。 おまけ：分類に失敗したと思われる画像 さて、ここまででこの機能のすごさは少しでも感じていただけたでしょうか？ 一方、AIに絶対はない、と言われているのが今日です。ここでも実際の分類結果から、あり得ないシチュエーションを設定し、そこに分類された画像を見てみようと思います。 パターン①：JAL or ANA × SkyTeam 上記の結果にもありますが、JALはOneworld、ANAはStar Allianceなので、このパターンの結果は存在し得ないはずです。しかし、この結果を示すものが一件だけありました。 ロゴを見ればJALと一目で分かりますが、尾翼の緑色が特殊ですね。これにより結果が揺らいでしまったのでしょうか… パターン②：ランディングギアが出ていない × 着陸状態 飛行機では着陸時にランディングギアを出します。 上記の状態は通常の着陸では起こらないはずですので、このパターンは存在し得ないはずです。しかし、この結果を示すものが35件ありました。 実際の画像をすべて確認すると、すべて着陸状態で、かつランディングギアは出ている状態でした。 つまり、ランディングギアの判別が誤っているということになります。 一方、正常に判別できている結果と比べると、ランディングギアが主翼や影で隠れて見えない（見えにくい）画像が多い…？と感じました。この点を表現としてプロンプトに加えることで、精度改善につながるのでは、と考えています。 PROMPT | Snowflake Documentation docs.snowflake.com この改善に挑戦しようとしたところで、一通のメールが… 6,000枚の画像を無計画に分析したからですね。。2日間で$400を使い切ってしまったようです。 プロンプトによる精度改善の検証は、今後の課題にしたいと思います。 皆様が同じように試される場合は、事前にサイズを圧縮する・枚数を減らすなど工夫をされることを心よりおすすめいたします… おわりに 今回はSnowflakeのAIサービス「Cortex AI」を活用して、非構造データの代表格である画像データの分類に挑戦してみました。 SQLに触れることが3年前の新人研修以来だった私にとって、不安なことが多かったのですが、ほんの数行書くだけ、しかもパッと見ただけで処理内容が分かるような記述に感動しました。 また、今回の学習では数多くのエラーに遭遇しましたが、そのたびにCortex Codeが助け舟を的確に出してくれ、効率的に学習を進めることができました。 もちろん、公式ドキュメントでの裏取りも行ったので、今まで以上に深く物事が学べている印象です。 ワタシハ スノーフレーク チョットデキルに一歩でも近づけたのでしょうか… コミュニティのあり方からLinuxの未来まで ─LinuxCon Japan 2014、Linus Torvalds氏キーノート発言集 | gihyo.jp 5月20日～22日の3日間、東京・椿山荘で開催中の「LinuxCon Japan 2014」2日目最後のキーノートはこの人、Linuxの生みの親でありカリスマ的存在と言えるLinus Torvaldsさんの登場です。 gihyo.jp

本記事は 春のスキルアップ応援フェア2026 4/23付の記事です 。 皆さんこんにちは！ 気づいたらToDoの数がとんでもなく増えていきがち。 どうも、いとさんです。 実は、人間は「完了したこと」よりも「やり残していること」の方を強く覚えてしまう ゼイガルニク効果 という性質があるそうです。 リストが増えれば増えるほど、脳が勝手に「あれもやってない、これもやってない」と通知を出し続けている状態なんですね。バックグラウンドで常にタスクが動いているようなもので、これでは脳が休まる暇もありません。 参考・引用： 「中途半端に終わっているものほどよく覚えている『ゼイガルニク効果』とは」 引用： リクナビNEXTジャーナル この「脳内のバックグラウンドプロセス」を終了させてスッキリさせるためには、まずは情報を頭の外に追い出すことが不可欠です。 さて今回は、 「飲みの場で決まった予定」や「やるべきこと」 を、スマホからサッと入力して自分に通知したい。そんな願いを、GoogleフォームとGoogle Apps Script（GAS）だけで叶える個人開発に挑戦しました。 🛠 実装ステップ：自分専用ToDo通知Botの作り方 今回の開発は、大きく分けて 3つのフェーズ で進めます。 入力インターフェース（Googleフォーム）の作成 プログラム（GAS）の実装 自動実行（トリガー）と権限の承認 ステップ1：入力インターフェース（Googleフォーム）の作成 まずはToDoを入力するための窓口を作ります。 Googleフォーム を新規作成します。 以下の2つの質問を用意します。 タイトル： ToDoの内容 （記述式） タイトル： 期限 （日付） 「回答」タブを開き、「スプレッドシートに表示」をクリックして、回答保存用のシートを新規作成します。 ステップ2：プログラム（GAS）の実装 次に、データをメールに変換して飛ばす機能を実装します。 スプレッドシートを新規作成します。 スプレッドシートのメニューから 「拡張機能」 ＞ 「Apps Script」 を開きます。 表示されたエディタ（コード.gs）の中身を一度空にして、以下のコードを貼り付けます。 /** * フォーム送信時に実行されるメイン関数 */ function onFormSubmit ( e ) { // 1. フォームの入力内容を受け取る // 質問タイトルと一文字も違わないように注意！ const item = e.namedValues[ 'ToDoの内容' ] ? e.namedValues[ 'ToDoの内容' ][ 0 ] : "項目なし" ; // 2. 期限のデータを取得し、文字化けを防ぐ処理 let deadline = "期限なし" ; if (e.namedValues[ '期限' ] && e.namedValues[ '期限' ][ 0 ]) { try { // 日付を「yyyy/MM/dd」の形式に整形 const dateObj = new Date (e.namedValues[ '期限' ][ 0 ]); deadline = Utilities.formatDate(dateObj, "JST" , "yyyy/MM/dd" ); } catch (err) { // 変換失敗時はそのままの文字を使用 deadline = String (e.namedValues[ '期限' ][ 0 ]); } } // 3. 送信先（自分のGmail）を設定 // ※ ここを自分のアドレスに書き換え const recipient = 'your-email@gmail.com' ; // 4. メールの内容を組み立てる const subject = "✅【ToDo通知】" + item; const body = ` ━━━━━━━━━━━━━━━━━━ ✅ 内容: ${item} ✅ 期限: ${deadline} ━━━━━━━━━━━━━━━━━━ ※このメールはGoogle Apps Scriptから自動送信されています。 ` ; // 5. GmailAppを使って送信 try { GmailApp.sendEmail(recipient, subject, body); console .log( "送信成功！" ); } catch (error) { console .error( "送信に失敗しました: " + error.toString()); } } ステップ3：自動実行（トリガー）と権限の承認 ここが一番の難所でした。 GASエディタ左側の 「時計アイコン（トリガー）」 をクリックします。 右下の 「トリガーを追加」 を選択。 実行する関数： onFormSubmit イベントのソース： 「スプレッドシートから」 イベントの種類： 「フォーム送信時」 「保存」を押すと、Googleアカウントの承認画面が出ます。 自分のアカウントを選択 ＞ 「詳細」 ＞ 「（プロジェクト名）に移動（安全ではない）」 ＞ 「許可」 をクリック。 これの意味が分からず永遠と安全なページに戻る(BACK TO SAFETY)を押し続けていました…。 1. なぜこの画面が出るのか？ セキュリティ上の保護 Google Apps Scriptは、スプレッドシートの読み書きやメールの送信など、強力な操作が可能です。悪意のあるプログラムが勝手にデータを操作しないよう、Googleは「公式に審査・承認されたアプリ」以外が動こうとすると、ユーザーに注意を促す仕組みになっています。 「未承認」の状態だから あなたが自分で作ったスクリプトや、社内で共有されたばかりのスクリプトは、Googleによる個別の安全審査（認証）を受けていません。そのため、「どこの誰が作ったかわからない（Googleが保証していない）アプリが動こうとしていますよ」という警告が出ます。 自分で作成したスクリプトであれば、安全だとわかっているため、上記の手順で進めることができます。 ⚠️注意 信頼できるか確認する： 自分が書いたコードや会社から受け取ったものであれば問題ありません。 知らない人からのリンクは避ける： 全く知らない人が作ったスクリプトでこの画面が出た場合は、安易に許可しないよう注意してください。ドライブ内のファイルが盗まれたり、勝手にメールを送られたりするリスクがあります。 無事承認が完了するとトリガーが作成されます。 🧪 動作確認：いざ、テスト送信 設定が終わったら、エディタの「実行」ボタンは押さず、 実際のGoogleフォーム からデータを送ります。 フォームのプレビュー画面から「お昼は友達とランチ」と入力して送信。(日付はデフォルトから変更しないと期限なしで送信されました) 自分のメールフォルダを開き、数秒後に「 ✅ 【ToDo通知】」という件名のメールが届いていれば……完成です！ テストも含めた実行ログは先ほど作成したスプレッドシートにきちんと保存されていました。(テスト中の眠気の凄さがうかがえますね) 💡実装で学んだエラーが出たらここを確認 「undefined」と出る： フォームの質問タイトルと、コード内の ['ToDoの内容'] が完全に一致しているか確認する。 メールが届かない： トリガーが正しく設定されているか、メールアドレスが正しく入力されているか見直しする。 ✨ まとめ 今回の開発を通じて、「エラーメッセージをよく読むこと」と「一つずつ権限を確認すること」の大切さを学びました。 「今日は推し活なので早く寝る」といった些細なToDoも、自作ツールから届くと少し特別な気分になりますね。 次は、期限の前日に自動でリマインドを送る「定期実行機能」や自動でカレンダーに予定を追加してくれる機能を追加して、さらに便利にしていきたいと思います！ ありがとうございました！

本記事は 春のスキルアップ応援フェア2026 4/22付の記事です 。 こんにちは！SCSKサイトーです🐧 Snowflake を触り始めると、避けて通れない資格の1つが  SnowPro Core です。 今回は、その SnowPro Coreに合格したので、概要・難易度・勉強方法等についてまとめてみます。 これから受ける方の参考になれば幸いです！ SnowPro Core 試験の概要 SnowPro Core は、Snowflake が公式に提供している認定資格の1つです。 Snowflakeをある程度業務で触っている 中級者向けの資格 です。 試験時間 ：115分 問題数 ：100問（選択式） 出題範囲 ： Snowflake AIデータクラウドアーキテクチャの使用 Snowflakeアカウントおよび仮想ウェアハウスの管理 データのロード、アンロード、および変換の実行 構造化データ、半構造化データ、および非構造化データの使用 パフォーマンスの監視および最適化 データコラボレーションおよびデータ保護の有効化 Snowflake接続の確立 ※26/4/10時点の内容です SnowPro® Core認定の概要 (COF-C03) – Snowflake   難易度感 AWSの世界でいう「AWS SAA」、Azureでいうと「AZ-104」あたりに近い立ち位置だと感じました。 Snowflake を「触ったことはある」だけだと、解けない問題が多いです。 （例：ResultキャッシュとWarehouseキャッシュが保持される期間の違い） まさに Snowflake 技術者の登竜門 、という表現がしっくりきます。   アウトプット用に使った教材（Udemy） アウトプットとしては、以下の Udemyの問題集を使いました。 Snowflake Snowpro Core: Certification Exam Questions COF-C03 *** Updated February 2026: 40 new questions added, including updated COF-C03 exam content. ****** 2025 Updates (11 updat... www.udemy.com かなりの問題数があり、以下の用途で主に使いました！ 試験形式に慣れる 自分の弱点がどこかを可視化する   やって良かった勉強法：問題を解いて、間違いを“分類”する 自分がやった勉強方法は以下の通りです。 平日は1時間・休日は2時間ほど取り組み、約3か月で合格できました！ ① とにかく問題を解く ② 間違えた問題を「分類」したノートを作る ③ 公式ドキュメントで裏取り   特に 分類 が重要でした。 例えば、こんな感じです。 Edition Standard / Enterprise / Business Critical/ VPSの違い COPY INTO 圧縮形式、エラー時の挙動 FILE FORMAT / ON_ERROR 周り データ共有 External Stage Data Sharing レプリケーション 「なんとなく知っている」が一番危険で、 試験はその“なんとなく”では解けない問題を多く出題されます。。   まとめ SnowPro Core は、 Snowflakeを業務で触るなら一度は通る道 なんとなくの理解では突破できない オススメの勉強法は「問題 → 間違い → 分類 → ドキュメント」 という、Snowflake技術者として成長できる試験でした。 次は さらに難易度の高い SnowPro Advanced の受験を考えています。 合格したら、ぜひ体験記をお伝えできればと思います！

以下の記事で、 AIセキュリティの概要 、およびそれに対するソリューションである 「Cato AIセキュリティプラットフォーム」 について簡単に 機能紹介 させていただきました。 Cato AI セキュリティプラットフォームとは？～AIセキュリティ課題を解決する新たなソリューション～ AI活用が進む中で、「シャドーAI」や情報漏洩、AI特有の攻撃など、新たなセキュリティ課題が企業で問題になっています。本記事では、AIセキュリティの主なリスクを整理するとともに、それらを解決するソリューションとしてCato Networksが提供する「Cato AIセキュリティプラットフォーム」を解説します。ユーザーによるAI利用の保護から、自社AIアプリケーションを守るAIファイアウォールまで、企業のAI利用を安全にする仕組みをわかりやすく紹介します。 blog.usize-tech.com 2026.04.15   本記事では上記が提供する機能のうち、 「ユーザー向けAIセキュリティ」 、つまり 「AIを利用する」 側のセキュリティについて、 「どのようにユーザーのAI利用を可視化・ブロックできるのか」 、及び 「どのように設定するのか」 を中心に、実際の検証とともに詳細解説していきます。   ユーザー向けAIセキュリティ概要 Catoが提供する ユーザー向けAIセキュリティ機能 は現状、以下の 3つ となります。（前回記事より再掲） No. 機能 説明 1 シャドーAIの検出 利用中のすべてのAIをツールごとに可視化 2 プロンプト＆アクションの可視化 ユーザーの プロンプト・アクションを可視化 し、 許可される操作を制御 3 AIインタラクションDLP（Data Loss Prevention） 機密情報を自動的にマスキングしたり、高リスク情報の送信をブロックしたりすることで、 意図しない情報漏洩を防止   各機能についてのより具体的な設定方法や検証結果についてを、本記事では見ていきます。 なお、上記機能の利用は、 Catoクラウドを経由して行われる通信 が前提となります。 そのため今回の検証については、事前に Catoの管理コンソール上でのユーザー作成及び、Catoクラウド経由での通信を実現 したうえで実行しておりますので、その点ご認識ください。   ① シャドーAIの検出 まずは、組織内でどのAIサービスが利用されているかを確認する 「シャドーAI検出」 についてです。 本機能により、主に以下の確認が可能です。 ・「誰が」が「 どのAI」を「 いつ」 利用したか ・検出したAIツールの危険度 設定と確認方法 設定方法 本機能については、 Catoクラウドを経由した通信であれば 、 設定なしに自動で検出が可能 です。 特別な設定が不要なのはありがたいですね！   検出結果の確認方法・確認できる内容 検出した AIツールの確認 については、 Catoの管理コンソール で以下のようにして実施可能です。 [AIセキュリティ] タブを選択 メニューバーより、 [Discovery] を選択 環境内の 全ユーザーが利用しているAIアプリケーション を、 自動で判定されたAIツールの危険度（High、Middle、Low） とともに、 ダッシュボードで一元的に確認 できます。 なお、デフォルトは 過去2日以内 の利用状況が表示されますが、 期間指定 も可能です。   それぞれのAIツール項目を選択すると詳細画面となり、ダッシュボードに表示された項目以外にも、 ・AIツールの詳細（カテゴリー、危険度と脅威の選定理由） ・選択したAIツールの1日あたりの利用者数 ・利用ユーザー名 ・適用されているセキュリティポリシー（セキュリティポリシーの具体的内容については後述） といった内容が確認可能です。   検証～Microsoft Copilot、ChatGPTのログインなしでの利用～ 検証として、 個人ユーザー向けのMicrosoft CopilotやChatGPT をログインなし（＝企業向けアカウント以外）で利用し、 利用AIとして検出 されるか、及び 危険度の判定 はどうなるかを検証してみました。 （あくまで未ログイン状態での利用は 検証目的 です、もちろん 通常の勤務時のAI利用 は企業アカウントで、適切な設定を実施したうえでご利用ください！）   1. Microsoft Copilot、ChatGPTの利用 まずはMicrosoft Copilot、ChatGPTそれぞれ、ログインなしで使ってみます。 プロンプトは「テストです。挨拶を返して」など適当な文言で実施しました。   2. Catoの管理コンソールでの確認 その後、Catoの管理コンソールに移り、確認を実施します。 画像のように、いずれも セキュリティレベル（危険度）が「High」 で登録されていました。 詳細を開きより理由確認すると、ログインなしで利用する場合は プロンプトが学習に利用されるため、高リスク ということが示されていました。 上記の検証のように、AIツールでも、 個人版（及びログインなし）か商用版かで正しく識別してくれる のは安心ですし、危険度レベルの理由も示してくれるので、ありがたいですね。 また詳細画面より、 利用ユーザーや最終使用日も可視化できること が確認できました。 このように、 「誰が」が「 どのAI」を「 いつ」 利用したかをAIツールごとに危険度 とともに可視化できます。   ② プロンプト＆アクションの可視化 次に見ていくのは、 「プロンプト・アクションの可視化」 機能です。 ユーザーがどのAIを利用しているのかに加えて、 「どんなプロンプトを入力しているか」 や 「どんなアクションを実行しているか」 はセキュリティにおいて非常に気になるところだと思います。 本機能により、 ・「誰が」が「 どのAIを利用して」「 どんなプロンプト」 を実行したか を条件ごとに可視化できます。 設定と確認方法 設定方法 設定については、以下2つの場合で必要な対応が少し異なります。（②だと①の内容に加えて追加でエンジンプロファイルの設定が必要） ① ある特定のAIツールについて 、すべてのプロンプト・アクションを可視化したい ② ある特定のAIツールについて、 特定の条件（プロンプト内容）のみ可視化したい 実は②については、後ほど紹介する AIインタラクションDLP設定時 に利用する「 エンジンプロファイル」 を使うという違いがあるだけで、それ以外の設定は ①と同じ になります。 エンジンプロファイル については、 AIインタラクションDLP の設定時に詳しく説明するので、本項では ①に絞って解説 していきたいと思います。   設定① User Interaction Policyの設定 まず、 [AI Securty]タブ – [User Interaction Policy]メニュー 選択します。 本メニューでは、 ユーザーがAIに対してプロンプトを実行した際のアクション（可視化・ブロック・難読化等）を定義 します。 プロンプトの可視化及び 、 ③AIインタラクションDLP での ブロック・難読化設定 にも共通で利用する設定項目となります。 早速、画面右部の [New]-[New NetWork Rule] を選択して、新規ポリシーを作成していきます。 その際の 具体的な設定項目 は以下の通りです。（エンジンプロファイルを除き 必須項目 ） No. 設定項目 説明 選択可能な内容 1 General ポリシー名・ポリシーの説明 自由に設定 2 Source ポリシーを設定する ユーザー Any（全ユーザー） 特定ユーザー（複数選択可） 特定ユーザーグループ（複数選択可） 3 Applications ポリシーを設定する AI Gemini関連、Copilot関連、ChatGPT関連 、 Claude 、Perplexity、DeepSeek、Grok等 4 Engine Profile ポリシーに適用する エンジンプロファイル   エンジンプロファイルを自由に選択 ※特定のAIすべての通信を可視化したい場合は設定不要 5 Action ポリシー合致したプロンプトへの アクション ①アクション 　Block （ブロック・可視化も行う） 　Monitor （可視化のみ） 　Annoymize＆Block （難読化＆ブロック） 　Annoymize＆Monitor （難読化＆可視化）                                ※Monitor all sessions for selected appsにチェックを入れればエンジンプロファイルを選択不要になる ②通知 ON ・ OFF のいずれか ③Frequency(頻度）（通知ON時のみ） Hourly・Daily・Weekly・ 　Immediate(即時) のいずれか ④通知先（通知ON時のみ） SubscriptionGroup MailingList WebHook のいずれか [Action]の項目で、Monitor とすると 「可視化」のみ、Block とすると 「可視化＆ブロック」、 Annoymize は 「難読化」で、制御したい情報（個人情報等） が AIに届く前に、 Cato側で 難読化して送信 してくれます。 今回のように、 特定のAIに対するプロンプトすべてを可視化 したい場合には、記載しているように、 [Action]の Monitor all sessions for selected appsにチェックを入れましょう。 （エンジンプロファイルの設定が不要になります） 設定が完了した後は、 [Save] を押下しましょう。   設定② ポリシー設定の有効化 設定完了したただけでは有効化されませんのでご注意ください。 以下画像の右側にある [Publish]を押下し、警告が表示された後、さらに[Publish] を押して有効化する必要があります。   画像のように 「User Interaction Policy Enabled」にチェック が入っていれば、正常に有効化が完了しています。     可視化したプロンプトの確認方法 可視化したプロンプトの確認は、 [AI Security]タブ – [Session Explore]メニュー で行います。 Session Exploreメニューでは、現状以下のように、 User Inte raction Policy で 可視化・ブロックを設定 したAIツールについて、以下のようなことが一目で確認できるダッシュボードを提供しています。 ・ どのAIツールが一番使われているか ・ どんなジャンルの会話がよく実施されているか ・ ポリシーによるプロンプト可視化・ブロック履歴（各ユーザー・セッションごと）   履歴をクリックしその後の画面で、 [Reveal Session] を選択するとその履歴について、 実行されたプロンプト及びAIからのレスポンス を確認できます。   注意点 として、プロンプト履歴の確認を行うためには、プロンプトを確認したい 管理ユーザーに [AI Security for Users]の[Read Sensitive Content]権限 が必要となります。                     上記権限について、既定のEditorロールでは現状（2026/4時点）付与されておりません ので、必要に応じて、ご自身で新規ロール作成の上、必要なユーザーへのアタッチをお願いします。   また、本項の検証については、プロンプトの可視化という比較的わかりやすい機能であり、かつAIインタラクションDLPの検証でもプロンプトの可視化を実施するため、省略させていただきます。   ③ AIインタラクションDLP（Data Loss Prevention） 最後に AIインタラクションDLP の機能について、設定・確認方法の連携と検証を実施していきます。 といっても、エンジンプロファイルを設定し、アクションに 「Block」や「Annoymize」 を設定する以外は、設定・確認方法ともにほぼ 可視化の際と同一 です。 設定・確認方法 設定方法 設定①　エンジンプロファイルの作成 設定にはまず 「エンジンプロファイル」 と呼ばれる、 検知ルールやデータ識別方法の設定をまとめたプロファイルを作成する必要があります。 [AIセキュリティ]タブ – [Engine Profiles]メニューより、エンジンプロファイル の設定画面を開き、 [New] ボタンを押して新規エンジンプロファイルを作成します。 エンジンプロファイルは現在（2026/4)、 カスタムプロファイル もしくは 3つの定義済みプロファイル から 設定可能です。 （定義済みプロファイルについては、随時アップデートも入る予定の模様） No. 設定 説明 検知・制御可能な内容例 1 Create a Custom Profile 事前に用意されているDetector(検知ルール）や正規表現 を用いて、独自プロファイルを作成する （＝カスタムプロファイル） 以下2つを選択可能 ・事前に用意されているDetector の 範囲で自由 に組み合わせる ・自身でCustom Detectorを作成し、正規表現 で実現できる範囲で、 自由に設定 2 Sensitive Identifiers PIIやPCIを含む機密情報 を検知し、コンプライアンスの確保とデータ漏えいの防止 住所・電話番号・Emailアドレス・クレジットカード番号・口座番号・患者番号・パスポート番号等 3 EU AI Act Support AIに関連するリスク要因や規制対象データを検知し、 EU AI Act へのコンプライアンス対応 を実施 採用や従業員評価 4 Secrets & Passwords 認証情報や機密アクセス・トークンなどの 機密技術データの検知 パスワード、APIキー、秘密鍵、アクセストークンなど、ユーザーやシステムの認証に使用される秘密情報   用途に応じて設定出来たら、 [Save] で保存します。 なお、一度設定したプロファイル設定は、削除しない限り 再設定は不要です。 （プロファイル設定はポリシーごとに使いまわす）   設定② User Interaction Policyの設定 プロファイルが設定出来たら、「 ②プロンプト＆アクションの可視化」 で設定した 「User Interaction Policy」 を設定していきます。 設定項目はほぼ同じ ですので割愛しますが、 エンジンプロファイル として設定したいプロファイルを選択したうえで、 適切なアクション（ブロック・難読化） を設定してください。   設定③ ポリシー設定の有効化 こちらも ②プロンプト＆アクションの可視化 で実施したように Publishを押下 して、ポリシー設定を有効化しましょう。 これで、設定については完了です。   ブロック・難読化したプロンプトの確認方法 ブロック・難読化したプロンプトの確認方法は、可視化の際と同じ手順で [AI Security]タブ – [Session Explore]メニュー で行います。 ブロック・難読化が適用された場合は、各セッション履歴項目うち [Viloations]の項目に設定したポリシーが表示 されますので、そこでご判断ください。 なお、ブロック・難読化された会話内容については、画像のように 適用されたポリシールールとそれに紐づくエンジンプロファイル名 が表示されます。   検証～個人情報・パスワードの入力ブロック～ では検証として、実際にAIに ダミーの個人情報やアクセスキー などを入力し、 検知・難読化及びブロック してくれるかを見ていきたいと思います。 エンジンプロファイル・ポリシーの準備 まず、 エンジンプロファイル・ポリシー の設定をしていきます。 エンジンプロファイルは定義済みの以下2つを利用しました。 ・ Sensitive Identifiers ：個人情報関連のプロファイル設定 ・ Secrets & Passwords ：キーやパスワード等を検知してくれるプロファイル設定   その後、それぞれの プロファイルごとに以下の名前でポリシー を用意しました。 （現状 1ポリシーにつき1プロファイルのみ紐づける ことが可能です） ・ test-Sensitive-Identifiers-Policy ・ test-Secrets-Passwords-Policy なお、それぞれの アクションの挙動 の違いを見るためにも、 test-Sensitive-Identifiers-Policyでは「Block」設定、 test-Secrets-Passwords-Policyでは「Annoymize＆Block」（難読化＆ブロック）設定としています。 その他の設定としては、 適用ユーザーはAny 、適用AIは Copilot、ChatGPT としています。 これで、エンジンプロファイル・ポリシー側の設定は完了です。 AIにてプロンプト入力・送信 次に実際に生 成AIのチャット画面からプロンプトを入力 し、AIの利用ユーザー側からの見え方を確認します。 今回はCopilotを利用しました。 まずは、設定したポリシー（個人情報、パスワード関連）以外のプロンプトを入力していきます。 以下と入力してみました。 「これはテストです。こんにちはと返答してください」 画像の通り返答がありました。 ポリシーに引っかからない内容 であれば、特に問題なく会話できそうですね。   次に、 test-Sensitive-Identifiers-Policyに引っかかるように、ダミーの個人情報を入力します。 メールアドレス:test@email.com 結果、画像の通りポリシーに合致して、プロンプトが ブロック された旨の表示がされました。 （This message was blocked～の文言です） Detectionには 検知したポリシー名 が記載されています。 AI側にはメールアドレスではなく、 ブロック後に表示された文章が到達したようで 、 それに関する返答が実施されていますね。   このように、 ブロック設定を適用したプロンプトについては、Cato側でブロックし 自動で出力を変換してAIに送信 してくれるようです。 次に、ダミーのキーとパスワードを入力して、 難読化とブロック が実施されるかを見ていきたいと思います。 以下のような AWSのアクセスキーを模したコード をプロンプトとして、実行します。 client = boto3.client( ‘s3’, aws_access_key_id=’IABFAAOSFODNN7EXAMPLE’, aws_secret_access_key=’JaXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY’ ) 上記プロンプトで実行したところ、 アクセスキーIDとアクセスキー の部分が、 [SECRET_1]、[SECRET_2] のように 難読化して送信 されたのが確認できました。 難読化の場合は、プロンプト自体を全てメッセージ変換するのではなく、該当箇所のみを難読化する仕様のようです。   実行結果のCato管理コンソールからの確認 次に、 Catoの管理コンソール から、実行されたプロンプトの履歴を確認します。 [AI Security]タブ – [Session Explore]メニュー に進むと以下のように、 プロンプトをブロックした履歴が表示されていますね。   それぞれの履歴をクリックして、ユーザーとAIとの会話履歴を確認していきます。 まずは メールアドレスをブロックしたセッション から見ていきます。 画像のように、 適用されたポリシー及びエンジンプロファイル名と、 ブロックされた具体的な箇所・及び実際にユーザーが送信しようとしたプロンプト が確認できました。 （test-Sensitive-identifiers-Policy以外でも検知されていますが、こちらは以前の検証にて利用していた ポリシーですので気にしないでください） 次に、 アクセスキーを難読化したセッションの履歴 を確認します。 画像のように、 適用されたポリシー・エンジンプロファイル名と、 ブロックされた具体的な箇所、及び対象箇所を「難読化」したうえで、ユーザーが送信したプロンプト が 表示されました。 難読化した場合は、C ato上でのプロンプト確認時も難読化された状態で表示される仕様 のようです。 以上で検証は終了となります。 まとめ 生成AIは今後ますます業務で利用されていき、私たちの生産性向上に寄与してくれるでしょう。しかし、その一方で利用には常にセキュリティリスクが伴います。 そのため、 AIの利用を完全に禁止 するのではなく、 安全に利用できる環境を整える ことが重要です。 Catoのユーザー向けAIセキュリティの各種機能 は、 企業の情報システム部様・管理者様側 から見た以下ニーズに対応しており、そういった環境の実現に非常に役立つと感じました。 対応可能なニーズ例 １． 社内で許可していないAI（シャドーAI）を利用しているユーザーの把握 ２．従業員が実際に入力しているプロンプト・応答を、各AI・ユーザーごとに可視化・一元管理 ３．個人情報やパスワード等の機密情報を含んだプロンプトの難読化・ブロック ４．独自ルールを設定し、特定の文言がプロンプトに含まれた際の難読化・ブロック　等   また別記事で、独自構築したAIアプリへのセキュリティ機能についても詳細解説させていただく予定です。 最後までご覧いただき、ありがとうございました。

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 所属： エンジニアリング革新本部エンジニアリング革新推進部 氏名：安彦 洋樹   【自己紹介】 「2024 Japan AWS Top Engineers (Analytics)」 に続き、今年度は「2025 Japan AWS Top Engineers (AI/ML Data Engineer)」に選出して頂きました。 今現在はAI/データ活用ビジネスを牽引する部署のラインマネージャとして、主にAWSのData Analytics系のサービスを使ってデータ活用ビジネスの拡大に努めています。   本編 AWSエンジニアになった背景を教えてください。 SCSKに入社以来、アプリケーション開発する部署と基盤を 構築する 部署を渡り歩き、主にデータベーススペシャリストとして様々な大規模プロジェクトを経験してきました。 その中でデータエンジニアとしてオンプレ環境でDWHシステムを構築するプロジェクトも何度か経験しており、その経験を活かして、 2018年に Amazon Redshiftを中心とした顧客情報基盤構築プロジェクトでデータエンジニア兼ITアーキテクトを担当 しました。 そこで AWSのData Analytics系のサービス(Amazon Redshift、Amazon QuickSight、AWS Glue等)の魅力に気づいてそれ以降、本格的にAWSのデータ活用系システム構築のプロジェクトに注力 することになりました。 2023年にはプロジェクトで培ったノウハウを汎化して、 AWSベースの 「クラウドデータ活用サービス」 をローンチ し、サービスの販促活動の一環としてAWS様主催のセミナーに登壇させて頂いたり、データ活用ビジネス拡大に向けて様々な活動をしております。 エンジニアとして大切にしている価値観や信条はありますか？ まずこれだけは 誰にも負けないという領域を持つことが大切 だと思っています。 私自身はデータベーススペシャリストとして常にトップクラスのエンジニアであり続けることを意識 しています。 それとエンジニアとしてはやはり座学で得た知識だけでなく、それを 常に実践的な技術まで昇華させておく必要がある と思っており、それがプロとしても仕事に繋がるものと考えています。 この度は受賞おめでとうございます！ 受賞に至るまで特に重点を置いて取り組んできたこと・乗り越えたチャレンジを教えてください。 今回は AIサービスを使った名寄せや、データマネージメントの実現等、これまでできてなかった新しい要素を提案 してプロジェクトの中で実現したこと、それをセミナー登壇などで社内外に広く発信して、 A WS Data Analyticsってこんなことができるんだってことを一人でも多くの方に知って頂くをことを意識 しました。 受賞がご自身のキャリアやチームに与えた影響はありますか？ Data Analyticsの領域においてAWSに公的に活躍を認めて頂いたということが純粋にうれしかったですし、すごい自信になりました。 このプレゼンスを活かして データ活用プロジェクトの提案書の要員紹介のスライドに「Top Engineer」の肩書を入れて受注確度を上げたりすることができました。 今では チーム全員をTopEngineerにして、最強のData Analytics集団を作り上げてやろうという野望を持って、実現に向けて日々ラインマネージメントしています。 今後、個人として、挑戦してみたい新しい技術・分野や、目指している目標について教えてください。 これまでの データ活用基盤に「モダンデータスタック」と呼ばれる新しい要素を取り入れた新しいサービスの開発や案件適用を実現 していきたいと思っています。 更にそれを 「AI-Ready」な基盤にすることでAIによるデータ活用価値の最大化を図ること を目指します。 前回のリレーインタビューでの畑 健治さんから 福地さんへのご質問です。ご回答をお願いいたします 安彦さんはプレイングマネージャーとして技術の最前線に立ちながら、メンバーを育てていくことにも力を注がれていると思います！ 日頃メンバーと接するうえで工夫されていることや、大事にしていること があればぜひお聞かせください！ 日頃から次世代のトップエンジニア候補を育成することを考えていて、その中で大事にしていることは、 机上の知識だけではなく実際にプロジェクトやサービス開発を通して得られた知識や経験を実践的な話として伝えてあげること なのかなと思っています。 次のインタビューは AWS Ambassador の「広野 祐司」さんです！安彦さんにお聞きしたいことはありますか？ 広野さんはAmbassadorとして、これまで主にクラウドネイティブ、DevOps、モダンWebアプリケーション開発等の第一人者として技術者育成に尽力されてきたかと思います。しかし近年AIの台頭により本領域についても変革期を迎えていると感じているのですが、広野さんはこの状況に対し、 今後はどのような取り組みを構想されていますでしょうか。 安彦 洋樹さん、ありがとうございました！   最後に、読者の方へメッセージをお願いいたします！ AI時代と呼ばれる現代において、AIだけではなくそれを有効に活用するための「データ」の質についても注目されるようになってきますので、これまで以上にデータエンジニアリングに注力し 「データ＆AI」でお客様のデータドリブン経営を強力に支援していければ と思っています。     次回インタビューは、2025 Japan AWS Ambassadors を受賞された 広野 祐司（ひろの ゆうじ） さんです。 次回の記事もお楽しみにお待ちください！

本記事は 春のスキルアップ応援フェア2026 4/21付の記事です 。 こんにちは。SCSK渡辺(大)です。 「動くけどAWS Well-Architected じゃない」環境をAIに作らせ、直すことでベストプラクティスを学んでみました。 個人的には非常に勉強になりました。 AWS Well-Architected とは、AWSが公開しているクラウド設計・運用のベストプラクティス集です。 次の6つの柱で構成されています。 運用上の優秀性 — 運用の自動化、監視、改善 セキュリティ — データ保護、アクセス管理、検出 信頼性 — 障害復旧、バックアップ、冗長化 パフォーマンス効率 — リソースの適切な選択と最適化 コスト最適化 — 無駄なコストの排除、適正サイズ 持続可能性 — 環境負荷の最小化   全体の流れ デプロイ : アンチパターン入りCFNテンプレートを特定のリージョンでデプロイ 修正 : AWSマネジメントコンソールでアンチパターンを見つけて修正 クリーンアップ : スタック削除（必要に応じてスタック外リソース削除）   問題用に作るもの YAMLのテンプレート1つで（AWS CloudFormationスタック1つで）以下のリソースを作ります。 これらにAWS Well-Architectedのベストプラクティスに反するアンチパターンが仕込まれています。 論理ID リソース種類 関連する問題 ChallengeVPC VPC A1, B2 PrivateSubnetA / B サブネット × 2 B2 PrivateRouteTable ルートテーブル B2 EC2SecurityGroup セキュリティグループ B2 RDSSecurityGroup セキュリティグループ B2 ChallengeBucket S3バケット B1, M3, B2 AccessLogBucket S3バケット B1, B2 EC2Role IAMロール M1, B2 EC2InstanceProfile インスタンスプロファイル — ChallengeInstance EC2インスタンス A2, B2 RDSSubnetGroup DBサブネットグループ B2 ChallengeDB RDSインスタンス B3, M2, B2 ChallengeTable DynamoDBテーブル A3, B2 ChallengeLogGroup CloudWatch Logsロググループ B2 FlowLogsLogGroup CloudWatch Logsロググループ A1, B2   ⚠ 各リソースの備考を見る（ネタバレ注意） 論理ID 備考 ChallengeVPC フローログ無効 PrivateSubnetA / B Multi-AZ用プライベートサブネット PrivateRouteTable — EC2SecurityGroup EC2用、インバウンドなし RDSSecurityGroup RDS用、VPC内部のみ ChallengeBucket アクセスログ無効、バージョニング無効 AccessLogBucket アクセスログの保管先として使用 EC2Role Action/Resource全開 EC2InstanceProfile EC2Roleに紐づく（タグ非対応） ChallengeInstance EBS gp2、暗号化なし RDSSubnetGroup タグエディタからは見つけにくい ChallengeDB Single-AZ、バックアップ無効 ChallengeTable 過剰キャパシティ、Auto Scalingなし ChallengeLogGroup 保持期間未設定（無期限） FlowLogsLogGroup VPCフローログの送信先として使用   セキュリティリスクが実際に発生するような構成（ポート全開放など）は含めていません。 EC2・RDSはプライベートサブネット配置、S3はパブリックアクセス完全ブロック、セキュリティグループはインバウンドなしです。 コストは東京リージョンで24時間以内に削除した場合、約200〜300円です。終わったら必ずスタック削除してください。   問題構成 9問構成（初級3問・中級3問・上級3問）です。 ヒントは3段階で用意しています。 難易度 問題の頭文字 主な柱 初級 B (Beginner) セキュリティ、運用上の優秀性、信頼性 中級 M (Middle) セキュリティ、信頼性 上級 A (Advanced) セキュリティ、コスト最適化、パフォーマンス効率、運用上の優秀性   デプロイ 以下のテンプレートをAWS CloudFormationで特定のリージョンにデプロイしてください。 デプロイは10分以内で完了します（RDSの作成に時間がかかります）。 スタック作成の最後のステップで「AWS CloudFormation によって IAM リソースが作成される場合があることを承認します。」のチェックボックスにチェックを入れてください。 テンプレートにIAMロールが含まれているため必要です。 ▶ wa-challenge.yaml（クリックで展開） AWSTemplateFormatVersion: '2010-09-09' Description: > Well-Architected Anti-Pattern Challenge. This template contains anti-patterns that violate Well-Architected best practices. Find and fix them using the AWS Management Console. Parameters: LatestAmiId: Type: AWS::SSM::Parameter::Value<AWS::EC2::Image::Id> Default: /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64 Resources: ChallengeVPC: Type: AWS::EC2::VPC Properties: CidrBlock: 10.0.0.0/16 EnableDnsSupport: true EnableDnsHostnames: true PrivateSubnetA: Type: AWS::EC2::Subnet Properties: VpcId: !Ref ChallengeVPC CidrBlock: 10.0.1.0/24 AvailabilityZone: !Select [0, !GetAZs ''] PrivateSubnetB: Type: AWS::EC2::Subnet Properties: VpcId: !Ref ChallengeVPC CidrBlock: 10.0.2.0/24 AvailabilityZone: !Select [1, !GetAZs ''] PrivateRouteTable: Type: AWS::EC2::RouteTable Properties: VpcId: !Ref ChallengeVPC PrivateSubnetARouteTableAssociation: Type: AWS::EC2::SubnetRouteTableAssociation Properties: SubnetId: !Ref PrivateSubnetA RouteTableId: !Ref PrivateRouteTable PrivateSubnetBRouteTableAssociation: Type: AWS::EC2::SubnetRouteTableAssociation Properties: SubnetId: !Ref PrivateSubnetB RouteTableId: !Ref PrivateRouteTable EC2SecurityGroup: Type: AWS::EC2::SecurityGroup Properties: GroupDescription: EC2 Security Group - No inbound access VpcId: !Ref ChallengeVPC SecurityGroupIngress: [] SecurityGroupEgress: - IpProtocol: '-1' CidrIp: 10.0.0.0/16 RDSSecurityGroup: Type: AWS::EC2::SecurityGroup Properties: GroupDescription: RDS Security Group - VPC internal only VpcId: !Ref ChallengeVPC SecurityGroupIngress: - IpProtocol: tcp FromPort: 3306 ToPort: 3306 SourceSecurityGroupId: !Ref EC2SecurityGroup SecurityGroupEgress: - IpProtocol: '-1' CidrIp: 10.0.0.0/16 ChallengeBucket: Type: AWS::S3::Bucket DeletionPolicy: Delete Properties: PublicAccessBlockConfiguration: BlockPublicAcls: true BlockPublicPolicy: true IgnorePublicAcls: true RestrictPublicBuckets: true AccessLogBucket: Type: AWS::S3::Bucket DeletionPolicy: Delete Properties: PublicAccessBlockConfiguration: BlockPublicAcls: true BlockPublicPolicy: true IgnorePublicAcls: true RestrictPublicBuckets: true EC2Role: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Principal: Service: ec2.amazonaws.com Action: sts:AssumeRole Policies: - PolicyName: OverlyPermissivePolicy PolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Action: '*' Resource: '*' EC2InstanceProfile: Type: AWS::IAM::InstanceProfile Properties: Roles: - !Ref EC2Role ChallengeInstance: Type: AWS::EC2::Instance Properties: InstanceType: t3.micro ImageId: !Ref LatestAmiId SubnetId: !Ref PrivateSubnetA SecurityGroupIds: - !Ref EC2SecurityGroup IamInstanceProfile: !Ref EC2InstanceProfile PropagateTagsToVolumeOnCreation: true BlockDeviceMappings: - DeviceName: /dev/xvda Ebs: VolumeSize: 20 VolumeType: gp2 Encrypted: false DeleteOnTermination: true RDSSubnetGroup: Type: AWS::RDS::DBSubnetGroup Properties: DBSubnetGroupDescription: Challenge RDS Subnet Group SubnetIds: - !Ref PrivateSubnetA - !Ref PrivateSubnetB ChallengeDB: Type: AWS::RDS::DBInstance DeletionPolicy: Delete Properties: DBInstanceClass: db.t3.micro Engine: mysql EngineVersion: '8.0' MasterUsername: admin MasterUserPassword: ChallengePw123! AllocatedStorage: '20' DBSubnetGroupName: !Ref RDSSubnetGroup VPCSecurityGroups: - !Ref RDSSecurityGroup PubliclyAccessible: false MultiAZ: false BackupRetentionPeriod: 0 StorageEncrypted: false ChallengeTable: Type: AWS::DynamoDB::Table DeletionPolicy: Delete Properties: TableName: ChallengeTable AttributeDefinitions: - AttributeName: PK AttributeType: S KeySchema: - AttributeName: PK KeyType: HASH BillingMode: PROVISIONED ProvisionedThroughput: ReadCapacityUnits: 100 WriteCapacityUnits: 100 ChallengeLogGroup: Type: AWS::Logs::LogGroup DeletionPolicy: Delete Properties: LogGroupName: /challenge/application FlowLogsLogGroup: Type: AWS::Logs::LogGroup DeletionPolicy: Delete Properties: LogGroupName: /vpc/flow-logs Outputs: VPCId: Value: !Ref ChallengeVPC FlowLogsLogGroupName: Value: !Ref FlowLogsLogGroup S3BucketName: Value: !Ref ChallengeBucket AccessLogBucketName: Value: !Ref AccessLogBucket EC2InstanceId: Value: !Ref ChallengeInstance RDSEndpoint: Value: !GetAtt ChallengeDB.Endpoint.Address DynamoDBTableName: Value: !Ref ChallengeTable   問題に取り組む デプロイが完了したら、AWSマネジメントコンソールで東京リージョンを選択し、以下の問題を見ながらアンチパターンを見つけて修正してください。 スタックの「リソース」タブから各種リソースを参照しにいくとスムーズに進められます。 各問題に取り組む前に、必ず上記の「問題用に作るもの」セクションでデプロイされるリソースの一覧を確認してください。どのサービスのどのリソースが作られているかを把握しておくことで、問題の対象を特定しやすくなります。   初級問題 B1: S3バケットのアクセスログ 柱 : セキュリティ 問題 : デプロイされたS3バケットにはWell-Architectedセキュリティ柱の検出に関するベストプラクティスに反する設定があります。見つけて修正してください。 関連するWell-Architectedガイド : SEC04-BP02 Capture logs, findings, and metrics in standardized locations 💡 ヒント1（方向性） 誰がいつバケットにアクセスしたかを追跡するための設定を確認してください。S3バケットのプロパティを見てみましょう。 💡 ヒント2（具体的なガイドリンク） S3のサーバーアクセスログが無効になっています。バケットへのアクセスを監査できません。 Amazon S3 サーバーアクセスログ 💡 ヒント3（ほぼ答え） S3コンソール → バケットを選択 → 「プロパティ」→ 「サーバーアクセスのログ記録」を編集 →  「有効にする」を選択し、ログの送信先にスタックで作成済みのアクセスログ用バケット（ AccessLogBucket ）を指定してください。 サーバーアクセスログの有効化 B2: リソースのタグ付け 柱 : 運用上の優秀性 + コスト最適化 問題 : デプロイされたリソース群にはWell-Architected運用上の優秀性の柱に反する共通の問題があります。見つけて修正してください。 注意 : APIレート制限にご注意ください。 関連するWell-Architectedガイド : COST04-BP01 Track resources over their lifetime 💡 ヒント1（方向性） リソースの管理・追跡・コスト配分に必要な基本的な設定が欠けています。複数のリソースに共通する問題です。 💡 ヒント2（具体的なガイドリンク） すべてのリソースにタグが一切付いていません。 AWS リソースのタグ付けのベストプラクティス 💡 ヒント3（ほぼ答え） 全リソースに Environment , Project , Owner 等のタグを追加してください。各リソースのコンソール画面 → 「タグ」タブから追加できます。 注意 :タグエディタで一括タグ付けする場合、リソースタイプでフィルタしてチャレンジのリソースだけを選択してください。アカウント内の全リソースを対象にするとAPIレート制限に抵触したり、マネージドルールなどタグ変更が禁止されているリソースでエラーになります。 タグエディタを使用したタグの管理 B3: RDSの自動バックアップ 柱 : 信頼性 問題 : デプロイされたRDSインスタンスにはWell-Architected信頼性の柱のバックアップベストプラクティスに反する設定があります。見つけて修正してください。 関連するWell-Architectedガイド : REL09-BP03 Perform data backup automatically 💡 ヒント1（方向性） 障害時のデータ復旧に関するベストプラクティスを確認してください。RDSの設定を見てみましょう。 💡 ヒント2（具体的なガイドリンク） RDSの自動バックアップが無効になっています（バックアップ保持期間が0日）。 Amazon RDS バックアップの操作 💡 ヒント3（ほぼ答え） RDSコンソール → インスタンスを選択 → 「変更」→ 「バックアップ保持期間」を1日以上（推奨: 7日）に設定してください。 自動バックアップの有効化   中級問題 M1: IAMの最小権限 柱 : セキュリティ 問題 : デプロイされたIAMロールにはWell-Architectedセキュリティ柱のアクセス管理ベストプラクティスに反する設定があります。見つけて修正してください。 関連するWell-Architectedガイド : SEC03-BP02 Grant least privilege access 💡 ヒント1（方向性） IAMのアクセス権限に関するベストプラクティスを確認してください。EC2に割り当てられたロールのポリシーを見てみましょう。 💡 ヒント2（具体的なガイドリンク） EC2ロールのポリシーが Action: "*" , Resource: "*" で全権限を許可しています。 IAM でのセキュリティのベストプラクティス 💡 ヒント3（ほぼ答え） IAMコンソール → ロール → EC2ロールを選択 → OverlyPermissivePolicy  を編集し、必要なアクション/リソースのみに絞ってください。当チャレンジではEC2に特定の用途がないため、インラインポリシー OverlyPermissivePolicy を削除するか、AWS管理ポリシー AWSDenyAll をアタッチして全アクションを拒否する方法でも正解です。 IAM ポリシーの作成 M2: RDSの可用性 柱 : 信頼性 問題 : デプロイされたRDSインスタンスにはWell-Architected信頼性の柱の障害管理ベストプラクティスに反する設定があります。見つけて修正してください。（B3とは別の問題です） 関連するWell-Architectedガイド : Failure management – Reliability Pillar 💡 ヒント1（方向性） 単一障害点の排除に関するベストプラクティスを確認してください。 💡 ヒント2（具体的なガイドリンク） RDSがSingle-AZ構成で、AZ障害時にフェイルオーバーできません。 Amazon RDS の高可用性 (マルチ AZ) 💡 ヒント3（ほぼ答え） RDSコンソール → インスタンスを選択 → 「変更」→ 「可用性と耐久性」セクションで「マルチAZデプロイメント」を「スタンバイインスタンスを作成する」に変更してください。 マルチ AZ DB インスタンスのデプロイの変更 M3: S3のデータ保護 柱 : 信頼性 + セキュリティ 問題 : デプロイされたS3バケットにはWell-Architectedのデータ保護ベストプラクティスに反する設定があります。見つけて修正してください。（B1とは別の問題です） 関連するWell-Architectedガイド : REL09-BP02 Secure and encrypt backups 💡 ヒント1（方向性） データの誤削除からの保護に関するベストプラクティスを確認してください。 💡 ヒント2（具体的なガイドリンク） S3バケットのバージョニングが無効で、オブジェクトの誤削除から復旧できません。 S3 バージョニングの使用 💡 ヒント3（ほぼ答え） S3コンソール → バケットを選択 → 「プロパティ」→ 「バージョニング」を「有効」に変更してください。 バケットでのバージョニングの有効化   上級問題 A1: ネットワーク監査ログ 柱 : セキュリティ + 運用上の優秀性 問題 : デプロイされたVPCにはWell-Architectedセキュリティ柱の検出に関するベストプラクティスに反する設定があります。見つけて修正してください。 関連するWell-Architectedガイド : Security Pillar – Detection 💡 ヒント1（方向性） ネットワークトラフィックの監査・可視化に関するベストプラクティスを確認してください。 💡 ヒント2（具体的なガイドリンク） VPCフローログが無効で、ネットワークトラフィックの監査ができません。 VPC フローログ SEC04-BP01 Configure service and application logging 💡 ヒント3（ほぼ答え） VPCコンソール → VPCを選択 → 「フローログ」タブ → 「フローログを作成」で以下を設定してください: 名前 – オプション : 任意（空欄でもOK） フィルタ : すべて 最大集約間隔 : 10分（デフォルトのまま） 送信先 : CloudWatch Logsに送信 送信先ロググループ : スタックで作成済みの /vpc/flow-logs を選択 IAMロール : 「Set Up Permissions」から新規作成、または既存のフローログ用ロールを選択 ログレコードの形式 : AWSのデフォルト形式（デフォルトのまま） 追加のメタデータ : なし（デフォルトのまま） フローログの作成 A2: EBSストレージの最適化 柱 : コスト最適化 + セキュリティ 問題 : デプロイされたEC2インスタンスのEBSボリュームにはWell-Architectedのコスト最適化とセキュリティのベストプラクティスに反する設定があります。見つけて修正してください。 関連するWell-Architectedガイド : Cost Optimization Pillar SEC08-BP02 Enforce encryption at rest 💡 ヒント1（方向性） ストレージの世代選択とデータ保護の2つの観点で確認してください。 💡 ヒント2（具体的なガイドリンク） 2つの問題があります: EBSがgp2（旧世代）で、gp3の方がコスト効率が良い EBSの暗号化が無効 gp2 から gp3 への移行 💡 ヒント3（ほぼ答え） gp2→gp3の変更: EC2コンソール → ボリューム → ボリュームを選択 → 「変更」→ タイプを gp3 に変更 → 「変更」をクリック。 暗号化の対応: 既存ボリュームでは暗号化を直接有効にできないため、以下の手順が必要です: EC2コンソール → インスタンス → 対象インスタンスを 「停止」 する ボリューム → 対象ボリュームを選択 → 「スナップショットを作成」 スナップショット → 作成したスナップショットを選択 → 「スナップショットをコピー」→ 「暗号化」にチェック → コピー 暗号化済みスナップショットを選択 → 「スナップショットからボリュームを作成」→ AZを元のボリュームと同じにする 元のボリュームをインスタンスからデタッチ 暗号化済みボリュームをインスタンスにアタッチ（デバイス名: /dev/xvda ） インスタンスを起動 「停止」と「終了」を間違えないでください。「終了」（Terminate）するとインスタンスが削除されてしまい、ボリュームのアタッチ先がなくなります。必ず「停止」（Stop）を選んでください。 暗号化の手順は複雑なため、gp2→gp3の変更だけでも正解とします。 EBS ボリュームの変更 A3: DynamoDBのキャパシティ管理 柱 : コスト最適化 + パフォーマンス効率 問題 : デプロイされたDynamoDBテーブルにはWell-Architectedのコスト最適化とパフォーマンス効率のベストプラクティスに反する設定があります。見つけて修正してください。 関連するWell-Architectedガイド : Performance Efficiency Cost Optimization Pillar 💡 ヒント1（方向性） データベースのキャパシティ管理とコスト効率に関するベストプラクティスを確認してください。 💡 ヒント2（具体的なガイドリンク） DynamoDBがプロビジョンドモードで過剰なRCU/WCU（各100）が設定されており、Auto Scalingも無効です。 DynamoDB on-demand capacity mode DynamoDB Well-Architected Lens 💡 ヒント3（ほぼ答え） DynamoDBコンソール → テーブルを選択 → 「追加の設定」→ 「読み込み/書き込みキャパシティ」セクションの「編集」をクリック。 以下のいずれかを実施してください: 方法1: オンデマンドモードに変更（推奨） キャパシティモードを「オンデマンド」に変更 「変更を保存」をクリック 方法2: Auto Scalingを有効化 キャパシティモードは「プロビジョンド」のまま 読み込みキャパシティ: 「Auto Scaling」をオン → 最小キャパシティを1〜5程度に設定 書き込みキャパシティ: 同様に「Auto Scaling」をオン → 最小キャパシティを1〜5程度に設定 「変更を保存」をクリック DynamoDB Auto Scaling   クリーンアップ CloudFormationコンソールからスタックを削除してください。 S3バケットにオブジェクトが残っているとスタック削除が失敗します。B1でアクセスログを有効にした場合、 AccessLogBucket と ChallengeBucket の中身を先に空にしてからスタックを削除してください。S3コンソール → バケットを選択 → 「空にする」で削除できます。   スタック外リソースの手動削除 問題を解く過程で、スタック管理外のリソースが作成されている場合があります。これらはスタック削除では消えないため、手動で削除してください。 ⚠ スタック外リソースの一覧と削除手順（ネタバレ注意） 関連問題 リソース 削除手順 A1 VPCフローログ VPCコンソール → VPCを選択 → 「フローログ」タブ → フローログを選択 → 「アクション」→「フローログの削除」 A1 VPCフローログ用IAMロール IAMコンソール → ロール → VPCFlowLogs-Cloudwatch-* のようなロールを検索 → 削除 A2 EBSスナップショット（暗号化対応した場合） EC2コンソール → スナップショット → 作成したスナップショットを選択 → 「アクション」→「スナップショットの削除」 A2 デタッチ済みEBSボリューム（暗号化対応した場合） EC2コンソール → ボリューム → 状態が「available」のボリュームを選択 → 「アクション」→「ボリュームの削除」 A2のEBS暗号化対応（スナップショット→暗号化コピー→新ボリューム作成）を行わなかった場合、スナップショットとデタッチ済みボリュームの削除は不要です。   まとめ テンプレートや問題文はAIに作ってもらいましたが、実際に自分で修正を試してみると、S3のデフォルト暗号化が既に有効になっていて問題として成立しなかったり（この問題は削除してもらいました）、ヒントの手順が現在のコンソールUIと合っていなかったりと、そのままでは使えない箇所がいくつもありました。 AIが生成したものを鵜呑みにせず、自分で手を動かして検証することの大切さを改めて感じました。 Well-Architected Framework は読むだけでは実感が湧きにくいですが、「動くけどベストプラクティスじゃない環境」を自分の手で直すことで、各ベストプラクティスの意味が体感できました。 「M2: RDSの可用性」ではMulti-AZ化の過程で、定期メンテナンスウィンドウの設定や延期方法についても学ぶことができました。 また「B1: S3バケットのアクセスログ」では、ログの蓄積をきっかけにS3ライフサイクルポリシーやストレージクラス移行時の料金体系についても理解が深まりました。 このように、1つのアンチパターンを修正する過程で関連するベストプラクティスにも自然と触れることができ、Well-Architectedの学習が点ではなく面で広がっていく実感がありました。

Windows版Dropboxデスクトップアプリは、Windowsと適切に統合するため、従来の同期方式から「WindowsのクラウドファイルAPI」へ順次移行しています。 この移行は急を要するものではなく、レガシー同期方式のままでも突然利用できなくなる心配はありません。このままレガシー同期エンジンでもDropboxデスクトップアプリを利用できます。 ただし、アップデートを行わない場合、今後のOS機能改善や性能向上、セキュリティアップデートが適用されない可能性があるため、ご注意ください。 アップデートの適用状況を確認する まずは「アップデート対象か／アップデート済みか」を確認します。Dropboxデスクトップアプリを起動し、タスクバーのDropboxアイコンをクリックします。左下のアバターを選択し、表示されたメニューで［基本設定］ をクリックします。 ［基本設定］画面［同期］タブ を開いて、次の表示があるか確認します。 1） アップデート済みの場合 「Dropbox on Cloud Filesをご利用中です。」 と表示されていれば、すでにアップデートが完了しています。        2） アップデート対象の場合 「このアップデートにより、DropboxをWindowsで引き続きスムーズに実行できます。『今すぐ更新』」 と表示されていれば、アップデート対象です。        3）どちらも表示されない場合 どちらも表示されない場合は、現時点では 移行対象外 の可能性があります。 このあと紹介する「更新されない条件」を確認し、該当しない場合はサポートへのお問い合わせをおすすめします。 アップデート後の主な変更点 アップデート完了後には 以下の変化が見られます。 エクスプローラーに ［状態］列 が追加され、ファイル／フォルダの同期状態がアイコンで分かりやすくなります。 Dropboxの同期アイコンが、従来のオーバーレイ表示 から、Windows標準のクラウドファイル同期アイコンへ移行します。                              エクスプローラーの表示 アップデート手順 アップデート対象の場合、Dropboxからメッセージが表示されます。表示された画面で［今すぐ更新］、もしくは［基本設定］画面［同期］タブで［今すぐ更新］をクリックしてください。       「今すぐ更新」ボタンを クリックする と、下のダイアログが表示されます。「開始」ボタンをクリックするとアップデートが開始されます。                  アップデート中によくある質問・注意点 アップデート中、一時的にタスクバーのDropboxアイコンが消えることがありますが、しばらくすると再表示されます。 タスクバーのDropboxアイコンにカーソルを合わせると、 ファイルのインデックス作成状況 が 確認でき、クリックすると同期状態が表示されます。                                       アップデート中にDropboxデスクトップアプリの画面が表示されたら「次へ」で進み、最後は「完了」で閉じます。 Dropbox同期アイコンなど、Dropboxデスクトップアプリをより快適に利用するためのTipsを紹介する画面が表示されます。           実施タイミングに注意！ ファイルやフォルダの閲覧・編集は通常通り可能ですが、同期ファイルが多い場合はアップデートに数時間かかることもあります。その ため、帰宅前や終業間際の実施は避け、未完了の場合はPCを起動したまま終業する運用をご検討ください。 アップデートできない・案内が出ない場合の対応 アップデートは自動で順次進む仕様ですが、現時点では次の条件に当てはまる場合は自動アップデートは適用されません。 同期対象ファイル数が50万件以上 更新されていない レガシー版のDropbox Backup を実行しているアカウント 対処1：同期ファイル数を減らす（選択型同期） “同期対象ファイル数” は、「Dropboxデスクトップアプリで同期しているファイル数」です。 ［基本設定］画面   [同期] タブ の「 選択型同期 」で同期ファイル数の調整が可能です。同期するフォルダを絞ることで、同期するファイル数を減らすことができます。           対処2：Dropbox Backupの状態を確認 Dropboxデスクトップアプリ[基本設定]画面［バックアップ］タブの「バックアップを管理」をクリックします。表示されたDropbox Backup 画面で「無効」になっているか確認します。バックアップを有効にしていた場合は「無効」に変更します。                                    Dropbox Backupを有効にしていたPCでは、Dropbox Backupを無効に設定変更した後にPCを再起動（Dropboxデスクトップアプリを再起動）すると、アップデートを促すDropboxのメッセージが表示されるようになりました。 「WindowsのクラウドファイルAPI」方式への移行メリット 従来の同期アイコンは オーバーレイアイコン で表示されます。Windowsでは、エクスプローラーが読み込むことができるオーバーレイアイコンの数に上限があります。もし、Dropboxの他に複数のクラウドやファイル同期ソフト（OneDriveなど）を同時に利用している場合、上限の15件を超えて同期アイコンが表示されない制約がありました。 「WindowsのクラウドファイルAPI」に移行すると、Dropboxだけでなく、OneDriveなどのクラウドサービスを使っていても他サービスと共存でき、 エクスプローラー上で統一されたアイコン表示でクラウドファイルの状態が分かりやすくなります 。 まとめ Windows版Dropboxのアップデート案内が表示された際は、より安心・快適なDropbox利用のため、迅速なアップデート実施をご検討ください。 本投稿に関するお問い合わせ先     ：　 Dropbox-sales@scsk.jp SCSKのDropbox取り組み紹介      ：   https://www.scsk.jp/product/common/dropbox/index.html 参照情報 Windows 版 Dropbox アップデートの概要 – Dropbox ヘルプ https://help.dropbox.com/ja-jp/installs/dropbox-for-windows Windows 版 Dropbox の改訂版で予想される変更点 – Dropbox ヘルプ https://help.dropbox.com/ja-jp/installs/windows-support-for-expected-changes Dropbox Backup を削除する方法 – Dropbox ヘルプ https://help.dropbox.com/ja-jp/organize/delete-dropbox-backup Windows デスクトップ アプリの Dropbox 同期アイコン – Dropbox ヘルプ – Dropbox ヘルプ https://help.dropbox.com/ja-jp/sync/sync-icons-windows

はじめまして。SCSKのすぐろです。 プレビュー版として実装されていたAWS DevOps Agentが2026年3月にGA（一般提供）されましたね。 インシデント発生時に自動で原因調査を行ってくれるサービスですが、実際にどこまで調べてくれるのかが気になったので、Amazon EC2上のWebサーバーで障害を発生させ、DevOps Agentの調査精度と限界を検証してみました。 参照: AWS DevOps Agent is now generally available AWS DevOps Agentとは インシデント発生時に、複数のデータソースを横断的に分析し、根本原因の特定と緩和策の提案を自動で行うマネージドサービスです。AWSネイティブなCloudWatchメトリクス・CloudWatch Logs・CloudTrailに加え、Datadog、Dynatrace、New Relic、Splunk等のサードパーティ製監視ツールや、GitHub、GitLab等のCI/CDパイプライン、ServiceNow、PagerDuty等のチケットシステムとも連携できます。GA版ではAzureやGrafanaのサポートも追加されました。 参照: About AWS DevOps Agent 参照: AWS DevOps Agent GA発表ブログ 料金 従量課金制で、エージェントがタスクに費やした時間に対して秒単位で課金されます。アイドル状態や待機中は課金されません。 課金対象 単価 Investigations（インシデント対応） $0.0083 / agent-second Evaluations（インシデント予防） $0.0083 / agent-second On-demand SRE tasks（チャット） $0.0083 / agent-second 新規利用者には2ヶ月間の無料トライアルがあり、各月Investigation 20時間・Evaluation 15時間・チャット 20時間まで無料で利用できます。 参照: Pricing – AWS DevOps Agent 検証のきっかけ 本番稼働中のWebサーバー(EC2インスタンス)のインシデント調査に使用するにあたり、以下の4点がきになりました。 EC2インスタンスへの影響はあるか DevOps AgentのIAMマネージドポリシー（ AIDevOpsAgentAccessPolicy ）を確認すると、EC2に対しては ec2:Describe* 等の読み取り系APIのみが許可されています。セキュリティドキュメントにも「エージェントが利用可能なツールは、チケットやサポートケースのオープンを除き、リソースを変更することができない」と記載されています。つまり、DevOps Agentの導入・調査によってEC2インスタンスが変更・停止されることはありません。 参照: DevOps Agent IAM permissions 参照: AWS DevOps Agent Security サーバーの中まで見に行ってくれるのか DevOps AgentはAWSのAPIを通じて情報を収集します。OS内部に直接アクセスする機能はドキュメントに記載されていません。OS内部の情報を調査対象にするには、CloudWatch Agent等でCloudWatch Logsやカスタムメトリクスとして事前に送信しておく必要があります。 参照: About AWS DevOps Agent 参照: What is a DevOps Agent Topology? どうやって調査しているのか IAMポリシーにはSSMでコマンドを実行する ssm:SendCommand やSSH接続用の ec2-instance-connect:* は含まれていません。SSHやSSMでEC2に接続するのではなく、AWSのAPIを通じた読み取り専用アクセスのみで調査を行います。 参照: DevOps Agent IAM permissions サーバー内に何かインストールされるのか EC2インスタンス内部にエージェントソフトウェアがインストールされることはありません。導入時に作成されるのはAgent Space（論理コンテナ）やサービスリンクロール等、AWSコントロールプレーン側のリソースのみです。 参照: DevOps Agent IAM permissions 検証 検証環境 EC2: t3.micro（Amazon Linux 2023）、httpd（Apache）をUserDataで起動 CloudWatch Agent: 以下の設定でログ・メトリクスを送信 CloudWatch Agentの設定ファイル（ /opt/aws/amazon-cloudwatch-agent/etc/config.json ）: { "metrics": { "namespace": "DevOpsAgentTest", "metrics_collected": { "mem": { "measurement": ["mem_used_percent"], "metrics_collection_interval": 60 }, "disk": { "measurement": ["used_percent"], "metrics_collection_interval": 60, "resources": ["*"] } } }, "logs": { "logs_collected": { "files": { "collect_list": [ { "file_path": "/var/log/messages", "log_group_name": "/devops-agent-test/messages" }, { "file_path": "/var/log/httpd/error_log", "log_group_name": "/devops-agent-test/httpd-error" }, { "file_path": "/var/log/httpd/access_log", "log_group_name": "/devops-agent-test/httpd-access" } ] } } } } /var/log/messages をCloudWatch Logsに送信することで、OOM KillerなどカーネルレベルのイベントがDevOps Agentの調査対象になります。メモリ・ディスク使用率のカスタムメトリクスも送信し、標準メトリクス（CPU、ネットワーク等）と合わせてDevOps Agentが参照できるようにしています。 検証1: CPU高負荷 SSMで接続し、 yes > /dev/null コマンドでCPUを100%に張り付かせた状態でDevOps Agentに調査を依頼しました。 調査依頼プロンプト: EC2インスタンス(i-xxxxx )のCPU使用率が急上昇しました。原因を調査してください。 結果: CPU使用率が100%に達していることを正しく検知 CloudTrailからタイムラインを構築し、同時刻のイベント（yum update、Inspector 2スキャン、SSMセッション開始）を列挙 「SSMセッション内でCPU集約的なコマンドを実行した可能性がある」と推測 → 実際に正しい方向の推測 調査した結果原因を断定できなかったので仮説を立てている 各仮説に「可能性がある」という表現を使い、断定を避けていた 「調査ギャップ」として確認できなかった事項を明確に報告 真の原因（yesコマンド）にはOS内部のプロセス情報がないため到達できませんでしたが、仮説と事実を区別した誠実な調査結果でした。 調査コスト: 約6分（360秒）→ $2.99（$1=¥150換算で約¥448） 追加検証: SSMセッションログを有効にして再検証 検証1ではDevOps Agentが実行コマンドを特定できなかった原因は、SSMセッション内で何を実行したかのログがCloudWatch Logsに送信されていなかったためです。そこで、SSM Session ManagerのCloudWatch Loggingを有効にし、セッション中のコマンド入出力をCloudWatch Logsに記録する設定を追加した上で、同じCPU高負荷を再現して調査を依頼しました。 調査依頼プロンプト: EC2インスタンス(i-xxxxx )のCPU使用率が急上昇しました。原因を調査してください。 結果: 根本原因を「IAMユーザーxxxxxによる意図的なCPUストレステストの実行」と正確に特定 実行コマンド（ for i in $(seq 1 $(nproc)); do (yes > /dev/null) & done ）を特定 実行ユーザー、セッションID、起動されたプロセスのPIDまで特定 「計画的な負荷テストであり、システム異常やマルウェアではない」と正しく判断 SSMセッションログという1つのデータソースを追加しただけで、検証1の「仮説止まり」が「正確な原因特定」に変わりました。DevOps Agentの調査精度がデータソースの充実度に直結することを改めて裏付ける結果となりました。 検証2: メモリ逼迫によるOOM Killer発動 stress-ng でメモリを枯渇させ、OOM Killerによってhttpdが強制終了される状況を作り、DevOps Agentに調査を依頼しました。検証1と異なり、OOM Killerのログが /var/log/messages → CloudWatch Logs経由でDevOps Agentの調査対象になります。 調査依頼プロンプト: EC2インスタンス(i-xxxxx )上のWebサーバー（httpd、ポート80）が応答しなくなりました。原因を調査してください。 結果: 根本原因を「stress-ngツールによる意図的なメモリ枯渇テスト」と正確に特定 実行ユーザー（SSMセッションユーザー）を特定 実行コマンドとパラメータ（ stress-ng --vm 1 --vm-bytes 900M ）まで特定 OOM Killerが全httpdプロセス（PID含む）を強制終了したことをログから読み取り タイムラインを正確に構築（00:07:17 → 00:11:29 → 00:17:32） メモリ枯渇 → OOM Killer → httpd停止 という因果関係に正しく到達 検証1では仮説止まりだったのに対し、CloudWatch Logsにカーネルログという明確な根拠があったことで、正確な原因特定ができました。 また、調査完了後に「緩和計画」という機能を実行したところ、stress-ngプロセスの停止 → httpdサービスの再起動 → 事後検証（HTTP 200 OK確認）まで、具体的なコマンド付きの復旧手順を提示してくれました。手順通りに実行してWebサーバーの復旧を確認できました。 調査コスト: 約5分（304秒）→ $2.52（$1=¥150換算で約¥379） わかったこと 良かった点 AWSのAPI経由で取得できる情報を横断的に分析し、タイムラインを構築する能力は高い CloudWatch Logsに根拠となるログが存在する場合、実行コマンド・ユーザー・タイムラインまで正確に特定できる（検証2で確認） 調査ギャップ（確認できなかったこと）を報告する仕組みがある EC2インスタンスへの変更やエージェントのインストールは不要 従量課金制で、調査しなければ費用は発生しない 注意が必要な点 OS内部のプロセス状態やローカルログには直接アクセスできない CloudWatch Logsに送信されていない情報は調査対象外 データソースに根拠がない場合、仮説止まりになる（検証1で確認） 調査精度の比較 検証 データソースの根拠 原因特定 評価 検証1（CPU高負荷） △ メトリクスのみ × 仮説止まり 真の原因に到達できず 検証1 追加検証（SSMセッションログ有効） ○ メトリクス + SSMセッションログ ○ 正確に特定 コマンド・ユーザー・PIDまで特定 検証2（メモリ逼迫） ○ メトリクス + OOM Killerログ ○ 正確に特定 コマンド・ユーザーまで特定 まとめ DevOps Agentの調査精度は、データソースに残る根拠の有無に大きく依存します。検証1ではメトリクスだけでは仮説止まりでしたが、SSMセッションログを1つ追加しただけで正確な原因特定に変わりました。 導入を検討する場合は、DevOps AgentがAPIレベルで情報を取得できる環境を整備しておくことが重要だと感じました。CloudWatch Agentによるログ・メトリクスの送信はもちろん、CloudTrailの有効化やVPCフローログの設定など、DevOps Agentが参照できるデータソースを充実させて調査精度を向上させることで、インシデント調査はエージェントにお任せし、業務効率を向上させていきましょう！

こんにちは。SCSKの松渕です。 今回は、ある歌手の歌詞を ベクトル化＆簡易的なデータ分析 してみました。 3/10に発表されたばかりの Gemini Embedding 2 モデル を利用してみました！ はじめに 組み込みモデル（Embedding Model）とは？ 一言で言うと、「言葉や画像の意味を、コンピューターが計算できる『座標（ベクトル）』に変換する技術」のことです。これまでのキーワード検索（完全一致）とは異なり、データの「文脈」や「ニュアンス」を数値化します。 なぜ「ベクトル」にするのか？ 例えば、「ネコ」と「子猫」という言葉は、文字で見れば一字も重なりませんが、意味は非常に近いです。組み込みモデルを通すと、これらは多次元空間上で「非常に近い距離にある点」として配置されます。 キーワード検索: 「文字」が同じものを探す。 セマンティック検索（Embedding）: 「意味」が似ているものを探す。 実務での役割 近年のAI開発、特にRAG（検索拡張生成）においては、膨大なドキュメントから「ユーザーの質問に最も関連する箇所」を特定するための「検索の脳」として機能しています。   Gemini Embedding 2 とは？ 2026年3月にプレビューが開始された  gemini-embedding-2-preview は、 これまでの テキスト専用モデルから大きく進化 を遂げました。 1. 待望の「マルチモーダル」対応 何といっても 最大の特徴はネイティブマルチモーダル対応 です。テキストだけでなく 画像や動画も同じベクトル空間にマッピングできます 。 「この動画の、このシーンに似た画像を、テキストで検索する」といった、メディアを跨いだ検索が極めて高い精度で実現可能になりました。 テキスト、画像、動画、音声、およびPDFの5つの異なるモダリティが、モデルの中間層（隠れ層）において動的に相互作用し、深いレベルでの「セマンティック・フュージョン（意味的融合）」が実現されます 。例えば、 動画内の特定の動き と 添えられた説明テキスト が、 単一の3,072次元ベクトル空間内に矛盾なく配置 されるのである 。 これで「なんかスパイ映画のオープニングっぽい映像」とかをテキストで映像検索できるようになります。 もちろん今までも実現できてはいたんですが、いったんテキスト化してベクトル化が必要だったのが不要になったようです。   2. マトリョーシカ・エンベディング（次元の柔軟性） 通常、ベクトルの次元数（1536次元など）は固定ですが、gemini-embedding-2では次元を削っても精度が落ちにくい」設計が採用されています。マトリョーシカ人形のように、 大きなベクトル（3072次元）の中に、小さなベクトル（768次元や256次元）が綺麗に入れ子 になって入っています。 高精度が必要な時: 1536次元でフルパワー解析。 コストや検索速度を優先する時: 256次元に圧縮してインデックス容量を削減。 といったように、用途に応じてインフラのコスト最適化とパフォーマンスのバランスを柔軟に取れるようになっています。 次元数は検索速度とのトレードオフにもなっているため、1次検索は低次元で素早く、2次検索は高次元で品質高く、といった使い分けもできます。 特に 768次元への縮小 は、精度低下を最小限に抑えつつ、ストレージコストを約75%削減できるため、Googleはこれを 推奨 しています 。 エンベディング(Google Cloud ドキュメント) 3. 長文対応とコンテキスト理解の深化 従来モデルよりも一度に処理できるトークン数（入力できる文章量）が拡大し、ドキュメント全体の一貫性をより深く理解したベクトル生成が可能になりました。これにより、RAGにおける「情報の取りこぼし」が劇的に減少しています。 うれしい点としては、 細かいチャンクに刻む必要がなくなった ため、「文章の前後関係（文脈）がぶった切れる」という今までのRAG特有の悩みが一定解消されます。8kあれば、一般的な章立て一つ分や、 中規模なPDFなら丸ごと一つのベクトル として取り込めるため、検索の精度（セマンティックな一致度）が劇的に向上します。 機能 Gemini Embedding（従来） Gemini Embedding 2 対応データ テキストのみ テキスト・画像・動画 次元数 固定 可変（マトリョーシカ対応） 検索精度 高い 極めて高い（最新MTEB基準） 主な用途 テキストRAG マルチモーダルRAG / 高度な検索 まとめてみて知ったのですが、 音声（音楽）にはまだ対応していない ようです。時間の問題だとは思いますが。   今回やってみたこと ある有名歌手（2026/3/28現在、288曲リリースされていました）の 歌詞をベクトル化 して、 クラスタリング してみたいと思います。 今回のブログ単体だと、上記で必死に解説し たGemini Embedding 2の良さを全然活かせていないユースケース になってしまってます。。。 いずれ、画像や映像と絡めて分析だとか検索できるようにしていきたいなと思います。   事前準備 データ準備 ブログの本質じゃないのでさらっとしますが、 めっちゃくちゃ大変でした。今回一番時間かかりました。 以下のような、CD名と歌詞のリストです。今回は歌詞しか使わないですが、いずれ発売年ごとに傾向分析とかしてみたいと思って付与してます。     ベクトル化とBigquery格納とクラスタリング まずはエクセルからBigQueryへ 先ほどのエクセル歌詞の部分をベクトル化しますが、処理しやすいようにまずBigQueryへ投入します。 なお、Antigravityですべて機能開発してもらいました。Antigravityのブログは 以前に書いた ので今回は割愛します。 日本語で依頼すればこのレベルの処理はすぐ実装してくれるかと思います。   ベクトル化してBigQuery投入 Vertex AIでGemini呼び出して、各曲ごとのベクトルを作成してもらいます。 この際、 google-genai SDKを使用 し、 gemini-embedding-2-preview モデル を利用して数値ベクトルに変換します。 gemini-embedding-001では設定できていた ユースケースの設定（task_type） はgemini-embedding-2-previewでは 使用できなく なっております。 プロンプトにタスクの指示を追加 する必要があります。 今回でいえばベクトル化する際の指示プロンプトに以下のような入力をします。 t ask: clustering |  query: {content}   ユースケースの設定 の前提として、情報検索や埋め込みベクトルの世界で「対称的（Symmetric）」と「非対称的（Asymmetric）」という分類があります。 対称的な検索（Symmetric Search） ： 「似たもの同士」を探すパターン です。クエリ（入力）とターゲット（対象）の長さや情報の密度がほぼ同じ場合を指します。 非対称的な検索（Asymmetric Search） ： 「短い問い」から「長い答え（あるいは詳細な情報）」を探すパターン です。現代の検索エンジンやAIチャット（RAG）の多くはこの形です。 今回のようなクラスタリング用のベクトルは対称的な検索になります！ エンベディング(Google Cloud ドキュメント) ベクトル化無事できました   クラスタリング ベクトル化の次はクラスタリングします。 エルボー法を用いて、クラスタリングする適切な数を探し出します。 ※私自身、ちゃんとエルボー法を理解していないのですが、Antigravityによくわからないまま依頼したら作ってくれましたし動きました。 ざっくり以下のような動きをしているようです。 候補となるクラスタ数（k）のループ 「何グループに分けるのが適切か？」を判断するために、2から最大10までで、 力技で全てのパターンを計算 します。 k=2, 3, 4, …, 10  のそれぞれで K-Means を実行します。 エルボー法による「曲がり角」の特定 「グループを増やしても、もう 劇的には誤差（クラスタ中心点から各要素の距離の二乗和（SSE））が減らなくなった地点 」が、そのデータセットにとって 最も自然なグループ数（最適な k）であると判断 します。 KneeLocator による自動判定 通常、エルボー法は人間がグラフを見て判断しますが、このコードでは プログラムで自動判定 しています。 プロットされた曲線の「曲率」が最大になるポイントを数学的に算出しています。 最終的なクラスタリングの実行 決定された「最適な k 」を用いて、 もう一度 K-Means を実行 し、各歌詞に cluster_id（0, 1, 2…）を割り振ります。 今回は288曲を 4クラスタに分類 されました。   Vertex AI(Gemini)で、クラスタの特性を分析 ベクトル化してのクラスタリングは、 ブラックボックス的な数学的分類 となります。 そのため、そのままでは 説明性（Interpretability）を持ちません。 そのため、Geminiへ各クラスタの意味の説明を求めました。以下、Geminiの分類への説明です。 以下の説明でどの歌手かわかった人はジャンキーかもしれません・・・！ クラスター1：【生理現象・身体感覚系】（Biometric Cluster） 　このクラスターは、恋愛感情を直接的な形容詞ではなく、心拍数の変化、皮膚の温度、体調の違和感として描写する楽曲群である。感情が脳ではなく「肉体」に宿っていることを強調する。 クラスター2：【生活空間・日常痕跡系】（Domestic Trace Cluster） 　このクラスターは、洗面所、台所、廊下といった生活空間の中に、相手の「不在の在」や「共有の証拠」を見出す楽曲群である。大きな愛を語るのではなく、小さな生活雑貨に愛を託すのが特徴である。 クラスター3：【執着・不可逆的痕跡系】（Obedient / "Curse" Cluster） 　ファンの間で「呪い」と称されることもある、非常に重厚で執着心の強い楽曲群である。 クラスター4：【季節・比喩描写系】（Ephemeral Cluster） 　季節の移ろいや気象現象に、感情のゆらぎや「戻れない時間」を投影する楽曲群である。   今回は取りませんでしたが、説明性を持たせるクラスタリングとしては以下のようなアプローチも存在します。 母数が多く、後付けでの説明が困難な際には採用検討するとよいかと思います      多段階クラスタリング：　 全データをLLMに見せるのではなく、数学的に仕分けした「中心」だけをAIに解釈させる手法。 特徴量抽出（トピックモデル）を介した分類： 　高次元のベクトル（3072次元など）を、人間が理解しやすい2次元や3次元に圧縮して、「地図」を作る手法。 「LLM蒸留」による分類器の構築 (Distillation) ：　LLMの知能を、より軽量で高速な「分類専用モデル」に移植する手法。   まとめ 最新の Gemini Embedding 2 を使って、一見「データ化」とは対極にあるような 情念の世界を可視化 してみました。 数学的に導き出された4つのクラスタは、驚くほど正確に彼女の楽曲が持つ「多面性」を捉えていました。特に、特定の生活雑貨に宿る記憶や、身体感覚で語られる恋、あの歌詞特有の 重さ みたいなものまでもが、 3,072次元の空間において明確な座標として存在 していたことには、一人の技術者として、そして一人のファンとして震えるものがありました。 技術は、時に「意味」を冷徹に分解しますが、今回のように「言葉にできない魅力」を再発見する手助けもしてくれます。次は、マルチモーダルモデルの真骨頂である画像や動画（MV）を組み合わせ、彼女の表現する世界をより多角的に、深く、ベクトル空間の中に再現してみたいと思います。

こんにちは、SCSKのhosynary（江浜）です。 SCSKでは現在、社内のデータ活用基盤としてSnowflakeを採用しており、Snowflake Intelligenceの利用についても検証を行っています。 Snowflake Intelligenceを使って社内データ活用のPoCを始める – TechHarmony 特に回答精度については、現在運用中の定型ダッシュボードと同じデータモデルを参照したうえで、Snowflake Intelligence上で同等のインサイトを得ることができるか、といった観点でいくつかの品質確認項目を設けて検証を行っています。 検証を進める中で、 なぜ数値が合わないのか なぜ意図した回答にならないのか といった課題に直面しました。 本記事では、検証を通じて見えてきたSnowflake Intelligenceの運用においてチューニングが発生する可能性が高いポイントを、3つの観点から整理してみました。   Snowflake Intelligenceのチューニングポイント 運用の中でチューニングが発生するポイントは、大きく次の3つです。 Cortex Agent Semantic View データモデル いずれもSnowflake Intelligenceの出力精度や使い勝手に直結する重要な要素です。 ここから、それぞれの項目についてチューニングポイントを述べていきます。   Cortex Agent 役割 Cortex Agent は、ユーザーからの自然言語による問い合わせを 全体としてどのように解釈するか を制御する役割を担います。 使用するSemantic Viewの選択やWeb検索の有効／無効といったエージェント自体の設定だけでなく、 年度の考え方（例：4月～翌年3月を1年度とする） 指標の解釈ルール 分析時の前提条件の明文化 など、エージェントの出力全体に関わる共通ルールを定義します。 チューニングが必要になるタイミング 全体的に意図しない回答が生成される場合 回答内容がタイミングによってぶれる場合 こうしたケースでは、 Cortex Agent 側で定義内容を修正する対応が必要になります。 主な設定内容 会計等に関わる統一ルール 年度の考え方や、「売上」「売上高」「収益」は本システムでは同義語として扱う等同義語のルール 設定例イメージ 「“年度”という表現が使われた場合は、4月から翌年3月までの12か月を対象として分析する」 回答できない場合の設定 設定例イメージ 「データが不足している、または定義が曖昧な場合は、推測で回答せず「確認が必要」である旨を明示する。」 これらに加え、一般的にAIエージェントで広く設定されている項目についても、あわせて定義しておくことが重要です。 検証で見えてきたポイント 出力全体に関わる部分であるため、なるべく初期構築段階で必要そうな設定項目を洗い出しておくことが重要 修正自体は容易   Semantic View 役割 Semantic Viewは、 Snowflake上のデータモデルをAIに解釈させるためのセマンティックレイヤー です。 どのテーブルが何のデータか どのカラムがディメンションか／メトリクスか どの質問にどういったSQLを使うべきか といった情報を yamlファイル等 で定義します。 チューニングが必要になるタイミング データモデルが更新された場合 一部の質問で、意図しないSQLが生成される場合 合計値や指標の解釈がずれる場合 こうしたケースでは、Semantic View側で メトリクスや説明、検証済みクエリを修正、追記 する対応が必要になります。 主な設定内容 質問パターンごとの参照先テーブル指定 「質問の分類化」欄を修正することで内容に応じてどのテーブルを参照させるか自然言語で定義することが可能です。 設定イメージ 「“組織別の売上に関する質問はXXXXを、品目別の売上に関する質問はXXXXXのテーブルを参照してください」 メトリクス定義（合計・平均・条件付き集計など）の設定 「ディメンション」、「ファクト」、「メトリック」欄を修正することで どのカラムが何を表しているか 、 言葉の定義が何をもって計算されているか（計算ロジック） を カラム名やSQL関数等 を用いて定義することが可能です。 設定イメージ <任意のファクト名> 予算に対する見込の達成率。単位はパーセント <見込値を表すカラム> / NULLIF(<予算値を表すカラム>, 0) * 100　·NUMBER(29,9) 検証済みクエリ（想定SQL）の追加 検証済みクエリは質問内容とその際に実行する想定SQLをあらかじめ設定しておくことでより正確な回答を生成してくれます。 設定しておくと、質問に似ている場合にのみ検証済みクエリは使用され、レイテンシの低減にも繋がります。 設定イメージ 質問例：2025年度の計上済の売上推移について社外と社内売上の合計を月ごとに累積値で棒グラフで表現してください SQL例：～ 検証で見えてきたポイント Semantic Viewは既存のデータモデルから自動生成しただけでは完結しないケースが多く、正確なチューニングには 社内ルールの把握 や、 業務・データへの理解が不可欠 です。そのため、運用フェーズでは 最も作業頻度が高くなりやすいポイント と言えます。 現状は公開いただいている自動生成プロシージャ( Snowflake のセマンティックビューを AI で自動生成しよう )や、Semantic View Autopilotを用いて初期で作成をしたのちに、出力やSnowflake Intelligenceのログを確認して正しい解釈を加えるチューニングを実施中です。 今後は Cortex Code 等のAI駆動型ツールや、 Cortex Search 等のテキストデータに特化した検索ツールを組み合わせて、連携先システムの設計書・仕様書、業務ロジック、社内定義を埋め込んだSemantic Viewを効率的に作成して、正しい解釈を加えていく方式を検討する必要があるなと考えています。   データモデル 役割 データモデルは、 Snowflake Intelligenceが参照する実テーブル を指します。 出力の土台 のようなものなので、ここが不安定だとどれだけAgentやSemantic Viewを調整しても限界があります。 チューニングが必要になるタイミング 分析対象データの拡大 新しい分析軸の追加 既存データの粒度や構造が合わなくなった場合 これらに対応するため、 新規テーブルの追加 既存テーブルへのカラム追加 集計・明細テーブルの分離 といった SQLによるデータモデル（テーブル定義）の修正 が必要になります。 検証で見えてきたポイント AIが誤認しにくいよう、 意味が明確で一貫性のあるデータモデルを整備すること が重要だと感じています。 特に参照先がBIツール前提のデータモデルの場合、BI上では表示制御することで問題ないようなデータの持ち方でも、 AIでは誤認識される ようなケースが出てきます。例えば合計値と明細が同一のテーブルに格納されていることで合計値を出力する際の2重計上されるケースや、年月の表記をBI出力用に文字列型に変換してあることで月次での出力結果が意図しない結果を出力するケースなどがあります。 意図しない出力に対して随時Semantic Viewに解釈を加えていくアプローチは、今後増えていく全てのSemantic Viewやエージェントに対して修正が増えていくことに繋がるので、元のデータモデルを見直すことは大きい意義を持ちます。 またデータモデルから構築する場合はAI側が正しく理解できるようにモデルやカラムの命名についても留意する必要があります。 構築ルールや命名規則等を明確にし、Semantic View等と合わせて AIも人も理解しやすいデータモデル として整備していくことが重要かと思います。   まとめ Snowflake Intelligenceは導入すればなんでも正確に回答をしてくれるツールではありません。 Cortex Agent Semantic View データモデル この3層を 運用しながら育てていく ことが重要です。   一方で、これらの整備や運用に時間がかかりすぎてしまっては本末転倒です。 今後の課題として効率のよい開発方式や構成管理方式、運用方式を合わせて検討していくことが必要だなと感じています。 導入検討中の方、すでに検証を進めている方の参考になれば幸いです。

こんにちは。SCSKの岡尾です。 皆さん、S3 Tablesについてご存じでしょうか。 AWS re:Invent 2024で発表され、話題を呼んだ新機能「 Amazon S3 Tables 」。データレイクの構築・運用を根本から変えるポテンシャルを秘めたこのサービスについて、「実際にどう使えるの？」「既存のS3バケットと何が違うの？」と気になっている方も多いのではないでしょうか。 本記事では、S3 Tablesの基本的な概要を紹介しつつ、実際にS3 Tablesへのデータ連携（ETL処理）を実装する中で「これは便利だ！」と感じた機能について、これから利用を検討している方向けに解説します。 1. S3 Tablesとは Amazon S3 Tablesは、オープンテーブルフォーマットである Apache Iceberg形式のテーブルを、S3上でネイティブに保存・管理できるフルマネージド機能 です。 これまでデータレイクを構築する際は、S3バケットにParquet形式などのファイルを配置し、AWS Glue Data Catalogでメタデータを管理してテーブルとして扱うのが一般的でした。S3 Tablesは、これをS3自身の機能として統合し、AWS Glue Data Catalogとのシームレスな連携や、テーブルのメンテナンス作業を自動化してくれます。 S3(Parquet)との比較 従来の「S3にParquetファイルを直置きする方式」と比較すると、S3 Tablesにはデータエンジニアを悩ませてきた課題を解決する強力なメリットがあります。   S3 Tables 従来のS3(Parquet) ACIDトランザクションのサポート 複数のETLジョブやユーザーが同時に読み書きを行っても、 データの整合性が完全に保証される . ファイルベースのため、データの書き込み中に別の分析クエリが走ると、不完全なデータが読み取られるリスクがある. ファイル管理・メンテナンスの自動化 S3側で自動的にファイルの コンパクション （最適化）や、不要になった古い スナップショットの削除 を行ってくれるため、チューニングや運用保守の手間が省ける. ストリーミング処理などで小さなファイルが大量に発生する（スモールファイル問題）とクエリ性能が劣化するため、定期的にファイルを結合するバッチ処理を自前で組む必要がある. レコードレベルの更新・削除 レコード単位での更新 （ UPDATE ）や 削除 （ DELETE ）が、通常のデータベースのようにSQLで簡単に実行可能. 特定のレコードを含む対象のParquetファイル全体を読み込み、除外・置換して書き直す必要がある. 2. S3 Tablesの機能紹介 ここからは、実際に外部システムからS3 Tablesへデータを連携するETL処理を実装した際に、有用だと実感した機能をご紹介します。 Upsert処理 データ連携において「新規レコードは追加（INSERT）し、既存レコードで変更があったものは更新（UPDATE）する」という Upsert処理 は頻出要件です。 従来のS3(Parquet)環境でUpsertを実現しようとすると、対象データの全量読み込み、IDベースでの差分結合、そして新しいファイルの再生成という泥臭く重い処理を書く必要がありました。 しかしS3 Tablesを利用することで、Amazon AthenaやAWS Glue（Apache Spark）などから** MERGE INTO 構文を使ってシンプルにUpsert処理を記述できる**ようになります。 ＜サンプルコード＞ spark.sql(f""" MERGE INTO glue_catalog.{S3_DATABASE_NAME}.{S3TABLE_NAME} AS t USING staging AS s ON {" and ".join(join_phrase_list)} WHEN MATCHED THEN UPDATE SET * WHEN NOT MATCHED THEN INSERT * """) タイムトラベル ETL運用における落とし穴として、「誤って本番データのテーブルを上書きしてしまったり、削除してしまうこと」があります。従来のS3では、オブジェクトのバージョン管理を有効にしてスクリプトを書いて復元するなど、が必要でレコード単位ではさらに労力がかかっていました。 S3 Tablesは、データが更新されるたびにスナップショットを自動的に保持しています。この仕組みを利用した タイムトラベル機能 により、過去の任意の時点のデータをクエリしたり、障害発生前の状態にテーブルを瞬時にロールバックしたりすることが可能です。 ETLのジョブ性能の検証で同じデータを用いて条件を変えながら検証する場面でこの機能を利用しました。これにより、簡単にデータが連携される前の状態にロールバックすることができ、非常に便利だと思いました。 簡単にAthenaからスナップショットの一覧を確認できます。 SELECT * FROM "<テーブル名>$snapshots" また、スナップショットからの復元は、一度データを削除してから以下のように過去の時点のデータを挿入することで可能です。 INSERT INTO "<テーブル名>" SELECT * FROM "<テーブル名>" FOR TIMESTAMP AS OF TIMESTAMP '2026-03-23 09:00:00 UTC';   障害時はさらに重宝しそうな機能だなと思いました。 3. まとめ 今回S3 Tablesを触ってみて、単なる「S3の新しい保存領域」ではなく、上手に活用することでデータレイクの課題（トランザクション管理、ファイル最適化、レコード更新など）を解決してくれるソリューションだと感じました。 これからデータ基盤の新規構築や、既存のデータレイクの刷新を検討している方は、ぜひS3 Tablesを選択肢に入れてみてください。運用負荷を大きく下げ、よりデータ活用そのものに注力できる環境が手に入るはずです。

当記事は、 日常の運用業務（NW機器設定）の自動化 により、 運用コストの削減　および　運用品質の向上 　を目標に 「Ansible」 を使用し、様々なNW機器設定を自動化してみようと　試みた記事です。 Ansibleは、OSS版（AWX）＋OSS版（Ansible）を使用しております。   Fortigateの「Objects-アドレス」の登録／変更／削除を実施してみた 事前設定 Templateを作成し、インベントリーと認証情報を設定する。 インベントリー：対象機器（ホスト）の接続先／接続方法／使用プラグインを設定する。 ansible_host: xxx.xxx.xxx.xxx --- ansible_host: xxx.xxx.xxx.xxx　←　接続先IPを指定 ansible_connection: httpapi　 ←　FortiGateは、デフォルト接続方式（ssh）ではなく、HTTP/HTTPS(API)を使用 ansible_httpapi_use_ssl: yes　 ←　HTTP/HTTPS(API)を使用する際、HTTPSを使用 ansible_httpapi_validate_certs: no　 ←　HTTP/HTTPS(API)を使用する際、証明書のチェックを無視（証明書が信頼できないエラーを回避） ansible_network_os: fortinet.fortios.fortios 　←　接続方式（httpapi）を使用する場合、使用するプラグインを指定 認証情報：対象機器へのログイン情報（ユーザ名／パスワード）を設定。 ユーザ名は　　変数：ansible_user　　　に保持される パスワードは　変数：ansible_password　に保持される   Playbook作成（YAML） 使用モジュール fortinet.fortios.fortios.fortios_firewall_address 　を使用。 ※参考ページ：https://docs.ansible.com/projects/ansible/latest/collections/fortinet/fortios/fortios_firewall_address_module.html   Objects-アドレスの登録(Type：Subnet) アドレス情報(Type：Subnet)を指定して登録（state: ‘present’）を行う。 - name: Add Address(Subnet) fortios_firewall_address: vdom: "root" state: "present" firewall_address: name: "test_add001" type: "ipmask" 　　　　　　　　　←　Type：Subnet　を指定 subnet: "10.10.10.0 255.255.255.0"　　←　IP/Netmask　を指定 comment: "IP NETMASK" register: wk_result 実行結果：対象のアドレスが登録された。　※登録後のアドレス情報を抜粋 "msg": { "meta": { "results": [ { "name": "test_add001", "type": "ipmask", "subnet": "10.10.10.0 255.255.255.0", "comment": "IP NETMASK" } ], "status": "success", "vdom": "root" } }   Objects-アドレスの登録(Type：IP Range) アドレス情報(Type：IP Range)を指定して登録（state: ‘present’）を行う。 - name: Add Address(IP Range) fortios_firewall_address: vdom: "root" state: "present" firewall_address: name: "test_add002" type: "iprange"　　　　　　　←　Type：IP Range　を指定 start_ip: "10.10.10.20"　　　←　IP Range（開始）　を指定 end_ip: "10.10.10.21"　　　　←　IP Range（終了）　を指定 comment: "IP RANGE" register: wk_result 実行結果：対象のアドレスが登録された。　※登録後のアドレス情報を抜粋 "msg": { "meta": { "results": [ { "name": "test_add002", "type": "iprange", "start-ip": "10.10.10.20", "end-ip": "10.10.10.21", "comment": "IP RANGE" } ], "status": "success", "vdom": "root" } }   Objects-アドレスの変更　※同一Typeでの変更パターン アドレス情報(Type：Subnet)を指定して変更（state: ‘present’）を行う。 - name: Add Address(Subnet) fortios_firewall_address: vdom: "root" state: "present" firewall_address: name: "test_add001" type: "ipmask"　　　　　　　　　　　　　←　Typeは　変更しない subnet: "10.10.20.0 255.255.255.0"　　←　IP/Netmaskを　"10.10.10.0 255.255.255.0"から変更する comment: "IP NETMASK" register: wk_result 実行結果：対象のアドレスが変更された。※変更後のアドレス情報を抜粋 "msg": { "meta": { "results": [ { "name": "test_add001", "type": "ipmask", "subnet": "10.10.20.0 255.255.255.0", "comment": "IP NETMASK" } ], "status": "success", "vdom": "root" } }   Objects-アドレスの変更　※異なるTypeへの変更パターン アドレス情報(Type：IP Range)を指定して変更（state: ‘present’）を行う。 - name: Change Address(IP Range -> Subnet) fortios_firewall_address: vdom: "root" state: "present" firewall_address: name: "test_add002" type: "ipmask"　　　　　　　　　　　　←　 Type：IP Range　から変更する subnet: "10.10.30.0 255.255.255.0"　←　 start_ip: "10.10.10.20",end_ip: "10.10.10.21"から変更する comment: "IP RANGE -> IP NETMASK" register: wk_result 実行結果：対象のアドレスが 正しく変更されない！！ 　※変更後のアドレス情報を抜粋 "msg": { "meta": { "results": [ { "name": "test_add002", "type": "ipmask",　　　　　　　　　←　Typeは、変更された "subnet": "0.0.0.0 0.0.0.0",　　　←　subnetは、正しく設定されない。。。 "comment": "IP RANGE -> IP NETMASK", } ], "status": "success", "vdom": "root" } } 異なるTypeへの変更対応方法について 現状のAnsibleモジュールでは、異なるTypeへの変更は正しく実施されないことが分かりました。。。 その為、異なるTypeへの変更時は、変更元アドレスを削除した後に　新しいTypeのアドレスを登録するようにしましょう！   Objects-アドレスの削除 接続情報とアドレスを指定して削除（state: ‘absent’）を行う。 - name: Delete Address fortios_firewall_address: vdom: "root" state: "absent" firewall_address: name: "test_add001" register: wk_result 実行結果：対象のアドレスが削除された。　※削除後のアドレス情報なし   最後に 「Ansible」の「 fortinet.fortios.fortios.fortios_firewall_address 」を使用し、「Objects-アドレス」の登録／変更／削除　ができたことは良かった。しかし、現状　設定情報がベタ書きで使い勝手が悪いので、今後　設定内容をINPUTする仕組みを試みたいと思います。これに伴い、何らかの変更申請の仕組みと連携することができ、より設定変更の自動化が活用できるようになると思います。

こんにちは！ 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スタック１つで）以下を全部作ります。 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から「いいね」を貰うことができて嬉しかったです。

こんにちは。ＳＣＳＫの池田です。 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連携まで含めた“アプリもデータも守る”設計で、止めないシステム運用を支援します。  詳しい内容をお知りになりたいかたは、以下バナーからお問合せください。