【AI文芸】田辺の日常 - AWS VDI管理編

2025年2月10日 08:16

ChatGPTが書いた別の話で業務がAWS VDI管理という設定になってて具体的にどういう業務なのか分からなかったのでChatGPTに書いてもらったものです。
基本的にo1で作っていますが、o1が登場させた玲奈はキャラが違っていたので4oでリテイクして事件の中身ごと差し替えました。

１日目

06:00 – 目覚めから始まる一日

朝のアラームが鳴る。スマホの画面には「AWSメンテナンス作業日」というカレンダーの通知が光っている。
田辺は「うう……もう6:45か」と呟きながら布団をどけて起き上がる。いつもならもう少し寝ていたいところだが、今日はAmazon WorkSpacesの定期メンテナンスを実施する日。何かトラブルが起きないとも限らない。早めに出社して準備をしなくては。

着替えを済ませ、テレビのニュースを流しながら電子レンジで温めた冷凍パスタをかきこむ。コーヒーサーバーにセットしておいた豆が自動で挽かれ、香りが部屋を満たす。「あー、コーヒーうまい」と一息つきながら、スマホでSlackの通知をチェック。#aws_opsチャンネルには夜中のうちに飛び交ったメッセージが10件以上。「嫌な予感しかしない…」と、少し胸騒ぎを覚える。

07:15 – オフィスへ移動

電車に揺られながら、田辺は会社支給のMacBookを開き、AWSコンソールをチェックする。耳にはワイヤレスイヤホンを装着し、同僚からのボイスメッセージを再生。

田辺さん、おはようございます。夜中にWorkSpacesのクローン作成が失敗して、動かない状態のユーザーが何名かいるっぽいです。あとで詳しく話しましょう。

クローン作成というのは、WorkSpacesのイメージを使って新しいVDI環境を量産する作業のこと。新入社員が多い時期にはよくやる作業だが、たまにバンドル設定やディレクトリ連携で引っかかることがある。
田辺はSlackに短く返信する。

了解です。オフィス着いたら確認しますー

電車は田町駅に到着。人混みをかき分けながら改札を抜け、オフィスビルへ向かう。外は曇り空だが、雨はまだ降っていない。

08:00 – 早朝出社

オフィスに着くと、まだ人はまばら。エンジニアはフレックス制のメンバーが多いので、8時台に来るのは管理者の田辺くらいだろう。
セキュリティゲートを通り、エレベーターでフロアに上がる。執務室の照明をつけて、自分のデスクに荷物を置く。まずはコーヒーを淹れてから……と思ったが、急ぎ確認したいことがある。

MacBookを開き、AWSコンソールのAmazon WorkSpacesダッシュボードにアクセス。夜中の作業ログを確認する。

CloudTrail で該当の操作（CreateWorkspaces）が失敗している時間帯をチェック
Event History からエラーコードや呼び出されたAPIをひと通り閲覧

aws workspaces describe-workspaces \
  --query 'Workspaces[*].[WorkspaceId,State,UserName]'

コンソールのブラウザで確認するだけでなく、CLIでも軽くステータスを取り出してみる。すると、下記のようなステータスが散見される。

[
  ["ws-1234567890abcdef", "ERROR", "fujita.kouhei"],
  ["ws-abcdef1234567890", "ERROR", "nakamura.yuri"]
]

「ERROR…」と渋い顔になる田辺。理由を調べると、夜中のバッチ処理中にディレクトリ登録がうまくいかなかったらしい。ディレクトリサービス（AWS Managed Microsoft ADまたはオンプレAD）との連携に不具合があった場合、WorkSpacesのプロビジョニングが止まってしまう。
「とりあえず再作成か……」とつぶやき、失敗しているWorkSpacesを削除して再度作り直すコマンドを用意する。

# 失敗したWorkSpacesを削除
aws workspaces terminate-workspaces --terminate-workspaces-request \
'[
  {"WorkspaceId": "ws-1234567890abcdef"},
  {"WorkspaceId": "ws-abcdef1234567890"}
]'

# 新規作成コマンド（簡易例）
aws workspaces create-workspaces --workspaces \
'[
  {
    "DirectoryId": "d-9067xxxxxx",
    "UserName": "fujita.kouhei",
    "BundleId": "wsb-xxxxxxx",
    "WorkspaceProperties": {
      "RunningMode": "AUTO_STOP"
    }
  },
  {
    "DirectoryId": "d-9067xxxxxx",
    "UserName": "nakamura.yuri",
    "BundleId": "wsb-xxxxxxx",
    "WorkspaceProperties": {
      "RunningMode": "AUTO_STOP"
    }
  }
]'

Slackで担当メンバーに報告。

夜中のWorkSpaces新規作成失敗、ディレクトリ連携にミスあり。手動で削除して再度作りました。  
後ほど検証お願いします～

そして一息ついて、ようやくオフィスのカフェスペースでコーヒーを淹れる。

08:30 – 朝会 & セキュリティチェック

8:30になると、チームのメンバーが徐々に出社してくる。立ち話レベルの朝会が始まる。田辺は昨夜～今朝にかけてのWorkSpacesトラブル報告と対応状況を共有。
同時に、最近増えているランサムウェアやフィッシングへの対策強化についても話し合う。WorkSpaces上でエンドユーザーが勝手にソフトを入れられないよう、イメージ管理やAppLockerの設定を見直す予定がある。

田辺は会議室に入る前、CloudWatchのアラーム一覧をチェックする。赤く表示されているのは以下のアラーム：

CPUUtilization > 85% が30分継続
SessionLatency > 200ms が10分継続

「どのWorkSpacesだ？」と思い、詳細を見ると、昨日も遅延が話題になった山田の環境がまた引っかかっている。

09:00 – 即席トラブルシュート

田辺は会議室を出た後、Slackで山田にメンションする。

@yamadataro おはようございます。またWorkSpacesが重いですか？Latency 200ms越えのアラームが出ています

山田から返信：

またTeamsが重いんですよ……  
ミーティング中にカメラONだとCPU100%近くなるんです

「やっぱTeamsかよ」と苦笑いしながら、CLIで状況を把握するコマンドを打つ。

aws workspaces describe-workspaces --workspace-ids ws-xxxxxxxxxxx

{
  "Workspaces": [
    {
      "WorkspaceId": "ws-xxxxxxxxxxx",
      "State": "AVAILABLE",
      "UserName": "yamada.taro",
      "IpAddress": "203.0.113.42",
      "BundleId": "wsb-xxxxxxx"
    }
  ]
}

さらに、AWS Systems Manager を使ってWorkSpaces内のプロセスを確認できるスクリプトを流す。

aws ssm send-command \
  --document-name "AWS-RunPowerShellScript" \
  --targets "Key=InstanceIds,Values=ws-xxxxxxxxxxx" \
  --parameters 'commands=["Get-Process | Sort-Object -Descending CPU | Select-Object -First 5 | Format-List"]'

結果を受け取ってみると、案の定Teams.exeとTeamsHooks.exeがCPUの半分以上を占拠している様子が出てくる。音声・ビデオ通話が多いとTeamsが暴走することがある。

田辺はWorkSpacesのスペック（Bundle）を1ランク上げることを検討。ModifyWorkspacePropertiesを使い、PowerからPerformanceへ、またはPerformanceからPowerへ変更する。

aws workspaces modify-workspace-properties \
  --workspace-id ws-xxxxxxxxxxx \
  --workspace-properties '{"ComputeTypeName":"POWER"}'

Slackで山田に連絡する。

Teams会議が多いならスペックを上げておきます。  
30分くらいで適用されるんで、その後また確認をお願いします。

山田：「助かります！」

10:00 – スクリプトメンテ＆モニタリング強化

作業が一段落したところで、今度はモニタリングを強化するためのスクリプトに手を入れる。WorkSpacesのログをまとめてAmazon S3に集約し、そこからAmazon Athenaでクエリできるようになっている仕組みだが、最近クエリが遅くなってきた。データ量が増えている証拠だ。

田辺はGitHub Enterprise上のリポジトリを開き、社内で運用しているTerraformコードをチェック。CloudWatch Logs→S3エクスポート部分の設定に改修が必要かもしれない。

CloudTrail ログや WorkSpaces Access Logs をS3に集める
Glue のCrawlerを定期実行し、Athenaからスキーマを認識させる
さらにQuicksightで可視化するかどうか検討

田辺はTerraformファイルを開いてPull Requestを作成。ファイルの中で、ログの保持期間やパーティション分割の見直しを行う。

resource "aws_cloudwatch_log_group" "workspaces_log_group" {
  name              = "/aws/workspaces/connection"
  retention_in_days = 30
}

# ... S3エクスポートの定義など ...

「これでちょっとは処理が軽くなるかな」と思いながら、同僚にレビューを依頼する。

11:30 – 来客対応 & セキュリティ監査の一幕

今日の午前は、外部の監査チームがオフィスにやってくる日でもある。SOC2やISO27001の対応で、クラウド上のVDI環境のログやアクセス管理が適切かどうかチェックされるのだ。

会議室で監査担当と30分ほど打ち合わせし、必要なドキュメントを提示する。WorkSpacesの場合、AWSのセキュリティ基準に乗っかった形でコントロールを説明できる。加えて社内の取り組み（アクセス制御ポリシー、オンボーディング/オフボーディング手順、ロール管理など）を話す。

AWS IAM でのRBAC (Role-Based Access Control)
オンプレAD連携時のConditional Access
Multi-Factor Authentication (MFA) を強制しているか

「大丈夫そうですね。WorkSpacesの監査ログも数ヶ月分ちゃんと揃っていますね」と、監査担当は納得した様子。田辺はホッと胸を撫で下ろす。

12:30 – ランチタイム

ようやくやってきた昼休憩。田町の街並みはオフィス街なので、安くてボリュームのある定食屋やとんかつ屋が揃っている。
今日の田辺は「とんかつ檍」でロースカツ定食を食べることに。
サクサクした衣とジューシーな肉。ライスをがっつり食べて体力をチャージする。「うまい……」と静かに幸福感に浸る。

13:00 – 午後の一仕事：ネットワーク問題勃発

オフィスに戻ると、Slackの#aws_opsが騒がしい。ざっとメッセージを見てみると、VPN接続が突然切れてWorkSpacesから切断されるユーザーが続出との報告。

「急にWorkSpacesが落ちた！」
「再接続してもダメなんだけど…」

こういうときはまずネットワークのルートテーブルやVPC Peering、NAT Gateway、VPNトンネルの状態を確認する。田辺はCLIで叩く前に、一旦AWSコンソールでVPC画面をチェック。

Site-to-Site VPN のトンネルステータスが DOWN になっていないか？
CloudWatch Logs のVPNログを確認し、切断タイミングを特定
Route53 Resolver (もし内部DNSを使っているなら) の設定をチェック

何やら怪しいのは、朝にネットワーク担当の清水がPeeringの設定を更新したらしいという話。ルートが誤って削除された可能性がある。
そこでコマンドを叩く。

aws ec2 describe-route-tables --filters "Name=vpc-id,Values=vpc-aaaaaaa"

返ってきた結果をJSONで眺めると……

{
  "RouteTables": [
    {
      "RouteTableId": "rtb-xxxxx",
      "Routes": [
        {
          "DestinationCidrBlock": "10.1.0.0/16",
          "VpcPeeringConnectionId": "pcx-yyyyy",
          "State": "active"
        },
        {
          "DestinationCidrBlock": "10.2.0.0/16",
          "GatewayId": "local"
        }
        # 10.3.0.0/16 が消えている…！
      ]
    }
  ]
}

「やっぱりか……」と思わずため息が漏れる。どうやら10.3.0.0/16のルートが抜けているため、VPN接続先へのトラフィックが途絶している。
Slackで清水にDM。

@shimizu-san VPC Peeringのルートテーブルから10.3.0.0/16が抜けてるね。  
そこ追加してもらえます？

清水：「あ、すみません、今すぐ直します！」

数分後、ルートが復旧。WorkSpacesのユーザーも再びつながり始める。
Slackの#aws_opsチャンネルで田辺はアナウンス。

@everyone VPN経由のWorkSpaces接続は復旧しました。  
まだ繋がらない方はWorkSpacesを再起動してみてください～

14:30 – ユーザー問い合わせ対応：Excelのリンク切れ問題

今度はユーザーから個別の問い合わせが入る。

WorkSpaces上のExcelで社内ファイルサーバのリンクが切れます。ネットワークドライブにアクセスするときにエラーが出るんです…

WorkSpacesは社内ファイルサーバにAWS Direct Connect経由で接続しているはずだが、時々DNSの設定が原因でファイルサーバが見えなくなることがある。田辺は以下の点をチェック。

WorkSpaces側のIPアドレスやDNS設定が正しいか
WINSサーバ（古い仕組みだが一部で使っている）の参照先は正しいか
ADのログオンスクリプトでネットワークドライブを割り当てているが、スクリプトが失敗していないか

aws ssm send-command \
  --document-name "AWS-RunPowerShellScript" \
  --targets "Key=InstanceIds,Values=ws-zzzzzzzzzzz" \
  --parameters 'commands=["ipconfig /all","Get-DnsClientServerAddress"]'

結果を見るとDNSサーバが社内の10.1.5.10と10.1.5.11になっている。問題はなさそう。
続けてログオンスクリプトのエラーログをチェック。

aws ssm send-command \
  --document-name "AWS-RunPowerShellScript" \
  --targets "Key=InstanceIds,Values=ws-zzzzzzzzzzz" \
  --parameters 'commands=["type C:\\scripts\\logon.log"]'

ファイルが存在しないエラー……どうやらスクリプトそのものが配置されていない様子。
オンプレADのGPO設定から漏れていたのかもしれない。管理者に連絡し、スクリプトのパスを再設定してもらうよう依頼。

ユーザーに状況をSlackで報告し、

ネットワークドライブ割り当てスクリプトがAD側で正しく配布されていませんでした。  
担当部署に依頼して対応してもらうので、少しお待ちください～

15:30 – 夕方に向けたタスク整理 & 自動化検討

ここまでトラブルシュート続きでドタバタしていた田辺は、ようやく落ち着いて自分のタスクを整理する。

WorkSpaces の定期メンテナンス → OSパッチやAVソフトの更新スクリプトをSystems Managerで流す
コスト最適化 → 使われていないWorkSpacesを特定して停止／削除する。特に自動停止(AUTO_STOP)の設定が外れているものがないかチェック
ユーザー新規登録の自動化 → 人事システムと連携して、オンボーディング時にWorkSpacesを自動作成できるか考える

特にコスト管理は重要だ。オンボーディングで増えたWorkSpacesが放置されていると、使われていないのに毎月高額な料金がかかる。AWS Trusted AdvisorやCost Explorerを開いて、リソース利用率をチェック。

aws workspaces describe-workspaces \
  --query 'Workspaces[?State==`AVAILABLE`]'

ズラッと一覧が出る中には「最終ログイン日が3か月前」みたいなWorkSpacesもある。田辺はそれらをスプレッドシートに洗い出し、オーナーに確認して不要なら削除する。
また、RunningModeをALWAYS_ONにしているユーザーが多すぎるとコストが爆発する恐れがあるため、AUTO_STOPに切り替えられそうなユーザーを探す。

17:00 – 残業前にやる仕事: レポート作成

夕方になると、マネージャーから「今週のWorkSpaces稼働状況をレポートにまとめておいて」と言われる。毎週金曜に提出するルーチン作業だが、これが結構めんどくさい。
田辺はAthenaやQuickSightの画面から今週の同時セッション数、最大CPU使用率、平均セッション遅延といったメトリクスをグラフ化し、PowerPointに貼り付ける。

同時セッションピーク：月曜10時台に150セッション
平均セッション遅延：150ms前後
クライアントOSの内訳：Windows 70%, Mac 20%, iPad 10%

「マネージャーにはこういう可視化したデータがわかりやすいんだよな……」と呟きつつ、グラフの体裁を整える。

18:30 – 退社のはずが… 最後の問い合わせ

そろそろ切り上げようかというタイミングで、またSlackが鳴る。

田辺さん、すみません。新入社員の武田がWorkSpacesにログインできないみたいなんです…今日アカウント作成したんですけど『Invalid credentials』と出ます。

どうやらActive Directoryとユーザー名が紐付いていないか、初期パスワードの発行に不備があった可能性が高い。
田辺は再度、作業ログを確認。

aws workspaces describe-workspaces \
  --directory-id d-9067xxxxxx \
  --user-name takeda.hanako

返り値が空。「そもそもWorkSpacesが作られていない？」と思い、さらにaws ds describe-users --directory-id d-9067xxxxxx --limit 10などでADユーザー情報を追いかける。

結果、オンボーディングスクリプトが途中で止まっていたらしい。アカウントがADに存在しない。田辺は慌てて人事システム担当に連絡し、ユーザー情報の反映を依頼。どうやら人事側のデータにスペルミス（takeda.hanakoではなくtakeda.hanekoになっていた）があった。

正しいユーザー名でADを作成し、WorkSpacesも作り直す。

aws workspaces create-workspaces --workspaces \
'[
  {
    "DirectoryId": "d-9067xxxxxx",
    "UserName": "takeda.hanako",
    "BundleId": "wsb-xxxxxxx"
  }
]'

あわせて初期パスワードを設定し、ユーザーに案内。武田さんから感謝のメッセージが届く。

ログインできました！ありがとうございます！

「これで今日の仕事は終わり！」と、田辺はほっと安堵の息をつく。

19:30 – 一日の終わり

外はすでに真っ暗。小雨が降っている様子が窓越しに見える。ビルのネオンが反射して、ささやかな夜景が広がる。
田辺はデスクを片付け、最後に自分のSlackステータスを「退勤中」に変更。MacBookをバッグに仕舞い、帰り支度をする。

廊下を歩きながら、ふと頭の中で明日のTODOを思い浮かべる。

定期メンテナンス（Windows Updateパッチ適用）
Cost Explorerで不要なWorkSpacesの洗い出し継続
TerraformのPull Requestをレビューして本番適用

「明日も忙しくなりそうだな……」と思いながら、ビルを出て夜風に当たる。田町駅に向かう足取りは、どこか充実感にあふれていた。

“クラウドの管理業務は物理サーバの保守がない分楽だ”
…と世間ではよく言われるが、実際はトラブルシュートやユーザーサポート、環境最適化に追われている。
それでも、物理サーバの故障対応に追われていた頃に比べれば、スケールする設計やログ解析がしやすい分、やりがいを感じる。

翌日編

06:00 – 早朝、静寂の中で

ケータイのアラームが鳴るより少し前に、田辺は目を覚ました。窓の外からかすかに聞こえる鳥のさえずりと、時折通り抜ける車の音。前日は夜遅くまでWorkSpacesのトラブル対応に追われたものの、何とか定時プラス少しで退社できた。朝の光の中でふっと気が抜けるような感覚がある。

「昨日はVPN切断にクローン作成失敗、CPU高騰問題……盛りだくさんだったなぁ。」
スマホを手に取りSlackの通知を確認すると、未読はそこまで多くない。 #aws_ops チャンネルに3件、 #vdi_troubleshoot に1件ほど。どうやら深夜帯は平穏だったらしい。

田辺はゆっくりと布団から抜け出し、キッチンでお湯を沸かして紅茶を淹れる。コーヒーも好きだが、今日はなんだか暖かい紅茶が飲みたい気分だった。マグカップを片手にソファに腰掛け、スマホを開いてSlackのメッセージを一つひとつ確認する。

「WorkSpacesの自動シャットダウン（AutoStop）が効いているかどうか、確認してほしい」
「新入社員の武田さん、ログインOKになった後、デスクトップ壁紙がデフォルトに戻らないって言ってます」
「Windows Updateが途中で止まったユーザーが3人ほどいるらしい」

いずれも大きな障害というほどではなさそうだ。田辺はホッとする一方、「細かい対応が今日も山積みだな」と気合を入れ直す。

06:30 – 朝の支度と情報収集

シャワーを浴び、身支度を整えながらテレビニュースをBGM代わりに流す。テレビでは「円安の影響でIT機器の価格が上昇」だとか、「リモートワーク普及で地方移住に関心が高まる」など、興味深い話題が流れている。
リモートワークが広がるほど、WorkSpacesの需要は今後ますます増えるだろう。クラウドVDIの管理者としては、スケール拡大に備えて様々な自動化スクリプトや運用ルールを整備しておきたいところだ。

朝食は軽めに、昨日の夕食の残り物を温めて済ませる。出発前にもう一度Slackをチェック。武田さん（昨日アカウント作成した新入社員）から、こんなメッセージが届いていた。

田辺さん、おはようございます。  
WorkSpacesの壁紙が一瞬だけ変わってまた戻ってしまうんですが、どうやったら固定できますか？

「おそらくグループポリシーで壁紙が固定設定されてるか、あるいはインターバルでスクリプトが走ってる可能性があるな……」とすぐに察しがつく。
田辺は「会社標準の壁紙に強制リセットされるポリシーを無効にしないとダメかもですね」と返信しておく。

07:15 – 通勤電車とAWSコンソールのチェック

いつもと同じ田町行きの電車に乗り込む。車内は混み合っているが、スマホ操作はなんとかできるスペースがある。片手で吊革を掴み、もう片手で画面をスクロールしながらAWSコンソールを覗く。

Cost Explorer でWorkSpaces関連のコスト推移を確認。今月に入ってからユーザー数が増えているせいで、先月比で15%ほどコストアップ。マネージャーから「予算をなるべく抑えてほしい」と言われているので、AutoStopを徹底的に有効活用する必要がある。

引き続きCloudWatchでアラームステータスをチェックすると、CPU高騰アラームは一つも出ていない。昨日のTeams問題もスペックアップでしのげたようだ。

08:00 – オフィス到着と朝のルーチン

オフィスビルに着き、まだ人が少ないフロアに入る。セキュリティカードをかざして扉を開け、自分のデスクに向かう。今日は最初に「朝の一杯のコーヒー」ではなく、「朝の一杯の紅茶」を淹れることにする。

MacBookを開き、最初の作業はお決まりのWorkSpacesダッシュボードのチェック。

利用中のWorkSpaces数
最近作成されたWorkSpaces
エラー状態になっているWorkSpaces

さらにCLIでもざっと一覧を取る。

aws workspaces describe-workspaces --query "Workspaces[?State=='ERROR']"

結果は空。どうやら今はERROR状態のWorkSpacesはゼロらしい。ほっと胸を撫で下ろす。

08:30 – チーム朝会：小さな問題の洗い出し

しばらくすると、続々と同僚が出社してくる。フレックスの人も多いが、朝型メンバーが集まって軽い朝会を開始。田辺は昨日のトラブルと対応を簡潔に共有する。

VPN接続切れ → ルートテーブル変更で解決
新規ユーザーアカウント作成不備 → スペルミス修正、再作成完了
CPU高騰（Teams問題） → WorkSpacesのスペックをPOWERへ上げて対応

「大きな障害はなさそうですが、壁紙問題やWindows Updateが途中で止まるなど、ちょっとした問い合わせが数件ありますね。」と田辺が報告すると、他のメンバーもうなずきながらログを確認している。

09:00 – Windows Updateの途中失敗を調査

まずは「Windows Updateが途中で止まった」ユーザーがいる件を確認する。WorkSpaces上のWindows Updateは、通常ならAWS Systems Manager (SSM) のパッチ管理機能を使って半自動化している。時々、ユーザーがログイン中にOS更新が走って競合を起こすケースがある。

田辺は以下のコマンドで対象のWorkspaceインスタンスにSSMスクリプトを送り、イベントログを収集する。

aws ssm send-command \
  --document-name "AWS-RunPowerShellScript" \
  --targets "Key=InstanceIds,Values=ws-abcdefg" \
  --parameters '{
    "commands": [
      "Get-WinEvent -LogName System | Where-Object { $_.Id -eq 20 -or $_.Id -eq 1001 } | Select TimeCreated,Id,Message -First 20"
    ]
  }'

返ってきたログから判断するに、アップデート適用中にユーザーが手動で再起動してしまい、インストールが中断された形跡がある。

「まあ、よくあるパターンだよね……」
田辺はSlackでそのユーザーに連絡し、OSを再起動した上でWindows Updateを再実行してもらうよう案内する。

10:00 – グループポリシーの壁紙固定問題

新入社員の武田さんから再度問い合わせ。「やっぱり壁紙が自分の好きな写真に変えても、再起動すると戻ってしまうんです……」

そういう“壁紙固定ポリシー”は、会社のブランドロゴ入り壁紙を使うように設定している。例えばオンプレADのGPOで Set a custom desktop background を有効にしている場合、ユーザーが手動で変えても、次回ログイン時に元に戻る。

田辺は同僚に確認し、開発部門やデザインチーム向けの“壁紙自由化”グループに武田さんを一時的に追加してもらうことを提案。これが承認されれば、WorkSpaces上で個人の壁紙が使えるようになる。

田辺がオンプレAD管理コンソール（RDP経由か、もしくはAWS上の仮想マシン経由）にアクセスして、GPOの設定を確認する。グループ“Wallpaper-Free”にユーザーを追加するスクリプトを実行。

Add-ADGroupMember -Identity "Wallpaper-Free" -Members "takeda.hanako"

Slackで武田さんに連絡。

これで再ログインしたら壁紙変わるはずなので試してみてください～

武田さん：「ありがとうございます！今晩かわいい猫の写真にしてみます！」

10:30 – コスト最適化タスク：AutoStop設定の大掃除

田辺はWorkSpacesのコストを下げるために、AutoStopの設定が外れているユーザーを一斉に見直す作業に着手する。デフォルトではAutoStopにしているが、役職や業務によっては “ALWAYS_ON” のバンドルが当てられている場合がある。

手順はこうだ：

CLIで全WorkSpaces一覧を取得し、JSONをファイルに落とす
その中から RunningMode が ALWAYS_ON のワークスペースを抽出
ユーザー名や最終ログイン日を照らし合わせ、不要そうなものを AUTO_STOP に変更

aws workspaces describe-workspaces > all_workspaces.json

jq '.Workspaces[] | select(.WorkspaceProperties.RunningMode=="ALWAYS_ON")' all_workspaces.json \
  > always_on_workspaces.json

さらにalways_on_workspaces.jsonをチェックし、連携している社員情報のスプレッドシートから「退社済み」「異動済み」「長期休暇中」のユーザーを突き合わせる。すると10名ほどが該当する。

「これ、もうALWAYS_ONじゃなくていいでしょ」と判断した田辺は一括で変更のコマンドを作る。

while read WORKSPACE_ID; do
  aws workspaces modify-workspace-properties \
    --workspace-id $WORKSPACE_ID \
    --workspace-properties '{"RunningMode":"AUTO_STOP","RunningModeAutoStopTimeoutInMinutes":60}'
done < target_workspace_ids.txt

念のためSlackでチームにアナウンス。

ALWAYS_ONのWorkSpacesの一部をAUTO_STOPに切り替えます。  
使い方に問題ある場合は連絡ください！

11:30 – システム管理部門とのオンライン会議

少し早いが、ランチ前にシステム管理部門とのオンライン会議がセットされている。テーマは「リモートワークを支えるVDI環境の拡張計画」。

新たに100名の増員が決まっており、WorkSpacesを一斉追加する必要がある
ゆくゆくは3D CADを使う部署も対象にしたいので、Graphics BundleのWorkSpacesも検討
予算上限とコスト最適化のバランスをどう取るか

Teamsでのオンラインミーティングが始まると、画面共有しながら資料を説明する田辺。前回、TeamsがCPUを食いまくって苦しめられた経験があるので、自分の端末スペックは一応POWER Bundleにアップ済みだ。おかげで今回の通話はさほど負荷を感じない。

「今回、CAD利用者向けにGraphics GPU搭載のWorkSpacesを準備するとすると、コストは月あたりこのくらい上がります。でも常時使うわけじゃないならAutoStopを活用して費用を抑えられます。」
会議は滞りなく進み、システム管理部門からも「前向きに検討しましょう」という返事が得られる。

12:30 – 昼食: 社食でのリラックスタイム

会議を終え、社食へ向かう。田町の外食もいいが、今日は社内カフェテリアのメニューが気になる日替わり。メインは鶏の照り焼き定食。そこそこ混んでいるが、ひとりで席を確保してのんびり食事。

隣のテーブルで若手エンジニア同士が「俺はDockerがどうの、Kubernetesがどうの」と盛り上がっているのを横耳で聞きながら、田辺は心の中で「VDI管理って、地味だけどなくてはならない基盤だよな」と改めて思う。

ふとSlackを開くと、朝は見なかった未読メッセージが追加されていた。システム監査チームから「WorkSpacesのログをもう少し細かく提出してほしい」と要望が来ている。
監査対応は手間がかかるが、ログの保管と提出はしっかりやっておく必要がある。午後のタスクに組み込むと決め、食事を済ませる。

13:30 – 監査チーム対応: 詳細ログの抽出

午後になり、田辺は監査チームのリクエストにこたえるため、CloudTrailやWorkSpaces Access Logsの過去3ヶ月分を抽出する。作業手順としては、AthenaでクエリしたデータをCSV出力し、それをS3に置いた上でアクセス権限を管理する。

SELECT eventTime, eventName, awsRegion, sourceIPAddress, userAgent, errorCode
FROM "cloudtrail_database"."workspaces_logs"
WHERE eventTime BETWEEN TIMESTAMP '2024-11-01 00:00:00' AND TIMESTAMP '2025-01-31 23:59:59'
  AND eventName IN ('CreateWorkspaces', 'TerminateWorkspaces', 'ModifyWorkspaceProperties');

クエリの結果を一旦S3に落とし、そのS3パスを監査チームへ共有。監査チームのIAMロールには、そのS3バケットに対するGetObject権限を付けたポリシーを限定的に適用する。

Slackで監査担当にURLを伝え、パスワード付きZIPなどの形でまとめるよう調整。「クラウドの監査ってこういう手間が省けるはずだったんだけどなぁ……」とちょっと笑いがこぼれる。実際にはオンプレ時代よりは大幅にマシなものの、やはり監査プロセスはそれなりに面倒だ。

14:30 – WorkSpacesイメージ更新の下準備

今週末に実施予定のWorkSpacesイメージ更新作業を前倒しで準備する。新しいGolden Image（ベースAMI）を作っておき、それをもとに量産する予定だ。

Windows OSやOfficeのパッチを適用した最新状態
社内標準のウイルス対策ソフトが最新版かどうか
必要な開発ツール（Visual Studio Code、Chrome、Firefoxなど）がプリインストールされているか

田辺はAmazon WorkSpaces Consoleから「イメージの作成」フローを開き、既存のマスターWorkSpaceをベースにCreate Imageを実行。すると数十分ほど待って完了した後、WorkSpace Bundlesの一覧に新しいカスタムバンドルが増える。
「このイメージがあれば、新しいユーザーを一気に作っても最新環境が配布できる」とニヤリ。運用工数が一気に減るのが嬉しい。

15:30 – ユーザーサポート窓口でのトラブルシュート

夕方前、ユーザーサポート担当から「WorkSpacesから印刷しようとするとプリンタが見えない」という相談が舞い込む。テレワークの方が自宅プリンタを使うケースだ。
会社の方針としては、WorkSpacesからローカルプリンタへの出力を基本的にブロックしている。しかし部署によっては認可されている場合もある。

田辺はWorkSpaces Clientの設定を確認し、プリンタのリダイレクトがオフになっているユーザーがいるかチェックする。AWS WorkSpaces Web Accessを使っている場合は、そもそもプリンタのリダイレクトがサポートされないので、その点も要注意。

結局、ポリシーで“オフ”になっているのを“オン”に切り替える申請プロセスが必要だとわかり、ユーザーには「総務経由で申請を行ってください」と回答。セキュリティ部門への許可も必要で、簡単にはオンにできない仕組みだ。

「意外とこういうところ、社内調整が一番大変なんだよな」と田辺は頭を掻く。

16:30 – スクリプトの自動化＆Terraform更新

昨日もやったが、引き続きTerraformを用いてWorkSpacesの構成管理をより効率化する作業を進める。イメージ更新やバンドル設定、AutoStopの設定などをTerraformで一元管理できれば、ヒューマンエラーを減らせる見込み。
GitHub Enterprise上のリポジトリでPull Requestを開き、昨日対応した内容に追加で以下の部分を追記する：

AutoStopタイムアウトを全社デフォルト60分に統一
AlwaysOnが必要な一部の役職（経営陣・サーバ管理者）向けのタグ設定
WorkspaceProperties の RootVolumeSizeGib や UserVolumeSizeGib を状況に応じて柔軟に設定可能にする

「コードとして管理しておくと、やっぱり後から何をやったかわかりやすいな」と田辺はTerraformファイルを見渡し、快哉をあげる。レビューをチームメンバーに依頼して、マージは明日以降になりそうだが、確実に運用効率は上がっていくだろう。

17:30 – 玲奈がやってきた？最後のひと波乱

田辺がそろそろ仕事を終えようかという頃、玲奈が現れた。
彼女は相変わらずの無表情で、スッと田辺のデスクの前に立つ。何を考えているのか全く読めないが、いつも通りの玲奈だ。

「田辺」
「ん？」
「WorkSpaces、壊れた」

田辺は思わず固まる。「壊れた」という表現が玲奈の口から飛び出すのは珍しい。いつもなら「挙動が変」「妙な動きをする」とか、もっと冷静に分析した表現を使うはずだ。

「ちょっと待って、何がどうなった？」
田辺はすぐにPCを開き、WorkSpacesの管理コンソールを確認する。

「ログインはできる。けど、全部壊れた」
「全部？」

"壊れた" という言葉が漠然としすぎている。田辺はもう少し詳しい情報を聞こうとしたが、玲奈はそのまま無言でPCを田辺の方に向けた。

田辺は画面を覗き込む。
WorkSpacesのデスクトップは表示されている。しかし、明らかに異常だった。

アイコンがすべて消えている。
スタートメニューが開かない。
タスクバーの時刻表示がなぜか1970年1月1日になっている。

「……これは、なかなか派手にやらかしてるな」

田辺は直感的に「ユーザープロファイル破損」の可能性を疑った。WindowsのWorkSpacesでは、プロファイルデータ（C:\Users\ユーザー名）が破損すると、ログインできるがデスクトップがまっさらになることがある。

「昨日、何か設定いじった？」
「いじってない」
「アプリは？」
「Adobe系を入れた。入れたら壊れた」

田辺は考える。Adobeのインストールでシステム全体が破壊されることは考えにくい。ただ、WorkSpacesは基本的に仮想環境なので、一部のアプリがOSの動作をおかしくすることはよくある。

「待って、Adobe入れる時に、何か管理者権限要求された？」
「された」
「許可した？」
「した」

「そっちかーーー！」

田辺は頭を抱える。WorkSpacesでは「管理者権限を持つアプリ」を入れようとすると、仮想化環境と競合することがある。特にCreative Cloud系は、仮想環境を検知すると強制的に設定を変えようとすることがあるのだ。

「つまり、Adobeのインストール時にプロファイル周りを触られて、破損した可能性があるってことか……」

田辺はAWS Systems Manager (SSM) を使って、玲奈のWorkSpaces上で「プロファイル復元」できるかを試す。

aws ssm send-command \
  --document-name "AWS-RunPowerShellScript" \
  --targets "Key=InstanceIds,Values=ws-xxxxxxx" \
  --parameters 'commands=["sfc /scannow"]'

このコマンドは、Windowsの「システムファイルチェッカー」を実行し、破損したシステムファイルを修復する。玲奈のWorkSpacesがまだまともに動くなら、これでワンチャン直る可能性がある。

5分ほど待つ。

→ 失敗。
「保護されたシステムファイルが破損していますが、修復できませんでした」というメッセージが返ってくる。

「だめだ、完全にぶっ壊れてる」
「ふむ」
玲奈は表情を変えずに静かに画面を見つめている。

「WorkSpaces再作成するしかないな」
「めんどい？」
「まあ、ちょっとな」

玲奈はしばらく無言で田辺の作業を眺めていたが、突然こう言った。
「田辺」
「ん？」
「デスクトップが壊れた時、人は最初に何を思う？」

「……え？」
「おそらく、焦る。でも私は焦らなかった。それはなぜ？」

「……知らんがな」

「WorkSpacesだからだ」

「……は？」

「物理PCが壊れたら、焦る。でもWorkSpacesなら、再作成すれば戻る。つまり、破壊される前提で使っているから、焦らない。」

田辺は一瞬絶句した。
玲奈の言っていることは、一理ある。確かにWorkSpacesの強みは「環境が壊れてもすぐ作り直せること」だ。それゆえに、物理PCが壊れたときほどの焦燥感はない。

「……なるほどな」
「だから、さっさと再作成して」
「お、おう」

田辺はWorkSpacesを再作成するために、まず玲奈の現在のWorkSpacesを削除。

aws workspaces terminate-workspaces --terminate-workspaces-request '[{"WorkspaceId":"ws-xxxxxxx"}]'

続けて、新しいWorkSpacesを作成する。

aws workspaces create-workspaces --workspaces '[{"DirectoryId":"d-xxxxxxx","UserName":"rena","BundleId":"wsb-yyyyyyy"}]'

30分ほどかかるので、その間に玲奈は「ちょっとスタバ行ってくる」と言い残し、颯爽とオフィスを出ていった。
そして30分後、何事もなかったかのように戻ってきて、再ログイン。

「……元に戻った？」
「戻った」
「よかった」
「田辺」
「ん？」
「また壊れたらよろしく」

「いや、壊すなよ……！」

玲奈はクールに去っていく。
田辺は深いため息をつきながら、「まったく、どこまでもマイペースなやつだな」と苦笑する。

18:30 – 退社、そして夜の静けさ

すべての対応を終え、ようやく田辺は退社準備に入る。WorkSpacesの管理コンソールを最後に確認し、問題がないことをチェック。

オフィスを出ると、空はすっかり夜になっていた。小雨が降り出しそうな雰囲気だが、田町のビル群はいつも通りの風景。

田辺はふとスマホを開き、Slackの通知を確認すると、玲奈から短いメッセージが届いていた。

WorkSpaces、便利だね。

「……まあな」

田辺はスマホをポケットにしまい、電車に乗り込む。
明日もまた、WorkSpacesの管理が待っている。
だが、少しだけ楽しいかもしれない。

（終）