SAPの権限テストをAIで自動化｜Claude Codeと二人三脚でアプリ開発

「SAPの権限ロールを、まとめて、自動的にテストできないか？」

このお題を前に、以前の私なら腕組みして唸ったあげく、最後は諦めていたはずだ。

ところが今回、私はこのアプリを実働およそ4時間で完成させてしまった。しかも一人ではない。2つのAIとコラボしての成果である。

本記事は、SAPの権限テストを自動化するアプリを、AIとの協働でゼロから作り上げた過程の記録である。

ここで最初に強調しておきたいのは、今回の開発が「1人の人間と、2つのAIによる、三者のコラボレーション」だったという点だ。

実装を担うAIと、作戦を練るAI。役割の違う二つのAIを、人間である私がハブとなってつないでいく。この体制が、環境構築の躓きから沼のデバッグまでを一気に突き進め、一ヶ月かかってもおかしくない仕事を半日で終わらせた。

その全貌を、順を追って語っていきたい。

SAP権限テストという「地味で重い」作業を自動化する

まず、何を作ろうとしたのかを説明しておこう。

SAPの導入プロジェクトでは、ユーザーに割り当てた権限ロールが「意図どおりに効いているか」を検証する工程がある。あるユーザーで特定のトランザクションコード（以下T-CD）を開いてみて、ちゃんと開けるか、それとも「権限がありません」と弾かれるか。これを一つひとつ確かめていく。重要な作業であるが、手間のかかる、地味で重い作業だ。

問題は、この確認対象のT-CDが数十、時に数百に及ぶことだ。人力でSAP GUIにT-CDを打ち込み、画面を目視し、結果をExcelに記録し、証跡のスクリーンショットを撮る——これを延々と繰り返す。

考えただけで気が遠くなる。当然、自動化したい。

やりたかったことの全体像

今回作りたかったツールの要件は、次のようなものだ。

要するに「Excel駆動の、SAP権限テスト自動実行＆証跡取得ツール」である。地味だが、現場のSAPコンサルタントなら「あれば絶対に助かる」と即答する類のツールだ。

三者のコラボレーション： 二人のAIと私

ここで、今回の開発体制を具体的に説明しておきたい。登場人物は次の三者である。

一人目は人間、つまり私

SAPの現場知と、後述する自作ツールのコード資産を持ち込み、全体の方針を決め、二つのAIの間を取り持つハブの役割を担う。

二人目はAI、Claude Code

Anthropicのコーディングエージェントで、私のWindows上でPythonのコードを実際に書き、ファイルを生成し、修正する「実装担当」である。

三人目もAI、Claudeのチャット

こちらは「作戦参謀」だ。Claude Codeのセットアップ方法や使い方を教え、詰まったときに原因を推定し、そして何より、Claude Codeに流し込むための的確なプロンプト（指示文）を組み立ててくれる役割を担った。
なお、今回私が使ったのはOpus5だ。

私はこの二人のAIを、次のように使い分けた。

まずチャット側のClaudeと相談して「次に何をすべきか」「どう指示すべきか」の作戦を練る。そこで得たプロンプトを、Claude Codeに流し込んで実装させる。実行結果やエラー、画面のスクリーンショットを、今度はチャット側のClaudeに見せて「これは何が起きているのか」「次はどうするか」を相談する。そしてまた次の指示へ——。

人間である私は、この二人のAIの間で情報を運び、判断を下す橋渡し役に徹していた。言うなれば、実装担当と参謀を抱えた、小さなプロジェクトのプレイングマネージャーである。

三画面で戦う： AI協働開発のデスクトップ

この三者体制は、私のデスクトップにそのまま表れていた。SAP自動化アプリの開発のために開いていた画面は、大きく三つである（ExcelやエクスプローラーのようなSAP標準の道具は除く）。

一つ目は、Claude Code。PowerShell経由で起動し、ここでコードの生成と修正が行われる。

二つ目は、Claudeのチャット。作戦会議の場であり、プロンプトの生成工房であり、詰まったときの相談窓口だ。

三つ目は、Pythonアプリをデバッグ実行するためのPowerShell。Claude Codeが書いたPythonのコードを、実際にSAPを相手に走らせて動作を確認する検証の場である。

この三画面を行き来しながら、私は作業を進めた。

チャットで作戦を立て、Claude Codeで実装し、別のPowerShellで実際に動かして結果を見る。その結果をまたチャットに持ち帰る。この三角形をぐるぐると回すことが、開発のサイクルそのものだった。

「実装を担うClaude Code」と「実行して検証するPowerShell」を分けたのは、役割を明確にするためである。前者はコードを書く係、後者はSAP相手に動かす係。混ぜずに分けることで、頭が整理される。

最初の設計判断 ― どのAIツールで作るか

そもそも、この種のツールをどう作るのがベストか。私はまずチャット側のClaudeに相談した。

返ってきた答えは明快だった。開発そのものはClaude Codeに任せるのがよい、と。

理由はシンプルで、Claude Codeはローカルのマシン上でコードを書き、実行し、その結果を見てまた直す、という反復をこなせる開発エージェントだからだ。私自身がSAP GUIを動かしているのと同じWindows上で、開発と検証を回せる。

この「作戦をチャットで決めてから、実装をClaude Codeに任せる」という流れが、まさに三者協働の第一歩だった。参謀が方針を示し、実装担当が形にする。人間はその判断を承認し、橋を渡す。

相棒たちとの初対面： 環境セットアップでいきなり躓く

意気込んで始めたはいいが、開発の第一歩、環境構築でさっそく転んだ。だがこの「躓きと復旧」もまた、これから同じ道を歩む人には有益な情報になるはずなので、包み隠さず書いておく。そしてここでこそ、チャット側のClaudeが「セットアップの先生」として活躍した。

SAP自動化アプリの開発に何をインストールするか

今回のツールはPythonで作る。したがってまず必要なのは、WindowsのPython本体である。

ここで一つ重要な注意がある。開発をWSL（Windows Subsystem for Linux）でやりたくなる人もいるだろうが、実行するPythonはWindows側でなければならない。理由は、このツールがSAP GUIのウィンドウを直接操作するため、WSL上のPythonではWindowsのウィンドウハンドルに手が届かないからだ。ここを外すと、後で全く動かずに悩むことになる。この勘所も、チャット側のClaudeが最初に釘を刺してくれた。

Claude Codeの準備

Claude Codeのインストールはとても簡単。PowerShellから次のコマンド一発だ。

irm https://claude.ai/install.ps1 | iex

ダウンロード手順の詳細を知りたければ、以下のサイトに上記のコマンドを含むOS別の記載がある。

https://claudelog.com/faqs/download-claude-code

「claudeが認識されません」 ― PATHの罠

Claude Codeのインストーラは無事に完走した。ところが、いざPowerShellでclaudeと叩くと「用語 ‘claude’ は認識されません」と冷たく突き放される。インストールは成功したはずなのに、起動できない。

すかさずチャット側のClaudeに状況を伝えると、即座に原因を言い当てた。

これはWindowsのnativeインストーラでよく起きる、PATH登録の取りこぼしだという。インストーラは実行ファイルをユーザーフォルダ配下の所定の場所に置くのだが、そこを環境変数PATHに追加しそこねることがある。対処は、その場所をユーザーのPATHに追加し、PowerShellを開き直すだけ。「まずファイルが存在するか確認し、あれば一時的にPATHを通して動作を確かめ、恒久的に登録する」という手順を段階的に示してくれたので、初見の関門をあっさり越えられた。

ちなみに私は、この開発を途中から別のマシンでも動かした。すると当然のように、そちらでも同じPATHの罠にかかった。「ああ、これね」と即座に対処できたのは、一度チャットで教わった道だったからだ。

Python本体

Microsoft Storeにもあるが、python.org 版が推奨されている。次のコマンド一発でインストール可能。

pip install pywin32 openpyxl pillow anthropic

インストール時に「Add python.exe to PATH」は必ずチェック。

依存パッケージ

詳しくはよく分からないが、 Excel操作・スクショ・判定のために入れておくといいらしい。Claudeに言われるがままインストールする。

pip install pywin32 openpyxl pillow anthropic

エディタ

定番のVS Code（Visual Studio Code）を使用する。

エディタはPythonコードを直接修正するために使用するものだが、今回はコードの作成も修正もすべてClaude Codeに任せたので使用することはなかった。

人間の手札を切る： 自前のコード＝ノウハウを渡す

ここからが、今回の協働で「自分の知見が役立った」と感じた部分だ。

AIに丸投げするのではなく、人間が持っている知見・資産を、適切なタイミングで差し出す。これが三者の協働を加速させた。

なぜSAP GUI Scriptingを使わないのか

SAP GUIを自動操作する、と聞いたSAP技術者の多くは、まず「SAP GUI Scripting API」を思い浮かべるはずだ。画面部品をIDで掴んで操作する、あの仕組みである。実際、チャット側のClaudeも最初はこの方式を提案してきた。

しかし現場には、Scriptingが管理者によって無効化されている環境が少なくない。セキュリティ上の理由で、あえて封じられているのだ。まして今回は「権限のテスト」である。与える権限もAPIも、依存するものは最小限にしたい。

ここで、私には手札があった。前職のSAPデータ登録・自動化ツールの開発で培った、Scriptingに頼らずWindowsのAPIで直接ウィンドウを操作するコードである。SAP GUIのウィンドウを探し出し、そのコマンドボックスに対してWindowsのメッセージを送り込んでT-CDを流し込み、Enterに相当する信号を送る。この方式なら、Scriptingが無効でも動く。

私はこのコード（元はVBAで書いていたもの）をチャット側のClaudeに提示し、「これをPythonに移植する方針で進めたい」と伝えた。

ここでのClaudeの対応が賢かった。まず「そのコードはScripting APIを使っているのか、それともウィンドウメッセージ方式なのか」を切り分け、後者だと確認したうえで「ならば移植する意味がある」と判断した。もしScripting方式だったなら、コンピュータ言語を変えても本質は同じで移植の意味が薄い、という理屈まで添えて。

人間の持ち込んだ資産を、AIが正しく評価して受け取ってくれたわけだが、自分がAIの先生になった気がして、ちょっと良い気分である。

参謀が指示書を書き、実装担当が形にする

ここでの三者の連携が、今回の開発スタイルを象徴していた。

• まず私が現場の資産（動作実績のあるコード）と方針（Scriptingを使わない）を持ち込む。
• チャット側のClaudeが、それをClaude Codeに渡すための具体的な指示文に落とし込む。
• そしてClaude Codeが、その指示に従ってPythonの部品を実装する。
• 人間は、参謀が書いた指示文を承認してClaude Codeに流し込み、出来上がった結果をまた参謀に見せる。

どれか一人が欠けても、この速度は出ない。人間だけなら移植に時間がかかり、実装担当のAIだけなら「Scriptingを使わない」という現場知や実績あるコードを持っていない。そして参謀のAIがいなければ、実装担当への的確な指示文を組み立てるのに、人間がもっと頭を悩ませることになっただろう。

移植された部品は、SAPにログインした状態で誰でも開ける無害なT-CD（たとえばSU3）を一つ投げてみて、テストする。

すると、あっさり動作確認できた。

そうりゃあ上手くいくさ。元は私が書いたコードなのだから！

Excelから読んだT-CDをコマンド欄に流し込むという、このアプリの心臓部が、生きて動いた瞬間だ。
ここが動けば、あとは積み上げるだけだ。

ちなみに、Claudeとのチャットを始めてからここまで来るのに、およそ30分である。

実測が全て： SAPのメッセージはどこにいるのか

心臓部が動いたので、次は「T-CDを実行した結果、成功したのか権限エラーなのか」を読み取る仕組みづくりだ。

ここからは、実際のSAP画面を相手に一つずつ突き止めていく、探偵のような工程が続く。そしてこの探偵役は、まさに三者の連携で進んでいった。

ステータスバーの正体を突き止める

判定の根拠になるのは、T-CD実行後にSAP画面下部のステータスバーに出るメッセージだ。「権限がありません」「未登録です」といった一行である。

だが、Scriptingを使わない以上、このメッセージがWindows上でどのウィンドウ部品に格納されているのかは、自明ではない。

そこで、チャット側のClaudeと相談して「SAP画面配下の全ウィンドウ部品を一覧表示し、そのクラス名とテキストを吐き出す診断ツールを作らせよう」という作戦を立て、その指示文をClaude Codeに流し込んだ。生成された診断ツールを別のPowerShellで実行し、存在しないT-CDをわざと投げてエラーを出させ、その出力をチャットのClaudeに見せる。

この実測の結果、メッセージ本体が特定のウィンドウ部品（ステータスバー領域配下の入力欄部品）に格納されていることが判明した。存在しないT-CDを投げれば「未登録です」が入り、正常に開けるT-CDなら空になる。空なら正常、非空ならメッセージありという、判定の軸がここで固まった。

まさに三画面をぐるりと一周して得た成果である。

文字化けとの戦い

ところが、読み取ったメッセージがことごとく文字化けした。日本語が意味不明な記号列になる。

原因は、テキスト取得に使ったWindows APIがANSI版で、日本語をうまく扱えていなかったことだ。ここはチャットのClaudeが原因を推定し、Unicode版のAPIで読み直すプロンプトを組み立て、Claude Codeに実装させて解決した。「日本語環境では文字取得は必ずUnicode版APIで」という基本を思い出させてくれた。

修正後は「トランザクション ○○ は未登録です」と、美しい日本語で取得できるようになった。

差分検出、大空振り

この工程では、大きく空振りもしている。当初は「T-CD実行の前後で、変化したウィンドウ部品を自動検出すればステータスバーが分かるはず」という賢そうな作戦を立てた。ところが実行してみると、検出された「変化した部品」は、実はツールバー上のボタンが内部的に作り直されただけのダミーばかりで、肝心のメッセージは差分に現れなかった。

ここで潔く方針転換し、「差分を探す」のではなく「メッセージが入る部品を名指しで直読みする」方式に切り替えた。回り道ではあったが、この空振りのおかげで「SAPのウィンドウ部品はこう振る舞うのか」という理解が深まった。実測で回り道をしながら、確実な方式にたどり着く。これがこの手の開発の本質だと思う。

沼、また沼 ― 三者で渡るデバッグの泥沼

判定の仕組みができ、いよいよ本体ツールの組み立てに入った。ここからが、ある意味この開発のハイライトである。

実際にSAPを相手にアプリを走らせると、次から次へと問題が噴出した。しかし面白いのは、いつでも三画面をぐるりと回すリズムで解決していったことだ。

デバッグ用PowerShellで問題を再現し、その画面をチャットのClaudeに見せて原因を推定してもらい、修正指示を組み立ててClaude Codeに実装させる。この三角形の回転で、沼を一つずつ渡っていった。

良かれと思った処理が、実は害だった

各T-CDを実行する前に、「前の画面を閉じてスタート画面に戻す」ために、一度コマンドフィールドに「/N」を送信する処理を入れた。丁寧な作りのつもりだったが、これを入れた瞬間、T-CDが一つも開かなくなった。

この事象に対するClaudeの原因切り分けは鮮やかだった。

デバッグ用PowerShellで「T-CDを一つだけ開く」単体テストをやってみる。すると、正常に開く。
この結果をチャットのClaudeに見せると、「犯人はT-CD実行そのものではなく、その前に入れた戻すための/nだ」とすぐに特定した。

実は、戻る先の画面ではコマンドフィールドの状態が特殊で、戻った直後のT-CD入力を受け付けなくなっていたのだ。良かれと思って足した一手が、全体を止めていた。この処理を削除したら、あっさり動いた。

「単体テストで切り分けると原因が一意に絞れる」という、デバッグの王道を地で行く一幕だった。

判定が一行ずつズレる怪

次に遭遇したのは、判定結果がExcel上で一行ずつ下にズレて記録される怪現象だ。あるT-CDの行に、一つ前のT-CDの結果が書かれてしまう。原因は、T-CDを送信した後、SAPの画面が実際に切り替わりきる前に結果を読み取ってしまい、前の画面のメッセージ残像を拾っていたことだった。

ここでの解決策が秀逸だった。
「一定秒数待つ」という待機処理は、一見上手くいきそうに思えるが、実際にやってみると不安定だ。PCの処理やSAPサーバーからの応答が遅ければ間に合わない。

そこでチャットのClaudeが提案したのは、「送信前の画面の状態を覚えておき、そこから変化したことを確認してから読む」という方式だった。

不確かな一定時間の待機ではなく、変化を観測してから進む。これで、全権限を持つはずのユーザーで試した際に全T-CDが正しく判定され、権限のないユーザーでは狙いどおり「権限がありません」を検出できるようになった。

スクリーンショットの下が切れる

証跡のスクリーンショットで、肝心のステータスバーが写る画面下部が切れるという問題にも悩まされた。ウィンドウを最大化しても切れる。

ここでも実測が効いた。最大化したウィンドウの座標を実際に出力してみると、ウィンドウが画面の縁から数ピクセルだけはみ出す値を返していた。この「はみ出し座標」をそのまま撮影範囲に渡していたため、範囲がずれて下端が欠けていたのだ。座標を画面の実領域に収まるよう補正してから撮ることで解決した。

さらに厄介だったのが、別のマシンで動かしたときに起きた座標エラーだ。そのマシンはマルチモニタ構成で、SAPウィンドウが主モニタの外側のモニタにあったため、座標が負の値になり、撮影範囲の計算が破綻した。デバッグ用PowerShellで実際の座標値を出力し、その数値をチャットのClaudeに見せると、モニタの実際の配置を取得して撮影範囲を組み直す方針を示してくれた。環境が変わると新たな問題が顔を出す。だが三画面のリズムで一つずつ潰していけば、着実に解決していく。

一過性のメッセージを、確実な証跡に変える

最も本質的だった問題は、権限エラーのスクリーンショットにエラーメッセージが写らないことだった。判定では確実にメッセージを取得できているのに、撮影の頃にはステータスバーの表示が消えている。SAPのステータスバーメッセージは、画面操作や再描画のタイミングで消える一過性のものだったのだ。

このため、メッセージが写っているスクリーンショットを撮れないことが多い。この事実から、作戦参謀であるCaludeは現実的な提案を私にしてきた。

スクショという「見た目の一過性メッセージ」よりも、判定時に確実に取得できているメッセージ文字列を、必ずExcelのセルにテキストとして書き残すことを主たる証跡とするよう提案してきたのだ。スクリーンショットは補助証跡と位置づける。画像に頼らず、取得済みのデータを正として残す。この割り切りによって、証跡の信頼性が一気に上がった。

完成、そして磨き上げ： 実務で使えるツールへ

中核が固まったあとは、実運用で効いてくる細部を詰めていった。これらもすべて、チャットで要件を伝え、出てきた指示文をClaude Codeに流し込めば的確に実装された。

たとえば、対象のExcelファイルが他のアプリで開かれていると保存できずにエラーになる。これを、処理の最初に書き込み可否をチェックし、開いていれば「閉じてからEnterを」と促して待つ仕組みにした。全T-CDを処理し終えた最後で失敗して全部が無駄になる、という悲劇を未然に防げる。

また、Excel内に同じT-CDが複数回現れるケースに備え、起動時に重複を検出して「○○が△行目と□行目で重複しています。続行するか終了するか」とユーザーに判断を仰ぐようにした。処理中に同じT-CDが出た場合は、シート名に行番号を付けて区別する。前回実行の古い証跡シートは削除して最新に置き換える。こうした「痒いところに手が届く」振る舞いを、対話しながら一つずつ足していった。

処理対象の終了行を指定できるようにしたり、ファイル名だけの指定でもカレントフォルダから読めるようにしたり。細かな使い勝手の改善も、要望を言葉で伝えるだけで形になっていく。この「言えば直る」感覚こそ、AIコーディングエージェントの真骨頂だと思う。

二つのAIは、何が有用だったのか

ここで一度立ち止まり、二つのAIの有用性を、私の実感として整理しておきたい。役割が違うので、効いたポイントも違う。

まず前提として、面白い事実がある。AIが出力するコードは、文法的にはほぼ完璧だ。書き間違いやタイプミスで動かない、という初歩的なつまずきは、まず起きない。

しかし——ここが肝心なのだが——文法的に正しいことと、期待どおりに動くことは、まったく別物である。SAPの画面がいつ切り替わるか、ステータスバーのメッセージがどの部品に入るか、マルチモニタで座標がどうなるか。こうした「実際に動かしてみないと分からない」ことは、コードがいくら綺麗でも、実測しなければ確かめようがない。本記事で延々と沼にハマってきたのは、まさにこの「実測が要る領域」だったからだ。

だからこそ、開発は次のサイクルで回った。実装担当のClaude Codeが書いたコードを、人間である私がデバッグ用PowerShellで実際に動かす。その結果——エラーであれ、おかしな挙動であれ——を、参謀役のチャットのClaudeに伝える。チャットのClaudeが原因を推定し、次の修正のためのプロンプトを組み立てる。そのプロンプトをClaude Codeに流し込んでコードを直し、また動かす。

この「実装 → 実測 → 相談 → 指示 → 修正」のサイクルを、ぐるぐると高速で回すことでデバッグは進んだ。

人間が一人で「調べて、書いて、試して、また調べて」とやっていたら一周に何十分もかかるところを、この三者体制なら段違いのスピードで周回できる。とにかくデバッグが捗るのだ。

そして、このサイクルを回すうえで、私が何より助けられたのは、チャットのClaudeの、常に冷静沈着な佇まいだった。どんなに意味不明なエラーを見せても、動じない。
淡々と原因の候補を挙げ、「まずこれを確かめましょう」と的確な次の一手を示してくる。その指示に従っていれば、そのうち必ず解決するだろう——という絶対的な安心感があった。言われたとおりに一つずつ実測を重ねていけば、どんな沼も、いつかは必ず抜けられる。
この信頼感があるから、目の前の問題に落ち着いて向き合えた。参謀を信じて任せられる、というのは、想像以上に大きな支えだった。

考えてみてほしい。もし私が一人で、これだけ次から次へと問題にぶち当たっていたら、どうなっていただろうか。

作業が捗らないのはもちろんだが、それ以上に、途中で嫌になって投げ出していたはずだ。「良かれと思った処理が害だった」「判定が一行ずれる」「Excelが壊れる」「スクショの下が切れる」——この次々と起きる不具合を、たった一人で、解決の当てもないまま受け続けるのは、精神的にきつい。孤独な戦いは、技術的な難しさ以上に、心を折る。

だが、今回はそうならなかった。詰まったときに一緒に頭を抱え、冷静に次の道を示してくれる相棒が、二人もいた。この心強さは、孤独になりがちな開発において、想像以上に大きかった。

「一人じゃない」という、ただそれだけのことが、開発を最後まで走り切らせてくれた。速く終わる、正確に動く——そうした目に見える利点の陰にある、この精神的な安定こそが、AIと共に開発を進めること、いわゆるバイブコーディングの、最も大きな利点の一つなのではないか。私は今回、それを心から実感した。

一ヶ月の仕事が半日に： 時短だけではないAIと協働することの利点

さて、苦労話をここまで書いてきたが、いちばん伝えたいのはここからだ。これだけ沼にハマり、これだけ問題に遭遇したにもかかわらず、このツールは開始から完成まで、およそ4時間で出来上がった。

しかも、この4時間の大半は「AIの応答を待っている時間」である。Claude Codeがコードを書き、実行し、結果をまとめている間、あるいはチャットのClaudeが作戦と指示文を練っている間、私はコーヒーを飲んだり、次に何を確認すべきかを考えたりしていた。私自身が実際に手を動かし、頭を使っていた正味の時間は、4時間よりずっと短い。SAP画面を見て「ここがステータスバーだ」と判断したり、二つのAIの間で情報を運んで「この処理は害だから消そう」と方針を示したり。人間がやったのは、そういう橋渡しと要所の判断が中心だ。

もし同じことを、私が一人で、AIの助けなしにやっていたら——

おそらく一ヶ月はかかっただろう。Scriptingを使わないウィンドウ操作の移植、ステータスバーの部品特定、文字化けの解決、遷移検知の安定化、マルチモニタ座標の補正、Excel破壊の回避。これらの一つひとつが、調べ、試し、失敗し、また調べる、という時間を要する調査タスクだ。それを何十個も積み重ねる。想像するだけで気が重い。

そもそも、本業をやりながら一ヶ月もの試行錯誤の時間を確保すること自体が不可能だ。

それが、半日で終わった。この差は、単なる「作業の効率化」という言葉では足りない。取り組めるテーマの範囲そのものが広がるのだ。「一ヶ月かかるなら、やめておこう」と諦めていた自動化が、「半日でできるなら、やってみよう」に変わる。生産性が上がるとは、こういうことだと思う。速く終わるだけでなく、やろうと思えることが増える。

そして大事なのは、これは「AIに丸投げしたら勝手に出来た」という話では断じてない、という点だ。

Scriptingを使わないという現場知、動作実績のあるコード資産、SAP画面を見て部品を特定する判断、害になる処理を見抜く経験。人間の側の専門性が随所で効いている。そして二つのAIを適材適所で使い分け、その間をつなぐハブとしての立ち回り。1人の人間と2つのAIが、それぞれの持ち場で噛み合ったときの生産性こそが、今回いちばんの発見だった。

まとめ： 一人じゃない、という最大の武器

本記事では、SAP GUI Scriptingが使えない現場で、二つのAIとの協働によってSAP権限テストの自動化ツールを作り上げた過程を、環境セットアップの躓きから沼のデバッグ、そして完成までたどってきた。

振り返れば、この開発の核心は役割分担にある。
現場知と資産を持ち込み、二つのAIをつなぐハブとなる人間。作戦を練り、指示文を組み立てる参謀役のチャットのClaude。そのコードを実際に書き、実行する実装担当のClaude Code。
この三者が、三画面のデスクトップ上で三角形を描くように連携したとき、一ヶ月の仕事が半日で終わった。しかもその半日の大半は待ち時間で、人間の正味の労力はさらに小さい。生産性が上がるとは、速く終わることだけでなく、これまで諦めていたことに手を伸ばせるようになることだと、身をもって知った。

ここで、あらためて強調しておきたいことがある。
今回、処理の核となる部分——SAP GUIを直接操作するWindowsメッセージを送信するコード——は、AIが生み出したものではなく、私が作りAIに提供したものだ。Scriptingが封じられた環境で、どう立ち向かうか。この判断と資産は、現場で手を動かしてきた人間の側にしかなかった。いわば、人間の持つ「現場知」が、開発の土台を支えたのである。AIはときに万能に見える。実際、恐ろしく優秀だ。だが今回の経験は、私にこう再認識させた——
人間の持つ知見も、まだまだ捨てたものではない、と。

もう一つ、この協働が教えてくれた本質がある。
AIはコードを書けるが、自分自身でそのコードを走らせることはできない。実際のSAPを相手に動かし、画面がどう変わったかを見て、その結果をフィードバックする——この「実測」の役目は、人間にしか担えなかった。裏を返せば、人間が走らせて結果を返すからこそ、AIもまた活きるのだ。
コードを書くAIと、それを現実の中で走らせる人間。この両輪が噛み合って初めて、机上のコードが「実際に動くアプリ」になる。AIと人間は、どちらかがどちらかに取って代わる関係ではない。互いの欠けたところを埋め合う、対等な相棒なのだと思う。

そして、今回いちばん深く胸に残ったのは、実は速さや効率ではない。
「開発が、孤独な戦いでなくなった」ということだ。一人で黙々とコードと向き合い、原因の分からないエラーに延々と一人で悩み、解決の当てもないまま心をすり減らしていく—— これまでの開発には、多かれ少なかれ、そういう孤独がつきまとっていた。技術的な壁より、その孤独のほうが、途中で人を投げ出させる。

今回、その孤独が消えた。詰まれば冷静に次の一手を示してくれる参謀がいて、指示どおりに手を動かせば必ず前に進むという安心感があった。「アドバイス通りにやっていれば、そのうち必ず解決する」——この安心感が、どんな沼の中でも私を落ち着かせ、最後までやり切ることができた。
精神的に安定した状態で開発に没頭できること。これは、生産性という言葉では測りきれない。AIと共に作る「バイブコーディング」の、静かで、しかし決定的な利点だと思う。

SAPの現場には、地味だが重い、自動化したい作業がまだ山ほど眠っている。次はどの沼に飛び込もうか——
そう思えること自体が、このAIとの協働がもたらした、何より大きな収穫なのかもしれない。

---