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

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

みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。最近1週間の生成 AI を巡っては、Anthropic Claude Opus 4.7 の Amazon Bedrock 対応や、東京リージョンでの提供開始をはじめとして、「より強いモデルを、より現場に近い場所で動かす」ためのアップデートが相次ぎました。また4月20日〜24日に開催された Hannover messe では、AI技術による生産プロセスの最適化、効率化、そして企業の競争力向上と持続可能性が主要なテーマとなっていました 。デー

DevOpsグループCREチームのy.s.です。 2026年3月25日に開催された CRE Camp #5 現場でつくるユーザー信頼性 ー LTと対話のセッション ー に参加してきました。 CRE Campは、Customer Reliability Engineering（CRE）やCustomer Support/Successに関わるエンジニアが集まり、プロダクトの信頼性向上やユーザー体験の改善について事例共有・対話するMeetupです。今回の会場は弁護士ドットコム株式会社（六本木）。LTと対話セッ

この記事は、”Reimagine your mainframe applications with Agentic AI and AWS Transform” を翻訳したものです。 本ブログでは、reimagine パターンによってメインフレームのレガシーアプリケーションをモダナイズする AWS のアプローチの概要を説明し、組織がレガシー COBOL アプリケーションをモダンなクラウドネイティブアーキテクチャに変換する方法を紹介します。 人材不足、コスト増加、ビジネスアジリティの制約により、組織はレガシー

この記事は、”Taking a comprehensive perspective to mainframe application modernization with a disposition strategy” を翻訳したものです。 はじめに メインフレームのお客様は、モダナイゼーションの選択肢が無数にあります。現在、多くの組織は、人材不足や、高額なコストとその上昇、レガシー環境ではビジネスアジリティに制限が掛かることで、モダナイゼーションが急務となっています。また、お客様自身も、モダナイゼーショ

現在、AI がメインフレームアプリケーションのモダナイゼーションを可能にすることについて、大きな期待が寄せられています。企業の取締役会は注目しています。CIO はプランを求められています。AI は COBOL のモダナイゼーションを加速する真のアクセラレーターです。しかし、確かな結果を得るには、ソースコードだけでは提供できない追加のコンテキストが必要です。400 社を超える企業顧客と一緒に仕事をした経験から私たちが学んだことは、メインフレームのモダナイゼーションには 2 つのまったく異なる側面があるという

このブログ記事では、移行途中の過渡期に於けるハイブリッドアーキテクチャの連携パターンと連携ソリューションを設計する方法を紹介します。 多くの一般的なメインフレーム環境には、データやコードを共有するアプリケーション間の複雑で密結合されたシステム間連携があります。メインフレームアプリケーションを AWS クラウドに移行するとき、大規模な移行には Strangler fig パターン を使用した段階的なアプローチが推奨されます。インクリメンタルなアプローチでは、過渡期 (移行) フェーズまたはトランスフォーメー

レガシーメインフレームアプリケーションは、企業全体の重要な事業運営のバックボーンの一部ですが、これらのシステムにはモダナイゼーションに関する重大な課題があります。メインフレームは何十年にもわたって信頼性が証明されてきましたが、多額の技術的負債を蓄積し、専門知識の需要はますます少なくなり、迅速なイノベーションと機能の導入を妨げています。AWS Mainframe Modernization with Rocket Software は、お客様が切望していたこれらのレガシーアプリケーションの知的財産を元のソー

※本記事は、ホスト系COBOL処理系からオープン系COBOL処理系への移行検証を整理する連載の第2回です。 前回は、マニュアルに書かれていない非互換が存在することを整理しました。 ▶ 第1回はこちら COBOL現新移行で「マニュアルに書いていない非互換」とどう向き合ったか はじめに 第1回では、仕様ベースの非互換抽出だけでは不十分であり、 実行結果ベースの検証が必要であることを述べました。 では、実機検証はどのように設計すればよいのでしょうか。 重要なのは、「何をどの順番で疑うか」を整理することでした。

はじめに 銀行の勘定系システムや保険の基幹業務など、 社会インフラを支える多くの重要システムはいまもCOBOLで稼働しています。 これらのシステムでは、わずかな計算差異や判定誤りも許されません。 そのため、既存環境から新しい実行環境への移行は、 単なる「言語の移し替え」ではなく、 動作結果の完全一致が求められる高度な作業となります。 しかし移行対応の中で、次のような問題に直面しました。 文法上は正しい コンパイルエラーも発生しない それでも実行結果が一致しない 論理を変更していないにもかかわらず、 環境の

はじめに 2025/12/15に人生初のハッカソンに参加してきました。 この記事では、そのハッカソン GitHub Copilot Quest：Hack the Legacy の概要と、チームで実施したアプローチ、参加しての気づき・感想をまとめていきます。 GitHub Copilot Quest：Hack the Legacy概要 アスキー社と日本マイクロソフト社によるハッカソンイベント「GitHub Copilot Quest：Hack the Legacy」は、「レガシーモダナイゼーション[1]」を

はじめに 金融系の基幹システムでは、いまでもCOBOLが現役で動いています。何十年も安定稼働してきたCOBOLのシステムは、ビジネスの根幹を支える一方で、保守担当者の減少やブラックボックス化といった課題を抱えています。 ここ数年、そうした課題に対して生成AIを使ってCOBOLソースを解析する取り組みが少しずつ広がっています。生成AIにCOBOLのソースを読み込ませ、仕様書を自動生成し、Javaなどのモダン言語への変換を支援する、そのようなユースケースが現実的になってきました。 ただし、実際にやってみるとす

2025 年 5 月、私たちは AWS Transform for mainframe をリリースしました。これは、メインフレームのワークロードを大規模にモダナイズするための、初のエージェント型 AI サービスです。AI 搭載のメインフレームエージェントは、モダナイゼーションの各フェーズにおける複雑でリソース集約型の作業を自動化することで、メインフレームのモダナイゼーションを加速します。COBOL、CICS、DB2、VSAM を含むレガシーメインフレームアプリケーションを最新のクラウド環境へ移行するプロセ

こんにちは、 豊濱 です。 現在は、プロダクト開発部で ウェルミージョブ 、 シカトル 、 カイゴジョブアカデミー のエンジニアリングマネージャ(EM)を担当しています。 この記事では、現在ウェルミージョブで取り組んでいることについてご紹介します。 少し自己紹介 まだ20世紀だったころにソフトバンクに入社し、2日目に子会社のヤフーに出向ののち正式に転籍、そこから約16年働いていました。 21世紀に入ったあたりから、インターネットの急速な普及、大容量回線によるコンテンツの進化、スマートフォンの台頭など、業界