Antigravityを使ってWordPress用のAWS EC2インスタンスを移行

何をするか

最近、古くなったWebサーバーから最新の環境へお引っ越しをする機会がありました。今回は、普段使っているAIコーディングアシスタント「Antigravity」を相棒にして、PHP 7の旧サーバーから、AWS EC2上の最新のBitnami WordPress(PHP 8)環境への完全移行を行いました。単にデータを移すだけでなく、「AIと一緒にトラブルシューティングをしながらインフラを再構築する」という新しい移行体験を記事にまとめました。

サーバー移行って何?(1分で分かる概要)

今回直面した最大の動機は「PHP 7のサポート終了(EOL)」です。古いバージョンのまま放置するとセキュリティリスクが高まるため、サーバーまるごと最新環境へ移す必要がありました。手順の概要は以下の通りです:

AWS上に新サーバー構築 → データのエクスポート/インポート → SSL・セキュリティの再設定 → 旧サーバー削除

今回はデータ移行の定番プラグイン「All-in-One WP Migration」を利用しましたが、環境が新しくなることで発生した様々な「摩擦」をAIと一緒に乗り越えることになりました。

最新環境(PHP 8 + Bitnami)にするメリット

最新のサーバー環境にするだけで、以下のような恩恵があります。一言で言うと「速くてめちゃくちゃ堅牢」になります。

  • セキュリティの大幅向上
    最新のPHPパッチが適用されるのはもちろん、Bitnami標準のガチガチなセキュリティ設定(.htaccessのシステムレベルでの無効化など)により、外部からの攻撃耐性が飛躍的に高まります。
  • 処理速度(パフォーマンス)の向上
    PHP 7から8になることでWordPressの動作自体が最適化・高速化され、表示速度の改善が見込めます。
  • 分かりやすいコスト削減
    移行完了後に古いEC2インスタンスを完全削除することで、無駄なクラウド維持費をスパッとカットできます。

手順(Antigravityと進める完全移行劇)

1. 新サーバーへのデータインポートと「タイムアウト」の壁

AWSで新しいBitnami WordPressを立ち上げ、データをインポートしようとしたところ、最初の壁が出現。データ量が大きかったため、なんとインポートが77%でストップしてしまいました。

原因は「PHPの処理時間上限(タイムアウト)」。ここでAntigravityが本領を発揮します。チャットで「止まりました」と伝えただけで、AIが裏側でSSH経由で新サーバーに接続し、php.inimax_execution_time設定を1時間(3600秒)に拡張。その後、無事に100%までインポートが完走しました。

2. 実はここでハマった…「Critical Error」と古いプラグインの悲鳴

これで移行完了!と思いきや、サイトを開くと画面が真っ白になり「There has been a critical error on this website.」の絶望的な文字が。

原因は、旧環境から引き継いでしまった「古いプラグイン」でした。これらが最新のPHP 8の仕様に対応しきれず、裏でエラーを吐き続けていたのです。これもAntigravityがすぐにエラーログを解析し、SSHから直接問題のプラグインフォルダをリネームして強制無効化。一瞬でサイトが復旧しました。

3. Let’s EncryptによるSSL証明書の再設定

続いてHTTPS化です。サーバー(IPアドレス)が変わったことでブラウザから警告が出る状態になっていました。Bitnami専用のbncert-toolコマンドを実行して証明書の再発行を試みましたが、ここでも「wwwあり」ドメインのDNS設定が存在しないというエラーが。

すかさず設定を「wwwなし」単体に切り替えてAIが対話を自動で進行させ、無事に新しいSSL証明書の発行と、定期更新の自動設定(cronジョブ)まで完了させることができました。

4. 最大の罠:超セキュア環境による「ログイン画面」の仕様衝突

最大の難関はセキュリティプラグインでした。以前は専用のログインURLを作るために「Login Rebuilder」プラグインを使っていましたが、新環境では全く機能しません。理由は、Bitnamiの強固なセキュリティ設定でした。「.htaccess」ファイルがシステム根幹で無効化されていたため、プラグインが物理ファイルを作ったりURLを偽装する手法が全ブロックされていたのです。

そこでモダンな「WPS Hide Login」へ切り替えを試みますが、これも404エラーに。最終的に、Antigravityが不要な古いプラグインの残骸を完全にパージし、パーマリンクの空更新を行うことで、Bitnami独自のルーティング設定をうまく機能させ、「新しい安全な専用ログインURL」を完璧にセットアップできました。

おまけ:旧サーバーを落としてスッキリ

新環境が完璧に動くこと、ログイン画面の保護が強力に効いていることを確認したのち、AWS CLIコマンドを使って古いEC2インスタンスをterminate-instancesで完全削除しました。

aws ec2 terminate-instances --instance-ids [古いインスタンスID]

これで、毎月発生していた旧サーバーの無駄な維持費もストップ。移行プロジェクトは無事に完了となりました。

まとめ

今回の移行で痛感したのは、「環境を新しくするということは、過去の古い仕組みとの摩擦が必ず起きる」ということです。特にBitnamiのような高セキュリティ環境では、直感的な操作(プラグインを入れるだけ)が通用しない場面が多々あります。

しかし、AntigravityのようなAIアシスタントがいることで、「エラーが起きた」と伝えるだけで、AIが原因を見抜き、SSHで直接サーバーに潜り込んでコマンドを叩き、設定を書き換えて直してくれる。そんな専属のインフラエンジニアとペアプログラミングをしているかのような、次世代の保守運用を体験できました。システム移行を重荷に感じている方は、ぜひAIを相棒に迎えてみてはいかがでしょうか。

AntigravityでMCP(Model Context Protocol)を使ってローカルDBと自然言語で会話してみた

何をするか

最近、AIコーディングツールの世界で話題になっている「MCP(Model Context Protocol)」という技術があります。 簡単に言うと、AIとデータベースやファイルシステムなどの外部ツールを直接つなぐ「標準規格」です。 今回は、私が普段使っているAIコーディングアシスタント「Antigravity」にMCPを設定して、ローカルのSQLiteデータベースと接続。 「〇〇を追加して」「△△のデータを見せて」と日本語で話しかけるだけでDBを操作する、ということをやってみました。

MCPって何?(1分で分かる概要)

MCPは2024年11月にAnthropic社が発表したオープン標準で、2026年現在、OpenAI、Google、Microsoftなど主要AI企業もサポートしています。 仕組みはこうです:

AIアプリ(Antigravity) → MCPプロトコル → MCPサーバー → 外部ツール(DB、ファイルなど)

「MCPサーバー」というのが橋渡し役で、AIからの「このテーブルの中身を見せて」というリクエストを、実際のSQLクエリに変換して実行してくれるわけです。

MCPを使うと何が嬉しいのか?

一言で言うと、AIが「物知りなアシスタント」から「実務をこなす実行部隊」に進化します。 具体的には、以下の3つのメリットが非常に強力です。

  • 外部情報の「取得」ができる
    最新のニュース、天気、GitHubのリポジトリ、Google検索の結果など、AIの学習データに含まれていない「リアルタイムの情報」をツール経由で取ってこれます。
  • 外部情報の「操作」ができる
    単に調べるだけでなく、Slackへの投稿やカレンダー登録、そして今回のメインである「DBの中身を書き換える」といったアクションまでAIが代行してくれます。
  • 「自環境のサーバ」とも連携可能
    これがエンジニアにとって最大の魅力です。公開されているWebサービスだけでなく、自分が管理しているローカル環境や社内ネットワーク上のサーバ、DBともセキュアに連携させることができます。

手順(AntigravityによるローカルDB連携)

1. MCP設定ファイルを作成する

Antigravityの設定ディレクトリ内のmcp_config.jsonに、使いたいMCPサーバーを書き込みます。 最終的に私が設定したのは以下の3つです。

{
    "mcpServers": {
        "everything": {
            "command": "npx.cmd",
            "args": ["-y", "@modelcontextprotocol/server-everything"]
        },
        "filesystem": {
            "command": "npx.cmd",
            "args": ["-y", "@modelcontextprotocol/server-filesystem", "プロジェクトパス"]
        },
        "sqlite": {
            "command": "npx.cmd",
            "args": ["-y", "mcp-server-sqlite-npx", "DBファイルのパス"]
        }
    }
}

ポイントは、Node.js(npm/npx)がインストールされていれば、パッケージのインストール作業は不要ということ。npx -yが自動でダウンロード&実行してくれます。

おまけ:より安全なDB接続(環境変数の活用)

1. 設定ファイルへの直書き(ベタ書き)のリスク

PostgreSQLなどのサーバー型DBに接続する際、以下のようにmcp_config.json内に接続用URL(ユーザー名やパスワード)を直接指定することができます。

{
    "mcpServers": {
        "postgres": {
            "command": "npx.cmd",
            "args": [
                "-y",
                "@modelcontextprotocol/server-postgres",
                "postgresql://admin_user:MySecretPassword123@localhost:5432/my_database"
            ]
        }
    }
}

しかし、上記のようにJSONファイルにパスワードを平文で記述するのは、セキュリティの観点から非常に危険なアンチパターンです。

もし誤って設定ファイルをGitHubなどに公開してしまった場合、データベースが乗っ取られる原因になります。

2. 環境変数を使ったセキュアな設定方法

安全に運用するためには、PC本体の環境変数を利用して接続情報を隠蔽するのがベストプラクティスです。具体的には、mcp_config.jsonからは引数の接続URLを完全に削除します。

{
    "mcpServers": {
        "postgres": {
            "command": "npx.cmd",
            "args": [
                "-y",
                "@modelcontextprotocol/server-postgres"
                // ※ここに接続URLやパスワードを書かない!
            ]
        }
    }
}

ポイントは、Windowsのシステム環境変数にDATABASE_URLとしてpostgresql://admin_user:MySecretPassword123@localhost:5432/my_databaseをあらかじめ登録しておくこと。そうすれば、設定ファイル上にはパスワード情報が一切残りません。

3. なぜJSONに書いていないのに変数を読み込めるのか?

「JSONに『DATABASE_URLを使え』と書いていないのに、なぜMCPサーバーは勝手に読み込めるの?」と疑問に思うかもしれません。

その答えは、MCPサーバー(@modelcontextprotocol/server-postgresなどのパッケージ)のソースコード自体にあります。パッケージ側は、「もし引数からURLが渡されなかったら、自動的にOSの環境変数からDATABASE_URLを探しに行く」ように初めからプログラミングされています。

つまり、JSONファイルはあくまで最初の起動スイッチにすぎず、起動した裏側でプログラムが勝手にパソコンの環境変数を見に行ってくれる仕様になっているため、JSONにわざわざ書かなくても動作するのです。

(※パッケージごとに探しに行く環境変数の名前は異なるため、事前に公式ドキュメントで確認しておく必要があります!)

ポイントは、Windowsのシステム環境変数にDATABASE_URLとしてpostgresql://user:pass@localhost/dbをあらかじめ登録しておくこと。そうすれば、設定ファイル上にはパスワード情報が一切残りません。

2. 実はここでハマった…パッケージが存在しない!

最初、公式ドキュメントに書いてあった@modelcontextprotocol/server-sqliteというパッケージを設定しました。 ところが、Antigravityの「Manage MCP servers」画面に真っ赤なエラーが。 「404 Not Found」——npmレジストリにパッケージが存在しない、と。 Antigravityに調査してもらったところ、公式GitHubリポジトリでSQLiteサーバーは「アーカイブ(廃止)」されていたことが判明。 公式の情報が古くなっていたわけです。 結局、mcp-server-sqlite-npxという別のNode.js対応パッケージを見つけてテスト。 ターミナルに「SQLite MCP Server running on stdio」と表示され、無事に起動を確認できました。

3. MCPサーバー接続成功!33ツールが利用可能に

設定を書き換えてAntigravityの「Manage MCP servers」画面でRefreshすると…

  • everything:14 / 14 ツール ✅
  • filesystem:14 / 14 ツール ✅
  • sqlite:5 / 5 ツール ✅

合計33ツールがAIから直接使えるようになりました。 SQLiteサーバーが提供するツールは以下の5つです:

  • create_table — テーブル作成
  • write_query — INSERT / UPDATE / DELETE の実行
  • read_query — SELECTクエリの実行
  • list_tables — テーブル一覧の取得
  • describe_table — スキーマ情報の取得

4. 自然言語でDBを操作してみた

ここからが本番です。Antigravityのチャットで、普通の日本語でDBを操作していきます。 ■ テーブル作成 Antigravityに「ユーザーテーブルを作って」と伝えただけで、create_tableツールが呼ばれ、id / name / email / age / city / created_at の6カラムのテーブルが自動で作成されました。 ■ データ挿入 5名分のサンプルデータが一括で挿入されます。 さらに「山口達也を追加して」と日本語で伝えると、AIが自動でINSERT文を生成して即座に実行。承認ボタンを押す必要もありません。 ■ データ取得 テーブルの中身を確認してみます。

SELECT * FROM users ORDER BY id
ID 名前 年齢 都市
1 田中太郎 28 東京
2 鈴木花子 34 大阪
3 佐藤健 23 福岡
4 山田美咲 31 札幌
5 高橋翔太 45 名古屋
6 山口達也 30 広島

6名分のデータが正しく格納されています。これ、一度もSQLを自分で書いていません■ 集計クエリ 「都市ごとの平均年齢を教えて」と聞くと、GROUP BYクエリが自動生成されて、名古屋の45歳が最高齢、福岡の23歳が最年少という結果が即座に返ってきました。 ■ データ更新 「佐藤健の年齢を23にして」と言うだけで、UPDATE文が実行されました。

5. MCPがないとどうなるのか?

ちなみに、MCPがなくてもターミナル経由でDBを操作すること自体は可能です。違いを比較してみました。

比較 MCPなし MCPあり
操作方法 AIがコマンドを提案→ユーザーが承認→実行 AIが直接ツールを呼び出し
手間 毎回ターミナル経由 シームレス
自然言語対応 △ SQLを書いてコマンド提案 ◎ 「〇〇を追加して」だけ
応答速度 承認ステップが必要で遅い 即座にデータ取得・操作

今回の「山口達也を追加して」→即座に挿入完了、が象徴的ですが、MCPありだと「会話の延長線上でDBが操作される」感覚なのが大きな違いです。

おまけ:リモートDBにも接続可能

今回はローカルのSQLiteファイルを使いましたが、MCPは対応パッケージさえあればリモートサーバーのDBにも接続できます。

  • PostgreSQLmcp-server-postgres
  • MySQL@benborla29/mcp-server-mysql
  • MongoDBmcp-mongo-server

接続文字列を設定するだけなので、例えばAWSのRDSに接続して「先月の売上データを見せて」なんてこともできます。

情報漏洩の懸念について

1. データの流れと「学習」の境界線

MCP(Model Context Protocol)を使ってローカルDBに接続すると、データは以下のように処理されます。

  • ローカル実行: MCPサーバー自体はユーザーのPC(ローカル環境)で動作します。そのため、データベースの中身が丸ごとGoogleのサーバーへ送信されることはありません。
  • コンテキストとしての利用: AIエージェントがDBを検索し、回答を生成するために必要な特定のレコード(テキストや数値)だけを抽出してAIモデルに送信します。この「送信された断片的なデータ」が学習に使われるかどうかが、プライバシー保護の分かれ目になります。

2. Antigravityにおける学習ポリシー

Antigravityは2026年現在、開発者向けのプレビュー版として提供されており、利用するアカウントの種類によって以下のルールが適用されます。

A. 個人用Googleアカウント(Gmail)の場合

デフォルトの状態では、AIとのやり取り(プロンプトや、DBから取得された回答内容)は、Googleのサービス改善やモデルの学習に使用される可能性があります。

【回避方法】
Antigravityの設定画面(Settings)にある「Enable Telemetry」をOFFに切り替えてください。これを無効にすることで、インタラクションデータの収集が停止され、プライバシーを保護できます。

B. Google Cloud (GCP) または Workspace アカウントの場合

企業向け・開発者向けの契約(GCPプロジェクトやGoogle Workspace)を介してAntigravityを利用している場合、Googleの基本規約により、入力されたデータやモデルの回答がグローバルなモデルの学習に使用されることはありません。ビジネス利用でも安心してローカルDBとの連携が可能です。

まとめ

今回の体験で感じたのは、MCPは「AIとデータの距離をゼロにする」技術だということです。 前回のSSL証明書更新では、Antigravityが「サーバー操作」を自動化してくれました。 今回のMCPでは、「データベース操作」までもが自然言語で完結するようになりました。 もはやSQLが書けなくても、「30歳以上のユーザーを教えて」と聞くだけでAIがクエリを書いて実行してくれる。 開発でも運用でも、AIに「何をしたいか」を伝えるだけで、あとは全部やってくれる時代がどんどん現実になっています。 設定ファイルを1つ書くだけで始められるので、興味がある方はぜひ試してみてください。

AntigravityににSSL証明書(Let’s Encrypt)の更新を丸投げしてみた

何をするか

Webサイトを運営していると避けて通れないのが「SSL証明書(https化)の有効期限切れ」問題です。
今回、私が管理しているサーバー(AWS/Bitnami環境)でLet’s EncryptのSSL証明書が期限切れになってしまい、サイトが警告表示(保護されていません)になってしまいました。

通常なら「SSHでサーバーに入って、更新コマンドを調べて、Apacheの設定ファイルを書き換えて、再起動して…」と非常に面倒な作業が必要です。
しかし今回は、最強のAIアシスタント「Antigravity」に、SSHのログイン情報だけを渡して「完全AI主導」でSSL証明書の更新と自動化の設定をやってもらいました!

手順(Antigravityによる全自動更新プロセス)

1. Antigravityに「サーバー情報」と「お願い」を伝える

私がAntigravityのチャット画面に入力したのは、基本的に以下の情報だけです。

  • 「xxx.xxx.xxx.xxx のサーバーのSSL証明書が切れたから更新したい」
  • 「SSH接続用の秘密鍵(key.pem)はパソコンのこのフォルダにあるよ」

たったこれだけです。
するとAntigravityは、「承知しました。それでは私のほうでサーバーにログインして現状を調査します」と宣言し、勝手に私のパソコンのターミナル(コマンドライン)を立ち上げて、自動でSSH接続を開始したのです。

2. AIによる環境調査と「Lego」の特定

サーバーに入ったAntigravityは、迷うことなくLinuxコマンド(unamelssystemctl など)を打ち込み、現在の環境を調査し始めました。
数秒後、Antigravityから「このサーバーはBitnami環境であること、そしてLet’s Encryptの更新には『Lego』という専用ツールが使われていることが分かりました」という報告が。私はただ画面を見ているだけです。

3. 証明書の再取得を「AI主導」で実行

環境を把握したAntigravityは、「それでは、Legoツールを使って新しい証明書を取得します。実行してよろしいでしょうか?」とImplementation Plan(実行計画)を提示してくれました。
私が「Approve(承認)」ボタンを押すと、Antigravityは次々とコマンドを打ち込みます。

# AIが自動で叩いたコマンドの一部
sudo /opt/bitnami/letsencrypt/lego --tls --email="hoge@example.com" --domains="example.com" --path="/opt/bitnami/letsencrypt" renew

さらに、新しく取得した証明書をApache(Webサーバー)に適用するためのシンボリックリンクの張り替えまで、手際よくあっという間に完了させてしまいました。

4. Webサーバーの再起動と、今後の「自動更新(cron)」の設定まで

証明書の差し替えが終わると、Antigravityは自動でApacheを再起動し、「ブラウザでサイトを確認してみてください。新しい証明書が適用されているはずです!」と教えてくれました。
確認すると、見事に「保護された通信」が復活!!

また、
「今後また期限が切れないように、Cron(定期実行)で自動更新されるように設定しておきましょうか?」と、根本的な解決策まで自発的に提案・設定してくれたのです。

# AIが自動で設定したCronジョブ
0 0 1 * * sudo /opt/bitnami/letsencrypt/lego ...(略)... renew && sudo /opt/bitnami/ctlscript.sh restart apache

まとめ

これまでのサーバー運用は、エラー画面とGoogle検索のにらめっこでした。
しかし、Antigravityを使えば「鍵を渡して目的を伝えるだけ」
あとはAIが勝手にサーバーに入り込み、環境を調査し、最適なコマンドを打ち込んでミッションを完遂してくれます。

インフラエンジニアがいなくても、AIさえいればサーバーの保守・運用ができてしまう時代が来たことを肌で感じた体験でした。

AIエージェント「Antigravity」を使ってAndroidアプリを開発してみた

何をするか

プログラミング(Androidアプリ開発)は完全未経験
でも、「〇〇分後や指定時刻にバイブレーションだけで静かに起こしてくれる、シンプルなアラームアプリが欲しい!」と思いやってみました。
※すでに類似アプリがあるが、広告ありのものしか見当たらず、、

そこで今回は、話題のAIエージェント「Antigravity」の力を借りて、Android Studioの設定から実際のコーディング、そして実機での動作確認までをゼロから行い、オリジナルの「Simple Vibe Alarm」アプリを完成させます!
※Android Studio自体も未導入の状態からスタートです

↓完成したアプリのイメージはこんな感じ

手順(Antigravityとの開発プロセス)

1. Antigravityに「作りたいもの」を伝える

まずはAntigravityに「Androidの電卓アプリを作りたい」「アラームアプリは作れる?」とチャットで相談するところからスタートしました。
私はAndroid開発の知識がなかったので、「こういうのが欲しい」と日本語で要望を伝えるだけ。 するとAntigravityが「Jetpack Composeを使った最新のUIで作りましょう」「ロック画面でも鳴るようにするにはこんな権限が必要です」と、必要な技術要素をすべて裏側で考えて提案してくれました。

2. Android Studioの環境構築とプロジェクト立ち上げ

Android Studioの準備もAntigravityのサポートのもとで進めました。
「新しいプロジェクトはどうやって作るの?」「エミュレータはどうやって起動するの?」といった初歩的な疑問から、遭遇した細かい設定エラー(ビルド設定やSDKバージョンの違いなど)まで、チャットで聞けばすぐに解決策を教えてもらいながら進められました。
しかも、Antigravityは私のPC(ローカル環境)のファイルを直接読み取ってくれるので、「〇〇行目でエラーが出てるんだけど…」という手間すら省けました。

3. プログラムのおまかせ実装

ここが一番感動したところです。
「ダークモードっぽくて、システムバーも黒くしたい」「『何分後』と『指定時刻』の両方を選べるようにしたい」と伝えると、Antigravityが実際のファイル(MainActivity.ktなど)を直接編集して、一気にコードを書き上げてくれました。

私は、時々出てくる「この設計(プラン)で進めていいですか?」というImplementation Plan(実装計画)に対して、「OK(Approve)」を出すだけ。まるで優秀なエンジニアとペアプログラミングをしているような感覚でした。

4. バグへの遭遇と修正(AIとのトラブルシューティング)

順調に見えた開発ですが、大きな壁にぶつかりました。
「スリープ状態(画面オフやロック画面)の時に、指定時刻ならアラーム画面が出るのに、『〇〇分後』だと鳴らない・画面が出ない!」という動作不良が発覚したのです。

初心者の私ならここで挫折していたかもしれませんが、Antigravityに「ロック画面でうまく動かないんだけど…」と伝えると、すぐさま調査を開始。
Android 12以降の権限(SCHEDULE_EXACT_ALARM)の問題や、省電力機能(Dozeモード)下での AlarmManager.setAlarmClock の使い方の違いなどを分析し、自動でコードを修正してくれました。

5. 実機での確認と完成!

修正後、自分のAndroidスマホにアプリを転送してテストしました。
アプリを起動して「10分後」にタイマーをセットし、スマホの画面を消して待ちます……。

10分後、真っ暗だったスマホの画面がパッと点灯し、ロック画面を突き破ってアラーム画面が表示され、指定通りにしっかりとバイブレーションが作動しました!!

できた!!


まとめ

「プログラミング未経験だから…」と諦めていた自作アプリですが、Antigravityという頼もしいAIエージェントのおかげで、想像以上にサクサクと(しかも本格的なコードで)完成させることができました。
アイデアさえあれば、誰でも形にできる時代になったことを実感しています。次はどんなアプリを作ろうか、今からワクワクしています!

初めてのリーダー・マネジメント振り返り

リーダーを担うのは2回目ですが、1回目はリーダー2人体制だったため、2回目が実質はじめてのリーダーという感じでした。
とても濃い2年間だったため、振り返り、反省、学び等を残しておきます。

リーダー経験振り返り
①逆風の中での引き継ぎ
【状況】 2階級上のハイスペックな前任者の退職に伴う業務引き継ぎを開始。リーダー案件2つ、SE案件2つの計4案件を担当することに。
【課題】 引き継ぎ期間は1か月あったが、前任者の有給消化や既存業務のクローズ対応が重なり、実質的な引き継ぎは2週間。未知の技術(IP-KVM等)もあり、強いプレッシャーを感じる。
【反省】 限られた時間の中で、情報の優先順位付けや効率的なキャッチアップ方法をさらに工夫する余地があった。

②キャッチアップの限界と挫折
【状況】 新体制での業務がスタート。リーダー案件の把握に注力するあまり、SE案件まで手が回らず、お客様から存在価値を問われるクレームが発生。
【課題】 日々の業務に加え、休日・夜間のサービス残業で情報を補うが、精神的・時間的に限界を迎える。
【学び・反省】 「できないと思われたくない」というプライドと、上長への気後れから、キャパシティオーバーを早期に相談できなかった。「早めのエスカレーション」はリーダーの義務であると痛感。

③転機と「巻き込み」の成功
【状況】 既存顧客から新規案件の相談を受け、3つ目のリーダー案件がスタート。これに伴いSE案件から離脱し、リソースをリーダー業務へ集中させる。
【行動】 8月の契約更新期、初めての契約実務に対し、自力の限界を認めて上長へSOSを発信。深夜まで上長のフォローを仰ぎながら、不慣れな契約対応や顧客説明を完遂。
【成果・教訓】 一人で抱え込まず**「周囲を巻き込む」ことで、自分以上の役職が担うべき難易度の高い業務を完遂**でき、大きな自信と経験に繋がった。

④属人化の罠とテックリードへの成長
【状況】 3案件の同時リーダーという社内でも稀な状況を完遂すべく、がむしゃらに邁進。社内評価は高まるが、私生活を犠牲にした働きにより心身に過度な負荷(適応障害に近い症状)がかかる。
【課題】 自身の技術力(オンプレNW、SV構築)に頼りすぎた結果、業務が属人化。「自分と同じレベルの人間がいればいい」という自惚れに近い悩みに陥り、適切なデリゲーション(権限移譲)ができていなかった。
【反省】 自分のタスクに余裕がないため、メンバーへの依頼が雑になり、結局自分でやり直すという悪循環。「人に任せるための準備」への投資不足を痛感。

⑤完遂とチームの絆
【成果】 綱渡りのような調整の末、スケジュール通りシステム構築・検証を完了。リリース後の課題はあるものの、チームメンバーから「あなたでなければできなかった」と労いの言葉を受ける。
【総括】 プレイヤーとしての強みを活かしつつも、マネジメントの難しさと「持続可能な働き方」の重要性を深く学んだ2年となった。

■マネジメントの道に進んでいきたいのか?
約2年、がっつりとマネジメントやリーダーを経験したうえで、今後もマネジメントの道に進んでいきたいかと言われると「感情的にはNO」です。
やはりプレイヤー時代の「時間を忘れ業務(設計/構築の検討や切り分け)に没頭していた自分」の方が生き生きしていました。
しかし、キャリア的な生存戦略を考えると、全くマネジメントをしないのは大きなリスクになるため、
プレイヤーとしての専門性を維持/向上しつつ、マネジメントも可能なリードエンジニアを目指すのが良いかなと今時点では考えております。
☆中長期的なToDo
・マネジメントの型を身に着ける
 →不要な(強迫観念に駆られた)サビ残を減らす、技術的好奇心を満たすためのサビ残は悪くない
・サードプレイスを探す
 →休息の効率化

VMware Workstation PlayerからESXiに移行する

何をするか

VMware Workstation Player上で動かしている仮想マシンのイメージファイルをESXiで使えるように変換して使用する。

qemuマシン側

VMware Workstationフォルダにovftool.exeがあることを確認する
・ディレクトリ
C:\Program Files (x86)\VMware\VMware Workstation\OVFTool

変換前のvmxファイルと変換後のovfファイル名を指定する
C:\Program Files (x86)\VMware\VMware Workstation\OVFTool>ovftool.exe D:\VM\kali-linux-2023.3-vmware-amd64.vmwarevm\kali-linux-2023.3-vmware-amd64.vmx C:\Users\xxx\Desktop\tmp\20231104\kali-linux.ovf

Versa SD-WANルータ ZTP

■VersaZTP
・デバイスのZTP情報

 -デバイスアクティベーションのための初期ZTP接続情報を作成するために使用し、ローカルアクティベーションデバイスをCPEデバイスに接続することができます。

 -このテンプレートから作成されたデバイスのZTPコンフィギュレーションは、アクティベーション専用です-Temporary Configuration

・アクティベーションメールとトークン

 -デバイステンプレートがZTP対応テンプレートとして構成されている必要があります。

 -電子メールを生成するためにVersa DirectorのSMTP設定が必要です。

 -またはZTPトークンを生成し、CPEへのローカルWebブラウザーの接続で使用することができます。

 -ZTP情報を取得するデバイスを選択 URLベースのZTP情報アイコンをクリック

・ZTP URL

アクティベーション情報をトークン文字列にエンコードしたURLを含む 接続機器のウェブブラウザに直接貼り付け可能

・URLアクティベーション

 -DHCP対応デバイスをCPEデバイスのイーサネットポート2またはイーサネットポート4に接続する デバイスがIPアドレスを受信し、CPEと通信できることを確認する
→ifconfigでCPEからIP取得出来てること、CPE LAN IPにping通ることを確認

・ブラウザアクティベーション

電子メールのリンクをクリックするか、ブラウザのアドレスバーにトークンのURLを貼り付けてください。

・コンフィギュレーション情報

ブランチ構成情報がデバイスに存在する(URLトークンから抽出される)

・起動状況

アクティベーションが完了すると、デバイスが再起動し、SD-WANに参加します。

・ステージングスクリプトによるFlexVNF CPEのアクティベーション

/opts/versa/scripts ディレクトリにあるスクリプトは sudo パーミッションが必要です。

すべてのスクリプトオプションが表示されるわけではありません。オプションは ./staging.py –helpコマンドを実行することで見つけることができます。
デバイスは自動的に再起動し、SD-WANに追加されます。
 1)スクリプト名
 2)コントローラで必要とされるローカル認証情報
 3) コントローラーに要求されるリモート認証の認証情報
 4) コントローラのデバイステンプレートに設定されているデバイスのシリアル番号
 5)コントローラIPアドレス
 6)プロバイダに接続されたWANインターフェース(コントローラ側ポート)
 7)CPEデバイスのWANインターフェースアドレス
 8)サービスプロバイダー側WANポートのゲートウェイアドレス

Azure AD ハイブリッドAD joinとSSOの実装

■目的
AADjoinデバイス、HybridADjoinデバイスにてsSSO(シームレスSSO)を有効にする
※社外NWからの接続はAzureADユーザでログイン時のみsSSO有効化

■必要設定
ユーザプロビジョニング等の初期設定は実装済の想定

・AADC
 -デバイスオプションにてHybrid AD join有効化
 -同期オプションにてデバイスのをjoin有効化
 -ユーザサインインオプションにてSSO有効化
・GPO(端末のインターネットオプション設定でも可)
 -MSwebサイト、AAD関連サイトをイントラネット判定
 -イントラゾーンサイの自動ログオンを有効化
・FW設定
 -AADC→オンプレAD
 -AADC→AAD
 -クライアント→AAD
※プロキシ環境の場合は、イントラゾーン登録Webサイトのみ許可
 
■FWルール設定詳細
・AADC→オンプレAD
・AADC→AAD
https://learn.microsoft.com/ja-jp/azure/active-directory/hybrid/reference-connect-ports

・クライアント→AAD
https://learn.microsoft.com/ja-jp/azure/active-directory/devices/howto-hybrid-azure-ad-join

https://learn.microsoft.com/ja-jp/azure/active-directory/hybrid/tshoot-connect-connectivity

■イントラ判定
https://learn.microsoft.com/ja-jp/azure/active-directory/devices/howto-hybrid-join-downlevel

ここに記載のURLに加えてonmicrosoft等のSWGベンダー指定のバイパス除外ドメインも?
これらはプロキシバイパスされる

Azure ADの種類

■Azure ADとは
クラウドベースのディレクトリサービス
オンプレミスADとの連携が取れるのが特徴

■Azure ADを利用するケース
・Azure AD registered:AADにユーザが登録されている、端末はドメイン参加していない
・Azure AD joined:AADにユーザが登録されている、端末はドメイン参加している
・Hybrid Azure AD joined:AAD/オンプレADに共通のユーザが登録されている、端末は両方のドメインに参加している

■各ケースの特徴
・Azure AD registered
-○メリット
IDaaSとしてAzure AD使うだけなので、端末がドメイン参加する形ではなく端末側設定が不要
Windows以外のデバイスでも利用可能

-●デメリット
オンプレミス側のユーザ管理は別途AD等(ディレクトリサービス)が必要となる
※ユーザ情報自体はオンプレADからプロビジョニング可能

個人利用等でオンプレにADが必要ない場合はこれでも十分

・Azure AD joined
-○メリット
オンプレADを持たない企業でもディレクトリサービスとして利用できる
SSOができる(クラウドサービスのみ)

-●デメリット
インターネット接続がない環境では利用不可
オンプレAD等と併用する場合はIDが二重管理になる

オンプレにADが無くディレクトリサービスを利用したい場合はこの選択肢おあり

・Hybrid Azure AD joined
-○メリット
オンプレADのユーザでAzure ADの機能も使えるようになる
SSOができる(クラウドサービス/オンプレリソース両方)

-●デメリット
オンプレおよびAzure AD Connect + 各種設定が必要

環境構築の手間はあるが、利便性では圧倒的にこれ