【Windows】 Google Antigravityのブラウザ関連の問題を解決する方法

WindowsでのAntigravityのブラウザ関連の問題の解決策を紹介します。

以下の2つの問題を解決します。

1. Windows上のAntigravityでブラウザが起動しない
2. WSLにリモート接続したAntigravityでブラウザは起動するがページが開けない

それぞれで対処法が異なります。

Windows上のAntigravityでブラウザが起動しない

ブラウザを起動しようとすると以下のようなメッセージが出て起動しません。

解決方法

1. Antigravityが起動している場合は終了する
2. PowerShellを開く

3. 以下のコマンドを実行する

    [System.Environment]::SetEnvironmentVariable('HOME', "$env:USERPROFILE", 'User')
   

   

4. Antigravityを起動し、ブラウザが起動することを確認する

   

WSLにリモート接続したAntigravityでブラウザは起動するがページが開けない

URLを開こうとすると、ブラウザは起動しますがページが開けません。

以下のようなメッセージが返ってきます。

The open_browser_url tool failed to open https://www.google.com due to a connection error with the browser (CDP port not responsive). I attempted to open the page twice, but both attempts failed with the same error. Therefore, I cannot complete the task of opening Google at this time.

解決方法

1. Antigravityが起動している場合は終了する
2. PowerShellを開く

3. 以下のコマンドを実行し、WSLを一度終了する

    wsl --shutdown
   

4. %USERPROFILE%\.wslconfigを作成し、以下の項目を追加する

    [wsl2]
    networkingMode=mirrored
   

   

5. Antigravityを起動し、ページが開くことを確認する

   

---

参考

• https://www.reddit.com/r/google_antigravity/comments/1qna2oa/fix_does_antigravity_fail_to_agentically_open_the/?tl=ja

Colabの無料枠でHeartMuLaを動かすコード

音楽生成AIのHeartMuLaをGoogle Colabの無料枠で動かすためのコードです。

手順

1. ランタイムをT4に変更してください。
2. 4つのセルを用意し、以下の4つのコードブロックをそれぞれに貼り付けてください。
3. その後、順番に一つずつ実行してください。
4. 2回目以降の生成は、歌詞やタグを変更し、セル2から再実行してください。

# ============================================
# セル1: 環境セットアップ
# ============================================

# 必要なシステムパッケージのインストール
!apt-get update -qq
!apt-get install -y ffmpeg

# リポジトリのクローン
!git clone https://github.com/HeartMuLa/heartlib.git
%cd heartlib

# パッケージのインストール
!pip install -e . -q

# Hugging Faceからモデルをダウンロード
# 推奨版(RL版)を使用
!pip install huggingface_hub -q

from huggingface_hub import snapshot_download

print("HeartMuLaGenをダウンロード中...")
snapshot_download(
    repo_id="HeartMuLa/HeartMuLaGen",
    local_dir="./ckpt"
)

print("HeartMuLa-RL-oss-3B-20260123をダウンロード中...")
snapshot_download(
    repo_id="HeartMuLa/HeartMuLa-RL-oss-3B-20260123",
    local_dir="./ckpt/HeartMuLa-oss-3B"
)

print("HeartCodec-oss-20260123をダウンロード中...")
snapshot_download(
    repo_id="HeartMuLa/HeartCodec-oss-20260123",
    local_dir="./ckpt/HeartCodec-oss"
)

print("ダウンロード完了!")

# ============================================
# セル2: 歌詞とタグの設定
# ============================================

# 歌詞を設定(日本語もOK)
lyrics = """[Intro]

[Verse]
グーグルコラボってすごいな
ジーピーユーが使えるんだ
無料なのに

[Prechorus]
モデルを毎回 ダウンロード
時間がかかるけど

[Chorus]
静けさと叫びの間で
浮かんでは沈んでゆく
優しさと激しさが
同じ場所で交差する

[Outro]
世界の何処かで
ジーピーユーがフル稼働している
"""

# 歌詞ファイルを保存
with open("./assets/my_lyrics.txt", "w", encoding="utf-8") as f:
    f.write(lyrics)

# タグの設定
tags = "synthesizer, electronic, ambient, atmospheric, dreamy"

with open("./assets/my_tags.txt", "w", encoding="utf-8") as f:
    f.write(tags)

print("歌詞とタグを設定しました")
print(f"歌詞:\n{lyrics}")
print(f"\nタグ: {tags}")
"""

# 歌詞ファイルを保存
with open("./assets/my_lyrics.txt", "w", encoding="utf-8") as f:
    f.write(lyrics)

# タグの設定
tags = "synthesizer, electronic, ambient, atmospheric, dreamy"

with open("./assets/my_tags.txt", "w", encoding="utf-8") as f:
    f.write(tags)

print("歌詞とタグを設定しました")
print(f"歌詞:\n{lyrics}")
print(f"\nタグ: {tags}")

# ============================================
# セル3: 音楽生成の実行
# ============================================

!python ./examples/run_music_generation.py \
    --model_path=./ckpt \
    --version="3B" \
    --lyrics=./assets/my_lyrics.txt \
    --tags=./assets/my_tags.txt \
    --save_path=./assets/output.mp3 \
    --max_audio_length_ms=240000 \
    --topk=50 \
    --temperature=1.0 \
    --cfg_scale=1.5 \
    --lazy_load=true

print("\n音楽生成が完了しました!")

# ============================================
# セル4: 生成された音楽の再生
# ============================================

from IPython.display import Audio, display
from google.colab import files

# 音楽の再生
print("生成された音楽:")
display(Audio('./assets/output.mp3'))

2026年2月1日に動作確認済みです。もし動かない場合はコメント欄でお知らせいただけたら、できる限り対処したいと思います。

github.com

OnnxStreamをRaspberry Pi 3 B+でビルドしたときのアセンブラエラーの解決方法

OnnxStreamビルド時のエラー

Raspberry Pi 3B+でOnnxStreamをビルドしようとしたところ、アセンブラエラーに遭遇しました。

[ 14%] Building C object CMakeFiles/microkernels-prod.dir/src/qd8-f16-qb4w-gemm/gen/qd8-f16-qb4w-gemm-1x16c4-minmax-neondotfp16arith.c.o
/tmp/cciHYoZB.s: Assembler messages:
/tmp/cciHYoZB.s:96: Error: selected processor does not support `vsdot.s8 q11,q5,d7[0]' in ARM mode
/tmp/cciHYoZB.s:101: Error: selected processor does not support `vsdot.s8 q11,q10,d7[1]' in ARM mode
/tmp/cciHYoZB.s:102: Error: selected processor does not support `vsdot.s8 q13,q5,d7[0]' in ARM mode
/tmp/cciHYoZB.s:103: Error: selected processor does not support `vsdot.s8 q13,q8,d7[1]' in ARM mode
/tmp/cciHYoZB.s:105: Error: selected processor does not support `vsdot.s8 q14,q6,d7[0]' in ARM mode
/tmp/cciHYoZB.s:107: Error: selected processor does not support `vsdot.s8 q14,q9,d7[1]' in ARM mode
/tmp/cciHYoZB.s:111: Error: selected processor does not support `vsdot.s8 q12,q9,d7[0]' in ARM mode
/tmp/cciHYoZB.s:112: Error: selected processor does not support `vsdot.s8 q12,q8,d7[1]' in ARM mode
/tmp/cciHYoZB.s:202: Error: selected processor does not support `vsdot.s8 q13,q8,d7[0]' in ARM mode
/tmp/cciHYoZB.s:206: Error: selected processor does not support `vsdot.s8 q11,q9,d7[0]' in ARM mode
/tmp/cciHYoZB.s:208: Error: selected processor does not support `vsdot.s8 q14,q8,d7[0]' in ARM mode
/tmp/cciHYoZB.s:211: Error: selected processor does not support `vsdot.s8 q12,q8,d7[0]' in ARM mode
gmake[5]: *** [CMakeFiles/microkernels-prod.dir/build.make:4049: CMakeFiles/microkernels-prod.dir/src/qd8-f16-qb4w-gemm/gen/qd8-f16-qb4w-gemm-1x16c4-minmax-neondotfp16arith.c.o] Error 1
gmake[4]: *** [CMakeFiles/Makefile2:631: CMakeFiles/microkernels-prod.dir/all] Error 2
gmake[3]: *** [Makefile:149: all] Error 2
gmake[2]: *** [CMakeFiles/xnnpack_build.dir/build.make:133: xnnpack_build-prefix/src/xnnpack_build-stamp/xnnpack_build-build] Error 2
gmake[1]: *** [CMakeFiles/Makefile2:124: CMakeFiles/xnnpack_build.dir/all] Error 2
gmake: *** [Makefile:103: all] Error 2

解決方法

OnnxStream/src/CMakeLists.txtのXNNPACK_CMAKE_ARGSに-DXNNPACK_ENABLE_ARM_DOTPROD=OFFを追加します。

set(XNNPACK_CMAKE_ARGS
        -DCMAKE_BUILD_TYPE=Release
        -DXNNPACK_BUILD_TESTS=OFF
        -DXNNPACK_BUILD_BENCHMARKS=OFF
        -DCMAKE_POSITION_INDEPENDENT_CODE=${OS_SHAREDLIB}
        -DXNNPACK_LIBRARY_TYPE=static
        -DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE}
        -DXNNPACK_ENABLE_ARM_DOTPROD=OFF       【これを追加する】
)

その後、ビルドをやり直すと正常にできるはずです。

Windows Updateで「Canon – Printer」エラーが出たときの直し方（printmanagement.msc使用）

Windows Update に 「Canon – Printer – … で失敗（0x800f020b）」 と出続けることがあります。 原因のほとんどは、もう使っていない Canon プリンターのドライバーだけが PC に残っていて、Windows Update がそれを更新しようとして失敗しているケースです。

この記事では printmanagement.msc（印刷管理コンソール） を使って、不要な Canon ドライバーを削除し、エラーを消す手順を解説します。

前提と注意

• 対象：Windows 10/11 の 印刷管理コンソールが使えるエディション（Pro / Enterpriseなど）。
• 管理者権限のアカウントで作業してください。
• まだ使っている Canon プリンターがある場合は削除しないでください。

ゴール

• Print Management から Canon のプリンタードライバーを削除する → Windows Update の「Canon – Printer…」更新が表示/失敗しなくなる

手順

1) 印刷管理コンソールを開く

1. Win + R を押す
2. printmanagement.msc と入力 → Enter

2) ドライバー一覧を表示

左ペインで 「プリント サーバー」 →（自分のPC名）→「ドライバー」 を選択。

右ペインに、この PC に入っているプリンタードライバーが一覧表示されます。

3) Canon のドライバーを見つける

• 列の「プロバイダー」または「名前」をクリックして並べ替え。
• Canon / Canon Inc. が付いている行（x64 などアーキテクチャも確認）を特定します。

4) Canon ドライバーを削除

1. 対象の Canon ドライバーを右クリック → 「削除」。
2. 「使用中のプリンターがあります」等のダイアログが出たら、同コンソール左ペインの 「プリンター」 で該当プリンターが残っていないか確認し、あれば 右クリック→削除。 その後もう一度ドライバーの削除を実行します。
3. 複数の Canon ドライバーがある場合は すべて削除します。
4. 念のためコンソールの 「表示の最新の情報に更新」 を押して、Canon の行が消えたことを確認。

メモ：削除直後に「プリント スプーラー」再起動や再起動を促されることがあります。指示に従ってください。

5) Windows Update を再チェック

1. 設定 → Windows Update → 更新プログラムのチェック
2. これまで出ていた 「Canon – Printer – …」 の更新が表示されなくなれば完了です。

なぜGitHub Actionsはパブリックリポジトリで無料無制限なのか

ソフトウェア開発に携わっている方なら、「GitHub Actions」という言葉を耳にしたことがあるでしょう。コードの変更がプッシュされるたびに自動でテストを実行したり、デプロイを行ったりと、CI/CD（継続的インテグレーション/継続的デリバリー）の自動化に欠かせないツールです。

多くのクラウドサービスが利用量に応じて課金される中、GitHub Actionsがパブリックリポジトリで「無料かつ無制限」に利用できる、という点は驚きに感じるかもしれません。一体なぜ、GitHubはこの太っ腹なサービスを提供しているのでしょうか？今回はその理由と、GitHubの戦略的な意図について深掘りしていきます。

GitHub Actionsとは？

まず簡単に、GitHub Actionsについておさらいしておきましょう。

GitHub Actionsは、GitHub上でソフトウェア開発のワークフローを自動化するためのプラットフォームです。リポジトリでのイベント（例: プッシュ、プルリクエストの作成、Issueのオープンなど）をトリガーとして、コードのビルド、テスト、デプロイなど、様々なタスクを自動実行できます。これにより、開発チームは手作業の負担を減らし、より迅速かつ高品質なソフトウェア開発に集中できるようになります。

パブリックリポジトリでの「無料無制限」の真意

さて、本題の「なぜパブリックリポジトリで無料無制限なのか？」という疑問に迫ります。結論から言うと、これはGitHub（そしてその親会社であるMicrosoft）の多角的な戦略と、オープンソースエコシステムへの深いコミットメントに基づいています。

1. オープンソースコミュニティの育成と支援

現代のソフトウェア開発は、オープンソースソフトウェア（OSS）なくしては成り立ちません。OS、ライブラリ、フレームワークの多くはOSSであり、商用プロダクトもOSSの上に成り立っています。

GitHubは、OSS開発者がCI/CDツールにかかる費用を気にすることなく、最高品質のツールを利用できるようにすることで、OSSプロジェクト全体の品質向上と開発効率アップを強力に後押ししています。OSSが発展すればするほど、それを基盤とするソフトウェア産業全体が活性化し、結果としてGitHubプラットフォームの価値も高まります。これは、長期的な視点に立った投資と言えるでしょう。

2. プラットフォームの普及とユーザー獲得

GitHub Actionsを無料で利用可能にすることで、より多くの開発者や企業がGitHubのプラットフォームに惹きつけられます。特に、多くの開発者が関わるOSSプロジェクトでGitHub Actionsが広く使われることで、GitHubのユーザーベースは飛躍的に拡大します。

一度GitHub Actionsの利便性を体験すれば、その使いやすさから他のプロジェクト（例えばプライベートリポジトリでの開発）でも利用したくなるでしょう。結果的に、有料プランへのアップグレードや、GitHubエコシステムへの囲い込みにつながる可能性を秘めています。

3. エコシステムの強化と標準化

GitHub Actionsには、世界中の開発者が作成・公開している「Actions」と呼ばれる再利用可能なワークフローの部品が豊富に存在します。無料で無制限に利用できることで、これらのActionsの開発と共有が活発になり、GitHub Actionsのエコシステムはますます豊かになります。

これにより、GitHub Actionsはより多機能で汎用性の高いCI/CDプラットフォームとなり、事実上の業界標準として多くの開発者に選ばれる存在となることを目指しています。

4. ブランドイメージの向上

オープンソースコミュニティへの積極的な貢献は、企業としてのブランドイメージを大きく高めます。GitHubがOSS開発を強力に支援することで、「開発者にとって最高のプラットフォーム」というポジショニングを確立し、技術者からの信頼と尊敬を獲得しています。これは、採用活動においても有利に働くことでしょう。

5. フィードバックとデータによるサービス改善

膨大な数のワークフローがパブリックリポジトリで実行されることで、GitHubはActionsの利用状況に関する貴重なデータを収集できます。これにより、サービスのパフォーマンス改善、新機能の企画、ボトルネックの特定など、プラットフォーム全体の継続的な進化に役立てられています。

まとめ：戦略的な「無料」の裏側

GitHub Actionsがパブリックリポジトリで無料かつ無制限に提供されているのは、単なるサービス精神だけでなく、GitHubの周到なビジネス戦略に基づいています。オープンソースエコシステムへの貢献を通じて、プラットフォームの普及を促進し、ユーザーベースを拡大し、最終的には自社のビジネス成長に繋げるという、非常に巧妙なモデルです。

私たち開発者にとっては、この「無料無制限」の恩恵を最大限に活用し、より効率的で高品質なソフトウェア開発を実現できる、非常に素晴らしい環境が提供されていると言えるでしょう。

Ubuntu の curl でOneDrive クライアントが警告を出す理由と対処法まとめ

Ubuntu 22.04 や Debian 系 Linux 環境で onedrive クライアント を使っていて、こんな警告が出たことはありませんか？

WARNING: Your cURL/libcurl version (7.81.0) has known HTTP/2 bugs that impact the use of this client.
         Please report this to your distribution, requesting an update to a newer cURL version, or consider upgrading it yourself for optimal stability.
         Downgrading all client operations to use HTTP/1.1 to ensure maximum operational stability.

今回はこの警告の意味と、技術的背景、そして具体的な対処法を分かりやすく解説します。

---

🔍 何が起きているのか？

この警告は、あなたの環境にある curl 7.81.0 に HTTP/2 に関する複数の既知バグがあるため、OneDrive クライアントが安全のために HTTP/1.1 に強制ダウングレードしていることを意味しています。

---

🧠 バージョン別 curl のHTTPバージョン対応状況

OneDrive クライアントは curl ライブラリのバージョンに応じて、HTTP/1.1 と HTTP/2 を使い分けます。

curl バージョン	デフォルト動作	コメント
< 7.47.0	HTTP/1.1	古すぎる
7.47.0〜7.61.9	HTTP/1.1 優先	問題なし
7.62.0〜現在	HTTP/2 優先（HTTPS）	要注意 ⚠️

この中で、7.62.0 以降は HTTP/2 を積極的に使おうとしますが、それに伴い問題が発生します。

---

🐛 curl 7.81.0 に含まれる既知バグ（抜粋）

Ubuntu 22.04 に標準搭載されている curl 7.81.0 には、以下のような HTTP/2 関連のバグが報告されています：

バグ番号	内容
#5	HTTP/2 接続が途中で勝手に切れる
#6	フレーム処理のバグでデータ破損の可能性
#7	ストリームが適切に閉じられずメモリリークが発生
#8〜13	通信のハング、予期せぬ切断、SIGPIPE シグナル未処理など

つまり、正常な HTTP/2 通信が保証されない状態です。

---

⚠️ 放置するとどうなる？

• アップロード／ダウンロード失敗
• クライアントが突然終了
• 「HTTP2 framing layer error」などの通信エラー発生
• 「タイムアウト」「DNS 解決失敗」などの曖昧なエラー

など、日常的な OneDrive の利用に支障が出る可能性が高いです。

---

✅ 対処法

方法①：curl を最新版（8.11.0 以上）にアップグレード【推奨】

最も根本的な解決方法です。以下のようにしてアップグレードできます（例：Debian/Ubuntu）。

sudo add-apt-repository ppa:curlpp/ppa
sudo apt update
sudo apt install curl

※または backports や自前ビルドで導入。

---

方法②：OneDrive クライアント側で HTTP/1.1 & IPv4 を強制

curl の更新が難しい場合は、設定で回避可能です。

~/.config/onedrive/config に以下を追加：

force_http_11 = "true"
ip_protocol_version = "1"

これにより：

• HTTP/2 を完全無効化
• curl の IPv6 DNS バグも回避

安定性重視なら、この設定でも十分運用可能です。

---

✏️ まとめ

対策内容	効果	難易度
curl を最新版にする	根本解決、HTTP/2 使用可能	中〜高
HTTP/1.1 & IPv4 強制設定	安定運用可、制限あり	低

Ubuntu 22.04 のような LTS 環境では古い curl を使い続けているケースが多いため、この問題に遭遇する人は少なくありません。警告が出たら無視せず、早めに対処しておきましょう！

---

🔗 関連リンク

• onedrive クライアント 公式 GitHub ドキュメント
• curl 公式リリースノート

Git における `assume-unchanged` と `skip-worktree` の技術的比較

はじめに

Git を利用する開発現場では、特定のファイルを「一時的に無視」したいというニーズが頻繁に発生する。例えば、共有リポジトリ内の構成ファイルや、ビルドによって一時的に変更されるファイルが該当する。

Git にはこのようなケースに対応する2つの機能が存在する：
- assume-unchanged
- skip-worktree

本稿では、これら2つの機能の違い、使いどころ、内部挙動を技術的観点から明確に比較する。

---

1. 基本概念

1.1 assume-unchanged

git update-index --assume-unchanged <path>

このコマンドは、Git に対して「このファイルは今後変更されないものとして扱ってよい」というヒントを与える。
Git のステータストラッキングにおいて、変更検知の対象から外されるため、git status でも変更が表示されなくなる。

ただし、実際には 変更されていても Git はそれに気づかない という点で注意が必要である。

1.2 skip-worktree

git update-index --skip-worktree <path>

こちらは「このファイルの内容はワークツリー上で編集されても、Git は一切関知しない」ことを意味する。
Git の挙動としては、ローカルの変更は完全に無視されるうえに、pull などによってリモートの変更が存在しても、上書きされることがない。

この動作は、開発者ごとの設定差異（例：.env, config.json）など、ローカルで保持すべきカスタムファイルを扱う場面に適している。

---

2. 比較表

特徴	assume-unchanged	skip-worktree
ステージング対象になるか	いいえ	いいえ
git status で表示されるか	表示されない	表示されない
git diff に出るか	出ない	出ない
リモート変更で pull 時に上書きされるか	上書きされる可能性あり	上書きされない（安全）
用途	ビルド成果物、一時ファイルなど	設定ファイルのローカル上書きなど
フラグの優先度	低	高（競合時はこちらが効く）

---

3. 内部挙動の違い

両者は Git の index に対して異なるフラグを設定している。

• assume-unchanged は「パフォーマンス最適化」の一環で設計されており、あくまで Git のチェックを省略することが目的。
• skip-worktree は「意図的に作業ディレクトリで変更されるファイル」に対する処理として設計されており、追跡から除外することが目的。

git ls-files -v

上記コマンドで現在のフラグ状態を確認可能である。

プレフィックス	意味
H	skip-worktree
h	assume-unchanged

---

4. 両者を同時に使った場合

技術的には、assume-unchanged と skip-worktree の両方のフラグを同じファイルに対して設定することは可能である。
ただし、skip-worktree のほうが優先されるため、assume-unchanged を併用する意味は事実上ない。

---

5. 実用的な適用例

ケース1：自動生成ファイル（例：.min.js, *.cache）

→ assume-unchanged が適している。
ローカルでのビルドで変更されるが、Git 上のトラッキングは不要な場合。

ケース2：開発者ごとのローカル設定（例：config.local.json）

→ skip-worktree を使用するべき。
Git 管理は維持しつつ、ローカルごとの差異を無視したい場合。

---

6. 注意点と運用上のリスク

• どちらのフラグも Git の状態を「隠蔽」するものであり、使い方を誤ると意図せぬデータ損失が発生する可能性がある
• 特にチーム開発では、ドキュメントで運用ルールを明示すべき
• CI/CD パイプラインや GitHub Actions がこれらのファイルに関与する場合、.gitignore との整合性にも注意する必要がある

---

おわりに

assume-unchanged と skip-worktree は見た目の挙動が似ているため混同されがちだが、目的と設計思想が異なる。

正しく理解し、目的に応じて使い分けることで、Git による開発フローをより安全かつ柔軟に構築できる。