「Py-BOL」って命名センスよ。結局AIに丸投げするんじゃなくて、人間がどう制約をかけるかが鍵だよな
「現在も1日あたり推定3兆ドルの金融取引を処理しています」銀行やクレジットカードの処理は今でもメインフレームが多い
凄いな…これで救われる現場が出る事を祈る
現代化したCOBOLのオバチャマのイラストまだ？ 荒井清和さんにちゃんと発注してね！
すごい。自分にはできないな。たとえAIを使いこなしたとしても、このアプローチは思いつかないだろう。 AI全盛でも、必要とされる技能を見たように感じる。
COBOLではPIC XやPIC 9で定義するので、-Xという変数名は普通PIC X、すなわち英数字を意味します。intにはなりません、文字列です
悪いのはCOBOLそのものではなく、長年メンテされた結果どこに何があるかが解らない、予期せぬところに影響が及びかねないという点なので、ストレートコンバージョンが出来てもそこまでハッピーになるとは限らない
ああ、PIC X(n)…
アプローチは間違ってないと思うが、もっと良い方法がありそう
BCDとか少数丸めの話は知ってるんだろうか？Pythonとの丸めの挙動の差異を完全に把握して完全一致させることは検証済みなのだろうか？Decimal使っても挙動を合わせるのは地獄。逆トランスパイラならいいのかもと思った。
Py-BOLでPythonにしたコードをAIに読ませて変数名を分かりやすくしてもらうと便利だよ、という事なのかな。自分に知識がなくてまだ凄さがわかってない。
「正確性はコンパイラ理論が、意味はLLMが担当する」この考え方、すべてのAIタスクに応用できそう
COBOLの価値はあの独特の変数管理なんだけどなぜ他の言語に移植されないのか
残存する「COBOL資産」はソースとしてのCOBOLではなく、メインフレームのメーカー独自OSとJCLとのセットで意味があるのでは？汎用言語としてのCOBOLをPythonに置き換えれても計算機アーキテクチャ含めて再現はされんような。
COBOL知らんからPIC Xやら9やらAIに解説してもらった。githubのreadme読むと WS-CUST-ID-X の想定は(慣例に反して)PIC 9みたいやが / テストセットはCOBOLで書いて両方通さんと意味ないやろ
大手各社もうLLMが出たときからやってんだよね。。。あとどんなに革新的だったとしても相手は超大手なのでコネが無いと採用されるのは難しい。
素晴らしい
後で見る
今も商業高校ってCOBOLの授業あるのかな……。
すごいな
この記事の疑問:ASTが正確に作れるのかっていうのと、変数名だけLLMに改名してもらった結果を機械的な置換でソースに適用するんじゃダメなのかというのと
やろうとしてることはわかるけどこの時点で何をどう評価して良いやら…
決定論的な領域と曖昧な領域を分ける、はLLM以前から意識するとシステムが堅牢になる考え方ではあったようには思う（末端の関数の純粋性とか、データのイミュータビリティとか）。LLMに仕事させる場合もやっぱり大事
PythonよりCOBOLの方が最後まで残ると思うので、書き換えはナンセンスですね。50年以上重要分野で使われてきた実績がありますから、今後50年も安泰です。情報系新卒こそ、COBOLとJCLと階層型データベースの勉強を。
「コンパイルも通るし実行もできるけど、保守性は絶望的」というClaude Codeと現新比較テストだけで実現できる部分を超えるのがよくわからない。変数名の意味とかそもそもCOBOLに無くてわかんないから困ってるんだよね？
「Py-BOLDはまだプロダクションツールではありません」←実験以上の“商品”として成立するようになるんだろうか。そもそも導入が検討されるような話か分からないけど、みずほみたいになりそうな予感しかしない。
読める！！読めるぞ！！ 私も古い秘密の要件を持っているんだよ
秘伝のタレには、整合性や論理的な帰結を無視した特殊処理が詰まってるから「正確性の維持」を厳守は必須。
意味エージェントでのハルシネーションは厳密には無くせないと思うけど検証エージェントで検出できればOKって感じなのかな。PIC NとかEBCDICとか10進演算とか細かいツッコミポイントはありそう
地上実況？
“-N は数値（Numeric）、-X は英数字（Alphanumeric）、-RT- はレート。”
Xは文字列だしさらに桁数定義もあるからPythonにそのまま移行するの無理じゃない？
この方の貢献はCOBOL85のsubsetのparserを書いたことと、Anthropic APIとのI/Oをsetupして変換用プロンプトを作ったことなのかな。
COBOL現代化でLLMの誤りを防ぎ、LangGraphと型付きAST、pytestで同一性検証するPy-BOLDを解説。
COBOL→Python移行でLLMの幻覚問題を回避するため、決定論的AST解析＋LLM命名＋自動pytest生成の3段エージェント構成「Py-BOLD」。正確性と可読性を分離したニューロシンボリック設計。
遺産であるCOBOLを現代化し、その正確性を自ら証明するAIを開発した話
「Py-BOL」って命名センスよ。結局AIに丸投げするんじゃなくて、人間がどう制約をかけるかが鍵だよな
「現在も1日あたり推定3兆ドルの金融取引を処理しています」銀行やクレジットカードの処理は今でもメインフレームが多い
凄いな…これで救われる現場が出る事を祈る
現代化したCOBOLのオバチャマのイラストまだ？ 荒井清和さんにちゃんと発注してね！
すごい。自分にはできないな。たとえAIを使いこなしたとしても、このアプローチは思いつかないだろう。 AI全盛でも、必要とされる技能を見たように感じる。
COBOLではPIC XやPIC 9で定義するので、-Xという変数名は普通PIC X、すなわち英数字を意味します。intにはなりません、文字列です
悪いのはCOBOLそのものではなく、長年メンテされた結果どこに何があるかが解らない、予期せぬところに影響が及びかねないという点なので、ストレートコンバージョンが出来てもそこまでハッピーになるとは限らない
ああ、PIC X(n)…
アプローチは間違ってないと思うが、もっと良い方法がありそう
BCDとか少数丸めの話は知ってるんだろうか？Pythonとの丸めの挙動の差異を完全に把握して完全一致させることは検証済みなのだろうか？Decimal使っても挙動を合わせるのは地獄。逆トランスパイラならいいのかもと思った。
Py-BOLでPythonにしたコードをAIに読ませて変数名を分かりやすくしてもらうと便利だよ、という事なのかな。自分に知識がなくてまだ凄さがわかってない。
「正確性はコンパイラ理論が、意味はLLMが担当する」この考え方、すべてのAIタスクに応用できそう
COBOLの価値はあの独特の変数管理なんだけどなぜ他の言語に移植されないのか
残存する「COBOL資産」はソースとしてのCOBOLではなく、メインフレームのメーカー独自OSとJCLとのセットで意味があるのでは？汎用言語としてのCOBOLをPythonに置き換えれても計算機アーキテクチャ含めて再現はされんような。
COBOL知らんからPIC Xやら9やらAIに解説してもらった。githubのreadme読むと WS-CUST-ID-X の想定は(慣例に反して)PIC 9みたいやが / テストセットはCOBOLで書いて両方通さんと意味ないやろ
大手各社もうLLMが出たときからやってんだよね。。。あとどんなに革新的だったとしても相手は超大手なのでコネが無いと採用されるのは難しい。
素晴らしい
後で見る
今も商業高校ってCOBOLの授業あるのかな……。
すごいな
この記事の疑問:ASTが正確に作れるのかっていうのと、変数名だけLLMに改名してもらった結果を機械的な置換でソースに適用するんじゃダメなのかというのと
やろうとしてることはわかるけどこの時点で何をどう評価して良いやら…
決定論的な領域と曖昧な領域を分ける、はLLM以前から意識するとシステムが堅牢になる考え方ではあったようには思う（末端の関数の純粋性とか、データのイミュータビリティとか）。LLMに仕事させる場合もやっぱり大事
PythonよりCOBOLの方が最後まで残ると思うので、書き換えはナンセンスですね。50年以上重要分野で使われてきた実績がありますから、今後50年も安泰です。情報系新卒こそ、COBOLとJCLと階層型データベースの勉強を。
「コンパイルも通るし実行もできるけど、保守性は絶望的」というClaude Codeと現新比較テストだけで実現できる部分を超えるのがよくわからない。変数名の意味とかそもそもCOBOLに無くてわかんないから困ってるんだよね？
「Py-BOLDはまだプロダクションツールではありません」←実験以上の“商品”として成立するようになるんだろうか。そもそも導入が検討されるような話か分からないけど、みずほみたいになりそうな予感しかしない。
読める！！読めるぞ！！ 私も古い秘密の要件を持っているんだよ
秘伝のタレには、整合性や論理的な帰結を無視した特殊処理が詰まってるから「正確性の維持」を厳守は必須。
意味エージェントでのハルシネーションは厳密には無くせないと思うけど検証エージェントで検出できればOKって感じなのかな。PIC NとかEBCDICとか10進演算とか細かいツッコミポイントはありそう
地上実況？
“-N は数値（Numeric）、-X は英数字（Alphanumeric）、-RT- はレート。”
Xは文字列だしさらに桁数定義もあるからPythonにそのまま移行するの無理じゃない？
この方の貢献はCOBOL85のsubsetのparserを書いたことと、Anthropic APIとのI/Oをsetupして変換用プロンプトを作ったことなのかな。
COBOL現代化でLLMの誤りを防ぎ、LangGraphと型付きAST、pytestで同一性検証するPy-BOLDを解説。
COBOL→Python移行でLLMの幻覚問題を回避するため、決定論的AST解析＋LLM命名＋自動pytest生成の3段エージェント構成「Py-BOLD」。正確性と可読性を分離したニューロシンボリック設計。