トヨタ北米、AWS上のSAP運用基盤を内製　20システム・60台超を1画面で管理

BasisPilotを使えるのは、Toyota Motor North Americaの権限を持つ社員に限られています。BasisPilotは商用製品ではありません。外部の企業や個人に販売されるものではありません。

BasisPilotは社内プラットフォームです。AWS上で動くSAP（企業の基幹業務を支えるソフト）の運用を、1つの画面とAIアシスタントで扱えます。

AWSの日本語ブログによると、これはトヨタ北米のSAPチームと共同で執筆された事例です。公開されているのはアーキテクチャと設計判断です。開発はトヨタのSAP BTP Platform部門が担当し、SAP運用から始まりました。

60台超・20システムを1画面に集約

現在の対象は、開発・テスト・ステージング・本番の各環境にまたがる60台以上のAmazon EC2ホスト上の20のSAPシステムです。複数のAWSアカウントとリージョンにまたがります。ABAPとJavaのアプリケーションスタックや、マルチテナント構成を含むSAP HANA（SAPのデータベース）に対応します。

これまでは、エンジニアがターミナル、SAP GUI、スプレッドシート、AWSコンソールを行き来して作業していました。BasisPilotは単一ダッシュボードとして設計・開発されました。Amazon Bedrockを活用したツール呼び出し型のAIアシスタントを組み込んでいます。

設計の土台には5つの原則があります。

• 1つ目は、SAPシステム、AWSホスト、クラスター、バックアップ、パッチの状況を1つの画面で見ることです。どのアカウントやリージョンにあるかは問いません。
• 2つ目は、変更を伴う操作をロールベースのアクセス制御、環境ごとの承認ゲート、完全な監査証跡に通すことです。
• 3つ目は、AIが質問への回答や承認済みツールの呼び出し要求などを担うことです。検証・承認・実行・監査はプラットフォーム側が担います。
• 4つ目は、権限を持つ各チームが、ヘルスやアラートを自分で確認できることです。
• 5つ目は、プラットフォームをサーバーレスで構成し、パッチを当てるサーバーを持たないことです。

ダッシュボードには、次の機能があります。

• システムの起動・停止・再起動と、CPU、メモリ、SAPプロセスの状態などのライブメトリクス
• HANAバックアップカタログの可視化と、RPO（許容されるデータ損失の範囲）違反のアラート
• OSパッチ適用。SAPを考慮し、承認ゲート付きで「SAP停止、再起動、SAP起動」の順に行う
• HAクラスターの状態確認と、AWS Elastic Disaster Recoveryを使ったDR（災害復旧）訓練。模擬訓練と実訓練があり、人による確認ゲートを挟みながらステップごとに実行する
• SAPセキュリティ監査ログの監視と、コストの最適化提案
• 誰が何をしたかを残す操作ログ

アクセスはロールベースです。運用操作ができるのは、承認された役割と承認ゲート付きのワークフローに限られます。読み取り専用の利用者は、プロダクト、インフラ、サポートの各チームにも広がっています。

AIはツールを呼ぶだけ、実行は決まった手順が担当

AIアシスタントは、表示中のページを認識しながら動きます。質問への回答、承認済みバックエンドツールの呼び出し要求、診断結果の要約を担います。

検証、承認、実行、監査はプラットフォーム側が制御します。ブログは「生成されたテキストがシェルコマンドになることは決してありません」と説明しています。

Manish Kumar氏は、AIをどこに当てはめるかから始めたのではないと語っています。最初に考えたのは、Basisエンジニアがシステムに触れる前に下す判断でした。

どのエビデンスを信頼するか、何をどの順序で行うか、何があれば作業を止めるかです。BasisPilotは、その判断をプラットフォームの振る舞いとして書き起こしたものだとしています。

制限は、質問の範囲にも及びます。ユーザーが「バックアップステータス」とだけ尋ねると、アシスタントはどのSAPシステムかを聞き返します。直近の文脈から対象を推測することはなく、システムIDが指定されて初めて、読み取り専用のバックアップツールにつながります。

「このシステムはメンテナンスしても安全か」という質問には、まとめて答えます。まとめる内容は、システムの状態、ホストの負荷、バックアップの保護状況、クラスターの状況、メンテナンスウィンドウ、最近の操作履歴です。

10〜90分の作業を支える設計

SAPの停止や起動は、通常の操作でも10〜90分かかります。データベースやアップグレードの作業には数時間続くものもあり、同期的なWebリクエストの時間には収まりません。

そこでBasisPilotは、作業の開始前にDynamoDBへ追跡用の記録を作ります。記録には、操作のID、現在の段階、進捗、完了した結果、承認、エラーが残ります。ホスト側の作業はAWS Systems Manager Run Commandが実行し、画面とチャットは同じ記録を参照します。

Lambda関数の残り時間が少なくなると、状態を保存して自分自身を非同期に再呼び出しします。ブラウザを閉じても停止処理は続き、エンジニアは記憶から手順を組み直すことなく、保存された状態に戻れます。

順序も、画面に表示するだけでなくコードで強制されています。停止時は、アプリケーションインスタンスを止めて確認します。その後、セントラルサービス、データベース、必要ならEC2の順に止めます。

データベースの停止を確認できないときは、インフラの停止がブロックされます。

「コマンドが受け付けられた」という段階は中間状態とみなされます。成功とするには、意図した結果をライブで検証する必要があります。

ハブアンドスポーク構成と監視の頻度

中央のハブアカウントに、画面、API、AIエージェント、DynamoDBの状態を置きます。実際のSAPは、ステージング、本番、DRのスポークアカウントにあります。

ハブからスポークへの接続は、範囲を限定したクロスアカウントロールをSTS AssumeRoleで引き受ける方式だけです。ホストでの作業はSystems Manager Run Commandを使います。そのため、プラットフォームが管理する操作では、SSHキーも外からの通信の開放も不要とされています。

監視の間隔は次のとおりです。

• ライブメトリクス、SAP監査ログ、SLA測定は5分ごと
• 性能とファイルシステムの履歴は1時間ごとで、90日間保持
• HANAバックアップカタログは1日3回
• セキュリティ基準の確認は30分ごと

SLAの目標値は次のとおりです。

• 開発とテスト: 99.0%
• ステージング: 99.5%
• 本番: 99.9%

計画停止はメンテナンスウィンドウに登録でき、その間は該当システムのアラートが抑えられます。ウィンドウの開始と終了時刻、理由、担当エンジニアが記録されます。作成・更新・削除は監査ログに残ります。

Kiroで開発を加速

開発を主導したのは、Senior SAP Product OwnerのManish Kumar氏です。AWSのAI搭載IDEのKiroを使いました。

大規模なコードの探索や雛形の作成、ReactとLambdaをまたぐ不具合の追跡、テストや技術文書の改善を進めました。SAPの依存関係の順序や承認の境界などは、同氏のSAP運用経験に基づいています。実際のシステムの挙動と照らし合わせて確認されています。

AWSのSAP向けの取り組みについては、AWS、SAP ABAP向けにスペック駆動開発のワークフローを公開でも報じています。

編集部の見方では、この事例の要点はAIの性能ではなく、AIに触らせる範囲を先に設計したことにあります。