こんにちは、SCSKでAWSの内製化支援『 テクニカルエスコートサービス 』を担当している貝塚です。 前記事では、EC2への接続記録を必ず取得するという観点から、 Session Managerのログ記録 Fleet ManagerのRDP録画 ネットワーク経由の従来型ログイン を考慮する必要があることを説明し、1. Session Managerのログ記録 について設定方法等を解説しました。 AWS Systems Manager Session Managerでの監査ログ取得 - セッションログ設定編 Systems Manager Session Managerで監査証跡を取るためにCLIの入出力ログ取得とRDP録画の導入を検討しました。 blog.usize-tech.com 2026.03.09 本記事では 2. Fleet ManagerのRDP録画設定方法について解説します。 RDP接続記録の設定 RDP接続記録とは Fleet Manager Remote Desktopを使用したRDP接続を画面録画し、S3バケットに保存する機能です。GUI操作の証跡を動画として残すことができます。 RDP接続記録を有効化するには、Just-in-time（JIT）ノードアクセスを有効化する必要があります。JITノードアクセスは、動的で時間制限付きのアクセス制御を提供する機能で、承認ポリシーベースのアクセス管理を実現します。 Just-in-time ノードアクセスの概要 Just-in-time（JIT）ノードアクセスは、以下の特徴を持つアクセス制御機能です。 動的なアクセス制御： アクセス要求時に承認ポリシーを評価 時間制限付きアクセス： 一定時間後に自動的にアクセス権限が失効 承認ポリシーベース： Cedar言語(Amazonが開発したオープンソースのポリシー言語)で記述された承認ポリシーで制御 RDP接続記録の前提条件： RDP接続記録機能を有効化するために必須 JITノードアクセスを有効化することで、RDP接続記録機能が利用可能になります。 Quick Setupの初回セットアップ JITノードアクセスを有効化する前に、Quick Setupの初回セットアップを実行する必要があります。 この記事では単一アカウント環境の場合のみを説明しています。Organizations環境には対応していないのでご注意ください。 quicksetup-init.sh スクリプト(本記事で使用したスクリプトは、記事の最後に掲載しています)を実行します。 bash quicksetup-init.sh --profile default --region ap-northeast-1 –profileにはAWS CLIを実行するプロファイル名を指定します。 このスクリプトは、CloudFormation StackSets用のIAMロール2件を作成します。 AWS-QuickSetup-StackSet-Local-AdministrationRole AWS-QuickSetup-StackSet-Local-ExecutionRole JIT有効化の手順 Quick Setupの初回セットアップ完了後、 enable-jit-node-access.sh スクリプトを実行してJITノードアクセスを有効化します。 bash enable-jit-node-access.sh --profile default --region ap-northeast-1 –profileにはAWS CLIを実行するプロファイル名を指定します。 このスクリプトは以下の処理を実行します。 1. Configuration Managerを作成 2. JITノードアクセスを有効化 3. ホームリージョン、ターゲットアカウント、ターゲットリージョンを設定 スクリプト実行後、Configuration ManagerのステータスがSUCCEEDEDになることを確認してください。 RDP接続記録の設定 JITノードアクセスの有効化後、 configure-rdp-recording.sh スクリプトを実行してRDP接続記録を設定します。 bash configure-rdp-recording.sh --profile default --region ap-northeast-1 --stack-name my-session-manager-stack –profileにはAWS CLIを実行するプロファイル名、–stack-name2には 前の記事の「AWS CloudFormationでの設定」のところで作成したスタック名  を指定します。 このスクリプトは以下の処理を実行します。 1. CloudFormationスタックからKMSキーARNとS3バケット名を取得 2. ssm-guiconnect update-connection-recording-preferences APIを使用してRDP接続記録を設定 設定完了後、以下のコマンドで設定内容を確認できます。 aws ssm-guiconnect get-connection-recording-preferences --region ap-northeast-1 承認ポリシーの作成 JITノードアクセスでは、Cedar言語で記述された承認ポリシーによってアクセス制御を行います。承認ポリシーの作成にはSystems Manager統合エクスペリエンスの有効化が必要です。Systems Managerコンソールを開き、画面上部に「新しいエクスペリエンスを有効にする」バナーが表示されている場合はクリックして有効化してください。 有効化後、承認ポリシーの作成はAWSマネジメントコンソールから実施します。 1. Systems Manager >ジャストインタイムノードアクセス に移動 2. 承認ポリシー タブを選択 3. 自動承認ポリシーを作成 をクリック 4. ポリシーステートメントを入力 5. 自動承認ポリシーを公開 ボタンをクリック 「3. 自動承認ポリシーを作成」の画面 自動承認ポリシーによるアクセスの有効期間は1時間で、変更できません。また、AWSアカウントとリージョンごとに1つの自動承認ポリシーのみ作成可能です。 以下は、特定のタグを持つノードへのアクセスを自動承認するポリシーステートメントの例です。 permit ( principal, action == AWS::SSM::Action::"getTokenForInstanceAccess", resource ) when { resource.hasTag("Project") && resource.getTag("Project") == "windows-ec2-private" }; permitステートメントの各要素は以下の通りです。 principal: アクセスを要求するユーザー。”principal,” と書くとすべてのユーザーが対象になる。’principal in AWS::IdentityStore::Group::”グループID”,’ と書くと特定のIAM Identity Centerグループに限定できる action: JITノードアクセスでは常に AWS::SSM::Action::”getTokenForInstanceAccess” resource: アクセス対象のノード when句: 自動承認の条件。resource.hasTag()やresource.getTag()でノードのタグを評価できる 設計上の留意点 1. KMSキーの要件 RDP録画の暗号化に使用するKMSキーには、以下の要件があります。 対称キー（Symmetric key）であること 暗号化と復号化（Encrypt and decrypt）用途であること 必須タグ: SystemsManagerJustInTimeNodeAccessManaged: true このタグがないと、RDP接続記録の設定時にエラーが発生します。 2. S3バケットポリシー RDP録画ファイルを保存するS3バケットのバケットポリシーには、ssm-guiconnect.amazonaws.com サービスプリンシパルが、RDP録画ファイルをS3バケットに書き込むための権限（PutObject）が必要です。 { "Sid": "ConnectionRecording", "Effect": "Allow", "Principal": { "Service": ["ssm-guiconnect.amazonaws.com"] }, "Action": "s3:PutObject", "Resource": [ "arn:aws:s3:::bucket-name", "arn:aws:s3:::bucket-name/*" ], "Condition": { "StringEquals": { "aws:SourceAccount": "account-id" } } } aws:SourceAccount条件により、特定のAWSアカウントからのアクセスのみを許可します。 3. IAMロールの権限 RDP接続を開始するユーザーには、以下の権限が必要です。(IAMロール作成は、本記事・前記事のCloudFormationテンプレートやスクリプトには含まれていません) ssm-guiconnect:StartConnection ssm-guiconnect:CancelConnection ssm-guiconnect:GetConnection kms:CreateGrant RDP接続とRDP録画の確認 ここまで完了していれば、RDP録画の準備はできています。Fleet Managerを使ってEC2インスタンスに接続(テストインスタンスが必要な場合は 前の記事 でCloudFormationを使って作成したEC2インスタンスを使用)してください。 リモートデスクトップ画面の上部に表示されている設定タブをクリックし、「S3への接続を記録」が有効になっていること、S3バケット に録画保存先のS3名が表示されることを確認してください。 リモートデスクトップ接続を終了すると、指定されたS3バケットに録画データが置かれていることを確認できるはずです。 まとめ RDP録画有効化手順についてまとめました。 次の記事では、ネットワークの面から検討・考察を行います。   スクリプト類 本記事に出てきたスクリプト類を掲載します。 quicksetup-init.sh #!/bin/bash # Quick Setup 初回セットアップスクリプト # このスクリプトは、AWS Systems Manager Quick Setupの初回セットアップを # AWS CLIを使用してプログラマティックに実行します。 # # 使用方法: # 単一アカウント環境: bash scripts/quicksetup-init.sh # Organizations環境: bash scripts/quicksetup-init.sh --enable-organizations set -e # 設定 REGION="ap-northeast-1" PROFILE="" ENABLE_ORGANIZATIONS=false # コマンドライン引数の解析 while [[ $# -gt 0 ]]; do case $1 in --profile) PROFILE="$2" shift 2 ;; --enable-organizations) ENABLE_ORGANIZATIONS=true shift ;; --region) REGION="$2" shift 2 ;; *) echo "不明なオプション: $1" echo "使用方法: $0 [--profile PROFILE] [--enable-organizations] [--region REGION]" exit 1 ;; esac done # プロファイルオプションの設定 PROFILE_OPT="" if [ -n "${PROFILE}" ]; then PROFILE_OPT="--profile ${PROFILE}" fi ACCOUNT_ID=$(aws sts get-caller-identity ${PROFILE_OPT} --query Account --output text) echo "==========================================" echo "Quick Setup 初回セットアップスクリプト" echo "==========================================" echo "アカウントID: ${ACCOUNT_ID}" echo "リージョン: ${REGION}" echo "Organizations統合: ${ENABLE_ORGANIZATIONS}" echo "" # Organizations統合の有効化（オプション） if [ "${ENABLE_ORGANIZATIONS}" = true ]; then echo "Organizations統合を有効化します..." echo "" # ステップ1: CloudFormationの信頼アクセスを有効化 echo "ステップ1: CloudFormationの信頼アクセスを有効化中..." if aws cloudformation activate-organizations-access ${PROFILE_OPT} --region "${REGION}" 2>&1 | grep -q "already activated"; then echo " 既に有効化されています" else echo " 有効化しました" fi echo "" # ステップ2: Systems ManagerとOrganizationsの統合を有効化 echo "ステップ2: Systems ManagerとOrganizationsの統合を有効化中..." if aws organizations enable-aws-service-access ${PROFILE_OPT} --service-principal ssm.amazonaws.com 2>&1 | grep -q "already enabled"; then echo " 既に有効化されています" else echo " 有効化しました" fi echo "" else echo "単一アカウントモードで実行します（Organizations統合はスキップ）" echo "" fi # ステップ3: Explorer用のIAMロールを作成（単一アカウント環境では不要） if [ "${ENABLE_ORGANIZATIONS}" = true ]; then echo "ステップ3: Explorer用のIAMロールを作成中..." else echo "ステップ3: Explorer用のIAMロールを作成中（単一アカウント環境ではスキップ）..." fi if [ "${ENABLE_ORGANIZATIONS}" = true ]; then EXPLORER_ROLE_NAME="AWS-QuickSetup-SSM-RoleForEnablingExplorer" if aws iam get-role ${PROFILE_OPT} --role-name "${EXPLORER_ROLE_NAME}" --region "${REGION}" >/dev/null 2>&1; then echo " ${EXPLORER_ROLE_NAME}: 既に存在します" else aws iam create-role \ ${PROFILE_OPT} \ --role-name "${EXPLORER_ROLE_NAME}" \ --assume-role-policy-document file://scripts/quicksetup-init/explorer-role-trust-policy.json \ --region "${REGION}" >/dev/null echo " ${EXPLORER_ROLE_NAME}: 作成しました" fi fi echo "" # ステップ4: Quick Setupサービス設定を更新 echo "ステップ4: Quick Setupサービス設定を更新中..." aws ssm update-service-setting \ ${PROFILE_OPT} \ --setting-id "arn:aws:ssm:${REGION}:${ACCOUNT_ID}:servicesetting/ssm/opsitem/ssm-patchmanager" \ --setting-value "Enabled" \ --region "${REGION}" 2>&1 | grep -q "." || echo " 設定を更新しました" echo "" # ステップ5: CloudFormation StackSets用のIAMロールを作成 echo "ステップ5: CloudFormation StackSets用のIAMロールを作成中..." # Administration Role ADMIN_ROLE_NAME="AWS-QuickSetup-StackSet-Local-AdministrationRole" if aws iam get-role ${PROFILE_OPT} --role-name "${ADMIN_ROLE_NAME}" --region "${REGION}" >/dev/null 2>&1; then echo " ${ADMIN_ROLE_NAME}: 既に存在します" else aws iam create-role \ ${PROFILE_OPT} \ --role-name "${ADMIN_ROLE_NAME}" \ --assume-role-policy-document file://scripts/quicksetup-init/administration-role-trust-policy.json \ --region "${REGION}" >/dev/null aws iam attach-role-policy \ ${PROFILE_OPT} \ --role-name "${ADMIN_ROLE_NAME}" \ --policy-arn "arn:aws:iam::aws:policy/AdministratorAccess" \ --region "${REGION}" echo " ${ADMIN_ROLE_NAME}: 作成しました" echo " IAMの整合性を待機中（10秒）..." sleep 10 fi # Execution Role用のTrust Policyを動的に生成 EXEC_ROLE_NAME="AWS-QuickSetup-StackSet-Local-ExecutionRole" EXEC_TRUST_POLICY=$(cat </dev/null 2>&1; then echo " ${EXEC_ROLE_NAME}: 既に存在します" else echo "${EXEC_TRUST_POLICY}" > execution-role-trust-policy.json aws iam create-role \ ${PROFILE_OPT} \ --role-name "${EXEC_ROLE_NAME}" \ --assume-role-policy-document file:///execution-role-trust-policy.json \ --region "${REGION}" >/dev/null aws iam attach-role-policy \ ${PROFILE_OPT} \ --role-name "${EXEC_ROLE_NAME}" \ --policy-arn "arn:aws:iam::aws:policy/AdministratorAccess" \ --region "${REGION}" rm /execution-role-trust-policy.json echo " ${EXEC_ROLE_NAME}: 作成しました" fi echo "" echo "==========================================" echo "Quick Setup 初回セットアップが完了しました" echo "==========================================" echo "" echo "作成されたリソース:" if [ "${ENABLE_ORGANIZATIONS}" = true ]; then echo " - IAMロール: ${EXPLORER_ROLE_NAME}" fi echo " - IAMロール: ${ADMIN_ROLE_NAME}" echo " - IAMロール: ${EXEC_ROLE_NAME}" echo "" echo "次のステップ:" echo " 1. JIT有効化スクリプトを実行: bash enable-jit-node-access.sh" echo "" enable-jit-node-access.sh  #!/bin/bash # Just-in-time Node Access有効化スクリプト # このスクリプトは、AWS Systems Manager Quick SetupのAPIを使用して # Just-in-time (JIT) ノードアクセスを有効化します。 set -e # 設定 REGION="ap-northeast-1" PROFILE="" # コマンドライン引数の解析 while [[ $# -gt 0 ]]; do case $1 in --profile) PROFILE="$2" shift 2 ;; --region) REGION="$2" shift 2 ;; *) echo "不明なオプション: $1" echo "使用方法: $0 [--profile PROFILE] [--region REGION]" exit 1 ;; esac done # プロファイルオプションの設定 PROFILE_OPT="" if [ -n "${PROFILE}" ]; then PROFILE_OPT="--profile ${PROFILE}" fi ACCOUNT_ID=$(aws sts get-caller-identity ${PROFILE_OPT} --query Account --output text) CONFIG_MANAGER_NAME="JITNodeAccess-${ACCOUNT_ID}" S3_BUCKET_NAME="windows-ec2-private-session-logs-${ACCOUNT_ID}" KMS_KEY_ALIAS="alias/windows-ec2-private-rdp-recording-key" echo "==========================================" echo "Just-in-time Node Access 有効化スクリプト" echo "==========================================" echo "アカウントID: ${ACCOUNT_ID}" echo "リージョン: ${REGION}" echo "S3バケット: ${S3_BUCKET_NAME}" echo "KMSキーエイリアス: ${KMS_KEY_ALIAS}" echo "" # KMSキーIDを取得 echo "KMSキーIDを取得中..." KMS_KEY_ID=$(aws kms describe-key ${PROFILE_OPT} --key-id "${KMS_KEY_ALIAS}" --region "${REGION}" --query 'KeyMetadata.KeyId' --output text) echo "KMSキーID: ${KMS_KEY_ID}" echo "" # 必要なIAMロールが存在するか確認 echo "必要なIAMロールを確認中..." ADMIN_ROLE_NAME="AWS-QuickSetup-StackSet-Local-AdministrationRole" EXEC_ROLE_NAME="AWS-QuickSetup-StackSet-Local-ExecutionRole" # Administration Roleの存在確認 if aws iam get-role ${PROFILE_OPT} --role-name "${ADMIN_ROLE_NAME}" --region "${REGION}" >/dev/null 2>&1; then echo " ${ADMIN_ROLE_NAME}: 存在します" else echo " ${ADMIN_ROLE_NAME}: 存在しません。作成が必要です。" echo "" echo "エラー: 必要なIAMロールが存在しません。" echo "Quick Setupを使用する前に、以下のロールを作成する必要があります:" echo " - ${ADMIN_ROLE_NAME}" echo " - ${EXEC_ROLE_NAME}" echo "" echo "これらのロールは、AWS Systems Manager Quick Setupの初回セットアップ時に自動作成されます。" echo "Systems Managerコンソールから「Quick Setup」を開き、初回セットアップを完了してください。" exit 1 fi # Execution Roleの存在確認 if aws iam get-role ${PROFILE_OPT} --role-name "${EXEC_ROLE_NAME}" --region "${REGION}" >/dev/null 2>&1; then echo " ${EXEC_ROLE_NAME}: 存在します" else echo " ${EXEC_ROLE_NAME}: 存在しません。作成が必要です。" echo "" echo "エラー: 必要なIAMロールが存在しません。" exit 1 fi ADMIN_ROLE_ARN="arn:aws:iam::${ACCOUNT_ID}:role/${ADMIN_ROLE_NAME}" echo "" # Configuration Definitionの作成 echo "Configuration Definitionを作成中..." CONFIG_DEF=$(cat <<EOF { "Type": "AWSQuickSetupType-JITNA", "LocalDeploymentAdministrationRoleArn": "${ADMIN_ROLE_ARN}", "LocalDeploymentExecutionRoleName": "${EXEC_ROLE_NAME}", "Parameters": { "HomeRegion": "${REGION}", "TargetAccounts": "${ACCOUNT_ID}", "TargetRegions": "${REGION}" } } EOF ) echo "Configuration Definition:" echo "${CONFIG_DEF}" | jq . echo "" # Configuration Managerの作成 echo "Configuration Managerを作成中..." set +e RESPONSE=$(aws ssm-quicksetup create-configuration-manager \ ${PROFILE_OPT} \ --name "${CONFIG_MANAGER_NAME}" \ --description "Just-in-time Node Access configuration for Windows EC2 instances" \ --configuration-definitions "${CONFIG_DEF}" \ --region "${REGION}" \ --output json 2>&1) EXIT_CODE=$? set -e echo "終了コード: ${EXIT_CODE}" echo "レスポンス:" echo "${RESPONSE}" echo "" if [ ${EXIT_CODE} -eq 0 ]; then echo "成功: Configuration Managerが作成されました" MANAGER_ARN=$(echo "${RESPONSE}" | jq -r '.ManagerArn') echo "Manager ARN: ${MANAGER_ARN}" else echo "エラー: Configuration Managerの作成に失敗しました" exit 1 fi echo "" echo "==========================================" echo "Just-in-time Node Access の有効化が完了しました" echo "==========================================" echo "" echo "次のステップ:" echo "1. Systems Manager コンソールで設定を確認" echo "2. 承認ポリシーを作成（自動承認または手動承認）" echo "3. EC2インスタンスへのアクセスをテスト" echo "" configure-rdp-recording.sh #!/bin/bash # RDP接続記録設定スクリプト（オプトインログ記録機能用） # このスクリプトは、Fleet Manager RDP接続の記録設定を行います # 新しいスタック（windows-ec2-private-vpc-opt-in）用 set -e # 設定 REGION="ap-northeast-1" STACK_NAME="windows-ec2-private-vpc-opt-in" PROFILE="" # コマンドライン引数の解析 while [[ $# -gt 0 ]]; do case $1 in --profile) PROFILE="$2" shift 2 ;; --region) REGION="$2" shift 2 ;; --stack-name) STACK_NAME="$2" shift 2 ;; *) echo "不明なオプション: $1" echo "使用方法: $0 [--profile PROFILE] [--region REGION] [--stack-name STACK_NAME]" exit 1 ;; esac done # プロファイルオプションの設定 PROFILE_OPT="" if [ -n "${PROFILE}" ]; then PROFILE_OPT="--profile ${PROFILE}" fi echo "==========================================" echo "RDP接続記録設定スクリプト（オプトインログ記録機能用）" echo "==========================================" echo "スタック名: ${STACK_NAME}" echo "リージョン: ${REGION}" echo "" # CloudFormationスタックから情報を取得 echo "CloudFormationスタックから情報を取得中..." ACCOUNT_ID=$(aws sts get-caller-identity ${PROFILE_OPT} --query Account --output text) KMS_KEY_ARN=$(aws cloudformation describe-stacks \ ${PROFILE_OPT} \ --stack-name "${STACK_NAME}" \ --region "${REGION}" \ --query 'Stacks[0].Outputs[?OutputKey==`RDPRecordingKMSKeyArn`].OutputValue' \ --output text) S3_BUCKET_NAME=$(aws cloudformation describe-stacks \ ${PROFILE_OPT} \ --stack-name "${STACK_NAME}" \ --region "${REGION}" \ --query 'Stacks[0].Outputs[?OutputKey==`SessionLogsBucketName`].OutputValue' \ --output text) echo "アカウントID: ${ACCOUNT_ID}" echo "S3バケット: ${S3_BUCKET_NAME}" echo "KMSキーARN: ${KMS_KEY_ARN}" echo "" # 値の検証 if [ -z "${KMS_KEY_ARN}" ] || [ -z "${S3_BUCKET_NAME}" ]; then echo "エラー: CloudFormationスタックから必要な情報を取得できませんでした" echo "スタック名が正しいか確認してください: ${STACK_NAME}" exit 1 fi # 既存の設定を確認 echo "既存のRDP接続記録設定を確認中..." set +e EXISTING_PREFS=$(aws ssm-guiconnect get-connection-recording-preferences \ ${PROFILE_OPT} \ --region "${REGION}" \ --no-cli-pager 2>&1) EXIT_CODE=$? set -e if [ ${EXIT_CODE} -eq 0 ]; then echo "既存の設定が見つかりました:" echo "${EXISTING_PREFS}" | jq . echo "" echo "既存の設定を上書きしますか？ (y/N)" read -r RESPONSE if [[ ! "${RESPONSE}" =~ ^[Yy]$ ]]; then echo "処理を中止しました" exit 0 fi echo "" fi # RDP接続記録設定を更新 echo "RDP接続記録設定を更新中..." # JSONペイロードを作成 PAYLOAD=$(cat <&1) EXIT_CODE=$? if [ ${EXIT_CODE} -eq 0 ]; then echo "成功: RDP接続記録設定が更新されました" echo "${RESPONSE}" | jq . else echo "エラー: RDP接続記録設定の更新に失敗しました" echo "${RESPONSE}" exit 1 fi echo "" echo "==========================================" echo "RDP接続記録設定が完了しました" echo "==========================================" echo "" echo "設定内容:" echo " - S3バケット: ${S3_BUCKET_NAME}" echo " - KMSキー: ${KMS_KEY_ARN}" echo "" echo "次のステップ:" echo " 1. Fleet Manager > Managed nodes に移動" echo " 2. 対象のEC2インスタンスを選択" echo " 3. Node actions > Connect > Remote Desktop を選択" echo " 4. RDP接続をテスト" echo " 5. 接続終了後、S3バケットに記録が保存されることを確認" echo "" echo "S3バケット内の記録を確認:" echo " aws s3 ls s3://${S3_BUCKET_NAME}/ --recursive --region ${REGION}" echo ""

はじめに チューリングのVLAチームでエンジニアをしている横井です。経済産業省およびNEDOが推進するプロジェクト「GENIAC」第3期の支援のもと、自社で開発したVLM「Heron」を土台に将来の走行軌跡を出力する 自動運転VLAモデル「DriveHeron」 をチームで開発しました。本記事では、DriveHeronを自動運転システムに統合し、リアルタイムで車両を制御できるようにした取り組みを紹介します。 https://youtu.be/bv90MHM74IY E2EモデルからVLAモデルへ 自動運転で難しいのはカメラに映る情報を解釈し、交通規範や状況に照らして次の行動へ落と

はじめに はじめまして。介護/障害福祉事業者向け経営支援「カイポケ」の事業部でCS職（カスタマーサクセス/サポート）をしているTSUNOです。カイポケに携わって10年以上になります。 エンジニアではありません。プログラミングの経験もありませんでした。 そんな私がAIを活用して業務自動化ツールを開発した結果、 月17.7時間の工数削減 と 購買判断の適正化 を実現しました。 この記事は、非エンジニアのCS職がAIで業務自動化を進めた実践記です。AIでここまでできるんだ、という実感を持ってもらえたら嬉しいです。 なぜやろうと思ったのか カイポケのCSでは、お客様からの問い合わせ対応だけでなく、カイポケを利用するうえでの事務手続きまで、お客様の業務を幅広く支えています。 2024年11月、業務体制の変更にともない、新たに業務を引き継ぐことになりました。 この業務は完了までに多くのステップがあります（下図）。引き継いだのはそのフェーズ2の部分でした。 複雑な作業を、ひたすら繰り返す。通常業務にこれらが上乗せされる状況では、とてもではないですが手が回りません。ちょうどその頃、無料版のChatGPTで簡単なGoogle Apps Script（GAS）を書く体験をしていました。もっと本格的にプログラムで業務を改善できるのではないか——そう考え始めたのが、すべての出発点です。 AI活用のステップアップ 最初から有料ツールを使っていたわけではありません。 無料ツールで小さく始めて、成果が出たら次のステップへ。その繰り返しで、気がつけば本格的な開発環境が整っていました。 大事なのは、 最初から大きな投資をする必要はない ということです。 時期 やったこと きっかけ 2024年1月〜 無償版ChatGPTでAI活用を開始 AI活用への興味 2024年11月〜 GASで業務自動化に着手 業務効率化の必要性が高まった 2025年1月頃 Google Workspace標準搭載のGeminiを活用 会社の環境変化 2025年11月 Claude Codeで本格的な開発へ AIツールの比較・検証を経て 2025年12月 Claude MAXプランへグレードアップ ROIを上司に提示して承認 ※ 各時期は筆者が知った・使い始めたタイミングであり、サービスのリリース時期とは異なります。 AI活用の情報収集は多方面から行いました。 X YouTube Google CloudユーザーコミュニティのJagu'e'r ※ Jagu'e'r （ジャガー） とは、Google Cloudユーザー企業が企業の垣根を超えて最新技術やノウハウを共有し合い、クラウド活用の変革を推進する公式コミュニティです。 特にJagu'e'rの無料ハンズオンセミナーでVertex AIに触れたことが、「APIを通じてAIを使う」というイメージを掴むきっかけになりました。この体験が後述するデータ移行支援ツールの技術選定につながりました。こうした外部の学びの場に加え、最近では社内エンジニア主催のClaude Code活用ナレッジ共有会にも参加しました。 よくわからなくても飛び込んでみると、新しい発見があるものです。 生成AIを使った3つの取り組み ここからは、AIを活用して取り組んだ3つの事例を紹介します。 # 事例 概要 1 GAS + 業務フローの見直し 6時間→2時間に圧縮 2 介護保険請求の事務手続きRPA※ 月17.7時間の工数削減 購買判断の適正化 3 AI駆動で開発中のデータ移行支援ツール 帳票の自動解析とデータ整形 ※ RPA（Robotic Process Automation）：人がブラウザやアプリ上で行う操作をプログラムで自動化する技術 1．最初の成功体験 — GASで6時間の業務を2時間に AI活用で最初に取り組んだのは、GASによる業務自動化です。 コードは主にChatGPTで生成・修正しました。自分でゼロから書いたわけではなく、「こういう処理がしたい」とAIに伝えて、出てきたコードを実行し、うまくいかなければエラーメッセージをAIに貼って修正する——このサイクルを回すことで、コードは着実に動くものになっていきました。 結果、1日あたり約6時間かかっていた業務が約2時間に圧縮されました。ただし、これはGASによる自動化だけの効果ではなく、業務フロー全体の見直し（不要な手順の廃止や作業順序の組み替え）との合算です。GAS単体の削減効果として切り出せる数字ではありませんが、ツールを作ること自体が業務を棚卸しするきっかけになったという意味で、大きな一歩でした。 2．介護保険請求の事務手続きRPA — 業務自動化の本格展開 前述の業務見直しの過程で「GASでは解決できない業務」も浮き彫りになりました。業務の中には、介護保険の請求手続きに使う外部システム上で、ログイン・画面操作・帳票出力といったブラウザ操作を行う工程が含まれていました。 このシステムには外部からプログラムで連携するための仕組み（API）が提供されておらず、ブラウザを人の手で操作するしかありません。こうしたブラウザ操作はGASの守備範囲外であり、自動化するにはブラウザそのものを操作するRPAが必要でした。 なお、外部システムをRPAで操作するにあたっては、利用規約の確認や社内のリスクマネジメント部門への事前相談を行ったうえで開発を進めています（詳細は後述の「外部システムを操作する上での配慮」で触れます）。 介護事業所がカイポケを通じて介護保険を請求するには、このシステム上で各種手続きを行う必要があります。これらの作業は、全都道府県にわたる多数のアカウントに対して日々行われます。 以前にもこの業務を自動化するRPAツールが作られたことがありました。しかし、運用環境の変化に対応しきれなくなり、最終的に役割を終えていました。業務は再び手作業に戻っていたのです。 GASで積み重ねた成功体験が、「自分で作ろう。エラーが出ても、AIに聞きながら対処できる」という確信を支えていました。 成果①：月17.7時間の工数削減 RPAによる自動化で、月に17.7時間（稼働日20日/月換算で、1日あたり53分）の業務時間が削減されました。2026年1月時点の実績です。これらの業務はお客様の増加とともに件数が増える傾向にあり、今後さらに削減効果が拡大する見込みです。 数字には表れない変化もあります。以前はルーチン対応で手一杯でしたが、時間が生まれたことで、お客様への進捗報告をより適切な頻度で届けられるよう設計し直す余裕ができました。自動化の本当の価値は、 削減した時間そのものではなく、その時間で何ができるようになるか にあると感じています。 成果②：購買判断の適正化 工数削減以上にインパクトが大きかったのが、購買判断の適正化です。 従来の運用では、外部システムにログインして処理件数を一つひとつ確認する必要があり、全体の正確な把握が困難でした。そのため、実態より多めにアカウントを購入せざるを得ない状況が続いていました。 RPAがこのログインと件数取得を自動で行うようになったことで、実際の利用状況が正確に見えるようになり、不要なアカウント購入を回避してコスト適正化を実現しました。 こうした削減効果の見込みをROIとして上司に提示し、AIツールの上位プランの利用承認を得ました。承認後の実績データでもその効果が裏付けられています。「ツールの利用料に対して、これだけの時間が浮く」という説明は、社内で予算を取るうえで有効でした。 データが見えるようになると、正確な判断ができる と実感した出来事でした。 3．AI駆動で開発中のデータ移行支援ツール データ移行支援ツールは、RPAと並行して開発を進めてきたもう一つのプロジェクトです。現在は検証フェーズであり、RPAのような確定した成果はまだありません。ここでは「完成していなくても、非エンジニアがAIと一緒にここまで到達できる」という過程をお伝えします。 何を解決するツールか カイポケを導入いただく際、お客様がこれまで蓄積してきたデータを、カイポケに登録したいというニーズがあります。その際、帳票（PDF）を目視で読み取り、手作業で転記する。これは時間がかかるだけでなく、ミスが起きやすい作業です。 データ移行支援ツールは、この帳票をAI（Geminiをチャット画面ではなくAPI経由で利用）で自動解析し、カイポケに取り込める形式に変換する仕組みです。 Geminiアプリから始まり、Claude Codeで成長した 最初はGeminiアプリのチャット画面上で、1つのプログラムファイル（.py）にコードを書いていく形でスタートしました。「この帳票のこの項目を読み取って」「エラーが出たから直して」とやり取りしながら、少しずつコードを育てていきました。 しかし、コードが1,600行を超えたあたりで限界が来ました。チャットが一度に扱える文脈の範囲（コンテキスト）にコード全体が収まりきらなくなり、修正のたびに前後関係が途切れるようになったのです。 そこで切り替えたのが「Claude Code」という、テキスト入力で操作する開発ツールでした。プロジェクト全体のファイルを把握しながら、エージェントのように自律的にコードを編集・実行してくれます。 Claude Codeに切り替えてからは開発速度が大幅に上がり、1,600行の単一ファイルだったコードは、役割ごとにファイルを分けた9,300行超の構成にまで成長しています。 時点 規模 開発環境 初期 約1,600行・単一の.pyファイル Geminiアプリのチャット画面 現在 約9,300行 + テスト約1,800行・複数ファイル構成 Claude Code AIに任せる部分と、任せない部分 開発を進める中で、正確性の高いデータソースを優先する設計にたどり着きました。介護保険の請求データは、仕様書でCSV形式として定義されています。これらはCSVから確実に取得し、CSVでは得られない情報だけを帳票PDFからAIに読み取らせる「ハイブリッド方式」を採用しています。 CSV形式で確実に取得できるデータを、あえて精度にばらつきのあるAI読み取りに回す理由はありません。AIは帳票の読み取りで誤認識を起こすことがあるため、確実な手段があるならそちらを優先する。どのデータをどの方法で取得するかの線引きにも、ドメイン知識が活きています。 ※ 個人情報を含むデータのAI処理にあたっては、エンタープライズ向けのセキュアなサービスを利用しています。 現在地 開発環境での検証を経て、クラウド上で動くWebアプリとして構築し、ブラウザからアクセスできる状態にまで持ってきました。前述のハイブリッド方式は、実データを用いた検証でも一定の精度で動作することを確認しています。現在は様々なパターンのプロンプト（AIへの読み取り指示）を調整しながら、対応できる帳票の種類を増やしているところです。自分以外のメンバーが使える状態にすることは今後の課題です。 完成にはまだ時間がかかりますが、非エンジニアによる業務改善の新しい可能性を示せたと考えています。ここからは、3つの事例を通じて得た実践的な学びを共有します。 非エンジニアがAI駆動開発を進めるためのプラクティス 非エンジニアがAIを活用して成果を出すためには、具体的な手法の前に、まずベースとなる「心構え」からお伝えします。 まず押さえておきたい4つの心構え 1. プログラミング経験より、深い業務フロー理解 業務を深く理解し、常に改善点を模索すること。 2. 人間は「要件定義と判断」、AIは「実装担当」 「何を作るか」「どんなエラーが危険か」「どのデータをAIに任せてはいけないか」。こうした判断は人間の役割です。具体的な指示を出し、AIをコントロールすること。 3. AIの出力は「たたき台」として受け取る AIは自信満々に間違えることがあります。コードの中身をすべて理解するのは難しくても、「この修正で何が変わった？」「意図した設計になっている？」とAIに確認することはできます。複数のAIにクロスチェックさせるのも有効です。鵜呑みにせず、自分の言葉で問いかける習慣を持つこと。 4. 小さく始めて、成果を積み重ねる 小さな自動化の成功体験が、次の挑戦への自信と原動力になりました。まずは手を動かしてみること。 実践＆組織で進めるための6つのプラクティス 心構えを土台として、私が実際にやってきた中で「これは他の人にも再現できる」と感じた具体的なアクションを6つにまとめました。 カテゴリ # プラクティス ひとことポイント 実践 1 AIへの指示は「業務の言葉」でいい 専門用語より「何を・なぜ・どうしたいか」 2 エラーは壁ではなく、手がかり エラーメッセージをAIに貼るだけで前に進める 3 テストもAIに書いてもらう ただし「業務的に正しいか」は人間が考える 4 環境構築は「AIに聞く → 裏取り → セキュリティ確認」 シャドーITを避ける手順を省かない 組織 5 成果を数字で見せて、リソースを得る ROIで上司の承認を得る 6 外部システムを操作する上での配慮 利用規約・社内承認・負荷配慮 1. AIへの指示は「業務の言葉」でいい プロンプトエンジニアリングだと身構える必要はありません。大事なのは、 業務の文脈を丁寧に伝えること です。データ移行支援ツールの開発初期に私がAIに伝えたのはこんな内容でした。 専門用語は一切使っていませんが、「何を・なぜ・どうしたいか」が明確なので、AIはセキュリティ設計、並列処理、エラーハンドリング、コスト表示まで一度に提案してくれました。「個人情報はログに出ないようにして」——こうした発想は、業務で日常的に個人情報を扱い、その重みを知っているからこそ生まれるものです。AIの出力品質を左右するのは、プログラミングの知識ではなく業務の知識です。 ただし、AIに任せきりでいい部分と、人間が厳密に設計しなければならない部分はあります。外部システムの仕様書を読み込み、帳票にどのような値が入ってくるのかを整理した上で読み取りのロジックを設計する——ここは業務を知っている人間が責任を持つ領域です。 2. エラーは壁ではなく、手がかり 非エンジニアにとって最大の壁は、エラーが出たときの対処です。でもやることは簡単で、 エラーメッセージをそのままAIに貼る だけです。実際の開発では、エラー対処を段階的にレベルアップさせていきました。 まず貼る — エラーメッセージをAIに貼って「これどうすればいい？」と聞く。大抵はこれで解決策が返ってくる 戦略を作る — エラーの種類ごとの対処方針をAIと一緒に設計する 仕組み化する — エラー発生時に画面キャプチャやHTML、処理ログを自動取得し、原因特定を容易にする ひとつ注意しておきたいのは、エラーは自分のコードだけから起きるわけではないという点です。Pythonのバージョンアップをしたところ、コードを一切変えていないのに、ライブラリが未対応でツールが動かなくなった経験もあります。「動いているものを維持する」難しさも学びでした。 3. テストもAIに書いてもらう 「このコードが正しく動くか確認するテストを書いて」とAIに頼めばテストコードは生成してくれます。ただし、AIが自動生成するのは「コードが技術的に正しいか」の確認です。 「業務的に正しいか」を確認するテストは人間が考える必要があります 。 たとえば「処理が中途半端な状態のまま放置されていないか」というテストシナリオは、実際の運用リスクを知っている人間にしか発想できません。AIに「こういうケースをテストしたい」と伝えれば、コード自体は書いてくれます。 4. 環境構築は「AIに聞く → ネットで裏取り → セキュリティ部門に確認」 必要なライブラリやセットアップ手順をAIに聞き、全体像を把握します。次にライセンス形態や開発元の信頼性をネットで裏取りします。その上で、社内のセキュリティ部門に「このツールを導入してよいか」確認します。 たとえばライブラリ導入時は、ライセンスが商用利用可能であること、開発元が信頼できることを確認した上で社内の専門部署に確認を取る——この手順を省かず、シャドーIT（会社の管理部門を通さずにツールを導入すること）を避けることが、長く使える仕組みにするための土台になります。 5. 成果を数字で見せて、リソースを得る 非エンジニアが業務時間を使って開発を進めるには、上司の理解が不可欠です。前述のとおり、削減効果を数字で示すことで上位プランの承認を得ました。 段階的にスケールし、各段階で成果を見せていくことで、次のチャレンジへの許可を得やすくなります。 6. 外部システムを操作する上での配慮 RPAの開発着手前に、以下の確認・配慮を行いました。 利用規約の確認 — RPAによる自動操作が明示的に禁止されていないことを確認 robots.txtの確認 — 対象システムにrobots.txt（RPAによるアクセス範囲を示すファイル）は設置されていないことを確認 社内承認 — リスクマネジメント部門に事前相談し、問題ないとの確認を取得 負荷への配慮 — 人間が操作するのと同等の速度で動作させ、未知のエラー発生時には自動停止する設計 おわりに — 属人化しない自動化を目指して 「あなたがいなくなったらどうなるの？」 ——避けられない問いです。実際、過去に社内で作られたRPAも引き継ぎがうまくいかず使われなくなった経緯があります。だからこそ、トラブルシューティングガイドや運用手順書といったドキュメントを整備するようにしています。そして何より、 AIがメンテナンスの「通訳」になれる 可能性に期待しています。コードを読めなくても、AIにエラーメッセージを貼れば対処法が返ってくる。作った人がいなくなっても回せる仕組みを作ること——その「属人化しない自動化」を目指して、今も試行錯誤を続けています。 データ移行支援ツールはまだ完成していません。模索中のことも多くあります。でも、非エンジニアだからこそ「使う側の目線」で作れる強みがある。業務を深く理解した人間にしか書けない要件定義がある。そしてAIが、その要件定義をコードに落とし込んでくれる。 自分で作るようになって、大きな気づきがありました。先述のPythonアップデートで動かなくなった経験を通じて、社内のエンジニアがフレームワークや基盤の更新に日々取り組む大変さを、身をもって理解できました。大規模なシステムを止めずに改善し続けるエンジニアの仕事に対する解像度が上がったことで、協業の質も変わったと感じています。非エンジニアが自分で作る経験は、エンジニアとの共通言語を増やすことにもつながるのです。 この記事を読んで、「自分もやってみよう」と思ってくれる方が一人でもいたら、書いた甲斐があります。最初の一歩は、「AIで何ができるか」を考えることではありません。「こんな作業が大変なんだよね」と、AIに壁打ちしてみること。そこに、活用のヒントがあるかもしれません。 追伸： 実はこの記事自体も、大部分をAIに書いてもらっています。構成案の作成、文章の推敲、さらには実際のプログラムと記事の内容に食い違いがないかの確認まで、AIと一緒に進めました。 ただし、「何を伝えたいか」「どんなストーリーで読者に届けるか」——その核となる設計は、自分の頭で考えました。AIは優秀な道具ですが、魂を込めるのは人間の仕事です。ツール開発もブログ執筆も、そこは変わらないと思います。