Zenn
☺️

Manusで作る！Windows用オーディオ切替ウィジェットの開発記

に公開
Windows 10
Audio
manus
tech

Manusで作る！Windows用オーディオ切替ウィジェットの開発記

今回はAIアシスタント「Manus」と一緒に、Windows用のオーディオ出力切替ウィジェットを開発した体験を共有します。この記事では、アイデアの発案から実装、そして様々な技術的課題の解決までの道のりをお伝えします。

きっかけ：日常の小さな不便さ

皆さんは、PCで作業中に「スピーカーからヘッドホンに音声出力を切り替えたい」と思ったとき、どうしていますか？

Windows標準の切替方法は以下の通り：

  1. タスクバーの音量アイコンを右クリック
  2. 「サウンド」を選択
  3. 「再生」タブを開く
  4. 目的のデバイスを右クリック
  5. 「既定のデバイスとして設定」を選択

この5ステップ、毎回行うには面倒すぎますよね。特にオンライン会議中に急いで切り替えたいときなど、ストレスになります。
特にVR系バーチャルデスクトップを繋いだ後はまずオーディオ持ってかれるんですよね。

「常に確認できてワンクリックで切り替えられるツールがあれば...」

そんな思いから、Manusに相談してみることにしました。

Manusとの開発プロセス

要件定義：明確なゴールを設定

まず、Manusに以下の要件を伝えました：

  • Windowsのウィジェットとして動作するアプリ
  • 現在のオーディオ出力デバイスを表示
  • ワンクリックで別のデバイスに切り替え可能
  • 軽量でバックグラウンドで常駐可能
  • 前回選択したデバイスを記憶

Manusはこれらの要件を整理し、実装方針を提案してくれました。C#とWPFを使用し、Core Audio APIでデバイス操作を行う方針です。

技術調査：適切なAPIの選定

Manusは、Windows Core Audio APIに関する情報を収集し、オーディオデバイスの列挙と切替に必要なコードを調査してくれました。

特に印象的だったのは、単にコードを提示するだけでなく、以下のような詳細な説明も付けてくれたこと：

  • IMMDeviceEnumeratorインターフェースの使い方
  • デバイス列挙のためのEnumAudioEndpointsメソッドの使用法
  • デフォルトデバイス設定のためのIPolicyConfigインターフェースの活用方法

UI設計：使いやすさを重視

Manusは、Windows 11風のミニマルなデザインを提案してくれました：

  • 折りたたみ可能なウィジェット
  • デバイスタイプに応じたアイコン表示（スピーカー、ヘッドホン、HDMI等）
  • 展開時にはデバイス一覧をリスト表示
  • 選択するとすぐに切り替わる直感的な操作性

実装：段階的な開発

Manusは、プロジェクト構成から実装まで、段階的に進めてくれました：

  1. Visual Studioソリューションの作成
  2. MVVMパターンに基づくプロジェクト構造の設計
  3. Core Audio APIを利用したデバイス操作機能の実装
  4. WPFによるUI実装
  5. 設定保存機能の追加

直面した技術的課題と解決策

開発は順調に進んでいるように見えましたが、実際にビルドして動かしてみると、いくつかの問題が発生しました。

課題1：Visual Studioのバージョン互換性

最初に提供されたプロジェクトが.NET 6.0向けだったため、古いVisual Studioでは開けないというエラーが発生しました。

MSBuild バージョン 17.0.0 以上が必要です。現在利用可能な MSBuild のバージョンは 16.11.2.50704 です。

Manusは問題を即座に理解し、Visual Studio 2022のインストールを提案。その後も様々なビルドエラーに対して、的確な修正を提供してくれました。

課題2：メモリアクセス違反

最も難しかったのは、アプリ実行時に発生したメモリアクセス違反です：

System.AccessViolationException
Message=Attempted to read or write protected memory.

これはCore Audio APIの低レベルなCOM呼び出しが原因でした。Manusは以下の対応を行いました：

  1. まず構造体定義とメモリ管理を見直した修正版を提供
  2. それでも解決しなかったため、NAudioライブラリを導入する抜本的な改善策を提案
  3. NAudioを使ったコードでも問題が残ったため、COMインターフェース定義を徹底的に見直し

最終的には、正確なインターフェース定義とMarshalAs属性の適切な設定により、問題を解決できました。

課題3：UI動作の不具合

UIの動作にも問題がありました：

  • デバイスをクリックしても切り替わらない
  • ウィジェットが折りたためない
  • ListBoxの参照があいまいというエラー

これらの問題に対しても、Manusは根気強く対応してくれました。特にWPFとWindows Formsの名前空間競合を解決するために、完全修飾名を使用するという解決策は勉強になりました。

完成！使ってみた感想

最終的に完成したアプリは、まさに求めていた機能を実現してくれました：

  • ウィジェットをクリックするとデバイス一覧が表示される
  • デバイスを選択すると即座に切り替わる
  • 軽量で邪魔にならないデザイン
  • 前回使用したデバイスを記憶してくれる

特に気に入ったのは、デバイスタイプに応じたアイコン表示です。視覚的に分かりやすく、どのデバイスに切り替えるか迷うことがなくなりました。

Manusとの開発体験

今回のプロジェクトを通じて、Manusとの開発体験について感じたことをいくつか共有します：

1. 技術的な深さと広さ

Manusは、C#、WPF、Windows API、COMインターフェースなど、多岐にわたる技術領域に精通していました。特に印象的だったのは、問題が発生したときの原因特定と解決策の提案の速さです。

2. 段階的な問題解決アプローチ

複雑な問題に直面したとき、Manusは「まずこれを試してみましょう」という形で段階的に解決策を提案してくれました。一度に全てを解決しようとするのではなく、一歩ずつ進める姿勢が、開発プロセスを分かりやすくしてくれました。

3. 丁寧な説明とドキュメント

コードだけでなく、設計書やREADME、ビルド手順など、充実したドキュメントも提供してくれました。これにより、自分でコードを理解し、必要に応じて修正することも容易になりました。

4. 柔軟な対応力

当初の計画から変更が必要になったとき（例：Core Audio APIの直接利用からNAudioへの切り替え）も、柔軟に対応してくれました。これは実際のソフトウェア開発でも重要な資質だと感じます。

まとめ：Manusとの開発は「共同作業」

今回のプロジェクトを通じて最も感じたのは、Manusとの開発は単なる「AIに命令する」という関係ではなく、本当の意味での「共同作業」だということです。

私が問題を伝え、Manusが解決策を提案し、それを試した結果をフィードバックする...このサイクルを繰り返すことで、一人では難しかったプロジェクトを完成させることができました。

特に、Windows APIのような複雑な領域では、Manusの知識と問題解決能力が大きな助けになりました。

もし皆さんも「あったら便利だけど、作るのは大変そう」というアイデアをお持ちなら、Manusに相談してみることをおすすめします。きっと素晴らしい共同開発体験ができるはずです！

皆さんも、日常の小さな不便を解決するアプリ開発、Manusと一緒に挑戦してみませんか？

Discussion