※本記事は、ホスト系COBOL処理系からオープン系COBOL処理系への移行検証を整理する連載の第8回です。 1. なぜソート順を検証したのか ソート順の違いは、目に見えやすい差異です。 しかし問題は、 並び順が変わること＝業務ロジックが変わること にあります。 特に、 キー順処理 最小値／最大値取得 先頭レコード判定 重複判定 などに直接影響します。 2. 差異の根本原因 2.1 文字コードの違い 項目 ホスト環境 オープン環境 英大文字 連続配置 連続配置 英小文字 大文字より後 大文字より後 数字 英字より前 英字より前 記号 環境依

はじめに 自身は以前、Databricksを利用した案件に携わっていました。その案件では、ジョブの作成や実行をジョブとパイプラインのUI画面から行っていましたが、手作業による操作はミスをしやすく、またミスに気づきにくい という課題がありました。 この対策としてDatabricks CLIを活用する方法が考えられますが、社内規約や利用環境の制限により、CLIを使用できないケースも少なくありません。 本記事では、Databricks REST APIを用いて、Databricks CLIやジョブ／パイプラインのUI画面を操作することなく、Notebookだけでジョブの作成から実行までを行

はじめに Oracle Alloy の「Select AI」を、インターネットに公開されていないプライベートなLLM（Ollamaなど）と連携させて検証するための手順を解説します。 手順は少し長くなるため、 　①VCN の構築 　②コンピュートの準備 　③Autonomous Databaseの作成 　④LLM の準備と Select AI の実行確認 といった４つに分けて説明します。 第1回目はすべてのリソースの基盤となる仮想クラウド・ネットワーク (VCN) の構築です。 なぜこの設定が必要か？ プライベートLLM で Select AIを試すためには、安全なプライベート・サ

はじめに Datadog Bits AI SREは、アラートを起点に関連情報を横断的に参照し、原因候補や調査の方向性を提示してくれる機能です。障害対応を支援してくれる一方で、使ってみると、有効化しただけで十分に活用できるわけではなさそうだと感じる場面もありました。 そこで今回は、Tag設計、Monitorメッセージ、Runbook、Feedback（Memory） の4観点から、Bits AIの回答品質がどう変わるかを検証しました。 結論として、Bits AIの有用性は機能そのものよりも、Tag設計やRunbook、Monitorメッセージなどの整備状況に大きく左右されることが分かり

はじめに Google BigQuery は、Google Cloud のサーバーレスなデータウェアハウスです。 大量データの集計や分析を SQL で実行でき、インフラ管理をほとんど意識せずに使えます。 その BigQuery 上で、機械学習を SQL を用いて操作できる機能が BigQuery ML です。 AI関数が増えたことで、SQLだけで予測や異常検知を試せる範囲が広がりました。 2025年以降の主な BigQuery の AI 機能アップデートは以下です（2026-04 時点）。 ※ 一部に Preview の機能を含みます。最新の提供状況は各関数の公式ドキュメントを確認し

はじめに 昨今、ランサムウェアをはじめとするサイバー攻撃による被害が深刻化しています。 ログ分析や不正検知は昔から取り組まれてきたテーマですが、不正は複数のイベントの関連の中で現れることが多く、単発のイベントだけでは検知が難しくなっています。 特にクラウドやSaaSでは、管理操作やデータアクセスがAPIや複数サービスに分散して監査ログに記録されるため、個々の操作は自然に見えても、主体・対象の関係を横断して見ると不自然さが現れることがあります。 そこで本記事では、クラウド監査ログ向けに設計した不正検知の一つのアプローチと、その検証結果について解説します。 クラウドログで見抜くべき

※本記事は、ホスト系COBOL処理系からオープン系COBOL処理系への移行検証を整理する連載の第7回です。 1. なぜ移送属性を独立観点としたのか COBOLにおける MOVE 文は、単なる代入ではありません。 内部では、 型変換 桁調整 符号処理 表現形式変換 が発生します。 そのため、 文法は同じでも結果が変わる 可能性があります。 2. 検証設計 検証軸 送出し側の型 受取り側の型 桁数差 符号有無 表現形式（DISPLAY / COMP / COMP-3） 3. 基本検証コード IDENTIFICATION DIVISION.

※本記事は、ホスト系COBOL処理系からオープン系COBOL処理系への移行検証を整理する連載の第6回です。 1. なぜ中間演算精度を検証したのか 演算結果が一致していても、 内部の計算過程が異なれば将来的な誤差が発生する可能性があります。 特に金額系では、 桁あふれ 丸め 符号処理 内部表現 が業務結果に直結します。 2. 検証設計 確認観点 COMPUTE ADD / SUBTRACT ROUNDED有無 桁あふれ COMP / DISPLAY差 符号桁 3. 検証コード例 IDENTIFICATION DIVISION. PR

はじめに 前回の記事では、Apache Spark（以下Spark）からApache Iceberg（以下Iceberg）に対してMERGE INTOを実行する際に、ON句でtarget側のデータを絞り込むことで、shuffleに流れ込むデータ量を減らす方法を確認しました。 https://zenn.dev/kentyy/articles/485a2b368370bc しかし、データの特性上ON句でtarget側のデータ量を絞り込めない場合もあります。またJOIN自体は無くならないため、source側のデータ量が多いとshuffleコストは高くなります。 そこで、本記事では、Spar

はじめに この記事で扱うこと k6の既存CSVモジュール（k6/experimental/csv）に、タイムスタンプを考慮したデータ放出タイミングの制御——リプレイ機能——を追加した実装を紹介します。 実装の設計判断、peek()バッファの導入、および2点の検証（タイムスタンプ忠実性・実行効率比較）について述べます。 自己紹介 NTTデータグループ 技術革新統括本部に所属している鈴木刀磨です。 高負荷環境における並列分散システムの検証や、性能評価に関する研究開発に従事しています。 本記事で紹介するリプレイ機能は、実際の概念実証（PoC）において「実トラフィックに近い負荷を再現

はじめに Observabilityの文脈でAI活用への期待が高まっています。ログ・メトリクス・トレースが揃っていても、障害発生時に「どこから見ればよいか」「どの仮説を先に当たるべきか」で時間を使ってしまうことは、現場では珍しくありません。 今回、AIを活用したObservability高度化をテーマに、DatadogのAI機能（Bits AI SRE）を用いた障害解析検証を実施しました。本記事では、その検証結果をもとに、AIが実際にどこまで役立つのか、そして何が限界なのかを紹介します。 ! この記事は2026年3月時点の検証結果をもとにしています。機能のUpdateにより記載の結果

はじめに Informatica IDMC（Intelligent Data Management Cloud）を運用するうえで、「誰に何をさせるか」を制御するロール設計は不可欠です。 ドキュメントでは、ロールについて次のように定義されています。 A role is a collection of privileges that you can assign to users and groups. To ensure that every user can access assets and perform tasks in your organization, assign a

はじめに AIを活用した開発が一般化するにつれて、API利用料を日常的に意識する場面が増えてきました。 最近では、ノートPC上で動作する自律型 AI エージェント（例：OpenClaw など）や開発支援ツールを常時稼働させ、外出先からスマートフォン経由で指示を与えるような利用スタイルも増えつつあります。 このような環境では、API利用料はバックグラウンドで継続的に増加するため、 「気づいたら想定以上の課金が発生していた」 という状況が起こり得ます。 しかし実際の運用では、以下のような課題があります。 API利用料を確認するために OpenAI Platform（管理コンソール）を毎

本記事は「IDMC REST API入門」シリーズの第4回（最終回）です。全4回にわたって、REST APIを使ったログインからジョブ実行・監視・ログ取得までの一連の流れを、公式ドキュメントの記述を交えて解説します。 シリーズ一覧： 第1回：REST APIの基本とログイン 第2回：ジョブ実行と停止 第3回：ジョブの監視 第4回：ログ取得とまとめスクリプト　👈 本記事 はじめに 第3回では、activityMonitor（実行中ジョブ）とactivityLog（完了済みジョブ）の2つのAPIでジョブの状態を監視する方法を解説しました。 ジョブが完了（成功・失敗問わず）した後、次に必

本記事は「IDMC REST API入門」シリーズの第3回です。全4回にわたって、REST APIを使ったログインからジョブ実行・監視・ログ取得までの一連の流れを、公式ドキュメントの記述を交えて解説します。 シリーズ一覧： 第1回：REST APIの基本とログイン 第2回：ジョブ実行と停止 第3回：ジョブの監視　👈 本記事 第4回：ログ取得とまとめスクリプト はじめに 第2回では、REST APIでのジョブ実行と停止を解説しました。ジョブを実行したら、次に必要なのは「ジョブが正常に完了したか？失敗したか？」を確認することです。 IDMCにはGUIのモニタ画面がありますが、REST

Vertex AI で実現するオンライン需要予測 — ブラウザのみで完結する構築ガイド はじめに この手順でできること Google Cloud の Vertex AI を使用して、オンライン（リアルタイム）需要予測 を REST API 経由で実行できる環境をハンズオンで構築します。 通常、Vertex AI Forecast（AutoML Forecasting）はバッチ推論のみ対応ですが、Tabular Workflow for Forecasting テンプレートを使用することで、学習済みモデルを Vertex AI Endpoint にデプロイし、API 経由のオン

※本記事は、ホスト系COBOL処理系からオープン系COBOL処理系への移行検証を整理する連載の第5回です。 1. なぜファイル定義を独立観点としたのか COBOLにおけるFD句は、単なる構造宣言ではありません。 RECORDING MODE BLOCK CONTAINS レコード長 固定長／可変長 ラベルレコード これらは、実行環境と密接に結びついています。 言語仕様は同じでも、 I/Oの前提が変われば動作が変わります。 2. 検証観点 以下の観点で確認しました。 OPEN時の挙動 READ時のレコード解釈 レコード長の扱い EOF検知のタイミング 固定長／可変長の差

※本記事は、ホスト系COBOL処理系からオープン系COBOL処理系への移行検証を整理する連載の第4回です。 1. なぜデータ例外を独立観点としたのか データ例外は単なる異常系ではありません。 移行時に問題となるのは、 例外が発生するかどうか どの命令で発生するか 発生後の処理が継続するか停止するか 戻りコードやメッセージの違い です。 つまり、 例外の“存在”ではなく、“構造”が問題 になります。 2. 検証設計 2.1 検証軸 ステートメント軸 MOVE ADD SUBTRACT COMPUTE DIVIDE IF（比較） DISPLAY データパタ

1. はじめに 最近、SC-100 をはじめとする Microsoft のセキュリティ資格と、Google Cloud の Professional Cloud Security Engineer を取得しました。学習を進める中で印象的だったのは、Microsoft Azure と Google Cloud が、同じようなテーマを扱っていてもセキュリティ設計の発想にはかなり違いがあるという点です。 特に違いが出やすいと感じたのは、「どこをセキュリティの境界と捉えるか」 と 「何を起点に設計するか」 の2つでした。資格試験は知識の確認だけでなく、ベンダーがどのような前提でセキュリティを

1. はじめに 本稿では、Kiro を用いた仕様駆動開発の検証を通じて、API 開発における生産性と品質の変化を評価した事例を紹介します。 実際の開発案件で実装された領域に対して、設計から試験工程までを Kiro で再実装し、従来開発と比較するという試みになっています。 2. 自己紹介 株式会社 NTT データ ソリューション事業本部 C&D 事業部に所属しており、パブリッククラウド領域の案件に取り組んでいます。 本稿の取り組みのような 生成 AI を活用した開発にご興味をお持ちいただけた方は、お気軽にお問い合わせください。 3. Kiro における仕様駆動開発 一般