【ABAPプログラマはもう要らない!?】ChatGPTにABAPを書かせてみた

「プログラマ、もう要らないんじゃないか！？」

そんな問いが、頭の中で何度もこだまする。

きっかけは、筆者がChatGPTに実際にABAPプログラムを書かせてみた、たった一度のトライアルだった。
結果から先に言えば、AIは完璧にABAPを書き上げた。しかも、SAP業界の熟練ABAPerでさえ「無理だろう」と尻込みしたOData APIの呼び出しを、AIは淡々と、迷いなく、書いてのけたのだ。

本記事では、筆者がChatGPT 5.5にABAPプログラムを書かせた一部始終を、実際に投げたプロンプトと完成したコードまで含めて赤裸々に公開する。そして同時に、「ABAPプログラマはもう不要なのか？」という、業界にとって極めて重い問いに、現役SAPコンサルタントの立場から正面から向き合う。

少し挑発的に聞こえるかもしれないが、SAP関係者のすべて、特にABAPプログラマとしてキャリアを歩む者には、ぜひ最後まで読んでほしい。これは決して脅しではなく、これからの時代を共に生き抜くための、率直な問題提起である。

きっかけは「ABAPからOData呼べる人がいない」現場

そもそも、筆者がAIにABAPを書かせようと思い立った背景には、ある現場での「行き詰まり」があった。
今回のトライアルは、実験のための実験ではない。れっきとした業務要件を解決するための、半ば追い詰められた末の挑戦だったのだ。

ABAPの王道はBAPI ：ABAPerはWeb APIに踏み出さない

筆者が現在関わっているS/4HANA導入プロジェクトで、ある業務要件に応えるアドオンを開発する必要があった。仕様を詰めていく過程で、技術的には「OData APIを呼び出してSAP外部のシステムと連携する処理」が必要だと判明した。ODataは技術の主流になりつつあるため、今後このような判断をする場面は増えるだろう。

問題は、開発メンバーの構成だった。チームは全員ABAPプログラマで構成されていた。経験豊富で、SE38もSE80も自在に使いこなす職人たちである。しかし、いざ「ABAPからOData APIを呼び出してほしい」と要件を伝えた瞬間、空気が止まった。誰一人として、ABAPからWeb APIを叩いた経験がなかったのだ。

これは、決して彼らの怠慢や勉強不足ではない。むしろ、ABAPerとしては当然のキャリアパスを歩んできた結果である。ABAPの世界では、SAP内部のデータ操作や業務処理を実装する場合、汎用モジュール（Function Module）やBAPIを使うのが王道中の王道だ。販売伝票を作るなら BAPI_SALESORDER_CREATEFROMDAT2、購買発注なら BAPI_PO_CREATE1 ――　SAPが標準で提供する膨大なBAPの中から、用途に応じて適切に呼び出す。これがABAP開発の常識であり、教科書通りの作法である。

一方、ABAPからWeb API（OData/SOAP)を叩くという場面は、現場にほとんど存在しない。SAP内部の処理であればBAPIで完結するし、外部システムとの連携も、伝統的には IDoc、RFCといったSAP標準のインタフェース技術で行うのが定石だった。Web APIを呼び出す必要性自体が、ABAP開発の現場ではほぼ発生してこなかったのだ。

事例が乏しい技術に対して、ABAPerが「やったことがない」「本当にできるのか？」と慎重になるのは、エンジニアとしてむしろ正しい態度ですらある。

ABAPプログラマに「OData? 無理でしょ」と言われた日

ABAPerから返ってきた言葉は、いずれも消極的なものばかりだった。

繰り返しになるが、これは彼らの怠慢ではない。前例のない領域に対して、職人として慎重に身構える――
ABAPerとしての真っ当な反応である。

とはいえ、技術的な可否で言えば、ABAPからHTTPクライアントを使ってWeb APIを呼び出すこと自体は、ずっと前から可能だった。CL_HTTP_CLIENTクラスを使えば、SOAPもRESTも、もちろんODataも呼び出せる。SAP自身、これらのクラスは何年も前にリリースしている。

問題は技術的な制約ではなく、現場にノウハウが蓄積されていないという、純粋な「経験不足」だった。
誰もやったことがない、書ける人が身近にいない、頼める相手がいない――
この三重苦に、プロジェクトは行き詰まりかけた。

そのとき、筆者の頭をよぎったのが

「AIに書かせてみたらどうか」

というアイデアだった。Web上では、生成AIがコードを書く話は山ほどある。

しかし、ABAPでも通用するのか？
その答えを、自分の手で確かめてみることにした。

なお、今回のトライアルで使用したSAP S/4HANA環境は、以下の記事でも紹介している「Professor’s RSA」である。

半信半疑だった「ABAPで生成AIは通用するのか」問題

正直に告白する。筆者は、ABAPに対する生成AIの実力には、最初かなり懐疑的だった。これには、それなりに理由がある。

生成AIは Python や Java は得意。ではABAPは?

世間で「AIにコードを書かせた」という成功事例の大半は、PythonかJava、あるいはC#といった、メジャーなプログラミング言語の話である。これらの言語は、GitHubを筆頭に、世界中に膨大な量のサンプルコードが存在する。AIはそれらを学習データとして取り込んでいるため、当然、高い精度でコードを生成できる。

では、ABAPはどうか。

ABAPはSAP独自のプログラミング言語であり、世界中のプログラマ人口で見ればごくマイナーな部類に入る。GitHub上にあるABAPコードの量は、Pythonとは比べるべくもない。さらに、ABAPのコードは多くが企業のSAPシステム内部に閉じており、外部に公開されることが少ない。AIの学習データとして、果たして十分な量があるのか、疑問だった。

ABAPは「マイナー言語」：AIに食わせるデータ量は足りているか

もう一つ懸念したのは、ABAP特有の癖である。ABAPはデータ型もテーブル定義も、SAPシステム内部の情報に依存する。さらに、内部テーブル、Dynproといった、他言語にはない概念が山ほどある。これらをAIが正しく扱えるとは、正直なところ思っていなかった。

しかも、今回挑戦するOData呼び出しは、ABAPの中でも比較的新しい領域である。学習データが豊富にあるとも考えにくい。

「まあ、雛形くらいは出してくれるだろう。あとは人間が直せばいい⋯」

そんな気持ちで、筆者はChatGPTにプロンプトを投げ始めた。

ChatGPT に実際にABAPを書かせた手順

ここからは、実際の手順を具体的に紹介する。今回筆者が使ったAIモデルは、ChatGPT 5.5である。最新世代の生成AIに、ABAPプログラムを書かせた実録だ。

先に一点、お断りしておく。本記事では分かりやすい例として「OData経由の購買発注登録」を題材に取り上げているが、実際に筆者の現場で必要だった業務要件、そしてそれに対応するOData APIは、これとはまったく別のものである。

本来、購買発注の登録だけが目的なら、ABAP + BAPI_PO_CREATE1で事足りる話だ。だが、業務要件によってOData APIが個別に異なっていても、本記事で紹介するアプローチ――「Excelマクロを仕様書代わりに渡し、AIにABAPへコンバートさせる」――は、すべてのABAP + ODataの組み合わせに通用するはずである。だからこそ、入門記事として広く読んでもらいたい価値があると考えた。

インプットは「Excelマクロ + シート」つまり仕様書の代用

今回のトライアルでは、まったくのゼロからABAPを書かせたわけではない。筆者は事前に、別のアプローチで試したことがあった。それが、以下の過去記事で紹介した、Excelマクロを使ったOData経由の購買発注登録である。

この記事で作成したExcelマクロとシートを、そのままChatGPTへのインプットとして渡したのだ。これは、いわば「仕様書の代用」である。Excelマクロには、OData呼び出しのエンドポイント、認証方法、Jsonボディの構造、レスポンスのパース処理――　購買発注登録に必要なすべてのロジックが、VBAというコードの形で凝縮されていた。

実際にChatGPTに投げた最初のプロンプト

筆者がChatGPT 5.5に最初に投げたプロンプト（AIへの指示文）を、ありのまま公開する。前回の記事で作成したExcelワークシートとVBAコードを添付ファイルとして渡しつつ、本文には以下の指示文を入れた。

このOData V4をコールして購買発注を登録するExcelマクロをABAPにコンバージョンしてください。
ワークシート「Main」に入力しているデータは、GUIの画面から入力できるようにしてください。
入力画面は購買ヘッダと購買明細に分け、ヘッダはテキストボックス形式で、明細はALVグリッド形式で入力できるようにしてください。

たったこれだけである。

• 「Excelマクロの実コードがこちらに提示されていない」は、この時点でExcelファイル内にあるVBAコードを読み取れていないためである。この後、別途テキストファイルでVBAコードをChatGPTに送っている。

「Excelマクロ + ワークシート」という参照資料をAIに食わせたうえで、「ABAPにコンバートしてくれ」「入力画面のヘッダはテキストボックスで、明細はALVグリッドで」――
この程度の指示で、AIはきちんと動くプログラムを書き上げてきた。

ここで、重要なTipsを共有しておきたい。生成AIにABAPを書かせる際、「VBAから移植してくれ」という指示は極めて強力である。なぜなら、VBAコードには「何をしたいか」が手続き的にすべて書かれており、AIはその意図を読み取ることで、ABAP特有の構文に翻訳しやすくなるからだ。

自然言語だけで仕様を伝えるよりも、既存のコードを「リファレンス」として渡すほうが、AIの精度は格段に上がる。これは、JavaからPythonへの移植や、VB.NETからC#への変換でも、同じ原則が成り立つ。
AI時代の仕様書は、自然言語よりもコードのほうが伝わりやすいのかもしれない。

SE38にコピペして、あとはひたすらデバッグ

ChatGPTから出力されたABAPコードは、まずT-CD: SE38（ABAPエディタ）を立ち上げ、新規プログラムとして貼り付けた。

これだけである。「チェック」すると文法的なエラーは数件出たが、AIにスクショを貼って伝えれば、すぐに修正案を出してくれた。

文法的に完成したコードを、まず「有効化」する。あとは、実機で動かしながらデバッグを進める。
これだけのシンプルな流れだ。

「コードを書く」という工程が、いつの間にか「コードをコピペしてデバッグする」工程に置き換わっている。
これは、もはやSAP開発の従来の常識を覆す変化である。

スクリーンペインタは人間の手で：人機協創の境界線

ただし、すべてがAIだけで完結したわけではない。今回のアドオンには、SE38で書くABAPコードのほかに、スクリーンペインタを使った画面デザインの部分があった。これは、ABAPコードではなく、GUI上での設定作業である。
SE80より「スクリーンペインタ」を呼び出し、ドラッグ&ドロップしたり、項目を選択したり、属性を設定したりする必要がある。

当然、ここはAIに「やらせる」ことはできない。AIはコードは書けるが、GUIを操作することはできないからだ。

筆者はスクリーンペインタを使った経験もなかったので、AIに頼んで「スクリーンペインタでこういう操作・設定をしてください」という手順の指示を受け取り、それを基に自分の手でSAP GUIを操作して設定を進めた。

操作が分からなければ、都度「これでいい？」「こんな感じ？」と、スクショを貼り付け、対話をしながら作業を進めていく。

この「コードそのものではなく、人間が手を動かさなければならない部分」こそ、現時点でのAIの限界であり、同時に「人機協創」の境界線である。AIは指示を出す、人間がそれに従って手を動かす――　これは、まるで上司と部下の関係が逆転したような構図でもある。だが、これが現実のAI時代の働き方なのだ。

専門家向けに補足しておくと、SAPの世界では今後、Joule（SAPの生成AIアシスタント）やSAP Build Code、ABAP Cloudなどの進化により、GUI操作を含む業務作業もAIが代行できる範囲が広がっていくと予想される。しかし、現時点（2026年5月時点）では、スクリーンペインタなどの「クラシックなGUI設定作業」は、依然として人間の手仕事である。ただし、この境界線は、今後数年で大きく動くだろう。

OData認証部分はやはりハマった：AIと二人三脚のデバッグ

結果から言えば、AIが出力したABAPコードのうち、OData呼び出しのメインロジック、すなわち、HTTPクライアントの生成、リクエストの組み立て、JSONボディの作成、レスポンスのパース―― これらは、デバッグも必要ないほど完璧だった。一発で動いた、と言ってもいい。

しかし、唯一ハマった部分がある。それはOData APIのWeb認証だった。これは以前の記事でも詳しく解説している通り、ABAPからのOData呼び出しにおける「最大の難所」である。

CSRFトークンの取得、Basic認証のヘッダー組み立て、セッション維持のためのクッキー管理――
このあたりは、VBAでサンプルを渡していたものの、ABAPではほぼ参考にならないらしい。SAP側の実行環境によって挙動が変わるため、机上の理論だけではどうにもならない。実際に動かしてみて、エラーを見て、調整する。それの繰り返しになる。

ここで筆者が取ったアプローチは、「AIとの二人三脚デバッグ」だった。
エラーが出るたびに、エラーメッセージ、HTTPレスポンスコード、レスポンスボディの内容を、テキストまたはスクショで、そのままChatGPTに貼り付ける。
すると、AIは「〇〇の取得が正しくできていないようだ。デバッガに〇〇を追加して・・・」といった具合に、的確な改善案を提示してくる。それを反映し、また実行する。エラーが出たら、また貼り付ける。

このサイクルを数回繰り返したところで、認証は通った。
完璧に動作するABAPプログラムが、筆者の手元に完成したのである。

所要時間は、デバッグ込みで半日もかからなかった。

デバッグ過程で見えた、5つの「ハマりポイント」

完成したABAPコード（便利ツールと資料にて公開中）の冒頭には、ChatGPTが「ハマりポイント」として整理した5項目のコメントブロックが残されている。実際のコメントから、要旨を抜粋して紹介しよう。

これらはAIが筆者との共同デバッグを通して経験した、「ハマりポイント」として整理してくれたものだ。
「コードを保守する人のために」と、コードの冒頭にコメントを追記してくれているのである。ベテランの先輩エンジニアが、引き継ぎの際に書き残してくれるメモのようなものだ。

そう、AIは可読性の高い、丁寧で分かりやすいコメントもふんだんに入れてくれる。これは、人間のプログラマがしばしば手を抜きがちな部分である。

納期に追われると、コードは書いてもコメントは書かない。あるいは、書いてもコードと乖離した古い内容のまま残る。AIにはそうしたサボりがない。常に最新のロジックに対応した、丁寧なコメントを生成する。これだけでも、コードの保守性という観点で、AIは並のプログラマを上回っていると言える。

結果、ABAPプログラムは完璧に動いた

では、AIが書き上げたABAPプログラムは、最終的にどうなったのか。結論を一言で言えば、「完璧に動いた」である。ただし、その「完璧」という言葉の重みを、もう少し丁寧に解説しておきたい。

OData呼び出しロジックはデバッグ不要レベル

まず、OData APIを呼び出すコア部分のコードは、生成された瞬間から、ほぼノーミスだった。CL_HTTP_CLIENTのインスタンス化、URLの組み立て、リクエストメソッド(POST)の設定、Content-Typeヘッダーの追加、JSON形式のリクエストボディの作成、レスポンスの受け取りとパース―― これらすべてが、ABAPの作法に則った正しいコードとして出力された。

変数の命名規約も、ハンガリアン記法(lt_, ls_, lv_)に則ったものだった。コメントも適切に挿入されており、しかも読みやすい。レビューする側からすれば、「これ、本当にAIが書いたのか」と疑いたくなる出来栄えだった。

筆者はABAPコーディング未経験。それでも作れてしまった事実

ここで、もう一つ衝撃の事実を告白しなければならない。筆者自身は、ABAPプログラムを一からまともに書いた経験が、ほとんどない。SE38の起動の仕方は知っているし、コードを読むことはできる。しかし、自分の手でABAPプログラムをイチから書いてリリースした経験は、正直に言ってほぼゼロに等しい。筆者の本業はSAPのモジュールコンサルタントであり、PMO業務やモジュールコーディネーションが中心だからだ。

つまり、ABAPコーディングについては、ほとんど未経験者に等しい筆者が、AIを使って、Dynproの入力画面、ALVグリッドの明細入力、OData認証、購買発注のPOST送信まで含めた本格的なABAPレポートプログラムを、半日で完成させてしまったのである。これがどれほどの衝撃か、SAP業界の人間ならわかってもらえるはずだ。

仕様を伝えられる人間さえいれば、AIはABAPプログラムを作れる

これが、今回のトライアルから導き出された、最も重要な結論である。コードを自分で書く能力は、必ずしも必要ではない。AIに正しく指示を与え、出てきたコードをレビューし、エラーを見て改善を促す――
これだけで、本番品質のABAPコードが手に入る時代に、すでに我々はいるのだ。

ABAPプログラマはもう不要なのか?

さて、ここからが本記事の核心、そして読者諸氏に問いたかった本題である。今回のトライアル結果を踏まえて、筆者は声を大にして問いたい。ABAPプログラマは、もう不要なのではないか? ――
この問いを、業界の現実として受け止めるべき時が、いよいよ来ているのではないか。

消えるのは「仕様書を読んで書くだけ」のコーダー

誤解のないように言っておくと、筆者は「すべてのABAPプログラマが不要になる」と主張しているわけではない。消えるのは、特定のタイプのプログラマである。それは、「仕様書を渡されて、その通りにコードを書くだけ」のコーダーだ。

この手のコーダーは、これまでSAP業界に大量に存在してきた。プロジェクトの開発フェーズでは、設計者が仕様書を書き、コーダーがそれをコードに落とし込む――　この分業体制が、長らく業界の標準だった。だが、よく考えてみてほしい。「仕様書をコードに翻訳する」という作業は、まさに今、AIが最も得意とする領域なのだ。

仕様書がきちんと書かれていれば、AIはそれを読み取り、ABAPコードとして出力する。これは、もはや実証された事実である。筆者の体験は、特殊な事例ではない。条件さえ整えば、誰でも、いつでも、同じ結果を得られる。そして、AIによる出力は、24時間365日、文句一つ言わず、疲れも見せず、機嫌も損ねず、淡々と作業を続ける。
「ただコードを書くだけのプログラマ」は、コスト構造的にも、品質的にも、AIに勝てる要素を見つけるのが難しい。

慎重さは美徳。しかし、そこに留まり続けるABAPerに未来はない

さらに踏み込んで言えば、消えるのは「仕様書を見て書くだけ」のコーダーに加えて、「新技術を学ぼうとしないABAPer」である。誤解しないでほしい。本記事の前半でも述べた通り、前例のない技術に対してABAPerが慎重な態度をとるのは、職人としてまったく正しい反応だ。技術的な実績や知見が乏しい領域に、安易に飛び込まないのは、品質と納期を預かるエンジニアとしての矜持でもある。

問題はその先である。慎重に評価したうえで「これは現場で必要だ」と判断したならば、一歩踏み出さなければならない。にもかかわらず、慎重さを口実に未知の領域への学習そのものを避け、自分の知っているBAPIと汎用モジュールの世界だけで仕事を続けようとする―― この姿勢に留まるABAPerは、遠からず行き場を失う。

なぜなら、SAP業界の技術地図は、すでに大きく動いているからだ。S/4HANA、ABAP Cloud、Fiori、OData、CAP、RAP、Joule―― 新しいキーワードが次々と登場し、SAPは「クラシック」から「モダン」へと急速に変貌しつつある。BAPIとSE38だけで完結する時代は、確実に終わりに向かっている。そして、新技術を躊躇なく学習し、文句一つ言わずに正確無比なコードを書くAIという「超優秀な競合」が、すでに目の前に現れている。AIは慎重さを必要としない。事例がなくても、淡々と書く。これが現実だ。

AIは「不安も文句も言わない、超優秀な新人」

今回のトライアルで筆者が最も感銘を受けたのは、AIの「態度」だった。
考えてみてほしい。人間のABAPプログラマに、未知の領域である「OData呼び出し」を依頼すれば、たいていは尻込みする。「やったことがない」「調べる時間が欲しい」「他の人にやらせたほうがいい」「リスクが大きい」―― こうした反応が返ってくるのが、現実だ。

だが、AIは違った。OData APIという、ABAPerにとって未知の領域であっても、AIは不安を見せず、文句も言わず、淡々とコードを書き上げた。エラーを貼り付ければ、嫌な顔ひとつせず、的確な改善案を返してくる。深夜に質問しても、休日に依頼しても、いつでも同じクオリティで応答する。これは、もはや「技術力はベテラン、態度は超優秀な新人」と言って差し支えないレベルである。

しかも、この「新人」は、給料を要求しない。残業手当もいらない。離職もしない。教育コストもほぼゼロ。SAP業界が長年抱えてきた「プログラマの人材不足」という構造問題に対して、AIは強力な解決策になり得る存在なのだ。経営者の立場から見れば、これは見逃せない大きな機会である。

ここで、もう一つ重要な事実を伝えておきたい。今回のトライアルで使ったAIは、汎用の生成AIであるChatGPT 5.5だ。ABAP専用にチューニングされたモデルではない。それでも、この精度である。今後、SAPが提供するJouleや、ABAP専用の開発支援AIが本格化すれば、その精度はさらに上がるだろう。

「仕様を伝える者がいれば、人間のABAPプログラマは必ずしも必要ではない」

この命題は、年を追うごとに、より確かなものになっていく。

価値あるABAPプログラマとして生き残るために

では、ABAPプログラマ／エンジニアとしてキャリアを歩んできた我々は、これから何をすべきなのか。

「不要になる」と煽るだけでは、何も生まれない。本記事の真の目的は、危機感を共有し、「価値あるプログラマとして生き残るためのヒント」を提示することにある。

求められるのは「仕様を語れる人」と「AIを使いこなす人」

AI時代に価値を発揮できるプログラマは、大きく二つのタイプに分かれる。一つは「仕様を語れる人」、もう一つは「AIを使いこなす人」だ。両方を兼ね備えていれば、なお強い。

仕様を語れる人

「仕様を語れる人」とは、業務要件を深く理解し、それをコードに落とし込むレベルまで具体的に表現できる人材である。ユーザー部門にヒアリングし、業務プロセスを整理し、システムでどう実現するかを設計する―― この能力は、AIには代替できない。なぜなら、AIは「目の前の要件をコードに翻訳する」ことはできても、「曖昧な業務課題から要件そのものを引き出す」ことはできないからだ。

AIを使いこなす人

「AIを使いこなす人」とは、生成AIに対して的確な指示を出し、出てきたアウトプットを評価し、必要に応じて改善を促せる人材である。プロンプトエンジニアリングと呼ばれる領域だが、本質はもっとシンプルで、次の二つに尽きる。

ABAPerが今日から始めるべき2つのアクション

具体的に、ABAPプログラマが今日から始めるべきアクションを、二つ提案したい。これは、筆者がITおよびSAP業界に身を置いてきた立場から、本気で推奨する内容である。

アクション1: 生成AIを「生成AI」として活用する習慣をつける

筆者の観察では、SAP関係者のうち、生成AIを日常的に使っている人の割合は驚くほど少ない。さらに、使っている人の中でも、利用が「検索」に留まるケースが大半である。「ChatGPTやGeminiで〇〇について調べてみた」という使い方は、生成AIの本領を発揮していない。Google検索の上位互換くらいの位置づけになってしまっている。

本来、生成AIは「生成」のためのツールである。コードを書く、文書を書く、設計を考える、レビューしてもらう、議論する・・・ こうした「人間の知的生産活動を代替・拡張する」使い方をしてこそ、その真価が発揮される。

これを身につけるには、実際に使ってみるのが一番だ。本を読んでも、セミナーを聞いても、自分で手を動かさなければ絶対に身につかない。

今日から、業務の一部を必ずAIに任せてみてほしい。仕様書のドラフト、メールの下書き、コードのレビュー、何でもいい。毎日、何かしらをAIに任せる。これを習慣化することが、第一歩である。

アクション2: マネジメントスキルを身につける

これは少し意外に思われるかもしれないが、筆者は強く推したい。AIが「超優秀な新人」だとすれば、その新人を上手く使う術を身につける必要がある。それはもう、マネジメントのスキルにほかならない。

具体的には、「適切なゴール設定をする力」「タスクを分解して指示する力」「アウトプットをレビューしてフィードバックする力」「複数のAIや人間を組み合わせて成果を出す力」――　これらは、いずれも人間のチームを率いるマネージャーに求められるスキルと同じである。

コードを書くだけの時代から、AIを使って成果を出す時代へ。求められるのは、より上位の「人（やAI）を動かすスキル」へとシフトしていく。

これまで「自分は技術者だから、マネジメントは興味ない」と言ってきたABAPプログラマ／エンジニアこそ、この変化を真剣に受け止めるべきだ。AIをマネジメントできる技術者は、これからの時代に圧倒的な価値を持つ。
コードを書く能力は、もはや差別化要因ではない。AIを動かす能力こそが、価値の源泉になる。

まとめ：AIにABAPを書かせて見えた、これからのSAP開発

ChatGPT にABAPプログラムを書かせるという、たった一度のトライアルから見えてきたのは、SAP開発の未来像そのものだった。AIは、ABAPというマイナー言語に対しても、OData APIという最先端領域に対しても、不安や文句を一切見せず、完璧に近いコードを書き上げた。ABAPコーディング未経験の筆者でさえ、Excelマクロを仕様書代わりに渡し、わずか数行のプロンプトを投げるだけで、本番品質のプログラムを半日で完成させることができた。

本記事では分かりやすい例として購買発注登録を題材にしたが、このアプローチ――「既存のロジック（VBAでもSQLでもよい）を仕様書代わりに渡し、AIにABAPへコンバートさせる」――　は、API_PURCHASEORDER_2 に限らず、ありとあらゆる OData API に通用するはずだ。販売伝票、在庫移動、生産指図、会計仕訳・・・SAP S/4HANAが提供する OData API は膨大にあり、そのいずれも、本記事の手順を応用すれば、ABAPから呼び出すアドオンを作ることができる。

この事実は、SAP業界、特にABAPプログラマにとって、重く受け止めるべきものである。「仕様書を読んで書くだけ」のコーダー、そして「新技術を学ぼうとしないABAPer」は、AIという超優秀な競合の登場によって、いよいよ存在価値を問われる時代に入った。これはもう、「いつか来る話」ではない。今、目の前で起きている現実である。

だが、悲観する必要はない。価値あるプログラマとして生き残る道は、確実に存在する。それは、「仕様を語れる人」「AIを使いこなす人」になることだ。そのために、今日から始められる二つのアクション、生成AIを生成AIとして使う習慣をつけること、そしてAIをマネジメントするスキルを磨くこと――
これらを愚直に実践してほしい。

「ABAP AI」「ABAP ChatGPT」というキーワードで検索してこの記事にたどり着いた読者諸氏には、ぜひ一度、自分の手でAIにABAPを書かせてみてほしい。Excelマクロでも、JavaのコードでもCOBOLのコードでも構わない。コードを持ち合わせていなければ、何か既存のロジックを渡し、「これと同じ処理をABAPで書いて」と頼んでみる。
そして出てきたコードを、自分の目で確かめてほしい。そこに広がるのは、おそらくあなたが想像している以上の世界である。

「ただコードを書くだけのプログラマ」は、間違いなくお払い箱になる。それは脅しでも煽りでもなく、現場でAIにABAPを書かせた筆者の、偽らざる実感である。

だが、AIを上手く使いこなし、業務とテクノロジーの架け橋になれるABAPプログラマには、これまで以上に大きな活躍の舞台が待っている。SAP × AIの時代に、価値あるプログラマとしてどう生き残るか――
この問いに、一人ひとりが向き合うときが、今、来ている。

本記事が、その一歩を踏み出すきっかけになれば、筆者にとってこれ以上の喜びはない。

---

本記事で紹介したABAPプログラムの完全なソースコードは、「便利ツールと資料」で公開している。AIが書いた、OData API を利用する約1,250行のリアルなABAPコードを、ぜひ自分の目で確かめてほしい。