はじめに

Toyota Motor North America（以下、トヨタ）は、AWS 上の大規模な SAP ランドスケープで、AI アシスト型の SAP 運用プラットフォーム BasisPilot を運用しています。現在の BasisPilot の対象範囲は、開発・テスト・ステージング・本番の各環境にまたがる 60 台以上の Amazon EC2 ホスト上の 20 の SAP システムで、複数の AWS アカウントとリージョンに及びます。このプラットフォームは、ABAP および Java のアプリケーションスタックや、マルチテナント構成を含む SAP HANA データベースなど、主要な SAP ワークロードタイプをサポートしています。従来、このランドスケープの運用には、エンジニアがターミナル、SAP GUI、スプレッドシート、AWS コンソールの間を行き来する必要がありました。

トヨタの SAP BTP Platform 部門で、BasisPilot は Amazon Bedrock を活用したツール呼び出し型の AI アシスタントを組み込んだ、単一ダッシュボードの運用プラットフォームとして設計・開発されました。SAP 運用から始まったものの、現在では AWS 上でホストされるワークロードの可視性、ヘルス指標、一般的なトラブルシューティング情報を、手動のステータス更新を待たずに必要とする、権限を持つプロダクト・インフラ・サポートの各チームにとっても有用なプラットフォームになっています。本記事では、このプラットフォームの機能、アーキテクチャ、背後にある AWS サービス、そして AI アシスタントがヘルスチェックから SAP カーネルアップグレードの計画・実行支援に至るまで、承認済みの運用ワークフローをどのように支援しているかを説明します。

社内発のイノベーション

BasisPilot は商用製品ではありません。トヨタ社内で、SAP BTP Platform と SAP 運用ランドスケープに焦点を当てたエンジニアリングの取り組みとして始まりました。

Manish がこのプラットフォームを構想し、運用モデルを定義し、アーキテクチャ・設計・実装を主導しました。その作業には、共通のエビデンスモデル、サーバーレス API、クロスアカウント制御、非同期ワークフローエンジン、SAP の依存関係ロジック、承認境界、そしてツール呼び出し型の AI レイヤーが含まれます。トヨタの関係者と AWS のメンバーは、レビュー、検証、改良で協力しました。このプラットフォームは、監視、ライフサイクル管理、パッチ適用、HA、DR、バックアップ、コスト、セキュリティといった日々の運用を単一のサーバーレスインターフェースに集約し、承認済みで監査可能なワークフローのための AI アシスト運用レイヤーを備えています。その対象範囲は、SAP 運用ダッシュボードから、権限を持つチーム向けの共通の可視化・トラブルシューティングツールへと拡大しています。

実装を加速するための Kiro の活用

BasisPilot のコンセプト、運用モデル、アーキテクチャを定義した後、Manish は AWS の AI 搭載 IDE である Kiro を開発環境として使い、大規模なコードベースの探索、スキャフォールディングの作成、React と Lambda の境界をまたぐ不具合の追跡、テストや技術ドキュメントの改善といった個別の実装作業を高速化しました。特に、1 つの変更が API コントラクト、DynamoDB でのトラッキング、Systems Manager による実行、ユーザーインターフェースにまたがる場合に役立ちました。

SAP の依存関係シーケンス、承認境界、ロールバック要件、クロスアカウント制御、検証基準は Manish の SAP 運用経験に基づくもので、実際のシステムの挙動と照らし合わせて確認されています。彼は提案をレビューして調整し、BasisPilot の規約に統合し、結果をテストし、最終的な設計と実装の責任を担いました。

本記事の内容について

トヨタの公開コンテンツガイドラインに従い、本記事ではアーキテクチャパターン、AWS サービス、設計上の判断のみを説明しています。アカウント ID、社内ホスト名、エンドポイント、認証情報、システム ID、その他の環境固有の情報は含まれていません。

「私は、AI をどこに当てはめられるかを問うところから始めたのではありません。Basis エンジニアがシステムに触れる前に下さなければならない判断、つまり、どのエビデンスを信頼するか、何をどの順序で行うべきか、何があれば作業を止めるべきか、から始めました。BasisPilot は、その判断をプラットフォームの振る舞いとして書き起こすことから生まれたのです。」

– Manish Kumar、Senior SAP Product Owner、Toyota Motor North America

ミッションと目標

BasisPilot は、改善（継続的改善）の精神に基づく 5 つの原則に沿って開発されました。

• 単一ダッシュボード – SAP システム、AWS ホスト、クラスター、バックアップ、パッチサイクルを、どの AWS アカウントやリージョンにあるかにかかわらず、1 つのダッシュボードで可視化します。
• 安全な自動化 – 変更を伴うすべての操作は、ロールベースのアクセス制御、環境に応じた承認ゲート、完全な監査証跡を経由します。
• 汎用チャットボットではなく AI アシスト運用 – アシスタントは質問への回答、承認済みバックエンドツールの呼び出し要求、診断結果の要約、制御されたワークフローのガイドを行い、検証・承認・実行・監査の制御はプラットフォーム側が担います。
• 共有のセルフサービス可視化 – 権限を持つアプリケーション・インフラ・サポートの各チームが、ヘルス、アラート、トラブルシューティング情報を直接確認できるため、SAP BTP Platform チームによる手動更新への依存が減ります。
• サーバーレスでコスト効率が高い – プラットフォーム自体にパッチを当てるべきサーバーはありません。バックエンドは Lambda、DynamoDB、およびリクエスト課金のマネージド AWS サービス上で稼働します。

プラットフォームの機能

BasisPilot は Amazon CloudFront から配信される React のシングルページアプリケーションで、バックエンドはすべてサーバーレス API で構成されています。アクセスはロールベースで、承認済みワークフローを操作できるユーザーもいれば、読み取り専用の可視化、インシデントのトリアージ、ステータス確認にプラットフォームを使うユーザーもいます。ダッシュボードは次の機能モジュールを提供します。

図 1 – 実際の画面からキャプチャした BasisPilot のランドスケープダッシュボード。運用値はオリジナルのままで、キャプチャ範囲にはマスキングが必要な SID、ホスト名、アカウント、IP の値は含まれていません。

Dashboard: 権限を持つチーム向けのランドスケープ全体のヘルス。システムの可用性、リソースのホットスポット、重大アラート、SLA 達成状況、クラウドインフラの概要をひと目で確認できます。

Systems: ABAP と Java の両スタックに対応したシステム単位のビュー。コンポーネントのステータス（ASCS/PAS/AAS または SCS/JAS とデータベース）、ライブメトリクス、起動/停止/再起動の操作を提供します。

Host Manager: ホストレベルの CPU/メモリ/ディスク、SAP プロセスのステータス、ファイルシステムの詳細（HANA のデータ/ログボリュームを含む）、ホストの一括操作を提供します。

Backup Status: HANA バックアップカタログ（フル/差分/増分/ログ）の可視化、ログバックアップの連続失敗の検知、RPO 違反アラートを提供します。

OS Patching: 環境ごとの AWS Systems Manager Patch Manager のコンプライアンス、パッチベースラインの承認日の自動化、パッチウィンドウ、そして承認ゲート付きの SAP を考慮した再起動オーケストレーション（SAP 停止 → 再起動 → SAP 起動）を提供します。

Cluster Status: Pacemaker/Corosync の HA クラスターのヘルス、HANA System Replication の状態、ノードのロール、フェイルオーバー履歴、安全なクラスター操作（メンテナンスモード、スタンバイ、制御されたスイッチオーバー）を提供します。

Disaster Recovery: AWS Elastic Disaster Recovery を使った DR テストのオーケストレーション。模擬訓練と実訓練、人による確認ゲートを伴うステップごとの実行、テストごとの完全な監査を提供します。

Threat Monitor: SAP のセキュリティインテリジェンス。SAP Security Audit Log による重要トランザクションの監視、HANA の監査イベント、SIEM へのエクスポート（CEF、Syslog、CSV、JSON）を提供します。

Security: SAP セキュリティベースラインのコンプライアンスを自動化。標準ユーザーのチェック、クライアント設定、プロファイルパラメータ、システムの変更可能性、HANA ユーザーのセキュリティを定期的に収集します。

Activity Log: ランドスケープ全体のすべての起動/停止/アップグレード/パッチ/ストレージ操作について、誰が何をしたかの完全な監査証跡を、実行中の操作のライブ進捗とともに提供します。

Cost & Optimization: マルチアカウントの支出トレンド、EC2 のライトサイジングと新世代インスタンスの推奨、Amazon S3 のライフサイクル分析、Savings Plans のカバレッジ、古いバックアップの削除機会を提供します。

Findings: 継続的なセキュリティ/コストのインスペクター。オープンなセキュリティグループ、古い IAM キー、暗号化されていない Amazon EBS、パブリックな S3、アイドル状態のリソース、バックアップボールトの衛生状態を検出します。

AI Assistant: 表示中のページを認識するアシスタント。SAP 運用に関する質問への回答、承認済みバックエンドツールの呼び出し、長時間実行タスクの追跡、ダウンロード可能なレポートの作成を行います。

コアプラットフォームチームを超えた共有の可視化

設計上の重要な成果の 1 つは、BasisPilot が特定の専門グループに限定されないことです。同じヘルス、インベントリ、トラブルシューティングのビューを、RBAC を通じて AWS 上でホストされるエンタープライズプラットフォームを管理または利用する他の権限を持つチームにも公開できます。読み取り専用ユーザーに対しては、システムが稼働しているか、どのコンポーネントが異常か、メンテナンスウィンドウが有効か、問題がホストリソース・バックアップステータス・プラットフォームの可用性のいずれに関係しているか、といったよくある質問にアシスタントが答えます。運用操作は、承認されたロールと承認ゲート付きのワークフローに限定されたままです。

メリットを受けるのは誰か

BasisPilot は企業内のさまざまなロールに、それぞれの責任に応じたアクセスで価値を提供します。プラットフォームから最も大きなメリットを得るのは次のグループです。

• SAP Basis およびプラットフォームエンジニア – 承認ゲート付きのワークフローを操作します。起動/停止、OS パッチ適用、カーネルおよび HANA リビジョンのアップグレード、HA クラスター操作、DR 訓練、ストレージ移行などです。
• SAP 運用担当者およびオンコール対応者 – アクショントラッカーで長時間の作業を追跡し、記憶から Runbook を組み立て直すことなく、永続化された状態に戻れます。
• アプリケーションおよびプロダクトチーム – 依存している SAP ワークロードのシステムヘルス、コンポーネントのステータス、有効なメンテナンスウィンドウを、手動更新を待たずに確認できます。
• インフラおよびサポートチーム – 読み取り専用の可視化とアシスタントを使い、アカウントやリージョンをまたいだ一次トリアージを行います。
• セキュリティおよびコンプライアンスチーム – SAP Security Audit Log のイベントを監視し、ベースラインコンプライアンスのチェックを実行し、検出結果を全社の SIEM にエクスポートします。
• FinOps およびコスト責任者 – マルチアカウントの支出トレンド、ライトサイジングの推奨、Savings Plans のカバレッジ、古いバックアップの削除をレビューします。
• 監査および変更管理の関係者 – 変更を全社の ITSM や SAP Cloud ALM と結び付ける、完全なアクティビティ証跡とエビデンスパックを活用します。

継続的な監視と SLA トラッキング

ダッシュボードの裏側では、スケジュール実行されるコレクター群が、手動ポーリングなしにランドスケープの状態を最新に保っています。

• 5 分ごとのライブメトリクス – CPU、メモリ、SAP プロセスのステータス、クラスターの状態を、SSM を通じて全ホストから並列に収集します。コレクターは EC2 の状態を認識するため、停止中のインスタンスが古い「グリーン」を表示することはありません。
• 1 時間ごとのトレンド履歴 – パフォーマンス（CPU/メモリ/ディスク/ロードアベレージ）とファイルシステムごとの使用量を、TTL による 90 日間保持の専用履歴テーブルに書き込み、推定ではなく実データに基づくトレンドチャートを実現しています。
• 5 分ごとの SLA 測定 – システムごとの可用性サンプルを、環境別の目標値（開発/テストは 99.0%、ステージングは 99.5%、本番は 99.9%）に対する月次の達成率に集計し、専用の SLA ダッシュボードに表示します。
• セキュリティおよびコンプライアンスのチェック – SAP Security Audit Log のイベントを 5 分ごと、セキュリティベースラインのコンプライアンスを 30 分ごとに確認します。
• 重大アラート – コンポーネント停止、バックアップ失敗、リソースのしきい値超過といった状態を、確認（Acknowledge）ワークフローとともにダッシュボードに表示します。

図 2 – SLA ダッシュボード

メンテナンスウィンドウ

計画停止は第一級の概念として扱われています。専用のメンテナンス API により、エンジニアは任意のシステムを個別または一括でメンテナンスウィンドウに入れることができ、開始/終了時刻、理由、担当エンジニアが記録されます。ウィンドウが有効な間はそのシステムのアラートが抑制されるため、計画作業で誰かが呼び出されることはなく、作成/更新/削除はすべて監査ログに書き込まれます。AI アシスタントもこれに関与します。現在および今後のウィンドウの一覧表示、会話による新しいウィンドウのスケジュールが可能で、アシスタント自身の長時間ワークフロー（カーネルアップグレード、パッチ適用）もメンテナンス状態を尊重・参照します。

「BasisPilot で最も感銘を受けたのは、Manish の設計と実装の独創性、深さ、完成度でした。彼はこれを既存の SAP 機能の導入や、バラバラなツールの寄せ集めとして扱いませんでした。ユーザーインターフェース、API、データベース、認証と認可、ロールベースのアクセス制御、バックエンドサービス、AI 機能、そしてそれらを責任をもって運用するために必要なガバナンスモデルを含む、エンドツーエンドのエンタープライズプラットフォームを構想し、構築したのです。このプラットフォームは、アーキテクチャを稼働させるために開発された Python、React、JavaScript にまたがる広範で深く統合されたコードベースを持つ、相当なエンジニアリングの成果です。

最も重要なアーキテクチャ上の選択の 1 つは、データおよびインテリジェンスのプレーンと、統制されたコントロールプレーンを明確に分離したことです。この分離により、ID、認可、承認、実行、検証、監査を決定論的かつ統制された状態に保ちながら、インサイトや AI 機能を進化させることができます。Manish は SAP の依存関係モデルから、AWS アーキテクチャ、アプリケーションアーキテクチャ、セキュリティモデル、実装に至るまで設計を主導しました。単に導入方法を提案するのではなく、SAP 運用の深い知見を、実際に動くクラウドネイティブなシステムへと落とし込んだのです。このアプローチの効果はすでに表れ始めており、複雑な SAP ランドスケープへの理解が深まり、より根拠のある意思決定ができるようになり、SAP に依存するビジネス運用の信頼性、レジリエンス、継続性に対する確信も高まっています。」

Anshuman Kowtha、Manager、Toyota Motor North America

難しい問題: SAP の時間は HTTP の時間に収まらない

SAP のメンテナンスイベントは、単一のコマンドで完結するものではありません。セントラルサービスを停止する前に、アプリケーションサーバーをドレインする必要があります。共有またはマルチテナントのデータベースは、依存するアプリケーションが稼働している間は停止してはなりません。SAP HANA はフラッシュして検証済みの状態に達するまで時間を要します。起動時は Amazon EC2、AWS Systems Manager、データベース、セントラルサービス、アプリケーションインスタンスの順に待つ必要があります。通常の操作でも 10〜90 分かかり、データベースやアップグレードのワークフローの中には数時間続くものもあります。これらはいずれも同期的な Web リクエストとは相容れません。

そこで BasisPilot は、リクエストの時間と操作の時間を分離しています。アクション API は、長時間の作業を開始する前に永続的なトラッカーを作成します。Amazon DynamoDB には、アクション ID、現在のフェーズ、進捗、完了した結果、承認、エラーが保存されます。ホスト側の作業は AWS Systems Manager Run Command が実行し、ダッシュボードとチャットインターフェースはどちらも同じトラッカーを参照します。Lambda 関数自身の残り時間が少なくなると、状態をチェックポイントして自分自身を非同期に再呼び出しし、ブラウザは単にトラッカーのレコードをポーリングします。同じパターンが、AI エージェントの長時間タスク、OS パッチ適用時の再起動、カーネルアップグレード、マルチテラバイト規模のストレージ移行を支えています。このフェーズベースの自己チェックポイント型の設計は、同期リクエストの時間を超える作業に対して AWS が推奨するパターンであり、これによりトヨタは接続を開いたままにすることなく、数時間に及ぶ SAP 操作を Lambda 上で実行できています。

ブラウザを閉じたり更新したりしても、SAP の停止処理が続くかどうかには影響しません。エンジニアは記憶から Runbook を組み立て直すことなく永続化された状態に戻ることができ、より長いアップグレードでは、監視のチェックポイントにより、変更をやみくもに再実行することなく観測を再開できます。

依存関係ゲートが稼働時間と制御されたダウンタイムの両方を守る

シーケンスは画面に表示されるだけでなく、コードで強制されます。停止時、BasisPilot はアプリケーションインスタンスを停止し、停止したことを検証してから、セントラルサービス、データベース、そして要求された場合は Amazon EC2 を停止します。データベースの停止を検証できない場合、インフラの停止はブロックされます。起動時はこの順序が逆になり、EC2 と Systems Manager の準備完了、データベースのヘルス、セントラルサービス、アプリケーションインスタンスの順に進みます。並列作業は安全なレイヤー内では許可されますが、順序を守るべき依存関係をまたいで行われることはありません。

BasisPilot は「コマンドが受け付けられた」ことを中間状態として扱います。成功とするには意図した結果のライブ検証が必要であり、これにより、データベース、エンキューサービス、アプリケーションプロセスがまだ完了していないのに、ランドスケープが利用可能であると報告してしまうことを防いでいます。

ダッシュボードからアシスタントまで共通のエビデンスモデル

ランドスケープダッシュボード、Systems ビュー、Host Manager、Backup Status、アクショントラッカー、AI アシスタントは、同じ運用エビデンスを異なる視点で見せるものです。システムカードはコンポーネントのロールとワークプロセスのヘルスを示します。ホストビューは CPU、メモリ、ディスク、ファイルシステム、上位プロセスを追加します。Backup Status は、フル、差分、増分、ログの各バックアップ履歴に加え、欠落、失敗、古い状態、継続性の状況を追加します。

そのため、「このシステムはメンテナンスしても安全か？」といった質問に対して、アシスタントはシステムの状態、ホストの負荷、バックアップによる保護状況、クラスターの状況、メンテナンスウィンドウ、最近のアクション履歴をまとめることができます。その後に承認済みのアクションが続く場合は、決定論的なワークフローのコードがシーケンス、認可、実行、検証、監査を制御します。生成されたテキストがシェルコマンドになることは決してありません。

ガードレールはアシスタントが「しないこと」も定義する

BasisPilot は、漠然とした質問をランドスケープ全体を調べる許可とはみなしません。たとえばバックアップステータスは、意図的に単一の SAP システムに範囲を限定しています。これは、バックアップやリカバリポイントの情報を返す前に、プラットフォームが正しい HANA データベースのホストとカタログを特定する必要があるためです。ユーザーが「バックアップステータス」とだけ尋ねた場合、アシスタントはどの SAP システムを確認するかを尋ねます。無関係なシステムを統合したり、直近の文脈から対象を推測したりはしません。

この境界は、モデルやツールが実行される前に強制されます。ユーザーがシステム ID を指定すると、リクエストは読み取り専用のバックアップツールにルーティングされます。同じ原則がすべての機能に適用されます。アシスタントは型付けされ範囲が限定されたツールへのインターフェースであり、あらゆるものを調べたり変更したりする包括的な権限ではありません。

図 3a・3b: 実際の BasisPilot チャットボットのやり取り。漠然としたバックアップステータスの要求はスコープ境界で止められ、アシスタントはバックアップデータを照会する前に SAP SID を 1 つ指定するよう求めています。マスキングしているのは例示の SID の値のみで、リクエスト、レスポンス、タイムスタンプ、画面は改変していません。

アーキテクチャ

BasisPilot はハブアンドスポーク型の設計を採用しています。中央のハブアカウントがプラットフォーム（フロントエンド、API、AI エージェント、すべての DynamoDB の状態）をホストします。スポークアカウント（ステージング、本番、DR）には実際の SAP ワークロードが含まれます。ハブからスポークへのアクセスは、厳密に範囲を限定したクロスアカウントロールへの STS AssumeRole のみを介して行われ、ホストレベルの作業はすべて AWS Systems Manager Run Command を経由します。プラットフォームが管理する操作では SSH キーもインバウンドアクセスの開放も不要です。AWS STS と AWS Systems Manager を用いたこのハブアンドスポークモデルは、クロスアカウント運用に対して AWS が推奨するアプローチに沿ったものであり、トヨタは常設の認証情報やインバウンドのネットワークアクセスなしに、すべてのスポークアカウントにアクセスできています。

以下の図では、ハブアンドスポークの全体像から、サーバーレス、AI、監視、アクションの各レイヤーへと、同じアーキテクチャを段階的に詳しく示します。続くデータフローのセクションでは、これらのコンポーネントが実行時にどのように連携するかを説明します。

図 4 – BasisPilot のリファレンスアーキテクチャ: 認証済みユーザーはサーバーレスのハブプラットフォームにアクセスし、Bedrock の AI エージェントと API Lambda は STS と AWS Systems Manager のみを通じてスポークアカウントの SAP システムに作用します。

図 5 – コンポーネントの詳細ビュー: ハブ内のサーバーレスプラットフォームの各レイヤーと、STS AssumeRole と SSM のみを通じてアクセスされるスポークアカウント内の SAP ワークロード。

データフロー

プラットフォームのレイヤー構成を踏まえると、実行時の流れは次のように追うことができます。

検出（Discovery）。フィーダー Lambda がリソースタグを使って SAP の EC2 インスタンスを検出し（1 つのデータベースが複数の SAP システムに対応するマルチテナント HANA のマッピングも含む）、DynamoDB 内のホスト/システムのインベントリを作成します。

収集（Collection）。EventBridge がコレクター Lambda をトリガーします（ライブメトリクス、クラスターの状態、SLA サンプル、セキュリティイベントは 5 分ごと、パフォーマンスとファイルシステムのトレンドは 1 時間ごと、HANA バックアップカタログは 1 日 3 回）。コレクターは SSM を通じてホスト上で読み取り専用コマンドを並列に実行し、CPU、メモリ、ファイルシステム、SAP プロセス、バックアップ、セキュリティ、SLA のデータを DynamoDB に書き込みます。コレクターは EC2 の状態を認識しており、停止中のインスタンスではキャッシュされたプロセス数を積極的にゼロにするため、ダッシュボードが古い「グリーン」を表示することはありません。

提供（Serving）。API Lambda が DynamoDB から読み取り、保護されたルートには Cognito の JWT オーソライザーを設定した API Gateway を通じて React フロントエンドにデータを提供します。EC2 の状態が常に最初に確認され、停止中のインスタンスはキャッシュされたプロセスデータよりも優先されます。

アクション（Action）。変更を伴う操作（起動/停止、パッチ適用、アップグレード、ストレージ変更）は、フェーズベースのワークフローとして実行されます。各 API 呼び出しはゲートウェイのタイムアウトより十分短く完了し、進捗は DynamoDB で追跡され、UI はトラッカーをポーリングし、停滞したフェーズは回数制限付きの冪等なリトライで自己修復します。

設計上の教訓: すべてをフェーズベースに

SAP の操作は通常 10〜90 分かかり、API Gateway や Lambda の制限をはるかに超えます。BasisPilot は長時間の操作をすべて小さなフェーズに分割し、状態を DynamoDB にチェックポイントします。Lambda は自身の残り時間が少なくなると自分自身を非同期に再呼び出しし、ブラウザ（またはチャット UI）は単にトラッカーのレコードをポーリングします。同じパターンが、AI エージェントの長時間タスク、OS パッチ適用時の再起動、カーネルアップグレード、マルチテラバイト規模のストレージ移行を支えています。

使用している AWS サービス

AI アシスタント: 制約されているからこそ役に立つ

AI アシスタントは、権限を持つエンジニア、プロダクトオーナー、サポートチームを支援するために設計されており、運用上の責任を置き換えるものではありません。Amazon Bedrock のツール使用を利用し、モデルはプラットフォームの 68 個の型付きツールのいずれかを要求できますが、アプリケーションがその要求を検証し、RBAC を確認し、承認ポリシーを適用したうえで、安全な場合にのみツールを実行します。この分離が重要です。モデルはタスクを推論する手助けはできますが、認可、検証、実行、監査の責任はプラットフォームが負い続けます。

ツールのカテゴリ

リクエストがエージェント内をどのように流れるか

インテントルーティング。 モデルがリクエストを受け取る前に、軽量なルーティングで利用可能なツールを最も関連性の高い候補に絞り込みます。これによりプロンプトの範囲が狭まり、誤ったツール選択が減ります。「はい」や「進めて」のような単純な確認は直前の保留中のアクションに紐付けられ、信頼度の高い入力（たとえば、エージェントが求めた後に指定されたカーネルメディアのパス）では、追加のモデル呼び出しの代わりに決定論的なファストパスを使用できます。

RBAC ゲート。 呼び出し元のロールは JWT のクレームから取得され、ツールに必要な権限と照合されます。閲覧者ロールは読み取り専用のままで、オペレーターおよび管理者ロールは制御されたアクションを要求できます。

承認ゲート。 環境に応じたポリシーにより、本番環境のアクション、マルチテナントのデータベースホスト、破壊的な操作は、実行されずに必ず保留中の承認が作成されます。ユーザーは何が実行されるかを正確に確認できます。カーネルアップグレードのような複雑なワークフローでは、ライブの事前チェックレポート（現行バージョンと目標バージョン、実行中のプロセス、メディアの検証）が、選択可能な確認/キャンセルボタンとともに表形式で提示された後にのみ承認が求められます。古い承認は自動的に失効します。

入力の検証。 システム ID はパターンで検証され、SSM コマンドは許可リストに登録された操作から組み立てられ、安全でないシェルのメタ文字は拒否されます。アシスタントが自由形式のシェルを受け取って実行することはありません。

実行と検証。 長時間の操作は、チャット内にライブの進捗カードを表示する非同期タスクとして実行されます。ワークフローはキャッシュされた状態を信頼するのではなく、ライブのプロセスチェックで結果を検証し、リスクの高いワークフローには、起動の検証に失敗した場合にバックアップしたカーネルを復元するといったロールバック経路が含まれています。

監査。 すべてのツール呼び出し、承認、結果は、ユーザー ID とともにアクションログに記録されます。これは Activity Log ページが表示するものと同じ証跡です。

ケーススタディ: AI アシスト型の SAP カーネルアップグレードワークフロー

代表的なワークフローの 1 つが、意図した運用モデルをよく示しています。エンジニアが主導権を保ち、アシスタントがチェックと承認済みの実行ステップを調整します。

1. エンジニアが、あるシステムのカーネルアップグレードを依頼します。アシスタントは、カーネルメディアの場所（ホストのパスまたは S3 のロケーション）を尋ねます。
2. エンジニアがパスを指定すると、決定論的なファストパスにより非同期の事前チェックが開始されます。現在のカーネルレベル、目標メディアの検証、パッチレベル混在の警告、各ホストで実行中のインスタンス、ディスク容量のチェックです。
3. アシスタントは、続行/キャンセルボタンとともに計画を表形式で提示します。この時点では何も変更されていません。
4. 承認後、ワークフローはホストごとに実行されます: メディアのステージングと展開 → 現行カーネルのバックアップ → システムのインスタンスを想定どおりの順序で停止 → デプロイ → セントラルサービスから起動 → プロセスのヘルスとカーネルレベルを検証。起動の検証に失敗した場合、ワークフローはシステムを部分的にアップグレードされた状態のまま放置せず、バックアップを復元します。
5. 旧パッチレベルから新パッチレベルへの変化やバックアップの場所を含む最終結果が、チャットに投稿され監査ログに記録されます。パイロット利用期間中、エンジニアの役割は手動の Runbook を実行することから、承認済みワークフローを監督することへと変わりました。2026 年 5 月に実施した 15 件以上のパイロットのカーネルアップグレードの観察に基づくと、システムあたりの推定所要時間は約 2.5 時間から 45 分に短縮され、約 70% 削減されました。エンジニアの実作業工数は個別には測定していません。

得られた教訓: AI ワークフローは他の自動化と共存しなければなりません。初期の社内テスト中、AI アシストによるアップグレードが成功してシステムが再起動した数分後に、停滞していたダッシュボードの停止トラッカーの自己修復リトライが発動し、競合する停止アクションが生じました。修正は表面的なものではなく体系的なものでした。システムごとのワークフローロック、リトライと承認の鮮度ウィンドウ、アクション後の再検証ウィンドウです。複数の自動化が同じランドスケープを共有する場合、リトライは状況が変わっていないと決して仮定してはならず、アクションの前に状態を再確認しなければなりません。

モデル戦略

• 階層化されたモデル: 単純なステータスの質問は低レイテンシーでコスト効率の高い Claude の階層に、調査、マルチステップのワークフロー、レポートの統合はより推論能力の高い階層に振り分けます。階層はセッション単位ではなくリクエスト単位で選択されます。
• ツールループの上限設定: 1 リクエストあたりのツール使用ターンを最大 7 回に制限し、最終ターンでは強制的に回答をまとめることで、レイテンシーとコストを予測可能に保ちます。
• 結果のキャッシュ: 読み取り専用ツールの結果はツールごとの TTL でキャッシュされ、「refresh」と言えばキャッシュを回避できます。破壊的な操作や確認済みのアクションでは、キャッシュは決して使用されません。
• 組み込みのナレッジベース: SAP Basis の Runbook（起動/停止のシーケンス、OOM 分析、スプリットブレインからの復旧、EBS の拡張手順）を Lambda にパッケージ化し、アシスタントがワークフローを推奨または開始する前に低レイテンシーで検索できるようにしています。

セキュリティとガバナンス

• ID。保護された API ルートでは JWT 検証を伴う Amazon Cognito を使用し、ユーザー ID は常にトークンのクレームから取得し、リクエストボディからは取得しません。
• 最小権限。スポークアカウントのロールは、プラットフォームが必要とする SSM と読み取りの権限のみを公開し、セッションは短期間です。
• ホストを公開しない。プラットフォームが管理する操作では SSH はゼロで、すべてのホストとのやり取りは許可リストのコマンドセットを使った監査可能な SSM Run Command です。
• 変更管理。本番環境のアクションは常に人が承認します。エビデンスパックとリリースワークフロー連携により、変更を全社の ITSM および SAP Cloud ALM のプロセスに結び付けます。
• 監査とコンプライアンス。プラットフォームが管理するリソースは全社のタグ付け標準に従い、監査ログはコンプライアンスのトレーサビリティを支え、セキュリティモジュールはイベントを標準形式で全社の SIEM にエクスポートします。
• リカバリ。リスクの高いワークフローでは、プラットフォームが対象の状態を変更する前に、安全確保のためのエビデンス（AMI、カーネルのバックアップ、スナップショット）を取得し、ロールバックの選択肢を確保します。

これらの制御を組み合わせることで、AWS のセキュリティのベストプラクティス、最小権限のスポークロール、短期間の STS セッション、Amazon Cognito によるトークンベースの ID が適用され、AI とデータのレイヤーが進化しても、トヨタは ID、認可、監査を決定論的に保つことができています。

「BasisPilot は、断片化したツールと手動の Runbook による SAP 運用を、インテリジェントで統制された 1 つの運用プラットフォームへと変革します。リアルタイムの可視化、AI アシストによる診断、制御された自動化を、エンタープライズ環境が求める承認、検証、監査可能性、ロールバックと組み合わせています。Manish のリーダーシップにより、SAP 運用の深い専門知識が、企業全体に拡張できる能力へと変わりました。」

Ashish Patel、Senior Manager、Toyota Motor North America

成果

アーキテクチャ、運用上のガードレール、人によるレビューのモデルを組み合わせることで、次のような実践的な成果が得られました。

• 1 つのプラットフォーム: BasisPilot は、SAP アプリケーション、データベース、AWS インフラの情報を、環境やアカウントをまたいで 1 つのインターフェースに集約することで、ターミナル、コンソール、スプレッドシートの間を行き来する必要を減らします。チームは、運用情報の収集と分析に費やす時間が少なくとも 20% 削減されたと見積もっています。これは、画面の切り替えが減ったことと、アシスタントがシステムのエビデンスをまとめ、エンジニアによる結果の解釈を助けることの両方を反映しています。このプラットフォームは、基盤となる SAP や AWS のサービスを置き換えるのではなく、これらのワークフローを統合するものです。
• セルフサービスの拡大: 権限を持つチームはシステムのヘルス、アラート、トラブルシューティング情報を直接確認できるため、ステータス確認のために Basis チームに頼る必要が減ります。チームの報告によると、セルフサービスの可視化を導入した後、ステータス関連のチケットが推定 25% 減少しました。この数値はシステムステータスに関する問い合わせに適用されるもので、インシデントの総数やインシデントの解決時間を示すものではありません。
• 手作業の削減: BasisPilot は、日々のヘルスチェック、SAP プロセスとホスト負荷の分析、バックアップの確認、レポート作成から、ランドスケープの協調的な起動/停止、パッチ適用、アップグレード、ストレージ変更に至るまで、SAP 運用サイクル全体の作業を支援します。エンジニアはダッシュボードと範囲を限定した AI ツールを使って、エビデンスの収集、問題の調査、サポート対象のアクションの調整を行います。プラットフォームは、これらのワークフロー内で依存関係のシーケンス、必要な承認、進捗の追跡、検証、監査記録を処理します。コスト最適化、セキュリティとコンプライアンスのチェック、高可用性と災害対策のビューも、日常的な運用レビューに必要な情報を提供します。
  パイロットでの見積もりは、この幅広い対象範囲のうち 2 つの部分を示しています。2026 年 5 月の 15 件以上のカーネルアップグレードの経験に基づくと、エンジニア 1 人・システム 1 つあたりの実作業工数は約 2.5 時間から 45 分に減少し、実作業工数が約 70% 削減されました。また別途、2026 年 3 月の 30 件以上のファイルシステム縮小の観察では、推定所要時間は以前の 3〜4 時間に対して約 1 時間となり、所要時間が約 67〜75% 短縮されました。
• より安全な運用: サポート対象の操作は、ロールベースの権限、環境に応じた承認ポリシー、監査ログ、結果のライブ検証に従います。リスクの高いワークフローにはバックアップとリカバリのステップが含まれます。たとえばカーネルアップグレードのワークフローでは、起動の検証に失敗した場合に以前のカーネルを復元できます。これらの制御は、すべての変更が自動的に元に戻せると仮定するのではなく、実装されている箇所で明確なリカバリ経路を提供します。
• サーバーレスの運用モデル: BasisPilot のプラットフォームレイヤーは、管理やパッチ適用が必要な専用のアプリケーションサーバーを持たず、マネージドな AWS サービス上で稼働します。コレクターと API は需要に応じてスケールします。2026 年 9 月 25 日時点で、チームの AWS インベントリレビューでは、プライマリのハブリージョンで BasisPilot に関連する 47 個の AWS Lambda 関数と 53 個の Amazon DynamoDB テーブルが確認されました。これらの数にはパイロットおよびレガシーのコンポーネントも含まれます。

まとめ

BasisPilot は、SAP プラットフォームの専門知識を、サーバーレスの AWS サービスと、厳格な認可・監査の制御を中心に構築された AI アシスタンスと組み合わせることで何が可能になるかを示しています。そのアーキテクチャパターン（STS と SSM によるハブアンドスポーク、フェーズベースの長時間ワークフロー、RBAC と承認ゲートの背後でのツール呼び出し、検証ファーストの自動化）は、AWS 上で大規模かつ規制の厳しいワークロードを運用する企業が応用できるものです。

はじめてみましょう

BasisPilot の背後にあるパターンは、お客様自身の SAP やエンタープライズの運用プラットフォームに導入できるマネージドな AWS サービスに基づいています。次のリソースは良い出発点になります。

• Amazon Bedrock – バックエンドツールへの統制されたアクセスを備えた、ツール呼び出し型の AI アシスタントを構築できます。Amazon Bedrock のドキュメントを参照してください。
• AWS Systems Manager – SSH を使わずに、EC2 ホスト上でエージェントレスかつ監査可能なコマンドを実行できます。
• AWS Lambda と Amazon DynamoDB – 永続的な状態追跡を伴う、フェーズベースの自己チェックポイント型ワークフローを実装できます。
• AWS STS によるクロスアカウントアクセス – 短期間で範囲を厳密に限定したロールを通じて、スポークアカウントのワークロードにアクセスできます。
• SAP on AWS – AWS 上で SAP ワークロードを実行するためのリファレンスアーキテクチャと運用ガイダンスです。

これを組織で実践するには、まず運用上の判断、つまり依存関係、承認ゲート、検証ステップをプラットフォームの振る舞いとして書き起こし、そのうえで、統制されたワークフローへの範囲を限定したインターフェースとして AI アシスタントを追加することから始めてください。

著者:

	Manish Kumar は、Toyota Motor North America（トヨタ）の SAP BTP Platform チームの Senior SAP Product Owner です。SAP のソリューションアーキテクチャ、クラウド移行、システムアップグレード、エンタープライズのモダナイゼーションにわたる経験を持ちます。BasisPilot を構想し、その設計・アーキテクチャ・実装を主導し、SAP の専門知識と、AWS 上での AI アシストによる分析および統制された運用を結び付けました。プロダクトオーナーシップと実践的なエンジニアリングを組み合わせ、信頼性、セキュリティ、人による監督を重視しています。プラットフォームが作業を準備し、すべての変更はエンジニアが承認するという考え方です。SAP BTP ソリューションアーキテクチャ、TOGAF 9、AI ガバナンス（IAPP AIGP）の認定を保有し、IEEE Senior Member および IAPP Fellow of Information Privacy (FIP) でもあります。
	Anshuman Kowtha は Toyota Motor North America の Technical Manager で、同社の SAP および AWS クラウド環境全体のプラットフォーム戦略とデリバリーを率いています。エンタープライズテクノロジーで 23 年、エンタープライズ規模の SAP ランドスケープの統括で 15 年以上の経験を持ち、オンプレミスのインフラからハイパースケールクラウドへ、レガシー SAP から S/4HANA へといった大きなプラットフォームの転換を導き、移行・変革・継続的なモダナイゼーションの期間を通じてミッションクリティカルなシステムを構築・拡張してきました。実践的な技術基盤、徹底した運用の厳格さ、ガバナンスとセキュリティへの強いこだわりをもって、企業がクラウドと ID のプラットフォームを大規模に導入できるよう支援しています。
	Ashish Patel は Toyota Motor North America の SAP Technology 担当 Senior Manager で、トヨタでの 7 年以上を含む 24 年の SAP プラットフォームの経験を持ちます。SAP および ERP プラットフォーム、クラウドインフラ、システム統合を専門とし、テクノロジー戦略をビジネスの優先事項と整合させることに注力しています。プラットフォームの信頼性向上、運用効率の改善、デジタルトランスフォーメーションの支援に向けた取り組みを率いています。そのリーダーシップは、協働、継続的改善、そして複雑な技術課題を実践的なビジネスソリューションに変えるチームの育成を重視しています。複数の SAP Technology Associate および Specialist 認定に加え、AWS Certified Solutions Architect – Associate を保有しています。
	Neill Reidy は AWS の Principal Technical Account Manager で、企業がレジリエントで運用上優れたクラウド環境を構築できるよう支援しています。Linux とネットワークで 29 年の経験を持ちます。AWS re:Invent で登壇し、複数の AWS Professional 認定を保有し、AWS Systems Manager、Amazon Connect、AWS Unified Operations、災害対策に関する AWS ブログ記事やお客様事例を執筆しています。
	Vijay Sitaram は AWS の Principal Technical Account Manager です。データベースと SAP テクノロジーを中心に IT 分野で 26 年の経験を持ち、自動車・製造業のお客様の AWS 上の SAP ワークロードのサポートリーダーを務めています。レジリエンス、コスト、運用の卓越性に重点を置き、お客様が SAP ワークロードを運用・拡張できるよう支援しています。AWS for SAP のブログ記事を複数執筆し、バックアップ、レジリエンス、および SAP 運用向けの MCP を用いた AI 主導の kiro-cli に関する AWS ワークショップを作成しました。AIOPS for SAP MCP Server のオーナーであり、AWS re:Invent の登壇者でもあります。AWS Solutions Architect Professional と GenAI Professional の認定を保有しています。余暇には CrossFit、ウェイトリフティング、マウンテンバイク、原野でのバックパッキングを楽しんでいます。

© Toyota Motor North America. 本ドキュメントは、知見共有を目的として社内ツールのアーキテクチャを説明するものです。環境固有の識別子は、トヨタの公開コンテンツガイドラインに従いすべて省略しています。AWS のサービス名は Amazon.com, Inc. またはその関連会社の商標です。SAP および SAP HANA は SAP SE の商標です。