はじめに こんにちは、たかぎ@hitsanです。 最近、趣味でSystemVerilogを使ったハードウェア開発に入門しています。 ハードウェア開発では信号の値を見るために波形を確認するのですが既存のツールはGUIを介して確認するものがほとんどです。ですが私は開発環境をターミナル内で完結させたいのでCLIで波形を確認することができるツールを作りました。 今回はAIを使って開発したのでAIを使った自分用のツールのつくり方を紹介します。 前提知識 この章では今回の記事に必要なハードウェア開発の前提知識について少しお話します。 SystemVerilogはデジタル回路の設計・検証に使用

G-gen の三浦です。当記事では Google Antigravity を使用し、バイブコーディングで目標管理アプリを開発する手順と、Browser Agent によるデバッグの流れを紹介します。 概要 Google Antigravity とは リリースステージ 使用可能なモデル データの保護 検証手順 検証 インストール 初期設定 日本語化とルール設定 自然言語による開発 Browser Agent によるデバッグ 概要 Google Antigravity とは Google Antigravity は、AI を使用して開発作業ができる IDE（統合開発環境）です。Google Antigravity を使うことで、自然言語でやりたいことを伝えて AI がコードの生成や修正を進める開発スタイルである バイブコーディング （vibe coding）を実現できます。 自然言語を使ってチャットで Google Antigravity に作業を依頼すると、AI エージェントがエディタ、ターミナル、ブラウザを使って、実装や修正を段階的に実行します。 参考 : Google Antigravity 参考 : vibe コーディングとは Google Antigravity の主な特徴は以下のとおりです。 特徴 説明 AI-powered IDE エディタ内で AI と対話しながら、作成・修正・調査を一連の流れで実行 Asynchronous Agents 複数の作業を同時に依頼でき、複数タスクを並行して実行可 Agent Manager エージェントとの会話、進捗、成果物を1つの画面でまとめて管理 Multi-window 編集、管理、ブラウザ確認を分けて表示して効率的に並行作業 Browser Agent エージェントがブラウザを操作し、画面確認や情報収集を行う リリースステージ Google Antigravity は、2026年2月現在、 パブリックプレビュー です。当記事で解説する内容は一般提供（GA）の際に変更される可能性があることをあらかじめご了承ください。プレビュー版のサービスや機能を使うに当たっての注意点は、以下の記事も参考にしてください。 blog.g-gen.co.jp 使用可能なモデル Google Antigravity で使用するバックエンドの AI モデルとしては、Google が提供する Gemini シリーズに加えて、Anthropic の Claude など他社モデルも使用可能です。 2026年2月現在、Google Antigravity では以下の生成 AI モデルを選択できます。 提供元 モデル Google Gemini 3 Pro（high） Google Gemini 3 Pro（low） Google Gemini 3 Flash Anthropic Claude Sonnet 4.5 Anthropic Claude Sonnet 4.5（thinking） Anthropic Claude Opus 4.5（thinking） OpenAI GPT-OSS 参考 : Models データの保護 Google Antigravity は Google 製品であり、以下のような規約が適用されます。 Google Terms of Service Google Cloud - Service Specific Terms Google Workspace AI Ultra for Business で認証する場合に適用 Google Antigravity Additional Terms of Service Google Privacy Policy Generative AI Additional Terms of Service Google Antigravity 自体は無償で利用できますが、その場合、Google Antigravity Additional Terms of Service に記載のとおり、ユーザーデータやメタデータ、AI とのやりとりなどが記録され、保存されます。また、それらの情報はサービス改善に使用される可能性があります。ただし、Google Workspace AI Ultra for Business サブスクリプションを使用して認証する場合は、「当社はお客様のプロンプト、コンテンツ、またはモデル応答を収集しません。」とされています。 上記のような記載があるものの、Google Antigravity の企業による利用に際して、データがモデルのトレーニングに使用されないためにはどうすればよいか、という公式のガイダンスは、2026年2月現在、Google から発表されていません。 2026年2月現在、Google Antigravity のリリースステージがパブリックプレビュー段階であることからも、企業が当サービスを使うにあたりどのようにすべきかは明確になっていません。なお公式料金ページには、 Organization plan が近日中に発表されることが示唆されており、このプランは Google Cloud と連携することでデータの保護を提供するような内容となることが想定されます。 参考 : Choose the perfect plan for your journey 検証手順 検証手順は以下のとおりです。インストールとアプリ開発に加え、意図的にエラーが発生する状況を作り、Browser Agent で原因特定から修正までできるか確認します。 項番 内容 説明 1 インストールと初期設定 インストール後、初回起動〜サインインまでを実施し、エージェントの実行ポリシー（コマンド実行や変更適用のレビュー要否など）を設定します。 2 日本語化とルール設定 画面表示を日本語化し、「回答・計画は日本語で実施する」などのルールを設定します。 3 自然言語によるアプリ作成 チャットに要望を入力し、計画の提示 → レビュー → 実装 → 起動確認までを行います。 4 Browser Agent によるデバッグ検証 わざと不具合を入れ、Browser Agent（ブラウザ操作）でエラー画面を確認し、原因特定〜修正までできるかを確認します。 本検証時の端末と Antigravity のバージョンは以下のとおりです。 OS : Windows 11 Pro 実行環境 : WSL2（Ubuntu） Antigravity : 1.13.3 検証 インストール 公式サイトから、利用する OS に合わせたインストーラーをダウンロードして実行します。対応 OS と要件の詳細は公式ドキュメントをご確認ください。 対応 OS macOS Windows Linux 参考 : Download Google Antigravity 使用許諾契約書を確認して問題がない場合は「同意する」を選択し、「次へ」を選択します。 使用許諾契約書の同意 インストール先を指定し、「次へ」を選択します。 インストール先の指定 ショートカットの作成場所を指定し、「次へ」を選択します。 ショートカットの指定 その他で必要な項目があれば選択し、「次へ」を選択します。 追加タスクの選択 内容を確認し、「インストール」を選択します。 インストールの選択 インストールが完了したので、「完了」を選択します。 完了を選択 初期設定 Antigravity を起動し、「Next」を選択します。 起動と Next の選択 Visual Studio Code （以下、 VS Code ）を使用している場合、設定をインポートできます。不要な場合は「Start fresh」を選択します。 VS Code 設定をインポートするかの選択 次に IDE のテーマ（配色などの見た目）を選択し、「Next」を選択します。 テーマの選択 Antigravity のエージェントをどのように動かすかを選択します。選択したモードに応じて、エージェントの動きが変わります。本検証では Review-driven development を選択します。 エージェントの設定 利用モード（左側）の違い モード 特徴 Secure Mode すべての操作を 都度確認 してから実行します。加えて、より厳格な保護設定が適用されます（詳細は公式ドキュメント参照）。 Review-driven development（推奨） 要所で 人間の確認を挟みながら 作業を実行します。 Agent-driven development エージェントが 自律的に反復 して作業を実行します（確認なしで進む場合があります）。 Custom configuration 実行ポリシー（例 : コマンド実行やレビュー要否）を 細かく設定 できます。 実行ポリシー（右側）の項目 項目 制御項目 選択肢 影響 Terminal execution policy ターミナル（コマンド）実行の扱い Always Proceed / Request Review コマンド 自動実行するか 、 都度確認するか を制御します。 Review policy 変更の適用・進行時の人間の確認の要否 Always Proceed / Agent Decides / Request Review 変更を 即適用するか 、 都度確認するか 、 状況に応じて自動判断するか を制御します。 JavaScript execution policy ブラウザ等での JS 実行 Always Proceed / Request Review / Disabled JavaScript を 自動実行するか 、 都度確認するか 、 無効化するか（Disabled） を制御します。 参考 : Secure Mode 参考 : Agent Modes / Settings エディタの初期設定を行い、「Next」を選択します。 Keybindings（キー割り当て） ：通常は Normal を選択します。 Vim 操作に慣れている場合は Vim を選択します。 Extensions（拡張機能） ：Python や Go などの言語拡張機能をインストールするかを選択します。 エディタの設定 「Sign in with Google」を選択し、Google アカウントで認証を実施します。 Google 認証の実施 認証が完了すると、以下画面に切り替わります。注意事項の確認と必要に応じてチェックボックスを有効化します。チェックボックスを有効化した場合、利用状況データの送信を許可することを指します。 利用規約の確認 初期設定は以上です。これらの設定は後から変更できます。 エディタの表示 日本語化とルール設定 左サイドバーの「Extensions」を選択し、 日本語 と入力して表示された Japanese Language Pack for Visual Studio Code の「Install」を選択します。 画面の日本語化 左下にポップアップが表示されるので、「Change Language and Restart」を選択します。 Antigravity の再起動 日本語表記になっていることを確認し、右上の三点リーダーから「Customizations」を選択します。 Customizations を選択 Rules タブで「Global」を選択し、以下を入力して保存します。Global ルールは全体の共通仕様です。 回答及び計画などの各種ドキュメントはすべて日本語にすること Rules の設定 参考 : Rules 自然言語による開発 右上の「Open Agent Manager」を選択します。 Open Agent Manager を選択 「Open Workspace」 > 「Open New Workspace」 を選択し、作業用フォルダ（ Workspace ）を開きます。 Open Workspace を選択 参考 : Workspaces 作業用のフォルダを選択します。 フォルダの選択 「Next」を選択します。 Next を選択 会話画面が表示されます。モデル（ Gemini 3 など）の選択に加え、会話モードとして以下 2 つを選択できます。 モード 説明 Planning 実行前に計画（手順）を提示してから進めるモードです。調査や設計、複雑な作業を慎重に進めたいケースに適しています。 Fast 計画より実行を優先して、直接タスクを進めるモードです。軽い修正や試行をすぐに動かして確認したいケースに適しています。 モードの選択 モデルの選択 本検証時は以下の設定で、以下プロンプトを入力し、Enter キーを押下します。 モード : Planning モデル : Gemini 3 Pro（high） 社員の目標を管理するシステムを作りたい プロンプトの入力 エージェントから実装計画の確認依頼が来たので、内容を確認します。 実装計画の確認1 実装計画の確認2 実装計画の確認3 計画が問題ない場合、「Review」を選択してコメントを入力し、「Submit」を選択します。 計画の承認 エージェントから、 Next.js のプロジェクト作成コマンドの実行確認依頼が届きます。内容を確認して「Accept」を選択します。 エージェントによるコマンド実行の承認 エージェントから実装（ダッシュボードと社員一覧画面）の完了連絡が届いたら、コマンドを実行して確認します。 エージェントからの動作確認依頼 コマンドの実行 表示された URL にアクセスし、画面が表示されることを確認します。 アプリの表示確認1 アプリの表示確認2 Browser Agent によるデバッグ コードを意図的に改修し、アクセス時にエラーが出るようにします。 エラーが出るように改修 エージェントに対し、エラー内容をブラウザで確認するよう指示します。エージェントから Browser Agent を使用したデバッグの実行許可を求められるため、「Setup」を選択します。 エージェントによる Browser Agent のセットアップ確認 参考 : Browser Agent ブラウザが起動し、Antigravity 用の拡張機能のインストールが求められるため、確認してインストールを実施します。 拡張機能のインストール1 拡張機能のインストール2 拡張機能のインストール3 インストールすると、Antigravity によりエラーページへのアクセスとデバッグ情報の収集が開始されます。 エージェントによるデバッグ情報の収集 エージェントから修正完了連絡が来たので、再度アクセスしてエラーが表示されずに画面が表示されていることを確認します。 エージェントからの修正完了連絡 アクセスの確認 三浦 健斗 (記事一覧) クラウドソリューション部 2023年10月よりG-genにジョイン。元オンプレ中心のネットワークエンジニア。 ネットワーク・セキュリティ・唐揚げ・辛いものが好き。 Google Cloud Partner All Certification Holders 2025 / Google Cloud Partner Top Engineer 2026

こんにちは、SCSKで テクニカルエスコートサービス を担当している兒玉です。 Webサイトを作成する際に、APEXドメインへのアクセスを転送したい、と思うことはありませんか？ APEXドメイン（アペックスドメイン、Zone APEX 、ネイキッドドメイン、ルートドメインとも呼ばれる）とは、「example.com」のようにサブドメイン（www.など）を含まない、ドメイン名そのもののアドレスを指します。 Webサイトにアクセスするユーザー側の立場として考えると、サブドメインあるいはサーバー名を指定してアクセスするのは入力するのが面倒ですし、通例として www に決まっているとしても、決まっているならそっちに自動的に誘導してほしいと考えるのは自然な考えだと思います。 ところが、DNSの仕組みからすると、APEXドメインはちょっと厄介で、APEXドメインには CNAME 適用できないという制約があります。 # これはできない（RFC違反） example.com. CNAME d123456789.cloudfront.net. # サブドメインならOK www.example.com. CNAME d123456789.cloudfront.net. CNAMEはそもそも「このドメインのことは全部あっちの窓口にお願いします」という記述なのですが、APEXドメインにはSOA(Start Of Authority) つまり「このドメインの責任者は私です」という名札をつけて立っている担当者がいる状況なわけです。 こんな矛盾した記述がされているドメインにDNSが問い合わせを行うと、混乱を招いてしまうため禁止されているんですね。 しかし、wwwなどサーバ名なしのドメインからそのドメインのホームページにたどり着きたいという動機もわかります。 では、どうすればよいか。 選択肢としては3つあります。 1. Amazon Route 53のALIASレコードを使う Route 53を使っている場合、ALIASレコードという特殊なレコードタイプが使えます。これはAWS独自の機能で、APEXドメインでもCloudFrontやALBを指定できます。 しかし、これはRoute 53を使っている場合のみ。DNSサーバーを移管したくない、あるいは移管できない状況ではこの選択肢は採用できません。 2. 外部DNSプロバイダーの独自機能を使う 一部のDNSプロバイダー（Cloudflare、DNSimpleなど）は、ALIAS相当の独自機能を提供しています。 しかし、全てのプロバイダーが対応しているわけではありませんし、移管できない状況であれば 1. のケースと同様にこちらも採用できません。 3. 固定IPアドレスを使う Aレコードで固定IPアドレスを指定する方法。これならどのDNSプロバイダーでも使えます。 仕方なく 3. を選ぶことになります。ところが、AWS上でベストプラクティスとされる CloudFront や ALBは動的IPなので、固定IPアドレスを持つサーバー（例えば Elastic IP + EC2）が別に必要になってしまいます。これをうまくサーバレスで解決するソリューションを考えます。 まとめると、こんな状況ではないでしょうか？ 会社のポリシーでALIAS相当の機能に対応していない外部DNSプロバイダーを使わなければならない でもAPEXドメインでのアクセスを受け付けたい CloudFrontやALBなど、AWSのサービスにリダイレクトしたい サーバーの維持管理をしたくないのできればサーバーレスで実現したい  このソリューションでは、こんな状況を解決いたします！ 前編では、検証用のリダイレクト先環境と証明書の準備までを行います。   ソリューションの全体像 ソリューションの全体像は以下のようになります。 他社DNSでのAPEXドメインレコードに対する要件（IPアドレスを直接設定）を満たすために、Network Load Balancer(NLB) に Elastic IP を付与し、Webサイトとして必要な証明書は Application Load Balancer(ALB) で行い、サブドメインに対するリダイレクト処理を行うHTML応答を Lambda関数内で生成、レスポンスとして返却することで、ブラウザにサブドメインへリダイレクトするよう促します。 この処理をフロー図にすると以下のようになります。 このソリューションの料金概算 前提条件 リージョン: ap-northeast-1（東京） 月間リクエスト数: 100万リクエスト（想定） 平均レスポンスサイズ: 10KB 稼働時間: 24時間365日（730時間/月） 使用サービスと料金 AWS Lambda 設定 メモリ: 128MB ランタイム: Python 3.12 平均実行時間: 100ms（想定） 料金 リクエスト料金: $0.20 per 1M requests 100万リクエスト × $0.20 = $0.20/月 コンピューティング料金: $0.0000166667 per GB-second 100万リクエスト × 0.1秒 × 0.125GB = 12,500 GB-秒 12,500 GB-秒 × $0.0000166667 = $0.21/月 Lambda合計: $0.41/月   Application Load Balancer (ALB) 料金 ALB時間料金: $0.0243 per hour（東京リージョン） 730時間 × $0.0243 = $17.74/月 LCU料金: $0.008 per LCU-hour 想定: 0.5 LCU/時間（低トラフィック） 730時間 × 0.5 LCU × $0.008 = $2.92/月 ALB合計: $20.66/月   Network Load Balancer (NLB) 料金 NLB時間料金: $0.0243 per hour（東京リージョン） 730時間 × $0.0243 = $17.74/月 NLCU料金: $0.006 per NLCU-hour 想定: 0.5 NLCU/時間（低トラフィック） 730時間 × 0.5 NLCU × $0.006 = $2.19/月 NLB合計: $19.93/月   Elastic IP Address 料金 Public IPv4アドレス料金: $0.005 per IP per hour 2個のElastic IP × 730時間 × $0.005 = $7.30/月 Elastic IP合計: $7.30/月   AWS WAF 設定  Web ACL: 1個 マネージドルール: 3個（AWSManagedRulesCommonRuleSet、SQLi、KnownBadInputs） カスタムルール: 1個（Rate-based rule） 合計ルール数: 4個 料金 Web ACL料金: $5.00 per month ルール料金: $1.00 per rule per month 4ルール × $1.00 = $4.00/月 リクエスト料金: $0.60 per 1M requests 100万リクエスト × $0.60 = $0.60/月 WAF合計: $9.60/月   VPC関連リソース 料金 VPC: 無料 Subnets: 無料 Internet Gateway: 無料 Route Tables: 無料 Security Groups: 無料 VPC合計:$0.00/月   その他料金 インターネットへのデータ転送（アウトバウンド）: 最初の10TB/月: $0.114 per GB（東京リージョン） – 次の40TB/月: $0.089 per GB – 次の100TB/月: $0.086 per GB 100万リクエスト × 10KB = 10GB/月の場合 – データ転送料金: 10GB × $0.114 = $1.14/月 その他料金合計: $1.14/月   VPC関連リソース 月額料金合計   サービス 月額料金（USD） 月額料金（JPY）※ Lambda $0.41 ¥62 ALB $20.66 ¥3,099 NLB $19.93 ¥2,990 Elastic IP (×2) $7.30 ¥1,095 WAF $9.60 ¥1,440 VPC $0.00 ¥0 ACM $0.00 ¥0 IAM $0.00 ¥0 その他 $1.14 ¥171 合計 $59.04 ¥8,857 ※ 為替レート: 1 USD = 150 JPY で計算   検証用リダイレクト先(転送先ドメイン)の作成 本番では本来のWebサイト（ 例えば www.example.com ) に転送するのですが、今回は記事用の検証なので転送先ドメインが必要です。検証用に CloudFront – S3 の環境を作成します。下図の右側の赤枠の範囲になります。 本筋でないコードを全部載せるとそれだけで記事が埋め尽くされてしまうので、必要なファイルのを zip 化したファイルのリンクを載せておきます。 test_environment.zip SHA256: 829899f97643f4dac1dff61e7600a42da4e5afd5e3f4b702cf010d95051eb960 ダウンロードしたファイルを CloudShell などにファイルをアップロードし、 zip ファイルの中身を展開してフォルダを移動します。 ~ $ unzip test_environment.zip -d ./test_environment Archive: test_environment.zip inflating: ./test_environment/deploy_test_environment.sh inflating: ./test_environment/test-environment.yaml inflating: ./test_environment/TEST_ENVIRONMENT_README.md ~ $ cd test_environment test_environment $   vim などで、 deploy_test_environment.sh の中のパラメータを修正します。 PROFILE は AWS が使用するプロファイル名でえすが、 CloudShellからの実行の場合は “” で良いです。 STACK_NAME は CloudFormationが作成するスタック名です。わかりやすい名前や環境の命名規則に沿った形に変更します。 COST_TAG はAWS内でのコスト配分タグとして使用されるタグの値を設定します。（タグの属性名は 内部では “Cost” と固定になっています。） deploy_test_environment.sh のパラメータ設定 パラメータを修正後、デプロイします。 test_environment $ ./deploy_test_environment.sh 10分くらいで、デプロイが完了するので  CloudFront Domain: abcdef01234567.cloudfront.net Test Website URL: https://abcdef01234567.cloudfront.net の箇所をメモしておきます。　これが転送先となる検証用リダイレクト先サイトのドメイン名とWebサイトの URL です。 Test Website URLにアクセスしてみると、 アクセスできましたね。（画像参照） これで検証用リダイレクト先ドメインの環境ができました。 APEXドメイン/サブドメイン用のサーバー証明書の準備 転送用の APEXドメインも https でアクセスが必要ならAPEXドメイン用の証明書が必要です。 サブドメインのワイルドカードも一緒に設定します。これは転送先(www.example.comなど)でも使えますので、AWS Certification Manager から 1枚にまとめて発行します。 CloudFront で使用するので、 証明書を作成するリージョンは 米国東部（バージニア北部）(us-east-1)  である必要があります。   エクスポート可能な証明書は有料ですが、AWS内でのみ使用する場合はエクスポート不要なので無料で利用できます。 料金 – ACM AWS Certificate Manager の料金 – アマゾン ウェブ サービス (AWS) aws.amazon.com リクエストをしただけでは、証明書は有効になりません。まだ、 「保留中の検証」というステータスになっているのがわかります。 ドメインの正当な持ち主であることを証明するために、 証明書をリクエストしたドメインのDNSの 指定された CNAME名 に指定された CNAME値 を設定する必要があります。 CNAME 名 と、 CNAME 値をコピーして、 DNS のプロバイダ画面から、 CNAMEレコードを追加して、 コピーしておいた CNAME名、対応する CNAME値 を設定します。 今回はAPEXドメイン用と、 そのサブドメイン用のワイルドカードで 2 レコードありますが、設定すべき値のセットは同じだったので 追加した CNAME レコードは 1 つでした。 DNSプロバイダの設定画面はUIが様々でどう設定すれば良いかはそのプロバイダ毎に異なるのですが、きちんと設定できているかは dig コマンドで検証すればわかります。 マスクされている箇所ばかりでわかりにくいですが、 dig cname _9c63abcdef0123456789abcdef01234.example.com. と打って、応答の ANSWER SECTION で、 CNAME名 の対となる CNAME値 が表示されれば OK です。 しばらくすると、Certificate Manager の証明書のステータスが「発行済み」に、ドメインのステータスが 「成功」 に変わります。 これで証明書は利用可能になりました。 検証用リダイレクト先サイトに ACM 証明書を設定 転送先となる検証用リダイレクト先(www.example.com) の CloudFront に、サブドメイン  www.example.com を担当してもらうために、担当するサブドメイン名とCertificate Managerから取得した証明書を設定します。 CloudFormationスタックに、先程作成した検証用リダイレクト先のスタックがありますので、 CloudFrontDistributionId の 値 にあるディストリビューションを覚えておいて、マネジメントコンソールの CloudFront の画面から開きます。 ディストリビューションの画面から Add domain をクリック www.example.com (実際は自分のドメイン名) を入力して、Next をクリック 先程作成した証明書が表示されるので、それをチェックして Next、 変更を確認してAdd domains  Distribution updated successfully と表示され、代替ドメイン名に www.example.com 、カスタムSSL証明書の欄がチェックマークになっていればOKです。 Route domains to CloudFront ボタンを押すと、DNSサーバーに設定する レコードの情報が表示されます。これを、利用しているDNSサーバーに設定します。 DNSプロバイダーによってはAレコードに値を直接入力できない場合がありますが、その場合はCNAMEレコードとして設定しても問題ありません。 今回はここまで。