生成AIが登場してから、「AIを使えば何でも自動化できる」という期待が一気に広がっている。SAPの現場も例外ではない。その一方で、「SAPは特殊だし機密も多いから、AIなんて使えない」という慎重な声も根強い。だが実際に仕事で使ってみると、どちらも言い過ぎだと分かる。SAPプロジェクトでAIを使うときには、「できること」と「できないこと」のはっきりした「境目」があるのだ。
生成AIを使ったことのある人なら、この境目をなんとなく肌で感じているはずだ。でも、それをきちんと整理した資料は、筆者の知る限りあまり見かけない。みんな感覚では分かっているのに、言葉にした地図がない。これは少し不自由だ。
そこで本記事では、SAPの仕事における生成AIの「できること」「できないこと」を、それぞれ7つずつ整理する。
ただ並べるのではなく、なぜできるのか・なぜできないのかを、現場の「あるある」を交えながら説明していく。
SAPとAIの話に初めて触れる人にも分かりやすく、現役のコンサルタントやエンジニアにも役立つコツを盛り込んだつもりだ。
先に結論を言ってしまおう。AIは「やり方がはっきり決まっている作業」がとても得意だ。逆に、「人が考えて決める作業」や「一度やったら取り消せない、責任の重い作業」は苦手である。
AIは便利だが、何でもできる魔法ではない。使う場所を間違えると、プロジェクトは失敗しかねない。だからこそ、得意・不得意を見極めたうえで使い、仕事の効率を最大限に高めていきたい。
なぜ今「SAP × AI」のできること・できないことを整理するのか
SAPでのAI活用が話題になるほど、現場は二つの極端な考えに振り回されやすい。整理を始める前に、まずこの二つの落とし穴を見ておきたい。どちらも、放っておくとプロジェクトの足を引っ張る考え方だ。
どちらも危ない
「AIは何でもできる」は危ない
一つ目の落とし穴は「AIは何でもできる」という思い込みだ。
設計も判断も全部AIに任せられる、と考えてしまうパターンである。これを真に受けると、お金をかけすぎたり、間違った判断をしたりして、プロジェクトは燃え上がる。AIに任せてはいけないところまで任せた結果、あとの工程で大きなやり直しが発生する。
これは、すでに現場で見られる典型的な失敗だ。AIがスラスラ出した答えを誰も確かめず、本番直前になって「実は業務に合っていなかった」と気づく――そんな事態は、決して大げさな話ではない。
「AIはまだ使わなくていい」も危ない
二つ目の落とし穴は、その反対の「AIはまだ使わなくていい」という考えだ。
SAPは特殊だからAIなんか使えない、AIは信用できない―― そう言って後回しにしていると、効率の面で確実に置いていかれる。すでにABAPのコーディングやBAPI調査では、AIを使うチームと使わないチームの差が広がる一方だ。
同じ時間でも、一方は大事な設計に頭を使い、もう一方は調べ物に追われている。この差は、プロジェクトが進むほど大きくなっていく。
正解はその真ん中にある。できること・できないことを見極めて、任せられるところはどんどんAIに任せ、人がやるべきところは人がやる。この線引きこそが、これからのSAPの仕事を効率化するうえで一番大事なポイントだ。
この記事の地図 ― SAP Activate の段階で考える
できること・できないことを考えるとき、ばらばらに並べても分かりにくい。そこでこの記事では、SAP導入の標準的な進め方である「SAP Activate」を地図として使う。
SAP Activateは次の6つの段階でできている。SAP S/4HANA導入のいわば定番の流れで、どの段階で何をやるかが決まっている。
- Discover（構想）
- Prepare（準備）
- Explore（要件のすり合わせ）
- Realize（構築）
- Deploy（本番展開）
- Run（運用）
この段階ごとに、AIの「できる」「できない」を当てはめていくと、整理がしやすい。
大きな傾向として、上流の構想や判断ほど人間の出番が多く、下流の決まった作業ほどAIが活きる、ということも見えてくる。
まずは全体像を表でつかんでおこう。一つひとつの詳しい話は、このあと順番に説明していく。
- ABAPコーディング
- BAPI・RFCの検索と調査
- トランザクションが使うテーブルの特定
- SAP用語の調査・用語集づくり
- トランザクションコードの調査
- MRP計算のシミュレーション
- 要件定義のヒヤリングシート作成
- 要件定義（言葉にならない要望のくみ取り）
- 標準で進めるか作り込むかの判断
- 移行データの作成（古い項目の対応づけ）
- SAP GUIを操作する実機テスト
- 本番への切り替え（カットオーバー）の判断と作業
- 障害の原因の切り分けと対応の判断
- カスタマイジング（設定値）の決定
SAPの仕事で生成AIにできること7選
まずは「できること」から見ていこう。
ここで挙げる7つは、筆者が実際に試して、効果を体感してきたものばかりだ。それぞれ詳しい検証記事も当ブログで公開しているので、もっと知りたい人はリンク先も読んでみてほしい。
共通点は、どれも「答えが資料や仕様として存在する」調べ物・文章づくりの作業という点である。
1. ABAPコーディング ― ほぼ完璧
できることの筆頭は、なんといってもABAPのコーディングだ。仕様を渡せば、内部テーブルの処理もBAPIの呼び出しも、動くコードをすらすらと書いてくる。筆者の感覚では「ほぼ完璧」と言っていいレベルだ。SELECT文の組み立てや、Loop処理といった、決まった形の実装ほど力を発揮する。
少し慣れた人向けのコツを挙げると、命名のルールやコメントの方針、エラー処理のやり方、さらには社内のコーディング標準まで一緒に伝えると、あとで直しやすいきれいなコードが返ってくる。
逆に丸投げすると「動くけれど読みにくい」コードになりがちなので、最後の確認は欠かせない。「ABAPプログラマはもう要らないのか?」という問いは、もう笑い話ではなくなっている。
2. BAPI・RFCの検索と調査
「この処理を実現するBAPIはどれだろう?」―― SE37を探し回って、それらしい名前を片っ端から叩いていく。あの時間のかかる作業を、AIはすっぱり減らしてくれる。
やりたい業務処理を伝えれば、使えそうな汎用モジュール／BAPIの候補を出してくれるのだ。
たとえば「入出庫を登録したい」と言えば、BAPI_GOODSMVT_CREATEのような定番がすぐに出てくる。
注意したいのは、AIが挙げたBAPIが本当に要件に合うかどうかは、必ず実機や資料で確かめること。候補を「絞り込む」ところでこそ、AIは役に立つ。
3. トランザクションが使うテーブルの特定
「このトランザクションは、どのテーブルを更新しているのか?」という調べ物も、AIの得意分野だ。よく使うトランザクションがアクセスするテーブルの当たりを、すぐにつけてくれる。MM・SD・FI・PPといった主要なモジュールの定番テーブルなら、精度はかなり高い。
コツとしては、ST05のSQLトレースや、画面項目の技術情報（F1ヘルプ）と合わせて確かめると、精度も安心感も一段上がる。AIで当たりをつけて、実機で裏を取る。この二段構えが、調査の時間を大きく短くする勝ちパターンだ。
4. SAP用語の調査・用語集づくり
SAPは独特の用語の宝庫だ。「移動タイプ」「評価クラス」「勘定設定」―― SAPに不慣れな顧客は、まずこの言葉の壁にぶつかる。チームが早く立ち上がるうえで、用語集は地味だが強力な武器になる。AIに頼めば、プロジェクトに合わせた用語集のたたき台を、短い時間で作ってくれる。
特定の人しか分からない「言葉の壁」を下げる効果は大きく、新人向けの資料としても使い回せる。できあがった用語集に自社ならではの補足を足していけば、立派なナレッジ資産になる。
5. トランザクションコード（T-CD）の調査
似たようなトランザクションコードの違いを知りたい、目的の機能を持つコードを探したい。こうした調べ物もAIで速くなる。ME21NとME21は何が違うのか、「あのとき使った、あれをやるための画面はなんだったろう？」―― こうしたアバウトな質問にも、AIはすぐに答えを返してくれる。
たくさんあるトランザクションコードの中から、目当ての一つを見つける手間が大きく減るのだ。
6. SAP実機動作のシミュレーション
生産計画の分野でも、AIは頼りになる。計画戦略グループやMRPの動きを、実機を回す前に試しに整理させることができる。「この計画方針グループだと、独立所要量と従属所要量はどうつながるのか」「この設定で、計画手配はいつ生成されるのか」をAIと一緒に考えることで、設計の見通しが立てやすくなる。
もちろん、最終的に正しいかどうかは実機での確認が必要だが、設計の初めの段階で頭を整理するには十分に役立つ。
7. 要件定義のヒヤリングシート作成
7つ目は少し毛色が違う。要件定義「そのもの」はAIにはできない（あとで説明する）。でも、要件定義で使う「ヒヤリングシート」、つまり何を聞くべきかという質問リストは、AIが優秀なたたき台を作ってくれる。聞き漏らしを防ぐチェックリストとして、十分に使えるレベルだ。
「在庫管理の要件を聞くなら、どんな観点を押さえるべき?」とたずねれば、評価方法、ロット管理、引当ルールといった論点が並んだ質問リストが返ってくる。ここが、次に話す「できないこと」へのちょうどよい前振りになっている。
質問はAIで作れる。でも、その質問を投げて本音を引き出すのは―― という話だ。
SAPの仕事でAIにできないこと7選
便利なAIにも、任せると危ないところがはっきりとある。SAP Activateの段階を、上流から下流へたどりながら、AIにできないこと7つを見ていこう。読み進めるほど「そうだよな」とうなずけるはずだ。そして、その「そうだよな」の正体は、この章のあとできちんと言葉にする。
1. 要件定義 ― 言葉にならない要望のくみ取り（Explore）
できないことの筆頭は、要件定義だ。さっき「ヒヤリングシートはAIが作れる」と言ったが、そのシートを手にお客さんと話し、本音を引き出す作業はまったくの別物である。「今まで通りでいい」「いい感じにやってほしい」――現場から出てくるのは、こういうはっきり言葉になっていない要望ばかりだ。
たとえば、こちらが「どのようなシステムをお望みですか?」とたずねると、返ってくる答えは「安くて使いやすいものを」だったりする。これだけでは、要求仕様には何ひとつ落とし込めない。ここから深掘りしていくわけだが、顧客の業種・業界、そして現場の空気感から、本当に必要なニーズを嗅ぎ取り、要求仕様という形にまとめていく――
この作業は、いくつもの現場を渡り歩き、経験を重ねてきた人間ならではのものだ。
担当者本人すら気づいていない暗黙のルール、部署をまたいだ力関係、何年も前に決まった事情。これらを会話の中からくみ取り、ときに食い違う要望を調整し、システムの設計に落とし込むのが要件定義だ。表情や声色から「この人は本当はこう思っている」と察する。会議で言えなかった本音を、休憩時間の雑談で引き出す。
さらに、「その業務、本当に必要ですか？」と、根本的な質問を投げかけて気付きを与え、業務そのものを改善することだってある。
こうしたことは、AIには手が届かない。AIは「聞くべき質問」は作れても、「相手が口にしていない本心」をその場の空気から読み取ることはできないのだ。ここは人間のコンサルタントの一番の見せ場である。
2. 標準かアドオンかの判断（Explore）
Exploreの段階で一番大事なのが、標準機能だけで業務を回すのか、それとも追加開発（アドオン）で作り込むのか、という判断だ。SAPではこれをFit-to-Standardやフィットギャップ分析と呼ぶ。この判断はAIにはできない。
AIは「標準で実現するやり方」と「追加開発するやり方」、そして一般的な良い点・悪い点なら整理できる。
でも、最後に「どちらを選ぶか」は、開発のお金、保守の手間、将来のバージョンアップへの強さ、現場の使いやすさ、さらには経営陣の意向まで、すべてを天秤にかけて決める仕事だ。
標準に業務を合わせるのか、業務に合わせてシステムを曲げるのか。この決断は、その会社の文化や戦略そのものに踏み込む。リスクと責任を背負って「これでいく」と腹をくくる行為は、人間にしかできない。
3. カスタマイジング（パラメータ設定値）の決定（Realize）
IMGでのパラメータ設定は、できそうでできない。
評価クラス、移動タイプ、いろいろな管理パラメータ、出力の条件―― 「その設定が何を意味するのか」「〇〇の設定を変更したい場合、どのIMGノードを開くのか」なら、AIは丁寧に説明できる（情報不足や間違えることも多いが）。
でも、「この会社では具体的にどの値を設定すべきか」は、その会社の業務の実態やこれまでの決まり事に根ざした判断であり、AIには決められない。
同じ「評価クラス」でも、会社の会計方針や品目の体系によって、ベストな答えは変わるからだ。
ただし、この分野は、Jouleが進化するなど近い将来に景色が変わるかもしれない。
今は人間の判断が欠かせないが、AIが社内の業務資料や過去の設定内容、これまでの決定の記録まで読めるようになれば、設定値を提案する精度はぐっと上がるだろう。そのとき人間の役割は、ゼロから値を決めることから、「AIの提案を吟味して、最後にOKを出すこと」へと変わっているはずだ。
あくまで「今はまだ」人間の判断が必要、というのが正確な現在地である。
4. 移行データの作成 ― 古い項目の対応づけ（Realize）
データ移行は、AIの得意・不得意がくっきり分かれる分野だ。データの整形や形式の変換なら、AIは強い味方になる。問題は、その手前にある「どの項目をどこに移すか」という対応づけ（マッピング）である。
あるあるを挙げよう。古いシステム（移行元）の項目の意味が、もう誰にも分からない。「このフラグは何を表しているのか？」を知っている人が、すでに辞めている。コードの体系はその場しのぎで増えていき、説明書も残っていない。
こういう状態だと、移行元の情報がそもそも足りていないので、新システムへの対応づけは、人間が業務知識と過去の事情で一つひとつ埋めていくしかない。
ここがポイントだ。AIは、与えられた情報を変換することはできても、足りない情報そのものを生み出すことはできない。「この曖昧なコードは、業務の上でどの分類に寄せるべきか」という判断は、現場を知る人間の仕事である。そして移行のあとに「このデータは業務として正しいのか」を最後に確かめるのも、もちろん人間の役目だ。
5. SAP GUIを操作する実機テスト（Realize / Deploy）
画面を切り替え、値を入力し、結果を目で確かめる。SAP GUIを実際に操作するテストは、今のところAIには任せられない。AIがPC画面を操作する技術は進んできてはいるが、複雑なSAP GUIを安定して操作し、思わぬポップアップやエラーにもきちんと対応できる、というレベルにはまだ届いていないのが正直なところだ。
ただし誤解しないでほしい。テストケースの設計や、テストの観点の洗い出し、テストデータの準備なら、AIは大いに役立つ（これは「できること」側だ）。「この機能のテスト観点を挙げて」と頼めば、正常なケースも異常なケースも、ぎりぎりの値のケースまで網羅したたたき台が出てくる。あくまで「実機を操作すること自体」が、今は人間の担当という線引きである。
これはテストに限った話ではない。以下の記事でも述べいるが、たとえばスクリーンペインタ（SE51）で画面を作り込むような、SAP GUI上での操作も同じだ。コードの中身はAIが書けても、画面を実際に組み立てる操作そのものは、今のところ人間の手で行うことになる。「実機を操作する作業」は、まとめてAIの苦手分野だと押さえておこう。
6. 本番への切り替え（カットオーバー）の判断と作業（Deploy）
新しいシステムを本番に切り替えるカットオーバー。ここはプロジェクト最大の山場で、AIに最後の判断を任せてはいけないところだ。理由ははっきりしている。本番への切り替えは、一度やったら元に戻せないからだ。走り出した移行を、なかったことにはできない。
本番前のリハーサルの結果をどう見るか、進めるか止めるか（Go / No-Go）をどう判断するか、思わぬトラブルが起きたとき引き返すのか突き進むのか。限られた時間の中で、すべての情報がそろわないまま決断を下す。その一つひとつが、会社やお客さんに対する責任を伴う重い判断だ。
AIは判断の材料を整理したり、チェックリストを作ったりは手伝ってくれる。でも、責任を引き受けて引き金を引くのは人間でなければならない。むしろ、AIが整理してくれた材料を前に、人間が腹をくくる―― これが理想の役割分担だろう。
7. 障害の原因の切り分けと対応（全段階に共通）
障害対応も、AIには荷が重い分野だ。「再現しない」「特定のユーザーだけ起きる」「昨日までは動いていた」――SAPの現場でおなじみのこの手の障害は、システムの中のデータやログだけを見ていても、原因にたどり着けないことが多い。
障害を調べるときに本当に大事なのは、ユーザーが実際にどんな操作をしたのか、どんな順番で何を入力したのか、どの権限で何を見ていたのか、という「その場の状況」まで追いかけることだ。ダンプ（ST22）やログだけでは見えない、人の動きが原因の中心だった、ということは珍しくない。
AIはダンプやログを読んだり、エラーメッセージの意味を読み解いたりするのは得意な相棒だが、ばらばらの手がかりを集め、関係者に話を聞き、再現の条件を組み立て、最後に原因を切り分ける――この探偵のような仕事は、人間が現場と向き合ってこそできる。そして、本番システムにどう手を打つかの最後の判断にも、当然ながら責任が伴う。
できる・できないを分ける ―「境界線」の正体
ここまで14個を見てきた。あらためて全体をながめると、できること・できないことの境目には、一本筋の通った理由があると気づく。それは次の3つの問いで説明できる。
この問いを持っておけば、この記事に載っていない作業に出会っても、自分で「これはAIに任せられるかな?」と判断できるようになる。これこそ、この記事で一番持ち帰ってほしい考え方だ。
問い1：その知識は「文書になっているか」
できることは、どれも文書として残っている領域だ。
ABAPの文法、テーブルの定義、BAPIの仕様、トランザクションコードの一覧。資料やマニュアルとしてはっきり書かれているから、それを学んだAIが力を発揮できる。
一方、できないことの多くは、人の頭の中にしかない世界である。言葉にならない要望、現場だけのルール、説明書のない過去の事情、辞めた人の記憶。文書になっていない情報を、AIは扱えない。「ネットで検索しても出てこないこと」は、AIにも出せない、と考えると分かりやすい。
問い2：その作業は「やり直せるか」
AIが出したものは、気に入らなければ捨てて、やり直せる。コードも文章も、何度でも書き直せる。だから安心して任せられる。
ところが、本番への切り替えやデータの登録は、一度やったら元に戻せず、その結果に責任が生まれる作業だ。やり直せず、責任の重い引き金は、人間が引くしかない。これはAIが賢いかどうかの問題というより、「誰が責任を取るか」という問題である。AIがどれだけ賢くなっても、決断の責任をAIに背負わせることはできないのだ。
問い3：判断に必要な情報が「そろっているか」
3つ目が、いちばん実践的な問いだ。移行データの対応づけも、障害の原因の切り分けも、できない理由のおおもとは「情報が足りないこと」にある。
AIは、与えられた情報をすばやく正確に処理するが、足りない情報を魔法のように生み出すことはできない。情報が足りないところに、人間の業務知識という穴埋めが必要になる。
逆に言えば、これは大きなヒントでもある。情報をそろえるしくみを用意できれば、AIが活躍できる範囲は確実に広がる、ということだ。
さっきカスタマイジングのところで触れた「近い将来は変わるかもしれない」という話も、この問いで説明がつく。社内の業務の事情という情報がAIに届くようになれば、できないことの一部は、できることに移っていく。
つまり、できる・できないの境目は固定ではなく、情報がどれだけそろっているかで動いていくのだ。この見方を持てるかどうかが、移り変わりの時期を乗り切るうえで効いてくる。
おまけ：その作業は「実機を操作するものか」
3つの問いに加えて、もう一つ分かりやすい目印がある。それは「実機を操作する作業か」どうかだ。
SAP GUIでのテスト、スクリーンペインタでの画面づくりなど、実際にシステムを手で動かす作業は、まとめて今のAIの苦手分野だと考えてよい。
中身を考えること（コードや観点）は得意でも、画面を操作する行為そのものは、まだ人間の担当――そう覚えておくと、判断に迷ったときの助けになる。
まとめ：SAPのAI活用は「使う場所」の見極めが重要
この記事では、SAPの仕事における生成AIのできること・できないことを、SAP Activateの6つの段階に沿って、それぞれ7つずつ整理した。要約すると、次の3つにまとめられる。
- 「AIは何でもできる」は危ない。でも「AIはまだ使わなくていい」も、同じくらい危ない。極端に偏らず、境目を見極めることが第一歩。
- 今は明らかに移り変わりの時期。だからこそ、AIを恐れずにどんどん使い、現場でやり方のコツをためていくことが大事。できる・できないの境目は、情報がそろうほど動いていくのだから。
- そのうえで、AIの使う場所や効果的な聞き方（プロンプト）を、プロジェクトごとに整理してまとめ、ふだんの作業に組み込む。「AIが得意な一部の人」に頼るのではなく、チームの仕組みへ。これができれば、効率は確実に上がる。
あらためて整理すると、
- できることは「やり方が決まっていて、答えが資料にあって、やり直せる作業」。
- できないことは「人が考えて決める作業や、人の頭の中にしかない知識、やり直せず責任の重い作業」。
- その境目は「情報がどれだけそろっているか」で少しずつ動いていく。
この3つさえ押さえておけば、AIに任せるところは思い切って任せ、人がやるところはしっかり握れる。
SAPでのAI活用は、難しい技術論ではなく「使う場所」の見極めが重要だ。その見極めこそが、これからのSAPプロジェクトでAIを味方につける勝ち筋であり、SAPの仕事を効率化する本質だと、筆者は考えている。
次回は、もっと上流の「意思決定に直結するAI活用」という切り口でも掘り下げてみたい。
コメント